Schnittstellenmodellierung mit SysML v2 (in SysIDE)

Schnittstellenmodellierung ist wichtiges Thema in Model Based Systems Engineering (MBSE), da diese Komponenten voneinander entkoppeln. Das ermöglicht das Beherrschen der Komplexität. Sprachen wie die SysML eignen sich hervorragend, um Schnittstellen präzise zu spezifizieren.

In diesem Artikel schaue ich mir die Konstrukte zu Schnittstellenmodellierung der SysML v2 etwas genauer an, denn da gibt es eine ganze Menge von! Das Thema ist zwar unabhängig vom Werkzeug. Doch die folgenden Beispiele habe ich mit SysIDE durchgespielt, da ich mich mit diesem Werkzeug sowieso noch einmal auseinandersetzen wollte.

Hinweis: Ich veranstalte ein Webinar zu Schnittstellen mit SysML am 25.09., 16:00, zusammen mit SodiusWillert. Jetzt anmelden

Schnittstellen entkoppeln Subsysteme

Schnittstellen ermöglichen es, Systeme in klar abgegrenzte Komponenten/Subsysteme zu zerlegen, die unabhängig voneinander entwickelt, getestet und sogar ausgetauscht werden können. Dieses Prinzip der Entkopplung reduziert den Koordinationsaufwand zwischen Teams und erlaubt asynchrone Entwicklungsprozesse. Stabile Schnittstellen können Probleme bei der Integration drastisch reduzieren.

Gutes MBSE praktiziert „Black Box“-Denken, ein Konzept, bei dem Komponente über ihre Ein- und Ausgaben sowie ihr Verhalten beschrieben, ohne dass ihre innere Funktionsweise bekannt sein muss. Genau dies ist einer der Stärken der SysML (egal welche Version). Wer mit komplexen Systemen arbeitet, kommt um saubere Schnittstellenmodellierung nicht herum.

SysIDE: SysML v2-Modellierung in VS Code

Ich habe bereits mit mehreren SysML v2-Werkzeugen experimentiert. SysIDE stand schon länger auf meiner Liste von interessanten Werkzeugen: Denn SysIDE ist sowohl Open Source als auch kommerziell, eine Kombination, die die Softwareentwicklung transformiert hat.

Ebenso ungewöhnlich ist der „Text First“-Ansatz von SysIDE: Es handelt sich nicht um ein eigenständiges Werkzeug, sondern ist eine Erweiterung von VS Code bzw. kompatibler IDEs. Ich nutze seit einer Weile Cursor AI, in das sich SysIDE problemlos installieren lässt.

Die Community-Edition von SysIDE ermöglicht keine visuelle Darstellung. Ich habe zur Zeit ein aktives Trial, weshalb ich auch SysIDE-generierte Diagramme aus SysIDE im Folgenden einbinde. Die Diagramme werden mit TomSawyer gerendert, welches beim SysIDE Modeler mit dabei ist.

Schnittstellenmodellierung mit SysML v2

Wer nicht mit der SysML v2 vertraut ist, sollte einen Blick auf die SysML v2 FAQ von Tim Weilkiens, Stephan Roth & Uwe Kaufmann werfen, die die wichtigsten Fragen beantwortet.

Zunächst zu unserem Inventar: Die SysML v2 unterscheidet bei fast allen Elementen zwischen Nutzung und Definition, wobei die Definition oft optional ist.

Für die Schnittstellenmodellierung müssen wir zwei Aspekte berücksichtigen:

• Was verbinden wir?
• Wie verbinden wir es?

Verbinden können wir fast alles: Parts, Ports, aber auch Actions und vieles mehr, wobei nicht jeder Elementtyp in jeder Konstellation für die Schnittstellenmodellierung relevant ist Ebenso sind im Kontext der Schnittstellenmodellierung nicht alle Verbindungsmöglichkeiten relevant aber konkret Connections und Interfaces (eine Spezialisierung von Connection).

Weiterhin kommen Elemente wie Attributes und Items ins Spiel, wenn es darum geht, was sich an den Schnittstellen abspielt.

Hinweis: Bitte gern Rückmeldung zu den folgenden Beschreibungen, die sicherlich an der einen oder anderen Stelle noch Verbesserungspotential haben.

Parts und Connections

Parts sind die elementaren „Bausteine“ in SysML v2. Parts können direkt miteinander verbunden werden, und zwar mit Connections. Wobei gleich vorweg: Für die Modellierung von Schnittstellen würden wir normalerweise nicht Parts verbinden, sondern Ports (nächster Abschnitt).

package SETrends {
  part A;
  part B;
  connection connect (A, B);
  // connect (A, B);  # Alternative 1
  // connect A to B;  # Alternative 2
}

Ports

Ein Port in SysML v2 entspricht einem Proxy Port in SysML v1.x. Ein Portist ein Teil eines Parts. Ports können ebenfalls mit Connections, aber auch mit Interfaces verbunden werden (gleich mehr zu den Unterschieden):

package SETrends {
  part A {
    port pa;
  }
  part B {
    port pb;
  }
  interface connect (A.pa, B.pb);
  // connection connect (A.pa, B.pb); # Möglich aber nicht sinnvoll
}

