Unterstützung von Prozessen des Produktdatenmanagements mit dezentralen Konzepten: Stand der Forschung, Anwendungsszenarien, Marktchancen

Transkript

1 Diplomarbeit Unterstützung von Prozessen des Produktdatenmanagements mit dezentralen Konzepten: Stand der Forschung, Anwendungsszenarien, Marktchancen eingereicht bei der Abteilung für Wirtschaftsinformatik Institut für Informatik Fakultät für Mathematik / Informatik und Maschinenbau Technische Universität Clausthal zur Erlangung des Grades einer Diplom Wirtschaftsinformatikerin von Sonja Schäfer Römerstraße Düsseldorf Studienrichtung: Wirtschaftsinformatik Datum: 12. Februar 2007 Erstgutachter: Prof. Dr. Jörg P. Müller, TU Clausthal Zweitgutachter: Prof. Dr.-Ing. N. Müller, TU Clausthal Betreuer: Dipl. Wirt.-Inf. Patrick Stiefel, TU Clausthal

2

3 i Inhaltsverzeichnis Inhaltsverzeichnis... i Abbildungsverzeichnis.iv Tabellenverzeichnis..vi Verzeichnis der Screenshots.vii Abkürzungsverzeichnis ix 1 Einleitung Ziel der Arbeit Überblick über den Aufbau der Arbeit Begriffsdefinitionen Produktdaten Produktlebenszyklus Produktlebenszyklusmanagement Produktdatenmanagement Definition Produktdatenmanagement Übersicht über erweiterte PDM-Begriffe, Abgrenzung gegenüber verwandten Begriffen und Synonyme Kollaborative Produktentwicklung Kollaborative Produktentwicklung Annahmen und Probleme für die Interoperabilität im Unternehmen und über Unternehmensgrenzen hinweg Interoperabilität im Unternehmen Interoperabilität zwischen mehreren Unternehmen Anforderungen und Beurteilungskriterien Klassifizierung von Produktdatenmanagementsystemen Fallstudie Verwendete Architekturen und Funktionsanalyse Eigner PLM Agile Advantage

4 ii 5 Architektur und Austauschformate für die kollaborative Produktentwicklung Netzarchitekturen Client-Server-Architektur Peer-To-Peer-Architektur Austauschformate STEP PDTnet PDML PDX JT PDM Enabler Vergleich der Austauschformate bezüglich der Einsatzmöglichkeiten in kollaborativen PDM- Umgebungen Lösungen für die kollaborative Produktentwicklung mit Hilfe von Produktdatenmanagementsystemen Vorhandene Ansätze und Lösungen für die kollaborative Produktentwicklung PLM Services von OMG PDM-Collaborator Product Collaboration Platform Bewertung von Peer-To-Peer-basierten Lösungen für die kollaborative Produktentwicklung Kollaborative Produktentwicklung innerhalb eines Unternehmens Kollaborative Produktentwicklung zwischen verschiedenen Unternehmen Empfehlungen für die Product Collaboration Platform Zusammenfassung und Ausblick Quellenverzeichnis...121

5 iii Anhang A Screenshots Eigner PLM Anhang B Screenshots Agile Advantage Anhang C Erklärung Anlagen...146

6 iv Abbildungsverzeichnis Abbildung 1: Produktlebenszyklus... 7 Abbildung 2: Abhängigkeiten der PLM-Funktionsblöcke Abbildung 3: PLM und ERP Abbildung 4: Schnittstellen zu PDM Abbildung 5: Dokumentenverwaltung im PDM mittels Vault und Vault- Location Abbildung 6: PDM mit Client-Server-Architektur Abbildung 7: PLM als Bindeglied zwischen den Säulen Produktion und Produktentwicklung des Y-CIM-Modells Abbildung 8: Datenaustausch mittels Austauschformat Abbildung 9: Unterstützung von Concurrent Engineering durch PDM Abbildung 10: Baumstruktur des LEGO -Hauses Abbildung 11: Speichern eines Dokuments auf dem Fileserver des Eigner PLMs Abbildung 12: Komponenten von Agile Advantage Abbildung 13: Client-Server-Architektur von Agile Advantage Abbildung 14: Super-Peer-Netzwerk Abbildung 15: Das Client/Server-Modell enthält Anforderungen und Antworten Abbildung 16: Möglichkeiten zur Aufteilung der Aufgaben Darstellung, Anwendungslogik und Datenmanagement auf Client und Server Abbildung 17: P2P-Netz Abbildung 18: Prinzipieller Aufbau von STEP Abbildung 19: Typdeklarationen in EXPRESS Abbildung 20: Entity-Deklaration in EXPRESS Abbildung 21: Funktion in EXPRESS Abbildung 22: Globale Regel in EXPRESS Abbildung 23: Deklaration einer Entity in EXPRESS (1) und Erzeugen der entsprechenden Relation in SQL (2) Abbildung 24: Übersetzung von aggregierten Datentypen aus EXPRESS in relationale Datenbanken Abbildung 25: Umfang und Inhalt des STEP PDM-Schemas... 56

7 v Abbildung 26: Ausschnitt aus einem STEP-File, das ein Teilmodell des LEGO -Hauses beschreibt Abbildung 27: Szenario "Datenaustausch" im Projekt PDTnet Abbildung 28: Szenario Web-basierter Austausch von PDM-Daten im Projekt PDTnet Abbildung 29: Prinzip der Übersetzung aus EXPRESS in ein XML-Schema und Beispiel einer möglichen XML-Instanzierung Abbildung 30: Graphische Darstellung des PDTnet-Schemas in XML Abbildung 31: Ausschnitt einer XML-Datei nach dem PDTnet-Schema, die Teile der Produktdaten des LEGO -Hauses enthält Abbildung 32: Beziehungen zwischen PDML-Schemata Abbildung 33: Beispiel für die Übersetzung einer Deklaration eines Produkts innerhalb eines EXPRESS-Schemas (links) in eine Deklaration innerhalb einer XML-DTD (rechts) Abbildung 34: Elemente des PDML-Integrationsschemas Abbildung 35: Ausschnitt aus einer XML-Datei nach der Product-Structure- ATS-DTD, die Teile der Struktur des LEGO -Hauses enthält Abbildung 36: Aufbau eines PDX-Pakets Abbildung 37: Oberfläche des PDXplorer bei der Ansicht des PDX-Pakets des LEGO -Hauses Abbildung 38: Ausschnitt aus der Datei pdx.xml nach dem Export des Parts "LEGO -Haus" aus Agile Advantage Abbildung 39: Struktur einer JT-Datei Abbildung 40: Abhängigkeiten der PDM Enabler Module Abbildung 41: Detaillierter Aufbau von STEP und Übersicht über die Nutzung der Bausteine durch die Austauschformate Abbildung 42: Online Zusammenarbeit mittels PLM Services Abbildung 43: Architektur der PLM Services Abbildung 44: Szenarien des Verbundprojektes PDM-Collaborator Abbildung 45: Architektur des PDM-Collaborators Abbildung 46: Liefereinheiten und Entwicklungsleistungen Abbildung 47: Architektur der Product Collaboration Platform Abbildung 48: Aufbau einer Ressource in der PCP Abbildung 49: Collaboration Plattform als Rahmenvorgabe...107

8 vi Abbildung 50: Vorschlag für den Aufbau des XML-Schemas einer möglichen RMF-Ressource, orientiert am Aufbau von PDX-Paketen Abbildung 51: Vorschlag für den Aufbau der Additional_Attributes Tabellenverzeichnis Tabelle 1: Erfüllung der PDM-Funktionalitäten durch Eigner PLM Tabelle 2: Erfüllung der PDM-Funktionalitäten durch Agile Advantage Tabelle 3: Vorgegebene Klassenstruktur in Agile Advantage Tabelle 4: Abbildung von einfachen EXPRESS-Datentypen nach SQL2. 53 Tabelle 5: Vergleich der vorgestellten Austauschformate... 84

9 vii Verzeichnis der Screenshots Screenshot 1: Oberfläche von Eigner PLM Screenshot 2: Fenster zum Anlegen eines neuen Artikels in Eigner PLM Screenshot 3: Artikelliste des LEGO -Hauses in Eigner PLM Screenshot 4: Stückliste in der Browseransicht des Eigner PLM Screenshot 5: Strukturauflösung des LEGO -Hauses in Eigner PLM Screenshot 6: Anlegen eines "gespeicherten Dokuments" in Eigner PLM Screenshot 7: Das Dokument kann nun mittels Check-Out reserviert werden Screenshot 8: Das Projekt "Rohbau" ist ein Unterprojekt des Projekts "Hausbau" Screenshot 9: Festlegen der Attribute für ein variables Bauteil Screenshot 10: Die verschiedenen LEGO -Steine können für den Variantenplatzhalter eingesetzt werden Screenshot 11: Bildung von Klassen und Übersicht über eine mögliche Klassenhierarchie Screenshot 12: Die LEGO -Steine bekommen Klassifizierungsmerkmale Screenshot 13: Zwischenstand bei der Ableitung einer konkreten Stückliste für einen Kundenauftrag Screenshot 14: Neuer Workflow im Workfloweditor Screenshot 15: Agile Administrator Oberfläche Screenshot 16: Anlegen eines neuen Benutzers mit dem Agile Administrator Screenshot 17: Startbildschirm eines Agile Advantage 2006 Benutzers 136 Screenshot 18: Neues Teil "LEGO -Stein 2x2" anlegen Screenshot 19: Liste der letzen Objekte, die User 1 besucht hat (in diesem Fall die Einzelteile des LEGO -Hauses) Screenshot 20: Stückliste des LEGO -Hauses in Agile Advantage

10 viii Screenshot 21: Suche nach allen Teilen, die der Produktlinie "LEGO - Produkt" angehören Screenshot 22: Check-Out von einem Dokument "Bauplan", welches vorher dem LEGO -Haus zugeordnet wurde Screenshot 23: Neuer Change, welcher dem Dachziegel zugeordnet wurde Screenshot 24: Der User muss seine Zustimmung für den Statuswechsel des Change geben Screenshot 25: Workflow der Änderung wurde durchlaufen (Status: Implemented), neuer Status für das Teil "Dachziegel" (Pilot Released) Screenshot 26: Liste der von der Änderung betroffenen Objekte Screenshot 27: Stückliste des LEGO -Hauses, nachdem sie unter Verwendung von Redlining geändert wurde Screenshot 28: Suche nach den Objekten, die mit Agile express 2006 Professional exportiert werden sollen Screenshot 29: Filter-Dialog für den PDX-Export mit Agile express 2006 Professional Screenshot 30: Ansicht der exportierten Daten im PDX-Format mit dem Agile express 2006 Professional...144

11 ix Abkürzungsverzeichnis AML ANSI AP ASL ATS CAC CAD CAE CAM CAO CAP CAQ CASE CAx CC CE CIM CORBA cpdm CRM CSV DB DBM DBS DE DMU DSL DTD DTS EAI ECO Approved Manufacturer List American National Standardization Institute Anwendungsprotokoll Approved Supplier List Applications Transaction Set Computer Aided Calculation Computer Aided Design Computer Aided Engineering Computer Aided Manufacturing Computer Aided Office Computer Aided Planning Computer Aided Quality assurance Computer Aided Software Engineering Sammelbegriff für Software im Engineering Umfeld: CAD, CAE, CAM, CAO, CAP, CAQ, CASE und andere Conformance Class Concurrent Engineering Computer Integrated Manufacturing Common Object Request Broker Architecture Collaborative Product Definition Management Customer Relationship Management Comma Separated Values Datenbank Datenbankmanagement Datenbanksystem Data Exchange Digital Mock Up Digital Subscriber Line Document Type Definition Draft Technical Specification Engineering Animation Incorporated Engineering Change Order

12 x EDIFACT EDM EDMS EJB ENGDAT ENX ERP FEM GPM ID IDL IGES IMAN IPC IPK ISDN ISO ivip J2EE JT JXTA KMU LAN LCA Mgnt. NC NEMI ODETTE OEM OFTP OMG Electronic Data Interchange For Administration, Commerce and Transport Engineering Data Management Engineering Data Management System Enterprise Java Beans Engineering Data European Network exchange Enterprise Resource Planning Finite-Elemente-Methode Globales Produktdatenmanagement Identifikationsnummer Interface Definition Language Initial Graphics Exchange Specification Information Manager (von UGS) Institute for Printed Circuits Frauenhofer-Institut für Produktionsanlagen und Konstruktionstechnik Integrated Services Digital Network International Organization for Standardization Initiative zur integrierten virtuellen Produktentstehung Java 2 Platform, Enterprise Edition Jupiter-Tessellation Juxtapose Kleine und mittlere Unternehmen Local Area Network Lifecycle Applications (von ENOVIA) Management Numerical Control National Electronics Manufacturing Initiative Organization for Data Exchange by Tele-Transmission in Europe Original Equipment Manufacturer ODETTE File Transfer Protocol Object Management Group

13 xi P2P PDF PDM PDML PDMS PDTnet PDX PIM PLM PPS PSM RFP RMF SCM SDAI SE SML SOAP STEP TCP/IP TIFF TIS VDA-FS VDI VPDM VPM VR WAN WSDL WWW XMI XML Peer-To-Peer Portable Document Format Produktdatenmanagement Product Data Markup Language Produktdatenmanagementsystem Produktdatentechnologie und Kommunikation im Netzwerk von Automobilhersteller und Zulieferer Product Data exchange Platform Independent Model Produktlebenszyklusmanagement Produktionsplanung und steuerung Platform Specific Model Request-For-Proposal Resource Management Framework Supply Chain Management STEP Data Access Interface Simultaneous Engineering Sachmerkmalleiste Simple Object Access Protocol Standard for the Exchange of Product Model Data Transmission Control Protocol / Internet Protocol Tagged Image File Format Technisches Informationssystem Verband der Automobilindustrie - Flächenschnittstelle Verein Deutscher Ingenieure Virtuelles Produktdatenmanagement Virtual Product Development Management (von ENOVIA) Virtual Reality Wide Area Network Web Services Description Language World Wide Web XML Metadata Interchange extensible Markup Language

14 xii XPDI XSD XSLT ZSS extended Product Data Integration XML Schema Definition extensible Stylesheet Language Transformations Zeichnungsstammsatz

15 1 1 Einleitung 1.1 Ziel der Arbeit In der folgenden Arbeit soll aufgezeigt werden, welche Möglichkeiten Produktdatenmanagementsysteme für die kollaborative Produktentwicklung bereithalten. Insbesondere soll dabei auf dezentrale Ansätze mittels Einsatz von Peer-To-Peer-Architekturen eingegangen werden. Es ist zu prüfen, in welchen Fällen eine P2P-Architektur Vorteile gegenüber der Client-Server-Architektur bietet. Grundlage hierfür bietet die Untersuchung bestehender Produktdatenmanagementsysteme mittels Fallstudien. Des Weiteren ist Gegenstand der Arbeit, welche Anforderungen an Schnittstellen zwischen Produktdatenmanagementsystemen bestehen, um Produktdaten sicher zwischen diesen Systemen übertragen zu können. Außerdem wird ein Überblick über vorhandene Austauschformate und Lösungen geliefert. In diesem Zusammenhang wird die in der Arbeitsgruppe Wirtschaftsinformatik an der Technischen Universität Clausthal erstellte Lösung PCP (Product Collaboration Platform) eingeordnet und bewertet. 1.2 Überblick über den Aufbau der Arbeit In Kapitel 2 werden zunächst die für die Arbeit grundlegenden Begriffe definiert, so wie sie im Folgenden verstanden werden wollen, da über diese sowohl in der Literatur als auch in der Praxis kein einheitliches Verständnis besteht. In Abschnitt 2.1 wird festgelegt, welche Daten unter dem Begriff Produktdaten zusammengefasst werden. In Abschnitt 2.2 wird der Umfang des betrachteten Produktlebenszyklus festgelegt. Zur Einordnung der Gesamtproblematik wird in Abschnitt 2.3 das Produktlebenszyklusmanage-

16 2 ment vorgestellt. Der Kernbegriff Produktdatenmanagement wird in Abschnitt 2.4 erläutert und von anderen Begriffen abgegrenzt. Schließlich wird in Abschnitt 2.5 erläutert, was im Folgenden unter kollaborativer Produktentwicklung verstanden werden soll. In Kapitel 3 sollen die Probleme der Zusammenarbeit innerhalb bzw. zwischen Unternehmen aufgezeigt werden (Abschnitt 3.1) und Anforderungen sowie Beurteilungskriterien für Systeme zur Unterstützung der Kollaboration festgelegt werden (Abschnitt 3.2). Inhalt von Kapitel 4 ist die Beschreibung einer Fallstudie (4.1), die in mit Eigner PLM 5.0 und in mit Agile Advantage 2006 durchgeführt wird. In diesem Zusammenhang werden die Funktionalitäten der beiden Systeme dargelegt und die Architektur des Agile-Systems untersucht. Kapitel 5 beschäftigt sich mit möglichen Netzarchitekturen (5.1) und Austauschformaten (5.2), die für den Aufbau verteilter, kollaborativer PDM-Systeme in Frage kommen. Möglich Netzarchitekturen sind Client-Server-Architekturen (5.1.1) oder Peer-To-Peer-Architekturen (5.1.2), welche jeweils vorgestellt sowie Vorund Nachteile dargelegt werden. Als unvollständige Auswahl betrachteter Austauschformate werden STEP (5.2.1), PDTnet (5.2.2), PDML (5.2.3), PDX (5.2.4), JT (5.2.5) sowie die PDM Enablers der OMG (5.2.6) näher erläutert und ihr Nutzen bzgl. des Einsatzes in der kollaborativen Produktentwicklung bewertet. Die PDM Enablers nehmen dabei eine gewisse Sonderstellung ein, da es sich nicht um ein Dateiformat, sondern um eine CORBA-Standardschnittstelle zum Zugriff auf Objekte in PDM-Systemen handelt. In Kapitel 6 geht es um konkrete Lösungen bzw. theoretische Ansätze, die es für die kollaborative Produktentwicklung mittels PDM-System schon gibt. Eine unvollständige Auswahl wird in Abschnitt 6.1 vorgestellt. Die Auswahl beinhaltet die PLM Services von OMG (Abschnitt 6.1.1), den PDM-Collaborator (Abschnitt 6.1.2) und die Product Collaboration Plat-

17 3 form, die zurzeit von der Arbeitsgruppe Wirtschaftsinformatik an der Technischen Universität Clausthal entwickelt wird (Abschnitt 6.1.3). Im Anschluss (Abschnitt 6.2) wird der Einsatz der Peer-To-Peer- Architektur zur Lösung des Problems kollaborative Produktentwicklung diskutiert. Abschließend werden die Erkenntnisse dieser Arbeit in Kapitel 7 zusammengefasst und Schlussfolgerungen gezogen.

18 4 2 Begriffsdefinitionen In diesem einleitenden Kapitel werden die grundlegenden Begriffe dieser Arbeit definiert, so dass ihre Verwendung im Folgenden einheitlich geschehen kann. In der Literatur herrscht nicht immer Einigkeit über die Inhalte der erläuterten Begriffe, so dass evtl. nicht in jedem Fall eine Übereinstimmung gegeben ist. Des Weiteren verwendet die Industrie häufig Modebegriffe, um alte Konzepte neuer erscheinen zu lassen bzw. den Fortschritt ihrer Produkte zu betonen. 2.1 Produktdaten Produktdaten sind alle Daten, die sich auf ein Produkt oder einen Prozess zu dessen Entwicklung, Herstellung, Produktion oder Wartung beziehen [STAR 06, S. 82]. Die Daten sind nötig, um ein Produkt während dessen gesamten Lebenszyklus zu beschreiben. 1 Sie können nach vielen verschiedenen Kriterien klassifiziert werden: - der Phase des Produktlebenszyklus in der die Daten entstehen, - dem Mitarbeiter bzw. der Abteilung bzw. dem Unternehmen, in der sie erstellt werden, - dem Medium auf dem sie notiert sind, - dem Ort an dem sie gespeichert sind oder - dem Format in dem sie vorliegen [STAR 06, S. 82]. Dadurch dass Produktdaten auf vielfältige Weise vorliegen können, kann die Transformation in ein anderes Format, auf ein anderes System oder Medium schwierig oder unmöglich sein. Durch die große Menge an Produktdaten, die während eines Produktlebenszyklus entstehen, ist es notwendig, ein geeignetes System zur Klassifizierung zu nutzen, um die Wiederverwendung von Daten zu ermöglichen. 1 Vgl. aderlist]=p&tx_simpleglossar_pi1[showuid]=273,

19 5 Produktdaten repräsentieren das Know-how eines Unternehmens. Aus diesem und aus rechtlichen Gründen ist es erforderlich, die Produktdaten über lange Zeiträume zu archivieren. Dabei ist zu beachten, dass es notwendig sein kann, nicht nur elektronische sondern auch traditionelle Medien zu nutzen. Durch die schnelle Entwicklung von Anwendungssystemen und der Formate sowie der Speichermedien ist eine Wiederverwendung elektronischer Daten nach langen Speicherzeiten oft nicht möglich. In der Regel werden Produktdaten häufig geändert. Es ist notwendig die Änderungen der Daten nachvollziehbar zu machen und zu veröffentlichen. Größere Änderungen führen zu neuen Versionen der Produktdaten. Auch ältere Versionen müssen verfügbar bleiben. Produkte gibt es in zunehmend vielen Varianten, die möglichst effizient verwaltet werden müssen [STAR 06, S ]. Die zunehmende Vielfalt ist auf die stärkere Ausrichtung an Kundenanforderungen zurückzuführen. Für die Variantenverwaltung ist es grundlegend, die Struktur eines Produktes zu untersuchen, um möglichst zahlreiche Teile für viele Varianten wieder zu verwenden [SEND 05, S. 47]. Abhängig von der Aufgabe eines Mitarbeiters hat dieser andere Ansprüche an die Produktdaten und benötigt spezielle Zugriffsrechte. Jeder Mitarbeiter möchte eine möglichst passende Sicht auf die Produktdaten vorfinden. Des Weiteren müssen die Daten vor unzulässigen Zugriffen und Änderungen geschützt werden [STAR 06, S ]. Beispiele für Produktdaten sind: - Geometriedaten (3D CAD-Dateien, 2D CAD-Dateien, technische Zeichnungen in Papierform, eingescannte Zeichnungen, Fotos, Skizzen) - Test- und Analysedaten, Berechnungen (Feedbackresultate von Kunden aus Feldtests, analytische Modelle, Belastungsanalyseresultate, Stromkreisanalyseresultate, FEM-Ergebnisse, Simulationsergebnisse, Testdatendateien, Testprozeduren, Testresultatkommentare, thermodynamische Analyseergebnisse)

20 6 - Anweisungen und Handbücher (Aufbauanweisungen, Demontageanweisungen, Installationsanweisungen, Schweißanweisungen, Ausführungshandbuch, Benutzerhandbücher, Servicehandbücher) - Programme (Computerprogramme, die dem Produkt zugeordnet sind und solche, die für die Ausführung des Prozesses genutzt werden, NC-Programme) - Spezifikationen (Designspezifikationen, Entwürfe, Kundenanforderungen) - Produktstrukturdaten (Konfigurationen, Stücklisten, Verwendungsnachweise, Teilelisten, Varianten, Formeln) - Zustandsbeschreibungen bzw. Änderungsverlaufsdaten (Statusreports, as-ordered-, as-delivered-, in-process-, in-review-, released-, as-designed-, as-planned-, as-built-, as-installed-, asmaintained-, as-operated-konfiguration, Versionsmanagementdaten) - Prozessdaten (Projektpläne, Prozessmodelle, Prozesspläne, Arbeitspläne) - Werkzeugdesign, Vorrichtungsdesign [STAR 06, S. 82, 86-90, 237] Im Folgenden wird davon ausgegangen, dass Produktdaten in elektronischer Form vorliegen, wenn nicht ausdrücklich erwähnt wird, dass auch andere Medien eingeschlossen sind. 2.2 Produktlebenszyklus Der Begriff Produktlebenszyklus soll im Folgenden nicht dem in der Betriebswirtschaft gebräuchlichen Ausdruck entsprechen, der die Phasen Einführung, Wachstum, Reife, Sättigung und Rückgang umfasst und vor allem für Marketing und Vertrieb von Bedeutung ist [SCHI 00, S. 120]. Stattdessen wird der Begriff nachfolgend benutzt, um die Phasen von der Produktplanung, über die Konstruktion und Entwicklung, die Arbeitsvorbereitung, die Fertigung und Montage bis zum Vertrieb, der Inbetriebnahme

21 7 und der Wartung und der letzten Phase, dem Recycling, zu beschreiben (siehe Abbildung 1). 2 Abbildung 1: Produktlebenszyklus Produktlebenszyklusmanagement Der Begriff Produktlebenszyklusmanagement wird in der Literatur nicht einheitlich verwendet. Aus diesem Grund wird folgend eine Definition gegeben, die erläutert, wie der Begriff in der Arbeit zu verstehen ist. "PLM is the business activity of managing a company s products all the way across their lifecycles in the most effective way. PLM helps a company get its products to market faster, provide better support for their use, and manage end-of-life better." [STAR 06, S. 420] "PLM is a holistic business activity addressing many components such as products, organisational structure, working methods, processes, people, information structures and information systems. It s a new paradigm, a new way of looking at the world." [STAR 06, S. 16] Im Mai 2004 haben sich die Mitglieder des sendler/circle it-forums auf eine Definition für PLM geeinigt, die unter dem Namen "Liebensteiner Thesen" bekannt ist [SEND 05, S. 30]. 2 Vgl Vgl

22 8 "Liebensteiner Thesen Produkt Lifecycle Management (PLM) ist ein Konzept, kein System und keine (in sich abgeschlossene) Lösung. Zur Umsetzung/Realisierung eines PLM-Konzeptes werden Lösungskomponenten benötigt. Dazu zählen CAD, CAE, CAM, VR, PDM und andere Applikationen für den Produktentstehungsprozess. Auch Schnittstellen zu anderen Anwendungsbereichen wie Enterprise Resource Planning (ERP), Supply Chain Management (SCM) oder Customer Relationship Management (CRM) sind Komponenten eines PLM-Konzeptes. PLM-Anbieter offerieren Komponenten und/oder Dienstleistungen zur Umsetzung von PLM Konzepten." [SEND 05, S ] Mit der Einführung von PLM in einem Unternehmen ändert sich die Betrachtungsweise grundlegend. Sie ist nun nicht mehr vertikal funktionsorientiert sondern horizontal produktorientiert. Im Mittelpunkt steht nun der Produktlebenszyklus von der Wiege bis zur Bahre über die Funktionen hinweg [STAR 06, S. 8, 17]. Neben dem Fokus auf ein Produkt ermöglicht PLM die Betrachtung des gesamten Produktportfolios in einem Unternehmen, welches sowohl schon in Produktion befindliche als auch geplante Produkte enthält. Somit ist eine integrierte Verwaltung der gesamten Produktpalette möglich [STAR 06, S. 11, 20]. Der PLM-Ansatz kann über die Unternehmensgrenzen hinweg auch auf das erweiterte Unternehmen angewandt werden. PLM ermöglicht es, Geschäftsprozesse und Produktdaten global zu integrieren und somit Abteilungen, Geschäftspartner, Lieferanten und Kunden zu verbinden. 4 PLM gestattet die Echtzeit-Zusammenarbeit und Datenverteilung für zeitlich und räumlich verteilte Teams. Mittels offener Schnittstellen können heterogene IT-Welten angesprochen werden. Durch die Verwendung von 4 Vgl ; Vgl

23 9 Standards, auf die bei der Einführung von PLM Wert gelegt wird, kann der notwendige Datenaustausch vereinfacht und die Informationsbasis stabilisiert werden. 5 Für PLM ist es besonders wichtig, dass alle Systeme, die Zugriff auf die Produktdaten benötigen, eine einheitliche konsistente Datenbasis vorfinden. Solche Systeme können ERP / PPS, CAD, CAM usw. sein. Die Basis für diese Funktionalität im PLM bietet ein PDMS (siehe 2.4). Ziel von PLM ist es, dem Anwender über eine einheitliche Oberfläche transparenten Zugriff auf Daten und Prozesse verschiedener Verwaltungssysteme zu ermöglichen. 6 Zu jeder Zeit sollen die richtigen Informationen über ein Produkt am richtigen Ort zur Verfügung stehen. 7 PLM will universellen, sicheren und konsistenten Zugriff auf produktdefinierende Informationen ermöglichen. Der Begriff Information bezieht sich im PLM-Zusammenhang nur auf die digitale Repräsentation und nicht auf andere mögliche Medien. 8 Für PLM sind Prozesse ebenso wichtig wie Daten. Die Organisation des Datenflusses geht mit der Organisation der Prozesse einher, denn mit schlecht organisierten Prozessen kann auch durch optimierte Datenverwaltung kein verbessertes Ergebnis erzielt werden. 9 Unternehmensweites PLM ändert die Organisationsstruktur und Verantwortlichkeiten im Unternehmen und kann nur durch Re-Engineering erreicht werden. Es ändern sich die Zusammenhänge zwischen Prozessen, die Art und Weise wie Menschen arbeiten und wie Systeme zusammengehören [STAR 06, S. 8, 226]. Um bei der Einführung von PLM die Komplexität beherrschen zu können, werden die verschiedenen Funktionen in einzelnen Projekten implementiert. Dabei darf es jedoch nicht zur Isolierung einzelner Aspekte kommen; die in Abbildung 2 dargestellten Abhängigkeiten müssen unbedingt 5 Vgl Vgl Vgl. derlist]=p&tx_simpleglossar_pi1[showuid]=180, Vgl Vgl

24 10 beachtet werden. Zunächst sind die Grundfunktionen "Klassifizierung und Benennung" sowie "Produktstrukturmanagement" als Voraussetzung für alle weiteren Funktionen zu implementieren. Danach können das Daten- & Dokumentenmanagement und die weiteren in Abbildung 2 gezeigten Basisfunktionen eingeführt werden. Anschließend werden die erweiterten Funktionen und schließlich nach Bedarf die Premiumfunktionen etabliert [ARNO 05, S ]. Abbildung 2: Abhängigkeiten der PLM-Funktionsblöcke [ARNO 05, S. 49] PLM ist wie ERP ein Kernprozess im Unternehmen. Während sich PLM mit den Produkten beschäftigt, steht bei ERP die Produktion im Vordergrund. Wie in Abbildung 3 zu sehen ist, stehen die beiden Konzepte orthogonal zueinander und besitzen eine Schnittstelle [ARNO 05, S. 14].

25 11 Abbildung 3: PLM und ERP [ARNO 05, S. 14] 2.4 Produktdatenmanagement Ebenso wie der Begriff PLM in der Realität oft unterschiedlich gebraucht wird, ist auch beim Begriff PDM oft nicht klar, welche Konzepte der Autor bzw. Hersteller einer PDM-Lösung einbezieht. Des Weiteren hat PDM mittlerweile eine historische Entwicklung durchlebt, in der sich der Begriff weiterentwickelt hat. Aus diesen Gründen wird in definiert, was unter PDM im Weiteren zu verstehen ist. Im Laufe der Jahre haben sich spezielle Ausrichtungen und Erweiterungen von PDM entwickelt. Einige Beispiele werden in erläutert. Des Weiteren wird dort, um Verwechslungen mit anderen Begriffen vorzubeugen und die Einordnung von PDM noch klarer zu definieren, PDM anderen Begriffen gegenübergestellt.

26 Definition Produktdatenmanagement Produktdatenmanagement ist das Konzept, auf der Basis eines integrierten Produktmodells, Daten und Dokumente zu speichern, zu verwalten und zur Verfügung zu stellen. Auch die Unterstützung insbesondere der Produktentwicklung auf Basis eines Prozessmodells gehört zum PDM. Produktdatenmanagementsysteme sind Teil des betrieblichen Informations- und Koordinationssystems und setzten das Konzept PDM um. 10 Das integrierte Produktmodell ist eine zentrale Zusammenstellung aller Informationen über ein Produkt, die während des Produktlebenszyklus entstehen. Das integrierte Produktmodell besteht aus Partialmodellen, die jeweils in verschiedenen Erzeugersystemen entstehen, und ergänzenden Struktur- und Stammdaten. Viele standardisierte Austauschformate, wie z. B. STEP (siehe ) basieren auf dem integrierten Produktmodell [ARNO 05, S ]. PDM-Systeme sind technische Datenbank- und Kommunikationssysteme, die dazu dienen, Informationen über Produkte und deren Entstehungsprozesse bzw. Lebenszyklen konsistent zu speichern, zu verwalten und transparent für alle relevanten Bereichen eines Unternehmens bereitzustellen. [VDI 02, S. 4] Ein PDMS bildet die Grundlage für ein Gesamtsystem, welches durch die Verbindung von am Produktentwicklungsprozess beteiligten Anwendungssystemen (z. B. CAx-Systeme, Office-Programme, NC-Tools usw.) über Schnittstellen entsteht [ARNO 05, S ]. Die Schnittstellen im PDM haben die Aufgabe, Daten mit anderen Systemen auszutauschen und sicherzustellen, dass die Daten über Systemgrenzen hinweg konsistent sind und dieselbe Aktualität besitzen. Wie in Abbildung 4 zu sehen ist, integriert ein PDMS wie z. B. PRO-FILE alle Autorensysteme, die am Produktentwicklungsprozess beteiligt sind [SEND 05, S. 80]. 10 Vgl ; Vgl

27 13 Abbildung 4: Schnittstellen zu PDM [SEND 05, S. 80] PDM-Systeme bieten Artikel (Einzelteile, Baugruppen, Produkte), Dokumente und Projekte als Basisobjekte [SEND 05, S ]. Auf diese Objekte werden dann die PDM-Funktionen angewandt. Die Grundfunktionen, die ein PDMS bieten sollte sind: - Erstellen von Stücklisten (insbesondere Konstruktionsstücklisten), - Klassifizierung der Artikel mittels SML (Variantenmanagement und Erhöhung der Wiederverwendung), - Objektstatus und Workflow (der Status legt fest, wer als nächstes welche Berechtigungen an einem Objekt hat und welche möglichen Folgezustände möglich sind), - Versionierung (durch Änderungen an einem Produkt), - Benutzerverwaltung und rechte, - Sperren von Objekten (Vermeidung von gleichzeitig entstehenden konkurrierenden Änderungen), - Datenhaltung der Stammdaten / Metadaten in einer Datenbank und der Dokumente in geschützten Bereichen, - Erstellung von neutralen Datenformaten (zur leichteren Austauschbarkeit und Archivierung; mögliche Formate sind für 3D-Modelle z. B. STEP und für technische Zeichnungen z. B. TIFF oder PDF). [SEND 05, S ]

28 14 PDM-Systeme sind meistens modular aufgebaut. Es gibt ein Basismodul, das um weitere Module ergänzt werden kann, so dass ein Anwender die Funktionalität erhält, die er benötigt. Des Weiteren kann das PDMS später im Bedarfsfall erweitert werden [ARNO 05, S. 164]. Zum Speichern der Dokumente wird in PDM-Systemen ein geschützter Speicherbereich eingerichtet. Der Zugriff auf darin befindliche Dokumente ist dann nur über das PDMS möglich, um unberechtigtem Zugriff vorzubeugen und mittels Check-In- und Check-Out-Funktionen konkurrierende Änderungen der Dokumente zu vermeiden [ARNO 05, S ]. Über die gespeicherten Dokumente werden Metadaten angelegt, welche zusammen mit Informationen über die Artikel, Projekte, Kunden usw. in einer evtl. verteilten Datenbank verwaltet werden [SCHO 99, S. 94]. Die Datenbank kann ebenfalls geschützt sein, und wird in diesem Fall als "Vault" bezeichnet. Der Bereich, in dem die Dokumente gespeichert werden, wird als "Vault-Location" bezeichnet. Abbildung 5 zeigt den Zusammenhang zwischen Vault und Vault-Location. In der Datenbank wird für eine Zeichnung ein Zeichnungsstammsatz angelegt, welcher ID, Änderungsindex, Namen, Werkstoff usw. enthalten kann. Des Weiteren wird mindestens ein Zeichnungsblatt zu der Zeichnung angelegt, in der die Blattnummer, das Zeichnungsformat usw. beschrieben werden. Außerdem ist der Ablagebereich der zugehörigen Datei im File-System verzeichnet [SCHO 99, S ]. Abbildung 5: Dokumentenverwaltung im PDM mittels Vault und Vault-Location [SCHO 99, S. 96] Die meisten PDM-Systeme sind mit Client-Server-Architekturen realisiert. Es gibt einen PDM-Server und mehrere PDM-Clients [ARNO 05, S. 164].

29 15 Auf einem Hardware-Server liegen die Datenbank mit den Vaults für die Metadaten, der Software-Server des DBM- und des PDM-Systems. Die Dokumente selbst sind meistens dezentral auf die Vault-Locations der File-Systeme von Arbeitsplatzrechnern oder, im Falle verteilter Installationen, lokaler Server verteilt (siehe Abbildung 6) [SCHO 99, S. 110]. Abbildung 6: PDM mit Client-Server-Architektur [SCHO 99, S. 110] Durch die Workflowmanagement-Funktionalität von PDM-Systemen können diese Arbeits- und Freigabeabläufe steuern, überwachen und dokumentieren. Dadurch wird die Zusammenarbeit sowohl in der Konstruktion als auch mit Nachbarabteilungen unterstützt Vgl

30 Übersicht über erweiterte PDM-Begriffe, Abgrenzung gegenüber verwandten Begriffen und Synonyme Der Begriff cpdm beschreibt das Konzept von PDM, welches um Möglichkeiten der Produkt- und Prozessverwaltung im erweiterten Unternehmen mittels Internet und Webtechnologien erweitert wird [CONT 02, S ]. Der Begriff GPM bezieht sich auf die Verwaltung von Produktdaten auf globaler Ebene. Sowohl die verteilten Niederlassungen eines Unternehmens als auch weltweite Zulieferer sollen Zugang zu Produktdaten erhalten [DOBL 98, S. 1]. Das Engineering Data Management ist der zeitliche Vorgänger von PDM [GOLT 02, S. 59]. Häufig werden die Begriffe EDM und PDM jedoch auch völlig synonym verwendet. 12 PDM-Systeme sind Technische Informationssysteme. Die von einem PDMS verwalteten Daten und Prozesse sind technischen Ursprungs. Im Gegensatz dazu sind ERP-Systeme Kommerzielle Informationssysteme, d. h. es geht um die Bearbeitung betriebswirtschaftlich-planerischer Aufgaben [SCHO 99, S. 56]. ERP ist das zentrale Konzept entlang der Wertschöpfungskette (Beschaffung, Produktion, Absatz). Ziel ist dabei die Planung und Steuerung von Aufträgen und die effiziente Einplanung von Unternehmensressourcen [SCHO 99, S. 6-7]. ERP-Systeme beschäftigen sich mit der Produktion einer bestimmten Konfiguration eines Produkts, während sich PDM- Systeme um die Entwicklung und Darstellung verschiedener Konfigurationen eines Produktes kümmern [SEND 05, S. 35]. Der Begriff ERP wird weitgehend synonym mit dem Begriff Produktionsplanung und -steuerung verwendet [SCHO 99, S. 6]. Der Fokus von PDM liegt nicht auf der Integration von Computersystemen, sondern auf der Verbesserung des Flusses, der Qualität und des Nutzens von Produktdaten. Damit ist PDM nicht identisch mit Computer Integrated 12 Vgl

31 17 Manufacturing [STAR 06, S. 285]. Das Y-CIM-Modell von A.-W. Scheer stellt Industrieprozesse in zwei Ästen dar. Der linke Ast beschreibt die betriebswirtschaftlich-logistische Prozesskette, während der rechte Ast die technische Prozesskette fokussiert. Die Vorgänge auf der linken Seite des Y-CIM-Modells werden durch ein ERP-Tool unterstützt, auf der Seite der technischen Prozesse kommen CAx-Werkzeuge zum Einsatz. Wie in Abbildung 7 zu erkennen ist, befindet sich das PLM-Konzept (und damit auch PDM) durch seinen Integrationscharakter zwischen beiden Ästen [SCHE 06, S. 4-11]. Abbildung 7: PLM als Bindeglied zwischen den Säulen Produktion und Produktentwicklung des Y-CIM-Modells [SCHE 06, S. 14] Synonyme für PDM sind: Enterprise Product Data Management, Product Development Management, Virtual Product Development Management, Product Information Management, Technical Information Management und Engineering Database [SCHO 99, S. 93].

32 Kollaborative Produktentwicklung Unter Kollaboration versteht man die Zusammenarbeit mehrerer Einzelpersonen. 13 Viele Unternehmen sind heutzutage weltweit verteilt. Dieses bedingt, dass Teams ohne Rücksicht auf Raum- und Zeitunterschiede zusammenarbeiten müssen [STAR 06, S. 98]. Verstreute Entwicklungsteams arbeiten meistens mit verschiedenen Systemen zur Unterstützung des Produktentwicklungsprozesses, was zu Schnittstellenproblemen führt [BULL 99, S. 5]. Kollaboration kann auf verschiedenen Ebenen stattfinden. Die Zusammenarbeit kann zeitlich versetzt oder gleichzeitig erfolgen. Das Team kann sich innerhalb eines Raumes aufhalten oder über den gesamten Globus verteilt sein. Ein weiteres Klassifizierungsmerkmal für die Zusammenarbeit ist die Systemvielfalt, die während der Entwicklung eingesetzt wird. Es ist möglich, dass verschiedene CAx-Tools eingesetzt werden, jedoch genau ein PDMS. In der Zusammenarbeit verschiedener Unternehmen ist allerdings mit einer heterogenen PDMS-Landschaft zu rechnen. Für die kollaborative Produktentwicklung ist es also unumgänglich, dass verschiedene Formate und Modelle aufeinander treffen. Diese Schnittstellenproblematik führt dazu, dass n * (n - 1) Formatkonvertierungen zwischen je zwei Systemen nötig sind (bei n verschiedenen Systemen insgesamt). Alternativ kann ein standardisiertes Austauschformat benutzt werden. Dadurch wird die Anzahl der zu programmierenden Schnittstellen erheblich reduziert (auf 2 * n) [LUEH 96, S. 1] und die Abhängigkeit von bestimmten proprietären Formaten und deren Hersteller reduziert. Diese Situation kann durch den Einsatz von PDM weiter verbessert werden. Abbildung 8 zeigt exemplarisch den möglichen Datentransfer zwischen Auftraggeber und Zulieferer. In diesem Fall sollen CAx- und deren PDM-Beschreibungsdaten übertragen werden. Die ISO-Norm STEP 13 Vgl ; Vgl

33 19 bietet hier den Vorteil, dass vollständige PDM-Produktmodelle übermittelt werden können. Mittels eines STEP-Preprozessors werden die zu übertragenden Daten in STEP-Files verwandelt. Die Daten werden zum Zulieferer gesendet und dort mittels eines Post-Prozessors aus dem STEP-Format in das gewünschte Zielformat überführt. Sie können dann in Vault und Vault-Location des dortigen PDMS importiert werden. Die Details der Übertragung mittels OFTP und ISDN sollen hier unberücksichtigt bleiben, da sie auf zum Teil veralteten Annahmen beruhen bzw. irrelevant sind. Es sei hier noch erwähnt, dass ENGDAT ein Standard zum Austausch von Konstruktionsdaten in der deutschen Automobilindustrie ist. ENGDAT ist eine Untermenge von EDIFACT, der EDI- Standardsprache nach ISO 9735 [SCHO 99, S ]. Abbildung 8: Datenaustausch mittels Austauschformat [SCHO 99, S. 313] Die Zusammenarbeit in Teams unterstützt durch PDM-Systeme ermöglicht Concurrent bzw. Simultaneous Engineering. Die Arbeitsschritte in der Entwicklungsphase werden oft jeweils mehrfach durchlaufen, bis eine abschließende Lösung gefunden ist. Der anschließende Schritt kann erst hinterher beginnen. Es kommt also zu einer sequentiellen Ausführung der Schritte im Entwicklungs- und Konstruktionsprozess. CE bedeutet nun, dass ein Arbeitsschritt seine Zwischenergebnisse schon früher bereitstellt, so dass nachgelagerte Phasen schon vor der abschließenden Freigabe gestartet werden können (siehe Abbildung 9). Dieses führt zu zeitparallelen Arbeitsschritten. CE hat zum einen eine Zeitersparnis zur Folge. Zum anderen können Fehler früher aufgedeckt werden und Bedürfnisse

34 20 späterer Schritte früher berücksichtigt werden. Diese Ausführung zeitparalleler Arbeitsprozesse benötigt eine ständige Synchronisation von Informationen. Die Mitarbeiter müssen ihre Ergebnisse stets miteinander abstimmen. Dafür ist ein TIS unabdingbar, denn die Informationen müssen ständig für die Mitarbeiter bereitstehen. Zur Koordination und Kontrolle der Arbeiten müssen Prozess- und Projektmanagement eingesetzt werden [SCHO 99, S ]. Abbildung 9: Unterstützung von Concurrent Engineering durch PDM [SCHO 99, S. 78]

35 21 3 Kollaborative Produktentwicklung In diesem Kapitel soll herausgestellt werden, welche Annahmen an die kollaborative Produktentwicklung gestellt werden und welche Probleme auftreten können. Dabei sollen mögliche Szenarien unterschieden werden (3.1). Des Weiteren sollen Anforderungen, welche die kollaborative Produktentwicklung an ein PDMS stellt, erarbeitet und Beurteilungskriterien für deren Leistung in der kollaborativen Umgebung festgelegt werden (3.2). 3.1 Annahmen und Probleme für die Interoperabilität im Unternehmen und über Unternehmensgrenzen hinweg Als grundlegende Annahme soll getroffen werden, dass allen an der Kollaboration beteiligten Parteien ein Internetzugang mit mindestens DSL- Geschwindigkeit (Uploadrate: 128 kbit/s; Downloadrate: 1024 kbit/s) 14 zur Verfügung steht Interoperabilität im Unternehmen Es wird davon ausgegangen, dass innerhalb eines Unternehmens nur ein PDMS vorhanden ist, welches die Zusammenarbeit der Mitarbeiter steuert. Das Unternehmen kann im einfachsten Fall an nur einem Standort stationiert sein und sich somit auf eine Zeitzone und Sprache konzentrieren. Jedoch ist es auch möglich, dass es sich um ein verteiltes Unternehmen handelt, wobei Sprach- und Zeitzonenunterschiede eine Rolle spielen können. Des Weiteren wird die Annahme getroffen, dass innerhalb einer Firma die grundsätzliche Bereitschaft besteht, einen zentralen Server zu betreiben

36 22 Der Aufwand für die Etablierung der Kollaboration kann verhältnismäßig hoch sein, da von einer dauerhaften Nutzung der einmal errichteten Kollaborationsplattform ausgegangen wird Interoperabilität zwischen mehreren Unternehmen Im Falle der Kollaboration mehrerer Unternehmen auch virtuelles Unternehmen ist damit zu rechnen, auf eine heterogene PDMS- Landschaft zu treffen [DOMA 00, S. 1]. Es wird davon ausgegangen, dass kein beteiligter Partner bereit ist, zwangsweise auf das PDMS eines Abnehmers, Zulieferers oder Entwicklungspartners umzusatteln. Ferner muss neben der Heterogenität der PDMS-Landschaft auch von Heterogenität bzgl. Hardware, Software und Datenformat ausgegangen werden [DOBL 98, S. 7]. Es wird angenommen, dass kein Partner bereit ist, die Wartung und Finanzierung eines Servers, welcher auch von den anderen Mitstreitern genutzt wird, zu übernehmen. Zusätzlich wird unterstellt, dass die Teilnehmer nicht damit einverstanden sind, dass Kopien von Daten, die in ihrem Unternehmen erstellt wurden, in fremden Systemen gespeichert bzw. verwaltet werden. Weiterhin soll der Aufbau der Kollaboration mit möglichst geringem Aufwand verbunden sein, so dass auch innerhalb kurzer Zeit für kurzfristige Zusammenarbeit ein Einsatz möglich ist [DOBL 98, S. 8]. Nicht vernachlässigt werden darf, insbesondere in der Zusammenarbeit mehrerer Unternehmen, dass bestimmte Informationen nicht allen bzw. keinen Partnern zugänglich sein dürfen. Wer, wann welche Informationen bekommen darf, muss flexibel und sicher zugewiesen werden können [DOBL 98, S. 7]. Des Weiteren soll die Möglichkeit bestehen, dass jeder Partner stets die Zusammenarbeit abbrechen und aus dem Verbund der Kollaborationsge-

37 23 meinschaft austreten kann, ohne dass daraus Nachteile für die übrigen Mietglieder entstehen dürfen. 3.2 Anforderungen und Beurteilungskriterien Die kollaborative Produktentwicklung stellt zunächst Anforderungen an die Zuverlässigkeit der Datenverfügbarkeit. Es muss sichergestellt werden, dass stets die aktuellsten Informationen bzw. Informationen in einer angeforderten Konfiguration konsistent und transparent für alle berechtigten Partner zur Verfügung stehen. Auch die Möglichkeiten zur effizienten Suche nach Informationen spielt in diesem Zusammenhang eine Rolle [DOBL 98, S ]. Außerdem müssen die Daten für alle Teilnehmer lesbar sein. Liegen Informationen nur in einem proprietären Format vor, sind sie wahrscheinlich nicht für alle Interessenten verwendbar. Unter Umständen kann es ausreichend sein, ein neutrales Format zu wählen, dass allen die Ansicht, nicht jedoch die Bearbeitung von Dateien, ermöglicht (z. B. TIFF). In vielen Fällen reicht diese Zugriffsmöglichkeit jedoch nicht aus und es muss ein mächtigeres, neutrales Datenformat für den Austausch z. B. von 3D- CAD-Dateien gewählt werden [SCHO 99, S. 61; CONT 02, S ]. Insbesondere bei der Zusammenarbeit mehrerer Unternehmen muss gewährleistet werden, dass kein zufälliger und / oder beabsichtigter Zugriff auf nicht freigegebene Informationen möglich ist. Der Zugriff auf sensible Daten muss flexibel anpassbar sein, d. h. es muss möglich sein, festzulegen, wer, wann, zu welchen Informationen Zugang bekommt [DOBL 98, S. 7, 14]. Ein weiteres Beurteilungskriterium stellt der Umfang der möglichen Kollaboration dar. Ist die Kollaboration rund um die Uhr möglich? Geht es allein um Datenaustausch oder sind Unterstützung von Konferenzen und Absprachen nötig? In wie weit wird die Suche nach Informationen unterstützt?

38 24 Des Weiteren muss es möglich sein, einen Workflow für die Strukturierung des Produktentwicklungsprozesses entlang aller Kollaborationsteilnehmer zu erstellen und den Datenfluss (zum Teil) zu automatisieren. Dieser Workflow muss jedoch flexibel anpassbar und dynamisch sein [DOMA 00, S. 2]. Ein für das Gesamtverhalten weiterhin wichtiges Kriterium ist die mögliche Granularität des Datenzugriffs [DOMA 00, S. 2]. Umso gröber die Granularität ist, desto mehr Daten bleiben für die Bearbeitung durch weitere Nutzer gesperrt, wenn ein Nutzer sie durch ein Check-Out für sich reserviert hat. Des Weiteren erhöht sich die Menge der zu übertragenden Daten. Ideal wäre eine Granularitätsstufe, die es erlaubt, auf einzelne Eigenschaften eines Produktes zuzugreifen, um diese zu ändern, ohne vollständige Dateien bzw. gänzliche Informationen zu einem Artikel sperren zu müssen. Schließlich spielen Kriterien wie durchschnittliche und maximale Zugriffsgeschwindigkeit, Verfügbarkeit sowie Datenintegrität eine große Rolle [DOBL 98, S ].

39 25 4 Klassifizierung von Produktdatenmanagementsystemen In diesem Kapitel wird zunächst eine exemplarische Fallstudie (4.1) vorgestellt und anschließend mit den beiden verfügbaren PLM-Lösungen Eigner PLM 5.0 (4.2.1) und Agile Advantage 2006 (4.2.2) durchgeführt. 15 Anhand der Fallstudie soll die Funktionalität der Systeme demonstriert und anschließend beurteilt werden, ob die in Abschnitt erwähnten Funktionalitäten eines PDM-Systems bereitgestellt werden. Des Weiteren soll auf die Architektur der PDM-Systeme eingegangen werden. 4.1 Fallstudie Zur Demonstration des Funktionsumfangs der PLM-Lösungen Eigner PLM 5.0 und Agile Advantage 2006 und zur Untersuchung der Architektur soll eine Fallstudie durchgeführt werden. Innerhalb der Fallstudie soll es darum gehen, ein LEGO -Haus zu errichten. Im ersten Schritt werden verschiedene Einzelteile angelegt, Baugruppen definiert und Stücklisten erzeugt sowie ausgegeben. Als Einzelteile werden 2x2- und 2x3-Steine, Dachziegel und Dachfirstplatten, Fenster und Türen angelegt. Als Baugruppen sollen Wände aus Steinen und optional zusätzlich Türen und Fenstern bestehen. Das Dach setzt sich aus Dachziegeln und firstplatten zusammen. Aus diesen Baugruppen wird dann wiederum das Produkt Haus zusammengefügt (siehe Abbildung 10). 15 Anmerkung: Die Hersteller bezeichnen ihre Produkte selbst als PLM-Systeme, eigentlich sind es jedoch allenfalls PDM-Systeme. Zur Unterscheidung siehe Abschnitt 2.3 und 2.4. Im Weiteren wird hier trotzdem die Bezeichnung als PLM-System übernommen.

40 26 Abbildung 10: Baumstruktur des LEGO -Hauses Im nächsten Schritt sollen den erzeugten Artikeln vorhandene Dokumente (Textdokumente, 3D-CAD-Dateien, Zeichnungen, usw.) zugeordnet werden. Danach wird ein Projekt zum Hausbau definiert und die Teilprojekte Produktion der Einzelteile, Rohbau und Dachbau angelegt. Den Projekten werden dann die jeweiligen Baugruppen zugeordnet. Im vierten Schritt geht es um die Anlage von Varianten. Die Steine können verschiedene Farben bekommen, die Wände können unterschiedlich lang sein und das Dach kann verschieden groß sein. Im nächsten Schritt wird auf das Thema Klassifizierung eingegangen. Zu diesem Zweck wird eine abstrakte Klasse Baustein mit dem Attribut Breite erzeugt. Als Unterklassen werden dann Steine (Attribute: Länge, Farbe), Dachziegel (Attribute: Höhe) und sonstige Bausteine angelegt. Sonstige Bausteine können Dachfirstplatten, Türen (Attribut: Höhe) und Fenster (Attribute: Tiefe, zu_öffnen) sein. Anschließend wird ein Kundenauftrag angelegt. Schließlich soll ein Workflow für die Bearbeitung von Änderungsanträgen festgelegt und ausgeführt werden. In der Fallstudie wird angenommen, dass das Material der Dachziegel nach deren Freigabe verändert werden soll. Statt rotem Kunststoff soll zukünftig durchsichtiger Kunststoff verwendet werden, um komfortablere Einblicke zu ermöglichen.

41 Verwendete Architekturen und Funktionsanalyse Die beschriebene Fallstudie wird mit dem Eigner PLM 5.0 und Agile Advantage durchgeführt. Dabei wird kurz die Architektur der PLM-Systeme erläutert und die grundsätzliche Funktionsweise und Bedienung aufgezeigt Eigner PLM 5.0 Aufbau der Benutzeroberfläche Die Client-Oberfläche des Eigner PLM 5.0 (siehe Anhang A, Screenshot 1) gliedert sich im Wesentlichen in sieben Bestandteile. Neben dem Hauptfenster, in dem sich Masken zur Bearbeitung und Verwaltung von Objekten öffnen, finden sich optional zwei so genannte Browserfenster, in dem zuletzt verwendete Objekte angesteuert (Favoriten) bzw. Objekte in übersichtlichen Baumstrukturen angezeigt werden können. Ein weiteres Fenster dient als Log und zeigt Anmerkungen und Fehlerberichte an. Ansonsten finden sich eine Statuszeile, eine Menü- und eine Symbolleiste zur Nutzung der Funktionen des Eigner PLMs. Die Anordnung der Elemente sowie das Anzeigen verschiedener Buttons und Elemente sind individuell anpassbar. Anlegen von Artikeln In Eigner PLM 5.0 werden alle Teile als Artikel angelegt (siehe Anhang A, Screenshot 2). Es öffnet sich ein Fenster innerhalb des Hauptbereichs von Eigner PLM 5.0, in dem Artikel-Nr., Name eingetragen und weitere Angaben über z. B. Werkstoff und Einheit sowie zu verwendenden Prüfablauf gemacht werden können. Das Anlegen von Artikeln kann auch abhängig von vorhandenen Lizenzen direkt integriert aus anderen Anwendungen (z. B. CAD-Systemen) geschehen. Zu diesem Zweck wird innerhalb der Anwendung eine Funktion Speichern in Eigner PLM o. ä. bereitgestellt, die automatisch den Eigner PLM Client startet und hierin Fenster zum Anlegen eines Artikels und Dokuments öffnen, wobei im Idealfall schon einige Felder vorausgefüllt sein können.

42 28 Zur Übersicht ist es möglich, sich eine Artikelliste - eingeschränkt auf ein selbstdefiniertes Suchkriterium - ausgeben zu lassen (siehe Anhang A, Screenshot 3). Von dieser Liste kann direkt das Fenster zur Beschreibung eines Artikels zur Bearbeitung geöffnet werden. Anlegen der Produktstruktur Über die Tabs Stückliste bzw. Verwendung kann die Struktur der Beziehungen der Artikel untereinander angelegt bzw. betrachtet werden. Die sich daraus ergebende Stückliste kann dann sowohl im internen Browser (siehe Anhang A, Screenshot 4), im externen Browser (graphischer Browser) als auch als Strukturauflösung (siehe Anhang A, Screenshot 5) angezeigt werden. Analog ist die Betrachtung eines Verwendungsnachweises möglich. Verwaltung von Dokumenten Neben dem Anlegen von Artikeln ist außerdem das Anlegen von Dokumenten möglich (siehe Anhang A, Screenshot 6). Dabei werden im Eigner PLM 5.0 verschiedene Arten von Dokumenten (gespeicherte Dokumente, 2D-Zeichnungen, 3D-Modelle, physikalische Modelle, Dokumente mit Dateiangabe, archivierte (Papier-) Dokumente, Office-Dokumente) unterschieden, die jeweils andere Eintragungen ermöglichen oder bedingen. Die Dokumente können auch direkt aus der Ursprungsanwendung in Eigner PLM 5.0 gespeichert werden, falls eine geeignete Schnittstelle und eine Lizenz vorhanden sind. Die angelegten Dokumente werden auf dem File-Server (außer Dokumente mit Dateiangabe, bei denen dieses explizit vermieden wird) in einem bestimmten Sicherheitsbereich gespeichert (siehe Abbildung 11).

43 29 Abbildung 11: Speichern eines Dokuments auf dem Fileserver des Eigner PLMs 16 Dokumente, die im Eigner PLM 5.0 angelegt wurden, können anschließend mit Check-Out vom Nutzer reserviert werden und mit Check-In freigegeben werden (siehe Anhang A, Screenshot 7). So wird verhindert, dass mehrere Nutzer gleichzeitig konkurrierende Änderungen an Dokumenten vornehmen können. Über den Reiter Dokumente im Fenster eines Artikels können Dokumente Artikeln zugeordnet werden (bzw. entsprechend analog über den Reiter in Artikeln des Fensters eines Dokuments). Anlegen von Projekten Ähnlich wie Dokumente und Artikel lassen sich auch Projekte anlegen, die wiederum sowohl eine hierarchische Struktur untereinander haben können (siehe Anhang A, Screenshot 8), als auch Dokumenten und Artikeln über entsprechende Reiter zugeordnet werden können. Variantenmanagement Zur Anlage von Varianten werden Variantenplatzhalter ähnlich wie Artikel angelegt. Unter dem entsprechendem Reiter können Attribute definiert 16 Vgl. Tutorium des Eigner 5.0 Praktikums im Institut für Maschinenwesen der Technischen Universität Clausthal,

44 30 werden, welche die Unterscheidungsmerkmale der Varianten darstellen (siehe Anhang A, Screenshot 9). In der Variantenleiste eines Variantenplatzhalters werden die möglichen, konkreten Artikel hinterlegt, die für den Variantenplatzhalter eingesetzt werden können (siehe Anhang A, Screenshot 10). Ein Variantenplatzhalter wird wie ein Artikel als Teil einer Stückliste benutzt. Bei der Generierung eines konkreten Kundenauftrags wird vom Eigner PLM 5.0 abgefragt, welcher konkrete Artikel für den Variantenplatzhalter eingesetzt werden soll. Klassifizierung von Artikeln Zur Klassifizierung von Artikeln gibt es im Eigner PLM 5.0 die Möglichkeit, zunächst Attribute anzulegen und diese anschließend bei der Erstellung von Klassen zu benutzen. Die Klassen können eine Hierarchie bilden (siehe Anhang A, Screenshot 11), wobei Subklassen die zu verwendenden Attribute von den Superklassen erben. Unter dem Reiter Sachm.Leiste einer Klasse können die verschiedenen Artikel der Klasse dann aufgelistet und die Attribute mit Werten hinterlegt werden (siehe Anhang A, Screenshot 12). Kundenauftrag und kundenspezifische Stückliste Bei der Anlage eines Kundenauftrags in Eigner PLM 5.0 werden die Positionen des Auftrags in einer Liste hinterlegt. Über den Befehl Ableiten Struktur wird dann die auftragsspezifische Strukturauflösung für eine Position erzeugt. Dabei werden automatisch Abfragen wie in Screenshot 13 (siehe Anhang A) generiert, wobei Varianten aufgelöst und optionale Bauteile abgefragt werden. Workflowmanagement Den Objekten in Eigner PLM 5.0 können Prüfabläufe zugeordnet werden. Neben den vorhandenen Abläufen können mittels Workflow-Editor (siehe Anhang A, Screenshot 14) oder per Liste neue Workflows erstellt werden. Der zugeordnete Prüfablauf kann nach dem Speichern nicht mehr geändert werden. Durch Betätigen des Ampelbuttons, wird der Status eines

45 31 Objekts gewechselt. Nachdem ein Objekt freigegeben wurde (letzter Status), kann über das Kontextmenü eine neue Version des Objekts angelegt werden. Über das Kontextmenü der neuen Version kann der Vorgänger aufgerufen werden und eine Änderungsbeschreibung zugeordnet werden. Weitere Funktionalität Weitere Funktionen, die Eigner PLM 5.0 bietet, sind unter anderem Rollenkonzepte und Gruppenbildung mit Festlegung bestimmter Privilegien, sowie Unterstützung von Arbeitsabläufen mittels Benachrichtigungskonzept, des Weiteren Drucken und Exportieren in die Formate PDF und TIFF. PDM-Funktion Eigner PLM 5.0 Stücklisten erstellen Klassifizierung Workflows Versionierung Benutzerverwaltung Check-Out & Check-In Metadatenhaltung in einer Datenbank Dokumentenhaltung in einem geschütztem Bereich Erstellung von neutralen Datenformaten PDF, TIFF Tabelle 1: Erfüllung der PDM-Funktionalitäten (siehe Abschnitt 2.4.1) durch Eigner PLM 5.0 Die Evaluation der Basisfunktionen des PLM-Systems Eigner PLM 5.0 wurde in dieser Arbeit dank einer Kooperation mit dem Institut für Maschinenwesen (IMW) der TU Clausthal ermöglicht. Die ersten Erfahrungen im Umgang mit Eigner PLM haben gezeigt, dass der Betrieb eines eigenen PLM-Systems für die weiteren Forschungsvorhaben der Arbeitsgruppe Wirtschaftsinformatik von Vorteil wäre. Die Wahl fiel dabei auf einen Nachfolger von Eigner PLM 5.0 Agile Advantage 2006 von der Firma Agile im Rahmen einer Forschungszusammenarbeit. Die PLM-Lösung Agile Advantage 2006 ist das System von Agile, das auf KMU ausgerich-

46 32 tet ist. Da insbesondere die Kollaboration von / mit KMU im Fokus der Arbeitsgruppe Wirtschaftsinformatik steht, wurde die Entscheidung für Agile Advantage 2006 getroffen, um ein für sie typisches PLM-System zu untersuchen. Große Unternehmen haben häufig einen festen Kreis von Zulieferern und Abnehmern und geben diesen die zu verwendenden Systeme, so auch PLM-Systeme, vor, so dass die in Abschnitt gemachten Annahmen nicht zutreffen Agile Advantage 2006 Agile Advantage besteht aus mehreren Komponenten (siehe Abbildung 12), wobei die wichtigsten der Agile Advantage Windows Client, der Web Client und der Administrator Client sind. Sie stellen Front-Ends mit unterschiedlichen Funktionalitäten für die entsprechenden Nutzergruppen bereit. Der Agile Advantage ehub ist verantwortlich für die Verwaltung der Client Sessions und regelt die Kommunikation zwischen Teilnehmern und der AGILE-Datenbank. Agile Advantage ifs ist der File-Server zur Speicherung von Anhängen. Optional können der Agile ChangeCAST-Server zum Datenaustausch mit ERP-Systemen und Agile Advantage Web Server Component installiert werden. Optional stehen noch ein Agile Import-Client (zum Import von Produktdaten aus Text-, Microsoft Excel- und PDX-Dateien) und Agile express- Client (zur Erstellung von PDX-Dateien) zur Verfügung. Letztlich gibt es noch Agile ADK zur Anwendungsentwicklung und Agile Reports zur Erstellung von Verwaltungs- und Datenbankberichten [AADV 06, S. 1-2, ].

47 33 Abbildung 12: Komponenten von Agile Advantage 2006 [AADV 06, S. 1-4] Vorstellung und Beurteilung der Funktionalität Das PLM-System von Agile (Agile Advantage 2006) bietet einen Administrator-Client (Agile Administrator 2006) und einen Client für Benutzer (Agile Advantage Windows Client 2006) an. Der zusätzlich vorhandene Agile Advantage Web Client bietet ähnliche nicht identische Funktionalität wie der Windows-Client mit anderer Benutzeroberfläche innerhalb eines Internet-Browsers und wird hier nicht weiter betrachtet. Administrator-Client Der Administrator kann mit dem Administrator-Client ein sog. Customizing des Agile PLM-Systems durchführen. Es werden im Wesentlichen Einstellungen vorgenommen, welche das Verhalten und Aussehen der Benutzer-

48 34 Clients bestimmen. Die Oberfläche des Administrator-Clients gliedert sich in ein Menü, eine Toolbar, eine Statuszeile, eine Hauptfenster und ein Browserfenster (siehe Anhang B, Screenshot 15). Im Browser können verschiedene Elemente ausgewählt werden, während im Hauptfenster Eigenschaften dieser angezeigt werden. Sofern die Eigenschaften nicht deaktiviert sind, können vom Administrator Änderungen an ihnen vorgenommen werden. Der Administrator hat so unter anderem die Möglichkeit, neue Benutzer anzulegen (siehe Anhang B, Screenshot 16) und diese mit Rechten zu versehen, er kann neue Objekt- Klassen (z. B. eine Klasse für eine neue Art von Teilen oder eine Klasse für eine neue Art von Dokument, usw.) erzeugen, welche später von den Benutzern verwendet werden können und er kann Änderungsabläufe anlegen und verändern. Des Weiteren kann er das Erscheinungsbild und die Eingabefelder der Formulare anpassen, welche von den Benutzern zum Erzeugen und Verwalten von Objekten genutzt werden und festlegen, welche Attribute es gibt und ob diese sichtbar sein sollen. Der Administrator hat noch weitere Einflussmöglichkeiten (Organisationen, Lizenzen, Serververbindung, etc.), auf die hier nicht weiter eingegangen wird. Der Nutzer des Agile Advantage Windows Clients hat je nach Privilegien, die ihm vom Administrator zugeteilt wurden, verschiedene Möglichkeiten. Es ist also denkbar, dass nicht jeder Benutzer die im Folgenden vorgestellten Funktionalitäten nutzen kann. Aufbau der Benutzeroberfläche Das Fenster des betrachteten Clients besteht ebenfalls aus Toolbar, Menü und Statuszeile. Zusätzlich enthält es ein Dialogfenster Search, in dem hierarchisch einsortiert verschiedene Suchen nach Objekten vorgegeben, sowie die zu letzt besuchten Objekte aufgelistet sind (siehe Anhang B, Screenshot 17). Anlegen von Objekten (Artikel, Dokumente, Änderungsanträge, ) Über den Button New in der Toolbar können neue Objekte erzeugt werden. Diese Objekte können z. B. Teile, aber auch Änderungen oder Dokumente sein. Welche Objekte es gibt bzw. welche von einem bestimm-

49 35 ten Benutzer auch tatsächlich angelegt werden können, ist vom Administrator festgelegt. Je nach ausgewählter Kategorie öffnet sich zunächst ein Fenster zur Zuordnung einer Nummer für das Objekt. Die Nummer kann manuell vom Benutzer vergeben oder vom System erzeugt werden. Keine zwei Objekte können die gleiche Nummer besitzen. Anschließend öffnet sich ein Fenster mit i.d.r. mehreren Tabs, in welchen die Eigenschaften des Objekts beschrieben werden können (siehe Anhang B, Screenshot 18). Über die Objekte wird eine Historie angelegt, welche wichtige Ereignisse dokumentiert und über den Reiter History eines Objekts eingesehen werden kann. Jeder Benutzer kann sich eigene Suchen definieren bzw. der Administrator kann Standardsuchen festlegen. Auf diese Weise kann der Benutzer sich z. B. eine Liste aller bisher angelegten Teile einer bestimmten Produktlinie (z. B. LEGO -Produkt) anzeigen lassen (siehe Anhang B, Screenshot 21). Die Suchen können mehrere Suchkriterien verbinden, welche jeweils vielfältige Möglichkeiten bieten, so dass komplexe Anfragen möglich sind. Eventuell häufiger auszuführende Suchen können gespeichert werden, was ermöglicht, dass mit einem Mausklick eine Abfrage abläuft, welche dynamisch Listen von entsprechenden Objekten generiert. Innerhalb der Fallstudie wurde davon ausgegangen, dass ein Benutzer (User1) alle Einzelteile für das LEGO -Haus anlegt. Die Liste der zuletzt betrachteten Objekte (siehe Anhang B, Screenshot 19) gibt ihm einen Überblick über diese. Anlegen der Produktstruktur Im Anschluss kann ein anderer Benutzer (User2) die Baugruppen anlegen und über den Reiter BOM festlegen, welche Bauteile in seine Teile eingehen (siehe Anhang B, Screenshot 20). Über den Reiter Where Used kann ein Verwendungsnachweis abgerufen werden. Die Angabe, ob ein Teil in einer Stückliste nur optional zu verwenden ist, kann nur indirekt z. B. in einem Anmerkungsfeld geschehen. Daraus ist jedoch keine automatische Abfrage bei der Erstellung einer konkreten Stückliste generierbar.

50 36 Verwaltung von Dokumenten Den Teilen, welche angelegt wurden, können ähnlich wie im Eigner PLM 5.0, Dokumente zugeordnet werden, welche anschließend vom Agile Advantage 2006 verwaltet werden. Diese Dokumente können nach ihrer Zuordnung dann mittels Check-Out dem Benutzer zur Verfügung gestellt werden und so vor konkurrierenden Zugriffen geschützt werden (siehe Anhang B, Screenshot 22) und mittels Check-In wieder dem System übergeben werden. Workflowmanagement Zum Ändern des Status und Revisionsstandes eines Objektes werden Änderungen benutzt. Zunächst muss ein Objekt der Klasse Change angelegt werden, welches dann dem / den entsprechenden Objekt(en) zugeordnet werden kann (siehe Anhang B, Screenshot 23). Der Workflow einer Änderung wird auf dem Haupttab eingetragen. Neue Workflows können vom Administrator erstellt werden. Nachdem ein Change einem Objekt zugeordnet ist, kann dieses verschiedene Stati durchlaufen, wobei die Zustimmung von zugeordneten Personen ( Approver ) nötig sein kann. Die Approver sowie weitere Personen ( Observer ) können über von der Statusänderung in Kenntnis gesetzt werden. Die Approver können die Suche Changes that need my approval starten, so dass sie die entsprechenden Änderungen angezeigt bekommen (siehe Screenshot 24). Sie können dann der Änderung zustimmen (oder auch nicht). Die Observer können der Änderung zustimmen, müssen jedoch nicht. Der Workflow kann auch ohne ihre Zustimmung fortgesetzt werden. In jedem Zustand können verschiedene Rollen verschiedene Zugriffsrechte haben. Nachdem eine Änderung den vollständigen Workflow durchlaufen hat, ändert sich der Zustand des Elements, dem der Change zugeordnet wurde (siehe Screenshot 25). Ein Change hat einen Tab Affected Items, in dem alle betroffenen Objekte aufgelistet werden (siehe Screenshot 26). Dort kann mittels eines Buttons das Redlining des Objektes gestartet werden. Es erscheint ein neues Fenster mit drei Tabs: BOM Redline, Manufacturer Redline und Attachment Redline. Unter diesen Reitern können Veränderungen an den

51 37 entsprechenden Informationen vorgenommen werden, also z. B. die Stückliste verändert werden. Die gemachten Änderungen werden gekennzeichnet, als wären sie auf dem Papier mit einem roten Stift gemacht worden (siehe Screenshot 27). Auf diese Weise bleiben die Änderungen nachvollziehbar. Projekte und Kundenaufträge Projekte und Kundenaufträge sind keine Standardobjekte in Agile. Es ist aber möglich, dass der Administrator Klassen für diese Arten von Objekten anlegt. Über vom Administrator zugeordnete Attributfelder können die Projekte bzw. Aufträge dann vom Benutzer einem Teil zugeordnet werden. Jedoch enthalten diese Felder dann keinerlei semantische Bedeutung. Variantenmanagement Des Weiteren gibt es in Agile Advantage keine Möglichkeit, Varianten zu unterscheiden. Variantenteile müssen dann als mehrere Teile angelegt werden und dementsprechend viele verschiedene Stücklisten erzeugt werden. Agile bietet jedoch eine weitere PLM Lösung Agile e6 an, in der diese Funktionalität gegeben ist. Klassifizierung Klassifizierung über Sachmerkmalleisten wird ebenfalls nicht explizit unterstützt, jedoch können vom Administrator weitere, klassifizierende, Attribute angelegt werden. Agile bietet eine dreistufige Klassenhierarchie, so dass die Vererbung von Attributen möglich ist. Die Attribute auf allen Tabs außer der Seite drei sind für alle Subklassen einer Agileklasse gleich. Die Attribute auf der Titelseite sind fest vorgegeben und können lediglich umbenannt werden. Hingegen kann der Administrator auf Agileklassen-Ebene die Attribute der Seite zwei und den übrigen Tabs (außer Seite drei und Titelseite) ändern, ausblenden und festlegen. Individuelle Benutzerklassen bekommen ihre eigenen Attribute anschließend auf der Seite drei.

52 38 PDX-Export Mit Hilfe des Agile Clients Agile express 2006 Professional, aber auch aus dem oben beschriebenen Windows-Client können Produktdaten in PDX- Paketen gespeichert werden. Zu diesem Zweck wird ein Objekt gesucht und ausgewählt (siehe Screenshot 28) und im anschließenden Dialog bestimmt, welche Informationen und bis zu welcher Tiefe der Produktstruktur exportiert werden soll (siehe Screenshot 29). Anschließend ist es möglich, die exportierten Informationen, die jetzt im PDX-Paket gespeichert sind, mit Hilfe des express-clients zu betrachten (siehe Screenshot 30). Für weitere Informationen über das exportierte PDX-Paket und das PDX-Format siehe PDM-Funktion Agile Advantage 2006 Stücklisten erstellen Klassifizierung Workflows Versionierung Benutzerverwaltung Check-Out & Check-In Metadatenhaltung in einer Datenbank Dokumentenhaltung in einem geschütztem Bereich Erstellung von neutralen Datenformaten CSV, PDX, (PDF 17 ) Tabelle 2: Erfüllung der PDM-Funktionalitäten (siehe Abschnitt 2.4.1) durch Agile Advantage 2006 ( ) Architektur von Agile Advantage 2006 Agile Advantage 2006 ist ein Client-Server-System (siehe Abbildung 13). Es gibt verschiedenartige Server: File-Server (Agile Advantage ifs), Application-Server (Agile Advantage ehub), Web-Server (Agile Advantage Web-Server) und ERP-Datenaustausch-Server (Agile Advantage Chan- 17 Anmerkung: Es gibt keinen direkten PDF-Export in Agile Advantage Über die Druckfunktion kann jedoch mittels PDF-Drucker eine PDF-Datei erstellt werden.

53 39 gecast). Die Clients sind der Administrator- und der Windows-Client, der Web-Client, sowie der Import-Client (Agile Advantage Import) und der Export-Client (Agile Advantage express) [AADV 06, S. 1-2]. Abbildung 13: Client-Server-Architektur von Agile Advantage 2006 Die Datenbank ist für Agile Advantage 2006 immer eine ORACLE- Datenbank. Das Datenbankschema ist fest vorgegeben und besteht aus 136 Tabellen. 18 Durch Einstellungen im Administrator-Client kann lediglich verändert werden, welche Benennung die einzelnen Attribute in der Client- Ansicht erhalten (nicht die Benennung in der Datenbank) und ob die Attribute dem Benutzer angezeigt werden oder nicht. Das Vorhandensein und die Typen der Attribute können jedoch nicht beeinflusst werden. Die Objekte in Agile Advantage 2006, die von den Clients erzeugt werden können, sind in einer dreistufigen Klassenhierarchie angeordnet (siehe Tabelle 3). Vom Administrator können nur auf der untersten Ebene neue Klassen angelegt werden. Die Titelseite (der erste Tab) eines Objektes ist für alle Objekte, die zu einer Superklasse gehören also z. B. für alle 18 Anmerkung: Auf der beigelegten CD sind das Modell der relationalen DB, das mit dem DBDesigner von fabforce.net erstellt wurde, und weitere Informationen eingefügt

54 40 Changes gleich. Die Page two (und die übrigen Tabs: History, Attachments usw.) ist wiederum für alle Objekte derselben Agile Klasse identisch. Für die individuellen Klassen steht eine Page three zur Verfügung, auf der Attribute angelegt werden können, welche nur Objekte der untersten Klassenebene besitzen. Die Attribute auf jedem Reiter können jeweils angezeigt werden oder nicht. Nur auf den Titelseiten der verschiedenen Klassen ist die Sichtbarkeit der Attribute nicht anpassbar. Superclass Agile class Installed userdefined subclass Change Change Orders ECO Change Requests ECR Deviations Deviation Manufacturer Orders MCO Quality Change Requests CAR Stop Ships Stop Ship Product Service Problem Reports Problem Report Request Issues Issue Item Parts Part Documentation Document --- Suppliers Supplier --- Customers Customer --- Packages Package --- Manufacturer Parts Manufacturer Part --- Manufacturers Manufacturer Tabelle 3: Vorgegebene Klassenstruktur in Agile Advantage 2006 [AADM 06, S. 5-4] Agile Advantage 2006 wurde im Wesentlichen für KMU entwickelt, mit dem Ziel, dass die Anpassung an das Unternehmen möglichst einfach und schnell durchführbar ist. Daraus erklärt sich das starre Datenbankschema. Auch die Entscheidung, kein Variantenmanagement zu unterstützen, wird damit begründet.

55 41 5 Architektur und Austauschformate für die kollaborative Produktentwicklung Die kollaborative Produktentwicklung mit Hilfe von PDM-Systemen kann prinzipiell entweder auf der Client-Server-Architektur oder auf der Peer-To- Peer-Architektur basierend realisiert werden (5.1). In jedem Fall ist der Austausch von Produktdaten über ein Standardformat notwendig, damit für jeden Teilnehmer alle syntaktischen und semantischen Informationen zugänglich sind. In diesem Kapitel werden einige mögliche Standardformate (5.2) und Standardzugriffsmöglichkeiten (5.2.6) auf Produktdaten vorgestellt, die den Austausch von Informationen an den Schnittstellen zwischen PDM-Systemen ermöglichen sollen. 5.1 Netzarchitekturen Der grundsätzliche Aufbau eines Netzwerks kann zwei unterschiedlichen Architekturen folgen: Client-Server-Architektur (siehe 5.1.1) oder Peer-To- Peer-Architektur (siehe 5.1.2). 19 Abhängig von der gewählten Architektur werden die Aufgaben der einzelnen Netzteilnehmer unterschiedlich definiert, verteilt und gebündelt. Die Entscheidung für eine bestimmte Architektur hat weitreichenden Einfluss auf die Leistungsfähigkeit und Funktionalität des Netzwerks und muss daher gut durchdacht werden. Die Standard-Architektur im PDM-Umfeld ist die Client-Server-Architektur [ARNO 05, S. 164], was auch Abschnitt 4.2 bestätigt wurde. Das Projekt Product Collaboration Platform (siehe Abschnitt 6.1.3) beschäftigt sich mit dem Einsatz der P2P-Architekur als Alternative. Aus diesem Grund werden die beiden Architekturen in diesem Kapitel kurz vorgestellt. 19 Anmerkung: Eine Mainframe-Architektur wird hier als veraltet und für das PDM- Problem nicht anwendbar angesehen und deswegen von der Betrachtung ausgeschlossen

56 42 Trotz der eigentlich gegensätzlichen Definition beider Architekturen ist in der Realität nicht immer trennscharf festzustellen, welche Architektur einem Netzwerk tatsächlich zu Grunde liegt. Es sind durchaus Mischformen denkbar. So wurde z. B. im File-Sharing-System Gnutella festgestellt, dass 20 % der Peers 98 % der Dateien zur Verfügung stellten. Ein Großteil der Peers hat also ausschließlich Client-Funktionalitäten übernommen, während nur wenige als Server dienten [SAAK 05, S. 760]. Des Weiteren gibt es so genannte Super-Peer-Architekturen (siehe Abbildung 14), wobei einige Peers die Super-Peers untereinander in einem P2P-Netz agieren, jedoch jeweils die Rolle als Server für eine Menge von Clients übernehmen [SAAK 05, S. 761]. Abbildung 14: Super-Peer-Netzwerk [SAAK 05, S. 761] Client-Server-Architektur Die Client-Server-Architektur ist der Standardansatz in Netzwerken. Dabei fungiert ein Teilnehmer als Anbieter von Diensten (Server), welche von anderen Teilnehmern (Clients) angefordert werden. Die Kommunikation findet dabei nur zwischen Client und Server statt [VERM 04, S. 5-6]. Der Client sendet eine Anforderung über das Netz an

57 43 den Server, welche von diesem bearbeitet wird. Der Server schickt dann seine Antwort wiederum über das Netz an den Client (siehe Abbildung 15). Abbildung 15: Das Client/Server-Modell enthält Anforderungen und Antworten [TANE 03, S. 19] Ein Server kann im Regelfall eine Vielzahl von Clients bedienen. Client und Server können sich sowohl innerhalb eines Gebäudes befinden als auch räumlich weit voneinander entfernt aufgestellt sein [TANE 03, S ]. In Abhängigkeit von der Leistungsfähigkeit der Clients gibt es fünf Möglichkeiten, die Darstellungs-, Anwendungslogik- und Datenmanagementaufgaben auf Client und Server zu verteilen (siehe Abbildung 16). Die Datenmanagementschicht übernimmt die Speicherung und Verwaltung der zu verarbeitenden Daten, die Anwendungsschicht verarbeitet die Daten und die Darstellungsschicht ermöglicht die Visualisierung für und die Interaktion mit dem Benutzer. Die ideale Aufteilung ist von der Aufgabe, der Leistungsfähigkeit der einzelnen Komponenten und der Anzahl der Benutzer abhängig [LAUD 06, S ].

58 44 Abbildung 16: Möglichkeiten zur Aufteilung der Aufgaben Darstellung, Anwendungslogik und Datenmanagement auf Client und Server [LAUD 06, S. 291] Wie in erwähnt, ist die Client-Server-Architektur der Standard für PDM-Systeme [ARNO 05, S. 164]. Der Vorteil der Client-Server-Architektur ist ihre Einfachheit und leichte da zentrale Wartbarkeit. Es kann von zentraler Stelle eine Zugriffspolitik entwickelt werden, so dass Sicherheitsaspekte überschaubarer zu verwalten sind. Nachteilig kann gewertet werden, dass häufig die Client-Rechner nicht ausgelastet werden, da in der heutigen Zeit auch auf diesen relativ viel Leistung bereitsteht [VERM 04, S. 5-6]. Andererseits kann es zu einer Überlastung des Servers kommen. Des Weiteren besteht eine hohe Abhängigkeit vom Server. Fällt dieser aus, steht keine Funktionalität mehr zur Verfügung ( Single Point of Failure ) Peer-To-Peer-Architektur Der Peer-To-Peer-Ansatz ist eine Alternative zum Client-Server-Ansatz. In P2P-Systemen gibt es keine zentrale Koordination und keine zentrale Datenbasis. Jeder Netzknoten wird als Peer bezeichnet und agiert sowohl als Client als auch als Server. Keiner dieser Peers hat eine globale Sicht auf das gesamte System und jeder Peer agiert autonom. Das Verhalten 20 Vgl

59 45 des Gesamtsystems entsteht aus den einzelnen Interaktionen zwischen den Peers. Ein P2P-System zeichnet sich durch seine Flexibilität und Fehlertoleranz aus, bezahlt dieses jedoch durch hohe Komplexität [DUST 03, S ]. Abbildung 17: P2P-Netz Gründe für den Einsatz von Peer-To-Peer-Systemen Die Entscheidung, ob ein P2P-System eingesetzt werden soll, muss begründet sein und darf nicht unüberlegt getroffen werden. Ein Grund für den Einsatz von P2P-Systemen kann z. B. sein, dass ein Client-Server-Ansatz im Anwendungsfall nicht gut skaliert. Ein weiterer Grund kann sein, dass der Anwendungsfall inhärent P2P ist also durch die Verteilung der Ressourcen zwangsweise oder vernunftgemäß gegeben bzw. das System direkt auf den Ressourcen der Peers aufbaut. Ein zusätzlicher Vorteil von P2P-Systemen ist, dass sich die Peers jederzeit an- und abmelden können und sich das System selbst organisiert [DUST 03, S ]. Dieses ist insbesondere beim Einsatz von mobilen Geräten von Vorteil. Des Weiteren fällt in einem P2P-Netz die Abhängigkeit von der Verfügbarkeit eines Servers weg. Außerdem wird die zur Verfügung stehende Netzbandbreite effektiver weil symmetrischer genutzt [CHTC 02, S ].

60 Unterscheidung von Peer-To-Peer-Architekturen P2P-Systeme können sich bezüglich Strukturiertheit, Hierarchiegrad und Kopplungsgrad unterscheiden. Dieses führt dazu, dass es vielfältige P2P- Architekturen z. B. Napster, Gnutella, Chord, JXTA etc. gibt. Ist ein P2P-System strukturiert, speichern Peers lokal Wissen über Ressourcen anderer Peers. Die Grade der hierarchischen Struktur eines P2P-Systems sind typischerweise: zentral (es gibt einen globalen Index an zentralisierter Stelle), dezentral (es gibt keinen zentralen Index) oder hierarchisch (es gibt normale Peers und Super-Peers, die den globalen Index verwalten). In lose gekoppelten P2P-Systemen können die Peers ihre logische Peer-Adresse und damit ihre Rolle im System ändern. In stark gekoppelten Systemen ist die ID eines Peers nach seinem Eintritt festgelegt. In diesem Fall ist es nicht möglich, dass sich Gruppen von Peers zu einem System zusammenschließen. Nur einzelne Peers können in ein Netz eintreten [DUST 03, S ]. 5.2 Austauschformate Für den Austausch von Produktdaten gibt es mehrere Standardformate. Von der Automobilindustrie wird eher STEP, von der Elektronikindustrie eher PDX genutzt. PDML wird in der Luftfahrt- und Verteidigungsindustrie eingesetzt [EIGN 03, S. 9]. Des Weiteren wird JT häufig als Standardaustauschformat genannt [UGS 06, S. 13]. JT sieht sich in der Automobilbranche und Luftfahrtindustrie verbreitet. 21 PDTnet ist ein Projekt der ProSTEP AG und anderen um STEP-Daten webfähig zu machen. Die Daten werden dafür in eine XML-Datei übertragen. PDML ist eine Anwendung von STEP und benutzt EXPRESS als Beschreibungssprache. Es liefert eine direkte Abbildung von EXPRESS nach XML

61 47 PDTnet und PDML basieren also auf ähnlichen Vorgehensweisen. PDX wurde von IPC Association Connecting Electronics Industries und NEMI erstellt und von ANSI bestätigt. JT wurde von EAI entwickelt, welche im Jahre 2000 von UGS akquiriert wurden. Die Lizenzrechte von JT liegen also bei UGS. Im Folgenden werden die Formate kurz vorgestellt und anschließend ein Beispiel für eine mögliche Austauschdatei angegeben, so wie sie aussehen könnte, wenn sie während der in Kapitel 4.1 vorgestellten Fallstudie erzeugt worden wäre. Anschließend werden die Formate bezüglich der Eignung in der kollaborativen Produktentwicklung bewertet, insbesondere in Hinsicht auf die Verwendung in der Product Collaboration Platform, welche derzeit am Institut für Informatik an der Technischen Universität Clausthal entwickelt und in Abschnitt kurz vorgestellt wird. Die PDM Enabler sind von der OMG spezifiziert. Sie sind eine CORBAbasierte Schnittstelle auf PDM-Systeme und kein Austauschformat in dem Sinne der anderen vorgestellten Formate in diesem Kapitel STEP Die ISO-Norm International Automation Systems and Integration Product Data Representation and Exchange ist unter dem Namen Standard for the Exchange of Product Model Data kurz STEP bekannt [LUEH 96, S. 6] Der STEP-Standard Die STEP-Norm wurde erschaffen, um vollständig alle Produktdaten abzubilden. Die Norm ermöglicht sowohl den Produktdatenaustausch per Datei, als auch Produktdatenbanken mit normierter Schnittstelle zum Datenbankzugriff [LUEH 96, S. 6-7].

62 48 Die Produktdaten werden, wie in Abbildung 18 zu sehen, in Basismodelle und Anwendungsprotokolle unterteilt. Die allgemeinen Basismodelle sind anwendungsunabhängig und bilden die Grundlage für die Produktbeschreibung. Auf diese bauen die anwendungsabhängigen Basismodelle auf. Durch sie werden die allgemeinen Konstrukte erweitert und spezialisiert, um sie für viele Anwendungen verwendbar zu machen. Auf den Basismodellen bauen wiederum die Anwendungsprotokolle auf. Sie beschreiben benötigte Teile der Basismodelle und erweitern diese um anwendungsspezifische Daten. Die Konformitätstests haben die Aufgabe, die STEP-unterstützende Software zu überprüfen und zu validieren. Die Beschreibungsmethoden geben einen Überblick über die STEP-Norm und die zur Produktdatenbeschreibung verwendeten formalen Sprachen. In den Implementierungsmethoden werden die verwendeten Techniken für den Produktdatenaustausch beschrieben [LUEH 96, S. 7-11]. Abbildung 18: Prinzipieller Aufbau von STEP [LUEH 96, S. 7] EXPRESS Zur Spezifikation von Produktdaten wird die formale Sprache EXPRESS benutzt. Sie wird in Teil 11 der STEP-Norm definiert und gehört zu den Beschreibungsmethoden. EXPRESS ermöglicht die Deklaration von Datentypen (Konstanten, einfache, generalisierte und aggregierte Datentypen, Aufzählungs- und

63 49 Auswahltypen, Entities). Die Deklaration erfolgt wie in Abbildung 19 schematisch dargestellt. Des Weiteren wird die Erstellung von Prozeduren, Funktionen und globalen Regeln unterstützt [LUEH 96, S ]. Abbildung 19: Typdeklarationen in EXPRESS: 1) Konstantendeklaration; 2) einfache Typdeklaration; 3) Aggregierter Datentyp; 4) Aufzählungstyp; 5) Auswahltyp [LUEH 96, S ] 22 In EXPRESS werden die Objekttypen als Entities bezeichnet. Eine Entity besitzt Attribute und eine eindeutige Objektidentität, so dass mehrere Entityinstanzen mit identischen Attributwerten existieren können. Attribute einer Entity können als Typangabe wiederum eine Entity besitzen. So können Beziehungen zwischen den Entities erstellt werden. Durch den Zusatz OPTIONAL bzw. das Anlegen einer Menge (SET) können die Kardinalitäten der Beziehung festgelegt werden. Mit Hilfe der INVERSE- Klausel kann die Beziehung zwischen zwei Entities weiter spezifiziert werden, d. h. es können die Kardinalitäten der inversen Beziehung 22 Anmerkung: <xyz> bedeutet im Folgenden, dass xyz optional eingefügt werden kann oder nicht (nach einer durch getrennten Aufzählung, kann der Teil in <> u. U. zwingend erforderlich sein, abhängig vom vorher eingesetzten Term); a b soll bedeuten, dass entweder a oder b eingefügt werden kann; heißt, es können noch beliebige weitere Einträge analog zum vorherigen erfolgen

64 50 festgelegt werden. Mit Hilfe des "supertype-constraint"- und des "SUBTYPE OF"-Ausdrucks können Vererbungshierarchien zwischen den Entities aufgebaut werden. Der prinzipielle Aufbau einer Entity-Deklaration ist in Abbildung 20 zu sehen [LUEH 96, S ]. Abbildung 20: Entity-Deklaration in EXPRESS [LUEH 96, S ] 23 In EXPRESS wird zwischen Funktionen, die einen Rückgabewert generieren und Prozeduren ohne Rückgabewert unterschieden. Prozeduren können jedoch im Gegensatz zu Funktionen die ihnen übergebenen Parameter verändern. Zur Erstellung von Funktionen siehe Abbildung Anmerkung: supertype_constraint: <ABSTRACT> SUPERTYPE OF (supertype_expression) supertype_expression: entity_ref one_of supertype_expression <AND entity_ref one_of supertype_expression <ANDOR entity_ref one_of supertype_expression <AND entity_ref one_of supertype_expression >>> one_of: ONEOF (supertype_expression <, supertype_expression, >); inverse_clause: INVERSE attribute_decl : < SET BAG [grenze1:grenze2] OF > entity_ref FOR attribute_ref;

65 51 Abbildung 21: Funktion in EXPRESS [LUEH 96, S ] Um die Ausprägungen von Entities über eine Bedingung zu verknüpfen, gibt es in EXPRESS globale Regeln (siehe Abbildung 22). Abbildung 22: Globale Regel in EXPRESS [LUEH 96, S ] Weitere Konstrukte in EXPRESS sind Schemata, ausführbare Anweisungen und eingebaute Funktionen. Auf diese soll jedoch an dieser Stelle nicht eingegangen werden [LUEH 96, S ]. EXPRESS ist keine vollständige Programmiersprache, da es keine eigene Speicherverwaltung, keine Ein- und Ausgabeoperationen und anderes zur Verfügung stellt. Es gibt vielerlei Vorschläge zur Ergänzung von EX- PRESS um weitere Konstrukte bzw. Weiterentwicklung zu einer Programmiersprache [LUEH 96, S. 12, 31]. EXPRESS-G liefert die Möglichkeit EXPRESS-Schemata graphisch darzustellen, kann aber auch unabhängig von EXPRESS eingesetzt werden. EXPRESS-G soll hier nicht weiter erläutert werden [LUEH 96, S ].

66 52 Überführung von EXPRESS-Schemata in Datenbanken Aus einer Schema-Deklaration in EXPRESS lassen sich direkt relationale Datenbanken bzw. objektorientierte Datenbanken ableiten [LUEH 96, S ]. Für die Übersetzung gibt es häufig mehrere Möglichkeiten, welche verschiedene Vor- und Nachteile aufweisen. Zur idealen Transformation muss in vielen Fällen manuell über die beste Übersetzungsregel entschieden werden. Einfache Entities ohne Beziehungen zu anderen Entities sind wie in Abbildung 23 direkt in Relationen zu übersetzen. Abbildung 23: Deklaration einer Entity in EXPRESS (1) und Erzeugen der entsprechenden Relation in SQL (2) [LUEH 96, S ] Tabelle 4 zeigt die Zuordnung von SQL2-Datentypen zu einfachen EXPRESS-Datentypen. Die Datentypen in EXPRESS entsprechen nicht genau den Datentypen von SQL 24, da EXPRESS z. B. von unbeschränkten Wertebereichen und Genauigkeiten ausgeht [LUEH 96, S ]. 24 Anmerkung: In dieser Arbeit wird von SQL2 ausgegangen

67 53 EXPRESS-Datentyp INTEGER REAL und REAL (n) und NUMBER STRING BINARY BOOLEAN und LOGICAL SQL2-Datentyp integer decimal (n) oder float char oder varchar oder text bit oder char oder byte integer Tabelle 4: Abbildung von einfachen EXPRESS-Datentypen nach SQL2 [LUEH 96, S. 65] Um die in EXPRESS angenommene Objektidentität herzustellen und einen Primärschlüssel zu definieren, muss in den Relationen jeweils ein zusätzliches Attribut eingefügt werden. Zur Abbildung von Aufzählungstypen und Auswahltypen aus EXPRESS werden jeweils eine Relation für Aufzählungstypen und eine für Auswahltypen erzeugt [LUEH 96, S ]. Bei der Überführung von aggregierten Datentypen aus EXPRESS in relationale Datenbanken muss für jedes aggregierte Attribut eine Relation angelegt werden [LUEH 96, S ]. Bei der Erzeugung von Arrays und Matrizen, sowie Listen, Mengen und Multimengen wird vorgegangen, wie in Abbildung 24 gezeigt wird [LUEH 96, S ].

68 54 Abbildung 24: Übersetzung von aggregierten Datentypen aus EXPRESS in relationale Datenbanken: 1) Entity mit allen aggregierten Datentypen; 2) Erzeugen der Relation für die Entity aus 1; 3) Erzeugen von Relationen für Matrizen; 4) Erzeugen von Relationen für Listen; 5) Erzeugen von Relationen für Mengen; 6) Erzeugen von Relationen für Multimengen [LUEH 96, S ] Abgeleitete Attribute können nur benutzt werden, falls das DBS Prozeduren und Trigger unterstützt [LUEH 96, S ].

69 55 Für die Umsetzung von Beziehungen zwischen Entities werden 1:1-, 1:nund m:n-beziehungen unterschieden. Für die Übersetzung von 1:1- Beziehungen und 1:n-Beziehungen gibt es mehrere Möglichkeiten. Letztlich können beide wie m:n-beziehungen übersetzt werden, wenn dieses auch nicht in jedem Fall ideal ist. Bei der Übersetzung von m:n-beziehungen in relationale Datenbanken werden drei Relationen erzeugt. Zwei Relationen beschreiben die Entities selbst, während die dritte die Beziehung widerspiegelt. Bei der Überprüfung von Kardinalitäten können CHECK-Klauseln und Datenbankprozeduren behilflich sein. Mögliche Existenzabhängigkeiten können mit den Zusätzen ON DELETE CASCADE bzw. ON DELETE SET NULL angegeben werden. Für die Darstellung von Vererbungshierarchien in relationalen Datenbanken werden Relationen für jeden Supertyp und jeden Subtypen erstellt. Dabei ist der Primärschlüssel zugleich Fremdschlüssel auf die Relation der Super- bzw. Subtyprelation. Zusätzlich wird eine Relation für die Darstellung der Generalisierung erzeugt. Falls von der Datenbank unterstützt, können mittels CHECK-Klauseln Regeln für erlaubte bzw. verbotene Disjunktionen der Subtypen festgelegt werden. Dieser Ansatz erlaubt unter anderem auch Mehrfachvererbung und überlappende Subtypen [LUEH 96, S ]. Einschränkungen bei der Übersetzung von EXPRESS in relationale Datenbanken zeigen sich unter anderem bei der Transformation von UNIQUE-Klauseln, welche in SQL nicht auf abgeleitete und aggregierte Attribute angewandt werden kann. WHERE -Klauseln in EXPRESS können mit CHECK-Klauseln in SQL nachgebildet werden. Globale Regeln aus EXPRESS können je nach Umfang des DBS mit relationsübergreifenden Integritätsbedingungen bzw. Triggern und Datenbankprozeduren übersetzt werden [LUEH 96, S ].

70 56 Um auf STEP-Datenhaltungssysteme einheitlich zugreifen zu können, wurde die Zugriffschnittstelle SDAI entwickelt. SDAI ist Teil 22 der STEP- Norm [LUEH 96, S ]. Dadurch sind Möglichkeiten gegeben, die wichtigen Daten aus einem PDMS entweder als vollständige (STEP-)Datei zu entnehmen oder in einer Datenbank zu hinterlegen Das STEP PDM-Schema Da PDM-relevante Daten anwendungsübergreifend und somit in verschiedenen, nicht aufeinander abgestimmten, Anwendungsprotokollen beschrieben sind, wurde das PDM-Schema entwickelt. So werden alle PDMrelevanten Daten aus den verschiedenen Anwendungsprotokollen in Einklang gebracht. 25 Das STEP PDM-Schema beinhaltet alle für PDM wichtigen Daten aus den STEP-Anwendungsdatenmodellen AP 203, AP 212, AP 214 und AP 232 (vgl. Abbildung 25) [CHRI 01, S. 2]. 26 Abbildung 25: Umfang und Inhalt des STEP PDM-Schemas [UNGE 02, S. 5] 25 Vgl Anmerkung : Das PDM-Schema in EXPRESS und EXPRESS-G findet sich im Internet ( Stand : ) und auf der beigelegten CD; des Weiteren ist aus [UNGE 02, S. 5] an Beispielen der Aufbau einer Datei im STEP-Format zu entnehmen

71 57 Jedes "Produkt" im PDM-Schema kann entweder ein Teil oder Dokument sein [UNGE 02, S. viii]. Das PDM-Schema deckt nicht alle Funktionalitäten ab, die ein PDMS benötigt. Unter anderem können jedoch Teile und Dokumente identifiziert, klassifiziert und versioniert werden. Des Weiteren können z. B. Strukturen abgebildet und Eigenschaften beschrieben werden. Damit werden zumindest die wichtigsten PDM-Funktionen unterstützt [UNGE 02, S. 5] Verwendungsmöglichkeit in der Fallstudie und der kollaborativen Produktentwicklung Insbesondere das STEP PDM-Schema aus dem vorigen Abschnitt beschreibt ein ausführliches Produktmodell, dass für die Beschreibung der Daten von PDM-Systemen konzipiert ist. Abbildung 26 zeigt einen Ausschnitt aus einer STEP-Datei, wie sie während der Durchführung der Fallstudie aus Kapitel 4 entstanden sein könnte.

72 58 Abbildung 26: Ausschnitt aus einem STEP-File, das ein Teilmodell des LEGO -Hauses beschreibt 27 Einige (PDTnet, PDML, PDM Enabler) der später in diesem Kapitel beschriebenen Austauschformate benutzen das Datenmodell von STEP (PDM-Schema und/oder AP 214 und andere) und bringen es in eine portablere Form XML. STEP hat dadurch, dass es in einer internationalen Norm standardisiert ist, den Vorteil, dass das Datenmodell einheitlich gebraucht wird und eine recht große Verbreitung gefunden hat. Diese Verbreitung findet sich allerdings vor allem in der Automobilindustrie [EIGN 03, S. 9]. Die weite Verbreitung bringt mit sich, dass es schon eine Zahl von PDM-Systemen gibt, die mittels eines STEP Pre- und Postpro- 27 Anmerkung: Die vollständige STEP-Datei ist auf der beiliegenden CD zu finden

