Interdisziplinäre Produktentwicklung – Modellbasiertes Systems Engineering

1 Einleitung

Innovative, interdisziplinäre Produktentwicklung erfordert ein Überdenken von heutigen Methoden, Prozessen, IT-Lösungen und Organisationsformen. Insbesondere fehlt es an Unterstützung durch geeignete IT-Lösungen für die funktionale Beschreibung und Auslegung von Systemarchitekturen. Für die disziplinübergreifende Systemmodellierung der Konzeptphase gibt es nur eingeschränkte IT-Unterstützung. Elektronik und Software stellen einen immer stärkeren Anteil im Produktentwicklungsprozess (PEP) dar. Konstruktions- und Entwurfsmethoden dieser Disziplinen sollten auf den Prüfstand gestellt und ihre Tauglichkeit für einen modernen, interdisziplinären Konstruktionsansatz überprüft werden. Model Based Systems Engineering (MBSE) könnte sich als integrative Methode etablieren und eine Brücke zwischen den verschiedenen Ingenieurdisziplinen bilden. Als „Enabler“ für das MBSE werden Systemmodellierungssprachen wie  SysML vorgestellt, die ein Werkzeug für eine interdisziplinäre Systembeschreibung darstellen. Auf konkreterer Stufe können Simulationssprachen wie Matlab/Simulink oder Modelica eine frühe multidisziplinäre Simulation ermöglichen, die in Verbindung mit Systembeschreibungssprachen eine frühe Konzeptformulierung erlaubt. Dieser Beitrag soll neue Methoden, Prozesse und IT-Lösungen für eine interdisziplinäre, virtuelle Produktentwicklung aufzeigen. [1]

Model Based Systems Engineering (MBSE) ist ein multidisziplinärer Ansatz mit dem Ziel, eine ausgewogene Systemlösung als Reaktion auf diverse Stakeholder-Bedürfnisse zu entwickeln [2]. MBSE hilft dem Ingenieur den Überblick über komplexe Systeme zu behalten, den Zusammenhang zu verstehen und die Spezifikation und damit alle definierten Anforderungen zu erfüllen. Während klassische Methoden des Systems Engineerings papier- oder dokumentenbasiert sind, basiert MBSE auf digitalen  Systemmodellen. Diese erlauben die Erfassung der Komplexität und erleichtern den Informationsaustausch zwischen den Disziplinen. Modellierungssprachen ermöglichen eine modellbasierte Spezifikation eines Produktes auf einer allgemeinen Ebene, die für alle an der Entwicklung beteiligten Disziplinen verständlich ist. Das Problem der Integration der Komponenten während des Entwicklungsprozesses kann durch die Verwendung solcher Modellierungssprachen möglichst früh in Angriff genommen werden, indem die Definition von Korrelationen zwischen Systemanforderungen, Funktionen, Struktur und Verhalten definiert wird.

Darüber hinaus werden in heutigen Unternehmen die im Entwicklungsprozess anfallenden Daten meist durch Product Lifecycle Management (PLM) -Lösungen verwaltet, so dass die Integration einer funktionalen Produktbeschreibung in PLM die interdisziplinäre Zusammenarbeit frühzeitig unterstützen kann.

2 Ausgangssituation
Die Realisierung der vielfältigen Funktionalitäten von Produkten hat sich in den letzten Jahren von rein mechanischen zu mechatronischen Komponenten verändert. Funktionen und Verhalten als eine neutrale Beschreibung werden mehr und mehr wichtig, wenn es um eine interdisziplinäre Entwicklung geht. Die Komplexität der Integration mechatronischer Komponenten während des PEP steigt durch die starke Beteiligung der verschiedenen Disziplinen. Darüber hinaus spielt Software eine immer größere Rolle im Kontext der modernen interdisziplinären Produktentwicklung. Kommunizieren Produkte miteinander, wird von Cyber-Physical Systems bzw. cybertronischen Systemen gesprochen. Aktuelle Forschungsinitiativen konzentrieren sich auf technologische Fortschritte mit Software-intensiven, eingebetteten Systemen in technischen Produkten [3]. Software wird in Zukunft eine Vielzahl von weiteren Produktfunktionen ermöglichen. Dies setzt eine noch stärkere Einbeziehung des Software-Engineerings in den PEP voraus. Deshalb ist es wichtig, die Transparenz zwischen den Disziplinen zu erhöhen.

Es fehlt jedoch an etablierten, d.h. industriell eingesetzten Methoden, Prozessen und IT-Lösungen für die disziplinübergreifende Entwicklung interdisziplinärer Systeme und damit intelligenter und vernetzter Produkte und Produktionssysteme. Dabei hat sich gerade in Deutschland in den 60er und 70er Jahren eine auf Funktionen basierende Entwicklungsmethodik mit abgeleiteten Entwicklungsprozessen herausgebildet, die natürlich zu dieser Zeit noch nicht auf formalen Sprachen aufsetzte und schwerpunktmäßig mechanisch geprägt war. Parallel haben sich international im Wesentlichen auf formalen Sprachen basierende Software-Entwicklungsmethoden ausgebildet (siehe Abbildung 1).

Seit den 50er Jahren wurde insbesondere bei der amerikanischen Luft- und Raumfahrt und in großen Militärprojekten Systems Engineering (SE) als interdisziplinärer, dokumentengetriebener Ansatz zur Entwicklung und Umsetzung komplexer technischer Systeme in großen Projekten definiert und eingesetzt. Dieser Ansatz wurde aus Sicht der Software- und Elektronikindustrie permanent ausgebaut und bietet heute Modellierungs- und Simulationsunterstützung von komplexen, stark vernetzten Systemen an.

Heute genutzte PLM und ERP Konzepte sind für die Umsetzung der Anforderungen aus der interdisziplinären Produkt- und Produktionssystementwicklung in der frühen Phase des PEP nicht geeignet. Die bisher genutzten Datenmodelle sind zu starr ausgelegt und die Trennung in monolithische Systeme für Entwicklung (PLM), Logistik, Produktion und Personal (PPS, ERP), Kunden- und Zuliefererintegration (CRM, SCM) sind nicht mehr zeitgemäß. Sie ermöglichen nicht mehr, die Erfassung der komplexen Zusammenhänge der Produkte selbst, ihrer Wechselwirkung untereinander, sowie ihr Zusammenspiel insbesondere in der frühen Phase des Entwicklungsprozesses mit zunehmend intelligent auszulegenden Produktions- und Infrastruktur-Systemen umzusetzen.

In den verschiedenen Phasen des PEP existieren bereits heute eine Vielzahl von Anwendungssprachen und -systemen:

• Modellbildung und Spezifikation -> SysML (OMG Standard), ModelicaML
• Modellbildung und Simulation -> Simulink, Simscape, Matlab, Modelica
• Disziplinspezifische Modellbildung und Simulation -> Hier existieren eine Vielzahl von M-CAD, E-CAD, CASE (Computer Aided Software Engineering) und CAE Lösungen

Die IT-Lösungen der zweiten und insbesondere der dritten Phase sind weitgehend industriell implementiert und akzeptiert. Auf der ersten Ebene sind trotz Existenz internationaler Standards noch keine industriellen Anwendungen für interdisziplinäre Produkt- und Produktionssystementwicklung bekannt. Von wissenschaftlicher Seite existieren hier Vorschläge neben dem OMG Standard eigene Modellierungssprachen zu entwickeln. Die Schnittstellen zwischen den drei Ebenen sind nur teilweise existent und müssen für eine durchgängige Prozessgestaltung entwickelt, implementiert und ausgebaut werden.

Zusammenfassend ist die Ausgangslage gekennzeichnet durch fehlende integrative Methoden, Prozesse und IT-Lösungen – sowohl auf der Administrationsseite (PLM und ERP) als auch auf der Anwendungsseite – bzw. deren fehlende Integration in ein durchgängiges Modellierungskonzept von Anforderungen (A), Funktionen (F), logischer (L) und physischer (P) Beschreibung von interdisziplinären Produkten und Produktionssystemen. Der Ansatz des Systems Engineerings und insbesondere des Model Based Designs könnte ein zukünftiger Leitfaden für Methoden, Prozesse und IT-Lösungen zur Entwicklung interdisziplinärer Produkte und Produktionssystemen sein.

3 Stand der Forschung

In diesem Abschnitt werden die damit verbunden Arbeiten auf dem Gebiet der kon-zeptionellen Produktmodellierung andiskutiert. Dies beinhaltet die funktionalen Mo-dellierungs- und Beschreibungssprachen von mechatronischen Systemen sowie darüber hinausgehend auch die PLM-Integration dieser Beschreibung.

3.1 Funktionale Modellierung

Die funktionale Modellierung stellt eine abstrakte Methode für das Verständnis und für den Gesamtwert eines Produktes dar. Die primäre Aufgabe ist die Unterstützung der Suche nach geeigneten Lösungen im Design, sowie die Schaffung  eines disziplinunabhängigen Modells eines Produktes.

Ein funktionales Modell enthält eine abstrakte Beschreibung der wichtigsten Ziele eines Produktes durch Angabe seiner Funktionen (Substantiv-Verb-Kombination) [4]. Die gesamte Funktion wird in ihre Teilfunktionen unterteilt, von denen jede wiederum in weitere Teilfunktionen unterteilt werden kann. Dies führt zu einer funktionalen Hierarchie. Eine typische Darstellung eines funktionalen Modells ist ein Diagramm, mit dem Funktionen als separate Blöcke und Verbindungen, wie Stoff-, Energie- oder Signalaustausch dargestellt werden können.

Bisher wurden funktionale Modelle nicht im Sinne eines modellbasierten Ansatzes betrachtet, sondern mehr als Dokumente verstanden. Darüber hinaus sind funktionale Modelle selten formal und damit durch den Computer interpretierbar.

