Systems Engineering mit SysML/UML E-Book

Tim Weilkiens

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2014

Seitenzahl: 524

Beschreibung

Systeme bestehen aus Bausteinen unterschiedlicher Disziplinen wie Hardware, Software oder Mechanik. Der Fortschritt ermöglicht immer komplexere Systeme, der Markt fordert immer schnellere Entwicklungszeiten, und die Globalisierung führt zu international verteilten Entwicklungsteams. Das Systems Engineering mit seiner ganzheitlichen, disziplinenübergreifenden Sichtweise hat in diesem Umfeld eine herausragende Bedeutung. Das Buch zeigt anhand des pragmatischen Modellierungsvorgehens SYSMOD und eines durchgängigen Fallbeispiels die Methoden der Systemmodellierung mit der Systems Modeling Language (OMG SysML (TM)). Den Sprachen SysML und UML (TM) (auf der SysML basiert) ist jeweils ein eigenes Kapitel gewidmet, das alle Sprachelemente behandelt. Ein weiteres Kapitel beschreibt die Spracherweiterung der SysML (Profil) für SYSMOD. Im Anhang befinden sich eine Übersetzung der englischen Begriffe und ein umfangreiches Glossar. Die 3. Auflage basiert auf der aktuellen SysML-Version 1.4, die einige Neuerungen mitbringt. Ebenso enthält sie auch die Elemente der Vorgängerversion 1.3, die es zum Zeitpunkt der 2. Auflage noch nicht gegeben hat. SYSMOD adressiert jetzt explizit die Architekturtypen: Basisarchitektur, logische Architektur, physische Produktarchitektur und funktionale Architektur. Weiter wurde ein neues Kapitel zur Vorbereitung auf die OCSMP-(OMG Certified Systems Modeling Professional-)Zertifizierung der OMG aufgenommen. "Zusammen mit der weltweiten Systems-Engineering-Zertifizierung (inklusive SysML) ist jetzt ein guter Zeitpunkt, um geradewegs zu starten, die SysML zu lernen und anzuwenden. Dieses Buch ist eine fantastische Unterstützung für dieses Vorhaben." (Aus dem Geleitwort von Richard Mark Soley, OMG)

Leseprobe

Tim Weilkiens ist Geschäftsführer der Beratungsfirma oose Innovative Informatik GmbH. Seine thematischen Schwerpunkte sind die Modellierung und Entwicklungsprozesse für Systeme. Er ist für oose GmbH Repräsentant bei der OMG, ist u. a. Koautor der SysML-Spezifikation und Koentwickler des Zertifizierungsprogramms OMG Certified Systems Modeling Professional (OCSMP).

Sie erreichen ihn unter [email protected].

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.de/plus

Systems Engineering mit SysML/UML

Anforderungen, Analyse, Architektur

3., überarbeitete und aktualisierte Auflage

Tim Weilkiens

Tim Weilkiens

[email protected]

Lektorat: Christa Preisendanz

Copy Editing: Ursula Zimpfer, Herrenberg

Satz: Tim Weilkiens

Herstellung: Frank Heidt

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN

Buch 978-3-86490-091-4

PDF 978-3-86491-543-7

ePub 978-3-86491-544-4

3. Auflage 2014

Copyright © 2014 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Copyright-Hinweis für den Verlag

Der Inhalt, die Notationsübersichten für die Umschlaginnenseiten und das Glossar ist weitestgehend durch Mitarbeiter der oose GmbH während dessen bezahlter Arbeitszeit entstanden oder basiert auf anderen Materialien der oose GmbH und sind somit Eigentum der oose GmbH. Ich erteile jedoch als Geschäftsführer der oose GmbH dem dpunkt-Verlag hiermit das unbegrenzte und nicht-exklusive Nutzungsrecht für die Verwendung im nachfolgenden Buch.

Tim Weilkiens

Copyright-Hinweis für das Buch

BPMN, ReqIF, OMG SysML, OMG Systems Modeling Language, the OMG SysML logo, OCSMP, UML, Unified Modeling Language and the UML logo are trademarks or registered trademarks of the Object Management Group, Inc. in the United States, the European Union and other countries.

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort zur 3. Auflage

Seit der 2. Auflage sind nun 6 Jahre vergangen. In dieser Zeit hat sich die Sprache SysML, das Vorgehen SYSMOD und die MBSE-Disziplin (Model Based Systems Engineering) weiterentwickelt. Das Thema unterliegt einer hohen Dynamik, der das Medium Buch nur schwer folgen kann. Das war für mich der Grund, vor ein paar Jahren den MBSE-Blog unter www.model-based-systems-engineering.com zu starten. Neue Erkenntnisse und Weiterentwicklungen kann ich dort zeitnah publizieren. Jetzt ist aber auch ein guter Zeitpunkt, den aktuellen Stand kompakt und zusammenhängend in diesem Buch festzuhalten. Die wesentlichen Änderungen der 3. Auflage sind:

Das Buch basiert auf der aktuellen SysML-Version 1.4, die einige Neuerung mitbringt. Ebenso enthält es auch die Elemente der Vorgängerversion 1.3, die es zum Zeitpunkt der 2. Auflage noch nicht gegeben hat.

SYSMOD adressiert jetzt explizit die Architekturtypen: Basisarchitektur, logische Architektur, physische Produktarchitektur und funktionale Architektur.

Diverse kleinere Anpassungen von SYSMOD, die auf Erfahrungen und Feedbacks aus der Praxis basieren, sind enthalten.

Ein neues Kapitel zur Vorbereitung auf die OCSMP-Zertifizierung der OMG ist hinzugekommen.

Feedbacks, die ich zur 2. Auflage erhalten habe, sind eingearbeitet. Vielen Dank an alle diejenigen, die mir eine Rückmeldung gegeben haben.

Ich wünsche Ihnen viel Freude und Erkenntnisse beim Lesen und freue mich auf Ihre Rückmeldungen.

In einem fliegenden Verband namens Fairchild Dornier 328-110irgendwo über Deutschland.April 2014, Tim Weilkiens

Vorwort zur 2. Auflage

Im April 2006 ist die OMG Systems Modeling Language (OMG SysMLTM) veröffentlicht und im September 2007 offiziell von der Object Management Group (OMG) verabschiedet worden.

Die Erstauflage dieses Buchs ist kurz nach der Veröffentlichung der SysML erschienen. Anfang 2008 habe ich eine aktualisierte Version des Buchs auf Englisch beim Morgan Kaufmann Verlag in der OMGPress publiziert. Bis heute ist es weltweit das einzige Buch über SysML. So sehr mir das Monopol natürlich zugute kommt, so sehr wünsche ich den Anwendern aber auch die Vielfalt durch weitere SysML-Bücher. Nur so kann sich die Sprache erfolgreich entfalten.

Es gibt bereits viele Projekte, die SysML verwenden bzw. den Einsatz der Sprache planen und vorbereiten. Erfahrungen und Best Practices, die ich als Berater in diesen Systems-Engineering-Projekten gesammelt habe, sind Teil der Neuerungen in dieser 2. Auflage des Buchs. Während der Arbeit an der Neuauflage arbeitete ich auch in der SysML Revision Task Force der OMG an der nächsten SysML Version 1.1. Sie wird Anfang 2009 erscheinen. Aus dieser Arbeit stammen ebenfalls ganz aktuelle Informationen, die Sie in diesem Buch finden.

Konkrete Themen aus Projekten die SysML betreffen und die ich in der neuen Auflage des Buchs aufgenommen bzw. vertieft habe, sind Heuristiken zur Anforderungsmodellierung (Abschnitt 2.5.2), Variantenmodellierung (Abschnitt 2.10.2), Modellmanagement (Abschnitt 2.10.1) und die Vorstellung eines Intensitätsmodells (Abschnitt 2.10.7).

Es gibt aus dieser Arbeit auch Themen, die ich hier nicht oder nur am Rande erwähne, da sie den Rahmen des Buchs sprengen würden oder da sie noch zu unreif für eine Publikation dieser Art sind. Dazu zählt beispielsweise die Integration von Modellen. Ebenso wie das Systems Engineering eine Querschnittsfunktionalität über alle Disziplinen des Projekts bildet, hat auch das SysML-Modell diese Rolle inne. Es beschreibt die ganzheitliche Systemarchitektur und hat zur Aufgabe, die Modelle der einzelnen Disziplinen wie Software und Mechanik zu integrieren. Teil dieser Thematik sind Datenstandardformate wie XMI und ISO AP-233.

Weitere Themen sind die Anwendung des Zusicherungsdiagramms und modellbasierte Simulationen.

Bei dem Aufsehen, für das SysML bisher gesorgt hat, darf nicht vergessen werden, dass SysML nur eine Sprache ist. Sie ist nur ein Baustein in der Systementwicklung und nutzlos, wenn ein entsprechendes Vorgehen fehlt. Insbesondere der Mensch selbst ist ein wesentlicher Faktor für den Projekterfolg (Stichwort: Soft Skills).

Ich habe SysML oft als Türöffner für Systems-Engineering-Prozesse erlebt. Projekte, die SysML als direkten Problemlöser gesehen haben, sind über die ersten Gehversuche mit der Sprache auf mangelhafte oder fehlende disziplinenübergreifende Prozesse und Projektstrukturen aufmerksam geworden. Da lagen die eigentlichen Probleme. Die Folge bzw. ist die Einführung des Systems Engineering als explizite Disziplin im Projekt oder Unternehmen. Die ersten positiven Synergieeffekte traten dann schnell auf.

Der Erfolg der SysML zeigt, dass hier der richtige Weg eingeschlagen worden ist. Wir stehen erst am Anfang des Weges: »This is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.«(Winston Churchill)

In einem fliegenden Verband namens A300 irgendwo über Deutschland.Juni 2008, Tim Weilkiens

Geleitwort von Richard Mark Soley

Laut Flugzeugbauer Boeing hat das Flugzeug vom Typ 747-400 ein maximales Bruttostartgewicht von fast 400.000 kg (einschließlich einer durchschnittlichen Anzahl von 416 Passagieren, einer Frachtladung von 171 Kubikmetern und über 200.000 kg Sprit). Vier Riesenmotoren treiben den Vogel mit bis zu 88% Schallgeschwindigkeit über unglaubliche Entfernungen – bis zu 13.500 km – an, ohne nachtanken zu müssen. Allein die Länge des Flugzeugs (45 m) ist länger als der gesamte Erstflug der Gebrüder Wright.

Doch diese erstaunlichen Zahlen, die nach 30 Jahren durch noch größere Passagierflugzeuge in den Schatten gestellt werden, sind nichts im Vergleich zur Komplexität des Systems, bestehend wiederum aus Systemen (System of Systems), aus denen sich die Boeing 747-400 zusammensetzt. Das Elektrosystem des Flugzeugs umfasst etwa 274 km Kabel. Die hochfesten Aluminium- und Titanteile arbeiten sowohl im Stillstand als auch unter Hitzeeinwirkung durch das enorm schnelle Durchströmen der Luft. Backup-Systeme halten die Navigation und lebenswichtige Systeme in Gang für den Fall, dass das Hauptsystem ausfällt. Sogar das Unterhaltungselektroniknetz in der Kabine gehört zu den komplexeren Systemen auf der Welt. Die Boeing 747-400 umfasst etwa sechs Millionen Teile, wovon fast die Hälfte einfache Befestigungselemente wie Schrauben und Muttern sind. Kein Wunder, dass ein Boeing-Sprecher einmal witzelte: »Wir betrachten eine 777 als Sammlung von Teilen, die im geschlossenen Verband fliegen.« Als Vielflieger hoffe ich inständig, dass dieser »geschlossene Verband« eingehalten wird!

