latenlazy
I really should change my personal text
- Joined
- 4 July 2011
- Messages
- 245
- Reaction score
- 37
Part of the issue is that the component technologies themselves have become more complicated. The more complicated your component technology the more the complications of their integration dependencies multiply by an order of magnitude. Frankly, I think if a modular solution is what you want, it makes more sense to unpack one complex integrated platform into a bunch of distribute and delegated platforms, than to welcome in the contradiction of trying to make a complex integrated platform more modular in its internal construction and design. Alternatively, you can also focus on simplifying your component technologies rather than modularizing your integrated platform. No amount of modularization will make your integrated platform more adaptable if the components that are being integrated only increase in complexity. A lot of what goes into making these kinds of products more program efficient and effective really comes down to managing complexity rather than increasing iteration or modularity.after reading this, it once again becomes a big issue...Why manned craft adding continual complication and cost?This all sounds good in theory until you realize the standardized frameworks and interfaces you need to get your modularizable solution can end up imposing their own performance constraints, especially for hardware with a lot of integrated dependencies. There are serious problems in trying to adapt software development models, which tend to benefit from open ended and adaptive development paths for meeting performance parameters (both as a function of their level of abstraction and in no small part thanks to excess of computational power now available), as well as fast iterative workflows (updating code is a much less burdensome task than tinkering with physical hardware) to hardware domains where constraints are physically based and hitting performance targets require specific integration dependencies that are closed looped.@BDF : I think you forgot to factor-in the effect of having shared sub-systems and software across different airframe. That will translate into substantial cross-fleet economies. IMOHO you should add a K factor into the above equation and add fleet numbers:
With Ni the N number of airframe of type i fleet, TOC = $160M * K*Sqrt(N1+N2+...+Nn).
With K a function of the level of cross-integration of sub-systems (K>1 and lim(K) =1 when integration is fully optimal). K is an indice of Quality.
Often times what ends up happening when these models from software engineering are applied too zealously to hardware is that you end up compounding the cost problem when you find yourself spending time not so much updating components as you are wasting time trying to update the original frameworks to enable greater capability for future technology that works differently from the protocols that the framework was originally configured for. Modular iterative approaches are essentially vulnerable to greater technical debt that accumulates as the framework ages, and this technical debt tends to be a lot more costly when what you’re trying to fit together are complex physical objects rather than abstract logic represented by lines of code. This doesn’t mean that these kinds of iterative open ended program concepts can’t work, but there are a lot of ways they can go horribly wrong, amplifying the time, performance, and resource problems that were originally meant to be solved by its adoption.
Last edited: