Entwicklung mit System

Systems Engineering mit Eclipse

Michael Jastram
Systems Engineering mit Eclipse

© iStock / the4js

Eclipse hat sich schon längst von der reinen Java-Entwicklung emanzipiert und wird in zahlreichen Domänen eingesetzt. In diesem Artikel geht es um die Systementwicklung, in der sich in den letzten Jahren im Eclipse-Umfeld einiges getan hat. Insbesondere das auf Topcased basierende PolarSys und Papyrus haben hier die Aufmerksamkeit – nicht zuletzt, weil Konzerne wie Airbus und Ericsson hier hohe Beträge investieren. Doch diese Ansätze sind schwergewichtig. In diesem Artikel zeigen wir, wie man auch leichtgewichtig mit Eclipse ins Systems Engineering einsteigen kann. Die dazugehörigen Materialien gibt es in dem Communityprojekt SE-Teaching.

Beim Systems Engineering geht es darum, komplexe technische Systeme zu entwickeln. Typische Beispiele sind Autos, Flugzeuge, Züge und dergleichen. Typische Produkte haben einen hohen Softwareanteil. Da oft hohe Summen oder gar Menschenleben auf dem Spiel stehen, gilt es oft, bestimmte Standards wie IEC 61508 oder ISO 29292 einzuhalten. Das wiederum bedeutet, dass bestimmte Disziplinen formal unterstützt werden müssen, wie Anforderungsmanagement, Validierung und Verifizierung etc.

Nach einem kurzen historischen Abriss des Systems Engineering wird gezeigt, wie es heute in der Industrie praktiziert wird. Danach wird auf die in Eclipse verfügbaren Werkzeuge und Komponenten zum Systems Engineering eingegangen, insbesondere PolarSys. Und zuletzt wird SE-Teaching beschrieben und warum dieses Communityprojekt ins Leben gerufen wurde.

Es war einmal … Systems Engineering

Geprägt wurde der Begriff Systems Engineering durch die Raumfahrt. Kein Wunder, denn dort sind Fehler teuer. Außerdem ist die Koordinierung von einerseits vielen Teilen und Untersystemen, andererseits von Organisationen und Personen notwendig.

Daher nimmt der Prozess eine zentrale Rolle im Systems Engineering ein. Der Prozess hat sicherzustellen, dass eine Lösung für das Problem des Kunden zufriedenstellend umgesetzt wird und über den Lebenszyklus des Produkts erhalten bleibt. Zu den in der Softwarewelt bekannten Prozessen gehört zum Beispiel der Rational Unified Process (RUP) oder der daran angelehnte Open Unified Process (OpenUP).

Verpönt als Prozess ist der Wasserfall (zu Recht!), bei dem die Artefakte gnadenlos nacheinander erstellt werden, von den Anforderungen bis zur Implementierung. Inzwischen berücksichtigen alle relevanten Prozesse, dass man im ersten Durchgang nicht immer alles richtig erfasst, und sie sind in der Regel iterativ.

Eine Systementwicklung produziert eine Reihe von Artefakten, die alle miteinander verzahnt sind: Anforderungen, Spezifikationen, Quellcode und Tests (und Testergebnisse) aller Arten sowie Dokumentation, um nur einige zu nennen. Da kann man schnell den Überblick verlieren.

Kein Wunder, dass Werkzeuge entwickelt wurden, sobald Computer leistungsfähig genug waren. In den Neunzigern sprossen die Tools nur so aus dem Boden, allerdings meistens für Teildisziplinen: zum Beispiel die Rationalwerkzeuge in der Modellierung oder DOORS im Anforderungsmanagement. Für die Nutzer war es schwierig, sich in dem Dschungel zurechtzufinden: Welches Werkzeug, und vor allem welcher Standard wird sich durchsetzen? Zum Glück verstanden das auch die Werkzeughersteller, und die Unified Modeling Language (UML) ist ein gutes Beispiel dafür, dass ein offener Standard die Akzeptanz einer Modellierungssprache drastisch verbessern kann. Etwas Ähnliches passiert zurzeit im Anforderungsmanagement, wo sich das Requirements Interchange Format (ReqIF) als Standard etabliert.

