Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine...

235
Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades Doktor-Ingenieur der Fakultät für Maschinenbau der Ruhr-Universität Bochum von Dipl.-Ing. Fahmi Bellalouna aus Paris (Frankreich) Bochum 2009

Transcript of Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine...

Page 1: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Integrationsplattform für eine interdisziplinäre Entwicklung

mechatronischer Produkte

Dissertation

zur Erlangung des Grades

Doktor-Ingenieur

der

Fakultät für Maschinenbau

der Ruhr-Universität Bochum

von

Dipl.-Ing. Fahmi Bellalouna

aus Paris (Frankreich)

Bochum 2009

Page 2: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades
Page 3: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Dissertation eingereicht: 21.04.2009

Tag der mündlichen Prüfung: 03.07.2009

Erster Referent: Prof. Dr.-Ing. M. Abramovici

Zweiter Referent: Prof. Dr.-Ing. R. Anderl

Page 4: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades
Page 5: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Inhalt I

Inhalt

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

1.1 Problemanalyse ............................................................................................. 3

1.1.1 Prozessbezogene Probleme .............................................................. 3

1.1.2 Datenbezogene Probleme ................................................................. 5

1.1.3 PLM-System-bezogene Probleme ..................................................... 6

1.2 Zielsetzung ..................................................................................................... 7

1.3 Vorgehensweise ............................................................................................. 9

2 Grundlagen und Begriffsabgrenzung ............................................. 12

2.1 Begriffsbestimmung ..................................................................................... 12

2.2 Mechatronische Systeme ............................................................................. 13

2.2.1 Definition der Mechatronik ............................................................... 13

2.2.2 Mechatronische Domänen ............................................................... 14

2.2.3 Aufbau eines mechatronischen Systems ......................................... 15

2.2.4 Modularisierung eines mechatronischen Systems ........................... 17

2.2.5 Innovationspotenziale der Mechatronik ........................................... 18

2.3 Interdisziplinäre Methodik zur Entwicklung mechatronischer Systeme nach VDI 2206 .............................................................................................................. 20

2.3.1 Problemlösungszyklus auf der Mikroebene ..................................... 20

2.3.2 V-Modell der Makroebene ............................................................... 22

2.3.3 Prozessbausteine ............................................................................ 24

2.4 Methodische Ansätze zur Konzipierung mechatronischer Systeme ............. 25

2.4.1 Systemtechnik ................................................................................. 25

2.4.2 Funktionsorientierte Vorgehensweise .............................................. 26

2.4.3 Partitionierung mechatronischer Systeme ....................................... 27

3 Anforderungsanalyse ...................................................................... 29

3.1 Prozessbezogene Anforderungen ................................................................ 30

3.1.1 Unterstützung einer interdisziplinären, funktionsorientierten Entwicklungsmethodik .................................................................................. 30

3.1.2 Synchronisation der domänenspezifischen Entwicklungsprozesse . 31

3.2 Datenbezogene Anforderungen ................................................................... 32

Page 6: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

II Inhalt

3.3 PLM-Systemlandschaft-bezogene Anforderungen ....................................... 34

3.3.1 Interdisziplinarität ............................................................................. 34

3.3.2 Schutz bestehender IT-Investitionen ................................................ 34

3.3.3 Flexibilität ......................................................................................... 34

4 Stand der Forschung und der Technik ........................................... 36

4.1 Allgemeine IT-Integrationsansätze ............................................................... 36

4.1.1 Proprietäre Punkt-zu-Punkt Schnittstellen ........................................ 37

4.1.2 Standard-Datenmodelle ................................................................... 38

4.1.3 Data Warehouse .............................................................................. 39

4.1.4 Single IT-Systeme ............................................................................ 41

4.1.5 Enterprise Application Integration (EAI) ........................................... 45

4.1.6 Semantische Technologie ................................................................ 49

4.1.7 Serviceorientierte Architektur (SOA) ................................................ 51

4.2 Produktdatenintegration ................................................................................ 56

4.2.1 STEP ................................................................................................ 57

4.2.2 STEP-PDM-Schema ........................................................................ 58

4.2.3 MechaSTEP ..................................................................................... 59

4.3 Funktionsintegration ..................................................................................... 61

4.3.1 PDM-Enablers .................................................................................. 61

4.3.2 OMG PLM Services .......................................................................... 62

4.4 Domänenspezifische PLM-Anwendungen .................................................... 63

4.4.1 PLM-Anwendungen innerhalb der Entwicklung mechanischer Produktkomponenten ................................................................................... 66

4.4.2 PLM-Anwendungen innerhalb der Entwicklung elektrotechnischer Produktkomponenten ................................................................................... 67

4.4.3 PLM-Anwendungen innerhalb der Entwicklung eingebetteter Softwaresysteme .......................................................................................... 69

4.5 Relevante Forschungsaktivitäten .................................................................. 71

4.5.1 iViP ................................................................................................... 71

4.5.2 PDM-Collaborator (PDM-C) ............................................................. 73

4.5.3 Mechasoft ......................................................................................... 75

4.5.4 EUMECH .......................................................................................... 76

4.5.5 VIVACE ............................................................................................ 77

4.5.6 MIKADO ........................................................................................... 79

Page 7: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung III

4.5.7 Web-basierte föderierte PDM-Umgebung (Gerhard) ....................... 82

4.5.8 Föderatives Informationsmodell zur Systemintegration für die Entwicklung mechatronischer Produkte (Kleiner) ......................................... 83

4.5.9 Model Management and Integration Platform for Mechatronics Product Development (El-Khoury) ................................................................ 83

4.5.10 Föderatives PDM zur Verwaltung mechatronischer Systemstrukturen (Pham-Van) .................................................................................................. 85

4.5.11 Virtual Product Development Environment (Storga) ........................ 85

4.6 Bewertung des Standes der Technik und Forschung und resultierender Handlungsbedarf ................................................................................................. 87

4.6.1 Bewertung der allgemeinen IT-Integrationsansätze ......................... 87

4.6.2 Bewertung der Produktdatenintegrationsansätze ............................ 88

4.6.3 Bewertung der Funktionsintegrationsansätze .................................. 88

4.6.4 Bewertung der domänenspezifischen PLM-Anwendungen ............. 89

4.6.5 Bewertung der Forschungsaktivitäten .............................................. 90

4.6.6 Fazit und resultierender Handlungsbedarf ....................................... 91

5 Grundkonzept einer SOA-basierten Integrationsplattform .......... 94

5.1 Gesamtkonzept ............................................................................................ 94

5.2 Generische serviceorientierte Architektur .................................................... 97

5.2.1 Metamodell für die generische serviceorientierte Architektur ........ 101

5.2.2 Services ......................................................................................... 104

5.2.3 Nachrichten .................................................................................... 106

5.2.4 Workflow-Modellierung .................................................................. 106

5.2.5 SOA-Interaktionsschema ............................................................... 107

5.3 Vorgehensmodell zur Realisierung einer SOA-basierten Integrationsplattform für die Entwicklung mechatronischer Produkte .................................................. 109

6 Definition der interdisziplinären Use Cases für die mIP ............. 113

6.1 Entwurf eines mechatronischen Systems .................................................. 113

6.2 Domänenspezifischer Entwurf ................................................................... 120

6.3 Systemintegration ...................................................................................... 128

6.4 Iterative Vorgehensweise ........................................................................... 136

7 Konzipierung der mIP .................................................................... 141

7.1 Funktionalitäten der mIP ............................................................................ 141

7.2 Mechatronisches Meta-Datenmodell der mIP ............................................ 145

Page 8: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

IV Inhalt

8 Definition der SOA-Elemente für die mIP ..................................... 148

8.1 Definition der Workflows ............................................................................. 148

8.2 Definition der Services ................................................................................ 150

8.3 Definition des Registry- und Mediation-Moduls .......................................... 154

9 Web Service-basierte Konzeption der SOA-Elemente ................ 156

9.1 Web Service-basierte Konzeption der Services .......................................... 156

9.2 Web Service-basierte Modellierung der Workflows .................................... 158

9.2.1 BPEL-Prozess-Basiselemente ....................................................... 159

9.2.2 Funktionsprinzip einer BPEL-Prozesskomposition ......................... 159

9.2.3 Beispiel für die Komposition des Workflows „W_Release_Mechatronics_System“ ......................................................... 160

9.2.4 Beispiel für die Komposition des Workflows „W_Version_Mechatronics_System“ .......................................................... 165

10 Prototypische Realisierung ........................................................... 169

10.1 IT-Systemarchitektur................................................................................... 169

10.1.1 Teamcenter Engineering ................................................................ 170

10.1.2 ActiveBPEL Designer ..................................................................... 171

10.1.3 ActiveBPEL Engine ........................................................................ 171

10.1.4 Apache Tomcat Server ................................................................... 171

10.2 Funktionsweise der mechatronischen Integrationsplattform ....................... 171

10.2.1 Erweiterung des Standarddatenmodells von TC Engineering ........ 171

10.2.2 Erstellung einer logischen Systemarchitektur ................................. 172

10.2.3 Erstellung einer technischen Systemarchitektur ............................. 176

10.2.4 Erstellung einer E/E-Systemarchitektur .......................................... 178

10.2.5 Erstellung einer Software-, Hardware- bzw. mechanischen Systemarchitektur ....................................................................................... 179

10.2.6 Erstellung von Software-, Hardware- und E/E-Baseline sowie mechanischer Systemkonfiguration und mechatronischem Gesamtsystem180

11 Verifikation und Bewertung der Ergebnisse ................................ 182

11.1 Verifikation der prozessbezogenen Anforderungen .................................... 182

11.1.1 Verifikation der Anforderungen zur Ermöglichung einer interdisziplinären und funktionsorientierten Entwicklungsmethodik ............ 182

Page 9: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung V

11.1.2 Verifikation der Anforderungen zur Synchronisation der domänenspezifischen Entwicklungsprozesse ............................................ 183

11.2 Verifikation der datenbezogenen Anforderungen ....................................... 184

11.3 Verifikation der PLM-Systemlandschaft-bezogenen Anforderungen .......... 185

11.3.1 Verifikation der Anforderung an die Interdisziplinarität ................... 185

11.3.2 Verifikation der Anforderung zum Schützen bestehender IT-Investitionen ............................................................................................... 186

11.3.3 Verifikation der Anforderungen an die Flexibilität ........................... 187

12 Zusammenfassung und Ausblick ................................................. 188

12.1 Zusammenfassung der vorliegenden Arbeit ............................................... 188

12.2 Weitere Forschungspotenziale ................................................................... 190

13 Literaturverzeichnis ....................................................................... 192

14 Anhang ............................................................................................ 205

14.1 Elemente des Message Oriented Model .................................................... 205

14.2 Beschreibung der mIP-Funktionen ............................................................. 206

14.3 Mechatronisches Meta-Datenmodell .......................................................... 212

14.4 WS-BPEL ................................................................................................... 213

14.4.1 Struktur eines BPEL-Prozesses ..................................................... 213

14.4.2 BPEL-Aktivitäten ............................................................................ 213

14.5 Use Cases zur Freigabe interdisziplinärer Systeme ................................... 214

Page 10: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

VI Abbildungsverzeichnis

Abbildungsverzeichnis

Abbildung 1-1: Anteil der Disziplinen an der Produktwertschöpfung ......... 1

Abbildung 1-2: Verteilung der Pannenursachen im Automobil .................. 2

Abbildung 1-3: Stand der Prozessintegration innerhalb der mechatronischen Produktentwicklung ............................................ 4

Abbildung 1-4: Stand der Integration der domänenspezifischen PLM-Tools innerhalb der mechatronischen Produktentwicklung ........................ 7

Abbildung 1-5: Gliederung und Vorgehensweise der Arbeit ................... 10

Abbildung 2-1: Mechatronik – Synergie aus dem Zusammenwirken verschiedener Disziplinen .......................................................... 14

Abbildung 2-2: Grundstruktur eines mechatronischen Systems ............. 17

Abbildung 2-3: Beispiel für die Strukturierung mechatronischer Systeme ............................................................................................. 18

Abbildung 2-4: Problemlösungszyklus als Mikrozyklus .......................... 21

Abbildung 2-5: V-Modell als Makrozyklus ........................................... 23

Abbildung 2-6: Strukturierung eines Systems .................................... 26

Abbildung 2-7: Vorgehensleitfaden zur Partitionierung mechatronischer Systeme ................................................................................. 28

Abbildung 3-1: Notwendige Maßnahmen zur Beherrschung der Entwicklung mechatronischer Produkte ......................................................... 29

Abbildung 4-1: Entwicklungsschwerpunkte im Umfeld der IT-Integrationstechnologien ........................................................... 37

Abbildung 4-2: Schematischer Aufbau eines Data Warehouse ............... 41

Abbildung 4-3: Darstellung des Integrationsgedanken von CIM im Y-CIM-Modell .................................................................................... 42

Page 11: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung VII

Abbildung 4-4: ARIS-Haus ............................................................... 44

Abbildung 4-5: EAI-Referenzarchitektur ............................................. 46

Abbildung 4-6: Teilnehmer einer serviceorientierten Architektur ............ 54

Abbildung 4-7: Umfang und Inhalt des Datenmodells MechaSTEP .......... 60

Abbildung 4-8: PLM-Grundkonzept .................................................... 64

Abbildung 4-9: Heutiger Einsatz der domänenspezifischen PLM-Anwendungen innerhalb der Entwicklung mechatronischer Produkte an Hand des V-Modells VDI 2206 .................................................... 65

Abbildung 4-10: iViP-Systemarchitektur ............................................. 72

Abbildung 4-11: Schichtenmodell der PDMC-Architektur ....................... 74

Abbildung 4-12: Beschreibung der mechatronischen Komponente im Mechasoft-Metamodell .............................................................. 75

Abbildung 4-13: Architektur des VIVACE-EDM Frameworks .................. 78

Abbildung 4-14: MIKADO-Gesamtarchitektur ...................................... 79

Abbildung 4-15: Architektur der Mechatronik-Kooperationsplattform ..... 81

Abbildung 4-16: MDM-Plattform-Architektur ....................................... 84

Abbildung 4-17: CPDM Systemarchitektur ......................................... 86

Abbildung 5-1: Grundkonzept einer SOA-basierten Integrationsplattform . 96

Abbildung 5-2: Generische serviceorientierte Architektur .................... 98

Abbildung 5-3: Zuordnung der Komponenten des Grundkonzepts zu den Elementen der serviceorientierten Architektur ............................ 101

Abbildung 5-4: Metamodell für die serviceorientierte Architektur ........ 104

Abbildung 5-5: SOA-Interaktionsschema ........................................ 107

Page 12: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

VIII Abbildungsverzeichnis

Abbildung 5-6: Verwendung der Web Service-Technologie für die Implementierung der serviceorientierten Architektur ................... 112

Abbildung 6-1: Logische Systemarchitektur eines mechatronischen Produktes 114

Abbildung 6-2: Funktionspartitionierung zur Erstellung einer technischen Systemarchitektur eines mechatronischen Produktes ................... 115

Abbildung 6-3: Use Case „Erstellen einer logischen Systemarchitektur“.... 116

Abbildung 6-4: Ausschnitt einer logischen Systemarchitektur eines Fahrzeugs ...................................................................... 117

Abbildung 6-5: Use Case „Erstellen einer technischen Systemarchitektur“ 118

Abbildung 6-6: Ausschnitt einer technischen Architektur der logischen Funktion „Fahrzeug bei Kurvenfahrt stabilisieren“ als Regelkreis .. 119

Abbildung 6-7: Use Case „Erstellen einer E/E-Architektur“ .................. 121

Abbildung 6-8: Ausschnitt einer E/E-Architektur eines elektrischen Bremssystems ...................................................................... 123

Abbildung 6-9: Use Case „Erstellen einer Softwarearchitektur“ ............ 124

Abbildung 6-10: Ausschnitt einer ESP-Software-Systemarchitektur ..... 125

Abbildung 6-11: Use Case „Erstellen einer Hardware-Systemarchitektur“ ........................................................................................... 126

Abbildung 6-12: Ausschnitt einer ESP-Hardware-Systemarchitektur .... 126

Abbildung 6-13: Use Case „Erstellen einer mechanischen Systemarchitektur“ ................................................................. 127

Abbildung 6-14: Steuerung der mechanischen Bremssystemkomponente durch das ESP-System ........................................................... 128

Abbildung 6-15: Integration eines mechatronischen Systems .............. 129

Page 13: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung IX

Abbildung 6-16: Use Case „Erstellen einer Software-Baseline“ ............. 130

Abbildung 6-17: Software-Baseline eines ESP-Softwaresystems .......... 131

Abbildung 6-18: Use Case „Erstellen einer Hardware-Baseline“ ............ 131

Abbildung 6-19: Hardware-Baseline eines ESP-Hardwaresystems ........ 132

Abbildung 6-20: Use Case „Erstellen einer E/E-Baseline“ .................... 133

Abbildung 6-21: Use Case „Erstellen einer mechanischen Konfiguration“ ........................................................................................... 134

Abbildung 6-22: Mechanische Konfiguration eines Bremssystems ........ 135

Abbildung 6-23: Use Case „Erstellen eines mechatronischen Gesamtsystems“ .................................................................... 136

Abbildung 6-24: Iterativer Entwicklungsprozess mechatronischer Produkte ........................................................................................... 138

Abbildung 6-25: Use Case „Versionierung eines interdisziplinären Systems“ ........................................................................................... 139

Abbildung 6-26: Use Case „Freigabe eines E/E-Gesamtsystems“ .......... 140

Abbildung 7-1: Mechatronisches Meta-Datenmodell ........................... 147

Abbildung 8-1: Funktionsweise eines Web Service Gateway ............... 151

Abbildung 8-2: Funktionsweise von Registry- und Mediation-Modul ...... 155

Abbildung 9-1: Struktur eines Service ............................................. 157

Abbildung 9-2: WSDL-Beschreibung des Service „S_Get_Release_Status_Microcontroller“ ................................... 158

Abbildung 9-3: Funktionsprinzip einer BPEL-Komposition .................... 160

Abbildung 9-4: Workflow „W_Release_Mechatronics_System” ............. 161

Abbildung 9-5: Ausschnitt eines BPEL-Prozesses für „W_Release_Mechatronics_System“ .......................................... 164

Page 14: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

X Abbildungsverzeichnis

Abbildung 9-6: Auszug aus dem BPEL-Code für „W_Release_Mechatronics_System“ .......................................... 165

Abbildung 9-7: Workflow „W_Version_Mechatronics_System” ............. 166

Abbildung 9-8: BPEL-Prozess für „W_Version_Mechatronics_System“ ... 167

Abbildung 9-9: Auszug aus dem BPEL-Code für das „W_Version_Mechatronics_System“ .......................................... 168

Abbildung 10-1: IT-Architektur der prototypischen mechatronischen Integrationsplattform .............................................................. 170

Abbildung 10-2: Implementierung des mechatronischen Meta-Datenmodells in TC-Engineering ............................................... 172

Abbildung 10-3: Erstellen von Systemen und logischen Funktionen ...... 173

Abbildung 10-4: Erstellung einer hierarchischen Beziehung zwischen zwei Systemen (Fahrzeug und Antriebsstrang) .................................. 173

Abbildung 10-5: Erstellung einer funktionalen Beziehung zwischen logischen Funktionen (1/2) ...................................................... 174

Abbildung 10-6: Erstellung einer funktionalen Beziehung zwischen zwei logischen Funktionen (2/2) ...................................................... 174

Abbildung 10-7: Darstellung der funktionalen Abhängigkeiten zwischen zwei logischen Funktionen ....................................................... 175

Abbildung 10-8: Logische Architektur des elektrischen Bremssystems .. 175

Abbildung 10-9: Regelkreis der logischen Funktion „Fahrzeugstabilisierung bei Kurvenfahrt“ .................................................................... 176

Abbildung 10-10: Partitionierung einer logischen Funktion (1/2) .......... 177

Abbildung 10-11: Partitionierung einer logischen Funktion (2/2) .......... 177

Abbildung 10-12: Darstellung von Informationen zur funktionalen Partitionierung ....................................................................... 178

Page 15: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung XI

Abbildung 10-13: E/E-Systemarchitektur der Funktion „Ermittlung des Sollverhaltens des Fahrzeugs“ .................................................. 179

Abbildung 10-14: Software- und Hardware-Systemarchitektur ............ 179

Abbildung 10-15: Partitionierung von Software-Systemfunktionen ....... 180

Abbildung 10-16: Erstellung einer Software-Baseline ......................... 181

Abbildung 14-1: Referenzmodell für das Message Oriented Model ........ 205

Abbildung 14-2: Mechatronisches Meta-Datenmodell ......................... 212

Abbildung 14-3: Struktur eines BPEL-Prozesses ................................ 213

Abbildung 14-4: Use Case „Freigabe eines mechanischen Gesamtsystems“ ........................................................................................... 215

Abbildung 14-5: Use Case „Freigabe eines gesamten Hardwaresystems“ ........................................................................................... 215

Abbildung 14-6: Use Case „Freigabe eines gesamten Softwaresystems“ 215

Abbildung 14-7: Use Case „Freigabe eines mechatronischen Gesamtsystems“ .................................................................... 216

Page 16: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

XII Tabellenverzeichnis

Tabellenverzeichnis

Tabelle 4-1 Wichtigste Komponenten eines Data Warehause ............. 40

Tabelle 4-2 EAI-Schichten ............................................................ 46

Tabelle 4-3 Grundprinzipien einer serviceorientierten Architektur ....... 53

Tabelle 4-4 Beschreibung der Teilnehmer einer serviceorientierten Architektur .............................................................................. 54

Tabelle 4-5 Überblick über die STEP-Serien ..................................... 58

Tabelle 4-6 „Units of Functionalities“ für das PDM-Schema ................ 59

Tabelle 4-7 Hauptmodule des PDM-Enablers Standards .................... 62

Tabelle 4-8: Beschreibung der PLM-Methoden .................................. 64

Tabelle 4-9: Bewertung der IT-Integrationstechnologien .................... 88

Tabelle 4-10: Bewertung der Produktdatenintegrationsansätze ........... 88

Tabelle 4-11: Bewertung der Funktionsintegrationsansätze ................... 89

Tabelle 4-12: Bewertung der domänenspezifischen PLM-Anwendungen 90

Tabelle 4-13: Bewertung der Forschungsprojekte ............................. 91

Tabelle 7-1: Funktionen der mechatronischen Integrationsplattform .. 145

Tabelle 8-1: Klassifizierung der mIP-Workflows .............................. 149

Tabelle 8-2: Services für die Workflows und mIP-Funktionen ............ 152

Tabelle 9-1: Die notwendigen Services für das Workflow „W_Release_Mechatronics_System“ .......................................... 162

Tabelle 11-1: Verifikation der Anforderungen zur Ermöglichung einer interdisziplinären und funktionsorientierten Entwicklungsmethodik 183

Tabelle 11-2: Verifikation der Anforderungen zur Synchronisation der domänenspezifischen Entwicklungsprozesse ............................... 184

Page 17: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung XIII

Tabelle 11-3: Verifikation der datenbezogenen Anforderungen ........... 185

Tabelle 11-4: Verifikation der Anforderung an die Interdisziplinarität .. 186

Tabelle 11-5: Verifikation der Anforderung zum Schützen bestehender IT-Investitionen ......................................................................... 187

Tabelle 11-6: Verifikation der Anforderungen an die Flexibilität .......... 187

Tabelle 14-1: Beschreibung der mIP-Funktionen ............................... 211

Page 18: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades
Page 19: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung 1

1 Einleitung

„Ein hochintelligenter Bildsensor erkennt das Verkehrszeichen Geschwindigkeitsbegrenzung nach einer blitzschnellen Verarbeitung, gibt die Information an das Bremssteuergerät und das Motormanagementsystem weiter. Die aktuelle Höchstgeschwindigkeit wird dem Fahrer über ein Head-Up-Display angezeigt, das Fahrzeug wird automatisch und sanft auf das aktuelle Tempolimit abgebremst und das Tempolimit wird automatisch durch den Tempomat als Wunschgeschwindigkeit übernommen.“ Durch zunehmende Einbringung sowie die intelligen-te Integration von Lösungsprinzipien aus den Domänen Elektrotechnik und Informationstech-nik in die Mechanik-dominierten Produkte könnten dieses intelligente System „videobasiertes Fahrerassistenzsystem“ und weitere hochintelligente Funktionen in den nächsten Jahren selbstverständlich sein. Eine aktuelle Studie der Sendler\Circle1 [Send2008] innerhalb der Fertigungsindustrie besagt, dass der Anteil von E-Technik, Elektronik und Software an der Wertschöpfung der Produkte die reine Mechanik bereits auf ein Drittel zurück drängt (Abbil-dung 1-1), und das, obwohl die Studie ihren Schwerpunkt keineswegs im Hightechbereich hat.

23,5

39,5

37

0 10 20 30 40 50

Software

E/E (Elektrik/Elektronik)

Mechanik

Anteil in %

Abbildung 1-1: Anteil der Disziplinen an der Produktwertschöpfung [Send2008]

Mechatronik – das synergetische Zusammenspiel der Domänen Mechanik, Elektrotechnik und Informationstechnik – ermöglicht die Ausschöpfung von hohen Innovationspotenzialen; nicht

1 Sendler\Circle: http://www.sendlercircle.com/

Page 20: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

2 Einleitung

nur für den Technologievorreiter Automobilbau, sondern auch im Maschinenbau und in art-verwandten Branchen. Beispielsweise geht der VDA2 davon aus, dass rund 90% der zukünfti-gen Innovationen im Automobil auf mechatronischen Systemen basieren werden [VDA2005]. Es wird erwartet, dass die mechatronischen Systeme der nächsten Generationen sich mithilfe komplexer Software intelligent verhalten und selbstständig ihr Verhalten durch Bildung von Gemeinschaften autonomer Agenten verbessern können. Durch ihre inhärente Intelligenz be-stimmen diese Systeme dabei autonom neue oder auch veränderte Ziele und führen nachfol-gend entsprechende Verhaltensanpassungen durch [FGMO2007]. Diese neuen Systeme wer-den auch als Smart Produkte bezeichnet.

Mit den neuen Produktinnovationen hat die Mechatronik zu einer steigenden Systemkomplexi-tät geführt, welche zusätzlich mit kürzeren Entwicklungszeiten und wachsendem Kostendruck gepaart ist, was zur Folge hat, dass die Entwicklungsrisiken derartiger Systeme erheblich ge-stiegen sind, wie beispielsweise die Pannenstatistiken des ADAC (Abbildung 1-2) der letzten Jahre unmissverständlich zeigen. Ungefähr die Hälfte der Ausfallursachen in Automobilen ist auf die technischen Systeme, die eine hohe Integration von mechanischen, elektrotechnischen und informationstechnischen Komponenten aufweisen, zurückzuführen. Untersuchungen in diesem Zusammenhang haben gezeigt, dass ca. 80% dieser Ausfälle ihren Ursprung in der Produktentwicklungsphase und insbesondere in der Entwurfs- und Spezifikationsphase haben [Jaco2003].

0102030405060708090

100

2001 2002 2003 2004 2005 2006 2007 2008

49,1 49,3 49,3 52 49,6 52,2 52,4 54

10,6 10,6 10,1 9 7,7 7,9 7,8 86,7 6,7 6,9 7

6,2 6,7 7,1 75,8 5,8 6 6

66,6 6,8 8

27,8 27,6 27,7 26 30,5 26,6 25,9 23

Ant

eile

an

den

Pann

en (%

)

Jahr

Verteilung der Pannenursachen im Automobil

Sonstige Störungsursachen

Einspritzanlage

Räder/Reifen

Motor

Mechatronische Systeme

Abbildung 1-2: Verteilung der Pannenursachen im Automobil nach [ADAC2009]

2 VDA: Verband der Automobilindustrie

Page 21: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung 3

1.1 Problemanalyse

Komplexe mechatronische Produkte, die durch die Kombination und Integration von Lö-sungsprinzipien aus den Ingenieursdisziplinen Mechanik, Elektrotechnik und Informations-technik entstehen, haben automatisch zu einer zunehmenden Erhöhung der Komplexität von Entwicklungsmethoden, -prozessen sowie den dabei angewandten IT-Werkzeugen und anfal-lenden Produktdaten geführt.

In Anbetracht dieser Tendenz werden viele Unternehmen mit immer neuen Problemen konf-rontiert, was die Beherrschung der Entwicklung mechatronischer Produkte unter der Zielset-zung der Qualitätserhöhung sowie der Reduzierung der Entwicklungskosten und -zeit er-schwert.

Im Folgenden werden die Hauptprobleme innerhalb der Entwicklung mechatronischer Produk-te unter drei verschiedenen Gesichtspunkten analysiert:

• prozessbezogene Probleme, • datenbezogene Probleme und • PLM3-System-bezogene Probleme.

1.1.1 Prozessbezogene Probleme

Die Besonderheit mechatronischer Systeme besteht darin, dass deren Teilsysteme auf Basis unterschiedlicher technischer Lösungsprinzipien – Mechanik, Elektrotechnik, Informations-technik – miteinander verknüpft werden und durch das resultierende synergetische Zusam-menwirken Produktinnovationen erzielt werden [StRu2005]. Unter diesen multidisziplinären Rahmenbedingungen kommt den Entwicklungsprozessen bei der Realisierung derartiger Sys-teme eine wichtige Rolle zu.

Allerdings weisen die in den meisten Unternehmen etablierten Prozesse enorme Mängel hin-sichtlich der Beherrschung der domänenübergreifenden und interdisziplinären Entwicklungs-abläufe auf. Die Produktentwicklung mechatronischer Systeme erfolgt innerhalb der meisten Unternehmen (ca. 80%) wie eine Studie der Aberdeen Group zeigt (Abbildung 1-3) bislang getrennt und relativ isoliert in den involvierten Fachdisziplinen auf der Grundlage etablierter, spezifischer Entwicklungsmethoden und Vorgehensmodelle, die durch eigene Denkweisen, Begriffswelten und Erfahrungen geprägt sind [StBM2003].

3 PLM: Product Lifecycle Management (s. Kapitel 4.3)

Page 22: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

4 Einleitung

50% der Unternehmen

30% der Unternehmen

20% der Unternehmen

0%

10%

20%

30%

40%

50%

60%

Isolierte autonome domänenspezifische

Entwicklungsprozesse (Ohne domänenübergreifende

Koordination)

Isolierte autonome domänenspezifische

Entwicklungsprozesse (Teilweise

domänenübergreifende Koordination)

Integrierte, domänenübergreifende Entwicklungsprozesse

Abbildung 1-3: Stand der Prozessintegration innerhalb der mechatronischen Produktentwick-lung [ABER2006]

Diese Situation hat zur Folge, dass

eine Betrachtung des Produkts als integriertes, mechatronisches Gesamtsystem insbe-sondere in den frühen Entwicklungsphasen nicht möglich ist.

komplexe Zusammenhänge, Interaktionen und Wechselwirkungen zwischen den ver-schiedenen Fachdisziplinen erst in einer späteren Entwicklungsphase in Betracht gezo-gen werden können [Adms2004]. Die Folge ist die Entwicklung fehlerhafter Produkte, die erst nach mehreren Entwicklungsschleifen optimiert werden können.

ein gemeinsames Verständnis für Probleme und Aufgaben über alle Domänen nicht ausreichend unterstützt wird.

Steuerung, Koordination und Abstimmung der Entwicklungsprozesse, -abläufe, -auf-gaben sowie deren Ergebnisse über alle Domänen unzureichend unterstützt werden. Da-durch ist eine frühzeitige Qualitätsabsicherung sowie ein Zuverlässigkeitsnachweis des zu entwickelnden Produkts nicht möglich.

Teile des Produkts getrennt voneinander in den jeweiligen Fachbereichen entwickelt und deren Schnittstellen nicht ausreichend miteinander abgestimmt werden. Die Folgen sind nicht kompatible Schnittstellen und Teilsysteme, die nicht zu einem funktionsfähi-gen Gesamtsystem zusammengeführt werden können [GaFr2006].

eine domänenübergreifende Anwendung einer durchgängigen, interdisziplinären Ent-wicklungsmethodik, die die besonderen Bedürfnisse der Mechatronik berücksichtigt, nicht möglich ist.

Page 23: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung 5

ein domänenübergreifendes Integrations-, Konfigurations-, Änderungs- und Freigabe-management wenig bzw. kaum unterstützt wird.

die Integration der domänenspezifischen Entwicklungsergebnisse erst in den Erpro-bungsphasen des Produkts erfolgen kann, da eine frühzeitige digitale Gesamtintegration und -absicherung der Entwicklungsergebnisse nicht zweckmäßig durchgeführt werden kann.

In den letzten Jahren wurden zahlreiche Forschungs- und Industrieprojekte durchgeführt, um eine integrierte und interdisziplinäre mechatronische Produktentwicklung unter Berücksichti-gung der Domänen Mechanik, Elektrotechnik und Informationstechnik zu ermöglichen. Das Resultat dieser Bemühungen ist die Entstehung einer Reihe von methodischen Ansätzen, wie beispielsweise die VDI-Richtlinie 2206 „Entwicklungsmethodik für mechatronische Systeme“ und das 3-Ebenen-Modell zur prozessualen Integration der verschiedenen Entwicklungsdomä-nen auf einer interdisziplinären Ebene.

Allerdings trifft die Einführung derartiger Ansätze in der Praxis auf große Probleme, insbe-sondere im Hinblick auf die Heterogenität der Daten- und PLM-Systemlandschaft, die einen effizienten Einsatz dieser Methoden und Modelle zur Optimierung der Entwicklungsprozesse mechatronischer Produkte kaum möglich macht.

1.1.2 Datenbezogene Probleme

Für die Unterstützung der Entwicklung mechatronischer Systeme haben sich über die Jahre zahlreiche domänenspezifische rechnergestützte Werkzeuge wie z. B. MCAx4, ECAx5, CASE6 innerhalb von Unternehmen etabliert. Diese erzeugen eine große Menge heterogener Produkt-daten und Produktstrukturen, die in verschiedenen nicht zueinander kompatiblen Formaten und Strukturen vorliegen [AnKr1999]. Beispielsweise werden heute MCAx-Daten in PDM7-Systeme, ECAx-Daten in EES8-Systeme und CASE-Daten in SCM9-Systeme abgelegt und dort verwaltet, die jeweils ihre eigenen spezifischen Datenmodelle (z. B. die Datenmodelle AP 20410 und AP 21211 des STEP-Standards12 für PDM- bzw. EES-Systeme und CASE-Tools-spezifische Datenmodelle für SCM-Systeme) haben [AbBe2007]. Diese große Vielfäl-

4 MCAx: Computer Aided Systeme für die Mechanik-Konstruktion 5 ECAx: Computer Aided Systeme für die Elektrik/Elektronik-Konstruktion 6 CASE: Computer Aided Software Engineering 7 PDM: Product Data Management (vgl. Abschnitt 4.3.1) 8 EES: Electrical Engineering Solution (vgl. Abschnitt 4.3.2) 9 SCM: Software Configuration Management (vgl. Abschnitt 4.3.3) 10 AP 204: STEP-Anwendungsprotokoll (Core data for automotive mechanical design processes) 11 AP 212: STEP-Anwendungsprotokoll (Electrotechnical Design and Installation) 12 STEP: Standard for the Exchange of Product Model Data (vgl. Abschnitt 4.2.1)

Page 24: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

6 Einleitung

tigkeit an Produktdaten, Datenmodellen und Datenformaten hat enorme Probleme bei der Entwicklung mechatronischer Systeme verursacht:

Eine ganzheitliche und interdisziplinäre System-, Funktions- und Komponentenbe-schreibung der mechatronischen Produkte kann nicht dargestellt, nachvollzogen und bedarfsgerecht hergestellt werden.

Interdisziplinäre und funktionale Zusammenhänge zwischen den verschiedenen Kom-ponenten und Systemen können nicht zielgerecht abgebildet, dargestellt und verstanden werden.

Interdisziplinäre Verhalten von Komponenten, Systeme und Funktionen bei gegenseiti-ger Abhängigkeit können nicht ausreichend dargestellt und erforscht werden.

Die Vielzahl der gegenseitigen vernetzten Forderungen und Restriktionen zwischen den Systemen, Funktionen und Komponenten kann nicht im Sinne einer „Multizieloptimie-rung“ erfüllt werden [Möhr2004].

Eine domänenübergreifende und durchgehende Nutzung von Produktdaten und Pro-duktstruktur ist heute nicht möglich [AnKF2000].

Es folgt eine redundante und teilweise inkonsistente Ablage von Produktdaten in ver-schiedenen Fachbereichen.

Eine domänenübergreifende und koordinierte Änderung an Produktdaten, Funktionen und Systemen, die aufeinander aufbauen, wird kaum unterstützt.

Eine domänenübergreifende Freigabe der Produktdaten sowie deren Funktionen, Sys-teme und Komponenten ist aufgrund des unterbrochenen Informationsflusses zwischen den verschiedenen Fachdisziplinen nur bedingt bzw. kaum möglich.

Eine domänenübergreifende Produktdatenkonfiguration ist nicht zweckmäßig durch-führbar.

1.1.3 PLM-System-bezogene Probleme

Innerhalb der Entwicklung mechatronischer Produkte stellen die domänenspezifischen PLM-Systeme den Dreh- und Angelpunkt für das Management und die Steuerung der Produktdaten und der Entwicklungsprozesse sowie für die Integration der verschiedenen IT-Werkzeuge dar.

Die PLM-Systeme, die heute in den Entwicklungsbereichen vieler Unternehmen vorzufinden sind, sind historisch gewachsen und spiegeln die vollzogenen organisatorischen und techni-schen Entwicklungen wider [Abra2007]. Dabei wurden viele Applikationen bzw. Funktionen sehr anwendungs- und bereichsspezifisch implementiert, ohne den Gesamtentwicklungspro-zess über alle Domänen und die zukünftige Entwicklung des Unternehmens zu betrachten.

Die klassische PLM-Systemlandschaft, die am häufigsten innerhalb eines Unternehmens an-zutreffen ist, ist heterogen und besteht meistens aus den drei verschiedenen inkompatiblen und

Page 25: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung 7

unabhängigen domänenspezifischen PLM-Systemen PDM, EES und SCM für die Bereiche Mechanik, Elektrotechnik bzw. Informationstechnik [AbBe2008]. Diese Systeme wurden innerhalb der meisten Unternehmen, wie eine Studie der Aberdeen Group zeigt, (Abbildung 1-4) als Insel-Lösungen eingeführt. Deren Integration beschränkt sich in der Regel – wenn sie überhaupt existiert – auf den einfachen Austausch von Metadaten, wie z. B. Teilesachnum-mern oder Änderungsindex, die vornehmlich einen logistischen Zweck haben.

68% der Unternehmen

29% der Unternehmen

3% der Unternehmen

0%

10%

20%

30%

40%

50%

60%

70%

80%

Isolierte domänenspezifische PLM-Tools

Isolierte Domänenspezifische PLM-Tools (Teilweise

integriert)

Vollintegrierte PLM-Tools

Abbildung 1-4: Stand der Integration der domänenspezifischen PLM-Tools innerhalb der me-chatronischen Produktentwicklung [ABER2006]

In Anbetracht dieser Situation kann heute ein interdisziplinäres und domänenübergreifendes Management und Steuern von Prozessen, Abläufen und Daten bei der Entwicklung von Pro-dukten unter mechatronischen Aspekten – Kombination und Integration von Lösungsprinzi-pien aus den Ingenieursdisziplinen Mechanik, Elektrotechnik und Informationstechnik – nur sehr bedingt durchgeführt werden.

1.2 Zielsetzung

Eine zielführende Entwicklung komplexer mechatronischer Produkte – die durch die synerge-tische Integration unterschiedlicher domänenspezifischer Lösungsprinzipien entstehen – unter den Rahmenbedingungen Zeit, Kosten und Qualität kann nur durch die Verwendung von interdisziplinären Entwicklungsmethoden erreicht werden. Jedoch setzt der Einsatz derartiger Methoden eine nahtlose Zusammenarbeit und Synchronisation der verschiedenen domänen-spezifischen Entwicklungsprozesse und der dabei zu verwendenden PLM-Anwendungen und zu handhabenden Entwicklungsdaten voraus.

Diese Arbeit hat zum Ziel, eine Interoperabilitätslösung zur Ermöglichung der Zusammenar-beit bzw. des Interagierens der verschiedenen heterogenen Entwicklungsprozesse, PLM-Anwendungen und Datenmodelle zu entwickeln. Die Hauptzielrichtungen dieser Lösung sind:

Page 26: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

8 Einleitung

1. Die Synchronisation und die Koordination der domänenspezifischen Entwick-lungsprozesse durch die Bereitstellung interdisziplinärer Synchronisationsmecha-nismen (wie z. B. interdisziplinäres Freigabe-, Änderungs- und Konfigurations-management), um interdisziplinäre Entwicklungsprozesse und -tätigkeiten durch-führen zu können.

2. Die Homogenisierung der verschiedenen domänenspezifischen Partialdatenmo-delle auf eine abstrakte, interdisziplinäre Ebene auf Basis eines mechatronischen Meta-Datenmodells, um eine interdisziplinäre Beschreibung und Handhabung von Produktkomponenten, -systemen und -funktionen sowie deren Beziehungen zu ermöglichen.

3. Eine prozessorientierte und flexible Anbindung der verschiedenen domänenspezi-fischen PLM-Anwendungen nach dem Prinzip der losen Kopplung13 zu ermögli-chen, um eine durchgängige Nutzung der PLM-anwendungsspezifischen Funktio-nen und Daten auf eine interdisziplinäre Ebene zur Ausführung von interdiszipli-nären Prozesstätigkeiten gewährleisten zu können.

Den Kern dieser Lösung stellt eine mechatronische Integrationsplattform (mIP) dar, die einen prozessorientierten Integrationsansatz auf Basis des SOA14-Paradigmas verfolgt. Durch die Umsetzung dieses Lösungsansatzes sollen die folgenden übergreifenden Ziele erreicht werden:

Effiziente Einführung und Anwendung von interdisziplinären Methoden zur Entwick-lung mechatronischer Produkte.

Effiziente Durchführung von interdisziplinären und funktionsorientierten Entwick-lungsprozessen mechatronischer Produkte.

Bessere Beherrschung der Heterogenität im Hinblick auf Prozesse, Daten und IT-Werkzeuge innerhalb mechatronischer Entwicklungsumgebung.

Integration von bereits bestehenden, etablierten domänenspezifischen Entwicklungspro-zessen und -abläufen in den gesamten mechatronischen Entwicklungsprozess mit mini-malem Aufwand.

Zielgerechte und schnelle Aufbringung und Bereitstellung von domänenspezifischen Produkt- sowie Prozessdaten und -informationen in den gesamten mechatronischen Entwicklungsprozess mit minimalem Aufwand.

Erhöhung der Flexibilität der PLM-Systemlandschaft aufgrund der losen Kopplung der domänenspezifischen PLM-Anwendungen und somit die Erhöhung der Unternehmens-agilität im Hinblick auf die Weiterentwicklung und Änderung von vorhandenen An-

13 Lose Kopplung: s. Abschnitt 4.1.7 14 Serviceorientierte Architektur (vgl. Abschnitt 4.1.7)

Page 27: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung 9

wendungen oder die Einführung von neuen Anwendungen.

Bewahrung bzw. Stärkung der internen Autorität und Freiheit der verschiedenen Do-mänen bezüglich der Weiterentwicklung ihrer internen Prozesse und Abläufe, damit die Innovationsfähigkeit der einzelnen Fachdomänen nicht unnötig eingeschränkt wird.

Im Sinne einer vereinfachten und idealisierten Betrachtung wird in dieser Arbeit davon ausge-gangen, dass innerhalb der Entwicklung mechatronischer Produkte die drei Hauptdomänen Mechanik, Elektrotechnik und Informationstechnik involviert sind, die ihre eigenen abge-grenzten und klar definierten domänenspezifischen Entwicklungsprozesse und Partialdaten-modelle haben. Die Verwaltung und die Steuerung dieser domänenspezifischen Entwick-lungsprozesse und -daten erfolgen in den jeweiligen Domänen durch die Verwendung spezia-lisierter, domänenspezifischer PLM-Anwendungen.

1.3 Vorgehensweise

Zur Realisierung der beschriebenen Ziele wird die in Abbildung 1-4 dargestellte Vorgehens-weise verfolgt. Die Abbildung zeigt zudem den Aufbau und die Gliederung der Arbeit.

Page 28: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

10 Einleitung

Begriffs-bestimmung

Mechatronische Systeme

Methoden zur Entwicklungmechatronischer Produkte

Grundlage und Begriffsabgrenzung

Prozessbezogen Datenbezogen PLM-System-bezogen

Anforderungsanalyse

Prototypische Realisierung und Validierung

Kapitel 2

Kapitel 3

Kapitel 4

Kapitel 10 / 11

IT-Integrations-technologien

Produktdaten-integration

DomänenspezifischenPLM-Anwendungen

Handlungsbedarf

Stand der Technik und ForschungFunktions-integration

Kapitel 5 Grundkonzept der SOA-basierten Integrationsplattform

Generische SOAGesamtkonzept Vorgehensmodell

Kapitel 6 / 7 Konzept der mechatronischen Integrationsplattform

Funktionen der mIP Föderiertes Datenmodell der mIP

Interdisziplinäre Use Case der mIP

Kapitel 8 / 9Definition der SOA-Elemente

SOA-Element für die mIP

WS-basierte Konzeption der SOA-Element

Abbildung 1-5: Gliederung und Vorgehensweise der Arbeit

Ausgehend von der in Kapitel 1 beschriebenen Problemstellung und Zielsetzung dieser Arbeit werden in Kapitel 2 zunächst die relevanten Begrifflichkeiten für mechatronische Produkte definiert und abgegrenzt sowie die wichtigsten Methoden zur Entwicklung mechatronischer Produkte vorgestellt.

In Kapitel 3 werden die Anforderungen im Hinblick auf Prozesse, Daten und PLM-Anwendungen formuliert und analysiert, um eine interdisziplinäre und integrierte Entwicklung mechatronischer Produkte effizient durchführen zu können.

Auf Basis der definierten Anforderungen wird in Kapitel 4 der Stand der Technik und For-schung untersucht und bewertet. IT-Integrationstechnologien und Integrationsansätze auf Pro-duktdaten- und Anwendungsfunktionsebene wurden ausführlich vorgestellt und im Hinblick auf ihre Potenziale als Interoperabilitätslösung innerhalb der Entwicklung mechatronischer Produkte diskutiert. Weiterhin werden die domänenspezifischen PLM-Anwendungen unter-sucht und ihre Eignung zur Unterstützung interdisziplinärer und funktionsorientierter Entwick-lungsprozesse und -aktivitäten diskutiert. Eine Übersicht der relevanten und aktuellen For-

Page 29: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Einleitung 11

schungsprojekte und eine Gesamtbewertung des Standes der Technik und der Forschung und der daraus resultierende Handlungsbedarf runden dieses Kapitel ab.

Aufbauend auf dem Handlungsbedarf wird in Kapitel 5 zunächst das Gesamtkonzept für eine SOA-basierte Integrationsplattform vorgestellt. Die notwendigen Elemente zur Realisierung des Gesamtkonzepts werden im Rahmen einer generischen serviceorientierten Architektur entworfen. Anschließend wird ein Vorgehensmodell, das die Realisierung einer mechatroni-schen Integrationsplattform auf Basis dieser generischen serviceorientierten Architektur be-schreibt, vorgestellt.

Im Kapitel 6 erfolgt die Analyse der mechatronischen Entwicklungsprozesse, um die interdis-ziplinären Use Cases für die mechatronische Integrationsplattform zu definieren. Zusätzlich werden die Use Cases durch ein Anwendungsbeispiel aus dem Automobilbereich „Entwick-lung eines elektronischen Bremssystems“ erläutert. Auf Basis dieser Use Cases werden in Ka-pitel 7 die Funktionalitäten und das Datenmodell der mechatronischen Integrationsplattform konzipiert.

Die Definition der SOA-Elemente ist Gegenstand des 8. Kapitels. Eine weitere Konzipierung der SOA-Elemente in Anlehnung an die Web Service-Technologie wird in Kapitel 9 durchge-führt. Kapitel 10 beschreibt die prototypische Umsetzung der entwickelten SOA-basierten mechatronischen Integrationsplattform. Hierzu wurde ein PDM-System als Basis für die Im-plementierung der Integrationsplattform-Funktionalitäten und –Datenmodell eingesetzt. Die Funktionsweise der prototypischen Implementierung wird anhand eines exemplarischen An-wendungsszenarios verdeutlicht.

In Kapitel 11 erfolgt eine Validierung der entwickelten SOA-basierten mechatronischen Inte-grationsplattform sowie der prototypischen Implementierung unter Berücksichtigung der in Kapitel 3 beschriebenen Anforderungen.

Page 30: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

12 Grundlagen und Begriffsabgrenzung

2 Grundlagen und Begriffsabgrenzung

In diesem Kapitel werden die wichtigsten Begriffe und Grundlagen zur interdisziplinären und integrierten Entwicklung mechatronischer Produkte erläutert. Dabei werden zunächst Schlüs-selbegriffe, die für diese Arbeit wichtig sind, definiert. Der Aufbau eines mechatronischen Systems stellt den Gegenstand des Kapitels 2.2 dar. Eine Methodik für die Entwicklung eines mechatronischen Systems sowie weitere methodische Ansätze zur Konzipierung und Model-lierung derartiger Systeme werden in Kapitel 2.3 bzw. 2.4 dargestellt.

2.1 Begriffsbestimmung

Im Folgenden wird eine Abgrenzung und Definition der relevanten Begrifflichkeiten in Bezug auf die vorliegende Arbeit vorgenommen.

Interdisziplinär

bezeichnet die Entwicklungsvorgehensweisen, -methoden, -prozesse, -aufgaben etc., die alle disziplinbezogene Aspekte, d. h. mechanische, elektrotechnische und informationstechnische Aspekte, eines mechatronischen Produkts und deren Wechselwirkungen gleichzeitig und gleichrangig auf einer abstrakten – domänenunabhängigen – Ebene betrachten. Hierbei wird das Produkt als integriertes mechatronisches Gesamtsystem behandelt.

Integriert/Integrativ

beinhaltet die Entwicklungsvorgehensweisen, -methoden etc., die sich insbesondere mit den integrativen Phasen des Produktentstehungsprozesses beschäftigen. Die integrativen Phasen sind diejenigen Phasen im mechatronischen Entstehungsprozess, die Aktivitäten zur Integrati-on der einzelnen domänenspezifischen Entwicklungsergebnisse – dies können auch Anforde-rungen, Spezifikationen etc. sein – zu einem realen oder virtuellen mechatronischen Gesamt-system umfassen.

Domänenübergreifend

bezeichnet die Entwicklungsvorgehensweise, -methoden, -prozesse, -aufgaben etc., deren Durchführung eine Kooperation, Koordination sowie die Synchronisation von mehreren do-mänenspezifischen Vorgehensweisen, Methoden, Prozessen, Aufgaben etc. erfordern.

Page 31: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundlagen und Begriffsabgrenzung 13

Domänenspezifisch

wiederum bezeichnet die Entwicklungsvorgehensweisen, -methoden, -ergebnisse, IT-Systeme etc., die in einer bestimmten mechatronischen Domäne (vgl. Abschnitt 2.2.2) entstanden und dort gebräuchlich sind [Möhr2004].

Interoperabilität

schließlich bedeutet die Fähigkeit unabhängiger, heterogener und domänenspezifischer Pro-zesse, Partialdatenmodelle, IT-Systeme sowie Organisationen, nahtlos zusammen zu arbeiten, um die Entstehung eines funktionsfähigen mechatronischen Gesamtsystems zu ermöglichen, ohne dass dazu gesonderte Absprachen – also gegenseitiges, detailliertes Wissen über interne funktionale und organisationale Abläufe – zwischen den Prozessen, Datenmodellen, IT-Systemen und Organisationen notwendig sind.

2.2 Mechatronische Systeme

2.2.1 Definition der Mechatronik

1969 prägte der Japaner K. Kikuchi, Präsident der YASKAWA Electric Corporation, den Be-griff Mechatronics (deutsch Mechatronik) [HaTF1996]. Dabei setzte sich das Wort Mechat-ronik aus den zunächst ausschließlich betroffenen zwei Fachdisziplinen Mechanik und Elekt-ronik zusammen. Mit dem Aufkommen der Mikroelektronik kam die Informationstechnik als weiterer Bestandteil der Mechatronik hinzu [Schw1989]. Nach heutigem Verständnis stellen mechatronische Systeme das synergetische Ergebnis der klassischen Ingenieurwissenschaften Maschinenbau, Elektrotechnik und Informationstechnik sowie ihrer Entstehungsprozesse (d. h. Entwicklung, Absicherung und Fertigung) dar.

Durch den Einbezug der modernen Informationstechnik wird erwartet, dass mechatronische Systeme zukünftig mit mehr Intelligenz ausgestattet werden können und somit die Entstehung von anpassungsfähigen Systemen, Smart Systems, ermöglichen. Diese Systeme sind in der Lage, auf Veränderungen ihrer Umgebung zu reagieren, kritische Betriebszustände zu erken-nen und Abläufe, die nur schwer steuerbar sind, durch Einsatz der Regelungstechnik zu opti-mieren [VDI2206].

Der Begriff Mechatronik hat im Laufe der Zeit aufgrund der ständigen Technologieerweite-rung unterschiedliche Definitionen erfahren und wird in der Literatur uneinheitlich verwendet. Diese Arbeit wird sich an der Definition von Schweitzer [Schw1989] orientieren:

Mechatronik ist ein interdisziplinäres Gebiet der Ingenieurwissenschaften, das auf den Grundlagen der klassischen Disziplinen Mechanik, Elektrotechnik und Informatik auf-baut (Abbildung 2-1). Ein typisches mechatronisches System nimmt Signale auf, verar-beitet sie und gibt Signale aus, die es z. B. in Kräfte und Bewegungen umsetzt.

Page 32: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

14 Grundlagen und Begriffsabgrenzung

Mechanik

Mechatronik

Abbildung 2-1: Mechatronik – Synergie aus dem Zusammenwirken verschiedener Disziplinen [Iser1999]

2.2.2 Mechatronische Domänen

Mechanik

Der Begriff Mechanik bezeichnet im engeren Sinn ein Teilgebiet der klassischen Physik, des-sen Aufgabe darin besteht, die Bewegungsabläufe von Massen mithilfe von Naturgesetzen zu erklären und mathematisch zu beschreiben. Im Rahmen dieser Arbeit wird dieser Begriff in einem erweiterten Sinne zur Bezeichnung einer Domäne der Mechatronik verwendet, deren Aufgabe in der Entwicklung der mechanischen Bestandteile eines mechatronischen Systems besteht, indem Gestalt, Material und Anordnung der das mechatronische System repräsentie-renden Körper festgelegt werden. Die Domäne Mechanik widmet sich somit all jenen Funk-tionen des mechatronischen Systems, die unter Nutzung mechanischer Gesetzmäßigkeiten realisiert werden sollen. Dies umfasst sowohl bewegte Komponenten, die eine mechanische Leistung übertragen oder zugeführt bekommen, als auch ruhende Teilsysteme, die nicht unmit-telbar am Leistungsfluss beteiligt sind und eher passive Funktionen wie Lagerungs-, Stütz- oder Gehäuseaufgaben übernehmen [Jans2006].

Die technischen Gebiete Hydraulik und Pneumatik, die auf einer kombinierten Nutzung fest-körper- und fluidmechanischer Effekte basieren, können daher ebenfalls der mechanischen Domäne zugeordnet werden.

Elektrotechnik

Die Domäne Elektrotechnik widmet sich jenen Teilfunktionen eines mechatronischen Sys-tems, zu deren Erfüllung auf die physikalischen Gesetzmäßigkeiten der Elektrodynamik zu-rückgegriffen wird. Grundsätzlich werden dabei die Eigenschaften elektrischer Ladungen und

Page 33: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundlagen und Begriffsabgrenzung 15

deren Wechselwirkungen mit elektrischen und magnetischen Feldern genutzt. Die Nutzung der Elektrizität zur Realisierung technischer Funktionen erfolgt durch die Verschaltung passiver und aktiver Bauteile, die jeweils definierte Übertragungseigenschaften besitzen. In Abhängig-keit davon, ob bei einem elektrischen Teilsystem der Energie- oder Informationsumsatz im Vordergrund steht, unterscheidet man zwischen Leistungs- und Signalelektronik. Darüber hi-naus lässt sich je nach Art der Informationsrepräsentation eine Unterteilung in Analog- und Digitalelektronik vornehmen [Jans2006].

Informationstechnik

Während bei den bisher betrachteten Domänen die gezielte Beeinflussung physikalischer Grö-ßen im Mittelpunkt steht, dienen diese bei der Informationstechnik lediglich als Träger des nicht-physikalischen Konstrukts Information. Da zur Informationsrepräsentation elektrische Signale genutzt werden, ist die Informationstechnik eng mit der Elektrotechnik verknüpft. Im Rahmen dieser Arbeit soll als Abgrenzungskriterium zwischen diesen beiden Domänen die Nähe zur physikalischen Ebene herangezogen werden. Während bei der Elektrotechnik ein unmittelbarer Bezug zu den physikalischen Größen gegeben ist, werden diese bei der Realisie-rung von Funktionen durch die informationstechnische Domäne nicht explizit betrachtet. Aus Sicht der Informationstechnik ist es eher zweitrangig, welche physikalischen Prinzipien ge-nutzt werden, um die erforderlichen arithmetisch-logischen Funktionen im technischen System abzubilden [Jans2006].

Eine weitgehende Entkopplung zwischen der funktionalen und der physikalischen Ebene ist bei den digitalen Bestandteilen der Informationsverarbeitung mechatronischer Systeme gege-ben. Daher werden in dieser Arbeit jene Funktionen, die mithilfe digitaler Signalverarbeitung realisiert werden, der Domäne Informationstechnik zugeordnet. Dies umfasst insbesondere die zum Betrieb des mechatronischen Systems erforderliche Software, aber auch die zugehörige programmierbare Hardware sowie nicht-programmierbare Logikbausteine, sofern nicht deren physikalische Eigenschaften, sondern die Funktionalität in Form von arithmetischen und logi-schen Operationen im Vordergrund steht. Wegen der engen Kopplung beider Disziplinen auf der physikalischen Ebene ist der Übergang von der informationstechnischen zur elektrotechni-schen Domäne auf der Hardwareseite fließend. Die Software hingegen lässt sich eindeutig der Informationstechnik zuordnen, auch wenn z. B. bei der Programmierung von Mikrocontrollern deren Hardwarefunktionalitäten und -eigenschaften berücksichtigt werden müssen [Jans2006].

2.2.3 Aufbau eines mechatronischen Systems

Nach VDI 2206 zeichnen sich mechatronische Systeme durch die funktionale und/oder räum-liche Integration von Sensoren, Aktoren (auch Aktuatoren genannt), Informationsverarbeitung und eines Grundsystems aus (Abbildung 2-2).

Page 34: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

16 Grundlagen und Begriffsabgrenzung

Bei dem Grundsystem handelt es sich in der Regel um eine mechanische, elektromechani-sche, hydraulische oder pneumatische Struktur bzw. eine Kombination aus diesen. Allgemein ist allerdings ein beliebiges physikalisches System als Grundsystem denkbar.

Aufgabe der Sensoren ist die Bestimmung von ausgewählten Zustandsgrößen des Grundsys-tems. Sensoren können dabei physisch Messwertaufnehmer oder aber reine Softwaresensoren (sogenannte „Beobachter“) sein. Die Sensoren liefern die Eingangsgrößen für die Informati-onsverarbeitung, die heute in den meisten Fällen digital mittels Mikroprozessoren erfolgt. Diese veranlasst die notwendigen Einwirkungen, um die Zustandsgrößen des Grundsystems in gewünschter Weise zu beeinflussen. Die Umsetzung der Einwirkungen erfolgt durch Aktoren direkt am Grundsystem. Oft wird die Informationsverarbeitung zusätzlich über ein Kommu-nikationssystem mit anderen Informationsverarbeitungseinheiten verbunden sein. Die Kom-munikation mit dem Menschen bzw. Systemanwender erfolgt ggf. über spezielle Mensch-Maschine-Schnittstellen [VDI2206], [Möhr2004].

Grundsätzlich lassen sich die Komponenten eines mechatronischen Systems (d. h. Grundsys-tem, Sensoren, Informationsverarbeitung und Aktoren) über Stoff-, Energie- oder Informati-onsflüsse kommunizieren [GaLü2000]:

Stoffflüsse: Stoffe, die Komponenten eines mechatronischen Systems miteinander ver-binden, sind z. B. feste Körper, Prüfgegenstände, Behandlungsobjekte, Gase oder Flüs-sigkeiten.

Energieflüsse: Unter Energie ist in diesem Zusammenhang jede Energieform zu ver-stehen, wie z. B. mechanische, thermische oder elektrische Energie, aber auch Größen wie Kraft oder Strom.

Informationsflüsse: Informationen, die zwischen den Komponenten mechatronischer Systeme ausgetauscht werden, sind beispielsweise Messgrößen, Steuerimpulse oder Da-ten.

Page 35: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundlagen und Begriffsabgrenzung 17

Aktoren

Grundsystem

Kommunikations-system

Mensch-Maschine-Schnittstelle

Informations-verarbeitung

Informations-verarbeitung Mensch

Leistungs-versorgung

Sensoren Umgebung

notwendige Einheitoptionale Einheit

Informationsf lussEnergief lussStof ffluss

Legende:

Grundsystem

Abbildung 2-2: Grundstruktur eines mechatronischen Systems [VDI2206]

2.2.4 Modularisierung eines mechatronischen Systems

Komplexe mechatronische Systeme bestehen im Allgemeinen aus der synergetischen Integra-tion verschiedener mechatronischer Module, das heißt Systemelemente oder Bauteile, die zu einer Gruppe zusammengefasst werden und gemeinsam eine bestimmte Funktion erfüllen. Da diese Module unterschiedliche Funktionen beinhalten und repräsentieren, ist es sinnvoll, die Integration nicht nur auf einer Ebene zu gestalten, sondern auf das Ordnungsprinzip der Hie-rarchisierung zurückzugreifen. Die in der Abbildung 2-2 dargestellte Grundstruktur eines me-chatronischen Systems ist als Grundbaustein zu verstehen [VDI2206].

Werden mehrere Grundbausteine über ihre mechatronische Funktionsstruktur und über ihre mechatronische Tragstruktur miteinander verkoppelt, so entsteht ein System höherer Ordnung. Auf dieser höheren Stufe werden zusätzlich Aufgaben des Grundbausteins unter Umständen mit zusätzlicher Sensorik und Informationsverarbeitung realisiert. Neben der Realisierung von Fehlerdiagnosen und Überwachungsalgorithmen steht besonders die Generierung von Vorga-ben für untergeordnete mechatronische Grundbausteine im Vordergrund dieser Hierarchiestufe [VDI2206].

Abbildung 2-3 zeigt exemplarisch eine hierarchische Struktur mechatronischer Systeme. Grundbausteine der 1. Ebene (z. B. elektronisches Bremssystem) werden auf der 2. Ebene mit überlagerter Informationsverarbeitung verkoppelt (z. B. Fahrzeug). Auf der 3. Ebene entstehen vernetzte Systeme, die nur über die Informationsverarbeitung verbunden sind (z. B. Ermittlung des Sicherheitsabstandes mittels adaptiver Fahrgeschwindigkeitsregelung und Fahrzeug ab-bremsen).

Page 36: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

18 Grundlagen und Begriffsabgrenzung

Elektronisches Bremssystem

Fahrzeug

Adaptive Fahrgeschwindigkeitsregelung

Informationsverarbeitung

Aktorik Sensorik

Grundsystem

BS: Grundbaustein

BS

Informationsverarbeitung

BS

BS

BS

S: System

Informationsverarbeitung

S S NS

NS: vernetzte System

Abbildung 2-3: Beispiel für die Strukturierung mechatronischer Systeme, in Anlehnung an [VDI2206]

2.2.5 Innovationspotenziale der Mechatronik

Das synergetische Zusammenwirken von Maschinenbau, Elektrotechnik und Informations-technik ermöglicht die Ausschöpfung von hohen Innovationspotenzialen, vor allem bei der Entwicklung und Realisierung von neuen Produkten und Anwendungen. Diese Innovationspo-tenziale lassen sich in vier Bereiche gliedern [Möhr2004]:

Funktions- und Verhaltensverbesserung technischer Systeme

Mechatronik trägt dazu bei, Funktionen und Verhalten vorhandener technischer Systeme zu verbessern. Das äußere Erscheinungsbild, die prinzipielle Funktionsweise und der Anwen-dungsbereich bleiben dabei meist unverändert. Beispiele solcher Innovationspotenziale sind:

Anti-Blockier-System (ABS): Das Grundprinzip des hydraulischen Bremssystems wird um ABS-Ventil, Drehzahlsensor und ABS-Steuergerät ergänzt, um ein Blockieren der Räder zu verhindern.

Dynamisches Kurvenlicht: Der Scheinwerfer wird in Abhängigkeit vom gerade durch-

Page 37: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundlagen und Begriffsabgrenzung 19

fahrenen Kurvenradius und der Fahrgeschwindigkeit geschwenkt; der Autofahrer er-kennt beim Einlenken den Kurvenverlauf frühzeitiger und kann seine Fahrweise anpas-sen [HELL2008].

„Schreiende Schraube“ für präzises Einstellen der Vorspannkraft: Bei der klemmkraft-gesteuerten Schraubenmontage wird die Schallemission der Schraube bei mikroplasti-scher Verformung gemessen und berücksichtigt [Klos2001].

Reduzierung von Baugröße, Gewicht und Kosten

Insbesondere durch räumliche Integration können Baugröße und Gewicht von Komponenten reduziert werden. Dies gelingt beispielsweise durch Integration von elektronischen Funktionen in mechanische Elemente (Steckverbinder oder Gehäuse) und durch den Entwurf multifunk-tionaler Bauteile (Gehäuse, Kühlkörper und Leitungsträger).

Kosteneinsparungen lassen sich durch niedrigere Herstellkosten (Entfall von Gehäusen oder Bauteilen), niedrigere Logistikkosten (weniger Bauteile bei Transport, Lagerhaltung und Ein-gangsprüfung) und geringeren Montageaufwand (Entfall von separaten Gehäusen, Reduzie-rung der Verkabelung durch Bussysteme) erzielen [VDA2000].

Neue Funktionen und Anwendungen

Gänzlich neue Funktionen und Anwendungen können entstehen, wenn Systeme von Anfang an mechatronisch konzipiert werden, d. h. auf der synergetischen Kombination von Lösungs-prinzipien aus verschiedenen Domänen beruhen. Beispiele sind X-by-Wire15-Anwendungen in der Luftfahrt oder Automobilindustrie; ferner Werkstoffstrukturen, die Sensoren, Aktoren und informationsverarbeitende Komponenten integrieren und damit gleichzeitig tragende wie akto-rische bzw. sensorische Aufgaben übernehmen, z. B. Piezoelektrika.

Intelligente und selbstoptimierende Systeme

Neue Forschungs- und Anwendungsfelder entstehen mit sog. intelligenten (engl. auch smart, active) mechatronischen Systemen. Darunter wird die Fähigkeit eines mechatronischen Sys-tems verstanden, seine internen Zustände zu erkennen und diese mithilfe inhärenter Informati-onsverarbeitung zu optimieren. Anwendungsbeispiele sind Maschinen mit Eigendiagnosefä-higkeiten, d. h. sie können sich selbst justieren, Auskunft über Funktionssicherheit und Restle-bensdauer geben und Korrekturen vorschlagen bzw. durchführen [Schw2002].

15 X-by-Wire: Steuerbefehle werden nicht mehr direkt (mechanisch oder hydraulisch), sondern über elektrische Leitung “by wire” an das Steuerelement (z. B. Seitenruder am Flugzeug, Radbremse im Automobil) übertragen [Möhr2004].

Page 38: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

20 Grundlagen und Begriffsabgrenzung

2.3 Interdisziplinäre Methodik zur Entwicklung mechatronischer Systeme nach VDI 2206

Um die Entwicklung mechatronischer Produkte und die dazugehörende Komplexität unter den Rahmenbedingungen Zeit, Kosten und Qualität beherrschen zu können, ist eine interdiszipli-näre Entwicklungsvorgehensweise erforderlich. Diese Vorgehensweise muss die verschiede-nen domänenspezifischen Entwicklungsmethoden systematisch und synergetisch zusammen-führen, um eine interdisziplinäre und integrierte Entwicklung mechatronischer Systeme über alle Domänen hinweg ermöglichen zu können. Aus dieser Anforderung heraus kam die VDI-Richtlinie 2206 „Entwicklungsmethodik für mechatronische Systeme“ im Jahr 2004 zustande.

Die VDI-Richtlinie 2206 soll die Richtlinien VDI 2221 (Methodik zum Entwickeln und Kons-truieren technischer Systeme und Produkte) und VDI 2422 (Entwicklungsmethodik für Geräte mit Steuerung durch Mikroelektronik) weiter ergänzen, die sich lediglich auf die Entwicklung mechanischer bzw. mikroelektronischer Produkte konzentrieren.

Den Kern dieser Richtlinie bildet ein Vorgehensmodell, das sich im Wesentlichen auf drei Elemente stützt [VDI2206], [Möhr2004]:

Allgemeiner Problemlösungszyklus auf der Mikroebene

V-Modell auf der Makroebene

Vordefinierte Prozessbausteine zur Bearbeitung wiederkehrender Arbeitsschritte bei der Entwicklung mechatronischer Systeme

2.3.1 Problemlösungszyklus auf der Mikroebene

Der Problemlösungszyklus beschreibt eine strukturierte und systematische Vorgehensweise für Problemlösungen, die auf der Grundlage eines allgemeinen Problemlösungszyklus aus dem System Engineering basiert. Der Mikrozyklus soll vor allem den im Prozess stehenden Pro-duktenwickler bei der Bearbeitung vorhersehbarer und damit planbarer Teilaufgaben, aber auch bei der Lösung plötzlich auftretender, unvorhersehbarer Probleme unterstützen. Der Problemlösungszyklus umfasst in seinem Kern die folgenden Schritte (Abbildung 2-4) [VDI2206], [GaMö2003]:

Page 39: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundlagen und Begriffsabgrenzung 21

Situationsanalyse Zielübernahme

Zielformulierung Situationsanalyse

Entscheidung

Analyse und Bewertung

Anstoß Anstoß

Ist-Zustandorientiertes Vorgehen(vorhandene Struktur

wird zu Grunde gelegt)

Soll-Zustandorientiertes Vorgehen

(Idealkonzept steht im Vordergrund)

Synthese• Lösungs-

alternativen entwickeln

• Lösungen prüfen, verbessern, verwerfen

Planen desweiterenVorgehens

Lernen

Abbildung 2-4: Problemlösungszyklus als Mikrozyklus [VDI2206]

Situationsanalyse bzw. Zielübernahme

Ein Handlungsbedarf zur Lösung eines Problems kann entweder aus der Untersuchung einer Ist-Situation, der Situationsanalyse, heraus entstehen oder durch die Vorgabe eines von außen vordefinierten Zieles, der Zielübernahme, angestoßen werden. Die Situationsanalyse führt in der Regel automatisch zur Definition einer Soll-Situation und damit Zielformulierung (Ist-Zustand-orientiertes Vorgehen). Ausgehend von einer Zielübernahme wird zunächst die Ist-Situation analysiert, um einen Lösungsweg zu definieren (Soll-Zustand-orientiertes Vorge-hen).

Analyse und Synthese

Basierend auf der Zielformulierung und Situationsanalyse erfolgt die Suche nach Lösungen für das gegebene Problem. Dieser Prozess stellt sich in der Praxis als ein permanentes Wechsel-spiel von Synthese- und Analyseschritten dar. Ziel dieses Teilschritts ist es, alternative Lö-sungsvarianten zu erarbeiten. Bei der Lösungssuche können selbstverständlich zusätzliche Aspekte des Problems erkannt werden, die einen Rücksprung zu Situationsanalyse und Ziel-

Page 40: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

22 Grundlagen und Begriffsabgrenzung

formulierung notwendig machen oder als ergänzende Kriterien in den nachfolgenden Bewer-tungsschritt mit einfließen müssen [VDI2206].

Analyse und Bewertung

Die entwickelten Lösungsvarianten werden detailliert evaluiert. Dabei werden die Eigenschaf-ten der Teil- bzw. die Gesamtlösungsvarianten auf Basis von Bewertungskriterien, die aus den Lösungsanforderungen abgeleitet werden, analysiert. Hierfür können Berechnungs-, Simulati-ons- und Testmethoden und Werkzeuge verwendet werden. Die Bewertungsergebnisse sollen als Entscheidungsgrundlage für eine oder mehrere Lösungsalternativen dienen.

Entscheidung

In Form der Entscheidung muss festgestellt werden, ob der bisherige Verlauf der Problemlö-sung zu einem befriedigenden Ergebnis geführt hat. Ist das nicht der Fall, muss zur Situations-analyse und Zielformulierung zurückgekehrt werden. Andernfalls erfolgt eine Entscheidung für eine, vielleicht auch mehrere, Lösungsalternativen, die zur Grundlage der weiteren Pla-nung gemacht werden.

Planen des weiteren Vorgehens sowie Lernen aus bisherigen Schritten

Die Planung des weiteren Vorgehens wird in vielen Fällen mehr oder weniger fließend in wei-tere Problemlösungszyklen einmünden und auf diese Weise zu einem effizienten, situations-angepassten Prozessverlauf führen. Neben der rein operativen Bewertung des Handlungser-gebnisses sollte am Ende jedes Mikrozyklus jedoch auch kurz innegehalten werden, um so-wohl das Ergebnis als auch den Prozessablauf einer allgemeinen kritischen Betrachtung zu unterziehen. Indem nachvollzogen wird, was am jeweiligen Prozessablauf und dem Ergebnis gut und was weniger gut war bzw. ist, lässt sich verfügbares Wissen für kommende Entwick-lungsaufgaben generieren.

2.3.2 V-Modell der Makroebene

Der Makrozyklus stellt ein generisches Vorgehensmodell für die Integration die an der Ent-wicklung mechatronischer Systeme beteiligten domänenspezifischen Prozesse (Mechanik, Elektrotechnik und Informationstechnik) dar. Dieses Vorgehensmodell wurde aus dem in der Softwareentwicklung etablierten V-Modell abgeleitet und an die Anforderungen der Mechat-ronik weiter angepasst. Dieses Modell umfasst die folgenden Hauptphasen (Abbildung 2-5):

Page 41: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundlagen und Begriffsabgrenzung 23

Mechanik

Abbildung 2-5: V-Modell als Makrozyklus [VDI2206]

Anforderungen

Ausgehend von einem vordefinierten Lastenheft oder einem Produktsteckbrief wird die An-forderungsanalyse für das gesamte System unter Beteiligung aller Fachbereiche (Mechanik, Elektrotechnik, Informationstechnik) durchgeführt. Als Ergebnis wird in der Regel ein Pro-duktpflichtenheft entstehen, das u. a. die folgenden Informationen beinhaltet:

Beschreibung der (Sub-)Systeme,

Beschreibung der (Haupt-)Funktionen,

Beschreibung der Schnittstellen zwischen den (Haupt-)Funktionen, (Sub-)Systemen un-tereinander,

Beschreibung von externen Schnittstellen und

Festlegung von Restriktionen, Annahmen und Abhängigkeiten.

Das erstellte Pflichtenheft soll als Basis zur Entwicklung von Testszenarien für den späteren Produktabnahmetest dienen.

Systementwurf

Ziel ist die Festlegung eines domänenübergreifenden, interdisziplinären Lösungskonzepts, das die wesentlichen physikalischen und logischen Wirkungsweisen des zukünftigen Produktes beschreibt. Hierzu wird die Gesamtfunktion eines Systems in wesentliche Teilfunktionen zer-legt. Diesen Teilfunktionen werden geeignete Wirkprinzipien bzw. Lösungselemente zugeord-net und die Funktionserfüllung wird im Systemzusammenhang geprüft.

Page 42: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

24 Grundlagen und Begriffsabgrenzung

Domänenspezifischer Entwurf

Auf der Basis dieses gemeinsam entwickelten Lösungskonzepts erfolgt die weitere Konkreti-sierung meist getrennt in den beteiligten Domänen. Detailliertere Auslegungen und Berech-nungen sind nötig, um insbesondere bei kritischen Funktionen die Funktionserfüllung sicher-zustellen.

Systemintegration

Die Ergebnisse aus den einzelnen Domänen werden zu einem Gesamtsystem integriert, um das Zusammenwirken untersuchen zu können.

Eigenschaftsabsicherung

Der Entwurfsfortschritt muss fortlaufend anhand des spezifizierten Lösungskonzepts und der Anforderungen überprüft werden. Es ist sicherzustellen, dass die tatsächlichen mit den ge-wünschten Systemeigenschaften übereinstimmen.

Modellbildung und -analyse

Die beschriebenen Phasen werden flankiert durch die Abbildung und die Untersuchung der Systemeigenschaften mithilfe von Modellen und rechnerunterstützten Werkzeuge zur Simula-tion.

Produkt

Das Ergebnis eines durchlaufenen Makrozyklus ist das Produkt. Dabei wird unter Produkt nicht ausschließlich das fertige, real existierende Erzeugnis verstanden, sondern die zuneh-mende Konkretisierung des zukünftigen Produktes (Produktreife). Reifegrade sind z. B. das Labormuster, das Funktionsmuster, das Vorserienprodukt etc.

2.3.3 Prozessbausteine

Im Rahmen dieser Richtlinie VDI 2206 sind Prozessschritte bzw. Aktivitäten, die innerhalb des Gesamtentwicklungsprozesses mechatronischer Systeme häufig vorkommen, als vordefi-nierte Bausteine beschrieben. Die folgenden Bausteine sind für die oben schon genannten Pro-zessschritte definiert:

Systementwurf,

Modellbildung und -analyse,

domänenspezifischer Entwurf,

Systemintegration und

Eigenschaftsabsicherung.

Page 43: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundlagen und Begriffsabgrenzung 25

2.4 Methodische Ansätze zur Konzipierung mechatronischer Sys-teme

2.4.1 Systemtechnik

Die Systemtechnik ist eine interdisziplinäre Problemlösungsmethodik für künstliche Systeme. Sie stellt Methoden, Verfahren und Hilfsmittel zur Analyse, Planung, Auswahl und Gestalt von komplexen Systemen zur Verfügung und schlägt einen allgemeingültigen, produktneutra-len Problemlösungsprozess für die Anwendung vor [Klei2003].

Die Theorie der Systemtechnik bildet die notwendige Grundlage für die Konstruktionswissen-schaft und führt den Ingenieur dahin, zweckgebunden zu denken, große Zusammenhänge zu sehen, die Ganzheit als Prinzip zu verstehen und anzuwenden sowie wichtige Analogien und Relationen allgemein zu erkennen [Hubk1984].

Hubka [Hubk1984] bezeichnet als System ein aus einer endlichen Menge von Elementen nach bestimmten Regeln geordnetes Ganzes. Damit existieren zwischen den Elementen ganz bestimmte Beziehungen. Hierzu sind das Element und das System als relative Begriffe zu be-trachten. Ein Element kann auch ein System sein und ein System kann wieder zum Element eines größeren Systems werden. Zweckgebundenes Verhalten eines Systems bezeichnet Hub-ka als Funktionen, d. h. als ein ganz bestimmtes Verhalten, das der gewünschten Wirkungsfä-higkeit entspricht. Eine Funktion ist auch dadurch gekennzeichnet, eine Eingangsgröße in eine ganz bestimmte Ausgangsgröße zu überführen. Der Begriff Systemstruktur wird als innere Gliederung, Ordnung oder Aufbau des Systems verstanden und ist die Menge aller Elemente und Relationen eines Systems [DaHu1997]. Jedes System hat eine Umgebung und äußere Relationen zur Umwelt, die als Input oder Output bezeichnet werden. Jedes System, seine Elemente und Relationen besitzen Eigenschaften, die gewisse Ausprägungen aufweisen. Die Gesamtheit der Ausprägungen aller Eigenschaften eines Systems zu einem bestimmten Zeit-punkt wird als Zustand des Systems bezeichnet. Die Struktur legt das Verhalten des Systems fest, d. h. ein geschlossenes System mit einer gegebenen Struktur weist ein spezielles Verhal-ten auf [Klei2003] (Abbildung 2-6).

Page 44: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

26 Grundlagen und Begriffsabgrenzung

a

b

c d

e

f

g h

S1 S2l

i

kE

E

A

S

a…h: Systemelemente

i…l: Anschlusselemente

S: Gesamtsystem

S1,S2 : Teilsystem

E: Eingangsgrößen

A: Ausgangsgrößen

Abbildung 2-6: Strukturierung eines Systems [PBFG2004]

Im Mittelpunkt der Betrachtung der Systemtechnik stehen technische Systeme sowie deren Zweck, Wirkungsweise, Aufbau und Zustände. Die Wahrnehmung technischer Systeme kann dabei unter verschiedenen Gesichtspunkten erfolgen. Die Black-Box-Betrachtung fragt nach den (Aus-)Wirkungen eines Systems und identifiziert Eingangs- und Ausgangsgrößen. Die White-Box-Betrachtung analysiert das Wesen eines technischen Systems vor allem mit Sicht auf den inneren Aufbau, den Hubka in Funktions-, Organ und Baustruktur unterteilt [Klei2003].

Die Aufgabe des Entwicklungsingenieurs ist es, vom Groben zum Feinen – mithilfe der Trans-formation von einer Struktur in eine andere unter Festlegung bzw. Abstraktion einiger Kons-truktionsmerkmale oder Systemeigenschaften – zu gelangen. Die Transformation der Struktu-ren technischer Systeme hat dabei eine unmittelbare Bedeutung für das methodische Vorge-hen, da dadurch das iterative Vorgehen und die Definition von Algorithmen des Konstrukti-onsablaufs ermöglicht werden [Klei2003]. Das Grundprinzip der Systemtechnik liegt in der Aufgliederung der Problemlösungsprozesse in parallele Lösungswege durch Aufspaltung eines komplexen Gesamtproblems in überschaubare Teil- bzw. Einzelprobleme und folglich in der Aufgliederung eines technischen Systems in Teilsysteme [Klei2003].

2.4.2 Funktionsorientierte Vorgehensweise

Die funktionsorientierte Vorgehensweise findet derzeit immer mehr Verbreitung. Nach Kal-lenbach [BKSS1997] lassen sich die Anforderungen an komplexe mechatronische Systeme nicht mehr durch die getrennte Analyse und Synthese der Subsysteme realisieren. Im Zentrum der funktionsorientierten Vorgehensweise nach Kallenbach steht die Präzisierung der Funkti-onsanforderungen an das Produkt, die es in allen Phasen des Entwicklungsprozesses zu be-rücksichtigen gilt. Das Finden einer optimalen Funktionsstruktur wird dazu in die Schritte „Zerlegung der Gesamtfunktion in Teilfunktionen“ und „Zuordnung von Teilstrukturen“ un-terteilt und als „Funktionsstrukturübergang“ bezeichnet.

Page 45: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundlagen und Begriffsabgrenzung 27

Die Anwendung von bekannten Konstruktionsregeln gemäß verfügbarer Konstruktionsmetho-den und die Überprüfung der technologischen Verträglichkeit führen zur Auswahl geeigneter Wirkprinzipien zur Realisierung der definierten Funktionen und zugeordneten Gestaltelemente und schließlich zur Gesamtgestaltung des mechatronischen Systems.

Nach Kallenbach ist gerade die Abbildung von Anforderungen, Funktionen und ihren Ver-knüpfungen sowie deren Überführung in Gestaltelemente und in die Gesamtgestalt des me-chatronischen Systems eine wesentliche Voraussetzung für die Beherrschung der Komplexität der Systeme und dient zur Sicherstellung der Transparenz im multidisziplinären Entwick-lungsprozess.

2.4.3 Partitionierung mechatronischer Systeme

Da die Gesamtfunktion mechatronischer Systeme durch das Zusammenwirken von Lösungs-prinzipien unterschiedlich gut erfüllt wird und viele Teilefunktionen grundsätzlich sowohl mechanisch als auch elektronisch oder informationstechnisch realisiert werden können, ergibt sich in der Regel eine Vielzahl von Variantenmöglichkeiten bezüglich der Domänenstruktur. Bei der Entwicklung eines mechatronischen Systems muss daher festgelegt werden, in welcher Weise die verschiedenen Domänen zusammenwirken sollen, um die geforderten Systemeigen-schaften zu erzielen. Dieser Prozess wird als Partitionierung bezeichnet. In der englischspra-chigen Literatur werden hierfür auch die Begriffe technology allocation oder domain allocati-on verwendet. Dadurch wird zum Ausdruck gebracht, dass im Rahmen der Partitionierung eine Zuweisung von Domänen bzw. von Technologie verschiedener Domänen zu den Teil-funktionen des Produkts erfolgt [Jans2006].

Jansen [Jans2006] unterscheidet bei der Partitionierung mechatronischer Systeme zwischen einer funktionalen und einer räumlichen Partitionierung:

Unter der funktionalen Partitionierung eines mechatronischen Systems ist die Zuord-nung einer Funktion bzw. einer Gruppe von Funktionen des Systems zu einer bestimm-ten Domäne (Mechanik, Elektronik, Informationstechnik etc.) oder Kombination von Domänen zu verstehen. Dabei werden auch die Relationen zwischen den Teilfunktionen den verschiedenen Domänen zugeordnet.

Die räumliche Partitionierung umfasst die geometrische Anordnung und bauliche Gruppierung von Systemelementen innerhalb des mechatronischen Systems unter be-sonderer Berücksichtigung der zu ihrer Realisierung genutzten Domänen.

Bei der Durchführung der Partitionierung mechatronischer Systeme spielt vor allem die Abbildung der Relationen zwischen den Systemfunktionen und den Systemelemente eine wichtige Rolle, um ein gesamtes Systemkonzept beschreiben zu können. Hierzu wird zwi-schen Realisierungs- und Hierarchierelationen differenziert. Durch Realisierungsrelationen werden die Assoziationen eines Systemelements zu den zugehörigen konkretisierenden

Page 46: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

28 Grundlagen und Begriffsabgrenzung

und abstrahierenden Elementen abgebildet. Hierarchierelationen dienen der vertikalen Strukturierung eines Systems [Jans2006].

Zur systematischen und strukturierten Partitionierung mechatronischer Systeme hat Jansen im Rahmen einer Doktorarbeit einen Vorgehensleitfaden für die Systempartitionierung entwickelt (Abbildung 2-7). Der Leitfaden kann als Ergänzung zum V-Modell für den Entwurf mechatronischer Systeme (vgl. Abschnitt 2.3.2) betrachtet werden, das den Ent-wicklungsprozess auf einer übergeordneten Ebene beschreibt. Wie in der Abbildung dar-gestellt, erfolgt die Partitionierung in der Phase des Systementwurfs, da zum Eintritt in den domänenspezifischen Entwurf zwangsläufig eine Domänenallokation erfolgt sein muss. Die im Leitfaden definierten Arbeitsschritte sind somit in den gekennzeichneten Bereich des V-Modells einzuordnen.

Abbildung 2-7: Vorgehensleitfaden zur Partitionierung mechatronischer Systeme [Jans2006]

Page 47: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anforderungsanalyse 29

3 Anforderungsanalyse

Die Mechatronik eröffnet durch das enge Zusammenwirken von Maschinenbau, Elektrotech-nik und Informationstechnik faszinierende Möglichkeiten und große Erfolgspotenziale für die Gestaltung zukünftiger Produkte. Zugleich stellt sie besondere Anforderungen an die Prozesse, Daten- und IT-Landschaft innerhalb der Produktentwicklung. Diese besonderen Anforderun-gen entstehen vor allem aufgrund der hohen Komplexität und Heterogenität mechatronischer Systeme, die durch die Integration mehrerer Lösungsprinzipien aus verschiedenen Fachdiszip-linen verursacht wurde.

Um die interdisziplinären und domänenübergreifenden Entwicklungsprozesse und -abläufe beherrschen zu können, sind für die meisten Unternehmen laut einer Studie der Aberdeen Group (Abbildung 3-1) Integrations- bzw. Interoperabilitätsansätze auf Prozess-, Daten- sowie Anwendungssystem-Ebene dringend notwendig.

90% der Unternehmen

70% derUnternehmen

30% derUnternehmen

0% 20% 40% 60% 80% 100%

Domänenübergreifende integrierte Entwicklungsprozesse

Domänenübergreifende integrierte PLM-Tools

Domänenübergreifendes integriertes Änderungsmanagement

Abbildung 3-1: Notwendige Maßnahmen zur Beherrschung der Entwicklung mechatronischer Produkte [ABER2006]

Im Folgenden werden die Anforderungen hinsichtlich der Prozesse, Daten und PLM-Systeme dargestellt, um eine interdisziplinäre und integrierte Produktentwicklung im Sinne der optima-len Nutzung des synergetischen Zusammenwirkens der einzelnen Fachdisziplinen zu ermögli-chen.

Page 48: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

30 Anforderungsanalyse

3.1 Prozessbezogene Anforderungen

3.1.1 Unterstützung einer interdisziplinären, funktionsorientierten Entwick-lungsmethodik

Die Entwicklung zuverlässiger mechatronischer Produkte setzt eine ganzheitliche Betrachtung eines Produkts als integriertes mechatronisches Gesamtsystem sowie eine gleichberechtigte Berücksichtigung der Aspekte aller beteiligten Domänen voraus. Daher sind eine Beherr-schung der interdisziplinären Entwicklungsprozesse und eine domänenübergreifende Koopera-tion und Koordination zwischen den beteiligten Fachdisziplinen unerlässlich, um eine gesamt-optimierte mechatronische Systemlösung herbeiführen zu können.

Um eine domänenübergreifende Zusammenarbeit zwischen den verschiedenen Fachdiszipli-nen und eine Abstimmung zwischen allen Entwicklungsprozessen unter mechatronischen Rahmenbedingungen zu erreichen, ist die Anwendung einer interdisziplinären und funktions-orientierten Entwicklungsmethodik notwendig. Mit dem Konzept der interdisziplinären und funktionsorientierten Produktentwicklung lässt sich ein hochkomplexes mechatronisches Sys-tem effizient beherrschen [WaHe2007]. Eine derartige Entwicklungsmethodik lässt sich in-nerhalb eines heterogenen Umfeldes wie dem der Mechatronik nur wirkungsvoll einsetzen, wenn die folgenden Anforderungen nicht nur methodisch, sondern auch systemtechnisch er-füllt werden:

A.1.1 Die gewachsenen und etablierten Entwicklungsprozesse und -methoden – also be-reits vorhandene und durch die Firmenphilosophie vorgegebene Teilprozesse, wie z. B. Mechanik-Entwicklungs-, E/E16-Entwicklungs- und Softwareentwicklungsprozesse – sol-len nicht ausgegrenzt, sondern mit möglichst geringen Veränderungen in den übergrei-fenden interdisziplinären Entwicklungsprozess aufgenommen werden [BDKP2005].

A.1.2 Alle an der Produktentwicklung beteiligten Fachbereiche müssen bereits zu Be-ginn des Entwicklungsprojektes zwingend eingebunden werden.

A.1.3 Das frühzeitige, gemeinsame und domänenübergreifende Problem- und Zielver-ständnis der einzelnen Fachbereiche untereinander soll unterstützt und gestärkt werden, um das Entwicklungsrisiko zu minimieren.

A.1.4 Eine domänenübergreifende Systemspezifikation, -beschreibung und Erarbeitung von Lösungskonzepten in den früheren Entwicklungsphasen soll ermöglicht werden und somit soll die Dominanz einiger weniger Fachbereiche, wie z. B. dem Mechanik-Fachbereich vermieden werden.

A.1.5 Eine frühzeitige Identifizierung und Berücksichtigung der Wechselwirkung zwi-schen den domänenspezifischen Wirkprinzipien, Lösungselementen und Technologien

16 E/E: Elektrik und Elektronik

Page 49: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anforderungsanalyse 31

soll möglich sein.

A.1.6 Eine Hinwendung von einer komponenten- hin zu einer funktionsorientierten Denkweise über den gesamten Produktlebenszyklus soll unterstützt werden.

3.1.2 Synchronisation der domänenspezifischen Entwicklungsprozesse

Synchronisation und Abstimmung zwischen einzelnen Domänen ist bei der Entwicklung me-chatronischer Produkte unumgänglich, da sich Teilsysteme gegenseitig bedingen und diese zu einem Gesamtsystem integriert werden müssen [BDKP2005]. Daher sind domänenübergrei-fende Synchronisationsmechanismen auf einer interdisziplinären Prozessebene erforderlich, um die verschiedenen parallel laufenden domänenspezifischen Entwicklungsaufgaben optimal koordinieren zu können.

Die wichtigsten Synchronisationsmethoden, die innerhalb der Entwicklung mechatronischer Produkte eingeführt werden müssen, sind:

A.2.1 Domänenübergreifendes und funktionsorientiertes Versionierungsmanagement

Um eine domänenübergreifende und interdisziplinäre Datenlenkung und Verfolgung ent-lang der gesamten Entwicklungsprozesse sicherzustellen, sind die Steuerung sowie die Abstimmung der verschiedenen domänenspezifischen Versionierungsmethoden auf eine interdisziplinäre und funktionale Produktebene über alle Entwicklungsbereiche erforder-lich. Das bedeutet, die Versionierung von domänenspezifischen Produktkomponenten so-wie deren Relationen müssen automatisch zur Versionierung der zu realisierenden inter-disziplinären Funktionen und Systemen und deren Abhängigkeiten führen und umgekehrt.

A.2.2 Domänenübergreifendes und funktionsorientiertes Freigabemanagement

Die zuverlässige Erreichung und Bestimmung der erforderlichen Reifegrad- und Quali-tätsziele eines Produktes bedingt einen domänenübergreifenden und funktionsorientierten Freigabemanagementprozess, welcher die domänenspezifischen Freigabeprozesse steuert und systematisch zu einer Gesamtfreigabe des Produkts über alle Domänen hinführt. Das heißt technische Komponenten können erst freigegeben werden, wenn die gewünschten Gesamtfunktionen erfüllt und freigegeben sind (z. B. ein Bremspedal kann erst freigeben werden, wenn das gesamte Bremssystem inkl. ESP17-, ABS18-System etc. einwandfrei funktioniert).

A.2.3 Domänenübergreifendes und funktionsorientiertes Änderungsmanagement

Die Abschätzung der Tragweite einer Änderung innerhalb des Gesamtprodukts bzw. die Auswirkung auf weitere Komponenten, Funktionen und Systeme erfordert die Einführung eines domänenübergreifenden, funktionsorientierten Änderungsmanagements. Dieses er-

17 ESP: Elektronisches Stabilitätsprogramm (vgl. Abschnitt 6.2) 18 ABS: Antiblockiersystem (vgl. Abschnitt 6.2)

Page 50: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

32 Anforderungsanalyse

möglicht, dass die Prozessteilnehmer rechtzeitig über Änderungen, die in anderen Fachbe-reichen unternommen wurden, informiert sind und somit rechtzeitig darauf reagieren kön-nen. Alle domänenspezifischen Änderungsmanagementprozesse müssen von einem do-mänenübergreifenden Änderungsmanagement koordiniert werden, um die Beherrschung der Änderungen auf Gesamtproduktebene über alle Domänen hinweg gewährleisten zu können.

A.2.4 Domänenübergreifendes und funktionsorientiertes Konfigurationsmanagement

Ein domänenübergreifendes, funktionsorientiertes Konfigurationsmanagement ist not-wendig, um abgestimmte, abgesicherte und zueinander kompatible Komponenten, (Teil-)Funktionen und (Sub-)Systeme aus verschiedenen Fachdisziplinen systematisch zu einem funktionierenden Gesamtsystem zusammenzuführen. Somit ist jederzeit festzuhalten, wel-che Kombinationen von Systembestandteilen mit welchen Entwicklungsständen in einem Produkt verbaut sind.

3.2 Datenbezogene Anforderungen

Eine Betrachtung des Produktes als integriertes mechatronisches Gesamtsystem macht die Synchronisation nicht nur zwischen den beteiligten Organisationen und Prozessen notwendig, sondern auch zwischen den domänenspezifischen Partialdatenmodellen und entlang des Ge-samtentwicklungsprozesses. Daher ist die Erstellung eines disziplinübergreifenden, mechatro-nischen Meta-Datenmodells notwendig, um die komplexen Zusammenhänge innerhalb der Entwicklung mechatronischer Systeme meistern zu können.

Das mechatronische Meta-Datenmodell muss zur Erhöhung der Homogenität zwischen den unterschiedlichen Fachdisziplinen innerhalb der Entwicklung mechatronischer Systeme bei-tragen. Daher sind die folgenden Anforderungen zu erfüllen:

A.3.1 Das mechatronische Meta-Datenmodell muss alle interdisziplinären Produktdaten, die für eine ganzheitliche Betrachtung eines mechatronischen Systems notwendig sind, abbilden und deren Verwaltung und Steuerung ermöglichen.

A.3.2 Das mechatronische Meta-Datenmodell muss die Erstellung einer interdisziplinären Gesamtsystemspezifikation in Form einer logischen Systemarchitektur unterstützen, d. h. eine domänenunabhängige, -neutrale und abstrakte Abbildung und Modellierung von (Sub-) Systemen und (Teil-)Funktionen eines mechatronischen Produkts sowie von deren Abhängigkeiten und Verhalten müssen auf Basis dieses Datenmodells möglich sein. Diese lösungsneutrale Darstellung vermeidet eine Fixierung auf bestimmte Lösungsideen und eröffnet neue Lösungsfelder unter Beteiligung der verschiedenen Fachdisziplinen [Ga-

Mö2004]. Aus dieser interdisziplinären logischen Systemarchitektur sind die domänen-spezifischen Detaillierungen und Spezifikationen der mechatronischen Systeme abzulei-ten.

Page 51: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anforderungsanalyse 33

A.3.3 Das mechatronische Meta-Datenmodell muss die Partitionierung der mechatroni-schen Systemfunktionalitäten auf die für ihre Umsetzung zuständigen domänenspezifi-schen technischen Produktkomponenten und Systeme zulassen. D. h. die Überleitung von der logischen Systemarchitektur zu der technischen Systemarchitektur (Funktions-Mapping) muss abbildbar und nachvollziehbar sein. Auf dieser Weise wird ersichtlich, durch welche Komponente(n) eine bestimmte Funktion realisiert wird.

A.3.4 Das mechatronische Metda-Datenmodell muss die semantische Homogenität inner-halb einer heterogenen mechatronischen Umgebung erhöhen. Hierfür müssen alle domä-nenspezifischen Partialdatenmodelle, z. B. mechanische, elektrotechnische und informati-onstechnische Datenmodelle, auf Basis dieses mechatronischen Meta-Datenmodells mi-teinander verknüpft werden. Als Verknüpfungspunkte zu den einzelnen domänenspezifi-schen Partialdatenmodellen sollen hier die übergreifenden interdisziplinären Zusammen-hänge auf eine mechatronische Meta-Modellebene abgebildet werden. Somit können die komplexen und interdisziplinären Wechselbeziehungen der technischen Komponenten und Systeme mit mehr Transparenz und weniger organisatorischem Aufwand in den frü-hen Entwicklungsphasen dargestellt und visualisiert werden. Dieses führt vor allem zur Minimierung des Entwicklungsrisikos.

A.3.5 Das mechatronische Meta-Datenmodell muss ermöglichen, dass die gewachsenen und bereits etablierten domänenspezifischen Partialdatenmodelle wie z. B. bereits vorhan-dene Datenmodelle der mechanischen, elektrotechnischen und informationstechnischen Bereiche, beibehalten und mit möglichst geringen Veränderungen auf domänenübergrei-fender Ebene integriert werden können.

A.3.6 Das mechatronische Meta-Datenmodell muss die interne Autorität und Freiheit der domänenspezifischen Partialdatenmodelle im Hinblick auf Veränderungen und Weiter-entwicklung bewahren, d. h. eine Änderung eines Datenmodells darf die anderen Daten-modelle nicht beeinflussen.

A.3.7 Das mechatronische Meta-Datenmodell muss um neue Objekte und Domänen er-weiterbar sein. Beispielsweise muss die Einführung von neuen Fachdisziplinen innerhalb des Entwicklungsprozesses ohne großen Aufwand möglich sein.

A.3.8 Das mechatronische Meta-Datenmodell muss dazu beitragen, dass in Kombination mit klar definierten Abläufen (Workflows) die Kanalisierung des Datenflusses entlang des Gesamtentwicklungsprozesses über alle Domänen sichergestellt wird.

A.3.9 Das mechatronische Meta-Datenmodell muss die Einführung und Implementierung von domänenübergreifenden, interdisziplinären Versionierungs-, Konfigurations-, Ände-rungs- und Freigabemanagementmethoden unterstützen.

A.3.10 Das mechatronische Meta-Datenmodell muss als Integrationsbasis dienen, um die domänenspezifischen Entwicklungsergebnisse zu einem funktionierenden Gesamtsystem

Page 52: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

34 Anforderungsanalyse

zusammenzuführen.

3.3 PLM-Systemlandschaft-bezogene Anforderungen

Um die oben genannten Anforderungen an die Prozess- und Datenlandschaft erfüllen zu kön-nen, kommt der Integration der domänenspezifischen PLM-Anwendungen – d. h. PDM-, EES- und SCM-System – eine Schlüsselrolle zu. Die Ermöglichung einer interdisziplinären und funktionsorientierten Entwicklungsmethodik erfordert nicht nur ein interdisziplinäres, mechat-ronisches Meta-Datenmodell, sondern auch eine interdisziplinäre, föderierte mechatronische Integrationsplattform, welche die im Folgenden beschriebenen Anforderungen erfüllen muss:

3.3.1 Interdisziplinarität

A.4.1 Die mechatronische Integrationsplattform (mIP) muss die Überwindung der Schwie-rigkeiten, die durch die IT-Heterogenität innerhalb des mechatronischen Umfelds entste-hen können, fördern. Dies geschieht, indem sie die bereits vorhandenen und etablierten domänenspezifischen PLM-Anwendungen – in der Regel sind dies PDM-, EES- und SCM-Systeme – auf Basis des mechatronischen Meta-Datenmodells zu einer integrierten, interdisziplinären Entwicklungsumgebung miteinander koppelt.

A.4.2 Die mechatronische Integrationsplattform muss die im Abschnitt 3.1.1 geforderten Rahmenbedingungen für einen effizienten Einsatz einer interdisziplinären und funktions-orientierten Entwicklungsmethodik möglich machen.

A.4.3 Die mechatronische Integrationsplattform muss die im Abschnitt 3.1.2 geforderten interdisziplinären Synchronisationsmethoden unterstützen und ermöglichen.

3.3.2 Schutz bestehender IT-Investitionen

In letzter Zeit wurden innerhalb der Fachbereiche große Investitionen für den Aufbau der ei-genen PLM-Anwendungen und der dazugehörigen IT-Infrastruktur getätigt und diese stellen heute bereits einen enormen Wert für die Unternehmen dar, so dass eine komplette Ersetzung dieser IT-Systeme niemals in Frage kommen kann. Zudem beinhalten derartige IT-Systeme langjähriges Unternehmenswissen und -erfahrungen, die für die Unternehmen unverzichtbar sind.

A.5.1 Vor diesem Hintergrund muss die mechatronische Integrationsplattform die vorhan-denen domänenspezifischen PLM-Anwendungen und die dazugehörende IT-Infrastruktur nicht ersetzen oder ausgrenzen, sondern darauf aufbauen.

3.3.3 Flexibilität

Mechatronische Produkte und die dazugehörigen Technologien sind sehr kurzlebig, was zu einer hohen Änderungsdynamik innerhalb der Entwicklung derartiger Produkte führt. Demzu-folge müssen Unternehmen oftmals kurzfristige Änderungen in der Prozesslandschaft oder Einführungen von neuen Technologien und IT-Systeme oder Stilllegung von alten IT-

Page 53: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anforderungsanalyse 35

Systemen durchführen, was häufig eine aufwendige Anpassung der gesamten IT-Landschaft bedingt, z. B. die Anpassung von Systemschnittstellen.

A.6.1 Daher ist es wichtig, dass die mechatronische Integrationsplattform diese Ände-rungsdynamik innerhalb der einzelnen Fachbereiche nicht behindert, sondern mit mög-lichst geringem Anpassungsaufwand ermöglicht.

Um dieser Herausforderung gerecht zu werden, muss die mechatronische Integrationspattform ein hohes Maß an Flexibilität aufweisen. Diese Flexibilität ist für die Steigerung der Innovati-onsfähigkeit und der Agilität der Unternehmen im Sinne der schnellen Reaktion auf die Marktanforderungen und somit zur Stärkung der Wettbewerbsfähigkeit erforderlich.

A.6.2 Um die geforderte Flexibilität innerhalb der IT-Landschaft zu erreichen, muss die mechatronische Integrationsplattform die domänenspezifischen PLM-Systeme prozess-orientiert nach dem Prinzip der losen Kopplung über alle Domänen miteinander verknüp-fen. Auf diese Weise können unnötige Abhängigkeiten und enge Kopplungen zwischen den PLM-Anwendungen, die zu einer starren IT-Architektur führen, vermieden werden.

Page 54: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

36 Stand der Forschung und der Technik

4 Stand der Forschung und der Technik

Die permanent steigende Heterogenität der Methoden, Prozesse, Daten sowie der benutzten IT-Werkzeuge innerhalb der Produktentwicklung stellt seit längerer Zeit einer der wichtigsten strategischen Herausforderungen für Unternehmen dar. Zugleich werden die dynamischen Veränderungen der Unternehmen und ihrer Produkte dafür sorgen, dass die Beherrschung die-ser Heterogenität immer als andauernde Herausforderung zu betrachten ist.

Sowohl in der Praxis als auch in der Forschung wurde dieser Trend frühzeitig erkannt. Daher haben sich viele Unternehmen aus verschiedenen Industrie-, Beratungs- und IT-Branchen so-wie Forschungsinstitute seit längerer Zeit der Entwicklung von Integrations- bzw. Interopera-bilitätslösungen zur Beherrschung dieser Heterogenität gewidmet. Die Ergebnisse dieser Be-mühungen spiegeln sich heute vor allem in den zahlreichen und vielfältigen Integrationslö-sungsansätzen wider. Deren Spektrum reicht von IT-Integrationsinfrastrukturen und -plattformen bis hin zu Standarddatenmodellen und -integrationsdiensten.

In diesem Kapitel werden zunächst die allgemeinen IT-Integrationsansätze zur Ermöglichung der Integration und der Interoperabilität innerhalb heterogener IT-Systemlandschaften detail-liert analysiert und diskutiert (Kap. 4.1). Anschließend erfolgt in Kapitel 4.2 die Untersuchung und Bewertung von Engineering-spezifische Standardmodellen für Daten- und Prozessintegra-tion innerhalb der Entwicklung mechatronischer Produkte. Kapitel 4.3 befasst sich mit den Ansätzen zur Integration von Engineering-Tools auf Anwendungsfunktionsebene. Hierzu wer-den Standarddienste zum Aufrufen und Ausführen von Systemfunktionen erläutert und disku-tiert. Die Beschreibung des Leistungsumfangs unterschiedlicher domänenspezifischer PLM-Systeme für das Daten- und Prozessmanagement innerhalb der Entwicklung mechatronischer Produkte ist Gegenstand des Kapitels 4.3. Die relevanten Forschungsprojekte, die sich mit der Thematik der Daten-, Prozess- und IT-Systemintegration innerhalb des mechatronischen Um-felds beschäftigt haben, werden in Kapitel 4.4 vorgestellt und diskutiert. Abschließend wird in Kapitel 4.5 ein Resümee gezogen und der Handlungsbedarf abgeleitet.

4.1 Allgemeine IT-Integrationsansätze

Die Vision des nahtlosen Data-Sharing über alle IT-Systeme hinweg innerhalb eines Unter-nehmens oder einer Organisationseinheit, ohne dass die Systeme eng miteinander gekoppelt sein müssen, entstand mit der Geburt der ersten IT-Anwendungen Mitte der fünfziger Jahre. Seitdem wurden und werden immer noch zahlreiche Ansätze entwickelt und mannigfaltige IT-Lösungen auf den Markt gebracht mit dem Hauptziel, die Interoperabilität zwischen verschie-

Page 55: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 37

denen IT-Systemen in einer heterogenen IT-Landschaft zu erhöhen. Die Entwicklungsschwer-punkte im Umfeld der IT-Integrationstechnologie in den letzten sechzig Jahren kann nach [StBM2003], [Poll2001a] in etwa wie folgt dargestellt werden (Abbildung 4-1):

Seit 1954: Proprietäre Punkt-zu-Punkt Schnittstellen

seit 1960: Standard Datenmodelle

1980 – 1999: Data Warehouse

seit 1990: Single IT-Systeme

seit 1993: Enterprise Application Integration (EAI)

seit 1995: Semantische Technologien

seit 2002: Serviceorientierte Architektur (SOA)

1950 1960 1970 1980 1990 2000 2010

Proprietäre Punkt-zu-Punkt Schnittstellen

Standard Datenmodelle

Data Warehouse

Single IT-Systeme

Enterprise Application Integration (EAI)

Semantische Technologien

ServiceorientierteArchitektur (SOA)

Abbildung 4-1: Entwicklungsschwerpunkte im Umfeld der IT-Integrationstechnologien

4.1.1 Proprietäre Punkt-zu-Punkt Schnittstellen

Zu Beginn der Rechnerrevolution haben Unternehmen IT-Applikationen entsprechend ihrem eigenen Bedarf selbst programmiert bzw. programmieren lassen, um einfache Rechenaufgaben zu automatisieren. Kurz nach der Einführung der ersten Rechnerprogramme tauchte die Prob-lematik der Inkompatibilität der verschiedenen IT-Systeme auf. Da zu diesem Zeitpunkt keine kommerziellen Lösungen existierten, mussten die Unternehmen bedarfsspezifische proprietäre Punkt-zu-Punkt-Schnittstellen implementieren. Mit dieser Vorgehensweise konnten immer

Page 56: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

38 Stand der Forschung und der Technik

maßgeschneiderte und effiziente Lösungen entwickelt werden, die einwandfrei funktioniert haben [Poll2001b].

Doch ist die Anzahl der IT-Systeme sowie deren Komplexität mit der Zeit allmählich gestie-gen und parallel dazu hat sich die Menge und die Vielfältigkeit der Punkt-zu-Punkt-Schnittstellen mehrfach verdoppelt. Dieses führte u. a. zu den folgenden Problemen:

Die proprietären Punkt-zu-Punkt-Schnittstellen waren nicht mehr zu handhaben bzw. zu bewältigen.

Die Weiterentwicklung und Wartung der proprietären Punkt-zu-Punkt-Schnittstellen sind teuer und zeitaufwendig geworden.

Die Leistungen der proprietären Punkt-zu-Punkt-Schnittstellen sind an ihre Grenzen ge-stoßen und konnten technologisch gesehen nicht mehr optimiert werden, was zu enor-men Performanceeinbußen der gesamten IT-Systemlandschaft geführt hat.

Angesichts dieser Situation haben sich damals Unternehmen sowie Fachleute zum ersten Mal Gedanken über effiziente und nachhaltige Integrationsansätze gemacht und somit die Grün-dung einer neuen Disziplin „Systemintegration“ (auch bekannt als „Integration Engineering“) ausgelöst, die seitdem mehrere Evolutionsstufen erfahren hat. Trotz zahlreicher Standard-IT-Integrationslösungen versuchen bis heute noch viele Unternehmen ihre IT-Anwendungen durch eigenimplementierte Punkt-zu-Punkt-Schnittstellen miteinander zu verknüpfen. Dies ist in den meisten Fällen darauf zurückzuführen, dass die eigenimplementierten Schnittstellen viel günstiger sind, als die kommerziellen Standard-IT-Integrationslösungen.

4.1.2 Standard-Datenmodelle

Seit den sechziger Jahren haben sich diverse nationale und internationale Konsortien gegrün-det, die aus namhaften Firmen bestehen. Diese haben sich zum Ziel gesetzt, standardisierte Datenmodelle bzw. Formate für einen maschinellen Datenaustausch zwischen verschiedenen IT-Systemen und Organisationseinheiten zu entwickeln. Das Resultat dieser Bemühungen ist die Entstehung einer großen Anzahl von Standarddatenmodellen und Formaten wie z. B. AN-SI19, EDIFACT20, STEP, XML21, welche in Form von Datenpreprozessoren implementiert worden sind. Die Einführung derartiger Standards als Instrument zur Erhöhung der Interope-

19 ANSI: Die Abkürzung steht für „American National Standards Institute“, aber in der Computertechnik be-zeichnet ANSI eine bestimmte Gruppe von Zeichensätzen, die auf ASCII basieren. 20 EDIFACT ist die Abkürzung für United Nations Electronic Data Interchange For Administration, Commerce and Transport. EDIFACT ist ein branchenübergreifender internationaler Standard für das Format elektronischer Daten im Geschäftsverkehr. 21 XML: Extensible Markup Language ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien. XML wird u. a. für den Austausch von Daten zwischen Computersystemen ein-gesetzt.

Page 57: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 39

rabilität innerhalb heterogener IT-Systemlandschaften war und ist nur sehr beschränkt dien-lich. Die Hauptursachen hierfür sind u. a. die folgenden Faktoren:

Die Standarddatenmodelle sind sehr umfangreich und ausführlich beschrieben, was eine vollständige und standardkonforme Umsetzung bzw. Implementierung kaum möglich macht.

Es existiert kein Konsens zwischen den IT-Systemherstellern bei der Implementierung dieser Standards, d. h. aus einem Standard werden mehrere herstellerspezifische Stan-dards bzw. Formate abgeleitet.

Aufgrund der zwei vorherigen Punkte führt der Datenaustausch mittels Standardforma-ten in den meisten Fällen zu Informationsverlusten und bis hin zur Beschädigung der zu übertragenden Informationen.

Heute ist klar zu erkennen, dass die Verwendung derartiger Standard-Datenmodelle in der Praxis als Interoperabilitätsansatz innerhalb einer heterogenen IT-Landschaft konnte in meis-ten Fällen nicht zur Erreichung der angestrebten Ziele beibringen. Daher werden diese Stan-dard-Datenmodelle in der Praxis mit anderen IT-Integrationsansätzen wie z.B. EAI, semanti-sche Technologie oder SOA kombiniert, um bessere Ergebnisse zu erreichen.

4.1.3 Data Warehouse

Das Data Warehouse-Konzept, das auch unter den Bezeichnungen Atomic Database, Decisi-on-Support System Foundation, Information Warehause, Business Information Resource und Reporting Database bekannt ist, wurde erstmals Anfang der achtziger Jahre unter den Schlag-worten Data Supermarket und Super Databases erwähnt [Holt1999]. 1988 stellte die Firma IBM ein internes Projekt unter der Bezeichnung European Business Information System vor, das 1991 in Information Warehouse Strategy umbenannt wurde [MeGr1993]. Das in diesem Projekt entwickelte Konzept beinhaltet Produkte, Mechanismen und Vorgehensweisen zur Überwindung der Heterogenität und Bewältigung der Informationsexplosion [Holt1999]. Anfang der neunziger Jahre wurde das Data Warehouse-Konzept von verschiedenen Hardwa-reherstellern sowie Software- und Beratungshäusern aufgegriffen und als Dienstleistungspaket auf dem Markt angeboten [DATA1994]. Das Data Warehouse-Konzept lässt sich folgender-maßen erläutern:

Ein Data Warehouse ist eine physische Datenbank, deren Inhalt sich aus Daten unter-schiedlicher Quellen zusammensetzt. Die Daten werden von verschiedenen operationa-len IT-Systemen in das Data Warehouse geladen, um eine integrierte Datensicht vor al-lem zu Analysezwecken zu ermöglichen. [MuBe2000], [BaGü2004]

Data Warehouse-Lösungen werden mit dem Ziel eingesetzt, insbesondere folgende Anwen-dungen zu realisieren [Holt1999], [MuBe2000], [BaGü2004]:

Integration von Daten aus unterschiedlich strukturierten und verteilten Datenbeständen,

Page 58: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

40 Stand der Forschung und der Technik

um eine globale Sicht auf die Quelldaten und damit übergreifende Auswertungen zu ermöglichen

Ermittlung verborgener Zusammenhänge zwischen Daten durch Data Mining22

Schnelle und flexible Verfügbarkeit von Berichten, Statistiken und Kennzahlen

Bereitstellung von umfassenden Informationen über Geschäftsobjekte und Zusammen-hänge

Die folgende Tabelle 4-1 zeigt eine Übersicht der wichtigsten Data Warehouse-Komponenten (Abbildung 4-2) [Holt1999], [Inmo2002], [MuHR1996]:

Komponente Beschreibung

Datenbasis

Den Kern des Data Warehouse-Konzepts bildet eine Daten-basis, die sowohl aktuelle als auch historische Daten aus allen eingebundenen Unternehmensbereichen in unterschiedlichen Verdichtungsstufen enthält.

Transformationsprogramme

Die zweite Komponente im Data Warehouse-Konzept bilden die zur Übernahme unternehmensinterner und -externer Da-ten eingesetzten Transformationsprogramme. Ihre Funktiona-lität umfasst die Extraktion von Daten aus den unterschiedli-chen Quellsystemen, die eigentliche Transformation der Da-ten sowie deren Transport und den Ladevorgang in die Da-tenbasis des Data Warehouse.

Meta-Datenbank

Zu den idealtypischen Komponenten eines Data Warehouse gehört ein Meta-Datenbanksystem, in dem Informationen über alle Data Warehouse-Komponenten gehalten und ver-waltet werden. Es soll den Benutzern ein schnelles und siche-res Auffinden der benötigten Daten ermöglichen.

Archivierungssystem Neben der Datenbasis beinhaltet das Data Warehouse-Konzept ein Archivierungssystem, das die Bereiche Datensi-cherung und -archivierung abdeckt.

Tabelle 4-1 Wichtigste Komponenten eines Data Warehause

22 Data Mining: unter Data Mining wird die systematische Anwendung von Methoden, die meist statistisch-mathematisch begründet sind, auf einen Datenbestand mit dem Ziel der Mustererkennung verstanden.

Page 59: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 41

Verdichtungsstufe N

Verdichtungsstufe 2

Verdichtungsstufe 1

Transformations-programme

unternehmensinterneDaten

unternehmensexterneDaten

Archivierungs-system

Datenbasis

archivierte Detaildaten

Meta-Daten-bank-

system

Abbildung 4-2: Schematischer Aufbau eines Data Warehouse [Holt1999]

Der Data Warehouse-Ansatz zur Steigerung der Interoperabilität innerhalb heterogener IT-Systemlandschaften konnte bis heute in der Praxis keine breite Akzeptanz erreichen. Eine der wenigen Ausnahmen stellt der Einsatz als Datenverdichtungssysteme für Statistik- und Analy-sezwecke oder Langzeitarchivierungssysteme dar. Dies ist auf folgende Schwachstellen zu-rückzuführen:

Die Zusammenführung aller Daten der verschiedenen IT-Systeme in einer gemeinsa-men Datenbank bedingt ein gemeinsames Datenbankschema bzw. Datenmodell für alle IT-Systeme. Die Erstellung und die Pflege derartiger Datenmodelle aufgrund der Ände-rungsdynamik der Datentypen und -umfänge sind realistisch kaum umsetzbar.

Eine homogene Datenbasis für alle IT-Systeme führt zwangsläufig zu Verlusten von syntaktischen und semantischen Informationen der Datenobjekte sowie Zusammenhän-gen zwischen den Datenobjekten.

Der Einsatz eines Data Warehouse-Systems als operatives System erfordert die Ge-währleistung sowohl einer schnellen Echtzeitdatenübernahme als auch eines schnellen Echtzeitdatenzugriffs, was aufgrund der Datenmenge nicht immer einfach zu realisieren ist.

4.1.4 Single IT-Systeme

Seit Anfang der neunziger Jahre versuchen die führenden IT-Systemhersteller die Probleme, die durch die Daten- und IT-System-Heterogenität entstanden sind, zu lösen, indem sie ans-pruchsvolle und komplexe Single-IT-Systeme – quasi „Alleskönner“ – entwickeln. Solche Systeme sollen durch ihre umfangreichen Funktionalitäten, Workflows und Schnittstellen in der Lage sein, die zahlreichen Inselsysteme, die innerhalb der Unternehmen historisch über die

Page 60: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

42 Stand der Forschung und der Technik

Jahre gewachsen sind, abzulösen. Als Grundlage bzw. Orientierungshilfe zur Konzipierung und Entwicklung solcher IT-Systeme wurden in der letzten Zeit mehrere Integrationsrefe-renzmodelle wie z.B. der PLM-Ansatz (s. Kapitel 4.3), das CIM- oder das ARIS-Modell ent-wickelt. Im Folgenden werden das CIM- und das ARIS-Modell kurz beschreiben:

CIM-Modell

Unter dem Begriff CIM (Computer Integrated Manufacturing) ist die Integration der techni-schen Funktionen der Konstruktion und Entwicklung, der Fertigungsvorbereitung, der Ferti-gung und Montage, des Prüfens und Testens, sowie der Qualitätssicherung mit den betrieblich-organisatorischen Teilfunktionen der Produktionsplanung und –steuerung (PPS) und weitge-hend mit den Funktionen des Einkaufs (Bestell- und Lieferantenwesen) und Versands sowie des Auftragszentrums (Auftragsbearbeitung und –überwachung) zu einem organisatorisch und informationstechnisch funktionierenden Gesamtablauf gemeint [RuGo1991].

Das Ziel von CIM ist die unternehmensweite und ggf. auch unternehmensübergreifende Au-tomatisierung und Integration sämtlicher Informationsflüsse (Informationsintegration), so dass die gemeinsame und bereichsübergreifende Nutzung sämtliche Informationen möglich ist (Abbildung 4-3). Dadurch wird gleichzeitig eine Funktionsintegration erzielt [RuGo1991].

Konstruktion

Arbeitsplanung

Stück-listen

Arbeits-pläne

Betriebs-mittel

Fertigungssteuerung

Betriebsdatenerfassung

Kontrolle (Mengen, Zeiten, Kosten)

Versandsteuerung

Steuerung von NC-, CNC-, DNC-

Maschinen und Robotern

Transportsteuerung

Lagersteuerung

Montagesteuerung

Instandhaltung

Qualitätssicherung

NC-ProgrammierungAuftragsfreigabe

Planung des Primärbedarfs

PPSPrimär betriebswirt-

schaftlich planerischeFunktionen

CAD/CAMPrimär technische

Funktionen

Plan

ung

Pla

nung

Steu

erun

g

Steu

erun

g

CAQ

CAM

und -Steuerung

ZentraleDaten-

verwaltung

Produktentwurf

Kapazitätsabgleich

Kapazitätsterminierung

Materialwirtschaft

Kalkulation

Auftragssteuerung (Vertrieb)

Abbildung 4-3: Darstellung des Integrationsgedanken von CIM im Y-CIM-Modell nach Scheer [Sche1990]

Page 61: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 43

Hierdurch sollten alle an der Produktentstehung beteiligten technischen und administrativen Unternehmensbereiche und IT-Systeme (CAD, CAM23, CAQ24, CAP25 und PPS26) integriert werden. Zur datentechnischen Integration des CIM-Informationsflusses wurden mehrere CIM-Integrationsebenen definiert, die sukzessive aufeinander aufbauen [RuGo1991]:

Integrierte Unternehmensverwaltung

Integrierte Verfahrenskettenverwaltung

Integrierte Informationsverwaltung

Integrierte Kommunikationsverwaltung

In der Praxis fand ein Teil des CIM-Konzepts seine Verwendung in mehreren IT-Anwendungen wie z.B. ERP27- und PDM-Systeme.

ARIS

Die Abkürzung ARIS steht für Architektur integrierter Informationssysteme und wurde von A.-W. Scheer entwickelt. ARIS stellt ein Rahmenkonzept zur ganzheitlichen Beschreibung (Modellierung) computergestützter Informationssysteme von Fachkonzept bis zur Implemen-tierung [Sche2001]. ARIS stützt sich hauptsächlich auf seine eigene Fünf-Sichten-Architektur (ARIS-Haus). Diese fünf Sichten sind die Organisations-, Daten-, Leistungs-, Funktions- und Steuerungssicht auf einen Prozess. Die Einteilung erfolgt, um die Komplexität des Modells in fünf Facetten aufzubrechen und so die Prozessmodellierung einfacher zu ge-stalten. Jede Sicht des ARIS-Konzeptes gibt das Modell eines Geschäftsprozesses unter einem bestimmten Aspekt wieder (Abbildung 4-4) [Sche2001]:

Funktionssicht: Die Vorgänge, die Leistungen transformieren, und die zwischen ihnen bestehenden statischen Beziehungen werden in der Funktionssicht beschrieben.

Organisationssicht: Die Organisationssicht beschreibt alle Ressourcen (menschliche Arbeitskräfte, Maschinen, Hardware), das heißt alle Organisationseinheiten und ihre Beziehungen.

Datensicht: Die Datensicht beschreibt alle Ereignisse (die Daten generieren) und Um-felddaten, wie Schriftverkehr, Dokumente etc., das heißt alle unternehmensrelevanten Informationsobjekte.

Leistungssicht: Die Leistungssicht beschreibt alle Dienst-, Sach- und finanziellen Leis- 23 CAM: Computer Aided Manufacturing 24 CAQ: Computer Aided Quality 25 CAP: Cmputer Aided Planing 26 PPS: Produktionsplanung und –steuerung 27 ERP: Enterprise Resource Planning-Systeme unterstützen Unternehmen bei der Planung von Ressourcen (z.B. Material-, Personal-, Produktionsressourcen)

Page 62: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

44 Stand der Forschung und der Technik

tungen.

Steuerungssicht: Die Steuerungssicht beschreibt die Integration der vorangegangenen Sichten in einen logischen (nicht zeitlichen) Ablaufplan, das heißt Verknüpfung der an-deren Sichten.

Jede Beschreibungssicht des ARIS-Hauses ist in drei Beschreibungsebenen eingeteilt [Sche2001]:

Fachkonzept: Strukturierte Darstellung eines Prozesses mittels DV28-fremden Beschrei-bungsmodellen (je nach Sicht z. B.: ERM29, EPK30, Organigramm, Funktionsbaum).

DV-Konzept: Umsetzung des Fachkonzeptes in DV-nahe Beschreibungsmodelle (je nach Sicht z. B. Relationen, Struktogramme, Topologien).

Implementierungsebene: DV-technische Realisierung der beschriebenen Prozessteile (je nach Sicht z. B. mittels Erstellung von Programmcode, Datenbanksystemen, Einsatz von Protokollen).

In der Praxis bildet das ARIS-Konzept die Grundlage von verschiedenen Software-Produkten, beispielsweise das ARIS Toolset oder die grafischen Prozessintegration der SAP Exchange Infrastructure.

Fach-konzept

DV-Konzept

Implementierung

Fachkonzept

DV-Konzept

Implementierung

Fachkonzept

DV-Konzept

Implementierung

Fachkonzept

DV-Konzept

Implemen-tierung

FachkonzeptDV-Konzept

Implementierung

Daten Steuerung Funktion

Leistung

Abbildung 4-4: ARIS-Haus [Sche2001]

28 DV: Datenverarbeitung 29 ERM: Entity Relationship Modell 30 EPK: Ereignisgesteuerte Prozesskette

Page 63: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 45

Die in Anlehnung an die verschiedenen Integrationsmodelle bzw. Ansätze entwickelten Single IT-Systeme haben zur Realisierung eines integrierten Managements von Daten, Prozessen und IT-Anwendungen innerhalb der einzelnen Disziplinen einen wertvollen Beitrag geleistet. Als bedeutende Vertreter derartiger Systeme können hier z. B. die PDM-, ERP- oder SCM-Systeme (s. Kapitel 4.3) genannt werden. Jedoch weisen diese Single IT-Systeme einige Schwächen auf:

Sie sind sehr domänenspezifisch konzipiert und können zur Unterstützung interdiszipli-närer Prozessaktivitäten nur begrenzt eingesetzt werden.

Sie sind unflexibel im Hinblick auf Geschäftsprozessänderungen und Einführung von zusätzlichen, neuen IT-Systemen.

Die Einführung solcher Systeme ist zeitaufwendig und kostspielig.

Sie erhöhen die Abhängigkeit der Unternehmen von bestimmten IT-Systemherstellern und somit beschränken sie die Auswahl von weiteren Lösungsalternativen.

4.1.5 Enterprise Application Integration (EAI)

EAI steht für Enterprise Application Integration. Der Begriff wurde durch das Bemühen ge-prägt, viele IT-Anwendungen, die nicht für eine Zusammenarbeit entworfen wurden und auch nur Teilaufgaben von Geschäftsprozessen abdecken, dazu zu bringen, in einheitlichen Ge-schäftsprozessen zusammenzuarbeiten. Es geht also darum, heterogene Anwendungen eines Unternehmens so zu integrieren, dass sie sich möglichst so verhalten, als wären sie von An-fang an dafür entworfen worden, die aktuellen Geschäftsprozesse zu unterstützen [Kell2002]. Der EAI-Ansatz ist dergestalt, dass durch Einbringung eines zentralen (Hub&Spoke) oder dezentralen (Bus) Verbindungselements in Form sogenannter Integrations-server die Komplexität von N/2*(N-1) Punkt-zu-Punkt-Verbindungen auf N Verbindungen zwischen N Applikationen und dem Integrationsserver selbst reduziert werden können [Schm2006].

Den Kern des EAI-Konzepts stellt eine Schichtenarchitektur dar, welche aus drei Schichten besteht: Kommunikationsschicht, Protokoll-Adapterschicht und Prozessschicht. Eine Über-sicht über diese Schichten und deren Verantwortlichkeiten wird in der folgenden Tabelle 4-2 und in der Abbildung 4-5 gegeben [Kell2002]:

Schicht Verantwortlichkeiten

Kommunikationsschicht

Die Kommunikationsschicht transportiert Nachrichten (Messages) zwischen Sendern und Empfängern. Sie ist ebenfalls für das Finden des richtigen Empfängers einer Nachricht (Routing), für die Sicherheit von Aufrufen und für die Konvertierung von Nachrichten zwischen verschie-denen Formaten verantwortlich.

Page 64: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

46 Stand der Forschung und der Technik

Protokoll-Adapterschicht

Die Protokoll-Adapterschicht ist dafür verantwortlich, dass externe Auslöser, wie Funktionsaufrufe, Datenbankupdates, E-Mail und andere Arten von externen Ereignissen, in Nachrichten umgewandelt werden.

Prozessschicht

Die Prozessschicht erlaubt es, komplexe Kommandos und Abläufe aus einfachen Kommandos und Aufrufen zusam-menzubauen. Wenn ein Prozess in einen bestimmten Zu-stand gelangt, kann er Nachrichten verschicken.

Tabelle 4-2 EAI-Schichten

Prozessschicht

Kommunikationsschicht

Protokoll-Adapterschicht

E-M

ail

http

Lega

cies

Wei

tere

Abbildung 4-5: EAI-Referenzarchitektur [Kell2002]

Heutige EAI-Lösungen verfolgen im Wesentlichen je nach Anwendungsart vier verschiedene Integrationsansätze: Integration über Benutzungsschnittstelle, Integration über Funktionsauf-rufe, Integration über Datenbanken und Integration über Komponenten.

Die Grundidee bei der Integration über die Benutzungsschnittstelle besteht darin, auf die Be-nutzungsschnittstellen existierender Anwendungen eine neue Benutzungsschnittstelle aufzu-setzen. Diese neue Benutzungsschnittstelle wird entweder mit dem Ziel implementiert, besser benutzbar zu sein, oder mit dem Ziel, durch die Integration mehrerer Anwendungen eine bes-sere Funktionalität oder eine konsistente Führung durch Geschäftsprozesse bieten zu können [Kell2002]. Eine einfache Art, Anwendungen über die Benutzungsoberfläche zu integrieren, ist die Web-Integration mit Frames31, wie z. B. in Form von Web Portalen.

Bei der Integration über Funktionsaufrufe werden aus einer Applikation die Funktionen einer anderen Applikation aufgerufen. Der Funktionsaufruf lässt sich entweder mittels Senden von 31 Frame: Ein Frame ist ein Teilbereich einer Web-Seite, in dem eine andere Web-Seite dargestellt werden kann.

Page 65: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 47

Nachrichten (Message-basierte Kommunikation) oder auf Basis von direkten Schnittstellen (Interface-basierte Kommunikation) realisieren.

Die zentrale Idee bei der Integration über Datenbanken ist, dass mehrere Anwendungen über eine gemeinsame Datenbasis kommunizieren. Dabei sind zwei Hauptszenarien zu unterschei-den [Kell2002]:

Eine Anwendung benutzt mehrere Datenbanken, die aber durch Middleware zu einer gemeinsamen logischen Datenbank zusammengefasst werden, oder

mehrere Anwendungen benutzen eine gemeinsame Datenbank und kommunizieren über diese.

Bei der Integration über Komponenten können mehrere Integrationsformen realisiert werden, wobei hier eine Komponente als ein Stück Software mit einer definierten Schnittstelle be-zeichnet wird [Kell2002]:

Plug-ins: die Integration von Komponenten an dafür vorgesehenen Stellen. Dabei wer-den bestimmte verschiedene Schnittstellen vorgegeben, die die Komponente erfüllen muss.

GlueWare: die Integration von vorgefertigten Komponenten mittels „Klebstoff“. Dieser Klebstoff kann z. B. ein EAI-Integrationsserver sein.

Container: die Integration von Komponenten in sogenannten Containern. Dieses Modell wird an verschiedenen Stellen wie z.B. GUIs32 verwendet.

In der Praxis sind in den letzten Jahren mehrere Industriestandards auf Basis der EAI-Prinzipien entstanden, um eine einheitliche und einfache Implementierung von EAI-basierten Integrationslösungen in Form von Middleware-Lösungen zu ermöglichen. Als prominente Beispiele dieser Industriestandards werden CORBA und EJB im Folgenden kurz vorgestellt:

CORBA

CORBA steht für Common Object Request Brocker Architecture und wird von der OMG33 entwickelt. CORBA ist eine Spezifikation für eine objektorientierte Middleware, deren Kern ein sog. Object Request Broker, der ORB bildet, und die plattformübergreifende Protokolle und Dienste definiert. Hierzu unterstützt CORBA sprachunabhängige Schnittstellendefinitio-nen von Komponenten und die transparente Verteilung von Objekten. Auf jedem Rechner, den ein CORBA-basiertes Informationssystem nutzt, ist ein CORBA-konformer ORB implemen-tiert. Ein Dienst auf einem entfernten Rechner wird aufgerufen, indem eine den Dienst reprä-sentierende Schnittstelle, das so genannte stub inteface, aufgerufen wird. Das stub inteface übergibt den Aufruf an den lokal installierten ORB, welcher wiederum den aufgerufenen 32 GUI: Graphical User Interface (Graphische Benutzeroberfläche) 33 OMG: Object Management Group

Page 66: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

48 Stand der Forschung und der Technik

Dienst lokalisiert und den Aufruf an den entsprechenden ORB weiterleitet. Dieser ORB ruft das so genannte skeleton interface des Dienstes auf, eine implementierungsunabhängige, loka-le Schnittstelle des Dienstes. Diese Schnittstelle wiederum ruft den eigentlichen Dienst auf und liefert dessen Ergebnis an den ORB zurück. Über den ORB des aufrufenden Dienstes wird schlißlich das Ergebnis an diesen zurückgeliefert [ENGE2006].

EJB

Enterprise JavaBeans (EJB) ist ein Industriestandard, der von der Firma Sun unter maßgebli-cher Beteiligung der Firmen IBM, Oracle und anderen im März 1998 als Spezifikation verab-schiedet wurde. Der Standard spezifiziert ein serverseitiges Komponentenmodell für verteilte Informationssysteme. Er setzt dabei auf der Programiersprache Java und den Technologien, die durch die Bibliotheken der Jave 2 Enterprise Edition (J2EE) zur Verfügung stehen, auf [ENGE2006].

Für den übergreifenden Aufruf von Diensten bietet EJB verschidene Alternativen [EN-

GE2006]:

Web Services: Fachkomponenten (in der EJB-Terminologie Beans) können direkt durch Web Services repräsentiert werden.

IIOP: EJB unterstützt die Implementierung des IIOP-Standards von J2EE.

Java: Der Standard von J2EE für den Aufruf von entfernten Methoden kann verwendet werden (Java Remote Method Protocol, Abk.: JRMP).

JMS: Für den Einsatz von nachrichtenorientierter Middleware kann der Java Message Service (JMS) Standard verwendet werden.

Die ersten beiden Alternativen bieten dabei den Vorteil einer Java-unabhängigen Schnittstelle, während die beiden letzten Alternativen voraussetzen, dass sowohl Dienstnehmer als auch Dienstgeber mit Java realisiert wurden [ENGE2006].

Die EAI-Ansätze sind heute in diversen Ausprägungen als IT-Integrationslösungen zu finden wie z. B. Application to Application- (A2A), Business to Business- (B2B) und Person to Sys-tem-Lösungen (P2S). Dennoch erwies sich die Einführung solcher Lösungen in der Praxis als sehr aufwendig und risikobehaftet. Die Aberdeen Group kommt in [ABER2002] zu dem Schluss, dass mehr als 70% der EAI-Projekte nicht erfolgreich waren. Das Ziel – prozessorien-tierte Integration heterogener IT-Systeme zur Unterstützung der Geschäftsprozesse – hat EAI in der Praxis kaum erreicht [AiSc2005]. EAI-Produkte werden heute fast ausschließlich für die Integration von System zu System eingesetzt, d. h. die Kopplung von Applikationen für den automatisierten Datenaustausch [Schm2006]. Die mäßige Entwicklung des EAI-Ansatzes ist auf mehrere Ursachen zurückzuführen:

Aus IT-Sicht schaffen EAI-Lösungen eine enge und feste Kopplung der IT-Anwendungen zueinander, was zu einer Einschränkung der Flexibilität, Agilität sowie

Page 67: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 49

der Anpassbarkeit der gesamten IT-Systemlandschaft führen kann.

EAI-Lösungen sind keine schlüsselfertigen Produkte und ihre Einführung ist mit einem enormen Aufwand verbunden. Dieser Aufwand entsteht vor allem beim Entwurf und der Implementierung der notwendigen Schnittstellen und Adapter, was in den meisten Fällen ca. 80% der gesamten Projektkosten ausmacht [Kell2002].

EAI-Lösungen sind sehr technologiegebunden und herstellerabhängig, deshalb sind sie sehr spezifisch und untereinander nicht kompatibel [Welt2005].

4.1.6 Semantische Technologie

Die semantischen Technologien zielen darauf ab, eine höhere technische Interoperabilität zwi-schen unterschiedlichen IT-Systemen innerhalb einer heterogenen IT-Landschaft zu ermögli-chen. Hier steht vor allem die Ermöglichung der Interaktion von dispersen Datenbeständen und Anwendungen auf technischer, organisatorischer und semantischer Ebene im Vorder-grund, ohne dass die Autonomie der einzelnen Teilsysteme aufgehoben wird [BlPe2006]. Die semantischen Technologien verfolgen den Ansatz, Daten mit Struktur (Syntax) und Be-deutung (Semantik) zu versehen mit dem Ziel, diese von Maschinen bzw. Software interpre-tierbar und für vorher nicht notwendigerweise vorgesehene Zwecke wieder- und weiterver-wendbar zu machen [HKRS2007]. In diesem Zusammenhang spricht man davon, Daten ma-schinenlesbar und -interpretierbar bereitzustellen.

Die Idee der semantischen Technologien stammt aus den neunziger Jahren und greift auf fun-dierte Vorarbeiten aus der künstlichen Intelligenz (z. B. Interferenzmaschinen, Expertensys-teme, fallbasiertes Schließen, statistische Datenanalyse), der Wissensrepräsentation (z. B. Knowledge Engineering, Wissensmodellierung, Datenbankprogrammierung und -mo-dellierung) sowie der Sprachverarbeitung (Texterkennung und -verarbeitung) zurück [John2006]. Dieser Ansatz hat vor allem innerhalb des Internetumfelds erheblich an Bedeu-tung gewonnen und wird heute überwiegend im Zusammenhang mit der Web-Technologie weiterentwickelt. Dieser Web-spezifische Ansatz ist inzwischen unter dem Begriff Semantic Web bekannt und wird hauptsächlich durch das W3C34 als Erweiterung des WWW35-Standards spezifiziert und entwickelt. Ziel und Vision des Semantic Web ist es, die im World Wide Web verfügbare Information in einer dem Menschen verständlichen und für Maschinen lesbaren Form vorzuhalten [John2006]. Das Semantic Web versteht sich dabei als ein über das „Web of Links“ hinausgehendes „Web of Meaning“, in dem ein Verstehen der Bedeutun-gen und der logischen Verbindungen zwischen Informationen möglich wird [FHLW2003]. Dabei basiert es auf zwei einfachen Grundprinzipien. Zum einen werden die im World Wide Web verfügbaren Ressourcen wie z. B. Web-Seiten, Bilder, Textdateien über einen eindeuti-

34 W3C: World Wide Web Consortium 35 WWW: World Wide Web

Page 68: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

50 Stand der Forschung und der Technik

gen Bezeichner identifiziert, zum anderen werden eben diese Ressourcen semantisch annotiert [John2006]. Hierfür sind zwei zentrale Bausteine, die sogenannten Ontologiesprachen RDF36 und OWL37, durch das W3C bereitgestellt worden, welche zu strukturierter Beschrei-bung von Informationen und ihren Beziehungen und zur Formulierung von Regeln und Schlussfolgerungen innerhalb einer Wissensdomäne dienen können.

Unternehmen, die heute die semantischen Technologien bzw. das Semantic Web innerhalb ihrer betrieblichen Anwendungen einführen, verfolgen insbesondere die folgenden Ziele [John2006]:

Einerseits soll dem Mitarbeiter mithilfe semantischer Technologien ein „intelligenter Zugang“ zu Informationen bzw. eine kontextspezifische Suche angeboten werden.

Andererseits sollen über semantische Web Services die Datenverarbeitungsprozesse aus unterschiedlichen Anwendungen integriert werden, um ein qualitativ besseres Informa-tionsmanagement umzusetzen.

Eine vom Fraunhofer Institut (Rechnerarchitektur und Softwaretechnik) durchgeführte Studie [John2006] über die semantische Technologie in der betrieblichen Anwendung hat gezeigt, dass in der Praxis eine große Skepsis und Unsicherheit bei Unternehmen, vor allem bei An-wendern und IT-Beratern, im Hinblick auf die Anwendung dieser semantischen Technologien herrscht. Ein Großteil der befragten Unternehmen sieht die auf dem Markt vorhandenen Tech-nologien noch nicht als ausgereift an, um sie mittelfristig einzusetzen. Einer der Hauptgründe dieser vorsichtigen bis negativen Meinungen ist die fehlende Standardisierung des Design-, Implementierungs- und Wartungsprozesses der Ontologien, was zwangsläufig zu einer Viel-zahl von heterogenen Ordnungssystemen, die nebeneinander existieren, führt [John2006]. Eine weitere Barriere für die semantische Anwendungsintegration besteht darin, dass die se-mantischen Technologien und Verfahren sehr vielfältig sind und somit den Nutzer verunsi-chern. So liefern z. B. Anfragen an verschiedene Suchmaschinen unterschiedliche Suchergeb-nisse. Den semantisch basierten Informationssystemen (z. B. Wissensmanagementsysteme) liegen in der Regel unterschiedliche Strukturen und Terminologien zur Aufbereitung der In-halte zugrunde. Somit sind die Prozesse der Recherche und automatischen Informationsschlie-ßung häufig von Zufällen geprägt, was das Vertrauen in die Technologien einschränkt [John2006]. Zudem ist heute der Aufwand zur Modellierung, Gewinnung und Pflege der semantischen Daten aufgrund der hohen Komplexität der gängigen Werkzeuge wie z.B. Onto-logie-Editoren im semantischen Technologieumfeld sehr hoch [ToMa2006]. Zwar stellt die semantische Technologie nach wie vor ein spannendes Forschungsfeld sowie einen für die Zukunft vielversprechenden Ansatz dar, die bisher erreichten Resultate auf Methoden- sowie auf Werkzeugebene lassen jedoch einen prozesssicheren Einsatz insbesondere als Integrations- 36 RDF: Resource Description Framework 37 WOL: Web Ontology Language

Page 69: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 51

lösung unterschiedlicher IT-Anwendungen als sehr fragwürdig erscheinen – zumindest in nä-herer Zukunft.

4.1.7 Serviceorientierte Architektur (SOA)

SOA steht für serviceorientierte Architektur. Die Haupthypothese der SOA ist, dass die infor-mationstechnische Infrastruktur jedes Unternehmens sich strikt den geschäftlichen Interessen und Prozessen unterordnet [KrBS2004]. SOA unterliegt ausschließlich einer geschäftlichen „Business“-Motivation, wobei die IT nur als Mittel zum Zweck betrachtet wird. Hierzu sieht das SOA-Konzept vor, Anwendungen oder Anwendungsbestandteile als Services (Dienste) zu konzipieren, die sich hardware- und softwaremäßig beliebig verteilen und sich dynamisch zur integrierten Unterstützung von Geschäftsteilprozessen verknüpfen lassen [HeLe2005]. Dabei werden die Services ausschließlich von bestehenden Applikationen oder anderen Services ge-nutzt. Hierfür ist es unerheblich, welche Hard- oder Software, Programmiersprachen oder Be-triebssysteme die einzelnen verwenden [DJMZ2005].

Obwohl das SOA-Konzept hauptsächlich prozessgetrieben ist, verspricht seine Einführung eine Reihe von technischen Nutzpotenzialen, welche im Folgenden dargestellt werden [RiHS2005] [An2007]:

Erhöhung der technischen Interoperabilität innerhalb einer heterogenen IT-Systemlandschaft mit dem Hauptziel, eine durchgängige und integrierte Durchführung der Geschäftsprozesse zu ermöglichen.

Reduktion der Systemlandschafts-Komplexität mittels der Kapselung von Implementie-rungsdetails hinter definierten Schnittstellen. Die Einführung einer SOA trägt daher da-zu bei, die Beherrschbarkeit der unternehmensweiten IT-Systemlandschaft zu verbes-sern.

Durch Wiederverwendung bestehender fachlicher Komponenten sowie durch deren In-tegration über die einheitliche SOA-Infrastruktur können mittelfristig Entwicklungs- und Wartungskosten für die IT-Systeme eingespart werden.

Bewährte Legacy-Systeme können weiter betrieben werden, ohne dass die modernen Systeme von technologischen Altlasten abhängig gemacht werden. Die SOA bietet da-her einen hohen Investitionsschutz. Aus diesem gleichen Grund begünstigt die SOA ei-ne evolutionäre Entwicklung der Anwendungslandschaft, da einzelne Komponenten durch die lose Kopplung leichter abgelöst werden können.

Eine bestehende, gewachsene Anwendungslandschaft kann fachlich so partitioniert und in erneuerbare Bestandteile zerlegt werden, dass eine gestufte Ablösung auch von mo-nolithischer und gewachsener Software möglich wird.

Trotz zahlreicher Publikationen in Wissenschaft und Praxis existiert zum heutigen Zeitpunkt keine einheitliche bzw. standardisierte Beschreibung oder Darstellung, welche den SOA-

Page 70: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

52 Stand der Forschung und der Technik

Ansatz begreiflich macht. Diese Definitionslücke wird heute von vielen IT- bzw. Software-herstellern genutzt, um ihre IT-Systeme, die nur einzige SOA-Teilaspekte beinhalten (bei-spielsweise Middlewaresysteme, webbasierte Thin-Client-Lösungen, Web-Portal-Lösungen), als SOA-Lösungen zu vermarkten.

Angesichts dieser Situation hat die OASIS38 vor ein paar Jahren den Versuch gestartet einen entsprechenden SOA-Standard zu definieren. Das Ergebnis dieser Initiative ist die Entstehung des „Reference Model for Service Oriented Architecture“ und der „Reference Architecture for Service Oriented Architecture“:

Reference Model for Service Oriented Architecture [OASI2006]: Dieses Dokument umfasst in erster Linie eine Reihe von Begriffserklärungen für IT-Entwickler und –Architekten. Ziel dieses Dokuments ist es, die zunehmende Begriffsverwirrung um SOA einzudämmen – das zumindest hoffen die Autoren des Dokuments –.

Reference Architecture for Service Oriented Architecture [OASI2008]: Dieses Doku-ment liefert ein abstraktes Rahmenwerk, das vor allem die Eigenschaften und die Be-ziehungen eines Services mit seinem Umfeld innerhalb einer serviceorientierten Archi-tektur beschreibt.

Durch die OASIS-Bemühung wurden viele Definitionen und Prinzipien zur Konzipierung bzw. Entwicklung von SOA-basierten Ansätzen festgelegt, was zur Erleichterung des SOA-Grundverständnisses bei der Durchführung von SOA-Vorhaben führen kann. Allerdings sind OASIS-Modelle sehr abstrakt und haben keinen direkten Bezug zur tatsächlichen Umsetzung bzw. Realisierung einer serviceorientierten Architektur. Daher lassen die OASIS-Modelle noch viele Fragen offen wie z.B.:

Wie sieht eine serviceorientierte Architektur zur prozessgetriebenen Integration aus?

Wie wird ein Service realisiert?

Wie wird ein Service für die Prozessintegration verwendet?

Wie wird eine serviceorientierte Architektur umgesetzt?

Aufgrund fehlender umfassender Beschreibung wird im weiteren Verlauf dieser Arbeit SOA als Architektur-Paradigma betrachtet, das sich wie folgt definieren lässt:

Die serviceorientierte Architektur (SOA) ist ein Paradigma für die Realisierung einer unternehmensweiten Business-Architektur, deren zentrales Konstruktionsprinzip lose gekoppelte Services (Dienste) sind. Mittels Services werden die Fachfunktionalitäten unterschiedlicher Applikationen über eine implementierungsunabhängige Schnittstelle gekapselt, um diese anschließend im Rahmen einer Prozessintegration entlang der be-

38 OASIS: Organization for the Advancement of Structured Information Standards.

Page 71: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 53

trieblichen Abläufe zu verschalten. Zu jeder Service-Schnittstelle gibt es einen Service-vertrag, der die funktionalen und nicht-funktionalen Merkmale der Schnittstelle be-schreibt [StTi2007], [SHVW2006], [OASI2008].

Bei einer serviceorientierten Architektur lässt sich die lose Kopplung wie folgt definieren:

Lose Kopplung ist eine bestimmte Art der Verbindung mehrerer Softwaresysteme mitei-nander. Im Vordergrund steht dabei eine möglichst geringe Abhängigkeit zwischen dem Aufbau der einzelnen Systeme. Im Gegensatz zur engen Kopplung können lose gekoppelte Systeme autonom agieren und lassen sich relativ leicht voneinander lösen und flexibel kombinieren.

Ferner ist eine serviceorientierte Architektur durch die Grundprinzipien bzw. Merkmale Inter-operabilität, Schnittstellenorientierung, Modularisierung und Geschäftsorientierung charakte-risiert [Hele2005] [OASI2008], die in der folgenden Tabelle 4-3 beschrieben werden:

Grundprinzip Beschreibung

Interoperabilität

Sowohl zur Servicebeschreibung als auch für die Interaktion, Kom-munikation und Nutzung der Services werden einheitliche, bereits akzeptierte Standards verwendet. Erst die Abstützung auf offene, platt-formunabhängige und verbreitete Standards ermöglicht die Interope-rabilität eines Service und seine Verwendungen in unterschiedlichen Kontexten.

Schnittstellenorientierung

Ein Service stellt eine stabile Schnittstelle dar, die von den Implemen-tierungsdetails, z. B. der verwendeten Programmiersprache und den Software-Komponenten, abstrahiert wird. Die Schnittstelle ist selbst-beschreibend, d. h. der Service ist über Metadaten technisch und fach-lich vollständig spezifiziert. SOA trennen damit die Beschreibung der Funktionalität in Form einer Schnittstelle von ihrer Implementierung.

Modularisierung

Eine SOA strukturiert die Applikationsarchitektur in eine überschau-bare Menge teilautonomer Subsysteme. Nach bekannten Prinzipien der Komponentenbildung werden dabei Funktionalität oder Ressour-cen mit großer Abhängigkeit (Kohäsion) untereinander so zusammen-gefasst, dass sie gegenüber den anderen Subsystemen eine möglichst geringe Abhängigkeit (lose Kopplung) aufweisen.

Geschäftsorientierung Services bieten Funktionalität auf einer groben, an Geschäftsaktivitä-ten orientierten Granularitätsebene und kapseln fachlich abgrenzbare, aus geschäftlicher Sicht sinnvolle und wertschöpfende Leistungen.

Tabelle 4-3 Grundprinzipien einer serviceorientierten Architektur

Page 72: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

54 Stand der Forschung und der Technik

Für die Realisierung einer serviceorientierten Architektur sind grundsätzlich zwei verschiede-ne Teilnehmer erforderlich, Service-Anbieter (Provider) und Service-Nutzer (Consumer). In öffentlichen SOA werden die Eigenschaften und Schnittstellen von Services sowie verwendete Nachrichtenformate im öffentlich zugänglichen Verzeichnis (Service Registry) bekannt ge-macht [Welt2005], [Wenz2004]. Die Tabelle 4-4 und die Abbildung 4-6 beschreiben die Teilnehmer einer SOA-Architektur:

Teilnehmer Beschreibung

Service Provider

Der Service Provider ist der Anbieter des Service. Er stellt die Implementierung eines Service sowie dessen Beschrei-bung und dessen Schnittstellen bereit. Der Service erhält vom Service Consumer Anfragen und führt diese aus. Ein Service Provider kann auch als Service Consumer auftreten und umgekehrt.

Service Registry

Bei einer Service Registry handelt es sich um ein zentrales, logistisches Verzeichnis von Services. Die Registry ist eine zentrale Stelle, in der Service-Anbieter ihre Services veröf-fentlichen können und Service-Nutzer existierende Services auffinden können.

Service Consumer

Der Service Consumer sucht in einer Service Registry nach dem gewünschten Service und verwendet bei der Suche gefundene Servicebeschreibungen zum Aufrufen des Servi-ce Provider.

Tabelle 4-4 Beschreibung der Teilnehmer einer serviceorientierten Architektur

Service ProviderService Consumer

Service Registry

Service aufrufen

Abbildung 4-6: Teilnehmer einer serviceorientierten Architektur

Page 73: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 55

Die Einführung einer einheitlichen technischen Basis bzw. IT-Infrastruktur für die Interaktion der Anwendungssysteme ist eine Voraussetzung für die Umsetzung einer serviceorientierten Architektur. Diese Infrastruktur soll neben der Entwicklung und dem Betrieb der Services wei-tere Funktionalitäten bereitstellen [StTi2007]:

Servicesteuerung „Services Orchestrierung“ im Sinne der Realisierung der Prozessin-tegration: Prozessintegration erfordert eine durchgängige Funktionsausführung über alle Applika-tionen hinweg, welche durch das Zusammenspiel bzw. die Interaktion von mehreren Services erreicht wird. Die IT-Infrastruktur muss daher über entsprechende Mechanis-men verfügen, um die Steuerung derartiger Interaktionen zwischen verschiedenen Ser-vices zu ermöglichen.

Technische Konnektivität zwischen allen Komponenten

Unterstützung heterogener Informationstechnologien: Die IT-Infrastruktur muss Brücken zwischen heterogenen Informationstechnologien schlagen. Service Consumer sind möglicherweise in anderen Programmiersprachen entwickelt als die von ihnen aufgerufenen Service Provider.

Kapselung verschiedener Kommunikationskonzepte: Die IT-Infrastruktur muss beispielsweise die Kommunikation synchroner und asynch-roner Komponenten miteinander ermöglichen.

Bereitstellung technischer Dienste: In einer SOA muss neben den eigentlichen (wertschöpfenden) Business-Services noch eine Reihe technischer Dienste vorhanden sein, wie etwa Logging, Autorisierung, Tran-saktionsmanagement oder Nachrichtentransformation.

Die oben genannten Funktionalitäten können heute zum großen Teil von zahlreichen EAI-Lösungsansätzen wie z. B. CORBA oder EJB (s. Abschnitt 4.1.5) realisiert werden, demzufol-ge sind sie auch als Basis für eine SOA-Infrastruktur gut geeignet. Allerdings spielen derzeit in der Praxis die Web Services-Technologie und die damit verbundenen Standards die Rolle der tragenden Technologie für den Aufbau einer SOA-Infrastruktur [RiHS2005]. Dies ist dar-auf zurückzuführen, dass die Web Services-Technologie auf dem XML-Standard basiert, wel-cher zu den am meisten verbreiteten und akzeptierten Standards zählt. Die Web Services-Technologie verfügt darüber hinaus über Standardkomponenten wie z. B. WSDL39, SOAP40 und UDDI41, die als Grundlage für die Realisierung von einfachen und flexiblen SOA-Infrastrukturen – im Vergleich zur EAI-Lösungsansätzen – dienen können. Ein weiterer Vor-

39 WSDL: Web Service Description Language (s. Kapitel 5.3) 40 SOAP: Simple Object Access Protocol (s. Kapitel 5.3) 41 UDDI: Universal Description, Discovery and Integration (s. Kapitel 5.3)

Page 74: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

56 Stand der Forschung und der Technik

teil einer standardisierten Infrastruktur auf Basis von Web Services liegt in der Interoperabili-tät von Softwareprodukten. So statten die großen Softwareproduzenten ihre Produkte zuneh-mend mit Web Service-basierten Schnittstellen aus, um den Vorteil einer einfachen Integration bieten zu können [RiHS2005]. Im Bereich der Infrastrukturkomponenten stehen inzwischen Produkte von allen namhaften Herstellern bereit (z. B. SAP NetWeaver, IBM WebSphere, Microsoft .Net, Oracle SOA Suite). Nicht alle stellen Web Services in das Zentrum, aber alle bieten zumindest die Möglichkeit Web Service-basierter Kommunikation [RiHS2005].

Obwohl die Basis-Technologien und Standards für die Umsetzung des SOA-Paradigmas seit langer Zeit in ausgereifter Form vorhanden sind, existieren in der Praxis bislang fast keine Unternehmen, die das SOA-Konzept mit den dazu gehörenden Zielen vollständig realisiert haben. Zu den Gründen dafür zählen eine fehlende standardisierte, detaillierte und umfassende Modellbeschreibung für eine serviceorientierte Architektur sowie eine etablierte Methodik für die Umsetzung derartiger Architekturen. Dies führt in der Praxis vor allem dazu, dass bei SOA-Initiativen oder -Projekten der Fokus häufig stark auf wenige Teilbereiche bzw. Einzel-aspekte – meistens technischer Art – gerichtet wird. Der nutzbringende Charakter von SOA als unternehmensweites Business-Konzept geht dadurch leicht verloren, und mit ihm ein erhebli-cher Teil des möglichen Mehrwerts [StTi2007]. Um die Wahrscheinlichkeit eines SOA-Erfolges zu erhöhen, müssen Unternehmen akzeptieren, dass SOA eine strategische Geschäfts-initiative ist und kein taktisches Technologieprojekt. Daher ist eine konzentrierte Planung und Erstellung einer SOA-Einführungsstrategie gemäß den SOA-Prinzipien von großer Bedeutung und sehr erforderlich [DJMZ2005]. Mit anderen Worten soll SOA eher als Rahmen bzw. als Lebensweise „Lifestyle“ und nicht als IT-Lösung verstanden und angewendet werden [Ma-

ne2003].

Dass SOA in der Wirtschaft heute und in der Zukunft ein wichtiges Thema ist, zeigen auch die Zahlen aus der Studie „SOA Check 2007“ vom IT- Beratungsunternehmen S.A.R.L Martin [Mart2007]: 31% der Unternehmen sind dabei, SOA einzuführen, oder sie haben teilweise SOA-Teilaspekte eingesetzt, 42% der Unternehmen planen den Einsatz von SOA und nur 17% planen zurzeit keinen Einsatz von SOA-Konzepten. Bei der Interpretation dieser Zahlen muss natürlich auch die nicht vorhandene einheitliche SOA-Definition berücksichtigt werden.

4.2 Produktdatenintegration

Der Ansatz der Produktdatenintegration hat zum Ziel, verschiedene IT-Systeme durch den Einsatz eines standardisierten Produktdatenmodells und die Bereitstellung von standardisierten Diensten auf Datenebene zu integrieren. Die Hauptidee dabei sieht eine einheitliche syntakti-sche und semantische Beschreibung der Produktstruktur und -daten innerhalb des gesamten Produktlebenszyklus vor. Der Begriff Daten schließt dabei die Nutzdaten und die dazugehö-renden beschreibenden Daten (Metadaten) ein. Die Produktbeschreibung geschieht in der Re-

Page 75: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 57

gel auf Basis eines standardisierten Produktdatenmodells, welches durch alle am Entstehungs-prozess beteiligten IT-Werkzeuge interpretiert und bearbeitet werden kann.

Mehrere Konsortien aus Industrie und Forschung (wie z. B. Prostep iViP) haben sich in der Vergangenheit mit dem Ziel gebildet, derartige branchenspezifische Produktdatenmodelle zu entwickeln. Das Resultat dieser Bemühungen ist die Entstehung von mehreren Standarddaten-formaten, die heute zu Datenaustauschzwecken zwischen verschiedenen IT-Systemen insbe-sondere im CAx-Bereich innerhalb der Produktentstehung verwendet werden können. In den folgenden Abschnitten werden solche Ansätze, die im mechatronischen Umfeld eingesetzt werden können, näher durchleuchtet.

4.2.1 STEP

STEP „Standard for the Exchange of Product Model Data“ ist eine Normenreihe, die im Rah-men der ISO42 entwickelt wurde. Dieser Standard baut auf einem dateibasierten Prozessge-danken auf und soll hauptsächlich als Medium für den Produktdatenaustausch, die Produktda-tenspeicherung und -archivierung sowie die Produktdatentransformation dienen [AnTr2000]. STEP stellt eine Antwort auf die rasante Zunahme der Anzahl der Datenformate im CAx-Bereich und zugleich die Leistungsprobleme der vorherigen Standarddatenmodelle (wie z. B. IGES, SET, VDAIS, DXF) im Hinblick auf Kompatibilität, Konformität und Umfang der ab-zubildenden Daten dar. STEP ist kein fertiges Produktreferenzmodell für die Produktbeschrei-bung, sondern vielmehr ein Methodenkatalog und Baukasten für die Beschreibung anwen-dungsspezifischer Produktdatenmodelle, die als Serien der ISO-Normenreihe ISO 10303 er-schienen sind [GrEP1994]. Die Tabelle 4-5 zeigt einen Überblick der bis heute veröffentlich-ten Serien [Pham2007], [PROS2008]:

Serie Beschreibung 10er Serie Beschreibungsmethoden zu Spezifikation von Datenmodellen.

20er Serie Implementierungsmethoden zum Austausch von Produktdaten durch eine sequen-tielle Datei.

30er Serie Konformitätsprüfungsmethoden, beispielsweise zur Entwicklung und Strukturie-rung von Testfällen für auf STEP basierende Software-Systeme.

40er Serie Integrierte Produktmodelle sind Informationsmodelle, die Produktdaten unabhän-gig von einer speziellen Anwendung beschreiben.

100er Serie Anwendungsressourcen für bestimmte Anwendungsfälle wie beispielsweise FEM- oder MKS-Simulationen.

200er Serie Ein Anwendungsprotokoll (AP, Application Protocol) beinhaltet eine standardi-sierte Beschreibung von Produktdaten unter einem spezifischen Anwendungsas-

42 ISO: International Organization for Standardization

Page 76: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

58 Stand der Forschung und der Technik

pekt (Automobilbau, Schiffbau).

500er Serie Anwendungsspezifische Konstrukte zur Unterstützung der Entwicklung von An-wendungsprotokollen.

Tabelle 4-5 Überblick über die STEP-Serien

Die STEP- Referenzmodelle sind sehr umfangreich und umfassen zahlreiche Klassen, Attribu-te und Beziehungen, die durch eine große Menge von Diagrammen auf Basis der Modellie-rungsmethode Express_G abgebildet sind. Dies hat dazu geführt, dass die Datenmodelle sehr komplex und unüberschaubar sind und somit eine vollständige Umsetzung des Standards kaum möglich ist. Des Weiteren herrscht heute in der Praxis kaum ein Konsens zwischen den IT-Systemherstellern bei der Implementierung von STEP, was zur Entstehung mehrerer hers-tellerspezifischer STEP-Formate geführt hat, die nicht kompatibel zueinander sind. Aufgrund dessen ist der Einsatz von STEP als Datenaustausch bzw. Datenintegrationsformat häufig mit enormen Informationsverlusten verbunden. Weiterhin ist der STEP-Standard zur Integration von Modelldaten in erster Linie auf die Mechanik zugeschnitten [Czub2003]. Dagegen wur-den Aspekte aus elektrotechnischen und informationstechnischen Bereichen (z. B. Abbildung von Daten eingebetteter Software) kaum berücksichtigt. Daher ist der STEP-Standard als Da-tenmodell zur Integration von domänenspezifischen Partialdatenmodelle, Prozessen und IT-Werkzeugen innerhalb der Entwicklung mechatronischer Systeme nicht geeignet.

4.2.2 STEP-PDM-Schema

Das STEP-PDM-Schema wurde von ProSTEP und PDES Inc. entwickelt und in der ersten Version im Jahr 1997 veröffentlicht. Es stellt ein Referenz-Informationsmodell für den Aus-tausch von PDM-relevanten Daten in einer heterogenen Umgebung dar und legt die wesentli-chen Entitäten und Attribute fest, die für den PDM-Datenaustausch benötigt werden [PROS2008], [Gerh2000]. Das STEP-PDM-Schema soll die Integration von PDM-Systemen auf modelltechnischer Ebene bzw. die Bereitstellung von PDM-Daten anderer IT-Systeme ermöglichen [Czub2003]. Dieses Schema basiert auf Entitäten aus dem STEP-Standard und umfasst im Grunde eine Schnittmenge der PDM-relevanten STEP-Anwendungsprotokolle AP 203 (Configuration controlled design), AP 212 (Electrotechnical design and installation), AP 214 (Core data for automotive mechanical design process) und AP 232 (Technical data core packaging and exchange) [Czub2003].

Die im STEP-PDM-Schema abgebildeten Units of Functionality bilden somit typische PDM-relevante Daten zur Identifikation, Versionierung und Authentifizierung sowie zur Abbildung von Strukturen und Klassifikationen ab:

Page 77: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 59

Unit of Functionality Abzubildende Informationen Part and Document Identification ID, Name, Beschreibung etc.

Part and Document Classification Kategorien und Subkategorien

Part Properties Allgemeine Attribute und spezielle Eigenschaften wie Mate-rial und Form

Part Structure and Relationships Baugruppenstrukturen, Sichten, Stücklisten, Substitute

External Files Referenzen auf externe Dateien

Authorization Zugriffsrechte und Benutzerverwaltung

Configuration and Effectivity Information

Konfigurationseinheiten, Produktkonfigurationen und Effek-tivitäten

Engineering Change Work Orders, Aktivitäten

Tabelle 4-6 „Units of Functionalities“ für das PDM-Schema

Die Implementierung des STEP-PDM-Schemas soll analog zu den STEP-Anwendungs-protokollen erfolgen, so dass ein Datenaustausch über STEP Physical Files oder SDAI43 mög-lich ist [PROS2008]. Die Benchmarks für die PDM-Schema-Prozessoren haben in der Praxis gezeigt, dass die Prozessorentwicklung auf syntaktischer Ebene eine hohe Qualität erreicht hat. Probleme gibt es weiterhin auf semantischer Ebene, weil die semantischen Unterschiede der heterogenen PDM-Systeme und deren Daten derzeit viel zu groß sind, daher ist für die Implementierung des Schemas eine aufwendige und detaillierte Abstimmung zwischen den beteiligten Systemen erforderlich [Pham2007], [Gerh2000]. Weiterhin blieben viele me-chatronische Aspekte, insbesondere die elektrotechnischen und die informationstechnischen Entwicklungsprozesse und -daten bei der Definition dieses Schemas außer Acht, was seine Anwendung innerhalb eines interdisziplinären Umfelds wie die Mechatronik sehr einschränkt.

4.2.3 MechaSTEP

MechaSTEP (wird auch PAS 1013 genannt) ist die Abkürzung für „STEP Datenmodelle zur Simulation mechatronischer Systeme“. Ziel von MechaSTEP ist die Erstellung eines zu STEP konformen normungsfähigen Dokuments, welches ein neutrales Datenformat für den Daten-austausch zwischen Berechnungs- und Simulationssystemen beschreibt [Pham2007]. Dieses Datenmodell wurde innerhalb des Arbeitskreises MechaSTEP Industrie entwickelt, welcher durch mehrere deutsche Automobilhersteller initiiert und vom BMBF gefördert wurde [MECH2001].

43 SDAI: Standard Data Access Interface

Page 78: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

60 Stand der Forschung und der Technik

Das MechaSTEP-Datenmodell wurde basierend auf den im STEP-Datenmodell definierten Methoden und Konzepten entwickelt. Es erweitert die bisher für einige Bereiche vorliegenden Datenmodelle wie z. B. STEP AP 214 durch ein Datenmodell zur Unterstützung der Simulati-on mechatronischer Systeme. Es ermöglicht, produktdefinierte Daten aus den Bereichen Me-chanik, Elektrotechnik, Hydraulik und Regelungstechnik abzubilden und mit den Informatio-nen für die Berechnung und Simulation zu verknüpfen [MECH2001]. Das MechaSTEP-Datenmodell soll hauptsächlich als neutrales Datenformat für den Datenaustausch zwischen verschiedenen Simulationswerkzeugen sowie zur Ablage der Simulationsdaten und -ergeb-nisse in PDM-Systeme dienen (Abbildung 4-7), daher liegt sein Fokus prinzipiell auf der Be-schreibung der simulationsrelevanten Eigenschaften eines Produktes.

MechaSTEPSTEP Datenmodell zur Simulation mechatronischer Systemen

MechaSTEPDatenmodell

Abbildungvon

Elektrik

Abbildungvon

Hydraulik / Pneumatik

Abbildungvon Steuerungs-

technik Abbildungvon

Mechanik

Elektrik Hydraulik / Pneumatik Steuerungstechnik Mechanik

Abbildung 4-7: Umfang und Inhalt des Datenmodells MechaSTEP [MECH2001]

In der Praxis sind bis heute kaum entsprechende Prozessoren verfügbar. Zwar wurde die Machbarkeit für den Datenaustausch im Bereich der Mehrkörpersimulation nachgewiesen, für weitere Bereiche liegt eine Validierung jedoch nur eingeschränkt vor. Obwohl MechaSTEP mehr mechatronische Aspekte als im herkömmlichen STEP-Ansatz beinhaltet, bleibt dennoch seine Verwendung als Integrationsmedium für Daten und Prozesse innerhalb der Entwicklung mechatronischer Systeme aufgrund der folgenden Schwachstellen sehr fraglich:

Diese vollständige Anlehnung an den STEP-Standard führt gezwungenermaßen zur Vererbung seiner Defizite vor allem im Hinblick auf die Komplexität und Kompatibili-tät.

Bei der Entwicklung von MechaSTEP wurde im Wesentlichen Wert auf die Einbindung der Mehrkörpersimulationswerkzeuge gelegt; mechatronische Aspekte wurden nach wie

Page 79: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 61

vor nur unzureichend berücksichtigt, z. B. Aspekte aus dem Bereich Informationstech-nik.

4.3 Funktionsintegration

Um die Zusammenarbeit bzw. das Interagieren zwischen den verschiedenen heterogenen En-gineerings-Anwendungen innerhalb des Produktentwicklungsumfelds zu ermöglichen, wurden eine Reihe von Anwendungsfunktionen als Standarddienste oder Standardservices spezifiziert. Die Aufgabe dieser Dienste liegt darin, eine Integration der diversen Engineering-Anwendungen auf eine Anwendungsfunktionsebene zu unterstützen. Dabei verwenden die Engineering-Systeme diese Dienste, um die Funktionen andere Engineering-Systeme online aufzurufen und auszuführen. In den folgenden Abschnitten werden die zwei wichtigsten An-sätze aus diesem Umfeld „PDM-Enablers“ und „PLM Services“, welche eine weitere Ent-wicklung des STEP-Standards darstellen, näher erläutert.

4.3.1 PDM-Enablers

Die PDM-Enablers-Spezifikation wird seit 1996 unter dem Dach der OMG mit dem Ziel ent-wickelt, operationale Schnittstellen zu PDM-Systemen sowie PDM-Dienste in einer verteilten Systemumgebung zur Verfügung zu stellen [Czub2003], [Lämm2002], [EiSt2001].

Diese Spezifikation beschreibt eine standardisierte Schnittstelle für den Online-Zugriff von IT-Systemen auf PDM-Systeme und deren Dienste auf Basis von CORBA [FiKW2000], [Lä-

Ma1999]. Darüber hinaus wird es PDM-Systemen, die über eine nach PDM-Enablers defi-nierte Schnittstellenspezifikation verfügen, ermöglicht, gegenseitig Funktionen auf einen frei-gegebenen Ausschnitt ihrer Informationsmodelle auszuführen [GaEK2001].

Der PDM-Enablers Standard umfasst insgesamt zwölf Hauptmodule, die jeweils als Enabler bezeichnet werden können. Die Hauptmodule sind unterteilet in Basis-Referenzmodule – PdmResponsibility, PdmFoundation und PdmFramework – und Domänenmodule, welche auf die Basis-Referenzmodule referenzieren können. Die Funktionalitäten der einzelnen Module werden in der folgenden Tabelle kurz beschrieben [Pham2007], [Kras2002]:

Modul Beschreibung PdmResponsibility Beschreibt die Organisationen und die Zuständigkeiten.

PdmFoundation Beschreibt die Basiskonstrukte und Grundeigenschaften der PDM-Objekte.

PdmDocumentManagement Regelt den Zugriff auf die PDM-Dokumente.

PdmProductStructure Bildet die PDM-Baugruppenstruktur ohne Varianten-management ab.

PdmConfigurationManagement Ermöglicht den Zugriff auf Produktkonfigurations- und

Page 80: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

62 Stand der Forschung und der Technik

Produktvariantendaten. Dieses Modul ist aus STEP AP 214 abgeleitet.

PdmChangeManagement Ermöglicht den Zugriff auf Änderungsmanagementda-ten.

PdmManufacturingImplementation Beschreibt den Fertigungsprozess auf hohem Abstrakti-onsgrad für den Konstruktionsprozess.

PdmEffectivity Regelt die Gültigkeit eines PDM-Objekts in Zusam-menhang mit dem Konfigurationsmanagement.

PdmViews Ist zuständig für die Verwaltung von PDM-Sichtkonzepten.

PdmSTEP Ist eine Schnittstelle zur Einbindung von STEP-Prozessoren.

PdmBaseline Ist zuständig für die Handhabung von Baselines, Samm-lung von Objekten und Einfrierung des Zustands.

Tabelle 4-7 Hauptmodule des PDM-Enablers Standards

Vom Gebrauch der PDM-Enablers profitieren vor allem Systemanbieter, Integratoren oder auch Endkunden, die nicht nur die bereits getätigten Investitionen in Applikationen mit PDM-Funktionalitäten sichern, sondern auch für die Zukunft erheblich niedrigere Integrationskosten bei Anbindung weiterer Systeme erzielen [KaLa2001]. Allerdings beschränkt sich die PDM-Enablers-Spezifikation nur auf die mechanischen Aspekte eines Produkts – wie z. B. mechani-sche Produktstruktur und -konfiguration – ohne jegliche Betrachtung weiterer Gesichtspunkte aus anderen Domänen wie der Elektrotechnik und Informationstechnik. Dieses bedeutet, dass PDM-Enablers die interdisziplinären Entwicklungsabläufe bei der Entwicklung mechatroni-scher Produkte nicht sinnvoll unterstützen kann.

4.3.2 OMG PLM Services

PLM Services ist ein Standard der OMG und basiert auf den Applikationsprotokoll AP 214 des STEP-Standards. Der PLM Services-Standard wurde aufgrund von Anforderungen der Auto-mobilindustrie für den synchronen und asynchronen Datenaustausch in verteilten Kooperati-onsprojekten entwickelt [BSMA2006]. Die Zielsetzung bestand darin, eine XML-Spezifikation der Conformance Classes CC6 und CC8 des Anwendungsprotokolls AP 214 zu erstellen, um einen web-basierten Datenaustausch zwischen verschiedenen PDM-Systemen zu ermöglichen. Der PLM Services-Standard beschreibt darüber hinaus Dienste zur dezentralen Verwaltung von Daten aus unterschiedlichen PDM-Systemen mithilfe von Web Services. Fol-gende Services sind damit realisiert [BSMA2006], [LäBu2007]:

Start von PLM-Sitzungen (Authentifizierung und Authorisierung),

Page 81: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 63

Navigation durch PDM-Produktstrukturen,

asynchrone Dokumentenverwaltung unter Einbeziehung von Lageinformation und

Klassifikation.

In der Praxis steckt der PLM Services-Standard noch in den Kinderschuhen. Es existiert der-zeit nur eine prototypische Umsetzung als Demonstrator, die durch das PDM Implementor Forum implementiert wurde.

Die neue Ausgestaltung des STEP-Standards mithilfe der XML-Technologien wird die Im-plementierung vereinfachen, die Kompatibilität und die Konformität fördern und somit die Akzeptanz bei den Anwendern erhöhen. Jedoch umfasst der aktuelle Stand des PLM Services-Standards nur die Conformance Classes CC6 und CC8, welche das Produkt lediglich aus me-chanischer Sicht beschreiben. Die Anwendung dieses Standards für die Prozess-, Daten- und IT-Werkzeugintegration innerhalb der Entwicklung mechatronischer Systeme erfordert eine Betrachtung von weiteren mechatronischen Domänen, beispielsweise die Entwicklung von elektrotechnischen und informationstechnischen Produktkomponenten.

4.4 Domänenspezifische PLM-Anwendungen

Für die Steuerung und Automatisierung der während der Produktentwicklung durchzuführen-den Prozesse und Tätigkeiten und für die Organisation der dabei anfallenden Daten wurden in den letzten Jahren zahlreiche PLM-Lösungen entwickelt. Der Umfang der Funktionalität die-ser Systeme reicht von einfachen Dokumentmanagementfunktionen bis hin zu hoch komple-xen Schnittstellen für die Integration von CAx- und ERP-Systemen. Der PLM-Ansatz lässt sich heute im Allgemeinen wie folgt definieren:

PLM umfasst integrierte Konzepte, Methoden, Werkzeuge und Modelle zum Manage-ment von produktdefinierenden Informationen und Engineering-Prozessen sowie zur In-tegration operativer Engineering-Methoden und -Anwendungen im kooperativen, global verteilten Produktlebenszyklus. [Abra2005](Abbildung 4-8)

Die Basis PLM-Methoden sind in der folgenden Tabelle 4-8 dargestellt [Abra2006]:

Methoden Beschreibung

Methoden zum Datenmanagement

Sie sind Methoden zur Identifikation, Strukturierung, Klassifizierung, Modellierung, Suche, Verteilung, Visualisierung und Archivierung von produkt-, pro-zess- und projektbezogenen Metadaten und Modellen.

Methoden zum Prozessmanagement

Sie sind Methoden zur Modellierung, Strukturierung, Planung und Steuerung von formellen oder semi-formellen Prozessen, z. B. Freigabe-, Änderungs- oder Benachrichtigungsprozesse. Die enge Verbindung

Page 82: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

64 Stand der Forschung und der Technik

zwischen den verschiedenen Prozessphasen und den resultierenden Produktmodellen wird durch sogenann-te Konfigurationsmanagementmethoden abgedeckt.

Methoden zum Management der Anwendungsintegration

Sie sind Methoden zur Verwaltung von Engineering-Applikationen bzw. zur Definition und zum Manage-ment von Schnittstellen zu operativen Engineering-Erzeuger-Systemen wie MCAD-, ECAD-, CAM-, CAE-, CASE-Software sowie zu unternehmensüber-greifenden Softwaresystemen, wie ERP- oder CRM-Systemen.

Prozessübergreifende Methoden

Sie sind Methoden zum Zugriffsmanagement, zur Unterstützung der Engineering Collaboration bzw. zur Datenverdichtung und -analyse in Form von Manage-ment-Reports.

Tabelle 4-8: Beschreibung der PLM-Methoden

Abbildung 4-8: PLM-Grundkonzept [ASEV2007]

Allerdings ist festzustellen, dass die heute existierenden PLM-Systeme sehr domänenspezi-fisch konzipiert sind und wenig bzw. kaum interdisziplinäre Funktionen und Methoden anbie-ten. Dies ist hauptsächlich darauf zurückzuführen, dass die Entwicklung dieser Systeme inner-halb der einzelnen Fachdomänen (Mechanik, Elektrotechnik und Informationstechnik) auf Basis historisch vorhandener domänenspezifischer alter Konzepte und Systemarchitekturen –

Page 83: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 65

wie in den folgenden Abschnitten zu sehen ist – entworfen wurden. Die Abbildung 4-9 zeigt an Hand des V-Modells VDI 2206 den Einsatz der domänenspezifischen PLM-Anwendungen innerhalb der Entwicklung mechatronischer Produkte. Während für das Management von Pro-duktdaten und Prozesse in den Bereichen Mechanik, Elektrotechnik und Informationstechnik geeignete PLM-Systeme wie PDM-, EES- und SCM-Systeme zu finden sind, fehlen für die Unterstützung von interdisziplinären und domänenübergreifenden Entwicklungsprozessen wie beispielsweise bei dem domänenübergreifenden Systementwurf und bei der domänenübergrei-fenden Systemintegration vergleichbare Managementansätze.

Informationstechnik

Elektrotechnik

Mechanik

Domänenspezifischer Systementwurf

SCM

EES

PDM

Eigenschaftsabsicherung

Anforderungen Produkt

Fehlende PLM-Unterstützung

Legende:

PDM: Produktdatenmanagement SystemEES: Electrical Engineering Solution SystemSCM: Software Configuration Management System

Abbildung 4-9: Heutiger Einsatz der domänenspezifischen PLM-Anwendungen innerhalb der Entwicklung mechatronischer Produkte an Hand des V-Modells VDI 2206

Die Eigenschaften der gängigen domänenspezifischen PLM-Systeme für das Daten- und Pro-zessmanagement innerhalb des Mechanik-, Elektrotechnik- sowie Informationstechnikberei-ches werden in den folgenden Abschnitten beschrieben und ihre jeweilige Eignung als inter-disziplinäre mechatronische Integrationsplattform diskutiert.

Page 84: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

66 Stand der Forschung und der Technik

4.4.1 PLM-Anwendungen innerhalb der Entwicklung mechanischer Produkt-komponenten

Die ersten Ansätze zum Management von Daten innerhalb der Entwicklung mechanischer Produktkomponenten entstanden Anfang der achtziger Jahre in Form von Dokumentationssys-temen für die Verwaltung und Ablage von digitalen technischen Zeichnungen. Die erfolgrei-che Einführung sowie die rasante Verbreitung von 3D-MCAD-Systemen haben zur Entste-hung einer neuen Generation von Verwaltungssystemen, den sogenannten Technical Data Ma-nagement-Systemen (TDM), für das Management von 2D- und 3D-MCAD-Daten geführt. Die Anfang der neunziger Jahre entwickelten Product Data Management-Systeme stellten die Produktstruktur als Hauptträger aller Produktinformationen in den Mittelpunkt und berück-sichtigten auch die zugeordneten Freigabe- und Änderungsprozesse innerhalb der Produktent-wicklungsphase [AbSc2004]. Ab Mitte der neunziger Jahre gewann der Einsatz weiterer CAx-Werkzeuge (z. B. CAE, CAM) entlang des Produktentstehungsprozesses mehr an Bedeu-tung, was die Geburt der nächsten Generation von PDM-Systemen, den Enterprise Product Data Management-Systemen, ausgelöst hat. Die Enterprise PDM-Systeme sollen die Integra-tion der verschiedenen CAx-Tools wie z. B. MCAD, CAE, CAM auf Basis eines integrierten Produktdatenmodells ermöglichen und somit die Voraussetzung für eine durchgängige virtuel-le Produktentwicklung schaffen. Ende der neunziger Jahre und Anfang des neuen Jahrtausends ist eine neue Organisationsform der Produktentwicklung entstanden, die heute vorwiegend als verteilte oder kollaborative Produktentwicklung bekannt ist. So entwickeln sich die Enterprise PDM-Systeme zu Collaborative PDM-Systemen, die eine Anbindung mehrerer Entwicklungs-partner, die organisatorisch sowie geographisch voneinander getrennt sind, ermöglichen sollen [AbSc2005]. Innerhalb der Entwicklung mechanischer Produkte und Produktkomponenten werden die TDM-, PDM-, Enterprise PDM und Collaborative PDM-Systeme immer als PDM-Systeme bezeichnet, daher werden diese Systeme innerhalb dieser Arbeit ebenfalls PDM-Systeme genannt.

Die PDM-Systeme, die derzeit auf dem Markt existieren, sind insgesamt sehr ausgereift und können einen erheblichen Beitrag zur Realisierung einer durchgängigen und integrierten Ge-samtproduktentwicklung leisten. Dennoch ist festzustellen, dass diese Lösungen das Ma-nagement und die Integration von Produktdaten und Prozessen innerhalb des Mechanik-Entwicklungsumfelds als Hauptfokus haben. So werden die am Markt verfügbaren Systeme beispielsweise den Anforderungen hinsichtlich Datenverwaltung im Bereich Elek-trik/Elektronik noch nicht gerecht [WeSW2000]. Dies ist im Wesentlichen darauf zurückzu-führen, dass die derzeitigen Lösungen nichts anderes als die Weiterentwicklung der TDM-Lösungen darstellen, welche sich ausschließlich auf die Verwaltung der MCAD-Daten spezia-lisiert hatten. Dies bedeutet, dass die gängigen PDM-Systeme mechanisch-orientiert sind und kein interdisziplinäres und durchgängiges Management von Daten und Prozessen entlang der gesamten Produktentstehung über alle Domänen ermöglichen können. Somit beschränkt sich ihr Einsatz vornehmlich auf den mechanischen Bereich. Um dieses Defizit zu umgehen, haben

Page 85: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 67

viele Hersteller mechatronischer Produkte (wie z. B. Automobilhersteller) versucht, die wäh-rend der Produktentwicklung anfallenden elektrotechnischen und informationstechnischen Produktdaten (z. B. Entwicklungsdaten für Hardwarekomponenten und eingebettete Software-komponenten) innerhalb der mechanischen Produktstruktur unterzubringen, um eine durch-gängige Datenorganisation zu ermöglichen. Dieser Versuch ist allerdings gescheitert, da viele essenzielle logische und funktionelle elektrotechnische und informationstechnische Produktin-formationen bzw. Zusammenhänge nicht auf Gesamtproduktebene abgebildet werden konnten, sondern nur teilweise lokal innerhalb der einzelnen Fachbereiche. Ein weiteres Problem be-steht darin, dass die gängigen Managementsysteme an der herkömmlichen komponentenorien-tierten Arbeitsweise ausgerichtet sind und vor allem die Sicht auf die Komponenten des be-trachteten Produktes unterstützen [WaHe2007]. Dieses kann die Verwendung von funktions-orientierter Methodik bei der Entwicklung mechatronischer Systeme nicht sinnvoll unterstüt-zen.

4.4.2 PLM-Anwendungen innerhalb der Entwicklung elektrotechnischer Pro-duktkomponenten

Die Ansätze zum Daten- und Prozessmanagement innerhalb der E/E-Konstruktion haben sich bislang, im Gegensatz zu dem mechanischen Bereich, nur sehr schwach etabliert und bis jetzt keinen nennenswerten Durchbruch erzielt. PDM- bzw. PLM-Systemhersteller haben die As-pekte der E/E-Konstruktion bislang nur marginal betrachtet, z. B. haben manche Hersteller zusätzliche Funktionalitäten als Add-On-Module in den vorhandenen PDM-Systemen imple-mentiert, um E/E-Dokumente zu verwalten. Dieser Ansatz hat sich in der Praxis kaum be-währt, da die logischen und funktionalen Produktinformationen, welche die E/E-Komponenten charakterisieren bzw. dominieren – im Gegensatz zu mechanischen Komponenten, die geome-trieorientiert sind –, innerhalb der klassischen PDM-Systeme nicht abbildbar und beschreibbar sind. Einer der Hauptgründe dieser langsamen Entwicklung des Produktdatenmanagements innerhalb der E/E-Konstruktion ist die Erwägung, diesen Bereich – in der Vergangenheit und teilweise bis heute – nur als Dienstleister und nicht als eine der Hauptdomänen innerhalb der Entwicklung mechatronischer Produkte zu sehen.

In Anbetracht dieser Situation haben sich ECAD-Systemhersteller ständig bemüht, entspre-chende integrierte Lösungen für das E/E-Datenmanagement innerhalb der ECAD-Systeme als Add-On-Module zu entwickeln. Das Ergebnis dieser langjährigen Bemühungen ist die Entste-hung der neuen ECAD-Systemgeneration, die heute als EES-Systeme (Electrical Engineering Solution) bekannt ist. EES gilt als ein neues Konzept, das den gesamten E/E-Konstruktions- und -Herstellungsprozess durchgängig unterstützt und damit effizienter gestaltet [HoSR2001]. Diese neue Systemgeneration soll die Durchführung eines durchgängigen, mo-dellorientierten E/E-Engineerings auf Basis eines einheitlichen, objektorientierten E/E-Datenmodells ermöglichen [ScRo2003]. Konkret bedeutet dies, dass der Kern eines EES-Systems ein integriertes Datenmodell darstellt, welches als Basis für die Erstellung, Bearbei-

Page 86: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

68 Stand der Forschung und der Technik

tung, Ableitung sowie die Verwaltung der verschiedenen E/E-Dokumente wie z. B. Schaltplä-ne, Platinenlayouts, Stromlaufpläne, Ablauf- und Schaltfolgediagramme, Verdrahtungspläne und -listen, Anschluss-, Verbindungs- und Kabelpläne, Stück- und Bauteillisten dient. Weiter-hin sollen die EES-Systeme u. a. die folgenden Aktivitäten unterstützen [Scro2003], [Gisc2007]:

Nummerierung von E/E-Komponenten,

Zentrale Verwaltung und Archivierung der erstellten E/E-Dokumente auf Datenbankba-sis,

Versionierungsmanagement der erstellten E/E-Dokumente,

Variantenkonstruktion und -management,

Konfigurationsmanagement,

Wiederverwendung von E/E-Komponenten,

Verwaltung von E/E-Normteilbibliotheken und E/E-Standardkomponenten,

Verwaltung von E/E-Betriebsmitteln,

Freigabemanagement,

Datenaustausch auf Basis verschiedener Standarddatenmodelle wie z. B. STEP-Datenmodell AP 212, DXF,

Integration verschiedener ECAD-Systeme,

Integration verschiedener ECAE-Systeme wie HiL- und SiL-Systeme,

Verwaltung von funktionalen sowie logischen Zusammenhängen zwischen den E/E-Komponenten,

Prüfung und Auswertung von funktionalen und logischen E/E-Funktionalitäten.

Die EES-Systeme stellen heute eine Integrationsplattform innerhalb der Entwicklung der E/E-Systeme dar, welche zur Optimierung der Steuerung der E/E-Teilprozesse sowie des E/E-Datenmanagements einen großen Beitrag leisten können. Es bleibt jedoch festzuhalten, dass diese Systeme heutzutage in der Praxis nur als Insellösungen innerhalb der mechatronischen Produktentwicklung verwendet werden. Die Anbindung mit Managementsystemen aus ande-ren Bereichen wie PDM oder SCM (vgl. Abschnitt 4.3.3) beschränkt sich i. d. R. – wenn sie überhaupt existiert – vorwiegend auf den Austausch von einzelnen Produktstammdaten wie z. B. Teilesachnummern oder Teilebezeichnungen. Eine breite Anbindung scheitert sowohl an den größeren Unterschieden zwischen den domänenspezifischen Produktdatenmodellen als auch an den Besonderheiten der domänenspezifischen Entwicklungsprozesse und -abläufe.

Page 87: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 69

4.4.3 PLM-Anwendungen innerhalb der Entwicklung eingebetteter Software-systeme

Das Thema Daten- und Prozessmanagement innerhalb der Entwicklung eingebetteter Soft-waresysteme fand seinen Ursprung Anfang der fünfziger Jahre innerhalb der US-Luft- und Raumfahrtindustrie. Die erste IT-Lösung für die Organisation, Steuerung und Verfolgung von Änderungen innerhalb der Softwareentwicklung wurde für das Apollo Raumfahrtprogramm entwickelt. Jedoch kamen die ersten kommerziellen Lösungen erst Anfang der siebziger Jahre unter dem Namen Software Configuration Management Systeme (SCM) (wie z. B. Make, SCCS „Source Code Control System“) auf den Markt [CrAD2003]. Die Steigerung der Komplexität und die daraus resultierende starke Modularisierung der eingebetteten Software-systeme in den achtziger Jahren haben den Einsatz von SCM-Lösungen innerhalb der Soft-wareentwicklung unerlässlich gemacht und somit deren Durchbruch ausgelöst. Dabei stellten das Konfigurations- und das Versionierungsmanagement der Quellcode-Dateien die Kernfunk-tionalitäten der ersten kommerziellen SCM-Tools dar [CrAD2003]. Innerhalb der neunziger Jahre ist der Softwareanteil bei den meisten Produkten rasant gestiegen. Infolgedessen hat auch das Thema Prozessmanagement innerhalb der Softwareentwicklung mehr an Bedeutung gewonnen. Für die methodische Unterstützung derartiger Entwicklungsprozesse wurden eine Reihe von nationalen und internationalen Vorgehensmodellen (wie z. B. CMM, CMMI, SPI-CE, V-Modell, ISO/IEC12207) entwickelt, die prozessorientierte Methoden wie z. B. Freiga-be- und Änderungsmanagement als Standardabläufe innerhalb der Softwareentwicklung defi-niert haben. Dies hat dazu geführt, dass sich die SCM-Systeme vom Verwaltungssystem der Quellcode-Dateien zum komplexen Prozessmanagementsystem entwickelt haben. Heute lässt sich SCM wie folgt definieren:

Software Configuration Management unterstützt die Identifikation, Initiierung und effi-ziente Verwaltung und Steuerung von Softwarekonfigurationen durch geeignete Metho-den, Werkzeuge und Hilfsmittel, um durch kontrollierte Änderungen die Entwicklung und Pflege eines Softwareprodukts zu erleichtern und transparent zu machen. [Fähn2003]

Dabei lässt sich eine Softwarekonfiguration wie folgt definieren:

Softwarekonfiguration ist eine benannte und formal freigegebene Menge von Software-elementen mit den jeweils gültigen Versionsangaben, die zu einem bestimmten Zeitpunkt im Produktlebenszyklus in ihrer Wirkungsweise und den Schnittstellen aufeinander ab-gestimmt sind und gemeinsam eine vorgesehene Aufgabe erfüllen sollen. [Fähn2003]

Heutige SCM-Lösungen umfassen u. a. die folgenden Methoden und Funktionalitäten [CrAD2003], [HeSi2003], [LiSL2001], [EsGK2002], [Fähn2003], [Berc2002]:

1. Verwaltungsfunktionen

Identifikation von Softwaresystemen und Softwarekomponenten,

Page 88: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

70 Stand der Forschung und der Technik

Verwaltung von Softwarearchitektur und den dazu gehörenden Softwarekomponen-ten,

Verwaltung von Software- und Softwarekomponentenversionen,

Abbildung und Verwaltung von funktionalen und logischen Zusammenhängen und Schnittstellen zwischen Softwarekomponenten eines Softwaresystems,

Verwaltung von parallelen Entwicklungsständen (sog. Branches),

Verwaltung von Softwarevarianten,

Verwaltung von Programmierbibliotheken.

2. Konfigurationsmanagementfunktionen

Erstellung und Verwaltung von Softwarekonfigurationen,

Abbildung und Verwaltung von funktionalen und logischen Zusammenhängen und Schnittstellen zwischen Softwarekomponenten und -systemen einer Softwarekonfi-guration,

Erstellung und Verwaltung von Referenzkonfigurationen (sog. Baselines).

3. Test- und Validierungsmanagementfunktionen

Integrationsmanagement der verschiedenen Softwaresysteme und Komponenten,

Build Management für die Generierung von Quellecodes für die Compiling- und Linking-Aktivitäten,

Erfassung und Verwaltung von Testergebnissen,

Erfassung und Verwaltung von Fehlermeldungen,

Auswertungs- und Prüffunktionalitäten.

4. Prozessmanagementfunktionen

Freigabemanagement (sog. Release Management).

Änderungsmanagement.

5. Integration von verschiedenen CASE-Tools

Bidirektionaler Austausch der Software-Metadaten

Bidirektionaler Austausch der Softwarearchitektur

Die Einführung von SCM-Lösungen innerhalb der Softwareentwicklung hat sich im Sinne der Optimierung und Verbesserung der Entwicklungsprozesse sowie der Verkürzung der Entwick-lungszeit als erfolgreich herausgestellt [Tich1999]. Ebenso hat sich SCM als essenzielle Dis-ziplin innerhalb des Softwareentwicklungsbereichs etabliert. Dennoch ist festzustellen, dass die SCM-Systeme nur als Insellösung innerhalb der mechatronischen Produktentwicklung

Page 89: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 71

eingesetzt werden. Einer der Hauptgründe dafür sind die fehlenden Integrationsansätze zwi-schen den verschiedenen domänenspezifischen Prozess- und Datenmanagementsystemen (PDM, EES und SCM). Um einen integrierten Datenbestand für das mechatronische Gesamt-produkt zu schaffen, haben viele Unternehmen versucht Softwaresysteme und -komponenten zusätzlich innerhalb der mechanischen Produktstruktur bzw. -stückliste einzuordnen. Dies konnte allerdings die Problematik der Daten- und Prozessintegration innerhalb mechatroni-scher Produktentwicklung aufgrund der folgenden Schwachstellen nicht wirklich lösen:

Mechanische Produktstruktur bzw. -stücklisten sind in der Regel geometrie- und mon-tageorientiert, während die Softwarestruktur bzw. -architektur logik- und funktional-orientiert ist. Daher kann ein Großteil der Softwareinformationen und Zusammenhänge zwischen den Softwarekomponenten nicht abgebildet und verwaltet werden.

Der Entwicklungsprozess für mechanische Komponenten unterscheidet sich sehr stark von dem Softwareentwicklungsprozess, beispielsweise bei der Durchführung von Än-derungen können Softwarekomponente im Vergleich zu den mechanischen Komponen-ten schnell und einfach geändert und produktiv eingesetzt werden. Deshalb kann eine hybride Produktstruktur, die aus Software- und mechanischen Komponenten besteht, zu Komplikationen, Schwierigkeiten sowie Unstimmigkeiten bei der Durchführung von Freigabemanagement- und Änderungsmanagementprozessen innerhalb der einzelnen Bereiche führen.

4.5 Relevante Forschungsaktivitäten

4.5.1 iViP

Die übergreifende Zielsetzung des Leitprojekts iViP44 (integrierte Virtuelle Produktentste-hung) bestand in der Einrichtung verbesserter technischer Rahmenbedingungen für die Ent-wicklung neuartiger, marktfähiger Produkte [KBBJ2003]. Der Ansatz zur Erreichung dieses Ziels beruht auf der Entwicklung einer IT-Plattform, der sogenannten iViP-Plattform. Diese Plattform soll die für die Produktentstehung verwendeten digitalen Werkzeuge über neutrale, möglichst standardisierte Schnittstellen integrieren. Dadurch sollen eine durchgehende integ-rierte virtuelle Produktentstehung ermöglicht und zukünftige innovative Integrationskonzepte realisiert werden. Die entwickelte Plattform basiert auf einer offenen Systemarchitektur (Ab-bildung 4-10), welche den Produktentwicklern die Möglichkeit gibt, aufgabenspezifisch die notwendigen Softwarebausteine zu konfigurieren und diese über eine einheitliche Benut-zungsoberfläche aufzurufen und gezielt einzusetzen [KBBJ2003].

Die iViP-Systemarchitektur besteht aus folgenden Bausteinen [Mühl2002]:

44 iViP: das Projekt “integrierte Virtuelle Produktentstehung” wurde durch das Bundesministerium für Bildung und Forschung (BMBF) gefördert und von 1998 bis 2002 durchgeführt.

Page 90: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

72 Stand der Forschung und der Technik

iViP-Client: iViP-Client soll den transparenten Zugriff auf Produktdaten aus unter-schiedlichen Systemen gewährleisten und die Anbindungen von spezifischen Enginee-ring-Werkzeugen erlauben. Dieser Client spielt innerhalb der iViP-Plattform die Rolle einer einheitlichen, plattformübergreifenden Benutzeroberfläche für die iViP-konformen Werkzeuge.

iViP-Werkzeuge: iViP-Werkzeuge sind Softwareanwendungen, die bestimmte Aufga-ben übernehmen, indem sie eigenständig Anwendungslogik kapseln und der iViP-Plattform zur Verfügung stellen.

Externe Werkzeuge: Externe Werkzeuge stellen bereits existierende Software dar (z. B. CAD, PDM, DMU), die an die iViP-Plattform mittels geeigneter Schnittstellen ange-bunden werden sollen.

Plug-ins: Plug-ins ermöglichen dem Anwender innerhalb des iViP-Clients den Zugriff auf die unterschiedlichen, für den jeweiligen Anwender verfügbaren Werkzeuge.

Systemdienste: Die Systemdienste koordinieren den Informationsaustausch zwischen den einzelnen Komponenten der iViP-Plattform bezüglich des Systemzustands.

Datenbus: Der Datenbus ist eine CORBA-Datenschnittstelle, die auf Basis des Stan-darddatenmodells PDM-Enablers entwickelt wurde. Dieser Datenbus soll den Datenaus-tausch zwischen den einzelnen Komponenten der iViP-Plattform ermöglichen.

Abbildung 4-10: iViP-Systemarchitektur [Mühl2002]

Page 91: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 73

Die entwickelte iViP-Plattform stellt ein klassisches Engineering-Portal dar, welches einen zentralen Zugriff auf verschiedene Engineering-Werkzeuge und eine einheitliche Benutzer-oberfläche liefert. Dies erleichtert zwar die Arbeit der Ingenieure innerhalb einer heterogenen Systemlandschaft, löst allerdings die Problematik der interdisziplinären Daten- und Prozessin-tegration im Wesentlichen nicht. Ferner hat sich dieses Projekt vor allem mit den mechani-schen Aspekten der Produktentwicklung beschäftigt (z. B. Integration von CAD-, DMU- und MKS-Systemen). Die Betrachtung von weiteren Bereichen wie Elektrotechnik und Informati-onstechnik blieb dabei außer Acht.

4.5.2 PDM-Collaborator (PDM-C)

Ziel des Verbundprojekts PDM-C45 (PDM-Collaborator) war es, Lösungen zu entwickeln, mit denen Produktdaten verschiedener Partner und aus unterschiedlichen PDM-Systemen unter-nehmensübergreifend zugänglich und automatisiert weiterverarbeitbar gemacht werden kön-nen, ohne bestehende PDM-Installationen ablösen oder modifizieren zu müssen [AbSV2003]. Zur Erreichung dieses Ziels wurde eine IT-Systemarchitektur entwickelt, die verschiedene Partner eines Entwicklungsverbundes unabhängig vom jeweils bereits intern verwendeten PDM-System zu einer Teilnahme in diesem Entwicklungsverbund befähigen soll [ASVH2004]. Zusätzlich verfügt die Architektur von PDM-C über PDM-Services für Ent-wicklungspartner, die überhaupt kein PDM-System haben. Die PDM-C-Architektur basiert auf einem Schichtenmodell (Abbildung 4-11). Das PDM-Collaborator-Schichtenmodell präsen-tiert sich gegenüber den Clients über Adaptoren als PDM-System, besitzt allerdings keine ei-gene Datenhaltung, sondern leitet Anfragen über Konnektoren an die untergeordneten PDM-Systeme weiter [ASVH2004]. Im Folgenden sind die einzelnen Komponenten der PDMC-Architektur beschrieben [ASVH2004]:

Basic Services: Die Basic Services übernehmen die notwendigen Infrastrukturmaßnah-men wie die Benutzerverwaltung, das Session-Management oder die Abbildung der Nutzerzugangsdaten auf die der angeschlossenen Systeme (User Mapping).

Collaboration Services: Collaboration Services beinhalten ein übergeordnetes Work-flow-Management zur Integration von Änderungs- und Freigabemanagementprozessen zwischen Unternehmen sowie ein zentrales Projektmanagement für die Entwicklungs-kollaboration.

Application-specific Services: Application-specific Services umfassen Dienste für die Behandlung von Projekt- und Produktdaten (Collaboration Services, Federation Servi-ces) und weitere grundlegende Infrastrukturdienste (Basic Services) für die Datenkon-vertierung.

45 PDM-C: das Projekt “PDM-Collaborator” wurde durch das Bundesministerium für Bildung und Forschung (BMBF) gefördert und von 2002 bis 2003 durchgeführt.

Page 92: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

74 Stand der Forschung und der Technik

Federation Services: Federation Services – auch Federation-Engine genannt – organi-sieren die Verteilung der Benutzeranfrage an die betroffenen PDM-Systeme und das Zusammenfügen der Einzelergebnisse zu einem Gesamtergebnis. Die Federation-Engine-Komponente verwendet das Standarddatenmodell STEP AP 214 als Datenbasis, um den Datenaustausch mit den verschiedenen PDM-Systemen zu ermöglichen.

Connectoren: Die Connectoren ermöglichen die Verbindung der jeweiligen PDM-Systeme mit der Federation-Engine-Komponente. Sie beinhalten Funktionen zum Über-setzen der jeweiligen PDMS-internen Datenstruktur in die Struktur des STEP AP 214-Datenmodells. Diese Connectoren müssen von den PDM-Systemanbietern für die je-weiligen PDMS bereitgestellt werden.

Client: Der Client soll die Ergebnisse von Anfragen an die Federation-Engine visuali-sieren. Seine Funktionalität kann einfach in die nativen PDM-Clients der verschiedenen PDMS-Anbieter mit aufgenommen werden.

Abbildung 4-11: Schichtenmodell der PDMC-Architektur [PDMC2003]

Die entwickelte PDMC-Lösung ermöglicht im Wesentlichen das Zusammenführen und Visua-lisieren von Daten zu einem bestimmten Produkt aus verschiedenen PDM-Systemen auf Basis eines föderierten Standarddatenmodells (hier STEP AP 214). Dieser Ansatz kann bei der Ver-einheitlichung der Sichtweise auf das Produkt und der Verbesserung der Kommunikation zwi-schen verschiedenen Partnern innerhalb eines Entwicklungsverbunds unterstützen. Dennoch ist zu bemerken, dass die Federation-Engine – die de facto ein STEP-Preprozessor ist – nur mechanische und geometrische Produktstrukturen transformieren und visualisieren kann. Eine vollständige Darstellung des Produkts setzt eine Erweiterung der Federation-Engine um weite-re mechatronische Domänen wie die Elektrotechnik und Informationstechnik voraus.

Page 93: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 75

4.5.3 Mechasoft

Das Projekt FORSOFT46 hat sich die Optimierung der Entwicklungsprozesse für Software, Embedded Systems und mechatronische Systeme zum Ziel gesetzt. Im Teilprojekt Mechasoft wurde eine mechatronische Entwicklungsumgebung Mechasoft Modeller (MeSoMod) entwi-ckelt, um eine domänenübergreifende Modellierung mechatronischer Systeme zu ermöglichen [ReAL2001]. Den Kern des entwickelten Konzeptes bildet ein funktionsorientiertes Produkt-modell (Abbildung 4-12), das auf einem selbst definierten multidisziplinären Produktdaten-modell basiert, um eine abstrakte und objektorientierte Beschreibung mechatronischer Kom-ponenten zu ermöglichen [Klei2003]. Darüber hinaus soll das definierte Modell die einzelnen domänenspezifische Partialmodelle und Sichten miteinander verknüpfen und somit das ge-meinsame Erarbeiten mechatronischer Lösungen erlauben.

Abbildung 4-12: Beschreibung der mechatronischen Komponente im Mechasoft-Metamodell [ReAL2001]

MeSoMod soll die Erstellung einer abstrakten und domänenunabhängigen Funktionsbeschrei-bung eines mechatronischen Systems in Form von Funktionsbaumstrukturen ermöglichen. Die einzelnen Funktionen können den jeweiligen domänenspezifischen Komponenten zugeordnet werden und somit können die Partialmodelle miteinander auf Funktionsebene verknüpft wer-den, wobei die Produktkomponenten und die dazugehörigen Modelle und Daten in separaten CAx- und PDM-Systemen verwaltet werden.

46 FORSOFT: der bayerische Forschungsverbund “FORSOFT” wurde durch die Bayerische Forschungsstiftung gefördert und von 2000 bis 2003 durchgeführt.

Page 94: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

76 Stand der Forschung und der Technik

Ziel des Mechasoft-Ansatzes ist es, eine funktionale Integration der einzelnen domainspezifi-schen Partialdatenmodelle auf Basis eines föderierten Funktionsmodells zu realisieren, um eine wichtige Voraussetzung für eine integrierte und interdisziplinäre mechatronische Pro-duktentwicklung zu schaffen. Allerdings weist das entwickelte Funktionsmodell noch einige Defizite auf:

Die interdisziplinären Aspekte sind sehr grob definiert, daher kann eine gesamte me-chatronische Modellbildung nicht vollständig über alle Domänen durchgeführt werden.

Beziehungen bzw. Abhängigkeiten zwischen Systemen, Funktionen und Komponenten sind aus dem Modell nicht zu lesen.

Dem Funktionsmodell fehlt es an Detaillierung im Hinblick auf das interdisziplinäre Management von Systemen, Funktionen und Komponenten eines mechatronischen Pro-duktes mittels interdisziplinärer Methoden wie z. B. Versionierungs-, Konfigurations-, Freigabe- oder Änderungsmanagement.

4.5.4 EUMECH

Zielsetzung des Verbundprojekts EUMECH47 war die Bereitstellung von Entwicklungsumge-bungen für mechatronische Erzeugnisse [ReAL2001]. Die Entwicklungsumgebungen wurden für die Produktklassen Feinwerktechnik, Hochleistungshydraulik und Servohydraulische Prüf-einrichtungen aufgebaut und erprobt. Das Teilprojekt 3 hat sich dem Entwurf der Integrati-onsmechanismen für IT-Werkzeuge innerhalb der Konzipierungsphase mechatronischer Sys-teme gewidmet. Hierzu wurde eine Integrationsplattform für die Entwicklung mechatronischer Systeme gemäß KOMFORCE48 -Referenzmodell entwickelt, die die aufgabenorientierte Integ-ration von IT-Werkzeugen in den Entwicklungsprozess unterstützen soll. Ferner soll sie Pro-zessmanagement- und Produktdatenmanagement-Funktionalitäten bereitstellen.

Die im Rahmen des Projektes entstandene Integrationsplattform verfügt über folgende Kom-ponenten [ReAL2001]:

Integrationskomponente: Die Integrationskomponente übernimmt die Aufgaben der IT-Werkzeugintegration (z. B. CAD, CAE) in den Prozessbeschreibungen.

Produktdatenmanagement (Small-PDM): Die Systemkomponente Small-PDM stellt die notwendige PDM-Funktionalität zur Verfügung, um die bei der Entwicklung anfallen-den Produktdaten zu verwalten.

IT-Entwicklungswerkzeuge: Die zur eigentlichen Entwicklungsarbeit eingesetzten Werkzeuge wie CAD-, FEM- oder Simulationswerkzeuge gehören zur Gruppe der IT-

47 EUMECH: das Projekt “Methoden und Werkzeuge zur Entwicklung mechatronischer Systeme” wurde durch das Bundesministerium für Bildung und Forschung (BMBF) gefördert und von 1997 bis 2000 durchgeführt. 48 KOMFORCE: KOMFORCE bezeichnet den “Kommunikations- und Forschungskreis für Integrationstechno-logien in Computer Aided Design und Engineering”.

Page 95: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 77

Entwicklungswerkzeuge.

Konvertierungs- und Kopplungsdienste: Um den Datenaustausch zwischen den Ent-wicklungswerkzeugen zu ermöglichen, sind drei Konvertierungs- und Kopplungsdienste entwickelt worden.

Weitere Systemkomponenten: Neben den genannten Systemkomponenten sorgen zwei weitere Komponenten für die Ergänzung der Plattformfunktionalitäten. Hierfür wurden zwei Schnittstellen, eine zur Anbindung externer Lösungselemente, z. B. externer Pro-duktkataloge, und die andere zur Anbindung von Standardwerkzeugen wie beispiels-weise Office-Programmen konzipiert.

Die entwickelte Integrationsplattform dient lediglich dazu, CAD- und Berechnungswerkzeuge an ein PDM-System zu binden, um deren erzeugte Daten zentral zu verwalten. Jedoch benötigt eine integrierte mechatronische Produktentwicklung vielmehr als Punkt-zu-Punkt-Datenschnittstellen zwischen einen PDM-System und verschiedenen CAx-Systemen. Dieser Ansatz, EUMECH, hat sich mit den interdisziplinären Aspekten eines mechatronischen Sys-tems nicht umfassend beschäftigt und liefert somit keine Lösung, um eine solche interdiszipli-näre Entwicklung zu unterstützen und zu ermöglichen.

4.5.5 VIVACE

Das Projekt VIVACE49 [FNHG2006] wird im Rahmen des sechsten europäischen Rahmen-programms durchgeführt und hat als Gesamtzielsetzung die Reduzierung der Entwicklungs-kosten eines Flugzeugs um 5% sowie die Reduzierung der Entwicklungszeit und der Entwick-lungskosten einer Flugzeugturbine um 30% bzw. 50%. An diesem Projekt waren 63 europä-ische Unternehmen und Forschungsinstitute aus dem Luftfahrtbereich beteiligt [VIVA2008]. Das Teilprojekt EDM (Engineering Data Management) beschäftigt sich mit der Entwicklung eines EDM Frameworks, welches einen domänen- und unternehmensübergreifenden Entwick-lungsprozess erlauben und unterstützen soll. Die Architektur dieses Frameworks besteht aus drei Layers (Abbildung 4-13) [FNGH2006]:

Process Management Layer: Dieses Layer soll Tools und Workflow-Managementsysteme bereitstellen, um domänen- und unternehmensübergreifende Ent-wicklungsprozesse und -aktivitäten definieren und implementieren zu können.

Operational und Collaboration Layer: Dieses Layer umfasst alle Engineering-Tools, al-so die Operational Tools (z. B. CAD, CAE, DMU) und die dazugehörigen PDM- und SDM-Systeme (Simulation Data Management) Collaboration Tools. Zur Durchführung von domänen- oder unternehmensübergreifenden Entwicklungstätigkeiten soll innerhalb dieses Layers ein entsprechendes User-Interface PCM UI entwickelt werden. Dieses

49 VIVACE: das Projekt “Value Improvement through a Virtual Aeronautical Collaborative Enterprise” wurde durch die europäische Union gefördert und von 2004 bis 2007 durchgeführt.

Page 96: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

78 Stand der Forschung und der Technik

Interface soll mit den PDM- und SDM-Systemen via Web Services kommunizieren.

Product Context Management Layer: Dieses Layer stellt die Basisinfrastruktur des EDM Frameworks dar. Es liefert Web Services als Konnektoren zwischen den Opera-tional- und den Collaboration-Tools sowie Datenmodelle Information Model, Domain Model und Consolidated Repository für die domänen- und unternehmensübergreifende Beschreibung und Modellierung von Produktkomponenten. Diese Modelle sind auf Ba-sis der Application Protokolle 239 (Product Life Cycle Support) und 209 (Composite and metal structural analysis and related design) und des Parts 104 (Finite Element Ana-lysis) des STEP-Standards definiert.

Context Management Tools

Process ManagementvalidationanalysedesignWork

ordervalidationrequest

Engineering ToolsCAD DMU CAE

Data Management Tools

Product Context Management

Information model

Consolidated repository

Web services

Domain model

InformationNavigator

PCM User Interface

PDM SDM

Abbildung 4-13: Architektur des VIVACE-EDM Frameworks [VIVA2008]

Aus der Beschreibung der Architektur des EDM Frameworks lässt sich erkennen, dass haupt-sächlich das Thema „Berechnung und Simulation“ den Schwerpunkt dieses Projekts darstellt. Engineering-Bereiche wie die Elektrotechnik und die Informationstechnik wurden im Rahmen dieses Konzepts nicht betrachtet und daher kann es den Belangen einer interdisziplinären Pro-duktentwicklung nur zum Teil gerecht werden.

Page 97: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 79

4.5.6 MIKADO

Ziel des vom BMBF geförderten Verbundprojekts MIKADO50 Mechatronik-Kooperationsplattform für anforderungsgesteuerte Prüfung und Diagnose ist es, Methoden und Werkzeuge bereitzustellen, die die heutige Vorgehensweise in der mechatronischen Pro-duktentstehung zu einem fachübergreifenden Systems Engineering ausbauen. Dazu gehört die Bildung von Anforderungsnetzen sowie interdisziplinären und unternehmensübergreifenden Informations- und Kooperationsmodellen als durchgängige und integrierte Basis für die Ent-wicklung mechanischer, elektrischer und regelungstechnischer Komponenten und Software (Abbildung 4-14) [Hayk2007].

Abbildung 4-14: MIKADO-Gesamtarchitektur [HaLR2008]

Einen wichtigen Bestandteil dieses Projekts stellt die Entwicklung einer Kooperationsplatt-form dar. Diese Plattform ermöglicht eine integrative und synchronisierte Systementwicklung im Sinne des Systems Engineering. Sie schafft eine disziplinübergreifende Informationsbasis und stellt so sämtliche Informationsinhalte bereit, die im Rahmen einer mechatronischen Pro-duktentstehung verwaltet und gegebenenfalls miteinander in Beziehung gesetzt werden müs-sen. Außerdem sollen mit ihrer Hilfe alle relevanten Entwicklungswerkzeuge zusammenge-führt werden [HSTZ2008]. Die Abbildung 4-15 zeigt schematisch die Architektur der Koope- 50 MIKADO: das Projekt “Mechatronik-Kooperationsplattform für anforderungsgesteuerte Prüfung und Diagno-se” wird durch das Bundesministerium für Bildung und Forschung (BMBF) gefördert. Projektlaufzeit: 2006 – 2009.

Page 98: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

80 Stand der Forschung und der Technik

rationsplattform sowie die anzubindenden Systeme und Werkzeuge. Diese Architektur bein-haltet die folgenden Komponenten [HSTZ2008]:

Basisdienste: Zu den Basisdiensten gehören unter anderem die Sitzungsverwaltung, das User-Management, die Datenpersistenz und die Objektverwaltung.

Datenmanagement: Das Management der multidisziplinären Produktdaten wird durch die Datenmanagement-Komponente realisiert. Sie verwaltet und ermöglicht die effizien-te Nutzung aller relevanten Daten aus den vernetzten Teilmodellen der unterschiedli-chen Fachdisziplinen. Dazu stellt sie grundlegende Funktionen wie Suchen, Navigieren, Versionsverwaltung, Verlinkung von Teilmodelle, Erstellen von Sichten und Konfigu-rationen sowie Datenaustausch bereit.

Kooperationsmanagement: Die Kooperationsmanagement-Komponente übernimmt die Gestaltung des Zusammenspiels zwischen den zuständigen Rollen und ihren Rechten innerhalb eines Projekts sowie die Zuordnung von Datenschemata, Struktur- und Kon-textansichten zu verschiedenen Benutzer- und Anwendungsprofilen.

Workflow Engine: Die Workflow Engine instanziiert die im Prozessmodell gespeicher-ten Referenzvorgehensbausteine, die individuell modelliert und an die Prozesse ange-passt wurden.

Informationsmodell: Das Informationsmodell beinhaltet alle vernetzten Teilmodelle und disziplinspezifischen Sichten. Jeder Benutzer arbeitet an seinen Teilmodellen. Seine Änderungen werden wieder in das gesamte Informationsmodell übernommen. Die we-sentlichen Bestandteile im Informationsmodell sind die Produkt-, Dokument-, Anforde-rungs- und Funktionsstruktur.

Kooperationsmodell: Das Kooperationsmodell beschreibt die Definition der Benutzer- und Rollenprofile, sodass die Zuordnung der Teilmodelle eindeutig erfolgen kann.

Prozessmodell: Das Prozessmodell beinhaltet die Bausteine, mit denen die Prozesse in der mechatronischen Produktentwicklung beschrieben werden.

Page 99: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 81

Abbildung 4-15: Architektur der Mechatronik-Kooperationsplattform [HSTZ2008]

Der Kern dieses Konzeptes ist das Informationsmodell, welches die Summe aller Datenmodel-le der an der Produktentwicklung eingesetzten Engineering-Tools wie z.B. M-CAD und E-CAD-Systeme beinhaltet. Auf Basis dieses Modells sollen alle mechatronische Produktdaten und Entwicklungsprozesse organisiert werden und alle Engineering-Tools integriert werden. MIKADO verfolgt den Ansatz ein zentrales Managementsystem (Kooperationsplattform) für alle Daten, Prozesse, Tools und Bereiche innerhalb der Entwicklung mechatronischer Produk-te zu entwickeln. Um die Anforderungen aller Fachdisziplinen erfüllen zu können, muss die Kooperationsplattform alle Funktionalitäten der domänenspezifischen PLM-Systeme, d.h. PDM-, EES- und SCM-Systeme (s. Kapitel 4.4) zur Verfügung stellen. Diese sind aus der Be-schreibung der Datenmanagement-Komponente nicht erkennbar. Desweiteren stellt so ein Vorhaben aus technischer sowie organisatorischer Sicht eine hoch komplexe Aufgabe dar, die langfristig zu einer unflexiblen und monolithischen Systemlandschaft führen kann.

Die meisten Unternehmen, die mechatronische Produkte entwickeln und produzieren, setzen bereits domänenspezifische PLM-Systeme wie z.B. PDM-, EES- und SCM-Systeme innerhalb der einzelnen Fachdisziplinen ein. Diese Systeme beinhalten langjähriges Unternehmenswis-sen und –erfahrungen, die für die Unternehmen unverzichtbar sind. Die Integration dieser Sys-teme in der Kooperationsplattform sowie die Synchronisation deren Daten und Prozesse auf domänenübergreifender Ebene wurde durch das MIKADO-Konzept nicht ausreichend be-trachtet.

Page 100: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

82 Stand der Forschung und der Technik

4.5.7 Web-basierte föderierte PDM-Umgebung (Gerhard)

Gerhard [Gerh2000] hat sich im Rahmen seiner Dissertation die Erweiterung der PDM-Technologie zur Unterstützung verteilter kooperativer Produktentwicklungsprozesse als Ziel gesetzt. Hierzu wurde eine Lösung für die Integration verschiedener CAx- und Informations-managementanwendungen in virtuellen Kooperationsformen auf Basis der PDM-Technologie konzipiert. Kern dieser Lösung ist eine web-basierte föderierte PDM-Umgebung als system-übergreifendes Informationsmanagement- und Integrationswerkzeug.

Das in der genannten Arbeit entwickelte Konzept verfolgt keinen zentralisierten, monolithi-schen Integrationsansatz mit einer möglichst vollständigen Integration heterogener IT-Systeme, sondern einen Ansatz zur verteilten Datenhaltung mit einer kontrollierten Redundanz und eine Überwachung der Konsistenz von Datenbeständen innerhalb verteilter Systeme.

Das entwickelte Konzept gliedert sich in drei Hauptbestandteile [Gerh2000]:

Basistechnologie: In diesem Teil wurden verschiedene Basistechnologien aufgegriffen und im Hinblick auf die Realisierung der föderierten PDM-Umgebung evaluiert. An-hand der durchgeführten Analyse wurde die Internettechnologie als Grundlage für die Umsetzung der Lösung ausgewählt.

Anwendungsmethodik: Ein föderiertes Informationsmanagement wurde als Anwen-dungsmethodik aus System- und Anwendersicht für die föderierte PDM-Umgebung de-finiert, um allen Partnern alle Informationen für die Entwicklung eines Produkts trans-parent bereitzustellen. Dieses beinhaltet im Wesentlichen Methoden zu Systemföderati-on und Dezentralisierung, Nutzung der Informationsressource Web, Anwendung aus Sicht der Benutzer, Ablageorganisation und semantisches Mapping.

Assistenzdienste: Der Aufbau der web-basierten föderierten PDM-Umgebung setzt die Erweiterung der PDM-Systeme um zusätzliche Funktionalitäten, Assistenzdienste, vor-aus. Die Assistenzdienste Datennavigation, Informationssuche, Informationsgewinnung, -übernahme und -aktualisierung wurden in dieser Arbeit definiert.

Gerhards Arbeit hat sich vor allem mit den technischen Möglichkeiten zur Realisierung einer föderierten PDM-Umgebung zur Unterstützung verteilter kooperativer Entwicklungsprojekte beschäftigt, indem sie die Fähigkeit der Internettechnologie sowie ihren möglichen Einsatz für die Umsetzung des gedachten Konzepts aufgezeigt und in den Vordergrund gestellt hat. Aller-dings wurden methodische und prozessuale Aspekte des Datenmanagements (wie z. B. Konfi-gurations-, Versionierungs-, Freigabe- und Änderungsmanagement) innerhalb verteilter koo-perativer Entwicklungsprojekte nur am Rande betrachtet. Außerdem standen die Aspekte der interdisziplinären und integrierten Entwicklung mechatronischer Systeme nicht im Fokus jener Dissertation.

Page 101: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 83

4.5.8 Föderatives Informationsmodell zur Systemintegration für die Entwick-lung mechatronischer Produkte (Kleiner)

Kleiner [Klei2003] hat sich im Rahmen seiner Dissertation mit der Entwicklung einer multi-disziplinären Entwurfsmethode und der Optimierung des Rechnereinsatzes bei der Modellbil-dung und -analyse mechatronischer Systeme innerhalb der Entwurfsphase beschäftigt. Dabei wurde das Ziel verfolgt, die domänenspezifischen Modellierungsmethoden, Partialmodelle und CAx-Systeme zu einer Arbeitsumgebung für den Entwurf von mechatronischen Systemen zu verknüpfen. Zur Umsetzung dieses Ziels wurden [Klei2003]:

eine multidisziplinäre Modellierungsmethodik für den Entwurf mechatronischer Syste-me konzipiert,

ein Referenzmodell zur Föderation von Produktdatenmodellen für die mechatronische Produktentwicklung definiert und

ein Assistenzsystem zur Unterstützung des Entwurfs mechatronischer Systeme entwi-ckelt.

Der Integrationsansatz bei dieser Arbeit basiert auf einem föderativen Produktdatenmodell. Hierfür wurden das mechanische und das regelungstechnische Modell zu einem übergreifen-den Informationsmodell abstrahiert. Auf Basis dieses Informationsmodells soll die Verknüp-fung zwischen den verschiedenen CAx-Systemen realisiert werden und damit die Ermögli-chung eines interdisziplinären Entwurfs mechatronischer Systeme. Für die Definition dieses Informationsmodells wurde das MechaSTEP-Modell als Grundlage verwendet und weiter an die Anforderung der Arbeit angepasst.

Die Arbeit liefert einen wertvollen Ansatz in Richtung integrierter mechatronischer Produkt-entwicklung. Allerdings wurden vor allem mechanische und regelungstechnische Simulations- und Modellierungsgesichtspunkte innerhalb der Entwurfsphase behandelt, daher ist eine feh-lende ganzheitliche domänenübergreifende Betrachtung der mechatronischen Prozesse in die-ser Arbeit festzustellen.

4.5.9 Model Management and Integration Platform for Mechatronics Product Development (El-Khoury)

El-Khoury [Elkh2006] hat sich im Rahmen seiner Dissertation der Integration der einzelnen Fachdomänen zu einer multidisziplinären mechatronischen Gesamtdomäne gewidmet. Hierzu wurde eine Plattform für mechatronische Produktentwicklung Model Data Management Sys-tem (MDM) als Basis für die Integration entwickelt, die auf Basis des PDM-Systems Matrix-One implementiert wurde. Die entwickelte MDM-Plattform soll verschiedene domänenspezi-fische IT-Systeme (wie z. B. MCAD-, ECAD-, CASE-, CAE-Systeme) zu einer gesamten me-chatronischen IT-Systemumgebung koppeln und deren erzeugte Daten zentral verwalten. Zu diesem Zweck wurde die in Abbildung 4-16 dargestellte Architektur entworfen, welche die folgenden Komponenten umfasst:

Page 102: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

84 Stand der Forschung und der Technik

Data Repository: Die Data Repository stellt die Datenbank für die Speicherung der Da-ten dar, die von den domänenspezifischen IT-Systemen erzeugt werden. Die Datenbank verfügt über ein generisches und domänenübergreifendes Informationsmodell meta-meta model, um die toolspezifischen Metadaten der einzelnen Datenobjekte abbilden zu können.

Managementfunktionen: Die Managementfunktionen stellen herkömmliche PDM-Funktionalitäten wie z. B. Versionierungs-, Produktstruktur-, Änderungs- und Freiga-bemanagement dar.

Tool Interface: Das Tool Interface präsentiert die Schnittstelle zwischen dem MDM-System und den domänenspezifischen IT-Tools. Die Schnittstelle ermöglicht mittels XML den Austausch der Metadaten zwischen den IT-Tools und der Data Repository.

Information Model

ModelA Process (Workf low, roles, …)

Integrationmechanisms

VersionControl

ChangeManagement

Sof twareSpecif ic

HardwareSpecif ic

Managementfunctionalities

Tool interface

Data repository

Tool-independent format

ModelA ModelB ModelC

Datamapping

Modelupdate

Model Data Management

…ModelB

Adaption Layer

Adaption Layer

Adaption Layer

Common database

Common meta-meta model

Abbildung 4-16: MDM-Plattform-Architektur [Elkh2006]

Page 103: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 85

El-Khoury verfolgt den Ansatz des Central Data Warehouse, welcher eine Aggregation und eine Abstraktion der domänenspezifischen Informationsmodelle zu einem gemeinsamen, ver-einfachten domänenübergreifenden Informationsmodell als Hauptziel hat. Diese Vereinfa-chung führt dazu, dass viele domänenspezifische Detailinformationen, die für die gesamte Produktentwicklung von größerer Bedeutung sind, nicht mehr auf dem domänenübergreifen-den Informationsmodell abbildbar sind. Des Weiteren ist ein gemeinsames Management aller Produktdaten (mechanische, elektrotechnische und informationstechnische Daten) innerhalb eines PDM-Systems nur bedingt bzw. sehr eingeschränkt möglich, da die Granularität der elektrotechnischen und informationstechnischen Datenstruktur anders ist als die Datenstruktur mechanischer Komponenten, beispielsweise kann die Struktur eines Software-Quellcodes nicht sinnvoll in einem PDM-System abgebildet und verwaltet werden.

4.5.10 Föderatives PDM zur Verwaltung mechatronischer Systemstrukturen (Pham-Van)

Pham-Van [Pham2007] hat sich im Rahmen seiner Dissertation die Entwicklung eines Kon-zepts zur Erweiterung eines herkömmlichen PDM-Systems zum föderativen PDM-System, das zur Verwaltung einer mechatronischen Systemstruktur sowie ihrer Komponenten eingesetzt werden kann, als Ziel gesetzt. Den Kern dieses Konzepts stellt ein Informationsmodell – Kernmodell – dar, das die Abbildung der mechatronischen Produktstruktur und Metadaten ermöglichen soll. Dieses Kernmodell basiert im Wesentlichen auf dem STEP AP 214 Stan-darddatenmodell und wurde um weitere Objektklassen, die MKS_Ergebnisse-Klasse, die FEM_Ergebnisse-Klasse und die Simulation_Feedbacks-Klasse, erweitert, um einen Daten-austausch zwischen dem föderativen PDM-System und den Simulationswerkzeugen zu ermög-lichen.

Der entwickelte Ansatz dient lediglich dazu, die Simulation mechatronischer Produkte auf Gesamtsystemebene zu ermöglichen. Hierzu wurden insbesondere die Simulationsmethoden MKS51 und FEM52 unterstützt. Das definierte Kerninformationsmodell kann eine interdiszipli-näre mechatronische Produktabbildung und -beschreibung unter Betrachtung der drei Diszipli-nen Mechanik, Elektrotechnik und Informationstechnik nur teilweise unterstützen. Ferner werden manche mechatronischen Produktkomponenten wie z. B. Informationssysteme (vgl. Abschnitt 2.2.3) innerhalb des Datenmodells nur am Rande als Zulieferkomponente dargestellt und nur mit den Attributen Name und Hersteller beschrieben.

4.5.11 Virtual Product Development Environment (Storga)

Der von Storga entwickelte Virtual Product Development Environment (VPDE)-Ansatz stellt eine grobe Architektur für ein Collaborative PDM-System (CPDM) dar [StBM2003]. Dieser

51 MKS: Mehrkörpersimulation 52 FEM: Finite-Elemente-Methode

Page 104: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

86 Stand der Forschung und der Technik

Ansatz hat zum Ziel, das Datenmanagement sowie die -bereitstellung innerhalb von Entwick-lungsprojekten, die einerseits multidisziplinär sind und andererseits aus mehreren Entwick-lungspartnern bestehen, zu optimieren. Das dargestellte CPDM-System basiert auf der Web Service Technology und umfasst vier Hauptkomponenten, die Datenorganisation und die Steuerung des Datenflusses über alle Entwicklungsbereiche und -partner ermöglichen (Abbil-dung 4-17):

Design Projects and Users Manager: Diese Komponente verfügt über Funktionen zum Management von Projekten, Projektressourcen und Projektorganisationen.

Design Actions and Requests Manager: Diese Komponente stellt Funktionen zur Be-schreibung von Entwicklungsaufgaben und dessen Abhängigkeiten bereit.

Product Components Manager: Die Funktionen dieser Komponente ermöglichen die Verwaltung der Produktkomponenten und –daten sowie deren Beziehungen.

Additional Modules: Diese Komponente bietet Funktionen zur Benutzerverwaltung und zum Session-Management an.

Der VPDE-Ansatz präsentiert ein grobes IT-Konzept für ein mögliches kollaboratives PDM-System. Allerdings sind die Hauptmodule dieses Konzepts sehr generisch beschrieben und können daher nicht direkt und ohne weitere Spezifizierung übernommen bzw. umgesetzt wer-den. Ferner hat sich die genannte Arbeit sehr intensiv mit der allgemeinen Beschreibung der Web Service Technology beschäftigt, anstatt eine Vorgehensweise für die Anwendung dieser Technologie bei der Konzeptumsetzung zu geben.

Abbildung 4-17: CPDM Systemarchitektur [StBM2003]

Page 105: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 87

4.6 Bewertung des Standes der Technik und Forschung und re-sultierender Handlungsbedarf

4.6.1 Bewertung der allgemeinen IT-Integrationsansätze

Eine Bewertung der im Abschnitt 4.1 vorgestellten IT-Integrationstechnologien nach IT-relevanten Kriterien zeigt (Tabelle 4-9), dass die meisten Technologien außer der semanti-schen und des SOA-Ansatzes große Schwächen insbesondere im Hinblick auf die Flexibilität (Anforderung A.6.1 und A.6.2) aufweisen. Um die Interoperabilität zwischen den verschiede-nen Domänen innerhalb der Entwicklung mechatronischer Produkte zu ermöglichen bzw. zu verbessern, können Ansätze aus der semantischen bzw. aus der SOA-Technologie oder diese auch in Kombination miteinander verwendet werden. Jedoch zeichnet sich heute die techni-sche Umsetzung der semantischen Technologie aufgrund der fehlenden Tools (s. Abschnitt 4.1.6) als sehr schwierig ab, was zumindest einen mittelfristigen Einsatz nicht möglich macht. Technisch gesehen ist die Umsetzung eines SOA-Konzepts heutzutage sehr realistisch, aller-dings fehlt hier noch eine SOA-Leitarchitektur, die vor einer Umsetzung anwendungsbezogen definiert werden muss.

Ansätze

Anforderungen

Übe

rwin

dung

der

IT-

Het

erog

enitä

t (A

.4.1

)

Schu

tz b

este

hend

er IT

-In

vest

ition

en (A

.5.1

)

Unt

erst

ützu

ng u

nd E

rmög

li-ch

ung

der Ä

nder

ungs

dyna

mik

(A

.6.1

)

Ver

knüp

fung

der

dom

änen

-sp

ezifi

sche

n PL

M-S

yste

me

nach

dem

Prin

zip

der l

osen

K

oppl

ung

(A.6

.2)

Proprietäre Punkt-zu-Punkt Schnittstellen � � �

Standard Datenmodelle � �

Data Warehouse �

Single IT-Systeme � � �

EAI � �

Semantische Technologien

SOA

Legende: geeignet teilweise geeignet � nicht geeignet

Page 106: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

88 Stand der Forschung und der Technik

Tabelle 4-9: Bewertung der IT-Integrationstechnologien

4.6.2 Bewertung der Produktdatenintegrationsansätze

Die untersuchten Produktdatenintegrationsansätze sind durch ihre Monodisziplinarität gekenn-zeichnet. Dabei stellt vor allem die Beschreibung der mechanischen und simulationstechni-schen Produktdaten den Hauptfokus dieser Standarddatenmodelle dar. Einer der Hauptgründe hierfür ist, dass die meisten Datenmodelle innerhalb der Produktentwicklung auf Basis des STEP-Datenmodells erstellt wurden. Eine Erweiterung dieses Standards um weitere Diszipli-nen ist theoretisch möglich, aber dieses wird deren Komplexität – die ohnehin schon sehr groß ist – nur weiter erhöhen und somit deren Umsetzung weiter erschweren.

Ansätze

Anforderungen

Abb

ildun

g al

ler i

nter

disz

iplin

ären

Pro

-du

ktda

ten

(A.3

.1)

Erst

ellu

ng e

iner

inte

rdis

zipl

inär

en lo

gi-

sche

n Sy

stem

arch

itekt

ur (A

.3.2

)

Abb

ildun

g de

r Übe

rleitu

ng v

on d

er

logi

sche

n zu

der

tech

nisc

hen

Syst

emar

chite

ktur

(A.3

.3)

Ver

knüp

fung

alle

r fac

hspe

zifis

chen

Par

-tia

ldat

enm

odel

le (A

.3.4

)

Schü

tzen

von

ber

eits

eta

blie

rten

fach

spe-

zifis

chen

Par

tiald

aten

mod

elle

n so

wie

de

ren

Aut

oritä

t und

Fre

ihei

t (A

.3.5

, A

.3.6

)

Erw

eite

rbar

keit

um n

eue

Obj

ekte

und

D

iszi

plin

en (A

.3.7

)

Erm

öglic

hung

ein

es d

omän

enüb

ergr

ei-

fend

en u

nd d

urch

gäng

igen

Dat

enflu

sses

(A

.3.8

)

Erm

öglic

hung

von

do

män

enüb

ergr

eife

ndem

Ver

sion

s-,

Kon

figur

atio

ns-,

Änd

erun

gs- u

nd

Frei

gabe

man

agem

ent(

A3

9)B

asis

für d

ie In

tegr

atio

n vo

n fa

chsp

ezifi

-sc

hen

Entw

ickl

ungs

erge

bnis

sen

(A.3

.10)

STEP � � � � � � � � STEP-PDM-Schema � � � � � � � �

MechaSTEP � � �

Legende: geeignet teilweise geeignet � nicht geeignet

Tabelle 4-10: Bewertung der Produktdatenintegrationsansätze

4.6.3 Bewertung der Funktionsintegrationsansätze

Die vorgestellten Funktionsintegrationsansätze haben zum Ziel die Zusammenarbeit heteroge-ner PLM-Systeme durch die Bereitstellung von standardisierten Diensten zu ermöglichen. Hierzu verwenden PLM-Systeme Standard-Services, um auf Funktionen anderer PLM-Systeme zugreifen zu können. Allerdings basieren diese Ansätze hauptsächlich auf den STEP AP214 Standard und legen daher ihren Fokus nur auf die mechanischen Aspekte eines Pro-

Page 107: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 89

dukts. Eine Erweiterung dieser Standard-Dienste um weitere mechatronische Aspekte wäre möglich, aber setzt diese eine Erweiterung des zugrundliegenden Standards – in diesem Fall der STEP AP214 – voraus (s. Abschnitt 4.6.2).

Ansätze

Anforderungen

Erm

öglic

hung

ein

er in

terd

iszi

pli-

näre

n un

d fu

nktio

nsor

ient

ierte

n En

twic

klun

gsm

etho

dik

(A.1

.1 –

A

1.6)

Unt

erst

ützu

ng d

er S

ynch

roni

satio

n fa

chsp

ezifi

sche

r Ent

wic

klun

gspr

o-ze

sse

(A.2

.1 –

A.2

.4)

Erfü

llung

der

dat

enbe

zoge

nen

Anf

orde

rung

en (A

.3.1

– A

.3.1

0)

Inte

rdis

zipl

inar

ität (

A.4

.1 –

A.4

.3)

Flex

ibili

tät (

A.6

.1, A

.6.2

)

PDM-Enablers � � � � OMG PLM

Services � � � �

Legende: geeignet teilweise geeignet � nicht geeignet

Tabelle 4-11: Bewertung der Funktionsintegrationsansätze

4.6.4 Bewertung der domänenspezifischen PLM-Anwendungen

Die marktgängigen PLM-Anwendungen sind für das Management der Entwicklungsprozesse und -daten sowie für die Integration von IT-Werkzeugen innerhalb der einzelnen Domänen gedacht und konzipiert worden. Jedoch verfügen derartige Systeme über hohe und nützliche Potenziale – vor allem was die leistungsstarken Funktionalitäten, WFMS53 und Schnittstellen betrifft –, die in Richtung Management von interdisziplinären Prozessen und Daten innerhalb der Entwicklung mechatronischer Produkt genutzt bzw. erweitert werden können. Insbesonde-re die PDM-Systeme können aufgrund ihres Entwicklungsvorsprungs gegenüber den EES- und SCM-Systemen einen wertvollen Beitrag als Basis für die Entwicklung einer integrierten mechatronischen Integrationsplattform leisten.

53 WFMS: Workflow-Management-System

Page 108: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

90 Stand der Forschung und der Technik

Ansätze

Anforderungen

Übe

rwin

dung

der

IT-

Het

erog

enitä

t (A

.4.1

)

Unt

erst

ützu

ng in

terd

iszi

plin

ä-re

r und

funk

tions

orie

ntie

rter

Entw

ickl

ungs

met

hodi

k (A

.4.2

,)

Erm

öglic

hung

der

Syn

chro

ni-

satio

n de

r fac

hspe

zifis

chen

En

twic

klun

gspr

ozes

se (A

.4.3

)

Schu

tz b

este

hend

er IT

-In

vest

ition

en (A

.5.1

)

Unt

erst

ützu

ng u

nd E

rmög

li-ch

ung

der Ä

nder

ungs

dyna

mik

(A

.6.1

)

Ver

knüp

fung

der

dom

änen

-sp

ezifi

sche

n PL

M-S

yste

me

nach

dem

Prin

zip

der l

osen

K

oppl

ung

(A.6

.2)

PDM-Systeme

EES-Systeme

SCM-Systeme

Legende: geeignet teilweise geeignet � nicht geeignet

Tabelle 4-12: Bewertung der domänenspezifischen PLM-Anwendungen

4.6.5 Bewertung der Forschungsaktivitäten

Obwohl sich mehrere Forschungsarbeiten in den letzten Jahren dem Thema integrierte Ent-wicklung mechatronischer Produkte gewidmet haben, zeigt die Analyse und Bewertung dieser Projekte, dass die Aspekte der Interdisziplinarität mechatronischer Systeme nicht ausreichend und umfassend betrachtet und gelöst wurden. Des Weiteren ist bei der Untersuchung dieser Forschungsaktivitäten festzustellen, dass in den meisten Projekten unter integrierter Entwick-lung mechatronischer Systeme vielmehr die Integration der geometrischen Modelle aus den CAD-Tools mit den Berechnungs- bzw. Simulations-Modellen (z. B. FEM, MKS) aus den CAE-Tools verstanden wurde. Die Realisierung einer integrierten Entwicklung mechatroni-scher Systeme unter vollständiger Betrachtung der drei Disziplinen Mechanik, Elektrotechnik und Informationstechnik wurde in sehr wenigen Forschungsprojekten als Hauptziel definiert.

Page 109: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 91

Ansätze

Anforderungen

Erm

öglic

hung

ein

er in

terd

iszi

pli-

näre

n un

d fu

nktio

nsor

ient

ierte

n En

twic

klun

gsm

etho

dik

(A.1

.1 –

A

1.6)

Unt

erst

ützu

ng d

er S

ynch

roni

satio

n fa

chsp

ezifi

sche

r Ent

wic

klun

gspr

o-ze

sse

(A.2

.1 –

A.2

.4)

Erfü

llung

der

dat

enbe

zoge

nen

Anf

orde

rung

en (A

.3.1

– A

.3.1

0)

Inte

rdis

zipl

inar

ität (

A.4

.1 –

A.4

.3)

Schu

tz b

este

hend

er IT

-In

vest

ition

en (A

.5.1

)

Flex

ibili

tät (

A.6

.1, A

.6.2

)

iViP � � � � �

PDM-C � � � �

Mechasoft � � �

EUMECH � � � � �

VIVACE � � �

MIKADO � �

Ansatz von Gerhard � � � �

Ansatz von Kleiner � � � � Ansatz von El-Khoury � � Ansatz von Pham-Van � � �

Ansatz von Storga � � � �

Legende: geeignet teilweise geeignet � nicht geeignet

Tabelle 4-13: Bewertung der Forschungsprojekte

4.6.6 Fazit und resultierender Handlungsbedarf

Das Ziel einer voll integrierten und interdisziplinären Entwicklung mechatronischer Produkte unter Betrachtung aller Domänen Mechanik, Elektrotechnik und Informationstechnik kann nur erreicht werden, wenn eine ausreichende Interoperabilität zwischen den verschiedenen domä-nenspezifischen Entwicklungsprozessen, -daten und IT-Werkzeugen herrscht. Um die nötige Interoperabilität realisieren zu können, sind geeignete interdisziplinäre Mechanismen für die Befähigung der Zusammenarbeit zwischen den jeweiligen Domänen nicht nur auf Organisati-

Page 110: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

92 Stand der Forschung und der Technik

onsebene sondern auch auf Prozess-, Daten- und IT-Ebene erforderlich. Diese Mechanismen sollen die verschiedenen domänenspezifischen Entwicklungsprozesse, Partialdatenmodelle und IT-Werkzeuge auf eine interdisziplinäre Produktebene zur Durchführung interdisziplinä-rer Prozessaufgaben verknüpfen und synchronisieren. Dies kann nur bewältigt werden, wenn ein prozessgesteuerter Interoperabilitätsansatz verfolgt wird, welcher das Zusammenspiel der verschiedenen mechatronischen Domänen flexibel und gezielt auf den Bedarf der zu erledi-genden Prozessaktivitäten steuert und regelt.

Die gängigen IT-Integrationstechnologien stellen eine technisch gut ausgereifte Basis für die Realisierung einer flächendeckenden Interoperabilität innerhalb einer heterogenen IT-Systemlandschaft dar. Vor allem der Siegeszug der Web Service-Technologie hat heute viele neue Möglichkeiten und Potenziale geschaffen, um eine günstige, schnelle und flexible Inter-aktion und Kommunikation zwischen verschiedenen IT-Systemen mit unterschiedlichen Ba-sistechnologien herstellen zu können. Dennoch fehlt zurzeit eine Leitarchitektur bzw. eine Vorgehensweise für einen effizienten und zielführenden Einsatz solcher Technologien zur Erreichung der erhofften Interoperabilitätsziele.

Für die Realisierung einer integrierten und interdisziplinären Entwicklung mechatronischer Produkte ist neben den IT-Integrationstechnologien die Bereitstellung einer föderierten me-chatronischen Integrationsplattform von großer Bedeutung. Diese Plattform soll sowohl die interdisziplinären Prozessaktivitäten und Daten steuern und verwalten als auch die verschiede-nen domänenspezifischen PLM-Anwendungen (PDM, EES und SCM) nach dem Prinzip der losen Kopplung miteinander verknüpfen. Die marktgängigen PLM-Anwendungen können trotz ihrer strengen domänenspezifischen Konzeption einen wertvollen Beitrag hierbei leisten, da sie über leistungsfähige Managementfunktionalitäten, WFMS und web-basierte Schnittstel-len, die um interdisziplinäre Aspekte erweitert und angepasst werden können, verfügen.

Trotz zahlreicher wissenschaftlicher Arbeiten und Publikationen sowie Standards im Umfeld der Mechatronik ist eine umfassende Betrachtung und Behandlung aller mechatronischen As-pekte heute zu vermissen. Die Analyse der dabei entwickelten Konzepte zeigt, dass diese For-schungsarbeiten und Standards sich noch in einem monodisziplinarischen Umfeld bewegen und nur Lösungen für sehr eingeschränkte Teilprobleme anbieten.

Eine integrierte und interdisziplinäre Entwicklung mechatronischer Produkte bedingt ein Inter-operabilitätskonzept, welches ein synergetisches Zusammenspiel zwischen den verschiedenen Domänen ermöglicht. Dieses Konzept muss die folgenden Punkte umfassen:

Die Definition einer prozessorientierten Integrationsarchitektur für die Realisierung ei-ner prozessgesteuerten Interoperabilität zwischen den verschiedenen domänenspezifi-schen Entwicklungsprozessen, Partialdatenmodellen und PLM-Anwendungen (PDM, EES und SCM).

Die Definition eines Vorgehensmodells, das die Umsetzung der prozessorientierten In-

Page 111: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Stand der Forschung und der Technik 93

tegrationsarchitektur zur Realisierung einer mechatronischen Integrationsplattform er-möglicht.

Die Definition von Methoden für die interdisziplinäre und funktionsorientierte Syn-chronisation der domänenspezifischen Prozessaktivitäten: Versionsmanagement, Konfi-gurationsmanagement, Änderungsmanagement und Freigabemanagement.

Die Definition eines mechatronischen Meta-Datenmodells, welches die Anforderungen A.3.1 – A.3.10 erfüllt.

Die Definition der Funktionalitäten der mechatronischen Integrationsplattform, die eine integrierte, funktionsorientierte und interdisziplinäre Entwicklung mechatronischer Pro-dukte unterstützt.

Page 112: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

94 Grundkonzept einer SOA-basierten Integrationsplattform

5 Grundkonzept einer SOA-basierten Integrations-plattform

5.1 Gesamtkonzept

Die Entwicklung mechatronischer Produkte, die durch die synergetische Zusammenwirkung von Lösungsprinzipien aus den Disziplinen Mechanik, Elektrotechnik und Informationstech-nik entstehen, erfordert eine abgestimmte domänenübergreifende Zusammenarbeit der nicht nur an der Entwicklung beteiligten Personen und Organisationseinheiten, sondern auch der domänenspezifischen Entwicklungsprozesse, Partialdatenmodelle sowie IT-Werkzeuge. Wäh-rend das durchgängige Management und die vollständige Integration der Prozesse, Datenmo-delle und IT-Werkzeuge innerhalb der einzelnen Disziplinen dank leistungsfähiger domänen-spezifischer PLM-Systeme (PDM-, EES- und SCM-Systeme) längst als Realität zu betrachten sind, ist heute ein adäquates, interdisziplinäres Prozess- und Datenmanagement über alle Do-mänen hinweg kaum möglich. Ziel dieser Arbeit ist es, ein Interoperabilitätskonzept zu entwi-ckeln, das ein interdisziplinäres Prozess- und Datenmanagement innerhalb eines heterogenen und komplexen Umfelds – wie der Mechatronik – ermöglicht. Als Leitfaden für die Entwick-lung dieses Konzept wird das im Rahmen der VDI-Richtlinie 2206 „Entwicklungsmethodik für mechatronische Systeme“ beschriebene V-Modell (Makrozyklus) dienen.

Diese Arbeit verfolgt einen SOA-Ansatz für die Entwicklung eines prozessorientierten Inter-operabilitätskonzepts, welches eine interdisziplinäre Produktentwicklung mechatronischer Systeme insbesondere während der Systementwurfs- und Systemintegrationsphase ermöglicht. Dieses Konzept stellt eine serviceorientierte Architektur dar, die als Basis für eine prozess-orientierte Integration der verschiedenen domänenspezifischen PLM-Anwendungen auf einer domänenübergreifenden mechatronischen Ebene dienen soll. Eine mechatronische Inte-grationsplattform (mIP) bildet den Kern dieser Architektur, die über Funktionalitäten für das Management sowie die Steuerung von interdisziplinären Entwicklungsprozessen und -daten verfügt. Die mIP stellt ein PLM-Tool für die Entwicklungsprozessbeteiligten dar, wel-che die domänenübergreifenden Aufgaben haben wie beispielsweise Gesamtsystemdesigner, Gesamtsystementwickler, Funktionsverantwortlicher, Release-Manager. Die Konzipierung dieser Integrationsplattform beruht auf einer Reihe von interdisziplinären Management- und Steuerungsmethoden, die ein interdisziplinäres Versionierungs-, Änderungs-, Konfigurations- und Freigabemanagement über alle Domänen hinweg ermöglichen. Die interdisziplinäre Be-schreibung sowie die Handhabung von mechatronischen Systemen, Funktionen, technischen

Page 113: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundkonzept einer SOA-basierten Integrationsplattform 95

Komponenten sowie deren Abhängigkeiten bzw. Beziehungen untereinander können mittels eines mechatronischen Meta-Datenmodells durchgeführt werden. Dieses Datenmodell stellt auch eine Grundlage für die Verwaltung und Steuerung von interdisziplinären Produktdaten, die während der domänenübergreifenden Produktentwicklungsprozesse entstehen, in der me-chatronischen Integrationsplattform dar. Des Weiteren sind die verschiedenen domänenspezi-fischen Partialdatenmodelle auf Basis dieses Datenmodells zu verknüpfen, zu synchronisieren und zu harmonisieren mit dem Ziel, die Entwicklungsdaten und -ergebnisse aus den verschie-denen Domänen auf eine interdisziplinäre Gesamtproduktebene zu einer funktionsfähigen me-chatronischen Gesamtlösung zu integrieren.

Das Management und die Steuerung von interdisziplinären Entwicklungsprozessen und -daten innerhalb der mechatronischen Integrationsplattform (mIP) bedingen in der Regel die Zusam-menarbeit von mehreren Funktionalitäten und Daten aus den unterschiedlichen domänenspezi-fischen PLM-Anwendungen (d. h. PDM-, EES- und SCM-System). Die Interaktion bzw. die Kommunikation der domänenspezifischen PLM-Anwendungen mit der mIP wird durch die Verwendung von Services realisiert. Hierzu werden die Funktionen inklusive Input- und Out-put-Daten der jeweiligen domänenspezifischen PLM-Anwendungen als standardisierte Servi-ces mittels geeigneter Adapter die sogenannten SOA-Adapter für die mIP bereitgestellt. Die domänenübergreifende Daten- und Prozessdurchgängigkeit bei der Ausführung von interdis-ziplinären Management- bzw. Steuerungsfunktionalitäten innerhalb der Integrationsplattform wird durch den Einsatz von SOA-basierten Integrationsmechanismen sichergestellt, welche das Interagieren der Services miteinander über alle domänenspezifischen PLM-Anwendungen hinweg steuern und synchronisieren. Diese serviceorientierte Kommunikation bzw. Verknüp-fung trägt maßgeblich zur Realisierung einer flexiblen PLM-Systemlandschaft bei, indem sie eine harte Verbindung der Systeme durch direkte Schnittstellen sowie eine starke gegenseitige Abhängigkeit und Beeinflussung vermeidet. Damit kann die interne Freiheit und Autorität der Systeme im Hinblick auf ihre Weiterentwicklung geschützt werden.

Page 114: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

96 Grundkonzept einer SOA-basierten Integrationsplattform

Informationstechnik

Elektrotechnik

Mechanik

Domänenspezifischer Systementwurf

mIP

SOA-basierte Integration

SOA-Adapter

SOA-Adapter

Interdisziplinäre mIP-Funktionen:• Versionierungsmanagement• Konfigurationsmanagement• Freigabemanagement• Änderungsmanagement• Handhabung interdisziplinärer Produktdaten

Föderiertes mechatronischesDatenmodell

SCM

EES

PDM

Unterstützung interdisziplinärerEntwicklungsprozesse

Legende:mIP: mechatronische IntegrationsplattformPDM: Produktdatenmanagement SystemEES: Electrical Engineering Solution SystemSCM: Software Configuration Management System

Abbildung 5-1: Grundkonzept einer SOA-basierten Integrationsplattform

Im nächsten Abschnitt 5.2 wird eine im Rahmen dieser Arbeit definierte generische service-orientierte Architektur vorgestellt, die als Basis für die Entwicklung einer serviceorientierten mechatronischen Integrationsplattform dienen soll. Im Abschnitt 5.3 wird eine für diese Arbeit erstellte Vorgehensweise zur Umsetzung dieser generischen Architektur als Interoperabilitäts-lösung innerhalb der Entwicklung mechatronischer Produkte vorgestellt. Die Umsetzung die-ser Vorgehensweise und die dabei entstandenen Komponenten der mechatronischen service-orientierten Architektur sind Gegenstand der Kapitel 6, 7, 8 und 9 sein.

Page 115: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundkonzept einer SOA-basierten Integrationsplattform 97

5.2 Generische serviceorientierte Architektur

Trotz der Bemühungen mehrerer Standardisierungsgremien, wie z. B. OASIS (s. Abschnitt 4.1.7), ein SOA-Referenzmodell zu definieren, hat sich heute noch keine einheitliche Definiti-on des Begriffs einer serviceorientierten Architektur durchgesetzt. Die Spannbreiten reichen von Definitionen, die SOA als IT-Architektur-Paradigma sehen, bis hin zu Definitionen, bei denen SOA die serviceorientierte Restrukturierung aller Unternehmensprozesse umfasst, d. h. Themen, die in den Zeiten vor SOA noch als Geschäftsprozessoptimierung bzw. Business Process Reengineering bezeichnet wurden [HWSD2007]. Dies hat dazu geführt, dass heute keine standardisierte bzw. einheitliche Aufbauarchitektur existiert, die die Komponenten und die Struktur einer serviceorientierten Architektur bestimmt und beschreibt. Vielmehr existiert eine Reihe von unternehmensspezifischen bzw. lösungsspezifischen Architekturen, die durch diverse Beratungsunternehmen (z. B. Gartner Group, McKinsey) oder IT-Hersteller (z. B. IBM, SAP, Oracle) entwickelt wurden mit dem Ziel, ihre Dienstleistungen bzw. IT-Lösungen besser vermarkten zu können.

Ziel dieses Abschnitts ist es, eine neutrale und generische serviceorientierte Architektur sowie ein dafür erstelltes Metamodell vorzustellen, die auf der im Abschnitt 4.1.7 zitierten SOA-Definition und den vorgestellten Grundprinzipien basieren.

Die generische serviceorientierte Architektur ist ein abstraktes und technologieneutrales Architekturkonzept, d. h. es kann sowohl mit Web Service-Technologie als auch mit anderen Technologien, wie z. B. CORBA oder .Net-Remoting, realisiert werden. Das Konzept erfüllt die konzeptionellen Voraussetzungen zur Realisierung eines Gesamtsystems aus voneinander weitgehend unabhängigen Teilsystemen – die allein über Services miteinander kommunizieren –, um eine durchgängige und integrierte Businessprozess-Durchführung über alle IT-Anwendungen hinweg zu gewährleisten. Die Grundidee dabei ist es, fachliche Systemfunktio-nalitäten in kleine, lose gekoppelte Einheiten, genannt Services, zu kapseln, um diese schließ-lich flexibel zur Systemlaufzeit für die Integration von Prozessen aufzurufen. Die generische serviceorientierte Architektur stellt ein Schichtenmodell dar, welches aus fünf Schichten be-steht: Applikations-, Service-, Workflow-, Integrations- und Prozessschicht. Die Kommunika-tion der Service-, Workflow- und Integrationsschichten miteinander wird durch den Einsatz eines Registry- und eines Mediation-Moduls ermöglicht (Abbildung 5-2).

Page 116: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

98 Grundkonzept einer SOA-basierten Integrationsplattform

Funktion

FöderiertesDatenmodell

Inte

grat

ions

-sc

hich

tW

orkf

low

-sc

hich

tS

ervi

ce-

schi

cht

App

likat

ions

-sc

hich

t

Anwendung 1 Anwendung nAnwendung 2

Prozessschicht

Anwendung 3

Med

iatio

n-M

odul

Registry-M

odul

FunktionService

Workflow-AktivitätWorkflow

Legende: DomänenspezifischeAnwendungsfunktionen

DomänenspezifischeAnwendungsdatenbank

SOA-Adapter

Abbildung 5-2: Generische serviceorientierte Architektur

Applikationsschicht

Die Applikationsschicht enthält domänenspezifische Anwendungssysteme, die zur automati-schen Verarbeitung, Verwaltung und Steuerung von Informationen bzw. Daten innerhalb der Fachbereiche dienen z.B. PDM-, EES- und SCM-Systeme. Diese Applikationen sind in die-sem Modell als IT-Ressourcenquellen zu betrachten, welche ihre eigenen Daten und Funktio-nen in kapselbarer Form (sog. Services) über geeignete Schnittstellen zur Verfügung stellen.

Serviceschicht

Innerhalb der Serviceschicht werden die von domänenspezifischen Anwendungen bereitges-tellten Funktionen inklusive Daten in Form von standardisierten Services angeboten. D. h. die Services präsentieren eine Standardbeschreibung der anwendungsspezifischen Funktionen und der dazugehörenden Input- und Output-Daten sowie weitere Informationen zur Ausführung und zur Nutzung der angebotenen Funktionen. Die Definition der Services erfolgt Bottom-up basierend auf den von den verschiedenen domänenspezifischen Anwendungen bereitzustellen-den Funktionen. Um eine hohe Interoperabilität innerhalb einer heterogenen Systemlandschaft erreichen zu können, werden die Implementierungsdetails sowie die technologische Komple-xität der unterschiedlichen Anwendungssysteme mittels der Services abstrahiert und in einer standardisierten Form beschrieben.

Workflow-Schicht

Die Durchführung von domänenübergreifenden Prozessaktivitäten benötigt meistens die Dienste von mehreren Funktionen aus unterschiedlichen domänenspezifischen Anwendungen

Page 117: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundkonzept einer SOA-basierten Integrationsplattform 99

gleichzeitig. Diese anwendungsübergreifende Interaktion der verschiedenen Funktionen und ihrer Input- und Output-Daten soll dementsprechend koordiniert und gesteuert werden, um die Durchgängigkeit bei der anwendungsübergreifenden Bearbeitung von Geschäftsvorfällen ge-währleisten und somit Medienbrüche vermeiden zu können.

In der Workflow-Schicht werden Workflows definiert, die mehrere Aktivitäten gemeinsam über alle domänenspezifischen Anwendungen hinweg koordinieren und steuern. Dabei präsen-tiert eine Aktivität eine in sich geschlossene Verrichtungseinheit in einem Prozess, die logisch und fachlich zusammengehörende Arbeitsschritte (Prozessaufgaben) in einem aus Sicht des Benutzers sinnvollen Arbeitspaket zusammenfasst [HeLe2005]. Die einzelnen Aktivitäten wiederum nutzen auf der unteren Serviceschicht die dazu erforderlichen Services, um die Pro-zessaufgaben zu verrichten, d.h. die Services sind für die IT-Ausführung von Workflowaktivi-täten verantwortlich.

Integrationsschicht

Die Integrationsschicht stellt alle notwendigen Funktionen und Daten zur Verfügung, die eine domänenübergreifende Prozessdurchführung über alle IT-Anwendungen hinweg möglich macht. Die Funktionen dieser Schicht werden aus den Anforderungen der domänenübergrei-fenden Prozesse abgeleitet bzw. definiert und bilden in der Regel mehrere Aktivitäten, die zu Workflows auf der unteren Workflow-Schicht zusammengesetzt werden.

Die Integrationsschicht setzt auf ein domänenübergreifendes mechatronisches Meta-Datenmodell auf. Dieses Modell ermöglicht einerseits die Kommunikation zwischen der Integ-rationsschicht und den innerhalb der Applikationsschicht existierenden fachbereichsspezifi-schen Anwendungen auf Metadatenebene – d. h. alle für eine interdisziplinäre Prozessdurch-führung notwendigen domänenspezifischen Metadaten werden auf Basis des Datenmodells abstrahiert und homogenisiert – und andererseits die Beschreibung der interdisziplinären Da-tenobjekte sowie deren Beziehungen und Abhängigkeiten. Die Integrationsschicht soll als eine Integrationsplattform für die Unterstützung von domänenübergreifenden Prozessen wie z.B. die mIP umgesetzt werden.

Prozessschicht

Innerhalb der Prozessschicht werden domänenübergreifende Prozessabläufe definiert und dar-gestellt. Dabei wird eine Reihe von domänenübergreifenden Prozessaufgaben, die in einer vorgegebenen Ablauffolge zu erledigen sind und ggf. durch Applikationen unterstützt werden, als Einheit zusammengefasst. Für die Erledigung dieser Prozessaufgaben werden die Funktio-nalitäten und das mechatronische Meta-Datenmodell der Integrationsschicht verwendet. Inner-halb der Prozessschicht können z.B. die domänenübergreifenden Prozessschritte für die Ent-wicklung mechatronischer Produkte definiert werden.

Page 118: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

100 Grundkonzept einer SOA-basierten Integrationsplattform

Mediation-Modul

Das Mediation-Modul bildet das technische Rückgrat und die zentrale Informationsdrehschei-be für die Organisation, die Abwicklung und die Administration einer nachrichtenbasierten Interaktion der Integrations-, Workflow- und Serviceschicht miteinander und stellt Funktiona-litäten zur Verfügung, die den modularen und lose gekoppelten Aufbau des Gesamt-SOA-Lösungssystems sicherstellen. Zu den Hauptfunktionen des Mediation-Moduls zählen u. a. vgl. [Math2007]:

die Ermittlung zur Laufzeit für eine Anfrage aus der Integrationsschicht passenden und geeigneten Workflows und Services durch die Auswertung von Informationen aus dem Registry-Modul (s. Registry-Modul).

die Anbindung der zu kommunizierenden SOA-Komponenten, d. h. Integrationsschicht, Workflows und Services, an die Infrastruktur zum Nachrichten-Transport zwischen Sender und Empfänger.

Registry-Modul

Das Registry-Modul dient als öffentliches Verzeichnis für die Workflow- und Services-Beschreibungen. Zu diesen Beschreibungen gehören auf der einen Seite organisatorische In-formationen, die das Auffinden von Workflows und Services ermöglichen (z. B. Name, ID, Adresse), auf der anderen Seite technische Informationen – sog. Kommunikationskontrakte –, die die Voraussetzung (z. B. Nachrichtenformate, Technologieabhängigkeiten, Programmier-sprachen, Kommunikationsprotokolle, Laufzeitumgebung, maximale Antwortzeiten, Verfüg-barkeit, Funktionsbeschreibung, Dienstqualität, Sicherheitsmechanismen) für das Interagieren der beteiligten Komponenten festlegen.

Das Registry-Modul ist direkt an das Mediation-Modul angeschlossen, das diesen Zugriff be-nötigt, um die Kommunikation zwischen Integrations-, Workflow- und Serviceschicht abzu-wickeln.

Die Abbildung 5-3 zeigt die Zuordnung der Komponente des Grundkonzepts zu den jeweili-gen Elementen der serviceorientierten Architektur.

Page 119: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundkonzept einer SOA-basierten Integrationsplattform 101

Grundkonzept

Generische serviceorientierte Architektur

Abbildung 5-3: Zuordnung der Komponenten des Grundkonzepts zu den Elementen der servi-ceorientierten Architektur

5.2.1 Metamodell für die generische serviceorientierte Architektur

Um die Struktur und die Elemente der generischen serviceorientierten Architektur sowie deren Zusammenhänge formal zu beschreiben, wurde ein Metamodell mittels der Modellierungs-sprache UML entworfen. Die folgenden Klassen und deren Beziehungen sind dafür vorgese-hen (Abbildung 5-3):

Die Klasse Interdisziplinärer_Prozess dient zur Abbildung von interdisziplinären (Sub-)Prozessen (z.B. Entwicklungsprozesse mechatronischer Produkte). Ein interdisziplinä-rer (Sub-)Prozess umfasst eine Menge von domänenübergreifenden Domönenübergrei-fende_Aufgaben (z.B. Aufgaben bei der Entwicklung mechatronischer Produkte), die in einer vorgegebenen Ablauffolge zu erledigen sind und ggf. durch mehrere domänenspe-zifische Anwendungen unterstützt werden vgl. [HeLe2005].

Die Klasse Integrationsplattform beschreibt eine Anwendung, die das Management und die Steuerung von interdisziplinären Prozessen und Daten über alle domänenspezifi-schen Anwendungen hinweg ermöglicht. Zu diesem Zweck verfügt eine Integrations-plattform über mehrere Management-, Steuerungs- und Allgemein-Funktionen Integra-tionsplattform_Funktionen, die zur Handhabung von interdisziplinären Daten z. B. Ver-sionieren, Konfigurieren, Freigaben, Ändern, Verwalten, Lenken oder Löschen dienen können.

Die Klasse Item stellt alle interdisziplinäre Objekte (z.B. mechatronische Systeme, me-chatronische Produktfunktionen) dar, die innerhalb der Integrationsplattform verwaltet werden. Darüber hinaus ermöglichen derartige interdisziplinäre Objekte die Kopplung der verschiedenen disziplinspezifischen Partialdatenmodelle miteinander mit dem Ziel, eine durchgängige Datenverarbeitung über alle Domänen zu ermöglichen.

Page 120: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

102 Grundkonzept einer SOA-basierten Integrationsplattform

Die Klasse Interdisziplinäre_Daten stellt alle Metadaten (z.B. Bezeichnung, Status) dar, die die zu verwaltenden interdisziplinären Objekte und deren Abhängigkeiten (z.B. funktionale Abhängigkeiten zwischen mechatronischen Systemen) beschreiben.

Eine Integrationsplattform_Funktion (z.B. Freigabe eines mechatronischen Systems) kann eine oder mehrere Aktivitäten (z.B. Ermittlung des Freigabestatus der technischen Systeme, d.h. mechanisches, elektrotechnisches und informationstechnisches System, des mechatronischen Systems) umfassen, die mittels einer oder mehrerer Funktionen von domänenspezifischen Anwendungen (z.B. Ermittlung des Freigabestatus des me-chanischen Systems im PDM-System) ausgeführt werden können. Die Klasse Aktivität wird dazu genutzt, alle notwendigen Aktivitäten für die vollständige Realisierung von Integrationsplattformfunktionen abzubilden.

Falls eine Integrationsplattformfunktion nur die Dienste einer einzelnen domänenspezi-fischen Anwendungsfunktion braucht, werden diese Dienste durch einen einzelnen Ser-vice bereitgestellt. Diese Situation wird durch die 1:1 Assoziation der Klasse Aktivität mit der Klasse Service abgebildet. Andernfalls sind für die Ausführung einer Integrati-onsplattform mehrere domänenspezifische Anwendungsfunktionen notwendig, was durch die 1:1..* Assoziation der Klasse Aktivität mit der Klasse Service abzubilden ist.

Die Klasse Workflow präsentiert alle Workflows zur automatischen Steuerung der Aus-führung von mehreren Aktivitäten über mehrere domänenspezifische Anwendungen. Workflows bieten Integrations- und Laufzeitdienste für die Bündelung, Synchronisie-rung und Steuerung von Aktivitäten zur Realisierung anwendungsübergreifender Inte-gration der Geschäftsprozesse. Z.B. kann ein Workflow die einzelnen Aktivitäten zur Ermittlung der Freigabestatus der technischen Systeme eines mechatronischen Systems zusammenführen und synchronisieren, um den Freigabestatus des gesamten mechatro-nischen Systems zu definieren.

Jede Funktion einer domänenspezifischen Anwendung (z.B. Ermittlung des Freigabe-status eines mechanischen Systems im PDM-System) und die zugehörigen Input- und Output-Daten werden durch einen Service beschrieben und auf Serviceebene repräsen-tiert. Dieses wird durch die Assoziation zwischen der Klasse Service und der Klasse Domänenspezifische_Anwendung abgebildet. Dabei stellt die Klasse Service eine ab-strakte Beschreibung der Funktionen der domänenspezifischen Anwendungen inklusive Ausführungsinformationen, Input- und Output-Daten dar.

Integrationsplattform_Funktionen, Workflows und Services kommunizieren miteinander sowie mit ihrem Anbieter und Nutzer durch Senden und Empfangen von Nachrichten, die durch die Klasse Nachricht abgebildet werden. Zur Ermittlung der geeigneten Kommunikationspartner und zur Ermöglichung der Kommunikation werden die Ver-mittlungs- und Kommunikationsdienste des Mediation-Moduls in Anspruch genommen.

Page 121: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundkonzept einer SOA-basierten Integrationsplattform 103

Die Klasse Registry-Modul stellt Metadaten bereit, die die Workflows und Services or-ganisatorisch und technisch beschreiben, so dass eine Nutzung ihrer Dienste ohne wei-tere zusätzliche Informationen sichergestellt wird.

Die Klasse Domänenspezifische_Anwendung präsentiert alle domänenspezifischen An-wendungssysteme (z.B. PDM-, EES-, SCM-System), die die domänenspezifischen Ob-jekte Domänenspezifische_Item, Daten Domänenspezifische_Daten und Prozesse Do-mänenspezifischer_Prozess sowie Aufgabe Domänenspezifische_Aufgabe verwalten und steuern. Diese Anwendungen stellen Funktionen Domänenspezifi-sche_Anwendungsfunktion inklusive Input- und Output-Daten als Services über geeig-neten Schnittstellen zur Verfügung, d. h. die domänenspezifischen Anwendungen sind für die Implementierung der Dienste, die durch die Services angeboten werden, verant-wortlich.

Page 122: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

104 Grundkonzept einer SOA-basierten Integrationsplattform

Interdisziplinärer_ProzessDomänenübergreifende_Aufgabe 11..*Integrationsplattform 1..*1

Integrationsplattform_Funktion

11..*

Interdisziplinäre_Daten

1

1..*

1..* 1..*

Aktivität

*

*

Workflow

* *

Service

1

1..*

Domänenspezifische_Anwendung

1..*

1

Domänenspezifische_AnwendungsfunktionDomänenspezifische_Item

11..*

Nachricht

1

*

1..*1

1..*

*

1

1..*

Registry-Modul1

1

1

1

Mediation-Moduls

*

*

* *

*

*

1 1..*1

1

hatunterstützen

hat

organisieren

hat

nutzt

steuert

sendet/empfangt

sendet/empfangt

sendet/empfangt sendet/

empfangt

sendet/empfangt

sucht

suchtsucht

veröffentlicht

veröffentlichtnutzt

hat

hat

1..* 1..*

organisieren

bietet an

1

*

hat Sub-Prozess

Interdisziplinäres_Item

umfasst

Domänenspezifische_Daten

1

1..*

Domänenspezifischer_Prozess

Domänenspezifische_Aufgabe

1

1..*

hat

1

*

hat Sub-Prozess

1..*1

unterstützen

Abbildung 5-4: Metamodell für die serviceorientierte Architektur

5.2.2 Services

Innerhalb einer serviceorientierten Architektur präsentieren die Services die elementaren Bausteine. Ohne sie ist eine derartige Architektur nicht realisierbar. Im Kontext einer SOA lassen sich Services wie folgt definieren:

Services sind diskrete Software-Module, die über ihren Namen via eine selbstbeschrei-bende Schnittstelle wiederholt und mehrfach aufgerufen werden, typischerweise in ei-nem Anfrage-Antwort (Request-Respond)-Modus. Mittels des Einsatzes von Services wird eine Integration nicht mehr „hart codiert“ sondern flexibel nach dem Request-Respond-Prinzip vorgenommen [GART2008], [Glöc2007], [OASI2008].

Page 123: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundkonzept einer SOA-basierten Integrationsplattform 105

Trotz herrschender Einigkeit innerhalb der Fachwelt über die Aufgabe und die Definition ei-nes Service fehlt heute noch immer eine einheitliche Beschreibung von dessen Struktur. In diesem Abschnitt wird in Anlehnung an mehrere bereits existierende Servicestrukturbeschrei-bungen [KrBS2004], [DJMZ2005], [AENS2006], [Math2007], [OASI2008] eine für diese Arbeit geeignete Servicestruktur vorgestellt.

Damit ein Service überhaupt innerhalb einer serviceorientierten Architektur nützlich und zu-gänglich gemacht werden kann, muss er eine Reihe von Bedingungen erfüllen. So muss er aufrufbar sein, eine definierte Funktionalität aufweisen und Offenheit gegenüber externen Aufrufen besitzen [LSHK2006]. Ein SOA-fähiger Service muss mindestens über zwei Kom-ponenten Service-Schnittstelle und Service-Implementierungsmodul verfügen.

Service-Schnittstelle

Die Schnittstellen eines Service legen die Service-Funktionalitäten fest. Ferner bestimmen sie Form und Inhalt, unter denen sich die Services aus einer SOA-Landschaft heraus aufrufen lassen. Schnittstellen stellen die Ports der Services dar, die den Zugang zu den Service-Funktionen für die Service-Nutzer ermöglichen. Daher müssen sie für die anderen Nutzer öf-fentlich und in maschinenlesbarer Form beschrieben werden, d. h. sie müssen für alle poten-ziellen Service-Nutzer sichtbar, lesbar sowie verständlich sein. Um ein Interagieren der Servi-ce-Nutzer mit Service-Anbietern zu realisieren, liefern die Service-Schnittstellen formelle und neutrale Beschreibungen von Nachrichten, die ein Service senden oder empfangen kann. Diese Nachrichten enthalten u. a. Operationen sowie Input- und Output-Daten, die für eine automati-sche Interaktion zwischen Service-Nutzer und Service-Anbieter notwendig sind.

Service-Implementierungsmodul

Das Implementierungsmodul stellt das Kernelement eines Service dar, das für die Ausführung bzw. die Erfüllung der Dienste verantwortlich ist. Ein Serviceimplementierungsmodul besteht aus einer Business-Logikeinheit, die die logische Implementierung der Service-Funktionalitäten beinhaltet. Zu diesen zählen z. B. die dynamische Laufzeitbindung des Servi-ce, Anbindung von Applikationsfunktionen, Algorithmen für Anbindungsablauf von Applika-tionsfunktionen, Datenkonvertierung und -bereitstellung. Hierbei ist darauf zu achten, dass die technische Implementierung der Service-Funktionen nicht innerhalb des Service selbst, son-dern innerhalb der anzubindenden Anwendungen stattfindet.

Das Merkmal der losen Kopplung ist für SOA-basierte Interoperabilitätslösungen zentral, des-halb sollten die Services möglichst nur „für sich“ stehen. Das bedeutet, sie realisieren auf ihrer eigenen technischen Basis klar definierte Funktionalitäten und bieten diese im SOA-Kontext zum Aufruf an. Ihr technisches Innenleben ist vor den aufrufenden Instanzen verborgen und für diese tatsächlich auch uninteressant, denn alle Funktionalitäten, die extern genutzt werden können und sollen, sind schließlich über die äußeren Schnittstellen zugreifbar. Ebenso wenig

Page 124: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

106 Grundkonzept einer SOA-basierten Integrationsplattform

sind die technischen Eigenschaften der Service-Nutzer für die angesprochenen Services von Bedeutung, solange diese die Service-Schnittstellen korrekt aufrufen. [Math2007]

5.2.3 Nachrichten

Integrationsplattform, Workflows und Services interagieren und kommunizieren miteinander durch Senden und Empfangen von Nachrichten (Messages), um Dienstleistungen anzufordern bzw. anzubieten. Zur Realisierung einer SOA-basierten Interoperabilitätslösung nach dem Prinzip der losen Kopplung müssen Nachrichten die folgenden Merkmale aufweisen [Wenz2004]:

Deskriptiv: Nachrichten müssen selbstsprechend sein, damit ein Empfänger ohne weite-re Informationen über den Sender diese bearbeiten kann.

Verständlich: Nachrichten müssen von allen SOA-Beteiligten (Services, Workflows, Applikationen) verstanden werden. Dazu müssen die Nachrichten semantisch und syn-taktisch einheitlich beschrieben sein.

Statuslos: Die Services sollten sich aus verschiedenen Ablaufkontexten heraus mehr-fach und wiederholt aufrufen lassen. Deswegen sollten die Transport- und Nachrichten-protokolle keine Status transportieren und auch im aufgerufenen Service sollte ein sol-cher nicht gehalten werden.

Erweiterbar: Da Services und Applikationen einem ständigen Wandel unterliegen, müs-sen Nachrichten ohne großen Aufwand erweiterbar sein.

Zur Konzipierung von Nachrichten, die o. g. Merkmale aufweisen, kann das von W3C entwi-ckelte Nachrichtenmodell Message Oriented Model (MOM) verwendet werden. Mit diesem Modell wird in erster Linie der Aufbau einer Web Service-Nachricht definiert, dessen Bezie-hung zu einem Service zugestellt werden [DJMZ2005]. Das Message Oriented Model ist generisch und technologieneutral beschrieben, so dass seine Anwendung als Grundlage für die Nachrichtenmodellierung nicht nur auf die Web Service-Technologie beschränkt ist, sondern auch in Zusammenhang mit anderen Technologien verwendet werden kann.

Die Beschreibung der Struktur und der Inhalte des Message Oriented Model werden im An-hang 14.1 näher erläutert.

5.2.4 Workflow-Modellierung

Die Workflows bestehen aus aufeinanderfolgenden Serviceaufrufen über alle domänenspezifi-schen Applikationen. Dies erfordert einen entsprechenden Orchestrierungsmechanismus zur Steuerung und Synchronisation der Serviceaufrufe, um eine integrierte Prozessdurchführung und durchgängige Datenbearbeitung über alle Applikationen hinweg zu gewährleisten. Dem-zufolge muss der Orchestrierungsmechanismus eine standardisierte Workflow-Beschreibung ermöglichen, welche die Anbindung sowie die Ausführung der verschiedenen Services auf Gesamtprozessebene sicherstellt.

Page 125: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundkonzept einer SOA-basierten Integrationsplattform 107

Zu diesem Zweck kann der BPEL54-Standard (auch als WS-BPEL bekannt), der von mehreren namhaften IT-Herstellern (Microsoft, IBM, SAP, BEA, Oracle und Siebel) definiert wurde, gut dienlich sein. Mit BPEL lässt sich ein Prozess graphisch mittels eines BPEL-Editors be-schreiben und abbilden. Dies ist jedoch auch mit anderen Workflow-Modellierungstechniken möglich. Im Unterschied zu den anderen Techniken kann aus dem graphischen modellierten Geschäftsprozess direkt ein ausführbarer Code produziert werden. Im Abschnitt 9.2 wird näher auf die Anwendung des BPEL-Standards für die Modellierung von Workflows in dieser Arbeit eingegangen. Die BPEL-Basiselemente werden im Anhang 14.4 ausführlich beschrieben.

5.2.5 SOA-Interaktionsschema

Das grundlegende Interaktionsschema der entwickelten serviceorientierten Architektur ist in Abbildung 5-4 dargestellt und sein Ablauf lässt sich wie folgt verdeutlichen:

Mediation-Modul

Registry-Modul

IP

Workflow

Service

DA

ServiceServiceService

DA DA DA

Weitere Services

14

Legende:IP: IntegrationsplattformDA: Domänenspezifische Applikation

Veröffentlichen

15

1011

1213

16

12

3

4

5

6

7

8

9

Abbildung 5-5: SOA-Interaktionsschema

Die ausführbaren Workflows und Services publizieren ihre für dessen Nutzung notwen-digen organisatorischen und technischen Informationen als Metadaten im Registry-Modul.

Zur Durchführung einer Prozessaufgabe über alle domänenspezifische Anwendungen wird eine Integrationsplattform-Funktion verwendet (1).

54 BPEL: Business Process Execution Language (siehe Abschnitt 6.4.2)

Page 126: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

108 Grundkonzept einer SOA-basierten Integrationsplattform

Infolgedessen sendet die Integrationsplattform zur Laufzeit eine Workflow-Suchanfrage zum Mediation-Modul (2), um nach einem für die Ausführung der gestarteten Integrati-onsplattform-Funktion geeigneten Workflow zu suchen.

Das Mediation-Modul greift seinerseits auf die im Registry-Modul hinterlegten Metada-ten zu, um einen der Anfrage gemäß geeigneten Workflow zu finden (16).

Die Metadaten des vermittelten Workflows werden zu der Integrationsplattform zu-rückgemeldet (3).

Auf Basis der zurückgemeldeten Workflow-Metadaten generiert die Integrationsplatt-form eine Nachricht zum Aufrufen des ermittelten Workflows (4).

Der aufgerufene Workflow startet zur Laufzeit eine Suchaktion nach passenden Servi-ces (5), die Workflow-Schritte ausführen können. Hierzu werden die Vermittlungs-dienste des Mediation-Moduls und die im Registry-Modul abgelegten Service-Metadaten verwendet (16).

Die Metadaten der gefundenen Services werden zum Workflow zurückgesendet (6), um daraus eine oder mehrere Nachrichten zum Serviceaufruf zu erstellen (7).

Die für die Auftragsbearbeitung aufgerufenen Services stoßen die Bearbeitung der Ser-vice-Funktionen innerhalb der einzelnen domänenspezifischen Applikationen an (8). Sobald die domänenspezifischen Applikationen die Bearbeitung abgeschlossen haben, werden die Ergebnisse in Form von Nachrichten an die aufrufenden Services übermittelt (9).

Ein Service kann zusätzlich weitere Dienste anderer Services in Anspruch nehmen, um seine Aufgabe vollständig verrichten zu können. Wenn das der Fall ist, sendet er eine Suchanfrage zum Mediation-Modul zur Ermittlung geeigneter Services (10, 11). An-schließend können die ermittelten Services aufgerufen und deren Dienste genutzt wer-den (12, 13).

Die empfangenen Ergebnisse von den domänenspezifischen Applikationen und/oder von anderen Services werden durch die aufrufenden Services in standardisierter Form aufbereitet und für die weitere Bearbeitung in das Workflow zur Realisierung von komplexen, übergeordneten Diensten bzw. Funktionen bereitgestellt (14).

Die durch den Workflow orchestrierten und gebündelten Leistungen der einzelnen Ser-vices werden für die Integrationsplattform-Funktion bereitgestellt, um eine domänen-übergreifende Geschäftsprozessaufgabe durchführen zu können (15).

Page 127: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundkonzept einer SOA-basierten Integrationsplattform 109

5.3 Vorgehensmodell zur Realisierung einer SOA-basierten Inte-grationsplattform für die Entwicklung mechatronischer Pro-dukte

Für die Realisierung einer SOA-basierten Integrationsplattform für die Entwicklung mechat-ronischer Produkte auf Basis der im vorherigen Kapitel vorgestellten generischen service-orientierten Architektur wird in diesem Abschnitt ein Vorgehensmodell vorgestellt. Darüber hinaus soll dieses Vorgehensmodell als Leitfaden bzw. Orientierungshilfe für eine unterneh-mensspezifische Umsetzung des in dieser Arbeit entwickelten SOA-Ansatzes dienen, um den Interoperabilitätsgrad innerhalb einer heterogenen IT-Systemlandschaft zu erhöhen. Dieses Modell umfasst die vier Phasen Prozessanalyse, Konzipierung der mechatronischen Integrati-onsplattform, Definition der Workflows und Services und Implementierung der SOA-Elemente, die im Folgenden durchleuchtet werden:

Phase 1: Prozessanalyse

Eine serviceorientierte Architektur ist ein prozessgetriebener Lösungsansatz, daher kommt der Prozessanalyse eine wichtige Rolle bei der SOA-Umsetzung zu. Im Rahmen dieser Phase werden die Entwicklungsprozesse mechatronischer Produkte analysiert mit dem Ziel, die dabei durchzuführenden interdisziplinären Anwendungsfälle (Use Cases) zu identifizieren und zu modellieren. Basierend auf diesen Anwendungsfällen sind die weiteren Komponenten der ser-viceorientierten Architektur (Funktionalitäten und Datenmodell der Integrationsplattform, Workflows und Services) zu konzipieren.

Die Analyse des Entwicklungsprozesses mechatronischer Produkte wird in Form einer An-wendungsfallanalyse durchgeführt. Dabei werden auf Basis des V-Modells der VDI-Richtlinie 2206 „Entwicklungsmethodik für mechatronische Systeme“ alle möglichst interdisziplinären Use Cases, die während der Entwicklung mechatronischer Produkte vorkommen können, defi-niert. Für die Modellierung dieser Anwendungsfälle kann das UML Use Case-Diagramm an-gewendet werden, das vor allem das externe Verhalten der zu entwickelnden SOA-basierte Integrationsplattform aus Sicht der Nutzer zeigt.

Phase 2: Konzipierung der mechatronischen Integrationsplattform (mIP)

Ausgehend von den in der Phase 1 festgelegten und modellierten interdisziplinären Use Cases werden die notwendigen Funktionalitäten der Integrationsplattform definiert. Hierbei soll jeder vom Integrationsplattform-Anwender durchzuführenden Use Case durch eine oder mehrere Integrationsplattform-Funktionen ausgeführt werden. Des Weiteren sind die dabei zu bearbei-tenden interdisziplinären Daten- und Produktobjekte, deren Attribute sowie deren Abhängig-keiten in Form eines Datenmodells vollständig zu definieren und zu beschreiben. Dieses Da-tenmodell soll einerseits als Basis für das Management und die Steuerung der interdisziplinä-ren Produktdaten und Prozesse und andererseits als Integrationsmodell zur Verknüpfung der

Page 128: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

110 Grundkonzept einer SOA-basierten Integrationsplattform

verschiedenen domänenspezifischen Partialdatenmodelle auf Metaebene dienen. Das UML-Klassendiagramm hat sich in den letzten Jahren als Datendarstellungsform gut etabliert und kann daher im Rahmen der Modellierung des interdisziplinären Datenmodells eingesetzt wer-den.

Phase 3: Definition der Workflows und Services

Für die mIP-Funktionen, deren Realisierung mehrere Dienste domänenspezifischer PLM-Anwendungen (d. h. PDM-, EES- und SCM-System) erfordert, werden Workflows definiert. Die Workflows werden durch die Verwendung von Aktivitäten die Interaktion der verschiede-nen domänenspezifischen PLM-Anwendungsfunktionen miteinander abbilden. Hierfür wird das UML-Aktivitäten-Diagramm als Modellierungsdiagramm verwendet.

Zur Definition der Services wird ein Bottom-up-Vorgehen verfolgt. Dabei werden die Funk-tionalitäten der bereits vorhandenen domänenspezifischen PLM-Systeme analysiert und als Service analog zu der im Abschnitt 5.2.2 vorgestellten Struktur beschrieben und für die Work-flow-Aktivitäten und für die mIP-Funktionen, deren Ausführung nur einen einzelnen Dienst einer domänenspezifischen PLM-Anwendung benötigt, zur Verfügung gestellt.

Nach der Definition der Workflows und der Services wird die Integration bzw. die Anbindung der Services in die Workflows modelliert. Hierzu werden die Aktivitätsdiagramme der Work-flows in eine technisch ausführbare Beschreibungssprache übersetzt. Dabei werden die Work-flow-Aktivitäten mit weiteren zur Ausführung notwendigen technischen Details sowie Lauf-zeitaspekten zur Anbindung und Steuerung von Services erweitert.

Zur Modellierung von SOA-konformen ausführbaren Workflows kann die Standardsprache WS-BPEL Business Process Execution Language for Web Service verwendet werden. Zu die-sem Zweck werden heute kommerzielle SOA-Implementierungsplattformen mit BPEL-Grafikeditoren angeboten, mit denen Workflows BPEL-konform graphisch modelliert werden können, so dass anschließend daraus automatisch ein BPEL-Ausführungscode abgeleitet wer-den kann.

Phase 4: Implementierung der SOA-Elemente

Zwar kann eine serviceorientierte Architektur grundsätzlich mittels mehrere EAI-Technologien wie z. B. CORBA, EJB (s. Abschnitt 4.1.5) umgesetzt werden, jedoch ist es wichtig eine Implementierungstechnologie auszuwählen, die einerseits die Realisierung der im Abschnitt 4.1.7 erwähnten SOA-Grundprinzipien, d. h. Interoperabilität, Schnittstellenorientie-rung, Modularisierung und Geschäftsorientierung, erleichtern soll, andererseits innerhalb einer heterogenen IT-Landschaft jedoch auch leicht handhabbar sein soll. Die Web Service-Technologie kann aufgrund des hohen Standardisierungsgrads sowie der hohen zu genießen-den Akzeptanz seitens der IT-Hersteller und Anwender eine bedeutende Rolle bei der Umset-zung einer serviceorientierten Architektur spielen [Bock2007]. Diese Technologie verfügt über drei Standards, WSDL, SOAP, und UDDI, die eine wichtige Grundlage für die Imple-

Page 129: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Grundkonzept einer SOA-basierten Integrationsplattform 111

mentierung von Services, Mediation- und Registry-Modul sowie die für das Interagieren not-wendigen Nachrichten darstellen. Diese Standards lassen sich wie folgt zusammenfassen:

WSDL, die „Web Services Definition Language“, ist das Format, um Service-Schnittstellen zu beschreiben. Dabei werden im Wesentlichen drei verschiedene Aspek-te beschrieben: die Signatur (Name und Parameter), das sogenannte Binding (das Proto-koll zum Serviceaufruf) und die Adresse, mit der der Service konkret aufgerufen werden kann (auch location genannt) [Josu2008]. WSDL kann zur Definition und zur Imple-mentierung von Services verwendet werden.

Das SOAP (Simple Object Access-Protokoll) ermöglicht eine ausführbare Beschrei-bung von Message Oriented Model (MOM)-basierten Nachrichtenmodellen (vgl. Ab-schnitt 5.2.3). Hierzu stellt es eine mögliche, standardisierte Variante dar, wie Service Provider und Consumer miteinander kommunizieren könnten. SOAP ist nicht an ein be-stimmtes Transportmedium gebunden, sondern beschreibt lediglich eine standardisierte Nachrichtenstruktur [Schn2006]. Die SOAP-Struktur kann als Basis für die Beschrei-bung von ausführbaren Nachrichten zwischen den Komponenten einer serviceorientier-ten Architektur angewendet werden.

Das UDDI, „Universal Description and Discovery Interface“, ist die Spezifikation eines Web Service-Verzeichnisdienstes, welcher zur Registrierung sowie zum Auffinden von Diensten anhand der registrierten Eigenschaften der Services dient. UDDI kann zur Im-plementierung von Mediation- und Registry-Modul innerhalb der serviceorientierten Architektur benutzt werden.

Die Build-Integration und die Ausführung (auch Assemble, Deploy genannt) der verschiede-nen Komponenten (Integrationsplattform, Workflows, Services) der serviceorientierten Archi-tektur kann mittels einer kommerziellen SOA-Engine (z. B. ActiveBPEL Engine, IBM WebS-phere Process Server, Microsoft BizTalk Server oder Oracle BPEL Process Manager) realisiert werden. Diese Engines können auf Basis der Workflow-Beschreibungen – die mittels der WS-BPEL modelliert werden – die verschiedenen Services zusammenführen und orchestrieren, um die Funktionalitäten der Integrationsplattform zu realisieren (Abbildung 5-7).

Page 130: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

112 Grundkonzept einer SOA-basierten Integrationsplattform

Service.wsdl Service.wsdl

Service.wsdl

Service.wsdl

Service.wsdl

Service.wsdl

Service.wsdl

Service.wsdl

SOAP

Workflow_3.bpelWorkflow_1.bpel Workflow_n.bpel

. . . UDDI

Registry-/Mediation-Modul

Legende:

mIP

PDM EES SCM

Service.wsdl

Abbildung 5-6: Verwendung der Web Service-Technologie für die Implementierung der ser-viceorientierten Architektur

Zur Implementierung der mIP können kommerzielle PLM-Anwendungen als Basis verwendet werden, da sie bereits vorgefertigte Management-Funktionalitäten, wie z. B. Versionierungs-, Änderungsmanagement-, Freigabemanagement- und Workflow-Funktionen sowie ein umfas-sendes Meta-Datenmodell mit vorkonfigurierten Klassen-Templates, die an die Belange der Entwicklungsprozesse und –Daten mechatronischer Produkte angepasst werden können, be-reitstellen.

Die mittels dieses Vorgehensmodells zu definierenden bzw. zu entwickelnden interdisziplinä-ren Use Cases, mIP-Funktionen, mechatronischen Meta-Datenmodell und Elemente der servi-ceorientierten Architektur (d.h. Workflows, Services, Registry- und Mediation-Modul) ent-sprechen weitgehend der Standard-Abläufe und –Prozesse innerhalb der Entwicklung mechat-ronischer Produkte gemäß der VDI Richtlinie 2206. Daher können Sie als Basis zur Entwick-lung von unternehmensspezifischen SOA-basierten Integrationslösungen zur Ermöglichung von interdisziplinärer Entwicklung mechatronischer Produkte.

Page 131: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 113

6 Definition der interdisziplinären Use Cases für die mIP

Um die interdisziplinären Use Cases innerhalb der Entwicklung mechatronischer Systeme identifizieren zu können, wird die generische Entwicklungsmethodik für mechatronische Sys-teme (VDI 2206) analysiert und detailliert beschrieben. Aus dieser werden dann die für die Entwicklung mechatronischer Systeme durchzuführenden interdisziplinären Use Cases abge-leitet. Des Weiteren werden diese Use Cases anhand des mechatronischen Systems elektroni-sches Bremssystem beispielhaft beschrieben und veranschaulicht.

6.1 Entwurf eines mechatronischen Systems

Ziel ist die Festlegung eines domänenübergreifenden Lösungskon-zepts, das die wesentlichen physikalischen und logischen Wir-kungsweisen des zukünftigen Produktes beschreibt. Hierzu wird das Gesamtprodukt in Form eines Funktionsplans (Abbildung 6-1) (auch logische System-architektur genannt) in wesentliche (Sub-) Systeme und (Teil-)Funktionen zerlegt. Die logi-sche Systemarchitektur beschreibt abstrakte Lösungen nach dem Black-Box-Prinzip – bei dem gefragt wird, was das System leisten soll –, daher sollen technische Realisierungsentscheidun-gen in dieser Phase nicht vorgenommen oder unnötig eingeschränkt werden. Des Weiteren werden diesen Funktionen geeignete Wirkprinzipien bzw. Lösungselemente zugeordnet und die Funktionserfüllung wird im Systemzusammenhang durch Verwendung z. B. von Model-in-the-Loop-Simulationsumgebung (MiL) geprüft. Zur Strukturierung von komplexen mechat-ronischen Systemen und zur Erstellung der logischen Systemarchitektur ist die Verwendung von Methoden wie z. B. der im Abschnitt 2.4.1 und 2.4.2 vorgestellten Systemtechnik-Methodik bzw. der funktionsorientierten Entwicklungsvorgehensweise vor allem zur Beherr-schung und Überwindung der Komplexität solcher Systeme sehr wichtig.

Page 132: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

114 Definition der interdisziplinären Use Cases für die mIP

f3.1.1f3.1.4

f3.1.2

f3.1.3 f7.2.1 f7.2.4

f7.2.2 f7.2.3

f3.1

f3.3f3.2 f3.4 f7.1 f7.4

f7.2 f7.3

S1

S1.3

S1.1

S1.4

S1.2

f1f4

f2

f5f3 f6

f8

f7f9

f10f13

f11f12 f14

f16

f15f17

f18

Legende:S: (Sub-)Systemf: (Teil-)Funktion

Abbildung 6-1: Logische Systemarchitektur eines mechatronischen Produktes

Zum Systementwurf gehört auch die weitere Konkretisierung der logischen Systemarchitektur zu einer konkreten technischen Systemarchitektur. Dabei werden für die Durchführung der Systemfunktionalitäten sog. Regelkreise definiert und anschließend die einzelnen Systemfunk-tionen zu den Regelkreiselementen (Regler, Stellglied, Regelstrecker, Übertragungsglied und Messglied) zugeordnet. Des Weiteren wird in dieser Phase die Partitionierung des gesamten Systems durchgeführt, indem die Realisierungstechnologie der Regelkreiselemente festgelegt wird, d. h. es wird definiert, welches Regelkreiselement durch welche technischen Systeme (mechanisches System (Aktor), Informationsbearbeitungssystem oder Sensoren) realisiert werden soll (Abbildung 6-2). Dieser Vorgang kann mithilfe des im Abschnitt 2.4.3 präsentier-ten Partitionierungsleitfadens durchgeführt werden. Auf Basis der technischen Systemarchi-tektur bzw. des Regelkreises kann einerseits frühzeitig die technische Umsetzbarkeit des ge-samten Konzepts analysiert und beurteilt werden – beispielsweise die Durchführung von steuerungs- und regelungstechnischen Analysen, Echtzeitanalysen, die Analyse verteilter und vernetzter Systeme, Sicherheits- und Zuverlässigkeitsanalysen –, andererseits können ver-schiedene Realisierungsalternativen einander gegenübergestellt und bewertet werden [ScZu2004]. Hierzu können Model-in-the-loop-Simulationsumgebung und Rapid-Control-Prototyping-Tools (RCP) verwendet werden.

Schließlich sollen basierend auf den Ergebnissen des Systementwurfs Anwendungsszenarien für die spätere System-Integration und den System-Test erarbeitet werden.

Page 133: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 115

f1.4.2

f1.4.3f1.4.4

f1.4.1

f1.4.4

f9.4.2

f9.4.1

f9.4.3f9.4.4

logische Systemarchitektur

technische Systemarchitektur

Regler(Informationsbearbeitung)

Stellglied(Aktor)

Regelstrecke(mechanisches System)

Sensor

FunktionspartitionierungLegende:

Abbildung 6-2: Funktionspartitionierung zur Erstellung einer technischen Systemarchitektur eines mechatronischen Produktes

Im Rahmen der Entwurfsphase lassen sich zwei interdisziplinäre Use Cases identifizieren:

i. Erstellung einer logischen Systemarchitektur

Bei der Erstellung einer logischen Systemarchitektur handelt es sich vor allem um die Definition von logischen Systemen und logischen Funktionen sowie deren Beziehungen und Abhängigkeiten untereinander. Bei der Festlegung der Beziehungen zwischen den Elementen der logischen Systemarchitektur sind vor allem die Energie-, Stoff- und In-formationsflüsse zu definieren. An der Erstellung der logischen Systemarchitektur wer-den in der Regel alle an der Entwicklung des mechatronischen Systems beteiligten Berei-che mitwirken (Abbildung 6-3).

Page 134: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

116 Definition der interdisziplinären Use Cases für die mIP

Abbildung 6-3: Use Case „Erstellen einer logischen Systemarchitektur“

Beispiel: Logische Systemarchitektur eines elektronischen Bremssystems

Aus einer Gesamtsystemsicht besteht ein Fahrzeug in der Regel aus den vier logischen Haupt-systemen Antriebsstrang, Fahrwerk, Karosserie und Multimedia, die funktional voneinander abhängig sind und wiederum weitere logische Subsysteme beinhalten. Beispielsweise umfasst das Fahrwerksystem die logischen Subsysteme Räder, Radaufhängung, Federung, Stoßdämp-fer, Lenkung und die elektronische Bremse. Die Aufgabe eines elektronischen Bremssystems kann mittels mehrerer logischer Funktionen beschrieben werden, hier sind u. a. die folgenden Funktionen zu nennen [BOSC2004], [WaRe2006]: Fahrzeuggeschwindigkeit verringern, Fahrzeug zum Stillstand bringen, Fahrzeug im Stillstand halten, Unerwünschtes Beschleuni-gen bei einer Talfahrt verhindern, Stabilität und Lenkbarkeit bei allen Fahrbahnbeschaffen-heiten sicherstellen, Spur- und Richtungstreue bei Vollbremsung und Teilbremsung sicherstel-len, Fahrzeug bei Kurvenfahrt stabilisieren, Notbremssituationen erkennen und Bremsweg verkürzen, Abstand regeln und Im Bedarfsfall abbremsen.

Die o. g. Funktionalitäten eines Bremssystems lassen sich in weitere logische Teilfunktionen unterteilen. Beispielsweise wird die Stabilität eines Fahrzeugs bei einer Kurvenfahrt sicherge-stellt, indem die einzelnen Räder gezielt durch das aktive Eingreifen des Bremssystems ge-bremst werden und das Motorantriebsmoment durch das aktive Eingreifen des Motormanage-mentsystems reduziert wird. Daher muss die logische Funktion Fahrzeug bei Kurvenfahrt sta-bilisieren u. a. die folgenden Teilfunktionen erfüllen: Fahrzeuginstabilität erkennen, Aktuelle Fahrsituation erfassen, Sollverhalten des Fahrzeugs ermitteln, Optimale Bremskraft für die

Page 135: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 117

einzelnen Rädern ableiten, Optimales Motorantriebsmoment ableiten, Optimale Bremskraft umsetzen und Optimales Motorantriebsmoment umsetzen.

Ein Ausschnitt der logischen Systemarchitektur des elektronischen Bremssystems ist in der Abbildung 6-4 dargestellt.

Fahrzeug

Antriebsstrang

Fahrwerk

Karosserie

Multimedia

Räder

BremseFahrzeug bei Kurvenfahrt stabilisieren

Optimale Kraft ableiten

Optimale Bremskraft ableiten

(Sub-)System

(Teil-)Funktion

Legende:

Abbildung 6-4: Ausschnitt einer logischen Systemarchitektur eines Fahrzeugs nach [BOSC2004], [WARE2006]

ii. Erstellung einer technischen Systemarchitektur

Die Erstellung einer technischen Systemarchitektur umfasst zunächst die Definition der Regelkreiselemente zur Durchführung der logischen Systemfunktionalitäten sowie die dafür notwendigen domänenspezifischen technischen Systeme, d. h. mechanische Syste-me (Aktoren), E/E-Systeme und informationstechnische Systeme. Anschließend erfolgt die Partitionierung der logischen Systeme und Funktionen auf die technischen Systeme und die weitere Detaillierung der innerhalb der logischen Systemarchitektur definierten System- und Funktionsbeziehungen auf die technische Ebene (Abbildung 6-5).

Page 136: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

118 Definition der interdisziplinären Use Cases für die mIP

Abbildung 6-5: Use Case „Erstellen einer technischen Systemarchitektur“

Beispiel: Technische Systemarchitektur der logischen Funktion „Fahrzeug bei Kurven-fahrt stabilisieren“

Zur Realisierung der Funktion Fahrzeug bei Kurvenfahrt stabilisieren wird ein Regelkreis (Abbildung 6-6) mit den folgenden Elementen definiert:

Sensoren (Drehrate-, Querbeschleunigungs-, Lenkradwinkel-, Vordruck-, Drehzahlsen-soren): Die Sensoren dienen zur Erfassung der aktuellen Fahrzeugsituation, der Um-weltbedingungen sowie des Fahrerwunsches und zur Bestimmung der Reglerein-gangsgrößen (r, w und z). Die Sensoren sind verantwortlich für die Realisierung der lo-gischen Teilfunktionen Fahrzeuginstabilität erkennen und Aktuelle Fahrsituation erfas-sen.

Regler (E/E-Bremssteuerung): Die E/E-Bremssteuerung definiert auf Basis der durch die Sensoren erfassten Ist-Größen und der vom Motormanagementsystem gelieferten Drehzahl das Sollverhalten des Fahrzeuges, um die Fahrzeugstabilität sicherstellen zu können. Hierbei werden die Hilfsstellgrößen (yr) ermittelt und an die Stellglieder weiter gegeben. Der Regler ist verantwortlich für die Realisierung der logischen Teilfunktion Sollverhalten des Fahrzeugs ermitteln.

Page 137: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 119

Stellglieder (Bremshydraulik, Motorsteuerung): Die Stellglieder leiten aus den Hilfs-stellgrößen die notwendige Bremskraft für die einzelnen Räder und das notwendige Mo-torantriebsmoment ab, um die Fahrzeugstabilität wiederherstellen zu können. Die abge-leiteten Größen werden als Stellgrößen (y) an die Regelstrecke vermittelt. Die Stellglie-der Bremshydraulik und E/E-Motorsteuerung sind für die Umsetzung der logischen Funktionen Optimale Bremskraft für die einzelnen Räder ableiten bzw. Optimales Mo-torantriebsmoment ableiten verantwortlich.

Regelstrecke (Radbremsen, Motor): Die Regelstrecken sorgen dafür, dass die Stellgrö-ßen umgesetzt werden. Die Radbremsen und der Motor dienen u. a. dazu, die logischen Teilfunktionen Optimale Bremskraft umsetzen und Optimales Motorantriebsmoment umsetzen zu realisieren. Die Fahrzeugstabilität bei einer Kurvenfahrt ist als Ausgangs-größe (x) des Regelkreises zu betrachten.

Regler(E/E-Bremssteuerung)

Bremshydraulik

E/E-Motorsteuerung

Stellglieder Regelstrecke

Radbremsen

Motor

Übertragungsglied(Sensoren für Umweltgrößen)

w

e yr

y

y

x

r

-+

Führungsgröße(Fahrervorgabe)

Vordrucksensor (Bremse)

Lenkradwinkelsensor (Einschlag des Lenkrads)

Motormanagementsystem (Betätigung des Gaspedals)

Drehratesensoren

Querbeschleunigungssensoren

Drehzahlsensoren

Sensoren

z

Abbildung 6-6: Ausschnitt einer technischen Architektur der logischen Funktion „Fahrzeug bei Kurvenfahrt stabilisieren“ als Regelkreis nach [BOSC2004], [WARE2006]

Die Durchführung der in dieser Entwicklungsphase relevanten Use Cases, d. h. die Erstellung der logischen und technischen Systemarchitektur, benötigt keine Funktionalitäten von domä-nenspezifischen PLM-Anwendungen und kann vollständig innerhalb der mIP erfolgen.

Page 138: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

120 Definition der interdisziplinären Use Cases für die mIP

6.2 Domänenspezifischer Entwurf

Auf der Basis des gemeinsam entwickelten Lösungskonzeptes folgt die weitere Konkretisierung meist getrennt nach domänen-spezifischer Entwicklungsmethodik in den beteiligten Domänen. Dabei wird zunächst zwischen den mechanischen Systemen – darunter fallen auch hydrauli-sche, pneumatische Systeme – und den E/E-Systemen (eingebettete Software- und Hardware-systeme) unterschieden.

Da zwischen den eingebetteten Software- und Hardwaresystemen eine enge Verbindung bzw. Abhängigkeit besteht, soll zunächst ausgehend von der gesamten technischen Systemarchitek-tur eine E/E-Systemarchitektur abgeleitet werden. Dabei sollen die Funktionalitäten der E/E-Systeme weiter verfeinert und auf bestimmte eingebettete Software- und Hardware-Systeme partitioniert werden. Darauf basierend werden die Software-System- und die Hardware-Systemarchitektur für das Gesamtprodukt erstellt, welche als Basis für die Entwicklung und die Umsetzung der einzelnen Software- und Hardwarekomponenten dienen sollen.

Innerhalb der Entwicklung mechanischer Systeme wird die gesamte technische Architektur zu einer Mechanik-Systemarchitektur überführt mit dem Ziel, die zu realisierenden mechanischen Systemfunktionalitäten auf bestimmte mechanische Komponenten zu partitionieren. Auf Basis dieser Systemarchitektur werden die einzelnen mechanischen Komponenten realisiert.

Die erstellten technischen Architekturen sollen als Grundlage für die späteren Integrations- und Testaktivitäten der Komponenten auf gesamten Software-, Hardware-, E/E- und mechani-schen Systemebene dienen.

Die realisierten mechanischen, Hardware- und Software-Komponenten werden vor der Integ-ration zunächst mithilfe von Simulationstools, wie z. B. Hardware-in-the-Loop (HiL), Soft-ware-in-the-Loop (SiL), FEM, getestet, um die Erreichung des zu erwartenden Reifegrads sicherzustellen.

Im Rahmen dieser Entwicklungsphase werden hauptsächlich die folgenden interdisziplinären Use Cases durchgeführt:

iii. Erstellung einer E/E-Systemarchitektur

Hier werden die innerhalb der technischen Systemarchitektur definierten E/E-Systeme weiter konkretisiert. Dabei werden die Funktionalitäten des E/E-Systems weiter verfei-nert und dessen technologische Umsetzung festgelegt. Dies erfolgt, indem die Software- und die Hardwaresysteme, die für die Realisierung dieser Funktionalitäten erforderlich sind, sowie deren Beziehungen untereinander (d. h. den erforderlichen Informations- und Energieaustausch zwischen den Systemen) spezifiziert werden. Dieser Anwendungsfall wird vollständig in der mIP realisiert und benötigt keine weiteren Funktionalitäten von domänenspezifischen PLM-Anwendungen (Abbildung 6-7).

Page 139: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 121

Abbildung 6-7: Use Case „Erstellen einer E/E-Architektur“

Beispiel: Technische Systemarchitektur eines E/E-Bremssteuerungssystems

Das E/E-Bremssteuerungssystem dient dazu, das Sollverhalten eines Fahrzeugs zu ermitteln, um die Fahrstabilität gewährleisten zu können. Hierbei sollen die drei Freiheitsgrade des Fahr-zeugs in der Ebene, Längsgeschwindigkeit, Quergeschwindigkeit und Drehgeschwindigkeit um die Hochachse (Giergeschwindigkeit), innerhalb der beherrschbaren Grenzen gehalten wer-den. Um diese Aufgabe bewältigen zu können, soll das E/E-Bremssteuerungssystem die nach-stehenden aufgeführten technischen Funktionen realisieren [BOSC2004]:

Bestimmte Schätzgrößen beobachten: Diese Funktion ermittelt aus den durch unter-schiedliche Sensoren erfassten Messgrößen, wie z. B. Giergeschwindigkeit, Lenkrad-winkel, Querbeschleunigung, Reifenschlupfwerte etc., die notwendigen Größen zur Be-stimmung des Sollverhaltens des Fahrzeuges, wie z. B. Seitenkräfte am Rad, Schräg-laufwinkel, Schwimmwinkel, Fahrzeugquergeschwindigkeit etc.

Sollwert für Giergeschwindigkeit/Schwimmwinkel berechnen: Diese Funktion be-rechnet auf Basis der von Fahrzeugsensoren gelieferten Eingangsgrößen, wie z. B.

Page 140: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

122 Definition der interdisziplinären Use Cases für die mIP

Lenkradwinkel, Fahrzeuggeschwindigkeit, Gaspedalstellung, Bremskreisdruck etc., die Sollwerte für den Schwimmwinkel und die Giergeschwindigkeit, die für die Fahrzeug-stabilität notwendig sind.

Zustand für Giermoment regeln: Basierend auf der von der Funktion Bestimmte Schätzgrößen beobachten ermittelten Größen und weiterer zusätzlicher Sensorenwerte berechnet die Funktion Zustand für Giermoment regeln das Giermoment, das benötigt wird, um die Ist-Zustandsgröße den Sollzustandsgrößen des Fahrzeugs anzugleichen.

Sollwert für Bremssperrmoment/Reifenschlupf berechnen: Diese Funktion definiert die Sollwerte für das Bremssperrmoment und den Reifenschlupf. Hierbei dienen die von der Funktion Zustand für Giermoment regeln ermittelten Werte als Eingangsgrößen.

Bremsschlupf regeln: Aus den Signalen der vier Raddrehzahl-Sensoren und den defi-nierten Sollwerten für das Bremssperrmoment und den Reifenschlupf ermittelt die Funktion Bremsschlupf regeln die jeweiligen Radgeschwindigkeiten und -verzögerungen sowie die Schlupfwerte, um das Blockieren der Räder zu verhindern und die Lenkfähigkeit aufrechtzuerhalten.

Antriebsschlupf regeln: diese Funktion dient dazu, das Motorsollmoment im Antriebs-fall auf das auf die Fahrbahn übertragbare Antriebsmoment zu begrenzen, um damit ein Durchdrehen der Antriebsräder zu verhindern.

Motorschleppmoment regeln: diese Funktion optimiert den Schlupf an den Antriebs-rädern bei abrupter Gaswegnahme, um einen übermäßigen Bremsschlupf zu verhindern und somit starke Lastwechselreaktion bzw. Gieraktion insbesondere in einer Kurve zu verhindern.

Zur Umsetzung der oben erläuterten Funktionen wird das ESP-System (Elektronisches Stabilitäts-Programm) definiert, welches ein ESP-Software- und ein ESP-Hardware-system beinhaltet (Abbildung 6-8).

Page 141: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 123

Messgrößen

LenkradwinkelGiergeschwindigkeitQuerbeschleunigungRaddrehzahlBremskreisdruck

Radbremsen

Motor

Bestimmte Schätzgrößen beobachten

Sollwert für Giergeschwindigkeit/Schwimmwinkel berechnen

Zustand für Giermoment regeln

Sollwert für Bremssperrmoment/Reifenschlupf berechnen

Bremsschlupf regeln

Antriebsschlupf regeln

Motorschleppmoment regeln

ESP-System (inkl. HW- und SW-System)

Fahrzeug

Abbildung 6-8: Ausschnitt einer E/E-Architektur eines elektrischen Bremssystems nach [BOSC2004], [WARE2006]

iv. Erstellung einer Software-Systemarchitektur

Die definierten Softwaresysteme werden in mehrere Softwarefunktionen zerlegt, die in-nerhalb verschiedener Softwarekomponenten implementiert werden. Die Summe der ein-zelnen Softwarekomponente bildet die gesamte Software-Systemarchitektur eines me-chatronischen Systems. Die Softwarekomponenten werden aus der mIP heraus in das SCM-System erstellt, wo sie während ihres gesamten Entstehungsprozesses verwaltet und gesteuert werden. Anschließend werden diese Komponenten in der mIP den jeweili-gen Softwaresystemfunktionen zugeordnet (Abbildung 6-9).

Page 142: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

124 Definition der interdisziplinären Use Cases für die mIP

Abbildung 6-9: Use Case „Erstellen einer Softwarearchitektur“

Beispiel: Softwarearchitektur eines ESP-Systems

Die Implementierung der Funktionen des ESP-Systems findet in verschiedenen Softwarekom-ponenten statt (Abbildung 6-10):

Dynamische Stability Control (DSC): Innerhalb der DSC-Softwarekomponente wer-den die ESP-Softwarefunktionen Bestimmte Schätzgrößen beobachten, Sollwert für Giergeschwindigkeit/Schwimmwinkel berechnen, Zustand für Giermoment regeln und Sollwert für Bremssperrmoment/Reifenschlupf berechnen realisiert.

Antiblockiersystem (ABS): Die ESP-Softwarefunktion Bremsschlupf regeln wird durch die Softwarekomponente ABS umgesetzt.

Antriebsschlupfregelung (ASR): Die Softwarekomponente ASR ist verantwortlich für die Realisierung der ESP-Softwarefunktion Antriebsschlupf regeln.

Motorschleppmomentregelung (MSR): Mittels der Softwarekomponente MSR wird die ESP-Softwarefunktion Motorschleppmoment regeln realisiert.

Page 143: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 125

Beobachter bestimmt Schätzgrößen

Sollwertberechnung für Gier-geschwindigkeit/Schwimmwinkel

Zustandsregler für Giermoment

Sollwertberechnung für Brems-sperrmoment/Reifenschlupf

Softwarekomponente DSC

Bremsschlupfregler

Softwarekomponente ABS

Antriebsschlupfregler

Softwarekomponente ASR

Motorschleppmomentregler

Softwarekomponente MSR

ESP-Softwaresystem

Eingangsgröße Ausgangsgröße

Abbildung 6-10: Ausschnitt einer ESP-Software-Systemarchitektur nach [BOSC2004], [WA-

RE2006]

v. Erstellung einer Hardware-Systemarchitektur

Analog zur Erstellung einer Software-Systemarchitektur werden bei der Erstellung einer Hardware-Systemarchitektur die im Rahmen der technischen Systemarchitektur festge-legten Hardwaresysteme durch weitere Hardwaresystemfunktionen beschrieben, die in mehreren Hardwarekomponenten umgesetzt werden. Aus der mIP heraus werden die Hardwarekomponenten im EES-System definiert, wo sie zukünftig entlang ihres gesam-ten Entstehungsprozesses verwaltet und gesteuert werden. Im nächsten Schritt werden die Hardwaresystemfunktionen auf die erstellten Hardwarekomponenten in der mIP partitio-niert (Abbildung 6-11).

Page 144: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

126 Definition der interdisziplinären Use Cases für die mIP

Erstellen einer Hardwaresystemarchitektur

Elektrotechnik-Entwickler

HW-SystemfunktionHW-Komponente zuordnen

HW-Systemfunktiondefinieren

HW-Komponentedefinieren

Abbildung 6-11: Use Case „Erstellen einer Hardware-Systemarchitektur“

Beispiel: Hardwarearchitektur eines ESP-Systems

Die Softwarekomponenten des ESP-Softwaresystems DSC, ABS, ASR und MSR werden in vier verschiedene Hardwarekomponenten bzw. Mikrocontroller – DSC-, ABS-, ASR- und MSR-Mikrocontroller – eingebettet, die zusammen das gesamte ESP-Hardwaresystem darstel-len (Abbildung 6-12).

Mikrocontroller DSC

Mikrocontroller ABS

Mikrocontroller ASR

Mikrocontroller MSR

ESP-Hardwaresystem

Abbildung 6-12: Ausschnitt einer ESP-Hardware-Systemarchitektur nach [BOSC2004], [WA-

RE2006]

vi. Erstellung einer Mechanik-Systemarchitektur

Ausgehend von der technischen Systemarchitektur werden die mechanischen System-funktionen definiert und die zu deren Realisierung notwendigen mechanischen, hydrauli-

Page 145: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 127

schen und pneumatischen Komponenten festgelegt. Die Spezifikation der mechanischen Komponenten und deren Verknüpfung mit den umzusetzenden mechanischen System-funktionen erfolgen zunächst in der mIP und werden anschließend in das PDM-System weitergeleitet, wo sie zukünftig verwaltet und gesteuert werden.

Erstellen einer mechanischen Systemarchitektur

Mechanik-Entwicklermechanische

Systemfunktion mechanische Komponentezuordnen

mechanischeSystemfunktion definieren

mechanischeKomponente definieren

Abbildung 6-13: Use Case „Erstellen einer mechanischen Systemarchitektur“

Beispiel: Mechanische Systemarchitektur eines Bremssystems

Mittels der durch die Funktionen des ESP-Systems ermittelten Sollwerte werden die Aktoren der Bremse und des Motors wie folgt angesteuert:

Die DSC-Funktionen dienen dazu, das optimale Giermoment permanent zu bestimmen, um ein stabiles Fahrverhalten in bestimmten Fahrsituationen, z. B. in einer Kurvenfahrt, sicherzustellen. Mittels des ermittelten Giermoments werden die Bremshydraulikeinheit und das Motormanagement gesteuert, um einen aktiven, radselektiven Bremseingriff an allen vier Rädern durchzuführen und die Motorleistung optimal zu regeln. Somit wird das Fahrzeug immer auf einem sicheren und stabilen Kurs gehalten.

Die ABS-Funktionen ermitteln die jeweiligen Radgeschwindigkeiten und -verzögerung sowie die Schlupfwerte und damit wird an jedem Rad durch Bremsdruckmodulation in der Hydraulikeinheit der optimale Radschlupf eingestellt.

Die ASR-Funktionen sorgen dafür, dass das Motorsollmoment im Antriebsfall auf das auf die Fahrbahn übertragbare Antriebsmoment begrenzt wird, um damit ein Durchdre-hen der Antriebsräder zu verhindern. Dieses geschieht entweder durch Bremsen der an-getriebenen Räder oder durch Abbauen der überschüssigen Motorleistung. Die Reduzie-rung der Motorleistung wird durch die Steuerung der Motordrosselklappe, der Kraft-

Page 146: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

128 Definition der interdisziplinären Use Cases für die mIP

stoffeinspritzung und des Zündwinkels mittels des Motormanagementsystems vorge-nommen.

Die Steuerung des mechanischen Bremssystems durch die Funktionalitäten des ESP-Systems wird in der Abbildung 6-14 veranschaulicht. Die Komponenten (6; 7; 8; 9; 10 und 11) stellen zusammen das mechanische Bremssystem dar.

Abbildung 6-14: Steuerung der mechanischen Bremssystemkomponente durch das ESP-System [BOSC2004]

6.3 Systemintegration

Die Ergebnisse aus den einzelnen Domänen werden in der System-integrationsphase zu einem mechatronischen Gesamtsystem zu-sammengeführt. Anschließend wird das Gesamtsystem hinsich-tlich seiner Funktionalität untersucht und freigegeben. Hierzu werden die einzelnen abgesi-cherten technischen Komponenten (Mechanik, Hardware und Software) stufenweise zu einem funktionsfähigen Gesamtsystem zusammengeführt. Dieser Vorgang wird durch den sog. Re-leasemanagement-Prozess gesteuert.

Innerhalb des mechanischen Bereiches wird auf Basis der in der domänenspezifischen Ent-wurfsphase erstellten mechanischen Systemarchitektur die mechanische Produktkonfiguration erstellt. Diese soll als Instrument für die Integration der einzelnen mechanischen, hydrauli-schen und pneumatischen Komponenten zu einem Gesamtsystem sowie als Basis für den Test und die Freigabe des gesamten Systems aus mechanischer Sicht dienen.

Angesichts der starken Vernetzung und Abhängigkeit zwischen den E/E-Komponenten ist eine Kompatibilität zwischen diesen, d. h. Software- und Hardware-Komponenten, bitgenau not-wendig, um ein funktionsfähiges System realisieren zu können. Daher werden zunächst die einzelnen Software- und Hardwarekomponenten auf Basis der erstellten Software- bzw. Hardware-Systemarchitektur zum gesamten Software- bzw. Hardwaresystem integriert und

Page 147: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 129

validiert. Nach erfolgreicher Validierung werden aus den gesamten Software- und Hardware-systemen eine Software- und eine Hardware-Baseline definiert. Im nächsten Schritt werden die abgesicherten Software- und Hardware-Baselines basierend auf der E/E-Systemarchitektur zu einem gesamten E/E-System zusammengeführt und nach einer bestandenen Validierung wird das E/E-System als E/E-Baseline freigegeben.

Anschließend wird die abgesicherte mechanische Konfiguration und E/E-Baseline anhand der technischen Systemarchitektur zu einem mechatronischen Gesamtsystem integriert und vali-diert (Abbildung 6-15).

Freigegebene HW-Komponenten

Freigegebene SW-Komponenten

Freigegebene mechanischeKomponenten

ValidierungHW-Systeme

ValidierungSW-Systeme

Validierungmechanischer

Systeme Integration Integration Integration

HW-Baseline

SW-Baseline

Integration

ValidierungE/E-Systeme

Integration

E/E-Baseline

MechanischeSystemkonfiguration

MechatronischesGesamtsystem

Abbildung 6-15: Integration eines mechatronischen Systems

Die interdisziplinären Use Cases, die während der Systemintegrationsphase durchzuführen sind, lassen sich wie folgt beschreiben:

Page 148: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

130 Definition der interdisziplinären Use Cases für die mIP

vii. Erstellung einer Software-Baseline

Die freigegebenen Entwicklungsstände der einzelnen Softwarekomponenten werden ge-mäß einem vordefinierten Software-Release-Plan und auf Basis der Software-Systemarchitektur zu einem Gesamtsoftwaresystem zusammengeführt. Dabei werden die Softwarekomponenten den Funktionen der Software-Systemarchitektur zugeordnet und anschließend auf eine gesamte Softwaresystemebene funktional mittels SiL-Tools getes-tet. Nach erfolgreichem Test wird das Gesamtsoftwaresystem als Software-Baseline frei-gegeben (Abbildung 6-16).

Version einer SW-Komponente einerVersion einer SW-Systemfunktion

innerhalb der SW-Systemarchitekturzuordnen

Gesamtsoftwaresystem freigeben

Erstellen einer Software-Baseline

Software-Entwickler

Abbildung 6-16: Use Case „Erstellen einer Software-Baseline“

Beispiel: Software-Baseline eines ESP-Systems

Die Abbildung 6-17 präsentiert die ESP-Software-Baseline B1, welche sich aus der freigege-benen Versionen der Softwarekomponenten SW-DSC (Version V3), SW-ABS (Version V1), SW-ASR (Version V2) und SW-MSR (Version V1) zusammensetzt.

Page 149: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 131

Softwarekomponente DSC Zeit

Version V1 Version V2 Version V3(freigegeben)

Version V4

Softwarekomponente ABS Zeit

Version V1(freigegeben)

Version V2

Softwarekomponente ASR Zeit

Version V1 Version V2(freigegeben)

Version V3

Softwarekomponente MSR Zeit

Version V1(freigegeben)

Version V2

SW-Baseline B1

ESP-Software-Baseline B1 = { SW-DSC (V3); SW-ABS (V1); SW-ASR (V2); SW-MSR (V1)}

Abbildung 6-17: Software-Baseline eines ESP-Softwaresystems

viii. Erstellung einer Hardware-Baseline

Ein funktionsfähiges Gesamthardwaresystem wird auch als Hardware-Baseline gekenn-zeichnet. Hierbei werden funktionalabgesicherte Entwicklungsstände einzelner Hardwa-rekomponente entsprechend eines Hardware-Release-Plans und durch die Zuordnung zu den einzelnen Hardware-Systemfunktionen zu einem Gesamthardwaresystem integriert und mithilfe von HiL-Tools validiert.

Abbildung 6-18: Use Case „Erstellen einer Hardware-Baseline“

Page 150: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

132 Definition der interdisziplinären Use Cases für die mIP

Beispiel: Hardware-Baseline eines ESP-Systems

Die Hardware-Baseline B1, die in Abbildung 6-19 dargestellt ist, enthält die freigegebenen Entwicklungsstände Version V2, Version V1, Version V2 und Version V4 der Hardwarekom-ponenten HW-DSC, HW-ABS, HW-ASR bzw. HW-MSR.

ESP-Hardware-Baseline B1 = { HW-DSC (V2); HW-ABS (V1); HW-ASR (V2); HW-MSR (V4)}

Mikrocontroller DSC Zeit

Version V1 Version V2(freigegeben)

Version V3

Mikrocontroller ABS ZeitVersion V1

(freigegeben)Version V2

Mikrocontroller ASR Zeit

Version V1 Version V2(freigegeben)

Mikrocontroller MSR Zeit

Version V1 Version V2 Version V3 Version V4(freigegeben)

HW-Baseline B1

Abbildung 6-19: Hardware-Baseline eines ESP-Hardwaresystems

ix. Erstellung einer E/E-Baseline

Die in der Software- und Hardware-Baseline freigegebenen Software- und Hardwaresys-teme werden im nächsten Schritt den E/E-Systemfunktionen zugeteilt und darauf basie-rend wird ein gesamtes E/E-System gebildet. Nach einer erfolgreichen funktionalen Überprüfung kann das E/E-System als E/E-Baseline freigegeben werden. Der Use Case Erstellung einer E/E-Baseline wird komplett in der mIP ohne die Verwendung von Funk-tionen domänenspezifischer PLM-Anwendungen erfolgen (Abbildung 6-20).

Page 151: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 133

Abbildung 6-20: Use Case „Erstellen einer E/E-Baseline“

Beispiel: E/E-Baseline eines ESP-Systems

Die E/E-Baseline B1 des ESP-Systems setzt sich aus der Software-Baseline B1 und der Hard-ware-Baseline B1zusammen.

B1 = {SW-Baseline B1 + HW-Baseline B1}

= {SW-DSC (V3); SW-ABS (V1); SW-ASR (V2); SW-MSR (V1)} + {HW-DSC (V2); HW-ABS (V1); HW-ASR (V2); HW-MSR (V4)}

x. Erstellung einer mechanischen Konfiguration

Die in der domänenspezifischen Entwurfsphase entwickelten und freigegebenen Stände mechanischer Komponenten (Mechanik, Hydraulik und Pneumatik) werden durch die Zuordnung zu den mechanischen Systemfunktionen zu einem mechanischen Gesamtsys-tem integriert und es werden dessen Funktionalitäten überprüft. Ein funktionales abgesi-chertes mechanisches Gesamtsystem wird dann als mechanische Konfiguration freigege-ben (Abbildung A-21).

Page 152: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

134 Definition der interdisziplinären Use Cases für die mIP

Version einer mechanischen Komponenteeiner Version einer mechanischen

Systemfunktion innerhalb derMechanik-Systemarchitektur zuordnen

MechanikGesamtsystem freigeben

Erstellen einer mechanischen Konfiguration

Version einer hydraulischen Komponenteeiner Version einer mechanischen

Systemfunktion innerhalb derMechanik-Systemarchitektur zuordnen

Version einer pneumatischen Komponenteeiner Version einer mechanischen

Systemfunktion innerhalb derMechanik-Systemarchitektur zuordnen

Mechanik-Entwickler

Abbildung 6-21: Use Case „Erstellen einer mechanischen Konfiguration“

Beispiel: Mechanische Konfiguration eines Bremssystems

Die freigegebenen Entwicklungsstände mechanischer Komponenten werden zu einer mechani-schen Gesamtsystemkonfiguration K1 integriert und freigegeben (Abbildung 6-22).

K1 = {Hydroaggregat (V2); Radbremse (V3); Kraftstoffeinspritzung (V2); Zündwinkel (V1); Drosselklappe (V2)}.

Page 153: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 135

Mechanische Konfiguration K1 = { Hydroaggregat (V2); Radbremse (V3); Kraftstoffeinspritzung(V2); Zündwinkel (V4); Drosselklappe (V2)}

Drosselklappe Zeit

Version V1 Version V2(freigegeben)

Version V3

Hydroaggregat Zeit

Version V1 Version V2(freigegeben)

Zündwinkel ZeitVersion V1

(freigegeben)Version V2

Kraftstoffeinspritzung Zeit

Version V1 Version V2(freigegeben)

Version V3 Version V4

Radbremse Zeit

Version V1 Version V2 Version V3(freigegeben)

Mechanische Konfiguration K1

Abbildung 6-22: Mechanische Konfiguration eines Bremssystems

xi. Erstellung eines mechatronischen Gesamtsystems

Bei der Erstellung des mechatronischen Gesamtsystems handelt es sich um die Zusam-menführung der freigegebenen E/E-Baseline und der mechanischen Konfiguration auf Basis der technischen Systemarchitektur. Hierzu werden die E/E- und die mechanischen Systeme den Funktionen der technischen Systemarchitektur zugeordnet und auf einer Gesamtsystemebene validiert. Die Erstellung des mechatronischen Gesamtsystems wird vollständig in der mIP durchgeführt und daher sind keine weiteren Funktionen domänen-spezifischer PLM-Anwendungen notwendig.

Page 154: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

136 Definition der interdisziplinären Use Cases für die mIP

Version eines E/E-Systems einerVersion einer logischen Systemfunktion

innerhalb der logischenSystemarchitektur zuordnen

mechatronischesGesamtsystem freigeben

Erstellen eines mechatronischen Gesamtsystems

Version eines mechanischen Systemseiner Version einer logischen

Systemfunktion innerhalb der logischenSystemarchitektur zuordnen

Mechanik-Entwickler

Elektrotechnik-Entwickler

Software-Entwickler

Legende:

Abbildung 6-23: Use Case „Erstellen eines mechatronischen Gesamtsystems“

Beispiel: Mechatronisches Gesamtsystem eines elektronischen Bremssystems

Das mechatronische Gesamtsystem S1 des elektronischen Bremssystems setzt sich wie folgt zusammen:

S1 = K1 + B1

= {Hydroaggregat (V2); Radbremse (V3); Kraftstoffeinspritzung (V2); Zündwinkel (V1); Drosselklappe (V2)} + {SW-Baseline B1 + HW-Baseline B1}

= {Hydroaggregat (V2); Radbremse (V3); Kraftstoffeinspritzung (V2); Zündwinkel (V1); Drosselklappe (V2)} + {{SW-DSC (V3); SW-ABS (V1); SW-ASR (V2); SW-MSR (V1)} + {HW-DSC (V2); HW-ABS (V1); HW-ASR (V2); HW-MSR (V4)}}

6.4 Iterative Vorgehensweise

Die Entwicklungsaufgaben von mechatronischen Produkten sind aufgrund der Interdisziplinarität in der Regel sehr komplex und mit vielen Entwicklungsrisiken und -fehlern behaftet. Daher sind für die Entwicklung derartiger Systeme mehrere Iterationsschleifen notwendig, um einen Serien-reifegrad erreichen zu können. Diese Iterationsschleifen können auf vier verschiedenen Ebe-nen erfolgen (Abbildung 6-24):

Komponenten-Ebene (1): Die technischen Komponenten, d. h. Mechanik-, Hardware-

Page 155: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 137

und Software-Komponenten, werden entwickelt und weiter optimiert bis zur Erfüllung des zu erwartenden Reifegrads bzw. der geforderten Anforderungen. D. h. die Kompo-nententests sollen erfolgreich sein.

Domänenspezifische System-Ebene (2): Ziel der domänenspezifischen Subsystem-Ebene ist es, eine funktionsfähige mechanische Produktkonfiguration und E/E-Baseline zu entwickeln und abzusichern. Deshalb wird die Entwicklung der betroffenen techni-schen Komponenten mehrmals durchlaufen bis eine erfolgreiche Integration zu einer mechanischen Konfiguration bzw. E/E-Baseline entsprechend der geforderten Anforde-rungen erreicht wird.

System-Ebene (3): Auf der System-Ebene wird die funktional abgesicherte mechani-sche Konfiguration und E/E-Baseline zu einem mechatronischen Gesamtsystem integ-riert. Hierzu soll die Entwicklungsarbeit mehrmals iteriert werden, bis die Integration aller technischen Komponenten zu einem funktionsfähigen mechatronischen Gesamt-system entsprechend dem geforderten Reifegrad möglich ist.

Entstehungsprozess-Ebene (4): Das zu entwickelnde mechatronische Gesamtsystem wird in der Regel nicht innerhalb eines Makrozyklus auf Serienreifegrad gebracht. Ein marktreifes Gesamtsystem wird normalerweise inkrementell bzw. schrittweise entwi-ckelt. In einem ersten Zyklus werden beispielsweise das System funktional spezifiziert, erste Wirkprinzipien und/oder Lösungselemente ausgewählt und grob dimensioniert, im Systemkontext auf Konsistenz geprüft und exemplarisch realisiert. Das Ergebnis ist in der Regel ein Labormuster. Dies wird in einem zweiten Zyklus weiter konkretisiert (Feindimensionierung der Lösungselemente, Verhaltens- und Gestaltsimulation), um erste Funktionsmuster zu erstellen. Je nach Entwurfsaufgabe sind ggf. weitere Makro-zyklen erforderlich, um zum serienreifen Produkt zu gelangen. Die Anzahl der Makro-zyklen hängt von der spezifischen Entwicklungsaufgabe ab [VDI2206].

Page 156: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

138 Definition der interdisziplinären Use Cases für die mIP

K1 K2 Kn

B1 B2 Bn

S1 S2 Sn

Lastenheft

Projektstart

Labor-Muster

Funktions-Muster

Vorserien-Produkt …

Reifegrad Reifegrad

Komponenten-Ebene

DomänenspezifischeSystemebene

System-Ebene

1

2

3

4

Legende:K: Komponente

B: Baseline

S: System

1 Iteration auf Komponentenebene

2 Iteration auf domänenspezifische System-Ebene

3 Iteration auf System-Ebene

3 Iteration auf Entstehungsprozess-Ebene

Abbildung 6-24: Iterativer Entwicklungsprozess mechatronischer Produkte nach [VDI2206]

Diese iterative Entwicklungsvorgehensweise mechatronischer Systeme setzt adäquate Ma-nagementfunktionalitäten voraus, welche die Handhabung der interdisziplinären Datenobjekte domänen- bzw. anwendungsübergreifend ermöglichen. Diese Managementfunktionalitäten lassen sich anhand der folgenden Use Cases beschreiben:

xii. Versionierung eines interdisziplinären Systems

Systeme, d. h. Software-, Hardware, E/E-System, mechanisches und mechatroni-sches Gesamtsystem, beinhalten weitere domänenspezifische technische Komponen-ten. Eine Änderung an der funktionalen Eigenschaft oder/und die Ausgestaltung die-ser technischen Komponenten sowie deren Beziehungen und Abhängigkeiten führen

Page 157: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der interdisziplinären Use Cases für die mIP 139

automatisch zu einer Änderung an den übergeordneten interdisziplinären Systemen und Funktionen. Dies bedeutet, eine Versionierung einer domänenspezifischen tech-nischen Komponente in der jeweiligen domänenspezifischen PLM-Anwendung zwingt automatisch die Versionierung der darüberliegenden interdisziplinären Sys-teme und Funktionen in der mIP (Abbildung 6-25).

mechanischeKomponente versionieren

hydraulischeKomponente versionieren

pneumatischeKomponente versionieren

mechanischesGesamtsystem versionieren

Softwarekomponenteversionieren

Hardwarekomponenteversionieren

gesamtesSoftwaresystem versionieren

gesamtesHardwaresystem versionieren

gesamtesE/E-System versionieren

mechatronischesGesamtsystem versionieren

Versionierung eines interdisziplinären Systems

Elektrotechnik-Entwickler

Software-Entwickler

Mechanik-Entwickler

Abbildung 6-25: Use Case „Versionierung eines interdisziplinären Systems“

Beispiel: Versionierung eines elektronischen Bremssystems

Eine Änderung der Softwarekomponente MSR von der Version V1 auf die Version V2 führt automatisch zur Erstellung einer neuen ESP-Software-Baseline B2. Aufgrund dessen wird eine neue E/E-Baseline B2 des ESP-Systems erzeugt, die wiederum in einer neuen Version des mechatronischen Gesamtbremssystems S2 integriert wird.

xiii. Freigabe eines interdisziplinären Datenobjektes

Um ein interdisziplinäres System, d. h. Hardware-, Software-, E/E-, mechanisches oder mechatronisches System zu einer Baseline oder Konfiguration, freigeben zu können, müssen zunächst die untergeordneten domänenspezifischen technischen Komponenten freigegeben sein. Dies bedeutet, dass bei der Freigabe eines interdis-ziplinären Systems in der mIP der Freigabestatus der untergeordneten Komponenten in den jeweiligen domänenspezifischen PLM-Systemen überprüft werden muss.

Die Abbildung 6-26 zeigt den Use Case zur Freigabe eines E/E-Gesamtsystems. Die weiteren Anwendungsdiagramme zur Beschreibung der anderen interdisziplinären Systeme sind im Anhang 14.5 zu finden.

Page 158: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

140 Definition der interdisziplinären Use Cases für die mIP

Abbildung 6-26: Use Case „Freigabe eines E/E-Gesamtsystems“

Beispiel: Freigabe eines elektronischen Bremssystems

Die Freigabe des elektronischen Gesamtbremssystems bedingt zunächst die Freigabe der un-tergeordneten mechanischen Bremssystemkonfiguration und der E/E-Baseline sowie der dazu gehörenden HW-, SW-Baseline und der SW-, HW- und mechanischen Komponenten.

Page 159: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Konzipierung der mIP 141

7 Konzipierung der mIP

Basierend auf den im vorherigen Kapitel (Definition der interdisziplinären Use Cases für mIP) definierten Use Cases zur Entwicklung mechatronischer Systeme werden in diesem Kapitel die Funktionalitäten einer mechatronischen Integrationsplattform und das zugrundeliegende Datenmodell vorgestellt.

7.1 Funktionalitäten der mIP

Zur Ermöglichung der Use Cases für die Entwicklung mechat-ronischer Produkte sind vor allem IT-Unterstützungsfunktionen, die die Durchführung von interdis-ziplinären Prozessen bzw. Prozessaufgaben ermöglichen, von großer Bedeutung. Mithilfe de-rartiger Funktionen soll hauptsächlich die Durchgängigkeit bei der Organisation und Steue-rung der interdisziplinären Produktdaten und Prozesse über alle Domänen hinweg gewährleis-tet werden. Hierzu sollen die Funktionen der mIP die Zusammenarbeit der verschiedenen hete-rogenen domänenspezifischen PLM-Anwendungen steuern, um eine synergetische Integration der drei Domänen (Mechanik, Elektrotechnik und Softwaretechnik) auf mechatronischer Ge-samtsystemebene zu unterstützen.

Die Funktionalitäten der mIP lassen sich bezogen auf die Use Cases wie folgt erläutern:

Funktionalitäten zur Erstellung einer logischen Systemarchitektur

Die mIP-Funktionalitäten zur Erstellung einer logischen Systemarchitektur umfassen insbe-sondere Funktionen, die die Definition der Elemente der logischen Systemarchitektur sowie die Abbildung von deren Beziehungen und Abhängigkeiten zueinander ermöglichen. Zu den Elementen der logischen Systemarchitektur gehören vor allem (Sub-)Systeme und logische (Teil-)Funktionen, die zueinander Relationen in Form von Energie-, Stoff- oder Informations-flüssen haben.

Funktionalitäten zur Erstellung einer technischen Systemarchitektur

Die mIP-Funktionen zur Erstellung von technischen Systemarchitekturen dienen zunächst da-zu, mechanische, E/E-Systeme und Sensoren zu definieren sowie deren Beziehungen abzubil-den. Diese Systeme stellen im Wesentlichen die Kernelemente einer technischen Architektur dar. Des Weiteren sind mithilfe dieser Funktionen die Partitionierung der logischen Funktio-nen auf die jeweiligen Elemente der technischen Systemarchitektur, d. h. mechanische, E/E-

Page 160: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

142 Konzipierung der mIP

Systeme bzw. Sensoren, die für ihre Realisierung verantwortlich sind, zu ermöglichen (dieser Vorgang wird auch Funktions-Mapping genannt).

Funktionalitäten zur Erstellung einer E/E-Systemarchitektur

Die mIP-Funktionalitäten zur Erstellung einer E/E-Systemarchitektur sind hauptsächlich Funktionen für die Definition von E/E-Systemfunktionen, Software- und Hardwaresystemen, die zusammen eine E/E-Systemarchitektur bilden. Eine weitere Aufgabe dieser Funktionen besteht darin, die Partitionierung der E/E-Systemfunktionen auf die jeweiligen Software- bzw. Hardwaresysteme, die für deren Umsetzung erforderlich sind, zu unterstützen.

Funktionalitäten zur Erstellung einer Software-Systemarchitektur

Mithilfe dieser mIP-Funktionen werden die Softwaresystemfunktionen festgelegt und die dazu notwendigen Softwarekomponenten aus der mIP heraus im SCM-System spezifiziert. An-schließend wird die Partitionierung der Softwaresystemfunktionen auf die entsprechenden Softwarekomponenten durchgeführt.

Funktionalitäten zur Erstellung einer Hardware-Systemarchitektur

Die von einem Hardwaresystem zu erfüllenden Funktionen sowie die dafür erforderlichen Hardwarekomponenten werden mittels dieser mIP-Funktionalitäten definiert und ihre Zuord-nung zueinander (Funktionen – Komponenten) wird abgebildet. Die Definition der Hardware-komponenten wird aus der mIP heraus im EES-System durchgeführt.

Funktionalitäten zur Erstellung einer mechanischen Systemarchitektur

Die Funktionen und die Komponenten (d. h. mechanische, hydraulische bzw. pneumatische Komponenten) eines mechanischen Systems sowie deren Mapping (Funktion – Komponenten) werden mithilfe dieser mIP-Funktionalitäten festgelegt. Das Erzeugen von mechanischen Komponenten wird aus der mIP heraus im PDM-System erfolgen.

Funktionalitäten zur Erstellung einer Software-Baseline

Die mIP-Funktionalitäten zur Erstellung einer Software-Baseline unterstützen die Zusammen-führung von einzelnen Softwarekomponenten zu einem Gesamtsoftwaresystem, indem sie die Zuordnung bestimmter Stände von Softwarekomponenten aus dem SCM-System zu Software-systemfunktionen in mIP abbildet. Diese mIP-Funktionalitäten ermöglichen auch die Freigabe eines funktionsfähigen Gesamtsoftwaresystems zu einer Software-Baseline.

Funktionalitäten zur Erstellung einer Hardware-Baseline

Diese mIP-Funktionalitäten dienen dazu, verschiedene Entwicklungsversionen von Hardware-komponenten aus dem EES-System zu einem funktionsfähigen Gesamthardwaresystem auf Basis der Funktionen der Hardware-Systemarchitektur zu integrieren und als Hardware-Baseline in mIP freizugeben.

Page 161: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Konzipierung der mIP 143

Funktionalitäten zur Erstellung einer E/E-Baseline

Die zu einem E/E-System gehörenden Software- und Hardwaresysteme werden basierend auf der E/E-Systemarchitektur mittels dieser mIP-Funktionalitäten zusammen integriert, indem die freigegebenen Entwicklungsstände der Software- und Hardwaresysteme durch das Mapping auf die jeweiligen E/E-Systemfunktionen zu einem funktionsfähigen E/E-Gesamtsystem zu-sammengeführt und als E/E-Baseline freigegeben werden.

Funktionalitäten zur Erstellung einer mechanischen Konfiguration

Mit Unterstützung dieser mIP-Funktionalitäten werden Entwicklungsversionen mechanischer, hydraulischer und pneumatischer Komponenten aus dem PDM-System auf die mechanischen Systemfunktionen gemappt und daraus ein funktionsfähiges mechanisches Gesamtsystem ge-bildet und als mechanische Konfiguration in mIP freigegeben.

Funktionalitäten zur Erstellung eines mechatronischen Gesamtsystems

Zur Erstellung eines mechatronischen Gesamtsystems werden die Inhalte der E/E-Baseline und der mechanischen Konfiguration auf Basis der technischen Systemarchitektur zu einem funktionsfähigen mechatronischen Gesamtsystem zusammengeführt und freigegeben. Dies geschieht mit Unterstützung dieser mIP-Funktionalitäten.

Funktionalitäten zur Versionierung eines Systems

Durch diese mIP-Funktionalitäten werden die Versionsnummer eines Systems (d. h. Software-, Hardware-, E/E-, mechanisches und mechatronisches Gesamtsystem) im Falle einer Ände-rung einer darunter liegenden technischen Komponente bzw. eines darunter liegenden Teilsys-tems automatisch hoch gezählt und somit funktionale sowie nicht funktionale Abhängigkeiten zwischen den Bestandteilen eines Produkts bei eine Änderung automatisch berücksichtigt.

Die Implementierung der mIP-Funktionen wird je nach Interdisziplinarität und Komplexität nach drei unterschiedlichen Arten erfolgen:

Als eigene mIP-Funktion: Funktionen, die keine weiteren Funktionen und Daten von den domänenspezifischen PLM-Anwendungen (d. h. PDM-, EES- und SCM-System) benötigen, werden vollständig als eigene mIP-Funktionen implementiert.

Als Service: Funktionen, die die Dienste einer Funktion und die Daten einer domänen-spezifischen PLM-Anwendung benötigen, werden als Services implementiert.

Als Workflows: Funktionen, die mehrere Funktionen von einer oder mehreren domä-nenspezifischen PLM-Anwendungen benötigen, werden als Workflows implementiert.

Ein Überblick über die einzelnen Funktionen der mIP wird in der nächsten Tabelle 7-1 aufge-führt.

Page 162: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

144 Konzipierung der mIP

Use Case Funktionen der Integrationsplattform Implementiert als Er

stel

lung

ein

er

logi

sche

n Sy

s-te

mar

chite

ktur

F_Create_System Eigene mIP-Funktion

F_Create_Logic_Function Eigene mIP-Funktion

F_Create_System_System_Relation Eigene mIP-Funktion

F_Create_Logic_Function_Logic_Function_Relation Eigene mIP-Funktion

Erst

ell-u

ng e

iner

tech

ni-s

chen

Sys

tem

arch

itekt

ur F_Create_Mechanics_System Eigene mIP-Funktion

F_Create_E/E_System Eigene mIP-Funktion

F_Create_Sensor Eigene mIP-Funktion

F_Allocate_Logic_Function_to_Mechanics _System

Eigene mIP-Funktion

F_Allocate_Logic_Function_to_E/E_System Eigene mIP-Funktion

F_Allocate_Logic_Function_to_Sensor Eigene mIP-Funktion

F_Create_Mechanics_System_Mechanics_System_Relation

Eigene mIP-Funktion

F_Create_E/E_System_E/E_System_Relation Eigene mIP-Funktion

F_Create_Senor_Sensor_Relation Eigene mIP-Funktion

F_Create_Mechanics_System_E/E-System_Relation

Eigene mIP-Funktion

F_Create_E/E_System_Sensor_Relation Eigene mIP-Funktion

Erst

ellu

ng e

iner

E/E

-Sy

stem

arch

itekt

ur

F_Create_E/E_System_Function Eigene mIP-Funktion

F_Create_SW_System Eigene mIP-Funktion

F_Create_HW_System Eigene mIP-Funktion

F_Allocate_E/E_System_Function_to_SW_System

Eigene mIP-Funktion

F_Allocate_E/E_System_Function_to_HW_System

Eigene mIP-Funktion

F_Create_SW_System_SW_System_Relation Eigene mIP-Funktion

F_Create_HW_System_HW_System_Relation Eigene mIP-Funktion

F_Create_SW_System_HW_System_Relation Eigene mIP-Funktion

Erst

ellu

ng

eine

r Sof

t-w

are-

Syst

em-

arch

itekt

ur F_Create_SW_System_Function Eigene mIP-Funktion

F_Create_SW_Component Service F_Allocate_SW_System_Function_to_SW_Component

Eigene mIP-Funktion

Erst

ellu

ng

eine

r H

ardw

are-

Syst

em-

arch

itekt

ur F_Create_HW_System_Function Eigene mIP-Funktion

F_Create_HW_Component Service F_Allocate_HW_System_Function_to_HW_Component

Eigene mIP-Funktion

Page 163: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Konzipierung der mIP 145

Erst

ellu

ng

eine

r Mec

ha-

nik-

Syst

emar

chi-

tekt

ur

F_Create_Mechanics_System_Function Eigene mIP-Funktion

F_Create_Mechanics_Component Service

F_Allocate_Mechanics_System_Function_to_Mechanics_Component

Eigene mIP-Funktion

Erst

el-

lung

ei-

ner S

oft-

war

e-B

asel

ine F_Allocate_SW_Component_Version_to_SW_S

ystem_Function_Version Service

F_Release_SW_System Workflow

Erst

el-

lung

ei

ner

Har

d-w

are-

Bas

elin

e F_Allocate_HW_Component_Version_to_HW_System_Function_Version

Service

F_Release_HW_System Workflow

Erst

ellu

ng

eine

r E/E

-B

asel

ine

F_Allocate_SW_System_Version_to_E/E_System_Function_Version

Eigene mIP-Funktion

F_Allocate_HW_System_Version_to_E/E_System_Function_Version

Eigene mIP-Funktion

F_Release_E/E_System Workflow

Erst

ellu

ng

eine

r me-

chan

i-sc

hen

Kon

figu-

ratio

n F_Allocate_Mechanics_Component_Version_to_Mechanics_System_Function_version

Service

F_Release_Mechanics_System Workflow

Erst

ellu

ng

eine

s me-

chat

roni

-sc

hen

Ge-

sam

tsys

tem

s F_Allocate_E/E_System_Version_to_Logic_Function_Version

Eigene mIP-Funktion

F_Allocate_Mechanics_Version_to_Logic_Function_Version

Eigene mIP-Funktion

F_Release_Mechatronics_System Workflow

Ver

sion

ieru

ng

eine

s Sys

tem

s F_Version_SW_System Workflow

F_Version_HW_System Workflow

F_Version_E/E_System Workflow

F_Version_Mechanics_System Workflow

F_Version_Mechatronics_System Workflow

Tabelle 7-1: Funktionen der mechatronischen Integrationsplattform

Eine detaillierte Beschreibung dieser Funktionen ist im Anhang 14.2 zu finden.

7.2 Mechatronisches Meta-Datenmodell der mIP

Das Kernelement der mIP stellt das mechatronische Meta-Datenmodell dar, welches eine interdisziplinäre Beschreibung und Strukturierung mechatronischer Systeme über alle Domänen hinweg ermöglicht. Damit bietet es eine Unterstützung bei der Durchführung von interdisziplinären Entwicklungsprozes-sen bzw. -aufgaben und insbesondere der Erstellung der in Kapitel 6 definierten Use Cases an.

Page 164: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

146 Konzipierung der mIP

Die Grundstruktur dieses Datenmodells ergibt sich aus der Abstraktion der verschiedenen do-mänenspezifischen Partialdatenmodelle (Mechanik, Elektrotechnik und Informationstechnik) und präsentiert daher eine Grundlage für deren Verknüpfungen auf interdisziplinärer Gesamt-produktebene. Das mechatronische Datenmodell wurde als Klassendiagramm in UML entwor-fen und wird in Abbildung 7-1 schematisch abgebildet.

Die logische Systemarchitektur wird mithilfe der Klassen System und Function erstellt und beschrieben, indem ein mechatronisches Gesamtprodukt in (Sub-)Systeme bzw. in logische (Teil-)Funktionen aufteilen und deren Abhängigkeiten abbilden. Zur Abbildung von mechani-schen Systemen, E/E-Systemen und Sensoren, die die Hauptelemente der technischen System-architektur darstellen, sind die Klassen Mechanics_System, E/E_System, Actuaror und Sen-sor vorgesehen. Durch den Assoziationstyp implemented_in zwischen der Klasse Function und den Klassen Mechanical_System, E/E_System und Sensor wird die Partitionierung der logischen Funktionen auf die jeweiligen technischen Systeme abgebildet. Eine weitere Detail-lierung eines E/E-Systems geschieht mittels der Verwendung der Klassen SW_System und HW_System, die die Gesamtsoftware- und Gesamthardwaresysteme die zu einem E/E-System gehören, definieren. Zur Abbildung der Softwarekomponenten eines Gesamtsoftwaresystems sind die Klassen Application_SW und Platform_SW vorgesehen, welche die Anwendungs-softwarekomponenten zur Steuerung und Regelung des mechatronischen Systems und die Plattformsoftwarekomponenten (z. B. Bus-Treiber, Netzwerkmanagement, Flash-Treiber, Diagnoseprotokoll) definieren. Die Bestandteile eines Gesamthardwaresystems, d. h. die Mik-rocontroller und die Hardwaregehäuse, werden mithilfe der Klassen Microcontroller und HW_Body dargestellt. Durch die Klasse Mechanics_Component werden die mechanischen, hydraulischen und pneumatischen Komponenten eines mechanischen Gesamtsystems abgebil-det. Die Klassen Application_SW, Platform_SW, Microcontroller, HW_Body und Mecha-nics_Component sind keine direkten Klassen des mIP-Datenmodells und gehören im Grunde zu den Partialdatenmodellen der verschiedenen domänenspezifischen PLM-Anwendungen (d. h. PDM-, EES- und SCM-System). Die Bereitstellung bzw. die Verknüpfung dieser Klas-sen innerhalb des mIP-Datenmodells ermöglicht die Definition technischer Komponenten in den domänenspezifischen PLM-Anwendungen aus der mIP heraus und damit, dass eine voll-ständige und umfassende Betrachtung und Beschreibung aller mechatronischen Produktaspek-te schon in frühen Entwicklungsphase sichergestellt wird. Über die Aggregationsbeziehungen has zwischen den Klassen Application_SW, Platform_SW, Microcontroller, HW_Body und Mechanics_Component und den Klassen SW_System, HW_System und Mechanics_System werden einerseits die Verknüpfung sowie die Synchronisation der domänenspezifischen Parti-aldatenmodelle auf interdisziplinäre, mechatronische Produktebene ermöglicht und anderer-seits die domänenspezifischen Informationen, die für die Durchführung interdisziplinärer Entwicklungsprozesse und -aufgaben erforderlich und relevant sind, auf domänenübergreifen-der Ebene bereitgestellt und synchronisiert. Damit wird ein integrierter und durchgängiger

Page 165: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Konzipierung der mIP 147

Datenfluss über alle mechatronischen Domänen und entlang des gesamten Entwicklungspro-zesses gewährleistet.

Der Assoziationstyp depend_on dient dazu, die Beziehungen und die Abhängigkeiten zwi-schen den verschiedenen Elementen eines mechatronischen Systems zu definieren und darauf basierend die verschiedenen Systeme und Systemarchitekturen, d. h. logische, technische, me-chanische, E/E-, Software- und Hardware-System-Architektur, abzubilden.

Die Klassen SW_Baseline, HW_Baseline und Mechanical_Configuration ermöglichen die Bildung von Software-Baseline, Hardware-Baseline und mechanischer Konfiguration zur In-tegration von Entwicklungsständen mehrerer Software-, Hardware- bzw. mechanischen Kom-ponenten auf eine Gesamtsystemebene. Eine Software-Baseline und Hardware-Baseline kön-nen zu einer E/E-Baseline durch die Verwendung der Klasse E/E_Baseline zusammengeführt werden. Die Klasse Whole_System_Configuration beschreibt eine gesamte Konfiguration eines mechatronischen Systems, die sich aus einer E/E-Baseline und einer mechanischen Kon-figuration zusammensetzt.

Eine detaillierte Darstellung des mechatronischen Meta-Datenmodells ist im Anhang 14.3 zu finden.

Mechanics_Component

System

Function

Sensor E/E_System Mechanics_System

Platform_SWApplication_SW Microcontroller HW_Body

HW_SystemSW_System SW_Baseline HW_Baseline

E/E_Baseline

Mechanical_Configuration

Whole_System_Configuration

Aggregation

AllokationFunktionale AbhängigkeitGehört zu

Actuator

Abbildung 7-1: Mechatronisches Meta-Datenmodell

Page 166: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

148 Definition der SOA-Elemente für die mIP

8 Definition der SOA-Elemente für die mIP

8.1 Definition der Workflows

Um die domänenspezifischen Entwicklungsprozesse synchro-nisieren zu können und ihre Kooperation zu ermöglichen, sind domänenübergreifende Synchronisationsmechanismen auf ei-ner interdisziplinäre Produkt- und Prozessebene erforderlich. Zu diesen Mechanismen gehören vor allem das domänenübergreifende Versionierungs- bzw. Änderungsmanagement und das domänenübergreifende Freigabemanagement, welche für die Steuerung und die Koordinierung der verschiedenen parallel laufenden domänenspezifischen Entwicklungstätigkeiten von gro-ßer Bedeutung sind.

Die Realisierung dieser domänenübergreifenden Synchronisationsmechanismen erfordert das Interagieren mehrerer Funktionen der verschiedenen domänenspezifischen PLM-Anwendungen, d. h. PDM-, EES- und SCM-System. Um die Daten- sowie die Prozessdurch-gängigkeit über alle PLM-Anwendungen hinweg gewährleisten zu können, ist eine Steuerung bzw. eine Orchestrierung dieses Interagierens der PLM-Anwendungsfunktionen notwendig. Dies kann mittels Workflows geschehen, indem sie die heterogenen PLM-Systeme funktional sowie prozessual integrieren und deren gemeinsame Funktionsergebnisse als Input für die mIP-Funktionen bereitstellen, ohne dass die beteiligten einzelnen IT-Systeme detailliertes Im-plementierungswissen übereinander haben zu müssen.

Zur Realisierung eines domänenübergreifenden Freigabe- und Versionierungs- bzw. Ände-rungsmanagement werden die folgenden Workflows definiert:

W_Release_SW_System

W_Release_HW_System

W_Release_E/E_System

W_Release_Mechanics_System

W_Release_Mechatronics_System

W_Version_SW_System

W_Version_HW_System

Page 167: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der SOA-Elemente für die mIP 149

W_Version_E/E_System

W_Version_Mechanics_System

W_Version_Mechatronics_System

Die Workflows werden in zwei verschiedenen Klassen W_Release und W_Version (Tabelle 8-1) unterteilt, um ihre Organisation sowie ihre Suche innerhalb der serviceorientierten Archi-tektur zu erleichtern (s. Abschnitt 8.3).

Workflow-Klassen Workflows

W_Release

• W_Release_SW_System

• W_Release_HW_System

• W_Release_E/E_System

• W_Release_Mechanics_System

• W_Release_Mechatronics_System

W_Version

• W_Version_SW_System

• W_Version_HW_System

• W_Version_E/E_System

• W_Version_Mechanics_System

• W_Version_Mechatronics_System

Tabelle 8-1: Klassifizierung der mIP-Workflows

Die definierten Workflows lassen sich wie folgt beschreiben:

W_Release

Durch die Workflows, die zur Klasse W_Release gehören, werden die Freigabestatus aller technischen Komponenten eines Systems (d. h. Software-, Hardware-, E/E-, mechanisches und mechatronisches System) ermittelt und ausgewertet. Erst nach erfolgter Freigabe aller techni-schen Komponenten – in der jeweiligen domänenspezifischen PLM-Anwendung, in der sie verwaltet werden – werden die übergeordneten Systeme in der mIP freigegeben. Diese Work-flows werden im Rahmen der Ausführung der mIP-Funktionen F_Release_SW_System, F_Release_HW_System, F_Release_E/E_System, F_Release_Mechanics_System und F_Release_Mechatronics_System aufgerufen, um ein gesamtes Software-, Hardware-, E/E-, mechanisches oder mechatronisches System zu einer Software-, Hardware-, E/E-Baseline, mechanischen Konfiguration bzw. einem mechatronischen Gesamtsystem freizugeben.

Diese Workflows ermöglichen die vollständige und umfassende Betrachtung aller domänen-spezifischen Aspekte sowie aller funktionalen und hierarchischen Abhängigkeiten zwischen den verschiedenen Bestandteilen eines mechatronischen Produkts im Rahmen eines Freigabe-

Page 168: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

150 Definition der SOA-Elemente für die mIP

prozesses. Damit wird ein domänenübergreifendes und interdisziplinäres Freigabemanagement innerhalb der Entwicklung mechatronischer Produkte unterstützt.

W_Version

Durch die Workflows der Klasse W_Version werden die Auswirkung von Änderungen bzw. Versionierung von technischen Komponenten innerhalb ihrer lokalen Ablagesysteme (d. h. PDM-, EES- oder SCM-System) auf übergeordnete interdisziplinäre Systeme in der mIP über-tragen. Das heißt, dass die Workflows dafür sorgen, dass z. B. eine Änderung einer Applikati-onssoftwarekomponente im SCM-System zur Änderung bzw. Versionierung des übergeordne-ten Gesamtsoftwaresystems, E/E-Systems und mechatronischen Gesamtsystems führt. Diese Workflows werden bei der Ausführung der mIP-Funktionen F_Version_SW_System, F_Version_HW_System, F_Version_E/E_System, F_Version_Mechanics_System oder F_Version_Mechatronics_System angestoßen.

Diese Workflows ermöglichen eine automatische und lückenlose Verfolgung und Berücksich-tigung von funktionalen und hierarchischen Abhängigkeiten zwischen technischen Kompo-nenten und Systemen bei einer Änderung einer Komponente und somit kann deren Tragweite innerhalb des Gesamtprodukts bzw. die Auswirkung auf weitere Komponenten, Funktionen und Systeme frühzeitig identifiziert und dokumentiert werden. Durch diese Workflows kann sichergestellt werden, dass bei einer Änderung einer technischen Komponente alle an der Ent-stehung des Produkts betroffenen Organisationen rechtzeitig informiert bzw. allarmiert wer-den.

8.2 Definition der Services

Für die Umsetzung der definierten Workflows und einen Teil der mIP-Funktionen (s. Tabelle 7-1) werden in diesem Ab-schnitt mehrere Services definiert, die im nächsten Schritt als Web Services implementiert werden. Ein häufiger Diskussionspunkt bei der Definition von Services ist ihre Granularität. Potenzial für Wiederverwendung entsteht aber nur, wenn die Services einerseits genügend grob granular sind, um eine in sich geschlossene Funktionalität anzubieten. Andererseits müssen sie jedoch auch fein granular genug sein, um in unterschied-lichen Kontexten Verwendung finden zu können. Dafür gibt es aber keine allgemeingültigen Kriterien [Brau2005]. Für die Umsetzung der mIP wird in dieser Arbeit ein Service als eine in sich geschlossen Basisfunktion einer domänenspezifischen PLM-Anwendung (d. h. PDM-, EES- oder SCM-System) verstanden und betrachtet.

Damit die domänenspezifischen PLM-Anwendungen ihre Funktionalitäten als Web Services bereitstellen können, müssen sie über eine Web Service-Schnittstelle verfügen. Diese Hürde wird im Laufe der Zeit in dem Maße an Bedeutung verlieren, in dem sich die Einhaltung der Paradigmen der SOA bei der IT-Systementwicklung weiter durchsetzen kann und IT-

Page 169: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der SOA-Elemente für die mIP 151

Anwendungen einen immer größeren Teil ihrer Ressourcen über Web Services bereitstellen [Brau2005]. Für die bestehenden Legacy-PLM-Anwendungen, die keine Web Service-Schnittstellen (sog. Web Service Gateways) haben, können diese Schnittstellen über einen Adapter bereitgestellt werden und damit nachträglich Web Service-tauglich gemacht werden. Dieses Web Service Gateway setzt auf vorhandene APIs55 der Legacy-PLM-Anwendungen auf und wandelt alle eingehenden SOAP-Nachrichten in entsprechende Funktionsaufrufe der PLM-Anwendungen um und alle Ausgaben wiederum in SOAP-Nachrichten (Abbildung 8-1). Damit ein SOAP-Client die PLM-Anwendungen auch nutzen kann, muss das Gateway auch eine Schnittstellenbeschreibung in WSDL zur Verfügung stellen.

Bestehende Legacy-PLM-Anwendung

Web ServiceGateway

SOAP-Client

WSDL

SOAP

Java API

Abbildung 8-1: Funktionsweise eines Web Service Gateway nach [Brau2005]

Die für die Ausführung der Workflows und mIP-Funktionen notwendigen Services sowie die für ihre Bereitstellung (d. h. Services) zuständigen domänenspezifischen PLM-Anwendungen werden in der folgenden Tabelle 8-2 dargestellt:

mIP-Funktion/Workflow Services Service-Klasse

PLM-Anwen-

dung

F_Create_SW_Component S_Create_Application_SW S_Create

SCM

-Sys

tem

S_Create_Platform_SW S_Create

F_Allocate_SW_Component_Version_to_SW_System_Function_Version

S_Get_Application_SW S_Get

S_Get_Platform_SW S_Get

W_Release_SW_System, W_Release_E/E_System und W_Release_Mechatronics_System

S_Get_Release_Status_Application_SW

S_Get_Release_Status

S_Get_Release_Status_Platform_SW

S_Get_Release_Status

55 API: Application Programming Interface

Page 170: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

152 Definition der SOA-Elemente für die mIP

W_Version_SW_System, W_Version_E/E_System und W_Version_Mechatronics_System

S_Version_Application_SW S_Version

S_Version_Platform_SW S_Version

F_Create_HW_Component S_Create_Microcontroller S_Create

EES-

Syst

em

S_Create_HW_Body S_Create

F_Allocate_HW_Component_Version_to_HW_System_Function_Version

S_Get_Microcontroller S_Get

S_Get_HW_Body S_Get

W_Release_HW_System, W_Release_E/E_System und W_Release_Mechatronics_System

S_Get_Release_Status_Microcontroller

S_Get_Release_Status

S_Get_Release_Status_HW_Body

S_Get_Release_Status

W_Version_HW_System, W_Version_E/E_System und W_Version_Mechatronics_System

S_Version_Microcontroller S_Version

S_Version_HW_Body S_Version

F_Create_Mechanics_Component

S_Create_Mechanical_Component

S_Create

PDM

-Sys

tem

S_Create_Hydraulic_Component

S_Create

S_Create_Pneumatic_Component

S_Create

F_Allocate_Mechanics_Compo-nent_Version_to_Mechanics_System_Function_Version

S_Get_Mechanical_Component

S_Get

S_Get_Hydraulic_Component

S_Get

S_Get_Pneumatic_Component

S_Get

W_Release_Mechanics_System und W_Release_Mechatronics_System

S_Get_Release_Status_Mechanical_Component

S_Get_Release_Status

S_Get_Release_Status_Hydraulic_Component

S_Get_Release_Status

S_Get_Release_Status_Pneumatic_Component

S_Get_Release_Status

W_Version_Mechanics_System und W_Version_Mechatronics_System

S_Version_Mechanical_Component

S_Version

S_Version_Hydraulic_Component

S_Version

S_Version_Pneumatic_Component

S_Version

Tabelle 8-2: Services für die Workflows und mIP-Funktionen

Page 171: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der SOA-Elemente für die mIP 153

Zur Ermöglichung der Verwaltung und des Suchens der Services durch den Service-Nutzer innerhalb der serviceorientierten Architektur werden die Services in vier Klassen unterteilt S_Create, S_Get, S_Get_Release_Status, S_Version (Tabelle 8-2). Die Services lassen sich wie folgt beschreiben:

S_Create

Durch die Services, die zu dieser Klasse gehören, werden die Dienste der Funktionen der ver-schiedenen domänenspezifischen PLM-Anwendungen zur Erstellung technischer Komponen-ten (d. h. Applikationssoftware, Plattformsoftware, Mikrocontroller, Hardwaregehäuse, me-chanische, hydraulische und pneumatische Komponenten) für die mIP-Anwender angeboten.

Um eine technische Komponente erstellen zu können, müssen diese Services Operationen an-bieten, die durch die Eingabe von Metadaten (z. B. Komponenten-ID, Bezeichnung, …) eine technische Komponente in der entsprechenden domänenspezifischen PLM-Anwendung (PDM-, EES- oder SCM-System) erzeugen. Diese Operation stellt innerhalb eines Service nur eine Referenzierung bzw. einen Verweis auf die tatsächlich auszuführende PLM-anwendungs-spezifische Funktion dar.

S_Get

Die Services der Klasse S_Get ermöglichen den mIP-Anwendern die PLM-anwendungsspezi-fischen Funktionen zum Suchen und zur Bereitstellung technischer Komponenten zu benutzen.

Zur Realisierung dieses Dienstes verfügen die Services über Operationen, welche bei Eingabe von Metadaten aus einer domänenspezifischen PLM-Anwendung die gesuchte technische Komponente ausgeben. Beim Aufruf dieses Service empfangen die Operationen die Metadaten der zu suchenden Komponente und leiten sie weiter an die entsprechende PLM-anwendungsspezifische Funktion. Nach der Ausführung dieser Funktion werden die Ergebnis-se an die Services zurück geliefert.

S_Get_Release_Status

Die PLM-anwendungsspezifischen Funktionen zur Abfrage des Freigabestatus der technischen Komponenten werden durch die Services der Klasse S_Get_Release_Status aufgerufen und deren Dienste für das Workflow W_Release_System bereitgestellt.

Diese Services bieten Operationen, bei denen durch die Eingabe von Metadaten die Freigabe-status der entsprechenden technischen Komponenten ausgegeben werden, an. Zur Ausführung dieser ienste rufen diese Operationen mittels SOAP-Nachrichten die geeigneten PLM-anwendungsspezifischen Funktionen auf.

S_Version

Mittels der Services, die zu der Klasse S_Version gehören, werden Änderungen an technischen Komponenten automatisch an die übergeordneten technischen Systeme übertragen. Diese Ser-vices liefern Operationen, welche eine SOAP-Nachricht aufgrund einer Änderung einer tech-

Page 172: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

154 Definition der SOA-Elemente für die mIP

nischen Komponente von der entsprechenden domänenspezifischen PLM-Anwendung auto-matisch bekommen und darauf basierend eine Änderung der darüber liegenden technischen Systeme in der mIP hervorrufen. Die Dienste dieser Services werden im Workflow W_Version_System integriert.

8.3 Definition des Registry- und Mediation-Moduls

Die definierten Services und Workflows werden in einem Con-tainer (Server) abgelegt, der ein Registry- und ein Mediation-Modul zur Verwaltung und zur Vermittlung von Services und Workflows enthält. Das Regist-ry-Modul verfügt über ein Standarddatenmodell, das eine standardisierte Beschreibung der Services und Workflows ermöglicht sowie Methoden zur Service- und Workflow-Verwaltung beinhaltet. Das Mediation-Modul liefert Methoden, die dem Nutzer das Finden der geeigneten Services oder Workflows anhand der Beschreibungsdaten erleichtert (Abbildung 8-2).

Standarddatenmodell für die Service- und Workflow-Beschreibung

Das definierte Datenmodell basiert auf dem Datenmodell des UDDI-Standards und umfasst die folgenden Klassen:

businessEntity: Diese Klasse beschreibt die PLM-Anwendung, die für die funktionale Umsetzung des Service verantwortlich ist. Zu der Beschreibung gehören z. B. Name der PLM-Anwendung, Release, Serveradresse, URL56 etc. Diese Klasse ist für die Be-schreibung der Workflows nicht relevant, da Workflows zu keiner Anwendung gehören.

businessService: Durch diese Klasse werden die Workflows und die Services im Regist-ry-Modul beschrieben (z. B. Name, Key, Beschreibung etc.) und klassifiziert. Ein Workflow kann entweder zur Klasse W_Release oder zur Kategorie W_Version (s. Ab-schnitt 8.1) gehören. Services können je nach zu erfüllender Funktion zu den Klassen S_Create, S_Get, S_Get_Release_Status oder S_Version (s. Abschnitt 8.2) gehören.

bindingTemplate: Diese Klasse beschreibt die technischen Informationen, wie und wo ein Service oder ein Workflow aufgerufen werden kann. Zu diesen Informationen gehö-ren die notwendigen auszutauschenden Input- und Output-Daten sowie die Service- und Workflow-Adresse (z. B. http57-Adresse für Web Services).

Um Services hinzuzufügen, zu modifizieren oder zu entfernen, verfügt das Registry-Modul zusätzlich über eine UDDI Publishers API, die die Methoden save_service, save_business, save_binding, delete_service, delete_business und delete_binding liefert.

56 URL: Uniform Resource Locator 57 HTTP: Hypertext Transfer Protocol

Page 173: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Definition der SOA-Elemente für die mIP 155

Mediation-Modul

Zur automatischen Auffinden von Services und Workflows bietet das Mediation-Modul eine standardisierte UDDI-Schnittstelle Inquiry API, deren Methoden find_service, find_binding, find_business, get_serviceDetail, get_bindingDetail, get_businessDetail dem Nutzer das Su-chen und Aufrufen von Services oder Workflows ermöglicht. Hierzu haben diese Methoden einen direkten Zugriff auf die Service- und Workflow-Beschreibungsdaten im Registry-Modul.

Service Container

Registry-Modul

Mediation-Modul

Beschreibungs-Daten der Services

und Workflows

Service-Anbieter

Service-NutzerPublishers

APIInquiry

API

Veröffentlichung Suchen

Service-Anbieter: domänenspezifische PLM-AnwendungenService-Nutzer: Services, Workflows und mIP-Funktionen

Abbildung 8-2: Funktionsweise von Registry- und Mediation-Modul

Page 174: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

156 Web Service-basierte Konzeption der SOA-Elemente

9 Web Service-basierte Konzeption der SOA-Elemente

9.1 Web Service-basierte Konzeption der Services

Um die im Abschnitt 5.2.2 definierte Servicestruktur umzusetzen, werden die Services in An-lehnung an den WSDL-Standard erstellt. Ein Service besteht laut WSDL-Standard aus den folgenden Elementen:

types: Anhand des types-Elements werden alle Datentypen, die beim Austausch zwi-schen dem Service und den Service-Nutzern oder -anbietern verwendet werden, be-schrieben. Solche Datentypen können z. B. string, integer, boolean etc. sein.

message: Das message-Element definiert alle Nachrichten, die der Service bei der Kommunikation mit den Service-Nutzern und -anbietern austauschen wird.

portType: Mittels des portType-Elements werden die Funktionen, die ein Service zu bieten hat, und deren Input- und Output-Daten definiert.

binding: Das binding-Element bestimmt die Laufzeit-Kommunikationsmechanismen, die ein Service bei der Kommunikation mit anderen Teilnehmern verwenden wird. Dazu gehören z. B. das Nachrichtenformat und das Kommunikationsprotokoll (SOAP, http).

service: Das service-Element beschreibt, wo die angebotenen Dienste bzw. Funktionen des Service zu finden sind. Dieses Element stellt eine Referenzierung auf die Funktio-nen innerhalb der jeweiligen IT-Anwendungen dar.

Die Elemente types, message und portType präsentieren zusammen die Beschreibung der Ser-vice-Schnittstelle und das Implementierungsmodul eines Service wird durch die Elemente binding und service definiert (s. Abschnitt 5.2.2) (Abbildung 9-1).

Page 175: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Web Service-basierte Konzeption der SOA-Elemente 157

Service-Schnittstelle

Implementierungs-Modul

Abbildung 9-1: Struktur eines Service [W3C2008]

Die Abbildung 9-2 zeigt als Beispiel die WSDL-Beschreibung für den Service S_Get_Release_Status_Microcontroller.

Durch das Element operation innerhalb des portType wird eine Funktion GetReleaseStatus-Microcontroller definiert, die einen Input bekommt und einen Output zurückgibt. Der Input sind die Metadaten des Mikrocontrollers, der Output ist damit der Status des Mikrocontrol-lers. Die Parameter und ihre Typen von Input- und Output-Daten werden innerhalb der mes-sages Metadaten und ReleaseStatus definiert. Bei der message Metadaten sind Name (Type: String), ID (Type: Integer), und Version (Type: Integer) als Eingabe und bei der message Re-leaseStatus ist der Status (Type: String) als Ausgabe zu erwarten.

Mittels des Elements binding werden das Nachrichtenformat und das Protokoll definiert. Das Protokoll wird im Attribut transport festgelegt, was in diesem Beispiel HTTP ist. Das Ele-ment style hat die Kommunikationsart der Nachricht als rpc58 festgelegt und die Nachrichten-kodierung definiert.

Im Element Service wird der Service S_Get_Release_Status_Microcontroller mittels eines binding an die entsprechende zu erfüllende Funktion in dem EES-System gebunden. Die Ad-resse der Funktion in diesem Beispiel ist http://localhost:8080/active-bpel/services/GetReleaseStatusMicrocontroller.

58 Beim rpc style wird eine bestimmte Methode samt ihrer Parameter gesendet.

Page 176: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

158 Web Service-basierte Konzeption der SOA-Elemente

Abbildung 9-2: WSDL-Beschreibung des Service „S_Get_Release_Status_Microcontroller“

9.2 Web Service-basierte Modellierung der Workflows

Zur Modellierung der Workflows auf Basis der definierten Services wird die Service-Orchestrationssprache WS-BPEL 2.0 verwendet. WS-BPEL ist eine XML-basierte Sprache, die es ermöglicht, aus einer Komposition von einzelnen Web Services wiederum einen Prozess bzw. Workflow zu erstellen. Im Rahmen der Komposition können Festlegungen über die Rei-henfolge sowie die Abhängigkeiten und Verknüpfung der einzelnen Web Services in dem ent-stehenden Prozess bzw. Workflow getroffen werden. Dabei werden die zeitliche Abfolge der

Page 177: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Web Service-basierte Konzeption der SOA-Elemente 159

aufgerufenen Web Services festgelegt sowie der Datenfluss zwischen den verschiedenen Pro-zess- bzw. Workflow-Partnern geregelt.

9.2.1 BPEL-Prozess-Basiselemente

Ein BPEL-Prozess besteht aus einem Prozess-Interface und einem Prozess-Schema. Das Pro-zess-Interface ist in WSDL-Datei formuliert, da jeder BPEL-Prozess selbst einen Web Service darstellt. In der WSDL-Datei des Prozess-Interfaces werden die Datentypen des jeweiligen Web Services, welcher im Prozess integriert wird, beschrieben. Das Prozess-Schema definiert den eigentlichen Prozessablauf, die Art und Weise der Instanziierung und die involvierten Prozesspartner (Web Services).

Die Strukturierung eines BPEL-Prozesses erfolgt mittels einer Kombination aus hierarchi-schen Blöcken und Graphen. Die hierarchischen Blöcke können verschachtelt werden. Sie sind in BPEL als strukturierte Aktivitäten (flow, forEach, if, pick, repeatUntil, scope, sequence und wihle) formuliert. Diese strukturierten Aktivitäten kontrollieren den Fluss von atomaren Akti-vitäten (invoke, receive, reply, assign, compensate, compensateScope, empty, exit, throw, reth-row, validate und wait) und bilden so die Knoten eines Ausführungsbaums. Die atomaren Ak-tivitäten steuern den einzelnen Schritt eines BPEL-Prozesses; so ruft beispielsweise invoke einen Web Service auf. Die strukturierten und die atomaren Aktivitäten sowie die weiteren Elemente eines BPEL-Prozesses werden im Anhang 14.4 detailliert beschrieben.

Zur Abbildung und Modellierung von BPEL-Prozessen bzw. -Workflows können kommerziel-le graphische BPEL Process Designer Tools genutzt werden (wie z. B. ActiveBPEL Designer von Active Endpoints, BPWS4J Editor von IBM oder BPEL Process Manager von Oracle), welche eine intuitive Bedienung auch für unerfahrene Nutzergruppen ermöglichen. Aus der graphischen Abbildung des BPEL-Prozesses bzw. -Workflows kann direkt ein ausführbarer BPEL-Prozess durch eine BPEL Process Execution Engine (wie z. B. ActiveBPEL Engine, BPWS4J oder Oracle BPEL Process Server) erzeugt und ausgeführt werden.

9.2.2 Funktionsprinzip einer BPEL-Prozesskomposition

Ein BPEL-Prozess ermöglicht die Integration und die Interaktion mehrerer heterogener IT-Anwendungen, indem eine Sequenz von einzelnen Dienstanrufen (d. h. Web Services, die die Funktionen der einzelnen IT-Anwendungen repräsentieren) steuert. Zur Laufzeit ruft die BPEL-Prozess-Engine die im BPEL-Prozess (XML-Datei) beschriebenen Dienste (Web Ser-vices) entsprechend den BPEL-Prozessinstruktionen auf. So wird beispielsweise ein BPEL-Prozess von einer Applikation als Web Service aufgerufen. Im Laufe seiner Abarbeitung ruft der BPEL-Prozess einen externen Web Service auf, kopiert die vom externen Web Service erhaltenen Ergebnisse und gibt sie der aufrufenden Applikation zurück (Abbildung 9-3).

Page 178: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

160 Web Service-basierte Konzeption der SOA-Elemente

receive

invoke

receive

reply

receive

invoke

flow

assign

Scope

sequenceBPEL-Prozess-Schema WebService

WebService

WebService

WebService

WebService

WebService

WebService

Strukturierte Aktivität

Atomare Aktivität

Prozess-Interface

Legende:

Abbildung 9-3: Funktionsprinzip einer BPEL-Komposition

9.2.3 Beispiel für die Komposition des Workflows „W_Release_Mechatronics_System“

Im folgenden Abschnitt soll die Komposition des Workflows W_Release_Mechatronics_System beispielhaft anhand der Freigabe eines elektronischen Bremssystems veranschaulicht werden. Ein elektronisches Bremssystem besteht aus dem E/E-System ESP und aus dem mechanischen Bremssystem. Eine Freigabe des elektronischen Bremssystems kann nur erfolgen, wenn das ESP-System und das mechanische Bremssystem schon freigegeben sind. Die Freigabe dieser beiden Systeme setzt voraus, dass die darunter liegenden Subsysteme (wie z. B. ESP-Hardware- und ESP-Softwaresysteme) bzw. die techni-schen Komponenten (wie z. B. DSC, ABS, ASR, MSR, Hydroaggregat, Radbremse, Drossel-klappe) den Status „Freigegeben“ besitzen. Dies erfordert zunächst die Suche nach der betrof-fenen technischen Komponente innerhalb der domänenspezifischen PLM-Anwendungen und anschließend die Abfrage und die Auswertung von deren Freigabestatus. Nach der Auswer-tung der verschiedenen Freigabestatus kann die Bestimmung der Freigabestatus der darüber liegenden Systeme schrittweise erfolgen bis eine Ermittlung des Freigabestatus des elektroni-schen Gesamtbremssystems möglich ist (Abbildung 9-4).

Page 179: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Web Service-basierte Konzeption der SOA-Elemente 161

Abbildung 9-4: Workflow „W_Release_Mechatronics_System”

Page 180: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

162 Web Service-basierte Konzeption der SOA-Elemente

Die zur Realisierung dieses Workflows notwendigen Services werden in der folgenden Tabelle 9-1 aufgeführt:

Service Aufgabe

S_Get_Release_Status_Application_SW

Zur Ermittlung der Freigabestatus der Applikationssoftwarekomponenten DSC, ABS, ASR und MSR aus dem SCM-System.

S_Get_Release_Status_Platform_SW

Zur Ermittlung der Freigabestatus der Plattformsoftwarekomponenten DSC, ABS, ASR und MSR aus dem SCM-System.

S_Get_Release_Status_Microcontroller Zur Ermittlung der Freigabestatus der Mikrocontroller DSC, ABS, ASR und MSR aus dem EES-System.

S_Get_Release_Status_HW_Body Zur Ermittlung der Freigabestatus des ESP-Gehäuses aus dem EES-System.

S_Get_Release_Status_Mechanical_Component

Zur Ermittlung der Freigabestatus der mechanischen Komponenten Radbrem-se, Kraftstoffeinspritzung, Zündwinkel und Drosselklappe aus dem PDM-System.

S_Get_Release_Status_Hydraulic_Component Zur Ermittlung der Freigabestatus des Hydroaggregats aus dem PDM-System.

Tabelle 9-1: Die notwendigen Services für das Workflow „W_Release_Mechatronics_System“

Die Abbildung 9-5 zeigt einen Ausschnitt aus dem mittels WS-BPEL graphisch modellierten Workflows W_Release_Mechatronics_System. In diesem Ausschnitt ist der Workflowteil De-fine_Release_Status_Mechanics_System zur Ermittlung des Freigabestatus des mechanischen Gesamtsystems zu sehen. Dieser Workflowteil ist als strukturierte Aktivität Scope modelliert, welche alle zur Ermittlung des Freigabestatus notwendigen Aktivitäten beinhaltet. Nach dem Aufruf des Workflows erhält die strukturierte Aktivität Defi-ne_Release_Status_Mechanics_System durch die atomare Aktivität Receive eine Message Re-lease_Mechanics_System, die die Metadaten des betroffenen mechanischen Gesamtsystems sowie seiner technischen Komponenten enthält. Aufgrund dieser Message wird eine weitere strukturierte Aktivität Get_Release_Status_Mechanical_Component aufgerufen, die drei ver-schiedenen atomaren Invoke Aktivitäten zum Aufrufen der Service S_ S_Get_Release_Status_Mechanical_Component, S_Get_Release_Status_Hydraulic_Component und S_Get_Release_Status_Pneumatic_Component zur Bereitstellung der Freigabestatus der be-

Page 181: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Web Service-basierte Konzeption der SOA-Elemente 163

troffenen Systeme aus dem PDM-Systeme umfasst. Die ermittelten Freigabestatus werden an die strukturierte If-Aktivität Interpret_Release_Status_Mechanics_System für die Auswertung weitergegeben. Je nach Auswertungsergebnis wird entweder die atomare Assign-Aktivität Re-leased oder Not_Released aktiviert, um den Freigabestatus des mechanischen Gesamtsystems zu definieren.

Auf die gleiche Art und Weise funktionieren die strukturierten Scope-Aktivitäten Defi-ne_Release_Status_SW_System und Define_Release_Status_HW_System, um die Freigabesta-tus des gesamten Software- und Hardwaresystems zu definieren.

Die durch die strukturierten Aktivitäten Define_Release_Status_Mechanics_System, Defi-ne_Release_Status_SW_System und Define_Release_Status_HW_System definierten Freigabe-status werden an die strukturierte If-Aktivität Interpret_Release_Status_Mechatronics_System vermittelt, um die Freigabestatus des mechatronischen Gesamtsystems als Input an die mIP-Funktion F-Release_Mechatronics_System festzulegen.

Page 182: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

164 Web Service-basierte Konzeption der SOA-Elemente

Abbildung 9-5: Ausschnitt eines BPEL-Prozesses für „W_Release_Mechatronics_System“

Ein Auszug aus dem ausführbaren BPEL-Quellcode des Workflows W_Release_Mechatronics_System ist in Abbildung 9-6 zu sehen.

Page 183: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Web Service-basierte Konzeption der SOA-Elemente 165

Abbildung 9-6: Auszug aus dem BPEL-Code für „W_Release_Mechatronics_System“

9.2.4 Beispiel für die Komposition des Workflows „W_Version_Mechatronics_System“

Im Folgenden wird die Komposition des Workflows W_Version_Mechatronics_System bei-spielhaft durch die Versionierung eines elektronischen Bremssystems erläutert. Ausgehend von einem freigegebenen Stand eines elektrischen Bremssystems hat sich ein Regelungspara-meter der Funktion Bremsschlupfregler innerhalb der Softwarekomponente ABS geändert. Diese Änderung hat zur Folge, dass weitere Parameter des ESP-Softwaresystem angepasst werden müssen, was zur Erstellung einer neuen Version des ESP-Softwaresystems führt. Um diese Änderungen innerhalb des gesamten Bremssystems nachvollziehbar und rückverfolgbar zu machen, müssen demzufolge die Versionsnummer des gesamten ESP-Systems und die Ver-

Page 184: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

166 Web Service-basierte Konzeption der SOA-Elemente

sionsnummer des elektronischen Gesamtbremssystems um 1 hochgezählt werden (Abbildung 9-7).

Abbildung 9-7: Workflow „W_Version_Mechatronics_System”

Dieses Workflow wird in diesem Fall durch den Service S_Version_Application_SW angesto-ßen, welcher wiederum bei der Versionierung der Softwarekomponente ABS durch die SCM-Anwendung aufgerufen wurde. Die Komposition des Workflows mittels WS-BPEL kann gra-phisch wie in der Abbildung 9-8 dargestellt werden. Eine Versionierung einer technischen Komponente in einer domänenspezifischen PLM-Anwendung ruft direkt durch eine atomare Invoke-Aktivität einen entsprechenden Service (d. h. S_Version_Application_SW, S_Version_Platform_SW, S_Version_HW_Body, S_Version_Microcontroller, S_Version_Pneumatic_Component, S_Version_Hydraulic_Component oder S_Version_Mechanical_Component) auf, das die Vergabe einer hohen Version für das über-geordnete System (d. h. Software-, Hardware-, E/E-, mechanisches oder mechatronisches Ge-samtsystem) durch die atomare Assign-Aktivität in der mIP veranlasst.

Page 185: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Web Service-basierte Konzeption der SOA-Elemente 167

Abbildung 9-8: BPEL-Prozess für „W_Version_Mechatronics_System“

Ein Ausschnitt des ausführbaren BPEL-Quellcodes des Workflows W_Version_Mechatronics_System ist in der Abbildung 9-9 aufgeführt.

Page 186: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

168 Web Service-basierte Konzeption der SOA-Elemente

Abbildung 9-9: Auszug aus dem BPEL-Code für das „W_Version_Mechatronics_System“

Page 187: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Prototypische Realisierung 169

10 Prototypische Realisierung

In diesem Kapitel wird die prototypische Realisierung einer SOA-basierten Integrationsplatt-form für die Entwicklung mechatronischer Produkte auf Basis der entwickelten Konzepte dar-gelegt. Im Vordergrund dieser prototypischen Umsetzung steht vor allem eine flexible und offene Systemarchitektur, die die Anbindung von schon vorhandenen PLM-Anwendungen sowie zukünftigen neuen Anwendungen nach dem Prinzip der losen Kopplung ohne großen Aufwand ermöglicht.

Im Folgenden werden zunächst die IT-Architektur und die eingesetzten IT-Werkzeuge vorges-tellt. Im Anschluss werden die Arbeitsweise und die Funktionen der prototypischen mechatro-nischen Integrationsplattform (mIP) exemplarisch anhand der Entwicklung eines elek-tronischen Bremssystems veranschaulicht.

10.1 IT-Systemarchitektur

Für die Implementierung der SOA-basierten PLM-Architektur wurde die Web Service-Technologie als SOA-Umsetzungstechnologie verwendet. Die Auswahl der dabei verwendeten IT-Tools und -Standards erfolgte auf Basis der freien Verfügbarkeit der Softwaresysteme (Open Source Software) und der Gewährleistung der oben beschriebenen Anforderungen. Zu Definition, Modellierung, Debugging und Simulation der Web Services und der Workflows wurden die Open-Source-Produkte ActiveBPEL Designer und ActiveBPEL Engine eingesetzt. Für die Verwaltung und Ausführung der Web Services und der Workflows wurde der Apache Tomcat Server verwendet. Die Implementierung der mIP wurde auf Basis des kommerziellen PDM-Systems Teamcenter Engineering durchgeführt. In dieser Arbeit wurden keine realen domänenspezifischen PLM-Anwendungen (d. h. EES-, SCM- und PDM-System) benutzt, je-doch wurden deren Funktionen sowie die dazu gehörigen Input- und Output-Daten simuliert. Hierzu wurden die für die prototypische Umsetzung erforderlichen domänenspezifischen PLM-Anwendungsfunktionen und -daten in den Web Services definiert und ausgeführt (Ab-bildung 10-1).

Page 188: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

170 Prototypische Realisierung

mIP auf Basis Teamcenter Engineering

Apache TomcatServer

ActiveBPEL Designer und ActiveBPEL Engine

PDMEES

SCM

Virtuelle domänenspezifischePLM-Anwendungen

Aufrufen von Web Services und Workflows

Bereitstellung von Dienstender domänenspezifischen

PLM-Anwendungen

Ablage von Web Services und Workflows

Simulation der domänenspezifischenPLM-Anwendungsfunktionen und

-Daten innerhalb der Web Services

Abbildung 10-1: IT-Architektur der prototypischen mechatronischen Integrationsplattform

10.1.1 Teamcenter Engineering

Als Basis für die Implementierung der mechatronischen Integrationsplattform wurde das PDM-System Teamcenter Engineering der Firma Siemens PLM Software verwendet. Dies ist eines der führenden PDM-Systeme und wird zur Umsetzung von PLM-Konzepten sowohl unternehmensintern als auch unternehmensübergreifend eingesetzt. Es verfügt über Funktiona-litäten zur konsistenten Verwaltung und Steuerung von Geometriedaten, Produktstrukturen, Dokumenten, Freigabe- und Änderungsprozessen etc. während des Produktentstehungsprozes-ses. Zudem ist seine Architektur web service-konform, sodass die Kommunikation mit Web Services und die Integration in eine serviceorientierte Architektur möglich sind.

Die zurzeit auf dem Markt existierende Version von Teamcenter Engineering bietet standard-mäßig unzureichende Möglichkeiten an, um Daten und Prozesse mechatronischer Produkte zu verwalten und zu steuern, wobei es jedoch über eine JAVA-basierte Programmierschnittstelle verfügt, welche eine unternehmensspezifische Anpassung des Standarddatenmodells und der Standardsystemfunktionen ermöglicht.

Page 189: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Prototypische Realisierung 171

In dieser Arbeit wurden durch die Verwendung der JAVA-Programmierschnittstelle das Stan-darddatenmodell gemäß dem im Konzept definierten mechatronischen Meta-Datenmodell (s. Abschnitt 7.2) erweitert und dementsprechend angepasst sowie das Standardfunktionsset um die im Abschnitt 7.1. definierten Funktionen erweitert. Des Weiteren wurde die Web Service-Schnittstelle zum Aufrufen von Web Services und Workflows angepasst.

10.1.2 ActiveBPEL Designer

Für die Definition und die Modellierung der Services und Workflows (s. Abschnitt 8.1 und 8.2) mittels der Prozessmodellierungssprache WS-BPEL wurde in dieser Arbeit das System ActiveBPEL Designer der Firma ActiveEndpoints Inc. eingesetzt. Der ActiveBPEL Designer ermöglicht die graphische Modellierung von BPEL-Prozessen und generiert automatisch den zugehörigen ausführbaren BPEL-Code (WSDL-Datei) im Hintergrund. Er baut auf dem Eclipse-Framework auf.

10.1.3 ActiveBPEL Engine

Der durch den ActiveBPEL Designer erstellte Prozess-BPEL-Code wird semantisch und syn-taktisch mittels des Systems ActiveBPEL Engine geprüft (Debugging), welches zur SOA-Produktfamilie der Firma ActiveEndpoints Inc. gehört. Mit ActiveBPEL Engine können eine Design-Time Simulation und ein Test des Prozessablaufs durchgeführt werden.

10.1.4 Apache Tomcat Server

Zur Ausführung der Web Services und Workflows wurde der Apache Tomcat Server verwen-det. Der Apache Tomcat Server ist ein sogenannter Web Container. Er wurde von der Apache Software Foundation entwickelt. Es handelt sich um einen in Java geschriebenen Servlet-Container und verfügt über einen HTTP-Server.

10.2 Funktionsweise der mechatronischen Integrationsplattform

10.2.1 Erweiterung des Standarddatenmodells von TC Engineering

Zur Handhabung der im Rahmen der Entwicklung mechatronischer Produkte anfallenden Pro-duktobjekte und -daten wurde das Standarddatenmodell von Teamcenter Engineering gemäß dem mechatronischen Meta-Datenmodell (s. Abschnitt 7.2) um mehrere Klassen und Bezie-hungen erweitert. Diese Klassen und Beziehungen ermöglichen die Durchführung der Pro-zessaufgaben, die zu den in Kapitel 6 definierten Use Cases gehören.

Abbildung 10-2 zeigt die Standardklassen von Teamcenter Engineering und die im Rahmen dieser Arbeit neu definierten und umgesetzten Klassen:

Page 190: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

172 Prototypische Realisierung

Standardklassen von Teamcenter Engineering

Restliche Klassen wurdenin dieser Arbeit definiert

Klassen des Datenmodells

Legende:

Abbildung 10-2: Implementierung des mechatronischen Meta-Datenmodells in TC-Engineering

10.2.2 Erstellung einer logischen Systemarchitektur

Zur Erstellung der im Abschnitt 6.1 beschriebenen logischen Architektur des elektronischen Bremssystems sind zunächst die (Sub-)Systeme und die (Teil-)Funktionen in der mIP zu defi-nieren. Hierfür wurden in Teamcenter Engineering die mIP-Funktionen F_Create_System und F_Create_Logic_Function implementiert (s. Tabelle 7-1) (Abbildung 10-3).

Page 191: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Prototypische Realisierung 173

Erstellen eines Systems Erstellen einer Funktion

System: Elektrisches Bremssystem Funktion: Fahrzeugstabilisierung

Version 01 des Elektrischen Bremssystems

Version 01 der FunktionFahrzeugstabilisierung

Abbildung 10-3: Erstellen von Systemen und logischen Funktionen

Nach der Definition der (Sub-)Systeme und der (Teil-)Funktionen sollen deren hierarchische und funktionale Beziehungen bzw. Abhängigkeiten festgelegt werden. Für die Erstellung der hierarchischen Beziehungen wird das PSE-Modul von Teamcenter Engineering verwendet (Abbildung 10-4). Zur Definition der funktionalen Beziehungen wurden die mIP-Funktionen F_Create_System_System_Relation und F_Create_Logic_Function_Logic_Function_Relation (s. Abschnitt 7.1) implementiert, um die Beziehungen als Energie-, Stoff- oder Informations-fluss zu definieren (Abbildung 10-5, 10-6).

Abbildung 10-4: Erstellung einer hierarchischen Beziehung zwischen zwei Systemen (Fahr-zeug und Antriebsstrang)

Page 192: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

174 Prototypische Realisierung

Erstellung einer funktionalenBeziehung zwischen zwei Funktionen

Abbildung 10-5: Erstellung einer funktionalen Beziehung zwischen logischen Funktionen (1/2)

Zu verbindenden logischen Funktion auswählen

Typ der funktionalenBeziehung auswählen

Beziehungsrichtungfestlegen

Funktionale Beziehungbeschreiben

Abbildung 10-6: Erstellung einer funktionalen Beziehung zwischen zwei logischen Funktionen (2/2)

In Abbildung 10-7 ist die funktionale Abhängigkeit der logischen Funktion Fahrzeugstabili-sierung bei Kurvenfahrt von anderen logischen Funktionen zu sehen:

Page 193: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Prototypische Realisierung 175

Logische Funktion „Fahrzeug-stabilisierung“

Logische Funktionen, die zur Funktion „Fahrzeugstabilisierung“ funktionale Abhängigkeiten haben

Typ der funktionalen Beziehungen

Richtung der funktionalen Beziehungen

Beschreibung der funktionalen Beziehungen

Abbildung 10-7: Darstellung der funktionalen Abhängigkeiten zwischen zwei logischen Funk-tionen

Die Abbildung 10-8 stellt die logische Architektur des mechatronischen Systems elektrisches Bremssystem dar:

Hauptsysteme einesFahrzeugs

Subsysteme des Fahrwerksystems

Hauptfunktionen deselektrischen Bremssystems

Teilfunktion derFahrzeugstabilisierungs-funktion

Abbildung 10-8: Logische Architektur des elektrischen Bremssystems

Page 194: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

176 Prototypische Realisierung

10.2.3 Erstellung einer technischen Systemarchitektur

Die logische Funktion Fahrzeugstabilisierung bei Kurvenfahrt (vgl. Abschnitt 6.1) wird weiter konkretisiert, indem die technischen Systeme zur Realisierung ihrer Teilfunktionen zunächst definiert werden. Zu diesem Zweck wurden in Teamcenter Engineering die mIP-Funktionen F_Create_Mechanics_System, F_Create_E/E_System und F_Create_Sensor (s. Tabelle 7-1) implementiert.

Die einzelnen definierten technischen Systeme werden zu einem Regelkreis zur Realisierung der logischen Funktion Fahrzeugstabilisierung bei Kurvenfahrt zusammengeführt. Hierzu werden die Relationen zwischen den technischen Systemen als Energie-, Stoff- oder Informa-tionsflüsse definiert (Abbildung 10-9). Die dafür notwendigen Teamcenter Engineering-Funktionalitäten wurden wie in Tabelle 7-1 aufgeführt implementiert.

Sensoren

Regler

Regelstrecker

Stellglieder

Abbildung 10-9: Regelkreis der logischen Funktion „Fahrzeugstabilisierung bei Kurvenfahrt“

Im nächsten Schritt erfolgt die Partitionierung der logischen Teilfunktionen auf die definierten

technischen Systeme. Hierfür wurde im Teamcenter Engineering die mIP-Funktionen

F_Allocate_Logic_Function_to_Mechanics_System,

F_Allocate_Logic_Function_to_E/E_System und F_Allocate_Logic_Function_to_Sensor im-

plementiert (Abbildung 10-10, 10-11, 10-12).

Page 195: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Prototypische Realisierung 177

Partitionierung einer logischen Funktion

Abbildung 10-10: Partitionierung einer logischen Funktion (1/2)

Logische Teilfunktion„Ermittlung des Sollverhaltens“

Zuordnung der logischen Teilfunktion„Ermittlung des Sollverhaltens“ zum technischen System „EE-Bremssteuerung“

Beschreibung derFunktions-partitionierung

Abbildung 10-11: Partitionierung einer logischen Funktion (2/2)

Page 196: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

178 Prototypische Realisierung

Logische Teilfunktion„Ermittlung des Sollverhaltens“

Technisches System, das für die Realisierung der logischen Teilfunktion “Ermittlung des Sollverhaltens „ verantwortlich ist

Beschreibung der technischen Realisierung

Abbildung 10-12: Darstellung von Informationen zur funktionalen Partitionierung

10.2.4 Erstellung einer E/E-Systemarchitektur

Das im vorherigen Abschnitt definierte E/E-Bremssteuerungssystem wird hier weiter konkreti-siert, indem die logische Teilfunktion Ermittlung des Sollverhaltens des Fahrzeugs in weitere Teilfunktionen verfeinert (vgl. Abschnitt 6.2) und auf die für ihre Realisierung verantwortli-chen Software- und Hardwaresysteme (ESP-Softwaresystem und ESP-Hardwaresystem) parti-tioniert wird (Abbildung 10-13). Zu diesem Zweck wurden wie in der Tabelle 7-1 dargestellt die erforderlichen mIP-Funktionen in Teamcenter Engineering umgesetzt.

Page 197: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Prototypische Realisierung 179

Teilfunktionen der logischen Funktion „Ermittlung des Sollverhaltens des Fahrzeugs

Hardwaresystem

Softwaresystem

Abbildung 10-13: E/E-Systemarchitektur der Funktion „Ermittlung des Sollverhaltens des Fahrzeugs“

10.2.5 Erstellung einer Software-, Hardware- bzw. mechanischen System-architektur

Zur Erstellung einer Software- bzw. Hardware-Systemarchitektur werden in Teamcenter En-gineering die mIP-Funktionen – F_Create_SW_Component, F_Allocate_SW_System_Function_to_SW_Component, F_Create_HW_Component, F_Allocate_HW_System_Function_to_HW_Component, F_Create_Mechanics_Component und F_Allocate_Mechanics_System_Function_to_Mechanics_Component – implementiert, welche die Definition von Software-, Hardware- und mechanischen Komponenten aus der mIP heraus im SCM- , EES- bzw. PDM-System sowie die Partitionierung der Software-, Hardwa-re- und mechanischen Systemfunktionen auf die definierten Komponenten ermöglichen.

Die Abbildungen 10-14 zeigen exemplarisch die Software- und Hardware-Systemarchitektur des ESP-Systems (vgl. Abschnitt 6.2).

Applikationssoftwarekomponenten des ESP-Softwaresystems

Mikrocontroller des ESP-Hardwaresystems

ESP-Softwaresystemarchitektur ESP-Hardwaresystemarchitektur

Abbildung 10-14: Software- und Hardware-Systemarchitektur

Page 198: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

180 Prototypische Realisierung

In der Abbildung 10-15 ist die Partitionierung von ESP-Software-Systemfunktionen auf die DSC-Softwarekomponente (vgl. 6.2) zu sehen.

Softwarekomponente „DSC“

Softwaresystemfunktionen, die innerhalb der Softwarekomponente „DSC“ implementiert werden

Kurze Beschreibung der Funktionen

Abbildung 10-15: Partitionierung von Software-Systemfunktionen

10.2.6 Erstellung von Software-, Hardware- und E/E-Baseline sowie mechani-scher Systemkonfiguration und mechatronischem Gesamtsystem

Die Erstellung einer Software-, Hardware-, E/E-Baseline und mechanischen Systemkonfigura-tion wurde im Teamcenter Engineering durch die Erweiterung des Moduls PSE mit den mIP-Funktionen zur Zuordnung von Versionen technischer Komponenten zu den entsprechenden Versionen der verschiedenen technischen Systemfunktionen realisiert (s. Tabelle 7-1).

Die Erstellung der Version 01 der ESP-Software-Baseline (vgl. Abbildung 6-17) in der mIP wird in der Abbildung 10-16 exemplarisch veranschaulicht. Die Version 01 der ESP-Software-Baseline setzt sich aus den Softwarekomponenten DSC (Version 03), ABS (Version 01), ASR (Version 02), MSR (Version 01) und der ESP-Plattformsoftware (Version 04) zusammen.

Page 199: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Prototypische Realisierung 181

ESP-Software-Baseline ,Version 01Softwarekomponente

„DSC“, Version 03

Softwarekomponente „ASR“, Version 02

Softwarekomponente „MSR“, Version 01

ESP-Plattformsoftware , Version 01

Softwarekomponente „ABS“, Version 01

Abbildung 10-16: Erstellung einer Software-Baseline

Page 200: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

182 Verifikation und Bewertung der Ergebnisse

11 Verifikation und Bewertung der Ergebnisse

11.1 Verifikation der prozessbezogenen Anforderungen

11.1.1 Verifikation der Anforderungen zur Ermöglichung einer interdisziplinä-ren und funktionsorientierten Entwicklungsmethodik

Die in dieser Arbeit entwickelte mechatronische Integrationsplattform (mIP) bietet eine Reihe von Funktionalitäten, die die Durchführung von interdisziplinären Prozessaufgaben ab einem frühen Zeitpunkt im Entstehungsprozess und die Handhabung der dazu gehörenden interdis-ziplinären Produktdaten ermöglichen bzw. unterstützen. Aufgrund der vollständigen Orientie-rung bei der Konzipierung der mIP an das V-Modell der mechatronischen Entwicklungsme-thodik (VDI 2206) können die Integration und die Einbindung aller domänenspezifischer Ent-wicklungsprozesse sowie der daran beteiligten Fachbereiche durch den Einsatz der mIP maß-geblich gefördert und unterstützt werden. Innerhalb des definierten mechatronischen Meta-Datenmodells stehen interdisziplinäre Produktbestandteile wie z. B. logische und technische (Sub-) Systeme und (Teil-)Funktionen sowie deren hierarchische und funktionale Beziehungen zueinander im Mittelpunkt, was eine interdisziplinäre Systemspezifikation, eine frühzeitige Identifizierung und Berücksichtigung von Wechselwirkungen zwischen den Domänen sowie eine funktionsorientierte Denkweise stark unterstützt.

Anf.-Nr. Erläuterung Erfüllungsgrad

A.1.1 Ermöglichung der Integration und Ein-bindung der domänenspezifischen Ent-wicklungsprozesse

A.1.2 Unterstützung der Einbindung aller an der Produktentstehung beteiligten Fach-bereiche

A.1.3 Unterstützung des gemeinsamen und domänenübergreifenden Problem- und Zielverständnisses

A.1.4 Ermöglichung einer domänenübergrei-fenden Systemspezifikation

A.1.5 Unterstützung der Identifizierung und Berücksichtigung der Wechselwirkung zwischen den Disziplinen

Page 201: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Verifikation und Bewertung der Ergebnisse 183

A.1.6 Unterstützung der funktionsorientierten Denkweise

Legende: vollständig erfüllt größtenteils erfüllt O teilweise erfüllt

Tabelle 11-1: Verifikation der Anforderungen zur Ermöglichung einer interdisziplinären und funktionsorientierten Entwicklungsmethodik

11.1.2 Verifikation der Anforderungen zur Synchronisation der domänenspe-zifischen Entwicklungsprozesse

Die Workflows der Klasse W_Version (s. Abschnitt 8.1) ermöglichen es, die verschiedenen domänenspezifischen Versionierungsmechanismen, die innerhalb der einzelnen domänenspe-zifischen PLM-Anwendungen implementiert sind, auf mechatronische Gesamtprozessebene zu synchronisieren und darauf basierend ein domänenübergreifendes Versionierungsmanagement für das mechatronische Gesamtprodukt zu realisieren. Durch die Workflows der Klasse W_Release werden die Abhängigkeiten bzw. die Wechselwirkung zwischen den einzelnen Elementen eines mechatronischen Produkts (d. h. technische Komponente, Systeme, Funktio-nen, Beziehungen) automatisch bei der Durchführung von Freigabeprozessen berücksichtigt, so dass eine interdisziplinäre Freigabe für mechatronische Produkte und Produktbestandteile immer gewährleistet werden kann. Die mIP-Funktionen zur Erstellung von Softwaresystem-, Hardwaresystem-, E/E-System-Baselines sowie mechanischer und mechatronischer Gesamt-systemkonfiguration bieten die Möglichkeit, abgesicherte und zueinander kompatible Kompo-nenten, Funktionen und Systeme aus verschiedenen Domänen zu einem interdisziplinären funktionierenden Gesamtsystem zu integrieren. Somit ist jederzeit festzuhalten, welche Kom-binationen von Systembestandteilen in einem Produkt verbaut sind.

Durch die mIP-Funktionen zur Partitionierung von mechatronischen Systemfunktionen auf konkrete technische Systeme und Komponenten werden die Abhängigkeiten zwischen den technischen Systemen bzw. Komponenten mit den zu erfüllenden Produktfunktionen während des gesamten Produktentstehungsprozesses festgehalten und automatisch bei der Durchfüh-rung aller Prozessaufgaben in Betracht gezogen, sodass die funktionsorientierte Vorgehens-weise bei der Entwicklung des mechatronischen Produkts stetig unterstützt und gefördert wird.

In dieser Arbeit wurden keine konkrete Freigabe- und Änderungsprozesse für die Entwicklung mechatronischer Produkte definiert, da nur eine unternehmensspezifische Definition derartiger Prozesse sinnvoll ist. Aber durch die mIP-Funktionen zur Versionierungs- und Konfigurati-onsmanagement und die Workflows der Klassen W__Version und W_Release ist die Umset-zung von standardisierten, generischen Freigabe- und Änderungsprozessen wie z. B. die VDA-Empfehlung 4965 (Engineering Change Management) innerhalb des mechatronischen Um-felds möglich geworden.

Page 202: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

184 Verifikation und Bewertung der Ergebnisse

Anf.-Nr. Erläuterung Erfüllungsgrad

A.2.1 Ermöglichung eines domänenübergrei-fenden und funktionsorientierten Ver-sionierungsmanagements

A.2.2 Ermöglichung eines domänenübergrei-fenden und funktionsorientierten Ände-rungsmanagements

O

A.2.3 Ermöglichung eines domänenübergrei-fenden und funktionsorientierten Freiga-bemanagements

A.2.4 Ermöglichung eines domänenübergrei-fenden und funktionsorientierten Konfi-gurationsmanagements

Legende: vollständig erfüllt größtenteils erfüllt O teilweise erfüllt

Tabelle 11-2: Verifikation der Anforderungen zur Synchronisation der domänenspezifischen Entwicklungsprozesse

11.2 Verifikation der datenbezogenen Anforderungen

Die mIP basiert auf dem interdisziplinären, mechatronischen Meta-Datenmodell (s. Abschnitt 7.2), welches die notwendigen Klassen und Beziehungen zur Abbildung der relevanten inter-disziplinären Produktbestandteile sowie deren hierarchischen und funktionalen Abhängigkei-ten bereitstellt. Dies ermöglicht eine domänenunabhängige interdisziplinäre Gesamtsystem-spezifikation sowie die Erhöhung der semantischen Homogenität innerhalb der Entwicklung mechatronischer Produkte. Durch die Klasse Function und die Assoziation implemented in bietet das Datenmodell die Möglichkeit, eine funktionsorientierte Vorgehensweise bei der Entwicklung mechatronischer Produkte anzuwenden. Auf Basis der Beziehungen zwischen den Klassen Application_SW, Platform_SW, Microcontroller, HW_Body und Mecha-nics_Component und den Klassen SW_System, HW_System und Mechanics_System können die verschiedenen domänenspezifischen Partialdatenmodelle auf abstrakte interdisziplinäre Ebene verknüpft werden, sodass ein domänenübergreifender, durchgängiger Datenfluss ent-lang des gesamten Entwicklungsprozesses gewährleistet wird. Aufgrund dieser minimalen Kopplung können die domänenspezifischen Partialdatenmodelle ihre interne Freiheit im Hinb-lick auf Veränderungen und Weiterentwicklung bewahren, was die Weiterentwicklung der Produkte sowie die Prozess- und Datenlandschaft nicht unnötig behindern wird.

Die Beschreibung des Produktverhaltens mittels dieses Datenmodells hat sich nur auf die Ab-bildung der Energie-, Stoff- und Informationsflüsse zwischen den Systemen, Funktionen und Komponenten des Produkts beschränkt. Zur weiteren Beschreibung des Produktverhaltens

Page 203: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Verifikation und Bewertung der Ergebnisse 185

kann das Datenmodell aufgrund seines objektorientierten Aufbaus ohne großen Aufwand mit weiteren Klassen z. B. zur Abbildung von Simulationsdaten erweitert werden.

Anf.-Nr. Erläuterung Erfüllungsgrad

A.3.1 Abbildung aller interdisziplinären Pro-duktdaten

A.3.2 Ermöglichung der Erstellung einer logi-schen Systemarchitektur

A.3.3 Ermöglichung der Funkpartition auf die technischen Komponenten und Systeme

A.3.4 Unterstützung der semantischen Homo-genität innerhalb einer heterogenen me-chatronischen Umgebung

O

A.3.5 Integration der domänenspezifischen Partialdatenmodelle

A.3.6 Aufbewahrung der internen Autorität und Freiheit der domänenspezifischen Partialdatenmodelle

A.3.7 Erweiterbarkeit um neue Objekte und Disziplinen

A.3.8 Sicherstellung des domänenübergreifen-den Datenflusses entlang des gesamten Entwicklungsprozesses

A.3.9 Unterstützung des domänenübergreifen-den und interdisziplinären Versionie-rungs-, Konfigurations-, Änderungs- und Freigabemanagements

A.3.10 Integration von domänenspezifischen Entwicklungsergebnissen zu einem funktionierenden Gesamtsystem

Legende: vollständig erfüllt größtenteils erfüllt O teilweise erfüllt

Tabelle 11-3: Verifikation der datenbezogenen Anforderungen

11.3 Verifikation der PLM-Systemlandschaft-bezogenen Anforde-rungen

11.3.1 Verifikation der Anforderung an die Interdisziplinarität

Der in dieser Arbeit konzipierten mechatronischen PLM-Architektur liegt ein serviceorientier-ten Ansatz zugrunde, der durch die Kapselung und die Bereitstellung der Funktionalitäten der verschiedenen domänenspezifischen PLM-Anwendungen als standardisierte Services die IT-

Page 204: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

186 Verifikation und Bewertung der Ergebnisse

bedingten Heterogenitätsprobleme mit wenig Aufwand – im Vergleich zu anderen Integrati-onstechnologien wie z. B. EAI – überwinden kann.

Die entwickelte mIP stellt eine wichtige IT-Unterstützung zur Durchführung von interdiszipli-nären Entwicklungsprozessen bzw. -aufgaben dar, da die Konzipierung ihrer Funktionalitäten und ihres Datenmodells sich stark an der VDI-Richtlinie 2206 (Methodik für die Entwicklung mechatronischer Produkte) orientiert hat.

Anf.-Nr. Erläuterung Erfüllungsgrad

A.4.1 Überwindung der IT-Heterogenität in-nerhalb des mechatronischen Umfelds

A.4.2 Ermöglichung der Rahmenbedingungen zum Einsatz einer interdisziplinären und funktionsorientierten Entwicklungsme-thodik (vgl. Abschnitt 3.1.1)

A.4.3 Ermöglichung der interdisziplinären Synchronisationsmethodik (vgl. Ab-schnitt 3.1.2)

Legende: vollständig erfüllt größtenteils erfüllt O teilweise erfüllt

Tabelle 11-4: Verifikation der Anforderung an die Interdisziplinarität

11.3.2 Verifikation der Anforderung zum Schützen bestehender IT-Investitionen

Die SOA-basierte mechatronische PLM-Architektur und die für ihre Umsetzung ausgewählte Web Service-Technologie – die eine hohe Akzeptanz und sehr starke Verbreitung als IT-Integrationstechnologie bei den IT-Systemherstellern genießt – ermöglichen die Integration sowohl von neuen IT-Anwendungen – da sie eine Web Service-Schnittstelle als Standard-schnittstelle mit sich bringen –, als auch von Legacy-IT-Anwendungen durch einfachen Ein-satz von marktgängigen Web Service-Adaptern. Damit ist eine wichtige Voraussetzung zum Schützen bestehender IT-Investitionen erfüllt.

Page 205: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Verifikation und Bewertung der Ergebnisse 187

Anf.-Nr. Erläuterung Erfüllungsgrad

A.5.1 Aufbau auf vorhandene domänenspezifi-schen PLM-Systeme und die dazugehö-rige IT-Infrastruktur

Legende: vollständig erfüllt größtenteils erfüllt O teilweise erfüllt

Tabelle 11-5: Verifikation der Anforderung zum Schützen bestehender IT-Investitionen

11.3.3 Verifikation der Anforderungen an die Flexibilität

Bei der Konzipierung der SOA-basierten mechatronischen PLM-Architektur wurde insbeson-dere viel Wert darauf gelegt, dass die Integrationen bzw. die Interaktion der verschiedenen IT-Systeme untereinander nicht über direkte Schnittstellen realisiert werden, sondern via standar-disierte Services (lose Kopplung). Damit ist eine starke Abhängigkeit der IT-Systeme mitei-nander vermieden worden, sodass eine Änderung an einem IT-System keine Auswirkung auf die anderen Systeme mit sich bringt. Dies trägt dazu bei, die Flexibilität der IT-Landschaft und somit die Unternehmensagilität zu erhöhen.

Anf.-Nr. Erläuterung Erfüllungsgrad

A.6.1 Keine Behinderung der Änderungsdy-namik innerhalb des Unternehmens

A.6.2 Verknüpfung der domänenspezifischen PLM-Anwendungen nach dem Prinzip der losen Kopplung

Legende: vollständig erfüllt größtenteils erfüllt O teilweise erfüllt

Tabelle 11-6: Verifikation der Anforderungen an die Flexibilität

Page 206: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

188 Zusammenfassung und Ausblick

12 Zusammenfassung und Ausblick

12.1 Zusammenfassung der vorliegenden Arbeit

In dieser Arbeit wurde eine SOA-basierte Interoperabilitätslösung zur Ermöglichung der syn-ergetischen Zusammenarbeit der verschiedenen Domänen, die an dem Entwicklungsprozess mechatronischer Produkte beteiligt sind, entwickelt. Den Kern dieser Lösung stellt eine me-chatronische Integrationsplattform (mIP) dar, die die notwendigen Funktionalitäten zur Durch-führung interdisziplinärer und funktionsorientierter Entwicklungsprozesse und -tätigkeiten bereitstellt. Des Weiteren liegt der mIP ein mechatronisches Meta-Datenmodell zugrunde, welches eine interdisziplinäre Beschreibung technischer Komponenten, (Sub-)Systeme, (Teil-)Funktionen sowie deren Beziehungen und Abhängigkeiten ermöglicht. Dieses Datenmodell umfasst Verknüpfungspunkte als Objektklassen zur Anbindung und zur Homogenisierung der verschiedenen domänenspezifischen Partialdatenmodelle auf einer abstrakten und interdiszip-linären Ebene.

Die Durchführung interdisziplinärer Entwicklungsprozesse und -tätigkeiten (wie z. B. interdis-ziplinäres Versionierungs-, Freigabe- oder Konfigurationsmanagement) in der mIP erfordert oft die Zusammenarbeit mehrerer Funktionalitäten und der Daten von verschiedenen domä-nenspezifischen PLM-Anwendungen (d. h. PDM-, EES- und SCM-System). Diese Zusam-menarbeit muss zur Laufzeit orchestriert werden, d. h. sie muss dementsprechend dynamisch koordiniert und gesteuert werden. Hierfür wurde in dieser Arbeit eine serviceorientierte Archi-tektur entworfen, die eine prozessgesteuerte Integration der jeweiligen domänenspezifischen PLM-Anwendung nach dem Prinzip der losen Kopplung auf eine interdisziplinäre Prozess-ebene befähigt. Innerhalb dieser Architektur werden die domänenspezifischen PLM-Anwendungen (Service-Anbieter) ihre Funktionen als standardisierte Services für die mIP-Funktionen (Service-Nutzer) bereitstellen. Die Orchestrierung der Services erfolgt auf Basis von vordefinierten Workflows, die die notwendigen Services zur Laufzeit aufrufen und zur Ausführung von interdisziplinären Prozessaktivitäten anbinden. Die Suche und die Vermitt-lung nach geeigneten Workflows und Services für die Service-Nutzer (in diesem Fall die mIP) übernehmen die Registry- und die Mediation-Module, die alle notwendigen Informationen bzw. Voraussetzungen zur Nutzung und Ausführung von Services und Workflows verwalten.

Zur Realisierung dieser Architektur wurde in dieser Arbeit ein Vorgehensmodell definiert, welches als Leitfaden bzw. Orientierungshilfe zur unternehmensspezifischen Umsetzung von SOA-basierten Integrationslösungen dienen soll. Das Vorgehendmodell umfasst vier Umset-

Page 207: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Zusammenfassung und Ausblick 189

zungsphasen. In der Phase 1 (Kapitel 6) wurde der Entwicklungsprozess mechatronischer Pro-dukte in Anlehnung an die VDI-Richtlinie 2206 (Entwicklungsmethodik für mechatronische Systeme) analysiert und daraus wurden die relevanten interdisziplinären Use Cases zur Ent-wicklung mechatronischer Produkte abgeleitet. Ausgehend von den Use Cases wurde in der Phase 2 (Kapitel 7) die mechatronische Integrationsplattform (mIP) konzipiert, d. h. die erfor-derlichen mIP-Funktionen und das mechatronische Meta-Datenmodell wurden definiert. Die Definition der Workflows und Services waren Gegenstand der Phase 3 (Kapitel 8). Zunächst wurden die Workflows zur Ausführung von interdisziplinären Use Cases (Versionierungs-, Freigabe- und Änderungsmanagement) beschrieben. Anschließend wurden die notwendigen Services aus den Funktionen der domänenspezifischen PLM-Anwendungen abgeleitet und beschrieben. Die definierten Workflows und Services wurden in der Phase 4 (Kapitel 9) mo-delliert und implementiert. Hierzu wurde aufgrund ihrer zu genießenden hohen Akzeptanz und weiten Verbreitung bei den IT-Herstellern wie auch bei den Anwendern die Web Service-Technologie als SOA-Umsetzungstechnologie ausgewählt. Diese Technologie bietet drei Standards (WSDL, SOAP und UDDI) zur Definition und Implementierung von Services, Nachrichten, Registry- und Mediation-Modul an. Die Web Service-Standards werden heute durch fast alle IT-Systeme unterstützt, was eine Anbindung derartiger Systeme in der service-orientierten Architektur ohne zusätzlichen Aufwand möglich macht. IT-Systeme wie z. B. Legacy-Systeme, die keine Web Service-Schnittstelle unterstützen, können heute dank funkti-onsfähigen kommerziellen Adapters Web Service-fähig gemacht werden. Die Modellierung und Ausführung der Workflows erfolgte mittels der Verwendung der Prozessmodellierungs-sprache WS-BPEL, die eine graphische Modellierung der Prozesse ermöglicht. Als Modellie-rungstool wurde hier das System ActiveBPEL verwendet, das den BPEL-Prozesscode aus der graphischen BPEL-Prozessabbildung automatisch generiert und ausführt. Zur Veranschauli-chung der entwickelten Lösung wurden die Umsetzungsphasen von einem Beispiel eines me-chatronischen Entwicklungsprozesses aus dem Automobilbereich, der „Entwicklung eines elektronischen Bremssystems“, begleitet.

Der konzipierte Lösungsansatz wurde prototypisch realisiert. Hierfür wurde ein PDM-System als Implementierungsbasis verwendet, da solche Systeme bereits vorgefertigte Funktionalitä-ten wie z. B. Versionierungs-, Änderungs-, Freigabemanagementfunktionen und ein vorkonfi-guriertes Datenmodell, die einfach anzupassen sind, anbieten.

Durch die Umsetzung des entwickelten Konzepts wurden folgende Ziele erreicht:

Effiziente Durchführung von interdisziplinären und funktionsorientierten Entwick-lungsprozessen mechatronischer Produkte.

Bessere Beherrschung der Heterogenität im Hinblick auf Prozesse, Daten und IT-Werkzeuge innerhalb mechatronischer Entwicklungsumgebung.

Zielführendere Integration domänenspezifischer Prozesse, Daten und IT-Werkzeuge auf eine Gesamtproduktebene.

Page 208: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

190 Zusammenfassung und Ausblick

Erhöhung der Unternehmensagilität durch flexible Prozess-, Daten- und IT-Systemlandschaft.

Die in dieser Arbeit definierten bzw. entwickelten Konzeptbestandteile, d.h. die interdiszipli-nären Use Cases, die mIP-Funktionen, das mechatronische Meta-Datenmodell, die Services und die Workflows, können als Basis für die Entwicklung und Umsetzung von unternehmens-spezifischen Integrationslösungen zur Ermöglichung von interdisziplinären und funktions-orientierten Entwicklung mechatronischer Produkte dienen.

12.2 Weitere Forschungspotenziale

Im Rahmen dieser Arbeit wurde vor allem die Integration der verschiedenen domänenspezifi-schen Managementdaten (d. h. Versionierungs-, Freigabe-, Änderungs- und Konfigurations-management) fokussiert, um eine Steuerung der interdisziplinären Entwicklungsprozesse und -aufgaben zu ermöglichen. Dennoch kann das entwickelte Konzept zur interdisziplinären In-tegration virtueller Produktdaten (wie z. B. MCAD-, ECAD-, CASE-, Berechnungs- und Si-mulationsdaten) erweitert werden. Dies kann zukünftig interdisziplinäre Simulations-, Berech-nungs- oder Prüfungsarbeit erleichtern und effektiver ausgestalten, indem die heute unnötige Konvertierungs- und Datenaustauscharbeit durch automatische Datenbereitstellung in der mIP ersetzt wird. Beispielsweise können zukünftig zur Simulation des elektronischen Gesamt-bremssystems die relevanten Software- und Hardwaresteuerungsdaten und die Kinematik-Modelle durch geeignete Services aus dem SCM-, EES- bzw. PDM-System in die mIP impor-tiert und durch weitere Workflows zu einem Gesamtsystem zusammengeführt und automa-tisch simuliert werden.

In der Zukunft wird die semantische Technologie als Interoperabilitätslösung mehr an Bedeu-tung gewinnen. Durch Definition von Ontologien können Abhängigkeiten, Zusammenhänge und Restriktionen zwischen den verschiedenen domänenspezifischen Systemen, Funktionen und Komponenten detaillierter und genauer beschrieben werden. Damit können die Produkt-daten und die Entwicklungsprozesse selbstsprechend und systemunabhängig dargestellt wer-den, sodass sie von beliebigen weiteren IT-Anwendungen gelesen und interpretiert werden. Diese neue Technologie kann verwendet werden, um die gesamten mechatronischen Entwick-lungsdaten abzubilden und in die serviceorientierte Architektur als Ersatz für das mechatroni-sche Meta-Datenmodell einzuführen. Damit können die Interoperabilitätsfähigkeit sowie die Flexibilität der Gesamtlösung verbessert werden.

Eine weitere Forschungsrichtung ergibt sich aus dem aktuell laufenden SFB/Transregio 2959 Projekt zum Thema „Engineering hybrider Leistungsbündel“. In [MeUK2005] wird ein hyb-rides Leistungsbündel wie folgt definiert:

59 Web-Seite des SFB/TR 29: http://www.lps.rub.de/tr29/

Page 209: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Zusammenfassung und Ausblick 191

Ein hybrides Leistungsbündel(HLB) ist gekennzeichnet durch eine integrierte und sich gegenseitig determinierende Planung, Entwicklung, Erbringung und Nutzung von Sach- und Dienstleistungsanteilen einschließlich ihrer immanenten Softwarekomponenten. Dabei wird die Möglichkeit der Substitution der jeweiligen Sach- und Dienstleistungs-anteil vorausgesetzt.

Aufgrund der verteilten und asynchron ablaufenden Prozesse der Sach- und Dienstleistungs-entstehung sowie der nur schwer prognostizierbaren Auswirkungen der Kundenanforderungen in der Nutzungsphase können die HLB-Änderungsprozesse nicht deterministisch geplant und damit mit heutigen PLM-Methoden verwaltet werden. Daher ist bei der Definition und bei der Ausführung von Änderungsprozessen mehr Flexibilität und Agilität erforderlich, um die not-wendigen Änderungsprozesse über alle Domänen und Partner zur Laufzeit modellieren und initiieren zu können. Hierzu kann ein SOA-basierter Integrationsansatz durch den Einsatz von selbst agierenden bzw. intelligenten Services die notwendige Flexibilität und Agilität einen wichtigen Beitrag leisten.

Page 210: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

192 Literaturverzeichnis

13 Literaturverzeichnis

[AbBe2007] Abramovici, M. / Bellalouna, F.: Integration and Complexity Manage-ment within the Mechatronics Product Development, In: Proceedings of the 14th CIRP International Conference on Life Cycle Engineering, Wa-seda University, Tokyo, 2007, S. 113-118

[AbBe2008] Abramovici, M. / Bellalouna, F.: Service Oriented Architecture for the Integration of Domain-Specific PLM Systems within the Mechatronic Product Development, In: Proceedings of the 7th International Sympo-sium on Tools and methods of Competitive Engineering, Izmir, 2008, S. 941-953

[ABER2000] Aberdeen Group: Enterprise Application Integration: Evolving to Meet e-Business Demands (Report), Februar 2000

[ABER2006] Aberdeen Group: The Mechatronics System Design Benchamk Report, August 2006

[Abra2005] Abramovici, M.: Quo vadis PLM? – Teil 2: PLM-Vision 2015, CAD-CAM Report, Engineering Magazin Nr. 10, 2005

[Abra2006] Abramovici, M.: Evolution des Product Lifecycle Managements in einer veränderten Industrielandschaft, Product Life live 2006: Das Know-how Event zum Management des Produktlebens, 7.-8.11.2006, VDE Verlag, Mainz, S. 13-20

[Abra2007] Abramovici, M.: Future Trends in Product Lifecycle Management (PLM). In: Proceedings of the 17th CIRP Design Conference The Future of Product Development, Berlin, 2007, S. 665-674

[AbSc2004] Abramovici, M. / Schulte, S.: PLM, logische Fortsetzung der PDM -Ansätze oder Neuauflage des CIM-Debakels?, VDI-Berichte 1819, In-tegrierte Informationsverarbeitung in der Produktentstehung, VDI Ver-lag, Stuttgart, 2004

[AbSc2005] Abramovici, M. / Schulte, S.: PLM - Neue Bezeichnung für alte CIM-Ansätze oder Weiterentwicklung von PDM?, In: Konstruktion – Zeit-schrift für Produktentwicklung und Ingenieur-Werkstoffe 1/2 – 2005, Springer Verlag, Düsseldorf, 2005

Page 211: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Literaturverzeichnis 193

[AbSV2003] Abramovici, M. / Schlingensiepen, J. / Versmold, J.: Kooperation in heterogenen PDM-Umgebungen, eDM-Report 4/2003, Dressler Verlag, 2003

[ADAC2009] ADAC: www.adac.de Stand: Main 2009

[Adms2004] Adamsson, N.: Model-Based Development of Mechatronic System – Reducing the Gaps between Competencies. In: Proceedings of the TMCE 2004, Lausanne, 2004, S. 405-413

[AENS2006] Ackermann, U. / Eicker, S. / Neuhaus, S. / Schuler, P. M.: Das EPA-Modell – Ein Referenzmodell für prozessorientierte, dienstbasierte Un-ternehmensarchitekturen. In: Multikonferenz Wirtschaftsinformatik 2006, Tagungsband 2. GITO Verlag, Berlin, 2006, S. 183-197

[AiSc2005] Aier, S. / Schönherr, M.: Prozessorientierte Systemintegration: Ans-pruch und Realität. In: EAI-Workshop 2005 – Enterprise Application In-tegration, GITO Verlag, Berlin, 2005, S. 59-65

[An2007] An, C.: Hype or Reality: Service Oriented Architecture in Product Life-cycle Management – How IBM can help you achieve Innovation that matters. In: Proceedings of the 17th CIRP Design Conference The Future of Product Development, Berlin, 2007, S. 685-690

[AnKF2000] Anderl, R. / Kleiner, S. / Fröhlich, A.: Data Management for Mecha-tronic Products. In: Proceedings of the 6th International Conference on Concurrent Enterprising, Toulouse, 2000, S. 28-30

[AnKr1999] Anderl, R. / Krastel, M.: Multidisciplinary Product Data Management. In: Proceedings of the 2nd Symposium of Concurrent Multidisciplinary Engineering (CME), Bremen, 1999

[AnTr2000] Anderl, R. / Trippener, D.: STEP, Standard for the Exchange of Product Model Data, B. G. Teubner Verlag, Leipzig, 2000

[ASEV2007] Abramovici, M. / Schulte, S. / Eigner, M. / Vajna, S.: Product Lifecycle Management, Innovationspotenziale in der Produktentwicklung, In: In-novationspotenziale in der Produktentwicklung, Hanser Verlag, Mün-chen, Wien, 2007

[ASVH2004] Abramovici, M. / Schlingensiepen, J. / Versmold, J. / Hayka, H. / Pase-waldt, B.: Kooperationslösung für heterogene PDM-Umgebungen, eDM-Report 1/2004, Dressler Verlag, Darmstadt, 2004, S. 22-25

[BaGü2004] Bauer, A. / Günzel, H.: Data Warehouse Systeme: Architektur, Entwick-lung, Anwendung, 2. Auflage, dpunkt.verlag, Heidelberg, 2004

Page 212: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

194 Literaturverzeichnis

[BDKP2005] Bender, K. / Dominka, S. / Koç, A. / Pöschl, M. / Russ, M. / Stützel, B.: Embedded Systems – qualitätsorientierte Entwicklung, Springer Verlag, Berlin, 2005 [Berc2002] Berczuk, S. P.: Software Configuration Management Patterns: Effective

Teamwork and Practical Integration, Addison-Wesley Longman Verlag, Amsterdam, 2002

[BKSS1997] Birli, O. / Kallenbach, E. / Saffert, E. / Schäffle, C.: Zur Gestaltung in-tegrierter mechatronischer Produkte, In: VDI Bericht 1315, Mechatronik im Maschinenbau und Fahrzeugbau, VDI Verlag, Düsseldorf, 1997

[BlPe2006] Blumauer, A. / Pellegrini, T.: Semantic Web und semantische Techno-logien: Zentrale Begriffe und Unterscheidungen, In: Semantic Web – Wege zur vernetzten Wissensgesellschaft, Springer Verlag, Heidelberg, 2006, S. 9 – 25

[Bock2007] Bock, Y.: Composite Applications Enabling Product Data Management Applying SOA Principles and Software Factory Methods. In: Proceed-ings of the 17th CIRP Design Conference The Future of Product Devel-opment, Berlin, 2007, S. 513-520

[Bosc2004] BOSCH: Sicherheits- und Komfortsysteme – Funktion, Regelung und Komponenten, Robert Bosch GmbH, Vieweg und Teubner Verlag, Wiesbaden, 2004

[Brau2005] Braun, I.: Entwurf und Modellierung einer universellen Telearbeitsum-gebung auf Basis einer serviceorientierten Architektur, Dissertation, Fa-kultät Informatik, Technische Universität Dresden, 2005

[BSMA2006] Bopoungo, A. / Spiess, D. / Malzacher, J. / Anderl, R.: PLM Services für Mechatronik in der Automobilindustrie: ein föderativer Ansatz zur Effizienzsteigerung in der Produktentwicklung, In: Entwurf mechatroni-scher Systeme, HNI Velagsschriftenreihe 189, Paderborn, 2006

[CrAD2003] Crnkovic, I. / Asklund, U. / Dahlqvist, A. P.: Implementing and Integrat-ing – Product Data Management and Software Configuration Manage-ment, Artech House Computing Library, Boston, 2003

[Czub2003] Czubayko, R.: Rechnerinterne Repräsentation von informationsverarbei-tenden Lösungselementen für die verteilte kooperative Produktentwick-lung in der Mechatronik, Dissertation, Universität Paderborn, HNI-Verlag, Paderborn, 2003

[DaHu1997] Daenzer, W. F. / Huber, F.: Systems Engineering, Verlag Industrielle Organisation, Zürich, 1997

Page 213: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Literaturverzeichnis 195

[DATA1994] DATAPRO Information Group: IBM Information Warehouse Strategy, Delran, 1994, S. 6-7

[DJMZ2005] Dostal, W. / Jeckle, M. / Melzer, I. / Zengler, B.: Service-orientierte Architekturen mit Web Services, Konzepte – Standards – Praxis, Spekt-rum Akademischer Verlag, München, 2005

[EiSt2001] Eigner, M. / Stelzer, R.: Produktdatenmanagement-Systeme – Ein Leit-faden für Product Development und Life Cycle Management, Springer Verlag, Berlin, 2001

[Elkh2006] El-Khoury, J.: A Model Management and Integration Platform for Mechatronics Product Development, Dissertation, Royal Institute of Technology, Stockholm, 2006

[ENGE2006] Engel, T.: Ein Beitrag zur unternehmensübergreifenden Integration von Informationssystemen, Dissertation, Universität Karlsruhe, Karlsruhe, 2006

[EsGK2002] Esswein, W. / Greiffenberg, S. / Kluge, C.: Konfigurationsmanagement von Modellen, In: Modellierung betrieblicher Informationssysteme –MobIS 2002, Nürnberg, 2002

[Fähn2003] Fähnrich, K. P.: Software Management, Kernfachvorlesung, Praktische Informatik, Lehrstuhl Betriebliche Informationssysteme, Universität Leipzig, 2003

[FGMO2007] Frank, U. / Giese, H. / Müller, T. / Oberthür, S./ Romaus, C. / Tichy, M. / Vöcking, H.: Potenziale und Risiken der Selbstoptimierung für die Verlässlichkeit mechatronischer Systeme, In: 5. Paderborner Workshop, Entwurf mechatronischer Systeme, HNI-Verlagsschriftenreihe 210, Pa-derborn, 2007, S. 289

[FHLW2003] Fensel, D. / Hendler, J. / Lieberman, H. / Wahlster, W.: Spinning the semantic Web. Bringing the World Wide Web to its full potential, MIT Press, Cambridge, 2003

[FiKW2000] Fischer, F. / Karcher, A. / Wirtz, J.: Das PDM-Enablers Datenmodell als Referenzmodell für das Customizing von PDM-Systemen, In: Industrie Management special – Produktdatenmanagement 2/2000, GITO Verlag, Berlin, 2000

[FNGH2006] Feru, F. / Nguyen Van, T. / Guellec, P. / Harms, M.: EDM: a Frame-work for Virtual Aircraft Data Management, In: Proceedings 15th Sym-posium Product Data Technology Europe, Toulouse, France, 2006, S. 23-35

Page 214: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

196 Literaturverzeichnis

[GaEK2001] Gausemeier, J. / Ebbesmeyer, P. / Kallmeyer, F.: Produktinnovation – Strategische Planung und Entwicklung der Produkte von morgen, Carl Hanser Verlag, München, Wien, 2001

[GaFr2006] Gausemeier, J. / Frank, U.: Stand und Perspektiven der Entwicklung mechatronischer Systeme, In: Entwurf mechatronischer Systeme, HNI-Verlagsschriftenreihe, Band 189, Paderborn, 2006, S. 1-24

[GaLü2000] Gausemeier, J. / Lückel, J.: Entwicklungsumgebungen Mechatronik – Methoden und Werkzeuge zur Entwicklung mechatronischer Systeme, HNI-Verlagsschriftenreihe, Band 80, Paderborn, 2000

[GaMö2003] Gausemeier, J. / Möhringer, S.: Die neue Richtlinie VDI 2206 – Ent-wicklungsmethodik für mechatronische Systeme, VDI-Bericht 1753, Düsseldorf, 2003

[GaMö2004] Gausemeier, J. / Möhringer, S.: Integration der Funktions- und Prinzip-lösungsmodellierung mechatronischer Systeme, In: Entwicklungsme-thodik für mechatronische Systeme, HNI-Verlagsschriftenreihe, Band 156, Paderborn, 2004, S. 137-142

[GART2008] GARTNER GROUP: www.gartner.com, Stand September 2008

[Gerh2000] Gerhard, D.: Erweiterung der PDM-Technologie zur Unterstützung ver-teilter Kooperativer Produktentwicklungsprozesse, Dissertation, Univer-sität Bochum, Shaker Verlag, Aachen, 2000

[Gisc2007] Gischel, B.: Handbuch EPLAN Electric P8, Hanser Verlag, München, Wien, 2007

[Glöc2007] Glöckle, H.: IT-Integration und Migration – Konzepte und Vorgehens-weisen, In: IT-Integration & Migration, dpunkt.verlag, Stuttgart, 2007, S. 7-19

[GrEP1994] Grabowski, H. / Erb, J. / Polly, A.: STEP – Grundlage der Produktdaten-technologie, Aufbau und Entwicklungsmethodik, CIM Management 10, Darmstadt, 1994, S. 45-51

[HaLR2008] Hayka, H. / Lüddemann, J. / Stark, R.: Zuverlässigere Gestaltung me-chatronischer Produktentstehung, In: ZWF 2008 / 103, Carl Hanser Ver-lag, München, 2008, S. 714-719

[HaTF1996] Harashima, F. / Tomizuka, M. / Fukuda, T.: Mechatronics – What Is it, Why, and How?, An Editorial, IEEE/ASME Transactions on Mecha-tronics, 1996, S. 1-4

Page 215: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Literaturverzeichnis 197

[Hayk2007] Hayka, H.: Mechatronik-Kooperationsplattform für anforderungsge-steuerte Prüfung und Diagnose, In: Futur: Vision und Innovation. Mit-teilungen aus dem Produktionstechnischen Zentrum (PTZ), Berlin, 2007, S. 10-11

[HeLe2005] Heutschi, R. / Legner, C.: Serviceorientierte Architekturen: Vom Kon-zept zum Einsatz in der Praxis, Universität St. Gallen, Institut für Wirt-schaftsinformatik, St. Gallen, 2005

[HELL2008] Hella KG Hueck & Co.: Neues von Hella – Kurvenlicht erhöht die akti-ve Sicherheit, www.hella.com, Stand 2008

[HeSi2003] Heinisch, C. / Simons, M.: Adaptierbare Software-Architektur für den Software-Download in Kfz-Steuergeräte, In: Informatik 2003, Band 1, Innovative Informatikanwendungen, Frankfurt, 2003

[HKRS2007] Hitzler, P. / Krötzsch, M. / Rudolph, S. / Sure, Y.: Semantic Web – Grundlagen, 1. Auflage, Springer Verlag, Heidelberg, 2007

[Holt1999] Holthuis, J.: Der Aufbau von Data Warehouse-Systemen: Konzeption – Datenmodellierung – Vorgehen, 2. Auflage, Deutscher Universitäts Ver-lag, Wiesbaden, 1999

[HoSR2001] Holeczek, A. / Schäfer, D. / Roller, D.: Die Prozesskette des Schalt-schrankbaus, In: Elektrotechnik CAD: Neue Technologien, Anwendun-gen, Systementwicklung, Zukünftige Trends, Shaker Verlag, Aachen 2001

[HSTZ2008] Hayka, H. / Staub, G. / Thamburaj, V. / Zhang, Q.: Kooperationsplatt-form für mechatronische Produktentstehung, In: ZWF 2008 / 103, Carl Hanser Verlag, München, 2008, S. 721-725

[Hubk1984] Hubka, V.: Theorie technischer Systeme – Grundlagen einer wissen-schaftlichen Konstruktionslehre, Springer Verlag, Berlin, 1984

[HWSD2007] Höß, O. / Weisbecker, A. / Specht, T. / Drawehn, J.: Migration zu ser-viceorientierten Architekturen – top-down oder bottom-up?, In: IT-Integration & Migration, dpunkt.verlag, Stuttgart, 2007, S. 39-46

[Inmo2002] Inmon, W. H.: Building the Data Warehouse, Wiley and Sons, 2002, S. 33-34

[Iser1999] Isermann, R.: Mechatronische Systeme – Grundlagen, Springer Verlag, Berlin, 1999

Page 216: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

198 Literaturverzeichnis

[Jaco2003] Jacobi, G.: Software ist im Auto ein Knackpunkt – Programmierungs-problematik ist Ursache für drei Viertel aller Elektronikausfälle, VDI-Nachrichten, 28.02.2003, Nr. 9, S. 8

[Jans2006] Jansen, S.: Eine Methodik zur modellbasierten Partitionierung mechat-ronischer Systeme, Dissertation, Ruhr Universität Bochum, Shaker Ver-lag, Aachen, 2006

[John2006] John, M.: Semantische Technologien in der betrieblichen Anwendung – Ergebnisse einer Anwenderstudie, Fraunhofer Institut Rechnerarchitek-tur und Softwaretechnik, Berlin, September 2006

[Josu2008] Josuttis, N.: SOA in der Praxis – System-Design für verteilte Geschäfts-prozesse, dpunkt.verlag, 1. Auflage, München, 2008

[KaLa2001] Kahlert, T. / Langenberg, L.: EDM/PDM-Basiswissen: PDM-Enablers (PDME), EDMPDM-Newsletter, 2001

[KBBJ2002] Krause, F.-L. / Baumann, R. / Böttge, U. / Jansen, H. / Kaufmann, U. / Ficiciyan, Y.: iViP integrierte Virtuelle Produktentstehung, In: iViP Ab-schlussbericht, 2002, S. 9-13

[Kell2002] Keller, W.: Enterprise Application Integration: Erfahrung aus der Praxis, 1. Auflage, dpunkt.verlag, Heidelberg, 2002

[Klei2003] Kleiner, S.: Föderatives Informationsmodell zur Systemintegration für die Entwicklung mechatronischer Produkte, Dissertation, Technische Universität Darmstadt, Aachen, 2003

[Klos2001] Klos, M.: Der Schrei der Schraube – auf akustischer Emission basieren-de klemmkraftgesteuerte Serienmontage bei Schraubenverbindungen, VDMA Nachrichten, 03/01, VDMA Frankfurt, 2001

[Kras2002] Krastel, M.: Integration multidisziplinärer Simulations- und Berech-nungsmodelle in PDM-Systeme, Shaker Verlag, Aachen, 2002

[KrBS2004] Krafzig, D. / Banke, K. / Slama, D.: Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall International, Maryland, 2004

[Kutr2005] Kutritz, T.: Umfassendes Qualitätsmanagement für den Bereich Elek-tronik im Versuchsbau der Automobilindustrie, Dissertation, Fakultät Verkehrs- und Maschinensysteme, Technische Universität Berlin, 2005

[LäBu2007] Lämmer, L. / Bugow, R.: PLM Services in Practice, Proceedings of the 17th CIRP Design Conference, Berlin, 2007

Page 217: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Literaturverzeichnis 199

[LäMa1999] Lämmer, L. / Machner, B.: Online-PDM-Kopplung auf der Basis von Standards – STEP PDM Schema und OMG PDM Enablers, In: Produkt-daten-Journal, 2/1999

[Lämm2002] Lämmer, L.: PDM-Enablers, Leitprojekt integrierte Virtuelle Produkt-entwicklung, Abschlussbericht, 2002

[LiSl2001] Liskowsky, R. / Sladek, M.: Konfigurationsmanagement für Gruppenar-beit, Fakultät Informatik der Technische Universität Dresden, 2001

[LSHK2006] Liebhart, D. / Schmutz, G. / Heinisch, M. / Könings, M. / Kölliker, M. / Pakull, P. / Welkenbach, P.: Architecture Blueprints – Ein Leitfaden zur Konstruktion von Softwaresystemen mit Java spring, .Net, ADF, Forms und SOA, Hanser Verlag, Zürich, 2006

[Mane2003] Manes, A. T.: Web Services: A Manager’s Guide, Addison-Wesley Longman Verlag, Amsterdam, 2003

[Mart2007] Martin, W.: SOA Check 2007, Trends im deutschen Markt, Amadee AG, www.soa-check.net, Stand September 2008

[Math2007] Mathas, C.: SOA Intern: Praxiswissen zu Service-Orientierten IT-Systemen, Hanser Verlag, München, 2007

[MECH2001] MechaSTEP – STEP Datenmodelle zur Simulation mechatronischer Systeme, PAS 1013, Beuth Verlag, Berlin, 2001

[MeGr1993] Mertens, P. / Griese, J.: Integrierte Informationsverarbeitung 2, Pla-nungs- und Kontrollsystem in der Industrie, 7. Auflage, Wiesbaden 1993

[MeUK2005] Meyer, H. / Uhlmann, E. / Kortmann, D.: Hybride Leistungsbündel – Nutzenorientiertes Produktverständnis durch interferierende Sach- und Dienstleistung, wt Werkstattstechnik online, Springer-VDI-Verlag, Ausgabe 7/2005, S. 528-532

[Möhr2004] Möhringer, S.: Entwicklungsmethodik für Mechatronische Systeme, HNI-Verlagsschriftenreihe 156, Paderborn, 2004

[MuBe2000] Mucksch, H. / Behme, W.: Das Data Warehouse-Konzept: Architektur – Datenmodelle – Anwendungen, 4. Auflage, Dr. Theodor Gabler Verlag, Wiesbaden, 2000

[Mühl2002] Mühl, G.: iViP-Client und offene Integrationsplattform, In: iViP Ab-schlussbericht, 2002, S. 52-69

[MuHR1996] Mucksch, H. / Holthuis, J. / Reiser, M.: Das Data Warehouse-Konzept – ein Überblick, In: Wirtschaftsinformatik, Band 4, 1996, S. 421-433

Page 218: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

200 Literaturverzeichnis

[OASI2006] OASIS: Reference Model for Service Oriented Architecture Version 1.0, www.oasis-open.org, Stand September 2008

[OASI2008] OASIS: Reference Architecture for Service Oriented Architecture Ver-sion 1.0, www.oasis-open.org, Stand September 2008

[PBFG2004] Pahl, G. / Beitz, W. / Feldhusen, J. / Grote, K. H.: Konstruktionslehre – Grundlagen erfolgreicher Produktentwicklung – Methoden und Anwen-dung, 6. Auflage, Springer-Verlag, Darmstadt, 2004

[PDMC2003] PDM-Collaborator: Abschlussbericht, September, 2003

[Pham2007] Pham Van, T.: Föderatives PDM zur Verwaltung mechatronischer Sys-temstrukturen, Dissertation, TU Darmstadt, Shaker Verlag, Aachen, 2007

[Poll2001A] Pollock, J. T.: The Big Issue: Interoperability vs. Integration, eAI Jour-nal October 2001, http://www.modulant.com/ResourceLibrary/Library_WhtPapers.htm;

[Poll2001B] Pollock, J. T.: IT Systems Interoperability and the Revolution in Seman-tic Computing: Same Problem, Better Solutions, A Modulant White Pa-per, http://www.modulant.com/ResourceLibrary/Library_WhtPapers.htm; 2001.

[PROS2008] ProSTEP: iViP Association, http://prostep.org/de/standards/ Stand März 2008

[ReAL2001] Reinhart, G. / Anton, O. / Lercher, B.: Funktionsorientiertes Sichtenmo-dell für die Entwicklung mechatronischer Systeme, VDI-Z 143 (2001) 11/12, S. 67-70

[RGGH2005] Richter, J.-P. / George, T. / Gugel, T. / Heimann, T. / Lange, H. / Möl-lers, T.: Technology Guide SOA, Software design und management AG, Hamburg, 2005

[RiHS2005] Richter, J.-P. / Haller, H. / Schrey, P.: Serviceorientierte Architektur, In: Informatik-Spektrum, Springer Verlag, Berlin, 2005

[RuGo1991] Ruland, D. / Gotthardt, H.: Entwicklung von CIM-Systemen mit Daten-bankeinsatz, Carl Hanser Verlag, München, 1991

[Sche1990] Scheer, A.-W.: CIM-Strategien als Teil der Unternehmensstrategie, Springer Verlag, Berlin, 1990

[Sche2001] Scheer, A.-W.: ARIS – Vom Geschäftsprozess zum Anwendungssys-tem, Springer Verlag, Berlin, 2001

Page 219: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Literaturverzeichnis 201

[Schm2006] Schmale, T.: Mit EAI und SOA zum Real-Time Enterprise, In: Enterpri-se Application Integration – Serviceorientierung und nachhaltige Archi-tekturen, Band 2, 2. Auflage, GITO Verlag, Berlin, 2006

[Schn2006] Schneider, P. M.: Realisierung von verteilten Anwendungsszenarien anhand einer Serviceorientieren Architektur, Diplomarbeit Nr. 2481, In-stitut für Parallele und Verteilte Systeme, Universität Stuttgart, April 2006

[Schw1989] Schweitzer, G.: Mechatronik – Aufgaben und Lösungen, VDI-Tagung Mechatronik im Maschinen- und Fahrzeugbau, VDI Bericht 787, Bad Homburg, 1989, S. 1-15

[Schw2002] Schweitzer, G.: Mechatronics – the Way to Smart and Intelligent Ma-chines, In: Advanced Driving Systems, ISoM, First International Sym-posium on Mechatronics, Chemnitz, March 21-22, 2002, Proceedings, Chemnitz, 2002

[ScRo2003] Schäfer, D. / Roller, D.: Electrical Engineering Solution – ECAE Sys-teme der dritten Generation, atp automatisierungstechnische Praxis 45, München, 2003

[ScZu2004] Schäuffele, J. / Zurawka, T.: Automotive Software Engineering, Grund-lagen, Prozesse, Methoden und Werkzeuge, Vieweg & Sohn Verlag, Wiesbaden, 2004

[Send2008] Sendler, U.: Engineering Trends – Eine Studie über Trends in der Pro-duktentwicklung im deutschsprachigen Raum, Presseinformation des sendler\circle, September 2008

[SHVW2006] Schlemm, J. W. / Heutschi, R. / Vogel, T. / Wende, K. / Legner, C.: Ser-viceorientierte Architekturen: Einordnung im Business Engineering, In-stitut für Wirtschaftsinformatik, Universität St. Gallen, 2006

[StBM2003] Storga, M. / Bojcetic, N. / Marjanovic, D.: Web Services as Virtual Product Development Environment, In: Proceedings of the International Conference on Engineering Design, ICED 03: International Conference on Engineering Design, Stockholm, 2003

[StBM2004] Storga, M. / Bojcetic, N. / Marjanovic, D.: Consideration on IT Systems Interoperability in Product Development, Proceeding of the TMCE2004, Lausanne, 2004

[StRu2005] Stuetzel, B. / Russ, M.: Orientierungshilfe im mechatronischen Entwick-lungsprozess – das 3-Ebenen-Vorgehensmodell, atp automatisierungs-technische Praxis, No. 47, München, 2005, S. 46-50

Page 220: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

202 Literaturverzeichnis

[StTi2007] Starke, G. / Tilkov, S.: SOA-Expertenwissen: Methoden, Konzepte und Praxis serviceorientierter Architekturen, dpunkt.verlag, Stuttgart, 2007

[Tich1999] Tichy, W. F.: Vorlesung: Softwaretechnik, Institut für Programmstruk-turen und Datenorganisation, Technische Hochschule Karlsruhe, 1999

[ToMa2006] Tochtermann, K. / Maurer, H.: Semantic Web – Geschichte und Aus-blick einer Vision, In: Semantic Web – Wege zur vernetzten Wissensge-sellschaft, Springer Verlag, Heidelberg, 2006, S. 1 - 6

[VDA2000] Verband der Automobilindustrie e. V.: Unternehmerische Chancen und Herausforderungen durch die Mechatronik in der Automobilindustrie, Frankfurt am Main, 2000

[VDA2005] VDA: Auto Jahresbericht, Frankfurt, 2005

[VDI2206] VDI-Gesellschaft Entwicklung Konstruktion Vertrieb: VDI-Richtlinie 2206, Entwicklungsmethodik für mechatronische Systeme, Beuth Ver-lag, Berlin, 2003

[Viva2008] VIVACE: Final technical achievements, http://www.vivaceproject.com, Stand September 2008

[WaHe2007] Warkentin, A. / Herbst, J.: Funktionsorientierung bei PLM-Systemen: Eine Analyse des Standes der Technik. In: 5. Paderborner Workshop, Entwurf mechatronischer Systeme, HNI-Verlagsschriftenreihe 210, Pa-derborn, 2007, S. 335 - 349

[WaRe2006] Wallentowitz, H. / Reif, K.: Handbuch Kraftfahrzeugelektronik: Grund-lagen, Komponenten, Systeme, Anwendungen, Siemens VDO, Vieweg und Teubner Verlag, Wiesbaden, 2006

[Welt2005] Welte, S.: Entwurf serviceorientierter Anwendungen, Diplomarbeit, Universität Kaiserslautern, 2005

[Wenz2004] Wenzler, A.: Web Services und Service Oriented Architectures – Grund-lagen und Vergleich mit bestehenden Middlewaretechnologien, Techni-sche Universität Kaiserslautern, 2004

[WeSW2000] Wehlitz, P. / Schulz, A. / Werner, A.: PDM-Einführung in der Prozess-kette Elektrik/Elektronik in der Automobilentwicklung, In: Der Inge-nieur im Internet; erfolgreiche Anwendungen in der Industrie, VDI-Bericht 1537, VDI Verlag, Düsseldorf, 2000

[W3C2008] www.w3c.org, Stand September 2008

Page 221: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Vorveröffentlichungen

Abramovici, M. / Bellalouna, F.: Integration and Complexity Management within the Mechatronics Product Development, In: Proceedings of the 14th CIRP International Confer-ence on Life Cycle Engineering, Waseda University, Tokyo, 2007, S. 113-118

Abramovici, M. / Bellalouna, F.: Service Oriented Architecture for the Integration of Do-main-Specific PLM Systems within the Mechatronic Product Development, In: Proceedings of the 7th International Symposium on Tools and methods of Competitive Engineering, Izmir, 2008, S. 941-953

Bellalouna, F.: SOA-basierte Integrationsplattform für eine integrierte und interdisziplinäre Entwicklung mechatronischer Produkte, In: Berliner Kreis Tagungsband-Jahrestagung 2008 (Mechantronik – Die Herausforderung an Integration im Produktentstehungsprozess), Mün-chen, 2008, S. 151-175

Abramovici, M. / Bellalouna, F.: Service-Oriented Architecture-Based Approach for Man-agement of an Interdisciplinary and Integrated Mechatronic Product Design, In: Proceedings of the 16th CIRP International Conference on Life Cycle Engineering, Kairo, Ägypten, 2009, S. 236-243

Abramovici, M. / Bellalouna, F.: New PLM-Approach for the Mechatronic Product Design, In: Proceedings of the Proccedings of The 6th International Product Lifecycle Management Conference, Bath, UK, 2009

Abramovici, M. / Bellalouna, F.: Management der Entwicklung mechatronischer Produkte innerhalb eines heterogenen Engineering-Umfelds, In: ProduktDaten Journal, 1/2009, S. 54-57

Abramovici, M. / Bellalouna, F.: Management of Mechatronic Product Development in Het-erogeneous Engineering Environments, In: ProductDaten Journal, 1/2009, S. 54-57

Page 222: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades
Page 223: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anhang 205

14 Anhang

14.1 Elemente des Message Oriented Model

In diesem Abschnitt werden die Elemente des in der Abbildung 11-1 dargestellten MOM-Referenzmodells kurz erläutert:

Abbildung 14-1: Referenzmodell für das Message Oriented Model [W3C2008]

Address

Address ist eine erforderliche Information für die Transportmechanismen, um eine Nachricht transportieren zu können. Address beschreibt den Empfänger einer Nachricht und seine Loka-tion.

Agent

Ein Agent kann ein Sender oder Empfänger einer Nachricht sein.

Delivery Policy

Delivery Policy legt die Voraussetzung für das Senden und Empfangen einer Nachricht, wie z. B. Qualität der Nachricht, Verschlüsselung einer Nachricht fest.

Page 224: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

206 Anhang

Message

Message stellt den Kern einer Nachricht dar. Message umfasst die Funktionen und Daten, die von einem Sender zu einem Empfänger gesendet werden.

Message Body

Message Body präsentiert die Struktur einer Nachricht und liefert Mechanismen zur Vermitt-lung der Nachricht.

Message Correlation

Mit der Message Correlation wird eine Message mit einem bestimmten Kontext assoziiert, um die Korrelation insbesondere bei einer multiple-replies-Kommunikation zu ermöglichen.

Message Envelope

Message Envelope ist eine Struktur zur Einkapselung von message body und message headers.

Message Exchange Pattern

Message Exchange Pattern ist eine Vorlage, die eine generische Struktur zum Nachrichtenaus-tausch zwischen mehreren Teilnehmer beschreibt.

Message Header

Message Header umfasst alle Modalitätsinformationen einer Nachricht, die die Kommunikati-on mit der Nachricht ermöglichen (z. B. Sicherheitsinformationen, Routing-Informationen, Transaction-Informationen).

Message Receiver

Message Receiver ist der Empfänger einer Nachricht.

Message Reliability

Message Reliability ist die Bestätigung, dass eine Nachricht gesendet und empfängt wurde.

Message Sender

Message Sender ist der Erzeuger und Aussender einer Nachricht.

Message Transport

Message Transport ist der Transportmechanismus, der vom Message Sender zum Senden einer Nachricht verwendet wird.

14.2 Beschreibung der mIP-Funktionen

Page 225: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anhang 207

Use Case Funktion der Integrationsplattform

Beschreibung

Erstellung einer logischen System-architektur

F_Create_System Diese Funktion ermöglicht die Defini-tion eines mechatronischen Systems (z. B. elektronisches Bremssystem).

F_Create_Logic_Function

Diese Funktion ermöglicht die Defini-tion logischer Funktionen eines me-chatronischen Systems (z. B. die Funk-tion „Fahrzeug zum Stillstand brin-gen“).

F_Create_System_System_Relation

Durch diese Funktion werden die Rela-tionen zwischen den verschiedenen Systemen festgelegt. Diese Relationen können Energie-, Stoff- oder Informa-tionsflüsse sein.

F_Create_Logic_Function_Logic_Function_Relation

Mittels dieser Funktion wird die Art der Beziehungen zwischen den Sys-temfunktionen definiert. Diese Bezie-hungen können als Energie-, Stoff- oder Informationsaustausch vorkom-men.

Erstellung einer technischen Sys-temarchitektur

F_Create_Mechanics_System

Mit dieser Funktion werden die me-chanischen Systeme eines mechatroni-schen Produkts definiert (z. B. Hydrau-likeinheit).

F_Create_E/E_System Die E/E_Systeme, die zu einem me-chatronischen Produkt gehören, wer-den mithilfe dieser Funktion festgelegt (z. B. ESP-System).

F_Create_Sensor Mit dieser Funktion werden die Senso-ren eines mechatronischen Produkts definiert (z. B. Drehzahlsensor für Räder).

F_Allocate_Logic_Function_to_Mechanics_System

Die Partitionierung der logischen Funktionen auf die für ihre Umsetzung verantwortlichen mechanischen Sys-teme wird durch diese Funktion durch-geführt.

F_Allocate_Logic_Function_to_E/E_System

Diese Funktion ermöglicht die Parti-tionierung der logischen Funktionen auf die für ihre Realisierung notwendi-gen E/E-Systeme.

F_Allocate_Logic_Function_to_Sensor

Diese Funktion ermöglicht die Zuord-nung der logischen Funktionen zu den für ihre Realisierung notwendigen Sensoren.

F_Create_Mechanics_System_Mechanics_System_Relation

Die Beziehungen zwischen den me-chanischen Systemen werden mit die-ser Funktion beschrieben. Diese Be-

Page 226: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

208 Anhang

ziehungen können nur in Form von Energie- oder Stoffflüssen dargestellt werden.

F_Create_E/E_System_E/E_System_Relation

Die auszutauschenden Informationen zwischen den E/E-Systemen werden mittels dieser Funktion definiert.

F_Create_Sensor_Sensor_Relation

Die auszutauschenden Informationen zwischen den Sensoren werden mittels dieser Funktion definiert.

F_Create_Mechanics_System_E/E-System_Relation

Die Steuerungssignale, die die E/E-Systeme an die mechanischen Systeme versenden, werden mithilfe dieser Funktion festgelegt.

F_Create_E/E-System_Sensor_Relation

Die durch die Sensoren erfassten und an die E/E-Systeme gesendeten Signa-le werden mithilfe dieser Funktion abgebildet.

Erstellung einer E/E-Systemarchitektur

F_Create_E/E_System_Function Diese Funktion definiert die Funktio-nen eines E/E-Systems.

F_Create_SW_System Die Softwaresysteme, die zu einem E/E-System gehören, werden mit die-ser Funktion definiert werden.

F_Create_HW_System Diese Funktion ermöglicht die Defini-tion von Hardwaresystemen eines E/E-Systems.

F_Allocate_E/E_System_Function_to_SW_System

Diese Funktion dient dazu, die Zuord-nung der E/E-Systeme mit den zu rea-lisierenden E/E-Funktionen abzubil-den.

F_Allocate_E/E_System_Function_to_HW_System

Diese Funktion dient dazu, die Zuord-nung der E/E-Systeme mit der zu reali-sierenden E/E-Funktionen abzubilden.

F_Create_SW_System_SW_System_Relation

Die zwischen den Softwaresystemen auszutauschenden Informationen wer-den mittels dieser Funktion abgebildet.

F_Create_HW_System_HW_System_Relation

Die Abhängigkeiten der Hardwaresys-teme untereinander werden durch diese Funktion festgelegt.

F_Create_SW_System_HW_System_Relation

Die Abhängigkeiten zwischen den Software- und Hardwaresystemen innerhalb eines mechatronischen Sys-tems werden mit dieser Funktion ab-gebildet.

Erstellung einer Software-Systemarchitektur

F_Create_SW_System_Function Diese Funktion ermöglicht die Defini-tion von Funktionen eines Software-systems.

F_Create_SW_Component Diese Funktion ermöglicht die Spezi-fikation von Softwarekomponenten

Page 227: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anhang 209

eines Softwaresystems.

F_Allocate_SW_System_Function_to_SW_Component

Die Zuordnung der Softwaresystem-funktionen zu den für ihre Umsetzung verantwortlichen Softwarekomponen-ten wird mittels dieser Funktion er-möglicht.

Erstellung einer Hardware-Systemarchitektur

F_Create_HW_System_Function Die Funktionen eines Hardwaresys-tems werden mit dieser Funktion defi-niert.

F_Create_HW_Component Diese Funktion ermöglicht die Spezi-fikation von Hardwarekomponenten eines Hardwaresystems.

F_Allocate_HW_System_Function_to_HW_Component

Die Zuordnung der Hardwaresystem-funktionen zu den für ihre Umsetzung verantwortlichen Hardwarekomponen-ten wird mittels dieser Funktion er-möglicht.

Erstellung einer Mechanik-Systemarchitektur

F_Create_Mechanics_System_Function

Diese Funktion ermöglicht die Defini-tion von Funktionen eines mechani-schen Systems.

F_Create_Mechanics_Component

Diese Funktion ermöglicht die Spezi-fikation von mechanischen Kompo-nenten (d. h. mechanische, hydrauli-sche oder pneumatische Komponente) eines mechanischen Systems.

F_Allocate_Mechanics_System_Func-tion_to_Mechanics_Component

Die Beziehung zwischen den mechani-schen Systemfunktionen und den für ihre Realisierung erforderlichen me-chanischen Komponenten werden mit-tels dieser Funktion abgebildet.

Erstellung einer Software-Baseline

F_Allocate_SW_Component_Version_to_SW_System_Function_Version

Diese Funktion ermöglicht die Zuord-nung einer Version einer Software-komponente zu einer Version einer Softwaresystemfunktion, um ein Ge-samtsoftwaresystem zu erstellen.

F_Release_SW_System Diese Funktion dient dazu, ein Ge-samtsoftwaresystem zu einer Software-Baseline freizugeben.

Erstellung einer Hardware-Baseline

F_Allocate_HW_Component_Version_to_HW_System_Function_Version

Diese Funktion ermöglicht die Zuord-nung einer Version einer Hardware-komponente zu einer Version einer Hardwaresystemfunktion, um ein Ge-samthardwaresystem zu erstellen.

F_Release_HW_System Diese Funktion dient dazu, ein Ge-samthardwaresystem zu einer Hardwa-re-Baseline freizugeben.

Erstellung einer E/E-Baseline

F_Allocate_SW_System_Version_to_E/E_System_Function_Version

Diese Funktion ermöglicht die Zuord-nung einer Version eines Softwaresys-tems zu einer Version einer E/E-

Page 228: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

210 Anhang

Systemfunktion, um ein gesamtes E/E-System zu erstellen.

F_Allocate_HW_System_Version_to_E/E_System_Function_Version

Diese Funktion ermöglicht die Zuord-nung einer Version eines Hardware-systems zu einer Version einer E/E-Systemfunktion, um ein gesamtes E/E-System zu erstellen.

F_Release_E/E_System Diese Funktion dient dazu, ein gesam-tes E/E-System zu einer E/E-Baseline freizugeben.

Erstellung einer mechanischen Kon-figuration

F_Allocate_Mechanics_Component_Version_to_Mechanics_System_Function_version

Diese Funktion ermöglicht die Zuord-nung einer Version einer mechani-schen Komponente zu einer Version einer mechanischen Systemfunktion, um ein gesamtes mechanisches System zu erstellen.

F_Release_Mechanics_System Diese Funktion dient dazu, ein gesam-tes mechanisches System zu einer me-chanischen Konfiguration freizugeben.

Erstellung eines mechatronischen Gesamtsystems

F_Allocate_E/E_System_Version_to_Logic_Function_Version

Diese Funktion ermöglicht die Zuord-nung einer Version eines E/E-Systems zu einer Version einer logischen Funk-tion, um ein gesamtes mechatronisches System zu erstellen.

F_Allocate_Mechanics_Version_to_Logic_Function_Version

Diese Funktion ermöglicht die Zuord-nung einer Version eines mechani-schen Systems zu einer Version einer logischen Funktion, um ein gesamtes mechatronisches System zu erstellen.

F_Release_Mechatronics_System Diese Funktion dient dazu, ein gesam-tes mechatronisches System freizuge-ben.

Versionierung eines Systems

F_Version_SW_System

Diese Funktion ermöglicht die automa-tische und manuelle Versionierung eines Softwaresystems (falls eine un-tergeordnete Softwarekomponente sich ändert).

F_Version_HW_System

Diese Funktion ermöglicht die automa-tische und manuelle Versionierung eines Hardwaresystems (falls eine untergeordnete Hardwarekomponente sich ändert).

F_Version_E/E_System

Diese Funktion ermöglicht die automa-tische und manuelle Versionierung eines Hardwaresystems (falls ein un-tergeordnetes Software- und/oder Hardwaresystem sich ändert).

F_Version_Mechanics_System Diese Funktion ermöglicht die automa-tische und manuelle Versionierung eines mechanischen Systems (falls

Page 229: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anhang 211

eine untergeordnete Komponente sich ändert).

F_Version_Mechatronics_System Diese Funktion ermöglicht die automa-tische und manuelle Versionierung eines mechanischen Systems (falls ein untergeordnetes System sich ändert).

Tabelle 14-1: Beschreibung der mIP-Funktionen

Page 230: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

212 Anhang

14.3 Mechatronisches Meta-Datenmodell

Abbildung 14-2: Mechatronisches Meta-Datenmodell

Page 231: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anhang 213

14.4 WS-BPEL

14.4.1 Struktur eines BPEL-Prozesses

Die Struktur eines mit WS-BPEL modellierten Prozesses bzw. Workflows umfasst einen „Global Declarations“- und einen „Process Definition“-Teil (Abbildung 11-1). Während im ersten Teil u. a. Parameter, Nachrichten, Interaktionspartner und Kommunikationsregeln defi-niert bzw. bekanntgegeben werden, werden im zweiten Teil die Aktivitäten und die Funktiona-litäten des Prozesses bzw. des Workflows beschrieben.

Abbildung 14-3: Struktur eines BPEL-Prozesses

14.4.2 BPEL-Aktivitäten

BPEL unterscheidet zwischen atomaren und strukturierten Aktivitäten. Die atomaren Aktivitä-ten entsprechen einfachen Statements einer Programmiersprache. Atomare Aktivitäten können nicht zur Gruppierung anderer Aktivitäten verwendet werden.

Atomare Aktivitäten:

Assign: Verändern des Inhalts einer Variablen.

Invoke: synchroner (request/response) oder asynchroner Aufruf eines Service.

Receive/Reply: Anbieten einer synchronen oder asynchronen Service-Schnittstelle.

Page 232: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

214 Anhang

Throw: explizites Signalisieren eines Fehlers, der durch Fehlerbehandlungen aufgefan-gen werden kann; wird ein Fehler nicht aufgefangen – erreicht er also den globalen Scope –, so terminiert der Prozess.

Wait: Warten auf einen Zeitpunkt oder für eine Zeitspanne.

Empty: nichts tun, z. B. in einer Fehlerbehandlung nichts tun, um den Fehler auf diese Weise zu unterdrücken.

Strukturierte Aktivitäten lassen die rekursive Komposition von komplexen Prozessen und Workflows zu und steuern den Ablauf eines Prozesses. Die strukturierten Aktivitäten entspre-chen den strukturierten Keywords (if, for, while etc.) einer Programmiersprache. Strukturierte Aktivitäten enthalten immer atomare Aktivitäten zur Ausführung der konkreten Instruktionen in einem Prozessablauf.

Strukturierte Aktivitäten:

Sequence: In einer Sequence werden die Aktivitäten sequentiell abgearbeitet.

While: Ausführen von Aktivitäten, solange eine Boolesche Bedingung erfüllt ist.

Switch: bedingte Ausführung von Aktivitäten.

Flow: Die Aktivitäten werden parallel oder in beliebiger Reihenfolge ausgeführt, wobei Abhängigkeiten durch Links angegeben werden können.

Pick: aus Prozesssicht nicht deterministische Wahl durch externe Ereignisse.

14.5 Use Cases zur Freigabe interdisziplinärer Systeme

Page 233: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Anhang 215

Freigabe eines mechanischen Gesamtsystems

Abbildung 14-4: Use Case „Freigabe eines mechanischen Gesamtsystems“

Freigabe eines gesamten Hardwaresystems

Abbildung 14-5: Use Case „Freigabe eines gesamten Hardwaresystems“

Freigabe eines gesamten Softwaresystems

Abbildung 14-6: Use Case „Freigabe eines gesamten Softwaresystems“

Page 234: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

216 Anhang

Freigabe eines mechatronischen Gesamtsystems

Abbildung 14-7: Use Case „Freigabe eines mechatronischen Gesamtsystems“

Page 235: Integrationsplattform für eine interdisziplinäre ... · Integrationsplattform für eine interdisziplinäre Entwicklung mechatronischer Produkte Dissertation zur Erlangung des Grades

Lebenslauf

Persönliche Angaben Name: Fahmi Bellalouna Geburtsdatum und –ort: 24.05.1974 in Paris / Frankreich Staatsangehörigkeit: deutsch, tunesisch Familienstand: verheiratet, zwei Söhne

Bildungsgang

10/1997 – 07/2002 Studium des Maschinenbaus an der technischen Universität München

Fachrichtung: Informationstechnik, Mechatronik und Konstruk-tionstechnik Abschluss: Diplom-Ingenieur

03/1996 – 03/1997 Einjähriger Deutschkurs am Goethe Institut in Düsseldorf zur

Vorbereitung auf das Studium an deutschen Hochschulen Abschluss: „Prüfungsnachweis Deutsch als Fremdsprache“

10/1993 – 12/1995 Studium der Ingenieurwissenschaft an der Universität Tunis Fachrichtung: Elektronik 10/1980 – 06/1993 Grundschule und Gymnasium in Soliman, Tunesien Abschluss: Abitur

Berufstätigkeiten Seit 01/2009 Oberingenieur am Lehrstuhl für Maschinenbauinformatik (ITM)

der Ruhr-Universität Bochum 01/2006 – 12/2008 Wissenschaftlicher Mitarbeiter am Lehrstuhl für Maschinenbau-

informatik (ITM) der Ruhr-Universität Bochum 10/2002 – 12/2005 Projektingenieur, Fa. DaimlerChrysler AG, Sindelfingen