Why was MBSE invented in the 90s?
Developing hardware has always been a difficult task. Many interdependencies of parts, disciplines, physical and programmatic constraints as well as the interactions between humans working on a project create a level of complexity that is hard to manage.
With the realization that documents are not a sufficiently powerful system of records, it was proposed to store the properties and interdependencies of complex systems in a model representation. This was the core idea of the introduction of Model-Based Systems Engineering (MBSE).
It brought along the two core promises:
- MBSE models will help architects to make complex system tradeoffs
- MBSE models will help engineering teams to collaborate effortlessly
Why has MBSE not been able to keep these promises?
A Model-Based Systems Engineering approach that wants to keep the above promises needs to solve the following core aspects:
- Represent complex system properties in a model
- Make that model a collaborative Single Source of Truth for all stakeholders
The 30-year focus on SysML
The past 30 years have been focussed mostly on the first aspect: SysML was introduced as a language to describe system models. While it is very powerful (and its successor SysML 2.0 allows for even more modelling), it does not at all address the second point. The key inhibitors of adoption of SysML into daily industry processes are:
- SysML has a steep learning curve: engineers have to go through weeks of training to become proficient in this modelling language. It has made SysML tools expert tools who can only be used and understood by a small amount of system architects.
- SysML is purely descriptive: SysML models describe systems; however its major output are diagrams and drawings. While these provide valuable insights in early design trade-offs, they are not useful anymore once a system design has been decided upon: parameters and values that engineers need to calculate with are an afterthought and not at its core.
- SysML has not been built for collaboration: these models are thought of from a single architect perspective. Neither the models, nor the tools around it (e.g. Cameo, Capella, Enterprise Architect, etc.) are made for concurrent engineering work across different disciplines and dozens or hundreds of engineers.
- SysML tools do not integrate to existing workflows and tools; which makes it a tool of single experts and not of entire teams.
How to focus on industry needs instead: Data, Collaboration & Ease of Use? DDSE!
The key promise of MBSE to make engineering teams highly efficient is achieved by a more data-driven approach to MBSE; sometimes called Data Driven Systems Engineering (DDSE).
EIM Systems that implement DDSE methodology focus on the following 3 key aspects:
- The heart of models are its data; not diagrams. Engineering values (such as powerconsumptions, datarates, masses, etc.) with units and physical interdependencies are maintained and their relationship to other entities (requirements, components, etc.) are data-driven wherever possible. Data can be exchanged via APIs with external tools, is versioned and powerful calculation engines make up the core of EIM tools.
- All models are built for collaboration first. Concurrent multi-user access, multi-level permissions inside and across company borders, commenting and review functionalities are as important as the models themselves.
- A tool for every engineer. Instead of being an expert tool requiring weeks of training, EIM systems do the modelling implicitly within an interface that is intuitive to engineers without the need to learn a modelling language first. Initial onboarding takes minutes, while activity specific views (requirements engineering, simulation, verification, etc.) allow domain experts to model details of their domain.
What are the practical implications? MBSE or DDSE?
For early architecture trade-offs expert systems that implement MBSE in SysML diagrams can be very useful. The lead Architect can make high-level trade-offs of design decomposition and general system properties and behaviours; then use the created diagrams as a starting point to derive high-level system requirements.
Once the general system architecture has been selected and entire engineering teams get involved in subsystem design, tradeoffs, calculations, simulations and verification a Data-Driven Systems Engineering approach should be selected in the form of an EIM tool that allows for easy-to-use collaboration on a Single Source of Truth for engineering data across teams and disciplines.