Alle diese Fakten spiegeln eine Tatsache wider, die jeder Ingenieur kennt: Komplexität ist schwierig zu handhaben, und die meisten interessanten Systeme sind komplex. Noch schlimmer: Die Zusammensetzung von Systemen zu Systemen, die wiederum aus Systemen bestehen, z. B. die Elektro-, Hydraulik-, Antriebs- (Hub-, Schub- und Dauerbetrieb), Navigations- und weiteren Systeme des Flugzeugs in unserer Analogie, tendieren dazu, neue Komplexitäten in Form unerwarteter Teileüberlappung und unerwarteten Verhaltens von zuvor sich wohlverhaltenden Systemen einzuführen.

Als Folge der steigenden Komplexität von Systemen gibt es einen dringenden Bedarf, Komponentensysteme so beschreiben zu können, dass sich die Designs leicht unter Designerteams austauschen lassen. Eine gemeinsame Sprache ist eine entscheidende Komponente der Design-Methodologie eines jeden Systems oder Prozesses. Dabei spielt es keine Rolle, ob es sich um ein elektrisches, mechanisches oder chemisches System oder um Software handelt. Und wenn diese gemeinsame Sprache auf einer bereits existierenden basiert, wird das Team, das die Designs gemeinsam nutzt, rascher in der Lage sein, die Designaufgaben – und letztlich die noch anspruchsvolleren, langfristigen Wartungs- und Integrationsaufgaben – besser, schneller und billiger zu bewältigen.

Dieser Denkprozess führte die Object Management Group (OMG) mit ihren Hunderten von Mitgliedsfirmen aus aller Welt zur Entwicklung und Pflege der Systems Modeling Language (SysML). Der offene Standard weist eine Reihe positiver Merkmale auf:

Die Sprache basiert auf einer Erweiterung der OMG-eigenen Unified Modeling Language (UML). Softwareentwickler, die mit UML vertraut sind, können daher leicht auf SysML umsteigen, und Werkzeugentwickler, die mit UML-Werkzeugen arbeiten, können SysML problemlos unterstützen.

Die Sprache ist grafisch. Mich verblüfft es immer wieder, dass Softwareentwickler ihr Design mithilfe von Grafikelementen austauschen, dann aber z. B. »C++-Code« schreiben, um dieses Design auf den Computer zu übertragen. Ahnlich arbeiten Fertigungstechniker die Einzelheiten einer Produktfamilie mithilfe von Graphen, Kästen und Linien aus, um sie dann letztlich in Textform zu umreißen, z. B. mit PDES/STEP. Grafische Sprachen eignen sich naturgemäß für Designs und werden seit Tausenden von Jahren benutzt, wie etwa alte Gebäude- und Schiffsblaupausen, elektrische Schaltbilder usw. belegen.

Die Sprache hat viele Implementierungen. Internationale Standards sind einfach nicht das Papier wert, auf dem sie gedruckt werden (oder den Festplattenplatz, den sie belegen), falls man sie nicht implementiert. Noch bevor SysML Anfang 2006 in der endgültigen Spezifikation verfügbar war, kündigten bereits mehrere Firmen die Implementierung des Standards an.

Wichtig ist dabei, dass es sich bei SysML nicht einfach nur um eine weitere Modellierungssprache für die Softwareentwicklung handelt. Software ist heute in nahezu allen komplexen Systemen zwar eine wichtige Komponente, aber fast nie die einzige. Flugzeuge, Züge und Autos beinhalten Software ebenso wie Gebäuderegelungseinrichtungen oder Chemiewerke. Sie alle umfassen aber auch u. a. Haustechnik-, Hydraulik- und Elektrosysteme, die es aufeinander abzustimmen und übergreifend zu entwerfen gilt. Ebenso müssen die komplexen Systeme, die von Menschen und automatisierten Prozessen genutzt werden sollen, auch entsprechend geplant werden. Nur so lassen sie sich sachgerecht und sinnvoll nutzen (sowie warten und im Hinblick auf neue Anforderungen in künftige Systeme integrieren). Bei all diesen designübergreifenden Fragen muss berücksichtigt werden, dass alle komplexen Systeme in mehreren Konfigurationen verfügbar sind, je nach Anforderung des Einsatzumfelds, der Mitarbeiterqualifikation und zahlreicher weiterer Variablen.

Das ist der Fokus von SysML, einer Sprache zur Modellierung all dieser unterschiedlichen Faktoren im Verlauf der Entwicklung komplexer Systeme und aus Systemen bestehender Systeme. Der Zweck ist dabei nicht das Verbergen der Komplexität jener Systeme, sondern vielmehr ihre Offenlegung und Kontrolle angesichts sich ständig ändernder Geschäftsanforderungen und Infrastrukturen.

SysML wird wahrscheinlich nicht die letzte Sprache für die Entwicklung komplexer Systeme sein. Durch den schnellen Wandel in den meisten Entwicklungs- und Konstruktionsbereichen (und der damit einhergehenden Einführung völlig neuer Bereiche, wie z. B. der Biotechnik) dürfte sich auch die Spezifikationssprache selbst ändern. Für einen Ingenieur sollte das keine große Überraschung sein, denn viele langlebige Spezifikationssprachen haben sich im Laufe der Zeit gewandelt. Ein einfaches Beispiel: Gebäudebaupläne gibt es schon seit mehreren Hundert Jahren, diejenigen aus der Zeit bis etwa 1880 hatten aber kein internationales Symbol für elektrische Anschlüsse, da dieses Merkmal damals noch nicht existierte. Sprachen ändern sich, um sich an geänderte Konstruktionsanforderungen anzupassen. Vorteilhaft bei SysML ist, dass die Sprache auf einer Metamodell-Infrastruktur basiert – der Meta Object Facility (MOF), die ebenfalls von der OMG standardisiert wurde – und folglich für künftige Änderungen ausgelegt wurde. Die Technologie kann auch benutzt werden, um bestehende Designs, die in älteren Modellierungssprachen, wie etwa IDEF (eine häufig in der Luftfahrt und vielen anderen Bereichen verwendete Sprache), geschrieben wurden, umzuwandeln und zu integrieren.

Womit sich der Kreis schließt: Wir sind wieder angelangt bei der Sammlung von sechs Millionen Teilen, die im geschlossenen Verband fliegen. Die Aussicht, eine derart große Teilesammlung mit dem entsprechenden Bedarf an Menschen und Einrichtungen, Hardware und Software, Hydraulik, Elektrik und Navigation ohne eine gemeinsame Designsprache entwickeln zu können, die den konstanten Wandel von Komponentensystemen berücksichtigt, ist gleich null. SysML wurde eigens für diesen Bedarf ausgelegt. Die Sprache bewährt sich bereits in der Praxis für winzige, eingebettete Controller für Robotersysteme bis hin zu riesigen Industriekomponenten.

Lernen Sie also die Sprache und haben Sie Spaß dabei! Sie ist zwar nicht ganz einfach – komplexe Probleme bedürfen eben komplexer Lösungen -, aber logisch und beruht auf guten Designpraktiken. Und sorgen Sie letztlich dafür, dass jene Teile im geschlossenen Verband fliegen!1

Richard Mark Soley, Ph.D.Chairman and Chief Executive Officer Object Management Group, Inc.30. Mai 2006

Zusatz zur 3. Auflage

Jede Metrik darüber, wie gut ein Standard angenommen wird, muss nicht nur berücksichtigen, wie viele Anwender mit dem Standard arbeiten (die Anwender-Community), sondern auch wie enthusiastisch die Community ist, die den Standard entwickelt. SysML ist erfolgreich in beiden Metriken. Es gibt regelmäßige Aktualisierungen des Standards, die die Bedürfnisse und Anregungen von Tausenden von Anwendern aus aller Welt berücksichtigen. Der Wälzer, den Sie gerade in Ihren Händen halten, deckt die Änderungen der SysML bis zur Version 1.4 ab sowie Änderungen an der SYSMOD-Methodik des Autors zur Entwicklung realer, komplexer Systeme (und denken Sie daran, trotz unserer Vorliebe für Ockhams Rasiermesser, komplexe Probleme erfordern oft komplexe Lösungen).

SysML ersetzt ältere Systems-Engineering-Notationen mit einer Notation, die mit Sprachen und Methoden aller Disziplinen von der Softwareentwicklung bis zur Anlagenplanung integriert werden kann und von der echte Verkehrsflugzeuge (oder wie ich damals schrieb, »eine Ansammlung von Teilen, die in einem geschlossenen Verband fliegen«) abhängen. Zusammen mit der weltweiten Systems-Engineering-Zertifizierung (inklusive SysML) ist jetzt ein guter Zeitpunkt, um geradewegs zu starten, die SysML zu lernen und anzuwenden. Dieses Buch ist eine fantastische Unterstützung für dieses Vorhaben.

Richard Mark Soley, Ph.D.Chairman and Chief Executive Officer Object Management Group, Inc.Circa 32.000 Fuß über Nebraska, U.S.A. 14. Januar 2014

Inhaltsverzeichnis

1       Einleitung

1.1     Vorweg

1.1.1     Passt das Buch zu mir?

1.1.2     Was bietet mir das Buch?

1.1.3     Wie ist das Buch entstanden? Und danke!

1.1.4     Wie lese ich das Buch?

1.1.5     Wohin geht der Weg?

1.2     Systems Engineering

1.2.1     Was ist Systems Engineering?

1.2.2     Systems-Engineering-Prozesse

1.2.3     Der Systems Engineer

1.2.4     Historie des Systems Engineering

1.2.5     International Council on Systems Engineering

1.2.6     Systems Engineering in Deutschland

1.3     Modellbasiertes Systems Engineering (MBSE)

1.3.1     Die Sprachen UML und OMG SysML

1.3.2     BPMN

1.3.3     MATLAB/Simulink

1.3.4     Modelica

1.3.5     Specification and Description Language (SDL)

1.4     Randnotizen

1.4.1     AUTOSAR

1.4.2     Capability Maturity Model Integration (CMMI)

1.4.3     Industrie 4.0

1.4.4     ISO/IEC 15288

1.4.5     Product Lifecycle Management (PLM)

1.4.6     Requirement Interchange Format (ReqIF)

1.4.7     STEP

1.4.8     V-Modell® XT

2       Pragmatischer Modellierungsprozess SYSMOD

2.1     Fallbeispiel

2.2     Die Systemidee

2.3     Systemidee und Systemziele beschreiben

2.4     Basisarchitektur festlegen

2.5     Anforderungen ermitteln

2.5.1     Stakeholder identifizieren

2.5.2     Anforderungen aufnehmen

2.6     Systemkontext modellieren

2.6.1     Systemakteure identifizieren

2.6.2     System/Akteur-Objektfluss modellieren

2.6.3     Systeminteraktionspunkte identifizieren

2.7     Anwendungsfälle modellieren

2.7.1     Anwendungsfälle identifizieren

2.7.2     Anwendungsfälle essenziell beschreiben

2.7.3     Systemprozesse beschreiben

2.7.4     Anwendungsfälle redundanzfrei modellieren

2.7.5     Anwendungsfallabläufe modellieren

2.7.6     Objektfluss modellieren

2.8     Fachwissen modellieren

2.9     Logische Architektur modellieren

2.9.1     System/Akteur-Interaktion modellieren

2.9.2     Systemschnittstellen ableiten

2.9.3     Systemstrukturen modellieren

