Was ist neu in der SysML 1.6?

Dieser Blogbeitrag stellt die relevanten Änderungen in der neuen SysML Version 1.6 vor. Ich lasse die Änderungen aus, die nur das Spezifikationsdokument betreffen, wie die Korrektur von Tippfehlern oder Umformulierungen.

---

SysML 1.6 wurde am 5. Dezember 2019 veröffentlicht. Sie finden das Spezifikationsdokument auf der OMG-Website www.omg.org/spec/SysML. Dort finden Sie auch die Liste aller bisher veröffentlichten SysML-Spezifikationen. Die Spezifikationsdokumente der OMG  sind alle kostenlos erhältlich.

Die SysML 1.6 wurde von der SysML 1.6 Revision Task Force (RTF) erstellt. Mitglieder der RTF sind Vertreter verschiedener Unternehmen, die Mitglied der OMG sind. Darunter sind Toolhersteller wie NoMagic bzw. Dassault, PTC oder IBM, industrielle Anwender wie NASA oder Airbus und andere Organisationen wie NIST oder meine Firma oose. Yves Bernard von Airbus, Robert Karban von Nasa JPL und ich waren Vorsitzende der SysML 1.6 RTF.

Eine RTF arbeitet eine Liste von Problemen ab, die von jedem eingereicht werden können, der etwas Verdächtiges in einem Standard gefunden hat. Das Formular zur Meldung eines Problems kann auf der OMG-Webseite aufgerufen werden: issues.omg.org/issues/create-new-issue. Die RTF diskutiert jedes eingereichte Problem, und die Mitglieder der RTF erstellen Lösungsvorschläge und stimmen über deren Annahme (oder Ablehnung) ab.

Ende letzten Jahres hat die SysML 1.7 RTF mit der Arbeit an der nächsten Revision 1.7 der SysML begonnen. Yves Bernard von Airbus und ich von oose leiten die RTF.

Parallel dazu wurde auch mit der Arbeit an der nächsten Generation von SysML begonnen: die SysML v2. Schauen Sie sich die Blog-Postserie über die nächste Generation von SysML im Blog an.

Werfen wir nun einen Blick auf die Änderungen in der SysML 1.6:

Einige kleine Änderungen

Die meisten Änderungen waren kleine Dinge. Die folgende Liste zeigt einige davon:

Die Überschriften der Abteilungen eines Blocks müssen der folgenden Schreibweise entsprechen: Kursiv, sofern dies durch die verwendete Schriftart erlaubt ist, und

• Zentriert
• Kleinbuchstaben
• Wörter durch Leerzeichen getrennt

Die folgende Abbildung zeigt ein Beispiel mit den Überschriften nach dieser Schreibweise:

Die Aufzählungen FlowDirection, FeatureDirection und ControlValue werden in FlowDirectionKind, FeatureDirectionKind und ControlValueKind umbenannt, um die Namenskonvention der Aufzählungstypen zu erfüllen, dass der Name den Postfix „Kind“ haben soll.

Der Binding-Connector hat nun eine zusätzliche alternative Schreibweise. In Kombination mit Proxy-Ports erscheint der Binding-Connector sehr häufig in internen Blockdiagrammen, und das Schlüsselwort „equal“ überfüllt das Diagramm. Mit SysML 1.6 können Sie alternativ das Symbol = verwenden. Die nächste Abbildung veranschaulicht die neue alternative Schreibweise.

Mehr Formalismus: OCL statt Text

Ein Teil der Definition eines SysML-Modellelements ist oft eine Liste von Zusicherungen, z.B. hat die Erfüllungsbeziehung (satisfy) die Zusicherung: „Das Zielelement muss ein Element sein, das das Stereotyp Requirement oder einen der Subtypen von Requirement hat.“ Die in natürlicher Sprache geschriebenen Zusicherungen sind verständlich, aber manchmal nicht ausreichend präzise und durch ein Modellierungswerkzeug überprüfbar.

Wo immer möglich, bietet SysML 1.6 jetzt formal definierte Zusicherungs-Anweisungen in der Object Constraint Language (OCL). Insgesamt 22 Seiten OCL-Anweisungen haben die SysML-Spezifikation verbessert. So wird beispielsweise die oben erwähnte Zusicherung der Erfüllungsbeziehung nun auch in OCL angegeben:

AbstractRequirement.allInstances().base_NamedElement->includes(self.base_Abstraction.supplier)

Bitte beachten Sie, dass hiermit auch ein Fehler in der Zusicherung behoben wurde. Das Stereotyp Requirement wurde durch AbstractRequirement ersetzt, das mit SysML 1.5 eingeführt wurde und auch nicht-textuelle Anforderungen ermöglicht.

Teileigenschaften eines Blocks ohne Assoziationen definieren

Eine wesentliche Änderung in SysML 1.6 ist das Löschen der Einschränkung, dass Eigenschaften (Part-Properties), die von einem Block typisiert werden, als Ende einer Assoziation definiert werden müssen. In der Praxis können Sie nun Teileigenschaften beispielsweise in einem internen Blockdiagramm erstellen, ohne eine Komositionsbeziehung (Assoziation) modellieren zu müssen.

 

Im Modell haben sind nur die Blöcke (Typen der Teileigenschaften) und die Teileigenschaften selbst gespeichert. Es fehlen die Assoziationsbeziehungen. Daher können Sie nicht mehr die Zerlegungsstruktur in einem Blockdefinitionsdiagramm darstellen. Der Nutzen dieses Diagramms ist im Gegensatz zum Aufwand für die Erstellung des Diagramms allerdings gering. Die meisten Ingenieure sind nur an den internen Blockdiagrammdiagrammen interessiert.

