Es geht Schlag auf Schlag im PLM-Talk. Gerade erst wurde noch über die Unterschiede und Gemeinsamkeiten zwischen PLM und ERP gefachsimpelt, wird es heute wieder methodischer. Mit Tim Weilkiens, Vorstand der oose Innovative Informatik eG steht ein ausgewiesener Fachmann für ingenieurige Modelle Rede und Antwort.
Hallo Herr Weilkiens, herzlich willkommen auf meiner Blog-Couch zu einer weiteren Episode des PLM-Talks. Ich hoffe, Sie sitzen gemütlich. Man kann davon ausgehen, dass fast alle Leser dieses Blogs bereits eine Publikation von Ihnen in der Hand gehabt haben. Aber können Sie trotzdem ein paar Worte zu Ihrer Person und Ihrem Werdegang verlieren?
Tim Weilkiens
Ursprünglich bin ich Informatiker. Schon bei meinem ersten Arbeitgeber in den 90er-Jahren bin ich mit der UML in Berührung gekommen. Seitdem hat mich die Modellierung nicht mehr losgelassen. Mit der Entwicklung der neuen UML-Version 2.0 habe ich angefangen, in den Arbeitsgruppen der OMG mitzuwirken. Neben der UML, habe ich auch an der BPMN mitgewirkt sowie an den zahlreichen Zertifizierungsprogrammen der OMG. Und natürlich an der Entwicklung der SysML. Aktuell leite ich gemeinsam mit Airbus und der NASA, die Arbeitsgruppe zur nächsten Version SysML 1.6. An der nächsten großen Version 2.0 arbeiten wir ebenfalls bereits schon.
Sprachen sind das eine, viel wichtiger sind noch die Methoden. Hier gibt es allerdings wenig Standards. Ich betrachte mich mehr als ein Sammler als Erfinder von Methoden. Es sind erprobte Vorgehensweisen, denen ich in unterschiedlichen Firmen und Domänen begegne. So ist beispielsweise meine MBSE-Methodik SYSMOD (Systems Modeling Toolbox) oder VAMOS (Variant Modeling with SysML) entstanden.
Seit 2001 bin ich beim Beratungs- und Trainingshaus oose als Berater tätig. Seit 2010 zusätzlich auch als Geschäftsführer bzw. Vorstand seit wir uns in eine Genossenschaft umgewandelt haben.
Ihr Name ist untrennbar mit der System Modeling Language SysML verbunden. Aus welcher Motivation heraus entstand die Initiative zur Entwicklung dieser Erweiterung der UML? Was war das verbindende Element dieser doch recht unterschiedlichen Aktivisten der ersten Stunde der SysML?
Das verbindende Element war sicherlich die Überzeugung, dass Modellierung notwendig ist, um erfolgreich immer komplexer werdende Systeme entwickeln zu können. Die Konzepte der SysML war für die Beteiligten auch nicht wirklich Neuland. Alle haben schon Modellierung im Systems-Engineering-Umfeld eingesetzt. Nur eben keine SysML, sondern beispielsweise eine angepasste UML. Die Definition der SysML war dann „nur“ noch die Standardisierung bewährter Ansätze.
Für die Nichtinformatiker unter uns: Was ist eigentlich genau der Unterschied zwischen der UML und der SysML? Was kann SysML jetzt besser?
Die UML ist eine Modellierungssprache für Softwareanwendungen. Die SysML ist eine Modellierungssprache für Systeme bestehend aus Software, Elektronik, Mechanik, usw. Das sind zunächst scheinbar zwei verschiedene Paar Schuhe. Nun ist die UML sehr allgemein definiert, also statt konkret Softwaretechnologien anzusprechen, geht es vereinfacht gesagt darum, Dinge geschickt zu strukturieren und ihr Verhalten und Zusammenspiel zu beschreiben. Das lässt sich dann auch auf Systeme über Software hinaus übertragen.
Und das wurde ja auch schon bereits vor SysML-Zeiten mit der UML gemacht. Ich kenne neben Softwaremodellierung auch den Einsatz der UML, um Systeme zu beschreiben, Geschäftsprozesse und Unternehmen zu modellieren, bis hin zu biologischen und sozialen Systemen. Letzteres ist aber schon recht exotisch.
Man kann nicht sagen, dass die SysML etwas besser als die UML kann. Sie erfüllt einfach einen anderen Zweck. Die SysML ist formal ein Dialekt der UML. Elemente aus der UML, die softwarespezifisch sind oder keinen erkennbaren Nutzen für Systems Engineering haben, wurden entfernt. Dafür wurden neue Elemente und Begriffe ergänzt, wie beispielsweise Requirement oder Block.
Können Sie uns an einem Beispiel den Einsatz eines neu hinzugekommenen bzw. modifizierten Diagrammtypen aus der SysML schildern? So wird es vielleicht noch deutlicher, wie die SysML angewendet werden kann.
Ein zentraler Diagrammtyp der SysML ist das interne Blockdiagramm. Es zeigt, wie ein System aufgebaut ist. Rechtecke stehen für Systembausteine und die Linien dazwischen, dass es zwischen den Bausteinen einen Austausch gibt. Das kann eine softwarebasierte Kommunikation sein, eine mechanische Verbindung, der Austausch von Wärme oder eine beliebig andere Art. Zusätzlich kann noch dargestellt werden, dass die Kommunikation zwischen zwei Bausteinen über definierte Schnittstellen erfolgt.
Sie finden solche Darstellungen überall in Büros von Systemingenieuren auf Flipcharts und Skizzenblöcken. Die SysML hat das mit dem internen Blockdiagramm einfach nur standardisiert. Es ist eine intuitive und abstrakte Darstellung einer Systemstruktur.
Welche Vorteile sehen Sie durch den Einsatz von SysML in der Praxis – jetzt auch gerade im Bezug auf das Produkt-Lifecycle-Management? Ist SysML die neue Sprache im Requirements Engineering?
Die SysML fördert die Kommunikation zwischen verschiedenen Ingenieursdisziplinen und Stakeholdern. Das ist für viele Projekte ein großer Sprung nach vorne und oft auch ein „low hanging fruit“. Für den ersten großen Sprung, muss man gar nicht so viel Anlauf nehmen. Eine Bereitschaft zu springen, sollte natürlich schon da sein.
Ohne SysML fehlt eine formalisierte Grundlage disziplinenübergreifend zu kommunizieren und man landet automatisch bei Word, Powerpoint und Visio. Die Systems-Engineering-Informationen sind viel zu wertvoll, um sie monolithisch in einem Office-Dokument abzulegen. Systems-Engineering mit Word zu machen, ist wie Mechanical Engineering mit Paint. What you see is what you get – und mehr auch nicht.
Ich würde SysML nicht als die neue Sprache des Requirements Engineerings bezeichnen. Es ist die Sprache des Systems Engineerings. Gleichzeitig hat es durch die SysML einen großen Schub im Requirements Engineering gegeben. Wir wissen seit Jahrzehnten wie wichtig Requirements Engineering für den Erfolg eines Projekts ist und trotzdem gelingt es nicht, es richtig einzusetzen. Requirements Engineering gehört sowohl zu den TOP5 der Erfolgsfaktoren eines Projekts als auch zu den TOP5 der Gründe für das Scheitern eines Projekts. Die SysML hat vor allem eine Bewegung angestoßen, Anforderungen nicht nur rein textuell zu betrachten, sondern sie wirklich zu modellieren. Ein modellierter Zustandsautomat kann eine Anforderung (oder eine Menge an Anforderungen) sein und muss dafür nicht in Text übersetzt werden.
Der Sprung von einer eher dokumentzentrierten und natursprachlichen Form der Produktdefinition zu einer Modellierung in SysML ist aber schon ein Paradigmenwechsel, gerade wenn es um mechanische oder mechatronische Systeme geht. Was hilft aus Ihrer Erfahrung heraus, diesen Paradigmenwechsel vollziehen zu können?
Es hilft, diesen Sprung auch wirklich als Paradigmenwechsel zu behandeln. Es genügt nicht, ein paar Lizenzen für ein Modellierungswerkzeug zu kaufen und eine Schulung zu besuchen. Es ist ein Veränderungsprozess in der Organisation und muss entsprechend umgesetzt werden.
Meine letzte Frage zielt ein wenig in die Zukunft. Gibt es schon Pläne zur Weiterentwicklung von SysML? Oder gibt es bereits Ideen und Visionen zur Entwicklungen nach SysML?
Am Horizont geht gerade langsam die SysML V2 auf. Aktuell arbeiten wir an den Anforderungen für die neue Version der SysML. Ende dieses Jahres soll der zugehörige Request for Proposal veröffentlicht werden. Danach geht es an die Umsetzung. Nach 10 Jahren Erfahrung mit der SysML V1 hat sich genug angesammelt, um die nächste Generation der Sprache zu entwickeln. Zu den Plänen gehören beispielsweise eine Unterstützung der Modellierung von Varianten und der Austausch von Modellinformationen.
Herr Weilkiens, ich danke Ihnen für dieses informative Gespräch und wünsche Ihnen weiterhin viel Erfolg und gutes Gelingen in Ihren Projekten.