Die Rolle von MBSE in der digitalen Transformation von Elektrotechnik und Elektronik

Die digitale Transformation ist ein Trend, der im letzten Jahrzehnt immer mehr an Dynamik gewonnen hat. Sie wird heute in allen Bereichen der Wirtschaft, der staatlichen Verwaltung, der Gesellschaft und des täglichen Lebens in zunehmendem Maße aufgegriffen und erfährt aufgrund der aktuellen Covid-19-Situation einen massiven Auftrieb. Es lohnt sich daher, die möglichen Auswirkungen auf die Methoden und Prozesse in der Elektrotechnik und Elektronik genauer zu betrachten.

Es gibt viele Definitionen für den Begriff “Digitale Transformation”. Unabhängig davon, welche Sie bevorzugen, sie haben alle einen Aspekt gemeinsam: Die digitale Transformation sollte über eine einfache Übertragung von analogen Dokumenten und Prozessen in den digitalen Bereich hinausgehen. Es sollten vielmehr neue Wege und Möglichkeiten erforscht werden, um die heutigen Methoden und Prozesse für mehr Effizienz und schnellere Innovation zu verbessern.

Der Aufstieg des Digitalen Zwillings

Derzeit entsteht in diesem Zusammenhang eine Vielzahl von innovativen Geschäfts- und Prozessmodellen. Das Spektrum reicht dabei von der Zusammenarbeit in der Wertschöpfungskette bei der Produktentwicklung über Smart Sourcing und Produktion bis hin zu Produkten, die als Dienstleistung angeboten werden. Ein Beispiel: Der Kunde kauft Mobilität statt eines Autos, oder Produktionsleistungen statt einer Maschine. Was auf den ersten Blick als bloße Wortklauberei erscheinen mag, hat jedoch das Potenzial, etablierte Industrien tiefgreifend zu verändern.

Als Schlüssel für all diese Geschäfts- und Prozessinnovationen gilt gemeinhin der “Digitale Zwilling” – eine umfassende digitale Abbildung des Produkts oder der Dienstleistung mit all ihren Wandlungen im Verlauf Produktlebenszyklus – von der Anforderung über den Entwurf und die Fertigung bis hin zum ausgelieferten und gewarteten Produkt. Dies wiederum erfordert eine durchgängige digitale Prozesskette, die die in den jeweiligen Anwendungsfall benötigten Informationen schnell, zuverlässig und automatisiert bereitstellt.

Engineering-Daten für digitale Produkt- und Prozessinnovationen nutzen

In der Produktentwicklung und im Engineering gibt es bereits einen riesigen Bestand an digitalen Informationen, die von einer Vielzahl von Engineering-Anwendungen im Verlaufe der technischen Wertschöpfungskette erzeugt werden: Von Anforderungen, die das beabsichtigte Verhalten eines Produkts oder Systems beschreiben, über Funktionsbeschreibungen und Modelle, mechanische und elektrische/elektronische CAD-Daten, Simulations- und Testergebnisse bis hin zu den Artefakten der Betriebssoftware von Produkten und Anlangen.

In der Regel sind einige, aber bei weitem nicht alle dieser Anwendungen mit einer Art Informations-Backbone (auch als PDM-Schicht bezeichnet) verbunden. Dies Backbone liefert wiederum Informationen an Anwendungen und Umgebungen auf Unternehmensebene, etwa für Einkauf, Konfiguration, Änderungs- und Freigabemanagement. Und schließlich werden auch Daten an die Fertigung weitergegeben, um die Produktion und Montage zu steuern (siehe Abbildung 1: Eine typische IT-Landschaft für die Produktentstehung).

Diese Vielfalt und Heterogenität der Datenformate und -strukturen, die von den verschiedenen Domänen generiert werden, macht es schon nicht einfach, Punkt-zu-Punkt-Schnittstellen zu erstellen, geschweige denn heterogene Daten und Informationen zu vernetzen, um damit die verschiedenen Produktentstehungsprozesse wie Konfigurationsmanagement, Änderungsmanagement oder Fertigungsfreigabe zu versorgen.

Keine etablierten Standards für ein Prozessmodell zur digitalen Produktentwicklung

Betrachtet man die heute eingesetzten Engineering-Applikationen, so findet man das erste Hindernis bereits beim Versuch einer Darstellung eines elektromechanischen (auch “mechatronischen”) Produktmodells. Hier wird die Konsistenz auf Stücklistenebene durch die Verschiedenheit der in MCAD und den ECAD-Lösungen verwendeten Datenmodelle erschwert:

