Unterstützung von Prozessen des Produktdatenmanagements ...

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 14

40476 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

i

Inhaltsverzeichnis

Inhaltsverzeichnis……………………………………………………………... i

Abbildungsverzeichnis……………………………………………………….iv

Tabellenverzeichnis…………………………………………………………..vi

Verzeichnis der Screenshots……………………………………………….vii

Abkürzungsverzeichnis………………………………………………………ix

1 Einleitung......................................... ..................................................1

1.1 Ziel der Arbeit .................................................................................1

1.2 Überblick über den Aufbau der Arbeit ...........................................1

2 Begriffsdefinitionen ............................... ...........................................4

2.1 Produktdaten ..................................................................................4

2.2 Produktlebenszyklus ......................................................................6

2.3 Produktlebenszyklusmanagement.................................................7

2.4 Produktdatenmanagement...........................................................11

2.4.1 Definition Produktdatenmanagement...............................12

2.4.2 Übersicht über erweiterte PDM-Begriffe, Abgrenzung

gegenüber verwandten Begriffen und Synonyme............16

2.5 Kollaborative Produktentwicklung................................................18

3 Kollaborative Produktentwicklung ................... .............................21

3.1 Annahmen und Probleme für die Interoperabilität im

Unternehmen und über Unternehmensgrenzen hinweg.............21

3.1.1 Interoperabilität im Unternehmen .....................................21

3.1.2 Interoperabilität zwischen mehreren Unternehmen.........22

3.2 Anforderungen und Beurteilungskriterien....................................23

4 Klassifizierung von Produktdatenmanagementsystemen. ..........25

4.1 Fallstudie.......................................................................................25

4.2 Verwendete Architekturen und Funktionsanalyse.......................27

4.2.1 Eigner PLM 5.0 .................................................................27

4.2.2 Agile Advantage 2006.......................................................32

ii

5 Architektur und Austauschformate für die kollaborat ive

Produktentwicklung................................. .......................................41

5.1 Netzarchitekturen .........................................................................41

5.1.1 Client-Server-Architektur ..................................................42

5.1.2 Peer-To-Peer-Architektur..................................................44

5.2 Austauschformate.........................................................................46

5.2.1 STEP………. .....................................................................47

5.2.2 PDTnet ..............................................................................60

5.2.3 PDML… .............................................................................65

5.2.4 PDX…….. ..........................................................................71

5.2.5 JT………............................................................................76

5.2.6 PDM Enabler .....................................................................79

5.2.7 Vergleich der Austauschformate bezüglich der

Einsatzmöglichkeiten in kollaborativen PDM-

Umgebungen.....................................................................84

6 Lösungen für die kollaborative Produktentwicklung m it Hilfe von

Produktdatenmanagementsystemen..................... ........................89

6.1 Vorhandene Ansätze und Lösungen für die kollaborative

Produktentwicklung ......................................................................89

6.1.1 PLM Services von OMG ...................................................90

6.1.2 PDM-Collaborator .............................................................94

6.1.3 Product Collaboration Platform.......................................100

6.2 Bewertung von Peer-To-Peer-basierten Lösungen für die

kollaborative Produktentwicklung ..............................................105

6.2.1 Kollaborative Produktentwicklung innerhalb eines

Unternehmens.................................................................105

6.2.2 Kollaborative Produktentwicklung zwischen

verschiedenen Unternehmen .........................................107

6.2.3 Empfehlungen für die Product Collaboration Platform ..110

7 Zusammenfassung und Ausblick ....................... .........................115

Quellenverzeichnis................................. ..............................................121

iii

Anhang A – Screenshots Eigner PLM 5.0 .............. ............................127

Anhang B – Screenshots Agile Advantage 2006 ........ .......................135

Anhang C – Erklärung............................... ...........................................145

Anlagen ............................................ .....................................................146

iv

Abbildungsverzeichnis

Abbildung 1: Produktlebenszyklus................................................................ 7

Abbildung 2: Abhängigkeiten der PLM-Funktionsblöcke ........................... 10

Abbildung 3: PLM und ERP ........................................................................ 11

Abbildung 4: Schnittstellen zu PDM ........................................................... 13

Abbildung 5: Dokumentenverwaltung im PDM mittels Vault und Vault-

Location................................................................................................ 14

Abbildung 6: PDM mit Client-Server-Architektur........................................ 15

Abbildung 7: PLM als Bindeglied zwischen den Säulen Produktion und

Produktentwicklung des Y-CIM-Modells ............................................. 17

Abbildung 8: Datenaustausch mittels Austauschformat ............................ 19

Abbildung 9: Unterstützung von Concurrent Engineering durch PDM...... 20

Abbildung 10: Baumstruktur des LEGO®-Hauses...................................... 26

Abbildung 11: Speichern eines Dokuments auf dem Fileserver des Eigner

PLMs .................................................................................................... 29

Abbildung 12: Komponenten von Agile Advantage 2006 .......................... 33

Abbildung 13: Client-Server-Architektur von Agile Advantage 2006......... 39

Abbildung 14: Super-Peer-Netzwerk .......................................................... 42

Abbildung 15: Das Client/Server-Modell enthält Anforderungen und

Antworten ............................................................................................. 43

Abbildung 16: Möglichkeiten zur Aufteilung der Aufgaben Darstellung,

Anwendungslogik und Datenmanagement auf Client und Server ..... 44

Abbildung 17: P2P-Netz.............................................................................. 45

Abbildung 18: Prinzipieller Aufbau von STEP............................................ 48

Abbildung 19: Typdeklarationen in EXPRESS........................................... 49

Abbildung 20: Entity-Deklaration in EXPRESS.......................................... 50

Abbildung 21: Funktion in EXPRESS......................................................... 51

Abbildung 22: Globale Regel in EXPRESS................................................ 51

Abbildung 23: Deklaration einer Entity in EXPRESS (1) und Erzeugen der

entsprechenden Relation in SQL (2)................................................... 52

Abbildung 24: Übersetzung von aggregierten Datentypen aus EXPRESS

in relationale Datenbanken.................................................................. 54

Abbildung 25: Umfang und Inhalt des STEP PDM-Schemas.................... 56

v

Abbildung 26: Ausschnitt aus einem STEP-File, das ein Teilmodell des

LEGO®-Hauses beschreibt.................................................................. 58

Abbildung 27: Szenario "Datenaustausch" im Projekt PDTnet ................. 60

Abbildung 28: Szenario „Web-basierter Austausch von PDM-Daten“ im

Projekt PDTnet..................................................................................... 61

Abbildung 29: Prinzip der Übersetzung aus EXPRESS in ein XML-Schema

und Beispiel einer möglichen XML-Instanzierung .............................. 62

Abbildung 30: Graphische Darstellung des PDTnet-Schemas in XML ..... 63

Abbildung 31: Ausschnitt einer XML-Datei nach dem PDTnet-Schema, die

Teile der Produktdaten des LEGO®-Hauses enthält .......................... 65

Abbildung 32: Beziehungen zwischen PDML-Schemata .......................... 67

Abbildung 33: Beispiel für die Übersetzung einer Deklaration eines

Produkts innerhalb eines EXPRESS-Schemas (links) in eine

Deklaration innerhalb einer XML-DTD (rechts)................................... 68

Abbildung 34: Elemente des PDML-Integrationsschemas ........................ 69

Abbildung 35: Ausschnitt aus einer XML-Datei nach der Product-Structure-

ATS-DTD, die Teile der Struktur des LEGO®-Hauses enthält ........... 71

Abbildung 36: Aufbau eines PDX-Pakets................................................... 73

Abbildung 37: Oberfläche des PDXplorer bei der Ansicht des PDX-Pakets

des „LEGO®-Hauses“ .......................................................................... 74

Abbildung 38: Ausschnitt aus der Datei pdx.xml nach dem Export des

Parts "LEGO®-Haus" aus Agile Advantage 2006 ............................... 75

Abbildung 39: Struktur einer JT-Datei ........................................................ 77

Abbildung 40: Abhängigkeiten der PDM Enabler Module ......................... 80

Abbildung 41: Detaillierter Aufbau von STEP und Übersicht über die

Nutzung der Bausteine durch die Austauschformate ......................... 88

Abbildung 42: Online Zusammenarbeit mittels PLM Services .................. 90

Abbildung 43: Architektur der PLM Services 1.0 ....................................... 91

Abbildung 44: Szenarien des Verbundprojektes PDM-Collaborator ......... 94

Abbildung 45: Architektur des PDM-Collaborators .................................... 95

Abbildung 46: Liefereinheiten und Entwicklungsleistungen....................... 97

Abbildung 47: Architektur der Product Collaboration Platform ................101

