The Digital Thread – Is Model Based System Engineering (MBSE) Weaving the Fabric?
The term digital thread has become something of a buzzword lately that goes beyond the aerospace and defense industries to include manufacturing and other sophisticated physical systems. Systems engineering is a part of that digital thread. Specifically, Model-based systems engineering (MBSE) is a vital part of the broader digital fabric. Likewise, SysML is a subset of MBSE, and a key part of threading the fabric. The digital thread also includes end-to-end processes including cost, resources, and supply chain management. MBSE, on the other hand, is the fundamental way of communicating between all the other engineering disciplines.
Mechanical, software, and electrical are all engineering disciplines, but none are systems engineering alone. CAD is not system engineering. CAD’s primary communication function is directed to mechanical and electrical engineering. Likewise, software and electrical engineers, people with whom I respect and collaborate with on a weekly basis, are not systems engineers. MBSE is the core section of the fabric that uses these other’s information, and pulls them all together.
The Digital Thread Puts Engineering Back Into Systems Engineering
The way this happens is by way of the language, or through SysML. In other words, the need for the systems engineer to document everything is through SysML. SysML becomes the weaver of the digital fabric. If you bypass SysML for tracing items, for example a requirement to a part in CAD/PLM, it will be difficult to know where to pull on that thread. If that part had some systems design information, it may link into SysML but the path of the thread would be miswoven.
Pulling on the Digital Thread
The digital thread is virtually everything you can think of. This includes requirements, pre-requirements (conceptual modeling), and capabilities. Doing conceptual and capabilities modeling comes before requirements. It also goes through textual requirements and back into systems engineering. It then goes on and on through the process until you arrive at disposing of the product in the end. I should be able to pull on the digital thread and say, “Give me everything related to this specific part of the product.” We also call this traceability, which is a standard term throughout the world and cross disciplines. Similarly, impact analysis, would be like pulling on the thread and seeing where it goes. This would show where one specific piece of information, as it flows through all of my products, ends up.
For instance, say I want to change the range of a missile by 500 miles. In theory, I could pull on the thread, and my system should be able to answer several questions. It should tell me “what else will that touch? and “how much is the fuel?” This means having to consider the physical dimensions of how much it can hold. This also means having to talk to the electrical engineers, because perhaps fuel efficiency can help, or maybe software can help with how they are doing their thrust analysis, and on and on into the fabric of the system. Without the systems engineer weaving the fabric together, we would not be able to see these connections.
The Digital Thread Defined
The Digital Thread as defined by the USAF is “the creation and use of cross-domain, common digital surrogates of a materiel (military materials and equipment) system to allow dynamic, contemporaneous assessment of the system’s current and future capabilities to inform decisions in the Capability Planning and Analysis, Preliminary Design, Detailed Design, Manufacturing, Testing, and Sustainment acquisition phases. The digital surrogate is a physics-based technical description of the weapon system resulting from the generation, management, and application of data, models, and information from authoritative sources across the system’s life cycle.” Other systems besides military can benefit from this concept and the role design plays in the preliminary phases of structuring the system.
Moving Away From Textual Requirements
Engineers can, and often do, document their processes quite successfully using requirements-based tools. However a model can help them visualize the system. A model will demonstrate what the levels are, what components have which parts, and how things are allocated throughout the system. It will also show how you can you capture everything together conceptually, rather than just doing flat documentation, and even creating textual based requirements in a modeling form. Optimally you should have activity diagrams document the process of information, and sequence diagrams to describe the order of data exchanges. This level of modeling will minimize the need for textual requirements and greatly increase productivity, traceability, re-usability, and understanding.
US Army Leading the Way Towards MBSE
VOLKEL, NETHERLANDS – JUNE 15: Dutch Air Force CH-47 Chinook during the Air Power Demo at Royal Netherlands Air Force Days June 15, 2013 in Volkel, Netherlands.
Organizations that have benefited from this change from document-centric to a model-based approach are growing. The US Army is currently testing out all of the tools in the market for model-based. They are leading the way towards understanding what the model-based possibilities are. If only other organizations followed their lead, how much greater efficiency, and better communication there would be!
The goal of the initial trial should be to model everything and to keep communication at the critical information level. Another important objective is to understand what the order of logic is. This will result in reducing errors that occur when reading stacks of requirement documents and trying to tie the various parts together. We can identify the number of error reductions and prove them out. They need this valuable information before anything is executed. They also need to know how to materialize concepts so that they are not just reading drawing text to documents.
USAF Selects Lead Programs For ‘Digital Twin’ Initiative
US Army RDECOM is funding the Joint Multi Role Technology Demonstration (JMRTD) to do a technology trade study and maturation of the available tools in the marketplace to remove the need for textual and/or digital requirements to all digital information models. This information comes from the JMR Briefing Slides.
MBSE Becoming the Standard for Modern Systems
Organizations like Northrop-Grumman, Raytheon, Lockheed Martin, and Boeing are no longer adequately served by textual requirements format and lack of cross-correlation ability. Companies such as these are increasingly using and reaping the benefits of the model-based technique.
When companies transform completely into a model based approach, system definitions will become less ambiguous. MBSE is becoming a way not only for designing the system, but in weaving the fabric for the digital thread itself.
