Der Workshop war gut besucht und es gab drei Arbeitsgruppen.
Die Gruppe unter der Leitung von Herrn Prof. Hanno Weber beschäftigte sich mit dem deutschen Systems Engineering Handbuch und dessen Inhalten, sowie mit der Planung der finalen Phase für die erste Ausgabe dieses Handbuchs. Das Erscheinen der Version 1 ist für Mitte des Jahres geplant, aber es wurde auch schon mit einer Themensammlung und einer groben Planung für die folgende Version 2 begonnen. Basis des deutschen Handbuchs ist die Version 3.2 des INCOSE SE-Handbook. Allerdings wird das deutsche SE-Handbuch natürlich keine 1:1 Übersetzung des INCOSE Handbuchs sein, sondern vielmehr eine konsolidierte Sicht der GfSE auf das Systems-Engineering für den deutschsprachigen Raum.
Sehr eng verzahnt mit dem SE-Handbuch ist die Arbeit der Gruppe unter der Leitung von Dr. David Endler und Sven-Olaf Schulze am deutschen SE-Zertifizierungs-Programm, einem Weitebildungsprogramm der GfSE zum zertifizierten Systems Engineer. Inhaltlich ging es auf dem Workshop um ein erstes Review mit den Assessoren, die Lizensierung von Trainingsanbietern und Zulassung der Trainer, die Prüfungsinhalte (SE-Handbuch), das Marketing sowie natürlich um die terminliche Planung des Roll Outs. Es wird drei Zertifizierungsstufen C, B und A geben, wobei A den Experten-Level darstellt.
Ich habe an dem von Tim Weilkiens (oose Innovative Informatik GmbH) und Rainer Diekmann initiierten Projekt Varianten in der Modellierung teilgenommen.
Varianten sind ein im (MB)SE-Umfeld intensiv diskutiertes Thema. Man muss sich beispielhaft ja nur einmal das Produktlinienengineering im Automotive-Umfeld vor Augen führen, wo ein Kunde ein Fahrzeug eines Herstellers in nahezu unzähligen Varianten erwerben kann: mit und ohne Klimaanlage, verschiedene Motortypen und Motorleistungen, Front- oder Allrad-Antrieb, Schaltgetriebe oder Automatik, etc. Schnell wird bewusst, das alle diese Kombinationsmöglichkeiten einen mehrdimensionalen Lösungsraum aufspannen, der sich mit jeder neu hinzugefügten Variante stark vergrößert, und bei dem ein konkretes Fahrzeug exakt einer Lösung aus diesem Konfigurationsraum entspricht. Die Kombinationsmöglichkeiten aller optionalen Eigenschaften einer Fahrzeugreihe erreichen hier sehr schnell Dimensionen im Milliarden-Bereich!
Noch komplexer wird es, wenn Kombinationsmöglichkeiten von Varianten sich gegenseitig einschränken oder ausschließen müssen. So kann ein Fahrzeug entweder nur mit einem Schalt-, oder aber mit einem Automatik-Getriebe ausgerüstet werden, aber niemals gleichzeitig mit beiden Getrieben (Exklusiv-Oder-Verknüpfung). Auch kann es sein, das der Einbau einer Klimaanlage nur dann möglich ist, wenn der Motor eine gewisse Mindestleistung hat und die für eine Klimaanlage erforderlichen Zusatzaggregate betreiben kann. Und jede mögliche Variante kann weitreichende Auswirkungen auf die Architektur des gesamten Systems haben.
Schnell wird deutlich, das Varianten auch für das Model Based Systems Engineering eine große Herausforderung bedeuten. Leider ist aber die Modellierung von Varianten in der Sprache SysML nicht explizit vorgesehen, es fehlen die dazu notwendigen Konzepte. Wie aber kann man schon heute mit SysML-Bordmitteln der notwendigen Variantenmodellierung angemessen begegnen?
Das INCOSE MBSE Challenge Team "SysML for Telescope Modeling", das ein Modell des geplanten European Extremely Large Telescope (E-ELT) erstellt, war ebenfalls mit dieser Herausforderung konfrontiert gewesen. Es gab die Anforderung, das APE-System (Active Phasing Experiment) in zwei verschiedenen Kontexten betreiben zu müssen: einerseits bei der ESO im Labor in München, und andererseits in einem realen Teleskop in der Atacama-Wüste in Chile (Very Large Telescope, VLT). Das Challenge-Team hat diese Anforderung mit den leichtgewichtigen Erweiterungen der UML und SysML, den Profilen und Stereotypen, erfüllt (Profil "SYSMOD Variants").
Auf dem Workshop haben Tim und Rainer der Arbeitsgruppe zunächst dieses Konzept aus dem Teleskop-Modell vorgestellt. Nach anschließender Diskussion über Möglichkeiten und Grenzen hat uns Rainer zusätzlich die Feature Oriented Domain Analysis (FODA) vorgestellt (Feature = Merkmal, Eigenschaft), welche heutzutage zu einem sehr weit verbreiteten Ansatz auf dem Gebiet des Produktlinienengineerings gehört. Dabei werden die Features eines Produkts nach den Kriterien Pflicht-Feature oder optionales Feature kategorisiert, diese hierarchisch in einem Baum (sog. feature tree) eingeordnet, und ihre Abhängigkeiten (UND, ODER, EXOR) abgebildet. Wir fanden, das diese Darstellung einfach, aber dennoch sehr intuitiv ist. Auch haben wir uns das Eclipse-basierte Werkzeug pure::variants der pure-systems GmbH angeschaut, welches alle Phasen des Domain Engineerings unterstützt und Variantenmanagement für Softwareproduktlinien ermöglicht.
Es wurde dann die Idee geboren, aus den möglichen Varianten eines Systemmodells, durch Auswertung der Stereotypen aus dem "SYSMOD Variants" Profil, eine FODA-Tree ähnliche Ansicht zu generieren und diese nach Excel zu exportieren. Ziel soll es sein, über diese Excel-Tabelle eine einzelne, konkrete Ausprägung des Modells konfigurieren zu können. Dabei sollen auch die o.g. Abhängigkeiten zwischen Features, als auch Constraints berücksichtigt werden.
Da leider einige unserer Arbeitsgruppenmitglieder am Abend des ersten Tags abreisen mussten, waren wir am zweiten Tag nur noch zu zweit und haben daher versucht diese Idee mit zwei unterschiedlichen Modellierungstools (Ich mit Enterprise Architect und VBA, Tim mit MagicDraw und Apache Velocity) praktisch umzusetzen. Dieses gelang uns in Ansätzen auch, ein erster, präsentierbarer Prototyp scheiterte - auch auf Grund von Zeitknappheit - letztendlich aber an kniffligen Excel und VBA Problemchen. Jedenfalls ist es ein Ansatz, der weiterverfolgt werden soll.
Insgesamt war es ein toller Workshop, aus dem ich viele Anregungen, auch für die tägliche Praxis, mitnehmen konnte.