2.9.4     Zustandsmodell erstellen

2.9.5     Physische Produktarchitektur modellieren

2.10   Randnotizen

2.10.1   Modellmanagement

2.10.2   Variantenmanagement

2.10.3   SYSMOD-Zickzackmuster

2.10.4   Funktionale Architektur

2.10.5   Agiles Systems Engineering

2.10.6   Datenaustauschformate

2.10.7   SYSMOD-Intensitätsmodell

2.10.8   Modellsimulation

2.10.9   Testen

2.10.10 System of Systems (SoS)

2.10.11 Modellierungsmuster

2.10.12 Tod des Akteurs! Lang lebe der Akteur!

3       UML – Unified Modeling Language

3.1     Historie

3.2     Aufbau und Konzepte

3.3     Das Klassendiagramm

3.3.1     Classifier

3.3.2     Klasse

3.3.3     Eigenschaft

3.3.4     Operation

3.3.5     Assoziation

3.3.6     Aggregation und Komposition

3.3.7     Objektspezifikation

3.3.8     Abhängigkeitsbeziehung

3.3.9     Abstraktionsbeziehung

3.3.10   Generalisierung

3.3.11   Signal

3.3.12   Datentypen

3.3.13   Assoziationsklasse

3.4     Das Kompositionsstrukturdiagramm

3.4.1     Eigenschaft

3.4.2     Konnektor

3.4.3     Port

3.5     Das Anwendungsfalldiagramm

3.5.1     Anwendungsfall

3.5.2     Akteur

3.5.3     Enthältbeziehung

3.5.4     Erweiterungsbeziehung

3.6     Das Aktivitätsdiagramm

3.6.1     Aktivität

3.6.2     Aktion und Pin

3.6.3     Aktivitätskante

3.6.4     Aktivitätspartition

3.6.5     Parametermenge

3.6.6     Entscheidung und Zusammenführung

3.6.7     Mengenverarbeitung

3.6.8     Splitting und Synchronisation

3.6.9     Start- und Endknoten

3.6.10   Unterbrechbarer Aktivitätsbereich

3.6.11   Zentralpuffer und Datenspeicher

3.7     Das Zustandsdiagramm

3.7.1     Zustandsautomat

3.7.2     Zustand

3.7.3     Transition

3.7.4     Auslöser und Ereignis

3.7.5     Start- und Endzustand

3.7.6     Pseudozustand

3.8     Die Interaktionsdiagramme

3.8.1     Interaktion

3.8.2     Lebenslinie

3.8.3     Nachricht

3.8.4     Kombiniertes Fragment

3.8.5     Interaktionsreferenz

3.8.6     Zustandsinvariante

3.8.7     Zeitliche Zusicherungen

3.9     Das Paketdiagramm

3.9.1     Paket

3.9.2     Importbeziehung

3.10   Sonstige Modellelemente

3.10.1   Diagrammrahmen

3.10.2   Erweiterungsmechanismus Stereotyp

3.10.3   Informationsfluss

3.10.4   Kommentar

3.10.5   Modell

3.10.6   Zusicherung

4       SysML – Systems Modeling Language

4.1     Historie

4.2     Aufbau und Konzepte

4.3     Das Anforderungsdiagramm

4.3.1     Anforderung

4.3.2     Ableitungsbeziehung

4.3.3     Enthältbeziehung

4.3.4     Erfüllungsbeziehung

4.3.5     Kopiebeziehung

4.3.6     Prüfbeziehung

4.3.7     Verfeinerungsbeziehung

4.3.8     Verfolgungsbeziehung

4.3.9     Testfall

4.3.10   Tabellennotation

4.4     Die Zuteilung

4.4.1     Zuteilungsbeziehung

4.4.2     Zuteilungspartition

4.4.3     Tabellennotation

4.5     Die Blockdiagramme

4.5.1     Systembaustein

4.5.2     Port

4.5.3     Assoziationsbaustein

4.5.4     Bindungskonnektor

4.5.5     Einheit und Basisgröße

4.5.6     Einschränkende Referenz und Pfadendemultiplizität

4.5.7     Objektfluss

4.5.8     Schnittstellenbaustein

4.5.9     Werteverteilung

4.5.10   Wertetyp

4.6     Das Zusicherungsdiagramm

4.6.1     Zusicherungsbaustein

4.7     Das Anwendungsfalldiagramm

4.8     Das Aktivitätsdiagramm

4.8.1     Aktivitätsbaum

4.8.2     Kontrolloperator

4.8.3     Rate

4.8.4     Spezielle Objektknoteneigenschaften

4.8.5     Wahrscheinlichkeit

4.8.6     Zeitliche Zusicherungen

4.9     Das Zustandsdiagramm

4.10   Die Interaktionsdiagramme

4.11   Allgemeine Modellierungselemente

4.11.1   Begründung

4.11.2   Diagrammrahmen

4.11.3   Gruppe

4.11.4   Modellsicht und Standpunkt

4.11.5   Problem

4.11.6   Stakeholder

5       Systems-Engineering-Profil SYSMOD

5.1     Akteurskategorien

5.2     Aktivitäten

5.3     Erweiterte Anforderung

5.4     Spezielle Anwendungsfälle

5.5     Benutzerschnittstelle

5.6     Disziplinenspezifische Elemente

5.7     Gewichtete Beziehungen

5.8     Erweiterter Stakeholder

5.9     System und Subsystem

5.10   Spezielle Systembausteine

5.11   System- und Zusicherungskontextelement

5.12   Systemprozess

5.13   Varianten

5.14   Ziel

6       OMG Certified Systems Modeling Professional (OCSMP)

6.1     Sinn und Unsinn von Zertifizierungen

6.2     Der Zertifizierungsprozess

6.3     Das OCSMP-Zertifizierungsprogramm

6.4     Andere Zertifizierungsprogramme

6.5     OCSMP Model User

6.5.1     OCSMP-Basiselemente der SysML

6.5.2     Coverage-Map OCSMP Model User

6.5.3     Referenzen

6.5.4     Beispielfragen

6.6     OCSMP Model Builder Fundamental

6.6.1     Coverage-Map OCSMP Model Builder Fundamental

6.6.2     Referenzen

6.7     OCSMP Model Builder Intermediate

6.7.1     Coverage-Map OCSMP Model Builder Intermediate

6.7.2     Referenzen

6.8     OCSMP Model Builder Advanced

6.8.1     Coverage-Map OCSMP Model Builder Advanced

6.8.2     Referenzen

A       Anhang

A.1     Glossar

A.2     SysML auf Deutsch

A.3     Veraltete Konzepte der SysML

A.3.1    Standardport und Objektflussport

A.3.2    Modellsicht und Standpunkt

A.3.3    Einheit

A.4     Lösungen

Literaturverzeichnis

Index

1 Einleitung

Die Technik entwickelt sich vom Primitiven über das Komplizierte zum Einfachen. (Antoine de Saint-Exupéry)

Nach der Lektüre dieses Kapitels können Sie die folgenden Fragen beantworten:

Warum gibt es dieses Buch?Was ist modellbasiertes Systems Engineering (Vogelperspektive)?Welcher Zusammenhang besteht zwischen den Sprachen OMG SysML™ und UML™?Wie verhält sich der Inhalt dieses Buchs zu verwandten Themen wie beispielsweise CMMI™, ReqIF, Modelica oder dem V-Modell?

1.1 Vorweg

»Früher war alles besser!«

»Früher war alles viel einfacher. Da konnte man noch mit einer Handvoll Leute etwas auf die Beine stellen. Heute sind es schnell hundert Leute, die man braucht, um ein ordentliches System zu entwickeln. Und die kriegen dann meist nichts auf die Reihe ... Denk doch nur mal an das Projekt P08/15. Dabei sind dort Experten aus allen Bereichen vertreten ...«

Wechselstimmung

Solche oder ähnliche Feierabendmonologe höre ich immer häufiger. Als Geschäftsführer eines Beratungsunternehmens treffe ich viele Personen aus den unterschiedlichsten Branchen. Der Tenor ist aber gleich. Woran liegt das? Ganz einfach: am Fortschritt.

Wir sind an einem Punkt angekommen, an dem komplexe und verteilte Systeme gefordert werden, die von komplexen und verteilten Organisationen entwickelt werden. Die herkömmlichen Entwicklungsmethoden sind aber noch nicht bereit, diese ausreichend schnell und in einem akzeptablen Kostenrahmen zur Verfügung zu stellen.

»Fortschritt ist unaufhaltsam.«

Wir können nicht erwarten, immer fortschrittlichere, größere, bessere Systeme zu entwickeln und dabei weiterhin dieselben Werkzeuge einzusetzen. Die Vorgehensweisen, Modellierungssprachen, Entwicklungsumgebungen und Rollen wie der Systems Engineer müssen an dem Fortschritt teilhaben und sich ebenfalls weiterentwickeln.

Von Bits zu Objekten

In der Softwareentwicklung ist dieser Weg an einem Beispiel deutlich zu sehen. Angefangen bei Lochkarten über Assembler, prozedurale Programmiersprachen bis hin zu den objektorientierten Sprachen kennen die Entwicklungswerkzeuge immer größere Bausteine (von Bits bis Klassen/Objekte). Sie erleichtern so die Beschreibung komplexer Systeme. Der Weg zur nächsten Generation ist bereits eingeschlagen: Die grafische Unified Modeling Language (UML™) oder domänenspezifische Sprachen (DSL) werden zunehmend verwendet, um Softwaresysteme zu entwickeln, und mit diesen Sprachen werden immer mehr Aufgaben gelöst, die vorher mit herkömmlichen Programmiersprachen erledigt wurden (Abb. 1.1).

Abbildung 1.1Steigende Abstraktion der Programmiersprachen

1+1=3

Das Gesamtsystem ist mehr als die Summe seiner Bausteine. Die Wechselwirkungen zwischen den Elementen können komplex und schwer kontrollierbar sein. Das führt dazu, dass Vorgehensmodelle und Notationen benötigt werden, um effektiv diese Systeme entwickeln zu können. Ansonsten werden die Kosten der Entwicklung in naher Zukunft in keinem Verhältnis zum akzeptablen Preis der Produkte stehen.

Systems Engineering

Das Systems Engineering (Systementwicklung1) setzt sich schon länger mit dieser Problematik auseinander. Die Entwicklung großer Systeme, bei der viele unterschiedliche Disziplinen beteiligt sind, erfordert ganzheitliche Sichtweisen. Also losgelöst vom spezifischem Detailwissen werden die Anforderungen und Strukturen des Systems betrachtet, der gesamte Lebenszyklus von der Idee bis zur Entsorgung geplant, um insgesamt ein System zu entwickeln, das den Wünschen aller Beteiligten entspricht.

Modellbasiertes Systems Engineering (MBSE)

Im Systems Engineering fordert der Fortschritt einen Paradigmenwechsel: vom dokumentenzentrierten zum modellbasierten Systems Engineering (MBSE). Das Modell wird zur Quelle aller relevanten Informationen. Um gleich einem gängigen Missverständnis vorzugreifen: Die Dokumente sollen nicht verschwinden. Nur sind sie nicht mehr die Quelle der Informationen, sondern eine Sicht auf das Modell, beispielsweise automatisch erzeugt von einem Modellierungswerkzeug. Die Modellierungssprachen OMG Systems Modeling Language (OMG SysML™) und UML spielen in diesem Szenario natürlich eine wichtige Rolle.

Voneinander lernenUML ⇒ S. 201SysML ⇒ S. 309INCOSE ⇒ S. 19