Ein weiterer Vorteil ist, dass Sie weniger Modellelemente im Modell speichern und pflegen müssen. Die Modellierung einer Assoziation erzeugt 3 Elemente im Modell: die Assoziation selbst und eine Eigenschaft an jedem Assoziationsende. Wenn Sie die Eigenschaft ohne Zuordnung modellieren, legen Sie nur 1 Element statt 3 Elemente im Modell an.

Wenn Sie möchten, können Sie weiterhin die Eigenschaften mit einer Assoziationsbeziehung modellieren. SysML 1.6 hat nur die Einschränkung beseitigt, dass es obligatorisch ist. Übrigens wird SysML v2 den anwender-orientierten Modellierungsansatz unterstützen. Einfach ausgedrückt bedeutet es, ibd’s ohne bdd’s zu modellieren.

Eigenschaftsspezifischer Typ (Property-specific Type)

Kennen Sie eigenschaftsspezifische Typen? Nein? Kein Wunder, denn SysML spezifiziert sie sehr schlecht und entsprechend ist die Umsetzung in Modellierungswerkzeugen. Das bei der OMG eingereichte Problem über eigenschaftsspezifische Typen besagt:

• Die Definition eines eigenschaftsspezifischen Typs kann auf einem Blockdefinitionsdiagramm nicht angezeigt werden.
• Es wird keine Laufzeit-Semantik definiert.
• Es werden keine Beispiele für den eigenschaftsspezifischen Typ beschrieben.

SysML 1.6 verbessert die Definition des eigenschaftsspezifischen Typs und nimmt gleichzeitig einige kleinere Anpassungen vor. Die folgenden Abbildungen zeigen ein Beispiel für eine Anwendung des eigenschaftsspezifischen Typs.

 

Das Blockdefinitionsdiagramm definiert zwei Blöcke, die den sehr allgemeinen abstrakten Block Objekt spezialisieren. Das Warehouse verweist auf eine Liste von Artikeln, die im Lager gelagert werden (storedItems), und das Warehouse ist der Namensraum des eigenschaftsspezifischen Typs Warehouse Item. Der eigenschaftsspezifische Typ wird durch das Stereotyp <<pst>> gekennzeichnet.

Basierend auf diesen Definitionen erstellen wir eine Instanzspezifikation einer Machine und eines leeren Warehouse.

 

Jetzt lagern wir die Maschine im Lager ein, d.h., wir ordnen die Instanzspezifikation ProductX der Eigenschaft der eingelagerten Artikel zu. Damit erhält die Instanzspezifikation auch den eigenschaftsspezifischen Typ und die damit definierte Eigenschaft storedAt.

 

Wenn ProductX aus der Menge der eingelagerten Artikel entfernt wird, wird auch die Eigenschaft storedAt automatisch entfernt.

Konjugierte Ports

SysML 1.6 behebt ein großes Problem bei der Modellierung von konjugierten Ports. Die folgende Abbildung zeigt eine einfache Definition einer Tür mit einem Proxy-Port, der die Schnittstelle des Türschloss spezifiziert. Die Tür spezialisiert zusätzlich den Schnittstellenblock, um sicherzustellen, dass der Block die spezifizierten Schnittstellenmerkmale implementiert. Beachten Sie, dass es sich hier um eine technische Verwendung der Generalisierungsbeziehung handelt. Konzeptionell macht es keinen Sinn: Die Tür ist keine Art Schloss.

Im digitalen Zeitalter ist der Anwender der Tür ein Roboter, der den Schlüsselcode für das Türschloss hat. Im ersten Versuch ist die Definition ähnlich, aber mit einem konjugierten Port, d.h. der Schlüsselcode hat nicht die Richtung „in“ wie bei der Tür, sondern „out“. Übrigens – denken Sie nicht einmal daran, beide Ports im Blockdefinitionsdiagramm zu verbinden. Es sieht verlockend aus, ist aber völlig falsch. Sie verbinden sie im internen Blockdiagramm (Anwendung von Dingen versus Definition von Dingen).

 

Spätestens auf dem zweiten Blick werden Sie feststellen, dass die Definition des Roboters nicht funktioniert. Er erbt die Flow-Eigenschaft „in k:Keycode“ vom Schnittstellenblock, es sollte aber „out k:Keycode“ sein. Man brauchst also so etwas wie eine „konjugierte Generalisierungsbeziehung“. Als Workaround habe ich ein solches Element im SYSMOD-Profil definiert.

Jetzt wurde das Problem in SysML 1.6 behoben, aber nicht mit einer konjugierten Generalisierungsbeziehung. Ein neuer spezieller konjugierter Schnittstellenblock namens „~interfaceBlock“ übernimmt die Aufgabe. Der konjugierte Schnittstellenblock verweist auf den ursprünglichen Schnittstellenblock und dreht alle Richtungen um. Die Notation ist die gleiche wie beim konjugierten Portmechanismus und aus der Diagrammperspektive sieht es genauso aus. Hinter den Kulissen wird jedoch nicht der konjugierte Portmechanismus verwendet, sondern der neue konjugierte Schnittstellenblock.

 

Es ist vorgesehen, dass der größte Teil dieser Modellierung automatisch vom Modellierungstool durchgeführt wird und den Modellierer nicht stören sollte.

Dies waren alle relevanten Änderungen der SysML 1.6 gegenüber der SysML 1.5. Wenn Sie alle Änderungen sehen möchten, lesen Sie das Spezifikationsdokument mit Änderungsbalken. Sie können es von der SysML-Spezifikationsseite auf der OMG-Website herunterladen: www.omg.org/spec/SysML.

Die englische Version dieses Beitrags finden Sie im MBSE4U-Blog: https://mbse4u.com/2019/12/05/whats-new-in-sysml-1-6/