Ein pragmatischer Weg hin zu System Lifecycle Management (SysLM)
Technische Universität Kaiserslautern, Lehrstuhl für Virtuelle Produktentwicklung
November 2014
Die Komplexität von Product Lifecycle Management (PLM) Implementierungen hat bereits ein unangenehm hohes Level erreicht und der Anstieg der Komplexität von Produkten und deren Entwicklung wird sich vermutlich weiter beschleunigen. Indem System Lifecycle Management (SysLM) als nächste Stufe von PLM aufgebaut wird, erhöht sich diese Komplexität mit all ihren Vor- und Nachteilen sogar noch weiter. Während die Integration in eine einzelne, große PLM oder SysLM Lösung einen möglichen Ansatz darstellt, gibt es auch eine gegenteilige Vorgehensweise zu dieser All-in-one Alternative. Ein solches vollständig modularisiertes Konzept erlaubt eine Beibehaltung der aktuellen Unternehmens-IT und lässt deren Best-of-Breed Systeme unangetastet.
Falls Sie eine solche Best-of-Breed Version als mögliche Alternative in Betracht ziehen, könnte der folgende Ansatz einen pragmatischen Weg aufzeigen, wie SysLM in die Unternehmens-IT Landschaft eingeführt werden kann.
Was wird gemacht?
Abbildung 1 zeigt exemplarisch den Datenfluss für eine typische PLM Umgebung. Daten werden in einem Autorensystem wie z.B. einem Werkzeug für mechanischen, computerunterstützten Entwurf (M-CAD) erzeugt und in einem entsprechenden Team Datenmanagement (TDM) System verwaltet. Alle verwendeten Systeme bleiben unverändert, wenn die Konstruktionsstückliste (E-BOM) aus dem TDM in ein neutrales Format exportiert wird.
Mit “STEP AP242 edition 1 – Managed Model-based 3D Engineering” werden die zwei führenden STEP Anwendungsprotokolle (AP203 und AP214) zusammengeführt, um die Qualität des Datenaustauschs im Bereich der mechanischen Konstruktion weiter zu verbessern. Das Format wird zurzeit von der ISO standardisiert und enthält ein sogenanntes „business object model“, das nicht-geometrische Funktionalität zur Unterstützung der PDM Interoperabilität repräsentiert. Von diesem „business object model“ wird ein XML Schema abgeleitet, das den Austausch von Produktstrukturdaten basierend auf STEP AP242 XML ermöglicht. Siehe https://www.ap242.org für weitere Details.
Abbildung 1: Datenfluss der PDM Produktstruktur aus dem M-CAD zum PLM Backbone (STEP AP242 XML)
Warum wird’s gemacht?
System Lifecycle Management ermöglicht die Verwaltung von unternehmensweiten Prozessen an einem einzigen Ort, indem ein PLM Backbone als Verwaltungsort für alle prozessrelevanten Daten verwendet wird. Abbildung 2 zeigt, wie sich das Konzept in eine moderne und modellbasierte IT Architektur einfügt ohne die vorhandene Software- und Prozess-Infrastruktur zu stören.
Abbildung 2: Die Rolle von neutralen Datenschnittstellen (STEP AP242 XML, ReqIF etc.) für SysLM
Der PLM Backbone kann mit Hilfe von neutralen Datenschnittstellen in die Unternehmens-IT eingebunden werden, wodurch die vollständige Wahlfreiheit bei allen Software-Produkten erhalten bleibt. Flexibilität und Modularisierung wird für alle Unternehmens-IT Komponenten unterstützt und erlaubt je nach Bedarf die Verwendung von branchenführenden (Best-of-Breed) Lösungen.
Wie wird’s gemacht?
Um die Produktstruktur einer E-BOM auf einem standardisierten Weg auszutauschen, muss die Struktur aus dem entsprechenden TDM extrahiert und relevante Elemente auf das standardisierte Datenmodell abgebildet werden. Prototypen für PTC Windchill und Aras Innovator sind bereits jetzt sehr vielversprechend, sodass eine weite Verbreitung in Zukunft wahrscheinlich ist.
Der Prototyp für PTC Windchill (siehe Abbildung 3) extrahiert Produktstrukturen auf dem Windchill Server mit Hilfe eines Tasks in der internen Windchill Info*Engine. Der Task, bestehend aus einem Webject mit JSP Scriptlets, liegt auf dem Server und erzeugt eine Windchill konforme Produktstruktur für die entsprechend ausgewählte Baugruppe. Dieser Task kann von einer eigenständigen Java Anwendung, die auf dem Windchill Info*Engine SAK (Server Access Kit) basiert, aufgerufen werden um die Baugruppe abzurufen. Daraufhin bildet der Translator das Windchill Datenmodell auf das STEP AP242 XML Datenmodell ab und generiert eine XML Datei. Da der Translator selbst eine eigenständige Anwendung ist, kann er direkt auf dem Windchill Server oder auch von einem Client aus aufgerufen werden (siehe Abbildung 3).
Abbildung 3: Produktstruktur Translator von PTC Windchill zu STEP AP242 XML
Für Aras Innovator gibt es einen vergleichbaren Prototyp zum Export eines STEP AP242 XML (siehe Abbildung 4). Aras Innovator erlaubt den Zugriff auf den Server über die Adaptive Markup Language (AML), welche sowohl lokal auf dem Server als auch über eine Verbindung von außen verwendet werden kann. Der Translator ist eine eigenständige C# Applikation, die die Innovator Object Model (IOM) API in .NET verwendet um mit dem Server zu kommunizieren. Im Gegensatz zu PTC Windchill benutzt Aras Innovator keine Artefakte (wie z.B. Tasks), die zuvor auf dem Server abgelegt werden. Die gesamte Funktionalität ist in AML integriert und kann direkt über die IOM API aufgerufen werden. So wie auch bei PTC Windchill muss das exportierte Datenmodell auf das STEP AP242 XML Datenmodell abgebildet werden, bevor die XML Datei erzeugt werden kann.
Abbildung 4: Produktstruktur Translator von Aras Innovator zu STEP AP242 XML
Für die eigentliche Zuordnung der Elemente zwischen den verschiedenen Datenmodellen werden von einer unabhängigen Gruppe zurzeit Empfehlungen erarbeitet, die die Kompatibilität der erzeugten XML Dateien untereinander sicherstellen sollen. In einem nächsten Schritt könnte ein STEP AP242 XML Export auch direkt vom jeweiligen Anbieter in relevante Produkte integriert werden, was üblicherweise bei ISO Standards gängige Praxis ist.
Kontakt
Prof. Dr.-Ing. Martin Eigner
Dipl.-Wirtsch.-Inf. Sebastian Sindermann
Technische Universität Kaiserslautern
Lehrstuhl für Virtuelle Produktentwicklung
Gottlieb-Daimler-Straße 44
67663 Kaiserslautern
https://www.uni-kl.de