Ein Schritt in Richtung des modellbasierten Entwurfes ist der Ansatz von Stone [5]. Es geht um die Definition eines formalisierten Verfahrens auf Basis von Taxonomien und Regeln für die Beschreibung von Funktionen, die das Produktdesign beschreiben.

3.2 Modellierungssprachen für die konzeptionelle Produktmodellierung

Gausemeier et.al. schlagen die Spezifikationstechnik CONSENS (CONceptual design Specification technique for the ENgineering of complex Systems) für die Beschreibung von selbstoptimierenden mechatronischen Systemen vor. Mit Hilfe verschiedener Ansichten kann das System beschrieben werden. Jede Ansicht wird durch ein partielles Modell z.B. in Form eines Diagrammes dargestellt. In einem Teilmodell können spezifische Zusammenhänge dargestellt werden. Die wichtigsten Teilmodelle beschreiben Umfeld, Zielsystem, Verhalten, Anwendungsszenarien, Anforderungen, Funktionen, Wirkstruktur und Gestalt. Das Konzeptmodell wird durch die Summe von kohärenten Teilmodellen gebildet [6], [7].

Eine andere von der OMG vorgeschlagene Sprache für die Beschreibung von Systemen ist SysML. SysML wird als Werkzeug zur unabhängigen grafischen Modellierung im Rahmen von Spezifikation, Analyse, Design, Verifikation und Validierung von Systemen verstanden.

Es gibt Bestrebungen, aufbauend auf SysML- und UML-Spezifikationsmodelle Simulationsmodelle zu integrieren. ModelicaML ist eine grafische Modellierungssprache, basierend auf einem UML-Profil, um Simulationsmodelle in Modelica mit einer SysML-ähnlichen Semantik zu beschreiben. ModelicaML ermöglicht die Erstellung von Beschreibungsmodellen nach den Methoden des modellbasierten Systems Engineerings, die zudem in Modelica ausführbar sind [8]. Paredis et.al. schlagen darüber hinaus eine Spezifikation für die Modelltransformation von SysML-Modellen in Modelica Modelle vor, um so die analytischen Vorteile von Modelica mit der Beschreibungsfreiheit von SysML zu kombinieren [9].

3.3 PLM Integrationsaktivitäten

Um den interdisziplinären Produktentwicklungsprozess durchgängig unterstützen zu können, ist eine Integration des Systemmodells in PLM sinnvoll. Zur Integration in eine PLM Lösung werden hauptsächlich gängige Standards betrachtet.

Die XML Metadata Interchange Spezifikation (XMI) – standardisiert durch die OMG – unterstützt den Austausch von Modelldaten zwischen den Werkzeugen für Meta Object Facility (MOF)-basierte Modellierungssprachen, definiert jedoch kein Datenschema.

Ein weiterer Austauschstandard für den Austausch von Systems Engineering ist STEP AP233. In der SEDRES Projektgruppe wurde STEP AP233 für die Integration von Systems Engineering-Daten in PDM-Systemen formuliert. AP233 unterstützt die Systemmodellierung, welche die Systemstruktur und das Verhalten integriert [10].

In der OMG untersucht weiterhin eine Arbeitsgruppe die Zusammenhänge zwischen SysML und AP233. Ziel ist ein Mapping der gemeinsamen Datenkonstrukte, sowie ein Change Management für SysML.

4 Erweiterter, modellbasierter Ansatz in der Virtuellen Produktentwicklung

Die modellbasierte Entwicklung ist in der virtuellen Produktentwicklung von zentraler Bedeutung. Modelle können zum Beispiel topologische, physische, prozessorientierte, geometrische oder mathematische Modelle sein.

Im modellbasierten Systems Engineering (MBSE) werden Modelle für die Beschreibung und Spezifikation verwendet, um eine Strukturierung von komplexen technischen Problemen zu erleichtern. Dabei werden die Beziehungen zwischen Eigenschaften für die Analyse auf einer höheren strukturellen Ebene erfasst. Akteure aus verschiedenen Disziplinen sind an der Konzeption und Entwicklung eines komplexen Systems beteiligt. Jeder Stakeholder hat einen anderen Blick auf die Spezifikation [2]. Die Methoden des modellbasierten Systems Engineerings können dazu beitragen, ein multidisziplinäres Produkt in einer abstrakten Weise zu beschreiben. Die VDI 2206 definiert einen systematischen Ansatz für die Entwicklung mechatronischer Systeme. Der Fokus in diesem Artikel liegt hier auf dem linken Flügel des „V“ und erweitert es mit dem Einsatz von Methoden aus dem modellbasierten Systems Engineering (siehe Abbildung 2).

Es können drei Ansichten der Modellierung identifiziert werden:

• Modellbildung und Spezifikation
  Ein System wird durch qualitative Modelle beschrieben. Diese beinhalten Anforderungs-, Funktions- oder Systemstrukturen. Die Modelle sind beschreibend und können nicht simuliert werden. Als Autorenwerkzeuge dienen z.B. Editoren für Beschreibungssprachen wie SysML.
• Modellbildung und erste Simulation
  Auf dieser Ebene werden meist quantitative, simulierbare Modelle erstellt, z.B. multi-physikalische Simulationsmodelle, die mehrere Disziplinen mit einbeziehen. Als Autorenwerkzeuge dienen z.B. Simulationseditoren wie Dymola oder Matlab/Simulink.
• Disziplinspezifische Modellbildung
  Auf dieser Ebene werden z.B. Geometrie- oder CAE-Modelle erstellt, die einen sehr disziplinspezifischen Charakter haben. Als Autorenwerkzeuge dienen z.B. CAD Systeme oder disziplinspezifische Berechnungs- und Simulationssoftware.

Die Anforderungsdefinition ist der Ausgangspunkt der Entwicklung. Sie spiegelt die mehr oder weniger abstrakte Idee in Form von Kundenbedürfnissen oder Anforderungen der Anwender wieder. In der folgenden Anforderungsanalyse werden die Kundenanforderungen in logisch konsistente, technische Anforderungen übersetzt. Dies ist mit A in Abbildung 2 markiert.

In der frühen Phase der Produktentwicklung ist der interdisziplinäre Systementwurf für die Erstellung einer funktionalen Lösung, die alle Disziplinen vertreten kann, unerlässlich. Dies wird auch oft als Requirements Engineering bezeichnet. Beginnend mit einer groben Funktions- und Verhaltensbeschreibung, kann dieses Konzept Schritt für Schritt verfeinert werden. Die Aufgliederung und Abbildung in Funktionen und Teilfunktionen wird mit F in Abbildung 2 markiert. Diese bietet eine zunächst disziplin- und lösungsneutrale Sichtweise auf das Gesamtsystem in Form einer ersten Spezifikation.

Das Lösungskonzept wird durch die Definition von logischen Komponenten (gekennzeichnet mit L in Abbildung 2) beschrieben, die funktionale Elemente und Verhalten  realisieren. Das Lösungskonzept umfasst das logische und physikalische Verhalten sowie die Struktur des Systems.

Semi-formale Modellierungssprachen, wie UML oder SysML, sowie simulationsba-sierte Modellierungssprachen wie Matlab/Simulink/Simscape oder Modelica unter-stützen die interdisziplinäre Systementwicklung, so dass am Ende der interdisziplinären Systementwicklung Produkteigenschaften durch virtuelle Tests gezielt überprüft werden können. Bisher gibt es keinen durchgängigen Daten- bzw. Informationsaustausch zwischen der modellbasierten Spezifikation über die ersten Simulationen zu den entsprechenden Disziplinen. Gerade eine inkrementelle und integrierte Überprüfung von Eigenschaften mit virtuellen Tests setzt die Entwicklung von Anforderungen und definierten Testszenarien voraus.

Basierend auf den ersten Simulationen und der funktionalen Beschreibung beginnt die disziplinspezifische Entwicklung, die die physischen Elemente des Systems, wie Hardware-Teile oder Software-Code (gekennzeichnet mit P in Abbildung 2), adressiert. Hier setzen meist die CAx Prozesse in der virtuellen Produktentwicklung an.

5 Datenmanagement für die konzeptionelle Produktmodellierung

Eine vollständige Definition der Anforderungen, Funktionen und logischen System-elemente ist schwer schon zu Beginn zu erreichen. Daher sollte der Entwicklungsprozess nach dem oben vorgestellten V-Modell in inkrementellen Schleifen verlaufen, die alle Aspekte weiter verfeinern. Die Iterationen beginnen mit dem kleinsten „V“, bis es über die virtuellen Test-Iterationen mit detaillierten Simulationsmodellen, zur physikalischen Prüfung kommt. Jede Iteration bedeutet eine Zunahme des Wissens über das Produkt. Gleichzeitig bedeutet dies, dass Änderungen vorgenommen werden können, die entsprechend verwaltet werden müssen. Hierfür bietet sich das PDM System als Kern einer PLM Lösung an, wo zentrale Produktinformationen aus dem Entwicklungsprozess von allen beteiligten Personen zusammengetragen und organisiert werden.

Modelle in der Sicht der Modellierung und Spezifikation (Abbildung 2, oben links) werden in den frühen Phasen der Produktentwicklung mit dem Zweck erstellt, die Beschreibung des Produktes zu verwalten und alle kritischen Aspekte unter Einbeziehung aller Beteiligten zu überprüfen.

Basierend auf dem System-Spezifikationsmodell können verschiedene Aspekte des Produktes „eingefroren“ und „freigegeben“ werden, so dass in der disziplinspezifischen Entwicklung darauf Bezug genommen werden kann. Dies können z.B. Parameter von Komponenten für bestimmte disziplinspezifische Planungen und Simulationen sein, die wiederum auch für andere disziplinspezifische Modelle verwendet werden.

Die Verwaltung von funktionalen Beschreibungsmodellen in PDM kann  während der frühen Planungsphasen sowie später entlang des Produktlebenszyklus das Medium für die Rückverfolgung von Änderungen an Anforderungen, Funktionen und Verhalten, logischen sowie physikalischen Elementen sein. Ein Beispiel hierfür ist die Möglichkeit, durch die funktionale Beschreibung eine Zuordnung zu schaffen, welche Anforderungen eine Änderung in der Produktstruktur beeinträchtigen und umgekehrt.

5.1 Computerunterstützung für die funktionale Produktbeschreibung

Die funktionale Produktbeschreibung bezieht sich auf die Sicht der Modellierung und Spezifikation (Abbildung 2, oben links) und beschreibt das System aus einer funktionsorientierten Perspektive. Dazu gehören die Anforderungen, die funktionalen und logischen Elemente des Systems. SysML eignet sich für die Modellierung dieser Aspekte. SysML ist eine standardisierte Modellierungssprache und es existieren viele Werkzeuge für die Modellierung. XMI stellt hier eine Basis für den Datenaustausch dar, wird jedoch von vielen Werkzeugen nicht vollständig unterstützt. Zusätzlich zu den SysML-Modellierungs-Tools wie Magicdraw oder Enterprise Architect, bieten Anforderungsmanagement-Tools wie Doors, RequisitePro oder Integrity starke Unterstützung für die Modellierung von Anforderungen.

Abbildung 3 zeigt ein exemplarisches Beispielmodell eines Scheibenwischers in SysML. Die Anforderungen sind in einem hierarchischen Anforderungsdiagramm modelliert. Funktionen und logische Elemente des Systems sind hierarchisch in einem Blockdefinitionsdiagramm modelliert. Die interne Struktur wird durch interne Blockdiagramme abgebildet, die die funktionale und logische Architektur repräsentieren.

Zwischen zwei verschiedenen Modellelementen kann eine Zuordnungsbeziehung aufgebaut werden. Die so genannten Querverweise können auf verschiedene Arten eingeschränkt werden. In SysML existieren vordefinierte Zuweisungen. Darüber hinaus können aber auch neue Zuweisungen definiert werden. In dem angeführten Beispiel ist eine Zuweisung zwischen logischen und funktionalen Elementen des Systems definiert, die „realisiert“ heißt. Der Regensensor realisiert die Funktion „erkenne Regen“. Ein Merkmal (Property) eines Systemelements „erfüllt“ eine Anforderung. In unserem Vorschlag wird diese Zuordnung erweitert, so dass auch eine Funktion eine Anforderung erfüllen kann. Sind diese Querverweise definiert, können Anforderungen mit der funktionalen und logischen Architektur in Zusammenhang gebracht werden.

Soll der Scheibenwischer in Abbildung 3 in einem anderen Produkt verwendet werden (z.B. für PKW entwickelt und jetzt in LKW zu integrieren), kann es sein, dass die Bordspannung 24V beträgt und sich somit die Anforderung verändert. Um diese veränderte Anforderung umzusetzen, ist es wichtig, alle betroffenen logischen oder funktionalen Elemente des Systems zu kennen.

5.2 Inhalt eines funktionalen Produktbeschreibungsmodells

SysML-Editoren können helfen, ein erstes Konzept eines Systems mit Hilfe von unterschiedlichen Diagrammen grafisch zu modellieren. Zur Integration der modellierten Daten in ein PDM System wird im Folgenden ein Datenschema zur Abbildung auf z.B. XML vorgeschlagen, das unterschiedliche Perspektiven beinhaltet:

• Hierarchien
  Anforderungs-, Funktions- und logische Elementstrukturen können in einer hierarchischen Weise betrachtet werden. In PDM-Systemen können diese in einfacher Form als Struktur (ähnlich einer Stückliste) gespeichert werden.
• Querverweise unter Modellelementen verschiedener Typen
  Querverweise sind die Beziehungen zwischen verschiedenen Arten von Modell-Elementen, die mit Zuweisungen in SysML modelliert werden können. Der Vorteil des modellbasierten Systems Engineerings ist, dass diese Querverweise zusammen mit dem Systemelement verwaltet werden.
• Typisierte Verbindungen unter Modellelementen von demselben Typ
  Verbindungsdiagramme z.B. in Modelica oder interne Blockdiagramme in SysML beschreiben die interne Struktur eines Systems oder Systemelements über Verbindungen zwischen seinen Elementen, basierend auf Ports gleichen Typs.

Hierarchien werden in erster Linie für das Management komplexer Systeme verwendet. Werden funktionale oder logische Zusammenhänge betrachtet ist, dies für eine funktionale Produktbeschreibung meist nicht ausreichend.

5.3 Datenmodell für das Produktdatenmanagement

