Das Systemmodell – der Kern von MBSE

Das Systemmodell im Rahmen des Model-Based Systems Engineering (MBSE) bietet eine Reihe von Vorteilen. Die wichtigsten sind:

• Weniger Kosten. Fehler lassen sich bereits in früheren Entwicklungsphasen und nicht erst in der Integrations-, Verifikations- und Validierungsphase finden.
• Bessere Zusammenarbeit. Alle Systeminformationen sind im Systemmodell enthalten. Damit haben alle an der Entwicklung Beteiligten stets den gleichen Informationsstand.
• Bessere Übersicht. Alle Architektureinheiten sind im Systemmodell nach ontologischen Regeln aufeinander bezogen. Damit sind die Zusammenhänge zwischen den unterschiedlichen Gestaltungselementen für alle Entwickler ersichtlich.

Dokumentenbasierter oder modellbasierter Ansatz

Im Systems Engineering spricht man von einem modellbasierten Ansatz und einem dokumentenbasierten Ansatz. Während der dokumentenbasierte Ansatz aus vielen Dokumenten besteht, die miteinander nur mit großem Aufwand kompatibel gehalten werden können, behilft sich der modellbasierte Ansatz mit einem Systemmodell, das diese Vielfalt durch ein vernetztes geregeltes Konstrukt verwaltet. Die Vorteile des Systemmodells lassen sich aber nur unter folgenden Voraussetzungen nutzen:

1. mit einer definierten Modellierungssprache
2. mit einer bestimmten Modellierungsmethode
3. und mit einem dafür entwickelten IT-Tool

Dies sind drei für die Systemarchitekten und für alle, die mit der Systemarchitektur arbeiten, nicht leicht zu nehmende Hürden.

Das MBSE und das Systemmodell

Ein Modell ist eine Abstraktion der Realität, welches wir für einen bestimmten Zweck definieren. Nur ein Teil der Realität wird in einem Modell wahrgenommen, den wir für den Zweck des Modells brauchen. In einem CAD-Modell werden geometrische Eigenschaften eines Systems sichtbar gemacht. In einem CAE-Modell werden Materialeigenschaften ins Spiel gebracht, um das dynamische Verhalten eines Systems zu modellieren. In einem Kostenmodell werden Produkt und Projektkosten modelliert.

Welchem Ziel folgt ein Systemmodell und welcher Teil der Realität spielt darin eine Rolle? Nach der Definition des MBSE:

“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.” SE Vision 2020. In: INCOSE. INCOSE - International Council on Systems Engineering, 23. Februar 2009

Demzufolge finden sich eine Reihe an Modellelementen in einem Systemmodell: Anforderungen, Architektureinheiten, Parameter für die Systemanalyse und Testfälle für die Verifikation und Validierung des Systems.

Diese Modellelemente werden miteinander nach bestimmten Beziehungsarten verknüpft. U. a.:

• Anforderungen werden von Architektureinheiten erfüllt.
• Anforderungen werden von Verifikations- und Validationselementen verifiziert bzw. validiert.
• Parameter der Systemanalyse werden Architekturelementen zugeordnet.

Bezüglich Anforderungen kann man ein Systemmodell als eine nach der Topologie eines Systems gestaltete Datenablage für Anforderungen verstehen. Jede Anforderung ist der Architektureinheit oder den Architektureinheiten zugeordnet, die die Anforderung erfüllen sollen. Die Anforderungen an eine Architektureinheit (z. B. Systemelement, Schnittstelle, Verhalten, fließendes Element usw.) werden während ihrer Entstehung und Gestaltung definiert, und zwar so, dass das Zusammenspiel aller Architektureinheiten eines Systems die Quellenanforderungen erfüllt. Die Anforderungen an die Architektureinheiten leiten sich auf diese Weise von den Quellanforderungen ab. Eine abgeleitete Anforderung folgt nachstehender Rhetorik: „Damit das Zielsystem die Quellanforderung ‘Q‘ erfüllt, muss die Architektureinheit ‘A‘ dieses und jenes tun“. Deshalb kann eine abgeleitete Anforderung nicht allein stehen, sondern immer in Begleitung der Quellanforderung, von der sie sich abgeleitet hat.

Bezüglich der Parameter für die Systemanalyse kann man ein Systemmodell auch als eine nach der Topologie eines Systems gestaltete Sammlung von Parametern verstehen. Die Parameter stehen miteinander in von mathematischen Gesetzen bestimmten Beziehungen. Änderungen in einem Parameter verursachen eine Kette von Änderungen an anderen Parametern des Systems. Damit lassen sich MODA (Multiple Objective Decision Analysis) durchführen wie z. B. Trade-off Analysis. Da die mathematischen Gesetze oft mittels spezialisierter Simulationssysteme berechnet werden, wird die Integration von Simulationssystemen in ein Systemmodell eine zunehmend wichtige Rolle spielen.

