Stephan Roth - Softwareentwicklung

Hallo werte Leser,

am vergangenen Freitag (18. September 2009) habe ich beim diesjährigen Anwenderforum Model-Based Systems Engineering (MBSE) der Gesellschaft für Systems-Engineering (GfSE e.V.) teilgenommen, welches diesmal parallel zur SAFECOMP 2009 an der HAW Hamburg stattfand. Die 1979 ins Leben gerufene SAFECOMP-Konferenz, welche diesjähring in Hamburg zum 28. Mal stattfand, ist der internationale Treffpunkt für den Erfahrungsaustausch über sicherheitsrelevante Themen rund um Software und der Vermeidung, Erkennung und Beherrschung logischer Fehler bei Systemkonzeption und Systemrealisierung, insbesondere für sicherheitskritische Systeme.

Der zunehmende Trend, das modellbasierte Methoden im Bereich Systems Engineering Einzug halten, betrifft natürlich ganz besonders den Bereich Safety. Somit ist eine Kooperation entstanden: durch die Zusammenführung des MBSE Anwenderforums und einem SE-”Enabler” sollen die Erfahrungen und Erwartungen ausgetauscht werden. Wie können Sicherheitsaspekte bei der Systemmodellierung berücksichtigt und gefährliche Fehler vermieden werden?

Erst einmal vorweg eine Info: die GfSE-Arbeitsgruppe SysML hat sich in MBSE umbenannt. Damit soll dem Umstand Rechnung getragen werden, das die AG sich nicht nur mit der Sprache SysML und deren Weiterentwicklung und Praxistauglichkeit befasst, sondern sich auch um andere Modellierungssprachen, Tools, Projekte und Umsetzbarkeit kümmert.

Nachdem Frau Prof. Dr. Francesca Saglietti die Arbeit und Ziele von EWICS TC7, der Trägerorganisation der SAFECOMP, und Sven-Olaf Schulze die GfSE vorgestellt hat, hielt Dr. Rudolf Hauber von der HOOD Group den ersten Fachvortrag Model Based System Engineering for Safety and Security Aspects. Dr. Hauber stellte aktuelle Möglichkeiten der Sprache SysML zur Erfassung von Security und Safety Aspekten vor. Er schlug vor, die SysML-Modellelemente Modellsicht (view) und Standpunkt (viewpoint) heranzuziehen und z.B. einen SafetyViewpoint und SecurityViewpoint in das Modell einzuführen, welcher eine Stakeholder-spezifische Sicht auf das Modell z.B. für den Safety Engineer oder den Risk Manager bietet. Das Profil kann beispielsweise um die Stereotyp-Klassen <<hazard>>, <<failure>> oder <<threat>> erweitert werden. Somit können bei der Risiko-Analyse Systemkomponenten identifiziert und mit Klassen dieser Stereotypen verknüpft werden. Anschließend präsentierte Dr. Hauber die Möglichkeiten von SysML in einem V-Modell-getriebenen Entwicklungsprozess, insbesondere bei den Aktivitäten “SD 1.3: Definition of Criticality and Quality Requirements”, “SD 1.6: Threat and Risk Analysis” und “SD 2.1: Technical System Design”, sowie bei der Fault Tree Analysis und FMEA (Failure mode and effects analysis). Fazit: SysML kann zur Erfassung und Analyse von Sicherheitsaspekten bei der Systemmodellierung verwendet werden, es sollte aber über ein standardisiertes SysML Safety & Security profile nachgedacht werden.

In seinem Vortrag Modeling requirements – generating documents demonstrierte Marcus Winteroll von der oose Innovative Informatik GmbH an einem von oose durchgeführten Projekt aus der Hafenlogistik, wie man mit Hilfe von BPMN (Business Process Modeling Notation) und UML die Anforderungserhebung und Analyse durchführt, um zum Schluß aus dem Modell ein ausschreibungsfähiges Lastenheft zu generieren. Hierfür wurde das Tool MagicDraw™ verwendet, das neben UML auch die BPMN über ein PlugIn unterstützt. Auch dieses Projekt demonstriert eines der Kernziele und auch der wesentlichen Vorteile der modellbasierten Ansätze im Systems Engineering: das Modell steht im Mittelpunkt, und andere Produkte/Artefakte, wie z.B. Dokumente, können jederzeit aus dem Modell generiert werden und stellen somit nur eine Sicht auf das Modell zum Zeitpunkt des Erzeugens dar.