73 59 zessors in der Lage sind, STEP-Dateien zu erzeugen und zu importieren [CHRI 01, 1-3]. Des Weiteren werden die geometrischen Dateien aus CAD-Systemen häufig in STEP exportiert, so dass ein einheitliches Format für die geometrischen und die übrigen beschreibenden Informationen aus PDM-Systemen vorliegt. STEP hat als Format jedoch den Nachteil, dass es ohne einen entsprechenden Viewer oder Importprozessoren nicht lesbar ist. Verschiedene P2P-Systeme sind jeweils auf eine spezielle Art von Ressourcen spezialisiert und können nur solche Ressourcen verwalten und suchen. Das RMF von der Siemens AG (beschrieben in Abschnitt 6.1.3) kann z. B. ausschließlich XML-Dateien verwalten. Es gibt kein P2P- Framework, das in der Lage ist, direkt mit STEP-Dateien zu arbeiten. Wie in den folgenden Abschnitten zu sehen sein wird, ist es jedoch möglich, ein STEP-Schema in ein XML-Schema zu übersetzen und so das Datenmodell von STEP für die Kollaboration in P2P-Umgebungen (insbesondere solche, die auf dem RMF basieren) nutzbar zu machen. In der DTS ISO wird eine XML-Repräsentation von EXPRESS-Beschreibungen vorgeschlagen. 28 Wie in diesem Kapitel beschrieben, können STEP-Daten in eine relationale Datenbank überführt werden. Erste Ansätze zur Verwaltung relationaler Daten in P2P-Netzen mit entsprechenden Verteilungs- und Anfrageoperationen wurden vorgestellt. In solchen Netzen können jedoch keine Garantien für die Existenz und Integrität von Daten oder der Vollständigkeit von Anfrageergebnissen gemacht werden. Alternativ gibt es Ansätze für schemabasierte P2P-Systeme, auch Peer Data Management, bei denen jedoch mit langen Laufzeiten und semantischen Verlusten zu rechnen ist [SAAK 05, S ]. Sollte die Verwaltung von relationalen Daten in P2P-Systemen in Zukunft möglich werden, bieten sich dadurch erhebliche Vorteile für die Kollaboration gegenüber dem Austausch von Dateien, da der Zugriff direkt auf den Daten stattfinden kann, ohne das zuvor ein festes Paket von Produktdaten zum Austausch exportiert und bereitgestellt werden muss. Dadurch sinkt der Anteil von unnötig übertragenen 28 Vgl

74 60 Daten ( geringere Übertragungszeiten), unnötig vielen vorgehaltenen Dateien im Austauschformat ( geringerer Zeit-, Prozessor- und Speicheraufwand) und die Granularität des Datenzugriffs wird niedriger ( weniger vor konkurrierendem Zugriff zu schützende Daten) PDTnet PDTnet war ein Projekt führender Automobilhersteller, der PROSTEP AG und weiteren Unternehmen, um den Austausch von Produktdaten zu erleichtern [WEND 02, S. 13] Zielsetzung und Aufbau Zwei Szenarien wurden im PDTnet Projekt betrachtet. Das erste Szenario beschäftigt sich mit dem Datenaustausch zwischen OEM und Lieferant (siehe Abbildung 27) mit verschiedenen PDM- Systemen. Es werden PDM- und CAx-Daten zum Austausch ausgewählt. Mittels Datenaustausch-Tool werden die Daten versendet und beim Empfänger wieder in PDM- und CAx-Daten aufgeteilt. Basis für den physischen Dateiaustausch ist ISO STEP AP 214 [PROS 03c, S. 5]. Abbildung 27: Szenario "Datenaustausch" im Projekt PDTnet [PROS 03c, S. 5] Das zweite Szenario beschäftigt sich mit der Web-Integration von PDM (Abbildung 28, rote Verbindungslinien). Zwischen Entwicklungspartnern sollen web-basiert Produktdaten ausgetauscht werden. Die Übertragung

75 61 basiert auf dem PDTnet ISO STEP AP 214/XML Schema (im Folgenden kurz PDTnet-Schema). Ein Prototyp eines Web-Clients ist verfügbar. Beide Vorgehensweisen, web-basierter Datenaustausch und asynchroner Datenaustausch mittels OFTP und ENGDAT, sind möglich [PROS 03c, S. 6]. Abbildung 28: Szenario Web-basierter Austausch von PDM-Daten im Projekt PDTnet [PROS 03c, S. 6] Das PDTnet-Schema ist von der ISO AP 214 CC6 29 abgeleitet. Es verbindet die Produktdatenbeschreibung des STEP-Datenmodells mit der Syntax von XML, so dass ein Onlinezugriff auf die Daten möglich wird [WEND 02, S. 14]. 29 Anmerkung: Die Konformitätsklasse (CC) 6 der AP 214 enthält Produktdaten ohne geometrische Repräsentationen, nähere Informationen unter

76 62 Von der AP 214 wurde ein PDTnet EXPRESS Schema abgeleitet und für XML optimiert. Dieses Schema wurde dann in ein XML-Schema abgebildet [PROS 03a, S. 5]. Abbildung 29 zeigt, wie eine EXPRESS-Entity in einen Typen ( complextype ) im XML-Schema überführt werden kann und wie eine XML-Instanz beispielhaft aussehen könnte. Abbildung 29: Prinzip der Übersetzung aus EXPRESS in ein XML-Schema und Beispiel einer möglichen XML-Instanzierung [PROS 03a, S ] Bei der Abbildung aus dem STEP AP 214 werden einige Veränderungen und Vereinfachungen am resultierenden XML-Schema vorgenommen [PROS 03b, S ]. Die Abbildung 30 zeigt eine graphische Repräsentation des resultierenden XML-Schemas Anmerkung: Beide Formen des Schemas (XML-Schema und EXPRESS-Schema) sind unter verfügbar, sowie auf der beiliegenden CD zu finden

77 63 Abbildung 30: Graphische Darstellung des PDTnet-Schemas in XML Anmerkung: Erstellt mit Altova XMLSpy 2006

78 Verwendungsmöglichkeit in der Fallstudie und der kollaborativen Produktentwicklung Im PDTnet Projekt werden Szenarien zum Austausch von Produktdaten beschrieben. Bei der Entwicklung eines Systems zur kollaborativen Produktentwicklung sollten die beiden Szenarien zumindest berücksichtigt werden und ggf. Anwendung finden. Die Umsetzung eines Anwendungsprotokolls der ISO Norm STEP, das in EXPRESS beschrieben ist, in XML, ist ein grundsätzlich guter Weg, den Austausch von Produktdaten web-basiert zu gestalten. In dem Projekt wird damit die Grundlage für den Austausch von Produktdaten in einer XMLbasierten P2P-Umgebung wie dem RMF geschaffen, indem die Abbildung von EXPRESS nach XML beschrieben wird. Der allgemeine Nachteil des PDTnet-XML-Schemas besteht darin, dass es auf dem Anwendungsprotokoll 214 basiert, welches seine Ausrichtung eindeutig auf die Automobilindustrie hat (was leicht durch die Projektteilnehmer aus der Automobilindustrie zu erklären ist) und nicht allgemein gehalten ist. Auch wenn viele grundsätzlich in der Produktentwicklung nötige Elemente mittels des PDTnet-Schemas beschreibbar sind, so ist doch mit dem Fehlen bzw. Vorhandensein von in anderen Branchen (un-) wesentlichen Elementen zu rechnen oder mit grundsätzlichem Unverständnis bzw. Widerstand anderer Industriezweige. Für die allgemeine Verbreitung ist die Nutzung des STEP-PDM-Schemas als Grundlage zu empfehlen, da es eine Untermenge der AP 214 (und anderen Anwendungsprotokollen) darstellt und ausdrücklich für den Austausch von Daten aus PDM-Systemen konzipiert wurde. Die grundsätzliche Überführung von EXPRESS nach XML, sowie die Vereinfachung oder Veränderung einiger Aspekte bleibt jedoch prinzipiell unangetastet. Die folgende Abbildung (Abbildung 31) zeigt einen Ausschnitt aus einer XML-Datei nach dem PDTnet-Schema, wie sie bei der Durchführung der Fallstudie aus Abschnitt 4.1 entstanden sein könnte.

79 65 Abbildung 31: Ausschnitt einer XML-Datei nach dem PDTnet-Schema, die Teile der Produktdaten des LEGO -Hauses enthält PDML PDML verfolgt eine ähnliche Strategie wie PDTnet. Ein STEP EXPRESS Schema wird als Grundlage benutzt und in XML übersetzt. PDML ist 32 Anmerkung: Die XML-Datei ist auf der beiliegenden CD zu finden

80 66 jedoch älter als PDTnet und benutzt aus diesem Grund DTDs statt XML- Schemata. Des Weiteren werden alle Datenmodelle der Teilnehmer in eine DTD überführt, sowie ein integriertes, neutrales Gesamtmodell erstellt. Der Datenaustausch findet auf Teilmodell-Ebene und nicht auf Gesamtmodell-Ebene statt Zielsetzung und Aufbau PDML ist eine Lösung zum Produktdatenaustausch, die bewährte Techniken übernimmt und zusammenführt. Diese Techniken sind STEP als Produktdatenaustauschtechnologie (PDML übernimmt von STEP die integrierte Sicht der integrierten Ressourcen und EXPRESS als Datenspezifikationssprache), das Internet als Integrationsplattform, XML zur Strukturierung der Daten und PDM-Systeme als Werkzeug zum Datenmanagement [BURK 99, S. 4-5]. PDML definiert verschiedene Application Transaction Sets XML-DTDs als Vokabular für verschiedene Benutzer; sie stellen verschiedene Sichten auf die Daten dar. Zur Vermittlung zwischen ATSs gibt es ein Integrationsschema als neutrales Datenmodell. Zur Übersetzung zwischen einem ATS und dem Integrationsschema gibt es jeweils eine Abbildung (siehe Abbildung 32) [BURK 99, S. 7].

81 67 Abbildung 32: Beziehungen zwischen PDML-Schemata [PAER 04, S. 33] Die ATSs und das Integrationsschema werden in EXPRESS spezifiziert [PAER 04, S ]. Es wurden Algorithmen zur Übersetzung von einem EXPRESS-Schema in eine XML-DTD entwickelt, die möglichst viel von der Semantik und Struktur eines EXPRESS-Schemas erhalten. In Abbildung 33 ist die Übersetzung einer EXPRESS-Entity in eine XML-DTD beispielhaft dargestellt. PDML ist eine Anwendung von STEP das Integrationsschema basiert auf den integrierten Ressourcen von STEP [BURK 99, S. 5-6]; es wurde von den integrierten Ressourcen 41, 42, 43 und 44 abgeleitet [PAER 04, S. 34]. 33 Die integrierten Ressourcen gehören zu den allgemeinen Basismodellen und beschreiben Informationsmodelle in EXPRESS, ohne auf eine spezielle Anwendung ausgerichtet zu sein. Das Integrationsschema wird in eine XML-DTD übersetzt [PAER 04, S. 34]. 33 Anmerkung: Nähere Informationen über die Inhalte der Integrierten Ressourcen unter

82 68 Abbildung 33: Beispiel für die Übersetzung einer Deklaration eines Produkts innerhalb eines EXPRESS-Schemas (links) in eine Deklaration innerhalb einer XML-DTD (rechts) [BURK 99, S. 6] Es wurden ATSs vornehmlich für die amerikanische Verteidigungsindustrie angefertigt [BURK 99, S. 8-9]. 34 Das Integrationsschema ist eine große DTD, welche auf STEP basiert und eine integrierte Sicht auf die Produktdaten liefert (siehe Abbildung 34). Die Abbildung der Daten vom Integrationsschema auf ein ATS und umgekehrt erfolgt durch das PDML Toolkit [BURK 99, S. 10]. 34 Anmerkung: Beispiele für ATSs sind in [BURK 99] zu finden

83 69 Abbildung 34: Elemente des PDML-Integrationsschemas [BURK 99, S. 11] Anders als in STEP, wo immer die neutrale Datensicht übertragen wird, werden bei PDML nicht die Daten entsprechend dem Integrationsschema ausgetauscht, sondern ausschließlich den ATSs entsprechende [PAER 04, S ] Verwendungsmöglichkeit in der Fallstudie und der kollaborativen Produktentwicklung Wie in Abschnitt schon beschrieben, ist die Übersetzung eines Datenmodells aus STEP in XML ein grundsätzlich guter Weg, die Informationen aus STEP für den Austausch aufzubereiten. Dadurch wird der

84 70 Datenaustausch web-basiert möglich und die Ressourcen können grundsätzlich vom RMF benutzt, also in einer P2P-Architektur bereitgestellt werden. Während der Entwicklung von PDML gab es XML-Schemas noch nicht, so dass im Gegensatz zum PDTnet-Projekt DTDs eingesetzt wurden. Diese Technik gilt mittlerweile als veraltet. Jeder Kollaborationspartner muss sein internes Datenmodell in EXPRESS darstellen, woraus dann eine DTD generiert wird. Anschließend muss ein Mapping auf das Integrationsschema definiert werden. Daraus ergibt sich der Vorteil, dass das PDMS eines Unternehmens keinen STEP-Export unterstützen muss. Des Weiteren beruht das Integrationsschema von PDML auf anwendungsunabhängigen Ressourcen von STEP, so dass einem branchenübergreifenden Einsatz nichts entgegenspricht. Nachteilig an PDML ist der relativ große Aufwand für das Erstellen von ATSs und Mappings für jedes einzelne Unternehmen. ATSs wurden fast ausschließlich für die amerikanische Verteidigungsindustrie entwickelt. Die Weiterentwicklung und Verbreitung von PDML ist offenbar eingeschränkt, so dass keine weitgehende Verbreitung von PDML erreicht werden konnte. Für die Durchführung der Fallstudie müsste jedes Unternehmen eine eigene ATS für ihr Datenmodell erstellen. Diese ATS muss dann auf das Integrationsschema abgebildet werden. Ein Ausschnitt der Datei, die in der Fallstudie aus Abschnitt 4.1 entstanden sein könnten, ist in der Form einer Product Structure ATS in Abbildung 35 zu sehen.

85 71 Abbildung 35: Ausschnitt aus einer XML-Datei nach der Product-Structure-ATS-DTD, die Teile der Struktur des LEGO -Hauses enthält PDX PDX basiert im Gegensatz zu den übrigen vorgestellten Austauschformaten nicht auf STEP. Das PDX-Format ist als IPC-Standard definiert, was die Ausrichtung an der Elektronikbranche erklärt Zielsetzung und Aufbau PDX wurde geschaffen, um den Austausch von vollständigen Produktdefinitionen entlang der Supply Chain zu erleichtern [IPC2571, S. i]. PDX ist in der IPC-Serie 2570 festgelegt. Mit PDX ist es möglich, Stücklisten, AMLs und andere Produktinhalte (product contents) sowie Änderungen und Referenzen auf Dokumente (z. B. mit geometrischen Informationen) im XML-Format zu beschreiben. Mit IPC-257X ist es möglich, sowohl die gesamte als auch Teile der Produktstruktur zu definieren und zu übertragen [IPC2571, S. 1-2, 5].

86 72 PDX selbst ist nicht dafür ausgelegt, Produkte bis ins letzte Detail zu beschreiben. Die Informationen darin sind nicht ausreichend, um darauf basierend Teile zu fertigen. Zu diesem Zweck müssen weitere Dokumente in einem PDX-Paket eingebunden werden [IPC2571, S. 2]. Im IPC-2571 wird das PDX-Paket definiert, welches in jeder PDX- Implementierung benötigt wird. Im IPC-2578 werden z. B. Artikel, Stücklisten, Änderungen und AMLs definiert [IPC2571, S. 5]. Ein PDX-Paket enthält eine XML-Datei namens pdx.xml und beliebig viele Anhänge. In der Datei pdx.xml können Elemente aus anderen IPC- 257X PDX Standards eingeschlossen sein, es muss jedoch genau ein Element aus dem IPC-2571 enthalten sein. Es wird empfohlen, die Datei pdx.xml und die Anhänge in eine komprimierte Datei zu packen, welche dann die Dateiendung pdx erhält. Dieses vereinfacht den Austausch eines Pakets, indem es die Anzahl der Dateien auf eins reduziert und die Größe verringert. Dieses Vorgehen wird vom Standard jedoch nicht vorgeschrieben. Die Datei pdx.xml enthält neben der Angabe der verwendeten XML- Version zwei weitere Elemente im Prolog, welche Informationen zur PDX-Version und zur Software, mit der das PDX-Paket erstellt wurde, enthalten [IPC2571, S. 6]. Die Elemente in einem PDX-Paket sind Artikel, Änderungen, Historie, Herstellerteile, Lieferantenteile, Anhänge, Kontakte, as-built Produktkonfigurationen und zusätzliche Attribute (siehe Abbildung 36). Eine detaillierte graphische Darstellung des Aufbaus eines PDX-Pakets ist in IPC-2571 Kapitel 4 gegeben [IPC2571, S. 8-13].

87 73 Abbildung 36: Aufbau eines PDX-Pakets [IPC2571, S. 18] Anhänge können entweder im Paket eingeschlossen oder nur über Metadaten (Dateiname usw.) referenziert werden. Es ist ebenso möglich, auf Referenzen auf Anhänge im PDX-Paket zu verzichten und somit den Anhang gänzlich auszuschließen [IPC2571, S. 14]. Es ist weiterhin möglich, nur Teile der vorhandenen Daten in einem PDX- Paket zu verschicken. So können z. B. nur Änderungen verschickt werden oder nur Teile einer Stückliste, nur Kontaktdaten usw. [IPC2571, S. 16]. Im IPC-2571 ist eine DTD vorgegeben, die in jeder pdx.xml-datei enthalten sein muss [IPC2571, S ]. 35 Im IPC-2576 wird ein XML-Schema vorgegeben, welches die Form vorschreibt, in der die as-built Konfiguration eines Produktes an Supply- Chain-Partner weitergegeben werden sollte [IPC2576, S. 1]. Im IPC-2577 wird ein solches XML-Schema für Belange rund um das Thema Qualitätssicherung definiert (Standard noch im Vorschlagsstadium) [IPC2577, S. 1], der Standard IPC-2578 beschreibt den Austausch von AMLs, Stücklisten, ASLs und der Komponenten der Stückliste, außerdem Änderungshistorien [IPC2578, S. 1]. Es gibt PDX-Viewer, mit denen die Ansicht und das Schreiben (je nach Lizenz auch nur die Ansicht) von PDX-Dateien möglich ist. Abbildung 37 zeigt beispielhaft, wie der PDXplorer die Daten des LEGO -Hauses 35 Anmerkung: Die Standards IPC-2571, -2576, -2577, sowie die DTD stehen unter (Stand: ) zum Download bereit und sind auf der beiliegenden CD zu finden

88 74 präsentiert, nachdem das PDX-Paket, das innerhalb der Fallstudie aus Agile Advantage 2006 exportiert wurde (siehe 4.2.2), geöffnet wurde. Abbildung 37: Oberfläche des PDXplorer bei der Ansicht des PDX-Pakets des LEGO - Hauses Verwendungsmöglichkeit in der Fallstudie und der kollaborativen Produktentwicklung PDX ist das Datenaustauschformat, das von Agile Advantage 2006 (siehe 4.2.2) erzeugt werden kann. Aus diesem Grund kann an dieser Stelle ein Ausschnitt der Datei gezeigt werden, die im Rahmen der Untersuchung von Agile Advantage 2006 erzeugt wurde (siehe Abbildung 38).

89 75 Abbildung 38: Ausschnitt aus der Datei pdx.xml nach dem Export des Parts "LEGO - Haus" aus Agile Advantage Wie die oben beschriebenen Austauschformate PDTnet (5.2.2) und PDML (5.2.3) basiert auch PDX auf XML. Dadurch ergeben sich die gleichen Vorteile bzgl. Austauschbarkeit und Einsatzmöglichkeit im RMF. Da PDX nicht auf STEP basiert und keine detaillierte geometrische Darstellung unterstützt, muss für die Übertragung von 3D-Informationen stets eine weitere Datei ausgetauscht werden. Dieses ist jedoch explizit in der Norm vorgesehen, so dass ein PDX-Paket neben dem XML-Dokument in der Regel STEP-Dateien (oder Dateien anderen Formats) enthält. 36 Anmerkung: Die Dateien pdx.xml sowie IF pdx sind auf der beiliegenden CD zu finden

90 76 PDX ist vor allem in der Elektronikbranche verbreitet, es spricht jedoch nichts gegen den Einsatz in anderen Umfeldern, da das Datenmodell hinreichend flexibel ist auch wenn es speziell für diese Branche entwickelt wurde. Für den Einsatz von PDX spricht weiterhin, dass es genormt ist und somit verlässliche Standardvorgaben liefert. Außerdem gibt es zentrale Organe zur Weiterentwicklung des Standards und zum Support bei möglichen Schwierigkeiten. Der Austausch von PDX-Paketen scheint noch nicht so verbreitet zu sein wie der von STEP-Dateien, so dass die Anzahl verfügbarer Pre- und Postprozessoren geringer sein dürfte. D. h. dass in einer kollaborativen Entwicklungsumgebung evtl. noch nicht jeder Teilnehmer in der Lage ist, PDX-Pakete zu erstellen JT JT wurde von EAI entwickelt, die später von UGS akquiriert wurden. UGS hat ein Programm namens JT Open ins Leben gerufen, welches sich um die Entwicklung und Verbreitung von JT kümmert [CYON 06, S. 3, 5] Zielsetzung und Aufbau Das JT-Format kann vollständige CAD-Modelle darstellen, es wird jedoch auf einige Details verzichtet, so dass keine vollständige Transformation zwischen zwei verschiedenen CAD-Systemen möglich ist, jedoch eine genaue 3D-Darstellung [CYON 06, S. 5]. Mit dem JT Open Toolkit können *.jt-dateien erzeugt und gelesen werden. In einer Datei werden unter anderem Informationen über die Geometrie, Benutzermetadaten und die Produktstruktur gespeichert. Die Inhalte können flexibel angepasst werden, so dass verschiedene Anwendungen

91 77 verschiedene Teilinformationen erhalten können. 37 Da von JT CAD und PDM Attribute sowie Metadaten unterstützt werden, eignet es sich zum Einsatz in einer PLM-Umgebung [CYON 06, S. 11]. Alle Objekte, die im JT-Format repräsentiert werden, erhalten Objekt-IDs, über die sie dann referenziert werden können [UGS 06, S. 26]. Die Dateistruktur von JT ist wie in Abbildung 39 dargestellt, aufgebaut. Zunächst kommt immer der Dateikopf, welcher Informationen über die JT- Version enthält (aktuell 8.1), angibt, an welcher Position der TOC-Teil beginnt sowie weitere organisatorische Informationen enthält. [UGS 06, S ]. 38 Abbildung 39: Struktur einer JT-Datei In jeder JT-Datei muss ein Verzeichnis-Segment (TOC-Segement) vorhanden sein, in dem Angaben über die Datensegmente und deren Position gemacht werden [UGS 06, S ]. Alle Produktinformationen werden in Datensegmenten gespeichert. Datensegmente haben je nach Inhalt einen unterschiedlichen Typ. Unter anderem ist dieser Typ im Kopf eines solchen Datensegments hinterlegt. 39 Nach dem Kopf folgen die eigentlichen Informationen [UGS 06, S ]. 37 Vgl Anmerkung: Die Dokumentation von JT ist unter (Stand: ) verfügbar und auf der beiliegenden CD zu finden 39 Anmerkung: Für eine Tabelle der möglichen Datensegmenttypen siehe [UGS 06, S ]

92 78 Das JT-Format macht von verschiedenen Verschlüsselungs- und Kompressionstechniken verschiedener Qualitäten Gebrauch, zwischen denen der Erzeuger von JT-Dateien wählen kann [UGS 06, S ] Verwendungsmöglichkeit in der Fallstudie und der kollaborativen Produktentwicklung JT basiert nicht auf STEP und benutzt auch nicht XML als Dokumentstruktur. Letzteres hat den Nachteil, dass jeder Teilnehmer das JT Open Toolkit installieren muss, um JT-Dateien zu erzeugen und zu betrachten. Das Datenmodell von JT ist nicht von offizieller Stelle genormt, sondern wird von UGS verwaltet, so dass eine gewisse Abhängigkeitsbeziehung zu UGS entsteht. Der Vorteil von JT ist die grundsätzliche Branchenunabhängigkeit, sowie der Einsatz von modernen Verschlüsselungs- und Kompressionstechniken, so dass der Übertragungsaufwand verringert wird und eine gewisse Sicherheitsstufe ohne weitere Aufwendungen erreicht ist. Des Weiteren wird innerhalb des Projekts JT Open das JT-Format noch weiterentwickelt, so dass Einflussnahmen nicht auszuschließen sind und neue Techniken eingesetzt werden können. Außerdem sind geometrische Daten im Format integriert. Diese Informationen sind nicht so vollständig, wie für den direkten Austausch von CAD- Daten üblich, können jedoch eine große Hilfestellung zur Visualisierung bei der Übertragung zwischen PDM-Systemen sein. Nachteilig ist, dass JT-Dateien in P2P-Architekturen (noch) nicht unterstützt werden. Dadurch ist ihr Einsatz in einer solchen Umgebung praktisch ausgeschlossen.

93 PDM Enabler PDM Enabler sind im Gegensatz zu den vorhergehenden Abschnitten kein Austauschformat, sondern die Beschreibung einer Standardschnittstelle zwischen PDM-Systemen. Dabei werden verschiedene Objekte in UML definiert, auf die dann zugegriffen werden kann. Die PDM Enabler sind in einer Spezifikation der OMG beschrieben Zielsetzung und Aufbau Die Spezifikation der PDM Enabler ist in zwölf CORBA-IDL-Module aufgeteilt. Die Spezifikation ist mit anderen CORBA Services und Facilities kompatibel [OMG 00, S ]. Bei einer Implementierung in einem PDMS müssen nicht alle Module berücksichtigt werden, sie bauen jedoch teilweise aufeinander auf (siehe Abbildung 40) [OMG 00, S. 1-3]. 40 Anmerkung: Die Spezifikation ist auf der beiliegenden CD zu finden

94 80 Abbildung 40: Abhängigkeiten der PDM Enabler Module [OMG 00, S. 1-6] Im Modul PdmResponsibility werden die Schnittstellen zum Zugriff auf Personen festgelegt. Es werden die Klassen Actor, Person, Organization, Party, PersonOrganization und Program sowie deren Beziehungen definiert [OMG 00, S ]. Im PdmFoundation -Modul werden sechs grundlegende Klassen definiert, von denen viele weitere Enabler-Objekte aus anderen Modulen erben. Diese Klassen sind Manageable, Lockable, Revisionable, Iteratable, Stateable und SecurityClassifiable [OMG 00, S ]. Das Modul PdmFramework definiert Klassen, die speziell im PDM- Umfeld benötigt werden. Es erbt elementares Verhalten von den CORBAservices und dem PdmFoundation-Modul, um abstrakte Basisklassen für

