What exactly is MBSE?

I've written about MBSE several times on this blog, and most readers will be aware that this means Model Based Systems Engineering is meant. And many readers certainly have a rough idea of what it means. Nevertheless, there are many ambiguities and misunderstandings. For example, that MBSE is also possible without SysML, or that MBSE involves more than just use cases.

The reason for this article is a lecture on this topic, which I on June 1, 2017 in Cologne at the ASQF expert group meeting will be held. The Arbeitskreis Software-Qualität und -Fortbildung is a non-profit association that has been promoting the development and assurance of software and system quality for 20 years. I invite all readers to attend this free lecture and to forward this e-mail to interested colleagues from the Rhineland.

Update: Download slides of the presentation >>

What is MBSE?

You get a first idea of MBSE when you break down the abbreviation. And we already know what a model is from our childhood, from playing with models of houses, cars, airplanes and other things.

A model is a representation of an aspect of reality that interests us. There are different approaches to classifying models, as can be seen in the following image:

A tangible model allows the form to be analyzed, while a formula is an abstract model that allows the function to be analyzed.

Systems Engineering

The letters "SE" in MBSE stand for Systems Engineering"an interdisciplinary approach to developing and implementing complex technical systems in large projects" - that's what this blog is all about. What "based" means can be seen from the recently published article on the Difference between MBSE and MDSE out.

Our own modeling language

The scope of systems engineering is usually associated with the V-model which comprises many activities. The use of MBSE is first shown through the modeling of requirements. Requirements are classically recorded in text form, but can also be modeled. Although there are existing languages for requirements modeling, in this presentation we will develop our own modeling language. This is not as complicated as it sounds.

The development of the modeling language begins with the introduction of a type, for example "Stakeholder Requirement". This type also requires a few attributes, for example name, description, status, etc. This is actually enough to "model" the first requirements - i.e. to record the requirements in a table with the columns listed. Even at this early stage, it is possible to check the requirements: For example, it could be required that each requirement has a name.

Other types can be introduced in the same way, for example "Functional Requirement". These also have attributes that may differ from those of the "stakeholder requirements".

In order to really model, the types must be placed in relation to each other: A (likewise typed) relationship between stakeholder requirements and functional requirements could be made possible.

Let the model work

Used correctly, the newly invented modeling language can already generate considerable added value:

• Completeness criteria can be created and automatically checked. For example: Is there at least one functional requirement for each stakeholder requirement?
• Dealing with changes: If an element changes, the model can be used to find out whether other elements may need to be improved (via the relationships).
• Support of a workflow: The status of an element can be tracked (e.g. "In progress", "Finished"). When a "finished" element is being edited, a good tool can set the status to "In progress".
• Views of the model: Various views of a model can be created. Based on the status just presented, the progress (percentage of finished elements) could be displayed as part of a dashboard.

System modeling

In order to demonstrate more sophisticated modeling, we will show how systems are modeled. This can also be done in tabular form, but graphical modeling has proven itself in practice, starting with very casual "boxes and lines" that show the systems and their connections.

Unfortunately, informal modeling can easily lead to misunderstandings if the boxes and lines are not interpreted correctly. It is therefore advisable to use existing modeling languages in which the meaning of the elements is clearly defined. UML and the related SysML, which is a modification of UML for system modeling, are well known.

When modeling a system, it is important not to confuse the image with the model. For one thing, the image is just one view of the model, out of many possible views. In addition, only the smallest models show all elements in the diagram. It is common to include only parts of the model on the diagram for different purposes. And finally, there is often a lot of information stored in the model that is not included in the diagram, for example to avoid overloading it.

Encapsulation is an important concept in system modeling: a modeling language such as SysML requires the system boundaries to be defined via clearly defined interfaces. Ideally, it is sufficient to understand the behavior of the system interfaces in order to understand a system. How it is implemented is of secondary importance. For example, the user of a battery is not interested in whether it was implemented using zinc-carbon, nickel-metal hydride or another technology. They are only interested in whether the battery is compatible with the device, i.e. whether it fits the interface - both physically (e.g. size) and in terms of behavior (e.g. capacity).

And now all together

These were just two examples of modeling in systems engineering. And that is already MBSE, at least in its simplest form. But of course MBSE can be intensified. As already mentioned, systems engineering encompasses all activities of the V-model. Here we have only shown how modeling can be carried out in two areas. This can be extended, and more importantly, models can be interlinked.

It is tempting to believe that one huge model can cover a large part of the V-model. Some tool manufacturers promise such all-encompassing solutions, but you should be careful: Firstly, you can quickly become dependent on one manufacturer, and secondly, it is questionable whether all aspects are covered satisfactorily. Instead, it makes sense to pay attention to the integrability of the various models. Open standards or interfaces help here.

MBSE cannot be implemented overnight. A gradual introduction usually makes sense and, as shown here, even selective modeling can bring tangible added value. The SYSMOD Intensity Model shows what a step-by-step introduction can look like.

Until June 1 in Cologne

With my Lecture in Cologne I will be presenting the topics presented here in short form with more detail. I look forward to meeting one or two SE Trends readers there.

Images: BigStock and Wikimedia / CC BY-SA 2.0