Zuletzt stellt das Systemmodell auch eine nach der Topologie des Systems gestaltete Datenablage für die Verifizierung und Validierung eines Systems dar, indem Testfälle definiert werden, die die Systemanforderungen verifizieren und die Stakeholder-Anforderungen validieren. Die Testfälle werden die Erfüllungsbeziehung zwischen Anforderungen und Architektureinheiten als wahr oder falsch nachweisen. Dafür definiert ein Testfall die Eingaben (Stimuli), Umstände des Systems und erwartete Ergebnisse, um die Erfüllung einer oder mehrerer Anforderungen nachzuweisen. Da die Anforderungen den Architektureinheiten zugeordnet sind, sind die Testfälle indirekt auch den Architektureinheiten zugeordnet.

Auf diese Weise stellt das Systemmodell eine Datenstruktur dar, welche sich für die Verwaltung des Systems während seines gesamten Lebenszyklus optimal eignet. Mithilfe des Systemmodells kann man Snapshots der Anforderungen, der Systemarchitektur, der Analyse und der Testfälle aufnehmen: die Referenzkonfigurationen (Baselines). Die Referenzkonfigurationen bestehen aus zu einem bestimmten Zeitpunkt miteinander kompatiblen Konfigurationseinheiten. Die Konfigurationseinheiten sind nichts anderes als gebündelte und miteinander verknüpfte Anforderungen, Architektureinheiten, Analyse und Testfälle. Die Referenzkonfigurationen definieren die unterschiedlichen möglichen Konfigurationen oder Zusammensetzungen der Konfigurationseinheiten, die das Zielsystem aufbauen samt entsprechenden Anforderungen, Analysen und Testfällen.  Dazu können die Referenzkonfigurationen während der Gestaltung der Systemarchitektur für die Untersuchung von alternativen Systemlösungen nicht nur behilflich, sondern aus praktischen Gründen sogar notwendig sein.

Architektursichten

Das Systemmodell besteht also aus miteinander verknüpften Anforderungen, Architektureinheiten, Analyseszenarien und Testfällen. Dies führt zu einer, je nach Komplexität und Größe eines Systems, wachsenden und schwer zu überblickenden Anzahl an Elementen. Diese Komplexität ist mithilfe der Architektursichten zu bewältigen. Die Architektursichten ermöglichen dem Betrachter, sich auf seine Belange zu konzentrieren und alles andere auszublenden. Eine Architektursicht betrachtet eine Untermenge der Elemente eines Systemmodells. Eine wichtige Aufgabe eines Architekten ist das Erkennen der Belange jedes Stakeholders und das Herausstellen der für jeden Belang passenden Architektursicht.

• Eine Architektursicht kann auf das ganze System einen Blick werfen: Man kann nur die Struktur des Systems betrachten oder nur das Verhalten, man kann einen Anforderungsbaum aufbauen oder bestimmte Analysen darstellen.
• Man kann auch holistisch alle diese Aspekte nur für einen Teil des Systems betrachten.
• Man kann eine bestimmte Funktionalität eines Systems betrachten, indem man die betroffenen Systemelemente, Anforderungen, Analysen und Testfälle in einer Architektursicht betrachtet.
• Es können auch bestimmte fachliche Domänen einzeln in einer Architektursicht betrachtet werden.

Eine für jedes Projekt passende Auswahl an Architektursichten ist eine Voraussetzung für die Realisierung von erfolgreichen Systemen.

Die Struktur im Systemmodell

Systemelemente und Verbindungen werden prominent im Systemmodell dargestellt, denn Systeme sind

„[...] ein Verbund von interagierenden Elementen, der organisiert ist, um ein oder mehrere vorgegebene Ziele zu erreichen“ (ISO/IEC/IEEE 15288), GfSE - INCOSE Systems Engineering Handbuch

Die wesentlichen strukturellen Elemente eines Systems werden im Systemmodell durch Systemelemente, Schnittstellen, Verbindungen, fließende Elemente und deren Beziehungen untereinander dargestellt und verwaltet. Man unterscheidet zwischen zwei Arten von Systemelementen: den Definitionselementen und den Nutzungselementen. Mit Definitionselementen wird der Zusammenhang und der Aufbau der unterschiedlichen strukturellen Elemente der Architektur spezifiziert. Mit Nutzungselementen wird das System, basierend auf den Definitionselementen, zusammengebaut. Als analoges Beispiel kann die Bauanleitung eines LEGO-Spielzeugs dienen, mit der man mit unterschiedlichen Arten von Bausteinen (Definitionselemente) schrittweise nach den beschriebenen Abbildungen das Spielzeug mit den Teilen (Nutzungselemente) aufbaut.