Abbildung 48: Aufbau einer Ressource in der PCP.................................104

Abbildung 49: Collaboration Plattform als Rahmenvorgabe....................107

vi

Abbildung 50: Vorschlag für den Aufbau des XML-Schemas einer

möglichen RMF-Ressource, orientiert am Aufbau von PDX-Paketen

............................................................................................................111

Abbildung 51: Vorschlag für den Aufbau der Additional_Attributes ........112

Tabellenverzeichnis

Tabelle 1: Erfüllung der PDM-Funktionalitäten durch Eigner PLM 5.0 ..... 31

Tabelle 2: Erfüllung der PDM-Funktionalitäten durch Agile Advantage

2006...................................................................................................... 38

Tabelle 3: Vorgegebene Klassenstruktur in Agile Advantage 2006 .......... 40

Tabelle 4: Abbildung von einfachen EXPRESS-Datentypen nach SQL2 .53

Tabelle 5: Vergleich der vorgestellten Austauschformate ......................... 84

vii

Verzeichnis der Screenshots

Screenshot 1: Oberfläche von Eigner PLM 5.0........................................127

Screenshot 2: Fenster zum Anlegen eines neuen Artikels in Eigner PLM

5.0.......................................................................................................127

Screenshot 3: Artikelliste des LEGO®-Hauses in Eigner PLM 5.0 ..........128

Screenshot 4: Stückliste in der Browseransicht des Eigner PLM 5.0 .....128

Screenshot 5: Strukturauflösung des LEGO®-Hauses in Eigner PLM 5.0

............................................................................................................129

Screenshot 6: Anlegen eines "gespeicherten Dokuments" in Eigner PLM

5.0.......................................................................................................129

Screenshot 7: Das Dokument kann nun mittels Check-Out reserviert

werden................................................................................................130

Screenshot 8: Das Projekt "Rohbau" ist ein Unterprojekt des Projekts

"Hausbau" ..........................................................................................130

Screenshot 9: Festlegen der Attribute für ein variables Bauteil ..............131

Screenshot 10: Die verschiedenen LEGO®-Steine können für den

Variantenplatzhalter eingesetzt werden............................................131

Screenshot 11: Bildung von Klassen und Übersicht über eine mögliche

Klassenhierarchie ..............................................................................132

Screenshot 12: Die LEGO®-Steine bekommen Klassifizierungsmerkmale

............................................................................................................132

Screenshot 13: Zwischenstand bei der Ableitung einer konkreten

Stückliste für einen Kundenauftrag ...................................................133

Screenshot 14: Neuer Workflow im Workfloweditor.................................134

Screenshot 15: Agile Administrator Oberfläche .......................................135

Screenshot 16: Anlegen eines neuen Benutzers mit dem Agile

Administrator ......................................................................................135

Screenshot 17: Startbildschirm eines Agile Advantage 2006 Benutzers 136

Screenshot 18: Neues Teil "LEGO®-Stein 2x2" anlegen .........................136

Screenshot 19: Liste der letzen Objekte, die User 1 besucht hat (in diesem

Fall die Einzelteile des LEGO®-Hauses)...........................................137

Screenshot 20: Stückliste des LEGO®-Hauses in Agile Advantage 2006

............................................................................................................137

viii

Screenshot 21: Suche nach allen Teilen, die der Produktlinie "LEGO®-

Produkt" angehören ...........................................................................138

Screenshot 22: Check-Out von einem Dokument "Bauplan", welches

vorher dem LEGO®-Haus zugeordnet wurde ...................................138

Screenshot 23: Neuer Change, welcher dem Dachziegel zugeordnet

wurde..................................................................................................139

Screenshot 24: Der User muss seine Zustimmung für den Statuswechsel

des Change geben.............................................................................140

Screenshot 25: Workflow der Änderung wurde durchlaufen (Status:

Implemented), neuer Status für das Teil "Dachziegel" (Pilot Released)

............................................................................................................141

Screenshot 26: Liste der von der Änderung betroffenen Objekte ...........141

Screenshot 27: Stückliste des LEGO®-Hauses, nachdem sie unter

Verwendung von Redlining geändert wurde.....................................142

Screenshot 28: Suche nach den Objekten, die mit Agile eXpress 2006

Professional exportiert werden sollen ...............................................142

Screenshot 29: Filter-Dialog für den PDX-Export mit Agile eXpress 2006

Professional .......................................................................................143

Screenshot 30: Ansicht der exportierten Daten im PDX-Format mit dem

Agile eXpress 2006 Professional ......................................................144

ix

Abkürzungsverzeichnis

AML Approved Manufacturer List

ANSI American National Standardization Institute

AP Anwendungsprotokoll

ASL Approved Supplier List

ATS Applications Transaction Set

CAC Computer Aided Calculation

CAD Computer Aided Design

CAE Computer Aided Engineering

CAM Computer Aided Manufacturing

CAO Computer Aided Office

CAP Computer Aided Planning

CAQ Computer Aided Quality assurance

CASE Computer Aided Software Engineering

CAx Sammelbegriff für Software im Engineering Umfeld:

CAD, CAE, CAM, CAO, CAP, CAQ, CASE und andere

CC Conformance Class

CE Concurrent Engineering

CIM Computer Integrated Manufacturing

CORBA Common Object Request Broker Architecture

cPDM Collaborative Product Definition Management

CRM Customer Relationship Management

CSV Comma Separated Values

DB Datenbank

DBM Datenbankmanagement

DBS Datenbanksystem

DE Data Exchange

DMU Digital Mock Up

DSL Digital Subscriber Line

DTD Document Type Definition

DTS Draft Technical Specification

EAI Engineering Animation Incorporated

ECO Engineering Change Order

x

EDIFACT Electronic Data Interchange For Administration,

Commerce and Transport

EDM Engineering Data Management

EDMS Engineering Data Management System

EJB Enterprise Java Beans

ENGDAT Engineering Data

ENX European Network eXchange

ERP Enterprise Resource Planning

FEM Finite-Elemente-Methode

GPM Globales Produktdatenmanagement

ID Identifikationsnummer

IDL Interface Definition Language

IGES Initial Graphics Exchange Specification

IMAN Information Manager (von UGS)

IPC Institute for Printed Circuits

IPK Frauenhofer-Institut für Produktionsanlagen und

Konstruktionstechnik

ISDN Integrated Services Digital Network

ISO International Organization for Standardization

iViP Initiative zur integrierten virtuellen Produktentstehung

J2EE Java 2 Platform, Enterprise Edition

JT Jupiter-Tessellation

JXTA Juxtapose

KMU Kleine und mittlere Unternehmen

LAN Local Area Network

LCA Lifecycle Applications (von ENOVIA)

Mgnt. Management

NC Numerical Control

NEMI National Electronics Manufacturing Initiative

ODETTE Organization for Data Exchange by Tele-Transmission

in Europe

OEM Original Equipment Manufacturer

OFTP ODETTE File Transfer Protocol

OMG Object Management Group

xi

P2P Peer-To-Peer

PDF Portable Document Format

PDM Produktdatenmanagement

PDML Product Data Markup Language

PDMS Produktdatenmanagementsystem

PDTnet Produktdatentechnologie und Kommunikation im

Netzwerk von Automobilhersteller und Zulieferer

PDX Product Data eXchange

PIM Platform Independent Model

PLM Produktlebenszyklusmanagement

PPS Produktionsplanung und –steuerung

PSM Platform Specific Model

RFP Request-For-Proposal

RMF Resource Management Framework

SCM Supply Chain Management

SDAI STEP Data Access Interface

SE Simultaneous Engineering

SML Sachmerkmalleiste

SOAP Simple Object Access Protocol

STEP Standard for the Exchange of Product Model Data

TCP/IP Transmission Control Protocol / Internet Protocol

TIFF Tagged Image File Format

TIS Technisches Informationssystem

VDA-FS Verband der Automobilindustrie - Flächenschnittstelle

VDI Verein Deutscher Ingenieure

VPDM Virtuelles Produktdatenmanagement

VPM Virtual Product Development Management

(von ENOVIA)

VR Virtual Reality

WAN Wide Area Network

WSDL Web Services Description Language

WWW World Wide Web

XMI XML Metadata Interchange

XML eXtensible Markup Language

xii

XPDI eXtended Product Data Integration

XSD XML Schema Definition

XSLT eXtensible Stylesheet Language Transformations

ZSS Zeichnungsstammsatz

1

1 Einleitung

1.1 Ziel der Arbeit

In der folgenden Arbeit soll aufgezeigt werden, welche Möglichkeiten

Produktdatenmanagementsysteme für die kollaborative Produktentwick-

lung 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 „Wirtschaftsin-

formatik“ 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 Produkt-

