Effektive Integration von PLM und MBSE für die Entwicklung mechatronischer Produkte

Es ist ein attraktives Versprechen: Bei der Entwicklung eines Produkts alle relevanten Abhängigkeiten stets im Blick zu haben und für alle Beteiligten zu visualisieren, um Produktentscheidungen frühzeitig, schnell und präzise zu treffen. Dies verspricht das Model-Based Systems Engineering (MBSE).

Aber warum eine weitere Abstraktionsebene für das Produkt, wo doch bereits die pragmatische Abbildung eines digitalen Zwillings schwierig genug ist? Die Antwort hat drei Teile:

1. Ein Modell im Sinne des oben beschriebenen Versprechens ist gar keine zusätzliche Ebene.
   Warum? Weil für mögliche Produktenscheidungen auch ohne ein Modell alle relevanten Informationen zusammengetragen werden müssen – meist auf “unsichtbaren Systemen” wie Excel – und dabei immer nur eine aufwändig erzeugte Momentaufnahme darstellen.
2. Ein Modell ist Datentyp höherer Ordnung.
   Zwar werden auch in einem Modell Anforderungen, Funktionen und Produktstruktur miteinander verknüpft, aber diese Verknüpfung ist sowohl bidirektional und dynamisch als auch – und das ist das Entscheidende – mit Bedeutung belegt.
   Was heißt das? Eine Anforderung ist eben nicht einfach mit einer bestimmten Funktion (oder Gruppe von Funktionen) verknüpft, sondern beinhaltet eine Aussage: Die Anforderung ist die Grundlage eine Funktion (also im Umkehrschluss: keine Funktion ohne zugehörige Anforderung) und die Funktion erfüllt die Anforderung: Diese Semantik, die Bedeutungsverknüpfung von Elementen, zieht sich konsequent durch das Modell.
3. Modelle bringen Agilität.
   Wer Produktentscheidungen treffen muss, der muss auch die Alternativen und die möglichen Auswirkungen der Entscheidung genau kennen. Der Kunde ändert eine Anforderung? Welche Funktionen des Produkts werden betroffen sein? Welche Komponenten müssen “angefasst” werden? Welche Engineering-Aufwände ergeben sich daraus? Modelle beantworten diese Fragen augenblicklich.

Darüber hinaus enthalten Modelle weitere entscheidungsrelevante Konstrukte, die in herkömmlichen Systemen kaum gemeinsam abgebildet werden können, wie Risiken und Bedenken, Einschränkungen (Constraints) sowie die den Anforderungen zugeordneten Verifizierungs- und Validierungsanforderungen und -aufgaben.

Eine belastbare Datenquelle?

Man hat also für die Steuerung des Produkts alles an einem Ort. Aus diesem Grund sprechen Systemingenieure von ihren Modellen oft als “authoritative source of truth,” was sich verdächtig nach dem Anspruch der PLM-Welt anhört. Es ist aber, wie wir gleich sehen werden, etwas völlig anderes.

Abseits womöglich konkurrierender Ansprüche stellt sich aber mit zunehmender Akzeptanz des modellbasierten Arbeitens die Frage, wie PLM-Systeme und MBSE miteinander arbeiten und wie sie miteinander integriert werden können. Zur Beantwortung dieser Frage muss man leider etwas weiter ausholen und einen kleinen Exkurs in die Geschichte des Entwicklungsdatenmanagements machen.

Die heutigen Systeme für die Verwaltung von Entwicklungsdaten sind historisch aus den ersten Engineering Data Management System der 80er Jahre des letzten Jahrhunderts entwachsen. Diese ersten Systeme waren wenig mehr als Dateiverwaltungen mit Workflow-Funktionen und einer Rechtverwaltung. Sie waren dokumenten-orientiert.

Mit dem Einzug komplexer 3D-CAD-Systeme in die Entwicklung reichte dieser dokumentenbasierte Ansatz jedoch nicht mehr aus. Die aufkommenden PLM-Systeme mussten mit den nativen Datenstrukturen der jeweiligen CAD-Systeme umgehen können, um die notwendige Detailtiefe zu ermöglichen. Diese Systeme waren strukturlisten-orientiert.
Diese neue Generation von System konnte damit erstmals Strukturlisten von M-CAD und E-CAD-System miteinander verknüpfen. Der Grundstein für mechatronische Datenmodelle war gelegt.

Verknüpfte Datenstrukturen: ein Trumpf in der Mechatronik

Auch Modelle verknüpfen Datenstrukturen: Unter anderem Anforderungen, Funktionen und die Produktstruktur. Der Unterschied zu PLM-Systemen liegt aber in der semantischen Qualität dieser Verknüpfungen. Was ist damit gemeint? Jede Verknüpfung hat eine Bedeutung. Diese Bedeutungen sind eindeutig und kennzeichnen, wie sich die Elemente eines Modells miteinander verhalten und in welcher Beziehung sie stehen. Damit entsteht ein Datenmodell von höherer Qualität, als es baum- oder listenartige Strukturen bieten können.

Jeder, der sich einmal mit der Integration von Daten beschäftigt hat, weiß, dass man eindeutige Verbindungen nur dann herstellen kann, wenn die jeweiligen Datenstrukturen einen ähnlichen Aufbau besitzen. Daten weitgehend unterschiedlichen Aufbaus lassen sich entweder gar nicht, nur sehr schwer oder nur auf einer hohen Ebene miteinander verknüpfen. Wie bekommt man nun einen runden Klotz in ein eckiges Loch?

Modelle “füttern” Systeme

Die Antwort ist einfacher als gedacht. Wenn man für einen Moment annimmt, dass ein Modell tatsächlich die gesamten entscheidungsrelevanten Informationen eines Produkts in Verknüpfung beinhaltet, dann erkennt man, dass dieses Modell sehr gut andere Systeme “füttern” kann: Die Anforderungen, die in das Modell einfließen, stammen in der Regel aus einem System für das Anforderungsmanagement.

Das Anforderungsmanagement erhält dann “angereicherte” Informationen aus dem Modell zurück, z.B. die mit den Anforderungen verknüpften Validierungs- und Verifikationsanforderungen und deren zugehörige Parameter.

Auch bei der Produktstruktur ist ein ähnliches Vorgehen denkbar. Allerdings mit einem wesentlichen Unterschied: Die Produktstruktur besteht aus verschiedenen einzelnen Elementen aus den Entwicklungsdomänen: Der Mechanik, der Elektronik und der Software. Jede dieser Entwicklungsdomänen besitzt aufgrund der jeweils eigenen Entwicklungsmethode auch eigene Datenmodelle und damit auch – im Sinne des föderierten Datenmanagements – ein eigenes Domänen-Datenmanagement (DDM).

Gemeinsame Modelle für MBSE und PLM

An dieser Stelle löst sich der gordische Knoten aufwändiger mechatronischer Integration: Da jedes DDM nativ die Datenstrukturen der eigenen Domäne versteht und die jeweiligen Entwicklungsdaten auch dort föderiert verwaltet werden, müssen sie nicht aufwändig in einem PLM-System zusammengebunden werden.

Dieser Kontext des Gesamtprodukts entsteht bereits im Modell, denn hier “zielen” alle Elemente der Produktstruktur auf die Funktion, zu deren Erfüllung sie beitragen. Die Funktionsstruktur des Modells wirkt in diesem Sinne wie ein “gemeinsamer mechatronischer Nenner”.

In einem solchen Szenario kommt einem PLM-System immer noch eine wichtige Rolle als Rückgrat und Taktgeber des Entwicklungsprozesses zu. Die leidige Integrationsproblematik jedoch hat sich mit dem modellbasierten Arbeiten zumindest teilweise aufgelöst.

In unserem Webinar lernen Sie mehr über die Möglichkeiten, welche die modellbasierte Entwicklung mit Hilfe der MBSE-Software GENESYS für die Formulierung, Klärung und Umsetzung von komplexen Anforderungskatalogen bietet.

Jetzt ansehen