Auch wenn es offene Standards gibt, sind wir weit davon entfernt, von einem Werkzeug zum anderen wechseln zu können. Das wird aber mehr und mehr in der Industrie als Problem erkannt. Denn viele der Produkte, um die es in der Systementwicklung geht, haben einen Produktlebenszyklus von vielen Jahrzehnten. Bei sicherheitskritischen Systemen wie Flugzeugen oder Signalanlagen müssen die Entwicklungsartefakte über den gesamten Lebenszyklus abrufbar sein. Aber viele Hersteller wollen nicht versprechen, dass sie ihre Werkzeuge solange vorhalten, weiterentwickeln und warten. Und selbst wenn, kann ein Hersteller in Insolvenz gehen oder aufgekauft werden. Aber was ist die Alternative?

Open Source rettet den Tag

Insbesondere die Frage der Langzeitwartbarkeit und die Vermeidung von „Vendor-Lock-ins“ beschäftigte die Großindustrie seit Beginn des Jahrhunderts. Ein Konsortium aus einem Dutzend Firmen, einschließlich Airbus, Ericsson, Dassaut und vielen anderen, organisierte sich und gründete 2005 das Topcased-Projekt (heute PolarSys), eine Eclipse-basierte Plattform für Systems Engineering.

Open Source würde die beschriebenen Probleme lösen: Da es keinen einzelnen Hersteller gibt, gibt es auch kein Vendor-Lock-in. Denn nun ist die Kontrolle beim Nutzer, der gewillt ist, Geld für Weiterentwicklung und Wartungsverträge auszugeben. In der Vergangenheit wurden Millionen für Software von Firmen wie IBM, Atego, Esterel und ähnliche Firmen an Lizenz- und Wartungskosten bezahlt. Mit diesen Beträgen, wenn sie zusammengelegt werden, sollte sich doch vernünftige Open-Source-Software entwickeln lassen.

Topcased ging durch mehrere Phasen und Förderprogramme, um heute unter dem Namen PolarSys unter der Obhut der Eclipse Foundation weiterentwickelt zu werden. Aus diesen Aktivitäten heraus hat sich auch das Long-Term-Support-Programm (Eclipse LTS) geformt. Damit soll ein Marktplatz geschaffen werden, der es ermöglicht, bestimmte Versionen und Komponenten aus dem Eclipse-Ökosystem über lange Zeiträume warten zu lassen.

PolarSys ist – wie alle Eclipse-Anwendungen – eine Konfiguration von Komponenten. Die bekannteste und wichtigste davon ist wohl Papyrus (und damit auch implizit EMF und GMF, auf denen Papyrus basiert).

Das Problem mit PolarSys

Die Mitgliederliste von PolarSys liest sich wie das Who is Who der europäischen Schwerindustrie: Airbus, Ericsson, Thales, Atos und viele andere. Das ist grundsätzlich gut: Es zeigt, dass die Industrie gewillt ist, dieses neue Geschäftsmodell auszuprobieren – schließlich wurden seit der Gründung viele Millionen in Topcased/PolarSys investiert.

Diese Investitionen werden jedoch primär dafür genutzt, um die Ziele der PolarSys-Mitglieder umzusetzen. Das ist natürlich verständlich, denn heutzutage wird kaum noch aus Selbstlosigkeit Open-Source-Software entwickelt. Aber die Ziele der PolarSys-Mitglieder sind nicht immer die Ziele der breiten Masse. Mit anderen Worten: Viele Neugierige aus Industrie und Forschung werden auf PolarSys aufmerksam, wenden sich aber oft relativ schnell frustriert ab. Um nur ein Beispiel zu nennen: Es ist keine „Getting Started“-Anleitung zu finden, und nach dem Download des Werkzeugs ist der Nutzer ziemlich auf sich selbst gestellt.

SE-Teaching

SE-Teaching wurde erschaffen, um die eben beschriebenen Schwächen von PolarSys auszugleichen. Abbildung 1 zeigt, wie dies erreicht werden soll: Zunächst gilt es, drei sehr unterschiedliche Gruppen mit unterschiedlichen Interessen zusammenzubringen. Das sind zum einen die Industrienutzer, die leistungsfähige Werkzeuge haben möchten, und auch bereit sind, dafür zu bezahlen. Allerdings gibt es hier zwei Untergruppen: die Großindustrie, die ja bereits Geld in die Hand nimmt, indem sie PolarSys unterstützt, und der Mittelstand, der zwar Interesse hat, aber nicht die finanzielle Schlagkraft wie die Großindustrie. Die erste Gruppe wird bereits bedient, die zweite nur begrenzt.