daten zusammengefasst werden. In Abschnitt 2.2 wird der Umfang des

betrachteten Produktlebenszyklus festgelegt. Zur Einordnung der Ge-

samtproblematik wird in Abschnitt 2.3 das Produktlebenszyklusmanage-

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 Anforde-

rungen 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 4.2.1

mit Eigner PLM 5.0 und in 4.2.2 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 Vor-

und 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-

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 zusam-

mengefasst und Schlussfolgerungen gezogen.

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 ver-

schiedenen 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 Produktle-

benszyklus entstehen, ist es notwendig, ein geeignetes System zur

Klassifizierung zu nutzen, um die Wiederverwendung von Daten zu

ermöglichen.

1 Vgl. http://www.plmportal.de/index.php?id=909&no_cache=1&tx_simpleglossar_pi1[he

aderList]=P&tx_simpleglossar_pi1[showUid]=273, 16.08.2006

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 Anwendungssys-

temen und der Formate sowie der Speichermedien ist eine Wiederver-

wendung 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. 86 - 93]. 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 Varian-

ten 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. 238 - 239].

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, Belastungsanalysere-

sultate, Stromkreisanalyseresultate, FEM-Ergebnisse, Simulations-

ergebnisse, Testdatendateien, Testprozeduren, Testresultatkom-

mentare, thermodynamische Analyseergebnisse)

6

- Anweisungen und Handbücher (Aufbauanweisungen, Demonta-

geanweisungen, 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, Kundenanforde-

rungen)

- Produktstrukturdaten (Konfigurationen, Stücklisten, Verwen-

dungsnachweise, Teilelisten, Varianten, Formeln)

- Zustandsbeschreibungen bzw. Änderungsverlaufsdaten

(Statusreports, as-ordered-, as-delivered-, in-process-, in-review-,

released-, as-designed-, as-planned-, as-built-, as-installed-, as-

maintained-, as-operated-Konfiguration, Versionsmanagement-

daten)

- Prozessdaten (Projektpläne, Prozessmodelle, Prozesspläne, Ar-

beitspläne)

- Werkzeugdesign, Vorrichtungsdesign [STAR 06, S. 82, 86 - 90,

237]

Im Folgenden wird davon ausgegangen, dass Produktdaten in elektroni-

scher 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 Arbeitsvorbe-

reitung, die Fertigung und Montage bis zum Vertrieb, der Inbetriebnahme

7

und der Wartung und der letzten Phase, dem Recycling, zu beschreiben

(siehe Abbildung 1).2

Abbildung 1: Produktlebenszyklus3

2.3 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 com-

pany 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, organ-

isational 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. http://www.edmpdm.de/plm_glossar/produktlebenszyklus.htm, 15.08.2006 3 Vgl. http://www.plmportal.de/index.php?id=1182, 16.08.2006

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 Produktentstehungspro-

zess.

• Auch Schnittstellen zu anderen Anwendungsbereichen wie Enter-

prise Resource Planning (ERP), Supply Chain Management (SCM)

oder Customer Relationship Management (CRM) sind Komponen-

ten eines PLM-Konzeptes.

• PLM-Anbieter offerieren Komponenten und/oder Dienstleistungen

zur Umsetzung von PLM Konzepten." [SEND 05, S. 30 - 31]

Mit der Einführung von PLM in einem Unternehmen ändert sich die

Betrachtungsweise grundlegend. Sie ist nun nicht mehr vertikal funktions-

orientiert 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. http://www.cimdata.com/PLM/plm.html, 20.08.2006; Vgl. http://www.3ds.com/de/plm-glossary, 20.08.2006

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 vorfin-

den. 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 Me-

dien.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 Datenver-

waltung kein verbessertes Ergebnis erzielt werden.9

Unternehmensweites PLM ändert die Organisationsstruktur und Verant-

wortlichkeiten im Unternehmen und kann nur durch Re-Engineering

erreicht werden. Es ändern sich die Zusammenhänge zwischen Prozes-

sen, die Art und Weise wie Menschen arbeiten und wie Systeme zusam-

mengehö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 implemen-

tiert. Dabei darf es jedoch nicht zur Isolierung einzelner Aspekte kommen;

die in Abbildung 2 dargestellten Abhängigkeiten müssen unbedingt

5 Vgl. http://www.ugsplm.de/produkte/industrie/index.shtml, 24.08.2006 6 Vgl. http://www.siconvision.com/pdmplm/index.htm, 22.12.2006 7 Vgl. http://www.plmportal.de/index.php?id=909&no_cache=1&tx_simpleglossar_pi1[hea

derList]=P&tx_simpleglossar_pi1[showUid]=180, 20.08.2006 8 Vgl. http://www.cimdata.com/PLM/plm.html, 20.08.2006 9 Vgl. http://www.cimdata.com/PLM/plm.html, 24.08.2006

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. 48 - 49].

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].

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 2.4.1 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 2.4.2 erläutert. Des

Weiteren wird dort, um Verwechslungen mit anderen Begriffen vorzubeu-

gen und die Einordnung von PDM noch klarer zu definieren, PDM anderen

Begriffen gegenübergestellt.

12

2.4.1 Definition Produktdatenmanagement

Produktdatenmanagement ist das Konzept, auf der Basis eines integrier-

ten 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 Informati-

ons- 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 5.2.1.1) basieren auf dem integrierten Produktmodell

[ARNO 05, S. 32 - 35].

PDM-Systeme „sind technische Datenbank- und Kommunikationssysteme,

die dazu dienen, Informationen über Produkte und deren Entstehungspro-

zesse bzw. Lebenszyklen konsistent zu speichern, zu verwalten und

transparent für alle relevanten Bereichen eines Unternehmens bereitzu-

stellen.“ [VDI 02, S. 4] Ein PDMS bildet die Grundlage für ein Gesamtsys-

tem, welches durch die Verbindung von am Produktentwicklungsprozess

beteiligten Anwendungssystemen (z. B. CAx-Systeme, Office-Programme,

NC-Tools usw.) über Schnittstellen entsteht [ARNO 05, S. 163 - 164].

Die Schnittstellen im PDM haben die Aufgabe, Daten mit anderen Syste-

men auszutauschen und sicherzustellen, dass die Daten über System-

grenzen 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. http://www.edmpdm.de/plm_glossar/pdm.htm, 29.11.2006;

Vgl. http://produktdatenmanagement.know-library.net/, 29.11.2006

13

Abbildung 4: Schnittstellen zu PDM [SEND 05, S. 80]

PDM-Systeme bieten Artikel (Einzelteile, Baugruppen, Produkte), Doku-

mente und Projekte als Basisobjekte [SEND 05, S. 39 - 44]. Auf diese

Objekte werden dann die PDM-Funktionen angewandt. Die Grundfunktio-

nen, 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 Austausch-

barkeit 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. 39 - 67]

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 vorzu-

beugen und mittels Check-In- und Check-Out-Funktionen konkurrierende

Änderungen der Dokumente zu vermeiden [ARNO 05, S. 92 - 93]. Ü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. 94 - 96].

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].

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 Installatio-

nen, 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 Kon-

struktion als auch mit Nachbarabteilungen unterstützt.11

11 Vgl. http://www.pdm-produktiv.de/, 25.08.2006

16

2.4.2 Übersicht über erweiterte PDM-Begriffe, Abgre nzung gegen-

über verwandten Begriffen und Synonyme

Der Begriff cPDM beschreibt das Konzept von PDM, welches um Möglich-

keiten der Produkt- und Prozessverwaltung im erweiterten Unternehmen

mittels Internet und Webtechnologien erweitert wird [CONT 02, S. 34 - 35].

Der Begriff GPM bezieht sich auf die Verwaltung von Produktdaten auf

globaler Ebene. Sowohl die verteilten Niederlassungen eines Unterneh-

mens 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 (Beschaf-

fung, 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 Konfiguratio-

nen 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. http://www.edmpdm.de/plm_glossar/edm.htm, 28.08.2006

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 Produktentwick-lung 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].

18

2.5 Kollaborative Produktentwicklung

Unter Kollaboration versteht man die Zusammenarbeit mehrerer Einzel-

personen.13

Viele Unternehmen sind heutzutage weltweit verteilt. Dieses bedingt, dass

Teams ohne Rücksicht auf Raum- und Zeitunterschiede zusammenarbei-

ten müssen [STAR 06, S. 98]. Verstreute Entwicklungsteams arbeiten

meistens mit verschiedenen Systemen zur Unterstützung des Produktent-

wicklungsprozesses, was zu Schnittstellenproblemen führt [BULL 99,

S. 5].

Kollaboration kann auf verschiedenen Ebenen stattfinden. Die Zusam-