Während in der mechanischen Welt eine Baugruppe (z. B. ein Motor) durch einfaches Kopieren in der Stückliste in mehreren Instanzen verwendet werden kann, müssen in der elektrischen Welt eindeutige elektrische Referenzbezeichner verwendet werden, um die jeweils spezifische Verkabelung, Steuerung und den Absicherung der einzelnen Baugruppe zu bestimmen (Hinweis: Zuken verfügt mit seiner DS-2-Domain-Datenmanagement-Technologie über eine Lösung für dieses häufige Dilemma, mit der die Lücke zwischen mechanischen und elektrischen Baugruppen auf der Ebene des Stücklistenmanagements geschlossen werden kann.

Info DS-2

Wenn wir einen Schritt weiter gehen und Integrationsmodelle betrachten, die den gesamten Produktlebenszyklus umfassen, wie z. B. das verbreitete V-Modell, stellen wir fest, dass es keinen etablierten IT-Standard zur Unterstützung eines digitalen Prozessmodells gibt, das den gesamten Kreislauf von den Anforderungen über das detaillierte Design bis hin zu den Fertigungsergebnissen umfasst.

Warum ist das so? Zunächst einmal gibt es den gerne zitierten Produktentwicklungsprozess in der Realität gar nicht. Das, was gemeinhin als “Produktentwicklungsprozess” bezeichnet wird, ist in Wirklichkeit eine Kombination aus mehreren Aktivitäten und Teilprozessen, die meist parallel ablaufen und häufig in Wechselwirkung zueinander stehen, wie z. B. Projektmanagement, Konzeptentwicklung, Detailkonstruktion oder Änderungs- und Konfigurationsmanagement, um nur einige zu nennen. Das CAD-System ist nur eine Applikation in einer Umgebung, die aus mehreren Systemen und Prozessen besteht, und keinesfalls das Trägermedium des “Produktentstehungsprozesses”.

Die Produktentwicklung ist keine lineare Abfolge von Aktivitäten

Das CAD-Modell ist weder der Ausgangspunkt noch das Ende des Produktentwicklungsprozesses – es ist nur ein mehr oder weniger integriertes Teilsystem eines Gesamtsystems von verschiedenen Einzelsystemen. Und bei CAD selbst muss darüber hinaus zwischen den Disziplinen Mechanik, Elektrik und Elektronik unterschieden werden.

Im Idealfall wird ein neues Produkt zunächst als hierarchisch organisiertes, konsistentes System von Anforderungen beschrieben, die dann in funktionale und logische Strukturen überführt werden, die sukzessive in CAD-Daten und Stücklisten detailliert werden. Im folgenden Diagramm ist das schematisch dargestellt.

Ohne zu sehr ins Detail gehen zu wollen, können wir in dieser Abbildung zwei Aspekte erkennen: Erstens (von links nach rechts betrachtet) lassen sich Anforderungen, Funktionen, logische Elemente und Baugruppen im Verlauf der Entwicklung nicht 1:1 übersetzen. Und zweitens werden physikalische Elemente und Baugruppen (die dunkelblauen Kreise) von verschiedenen Prozessen (die hellblauen Quadrate) genutzt. Das Ergebnis ist eine Matrix dynamischer Beziehungen, die sich kaum als lineare Abfolge darstellen lässt, wie es das V-Modell suggeriert.

Single Source of Truth” – ein risikoreicher Weg im Umfeld der digitalen Transformation

Aus den vorgenannten Überlungen wird deutlich, dass es ein gewaltiges Unterfangen wäre, die Vielzahl von Anwendungen und Prozessbeteiligten, die in der Produktentwicklung tätig sind, über direkte Schnittstellen in einem monolithischen “Single-Source-of-Truth”-Ansatz zu verbinden.

Der Versuch, heterogene Anwendungen und Formate in ein monolithisches System zu pressen, erfordert nicht nur einen enormen Programmieraufwand, sondern birgt auch die Gefahr, dass die Flexibilität verloren geht, neue Best-in-Class-Player und -Lösungen, die im Laufe der Zeit auftauchen könnten, zu integrieren.

Darüber hinaus sollte die Digitale Transformation nicht an den Toren eines einzelnen Unternehmens Halt machen: Um die Effizienz zu maximieren, muss sie schließlich das erweiterte Ökosystem der Zulieferer-Werkbank einbeziehen – und spätestens hier gerät die Idee einer “Single-Source-of-Truth”-Umgebung ins Stocken.

Aus Sicht des Kunden ist es daher sinnvoll, auf ein Höchstmaß an Flexibilität zu achten und sich nicht in die Abhängigkeit von einem einzigen IT-Lieferanten und einen “Single-Source-of-Truth”-Ansatz zu begeben.

Eine zukunftsweisende Alternative: Verteilte “light-weight” Informationssysteme

Als Alternative zu hochintegrierten und inhärent unflexiblen “Single Source of Truth”-Ansätzen schlagen wissenschaftliche Vordenker wie Prof. Martin Eigner vom Lehrstuhl für Virtuelle Produktentwicklung der Technischen Universität Kaiserslautern, ein “federated light-weight information backbone Konzept” vor.

Dieses Konzept basiert auf einem Mix aus schlanken, disziplinübergreifenden Integrationen, offenen Webservices, Teamdatenmanagement-Anwendungen und verknüpften Datenmodell-Integrationen (REST-Technologie). Bei diesem Ansatz können die Informationen, die zur Versorgung der verschiedenen Prozesse entlang des Produktentwicklungslebenszyklus benötigt werden, in der erforderlichen Tiefe extrahiert werden, die durch die spezifischen Anforderungen der einzelnen Prozesse bestimmt wird.

Aber wie lässt sich bestimmen, welche Art und welche Tiefe von Informationen für eine spezifischen Produktentwicklungsprozess benötigt werden, wenn es keinen etablierten Industriestandard gibt?

Neue Wege erschließen mit MBSE

Zunächst einmal ist es ratsam, sich über die zukünftige Prozess- und Produktarchitektur klar zu werden, bevor man sich an die Umsetzung macht. Hier kommt das Model-Based Systems Engineering (MBSE) ins Spiel

Zwar wird diese Methodik meist mit Produkt- und Systemmodellierung in Verbindung gebracht, doch sie ist gleichermassen auch auf die Modellierung von IT- und Prozessarchitekturen anwendbar. Siehe dazu auch die Definition von INCOSE, der weltweiten Vereinigung von Systemingenieuren: “Model-Based Systems Engineering (MBSE) ist die formalisierte Anwendung digitaler Modellierung … zur Unterstützung von Systemanforderungen, Systemarchitektur, Design, Analyse, Verifikation und Validierung, Prozessplanung und Service”.

Mit den Modellierungs- und Verifikationsmöglichkeiten von MBSE ist es möglich, sowohl Konzepte für eine zukünftige Produktarchitektur als auch die dazugehörigen Entwicklungsprozesse und Arbeitsabläufe zu modellieren.

Mit einem MBSE-Tool wie GENESYS der Zuken-Tochter Vitech kann zunächst der Status quo einer bestehenden Produkt- und Prozessarchitektur modelliert und zu analysiert wwerden, der dann die Basis für die Modellierung der  Transformation zu liefert, bevor man Hand an die Produktivumgebung legt. Sowohl Produkt- als auch Prozessmodelle können simuliert und validiert werden, bevor man sich an die Umsetzung der digitalen Transformationsprojekte macht.

Info GENESYS

Wie geht’s weiter?

Die digitale Transformation der Produktentwicklung gewinnt in der Fertigungsindustrie zunehmend an Fahrt, obwohl sich bisher noch keine Standards herausgebildet haben. Um mit diesem Megatrend Schritt zu halten, ist es notwendig, rechtzeitig innovative Prozess- und Geschäftsmodelle auszuloten und schrittweise umzusetzen.

In diesem Artikel haben wir gezeigt, wie MBSE dabei helfen kann, das Risiko bei der Entwicklung und Verifizierung digitaler Prozessmodelle zu minimieren und somit das Risiko von IT-Implementierungsprojekten zu minimieren.

Bei unseren Betrachtungen haben wir uns hauptsächlich auf Ansätze zur Weiterentwicklung der IT-Infrastruktur konzentriert, welche die Digitalisierung der Prozessentwicklung unterstützen. Weitere Lektüre zum Thema digitale Produktentwicklung mit Hilfe von MBSE finden Sie in unserer umfangreichen Ressourcenbibliothek.

Quellenhinweis

Der vorliegende Beitrag basiert auf einer Präsentation von Oliver Hechtl, Head of Data Management and Integration, Zuken Europe. Eine Aufzeichnung dieser Präsentation kann in der Zuken-Ressourcenbibliothek abgerufen werden:

Zum Webinar

Weitere Informationen:

• Model-Based Systems Engineering mit Genesys
• eBook: Einführung in Model-Based Systems Engineering (MBSE)
• Whitepaper: One Model, Many Interests, Many Views