Die Softwareentwicklung kann viel vom Systems Engineering lernen. Zum Nehmen gehört aber auch ein Geben. Umgekehrt kann das Systems Engineering auch von der Softwareentwicklung lernen. Werkzeuge und Methoden zur Modellierung sind hier schon sehr weit entwickelt. Die UML ist eine Modellierungssprache aus diesem Umfeld. Sie hat sich als weltweiter Standard etabliert. Dem Systems Engineering fehlte bisher eine standardisierte Modellierungssprache. Das wird sich durch die neue SysML2 ändern. Sie basiert auf der UML und wird von führenden Unternehmen aus der Systems-Engineering-Branche einschließlich des International Council on Systems Engineering (INCOSE) unterstützt.

1.1.1 Passt das Buch zu mir?

Dieses Buch wird Sie interessieren und für Sie sehr hilfreich sein, wenn Sie ...

die Modellierungssprache SysML lernen wollen,

Systeme beschreiben, spezifizieren und entwickeln,

mit komplexen Systemen arbeiten,

Systems Engineering mit SysML durchführen wollen,

Systeme mit gemischten Disziplinen – beispielsweise Software und Hardware – entwickeln,

ein ganzheitliches Modell erstellen wollen, in dem Elemente nachvollziehbar zusammenhängen

(Traceability),

einen durchgängigen Weg von der Systemidee zum Systemdesign kennenlernen wollen.

Wenn Sie sich nicht in den obigen Punkten wiederfinden, fragen Sie mich, ob das Buch für Sie wertvoll sein könnte. Ich freue mich über eine E-Mail von Ihnen: [email protected].

Werkzeugkasten SYSMOD

Sie lernen in diesem Buch einen Werkzeugkasten kennen, mit dessen Hilfe Sie einen Weg von der Idee eines Systems zur Architektur finden. Die Ergebnisse halten wir in detaillierten und aussagekräftigen Modellen fest. Die Modellierungssprache ist SysML. Der Werkzeugkasten heißt SYSMOD – abgeleitet von Systemmodellierungsprozess bzw. Systems Modeling Process.

1.1.2 Was bietet mir das Buch?

In diesem Buch finden Sie:

den Werkzeugkasten SYSMOD zur Systementwicklung von der Systemidee zur Systemarchitektur,

Steckbriefe zu den Werkzeugen, die Sie individuell zu einem Gesamtvorgehen zusammensetzen können – das Buch gibt Ihnen einen Standardweg vor,

eine Beschreibung der SysML und UML,

eine Einführung in das Systems Engineering,

Randnotizen beispielsweise über Variantenmanagement, funktionale Architekturen, Simulation, Testen und Modellierungsmuster,

Best Practices zu SysML und SYSMOD.

1.1.3 Wie ist das Buch entstanden? Und danke!

UML ohne Software

Die Idee zu diesem Buch hatte ich im Jahr 2003 bekommen. Zu dieser Zeit hatte ich viele Seminare und Beratungseinsätze zum Thema Analyse und Design mit der UML. Der Teilnehmerkreis konzentrierte sich auf Softwareentwickler – vom Programmierer bis zum Projektleiter. In einem Seminar hatte sich allerdings ein außergewöhnlicher Teilnehmerkreis zusammengefunden: Ingenieure, z. B. Nachrichtentechniker, aber kein einziger Softwareentwickler. Sie planten ein großes Projekt, das Software, aber auch bauliche Maßnahmen, Hardware und andere Disziplinen beinhaltete. In der Schulung habe ich den Softwareaspekt reduziert und die Analyse- und Designtechniken allgemeiner erläutert. Für die Teilnehmer hat sich hieraus eine hervorragende Vorgehensweise für ihr Projekt ergeben.

Diese Teilnehmerkonstellation war ab dann kein Einzelfall mehr. Es folgten weitere Seminare, Workshops und Beratungsaufträge, in denen keine Softwareentwickler, sondern Ingenieure aus anderen Disziplinen teilnahmen, die Analyse und Design mit der UML für ihre Arbeit kennenlernen wollten. In mir keimten zunehmend Fragestellungen, Ideen und weiterführende Überlegungen auf: Wie viel Software enthält eigentlich die UML? Wie beschreibe ich Anforderungen mit der UML? Wie gehe ich mit hybriden Systemen um? Mir wurde langsam bewusst, dass die Sprache UML und die Vorgehensweise in vielen Bereichen unabhängig von Software eingesetzt werden kann.

Systems Engineering und SysMLOMG ⇒ S. 201

Der Blick über den Tellerrand hinaus hat mich zur Disziplin Systems Engineering geführt. Hier könnte ich mich mit meinen Gedanken gut einordnen. Der Zufall wollte es, dass ich in der Zeit durch meine Arbeit in der OMG an der UML2 angesprochen wurde, ob ich die Entwicklung der SysML unterstützen könnte. Das passte hervorragend in meine aktuellen Überlegungen, und ich habe sofort zugesagt. Seitdem bin ich aktiv an der Entwicklung von SysML beteiligt und Koautor der SysML-Spezifikation.

Die allgemeine Vorgehensweise in Analyse und Design, das Systems Engineering und die Modellierungssprache SysML – das Mosaik wurde vollständig. Das Bild, das sich daraus ergeben hat, möchte ich Ihnen in diesem Buch darstellen.

Danke, Kunden und Partner!

Die passenden Mosaiksteine konnte ich nur finden, da meine Ideen in vielen Diskussionen mit meinen Kunden und Partnern reifen konnten. Dafür ein großes Dankeschön! Besonders erwähnen möchte ich Reiner Dittel, Marc Enzmann, Ulrich Lenk und Robert Karban, Andreas Peukert sowie Dr. Rudolf Hauber und weitere Mitglieder aus dem INCOSE MBSE Challenge Team SE^23. Vielen Dank auch an Jesko Lamm von der Firma Bernafon für die zahlreichen Diskussionen und das gemeinsame Entwickeln der Methodik zu funktionalen Architekturen für Systeme (FAS) [58].

Danke, SysML!

Die kreativen Auseinandersetzungen in der SysML-Arbeitsgruppe der OMG mit sehr kompetenten Modellierern und Systemingenieuren haben mich große Schritte vorangebracht. Mein besonderer Dank gilt Conrad Bock, Sanford Friedenthal, Bran Selic, Alan Moore und Roger Burkhart.

Danke, oose!

Sehr wichtig für meine fachliche und persönliche Weiterentwicklung sind die Umgebung und die Freiräume, die mir meine Firma oose Innovative Informatik GmbH gibt. Vielen Dank an meine Kollegen und ganz besonders an Bernd Oestereich für die Unterstützung. Einige Abbildungen in diesem Buch wurden freundlicherweise von der oose Innovative Informatik GmbH zur Verfügung gestellt.

Danke, Verlag!

Ein großes Lob und Dankeschön an den dpunkt.verlag. Vor allem natürlich an Christa Preisendanz!

Danke, Richard!

Es ist immer eine Freude, mit Richard M. Soley zu kommunizieren. Vielen Dank für das fantastische Geleitwort.

Danke, Reviewer!

Ohne ein fachliches Review kann ein Buch keine ausreichende Qualität erreichen. Der Blick von außen ist wichtig. Vielen Dank besonders an Wolfgang Krenzer von IBM Automotive Industry und Andreas Korff von ARTiSAN Software Tools GmbH für die Reviews der 1. Auflage dieses Buchs.

Danke, Pavel Hruby!

Ich möchte auch Pavel Hruby für die hervorragende UML-Visio-Schablone danken (www.phruby.com). Sie wird übrigens auch für die offizielle UML- und SysML-Spezifikation verwendet.

Danke, Leser!

Vielen Dank natürlich auch an Sie, dass Sie dieses Buch gekauft haben und sich für das Thema interessieren. An Ihrem Feedback bin ich sehr interessiert. Schreiben Sie mir: [email protected].

1.1.4 Wie lese ich das Buch?

Lesen und Nachschlagen

Das Buch besteht aus zwei Teilen: Kapitel 1 und Kapitel 2 sind zum durchgängigen Lesen, Kapitel 3 und folgende sind primär zum Nachschlagen geeignet.

Einleitung

Sie befinden sich gerade in Kapitel 1. Hier erfahren Sie etwas über das Buch selbst – beispielsweise diese Anleitung zum Lesen – sowie einführende Grundlagen zum Thema Systems Engineering, SysML und UML. Sie können dieses Kapitel auch überspringen und direkt in Kapitel 2 einsteigen.

SYSMOD

In Kapitel 2 beschreibe ich das Vorgehen SYSMOD, um die Anforderungen an ein System zu erfassen, zu modellieren und eine Architektur abzuleiten, die den gestellten Anforderungen genügt. Die Ergebnisse des Vorgehens werden mit SysML modelliert.

Randnotizen

Am Ende von Kapitel 2 streife ich weitere Themen, die für das Vorgehen wichtig sind, wie beispielsweise funktionale Architekturen, Variantenmanagement und Modellmanagement.

UML und SysML

In Kapitel 4 und Kapitel 3 erläutere ich die Modellierungssprachen UML und SysML. Da SysML auf der UML aufbaut, stehen im SysML-Kapitel nur die erweiternden Elemente. Im UML-Kapitel erläutere ich entsprechend nur die Sprachelemente, die auch in SysML verwendet werden. Beide Kapitel stellen also insgesamt den SysML-Sprachumfang dar. Die Abgrenzung zeigt Ihnen deutlich, was die UML leistet und was die SysML ergänzt.

Profil SYSMOD Stereotyp ⇒ S. 299

In Kapitel 5 beschreibe ich die Spracherweiterungen (Stereotypen), die das in Kapitel 2 beschriebene Vorgehen SYSMOD benötigt. Sie gehören nicht zu den Sprachstandards SysML und UML.

Seitenrand

Am Seitenrand stehen Zwischenüberschriften zur besseren Orientierung und Querverweise mit Seitenangaben zu Zusatzinformationen, die für das Verständnis des Absatzes hilfreich sind.

1.1.5 Wohin geht der Weg?

Ausbreitung der UML

Mit SysML hat die UML ihr Ausbreitungsgebiet weiter vergrößert. Ausgehend von einer reinen Modellierungssprache zur Softwareentwicklung über die Geschäftsprozessmodellierung [61] nun zur Modellierungssprache des Systems Engineering. Wohin führt dieser Weg?

Lingua franca?

Es scheint, dass die UML auf dem besten Weg ist, zur Lingua franca der Modellierung zu werden. Das Potenzial hat sie. Die UML ist erweiterbar und somit an spezifische Bedürfnisse anpassbar. Sie ist international verbreitet, erprobt und anerkannt. Und hinter ihr steht die OMG – ein international agierendes Konsortium, dem führende IT-Firmen angehören.

Kompatible Sprachfamilie

Auch wenn ich ein starker Verfechter der UML bin und sie derzeit in ihrer Rolle konkurrenzlos sehe, glaube ich nicht, dass sie die Lingua franca der Modellierung wird. Ich denke (und hoffe), dass dies keine Sprache erreichen wird. Eine gewisse Vielfalt ist notwendig. Die UML legt aber die Saat für künftige Modellierungssprachen, was dazu führt, dass sie sich im Kern ähneln und in gewissen Grenzen kompatibel sind.

Die Zukunft wird einen großen Bedarf an Modellierungssprachen bringen. Unsere Systeme, die wir entwickeln, werden immer komplexer. Die Modellierungssprachen erlauben es mir, mich auf verschiedenen Abstraktionsebenen zu bewegen. Je abstrakter ich werde, desto einfacher erscheint mir das System. Ein guter Modellierer beherrscht die Kunst, auf abstrakter Ebene konkret zu werden.