menarbeit 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 Schnittstel-

lenproblematik führt dazu, dass n * (n - 1) Formatkonvertierungen zwi-

schen 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. http://www.woxikon.de/wort/Kollaboration.php, 03.10.2006;

Vgl. http://www.campuscontent.de/index.php?menuid=16, 03.10.2006

19

bietet hier den Vorteil, dass vollständige PDM-Produktmodelle übermittelt

werden können. Mittels eines STEP-Preprozessors werden die zu über-

tragenden 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ücksich-

tigt 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. 312 - 315].

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 zeitparalle-

len Arbeitsschritten. CE hat zum einen eine Zeitersparnis zur Folge. Zum

anderen können Fehler früher aufgedeckt werden und Bedürfnisse

20

späterer Schritte früher berücksichtigt werden. Diese Ausführung zeitpa-

ralleler 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. 78 - 80].

Abbildung 9: Unterstützung von Concurrent Engineering durch PDM [SCHO 99, S. 78]

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 Beurteilungskrite-

rien 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.

3.1.1 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 konzentrie-

ren. Jedoch ist es auch möglich, dass es sich um ein verteiltes Unterneh-

men 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.

14 http://www2.hilfe.t-online.de/dyn/c/06/52/97/652974.html, 04.12.2006

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.

3.1.2 Interoperabilität zwischen mehreren Unternehm en

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 kurzfristi-

ge 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-

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 berechtig-

ten Partner zur Verfügung stehen. Auch die Möglichkeiten zur effizienten

Suche nach Informationen spielt in diesem Zusammenhang eine Rolle

[DOBL 98, S. 15 - 16].

Außerdem müssen die Daten für alle Teilnehmer lesbar sein. Liegen

Informationen nur in einem proprietären Format vor, sind sie wahrschein-

lich 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. 37 - 38].

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, festzule-

gen, 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 unter-

stützt?

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 Granula-

ritä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 reser-

viert 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 Zugriffs-

geschwindigkeit, Verfügbarkeit sowie Datenintegrität eine große Rolle

[DOBL 98, S. 13 - 14].

25

4 Klassifizierung von Produktdatenmanagement-

systemen

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 2.4.1 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 über-nommen.

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 verwen-

det werden, um komfortablere Einblicke zu ermöglichen.

27

4.2 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 aufge-

zeigt.

4.2.1 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 Browserfens-

ter, 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 Symbol-

leiste 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.

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 (graphi-

scher 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 Doku-

menten 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 bedin-

gen. 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 Dokumen-

te mit Dateiangabe, bei denen dieses explizit vermieden wird) in einem

bestimmten Sicherheitsbereich gespeichert (siehe Abbildung 11).

29

Abbildung 11: Speichern eines Dokuments auf dem Fileserver des Eigner PLMs16

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 Doku-

menten vornehmen können.

Über den Reiter „Dokumente“ im Fenster eines Artikels können Dokumen-

te 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 Techni-

schen Universität Clausthal, http://orakel.imw.tu-clausthal.de:8017

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 Varianten-

platzhalter 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 verwenden-

den 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än-

dert werden. Durch Betätigen des „Ampelbuttons“, wird der Status eines

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 zugeord-

net werden.

Weitere Funktionalität

Weitere Funktionen, die Eigner PLM 5.0 bietet, sind unter anderem

Rollenkonzepte und Gruppenbildung mit Festlegung bestimmter Privile-

gien, sowie Unterstützung von Arbeitsabläufen mittels Benachrichtigungs-

konzept, 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ütz-

tem 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 Maschi-

nenwesen (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-

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 3.1.2

gemachten Annahmen nicht zutreffen.

4.2.2 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 Speiche-

rung 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 Produktda-

ten 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,

1-7 - 1-8].

33

Abbildung 12: Komponenten von Agile Advantage 2006 [AADV 06, S. 1-4]

4.2.2.1 Vorstellung und Beurteilung der Funktionali tät

Das PLM-System von Agile (Agile Advantage 2006) bietet einen Administ-

rator-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 Einstel-

lungen vorgenommen, welche das Verhalten und Aussehen der Benutzer-

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 Änderun-

gen 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 Administra-

tor 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 vorge-

stellten 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 vorgege-

ben, sowie die zu letzt besuchten Objekte aufgelistet sind (siehe Anhang

B, Screenshot 17).

Anlegen von Objekten (Artikel, Dokumente, Änderungs anträ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-

35

ten Benutzer auch tatsächlich angelegt werden können, ist vom Administ-

rator 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 Ereig-

nisse dokumentiert und über den Reiter „History“ eines Objekts eingese-

hen werden kann.

Jeder Benutzer kann sich eigene Suchen definieren bzw. der Administra-

tor 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 Anfra-

gen 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.

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 E-Mail

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

37

entsprechenden Informationen vorgenommen werden, also z. B. die

Stückliste verändert werden. Die gemachten Änderungen werden gekenn-

zeichnet, 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 Objek-

ten 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.

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 Produkt-

struktur exportiert werden soll (siehe Screenshot 29). Anschließend ist es

möglich, die exportierten Informationen, die jetzt im PDX-Paket gespei-

chert 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 5.2.4.

PDM-Funktion Agile Advantage 2006

Stücklisten erstellen �

Klassifizierung (�)

Workflows �

Versionierung �

Benutzerverwaltung �

Check-Out & Check-In �

Metadatenhaltung in einer Datenbank �

Dokumentenhaltung in einem geschütz-

tem Bereich �

Erstellung von neutralen Datenformaten CSV, PDX, (PDF17)

Tabelle 2: Erfüllung der PDM-Funktionalitäten (siehe Abschnitt 2.4.1) durch Agile Advantage 2006

4.2.2.2 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 2006. Über die

Druckfunktion kann jedoch mittels PDF-Drucker eine PDF-Datei erstellt werden.

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 4.0.5.6 von fabFORCE.net erstellt wurde, und weitere Informationen eingefügt

40

Changes – gleich. Die „Page two“ (und die übrigen Tabs: History, Attach-

ments usw.) ist wiederum für alle Objekte derselben Agile Klasse iden-

tisch. Für die individuellen Klassen steht eine „Page three“ zur Verfügung,

auf der Attribute angelegt werden können, welche nur Objekte der unters-

ten 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 user-defined subclass

Change Orders ECO Change Requests ECR Deviations Deviation Manufacturer Orders MCO Quality Change Requests CAR

Change

Stop Ships Stop Ship Problem Reports Problem Report Product Service

Request Issues Issue Parts Part Item 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.

41

5 Architektur und Austauschformate für die kolla-

borative 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 semanti-

schen 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 ausge-schlossen

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 Mischfor-

men 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]

5.1.1 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

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. 17 - 20].

In Abhängigkeit von der Leistungsfähigkeit der Clients gibt es fünf Mög-

lichkeiten, die Darstellungs-, Anwendungslogik- und Datenmanagement-

aufgaben 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 Aufga-

be, der Leistungsfähigkeit der einzelnen Komponenten und der Anzahl der

Benutzer abhängig [LAUD 06, S. 290 - 291].

44

Abbildung 16: Möglichkeiten zur Aufteilung der Aufgaben Darstellung, Anwendungslogik und Datenmanagement auf Client und Server [LAUD 06, S. 291]

Wie in 2.4.1 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“).20

5.1.2 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. http://www.netplanet.org/aufbau/architekturen.shtml, 18.12.2006

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. 161 - 163].

Abbildung 17: P2P-Netz

5.1.2.1 Gründe für den Einsatz von Peer-To-Peer-Sys temen

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äß gege-

ben – 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. 193 - 194]. 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 symmetri-

scher – genutzt [CHTC 02, S. 24 - 25].

46

5.1.2.2 Unterscheidung von Peer-To-Peer-Architektur en

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. 169 - 193].

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 Standardaus-

tauschformat genannt [UGS 06, S. 13]. JT sieht sich in der Automobil-

branche 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 übertra-

gen.

PDML ist eine Anwendung von STEP und benutzt EXPRESS als Be-

schreibungssprache. Es liefert eine direkte Abbildung von EXPRESS nach

XML. 21 http://www.jtopen.com/technology/, 27.12.2006

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 ausse-

hen 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 6.1.3 kurz vorgestellt wird.

Die PDM Enabler sind von der OMG spezifiziert. Sie sind eine CORBA-

basierte Schnittstelle auf PDM-Systeme und kein Austauschformat in dem

Sinne der anderen vorgestellten Formate in diesem Kapitel.

5.2.1 STEP

Die ISO-Norm 10303 „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].

5.2.1.1 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].

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 Produktbe-

schreibung. Auf diese bauen die anwendungsabhängigen Basismodelle