Abbildung 4 zeigt die mögliche Integration einer funktionalen Produktbeschreibung in eine PLM Umgebung. Oben auf der Abbildung ist die PDM/PLM-Lösung zur Verwaltung anfallender Produktdaten. Für diesen Beitrag wird davon ausgegangen, dass das PDM System die Verwaltung von Anforderungen und Stücklistenstrukturen bereits unterstützen kann. Unten auf der Abbildung sind entsprechend der Phasen des Entwicklungsprozesses Autorenwerkzeuge herangeführt (z.B. „Doors“ als Anforderungsmanagement Tool in der Phase „Planung“).

Die funktionale Produktbeschreibung integriert sich zwischen Anforderungen und Stücklistenstruktur (BOM). Funktionen lassen sich auf einfache Art und Weise hierarchisch modellieren (siehe Abschnitt 3.1). Dies kann in SysML-Editoren über Blockdefinitionen modelliert und in XML extrahiert werden.

Logische Systemelemente stellen die Realisierung von Funktionen mit einem physikalischen Effekt dar und definieren Eigenschaften. Ein Systemelement kann weitere externe Modelle als Dateien referenzieren. Dies könnte zum Beispiel eine Modelica oder Matlab/Simulink/Simscape Modelldatei sein, die entwickelt wurde, um die physikalischen Eigenschaften darzustellen und zu analysieren. Logische Systemelemente sind mit der physikalischen Stückliste (BOM) verbunden, welche M-CAD oder E-CAD Dateien sowie Software aufnimmt.

6 Zusammenfassung und Ausblick

In diesem Beitrag wurde eine Erweiterung des V-Modells nach VDI 2206 vorgeschlagen, welches auf die Herausforderungen der virtuellen, modellbasierten Produktentwicklung näher eingeht. Des Weiteren wurde ein Datenmodell für die funktionale Produktbeschreibung vorgestellt, welches einen leichteren Zugang zu den Methoden des modellbasierten Systems Engineerings für Organisationen ermöglichen soll, um eine interdisziplinäre Produktentwicklung zu unterstützen. Der Anwendungsbereich ist auf hierarchische und interne Strukturen sowie Querverweise zwischen Modell-Elementen fokussiert. Eine Integration der funktionalen Produktbeschreibung in ein PLM Konzept beinhaltet die Verfolgung von Änderungen und Einflüssen auf Anforderungen, Funktionen und logische Systemelemente. Erst ein Management der funktionalen Systembeschreibung ermöglicht die frühe Produktdokumentation und Qualitätssicherung.

Das vorgeschlagene Vorgehen im erweiterten V-Modell ist angelehnt an das modellbasierte Systems Engineering, was ein grundsätzliches Umdenken in der Produktentwicklung erfordert. Das vorgeschlagene Datenmodell implementiert drei Perspektiven: Hierarchien, Querverweise zwischen Modellelementen und typisierte Verbindungen innerhalb der Modellelemente. Diese Perspektiven sollten das Management der funktionalen und logischen Architekturen in einer PLM-Lösung ermöglichen.

Literaturverzeichnis

[1] Anderl, R; Eigner, M; Sendler, U; Stark, R (2012): Smart Engineering – Interdisziplinäre Produktentstehung, in: acatech DISKUSSION, Heidelberg: Springer.

[2] Friedenthal, S; Steiner, R; Moore, A (2009): A Practical Guide to SysML – The Systems Modeling Language, San Francisco: Morgan Kaufmann Pub.

[3] Broy, M; Glotzbach, U (2010): Cyber-Physical Systems – Innovation durch softwareintensive eingebettete Systeme. In: acatech DISKUTIERT, Heidelberg: Springer.

[4] Pahl, G; Beitz, W; Feldhusen, J; Grote, K-H (2007): Konstruktionslehre – Grundlagen erfolgreicher Produktentwicklung – Methoden und Anwendung, 7.Aufl., Heidelberg: Springer.

[5] Hirtz, J; Stone, R; McAdams, D; Szykman, S; Wood, K (2002): A functional basis for engineering design: Reconciling and evolving previour efforts, in: Research in Engineering Design, (13), Heidelberg: Springer, 65-82.

[6] Gausemeier, J; Frank, U; Donoth, J; Kahl, S (2009): Specification technique for the description of self-optimizing mechatronic systems, in: Research in Engineering Design, 20 (4), Heidelberg: Springer, 201-223.

[7] Gausemeier, J.; Dumitrescu, R.; Tschirner, C.; Stille, K.S.: Modellbasierte Konzipierung eines hybriden Energiespeichersystems für ein autonomes Schienenfahrzeug. Tag des Systems Engineerings 2011 (TdSE) , Nov. 2011.

[8] Schamai, W; Fitzson, P; Paredis, C; Pop, A (2009): Towards Unified System Modeling and Simulation with ModelicaML: Modeling of Executable Behavior Using Graphical Notations, in: Proceedings 7th Modelica Conference, Como/Italy, 20. – 22.09.2009, 612-621.