Weiterführende Referenzen

Die Homepage zum Buch und MBSE-Blog:

www.model-based-systems-engineering.com

SYSMOD als Eclipse-Process-Framework-Modell:

www.sysmod.de

Beispielmodelle online:

Kfz-Zugangssystem:

example.model-based-systems-engineering.com Teleskopprojekt: mbse.gfse.de

Direkter Kontakt:

[email protected]

Beratung, Trainings, Projektarbeit: Systems-Engineering@oose

www.oose.de/themen/systems-engineering

OMG™

www.omg.org – Hauptseitewww.omgsysml.org – OMG SysML™

INCOSE, Gesellschaft für Systems Engineering e.V.

www.incose.orgwww.gfse.de

1.2 Systems Engineering

Unterschiedliche Disziplinen, unterschiedliche Methoden

Jede Disziplin und jede Branche hat ihre eigenen Methoden. Sei es die Softwareentwicklung, die Hardwareentwicklung, die Mechanik, das Bauwesen, die Psychologie und so weiter. Diese Abgrenzungen funktionieren gut, solange man in einem Projekt innerhalb einer Disziplin bleibt. Bei disziplinübergreifenden Projekten wird es schwieriger. Zwischen den Methoden der jeweiligen Disziplinen müssen Schnittstellen geschaffen und aufeinander abgestimmt werden. Das Projektmanagement steht dann der Herausforderung gegenüber, die Besonderheiten aller Disziplinen zu berücksichtigen.

Unterschiedliche Charaktere

Die vielen Witze über die Eigenarten von Physikern, Ingenieuren, Informatikern, Mathematikern & Co. machen deutlich, dass bei interdisziplinären Projekten unterschiedliche Welten aufeinanderstoßen4. Missverständnisse und Konflikte sind vorprogrammiert.

Gute Einzellösung, schlechte Gesamtlösung

Die Softwareentwickler überlegen sich beispielsweise eine neue leistungsfähige Architektur. Diese benötigt allerdings mehr Speicherressourcen. Das fällt erst sehr viel später bei der Integration mit der Zielhardware auf. Die Hardwareentwickler sehen eine Möglichkeit, die Hardware ausreichend mit Speicher zu erweitern. Das Problem scheint gelöst. Aber noch viel später stellt man fest, dass die erweiterte Hardware keinen Platz mehr im Gehäuse hat, da die Gehäusedesigner von der Anderung nicht informiert worden sind. Die erhöhte Wärmeentwicklung der Hardware wird die geforderten Grenzwerte überschreiten. Jede Disziplin hat in ihrem Bereich die bestmögliche Lösung eingearbeitet. Die Summe der besten Einzellösungen ist aber nicht immer die beste Lösung für das Gesamtsystem.

1+1=3

1+1 ergibt also 3. Die Entwicklung disziplinenspezifischer Subsysteme wird gut beherrscht. Aber das »+« erhöht die Komplexität und führt zu vielfältigen Problemen. Allzu häufig fehlt in Projekten die verantwortliche Rolle für die Summenbildung, also die ganzheitliche, systemweite Sicht. Dabei gibt es hierfür bereits bewährte Methoden und Strategien. Die Disziplin des Systems Engineering beschäftigt sich seit über 50 Jahren mit diesem Thema.

Was bedeutet komplex?

»Das ist ganz schön komplex!« Das haben Sie bestimmt schon einmal gesagt. Was meint man eigentlich damit? Was bedeutet komplex? Es gibt noch ein ähnliches Wort: kompliziert. Ist es dasselbe? Nein! Etwas Komplexes muss nicht kompliziert sein. Die folgende Definition geht auf Georg Klaus zurück [56].

Definition

Die Komplexität bezieht sich auf die Anzahl und Art der Beziehungen zwischen Elementen in einem System.

Die Kompliziertheit bezieht sich auf die Anzahl der unterschiedlichen Elemente.

Gemäß dieser Definition sind viele Systeme komplex und hybride Systeme zusätzlich kompliziert. Das ist die Kernherausforderung des Systems Engineering.

Essenzielle Komplexität

Der Umgang mit der Komplexität zielt primär nicht darauf, sie zu reduzieren, sondern sie einfach erscheinen zu lassen. Systeme besitzen eine essenzielle Komplexität, die in der Natur des Systems liegt [7]. Sie kann nicht reduziert werden, ohne den Systemzweck zu verändern. Schlechte Lösungen können eine unnötige technische Komplexität einführen, die im Rahmen des Systems Engineering oder disziplinenspezifischer Betrachtungen reduziert werden kann.

1.2.1 Was ist Systems Engineering?

Allgemeinbegriff

Sicherlich haben Sie schon einmal von der Disziplin Systems Engineering gehört. Und wenn nicht, kommt der Begriff Ihnen vermutlich nicht fremd vor. Sowohl System als auch Engineering sind bekannte Allgemeinbegriffe. In Kombination hat auch jeder eine gewisse Vorstellung, was diese Disziplin ausmacht. Diese Vorstellungen sind nur oft sehr verschieden.

Definition System

Was verstehen Sie unter einem System? Ein Flugzeug? Ein Auto? Eine Lagerverwaltung? Ein Navigationssystem? Eine Textverarbeitungssoftware? Ihr Laptop? Ein Unternehmen? Alle Beispiele sind korrekt.

Definition

Ein System ist ein von Menschen erstelltes Artefakt, bestehend aus Systembausteinen, die gemeinsam ein Ziel verfolgen, das von den Einzelelementen nicht erreicht werden kann. Ein Baustein kann aus Software, Hardware, Personen oder beliebigen anderen Einheiten bestehen (nach [73]).

Große Systeme

Diese Definition des Systembegriffs ist bewusst sehr allgemein gehalten. Sie können im Sinne des Systems Engineering auch an sehr große Systeme denken. Beispielsweise an das Luftfahrtverkehrssystem, bestehend aus Flughäfen und Luftfahrtverkehrsstraßen.

Modellgröße vs. SystemgrößeSoS ⇒ S. 192

Bei der Größenbetrachtung des Systems müssen Sie deutlich zwischen der Größe des realen Systems und der Größe des Systemmodells unterscheiden. Das Luftfahrtverkehrssystem ist real deutlich größer als ein Auto. Wenn wir die zugehörigen Systemmodelle betrachten, kann es umgekehrt sein. Es ist abhängig von der Detaillierungstiefe der Modelle. Das Auto können wir beispielsweise bis zur letzten Schraube modellieren. Im Systemmodell des Luftfahrtverkehrssystems verwenden wir aber als kleinste Einheiten beispielsweise Flugzeuge und Flughäfen. Dieses Beispiel ist übrigens ein typisches System of Systems (SoS).

Definition Engineering

Jetzt kennen Sie den ersten Teil des Begriffs Systems Engineering. Der zweite Teil – der englische Begriff Engineering – steht allgemein für eine Disziplin, die Methoden und Werkzeuge strukturiert einsetzt, um ein Produkt zu entwickeln.

Definition Systems Engineering

Zusammengesetzt beschreibt der Begriff Systems Engineering Methoden, um erfolgreich Systeme zu entwickeln.

Definition

Das Systems Engineering ist ein interdisziplinärer Ansatz und konzentriert sich auf die Definition und Dokumentation der Systemanforderungen in der frühen Entwicklungsphase, die Erarbeitung einer Systemarchitektur und die Überprüfung des Systems auf Einhaltung der gestellten Anforderungen unter Berücksichtigung des Gesamtproblems: Betrieb, Zeit, Test, Erstellung, Kosten & Planung, Training & Wartung und Entsorgung (nach [73]).

Metadisziplin

Das Systems Engineering integriert alle Disziplinen und beschreibt einen strukturierten Entwicklungsprozess vom Konzept über die Produktions- bis zur Betriebsphase und abschließend wieder die Außerbetriebnahme des Systems. Es werden sowohl die technischen als auch die wirtschaftlichen Aspekte betrachtet, um ein System zu entwickeln, das den Benutzerbedürfnissen entspricht. Diese ganzheitliche Denkweise schließt beispielsweise auch Lösungen zu Problemen ein, die erst durch die Einführung eines neuen Systems entstehen.

Abbildung 1.2Disziplinen des Systems Engineering

Paket ⇒ S. 296

Abbildung 1.2 zeigt Aufgabenbereiche des Systems Engineering in Paket Form eines SysML-Paketdiagramms. Die einzelnen Bereiche werden jeweils nur auf Systemebene betrachtet und tauchen nicht in die Details einer Disziplin ein.

Die Konzepte des Systems Engineering findet man in den spezifischen Disziplinen wieder. Die Art und Weise, Probleme zu formulieren und Lösungswege zu entwickeln, weist hier viele Parallelen auf, die im Systems Engineering allgemein beschrieben sind.

Abbildung 1.3Lebensphasen eines Systems

Systemlebensphasen

Systems Engineering betrachtet den gesamten Lebenszyklus eines Systems. Abbildung 1.3 zeigt die im Standard ISO/IEC 15288 definierten Phasen eines Systems [73]. Das Lebensphasenmodell beschreibt die zeitlichen Abschnitte Entwicklung, Realisierung, Nutzung und Entsorgung. Eine Herausforderung in der Entwicklung von Systemen liegen darin, dass in der Entwicklungsphase Entscheidungen getroffen werden müssen, deren Folgen erst in späteren Phasen wirksam werden. In den späteren Lebensphasen besteht aber nur noch wenig Einfluss auf die Systemeigenschaften. Daraus leiten sich wichtige Fragen ab, die wir uns in der Entwicklungsphase stellen müssen, z. B.:

Welche Probleme löst das System?

Welche Probleme erzeugt das System?

In welchem Umfeld wird das System eingesetzt?

Wie lange soll das System eingesetzt werden?

Wie wird das System durch einen Nachfolger ersetzt?

Beispiel

Angenommen Sie entwickeln einen Flugzeugantrieb auf Basis einer neu entdeckten Substanz als Treibstoff. Neben der reinen Antriebsentwicklung müssen Sie auch klären, wie die Tanksysteme auf den Flughäfen aussehen müssen. Kann der Antrieb nach herkömmlichen Methoden entsorgt werden oder sind eigene Entsorgungssysteme notwendig? Welche Auswirkungen haben die Abgase auf Mensch und Natur? Und viele weitere Fragen sind zu beantworten.

Problemlösungszyklus

Der Problemlösungszyklus beschreibt den Weg vom Auftreten des Problems bis zur Lösung [41]. Die grobe Struktur besteht aus drei Schritten, die nicht nur linear, sondern auch mit Rückkopplungen durchlaufen werden:

1. Aktuelle Situation beschreiben und das zu erreichende Ziel formulieren

2. Lösungsmöglichkeiten erarbeiten

3. Beste Lösung auswählen

Was so einfach und selbstverständlich klingt, wird in der Praxis nicht immer so gelebt. Allzu oft wird beispielsweise Punkt 1 ausgelassen oder in Punkt 2 nur eine Lösung betrachtet. Das Vorgehen in diesem Buch beginnt mit der Formulierung des Ziels der Systementwicklung (Abschnitt 2.3). Die Analyse und die Architektur des Systems in einem Modell unterstützen die Betrachtung unterschiedlicher Varianten, sodass die optimale Lösung ausgewählt werden kann (siehe auch Abschnitt 2.10.2).

1.2.2 Systems-Engineering-Prozesse