auf. Durch sie werden die allgemeinen Konstrukte erweitert und speziali-

siert, 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]

5.2.1.2 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

49

Auswahltypen, Entities). Die Deklaration erfolgt wie in Abbildung 19

schematisch dargestellt. Des Weiteren wird die Erstellung von Prozedu-

ren, Funktionen und globalen Regeln unterstützt [LUEH 96, S. 12 - 32].

Abbildung 19: Typdeklarationen in EXPRESS: 1) Konstantendeklaration; 2) einfache Typdeklaration; 3) Aggregierter Datentyp; 4) Aufzählungstyp; 5) Auswahltyp [LUEH 96, S. 12 - 15]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 besit-

zen. 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

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. 16 - 23].

Abbildung 20: Entity-Deklaration in EXPRESS [LUEH 96, S. 16 - 23]23

In EXPRESS wird zwischen Funktionen, die einen Rückgabewert generie-

ren 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 21.

23 Anmerkung: supertype_constraint: <ABSTRACT> SUPERTYPE OF (super-

type_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;

51

Abbildung 21: Funktion in EXPRESS [LUEH 96, S. 23 - 24]

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. 24 - 25]

Weitere Konstrukte in EXPRESS sind Schemata, ausführbare Anweisun-

gen und eingebaute Funktionen. Auf diese soll jedoch an dieser Stelle

nicht eingegangen werden [LUEH 96, S. 25 - 26].

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 Pro-

grammiersprache [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. 26 - 30].

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. 52 - 97]. Für die Übersetzung gibt es häufig mehrere Möglichkeiten,

welche verschiedene Vor- und Nachteile aufweisen. Zur idealen Trans-

formation 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 entsprechen-den Relation in SQL (2) [LUEH 96, S. 61 - 63]

Tabelle 4 zeigt die Zuordnung von SQL2-Datentypen zu einfachen

EXPRESS-Datentypen. Die Datentypen in EXPRESS entsprechen nicht

genau den Datentypen von SQL24, da EXPRESS z. B. von unbeschränk-

ten Wertebereichen und Genauigkeiten ausgeht [LUEH 96, S. 63 - 66].

24 Anmerkung: In dieser Arbeit wird von SQL2 ausgegangen

53

EXPRESS-Datentyp SQL2-Datentyp

INTEGER integer

REAL und REAL (n) und NUMBER decimal (n) oder float

STRING char oder varchar oder text

BINARY bit oder char oder byte

BOOLEAN und LOGICAL 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 Auswahl-

typen erzeugt [LUEH 96, S. 66 - 69].

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. 69 - 72].

Bei der Erzeugung von Arrays und Matrizen, sowie Listen, Mengen und

Multimengen wird vorgegangen, wie in Abbildung 24 gezeigt wird

[LUEH 96, S. 69 - 72].

54

Abbildung 24: Übersetzung von aggregierten Datentypen aus EXPRESS in relationale Datenbanken: 1) Entity mit allen aggregierten Datentypen; 2) Erzeugen der Rela-tion 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. 70 - 71]

Abgeleitete Attribute können nur benutzt werden, falls das DBS Prozedu-

ren und Trigger unterstützt [LUEH 96, S. 72 - 75].

55

Für die Umsetzung von Beziehungen zwischen Entities werden 1:1-, 1:n-

und 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 Datenbankprozedu-

ren 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 Datenban-

ken 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 unter-

stützt, können mittels CHECK-Klauseln Regeln für erlaubte bzw. verbote-

ne Disjunktionen der Subtypen festgelegt werden. Dieser Ansatz erlaubt

unter anderem auch Mehrfachvererbung und überlappende Subtypen

[LUEH 96, S. 78 - 85].

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 Daten-

bankprozeduren übersetzt werden [LUEH 96, S. 85 - 88].

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. 33 - 51].

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.

5.2.1.3 Das STEP PDM-Schema

Da PDM-relevante Daten anwendungsübergreifend und somit in verschie-

denen, nicht aufeinander abgestimmten, Anwendungsprotokollen be-

schrieben sind, wurde das PDM-Schema entwickelt. So werden alle PDM-

relevanten 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. http://www.edmpdm.de/edmpdm_fachartikel/datenaustausch_step.htm,

27.12.2006 26 Anmerkung : Das PDM-Schema in EXPRESS und EXPRESS-G findet sich im Internet

(http://www.pdm-if.org/pdm_schema/ , Stand : 25.11.2006) und auf der beigelegten CD; des Weiteren ist aus [UNGE 02, S. 5] an Beispielen der Aufbau einer Datei im STEP-Format zu entnehmen

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 zumin-

dest die wichtigsten PDM-Funktionen unterstützt [UNGE 02, S. 5].

5.2.1.4 Verwendungsmöglichkeit in der Fallstudie un d der kollabora-

tiven 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 Aus-

schnitt aus einer STEP-Datei, wie sie während der Durchführung der

Fallstudie aus Kapitel 4 entstanden sein könnte.

58

Abbildung 26: Ausschnitt aus einem STEP-File, das ein Teilmodell des LEGO®-Hauses beschreibt27

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 internationa-

len 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

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 Informatio-

nen aus PDM-Systemen vorliegt. STEP hat als Format jedoch den

Nachteil, dass es ohne einen entsprechenden Viewer oder Importprozes-

soren 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 Daten-

modell von STEP für die Kollaboration in P2P-Umgebungen (insbesonde-

re solche, die auf dem RMF basieren) nutzbar zu machen. In der DTS ISO

10303-28 wird eine XML-Repräsentation von EXPRESS-Beschreibungen

vorgeschlagen.28

Wie in diesem Kapitel beschrieben, können STEP-Daten in eine relationa-

le Datenbank überführt werden. Erste Ansätze zur Verwaltung relationaler

Daten in P2P-Netzen mit entsprechenden Verteilungs- und Anfrageopera-

tionen wurden vorgestellt. In solchen Netzen können jedoch keine Garan-

tien 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. 769 - 774]. 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 bereitge-

stellt werden muss. Dadurch sinkt der Anteil von unnötig übertragenen 28 Vgl. http://www.prostep.org/de/standards/was/implementierung/, 01.02..2007

60

Daten (� geringere Übertragungszeiten), unnötig vielen vorgehaltenen

Dateien im Austauschformat (� geringerer Zeit-, Prozessor- und Spei-

cheraufwand) und die Granularität des Datenzugriffs wird niedriger

(� weniger vor konkurrierendem Zugriff zu schützende Daten).

5.2.2 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].

5.2.2.1 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 10303 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

61

basiert auf dem PDTnet ISO 10303 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 10303 AP 214 CC629 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 http://www.prostep.org/de/standards/was/ap/ap214/, 29.01.2007

62

Von der AP 214 wurde ein PDTnet EXPRESS Schema abgeleitet und für

XML optimiert. Dieses Schema wurde dann in ein XML-Schema abgebil-

det [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. 161 - 162]

Bei der Abbildung aus dem STEP AP 214 werden einige Veränderungen

und Vereinfachungen am resultierenden XML-Schema vorgenommen

[PROS 03b, S. 128 - 137]. Die Abbildung 30 zeigt eine graphische Reprä-

sentation des resultierenden XML-Schemas.30

30 Anmerkung: Beide Formen des Schemas (XML-Schema und EXPRESS-Schema) sind

unter http://www.prostep.org/de/standards/doku/ verfügbar, sowie auf der beiliegenden CD zu finden

63

Abbildung 30: Graphische Darstellung des PDTnet-Schemas in XML31

31 Anmerkung: Erstellt mit Altova XMLSpy 2006

64



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 XML-

basierten 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 Projektteil-

nehmer 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 Unver-

stä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.

65

Abbildung 31: Ausschnitt einer XML-Datei nach dem PDTnet-Schema, die Teile der Produktdaten des LEGO®-Hauses enthält32

5.2.3 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

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.


PDML ist eine Lösung zum Produktdatenaustausch, die bewährte Techni-

ken übernimmt und zusammenführt. Diese Techniken sind STEP als

Produktdatenaustauschtechnologie (PDML übernimmt von STEP die

integrierte Sicht der „integrierten Ressourcen“ und EXPRESS als Daten-

spezifikationssprache), das Internet als Integrationsplattform, XML zur

Strukturierung der Daten und PDM-Systeme als Werkzeug zum Datenma-

nagement [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 Integrations-

schema als neutrales Datenmodell. Zur Übersetzung zwischen einem ATS

und dem Integrationsschema gibt es jeweils eine Abbildung (siehe

Abbildung 32) [BURK 99, S. 7].

67

Abbildung 32: Beziehungen zwischen PDML-Schemata [PAER 04, S. 33]

Die ATSs und das Integrationsschema werden in EXPRESS spezifiziert

[PAER 04, S. 33 - 34]. 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 Informationsmo-

delle 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 41 –

44 unter http://www.prostep.org/de/standards/was/igr/, 29.01.2007

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 Verteidigungsindust-

rie 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

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. 34 - 35].