In einer Struktur muss man auf die korrekten und vollständigen Verbindungen zwischen den Systemelementen sowie auf die Kompatibilität der Schnittstellen achten. Die Verbindungen leiten bestimmte fließende Elemente von einem Systemelement zu einem anderen Systemelement. Es kommt darauf an sicherzustellen, dass die fließenden Elemente in der Struktur des Systemmodells entlang der Verbindungen und zuletzt durch die Schnittstellen in die Systemelemente hineinkommen.

• Ein System oder Systemelement weist folgende Eigenschaften auf:
• Es besteht aus Teilen – die Schnittstellen sind einige davon.
• Es kann bestimmte Flusseinheiten empfangen und zustellen.
• Es kann bestimmte Verhaltensweisen anbieten oder abfragen.

Aus welchen Systemelementen ein System bestehet, beruht auf Funktionalitäts- und Partitionierungsgründe und führt zum Konzept der Systemarchitektur. Es gibt drei grundsätzliche Funktionalitätsarten von Systemelementen:

• Die Applikations-Elemente führen Prozesse durch, die die Ziele des Systems erfüllen.
• Die Schnittstellen-Elemente verarbeiten die eingehenden und ausgehenden fließenden Elemente und Verhaltensabfragen, welche die Applikations-Elemente für die Durchführung ihre Prozesse brauchen.
• Die Infrastruktur-Elemente unterstützen die Systemelemente mittels Kommunikationsvernetzung oder Energieversorgung u. a.

Diese Funktionalitätsarten werden in Partitionen zugeordnet. Partitionen folgen unterschiedlichen Kriterien:

• Geographische Verteilung eines Systems
• Schutz des Systems,
• Verbesserung der Wartbarkeit des Systems durch die Gruppierung von Systemelementen mit niedriger Zuverlässigkeit
• Gruppierung von Systemelementen mit ähnlichen Auffrischraten [sic].

Zuletzt umfasst eine vollständige Struktur eines Systems alle Systemelemente samt ihren zugehörigen Schnittstellen, allen Verbindungen und allen fließenden Elementen. Dieser Aufbau muss für jede mögliche Konfiguration des Systems und zu jedem Zeitpunkt im Lebenszyklus des Systems aufrechterhalten werden.

Das Verhalten im Systemmodell

Das Verhalten eines Systems ergibt sich aus den Verhaltensweisen aller Elemente des Systems und dem emergenten Verhalten. Das emergente Verhalten eines Systems entsteht aus den Interaktionen und Wechselwirkungen der Systemelemente – deshalb verschwindet es, wenn sie voneinander getrennt werden. Die Systemelemente weisen ein inhärentes Verhalten und/oder abrufbares Verhalten auf. Das inhärente Verhalten eines Systemelements ist das Verhalten, das bei seiner Entstehung beginnt und bei seiner Stilllegung endet. Die abrufbaren Verhaltensweisen haben üblicherweise eine kürzere Lebensdauer und sind von zweierlei Art: Entweder werden sie abgefragt, daraufhin wird von ihnen auf eine Antwort gewartet, oder sie empfangen ein Signal, das ein Verhalten auslöst, allerdings ohne Wartezeit auf Rücklauf.

Indem das Verhalten im Systemmodell modelliert wird, entsteht eine eindeutige Beschreibung des Verhaltens eines Systems. Je nach Fall lässt sich das Verhalten eines Systems mittels unterschiedlicher Modellarten darstellen: der Zustandsautomaten, der Interaktionen, der Aktivitäten oder einer Kombination aus diesen Modellarten.

Zur Bestimmung des Verhaltens eines Systems sind zunächst die in den Stakeholder-Anforderungen beschriebenen erwarteten Dienste eines Systems mithilfe der Anwendungsfälle und Szenarien für alle Betriebsumstände und Umgebungsfaktoren zu modellieren. Zur Erfüllung dieser Erwartungen werden wird dann nach und nach das Verhalten und die Struktur des Systems modelliert.

Die fließenden Elemente und die Verhaltensabrufe, welche die unterschiedlichen Verhaltensweisen miteinander austauschen, fließen entlang der Verbindungen und durch die Schnittstellen, die in der Struktur des Systemmodells modelliert werden. Damit wird sichergestellt, dass die Struktur und das Verhalten des Systems konsistent gehalten werden.

