3 common myths about Model-Based Systems Engineering (MBSE)
I remember a client interaction where I finally asked the dreaded question- “have you considered MBSE as a methodology for overall systems engineering in your organization?”. The answer was not so memorable. I have heard this statement in one form or another in a lot of meetings. “We would rather use documents than train people on MBSE and the associated specialized tools”.
In January 2020, NASA reported that MBSE, “has been increasingly embraced by both industry and government as a means to keep track of system complexity”. This means that a lot of organizations are either in there nascent stages of adoption of MBSE or are just starting out.
MBSE brings together the three pillars: Systems Model, Systems Engineering & Systems Thinking
With the advent of complex and connected systems, it becomes important that a digitally driven traceable methodology be followed across disciplines like systems, software, hardware, safety, security, etc.
In this article I review the top 3 most common myths about adopting MBSE:
1. MBSE is just about 1D modeling of the systems and just a replacement of word/ visio/ lucidchart drawings.
“Model-based systems engineering (MBSE) is 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.”
As opposed to Document centric engineering, MBSE focuses on the models and puts them at the center of system design. As organizations are rapidly progressing towards end-to-end digital transformation, MBSE provides major advantages over the document-centric approach. MBSE allows different authors to capture the system’s design from various stakeholder views, such as system behavior, software, hardware, safety, security, or other disciplines. This approach allows system engineers to create a single source of truth for the system in which discipline-specific views of the system are created using the same model elements. Use of model elements allows to create consistent hierarchy of models where stakeholders can apply specific constraints and perform key MBSE activities like requirement traceability & verification, trade off analysis, system analysis, parameterization, simulation etc.
2. Implementing MBSE is a challenge!
Adopting MBSE and investing in a new workflow would mean that an organization would need to invest in talent, tools, new languages and methodologies. Instead of a complete overhaul of the process, the adoption can be overtaken in a phased-goal oriented approach. For instance, if traceability is something that the organization is struggling with, organizing and connecting requirements at different levels can be a good starting point. A good second step is to understand and map the requirements to appropriate architectural models elements (Software architecture, Electrical components, Mechanical components, etc).
Adopting MBSE doesn't have to be a challenge. Having the right expertise to drive adoption and tools that ease the adoption is the key.
3. MBSE is all about SysML!
SysML without a doubt is a language which facilitates collaboration, systems thinking, early validation of concepts, parameterization, configuration management, safety analysis, cybersecurity analysis and most importantly promotes a single source of truth. However, SysML is commonly replaced by domain specific languages (DSL) at the detailed design level like CAD for mechanical design, software development languages for software, hardware description languages (HDL) like Verilog/ VHDL for semiconductor design, etc. This means that there can be a potential disconnect between information captured at the concept phase and its flow to the implementation level if the aspect of tracebility is not paid careful attention at this level. The common solution to this issue is to use an effective ALM/ PLM solution which provides domain independent tracebility and smooth linkage between different DSLs.
The author would love to hear any feedback :)
References:
