search
menu Navigation
NextGenSysML Teil 4 – Querschnittsanforderungen

Systems Engineering

NextGenSysML Teil 4 – Querschnittsanforderungen

23. Januar 2019

In diesem Blogbeitrag werden die Querschnittsanforderungen für SysML v2 vorgestellt. Es ist Teil einer Blogpostserie über den kommenden neuen Standard SysML v2 und SysML API & Services. Die Blogbeiträge stellen die Anforderungen an den Standard vor, die in den von der OMG veröffentlichten Request for Proposal’s (RFP) definiert sind. Am Ende dieses Beitrags finden Sie eine Liste aller Beiträge dieser Reihe, einschließlich eines Links zum ersten Beitrag der Reihe, der eine allgemeine Einführung bietet.

Die Querschnittsanforderungen für SysML v2 gelten für alle Modellelemente.Viele von ihnen sind selbstverständlich. Trotzdem müssen sie natürlich spezifiziert werden.

Container

Wir reden viel über Modelle. Das Modell selbst ist ebenfalls ein vom RFP gefordertes Modellelement. SysML v1 hat auch ein Modellelement Model. Es ist ein Container und ein Namensraum für alle Modellelemente.

Ein weiteres wichtiges gefordertes Element ist die Modellbibliothek. Es ist auch bereits Teil der SysML v1.

Sowohl das Modell als auch die Modellbibliothek sind Container für andere Modellelemente. SysML v2 muss auch ein allgemeines Containerelement bereitstellen, d.h., ein Modellelement, das andere Modellelemente enthält. In SysML v1 ist dies ein Paket.

Auf den ersten Blick ähnelt eine Gruppe einem Container. Elemente einer Gruppe sind aber zwar Mitglied der Gruppe, aber nicht existentiell enthalten, und die Gruppe ist kein Namensraum. SysML v2 soll ein Gruppenelement haben und eine Beziehung zwischen einer Gruppe und den Mitgliedern der Gruppe. SysML v1 hat auch ein solches Element namens ElementGroup. Aufgrund der zugrunde liegenden UML sind die Funktionen der SysML v1 ElementGroup allerdings eingeschränkt und nur bedingt praxistauglich.

Modellelemente

Einige Anforderungen für SysML v2 betreffen grundlegende Eigenschaften eines Modellelements wie…

  • … eine eindeutige ID. Dies ermöglicht unter anderem die Zuweisung von URIs und den Zugriff über eine API.
  • … einen Namen und Aliase. Es ist offensichtlich, dass die meisten Modellelemente benannt werden müssen. Einige Elemente benötigen keinen Namen oder der Name ist optional, wie beispielsweise bei manchen Beziehungen. In SysML v1 gibt es keine Möglichkeit, Aliase zu definieren (außer bei Verwendung der Element-Import-Beziehung).
  • … ein Beschreibungsfeld. Ein SysML-v1-Modellierungswerkzeug bietet normalerweise ein Beschreibungsfeld für ein Modellelement an. Es ist jedoch nicht Teil des Standards. Jetzt wird es für die SysML v2 gefordert.
  • … eine Notiz. Es ist ein Text, der beispielsweise eine Navigation zu einem anderen internen oder externen Element oder einfach nur eine textuelle Notiz angibt. Zusätzlich zu einem in einer Notiz enthaltenen Navigationslink muss SysML v2 auch eine separate Navigationsbeziehung zwischen einem Modellelement und einem anderen internen oder externen Element anbieten. Die meisten SysML-v1-Modellierungswerkzeuge bieten bereits solche Hyperlinks, sie sind jedoch noch nicht Teil des Standards.

Eine nicht zwingende Anforderung für SysML v2 fordert ein Wurzelelement, das Features enthält, die für alle anderen Modellelemente gelten. In SysML v1 bzw. UML hat das Metamodell ein solches Wurzelelement, das einfach als Element bezeichnet wird.

Probleme und Risiken

Im Systems Engineering geht es viel um Problemlösungen und Risikomanagement. SysML v2 soll entsprechend Modellelemente für Probleme und Risiken mit geeigneten Attributen bereitstellen.

Beziehungen

Ein weiterer Satz von Anforderungen fordert verschiedene Beziehungen zwischen Modellelementen:

  • Eine generelle gerichtete Beziehung zwischen Modellelementen ohne weitere Semantik. Erweiterungen von SysML können auf dieser Basis ihre spezifischen Beziehungen definieren. SysML v1 bzw. die zugrunde liegende UML bietet keine semantikfreie gerichtete Beziehung. Die allgemeinste ist die Abhängigkeitsbeziehung mit der Abhängigkeitssemantik. Das ist zum Beispiel der Grund für die Verwirrung über die Richtung der Zuordnungsbeziehung (allocate), die auf der Abhängigkeitsbeziehung basiert.
  • Es sollte möglich sein, eine Beziehung aus anderen Beziehungen abzuleiten, z. B. ein Konnektor zwischen zwei Teilen, die von einem Konnektor zwischen verschachtelten Teilen abgeleitet wird. In SysML v1 kostet die Modellierung dieses Zusammenhangs erheblichen Aufwand, und es gibt keine Standardmethode, um die abgeleitete Beziehung zu beschreiben.
  • Eine Abhängigkeitsbeziehung zwischen Modellelementen.
  • Eine Ursache-Wirkung-Beziehung zwischen Modellelementen; SysML v1 hat keine solche Beziehung.
  • Eine Beziehung zwischen Elementen, die auf der einen Seite eine Begründung repräsentieren und auf der anderen Seite die durch die Begründung adressierten Elemente.
  • Eine Beziehung, die angibt, dass Modellelemente andere Modellelemente verfeinern.
  • Eine Beziehung, die angibt, dass Modellelemente konform zu anderen Elementen sind.
  • Eine Zuordnungsbeziehung (allocate) wie in SysML v1.
  • Eine Kopiebeziehung, um die Wiederverwendung von Katalogelementen zu ermöglichen. SysML v1 bietet bereits eine Kopiebeziehung, allerdings nur zwischen Anforderungen.

Variantenmodellierung

Ein heißes Thema in MBSE ist die Modellierung von Varianten. Dies ist zwar bereits mit SysML v1 möglich (z. B. VAMOS), wird jedoch nicht explizit von der Sprache unterstützt und das Fehlen eines Standards ist eine Hürde für die erforderliche Werkzeugunterstützung.

SysML v2 soll Elemente zur Modellierung von Varianten bereitstellen. Die Anforderungen für die Variantenmodellierung sind konform zum Standard ISO / IEC 26550: 2015. Die folgenden Variantenkonzepte werden für SysML v2 gefordert:

  • Variationspunkt zum Markieren von Features, die variieren können.
  • Varianten, die sich auf Variationspunkte beziehen.
  • Variabilitätsausdrücke zum Erstellen gültiger Variantenkonfigurationen, z.B. exclusive-or oder requires Einschränkungen.
  • Variantenbindung zum Verknüpfen einer Variante mit den Variationspunkten.

View und Viewpoints

View und Viewpoints sind ein wichtiges Konzept der Systemarchitektur. Es ist Teil von SysML v1, wird jedoch aus verschiedenen Gründen in der Praxis leider nur selten verwendet.

SysML v2 soll eine View definieren können. Eine konkrete View kann beispielsweise ein Diagramm oder ein generiertes Dokument sein. SysML v2 muss auch die Möglichkeit haben, einen Viewpoint zu definieren, der die Anforderungen einer View auf Basis von Stakeholdern und deren Anliegen festlegt.

Die Konzepte View und Viewpoint sind orientieren sich an dem Standard ISO 42010.

Metadaten

SysML v2 bietet die Möglichkeit, Metadaten auf Modellelemente anzuwenden:

  • eine Version
  • ein Zeitstempel
  • Datenschutz-Marker, z.B. Festlegen einer Sicherheitsklassifizierung.

Der nächste Blogbeitrag behandelt die Anforderungen an Eigenschaften, Werte und Ausdrücke  für die SysML v2.

Frühere Blogbeiträge dieser Reihe:

Geplante zukünftige Blogbeiträge:

  • NextGenSysML Teil 5 – Anforderungen an Eigenschaften, Werte und Ausdrücke
  • NextGenSysML Teil 6 – Strukturanforderungen
  • NextGenSysML Teil 7 – Schnittstellenanforderungen
  • NextGenSysML Teil 8 – Verhaltensanforderungen
  • NextGenSysML Teil 9 – Anforderungen an Anforderungen
  • NextGenSysML Teil 10 – Verifikationsanforderungen
  • NextGenSysML Teil 11 – Analyseanforderungen
  • NextGenSysML Teil 12 – Beispielmodell und Konformitätsanforderungen
  • NextGenSysML Teil 13 – SysML API & Services Übersicht
  • NextGenSysML Teil 14 – API & Services: Architekturanforderungen
  • NextGenSysML Teil 15 – API & Services: Konformitätsanforderungen
  • NextGenSysML Teil 16 – API & Services: Serviceanforderungen

(Übersetzung des Original-Blogposts: https://model-based-systems-engineering.com/2019/01/19/nextgensysml-part-4-cross-cutting-requirements/)


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.