⌚ Ready to cut system integration cost by 50%?

By Mark Sampson

Why spend 1/2 your program schedule and resources on system integration?

System Integration consumes a major portion of program schedules and resources as you bring software, electronics, and mechanics together.

In my blog Extending MBSE into your supply chain I described how you actually plan for integration issues and spend 30%-70% of your program schedules/resources bringing everything together on the right side of the V.

Why we have integration problems…

Looking at the V process the reason is clear:

Looking at the standard Aero ARP4754 process shows how the various development silos fit into the V process. Requirements are developed in one silo, tests used to verify those requirements is in another silo, architecture is somewhere else, and so on. This means there is no single source of truth, no cross-domain traceability, no lessons learned passed on, etc. as each silo is doing its own thing with its own toolsets.

You could blame the V process, but this V lays on top of an organization, which according to Conway’s Law says, organizations develop products that match their organization structures — that is we develop in silos and wait until we get to the right side of the V to do system integration, discover the integration problems, and THEN start integrating.

The Aerospace Vehicle System Institute (AVSI) Systems Architecture Virtual Integration Project (SAVI) says this has to change as it is no longer affordable to build airplanes how we used to (see Augustine’s Law #16) — crossing the affordability limit for both commercial and military aircraft back in 2013.

The project has gathered various measures of complexity from member organizations like this one for Source Lines-of-Code (SLOC):

One measure of aero system complexity taken from Aerospace Vehicle Systems Institute ( https://savi.avsi.aero/about-savi/)

They suggest a change from the current “spec-design-integrate” process to a “integrate, then build” process or as they put “start integrated, stay integrated”. So why do we put up with this? As one aero person put it to me, “because that’s how we’ve always done it.”

How to start integrated, stay integrated…

Putting aside the organization issues needed to do that shift for the moment, “starting integrated” will require capture and management of the cross-domain product drivers (architecture, requirements, parameters,…) in the organization’s Product Lifecycle Management (PLM) system so it can drive continuous integration:

Product architecture drives cross-product relationships that enables cross-product impact understanding
Requirements describing how well something is done need to show up across-silos to influence design decisions as they are happening
Parameters participate in configuration, so the right version is used in simulations, tests, etc.

“Staying integrated” requires managing/controlling the artifacts through standard PLM services like change, configuration, workflow, variation, and more:

A regulatory/requirement change follows product structures and allocations to notify all impacted by a change. Change management ensures that all affected are included and actions are completed with evidence maintaining a documented history of the product.
Testing knows which versions of test cases need to be performed, when, what resource are required, what versions of parameters, test equipment calibration status, etc. along with how they test outcomes compare with predicted digital twin results, etc.

Starting Integrated, Staying Integrated holds the promise of bringing us back to affordable.

Does this work?

According to Air Force Magazine, Boeing applied these techniques on the T-X trainer bending the cost curve down 50% less cost than what the USAF expected:

75% increase in first pass quality
50% less software development hours
80% reduction in assembly hours

..and this great quote from the project Chief Engineer:

Probably the most significant stats that we had, we went through the first 14 flights without a pilot squawk [integration issue]. That is a testament to how we went through this journey, [we] had a robust design.
Paul Niewald Boeing T-X Chief Engineer