Rezension: A Primer for Model-Based Systems Engineering (MBSE)

Zusammenfassung: Wer einen SysML-Modellierungsleitfaden erwartet, ist mit diesem Buch falsch beraten. Statt dessen geht es im MBSE-Primer um die Grundprinzipien der modellbasierten Systementwicklung. Das Buch erwartet keine besonderen Vorkenntnisse. Statt dessen wird hier anhand eines konkreten Beispiels gezeigt, wie sich die Grundprinzipien in der Realität manifestieren. Dazu wird schrittweise erklärt, was Systeme, Systementwicklung, Modellierung, und schließlich MBSE sind. Die Einsichten sind oft profund. Es lohnt sich, dieses Elementarbuch alle paar Jahre erneut zu lesen, um das Gesamtbild nicht aus den Augen zu verlieren.

Zielgruppe: Erfahrene Ingenieure und Führungskräfte, die die Prinzipien der modellbasierten Systementwicklung verstehen wollen. Für Berufseinsteiger eher ungeeignet.

Lesen Sie weiter um zu erfahren, wie viele Sterne ich dem Buch gegeben habe.

Bewertung: ★★★★★  Dieses kleine (gut 100 Seiten lange) Buch ist schnell gelesen. Es erfordert keine Vorkenntnisse, da es sich mit den Prinzipien von MBSE auseinandersetzt. Auch für erfahrene Systemingenieure sind viele spannende Einsichten dabei. Die einzige Gefahr ist, dass der Leser mit der falschen Erwartung an den MBSE-Primer geht und einen Modellierungsleitfaden erwartet.

Autoren: David Long, Zane Scott

Erwerben: Das Buch gibt es kostenlos als eBook (Registrierung erforderlich) oder Papier unter www.vitechcorp.com/mbse-primer/

Details: Das Buch bietet genau das, was der Titel sagt: Es ist eine Einführung in MBSE, und daraus ergibt sich auch gleich die Struktur: Es wird zunächst erklärt, was ein System ist. Das ist die Voraussetzung, um Systems Engineering zu verstehen. Nachdem dann auch noch erklärt wurde, was ein Modell ist, kann Model-Based Systems Engineering erläutert werden. Soweit erst einmal keine Überraschung.

Das Buch wird von einem passenden Fallbeispiel begleitet: Eine Geo-Bibliothek, die für Kunden über ein Satelliten-Netzwerk Bilder beschafft. Ein einfacher Anwendungsfall, der aber eine enorme Komplexität aufweist.

Systeme

Schon lange habe ich auf meiner Todo-Liste, ein Buch von Russell Ackoff zu lesen. Ackoff ist der Begründer der Idee des Systems Thinking. System Thinking fängt da an, wo Enlightenment (Erkenntnistheorie) aufhört. Im Zeitalter der Erkenntnis wurde Verständnis gesucht, indem Dinge in ihre Einzelteile unterteilt werden, um das Gesamte zu Verstehen. Aber genau das funktioniert bei Systemen ja gerade nicht: Das Ganze ist mehr als die Summe der Teile. Das ist ein Paradigmenwechsel, und das wird in diesem Buch noch einmal klar betont.

The critical idea here is that we begin not from a decomposition of the system into its parts but from the point of view of the system in its context. Twittern

Und konzeptionell besteht ein System nur aus wenigen Entitäten: Es gibt Entitäten (Entities), Eigenschaften (Attributes) und Beziehungen (Relationships). Ob es sich bei den Entitäten um Atome oder Motoren handelt, ist unerheblich.

Systems Engineering

Der Verantwortungsbereich des Systemingenieurs ist klar abgesteckt: Er bezieht sich auf das Gesamtsystem und die externen Schnittstellen. Der Systemingenieur muss sicherstellen, dass die Anforderungen der Stakeholder verstanden sind und korrekt in Funktionen umgesetzt werden, die über die Komponenten des Systems realisiert werden. Das ist sowohl ein technischer als auch ein Management-Prozess.

Im Systems Engineering begegnet man nur drei verschiedenen Grundproblemen: (1) Neusysteme, (2) Verbesserungen und (3) Nachbauten. Leider begegnen wir in der Ausbildung und Lehrbüchern oft nur dem ersten Grundproblem, obwohl die anderen beiden in der Praxis eine große, oft sogar größere Rolle spielen.

Im Systems Engineering begegnet man nur drei verschiedenen Grundproblemen: Neusysteme, Verbesserungen und Nachbauten. Leider werden die letzten zwei in der Lehre oft vernachlässigt. Twittern

Weiterhin wird in der SE-Lehre oft vernachlässigt, dass man es nicht nur mit einem, sondern drei Systemen zu tun hat: Neben dem zu entwickelnden System gibt es auch noch den Systemkontext, der ein eigenes System darstellt, und das System, das zur Entwicklung benutzt wird. Das letztere ist insofern wichtig, da es maßgeblich die Qualität des zu entwickelnden Systems beeinflusst. Dementsprechend detailliert gehen die Autoren auch auf dieses Thema ein.

