Integration von Gestaltung und Berechnung mittels CORBA · Integration von Gestaltung und Berechnung mittels CORBA vorgelegt von Diplom { Ingenieur Gregor Haderer aus Berlin Vom Fachbereich

Integration von Gestaltung undBerechnung mittels CORBA

vorgelegt von

Diplom – Ingenieur

Gregor Haderer

aus Berlin

Vom Fachbereich 11 - Maschinenbau und Produktionstechnik

der Technischen Universitat Berlin

zur Erlangung des akademischen Grades

Doktor der Ingenieurwissenschaften

– Dr.–Ing. –

genehmigte Dissertation

Promotionsausschuß:

Vorsitzender: Prof. Dr.-Ing F.-L. KrauseBerichter: Prof. Dr.-Ing. H. MertensBerichter: Prof. Dr.-Ing. M. AbramoviciBerichter: Dr.-Ing. O. Tegel

Tag der wissenschaftlichen Aussprache: 14. Juli 2000

Berlin 2000

D 83

Inhaltsverzeichnis

1 Einleitung 91.1 Entwicklungstrends . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Problemfelder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 CORBA als Integrationsplattform . . . . . . . . . . . . . . . . . . 111.4 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Gestaltung und Berechnung 152.1 Definitionen und Ziele . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Allgemeiner Produktentwicklungsprozeß . . . . . . . . . . 152.1.2 Modelle und Partialmodelle . . . . . . . . . . . . . . . . . 162.1.3 Virtuelle Produktentstehung . . . . . . . . . . . . . . . . . 17

2.2 Klassifizierung von Berechnungsmethoden . . . . . . . . . . . . . 192.3 Modelltechnische Sicht . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Geometriemodelle . . . . . . . . . . . . . . . . . . . . . . . 212.3.2 Modelle fur Berechnungen . . . . . . . . . . . . . . . . . . 222.3.3 Zusammenhange zwischen Geometrie und Ersatzmodellen

fur die Berechnung . . . . . . . . . . . . . . . . . . . . . . 24Allgemeine Verfahren . . . . . . . . . . . . . . . . . . . . . 24Spezielle Verfahren . . . . . . . . . . . . . . . . . . . . . . 25

2.3.4 Semantik in den Modellen . . . . . . . . . . . . . . . . . . 262.4 Prozeßtechnische Sicht . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4.1 Gestaltungsprozeß . . . . . . . . . . . . . . . . . . . . . . 272.4.2 Einordnung von Berechnungen in den Produktentwicklungs-

prozeß . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4.3 Arbeitsschritte beim Berechnen . . . . . . . . . . . . . . . 292.4.4 Auszutauschende Daten . . . . . . . . . . . . . . . . . . . 31

Modelldaten . . . . . . . . . . . . . . . . . . . . . . . . . . 31Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.5 Probleme bei der Integration . . . . . . . . . . . . . . . . . 332.5 Systemtechnische Sicht . . . . . . . . . . . . . . . . . . . . . . . . 34

2.5.1 Mogliche Kopplungsformen . . . . . . . . . . . . . . . . . 342.5.2 Zugriff auf die internen Modelle . . . . . . . . . . . . . . . 35

Programmierschnittstellen . . . . . . . . . . . . . . . . . . 36

1

Inhaltsverzeichnis

Integrationsgrad . . . . . . . . . . . . . . . . . . . . . . . . 36Dateischnittstellen . . . . . . . . . . . . . . . . . . . . . . 37Vernetzung der Systeme . . . . . . . . . . . . . . . . . . . 37

2.5.3 Plattformabhangigkeit . . . . . . . . . . . . . . . . . . . . 382.6 Anwendersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.6.1 Bereitstellung von Berechnungsmethoden . . . . . . . . . . 39Firmeninterne Berechnungsmethoden . . . . . . . . . . . . 39Berechnungsmethoden von externen Partnern . . . . . . . 39

2.6.2 Qualifizierung der Bearbeiter . . . . . . . . . . . . . . . . 392.6.3 Qualitat der Methoden . . . . . . . . . . . . . . . . . . . . 40

2.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Integrationsansatze 433.1 Integrierte Produktentwicklung . . . . . . . . . . . . . . . . . . . 43

3.1.1 STEP - ein integriertes Produktmodell . . . . . . . . . . . 43Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . 43Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.1.2 CAD–Referenzmodell . . . . . . . . . . . . . . . . . . . . . 46Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . 47Referenzarchitektur . . . . . . . . . . . . . . . . . . . . . . 47Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2 Integration von Softwaresystemen . . . . . . . . . . . . . . . . . . 493.2.1 Uberblick uber Client-Server Umgebungen . . . . . . . . . 503.2.2 CORBA - eine Systemarchitektur fur verteilte Objekte . . 51

Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Der Object Request Broker (ORB) . . . . . . . . . . . . . . 52Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . 54Container . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Verteiltes Objektmodell . . . . . . . . . . . . . . . . . . . 56Granularitat . . . . . . . . . . . . . . . . . . . . . . . . . . 56Die Common Object Services . . . . . . . . . . . . . . . . 56Common Facilities – Frameworks . . . . . . . . . . . . . . 58Vorteile gegenuber anderen Ansatzen . . . . . . . . . . . . 58

3.2.3 JAVA als Programmiersprache . . . . . . . . . . . . . . . . 59JAVA Virtual Machine . . . . . . . . . . . . . . . . . . . . 59Portabler Programmcode . . . . . . . . . . . . . . . . . . . 59JAVA und CORBA . . . . . . . . . . . . . . . . . . . . . . 60

3.3 Integrierte Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 613.3.1 Produktdatenmanagementsysteme . . . . . . . . . . . . . . 613.3.2 Feature Modellier–System FEAMOS . . . . . . . . . . . . 613.3.3 Objektorientierter Integrationsprozessor OBIP . . . . . . . 623.3.4 Projekt ANICA . . . . . . . . . . . . . . . . . . . . . . . . 63

2

Inhaltsverzeichnis

Kommunikationssystem . . . . . . . . . . . . . . . . . . . 63Definition einer Zugriffsschnittstelle . . . . . . . . . . . . . 63Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . 63Datenmanagement . . . . . . . . . . . . . . . . . . . . . . 64

3.3.5 Integrationsumgebung CORSICA . . . . . . . . . . . . . . 643.3.6 Konstruktionsanalyse- und Leitsystem KALEIT . . . . . . 653.3.7 Das System mfk . . . . . . . . . . . . . . . . . . . . . . . . 66

Produktmodell . . . . . . . . . . . . . . . . . . . . . . . . 66Integration von Berechnungsmethoden . . . . . . . . . . . 66

3.3.8 iViP–Projekt . . . . . . . . . . . . . . . . . . . . . . . . . 67Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . 67

3.3.9 Virtuelle Berechnungskompetenzzentren . . . . . . . . . . 683.3.10 Vergleich der Systeme . . . . . . . . . . . . . . . . . . . . 69

3.4 Integrationsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . 713.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4 Anforderungen an das Integrationssystem 754.1 Anforderungen der Teilbereiche . . . . . . . . . . . . . . . . . . . 75

Allgemeine Problembeschreibung . . . . . . . . . . . . . . 75Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Programme . . . . . . . . . . . . . . . . . . . . . . . . . . 76Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.2 Anforderungsliste . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 Integrationskonzept fur CAx–Anwendungen auf der Basis von COR-BA 815.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.2 Stand der Standardisierung . . . . . . . . . . . . . . . . . . . . . 825.3 Client–Server–Strukturen . . . . . . . . . . . . . . . . . . . . . . . 83

5.3.1 Zentraler Datenserver . . . . . . . . . . . . . . . . . . . . . 835.3.2 Applikationen als Server . . . . . . . . . . . . . . . . . . . 845.3.3 Client–Server–Strukturen mit CORBA . . . . . . . . . . . 845.3.4 Bewertung der Strukturen . . . . . . . . . . . . . . . . . . 85

5.4 Produktmodellstrukturen . . . . . . . . . . . . . . . . . . . . . . . 865.4.1 Partialmodelle in den Applikationen . . . . . . . . . . . . . 875.4.2 Semantische Verknupfung von Objekten . . . . . . . . . . 885.4.3 Definition eines Strukturmodells . . . . . . . . . . . . . . . 88

Baustruktur . . . . . . . . . . . . . . . . . . . . . . . . . . 89Bezugselemente . . . . . . . . . . . . . . . . . . . . . . . . 89Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Bedingungen und Relationen . . . . . . . . . . . . . . . . . 90

3

Inhaltsverzeichnis

Prozeßinformationen . . . . . . . . . . . . . . . . . . . . . 905.5 Kapselung der Applikationen . . . . . . . . . . . . . . . . . . . . . 91

Einfache Kapselung der Applikationen . . . . . . . . . . . 92CAx-Framework . . . . . . . . . . . . . . . . . . . . . . . . 92

5.6 Systemkonzept fur einfach gekapselte Applikationen . . . . . . . . 935.6.1 Systemstruktur . . . . . . . . . . . . . . . . . . . . . . . . 935.6.2 Anwendungsszenarien . . . . . . . . . . . . . . . . . . . . . 93

5.7 Systemkonzept fur ein CAx-Framework . . . . . . . . . . . . . . . 945.7.1 Produktmodell und Partialmodelle . . . . . . . . . . . . . 95

Referenzstruktur . . . . . . . . . . . . . . . . . . . . . . . 95Assoziationen . . . . . . . . . . . . . . . . . . . . . . . . . 96CAD–Komponenten . . . . . . . . . . . . . . . . . . . . . 97Berechnungskomponenten . . . . . . . . . . . . . . . . . . 97Durchgangiges Prozeßmodell . . . . . . . . . . . . . . . . . 98

5.7.2 Allgemeine und spezielle Dienste . . . . . . . . . . . . . . 98Bereitstellung von Normen . . . . . . . . . . . . . . . . . . 98Hilfesystem . . . . . . . . . . . . . . . . . . . . . . . . . . 99Protokollierung und Dokumentation . . . . . . . . . . . . . 100

5.7.3 Speicherung der Modelle . . . . . . . . . . . . . . . . . . . 1005.7.4 Systemstruktur . . . . . . . . . . . . . . . . . . . . . . . . 1005.7.5 Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.7.6 Implementierung . . . . . . . . . . . . . . . . . . . . . . . 103

Arbeitsschritte . . . . . . . . . . . . . . . . . . . . . . . . 103Erweiterungsmoglichkeiten . . . . . . . . . . . . . . . . . . 103Realisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . 104

5.8 Vergleich der Systemkonzepte . . . . . . . . . . . . . . . . . . . . 104Aufwand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6 Implementierung eines Integrationssystems 1076.1 Ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.1.1 Systemstruktur . . . . . . . . . . . . . . . . . . . . . . . . 1076.1.2 SOM als CORBA–Laufzeitumgebung . . . . . . . . . . . . 109

6.2 Geometriemodellierer . . . . . . . . . . . . . . . . . . . . . . . . . 1106.2.1 Pro/ENGINEER . . . . . . . . . . . . . . . . . . . . . . . 1106.2.2 Schnittstellendefinition des Geometriemodellierers . . . . . 1106.2.3 Implementierungsdetails . . . . . . . . . . . . . . . . . . . 113

Programmodule . . . . . . . . . . . . . . . . . . . . . . . . 113Struktur der Objekte . . . . . . . . . . . . . . . . . . . . . 113

6.3 Berechnungssystem . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.3.1 Schraubenberechnungsprogramm BOLT . . . . . . . . . . 1156.3.2 Struktur der Schnittstelle . . . . . . . . . . . . . . . . . . 115

4

Inhaltsverzeichnis

6.3.3 Implementierungsdetails . . . . . . . . . . . . . . . . . . . 117Programmodule . . . . . . . . . . . . . . . . . . . . . . . . 117Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . 117

6.4 Modellmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186.5 Ablauf einer integrierten Berechnung . . . . . . . . . . . . . . . . 119

6.5.1 Interaktionsdiagramm . . . . . . . . . . . . . . . . . . . . 1196.5.2 Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . 121

ModellManager . . . . . . . . . . . . . . . . . . . . . . . . 1236.6 Variationsmoglichkeiten . . . . . . . . . . . . . . . . . . . . . . . 1286.7 Bewertung des Losungsansatzes . . . . . . . . . . . . . . . . . . . 129

6.7.1 Kopplung der Modelle . . . . . . . . . . . . . . . . . . . . 1296.7.2 Kopplung der Programme . . . . . . . . . . . . . . . . . . 1306.7.3 Kopplung der Prozesse . . . . . . . . . . . . . . . . . . . . 132

6.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

7 Ausblick 1357.1 CORBA als Integrationsplattform . . . . . . . . . . . . . . . . . . 1357.2 Vernetzte Berechnungs–Competence–Center . . . . . . . . . . . . 1367.3 Komponentenbasierte CAx–Systeme . . . . . . . . . . . . . . . . . 137

Glossar 139

5

Inhaltsverzeichnis

6

Abkurzungen

API Application Pogrammers Interface, Schnittstelle eines Softwaresystemsfur den programmgesteuerten Zugriff.

CAE Computer Aided Engineering, computerunterstutztes Berechnen.

CAx Oberbegriff fur rechnerunterstutzte Systeme.

CORBA Common Object Request Broker Architecture.

DCE Distributed Computing Environment.

DCOM Distributed Component Object Model.

DLL Dynamically Linked Library, eine zur Laufzeit gebundene Programm-bibliothek.

FEM Finite Elemente Methode.

FTP File Transfer Protocoll, ein Protokoll fur die Ubertragung von Dateienuber das Internet.

HTML Hypertext Markup Language.

IDL Interface Definition Language, eine systemneutrale Beschreibungsspra-che fur objektorientierte Strukturen.

IIOP Internet Inter–ORB Protocol, ein Protokoll fur die Verknupfung meh-rerer Object Request Broker.

ISO International Organisation for Standardisation.

MKS Mehrkorpersimulationsverfahren.

OMA Object Managing Architecture, die Systemarchtitektur von CORBA.

OMG Object Managing Group, ein Zusammenschluß nicht profitorientierterFirmen und Institutionen zur Forderung der Objekttechnologie. Ent-wickler von CORBA.

7

ORB Object Request Broker.

SOM System Object Model, eine CORBA–Implementierung der Firma IBM.

STEP Standard for Exchange of Product Model Data, ein Produktdatenmo-dell.

SQL Standard Query Language, eine Datenbankabfragesprache.

WWW World Wide Web.

8

1 Einleitung

Die Entwicklung von technischen Produkten ist mit einer Vielzahl von Tatig-keiten verbunden. Dabei nehmen die Tatigkeiten Gestalten und Berechnen be-sondere Rollen ein. Bei der Gestaltung wird aus einem Konzept oder Entwurferstmals eine geometrisch stoffliche Gestalt festgelegt. Die Gestaltung ist damiteine der wesentlichen schopferischen Tatigkeiten des Ingenieurs. Bei der Berech-nung hingegen wird versucht, das Verhalten des realen oder geplanten Produktsvorherzusagen, indem in Form von Ersatzmodellen bestimmte Annahmen bezug-lich der Eigenschaften des Produkts gemacht werden. Je nach Aufgabenstellungund Konkretisierungsgrad konnen dabei im Laufe des Entwicklungsprozesses sehrunterschiedliche Ersatzmodelle zum Einsatz kommen, die jeweils eine eigene Sichtauf das Produkt darstellen.

Gestaltung und Berechnung sind seit jeher zwei eng miteinander verknupfte Ta-tigkeiten. Die Verknupfungen bestehen einerseits in den gemeinsam genutztenModellen und andererseits in den wechselseitigen Abhangigkeiten, die sich ausverschiedenen Auslegungs- und Nachweisrechnungen zwischen dem Gestaltmo-dell und den verwendeten Rechenmodellen ergeben. Bedingt durch die bei einerBerechnung erforderliche Abstraktion oder Reduktion auf ein Ersatzmodell, iststets eine Transformation zwischen einem Gestaltmodell und einem zugehorigenRechenmodell und umgekehrt erforderlich.

Fur beide der oben genannten Tatigkeiten stehen inzwischen leistungsfahige Soft-waresysteme fur eine rechnerunterstutzte Durchfuhrung zur Verfugung. Aller-dings sind die Entwicklungen bisher weitgehend isoliert abgelaufen, mit der Kon-sequenz, daß die entwickelten Systeme nicht miteinander operieren konnen. Furdie Durchfuhrung von in den Gestaltungsprozeß integrierten Berechnungen be-deutet dies, daß die oben genannten Transformationen durch den Bearbeitervorgenommen werden mussen. Der dafur erforderliche Zeitaufwand, sowie diemoglichen Fehlerquellen, bedingt durch Ubertragungsfehler, Redundanzen undInkonsistenzen sind fur einen effizienten Entwicklungsprozeß nicht tragbar. Ausdieser Erkenntnis entsteht die Forderung, die bestehenden Programme in ein Sy-stem zu integrieren, mit dem eine durchgangig rechnerunterstutze Durchfuhrungvon Gestaltung und Berechnung moglich ist.

9

1 Einleitung

1.1 Entwicklungstrends

Die derzeitigen Entwicklungen im Bereich der rechnerunterstutzten Produktent-wicklung verstarken den Bedarf nach einem Integrationsansatz, der es ermog-licht, Softwaresysteme fur die Bearbeitung verschiedener Teilaufgaben zu einemGesamtsystem zusammenzufugen. Wesentliche Veranderungen sind dabei sowohlin der Organisation der Entwicklungsprozesse als auch in den Moglichkeiten derRechnerunterstutzung festzustellen. Die Forderung nach einer Verkurzung derEntwicklungszeiten wird vielfach durch eine Parallelisierung der Arbeitsschrit-te in Form von Simultaneous Engineering erfullt. Ein effizientes Arbeiten mitverteilten Modellen ist aber nur moglich, wenn den verschiedenen Entwicklungs-arbeitsplatzen dieselbe Datenbasis zur Verfugung steht. Daher ist die Anwendungvon Simultaneous Engineering haufig mit der Einfuhrung von Produktdatenma-nagementsystemen verbunden. Verscharft wird diese Problematik dadurch, daßverstarkt Entwicklungsleistungen an Zulieferer abgegeben werden.

Seitens der Rechnerunterstutzung ergeben sich durch die in jungster Zeit erfolg-te nahezu flachendeckende Vernetzung der bestehenden Computersysteme volligneue Formen der Kooperation. Zusammen mit entstehenden Standards fur dieKommunikation zwischen verschiedenen Systemen sind Kopplungen vorstellbar,die uber einen bloßen Dateiaustausch weit hinausgehen.

Versionswechsel bei den verwendeten Betriebssystemen fuhren, zusatzlich zu derbereits vorhandenen Vielfalt, zu einer noch großeren Zahl systemspezifischer Soft-ware. Dabei stellt die Wartung und Portierung bestehender Softwaresystemeeinen erheblichen Aufwand dar.

Die Entwickler von CAD–Systemen versuchen entwicklungsprozeß- und fachdis-ziplinubergreifende Anwendungen zu schaffen. Vielfach werden zu einem CAD–System Produktdatenmanagmentsysteme mit einer hohen Interoperabilitat undModule fur die fruhen Phasen und die nachgelagerten Phasen der Entwicklungangeboten. Die schnelle Entwicklung auf diesem Gebiet fuhrt zu haufigen Release-wechseln und damit zu einem erheblichen Anpassungsaufwand fur die bestehendeSoftware.

Die Berechnungssoftware hingegen besteht haufig aus problemspezifischen Ent-wicklungen, die oft an eine vorhandene Systemumgebung angepaßt sind. Die Bi-bliothek von Berechnungsprogrammen kann somit einen betrachtlichen Teil desWissens in einem Unternehmen darstellen.

1.2 Problemfelder

In bezug auf die Integration von Berechnungen in den Gestaltungsprozeß erge-ben sich durch die genannten Entwicklungstrends einige Problemfelder. Insbe-sondere die Anbindung bestehender Berechnungssysteme an haufig wechselndeVersionen der aktuellen Geometriemodellierer bereitet Schwierigkeiten. Grun-

10

1.3 CORBA als Integrationsplattform

de fur diese Schwierigkeiten sind hauptsachlich das Fehlen von standardisiertenZugriffsschnittstellen und die Vielfalt bestehender Berechnungssoftware. Die Ent-wicklung von Berechnungsprogrammen fur spezielle Probleme fuhrt oft zu schwerwartbaren Systemen, die an eine Rechnerplattform gebunden sind. Die fehlendeInteroperabilitat, sowohl zwischen verschiedenen CAD–Systemen als auch zwi-schen Berechnungssystemen und Geometriemodellierern, erschwert die Schaffungvon durchgangig rechnerunterstutzten Entwicklungsprozessen.

In der vorliegenden Arbeit wird ein Losungsansatz fur die Integration von Maschi-nenelementberechnungen in den Gestaltungsprozeß vorgestellt. Fur die Berech-nung von Maschinenelementen stehen in der Regel durchgehend parametrisierteBerechnungsmethoden zur Verfugung, sodaß eine Kopplung der Geometriemodel-le mit den zugehorigen Rechenmodellen zunachst einfach erscheint. Maschinen-elemente werden aber meist in einer individuell gestalteten Umgebung eingesetzt,deren Merkmale in Eingangsgroßen fur die Berechnung ubersetzt werden mussen.Dabei sind fur die Berechnung oft Modellausschnitte oder spezielle Sichten aufdie Umgebung erforderlich. Fur eine Kopplung mussen daher neben Funktionenzur Identifizierung von Norm- und Standardteilen Methoden fur die Generierungder Sichten verfugbar sein. Fur eine Integration mussen die Modelle und derenVerknupfungen, sowie die Prozeßschritte zum Wechseln der Modelle untersuchtwerden. Die Problematik wird anhand der Berechnung von Schraubenverbindun-gen verdeutlicht.


Ein umfassender Losungsansatz fur eine Integration von Gestaltung und Berech-nung muß sich in die oben beschriebene, im Entstehen begriffene Systemland-schaft einfugen und zugleich offen sein fur zu erwartende Entwicklungen. DerLosungsansatz muß plattformubergreifend und netzwerkfahig sein und eine An-bindung bestehender Softwaresysteme, inbesondere der zahlreichen oft in Eigen-entwicklung entstandenen Berechnungsprogramme, ermoglichen.

Im Bereich Informationstechnik wird derzeit mit CORBA ein Standard ent-wickelt, der es ermoglicht, verschiedene Softwaresysteme miteinander zu koppeln,indem die beteiligten Programme uber neutrale, objektorientierte Schnittstellen-beschreibungen gekapselt und in das System integriert werden. CORBA stehtfur Common Object Request Broker Architecure. Fur die Kommunikation zwi-schen den beteiligten Systemen und die Verwaltung der Objekte sind in CORBAzahlreiche Dienste in Form von standardisierten Methoden definiert. Damit istCORBA ein Losungsansatz, der viele der oben genannten Forderungen zu erfullenverspricht.

Die Struktur von CORBA laßt dabei unterschiedliche Formen der Integrationzu, die sich hinsichtlich des Realisierungsaufwands und der erzielbaren Vortei-le unterscheiden. In dieser Arbeit wird untersucht, welche Integrationsformen

11

1 Einleitung

sinnvoll sind und inwieweit CORBA tatsachlich fur die Integration von Gestal-tungssoftware und Berechnungssoftware geeignet ist. Aus den Anforderungen anein Integrationssystem und den sich durch CORBA ergebenden Moglichkeitenwerden in der Arbeit zwei Integrationskonzepte abgeleitet und verglichen. Vonden zwei Konzepten wird eins aufgegriffen und implementiert. Aus dem Vergleichmit den gestellten Anforderungen und den Erfahrungen aus der Implementierungergibt sich, daß CORBA als Integrationsplattform grundsatzlich geeignet ist, daes einen sehr flexiblen Zugriff auf die angebundenen Systeme ermoglicht, daß aberdennoch ein gewisser Aufwand in den Bereichen Modellintegration und Prozeßin-tegration betrieben werden muß.

1.4 Gliederung der Arbeit

Im einfuhrenden Kapitel 2 werden die Zusammenhange der Arbeitsschritte Ge-stalten und Berechnen analysiert. Dabei wird auf die bestehenden Softwaresy-steme, auf die verwendeten Modelle, die Einordnung in den Entwicklungsprozeßund auf die bei einer Integration auftretenden Probleme eingegangen.In Kapitel 3 werden bestehende Losungsansatze fur verschiedene Ebenen derIntegration vorgestellt. Dabei werden aktuelle Konzepte der integrierten Pro-duktentwicklung, ausgewahlte Integrationssysteme sowie Standards fur die Inte-gration von Softwaresystemen behandelt. In diesem Kapitel wird auch die Inte-grationsumgebung CORBA vorgestellt. Aus den beschriebenen Ansatzen werdenallgemeine Integrationsstrategien abgeleitet.Aus den Merkmalen der Arbeitsschritte Gestalten und Berechnen und den Lo-sungsansatzen werden in Kapitel 4 Anforderungen an ein Integrationssystem for-muliert.Die Losung der Integrationsaufgabe bei Verwendung von CORBA als Kommuni-kationsplattform wird in Kapitel 5 beschrieben. In einem einleitenden Abschnittwerden die grundlegenden Merkmale einer CORBA–basierten Arbeitsumgebungerlautert. Nach einem Uberblick uber den Stand der Standardisierung im Bereichverteilte CAx–Umgebungen werden ausfuhrlich die verschiedenen Strukturen undKomponenten eines CORBA-basierten Integrationssystems vorgestellt. Abschlie-ßend werden zwei realisierbare Systemkonzepte fur eine einfache Kopplung undfur einen integrierten Entwicklungsarbeitsplatz prasentiert.Eine Implementierung der in Kapitel 5 entwickelten einfachen Kopplung wirdin Kapitel 6 beschrieben. Das implementierte System wird in bezug auf die inKapitel 4 gestellten Anforderungen bewertet.Zusammenfassende Betrachtungen uber die durchgefuhrten Arbeiten, die prakti-sche Anwendbarkeit der Ergebnisse und die zu erwartenden Entwicklungen schlie-ßen im Kapitel 7 die Arbeit ab.Bild 1.1 zeigt eine Ubersicht uber die Gliederung der Arbeit.

12

1.4 Gliederung der Arbeit

SystemstrukturenProduktmodellStandards

SystemstrukturSchnittstellenImplementierung

7.Ausblick

ModelleProzesseProgrammeIntegrationsprobleme

Merkmale der Arbeitsschritte

5.CORBA alsIntegrationsplattform

6.Implementierung einesIntegrationssystems

4.Anforderungen an einIntegrationssystem

IntegrationssystemeStandards

Konzepte

DatenaustauschSicherheitImplementierung

Berechnungs Competence CenterKomponentenbasierte CAx-Systeme

CORBA als Integrationsplattform

Kapitel Inhalt

1. Einleitung

3. Integrationsansätze

Übersicht

strategienIntegrations-

Integrationssystem

Ergebnisse

2.BerechnungGestaltung und

zwei Integrations-konzepte

Bild 1.1: Gliederung der Arbeit

13

1 Einleitung

14

2 Gestaltung und Berechnung

In diesem Kapitel werden Merkmale von Maschinenelementberechnungen, ihreZiele und die Eingliederung in den Produktentwicklungsprozeß erlautert. Da-bei wird insbesondere auf die modelltechnischen, die prozeßtechnischen und pro-grammtechnischen Probleme im Hinblick auf eine rechnertechnische Integrationvon Berechnungen in den Gestaltungsprozeß eingegangen.

2.1 Definitionen und Ziele

2.1.1 Allgemeiner Produktentwicklungsprozeß

Das generelle Vorgehen beim Entwickeln und Konstruieren wird in der VDI Richt-linie 2221 [VDI93] angegeben. Das in der Richtlinie vorgeschlagene Schema teiltden vollstandigen Entwicklungsprozeß in die vier Phasen: Klaren der Aufgabe,Konzeptphase, Entwurfsphase und Ausarbeitungsphase (vgl. Bild 2.1). Das Kla-ren der Aufgabe dient der Beschaffung von Informationen uber Anforderungen,die an die Losung gestellt werden, sowie an bestehende Bedingungen und de-ren Bedeutung. Das Ergebnis dieses Arbeitsschrittes, die Anforderungsliste, istArbeitsgrundlage und Informationsquelle fur alle nachfolgenden Arbeitsschritte.

Beim Konzipieren werden durch Abstraktion der Anforderungen die wesentlichenProbleme der Aufgabenstellung herausgearbeitet. Durch Aufstellen einer Funkti-onsstruktur und durch Suche nach geeigneten Wirkprinzipien und deren Kombi-nation in einer Wirkstruktur wird eine prinzipielle Losung erarbeitet, in der diewesentlichen Komponenten zur Realisierung des Produkts erkennbar sind. Dabeikann die prinzipielle Losung auch schon eine geometrische Festlegung enthalten[PB97].

Die gestalterische Festlegung der Losung erfolgt in der Entwurfsphase. Ausgehendvon der prinzipiellen Losung wird in diesem Arbeitsschritt die Baustruktur nachtechnischen und wirtschaftlichen Gesichtspunkten erarbeitet. Das Ergebnis die-ses Schrittes, der Gesamtentwurf, enthalt alle Informationen, um eine Kontrolleder Funktion, der raumlichen Vertraglichkeit, der Haltbarkeit und der angestreb-ten Kosten zu ermoglichen. Die geometrische Beschaffenheit des Produkts wirdmaßgeblich in diesem Arbeitsschritt festgelegt.

Im abschließenden Arbeitsschritt, der Ausarbeitung, erfolgt die endgultige Festle-

15


Anforderungsliste

Prinzipielle Lösung

Gesamtentwurf

Produktdokumentation

Konstruktionsphase Ergebnis

I

II

III

IV

Entwerfen

Konzipieren

Klären der Aufgabe

Ausarbeiten

Bild 2.1: Phasen und Arbeitsergebnisse des Konstruktionsprozesses (in Anleh-nung an [VDI93])

gung aller Details, die fur die Herstellung des Produktes erforderlich sind. Dazugehoren die detaillierte Festlegung der Form, der Werkstoffe, der Oberflache unddes Fertigungsprozesses. Ergebnis dieses Arbeitsschrittes ist die Produktdoku-mentation.Je nach Aufgabenstellung konnen die einzelnen Ergebnisse mehr oder wenigerausfuhrlich ausgefuhrt sein. Untersuchungen in der Praxis haben gezeigt, daßdas Schema nur sehr selten mit allen angegeben Schritten durchlaufen wird, daßsich aber die meisten Vorgehensweisen in das Schema einordnen lassen [Ruc97].Die aktuelle Forschung zielt darauf ab, die Entwicklungstatigkeiten in Form einerintegrierten Produktentwicklung durchzufuhren. Integrierte Produktentwicklungkann als zielorientierte Kombination organisatorischer, methodischer und tech-nischer Maßnahmen und Hilfsmittel definiert werden [Mee98]. In zahlreichenForschungsvorhaben wird zur Zeit versucht, den allgemeinen Entwicklungspro-zeß durchgangig rechnerunterstutzt durchzufuhren. Eine Auswahl bestehenderLosungsansatze ist in Kapitel 3 beschrieben.

2.1.2 Modelle und Partialmodelle

Das Vorgehen beim Entwickeln und Konstruieren wird durch verschiedene Mo-delle unterstutzt. Die Modelle konnen dabei Produkte oder Prozesse oder beidesbeschreiben, sie konnen eine vollstandige Beschreibung oder nur einen Ausschnitt

16

2.1 Definitionen und Ziele

enthalten und konnen als Denkmodelle des Bearbeiters existieren oder als rechner-interne Modelle in Softwaresystemen bestehen. Tabelle 2.1 gibt einen Uberblickuber allgemeine und in die in der vorliegenden Arbeit verwendeten Modellbegriffe.

Im Bereich der rechnerunterstutzten Produktentwicklung kommt den integrier-ten Modellen eine besondere Bedeutung zu. Definitionsgemaß sollen sie in derLage sein, samtliche im Produktlebenszyklus anfallenden Daten abzubilden. Siewerden damit zum zentralen Integrationswerkzeug, da samtliche Softwaresyste-me das integrierte Produktmodell als Datenbasis verwenden. Das Modell muß sofestgelegt und beschrieben werden, daß es die Funktionen der Produktdatenverar-beitung unterstutzt. In [GAP93] werden folgende zu unterstutzende Funktionengenannt:

• der Produktdatenaustausch

• die Produktdatenspeicherung

• die Produktdatenarchivierung und

• die Produktdatentransformation.

2.1.3 Virtuelle Produktentstehung

Von Industrie und Forschungseinrichtungen wird derzeit die virtuelle Produktent-stehung als Ziel formuliert. Die zentrale Vision der virtuellen Produktentste-hung besteht darin, eine vollkommen neuartige Grundlage fur den Produktent-stehungsprozeß von der initialen Produktplanung uber die Produktkonstruktionund –erprobung bis hin zum Fertigungsanlauf zu realisieren. “Virtuell”bezeichnethierbei die uber alle Phasen durchgangig digitale Produktentstehung mittels drei-dimensionaler Modelle uber Unternehmensgrenzen und Standorte hinweg. UnterEinbeziehung innovativer Technologien wie Multimedia und Virtual Reality (VR),sowie zukunftsorientierter Organisations–, Kommunikations– und Informations-systeme entsteht das “virtuelle Produkt” auf der Basis eines umfassenden 3D–Modells, zur Simulation aller Eigenschaften, Funktionen und Entstehungsphasen,visualisiert mit Hilfe von VR–Techniken, getestet und erprobt auf dem virtuellenPrufstand [KTA98]. Das Konzept der durchgangig digitalen Produktenstehungerfordert neue Konzepte fur die Integration der am Entwicklungsprozeß beteilig-ten Werkzeuge und umfassende Ansatze zur Steuerung des verteilten Prozesses.Ein großangelegtes Forschungsvorhaben hat sich die Schaffung einer Arbeitsum-gebung fur die virtuelle Produktentstehung zum Ziel gesetzt. Einzelheiten sindin Abschnitt 3.3.8 beschrieben.

17


Begriff Definition

Modell (allg.) Abstrakte Abbildung eines Ausschnittes der realenWelt mit dem Ziel, von Eigenschaften des Modellsauf Eigenschaften des realen Objekts zu schlie-ßen [VDI93] [Rot82]. Im Kontext von Software-programmen: als Datenmodell strukturelle Daten-menge zur rechnerinternen Reprasentation einesWeltausschnittes [Abe95].

Ersatzmodell Abstraktion eines realen oder geplanten Produktsdurch Reduktion auf eine Auswahl von Eigenschaf-ten. Ein Ersatzmodell wird verwendet, um dasVerhalten des Produkts durch Vereinfachung be-rechenbar und damit vorhersagbar zu machen.

Produkt-informations-modell

(Auch: konzeptionelles Modell) Definiert die mog-lichen Bestandteile und denkbaren Relationen zwi-schen den Bestandteilen fur eine Abbildung einesModells im Rechner [Boo94].

Produktmodell Die Einheit von Produktinformationsmodell undaller zu einem Produkt gehorenden Daten [Abe95].

IntegriertesProdukt-modell

Produktmodell fur die Abbildung von Daten ausallen Produktlebensphasen in einem einheitlichenDatenmodell [GAP93]. Ein kontinuierliches Fort-schreiben der Daten soll die informationsverlust-behaftete Modelltransformation verhindern. Indem Modell werden alle Daten abgebildet, die sichnicht aus bereits bestehenden Daten ableiten las-sen [Vel99].

Partialmodell Kennzeichnet eine definierte endliche Informati-onsmenge von Produktmerkmalen als Teil einesProduktmodells [Abe95] [Gra99].

Geometriemodell Hier: Rechnerinterne Darstellung der Geome-triedaten in einem Geometriemodellierer (CAD–System).

Rechenmodell Hier: Rechnerinterne Darstellung der Daten einesBerechnungsprogramms.

Strukturmodell Hier: Produktinformationsmodell fur die Integra-tion von Gestaltung und Berechnung. EnthaltAusschnitte aus einem Geometriemodell und ei-nem Rechenmodell und die fur die Verknupfungder Modelle erforderlichen Informationen.

Tabelle 2.1: Definitionen der wichtigsten Modellbegriffe

18

2.2 Klassifizierung von Berechnungsmethoden

2.2 Klassifizierung von Berechnungsmethoden

In diesem Abschnitt werden bestehende Klassifizierungen fur Berechnungen vor-gestellt. Die gefundenen Merkmale werden in den nachfolgenden Abschnittenaufgegriffen und in einer der drei Sichten, modelltechnische Sicht, prozeßtechni-sche Sicht oder systemtechnische Sicht detaillierter behandelt.In der Literatur existieren verschiedene Klassifizerungsansatze fur Berechnungs-methoden. Die VDI Richtlinie 2211 [VDI80] nennt die Genauigkeit, die Komple-xitat und die Haufigkeit der Benutzung als Unterscheidungsmerkmale. Die in derRichtlinie gezogenen Konsequenzen sind bezogen auf die heutige Rechnertechniknicht mehr zeitgemaß, weshalb die Richtlinie inzwischen zuruckgezogen wurde.Von Mertens [Mer98] wurde ein Klassifizierungsschema entwickelt, in dem Be-rechnungsmethoden nach Aufwand und Aussagegute in jeweils drei Klassen ein-geordnet werden konnen (vergleiche Bild 2.2). Dabei bezeichnet die Klasse AMethoden, die eine hohe Aussagegute und einen hohen Berechnungsaufwand oderModellierungsaufwand haben und in der Regel nur von einem Experten bearbei-tet werden konnen. Verfahren der Klasse B erfordern hingegen einen gegenuberA-Methoden verminderten Aufwand bezuglich Aufwand und Laufzeit, benotigenaber immer noch einen auf dieses Themengebiet spezialisierten Bearbeiter furdie Modellierung und die Interpretation der Ergebnisse. Berechnungsverfahren,die als allgemein bekannt vorausgesetzt werden konnen oder die in bekanntenRichtlinien oder anderen Quellen veroffentlicht wurden und bezuglich Laufzeitund Aussagegute gering eingestuft werden konnen, sind in die Klasse C einzu-ordnen. Fur die verschiedenen Verfahren existieren auch Zwischenstufen, wennbeispielsweise Methoden mit kurzer Laufzeit eine hohe Aussagegute besitzen. DasBestreben von Berechnungsabteilungen und Forschungseinrichtungen geht dahin,moglichst viele der bisher den Experten vorbehaltenen Verfahren durch entspre-chende Anpassungen auf eine B- oder C–Ebene zu bringen und damit weiterenAnwendern zuganglich zu machen. Die Uberfuhrung in C-Methoden bedeutetauch, daß die Randbedingungen so klar definiert sein mussen, daß fur die Mo-dellbildung kein Expertenwissen mehr erforderlich sein darf. Dies erhoht zugleichdie Chance, Teile der Modellbildung zu automatisieren.Die Ingenieurdisziplinen Mechanik, Fluidik, Thermodynamik, Warmeubertragung,Optik, Elektrotechnik und Akustik werden von Koller in [Kol98] fur die Unter-scheidung von Berechnungsverfahren herangezogen. Koller unterscheidet weiterin allgemeine, das heißt, fur alle Produkte geltende Verfahren, die sich meistaus physikalischen Gesetzen ergeben, und in spezielle, auf ein Produkt oder ei-ne Produktgruppe abgestimmte Verfahren, die sich aus einer produktspezifischenAnpassung der allgemeinen Verfahren ergeben.Eine Klassifizierung, die sich an dem Ziel und den Ergebnissen einer Berechnungorientiert, wird von Galwelat vorgenommen. Dort werden Auslegungsrechnungenoder Dimensionierungen, Nachweisrechnungen, Optimierungen und Vergleichs-rechnungen unterschieden [Gal80].

19


B AC

B

A

C

Zeitaufwand

Aus

sage

güte

C

B

B

A

Berechnungs- und Bewertungsmethoden Berechnungs- und Bewertungsmethoden

B AC

B

A

C

Zeitaufwand

Aus

sage

güte

C

B

C(B)

C(A)

(produktbezogen)(allgemein)

B

A

C(A)-Methoden für Produkte und Produktklassen

Zielvorgabe

Bild 2.2: Klassifizierung von Methoden nach Zeitaufwand und Aussagegute[MW99]

Im Hinblick auf eine Integration in den rechnerunterstutzten Gestaltungsprozeßist auch die Integrierbarkeit ein Klassifizierungsmerkmal. In diesem Zusammen-hang ist Methode als implementiertes Programm auf einem Rechner zu verstehen.In [Wol98] werden Methoden, deren Quellcode und deren Ein– und Ausgabepara-meter bekannt und programmatisch zuganglich sind, als direkt integrierbar, undMethoden, die nur als ubersetztes Programm mit nicht veranderbarem Ablauf,aber bekannter Parameterstruktur vorliegen als indirekt integrierbar bezeichnet.Als lose integrierbar werden Methoden bezeichnet, die in Gestalt von komplexenCAE–Systemen eine detaillierte Modelldefinition und Parameterermittlung furjede einzelne Berechnung erfordern.

Eine Klassifizerung, in der auch eine grobe Zuordnung zu den Phasen des Ent-wicklungsprozesses vorgenommen wird, ist in [Lof97] beschrieben. Dort werdenparameterorientierte Dimensionierungs- und Auslegungsrechnungen der Konzept-phase, allgemeine Modelle der technischen Mechanik (MTM), beispielsweise Bal-ken oder Platten, der Entwurfsphase und detaillierte FE–Berechnungen der Aus-arbeitungsphase zugeordnet.

Eine Ubersicht uber die genannten Merkmale ist in Bild 2.3 dargestellt.

20

2.3 Modelltechnische Sicht

Berechnungen

ModelltypGeometriemodellParameterFinite-Elemente

MechanikFluidikFEMCFD

Allgemein SpeziellMaschinenelementeSchraubenWelle-Nabe Verb.

EigenschaftenAussagegüte

ZielAuslegungFestigkeitsnachweisOptimierung

Prozeßeigenschaften

Ein

gang

sgrö

ßen

Erg

ebni

sse

Quellen

Komplexität

Aufwand

Integrierbarkeit

ModelleNormenVersuchswerteTabellenDiagramme Laufzeit

ArtModelleParameterÄnderungs-

Anwendungsgebiete

anforderungen

Bild 2.3: Merkmale von Berechnungen


Um Produktentwicklung rechnerunterstutzt betreiben zu konnen, wurden fur dieObjekte, die Gegenstand der Entwicklung sind, Produktinformationsmodelle ge-schaffen, in denen die Eigenschaften der Objekte abgebildet werden konnen. Indiesem Abschnitt werden die Eigenschaften der in den bestehenden Program-men vorhandenen Modelle beschrieben und die Probleme bei einer Integrationzusammengestellt.Integrierte Modelle kommen zur Zeit nur in Forschungssystemen zum Einsatz(vgl. Kapitel 3) und sind fur die bestehenden Programme noch nicht einsetzbar.Allerdings zielen die aktuellen Entwicklungen im Bereich CAD–Systeme daraufab, die Programme zu prozeßubergreifenden Universalwerkzeugen zu machen unddamit die internen Modelle in Richtung eines integrierten Produktmodells wei-terzuentwickeln.

2.3.1 Geometriemodelle

Der wesentliche Gegenstand der Gestaltung ist die Geometrie. Insofern sind dieGeometriemodelle die Arbeitsmodelle bei der Gestaltung. Fur die rechnerunter-

21


stutzte Durchfuhrung dieses Arbeitsschrittes stehen mit den modernen CAD–Systemen leistungsfahige Werkzeuge zur Verfugung, die umfangreiche interneDarstellungen des Modellierungsgegenstandes enthalten.Grundsatzlich konnen Geometriemodelle in B–Rep und CSG–Modelle unterschie-den werden. In B–Rep Modellen (Boundary Representation) wird ein geometri-sches Objekt durch seine Umrandungsflachen beschrieben. Diese Modellierungs-art wird haufig fur Freiformflachen verwendet.Im Gegensatz dazu werden CSG–Modelle (Constructive Solid Geometrie) beschrieben, indem von einem Grundkor-per durch boolsche Volumenoperationen Formelemente entfernt oder hinzugefugtwerden. Im Vergleich zu B–Rep Modellen bieten CSG–Modelle die Moglichkeit,die Entwicklungshistorie des Modells zu speichern und so auch Modifikationenam Modell ruckgangig zu machen.Stand der Technik sind derzeit parametrische 3-D Modelle, die je nach Aufga-benstellung als Flachenmodelle oder Volumenmodelle oder auch parallel in denSystemen verwaltet werden. Bei diesen Modellen werden die geometrischen Ei-genschaften des abgebildeten Objekts durch benannte Variablen, die Parameter,beschrieben. Parameter konnen nachtraglich verandert und zueinander in Be-ziehung gesetzt werden. In Verbindung mit Features, die in diesem Kontext alsKonstruktionselemente zu verstehen sind, lassen sich die Modelle schnell und ko-stengunstig im Rechner erzeugen [Gra99]. Uber die Benutzungsschnittstelle undzum Teil auch uber die Programmierschnittstelle hat man Zugriff auf die rechner-interne Darstellung der geometrischen Objekte. Leistungsfahige Programme wiePro/ENGINEER oder IDEAS bieten dabei sowohl Zugriffsmoglichkeiten auf reingeometrische Informationen, wie auf Punkte, Kanten, Flachen, und deren Eigen-schaften als auch auf die logischen Verknupfungen von Konstruktionselementenund Bauteilen [Par97].Die aktuellen Entwicklungen zielen darauf ab, sowohl die fruhen Phasen als auchdie der Gestaltung nachgelagerten Arbeitsschritte durch zusatzlich im Modell ab-gelegte Informationen zu unterstutzen. Ziel ist dabei immer, eine durchgangigeRechnerunterstutzung des Prozesses ohne Systemwechsel zu ermoglichen. Par-allel dazu werden die Systeme zunehmend fur die Anwendung im SimultaneousEngineering weiterentwickelt.

2.3.2 Modelle fur Berechnungen

Bauteilberechnungen liegt in der Regel ein physikalisches Ersatzmodell zugrunde.Im Bereich Maschinenbau bestehen diese Ersatzmodelle aus geometrischen Kom-ponenten, denen in Bezug auf die zu untersuchende Eigenschaft ein bestimmtesVerhalten unterstellt wird. Je nach Verfahren und Stand der Forschung konnendiese Komponenten komplette Baugruppen, einzelne Bauteile, Zonen eines Bau-teils oder die Elemente eines Finite-Elemente Netzes sein. Die Verknupfungenzwischen den Komponenten werden mit Hilfe von Bedingungen formuliert. DasVerhalten der Komponenten wird durch Formeln oder Algorithmen beschrieben.

22


Die Eigenschaften der einzelnen Komponenten konnen durch Parameter beschrie-ben werden.

Mit der oben gefundenen Aufteilung in geometrische Komponenten, Bedingungenund Parametern lassen sich die numerischen Verfahren wie FEM (Finite Elemen-te Methode) oder MKS (Mehrkorper Simulation) gut beschreiben: die FinitenElemente und die starren Korper bilden die geometrischen Komponenten, dieuber Rand- und Ubergangsbedingungen miteinander verbunden sind. Die Ei-genschaften der einzelnen Komponenten werden durch Parameter und Formelnbeschrieben. Der Ubergang vom realen Produkt zum Rechenmodell erfolgt, in-dem das System in viele gleichartige Elemente mit einfacher Struktur zerlegt wird.Ausgehend von einer vorhandenen geometrischen Struktur ist eine Zerlegung fastimmer moglich und die physikalischen Zusammenhange sind bekannt.

Rechenverfahren, die nur fur eine ganz bestimmte Gruppe von Maschinenele-menten geeignet sind, lassen sich bezuglich der Eingabeparameter mit Hilfe derzugrundeliegenden Baustruktur gliedern. Dabei ist der Gultigkeitsbereich entwe-der in Form der verwendeten Normteile oder in Form von Gultigkeitsbereicheneinzelner Parameter des Ersatzmodells angegeben. Fur die Ermittlung der Para-meter ist oft nicht die gesamte Geometrie erforderlich, sondern eine Auswahl voncharakteristischen Bezugselementen. Alle Eingabeparameter lassen sich in derRegel einer Baugruppe, einem Bauteil oder einem geometrischen Objekt einesBauteils (beispielsweise einer Flache oder einer Kante) zuordnen. Daruberhinauswerden diese Rechenverfahren oft in mehrere Rechenschritte unterteilt.

Die Parameter selber lassen sich in weitere Merkmalsgruppen einteilen. Einemogliche Unterteilung ist die Zusammenstellung der Produktmerkmale, wie sievon Pahl und Beitz in [PB97] vorgenommen wurde. In Bild 2.4 sind die Merk-malsgruppen zusammengestellt, die fur die Berechnung von Schraubenverbindun-gen nach der VDI–Richtlinie 2230 [VDI86] benotigt werden. Man erkennt, daßzahlreiche Parameter aus anderen Bereichen wie Fertigung oder Montage Ein-fluß auf das Rechenergebnis haben. Beispiele hierfur sind der Einfluß der bei derFertigung erzielbaren Oberflachenrauhigkeiten auf den Setzbetrag einer Schrau-benverbindung oder die Vorgabe eines bestimmten Werkzeuges bei der Montage.

Ein großer Teil der Parameter laßt sich bei Verwendung von Norm– und Stan-dardteilen aus den entsprechenden Norm– und Regelwerken ermitteln. Oft sindfur genormte Komponenten Tabellenwerke angegeben und fur individuelle Struk-turen die entsprechenden Formeln als zusatzlicher Rechenschritt angegeben.

Typisch fur die spezifischen Rechenverfahren ist auch, daß es eine Reihe vonParametern gibt, fur die nur in diesem Kontext gultige Tabellen oder Nahe-rungsformeln existieren, die von den allgemein bekannten Quellen abweichen.Beispielsweise existieren spezielle Tabellen mit zulassigen Flachenpressungen beiSchraubenverbindungen [VDI86].

Tabelle 2.2 zeigt einen Uberblick uber die Quellen von in Berechnungen verwen-deten Parameter und ihrer typischen Eigenschaften.

23


AuslegungsrechnungenErsatzmodelle

Anforderungsliste

� � � � � ��

� � � � � ��

� � � � � � ��

� � � � � ��

� � � � � � ��

� � � � � ��

� � � � � � ��

� � � � � � ��

Geometr.Ersatz-modell

Montage

Lasten

Werkstoff

Fertigung

Sicherheit

Anforderungsliste

Geometriemodell

Montagemodell

Normen

Versuchswertemethodenspez. Werte

Tabellenwerke

FertigungsunterlagenAnforderungsliste

Bild 2.4: Parameter und deren Quellen bei Bauteilberechnungen

2.3.3 Zusammenhange zwischen Geometrie undErsatzmodellen fur die Berechnung

Inhaltlich sind die geometrischen Daten einer Berechnung nur ein Teil der beno-tigten Daten (vergleiche Bild 2.4). Je nachdem, ob es sich bei dem Berechnungs-verfahren um ein allgemeines (zum Beispiel ein numerisches) Verfahren oder umein spezielles, auf ein Produkt abgestimmtes Verfahren handelt, sind die fur eineBerechnung benotigten Geometriedaten unterschiedlich.

Allgemeine Verfahren

Bei der Verwendung allgemeiner Verfahren, wie MKS oder FEM, wird in derRegel ein detailliertes Rechenmodell aus einem gegebenen Geometriemodell ab-geleitet, indem das Geometriemodell in kleinere, gleichartige (finite) Elementezerlegt wird. Eine Berechnung mit einem der Verfahren setzt demnach voraus,daß bereits ein Geometriemodell in Form eines Oberflachenmodells oder einesVolumenmodells existiert. Parameter oder Featureinformationen werden nichtbenotigt. Beim Ubergang von einem detaillierten Geometriemodell zu einem Re-chenmodell kann es erforderlich sein, Geometriedetails, die das Rechemodell un-notig verkomplizieren wurden, vor der Umwandlung aus dem Modell zu entfernen.Das Entfernen der fur eine Berechnung nicht relevanten Konstruktionselementewird auch als defeatureing bezeichnet. Zur Zeit muß diese Aufgabe noch durchden Bearbeiter erledigt werden [Zie99], da die Entscheidung, ob ein Konstrukti-onsdetail fur die Berechnung relevant ist oder nicht, sehr komplex ist.

24


Typ Beispiel Eigenschaften

Normen SchraubendurchmesserWerkstoffdaten

konstant, leicht zu iden-tifizieren

Andere Berechnungen LastenBetriebskrafte

veranderlich, hangen abvon Randbedingungen

Fertigungsunterlagen Oberflachenrauhigk. unterliegen Streuungen

Richtlinien ReibwerteAnziehfaktoren

begrenzte Gultigkeit,haben oft Ermessens-spielraum

Benutzereingaben Lasteinleitungsfaktor nicht reproduzierbarAnforderungsliste Lebensdauer konstant

Tabelle 2.2: Typische Quellen von Parametern und deren Eigenschaften

Spezielle Verfahren

Bei den speziell auf ein Produkt oder eine Produktgruppe abgestimmten Ver-fahren konnen die Modelle fur die Berechnung sowohl aus einer gegebenen Geo-metrie abgeleitet werden als auch umgekehrt. Dabei konnen beim Ubergangvon der Geometrie zum Ersatzmodell sowohl Informationen vernachlassigt wer-den, wenn bei der Berechnung Details wie beispielsweise Ausrundungsradien oderFasen nicht berucksichtigt werden als auch zusatzliche Informationen erforderlichsein, die ublicherweise nicht in einer Geometriedarstellung enthalten sind, Beispie-le hierfur sind Gewindeabmessungen, oder die Detailgeometrie eines Freistichs.In der Regel wird eine gegebene Geometrie nicht direkt in einer Berechnung ver-wendet, sondern als geometrisches Ersatzmodell, das aus dem Original mit Hil-fe von Abbildungsvorschriften und zusatzlichen Informationen abgeleitet wurde.Die Ableitung des Ersatzmodells ist einfach, wenn nur Norm– und Standard-teile oder parametrisierte Konstruktionsfeatures verwendet werden, da dann dieMerkmale fur beide Modelle aus den entsprechenden Bibliotheken entnommenwerden konnen. In vielen Fallen ist es allerdings nicht moglich, ein Produkt nuraus Norm– und Standardteilen aufzubauen, oder es zeigt sich, daß verschiede-ne Berechnungsverfahren eine unterschiedliche Parametrisierung erfordern wur-den. Beispielsweise kann eine Schraubenverbindung durch das Programm BOLT[BOL94] mit unterschiedlichen Modellannahmen berechnet werden. Bild 2.5 zeigtauf der linken Seite die Parametrisierung, wie sie fur eine Berechnung als zylin-drische Einschraubenverbindung erforderlich ware und auf der rechten Seite dieParametrisierung, wenn die verspannten Teile als balkenartige Struktur betrach-tet wurden.

25


A

u v

s END1

END2

END3

END4

VDI 2230 Balkenmodell

Bild 2.5: Unterschiedliche Parametrisierungen einer Schraubenverbindungim Programm BOLT in Abhangigkeit vom Berechnungsverfahren([BOL94])

2.3.4 Semantik in den Modellen

Semantik wird in [Wah86] als Lehre von der Bedeutung der Worter oder als Leh-re von den Zeichen und Symbolen als Denkinhalte einer Wissenschaft definiert.Im Bereich Informationstechnik wird der Begriff semantisches Datenmodell furDatenmodelle verwendet, in denen alle Strukturen und zulassigen Operationenbestimmten Typen von Informationen aus der realen Welt entsprechen [Stu90].Demzufolge konnen Datenmodelle eine unterschiedlich komplexe Semantik besit-zen, je nachdem wieviele der Eigenschaften der realen Welt in das Datenmodellubernommen wurden.

Von den CAD–Systemen werden sehr komplexe Datenmodelle gehalten und uberdie Programmierschnittstelle zuganglich gemacht. In den Systemen sind Dingewie Bauteile, Flachen, Kanten oder Punkte und Methoden fur die Analyse dieserDinge und den Relationen zwischen ihnen definiert [Par97]. Daruberhinaus wirdmit der Featuremodellierung versucht, den Objekten eine uber die reine Geome-trieinformation hinausgehende Bedeutung zuzuordnen [Rie94] [Lof97], und dieseBedeutung auch fur andere Aufgaben, wie die Erstellung von NC-Programmenoder die Materialwirtschaft zu nutzen. Detailbetrachtungen zeigen, daß, obwohlmehrere Systeme eine ahnliche Funktionalitat aufweisen, die Analysemethodenund damit die Semantik in den Modellen Unterschiede aufweisen [AJSK98]. Bei-spielsweise kann eine Kante beschrieben sein durch vier Koordinatenwerte oderdurch zwei Endpunkte, die jeweils aus zwei Koordinatenwerten bestehen.

Der komplexen Semantik der Geometriemodelle steht eine relativ einfache bei

26

2.4 Prozeßtechnische Sicht

den Rechenmodellen gegenuber. Die meisten Programme fur die Berechnungvon Maschinenelementen verwenden fur die Darstellung der Modelle benannteParameter [BOL94] [HEX95] [Dam96]. Die Bedeutung wird einem Parameterdurch den Benutzer zugeordnet. Verknupfungen zwischen Parametern oder dieZugehorigkeit zu einem Bauteil konnen aus den Systemen nicht ermittelt werden.Die unterschiedliche Semantik in den Systemen erschwert die modelltechnischeKopplung, da fur die Verknupfung der Modelle zusatzliche Informationen erfor-derlich sind.


Wahrend des Entwicklungsprozesses werden in nahezu allen Phasen Berechnun-gen mit unterschiedlichen Zielsetzungen durchgefuhrt. Allen Berechnungen istgemein, daß sie eine Vorhersage des Verhaltens oder der Eigenschaften eines Pro-dukts oder einer Komponente liefern sollen. Dabei werden die Eigenschaftendes realen oder geplanten Produkts auf ein Modell abgebildet, das dem Vorbildim Hinblick auf die zu untersuchenden Eigenschaften moglichst gut entspricht[Gra99].Der Ablauf von Entwicklungsaktivitaten wird in zunehmendem Maße durch rech-nergestutzte Prozeßmanagementwerkzeuge gesteuert [KOM96]. Die Aufgabe die-ser Werkzeuge besteht darin, sowohl die fur den jeweiligen Arbeitsschritt be-notigten CAE–Werkzeuge bereitzustellen als auch den Datenfluß zwischen denCAE–Werkzeugen prozeßbegleitend zu steuern und zu uberwachen. Die Merk-male der Schritte Gestalten und Berechnen im Hinblick auf eine prozeßtechnischeIntegration werden in diesem Abschnitt erlautert.

2.4.1 Gestaltungsprozeß

Je nach Aufgabenstellung kann sich der Gestaltungsprozeß uber die drei Kon-struktionsphasen Konzipieren, Entwerfen oder Ausarbeiten erstrecken. DerHauptanteil der Gestaltung erfolgt allerdings in der Entwurfsphase [PB97]. Ne-ben der Entwicklung einer maßstablichen Darstellung gehoren zur Gestaltung dieFestlegung der Werkstoffe und Fertigungsverfahren. Die Gestaltung wird dabeidurch die Methoden zur Losungssuche, Auswahl, Bewertung und Optimierungunterstutzt und ist daher zahlreichen Iterationen unterworfen.

2.4.2 Einordnung von Berechnungen in denProduktentwicklungsprozeß

Nach Koller konnen Produkte erst bemessen (dimensioniert) werden, wenn derenqualitative Parameterwerte, bzw. deren Gestalt feststeht [Kol98]. Damit warenBerechnungen der Entwurfsphase oder fruhestens dem Ende der Konzeptphase

27


zugeordnet. Tatsachlich kommen uberschlagige Auslegungsberechnungen schonin fruheren Phasen zum Einsatz, wenn es um die Auswahl und Bewertung vonWirkprinzipien geht [PB97]. Zu diesem Zeitpunkt ist die Bauteilgestalt gera-de erst im Entstehen oder besteht aus einer Anzahl von Wirkorten. Im Sinnevon Koller bedeutet das, daß zumindest die Parameter der zu untersuchendenStruktur feststehen mussen.Der Detaillierungsgrad eines zu entwickelnden Produkts bestimmt auch die mog-lichen Zielsetzungen einer Berechnung. In Bild 2.6 sind mogliche Formen vonMaschinenelementberechnungen und die Verknupfungen zwischen den Modellen,bei denen mindestens ein Konzept des Produkts vorliegt, dargestellt. Ausge-hend von diesem Konzept wird ein Ersatzmodell fur eine Berechnung aufgebaut,das wesentliche Merkmale des zu entwickelnden Produkts abbildet. Das Kon-zept enthalt ublicherweise nur wenige oder keine quantitative Geometriegroßen.Diese werden entweder durch die Berechnung bestimmt, oder mussen aus derAnforderungsliste entnommen oder aufgrund von festgelegten Hauptabmessun-gen abgeleitet werden. Das Konzept muß aber in seiner Struktur so festgelegtsein, daß der Einsatz der gewahlten Berechnungsmethode gerechfertigt ist und ei-ne Zuordnung der Komponenten beider Modelle sowie der fur die Modellbildungwesentlichen Merkmale moglich ist. Bei Konstruktionen, denen ein bekanntesund bewahrtes Losungsprinzip zugrunde liegt, existieren meist auch Rechenver-fahren fur die Festlegung der Hauptabmessungen anhand von definierten Anfor-derungen [Kol98]. In diesem Fall ist die Abbildung der Konzeptparameter aufdas Ersatzmodell nicht erforderlich. Vielmehr liefert eine Auslegungsrechnungals erster Schritt die Hauptabmessungen fur die Funktionstrager. Nach Hubkawerden in der Praxis viele Parameter auch mit “Konstruktionsgefuhl” festgelegtund anschließend durch Nachrechnung uberpruft [HE92], sodaß der Entwurf ohneBerechnung aus dem Konzept generiert wird.Basierend auf den Hauptabmessungen wird im Geometriemodellierer das Produktbis zum Entwurfsstadium ausgearbeitet. Mit der jetzt vorliegenden Detailgeome-trie sind Nachrechnungen der zuvor vorgenommenen Vordimensionierungen mog-lich. Dafur mussen die im Gestaltungsprozeß erstellten Geometriedaten wieder indas Rechenmodell ubertragen werden. Wenn das Ergebnis der Nachrechnung aufeine Uber- oder Unterdimensionierung des Bauteils hinweist, konnen die aus derNachrechnung gewonnenen Erkenntnisse in Form einer Optimierung wieder Ruck-wirkungen auf das Geometriemodell haben. Ahnliche Prozeßstrukturen ergebensich bei der Durchfuhrung von Montagesimulationen oder der Simulation vonFertigungsoperationen. Auch diese Operationen konnen in mehreren Iterationendurchlaufen werden, konnen ebenfalls Ruckwirkungen auf das Geometriemodellhaben und somit eine erneute Berechnung erforderlich machen. Anwenderproze-duren fur die Auslegung und die anschließende Gestaltung von Schraubenverbin-dungen in einem CAD–System wurden Schwenke zusammengestellt [Sch91].Je nach Laufzeit der Berechnung kann es sinnvoll sein, den Gestaltungsprozeßzu unterbrechen (asynchrone Anwendung), oder die Berechnung bei laufendem

28


��

��

�� "!$#&%&��'(')+* �,.-0/&132+4

57698;:=<?>;<?@;AB@;8 @;8DCFEG@DAIHJ@;8 KMLONPK9ABQI@;<RC=@D8

SUT0VWTYX0Z\[\]\[0^9_`_Bab_`cdTMe

fhgjilknm ab_`cdT0e

o�p�q�r�p�s"t$u&v&p�w(wx+y uzs�{Wp�|�}+~

� p�u�t$p�}�� p�t$u&v&p�w(wx�� s�}��M�&�3�+~

�3� �� (� � � � � � � ��z� �

� � � ��

¡B¢�£F¤\¢�¥§¦�¨R¢�¤$£&©&¢�ª(ª«+¬P¦�¨(�®¯¨�°&¨ ¢�ª�ª ¢\±³²"´"µ&�¶&·

¸º¹¼»¯¹9½¼¾À¿ÀÁÀ¿ÃÂ

Ä ¹MÅMÆ�Ç¼È�Æ�ÁÀ¿ÃÂ

Bild 2.6: Mogliche Berechnungen im Produktentwicklungsprozeß

CAD–System durchzufuhren (synchrone Anwendung).Daruber hinaus konnen auch Vergleichsrechnungen durchgefuhrt werden, derenZiel es ist, den Einfluß bestimmter Parameter oder die Sinnfalligkeit eines Er-gebnisses zu verfizieren [Gal80]. Diese Berechnungen konnen in allen Konstrukti-onsphasen durchgefuhrt werden und stehen in Relation zu einer anderen, bereitsdurchgefuhrten Berechnung, die bezuglich des verwendeten Ersatzmodells Ahn-lichkeit zu der aktuell durchgefuhrten hat.

2.4.3 Arbeitsschritte beim Berechnen

Eine Berechnung setzt sich aus mehreren Einzelschritten zusammen, die einenunterschiedlichen Bedarf an bereitzustellender Information [HE92] und ein un-terschiedliches Potential an Automatisierbarkeit besitzen. In [Wol98] werden dieSchritte:

• Vorbereitung

• Berechnung

• Nachbereitung

unterschieden. Zur Berechnungsvorbereitung gehoren die Modell- und Metho-denauswahl sowie die Ermittlung der Eingangsgroßen durch Analysieren der Geo-metrie und Zusammenstellen der nichtgeometrischen Parameter. Wegen der in

29


Abschnitt 2.3.2 beschriebenen Spielraume bei der Modellbildung wird die Me-thodenauswahl immer die Erfahrung eines Bearbeiters erfordern. Die der Be-rechnung nachfolgende Bewertung kann durch Visualisierung der Ergebnisse undBereitstellung zulassiger Werte unterstutzt werden. Auf der Grundlage der Be-rechnung konnen dann Variationen oder Optimierungen durchgefuhrt werden, diedurch eine automatische Anpassung der Geometrie oder durch eine programmier-te Optimierungsstrategie unterstutzt werden konnen. Die prozeßbegleitende undabschließende Erstellung der Dokumentation kann ebenfalls gut durch eine au-tomatische Protokollierung von Bearbeiter, Datum, Versionen der Modelle undder verwendeten Methoden, sowie der Benutzereingaben automatisiert werden.Tabelle 2.3 zeigt eine Ubersicht uber die Schritte, die mogliche Rechnerunter-stutzung und die vom Bearbeiter benotigten Informationen.

Prozeßschritt Rechnerunterstutzung Informationsbedarf◦ Modellauswahl ◦ automatische Analyse ◦ Definitionen

der Konfiguration ◦ Gultigkeitsbereiche◦ verfugbare Modelle

◦ Abbildung der ◦ Geometrieanalyse ◦ DefinitionenGeometrie auf ◦ Ermittlung von ◦ RegelnErsatzmodell Normdaten ◦ Modellannahmen

◦ Gultigkeitsbereiche◦ Ermitlung der ◦ Normen/Richtlinien

weiteren ◦ durchgef. BerechnungenParameter ◦ Anforderungen

◦ Meßwerte◦ Berechnung ◦ Abarbeitung der ◦ verwendete Formeln

Formeln ◦ Modellannahmen◦ Herkunft von

Parametern◦ Bewertung ◦ Visualisierung ◦ Zulassige Werte

◦ Vergleich mit ◦ Vergleichsrechnungenzulassigen Werten ◦ Streubereiche

◦ Einflußgroßen◦ Variation / ◦ Trendanalyse

Optimierung ◦ Geometrievariation◦ automat. Optimierung

◦ Dokumentation ◦ prozeßbegleitende ◦ Bereits vorhandeneProtokollierung Berechnungen

Tabelle 2.3: Moglichkeiten der Rechnerunterstutzung und Informationsbedarf desBearbeiters beim integrierten Berechnen

30


2.4.4 Auszutauschende Daten

Modelldaten

Je nachdem, um welche Art von Berechnungsmethode es sich handelt, variiertdie Struktur der zwischen Gestaltungssystem und Berechnungssystem auszutau-schenden Daten. Wahrend allgemeine Methoden mit Oberflachen- oder Volu-menmodellen auskommen, mussen fur speziell auf ein Produkt oder eine Pro-duktgruppe ausgelegte Methoden zusatzlich Informationen ubertragen werden.Die zusatzlichen Informationen mussen entweder in den Modellen enthalten sein,oder mit Hilfe von in den Modellen enthaltenen Schlusseln aus externen Quellenermittelt werden. Flachenmodelle und Volumenmodelle lassen sich in der Regelproblemlos aus einem parametrischen Geometriemodell ableiten. Schwieriger istes hingegen, wenn aus einem durch eine allgemeine Methode generierten Volu-menmodell ein parametrisiertes Geometriemodell abgeleitet werden soll, beispiels-weise, wenn aus dem Ergebnis einer Topologieoptimierung ein Parametermodellerstellt werden soll. Dieser Schritt kann zur Zeit nur manuell vollzogen werden.Die zu ubertragenden Daten hangen von den internen Modellen der beteiligtenApplikationen ab. Beim Ubergang mussen gegebenenfalls Informationen hinzuge-fugt werden, die im Ausgangsmodell nicht vorhanden sind. Beispielsweise werdenfur viele Berechnungen die außeren Lasten benotigt, die nicht im Geometriemo-dell enthalten sind. Wenn das Ergebnis einer Berechnung ein dimensioniertesBauteil ist, muß dafur ein Geometriemodell erzeugt werden. Bild 2.7 gibt einenUberblick uber den erforderlichen Datenaustausch.

Metadaten

Fur eine prozeßtechnische Integration mussen auch die Arbeitsschritte bis zumZustandekommen einer Berechnung und die nachfolgenden Schritte wie Ruckfuh-rung und Dokumentation der Ergebnisse beachtet werden. Dieser Punkt gewinntan Bedeutung, wenn man Berechnungen auch als Dienstleistungen, die ein exter-ner Anbieter seinem Kunden zur Verfugung stellt, versteht.

Methodenauswahl Bei Zusammenstellung der Metadaten fur die Methoden-auswahl wird davon ausgegegangen, daß der Anwender bereits einen Uberblickuber die generell verfugbaren Methoden hat und auf der Suche nach einer Metho-de fur ein bestimmtes Problem ist. Im einzelnen sollten folgende Informationenuber eine Methode verfugbar sein.

Gultigkeitsbereich. Wesentlich fur die Auswahl einer Methode ist die Frage, obdas zu berechnende System im Gultigkeitsbereich der Berechnungsmethodeliegt. Zur Festlegung eines Gultigkeitsbereiches gehoren neben Bereichs-angaben fur bestimmte Parameter auch Aussagen uber die Verwendungbestimmter Normteile oder bestimmte Modellkonfigurationen.

31


��

Geometriedaten

Bedingungen

Maße

bildl. Darstellung Ergebnisse

MetadatenParameter

geometr. Eigenschaften

Modelle

Benutzerdef. Werte

Zielvorgaben

Parameterwerte

Modelle

NormdatenModelle

MetadatenErgebnisse

Bild 2.7: Informationsfluß beim integrierten Berechnen

Modellannahmen. Die einer Berechnung zugrunde liegenden Modellannahmenmussen dem Anwender bekannt sein. Oft sind diese Annahmen nicht quan-tifizierbar und mussen daher durch den Anwender gefuhlsmaßig bewertetwerden (Beispiel: “Ebenbleiben der Querschnitte”).

Ziel. Aus dem Ziel einer Berechnung resultieren die Einordnung in den Entwick-lungsprozeß und die Art der erreichbaren Ergebnisse. Ziele konnen eineAuslegung, ein Festigkeitsnachweis oder eine Optimierung sein.

Eingangsgroßen. In Zusammenhang mit dem Ziel stehen auch die erforderli-chen Eingabedaten. Diese mussen sowohl in maschinenlesbarer Form alsauch fur den Benutzer lesbar sein. Anhand dieser Daten muß der Anwen-der entscheiden konnen, ob die Anwendung einer Methode zum jetzigenErkenntnisstand uberhaupt moglich und sinnvoll ist.

Aussagegute. Ein weiteres Kriterium fur eine Methodenauswahl ist auch dieerzielbare Aussagegute. Dazu gehoren auch Hinweise auf Empfindlichkeitendes Ergebnisses bezuglich bestimmter Parameter und Unsicherheiten bei derBestimmung von Eingabewerten.

32


Dokumentation Die Dokumentation einer Berechnung soll die Voraussetzun-gen und Randbedingungen einer durchgefuhrten Berechnung zu einem spaterenZeitpunkt nachvollziehbar machen und die erzielten Ergebnisse festhalten. Furdiesen Zweck sollten folgende Daten archiviert werden:

Quellen. Zu allen Parameterwerten, die nicht programmintern ermittelt werden,sollten die Quellen, aus denen der Wert bezogen wurde, protokolliert wer-den. Dazu gehoren geometrische Großen, Werte aus der Anforderungslisteoder Benutzereingaben.

Durchfuhrung. Bearbeiter, Datum und Uhrzeit der Berechnung gehoren in dieDokumentation.

Verknupfte Modelle. Die fur eine Berechnung herangezogenen Modelle mit de-ren Bearbeitungsstand oder Version mussen ebenfalls protokolliert werden.Anhand dieser Daten kann festgestellt werden, welche weiteren Modelle beieiner Anderung betroffen sind.

Ergebnisse. Die Ergebnisse einer Berechnung mussen ebenfalls protokolliert wer-den. Die Ergebnisse konnen ermittelte Sicherheitsfaktoren, die durch eineDimensionierung gefundenen Modelle oder Anderungsanforderungen an dasGeometriemodell sein.

2.4.5 Probleme bei der Integration

Die verschiedenen moglichen Erscheinungsformen von Berechnungen erschwereneine genaue Einordnung eines Berechnungssystems in eine Prozeßkette. Vielmehrist ein Berechnungssystem als ein Werkzeug zu sehen, das an verschiedenen Stel-len des Entwicklungsprozesses eingesetzt werden kann. Berechnungen konnen furdie Auswahl, die Bewertung und die Optimierung verwendet werden und las-sen sich damit gut in den allgemeinen Gestaltungsprozeß einordnen (vergleicheAbschnitt 2.4.1).Voraussetzung fur eine Benutzung eines Berechnungsprogramms als Werkzeug zurGeometriemodellierung ist eine hinreichende Integration der beteiligten Modelle,da Eingangsgroßen und Ergebnisse einer Berechnung Bestandteile des Geometrie-modells sein konnen. Außerdem muß das Berechnungsprogramm vom Arbeits-platz des Konstrukteurs aus aufrufbar sein und sollte sich in die Benutzungso-berflache und die Anwenderprozeduren des CAD–Systems einfugen. Methodenmit kurzer Laufzeit sollen ausfuhrbar sein, ohne daß das CAD–System beendetwerden muß. Methoden mit langer Laufzeit oder mit einem hohen Bedarf anSystemressourcen sollen auch eigenstandig lauffahig sein.In der Praxis haben die beteiligten Systeme unterschiedliche Vorgehensweisenbei der Benutzung. Erschwerend kommt hinzu, daß sowohl innerhalb der CAD–Systeme als auch innerhalb der Berechnungsprogramme verschiedene Anwen-derprozeduren und Benutzungsoberflachen fur die Modellierung existieren. Die

33


unterschiedliche Semantik der Modelle erschwert direkte Kopplung der Prozes-se. Um die Arbeitsschritte bei der Geometriemodellierung, Geometrieerzeugung,Geometrievariation, Positionierung von Bauteilen und ahnliches mit Hilfe vonBerechnungsprogrammen durchfuhren zu konnen, sind zusatzliche Informationenerforderlich, wie die Berechnungsergebnisse im Geometriemodell abgebildet wer-den konnen. Entsprechend mussen die Geometriedaten fur eine Berechnung indie entsprechende Parameterdarstellung gebracht werden.Die erforderlichen Metainformationen fur die Auswahl der Methoden und dieVerknupfung der Modelle sind in keinem der Systeme vorhanden und mussendaher zusatzlich in das System eingebracht werden.

2.5 Systemtechnische Sicht

Gestaltungsaufgaben und Berechnungsaufgaben sind durch zahlreiche Program-me und Programmsysteme rechnerunterstutzt durchfuhrbar. Dabei existieren furbeide Aufgaben breite Spektren von Losungen auf verschiedenen Rechnerplattfor-men mit unterschiedlichen Umsetzungen der oben genannten Modelle. Fur eineIntegration mussen Modelldaten zwischen den beteiligten Systemen ausgetauschtwerden, die Systeme mussen in ein durchgangiges Ablaufschema integriert werdenund die auf verschiedenen Plattformen bestehenden Applikationen mussen zusam-mengefuhrt werden. In diesem Abschnitt werden die moglichen Vorgehensweisenbei der Durchfuhrung von integrierten Berechnungen, die Zugriffsmethoden aufdie internen Modelle und die Plattformabhangigkeit der beteiligten Systeme be-schrieben.

2.5.1 Mogliche Kopplungsformen

Unter der Voraussetzung, daß Berechnungsmethoden als Werkzeuge angesehenwerden, die bei der Durchfuhrung einer Gestaltungsaufgabe an verschiedenenStellen eingesetzt werden konnen, muß eine Integration dafur sorgen, daß das Be-rechnungssystem mit den aktuellen Daten des Gestaltmodells arbeitet. Die Zu-sammenfuhrung von Modelldaten und Methoden kann auf unterschiedliche Weiseerfolgen:

Modellubertragung zwischen den Systemen (lose Kopplung): Vor der Berech-nung wird das Modell oder ein Ausschnitt davon vom Geometriemodelliererzum Berechnungssystem ubertragen und dort weiterverarbeitet. Das Ori-ginal des Modells verbleibt dabei im erzeugenden System und kann nurdort variiert werden. Ein solche Kopplung wird auch als lose Kopplungbezeichnet [Hah98]. Fur die Kopplung ist ein Dateiaustausch erforderlich,wobei zunehmend auch Ubertragungsverfahren, die das Internet als Medi-um verwenden, zum Einsatz kommen. Ublich sind hier FTP (File Transfer

34


Protokoll) oder an Emails angehangte Dateien [VDI99]. Die Verwaltungbestimmter Modellversionen und die Archivierung der entstehenden Do-kumente kann dabei von PDM–Systemen ubernommen werden (vergleicheAbschnitt 3.3.1). Die Ubertragung von Modellen kann sinnvoll bei Be-rechnungsprogrammen eingesetzt werden, die uber eigene Geometrieana-lyseroutinen verfugen und das ubertragene Modell, zum Beispiel fur eineElementierung, weiterverarbeiten. Ein typisches Anwendungsbeispiel hier-fur ist die Durchfuhrung von FE–Analysen, die als Methoden mit langerLaufzeit meist asynchron und auch von Experten als Bearbeiter durchge-fuhrt werden [Wol98].

Methodenubertragung zum Anwender: Im Gegensatz zur Ubertragung von Geo-metriemodellen konnen auch die Berechnungsmethoden vom Anbieter zumAnwender ubertragen, und als Erweiterung des Geometriemodelliers ver-wendet werden. Die Methode wird dann lokal am Arbeitsplatz des Anwen-ders eingesetzt und arbeitet mit dem CAD–System und dem Geometrie-modell des Anwenders. Die Ubertragung von Methoden ist sinnvoll, wennein Anwender seine Geometriemodelle, beispielsweise aus Sicherheitsgrun-den, nicht weitergeben mochte. Ein Anwendungsbeispiel hierfur sind Ausle-gungsrechnungen fur Zulieferkomponenten, bei denen die Berechnungspro-gramme durch den Zulieferer zur Verfugung gestellt werden.

Direkte Verknupfung der Programme: Die fur eine integrierte Berechnung er-forderliche Kopplung der Systeme kann auch mit einer direkten Netzwerk-verbindung der Programme realisiert werden. Sowohl das Geometriemodellals auch die Berechnungsmethode blieben beim jeweiligen Eigentumer undnur die fur die Berechnung erforderlichen Informationen wurden ubertra-gen. Diese Kopplung kann erforderlich werden, wenn die Methode nicht aufder Anwenderplattform lauffahig ist, aber trotzdem fur die Berechnung dieFunktionalitat des Geometriemodellierers benotigt wird.

Idealerweise bietet das Integrationssystem die Moglichkeit, alle drei genanntenKopplungsformen zu realisieren, da sich fur jeden Form sinnvolle Anwendungs-falle ergeben. Die Ubertragung von Modellen hat allerdings den Nachteil, daßsie ublicherweise mit einer Modelltransformation und damit mit Datenverlustverbunden ist [Sei85]. Anzustreben ist daher eine direkte Kopplung von Berech-nungssystem und CAD–System.

2.5.2 Zugriff auf die internen Modelle

Da in der vorliegenden Arbeit existierende Systeme zu einem integrierten Systemzusammengesetzt werden sollen, mussen die betrachteten Systeme auf die Zu-ganglichkeit ihrer internen Modelle untersucht werden. Grundsatzlich existierenzwei Moglichkeiten, Zugriff auf das Datenmodell eines Programms zu erhalten:

35


der programmgesteuerte Zugriff uber eine Programmierschnittstelle und der Aus-tausch uber Dateien.

Programmierschnittstellen

Programmierschnittstellen (engl.: Application Programmers Interface API ) bie-ten die Moglichkeit, zur Laufzeit des Programms auf die Funktionalitat und aufdie internen Datenmodelle zuzugreifen. In [KOM96] werden grundsatzlich dreiMechanismen fur den programmgesteuerten Zugriff beschrieben:

Applikationsbezogen. Durch Nutzung der Programmierschnittstelle einer Ap-plikation konnen neue Routinen zu der Grundfunktionalitat des Systemshinzugefugt werden. Die Routinen sind an die Programmierschnittstelledes System gebunden und mussen auf dem Rechner, der das Grundsystemhalt, lauffahig ubersetzt vorliegen.

Kommunikationsorientiert prozedural. Durch die Bereitstellung von netzwerk-fahigen Programmierschnittstellen konnen Applikationen, die auf verschie-denen Rechnern laufen miteinander kommunizieren. Klare Definitionen derSchnittstellen ermoglichen einen Modularen Aufbau des Gesamtsystems.Die zugreifenden Applikationen sind aber dennoch an die Schnittstellen-definition gebunden und mussen bei Anderung der Schnittstelle angepaßtwerden.

Kommunikationsorientiert objektorientiert. Um die Vorteile des objektorien-tierten Ansatzes, Wiederverwendbarkeit, Erweiterbarkeit und Modifizier-barkeit auch fur verteilte Applikationen nutzen zu konnen, wurden dieStrukturen der prozeduralen Kommunikationsmechanismen fur die Verwen-dung in objektorientierten Applikationen erweitert.

Fur den programmgesteuerten Zugriff existieren im Bereich Geometriemodellie-rung und Berechnung keine standardisierten Schnittstellen. Vielmehr existierenzahlreiche applikationsspezifische Schnittstellen, die jeweils ein Abbild der Funk-tionalitat und des internen Datenmodells der jeweiligen Applikation enthalten.Einheitliche Schnittstellen bieten die Systeme an, die auf dem selben Modellier-kern, beispielsweise ACIS beruhen. Im Forschungsprojekt ANICA wurde ver-sucht, aus den Programmierschnittstellen mehrerer bedeutender CAD–Systemeeine einheitliche Schnittstelle zu generieren, die die gemeinsame Funktionalitataller Schnittstellen abbildet [AJSK98]. Eine ausfuhrliche Beschreibung des Pro-jekts ANICA findet sich in Abschnitt 3.3.4.

Integrationsgrad

Da innerhalb eines Unternehmens meist ein spezielles CAD-System bevorzugtangewendet wird, werden integrierte Berechnungen oft durch systemspezifische

36


Erweiterungen der Berechnungsprogramme ermoglicht.Je nach Branche und Produktspektrum kann dabei der Integrationsgrad unter-schiedlich hoch gewahlt werden. Bei einfachen Produkten mit immer wiederkeh-renden Berechnungsmethoden konnen durch geeignete Wahl der Parametrisierungund durch Modularisierung der Methoden Modelle geschaffen werden, die direktaufeinander abbildbar sind. In [The99] wird beispielsweise ein System vorge-stellt, bei dem aus einer Reihe von Eingabedaten die gunstigste Variante einerGetriebebaureihe und das zugehorige Geometriemodell generiert werden. Dage-gen konnen in Bereichen mit wechselnden Randbedingungen und variantenreicherStruktur der Produkte sehr komplexe Abhangigkeiten zwischen den Modellen ent-stehen, die eine manuelle Anpassung erfordern. Beispiel hierfur ist die Auswahlvon Walzlagern fur einen beliebigen Anwendungsfall, bei der die Steifigkeiten derLagerumgebung in die Rechnung miteinbezogen werden mussen [LG99].

Dateischnittstellen

Ein anderes Verfahren, um Informationen zwischen Applikationen auszutauschen,ist die Kommunikation uber Dateien. Fur den Austausch von Geometriedatenexistieren zahlreiche Dateiformate mit unterschiedlichem Leistungsumfang. Ge-lost werden kann dadurch die Ubertragung von 3–D Flachenmodellen oder Draht-modellen. Allerdings existiert bislang kein Format, das in der Lage ist parame-trische 3–D Modelle zwischen verschiedenen Systemen zu ubertragen. Fur dieKopplung verschiedener Applikationen, die, wie oben beschrieben in mehrerenIterationen durchlaufen werden kann, bedeutet dies, daß nach einer Iteration dieParametrik eines Modells verloren ist.Eine Kommunikation uber Dateien bedeutet auch, daß die Daten empfangendeApplikation in der Lage sein muß, die Daten zu analysieren, und, was bei der Inte-gration von Berechnungen auch sinnvoll ist, zu variieren. Ein Berechnungssystemware damit auch gleichzeitig Geometriemodellierer.Mit STEP [ISO94] soll neben einem Produktmodellschema auch ein Dateiaus-tauschformat festgelegt werden, das in der Lage ist, alle produktbezogenen Datenzu ubertragen. STEP wird im Abschnitt 3.1.1 genauer beschrieben.Die existierenden Berechnungsprogramme verwenden alle eigene Dateiformate furdie Speicherung von Berechnungen. Die Dateiformate sind uberwiegend parame-terorientiert [BOL94] [Dam96]. Einige Systeme stellen Zeichnungsausschnitte derberechneten Komponente im 2D–Geometriedatenaustauschformat DXF zur Ver-fugung [HEX95].

Vernetzung der Systeme

Sofern die auf verschiedenen Rechnerplattformen bestehenden Systeme nicht aufeiner einzigen Plattform neu implementiert werden, muß davon ausgegangen wer-den, daß die Systeme auf verschiedenen Rechnern eines Netzwerkes laufen (siehe

37


auch Abschnitt 2.5.3). Die heutigen CAD–Systeme sind nicht fur eine Anwen-dung in einer Client Server Umgebung konzipiert. Vielmehr werden die Systemeals lokale Einzelplatzlosungen eingesetzt. Die Modelle werden als Dateien in ei-nem proprietaren Format abgelegt. Die aktuellen Entwicklungen zielen darauf ab,daß neben den geometrischen Daten auch zahlreiche nichtgeometrische abgelegtwerden und damit das CAD-System zum zentralen, universellen Entwicklungs-werkzeug wird. Ein Grund fur die Entwicklung der standallone–Losungen istauch der Entwicklungstrend in der Hardware. Die heutigen Arbeitsplatzsysteme,in Form von PC oder Workstations sind in bezug auf Rechenleistung und Grafik-fahigkeiten so leistungsfahig, daß eine Benutzung auch komplexer Anwendungenproblemlos moglich ist. Daruber hinaus erfordert das Arbeiten mit Geometrie-modellen, insbesondere mit schattierten Darstellungen zur Zeit noch die Ubertra-gung großer Datenmengen, die eine betrachtliche Netzwerkbelastung verursachenwurden. Die Entwicklung einer netzwerkfahigen Beschreibungssprache fur dieraumliche Darstellung von Korpern, wie die Virtual Reality Markup LanguageVRML konnte hier zu neuen Losungen fuhren [VRM99]. VRML ermoglicht denTransport von raumlichen Darstellungen uber Netzwerke mit relativ geringemDatenvolumen.

Daraus folgt, daß derzeit auch bei einem Integrationssystem das CAD–Systemlokal am Arbeitsplatz vorhanden sein sollte. Das Berechnungssystem kann auchuber eine Netzwerkverbindung angesprochen werden. In diesem Fall ist aber zu-satzliche Software fur die Abwicklung der Kommunikation zwischen den Systemenerforderlich.

2.5.3 Plattformabhangigkeit

Ubersetzter Programmcode kann in den meisten Fallen nicht auf verschiedenenRechnerplattformen ausgefuhrt werden. Die Ausnahme hierfur bildet die Pro-grammiersprache Java (vgl. Abschnitt 3.2.3). Diese Plattformabhangigkeit fuhrtdazu, daß Programme, wenn sie auf verschiedenen Systemen eingesetzt werdensollen, in verschiedenen Versionen ubersetzt werden mussen. Die Portierung aufeine andere Rechnerplattform ist oft auch mit einer Anpassung der Software anunterschiedliche Konzepte fur Speicherzugriffe oder Benutzungsschnittstellen ver-bunden.

Eine Portierung bestehender Software ist oft mit erheblichem Aufwand verbun-den, sodaß in der Praxis die Betriebssysteme zugunsten der bestehenden Softwarenicht auf dem neuesten Stand sind oder verschiedene Systeme parallel betriebenwerden [Abe97] [VDI99]. Die Tatsache, daß die Arbeitsumgebung aus heteroge-nen Systemen besteht, muß bei der Wahl des Integrationsansatzes berucksichtigtwerden.

38

2.6 Anwendersicht

2.6 Anwendersicht

Berechnungsmethoden sollten sich moglichst reibungslos in die Tatigkeiten desKonstrukteurs integrieren. In diesem Abschnitt werden Anforderungen an dieMethoden aus der Sicht des Anwenders und Szenarien fur die Anwendung vonBerechnungsmethoden vorgestellt.

2.6.1 Bereitstellung von Berechnungsmethoden

In vielen Unternehmen stellen die verwendeten Berechnungsmethoden einen nichtunerheblichen Teil des Firmen-Know-How dar [LG99] [The99]. Die zugrundelie-genden Modelle und Algorithmen werden oft uber lange Zeit weiterentwickelt undverfeinert, sodaß sehr leistungsfahige, aber auch sehr komplexe Programmsystemeentstehen. Dabei ist die Programmentwicklung meist an eine Programmierspra-che und an eine Hardwareplattform gebunden, da ein Systemwechsel mit eineraufwendigen Neuimplementierung der bestehenden Software verbunden ware.

Firmeninterne Berechnungsmethoden

Fur einen effizienten Einsatz der vorhandenen Berechnungssoftware sollten alleMethoden am Arbeitsplatz des Konstrukteurs verfugbar sein. Sofern die Pro-gramme alle auf der selben Rechnerplattform implementiert sind, die auch demKonstrukteur zur Verfugung steht, kann eine Installation auf dem Arbeitsplatz-rechner erfolgen. Anderenfalls kann eine Bereitstellung von Methoden im Fir-mennetzwerk (Intranet) erfolgen. Bei einer großen Anzahl verfugbarer Methodenist es ratsam, Metainformationen fur eine qualifizierte Auswahl von Methodenbereitzustellen. Zu den Metainformationen gehoren Aussagen uber Laufzeit, Aus-sagegute, Gultigkeitsbereiche und Ahnliches.

Berechnungsmethoden von externen Partnern

Anbieter von Zulieferkomponenten stellen ihren Kunden oft die zu ihren Produk-ten gehorenden Auslegungsverfahren in Form von Berechnungsprogrammen zurVerfugung. Dabei mussen oft die individuellen Merkmale des Kundenproduktsin der Berechnung berucksichtigt werden. Im oben genannten Beispiel der Aus-legung von Walzlagern muß die Steifigkeit der Lagerumgebung entweder bekanntsein oder durch das Berechnungsprogramm ermittelt werden [LG99]. Im letztenFall mussen dem Berechnungsprogramm alle benotigten Daten der Lagerumge-bung zur Verfugung gestellt werden.

2.6.2 Qualifizierung der Bearbeiter

Eine sinnvolle Anwendung von Berechnungsmethoden kann nur erfolgen, wennder Bearbeiter eine ausreichende Qualifikation fur die Vorbereitung der Berech-

39


nung und die Bewertung der erzielten Ergebnisse besitzt, da sonst die Verlaßlich-keit der Ergebnisse in Frage gestellt ist [Abe97]. Je nach Komplexitat dieser Ar-beitsschritte kann die Bearbeitung durch einen Experten erforderlich sein. Inbe-sondere bei der Bereitstellung von Berechnungmethoden uber das Internet kommtdiesem Punkt eine besondere Bedeutung zu. Aus der großen Zahl der moglicher-weise angebotenen Methoden muß der Bearbeiter die fur sein Problem am bestengeeignete Methode auswahlen konnen. Dazu mussen ihm die zugrundeliegendenModellannahmen und Gultigkeitsbereiche bereitgestellt werden. Daruber hinausmussen ihm Informationen uber die erzielbare Aussagegute und uber Empfindlich-keiten oder Unsicherheiten bei der Bestimmung bestimmter Parameter aufgezeigtwerden. In der Praxis sind zu den meisten Berechnungsprogrammen Ansprech-partner vorhanden, die die entsprechenden Auskunfte liefern konnen [LG99]. Oftwerden auch die Berechnungen wahrend eines Beratungsgesprachs beim Kundendurch den Anbieter durchgefuhrt.Eine zusatzliche Qualifizierung des Bearbeiters auf dem Gebiet der Informati-onstechnik soll fur die Anwendung eines Integrationssystems nicht erforderlichsein.

2.6.3 Qualitat der Methoden

Bei der Bereitstellung von Methoden uber das Internet ist die Qualitat der an-gebotenen Methoden ein weiterer Aspekt. Damit ist gemeint, daß sowohl dietheoretischen Grundlagen der Methode hinreichend abgesichert sind als auch dieImplementierung genau dem entwickelten Rechenmodell entspricht. Bei innerbe-trieblichen Anwendungen wird davon ausgegangen, daß die Entwicklungsabtei-lung die bereitgestellten Programme ausreichend getestet hat, um die einwand-freie Funktion sicherzustellen. Ebenso verhalt es sich mit Programmen, die einemAnwender von einem Zulieferer bereitgestellt werden. Unsicher ist allerdings, wieein solches Vertrauensverhaltnis zu einem noch nicht bekannten Anbieter aufge-baut werden kann. In der Diskussion sind derzeit sogenannte “Broker”, die An-fragen zu bestimmten Problemen an qualifizierte Einrichtungen weitervermitteln.Einen Ansatz hierfur bildet das Berliner Kreis Kompetenz Netzwerk [N.N99].

2.7 Zusammenfassung

In Tabelle 2.4 sind zusammenfassend die Merkmale dargestellt, die eine Integra-tion von Berechnungsprogrammen in Geometriemodellierer beschreiben. Dabeisind diejenigen Eigenschaften hervorgehoben, die in der weiteren Arbeit beruck-sichtigt werden sollen.

40

2.7 Zusammenfassung

Met

ho

den

Mo

del

leP

roze

sse

Sys

tem

eA

nw

end

er

Anwendungs-gebiet

Integrierbarkeit

Ziel

Modelltyp

Konfiguration

Integration vonGeometrie

ZeitlicheAbfolge

Lokalisierung

Plattform

Zugriff auf Geometrie

Kopplungsform

Benutzungs-schnittstelle

Zugriff

Programmier-sprache

Bearbeiter

Qualifizierung

Laufzeit mittel kurzlang

Produktgruppe allgemein

direkt indirekt lose

Auslegung Nachweis Optimierung

produktspezifisch

Parametermodell

vorgegebeneVarianten

flexibel

für Geometrie

synchron asynchron

selber Rechner Intranet Internet

selbe PlattformverschiedenePlattformen

Analyse Variation Erzeugung

Modell-übertragung

Methoden-übertragung

direkteKopplung

einheitlichgleiche

Grundelementeeigene

dateiorientiertProgrammier-schnittstelle

selbe Spracheverschiedene

Sprachen

Konstrukteur Experte

gering hochausreichend

(Flächen, Volumen)

Austauschformateallgemeine

Geometrie

starr vorgegeben

auf CAD-Systemabgestimmt

eigenes Format

Bereich Merkmale

Tabelle 2.4: Merkmale einer integrierten Berechnung

41


42

3 Integrationsansatze

In diesem Kapitel werden grundlegende Ansatze vorgestellt, die fur die gestell-te Integrationsaufgabe von Bedeutung sind. Im ersten Abschnitt werden dasintegrierte Produktmodell von STEP als Ansatz fur eine modelltechnische Inte-gration und die Systemarchitektur des CAD-Referenzmodell als Grundlage furein Systemkonzept vorgestellt. Im zweiten Abschnitt werden mit CORBA undJAVA zwei Ansatze vorgestellt, die eine plattformubergreifende und netzwerkfa-hige Nutzung von Softwaresystemen ermoglichen. Im dritten Abschnitt werdenwichtige bestehende Integrationssysteme vorgestellt, deren Konzepte teilweise aufden zuvor beschriebenen Ansatzen beruhen.

Aus den beschriebenen Systemen werden abschließend allgemeine Integrations-strategien abgeleitet.

3.1 Integrierte Produktentwicklung

3.1.1 STEP - ein integriertes Produktmodell

Ein Ansatz, samtliche Produktdaten in einem einheitlichen Format abzubildensoll mit STEP geschaffen werden. STEP steht fur Standard for Exchange ofProduct Model Data, und wird seit 1984 von der International Organisation ofStandardization (ISO) entwickelt.

Zielsetzung

Das Ziel der Entwicklung von STEP ist es, eine “eindeutige Reprasentation voncomputer-interpretierbaren Produktinformationen fur den gesamten Lebenszy-klus eines Produkts” zu schaffen [ISO94]. Als Phasen des Produktlebenszykluswerden dabei Entwicklung, Fertigung, Vertrieb, Wartung und Entsorgung ge-nannt. Bislang existieren in den verschiedenen am Produktentwicklungsprozeßbeteiligten Systemen unterschiedliche Modelle. Mit STEP sollen diese Modelleersetzt werden durch ein eindeutiges, konsistentes und redundanzfreies Modell.Dadurch soll eine implementierungsneutrale Beschreibung der Produktdaten ineinem Produktmodell erreicht werden [GEP94]. Aus der historischen Entwick-lung heraus war STEP als Dateiaustauschformat geplant. Inzwischen wurden

43


erganzend dazu mit Standard Data Access Interface (SDAI) standardisierte Zu-griffsmethoden festgelegt, mit deren Hilfe uber Programmiersprachen auf die Pro-duktdatenbasis zugegriffen werden kann.

Struktur

Die Norm besteht aus mehreren aufeinander aufbauenden Serien. Die Zusam-menhange zwischen den einzelnen Serien sind in Bild 3.1 dargestellt und werdennachfolgend erlautert [Nel99].

Die STEP Serien konnen in sechs Hauptgruppen eingeteilt werden: descriptionmethods, integrated information resources, application protocolls, implementati-on methods and conformance methodolgy. Die description methods bilden dieGrundlage von STEP. Sie enthalten in Teil 1 die fur alle weiteren Teile geltendenDefinitionen. Ebenso gehort zu den Grundlagen die Beschreibung von EXPRESS,einer Sprache fur die Modellierung von Daten, in der samtliche Konstrukte vonSTEP abgebildet sind.

Die eigentlichen Datenmodelle von STEP sind in den Integrated Information Re-sources beschrieben. Diese sind nochmals unterteilt in drei weitere Gruppen. Dieerste, die Generic Resources bilden allgemeine Formen der in den Anwendungs-protokollen benotigten Objekte ab. Die applikationsspezifischen Erganzungendieser Objekte werden in den Application Resoures vorgenommen. Die hier defi-nierten Konstrukte konnen von allen Anwendungsprotokollen verwendet werdenund bilden somit die Grundlage fur eine einfache Integration und hohe Inter-operabilitat. In der dritten Schicht der Integrated Information Resources, denApplication Interpreted Resources werden Elemente der beiden anderen Ebenenzu Gruppen zusammengefaßt. Diese Gruppen beschreiben Modelle in bestimm-ten wiederverwendbaren Abstraktionsebenen und ermoglichen es auf diese Weise,die gleiche Semantik in verschiedenen Anwendungen abzubilden.

Die Information Resources werden in den Application Protocolls zu definiertenModellen zusammengefugt, die den Zustand eines Produkts zu einem bestimmtenZeitpunkt seines Lebenszyklus beschreiben. Die hier definierten Konstrukte sinddie in den Anwendungsprogrammen verwendeten Modelle.

In der Gruppe der Implementation Methods sind Abbildungsvorschriften fur dieAbbildung der STEP Konstrukte in eine Reihe von ublichen Programmierspra-chen festgeschrieben. In einem eigenen Bereich, Conformance Testing, sind An-weisungen fur die Uberprufung der Konformitat behandelt. In dieser Hinsicht istSTEP einzigartig, da die Richtlinien zur Konformitatsprufung in der Norm selbstenthalten sind.

Fur die Konformitatsprufung werden in den Abstract Test Suites zu jedem An-wendungsprotokoll Testverfahren beschrieben.

44


IMPLEMENTATION METHODS

DE

SC

RIP

TIO

N M

ET

HO

DS

CO

NF

RO

MA

NC

E T

ES

TIN

G M

ET

HO

DO

LOG

Y F

RA

ME

WO

RK

INTEGRATED INFORMATION RESOURCES

APPLICATION PROTOCOLS AND ASSOCIATED ABSTRACT TEST SUITES

21 Clr txt enoded exchange str

22 Standard data access interface

23 C++ language binding (to#22)

24 C language binding (to #22)

25 FORTRAN language binding

26 IDL language binding

1 O

verv

iew

and

fund

amen

tal p

rinci

ples

11 E

XP

RE

SS

lang

uage

ref

eren

ce m

anua

l

12 E

XP

RE

SS

-I la

ngua

ge r

efer

ence

man

ual

31 General C

oncepts

32 Requirem

ents on testing labs and clients

33 Abstract test suites

34 Abstract test m

ethods for Part 21 im

pl.

35 Abstract test m

ethods for Part 22 im

pl

105 Kinematics106 Building core model107 Engineering anal. Core ARM108 Paramet. Constr. for expl. geom mdl

101 Draughting102 Ship Structures103 E/E Connectivity104 Finite element analysis

ISO TC 184 SC4 ISO 10303

201 Explicit draughting

203 Configuration-controlled design204 Mechanical Design using boundary rep205 mechanical design using surface rep206 mecahnical design using wireframe207 Sheet metal die pkanning and design208 Life-cycle product change process

211 Electronic P-C assy. test, diag., & remanuf.212 Electrotechnical design an installation213 Num Cont. (NC) process plans for mach’d parts214 Core data for automotive dgn processes215 Ship arrangement216 Ship moulded forms217 Ship piping218 Ship Structures219 Dimension Inspection220 proc. plg, mfg, assy of layered electrical products

202 Associative draughting

41 Fund of product descr & spec42 Geom & topl representation43 Repres specialization44 Product struct confg45 Materials

46 Visual Presentation

48 Form Features49 Process structure & properties

47 Tolerances

STEP on a Page

209 Compos & metal struct., anal., and rel. dgn210 Electronic assy: intecnt & pkg design

501 Edge-based Wireframe

502 Shell-based wireframe

503 Geom-bounded 2D wireframe

504 Draughting annotation

505 Drawing structure & admin

512 Faceted B-representation

513 Elementary B-representation

514 Advanced B-representation

515 Constructive solid geometry

511 Topol-bounded surface

506 Draughting elements

507 Geom-bounded surface

508 Non-manifild surface

509 Manifold surface

510 Geom-bounded wireframe

517 Mech-design geom present’n

518 Mech-desingn shaded present’n

519 Geometric tolerances

520 Assoc. draughting elements

516 Mechanical-design context

221 Process plant functional data&its schem.rep222 Design_manuf for composite structures

224 Mech parts def for p. plg using mach’n’g feat225 Building Elements using explicit shape rep

226 Ship mechanical systems227 Plant spatial configuration228 Building Services: HVAC229 Design & mfg info for forged parts230 Buildin structural frame: steelwork

231 Process Engineering data232 Technical data packaging core info &exch233 Syst Engineering data representation234 Ship operational logs

223 Exec of dgn & mfg product info for cast parts

INTEGRATED APPLICATION RESOURCES

APPLICATION INTERPRETED RESOURCES

INTEGRATED GENERIC RESOURCES

Bild 3.1: Ubersicht uber die verschiedenen Bestandteile von STEP [Nel99]

45


Anwendung

Die Anwendung von STEP als Datenbasis fur samtliche produktbezogenen Datenist zur Zeit noch nicht gegeben. Dies liegt hauptsachlich daran, daß insbesonderefur die nichtgeometrischen Daten noch keine Applikationen existieren, die in derLage sind, STEP Modelle zu verarbeiten. Ansatze, bei denen STEP als Daten-basis fur die Abbildung von Geometriemodellen verwendet wird, sind in [Har97]und [SAKJ98] beschrieben.

Im Bereich der Geometrieverarbeitung wird STEP bereits als Datenaustausch-format eingesetzt. Die Fahigkeit, auch Produktstrukturen abbilden zu konnen[GAS92], macht STEP zu einem geeigneten Werkzeug, um die Geometriemodelleeiner heterogenen CAD-Umgebung zu einem digitalen Gesamtmodell zusammen-zufugen. In [Pot95] wird eine Losung fur den Austausch von Geometriemodellenuber STEP bei ACIS-basierten Geometriemodellierern beschrieben. In [SAKJ98]wird eine Anwendung vorgestellt, bei der mit Hilfe von STEP Volumenmodelleaus dem CAD-System Pro/ENGINEER fur eine Bauraumuntersuchung in dasCAD-System CATIA importiert wurden. Ein Problem bei der Verwendung vonSTEP als Austauschformat ist, daß auch STEP nicht in der Lage ist, samtliche inden CAD-Systemen enthaltenen Informationen abzubilden und es daher zu einemInformationsverlust kommt. Insbesondere konnen keine parametrischen Modelleubertragen werden. Die Entwicklung von STEP ist dabei von einem Zielkonfliktzwischen den Nutzern und den Entwicklern der CAD-Systeme gepragt. Wah-rend die Nutzer erwarten, daß sie CAD-Modelle zwischen beliebigen Systemenaustauschen konnen, sind die Systemhersteller bemuht, ihrem eigenen Systembesondere Merkmale zu geben, um sich vom Mitbewerber abheben zu konnenund die Anwender an das eigene System zu binden.

3.1.2 CAD–Referenzmodell

In einem von acht deutschen Forschungsinstituten uber zwei Jahre durchgefuhr-ten Forschungsvorhaben wurde eine Referenzarchitektur fur zukunftige CAD–Systeme erarbeitet. Das Ziel dieses Vorhabens bestand darin, auf der Grundlagedes Stands der Technik die Anforderungen an zukunftige CAD–Systeme zusam-menzustellen und daraus eine Systemarchitektur abzuleiten, die als richtungswei-send fur die Entwicklungen der nachsten Jahre gelten kann. Motiviert war dieseArbeit durch die seit der Einfuhrung der CAD–Systeme entstandene große Zahlvon Systemarchitekturen, die eine Interoperabilitat zwischen zwei Systemen odereinen Systemwechsel erschwerte. In der Praxis fuhrt das dazu, daß ein großerTeil der Anwender nicht mit den neuesten Entwicklungen Schritt halt, sondernaus Kompatibilitatsgrunden bei veralteten Anwendungen stehen bleibt.

46


Anforderungen

Neben einer Beschreibung eines menschengerechten Entwicklungsarbeitsplatzeswurde in dem Forschungsvorhaben eine sehr ausfuhrliche Liste von Anforderungenan zukunftige CAD–Systeme zusammengestellt [Abe95]. Dabei werden Aspekteder Arbeits- und der Konstruktionswissenschaft, der Konfiguration, des Benut-zungsdialogs, der Berechnung, der Analyse und Simulation ebenso behandelt wieAnforderungen bezuglich Wissenverarbeitung, Modellierung, Produktmodell undIntegrationsmoglichkeiten. An dieser Stelle sollen die Anforderungen in Bezugauf Berechnung, Analyse und Simulation herausgestellt werden. Die drei Punktewerden unter dem Begriff Analysen zusammengefaßt, der als Methoden zur Lo-sungsfindung und Beurteilung definiert ist. Da diese Methoden haufig in Formvon problemspezifischen oder anwenderspezifischen Programmen implementiertsind, werden an die Software die Forderungen nach maximaler Modularitat undKombinierbarkeit sowie der nutzergerechten Gestaltung gestellt.

Referenzarchitektur

Die Grundstruktur der Referenzarchitektur gliedert sich in die vier Hauptkompo-nenten Anwendungsteil, Systemteil, Produktmodell und anwendungsspezifischesWissen (Bild 3.2). Die Komponenten werden in [Abe95] wie folgt definiert:

ProduktmodellspezifischesWissen

Anwendungs

Systemteil

Anwendungsteil

Bild 3.2: Systemstruktur des CAD–Referenzmodells [Abe95]

Anwendungsteil. Menge der in einem CAD–System verfugbaren anwendungsbe-zogenen Komponenten zur Realisierung konstruktionsspezifischer Funktio-nalitat.

47


Systemteil. Menge der in einem CAD–System verfugbaren anwendungsunab-hangigen Komponenten, die fur die Bereitstellung, Konfigurierung, Abar-beitung und Integration von Komponenten des Anwendungsteils benotigtwerden.

Produktmodell. Einheit von Produktinformationsmodell und Produktdaten zurBeschreibung einer Klasse von Produkten uber den gesamten Produktle-benszyklus.

Anwendungsspezifisches Wissen. Menge von anwendungsspezifischem Wissenzur Losung von Konstruktionsaufgaben.

Der Anwendungsteil mit den eigentlichen CAx–Applikationen ist dabei vom Sy-stemteil umgeben. Der Systemteil stellt in dieser Symbolik die Schnittstelle zumBenutzer und zu den verbundenen Datenbasen fur das anwendungsspezifischeWissen und das Produktmodell dar (vergleiche Bild 3.3).Die deutliche Trennung der Anwendungs- und Systemkomponenten in der Refe-renzarchitektur soll die Austauschbarkeit und Erweiterbarkeit sowohl der anwen-dungsbezogenen als auch der anwendungsunabhangigien Komponenten unterstut-zen [Abe95]. Die Modularisierung setzt sich innerhalb der einzelnen Komponen-ten fort. Bild 3.3 [Abe95] zeigt die verschiedenen Subsyssteme des Systemteils, dieuber eine gemeinsam genutzte Kommunikationspipeline miteinander verbundensind.

Wissens-managementsystem

Produktdaten-managementsystem

Benutzungsoberflächen-System

externeSystemegenerische Anwendungen

Ressourcen

spezifische Anwendungen

Konfigu-rations-system

Kommunikationspipeline

systemkations-

Kommuni-

ressourcenSystem-

Bild 3.3: Struktur des Systemteils

48

3.2 Integration von Softwaresystemen

Anwendung

In einer zweiten Phase des Projektes soll versucht werden, die Ansatze und Kon-zepte der ersten Phase zu implementieren und deren Effizienz in der industrieellenAnwendung nachzuweisen. Dafur wurden Defizite in den rechnerunterstutztenProduktentwicklungsprozessen herausgearbeitet und daraus Innovationfelder furdas Referenzmodell abgeleitet. Die drei wesentlichen Innovationsfelder sind nach[Abe97]: Organisation und durchgangige Unterstutzung von Produktentwicklungs-prozessen, Verteilte kooperative Produktentwicklung und Systemtechnische Inte-gration und Optimierung von Produktentwicklungsumgebungen. In verschiedenenTeilprojekten wurden diese Felder mit unternehmensspezifischen Entwicklungenbearbeitet [Abe97]. Neben der Entwicklung einer durchgangigen Produktdaten-haltung wurden als Ziele hauptsachlich eine Restrukturierung und durchgehendeRechnerunterstutzung der Entwicklungsprozesse angestrebt.

Hervorzuheben ist die klar gegliederte und umfassende Systemstruktur des CAD–Referenzmodells. Die Struktur ist fur die Integration bestehender Softwaresyste-me aber insofern als Referenzstruktur zu sehen, daß die zu integrierenden Syste-me jeweils mehrere Komponenten umfassen und daher eine klare Trennung nichtmehr vorgenommen werden kann. Die oben genannten Innovationsfelder konnenals Randbedingungen fur die Integrationsaufgabe gesehen werden.


Mit der zunehmenden Rechnerunterstutzung des Produktentwicklungsprozesseswachst die Forderung, daß die in den verschiedenen Anwendungsbereichen bereitsexistierenden Softwaresysteme integriert werden mussen. Die Grundstruktur ver-netzter Programme ist eine Client-Server-Beziehung, in der eine Applikation alsServer Daten und Methoden zur Verfugung stellt, die von der anderen als Clientin Anspruch genommen werden.

In der Informationstechnik existieren fur die Realisierung von Client-Server Sy-stemen verschiedene Losungsansatze. In einem Uberblick werden zunachst diewichtigsten Ansatze vorgestellt. Anschließend werden zwei der fur die Integrati-onsaufgabe am geeignetsten erscheinenden Ansatze weiter erlautert. Der erste istCORBA, eine Systemarchitektur, die es ermoglicht, Objekte plattformubergrei-fend und netzwerktransparent zu verwenden, indem existierende Applikationenuber neutrale Schnittstellen gekapselt und an ein standardisiertes Kommunikati-onssystem angeschlossen werden. Der zweite Ansatz ist die ProgrammierspracheJAVA, die mit dem Ziel entwickelt wurde, eine objektorientierte Sprache zu schaf-fen, deren ubersetzter Code auf allen Rechnerplattformen ohne Neuubersetzunglauffahig ist.

49


3.2.1 Uberblick uber Client-Server Umgebungen

Als Basis fur die Kommunikation in Netzwerken wurde von der ISO das hier-archisch gegliederte OSI-Schichtenmodell entwickelt (OSI - Open Systems Inter-connection). In dem Modell werden sieben Transportschichten fur unterschiedli-che Informationen definiert. Die Schichten reichen vom Verbindungsaufbau uberdie Sicherung von Transportwegen, die Defintion von Vermittlungsdiensten unddie Fehlerkorrektur bis zu Regeln fur den Ablauf der Kommunikation, die Formder Informationsdarstellung und die Randbedingungen fur Anwenderprogramme[Sch88]. Das Ubertragungsmedium und die Anwendungsfunktionen sind nichtBestandteil der Standardisierung. Bei der Implementierung eines Integrations-systems wird in erster Linie auf die Anwendungsfunktionen eingegangen. DieSchichten des OSI–Modells werden durch die nachfolgend beschriebenen Kopp-lungsmechanismen auf unterschiedliche Weise bedient.

Eine einfache Client-Server Beziehung kann uber Sockets realisiert werden. EinSocket ist ein Verbindungsendpunkt und wird uber eine Netzwerkadresse und einePortnummer identifiziert. Mit Sockets sind Methodenaufrufe uber ein Netzwerkhinweg ausfuhrbar. Aus Programmierersicht werden durch ein Socket die Detailseiner Netzwerkverbindung verdeckt. Allerdings mussen fur den Aufbau einerSocketverbindung die Identifizierungsmerkmale des Servers bekannt sein. DieMethodenaufrufe des Client mussen auf die Programmierschnittstelle des Serversabgestimmt sein. Implementierungen von Sockets existieren auf nahezu allenRechnerplattformen [OH97].

Die Kombination des Hypertext Transfer Protocoll HTTP mit dem Common Ga-teway Interface CGI ermoglicht es einem Client, uber ein html-Formular einProgramm auf dem Server zu starten und dessen Ausgaben per html-Dokumentzu beziehen. Der Datentransport ist an das html-Format gebunden. Fur jedeDatenubertragung muß eine neue Verbindung aufgebaut werden. Zwischen zweiProgrammaufrufen muß der Abfragestatus im Client gespeichert werden, da dasServerprogramm mit jedem Aufruf neu gesartet wird [OH97].

Eine komplette Infrastruktur fur verteilte Softwaresysteme wird mit der Dis-tributed Computing Environment DCE bereitgestellt [Ope93]. DCE ermoglichtdie Trennung von Verwendung und Implementierung eines Softwareprogrammsdurch die Einfurung einer neutralen Schnittstellenbeschreibungssprache und desKommunikationsmechanismus RPC [Ope91]. Daruber hinaus stehen in DCE einNamensdienst, Mechanismen fur Zeitsynchronisierung und die Integration vonPC–Arbeitsplatzen sowie standardisierte Sicherheitsmechanismen zur Verfugung.Mit Hilfe des Distributed File System konnen Dateisysteme verschiedener Rechnerzu einem einzigen, erweiterten Dateisystem zusammengesetzt werden. Die Sicher-heitsdienste, der Namensdienst sowie die Technik, Applikationen uber neutraleSchnittstellen zu kapseln, wurde bei der Entwicklung von CORBA aufgegriffen.Im Vergleich zu CORBA ist jedoch das Systemkonzept von DCE nicht objekt-orientiert, sondern prozedural aufgebaut. Das bedeutet, daß die Komponenten

50


einer DCE–Umgebung und die darin definierten Applikationen nicht durch einfa-che Vererbung und Erweiterung angepaßt werden konnen, sondern gegebenenfallskomplett neu implementiert werden mussen [OHE96].

Ein plattformgebundenes Konzept fur die Integration verschiedener Softwaresy-steme ist das Betriebssystem Windows mit dem Objektmodell DCOM (Distri-buted Component Object Model. Ahnlich wie in CORBA ist mit DCOM dienetzwerktransparente Verwendung von Objekten moglich. Allgemeine und spe-zielle Verzeichnisse und Dienste werden durch das Betriebssystem bereitgestellt[OH97].

Ein umfassende Darstellung und ein Vergleich der Konzepte ist ist in [OHE96]und [OH97] zu finden.

Aus dem Spektrum der moglichen Losungsansatze scheint CORBA am geeig-netsten, da mit CORBA ausdrucklich auch bestehende Softwaresysteme ver-schiedener Rechnerplattformen und unterschiedlicher Programmiersprachen inte-griert werden konnen. Die Technik, bestehende, auch prozedurale Applikationendurch eine objektorientierte Schnittstellenbeschreibung zu kapseln, ermoglicht dieSchaffung eines applikationsubergreifend gultigen Modellschemas. Daruber hin-aus steht mit einer CORBA–Umgebung eine vollstandige Arbeitsumgebung furverteilte Objekte zur Verfugung. Die Verzeichnisse und Dienste dieser Arbeit-sumgebung losen viele der Probleme, die beim Arbeiten mit verteilten Systemenentstehen auf einheitliche Weise.

Wie in Kapitel 2 festgestellt wurde, sind fur eine Kopplung der bestehenden Syste-me zusatzliche Informationen erforderlich, die in Form von Softwarekomponentenbereitgestellt werden mussen. Da auch hier eine plattformubergreifende Nutzungmoglich sein soll, muß fur diese Softwarekomponenten eine Programmiersprachegewahlt werden, die auf mehreren Plattformen verfugbar ist. JAVA erfullt dieseForderung, da sie als plattformunabhangige Sprache entwickelt wurde. Daruber-hinaus lassen sich mit JAVA auch plattformunabhangige Benutzungsoberflachengenerieren. Die beiden Technologien CORBA und JAVA sollen fur die Entwick-lung eines Integrationssystems verwendet werden und werden in den folgendenAbschnitten naher beschrieben.

3.2.2 CORBA - eine Systemarchitektur fur verteilte Objekte

CORBA steht fur “Common Object Request Broker Architecture” und ist einStandard fur Verwaltung von und die Kommunikation zwischen verteilten Soft-wareobjekten. Als Bestandteil von der Object Managing Architecture OMA istin CORBA spezifiziert, wie Softwareobjekte netzwerk- und plattformubergrei-fend angesprochen, transportiert und verwendet werden konnen. Die OMA wirdvon der Object Managing Group OMG, einem nicht profitorientierten Zusam-menschluß zahlreicher Hardwarehersteller, Softwareentwickler und Netzwerkbe-treiber zur Forderung der Objekt–Technologie, entwickelt und festgeschrieben

51


[Red96]. Dabei werden von der OMG lediglich die Inhalte des Standards gelie-fert. Die Implementierung wird durch die Softwarehersteller vorgenommen.

Struktur

Die verschiedenen in der OMA definierten Komponenten sind in Bild 3.4 dar-gestellt. Zentrale Komponente dieser Architektur ist der Object Request BrokerORB, der den Kommunikationskanal zwischen allen beteiligten Ressourcen bildet.In der Gruppe der Common Object Services COS sind eine Reihe von Dienstendefiniert, die allen Objekten und Applikationen im System zur Verfugung stehenund anwendungsunabhangig sind. Die eigentlichen Applikationen sind in den Ap-plication Objects gekapselt und ebenfalls an den ORB angeschlossen. In einemseparaten Block sind die fur ein Anwendungsgebiet definierten Objekte und derenDienste in Form der Common Facilities definiert. Zusammen mit den ApplicationObjects bilden sie eine Arbeitsumgebung (engl.: Framework) fur ein bestimmtesAnwendungsgebiet.

��

�� !�"#��$�%�

&('*),+.-0/214345�6�78796�:8;<1=/>-�3�-?+.-0'A@

BDCFEHGI�J<K�EHG�LNMPOQE IRJ�LNSTG�UVM�K�WXSTJ

Y�MHJZMP[\EHUVE<J<K ]Q^C,K�E<U_C

Y�MHJZMP[PEHUVEHJ<K `MPCba

Y�MHJZMP[PEHUVEHJ<K

c d�egf�h$ikj�f�l�mnf�o\ikp�q%r�stfDq

u�r�v v r�w c dxegf�h4izy�fDq|{~}�h�f�o

��<��?�Z� �H�H�� Z� � � �� N�T�Z�<�� P� �� 2�� Z� � �� ?� � � � � � � � � � �� P� �<�

�#� ��H� �Z�H�?�¡ �� £¢ � � �� H� � �\� � � � � � ¤ � �H�� ¥ � �¡� � � � � �b¦ � �Z� � �§� � ��¦ �H�Z� �¨©�2�Z�� X� � � � �§�Z�

ª¬«�.®?¯°«�±*²,³4´*µ(«�¶·¶�«�±8¸\³T¹º®�´»®?².®½¼A¾

Bild 3.4: Komponenten der Object Managing Architecture (OMA) [OHE96]

Der Object Request Broker (ORB)

Der Object Request Broker (ORB) kann als Objektbus definiert werden [OHE96].Objekte konnen uber ihn Methodenaufrufe an andere Objekte senden und diezugehorigen Ruckgabewerte beziehen. Client- und Serverobjekte konnen dabei

52


sowohl auf verschiedenen Knoten in einem Netzwerk als auch auf unterschied-lichen Rechnerplattformen implementiert sein. Der ORB sorgt dafur, daß dieZugriffe auf entfernt liegende Objekte fur den Client so erscheinen, als waren sielokal.Die Plattformunabhangigkeit wird erreicht, indem samtliche im Gesamtsy-stem vorkommenden Objekte, deren Attribute und Methoden in einer neutra-len Schnittstellenbeschreibungssprache IDL (Interface Definition Language) be-schrieben werden. Fur die Verbindung zwischen den Applikationen und demORB werden fur alle in der IDL-Datei definierten Objekte bei der Softwareer-stellung sogenannte Object Adapter generiert, die die uber den ORB kommendenFunktionsaufrufe umsetzen in Aufrufe im lokalen Adressraum. Das CORBA-Laufzeitsystem verfugt uber Verzeichnisse (engl.: Repositories) der im Systemdefinierten Objekte und deren Lokalisierung. Die folgende Liste gibt einen Uber-blick uber die Merkmale von CORBA [OHE96].

Statische und Dynamische Methodenaufrufe. In einer CORBA Umgebungsind sowohl statische als auch dynamische Methodenaufrufe moglich. Diestatischen Aufrufe werden bereits bei der Softwareherstellung in das Pro-gramm eingebunden und sind dadurch schneller, da die Typprufung beimUbersetzen erfolgt, und die Lokalisierung der Methode feststeht. Andersals andere Kommunikationsmechanismen erlaubt CORBA auch ein dyna-misches Binden zur Laufzeit, mit dem Vorteil, daß bei der Erstellung einesSoftwareprodukts nicht alle Bibliotheken, mit denen das Produkt spatereinmal zusammen verwendet werden soll, bekannt sein mussen. OffenbarerNachteil dieser Methode ist, daß durch die zur Laufzeit durchgefuhrte Typ-prufung und Methodenlokalisierung langere Ausfuhrungszeiten entstehen.

Verknupfungen zu Objekten in anderen Hochsprachen. Die Zuordnung vonden in der Interface Definition Language beschriebenen Strukturen zu denentsprechenden Konstrukten in einer fur die Implementierung gewahltenProgrammiersprache erfolgt in Language Bindings. Derzeit sind Umsetzerfur die Sprachen C, C++, Java und Smalltalk vorhanden. Durch die strikteTrennung von Schnittstelle und der zugehorigen Implementierung konnenauch Programme, die in verschiedenen Sprachen implementiert sind, mit-einander kommunizieren.

Selbsterklarende Komponenten. Durch die Vorhaltung der Schnittstellenbe-schreibungen in den entsprechenden Verzeichnissen konnen zur Laufzeit In-formationen uber Eigenschaften von Objekten ermittelt werden. Dies kannbeispielsweise benutzt werden, um einem dynamischen Funktionsaufruf zurLaufzeit die richtige Parameterliste zusammenzusetzen.

Transparente Funktionsaufrufe. CORBA-Objekte konnen im lokalenAdressraum oder auf einem entfernt liegenden Rechner existieren. Der

53


Benutzer muß sich dabei nicht um die Lokalisierung des Serverobjektes, umUbertragung von Objektdaten, Objektaktivierung oder Byte-Reihenfolgebei der Ubertragung von Daten zwischen verschiedenen Plattformen oderBetriebssystemen kummern. Diese Belange werden im Hintergrund durchdie CORBA-Laufzeitumgebung geregelt.

Polymorphie. Die Strukturen einer CORBA-Umgebung sind Objekte im Sinnedes objektorienterten Programmierens. Damit gehen alle Funktionsaufrufeauch an Objekte, die in der fur sie charakteristischen Weise darauf reagieren.

Komponenten

Softwarekomponenten sind eine besondere Form von objektorientierter Softwa-re. Das Ziel der Komponententechnologie ist es, Softwarekonstrukte zu schaffen,die als abgeschlossene Systeme in beliebiger, “nicht vorhersagbarer” Kombinationverwendet und zu großeren Gebilden zusammengesetzt werden konnen. CORBAunterstutzt die Entwicklung von Komponenten, indem es die netzwerktranspa-rente und plattformubergreifende Verwendung von Objekten ermoglicht und zu-gleich Informationen uber die Struktur der Objekte bereitstellt, die zur Laufzeitanalysiert werden konnen.

Damit sich verschiedene Objekte zu einem sinnvollen Gebilde zusammensetzenlassen, mussen sie eine gewisse Menge gemeinsamer Eigenschaften aufweisen. DieDefinition gemeinsamer Eigenschaften ist auch fur die Interoperabilitat zwischenObjekten, also den Datenaustausch und das gegenseitige Aufrufen von Methoden,erforderlich.

Die gemeinsamen Eigenschaften von Objekten werden in Form von gemeinsa-men Schnittstellen (engl.: Common Interface) implementiert. Die Intention einesCommon Interface liegt darin, Interoperabilitat, Austauschbarkeit, Entkopplungund Wiederverwenbarkeit von Softwaremodulen, die unabhangig voneinander ent-wickelt wurden, zu unterstutzen [AJSK98]. Dieser Ansatz setzt voraus, daß sichfur die Funktionalitat der beteiligten Applikationen ein “gemeinsamer Nenner”finden laßt, der in dem Common Interface abgebildet wird. Gegenuber bilatera-len Schnittstellen (siehe Bild 3.5) bietet diese Struktur den Vorteil, daß eine neueApplikation nur das Common Interface bereitstellen muß und dann automatischZugriff auf alle anderen Applikationen hat, wahrend bei einer bilateralen Struk-tur die Schnittstellen zu jeder anderen Applikation separat implementiert werdenmußten.

Die in einer CORBA-Umgebung definierten Objecte werden auch als CORBABusiness Objects (CBO) bezeichnet. Bei der Definition eines Anwendungsgebietsbilden sie die Dinge ab, mit denen in den Applikationen gearbeitet wird. DasKonzept von CORBA sieht vor, daß diese Objekte unabhangig von einer speziel-len Applikation verwendbar sein sollen und auch in einer nicht vorherbestimmtenWeise zusammenfugbar sein sollen. Mit diesem Ansatz soll eine maximale Flexi-

54


Common Interface

� � � � � ��

� � � � � ��

� � � � � ��

� � � � � ��

� � � ��

� ��

� ��

� ��

� � ��

� � � ��

� � � � ��

� � � ��

��

��

� ��

� ��

� ��

� ��

� ��

� ��

� ��

� ��

� � ��

� � ��

� ��

� ��

� � ��

� ��

! !! !! !

" " "" " "" " "

# ## ## #

$ $$ $$ $

% %% %% %

Bilaterale Schnittstellen Gemeinsame Schnittstellen

Bild 3.5: Vergleich zwischen bilateralen und gemeinsamen Schittstellen

bilitat bei der Verwendung der Objekte erreicht werden.

Die Business Objects bestehen aus drei Einzelkomponenten, die unter Nutzungder Basisdienste Kontakt zueinander halten:

Business Object: Das eigentliche Business Object uberwacht den Speicherbe-reich, die Metadaten und die Konsistenz des Objekts, steuert gleichzeitigenZugriff mehrerer Anwender und reagiert auf die Anfragen von Anwendern.

Business Process Objects: Das Verhalten eines Objekts innerhalb eines Prozeß-modells, die darin definierten Zustande und Methoden werden von einemBusiness Process Objects uberwacht. Außerdem werden hier die Mecha-nismen implememtiert, uber die sich mehrere Objekte zu einem großerenzusammenfugen lassen.

Business Presentation Objects: Zu einem Business Object gehoren ein odermehrere Business Presentation Objects, die das Objekt und seine internenDaten in verschiedenen Sichten fur den Benutzer sichtbar machen.

Container

Besonderer Bedeutung kommt den Modellen zu, in denen die Komponenten zukomplexen Informationseinheiten zusammengefugt werden. Als Fachbegriff wirdhierfur Container verwendet. Container mussen die Rahmenbedingungen festle-gen, unter denen Objekte zusammengesetzt werden konnen. Ein typisches Bei-spiel fur einen Container ist ein Dokument, in das verschiedene Objekte, wieTextkomponenten, Bilder, Tabellen und ahnliches eingefugt werden konnen. DerContainer muß in diesem Beispiel dafur sorgen, wieviel Platz den einzelnen Kom-ponenten fur die Darstellung zur Verfugung gestellt wird und muß Methoden zumSpeichern und Wiederherstellen gemischter Dokumente bereitstellen.

55


Verteiltes Objektmodell

Wahrend die Komponenten das Zusammenwirken verschiedener Objekte auf An-wendungsebene beschreiben, wird mit CORBA gleichzeitig ein verteiltes Objekt-modell auf Systemebene realisiert [Bet94]. In verteilten Objektmodellen ist derAufruf der Methoden der Objekte nicht meht davon abhangig, ob sie sich auf demselben Rechner befinden, oder per Netzwerk auf einem fremden Rechner ange-sprochen werden [Lov97]. Dies wird durch eine strikte Trennung von Schnittstel-len und Implementierungen der Objekte realisiert. Die Schnittstellen werden inneutraler Form netzwerkweit zur Verfugung gestellt. Die Laufzeitumgebung vonCORBA sorgt fur die Weiterleitung von Methodenaufrufen an die zugehorigenImplementierungen. Damit ist die Bindung von Objekten zu einem bestimmtenBetriebssystem aufgehoben.

Granularitat

Die Granularitat einer Schnittstelle ist ein Maß dafur, wie weit die von dieserSchnittstelle angebotenen Objekte in ihre Bestandteile zerlegt werden konnen.Je nach Clientapplikation konnen die Anforderungen an die Granularitat unter-schiedlich sein: ein Stucklistenverwaltungsprogramm benotigt lediglich die Na-men und die Anzahl der in einer Baugruppe verwendeten Komponenten, wah-rend ein FEM–Programm die genauen Abmessungen der Flachen und Kanteneines Bauteil benotigt. Bei der Integration von Gestaltung und Berechnung kannein sehr feingranularer Zugriff sowohl auf die Geometrie als auch auf das Rechen-modell erforderlich sein.

Die Common Object Services

Systeme, in denen Objekte aus verteilten Anwendungen verwendet werden, unter-scheiden sich von lokalen objektorientierten Systemen. Die lokalen Systeme sindvergleichsweise einfach zu handhaben: die Programme laufen in einem einzelnenProzeß auf einem einzelnen Rechner und die Schnittstellen der Objekte sind be-reits bei der Ubersetzung bekannt. Die Betriebssystemumgebung der Objekte istebenfalls bei der Ubersetzung bekannt und damit fest vorgegeben.

In verteilten Systemen hingegen werden zusatzliche Dienste benotigt, mit de-ren Hilfe Objekte lokalisiert, verknupft und transportiert werden konnen. DieObjekte sind unabhangig von einem bestimmten Prozeß und konnen auf ver-schiedenen Betriebssystemen verwendet werden. Es kann vorkommen, daß dieSchnittstelle zu einem Objekt erst zur Laufzeit bekannt ist, sodaß Programmedynamisch gebunden werden mussen. Die hierfur erforderlichen Dienste durfennicht betriebssystemspezifisch an einen Rechner gebunden sein, sondern mussenals allgemein verfugbare Dienste der objektorientierten Umgebung zur Verfugungstehen [McF98].

56


Ein großes Spektrum der fur verteilte Anwendungen benotigten Methoden ist inden Common Object Services definiert. Die Objekte und Methoden dieser Dienstesind per IDL–Definition festgeschrieben und gehoren zur Laufzeitbibliothek jederCORBA-Implementierung. Auf diese Weise wird sichergestellt, daß die Aufrufefur die Erzeugung, Vernichtung, die Benennung, der Transport etc. von Objek-ten auf allen Rechnerplattformen in gleicher Weise zur Verfugung stehen. Imeinzelnen sind folgende Dienste definiert [OHE96]:

Life Cycle Service. In diesem Dienst sind Methoden zum Erzeugen, Kopieren,Verschieben und Loschen von Objekten auf dem ORB definiert.

Persistence Service. Hier werden Methoden bereitgestellt, die es erlauben, Ob-jekte dauerhaft in relationalen oder objektorientierten Datenbanken zu spei-chern.

Naming Service. Mit Hife dieses Dienstes konnen Objekte mit einem netzwerk-ubergreifend gultigen Namen verknupft werden.

Event Service. Uber diesen Dienst konnen Ereignisse, die fur die beteiligten Ap-plikationen von Interesse sind, gebundelt und weitergegeben werden. DerORB sorgt fur die Weiterleitung der Ereignisinformationen.

Concurrency Control Service. Mit diesem Dienst konnen gemeinsame Zugriffeauf Objekte uberwacht und gesteuert werden. Ein wichtiger Mechanismusbeim Simultaneous Engineering.

Transaction Service. Eine einheitliche Schnittstelle fur die Ubermittlung vonDaten zwischen Objekten.

Relationship Service. Dieser Dienst stellt Methoden fur die Erzeugung und dieUberwachung von zwischen verschiedenen Objekten bestehenden Verknup-fungen bereit.

Externalization Service. Dieser Dienst definiert einen Standard fur eine Um-wandlung von Objekten in eine serielle Darstellung und umgekehrt.

Query Service. Zugriffe auf verschiedene Datenbanken werden uber die in diesemDienst beschriebenen Schnittstellen gekapselt.

Licensing Service. Die Nutzungshaufigkeit von Objekten kann mit diesemDienst uberwacht werden. Dabei ist die Uberwachung fur ein einzelnesObjekt, fur einen Rechner, fur eine Sitzung oder fur einen ganzen Bereichmoglich.

Properties Service. Mit diesem Dienst konnen zur Laufzeit Merkmale zu Ob-jekten hinzugefugt werden, indem Merkmalname und ein zugehoriger Wertangegeben werden.

57


Die allgemeinen Dienste sind zum Teil Bestandteil einer CORBA Laufzeitumge-bung und zum Teil Klassen, deren Schnittstelle von den Benutzerobjekten geerbtund implementiert werden muß. Letzteres ist erforderlich, wenn die Implemen-tierung Zugriff auf interne Datenstrukturen einer gekapselten Applikation habenmuß. Beispielsweise muß fur den Persistence Service ein Algorithmus implemen-tiert werden, der es erlaubt, die gesamte interne Struktur eines Objekts in einSpeichermedium zu schreiben. Dennoch ist die Definition dieses Dienstes sinn-voll, da hiermit eine allgemeine Methode zum Speichern von Objekten geschaffenwurde, deren Implementierung fur den Anwender transparent ist.

Common Facilities – Frameworks

Die fur einen bestimmten Anwendungsbereich erforderlichen Objekte und derenMethoden sind in den Common Facilities definiert. Zusammen mit den eigent-lichen Applikationen, den Application Objects, bilden sie die Arbeitsumgebung(engl.: Framework), in der Objekte angewendet werden. Typische Anwendungs-gebiete sind Textverarbeitung, Bankwesen oder CAx–Anwendungen. Die Com-mon Facilities sind noch einmal unterteilt in Horizontal Common Facilities undVertical Common Facilities. Dabei bezeichnen die Horizontal Common Facilitiesdiejenigen Dienste, die allen Applikationen und Objekten des jeweiligen Anwen-dungsgebiets gemeinsam zur Verfugung stehen sollen, und die Vertical CommonFacilities oder auch Domain Services [Red96] die Objekte und Methoden einerbestimmten Anwendung.

Die Common Facilities sind nicht Bestandteil einer CORBA-Laufzeitumgebung.Vielmehr bilden sie eine Anwendung, die eine funktionierende CORBA–Umge-bung voraussetzt. Das zur Zeit am weitesten entwickelte Framework ist das Text-verarbeitungssystem OpenDoc. Dort sind die in Textdokumenten vorkommen-den Objekte, wie Textbausteine, Diagramme, Tabellen oder Bilder als CORBA-Ojekte implementiert und in eine Umgebung eingebettet, die es ermoglicht, auchverteilt vorliegende Dokumente zu bearbeiten, zusammenzufugen, zu speichernoder zu verschieben. Derzeit ist es das Bestreben der OMG, die Common Fa-cilities fur ausgewahlte Anwendungsgebiete ebenfalls mit in den Standard auf-zunehmen. Entwurfe existieren unter anderem fur den CAx–Bereich und dasGesundheitswesen [OMG95].

Vorteile gegenuber anderen Ansatzen

CORBA bietet gegenuber anderen Ansatzen eine Reihe von Vorteilen. Im einzel-nen sind dies folgende Merkmale:

Plattformunabhangigkeit: Diese Eigenschaft von CORBA ermoglicht es, die inder Praxis existierende Vielfalt von Rechnerplattformen zu integrieren. Diesist ein Vorteil gegenuber plattformspezifischen Ansatzen.

58


Objektorientiertheit: Durch den objektorientierten Ansatz von CORBA konnensowohl die Objekte in den Applikationen, als auch die Dienste und Kom-ponenten der CORBA–Umgebung durch Vererbung zusammengefaßt odererweitert werden. Von großem Vorteil ist hier die Moglichkeit, mit der Tech-nik der Kapselung auch prozedurale Applikationen in eine objektorientierteUmgebung zu integrieren.

Netzwerkfahigkeit: CORBA ist ein Kommunikationssystem fur verteilte Objek-te. Dies ist ein Vorteil gegenuber lokalen Programmiermodellen. Zudemwird CORBA damit den Forderungen nach verteilten und vernetzten Ent-wicklungssystemen gerecht.

Framework: Durch die Definition und teilweise Implementierung von Dienstenfur das Arbeiten mit verteilten Objekten liefert CORBA automatisch einInfrastruktur fur verteilte Systeme. Dies ist ein Vorteil gegenuber rein kom-munikationsorientierten Ansatzen.

3.2.3 JAVA als Programmiersprache

Im Zuge der Vernetzung vieler Rechner uber das Internet wurde der Bedarf er-kannt, eine Programmiersprache zu entwickeln, die ohne Ubersetzung auf ver-schiedenenen Rechnerplattformen lauffahig ist. Von Sun Microsystems wurdemit JAVA eine solche Programmiersprache entwickelt [GJS98].

JAVA Virtual Machine

Das Konzept von JAVA besteht darin, daß die Programme nicht direkt ausgefuhrtwerden, sondern von einer Programmumgebung, der Virtual Machine, die einestandardisierte Schnittstelle zu den betriebssystemspezifischen Ressourcen wieSpeicher, Dateisystem oder Bildschirmdarstellung, zur Verfugung stellt. Die Im-plementierung der Virtual Machine ist plattformabhangig, wird aber inzwischenoft als Bestandteil des Betriebssystems zusammen mit diesem ausgeliefert. Im-plementierungen existieren inzwischen fur die verschiedenen Windows Versionen,fur die gangigen UNIX Versionen und auch fur MacOS.

Portabler Programmcode

JAVA ist eine objektorientierte Sprache, die eine vereinfachte Form der Syntaxvon C++ verwendet. Zusammenhangende Klassen werden in Form von packagesgebundelt. Der Programmcode wird mit einem Compiler in den JAVA-Bytecodeubersetzt. Der Bytecode ist die plattformunabhangige Fassung des Programmsund kann uber Netzwerke ubertragen werden. Wahrend anfanglich der Bytecodevon der Virtual Machine interpretiert wurde, wird in den aktuellen Versionen der

59


Bytecode zur Laufzeit von sogenannten Just-in-time Compilern in plattformspe-zifischen Maschinencode ubersetzt.Zur Sprache gehoren ebenfalls zahlreiche Klassen fur die Netzwerkprogrammie-rung, fur die Ein- und Ausgabe, fur die Programmierung von Nebenlaufigkeitsowie eine große Zahl von ebenfalls plattformubergreifend verwendbaren Kom-ponenten einer grafischen Benutzungsoberflache [Tur99]. Der Zugriff auf Daten-banken ist uber eine eigene, zum Standardumfang von JAVA gehorende Schnitt-stellenbeschreibung (JDBC Java Database Connectivity) moglich. Mit den vonden Datenbankherstellern bereitgestellten Datenbanktreibern konnen JAVA Pro-gramme auf diese Weise direkt auf netzwerkweit verteilte Datenbanken zugreifen.JAVA Programme konnen dabei sowohl als Applications als auch in Form vonApplets erstellt werden. Applications sind vergleichbar zu herkommlichen Pro-grammen: sie haben Zugriff auf alle Systemkomponenten, wie Speicher, Festplat-ten oder Bildschirm und werden vom Benutzer gestartet und beendet. Appletshingegen konnen Bestandteil eines Internetdokuments sein. Beim Aufruf des Do-kuments werden sie in einem Webbrowser ausgefuhrt. Die Virtual Machine wirdin diesem Fall durch den Webbrowser bereitgestellt. Start und Beendigung einesApplets erfolgen durch Aufruf und Verlassen des zugehorigen Dokuments. Diezur Ausfuhrung des Applets benotigten Klassen werden zur Laufzeit vom bereit-stellenden Server geladen. Beim Verlassen der Seite oder bei Beendigung desWebbrowsers wird auch das Applet beendet.

JAVA und CORBA

Eine außerst leistungsfahige Grundlage fur die Entwicklung verteilter Appliktio-nen bildet die Kopplung der Technologien JAVA und CORBA [OH97]. CORBAbietet die Moglichkeit, die Daten und Methoden großer, auch bestehender, Syste-me objektorientiert zu kapseln und auch in einem Netzwerk verfugbar zu machen.Mit JAVA konnen Anwendungsprogramme geschaffen werden, die uber CORBAauf diese Daten zugreifen, aber durch Portabilitat von JAVA auf nahezu allenRechnerplattformen lauffahig sind. Auf diese Weise konnen auch portable Be-nutzungsoberflachen fur Systeme geschaffen werden, die mit Objekten aus denCORBA-Servern arbeiten.Wie im Abschnitt 3.2.2 beschrieben, mussen bei der Implementierung von Cli-entanwendungen fur CORBA entweder die Schnittstellenbeschreibungen der Ser-verklassen bei der Ubersetzung des Programmcodes vorliegen, oder die Funkti-onsaufrufe mussen zur Laufzeit uber die wesentlichen langsameren dynamischenSchnittstellen erfolgen. Bei der Verwendung von JAVA als Programmiersprachekonnen problemlos Objekte aus verschiedenen Servern zur Laufzeit zusammen-gefugt werden und trotzdem die schnellen statischen Aufrufe verwendet werden,da die serverspezifischen Zugriffsmethoden als Bestandteil des JAVA Programmsmit zum Client ubertragen werden. Die Verwendung von CORBA–Objekten istdamit nicht mehr an eine plattformabhangige CORBA–Umgebung gebunden, da

60

3.3 Integrierte Systeme

die CORBA–Umgebung gegebenenfalls als JAVA–Applet zusammen mit der ei-gentlichen Anwendung ubertragen werden kann. Bei der Verwendung von Appletswird auf diese Weise ein Zugriff auf die Serverobjekte uber das WWW und damitvon jedem Rechner im Internet aus moglich.


3.3.1 Produktdatenmanagementsysteme

Die Verwaltung von Produktdaten zu bestimmten Konstruktionsstanden wird inzunehmendem Maße mit Hilfe von Produktdatenmanagementsystemen (PDM–Systemen) realisiert. Diese Systeme verwalten und archivieren die wahrend derEntwicklung eines Produkts entstehenden Dokumente. Zu den Dokumenten wer-den Metadaten, wie Bearbeiter, Konstruktionsversion, Freigabestatus sowie Pro-jekt– und Kosteninformationen verwaltet. Zudem konnen in den Systemen dieAbhangigkeiten zwischen verschiedenen Dokumenten abgebildet werden. Auf die-se Weise bilden PDM–Systeme die zentrale Datenbasis fur großere Entwicklungs-projekte.Aktuelle Forschungsarbeiten zielen darauf ab, verschiedene PDM–Systeme zu ei-nem firmenubergreifenden Gesamtsystem zu integrieren und ein Produktdaten-management auch uber raumlich entfernte und verteilte Datenbestande zu reali-sieren [AGL98].In Zusammenhang mit PDM–Systemen werden in Workflow–Systemen Arbeits-prozesse und die zugehorigen Informationsflusse abgebildet. In Zusammenarbeitmit einem PDM–System stellt ein Workflow–System je nach Bearbeitungsstandeiner Aufgabe die notigen Informationen und Dokumente zusammen und liefertsie an den Arbeitsplatz des fur den nachsten Bearbeitungsschritt zustandigenSachbearbeiters. Nach Erledigung der Teilaufgabe werden die veranderten oderneu erzeugten Dokumente an das Workflow–System gegeben und dort archiviertoder entsprechend des definierten Prozesses weitergeleitet.PDM–Systeme und Workflow–Systeme arbeiten dokumentorientiert. Das bedeu-tet, sie stellen anhand der Metadaten und nach bestimmten Auswahlkriterien dieDokumente zusammen, die der Anwender fur die Bearbeitung einer Teilaufgabebenotigt. Die inhaltliche Bearbeitung der Dokumente erfolgt mit den dafur vorge-sehenen Programmen, wie CAD–Systemen oder Berechnungssystemen. Dadurcheignen sich diese PDM–Systeme gut fur die Realisierung einer losen Kopplung(vergleiche Abschnitt 2.5.1).

3.3.2 Feature Modellier–System FEAMOS

Das System FEAMOS ist ein Modellierungssystem fur die rechnerunterstutzteProduktentwicklung. FEAMOS steht fur Feature-Modellier–System und ver-

61


wendet ein eigenes, aus Features aufgebautes Datenmodell. Features, werden indiesem Kontext als Konstruktionselemente definiert, die aus Geometrieinforma-tionen, aus semantischer Information oder aus beidem bestehen konnen [Rie94].Das System ermoglicht sowohl die Modellierung mit bestehenden Features alsauch die Definition neuer Features. Neben den Geometriefeatures sind im Sy-stem Positionier-, Toleranz- und Normteilfeatures definiert. Die Geometriemo-dellierung erfolgt unter Verwendung des Modellierkerns ACIS.

Die Erstellung neuer Produkte erfolgt, indem neue, produktspezifische Featureszusammen mit bereits bestehenden in einem Modell zusammengefugt werden. Dadie Modelle aufgrund der Featuredefinition bereits Semantik enthalten, konnendiese Informationen direkt fur Berechnungen verwendet werden. Die Beschrei-bung der Modelle erfolgt in einer eigenen, an EXPRESS angelehnten, SprachePDGL [Rie94].

3.3.3 Objektorientierter Integrationsprozessor OBIP

An der Ruhr–Universitat Bochum wurde das Konzept fur objektorientierte In-tegrationsprozessoren fur die Integration von Gestaltung und Berechnung ent-wickelt und implementiert. Ein Integrationsprozessor (kurz: INPRO) ist hier einKopplungsbaustein, der zwei verschiedene CA–Systeme miteinander verknupft.Ein INPRO extrahiert aus den jeweiligen Wirtssystemen die erforderlichen In-formationen und fugt diese zu einem eigenen, objektorientierten Datenmodellzusammen, das in einer objektorientierten Datenbank gespeichert wird [WB97].Dabei muß fur jeden zu koppelnden Abschnitt des Produktentstehungsprozessesein spezifischer INPRO konfiguriert werden. Dies geschieht, indem ein allgemei-ner INPRO fur die spezifische Kopplungsaufgabe konfiguriert und angepaßt wird.In dem allgemeinen INPRO sind Methoden fur die Instanzierung und Speiche-rung von Konstruktionsobjekten sowie eine Kommunikationsinfrastruktur undeine kontextsensitive Benutzungsoberflache implementiert.

Eine konkrete Auspragung eines INPRO’s ist ein Integrationsprozessor fur dieKopplung von Gestaltung und Berechnung. Diese Komponente enthalt spezi-fische Objekte und Methoden fur die Verknupfung von Geometriemodellierernund Berechnungssystemen. Die Ankopplung der Applikationen geschieht uberspezifische Module die das Datenmodell des INPRO’s in das Datenmodell der je-weiligen Applikation transformieren. Als Kommunikationssystem wird CORBAverwendet.

Fur eine rechnerbasierte Untersutzung von Entscheidungsprozessen bei der Mo-dellbildung und fur die Bewertung von Berechnungen ist eine Wissensverabeitungin das System integriert [BW98].

62


3.3.4 Projekt ANICA

Im Projekt ANICA wurde ein System geschaffen, mit dem verschiedene CAD–Systeme direkt miteinander gekoppelt werden konnen. ANICA steht furANalysis of access Interfaces of various CAx systems. Der Bedarf fur eine di-rekte Kopplung entstand aus der Tatsache, daß die bisher praktizierten Kopplun-gen uber Dateien in standardisierten Formaten mit numerischen Ungenauigkei-ten und Informationsverlusten durch nicht umkehrbare Konvertierungen behaftetsind [AJSK98]. Der Losungsansatz besteht im wesentlichen aus der Wahl einesKommunikationssystems und aus der Definition einer standardisierten Zugriffs-schnittstelle.

Kommunikationssystem

Als Kommunikationsinfrastruktur fur ANICA wurde CORBA gewahlt, weil COR-BA das Konzept einer einheitlichen, gemeinsamen Schnittstelle der beteiligtenApplikationen unterstutzt. Gleichzeitig ist mit CORBA eine direkte Kopplungvon Applikationen moglich.

Definition einer Zugriffsschnittstelle

Die Objekte der gemeinsamen Zugriffsschnittstelle wurden aus STEP [ISO94] ab-geleitet. In einem als Architecture Mining bezeichneten Prozeß wurde untersucht,welche Methoden zu diesen Objekten in verschiedenen CAD–Systemen existierenund welche Parameter diese Methoden benotigen. Im nachsten Schritt wurdendie gefundenen Methoden generalisiert und daraus eine allgemeine Schnittstellen-definition fur den Zugriff auf Geometriemodelle abgeleitet. Anschließend wurdendie definierten Funktionen durch Abbilden der Parameter und Methodennamenauf die CAD–System spezifische Notation implementiert [AJSK98].

Anwendung

Im Teilprojekt ProDMU wurde die Anwendbarkeit des Ansatzes nachgewiesen.Exemplarisch wurden die CAD–Systeme Pro/ENGINEER und CATIA mit dendefinierten Schnittstellen in eine CORBA Umgebung integriert. Fur eine Bau-raumuntersuchung wurden dann ein in Pro/ENGINEER und ein in CATIA er-zeugtes Bauteil in einer CATIA Sitzung zu einer Baugruppe zusammengefugt.Dabei wurden beide Modelle als Objekt zur Laufzeit aus den jeweiligen Applika-tionen zusammengfugt. Durch die direkte Kopplung wurden zum einen die obengenannten Nachteile der Dateikonvertierung aufgehoben und zum anderen eineZeitersparnis von ca. 20 % erreicht [SAKJ98]. Gleichzeitig konnten die bei derKollisionsprufung als kritisch erkannten Bereiche in den jeweiligen Originalmo-dellen markiert werden.

63


Die Probleme dieser Anwendung lagen in der Erzeugung von Geometrien inden jeweiligen CAD–Systemen. Wahrend der Export von Flachenmodellen ausPro/ENGINEER heraus unproblematisch ist, konnen keine reinen Flachenmodel-le zu einem bestehenden Parametrikmodell zugefugt werden [SAKJ98].

Datenmanagement

Ein zentrales Problem bei der Verwendung von verteilten Objekten ist die persi-stente Speicherung. Solange die Speicherung in den systemspezifischen Dateifor-maten erfolgt, ist die Verwendung von Objekten immer noch an die Verfugbar-keit des zugehorigen CAD–Systems gebunden. Um ein wirklich portables Objektzu erhalten, muß entweder die Applikation, in der das Objekt erstellt wurde,zusammen mit dem Objekt gespeichert werden, oder ein einheitliches, fur alleApplikationen lesbares Format verwendet werden. Da die in ANICA verwende-ten Objekte auf STEP beruhen, wurde ein zentraler Datenserver eingerichtet,der alle Objekte in einer objektorientierten Datenbank speichert. Das konzep-tionelle Modell der Datenbank ist durch die Objektklassen von STEP gegeben.Ein der Datenbank vorgelagerter Object Manager wandelt die Datenbankeintragein die von den Applikationen benotigten Objekte und uberwacht gleichzeitig dieKonsistenz bei parallelen Zugriffen.Hauptinteressent der Entwicklungen ist die Automobilindustrie, in der zur Zeitnoch in verschiedenen Fachabteilungen unterschiedliche CAD–Systeme eingesetztwerden. Fur Bauraumuntersuchungen und im Rahmen der Entwicklung des Di-gital Mockup (DMU) sollen die Modelle der verschiedenen Systeme zu einemGesamtmodell zusammengefugt werden konnen.

3.3.5 Integrationsumgebung CORSICA

Ein integriertes Ingenieursystem auf der Basis eines verteilten Produktmodells istin der Integrationsumgebung CORSICA realisiert. CORSICA steht fur CORBA-und STEP- basierende Integrationsumgebung fur CAx-Verfahren und wurde ander Universitat-GH Paderborn entwickelt [Hah98]. Das System verwendet eindurchgangiges, STEP-basiertes Modellschema das auf alle beteiligten Applika-tionen abgebildet wird. Die Systemarchitektur von CORSICA beruht auf imwesentlichen auf die drei folgenden Objektarten:

Intelligente Objekte. Die einzelnen CAx–Systeme werden durch die intelligenteObjekte gekapselt. Die Schnittstellenbeschreibung der intelligenten Objekteumfaßt Mechanismen fur die modelltechnische, die prozeßtechnische und diesystemtechnische Kopplung der CAx–Systeme. Das bedeutet, daß die intel-ligenten Objekte die im integrierten Ingenieursystem existierenden CAE–Werkzeuge mitsamt einer Integrationsschicht reprasentieren, die als Kop-pelelement die proprietare Kommunikationsschnittstelle an die standardi-

64


sierte Schnittstellenspezifikation des integrierten Ingenieuresystems anpaßt[Hah98].

Offene Objekte. Diese Objekte reprasentieren die Bestandteile des Produktmo-dells, die sich innerhalb der der integrierten CAx–Werkzeuge befinden. Die-se Objekte fuhren das Produktmodell und die in den Werkzeugen auf dasProduktmodell definierten Operationen zu einem einheitlichen objektorien-tierten Modell zusammen [Hah98].

Logische Objekte. Die Verbindung zwischen den verschiedenen Instanzen einesObjektes in den einzelnen CAx–Systemen wird uber die logischen Objek-te hergestellt. Damit werden die auf die intelligenten Objekte verteiltenPartialmodelle zu einem verteilten Produktmodell zusammengefugt.

Das System wird um zahlreiche Basisdienste, wie Identifikationsdienste, System-managementdienste und einen Constraintmanager zur Uberwachung systemuber-greifender Zwange erganzt. Mit dem System wurde die Kopplung des CAD–Systems Euclid3 und eine EMV–System (ein Programm zur Berechnung Elek-tromagnetischer Vertraglichkeit) realisiert.

3.3.6 Konstruktionsanalyse- und Leitsystem KALEIT

Im Rahmen des von der Deutschen Forschungsgemeinschaft geforderten Sonder-forschungsbereiches 203 “Rechnerunterstutzte Konstruktionsmodelle im Maschi-nenwesen” wurde ein Konzept fur ein System zur durchgangigen Unterstutzungdes Konstruktionsprozesses erarbeitet, das am Institut fur Maschinenkonstruk-tion -Konstruktionstechnik der TU Berlin in dem System KALEIT umgesetztwurde. Das System gliedert sich in die vier Hauptmodule Aufgabenanalysepro-zessor, Losungskoordinationsprozessor, Konstruktionsleitsystem und Speicherbe-reich [Fel89]. Fur die Speicherung der produktbezogenen Daten wird ein eigenesDatenmodell verwendet. Bei der Durchfuhrung von Entwicklungsaufgaben bautdas Modell eines Entwicklungsschrittes auf den im vorherigen Schritt erzeugtenDaten auf. Auf diese Weise wird eine durchgangige Nutzung der Daten uber alleEntwicklungsschritte erreicht [Bei90].Das Klaren und Prazisieren der Anforderungen wird durch den Aufgabenanalyse-prozessor unterstutzt. Diese Komponente verwendet eine vorgegebene Liste vonHauptmerkmalen und stellt fur die verschiedenen Merkmale zahlreiche Assoziati-onshilfen bereit. In einem Analyseteil wird anhand der Anforderungen uberpruft,ob sich in der Datenbasis bereits eine Losung fur diese Aufgabe befindet, die ge-gebenenfalls herangezogen werden kann [Stu90].Der Losungskoordinationsprozessor soll den Anwender bei Planung der einzelnenKonstruktionsschritte unterstutzen, indem er die verfugbaren Rechnerwerkzeu-ge, deren erforderliche Eingabedaten und ihre Ergebnisse bereitstellt. Er stellt

65


damit die Verbindung zwischen den Arbeitsschritten beim Konstruieren und denverfugbaren Rechnerwerkzeugen her.

Der eigentliche Entwicklungsprozeß wird durch das Konstruktionsleitsystem un-terstutzt. Dabei werden die vom Aufgabenanalyseprozessor ermittelten Aufgabenin der erforderlichen Reihenfolge ausgefuhrt. Das Zusammenwirken von Metho-den, Modellen und Daten wird als Operationsstruktur bezeichnet. Dabei exi-stieren fur verschiedene Branchen unterschiedliche Grundmuster von Operations-strukturen.

Die im Entwicklungsprozeß benotigten Methoden, Modelle und Prozeßdaten wer-den im Speicherbereich verwaltet. Damit war in KALEIT eine Form eines inte-grierten Produktmodells verwirklicht. Neben den Modellinformationen waren inder Operationsstruktur auch die erforderlichen Metainformationen fur eine ziel-gerichtete Anwendung von Methoden enthalten. Die Methoden waren dabei aufdas Datenmodell abgestimmt.

3.3.7 Das System mfk

Am Lehrstuhl fur Konstruktionstechnik der Universitat Erlangen Nurnberg wur-de das System mfk als Assistenzsystem fur die Beschreibung und Analyse vonBauteilen und Baugruppen entwickelt. Das System ist als Aufsatz zu einem kom-merziellen CAD–System konzipiert, verwendet aber ein eigenes, semantisches, re-lationsbasiertes Produktmodell. Fur die Visualisierung, fur mathematisch geome-trische Berechnung und fur die Reprasentation der geometrischen Elemente wirddie Funktionalitat des CAD–Systems verwendet. Ebenso erfolgt die Benutzerin-teraktion uber eine Erweiterung der Benutzungsschnittstelle des CAD–Systemsund damit in der fur den Konstrukteur vertrauten Arbeitsumgebung [Lof97].

Produktmodell

Das Produktmodell von mfk besteht aus den drei Grundelementen Parameter,Formelement und Beschreibungsmerkmal, die uber Relationen miteinander ver-knupft sind. Die Relationen dokumentieren dabei die wahrend des Konstruk-tionsprozesses dynamisch wachsenden Zusammenhange zwischen den Informati-onseinheiten [Web92]. Das Produktmodell ist die gemeinsame Datenbasis fur denAnalyseteil und den Syntheseteil des Systems.

Integration von Berechnungsmethoden

In das System sind verschiedene Berechnungsmethoden eingebunden, die direktauf der Datenbasis arbeiten. Unter anderem wurde fur die Implementierung die-ser Methoden ein wissensbasiertes System integriert. Externe Methoden konnenentweder in dem wissensbasierten System implementiert werden und arbeiten

66


dann ebenfalls auf der Datenbasis oder sie konnen Eingangsparameter in Formeiner Datei oder aus der Programmierschnittstelle des Systems beziehen.

3.3.8 iViP–Projekt

Das Projekt Innovative Technologien und Systeme fur die integrierte VirtuelleProduktentstehung (kurz: iViP) ist ein von Industrie und Forschungseinrichtun-gen unterstutztes Projekt mit dem Ziel verbesserte technische Rahmenbedingun-gen zur Schaffung technischer Produkte zu erlangen. Im Vordergrund des Pro-jekts steht die Entwicklung und industrielle Einfuhrung innovativer Werkzeugefur die Produktentstehung auf der Basis einer offenen Systemarchitektur [KTA98].Mit dieser Architektur soll eine Produktentstehungsumgebung geschaffen werden,die eine integrierte Funktionaliat fur eine phasenubergreifende Aufgabenbearbei-tung zur Verfugung stellt. Im Mittelpunkt der Entwicklung steht der “DigitaleMaster”, der als verbindlicher Informationstrager samtliche fur die Produktent-stehung und alle Folgephasen relevanten Daten eines Produkts enthalten soll.Die dem Projekt zugrundeliegende iViP–Architektur sieht die Schaffung eineroffenen Integrationsplattform vor, die auch die Einbindung bestehender hetero-gener Systemwelten unterstutzt [iVi99]. Das Projekt ist in die sechs Cluster:Infrastruktur Prozeßmanagement, Infrastruktur Datenmanagement, InnovativeGestaltungswerkzeuge, Aufbau und Validierung virtueller Produkte, Werkzeugezur virtuellen Fertigungserprobung und Referenzmodelle zur Fertigungserprobunggegliedert.

Systemarchitektur

In den Projekten der iViP–Cluster “Infrastruktur – Prozeßmanagement” und “In-frastruktur – Datenmanagement” wird die softwaretechnische Basis fur das Ge-samtprojekt erarbeitet. Die Basis ist eine CORBA–basierte Integrationsplatt-form, die ein Framework fur die in den anderen Teilprojekten entstehenden Soft-waremodule darstellt (vergleiche Bild 3.6).Grundlage bilden die Systemdienste fur die Anwenderverwaltung, das Manage-ment von Anwendersitzungen und die Verwaltung der iViP–Werkzeuge (Kom-ponenten). Die eigentlichen Applikationen sind uber objektorientierte Schnitt-stellenbeschreibungen gekapselt und in das Gesamtsytem integriert. Bei derImplementierung wurde weitgehend auf international etablierte Standards zu-ruckgegriffen. Fur die Bedienung des Systems wurde mit dem iViP–Client eineeigene Benutzungsoberflache geschaffen. Der iViP–Client stellt einen definiertenUmfang an Grundfuktionalitat zur Verfugung, der durch Erganzung von anwen-dungsspezifischen Plug–ins erweitert werden kann [iVi00].Fur die Nutzung von Softwarekomponenten ist das Konzept Software on demandvorgesehen. Hiermit konnen Nutzern Dienste zur Verfugung gestellt werden, diebeispielsweise nicht an ihren lokalen iViP–Servern installiert sind. Dabei konnen

67


Bild 3.6: iViP–Softwarearchitektur [iVi00]

die Methoden entweder zum Anwender transportiert oder uber Remote–Aufrufeauf der Servermaschine verwendet werden.

3.3.9 Virtuelle Berechnungskompetenzzentren

Eine Architektur “virtueller Berechnungskompetenzzentren fur die Integrationvon Gestaltung und Berechnung” wird in [Wol98] beschrieben. Dort ist einBerechnungs-Kompetenz-Zentrum definiert als ein Knotenpunkt im Internet, andem Berechnungsdienstleistungen einer bestimmten Fachdisziplin mit hoher Fach-und Problemlosungskompetenz angeboten werden. Die Leistungen eines solchenKompetenz–Zentrums umfassen dabei die Beratung, die Erstellung differenzierterBerechnungsangebote, sowie die Durchfuhrung und Dokumentation von Berech-

68


nungen. Die Architektur besteht aus den Komponenten Broker, Berechnungs-manager und einer objektorientierten Methodenbank. Die Kommunikation dieserKomponenten erfolgt uber das Internet unter Nutzung standardisierter Protokol-le. Die vom Kompetenzzentrum angebotenen Berechnungen konnen mit Geome-triemodellen verknupft werden, indem eine Verknupfung der einzelnen Parameterhergestellt wird. Um die Abbildung der Objekte im Rechenmodell zu denen imGeometriemodell zu ermoglichen, wurde ein Engineering–Meta–Modell EMM de-finiert, das sich an der Baustruktur orientiert. Das Zusammenspiel der einzelnenKomponenten wird im folgenden erlautert:

Broker. Der Broker ist fur die Koordinierung der Arbeitsablaufe in der verteil-ten Umgebung zustandig. Er uberwacht und protokolliert die Zugriffe inder verteilten Umgebung. Zudem sorgt er fur eine gezielte Informations-bereitstellung bezuglich der von einzelnen Kompetenzzentren angebotenenDienstleistungen und vermittelt Berechnungsanfragen mit einer bestimmtenThematik an ein geeignetes Kompetenzzentrum weiter.

Berechnungsmanager. Der Zugriff auf die Methoden eines Kompetenzzentrumserfolgt uber den Berechnungsmanager. Diese Komponente stellt die Infor-mationen uber die angebotenen Methoden zur Verfugung und unterstutztden Anwender bei der Auswahl einer geeigneten Methode mit Hilfe eineswissensbasierten Systems. Je nach Art und Umfang der Methode unter-stutzt sie den Anwender auch bei der Durchfuhrung der Berechnung, indemsie die Berechnung startet, den Benutzer zur Eingabe zusatzlicher Infor-mationen oder von Geometrieverknupfungen auffordert und die Ergebnissedokumentiert.

Objektorientierte Methodenbank. Um eine einheitliche Beschreibung der voneinem Kompetenzzentrum angebotenen Methoden zu erhalten, werden Me-thoden in einer objektorientierten Methodenbank gehalten. Darin werdenneben den moglichen Geometrieverknupfungen einer Methode auch außereLasten, Werkstoffe, zusatzliche Bedingungen und assoziierte Bewertungs-verfahren verwaltet.

3.3.10 Vergleich der Systeme

In der folgenden Ubersichtstabelle werden die Datenmodelle, der Kommunikati-onsmechanismus und die Offenheit der betrachteten Systeme miteinander vergli-chen. Ein Maß fur die Offenheit ist der Aufwand zur Einbindung neuer Methoden.Die Tabelle zeigt, daß in den meisten Fallen die Berechnungssoftware an die Mo-dellstruktur und an die Plattform des CAD–Systems gebunden ist. Bei einemWechsel einer der beiden Komponenten muß die Kopplung neu implementiertwerden. Eine Integration neuer Methoden wurde vereinfacht, wenn sowohl fur

69


System Datenmodell Kommunikation Einbindungneuer Methoden

FEAMOS eigenes — mussen im System(STEP angelehnt) formuliert sein

OBIP eigenes CORBA Anpassung and das(objektorient.) OBIP Datenmodell

ANICA STEP CORBA —OBIP eigenes CORBA Anpassung and das

(objektorient.) OBIP DatenmodellCORSICA STEP CORBA Implementierung der

CORSICA MetaklassenKALEIT eigenes — Implementierung

in CATIA APImfk semant. relation. Socket auf das Modell

(Pro/E angelehnt) abgestimmte APIiViP eigenes CORBA Implementierung der

iViP MetaklassenVirtuelle Eng. Meta Modell Socket auf das ModellBer. CC (Pro/E angelehnt) abgestimmte API

lose Verkn. moglich

Tabelle 3.1: Gegenuberstellung der betrachteten Integrationssysteme

70

3.4 Integrationsstrategien

die Zugriffe auf die Geometriedaten, als auch auf die Rechenmodelle einheitli-che Schnittstellen existierten. Durch eine Trennung von Schnittstellendefinitionund Implementierung, wie sie durch CORBA realisiert werden kann, konnte dieBindung an eine Rechnerplattform aufgehoben werden.Die Bindung an ein spezielles CAD–System wird durch die Verwendung von STEPaufgelost, wie sie im Projekt ANICA realisiert wurde. Jedoch beschrankt sichANICA auf den Austausch von Geometriedaten. Fur eine Integration von Berech-nungen mussen aber auch nichtgeometrische Daten verarbeitet werden konnen.Daruberhinaus sind in STEP nur Modelle, aber keine Methoden definiert. DieAnwendung von Berechnungsmethoden als Werkzeug erfordert den programmge-steuerten Zugriff uber definierte Funktionen fur die Geometrieanalyse, die Geo-metrieerzeugung und die Geometrievariation.

3.4 Integrationsstrategien

Aus den oben vorgestellten Integrationssystemen und den im vorigen Kapitel be-schriebenen Merkmalen lassen sich fur die Integration von Berechnungsmethodenin den Gestaltungsprozeß im wesentlichen drei Strategien ableiten:

Integriertes Produktmodell. Bei dieser Strategie wird versucht, bestehendeoder neu geschaffene Produktmodelle so zu erweitern, daß alle fur eine Be-rechnung benotigten Daten in dem Modell enthalten sind. Beispiele hierfursind das applikationsneutrale Produktmodell STEP und die auf bestimmteCAD-Systeme aufbauenden Produktmodelle der Systeme mfk oder FEA-MOS.

Standardisierte Zugriffsmethoden. Ein anderer Schwerpunkt liegt in der Defi-nition standardisierter Zugriffsmethoden auf die bestehenden Modelle. DieZugriffsmethoden sind dabei haufig an die zugrundeliegenden Modelle ge-bunden. In einigen Systemen geht daher die Vereinheitlichung der Zugriffs-schnittstelle mit einer Erweiterung oder Modifikation des Produktmodellseinher. Das Spektrum der verwendeten Zugriffsmethoden reicht dabei vonKommunikationsstandards auf Systemebene, wie IPC oder TCP/IP, uberCAD-System spezifische statische oder dynamische Bibliotheken bis hin zurobjektorientierten Kapselung und Integration in eine verteilte Arbeitsumge-bung. Das Ziel aller Zugriffsmethoden ist es, einen einheitlichen Zugriff aufdie Geometriedaten zu erhalten, oft in Zusammenhang mit einer Einbettungin komplexe Systemumgebungen und Schaffung eines Netzwerkzugriffs.

Modelltransformation. Eine weitere Technik ist die Modelltransformation, beider die Modelle des einen Systems in die Modelle des anderen Systemsuberfuhrt werden. Modelltransformationen sind in der Regel mit Informa-tionsverlust verbunden und daher nicht umkehrbar. Die Transformationen

71


konnen in beide Richtungen erfolgen: ein Geometriemodell kann fur dieWeiterverarbeitung in einem Berechnungssystem aus der CAD-System in-ternen Darstellung in ein neutrales Austauschformat ubersetzt werden undaus dem Ergebnis einer Berechnung kann durch Ubersetzen und Zuordnenvon Merkmalen ein Geometriemodell erzeugt werden.

In Tabelle 3.2 sind die Hauptmerkmale der drei Strategien dargestellt. AllenStrategien ist gemein, daß die Geometriemodelle die Kernmodelle sind, zu derenSchaffung oder Variation Berechnungsmethoden zur Hilfe genommen werden.

Strategie Vorteile Nachteile

IntegriertesProduktmodell

Redundanzfreie, konsi-stente Datenbasis fur alleApplikationen

Einbindung bestehenderSysteme aufwendigKomplexes monoli-thisches Datenmodell

StandardisierteMethoden

Anpassung weiterer Ap-plikationen moglichFlexibler Zugriff auf inter-ne Modelle.

Zusatzlich Modell- undProzeßkopplung notigZusatzlich Konsistenz-uberwachung erforderlich

Modell-transformation

Einfache Anbindung be-stehender Applikationen

Mehrfache Iterationenfuhren zu Datenverlust

Tabelle 3.2: Hauptmerkmale der Integrationsstrategien

Im Hinblick auf eine Modellkonsistenz und eine prozeßubergreifende Nutzungvon Daten ware die Anwendung eines integrierten Produktmodells die beste Lo-sung. Allerdings ist ein solches Modell mit den bestehenden Applikationen nichthandhabbar. Eine Modelltransformation scheidet aus, da wegen des auftreten-den Datenverlusts mehrere Iteration einer Operation nicht durchgefuhrt werdenkonnen. Fur das weitere Vorgehen werden daher standardisierte Zugriffsmetho-den gewahlt. Anzustreben ist dabei die Bildung von Applikationsgruppen, vonSystemen die fur ahnliche Funktionalitat gleiche Methoden verwenden.

3.5 Zusammenfassung

Die beschriebenen Integrationslosungen bieten alle die Moglichkeit, in den Gestal-tungsprozeß integrierte Berechnungen durchzufuhren. Dabei sind alle Losungenentweder an ein CAD–System oder an eine eigenes Produktmodell gebunden. DieBerechnungsmethoden sind damit nicht ohne Anpassungsaufwand in einer Um-gebung aus verschiedenen CAD–Systemen anwendbar. Neue Methoden mussen

72

3.5 Zusammenfassung

immer fur das vorhandene System entwickelt oder an die Systemumgebung ange-paßt werden. Die Forderung nach Offenheit der Systeme ist damit nicht erfullt.Durch die Entwicklung von CORBA und JAVA ist inzwischen die plattform-und netzwerkubergreifende Verwendung von Softwarekomponenten moglich ge-worden. Diese Standards sind aber allgemeine Ansatze, in denen noch keineModellstrukturen definiert sind. In diesem Bereich steht mit STEP ein umfas-sender Ansatz zur Verfugung, der aber parallel zu den aktuellen CAD–Systemenentwickelt wird und derzeit nicht in der Lage ist, die Modelle der heutigen CAD–Systeme abzubilden.Im Projekt ANICA wird eine plattformubergreifende Kopplung zweier CAD–Systeme realisiert, allerdings werden hier nur Geometriedaten ausgetauscht. Furdie Integration von Berechnungen mussen die Modelle um die nichtgeometrischenDaten erweitert werden. In der weiteren Arbeit wird daher das Konzept einerobjektorientierten Kapselung von Geometriemodellierern fur die Integration vonBerechnungssoftware erweitert.

73


74

4 Anforderungen an dasIntegrationssystem

Aus den in Kapitel 2 vorgestellten Merkmalen von Gestaltung und Berechnungund denn in Kapitel 3 festgestellten Defiziten lassen sich Anforderungen an einIntegrationssystem ableiten. Generelle Zielsetzung ist dabei, den Entwicklungs-prozeß zu verkurzen, indem das rechnerunterstutzte Gestalten und Berechnen ineinem integrierten System zusammengefaßt werden. In dem Integrationssystemsollen bestehende Gestaltungs- und Berechnungssysteme miteinander gekoppeltwerden konnen. Die Integration muß dabei auf eine verbesserte Funktionalitatdes Gesamtsystems abzielen [WN99]. In diesem Kapitel wird eine Liste mit denAnforderungen an das Integrationssystem aufgestellt. Die Gliederung der An-forderungen orientiert sich an den Integrationsebenen des KOMFORCE Arbeits-kreises, wonach eine Integration in den drei Ebenen Modellebene, Systemebeneund Prozeßebene erfolgen muß [KOM96]. Die vierte Ebene dieses Konzepts, dieMethodenebene entfallt in diesem Fall, da die zu integrierenden Berechnungs-programme Gegenstand der Integration sind, und somit durch die anderen dreiEbenen beschrieben werden.

4.1 Anforderungen der Teilbereiche

Allgemeine Problembeschreibung

Aus den allgemeinen Systemen der fruheren Kapitel werden Anforderungen furein konkretes Integrationssystem zusammengestellt. In dem System sollen das pa-rametrische CAD–System Pro/ENGINEER und das Berechnungsprogramm furSchraubenverbindungen BOLT [BOL94] integriert werden. Diese Systeme stehenstellvertretend fur aktuelle verwendete Geometriemodellierer und fur eine großeZahl von Berechnungsprogrammen. Der Integrationsansatz soll daher so gewahltwerden, daß er auf ahnliche Konfigurationen ubertragbar ist.

Modelle

Im CAD–System wird ein parametrisches Geometriemodell fur die Abbildung dergeometrischen Daten verwendet. Geometrische Eigenschaften und Topologiein-

75

4 Anforderungen an das Integrationssystem

formationen sind uber die Programmierschnittstelle des Systems zuganglich.Das Berechnungprogramm verwendet fur die Modelldarstellung benannte Para-meter. Andere Objekte als Parameter sind in dem Modell nicht enthalten. UberSteuerparameter konnen unterschiedliche Modellkonfigurationen und bestimmteRechenoperationen, wie Auslegung, Nachrechnung oder Optimierung ausgewahltwerden.

Programme

Eine Integrationslosung sollte sich in eine vorhandene Hardware- und Softwa-reumgebung einfugen [Abe97]. Die gewahlten Programme existieren zwar beideauf der selben Rechnerplattform und waren daher auch auf einem einzelnen Rech-ner koppelbar, der Losungsansatz soll aber auf verschiedene Plattformen uber-tragbar sein und dabei auch Systeme verschiedener Plattformen zusammenfuhrenkonnen. Dies impliziert, daß der Integrationsansatz auch netzwerkubergreifendarbeiten muß.Die Programmierschnittstelle des CAD–Systems ist in der Sprache C implemen-tiert. Das Berechnungsprogramm ist in FORTRAN implementiert.

Prozesse

Die prozeßtechnische Integration muß dafur sorgen, daß sich das Berechnungpro-gramm an verschiedenen Stellen des Gestaltungsprozesses als Werkzeug einsetzenlaßt. Das bedeutet, daß die in Bild 2.6 auf Seite 29 dargestellten Systemwechselzu einem beliebigen Zeitpunkt moglich sind und sich die beiden Teilprozesse “Ge-stalten” und “Berechnen” zu einem durchgangigen Gesamtprozeß zusammenfugenlassen. Dabei muß insbesondere der systemubergreifende Informationsaustauschfur die Schritte ermoglicht werden, an denen beide Systeme beteiligt sind. Wei-terhin muß der Integrationsansatz sicherstellen, daß die innerhalb eines Systemsbestehenden Teilprozesse und Iterationen durchgefuhrt werden konnen. Voraus-setzung hierfur sind neben den oben bereits genannten Anforderungen bezuglichder modelltechnischen und der prozeßtechnischen Integration vereinheitlichte Zu-griffsmethoden auf die Programme und deren Modelle. Dazu gehoren die Lokali-sierung und der Start der Programme sowie die Mechanismen zur Ubergabe vonEingangsgroßen und Ruckgabewerten. Das Integrationssystem muß es außerdemermoglichen, die fur den aktuell durchgefuhrten Prozeßschritt erforderliche Sichtauf die Daten des anderen Modells darzustellen. Um dem Benutzer eine einfacheHandhabung des Systems zu ermoglichen, sollte die Benutzungsoberflache fur alleSystemkomponenten einheitlich sein.Allgemein werden an Methoden folgende Forderungen gestellt [FR99] [Abe97]:

• einfache Bedienung

• maximale Flexibiltat

76


• kurze Zugriffzeit

• hohe Verfugbarkeit

• hoher Integrationsgrad

Verschiedene Berechnungsverfahren sollten auch miteinander kombinierbar sein.Standardberechnungen sollten vom Konstrukteur an seinem Arbeitsplatz, in sei-ner gewohnten Arbeitsumgebung durchfuhrbar sein [KMM99]. Fur eine qualifi-zierte Methodenauswahl mussen daher Informationen uber den Anwendungsbe-reich, die Gultigkeit und die Aussagegute einer Methode bereitgestellt werden.In vielen Fallen muß aus einer Berechnung auch eine Dokumentation abgeleitetwerden, die gegenuber Kunden als Nachweis dienen kann [Kum99]. Eine auto-matische Archivierung durchgefuhrter Berechnungen wird von Abeln in [Abe97]gefordert.

Sicherheit

Bei einem Datenaustausch uber ein Netzwerk ergeben sich besondere Anforde-rungen bezuglich der Sicherheit der Datenubertragung. Hier sind verschiedeneEbenen zu unterscheiden:

Sicherheit gegen unautorisierten Zugriff: Sobald urheberrechtlich geschutzte Mo-delle oder Methoden uber das Internet zuganglich gemacht werden, mussendiese durch geeignete Schutzmechanismen vor unberechtigtem Zugriff ge-schutzt werden.

Sicherheit der Datenubertragung: Die bei einem berechtigten Zugriff ubertra-genen Modelle und Daten durfen nicht durch dritte verandert werden odereinsehbar sein.

Zugriffskontrolle bei autorisiertem Zugriff: Selbst bei einem berechtigten Zu-griff mussen die Zugriffsoperationen durch ein Kontrollsystem uberwachtwerden. Dabei mussen Zugriffsparameter wie Schreib- und Leseberechtigun-gen und ubertragene Informationstiefe, sowie gleichzeitige Zugriffe mehrererBenutzer uberwacht werden.

Besonderer Bedeutung kommt der Verwendung von urheberrechtlich geschutz-ten Dokumenten dritter zu, beispielsweise den fur eine Berechnung verwendetenNormdaten. Diese konnen zwar in der Berechnung verwendet werden, durfenaber nicht als Dokument uber das Internet zuganglich gemacht werden.

77


Anforderungen an das IntegrationssystemF/W Anforderungen

ModelleF Kopplung eines parametrischen Geometriemodellierers mit einem

parameterorientierten Berechnungsprogramm.

F Im CAD–System sind geometrische Eigenschaften und Topologie-merkmale abrufbar.

F Im CAD–System konnen Norm– und Standardteile durch Namenidentifiziert werden.

F Das Berechnungsmodell wird durch benannte Parameter beschrie-ben.

F Die Auswahl von Norm– und Standardteilen im Berechnungssystemerfolgt uber Parameter.

F Vom Berechnungssystem sind verschiedene Modellkonfigurationenberechenbar. Die Auswahl von Konfigurationen erfolgt uber Steu-erparameter.

F Das Geometriemodell ist das Arbeitsmodell des Anwenders. DieBerechnung dient dazu, ein Geometriemodell zu erzeugen oder zuverandern.

ProgrammeF Fur eine synchrone Anwendung der Systeme soll eine direkte Kopp-

lung der Programme realisiert werden.

F Die Kopplung soll unter Nutzung der vorhandenen Programmier-schnittstellen erfolgen.

F Das Integrationssystem muß auf dem Betriebssystem AIX (UNIX)lauffahig sein.

W Mit dem Integrationssystem sollen weitere verbreitete Betriebsyste-me (andere UNIX–Versionen, Windows) angebunden werden kon-nen.

F Die Schnittstelle des CAD–Systems ist in C implementiert.

F Die Schnittstelle des Berechnungssystems ist in FORTRAN imple-mentiert.

W Die Integration von in anderen Sprachen implementierten Systemensoll moglich sein.

Tabelle 4.1: Anforderungsliste fur das Integrationssystem

78


Anforderungen an das IntegrationssystemF/W Anforderungen

ProzeßF Berechnungsmethoden sollen als Werkzeuge beim Gestalten einsetz-

bar sein.

F Die Berechnung erfolgt synchron zur Gestaltung. Die Methodenhaben eine kurze Laufzeit.

F Der Geometriemodelierer ist am Arbeitsplatz verfugbar. Das Be-rechnungsprogramm kann auf einem anderern Rechner im Intranetimplementiert sein.

W Das Berechnungsprogramm kann auf einem Rechner im Internetimplementiert sein.

F Als Werkzeug mussen bei einer Berechnung Geometrieanalysen,Geometrievariation und die Erzeugung von Geometrie moglich sein.

F Die Arbeitsmodelle mussen in den Originalsystemen sichtbar ge-macht werden konnen.

F Verknupfungen zwischen den Modellen mussen visualisiert werdenkonnen.

W Sicherheit gegen unberechtigen Zugriff.

W Sicherheit der Datenubertragung.

W Zugriffskontrolle bei berechtigetem Zugriff.

F Benutzung durch einen Anwender.

W Erweiterbar auf mehrere Anwender.

F Die Benutzung darf kein zusatzliches Wissen im Bereich Informati-onstechnik beim Anwender erfordern.

F Mit dem System sollen Auslegungsrechnungen, Nachweisrechnun-gen und Optimierungen moglich sein.

Tabelle 4.2: Anforderungsliste fur das Integrationssystem (Fortsetzung)

79


4.2 Anforderungsliste

Die Anforderungen sind in einer Anforderungsliste (in Anlehnung an [PB97]) aufden Seiten 78– 79 dargestellt. In der Liste werden Forderungen (F) und Wunsche(W) unterschieden.

4.3 Zusammenfassung

Der Integrationsansatz muß eine Integration in drei Hauptbereichen ermoglichen(vergleiche Bild 4.1):

Modell: Die in den Programmen existierenden Datenmodelle mussen in einemintegrierten Modell zusammengefuhrt werden. Da die Modelle eine un-terschiedliche Semantik aufweisen, mussen uber zusatzliche InformationenVerknupfungen zwischen den Modellen hergestellt werden.

System: Da die bestehenden Programme auf verschiedenen Rechnerplattformenund Betriebssystemen existieren konnen, muß der Integrationsansatz platt-formubergreifend und netzwerkfahig sein. Um die durchgefuhrten Berech-nungen reproduzierbar zu machen, mussen die Modelle beider Systeme unddie Verknupfungen zwischen den Modellen speicherbar sein.

Prozeß: Um eine Methode als Werkzeug in einem Gestaltungssystem nutzen zukonnen, muß sich die Anwendung einer Berechnungsmethode in die be-stehenden Anwenderprozeduren des Gestaltungssystems einfugen lassen.Da die Applikationen uber unterschiedliche Anwenderprozeduren verfugen,mussen die Ablaufe der beiden Systeme durch zusatzliche Softwarekompo-nenten aufeinander abgestimmt werden.

Die Hauptmerkmale der zu verbindenden Systeme sind in Bild 4.1 dargestellt.

SpeicherungPlattform

MethodenObjekte

CAD CAE

Modell

System

Prozeß

ObjekteMethoden

Plattform

Netzadresse

Modellsicht Modellsicht

SpeicherungNetzadresse

Aktivitäten

EingangsgrößenErgebnisse

EingangsgrößenErgebnisseAktivitäten

Bild 4.1: Merkmale der zu integrierenden Systeme

80

5 Integrationskonzept furCAx–Anwendungen auf der Basisvon CORBA

In diesem Kapitel werden mogliche Bestandteile und Strukturen eines CORBA–basierten Netzwerkes fur CAx–Anwendungen vorgestellt. In der Einfuhrung wer-den die Merkmale einer CORBA–Umgebung zusammengefaßt und die Situationbeschrieben, die sich bei der Anwendung von CORBA fur die Integration von Ge-staltung und Berechnung ergibt. In einem Uberblick werden die Aktivitaten derOMG auf diesem Gebiet dargestellt. Anschließend werden mogliche Strukturenfur die modelltechnische und die systemtechnische Kopplung bestehender CAx–Systeme vorgestellt. Abschließend werden zwei Integrationansatze prasentiert.

5.1 Ausgangssituation

Mit der durch die OMG definierten Architektur (vgl. Bild 3.4 auf Seite 52) istdie Grundstruktur einer CORBA–basierten Arbeitsumgebung bereits vorgegeben:verschiedene Applikationen sind uber einen gemeinsamen Kommunikationskanalmiteinander verbunden und haben dabei Zugriff auf eine Reihe allgemeiner undanwendungsgebietspezifischer Dienste. CORBA ermoglicht die netzwerktrans-parente und plattformubergreifende Verwendung von Objekten, die uber eineneutrale Schnittstellenbeschreibung bekannt gegeben werden und durch die Ap-plikationen zur Verfugung gestellt werden mussen.

Die Integrationsaufgabe besteht darin, bestehende Softwaresysteme zu einem Ge-samtsystem zu kombinieren. Sind die Applikationen durch Spezifikation undImplementierung einer Schnittstelle in ein CORBA–System integriert, wird dieInteroperabilitat auf Systemebene durch CORBA sichergestellt. Die Interopera-bilitat auf einer semantischen Ebene ist aber durch CORBA nicht vorgegeben.Dafur mussen die betrachteten Applikationen, ihr Verhaltnis zueinander, die vonihnen bereitgestellten Objekte und die durchfuhrbaren Operationen definiert undimplementiert werden.

81

5 Integrationskonzept fur CAx–Anwendungen auf der Basis von CORBA

5.2 Stand der Standardisierung

Zusammen mit der Object Management Architecture werden von der OMG furverschiedene Anwendungsgebiete Frameworks, also vordefinierte Systemumge-bungen, zusammengestellt und standardisiert. Der Stand der Entwicklungen istfur die einzelnen Anwendungsgebiete sehr unterschiedlich. Wahrend fur das An-wendungsgebiet Textverarbeitung die Entwicklung sehr weit fortgeschritten istund mit OpenDoc [OHE96] bereits eine Implementiertung vorliegt, sind die Stan-dards fur weitere Anwendungsgebiete noch in Bearbeitung. Eine Beschreibungder zu einem Anwendungsgebiet gehorenden Common Facilities, also der fur die-ses Gebiet typischen Objekte und Methoden, wird von der OMG im DokumentCommon Facilities Architecture [OMG95] veroffentlicht.

Der Bereich Konstruktion und Fertigung (engl. Titel: Manufacturing Facili-ty) beschreibt die rechnergestutzte Integration von Fertigungsaufgaben und Ein-richtungen und deren Zusammenwirken mit weiteren Unternehmensbereichen.Als Teilbereiche werden Produktentwicklung, Prozeßsteuerung, Qualitatsmana-gement, CAD, Vertrieb, Sicherheit und Versuchsfeld genannt. Das Ziel der In-tegration ist es, die bisherigen starren, monolithischen Systeme durch modulare,flexibel an Prozeßanderungen anpaßbare Komponenten zu ersetzen. Von beson-derer Bedeutung sind dabei die in der Praxis vorliegende geographische Verteilungder Systemkomponenten und das weite Feld der am Entwicklungsprozeß betei-ligten Applikationen. Daraus resultieren weitere Anforderungen an die applika-tionsubergreifenden Dienste, die insbesondere die dynamische Konfigurierbarkeitvon Komponenten, ein Dokumentationssystem zur nachvollziehbaren Protokollie-rung samtlicher Aktivitaten im Zusammenhang mit den Produktdaten und denZugriff auf die Produktdaten betreffen [OMG95]. Der Ansatz ist damit weit um-fassender, als es fur die Integration von Gestaltung und Berechnung erforderlichware.

Die Arbeitsgruppe hat ihre Tatigkeit erst vor kurzem aufgenommen, sodaß nochkeine Ergebnisse vorliegen. Lediglich im Bereich PDM-Integration liegen schonErgebnisse vor. Mit dem Dokument PDM Enablers [OMG98] liegt bereits dieuberarbeitete Fassung eines Vorschlags fur eine Spezifikation der Funktionalitateines CORBA basierten PDM-Systems vor. Die Spezifikation sieht eine entwick-lungsprozeßbezogene Verwaltung von in Baustrukturen geordneten Bauteilen undBaugruppen vor. Die Funktionalitat umfaßt die fur PDM-Systeme ublichen Ope-rationen, wie Komponenten erzeugen und finden, Versionsionierung, Anderungs-management und Konfigurationsmanagement. Das System arbeitet mit in Doku-menten gespeicherten Modellen, denen uber Attribute zusatzliche Eigenschaftenzugeordnet werden konnen. Die inhaltliche Beschreibung der Objekte soll mitdem durch STEP [ISO94] definierten Format erfolgen.

82

5.3 Client–Server–Strukturen


Das Zusammenwirken verschiedener Applikationen in einer verteilten Umgebungmuß durch klare Zustandigkeiten und Abhangigkeiten organisiert werden. Ublichsind hier Client–Server– Strukturen, in denen eine Applikation Daten und Me-thoden als Server zur Verfugung stellt und die andere als Client mit diesen Datenarbeitet oder die Methoden in Anspruch nimmt. Im nachfolgenden Text werdenmogliche Anordnungen von Client- und Serverapplikationen fur einen integriertenEntwicklungsarbeitsplatz vorgestellt.

� � �

��

��

�� !"#

� � �

��

��

��

� � �

��

��

� ��

Zentraler Applikationen als Externer ClientDatenserver Client und Server

Bild 5.1: Client–Server–Strukturen fur die Integration von Gestaltung und Be-rechnung

5.3.1 Zentraler Datenserver

Samtliche Produktdaten werden in einer zentralen Datenbank verwaltet (verglei-che Bild 5.1 links). Ein Datenbankserver stellt den als Client arbeitenden Ap-plikationen das gesamte Datenmodell oder Auszuge des Modells zur Verfugung.Die Applikationen arbeiten mit den bereitgestellten Daten und ubertragen diegeanderten Modelle zuruck auf den Server. Diese Struktur bietet zwei wichtigeVorteile: Die strukturierte Speicherung und Bereitstellung von Produktinforma-tionen und die Verfugbarkeit von Verfahren zur Steuerung des Zugriffs auf Pro-duktinformationen [GAP93]. Damit konnen Inkonsistenzen leichter uberwachtwerden und parallele Zugriffe, wie sie beim Simultaneous Engineering erfolgen,gesteuert werden. Die Daten des zentralen Servers mussen von den Applika-tionen in die internen Darstellungen umgewandelt werden. Das Produktmodelldes Datenbankservers muß in der Lage sein, samtliche produktbezogenen Datenabzubilden.

Eine mogliche Implementierung dieser Struktur wird in [AK98] beschrieben (ver-gleiche Abschnitt 3.3.4).

83


5.3.2 Applikationen als Server

Eine andere Struktur ergibt sich, wenn die beteiligten Applikationen als Serverfur die in ihnen bearbeiteten Modelle betrachtet werden. Danach wurden alleGeometriedaten in einem “Geometrieserver” gehalten und entsprechend Anfor-derungen in einem “Anforderungsserver” usw. Ein Geometrieserver stellt allegeometrischen Daten zur Verfugung und bietet Methoden zum Analysieren undVariieren der Geometrie an. Bei dieser Struktur entsteht ein verteiltes Datenmo-dell mit den entsprechenden Konsequenzen fur die Konsistenzuberwachung undDatenhaltung.Die Verknupfung der Modelle ist auf zwei Weisen moglich:

Applikationen sind gleichzeitig Client. Ein Server kann gleichzeitig Client einesanderen Server sein. Beispielsweise kann ein Geometrieserver Daten ausder Anforderungsliste beziehen. Bei mehreren Servern entstehen schnellkomplexe Abhangigkeiten zwischen den verschiedenen Partialmodellen mithohen Anforderungen bezuglich der Interoperabilitat der Objekte und derKonsistenzuberwachung.

Externe Clients. Eine klare Trennung der Partialmodelle bleibt erhalten, wenndie Applikationen nur als Server fur externe Clientprogramme arbeiten. Einexternes Clientprogramm bezieht Daten aus verschiedenen Partialmodellenund fugt diese zu einem integrierten Modell zusammen. Anderungen in ei-nem der Partialmodelle werden auf Anforderung des Clients vorgenommenund im Datenmodell der zugehorigen Applikation gespeichert. Die Anfor-derungen an die Interoperabilitat der Objekte sind bei dieser Konfigurationgeringer, da die Verknupfung uber den Client erfolgt. Demzufolge ist derAufwand fur die Implementierung des Client wesentlich hoher, da durchden Client zusatzlich die Konsistenz der Modelle uberwacht werden muß.

5.3.3 Client–Server–Strukturen mit CORBA

Aus den herkommlichen 2-Ebenen Client-Server Strukturen, bei denen ein Clientdirekt mit dem zugehorigen Server in Verbindung steht, wird bei der Verwen-dung von CORBA eine drei-Ebenen Client-Server Struktur (vgl. Bild 5.2). DieClient-Anwendung, in der die Objekte verwendet und zusammengefugt werden,bildet die erste Ebene. Ublicherweise werden in dieser Ebene auch die sichtbarenBestandteile der Objekte prasentiert. In der zweiten Ebene liegen die Imple-mentierungen der Objekte, eingebettet in eine CORBA-Laufzeitumgebung. Indieser Ebene werden die vom Client kommenden Aufrufe an die entsprechendenServer weitergeleitet und dort ausgefuhrt. Die CORBA-Laufzeitumgebung stelltdie Kommunikationsinfrastruktur zur Verfugung und verdeckt die internen Da-tenstrukturen der Datenserver, indem sie nur die in der Schnittstellendefinitionfestgelegten Objekte und Methoden bekannt gibt. Die dritte Ebene bilden die

84


Datenbasen fur die Objekte der zweiten Ebene. Dabei konnen eigens dafur einge-richtete Datenbanken genauso zum Einsatz kommen, wie existierende Programme(engl.: legacy code), die uber IDL gekapselt wurden, oder CORBA-konforme Ser-veranwendungen [OH97].

O

R

B

O R B

O R B

O R BO R B

GekapselteApplikation

CORBAIIOP

��

��

��

��

� � � � ��

��

��

��

��

Pro/E

1. EbeneVerwendung der Objekte

2. EbeneServer Objeke

3. EbeneBestehende Datenbasen

Datenbank

Lotus Notes

��

��

��

��

Bild 5.2: 3-Ebenen Client-Server Struktur mit CORBA (in Anlehnung an [OH97])

Mit CORBA ist es moglich, die drei Bereiche Prasentationslogik, Anwendungslo-gik und Datenhaltung auf verschiedene Rechner, plattformubergreifend, zu ver-teilen [Tur99]. Da CORBA in der Mitte zwischen den Datenbasen und den Client-Anwendungen steht, spricht man auch von Middleware.

Die Integration von bestehenden CAD–Systemen in eine Client-Server Strukturbringt einige Probleme mit sich, da die existierenden Systeme weder als Client-noch als Server ausgelegt sind (vgl. Abschnitt 2.5). Die Systeme vereinen alledrei Ebenen in einer einzigen Anwendung.

5.3.4 Bewertung der Strukturen

Fur eine Integration von Gestaltungs- und Berechnungssoftware kommen grund-satzlich alle vorgestellten Strukturen in Frage. Die Ansatze erfordern aber unter-schiedlich viel Aufwand bei der Implementierung der Clientanwendungen und derServerkomponenten. Sie unterscheiden sich ebenfalls darin, wie sich die Daten-modelle bestehender Softwaresysteme integrieren lassen und wie die Konsistenzzwischen den verschiedenen Datenbestanden uberwacht werden kann. Tabelle 5.1zeigt einen Uberblick uber die Merkmale der vorgestellten Strukturen.

85


Merkmal Zentraler Datenserver Applikationen. als externer ClientClient + Server

Aufwand hoch hoch niedrigserverseitigAufwand mittel hoch hochclientseitigKonsistenz- einfach aufwendig mitteluberwachungIntegrationbestehender schwierig schwierig einfachDatenstrukt.Erweiterbarkeit einfach einfach schwierig

Tabelle 5.1: Vergleich der verschiedenen Client-Server Strukturen

Die Verwendung eines zentralen Datenservers ermoglicht eine einfache Uberwa-chung der Konsistenz und ist leicht erweiterbar. Allerdings muß fur die zentraleSpeicherung ein Datenmodell bestehen, das in der Lage ist alle entstehenden In-formationen abzubilden und das in die Datenformate in den Applikationen um-gewandelt werden kann. Dies ist insbesondere fur die Integration bestehenderSoftwaresysteme eine kaum losbare Aufgabe. Eine sinnvolle Variante, bei der dieModelle der bestehenden Applikationen als Basis genommen werden, ist daher dieZusammenfuhrung der Modelle in einem externen Client. Entsprechend ist Im-plementierung des Clients wesentlich aufwendiger und, da in der Anwendung zweispezielle Server zusammengefuhrt werden, schwieriger erweiterbar. Die Struktur,in der die Applikationen gleichzeitig als Client und Server arbeiten, erfordert,daß, wie beim zentralen Datenserver, allen Anwendungen ein einheitliches Da-tenmodell zugrunde liegt. Daruberhinaus erfordert sie erheblichen Aufwand inder Konsistenzuberwachung.

5.4 Produktmodellstrukturen

Fur eine durchgangige Rechnerunterstutzung des Entwicklungsprozesses muß einSystem geschaffen werden, das in der Lage ist samtliche anfallenden Daten zuspeichern und den nachfolgenden Prozeßschritten zuganglich zu machen. Im Sin-ne der objektorientierten Programmierung muß ein konzeptionelles Modell fur dieAbbildung der in den verschiedenen Phasen benotigten Daten geschaffen werden[Boo94]. Die konzeptionellen Modelle werden in diesem Kontext als Produktin-formationsmodelle bezeichnet.

86


5.4.1 Partialmodelle in den Applikationen

In den zu koppelnden Applikationen existieren bereits Modelle fur die rechnerin-terne Abbildung der Objekte. Dies sind seitens der CAD–Systeme geometrieori-entierte Modelle und seitens Berechnungssysteme parameterorientierte Modelle,in denen geometrische und nichtgeometrische Informationen enthalten sind (vgl.Kapitel 2). Bei der Integration mussen die Objekte aus den verschiedenen Ap-plikationen zusammengefuhrt und miteinander verknupft werden. Grundsatzlichsind folgende Kombinationen von Objekten denkbar:

Gleiche Objekte in allen Applikationen. Die einfachste Form der Kopplung er-gibt sich, wenn in beiden Applikationen die gleichen Objekte mit den selbenMethoden implementiert sind. In einer solchen Umgebung konnen die Ob-jekte der einen Applikation direkt in der anderen verwendet werden, ohnedaß die Objekte uber Abbildungsvorschriften miteinander verknupft werdenmussen. Ein Beispiel hierfur ist die in [AJSK98] beschriebene Kopplung derCAD–Systeme Pro/ENGINEER und CATIA.

Verschiedene Objekte. Der typische Fall bei der Integration bestehender Syste-me ist der, daß von den Applikationen unterschiedliche Objekte zur Verfu-gung gestellt werden. Die verschiedenen Modelle ergeben von sich aus nochkein zusammenhangendes Produktmodell. Vielmehr mussen die Objekteaus den verschiedenen Modellen mit Hilfe von zusatzlichen Informationenzu einem Produktmodell zusammengefugt werden.

Interoperiernde Objekte. Anzustreben ist eine Systemumgebung, in der Objek-te einer Applikation in einer anderen verwendet werden konnen. Dieser An-satz spiegelt das naturliche Vorgehen bei der Entwicklung wieder, wonachfur die Bearbeitung einer Aufgabe Informationen verschiedener Teilberei-che zusammengefuhrt werden. Als Beispiel sei die in Kapitel 2 beschriebeneBeziehung zwischen Ersatzmodellen fur die Berechnung und Geometriemo-dellen genannt, wonach die Geometrie Bestandteil des Ersatzmodells ist. Indiesem Fall mussen die Objekte so definiert werden, daß sie untereinanderDaten austauschen konnen und sich zu einem Gesamtmodell erganzen.

Zentrales Modell und Methodenserver. Denkbar ist auch die Verwendung ei-nes zentralen Modells, aus dem spezielle Sichten fur die Weiterverarbeitungin den Applikationen abgeleitet werden. In den Applikationen werden dieModelle analysiert oder verandert und anschließend in das zentrale Modellzuruckgeschrieben. In einer solchen Umgebung konnten unabhangige Soft-wareanbieter (engl.: Independent Software Vendors ISV ) universell einsetz-bare Methoden entwickeln und auf Methodenservern zur Verfugung stellen.Die Abbildung von Daten eines zentralen Modells auf die rechnerinternenModelle der Applikationen bereitet dabei noch erhebliche Schwierigkeiten,

87


da dieser Schritt mit den zur Zeit existierenden neutralen Modellen nochmit einer verlustbehafteten und damit nicht umkehrbaren Modelltransfor-mation verbunden ist [Har97].

Fur die bestehende Integrationsaufgabe mussen in jedem Fall verschiedene Ob-jekte zusammengefuhrt werden. Die Art und Weise, wie die internen Modelle derApplikationen uber die Schnittstellen zuganglich gemacht werden, bestimmt dieStruktur des Gesamtmodells und die Art der Speicherung.

5.4.2 Semantische Verknupfung von Objekten

Die Semantik von Softwareobjekten wird durch ihre Attribute und die von von ih-nen bereitgestellten Methoden erzeugt [OHE96]. Da die Attribute und Methodenvon CORBA–Objekten uber die Schnittstellenbeschreibungen festgelegt werden,kann durch eine entsprechende Formulierung der Schnittstellenbeschreibung dieSemantik einer Applikation verandert werden.Damit sich Objekte verknupfen lassen, mussen sie einer gewissen gemeinsamenSemantik unterliegen. Die minimale gemeinsame Semantik von Objekten inCORBA–Umgebung ist dadurch gegeben, daß alle Objekte Eigenschaften voneinem allgemeinen CORBA-Objekt erben, und damit innerhalb der Umgebungansprechbar und identifizierbar sind. Zusatzliche Semantik kann den Objektendurch die Attribute und Methoden gegeben werden, die in der Schnittstellenbe-schreibung definiert und im zugehorigen Server implementiert sind. Die Semantikder Objekte ist fur die modelltechnische und die prozeßtechnische Kopplung vongroßer Bedeutung, da uber sie das Verhalten der Objekte und die Zugriffsmog-lichkeiten definiert werden.Das Problem bei der Kopplung bestehender Applikationen ist, daß jedes Systemseine eigene Semantik fur die Darstellung der internen Modelle verwendet. Imeinfachsten Fall kann ein bestehendes System direkt an eine vorgegebene Se-mantik angepaßt werden, wenn die Objekte und Methoden der Schnittstellenbe-schreibung sinngemaß mit denen des Systems ubereinstimmen. In diesem Fallkonnen die Objekte und Methoden direkt aufeinander abgebildet werden. Furdie Implementierung einer gewunschten Semantik mussen dann gegebenenfallsDatenstrukturen oder Funktionsaufrufe neu zusammengestellt werden. Einen er-heblichen Aufwand bedeutet die Schaffung einer Semantik in Systemen, die keineoder nur eine einfache Semantik beherrschen. In diesem Fall muß die Seman-tik durch zusatzliche Informationen in der Schnittstellenimplementierung erzeugtwerden.

5.4.3 Definition eines Strukturmodells

Aus den in Kapitel 2 beschriebenen Merkmalen von Geometriemodellen und Re-chenmodellen wird ein Strukturmodell fur integrierte Berechnungen definiert. Das

88


Modell ist als Referenzmodell zu verstehen, das neben den Informationen ausden beiden Teilmodellen die notigen Verknupfungsinformationen enthalt. Im fol-genden Text werden die Bestandteile eines Strukturmodells und die moglichenRelationen zwischen den Bestandteilen definiert. Die Gliederung des Modells ori-entiert sich an der Baustruktur. Eigenschaften von Baustrukturelementen werdenmit Hilfe von benannten Parametern definiert. Uber Bedingungen und Relatio-nen werden die Beziehungen der Elemente untereinander formuliert. Uber dieBedingungen konnen die Objekte in den Applikationen identifiziert werden.Je nachdem, wie die Applikationen gekapselt werden, muß das Strukturmodellin einem verbindenden Client oder in allen Applikationen implementiert werden.Im folgenden Text werden die Bestandteile eines Strukturmodells erlautert, wiees fur die Berechnung von Schraubenverbindungen erforderlich ist.

Baustruktur

Das Strukturmodell orientiert sich an der Baustruktur der zu berechnenden Ver-bindung. Eine Baustruktur wird hier definiert als eine Reihe von Bauteilen undBaugruppen, die uber geometrische Relationen miteinander verknupft sind undan geometrischen Orten, den Bezugselementen, ausgerichtet werden. Zu einemBaustrukturelement konnen verschiedene Reprasentationen existieren. MoglicheKombinationen von Baustrukturelementen werden durch erforderliche, alternati-ve oder optionale Elemente gebildet. Die einzelnen Elemente haben Merkmale,die uber benannte Parameter beschrieben werden. Die Zuordnung von Para-metern zu Elementen fur verschiedene Formen von Berechnungen werden uberBedingungen und Relationen formuliert. Eine symbolische Darstellung des Struk-turmodells enthalt Bild 5.3. Die Beziehungen zwischen den Elementen des Struk-turmodells sind in Bild 5.4 dargestellt.

Bezugselemente

Fur die Identifizierung bestimmter Wirkorte werden im Modell geometrische Be-zugselemente, wie Achsen, Ebenen oder Punkte definiert. An einem Grundge-rust, bestehend aus in allen Verbindungstypen vorkommenden BezugselementenSchraubenachse und Trennfugenflache, werden die moglichen Baustrukturelemen-te (Komponenten) und weitere Bezugselemente mit alternativen und optionalenElementen ausgerichtet. Merkmale von Komponenten werden durch benannteParameter definiert. Zu jeder Komponente werden Listen der von ihr definiertenParameter und zusatzlichen Bezugselemente gehalten.

Parameter

Die produktbeschreibenden Merkmale werden durch benannte Parameter defi-niert. Die Parameter sind entweder Baustrukturelementen oder Bezugselemen-ten zugeordnet. Zur einfachen Lokalisierung sind die Parameter nochmals in die

89


Bild 5.3: Bestandteile des Strukturmodells fur integrierte Berechnungen

Merkmalsgruppen Geometrie, Montage, Werkstoff, Lasten und Sicherheit unter-teilt.

Bedingungen und Relationen

Mit Hilfe von Bedingungen und Relationen konnen Verknupfungen zwischen ver-schiedenen Bestandteilen des Modells hergestellt werden. Relationen bestehenzwischen zwei Elementen und konnen fur die Identifizierung von Objekten und dieAbbildung der Struktur verwendet werden. Uber Bedingungen konnen Einschran-kungen der Modellkonfiguration und Regeln fur die Konsistenzuberwachung for-muliert werden.

Prozeßinformationen

Parallel zu der Baustruktur und zu den Parametern werden im Modell Informa-tionen zur Einordnung des Modells in den Entwicklungsprozeß gespeichert. Ineiner Liste sind die moglichen Verwendungsarten einer Methode, wie Dimensio-nieren, Festigkeitsnachweis oder Optimierung angegeben. In einem Prozeßobjekt

90

5.5 Kapselung der Applikationen

nentenKompo-

Relationen

hatBA

lies: "A hat B"

Bezugs-elemente

Parameter Quelle Tabelle

GeometrieModell

geometr.Objekte

verk

nüpf

t

hat

hat hat hat

hat

hat

hat

hat

hat

hat

Formel

geometr.Funktion

Diagramm

Bearbeiter

sind

ver

knüp

ft m

it

refe

renz

iere

n

besteht

aus

hat

Struktur-modell information

Prozeß-

Bild 5.4: Entity-Relationship Darstellung des Strukturmodells

wird angegeben, bei welchem Prozeßschritt ein Parameter Eingangsgroße und beiwelchem er Ergebnis ist.

5.5 Kapselung der Applikationen

Mit der Formulierung einer neutralen Schnittstelle wird die interne Datenstruktureiner CORBA–Applikation durch eine objektorientierte Beschreibung der nachaußen sichtbaren Objekte und Methoden verdeckt oder gekapselt. Dadurch istes moglich, beinahe jeden beliebigen Programmcode uber einen standardisiertenZugriffsmechanismus anderen Systemen zuganglich zu machen.

Fur die Implementierung der Schnittstelle wird aus der Schnittstellenbeschrei-bung (der IDL-Datei) mit einem Precompiler Programmcode mit den Metho-denkopfen in der Programmiersprache der jeweiligen Applikation generiert. DieMethoden mussen dann in der Entwicklungsumgebung der Applikation imple-mentiert und ubersetzt werden. Die CORBA Laufzeitumgebung wandelt dievon einem externen Client kommenden Funktionsaufrufe in Methodenaufrufe derSchnittstelle um. Auf diese Weise konnen auch bereits ubersetzte Programm-bibliotheken in eine CORBA Umgebung eingebunden werden, wenn zu jedemAufruf eine entsprechende Definition in der Schnittstellenbeschreibung vorgese-hen ist. Man spricht dann von einer delegate-Technik, da die Aufrufe an die

91


bestehende Bibliothek delegiert werden [Red96].Je nachdem, wie weit die Objekte der Schnittstellenbeschreibung den Strukturendes internen Modells einer Applikation entsprechen, ist der Implementierungs-aufwand unterschiedlich groß. Eine durchgangige Schnittstellenstruktur in allenbeteiligten Applikationen vereinfacht das Zusammenfugen von Objekten zu einemintegrierten Modell.Im folgenden Text werden zwei Konzepte fur eine Integration bestehender Syste-me vorgestellt: eine einfache Kapselung, bei der die vorhandenen Schnittstellender Systeme durch eine Formulierung in IDL direkt uber CORBA ansprechbar ge-macht werden, und die Definition eines Frameworks, also einer Arbeitsumgebung,in der von den Applikationen semantisch gleichartige Strukturen zur Verfugunggestellt werden.

O R B

C A E

extern. Client

C A DC A D C A E

O R B

Datenbasis

Einfache Kapselung Implementierung des Strukturmodellsin allen Applikationen

Bild 5.5: Mogliche Anbindungen der Applikationen

Einfache Kapselung der Applikationen

Bei dieser Kopplung werden die Objekte, die in den Programmierschnittstellender Applikationen definiert sind, in einer IDL-Datei beschrieben und uber eineeinfache Implementierung gekapselt. Durch diese Kapselung kann auf die Appli-kationen netzwerktransparent und plattformunabhangig zugegriffen werden. Einesemantische Verknupfung auf Modellebene und die Abstimmung der Aktivitatenzur Schaffung eines durchgangigen Prozesses muß durch eine zusatzliche Softwareerfolgen (vgl. Bild 5.5 links). Die Merkmale eines solchen Systems werden in Ab-schnitt 5.6 beschrieben. In Kapitel 6 wird die Implementierung einer einfachenKopplung des CAD–Systems Pro/ENGINEER und des Schraubenberechnungs-programms BOLT vorgestellt.

CAx-Framework

Als Alternative zu der einfachen Kapselung wird in Abschnitt 5.7 ein Konzeptfur eine CAx-Umgebung vorgestellt. In dieser Umgebung wird fur alle Applika-

92

5.6 Systemkonzept fur einfach gekapselte Applikationen

tionen eine gemeinsame Schnittstelle der bereitgestellten Objekte definiert, die esermoglicht, mehrere Reprasentationen eines Objektes in den verschiedenen Ap-plikationen zu verwalten (vergleiche Bild 5.5 rechts). Die Schnittstellen sind sogestaltet, daß von allen Systemen Objekte mit gleichen Strukturen und Methodenfur die Analyse und die Variation angeboten werden. Auf diese Weise ergeben sichinteroperierende Objekte. Die Schaffung einer zusatzlichen Softwarekomponentefur die Verknupfung von Modellen und fur die Realisierung eines durchgangigenProzeßmodells entfallt. Die Applikationen sind eingebettet in eine Umgebungstandardisierter Dienste.

5.6 Systemkonzept fur einfach gekapselteApplikationen

5.6.1 Systemstruktur

In der Schnittstelle des Geometriemodellierers sind geometrische Objekte, sowieMethoden fur die Analyse und die Variation dieser Objekte definiert. Die Schnitt-stelle des Berechnungssystems enthalt benannte Parameter. Uber die Methodenkonnen Parameter gesetzt und abgefragt und eine Neuberechnung veranlaßt wer-den.Da bei dieser Kopplungsform die zu verknupfenden Objekte eine unterschiedlicheSemantik haben, muß die Verknupfung in einer zusatzlichen Softwarekomponen-te erfolgen. Dies kann durch einen separaten Client fur beide Systeme realisiertwerden. Die geometrischen Objekte des CAD–Systems und die Parameter desBerechnungssystems werden im Client zu einem Strukturmodell zusammenge-setzt. Das Strukturmodell ist das Arbeitsmodell des Bearbeiters und wird ausden Modellen der Applikationen abgeleitet. Durch gezielte Interaktionen desBearbeiters konnen Variationen am Strukturmodell vollzogen und in den Appli-kationen nachgefuhrt werden. Dabei sind fur alle moglichen Veranderungen amStrukturmodell Anweisungen und Bedingungen zu formulieren, wie die Variationin den Applikationen umgesetzt werden muß. Beispielsweise mussen bei Verande-rung des Schraubendurchmessers im Geometriemodell das Modell der Schraubeersetzt und im Rechenmodell der entsprechende Parameter variiert werden.

5.6.2 Anwendungsszenarien

Diese Kopplung laßt sich fur sehr viele bestehende Softwaresysteme realisieren,da sich fur die meisten Systeme eine Beschreibung der Schnittstelle in IDL for-mulieren laßt und sich viele Programmiersprachen direkt oder indirekt in eineCORBA Umgebung integrieren lassen. Die Formulierung in IDL ermoglicht da-bei eine gleichzeitige Verwendung von Objekten aus in unterschiedlichen Spra-chen implementierten Servern und von verschiedenen Orten eines Netzwerkes.

93


O R B

C A EC A D

Applet

ServerWeb

lokale Anwendungen externe Anwendungen

Save UpdNew ?Load

download

Bild 5.6: Integrationssystem mit einfach gekapselten Applikationen

Sie ist damit besonders geeignet, um Berechnungsprogramme die nur auf einerbestimmten Plattform existieren und nicht portiert werden konnen, in eine andereHardeware- oder Softwareumgebung zu integrieren, sofern fur beide Plattformeneine CORBA–Laufzeitumgebung existiert.Fur die Programmierung der zusatzlichen Informationen zur Verknupfung derModelle und Prozesse bietet sich die Programmiersprache JAVA an. Durch diePlattformunabhangigkeit von JAVA kann diese Softwarekomponente immernocheingesetzt werden, wenn sich die Plattform einer Applikation andert. JAVA–Programme haben vollen Zugriff auf die in einer CORBA–Umgebung definiertenStrukturen. Daruberhinaus laßt sich mit JAVA eine portable Benutzungsoberfla-che fur beide Systeme gestalten. Dies ist insbesondere fur die Bereitstellung vonMethoden im Internet interessant.Eine Implementierung dieses Ansatzes sowie Variationsmoglichkeiten zur Uber-tragung des Strukturmodells werden in Kapitel 6 vorgestellt.

5.7 Systemkonzept fur ein CAx-Framework

Mit der oben beschriebenen einfachen Kopplung konnen zwar die bestehendenProgramme in einem integrierten System zusammenarbeiten, die Verwendungvon Objekten aus den Programmen erfordert aber immer einen auf genau die-se Server abgestimmten Client. Der Grundgedanke der Komponententechnolo-gie, namlich portable, austauschbare Objekte zu schaffen, ist damit nicht erfullt.

94


Voraussetzung hierfur ware die Definition einer Arbeitsumgebung, in der Ob-jekte verschiedener Applikationen als, bis zu einem gewissen Maß, gleichwertigeObjekte verwendet werden konnen und die Objekte von sich aus untereinanderInformationen austauschen konnten. In einer solchen Arbeitsumgebung wurdendie allgemeinen Objekte als Metaklassen in der Arbeitsumgebung definiert und inden Applikationen als spezifische Klassen implementiert. Die Eigenschaften derObjekte waren uber standardisierte Zugriffsmethoden zuganglich. Ein durchgan-giges Modellschema sorgt fur eine eindeutige und konsistente Ablage von Infor-mationen. Das Zusammenwirken der Applikationen mußte durch eine Reihe vonallgemeinen und speziellen Diensten unterstutzt werden.In diesem Abschnitt wird ein Konzept fur ein CAx-Framework zur Integrationvon Gestaltung und Berechnung vorgestellt.

5.7.1 Produktmodell und Partialmodelle

In dem CAx-Framework werden die Partialmodelle in den Applikationen als spe-zifische Ausschnitte eines Gesamtproduktmodells gesehen. In einer neutralenDatenbasis wird in Form einer Referenzstruktur ein Verzeichnis der in einemProdukt vorkommenden Baustrukturelemente angelegt. Zu jedem Baustruktur-element der Referenzstruktur konnen in den Applikationen verschiedene Sichtenexistieren. Die Referenzstruktur bildet die zentrale Datenbasis, in der alle Ver-knupfungen zu den Modellen in verschiedenen Applikationen verwaltet werden.Die Applikationen bilden spezielle Informationen zu einem Ausschnitt oder zurgesamten Baustruktur ab. Beispielsweise bildet das CAD-System Geometriein-formationen ab und das Rechenmodell ein aus dem Geometriemodell abgeleitetesErsatzmodell mit Berechnungsverfahren-spezifischen Erweiterungen ab. Dabeisind in allen Partialmodellen einzelne Baustrukturkomponenten identifizierbar(vergleiche Bild 5.7). Die Eigenschaften der Modelle werden durch die im Ab-schnitt 5.4.3 definierten, benannten Parameter beschrieben. Die Parameter sindeinem Baustrukturelement zugeordnet und gehoren einer der Gruppen Geometrie,Werkstoff, Montage, Fertigung oder Lasten an.

Referenzstruktur

In einer Referenzstruktur werden alle in einem Produkt vorkommenden Baustruk-turelemente und deren Verknupfungen gespeichert. Fur die Abbildung der Ver-knupfungen werden auf den Komponenten Bezugsorte definiert, zu denen in denPartialmodellen unterschiedliche Reprasentationen existieren konnen. Die Refe-renzstruktur wird in einer von den Applikationen unabhangigen Datenbasis ge-speichert.Die Referenzstruktur ist vergleichbar mit dem in [GAP93] beschriebenen GeneralModel, das fur die Beschreibung von Teilebibliotheken entwickelt wurde. Zu ei-nem General Model konnen verschiedenen Reprasentationsformen, beispielsweise

95


�� !�"��#$#

%&��' �()�� !�"��#$#

* ��!�� (+�� !�"��#$#,.- -0/�1�24365 2 /87

9 9;:=<?>A@�B > :'C

DFE�E6GIHKJMLON$JAG.P

Bild 5.7: Produktmodell aus Referenzstruktur mit assoziierten Partialmodellen(in Anlehnung an [And96])

2D Darstellungen, 3D Darstellungen, FEM–Modelle oder Bauteilkennlinien exi-stieren.

Assoziationen

Zu den Baustrukturelementen der Referenzstruktur werden Informationen gespei-chert, in welchen Applikationen Reprasentationen eines Elements existieren undwelcher Art die Informationen sind. Dies wird insbesondere fur die Konsistenz-uberwachung benotigt, wenn bei Anderungen an einem Modell andere Modellenachgefuhrt werden mussen. Die Informationen werden auch benotigt, um beider Definition eines neuen Partialmodells herauszufinden, welche Partialmodelleund Modellinhalte bereits existieren.Fur die Abbildung der Abhangigkeiten zwischen den Partialmodellen kann derRelationship Service aus den Common Object Services der CORBA Umgebungverwendet werden. Dieser Dienst erlaubt es, Beziehungen zwischen zwei Objektenzu definieren, indem den Objekten die Rolle, die sie in dieser Beziehung darstel-len, zugeordnet wird. Typische Beziehungen sind Erzeuger und Verarbeiter vonInformation. Beispielsweise kann durch eine Berechnung eine Schraube dimen-sioniert werden. Das Rechenmodell ist damit Erzeuger der Modellinformationzum Baustrukturelement Schraube. Durch Analyse der Relationen kann zuruck-verfolgt werden, in welchem Partialmodell eine Baustrukturkomponente definiertwurde.

96


CAD–Komponenten

Die geometrische Reprasentation der Baustrukturelemente ist in den CAD–Kom-ponenten enthalten. Uber die Schnittstelle werden Methoden fur die Durchfuh-rung von geometrischen Analysen und fur die Modellierung definiert. Neben denReprasentationen der Baustrukturelemente sind in diesem Modell auch Reprasen-tationen der in der Referenzstruktur gehaltenen Bezugselemente enthalten. Aufdiese Weise konnen auch geometrische Eigenschaften und Relationen zwischenBezugselementen ermittelt werden.

Um den Anwendern Zugriff auf geometrische Eigenschaften der Modelle zu er-moglichen, muß die Schnittstelle eine sehr feingranulare Aufteilung der von ihrangebotenen Objekte aufweisen. Konkret mussen in einem Geometriemodell ein-zelne geometrische Objekte, wie Punkte, Korperkanten oder Flachen ansprechbarsein. Die Zugriffsmethoden werden sowohl als Funktionsaufrufe als auch in Formvon scriptgesteuerten Anfragen ausgefuhrt.

Da die existierenden CAD-Systeme uberwiegend baustrukturorientierte Model-le abbilden, ist die Implementierung dieser Schnittstelle vergleichsweise einfach.Die meisten der Objekte sind in einer ahnlichen Form bereits in der Program-mierschnittstelle der gangigen CAD-Systeme enthalten. Unbefriedigend ist diedoppelte Datenhaltung der Geometrieobjekte, die sich aus der Kapselung der exi-stierenden Schnittstelle ergibt. Ungelost ist zur Zeit noch die Ubertragung vonparametrischen Modellen zwischen verschiedenen CAD-Systemen, insbesondereweil die persistente Speicherung noch in einem systemspezifischen Dateiformaterfolgt. Eine Schnittstelle zu implementieren, mit der parametrische Geometrie-modelle fremder Systeme importiert werden konnen ist das bisher nicht erreichteZiel einer Integration.

Berechnungskomponenten

In den Berechnungskomponenten werden die Baustrukturelemente um die fur dieBerechnungsaufgabe benotigten Informationen erganzt. Dabei konnen die Pa-rameter des Rechenmodells aus anderen assoziierten Modellen ermittelt werden.Fur diesen Zweck werden zu jedem Parameter Bedingungen formuliert, anhandderer der Wert eines Parameters ermittelt werden kann. Beispielsweise kannein Parameter als Abstand zweier Bezugsflachen definiert sein, und, sofern einGeometriemodell verknupft ist, uber eine Analysefunktion direkt aus dem Geo-metriemodell ermittelt werden.

Da von einer Berechnungsmethode ublicherweise nur bestimmte Strukturen be-rechnet werden konnen, muß zu jeder Methode ein Modell der berechenbarenStrukturen verfugbar sein. Im Strukturmodell eines Berechnungssystems mussendaher die berechenbaren Verbindungen und die dafur erforderlichen Bedingun-gen enthalten sein. Daruber hinaus mussen Verknupfungsanweisungen enthaltensein, mit denen ein geometrisches Ersatzmodell aus einem gegebenen Geometrie-

97


modell abgeleitet werden kann. Fur die Ableitung des Ersatzmodells kann dieFunktionalitat eines CAD-Systems erforderlich sein.Je nach Aufgabenstellung kann das Ergebnis einer Berechnung unterschiedlichsein:

Modell. Im Falle einer Auslegungsrechnung wird durch eine Berechnung eineKombination von Baustrukturelementen und deren Merkmalsauspragungenfestgelegt. Ublicherweise werden zu diesen Elementen Modelle in den Norm-und Standardteilbibliotheken existieren.

Dokumente. Als Ergebnis einer Nachweisrechnung werden Dokumente erzeugt,die die Eingabewerte und die erzielten Ergebnisse enthalten. Die Dokumen-te konnen zusammen mit dem Geometriemodell archiviert werden.

Anderungsanforderungen. Optimierungsrechnungen konnen zu Anderungsan-forderungen an das Geometriemodell fuhren. Sofern ein Geometriemodellverknupft ist, konnen die Anderungen durch das System, oder falls das nichtmoglich ist, durch den Benutzer vollzogen werden.

Durchgangiges Prozeßmodell

Fur die Realisierung einer durchgangigen Rechnerunterstutzung mussen Aktivi-taten mit Eingangsgroßen und Ergebnissen definiert und in allen Applikationenimplementiert werden. Die Aktivitaten beschreiben das Zusammenwirken derverschiedenen Softwarekomponenten und sind damit wesentliche Voraussetzungfur eine Interoperabilitat der Objekte.

5.7.2 Allgemeine und spezielle Dienste

Zu einer Arbeitsumgebung gehoren neben den eigentlichen Applikationen Hilfs-programme und Dienste, die in CORBA unter dem Namen Common Facilitieszusammengefaßt werden. Wie im Abschnitt 3.2.2 beschrieben, werden die Dien-ste aufgeteilt in anwendungsgebiet-spezifische (vertical) und anwendungsgebiet-ubergreifende (horizontal) Dienste. Eine Auswahl der fur einen integrierten Ent-wicklungsarbeitsplatz sinnvollen Dienste wird in den folgenden Abschnitten vor-gestellt.

Bereitstellung von Normen

Ein großer Teil der beim Gestalten und beim Berechnen benotigten Daten kannaus Normen oder Bibliotheken bezogen werden. Die Art der benotigten Infor-mationen ist dabei fur die Applikationsarten unterschiedlich. Wahrend ein Be-rechnungsprogramm nur die Parameterwerte benotigt, werden von einem CAD-System auch die zugehorigen Geometriemodelle benotigt. Ein Dienst fur die Be-

98


reitstellung von Normen kann daher aufgeteilt werden, in einen allgemeinen, furalle Applikationen verfugbaren Dienst und einen applikationsspezifischen Dienst.

Applikationsubergreifender Normdienst. Die Liste der verfugbaren Normen undBibliotheken, sowie die in den Normen enthaltenen Tabellen konnen als all-gemeiner Dienst angeboten werden. Daruberhinaus konnen die in Normenenthaltenen erlauternden Texte und Bilder als Auswahlhilfe fur den Benut-zer bereitgestellt werden.

Applikationsspezifische Normdienste. Die von dem allgemeinen Normdienst be-reitgestellten Normen und deren Inhalte mussen von den Applikationen inapplikationsinterne Darstellungen umgewandelt werden. Bei CAD-Systemensind dies ublicherweise in Teilebibliotheken abgelegte Geometriemodelle.Zur Wahrung der Konsistenz sollten die Geometriemodelle als parametri-sierte Modelle abgelegt werden, deren Parameter durch die vom allgemeinenNormdienst bereitgestellten Werte gesetzt werden. Der applikationspezifi-sche Normdienst fur ein CAD-System muß fur die richtige Auswahl des zueiner Norm gehorenden Geometriemodells und fur Zuordnung der Parame-ter sorgen.

Fur ein Berechnungssystem mussen die vom allgemeinen Normdienst be-zogenen Parameter den programmspezifischen Parametern zugeordnet wer-den.

Fur beide Systeme gilt, daß manchmal fur die Ermittlung von Parameternweitere Normen herangzogen werden mussen. Beispielsweise mussen nachder Auswahl einer Schraube mit metrischem Gewinde die fur die Berech-nung benotigten Gewindeabmessungen und Toleranzen aus der Norm furmetrische Gewinde bezogen werden.

Hilfesystem

Die Bereitstellung von Hilfeinformationen kann ebenfalls in Form eines allge-meinen Dienstes erfolgen. Auch hier kann in allgemeine und systemspezifischeKomponenten unterteilt werden.

Allgemeines Hilfesystem. Diese applikationsubergreifende Komponente bietetInformationen uber die Arbeitsumgebung und Metadaten uber die bearbei-teten Modelle an. Fur die Arbeitsumgebung sind dies Informationen uberverfugbare Programme, Daten und Dienste. Zu den Metadaten der Model-le gehoren Verknupfungen mit anderen Partialmodellen, Anderungsdatum,Bearbeiter und ahnliches.

Denkbar ist auch, daß weitere Informationssysteme, zum Beispiel fur Ge-staltungsregeln, oder recyclinggerechte Produktentwicklung in das Systemeingebunden werden. Unter dem Oberbegriff Hilfesystem konnen so die

99


Informationssysteme und die Navigatoren fur die anderen Systemkompo-nenten Normdatenbank, Dokumentationssystem und PDM-System zusam-mengefaßt werden.

Applikationsspezifische Hilfesysteme. Dies sind die Onlinehilfesysteme der be-teiligten Applikationen.

Protokollierung und Dokumentation

Ein wichtiger Arbeitsschritt beim Arbeiten mit verteilten Modellen ist die nach-vollziehbare Protokollierung der durchgefuhrten Arbeitsschritte (vergleiche Kapi-tel 4). Der Event Service von CORBA bietet die Moglichkeit bestimmte Ereig-nisse zu definieren die allen oder bestimmten Applikationen mitgeteilt werden.Durch Definition charakteristischer Ereignisse fur die Erstellung oder Verande-rung von Modellen konnen die Aktivitaten uberwacht und protokolliert werden.

5.7.3 Speicherung der Modelle

Beim Arbeiten mit im Netzwerk verteilten Applikationen ist der Speicherung derModelle aufwendiger als bei rein lokalen Anwendungen. Aus Grunden der Daten-sicherung und der Uberwachung von Anderungen ist eine Speicherung in einemzentralen Speichermedium anzustreben [AK98]. Voraussetzung dafur ist, daß sichalle Modelle unabhangig von der zugehorigen Applikation in einem entsprechen-den Medium speichern lassen. Der CORBA Dienst Persistence definiert zwarstandardisierte Methoden zur Speicherung und Wiederherstellung von Objekten,die Implementierung dieses Dienstes liegt aber in der Hand des Programmierers,da fur die Speicherung ein Abbild der internen Datenstruktur der gekapseltenApplikation erstellt werden muß. Der Persistence Service verwendet fur die Spei-cherung die im Serialization Service definierten Methoden zur Abbildung von Ob-jekten in einen kontinuierlichen Speicherbereich. Bei der Implementierung konntedie entsprechende systemspezifische Datei als Datenstrom ubertragen und in einlokales Dateisystem abgelegt werden.Fur die Verwaltung der gespeicherten Daten bietet sich die Verwendung der in[OMG98] definierten Methoden eines Produktdatenmanagementsystems an.


In Bild 5.8 auf Seite 101 ist ein Uberblick uber die im Framework vorkommendenKomponenten dargestellt:Neben den Applikationen, die jeweils ein eigenes Strukturmodell halten, sind imSystem die allgemeinen und die speziellen Dienste vorhanden. Die speziellenDienste, Normen, PDM-System und Hilfesystem stellen die wesentlichen Metho-den fur die Arbeit mit CAx-Komponenten zur Verfugung. Sie verwenden dafur

100


Normen

Persistence

Naming

Relationship

C A D C A E

PDM System

Hilfesystem TransactionLife Cycle

O R B

Spezielle Dienste Allgemeine Dienste

Datenbasis

Bild 5.8: Systemstruktur des CAx-Frameworks

die Methoden der allgemeinen Dienste Naming, Life Cycle, Transaction, Persi-stence und Relationship.

5.7.5 Anwendung

In einem Beispiel soll ein moglicher Ablauf einer integrierten Berechnung beschrie-ben werden. Die Aufgabenstellung lautet: in einer lokalen CAD-Sitzung soll fureine vorhandene Verbindungsumgebung eine Schraube ausgewahlt werden. DieBetriebskrafte und weiteren Randbedingungen bezuglich Fertigung und Montageseien bekannt und konnen vom Benutzer eingegeben werden. Der Ablauf siehtdann wie folgt aus:

1. Uber das Informationssystem erhalt der Benutzer eine Liste der ver-fugbaren Berechnungssoftware und der damit durchfuhrbaren Berechnun-gen. Der Benutzer wahlt eine Methode aus und sendet eine Anfrage an dieCORBA-Umgebung, daß eine Berechnung mit dem aktuellen Geometrie-modell durchgefuhrt werden soll.

2. Mit Hilfe des Implementation Repository der CORBA-Umgebung wirdder zur gewahlten Methode gehorende Server lokalisiert und gegebenenfallsautomatisch gestartet. Dem Berechnungsserver wird das Geometriemodellals Arbeitsmodell ubergeben.

101


3. Anhand der Bedingungen und Relationen im Rechenmodell wird das Geo-metriemodell analysiert. Dabei werden die Analysefunktionen durch dasCAD-System ausgefuhrt. Anschließend wird durch das Berechnungssystemeine Schraube ausgewahlt. Im Rechenmodell ist diese Schraube durch ihreNormbezeichnung spezifiziert.

4. Aus dem Normdienst des CAD-Systems wird auf Anforderung des Benut-zers mit den Daten des allgemeinen Normdienstes und der vom Berech-nungssystem erstellten Normbezeichnung ein Geometriemodell der gewahl-ten Schraube erzeugt. Das Rechenmodell stellt die fur den Einbau benotig-ten Bedingungen zur Verfugung.

5. Bei Abschluß der Sitzung werden alle betroffenen Datenbasen aktualisiert.Dem Geometriemodell und der Referenzstruktur wurden jeweils eine Kom-ponente hinzugefugt. In der Datenbasis existieren jetzt zwei Verknupfungenzum Produkt: eine zum Geometriemodell und eine zum Rechenmodell.

Aus der Systemstruktur ergeben sich daruber hinaus noch weitere Nutzungsmog-lichkeiten des Systems:

Nutzung der Geometriekomponenten: Die vom CAD–System bereitgestelltenKomponenten konnen von allen geometrieverabeitenden Systemen genutztwerden. Beispiele hierfur sind FEM–Systeme oder Simulationssoftware.

Nutzung der Berechnungskomponenten: Die bei der Berechnung festgelegtenGroßen haben Einfluß auf viele weitere Teilbereiche der Produktentwick-lung. Beispielsweise werden Oberflachenbeschaffenheiten auch bei Festle-gung des Fertigungsablaufs benotigt. Die fur alle Bereiche gleiche Strukturder Modelle ermoglicht es dem Anwender, die gesuchte Information schnellaufzufinden. Die standardisierten Zugriffsmethoden erlauben es, auch di-rekte Verknupfungen zwischen den Daten verschiedener Modelle herzustel-len.

Methodensuche: Die Auswahl der Berechnungsmethoden erfolgt mit Hilfe desInformationssystems durch den Anwender. Die tatsachliche Lokalisierungund Aktivierung der zugehorigen Server wird mit Hilfe der entsprechendenVerzeichnisse durch die CORBA-Lauftzeitumgebung erledigt.

Berechnungen durch externe Anbieter: Mit dem System konnen auch Berech-nungsmethoden externer Anbieter integriert werden. Dabei konnen alleder in Abschnitt 2.5.1 genannten Szenarien, Modellubertragung, Methoden-ubertragung oder direkte Verknupfung realisiert werden. Die Sicherheitme-chanismen von CORBA konnen fur eine entsprechende Einschrankung derZugriffsrechte und Verschlusselung der Ubertragung benutzt werden.

102


5.7.6 Implementierung

Die Realisierung eines CAx-Frameworks ist wesentlich aufwendiger als die ein-fache Kapselung bestehender Applikationen, da neben der Implementierung derSchnittstellen auch zahlreiche Dienste entworfen und implementiert werden mus-sen. Der folgende Abschnitt gibt einen Uberblick uber die erforderlichen Arbeits-schritte und die Erweiterungsmoglichkeiten.

Arbeitsschritte

• Das in Abschnitt 5.4.3 vorgestellte Strukturmodell muß in allen beteilig-ten Applikationen implementiert werden. Dazu gehoren auch eine sinnvolleVerteilung der Informationen auf die verschiedenen Modelle, sowie Metho-den zur Datenabfrage, Archivierung und fur die Konsistenzuberwachung.Grundlage ist hierfur eine zu schaffende gemeinsame Schnittstelle aller Ap-plikationen.

• Zur Speicherung der Referenzstruktur muß ein geeignetes Speichermediumausgewahlt und fur die Abbildung von Baustrukturen und Verknupfungenkonfiguriert werden.

• Der Normdienst muß konzipiert und implementiert werden. Dazu gehort dieEinrichtung einer Datenbank fur die allgemeinen Tabellen der Normen sowiedie Bereitstellung der applikationsspezifischen Sichten der in der Datenbankgehaltenen Modelle.

• Die allgemeinen Dienste, die nicht Bestandteil der CORBA-Laufzeitumge-bung sind, mussen spezifiziert und implementiert werden. Dazu gehorendie Definition von Beziehungen und Rollen im Relationship Service und dieImplementierung der Methoden des Persistetence Service und des Seriali-zation Service.

Erweiterungsmoglichkeiten

Eine bestehende Implementierung eines CAx-Frameworks laßt sich erweitern, in-dem weitere Applikationen entsprechend gekapselt und eingebunden werden. Vor-aussetzung fur eine Interoperabilitat mit den vorhandenen Systemen ist, daß diehinzukommenden Applikationen ebenfalls in der Lage, sind mit Baustrukturkom-ponenten zu arbeiten und die fur die Speicherung und Verknupfung der Modellebenotigten Methoden bereitstellen. Ist dies der Fall, konnen die Applikationenauf einer hohen semantischen Ebene Daten austauschen. Die bereits bestehendeInfrastruktur steht allen Applikationen gleichermaßen zur Verfugung.

103


Realisierbarkeit

Die praktische Umsetzung dieses Konzeptes ist mit erheblichem Aufwand ver-bunden. Die Schaffung eines Strukturmodells, in dem sich die Geometrieinforma-tionen und verschiedenen Berechnugsmodelle abbilden lassen, erfordert ein sehrumfangreiches Konzept. Die Implementierung dieses Konzeptes in bestehendenSoftwareumgebungen ist eine weitere schwierige Aufgabe, da allein die Kopplungzweier geometrieverarbeitender Systeme zu erheblichem Aufwand fuhrt und nurmit eingeschrankter Funktionalitat realisierbar ist [AJSK98]. Im Vergleich dazuist die Implementierung der allgemeinen und speziellen Dienste einfach zu rea-lisieren, insbesondere weil durch die standardisierten Dienste von CORBA eingroßer Teil schon implementiert ist.

5.8 Vergleich der Systemkonzepte

Abschließend werden die beiden aufgestellten Systemkonzepte hinsichtlich desAufwands und des erzielbaren Nutzens verglichen. Wegen der noch relativ grobenStruktur kann die Bewertung nur Anhaltswerte liefern.

Aufwand

Der Aufwand kann aufgeteilt werden in Aufwand zur Modellierung des Systemsund in Implementierungsaufwand. Zur Modellierung gehoren die die Formulie-rung von Modellinhalten und die Schaffung eines Prozeßmodells. Die Implemen-tierung kann in Client- und Serverkomponenten aufgeteilt werden.Der Modellierungsaufwand fur ein CAx-Framework ist dabei wesentlich hoherals bei einer einfachen Kopplung, da hier ein Objektmodell und ein Prozeßmo-dell geschaffen werden mussen, die sich in allen Applikationen abbilden lassen.Dementsprechend ist auch der Implementierungsaufwand in den Servern hoher,da das neue Objektmodell auf die internen Modelle der Applikationen abgebildetwerden muß. Bei der einfachen Kopplung besteht der Aufwand fur die Kopplungdarin, die Modelle und Prozesse zweier konkreter Systeme aufeinander abzustim-men. Der serverseitige Implementierungsaufwand ist bei der einfachen Kopplunggering, da die CORBA–Schnittstellen Abbilder der vorhandenen Schnittstellensind.

Nutzen

Als Nutzen werden die Erweiterbarkeit, die Anwenderfreundlichkeit und die Wie-derverwendbarkeit der geschaffenen Strukturen betrachtet.Die Erweiterbarkeit der einfachen Kopplung ist schwierig, da die implementiertenSchnittstellen und die Integration im Client speziell auf die Applikationen abge-stimmt sind. Gleiches gilt fur die Wiederverwendbarkeit, wobei sich durch die

104

5.8 Vergleich der Systemkonzepte

Formulierung in IDL die Objekte zumindest auch in anderen Systemumgebungenverwenden lassen. Eine Anpassung der Modelle ist aber immer erforderlich.Die Erweiterbarkeit und Wiederverwendbarkeit der Objekte im CAx–Frameworkist gut, da diese Objekte als portable, interoperierende Objekte mit ahnlicherStruktur definiert wurden. Ein klares und umfassendes Objektmodell erleichtertdabei die Eingliederung neuer Systeme. Daruberhinaus bietet der objektorien-tierte Ansatz von CORBA die Moglichkeit, bestehende Objekte durch Vererbungund Erweiterung mit zusatzlichen Eigenschaften und Methoden zu erganzen. Auseinem gegebenen Basissystem konnen so problemspezifische Losungen entwickeltwerden. Die Anwenderfreundlichkeit eines CAx–Frameworks ist großer, da durchdie ahnliche Struktur aller Objekte Informationen leichter identifiziert werdenkonnen. Bei der einfachen Kopplung hingegen besteht das Integrationssystemaus einer applikationsspezifischen Anpassung und ist daher fur jede Kopplungunterschiedlich.Bild 5.9 zeigt eine Darstellung der Bewertung. Man erkennt, daß die Vorteile desCAx–Frameworks einen wesentlich hoheren Aufwand nach sich ziehen. Außerdemwird deutlich, daß bei der einfachen Kopplung der Hauptanteil der Implementie-rung im Client liegt.

mittel mittelhoch gering gering hoch

Erweiterbarkeit

Anwenderfreundlichkeit

Weiterverwendung Server

Weiterverwendung Client

Design Prozeßmodell

Design Modellstruktur

Implemtentierung Server

Implementierung Client

Einfache Kopplung CAx-Framework

Auf

wan

dN

utze

n

Bild 5.9: Vergleich der Integrationskonzepte

Fazit

Der Aufwand fur die Definition und Implementierung eines CAx–Frameworks istmit dem heutigen Stand der Technik im Vergleich zum erzielbaren Nutzen erheb-

105


lich zu groß. Insbesondere die Definition einer Datenstruktur, die in der Lage ist,die Modelle bestehender Applikationen vollstandig abzubilden, ist kaum realisier-bar. Dennoch sollte das CAx–Framework als Vision fur zukunftige Entwicklungengesehen werden, da mit diesem System verschiedene Softwaresysteme in verteil-ter Umgebung sinnvoll zusammenarbeiten konnen. Wegen des Umfangs dieserAufgabe sollte die Entwicklung von den Systemherstellern selber vorangetriebenwerden. Die Entwicklungen im Bereich CAD–Referenzmodell und STEP, sowiedie Arbeiten der OMG selber sind hierfur eine gute Basis.Fur die Losung der Integrationsaufgabe ist die vorgestellte einfache Kopplungeine realisierbare Variante. Mit relativ geringem Aufwand kann hiermit eineplattformubergreifende und netzwerkfahige Integration realisiert werden. DiesesKonzept wurde daher aufgegriffen und exemplarisch implementiert.

106

6 Implementierung einesIntegrationssystems

In diesem Kapitel wird eine Implementierung der in Abschnitt 5.6 beschriebe-nen, einfachen Kopplung zweier bestehender Programme vorgestellt. Ziel der In-tegration war es, in den CAD–Gestalungsprozeß integrierte Berechnungen vonSchraubenverbindungen durchzufuhren. Fur das System wurden das CAD–System Pro/ENGINEER und das Berechnungsprogramm fur Schraubenverbin-dungen BOLT [BOL94] in die CORBA-Umgebung SOM [IBM96] der Firma IBMintegriert. Pro/ENGINEER ist ein verbreitetes, parametrisches 3-D CAD–Sytemund reprasentiert damit den Stand der Technik auf dem Gebiet Geometriemodel-lierung. BOLT ist am Institut fur Maschinenkonstruktion - Konstruktionstechnikder TU Berlin entwickelt worden und steht beispielhaft fur ein Rechenverfahren,bei dem standardisierte Konstruktionselemente, hier Schrauben, in einer individu-ell gestalteten Umgebung eingesetzt und berechnet werden mussen. Dabei ist dieSteuerung uber Eingabedateien mit benannten Parametern und die Implemen-tierung in FORTRAN typisch fur eine große Zahl in der Industrie existierenderAnwendungen [VDI99].

6.1 Ubersicht


Das System gliedert sich in die beiden Applikationen, Pro/ENGINEER undBOLT, die uber entsprechende Schnittstellen mit dem Object Request Brokerverbunden sind. Die Schnittstellendefinitionen beschreiben die Objekte und Me-thoden der in den Programmierschnittstellen definierten Objekte. Dies sind aufder Seite des CAD-Systems geometrische Objekte und fur das Berechnungspro-gramm benannte Parameter.

Beide Applikationen arbeiten als Server. Die Verknupfung der beiden Applikatio-nen auf semantischer Ebene erfolgt durch einen in Java implementierten Client,den Modellmanager. Der Modellmanager bildet somit das Strukturmodell ab(vgl. Bild 5.3 auf Seite 90).

Eine abstrakte Schnittstellenbeschreibung definiert allgemeine, von allen Appli-

107

6 Implementierung eines Integrationssystems

O R B

C A EC A D

Applet

ServerWeb

Save UpdNew ?

Pro/ENGINEER

Modellmanager

BOLT

Naming Service

Load

download

Bild 6.1: Systemstruktur des implementierten Integrationssystems

kationen benotigte Objekte, wie einen Basistyp fur Modelle und einfache Ob-jekte sowie die zugehorigen Methoden zum Identifizieren und Vergleichen vonObjekten. Außerdem werden in Form eines Common Object Service verschiedeneContainerklassen zum Transport von Objekten bereitgestellt.Das System ist so aufgebaut, daß die Geometriemodellierung auf dem lokalenRechner erfolgt, wahrend das Berechnungprogramm von einem entfernten Serverbezogen wird. Diese Aufteilung wurde aus folgenden Grunden vorgenommen:

• Die fur die Darstellung von Geometriedaten erforderliche zu ubertragendeDatenmenge ist zur Zeit noch sehr groß, so daß sich bei einem entferntlaufenden CAD-System eine starke Netzbelastung ergeben wurde.

• Die verfugbaren CAD-Systeme sind fur einen lokalen Betrieb optimiert.

• Das Geometriemodell ist der eigentliche “Modellierungsgegenstand” und istEigentum des Anwenders, wahrend das verwendete Berechnungsprogrammauch von einem externen Anbieter bezogen werden konnte.

Eingebettet in eine Unternehmensstruktur wurde die Funktionalitat des CAD-Systems am Konstruktionsarbeitsplatz durch von der Berechnungsabteilung odervon externen Anbietern bereitgestellte Berechnungsmethoden erweitert. DasGeometriemodell wird mit den vorgenommenen Anderungen und den zusatzlichenInformationen in der lokalen Datenbasis gespeichert. Die verwendeten Methodenbleiben “Eigentum” des Anbieters, werden nicht mit gespeichert und behaltenauch keine Modellinformationen in ihrer Datenbasis.

108

6.1 Ubersicht

6.1.2 SOM als CORBA–Laufzeitumgebung

Als CORBA-Umgebung wurde SOMobjects 3.0 der Firma IBM gewahlt. SOM-objects ist aus dem System Object Model (SOM) entstanden, das Grundlage furdas Betriebssystem OS/2 der Firma IBM war. Mit der Entwicklung von COR-BA wurde das System durch Erweiterungen und Anpassungen konform zu demneu definierten Standard gemacht. Die Version SOMobjects 3.0 ist konform zumStandard CORBA 2.0.

Die zu SOMobjects gehorende Software ermoglicht es, Arbeitsumgebungen zuentwickeln, die sich aus verteilten, interoperierenden Objekten zusammensetzen.Die Software besteht aus folgenden Komponenten [IBM96]:

IDL Compiler. Die neutralen Schnittstellenbeschreibungen werden mit einemIDL-Compiler in entsprechende sprachabhangige Konstrukte umgewandelt.Serverseitig sind dies Methodenkopfe und die zugehorigen Deklarationen.Fur die Verwendung im Client werden die Deklarationen erzeugt, die dieneu definierten Datentypen im Clientprogramm bekannt machen und furdie Weiterleitung der Methodenaufrufe an die Laufzeitumgebung sorgen.Servercode kann in den Programmiersprachen C und C++ und Clientde-klarationen konnen fur C, C++ und Java erstellt werden.

SOM Laufzeitumgebung. Das verteilte Objektmodell von CORBA wird durchdie SOM Laufzeitumgebung realisiert. Die Softwarekomponente verwaltetdie Klassen und die dazugehorigen Objekte und leitet die Methodenaufrufean die Implementierungen der Objekte weiter.

Verteilte Arbeitsumgebung. Die in CORBA festgelegte Infrastruktur fur einCORBA-basiertes System wird durch die verteilte Arbeitsumgebung (engl.:Distributed Framework) bereitgestellt. Dazu gehoren der Object RequestBroker und die verschiedenen Verzeichnisse uber die im System definiertenSchnittstellen und Implementierungen.

Object Services. Zusatzlich zur Arbeitsumgebung werden die implementiertenObject Services zur Verfugung gestellt. Dabei wird in SOM 3.0 nur ein Teilder in CORBA definierten Dienste angeboten. Die implementierten Dienstesind: Life Cycle, Security, Transaction und Naming.

Implementierungen von SOMObjects existieren fur die Betriebssysteme AIX,OS/2 und Windows95.

109


6.2 Geometriemodellierer

6.2.1 Pro/ENGINEER

Das CAD–System Pro/ENGINEER ist ein durchgangig parametrischer 3-D Geo-metriemodellierer. Die Modellierung erfolgt durch Hinzufugen von Konstrukti-onselementen (engl.: Features) zu einem als Basiselement bezeichneten Ausgangs-korper. Als Konstruktionselemente konnen die systeminternen Grundelemente,wie Bohrung, Fase, Schlitz oder Massivkorper, oder aus diesen Grundelementenzusammengesetzte Geometriemakros verwendet werden. Die Konstruktionsele-mente werden mit Hilfe von Bedingungen und benannten Parametern an beste-henden Objekten ausgerichtet.Mehrere Bauteile konnen zu einer Baugruppe zusammengesetzt werden. Dabeikann die Positionierung der Komponenten sowohl anhand von Koordinaten furLage und Ausrichtung erfolgen als auch durch die Verknupfung von geometrischenObjekten auf beiden Komponenten uber einfache geometrische Relationen.Die Parameter eines Bauteils konnen zueinander in Beziehung gesetzt oder auseiner gespeicherten Tabelle bezogen werden. In verschiedenen Modulen, zumBeispiel fur die Ableitung von Fertigungszeichnungen oder fur die Erzeugungvon NC-Datensatzen, konnen die erzeugten Modelle weiterverarbeitet werden.Pro/ENGINEER verwendet dabei fur alle Darstellungen dieselbe Datenbasis, so-daß bei Anderungen in einer Darstellung alle anderen Sichten automatisch nach-gefuhrt werden.Fur den programmgesteuerten Zugriff auf die Geometriemodelle steht mit Pro/-TOOLKIT eine leistungsfahige Programmierschnittstelle zur Verfugung. Mit derSchnittstelle sind alle Operationen moglich, die auch uber die Benutzungsoberfla-che ausfuhrbar sind. Daruber hinaus lassen sich die Benutzungsoberflachen umweitere Menupunkte und die internen Datenstrukturen um zusatzliche Merkmaleerweitern.Die Implementierung von Pro/TOOLKIT Applikationen erfolgt entweder als dy-namisch gebundene Bibliothek oder als eigenstandiges Programm, das uber In-terprozeßkommunikation auf den Pro/ENGINEER Prozeß zugreift. Die letztereVariante bietet eine großere Flexibilitat. Auf diese Weise kann Pro/ENGINEERals Teil einer ubergeordneten Anwendung gestartet werden [Par97].

6.2.2 Schnittstellendefinition des Geometriemodellierers

In der Geometrieschnittstelle sind zwei Partialmodelltypen, Part und Assembly,fur Bauteile und Baugruppen definiert. Partialmodelle konnen als eigenstandigeModelle in die Applikation geladen werden. Die Methoden zum Aufrufen undSchließen von Baugruppen und Bauteilen sind in der abstrakten Metaklasse furPartialmodelle definiert. Eine Baugruppe besteht aus einem oder mehreren Bau-teilen und den Verknupfungen zwischen diesen Bauteilen. Ein Bauteil kann in

110


seine geometrischen Bestandteile Flachen, Konturen, Kanten, Punkte und Kon-struktionselemente zerlegt werden. Zusatzlich sind in beiden Modelltypen Be-zugsebenen und -achsen definiert, an denen beim Modellieren die Konstrukti-onselemente positioniert werden. Bild 6.2 zeigt die Klassenhierarchie der geo-metrischen Objekte. Die Klassen wurden fur das CAD-System Pro/ENGINEERimplementiert, konnten aber auch fur andere CAD–Systeme, beispielsweise CA-TIA implementiert werden. Die interne Reprasentation der Objekte ware dannunterschiedlich, aber trotzdem konnte in gleicher Weise auf sie zugegriffen werden.

�� "!"# �$�

% &('&*),+.-�+0/

1 243457686:9 ;=<>;7?@5BA

C 5=2D9 5FEGAIH�5

JLK MONPK

Q R(ST=UWVYX.Z�UW[�\] ^`_ba [c[

d�egfYhji kmlonqp r hjsutv eow p x e,syf z|{}{ p iLt~��

z��o��{ � p v tx ��e,� p xm� � �}f z sPw � � � p x ��e,� p � ��t� � � ljp s

�(�� g�G��W�� (�� g��W��

�� "¡£¢¥¤�¦L§¨¤ª©=©B�

«¬�®°¯o± ²>³8´ µ ®°¯·¶ «W¸�¹�¯º¶ »�¼¾½¸¿®°¯·ÀÁ¶ ³ «¹ ³ ± ²FÂoÂ ¶,Ã ½Äm¸ ¼

Å Æ�ÇÈ}ÉoÊ�Ë�ÌÎÍÏ$ÐÒÑ�Ó�Æ,ÐªÆ,Ì}ÉÔ�Æ�Ç¿ÉPÆÖÕ�Ó�×�Ø}Ø}Æ

Å ×,È�ØÙÉÇP×,ÚÛÉPÆÖÕ�Ó�×�Ø}Ø}ÆÜÜ Ý

Bild 6.2: Struktur der Schnittstelle zum Geometriemodellierer

Fur die Analyse von Geometriemodellen stehen Funktionen zum Auffinden vonObjekten mit einem bekannten Namen und von Objekten, die in einer bestimm-ten Relation zu einem gegebenen Objekt stehen, zur Verfugung. Durch Namenkonnen Norm- und Standardteile sowie Konstruktionselemente identifiziert wer-den, die aus einer Bibliothek entnommen sind und deren Name daher bekanntist. Die Identifizierung von Objekten anhand von Relationen wird fur Struktu-

111


ren verwendet die sich nicht, oder nicht in jedem Fall aus Bibliothekselementenzusammensetzen. Die gesuchten Elemente und die zwischen ihnen bestehendenRelationen werden in Form eines Relationsgraphen ubergeben. Bild 6.3 zeigteinen Relationsgraphen fur eine einfache Bohrung. Die Analysefunktion zerlegtden Graphen und versucht eine eindeutige Zuordnung von Objekten im Gra-phen zu Objekten des Geometriemodells herzustellen. Ist die Abbildung nichteindeutig moglich, wird vom Benutzer eine Auswahl per Mausklick angefordert.Das Ergebnis des Aufrufs wird als Liste der gefundenen Elemente an den Clientzuruckgegeben. Wegen der sehr schnell sehr komplex werdenenden Relations-graphen ist es auch moglich, die gesuchten Bezugselemente direkt per Mausklickauszuwahlen.

senkrecht

parallel

grenzt an

coaxial

Bild 6.3: Relationsgraph fur eine einfache Bohrung

Zur Ermittlung von geometrischen Eigenschaften stehen Methoden zur Verfu-gung, die sowohl Eigenschaften eines einzelnen Objektes wiedergeben (Lange ei-ner Kante, Flacheninhalt, usw.) als auch Methoden, die aus der Relation zweierObjekte entstehen (Abstand zweier Achsen, Winkel zwischen zwei Ebenen usw.).Bei Eigenschaften, denen im Parametrikmodell ein Parameter zugeordnet ist,kann auch der Parameter direkt verknupft werden. In diesem Fall sind die Ei-genschaften des Modells durch den Client veranderbar.

Eine automatische Variation des Geometriemodells ist außerdem durch Hinzufu-gen oder Entfernen von Bauteilen oder Konstruktionselementen moglich. Norm-und Standardteile konnen, sofern sie aus einer Teilefamilie stammen, uber dieSchnittstelle durch andere Elemente der selben Familie ersetzt werden.

112


6.2.3 Implementierungsdetails

Programmodule

Die Implementierung der CAD-Schnittstelle besteht aus dem eigentlichen Ser-verprogramm, der Bibliothek mit den Objektimplementierungen und dem Pro-gramm Pro/ENGINEER. Das Serverporgramm wird als Kindprozeß durch dieals Damon laufende CORBA Umgebung gestartet, sobald eine Anfrage von ei-nem Client nach einem Geometrieobjekt gestellt wird. Das Serverprogrammist eine Standardimplementierung aus der CORBA–Umgebung und bildet dasHauptprogramm fur die als dynamisch gebundene Bibliothek realisierte Objek-timplementierung. In der Objektimplementierung sind die in der Schnittstellen-beschreibung enthaltenen Konstrukte definiert und mit Hilfe der Pro/TOOLKITBibliotheken implementiert. Zu Beginn einer Sitzung wird durch die Objektim-plementierung der Pro/ENGINEER Prozeß im asynchronen Modus gestartet.In diesem Modus ist das Serverprogramm das Hauptprogramm, das Funktio-nen im Pro/ENGINEER Prozeß aufruft, wahrend im synchronen Modus derPro/ENGINEER Prozeß das Hauptprogramm ist [Par97]. Der Datenaustauschzwischen Serverprogramm und Pro/ENGINEER erfolgt uber Interprozeßkommu-nikation. Die Kommunikation zwischen dem Client und den Objektimplementie-rungen erfolgt uber Remote Procedure Calls. Eine schematische Darstellung derProgrammodule zeigt Bild 6.4.

Pro/ENGINEER

� � � � � � � � ��

� � � � � � � � ��

CAD - Server

ORB (SOM Dämon)

Client

Pro

/T

OO

LKIT

Impl

emen

-tie

rung

Obj

ekt

��

��

IPC

RPC

DLL

startet Kindprozeß

Bild 6.4: Programmodule des Geometrie–Servers

Struktur der Objekte

Die Objektimplementierung ist fur die Speicherverwaltung aller durch Client–Programme erzeugte Objekte verantwortlich. Als Attribute sind in diesen Objek-ten Identifizierungsmerkmale und Verwaltungsdaten gespeichert. Geometrische

113


Merkmale werden immer aktuell aus dem CAD–System ermittelt. Zur Identifizie-rung werden die Speicheradresse und die Identifizierungsnummer (Id) der entspre-chenden Struktur im CAD–System gespeichert. Mit Hilfe der nur wahrend einerSitzung gultigen Speicheradresse konnen Funktionsaufrufe direkt an die Struk-tur im CAD–System weitergeleitet werden. Die Identifizierungsnummer kann furdie dauerhafte Speicherung von Objektreferenzen verwendet werden, da sie ubermehrere Sitzungen unverandert bestehen bleibt. Dies kann bei der Archivierungvon integrierten Berechnungen genutzt werden. Außerdem sind in der Objektim-plementierung Topologieinformationen gespeichert. Dies sind die ubergeordneteStruktur die das Objekt enthalt und die weiteren Strukturen, die diesem Objektzugehoren. Am Beispiel einer Flache (Plane) ist das ubergeordnete Objekt dasenthaltende Bauteil und die zugehorigen Objekte sind die begrenzenden Kanten.Bild 6.5 zeigt eine symbolische Darstellung der Klasse Plane.

getParent()

getChild()

getId()

getArea()

getNormvector()

update()

Objektreferenz

Kinder

Elternobjekt

Objekt Id

Name

Speicheradresse

Part

Liste

Zeichenkette

Ganzzahl

...()

Met

hode

n

Attr

ibut

e

PlaneProSurface{ ...}...ProPart{ ...}

Pro/Engineer Kernel

Bild 6.5: Struktur eines Geometrieobjektes in der Objektimplementierung

Um den Aufwand fur die Konsistenzuberwachung zu minimieren, werden geome-trische Eigenschaften nicht in der Objektimplementierung gespeichert, sondernbei Bedarf als Funktionsaufruf aus dem CAD–System ermittelt.Eine Inkonsistenz der Toplogie in der Schnittstellenimplementierung und im CAD–System kann entstehen, wenn das CAD–Modell verandert wird und dadurch inder Schnittstelle Verweise auf nicht mehr existierende CAD–Strukturen gespei-chert sind. Eine Variation des Geometriemodells kann wahrend einer integriertenBerechnung auf zwei Weisen erfolgen: durch Austausch eines Teils einer Teile-familie und durch Verandern von Parametern. Beim Austausch eines Teils wirdals Ergebnis des Funktionsaufrufs die Referenz des neuen Teils zuruckgegben undanstelle der bestehenden eingesetzt. Damit ist die Konsistenz fur die ubergeord-neten Objekte und fur das ersetzte Objekt gewahrt. Lediglich die untergeord-neten Objekte mussen neu verknupft werden. Dies kann manuell oder, sofern

114

6.3 Berechnungssystem

die Strukturen benannt wurden, anhand des Namens durch das System erfolgen.Bei der Variation von Parametern werden die neuen Parameterwerte zunachstnur in der Schnittstellenimplementierung gespeichert. Erst nach einem entspre-chenden Funktionsaufruf (update() ) werden die Parameter in das CAD–Systemubertragen und das CAD–Modell wird regeneriert. Die Implementierung derupdate–Funktion uberpruft nach erfolgreicher Regenerierung alle Referenzen desbetroffenen Bauteils. Sollte ein Objekt auf ein nicht mehr gultige Strukter imCAD–System verweisen, muß dieses Objekt neu verknupft werden.


6.3.1 Schraubenberechnungsprogramm BOLT

BOLT wurde am Institut fur Maschinenkonstruktion - Konstruktionstechnik furdie Berechnung von Schraubenverbindungen entwickelt. Mit sieben Modulen kon-nen Zylinderverbindungen, Balkenverbindungen, Apparateflansche, verschraubteKreisplatten, rotationssymmetrische Mehrschraubenverbindungen, Rechteckflan-sche und Kragflansche berechnet werden. Allgemeine, fur alle Module geltendeDaten, werden als Werkstoffdaten, Standardwerte und Berechnungswerte in Da-teiform zur Verfugung gestellt. Spezielle modulspezifische Daten werden in einerNorm- und Hilfswertedatei gespeichert.Das Programm arbeitet parameterorientiert im Batchbetrieb. Die Eingangspa-rameter werden aus der Eingabedatei gelesen, auf syntaktische Richtigkeit undKonsistenz uberpruft und anschließend an das aufgerufene Modul ubergeben. Beieiner fehlerhaften Eingabedatei wird ein Hinweis in die Ergebnisdatei geschriebenund die Berechnung abgebrochen. Bei vollstandigen und richtigen Eingabedatenwird die Berechnung durchgefuhrt und die Ergebnisse werden in einer lesbar for-matierten Textdatei gespeichert (siehe Bild 6.6).Die Berechnungsmodule sind in FORTRAN77 implementiert und dadurch aufverschiedenen Plattformen ubersetzbar. Fur das Betriebssystem Windows 95wurde inzwischen eine komfortable Benutzungsoberflache fur die Erstellung derEingabedateien und die Visualisierung der Ergebnisse erstellt.

6.3.2 Struktur der Schnittstelle

Die Schnittstelle zum Schraubenberechnungsprogramm BOLT arbeitet parame-terorientiert. Es werden Inputparameter fur Eingabewerte, Outputparameter furErgebniswerte und Temporary Parameters fur Zwischenergebnisse unterschieden.Die Zwischenergebnisse haben nur innerhalb des Rechenschemas eine Bedeutung,konnen aber bei der Durchfuhrung von Berechnungen von Interesse sein, um dasZustandekommen eines Ergebnisses zu verdeutlichen. Die von BOLT bereitge-stellten Partialmodelle sind die einzelnen Module fur die verschiedenen berechen-

115


*********************************************************************** ** AUSLEGUNG EINER SCHRAUBENVERBINDUNG - HAUPTBELEG ** ************************************************ ** ** 1. BENUTZTER BERECHNUNGSMODUL ---- VDI 2230 ---- BOLT 4.2 ** ** 2. AUSGABEDATEN ** ------------------------------------------------------------------ ** I SCHRAUBE D = I M 10.00 I STEIGUNG P = 1.50 I ** I SCHRAUBENLAENGE I 69.00 MM I GEWINDEL. B = 28.00 I ** I FESTIGKEITSKLASSE GUETE = I 12.90 I I ** I---------------------------+-------------+----------------------I ** I MUTTER I M 10.00 I STEIGUNG P = 1.50 I ** I SCHEIBE DSCH = I 21.00 MM I HSCH = 2.00 I ** I---------------------------+-------------+----------------------I ** I BOHRLOCHDURCHMESSER DB = I 11.00 MM I I ** I KOPFKREISDURCHMESSER DK = I 16.00 MM I I ** I---------------------------+-------------+----------------------I ** I ANZIEHFAKTOR ALPHA = I 1.60 I NACH VDI 2230 I ** I---------------------------+-------------+----------------------I ** I ANZIEHMOMENT,THEORETISCH I 84.72 NM I I ** I EINSTELLMOMENT-10.PROZENT I 76.25 NM I I ** I---------------------------+------------------------------------I ** I ANZIEHVERFAHREN : I DREHMOMENTENGESTEUERT MIT I ** I I DREHMOMENTENSCHLUESSEL I ** I---------------------------+------------------------------------I ** I SICHERHEITEN GEGEN - I I I ** I - DAUERBRUCH I 0.83 I VORH. SPAN. = 63.22 I ** I - FLAECHENPRESS. UEBERS. I 4.07 I FLAECHENPRES. 221.33 I ** I - LOCK.D.VERB.(FVMIN/FPA) I 5.21 I FVMIN IN KN = 27.80 I ** I - QUERKRAFTUEBERS. I 6.43 I REIBFAKTOR = 0.20 I ** ------------------------------------------------------------------ ** ** 3. SCHRAUBENKRAEFTE UND SICHERHEITEN ** X - X-KOORDINATE DER SCHRAUBE ** P1 - AUSLASTUNG DER SCHRAUBE NACH DEM VORSPANNEN ** P2 - AUSLASTUNG DER SCHRAUBE BEI BETRIEBSLAST ** ----------------------------------------------------------------- ** I X I FKRES I FSA I FSMAX I P1 I P2 I ** I MM I N I N I N I PROZ. I PROZ. I ** I----------+----------+----------+----------+---------+---------I ** I 0.00 I 22468. I 2709. I 48500. I 90.00 I 94.33 I ** ----------------------------------------------------------------- ***********************************************************************

Bild 6.6: Beispiel eines BOLT Ergebnisausdrucks

116


baren Verbindungstypen.

Von der CORBA–Schnittstelle werden die Werte aller Parameter gespeichert. BeiDurchfuhrung einer Berechnung mit dem Aurruf proceed() werden die Werte derInputparameter in die Eingabedatei von BOLT geschrieben und das Programmgestartet. Nicht gesetzte, aber benotigte Werte werden dabei aus einer Listevon Standardwerten bezogen. Anschließend werden mit den Ergebnissen der Be-rechnung die Werte der Resultparameter und der Temporary Parameters uber-schrieben. Als Variation kann dem Aufruf proceed() eine Liste von Parameternubergeben werden, die fur die aktuelle Berechnung verwendet werden soll.

6.3.3 Implementierungsdetails

Programmodule

Ahnlich wie beim Geometrie–Server besteht das Berechnungssystem aus einemStandard–Serverprogramm und einer dynamisch gebundenen Bibliothek mit dereigentlichen Objektimplementierung. Anders als beim CAD–System wird hier diein C implementierte Schnittstellenimplementierung direkt mit den in FORTRANimplementierten Moduldateien von BOLT zusammengebunden. Dies ist moglich,weil der C–Compiler und der FORTRAN–Compiler gleichartige Moduldateienerzeugen. Auf diese Weise sind direkte Funktionsaufrufe zwischen den beidenBibliotheken moglich. Werden bei solchen Funktionsaufrufen Speicheradressenubergeben, konnen auch Speicherbereiche, die von BOLT reserviert wurden, inder Schnittstellenimplementierung ausgewertet werden. Bild 6.7 zeigt schema-tisch die einzelnen Programmodule und ihre Verknupfungen.

Funktionsweise

Die Parameter und ihre aktuellen Werte werden von der Schnittstellenimplemen-tierung zwischengespeichert. Eine Berechnung wird durch den Funktionsaufrufproceed() gestartet. Da BOLT die Eingabedaten in Form einer Datei benotigt,werden fur die Berechnung samtliche Parameter entsprechend formatiert in eineEingabedatei geschrieben. Anschließend wird die Hauptroutine von BOLT auf-gerufen. Diese analysiert die Eingabedatei und legt die Parameter in mehrerenFeldern im Speicher ab. Die eigentliche Berechnung erfolgt mit den im Speicherbefindlichen Werten und auch die Ergebnisse werden im Speicher abgelegt, bevorsie in die Ergebnisdatei geschrieben werden. Bevor die Hauptroutine von BOLTbeendet wird, erfolgt ein Sprung in die Objektimplementierung. Bei diesem Funk-tionsaufruf werden die Speicheradressen der zuvor angelegten Parameterfelderubergeben. Fur die zuvor definierten Ergebnisparameter werden die Speicherbe-reiche ausgewertet und die Ergebnisse in die entsprechenden Objekte ubertragen.Ist dies erfolgt, wird die Hauproutine von BOLT beendet und der Speicherbe-reich fur die Felder wieder freigegeben. Nach Beendigung des Funktionsaufrufs

117


� � � � � � � � ��

� � � � � � � ��

ORB (SOM Dämon)

Client

Unterprozeßstartet

BO

LTF

OR

TR

AN

BOLT- Server

Que

lltex

t

BO

LTO

bjek

t-im

plem

emt.

��

��

DLL

RPC

Bild 6.7: Programmodule des Berechnungs–Servers

proceed() stehen in den Parameterobjekten der Schnittstellenimplementierung dieaktuellen Ergebniswerte der Berechnung.

Als schwierig erwies sich die Behandlung von Fehlern bei unvollstandigen oder un-gultigen Eingabeparametern, da diese Ereignisse von BOLT zwar erkannt werden,aber nur durch eine vorzeitige Programmbeendigung und einen entsprechendenKommentar im Ergebnisausdruck behandelt werden. Im Ergebnis außerten sichsolche Programmabbruche meist dadurch, daß ein großer Teil der Ergebnispara-meter den Wert null hatte. Um dem Anwender die Moglichkeit zu geben, beizweifelhaften Ergebnissen die Ergebnisdatei direkt einzusehen, kann der Inhaltder Ergebnisdatei mit einer zusatzlichen Methode direkt abgerufen werden. Eineausfuhrliche Fehlerbehandlung konnte uber eine Anpassung der Fehlerbehandlun-groutinen von BOLT erfolgen. Erfolg oder Mißerfolg einer Berechnung konntenals Ergebnis des proceed()-Aufrufs ubertragen werden.

6.4 Modellmanager

Im Modellmanager werden die Objekte aus den Applikationen zusammen mitDatenbankinformationen auf semantischer Ebene zu einem Strukturmodell ver-knupft. Inhaltlich setzt sich das Strukturmodell aus den in Bild 5.3 auf Seite 90gezeigten Informationen zusammen. Dabei werden die geometrischen Objekte ausdem CAD–Modell, die Rechenergebnisse aus BOLT und die ubrigen Daten auseiner Datenbank oder vom Benutzer bezogen. Der Modellmanager ist damit der

118

6.5 Ablauf einer integrierten Berechnung

Client fur die beiden Applikationen und die Datenbank. Das im Modellmanagergehaltene Modell stellt das aktuelle Arbeitsmodell fur den Benutzer dar und istnicht zu jeder Zeit konsistent mit beiden Partialmodellen. Die Konsistenz kanndurch gezielte Interaktion des Benutzers wiederhergestellt werden. Durch diesenMechanismus kann eines der Modelle variiert und optimiert werden, ohne daß dasandere Modell standig nachgefuhrt werden muß. Beispielsweise kann das Rechen-modell bezuglich des Schraubendurchmessers optimiert werden und anschließenddie geometrische Realisierbarkeit im Geometriemodell uberpruft werden.

Bei Aufruf des Modellmanagers wird der Graph des gewahlten Modells im Spei-cher angelegt und mit den ausgewahlten Partialmodellen verknupft. Dazu wirdentweder versucht, das Modell anhand der im Relationsgraphen gegebenen Bedin-gungen zu identifizieren, oder die Zuordnung der Komponenten, Bezugselementeund Parameter erfolgt durch den Benutzer. Nach vollstandiger Verknupfung derModelle konnen durch Variation einzelner Parameter die Partialmodelle variiertwerden. Auch hier ist eine vollstandig automatisches Nachfuhren der Partialmo-delle nicht immer moglich, sodaß eine Benutzerinteraktion erforderlich werdenkann.


Dieser Abschnitt beschreibt den prinzipiellen Ablauf einer Berechnung, die Funk-tion der einzelnen Systemkomponenten und die erforderliche Kommunikation.Der Ablauf wird zuerst an einem Interaktionsdiagramm erklart und anschließendan einem Anwendungsbeispiel veranschaulicht.

6.5.1 Interaktionsdiagramm

Die an einer integrierten Berechnung beteiligten Komponenten und deren Zusam-menwirken sind in Bild 6.8 dargestellt. Uber das in Java implementierte ControlCenter konnen alle Anwendungen im System gestartet und auch die Modelle aus-gewahlt und verknupft werden. Das Arbeitsmodell der integrierten Berechnungwird vom ebenfalls in Java implementierten Modellmanager gehalten und darge-stellt. Die Methodenaufrufe des Modellmanagers gehen uber den Object RequestBroker (ORB) an die entsprechenden Serverprozesse.

1. Aufruf eines Geometriemodells. In einem Auswahlfenster des Con-trolCenters kann der Benutzer das CAD–System und ein Modell wahlen.Im Implementation Repository der CORBA Umgebung ist eine Zuordnungvon Modelltypen zu Applikationen und damit zu Serverprogrammen gespei-chert. Anhand dieses Eintrages wird ein geeigneter, lokal implementierterServer ausgewahlt.

119


� � � ��

� ��

� ��

! "�#%$&! '( ) "�#*) $

+ ) ! , ! - ) '.'

, ! - ) '�'/, 0 "10 2 ) $

3 4 576 8 , ! - ) '.'

9 : ;=<

> ? @�A B ADC EGF AHF IJF K B

L F M L N MOF A B�PRQ C E @�SUT

L C V V B L A WJF ?GF Q BXA B ? K

Q C E @.SYT

L C V V B L A

B V A @ZA @.B[K

L C V V B L AAGC

I\C M]A

^ _a`cbed

f gihHjlk

mon pUq

E I

r sutwvx suy{zwsOy

|~} � }

|~} � }

� �

� �

� �

� �

� �

� �

� �

Bild 6.8: Interaktionsdiagramm einer integrierten Berechnung

2. Start des CAD-Systems. Der ORB startet den Geometriemodellierer,indem er den zuvor identifizierten Server startet. Der Server halt uber In-terprozeßkommunikation Kontakt zum ORB und ladt die als dynamisch ge-bundene Bibliothek implementierte Pro/TOOLKIT Applikation. Der Mo-dellmanager veranlaßt den Geometrieserver das ausgewahlte Geometriemo-dell zu laden.

3. Verknupfen mit einem Rechenmodell. Aus der Liste der verfugbarenBerechnungsmethoden wahlt der Benutzer im ControlCenter eine fur seinProblem geeignetes Berechnungsprogramm und dazu ein passendes Modell-schema. Anschließend startet er den Modellmanager, um eine Verknupfungzwischen dem lokalen Geometriemodell und dem gewahlten Rechenmodelherzustellen.

120


4. Start des Berechnungssystems. Vom ModellManager wird eine An-frage an den ORB gesendet, um einen Zugriff auf das Berechnungssystemzu erhalten. Mit Hilfe des Implementation Repository lokalisiert der ORBden entsprechenden Server und startet ihn. Der neue Server ist ebenfallsuber Interprozeßkommunikation mit dem ORB verbunden und ladt die dy-namisch gebundene BOLT-Bibliothek nach.

5. Verknupfung mit dem Strukturmodell. Durch Analyse der im Modell-Manager gespeicherten Bedingungen und Relationen und durch Auswahlder entsprechenden Komponenten im Geometriemodell werden die Kompo-nenten des Strukturmodells mit den Elementen in den Servern verknupft.

6. Berechnung und Variation der Modelle. Mit dem jetzt vorliegendenStrukturmodell kann die Berechnung durchgefuhrt werden. Veranderungenim Strukturmodell mussen in beiden Partialmodellen nachgefuhrt werden.Sofern die betroffenen Objekte uber Bedingungen mit dem Strukturmodellverknupft sind, ist eine automatische Variation der Partialmodelle moglich.Anderenfalls muß der Benutzer die Anderungen manuell vornehmen.

7. Archivierung der Ergebnisse. Die Veranderungen am Geometriemodellwerden vom CAD-System gespeichert. Das bei der Berechnung erzielteErgebnis wird vom ModellManager als Datei gespeichert.

6.5.2 Anwendungsbeispiel

Wahrend im vorigen Abschnitt die Interaktionen der Systemkomponenten be-schrieben wurden, steht in diesem Abschnitt die Darstellung des Systems ausBenutzersicht im Vordergrund. Im folgenden Beispiel wird beschrieben, wie mitdem System eine bestehende Pleuelschraubenverbindung (siehe Bild 6.9) berech-net und variiert werden kann. Das Vorgehen wird anhand der durchzufuhrendenArbeitsschritte erlautert. Die Funktionsweise der einzelnen Softwarekomponentenwird an den entsprechenden Stellen im Text erlautert. Folgende Arbeitsschrittesind durchzufuhren:

1. Start des ControlCenters. Uber das ControlCenter werden die im Sy-stem vorhandenen Programme gestartet und die Modelle ausgewahlt. Mitdem Aufruf des ControlCenters wird die CORBA–Umgebung initialisiert.Die Benutzungsschnittstelle enthalt die Auswahlmenus fur die Systeme unddie zu den Systemen verfugbaren Modelle. Uber drei Bedienfelder am Kopfdes Fensters konnen die Applikationen einzeln oder gemeinsam gestartetwerden. Bild 6.10 zeigt die Benutzungsoberfache des ConrolCenters miteinem aufgeklappten Menu zur Auswahl des CAD–Systems. Der Benut-zer wahlt hier das Modell “pleuel bg” , das im CAD–System Pro/Engineerdargestellt und mit dem Modul fur zylindrische Einschraubenverbindungen(VDI 2230) des Berechnungsprogramms BOLT berechnet werden soll.

121


Bild 6.9: Baugruppe mit der zu berechnenden Schraubenverbindung

ControlCenter

Bild 6.10: Benutzungsoberflache des ControlCenters

122


2. Aufruf des ModellManagers. Durch Anwahlen des“Verbinden”Bedien-feldes werden die Systeme mit der aktuell ausgewahlten Konfiguration vonModellen und Systemen gestartet. Anschließend wird mit dem ModellMa-nager die Benutzungsoberflache fur die integrierte Berechnung gestartet.

ModellManager

Der ModellManager liefert die Benutzungsoberflache fur die integrierte Be-rechnung. Mit ihm konnen die Bestandteile des Strukturmodells und dieVerknupfungen zwischen den Objekten uberwacht und visualisiert werden.Das Arbeitsfenster enthalt auf der linken Seite die Darstellung der Baustruk-tur in Form eines Baumes (vergleiche Bild 6.11). Auf der rechten Seite sinddie in Gruppen geordneten Parameter der aktuell ausgewahlten Baustruk-turkomponente und die Ergebnisse der zuletzt durchgefuhrten Berechnungdargestellt. Am unteren Rand des rechten Bildschirmbereichs kann die ge-wunschte Rechenoperation gewahlt werden. Die Auswahl verandert die inden anderen Fenstern dargestellten Informationen und legt die jeweiligenBedingungen fur die Verknupfungen mit den Partialmodellen fest.

Bedienfelder

Parameterfenster

Ergebnisfenster

Rechenoperationen

Baustruktur

Bild 6.11: Benutzungsoberflache des ModellManagers im Uberblick

In der Baustrukturdarstellung sind die fur eine Berechnung erforderlichenKomponenten mit einem Quadrat und die optionalen Komponenten miteinem Kreis gekennzeichnet (siehe Bild 6.12). Kompenenten, die mit einemElement des Geometriemodells verknupft sind, werden farbig markiert. FurKomponenten, die in verschiedenen Auspragungen vorkommen konnen, bei-spielsweise eine Schraube als Kopfschraube oder Stiftschraube, wurden fur

123


die Darstellung die Symbole unterteilt. Durch Anwahlen des Symbols wirdder Baum aufgeklappt und die moglichen Auspragungen werden angezeigt.

erforderliche Komponente

ausgewählte Ausprägung

erforderliche Komponente(verknüpft)

optionale Komponente

(mit verschied. Ausprägungen)

Bild 6.12: Erlauterung der Symbole fur die Baustrukturelemente

Mit dem Aufruf des ModellManagers wird das Strukturmodell in den Spei-cher geladen. Das Strukturmodell bildet das Modellschema, in dem alledurch das gewahlte Programm berechenbaren Modelle abgebildet sind.

3. Auswahl einer Rechenoperation. Im ModellManager wahlt der Be-nutzer die gewunschte Rechenoperation, in diesem Fall die Durchfuhrungeines Festigkeitsnachweises. Daraufhin werden im Ergebnisfenster die beidieser Operation erzielbaren Ergebnisse dargestellt und die Bedingungen imModell angepaßt.

4. Verknupfung mit dem Geometriemodell. Durch Auswahlen des ent-sprechenden Bedienfeldes wird die Prozedur zum Verknupfen des Struktur-modells mit dem Geometriemodell gestartet. Der Benutzer erhalt daraufhinein Fenster mit den im Geometriemodell vorhandenen Bauteilen und denim Strukturmodell zu besetzenden Komponenten. Durch Auswahlen den“Connect” Bedienfeldes (siehe Bild 6.13) werden die markierten Elementemiteinander verknupft und die Berechnungsparameter aus dem Geometrie-modell ermittelt.

Norm- und Standardteile werden uber den Teilenamen identifiziert. DieParameter von bekannten Standardteilen werden automatisch vom Systemerkannt und in das Rechenmodell ubertragen. Die Parameter der ubrigenTeile mussen durch den Benutzer im Geometriemodell identifiziert werden.Wenn ein Parameter im Geometriemodell als eigenstandiger Parameter vor-handen ist, hat der Benutzer die Moglichkeit, diesen direkt zu auszuwahlen.

124


Bild 6.13: Dialog zum Verknupfen der Modelle

Anderenfalls wird der Wert des Parameters aus einer geometrischen Rela-tion eines oder mehrerer geometrischer Objekte bestimmt. In diesem Fallmuß der Benutzer die entsprechenden Objekte auswahlen. Bild 6.14 zeigtdie Auswahlmoglichkeiten fur den Parameter “Plattenhohe” der Kompo-nente “Oberplatte” und die zugehorige Darstellung im CAD–System. DerWert kann durch den Abstand zweier Flachen, die Lange einer Kante oderdirekt durch einen Parameter (“DIMENSION”) bestimmt werden. Die di-rekte Verknupfung von Parametern hat den Vorteil, daß der Wert durchden ModellManager geandert werden kann.

Bild 6.14: Dialog zum Verknupfen der Parameter

125


Am Ende dieses Schrittes ist das Strukturmodell in einer gultigen Konfigu-ration mit dem Geometriemodell verknupft.

5. Berechnung. Durch Anwahlen des “Berechnen” Feldes wird aus der ak-tuellen Konfiguration ein Berechnungsdatensatz erstellt. Dafur werden dieBedingungen und Relationen fur die Erstellung der Berechnungsparameterausgewertet. Die Ergebnisse der Berechnung werden in der Ergebnistabel-le dargestellt. Werte die sich seit der letzten Berechnung geandert haben,sind durch einen Stern gekennzeichnet. Parameterwerte, die nicht vom Be-nutzer eingegeben werden und vom Berechnungsprogramm ermittelt wur-den, werden ebenfalls in das Strukturmodell ubertragen und gegebenenfallsals geandert markiert. Bild 6.15 zeigt das Parameterfenster und das Er-gebnisfenster nach der Berechnung. Die Detaildaten der Schraubengeome-trie, Flankendurchmesser und Kerndurchmesser wurden fur den gewahltenNenndurchmesser durch BOLT ermittelt. Optional kann die von BOLTerzeugte Ergebnisdatei durch Anwahlen des Bedienfeldes angezeigt werden(vergleiche Bild 6.6 auf Seite 116). Diese Option ist hilfreich, wenn dieBerechnung wegen fehlerhafter Eingabeparameter abgebrochen wurde. Indiesem Fall enthalt die Ergebnisdatei aussagefahige Fehlermeldungen.

Bild 6.15: Parameterfenster der Schraube und Ergebnisfenster nach der Berech-nung

6. Variation des Rechenmodells. Die Parameter des Strukturmodells kon-nen durch den Benutzer verandert werden. Im Modellmanager stehen fur

126


einige Parameter Listen mit vordefinierten Eintragen zur Verfugung. Beiden meisten anderen Parameter sind Gultigkeitsbereiche vordefiniert, dieuber automatisch aufklappende Informationsfenster angezeigt werden (sieheBild 6.16). Durch Andern von Parametern ist das Strukturmodell zunachstinkonsistent mit den Partialmodellen. Fur die Aktualisierung der Partialm-odelle stehen in der Menuleiste entsprechende Felder zur Verfugung.

912

M4..M39

938931912

Bild 6.16: Vordefinierte Optionen und Gultigkeitsbereiche der Parameter

7. Variation des Geometriemodells. Das Geometriemodell kann durchErsetzen von Normteilen und durch Verandern von Parameterwerten mo-difiziert werden. Wird in der Menuleiste das Feld “Ersetzen eines Bauteils”gewahlt, erscheint, sofern es sich um ein Teil aus einer Teilefamilie handelt,eine Liste der weiteren in dieser Familie verfugbaren Teile. Durch Auswah-len einer Variante wird das Bauteil im Geometriemodell ersetzt und die ge-anderten Parameter werden automatisch in Strukturmodell ubernommen.Nicht standardisierte Komponenten konnen durch Setzen der Parametergeandert werden. Durch Wahlen des Bedienfeldes wird versucht, alle Geo-metrieparameter des Strukturmodells im Geometriemodell nachzufuhren.Dies ist nur moglich wenn die Parameter zuvor direkt verknupft wurden.Im gezeigten Beispiel wurde der Außendurchmesser des verspannten Kor-pers durch den Abstand zweier Flachen definiert und kann daher nicht imGeometriemodell nachgefuhrt werden. Die betroffenen Parameter werdenim Strukturmodell entweder mit einem Stern als geandert oder mit einem“M” als nicht anderbar gekennzeichnet (siehe Bild 6.17).

8. Abschluß der Berechnung. Auf Wunsch wird dem Benutzer die Er-gebnisdatei von BOLT ubermittelt. Die Anderungen im Geometriemodellbleiben erhalten und werden zusammen mit dem Modell gespeichert.

127


Bild 6.17: Parametertabelle nach Aktualisierung des Geometriemodells

6.6 Variationsmoglichkeiten

In der implementierten Version des ModellManagers sind die Bedingungen undRelationen der berechenbaren Modelle als Programmcode implementiert. Da-durch ist eine sehr spezielle, auf genau die beiden verwendeten Programme ab-gestimmte Losung entstanden. Die Implementierung ist aber so gestaltet, daßder Programmteil fur die Verwaltung und die Darstellung der Modelle unabhan-gig ist von dem Teil, der fur den Modellaufbau verantwortlich ist. Ersetzt manden Programmteil fur den Modellaufbau, laßt sich der ModellManager auch aufandere Berechnungssysteme anpassen. Folgende Varianten sind hier vorstellbar:

Scripte fur Modellschemata. Eine flexible Losung ergibt sich, wenn die Infor-mationen zur Verknupfung der Modelle in Scripten gespeichert werden. DerModellManager mußte dann um einen Parser fur die gewahlte Scriptspracheerweitert werden. Die Scripte wurden vom Anbieter der Berechnungsme-thoden zur Verfugung gestellt werden.

Scripte mit Formeln. Oft sind fur die Verknupfung von Parametern zusatzlichmathematische Rechenoperationen erforderlich. Die Bearbeitung einer ineinem Script gespeicherten Formel zur Laufzeit erfordert eine zusatzlicheSoftwarekomponente. Die Werte der in Formel gespeicherten Parametermussen ermittelt und entsprechend der angegebenen Rechenoperationenverknupft werden. Eine Implementierung eines solchen Programms wird in[Wol98] als Solver bezeichnet. In dem dort beschriebenen System ermog-licht der Solver die Berechnung von mathematischen Formeln und uber-wacht modellubergreifend bestehende Bedingungen zwischen den Parame-tern. Steht in einem System ein hinreichend leistungsfahiger Solver zurVerfugung, konnen auch vollstandige Berechnungsalgorithmen als Scripteubertragen werden. In diesem Fall kann der Anwender die Berechnungsme-thode in allen Teilen seinen Bedurfnissen anpassen.

Portable Programme. Methoden, die aus komplexen Algorithmen bestehen, kon-nen auch mit Hilfe von JAVA-Applets in den lokalen Speicher geladen wer-den. Durch den standardisierten Zugriff uber die CORBA Schnittstelle

128

6.7 Bewertung des Losungsansatzes

kann das Applet direkt mit dem Geometriemodell arbeiten. Die Platt-formunabhangigkeit von JAVA ermoglicht dabei die Portabilitat sowohl desProgrammcodes als auch der Benutzungsoberflache. Eine Variation des Pro-gramms zur Laufzeit ist bei JAVA-Applets nicht moglich. Dennoch konnenzur Laufzeit Programmkomponenten, auch von verschiedenen Servern nach-geladen werden. Auf diese Weise ließen sich Methoden mit Komponentenaus verschiedenen Servern zusammensetzen.

Geometrieobjekte im Berechnungsserver. Wenn der Berechnungsserver so er-weitert wird, daß er direkt mit den Geometrieobjekten arbeiten kann, ent-fallen sowohl die Scripte als auch die portablen Programme. Diese Strukturist insbesondere dann von Bedeutung, wenn die Methode nicht dem Anwen-der uberlassen werden soll.


In diesem Abschnitt wird das Integrationssystem in bezug auf die in Kapitel 4gestellten Anforderungen bewertet. Eine Ubersicht in Tabelle 6.1 zeigt, welcheForderungen erfullt wurden, welche bedingt erfullt wurden, welche prinzipiell mitCORBA erfullbar waren, aber nicht umgesetzt wurden und welche nicht erfullbarsind.

6.7.1 Kopplung der Modelle

Ein durchgangiges Produktmodell fur die rechnerunterstutzte Produktentwick-lung, das von den betrachteten Programmen unterstutzt wird, existiert zur Zeitnicht. Daher wurde in einem externen Clientprogramm ein Strukturmodell im-plementiert, das die Objekte aus dem CAD–System und dem Berechnungssystemzu einem integrierten Modell zusammenfugt.Das Zusammenfugen der Objekte und das Zusammenstellen der Verknupfungs-informationen waren sehr umfangreiche Arbeitsschritte. Durch die bei CORBAverwendete Kapselung der Schnittstelle wurden diese Arbeitsschritte wesentlichvereinfacht. Mit der Formulierung einer Schnittstellenbeschreibung in IDL kon-nen die Programmiersprache und die eigentliche Struktur einer Programmier-schnittstelle verdeckt werden. Dadurch konnen auch Objekte aus verschiedenenApplikationen in einer Client–Anwendung zusammengefugt werden. Durch dieDefinition von Oberklassen fur systemweit gultige Objekte laßt sich das Ver-halten von Objekten vereinheitlichen. Beispielsweise konnen Methoden fur denAufruf und die Beendigung von Applikationen, definiert werden.Aus der doppelten Datenhaltung bei der Kapselung der Applikationen entstehenNachteile durch erhohten Speicherplatzbedarf und die Gefahr von Inkonsistenzen.Außerdem verursachen Methodenaufrufe uber CORBA hohere Laufzeiten als bei-spielsweise Remote Procedure Calls, da die Aufrufe von der CORBA–Umgebung

129


Forderungerfüllt

Forderungbedingt erfüllt

Forderung nicht erf.prinzipiell erfüllbar

Forderung nicht erfüllbar

Kopplung Geometriemodell mitParametermodell

Identifizierung von Norm- undStandardteilen

verschiedene Modellkonfigurationen

direkte Kopplung

Nutzung vorhandener Programmier-schnittstellen

Plattform AIX

andere Plattformen integrierbar

CAD-Schnittstelle in C

Berechnungsschnittstelle in FORTRAN

synchrone Anwendung der Programme

Geometrieanalysen

Geometrievariation

Geometrieerzeugung

Visualisierung der Verknüpfungen

Sicherheit gegen unberechtigen Zugriff

Sicherheit der Datenübertragung

Zugriffskontrolle

Benutzung durch einen Anwender

Benutzung durch mehrere Anwender

Auslegung, Nachrechnung, Optimierung

Programme

Modelle Prozesse

Geometrie als Haupt-Arbeitsmodell

Berechnung als Werkzeug beim Gestalten

Kopplung von Methoden über das Intranet

Kopplung von Methoden über das Internet

Visualisierung der Arbeitsmodelle in den Appl.

kein zusätzliches IT-Know-How erforderlich

Tabelle 6.1: Erfullbarkeit der gestellten Anforderungen

abgefangen und an den Empfanger weitergeleitet werden. Serverseitig kann eszu hoheren Laufzeiten kommen, wenn aufgrund unterschiedlicher Semantik desinternen Modells und der verwendeten Schnittstellenbeschreibung komplexe Da-tenstrukturen analysiert und neu aufgebaut werden mussen.

6.7.2 Kopplung der Programme

Mit der realisierten Kopplung uber einen zusatzlichen Client konnte die Forde-rung nach einer direkten Kopplung nicht erfullt werden. Dennoch konnte eineplattformubergreifende Integration realisiert werden.Voraussetzung fur eine Integration eines Servers ist das Vorhandensein einerCORBA–Laufzeitumgebung und die entsprechende Bibliothek mit den Schnitt-stellenimplementierungen. Fur die Erstellung der Bibliotheken werden sogenann-te Emitter, benotigt, die aus den Schnittstellenbeschreibungen die Methoden-rumpfe in der Programmiersprache der zu kapselnden Applikation erzeugen. Mitden bestehenden Emittern fur C, C++, Smalltalk und Java laßt sich ein großerTeil der existierenden Softwaresysteme integrieren. Wie im obigen Beispiel ge-zeigt, laßt sich auch vorhandener FORTRAN Code in das System einbinden.Client–seitig werden neben der CORBA-Laufzeitumgebung die Deklarationen furdie Umsetzung der Methodenaufrufe in die entsprechenden CORBA–Aufrufe be-

130


notigt. Diese Deklarationen werden, ahnlich wie bei den Servern, uber entspre-chende Emitter generiert.

Die Verwendung von Java-Clients macht auch die client–seitige CORBA–Lauf-zeitumgebung uberflussig, da diese zusammen mit dem eigentlichen Applet uberdas Netzwerk bezogen werden kann. Damit wird auf dem Client–Rechner lediglicheine Java–Umgebung (Virtual Machine) benotigt.

Die in der oben beschriebenen Implementierung benotigten Softwarekomponentensind in Bild 6.18 dargestellt. Dabei werden plattformgebundene und portableBibliotheken unterschieden.

plattformabhängige Bibliotheken portable Bibliotheken (Java)

CORBA-Laufzeitumgebung

JAVA Virtual Machine

CAD-Stubs

CAE-Stubs

ModellBrowser

O R B

CAE

Client

CAE-Server DLL

CORBA - Laufzeitumg.CAD-Server DLL

CORBA - Laufzeitumg.CAD

(TCP / IP)

externe Anwendungenlokale Anwendungen

Bild 6.18: Erforderliche Softwarekomponenten fur eine einfache Kopplung der Sy-steme

Die in Kapitel 4 geforderte Netzwerkfahigkeit ist mit CORBA gegeben. CORBAObjekte sind netzwerktransparent. Ein Client–Programm kann auf diese Wei-se ein Objekt eines anderen Servers verwenden, als ware es lokal im Speichervorhanden. Daruber hinaus werden als Bestandteil der CORBA–Umgebung Ver-zeichnisse der von den verschiedenen Servern zur Verfugung gestellten Objektegehalten, sodaß sich der Anwender nicht um die tatsachliche Lokalisierung vonProgrammkomponenten kummern muß. Er kann Objekte eines anderen Serversdurch eine Anfrage an die CORBA–Umgebung erhalten. Die CORBA–Umgebungermittelt aus dem entsprechenden Verzeichnis die Lokalisierung des Objekts, ak-tiviert es, und ubergibt dem Client eine Referenz auf das Objekt, mit der derClient direkt arbeiten kann.

131


6.7.3 Kopplung der Prozesse

In der Clientanwendung konnen Berechnungssystem und Gestaltungssystem voneiner einzigen Oberflache aus bedient werden. Damit ist auch eine prozeßtechni-sche Kopplung realisiert. Die Funktionalitat und die Benutzungsoberflache sindabgestimmt auf die Anforderungen der integrierten Berechnung und laufen paral-lel zu den bereits bestehenden Systemen. Die Verwendung eines Berechnungssy-stems als Werkzeug in der Arbeitsumgebung des Geometriemodellierers ist damitnicht gegeben. Dafur mußte ein systemubergreifendes Prozeßmodell definiert undin beiden Systemen implementiert werden.

Auch hier sorgt der Mechanismus der Kapselung dafur, daß die Systeme zusam-mengefuhrt werden konnen. In der Client–Anwendung konnen Funktionsaufrufean Objekte, die aus verschiedenen Servern stammen, gesendet werden. Daruberhinaus ermoglicht der Life Cycle Service die Erzeugung von Objekten, unabhan-gig von der Art und der Lokalisierung der zugehorigen Server.

Zusammenfassend sind in Bild 6.19 die Anforderungen dargestellt, die bei derVerwendung von CORBA automatisch erfullt sind, oder deren Erfullung durchCORBA unterstutzt wird (vergleiche Bild 4.1 auf Seite 80). Aus dem Bild wirddeutlich, daß mit Hilfe von CORBA eine plattformubergreifende und netzwer-kubergreifende Kopplung moglich ist. Die weiteren Bereiche modelltechnischeKopplung und prozeßtechnische Kopplung werden zwar durch CORBA unter-stutzt, sind aber nicht automatisch bei der Verwendung von CORBA als Integra-tionsplattform realisiert.

Plattform

MethodenObjekte

Netzadresse NetzadresseCAD CAE

ModellObjekte

Methoden

Plattform

Prozeß

Kopplung realisiert Kopplung wird unterstützt

Modellsicht Modellsicht

Speicherung SpeicherungSystemEingangsgrößenErgebnisseAktivitäten

EingangsgrößenErgebnisseAktivitäten

Bild 6.19: Anforderungen, die bei Verwendung von CORBA erfullt werden kon-nen

132

6.8 Zusammenfassung

6.8 Zusammenfassung

Das beschriebene Integrationssystem zeigt exemplarisch eine mogliche Form einerCORBA-basierten Kopplung eines parametrischen CAD–Systems und eines para-meterorientierten Berechnungsprogramms. Das CAD–System Pro/ENGINEERund das Berechnungsprogramm BOLT wurden uber objektorientierte Schnitt-stellen gekapselt und in eine CORBA Umgebung eingebunden. Die Struktur derSchnittstellen spiegelt dabei einen Auschnitt aus dem internen Modell der jewei-ligen Applikation wider. Die Verknupfung der Modelle erfolgt in einem separatenClient.Die Bewertung des Ansatzes zeigt, daß die Forderungen nach Netzwerkfahigkeitund Plattformunabhangigkeit erfullt sind.Fur die modelltechnische und die prozeßtechnische Kopplung waren zusatzlicheInformationen erforderlich, die im Client enthalten sind. In einem im Client im-plementierten Strukturmodell fur integrierte Berechnungen werden die Objekteaus den beiden Applikationen und die Verknupfungen zwischen den Objektenabgebildet. Fur die prozeßtechnische Kopplung wurden einige der in den Appli-kationen verfugbaren Funktionen im Client abgebildet.Herauszustellen ist die Flexibiltat im Zugriff auf die internen Modelle, die sichdurch die Kapselung der Applikationen ergibt. Im gezeigten Beispiel werden diein C und FORTRAN implementierten Applikationschnittstellen in einer JAVA–Applikation miteinander verknupft und Objekte aus beiden Applikationen paral-lel verwendet. Der Ansatz ist damit geeignet, bestehende Programme als Server inmoderne, objektorientierte Softwaresysteme zu integrieren, sofern eine CORBA–Laufzeitumgebung fur die Serverplattform existiert und die Programme mit ei-ner von CORBA unterstutzten Programmiersprache zusammengebunden werdenkonnen.

133


134

7 Ausblick


Mit dem implementierten Integrationssystem wurde nachgewiesen, daß mit COR-BA eine Kopplung bestehender Softwaresysteme realisierbar ist. Die Technik,Applikationen uber neutrale Schnittstellenbeschreibungen zu kapseln, ermoglich-te dabei auch die Zusammenfuhrung zweier in bezug auf die Datenstrukturen,den Programmablauf und die Zugriffsmethoden auf die Modelle unterschiedli-cher Systeme. Daruberhinaus ist es durch die Plattformunabhangigkeit und dieNetzwerkfahigkeit von CORBA moglich, die auf verschiedenen Rechnern mit un-terschiedlichen Betriebssystemen laufenden Programme zu koppeln. Die Mog-lichkeit, auch FORTRAN–Programme zu integrieren, macht CORBA zu einemgeeigneten Werkzeug, eine große Zahl bestehender Berechnungsprogramme in ei-ne moderene Systemumgebung zu integrieren.

Die wesentlichen Probleme der Integration lagen in der modelltechnischen Kopp-lung der Systeme. Die Schaffung eines einheitlichen, integrierten Produktmodellsist hierfur unumganglich. Dabei steht der Ansatz der OMG, die STEP als Pro-duktmodell fur CAx–Anwendungen einsetzen will, im Konflikt mit den Interes-sen der CAD–System Hersteller, die bisher auf proprietare Datenformate setzen.Fur die Integration von Berechnungen muß das Produktmodell auch nichtgeome-trische Daten enthalten konnen. Der umfassende Ansatz von STEP, samtlicheproduktbezogenen Daten abbilden zu konnen, ist dafur eine gute Grundlage.

Durch die Kopplung von CORBA und JAVA ergeben sich interessante Moglichkei-ten fur die Bereitstellung von Berechnungsmethoden uber das Internet. Von Be-rechnungsdienstleistern angebotene Methoden konnen uber das Internet geladenwerden und erhalten uber die lokale CORBA–Umgebung Zugriff auf das lokaleCAD–System. Dabei kann das JAVA–Applet das vollstandige Berechnungspro-gramm enthalten oder es kann die Dienste eines entfernt laufenden, uber CORBAgekapselten Berechnungsservers in Anspruch nehmen. Voraussetzung fur diesesSzenario sind eine in IDL formulierte, uber CORBA zugangliche Schnittstelledes CAD–Systems und eine lokale CORBA–Laufzeitumgebung. Die Schaffungeiner CORBA–konformen Schnittstelle durch die CAD–System–Hersteller waresomit die Basis fur eine netzwerkubergreifende Integration von Gestaltung undBerechnung.

135

7 Ausblick

7.2 Vernetzte Berechnungs–Competence–Center

Auf der Basis des oben beschriebenen Integrationssystems kann ein System ver-netzter Berechnungs–Competence–Center fur verschiedene Berechnungsaufgabenaufgebaut werden. Das System besteht aus einem in eine CORBA–Umgebung in-tegrierten CAD-System und einer Reihe von Servern, auf denen spezialisierte Be-rechnungsmethoden bereitgestellt werden. Die Methoden werden als Werkzeugebei der Durchfuhrung der aktuellen Konstruktionsaufgabe eingesetzt und arbei-ten mit dem lokalen Geometriemodell. Dabei konnen die Berechnungsprogrammedie Parameter aus dem Geometriemodell ableiten oder das Geometriemodell va-riieren, erfordern aber selber kein persistentes Produktmodell. Nicht automatischreproduzierbare Verknupfungen und Benutzereingaben werden als Attribute demGeometriemodell zugefugt oder als Datei zusammen mit dem Geometriemodellgespeichert.

�� !�"$# % &

')( *,+�- .

/1032 0�4�5�6�7�6�8�9�:;�<37�=�<�9�> 0$6

?�@$A�B C�DE F�G H I�JK�L M$N�O�P

QSR�T�U V

WYX[Z

\ ]�^ _$` acb�d e _$]�f�gh ]�ij�_$k h gaml�]�d b�d e _$]�f�gf�n�f�d l�a

o�prq s$t�uv t�w�x�y�z�y�{�|u}�v ~ { v ��

��3��$��

�� ,��

�¡ £¢¡¤,¥¦¨§�© ª¬« 1§¬®

¯±°³² ´ °³µ¶°·¹¸³º�» °�´ °³¼�½3° · °³¼1´ °³µ

¾À¿YÁÀÂÄÃ

Bild 7.1: Einbindung eines Berechnungs–Competence–Centers in eine Netz-werkumgebung

Berechnungs–Competence–Center sind in diesem Szenario Anbieter von Berech-nungsdienstleistungen und konnen sowohl innerhalb eines Unternehmens als auchdurch externe Dienstleister aufgebaut werden. Dabei konnen entsprechend denErfordernissen Applikationen verknupft, einzelne Parameter oder vollstandige

136

7.3 Komponentenbasierte CAx–Systeme

Modelle ubertragen werden. Zur problemspezifischen Anpassung der Berech-nungprgramme steht ein allgemeiner Methodenbaukasten zur Verfugung.

Entscheidend fur den Nutzen eines Berechnungs–Competence–Centers ist die Be-reitstellung von zusatzlichen Informationen uber die Berechnungsmethoden, dieeine qualifizierte Anwendung der Methoden ermoglichen. Je weniger der Anwen-der mit den Methoden des Anbieters vertraut ist, desto umfassender mussen diezusatzlichen Informationen sein. Insbesondere bei der Bereitstellung von Metho-den durch externe Anbieter ist die Qualifizierung und Unterstutzung der Anwen-der eine ernstzunehmende Aufgabe. Vorstellbar sind hier Schulungen durch dieAnbieter, die den Kunden mit den speziellen Eigenschaften einer Methode ver-traut machen und auch ein Vertrauensverhaltnis zwischen Anbieter und Anwen-der schaffen, oder auch Call-Center, in denen Experten fur Fragen zu bestimmtenMethoden zur Verfugung stehen. Stehen die zusatzlichen Informationen wederals Onlinehilfe noch in Form einer personlichen Beratung zur Verfugung, ist einesinnvolle Anwendung eigentlich nur fur einfache, allgemein bekannte Methodenmoglich.

Durch die Verwendung von uber IDL gekapselten Applikationen und CORBAals Kommunikationssystem wird die Verknupfung der Modelle wesentlich ver-einfacht. Die Schaffung einer standardisierten Zugriffsschnittstelle ermoglicht esden Entwicklern von Berechnungssoftware, Programme zu entwickeln, die mit al-len Geometriemodellierern arbeiten. Entsprechend ermoglicht die Kapselung vonBerechnungssoftware auch die Integration bestehender Programme, indem auchhier die Zugriffsmethoden, die Metadaten und die Strukturierung der Modellevereinheitlicht werden. Insbesondere im Hinblick auf eine Prozeßplanung undProzeßprotokollierung ist eine einheitliche Darstellung der Methoden von Vorteil.

Daruber hinaus stehen durch die Basisdienste von CORBA eine Infrastruktur furdie Lokalisierung, fur den Transport und fur eine netzwerktransparente Verwen-dung von Objekten, sowie standardisierte Sicherheitsmechanismen zur Verfugung.

7.3 Komponentenbasierte CAx–Systeme

Im Sinne der Objekttechnologie sollte sich ein Produktmodell aus beweglichen,plattform- und softwareumgebungsunabhangigen Softwarekomponenten zusam-mensetzen lassen. Entgegen dem bisherigen Entwicklungstrend, moglichst vieleInhalte in einem Softwaresystem abzubilden, mußten dann die Inhalte wiederauf verschiedene Modelle und damit auf verschiedene Applikationen verteilt wer-den. Allgemeine, in der Produktentwicklung benotigte Objekte und Methodenmußten in einer Klassenstruktur vorgegeben werden. Diese allgemeinen Objektemußten Methoden zum Speichern und zum Verknupfen untereinander enthaltenund uber Netzwerke transportierbar sein. Durch branchen- oder problemspezifi-sche Erweiterungen konnen diese allgemeinen Objekte an jeden Anwendungsfallangepaßt werden, sind aber dennoch in das Gesamtsystem integrierbar, da sie

137

7 Ausblick

die Eigenschaften der Basiselemente geerbt haben. Denkbare Komponenten sindFertigungspartialmodelle, Anforderungsmodelle, Geometriemodelle oder Stuckli-stenmodelle.Bei der Schaffung einer komponentenbasierten CAx–Umgebung ist die Defini-tion der Basiselemente, deren Gemeinsamkeiten und deren Wechselbeziehungeneine der herausragenden Aufgaben. Das Datenmodell von STEP kann hier alsGrundlage dienen.Eine weitere wichtige Aufgabe ist die Schaffung von Speichermechanismen fur dieeinheitliche Speicherung der Partialmodelle, ohne die wirklich portable Objektenicht denkbar sind. Alleine die Speicherung parametrischer Geometriemodelle ineinem neutralen Format ist eine bisher nicht geloste Aufgabe.Voraussetzung fur den Erfolg eines solchen Systems ist allerdings, daß die besteh-tenden Systeme sich in eine solche Umgebung integrieren lassen und die allgemeindefinierten Objekte und Methoden in ihren Schnittstellen anbieten. Um bei einergleichen Grundfunktionalitat der Systeme dennoch die Abgrenzung untereinan-der zu ermoglichen, mussen allgemeine Objekte und Methoden definiert werden,die um die systemspezifischen Merkmale erweitert werden konnen.

138

Glossar

Applikation Ein Softwareprogramm zur Bearbeitung einer Aufgabe.

Client Eine Softwarekomponente, die die Dienste einer anderen Softwarekom-ponente in Anspruch nimmt, entweder durch einen Funktionsaufruf oderdurch einen Zugriff auf ihren Status [Boo94].

Emitter Ein Softwareprogramm, das aus einer neutralen Schnittstellenbeschrei-bung Methodenrumpfe in einer bestimmten Programmiersprache generiert[OHE96].

Ersatzmodell Abstraktion eines realen oder geplanten Produkts durch Redukti-on auf eine Auswahl von Eigenschaften. Ein Ersatzmodell wird verwendet,um das Verhalten des Produkts durch Vereinfachung berechenbar und da-mit vorhersagbar zu machen.

Framework (Auch: Umgebung) Eine Ansammlung von Klassen, die eine be-stimmte Menge von Diensten fur einen bestimmten Bereich zur Verfugungstellen. Ein Framework exportiert einzelne Klassen und Mechanismen, diedie Clients einsetzen oder ubernehmen konnen [Boo94].

Geometriemodell Hier: Rechnerinterne Darstellung der Geometriedaten in ei-nem Geometriemodellier (CAD–System).

Integriertes Produktmodell Produktmodell fur die Abbildung von Daten ausallen Produktlebensphasen in einem einheitlichen Datenmodell [GAP93].Ein kontinuierliches Fortschreiben der Daten soll die informationsverlust-behaftete Modelltransformation verhindern. In dem Modell werden alleDaten abgebildet, die sich nicht aus bereits bestehenden Daten ableitenlassen [Vel99].

Methode Hier: ein auf einem Computer implementiertes Programm zur Durch-fuhrung von Berechnungen.

Persistenz Die Eigenschaft eines Objekts, mit deren Hilfe es Zeit uberdauernkann [Boo94].

139

Glossar

Modell Abstrakte Abbildung eines Ausschnittes der realen Welt mit dem Ziel,von Eigenschaften des Modells auf Eigenschaften des realen Objekts zuschließen [VDI93] [Rot82]. Im Kontext von Softwareprogrammen: als Da-tenmodell strukturelle Datenmenge zur rechnerinternen Reprasentation ei-nes Weltausschnittes [Abe95].

Partialmodell Kennzeichnet eine definierte endliche Informationsmenge von Pro-duktmerkmalen als Teil eines Produktmodells [Abe95] [Gra99].

Produktinformationsmodell Auch: konzeptionelles Modell Definiert die mogli-chen Bestandteile und denkbaren Relationen zwischen den Bestandteilenfur eine Abbildung eines Modells im Rechner [Boo94].

Produktmodell Die Einheit von Produktinformationsmodell und aller zu einemProdukt gehorenden Daten [Abe95].

Rechenmodell Hier: Rechnerinterne Darstellung der Daten eines Berechnungs-programms.

Server Eine Softwarekomponente, die anderen Softwarekomponenten Daten oderDienste zur Verfugung stellt.

Strukturmodell Hier: Produktinformationsmodell fur die Integration von Ge-staltung und Berechnung. Enthalt Ausschnitte aus einem Geometriemodellund einem Rechenmodell und die fur die Verknupfung der Modelle erfor-derlichen Informationen.

140

Literaturverzeichnis

[Abe95] Abeln, Olaf (Hrsg.): CAD-Referenzmodell . Stuttgart : B. G. Teubner,1995

[Abe97] Abeln, Olaf (Hrsg.): Innovationspotentiale in der Produktentwick-lung . Stuttgart : B.G. Teubner, 1997

[AGL98] Abramovici, M. ; Gerhard, D. ; Langenberg, L.: Unterstutzungverteilter Entwicklungsprozesse durch EDM/PDM. In: Prozeßket-ten fur die virtuelle Produktentwicklung in verteilter Umgebung (siehe[VDI98]), S. 69–86

[AJSK98] Arnold, F. ; Janocha, A. ; Swienczeck, B. ; Kilb, T.: Die CAx-Integrationsarchitektur ANICA und ihre erste Umsetzung in die Praxis.In: Integration heterogener Softwaresysteme (IHS’98) im Rahmen der28. GI-Jahrestagung Informatik ’98 . Magdeburg, 1998, S. 43–54

[AK98] Arnold, F. ; Kilb, T.: Data Management in distributed CAx Sy-stems. In: Anderl, R. (Hrsg.) ; Trippner, D. (Hrsg.): ProSTEPScience Days ’98, Product Data Technolgy - Facing the Future. Wup-pertal, 1998, S. 94–105

[And96] Andreasen, M.: The Nature of Design Features. In: Meerkamm,H. (Hrsg.): 7. Symposium Fertigungsgerechtes Konstruieren Lehrstuhlfur Konstruktionstechnik, Universitat Erlangen-Nurnberg, 1996

[Bei90] Beitz, W.: Konstruktionsleitsystem als Integrationshilfe. In: VDI–Berichte Nr. 812 (1990), S. 181–201

[Bet94] Betz, Mark: Interoperable Objects. In: Dr. Dobbs Journal (1994),October, S. 18–39

[BOL94] Institut fur Maschinenkonstruktion – Konstruktionstechnik. Berlin:BOLT 4.2 Benutzerhandbuch. 1994. – TU Berlin

[Boo94] Booch, Grady: Objektorientierte Analyse und Design. Bonn, Paris :Addison-Wesley, 1994

141


[BW98] Braun, P. ; Welp, E.G.: Wissensbasierte Unterstutzung der Pro-duktentwicklung in objektorientiert gekapselten Ingenieuranwendun-gen. In: Prozeßketten fur die virtuelle Produktentwicklung in verteilterUmgebung (siehe [VDI98]), S. 429–449

[Dam96] Damblon, Werner: VDI calc Maschinenelemente. Dusseldorf: VDI,1996. – CD-Rom zur Auslegung und Berechnung

[Fel89] Feldhusen: Durchgangige und flexible Rechnerunterstutzung in derKonstruktion. In: Konstruktion 41 (1989), S. 47–56

[FR99] Fischer, Th. ; Rautert, J.: Erfolgsfaktoren im Entwicklungsprozeßbei Heidelberger Druckmaschinen. In: Verkurzte Entwicklungsprozessedurch Integration von Gestaltung und Berechnung (siehe [VDI99]), S.1–12

[Gal80] Galwelat, Michael ; Beitz, Wolfgang (Hrsg.): RechnerunterstutzteGestaltung von Schraubenverbindungen. Berlin : TU Berlin, Insti-tut fur Maschinenkonstruktion-Konstruktionstechnik, 1980 ( Nr.2). –Schriftenreihe Konstruktionstechnik

[GAP93] Grabowski, H. ; Anderl, R. ; Polly, A.: Integriertes Produktmo-dell . Berlin : Beuth Verlag, 1993

[GAS92] Grabowski, H. ; Anderl, R. ; Schmidt, M.: STEP: Die Beschrei-bung von Produktsrukturen mit dem Teilmodell PSCM. In: VDI-Z134 (1992), Nr. 3, S. 51–55

[GEP94] Grabowski, H. ; Erb, J. ; Polly, A.: STEP - Grundlage der Pro-duktdatentechnologie Aufbau und Entwicklungsmethodik. In: CIMManagement 10 (1994), Nr. 4, S. 45–51

[GJS98] Gosling, J. ; Joy, B. ; Steele, G.: The Java Language Specification,1998. – URL http://java.sun.com/docs/books/jls/html/index.html

[Gra99] Grabowski, Hans: CAD- und CAx-Software. In: Konstruktion Band51 (1999), Oktober, Nr. 10

[Hah98] Hahn, Axel ; Gausemeier, Jurgen (Hrsg.): Integrationsumge-bung fur verteilte objektorientierte Ingenieursysteme. Paderborn :Universitat-GH Paderborn, Heinz Nixdorf Institut, 1998 ( Bd. 33).– HNI-Verlagsschriftenreihe

[Har97] Hardwick, Martin: STEP Business Objects ISFAA-97 Electronic Fo-rum, 1997. – URL http://sage.wt.com.au/∼ausstep/aec-libraries/w1-reference/bizobj.html

142


[HE92] Hubka, V. ; Eder, E.: Einfuhrung in die Konstruktionswissenschaf-ten. Berlin : Springer, 1992

[HEX95] HEXAGON Industriesoftware GmbH. Kirchheim/Teck: Software zurBerechnung von hochbeanspruchten Schraubenverbindungen nach VDI2230 . 1995. – Hexagon SR1

[IBM96] IBM Corporation. Austin: SOMObjects Developer’s Toolkit: Program-mers Guide. Second Edition. 1996

[ISO94] ISO10303: Industrial Automation Systems and Integration - ProductData Representation and Exchange. Genf : International Organiza-tion for Standardization, 1994 ( Part 1: Overview and FundamentalPrinciples). – ISO-Norm

[iVi99] iViP: Leitprojekt integrierte Virtuelle Produktentstehung. Berlin :Bundesministerium fur Bildung und Forschung, 1999. – Prospekt

[iVi00] iViP, Projekt: Integrierte Virtuelle Produktentstehung, 2000. – URLhttp://www.ivip.de

[Kum99] Kummlee, H.: Moglichkeiten und Grenzen des Einsatzes modernerEDV-Verfahren großer elektrischer Grenzleistungsmaschinen. In: Ver-kurzte Entwicklungsprozesse durch Integration von Gestaltung und Be-rechnung (siehe [VDI99]), S. 177–202

[KMM99] Kellner, P. ; Meißner, M. ; Muller, A.: Integration von CAx-Produktstrukturen - PDM-Systemen als Vorbereitung fur virtuelle Pro-duktentwicklung. In: Verkurzte Entwicklungsprozesse durch Integrati-on von Gestaltung und Berechnung (siehe [VDI99]), S. 31–46

[Kol98] Koller, Rudolf: Konstruktionslehre fur den Maschinenbau. 4. Auf-lage. Berlin, Heidelberg : Springer, 1998

[KOM96] KOMFORCE Arbeitskreis: Integrierter Entwicklungsarbeitsplatz.Paderborn : Kommunikations– und Forschungskreis fur Informations-technologien in Computer Aided Design und Engineering, 1996. – Re-ferenzpapier

[KTA98] Krause, F.-L. ; Tang, T. ; Ahle, U.: Virtuelle Produktentstehung.In: Prozeßketten fur die virtuelle Produktentwicklung in verteilter Um-gebung (siehe [VDI98]), S. 1–12

[Lof97] Loffel, Christoph: Integration von Berechnungswerkzeugen in denrechnerunterstutzten Konstruktionsprozeß . Erlangen, Lehrstuhl furKonstruktionstechnik. Universitat Erlangen–Nurnberg, Dissertation,1997

143


[LG99] Loffel, Chr. ; Goldbach, H.: Auf dem Weg zum virtuellen Pro-dukt durch intgrierte Berechnungsmethoden. In: Verkurzte Entwick-lungsprozesse durch Integration von Gestaltung und Berechnung (siehe[VDI99]), S. 123–138

[Lov97] Loviscach, Dr. J.: Paßgenau - Mit Komponenten zur personlichenSoftware. In: c’t (1997), Nr. Heft 3, S. 224–228

[McF98] McFall, Cynthia: An Object Infrastructure for Internet Middleware.In: IEEE Internet Computing (1998), Marz April, S. 46–51

[Mee98] Meerkamm, Harald: Integrierte Produktentwicklung. In: Konstruk-tion Band 50 (1998), September, Nr. 9

[Mer98] Mertens, H.: Aussagegute und Zeitaufwand - Kriterien zur Auswahlvon Berechnungsmethoden im Konstruktionsprozeß. In: VDI BerichteNr. 1442 VDI, Verein Deutscher Ingenieure, 1998

[MW99] Mertens, H. ; Wolfle, F.: Kooperation verteilter, dezentralerKonstruktions– und Berechnungsarbeitsplatze. In: Pahl, G. (Hrsg.):Gedenkschrift Wolfgang Beitz , Springer, 1999

[Nel99] Nell, Jim: STEP on a Page / National Institute of Stan-dards and Technology. 1999. – ISO 10303 Editing Committeehttp://www.nist.gov/sc5/soap

[N.N99] N.N.: Berliner Kreis Kompetenz Netzwerk. In: http://www.bkkn.de(1999)

[OH97] Orfali, Robert ; Harkey, Dan: Client/Server Programming withJAVA and CORBA. New York : Wiley, 1997

[OHE96] Orfali, Robert ; Harkey, Dan ; Edwards, Jeri: The EssentialDistributed Objects Survival Guide. New York : John Wiley & Sons,Inc., 1996

[OMG95] OMG: Common Facilities Architecture. 4. Revision. 1995

[OMG98] OMG: PDM Enablers. Revised Submission. 98. – mfg/98-01-01

[Ope91] Open Software Foundation (Hrsg.): Guide to OSF/1 . Sebastopol: O’Reilly Associates, Inc., 1991

[Ope93] Open Software Foundation (Hrsg.): OSF DCE Application De-velopment Guide. Revision 1.0. New Jersey : Prentice Hall, 1993

[Par97] Parametric Technolgy Corporation: Pro/TOOLKIT User’s Guide. Re-lease 18. 1997

144


[PB97] Pahl, G. ; Beitz, W.: Konstruktionslehre. 4. Auflage. Berlin :Springer, 1997

[Pot95] Potthast, A.: Datenaustausch zwischen STEP und ACIS. In: CAD-CAM Report (1995), Nr. 3

[Ruc97] Ruckert, Carsten: Untersuchungen zur Konstruktionsmethodik –Ausbildung und Anwendung . Dusseldorf : VDI Verlag, 1997 ( Reihe1 Nr.293). – VDI Fortschr.-Ber.

[Red96] Redlich, Jens-Peter: CORBA 2.0 . Bonn, Reading, Mass., MenloPark, California : Addison-Wesley, 1996

[Rie94] Rieger, Erik: Semantikorientierte Features zur kontinuierlichen Un-terstutzung der Produktgestaltung . Munchen : Hanser, 1994 (Produk-tionstechnik - Berlin 158)

[Rot82] Roth, K.: Konstruieren mit Konstruktionskatalogen. Berlin : Sprin-ger, 1982

[SAKJ98] Swienczek, B. ; Arnold, F. ; Kilb, Th. ; Janocha, A.: Online–Kopplung von CAx-Systemen fur die virtuelle Produktentwicklung –ein Vergleich mit dem dateibasierten Datenaustauch. In: VDI-BerichteNr. 1435 VDI, Verein Deutscher Ingenieure, 1998, S. 219–238

[Sch88] Scholz, B.: CIM-Schnittstellenkonzepte, Standards und Probleme derVerknupfungen von Systemkomponenten der rechnerintergrierten Pro-duktion. Munchen : Oldenbourg, 1988

[Sch91] Schwenke, Hendrick ; Beitz, Wolfgang (Hrsg.): Konstruktionswis-sen in CAD–Anwenderprozeduren. Berlin : TU Berlin, Institut furMaschinenkonstruktion-Konstruktionstechnik, 1991 ( Nr.21). – Schrif-tenreihe Konstruktionstechnik

[Sei85] Seiler, W.: Technische Modellierungs- und Kommunikationsverfah-ren fur das Konzipieren und Gestalten auf der Basis der Modellin-tegration. Dusseldorf : VDI-Verlag, 1985 ( Reihe 10, AngewandteInformatik, Nr. 49). – VDI Forschungsbericht

[Stu90] Sturmer, Ulf ; Beitz, Wolfgang (Hrsg.): Informationsmodell zumAbbilden funktionaler und wirkstruktureller Zusammenhange im Ma-schinenebau. Berlin : TU Berlin, Institut fur Maschinenkonstruktion-Konstruktionstechnik, 1990 ( Nr.17). – Schriftenreihe Konstruktions-technik

145


[The99] Theißen, J.: Kopplung von Gestaltung und Berechnung wahrendund nach der Entwicklungsphase einer Industrie Getriebebaureihe. In:Verkurzte Entwicklungsprozesse durch Integration von Gestaltung undBerechnung (siehe [VDI99]), S. 139–158

[Tur99] Turau, Volker: Techniken zur Realisierung Web-basierter Anwendun-gen. In: Informatik-Spektrum 22 (1999), Nr. 1, S. 3–12

[VDI80] VDI 2211: Datenverarbeitung in der Konstruktion / VDI VereinDeutscher Ingenieure. 1980. – VDI-Richtlinie Blatt 1

[VDI86] VDI 2230: Systematische Berechnung hochbeanspruchter Schrau-benverbindungen / VDI Verein Deutscher Ingenieure. 1986. – VDI-Richtlinie

[VDI93] VDI 2221: Methodik zum Entwickeln und Konstruieren technischerSysteme und Produkte / VDI Verein Deutscher Ingenieure. 1993. –VDI-Richtlinie

[VDI98] VDI-Gesellschaft Entwicklung, Konstruktion, Vertrieb (Veranst.):Prozeßketten fur die virtuelle Produktentwicklung in verteilter Umge-bung ( VDI–Berichte 1435). Dusseldorf : VDI-Verlag, 1998

[VDI99] VDI-Gesellschaft Entwicklung, Konstruktion, Vertrieb (Veranst.):Verkurzte Entwicklungsprozesse durch Integration von Gestaltung undBerechnung (VDI-Berichte 1487). Dusseldorf : VDI Verlag, 1999

[Vel99] Velten, V.: Integration von Stromungsberechnungen in den rechner-unterstutzten methodischen Konstruktionsprozeß . Aachen : Shaker,1999

[VRM99] Virtual Reality Markup Language Web 3D Consortium, 1999. – URLhttp://www.vrml.org

[Wah86] Deutsches Worterbuch. Gutersloh, Munchen, 1986

[WB97] Welp, E.G. ; Braun, P.: Semantische und systemtechnische Kopp-lung kommerzieller CAD– und Berechnungssysteme durch einen objek-torientierten Integrationsprozessor. In: VDI-Verlag (Hrsg.): VDI–Berichte 1357 . Dusseldorf, 1997, S. 125–141

[Web92] Weber, A.: Ein relationsbasiertes Datenmodell als Grundlage furdie Bauteiltolerierung . Erlangen, Lehrstuhl fur Konstruktionstechnik.Universitat Erlangen–Nurnberg, Dissertation, 1992

146


[Wol98] Wolfle, Frank: Virtuelle Berechnungskompetenzzentren als Dienst-leister zur Integration von Gestaltung und Berechnung. Dusseldorf :VDI Verlag, 1998 ( Reihe 20 Nr.274). – VDI Fortschr.-Ber.

[WN99] Westfechtel, B. (Hrsg.) ; Nagl, M. (Hrsg.): Integration vonEntwicklungssystemen in Ingenieuranwendungen. Berlin, Heidelberg: Springer, 1999

[Zie99] Ziesing, J.: Technische Berechnungen als Dienstleistung fur die Kon-struktionspraxis. In: Verkurzte Entwicklungsprozesse durch Integrati-on von Gestaltung und Berechnung (siehe [VDI99]), S. 103–122

147

Documents

Integration von Gestaltung und Berechnung mittels CORBA · Integration von Gestaltung und Berechnung mittels CORBA vorgelegt von Diplom { Ingenieur Gregor Haderer aus Berlin Vom Fachbereich