[9] Paredis, C; Bernard, Y; de Koning, H-P; Friedenthal, S; Fritzson, P; Rouquette, N; Schamai, W (2010): An Overview of the SysML-Modelica Transformation Specification, Beitrag im Internet: http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-modelica:sysml_and_modelica_integration veröffentlicht 2010, abgerufen am 02.02.2012.

[10] Eckert, R; Mansel, W; Specht, G (2005): STEP AP233 + Standard PDM = Systems Engineering PDM?, in: Proceedings of 11th international Conference on Concurrent Engineering, München, 20.-22.06.2005, 405-412.

Kontakt
Prof. Dr.-Ing. Martin Eigner
Dipl.-Ing. Torsten Gilz
Dipl.-Ing Radoslav Zafirov
Technische Universität Kaiserslautern
Lehrstuhl für Virtuelle Produktentwicklung
Gottlieb-Daimler-Straße 44
67663 Kaiserslautern
https://www.uni-kl.de 

5 Systems Lifecycle Management SysLM

Die beschriebene Komplexität der Produkte und Prozesse betrifft die gesamte Fertigungs- und Prozessindustrie, auch unabhängig von der Größe der Unternehmen. Zwar beschäftigen sich einzelne Branchen und Unternehmen in unterschiedlicher Intensität und mit verschiedenen Schwerpunkten mit der Suche nach Lösungen. Aber diese Suche ist bislang nicht erfolgversprechend, weil die zugrundeliegenden Denkansätze

• zu stark an bekannte Verfahrensweisen, Modelle und Organisationsstrukturen gebunden sind
• sich auf rasch zu erzielende Ergebnisse konzentrieren und deshalb immer nur einen kleinen Teilaspekt adressieren

Der Grund liegt darin, dass die Probleme sich in erster Linie auf der operativen Ebene zeigen. Deshalb versuchen bisher hauptsächlich die jeweils für ihren Bereich Verantwortlichen – Entwicklung, Fachbereiche, Produktion, Organisationsentwicklung, Vertrieb etc. – sie je nach Dringlichkeit zu lösen.

Da das Hauptproblem aber auf der unzureichenden Kommunikation, Zusammenarbeit und Synchronisation aller Beteiligten beruht, ist zunächst erforderlich, dass die oberste Ebene der Unternehmensführung diese Frage zu ihrer Aufgabe macht. Erst in nachfolgenden Schritten kann dann entschieden werden, welche Maßnahmen in welcher Reihenfolge einzuleiten sind. (Bild 6)

Der Problematik wird derzeit weder in den Führungsebenen der Industrie noch in der Gesellschaft hohe Priorität eingeräumt. Das liegt möglicherweise auch daran, dass die Industrie am Standort Zentraleuropa in den letzten Jahren gerade mit intelligenten Produkten ausgesprochen erfolgreich auf dem Weltmarkt auftreten konnte. Dieser Erfolg ist aber in hohem Maße gefährdet, wenn die fehlende Integration der Fachbereiche und ihrer Prozesse nicht grundsätzlich angegangen wird. Der momentane Erfolg stützt sich ausschließlich auf die hohe Spezialisierung und die weltweit führende Kompetenz der Ingenieure, Techniker und Wissenschaftler in Zentraleuropa.

Schon mittelfristig benötigt die Industrie neue Methoden, Modelle, Organisationsstrukturen und Prozesse sowie Werkzeuge.

Methoden

Die herkömmlichen Methoden der Entwicklung und Produktion beruhen in erster Linie auf der hohen Spezialisierung der einzelnen Fachbereiche. Für intelligente Produkte muss diese Spezialisierung ergänzt werden durch Methoden, die den Beteiligten ermöglichen, sich stärker als bisher auf die jeweils anderen Spezialisten zu beziehen, sich besser mit ihnen abzustimmen, in höherem Maß die Zusammenhänge zwischen den eigenen Arbeitsschritten und denen der nachfolgenden, parallelen oder vorgelagerten zu berücksichtigen.

Modelle

Modelle sind in vielen Bereichen der Industrie zu einem wichtigen Mittel geworden, die Prozesse sowohl zu beschleunigen als auch ihre Qualität und Sicherheit zu erhöhen. Aber die vielen Modelle, die dazu gegenwärtig genutzt werden, sind nur zum Zweck der Unterstützung der jeweiligen Prozesse und Arbeitsschritte gedacht. Sie sind nicht ausgelegt auf die multidisziplinäre Entwicklung und nicht auf die Unterstützung der Gesamtprozesse.

Hier fehlen der Industrie praxistaugliche Ansätze, um

• die vielen existierenden Modelle effektiv miteinander zu verknüpfen,
• in passender Granularität ein gemeinsames Datenmodell für Entwicklung und Produktion zu schaffen,
• Modelle zu definieren, die eine so realistische Funktionssimulation von Produkt und Fertigung gestatten, dass sie die Erzeugung von Hardwareprototypen weitgehend obsolet machen,
• Modelle zu erzeugen, die eine durchgängige Nutzung der Daten über den gesamten Lebenszyklus von Produkt und Produktionssystem erlauben.