Abb. 1: Die Artefakte und Stakeholder von SE-Teaching, die Community Platform hält alles zusammen

Abb. 1: Die Artefakte und Stakeholder von SE-Teaching, die Community Platform hält alles zusammen

Die Universitäten haben ebenfalls unterschiedliche Untergruppen. Zum einen möchten die Forscher die Möglichkeit haben, ihre Ideen schnell prototypisch umzusetzen, und zwar in einer Form, die relativ einfach in industriellen Pilotprojekten ausprobiert werden kann. Aber die Masse der Studierenden ist eher daran interessiert, marktfähige Kompetenzen aufzubauen. Die erste Gruppe nutzt Eclipse bereits effektiv als Plattform für Forschungsprojekte, die zweite jedoch nicht. Das ist wieder ein Henne-Ei-Problem, denn würde die Industrie Eclipse-basierte Software in der Breite einsetzen (wie es ja in der Java-Entwicklung schon der Fall ist), dann wäre der Nutzen für die Studierenden klar ersichtlich.

Die dritte Gruppe sind die Dienstleister. Auch heute füllen diese bereits den industriellen Bedarf von Beratung, Schulung, Systemintegration, Werkzeuganpassung und ähnlichen Aufgaben. Aber durch das neue, Open-Source-basierte Geschäftsmodell kommt noch die Weiterentwicklung von Software hinzu. In diesem Bereich tummeln sich ebenfalls bereits viele Spieler, und manche sind auch aktiv in PolarSys involviert, wie bspw. Atos oder Obeo. Aber dadurch, dass der Zielmarkt von PolarSys (noch) vergleichsweise klein ist, hält sich das Engagement in Grenzen.

SE-Teaching geht mit drei Ansätzen auf diese Probleme ein: Zunächst wurde eine durchgängige minimale Werkzeugkette für die Systementwicklung geschaffen; diese ist in Abbildung 2 zu sehen. Sie besteht aus fünf Komponenten, die von zwei Eclipse-Projekten bedient werden, EMF und RMF.

Abb. 2: Die minimale, Eclipse-basierte Werkzeugplattform für SE-Teaching, sie kann auf verschiedene Weisen erweitert werden, wie rechts gezeigt ist

Abb. 2: Die minimale, Eclipse-basierte Werkzeugplattform für SE-Teaching, sie kann auf verschiedene Weisen erweitert werden, wie rechts gezeigt ist

Leser, die mit dem V-Modell vertraut sind, werden es in dem Werkzeug wiedererkennen: Die Entwicklung beginnt links oben mit Anforderungen, die die Basis für das Systemmodell bilden. Dies stellt die Basis für den Quellcode dar, der entweder händisch oder automatisiert erstellt wird. Um sicherzustellen, dass das richtige System korrekt gebaut wird (Verification and Validation, V&V), gibt es eine entsprechende Testabdeckung aus Unit und Akzeptanztests.

Bevor die Einwände kommen, zwei wichtige Punkte:

Erstens: Es geht hier um das V-Modell, das lediglich die Abhängigkeiten der Artefakte zueinander darstellt. Es gibt auch einen V-Prozess, der mehr oder weniger vorschreibt, die Artefakte entlang des Vs zu erstellen. Aber das V-Modell kann auch mit anderen Prozessen eingesetzt werden: Denn die Abhängigkeiten der Artefakte bestehen auch, wenn man bspw. agil entwickelt. In dem Fall ist es dann wichtig, dass der Änderungsprozess ordentlich funktioniert.

Zweitens: Das hier gezeigte Modell ist so minimal, dass es für viele Projekte nicht ausreichend ist. Aber da kommt die Modularität von Eclipse ins Spiel: Denn einzelne Komponenten können ausgetauscht oder neue eingefügt werden. Damit das funktioniert, müssen die Schnittstellen standardisiert oder zumindest leicht anpassbar sein. Das ist in Abbildung 2 mit den Kästen auf der rechten Seite angedeutet.

