Zur Entwicklung von Berechnungsmethoden und deren ... · In VDI 2221 [VDI93] wird der...
Transcript of Zur Entwicklung von Berechnungsmethoden und deren ... · In VDI 2221 [VDI93] wird der...
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.
1.2 Einsatz von Berechnungsprogrammen in der DV-gestützten Produktkonstruktion 5
• 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 Einsatz von Berechnungsprogrammen in der DV-gestützten Produktkonstruktion 7
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].
1.2 Einsatz von Berechnungsprogrammen in der DV-gestützten Produktkonstruktion 9
• 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 Einsatz von Berechnungsprogrammen in der DV-gestützten Produktkonstruktion 11
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.
1.2 Einsatz von Berechnungsprogrammen in der DV-gestützten Produktkonstruktion 13
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].
1.2 Einsatz von Berechnungsprogrammen in der DV-gestützten Produktkonstruktion 15
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,
1.2 Einsatz von Berechnungsprogrammen in der DV-gestützten Produktkonstruktion 17
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
1.3 DFG-Schwerpunktprogramm zur Integration von Gestaltung und Berechnung 19
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.
1.3 DFG-Schwerpunktprogramm zur Integration von Gestaltung und Berechnung 21
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).
1.3 DFG-Schwerpunktprogramm zur Integration von Gestaltung und Berechnung 23
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
1.3 DFG-Schwerpunktprogramm zur Integration von Gestaltung und Berechnung 25
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
1.3 DFG-Schwerpunktprogramm zur Integration von Gestaltung und Berechnung 27
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
1.3 DFG-Schwerpunktprogramm zur Integration von Gestaltung und Berechnung 29
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
2.1 Analyse der Systemeigenschaften 35
beschreibbare Teilprodukte oder Teilprozesse unterteilt werden, die über
Systemkopplungen miteinander in Verbindung stehen (Bild 9).
Subsystem 2ParameterZustände
Subsystem 1ParameterZustände
Subsystem 3ParameterZustände
KopplungenSystem-
EingängeSystem-
Ausgänge
Systemgrenze
Subsystem 2ParameterZustände
Subsystem 1ParameterZustände
Subsystem 3ParameterZustände
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
Teilberechnung 2 Teilberechnung
3
Gesamtberechnung
Berechnungs-Ergebnisse
Bild 10: Berechnung und Analyse eines Systems durch sequentiellen
Einsatz mehrerer Teilberechnungen.
2.1 Analyse der Systemeigenschaften 37
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
Teilberechnung 2 Teilberechnung
3
Teilberechnung 1Eingangs-
DatenAusgangs-
Daten
Teilberechnung 2 Teilberechnung
3
Teilberechnung 1
Bild 11: Berechnung und Analyse eines Systems unter Berücksichtigung
der Rückwirkung zwischen den Systemkomponenten.
2 Analyse und Klassifikation von Berechnungen 38
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.
2 Analyse und Klassifikation von Berechnungen 40
• 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].
2.4 Klassifizierung von Berechnungsmethoden nach ihrem Kopplungspotential 41
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
2 Analyse und Klassifikation von Berechnungen 42
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
2.4 Klassifizierung von Berechnungsmethoden nach ihrem Kopplungspotential 43
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
2 Analyse und Klassifikation von Berechnungen 44
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
3 Allgemeines zur Entwicklung und Integration rechnerunterstützter Berechnungstools 48
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
3.1 Analyse der Arbeitschritte zur Entwicklung von Berechnungstools 49
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 Allgemeines zur Entwicklung und Integration rechnerunterstützter Berechnungstools 50
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 Analyse der Arbeitschritte zur Entwicklung von Berechnungstools 51
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.
3 Allgemeines zur Entwicklung und Integration rechnerunterstützter Berechnungstools 52
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 Analyse der Arbeitschritte zur Entwicklung von Berechnungstools 53
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
RechnerinternesDatenmodell
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
3 Allgemeines zur Entwicklung und Integration rechnerunterstützter Berechnungstools 54
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
RechnerinternesDatenmodell
1
RechnerinternesDatenmodell
2
Software-System
2
P1NPN2 PN1P2N
Software-System
1
Bild 17: Indirekt gekoppelte Softwaresysteme
3.1 Analyse der Arbeitschritte zur Entwicklung von Berechnungstools 55
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).
4 Entwicklung und Integration produktabhängiger Berechnungstools 60
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
4 Entwicklung und Integration produktabhängiger Berechnungstools 62
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).
4.2 Entwicklung einer webbasierten Berechnungsmethodenbank 63
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.
4 Entwicklung und Integration produktabhängiger Berechnungstools 64
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
4.2 Entwicklung einer webbasierten Berechnungsmethodenbank 65
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
4 Entwicklung und Integration produktabhängiger Berechnungstools 66
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
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 67
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.
4 Entwicklung und Integration produktabhängiger Berechnungstools 68
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.
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 69
• 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 )
Integrationsumgebung
Berechnungsprogramm
Berechnungsprogramm( Kopie )
Integrationsumgebung
CodeintegrationLoadingClient-Server
Methodenbank
Bild 24: Integrationsformen der Berechnungsmethoden in die
Methodenbank mittels Berechnungsmethodenmanagement
4 Entwicklung und Integration produktabhängiger Berechnungstools 70
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).
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 71
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.
4 Entwicklung und Integration produktabhängiger Berechnungstools 72
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
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 73
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
4 Entwicklung und Integration produktabhängiger Berechnungstools 74
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.
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 75
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.
4 Entwicklung und Integration produktabhängiger Berechnungstools 76
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
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 77
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
4 Entwicklung und Integration produktabhängiger Berechnungstools 78
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
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 79
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.
4 Entwicklung und Integration produktabhängiger Berechnungstools 80
Bild 31: Konzept des Berechnungsintegrationsmanagements
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 81
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
4 Entwicklung und Integration produktabhängiger Berechnungstools 82
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].
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 83
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.
4 Entwicklung und Integration produktabhängiger Berechnungstools 84
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
4.3 Verallgemeinerte Konzepte für produktabhängige Berechnungen 85
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
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 90
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.
5.2 Entwicklung eines MKS-Teilmodells zur dynamischen Untersuchung von Rädertrieben 91
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).
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 92
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
5.2 Entwicklung eines MKS-Teilmodells zur dynamischen Untersuchung von Rädertrieben 93
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).
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 94
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).
5.2 Entwicklung eines MKS-Teilmodells zur dynamischen Untersuchung von Rädertrieben 95
Ü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 Entwicklung und Integration produktklassenabhängiger Berechnungstools 96
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.
5.2 Entwicklung eines MKS-Teilmodells zur dynamischen Untersuchung von Rädertrieben 97
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.
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 98
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).
5.2 Entwicklung eines MKS-Teilmodells zur dynamischen Untersuchung von Rädertrieben 99
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.
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 100
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.
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 102
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).
5.3 Implementierung des Rädertriebmodells in SIMDRIVE3D-Umgebung 103
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
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 104
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)
5.3 Implementierung des Rädertriebmodells in SIMDRIVE3D-Umgebung 105
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 Entwicklung und Integration produktklassenabhängiger Berechnungstools 106
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 107
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
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 108
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
5.4 Integration produktklassenabhängiger Berechnungen in den Produktentwicklungsprozess 109
(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
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 110
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
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 112
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 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 113
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
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 114
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.
5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 115
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 Entwicklung und Integration produktklassenabhängiger Berechnungstools 116
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
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)
TransmitterKenngrößeweiterleiten
TransmitterKenngrößeweiterleiten
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
5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 117
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.
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 118
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
SIMDRIVE 3DPre- und Postprozessor
Arbeitsplatz 1
SIMDRIVE 3DPre- und Postprozessor
Simulations-kern
Daten u.ModelleDaten u.Modelle
ControllerController
Datenkanal (M, ϕ, ϕ, ..)Datenkanal (M, ϕ, ϕ, ..)Datenkanal (M, ϕ, ϕ, ..) Datenkanal (M, ϕ, ϕ, ..)Datenkanal (M, ϕ, ϕ, ..)Datenkanal (M, ϕ, ϕ, ..)
Modell-Info
Modell-Info Modell-Info
SteuersignaleModell-In
fo
Steuersignale
APIAPI
Remote Application Service Admin-Tool Remote Application ServiceAdmin-
ToolRemote Application ServiceRemote Application Service Admin-Tool
Admin-Tool Remote Application ServiceRemote Application ServiceAdmin-
ToolAdmin-
Tool
APIAPI
Arbeitsplatz 2
Daten u.ModelleDaten u.Modelle
Simulations-kern
M1 M2
Verknüpfungs-informationen
M1 M2
Verknüpfungs-informationen
Steuersignale
SIMDRIVE 3DPre- und Postprozessor
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
5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 119
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
SIMDRIVE 3DPre- und Postprozessor
Simulations-kern
Daten u.ModelleDaten u.Modelle
Controller
Modell-Info
Modell-Info Modell-Info
SteuersignaleModell-In
fo
Steuersignale
APIAPI
Remote Application Service Admin-Tool Remote Application ServiceAdmin-
ToolRemote Application ServiceRemote Application Service Admin-Tool
Admin-Tool Remote Application ServiceRemote Application ServiceAdmin-
ToolAdmin-
Tool
APIAPI
Arbeitsplatz 2
Daten u.ModelleDaten u.Modelle
Simulations-kern
Steuersignale
SIMDRIVE 3DPre- und Postprozessor
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.
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 120
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
5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 121
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
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 122
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).
5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 123
• 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.
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 124
-------------
Interface
Zeitmanagement-modul DC 1
--------------------------
DC 2
Puffer
SIMDRIVE 3D
DC 1DC 2
Interface PufferInterface Puffer
SIMDRIVE 3D
-------------
--------------------------
-------------
--------------------------
Remote ApplicationServer
Remote ApplicationServer
Admin-Tool
Admin-Tool
• Modellierung Gesamtmodel
• Verknüpfungsinformationen
• Steuerung
• Messages
• Errorhandling
Controller
Remote ApplicationServer
Remote ApplicationServer
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).
5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 125
Simulations-Programm
P3
Simulations-Programm
P2
Simulations-Programm
P1
Simulations-Programm
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 Entwicklung und Integration produktklassenabhängiger Berechnungstools 126
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
5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 127
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).
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 128
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
5.5 Kopplung von Berechnungsprozessen mit zeitabhängigen Modellparametern 129
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 -
5 Entwicklung und Integration produktklassenabhängiger Berechnungstools 130
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.