Die Anforderungen im Systemmodell

Wenn das Systemmodell strikt nach einer spezifizierten Modellierungssprache modelliert ist, ist das Systemmodell nichts anderes als eine Systemspezifikation. Allerdings ist diese nur für den verständlich, der die Modellierungssprache kennt. Falls es nötig ist, das Systemmodell in Prosa zu übersetzen, ist sicherzustellen, dass das Systemmodell und die prosaische Spezifikation jederzeit übereinstimmen. Dafür können im Systemmodell die Systemanforderungen als einfache Textfelder modelliert werden. Wichtig ist aber, diese Textfelder miteinander und auch mit den anderen Modellelementen in Beziehung zu setzen. Als Analogie denke man an ein Buch, das in zwei Sprachen gleichzeitig geschrieben wird.

Das System wird während seiner Gestaltung nicht in einem Schub, sondern durch mehrere Iterationen spezifiziert. Nur wenn alle Teile des Systems gemäß ihrer Struktur und ihres Verhaltens miteinander konsistent und vollständig spezifiziert sind, lässt sich der iterative Gestaltungsprozess abschließen. Aus diesem Grund ist es umso wichtiger, dass die im Text modellierten Systemanforderungen mit den gestalterischen Modellelemente jederzeit verbunden und in Übereinstimmung gehalten werden.

• Es gibt für die Anforderungen drei Beziehungsarten in einem Systemmodell:
• Eine Anforderung kann mit anderen Anforderungen zusammenkomponiert werden.
• Eine Anforderung kann „abgeleitet von“ einer anderen Anforderung sein, das heißt, die abgeleitete Anforderung spezifiziert etwas, was zur Erfüllung der ableitenden Anforderung beiträgt.
• Ein System/-element oder eine seiner Eigenschaften „erfüllt“ eine Anforderung, wenn die Struktur oder das Verhalten des Systemelements der textuellen Beschreibung der Anforderung entspricht.
• Ein Testfall „verifiziert“ eine Anforderung, indem er eine Vorgehensweise spezifiziert, die die textuelle Beschreibung der Anforderung bestätigt.

Mithilfe der Beziehungen der Anforderungen baut man einen Spezifikationsbaum. Der Spezifikationsbaum spezifiziert vollständig das System, vorausgesetzt, dass die Anforderungen richtig geschrieben und validiert sind. An der Spitze des Baumes steht die Systemspezifikation, welche sich in einer Dekomposition in unterschiedliche Systemanforderungen verzweigt.

Aus der Vielfalt von Systemanforderungen werden die Anforderungen der Systemelementen „abgeleitet“. Die abgeleiteten Anforderungen bilden einen verspiegelten Baum für jedes Systemelement – die Spezifikation jedes Systemelements.

Mit dem Aufbau des Baumes ist das Ziel erreicht, das System vollständig zu definieren.

Die Erfüllungs-Beziehung, die besagt, dass ein Systemelement bzw. eine Eigenschaft eine Systemanforderung Erfüllen soll und die Verifizierung-Beziehung, die besagt, dass ein Systemelement bzw. eine Eigenschaft tatsächlich eine Systemanforderung erfüllt, bieten uns anhand der Spezifikationsbaum des Systems die Basis für die Integrations-, Verifikations- und Validierungsstrategie.

Die Testfälle im Systemmodell

Ein Testfall ist ein Modellelement des Systemmodells, das signalisiert, ob „ein System, Systemelement oder eine seiner Eigenschaften tatsächlich eine Systemanforderung erfüllt“. Der Testfall spezifiziert eine Nachweisaktion für ein bestimmtes Systemelement. Wenn diese Nachweisaktion fehlerfrei verläuft, ist die Systemanforderung tatsächlich erfüllt. Die Nachweisaktion wird im Systemmodell mittels eines Verhaltens modelliert. Das Verhalten wird ein/mehrere Stimuli ausgeben und eine Antwort vom System erhalten, die mit den Angaben der Systemanforderung verglichen wird.  Das im Testfall beschriebene Verhalten kann seinerseits Bestandteil der Spezifikation eines Unterstützungssystems (eines Testgerätes) sein.

Besonders bemerkenswert im Umgang mit den Testfällen ist, dass es nicht um die Verifikation von Systemen oder Systemelementen, sondern von Systemanforderungen geht. Hier liegt der Fokus auf der Systemanforderung. Ein Testfall verifiziert eine Systemanforderung, indem der Testfall mit dem System interagiert, das die Systemanforderung erfüllt.

