Die Modellierungssprache SysML

Home 9 Sprachen 9 SysML

Einführung in SysML

SysML 1.x ist (abgesehen von BPMN) die wohl bekannteste Modellierungssprache neben der UML. SysML steht für Systems Modelling Language und stellt eine Erweiterung der UML dar. Genaugenommen ist SysML 1.x ein UML-Profil.

Die SysML wurde im September 2007 in der Version 1.0 von der Object Management Group (OMG) publiziert. Die aktuellste SysML Version ist 1.7. Diese wird voraussichtlich auch das letzte Release der 1.x SysML-Familie sein, da aktuell an der SysML 2.0 gearbeitet wird. SysML 2.0 ist nicht mehr als UML Profil realisiert und hat ihre eigene Sprachbasis (Metamodell), den KerML.

Die SysML 1.x basiert auf der UML Sprachfamilie mit ihren 14 Diagramm-Arten, wobei das 14te Diagramm der UML-Profilmechanismus ist, mit dem UML erweitert werden kann. Die SysML 1.x ist so eine Erweiterung. SysML ist allerdings nicht nur ein UML-Profil, sondern auch ein OMG Standard, welcher eine Sub-Menge der UML für SysML (UML4SysML) definiert und über SysML spezifische Stereotypen (zusätzliche Bezeichnungen auf UML Sprach-Elementen) die Sprache UML erweitert.

Der Grund für eine Systems Modelling Language war, dass einige Diagramme der UML sehr auf die Beschreibung von Software-Systemen ausgelegt sind und von der Begrifflichkeit stark an Objektorientierte Software Entwicklung erinnern. Daher wurden einige Modell-Elemente mittels Stereotypen umbenannt und mit TaggedValues, um einige Eigenschaften erweitert. Von den 14 bzw. 13 Diagrammen (wenn das UML-Profil nicht gerechnet wird) wurden 7 übernommen und zwei neue Diagramme hinzugefügt. Die SysML hat also 9 Diagramme im Gegensatz zu UML mit 13 (14 mit UML Profil) Diagrammen.

In der SysML finden wir also einige Diagramme, welche 1:1 von der UML übernommen wurden. Diese sind: das Paket-Diagramm (Package Diagram), Anwendungsfall-Diagramm (UseCase Diagram), das Zustandsautomaten-Diagramm (State Machine Diagram) und das Sequenzdiagramm (Sequence Diagram).

Das UML Klassendiagramm, das UML Kompositionsstrukturdiagramm und das UML Aktivitätsdiagramm wurden mittels UML-Profile erweitert und durch in der SysML Spezifikation definierten Constraints eingeschränkt.

Neben diesen UML Diagrammen gibt es in der SysML auch zwei gänzlich neue Diagramme, das Anforderungsdiagramm (Requirements Diagram) und das Parametrische Diagramm (Parametric Diagram).

UML-Diagramme

Diagramme sind wichtige Elemente in der UML. Informieren Sie sich hier über alle Diagramm-Arten im Überblick.

UML Diagramme mit Erweiterungen

SysML zum Beschreiben von Domänenmodellen

Block-Definitions-Diagramm (BDD)

Das UML Klassen-Diagramm heißt nun Block-Definitions-Diagramm. Die wesentliche Erweiterung ist die Einführung des Stereotypes «block» für die UML Klasse. Wir sprechen also nicht mehr von Klassen, sondern von Blöcken. Der Block entspricht dabei mehr dem Verständnis eines System-Ingenieures oder -Ingenieurin.

Eine Erweiterung in der SysML ist, dass Schnittstellen mittels UML Ports (Interaktionspunkte) genauer spezifiziert werden können und damit der stoffliche Austausch zwischen Systemen und Systembestandteilen genauer und formaler beschrieben werden kann.

Wir können z. B. definieren, dass ein bestimmter Stoff (Luft, Flüssigkeit, spezielle Kraftstoffe, Elektrizität, etc.) hinein oder hinaus fließen.

Die Flussrichtung wird dabei mit sogenannten FlowProperties definiert. Ein Property ist dabei eine Eigenschaft, welche in einem Block enthalten sein kann. Der Typ des Properties definiert, um was es sich dabei handelt. Dabei kann der Typ ein anderer Block sein oder ein DataType Element, welcher wiederum genauer spezifiziert sein kann.