Der Entwicklungsprozess wird in vier Domänen unterteilt, die dem Leser sicher bekannt sind: Anforderungen, Verhalten (Funktionalität), Architektur und Verifikation und Validierung (V&V). Diese werden teilweise anhand des Beispielsystems vermittelt.

Zuletzt wird noch auf das wichtige Thema Kommunikation eingegangen.

Modelle

Modelle können das gesamte Spektrum von Form bis Funktion füllen – also bspw. vom Holzmodell bis zur mathematischen Formel. Auch in diesem Kapitel wird der Diskurs wieder von Grundprinzipien geleitet. So besteht ein Modell aus vier Elementen:

• Sprache – Jedes Modell muss eine möglichst klare und präzise Sprache haben.
• Struktur – Die Elemente des Modells müssen zueinander in Beziehung gesetzt werden, was ohne Struktur schwer möglich wäre.
• Argumentation – Ein Modell sollte mit einer klaren Zielsetzung erstellt werden, und dazu muss das Modell bezüglich der Zielsetzung argumentieren ermöglichen.
• Präsentation – Es reicht nicht, dass die Argumentationsgrundlage irgendwo im Modell versteckt ist. Es muss auch möglich sein, in überzeugender Art und Weise zu präsentieren.

Diese vier Elemente werden in den folgenden Unterkapiteln im Detail und mit Beispielen detailliert beschrieben.

Wichtig ist es, das Modell nicht mit einem Bild, oder einer Sicht auf das Modell zu verwechseln. Ebenfalls kritisch ist der Aspekt der Sprache. Dabei ist nicht zu vergessen, dass Systems Engineering ePräsentationine übergreifende Aktivität ist und dementsprechend von Menschen aus unterschiedlichen Disziplinen verstanden werden muss.

Die Notwendigkeit einer klaren, eindeutigen Systemdefinitionssprache wird durch das Vorhandensein einer Vielzahl von Fachexperten, die am Systemdesign mitwirken, noch verstärkt. Twittern

Weiterhin kann ein Modell nicht so ohne weiteres auseinandergenommen werden, ohne dabei essentielle Eigenschaften zu verlieren. Hier findet sich das Systemdenken wieder: Ein System ist mehr als seine Einzelteile. Das trifft auch auf das Entwicklungssystem zu.

Etwas skeptisch bin ich bei der Aussage, dass Sprachen für Verhalten grafisch sein müssen (Seite 39, Language of Behavior). Hier würde mich sehr die Meinung meiner Leser interessieren. Fairerweise wird sogar eine N²-Matrix als grafisch klassifiziert, was die Aussage etwas relativiert. Hingegen stimme ich voll und ganz zu, dass die Sprache Black-Box-Denken ermöglichen muss. Dabei darf allerdings das Verhalten des in der Black-Box gekapselten Untersystems nicht verlorengehen.

In diesem Zusammenhang ist auch die Trennung von logischem und physikalischem Modell wichtig, denn während ein physikalisches System einem starken Wandel unterliegt (durch technologischen Fortschritt), bleibt das logische System, bzw. das Verhalten, relativ konstant. Ein Beispiel ist der Wandel von Bildschirmröhren zum LCD-Bildschirmen – die Funktion ist unverändert, die zugrundeliegende Technologie hat sich drastisch gewandelt. Diese Konzepte werden praktisch anhand konkreter Modellierungssprachen wie FFBDs, Aktivitäts- und Sequenzdiagramme erläutert.

Beim Thema Argumentation kommt unweigerlich Traceability ins Spiel, die als klarer Vorteil dem dokumentenbasierten Arbeiten dargestellt wird: Die Tatsache, dass sich in einem Modell Beziehungen in jeder Richtung navigieren lassen, ermöglicht die Navigation nicht nur nach unten, sondern auch nach oben (Wie sind wir zu dieser Entscheidung gekommen?) oder horizontal (Wo bestehen Wechselwirkungen?). Auch hier kristallisiert sich wieder das Systemdenken: Das Ganze ist mehr als die Teile.

MBSE

Auf einen Satz kondensiert bezeichnen die Autoren MBSE im Primer als Denkprozess: Es wird ein Rahmen gesetzt, der von Anfang an Effektivität und Konsistenz sicherstellt, aber gleichzeitig genug Freiraum für die konkrete Situation lässt. Konkret werden dei folgenden Vorteile Aufgezählt:

• Es ist möglich, das Gesamtproblem zu betrachten
• Problem und Lösung werden mit einer konsistenten Sprache beschrieben
• Es ergibt sich ein kohärentes Design
• Die Umsetzung der Systemanforderungen und deren Vollständigkeit kann nachgewiesen werden

An dieser Stelle zeigt sich zum ersten Mal, dass der MBSE-Primer ein kommerzielles Unternehmen (Vitech Corporation) unterstützt (abgesehen von dem großen Logo auf dem Cover). Denn hier wird der von den Autoren entwickelte und von Vitech kommerzialisierte Ansatz STRATA™ erwähnt. Der Name wurde von „Strategic Layers“ abgeleitet, da das Problem über zunehmend detaillierte Lagen strategisch auf die Lösung konvergiert.

Traditionell wird jede Domäne der Systementwicklung (Anforderungen, Funktionalität, Architektur, V&V) in sich abgeschlossen, bis zur Lösung. Bei STRATA hingegen sind die Lagen in sich abgeschlossen. Der Vorteil hier ist es, dass in einzelnen Lagen iterativ gearbeitet werden kann, ohne die Gesamtentwicklung zu stören. Ein weiterer Vorteil ist, dass der Gesamtkontext nie aus den Augen verloren wird.

Der Ansatz, Probleme in Lagen (Layers) zu lösen, ist der Kern von MBSE Twittern

Um zu zeigen, dass MBSE ein sinnvoller Lösungsansatz ist, beginnen die Autoren des Primer – wie kann es auch anders sein – bei den Anforderungen, also den Anforderungen an den Entwicklungsprozess. Sie stellen vier Schlüsselanforderungen auf und zeigen, dass MBSE diese gut umsetzen:

• Der Prozess muss zuverlässig zur Entwicklung erfolgreicher Systeme führen
• Der Prozess muss die Komplexität des Systems managen können
• Der Prozess muss zu einer effektiven Lösung für einen broad range von Kundenbedürfnissen führen
• Der Prozess muss alle Problemklassen berückslichtigen (Neuentwicklung, Verbesserung, Reverse-Engineering)

Anhand von STRATA wird gezeigt, wie diese Anforderungen von einer MBSE-Methode realisiert werden. Ich sehe aber kein Grundsätzliches Problem, diese auch mit anderen MBSE-Methoden umzusetzen, wenn sorgfältig gearbeitet wird. Allerdings behaupten die Autoren, dass viele SE-Prozesse – im Gegensatz zu STRATA – nicht gut mit Wechselwirkungen und Konsistenz umgehen können. Wie weit dies auch auf andere MBSE-Ansätze zutrifft, sei dahingestellt.

Um das bisher Beschriebene zu konkretisieren, werden nun drei der Ebenen oder Lagen der Lösung, die sich in STRATA manifestiert, hergeleitet. Dies wird ausführlich für die erste Lage beschrieben, die aus Anforderungen, Funktionalität und Architektur besteht. In der zweiten Ebene wird Verhalten (Thread Development) im Detail untersucht. Das ist insbesondere interessant, weil hier anschaulich gezeigt wird, wie mit der sich entwickelnden Komplexität umgegangen werden kann. Dabei unterscheiden die Autoren zwischen Verhalten und Funktionen. Hilfreich ist es, das Verhalten zu vereinheitlichen, um eine Redundanz bei den Funktionen zu vermeiden.

Im Abschluss beschreibt der MBSE-Primer allgemein, wie sich das Lagen-Prinzip in den folgenden Ebenen fortpflanzt.

Verification & Validation

Im Gleichschritt mit dem Lagen-Ansatz wird auch bei V&V-Aktivitäten vorgegangen, mit mindestens einem Design-Review pro Lage. Im Gegensatz zu traditionellem Vorgehen können beim modellbasierten Ansatz die V&V-Aktivitäten auch formalisiert werden. Dieses Kapitel ist recht kurz gehalten. Das ist einserseits verständlich, aber dennoch schade, da auch in der Praxis V&V nicht die Aufmerksamkeit gegeben wird, die sie verdienen (und die sich auch auszahlt).

Fazit

Der MBSE-Primer füllt für mich einen wichtigen Bedarf im Markt, für den es meiner Meinung nach noch nicht allzu viel Literatur gibt: Der technische fundierte Business Case für MBSE, geschrieben für erfahrene Systems Engineers und Entscheider. Das Buch ist technisch genug, um die Argumente überzeugend zu kommunizieren, setzt aber dennoch wenig Grundkenntnisse voraus. Damit hat es das Potential, ein zeitloser Klassiker zu werden.

Kudos, auch an die Autoren, deren kommerzielle Interessen aus diesem Buch herauszuhalten. Die Autoren machen kein Geheimnis aus Ihrer Rolle in der Vitech Corporation. Inhaltlich ist es a keiner Stelle Marketing- oder Vertriebsmaterial. Kompliment!

Bild: Lance Asper / Unsplash