Organisationsstrukturen und Prozesse

Die heutigen Organisationsstrukturen und Prozesse der meisten Industrien sind entstanden für Produkte, die auf der Spezialisierung bestimmter Fachdisziplinen beruhten. Sie basieren auf der Annahme, dass Produktentwicklung und Produktion weitgehend in sich geschlossene Prozesse sind. Beides trifft auf moderne Produkte nicht mehr zu.

Wenn die vorhandenen Strukturen nicht zu einem Hindernis der Weiterentwicklung werden sollen, müssen sie dem ganzheitlichen Ansatz einer multidisziplinären Entwicklung und Fertigung technischer Systeme untergeordnet werden. Die Grenzen zwischen den Fachbereichen müssen durchlässiger werden. Letztlich wird sich die erfolgreiche Schaffung solcher Strukturen auch in persönlichen Verantwortlichkeiten für Systems Lifecycle Management ausdrücken.

Werkzeuge

Die heute eingesetzten Werkzeuge sind ausgelegt auf die Unterstützung der gängigen Prozesse und Arbeitsweisen. Werkzeuge – insbesondere IT-Werkzeuge – für die Unterstützung der multidisziplinären Entwicklung und Fertigung existieren nur erst in Ansätzen.

Hinsichtlich der Werkzeuge ist die Problemstellung eine dreifache:

• Die vorhandenen Tools müssen besser miteinander kommunizieren.
• Es fehlen Werkzeuge für viele Aufgabenstellungen in allen Bereichen.
• Für alle Werkzeuge und ihre Verknüpfung oder Integration gilt: Ihre Bedienung muss um Faktoren vereinfacht werden.

Die beschriebenen Herausforderungen sind nicht kurzfristig zu lösen. Es braucht einen langen Atem und hohe Investitionen, insbesondere auf Seiten der produzierenden Industrie. Diese Investitionen werden sich aber bereits mittelfristig auszahlen durch eine wachsende Sicherheit, dass Produkte aus Zentraleuropa ihre führende Position auf dem Weltmarkt behaupten und möglicherweise sogar ausbauen können.

Voraussetzung für die Implementierung eines Systems Lifecycle Management (SysLM) ist ein generelles und grundsätzliches Umdenken. Nicht die einzelne Komponente eines Produktes, und nicht die einzelne Aufgabe eines Prozesses stehen im Vordergrund und sind primäres Ziel der Optimierung, sondern das Produkt als System unter Systemen und der durchgängige Prozess vom Konzept bis zum Recycling.

Zur Erreichung der zentralen Ziele des Systems Lifecycle Managements ist eine intensive Forschungsarbeit nötig, für die sich die Industrie mit der Wissenschaft noch enger zusammenschließen muss. Dabei können sich beide Seiten auf die in den letzten Jahren gewachsene Aufmerksamkeit stützen, die zum Beispiel auch auf der Ebene der deutschen Politik angekommen ist, etwa mit der Anfang 2012 gestarteten Kampagne „Industrie 4.0“.

Literaturverzeichnis

[SF11]    Eco tracing – a systems engineering method for efficient tracelink modelling, Stark, R., Figge, A., 2011, Konferenzbeitrag, veröffentlicht in Publica am IPK

[ANR12]    Das W-Modell – Systems Engineering in der Entwicklung aktiver Systeme, Anderl, R. Nattermann, R., Rollmann, Th., PLMportal: Positionen aus Wissenschaft und Forschung, Jahrgang 2012

[EGZ12]    Interdisziplinäre Produktentwicklung – Modellbasiertes Systems Engineering, Eigner, M., Gilz, T., Zafirov, R., PLMportal: Positionen aus Wissenschaft und Forschung, Jahrgang 2012

[BRR11]    Architekturen softwarebasierter Funktionen im Fahrzeug: von den Anforderungen zur Umsetzung, Broy, M., Reichart, G., Rothhardt, L., Informatik-Spektrum Vol. 34, Nr. 1, Springer Verlag 2011

[GLL12]    Produkte und Produktionssysteme integrativ konzipieren – Modellbildung und Analyse in der frühen Phase der Produktentstehung, Gausemeier, J., Lanza, G., Lindemann, U., Carl Hanser Verlag 2012

[KS97]    Das virtuelle Produkt, Management der CAD-Technik, Krause, F.-L., Spur, G., Carl Hanser, München Wien, 1997

[AES12]    Interdisziplinäre Produktentstehung, R. Anderl, M. Eigner, R. Stark, in Smart Engineering – Interdisziplinäre Produktentstehung, Schriftenreihe acatech Diskussion, April 2012, Hrsg.: R. Anderl, M. Eigner, R. Stark, U. Sendler, Springer-Vieweg