Wie in Abschnitt 5.2.2.2 schon beschrieben, ist die Übersetzung eines

Datenmodells aus STEP in XML ein grundsätzlich guter Weg, die Informa-

tionen aus STEP für den Austausch aufzubereiten. Dadurch wird der

70

Datenaustausch web-basiert möglich und die Ressourcen können grund-

sä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 Integra-

tionsschema von PDML auf anwendungsunabhängigen Ressourcen von

STEP, so dass einem branchenübergreifenden Einsatz nichts entgegen-

spricht.

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.

71

Abbildung 35: Ausschnitt aus einer XML-Datei nach der Product-Structure-ATS-DTD, die Teile der Struktur des LEGO®-Hauses enthält

5.2.4 PDX

PDX basiert im Gegensatz zu den übrigen vorgestellten Austauschforma-

ten nicht auf STEP. Das PDX-Format ist als IPC-Standard definiert, was

die Ausrichtung an der Elektronikbranche erklärt.


PDX wurde geschaffen, um den Austausch von vollständigen Produktdefi-

nitionen 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 übertra-

gen [IPC2571, S. 1 - 2, 5].

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ücklis-

ten, Ä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 kompri-

mierte 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 Produktkonfi-

gurationen 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].

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 enthal-

ten sein muss [IPC2571, S. 28 - 36].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, -2578 sowie die DTD stehen unter

http://webstds.ipc.org/25XXmatrix.htm (Stand: 21.12.2006) zum Download bereit und sind auf der beiliegenden CD zu finden

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“



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).

75

Abbildung 38: Ausschnitt aus der Datei pdx.xml nach dem Export des Parts "LEGO®-Haus" aus Agile Advantage 200636

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-00009.pdx sind auf der beiliegenden CD zu

finden

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 entwi-

ckelt 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.

5.2.5 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].


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

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. 26 - 28].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. 28 - 29].

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. 29 - 35]. 37 Vgl. http://www.jtopen.com/technology/jt_files_overview.html, 27.12.2006 38 Anmerkung: Die Dokumentation von JT ist unter

http://www.jtopen.com/technology/format_reference.shtml (Stand: 29.01.2007) verfüg-bar und auf der beiliegenden CD zu finden

39 Anmerkung: Für eine Tabelle der möglichen Datensegmenttypen siehe [UGS 06, S. 30 – 31]

78

Das JT-Format macht von verschiedenen Verschlüsselungs- und Kom-

pressionstechniken – verschiedener Qualitäten – Gebrauch, zwischen

denen der Erzeuger von JT-Dateien wählen kann [UGS 06, S. 218 - 219].



JT basiert nicht auf STEP und benutzt auch nicht XML als Dokumentstruk-

tur. 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 Kompressionstechni-

ken, 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 Informati-

onen 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 unter-

stützt werden. Dadurch ist ihr Einsatz in einer solchen Umgebung prak-

tisch ausgeschlossen.

79

5.2.6 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.40


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. 1-1 - 1-2]. 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

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“, „Organiza-

tion“, „Party“, „PersonOrganization“ und „Program“ sowie deren Beziehun-

gen definiert [OMG 00, S. 2-1 - 2-11].

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. 3-1 - 3-26].

Das Modul „PdmFramework“ definiert Klassen, die speziell im PDM-

Umfeld benötigt werden. Es erbt elementares Verhalten von den CORBA-

services und dem PdmFoundation-Modul, um abstrakte Basisklassen für

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. 4-1 - 4-22].

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. 5-1 - 5-8].

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. 6-1 - 6-15].

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 enthal-

ten (Check-out- und Check-in-Funktionalität) [OMG 00, S. 7-1 - 7-23].

Das „PdmProductStructureDefinition“-Modul enthält im Kern die Klassen

zur Definition von Teilen und Stücklisten. Teile können alles von Rohmate-

rialien 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 indivi-

duell um weitere Attribute und Beziehungen erweiterbar, ohne die gewon-

nene Interoperabilität zu beschädigen [OMG 00, S. 8-1 - 8-26].

82

Das „PdmEffectivity“-Modul ermöglicht es, festzulegen, wann eine be-

stimmte 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 Bestim-

mung der Anwendbarkeit eines Objektes dar [OMG 00, S. 9-1 - 9-12].

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. 10-1 - 10-25].

Im Modul „PdmManufacturingImplementation“ werden Spezifikationen für

Fertigungsprozesse sowie Beziehungen zwischen diesen, den produzier-

ten 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. 11-1 - 11-22].

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 – angebote-

nen Konfiguration eines Produktes eine eigene Produktstruktur aufgebaut

werden muss. Es können die Unterschiede der Konfigurationen beschrie-

ben 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. 12-1 - 12-43].

Das letzte Modul ist das „PdmStep“-Modul. Die Modelle der PDM Enabler

sind ähnlich wie die Anwendungsmodelle der diversen Anwendungsproto-

kolle 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

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. 13-1 - 13-7].

5.2.6.2 Verwendungsmöglichkeiten in der Fallstudie und der kollabo-

rativen Produktentwicklung

Die PDM Enabler definieren nicht nur ein Datenmodell, wie die Austausch-

formate 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.41

41 Vgl. http://www.omg.org/gettingstarted/corbafaq.htm, 01.02.2007

Anmerkung: unter http://www.omg.org/ sind ausführliche Informationen über CORBA verfügbar

84

5.2.7 Vergleich der Austauschformate bezüglich der Einsatzmög-

lichkeiten in kollaborativen PDM-Umgebungen

Wie in den vorherigen Abschnitten beschrieben, gibt es verschiedene

Austauschformate, die sich grundsätzlich für den Austausch von Produkt-

daten 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

Normungsinsti-tut ISO ---- ---- IPC ---- (OMG)

Geometriedaten � � � x � x

Branche Allgemein Automobil Vertei-digung

Elektro-nik

Allge-mein

Fertigungsin-

dustrie

Zuständiger Entwickler

ISO ProSTEP

iViP ---- IPC UGS OMG

Basisdatenmo-dell

STEP ISO 10303 AP 203, 212, 214, 232

STEP ISO 10303 AP

214

STEP ISO

10303 IGR 41, 42, 43,

44

---- ----

STEP ISO

10303 AP 203,

214

Aktuelle Version / Erscheinungs-

jahr 1.2 / 2002 1.8 / 2003 1999

1.0 / 2001

8.1 / 2006

1.3 / 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 Bran-

chen 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.

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

10303-28 – in der eine XML-Repräsentation der EXPRESS Daten be-

schrieben 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 geeigne-

ten 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. http://www.prostep.org/de/standards/was/implementierung/, 29.01.2007

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ätzli-

chen 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 besse-

ren Anschaulichkeit übertragen werden sollen. Dieses ist zum einen – wie

bei PDX – dadurch zu erreichen, dass 3D-CAD-Modelle in einem zusätzli-

chen 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 kollabo-

rativen Produktentwicklung notwendig sind. Gegebenenfalls können die

detaillierten Geometrieinformationen auch in einer weiteren Anfrage

gesondert angefordert werden, nachdem sich der Bedarf in der Groban-

sicht 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 10303 von welchem

Austauschformat benutzt werden. Während PDML auf Teilen der allge-

meinen Basismodelle basiert und somit anwendungsunabhängig ist, ist

das PDTnet-Schema von dem AP 214 abgeleitet, welches die Kerndaten

für mechanisches Automobildesign43 enthält. Das STEP PDM-Schema

wiederum bildet die relevante Schnittmenge aus mehreren APs (siehe

Abschnitt 5.2.1.3). Dadurch wird auch eine gewisse Anwendungsunab-

43 Vgl. http://www.prostep.org/de/standards/was/ap/, 30.01.2007

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.

88

Abbildung 41: Detaillierter Aufbau von STEP44 und Übersicht über die Nutzung der Bausteine durch die Austauschformate

44 Vgl. http://www.prostep.org/de/standards/was/aufbau/, 29.01.2007

89

6 Lösungen für die kollaborative Produktentwick-

lung mit Hilfe von Produktdatenmanagementsys-

temen

In diesem Kapitel werden zunächst vorhandene Lösungen für die kollabo-

rative 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 kollabo rati-

ve 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 6.1.1 werden die PLM Services von OMG vorgestellt und

bzgl. der Eignung für die Fallstudie aus Abschnitt 4.1 bewertet. Anschlie-

ßend in Abschnitt 6.1.2 der PDM Collaborator, der innerhalb eines Ver-

