search
menu Navigation
Was ist neu in der SysML 1.6?

Systems Engineering

Was ist neu in der SysML 1.6?

12. Dezember 2019

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:

SysML 1.6 block compartment notation

SysML 1.6 Block compartment notation

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.

SysML 1.6: Alternative Notation des BindingConnectors

SysML 1.6: Alternative Notation des Binding-Connectors

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.

SysML 1.6: Part-Properties ohne Assoziationen

SysML 1.6: Part-Properties ohne Assoziationen

 

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.

SysML 1.6: Beispiel eines eigenschaftsspezifischen Typs (Definition)

SysML 1.6: Beispiel eines eigenschaftsspezifischen Typs (Definition)

 

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.

SysML 1.6: InstanceSpecifications für eigenschaftsspezifischen Typ (Szenario 1)

SysML 1.6: Szenario 1 für igenschaftsspezifischen Typ

 

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.

SysML 1.6: Szenario 2 für igenschaftsspezifischen Typ 

SysML 1.6: Szenario 2 für igenschaftsspezifischen Typ

 

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.

SysML 1.6: Beispiel konjugierter Port (Definition Tür)

SysML 1.6: Beispiel konjugierter Port (Tür)

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).

SysML 1.6: Beispiel konjugierter Port (Definition Roboter - FALSCH)

SysML 1.6: Beispiel konjugierter Port (Roboter – FALSCH)

 

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.

SysML 1.6: Beispiel konjugierter Port (Definition Roboter - KORREKT)

SysML 1.6: Beispiel konjugierter Port (Roboter – KORREKT)

 

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/


7 Antworten zu “Was ist neu in der SysML 1.6?”

  1. Carsten Pitz sagt:

    Hallo Tim,
    zu deinem Beispiel mit konjugierten Ports. Bei UML ist der Port typisiert. Damit ist der, aus meiner Sicht Unsinn unnötig, die Blöcke Door und Robot von Lock ableiten zu müssen. Die Blöcke Door und Robot nutzen die Schnittstelle Lock via den Ports guard respektive opener. Aber dies bedingt, meiner Meinung nach keine Vererbungshierarchie.
    Was meiner Meinung nach geändert werden sollte ist, dass SysML::Allocate von UML::Abstraction abgeleitet ist. Das bedeutet, dass ein Element nur auf dessen Abstraktion alloziert werden darf.
    Desweiteren halte ich den Stereotyp <> auf einer UML::InstanceSpecification mehr als verwirrend. Elemente mit Klassen- und Objektcharakter sollten nicht vermischt werden.
    Ein frohes Fest,
    einen guten Rutsch und
    Beste Grüße,
    Carsten

    • Tim Weilkiens sagt:

      Hallo Carsten,

      Die Blöcke Door und Robot müssen von der Portdefinition Lock spezialisieren, um sicherzustellen, dass sie die geforderten Features auch umsetzen. Die Ports sind Proxy-Ports und nur Stellvertreter der eigentlichen Umsetzung in Door und Robot. Es ist dieselbe Struktur, wie die Interface-Realisierung in der UML.

      Das SysML::Allocate müsste eigentlich auf UML::DirectedRelationship basieren, aber das Element ist leider abstrakt. UML::Abstraction als Basis ist nicht perfekt, aber auch nicht verkehrt. Es besagt nicht, dass das eine Elemente die Abstraktion des anderen Elements ist, sondern, dass sie sich auf verschiedenen Abstraktionsebenen befinden. Es gibt auch nicht zwingend eine Richtung. Die Beziehung kann auch als bidirektional angesehen werden.

      Dein Hinweis auf das Stereotyp wurde leider verschluckt. Meintest Du PropertySpecificType? Das ist ein Stereotyp eines Classifiers.

      Viele Grüße,
      Tim

      • Carsten Pitz sagt:

        Hallo Tim,
        > Die Blöcke Door und Robot müssen von der Portdefinition Lock spezialisieren, um sicherzustellen, dass sie die geforderten Features auch umsetzen.

        Warum?

        Warum muss ein Robot Block ein (konjugierter) Lock InterfaceBlock sein. Die Beziehung UML::Generalization hat isSubstitutable : Boolean [0..1] = true als Attribut. Somit gilt die Aussage: „Indicates whether the specific Classifier can be used wherever the general Classifier can be used.“. Sprich der Block Robot ist ein drop-in replacement für den InterfaceBlock Lock.

        Das führt mich zur Frage: Hat ein SysML::InterfaceBlock Klassen- oder Schnittstellencharakter?

        Ich bin bisher von einem Schnittstellencharakter ausgegangen. Jedoch ist SysML::InterfaceBlock von UML::Class abgeleitet und ist somit ein UML::BehavioredClassifier. Somit hätte SysML::InterfaceBlock einen Klassencharakter. Ich bin hier verwirrt.

        Mir wäre lieber wenn SysML::Allocate von UML::Dependency abgeleitet wäre, denn eine Abhängigkeit drückt es aus. Aber verbietet die UML von abstrakten Metaklassen abzuleiten?

        In den Diagrammen „SysML 1.6: Szenario 1 für igenschaftsspezifischen Typ“ und „SysML 1.6: Szenario 2 für igenschaftsspezifischen Typ“ hat eine UML::InstanceSpecification den Stereotyp Block. Den Stereotyp Block sowohl für eine Klasse als auch für ein Objekt zu verwenden, halte ich für mehr als unschön.

        /Carsten

        • Tim Weilkiens sagt:

          Der Schnittstellenblock der SysML ist vergleichbar mit der Schnittstelle in UML und die hier verwendete Generalisierung mit der Schnittstellenrealisierungsbeziehung. Das es hier holprig ist, zeigt, dass die UML als Unterbau für die SysML nicht richtig gut passt, weswegen das auch mit der SysML v2 geändert wird.

          Die UML-Abstraktion ist eine spezielle Abhängigkeitsbeziehung. Somit ist die Semantik mit enthalten. Sie ist übrigens nicht abstrakt. Man kann in der UML eine Abhängigkeitsbeziehung modellieren.

          Instanzspezifikationen dürfen das Stereotyp ihres Typs anzeigen. Block und pst sind die Stereotypen des Typs und nicht der Instanzspezifikation selbst.

  2. Carsten Pitz sagt:

    Hallo Tim,
    IBM Rational Software Architect RealTime Edition oder auch Eclipse Papyrus for Realtime Modelle nutzen die UML Port Semantik extrem intensiv. Aus diesem Modellen wird Produktivcode erzeugt. Dieser Code läuft in Mobilfunknetzen mit 99,997% Verfügbarkeit. Egal ob die Infrastruktur von Ericsson, Nokia, ZTE oder Huawei geliefert wurde. Unter der Haube läuft mit diesen Werkzeugen modellierter und generierter Code. Und diese Modelle enthalten jeweils einige Hundert Ports.
    Ich frage mich daher, warum ich ausschließlich von SysML Leuten über Probleme der UML Port Semantik höre. Warum haben RT-UML und xtUML Leute keine Probleme damit?

    /Carsten

    • Tim Weilkiens sagt:

      Weil Systems Engineering etwas anderes ist als Software Engineering.

      Und in einer konkreten methodischen Anwendung der UML oder SysML, ist es auch kein Problem. Wenn in RT-UML und xtUML Sourcecode aus Ports generiert wird, interpretieren sie sie nur als Full-Port. Die UML lässt aber auch die Interpretation der Proxy-Ports zu.

      In meinem Door/Robot-Beispiel sehe ich übrigens auch kein Problem.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ich erkläre mich mit der Datenschutzerklärung und der Datenschutzinformation.