Aber ein Werkzeug ist nicht genug, wenn nicht klar ist, wie es eingesetzt werden soll. An dieser Stelle kommt die Dokumentation ins Spiel. Auch hier gibt es verschiedene Ansätze: Zum Beispiel kann der Entwicklungsprozess sorgfältig dokumentiert werden. Aber für SE-Teaching wird stattdessen der Einsatz des Werkzeugs anhand eines Beispiels definiert, was den Prozess lediglich implizit definiert. Der Grund ist, dass über ein gut dokumentiertes Beispiel die Konzepte interessierten Personen sofort zugänglich gemacht werden. Weiterhin wird in der Praxis fast nie ein Standardprozess eingesetzt, Prozesse müssen eigentlich immer angepasst werden. Da es schon gut dokumentierte Prozesse gibt, wäre es redundant, hier einen weiteren einzuführen. Dennoch orientiert sich das Beispiel an der ISO 29110, einer Richtlinie, die sich explizit an kleinere Entwicklungsprojekte richtet, die trotzdem standardkonform entwickeln wollen.

Eclipse Process Framework

Prozessdokumentation ist wichtig, allerdings zurzeit nicht Teil von SE-Teaching. Dennoch hat Eclipse auch hier schon einiges zu bieten, nämlich das Eclipse Process Framework. Dabei handelt es sich um einen Prozesseditor, der die Veröffentlichung des Prozesses als HTML ermöglicht. Der mitgelieferte Beispielprozess ist der OpenUP, der auf dem Rational Unified Process (RUP) basiert. Wie das generierte Ergebnis aussieht, kann man unter http://epf.eclipse.org/wikis/openup/ sehen.

Das dritte wichtige Element wurde eben schon angedeutet: Um eine anschauliche Dokumentation zu erstellen, muss es ein anschauliches Beispiel (Case Study) geben. Das Beispiel muss komplex genug sein, um die wichtigen Aspekte der Systementwicklung darzustellen, aber einfach genug, um es in kurzer Zeit konsumieren zu können. Und nicht zuletzt sollten alle Artefakte der kompletten Entwicklung – Anforderungen, Modelle, Code, Tests – ebenfalls verfügbar sein.

Das PolarSys-Projekt sieht ebenfalls ein Fallbeispiel als wichtig an, und hat dafür einen autonomen Rover ausgewählt. Dieses Beispiel soll auch für SE-Teaching herangezogen werden: Es ist einfach genug, um leicht verstanden zu werden, aber komplex genug, um viele interessante Aspekte der Systementwicklung zu untersuchen. Insbesondere in der Lehre könnte es ein guter Ansporn für die Studierenden sein, die Implementierung in Hardware umzusetzen. Im Rahmen einer Masterarbeit, die von Andrea betreut wird, wird zurzeit an Anforderungen für einen Rover gearbeitet.

SE-Teaching-Werkzeugkette

Abbildung 2 zeigt die fünf Komponenten der Werkzeugkette. Einige Entscheidungen werden sicherlich überraschen: Warum zum Beispiel wurde Ecore für die Systemmodellierung gewählt, und nicht UML? Das wird im Folgenden erörtert:

Anforderungen: Für das Erstellen und Bearbeiten wurde ProR ausgewählt, das Werkzeug des Requirements Modeling Frameworks. Dies arbeitet mit Daten im ReqIF-Format, einem offenen Standard. Damit ist Interoperabilität mit teuren Industriewerkzeugen wie DOORS oder IrQA gewährleistet. Dies ist sicherlich wichtig für industrielle Nutzer, die sich diese Werkzeugplattform anschauen, denn über ReqIF können sie schnell ihre eigenen Anforderungen importieren. Als Alternative dazu wurden SysML-Anforderungen in Erwägung gezogen.

Systemmodell: Die etablierte Sprache für die Systemmodellierung ist SysML, warum also Ecore? Die Hauptgründe sind (1) Einfachheit und (2) Reife. Ecore kann mit UML-Klassendiagrammen verglichen werden, und das ist ausreichend, um zügig ein Datenmodell zu erstellen. Außerdem ist eine ausgereifte Code- und Testgenerierung vorhanden. Papyrus, die Komponente für UML/SysML-Modellierung, ist ungleich mächtiger. Sie ist aber auch ungleich komplexer, und leider wesentlich unausgereifter. Durch die Modularität dieses Ansatzes ist es jedoch für interessierte Nutzer möglich, die Komponente auszutauschen.