Einen guten Überblick über einen Systems-Engineering-Prozess liefert das SIMILAR-Prozessmodell [1]. Es ist eine Abkürzung und steht für folgende Aufgaben:

S

tate the problem

I

nvestigate alternatives

M

odel system

I

ntegrate

L

aunch the system

A

ssess performance

R

e-evaluate

Im Einzelnen bedeuten die Aufgabenbereiche:

Anforderungsmodell erstellen (State the problem)

Am Anfang der Systementwicklung steht die Beschreibung der Aufgabe. Nur zu einer gut gestellten Aufgabe kann man auch eine gute Lösung finden. Fehler in dieser Phase können sehr kostspielig werden, sowohl finanziell als auch für das Ansehen. Die Aufgabenstellung definiert, was das System leisten bzw. welche Anforderungen das System erfüllen soll. Der Systems Engineer beschäftigt sich mit Anforderungen auf Systemebene.

SYSMOD-Zickzackmuster ⇒ S. 182

Das Anforderungsmodell beschreibt auf der betrachteten Ebene nicht die Lösung. Dies würde die Möglichkeit verbauen, alternative Lösungen zu evaluieren.

Alternative Lösungen prüfen (Investigate alternatives)

Eine wichtige Aufgabe des Systems Engineers ist es, alternative Konzepte zu prüfen und gegeneinander abzuwägen. Leider wird diese Aufgabe oft vernachlässigt. Der – menschliche – Drang, sich auf nur eine Lösung zum Problem zu konzentrieren, verdeckt den Blick darauf, dass eine alternative Lösung gegebenenfalls besser geeignet ist.

Der Systems Engineer entwirft – basierend auf dem Anforderungsmodell – also nicht nur eine Systemarchitektur, sondern üblicherweise auch alternative Architekturen. Hiermit können verschiedene Lösungswege gegeneinander abgewogen werden. Selten wird es eine eindeutige Lösung geben, die alle Vorteile in sich vereint. Es müssen also verschiedene Kriterien und Prioritäten betrachtet werden. Typische Aspekte sind beispielsweise Kosten, Größe, Gewicht, Entwicklungszeit, Time-to-Market und Risiken. Aus den Systemmodellen werden Parameter abgeleitet, um die notwendigen Aspekte unmittelbar sichtbar, vergleichbar und am Modell messbar zu machen. SysML bietet hierzu beispielsweise das Zusicherungsdiagramm an (Abschnitt 4.6).

Systemmodell erstellen (Model system)

Modelle werden bereits beim Abwägen der alternativen Lösungsmöglichkeiten erstellt. Jetzt wird das Modell der ausgewählten Lösung detailliert.

Die Modellierung mit SysML ermöglicht eine gute Verfolgbarkeit (Traceability) von Aspekten, beispielsweise die Umsetzung einer Anforderung (siehe Erfüllungsbeziehung in Abschnitt 4.3.4).

System einbetten (Integrate)

Das System wird nicht alleine dastehen und einem Selbstzweck dienen. Es wird in eine Umgebung eingebettet und mit dieser Umgebung interagieren. Die Einbettung wird in dieser Aufgabe betrachtet. Sie beinhaltet beispielsweise die Definition der Systemschnittstellen.

System implementieren (Launch the system)

Das System wird gemäß dem spezifizierten Architekturmodell erstellt und in Betrieb genommen. Die Modelle aus den vorherigen Schritten geben Implementierungsanforderungen für die Software, Hardware, Mechanik usw. vor.

Technische Messwerte prüfen (Assess performance)

Das lauffähige System wird getestet und vermessen. Die Werte müssen den gestellten Anforderungen entsprechen. Der Zusammenhang zwischen Test- und Anforderungsmodell wird in SysML mit der Prüfbeziehung hergestellt (Abschnitt 4.3.6).

Projektergebnisse überprüfen (Re-evaluate)

Diese Aufgabe steht übergreifend über allen anderen Aktivitäten. Ergebnisse aus dem Prozess werden kritisch geprüft und bewertet. Als Konsequenz werden die gewonnenen Erkenntnisse als Rückkopplung wieder in den Prozess eingegeben.

Risikomanagement

Ein weiteres Themenfeld des Systems Engineering, das nicht Teil der Abkürzung SIMILAR ist, ist das Risikomanagement bzw. – positiver formuliert – das Vorsorgemanagement.

Um in einem Projekt ein gutes Risikomanagement betreiben zu können, ist ein allgemeines Grundverständnis aller Beteiligten notwendig: Die Projektmitarbeiter sind in ihrer Arbeit nicht absolut perfekt, und die Projektleiter können nicht zaubern. Dinge gehen einfach schief. Das ist der Normalzustand.

Das Risikomanagement sorgt dafür, dass potenzielle Risiken identifiziert und Maßnahmen definiert werden, um das Risiko zu minimieren bzw. das Problem bei Eintritt des Risikofalls zu lösen. Es ist Teil der Entscheidungsprozesse im Projekt und bedarf regelmäßiger Beobachtung, um den Eintritt eines prognostizierten Risikofalls auch rechtzeitig zu entdecken und entsprechend zu reagieren.

1.2.3 Der Systems Engineer

Bindeglied

Der Systems Engineer ist das Bindeglied zwischen den einzelnen – oftmals sehr unterschiedlichen – Disziplinen eines Projekts. Er denkt systemweit unabhängig von Software, Hardware oder anderen spezifischen Gesichtspunkten.

Organigramm

Organisatorisch ist die Systems-Engineering-Disziplin häufig ähnlich einer Stabsstelle eingeordnet. Sie berichtet direkt an die Gesamtprojektleitung, die wiederum direkt mit den anderen Entwicklungsabteilungen kommuniziert. Der Systems Engineer ist nicht der Vermittler zwischen Projektleitung und den Entwicklungsabteilungen. Er legt die Architektur des Systems fest und muss in der Lage sein, sich mit den unterschiedlichen Entwicklungsabteilungen fachlich auseinanderzusetzen, und nicht nur die Rolle des Beobachters und Nachrichtenüberbringers spielen. Insbesondere ist er auch mit Entscheidungsbefugnissen ausgestattet. Laut INCOSE sollten 20 – 30% des gesamten Projektbudgets in das Systems Engineering fließen [73].

Implizites Systems Engineering

In vielen Projekten fehlt die in Abbildung 1.45 gezeigte Organisationseinheit Systems Engineering. Ihre Aufgaben werden von der Gesamtprojektleitung und den einzelnen Entwicklungsabteilungen wahrgenommen.

Abbildung 1.4Organisatorische Einordnung des Systems Engineering

Auch wenn die Gesamtprojektleitung inhaltlich in der Lage wäre, die Aufgaben des Systems Engineering zu übernehmen, fehlt neben den Leitungsaufgaben die notwendige Zeit. Die Entwicklungsabteilungen komm nizieren explizit n r mit ihren nmittelbaren Nachbardisziplinen, zudenen Schnittstellen existieren. Dad rch ist zwar ein gewisser Weitblick vorhanden, aber keine ganzheitliche Systemsichtweise. Das führt zn den in der Praxis beobachtbaren Problemen, dass leicht der Überblick über komplexe Systeme verloren geht.

Historische Strukturen

Ein häufiges Szenario ist, dass die Disziplin, die (meist) historisch bedingt im Unternehmen dominiert, die Aufgaben des Systems Engineering übernimmt. Spätestens sobald andere Disziplinen an Bedeutung zunehmen, entstehen in dieser Konstellation Konflikt- und Missverständnispotenziale, beispielsweise ein Maschinenbauer mit einer zunehmend dominierenden Softwaredisziplin.

Gesamtlösung fokussieren

Die Entwicklungsabteilungen des Projekts lösen Teilprobleme des Gesamtproblems. Jede Teillösung ist Auswahl aus einer Menge mehrerer Lösungsvarianten. Die Auswahlkriterien sind ohne die Rolle des Systems Engineers geprägt von der jeweiligen Disziplin. Wechselwirkungen zwischen den Lösungsvarianten der einzelnen Entwicklungsabteilungen bleiben unbemerkt. Das angewendete Teile-und-herrsche-Prinzip funktioniert nur, wenn jemand das Gesamtproblem im Fokus hat und dafür sorgt, dass die Summe der besten Teillösungen die beste der möglichen Gesamtlösungen ergibt. Also erst herrschen, dann teilen. Das ist eine der Aufgaben des Systems Engineering.

Prozesse einführen

Die Einbettung des Systems Engineering in die Projektstruktur zeigt, dass es nicht ohne Unterstützung aller Abteilungen – insbesondere des Managements – eingeführt werden kann. Neben der organisatorischen Veränderung ist es auch eine Änderung der Projektkultur. Klare Regeln und für alle Stakeholder transparente Aufgabenbeschreibungen sind wichtige Werkzeuge bei der Einführung eines Entwicklungsprozesses. Es kann nur funktionieren, wenn es sowohl von oben (Management) als auch von unten (Entwicklung) getrieben wird und man sich in der Mitte trifft bzw. sehr nahe kommt.

Tendenziell ist die Disziplin Systems Engineering auf dem Vormarsch und wird zunehmend als eigenständige Organisationseinheit und in Prozessen realisiert.

1.2.4 Historie des Systems Engineering

Damals vor 5000 Jahren ...

Die Menschheit hat schon vor über 5000 Jahren Systeme entwickelt. Damals haben die Ägypter ihre imposanten Pyramiden gebaut. Von Systems Engineering hat zu der Zeit noch niemand gesprochen. Auch wenn dies zum Teil bereits als Beginn der Disziplin angesehen wird, machen wir einen großen Zeitsprung nach vorne zum Anfang des 20. Jahrhunderts und setzen dort die Geburtsstunde des Systems Engineering. Die industrielle Revolution hat viele Systeme hervorgebracht, die eher mit dem Begriff des Systems Engineering verbunden werden: Autos, Flugzeuge, Maschinen. Den Ingenieuren war das Systems Engineering als eigenständige Disziplin aber nach wie vor fremd. Ein Chefingenieur war in der Lage, das gesamte System zu überblicken, und die Teildisziplinen konnten relativ autonom entwickelt werden, da die Schnittstellen einfach waren.

50er-Jahre

Das heutige Systems Engineering hat sich Ende der fünfziger Jahre entwickelt. In dieser Zeit hat die Menschheit Systeme in Angriff genommen, deren Komplexität und Projektdurchführung alles bisher Dagewesene übertrafen. Das Wettrennen der Weltmächte im Weltraum oder das militärische Wettrüsten hat Projekte ins Leben gerufen, die auf der einen Seite sehr komplexe Systeme entwickeln mussten und auf der anderen Seite gezwungen waren, schnell und erfolgreich zu sein. Dieser immense Druck hat dazu geführt, dass Methoden des Systems Engineering entwickelt wurden.

Auch im kommerziellen Bereich wurden die Systeme komplexer und der Bedarf nach ganzheitlichen Methoden größer. Aus dem Telekommunikationsbereich stammt beispielsweise eine frühe Publikation von Arthur Hall »Methodology for Systems Engineering« von 1962 [42].

ISO/IEC 15288

Langsam, aber stetig ist die Bedeutung des Systems Engineering angewachsen. Es sind nicht mehr nur die Riesenprojekte aus der Luft- und Raumfahrt, sondern auch »gewöhnliche« Projekte, die die Techniken dieser Disziplin einsetzen. Im Jahre 2002 ist der Prozessrahmen ISO/IEC 15288 [49] eingeführt worden, der die Prozesse entlang des Lebenszyklus eines Systems beschreibt. Damit ist das Systems Engineering auch formal eine anerkannte Disziplin in der Entwicklung von Systemen.

