@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.
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.
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.