Modellbasiertes Systems Engineering

Der Zeitpunkt ist ideal, sich mit Systems Engineering auseinander-, oder besser noch: zusammenzusetzen. SAP hat vor Kurzem mit Intelligent Product Design (IPD) eine Cloud-Lösung lanciert, die die tiefe Integration von Systems-Engineering-Szenarien in die PLM- und SAP-Infrastruktur ermöglicht und damit modellbasiertes Systems Engineering (MBSE) industrialisiert.

Zu den Highlights von SAP IPD gehören: modellbasiertes Anforderungsmanagement und Systems Engineering; Kollaborationsfunktionen für die workflowbasierte Zusammenarbeit; Testmanagement zur Verifizierung und Validierung; und Anforderungserfassung aus dem Produktbetrieb.

Der große Vorteil von IPD ist, dass keine Schnittstellen in die SAP-Welt mehr entwickelt werden müssen und CAD-agnostisch gearbeitet werden kann. Die bisherigen ersten Gehversuche, sich mit Free­ware-Produkten in diese Richtung zu bewegen, wurden oftmals von der eigenen IT-Abteilung jäh beendet. Mit IPD ist es möglich, den Anfangspunkt von PLM mittels umfassender Anforderungsmodellierung vorzuverlagern und die Anknüpfung an SAP-Objekte nicht erst mit SAP Engineering Control Center (ECTR) zu starten.

Der Enterprise Architect Designer for IPD (Werkzeug für die modellbasierte Systementwicklung) arbeitet mit SysML. Standardisiert ist die Beschreibungssprache SysML schon lange, doch von einer breiten Akzeptanz konnte bisher nicht gesprochen werden. SysML verbessert die disziplinübergreifende Kommunikation erheblich, weil sich Systeme durch Modelle ganzheitlich beschreiben lassen.

E-3 Gesprächspartner Jakob Röhrenbach, Account Executive Digital Supply Chain SAP bei Cenit, gibt Hilfestellung: „Bei Systems Engineering besteht die Herausforderung darin, die in den Systemmodellen verborgenen Mehrwerte in den Prozessen transparent zu machen.“

Die Methoden zu Systems Engineering sind seit Langem bekannt und zumindest Wissensfragmente hierzu sind in nahezu jedem Betrieb vorhanden, betont Röhrenbach; notwendig sei aber der Impulsgeber von außen, wenn es darum geht, Systems Engineering nachhaltig und umfassend zu etablieren. Und genau in dieser Rolle sieht man sich:

„Cenit war als SAP-Partner von Anfang an fokussiert auf die frühen Phasen des Produktlebenszyklus: auf die Entstehung der 2D- und 3D-CAD-Modelle und deren Überführung in weitere Downstream-Prozesse, etwa im Bereich der Fertigung. Begleitet haben wir unsere Kunden auch bei der Einführung von 3D-Master-Konzepten. Entstanden ist daraus eine enorme Kompetenz in Form einer Beratungsmannschaft und Expertise, dies in einem Lieferkettenmodell abzubilden“, sagt Röhrenbach.

Digital Supply Chain

SAP hat mehrere E2E-Ansätze im Köcher, unter anderem einen für die Digital Supply Chain. In der Lesart der Walldorfer ist diese Wertschöpfungskette Design to Operate (D2O) unterteilt in die Phasen Design, Plan, Build, Deliver und Operate, wobei sich die Domäne von MBSE auf Design im D2O-Zyklus konzentriert, doch eben auch für die anderen Abschnitte Wertbeiträge liefern kann.

„Bislang spannte sich die D2O-Kette häufig über Daten- und Abteilungssilos mit System- und Organisationsbrüchen. MBSE kann hier sowohl methodisch wie auch prozesstechnisch einen Ansatz bieten, nicht nur in den Engineering-Disziplinen auf ein domänenübergreifendes Produktmodell zurückgreifen zu können, sondern auch Aspekte des gesamten PLM-Zyklus zentral und neutral vorzuhalten“, sagt der zweite E-3 Gesprächspartner, Christian Markus, Experte für MBSE und SAP IPD bei der Cenit-Tochter Coristo, und betont:

„Das Besondere bei der neuen Lösung SAP IPD ist ihre tiefe Integration und damit der Zugriff auf SAP-Business-Objekte.“

Was unterscheidet den Anspruch des MBSE auf Durchgängigkeit bei der Kommunikation mit den verschiedenen Stakeholdern von jenem des 3D-Masters?

