What is MBSE and why do industries start to use?
Today’s multi-disciplinary, multi-supplier, and multi-application/tool product development environment encourages customers to adopt agile practices under firm deadlines. Agility is especially important in more traditional engineering environments such as aerospace, energy, and automotive industries, where waterfall product development has been long practiced and perfected.
As these products are highly complex, following a build-based agile iteration is expensive. Moreover, these industries are highly regulated and exceptionally quality-driven. Hence, the agility should not bear "haste creates waste" but should bear technologies that allow data-driven decisions, visibility, traceability, simplicity, and preferably automation to “go fast” while “sticking to highest standards”.
Complex product development requires inter-disciplinary and inter-supplier/company work. Hence, customers look for ways to be agile in this complex and dynamic environment. At the center of the complexity, we see Systems Engineering (SE).
According to the INCOSE (International Council on
Systems Engineering)
The term system here is a wide-range definition, including hardware, software, information, processes, people, configurations, supply chains, regulators and geographies. One of the fundamental functions of SE is to conduct the Verification and Validation (V&V) of the product development and overall lifecycle.
Verification and Validation through a product development, MBSE, traditional SE cost and cost of defects to the project
(V&V figures are adapted from Clarus Concept of Operations
Above you can see the stages of a waterfall product development method with the V&V diagram.
V&V is designed to follow the product development and the product itself in compliance with the requirements. Verification asks “are we building the product right?”, while Validation asks “are we building the right product?”.
V&V helps minimize late defect discovery by engineering and manufacturing functions orchestrated by systems engineering costs more with issue discovery near the end. It is good to know about serious issues sooner, rather than later.
Traditionally, Systems Engineers follow a document-based approach. The challenge is the inability to adapt to changes and complications with collaboration due to a large number of stakeholders and moving parts in the projects that overall slows down the product development process.
Document Based SE MBSE
Meanwhile, in the diagram above, you can see on the left side the challenge of a traditional approach.
It often involves lots of meetings, sharing of documents, emails with attachments, spreadsheets, pdfs and models “flying” between stakeholders in a document-based systems engineering setting. It can also mean that defects are prone to be discovered near the end of the project.
As we established earlier, late defect discovery costs more. It is far better to become aware of serious issues sooner than later.
Without this kind of approach, you could end up with multiple “sources of truths” for engineers - creating complications such as conflicting data, using inaccurate data, or late-minute correction of source data. This not only damages product quality, but also delays projects as it slows down overall product development.
Finally, with the IoT/Industry 4.0 transition in these industries, there are - and will be -more data. The size of data further creates a burden on an already-complicated situation.
At this triangle of complexity, speed and quality, systems engineers bring the "modeling" to replace documents. Model-Based Systems Engineering (MBSE) handshakes “behaviors”, “requirements” and “structures & relationships” expressed with “models".
INCOSE describes MBSE as “the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.”
The model here corresponds to an abstracted concept such as a phenomenon, relationship, structure, or system which can be represented graphically, mathematically, or physically.
The model facilitates concepts to aid decision-making processes by explaining the behaviors and simulating events. Models are low-fidelity system models, rather than high-fidelity engineering discipline models such as CAD models, Finite Element Models, etc. We will talk about system models in the “MBSE Under the Hood” section.
The other component of MBSE is the structures. Structures are any information (data or metadata) that exhibits a tree-like representation made of semi-static components. For example, the structures can be abstract concepts such as Product Variations and Configurations, or it can be as physical as a Bill-of-materials (BOM) or an assembly of components and moving systems such as an engine.
Behaviors define the relationship between structures or the parts inside the structures. The whole validation process in MBSE is automated by low-fidelity simulations like this one. Those bounding parameters are based on requirements. The diagram on page 7 shows how structures, behaviors, and requirements are connected under MBSE.
In this whitepaper, we have incorporated “people” into the MBSE framework. This is because the projects adopting MBSE are working in a highly multi-disciplinary environment in multi-stakeholder (internal & external) settings. Since we talk about automation and agility, people/user responsibilities, access and identity management, provided functionalities, work scope, and more are embedded parts of the MBSE workflows.
The term, “Model-Based”, varies by its scope and domain. For example, in software engineering, Model-Based ‘Software’ Engineering (MB‘S’E) has its unique features such as automatic code generation for system behavior and testing. MBSE’s auto code generation feature is especially important for highly regulated and safety critical industries such as aerospace industries.
On the other hand, the ‘model-based’ approach can be extended to a Model Based Enterprise (or Engineering) which covers the complete lifecycle of the product, not limited to virtualization but including physical space such as products, manufacturing, and more. MBE will be discussed in the following sections.
From the public sector perspective, US DoD 2018 Digital Engineering Strategy
-
Reduce time to field capabilities (time-to-market)
-
Improve efficiency and reuse across life cycle phases and programs with digital traceability
-
Enable early risk identification (quality) and cost reduction
-
Leverage data and models as an authoritative source of truth
-
The goal of an integrated digital ecosystem where stakeholders can access the data, functions, and elements needed to work in a purely digital manner
MBSE under the Hood: SysML, Digital Threads and Ontology
The main purpose of MBSE is to replace documents with reusable models. Therefore, the models should be system (i.e. discipline, type) and platform (i.e. tools, routines) agnostic. Hence, this creates the complication while connecting these into a common language and schema.
To do that, MBSE follows Unified Modeling Language
(UML)
Harnessing requirements, structures and behaviors with MBSE
The next important concept in MBSE is Ontology. Ontology establishes well-defined domain concepts in terms of the objects, definitions, and relationships inside and among the systems by bringing formal semantics. It is especially the case since these are “systems of systems” where each system is made of multitude of systems.
The meaning of the models, not the details but the emergent properties and metadata, needs to be expressed and understandable without calling their subject domain experts. Hence, ontology is a necessary step towards standardization and enabling data interchange which enables flexibility and interoperability.
This formalized application of modeling and simulation improves system requirements definition, design, verification and validation, operation, and overall performance.
The other concept that enables an MBSE model is called Digital Thread. The “thread” should be a standardized way to “connect” or “plug” the different types of models into a system of systems model. You may notice the overall features of the MBSE forms a “graph” or “network topography” as shown in the diagram above.
It shows a few examples for the impact of an engineering change in an object or a newly added object and relation.
In this model, MBSE can simulate the propagation of changes forwards and backwards as well as perform compatibility analysis based on the requirements sets. Hence, MBSE is a key to the traceability and change management as well as automation to discover defects and issues earlier.
The other feature of the MBSE is to provide Integrated (System) Design Environments (ISDEs) that provides a visual environment for the stakeholders to build, interact and work with system models.
The above discussion and concepts will be critical to see the benefit of cloud and AWS technologies to enable MBSE and MBSE related technologies as discussed in the following sections.
