Zur Entwicklung von Berechnungsmethoden und deren ... · In VDI 2221 [VDI93] wird der Konstruktionsprozess in vier Phasen, „Klären und Präzisieren der Aufgabenstellung“, „Konzipieren“,

Zur Entwicklung von Berechnungsmethoden und deren

Integration in den Produktentwicklungsprozess

vorgelegt von

Dipl.-Ing. Rasoul Mirkheshti

aus Berlin

Von der Fakultät V – Verkehrs- und Maschinensysteme

der Technischen Universität Berlin

zur Erlangung des akademischen Grades

„Doktor der Ingenieurwissenschaft“

- Dr.-Ing. -

genehmigte Dissertation

Promotionsausschuss: Vorsitzender : Prof. Dr.-Ing. H. Meyer

Gutachter : Prof. Dr.-Ing. H. Mertens

Gutachter : Prof. Dr.-Ing. F.-L. Krause

Tag der wissenschaftlichen Aussprache: 20.10.2006

Berlin 2006

D 83

Vorwort

Die vorliegende Arbeit entstand während meiner Tätigkeit als

wissenschaftlicher Mitarbeiter am Institut für Maschinenkonstruktion, Mikro-

und Medizintechnik - Fachgebiet Konstruktionslehre der Technischen

Universität Berlin sowie während meiner leitenden Tätigkeit in der

Forschung und Entwicklung bei der Firma „CONTECS engineering services

GmbH“. Für die Förderung des Forschungsvorhabens bin ich der

Deutschen Forschungsgemeinschaft DFG zu Dank verpflichtet.

Mein ganz besonderer Dank gilt meinem Doktorvater Herrn Prof. Dr.-Ing.

H. Mertens für das entgegengebrachte Vertrauen und die Förderung der

Arbeit. Durch viele Gespräche und Anregungen hat er mich nicht nur

während meiner Tätigkeit am Institut, sondern auch danach stets gefördert

und damit wesentlich zum Gelingen dieser Arbeit beigetragen.

Für das entgegengebrachte Interesse und die kritische Durchsicht dieser

Arbeit bedanke ich mich bei Herrn Prof. Dr.-Ing. F.-L. Krause und bei Herrn

Prof. Dr.-Ing. H.J. Meyer für seine Bereitschaft, den Vorsitz im Promotions-

ausschuss zu führen.

Danken möchte ich auch allen Mitarbeitern des Instituts und der Firma

CONTECS engineering services GmbH für ihre Unterstützung und für das

angenehme Arbeitsklima.

Berlin, im August 2006

Meiner Frau Nasrin und meiner Tochter Pouneh gewidmet,

die mir in dieser Zeit mit Liebe und Geduld beiseite standen.

Inhaltsverzeichnis

1. Einleitung 1

1.1 Einsatz von EDV in der Produktentwicklung 2

1.2 Einsatz von Berechnungsprogrammen in der DV-gestützten Produktkonstruktion 4

1.2.1 Modellarten und Modelleigenschaften 5

1.2.2 Anforderungen zur Integration von DV- Berechnungen in den Konstruktionsprozess 7

1.2.3 ABC-Konzept und Zeitaufwand 11 1.2.4 ABC-Konzept und Aussagegüte 13 1.2.5 Kurzbeschreibung einiger Berechnungsverfahren 16 1.2.6 Mehrkörper-Simulation (MKS) 18

1.3 DFG-Schwerpunktprogramm zur Integration von Gestaltung und Berechnung 19

1.3.1 Eigene Arbeiten 21 1.3.2 Weiterführende Arbeiten 29

1.4 Zielsetzung – Aufbau der Arbeit 30 1.4.1 Gliederung der Arbeit 32

2. Analyse und Klassifikation von Berechnungen 35

2.1 Analyse der Systemeigenschaften 35

2.2 Klassifizierung nach zeitunabhängigen und zeitabhängigen Berechnungen 39

2.3 Klassifizierung von Berechnungsverfahren nach Modellstruktur 40

2.4 Klassifizierung von Berechnungsmethoden nach ihrem Kopplungspotential 42

II

3. Allgemeines zur Entwicklung und Integration rechnerunterstützter Berechnungstools 46

3.1 Analyse der Arbeitsschritte zur Entwicklung von Berechnungstools 47

3.1.1 Arbeitsschritt Modellbildung 50 3.1.2 Arbeitsschritt Implementierung und Integration 51 3.1.3 Allgemeine Formen der Datenintegration 52

4. Entwicklung und Integration produktabhängiger Berechnungstools 57

4.1 Entwicklung eines webbasierten Berechnungs- Informations- und -assistenzsystems 60

4.2 Entwicklung eines webbasierten Berechnungs- methodenbank 62

4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 68

4.3.1. Berechnungsmethodenmanagement 70 4.3.2 Berechnungsparametermanagement 72 4.3.3 Berechnungsdatenmanagement 73

4.3.4. Berechnungsverknüpfungsmanagement 76 4.3.5 Berechnungsintegrationsmanagement 79 4.3.6 Realisierung des verallgemeinerten Konzeptes 83

5. Entwicklung und Integration produktklassen- abhängiger Berechnungstools 88

5.1 Einsatz von MKS zur Untersuchung dynamischer Verhalten komplexer Systeme 89

5.2 Entwicklung eines MKS-Teilmodells zur dynamischen Untersuchung von Rädertrieben 92

5.2.1. Berechnung der Verzahnungssteifigkeit 98

III

5.3 Implementierung der Rädertriebmodels in SIMDRIVE3D-Umgebung 102

5.3.1. Hilfsmittel zur interaktiven Unterstützung der Rädertreibmodellierung 104

5.3.2 Animationstool zur Untersuchung der Kontakt- kinematik im Verzahnungsbereich 108

5.4 Integration produktklassenabhängiger Berechnungen in den Produktentwicklungsprozess 109

5.5 Kopplung von Berechnungsprozessen mit zeit- abhängigen Modellparametern 113

5.5.1. Entwicklung eines erweiterten MKS-Modells zur Unterstützung cosimulierender Prozesse 115

5.5.2 Datenkommunikation und Prozessteuerung während der Cosimulation 118

5.5.3 Prozesssynchronisation 122 5.5.4 Realisierung der Cosimulation in der SIMDRIVE3D-

Umgebung 128

6. Zusammenfassung 133

7. Literatur 135

IV

1 Einleitung

Der Einsatz von EDV (Elektronische Datenverarbeitung) in der

Produktentwicklung hat einen großen Beitrag zur Verkürzung der

Produktentwicklungszeiten und zur Steigerung der Produktqualität

geleistet. Im Trend kürzer werdender Produktlebenszyklen und steigender

Produktkomplexität bzw. Produktvielfalt werden in der Produktentwicklung

immer höhere Anforderungen an Soft- und Hardwaresysteme gestellt. Die

wirtschaftliche Globalisierung ermöglicht den Unternehmen heutzutage

weltweit, die besten Entwicklungsstandorte und Entwicklungspartner zu

suchen und zu integrieren. Durch diese Vorgehensweise wollen

international agierende Firmen ihre Wettbewerbsfähigkeit stärken und

gleichzeitig neue Märkte vor Ort erschließen. Auslandsinvestitionen und

Produktverlagerungen lösen die klassischen Unternehmensstrukturen ab

[Gra97]. Die Grenzen moderner Unternehmen sind „virtuell“. Künftige

Zusammenarbeitsformen der Entwicklungsteams im Unternehmen werden

nicht mehr durch traditionelle Firmengrenzen geprägt sein. Die

Zulieferindustrie wird gleichzeitig auch zum Entwicklungspartner und wirkt

nicht nur als Modullieferant, sondern auch als Know-how- bzw.

Innovationsträger. Berechnungsfachwissen sowie Berechnungsprogramme

werden nicht mehr an einem Ort, sondern verteilt - bei den jeweiligen

Know-how-Trägern - vorhanden sein.

Die Entwicklung komplexer, hoch beanspruchter Baugruppen und

Maschinenanlagen erfordert allerdings eine Beteiligung von Experten

verschiedener Fachdisziplinen in einer vernetzten Entwicklungsumgebung.

Die durchgehende, reibungslose Daten- und Informationslogistik zwischen

allen an der Produktentwicklung beteiligten Hard- und Softwaresystemen

ist dabei eine große informationstechnische Herausforderung. Die meisten

Entwicklungsaktivitäten auf diesem Gebiet lassen sich einerseits der

Verbesserung des Produktinformationsmanagements und anderseits der

Entwicklung von Kommunikationsstrategien und Werkzeugen für global

verteilte Produktentwicklungssysteme zuordnen.

1 Einleitung 2

Zur Verbesserung des Produktinformationsmanagements wird an

Infrastrukturen gearbeitet, die eine Abbildung, Steuerung und

Überwachung wichtiger, auch global verteilter Geschäftsprozesse erlauben

sowie das Management und die Entwicklung komplexer Produktstrukturen

umfassend unterstützen. Im Mittelpunkt stehen dabei Anwendungen für

das Prozessmanagement, die Auftrags- und Dokumentenverwaltung sowie

das Änderungswesen über den gesamten Produktlebenszyklus hinweg.

Diese Ansätze gehen implizit von einer integrierten Nutzbarkeit und

flexiblen Schnittstellen zwischen den verschiedenen Systemen zur

Produktgestaltung und Berechnung aus, was zur Zeit jedoch nur auf einen

geringen Teil der zur Anwendung kommenden Applikationen und

Werkzeuge zutrifft, häufig lediglich nur innerhalb der Produktfamilie eines

Herstellers. Bei den Kommunikationsstrategien überwiegen multimediale

Ansätze aus dem Bereich der Telekooperation.

1.1 Einsatz von EDV in der Produktentwicklung

Der Einsatz von EDV zur Unterstützung der Produktentwicklung begann

schon in den 50er Jahren. Es handelte sich dabei um

Berechnungsaufgaben mit großem numerischem bzw. iterativem Aufwand.

In dieser Zeit wurden auch die ersten FE-Programme (Finite-Elemente-

Programme) entwickelt. In den 70er Jahren hat die Entwicklung von

numerisch gesteuerten Maschinen (NC-Maschinen) und Produktplanungs-

systemen (PPS) diesen Prozess revolutioniert. Das Optimierungspotential

im Bereich Fertigung und Planung in dieser Zeit war so groß, dass die

Entwicklung von CAD- bzw. FE-Systemen gegenüber der Entwicklung von

NC- und PP-Systemen weit zurück blieb. In den 80er Jahren haben

allerdings die Entwickler der CAD-Technologie diesen Rückstand

nachgeholt, gleichzeitig wurden auch leistungsfähige FE- und

Mehrkörpersimulationssysteme (MKS-Systeme) entwickelt [Schn05].

In den 90er Jahren wurde neben Optimierung und Weiterentwicklung

einzelner EDV-Systeme in der Produktentwicklung (Digital Mock-up, 3D-

Simulation, Rapid Prototyping, Virtual Reality, etc.) auch deren

1.1 Einsatz von EDV in der Produktentwicklung 3

Integrationsaspekte berücksichtigt. Durch die Entwicklung von EDM-

Systemen (EDM, Engineering Data Management) wurden große Teile der

CAx-Systeme1 von der Produktplanung über die Zeichnungserstellung bis

zur NC-Programmierung durchgehend integriert bzw. automatisiert. Die

Integration von FE- bzw. Simulationssystemen mit CAD ermöglichte die

Ausführung von statischen bzw. dynamischen Modellanalysen direkt vom

CAD-Arbeitsplatz aus. Die Datenkonsistenz zwischen den beiden

Systemen - CAD- und Analysetools - wurde entweder über ein

gemeinsames Datenmodell oder über den Einsatz leistungsfähiger

Schnittstellen sichergestellt. Durch diese Entwicklungen wurde auch die

Durchführung von Iterations- bzw. Optimierungsrechnungen möglich

[Beck94].

Die wirtschaftliche Globalisierung in den letzten Jahren hat die alte zentrale

Struktur von Unternehmen in ein Netz verteilt kooperierender Entwicklungs-

standorte umgewandelt. Zur Beschreibung technischer Produkte von der

Produktplanung über die Entwicklung und Herstellung bis zur

Produktentsorgung fallen große Mengen an Daten an, die zum größten Teil

durch Einsatz unterschiedlicher Softwarewerkzeuge verwaltet und

schließlich im Rechner gespeichert werden. Die Summe der verteilten

Daten bzw. Datenmodelle beschreiben dann gemeinsam das technische

Produkt und können zusammen im Hinblick auf eine integrierte

Softwareumgebung als „verteiltes Produktmodell“ bezeichnet werden

(siehe Abschnitt 4.3.3). Die heutigen Forschungs- bzw. Entwicklungs-

aktivitäten zur Integration von Softwaresystemen in die Produktentwicklung

berücksichtigen u. a., dass

• im Bereich der Produktentwicklung verschiedene Softwarewerkzeuge

(EDM-, CAD-Systeme, Datenbanken, etc.) mit unterschiedlichen

Datenmodellen eingesetzt werden, und 1 CAx steht stellvertretend für alle rechnerunterstützten Technologien. Unter CAx-Systemen

werden Programmsysteme verstanden, die für Anwendungsgebiete aus dem Ingenieurbereich

entwickelt sind, wie z.B. CAD-Systeme oder auch Berechnungssysteme wie FEM.

1 Einleitung 4

• die kooperierenden Entwicklungsarbeitplätze in der Regel weltweit

verteilt sind.

1.2 Einsatz von Berechnungsprogrammen in der DV-gestützten Produktkonstruktion

In diesem Abschnitt werden in Anlehnung an die Richtlinie VDI 2211 Blatt 2

„Datenverarbeitung in der Konstruktion; Berechnungen in der Konstruktion“

[VDI99-1] die wesentlichen Kriterien und Anforderungen zum Einsatz von

Berechnungen in den DV-gestützten Konstruktionsprozess zusammen-

fassend zitiert. Diese Richtlinie ergänzt die Richtlinien VDI 2221 „Methodik

zum Entwickeln und Konstruieren technischer Systeme und Produkte“ und

VDI 2216 „Datenverarbeitung in der Konstruktion – Einführungsstrategien

und Wirtschaftlichkeit von CAD-Systemen“.

Unter dem Begriff Konstruktion wird sowohl die Gestaltung einzelner Teile

als auch deren Zusammensetzung zu einem Ganzen verstanden.

Konstruieren kann somit Zusammensetzen, Anordnen, Formen und

Gestalten, aber auch Entwerfen, Hervorbringen, Bilden und Erfinden

bedeuten [Gra93]. In VDI 2221 [VDI93] wird der Konstruktionsprozess in

vier Phasen, „Klären und Präzisieren der Aufgabenstellung“, „Konzipieren“,

„Entwerfen“ und „Ausarbeiten“ zusammengefasst. Dabei finden die ersten

Berechnungsaktivitäten schon in den frühen Entwurfsstadien in Form von

Auslegungsrechnungen auf Basis von Faustformeln und einfachen

analytischen Gleichungen und später in Form von problem- bzw.

produktbezogenen Berechnungen statt. Als Hilfsmittel zur Anwendung von

Berechnungsverfahren stehen dem Konstrukteur folgende Möglichkeiten

offen:

• Einfache Hilfsmittel, z.B. Formulare, Tabellen, Taschenrechner.

• Standardsoftware, wie z.B. Tabellenkalkulationsprogramme oder

Bibliotheken mathematischer Programme.

• Bibliotheken für Standardrechnungen, wie z.B. zur Auslegung von

Maschinenelementen.


• Firmen-, produkt-, oder mitarbeiterspezifische Individualsoftware.

• Höhere Berechnungssoftware auf Basis numerischer Verfahren, wie

z.B. Finite-Elemente-Methode (FEM) oder Mehrkörpersimulations-

systeme (MKS).

• CAD-Systeme mit integrierten Berechnungsmodulen.

Dank moderner Hard- und Softwaretechnik ist es heutzutage möglich, auch

komplexe Systeme analytisch zu untersuchen, um damit experimentelle

Systemanalysen zu ersetzen. Eine Stärke der Berechnung liegt darin, dass

offene Fragen auch ohne ein reales System, ein reales Modell oder einen

Prototyp beantwortet werden können. Eine analytische, modellhafte

Beschreibung der physikalischen Systemeigenschaften, das sogenannte

Berechnungsmodell, dient als Basis der Berechnung (siehe Abschnitt

1.2.1). Das gewählte Berechnungsmodell muss in seinen Eigenschaften

das Original hinreichend genau repräsentieren. Gegebenfalls gehen auch

äußere Einflüsse in das Modell ein, die durch experimentelle

Untersuchungen oder Annahmen ermittelt worden sein können. Die Güte

und Aussagekraft einer Berechnung werden wesentlich vom zugrunde

gelegten Berechnungsmodell und der Bewertung der rechnerisch

erhaltenen Ergebnisse bestimmt. Darüber hinaus müssen bei der Bildung

von Berechnungsmodellen auch die zur Verfügung stehenden Rechen-

bzw. Auswertemethoden berücksichtigt werden.

1.2.1 Modellarten und Modelleigenschaften

Modelle sind – vereinfachte – Abbildungen oder Nachbildungen von

Originalen. Dabei werden von der großen Anzahl an Merkmalen des

Originals nur eine begrenzte Auswahl in das Modell übernommen werden.

Bei Berechnungen für materielle Objekte werden auch die Annahmen und

Gesetzmäßigkeiten, mit denen die Eigenschaften der zu untersuchenden

Gegenstände beschrieben werden, in Modellen (Berechnungsmodellen)

erfasst. Die Eigenschaften eines Modells sind vom modellierten Original

1 Einleitung 6

und dem Modellzweck abhängig. Je nach ihren Merkmalen gibt es

unterschiedlichen Modellarten.

Unter einem „integrierten Produktmodell“ versteht man die redundanzfreie

Abbildung aller relevanten Daten aus sämtlichen Lebensphasen (von der

Produkt-Planung über die –Entwicklung und –Herstellung bis zur

Produktbeseitigung) eines Produkts in einem einheitlichen, allgemeinen

Modell [Gra93]. Oft wird man nur die für einen bestimmten Zweck der

Modellbildung relevanten Merkmale des Originals auswählen und in einem

„Teilmodell (Partialmodell)“ zusammenfassen.

Bei vielen Problemstellungen genügt es, wenn Modellzustände unabhängig

von Zeiteinflüssen betrachtet werden. Solche Modelle heißen „statische

Modelle“. Ein „dynamisches Modell“ liegt vor, wenn bei wenigstens einem

seiner Merkmale die Zeit als veränderlicher Parameter auftritt. Modelle, die

das interne Verhalten der Systemelemente sowie die verhaltens-

bestimmende Struktur eines Systems nachbilden, heißen

„Strukturmodelle“, weil das Gesamtverhalten des Systems aus dem

internen Verhalten der Struktur erklärt werden kann.

Modelle können „deterministisch „ sein, d. h. zu jedem Ausgangszustand

gehört ein eindeutiger Folgezustand, oder „stochastisch“, d.h. zu einem

Ausgangszustand kann es mehrere Folgezustände geben.

Deterministische Modelle können stochastisches Verhalten zeigen, wenn

stochastische Einflussgrößen aus der Umwelt hinzutreten. Beispielsweise

kann ein Fahrzeug durch ein deterministisches Modell beschrieben

werden; zufällige Störgrößen von der Strecke, z.B. Fahrbahnunebenheiten,

ergeben ein stochastisches Modell zur Beschreibung der Fahrwerk-

belastung.


1.2.2 Anforderungen zur Integration von DV-Berechnungen in den Konstruktionsprozess

Für den effizienten Einsatz der DV-gestützten Berechnungshilfsmittel spielt

in erster Linie eine Rolle, inwieweit bereits digital gespeicherte

Produktmodelldaten in Berechnungsprogramme geladen, dort verarbeitet,

die Ergebnisse dargestellt und ggf. wiederauffindbar in einem einheitlichen,

integrierten Produktmodell gespeichert werden können. Von diesem

Hintergrund aus werden zwei Extreme hinsichtlich der Integration von DV-

gestützten Berechnungshilfsmitteln in den Konstruktionsprozess formuliert:

• Isolierte Berechnungs- oder Bibliotheksprogramme als Insellösungen

und

• CAD- und Berechnungssoftware auf Basis eines integrierten Produkt-

modells.

Die Anforderungen zur Integration von DV-Berechnungen werden in zwei

Gruppen „Anwenderanforderungen“ und „Soft- und Hardware-

anforderungen“ geteilt.

Anforderungen aus der Anwendersicht:

Die Integrationskonzepte aus Anwendersicht müssen folgende Kriterien

erfüllen:

• Einbettung der DV-Berechnungsverfahren in die methodische

Vorgehensweise zur rechnerunterstützten Konstruktion in Anlehnung an

die Richtlinie VDI 2221 [VDI93] unter Berücksichtigung des Einsatzes

moderner CAx-Systeme,

• netzweite Bereitstellung aller in einem Unternehmen eingesetzten

Berechnungsverfahren in einer anwendungsgerechten Berechnungs-

methodenbank,

• DV-Unterstützung der interdisziplinären Zusammenarbeit zwischen

Konstrukteuren und Berechnungsingenieuren,

1 Einleitung 8

• einheitliche und benutzerfreundliche Gestaltung und Bedienung der

CAx-Systeme an der Benutzungsschnittstelle,

• akzeptable Antwortzeiten von DV-Berechnungssystemen, wie dies für

die interaktive Arbeitsweise im Konstruktionsprozess erforderlich ist und

• Ausrichtung von CAx-Systemen an den Arbeitsabläufen in der

Konstruktion in sogenannten Prozessketten2, die sich ihrerseits

entscheidend auf die Organisationsstruktur von Unternehmen

auswirken.

Soft- und Hardwareanforderungen:

Die Soft- und Hardwareanforderungen zur Integration von DV-

Berechnungsverfahren können wie folgt zusammengefasst werden:

• Kopplung bestehender Berechnungssoftware

Bestehende DV-Berechnungssysteme wurden in der Regel isoliert von

anderen CAx-Systemen entworfen und implementiert. Ziel solcher Systeme

ist es, das für eine Berechnung notwendige Berechnungsmodell aus dem

CAD-Modell abzuleiten. Zur Kopplung der Systeme ist dann eine

Datenschnittstelle zu verwenden, die es erlaubt, einen möglichst großen

Teil der Produktdaten aus dem rechnerinternen Modell des CAD-Systems

in das Berechnungsmodell des Berechnungssystems zu überführen. Die

beim Datenaustausch vorzunehmenden Modelltransformationen sind

jedoch stets mit Datenverlusten behaftet [Seil85].

2 Prozesskette umfasst die Gesamtheit von Informationsverarbeitungsprozessen, in denen

voneinander abhängige bzw. aufeinander aufbauende Informationen zur Erreichung eines

gemeinsamen Zieles ausgetauscht werden [Mue95].


• Integration von CAx-Systemen auf Basis integrierter Produktmodelle;

In einem integrierten Produktmodell sind definitionsgemäß alle relevanten

Produktdaten aus sämtlichen Produktlebensphasen enthalten. Ein

integriertes Produktmodell ist daher Voraussetzung für die Realisierung

einer durchgängigen Wiederverwendung und Weiterverarbeitung einmal

digital erfasster und gespeicherter Produktdaten in unterschiedlichen CAx-

Systemen (Bild 1). Neue Entwicklungen im CAx-Bereich streben

inzwischen auch die Integration von Berechnungsmodellen in integrierte

Produktmodelle an [Grab96][Steg95]. Integrierte Produktmodelle bilden die

Ausgangsbasis für die Implementierung von CAx-Systemen [Gra93]. Auf

diese Weise soll die reibungslose Weitergabe von CAD-Daten an DV-

Berechnungssysteme, die Weiterverarbeitung der Daten und die

Rückführung der Berechnungsergebnissen in das Konstruktionssystem von

vornherein sichergestellt. Insbesondere die Entwicklung neuer DV-

Berechnungssysteme sollte dieser Herausforderung gerecht werden.

IntegriertesProduktmodell

Objekte undMethoden

Konstruktion

PreprocessingDV-Berechnung

Erstellung vonProduktmodelldaten

Objekte undMethoden

Kom

mun

ikat

ion

Kom

mun

ikat

ion

Bild 1: Integration von CAx-Systemen auf Basis eines integrierten

Produktmodells

1 Einleitung 10

• Nutzung von DV-Standards

Zur Übergabe von Berechnungsdaten zwischen CAD- und

Berechnungssystemen stehen verschiedene Datenschnittstellen zur

Verfügung, die es erlauben, Produktdaten im systemabhängigen oder

systemunabhängigen, d.h. standardisierten Datenformat zu übertragen. Die

Nutzung von DV-Standards bietet Entscheidungssicherheit in Bezug auf

einen längerfristigen Einsatz von CAx-Systemen und sichert die

Unabhängigkeit des Unternehmens von speziellen Anbietern.

• Nutzung offener DV-Systeme

Offenheit von DV-Systemen ist dann gegeben, wenn Hard- und

Softwarekomponenten problemlos ausgetauscht, ersetzt oder angepasst

werden können. Als wichtigstes Merkmal besitzen offene Systeme deshalb

eine Entwicklungsschnittstelle, welche das rechnerinterne Modell eines

CAx-Systems dokumentiert und offenlegt.

• Vernetzte, modulare Soft- und Hardwarearchitektur

In einer vernetzten, modularen Soft- und Hardwarearchitektur sind die

räumlich im Unternehmen verteilten DV-Arbeitsplätze durch Datenleitungen

miteinander verbunden. Dies ist Voraussetzung für eine sinnvolle

Integration oder Kopplung von CAD- und Berechnungssystemen zwecks

gemeinsamer Nutzung oder Austausch von Produktdaten über die Grenzen

isolierter Rechner hinaus. Durch den Aufbau von Rechnernetzen können

beispielsweise notwendige Eingabedaten für Berechnungssysteme,

Berechnungsergebnisse oder beliebige andere Arbeitsergebnisse digital

und online zwischen DV-Arbeitsplätzen von Mitarbeitern ohne Zeitverlust

ausgetauscht werden. Auf diese Weise wird sowohl die inner- als auch die

überbetriebliche, interdisziplinäre Zusammenarbeit zwischen Ingenieuren,

wie z.B. zwischen Konstrukteur und Berechnungsingenieur, durch

Rechnereinsatz verbessert.


1.2.3 ABC-Konzept und Zeitaufwand

Die bisherigen Erfahrungen mit Berechnungen im Konstruktionsprozess

haben gezeigt, dass es zweckmäßig ist, die Berechnungsmethoden

hinsichtlich des Zeitaufwands beim Anwender3 zu strukturieren [Me98].

Dies ist vor allem dann anzustreben, wenn die Kommunikation im Betrieb –

auch darüber hinaus – über ein Datennetz erfolgen soll. Bild 2 zeigt

vereinfacht die Kommunikationsstruktur zwischen einem Konstruktions-

und einem Berechnungsarbeitplatz [Woe98].

Bild 2: Konzept einer Kommunikationsstruktur zwischen Konstruktions-

und Berechnungsarbeitsplatz [Woe98]

3 Der Zeitaufwand für die Entwicklung einer Methode, der nur einmal auftritt, ist darin nicht zu

berücksichtigen.

1 Einleitung 12

Danach soll der entwerfende Konstrukteur, der mit einem CAD-System

arbeitet, mit allen für die Konstruktion erforderlichen Informationen über

Netz versorgt werden, und bei Bedarf Berechnungsaufträge an andere am

Netz angeschlossene Dienste weiterleiten können. Zur Gestaltung eines

optimalen Konstruktionsprozesses müssen diese Dienste dem

gemeinsamen Ziel nach möglichst kurzen Produktentstehungszeiten

verpflichtet sein. Folgerichtig muss die Methodenbank eines Berechnungs-

und Bewertungssystems Berechnungsmethoden mit möglichst geringem

Zeitaufwand bei hoher Aussagegüte anbieten und die Auswahl durch

Anwendungshinweise aus einer Wissensbasis unterstützen. Da dies nicht

uneingeschränkt möglich ist, müssen Berechnungsmethoden mit mittlerem

oder gar hohem Zeitaufwand für Zweifelsfälle ebenfalls bereitstehen. Zur

Transparenz des Berechnungsprozesses werden die Berechnungs-

methoden deshalb mit Anwendungshinweisen – entsprechend dem

Zeitaufwand – wissensbasiert verwaltet, wobei sinnvollerweise die

Berechnungsvorbereitung und die Berechnungsbewertung im Zeitaufwand

berücksichtigt werden. Berechnungsmethoden mit kurzem Zeitaufwand

werden in der Berechnungsebene C verwaltet, die mit mittlerem

Zeitaufwand in der Berechnungsebene B und die mit hohem Zeitaufwand in

der Berechnungsebene A.

Ein wissensbasiertes Berechnungs- und Bewertungssystem wird

entsprechend diesem ABC-Konzept auf der Basisebene C vor allem

Faustformeln und analytische Kurzprogramme anbieten, auf die der

Konstrukteur stets selbst zugreifen wird. Auch die Berechnungsmethoden

der Ebene B sollen vom Konstrukteur selbst nach einer gewissen

Einarbeitungszeit genutzt werden können. Im Sinne von Festigkeits-

berechnungen wird man hier vor allem feinfinite Berechnungsmethoden auf

der Grundlage linearer Werkstoffgesetze ablegen. Auf der Ebene A sind

dann feinfinite Methoden mit beliebigen Nichtlinearitäten denkbar, die im

allgemeinen bei der Anwendung spezielles Fachwissen und Rechner-

erfahrung erfordern.


Eine Gliederung des Berechnungsprozesses in die Ebenen A, B, C fügt

sich zwanglos in den Konstruktionsprozess ein. In der frühen

Entwurfsphase ist die Gestaltungsfreiheit des Konstrukteurs noch relativ

groß; da er extrem viele Entscheidungen zu treffen hat, sind nur schnelle

Entscheidungshilfen nutzbar, also Methoden der Basis-Ebene C. Da jedoch

die Bewertungsmethoden der Ebene C sehr häufig nur unscharfe

Beurteilungen erlauben, ist deren Aussagegüte oft eingeschränkt.

Mit wachsender Konkretisierung des Produktes nimmt der verbleibende

Gestaltungsspielraum des Produktes ab, so dass Methoden der Ebene B

die Feingestaltung unterstützen können. Da bei richtiger Wahl der

Berechnungsmethode B die Aussagegüte steigt, kann oft durch Festlegung

hinreichender Sicherheitsabstände eine weitere Berechnungsverfeinerung

unterbleiben. Ist jedoch auch damit keine Aussagesicherheit zu erreichen,

sind Berechnungsmethoden der Ebene A eventuell hilfreich, im Zweifel

können in solchen Fällen nur Betriebsversuche endgültige Aussage-

sicherheit herbeiführen.

1.2.4 ABC-Konzept und Aussagegüte

Aus der Sicht des Konstrukteurs ist es wünschenswert, möglichst viele

Berechnungs- und Bewertungsmethoden mit geringem Zeitaufwand (C-

Methoden) anwenden zu können. Dies ist im allgemeinen nicht ohne

weiteres möglich. Bei der Entwicklung eines vollständig neuen Produkts

wird sich vielmehr der im Bild 3 gezeigte Zusammenhang einstellen

[Me98].

1 Einleitung 14

Berechnungs- und Bewertungs-methoden (allgemein)

A

B

A

C

BC

Aus

sage

güte

Zeitaufwand

C

B

A

Bild 3: Natürliche Zuordnung von Aussagegüte und Zeitaufwand für

Berechnungs- und Bewertungsmethoden [Me98][VDI99-1] 4

Mit geringem Zeitaufwand ist im allgemeinen nur eine geringe Aussagegüte

erreichbar, bei hohem Zeitaufwand erwartet man bei richtiger

Vorgehensweise eher eine hohe Aussagegüte. Dies gilt auch für

Berechnungs- und Bewertungsmethoden.

In der Methodenebene C für den Zeitaufwand werden vor allem die

Berechnungsmethoden auf Basis von Faustformeln sowie analytischer

Kurzprogramme verwaltet. Auf dieser Ebene findet man auch

produktspezifische Auslegungsmethoden - vor allem für die frühen Phasen

des Konstruktionsprozesses. Die Methodenebene A ist für hochwertige

Berechnungsmethoden vorgesehen, die i. a. spezielles Fachwissen und

Rechnererfahrung verlangen. Die Methoden der Ebene A erfordern einen

größeren Zeitaufwand als Methoden der Ebene B bzw. C. Die Methoden

4 Hinweis: Die Literaturstelle [VDI99-1] bezieht sich auf den Entwurf der VDI 2211 Blatt2. Leider

sind die Bilder im endgültigen Weißdruck falsch wiedergegeben. Richtige Reihenfolge für

Zeitaufwand siehe Bilder 3 und 4 dieser Arbeit sowie Original [Me98].


der Ebene B bilden somit eine Brücke zwischen den Ebenen A und C

hinsichtlich des Zeitaufwands.

Zur Entwicklung solcher B-Methoden sind umfangreiche Betriebs-

erfahrungen und Berechnungswissen erforderlich, sie sollten aber vom

Konstrukteur direkt nach einer gewissen Einarbeitungszeit verwendet

werden können. Um Berechnungsmethoden mit höherer Aussagegüte,

aber mit geringem Zeitaufwand beim Anwender zu erhalten, werden für

bestimmte Produktklassen häufig eingesetzte A- und B-Methoden

hinsichtlich ihres Zeitaufwands optimiert und in Form von (C aus A)- oder

(C aus B)- oder (B aus A)-Methoden zur Verfügung gestellt (Bild 4).

Bild 4: Entwicklung von produktbezogenen (C aus B)- und (C aus A)-

Methoden – in Anlehnung an [Me98]

1 Einleitung 16

Die Entwicklung solcher Methoden erfordert allerdings ein langjähriges

Erfahrungswissen hinsichtlich des Betriebsverhaltens, der verwendeten

Werkstoffe, der Umwelteinflusse, etc. zur jeweiligen Produktklasse. Oft

werden dabei die allgemeingültigen Berechnungsgrundlagen eingeschränkt

und an die jeweilige Produktklasse angepasst, so dass die Vorgabe

bestimmter Berechnungsdaten automatisiert werden kann. Die so

optimierten Berechnungsmethoden sind allerdings nur für die relevante

Produktklasse einsetzbar, eine direkte Übertragung auf ähnliche

Produktklassen ist in der Regel nicht möglich. Allgemein gilt, je flexibler das

zugrunde liegende Berechnungsmodell ist, desto aufwendiger ist die

Modellvorbereitung für die Berechnung.

1.2.5 Kurzbeschreibung einiger Berechnungsverfahren

Die Methoden der Ebene C lassen sich in den Taschenbüchern der

Ingenieurwissenschaft nachsehen, wobei aber in der Regel Hinweise zur

Aussagegüte der Methoden unterbleiben. Eine Anwendung dieser

Methoden eignet sich deshalb vor allem zur Grobdimensionierung. Von

besonderem praktischem Wert ist, dass diese einfachen Methoden oft auf

geschlossen lösbaren analytischen Gleichungen beruhen und damit einen

schnellen Überblick über den Einfluss einzelner Konstruktionsparameter

ergeben.

Zur Untersuchung komplexer Bauteile bzw. Baugruppen mit hoher

Aussagegüte ist man in der Regel auf genauere Belastungsdaten und

genaueren Modellierungsverfahren angewiesen. Lösungen sind dann nur

noch mit „numerischen Berechnungsverfahren“ wie beispielsweise der

Finite-Elemente-Methode (FEM) - für nahezu alle Ingenieuraufgaben - oder

Mehrkörpersimulationssysteme (MKS) - zur Untersuchung von

Bewegungsabläufen - möglich. Diese Verfahren basieren auf der

Annäherung des Verhaltens komplexer Bauteile bzw. Baugruppen durch

Bestimmung des Verhaltens einer Vielzahl von kleinen zusammengefügten

Teilen. Die komplexe Struktur der Baugruppe wird dabei in kleine

Elemente, deren Verhalten relativ einfach beschrieben werden kann,


zerlegt (Diskretisierung). Dem einzelnen Element werden nun die

erforderlichen Eigenschaften zur Beschreibung des Elementverhaltens

zugeordnet. Anschließend wird das physikalisch-mathematische

Beschreibungsmodell für das Gesamtsystem aufgestellt. Nach Festlegung

der bekannten Randbedingungen wird in der Regel ein Gesamtgleichungs-

system aufgestellt, das durch Einsatz numerischer Verfahren näherungs-

weise gelöst werden kann.

1.2.5.1 Finite-Elemente-Methoden

Mit den Finite-Elemente-Methoden wird versucht, das Verhalten von

kompliziert gestalteten Bauteilen oder Feldbereichen (Kontinua) durch

Diskretisierung in kleinere Einheiten, die finiten Elemente, zu beschreiben.

Zur Berechnung von Balken- und Stabtragwerken bzw. Fachwerken

werden seit langem Verschiebungsverfahren verwendet, die methodisch

der Ebene C zuzuordnen sind. Bei diesen Problemstellungen handelt es

sich um konstruktiv bedingte diskrete Strukturen, die als sogenannte

Strukturelemente bezeichnet werden. Mit Hilfe elementarer Beziehungen

werden den Elementen entsprechende Steifigkeiten zugeordnet und die

Einzelstrukturen zu einem Gesamtsystem überlagert. Nach Einbringen von

bekannten Randdaten (hier Belastungen, Lagerungen) lassen sich durch

Lösen eines Satzes von linearen Gleichungen die unbekannten Werte

ermitteln.

Diese Vorgehensweise kann prinzipiell auf die Berechnung komplexer

Probleme übertragen werden. Im Gegensatz zu den vorher dargestellten

Strukturelementen ist nun vorab eine künstliche Zerlegung der betrachteten

Kontinua (Diskretisierung) notwendig. Man spricht in diesem

Zusammenhang von Kontinuumselementen. Dem einzelnen Element wird

nun wieder eine charakteristische Eigenschaft in Form einer

verallgemeinerten „Elementeigenschaft“ zugeordnet. Hierzu wird die

beschreibende Differentialgleichung des Problems (z.B. Bilanzgleichung,

Erhaltungssatz) in eine Variationsformulierung überführt. Durch einfache

Ansatzfunktionen für die physikalischen Größen in jedem Element – meist

1 Einleitung 18

in Form von Polynomansätzen – kann diese Variationsformulierung nun

direkt zur Beschreibung der charakteristischen Elementeigenschaften

verwendet werden.

Diese allgemeine Vorgehensweise erlaubt es, eine Vielzahl von

Ingenieuraufgaben hiermit zu bearbeiten. Dazu gehören u. a.:

• Statische Probleme der Festkörper- und Strukturmechanik

• Dynamische Probleme der Festkörper- und Strukturmechanik

(Schwingungsberechnungen mit und ohne Dämpfung, Eigen-

frequenzen)

• Stabilitätsprobleme, Eigenwertprobleme (z.B. Knicken und Beulen)

• Potentialprobleme (Wärmeübertragungsprobleme, elektrische Feld-

probleme)

• Allgemeine Strömungsprobleme kompressibler, inkompressibler und

zäher Medien

1.2.6 Mehrkörper-Simulation (MKS)

Mehrkörper-Simulationsprogramme werden zur Berechnung von

kinematischen und kinetischen Vorgängen beweglicher Konstruktionen

genutzt. Im wesentlichen setzen sich die Modelle dabei aus einer Anzahl

meist starrer Körper mit Massen- und Trägheitseigenschaften zusammen,

die über Gelenke unterschiedlicher Freiheitsgrade sowie Federn und

Dämpfer miteinander verbunden sind. Als Ergebnissen stehen, neben der

Berechnung der Bahnkurven einzelner Konstruktionspunkte, die

Bahngeschwindigkeiten und Bahnbeschleunigungen bereit.

Die generelle Vorgehensweise der MKS-Programme lässt sich so

zusammenfassen:

Von einem geometrisch und kinematisch beschriebenen Modell wird eine

interne Graphen-Darstellung abgeleitet und mit Hilfe dieser dann ein Satz

von Bewegungsgleichungen formuliert (Differentialgleichungen). Mit

geeigneten mathematischen Methoden (z.B. der numerischen Integration


nach Runge-Kutta) können die Bewegungsgleichungen über die Zeit

integriert werden, was als Ergebnis die zeitabhängigen Bahn-,

Geschwindigkeits- und Beschleunigungskurven liefert. Je nach MKS-

Programm können dabei offene, geschlossene oder mehrfach vermaschte

kinematische Ketten behandelt werden.

1.3 DFG-Schwerpunktprogramm zur Integration von Gestaltung und Berechnung

Im Jahr 1995 wurde das DFG-Schwerpunktprogramm (SPP) „Innovative,

rechnerunterstützte Konstruktionsprozesse – Integration von Gestaltung

und Berechnung“ ins Leben gerufen [CAT99]. Zu diesem Zeitpunkt stellten

viele der Berechnungsprogramme eine Insellösung dar. Schon zwischen

einzelnen Berechnungsbausteinen auf demselben, geschweige auf

unterschiedlichen Rechnern war eine konsistente Datenübergabe häufig

nicht gewährleistet. Noch viel schwieriger war es, aus einem CAD-

Geometriemodell die für ein idealisiertes Berechnungsmodell relevanten

Geometriedaten (z.B. Durchmesser einer Welle, Radius einer Kerbe usw.)

widerspruchsfrei und für alle Phasen des Konstruktionsprozesses eindeutig

an die maßgebenden Berechnungsmodule zu übergeben.

In der umgekehrter Richtung, d.h. also von einem beliebigen Berechnungs-

baustein zum aufrufenden CAD-Programm, scheiterte eine konsistente

Datenübergabe aus denselben Gründen. Durch die Verkürzung der

Arbeitsschritte zwischen Konstruktion und Berechnung sowie eine schnelle

und eindeutige Übergabe von Konstruktionsdaten an die Berechnung und

umgekehrt sollte im SPP ein Beitrag zur Reduzierung der Produkt-

entstehungszeiten des Gesamtproduktes geleistet werden. Die

wesentlichen Fragen bzw. Forschungsfelder, zu deren Lösung das

Schwerpunktprogramm einen Beitrag leisten sollte, waren:

1 Einleitung 20

• Wie müssen geometrische Partialmodelle sowie Berechnungs-

algorithmen hinsichtlich ihrer Operationsstruktur, Datenstruktur und

Datenspeicherung aufgebaut sein, damit unterschiedlichste

Berechnungsprogramme auf alle Partialmodelle automatisch zugreifen,

diese aufgrund von Berechnungsoperationen nach einer vorgegebenen

Konstruktionsstrategie verändern und das Geometriemodell

anschließend modifizieren können?

• Wie ist die Datensicherung und die Speicherung verschiedener

Gestaltungszustände (Datenbestände) während des Konstruktions-

prozesses auszuführen, um trotz kontinuierlicher Entwurfs-

vereinfachungen die grundlegenden Entscheidungskriterien für spätere

Anpassungs- oder Nachkonstruktionen zu sichern?

• Inwieweit ist es arbeitsmethodisch, programmiertechnisch und

aufwandmäßig lohnend bzw. machbar, mehrere Berechnungs-

programme und Geometriemodellierer von einem CAD-Konstruktions-

system aus zu verwalten und einzeln oder integriert, je nach den

Bedürfnissen des Konstrukteurs anzusteuern? Sind für ein solches

umfassendes Konstruktionssystem Methoden und Tools von

wissensbasierten Systemen einsetzbar und hilfreich?

• Im Interesse des Kopplungsmöglichkeiten von unterschiedlichen CAD-

Systemen und Berechnungsprogrammen, auch in vernetzten

Konstruktionsarbeitsplätzen, sind langfristig hersteller- und

systemabhängige Schnittstellen und Datenübertragungsformate

erforderlich. Reicht hier die internationale Standardisierung der

Produktdatentechnik für eine konsistente und widerspruchsfreie

Verknüpfung mehrerer Datenbestände aus (z.B. mit STEP5) oder

müssen diese Standards erweitert werden?

5 STEP: Standard for the Exchange of Product Model Data.


In der ersten Phase des Schwerpunktprogramms wurden zwei Gruppen mit

folgenden Forschungsschwerpunkten gebildet:

• Eine methodenorientierte Gruppe, die von vornherein nach flexibler

und allgemeiner Anwendbarkeit der Ergebnisse suchte, und

• eine objektorientierte Gruppe, die zunächst konkrete Produkte oder

Verfahren zur exemplarischen Entwicklung von Methoden heranzog, um

die Ergebnisse anschließend zu verallgemeinern.

1.3.1 Eigene Arbeiten

Das Fachgebiet Konstruktionslehre im Institut für Konstruktion, Mikro- und

Medizintechnik der Technischen Universität Berlin war während der gesamten

Förderperiode von 1995 bis 2001 unter Leitung von Prof. Dr.-Ing. H. Mertens

an DFG-Forschungsprojekt beteiligt. Das übergreifende Ziel der Arbeiten des

Fachgebiets im SPP war die Entwicklung eines wissensbasierten

Berechnungs- und Bewertungssystems mit einer offenen Architektur, um

damit Berechnungen unterschiedlicher Komplexität für alle am Konstruktions-

prozess beteiligten CAD-Systeme netzweit zur Verfügung zu stellen. Diese

Forschungsarbeiten zählten somit zur methodenorientierten SPP-Gruppe, die

von vornherein nach flexibler und allgemeiner Anwendbarkeit der Ergebnisse

suchte.

Die Forschungsaktivitäten des Fachgebiets Konstruktionslehre in den ersten

drei Jahren des SPP konzentrierten sich auf ein objektorientiertes

Integrationskonzept6. Wichtige Entwicklungsschwerpunkte dabei waren:

• Ausbau und Erprobung einer flexiblen, netzbasierten und erweiterbaren

Kommunikationsorganisation, die einen dialogorientierten Informations-

und Datenaustausch zwischen den integrierten Systemkomponenten

ermöglicht. 6 Diese Forschungsergebnisse sind ausführlich in der Dissertation von F. Wölfle [2]

dokumentiert.

1 Einleitung 22

• Aufbau einer objektorientierten Methodenbank für hochbeanspruchte

Bauteile und Baugruppen, in der Berechnungs- und Bewertungswissen

in strukturierter Form nach dem ABC-Konzept abgelegt und verwaltet

wird, so dass eine dem Konkretisierungsgrad des Geometriemodells

angemessene Berechnung interaktiv durchführbar ist.

Zur Konkretisierung der oben genannten Ziele wurde eine Analyse der

Arbeitsabläufe zwischen Konstruktions- und Fachabteilungen in Groß-

unternehmen durchgeführt. Die dabei gewonnenen Kenntnisse dienten als

Basis für die Realisierung der Integration von Gestaltung und Berechnung

im rechnerunterstützten Konstruktionsprozess. Zur Realisierung der

Kommunikation zwischen den CAD- und Berechnungsprozessen wurde

eine Client-Server-Architektur auf Basis von TI-RPC (Transport

Independent-Remote Procedure Call) der Firma SUN entwickelt und im

Laufe des Vorhabens fortlaufend verbessert (siehe Bild 2, Abschnitt 1.2.3).

Mit TI-RPC stand zum Entwicklungszeitpunkt eine flexible Plattform für die

Entwicklung verteilter Applikationen zur Verfügung, die den gestellten

Anforderungen gerecht wurde.

Aus der Analyse der grundsätzlichen Arbeitsweisen eines gestaltenden und

berechnenden Konstrukteurs konnten sequentielle, parallele und

kooperative Arbeitsabläufe im rechnerunterstützten Konstruktionsprozess

festgestellt werden. Auf der Grundlage dieser Analyse und der bewährten

Matrixorganisation als Kommunikationsstruktur bei Großunternehmen

wurde das Kommunikationskonzept nach Bild 2 erweitert. Das neue

Kommunikationskonzept wurde so ausgelegt, dass mehrere Konstrukteure

mit mehreren Fachabteilungen entsprechend einer Matrixorganisation

miteinander kommunizieren konnten (Bild 5).


INTER NET

INTE

RNET

INT

ERN

ETW

A N

W A

N

CB

A

CB

A

Kompetenzzentrum

SC

HWINGUNGEN

CB

A

Kompetenzzentru

m

AKKUSTIK

LAN

(Int

rane

t)

Konstruktionsabteilung

ANTRIEBSTECHNIK

Kompetenzzentrum

FESTIGKEIT und LEBENSDAUER

Leic

htba

u-

kons

trukt

ion

LAN (Intranet)

Vorr

icht

ungs

-

kons

trukt

ion

CB

AServer

Man

ager

Methoden

Man

ager

Man

ager

Man

ager

EDM / PDMCAD

EDM / PDMCAD

CADEDM / PDM

Bild 5: Kommunikationsstruktur nach Matrixorganisation [Woe98]

Zur strukturierten Bereitstellung von Berechnungsmethoden der C-Ebene

in einer einheitlichen Softwareumgebung wurde eine objektorientierte

Methodenbank konzipiert und prototypisch realisiert. Dabei wurde

besonderer Wert auf eine flexible Einbindung einzelner externer

Berechnungsmethoden gelegt (Bild 6).

1 Einleitung 24

BM BM BMBM

BM BM BMBM

BM BM BMBMMethoden-

Geometrie

Bel

astu

ng

Material Constraints

Methodenpool

Interface

Met

hode

EMO

- I n

terf

ace

Wra

pper

Methoden-

Geometrie

Engi

neer

ing Meta Modell (EMM

)

Engineer ing Meta O b jects (EM

O)

Externe Informationen- Wissensbasen und Datenbanken -

Bewertung

Kommunikation

Bild 6: Architektur einer objektorientierten Methodenbank

Ein sogenannter „Wrapper“ isolierte einerseits die Berechnungsmethoden

von der Umgebung und versorgte diese andererseits mit den zur

Berechnung notwendigen Parametern. Eine Methodenbankschnittstelle

(EMO-Interface) interpretierte und verwaltete diese Parameter, die von

beliebiger Anzahl und beliebigem Typ sein konnten. Dies ermöglicht die

Integration und das Management von Berechnungsmethoden

unterschiedlicher Architektur auf optimale Weise in einer einheitlichen


Benutzungsumgebung. Aussagegüte und Zeitaufwand dieser erprobten

Berechnungsverfahren beruhen auf analytischen Formeln und deren

Kombination und sind damit der Methodenebene C nach Abschnitt 1.2.4

zuzuordnen.

Das Objektmodell (EMO) bildet dabei die zentrale Komponente der

Methodenbank und integriert die Parameter beteiligter Komponenten

(Geometrie-, Material- Belastungsparameter etc.) in einer einheitlichen

Darstellung. EMO bildet die Grundlage des Anwendungssystems, in

dessen Mittelpunkt ein Constraint-Solver steht. Der Solver ist ein integraler

Bestandteil des Objektmodells und hat somit direkten Zugang auf alle

Daten und Objekte. Durch Parameter-Wrapping wird es möglich,

Constraints zwischen Berechnungsparametern aus unterschiedlichen

Ressourcen zu definieren, die während der Berechnung vom Solver

ausgewertet werden.

Als Konstruktionsarbeitsplatz wird exemplarisch das CAD-System

Pro/Engineer eingesetzt. Zur Analyse und Bereitstellung der CAD-

Parameter wird die programmierbare Schnittstelle des CAD-Systems mit

Client- bzw. Server-Modulen vorgesehen. Damit wird eine bidirektionale

Kopplung der CAD- und Berechnungsparameter Modellparameter netzweit

möglich. Im Bild 7 sind am Beispiel einer Flanschkupplungsberechnung

aus dem CAD-System Pro/Engineer die grafischen Benutzungsoberflächen

der Methodenbank und der Einsatz des Constraint-Editors zur Verknüpfung

von CAD- und Berechnungsparametern bzw. zur Spezialisierung der

Berechnungsmethode dargestellt.

1 Einleitung 26

Bild 7: Einsatz der Methodenbank und des Constraint-Editors im

Konstruktionsprozess

Man erkennt, dass die Berechnungsmethode (CAE-Methode), gekenn-

zeichnet durch Mechanikmodell und Eingabe-Parameter, dem CAD-Modell

– bestehend aus CAD- Modelltopologie und CAD-Parameter – in Fenstern

gegenübergestellt wird. Über Constraints (Relationen) werden die

Berechnungsparameter mit den korrespondierenden CAD-Parametern

nacheinander verknüpft und in der Assoziationsliste angezeigt. Neben

einfacheren (1 zu 1)-Relationen können auch nahezu beliebige,

komplexere (1 zu n)-Relationen formuliert werden - siehe beispielsweise


den Wert des Parameters t unter Relation. Die formulierten Relationen

werden vom Constraint-Solver vor jedem Berechnungslauf ausgewertet.

Jede Relation wird semantisch und lexikographisch überprüft. Nur wenn

der Typ des errechneten Wertes auf der rechten Gleichungsseite mit dem

des Berechnungsparameters auf der linken Seite übereinstimmt, wird die

Verknüpfungsgleichung als zulässig erkannt und nur dann in die

Assoziationsliste eingetragen.

Eine weitere Aufgabe des Constraint-Solvers bestand in der Unterstützung

des Anwenders bei der Bewertung der Berechnungsergebnisse und deren

Rückkopplung mit dem CAD-Modell (Bild 8).

Bild 8: Einsatz des Constraint-Solvers zur Bewertung der Berechnungs-

ergebnisse und deren Rückkopplung mit dem CAD-Modell.

1 Einleitung 28

Hierzu kann der Anwender zwischen den Output-Parametern der

Berechnungsmethode (Bild 8, rechts im Bewertungsfenster) und den CAD-

Parametern (Bild 8, rechts im CAD-Fenster) beliebige Constraints

formulieren (Bild 8, links im Bewertungsfenster). Bild 8 zeigt beispielsweise

die Vorgabe des Mindestaußendurchmessers des Flansches (DA_min) aus

der CAD-Geometrie. Unterschreitet der berechnete Flanschaußen-

durchmesser (d_FA) diesen Wert, so wird „d_FA=DA_min“ gesetzt. Sind

alle Bewertungskriterien erfüllt, so kann der Anwender die gekoppelten

CAD-Parameter bzw. das CAD-Modell aktualisieren.

Die konkreten Zielsetzungen der Arbeiten im Fachgebiet Konstruktions-

lehre zur zweiten, wieder dreijährigen SPP-Phase bestimmen einen großen

Teil der Arbeiten zu dieser Dissertation. Sie werden deshalb in die

erweiterte Zielsetzung dieser Arbeit eingebaut. Eine wesentliche Neuerung

zur zweiten Phase des SPP ergab sich aus dem Einsatz von Java- und

Webtechnologien als Entwicklungsplattform. Die objektorientierten

Architektur der Programmiersprache Java sowie ihre Plattform-

unabhängigkeit haben die Entwicklungsgeschwindigkeiten positiv

beeinflusst. Zum Ausbau der Client-Server-Architekturen standen u. a.

Java-RMI (Remote Method Invocation [Rust97]) zur Verfügung. Weiterhin

konnten zur Entwicklung wiederverwendbarer Softwaremodule

(Softwarekomponenten) die Java-Beans [Rea98] eingesetzt.

Alle weiteren Forschungsthemen zum DFG-Schwerpunktprogramm der

ersten drei Jahren sind für interessierte Leser zusammen mit einigen

Ergebnissen dem Tagungsband zur VDI-Tagung „Verkürzte Entwicklungs-

prozesse durch Integration von Gestaltung und Berechnung“ zu entnehmen

[CAT99], der Einführungsvortrag zum SPP ist auch über das Internetportal

des DFG-SPP-Servers an unserem Fachgebiet [SPP] zu finden. Das

Internetportal bietet darüber hinaus einen Zugang zu den Forschungs-

