Die Beherrschung und Optimierung des Produktlebenszyklus setzt eine Integration über die Dimensionen Domäne/Anwendungsbereich, Geschäftseinheit und Produktlinie entlang des Produktentwicklungsprozesses voraus und stellt einen wesentlichen Wettbewerbsvorteil dar. Viele IT-Projekte, die sich eine PLM-Implementierung zum Ziel setzen, werden jedoch noch so angegangen, als würden klassische IT-Produkte wie z.B. CAx, PDM- oder aber ERP-Systeme eingeführt. Die für ein PLM notwendige Gestaltung einer PLM-Architektur wird in der Regel lediglich auf Systembebauungsebene durchgeführt. Eine der zentralen Herausforderung bei der Entwicklung einer PLM-Architektur ist jedoch die Konzeption der in der PLM-Architektur zusammenwirkenden integrierten Produktmodelle. Um diese entwickeln zu können ist eine Begriffssystematik notwendig die im Rahmen der DoPLMCon Methode von Prof. Fischer entwickelt wurde. Der nachfolgende Artikel erläutert diese methodische Begriffssystematik und erklärt wie sie zur Umsetzung in einer PLM Architektur verwendet werden kann.
Originalquelle:
FISCHER, Jörg W.; Brinkmeier, Bernd:
Do(PLM)Con – Vorschlag einer Systematik zur Entwicklung von PLM-Architekturen.
In: ProduktDatenJournal,
Darmstadt, 19(2012)1, S.24-28.
(ISSN: 1436-0403)
Aktueller Diskussionstand beim Aufbau von PLM Architekturen
Die Notwendigkeit der Beherrschung des Produktlebenszyklus und die Wettbewerbsvorteile, die daraus erwachsen, sind von vielen Unternehmen erkannt. Demzufolge wird in der Industrie daran gearbeitet zukünftige integrierte PLM-Architekturen zu entwickeln und umzusetzen (siehe hierzu Sendler, Wawer 2011, S. 41 ff., Fischer u.a. 2011). Dabei ist es eine wesentliche Aufgabe eine geeignete IT-Systembebauung, die diesen Ansatz realisieren kann zu definieren und diese unter Berücksichtigung der vorhandenen Systembebauung in einem evolutionären Prozess technisch umzusetzen.
Ein in diesem Zusammenhang diskutiertes Idealbild (siehe Bild 1) ist es, die beteiligten IT-Systeme lose über einen Servicebus zu koppeln. Die von diesem Ansatz verfolgte Idee ist es, von jedem der IT-Systeme standardisierte „Services“ anbieten zu lassen, die von den anderen beteiligten IT-Systemen genutzt werden können. Die in Bild 1 dargestellte Sicht ist funktionell getrieben. Sie geht davon aus, dass jedes System definierte Funktionen (die Services) zur Verfügung stellen kann die dann von einem anderen System genutzt werden können. Dieses Idealbild ist so jedoch nicht realistisch.
Im Produktentwicklungsprozess werden Produktmodelle aufgebaut. Diese werden i.d.R. in Form von Produktstrukturen in IT-Datenmanagementsystemen abgebildet. Die in der Produktentwicklung verwendeten IT-Funktionen traversieren das jeweilige Produktmodell und extrahieren die zu bearbeitenden Daten. Dazu setzen sie eine spezifische Semantik, die die Produktmodelle erfüllen müssen, voraus. Wird diese von den Funktionen geforderte Semantik im Modell nicht erfüllt, steht die jeweilige Funktion nicht oder nur eingeschränkt zu Verfügung (siehe hierzu Fischer u.a 2011, S. 18 ff.). Diese Problematik kommt beim Aufbau integrierte PLM-Architekturen besonders zum Tragen, da die Integration die Semantik der integrierten Modelle beeinflusst.
In Bild 2 ist beispielhaft ein typisches industrielles Integrationsszenario dargestellt. Ziel beim Aufbau dieses Szenarios ist die Bereitstellung eines lagerichtigen, digitalen Produktprototyps, der sich auf Basis vom Kunden wählbarer Optionen konfigurieren lässt. Der Anwendungsfall wird innerhalb des PDM-Systems realisiert. Die Anwendungsfunktionen wie z.B. das Visualisieren des virtuellen Prototypen findet im PDM-Client statt.
Zur Realisierung werden Modellextrakte aus dem Konfigurationssystem in das Produktmodell des PDM-Systems eingebracht (Bild 2, Detail A). Im konkreten Fall handelt es sich um die Positionen, die Positionsvarianten, die Teile, sowie die Verwendung inklusive der Variantenbedingung. Dabei findet eine datentechnische Transformation zwischen dem Datenmodell des Quellsystems und dem Datenmodell des Zielsystems statt. Um das Modell zu vervollständigen müssen die eingebrachten Modellextrakte semantisch integriert werden. Die semantische Integration geschieht im Beispielfall durch manuelle Zuordnung der CAD-Dokumente zu den jeweiligen Verwendungen und ergänzen bisher nicht explizit dokumentierte geometrische Varianz. Die so ergänzten Informationsinhalte besitzen einen eigenen Lebenszyklus und müssen persistent vorgehalten werden. Dieses Vorgehen schafft die informationstechnische Basis für den neuen Anwendungsfall.
Der eigentliche Anwendungsfall wird vom Anwender mit Hilfe von IT-Applikationen durchgeführt. Die Applikationen (im Beispielfall der PDM-Client, siehe Bild 2, Detail C) greifen auf die im Datenmanagementsystem abgebildeten Produktmodelle zu, extrahieren einen Umfang zur Bearbeitung und stellen die Daten für den Anwender bereit. Das funktioniert aber immer nur dann, wenn die semantische Konsistenz die der jeweilige PDM-Client von der Produktstruktur im PDM-System fordert, eingehalten wird. Der geschilderte Fall zeigt, dass bei der Konzeption integrierter PLM-Architekturen über die funktionale Sicht hinaus auch die Semantik der Modelle sorgfältig geplant und dabei deren semantische Konsistenz vor dem Hintergrund der gewünschten Funktionsrealisierung aufrecht erhalten werden muss.
In aktuellen Implementierungsprojekten wird zumeist keine systematische, modellsemantische Diskussion geführt. Die bisher i.d.R. eingenommene funktionale Sicht führt häufig zu dem Problem, dass im Verlauf des Projekts zwar integrierte Modelle entstehen, deren Modellsemantik und semantische Integrität aber mühsam durch „Trial and Error“ solange angepasst werden bis sie ihren Zweck erfüllen.
Der wesentliche Grund hierfür ist, dass es bisher an geeigneten Methoden fehlt integrierte Produktmodelle systematisch zu konzipieren. Um hier Abhilfe zu schaffen wurde von Siemens PLM im Rahmen eines industriellen Forschungsprojekts die Do(PLM)Con Methodik entwickelt (siehe Fischer u.a. 2011). Neben Methoden zum Konzipieren integrierter PLM-Architekturen stellt sie eine Begriffssystematik bereit, die es erlaubt, die zu untersuchende Thematik methodische abstrahiert zu diskutieren. Im Folgenden werden einige wesentliche Teile dieser Begriffssystematik vorgestellt.
Teilmodelle und Trägersysteme
DoPLMCon verfolgt einen modellbasierte Ansatz und trennt konsequent zwischen „abstrakten“ (Teil-)Produktmodellen (kurz: Teilmodell) und deren Realsierung in Trägersystemen (z.B. PDM-System, ERP-System etc.).
Die Begrifflichkeit des Teilmodells lehnt sich an das Modellverständnis der VDI 3633, S. 3 an. Demzufolge ist ein Modell eine Abbildung eines Systems mit seinen Verhalten in einem anderen begrifflichen oder gegenständlichen System. Dabei bildet es die relevanten Eigenschaften dem jeweiligen Verwendungszweck entsprechen hinreichend genau nach. Ein Teilmodell in einer PLM-Architektur ist demzufolge ein abgeschlossener Informationsumfang, der einen Teilaspekt des Produkts abbildet, auf methodischer Ebene zusammengefasst werden kann und dazu gedacht ist spezifische Anwendungsfälle des technischen Geschäftsprozesses abzudecken.
In der Produktentwicklung werden unterschiedliche (Teil-)Produktmodellen abgebildet die verschiedene Aspekte des realen Produkts widerspiegeln. Ein typisches Beispiel ist der virtuelle Prototyp (für Beispiele möglicher Teilmodelle siehe z.B. Eigner Stelzer 2009, S. 79).
In Bild 3 (Detail A) sind die einige wesentliche Aspekte zur Definition von Teilmodellen im Rahmen der Do(PLM)Con Methode zusammengeführt. Ein Teilmodell existiert aufgrund seiner Verwendungszwecke (Bild 3, Detail A, Business Intent). Um diese zu realisieren muss es spezifische Anwendungsfälle (Use Cases) der Produktentwicklung abdecken. Die im Teilmodell zur Realisierung der Use Cases enthaltenen Daten unterliegen semantischen Anforderungen (Semantic). Die Semantik untergliedert sich in die Bereiche abzulegende Informationseinheiten (Information Entity), Relationen zwischen den Informationseinheiten sowie der prinzipiellen Ordnungsstruktur im Modell. Ein Teilmodell ist auf einen bestimmten inhaltlichen Umfang von Produktdaten (Content) ausgerichtet. Ein Beispiel wäre ein Teilmodell für CAD Daten, dass für den Inhalt „Produktlinie“ konzipiert wird.
Über den Aspekt des Inhalts weist ein Teilmodell ein spezifisches Verhalten (Behavior) auf. Dieses wird in die Kategorien zeitliche Entwicklung (Progression), Zugriff (Access) und Extraktion (Extraction) untergliedert. Beispiele für zeitliche Entwicklung sind unterschiedliche Granularitäten und Entwicklungsstände von Komponenten oder zeitabhängige Gültigkeiten von Teileverwendungen (vgl. zur Strukturentwicklung Eigner, Stelzer 2009, S. 118 ff.). Der Anwender führt die Anwendungsfälle durch das Bearbeiten und Verändern von Daten des Modells durch (Authoring). Dazu muss das Teilmodell traversiert und ein dedizierter Umfang aus diesem extrahiert (Extraction) werden. Typische Extraktionsmethoden für Produktmodelle sind z.B. die Konfiguration nach Änderungsstand bzw. Revision, Variante oder zeitlicher Gültigkeit.
Durch die beschriebene Systematik wird es möglich Teilmodelle abzugrenzen und die Anforderungen, die diese erfüllen müssen ohne IT-Systembezug auf abstrakter Ebene zu definieren. Damit wird eine neutrale Basis geschaffen, auf der Anforderungen aufgenommen und diskutiert werden können. Teilmodelle können damit unbeeinflusst von zuvor realisierten IT-Lösungen schrittweise auf den eigentlichen Bedarf an Anforderungen ausdefiniert werden. Durch diese Reduktion lassen sich bei der Umsetzung Kosten sparen, da dann lediglich die Anforderungen umgesetzt werden, die zur Aufgabenerfüllung tatsächlich notwendig sind.
Ein Teilmodell wird technisch von einem Datenmanagementsystem (kurz Trägersystem / Carrier IT-System) getragen. Trägersysteme bieten hierfür ein semantisches Konzept sowie ein darauf aufbauendes Verhaltenskonzept (Bild 3, Detail B). Nach Abschluss der Definition des Teilmodells und Auswahl des jeweiligen Trägersystems muss in einem nächsten Schritt das bisher lediglich abstrakt definierte Teilmodell mit Hilfe den vom Trägersystem vorgegebenen Konzepten realisiert werden. Dabei wird das Teilmodell in einen vom Trägersystem vorgegebenen semantischen Rahmen sowie dem darauf basierenden Verhaltensrahmen einpasst. Die Anwendungsfälle (Use Cases) die das Teilmodell erfüllen soll, werden durch Funktionen in Applikationen erfüllt, die den vom Trägersystem aufgespannten semantischen Rahmen sowie dem darauf basierenden Verhaltensrahmen ausnutzen. Das Trägersystem hat demzufolge direkten Einfluss auf die Umsetzbarkeit der Anforderungen des Teilmodells. Zur besseren Abdeckung der Anforderungen lassen sich Trägersysteme zwar an gestellte Anforderungen anpassen, dabei ist jedoch zu bedenken, dass Anpassungen semantischen Inkonsistenzen nach sich ziehen können und dadurch ggf. einige zukünftig gewünschte Funktionalitäten nicht mehr nutzbar werden.
Die sorgfältige Planung und Durchführung des Abbildungsprozesses der Teilmodelle im Trägersystem ist damit ein wesentlicher erfolgskritischer Faktor eines PLM-Projekts der methodisch unterstützt werden muss. Die Do(PLM)Con Methode von Siemens stellt hierfür die notwendigen Hilfsmittel zur Verfügung (vgl. Fischer u.a. 2011, S. 20 ff.).
Integration von Teilmodellen
Um die integrativen Anwendungsfälle die von den verschiedenen Teilmodellen gefordert werden abdecken zu können müssen die Teilmodelle integriert werden. Bisher gibt es jedoch keine Systematik, die eine semantische Integration trägersystemunabhängig planbar macht. Die Do(PLM)Con stellt eine solche Systematik bereit. Diese unterscheidet zwei wesentliche Gestaltungsbereiche der Teilmodellintegration (vgl. Bild 4).
Bild 4: Gestaltungsbereiche der Teilmodellintegration
Der Gestaltungsbereich „organisatorische Abgleich“ zielt auf eine Harmonisierung der informationserzeugenden Prozesse über die beteiligten Domänen ab. Eine solche Harmonisierung wird durch organisatorische Maßgaben umgesetzt, die z.B. festgelegen könnten, dass eine Konstruktionslösung nicht ohne entsprechendes Stücklistenkorrelat existieren darf oder die Freigabe einer Konstruktion automatisch einen Stücklisteneintrag bedingt. Damit eine solche Umsetzung gelingt, ist auch ein inhaltlicher Bedeutungsabgleich der zukünftig gemeinsam verwendeten Informationseinheiten notwendig. Der Bedeutungsabgleich der Informationseinheiten schafft die notwendigen „Ankerpunkte“ an denen die modellsemantische Integration später ansetzen kann. Im Falle eines Integrationsszenarios von CAx und Stückliste wird typischerweise die Komponente, die Positionsvariante und die Position als gemeinsam verwendeten Informationseinheiten über die Teilmodelle genutzt.
Der Gestaltungsbereich „semantische Verbindungsarchitektur“ definiert die Ausgestaltung der Verbindung zwischen den Teilmodellen. Eine Verbindung kann entweder über ein sog. „Cross-Modell Link“ oder ein „In-Model Link“ realisiert werden (vgl. Bild 4, unten rechts). Ein „Cross-Model Link“ bezeichnet eine teilmodellübergreifende Verknüpfung der Objekte des Quells- mit dem Zielmodell wohingegen ein „In-Model Link“ lediglich Objekte innerhalb eines Teilmodells verlinkt. Bei Anwendung des In-Model Linking müssen demzufolge zuvor Modellextrakte des Quellmodells in das Zielemodell eingebracht und dort persistent vorgehalten werden. „In-Modell Linking“ ist damit offensichtlich mit dem Nachteil behaftet, dass es die Vorhaltung redundanten Daten in beiden Teilmodellen (Quell- und Zielmodell) notwendig macht. Trotz dieses Nachteils ist „In-Modell Linking“ der aktuell am häufigsten genutzten Integrationsansatz. Dies hat eine Reihe von Gründen von denen einige nachfolgend skizziert werden.
In der aktuellen PLM-Implementierung tritt häufig der Fall auf, dass Teilmodelle in unterschiedlichen Trägersystemen realisiert werden. Aus einem „Cross Model Link“ wird dann ein „Cross System Link“ was technisch anspruchsvoll und potenziell risikobehaftet ist. Die weiteren Gründe sind organisatorischer Natur. Unterschiedliche Teilmodelle weisen häufig eine unterschiedliche zeitliche Entwicklung (Progression) auf. Eine Cross-Model Link trägt damit das Risiko im Zeitverlauf seine inhaltliche Gültigkeit zu verlieren, was eine inhaltliche Inkonsistenz der integrierten Modelle nach sich zieht, die manuell behoben werden muss. Darüber hinaus tritt häufig z.B. durch Ansätze des Simultaneous Engineering auch der Fall auf, dass sowohl an Quell- als auch am Zielmodell gleichzeitig gearbeitet wird. Die Modellinhalte in Quell- und Zielmodell entwickeln sich in diesem Falle gewollt unabhängig voneinander weiter, redundante Daten die doppelt gepflegt werden müssen sind demzufolge für die Realisierung des Business-Intents notwendig.
Eine derartige Konzeption der Integration wird im Rahmen von PLM-Projekten aktuell nicht vorgenommen. Häufig werden ohne die genaueren organisatorischen und technischen Konsequenzen zu bedenken Entscheidungen getroffen die dann mühsam und kostenintensiv umgesetzt werden oder nachträglich berichtigt werden müssen. Eine systematische Planung der Gestaltungsbereiche der Integration ist vor der technischen Realisierung der Teilmodelle in Trägersystemen ein entscheidender Faktor der das Projektrisiko erheblich mindern kann. Darüber hinaus kann mit Hilfe des Teilmodellkonzepts eine prospektiven Analyse und Planung der Aufgabenveränderungen der Entwicklungsabteilungen durchgeführt werden, die typischerweise mit der Umsetzung integrativer PLM-Architekturen einhergehen.
Nutzung der DoPLMCon zur Entwicklung von PLM Architekturen
Die hier aufgezeigte Begriffssystematik der DoPLMCon Methodik hilft eine integrierende PLM-Architektur bestehend aus vernetzten Teilmodellen auf abstrakter Ebene beschreiben, diskutieren und entwickeln zu können. Die PLM-Architektur wird dabei vollständig trägersystemunabhängig konzipiert. Damit können einfache und flexible Entwürfe von PLM-Architekturen bestehend aus integrierter (Teil-)Produktmodelle abgeleitet werden, die eine harmonische, kundenorientierte Mischung aus funktionaler Erfüllung, Komplexitätsbeherrschung und Performance ermöglichen.
In einem zweiten Schritt werden dann Realisierungsalternativen dieser PLM-Architektur in Trägersystemen entworfen. Mit der Do(PLM)Con lassen sich diese Realisierungsalternativen dann technisch absichern und hinsichtlich von Kriterien wie Leistungsfähigkeit, Kosten, Anforderungserfüllung, Implementierungsaufwand und Risiken bewerten.
Literatur
Eigner, Martin; Stelzer, Martin: Product Lifecycle Management. Ein Leitfaden für Product Development und Life Cycle Management
Heidelberg London New York: Spinger, 2. Auflage 2009.
Fischer, Jörg W. u.a.: Implementierung domänenintegrierender PLM-Lösungen. Do(PLM)Con – ein Ansatz zur Konzeption und Realisierung domänenintegrierender PLM-Lösungen. In: Industrie Management, Berlin, 27(2011)5, S. 17-21. (ISSN 1434-1980)
Sendler, Ulrich; Wawer , Volker: Von PDM zu PLM. Prozessoptimierung durch Integration.
München: Carl Hanser Verlag, 2011.