95 81 die Wiederverwendung in den Modulen für spezifische Anwendungen zu definieren. Diese Klassen sind unter anderem: ManagedEntity, Item- Master, ItemIteration, ItemRevision, Baselineable [OMG 00, S ]. Diese drei Module bieten Basis-PDM-Dienste. Die anderen neun Module definieren separierbare Gruppen von PDM-Diensten, so dass sie nicht implementiert sein müssen, falls ein Software-System einen Dienst nicht anbietet [OMG 00, S. 1-2]. Im PdmBaseline -Modul werden Klassen zur Erstellung von Baselines erstellt. Mittels Baselines können Konfigurationen rekonstruiert oder geprüft werden, sowie Änderungsanalysen durchgeführt werden [OMG 00, S ]. Das Modul PdmViews definiert unter anderem die Klasse Qualification. Ein Objekt dieser Klasse gibt an, ob eine Beziehung oder ein Objekt für einen Zweck bzw. unter gewissen Bedingungen anwendbar ist. Über Beziehungen und Vererbung ist es möglich, dass Klassen in einem Kontext nur sichtbar sind, falls sie in diesem auch anwendbar sind [OMG 00, S ]. Aufgabe des Moduls PdmDocumentManagement ist das Speichern und Erhalten von elektronischen Dokumenten. In dem Modul ist ein einfaches Protokoll zur Dateiübertragung zwischen PDM-Client und -Server enthalten (Check-out- und Check-in-Funktionalität) [OMG 00, S ]. Das PdmProductStructureDefinition -Modul enthält im Kern die Klassen zur Definition von Teilen und Stücklisten. Teile können alles von Rohmaterialien bis zu fertigen Produkten, aber auch Handbücher und Ähnliches sein. Ein Teil ist immer eine Sammlung von Objekten und Beziehungen, die spezifische Aspekte des Teils beschreiben. Die Musterbeschreibung eines Teils basiert auf Standards wie STEP AP 203 und AP 214 und Datenmodellen von PDM-Kunden. Diese Teiledefinition ist jedoch individuell um weitere Attribute und Beziehungen erweiterbar, ohne die gewonnene Interoperabilität zu beschädigen [OMG 00, S ].

96 82 Das PdmEffectivity -Modul ermöglicht es, festzulegen, wann eine bestimmte Revision, Komponente o. Ä. in der Produktion benutzt werden soll. Die Klasse Effectivity erbt dabei von der Klasse Qualification aus dem entsprechenden Modul, stellt also eine besondere Form der Bestimmung der Anwendbarkeit eines Objektes dar [OMG 00, S ]. Für die Durchführung von Änderungen gibt es vier Prozesse, welche in jeweils einer Klasse des Moduls PdmChangeManagement definiert werden: Engineering Change Issue, Engineering Change Request, Engineering Change Order und Engineering Change Notice [OMG 00, S ]. Im Modul PdmManufacturingImplementation werden Spezifikationen für Fertigungsprozesse sowie Beziehungen zwischen diesen, den produzierten Teilen, Fertigungsort und Änderungsanträgen (ECOs), definiert. So können z. B. auch Programme oder Werkzeuge für die Fertigung direkt dem entsprechenden Prozess zugeordnet werden und müssen nicht einem Teil zugeordnet werden [OMG 00, S ]. Als Erweiterung des Moduls PdmProductStructureDefinition gibt es das Modul PdmConfigurationManagement. Mit diesem Modul ist es möglich, dass nicht zu jeder evtl. nur geringfügig unterschiedlichen angebotenen Konfiguration eines Produktes eine eigene Produktstruktur aufgebaut werden muss. Es können die Unterschiede der Konfigurationen beschrieben sowie Regeln hinterlegt werden, wann welche Komponenten zu benutzen sind, abhängig von Werten von Eigenschaften. Der Aufbau des Moduls orientiert sich an der STEP AP 214 [OMG 00, S ]. Das letzte Modul ist das PdmStep -Modul. Die Modelle der PDM Enabler sind ähnlich wie die Anwendungsmodelle der diversen Anwendungsprotokolle von STEP, jedoch nicht identisch aufgebaut. Im Modul ist eine Klasse StepTranslator definiert, die den Export von PDM-Objekten in Dateien und den Import aus Dateien ermöglicht. Jede Instanz der Klasse unterstützt ein spezielles STEP AP. OMG gibt an, PDM Enabler seien besser auf die dynamischen Operationen zwischen PDM-Client und PDM- Server oder zwischen verschiedenen PDM-Servern ausgerichtet als

97 83 STEP. Dieses Modul dient dem Austausch zwischen PDM-Systemen und CAD-Systemen bzw. PDM-Systemen, die STEP AP 203 oder AP 214 benutzen [OMG 00, S ] Verwendungsmöglichkeiten in der Fallstudie und der kollaborativen Produktentwicklung Die PDM Enabler definieren nicht nur ein Datenmodell, wie die Austauschformate in diesem Kapitel, sondern auch Verhalten von Objekten in PDM- Systemen. Sie ermöglichen es, sowohl gezielt auf Objekte in PDM- Systemen zuzugreifen als auch die Daten in STEP auszugeben. Das Datenmodell basiert teilweise auf STEP, teilweise auf anderen Quellen. OMG gibt jedoch selbst an, dass das Modell nicht umfangreich genug für alle Industriezweige sein könnte [OMG 00, S. 8-1]. Bei der Errichtung des LEGO -Hauses können die Lieferanten über die standardisierten Funktionen auf die Teile, Dokumente und übrigen gespeicherten Objekte des PDM-Systems zugreifen und umgekehrt. Bei jedem teilnehmenden Unternehmen muss eine Implementierung der PDM Enabler vorgenommen werden. Danach ist jedoch der Zugriff auf Objektebene möglich. Die Vorteile der PDM Enabler ergeben sich aus den allgemeinen Vorteilen von CORBA. Es wird einfacher, Anwendungen für heterogene, verteilte Umgebungen zu erstellen Vgl Anmerkung: unter sind ausführliche Informationen über CORBA verfügbar

98 Vergleich der Austauschformate bezüglich der Einsatzmöglichkeiten in kollaborativen PDM-Umgebungen Wie in den vorherigen Abschnitten beschrieben, gibt es verschiedene Austauschformate, die sich grundsätzlich für den Austausch von Produktdaten aus PDM-Systemen eignen. Einige grundsätzliche Eigenschaften sind in Tabelle 5 aufgelistet. STEP PDM- Schema PDTnet PDML PDX JT PDM Enabler Dateiformat STEP XML XML XML JT STEP Normungsinstitut ISO IPC ---- (OMG) Geometriedaten x x Branche Allgemein Automobil Verteidigung Elektronik Allgemein Fertigun gsindustrie Zuständiger Entwickler ISO ProSTEP ivip ---- IPC UGS OMG Basisdatenmodell STEP ISO AP 203, 212, 214, 232 STEP ISO AP 214 STEP ISO IGR 41, 42, 43, STEP ISO AP 203, 214 Aktuelle Version / Erscheinungsjahr 1.2 / / / / / 2000 Tabelle 5: Vergleich der vorgestellten Austauschformate Die Formate unterscheiden sich unter anderem durch ihre Ausrichtung an verschiedenen Branchen bzw. deren Verbreitung in verschiedenen Industriezweigen. Für den Einsatz in einer kollaborativen PDM-Umgebung ist es von Vorteil, wenn keine spezielle Branchenausrichtung besteht, da dieses die allgemeine Akzeptanz und Verbreitung fördert und es keinerlei Beschränkung des Einsatzgebietes gibt. Diesbezüglich eigenen sich alle Formate außer PDTnet. Auch wenn ihnen in der Realität gewisse Branchen zugeordnet werden können, so besteht bzgl. des Datenmodells keine Beschränkung für den allgemeinen Einsatz. Das PDTnet-Schema ist speziell für den Einsatz in der Automobilindustrie besonders geeignet.

99 85 Des Weiteren ist es vorteilhaft, wenn ein Datenmodell normiert ist. Durch die Einhaltung von Normen wird vermieden, dass das Datenmodell von einzelnen Unternehmen auf deren spezielle Bedürfnisse angepasst wird und keine allgemeingültige Kompatibilität mehr vorausgesetzt werden kann. Besser ist es, wenn die Norm eine gewisse Flexibilität beinhaltet, die dann für die Beschreibung spezieller Eigenschaften genutzt werden kann. STEP und PDX sind normierte Austauschformate. PDTnet und PDML basieren auf der STEP-Norm, so dass auch bei Ihnen von einem stabilen Datenmodell ausgegangen werden kann. Das Datenmodell der PDM Enabler basiert zum Teil auf STEP, zum Teil jedoch auch auf anderen Quellen und wird nach eigenen Angaben noch verändert [OMG 00, S. 1-2]. Für den Einsatz in einer web-basierten kollaborativen Umgebung ist XML als Austauschformat am besten geeignet, da jeder Teilnehmer ohne Mehraufwand Zugang zu den Daten erhält. Außerdem ist XML das Datenformat, welches vom RMF der Siemens AG unterstützt wird. Aus diesem Grund ist auch der Einsatz in P2P-Netzen möglich. PDML, PDTnet-Schema und PDX sind Austauschformate, die auf XML basieren. Für die STEP-Norm liegt eine Draft Technical Specification vor ISO in der eine XML-Repräsentation der EXPRESS Daten beschrieben ist. 42 Mit den PDM Enablern ist ein Zugriff auf Objektebene möglich. Zur Implementierung ist ein gewisser Aufwand nötig, ansonsten eignen sich die PDM Enabler gut für den Austausch von Produktinformationen in heterogenen Umgebungen. Für den Austausch von Dateien mit geeigneten Informationen bieten die Enabler STEP-Export an. Dafür ist auf der Gegenseite wiederum eine Möglichkeit zum Verwerten dieser Dateien notwendig. In diesem Fall ist es besser, auf eine XML-Repräsentation zurückzugreifen. Bei der Auswahl des Austauschformates kann zusätzlich berücksichtigt werden, in wie weit der Austausch von Geometriedaten unterstützt wird. 42 Vgl

100 86 Ist der Austausch nicht notwendig, so kann ein Format, welches den Austausch von Geometriedaten unterstützt, dazu führen, dass unnötige Daten versendet werden. Gegebenenfalls ist dieses Problem mit zusätzlichen Integrationsbedingungen bei der Erzeugung der Austauschdateien zu umgehen. Bei der kollaborativen Produktentwicklung ist jedoch in der Mehrzahl der Fälle davon auszugehen, dass Geometriedaten zur besseren Anschaulichkeit übertragen werden sollen. Dieses ist zum einen wie bei PDX dadurch zu erreichen, dass 3D-CAD-Modelle in einem zusätzlichen Austauschformat (STEP, IGES, VDA-FS, etc.) hinzugefügt werden, welches speziell für den Datenaustausch zwischen CAD-Systemen ausgerichtet ist. Zum anderen können Datenmodelle wie z. B. das STEP PDM-Schema, PDTnet-Schema, PDML und JT direkt die Möglichkeit bieten, geometrische Daten auszutauschen. Diese Informationen sind jedoch i.d.r. nicht detailliert genug, um die Geometrie tatsächlich weiter mit CAD-Systemen zu bearbeiten, sondern dienen lediglich dem Viewing (wobei JT die detailliertesten Geometrieinformationen liefert). In den auf STEP basierenden Formaten können Verweise auf externe Zeichnungen oder Geometriemodelle angegeben werden. Welche Methode die beste ist, hängt davon ab, wie detailliert die geometrischen Daten in der kollaborativen Produktentwicklung notwendig sind. Gegebenenfalls können die detaillierten Geometrieinformationen auch in einer weiteren Anfrage gesondert angefordert werden, nachdem sich der Bedarf in der Grobansicht bestätigt hat. Wie schon häufiger erwähnt, basieren sowohl das STEP PDM-Schema, als auch das PDTnet-Schema, PDML und die PDM Enabler auf STEP. Abbildung 41 zeigt, welche Teile der ISO-Norm von welchem Austauschformat benutzt werden. Während PDML auf Teilen der allgemeinen Basismodelle basiert und somit anwendungsunabhängig ist, ist das PDTnet-Schema von dem AP 214 abgeleitet, welches die Kerndaten für mechanisches Automobildesign 43 enthält. Das STEP PDM-Schema wiederum bildet die relevante Schnittmenge aus mehreren APs (siehe Abschnitt ). Dadurch wird auch eine gewisse Anwendungsunab- 43 Vgl

101 87 hängigkeit erreicht bzw. das Datenmodell repräsentiert nur gemeinsame Inhalte mehrerer Anwendungen. Die PDM Enabler basieren auf den AP 203 und 214 von STEP, implementieren diese jedoch nicht vollständig und werden durch Informationen erweitert, die von Entwicklungspartnern ergänzt wurden [OMG 00, S. 8-2]. Aus diesem Grund ist das Datenmodell nicht für alle Unternehmen anwendbar.

102 88 Abbildung 41: Detaillierter Aufbau von STEP 44 und Übersicht über die Nutzung der Bausteine durch die Austauschformate 44 Vgl

103 89 6 Lösungen für die kollaborative Produktentwicklung mit Hilfe von Produktdatenmanagementsystemen In diesem Kapitel werden zunächst vorhandene Lösungen für die kollaborative Produktentwicklung in heterogenen PDMS-Landschaften vorgestellt und untersucht (Abschnitt 6.1). Anschließend wird der Einsatz von P2P- Architekturen für die kollaborative Produktentwicklung grundsätzlich bewertet (Abschnitt 6.2). 6.1 Vorhandene Ansätze und Lösungen für die kollaborative Produktentwicklung Die kollaborative Produktentwicklung mit Unterstützung von PDM- Systemen ist ein aktuelles Forschungsgebiet. Eine Auswahl der Lösungen für die Kollaboration in heterogenen Umgebungen werden hier vorgestellt. In Abschnitt werden die PLM Services von OMG vorgestellt und bzgl. der Eignung für die Fallstudie aus Abschnitt 4.1 bewertet. Anschließend in Abschnitt der PDM Collaborator, der innerhalb eines Verbundprojektes entwickelt wurde und verschiedene Szenarien der Zusammenarbeit identifiziert. Auch diese Lösung wird bzgl. der Fallstudie bewertet. Des Weiteren wird in die Lösung Product Collaboration Platform vorgestellt und bewertet, die an der TU Clausthal entwickelt wird und den Einsatz von P2P-Netzen (siehe Abschnitt 5.1.2) in der kollaborativen Produktentwicklung nutzt.

104 PLM Services von OMG Die PLM Services wurden von ProSTEP ivip entwickelt und von der OMG standardisiert Zielsetzung, Datenmodell und Architektur Das Projekt XPDI hatte zum Ziel, eine standardisierte Lösung zur Kollaboration zu ermöglichen und dabei PDTnet (5.2.2) und PDM Enablers (5.2.6) zu benutzen [FELTb, S. 2]. Es soll externe Partner mittels Nutzung von Web-Services integrieren. Seit 2005 sind die PLM Services OMG- Standard [FELTa, S. 4]. Sie werden zurzeit von der ProSTEP ivip Vereinsarbeitsgruppe PLM Services überarbeitet. 46 Die PLM Services ermöglichen synchronen Online-Datenzugriff (Abbildung 42), während der asynchrone Datenaustausch z. B. mittels STEP-Dateien (5.2.1) möglich ist. Abbildung 42: Online Zusammenarbeit mittels PLM Services [FELTa, S. 15] Im ersten Schritt wurde ein plattformunabhängiges Modell entwickelt, dessen Datenmodell auf STEP basiert und dessen Verhalten durch die Anwendungsfälle des PDTnet-Projekts und die PDM Enablers bestimmt 45 Vgl Vgl

105 91 wird. Dieses Modell wird in UML dargestellt. Daraus werden dann plattformspezifische Modelle z. B. in XML und CORBA entwickelt (siehe Abbildung 43). Abbildung 43: Architektur der PLM Services 1.0 [FELTb, S. 5] Das Informationsmodell der PLM Services basiert auf dem STEP PDM- Schema ( ), erweitert um Konfigurationsmanagement-Teile aus der CC8 47 des STEP AP 214. Das resultierende Datenmodell ist ein plattformunabhängiges Modell ( PIM Equivalence Model ) und in EXPRESS definiert [FELT 04, S. 16]. 48 Die nötigen Abbildungen für das Zusammenführen der beiden Schemata (PDM-Schema und CC8) finden mittels EXPRESS-X (ISO ) statt [FELT 04, S ]. EXPRESS-X gehört zu den STEP Beschreibungsmethoden (Status: Committee Draft) und ist eine Methode, um zwei EXPRESS-Datenmodelle ineinander abzubilden Anmerkung: Die Konformitätsklasse (CC) 8 der AP 214 enthält durch Konfigurationen kontrolliertes Design ohne geometrische Repräsentationen, nähere Informationen unter (Stand: ) 48 Anmerkung: Das PIM in EXPRESS ist in [FELT 04, S ] abgebildet 49 Vgl

106 92 Basierend auf der ISO (jedoch nicht komplett kompatibel) wird das EXPRESS-Schema auf XMI abgebildet [FELT 04, S ]. Das Resultat der Abbildung ist ein PLM Referenz-Modell in UML: das PIM Informational Model. Das Modell hat mehrere Pakete. Auf der obersten Ebene das Package PLM_services, das hierarchisch über den anderen Paketen (Alias_identification, Authorization, Change_and_work_ management, Classification, Configuration_management, Document_ and_file_management, Multi_language_support, Part_identification, Part_ structure, PLM_base, Process_planning, Properties, Shape_definition_ and_transformation) angeordnet ist [FELT 04, S ]. Im Computational PIM werden funktionale Aspekte beschrieben, da zur Ermöglichung der identifizierten Use Cases das Datenmodell um funktionelle Elemente angereichert werden muss. So werden die nötigen Lebenszyklus-Funktionen zum Lesen, Erstellen, Update und Löschen von Instanzen des Datenmodells im Computational PIM deklariert. Des Weiteren wird ein Mechanismus zum Stellen von Anfragen an das Informationsmodell im Computational PIM definiert [PROS 05, S. 323]. Das Datenmodell wird so um Funktionen angereichert, um eine einfach zu benutzende Schnittstelle auf die Daten zu liefern [FELT 04, ]. Anschließend kann das PIM in ein PSM übersetzt werden. Dafür wird das UML-Modell angereichert, so dass es z. B. in ein XML-Schema überführt werden kann. Alle Elemente im UML-Modell erhalten dafür den Stereotyp XSDschema [FELT 04, S ]. Schlussendlich entsteht das XML- Schema [FELT 04, S ]. Mittels WSDL werden die Funktionen als Web-Services definiert [FELT 04, S ]. Für die PLM Services sind ein XPDI-Client und XPDI-Server implementiert worden Anmerkung: ISO gehört zu den STEP Implementierungsmethoden und beschreibt eine EXPRESS in OMG XMI Überführung, nähere Informationen unter Anmerkung: Download unter

107 93 Es wird die Annahme getroffen, dass ein neutraler PLM-Client auf verschiedene PLM-Datenanbieter (mit verschiedenen PLM-Systemen) zugreift. Die betrachteten Anwendungsfälle sind jene aus dem PDTnet- Projekt: Export von Produktdaten (STEP PDM-Datei und optional CAD- Dateien in einem ENGDAT 52 -Paket); entsprechender Import von Produktdaten; Authentifizierung, Autorisierung und Aufbau einer Sitzung; Produktstrukturdaten durchsuchen; Download von Produktdaten und Metadaten sowie einzelnen Dateien; Upload von Produktdaten, Metadaten und Dateien; Objektanfragen; Suche; Änderungsmeldungen und zustimmung; Identifikation von Produktklassen und weitere [FELT 04, S ] Sich aus den PLM Services ergebende Möglichkeiten für Kollaboration in der Fallstudie Die Möglichkeiten für die Kollaboration ergeben sich aus den behandelten Anwendungsfällen [PROS 05, S. 5-49]. Für den Bau des LEGO -Hauses können sich verschiedene Entwicklungspartner mit Dateien mit Geometrieinformationen versorgen. Des Weiteren kann eine Online-Sitzung aufgebaut werden, wobei durch geeignete Authentifizierungsmaßnahmen für Sicherheit gesorgt wird. Ein Produzent von Bauteilen kann das LEGO -Haus als Startknoten identifizieren und durch die Struktur navigieren. Dabei wird er evtl. ein Teil identifizieren, für dessen Entwicklung er zuständig ist. Er kann auch durch gezielte Suche ein Bauteil seines Zuständigkeitsbereichs finden. Evtl. sind für dieses Bauteil vom OEM schon Vorgaben gemacht worden, die der Teilnehmer betrachten kann. Er kann dann Veränderungen und Erweiterungen vornehmen, wobei der OEM darüber informiert wird oder vice versa. 52 Anmerkung: ENGDAT ist in Abschnitt 2.5 grundlegend erläutert

108 PDM-Collaborator PDMC ist ein Verbundprojekt, das vom IPK koordiniert wird. Mit encom ist eine Realisierung der Projektergebnisse verfügbar. Durch den Einsatz des PDTnet-Datenmodells und der PDM Enabler besteht eine grundsätzliche Ähnlichkeit mit den PLM Services Zielsetzung, Datenmodell und Architektur Das Projekt PDM-Collaborator will die Kommunikation kooperierender Unternehmen ermöglichen. Diese soll auf verteilten und heterogenen PDM-Systemen basieren [KRAU 03, S. 2]. Das PDMC-System sorgt dafür, dass aus den verschiedenen PDM-Systemen der Kollaborationspartner für die Laufzeit ein einziges, virtuelles PDMS entsteht. Der Ansatz des PDM- Collaborators ist das Pull-Prinzip, d. h. jeder Teilnehmer kann sich online Zugriff auf Produktdaten verschaffen. In dem Projekt wurden drei Szenarien (siehe Abbildung 44) unterschieden: - Unternehmensübergreifende Kooperation mit heterogener PDM- Systemlandschaft - Standortübergreifende Kooperation mit homogener PDM- Systemlandschaft - Einbindung von Zulieferern ohne PDMS [PDMC 03, S. 8-9]. Abbildung 44: Szenarien des Verbundprojektes PDM-Collaborator [PDMC 03, S. 11]

109 95 Die PDMC-Komponenten verwenden das Datenmodell des PDTnet- Projekts (siehe 5.2.2) [PDMC 03, S. 25]. Die Architektur des PDM-Collaborators ist in Schichten aufgebaut. Auf jeder Instanz des PDMC-Systems ist eine Konfigurationsdatei vorhanden, in der die Services und Daten des PDMC-Systems abgelegt sind. Das System ist modular aufgebaut, so dass die Komponenten für die individuellen Ansprüche der Kooperationspartner ausgewählt werden können [PDMC 03, S. 43]. Die Clients bieten die Zugriffsmöglichkeiten auf das PDMC-System. Über Adaptoren präsentiert sich der PDM-Collaborator als PDM-System gegenüber den Clients. Anfragen der Clients werden über Connectoren an die tatsächlichen PDM-Systeme weitergeleitet (siehe Abbildung 45), der PDM-Collaborator selbst hat keine Datenhaltung. Die Adaptoren und Connectoren bilden Schnittstellen und Datenmodelle der Clients und Server auf die einheitliche Zugriffsschnittstelle und das einheitliche Datenmodell (EJB, PDM Enabler [siehe 5.2.6]) der PDM-Collaborator- Komponenten ab [KRAU 03, S. 6-7]. Der Client wird so eingestellt, dass er automatisch den richtigen Adaptor verwendet [PDMC 03, S. 44]. Abbildung 45: Architektur des PDM-Collaborators [KRAU 03, S. 7]

110 96 Die Services-Schicht enthält die Geschäftslogik, basiert auf J2EE und besteht aus vier Komponenten, wovon jede aus einer Engine und einem Repository besteht [PDMC 03, S. 44]. Die Basic Services übernehmen Aufgaben wie Benutzerverwaltung, Session-Management und Nutzerzugangsdatenverwaltung [KRAU 03, S. 7]. Zu den Basic Services gehört der User Manager. Das Repository des User Managers enthält Daten über Firmen, Benutzer und Zugriffsrechte. Die Engine überprüft Zugriffsrechte und stellt Anfragen an das Repository [PDMC 03, S ]. Die Application-specific Services bieten weiterführende Dienste wie z. B. Offline-Datenaustausch oder CAD-Konvertierung an [KRAU 03, S. 8]. So wurde in den JAVA-Client des PDMCs ein CAD- Konvertierungstool eingebunden [PDMC 03, S ]. Die Collaboration Services sind für die Verwaltung und Integration von Projekten und Prozessen (Freigabe- und Änderungsprozesse) zuständig [KRAU 03, S. 7]. Die Collaboration Services bestehen aus zwei Komponenten: dem Project Management Module, welches die unternehmensweite Projektverwaltung organisiert und dem Workflow Management Module, welches unternehmensübergreifendes Workflowmanagement unterstützt. Das Repository des Project Management Moduls bildet für ein Projekt ein Kooperationsmodell ab. Für jede Firma wird definiert, was ihre Leistung am Projekt ist. Die Leistungen werden als Baumstruktur modelliert und in Liefereinheiten und Entwicklungsleistungen aufgeteilt. Entwicklungsleistungen sind Blätter des Baumes und stellen konkrete Entwicklungsergebnisse dar. Liefereinheiten sind die Zusammenfassung von Entwicklungsergebnissen oder anderen Liefereinheiten (siehe Abbildung 46).