„Im Grunde genommen sind es zwei parallel laufende Ansätze, die sich gegenseitig ergänzen. Die Wirksphären sind voneinander getrennt, denn das Systemmodell umfasst alle entwicklungsrelevanten Inhalte und Zusammenhänge, während im 3D-Master geometriebasiert Informationen, etwa für die Fertigung, mitgeführt werden. Insbesondere Anforderungen und deren Beziehung zu den Änderungen werden über das Systemdiagramm widerspruchsfrei im Systemmodell abgebildet“, erklärt Röhrenbach.

Das Systemmodell umfasst sogenannte Satisfied-Beziehungen zur Anforderungsmodellierung und Verified-Beziehungen zu Testszenarien. Röhrenbach gibt aber zu bedenken, dass Systems Engineering nicht nur als reines Requirements Engineering, also als Anforderungsmodellierung, verstanden werden sollte, obwohl dies natürlich ein ganz wesentlicher Punkt dabei sei. Gemeinsam sei beiden Ansätzen, MBSE und 3D-Master, dass sie beide auf den digitalen Zwilling einer serialisierten (Produkt-)In­stanz einzahlen.

„Das MBSE-Modell ist dann sehr wertvoll, wenn ein virtueller Prototyp erzeugt werden soll, weil alle strukturierten Wirkzusammenhänge quasi auf Abruf bereitstehen und zu jeder Zeit transparent ist, was getestet wird“, ergänzt Christian Markus – MBSE-Modelle stünden am Anfang eines digitalen Fadens, der zum digitalen Zwilling führen kann.

Digitaler Zwilling

Modellbildung im Sinne von Systems Engineering ist für die meisten Unternehmen durchaus in Sichtweite. Sie werden ja täglich über die Autorenwerkzeuge wie MCAD oder ECAD neu erzeugt beziehungsweise verfeinert. Jedoch gibt es im Bereich des Anforderungsmanagements noch viele Grauzonen, weil hierbei gerne mit MS Excel gearbeitet wird.

„Das Wichtige am Anfang ist, mit einem klaren Willen Systems Engineering anzugehen. Die Ist-Aufnahme ist notwendig, zum Beispiel um sich zu vergegenwärtigen, wie viel davon bereits im Haus verankert ist: Wer im Unternehmen ist daran interessiert? Wer ist informiert? Und wer ist begeistert von MBSE?“, fragt Markus in der Rolle des Change Agent.

Nun ist die Zeit reif für ein Beispiel. Der bekannte Systemdenker Russell Ackoff hat sich intensiv mit Objektzusammenhängen und agilen Grenzen des Machbaren auseinandergesetzt:

„Probleme müssen nicht gelöst, sondern aufgelöst werden“ ist einer seiner starken Sätze, von denen man sich auch in der Produktentwicklung inspirieren lassen kann. Gemeinsam mit SAP hat Cenit den Trainingsplan eScooter entworfen.

„Die Entscheidung, einen eScooter als System zu modellieren, war motiviert von der Idee, einen weitgehend mechanischen Motorroller zu einem gelebten IoT-Szenario mit Elektrorollern in Free-Floating-Sharing-Systemen zu erweitern“, sagt Markus.

Im Zentrum des Trainingplans steht das rekuperative Bremsen bei den Elektrorollern. Lohnt sich dies bei einem derart leichten Fahrzeug oder ist eine Segelfunktion nicht doch besser? Das Feedback aus dem Feld (per Service-App) ergab, dass sich die Kunden gerade beim Bergabfahren eine Rekuperation wünschten, da sie sich scheuen, die Bremsen heiß zu fahren.

Bisher wurde diese Art von Rückgewinnung lediglich aus der Sicht des Energiemanagements diskutiert, nicht jedoch aus der Sicht einer Customer Experience. Außerdem ließ die Service-App verlautbaren, dass die verbauten Scheibenbremsen nicht die Anforderungen über die gesamte Betriebszeit des Scooters erfüllen würden.

„Man kommt auf intuitive Weise weg von einem Pipe und hin zu einem Platform Thinking, bei dem die Zielgruppe aktiv das Produktdesign mitgestaltet. Hier offenbart sich der Systemgedanke, dass nämlich das Produkt nicht allein im Schaufenster steht, sondern in einem Nutzungs- und Umweltkontext“, sagt Röhrenbach und Markus fügt hinzu:

„Dahinter steht der Ansatz, viel näher am Markt zu entwickeln als bisher. MBSE auf Basis von SAP IPD ist genau das Instrument, dieses agile Entwickeln zu praktizieren, denn über IPD ist es möglich, eine viel größere Anzahl an Rückmelde­kanälen für ein Produkt zu erschließen.“

Die meisten Ingenieure denken intuitiv in Modellen, auch wenn sie vielleicht eine andere Terminologie dafür verwenden.