Wenn ein Part ein anderes enthält, können wir über bind den Port nach außen sichtbar machen. Da es sich wirklich um denselben Port handelt, sind dies Referenzen, daher auch das Gleichheitszeichen:

part BlackBox {
  port p;
  part A {
    port p;
  }
  bind p = A.p;
}

Connections und Interfaces

Ein Interface ist zunächst eine Spezialisierung einer Connection für Ports: Jedes Interface ist also auch eine Connection. Ports mit Connections zu verbinden ist valides SysML v2, sollten wir aber vermeiden.

Connections sind selbst Elemente und können logisch oder physisch sein, bspw. eine logische Verbindung zwischen Pumpe und Tank oder eine physische Verbindung durch ein Rohrleitungssystem.

Connections können zusätzliche Attribute enthalten, die nicht direkt zu den verbundenen Elementen gehören, z. B. Flussrate durch eine Leitung.

Interfaces dienen der Wiederverwendbarkeit: Zum Beispiel sollte die Verbindung einer Stromversorgung bei verschiedenen Geräten und Steckdosen gleich bleiben.

Port Features, Port Definitionen und konjugierte Ports

In der Praxis würden wir mit Port Definitionen arbeiten, um eine Wiederverwendung zu ermöglichen.

Ebenso haben Ports in der Regel Features, die über in, out oder inout eine Richtung bekommen. Dies kennen wir alles schon aus SysML v1 und ermöglicht uns, die Konsistenz unseres Modells zu überprüfen. Features können aber auch zusätzliche Attribute sein,

Sobald wir mit Port Definitionen arbeiten, können wir diese auch konjugieren (~) um die Definition des Ports zu invertieren und alle Richtungen umzukehren.

Port Features: Kern der Schnittstellenbeschreibung

In diesem Artikel soll es ja um Schnittstellenbeschreibung, und die manifestiert sich in den Ports, und allem, was daran hängt. Das sind die eben schon angesprochenen Port Features, also Flüsse oder Attribute. Alle diese Features müssen technisch gesehen nicht typisiert sein, doch ohne macht es in der Praxis macht kaum Sinn. Schließlich wollen wir Präzision, die es uns ermöglicht automatische Konsistenzprüfungen durchzuführen.

Zum Abschluss daher ein weiteres Beispiel, dass zeigt, wie wir über Port Defs und Interface Defs sowie den Einsatz von Typisierung eine Steckdosenverbindung modellieren können. Was hier deutlich zu sehen ist: Das Diagram ist nur eine sehr lückenhafte Sicht auf das Modell. Dennoch ist es nützlich, um die Übersicht zu behalten. Für die Schnittstellenbeschreibung ist die textuelle Form wesentlich besser geeignet.

private import SI::V;
private import SI::A;
private import ISQElectromagnetism::electricPower;
package SETrends {
  port def HouseholdOutlet {
    out power : electricPower;
    attribute voltage = 230 [V];
    attribute maxCurrent = 16 [A];
  }
  port def HouseholdDevice {
    in power : electricPower;
    attribute voltage = 230 [V];
    attribute maxCurrent;
  }
  interface def ApplicanceConnection {
    end port outlet : HouseholdOutlet;
    end port device : HouseholdDevice;
  }
  part HouseholdGrid {
    port outlet : HouseholdOutlet;
  }
  part Toaster {
    port power : HouseholdDevice {
      :>> maxCurrent = 2 [A];
    }
  }
  interface : ApplicanceConnection connect 
    outlet ::> HouseholdGrid.outlet to 
    device ::> Toaster.power;
}

Was noch fehlt

Wie oft bei SysML, ist dies nur die Spitze des Eisbergs. Und das hier gezeigte ist noch nicht ausreichend für eine vollständige Modellierung von Schnittstellen:

• Die Modellierung von Verhalten habe ich hier ausgeklammert, denn das ist zwar ein wichtiges, aber gleichzeitig sehr umfangreiches Thema.
• Auch die Dokumentation habe ich hier ausgelassen (wobei die Symbolnamen ja selbst schon ein Teil der Dokumentation sind. Doch SysML v2 hat mehrere Mechanismen für die Dokumentation. Neben doc-Kommentaren können wir hier auch Metadaten oder verknüpfte Elemente wie Anforderungen berücksichtigen.
• Die vorgestellten Features können wir in vielen verschiedenen Permutationen einsetzen, zum Beispiel über die Verschachtelung von Ports, Vererbung und anderen Features.

Fazit

SysIDE war bisher mit Abstand die angenehmste Arbeitumgebung für die SysML v2 Textnotation, was auch auf die Integration mit VS Code zurückzuführen ist. Dabei zeigte sich auch, wie angenehm es ist, SysML v2-Schnittstellen textuell festzuhalten. Bei der Darstellung von Diagrammen ist allerdings noch Luft nach oben, zumal das ein kommerzielles Feature ist.

Schnittstellenmodellierung ist ein wichtiger Aspekt zur Beherrschung der Komplexität. SysML v2 und SysIDE zeigen deutlich einen Schritt in die richtige Richtung.