Testfall: „du Systemanforderung, ich will dich verifizieren, welches System oder Systemelement verspricht, dich zu erfüllen?“

Systemanforderung: „Danke! Das Systemelement XYZ sagt, dass es das kann.“

Testfall: „Lass mich das mal mit meinem Verhalten verifizieren.“

Es kann gut sein, dass ein System oder Systemelement von mehreren Testfällen verifiziert wird, denn es kann an der Erfüllung von mehreren Systemanforderungen beteiligt sein. Das bedeutet nicht, dass einige Nachweisaktionen überflüssig sind, ganz im Gegenteil, das System oder Systemelement wird unter verschiedenen Umständen verifiziert, die unterschiedlichen Nutzungsszenarien entsprechen.

Wenn man aus dem Spezifikationsbaum einen entsprechenden Testfällen-Baum aufbaut, verschafft man sich eine Basis für die Integrations-, Verifikations- und Validierungsstrategie. Der Testfälle-Baum lässt sich anhand seiner Verbindungen mit dem Systemmodell für jede Referenzkonfiguration des Systems darstellen und aufrechthalten.

Die Analyse im Systemmodell

Bei der Frage der Analyse liegt der Schwerpunkt in der oft komplizierten mathematischen Welt der Rechnungsmodelle. Die Eingaben und Ausgänge, die unterschiedlichen Eigenschaften eines Systems entsprechen, werden mittels mathematischer Sachverhalte zueinander in Bezug gestellt. Ohne Systemmodell müssten die Ergebnisse der Analyse in Dokumente und Tabellen verwaltet werden.

Das Systemmodell bietet die Möglichkeit, diese in Beziehungen zueinander gestellten Eigenschaften des Systems durch das Systemmodell zu verwalten und sie so mit den anderen im Systemmodell existierenden Eigenschaften zusammenzubringen. Aus der Sicht des Rechnungsmodells sind die Eigenschaften bloß die Eingaben und Ausgänge eines komplizierten Verfahrens. Aus der Sicht des Systemmodells aber bilden die Eigenschaften einen „n-dimensionalen“ Lösungsraum eines Systems. Das Systemmodell bietet auf diese Art ein Rahmenwerk für die Analyseergebnisse aus den Rechnungsmodellen.

Im Systemmodell wird ein Modellelement angewendet, das die Zusammenhänge zwischen Eingaben und Ausgänge abstrakt in Form einer Einschränkung darstellt. Das Systemmodell kümmert sich nicht um das interne Anlegen dieser Einschränkung, sondern stellt einfach nur einen Platzhalter dafür zur Verfügung. Eine Einschränkung wird dann mit Parametern versehen, die die entsprechenden Eingaben und Ausgänge nachbilden. Zuletzt müssen die Parameter in den Systemeigenschaften eingebunden werden.

Der Platzhalter kann je nach Modellierungs-Tool Rechnungsvermögen anbieten. Tools können üblicherweise Programmierungssprachen wie C, C++ oder Java interpretieren, sowie schon heute mögliche Integrationen mit Analyse-Tools wie „Modelica“ oder „Mathlab“ anbieten. In den kommenden Jahren erwarten wir durch die Verbreitung von API's ein erhöhtes Interaktionsvermögen. Die Integration von Rechnungsmodellen durch die Einschränkungen im Systemmodell verschafft die Möglichkeit, verschiedene Lösungen des Systems auszuprobieren und damit synchron die nötige Analyse beim entsprechenden Rechnungsmodellen anzusteuern, ohne Übertragungsfehler und Aufwand.

Fazit

Das Systemmodell liegt im Zentrum des MBSE und orchestriert alle für die Entwicklung nötigen Modelle. Auf diese Weise fungiert das Systemmodell als eine nach der Topologie des Zielsystems gestaltete Datenablage für Anforderungen, Systemelemente samt ihren Verhaltensweisen und Interaktionen, Parameter sowie Verifikations- und Validierungsmaßnahmen. Das Systemmodell stellt durch eine geeignete Modellierungssprache (SysML hat sich etabliert) eine zweckmäßige Modellierungsmethode und, in einem modernen Modellierungstool angewendet, eine effektive Unterstützung für den Systemarchitekten und -entwickler dar. Da Systeme immer komplexer und immer wieder miteinander in neuen und kreativen „Systems-of-Systems“ kombiniert werden, ist die Gestaltung eines Systemmodells nach einer anerkannten Modellierungssprache und Modellierungsmethode nicht nur ein Garant des Erfolgs der Systementwicklung, sondern auch ein nötiges Artefakt für die Beteiligung an künftigen „Systems-of-Systems“.