Was ist eigentlich MBSE?

In diesem Blog habe ich schon mehrmals über MBSE geschrieben, und den meisten Lesern ist sicher klar, dass damit Model Based Systems Engineering gemeint ist. Und viele Leser haben sicher auch eine ungefähre Vorstellung davon. Dennoch gibt es viele Unklarheiten und Missverständnisse. Zum Beispiel, dass MBSE auch ohne SysML möglich ist, oder dass zu MBSE mehr als nur Anwendungsfälle (Use Cases) gehören.

Der Anlass für diesen Artikel ist ein Vortrag zu diesem Thema, den ich am 1. Juni 2017 in Köln beim ASQF-Fachgruppentreffen halten werden. Der Arbeitskreis Software-Qualität und -Fortbildung ist ein gemeinnütziger Verein, der seit 20 Jahren die Entwicklung und Sicherung von Software- bzw. System-Qualität und fördert. Ich lade alle Leser ein, diesen kostenlosen Vortrag zu besuchen und diese E-Mail an interessierte Kollegen aus dem Rheinland weiterzuleiten.

Update: Foliensatz des Vortrags herunterladen >>

Was ist MBSE?

Eine erste Ahnung von MBSE bekommt man, wenn man die Abkürzung auseinandernimmt. Und was ein Modell ist, wissen wir schon aus unserer Kindheit, vom Spielen mit Modellen von Häusern, Autos, Flugzeugen und anderem.

Ein Modell ist die Abbildung eines Aspekts der Wirklichkeit, der uns interessiert. Dabei gibt es verschiedene Ansätze, Modelle zu klassifizieren, wie im folgenden Bild zu sehen ist:

Ein Modell zum Anfassen ermöglicht die Analyse der Form, während eine Formel ein abstraktes Modell ist, welches die Analyse der Funktion ermöglicht.

Systems Engineering

Die Buchstaben „SE“ in MBSE stehen für Systems Engineering, „ein interdisziplinärer Ansatz, um komplexe technische Systeme in großen Projekten zu entwickeln und zu realisieren“ – darum geht es in diesem Blog. Was „based“ bedeutet, das geht unter anderem aus dem kürzlich veröffentlichten Artikel über den Unterschied zwischen MBSE und MDSE hervor.

Eine eigene Modellierungssprache

Die Umfang von Systems Engineering wird in der Regel mit dem V-Modell illustriert, welches viele Aktivitäten umfasst. Der Einsatz von MBSE wird zunächst über die Modellierungen von Anforderungen gezeigt. Anforderungen werden klassisch textuell festgehalten, können aber auch modelliert werden. Es gibt zwar bestehende Sprachen für die Anforderungsmodellierung; in diesem Vortrag wird jedoch eine eigene Modellierungssprache entwickelt. Das ist gar nicht so kompliziert, wie es sich anhört.

Die Entwicklung der Modellierungssprache beginnt mit der Einführung eines Typen, zum Beispiel „Stakeholder Requirement“. Weiterhin benötigt dieser Typ ein paar Attribute, zum Beispiel Name, Beschreibung, Status, etc. Das reicht eigentlich schon, um die ersten Anforderungen zu „modellieren“ – also tabellarisch die Anforderungen mit den aufgeführten Spalten zu erfassen. Schon in diesem frühen Stadium ist es möglich, die Anforderungen zu überprüfen: Es könnte beispielsweise verlangt werden, dass jede Anforderung einen Namen hat.

Auf die selbe Weise können weitere Typen eingeführt werden, zum Beispiel „Functional Requirement“. Diese haben ebenfalls Attribute, die sich von denen der „Stakeholder Requirements“ unterscheiden können.

Um nun wirklich zu modellieren, müssen die Typen in Beziehung zueinander gestellt werden: Es könnte eine (ebenfalls typisierte) Beziehung zwischen Stakeholder Requirements und Functional Requirements ermöglicht werden.

Das Modell arbeiten lassen

Richtig eingesetzt, kann die eben erfundene Modellierungssprache bereits einen erheblichen Mehrwert generieren:

• Es können Vollständigkeitskriterien erstellt und automatisch überprüft werden. Zum Beispiel: Gibt es für jedes Stakeholder Requirement mindestens eine Funktionale Anforderung?
• Umgang mit Änderungen: Wenn sich ein Element ändert, dann kann über das Modell herausgefunden werden, ob andere Elemente möglicherweise nachgebessert werden müssen (über die Beziehungen).
• Unterstützung eines Arbeitsflusses: Der Status eines Elements kann verfolgt werden (bspw. „In Arbeit“, „Fertig“). Wenn ein „fertiges“ Element bearbeitet wird, kann ein gutes Werkzeug den Status auf „In Arbeit“ setzen.
• Sichten auf das Modell: Von einem Modell können verschiedene Sichten erstellt werden. Basierend auf dem eben vorgestellten Status könnte der Fortschritt (Prozent fertiger Elemente) als Teil eines Dashboards dargestellt werden.

Systemmodellierung

Um auch etwas anspruchsvollere Modellierung zu zeigen, soll gezeigt werden, wie Systeme modelliert werden. Das geht zwar auch tabellarisch, aber in der Praxis hat sich ein grafische Modellierung bewährt, zunächst einmal ganz salopp „Kästen und Linien“, die die Systeme und deren Verbindungen zeigen.

Leider führt eine informelle Modellierung leicht zu Missverständnissen, wenn die Kästen und Linien nicht richtig interpretiert werden. Daher ist es hier ratsam, auf bestehende Modellierungssprachen zurückzugreifen, bei denen die Bedeutung der Elemente klar definiert ist. Bekannt ist die UML, sowie die verwandte SysML, die eine Abwandung der UML für die Systemmodellierung darstellt.

Wichtig bei der Systemmodellierung ist es, nicht das Bild mit dem Modell zu verwechseln. Zum einen ist das Bild lediglich eine Sicht auf das Modell, von vielen möglichen. Außerdem werden nur bei kleinsten Modellen alle Elemente im Diagramm dargestellt. Es ist üblich, für unterschiedliche Zwecke nur Teile des Modells auf das Diagramm zu nehmen. Und zuletzt sind oft im Modell viele Informationen hinterlegt, die nicht ins Diagramm aufgenommen werden, zum Beispiel um es nicht zu überladen.

Ein wichtiges Konzept bei der Systemmodellierung ist die Kapselung: Eine Modellierungssprache wie SysML erfordert das Festlegen der Systemgrenzen über klar definierte Schnittstellen. Im Idealfall reicht es, das Verhalten der Systemschnittstellen zu verstehen, um ein System zu verstehen. Wie es umgesetzt ist, ist zweitrangig. Zum Beispiel interessiert den Nutzer einer Batterie nicht, ob diese nun über Zink-Kohle, Nickel-Metallhydrid oder eine andere Technologie realisiert wurde. Es interessiert nur, ob die Batterie mit dem Gerät kompatibel ist, also zu der Schnittstelle passt – sowohl physikalisch (z.B. Größe), als auch vom Verhalten (z.B. Kapazität).

Und nun alles Zusammen

Dies waren nur zwei Beispiele für Modellierung im Systems Engineering. Und das ist auch schon MBSE, jedenfalls in der einfachsten Form. Aber natürlich kann MBSE noch intensiviert werden. Wie bereits erwähnt, umfasst Systems Engineering alle Aktivitäten des V-Modells. Hier wurde nur gezeigt, wie in zwei Bereichen modelliert werden kann. Das kann ausgeweitet werden, und noch wichtiger, Modelle können mit einander verzahnt werden.

Es ist verführerisch zu glauben, dass ein riesiges Modell einen großen Teil des V-Modells abdecken kann. Manche Werkzeughersteller versprechen solche allumfassenden Lösungen, aber da sollte man vorsichtig sein: Zum einen kann man sich da schnell in die Abhängigkeit von einem Hersteller zu geben, zum anderen ist es fraglich, ob alle Aspekte auch zufriedenstellend abgedeckt werden. Statt dessen ist es sinnvoll, auf die Integrierbarkeit der verschiedenen Modelle zu achten. Offene Standards oder Schnittstellen helfen dabei.

MBSE kann nicht von heute auf morgen umgesetzt werden. Eine schrittweise Einführung ist in der Regel sinnvoll, und wie hier gezeigt wurde, kann auch punktuelles Modellieren einen spürbaren Mehrwert bringen. Das SYSMOD Intensity Model zeigt, wie eine schrittweise Einführung aussehen kann.

Bis zum 1. Juni in Köln

Bei meinem Vortrag in Köln werde ich die hier in Kurzform vorgestellten Themen mit mehr Detail vorstellen. Ich freue mich darauf, den einen oder anderen Leser von SE-Trends dort zu treffen.

Bilder: BigStock und Wikimedia / CC BY-SA 2.0