111 97 Abbildung 46: Liefereinheiten und Entwicklungsleistungen [PDMC 03, S. 89] Ein sogenannter Context ergibt sich aus einem Projekt und einer beteiligten Firma. Über Rollen und Contexte werden die Sichtbarkeiten für Mitarbeiter definiert. Das Kooperationsmodell besteht aus den Liefereinheiten und Entwicklungsleistungen, sowie den Contexten und Rollen. Den Entwicklungsleistungen werden Workflowinstanzen zugeordnet. Templates und Instanzen von Workflows werden im Repository des Workflow Management Moduls gespeichert, während die Engine des Moduls die Ausführung des Workflows überwacht. Die Workflows sind immer projektspezifisch. In den Workflowinstanzen sind die Verantwortlichkeiten für Entwicklungsleistungen beschrieben [PDMC 03, S ]. Die Federation Services -Komponente verteilt die Benutzeranfragen an die betreffenden PDM-Systeme und fügt Einzelergebnisse zu einem Gesamtergebnis zusammen [KRAU 03, S. 7-8]. Die Komponente ist für die Verwaltung und Überwachung von Zugriffsrechten verantwortlich. Das Federation Repository enthält Daten darüber, wie die Produktdaten über

112 98 die PDM-Systeme verteilt sind sowie Informationen über diese Systeme. Die Federation-Engine splitted die Anfragen, die von einem Benutzer gestellt werden und leitet sie an die anderen in Frage kommenden Systeme weiter. Dieses geschieht transparent, d. h. der Anfrager bekommt ein einheitliches Ergebnis. Durch ein Mapping der Datenmodelle der PDM- Systeme auf ein einheitliches Datenmodell ist es möglich, die Ergebnisse von Anfragen in eine Produktstruktur zu überführen. Die Benutzerrechte werden in den jeweils angeschlossenen Systemen verwaltet. Anfragen der Federation Engine werden nicht vom System beantwortet, wenn die entsprechenden Rechte nicht vorliegen. Schon während der Laufzeit des PDMC-Projekts wurden Implementierungen einer Federation Engine entwickelt, eines von der Firma Eigner und eines vom IPK. Des Weiteren eine Version von ZGDV, die jedoch außerhalb des Projektes auf dessen Ergebnissen basierend entwickelt wurde. Die verschiedenen Unternehmen benutzen in ihren PDM-Systemen unterschiedliche Datenmodelle (z. B. STEP AP 214 [siehe 5.2.1] oder das Datenmodell der PDM Enablers [siehe 5.2.6]). Des Weiteren unterscheiden sich die Produktdaten dadurch, dass in verschiednen Unternehmen verschiedene Nummernsysteme, Benennungen, Einheiten usw. verwendet werden und die Granularität der Produktstruktur unterschiedlich ist. Zwischen den Datenmodellen muss also ein Mapping geschehen. Die Abbildung von Produktdaten ist eine Abbildung von Objektgraphen aufeinander. Im PDMC werden Strukturmapping, Typenmapping und semantisches Mapping mittels einer Mapping Engine durchgeführt. Im Data Mapping Repository sind die Mappingregeln hinterlegt. Es gibt ein Definitions-Tool, mit dessen Hilfe die Mappingregeln zwischen zwei Datenmodellen definiert werden können. Sowohl das Quell- als auch das Zieldatenmodell müssen als XML-Schema vorliegen. Die Mappingregeln werden dann in einer xslt-datei gespeichert. Im PDMC-Projekt ist das Standarddatenmodell immer das PDTnet- Schema (siehe Abschnitt 5.2.2) [PDMC 03, S ]. Die Connector-Schicht ermöglicht die Anbindung der PDMC- Komponenten an die PDM-Server oder PDMC-Server. Server können für das PDMC-System sowohl PDM-Systeme als auch andere PDMC- Instanzen sein [PDMC 03, S. 45].

113 99 Als grundlegendes Datenmodell wurde im PDMC-Projekt das Datenmodell das PDTnet-Schema gewählt. Dieses Schema ist ein XML-Schema und entspricht dem STEP AP 214 [PDMC 03, S. 46]. Die Daten werden im PDM-Collaborator sowohl als Java-Datenstruktur, als auch als XML- Schema (analog zum PDTnet-Projekt) repräsentiert [KRAU 03, S. 10]. Mit Hilfe eines PDTnet-Java-Bindings ist die Umwandlung der PDTnet-XML- Daten in Javastrukturen möglich [PDMC 03, S. 49]. Die Kommunikation zwischen den verschiedenen PDM-Systemen erfolgt ohne zentrale Vermittlungsstation mittels Connectoren. Dabei sind die jeweiligen PDM-Systeme gleichberechtigte Partner. Für die Connectoren wurde eine API entwickelt. Sie können die internen Datenmodelle der Unternehmen in das neutrale Datenmodell abbilden und umgekehrt [PDMC 03, S. 49] Sich aus dem PDMC ergebende Möglichkeiten für Kollaboration in der Fallstudie Die Teilnehmer an der Entwicklung des LEGO -Hauses melden sich mit ihrem PDMC-Client bei den PDM-Systemen der anderen Teilnehmer oder einer PDMS-Föderation an. Mit dem Client kann er Anfragen an das PDMC-System stellen und vorhandene Dateien im XML-Format nach dem PDTnet-Schema betrachten und bearbeiten, sowie neue Teile und Baugruppen erstellen und Dokumente zuordnen. Der OEM des LEGO - Hauses würde ein Projekt anlegen. Anschließend würde er dessen grobe Produktstruktur vorgeben und delegieren, welcher Lieferant für welche Bauteile zuständig ist. Auf den für ihn definierten Bereich kann jeder Lieferant dann zugreifen und die Produktstruktur verfeinern und evtl. Unterbauteile an weitere Teilnehmer weiterreichen. Die Teilnehmer müssen dafür nicht unbedingt ein eigenes PDMS haben. Wenn die Lieferanten Bauteile angelegt bzw. verändert haben, exportieren sie diese Daten im XML-Format dem PDTnet-Schema entsprechend. Damit werden die Produktdaten für Teilnehmer sichtbar, die in ihrem Context definiert sind.

114 Product Collaboration Platform Die Product Collaboration Platform wird zurzeit an der Technischen Universität Clausthal in der Arbeitsgruppe Wirtschaftsinformatik entwickelt. Dabei werden insbesondere die Vorteile einer Peer-To-Peer-Architektur (siehe Abschnitt 5.1.2) diskutiert Zielsetzung, Datenmodell und Architektur Die Product Collaboration Platform (siehe Abbildung 47) möchte den transparenten Zugriff auf Produktmodelle in kollaborativen Umgebungen mit heterogener PDM-Landschaft ermöglichen. Dazu wird ein dezentrales Metadaten-Repository genutzt, das die produktbeschreibenden Daten enthält und vom Ressource Management Framework der Firma Siemens AG verwaltet wird [HOEH 06, S ].

115 101 Abbildung 47: Architektur der Product Collaboration Platform [STIE 06, S. 6] Das RMF ist ein P2P-Netzwerk (siehe Abschnitt 5.1.2), welches Chord 53 als zentralen Routingalgorithmus benutzt. Im RMF stehen Operationen zum Registrieren, Suchen und Modifizieren von Ressourcen sowie zum Anmelden für Benachrichtigungen zur Verfügung [STIE 06, S. 9-11]. Die Suche nach Ressourcen erfolgt anhand der Schlüsselworte [HOEH 06, S. 64]. Die PCP-Middleware ermöglicht dem Benutzer die Operationen des RMFs zu nutzen, um RMF-Ressourcen zu veröffentlichen, zu suchen und zu modifizieren [HOEH 06, S ]. Während der Entwicklung der PCP wurde das Szenario Collaborative Product Development, bei dem das gemeinschaftliche Erstellen eines Produktmodells im Fokus liegt, betrachtet. Es wird davon ausgegangen, 53 Anmerkung: Für Informationen über Chord-Systeme siehe [SAAK 05, S ]

116 102 dass ein Entwickler eine Anfrage nach einem Produktmodell mit spezifischen Eigenschaften stellt, woraufhin (mehrere) Anbieter Vorschläge für ein solches Produktmodell erzeugen können. Der Entwickler muss in diesem Fall eine Request-For-Proposal-Ressource erstellen. Die RFP- Ressource ist eine spezielle RMF-Ressource, in der die nachgefragten Eigenschaften hinterlegt sind. Des Weiteren kann eine solche RFP- Ressource einen Verweis auf eine STEP-Datei (siehe Abschnitt 5.2.1) enthalten, um den Import von geometrischen Daten in Form eines CAD- Modells in einem Viewer der Kollaborationspartner zu ermöglichen. Ein Anbieter kann sich die Anforderungen des Entwicklers, in einer graphischen Oberfläche aufbereitet, ansehen und gegebenenfalls ein verknüpftes CAD-Modell anschauen. Der Anbieter kann jetzt ein Produktmodell erstellen (wenn nicht schon ein entsprechendes Modell in seinem PDM- System vorhanden ist), die zugehörigen CAD-Modelle nach STEP exportieren und mit einer Proposal-Ressource reagieren. Die Proposal- Ressource ist nach dem gleichen XML-Schema wie die RFP-Ressource aufgebaut. Der Entwickler kann sich das erzeugte Produktmodell anschauen und gegebenenfalls zwischen mehreren Vorschlägen wählen [HOEH 06, S ]. Ressourcen im RMF sind XML-Dateien, welche RMF-spezifische Elemente, z. B. ID, Version und eine Liste von Suchschlüsselworten, enthalten [STIE 06, S. 7-9]. Als Suchschlüsselworte werden für die PCP ein systemweit eindeutiger Schlüssel, eine Bezeichnung und der Ressourcentyp (RFP oder Proposal) vorgeschlagen. Weitere Informationen, die über eine RMF-Ressource ausgetauscht werden, sind je nachdem ob es sich um ein Einzel- oder Bauteil handelt die IP-Adresse des Entwicklers bzw. Anbieters, sowie eine Verknüpfung zu einer STEP-Datei. Des Weiteren können bis zu zehn Metainformationen ( Part-Attribute ) über Attribute des Bauteils angegeben werden. Dieses sind die Eigenschaften des Produktmodells, die ein Entwickler angeben kann. Diese Eigenschaften werden sowohl durch deren Werte oder Wertebereiche beschrieben, als auch durch Angaben zur Einheit und Optionalität der Eigenschaft ergänzt (eine Eigenschaft

117 103 kann verpflichtend oder optional sein). Des Weiteren werden sie durch eine Beschreibung erläutert [HOEH 06, S ]. Die beschriebenen Eigenschaften sind Metainformationen, die direkte Auswirkungen auf die zugrunde liegende STEP-Datei haben bzw. aus der STEP-Datei bei der Erzeugung der Ressource extrahiert werden. In Abbildung 48 ist die graphische Darstellung des Schemas einer PCP- Ressource zu sehen. Der gelb markierte Bereich beschreibt die Elemente, die vom RMF vorgegeben sind. Der blau markierte Bereich zeigt die Elemente, die speziell für die PCP angelegt wurden. Dazu gehören auch die zehn Part-Attribute, die die geforderten / gewünschten Eigenschaften eines Produktmodells beschreiben. Der Aufbau dieser Attribute ist exemplarisch für Attribut 1 im grün markierten Bereich beschrieben. Die übrigen Part-Attribute sind analog aufgebaut.

118 104 Abbildung 48: Aufbau einer Ressource in der PCP [Frei nach: HOEH 06, S. 135] Sich aus der PCP ergebende Möglichkeiten für Kollaboration in der Fallstudie Der OEM des LEGO -Hauses hat mit der PCP die Möglichkeit, Anfragen nach Bauteil-Modellen mit bestimmten Eigenschaften zu stellen. Lieferanten können diese Anfragen dann suchen oder bekommen Nachrichten, wenn ein Schlüsselwort benutzt wurde, für das sie angemeldet sind. Sie können die RMF-Ressource mit dem Request betrachten und gegebenenfalls einen Vorschlag zur Lösung unterbreiten. Zur Verdeutlichung der

119 105 Geometrie der Daten können bzw. müssen STEP-Modelle in beide Richtungen übertragen werden bzw. deren URL wird bekannt gemacht. 6.2 Bewertung von Peer-To-Peer-basierten Lösungen für die kollaborative Produktentwicklung Kollaborative Produktentwicklung kann, wie in Abschnitt 3.1 beschrieben, innerhalb eines Unternehmens und zwischen mehreren Unternehmen vorteilhaft sein. In diesem Abschnitt wird zunächst bewertet, in wie weit der Einsatz von P2P-Architekturen innerhalb eines Unternehmens (Abschnitt 6.2.1) sinnvoll ist und welche Vorteile und Nachteile sich daraus beim Einsatz in Kollaborationspartnerschaften verschiedener Unternehmen ergeben (Abschnitt 6.2.2). Abschließend werden Empfehlungen für den Einsatz der PCP gegeben (Abschnitt 6.2.3) Kollaborative Produktentwicklung innerhalb eines Unternehmens Für die kollaborative Produktentwicklung innerhalb eines Unternehmens, in einer heterogenen PDM-Landschaft, bietet sich ein Client-Server- System an, wie es in der Praxis auch Verwendung findet. Die zentrale Verwaltung der Userdaten bietet Vorteile in der Wartbarkeit und Sicherheit. Für den Einsatz eines P2P-Netzes müssten die Daten zunächst in ein bestimmtes Format gebracht werden, dass vom System unterstützt werden kann, z. B. RMF-Ressourcen. Die Umwandlung von Daten führt jedoch häufig zu Informationsverlusten bzw. ist aufwändig. Da eine heterogene PDM-Landschaft besteht, ist keine Umwandlung in Standarddatenformate notwendig. Des Weiteren ist der Datenzugriff auf Datenbanken heute noch nicht Teil von P2P-Techniken. Der Zugriff würde also künstlich auf eine höhere Granularitätsstufe verschoben, was der Kollaboration hinderlich ist.

120 106 Ausgangspunkt war die Annahme, dass innerhalb eines Unternehmens die Bereitschaft besteht, einen Server zu unterhalten. Für verteilte Unternehmen können gegebenenfalls mehrere Server (z. B. einer pro Standort) betrieben werden, die dann untereinander kommunizieren. Diese Kommunikation kann durchaus als P2P-Kommunikation bezeichnet werden. Ein anderer Ansatz ist der Zugriff auf einen zentralen Server über das Internet. Dabei müssen dann entsprechende Caching-Verfahren helfen, damit nicht zu große Datenmengen, z. B. bei der Übertragung von angehängten Dateien, häufig übertragen werden müssen. Innerhalb eines Unternehmens ist es unwahrscheinlich, dass Teilnehmer dynamisch das Netz verlassen oder betreten wollen bzw. die Daten sind nicht bei ihnen, sondern auf dem Server gespeichert, so dass ihr Austritt keine Konsequenzen auf die Verfügbarkeit der Daten hat. Der Zugang für mobile Geräte kann über einen Web-Server (wie auch in Agile Advantage) erfolgen. Bei einer zentralen Unternehmenspolitik kann festgelegt werden, dass alle Angaben in einem PDM-Client in einer Sprache zu tätigen sind (z. B. englisch). Andererseits können bei Zugriffen über eine Web-Schnittstelle die Formulare auch in jeweiligen Landessprachen hinterlegt sein bzw. generiert werden. Das Problem, mit vielen Sprachen umzugehen, ist in einer Client-Server-Umgebung noch eher zu kontrollieren als in einer P2P- Umgebung. Es kann z. B. ein zentrales Wörterbuch eingesetzt werden, dass automatisch Vorschläge für internationale Benennungen oder Übersetzungen generiert. Nachteilig bei der Client-Server-Architektur bleibt, dass Daten bei einem Serverausfall nicht mehr verfügbar sind. Dieses Problem kann z. B. durch redundante Datenhaltung auf verteilten Servern verringert werden. In der Regel sollte dieses Problem jedoch nicht so gravierend sein, dass sich der Einsatz einer P2P-Architektur mit entsprechend höherem Koordinationsaufwand begründen lässt.

121 107 Insgesamt gibt es für den Fall von kollaborativer Produktentwicklung innerhalb eines Unternehmens unter den Annahmen aus keine feste Argumentationsgrundlage, um von der (Standard-)Client-Server- Architektur auf die P2P-Architektur zu wechseln Kollaborative Produktentwicklung zwischen verschiedenen Unternehmen Sobald eine heterogene PDM-Systemlandschaft vorliegt, kommt es zwangsläufig zu Schnittstellenproblemen. Die verschiedenen Teilnehmer an einem Produktentwicklungsprozess benutzen kein einheitliches Produktmodell, so dass Transformationen nötig werden. Wie auch bei den PDM-Collaborators (siehe Abschnitt 6.1.2) und der Product Collaboration Platform (siehe Abschnitt 6.1.3) beschrieben, ist es das Ziel, eine Collaboration Platform zu schaffen, die alle relevanten Produktdaten für alle Beteiligten zur Verfügung stellt (siehe Abbildung 49). Abbildung 49: Collaboration Plattform als Rahmenvorgabe [SCHE 06, S. 143] Diese Plattform kann real existieren, indem ein oder mehrere Server die Daten für alle Teilnehmer zur Verfügung stellen. Die Daten müssen auch in diesem Fall in einem Standardformat gespeichert sein, dass für alle Teilnehmer den Zugriff auf die Inhalte ermöglicht. Die Anzahl der Schnitt-

122 108 stellen reduziert sich damit auf zwei pro Teilnehmer. Ein Nachteil besteht darin, dass ein Server betrieben werden muss, d. h. ein Teilnehmer muss sich um dessen Wartung kümmern und die Kosten übernehmen bzw. diese Angelegenheiten müssen vertraglich geregelt werden. Des Weiteren müssen die datenerzeugenden Unternehmen ihre Datenhoheit aufgeben, die Daten befinden sich auf einem Server, der evtl. nicht direkt der Kontrolle ihres Unternehmens untersteht. Daraus ergeben sich ungewollte Abhängigkeiten und Redundanzen für den Fall, dass die Daten außerdem im Unternehmen gespeichert werden. Die Unternehmen haben außerdem wenig Kontrolle darüber, wer auf die Daten zugreift, da die Mechanismen zur Zugriffskontrolle unter Umständen nicht in ihrem Bereich liegen. Der Einsatz von P2P-Systemen ist vor allem dann notwendig, wenn die einzelnen Teilnehmer vermeiden wollen, dass ihre Daten redundant auf Servern jeweils anderer Teilnehmer gehalten werden und sie ihre Datenhoheit und die Zugriffskontrolle nicht verlieren wollen. Beim Einsatz von P2P-Systemen zur gemeinsamen Produktentwicklung durch mehrere Unternehmen existiert die Collaboration Platform nur virtuell. Die Einigung auf ein allgemeines Produktmodell ist zwar weiterhin notwendig, jedoch bleiben die Daten bei ihren Erzeugern gespeichert und damit unter deren Kontrolle. Wenn ein Unternehmen aus der Kollaborationsgemeinschaft ausscheiden möchte, muss es nur das Netz verlassen und die von ihnen zur Verfügung gestellten Daten stehen nicht mehr zur Verfügung. Ebenso ist der Eintritt für neue Unternehmen schnell möglich, sobald sie das Austauschformat interpretieren können. Der Austausch von Daten kann offline und online notwendig sein. Online- Zugriff bedeutet, dass eine spezifische Anfrage nach bestimmten Daten gestellt wird, auf die dann ad-hoc mit einer Antwort (den entsprechenden Daten bzw. Fehlermeldungen o. Ä.) reagiert wird. Offline-Austausch bedeutet in diesem Zusammenhang, dass die Daten ohne Anfrage zusammengestellt und verfügbar gemacht werden. Die größte Schwierigkeit bei der Etablierung einer Collaboration-Platform dürfte darin liegen, dass sich alle beteiligten Unternehmen auf ein standardisiertes Austauschformat einigen, da es kein allgemeines, umfassend

123 109 verwendetes Format gibt, sondern eine Fülle von Standardformaten, welche häufig besonders in einzelnen Branchen Verbreitung gefunden haben. Will man nun eine Plattform finden, die für alle Branchen einsetzbar ist, muss man unter Umständen zwei oder drei Formate nutzen, was zu unterschiedlichen Sichten auf die Daten führen kann. Idealerweise würden die Daten verteilt in Datenbanken mit gleichem Schema vorliegen, z. B. nach einem, das bei der Überführung eines STEP-Schema in EXPRESS in eine relationale Datenbank entsteht (siehe Abschnitt ). So wäre der Zugriff nicht nur auf Dateiebene, sondern mit hoher Granularität möglich. Leider ist die Suche in verteilten Datenbanken in P2P-Netzen noch nicht ausgereift, erste Lösungsansätze liegen jedoch bereits vor [SAAK 05, S ]. Außerdem müsste ein Unternehmen neben der eigentlichen PDM-DB des eingesetzten PDMS noch eine weitere betreiben, die nach dem allgemeingültigen Schema aufgebaut ist. Dieses erfordert neben erhöhtem Hardwarebedarf vor allem eine aufwendige Koordination der Integrität und Konsistenz beider Datenbanken. Weder beim PDMC noch beim PCP gibt es einen zentralen Server. Die PCP-Architektur setzt explizit auf einer P2P-Architektur auf. Beim PDMC ist die Definition der Netzwerkarchitektur etwas schwieriger. Jeder Teilnehmer betreibt einen Client, mit dem er auf die PDMC zugreift. Dabei wird eine Verbindung zu jedem (relevanten) Server der PDM-Systeme der anderen Teilnehmer aufgebaut. Für die Verwaltung des gesamten Produktmodells gibt es keine zentrale Instanz und auch der Zugriff wird nicht zentral gesteuert, sondern von den Clients selbständig verwaltet. Dieses sind Hinweise auf eine P2P-Architektur. Andererseits kommunizieren die Clients nicht untereinander, sondern mit mehreren Servern: die Anfragen werden an mehrere Server verteilt. Die Clients selbst beantworten keine Anfragen und die Server stellen auch keine Anfragen. Dieses ist das Konzept, welches hinter der Client-Server-Architektur steht. Man kann also von einer grundsätzlichen Client-Server-Architektur mit mehreren Servern sprechen, wobei das globale Produktmodell verteilt gespeichert ist.

124 Empfehlungen für die Product Collaboration Platform Aus den Erkenntnissen über die Anforderungsanalyse aus Abschnitt 3.1.2, den Fallstudien aus Abschnitt 4.1 und den Format- und Architekturanalysen aus Kapitel 5 ergeben sich grundsätzliche Empfehlungen für die PCP. Das Datenmodell der PCP sollte einem Standard angepasst werden, um die Akzeptanz des Systems sowie die Vielfältigkeit und den Umfang der Informationen zu erhöhen. Aus den PDM-Systemen der Unternehmen sind weit mehr Informationen zu generieren, die für die Entwicklung von Bauteilen nützlich sein können. Des Weiteren können nicht nur Anfragen nach und Vorschläge für einzelne(n) Bauteile(n) generiert werden, sondern auch für Teile der Produktstruktur. Da das RMF auf XML-Ressourcen beruht, bieten sich das STEP PDM- Schema, PDTnet-Schema und PDX als Austauschformate an. Da das PDTnet-Schema recht branchenspezifisch angelegt ist, sollten die anderen beiden Formate vorgezogen werden. Die in Abbildung 48 gezeigte Struktur einer PCP-Ressource könnte durch eine ersetzt werden, in der der blaue Bereich durch ein XML-Schema vom STEP-PDM-Format oder PDX-Format ersetzt wird. Dadurch könnte auch das Problem gelöst werden, dass genau zehn Attribute mit Eigenschaften möglich sind, da in beiden Formaten die Zuordnung von beliebig vielen, selbst definierten Eigenschaften möglich wäre. Die für die PCP spezifisch notwendigen Attribute (wie die IP-Adresse des Anfragers bzw. Vorschlagenden) können gegebenenfalls als weitere Elemente im XML-Schema definiert werden, so dass sich ein PCP-spezifischer Rahmen um das XML-Schema des Austauschformats ergibt. Es kann für den Anwendungsfall des Austauschs von Anfragen und Vorschlägen für Bauteile ausreichend sein, sich auf das PDX-Element Item zu beschränken, welches auch AdditionalAttributes enthält, statt ein gesamtes PDX-Paket zu definieren. In dem Falle ist mit weniger Overhead an Informationen zu rechnen. Abbildung 50 zeigt den möglichen Aufbau eines XML-Schemas, das sich am Aufbau eines Standard-PDX-Pakets orientiert. Der gelbe Bereich enthält die für die RMF-Ressource vorgegebenen Elemente, die blauen Bereiche sind aus

125 111 dem PDX-Standard 2571 übernommen. Der violette Bereich sind Elemente, die zusätzlich für die PCP notwendig sind. Abbildung 50: Vorschlag für den Aufbau des XML-Schemas einer möglichen RMF- Ressource, orientiert am Aufbau von PDX-Paketen Die AdditionalAttributes sollen die Part_Attributes (siehe Abbildung 48) ersetzen. Es können beliebig viele solcher Attribute in eine XML-Datei eingefügt werden. Die Definition der Attribute für PDX wird dafür um weitere Elemente für die PCP erweitert, mit der dann die gewünschten Wertebereiche angegeben werden können (siehe Abbildung 51).

126 112 Abbildung 51: Vorschlag für den Aufbau der Additional_Attributes Eine ähnliche Anpassung an die Bedürfnisse des RMFs kann auch vom XML-Schema des STEP PDM-Schemas geschehen. Das RMF, auf dem die PCP aufsetzt, erzeugt auf Grund eines Subscribe- Mechanismus eine große Menge von Datenaustauschvorgängen. Dadurch müssen die RMF-Ressourcen insbesondere in leistungsschwachen Netzwerken sehr klein sein. Aus diesem Grunde wurde bisher darauf verzichtet, die gesamten PDX- oder STEP-Informationen innerhalb der Ressource zu verschicken. Des Weiteren kann das RMF solche Elemente nicht verwalten, die beliebig häufig auftreten dürfen, wie z.b. die AdditionalAttributes des PDX-Schemas. Daraus folgt, dass die maximale Anzahl der vorzugebenden Attribute fest vorgeschrieben werden muss. Insbesondere der letzte Punkt lässt Zweifel daran aufkommen, ob das RMF eine dauerhaft ideale Lösung für die Datenverwaltung in der kollaborativen Produktentwicklung sein kann. Es ist zu prüfen, ob ein anderes P2P- System die Probleme der PCP besser lösen kann. Ein weiterer Kritikpunkt an der PCP ist darin begründet, dass die RMF- Ressourcen verteilt gespeichert werden (einmal pro Schlüsselwort). Dadurch geht der Vorteil der Datenhoheit verloren, der ansonsten ein