Die Bestandteile des PowerSubsystem mit simplen Blöcken, ohne ihre Ports anzuzeigen.

Mit dem BDD beschreiben wir z. B. den strukturellen Aufbau eines Systems, dabei gibt das SysML BDD nicht vor welche Sicht eingenommen werden soll, diese wird durch die eine spezielle Methode definiert, z. B. ob ein BDD eine logische Sicht auf das System, eine physische Sicht oder eine Software-Sicht bzw. eine Kombination davon beschreibt. Ja, mit SysML können auch (Software)-Systeme beschrieben werden, genauso wie die UML auch für die allgemeine Beschreibung von Systemen verwendet werde kann, mit den Einschränkungen die durch die SysML ergänzt wurden.

Die Bestandteile des PowerSubsystem mit simplen Blöcken, ohne ihre Ports anzuzeigen.

Der PowerControlUnit Block mit angezeigten Ports, manche sind durch Blöcke mit FlowProperties typisiert, daher zeigen sie Pfeile für dir Fließrichtung. Diese Ports können im IBD ebenfalls an Properites vom Typ PowerControlUnit angezeigt und mit anderen Ports oder Properties verknüpft werden.

Internes-Block-Definitions-Diagramm (IBD)

Das Interne Bock-Definitions-Diagramm ist eine Erweiterung des UML Kompositionsstruktur Diagramms. In der Regel werden BDD und IBD in der SysML als zwei Seiten einer Medaille betrachtet (Black-Box und White-Box Sicht des Systems) und kommen in der Regel immer beide vor.

Mit dem BDD definieren wir die Bauteile (Typen) in unserem System. Mit unterschiedlichen Beziehungen (Generalisierung (= Vererbung), Komposition & Aggregation (= Teil-Ganzes-Beziehung) beschreiben wir wie ein System aus anderen Systemen besteht.

Die interne Verdrahtung der Bauteile eines Systems wird im IBD vorgenommen. Für jede Aggregations-/Kompositions-Beziehung im BDD erhalten wir in SysML ein Property-Element, welches als konkreter Platzhalter für den Block zu sehen ist, welcher mit Aggregation/Komposition im BDD verbunden ist. In einem Block können somit mehrere Properties vom selben Typ enthalten sein, wenn im BDD mehrere Aggregations-, bzw. Kompositions-Beziehungen vorhanden sind.

Kompositions-Beziehungen führen dabei zu Properties mit durchgezogenem Rahmen und Aggregations-Beziehungen zu Properties mit strichliertem Rahmen.

Properties haben in der Regel einen Namen, einen Doppelpunkt, gefolgt vom Typ des Properties (<PropertyName> : <TypName>), in der Regel ist der Typ ein anderer Block aus dem BDD. Der Name des Properties wird im BDD als Name am Ende der Aggregation-/Kompositions-Beziehung angezeigt. Dadruch ist das BDD und das IBD jeweils eine Sicht auf das Gesamtsystem, welche sich gegenseitig synchronisieren.

 

Hat ein Block Ports (kleine Rechtecke am Rahmen), können diese auch an den Properties angezeigt werden, um damit auf die Interaktionspunkte der Blöcke zuzugreifen, wenn diese in einem anderen Block verwendet werden (als Property typisiert mit einem Block mit Port). Z. B. hat die PowerControlUnit einige Ports, welche im IBD ebenfalls angezeigt werden können.

Wurde der Port mit einem Block typisiert, der wiederum FlowProperties enthält, zeigt der Port eine Richtung [<] [>] oder [<>]. Letzteres bedeutet, dass die durch das FlowProperty definierte „Gut“ hinein und hinaus fließt oder das unterschiedliche Dinge hinein oder hinaus fließen.

Aktivitäts-Diagramm

Das SysML Aktivitätsdiagramm ist im Kern nicht angepasst und funktioniert genauso wie das UML Aktivitätsdiagramm. Es gibt lediglich einige Erweiterungen durch einigen Stereotypen, um eine bessere Kontrolle von Flüssen im Aktivitätsdiagramm zu errechen. Wir können in SysML Aktivitätsdiagrammen z. B. Wahrscheinlichkeiten bei den Flüssen (ObjectFlow) angeben, optionale Flüsse definieren und Kontinuierliche Flüsse genauer beschreiben.

Neue Diagramme in der SysML 1.x

Anforderungs-Diagramm

In der UML gibt es kein eigenes Modell für Anforderungen (Requirements). Das einzige Modell, welches dafür herangezogen werden kann, ist das Anwendungsfalldiagramm (Use Case Diagram).

Mit Use Cases beschreiben wir funktionale Anforderungen für unterschiedliche Stakeholder, welche durch UML Akteure beschrieben werden. Der Use Case, abhängig vom System-Kontext, beschreibt dabei den Sinn und Zweck des Systems.

Möchten wir allerdings nicht funktionale Anforderungen oder funktionale Anforderungen beschreiben, welche nicht unbedingt den primären System-Zweck beschreiben, fehlt in der UML ein Modell.

Im Enterprise Architect (EA) gab es immer schon ein Anforderungs-Modell. In der SysML ist dieses nun auch standardisiert und ebenfalls im EA verfügbar.

Mit dem Anforderungsmodell können wir vor allem textuelle Anforderungsbausteine definieren und diese mit den in der SysML verfügbaren Beziehungen verknüpfen, um damit Aussagen und somit strukturiert Informationen in unser Modell einzupflegen, um diese später automatisch verarbeiten zu können. Damit kann uns das Modell interessante Fragestellungen beantworten.

Die SysML bietet einige spezielle Beziehungen, die zwischen Requirements-Elementen verwendet werden.  Dabei müssen nicht alle verwendet werden. Die wichtigsten Beziehungen zwischen Anforderungen ist die «derivReqt» Beziehung, die aussagt, dass eine Anforderung aufgrund einer anderen Anforderung vorhanden ist. Wird das Ziel der «derivReqt» Beziehung geändert, hat dies eine Auswirkung auf alle davon abgeleiteten Anforderungen.

SysML Anforderungen können auch mit dem restlichen Modell verknüpft werden, und erlauben dadurch eine vollständige Traceability von der Stakeholder-Anforderung bis zu dem gewünschten System-Level, welches im Modell abgebildet werden soll.

Weitere wichtige Beziehungen sind dabei die «refine» Beziehung, mit der wir eine Anforderung durch ein anderes Modell-Element genauer beschreiben können. Damit können wir eine Brücke zwischen Textbaustein und Model Based Requirements schlagen.

Die «verify» Beziehung erlaubt es Test-Fälle («testCase») Element mit Anforderungen zu verbinden. Der Test-Fall beschreibt wie die Anforderung mit der er verknüpft ist getestet werden soll.

Die «satisfy» Beziehung beschreibt die Umsetzung einer Anforderung durch ein anderes Modell-Element. So kann z.B. eine Anforderung durch einen oder mehrere Blöcke umgesetzt werden.

Parametrisches-Diagramm

 Das Parametrische (Parametric) Diagramm ist ein gänzlich neues Modell und eine Spezialisierung von SysML Blöcken. Der SysML Block heißt hier ConstraintBlock (Block mit Stereotyp «constraint») und definiert eine Art Gleichung- der auch als Funktion gesehen werden – mit Eingabe und Ausgabe Variablen (Values). Die Variablen werden in einer Gleichung verwendet.

«constraint» Blöcke können nun im Parametirc Diagramm instanziiert werden und werden Constraint Properties genannt. Mehrere Constraint Properties können nun zu einem Funktionsgraphen zusammengebaut werden.

Durch Simulationsmöglichkeiten können Parametric Diagramme ausgewertet werden. Dabei können unterschiedliche Sets an Variablen Konfigurationen (der Eingabedaten) definiert werden. Die Simulation berechnet anschließend die Ausgabedaten.

Zum Berechnen können auch mathematische Solver wie Matlab-Simulink oder Modellica verwendet werden.

Einfaches Parametic Diagramm mit einem Constraint Property

Durch die Kombination mehrere Constraint Properties in einem Parametric Diagramm, können wir komplexere Systeme beschreiben. Die einzelnen Constraint Blöcke dienen hierbei als Bibliothek und die Verwendung als Constraint Property in einem Parametric Diagramm als einfache Beschreibung eines komplexen Systemverhaltens.

SysML mit Enterprise Architect

In diesem Basis-Training lernen Sie die Modellierungssprache Systems Modelling Language (SysML) anhand praktischer Beispiele mit dem Tool Enterprise Architect verstehen und einzusetzen.

t

FAQs zu SysML

Was ist SysML und wofür wird die Sprache benutzt?

SysML (Systems Modeling Language) wurde als grafische Modellierungssprache speziell für die Systemtechnik entwickelt. 2007 wurde SysML 1.0 durch die OMG offiziell veröffentlicht, 2023 erfolgte die Vorstellung der Beta Version der SysML v2. SysML ist eine Erweiterung und Anpassung der UML (Unified Modeling Language).

Da SysML für die Modellierung komplexer Systeme zum Einsatz kommt, wird sie vor allem in Bereichen wie Luft- und Raumfahrt, Automobilindustrie, Medizintechnik oder Verteidigung verwendet.

Die Hauptanwendungsbereiche der SysML sind:

  • Anforderungsanalyse: Modellierung und Verknüpfung von Systemanforderungen
  • Systemarchitektur: Definition der Systemkomponenten mit ihren Beziehungen und Schnittstellen
  • Systemverhalten: Modellierung des dynamischen Verhaltens von Systemen durch Aktivitäts-, Zustands- und Sequenzdiagramme
  • Kommunikation: SysML Modelle werden zur Kommunikation zwischen verschiedenen Disziplinen (z. B. Mechanik, Elektronik, Software) genutzt

Wie integriert man SysML- und UML-Modelle in ein Systems Engineering Projekt?

Um mit SysML- und UML-Modellen in einem Systems Engineering Projekt zu arbeiten, benötigt man einen methodischen Ansatz.

Finden Sie hier einige praktische Tipps zur Umsetzung dieser Integration:

  • Anwendungsfälle und Modellierungsziele: Wie beim Start jedes Modellierungsprozesses üblich, sollten die Anwendungsfälle und Ziele des Projekts klar definiert werden. So lassen sich die Stärken der beiden Sprachen am besten nutzen.
  • Diagrammtypen: Je nach Anforderungen im Projekt wählen Sie nun die relevanten Diagrammtypen aus den beiden Sprachen aus
  • Metamodell: Das gemeinsame Metamodell definiert die Beziehungen der Elemente zwischen SysML- und UML-Modellen
  • Werkzeugauswahl: Moderne Modellierungstools wie Enterprise Architect unterstützen sowohl SysML als auch UML und bieten Mechanismen zur Integration beider Modelltypen
  • Systemarchitektur: Die Systemarchitektur wird meist in SysML modelliert, die dafür Blockdefinitionsdiagramme (BDD) und interne Blockdiagramme (IBD) verwendet.
  • Softwaremodellierung: Zur detaillierten Modellierung von Softwarekomponenten wird UML verwendet, es kommen dafür meist Klassen-, Sequenz- und Aktivitätsdiagramme zum Einsatz
  • Verknüpfung: In SysML erstellte Anforderungen lassen sich mit den entsprechenden Softwarekomponenten (UML) verknüpfen
  • Dokumentation: Dokumentieren Sie die Modelle und deren Beziehungen ausführlich, um eine klare Kommunikation im Team zu gewährleisten
  • Integration: Durch die enge Einbindung der Modellierung in den Entwicklungsprozess stellen Sie sicher, dass immer der aktuelle Stand des Projekts abgebildet ist

Was ist die SysMLv2 und welche Neuerungen bringt sie?

SysMLv2 (Systems Modeling Language Version 2) wurde in der Beta Version 2023 vorgestellt. Sie soll die Begrenzungen von SysML aufheben und damit die Modellierung komplexer Systeme vereinfachen.

Die wichtigsten Verbesserungen in SysMLv2:

  • Syntax und Semantik: Die konsistentere Syntax und Semantik soll die Modellierung weniger fehleranfällig machen
  • Erweiterte Diagrammtypen und Modellierungskonzepte
  • Modularität und Wiederverwendbarkeit werden besser unterstützt
  • Bessere Automatisierungsmöglichkeiten sollen den Modellierungs- und Verifikationsprozess effizienter gestalten
  • Standardisierte Schnittstellen zur Integration mit anderen Technologien