Aufgrund der Historie dominiert das klassische Systems Engineering nach wie vor in den USA und in den Domänen Luft- und Raumfahrt sowie in militärischen Projekten. Insbesondere die SysML hat dem Thema modellbasiertes Systems Engineering (MBSE) großen Vorschub geleistet. Ein Überblick über MBSE finden Sie in Abschnitt 1.3.

1.2.5 International Council on Systems Engineering

1990 wurde in den USA die Organisation National Council on Systems Engineering (NCOSE) gegründet. Die Ziele waren die Entwicklung und Förderung des Systems Engineering in den USA. Nur fünf Jahre später sind diese Ziele auf internationale Ebene ausgedehnt worden und aus NCOSE wurde das International Council on Systems Engineering (INCOSE).

Die über 9500 Mitglieder kommen vorwiegend aus den USA (ca. 5600 Mitglieder), Großbritannien (ca. 820 Mitglieder) und Frankreich (ca. 510 Mitglieder). Aus Deutschland kommen ca. 420 Mitglieder (Abb. 1.5). Zu den amerikanischen Mitgliedern gehören beispielsweise Mitarbeiter der Firmen NASA, Boeing und General Motors. Zu den deutschen Vertretern zählen Mitarbeiter der Firmen Siemens, BMW und oose.

INCOSE ist in sogenannte Chapters unterteilt. In Deutschland ist das lokale INCOSE-Chapter die Gesellschaft für Systems Engineering e.V. (GfSE).

Weitere Informationen zu INCOSE und der GfSE finden Sie auf den Webseiten www.incose.org und www.gfse.de.

Abbildung 1.5INCOSE-Mitgliederverteilung (2005/2007/2013)

1.2.6 Systems Engineering in Deutschland

Implizites Systems Engineering

Deutschland hat hinsichtlich erfolgreicher Produktentwicklung weltweit eine bedeutende Stellung. Die Vermutung liegt nahe, dass das Systems Engineering konsequent betrieben wird. Näher betrachtet ist aber festzustellen, dass zwar die methodischen Ansätze des Systems Engineering angewendet werden, die Disziplin bisher aber keine hervorgehobene Rolle einnimmt. Nur selten findet man explizit einen etablierten Systems-Engineering-Prozess, eine Systems-Engineering-Abteilung oder einen Systems Engineer entsprechend der oben genannten Definition. Glücklicherweise steigen aber die Zahlen und Systems Engineering ist in Deutschland deutlich auf dem Vormarsch.

Tendenz steigend

Mein persönlicher Eindruck aus einer Vielzahl von Projekten, die ich im Rahmen meiner Berater- und Trainertätigkeit kennengelernt habe, ist, dass es ein zunehmendes Bewusstsein für die Notwendigkeit des Systems Engineering gibt. Eine Kennzahl, die meine Wahrnehmung untermauert, ist die deutlich steigende Zahl an Mitgliedern in der GfSE. Ihre Anzahl hat sich von 2005 bis 2013 verdreifacht.

Aus- und Weiterbildung

Mit zunehmender Bedeutung des Systems Engineering steigt auch die Anzahl der Aus- und Weiterbildungsangebote. Neben Beratungs- und Trainingsanbietern wie die Firma oose listet die Webseite der GfSE6 über 30 Hochschulangebote7 auf.

Systems Engineering Leadership

Ich arbeite aktuell gemeinsam mit der FH Campus02 aus Graz am berufsbegleitenden Masterstudiengang Systems Engineering Leadership8. Er setzt auf den positiven Erfahrungen des Masterstudiengangs Software Engineering Leadership9 auf. Ziel ist es, die Studierenden für Führungsrollen im Systems Engineering zu befähigen.

1.3 Modellbasiertes Systems Engineering (MBSE)

Schlüsseltechnologie

In many respects, the future of systems engineering can be said to Schlüsseltechnologie be model-based.

Das ist die Aussage von INCOSE in ihrem Papier zur Vision 2020 [69]. Modellierung ist eine Schlüsseltechnologie zur Entwicklung komplexer Systeme. Die Modelle halten die Informationen konsistent zusammen und ermöglichen verschiedene Sichten mit unterschiedlichen Abstraktionsebenen. Das ist notwendig, da eine einzelne Person die Komplexität mit all ihren interdisziplinären Abhängigkeiten nicht mehr bewältigen kann. INCOSE definiert MBSE wie folgt:

Definition

Modellbasiertes Systems Engineering (MBSE) ist die formalisierte Anwendung der Modellierung, um die Aktivitäten zu Systemanforderungen, Architektur, Analyse, Verifikation und Validierung von Beginn der konzeptuellen Architekturphase über die Entwicklung bis zu den späteren Phasen des Systemlebenszyklus zu unterstützen (nach [69]).

MBSE=SysML?

Die Definition klingt auf den ersten Blick eingängig. MBSE ist vereinfacht formuliert, Systems Engineering mit einem Systemmodell. Auf den zweiten Blick stellt sich die Frage, was ein Modell ist. Handelt es sich um ein SysML-Modell? SysML wird in der Definition von INCOSE zu MBSE aber nicht erwähnt. MBSE ist weit mehr als SysML. SysML ist nur eine Sprache, die im MBSE eingesetzt wird.

INCOSE definiert nicht den Begriff des Modells. In SYSMOD definiere ich den Begriff des Systemmodells wie folgt:

Definition

Das Systemmodell im Kontext des MBSE ist das Abbild eines realen oder noch zu entwickelnden Systems, wobei mittels Abstraktion nur die für einen definierten Zweck relevanten Attribute berücksichtigt werden. Das Systemmodell ist gekennzeichnet durch die folgenden Eigenschaften:

Das Systemmodell darf sich aus mehreren Repositories zusammensetzen, muss aber in sich konsistent sein und sich nach außen wie ein einzelnes Modell verhalten.Das Systemmodell erlaubt unterschiedliche Sichten auf die Informationen.Das Systemmodell ist maschinell auswertbar und liegt in einer abstrakten Syntax vor, die explizit MBSE-Konzepte wie Anforderungen oder Systemarchitekturen unterstützt.

Nach dieser Definition ist ein einzelnes SysML-Modell ein Systemmodell. Das Gleiche gilt für ein SysML-Modell, das mit einem Anforderungsmodell, einem UML-Modell und einem CAD-Modell verbunden ist. Ein Textverarbeitungsdokument ist kein Systemmodell, sondern nur eine mögliche Sicht auf ein Modell.

In den folgenden Abschnitten gebe ich Ihnen einen kurzen Überblick über eine Auswahl an Modellierungssprachen im Umfeld von MBSE.

1.3.1 Die Sprachen UML und OMG SysML

UML ⇒ S. 201OMG ⇒ S. 201

Im Bereich der Softwareentwicklung hat sich die Unified Modeling Language (UML) als Modellierungssprache etabliert. Es ist ein weltweiter Standard, der von der Object Management Group (OMG) spezifiziert wird. Die UML ist auch als ISO-Standard anerkannt (ISO/IEC 19501).

Standard gesucht

Trotz zahlreicher Initiativen, die Prozesse des Systems Engineering zu standardisieren (z. B. ISO/IEC 15288, EIA-632), hat sich bisher keine einheitliche Modellierungssprache ergeben. Das führt zu erheblichen Reibungsverlusten in interdisziplinären Projekten. Informationen in Form von Modellen können nur schlecht kommuniziert werden, Missverständnisse treten auf, verschiedene Werkzeuge sind notwendig und so fort.

UML für Systems Engineering

Im Jahr 2001 hat INCOSE sich zum Ziel gesetzt, die UML zu einer Standardsprache des Systems Engineering zu machen. Die UML erfüllt im Wesentlichen die Anforderungen, ist verbreitet, an spezifische Bedürfnisse anpassbar, und es gibt eine Vielzahl an Modellierungswerkzeugen, Literatur sowie Beratungs- und Seminaranbietern. Aufgrund des in der UML integrierten Erweiterungsmechanismus (Stereotypen) können neue Modellierungsvokabeln definiert und somit die UML an bestimmte Domänen und Disziplinen angepasst werden. Mit der Version UML 2.010 ist die Bandbreite der Einsatzmöglichkeiten gegenüber der UML1 noch größer geworden (siehe z. B. [61]).

OMG SysML™ ⇒ S. 309

Die Anpassung der UML für das Systems Engineering hat den Namen OMG Systems Modeling Language (OMG SysML™) und basiert in der aktuellen Version 1.4 auf der UML 2.5. Die wichtigsten Erweiterungen der SysML gegenüber der UML sind:

Die Klassen der UML werden in SysML Systembausteine genannt, das Klassendiagramm

Blockdefinitionsdiagramm

. Das UML-Kompositionsstrukturdiagramm heißt in SysML

internes Blockdiagramm

. Für beide Diagrammformen sind etliche Erweiterungen definiert.

Objektflüsse im internen Blockdiagramm

Unterstützung der

Enhanced Functional Flow Block Diagrams

(EFFBD) und kontinuierlicher Funktionen durch Aktions- und Objektknoten im Aktivitätsdiagramm.

Zwei neue Diagrammarten: Anforderungsdiagramm, Zusicherungsdiagramm

Unterstützung des Datenformats ISO AP-233, um Datenaustausch zwischen verschiedenen Werkzeugen zu ermöglichen.

Explizites Herausstreichen von UML-Elementen, die im Systems Engineering nicht benötigt werden, z. B. die softwarelastigen Komponenten

Warum noch eine »ML«?

Berechtigt ist die Frage, ob diese Erweiterungen überhaupt notwendig gewesen sind, oder anders gefragt: »Warum noch eine Modellierungssprache? Hätte man nicht einfach die UML verwenden können?« Die UML ist zwar sehr mächtig, weist aber hinsichtlich des Systems Engineering entscheidende Defizite wie die fehlende Anforderungsmodellierung auf. Ein weiterer Grund, der die Notwendigkeit von SysML begründet, ist die Tatsache, dass UML zum Teil softwarelastig und stark von der Objektorientierung geprägt ist, im Systems Engineering aber disziplinenneutral modelliert wird. Die Verwendung der UML kann leicht zu Akzeptanzproblemen und Missverständnissen in der Projektkommunikation führen.

OMG SysML™ 1.0

Die SysML ist im April 2006 in der Version 1.0 von der OMG als Standard angenommen worden. Etliche Hersteller unterstützen die Sprache. Hierzu gehören ARTiSAN Software Tools, IBM, NoMagic und Sparx Systems. TOPCASED11 ist ein Beispiel für ein Open-Source-Modellierungswerkzeug. Eine aktuelle Übersicht über SysML-Modellierungswerkzeuge finden Sie auf der Homepage des Buchs unter www.model-based-systems-engineering.com.

Ein Jahr lang hat die Finalization Task Force (FTF) am Feinschliff der Version 1.0 gearbeitet. Im April 2007 ist OMG SysML™ 1.0 als offizieller Standard der OMG verabschiedet und im September 2007 veröffentlicht worden.

OMG SysML 1.5

Seitdem sind etliche Verbesserungen an der Sprache vorgenommen worden. Aktuell wird an der Version 1.5 gearbeitet. Die Erhöhung der zweiten Versionsnummer zeigt, dass nur Fehler behoben und kleinere Änderungen vorgenommen werden. In der Version 1.3 ist das Portkonzept der SysML auf Basis von Erfahrungen aus dem praktischen Einsatz der SysML überarbeitet worden. Die Version 1.4 führt unter anderem ein überarbeitetes Konzept der Sicht ein, ermöglicht die Gruppierung von beliebigen Elementen und bietet weitere Möglichkeiten für die Modellierung von Einheiten. Umfangreiche Änderungen der Sprache können erst mit der Version 2.0 eingeführt werden, die derzeit noch nicht geplant ist.

