Systems Engineering Trends

Jede Woche Neuigkeiten aus der Welt des Systems Engineering

Modellierung & MBSEStandards & Methoden

Kontextmodellierung mit dem SysML-Block

Der Block ist einer der bekanntesten und wichtigsten Elemente der SysML. Doch gerade bei Einsteigern sehe ich in der Praxis oft Verwirrung und auch Fehler beim Einsatz, insbesondere am Whiteboard.

Dieser Artikel soll gerade Einsteigern helfen, sich nichts Falsches anzugewöhnen und den SysML-Block so schnell wie möglich selbst zu nutzen. Die Modellierung des Systemkontextes ist dafür ein gutes Beispiel. Und darum geht es in diesem Artikel.

Erfahrene SysML-Experten finden diesen Artikel wahrscheinlich langweilig. Die dürfen jedoch nach Fehlern suchen (gibt’s garantiert) und ihre eigenen Tipps zu Blöcken in die Kommentare schreiben.

Wichtige Unterscheidung: Definition und Verwendung des Blocks

In SysML begegnen uns Blöcke in zwei unterschiedlichen Kontexten, was gerade bei Einsteigern zur Verwirrung führen kann. Zum einen können Blöcke die Eigenschaften von einem für uns interessantem Element definieren. Dann erscheinen sie im Block Definition Diagram (bdd). Zum anderen können wir auch die Verwendung der Blöcke festhalten. Dann erscheinen sie im Internal Block Diagram (ibd).

Gerade am Whiteboard: Block Definition Diagram (bdd) und Internal Block Diagram (ibd) nicht vermischen!

Ein Kontext kann sowohl mit bdds oder ibds modellliert werden, beides hat seine Berechtigung. Wenn wir im Werkzeug modellieren, dann brauchen wir beides (zumindest bei SysML 1.x. Bei SysML v2 kann die Definition wegfallen).

Simples Beispiel: Handy laden

Dieses Beispiel stammt aus dem unten eingebettete Video. Wir wollen den Kontext für das Laden eines Smartphones modellieren. Dazu spielen die folgenden vier Teile zusammen, die alle Teil des Systemkontexts sind:

Ein iPhone, Ladekabel, Netzteil und Steckdose.
Bild 1: Die Teile, die wir betrachten.

Wenn wir uns an den Artikel von letzter Woche zum Modellierung des Systemkontexts erinnern, dann fällt zunächst auf, dass es kein „System of Interest“ gibt, das die Mitte unseres sternförmigen Kontextdiagramms bildet. Das ist nicht ungewöhnlich und begegnet uns insbesondere bei System of Systems. In solchen Fällen ist es üblich, den Systemkontext als eigenes Element einzuführen.

Alles Blöcke

Mit den vier oben aufgeführten Elementen haven wir also fünf Elemente, die wir jeweils als SysML-Block modellieren. Die Beziehung ist in diesem Fall trivial: die vier Elemente sind alle Teile des Kontexts. Das können wir visuell in einem Block Definition Diagram (bdd) über eine Composition-Relationship festhalten:

Bild 2: Die Teile als Bestandteil des Ladekontexts. Quelle: CameoMagic via Youtube

Ob sich der „Aufwand“ für ein bdd am Whiteboard lohnt, sollte hinterfragt werden. Bei einer Modellierung im Werkzeug (SysML 1.x) müssen wir die Blöcke anlegen, das Erstellen des Diagramms hingegen ist optional.

In der Praxis gibt es neben der Kontextmodellierung noch viele andere Anwendungsfälle für bdds.

Verwendung der Blöcke

Im Diagram sind nicht alle Eigenschaften der Blöcke zu sehen. Diese können aber optional in Fächern angezeigt werden. Da wir uns hier mit der Verbindung der vier Blöcke beschäftigen wollen, können wir im bdd die Ports anzeigen:

Block "iPhone" mit sichtbarem Bereich für Proxy-Ports

Hier sehen wir, dass das iPhone einen Lightning-Anschluss hat, der als Proxyport modelliert wurde. Warum wir auf „Full Ports“ verzichten sollten, beschreibt Tim Weilkiens in diesem Artikel.

Neben den Ports können Blöcke noch viele weitere Eigenschaften haben, wie Werte, Constraints, Operatoren und vieles mehr. Auch die Teile (Parts) sind Teil des Blocks und könnten in einem Fach angezeigt werden.

Doch auch, wenn wir in Bild 2 die Ports anzeigen würden, hätten wir noch keine Information über die Verwendung der Ports. Wir hätten lediglich eine SysML-Darstellung von Bild 1. Für die Verwendung brauchen wir ein Internal Block Diagram (ibd).

Verwendung in der Glasbox modellieren

Der Rahmen eines Internal Block Diagrams (ibd) entspricht immer einem SysML-Block. In diesem Fall wollen wir uns das innere des Kontextes anschauen, das folgendermaßen aussieht:

Bild 3: Die Verwendung der Teile des Ladekontexts. Quelle: CameoMagic via Youtube

Intuitiv ist das Bild recht einfach zu verstehen, da es zeigt, wie das iPhone über das Kabel mit dem Ladegerät verbunden ist, welches in der Wandsteckdose steckt. Doch was geht hier im Detail vor sich?

Schon visuell erkennen wir, dass sich die Symbole in Bild 2 und 3 unterscheiden: In Bild 2 haben wir Blockdefinitionen, in Bild 3 haben wir Instanzen von Blöcken. In der objektorientierten Welt ist dies Vergleichbar mit Klassen und Objekten (Objekte sind Instanzen von Klassen).

Was gerade für Einsteiger verwirrend sein kann: Häufig haben wir genau eine Instanz eines Blocks, wie in diesem Beispiel. Das muss aber nicht so sein.

Die Bezeichner der Blockinstanzen verstehen

Da im ibd die Boxen instantiierte Blöcke sind, haben sie auch Bezeichner, die aus zwei Teilen bestehen, zum Beispiel „box : Charger Box“. Dabei ist „box“ der Name der Instanz und „Charger Box“ die dazugehörige Blockdefinition.

Wenn wir es nur mit einer Instanz eines Blocks zu tun haben, können wir auch den Bezeichner weglassen. Dann erkennen wir am Doppelpunkt immer noch, dass es sich um eine Blockinstanz handelt. Also bspw. „: ChargerBox“.

Blöcke Verdrahten

Beim ibd liegt der Fokus darauf, die Verwendung der Teile zu verstehen. In Bild 3 sehen wir an den Relationen, wie die vier Teile miteinander verbunden sind und die Energie von Wall Outlet über Charger Box und Charger Cable zum iPhone fließt.

Hier zeigt sich bereits, warum die Modellierung einen Mehrwert darstellt:

  • Wir erkennen Ports, die definiert aber nicht verwendet wurden (Ports ohne Verbindung)
  • Wir erkennen, dass verbundene Ports kompatibel sein müssen

Um diesen Mehrwert zu realisieren, brauchen wir kein Diagramm. Moderne Werkzeuge können automatisch diese Überprüfung anhand des Modells durchführen. Doch auch am Whiteboard kann die Modellierung eines ibds einen hohen Nutzen zur Kommunikation beitragen, auch wenn wir dabei das Diagramm „nur“ visuell prüfen können.

Ports müssen oft komplementär sein (Stecker vs. Steckdose). Das Konzept der „konjugierten Ports“ wurde mit der SysML 1.6 abgeschafft. Warum, erklärt Tim Weilkiens in Conjugation Considered Harmful!

Verschachtelung

Anhand der Bezeichnungen in Bild 3 können wir erahnen, dass hinter dem Diagramm noch wesentlich mehr steckt, als zu sehen ist. Schauen wir uns die Verbindung zwischen Charger Box und Wall Outlet genauer an. Anhand der Tilde (~) erkennen wir, das mit „Standard Wall Plug“ einmal die Steckdose und auf der anderen Seite den Stecker repräsentiert. Weiterhin sehen wir „GND“ und „Power“. Falls wir mit einem Werkzeug modellieren, können wir hier eine Ebene tiefer gehen:

Bild 4: Wir können weitere Details eines Ports modellieren. Quelle: CameoMagic via Youtube

Auch hier haben wir wieder den Vorteil, dass Werkzeuge es uns ermöglichen, die Konsistenz des System zu validieren. Natürlich kann nur validiert werden, was auch modelliert wurde. Wenn wir in diesem Beispiel die Spannung modellieren aber nicht den Strom, dann kann uns das System vor dem Anschluss einer falschen Spannung warnen, nicht aber vor einer zu hohen Leistung (Stromfluss).

Fazit

Wir begegnen dem SysML-Block inzwischen so häufig, dass wir zumindest die Grundlagen kennen sollten. Beim Lesen ist es wichtig, dass wir verstehen, dass uns Blöcke in zwei unterschiedlichen Kontexten begegnet, als Definition und in der Verwendung. Beides hat seine Existenzberechtigung.

Wenn wir irgendwann anfangen, am Whiteboard Zusammenhänge zu skizzieren, ist es besonders wichtig, diesen Unterschied zu verinnerlichen. Nichts verwirrt mehr, als ibd und bdd zu mischen. Am Whiteboard ist häufig das ibd hilfreicher.

Video

Mehrere Bilder habe icvh aus diesem Kurzen Video genommen, das sehr schön zeigt, wie Block-Definition und -Verwendung zusammenspielen:

Photo by Thomas Kolnowski on Unsplash

Michael Jastram

Creator and Author of SE-Trends