aktivitäten der übrigen Forschungsinstitute zur zweiten Phase des SPP.

Man findet dort einen guten Überblick über den erreichten Stand der

Forschungen bis März 2002 mit Kurzberichten zu den Forschungsberichten

bzw. Veröffentlichungen der Schwerpunktsteilnehmer. Soweit in der


Dissertation auf Forschungsergebnissen aus dem SPP zurückgegriffen

wird, wird jeweils getrennt darauf hingewiesen.

1.3.2 Weiterführende Arbeiten

Parallel zum Ende des SPP startete eine weitere richtungweisende

Forschungsaktivität im Bereich der virtuellen Produktentwicklung - das

Projekt iViP (integrierte Virtuelle Produktentstehung) [Krau01]. Das im

Projekt iViP für alle Teilnehmer verbindliche Integrationskonzept

berücksichtigt nicht nur die globale Integration von unternehmenseigenen

Softwaresystemen, sondern auch die mit externen Kooperationspartnern.

Dabei wird ferner großer Wert auf das Prozess- bzw. Workflow-

Management gelegt, um komplexe Prozessketten in Unternehmen

unterstützen zu können. Sämtliche für Produktentstehung und alle

Folgephasen relevante Daten werden in einen sogenannten „Digitalen

Master“ abgelegt. Alle Softwareanwendungen werden in einer einheitlichen

Umgebung (iViP-Client) verwaltet und dem Anwender zur Verfügung

gestellt. Externe Anwender-Software kann über eine standardisierte

Schnittstelle (Plug-In) eingebunden werden [iViP]. Das

Kommunikationsprotokoll zwischen den Softwareanwendungen basiert auf

der von OMG(Object Management Group) definierten CORBA-Architektur

(Common Object Request Broker Architecture) [OMG].

Hinsichtlich der Integration von Berechnungen in den Konstruktionsprozess

wird im Projekt iViP überwiegend die Integration von FE-Systemen

adressiert. Ein Schwerpunkt liegt bei der automatisierten Gestalt- und

Topologieoptimierung von Bauteilen aus dem CAD-Modell heraus. Die

Integration der zugehörigen Berechnungsprogramme mit dem CAD-Modell

wird über problemangepasste topologisch fixierte Strukturmodelle auf Basis

von Funktions- bzw. Wirkprinzipien zur Unterstützung der frühen Phasen

des Produktentstehungsprozesses realisiert. Die Parameter verschiedener

Partialmodelle – z.B. aus dem CAD- und dem Werkstoffmodell – werden

über Beziehungen (Constraints) in Verbindung gebracht. Die

Konsistenzsicherung zwischen den Constraints wird mittels Constraint-

1 Einleitung 30

Checking bzw. Constraint-Solving durch Einsatz kommerzieller Software-

komponenten realisiert. Aussagegüte und Zeitaufwand dieser

Berechnungsverfahren beruhen auf linearen FEM-Berechnungen und sind

damit der Methodenebene B nach Abschnitt 1.2.4 zuzuordnen.

1.4 Zielsetzung - Aufbau der Arbeit

Vor der Formulierung der Ziele soll die bisher beschriebene übergeordnete

Problemstellung, in die die Arbeit eingebettet ist, zusammenfassend

beschrieben werden:

Die zunehmende Komplexität neuer, innovativer Produkte führt durch die

Beteiligung von Experten verschiedener Fachdisziplinen zu einer starken

Vernetzung konstruktiver Entwicklungsarbeit. Dies wird besonders in der

Phase der stofflich-geometrischen Gestaltung deutlich, die durch ein

Zusammenwirken von gestalterischen und rechnerischen Tätigkeiten

gekennzeichnet ist [Woe98]. Die Zusammenarbeit verschiedener, am

Produktentstehungsprozess beteiligten Konstrukteure und Entwicklungs-

ingenieure muss zur Erzielung eines angestrebten Produkterfolges zeit-

und qualitätsgerecht unter Beachtung der Wirtschaftlichkeit sichergestellt

werden. Dies führt heute zu einem Produktentstehungsprozess mit

überlappenden bzw. vernetzten Arbeitsschritten, die oftmals an

verschiedenen Standorten unter Zuhilfenahme unterschiedlicher Systeme

zur Produktgestaltung und Berechnung durchgeführt werden. Damit

verbunden ist eine Dezentralisierung von produktbeschreibenden Daten

und Informationen. In diesem Zusammenhang bekommt die Handhabung

verteilter produktbeschreibender Informationen einen neuen Stellenwert.

Bisher verfolgte Ansätze zur Gestaltung des Dateninformationsflusses

konzentrieren sich auf punktuelle Verbindungen zwischen verschieden-

artigen proprietären (herstellerspezifischen) IT-Applikationen für die

Gestaltung und Berechnung oder zielen darauf ab, einer Dezentralisierung

durch die Einführung eines zentralen, standardisierten Produktmodells

unter Anwendung erprobter Datenbanktechniken entgegenzuwirken.

1.4 Zielsetzung - Aufbau der Arbeit 31

Auf die genannten Schwachstellen haben die Entwickler von Systemen zur

Produktgestaltung reagiert, indem sie diese zu proprietären, dem

Entwicklungsprozess begleitenden Softwaresystemen erweitert haben. Auf

Basis von anwendungsbezogenen Produktmodellen verknüpfen diese

Systeme nicht nur einen großen Teil der Produktinformationen mit dem

CAD-Modell, sie verfügen darüber hinaus auch über eine Reihe von

Schnittstellen zu weiteren Softwaresystemen im Engineering-Bereich, z.B.

FEM- bzw. MKS-Systemen, Datenbanken, Management- und Work-Flow-

Systemen. Innerhalb der Produktfamilie eines Herstellers ist damit in ersten

Ansätzen die Möglichkeit geschaffen, auf mehrere Standorte und

Softwarewerkzeuge verteilte produktbezogene Daten und Informationen

einheitlich zu verwalten. Schwachstellen sind jedoch weiterhin in einer

integrierten Nutzbarkeit und in zu starren Schnittstellen zwischen den im

Produktentwicklungsprozess zur Anwendung kommenden Systemen und

IT-Werkzeugen zu erkennen.

Während die Entwicklungen bei den verschiedenen Systemen zur

Produktgestaltung durch eine Annäherung in Leistungsumfang und

Bedienbarkeit sowie der Tendenz zu offenen Systemen geprägt sind, stellt

sich die Situation auf der Berechnungsseite weniger übersichtlich dar.

Einerseits existieren für die Bearbeitung anfallender Berechnungen zur

Auslegung und zum Nachweis wichtiger Produkteigenschaften vielfältige

Berechnungs-, Simulations- und Optimierungsprogramme, die auf

Teilprobleme sehr gut zugeschnitten sein können, anderseits lassen diese

Programme nur selten eine allgemeine und integrierte Nutzbarkeit

erkennen. Bei komplexen Produkten führt dies zu langen Produktent-

wicklungszeiten, da viele Informationen noch nicht rechnerintegriert

ausgetauscht werden.

Der aktuelle Trend in der Produktentwicklung, eine durchgehende

Integration aller Softwaretools über alle Produktphasen von der

Produktidee über die Produktkonstruktion und Fertigung hin bis zum

Produktrecycling, im Hinblick auf ein optimales Datenmanagement

einzuführen, zwingt zum Umdenken. Dies erfordert u. a. tragfähige

1 Einleitung 32

Konzepte zur Entwicklung von Berechnungstools sowie deren Integration in

den Produktentwicklungsprozess, wozu die vorliegende Arbeit beitragen

will.

Ziel ist es, die vom Autor dieser Arbeit im Rahmen des DFG-

Schwerpunktprogramms (SPP) „Innovative, rechnerunterstützte

Konstruktionsprozesse – Integration von Gestaltung und Berechnung“

entwickelten Konzepte und Strategien einschließlich der erprobten

Realisierungen zur dargestellten übergeordneten Problemstellung zu

ordnen und zusammenfassend darzustellen. In die Arbeit werden

zusätzlich Entwicklungs- und Integrationskonzepte für Berechnungs-

verfahren mit flexibler Modellstruktur eingebunden, die vom Autor bei

Forschungs- und Entwicklungsarbeiten in der - aus dem Fachgebiet

Konstruktionslehre der TU Berlin ausgegründeten - Firma „Contecs

engineering services GmbH“ gewonnen und mit der Simulationsumgebung

des MKS-Programms SIMDRIVE3D erprobt wurden.

1.4.1 Gliederung der Arbeit

In Kapitel 2 werden zur Strukturierung der Arbeit vier charakteristische

Ordnungsgesichtspunkte für Berechnungsmethoden im Hinblick auf deren

Entwicklung sowie Integration in den Produktentwicklungsprozess

herausgestellt und die Berechnungsmethoden im Hinblick auf die

Systemeigenschaften (mit und ohne Rückwirkung), den Zeiteinfluss

(zeitunabhängig, zeitabhängig), die Modellstruktur (produktgebunden,

produktunabhängig), und deren Eignung für bidirektionale Koppelbarkeit

mit anderen Berechnungsmethoden (Methoden-Kopplungspotential)

klassifiziert. Hierzu werden die Berechnungsmethoden hinsichtlich ihrer

Komplexität bzw. Flexibilität analysiert und den softwaretechnischen

Möglichkeiten moderner Informationstechnik zugeordnet.

In Kapitel 3 wird auf die allgemein notwendigen Schritte zur Entwicklung

und Integration rechnerunterstützter Berechnungstools für den Einsatz im

Produktentwicklungsprozess eingegangen. Insbesondere werden dabei

1.4 Zielsetzung - Aufbau der Arbeit 33

theoretische Grundlagen zur Modellbildung und Integration von

Softwaretools beschrieben.

Kapitel 4 behandelt die Entwicklung und Integration produktabhängiger

Berechnungstools. Die Konzepte hierzu basieren in einem ersten Anlauf

auf der Web-Technologie. Neben webbasierten Berechnungstools wird

auch ein webbasiertes Berechnungsinformations- und Berechnungs-

assistenzsystem zur Informationsbeschaffung und Suche nach geeigneten

Berechnungsmethoden konzipiert und exemplarisch entwickelt. Eine

webbasierte Berechnungs-Methodenbank dient dabei zur Ausführung von

Berechnungen über einen Web-Browser. Anschließend wird anhand von

parametrisierten Berechnungsmethoden mit geringer Komplexität und

sequentiellem Berechnungsablauf gezeigt, dass die Konzepte zur

Entwicklung und Integration produktabhängiger Berechnungen – wegen

deren Parametrisierbarkeit – verallgemeinerbar sind. Aufbauend auf der

Dissertation von Wölfle [Woe98] werden erweiterte Konzepte und

Strategien vorgestellt, um Berechnungsparameter aller Art aus weltweit

verteilten Ressourcen in einer einheitlichen Form bereitzustellen bzw. zu

integrieren. Zusätzlich wird die in Bild 6 dargestellte objektorientierte

Methodenbank aus [Woe98] zur Integration verteilter Berechnungen bzw.

Berechnungsdaten ausgebaut.

In Kapitel 5 werden Konzepte zur Entwicklung und Integration von

produktklassenabhängigen Berechnungstools in den rechnerunterstützten

Produktentwicklungsprozess aufgegriffen. Dabei werden zeitabhängige

Berechnungsmethoden für dynamisch belastete Antriebselemente (MKS-

Modell für Zahnradgetriebe, Rädertriebe) betrachtet und im notwendigen

Umfang analysiert. Es wird gezeigt, dass die Integrationskonzepte für

MKS-Systemen sich nicht generell verallgemeinern lassen, da sie sich oft

auf spezielle Produkt- bzw. Modellklassen beziehen. Im letzten Abschnitt

des Kapitels wird schließlich die Kopplung von Berechnungsprozessen mit

zeitabhängigen nichtparametrisierbaren Modelldaten behandelt.

2 Analyse und Klassifikation von Berechnungen

Die Berechnungsverfahren in der Produktentwicklung haben eine große

Vielfalt an Daten und Strukturen. Sie weisen im allgemeinen individuelle,

oft heterogene, produktspezifische Abläufe auf, weswegen deren

systematische Entwicklung und Integration bis heute noch nicht vollständig

gelungen ist und abschließend auch nicht gelingen kann. Jeder nicht

standardisierte Berechnungsablauf enthält individuelle Berechnungsanteile.

Vor diesem Hintergrund erscheint es als notwendig, eine Klassifizierung

der in Forschung und Praxis eingesetzten Berechnungsverfahren

vorzunehmen, die es gestattet, Verfahren zur Entwicklung von

Berechnungs- und Bewertungsmethoden sowie deren Integration in den

Produktentwicklungsprozess unter Berücksichtigung informations-

technischer als auch technologischer Aspekte strategisch zu positionieren.

Diese Klassifizierung soll im weiteren Verlauf dieser Arbeit als

Strukturierungshilfe dienen. Anhand von praktischen Beispielen wird

gezeigt, dass die Vielfalt der möglichen Klassifikationen sowohl die

Entwicklung von Berechnungsprogrammen als auch deren Integration in

den Produktentwicklungsprozess unmittelbar beeinflusst.

2.1 Analyse der Systemeigenschaften

Bevor auf die einzelnen Klassifikationen näher eingegangen wird, sollen

grundsätzlich systemtechnische Überlegungen zur Systemstruktur

vorangestellt werden.

Die Entwicklung von Berechnungsmethoden zur Analyse technischer

Produkte erfordert in der Regel die Abstraktion bzw. Vereinfachung der

realen komplexen Produkte derart, dass eine Beschreibung ihrer

Eigenschaften mit Hilfe physikalischer Wirkprinzipien möglich ist. Zur

wissenschaftlichen Analyse und Modellierung der Produkte werden oft

auch die Prinzipien der Systemtechnik verwendet. Damit können komplexe

Produkte bzw. Prozesse je nach Bedarf in kleinere, einfacher


beschreibbare Teilprodukte oder Teilprozesse unterteilt werden, die über

Systemkopplungen miteinander in Verbindung stehen (Bild 9).

Subsystem 2ParameterZustände



KopplungenSystem-

EingängeSystem-

Ausgänge

Systemgrenze




KopplungenSystem-

EingängeSystem-

Ausgänge

Systemgrenze

Bild 9: Schematische Darstellung eines technischen Systems [Gip99].

Ein technisches System ist als Produkt ein komplexes „Ganzes“, das sich

aus mehreren, mehr oder weniger unterscheidbaren Bestandteilen

(Komponenten oder Subsystemen) zusammensetzt. Die Komponenten

eines Systems beeinflussen sich gegenseitig, - sie wirken aufeinander. Die

wechselseitigen Wirkungen können den momentanen Zustand der

Komponenten verändern. Der Gesamtzustand des Systems setzt sich

einerseits aus den Einzelzuständen seiner Komponenten und anderseits

aus Wechselwirkungen mit der Umgebung (über Systemgrenzen hinaus)

zusammen.

Die Komponenteneigenschaften eines Systems, seine Ein- bzw. Ausgänge

und seine inneren Kopplungen lassen sich in der Regel durch

Systemkenngrößen, auch Systemparameter genannt, beschreiben. Ein

System kann deshalb grundsätzlich durch seine Komponenten,

Kopplungen zwischen den Komponenten und seine Ein- und

Ausgangsgrößen beschrieben werden. Je nach Abstraktionsgrad können

für ein Produkt oder auch einen Prozess unterschiedliche Systemmodelle

2 Analyse und Klassifikation von Berechnungen 36

formuliert werden, die sich in Anzahl der Komponenten oder Kopplungen

oder Ein- und Ausgangsgrößen unterscheiden.

Oft wird vereinfachend versucht, statt des Gesamtsystemverhaltens, das

Verhalten einzelner Systemkomponenten bzw. Systembaugruppen

getrennt zu behandeln. Diese Vorgehensweise setzt allerdings voraus,

dass diese Systemkomponenten bzw. Systembaugruppen als quasi

rückwirkungsfrei betrachtet werden können, d. h. dass eine sich im Betrieb

durch Belastung verändernde Ausgangsgröße einer solchen Teilsystem-

komponente keinen rückwirkenden Einfluss auf die Eingangsgröße dieser

Komponente hat. Es soll bereits hier festgehalten werden, dass die

Komponenten dynamischer Systeme in der Regel nicht in allen

Betriebszuständen als rückwirkungsfrei angenommen werden dürfen!

Dagegen lassen sich viele statische Fragestellungen eventuell auf

rückwirkungsfreie Komponenten zurückführen. Sind die Teilsysteme als

rückwirkungsfrei annehmbar, so können die entsprechenden Teil-

berechnungen sequentiell ausgeführt werden (Bild 10). Je nach

Gesamtsystemstruktur können dann die Ergebnisse einer Teilberechnung

als Eingabedaten der nächsten Berechnung zur Verfügung stehen.

Teilberechnung 1

Berechnungs-Parameter

Teilberechnung 2 Teilberechnung

3

Gesamtberechnung

Berechnungs-Ergebnisse

Teilberechnung 1

Berechnungs-Parameter


3

Gesamtberechnung

Berechnungs-Ergebnisse

Bild 10: Berechnung und Analyse eines Systems durch sequentiellen

Einsatz mehrerer Teilberechnungen.


Bei dynamischen Systemen mit nicht-rückwirkungsfreien Komponenten ist

eine sequentielle Analyse der Teilsysteme nicht mehr alleine ausreichend,

das System muss als ein ganzes, unter Berücksichtigung der

Rückwirkungen zwischen seinen Komponenten untersucht werden. Je

nach Komplexität kommen bei der Analyse und Untersuchung solcher

Systeme abhängig von der erforderlichen Aussagegüte eine oder mehrere

Berechnungen zum Einsatz. Prinzipiell ist eine Unterteilung des

Gesamtsystems in immer feinere Systemkomponenten solange

erforderlich, bis sich alle relevanten Systemeigenschaften, z. B. alle

Eigenfrequenzen im vorgesehenen Betriebsbereich, mit ausreichender

Genauigkeit berechnen lassen. Hierzu wird das Systemverhalten

beispielsweise durch Aufstellen eines Differentialgleichungssystems für alle

Komponenten und seine zeitdiskreten Lösung näherungsweise

beschrieben (siehe auch Abschnitt 2.2). Besteht eine Systemkomponente

selbst aus weiteren Teilkomponenten, so sind diese auch als Komponenten

des Gesamtsystems zu berücksichtigen und in das Differentialgleichungs-

system aufzunehmen (Bild 11).

Eingangs-Daten

Ausgangs-Daten


3

Teilberechnung 1Eingangs-

DatenAusgangs-

Daten


3

Teilberechnung 1

Bild 11: Berechnung und Analyse eines Systems unter Berücksichtigung

der Rückwirkung zwischen den Systemkomponenten.


2.2 Klassifizierung nach zeitunabhängigen und zeitabhängigen Berechnungen

Wie bereits in Abschnitt 2.1 angedeutet, unterscheiden sich statische und

dynamische Berechnungen zum Teil erheblich voneinander. Bei statischen

Problemstellungen spielt die Zeit keine oder eine vernachlässigbare Rolle.

Die zugehörigen statischen Berechnungen sind deshalb unabhängig von

der Zeit, auch die im Berechnungsmodell benötigten Modellparameter

werden als konstant (zeitunabhängig) angenommen. Man bezeichnet

deshalb statische Berechnungen auch als zeitunabhängige Berechnungen.

Bei dynamischen Berechnungen mit determinierten äußeren Einflüssen

kommt zu den Berechnungsvariablen grundsätzlich noch die Zeit hinzu.

Alle im Berechnungsmodell vorkommenden Berechnungsdaten können

dann von der Zeit abhängen, beispielsweise die äußeren Belastungen oder

auch die Modellparameter. Die Berechnungsdaten sind dann, wenigstens

zum Teil, nicht konstant, d. h. zeitabhängig. Man spricht deshalb auch von

zeitabhängigen Berechnungen.

Deterministische zeitabhängige Einflüsse können periodisch oder

nichtperiodisch sein, sie lassen sich noch einteilen in harmonische und

allgemein periodische Einflüsse. Bei dynamischen Berechnungen mit

stochastischen, d. h. regellosen äußeren Einflüssen wird die Zeitvariable

durch mehrere Zufallsvariable ersetzt; hierauf wird in dieser Arbeit nicht

näher eingegangen.

Die im konkreten Fall einzusetzenden Berechnungsmethoden für

Aufgabenstellungen unterscheiden sich im allgemeinen erheblich

voneinander, da ihr Einsatz in entscheidendem Maße von der Komplexität

der Aufgabenstellung abhängt. Bei geringer Komplexität des

Berechnungsmodells strebt man im Konstruktionsprozess Berechnungs-

methoden mit analytischen, nicht diskreten Lösungsansätzen wegen ihrer

größeren Transparenz an, z.B. bei stabförmigen Bauteilen mit periodischer

Belastung. Komplexe zeitunabhängige und zeitabhängige Berechnungs-

verfahren erfordern den Einsatz höherwertiger Berechnungsmethoden, wie

2.3 Klassifizierung von Berechnungsverfahren nach Modellstruktur 39

beispielsweise Finite-Elemente-Methoden (FEM) bzw. Verfahren der

Mehrkörpersimulation (MKS). Die zu analysierenden Bauteile bzw.

Systeme sind hierzu i. a. zu diskretisieren, d. h. in geeignete diskret

berechenbare Teilkörper zu zerlegen und schließlich wieder mit Hilfe eines

Berechnungsalgorithmus zu einem Ganzen zusammenzusetzen. Die

diskreten Teilkörper einer bestimmten FE-Methode haben i. a. topologisch

die gleiche Struktur, bei Aufbau einer MKS-Struktur ist dagegen i. a.

zwischen Masse- und Feder-Teilkörpern (-Elementen) zu unterscheiden.

Die zu berechnenden Kenngrößen wie beispielsweise Spannungen,

Dehnungen, etc. bzw. Wege, Geschwindigkeiten, etc., sind bei

zeitunabhängigen Problemen Funktionen der unabhängigen Ortsvariablen,

bei zeitabhängigen Problemen kommt noch die Zeit als Variable hinzu.

2.3 Klassifizierung von Berechnungsverfahren nach Modellstruktur

Ein Modell ist eine Nachbildung oder ein Entwurf eines Gegenstandes oder

eines Prozesses, das nur die wichtigsten Eigenschaften des Vorbildes

erfasst [VDI99-1]. Durch geeignete Vereinfachungen können i. a. komplexe

Strukturen auf überschaubare, mathematisch leichter beschreibbare

Modelle oder leichter prüfbare Versuchs-Modelle für experimentelle

Untersuchungen reduziert werden. Berechnungsmodelle sind dann

vereinfachte Nachbildungen realer Produkte bzw. Prozesse auf Basis

naturwissenschaftlicher Erkenntnisse, um damit das Verhalten dieser

Produkte bzw. Prozesse mit Hilfe mathematischer Verfahren beschreiben

und analysieren zu können.

Die Vereinfachung (Reduktion) eines realen Produktes zu einem

Berechnungsmodell kann beispielsweise durch folgende Maßnahmen

erfolgen:

• Idealisierung der physikalischen Eigenschaften, z.B. durch

Linearisierung des Werkstoffgesetzes.

• Beschränkung der Bauteilgeometrie auf die Hauptabmessungen, z. B.

auf Balken mit konstantem Querschnitt.


• Idealisierungen der Bauteilbelastungen z.B. auf Punkt- oder linear

verteilte Streckenlasten.

• Klassifizierung der Umwelteinflüsse.

Für komplexe Baugruppen und Strukturen wird in der Regel eine

Diskretisierung des Modells in einfachere elementare Modelleinheiten

angestrebt. Mittels Verknüpfungselementen und unter Berücksichtigung

von Rand- und Übergangsbedingungen werden dann die diskreten

Modellelemente zu einem Gesamtmodell zusammengefügt.

Die Berechnungsverfahren auf Basis diskreter Modellelemente (z.B. FEM-

oder MKS-Elemente) zeichnen sich durch eine hohe Flexibilität und einen

großen Anwendungsbereich aus. Da die Modellstruktur des Gesamt-

modells bei diesen Berechnungsverfahren innerhalb gewisser Grenzen

relativ frei wählbar ist, nimmt die Modellvorbereitung zum Teil viel Zeit in

Anspruch. Berechnungsverfahren mit einem produktnahen, standard-

isierten Berechnungsmodell erfordern hingegen weniger Modellierungs-

aufwand.

Im Bild 12 sind die sich hieraus i. a. ergebenden Zusammenhänge

zwischen Berechnungsmethoden und Modellstruktur bzw. Modellierungs-

aufwand dargestellt. Berechnungsmethoden, die sich auf die Auslegung

eines bestimmten, beispielsweise geometrisch parametrisierten Produktes

oder einer ähnlich aufgebauten Produktklasse beziehen, sind in der Regel

schneller einsetzbar, da deren Berechnungsmodelle bzw. Berechnungs-

abläufe mehr oder weniger starr programmiert werden können. Solche

Methoden lassen jedoch wenig Flexibilität zu bzw. bieten nur geringe

Anpassungsmöglichkeit. Demgegenüber bieten generische Berechnungs-

methoden grundsätzlich eine höhere Flexibilität bei der Modellbildung an,

weswegen diese bei der konkreten Auslegung neuer Produkte zunehmend

an Bedeutung gewinnen. Die mit FEM behandelbaren Aufgabenstellungen

kommen aus ganz unterschiedlichen Bereichen, beispielsweise aus dem

Maschinenbau, dem Flugzeug- und dem Schiffsbau [Me95].


Ebenso wie bei der Modellvorbereitung erfordern auch die notwendigen

Bewertungen zu Neuprodukten mehr Aufwand, weil hier in der Regel kein

unmittelbares Berechnungs-Know-how und Erfahrungswissen vorhanden

ist. Dieser Bewertungsaufwand nimmt erst dann ab, wenn man die

Erfahrungen aus früheren Berechnungen für ähnliche Produkte einbinden

und gewisse produktabhängige Modellspezifikationen einführen kann.

(FEM, MKS, …)

(Schrauben-, Welle-Nabe-Verb, …)

(Ringscheibenkup, Verdichter, …)

Produktunabhängige Berechnungsmethoden

ProduktklassenabhängigeBerechnungsmethoden

ProduktabhängigeBerechnungsmethoden

Modellstruktur

Prod

uktu

nabh

ängi

g

Modellieru

ngsau

fwan

dPr

oduk

tgeb

unde

n

niedrig

hoch

Bild 12: Zusammenhänge zwischen Berechnungsmethoden und Modell-

struktur bzw. Modellierungsaufwand

2.4 Klassifizierung von Berechnungsmethoden nach ihrem Kopplungspotential

Die Bezeichnung „Kopplungspotential“ dient in dieser Arbeit zur

Kennzeichnung der unterschiedlichen Integrierbarkeit von Berechnungs-

methoden und -programmen in die Softwareumgebung von Produkten-

twicklungsprozessen. Die Bezeichnung Kopplungspotential ist zu verstehen


als Maß für das Vorhandensein von offenen Schnittstellen mit

standardisierten Ein- und Ausgabeformaten sowie für die Möglichkeit, den

Ablauf der Berechnungsprogramme automatisiert steuern zu können (Bild

13). Dabei wird nicht nur die Berechnungs-Vorbereitung und -Ausführung,

sondern auch die unmittelbare Bewertbarkeit der Berechnungsergebnisse

durch bidirektionale Kopplung der Berechnungs- und Bewertungs-

programme berücksichtigt. Das bidirektionale Kopplungspotential wird mit

den Attributen „gering“, „mittel“, „hoch“ und „100%ig“ gekennzeichnet

Bild 13: Bidirektionales Kopplungspotential der Berechnungsmethoden

Eine informationstechnische Analyse der ABC-Methoden zeigt, dass die

Informationsmenge und Informationsqualität von der C- zur A-Ebene rasch


zunimmt. Während zum Ausführen von Berechnungsmethoden aus der C-

Ebene – wegen deren Produktabhängigkeit - meist eine geringe Anzahl

