Sometimes,
“Depth Perception” by Roxie Prince
I wish my waters didn’t run so deep.
Perhaps,
if they were shallow,
they’d be sparkling,
crisp,
and clear to the bottom
instead of dark and often
murky.
How deep do you go with MBSE? (To use a phrase from the MagicGrid BoK: How much precision do you need?) For that matter, where does Systems Engineering stop and software, mechanical, electrical, integration, etc. engineering begin? Each organization is going to have a different (murky) idea. And how much SE modeling constitutes MBSE. This is the prerogative of the program’s Chief Systems Engineer. Years ago when the software discipline was transitioning from functional programming to Object-Oriented programming we had a similar question. Just using C++ did not mean you got all the benefits of OO. Just using SysML and an MBSE tool does not mean you will get all the benefits of MBSE.
Systems are made of segments, elements, subsystems, modules, assemblies, etc. The taxonomy you use may be dictated by a government customer or it may be your organization’s Best Practices. Each of these hierarchical system components will likely have a part number, a pile of documents, defined interfaces, and a specification.
This hierarchy of part numbers is sometimes called a Bill of Materials and there will likely be a corresponding hierarchy of Specifications (a Spec Tree). At the bottom of these hierarchies are the things that get used over and over in other systems. Usually the items above the bottom layer are composites and are unique to this system configuration.
We the Systems Engineers need to create models that extend to and include this bottom layer of assemblies. Moreover, each of these assemblies should have its own model just as it has its own part number, specification, and pile of documentation.
This is where the engineering rubber meets the road. Each of these assemblies, sometimes called Configuration Items by the DoD, are where the SE turns control over to the development engineers. The software, firmware, electronics, power, network, mechanical, test, etc. engineers will go off and create some tech marvel based on the SE’s direction. Each of these assemblies will then end up in the integration lab. Good or bad Systems Engineering is not detectable until the assemblies are in integration.
INCOSE, NASA, and my current gig are all looking at MBSE maturity models. Maybe we should call these ‘depth’ models… I might have a very ‘mature’ capability, but if I choose to only model to a certain depth (or precision) we will not realize the full benefits (ROI) of MBSE. Only when we choose to model to the Assembly level can we develop an electronic hand-off to the development disciplines and to the integrators who fold it all together. Only when we have a library of Assembly models can one quickly create a systems model and a digital hand-off that is “crisp and clear to the bottom.”
Photo by Ethan Elisara on Unsplash