SysML/UML im BuchProfil ⇒ S. 299

Das in Kapitel 2 beschriebene Vorgehen wendet die SysML an. Die Kapitel 3 und 4 beschreiben die Sprachen UML und SysML getrennt voneinander. Somit erfahren Sie, welche Elemente aus der UML stammen und welche Erweiterungen SysML einführt. In Summe beschreiben die Kapitel 3 und 4 den vollständigen Sprachumfang der SysML. Von der UML stelle ich nur die SysML-relevanten Teile vor. Das Kapitel 5 führt weitere Elemente in Form eines Profils (SYSMOD) ein, die im Rahmen des Vorgehens in diesem Buch verwendet werden. Das Kapitel 6 stellt das Zertifizierungsprogramm OMG Certified Systems Modeling Professional (OCSMP) vor und unterstützt bei der Vorbereitung zur Zertifizierungsprüfung.

1.3.2 BPMN

Geschäftliche Abläufe

Neben den Abläufen innerhalb eines (technischen) Systems sind auch die Prozesse im Umfeld des Systems wichtig. Welche Arbeitsabläufe sind in der Entwicklung, in der Produktion, im Betrieb und in der Entsorgung von dem System notwendig? In welche Abläufe bettet sich das System ein?

Geschäftsprozess-modellierung

Die Modellierung dieser Abläufe ist das Feld der Geschäfts-prozessmodellierung, einer Unterdisziplin des Geschäftsprozessmanagements (GPM) [78]12. Statt technischer Systeme werden hier geschäftliche Systeme – also Organisationen – modelliert, entwickelt und optimiert. Zwischen den beiden Disziplinen gibt es nicht nur Berührungspunkte, sondern auch viele Parallelen. Die Werkzeuge und Vorgehensweisen der Modellierung sind sich auf abstrakter Ebene in vielen Bereichen ähnlich [61].

Die Modellierungssprache der Geschäftsprozessmodellierung ist die Business Process Model and Notation (BPMN). Sie stellt einen standardisierten Satz grafischer Elemente bereit, um geschäftliche Abläufe zu modellieren. Das ermöglicht einen besseren Austausch zwischen Menschen. Gleichzeitig ist BPMN nicht nur eine Notation, sondern auch ein formales Modell, sodass die Prozesse auch ausgeführt werden können.

SysML

Die BPMN ist wie die UML und SysML eine Modellierungssprache der OMG. Etliche Modellierungswerkzeuge zu SysML bieten auch die BPMN-Modellierung an. Dadurch können Informationen aus einem SysML- und einem BPMN-Modell leicht miteinander verknüpft werden.

1.3.3 MATLAB/Simulink

Entwicklungsumgebung und Sprache

MATLAB™ (Matrix Laboratory) ist eine proprietäre Entwicklungsumgebung und Programmiersprache zur Visualisierung, Berechnung und Programmierung mathematischer Ausdrücke. Die Anwendung wird von der Firma The MathWorks entwickelt.

Simulation

Simulink™ ist eine Erweiterung von MATLAB zur Modellierung, Simulation und Analyse dynamischer Systeme. Hierfür werden Blockschaltbilder verwendet. Stateflow ist eine Erweiterung, die die Modellierung und Simulation endlicher Zustandsautomaten ermöglicht.

SysML

MATLAB/Simulink ist ein weitverbreitetes Werkzeug. Trotz seiner Fähigkeiten hat es den Nachteil, dass es ein proprietäres System ist und kein Standard wie beispielsweise SysML. Ein SysML-Modellierungswerkzeug steht nicht in direkter Konkurrenz zu MATLAB. Auch wenn es Überschneidungen gibt, beispielsweise im Bereich der Zustandsmodellierung, ergänzen sich beide Umgebungen. SysML ist mächtiger im Bereich der Anforderungsmodellierung und der Systemarchitektur, während MATLAB/Simulink im Simulationsbereich seine Stärken hat. Wenn Sie beide Umgebungen einsetzen, benötigen Sie eine Werkzeugkette, um die Durchgängigkeit Ihrer Modelle nicht zu verlieren.

1.3.4 Modelica

Physikalische Modelle

Modelica ist eine Sprache zur Beschreibung physikalischer Modelle. Sie kann in verschiedenen Bereichen wie beispielsweise Mechanik, Regelungstechnik und Elektrotechnik eingesetzt werden. Es gibt grafische Entwicklungsumgebungen zu Modelica, um Simulationsmodelle zu erstellen. Ähnlich wie es in MATLAB/Simulink möglich ist. Die Sprache Modelica ist frei verfügbar. Verantwortlich für ihre Entwicklung ist die Modelica Association. Das Open Source Modelica Consortium (OSMC) bietet unter www.openmodelica.org eine freie Umgebung für Modelica an.

SysML

SysML und Modelica können sich gut ergänzen. Die Stärken der SysML liegen in der Beschreibung komplexer Systeme. Die Stärken von Modelica liegen in der Analyse diskreter und kontinuierlicher zeitlicher Aspekte in komplexen Systemen.

Die SysML-Modelica Transformation Specification [37] standardisiert die Abbildung zwischen SysML- und Modelica-Modellen. Damit ermöglicht sie die kollaborative Anwendung beider Modelle in einer Umgebung. Eine Werkzeugkette zwischen SysML und Modelica ist in [55] beschrieben.

1.3.5 Specification and Description Language (SDL)

Telekommunikation

Im Telekommunikationsbereich ist die Specification and Description Language (SDL) entwickelt worden [52]. Sie wird von der International Telecommunication Union (ITU) als Standard herausgegeben. Inzwischen ist SDL auch außerhalb der Telekommunikationsbranche im Einsatz, beispielsweise zur Entwicklung medizinischer Systeme oder in der Luft- und Raumfahrt.

SysML

Die Sprache SDL hat viele Gemeinsamkeiten mit der UML und somit auch SysML. Beispielsweise stammen die Sequenzdiagramme von den Message Sequence Charts (MSC) der SDL ab [53]. Die vielen Gemeinsamkeiten erlauben eine Abbildung von SDL-Modellen in SysML/UML-Modelle [70].

1.4 Randnotizen

Ich möchte Ihnen einige Themen aus dem Umfeld dieses Buchs kurz vorstellen, damit Sie sie besser einordnen und abgrenzen können.

1.4.1 AUTOSAR

Internationales Projekt

AUTOSAR steht für Automotive Open System Architecture. Dahinter steht eine internationale Organisation, deren Ziel ein offener Standard für Elektronik-Architekturen im Automobil ist. Mitglieder sind im Wesentlichen Automobilhersteller und -zulieferer. Eine Grundlage von AUTOSAR ist u. a. das Projekt EAST-EEA.

Ziele

Das Ziel von AUTOSAR ist die bessere Austauschbarkeit von Komponenten in der Automobilelektronik zwischen Zulieferer und Hersteller sowie zwischen verschiedenen Produktlinien. Die dafür notwendige Vereinheitlichung findet unter Beibehaltung des Wettbewerbs statt. Berücksichtigt werden die Bereiche Karosserie-Elektronik, Antrieb, Fahrwerk, Sicherheit, Multimediasysteme, Telematik sowie die Mensch-Maschine-Schnittstelle.

ITEA-Projekt

Die Abkürzung EAST-EEA steht für Electronics Architecture and Software Technologies – Embedded Electronic Architecture [14]. Es ist ein Projekt im Rahmen des europäischen ITEA-Programms (Information Technology for European Advancement). Beteiligt an EAST-EEA sind Automobilhersteller und -zulieferer. Die Ergebnisse des Projekts bilden die Basis von AUTOSAR.

Modellierungssprache

Im Rahmen der Architektur ist die EAST-ADL (Architecture Description Language) entstanden. Sie ist ein Profil der UML zur Modellierung elektronischer Systeme im Automotive-Bereich. Schwerpunkte sind Anforderungsmodellierung, Durchgängigkeit über mehrere Abstraktionsebenen sowie Validierung und Verifikation.

EAST-ADL ist in sechs Bereiche aufgeteilt:

Struktur

Verhalten

Anforderungen

Validierung und Verifikation

Support

Varianten

Für jeden dieser Bereiche werden Sprachkonstrukte zur Verfügung gestellt.

SysML und EAST-ADL

Damit ergeben sich viele Überschneidungen mit den Fähigkeiten und Zielen der Sprache SysML. Erste Ansätze, die Sprachen näher zusammenzubringen, liegen vor. So ist die Anforderungsmodellierung von EAST-ADL eine Erweiterung des SysML-Ansatzes, allerdings basierend auf der SysML-Version 0.3. Da SysML allgemeiner ist – unabhängig von der Automobilbranche –, wird die Sprache auch einen höheren Verbreitungsgrad erreichen. Ich erwarte bzw. hoffe, dass beide Sprachen in Zukunft nicht konkurrieren, sondern sich gegenseitig ergänzen und eingesetzt werden.

SysML und AUTOSAR

SysML und AUTOSAR können nicht direkt verglichen werden. AUTOSAR ist eine Architektur mit standardisierten Schnittstellenbeschreibungen, Komponenten usw. SysML ist »nur« eine Modellierungssprache. Sie kann verwendet werden, um ein System gemäß der AUTOSAR-Architektur zu beschreiben.

1.4.2 Capability Maturity Model Integration (CMMI)

QualitätCMM

Dass Softwareentwicklungsprojekte scheitern, galt (gilt?) lange als normal. Der erfolgreiche Abschluss, d. h. Funktionalität wie gefordert, Entwicklungsdauer und -kosten wie geplant, war eine Ausnahme. Um dem entgegenzuwirken, hat das amerikanische Verteidigungsministerium die Entwicklung des Qualitätsmanagementmodells Capability Maturity Model (CMM) angestoßen, um Auftragnehmer besser bewerten zu können. Entstanden ist CMM Mitte der achtziger Jahre am Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh. Das CMM definiert fünf Stufen, die die Qualität einer Organisation und ihrer Prozesse auszeichnen. Betrachtet werden beispielsweise die Projektplanung, das Risiko- und das Anforderungsmanagement.

CMMI

Im Jahr 2000 ist der Nachfolger des CMM, das Capability Maturity Model Integration (CMMI), veröffentlicht worden. Hier sind die Erfahrungen aus der Anwendung des CMM mit eingeflossen. Neben der Softwareentwicklung beleuchtet CMMI nun auch das Systems Engineering.

SysMLVerfolgungsbeziehung ⇒ S. 327

Gute SysML-Modelle und die Prozesse, sie zu erstellen, helfen, die Qualitätskriterien des CMMI zu erfüllen. Beispielsweise wird von CMMI die Verfolgbarkeit von Anforderungen gefordert, was sich sehr gut in SysML abbilden lässt.

1.4.3 Industrie 4.0

Vernetzung

Das Internet hat die Welt klein und die Märkte groß gemacht. Angefangen mit weltweiter Kommunikation, die es ermöglichte, dass jeder lokale Anbieter seine Produkte nun weltweit vertreiben kann, hat Web 2.0 zu globalen Kooperationen und neuen Möglichkeiten geführt. Jetzt verbinden wir nicht nur Menschen, sondern auch Dinge miteinander. Das Internet of Things