von Eingabe-Parametern ausreicht, werden bei den Methoden der B- oder

A-Ebenen, z.B. bei FE-Berechnungen, große Parameteranzahlen

notwendig. Erschwerend kommt hinzu, dass die Anwendung von B- oder

A-Methoden in der Regel nicht algorithmisiertes Erfahrungswissen, z.B. zur

Bewertung von MKS-Ergebnisse, benötigt.

Eine 100%ige bidirektionale Kopplung ist i. a. nur für Berechnungs-

methoden der Ebene C gesichert. Dies hängt vor allem damit zusammen,

dass die Berechnungsmodelle der C-Ebene in der Regel für bekannte

Baugruppen konzipiert werden, damit der Anwender mit einer geringen

Anzahl von Parametern arbeiten und ohne großen Aufwand das

Berechnungsmodell anpassen kann. Dies gilt auch für unternehmens-

spezifische (C aus A)-Methoden, die auf unternehmenseigenem Know-how

basieren und ausschließlich für konkrete Produktgruppen mit geringer

Variationsmöglichkeit, konzipiert werden.

Ein 100%iges bidirektionales Kopplungspotential ist i. a. auch für

Auslegungsberechnungen mit Faustformeln oder Produktkennwerten

erreichbar, wenn bereits parametrisierte geometrische Produktmodelle

vorliegen. Ist dies in den frühen Phasen des Konstruktionsprozesses,

insbesondere bei Neukonstruktionen noch nicht gegeben, muss interaktiv

vom Konstrukteur eingegriffen werden. Deshalb wird für Auslegungs-

berechnungen lediglich das bidirektionale Kopplungspotential mit „hoch“

eingestuft.

Zur Analyse völlig neuer Produkte ist eine solche bidirektionale

Vorgehensweise, insbesondere in den späteren Phasen des Konstruktions-

prozesses, in denen es zunehmend auf hohe Aussagegüte und

Produktoptimierung ankommt, i. a nicht ohne Einschränkung möglich. Der

Einsatz generischer Berechnungsverfahren wie FEM tritt in diesen

Konstruktionsphasen zunehmend in den Vordergrund. Generische

Berechnungsmethoden sind aufgrund ihrer i. a. elementaren Modellstruktur


zwar flexibel im Einsatz, erfordern aber ein höheres Fachwissen und mehr

Zeit zur Modellbildung.

Eine bidirektionale Kopplung zwischen Gestaltung und Berechnungen

gelingt noch bei einfacheren Bauteilen mit überschaubaren Belastungen,

bei komplizierten Bauteilen mit Komplex-Beanspruchung sind Eingriffe

durch den Konstrukteur und erfahrene Berechnungsexperten bei

konkurrierenden Anforderungen unvermeidlich. Je höher die Ansprüche an

die Aussagegüte werden, umso geringer ist i. a. das Kopplungspotential

einzuschätzen. Für Aussagegüten, die der B-Ebene bzw. der A-Ebene

zuzuordnen sind, sind deshalb die bidirektionalen Kopplungspotentiale im

Mittel als „mittel“, bzw. „gering“ anzusehen!

3 Allgemeines zur Entwicklung und Integration rechnerunterstützter Berechnungstools

Die informationstechnische Umsetzung von Berechnungsverfahren lehnt

sich grundsätzlich an das zugrunde liegende Berechnungsmodell an.

Neben der rechnerinternen Abbildung des Berechnungsmodells ist die

widerspruchsfreie Implementierung des Lösungsweges erforderlich, so

dass eine deterministische7 Durchführung von Berechnungen gewährleistet

ist. Die erforderlichen Arbeitsschritte - von Problemdefinition bis zur

Implementierung bzw. Integration - laufen in der Regel iterativ ab.

Oft sind zur Entwicklung eines schnellen und hinreichend genauen

Lösungsweges zusätzliche Annahmen bezüglich der Modellbildung und

des Berechnungsalgorithmus notwendig, deren Einführung spezielles

Berechnungsfachwissen erfordert. Aus diesem Grund sind meist zur

Entwicklung komplexer Berechnungstools Spezialisten unterschiedlicher

Fachdisziplinen notwendig, um alle berechnungstechnischen, aber auch

informationstechnischen Anforderungen zu erfüllen.

Der Begriff „Berechnungstool“ wird in dieser Arbeit für ein

Softwareprogramm zur vollständigen Ausführung einer Berechnung, von

der Modellerstellung bis zur Bewertung verwendet. Darin sind auch alle

erforderlichen Komponenten, z. B. grafische Oberflächen für die Ein- und

Ausgaben sowie Schnittstellen zur externen Kommunikation

eingeschlossen.

Berechnungstools für die industrielle Praxis basieren auf einer großen

Vielfalt an Daten und Strukturen. Sie weisen i. a. individuelle, meist

heterogene Ablaufstrukturen auf, weswegen deren Integrationsprobleme

bis heute noch nicht ausreichend gelöst sind. Die Forschungsaktivitäten auf

diesem Gebiet betreffen sowohl Integrationsstrategien innerhalb einer

konkreten einheitlichen Softwareumgebung als auch solche zwischen

7 Deterministische Berechnungsmethoden produzieren bei gleichen Eingabedaten – unter

Berücksichtigung zulässiger Abweichtoleranzen - gleiche Ergebnisse [Küm99].

3 Allgemeines zur Entwicklung und Integration rechnerunterstützter Berechnungstools 46

heterogenen Softwaresystemen. Im ersten Fall handelt es sich um die

Integration spezieller – in der Regel komplexer - Berechnungsverfahren

unter Einsatz bekannter Softwaresysteme. Als Beispiel wäre die Kopplung

unternehmenseigener Berechnungsprogramme mit dem im Unternehmen

eingesetzten CAD-System über dessen programmierbare Schnittstelle zu

nennen. Solche Integrationsstrategien zielen meist nur auf aktuell

vorliegende Probleme und sind auf andere Programmsysteme mitunter

schwer übertragbar.

Mit der Entwicklung umfassender Integrationskonzepte für heterogene

Softwaresysteme wird zunehmend eine globale Integration aller beteiligten

Software-Systeme in einer übergeordneten einheitlichen Software-

umgebung angestrebt. Die bisher dabei behandelten Berechnungs-

programme weisen allerdings in den meisten Fällen eine geringe

Komplexität auf. Eine Verkettung mehrerer Berechnungsprogramme zur

Durchführung sequentieller oder auch iterativer Berechnungen wird in der

Regel noch nicht angestrebt.

3.1 Analyse der Arbeitschritte zur Entwicklung von Berechnungstools

Eine allgemeine Vorgehensweise bei der Entwicklung von Berechnungs-

tools ist im Bild 14 - exemplarisch zur Auslegung von Ringscheiben-

kupplungen - dargestellt. Ausgangspunkt der Entwicklung ist die

Aufgabenbeschreibung aus Benutzersicht in Form eines Pflichtenhefts.

Dabei werden alle Anforderungen hinsichtlich der Qualität der Berechnung,

Struktur und Aufbau der Benutzeroberflächen sowie der erforderlichen

datentechnischen Schnittstellen zu anderen Ressourcen festgelegt. Aus

dem Pflichtenheft wird in der Regel nach einer ausführlichen Analyse eine

technisch-wissenschaftliche Aufgabenstellung entwickelt. Hier werden die

Benutzeranforderungen hinsichtlich ihrer Realisierbarkeit überprüft und

mögliche Strategien festgelegt. Bei Bedarf werden bestimmte

Anforderungen nach Absprache mit dem Auftragsgeber geändert bzw.

erweitert.

3.1 Analyse der Arbeitschritte zur Entwicklung von Berechnungstools 47

Bild 14: Allgemeine Vorgehensweise bei der Entwicklung eines

Berechnungstools


Die notwendigen Arbeitschritte können wie folgt gegliedert werden:

• Technisch-wissenschaftliche Aufgabenstellung

• Idealisierung, Einführung von Modellannahmen

• Physikalisch-Mathematische Modellbildung

• Suche nach algorithmisierbaren Lösungsverfahren bzw.

• Konstruktion eines eindeutigen Lösungsverfahrens

• Implementierung des Berechnungsmodells und des dazugehörige

Lösungsverfahrens im Rechner

• Entwicklung aller erforderlichen Schnittstellen zur Einbindung externer

Ressourcen in den Berechnungsprozess sowie zur Weiterverarbeitung

und Bewertung der Berechnungsergebnissen

• Entwicklung von graphisch interaktiven Oberflächen, um den Anwender

bei der Modellbildung und Durchführung von Berechnungen und

Bewertungen zu unterstützen

Der Aufwand bei der Durchführung der beschriebenen Arbeitschritte richtet

sich vorwiegend nach dem vorgesehenen Berechnungsmodell und den

zugehörigen freien Parametern. Produktspezifisch parametrisierte

Berechnungsmodelle erfordern, wegen der im allgemeinen geringen

Anzahl von freien Parametern, einen geringeren Entwicklungsaufwand als

flexibel einsetzbare Berechnungsmodelle mit diskret veränderlichen

Teilmodellen. Zur Verdeutlichung werden später in der Arbeit die

Konzipierung und Realisierung von Berechnungstools für produktabhängig

parametrisierte Berechnungsmodelle - am Beispiel eines webbasierten

Berechnungsprogramms zur Auslegung von Schraubenverbindungen - und

modelldiskrete produktklassenabhängige Berechnungsmodelle – am

Beispiel eines Programms zur Auslegung von Rädertrieben für ein

konkretes MKS-Systems - vorgestellt. Es wird dort gezeigt, dass sich die

Konzepte zur Entwicklung und Integration von produktabhängigen

parametrisierten Berechnungsmodellen verallgemeinern lassen, während


die Konzepte zur Entwicklung von modelldiskreten produktklassen-

abhängigen Berechnungen von der Struktur und dem Aufbau der zugrunde

liegenden MKS-Umgebung abhängig sind.

Die Arbeitschritte Modellbildung und Implementierung bzw. Integration sind

für die Qualität und Zuverlässigkeit des Berechnungstools von

entscheidender Bedeutung, weswegen hier näher darauf eingegangen

wird.

3.1.1 Arbeitsschritt: Modellbildung

In der VDI 2211 wird die Modellbildung in drei Hauptschritten

Modellplanung, Modellentwurf und Modellkontrolle unterteilt.

3.1.1.1 Modellplanung

In der Planungsphase wird die Aufgabenstellung aus physikalischer Sicht

neu formuliert. Unter Berücksichtigung zulässiger Vereinfachungen (z.B.

Vernachlässigung von Details, dynamischen Lasten, etc.) werden die zu

berechnenden Parameter und Größen definiert. Anschließend werden

unter Berücksichtigung einer geforderten Aussagegüte, die einzuhaltenden

Grenzwerte sowie die Sicherheitsfaktoren festgelegt. Auf Basis dieser

Modelldefinition wird anschließend ein dem Original adäquates

Berechnungsmodell konzipiert, das alle relevanten Parameter

berücksichtigt: Oft setzt sich das Gesamtmodell aus mehreren kleineren

Teilmodelle zusammen. Die Systemgrenze für das Modell muss so gewählt

werden, dass die Wechselwirkung des Systems mit der Umgebung -

bezogen auf die zu berechnenden Phänomene - ausreichend genau

beschrieben und das Modell mit vertretbarem Aufwand berechnet werden

kann. Auch die ausgewählte Berechnungsmethode muss zu dem

gewählten Modell passen, da Berechnungsmodell und Berechnungs-

methode voneinander abhängig sind. Die Wahl der Berechnungsmethode

richtet sich nach der geforderten Genauigkeit, Aussagegüte und

Rechenaufwand (siehe auch ABC-Konzept).


3.1.1.2 Modellentwurf

Passend zur jeweiligen Berechnungsmethode und den dazugehörigen

Teilmodellen muss das zu untersuchende Gesamtsystem in Teilsysteme

zerlegt werden, die in ihren Eigenschaften und ihren Wechselbeziehungen

untereinander unter Berücksichtigung der Systemumgebung beschreibbar

sind. Jedes Teilsystem muss in seinen Eigenschaften und seinen

Wechselwirkungen zu anderen Teilsystemen und zur Systemumgebung

durch eindeutige Gesetzmäßigkeiten beschrieben werden. Dabei können

die Eigenschaften sowohl physikalische Gesetzmäßigkeiten als auch

empirische Näherungen („black-box“-Teilsysteme) sein.

3.1.1.3 Modellkontrolle

Jedes Berechnungsmodell stellt nur eine mehr oder weniger gute

Näherung des realen Systems dar. Daher muss nach dem Entwurf des

Modells geprüft werden, ob die getroffenen Modellannahmen die Realität

hinreichend genau nachbilden. Hierzu gehören neben Plausibilitäts-

betrachtungen auch Vergleiche mit vorhandenen Messwerten sowie

Vergleiche mit ähnlichen Berechnungen dazu.

3.1.2 Arbeitsschritt Implementierung und Integration

In der Phase der Implementierung steht neben der programmier-

technischen Umsetzung der Berechnungsmethode auch die Entwicklung

graphisch interaktiver Oberflächen zur Unterstützung des Anwenders bei

der Modellkonfiguration sowie der Durchführung von Berechnungen und

Bewertungen im Mittelpunkt. Während der gesamten Entwicklung sind

auch die Integrationsaspekte zur Daten-, Prozess- und

Programmintegration zu berücksichtigen. Je nach Bedarf wird die

Entwicklung verschiedener Schnittstellen zur Einbindung externer

Ressourcen in den Berechnungsprozess erforderlich. Zum besseren

Verständnis der Integrationskonzepte in dieser Arbeit werden im folgenden

einige allgemeine Formen der Datenintegration vorgestellt.


3.1.3 Allgemeine Formen der Datenintegration

Zur rechnergestützten, virtuellen Beschreibung technischer Produkte

werden diesen im Laufe ihrer Entwicklung - von der Produktidee über die

Realisierung bis zur Entsorgung - verschiedene Modellbeschreibungen

zugeordnet, die jeweils als „rechnerinternes Datenmodell“ oder kurz

„Datenmodell“ bezeichnet werden. Ein konkretes CAD-Datenmodell

repräsentiert beispielsweise geometrische Eigenschaften des Produktes zu

einem konkreten Zeitpunkt. Komplexe Datenmodelle wie beispielsweise

Berechnungs-Datenmodelle setzen sich aus kleineren Einheiten wie

Werkstoff-Datenmodellen, Belastungs-Datenmodellen, Geometrie-

Datenmodellen, etc. zusammen.

Die zur Beschreibung technischer Produkte eingesetzten vielfältigen

Datenmodelle haben oft gemeinsame Eigenschaften bzw. Parameter, die

zu Redundanzen führen können. So müssen die Geometrie- und

Materialdaten beim Einsatz einer Recyclingplanungssoftware wiederholt

eingegeben werden, falls eine direkte Kopplung mit dem CAD- bzw. der

Materialdatenbank nicht vorhanden ist. Es ist offensichtlich, dass die

Integrierbarkeit von Softwaresystemen in die Produktentwicklung mit dem

Grad der Überdeckung bzw. Kompatibilität ihrer rechnerinternen

Datenmodelle zusammenhängt.

Eine Integration von Softwaresystemen ist grundsätzlich dann möglich,

wenn entweder alle beteiligten Softwaresysteme auf demselben

Datenmodell basieren (Integration) oder die Möglichkeit besteht, die

Datenmodelle bidirektional ineinander abzubilden bzw. zu konvertieren

(Kopplung)8. Im folgenden werden die aus der Informationstechnik

bekannten Formen der Softwareintegration bzw. -kopplung exemplarisch

für zwei zu verbindende Softwaresysteme beschrieben. In der Praxis –

8 Die Begriffe Integration und Kopplung werden in der Praxis nicht präzise getrennt. Oft liegt

eine Mischform vor; d.h. einige Systeme sind integriert und greifen auf gemeinsame Daten und

Funktionen zu, während andere gekoppelt sind.


besonderes bei mehreren Softwaresystemen – können Integration und

Kopplung nebeneinander auftreten.

3.1.3.1 Integriertes System

Benutzen die gekoppelten Softwaresysteme dasselbe rechnerinterne

Datenmodell, so liegt ein „Integriertes Softwaresystem“ vor (Bild 15). Jede

Änderung, die über eines der Softwaresysteme im Datenmodell

vorgenommen wird, ist unmittelbar im anderen System sichtbar, wenn die

Kommunikation bidirektional erfolgen kann. Ein Parallelbetrieb der beiden

Softwaresysteme ist in der Regel nicht möglich.

Bild 15: Integriertes Softwaresystem

Ein Beispiel für eine solche Integration ist die in viele CAD-Systeme

integrierte Programmierumgebung zur Formulierung und Bearbeitung von

Constraints und Relations sowie zur Variantenverwaltung. Um

Dateninkonsistenz zu vermeiden, muss eine Verträglichkeitsprüfung vor

jeder verbindlichen Parameteränderung in den beteiligten Systemen

durchgeführt werden.


3.1.3.2 Direkte Kopplung

Eine „Direkte Kopplung“ liegt vor, wenn die Daten eines Systems direkt in

das Datenformat des anderen Softwaresystems konvertiert werden können

und umgekehrt (Bild 16).

RechnerinternesDatenmodell

1


2

Software-System

2

P12

P21

Software-System

1

Bild 16: Direkt gekoppelte Softwaresysteme

Abhängig von Übereinstimmungsgrad der Datenmodelle und der Qualität

des Kopplungsprotokolls entstehen mehr oder weniger Datenverluste. Ein

bidirektionaler Modellaustausch ist deswegen nur in Umfang des

gemeinsamen Teilmodells möglich. Diese Art der Integration nutzen

beispielsweise die meisten CAD-Systeme mit einem integrierten FE-

Programm. So werden aus dem CAD-Modell nur die relevanten

Geometriedaten - z.B. das Drahtmodell - in das FE-System importiert,

während beispielsweise reine NC-relevante Daten unterdrückt werden. Ein

besonderer Vorteil dieses Verfahrens ist, dass jedes der beteiligten

Softwaresysteme sein Modell über das gemeinsame Modell hinaus beliebig

erweitern kann. Werden allerdings Änderungen vorgenommen, die das

gemeinsame Modell betreffen, so muss auch das Kopplungsprotokoll

aktualisiert werden. Ein weiterer Nachteil ist, dass bei der Kopplung


mehrerer Softwaresysteme jeweils ein Kopplungsprotokoll pro Systempaar

erforderlich ist.

3.1.3.3 Indirekte Kopplung

Bei indirekter Kopplung tauschen alle beteiligten Softwaresysteme auf

Basis eines gemeinsamen Datenmodells Daten aus. Dabei werden die

Daten eines der Systeme zuerst über ein entsprechendes

Kopplungsprotokoll in ein Gemeinsames Neutrales Datenformat und dann

wiederum in das Datenformat des zweiten Systems konvertiert (Bild 17).

Der größte Vorteil dieser Art der Kopplung gegenüber direkter Kopplung ist,

dass jedes Softwaresystem über ein einziges Kopplungsprotokoll mit

mehreren Softwaresystemen Daten austauschen kann. Ein Beispiel wäre

der Geometrieaustausch zwischen verschiedenen CAD-Systemen auf

Basis des standardisierten Datenformats IGES (Initial Graphics Exchange

Specification).

Gemeinsames NeutralesDatenmodell


1


2

Software-System

2

P1NPN2 PN1P2N

Software-System

1

Bild 17: Indirekt gekoppelte Softwaresysteme


Die meisten standardisierten Datenformate sind zum Austausch

bestimmter Klassen von Daten wie beispielsweise Geometriedaten

entwickelt worden. Wegen unterschiedlicher Modellphilosophien bei den

meisten Systemen gehen in der Regel wertvolle Informationen – wie

beispielsweise die Parametrisierung des CAD-Modells beim Daten-

austausch über IGES – verloren.

4 Entwicklung und Integration produktabhängiger Berech-nungstools

Wie oben ausgeführt, sind Berechnungsmethoden, die sich auf die

Auslegung eines bestimmten, geometrisch parametrisierbaren Produktes,

in der Regel schneller einsetzbar als produktklassenabhängige oder

produktunabhängige Berechnungsprogramme. Produktabhängige

Berechnungsmethoden beziehen sich i. a, auf einfache Bauteile oder

Baugruppen eines technischen Systems. Derartige Berechnungen sind

charakteristisch für spezielle Auslegungsberechnungen, auch für

Festigkeitsnachweise. Bei der Ausführung solcher Berechnungen müssen

aber die auf das Bauteil oder die Baugruppe wirkenden Kräfte und

Momente vorab bekannt sein. Zur Abschätzung dieser Belastungen haben

sich in der Praxis sog. produktabhängige Betriebsfaktoren bewährt, die sich

auf den im allgemeinen bekannten Normalbetrieb von Aggregaten

beziehen. Vorausgesetzt wird hierbei stets, dass sich keine

Resonanzstellen des Aggregats im vorgesehenen Betriebsbereich befinden

und damit die dynamischen Wechselwirkungen zwischen den

Komponenten des Systems im Erfahrungsbereich bleiben. Man geht

gleichsam davon aus, dass im Betriebsbereich die Systemkomponenten

als rückwirkungsfrei betrachtet werden dürfen! (siehe Abschnitt 2.1). Es soll

hier erwähnt werden, dass für solche oder ähnliche Aufgaben auch sog.

Neuronale Netze zum Einsatz kommen können, die produktabhängig

trainiert werden müssen [Krau97][Krau-SPP]. Hierauf soll hier nicht näher

eingegangen werden.

Das zu entwickelnde Berechnungsmodell zur Analyse einer speziellen

Produktkomponente (Bauteil oder Baugruppe) wird dann soweit spezifiziert,

dass es nur noch eine überschaubare Anzahl an Eingabeparametern zur

Anpassung benötigt. Die hierbei entstehende produktabhängige

Berechnungsmethode ist dann in der Regel nicht verallgemeinerbar und

beschreibt das Verhalten des jeweiligen Teilprodukts lediglich in einer

fiktiven Systemumgebung.

57

Die Entwicklung solcher parametrisierten produktabhängigen

Berechnungsmodelle ist in der Regel dann möglich, wenn

• die Betriebslasten einschließlich der Betriebsfaktoren als bekannt

angenommen werden können,

• das zu berechnende Produkt eine weitgehend einfache Geometrie

besitzt,

• die Verbindung zu anderen Systemkomponenten im Anwendungs-

bereich als rückwirkungsfrei betrachtet werden kann.

Im Hinblick auf schnelle und genaue Berechnungsmethoden – (C aus B)-

und (C aus A)-Methoden - ist es vorteilhaft, wenn das zugrunde gelegte

Berechnungsmodell soweit vereinfachbar ist, dass es mittels einfacher

analytischer Lösungsansätze oder Näherungsgleichungen beschreibbar ist.

Die Ausführung solcher Berechnungen kann wesentlich in folgenden

Schritten zusammengefasst werden:

• Aufruf des Berechnungsprogramms

• Eingabe der Modell- bzw. Berechungsparameter

• Durchführung der Berechung

• Ergebnisanalyse bzw. Bewertung

Die Anwenderschnittstelle des Berechnungstools erstreckt sich je nach

Entwicklungsstand von X-Terminal-Anwendungen bis zu dynamischen

Eingabemasken. Die Berechnungsparameter werden entweder vom

Anwender manuell – z.B. über Eingabemasken - oder durch Kopplung mit

Parametern aus anderen Ressourcen – z.B. aus anderen Berechnungen

oder aus Datenbanken – in die jeweilige Berechnungsumgebung

eingeführt.

Als Entwicklungsplattform hat sich in den letzten Jahren die

Webtechnologie besonderes stark durchgesetzt. So stellt die

Zulieferindustrie beispielsweise ihren Kunden zunehmend webbasierte

Berechnungsformulare zur Verfügung, die eine schnelle Vorauslegung von

4 Entwicklung und Integration produktabhängiger Berechnungstools 58

Komponenten ermöglichen. Der Kunde hat damit immer Zugang zu den

aktuellsten Produktdaten und Berechnungsverfahren, wenngleich das

Produkt-Know-how im Unternehmen bleibt.

Wegen ihrer großen Flexibilität und leichten Erlernbarkeit wird die Web-

Technologie auch im Intranetbereich von Unternehmen intensiv eingesetzt.

Dort sind zahlreiche - historisch gewachsene – Berechnungsprogramme

vorhanden, die zwar eine geringe Flexibilität besitzen, aber die

physikalischen Eigenschaften hauseigener Produkte sehr gut abbilden und

zu deren Ausführung geringe Mengen an Parametern erforderlich sind.

Mittels Web-Technologie können diese Berechnungsmethoden - mit

interaktiven Oberflächen und ausführlichen Dokumentationen - allen

Abteilungen zur Verfügung gestellt werden. Auch die Verwaltung und

Strukturierung von Berechnungen kann mit Hilfe der Webtechnologie

optimal unterstützt werden.

Um die Leistungsfähigkeit bzw. Zuverlässigkeit der Webtechnologie bei der

Verwaltung bzw. Durchführung von Berechnungen zu erproben, wurde am

Institut für Konstruktion, Mikro- und Medizintechnik der TU-Berlin, FG

Konstruktionslehre eine webbasierte Berechnungsplattform zur Auslegung

von Maschinenelementen entwickelt und mit Studenten erprobt. Die

Berechnungsplattform enthält zwei Hauptkomponenten:

• Berechnungsinformations- und Berechnungsassistenzsystem

zur netzweiten Informationsbeschaffung und Suche nach geeigneten

Berechnungsmethoden und.

• Webbasierte Berechnungsmethodenbank

zur Ausführung von Berechnungen über einen Web-Browser.

4.1 Entwicklung eines webbasierten Berechnungsinformations- und -assistenzsystems

Vor jeder Berechnung ist in der Regel eine mehr oder weniger ausgeprägte

Phase der Informationsbeschaffung erforderlich. Diese Phase dauert umso

länger, je weniger der Benutzer mit den relevanten Berechnungskriterien

vertraut ist. Bild 18 zeigt das Konzept eines webbasierten Informations-

und Assistenzsystems, mit dessen Hilfe ein interessierter Benutzer durch

Fragen und geführtes Auswählen stufenweise zu einer für das vorliegende

Problem geeigneten Berechnungsmethode gelenkt wird. Jede neu

entwickelte Berechnung muss zuerst natürlich in der web-basierten

Datenbank registriert werden (Arbeitschritt I1 im Bild 18).

Neben klassischen Angaben wie Methodenbezeichnung und

Kurzbeschreibung können beim Registrieren auch stichwortartige

Merkmale angegeben werden, die bei der Suche einbezogen werden

können. Beispielsweise bei einem Schraubenberechnungsprogramm die

Suchwörter „Schraubenberechnung(en)“ „Schraubenverbindung(en)“,

„Schraube(en) etc. (Arbeitsschritt A1 im Bild 18).

Die ausführliche webbasierte Dokumentation der Berechnungsmethode

wird in einer Dokumentationsdatenbank mit eigenem Web-Server abgelegt

(Arbeitsschritt I2 im Bild 18). Die dazugehörige Adresse wird entsprechend

in die web-basierter Datenbank eingetragen und kann beim Bedarf vom

Anwender aufgerufen werden (Arbeitsschritt A2 im Bild 18). Hat der

Anwender die passende Berechnungsmethode gefunden so kann er diese

direkt aus der webbasierten Methodenbank aufrufen (Arbeitschritt A3 im

Bild 18).


Bild 18: Architektur des Berechnungsinformations- und Berechnungs-

assistenzsystems

Die praktische Umsetzung des Konzeptes zeigt Bild 19 Dabei wird das

Berechnungsinformations- und Berechnungsassistenzsystems von einem

CAD-Arbeitsplatz (Pro/Engineer) aus gestartet. Eine Suchmaschine

ermöglicht die flexible Suche von Berechnungsmethoden nach ABC-

Klassifizierung und weiteren Merkmalen. Jede Berechnungsmethode

verfügt über HTML-basierte Dokumentationen und kann als alleinstehende