Sourcecode: Hier wird die EMF-Codegenerierung eingesetzt, um Quellcode in Java zu erzeugen. Durch die Limitierungen von EMF werden hier eigentlich nur „Stubs“ generiert, die noch von Hand aus programmiert werden müssen. Da der EMF-Codegenerator ausgereift und die Unterstützung von Java in Eclipse ja bekannterweise exzellent ist, wurde dieser Ansatz gewählt.

Unit Tests: Auch hier kommt wieder die EMF-Testgenerierung zur Geltung. Ähnlich wie bei der Codegenerierung müssen die Tests von Hand mit Leben gefüllt werden.

Akzeptanztests: Die Akzeptanztests können in dieser einfachen Werkzeugkette nicht automatisiert generiert werden. Aber RMF stellt die Strukturen zur Verfügung, ein verlinktes Testdokument zu erstellen, in dem dann für jede neue Version die Testdurchführung dokumentiert werden kann.

Nachverfolgbarkeit: Werkzeuggestützte Nachverfolgbarkeit ist wichtig, um die Konsistenz der Systembeschreibung sicherzustellen. RMF ermöglicht dies zwischen Anforderungen, Systemmodell und Akzeptanztests (Abb. 3). Durch die EMF-Codegenerierung besteht eine Nachverfolgbarkeit zwischen dem Systemmodell, Quellcode und Unit Tests. Und nicht zuletzt wird durch das Ausführen der Unit Tests die korrekte Nachverfolgbarkeit zwischen Tests und Code sichergestellt.

Abb. 3: Das Anforderungsdokument des Ampelbeispiels, mit Verlinkung in das Ecore-Modell

Abb. 3: Das Anforderungsdokument des Ampelbeispiels, mit Verlinkung in das Ecore-Modell

SE-Teaching in Action

Auf der Webseite von SE-Teaching gibt es ein „Handbook“ zum Herunterladen. Dieses deckt die hier beschriebenen Inhalte ab. Im Moment ist es eher minimal und sicherlich ausbaufähig. Zunächst wird darin die Installation einer entsprechenden Eclipse-Umgebung beschrieben. Noch gibt es kein fertiges Werkzeug für SE-Teaching, stattdessen wird eine Standarddistribution über die entsprechenden Update-Sites erweitert. Bei dem Beispielprojekt handelt es sich um ein Ampelsystem. Wie bereits erwähnt, soll dies mittelfristig durch ein interessanteres Beispiel (Rover) ersetzt werden.

Abbildung 3 zeigt einen Screenshot aus dem Handbuch. Dort ist auf der linken Seite das Anforderungsdokument zu sehen, auf der rechten Seite das Ecore-Modell als Baumstruktur (eine grafische Darstellung gibt es ebenfalls). Im Anforderungsdokument ist zu sehen, dass REQ-2 drei Verlinkungen ins Modell enthält, und REQ-4 eine Verlinkung.

Nächste Schritte

Dieses Projekt wurde auf der EclipseCon Europe 2014 und dem Tag des Systems Engineering 2014 vorgestellt, wo es viel Interesse und Aufmerksamkeit auf sich zog. Nun gilt es, den Schwung zu nutzen und zügig voranzukommen. Zurzeit liegt dabei der Fokus im Forschungsbereich, denn dort besteht am ehesten die Möglichkeit, Mitstreiter zu engagieren (und Forschungsgelder zu akquirieren).

Für 2015 ist geplant, die Dokumente und Entwicklungsartefakte auf Basis der von Andrea Herrmann betreuten Masterarbeit auszubauen. Weiterhin soll an der Communityplattform gearbeitet werden: Das Projekt ist aus einer langen Diskussion auf LinkedIn entstanden, welches sich aber nur begrenzt für strukturierte Diskussionen eignet.

An dieser Stelle möchten wir alle Leser einladen, die Ergebnisse von SE-Teaching zu nutzen, und sich an der Diskussion zu beteiligen.

Geschrieben von
Michael Jastram
Michael Jastram
Dr. Michael Jastram ist Project Lead und Committer vom Eclipse Requirements Modeling Frameworks. Er ist Geschäftsführer der Formal Mind GmbH, die Forschungsergebnisse im Bereich Systems Engineering kommerzialisiert. Er ist regelmäßiger Fachautor und Sprecher auf Konferenzen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: