Der Weg zum cyber-physischen Produkt

Moderne cyber-physische Produkte basieren auf einer Kombination von digitalen und realen Komponenten und entstehen durch das Zusammenwirken verschiedener Ingenieursdisziplinen und Expertensystemen, deren Komplexität und Vernetzung stetig zunehmen. Durch den Trend zu variantenreichen und kundenindividuellen Produkten wird es immer wichtiger, die Zusammenhänge von Anforderungen, Lösungsarchitekturen und Optimierungszyklen mit Simulation und Verifikation in einem Digital Thread (Beziehungsnetzwerk) abzubilden, um die Prozesseffizienz und Innovationskraft zu steigern (vgl. Abbildung 1).

Im Zuge von Industrie 4.0 erhalten Produkte vermehrt digitale Fähigkeiten mit einer datentechnischen Vernetzung. Solche intelligenten, cyber-physischen Systeme (CPS) bestehen aus drei Kernelementen:

CPS-Produkte sind somit nicht nur mechanisch in 3D modelliert, sondern haben einen mechatronischen Charakter, verfügen über Intelligenz und können über eine Datenverbindung kommunizieren. Hierdurch werden neue digitale Fähigkeiten ermöglicht: Dinge können etwa ortsunabhängig – ohne physisch beim Produkt sein zu müssen – remote überwacht und kontrolliert werden. Darüber hinaus lassen sich Produkte weiter optimieren und automatisieren. Anstelle der bisherigen Produktlieferung als Basis der Rechnungsstellung rückt die Wirkung eines Produkts in den Fokus von Verrechnungsmodellen. Unternehmen entwickeln dafür zunehmend digitale Geschäfts­modelle. Als Beispiel hierfür sei das «Power-by-the-hour»-Modell des britischen Triebwerkherstellers Rolls-Royce genannt. Dabei werden Hersteller nicht mehr dazu verpflichtet, das Turbinentriebwerk zu kaufen, sondern bezahlen lediglich noch die Betriebsstunden.

Möglich werden leistungsfähige CPS-Produkte einerseits durch einen höheren Software- und Elektronik-Anteil gegenüber der Mechanik sowie durch eine größere Produktkomplexität. Andererseits müssen insbesondere in den Innovations- und Entwicklungsprozessen immer wieder neue Lösungen gefunden sowie neue Wege beschritten werden, was einen größeren Abstimmungsbedarf zwischen den Ingenieursdisziplinen erfordert.

Startpunkt einer jeden Entwicklung ist die Klärung und Erfassung der Anforderungen, die möglichst systematisch in Form von Anforderungsobjekten definiert werden sollten. Ausgehend von Produktanforderungen auf übergeordneter Geschäfts- und Marketing-Ebene sowie aus Sicht der Produktnutzung, werden Anforderungen – je nach angewendeter Methodik – in präziser formulierte Anforderungen der Technik heruntergebrochen und der Input mehrerer Teams zusammengetragen. Als Ergebnis entsteht so eine Anforderungsstruktur über eventuell mehrere Ebenen. Daraus können Einzelanforderungen mit Lösungselementen verlinkt werden. Und über einen Report lässt sich auch die klassische Anforderungsliste für ein Produkt als Dokument generieren.

Der nächste Schritt ist eine Funktionsanalyse für das zu entwickelnde Produkt, wofür zunächst die Gesamtfunktion bestimmt werden muss (zum Beispiel «Drehmoment wandeln» für ein Getriebe). Danach wird die Gesamtfunktion in einem konstruktionsmethodischen Top-down-Vorgehen stufenweise zerlegt, um die einzelnen Soll-Funktio­nen des Produkts zu erhalten. Diese sind lösungsneutral formuliert, damit noch offenbleibt, welche Ingenieursdisziplin zur Lösung ausgewählt wird (die Elektronik, die Mechanik etc.).

Danach erfolgt der Einstieg in den Lösungsfindungsprozess, wofür auf logischer Ebene Wirkprinzipien betrachtet werden, um den Funktionselementen eine Lösung zuordnen zu können (gegebenenfalls mithilfe des morphologischen Kastens). Anfangs ist das zwar noch wenig detailliert, aber es lässt sich schon erkennen, welche Disziplin angedacht ist (z. B. Elektromotor). Diese logische Abstraktionsebene ist notwendig, um für die Soll-Funktionen optimale Lösungen zu finden. Im Allgemeinen ist das nicht direkt auf Teileebene möglich, da eine Funktion nicht durch ein Einzelteil gelöst werden kann, sondern ein Wirkflächenpaar von mehreren Teilen benötigt wird. Auf dieser logischen Abstraktionsebene sind auch die sogenannten 1D-Simulationen anzuordnen, um Eigenschaften möglichst früh durch virtuelle Tests abzusichern. Abschließend kann der Übergang auf die physikalische Teileebene erfolgen, wobei den logischen Lösungselementen eine konkrete Lösung in Form von Einzelteilen oder Baugruppen zugeordnet wird. Auf dieser Konkretisierungsebene befinden sich die bekannten CAD-Modelle, kontinuierliche 3D-Simulationen (FEM: Finite-Elemente-Methode, CFD: Computational Fluid Dynamics, MKS: Mehrkörpersimulation) sowie die Produktstruktur­definition als Engineering BOM (Konstruktionsstückliste), die im weiteren Downstream-Prozess benötigt wird.

Die oben beschriebene Vorgehensmethodik über diese vier Ebenen wird im Englischen mit der Abkürzung RFLP (Requirements, Functional, Logical, Physical) bezeichnet und gehört zur Domäne des sogenannten Model Based Systems Engineerings (MBSE). Die Anwendung einer solchen Methodik empfiehlt sich immer dann, wenn eine komplexe Problemstellung bewältigt werden muss oder wenn für eine Aufgabenstellung ein komplett neuer Lösungsansatz erforderlich ist. In der IT-Landschaft haben sich dafür spezielle System-Modeling-Applikationen etabliert, deren Einbindung in die Enterprise-IT aufgrund ihres interdisziplinären Charakters eine besondere Herausforderung darstellt.

Für die Anforderungshandhabung stehen leistungsfähige Requirements-Engineering-Applikationen zur Verfügung. Gleichzeitig verfügen die Enterprise-IT-Systeme über Datenmodell-Erweiterungen für Anforderungen – allen voran die Product-Lifecycle-Management-Systeme (PLM). Aufgrund ihrer zentralen Bedeutung sollte die Gesamtheit der Produktanforderungen stets im PLM-System verfügbar sein, wobei Teilaspekte wie zum Beispiel reine Software-Anforderungen durchaus auch in einem Application-Lifecycle-Management-System (ALM) gepflegt und mit PLM synchronisiert werden können.

Für Systemmodelle ist zu beachten, dass diese zwar durch Systemingenieure erstellt werden, aber nicht nur Arbeitsergebnis einer Disziplin sind, sondern eine zentrale Sonderstellung im interdisziplinären Engineering-Prozess einnehmen. Die Inhalte des Systemmodells beschreiben dabei konzeptionelle Lösungsansätze und die Aufgabenteilung zwischen den beteiligten Ingenieursdisziplinen. Deshalb werden sie als Objekte benötigt, um den interdisziplinären Entwicklungsprozess über Teams und Abteilungen zu orchestrieren. Ähnlich zum strukturellen Informations­inhalt von CAD-Systemen (besteht aus/contains-Beziehungen) wird das Systemmodell somit nicht nur als Dokument abgelegt, sondern auch auf Objektebene synchronisiert.

Zentraler Unterschied gegenüber CAD-Integrationen ist jedoch die detaillierte und stark variierende Systemmodellierung auf abstrakter Ebene, die in der Tiefe ohnehin nur von Systemingenieuren verstanden wird. Daher ist für die Integration von System Modeling eine starre 100-Prozent-Synchronisation nicht sinnvoll, sondern ein flexibler Overlay-Approach zu bevorzugen, wo je nach Bedarf in einem Produktmodell sinnvolle Ankerelemente zur Synchronisation spezifisch ausgewählt werden können. Unwichtige Detailobjekte werden nicht synchronisiert und sind nur für die Fachdisziplin sichtbar. Hauptvorteil eines solchen Overlay-Ansatzes sind hocheffiziente Innovationsprozesse, die völlig flexible Digital-Thread-Aus­prägungen über die beteiligten Disziplinen zulassen – einschließlich der Verifikation geforderter Eigenschaften durch parametergesteuerte Simulationen.

Unternehmen mit der Zielsetzung, leistungsfähige CPS-Produkte zu entwickeln, können ihre Innovationskraft maßgeblich steigern, indem sie systemgetriebene Innovationsprozesse einführen und diese mit spezialisierten Appli­kationen und einer flexiblen IT-Architektur durchgängig unterstützen. Dadurch werden nicht nur bessere und intelligentere Produkte ermöglicht, sondern auch eine deutlich höhere Prozesseffizienz im Unternehmen. Für varianten-reiche oder kundenindividuelle Produkte und den Markterfolg wird das zukünftig immer wichtiger.