Berechnung in den frühen Konstruktionsphasen, in denen noch keine

Modell-Geometrie vorhanden ist, oder gekoppelt mit dem CAD-Modell

aufgerufen werden.

4.2 Entwicklung einer webbasierten Berechnungsmethodenbank 61

Bild 19: Berechnungsinformations- und Berechnungsassistenzsystem im

Einsatz

4.2 Entwicklung einer webbasierten Berechnungsmethodenbank

Der Aufruf bzw. die Ausführung webbasierter Berechnungen erfolgt in

einem Webbrowser (Client-Seite) wie ein gewöhnliches HTML-Dokument.

Oft ist es zweckdienlich, den Anwender durch gezieltes Fragen und

Antworten zur passenden Berechnungsmethode zu führen. Darüber hinaus

kann der Anwender in vielen Situationen mit Hilfe clientseitiger Skripte

interaktiv unterstützt werden. Skripte sind kleine Programmpakete, die mit


dem Dokument in den Speicherbereich des Webbrowsers geladen werden

und durch Ausführung bestimmter Benutzerinteraktionen zur Laufzeit

interpretiert und ausgeführt werden. Dadurch kann der Anwender beim

Ausfüllen von Berechnungsformularen optimal unterstützt werden, ohne

den Webserver (Server-Seite) zu belasten. Nach einer clientseitige

Überprüfung der Benutzerangaben wird das Berechnungsformular zum

Server geschickt. Nach syntaktischer bzw. inhaltlicher Überprüfung der

Benutzereingaben werden diese dem Berechnungsprogramm weiter-

geleitet. Je nach Berechnungsablauf werden die Ergebnisse in Web-

Format vorbereitet und über den Server an den Client zurückgeschickt (Bild

20).

Bild 20: Architektur eines webbasierten Berechnungstools

Die Realisierung eines webbasierten Berechnungstools zur Analyse und

Auslegung von Schraubenverbindungen zeigt exemplarisch Bild 21. Das

Berechnungsmodell basiert auf der Schraubenberechnungsrichtlinie „VDI

2230“. Weiterhin stehen mehrere Normteil- und Werkstoffdatenbanken -

beispielsweise DIN 931/933 zur Auswahl von Sechskantschrauben - dem

Anwender zur Verfügung. Die Eingabe der Berechnungsparameter erfolgt

über ein zentrales Webdokument (Bild 21 links).


Bild 21: Einsatz eines webbasierten Schraubenberechnungsprogramms

zur Auslegung einer Flanschverbindung

Neben Geometrieeingaben können Betriebslasten in axialer Richtung (FA:

statischer Anteil der Axialkraft; FAa: dynamischer Anteil der Axialkraft)

sowie in Querrichtung (FQ: statischer Anteil der Querkraft) eingegeben

werden. Die Betriebslasten können entweder vom Anwender per Hand

oder durch Vorschalten anderer Dokumente, z.B. durch Vorberechnungen

oder Datenbanktabellen, eingetragen werden. Im Bild 21 rechts kann

beispielsweise das Ergebnis einer Flanschberechnung, speziell die mindest

erforderliche Restklemmkraft zur Übertragung des Torsionsmoments Mt -

automatisch an das Schraubenberechnungsprogramm weitergegeben

werden.


Bild 22 zeigt die Auswahl von Werkstoffkennwerten für die Platten (Bild 22

links) über eine Materialdatenbank (Bild 22 unten) sowie die Auswahl der

Schraube als Normteil aus entsprechender Datenbank (Bild 22 rechts).

Werden für ein Berechnungsprogramm Normteildaten benötigt, so ist es

mitunter zweckmäßig den Anwender bei der Auswahl zu unterstützen und

eventuell bei nicht normgerechten Eingabedaten eine Warnung

auszugeben. Bild 22 rechts zeigt beispielsweise die Vorauswahl einer zu

berechnenden Schraube aus einer Schraubendatenbank. Im Beispiel

wurde eine Schraube M16 mit der Länge l=50 mm gewählt, die als Normteil

nicht verfügbar ist! Der Anwender erhält eine Warnmitteilung.

Bild 22: Einsatz interaktiver Datenbanksysteme bei webbasierten

Berechnungen


Durch Vorschalten produktspezifischer Berechnungsmethoden vor produkt-

neutrale Berechnungsmethoden kann man ohne großen Aufwand das

Einsatzgebiet von Berechnungstools erweitern. Bild 23 zeigt ein weiteres

Beispiel, in dem das Ergebnis einer Konsolen-Auslegung wiederum als

„mindestens erforderliche Restklemmkraft“ in das Schraubenberechnungs-

programm hineinfließt. Die zugeschalteten Berechnungsprogramme

müssen nicht zwingend vom Server des zentralen Dokumentes abgerufen

werden, sondern können auch eine andere Herkunft haben. Zum

Datenaustausch zwischen den Berechnungsformularen muss allerdings ein

gemeinsames Protokoll vorhanden sein.

Bild 23: Einsatz eines webbasierten Schraubenberechnungsprogramms

zur Auslegung einer Konsole


Im Bild 23 wird ein weiterer Vorteil von webbasierten Berechnungs-

methoden gezeigt, wonach bei Bedarf dynamisch interaktive Simulations-

bzw. Animationsdokumente in den Berechnungsprozess eingefügt werden

können. Das Bild zeigt einen Auszug aus der Berechnung einer Konsole.

Neben den Ausgabedaten des Berechnungsprogramms wird dem

Anwender auch das Verspannungsschaubild der Schraubenverbindung

grafisch angeboten, hiermit können die Auswirkungen von Konstruktions-

modifikationen nach Eingabe neuer Belastungs- bzw. Konstruktions-

parameter beurteilt werden.

4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen

Wie bereits ausgeführt, lassen sich die Konzepte zur Entwicklung und

Integration produktabhängig parametrisierter Berechnungen ver-

allgemeinern. Die meisten Integrationskonzepte lassen oft nur einen relativ

geringen Spielraum für Änderungen eines Produkts bzw. Anpassungen an

ein ähnliches Produkt zu. Bei der Datenkopplung zwischen einem

parametrisierten CAD- und einem parametrisierten Berechnungsmodell

würde beispielsweise bereits eine Umbenennung der zu verknüpfenden

CAD-Parameter die Verknüpfungsbedingungen (Constraints) verletzen und

die korrekte Ausführung der Berechnung verhindern. Zur Lösung dieses

Problems wird in [And-SPP] das Integrationskonzepts des

Assistenzsystems „Colibri“ (Constraint Linking Bridge) vorgestellt. Dieses

Konzept sieht die Entwicklung eines erweiterten parametrisierten

Datenmodells zur Verwaltung von Gestaltungs-Berechnungs-Beziehungen

vor. Colibri verfügt über Schnittstellen zu den zu koppelnden CAx-

Systemen und bietet dadurch die Möglichkeit, die zur Kopplung

notwendigen Zwangsbedingungen (Constraints) zu definieren.

Die in dieser Arbeit entwickelten Integrationskonzepte erweitern das

soeben beschriebene Integrationskonzept vor allem im Hinblick auf die

verteilte Struktur der Produktdaten als auch der Berechnungsmethoden, in

modernen Unternehmen. Ziel ist es u. a., netzweit verteilte

Berechnungsmethoden und deren Berechnungsparameter mit den


Berechnungsdaten in einer einheitlichen Umgebung zu integrieren bzw.

bereitzustellen9. Aufbauend auf dem Konzept der objektorientierten

Methodenbank (siehe Abschnitt 1.31, bzw. Bild 6) werden neue Konzepte

für die Methodenbank und das Constraint-Management vorgestellt.

Das bisherige Konzept zur objektorientierten Methodenbank hatte

hinsichtlich der Integration verteilter dezentraler Berechnungsmethoden

bzw. Berechnungsdaten aus unterschiedlichen Ressourcen folgende

Einschränkungen:

• Die Berechnungsmethoden mussten sich im physikalischen Speicher-

bereich des Wrappers befinden.

• Der Solver konnte keine heterogenen Datentypen und keine Iterationen

verarbeiten.

• Es konnte jeweils nur eine Berechnungsmethode geladen bzw. ein-

gesetzt werden.

Zur Umgehung dieser Probleme wurde die Entwicklung neuer Konzepte

bzw. die Überarbeitung des Konzepts der objektorientierten Methodenbank

erforderlich. Die Entwicklungsschwerpunkte werden in den Abschnitten

4.3.1 bis 4.3.6 unter folgenden Überschriften zusammenfassend behandelt:

• Berechnungsmethodenmanagement

zur netzweiten Bereitstellung von Berechnungsdiensten.

• Berechnungsparametermanagement

9 Im folgenden bezieht sich der Begriff Berechnungsparameter auf solche, die – als Teil einer

Berechnungsmethode - zur Anpassung des Berechnungsmodells vorgesehen sind. Zu deren

Belegung mit relevanten Parameterwerten werden die Berechnungsparameter mit Produktdaten

aus verschiedenen Ressourcen – z.B. Geometriedaten aus dem CAD oder Werkstoffdaten aus

einer Datenbank – verknüpft, die hier als Berechnungsdaten oder Berechnungsmodelldaten

bezeichnet werden.


zur einheitlichen Einbindung verteilter Berechnungsparameter in den

Berechnungsprozess.

• Berechnungsdatenmanagement

zur einheitlichen Einbindung verteilter dezentraler Berechnungsdaten – z.B.

Geometriedaten aus dem CAD-System oder Werkstoffdaten aus der

Datenbank - in den Berechnungsprozess.

• Berechnungsverknüpfungsmanagement

zur Unterstützung beim gleichzeitigen Einsatz mehrerer (multipler)

Berechnungsmethoden.

• Berechnungsintegrationsmanagement

zur dynamischen Verknüpfung von Berechnungsparametern und

Berechnungsdaten in den Berechnungsprozess sowie zur dynamischen

Ausführung von Berechnungen und Bewertungen.

4.3.1 Berechnungsmethodenmanagement

Die objektorientierte Methodenbank aus [Woe98] setzte voraus, dass die

Ausführung von Berechnungen auf dem lokalen Rechner stattfindet. Durch

Erweiterung des Integrationskonzeptes der Methodenbank um einen

Berechnungsmethodenmanager, wird zusätzlich eine dynamische,

netzweite Einbindung von Berechnungsprogrammen durch den Constraint-

Manager während des Berechnungsprozesses ermöglicht. Grundsätzlich

werden folgenden Integrationsformen berücksichtigt (Bild 24):

• Codeintegration

Hier befindet sich - wie bei objektorientierter Methodenbank - die

Berechnungsprogramme auf dem örtlichen Speichermedium der

Methodenbank.

• Loading

Zur Ausführung wird eine Kopie des ausführbaren Berechnungsprogramms

in den Arbeitsspeicher der Methodenbank geladen.


• Client-Server

Ein clientseitiges Programm wird als Platzhalter in die Methodenbank

integriert und kommuniziert beim Aufruf mit einem serverseitigen

Berechnungsprogramm.

Berechnungsprogramm

Integrationsumgebung

Berechnungsprogramm

Berechnungsprogramm( Client )


Berechnungsprogramm

Berechnungsprogramm( Kopie )


CodeintegrationLoadingClient-Server

Methodenbank

Bild 24: Integrationsformen der Berechnungsmethoden in die

Methodenbank mittels Berechnungsmethodenmanagement


4.3.2 Berechnungsparametermanagement

Die Anpassung des Berechnungsmodells an die vorliegende

Berechnungsproblematik erfolgt über die Berechnungsparameter, die vor

der Ausführung jeder Berechnung mit Werten belegt werden müssen. Im

Abschnitt 4.2 wurde exemplarisch gezeigt, dass die korrespondierenden

Parameterwerte entweder direkt vom Benutzer im jeweiligen

Berechnungsformular oder indirekt über zusätzliche Formulare – z.B.

Datenbankformulare - eingegeben werden können. Dieses Konzept setzt

allerdings voraus, dass Anzahl und Typ aller Parameter bei der

Entwicklung des Berechnungstools bekannt sind. Um unterschiedliche

Berechnungsmethoden dynamisch - zur Laufzeit – von einem

Berechnungstool aufrufen bzw. in ein Berechnungstool einsetzen zu

können, muss die Verknüpfung bzw. Einbindung von Berechnungs-

parametern unabhängig von deren Anzahl, Typ, Reihenfolge möglich sein.

Gleichzeitig müssen diese Parameter mit den relevanten Produktdaten –

beispielsweise Geometriedaten aus dem CAD-System – verknüpft werden.

Das Objektmodell (EMO) der objektorientierten Methodenbank aus

[Woe98] (siehe Abschnitt 1.3) und das Konzept der Parameter-Wrapping

werden hier durch einen sogenannten Parameter-Container ersetzt. Über

eine spezielle Schnittstelle greift der Parameter-Container auf die

Parameter der geladenen Berechnungsmethoden zu, und stellt diese

mittels Parameter-Wrapping dem Constraint-Manager bzw. Constraint-

Solver zur Verfügung (Bild 25).


Bild 25: Schnittstellen-Konzept eines Parameter-Containers zur

Einbindung verteilter Berechnungsparameter

Im Abschnitt 4.3.5 wird detailliert ausgeführt, wie die Berechnungs-

parameter mit den relevanten Berechnungsdaten verknüpft werden.

4.3.3 Berechnungsdatenmanagement

In großen Unternehmen können die Produktdaten weltweit an

verschiedenen Standorten anfallen und abrufbar in verteilten Datenbanken

abgelegt werden10. In diesem Fall müssen berechnungsrelevante Daten

auch aus unterschiedlichen Ressourcen netzweit zusammengetragen

werden (Bild 26). Mittels Berechnungsdatenmanagement können

Berechnungsdaten je nach Bedarf vom Entwicklungsarbeitsplatz aus

gesucht und in einer strukturierten Form (Modelldatenbaum)

zusammengestellt werden11.

Das Einfügen der Daten kann je nach Wunsch per Referenz oder Kopie

erfolgen. Die referenzierten Daten werden vom Berechnungsdaten-

management regelmäßig überprüft und zwischen der Quelle und dem

Modelldatenbaum konsistent gehalten, während die kopierten Daten im

10 In dieser Arbeit auch verteiltes Produktmodell genannt. 11 Die so zusammengestellten Daten werden in dieser Arbeit als Berechnungsdatenmodell

bezeichnet.


Modelldatenbaum unabhängig davon geändert werden und nach Wunsch

an der Quelle aktualisiert werden können.

Ein weiterer wichtiger Bestandteil der Berechnungsdaten sind benutzer-

definierte Daten, die das Datenmodell vervollständigen können. Damit hat

der Benutzer die Möglichkeit, Berechnungen trotz fehlender Verknüpfung

mit den Produktdaten auszuführen bzw. die Verknüpfung zu einem

späteren Zeitpunkt zu realisierten. Auch die anfallenden Daten, die zur

Steuerung des Berechnungsablaufs erforderlich sind – z.B.

Bewertungsparameter zum Abbruch oder zur Wiederholung eines

Berechnungslaufs – können ebenso vom Benutzer eingefügt und mit dem

Berechnungsdatenmodell für spätere Anwendungen gespeichert werden.

Bild 26: Zusammenstellung von verteilten Daten in Berechnungs-

datenmodell


Das Datenmanagementsystem ermöglicht dem Benutzer neben den

Zugang zu den verteilten Produktdaten auch die Archivierung und

Bereitstellung der Berechnungsdaten in einem einheitlichen, strukturierten

Berechnungsdatenmodell sowie deren Bereitstellung für das Berechnungs-

integrationsmanagement. Die Grundlage dafür bietet – wie bei

Berechnungsparameter aus dem vorigen Abschnitt - ein Parameter-

Container, der mittels Parameter-Wrapping, alle relevanten Berechnungs-

daten in einer einheitlichen Form einem Constraint-Manager und dem

dazugehörigem Constraint-Solver bereitstellt. Der große Vorteil von

Wrapping ist die Möglichkeit, Berechnungsdaten unterschiedlichen Typs

aus unterschiedlicher Herkunft und Quelle (beispielsweise aus

Datenbanken oder CAE-Systemen) in einer einheitlichen Umgebung zu

integrieren bzw. mit Berechnungsparametern zu verknüpfen. Bild 27 zeigt

den Aufbau des Parameter-Containers und die dazugehörige Schnittstelle

zu Einbindung verteilter Berechnungsdaten.

Bild 27: Schnittstellen-Konzept zur Einbindung verteilter Berechnungs-

daten


Die verknüpften Parameterwerte werden je nach Bedarf in regelmäßigen

Abständen mit der Quelle abgeglichen und auf Konsistenz überprüft. Nach

einer erfolgreichen Berechnung können die Parameterwerte der Quelle

aktualisiert werden.

4.3.4 Berechnungsverknüpfungsmanagement

Die Konzepte zur Integration von Berechnungen in den Produktent-

wicklungsprozess setzen in der Regel den Aufruf einer einzelnen

Berechnungsmethode bzw. die Durchführung eines einzelnen

Berechnungsprozesses voraus. Zur Berechnung und Analyse komplexer

Bauteile und Baugruppen kommen aber oft mehrere Berechnungs-

methoden zum Einsatz. Im Abschnitt 4.2 wurde beispielsweise gezeigt,

dass zur Auslegung einer Schraubenverbindung oft andere Vor-

berechnungen zur Ermittlung der erforderlichen Restklemmkraft notwendig

sind. Beim Einsatz mehrerer statischer Berechnungsmethoden (keine

zeitabhängigen Berechnungsparameter bzw. Betriebslasten) laufen die

einzelnen Berechnungsprozesse in der Regel sequentiell ab. Dabei ist oft

die erfolgreiche Ausführung einer Berechnung Voraussetzung zur

Ausführung der nächsten, weil deren Ausgangs- bzw. Eingangsdaten

gekoppelt sind.

Bild 28 zeigt formal den sequentiellen Ablauf zweier parametrisierten

Berechnungen. Der Ablauf jeder Berechnung wird in drei Hauptschritte,

„Berechnungsvorbereitung“, „Berechnungsdurchführung“ und „Bewertung“

unterteilt. Weiterhin kann formal jede Berechnung eine

Optimierungsschleife über eine „Zielfunktion“ mit bestimmten Kriterien

enthalten. Nach Abschluss der Berechnung 1, eventuell nach wiederholter

Variation der Eingangsbedingungen, werden die Kopplungs- und Eingangs-

Constraints für die nächste Berechnung überprüft bzw. bearbeitet. Sind

diese Constraints nicht erfüllt, so kann dies auch zur Wiederholung der

Berechnung 1 unter anderen Eingangsbedingungen führen.


Bild 28: Sequentieller Ablauf von zwei gekoppelten Berechnungen

Beim Einsatz mehrerer Berechnungen entsteht nach diesem Schema ein

zusammenhängendes Netz von Berechnungen (siehe auch Abschnitt 2.1),

deren Verwaltung und Steuerung ein hohes Maß an Leistung und

Flexibilität des Integrations- und Berechnungsmethodenmanagements

erfordert(Bild 29). Dabei ist u. a. auch die Verwaltung vorhandener

Überlappungen zwischen den physikalisch-mechanischen Modellen

einzelner Berechnungsmethoden (in Bild 29 als „Integriertes

Berechnungsmodell“ dargestellt) mittels geeigneter Constraints notwendig.


Berechnung 2

Berechnung 4

Berechnung 3

Berechnung 1

Berechnungsnetz

Bild 29: Einsatz mehrerer Berechnungen in Form eines

zusammenhängenden Berechnungsnetzes

Die Realisierung des Konzeptes erfolgt über den Einsatz des

Berechnungsmethodenmanagers (siehe Abschnitt 4.3.1) zum flexiblen

Laden der Berechnungen in den Berechnungsprozess sowie den Einsatz

der Berechnungsparametermanager zur Verwaltung bzw. Kopplung der

Berechnungsmodellparameter. Alle vorhandenen Berechnungsmethoden in

der Methodenbank verfügen über eine einheitliche Schnittstelle zum

Parameteraustausch (Set- bzw. Get-Methoden) sowie zur Berechnungs-

ausführung (Execute-Methoden). Nach dem Laden einer Berechnung kann

der Constraint-Manager mittels Get-Methoden alle Ein- bzw.

Ausgabeparameter in den Berechnungsprozess einbinden und zur

Formulierung von Constraints bereitstellen. Die Abarbeitung bzw.

Auswertung der Constraints erfolgt sequentiell von oben nach unten bzw.

von links nach rechts (siehe Bild 33).

Nachdem alle Eingabeparameter durch direkte Wertzuweisung oder

indirekt über eine Constraint-Formulierung mit einem Wert versehen

worden sind, kann die Execute-Methode zur Ausführung der eigentlichen


Berechnung aufgerufen werden. Anschließend können die

Ausgabeparameter über Constraints mit den Eingabeparametern der

nächsten Berechungsmethoden verknüpft werden. Zur Ausführung jeder

Berechnung übergibt der Constraint-Manager - mittels Set-Methoden - die

ermittelten Werte der Eingabeparameter an die Berechnungsmethode

weiter und veranlasst die Ausführung der Berechnung. Anschließend

werden die Werte der Ausgabeparameter ermittelt bzw. zugewiesen. Durch

Erweiterung des Constraint-Solvers mit Iterationsschleifen können auch

Optimierungsberechnungen organisiert werden.

4.3.5 Berechnungsintegrationsmanagement

In vielen Berechnungen stehen häufig nicht nur die geometrischen Daten

miteinander in Relation; vielmehr werden auch geometrische mit

technologischen Parameter des Produktes verknüpft. Beispielsweise sind

Werkstoffkennwerte oft von der Temperatur oder Bauteilgröße abhängig.

Die wesentlichen Eigenschaften des Integrationsmanagementsystems sind

Parameter-Wrapping und Constraint-Solving.

Durch Parameter-Wrapping wird es möglich, mittels Constraints die

Berechnungsparameter und Berechnungsdaten flexibel zu verknüpfen.

Diese Constraints werden während des Berechnungsablaufs von dem

Solver auf Konsistenz bzw. Vollständigkeit überprüft und bewertet. Weitere

Constraints werden zur Ausführung von Berechnungen sowie zur

Steuerung des Berechnungsablaufs erforderlich, die ebenfalls vom Solver

ausgewertet bzw. ausgeführt werden; beispielsweise der Constraint „exec“

in Bild 31, der zum Starten einer Berechnung während der Bearbeitung

dient.

Bild 30 zeigt schematisch die Arbeitsweise von Parameter-Wrapping bzw.

Constraint-Solving. Jeder Parameter enthält neben dem eigentlichen

Parameterwert bzw. Parametertyp auch weitere Informationen über seine

Herkunft und den aktuellen Zustand. Über Constraint-Mapping wird zu

jedem Zeitpunkt die erforderliche Information des Parameters abgefragt

und bereitgestellt. So wird z.B. beim Constraint-Solving der Parameterwert


sichtbar, während bei einer Update-Operation die Adresse der

Parameterquelle und die Update-Berechtigungen relevant sind.

PBP 1PBP 2 Berechnungsprogramm-Wrapping( Methodenbank )

Berechnungsparameter-Wrapping

P1

Pn

P2

P4 P3

P1

P2

Pn P3

Produktdatenresource-Wrapping

Ressourceparameter-Wrapping

Constraint-Mapping

Constraint-Solving

RS2RS1

P1

Pn

P1

P3 P4 Pn

P2 P2

P3

C1 = ( f ), ,

,

,

,

P4P1

C2 = ( f ), ,P3 P4P2

C3 = . . . .