Unter dem Titel From MBSE to Complete Virtual System Models stellte Gerd Döhmen von der Airbus Operations GmbH das EU-geförderte Projekt SPEEDS (SPEculative and Exploratory Design in Systems Engineering) vor. Bei dem SPEEDS-Projekt soll ein durchgängiger Standardrahmen zur Implementierung innovativer Konzepte, Methoden, Prozesse, Technologien und Werkzeuge der nächsten Generation für den Entwurf eingebetteter Systeme definiert werden mit dem Ziel, die Wettbewerbsfähigkeit Europas im Entwurf eingebetteter Systeme in wichtigen sicherheitskritischen Industriesektoren zu verbessern. Adressiert wird in dem Projekt u.a. ein bekanntes Problem: bei der Systementwicklung müssen häufig viele Entwickler mit den unterschiedlichsten Standard-Werkzeugen zusammenarbeiten, aber der Datenaustausch zwischen den Tools gestaltet sich meistens extrem schwierig. Die Integration der Tools in das SPEEDS environment realisiert die Vision einer nahtlosen, vom jeweiligen Werkzeug unabhängigen und organisationsübergreifenden Zusammenarbeit von Entwicklern unterschiedlichster Ingenieursdisziplinen. Die Lösung ist ein Complete Virtual System Model, welches in einem zentralen Repository abgelegt wird. Eines der Kernkonzepte in SPEEDS sind Contracts, die bei der funktionalen Zerlegung eines Systems zur Anwendung kommen. Contracts sind formale „Verträge“ – sprich: abstrakte Beschreibungen -, die Systemkomponenten an ihren Schnittstellen erfüllen müssen. Diese Contracts werden klassifiziert als Assumptions (Annahmen) und Promises (Versprechungen). Assumptions definieren die Anforderungen, die eine Systemkomponente an ihre Umgebung stellt. Promises definieren dann die garantierten Eigenschaften und das garantierte Verhalten der Systemkomponente, vorausgesetzt, ihre Assumptions werden erfüllt. Da mag der eine oder andere Leser nun vielleicht denken: das kommt mir irgendwie bekannt vor? Richtig! Das Entwurfskonzept Design By Contract (DbC), welches schon 1985 in der Programmiersprache Eiffel enthalten war, arbeitet sehr ähnlich. Im Systems-Engineering aber geht es nicht nur um Software, sondern beispielsweise auch um die physikalischen Eigenschaften oder die Sicherheitsaspekte einer Systemkomponente, die bei SPEEDS mit Hilfe von Contracts über den gesamten Systementwicklungsprozess, tool- und organisationsübergreifend, definiert, und im Complete Virtual System Model abgelegt werden.

Zu guter letzt präsentierten Wladimir Schamai und Parham Vasaiely vom EADS Innovation Works Systems Engineering Team unter dem Titel System Modeling and Simulation with UML/SysML and Modelica die Ergebnisse ihrer Arbeit. Modelica ist eine objektorientierte Beschreibungssprache für komplexe Multidomain-Modelle. Im Gegensatz zur UML/SysML, die eine Vielzahl an Diagrammarten für verschiedene Anwendungszwecke bereithält, ist Modelica eine text-basierte Modellierungssprache und die grafische Notation auf lediglich eine Diagrammart (Connection Diagram) beschränkt. Dem gegenüber aber hat Modelica Stärken vor allem bei der Simulation von Multidomain-Modellen, d.h. elektrische, hydraulische, pneumatische, mechanische, biologische oder thermische Komponenten können gemeinsam simuliert werden. Warum also nicht die Ausdrucksstärke der grafischen Modellierung mit UML/SysML und die leistungsstarken Simulationsmöglichkeiten von Modelica kombinieren? Die ModelicaML (Modelica Markup Language, ein UML-Profil für Modelica) setzt dabei auf UML/SysML auf und erlaubt das Generieren des häufig sehr umfangreichen und unübersichtlichen Modelica-Simulationscodes aus den Modellen heraus. Dieser Code kann dann mit den gängigen Modelica-Simulationswerkzeugen ausgeführt werden.

In der anschließenden Diskussion ging es vor allem darum, welche Erwartungen beide Seiten von einer Kooperation haben. Es wurde m.E. deutlich, dass das gezielte Weglassen von Details (Abstraktion) bei der Systemmodellierung unter den Aspekten Safety und Security auch Gefahren birgt. Zu schnell kann während des Abstrahierens ein auf den ersten Blick vielleicht unwichtiges, aber dennoch sicherheitsrelevantes Modellelement aus dem Modell “verschwinden”. Ein gutes Beispiel sind Embedded Systems, die in einem simulierten Modell vielleicht noch einwandfrei funktionieren, das reale System sich aber in einem Luftfahrzeug auf Grund der Umgebung (hohe Temperaturen, Vibrationen, schlechte Wärmeabfuhr) plötzlich ganz anders verhält. Auf der anderen Seite bietet aber gerade die Modellierung und Simulation die große Chance, ein System unter Safety und Security Aspekten zu betrachten und ist daher eine analytische Maßnahme zur Fehlervermeidung und Qualitätssicherung.

Alles in allem ein sehr interessantes Anwenderforum mit qualitativ hochwertigen Beiträgen und spannenden Diskussionen. Falls Sie auch an dem Thema Systems-Engineering interessiert sind, oder sich vielleicht sogar eine Mitarbeit bei der GfSE vorstellen können, so kontaktieren Sie mich.