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

of 235 /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

Embed Size (px)

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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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/

  • 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,88

    6,7 6,7 6,9 7 6,2 6,77,1 7

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

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

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

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

  • 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

  • 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:

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

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

  • 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 mIPInterdisziplinä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-

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

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

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

  • 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

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

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

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

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

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

  • 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]:

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

  • 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):

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

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

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

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

  • 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

  • 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 zu