If ( C1 && !C2&&C3) then ( ). . . .

)while ( C1 < . . . .. . . .

P4

P4

P2

P2

Bild 30: Verknüpfung mit Parameter-Wrapping und Constraint-Solving

Das Berechnungsmethodenmanagement und das Berechnungsdaten-

management bilden die Grundbausteine des Berechnungsintegrations-

managements. Das Hauptziel ist, die Produktdaten mit den

korrespondierenden Berechnungsparametern zur Laufzeit in geeigneter

Form zusammenzuführen. Die Notwendigkeit zur Datenverknüpfung


während der Laufzeit ergibt sich aus dem Konstruktionsprozess für

neuartige Produkte. In diesem Falle ergibt sich oft das Problem, dass die

notwendigen Berechnungsschritte in den frühen Phasen noch gar nicht

bekannt sind und dass eventuell netzweit nach geeigneten

Berechnungsverfahren bzw. Berechnungsprogrammen gesucht werden

muss. Werden geeignete Berechnungsprogramme gefunden, so sollten

diese, wenn möglich, als erstes in die Arbeitsumgebung des

Integrationsprogramms geladen werden können. Der Konstrukteur bzw. der

Berechnungsfachmann kann anschließend die für diese Berechnungen

erforderlichen Produktdaten zusammenstellen und bei Bedarf ergänzen

und im Berechnungsdatenmodell ablegen und anschließend mit dem

Verknüpfungsprozess beginnen. Sind Teile der berechnungsrelevanten

Daten noch nicht vollständig implementiert oder verfügbar (oft in den frühen

Phasen des Konstruktionsprozesses), so kann der Anwender – wie bereits

oben geschildert - die fehlenden Parametern vorläufig definieren und diese

zu einem späteren Zeitpunkt verknüpfen.

Das Konzept des Integrationsmanagements stellt Bild 31 mit den drei

Bausteinen „Berechnungsdatenmanagement“, „Berechnungsmethoden-

management“ und „Integrationsmanagement“ dar. Korrespondierend

stehen die drei Modelle „Berechnungsdatenmodell“, „Berechnungs-

methodenmodell“ und „Berechnungsintegrationsmodell“ in Verbindung.

Diese drei Modelle sind im Bild 31 exemplarisch für ein Berechnungs-

programm zur Berechnung der Steifigkeiten von Ringscheibenkupplungen

dargestellt. Rechts im Bild sind die physikalisch-mechanischen

Berechungsmodelle sowie die erforderlichen Eingangsparameter für die

Berechnung gezeigt. Diese Parameter werden vom Berechnungs-

integrationsmodell teilweise mit den Produktdaten des Berechnungs-

datenmodells direkt verknüpft und teilweise hergeleitet bzw. berechnet.

Anschließend wird die Berechnung ausgeführt. Nach dem Ausführen jeder

Berechnung können die Berechnungsergebnisse ausgewertet und die

Vorbereitung bzw. Ausführung der nächsten Berechnung vorgenommen

werden.


Bild 31: Konzept des Berechnungsintegrationsmanagements


Zusammengefasst beinhalten die drei Modelle folgende Daten und

Informationen:

• Berechnungsdatenmodell

beinhaltet alle berechnungsrelevanten Produktdaten.

• Berechnungsmethodenmodell

beinhaltet alle Ein- und Ausgangsdaten der eingesetzten Berechnungs-

methoden auf Basis der jeweiligen physikalisch-mechanischen Modelle

oder Anwendungsprogramme.

• Berechnungsintegrationsmodell

beinhaltet alle Constraints zum Verknüpfen von Berechnungsparameter

und Berechnungsdaten sowie zum Ausführen von Berechnungen und zur

Steuerung des Berechnungsablaufs.

4.3.6 Realisierung des verallgemeinerten Konzeptes

Die Konstruktion komplexer Produkte ist in der Regel ein iterativer Prozess

zwischen gestalterischen und rechnerischen Tätigkeiten. Sind die

Berechnungsergebnisse nicht zufriedenstellend, so werden die

Eingangskriterien modifiziert und der Berechnungsvorgang wiederholt. So

ein Berechnungsvorgang besteht in der Regel aus mehreren

Berechnungen mit Überlappungen (siehe Abschnitt 4.3.4 bzw. Bild 28). Die

Verwaltung, Ausführung und Versorgung eines solchen

Berechnungsnetzes erfolgt nach dem Konzept des Berechnungs-

verknüpfungsmanagements über ein Berechnungsverknüpfungsmodell. Oft

werden die Berechnungen in unterschiedlichen Kombinationen und

Abläufen eingesetzt, um eine sichere Aussage über Haltbarkeit der

Bauteile machen zu können, was den Einsatz mehrerer

Berechnungsverknüpfungsmodelle bedeuten würde.

Das Berechnungsdatenmodell sowie die dazugehörigen Berechnungs-

verknüpfungsmodelle sind wichtige Dateninhalte des Produktent-

wicklungsprozesses und sind zweckdienlich als Erweiterung des


Produktmodells12 hinzuzufügen. Bild 32 verdeutlicht die Erweiterung des

Produktmodells sowie den Einsatz mehrerer Berechnungsverknüpfungs-

modelle. Die verschiedenen Schichtdicken der Modellebenen sollen den

mehrfachen Einsatz der aufgerufenen Berechnungen in unterschiedlichen

Berechnungsverknüpfungsmodellen andeuten, was nur möglich ist, wenn

die Berechnungsmethoden in sich lösungsneutral in einer generalisierten

produktneutralen Form vorliegen und erst über Verknüpfungsmodelle für

das vorliegenden Produkt spezialisiert werden.

Bild 32: Globale Integrationsstrategie von Berechnungen und Erweiterung

des Produktmodells

12 Der Begriff Produktmodell wird als „Zusammenfassung aller relevanten Daten eines

technischen Produktes von der Produktidee bis zur Produktentsorgung“ definiert [VDI93].


Die Realisierbarkeit des Integrationskonzeptes wurde auf Basis moderner

Softwaretechnologie - insbesondere Java - erprobt. Bild 33 zeigt auf der

linken Seite die Umgebung des Berechnungsdatenmanagers. Es sind

Kopplungsmechanismen mit CAD- und Datenbanksystemen vorgesehen.

Als Datenformat wird vorzugsweise XML13 als ein neuer Standard zur

Beschreibung komplexer Strukturen verwendet. Die Daten werden zur

Laufzeit aus dem CAD-System Pro/Engineer importiert. Die Einbindung

anderer CAD-Systeme und Datenbanken ist als Erweiterung des

Berechnungsdatenmanagers vorgesehen. Die importierten Parameter

können je nach Bedarf verschiedene Zustände hinsichtlich deren

Aktualisierung wahrnehmen. Handelt es sich beispielsweise um eine

Werkstoffkonstante, so kann ihr Wert eingefroren werden. Ein

Geometrieparameter aus dem CAD-System hingegen kann als variabel

definiert und im Laufe der Berechnung modifiziert werden. Gleiche

Vorgehensweise gilt auch bei der Aktualisierung eines Parameterwertes an

seiner Quelle. Zusätzlich kann der Benutzer beliebig eigener Parameter

bzw. Parametergruppen definieren und verwenden. Ist beispielsweise in

einem importierten CAD-Modell ein Bauteil noch nicht verfügbar, so kann

der Anwender dieses als benutzerdefiniert in den Modellbaum einfügen

und mit entsprechenden Parameter versehen. Die Verknüpfung mit dem

eigentlichen CAD-Modell kann dann über eine zusätzliche

Parameterverknüpfung erfolgen.

Die rechte Seite von Bild 33 zeigt den Umfang des Berechnungs-

integrationsmanagers. In dieser Umgebung können beliebig viele

Berechnungsverknüpfungsmodelle (Analysis-Sheets) erzeugt werden.

Zuerst werden alle gewünschten Berechnungsmethoden über

Berechnungsmethodenmanager in die Arbeitsumgebung geladen.

Anschließend können zwischen den Modell- und Berechnungsparameter

13 XML ist eine Meta-Beschreibungssprache zur Beschreibung von Daten höher Komplexität.

Dadurch werden präzisere Deklarationen der Struktur und des Inhalts ermöglicht. XML wird u.a.

auch die Grundlage für eine neue Generation von Web-basierten Anwendungen zum Anzeigen

und Bearbeiten der Daten.


alle für die Berechnung erforderlichen Constraints in Form von

Gleichungen definiert werden. Um den Berechnungsablauf zu ergänzen

oder Bewertungen auszuführen, kann der Benutzer zwischen den

Berechnungsaufrufen auch eigene Hilfsparameter und Rechenschritte

formulieren. Im Bild 33 wird beispielsweise die Berechnung des

Antriebsmoments als Eingangswert einer Wellenvorauslegung mit Hilfe

einer Zwischenrechnung abgewickelt. Dazu werden zuerst zwei

Hilfsparameter für Leistung und Drehzahl und anschließend die

Leistungsgleichung formuliert. Zur Unterstützung der Kommentar-

möglichkeiten sind die gewohnten Kommentarzeichen aus der

Programmiersprache Java implementiert.

Berechnungsdatenmanager

Berechnungsdatenmodell

BerechnungsintegrationsmanagerBerechnungsmethodenmanager

Berechnungsverknüpfungsmodelle

Berechnungsmethodenmodelle

Bild 33: Umgebung zur Integration von Berechnungen in den

Konstruktionsprozess


Alle Constraint-Gleichungen werden vom Constraint-Solver sequentiell

abgearbeitet (Bild 45, rechts). Sind alle relevanten Eingangsparameter

einer geladenen Berechnungsmethode richtig verknüpft, so werden deren

aktuelle Werte ermittelt und anschließend die Berechnung ausgeführt

(Befehl „exec“ in Bild 45 rechts). Erfolgt die Berechnung fehlerfrei, so

werden die Ausgabeparameter der Berechnungsmethoden mit den

aktuellen Werten initialisiert. Diese können dann für weitere Bewertungen

bzw. Berechnungen verknüpft werden.

Zur Steuerung des Berechnungsablaufs können Fallunterscheidungen mit

Hilfe von IF-ELSE-Constraints formuliert werden. Zur Verfügung stehen

fast alle boolschen Operationen (==, >, <, etc.). Die Formulierung von

Iterationsschleifen ist in dem vorgestellten Stand der Entwicklung nicht

implementiert, aber als eine Erweiterung der Solver-Funktionalität

vorgesehen.

Die Berechnungsverknüpfungsmodelle sowie die dazugehörigen Berech-

nungsdatenmodelle können, wenn erwünscht, in einen Gesamt-

berechnungsmodell zusammengefasst und gespeichert werden. Nach dem

Laden eines Berechnungsmodells werden alle internen und externen

Verknüpfungen auf Konsistenz überprüft und, falls erforderlich,

entsprechende Warnungen ausgegeben.

5 Entwicklung und Integration produktklassenabhängiger Berechnungstools

Produktunabhängige und produktklassenabhängige Berechnungsverfahren

basieren in der Regel auf diskreten Berechnungsmodellen mit numerischen

Lösungsansätzen (siehe Abschnitt 1.2.5). Ein Beispiel für diskrete

Berechnungsmodelle sind die in der Schwingungstechnik gerne

eingesetzten Übertragungsmatrizen für Masse-, Feder- und Dämpfungs-

elemente, die u. a. in Mehrkörper-Simulationsprogrammen MKS für

Bewegungs- und Schwingungsberechnungen Anwendung finden. Wegen

der Energiespeicherfähigkeit der Massen- und Federelemente können

diese diskreten Teilmodelle i. a. nicht als rückwirkungsfrei betrachtet

werden, weswegen zu einer alle relevanten Betriebsbedingungen

berücksichtigenden Analyse in der Regel nur die Gesamtsystemsimulation

im Zeitbereich in Frage kommt (siehe Abschnitt 2.1 bzw. 2.2). In dieser

Arbeit wird im folgenden die Entwicklungs- und Integrationsproblematik von

produktklassenabhängigen Berechnungsverfahren, die in ein konkretes

produktunabhängiges MKS-Modell eingebunden werden sollen, behandelt.

Als Entwicklungsumgebung dient das produktunabhängige MKS-Programm

SIMDRIVE3D14, das zunächst zur Untersuchung und Analyse des

dynamischen Verhaltens von Antriebssystemen in Verbrennungsmotoren

entwickelt wurde. Der Simulationskern stellt alle erforderlichen elementaren

Berechnungsmodelle für Drehmassen und Übertragungselemente in einer

objektorientierten Modellumgebung zur Verfügung. Weiterhin verfügt der

Simulationskern über einen leistungsfähigen numerischen Integrator, der

nach Angabe der Anfangsbedingungen und Modellparameter Vorhersagen

über die zeitliche Entwicklung der Systemdynamik liefert. 14 SIMDRIVE3D© ist ein Produkt der Firma „CONTECS engineering services GmbH“ und dient

zur Konzeption, Analyse und Optimierung von beliebig aufgebauten Antriebssystemen

insbesondere von Verbrennungsmotoren. SIMDRIVE3D setzt auf Forschungsergebnissen auf,

die am Fachgebiet Konstruktionslehre der TU-Berlin in langjährigen Vorarbeiten mit Beteiligung

der Industrie entwickelt wurden.

5.1 Einsatz von MKS zur Untersuchung des dynamischen Verhaltens komplexer Systeme 87

Anhand eines MKS-Teilmodells zur Analyse des dynamischen Verhaltens

von Rädergetrieben wird im folgenden die komplexe, meist individuelle

Vorgehensweise bei der Entwicklung modelldiskreter, produktklassen-

abhängiger Berechnungsverfahren beschrieben.

5.1 Einsatz von MKS zur Untersuchung des dynamischen Verhaltens komplexer Systeme

Bevor auf das MKS- Teilmodell für Rädergetriebe näher eingegangen wird,

sollen einige grundlegende Überlegungen zu Mehrkörper-

Simulationsprogrammen (MKS-Programmen), die in den Abschnitten 1.2.6

und 2.1 beschrieben wurden, hier wiederholt und teilweise vertieft werden.

MKS-Programme werden – wie bereits erwähnt - zur Untersuchung des

dynamischen Verhaltens von Maschinen und Anlagen neben Versuchen

immer häufiger eingesetzt. Dazu wird das technische Produkt so modelliert,

dass die Komponenten, deren Kopplungen, sowie Ein- und

Ausgangsgrößen zusammen ein ganzheitliches Ersatzsystem bilden, das

mit den Modellbausteinen des MKS-Tools beschreibbar ist. Dieses

Ersatzsystem kann dann problemlos in der Modellierungsumgebung des

MKS-Tools abgebildet und simuliert werden.

Den Modellkomponenten eines MKS-Programms, mit denen der Anwender

arbeitet, entsprechen in der Regel virtuelle physikalische Bausteine, zu

denen mathematische Modelle im Rechner vorhanden sind. Die dem

Anwender verborgene mathematische Beschreibung der Gesamtsystem-

dynamik führt in der Regel auf einen Satz gewöhnlicher linearer oder

nichtlinearer Differentialgleichungen, welche die zeitliche Änderung der

Zustandsgrößen beschreiben. Die Lösung der Differentialgleichungen unter

den gegebenen Anregungsfunktionen sowie Anfangs- und Rand-

bedingungen erfolgt selbständig durch das MKS-Programm. Mit den

Simulationsergebnissen ist es dann möglich, die Eigenschaften bzw. das

zeitliche Verhalten des Systemmodells vorauszuberechen und schließlich

zu bewerten [Lip01].

5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 88

Zur Lösung der Differentialgleichungen werden numerische Verfahren

eingesetzt, die durch Diskretisierung der Zeitachse und stückweise

Linearisierung des Funktionsablaufs eine näherungsweise Berechnung der

Zustandsgrößen erreichen. Ein weiterer, wichtiger Aspekt dabei betrifft die

numerische Stabilität des Gleichungslösers (Solvers), der insbesondere bei

der Simulation im Zeitbereich direkten Einfluss auf die Simulationszeit und

die Qualität der Ergebnisse hat. Die meisten Solver verfügen über eine

dynamische Schrittweitensteuerung, die je nach Fehlergröße und System-

dynamik die optimale Zeitschrittweite für den nächsten Simulationsschritt

neu berechnet.

Die Entwicklung neuer MKS-Software-Tools ist eine große fachliche

Herausforderung und wird in der Regel von einem Team von Experten

verschiedener Fachdisziplinen durchgeführt. Zur Entwicklung neuer

Berechnungsmodelle in einer MKS-Umgebung ist neben Grundkenntnissen

zur jeweiligen Aufgabenstellung auch ein breites Fachwissen erforderlich.

Bild 34 gibt eine tabellarische Übersicht erforderlichen Fachwissens bei der

Modellentwicklung: Neben Fachwissen aus den Gebieten Mechanik,

Physik und Werkstofftechnik zur Entwicklung und Implementierung von

diskreten Modelleinheiten sind auch Grundkenntnisse über Mathematik,

Numerik und Informationstechnik zu deren Integration in die Gesamt-

simulationsumgebung erforderlich.

5.1 Einsatz von MKS zur Untersuchung des dynamischen Verhaltens komplexer Systeme 89


Aus dem Bild 34 wird weiterhin der erforderliche Aufwand beim Einsatz des

Berechnungstools ersichtlich. Die erforderlichen Daten und Informationen

zur Modellbeschreibung und Festlegung des Berechnungsablaufs kommen

in der Regel aus unterschiedlichen Ressourcen zusammen, deren

Bereitstellung und Kopplung mit großem Aufwand verbunden ist. Der

Anwender muss neben Kenntnissen über theoretische Grundlagen des

Berechnungsverfahrens auch mit der Struktur der kooperierenden

Ressourcen vertraut sein, um die relevanten Berechnungsdaten

zusammenstellen zu können. Problemangepasste Strategien zur

Integration der Berechnungen in den Konstruktionsprozess spezieller

Produkte, können wertvolle Unterstützung schaffen. Wünschenswert wäre

es, wenn sämtliche oder zumindest Teilmengen der Berechnungsdaten

automatisiert aus den beteiligten Softwaresystemen in den Berechnungs-

prozess fließen könnten.

5.2 Entwicklung eines MKS-Teilmodells zur dynamischen Untersuchung von Rädertrieben

Die Entwicklung neuer Berechnungsmodelle (Teilmodelle) in der

komplexen Modellumgebung eines MKS-Systems erfordert, neben der

Berücksichtigung lokaler Modellkriterien auch die Anpassung an das

übergeordnete MKS-Modell. Die Entwicklung des Verzahnungsmodells in

dieser Arbeit erfolgt deshalb speziell für die Modellstruktur des MKS-

Programms SIMDRIVE3D. Bild 35 zeigt einige elementare Modelleinheiten

von SIMDRIVE3D.


Masse, Tr gheitsmoment, absolute Dä ämpfung ...

Übersetzung, Übertragungsrichtung ...

Steifigkeit, Dämpfung...

Erregungstyp (Kraft, Weg, ...), Eingabeformat (Messdaten, Kennlinie, ...)

Drehmasse

Übertragungselement

Rheologisches Element

Erregungselement

PartialmodellPartialmodell ModelleigenschaftenModelleigenschaften

Bild 35: MKS-Modelleinheiten als Grundlage zur Implementierung eines

Zahnradmodells

Grundsätzlich besteht ein Simdrive-MKS-Modell aus mehreren

massebehafteten starren oder auch elastischen Einzelkörpern (Massen),

die mittels masseloser Koppelelemente (Übertragungselemente oder

Verbinder genannt) miteinander verbunden sind. Zur Einbindung

systemexterner Einflusse können an den Einzelkörpern Erregungen in

Form analytischer Gleichungen oder als Messdaten angebracht werden.

Ein spezielles Massenelement in der Elementbibliothek von SIMDRIVE3D

ist die Drehmasse. Es handelt sich dabei um einen starren Einzelkörper mit

rotatorischem Freiheitsgrad. Starre Körper haben im Gegensatz zu den

elastischen Körpern, die wesentliche Eigenschaft, dass neben deren

Masse auch die Massenträgheiten als zeitlich konstant betrachtet werden

können. Im einfachsten Fall sind zwei Drehmassen mit einem

Übertragungselement starr verbunden. Durch Einfügen sogenannter

rheologischer Elemente können physikalische Eigenschaften von

Übertragungselementen wie beispielsweise Steifigkeit oder Dämpfung

beeinflusst bzw. definiert werden (Bild 36).


Drehmassen

Übertragungselement

Erregungen

Rheologisches Element

Bild 36: Verbindung zweier Drehmassen in der SIMDRIVE3D-

Modellierungsumgebung

Im Gegensatz zu den klassischen MKS-Programmen, in denen die

Bewegungsdifferentialgleichungen aller Körper ausgehend von einem

Gesamtgleichungssystem gelöst werden, verfolgt SIMDRIVE3D einen

objektorientierten Ansatz. Dabei wird die Bewegungsdifferentialgleichung

für jeden einzelnen Körper – durch Freischneiden seiner Verbindungen -

aufgestellt. Zu einem Zeitpunkt t werden dann – gleichsam „simultan“ - für

alle Körper, z.B. alle Drehmassen, die zweiten Ableitungen der

Bewegungsvektoren (z.B. die Winkelbeschleunigungen) nach Aufstellen

der kinetischen Gleichungen, z.B. der jeweiligen Drallsätze, ermittelt.

Durch eine geeignete numerische Integration werden anschließend - für

jeden Körper - der Bewegungsvektor und dessen benötigten zeitliche

Ableitungen für den Zeitpunkt (t+dt) berechnet und an die jeweils

benachbarten Übertragungselementen weitergeleitet. Damit kann für jedes

Übertragungselement unter Berücksichtigung des Übertragungsgesetztes,

z.B. des Stoffgesetzes, der wirkende Kraftvektor, z.B. das


Torsionsmoment, für den Zeitpunkt t+dt bestimmt und daraufhin an die mit

ihm in Verbindung stehenden Körpern unter Berücksichtigung des

Vorzeichens weitergeleitet werden. Schließlich wiederholt sich der

Berechnungsgang, ausgehend von den Körpern, für den Zeitpunkt t+dt

erneut (Bild 37).

Ma1 M

a2

Voigt-Kelvin-Element

( - )( + )

Integration

θ1 θ2

Integration

c ( - ) + b ( - )Mi =

M =

1 ,1 1 2,2 2

2 1 2 1

2 2M = 1 1

Bild 37: Aufstellen der Bewegungsdifferentialgleichungen für einen

Zweimassenschwinger mit einem Voigt-Kelvin-Element als Übertragungs-

element.

Überträgt man die Überlegung für den oben beschriebenen

Zweimassenschwinger auf eine elastische Zahnradverbindung, so können

die Zahnradkörper einerseits als starre Massen und die sich im Eingriff

befindenden Zähne anderseits als Verbindungs- bzw. Übertragungs-

elemente abgebildet werden (Bild 38).


Verzahnungsmodell( - )( + )

IntegrationIntegration1 ,1 1 2,2 2

Mi

Bild 38: Die Zahnradverbindung als Zweimassenschwinger

Die Implementierung des Verzahnungsmodells erfolgt durch Erweiterung

der Modelleinheit Drehmasse aus der SIMDRIVE3D-Modellbibliothek um

Daten zur Beschreibung der Verzahnungsgeometrie und des Werkstoffs.

Als Drehmasse allein könnte ein Zahnrad grundsätzlich ohne zusätzlichen

Aufwand mit bisher verfügbaren SIMDRIVE3D-Übertragungselementen

gekoppelt werden. Die Kopplung zwei Zahnräder mit elastisch wirkenden

Zähnen erfordert aber darüber hinausgehend ein feinteiligeres

Übertragungselement für den Zahnkontakt und damit einige grundsätzliche

Erweiterungen des Modellierungskonzeptes in SIMDRIVE3D. Die bisher

verfügbaren Koppelelemente verbinden Massen mit fixierten Koppelstellen.

Eine Zahnradverbindung hat aber keine festen Koppelstellen, da die

Eingriffspunkte der Verzahnung dauernd ihre Lage ändern. Lediglich der

Achsabstand zweier Zahnräder kann in erster Näherung als konstant

angesehen werden (Bild 39).


Übertragungselementstarre Verbindung

ÜbertragungselementZahnkontakt

Bild 39: Erforderliche Koppelelemente zur Kopplung des Zahnradelements

mit anderen MKS-Elementen

Ein weiterer wichtiger Unterschied betrifft die Anzahl möglicher weiterer

Koppelstellen zu benachbarten Zahnrädern. Bei einer normalen

Drehmasse liegt die Anzahl möglicher Anschlussstellen für

Übertragungselemente zu anderen Massen bei zwei. Ein Zahnrad dagegen

kann wesentlich mehr Koppelstellen zu anderen getriebenen oder

treibenden Zahnrädern haben. Die Kräfte in allen Koppelstellen eines

Zahnrads bestimmen zusammen mit den wirksamen Massenkräften die

Kräfte- und Momentenbilanzen beim Aufstellen der kinetischen

Gleichungen.

Das Übertragungselement Zahnradverbindung weist aufgrund der dauernd

veränderlichen Eingriffspunkte auf den Zahnflanken eine veränderliche

Steifigkeit auf, zu deren Bestimmung im folgenden die Verzahnungs-

geometrie und die Verzahnungskinematik näher zu beachten sind.


5.2.1 Berechnung der Verzahnungssteifigkeit

Das Zahnradpartialmodell wird als Kombination von starren und

elastischen Teilkörpern, als hybrider Körper, aufgefasst. Während sich der

Grundkörper des Zahnrads durch seine Trägheitsmasse und

rotationssymmetrische Geometrie wie eine starre Drehmasse verhält,

müssen die sich im Kontakt befindenden Zähne als biegeweiche

Balkenelemente angesehen werden. Als besondere Eigenschaft der

Rädergetriebe ergibt sich hieraus eine periodisch veränderliche

Verzahnungssteifigkeit, weil die Eingriffspunkte auf den Zahnflanken

während einer Eingriffsperiode entlang der Eingriffsgeraden wandern und

damit unterschiedliche Hebelarme bezüglich der Zahnwurzeln aufweisen.

Als weitere Einflussfaktoren auf die Verzahnungssteifigkeit sollen die

zahnkraftabhängige lokale Hertzsche Flächenpressung sowie oder

Kontaktverluste im Resonanzbereich bzw. bei hoher Dynamik genannt

werden. Alle erwähnten Einflüsse ergeben zusammen das nichtlineare

Verhalten der Zahnsteifigkeit. Zur genauen Ermittlung der

Verzahnungssteifigkeit muss deswegen in jedem Zeitschritt die aktuelle

Kontaktkinematik neu berechnet werden.

Zur Beschreibung der Zahnkontur werden die Evolventenfunktion und die

genaue Abrollkinematik der während der Fertigung benutzten

Verzahnungswerkzeuge herangezogen. Letztere bestimmen zusammen

mit den sich im Rahmen der Fertigungsgenauigkeit einstellbaren

Profilverschiebungen bei der Vorverzahnung und der Nachverzahnung erst

die endgültige Zahnform. Zur Bestimmung der Zahnsteifigkeit wird die

endgültige Zahnkontur entlang der Zahnhöhe fein diskretisiert (Bild 40). Die

Berechnung erfolgt dann mit analytischen Ansätzen für die angedeuteten

Teilelemente.


Bild 40: Diskretes Zahnradmodell zur Berechnung der Zahnsteifigkeit

Bild 41 zeigt einen exemplarisch errechneten Verlauf der Zahnsteifigkeit

über die Zahnhöhe.

Bild 41: Verlauf der Zahnsteifigkeit über die Zahnhöhe

Zur Bestimmung der Gesamtsteifigkeit zweier sich in Kontakt befindenden

Zähne, wird neben den Steifigkeiten einzelner Zähne auch die Steifigkeit

an der Kontaktstelle berücksichtigt (Bild 42). Als Grundlage dient die vom

Heinrich Hertz (1857-1894) entwickelte Hertzsche Kontakttheorie.


Als weitere Einflussfaktoren im Kontaktbereich werden der Effekt der

Öldämpfung in Normalrichtung sowie die Reibverluste in tangentialer

Richtung berücksichtigt.

Bild 42: Zahnkontaktmodell mit viskoelastischer Kontaktsteifigkeit in

Richtung der Kontaktnormalen und in tangentialer Richtung

Während des Zahneingriffs wandert ein Kontaktpunkt entlang den

Eingriffsgeraden bei einem Zahn von Zahnkopf in Richtung Zahnwurzel

und beim Gegenzahn umgekehrt. Dementsprechend steigt bei einem Zahn

die Steifigkeit, während sie beim anderen abnimmt. Die Gesamtsteifigkeit

erhält damit einen für Zahnräder charakteristischen parabelförmigen

Verlauf, dessen Maximum bei zwei gleichen Zähnen genau in der Mitte der

Eingriffsgeraden liegt (Bild 43).


Bild 43: Verlauf der Zahnpaarsteifigkeit entlang der Eingriffsgeraden

Bei zwei sich in Kontakt befindenden Zahnrädern ändert sich während des

Betriebs die Anzahl der Zahnkontaktpaare und verursacht dadurch das

typisch ungleichmäßige Übertragungsverhalten von geradverzahnten

Rädertrieben. Je nach Überdeckungsgrad sind in der Regel 1 und 2 oder 2

und 3 Kontaktpaarzahlen möglich. Bei jedem Wechsel der Kontaktpaarzahl

ändert sich die Gesamtverzahnungssteifigkeit bzw. das übertragbare

Drehmoment sprunghaft. Bild 44 zeigt diese Situation bei einem Wechsel

zwischen 2 und 3 Kontaktpaaren. Im Betrieb kann dieser Verlauf u.a. von

Dämpfungseinflüssen an der Kontaktstelle (Öl- bzw. Materialdämpfung)

beeinflusst werden.


Bild 44: Verlauf der Verzahnungssteifigkeit bei Änderung der

Kontaktpaarzahl

5.3 Implementierung des Rädertriebmodells in SIMDRIVE3D-Umgebung

Zur Erprobung des implementierten Verzahnungsmodells wird ein

Zweirädertrieb aufgebaut. Um den Steifigkeitsverlauf besser beurteilen zu

können, wird die Verzahnung ohne Spiel und ohne Material- bzw.

Öldämpfung modelliert. Jedes Zahnrad wird mit einer Drehmasse starr

verbunden. An der Antriebseite wird eine Drehzahl vorgegeben, an der

Abtriebsseite zum Zeitpunkt Null abgebremst, sodass sich eine

Relativverdrehung zwischen den Zahnrädern aufbaut und die Drehzahl der

Abtriebswelle kurz minimal abfällt (Bild 45).

5.3 Implementierung des Rädertriebmodells in SIMDRIVE3D-Umgebung 101

Dre

hzah

l

Antriebs-drehzahl

Abtriebs-drehzahl

Verz

ahnu

ngss

teifi

gkei

t [N

/mm

]

Zeit

Antrieb

Abtrieb

Zeit [s]

Bild 45: MKS-Testlauf zur Berechnung des zeitlichen Steifigkeitsverlaufs

einer Zahnpaarung. Diagramm links oben: Drehzahlverlauf über der Zeit

bei Aufschaltung des Bremsmoments. Diagramm rechts unten:

Federsteifigkeit über der Zeit nach Aufschaltung des Bremsmoments mit

Detailansicht für stationären Bremsbetrieb.


Neben sprunghafter Änderungen der Zahnsteifigkeit beim Wechsel

zwischen zwei und drei Kontaktpaaren, zeigt der Gesamtverlauf anfangs

einen starken nichtlinearen Anstieg, dessen Ursache im nichtlinearen

Anstieg der Kontaktsteifigkeit beim Erhöhen der Normalkraft zu finden ist.

5.3.1 Hilfsmittel zur interaktiven Unterstützung der Rädertrieb-modellierung

Die genaue Geometrie der Zahnräder resultiert – wie bereits erwähnt – aus

dem gestuften Fertigungsprozess und der zum Fertigungsprozess

gehörenden Messgenauigkeit. Prinzipiell wäre eine direkte Vorgabe der

Profilverschiebung wünschenswert, da sich hieraus die Zahnradkontur

unmittelbar berechnen lässt. Bei der Fertigung allerdings ist eine

Einstellung der Profilverschiebung mittels eines radialen Versatzes des

Werkzeugs nicht genau genug, weswegen die Profilverschiebung nur

indirekt über das sog. „diametrale Zweikugelmaß“ vorgegeben wird.

Mit Hilfe des diametralen Kugelmaßes kann die Einhaltung der

gewünschten Zahnlückenweite bzw. Zahndicke nach Erfahrung

ausreichend genau sichergestellt werden. Die genaue radiale Position des

Werkzeugs wird dann so an der Werkzeugmaschine eingerichtet, dass sich

der Wert des diametralen Zweikugelmaßes innerhalb des gewünschten

Toleranzbereiches befindet. SIMDRIVE3D unterstützt den Anwender des

Programms dahingehend, dass neben der direkten Eingabe des

Profilverschiebungsfaktors auch die Messparameter des „diametralen

Zweikugelmaßes“ für einen vorgebbaren „Messkugeldurchmesser“

eingegeben werden können. Das System berechnet dann unmittelbar den

korrekten Wert des Profilverschiebungsfaktors (Bild 46).


DZKMDZKM

DK

DK

Bild 46: Einstellung der Profilverschiebung über Vorgabe des diametralen

Zweikugelmaßes und des Messkugeldurchmessers

Eine weiteres Hilfsmittel zur Unterstützung des Anwenders bei der

Kontrolle der gewünschten Getriebemodellierung in der Simderive3D-

Umgebung ist die exakte Positionierung der Zahnräder unter Beachtung

der sich aus der Fertigung ergebenden Zahnradgeometrie und des

angestrebten Wert des Normalflankenspiels, woraus sich der gesamte

Wert des Ist-Achsabstands und die Beschreibung der Verzahnungs-

kinematik ergibt. In der SIMDRIVE3D-Modellierungsumgebung kann der

Anwender neben der Verschiebung bzw. Positionierung der Zahnräder per

Mausklick oder Koordinateneingabe auch die Möglichkeit wählen, statt des

Achsabstands den Wert des Normalflankenspiels einzugeben. Der korrekte

Achsabstand wird dann unmittelbar berechnet und verwendet. Um


Zahnräder tangential zueinander bei Wahrung des Achsabstands

verschieben zu können, besteht die Möglichkeit ein Zahnrad zu fixieren.

Die Freiheitsgrade des Gegenzahnrads werden dann so eingestellt, dass

nur eine Verschiebung auf einer Kreisbahn unter Beibehaltung des

aktuellen Achsabstandes möglich ist (Bild 47). Diese Vorgehensweise ist

besonderes bei der Modellierung von Hochpräzisionsgetrieben mit sehr

kleinem Normalflankenspiel hilfreich.

Bild 47: Bestimmung des Achsabstandes über Eingabe des Normalflan-

kenspiels (rechts). Fixieren des Achsabstandes bei der Positionierung der

Zahnräder (links)


Zur Berechnung der Zahnkontur wird – wie oben ausgeführt - der

Fertigungsprozess zugrunde gelegt. Ausgangspunkt ist die Angabe der

Werkzeugsgeometrie nach DIN 3960. Über die Werkzeugsgeometrien und

unter Berücksichtigung der Fertigungsprozesse mit Vor- und

Fertigverzahnung und Fertigverzahnung wird die Zahnkontur unmittelbar

berechnet und graphisch dargestellt (Bild 48).

Bild 48: Berechnung der Zahnkontur unter Berücksichtigung der

Werkzeugsgeometrien und des Fertigungsprozesses


5.3.2 Animationstool zur Untersuchung der Kontaktkinematik im Verzahnungsbereich

Die Konturdarstellung in der Modellierungsumgebung entspricht exakt der

Konturberechnung in der Simulation. Damit wird eine visuelle Kontrolle,

während der Modellierung und auch während der Animation der

Kontaktkinematik sichergestellt (Bild 49).

Bild 49: SIMDRIVE3D-Animationstool zur Untersuchung der

Kontaktkinematik von Rädertrieben


5.4 Integration produktklassenabhängiger Berechnungen in den Produktentwicklungsprozess

Beim Einsatz von diskreten Berechnungen fallen in der Regel sowohl bei

der Modellbeschreibung, als auch bei der Bewertung, große Mengen an

Informationen und Daten an. Bei diskret finiten Berechnungsmodellen wie

FEM unterscheidet man zwischen dem FE-Solver – FE-Berechnungskern –

und Pre- bzw. Postprozessor – zur Berechnungsvorbereitung bzw.

Ergebnisanalyse -. Ein FE-Modell setzt sich aus einer Vielzahl identischer

Teilmodelle (Finiten Elementen FE) zusammen. Dadurch wird eine

automatische Generierung des finiten Modells (Netzgenerierung) aus dem

Geometriemodell (z.B. CAD-Modell) möglich. Die automatische

Netzgenerierung reicht in der Regel für einfache Bauteilformen aus. Bei

komplexeren Modellen ist häufig eine Nachbearbeitung erforderlich.

Bei MKS-Systemen, deren diskretes Gesamtmodell – im Gegensatz zu

FEM – aus unterschiedlichen Partialmodellen (Massen, Federn, Gelenke,

etc.) besteht, ist eine eindeutige automatisierte Zuordnung von

Systemkomponenten zu den Partialmodellen noch komplizierter. Die

Definition von starren Körpern und Verbindungen dazwischen richtet sich

oft nach der erforderlicher Simulationszeit, der Genauigkeit und Qualität

der Simulation. So werden zur Verkürzung von Rechenzeiten gerne

mehrere Körper zu einem Gesamtkörper reduziert, wenn der Einfluss der

Teilkörper auf die Gesamtsystemdynamik als gering erachtet werden kann.

Zur besseren Korrelation zwischen Produkt- und Modelldaten forscht die

ProSTEP iViP Projektgruppe SimPDM [STiViP] seit 2002 an Lösungen zur

Integration von Simulation und Berechnung in eine PDM-Umgebung,

speziell in Hinblick auf den Einsatz von MKS- und FEM-Systemen. Die

Analysen der simulations- und berechnungsrelevanten Daten haben

gezeigt, dass die in den Simulationsmodellen benötigte Modellstruktur nicht

mit der in PDM-Systemen vorhandenen Produktstruktur korreliert [Krast02].

Eine wesentliche Fragestellung dabei ist, wie die Simulations- und


Berechnungsmodelle automatisch mit den vorhandenen Produkt-

informationen aus dem PDM-System zu parametrisieren sind.

In [Krau05] wird zur Lösung solcher Fragen das Functional Mock-Up (FMU)

zur rechnerinternen Beschreibung von physikalischen bzw. logischen

Eigenschaften des Produktes bzw. der Produktkomponenten vorgestellt.

Hierzu ist das Digital Mock-Up (DMU) zu erweitern. Beim DMU werden i. a.

nur verschiedene geometrische Sichten - beispielsweise zur Kollisions-

oder Formprüfung - aus dem Produktmodell generiert. Diese

geometrischen Teilmodelle reichen aber i. a. zur funktionalen

Untersuchungen wie Kinematik- oder Montage- bzw. Demontagesimulation

nicht aus. Durch Erweiterung des Produktmodells mit relevanten

funktionellen Eigenschaften und Ableitung von Functional Mock-Ups soll u.

a. eine durchgehende Integration von Simulationen in den Produktent-

wicklungsprozess realisiert werden.

Die unten beschriebenen Integrationsprobleme und deren Lösung

beschränken sich auf MKS-Programme, insbesondere auf das Arbeiten mit

dem Simulationsprogramm SIMDRIVE3D. Trotzdem können damit

wesentliche, der bei Integration verschiedener Quelldaten auftretenden

Probleme und zugehörige Lösungsansätze verdeutlicht werden. Die

Ausgangsproblematik ist – ähnlich wie bei parametrisierten Berechnungen

– durch eine verteilte heterogene Datenstruktur aus unterschiedlichen

Ressourcen zu charakterisieren. Allerdings sind als Simulationsdaten nicht

nur Daten in parametrisierter Form, sondern auch beliebig strukturierte

Datenkomplexe, beispielsweise periodische bzw. nicht periodische

gemessene Kennlinien oder Hochlauf-Messschriebe etc. zu verarbeiten

und zu integrieren, insbesondere können die Simulationsdaten frequenz-

oder zeitabhängig sein.

Zur Kopplung derartiger externer Daten stehen dem Anwender in

SIMDRIVE3D zahlreiche Funktionalitäten – beispielsweise zur Analyse

bzw. zur Konvertierung der Daten – zur Verfügung. Externe Informationen

aus Messungen können beispielsweise als Leistung-Drehzahl-Kennlinien


(Bild 50 oben) oder als Leistung-Moment-Kennlinien (Bild 50 unten) an

einen starren Körper angekoppelt werden. Die erforderlichen Messwerte

werden während der Simulation automatisch generiert bzw. vorbereitet. Die

Datenquelle wird regelmäßig auf Konsistenz überprüft. Beim Speichern

eines Modells kann der Anwender entscheiden, ob die gekoppelten Daten

mit dem Modell mitgespeichert werden oder ob eine Referenz auf die

Datenquelle ausreicht

Aggregatkennlinie: Generator

Aggregatkennlinie: Klimakompressor

Aggregatkennlinie: Generator

Aggregatkennlinie: Klimakompressor

Bild 50: Kopplung von Messdaten bzw. Kennlinien mit SIMDRIVE3D-

Elementen


Bild 51 zeigt schematisch die Verknüpfung von weltweit verteilten Daten

über die 3D-Modellierungsumgebung von SIMDRIVE3D zu den internen

Berechnungsmodellen.

Last- undWerkstoffdaten

Modellierungs- und Integrationstool SIMDRIVE SIMDRIVE-Simulationskern

Wirkmodelle fürAntriebselemente

Geometrie- undStrukturdaten

Variations- undSteuerungsdaten

Kontaktmodelle

LH

SP LUE

KLKWGEN

Geometriemodelle

Werkstoffmodelle

Aggregatmodelle und KennlinienCAD-Modelle und

Motorkennwerte

Mess- undVersuchsdaten

Hydr. Modelle

eL

I

B2

C2

C1C0

s

Ψ

βA

FA FE

Bild 51: Integrationskonzept des Softwaresystems SIMDRIVE3D

Neben Geometrie- und Strukturdaten zur Modellierung des MKS-Modells

sind zahlreiche Last- und Werkstoffinformationen, etc. erforderlich, um

beispielsweise die physikalischen Eigenschaften aller Nebenaggregate

eines zu untersuchenden Motors beschreiben zu können. Diese

Informationen befinden sich oft bei internationalen Zulieferern der

Systemkomponenten. Zur Konvertierung der i. a. unterschiedlichen

Datenformate steht zwischen dem Simulationskern und der

Modellierungsumgebung eine modular aufgebaute Schnittstelle zur

Verfügung, womit auch neue Datenformate der Anwender ohne Änderung

des Simulationskerns eingebunden werden können.

5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 111

5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern

Bei der Simulation komplexer Systeme können Situationen auftreten, bei

denen der parallele Einsatz mehrerer Simulationsprogramme erforderlich

wird (Cosimulation). Dies kann beispielsweise dann der Fall sein, wenn:

• das komplexe System aus technologisch unterschiedlichen

Teilsystemen besteht und zu jedem Teilsystem ein eigenes

Simulationsprogramm bereitsteht (So kann beispielsweise zur

Simulation eines modernen Verbrennungsmotors neben einem MKS-

System zur Motorsimulation gleichzeitig der Einsatz eines Regler-

Simulationsprogramms zur Simulation der elektronischen

Motorsteuerung erforderlich werden) oder

• das komplexe System wegen geringer Hardwarekapazitäten in

einfachere Teilsystemen zerlegt werden soll.

Je nach der Kopplungsart der Simulationsprogramme kann man zwischen

Modellverbund, Solververbund und Programmverbund unterscheiden

[Gärt01].

Bei der Cosimulation nach dem Prinzip des Modellverbundes müssen die

in den einzelnen Programmen erstellten Modelle zu einem Gesamtmodell

vereint werden. Anschließend übernimmt eines der beteiligten Programme

mit seinem Solver die Berechnung des Gesamtsystems. Dieses Verfahren

setzt voraus, dass die beteiligten Simulationsprogramme entweder gleiche

Modelltopologie haben oder über entsprechende Schnittstellen zum Import

bzw. Export der Simulationsmodelle verfügen.

Beim Solververbund wird neben dem Simulationsmodell auch der

dazugehörige Solver (z.B. als abrufbare externe Prozedur) von einem

Simulationsprogramm in das andere Simulationsprogramm exportiert.

Beim Programmverbund nach [Gärt01] werden die beteiligten Programme

gleichzeitig ausgeführt und verwenden zur Berechnung jeweils das eigene


Modell und den eigenen Solver. Das Simulationsprogramm mit der

kleineren Zeitschrittweite steuert dabei die anderen Programme. Während

der Simulation werden die berechneten Größen an den Schnittstellen der

Teilsysteme ausgetauscht und so die Kommunikation zwischen den

Programmen sichergestellt. Voraussetzung für die Realisierung eines

Programmverbunds ist die Möglichkeit, die einzelnen beteiligten

Simulationsprogramme von außen anzusteuern, damit ein Datenaustausch

bei laufender Simulation erfolgen kann.

Zur Realisierung von Cosimulationen mit SIMDRIVE3D standen folgende

Anforderungen im Vordergrund:

• Es sollte möglich sein, ein komplexes Simulationsmodell in mehrere

einfachere Modelle zu teilen bzw. zu simulieren.

• Es sollte möglich sein, die Simulationslast auf mehrere Rechner zu

verteilen.

• Die Anwender sollten in der Lage sein, über eine Schnittstelle eigene

Simulationsprogramme mit SIMDRIVE3D-Modellen zu koppeln bzw.

mittels Cosimulation zu verbinden.

• Es sollte eine leistungsfähige Benutzeroberfläche sowohl zur

Modellbildung als auch zur Steuerung bzw. Verwaltung der

Cosimulation entwickelt werden.

Zur Realisierung der genannten Anforderungen wurde das Konzept der

Cosimulation nach dem Prinzip des Programmverbunds entwickelt.

Darüber hinaus wurde eine leistungsfähige Kommunikationsarchitektur

konzipiert, um eine verteilte Cosimulation zwischen mehreren

Simulationsprozessen (Multi-Solver-Cosimulation) zu ermöglichen. Die

Entwicklungsarbeiten wurden in drei Schwerpunkte, Modellerweiterung,

Datenkommunikation bzw. Prozesssteuerung und Prozesssynchronisation,

unterteilt. Diese Arbeitsschritte werden im folgenden ausführlich

beschrieben.


5.5.1 Entwicklung eines erweiterten MKS-Modells zur Unterstützung cosimulierender Prozesse

Die Teilung eines komplexen Mehrkörpermodells in Teilmodelle ist dann

möglich, wenn die zum Gesamtmodell zusammengesetzten Teilmodelle

sowohl kinematisch als auch kinetisch das Verhalten des Gesamtmodells

richtig wiedergeben. Im Abschnitt 5.2. wurde gezeigt, dass in SIMDRIVE3D

die Bewegungsdifferentialgleichung für jede einzelne Masse – nach dem

Freischneiden – getrennt aufgestellt wird. Im nächsten Schritt wurde dann

aus der Bewegungsdifferentialgleichung die Beschleunigungen (zweite

zeitliche Ableitung) des Bewegungsvektors für einen Zeitpunkt t ermittelt.

Durch numerische Integration des Beschleunigungsvektors unter

Beachtung der Geschwindigkeits-. und Bewegungsvektoren zum Zeitpunkt

t konnten dann Geschwindigkeits- und Bewegungsvektoren der

Einzelmassen für den nächsten Zeitschritt t+dt bestimmt werden. Im

folgenden Schritt wurden diese Bewegungs- und Geschwindigkeitsvektoren

an die mit dieser Masse – gekoppelten Übertragungselemente

weitergeleitet. Mit den Materialgesetzen der Übertragungselemente

konnten damit die für Zeitpunkt t+dt resultierenden Kraftvektoren an den

angekoppelten Massen ermittelt werden, die in den jeweiligen

Differentialgleichungen für den nächsten Zeitschritt gebraucht werden.

Die zwei Simulationsschritte „Aufstellen der Bewegungsdifferential-

gleichung mit numerischer Integration“ und „Weiterleiten der

Geschwindigkeits- und Bewegungsvektoren an die Übertragungselemente–

bilden die physikalische Grundlage zur Aufteilung eines Gesamtmodells in

zwei Teilmodelle für die Cosimulation. Eine Masse wird hierzu

zweckmäßigerweise in eine Master- und eine Schattenmasse geteilt. Die

Mastermasse besitzt die physikalischen Eigenschaften einer Masse

(Trägheit) und kann die Bewegungsdifferentialgleichung – für den Zeitpunkt

t - bereitstellen. Der durch Integration ermittelten Geschwindigkeitsvektor

sowie der durch nochmalige Integration gewonnene Bewegungsvektor – für

den Zeitpunkt t+dt - werden direkt an die Schattenmasse weitergeleitet, die

nicht anderes tut, als diese an das angekoppelten Übertragungselement


weiterzuleiten und den über das Übertragungselemente zurückgekoppelten

Kraftvektor für den Zeitpunkt t+dt zu empfangen. Dieser Kraftvektor wird

anschließend an die Mastermasse weitergeleitet, woraufhin der Vorgang

für den nächsten Zeitschritt wiederholt werden kann (Bild 52).

Integrationt t + dt

t + dtM

Gesamtmodell

Teilmodell 1

Momenten-geber

Teilmodell 2Drehzahl-

geber

Master Schatten

Bild 52: Teilung eines MKS-Modells in zwei Teilmodelle

Zur einfachen Realisierung von Master- und Schattenmassen in der

SIMDRIVE3D-Modellumgebung wird ein neues Massenelement (Cosim-

Masse) eingeführt, das über eine Schnittstelle zum Austausch von Kraft-

bzw. Weginformationen verfügt. Die Teilung eines Modells erfolgt durch

Teilung einer Masse in eine Master- (Sender-) und eine Schattenmasse

(Empfängermasse), die – wenn gekoppelt - während der Cosimulation

Kraft- und Wegdaten austauschen. Der Datenaustausch erfolgt in der

Regel netzweit zwischen den Simulationsprozessen der beiden

Teilmodelle.


Die Realisierung des Kopplungsprozesses zwischen Sender- und

Empfängermassen in einer netzweit verteilten Modellumgebung erfordert

zusätzlich die Entwicklung einer weiteren – virtuellen - Hilfsmasse. Diese

so genannte „externe Cosim-Masse“ verwaltet neben relevanten

Cosimulationsdaten (z.B. Kraft- und Bewegungsvektoren) auch alle

erforderlichen Informationen zur Kommunikation und zum Datenaustausch

zwischen den Simulationsprozessen. Jede Sender- bzw. Empfängermasse

wird mittels eines speziellen Koppelelements um eine externe Cosim-

Masse erweitert. Die Kopplung der Sender- und Empfängermassen erfolgt

dann – indirekt – über deren externen Cosim-Massen (Bild 53).

Externe Cosim-MasseKopplungsstelle zu externemSimulationsprozess (Sender)

Cosim-Masse (Empfänger)

Koppelelemente zurCo-Simulation

Cosim-Masse (Sender)

Externe Cosim-MasseKopplungsstelle zu externem

Simulationsprozessen (Empfänger)Externe Cosim-Masse

Kopplungsstelle zu externemSimulationsprozess (Sender)

Cosim-Masse (Empfänger)

Koppelelemente zurCo-Simulation

Cosim-Masse (Sender)

Externe Cosim-MasseKopplungsstelle zu externem

Simulationsprozessen (Empfänger)

Bild 53: Erweiterung der SIMDRIVE3D-Modellierungsumgebung zur

Kopplung der Simulationsdaten von drei MKS-Simulationsteilmodellen


5.5.2 Datenkommunikation und Prozesssteuerung während der Cosimulation

Zum Datenaustausch zwischen den Simulationsprozessen werden in der

Laufzeit Kommunikationskanäle eingerichtet. Neben Kraft- und

Bewegungsinformationen werden – wie bereits ausgeführt - während der

Cosimulation auch Daten zur Steuerung bzw. Synchronisation der

beteiligten Prozesse ausgetauscht. Grundsätzlich unterscheidet man

zwischen zentralen und dezentralen Kommunikationsarchitekturen. Bei der

zentralen Kommunikationsarchitektur sendet jeder Prozess seine Daten zu

einem Steuerungsprozessor (Controller), der dann die Daten analysiert und

entsprechend an anderen Prozessen weiterleitet (Bild 54). Der Controller

übernimmt auch die Synchronisation der Simulationsprozesse, d.h. alle

Simulationsprozesse arbeiten mit der gleichen Zeitschrittweite (synchrone

Cosimulation).

Controller

1 Sender 1. liefert Wegvektor2. erhält Kraftvektor

2 Empfänger 1. erhält Wegvektor2. liefert Kraftvektor

Step1 (Kraftvektor von Masse m2 übergeben)Step1 (Kraftvektor von Masse m2 übergeben)

TransmitterKenngrößeweiterleiten


Step1b (Kraftvektor der Masse m1 zuweisen)Step1b (Kraftvektor der Masse m1 zuweisen)

Step2 (Zeitschrittweite ∆ t2 übergeben)Step2 (Zeitschrittweite ∆ t2 übergeben)

Step2b (Zeitschrittweite ∆ t1 übergeben)Step2b (Zeitschrittweite ∆ t1 übergeben)

Step3 (Neue Zeitschrittweite ∆ t übernehmen)Step3 (Neue Zeitschrittweite ∆ t übernehmen)

Step3b (Neue Zeitschrittweite ∆ t übernehmen)Step3b (Neue Zeitschrittweite ∆ t übernehmen)



Step4 (Wegvektor von Masse m1 übergeben)Step4 (Wegvektor von Masse m1 übergeben)

Step4b (Wegvektor der Masse m2 zuweisen)Step4b (Wegvektor der Masse m2 zuweisen)

SynchronisatorZeitschritt-Managem.

∆ t= f (∆ t1, ∆ t2)

SynchronisatorZeitschritt-Managem.

∆ t= f (∆ t1, ∆ t2)

Master

Schatten

m1

m2

Bild 54: Konzept der synchronen Cosimulation mit zentraler

Kommunikationsarchitektur


Da die beteiligten Simulationsprozesse nur mit dem Controller Daten

austauschen müssen, ist dieser Kommunikationsaufbau einfach und

überschaubar. Weiterhin kann der Controller entsprechende Maßnahmen

ergreifen, wenn es zu Störungen in der Kommunikation bzw. Simulation

kommen sollte. Den Kommunikationsablauf kann man in folgenden

Schritten zusammenfassen:

• Schritt 1

Simulationsprozess mit der Empfängermasse m2 sendet seinen Kraftvektor

zum Zeitpunkt t an die Sendermasse m1 des gekoppelten Teilmodells

(Step 1/1b).

• Schritt 2

Beide Simulationsprozesse machen einen Abgleich der Zeitschrittweite mit

dem Controller und warten auf den Empfang der neuen Zeitschrittweite ∆t

(Step 2/2b bzw. 3/3b).

• Schritt 3

Der Simulationsprozess mit der Sendermasse m1 simuliert den Zeitschritt

∆t und sendet dem Simulationsprozess mit der Empfängermasse m2

seinen Bewegungs- und Geschwindigkeitsvektor (Step 4b).

• Schritt 4

Der Simulationsprozess mit der Empfängermasse m2 wartet auf den

Empfang des Wegvektors und simuliert anschließend den Zeitschritt ∆t

(Step 4). Der Ablauf wiederholt sich dann mit dem Schritt 1.


Bild 55 zeigt den prozesstechnischen Aufbau der synchronen Cosimulation

mit zentraler Kommunikationsarchitektur für zwei SIMDRIVE3D-Prozesse.

Die Ausführung von Simulationen erfolgt auf jedem Rechner über einen

sogenannten lokalen Server-Dienst (Remote Application Service). Der

lokale Server-Dienst wird grundsätzlich auf allen beteiligten Rechnern des

verteilten Rechnernetzes installiert: zu seinen Aufgaben gehört neben

Ausführung von Simulationen auch die Verwaltung bzw. Bereitstellung von

Cosimulationsmodellen.

Arbeitsplatz 1

SIMDRIVE 3DPre- und Postprozessor

Simulations-kern

Daten u.Modelle

Controller

Datenkanal (M, ϕ, ϕ, ..) Datenkanal (M, ϕ, ϕ, ..)

Modell-Info Modell-Info

Steuersignale

API

Remote Application Service Admin-Tool Remote Application ServiceAdmin-

Tool

API

Arbeitsplatz 2

Daten u.Modelle

Simulations-kern

M1 M2

Verknüpfungs-informationen

Steuersignale


Arbeitsplatz 1


Simulations-kern

Daten u.ModelleDaten u.Modelle

ControllerController

Datenkanal (M, ϕ, ϕ, ..)Datenkanal (M, ϕ, ϕ, ..)Datenkanal (M, ϕ, ϕ, ..) Datenkanal (M, ϕ, ϕ, ..)Datenkanal (M, ϕ, ϕ, ..)Datenkanal (M, ϕ, ϕ, ..)

Modell-Info


SteuersignaleModell-In

fo

Steuersignale

APIAPI


ToolRemote Application ServiceRemote Application Service Admin-Tool

Admin-Tool Remote Application ServiceRemote Application ServiceAdmin-

ToolAdmin-

Tool

APIAPI

Arbeitsplatz 2


Simulations-kern

M1 M2


M1 M2


Steuersignale


Bild 55: Prozesstechnischer Aufbau der synchronen Cosimulation mit

zentraler Kommunikationsarchitektur

Wie bereits ausgeführt übernimmt der Controller neben der

Prozesssteuerung auch die Zeitschrittsteuerung und Datentransfer

zwischen den Simulationsprozessen. Aufgrund der zentralen Daten-

kommunikation kann allerdings diese Architektur bei komplexeren Modellen

zu Überlastung des Controller-Prozesses und dementsprechend zu


Simulationsverzögerungen führen. In einem verbesserten Kommunikations-

konzept wird, zur Entlastung des Controllers, der Datentransfer zwischen

den Simulationsprozessen über externe Kommunikationskanäle

abgewickelt (Bild 56).

Nach dieser Architektur können die Simulationsprozesse nach dem

Abgleich ihrer Zeitschrittweiten über den Controller (Synchronisation) direkt

Bewegungs- bzw. Kraftvektoren austauschen. Die Datenkommunikation

erfolgt dann dezentral über einen direkten Datenkanal zwischen den

Simulationsprozessen auf Basis von TCP-Protokollen 15.

Arbeitsplatz 1


Simulations-kern


Controller

Modell-Info


SteuersignaleModell-In

fo

Steuersignale

APIAPI


ToolRemote Application ServiceRemote Application Service Admin-Tool

Admin-Tool Remote Application ServiceRemote Application ServiceAdmin-

ToolAdmin-

Tool

APIAPI

Arbeitsplatz 2


Simulations-kern

Steuersignale


Zeitschrittsteuerung

Prozesssteuerung

Datenkanal (M, ϕ, ϕ, ..)Datenkanal (M, ϕ, ϕ, ..)

Bild 56: Architektur zur synchronen Cosimulation bei dezentraler

Datenkommunikation zwischen den Cosimulationsprozessen

15 TCP (Transmission Control Protocol) ist ein verbindungsorientiertes Transportprotokoll und

stellt vor der Datenübertragung eine gesicherte Verbindung zwischen den Instanzen her.


Durch die Entlastung des Controllers wurde es möglich, stellenweise auch

mehr als zwei Simulationsprozesse zu verwalten bzw. zu synchronisieren.

Die Stabilität dieses Vorgangs war allerdings stark von der Netzbelastung

und der Rechengeschwindigkeit der beteiligten Simulationsprozesse

abhängig. Wegen der synchronen Zeitschrittsteuerung ist jeder Prozess

gezwungen, auf den Empfang bestimmter Daten zu warten. Ist der

Absenderprozess oder das Kommunikationsnetz überlastet, so kommt es

zu Kommunikationsverzögerungen bzw. Zeitlimitüberschreitungen des

Servers (server timeouts). Eine effektive Verbesserung der Simulations-

geschwindigkeit bzw. Prozessstabilität kann durch ein erweitertes Konzept

auf Basis asynchroner Cosimulation erreicht werden(siehe nächsten

Abschnitt).

5.5.3 Prozesssynchronisation

Im vorigen Abschnitt wurde gezeigt, dass bei der Cosimulation nach dem

Konzept des Programmverbunds jeder Simulationsprozess über einen

eigenen Solver und eigener Zeitschrittweitensteuerung verfügt und

demzufolge eine externe Synchronisation bzw. Abstimmung der

Zeitschrittweiten zwischen den Simulationsprozessen erforderlich ist. Dabei

sendet jeder Simulationsprozess seine optimale Schrittweite für den

nächsten Simulationsschritt an den Controller. Nachdem die gewünschten

Zeitschrittweiten aller Prozesse bei dem Controller angekommen sind,

ermittelt dieser die minimale erforderliche Zeitschrittweite und sendet diese

an alle Simulationsprozesse, die dann mit dieser Zeitschrittweite

weitersimulieren (synchrone Cosimulation). Der Nachteil dieses Verfahren

liegt vor allem darin, dass die Gesamtsimulationsgeschwindigkeit bei jedem

Zeitschritt von der kleinsten Zeitschrittweite dominiert wird (siehe auch Bild

54). Zusätzlich kann eine synchrone Cosimulation numerisch bedingte

Probleme zur Folge haben.

In [Andrew01] wird anhand eines einfachen Beispiels in der Umgebung des

MKS-Systems ADAMS gezeigt, dass eine externe Zeitschrittsteuerung bei

den Simulationsprozessen zu Systeminstabilität und Fälschung der


Ergebnisse führen kann. Dabei wird ein Einmassenschwinger

(Eigenfrequenz ca. 100 Hz) mit ADAMS modelliert und von außen mit einer

periodischen Kraft (Frequenz 1 Hz) angeregt. Der ADAMS-Solver simuliert

mit einer festen Zeitschrittweite von 0.04 Sek., der externe Prozess mit

einer festen Zeitschrittweite von 0.02 Sek. Man würde denken, dass eine

Abtastrate von 50/Sek. für eine periodische Kraft mit der Frequenz von

einem Hertz mehr als ausreichend wäre, um gute Simulationsergebnisse

zu erreichen. Das Bild 57 stellt den simulierten Federweg aus der

Cosimulation dem analytisch errechneten Federweg gegenüber. Man stellt

Abweichungen sowohl in der Amplitude als auch in der Phasenlage fest.

Bild 57: Federweg eines Einmassenschwingers nach [Andrew01],

analytisch exakte und diskrete cosimulierte Lösung

Eine Erhöhung der Zeitschrittweite des ADAMS-Solvers sowie eine

Verfeinerung der Abtastrate der Erregerkraft bringt keine nennenswerte

Verbesserung der Ergebnisse und führt zusätzlich zu Simulations-

instabilitäten. Es ist offensichtlich, dass eine akzeptable Simulations-

genauigkeit erst bei einer dynamischen Zeitschrittweitensteuerung der

Solver zu erreichen ist. Dazu müssen beide Simulationsprozesse in der

Lage sein, mit eigener optimaler Zeitschrittweite zu simulieren (asynchrone

Cosimulation). Unter der Voraussetzung, dass der ADAMS-Solver mit einer

größeren Zeitschrittweite simulieren würde, wird in [Andrew01] das


Konzept einer Schnittstelle mit einem Extrapolator auf der Seite des

ADAMS-Solvers und einem Interpolator auf der Seite des externen

Simulationsprozesses vorgestellt.

Das Konzept einer asynchronen Cosimulation wurde auch bei

SIMDRIVE3D favorisiert. Wichtige Argumente dafür waren:

• Eine dynamische Zeitschrittweitensteuerung bei den Cosimulations-

prozessen würde zur Verbesserung deren Simulationsgeschwindigkeit

bzw. Simulationsqualität führen.

• Die Prozesssynchronisation würde dann nicht mehr zentral über denn

Controller (siehe Bild 56), sondern direkt zwischen den gekoppelten

Simulationsprozessen erfolgen. Der Controller würde dann lediglich die

Aufgabe der Prozesssteuerung übernehmen.

• Im Vergleich zu [Andrew01] sollte das Konzept der asynchronen

Cosimulation in der SIMDRIVE3D-Umgebung noch folgende Zusatz-

anforderungen erfüllen:

• Es soll eine Cosimulation zwischen mehr als zwei Simulationsprogrammen

möglich sein.

• Die Simulationsprogramme sollen auf mehreren Rechnern im Netz verteilt

sein können.

• Jeder der beteiligten Prozesse soll Drehzahlgeber oder Momentengeber

sein können (siehe Abschnitt 5.5.1).

• Jeder Simulationsprozess soll gleichzeitig mit mehreren anderen

Simulationsprozessen cosimulieren können (multiple Cosimulation).


• Die Simulationsgeschwindigkeiten sowie die Zeitschrittweiten aller

cosimulierenden Prozessen sollen grundsätzlich variabel sein, da i. a. nicht

für die gesamte Betriebszeit festgelegt werden kann, welcher Prozess

während der Cosimulation die maßgebende Zeitschrittweite hat.

Zur Realisierung wurde das Konzept der dezentralen Cosimulation (siehe

Bild 56) erweitert. Die Cosimulationsschnittstelle (im Bild 56 als API

bezeichnet) wurde mit einem Zeitschrittmanagementmodul vorgesehen, so

dass die gekoppelten Simulationsprozesse in der Lage waren, unabhängig

vom Controller ihre Zeitschrittweiten abzugleichen. Jeder

Simulationsprozess konnte über sein Zeitschrittmanagementmodul den

Ablauf aller mit ihm cosimulierenden Prozesse analysieren bzw.

beobachten. Durch Erweiterung der Kraft- und Bewegungsvektoren mit

einem Zeitstempel und deren Pufferung wurden die Simulationsprozesse in

die Lage versetzt, die erforderlichen Simulationsdaten – für eine

gewünschte Zeitschrittweite – zu extrahieren ohne unmittelbar darauf

warten zu müssen (Bild 58).

Ein wichtiger Aspekt bei der Realisierung des Konzeptes war es auch, die

asynchrone Übertragung der Informationen zwischen den Simulations-

prozessen zu meistern. Durch den Einsatz einer verbindungslosen

Kommunikation auf Basis des UDP-Protokolls16 konnten die

Kommunikationsengpässe, die zur Verzögerung bzw. Blockade der

Simulationsprozesse führen, vermieden werden. Bei Verlust kritischer

Simulationsdaten könnten diese direkt oder indirekt (über Controller)

nachgefördert werden.

16 UDP (User Datagram Protocol) unterstützt direktes Versenden von Datenpaketen zwischen

den Prozessen und hat einen minimalen Protokollmechanismus. Eine garantierte Ablieferung

oder Sicherung gegen Duplizierung bzw. Reihenfolgenvertauschung der Datenpakete ist nicht

gegeben.


-------------

Interface

Zeitmanagement-modul DC 1

--------------------------

DC 2

Puffer

SIMDRIVE 3D

DC 1DC 2

Interface PufferInterface Puffer

SIMDRIVE 3D

-------------

--------------------------

-------------

--------------------------

Remote ApplicationServer


Admin-Tool

Admin-Tool

• Modellierung Gesamtmodel

• Verknüpfungsinformationen

• Steuerung

• Messages

• Errorhandling

Controller



Admin-Tool

Admin-Tool

Zeitmanagement-modul

Bild 58: Konzept einer asynchronen Cosimulation

Mit diesem Konzept wird die Aufgabe der Synchronisation nicht mehr

zentral über den Controller, sondern von den beteiligten

Simulationsprozessen selbst abgewickelt. Damit werden die

kommunizierenden Prozesse in die Lage versetzt, ihre Zeitschrittweiten

untereinander optimal anzupassen. Der Controller übernimmt primär die

Aufgaben der Steuerung bzw. Fehlerbehandlung während der gesamten

Cosimulation (Bild 59).


Simulations-Programm

P3


P2


P1


Pn

AppServer

AppServer

AppServer

AppServer

AppServerAppServer

AppServerAppServer

AppServer

AppServer

AppServer

AppServer• Modellierung Gesamtmodel

• Verknüpfungsinformationen

• Steuerung

• Messages

• Errorhandling

Controller

Bild 59: Konzept dezentraler (n:n)-Cosimulation

Die (n:n)-Kopplung nach dem Bild 57 wurde zwischen vier

Simulationsprogrammen mittlerer Komplexität erfolgreich erprobt.

Grundsätzlich wird die Anzahl maximal möglicher Cosimulationsprozesse

durch Leistungsfähigkeit der Hardware sowie Belastbarkeit der

Kommunikationsnetze beeinflusst.


5.5.4 Realisierung der Cosimulation in der SIMDRIVE3D-Umgebung

Der Aufbau der Cosimulation basiert bei SIMDRIVE3D auf einer multiplen

Client-Server-Architektur. Grundsätzlich unterscheidet man zwischen

verteilten und zentralen Server-Diensten. Der lokale Server-Dienst

„Remote Application Service“ wird grundsätzlich auf allen beteiligten

Rechnern des verteilten Rechnernetzes installiert. Seine Aufgabe ist die

Ausführung von Simulationen sowie die Bereitstellung von

Cosimulationsmodellen. Der Anwender kann von einer SIMDRIVE3D-

Sitzung aus seine Modelle zur Cosimulation bei dem lokalen Server-Dienst

registrieren (Bild 60).

Alle für die Cosimulation relevanten Modellinformationen wie

Modellbezeichnungen, Anzahl und Typ der Cosim-Massen etc. werden

somit den zentralen Server-Diensten „Controller“ zur Verfügung gestellt.

Zusätzlich verfügt der lokale Server-Dienst über erforderliche

Informationen, um einen Simulationsprozess zu starten und seine

Cosimulationsmodelle zu laden.

Cosim-Masse Registrieren

Cosim-Modell Registrieren

Bild 60: Registrierung der Cosimulationsmodellen beim lokalen Server-

Dienst


Zur Einbindung von externen Simulationsprogrammen in die Simdrive-

Cosimulationsumgebung steht eine programmierbare Schnittstelle (Cosim-

API) in Fortran bzw. C/C++ zur Verfügung. Die Registrierung von externen

Cosimmodellen beim lokalen Dienst-Server kann dann über eine Register-

Karte manuell erfolgen (Bild 61).

Bild 61: Manuelles Registrieren von Cosimulationsmodellen beim lokalen

Server-Dienst

Das Zusammenführen mehrerer Teilmodelle zu einem Gesamtmodell und

die Durchführung von Cosimulationen erfolgt über den zentralen Server-

Dienst (Controller). Über einen Scan-Tool können alle lokalen Server-

Dienste gesucht und nach Überprüfung der Zugriffsrechte des Anwenders

registriert werden (Bild 62).


Bild 62: Scan-Tool zur Suche nach lokalen Server-Diensten

Sind bei den lokalen Server-Diensten Cosimulationsmodelle verfügbar und

ist der Anwender berechtigt diese Modelle anzuwenden, so kann er die

Modelle bzw. deren Cosim-Massen über ein Auswahl-Tool selektieren und

in seine Modellumgebung einbinden (Bild 63).

Bild 63: Auswahl-Tool zum Selektieren der Cosim-Elemente


Bild 64 zeigt die Zusammenführung eines Kurbelwellenmodells, eines

Generatormodells und eines Riementriebmodells zu einem Gesamt-

simulationsmodell.

Rechnerarbeitsplatz mit dem Kurbelwellenmodell

Rechnerarbeitsplatz mit dem Generatormodell Rechnerarbeitsplatz mit dem Gesamtmodell

Bild 64: Zusammenführung von Teilmodellen zu einem Gesamt-

Cosimulationsmodell

Der zentrale Server-Dienst ist vollständig in der SIMDRIVE3D-Umgebung

integriert, so dass alle modell- bzw. prozesstechnische Aktivitäten

unmittelbar ausgeführt werden können. Der große Vorteil dabei ist, dass

Cosimulationsmodelle wie alle anderen SIMDRIVE3D-Modelle auch über

den gesamten Leistungsumfang des Simulationswerkzeugs – z.B.

Postprocessing-Tools zur Auswertung der Simulationsergebnisse -

verfügen. Die Cosimulatinsmodelle können auch - wie gewohnt -


gespeichert werden. SIMDRIVE3D bzw. der Controller überprüft beim

Laden eines Cosimulationsmodells die Verfügbarkeit der lokalen Server-

Dienste und Modellverknüpfungen. Der Anwender bekommt dann

entsprechende Warnungen, falls ein Server nicht erreichbar ist oder wenn

irgendwelche Teilmodelle bzw. Modellverknüpfungen nicht verfügbar sind.

6 Zusammenfassung

Im Rahmen dieser Arbeit wurden Konzepte zur Entwicklung und Integration

von produktabhängigen und produktklassenabhängigen Berechnungen

sowie von verteilten Berechnungsprozessen für den Produktentwicklungs-

prozess erarbeitet und realisiert.

Durch eine umfassende Modellanalyse wurde gezeigt, dass sich einige

dieser Konzepte nur dann weitgehend allgemein anwenden lassen, wenn

die zu untersuchenden Produkte eine in engen Grenzen variable Struktur

besitzen und der damit verbundene Modellierungsaufwand bei der

Anwendung nicht zu hoch ist. Die Modellanpassung kann dann

überwiegend über Eingabeparameter oder Eingabeparameterlisten, die

durchaus eine komplexe Datenstruktur aufweisen können, erfolgen.

Ergänzend zu diesen auf einer Parametrisierung aufsetzenden Konzepten,

die mittels Parameter-Wrapping eine vollständige Abkopplung der

Berechnungsmodelle von den Produktmodelldaten ermöglichen, wurde

auch der Einsatz moderner Web-Technologien zur Realisierung solcher

parametrisierten Berechnungsmethoden behandelt. Der sequentielle

Einsatz mehrerer miteinander vernetzter Berechnungen ist nur dann

zulässig, wenn die Systemkomponenten als rückwirkungsfrei betrachtet

werden können.

Zur Analyse komplexer dynamischer Systeme, die nur in gewissen

Betriebsbereichen als rückwirkungsfrei betrachtet werden können, wurden

Konzepte zur Entwicklung und Integration von numerischen Berechnungs-

verfahren mit flexibler Modellstruktur vorgestellt und realisiert. Es wurde am

Beispiel des zusammen mit der Automobilindustrie entwickelten MKS-

Systems SIMDRIVE3D gezeigt, dass der Entwicklungsaufwand für

praxistaugliche Simulationsberechnungsbausteine in der Regel sehr hoch

ist und die zugehörigen Konzepte eher individuell und selten

verallgemeinerbar sind. Grund hierfür sind die hohen Genauigkeits-

forderungen an die Simulationsergebnisse, die im allgemeinen nur mit

nichtlinearen Berechnungsansätzen realisierbar sind. Analytische einfache

6 Zusammenfassung 132

Lösungsverfahren scheiden für die Anwendung praktisch aus, sodass

notwendigerweise der Weg über eine flexible, damit diskrete

Modellgestaltung führen muss. Der vielfältige Einsatz verschiedenartigster

Simulationsbausteine für beispielsweise Riemen- und Kettentriebe sowie

Kurbeltriebe in der industriellen Anwendung erfordert aus

systemtechnischer Sicht auch die Integration dieser MKS-Bausteine zur

Simulation des Gesamtantriebs für den Produktentwicklungsprozess.

Deshalb wurde zusätzlich zur Datenintegration auch die Integration

gekoppelter Simulationsprozesse mittels synchroner und asynchroner

Cosimulation behandelt und Konzepte und Lösungen für solche komplexen

Berechnungsprozesse erarbeitet und erprobt.

Die systemanalytische Betrachtung der Berechnungsverfahren, die

Klassifizierung der Berechnungsmethoden nach Zeiteinfluss, Modellstruktur

und Methoden-Kopplungspotential sowie die realisierten Integrations-

konzepte in dieser Arbeit bieten den Entwicklern von Berechnungs-

verfahren eine schnelle Hilfe zur Zuordnung bzw. Abschätzung des

Entwicklungsaufwands sowie zur Suche nach optimalen Lösungs-

möglichkeiten.

Die Konzepte zu parametrisierten Berechnungsmodellen wurden im

Rahmen des DFG-Schwerpunktprogramms: „Innovative rechnerunter-

stützte Konstruktionsprozesse: Integration von Gestaltung und

Berechnung“ erarbeitet. Die Konzepte zur Entwicklung und Simulation von

MKS-Bausteinen und deren Einbindung in den Produktent-

wicklungsprozess entstanden in jahrlanger Zusammenarbeit zwischen dem

Fachgebiet Konstruktionslehre, der aus dem Fachgebiet ausgegründeter

Firma „Contecs engineering services GmbH“ und Firmen der deutschen

Automobilindustrie.

7 Literatur

[And-SPP] Anderl, R.: Integration von Produktentwicklungsmethoden über

Gestaltung-Berechnungs-Beziehungen. Kurzbericht zu DFG-SPP

[SPP].

[Andrew01] Andrew S. Elliott: A Highly Efficient, General-Purpose Approach

for Co-Simulation with ADAMS. Mechanical Dynamics, Inc.

480.985.1557.

[Bath90] Bathe, K.J.: Finite Elemente Methoden. Springer-Verlag; Berlin

1990.

[Beck94] Becker, M.: Innerbetriebliche Technologiefolgen am Beispiel von

CAD-Systemen. Studienarbeit Universität; Kaiserslautern 1994.

[Bra03] Braun, P.: Objektorientierte Wissensarchivierung und

Wissensverarbeitung in modellassoziierten Gestaltungs- und

Berechnungssystemen. Shaker-Verlag Aachen 2003; ISBN

3-8265-7768-X.

[CAT99] Verkürzte Entwicklungsprozesse durch Integration von Gestaltung und Berechnung. Potentiale und Erfahrung ;

Tagung Stuttgart, 8. 9. Juni 1999 anlässlich CAT-Engineering 99;

ISBN 3-18-091487-4.

[Dres04] Dresig, H. ; Holzweißig,. F. ; Rockhausen, L.: Maschinendynamik. Springer Verlag; Berlin 2004; ISBN

3540225463.

[Dyla02] Dyla, A.: Modell einer durchgängig rechnerbasierten Produkt-

entwicklung. FZG; München 2002; ISBN 3-00-009684-1.

II

[Engel96] Engeln-Müllges, G.: Numerik-Algorithmen. VDI-Verlag;

Düsseldorf 1996. ISBN 3-18-401539-4.

[Fayd03] Faydor, L.: Gear Geometry and Applied Theory. Cambridge

University Press 2003; ISBN 0521815177.

[Fair99] Fairlie, Boris.: Zur Verarbeitung von Berechnungserfahrung und

Informationsunschärfe bei der rechnerunterstützten Produkt-

auswahl. Fortschrittsbericht, VDI-R 1, Nr. 311; Düsseldorf 1999.

[Gärt01] Gärtner A., Van de Sand, A.: Auslegung von Fahrwerk-

systemen durch Cosimulation von MKS- und Fluidsimulations-

software. Haus der Technik; Essen 2001.

[Gip99] Gipser M.: Systemdynamik und Simulation, Teubner Verlag;

Esslingen 1999.

[Gra93] Grabowski, H. ; Anderl, R.: Inegriertes Produktmodell, Beuth-

Verlag; Berlin 1993.

[Grab96] Grabowski, H. ; Oertel, H. ; Rude, S. ; Maul, J. ; Velten, V.: Anforderungen an CAD-Systeme zur Integration von

numerischen Strömungsberechnungsverfahren. Konferenz-

beitrag zur CIM 96. Zakopane, Polen, vom 14.-17. Mai 1996.

[Gra97] Grabowski, H. ; Geiger, K.: Neue Wege zur Produkt-

entwicklung. Raabe Fachverlag für Wissenschaftsinformation;

Bonn 1997.

[Grot04] Grote, K.H. ; Feldhusen, J.: Dubbel Taschenbuch für den

Maschinenbau. Springer Verlag; Berlin 2004. ISBN 3540221425.

III

[Hard00] Harderer, G.: Integration von Gestaltung und Berechnung mittels

CORBA. Diss. TU-Berlin; 2000.

[HerHom89] Hertwich, RG ; Hommel, G. : Kooperation und Konkurrenz;

Nebenläufige verteilte und echtzeitabhängige Programm-

systeme. Springer Verlag; Berlin 1989.

[Heub00] Heubner, Axel.: Simulation von Synchronriementrieben mit

Spannelementen. Fortschrittsbericht, VDI-R 1, Nr. 330;

Düsseldorf 2000.

[iViP] Das Leitprojekt integrierte Virtuelle Produktentstehung iViP Abschlussbericht (1998-2002); Fraunhofer IRB Verlag 3-8167-

6165-8

[John03] Johnson, KL: Contact Mechanics. Cambridge University Press

2003, ISBN 0521347963.

[Krast02] Krastel, M.; Merkt, T.: Integration der Simulation und

Berechnung in eine PDM-Umgebung. Produktdaten Journal

2002.

[Krast04] Krastel, M.; Merkt, T.: Integration der Simulation und

Berechnung in eine PDM-Umgebung – die Arbeitsgruppe

SimPDM. Produktdaten Journal, Herbst 2004.

[Krau01] Krause, F.-L. ; Tang, T. ; Ahle, U.: Integrierte Virtuelle

Produktentstehung (iVip). Fortschrittsbericht. Fraunhofer IRB

Verlag; Stuttgart. 2001.

[Krau05] Bley, H.; Jansen, H. ; Krause, F.-L.; Spitalni, M.: 2. GERMAN-

ISRAELI SMPOSIUM on Design and Manufacture. Fraunhofer

IRB-Verlag; Berlin 2005; ISBN 3-8167-6874-1.

IV

[Krau97] Krause, F.-L. ; Carl A.: Neuronale Netze in der

Produktentwicklung. Konstruktion Vol. 47, 1997, ISSN 0720-5953

[Krau-SPP] Krause, F.-L.: Neuronale Netze basiertes Assistenzsystem zur

Integrierten Unterstützung des Entwicklungsprozesse. Kurz-

bericht zu DFG-SPP [SPP].

[KrauUhl98] Krause, F.-L. ; Uhlmann E.: Innovative Produktionstechnik. Carl

Hanser Verlag; München 1998.

[Küm99] Kümmlee, H.: Möglichkeiten und Grenzen des Einsatzes

moderner EDV-Verfahren zur Optimierung großer elektrischer

Grenzleistungsmaschinen. VDI-Berichte Nr. 1487, 1999, S. 177-

201.

[Lip01] Lippeck, A.: Entwicklung und Anwendung einer Richtlinie zur

Modellbildung und Simulation hybrider biomechanischer

Mehrkörpersysteme. Dissertation FB Maschinenwesen

Universität Essen 2001.

[Mark03] Markworth, R.: Entwicklungsbegleitendes Digital Mock-Up im

Automobilbau. Shaker-Verlag; Aachen 2003; ISBN 0945-0831.

[Me95] Mertens, H.: Festigkeitsberechnungen und Konstruktions-

prozess. VDI-Berichte Nr. 1227, 1995; S. 1-25.

[Me98] Mertens, H.: Aussagegüte und Zeitaufwand – Kriterien zur

Auswahl von Berechnungsmethoden im Konstruktionsprozess.

In: VDI-Berichte Nr. 1442; Düsseldorf 1998.

[Me99] Mertens, H.: Verkürzte Entwicklungsprozesse durch Integration

von Gestaltung und Berechnung. VDI-Ber. Nr. 1487; Düsseldorf:

1999.

V

[MeMiWo] Mertens, H. ; Mirkheshti, R. ; Wölfle F.: Rechnerunterstützte

flexible Zusammenarbeit zwischen verteilten Konstruktions- und

Berechnungsarbeitsplätzen. Konstruktion 1/2-2002 S. 67-72.

[Mill98] Millet, P.: Zur Berechenbarkeit des dynamischen Verhaltens von

Ringscheiben- und Laschenkupplungen. W&T-Verlag Berlin

1998.

[Mue95] Müller, G. ; Rehfeld, I.: FEM für Praktiker; Expert Verlag 1995;

ISBN 3-8169-1123-4.

[OMG] Object Management Group: http://www.omg.org.

[Pays00] Paysan, G.: Ein Wirkzonenkonzept zur Simulation des

Verschleiß- und Tragverhaltens reibkorrosionsgefährdeter

Maschinenelemente. Dissertation TU-Berlin 2000.

[Rea98] Reaz, Hoque: Programming JAVA Beans. McGraw-Hill

Companies 1998.

[Roth00] Roth, K.H.: Zahnradtechnik, Stirnrad-Evolventenverzahnung.

Springer Verlag; Berlin 2000. ISBN 3540676503.

[Rumb94] Rumbaugh, J. ; Blaha M.: Objektorientiertes Modellieren und

Entwerfen. Hanser-Verlag; München 1994.

[Rust97] Rusty Harold, Elliot.: JAVA Network Programming. O’Reilly &

Associates 1997.

[Schäf90] Schäfer, H.: CAD/CAM Planung langfristiger Gesamt-

konzeptionen. Düsseldorf: VDI-Verlag 1990.

VI

[Schn05] Schneider, J. ; Reichart, M.: Neue Technologien im Produkt-

innovationsprozess. Fachhochschule Vorarlberg, Februar 2005.

ISSN 1814-1293.

[Seil85] Seiler, W.: Technische Modellierungs- und Kommunikations-

verfahren für das Konzipieren und Gestalten auf de Basis der

Modell-Integration. Fortschritts-Berichte, Reihe 10 Nr. 49. VDI-

Verlag; Düsseldorf 1985.

[SpKrau97] Spur, G. ; Krause, F.-L.: Das virtuelle Produkt. München: Carl

Hanser Verlag 1997.

[SPP] http://keepcool.kf.tu-berlin.de/public/spp/index.html

http://contecs-engineering.de/spp/index.html

Projektplattform zum Schwerpunktprogramm „Innovative

rechnerunterstützte Konstruktionsprozesse: Integration von

Gestaltung und Berechnung“.

[Steg95] Steger, W.: Berechnungen in den frühen Phasen der

Produktentwicklung, in: Veröffentlichungen des SFB 346.

Universität Karlsruhe 1995.

[STiViP] ProSTEP iViP Projektgruppe SimPDM: (http://www.prostep.org/de/projektgruppen/simpdm).

[VDI93] VDI-Richtlinie 2221: Methoden zum Entwickeln und Konstruieren

technischer Systeme und Produkte. Düsseldorf 1993.

[VDI99-1] VDI-Richtlinie 2211, Blatt 2: Datenverarbeitung in der

Konstruktion; Berechnung in der Konstruktion, Entwurf. Berlin

1999.

VII

[VDI99-2] VDI-Richtlinie 2219: Datenverarbeitung in der Konstruktion;

Einführung und Wirtschaftlichkeit von EDM/PDM-Systemen.

Düsseldorf 1999.

[VDI99-3] VDI-Richtlinie 2218: Feature-Technologie. Düsseldorf 1999.

[VDI99-4] VDI-Richtlinie 2294: CAD-Benutzungsfunktionen. Düsseldorf

1999.

[Wrig01] Wriggers, P.: Nichtlineare Finite-Elemente-Methoden. Springer-

Verlag 2001; ISBN 3-540-67747-X.

[Woe98] Wölfle, F.: Virtuelle Berechnungskompetenzzentren als

Dienstleister zur Integration von Gestaltung und Berechnung.

Fortschrittsbericht, VDI-R 20, Nr. 274. Düsseldorf 1998.

Documents

Zur Entwicklung von Berechnungsmethoden und deren ... · In VDI 2221 [VDI93] wird der Konstruktionsprozess in vier Phasen, „Klären und Präzisieren der Aufgabenstellung“, „Konzipieren“,