127 113 Argument für die P2P-Architektur darstellt. Die Verteilung der Daten geschieht auf Grund der Schlüsselworte in der RMF-Ressource. Dabei kann es passieren, dass die Daten bei Teilnehmern gespeichert werden, die gar keine Zugriffsrechte besitzen. Die Zugriffe auf Daten, die nicht im eigenen Unternehmen gespeichert sind, werden nur schwer kontrollierbar sein. Der Zugriff durch Konkurrenten, die selbst die Datei gespeichert haben, wird nicht zu unterbinden sein. Besser ist es, nur einen Verweis auf die Datei zu speichern, so dass der Zugriff über vorherige Authentifizierung gesteuert werden kann. Da im RMF eine Kopie einer Ressource pro Schlüsselwort gespeichert wird, gibt es die Empfehlung, sich auf drei Schlüsselworte zu beschränken. Wenn nur ein Verweis gespeichert wird, kann die Anzahl erheblich erhöht werden, da die Datenmenge relativ klein ist. Dadurch kann die Suche nach Ressourcen effektiver werden. Der Vorteil der redundanten Haltung einer Ressource ist, dass sie nicht verloren geht, wenn der Teilnehmer das Netz verlässt. Dieses ist bei diesem Vorschlag dann nicht mehr der Fall. Allerdings kann es von einem Unternehmen auch durchaus erwünscht sein, dass alle eigenen Ressourcen gelöscht werden, wenn sie das Netz verlassen. Für die PCP müssen noch weitere Sicherheitsaspekte berücksichtigt werden. Es müssen Mechanismen zur Zuteilung von Benutzerrechten, sowie zur Authentifizierung und Integritätssicherung entwickelt werden. Neben dem Anwendungsfall Collaborative Product Development, der in dieser Arbeit vorgestellt wurde, ist ein Anwendungsfall Shared Model Repository vorgesehen. Bei diesem Anwendungsfall werden mittels der RMF-Ressourcen Metadaten über vorhandene Produktmodelle veröffentlicht, mittels denen diese Modell dann der Peer-To-Peer-Gemeinschaft bekannt gemacht werden, so dass diese die Modelle für ihre Zwecke benutzen können. Das Ziel ist die Wiederverwendung von Produktmodellen [HOEH 06, S ]. Neben diesen beiden Anwendungsfällen sollten noch weitere Fälle betrachtet werden. Denkbar wären Requests, die nicht an die Gemeinschaft, sondern an spezielle Unternehmen gerichtet werden, weil diese z. B. erprobte Partner in spezifischen Bereichen sind oder Rahmenverträge mit günstigen Konditionen bestehen. Außerdem

128 114 kann die Einschränkung auf bestimmte Unternehmen oder der Ausschluss von Unternehmen (Konkurrenten) notwendig sein.

129 115 7 Zusammenfassung und Ausblick Durch die zunehmende Globalisierung kommt es zu größerer Konkurrenz und einem daraus resultierenden Preisdruck. Die Produkte müssen schneller zur Marktreife gelangen und weiterhin günstig bleiben bzw. günstiger werden. Insbesondere international tätige Unternehmen und Unternehmen die durch Outsourcing ihre Fertigungstiefe verringert haben müssen es schaffen, ihre Produktdaten an allen Standorten präsent zu haben oder sie internationalen Zulieferern zur Verfügung zu stellen. Auch die Zusammenführung von Produktdaten verschiedener Unternehmen kann in diesem Zusammenhang notwendig sein. Des Weiteren führen organisatorische Maßnahmen wie das Simultaneous Engineering zu erhöhtem Bedarf an Datenaustausch in der Phase Produktentwicklung [DOBL 98, S. 1-2]. Die Verwaltung der Produktdaten während eines Produktlebenszyklus, insbesondere in der Produktentwicklungsphase, wird von Produktdatenmanagementsystemen (PDM-Systeme) übernommen. Zu den Aufgaben von PDM-Systemen gehören das Verwalten von Stammdaten, Stücklisten, Dokumenten, Versions- und Änderungsinformationen, Prozessinformationen, Varianten und Benutzern, sowie das Exportieren in neutrale Datenformate zum Austausch bzw. zur Archivierung der Produktdaten. Damit ist PDM ein wichtiger Teil des Produktlebenszyklusmanagement (PLM), welches als umfassendes Konzept zur Verwaltung des gesamten Produktlebenszyklus verstanden werden kann. Neben PDM-Systemen gehören auch CAx- und VR-Systeme zu PLM, sowie generelle Konzepte zur Steuerung der Entstehung und Verwaltung von Produktdaten, wie z. B. organisatorische Strukturen und Arbeitsmethoden. Damit sind PDM- Systeme bestens dafür geeignet, Unternehmen bei der kollaborativen Entwicklung eines Produkts zu unterstützen, egal ob innerhalb eines evtl. über mehrere Standorte verteilten Unternehmens oder entlang der Supply Chain mit Lieferanten und Abnehmern. Die Kollaboration innerhalb eines Unternehmens hat weniger Hürden zu meistern als die Zusammenarbeit mehrerer Unternehmen. Innerhalb eines Unternehmens kann die Zusammenarbeit als dauerhaft angesehen

130 116 werden und die Anschaffungs- und Wartungskosten für Server sind klar zuzurechnen. Im Gegensatz dazu ist bei der Kollaboration mehrerer Unternehmen die Zeitspanne oft begrenzt, so dass kein Entwicklungspartner bereit ist, einen zentralen Server zu finanzieren oder seine Systeme anzupassen. Das führt dazu, dass bei der Kollaboration mehrerer Unternehmen heterogenere Systeme miteinander zu verbinden sind. Beim Austausch von Daten gibt es mehr Schnittstellen, die es zu überwinden gilt. Ein weiterer wichtiger Aspekt vermutlich sogar der wichtigste ist die Sicherheit der Produktdaten. Die Kollaboration mit anderen Unternehmen birgt die Gefahr, dass Informationen unfreiwillig weitergegeben werden. Es müssen hohe Sicherheitsanforderungen erfüllt werden. Dazu gehört, dass die Benutzerverwaltung flexibel anpassbar ist und die Daten in der Verwaltungshoheit des Unternehmens bleiben, welches sie erzeugt hat. Ein zentraler Server hätte in diesem Fall zwar den Vorteil, dass die Benutzerverwaltung einfacher wäre, birgt aber den Nachteil, dass Lieferanten ihre Produktdaten an ein fremdes System abgeben müssen. Aus diesem Grund wurde in dieser Arbeit der Einsatz von Peer-To-Peer- Systemen in der kollaborativen Produktentwicklung untersucht. Bisher ist der Einsatz von klassischen Client-Server-Systemen bei PDM-Systemen Standard. Anhand der beiden PDM-Systeme Eigner PLM 5.0 und Agile Advantage 2006 wurde die Funktionsweise und Architektur von PDM-Systemen untersucht. Zu diesem Zweck wurde die Fallstudie Bau eines LEGO - Hauses mit beiden Systemen durchgeführt und die verschiedenen Funktionen zur Unterstützung in der Produktentwicklungsphase untersucht. Um in verteilten Umgebungen mit heterogenen Systemen und verschiedenen Produktmodellen Produktdaten auszutauschen, muss ein einheitliches Austauschformat eingesetzt werden, so dass nicht an jeder Schnittstelle individuelle Konvertierungen notwendig sind. Dadurch entsteht ein einziges Produktmodell für das gesamte, virtuelle Unternehmen. Einige mögliche Austauschformate wurden in dieser Arbeit vorgestellt. Diese können sowohl aus dem CAD-Bereich stammen und somit auch für den

131 117 Austausch von Geometrieinformationen benutzt werden, wie z. B. STEP (ISO 10303) oder JT, oder aber insbesondere für den Austausch von Produktdaten entwickelt worden sein, wie z. B. PDX (IPC 2570-er Serie). Aus STEP wurden weitere Austauschformate abgeleitet, so z. B. das STEP-PDM-Schema, das eine Untermenge mehrerer Anwendungsprotokolle der STEP-Norm darstellt und speziell für die Bedürfnisse beim Datenaustausch zwischen PDM-Systemen entwickelt wurde. Andere auf STEP basierende Austauschformate sind z. B. PDML und das PDTnet- Schema, das im Rahmen des PDTnet-Projekts mit der Teilnahme der PROSTEP AG und führenden Unternehmen - insbesondere der Automobilindustrie - entwickelt wurde. Das PDTnet-Projekt wird von der ProSTEP ivip organisiert. Für die allgemeine Verwendbarkeit eines Austauschformats ist es wichtig, dass es auf keine spezielle Branche zugeschnitten ist und das Format auch ohne spezielle Software lesbar ist. Letzteres gilt insbesondere für die Zusammenarbeit mit KMU, die nicht in der Lage oder nicht bereit sind, zusätzliche Investitionen in Front-Ends für die Betrachtung von Produktdaten zu leisten. Das PDTnet-Schema basiert z. B. auf dem AP 214 von STEP, welches speziell für die Automobilindustrie entwickelt wurde. Die anderen genannten Austauschformate sind prinzipiell branchenunabhängig, auch wenn sie jeweils besondere Verbreitung in einer speziellen Branche gefunden haben. Da die Ressourcen des in der Arbeitsgruppe Wirtschaftsinformatik eingesetzten Peer-To-Peer-Systems XML-Dateien sein müssen und XML ein allgemein verbreitetes Format ist, bieten sich die Austauschformate, die auf XML-Dateien basieren, zur Verwendung an. Das PDTnet-Schema, PDML und PDX sind solche Formate. Mit der ISO wurde ein Vorschlag erstellt, wie aus allgemeinen STEP- EXPRESS-Schemata XML-Schemata generiert werden können. JT wird nicht von Peer-To-Peer-Systemen unterstützt und ist aus diesem Grund für den Einsatz in einer solchen Umgebung nicht geeignet. Die Austauschformate STEP und JT können im Gegensatz zu den anderen vorgestellten Formaten recht viele geometrische Informationen weitergeben. Das kann hilfreich sein um ohne die Übertragung von

132 118 zusätzlichen CAD-Austauschdateien graphische Repräsentationen zu übermitteln und beim Empfänger so das Verständnis über das Produkt zu erhöhen, kann aber auch unnötigen Overhead erzeugen. Als Alternative zu den Austauschformaten gibt es die PDM Enabler. Sie übernehmen das Datenmodell von zwei STEP Anwendungsprotokollen, wodurch ihre Anwendungsunabhängigkeit als eingeschränkt zu bewerten ist, und erweitern dieses um Verhalten. Sie stellen eine CORBAkompatible und -basierte Schnittstelle dar. Eine weitere Möglichkeit zum Datenaustausch ist der Aufbau einer verteilten Datenbank, welche die Produktdaten enthält. Aus einer Datenmodellbeschreibung in EXPRESS (ISO ) lässt sich ein Datenbank-Schema generieren, welches von allen Kollaborationsteilnehmern implementiert werden könnte. Leider ist der Zugriff auf Datenbanken in Peer-To-Peer-Systemen noch nicht ausgereift. Erste Entwicklungen liegen jedoch schon vor. Der Ansatz des Datenaustausches auf Datenbank- Basis sollte jedoch nicht grundsätzlich verworfen werden, da der Zugriff so auf einer niedrigen Granularitätsstufe ermöglicht wird. Das hat den Vorteil, dass beim Einsatz von Techniken zur Vermeidung von konkurrierendem Schreibzugriff nur wenige Daten gesperrt werden müssen, während solche Techniken beim Datenaustausch auf Dateiebene entweder gar nicht möglich sind oder große Bereiche des Produktmodells nicht mehr veränderbar sind, falls ein Benutzer Daten der Austauschdatei mittels Check-Out für sich reserviert hat. In dieser Arbeit wurden beispielhaft drei Ansätze zum kollaborativen Produktdatenaustausch vorgestellt: die PLM Services der OMG, der PDM- Collaborator vom IPK und anderen und die Product Collaboration Platform, die von der Arbeitsgruppe Wirtschaftsinformatik an der Technischen Universität Clausthal zurzeit entwickelt wird. Die PLM Services der OMG basieren auf dem Datenmodell des STEP- PDM-Schemas und dem STEP AP 214 und bilden dieses in ein plattformunabhängiges Modell in UML ab. Dieses Modell wird um Verhalten erweitert, so dass Anwendungsfälle aus dem PDTnet-Projekt sowie der

133 119 PDM Enabler durchgeführt werden können. Das UML-Modell kann auf plattformspezifische Modelle z. B. in XML oder CORBA abgebildet werden. Darauf basierend können dann online Daten übertragen werden. Des Weiteren ist der Offline-Datenaustausch mittels STEP-Dateien vorgesehen. Im Projekt PDM-Collaborator wurde ein Schichtenmodell entwickelt, welches ermöglicht, dass Produktdaten innerhalb eines Unternehmens, zwischen Unternehmen mit PDM-Systemen und mit Lieferanten ohne PDMS ausgetauscht werden können. Mit einem Client meldet sich ein Teilnehmer an dem PDMC-System an und erhält so Zugriff auf die PDM- Systeme der anderen Teilnehmer. Seine Anfragen werden aufgeteilt und an die verschiedenen Systeme verschickt. Dieses geschieht für den Benutzer transparent, so dass sich das PDMC-System für ihn als ein PDMS darstellt. Das allgemeine Datenmodell ist das des PDTnet- Schemas. In der Zusammenarbeit ist immer ein Unternehmen der Leiter eines Entwicklungsprojekts und gibt die grobe Produktstruktur vor. Dabei werden Liefereinheiten und Entwicklungsleistungen definiert und anderen Unternehmen zugeordnet, so dass diese ihren Bereich des kollaborativ zu entwickelnden Produkts sehen können (Context des Unternehmens), jedoch nicht den gesamten Bereich. Es ist möglich, dass ein Unternehmen die Produktstruktur seines Contextes erweitert und wiederum an weitere Unternehmen delegiert. Die Product Collaboration Platform (PCP) ist eine Architektur zum Austausch von Produktdaten in Form von Anfragen und Angeboten. Basis der Architektur bildet das Resource Management Framework der Firma Siemens AG, ein Peer-To-Peer-System, das auf speziellen XML-Dateien sogenannten RMF-Ressourcen ausgerichtet ist. Für die PCP sind die Ressourcen Teileressourcen. Teileressourcen können Anfragen nach Produkten sein (RFP-Ressource) bzw. Antworten auf diese (Proposal- Ressource). In RFP-Ressourcen beschreibt ein Unternehmen Rahmenbedingungen für ein Teil, das sie benötigen. Diese Anfrage wird dann im RMF veröffentlicht. Andere Teilnehmer können diese Ressource entweder durch gezielte Suche finden oder sie werden über deren Veröffentlichung

134 120 informiert, falls sie sich für bestimmte Suchwörter in der Ressource angemeldet haben. Daraufhin können sie ein Produkt entwickeln, das die Bedingungen der RFP-Ressource erfüllt und eine entsprechende Proposal-Ressource veröffentlichen. Des Weiteren sind Ressourcen vorgesehen, die Metadaten über vorhandene Produktmodelle veröffentlichen. In dieser Arbeit wurden Empfehlungen über weitere Anwendungsfälle wie die Beschränkung der Kollaboration auf spezielle Unternehmen in unterschiedlichen Situationen abgegeben und auf Schwachstellen der PCP wie die Abgabe der Datenhoheit an fremde Unternehmen und allgemeine Sicherheitsbedenken aufmerksam gemacht, sowie eine Veränderung des XML-Schemas der RMF-Ressourcen vorgeschlagen, die sich am PDX-Standardaustauschformat orientiert, jedoch die Bedürfnisse der PCP ebenfalls erfüllt.

135 121 Quellenverzeichnis Literaturquellen [AADM 06] Agile Software Corporation: Agile Administrator 2006 SP1 for Agile Advantage, User Guide, 2006 [AADV 06] Agile Software Corporation: Agile Advantage 2006 SP1, Installation and Maintenance Guide, 2006 [ARNO 05] Arnold, V. et al.: Product Lifecycle Management beherrschen: Ein Anwenderhandbuch für den Mittelstand, Berlin, Heidelberg, 2005 [BULL 99] Bullinger, H.-J. et al.: Die verteilte Produktentwicklung im Zusammenhang von DMU, VR und EDMS, erschienen in: VDI Berichte 1497, Beschleunigung der Produktentwicklung durch EDM / PDM- und Feature-Technologie, München, 1999, S [BURK 99] Burkett, W.: PDML, Product Data Markup Language, A New Paradigm for Product Data Exchange and Integration, White Paper, 1999 [CHRI 01] Christ, J.: Fortschritte beim Austausch von PDM-Daten über STEP, Pressemitteilung des ProSTEP Verein zur Förderung internationaler Produktdatennormen e.v., Darmstadt, 2001 [CHTC 02] Chtcherbina, E. et al.: Peer to Peer in Theorie und Praxis, erschienen in: Javaspektrum, 4/2002, S [CONT 02] Contero, M. et al.: Product Data Quality and Collaborative Engineering, erschienen in: IEEE Computer Graphics and Applications, Mai/Juni 2002, S [CYON 06] Cyon Research Corporation: The Business Case for a Common Data Distribution Platform: A Look at UGS JT, Bethesda (USA), 2006

136 122 [DOBL 98] Doblies, M.: Globales Produktdatenmanagement zur Verbesserung der Produktentwicklung, Berichte aus dem Produktionstechnischen Zentrum Berlin, 1998 [DOMA 00] Domazet, D. et al.: An Infrastructure for Inter-Organizational Collaborative Product Development, Proceedings of the 33 rd Hawaii International Conference on System Sciences, 2000 [DUST 03] Dustdar, S. et al.: Software-Architekturen für Verteilte Systeme: Prinzipien, Bausteine und Standardarchitekturen für moderne Software, Berlin, Heidelberg, 2003 [EIGN 03] Eigner M.: Erfolgreiche Aktivitäten im Engineering mit IT- Systemen, Definition Anwendung Nutzen Risiken, erschienen in: WISSENSPORTAL Baumaschine.de, 2/2003 [FELT 04] Feltes, M. et al.: Product Lifecycle Management Service, Revised Submission, 2004 [FELTa] Feltes, M.: OMG PLM Services, Standard-based Engineering Collaboration, Introduction to OMG PLM Services 1.0, Daimler Chrysler Research [FELTb] Feltes, M.: PLM Services a Standard to Implement Collaborative Engineering, Daimler Chrysler Research [GOLT 02] Goltz, M.; Müller, D.: PDM/PLM Verwaltung von Produktdaten ohne Grenzen!?, Institut für Maschinenwesen, TU Clausthal, Institutsmitteilung Nr. 27, 2002, S [HOEH 06] Höhne, E.: Versionierungs- und Synchronisationskonzepte für dezentrale Produktdatenbanken, Institut für Informatik, TU Clausthal, 2006 [IPC2571] IPC: IPC-2571, Generic Requirements for Electronics Manufacturing Supply Chain Communication Product Data exchange (PDX), Bannockburn (USA), 2001

137 123 [IPC2576] IPC: IPC-2576, Sectional Requirements for Electronics Manufacturing Supply Chain Communication of As-Built Product Data Product Data Exchange (PDX), Northbrook (USA), 2001 [IPC2577] IPC: IPC-2577, Sectional Requirements for Supply Chain Communication of Manufacturing Quality Assessment Product Data exchange (PDX), Northbrook (USA), 2005 [IPC2578] IPC: IPC-2578, Sectional Requirements for Supply Chain Communication of Bill of Material and Product Design Configuration Data Product Data exchange (PDX), Bannockburn, 2001 [KRAU 03] Krause, F.-L. et al.: Produktdatenbasierte Kooperation in der Produktentstehung, erschienen in: Adam, W. et al.: Datenmodelle in der Produktion, Fortschr.-Ber. VDI Reihe 2 Nr. 633, Düsseldorf, 2003 [LAUD 06] Laudon, K. et al.: Wirtschaftsinformatik Eine Einführung, München, 2006 [LUEH 96] Lührsen, H.: Die Entwicklung von Datenbanken für das Produktmodell der ISO-Norm STEP, Erlangen, 1996 [OMG 00] OMG: Product Data Management Enablers Specification, Version 1.3, 2000 [PAER 04] Pärnänen, A.; Siltanen, P.: Product Data Standards, Paper IXI Project, Report D6.3, Version 2.7, 2004 [PROS 03a] PROSTEP AG: PDTnet Projekt, Derivation of the PDTnet Schema from AP 214, 2003 [PROS 03b] PROSTEP AG: PDTnet Projekt, PDTnet Implementation Guide V 1.6, 2003 [PROS 03c] PROSTEP AG: PDTnet Projekt, Produktdatentechnologie und Kommunikation in Netzwerk von Automobilhersteller und Zulieferer, Abschlussbericht, 2003

138 124 [PROS 05] ProSTEP ivip Association; ISO; OMG, Inc.: Product Lifecycle Management Services, Convenience Document, 2005 [SAAK 05] Saake, G. et al.: Datenbanken Implementierungstechniken, 2., aktualisierte und erweiterte Auflage, Bonn, 2005 [SCHE 06] Scheer, A.-W. et al.: Prozessorientiertes Product Lifecycle Management, Berlin, Heidelberg, 2006 [SCHI 00] Schierenbeck, H.: Grundzüge der Betriebswirtschaftslehre, 15. Auflage, München, 2000 [SCHO 99] Schöttner, J.: Produktdatenmanagement in der Fertigungsindustrie: Prinzip Konzepte Strategien, München, Wien, 1999 [SEND 05] Sendler, U.; Wawer, V.: CAD und PDM: Prozessoptimierung durch Integration, München, Wien, 2005 [STAR 06] Stark, J.: Product Lifecycle Management: 21st Century Paradigm for Product Realisation, 3. Auflage, London, 2006 [STIE 06] Stiefel, P.; Müller J. P.: A peer to peer based approach to collaborative product engineering, Institut für Informatik, TU Clausthal, 2006 [TANE 03] Tanenbaum, A.: Computernetzwerke, 4. überarbeitete Auflage, München, 2003 [UGS 06] UGS: JT File Format Reference, Version 8.1, 2006 [UNGE 02] Ungerer, M.; Buchanan, K.: Usage Guide for the STEP PDM Schema V1.2, Release 4.3, 2002 [VDI 02] VDI-Gesellschaft Entwicklung, Konstruktion, Vertrieb: VDI- Richtlinie 2219, Informationsverarbeitung in der Produktentwicklung, Einführung und Wirtschaftlichkeit von EDM/PDM-Systemen, Düsseldorf, 2002

139 125 [PDMC 03] Verbundprojekt PDM-Collaborator: Unternehmensübergreifende Kooperation auf PDM-Ebene, Abschlussbericht, 2003 [VERM 04] Verma, D.: Legitimate applications of peer to peer networks, IBM T. J. Watson Research Center, USA, 2004 [WEND 02] Wendenburg, M.: Simultaner Zugriff auf die PDM-Daten, erschienen in ProduktDaten Journal, Nr. 2 I 2002, S

140 126 Internetquellen

141 127 Anhang A Screenshots Eigner PLM 5.0 Screenshot 1: Oberfläche von Eigner PLM 5.0 Screenshot 2: Fenster zum Anlegen eines neuen Artikels in Eigner PLM 5.0

142 128 Screenshot 3: Artikelliste des LEGO -Hauses in Eigner PLM 5.0 Screenshot 4: Stückliste in der Browseransicht des Eigner PLM 5.0

143 129 Screenshot 5: Strukturauflösung des LEGO -Hauses in Eigner PLM 5.0 Screenshot 6: Anlegen eines "gespeicherten Dokuments" in Eigner PLM 5.0

144 130 Screenshot 7: Das Dokument kann nun mittels Check-Out reserviert werden Screenshot 8: Das Projekt "Rohbau" ist ein Unterprojekt des Projekts "Hausbau"

145 131 Screenshot 9: Festlegen der Attribute für ein variables Bauteil Screenshot 10: Die verschiedenen LEGO -Steine können für den Variantenplatzhalter eingesetzt werden

146 132 Screenshot 11: Bildung von Klassen und Übersicht über eine mögliche Klassenhierarchie Screenshot 12: Die LEGO -Steine bekommen Klassifizierungsmerkmale

147 Screenshot 13: Zwischenstand bei der Ableitung einer konkreten Stückliste für einen Kundenauftrag 133

148 Screenshot 14: Neuer Workflow im Workflow-Editor 134

149 135 Anhang B Screenshots Agile Advantage 2006 Screenshot 15: Agile Administrator Oberfläche Screenshot 16: Anlegen eines neuen Benutzers mit dem Agile Administrator

150 136 Screenshot 17: Startbildschirm eines Agile Advantage 2006 Benutzers Screenshot 18: Neues Teil "LEGO -Stein 2x2" anlegen

151 137 Screenshot 19: Liste der letzen Objekte, die User 1 besucht hat (in diesem Fall die Einzelteile des LEGO -Hauses) Screenshot 20: Stückliste des LEGO -Hauses in Agile Advantage 2006

152 138 Screenshot 21: Suche nach allen Teilen, die der Produktlinie "LEGO -Produkt" angehören Screenshot 22: Check-Out von einem Dokument "Bauplan", welches vorher dem LEGO - Haus zugeordnet wurde

153 Screenshot 23: Neuer Change, welcher dem Dachziegel zugeordnet wurde 139

154 Screenshot 24: Der User muss seine Zustimmung für den Statuswechsel des Changes geben 140

155 141 Screenshot 25: Workflow der Änderung wurde durchlaufen (Status: Implemented), neuer Status für das Teil "Dachziegel" (Pilot Released) Screenshot 26: Liste der von der Änderung betroffenen Objekte

156 142 Screenshot 27: Stückliste des LEGO -Hauses, nachdem sie unter Verwendung von Redlining geändert wurde Screenshot 28: Suche nach den Objekten, die mit Agile express 2006 Professional exportiert werden sollen

157 Screenshot 29: Filter-Dialog für den PDX-Export mit Agile express 2006 Professional 143

158 Screenshot 30: Ansicht der exportierten Daten im PDX-Format mit dem Agile express 2006 Professional 144