Today’s complex products require integrated product architecture to drive product development. What if we could extend that product architecture into the supply chain, extending MBSE?
The MBSE Journey
MBSE is a journey for your organization AND your supply chain. However, depending on where we started our Model-Based Systems Engineering (MBSE) journey, we tend to be insular in our MBSE processes and tool implementations focusing on our organization and ignoring our supply chain.We may have gotten away with this in the past as vertically integrated/self-contained industries, but today’s multi-domain electronics, software, optics, mechanics, et al.-type products involve substantial supply chains that provide critical pieces of our finished products demanding tight-process integration if we expect to succeed.
Growing up in the high technology component and systems business, I learned the program planning rule of thumb that you could count on half your program being consumed by systems integration.I went looking for guidance/advice on where this came from, but couldn’t find it, but everyone I talk to in aero, auto, and other complex development industries aren’t surprised by that statement and expect to spend as much as half a programs resources/time on bringing everything together, finding problems, and then iterating–adding time to program schedules while increasing risk of runaway projects (i.e. with more time spent on integration than original design).
Integration is Complex
As product complexity increases, there’s a growing realization that we can’t run programs/projects like we use to and we need to figure out how to get everyone including our suppliers to be on the same page continuously because we can no longer afford to build and integrate products like we use to.We need to make sure we are extending MBSE.
For example, after watching aircraft complexity and cost soar; approaching unaffordability, the aerospace business has started collaborating around The Aerospace Vehicle Systems Institute (AVSI) (avsi.aero) hosted at Texas A&M University. AVSI is a consortium of aerospace companies whose goal is to achieve superior results at lower cost.They have launched a number of initiatives including the System Architecture Virtual Integration (SAVI) (savi.avsi.aero) project.SAVI is about changing the way we develop aircraft by starting integrated and staying integrated or in their words “integrate and then build”.
They’ve researched/monitor a number of system complexity metrics, like this one measuring system complexity based on software source lines of code (SLOC):
…along with some interesting descriptive quotes:
“Development effort, which increases exponentially with SLOC, is increasing at an alarming rate.For example, the F35 has approximately 175 times the number of SLOC as the F16. But, it is estimated to have required 300 times the development effort”
…which claim we reached the limits of our existing serial processes. This means the classic way of building aircraft: spec, integrate, and repeat is no longer affordable. So, what do we do differently?
MBSE solutions produce the product architecture/blueprints that drive today’s complex product development processes. Product architecture’s purpose is to communicate what to do and how to do it to all disciplines to drive an integrated solution; or put another way architecture needs to be integrated with the suppliers which are delivering major parts of the product.
Standard Language to Communicate
For many years the lack of standard systems modeling language (like the software or electronics industry has) has hampered these efforts, but with the arrival of SysML v1, we finally have a standard graphical language with which to communicate. The problem is that the language is so flexible it allows describing the same solution in many different ways along with the inability to isolate subsystems so OEM’s can share subsystem content with suppliers without providing whole system model (i.e. IP problems).
Back in Jan. 2019, the Aerospace & Defense PLM Action Group released a MBSE Data Interoperability problem statement & assessment describing this supplier integration issue and requesting input from MBSE tool suppliers on how to address this SysML OEM-Supplier data exchange problem.They executed eight sample package exchanges with suppliers resulting in a successful digital exchange of less than 50% of the time with the ability to interpret the design intent less than 20% of the time.They concluded, “it was not yet feasible to exchange MBSE system architecture & requirements with current tools”—i.e. the current standard language and exchange mechanisms cannot support the start integrated, stay integrated paradigm change.
Luckily, this issue along with other shortcomings have been recognized and is being addressed by the next generation SysML language—SysML v2.SysML v2 recognizes the role of Product Lifecycle Management (PLM) and the necessity of integrating system architecture with PLM for this type of supplier collaboration.
Siemens is not only participating on SysML v2 standard development teams but also actively working with existing SysML tool suppliers to integrate product architecture with the product lifecycle (which already does the job of supplier integration/data exchange for other disciplines)
Back in 2018, we announced a partnership/integration with Obeo’s open source Capella solution which includes an integrated ISO15288 standard process methodology ARCADIA to enable this supply chain collaboration.We have since launched a Teamcenter PLM integrated solution called System Modeling Workbench (SMW) that allows organizations and their supply chain to collaborate around a streamlined SysML language extending MBSE into the supply chain, creating what we call a Model-Based Design Chain (MBDC).We’ll be talking more about MBDC in future blogs.
Register Now, and Join Us!
If you’d like to learn more about this, join us on Thursday, December 5, 2019 for our next integrated MBSE webinar to learn how Siemens’ System Modeling Workbench (SMW) integrates system modeling/product architecture with Teamcenter PLM and an OOTB standard based methodology to guide users to create product architectures to not only drive design inside your organization but through your entire supply chain creating a Model Based Design Chain to support a closed-loop product development process—so you can start integrated, stay integrated.
Want to learn more? Have you looked at the other Model Based System Engineering Articles?