bundprojektes entwickelt wurde und verschiedene Szenarien der Zusam-

menarbeit identifiziert. Auch diese Lösung wird bzgl. der Fallstudie

bewertet. Des Weiteren wird in 6.1.3 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 kollabora-

tiven Produktentwicklung nutzt.

90

6.1.1 PLM Services von OMG

Die PLM Services wurden von ProSTEP iViP entwickelt und von der OMG

standardisiert.45

6.1.1.1 Zielsetzung, Datenmodell und Architektur

Das Projekt XPDI hatte zum Ziel, eine standardisierte Lösung zur Kollabo-

ration 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 Ver-

einsarbeitsgruppe „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. http://www.prostep.org/en/standards/plmservices/, 30.01.2007 46 Vgl. http://www.pdtec.de/index.php?page=0&lang=0, 30.01.2007

91

wird. Dieses Modell wird in UML dargestellt. Daraus werden dann platt-

formspezifische 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 (5.2.1.3), erweitert um Konfigurationsmanagement-Teile aus der

CC847 des STEP AP 214. Das resultierende Datenmodell ist ein plattform-

unabhä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 10303-14) statt

[FELT 04, S. 58 - 160]. EXPRESS-X gehört zu den STEP Beschrei-

bungsmethoden (Status: Committee Draft) und ist eine Methode, um zwei

EXPRESS-Datenmodelle ineinander abzubilden.49

47 Anmerkung: Die Konformitätsklasse (CC) 8 der AP 214 enthält durch Konfigurationen

kontrolliertes Design ohne geometrische Repräsentationen, nähere Informationen unter http://www.prostep.org/de/standards/was/ap/ap214/ (Stand: 30.01.2007)

48 Anmerkung: Das PIM in EXPRESS ist in [FELT 04, S. 161 – 186] abgebildet 49 Vgl. http://www.prostep.org/de/standards/was/aufbau/, 30.01.2007

92

Basierend auf der ISO 10303-2550 (jedoch nicht komplett kompatibel) wird

das EXPRESS-Schema auf XMI abgebildet [FELT 04, S. 186 - 194].

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. 194 - 353].

Im Computational PIM werden funktionale Aspekte beschrieben, da zur

Ermöglichung der identifizierten Use Cases das Datenmodell um funktio-

nelle Elemente angereichert werden muss. So werden die nötigen Le-

benszyklus-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 Infor-

mationsmodell 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, 354 - 396].

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. 397 - 496]. Schlussendlich entsteht das XML-

Schema [FELT 04, S. 496 - 533]. Mittels WSDL werden die Funktionen als

Web-Services definiert [FELT 04, S. 534 - 549].

Für die PLM Services sind ein XPDI-Client und XPDI-Server implementiert

worden.51

50 Anmerkung: ISO 10303-25 gehört zu den STEP Implementierungsmethoden und

beschreibt eine EXPRESS in OMG XMI Überführung, nähere Informationen unter http://www.prostep.org/de/standards/was/implementierung/, 30.01.2007

51 Anmerkung: Download unter http://www.prostep.org/en/projektgruppen/pdm-if/plmservices.htm, 31.01.2007

93

Es wird die Annahme getroffen, dass ein neutraler PLM-Client auf ver-

schiedene 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 ENGDAT52-Paket); entsprechender Import von Produkt-

daten; Authentifizierung, Autorisierung und Aufbau einer Sitzung; Produkt-

strukturdaten 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. 16 - 54].

6.1.1.2 Sich aus den PLM Services ergebende Möglich keiten 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 Entwick-

lungspartner 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 identifi-

zieren 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 Erweite-

rungen vornehmen, wobei der OEM darüber informiert wird oder vice

versa.

52 Anmerkung: ENGDAT ist in Abschnitt 2.5 grundlegend erläutert

94

6.1.2 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.


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]

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 individu-

ellen 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]

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. 131 - 134].

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. 135 - 138].

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 Kompo-

nenten: dem „Project Management Module“, welches die unternehmens-

weite 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 model-

liert und in Liefereinheiten und Entwicklungsleistungen aufgeteilt. Entwick-

lungsleistungen sind Blätter des Baumes und stellen konkrete Entwick-

lungsergebnisse dar. Liefereinheiten sind die Zusammenfassung von

Entwicklungsergebnissen oder anderen Liefereinheiten (siehe Abbildung

46).

97

Abbildung 46: Liefereinheiten und Entwicklungsleistungen [PDMC 03, S. 89]

Ein sogenannter Context ergibt sich aus einem Projekt und einer beteilig-

ten Firma. Über Rollen und Contexte werden die Sichtbarkeiten für

Mitarbeiter definiert. Das Kooperationsmodell besteht aus den Lieferein-

heiten und Entwicklungsleistungen, sowie den Contexten und Rollen. Den

Entwicklungsleistungen werden Workflowinstanzen zugeordnet. Templa-

tes 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 projekt-

spezifisch. In den Workflowinstanzen sind die Verantwortlichkeiten für

Entwicklungsleistungen beschrieben [PDMC 03, S. 83 - 94].

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

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 Unterneh-

men 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 Struktur-

mapping, Typenmapping und semantisches Mapping mittels einer Map-

ping Engine durchgeführt. Im Data Mapping Repository sind die Map-

pingregeln 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. 95 - 131].

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].

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].

6.1.2.2 Sich aus dem PDMC ergebende Möglichkeiten f ür Kollabora-

tion 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.

100

6.1.3 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.


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. 71 - 72].

101

Abbildung 47: Architektur der Product Collaboration Platform [STIE 06, S. 6]

Das RMF ist ein P2P-Netzwerk (siehe Abschnitt 5.1.2), welches Chord53

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. 71 - 72].

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. 764 – 765]

102

dass ein Entwickler eine Anfrage nach einem Produktmodell mit spezifi-

schen 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 graphi-

schen Oberfläche aufbereitet, ansehen und gegebenenfalls ein verknüpf-

tes 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 expor-

tieren 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 an-

schauen und gegebenenfalls zwischen mehreren Vorschlägen wählen

[HOEH 06, S. 75 - 84].

Ressourcen im RMF sind XML-Dateien, welche RMF-spezifische Elemen-

te, 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 angege-

ben 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

103

kann verpflichtend oder optional sein). Des Weiteren werden sie durch

eine Beschreibung erläutert [HOEH 06, S. 84 - 88]. 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 exem-

plarisch für Attribut 1 im grün markierten Bereich beschrieben. Die übrigen

Part-Attribute sind analog aufgebaut.

104

Abbildung 48: Aufbau einer Ressource in der PCP [Frei nach: HOEH 06, S. 135]

6.1.3.2 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. Lieferan-

ten 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 gegebenen-

falls einen Vorschlag zur Lösung unterbreiten. Zur Verdeutlichung der

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 (Ab-

schnitt 6.2.1) sinnvoll ist und welche Vorteile und Nachteile sich daraus

beim Einsatz in Kollaborationspartnerschaften verschiedener Unterneh-

men ergeben (Abschnitt 6.2.2). Abschließend werden Empfehlungen für

den Einsatz der PCP gegeben (Abschnitt 6.2.3).

6.2.1 Kollaborative Produktentwicklung innerhalb ei nes Unterneh-

mens

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 Sicher-

heit.

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 Standard-

datenformate notwendig. Des Weiteren ist der Datenzugriff auf Datenban-

ken heute noch nicht Teil von P2P-Techniken. Der Zugriff würde also

künstlich auf eine höhere Granularitätsstufe verschoben, was der Kollabo-

ration hinderlich ist.

106

Ausgangspunkt war die Annahme, dass innerhalb eines Unternehmens

die Bereitschaft besteht, einen Server zu unterhalten. Für verteilte Unter-

nehmen können gegebenenfalls mehrere Server (z. B. einer pro Standort)

betrieben werden, die dann untereinander kommunizieren. Diese Kommu-

nikation 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 ange-

hä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 Koordinations-

aufwand – begründen lässt.

107

Insgesamt gibt es für den Fall von kollaborativer Produktentwicklung

innerhalb eines Unternehmens unter den Annahmen aus 3.1.1 keine feste

Argumentationsgrundlage, um von der (Standard-)Client-Server-

Architektur auf die P2P-Architektur zu wechseln.

6.2.2 Kollaborative Produktentwicklung zwischen ver schiedenen

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-

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 Daten-

hoheit 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 stan-

dardisiertes Austauschformat einigen, da es kein allgemeines, umfassend

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 einsetz-

bar 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 5.2.1.2). So wäre der Zugriff nicht nur auf Dateiebene, sondern

mit hoher Granularität möglich. Leider ist die Suche in verteilten Daten-

banken in P2P-Netzen noch nicht ausgereift, erste Lösungsansätze liegen

jedoch bereits vor [SAAK 05, S. 769 - 774]. Außerdem müsste ein Unter-

nehmen neben der eigentlichen PDM-DB des eingesetzten PDMS noch

eine weitere betreiben, die nach dem allgemeingültigen Schema aufge-

baut ist. Dieses erfordert neben erhöhtem Hardwarebedarf vor allem eine

aufwendige Koordination der Integrität und Konsistenz beider Datenban-

ken.

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 Teil-

nehmer 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 Pro-

duktmodells 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.

110

6.2.3 Empfehlungen für die Product Collaboration Pl atform

Aus den Erkenntnissen über die Anforderungsanalyse aus Abschnitt 3.1.2,

den Fallstudien aus Abschnitt 4.1 und den Format- und Architekturanaly-

sen 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, son-

dern 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 ande-

ren 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

111

dem PDX-Standard 2571 übernommen. Der violette Bereich sind Elemen-

te, 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).

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 „Additio-

nalAttributes“ des PDX-Schemas. Daraus folgt, dass die maximale Anzahl

der vorzugebenden Attribute fest vorgeschrieben werden muss. Insbeson-

dere 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

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 Authentifi-

zierung 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 Ressour-

cen 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öffent-

licht, 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 Produktmodel-

len [HOEH 06, S. 94 - 95]. 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

114

kann die Einschränkung auf bestimmte Unternehmen oder der Ausschluss

von Unternehmen (Konkurrenten) notwendig sein.

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 Produktdaten-

managementsystemen (PDM-Systeme) übernommen. Zu den Aufgaben

von PDM-Systemen gehören das Verwalten von Stammdaten, Stücklisten,

Dokumenten, Versions- und Änderungsinformationen, Prozessinformatio-

nen, Varianten und Benutzern, sowie das Exportieren in neutrale Daten-

formate zum Austausch bzw. zur Archivierung der Produktdaten. Damit ist

PDM ein wichtiger Teil des Produktlebenszyklusmanagement (PLM),

welches als umfassendes Konzept zur Verwaltung des gesamten Produkt-

lebenszyklus 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

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 Entwicklungspart-

ner bereit ist, einen zentralen Server zu finanzieren oder seine Systeme

anzupassen. Das führt dazu, dass bei der Kollaboration mehrerer Unter-

nehmen 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 Unterneh-

men 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 Liefe-

ranten 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 unter-

sucht.

Um in verteilten Umgebungen mit heterogenen Systemen und verschie-

denen Produktmodellen Produktdaten auszutauschen, muss ein einheitli-

ches Austauschformat eingesetzt werden, so dass nicht an jeder Schnitt-

stelle 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

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 Anwendungsproto-

kolle 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 Automo-

bilindustrie - 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 Produktda-

ten 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än-

gig, 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

10303-28 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

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 CORBA-

kompatible und -basierte Schnittstelle dar.

Eine weitere Möglichkeit zum Datenaustausch ist der Aufbau einer

verteilten Datenbank, welche die Produktdaten enthält. Aus einer Daten-

modellbeschreibung in EXPRESS (ISO 10303-11) lässt sich ein Daten-

bank-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 Plat-

form, 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 plattfor-

munabhängiges Modell in UML ab. Dieses Modell wird um Verhalten

erweitert, so dass Anwendungsfälle aus dem PDTnet-Projekt sowie der

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 Aus-

tausch 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 Rahmenbe-

dingungen 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

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 Propo-

sal-Ressource veröffentlichen. Des Weiteren sind Ressourcen vorgese-

hen, 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.

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 Be-

richte 1497, Beschleunigung der Produktentwicklung durch EDM /

PDM- und Feature-Technologie, München, 1999, S. 3 - 24

[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 inter-

nationaler Produktdatennormen e.V., Darmstadt, 2001

[CHTC 02] Chtcherbina, E. et al.: Peer to Peer in Theorie und Praxis,

erschienen in: Javaspektrum, 4/2002, S. 23 – 28

[CONT 02] Contero, M. et al.: Product Data Quality and Collaborative

Engineering, erschienen in: IEEE Computer Graphics and Applica-

tions, Mai/Juni 2002, S. 32 – 42

[CYON 06] Cyon Research Corporation: The Business Case for a Com-

mon Data Distribution Platform: A Look at UGS’ JT, Bethesda

(USA), 2006

122

[DOBL 98] Doblies, M.: Globales Produktdatenmanagement zur Verbes-

serung der Produktentwicklung, Berichte aus dem Produktionstech-

nischen Zentrum Berlin, 1998

[DOMA 00] Domazet, D. et al.: An Infrastructure for Inter-Organizational

Collaborative Product Development, Proceedings of the 33rd 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 Soft-

ware, 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 Collabora-

tive Engineering, Daimler Chrysler Research

[GOLT 02] Goltz, M.; Müller, D.: PDM/PLM – Verwaltung von Produktda-

ten ohne Grenzen !?, Institut für Maschinenwesen, TU Clausthal,

Institutsmitteilung Nr. 27, 2002, S. 59 - 67

[HOEH 06] Höhne, E.: Versionierungs- und Synchronisationskonzepte für

dezentrale Produktdatenbanken, Institut für Informatik, TU Claus-

thal, 2006

[IPC2571] IPC: IPC-2571, Generic Requirements for Electronics Manufac-

turing Supply Chain Communication – Product Data eXchange

(PDX), Bannockburn (USA), 2001

123

[IPC2576] IPC: IPC-2576, Sectional Requirements for Electronics Manu-

facturing 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 Pro-

duktmodell 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

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 Fertigungsin-

dustrie: 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 Para-

digm 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 Claust-

hal, 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 Produktentwick-

lung, Einführung und Wirtschaftlichkeit von EDM/PDM-Systemen,

Düsseldorf, 2002

125

[PDMC 03] Verbundprojekt PDM-Collaborator: Unternehmensübergreifen-

de 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. 13 - 16

126

Internetquellen

http://webstds.ipc.org/

http://www.3ds.com/de/

http://www.baumaschine.de/

http://www.campuscontent.de/

http://www.cimdata.com/

http://www.edmpdm.de/

http://www.elektronik-kompendium.de/

http://www.jtopen.com/

http://www.know-library.net/

http://www.netplanet.org/

http://www.pdm-produktiv.de/

http://www.pdm-if.org/

http://www.pdtec.de/

http://www.plmportal.de/

http://www.prostep.org/

http://www.siconvision.com/

http://www.t-online.de/

http://www.ugsplm.de/

http://www.woxikon.de/

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

128

Screenshot 3: Artikelliste des LEGO®-Hauses in Eigner PLM 5.0

Screenshot 4: Stückliste in der Browseransicht des Eigner PLM 5.0

129

Screenshot 5: Strukturauflösung des LEGO®-Hauses in Eigner PLM 5.0

Screenshot 6: Anlegen eines "gespeicherten Dokuments" in Eigner PLM 5.0

130

Screenshot 7: Das Dokument kann nun mittels Check-Out reserviert werden

Screenshot 8: Das Projekt "Rohbau" ist ein Unterprojekt des Projekts "Hausbau"

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

132

Screenshot 11: Bildung von Klassen und Übersicht über eine mögliche Klassenhierarchie

Screenshot 12: Die LEGO®-Steine bekommen Klassifizierungsmerkmale

133

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

134

Screenshot 14: Neuer Workflow im Workflow-Editor

135

Anhang B – Screenshots Agile Advantage 2006

Screenshot 15: Agile Administrator Oberfläche

Screenshot 16: Anlegen eines neuen Benutzers mit dem Agile Administrator

136

Screenshot 17: Startbildschirm eines Agile Advantage 2006 Benutzers

Screenshot 18: Neues Teil "LEGO®-Stein 2x2" anlegen

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

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

139

Screenshot 23: Neuer Change, welcher dem Dachziegel zugeordnet wurde

140

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

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

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

143

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

144

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

145

Anhang C – Erklärung

E R K L Ä R U N G

Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig verfasst

und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt

habe, dass alle Stellen der Arbeit, die wörtlich oder sinngemäß aus

anderen Quellen übernommen wurden, als solche kenntlich gemacht sind,

und dass die Arbeit in gleicher oder ähnlicher Form noch keiner Prüfungs-

behörde vorgelegt wurde.

Düsseldorf, 12. Februar 2007

Sonja Schäfer

146

Anlagen

CD: Anlagen zur Diplomarbeit_Sonja Schäfer 2007

Unterstützung von Prozessen des Produktdatenmanagements ...

Documents

Transcript of Unterstützung von Prozessen des Produktdatenmanagements ...