Sie sind auf Seite 1von 62

Inhaltsverzeichnis:

1. Einführung

3

1.1 Motivation der Arbeit

3

1.2 Problemstellung

6

1.3 Ziele der Arbeit

7

1.4 Gliederung

der Arbeit

8

2. Grundlegende

Technologien

9

2.1 Relationale Datenbanken und SQL

9

2.2 Pentaho Data Integrator [PDI]

10

2.3 Ontologie

12

2.3.1 Bestandteile einer Ontologie

14

2.3.2 Ontologiesprachen

16

2.3.3 Web Ontology Language

18

3. Integration des UNV-Dateiformats

24

3.1 Datenstruktur

24

3.1.1 Datenbank

Aufbau der

24

3.1.2 Daten (Stammdaten)

Festgelegte

27

3.1.3 Datensatztabellen

Aufbau der

29

3.1.4 Materialdarstellung in der Datenbank

30

3.2 UNV-Format

31

3.2.1 Übersicht

31

3.2.2 Syntax und Semantik

32

3.2.3 Datasetssyntax

33

3.3 UNV-Integrator

36

3.3.1 Das Einlesen von Knoten

39

3.3.2 Das

Einlesen

von

Zellen

40

3.3.3 Einlesen von Materialnamen

41

3.3.4 Einlesen von Materialeigenschaften

43

- 2 -

4. Datenvorbereitung

46

4.1 Data Enrichment

46

4.2 Wissensbasis

46

4.2.1 Annotations

49

4.2.2 Merkmale

50

4.3 Systemanpassung

51

4.3.1 Datenbankerweiterung

51

4.3.2 Wissensbasiserweiterung

52

4.3.3 Transformation zur Interfacebestimmung

53

5. Zusammenfassung

56

6. Abbildungsverzeichnis

57

7. Tabellenverzeichnis

59

8. Literatur

60

- 3 -

1.

Einführung

1.1

Motivation der Arbeit

In der modernen Welt werden von neuen Produkten und den darin verarbeiteten Materialien immer höhere Anforderungen abverlangt. Gleichzeitig steigt die Komplexität von solchen Produkten und damit der zugrundeliegenden Produktionsprozessen. Um den Herausforderungen der modernen Welt gerecht zu werden, kommen im Produkt- und Prozessdesign integrative Simulationstechniken zum Einsatz. Als Resultat steigt der Planungsaufwand bei solchen modernen, hochwertigen Produkt an [Schmitz 2011]. Eine Strategie, um diesen zu reduzieren, ist die Entwicklung einer Simulationsplattform, die den Einsatz verschiedener Simulationswerkzeuge ermöglicht. Eine solche Plattform ist die „Integrierte Plattform für verteilte numerische Simulationen“ (ICD B-1.2), die im Rahmen des Excellenzclusters „Integrative Produktionstechnik für Hochlohnländer“ entwickelt wird. Diese Plattform stellt Methoden und Konzepte zur Kopplung von heterogenen numerischen Simulationswerkzeugen bereit, wodurch eine vollständige Simulation von Fertigungsprozessen realisiert werden kann. Die Plattform ist in der Lage, zur Laufzeit definierte Simulationsprozesse zu erfassen, auszuführen und zu simulieren. Das bedeutet, dass die tatsächliche Reihenfolge der Kopplung zunächst unbekannt ist, und erst zur Laufzeit vom Benutzer festgelegt wird. Aufgrund der Heterogenität verschiedener Simulationsprogramme sowohl in ihrer technischen Anbindung, wie auch in ihrer Datenrepräsentation werden die Daten zuerst auf der Plattform integriert. Diese Aufgabe wird durch den Datenintegrator übernommen. Die Datenintegration umfasst neben der Integration und Extraktion der Daten auch eine Analyse, um fehlende oder unzureichende Daten automatisch anzureichern. Unter Anreicherung wird in diesem Kontext die Extraktion impliziter Informationen aus bereits existierenden Daten verstanden. Die Architektur der Plattform ist in Abbildung 1–1 dargestellt. Der Datenintergator sowie Datenextraktor sind Dienste, die von einem Service Provider bereitgestellt werden. Die Anfragen von Applikationen Dienste benutzen zu können, werden durch Service Registry angenommen und verwaltet. Der Process Manager ist für die Ausführung der Integrationsprozesse zuständig [Reinhard 2011].

- 4 -

- 4 - Abbildung 1–1: Facharchitektur der Simulationsplattform [Reinhard 2011] Aufgrund der Dynamik in Form von

Abbildung 1–1: Facharchitektur der Simulationsplattform [Reinhard 2011]

Aufgrund der Dynamik in Form von unbekannten Kopplungspartnern sowie komplexen Datenformaten und -strukturen wird eine Integrationslösung benötigt, die sich adaptiv verhält. Damit ist gemeint, dass die Integrationslösung zur Laufzeit bestimmen muss, welche Datentransformationen zur Anreicherung der Daten benötigt werden. Dabei kommen Algorithmen und Methoden aus der künstlichen Intelligenz und des Semantic Web zum Einsatz. Die technische Kopplung der Simulationen erfolgt mittels einer Grid Middleware.

Als Simulationswerkzeuge werden unterschiedliche Simulationsprogramme verwendet. Drei dieser Simulationsprogramme sind die bei der ACCESS e.V. entwickelten Applikationen CASTS, MICRESS und HOMAT. CASTS ist eine Software für die Simulation von Gießprozessen und der Wärmebehandlung. Die Software CASTS verwendet die Finite Elemente Methode (FEM) zur Simulationsberechnung. Die Besonderheit von CASTS liegt in der

- 5 -

Betrachtung der teilerstarrten Bauteilen, da Gas, Schmelze und Erstarrtes gleichzeitig als getrennte Phasen behandelt werden [----]. MICRESS hingegen ist eine Mikrostruktursimulation mit der man Untersuchungen im Mikrometerskalenbereich durchführt. Mit Untersuchungen im Mikrometerskalenbereich wird versucht die Informationen über die Struktur und Kinetik zu gewinnen. Solche Informationen sind beispielsweise Kristallmorphologie, Korngrößen, Wärme- und Stofftransporte oder elastischer Spannungszustand und Mikrospannungen [----]. Da die Ergebnisse aus der Mikrostruktursimulation wegen den Skalenunterschieden nicht direkt verwendet werden können, müssen sie konvertiert und transformiert werden. Die Software HOMAT übernimmt diese Konvertierung und Transformation der Ergebnisse aus der Mikrostruktursimulation. Dabei wird ein heterogener Werkstoff durch einen äquivalenten homogenen Werkstoff ersetzt [----].

Der Einsatz der Simulationen wird in Abbildung 1–2 gezeigt. Am Beispiel der Herstellung eines Getriebezahnrades wird die Verkettung von verschiedenen Simulationen dargestellt. Während eines Herstellungsprozess wird der Rohling mehrfach wärmebehandelt und umgeformt, bis aus ihm ein Zahnrad wird. Dabei finden die Simulationsprozesse auf zwei Ebenen statt. Die Makroebene, in der Umform-, Wärmebehandlungs- und Schweißsimulationen verwendet werden, und die Mikroebene, in der das Gefüge untersucht wird. Zwischen Makro- und Mikroebene liegt eine Transferebene, in der die Daten aus der Mikroebene für die Verwendung in der Makroebene homogenisiert werden. Die Softwarewerkzeuge, die zum Einsatz kommen, sind eigenständig und besitzen keine gemeinsame Schnittstellen Datenformaten, Datenstrukturen und Datenrepräsentation [Schilberg 2009].

RohlingRohling

Rohling

Rohling

Rohling

Rohling

wärmbebehandelt

wärmbebehandelt

wärmbebehandelt

ZahnradZahnrad

Zahnrad

Zahnrad

Zahnrad

Zahnrad

wärmebehandelt

wärmebehandelt

wärmebehandelt

Wärmebe- Wärmebe- Umformungen Umformungen Wärmebe- Wärmebe- handlungen handlungen handlungen handlungen
Wärmebe- Wärmebe-
Umformungen
Umformungen
Wärmebe- Wärmebe-
handlungen
handlungen
handlungen
handlungen

GetriebezahnradGetriebezahnrad

Getriebezahnrad

Schweißen Schweißen
Schweißen
Schweißen
Getriebezahnrad Schweißen Schweißen Abbildung 1–2: Simulationskette zum Herstellung eines

Abbildung 1–2: Simulationskette zum Herstellung eines Getriebezahnrads [Schilberg 2009]

- 6 -

Bei Homogenisierungssimulationen werden unter anderem die Diskontinuitäten berechnet. Eine Diskontinuität entsteht an den Grenzbereichen an denen zwei verschiedene Materialgruppen mit verschiedenen Eigenschaften aneinander stoßen. Diese Informationen sind notwendig, da an diesen Grenzbereichen die Materialen verschiedene Eigenschaften aufweisen. Um Diskontinuitäten berechnen zu können wird die Diskretisierung von Materialgruppen vorgenommen. Das bedeutet dass, eine Materialgruppe von den anderen Materialgruppen getrennt wird. Eine Materialgruppe wird dabei als eine Menge von Volumenelementen angesehen, die dem gleichen Material angehören. Bei HOMAT kommt der Finite-Elemente (FE) Ansatz zum Einsatz, um Bauteile als endliche Menge von Elementen bzw. Volumenelementen (z.B. Hexaeder, Pentaeder, Tetraeder), die geometrisch beschrieben werden können, darzustellen. An dem Beispiel der Berechnung von Diskontinuitäten werden Daten für HOMAT um Interfaceinformationen angereichert. Die Anreicherung wird durchgeführt, indem die bestehende Daten analysiert und implizite Informationen (hier Interfaces) expliziert werden. Als Interfaces werden diejenigen Flächen bezeichnet, die zwischen zwei Volumenelementen verschiedener Materialgruppen liegen.

Interfaceflächen werden identifiziert, indem alle Flächen sortiert und danach paarweise verglichen werden. Diejenigen Flächen, die doppelt vorkommen, sind dabei Interfaces. Wichtig sind in diesem Zusammenhang auch freie, also äußere Flächen, an welche keine weiteren Flächen des Bauteils angrenzen.

Die Trennung von Materialgruppen passiert durch Verdoppelung von Knoten, die die entsprechende Interfacefläche darstellen. Das bedeutet, dass aus einer Interfacefläche zwei einfache Flächen entstehen, die den verschiedenen Materialgruppen gehören.

1.2

Problemstellung

Die Anbindung der Simulationssoftware CASTS erfordert die Erweiterung der im Rahmen des Exzellenzclusters entwickelten Simulationsplattform, um das von CASTS verwendete UNV- Formats zu unterstützen. Des Weiteren müssen Datentransformationen bereitgestellt werden, um die benötigten Informationen (äußere Flächen und Interfaceflächen) in existierenden Datensätzen anreichern zu können.

- 7 -

Um diese Anreicherung in das bestehende System integrieren zu können, muss die in der Simulationsplattform eingesetzte Datenanalyse-Komponente angepasst werden. Diese Komponente setzt die beschriebene adaptive Anreicherung der vorliegenden Daten um. Der Analyse-Algorithmus sieht dabei vor, zunächst Merkmale zu identifizieren, die durch die gegebenen Daten erfüllt werden. Ein Merkmal ist z.B. die Dimensionalität von Bauteildaten (2D oder 3D). Anschließend wird anhand der gegebenen sowie der definierten, zu erfüllenden Merkmale (bestimmt durch das Datenformat) eine Transformationskette bestimmt, die auf den existierenden Datentransformationen basiert.

Für die freien Flächen und Interfaceflächen müssen entsprechende Merkmale bestimmt werden, die diese Eigenschaften beschreiben. Die Datenanalyse-Komponente muss zur Anbindung von CASTS um eben diese Merkmale erweitert werden. Aufgrund der Komplexität der Merkmalsdefinitionen ist die bisherige Implementierung der Datenanalyse-Komponente nicht in der Lage, diese Merkmale abzubilden und zu analysieren. Daher besteht der Hauptteil der Arbeit in der Definition von diesen Merkmalen und in der Erweiterung der Datenanalyse-Komponente. Dadurch soll die Möglichkeit eröffnet werden, herauszufinden, ob Interfaceflächen sowie freie Flächen in einem Datensatz bereits identifiziert wurden, oder nicht. Merkmale werden in der Wissensbasis definiert. Die Wissensbasis ist ein Teil der Datenanalyse-Komponente, der zur Beschreibung von Informationen und Beziehungen über Datenbestand in der Simulationspattform verwendet wird. Die Wissensbasis muss untersucht und um Konzepte und Individuen ergänzt werden, so dass eine Abbildung der Merkmale möglich wird.

1.3 Ziele der Arbeit

Für die Arbeit ergeben sich somit die nachfolgenden Ziele:

1. Integration des UNV-Formats in die Simulationsplattform (Integrator und Extraktor).

2. Identifikation der Merkmale, so dass freie Flächen und Interfaceflächen in einem gegebenen Datensatz analysiert werden können.

- 8 -

4.

Implementierung

der

benötigten

Datentransformationen,

die

freie

Flächen

und

Interfaceflächen berechnen.

 

1.4

Gliederung der Arbeit

 

Als erstes wird im Kapitel 2 der Überblick über Technologien vorgestellt, die in der Simulationsplattform zu Einsatz kommen und für diese Arbeit relevant sind. Dabei wird die Datenverwaltung beschrieben, darunter Speicherung der Daten mit der relationalen Datenbank, Anfragen an die Datenbank mit der Anfragesprache SQL. Als Nächstes wir der Pentaho Data Integrator beschrieben, mit deren Hilfe der UNV-Integrator und der UNV-Extraktor implementiert wurden. Auch wird in diesem Kapitel die Ontologie repräsentiert, mit deren Hilfe die Wissensbasis formuliert wurde. Es werden Bestandteile einer Ontologie sowie Ontologiesprachen, darunter OWL, erläutert.

Im Kapitel 3 wird zuerst vorgestellt, wie die Datenstruktur von der Simulationsplattform aufgebaut ist. Als Nächstes wird gezeigt, wie das UNV-Format organisiert ist. Schließlich werden der UNV-Integrator und UNV-Extraktor beschrieben und in das System integriert.

Im Kapitel 4 wird die Erweiterung des Datenerkennungs- und Datenanreicherungsmechanismus vorgenommen. Dazu wird zuerst der Aufbau der Wissensbasis vorgestellt. Hauptteile der Wissensbasis wie Annotationen und Merkmale werden näher betrachtet. Als Nächstes wird gezeigt, wie das System erweitert wurde. Dabei werden Änderungen an der Datenbank und Wissensbasis erläutert. Zum Schluss wird der Algorithmus zur Interfaceberechnung vorgestellt.

Kapitel 5 schließt die Arbeit mit einer Zusammenfassung ab.

- 9 -

2. Grundlegende Technologien

In diesem Kapitel werden Technologien dargestellt, die in der Simulationspattform verwendet

werden. Es fängt mit dem Kapitel 2.1, wo die relationale Datenbank betrachtet wird. Im Kapitel

2.2 wird der Pentaho Data Integrator vorgestellt und seine Vorteile erläutert. Kapitel 2.3

berichtet über die Entwicklung von Ontologien. Hier werden Bestandteile einer Ontologie

dargestellt. Weiter werden im Kapitel 2.3.2 Ontologiesprachen präsentiert. Schließlich wird im

Kapitel 2.3.3 die Ontologiesprache OWL vorgestellt und mit einem Beispiel erläutert.

2.1 Relationale Datenbanken und SQL

Die in der Simulationsplattform integrierten Daten werden innerhalb einer relationalen

Datenbank persistiert. Eine Relation ähnelt dabei einer Tabelle mit Datensätzen, die in einer

bestimmten Beziehung zueinander stehen. Dabei repräsentiert jede Zeile der Tabelle eine Liste

zusammenhängender Datenwerte und wird in der formalen Terminologie des relationales

Modells als Tupel bezeichnet. Die Spaltenüberschrift eines Tupels wird Attribut genannt

[Elmasri 2002]. Ein Tupel stellt somit einen Datensatz dar, dessen Attribute die Eigenschaften

eines Objekts in der realen Welt beschreiben. Zwei oder mehrere Tabellen können in einer

Beziehung zueinander stehen. Ein Verbindungsglied zwischen diesen Tabellen ist ein Schlüssel.

[Schneider 2004] beschreibt einen Schlüssel als:

“[…] eine minimale Menge von Attributen einer Datei, so dass ein Datensatz hierdurch eindeutig identifiziert wird.”

In einer Relation können mehrere Schlüssel existieren, wobei einer von diesen Schlüsseln in der

Regel den Primärschlüssel (primary key) der Relation darstellt. Der Primärschlüssel identifiziert

den Datensatz während seiner gesamten Lebenszeit eindeutig im System und sollte in seinem

Wert unveränderlich sein. Eine Attributkombination, die ebenfalls zur eindeutigen Identifikation

des Datensatzes herangezogen werden kann, jedoch ungleich dem Primärschlüssel ist, wird

Sekundärschlüssel (secondary key) genannt [Schneider 2004]. Die Abbildung 2–1 zeigt ein

Beispiel für eine relationale Datenbank. Die Tabelle „Knoten“ enthält als Attribute eine

Identifikationsnummer (Knoten_ID) und Koordinaten (Pos. X, Pos. Y, Pos. Z) für ein

dreidimensionales Koordinatensystem. Diese Attribute stehen in einer Relation zu einander.

Genauso identifizieren die Attribute „Zellen_ID“, „Knoten“ und „Type_ID“ eine Zelle. Die

- 10 -

Relation zwischen den beiden Tabellen „Zellen“ und „Knoten“ ist definiert durch das Attribut „Knoten“ in dem die Knoten_ID’s aus der Tabelle „Knoten“ enthalten sind und die Zelle beschreiben. Eine Zelle kann weitere Eigenschaften besitzen. Die Tabelle „Zellen_Eigenschaft“ stellt eine Zelleneigenschaft dar. Diese Tabelle enthält das Attribute „Zellen_ID“, das die gegebene Eigenschaft einer bestimmten Zelle zuordnet.

die gegebene Eigenschaft einer bestimmten Zelle zuordnet. Abbildung 2–1: Mögliche Darstellung von Knoten und Zellen

Abbildung 2–1: Mögliche Darstellung von Knoten und Zellen in einer relationalen Datenbank

Für die Arbeit mit relationalen Datenbanken hat sich die SQL (Standard Query Language) etabliert. [Riemer 2007] nennt SQL

“[…] eine enorm wichtige Sprache, ohne die kein Datenbankentwickler auskommt.”

Einige Sprachbestandteile von SQL, die auch bei der vorliegenden Arbeit Anwendung finden, sind die Datendefinitionssprache (DDL), die Datenmanipulationssprache (DML) und die Datenabfragesprache (DQL). Die DQL hat hierbei einen besonderen Stellenwert, da mittels der dort enthaltenen SELECT-Anweisung, Datensätze aus der Datenbank ausgelesen werden können. DQL unterstützt die Erweiterung von Anfragen um mathematische Bedienungen.

2.2 Pentaho Data Integrator [PDI]

Die Integration vom UNV-Format in die Integrationsplattform wird mit Hilfe des Pentaho Data Integrators (PDI) durchgeführt. Der Pentaho Data Integrator, auch als Kettle bekannt, ist ein in Java geschriebenes ETL-Tool. ETL steht für Extracting (Extraktion), Transforming

- 11 -

(Transformation) und Loading (Laden) und beschreibt einen Prozess zur Datenintegration [Vassiliadis 2003]. Dieser wird in der Regel eingesetzt um große Datenmengen aus unterschiedlichen Datenquellen in eine Datenquelle, dem sogenannten Data Warehouse zu übertragen. Hierbei umfasst die Extraktion alle Vorgänge, die notwendig sind, um die in den Datenquellen gehaltenen Daten zu extrahieren [Leser 2007]. Dieser Vorgang wird beispielsweise durch das gesteuerte Ausführen von SQL-Skripten in einer relationalen Datenbank als Datenquelle realisiert (vgl.Kapitel 2.1).

Die Transformation hingegen bezeichnet die Schritte zur Transformation der extrahierten Daten in das Format die Struktur und die Semantik der Zielanwendung. Dies beinhaltet zum Beispiel die Umformung von Datumsangaben. Ein Beispiel hierfür wäre die Transformation aus der Form „10 Juni 2011“ in die alternative Darstellung „10.06.2011“.

Das Laden bezeichnet das tatsächliche Überführen der Daten in die endgültige Datenrepräsentation, also beispielsweise in ein Data Warehouse. Bei einer Anwendung entspricht das Laden somit dem Schreiben der Daten im anwendungsspezifischen Datenformat.

Der PDI ist aber nicht nur ein ETL-Werkzeug, sondern wird auch für andere Zwecke, wie die Realisierung vom Datentransfer zwischen verschiedenen Anwendungen oder Datenbanken verwendet [Roldan 2010].

Abbildung 2–2 zeigt das Arbeitsfenster vom PDI. Links befindet sich eine strukturierte Leiste mit verschiedenen Optionen. Die verwendeten Optionen werden auf die Arbeitsfläche (größte Fläche in der Abbildung) gezogen und miteinander verkettet, abhängend davon, was der Benutzer erreichen will.

- 12 -

- 12 - Abbildung 2–2: Interface vom PDI Die ETL-Fähigkeiten sind dabei vielfältig. Eine für diese

Abbildung 2–2: Interface vom PDI

Die ETL-Fähigkeiten sind dabei vielfältig. Eine für diese Arbeit wichtige Fähigkeit vom PDI ist die Möglichkeit eine Textdatei zeilenweise parallel abzuarbeiten. Das bedeutet, dass alle Zeilen gleichzeitig bearbeitet werden können. Der PDI enthält Werkzeuge, die verschiedene Manipulationen von Datenbankinhalten erlauben und unterstützt standardmäßig weit verbreitete Formate wie z.B. Excel und XML. Darüber hinaus wird die Programmiersprache Java und die Skriptsprache JavaScript unterstützt, die eine Individualisierung einzelner Arbeitsschritte ermöglichen.

Eine Kette von bestimmten Aufgaben wird in einer sogenannten PDI-Transformation realisiert (nicht zu verwechseln mit der ETL-Transformation). Eine Folge von solchen Transformationen, die zu einem Prozess gehören, wird als Job bezeichneten. Ein PDI-Job kann verschiedene Parameter und Argumente enthalten, die für alle Transformationen, die zu diesem Job gehören, sichtbar sind. Die Parameter können beispielsweise zum Speicherung von Zugriffsinformationen für eine Datenbank verwendet werden. Als Argument wird der Pfad und der Name der einzulesenden Datei verwendet (vgl. Kapitel 3.3).

2.3

Ontologie

Der Begriff Ontologie stammt ursprünglich aus der Philosophie [Hepp/Moor 2008] und bildet sich aus den griechischen Wörtern „onta“ (das Seiende) und „logos“ (Lehre), was „die Lehre

- 13 -

vom Seienden“ bedeutet [Geisler 2009]. Seit zwanzig Jahren gewinnt die Ontologie in der

Informatik an Bedeutung. Dies liegt an der Fähigkeit der Ontologie die Interoperabilität

zwischen mehreren Repräsentationen der Realität herzustellen. Ein Beispiel ist die Realisierung

der Interoperabilität zwischen Datenprozessmodellen innerhalb von Computersystemen

[Hepp/Moor 2008]. Ein weiterer entscheidender Vorteil von Ontologie ist die Fähigkeit

Schlussfolgerungen aus dem formalisierten Wissen ziehen zu können. Als formalisiertes Wissen

wird der mit Hilfe der Ontologie dargestellte Zustand der Teilrealität bezeichnet

[Stuckenschmidt 2009].

[Geisler 2009] schreibt:

“In der Informatik versteht man unter Ontologie (nach Gruber) eine explizite, formale Spezifikation einer gemeinsamen Konzeptualisierung (Begriffsbildung).”

Entsprechend dieser Definition interpretiert [Studer 1999] die Ontologie auf folgende Weise:

“Eine Ontologie stellt eine Sammlung von Konzepten, Beziehungen und Regeln zur Verfügung, die auf dem Konsens einer Gruppe von Personen, z.B. eines Unternehmensbereiches, beruhen. Solch eine Ontologie stellt eine von dieser Personengruppe gemeinsam getragene Sicht auf einen Anwendungsbereich zur Verfügung.”

Also beschreibt eine Ontologie einen Teil der Realität. Diese Beschreibung lässt sich mit

logischen Formeln ausdrücken. Dabei konzentriert sich die Ontologie auf den inhaltlichen

Aspekten dieser Beschreibung und die Logik stellt eine Sprache zur Formalisierung dieser

Beschreibung bereit [Stuckenschmidt 2009].

Die Anforderungen, die eine Ontologie erfüllen muss, sind nach [Geisler 2009] folgende:

Eine Ontologie soll formal aufgebaut sein, um von Maschinen gelesen werden zu können.

Das durch die Ontologie ausgedrückte Wissen soll explizit angegeben sein.

Eine Ontologie soll mit Konzepten die Welt beschreiben.

Es soll zumindest in einem kleinen Kreis, Konsens über diese Konzepte herrschen.

Wie oben schon erwähnt, enthält das Data Enrichment eine Wissensbasis. Diese Wissensbasis

wird mit Hilfe von Ontologien repräsentiert. Die Wissensbasis strukturiert und kategorisiert die

Informationen aus der Datenbank. Das Data Enrichment entscheidet anhand der

- 14 -

Schlussfolgerungen aus der Ontologie, ob die Kopplung von Simulationen erfolgreich ist, oder ob Transformationen ausgeführt werden müssen, um fehlende Daten zu erzeugen.

2.3.1 Bestandteile einer Ontologie

Eine Ontologie besteht nach [Wichmann 2007] aus drei Teilen:

Konzepte (Klassen), Begriffen,

Relationen zwischen den Begriffen,

Regeln über die Relationen und Begriffe.

Diese Begriffe werden im Folgenden kurz erläutert.

Klassen

Als erstes werden bei der Erstellung einer Ontologie Konzepte (auch als Klassen bezeichnet) und deren Hierarchie festgelegt. Es wird entschieden welche Objekte in der Wissensbasis abgebildet werden sollen und welche Terme dafür benutzt werden. Wichtig ist dabei auch die Subsumptionsbeziehung zwischen Klassen von Objekten [Stuckenschmidt 2009]. Als Subsumption werden die Teilmengenbeziehungen bezeichnet. Es sollen nur für den Kontext sinnvolle Objekte abgebildet werden, um Komplexität gering zu halten. Beim Festlegen von Kategorien werden Objekte nach Gemeinsamkeiten unterteilt. Die Objekte mit den relevanten gemeinsamen Eigenschaften bilden eine Kategorie. Ein konkretes Objekt, das mit einem Konzept beschrieben ist, wird als Individuum bezeichnet. Abbildung 2–3 veranschaulicht mögliche Klassen und deren Beziehungen in einer Bier-Ontologie. Dabei ist die Klasse Beer eine Oberklasse von der BottomFermentedBeer und die Klassen Lager, Pilsner und Bock sind Unterklassen von ihr. Außerdem besitzt Pilsner ein Individuum namens Jever.

- 15 -

- 15 - Abbildung 2–3: Beispiel für Ontologieklassen und Individuen Relationen Nachdem die Klassenhierarchie festgelegt

Abbildung 2–3: Beispiel für Ontologieklassen und Individuen

Relationen

Nachdem die Klassenhierarchie festgelegt ist, werden die Relationen (auch Beziehungen genannt) zwischen den Klassen identifiziert. Die Relationen verknüpfen verschiedene Objektklassen miteinander. Die Art der Relation wird entsprechend dem Kontext bestimmt. Beziehungen werden so gewählt, dass sie eine hierarchische Einstufung (Teilmengebeziehung) ausdrücken.

Ein Beispiel für eine Hierarchie wäre „Rotwein“ isA „Wein“ und „Rotwein“ hatFarbe „rot“

Eine andere Art von Beziehungen zeigt Zugehörigkeit einer Eigenschaft einer Klasse

Es können parallel auch inverse Beziehungen definiert werden. [Voss 2003] hält folgende Relationsarten sinnvoll:

- Hierarchische Relationen

- generische Relation

- Instanzrelation (Klasse/Instanz)

- Vererbungsrelation (Ober/Unterklasse)

- partitive Relation (Ganzes/Teile)

- Eigenschaftsrelation

- Ordnungsrelation

- 16 -

- Koordinative Beziehungen

- Synonymien, Antynomie

- Assoziationsbeziehungen

Regeln

Logische Aussagen über Konzepte und Relationen werden als Regeln bezeichnet. Unter Regeln befinden sich beispielsweise die Axiome, die in einer Domäne ohne Beweis immer gültig sind. [Stuckenschmidt 2009] beschreibt einen Einsatz sogenannter „Closure-Axiome“, die den Wertebereich einer bestimmten Eigenschaft einschränkt.

2.3.2

Ontologiesprachen

Ontologien werden mit Ontologiesprachen modelliert. Ontologiesprachen ermöglichen Teile der Realität entsprechend einem bestimmten Kontext zu formalisieren und logisch zu beschreiben. Die Abbildung 2–4 zeigt Einordnung und Zusammenhang der einzelnen Sprachfamilien auf, die zur Entstehung der Web Ontology Language (OWL) beigetragen haben. Im Fokus dieser Abbildung steht die Ontologiesprache OWL. Diese Sprache wird bei der Entwicklung von Ontologie für die Simulationsplattform benutzt. Mehr zu der OWL in dem Kapitel 2.3.3. Weiter in diesem Kapitel werden Ontologiesprachen aus Abbildung 2–4 näher betrachtet.

- 17 -

- 17 - Abbildung 2–4: Schichtung der Ontologiesprachen [Kuhnt 2003] Auf die ganz unten in der

Abbildung 2–4: Schichtung der Ontologiesprachen [Kuhnt 2003]

Auf die ganz unten in der Abbildung liegenden Sprachen wird im Rahmen der Arbeit nicht näher aufgegangen. Als Nächste Sprache wird die Ontologiesprache RDF vorgestellt.

RDF

Ein einfaches Datenmodell zur Repräsentation von Wissen im Internet, das der Ontologiesprachen vorangegangen ist, ist das Resource Description Framework (RDF). Die zentrale Idee von RDF besteht darin binäre Relationen zwischen eindeutig bezeichneten Ressourcen zu beschreiben. Ressourcen können hierbei Objekte, Klassen, Relationen oder konkrete Werte bezeichnen. Binäre Relationen werden im RDF in Form eines Tripels (Subjekt, Prädikat, Objekt) dargestellt Stuckenschmidt 2009.

RDFS

RDFS (Resource Description Framework Schema) ist eine Weiterentwicklung der Repräsentationssprache RDF, d.h. RDFS basiert auf dem Modellierungsprimitiven des RDF- Ansatzes [Kuhnt 2003]. Mittels der Aussagen, die mit RDF formuliert wurden, können mit RDFS Klassen und Properties definiert und Vererbungshierarchien für Klassen und Eigenschaften erzeugt werden. RDFS hat Möglichkeit den Ursprungsbereich (domain) und Bildbereich (range) einer Objekteigenschaft zu beschränken. Das bedeutet, dass die Individuen, die diese Objekteigenschaft verknüpft, müssen der Klasse angehören, die als domain bzw. range vordefiniert ist.

OIL

- 18 -

OIL bedeutet “Ontology Inference Layer” oder “Ontology Interchange Language”. Diese

Sprache ist eine Erweiterung von RDFS und wurde in Europa entwickelt. Die Entwicklung von

OIL wurde von framebasierten Systemen, wie der deskriptiven Logik und den W3C Standards

XML und RDF beeinflusst [Wichmann 2007].

DAML

DAML steht für „DARPA Agent Markup Language“ und ist ebenfalls eine Erweiterung von

RDFS. DAML ist eine ausdruckstärkere Ontologiesprache und wurde entwickelt um den

Anforderungen des Semantik Web nachzukommen. DAML ist die amerikanische Variante von

OIL [Wichmann 2007].

DAML & OIL

DAML & OIL ist eine Ontologiesprache, die aus dem Zusammenfügen von DAML und OIL

hervorgegangen ist. Das Zusammenfügen wurde aufgrund der ähnlichen Zielsetzung veranlasst.

DAML&OIL ist weitaus ausdruckstärkere als die einzelnen Teilsprachen [Wichmann 2007].

2.3.3 Web Ontology Language

Die Web Ontology Language (OWL) ist eine Ontologiesprache, die auf der Prädikatenlogik

basiert. Die OWL baut auf RDF und RDFS auf. Sie wurde im Februar 2004 vom W3C

standardisiert und empfohlen [Hitzler 2008]. [Geisler 2009] schreibt über OWL folgendes:

“Wie auch mit RDFS, so können mit OWL-Konzepte einer beliebigen Domäne sowie deren Beziehungen zueinander formal so beschrieben werden, dass deren Bedeutung auch für Maschinen (Software) verarbeitbar („verstehbar“) ist. Dabei geht OWL weit über die Ausdruckmöglichkeiten von RDFS hinaus, sodass insbesondere auch komplexeste Zusammenhänge, z. B. in natürlichsprachigen Sätzen, hinreichend genau modelliert werden können”

OWL ist in drei Teilsprachen unterteilt. Die Teilsprachen unterscheiden sich in der

Ausdrucksstärke, je nach Anforderungen von Anwender [Hitzler 2008]. Die Teilsprachen sind

die Folgenden: OWL Full, OWL DL, OWL Lite. Dabei ist die OWL Lite eine echte Teilsprache

von OWL DL und OWL DL ist ihrerseits eine echte Teilsprache von OWL Full vgl. Abbildung

2–5. Auf die einzelnen Teilsprachen wird im Folgenden im Detail eingegangen.

- 19 -

- 19 - Abbildung 2–5: OWL Teilsprachen [Wichmann 2007] OWL Lite OWL Lite ist die OWL-Teilsprache

Abbildung 2–5: OWL Teilsprachen [Wichmann 2007]

OWL Lite

OWL Lite ist die OWL-Teilsprache mit der geringsten Ausdrucksmächtigkeit. Sie unterstützt die Klassifikationshierarchien mit Relationen wie bei RDFS und erlaubt einfache Restriktionen wie beispielsweise für den lokalen Range-Bereich. Zu den einfachen Restriktionen zählt auch die Einschränkung der Zahlenkardinalität, die nur die Werte 0 und 1 erlaubt. OWL Lite unterstützt ebenfalls verschiedene Eigenschaften wie zum Beispiel Transitivität, Symmetrie und Umkehrung [Fensel 2007]. OWL Lite ist entscheidbar und hat ExpTime Komplexität [Hitzler

2008].

OWL DL

DL steht für Description Logic und drückt die Ähnlichkeit von OWL DL zur Beschreibungslogik

SHOIN aus. Diese OWL-Teilsprache stellt die maximale Ausdrucksmächtigkeit zur Verfügung

und wird von aktuellen Softwarewerkzeugen fast vollständig unterstützt[Hitzler 2008]. OWL DL

erlaubt volle Unterstützung für Negation, Disjunktion, Kardinalitätsrestriktion und Aufzählung

[Fensel 2007]. Die OWL DL bleibt bei der maximalen Ausdrucksmächtigkeit entscheidbar und lässt vollständige und korrekte Inferenz mit der Komplexität NExpTime.

OWL Full

Die OWL Full enthält als einzige OWL-Teilsprache das komplettes RDF-Schema (RDFS). Die Ausdrucksmächtigkeit von OWL Full ermöglicht Aussagen, die die Entscheidungsfähigkeit einer Beschreibungslogik übersteigen, daher ist OWL Full unentscheidbar und verliert das volle Schlussfolgerungsvermögen.

- 20 -

2.3.3.1 Funktionsweise von OWL

In diesem Abschnitt wird ein Überblick über die grundlegenden Sprachelemente der OWL gegeben.

Konzepte

Konzepte (Klassen) werden in OWL durch owl:Class definiert. Die Klassendefinition wird in Abbildung 2–6 am Beispiel einer Bier-Ontologie gezeigt. In diesem Fall werden Konzepte Beer, BottomFermentedBeer und Pilsner eingeführt.

Beer , BottomFermentedBeer und Pilsner eingeführt. Abbildung 2–6: Definition von Konzepten in OWL Abbildung

Abbildung 2–6: Definition von Konzepten in OWL

Abbildung 2–7 zeigt, wie eine Teilmengenbeziehung in OWL definiert werden kann. Um die Teilmengenbeziehung auszudrücken, wird das Konstrukt rdfs:subClassOf benutzt. Dabei stehen zwei Varianten zur Verfügung. Bei der ersten Variante a wird BottomFermentedBeer als ein Unterkonzept von Beer definiert, indem das Schlüsselwort rdf:resource verwendet wird. Bei der zweiten Variante b wird dem Konzept BottomFermentedBeer das Konzept Pilsner als Unterkonzept zugeordnet. In diesem Fall wird das Schlüsselwort rdf:about benutzt. Mit den Schlüsselwörtern rdf:resource und rdf:about kann innerhalb einer Ontologie auf die Konzepte verwiesen werden.

- 21 -

- 21 - Abbildung 2–7: Definition von Unterkonzepten und Anmerkungen in OWL Außer Teilmengenbeziehungen wird in

Abbildung 2–7: Definition von Unterkonzepten und Anmerkungen in OWL

Außer Teilmengenbeziehungen wird in Abbildung 2–7 gezeigt, wie bei OWL Anmerkungen definiert werden können. Dies geschieht durch das Konstrukt rdfs:label. In diesem Beispiel wird das Schlüsselwort xml:lang verwendet, was auf die zusätzliche Sprachanmerkung (Language) hindeutet.

In OWL existieren zwei vordefinierten Konzepte, nämlich owl:Thing und owl:Nothing. Das Konzept owl:Nothing ist ein leeres Konzept, das die leere Menge bezeichnet und ein Unterkonzept aller Konzepte ist. owl:Thing ist hingegen das allgemeinste Konzept, das alles enthält. Jedes Individuum muss mindestens einem Konzept angehören, somit wird es mindestens dem Konzept ows:Thing zugeordnet. Das Konzept owl:Nothing wird beispielsweise bei der Überprüfung von Klassenkonsistenz benutzt. Die Konsistenzüberprüfung hilft Modellierungsfehler aufzuspüren. Dabei wird eine Klasse inkonsistent genannt, wenn sie äquivalent zu owl:Nothing ist.

Individuen

Individuen können als Instanzen von Konzepten definiert werden. Als Beispiel dafür wird in Abbildung 2–8 die Deklaration des Individuums Jever vorgestellt, das dem Konzept Pilsner angehört.

Individuums Jever vorgestellt, das dem Konzept Pilsner angehört. Abbildung 2–8: Definition von Individuen in OWL

Abbildung 2–8: Definition von Individuen in OWL

- 22 -

Die Abbildung 2–9 stellt die äquivalente Definition zu der aus Abbildung 2–8 des Individuums Jever, dabei wird die Zugehörigkeit dem Konzept Pilsner explizit mit rdf:type angegeben.

dem Konzept Pilsner explizit mit rdf:type angegeben. Abbildung 2–9: Explizite Definition von Individuen in OWL

Abbildung 2–9: Explizite Definition von Individuen in OWL

Relationen

Es gibt in OWL zwei Arten von Relationen: abstrakte und konkrete. Abstrakte Relationen verbinden Individuen mit Individuen. Konkrete Relationen verbinden hingegen Individuen mit Datenwerten [Hitzler 2008]. Die Relationen sind Unterkonzepte von rdf:Property. In Abbildung 2–10 wird illustriert, wie die abstrakte Relation madeFrom als owl:ObjectProperty definiert ist. Dabei wird der Definitionsbereich mittels rdfs:domain (auf Individuen vom Konzept Beer beschränkt) und der Wertebereich mittels rdfs:range (auf Individuen vom Konzept Ingredient beschränkt) angegeben.

Individuen vom Konzept Ingredient beschränkt) angegeben. Abbildung 2–10: Definition von abstrakten Relationen in

Abbildung 2–10: Definition von abstrakten Relationen in OWL mit owl:ObjectProperty

In Abbildung 2–11 wird hingegen die Definition von einer abstrakten Relation mit Hilfe von owl:DatatypeProperty dargestellt. Dabei wird die Beschränkung des Wertebereichs rdfs:range durch den Verweis auf eine Internetseite gesetzt.

durch den Verweis auf eine Internetseite gesetzt. Abbildung 2–11: Definition von abstrakten Relationen in

Abbildung 2–11: Definition von abstrakten Relationen in OWL mit owl:DatatypeProperty

- 23 -

Ein Beispiel für eine konkrete Relation wird in der Abbildung 2–12 präsentiert. Bei dieser Definition wird mit hasAlcoholicContent angegeben, welchen Alkoholgehalt das Pilsner Jever hat.

angegeben, welchen Alkoholgehalt das Pilsner Jever hat. Abbildung 2–12: Definition von konkreten Relationen in OWL

Abbildung 2–12: Definition von konkreten Relationen in OWL

In dem nächsten Kapitel wir die praktische Realisierung von UNV-Integrator und UNV- Extraktor vorgestellt.

- 24 -

3.

Integration des UNV-Dateiformats

3.1

Datenstruktur

In diesem Kapitel wird beschrieben, wie die Datenbank aufgebaut ist. Zuerst werden in Kapitel

3.1.1 allgemeine Eigenschaften und Konventionen der Datenbank beschrieben. In dem Kapitel

3.1.2 werden die Tabellen erläutert, die Stammdaten enthalten. Die Stammdaten ermöglichen das

formatunabhängige Speichern der Daten. In dem Kapitel 3.1.3 wird die Aufbau einer Tabelle am Beispiel der Zellentabelle dargestellt. Die Datenbankerweiterung für die Materialeigenschaften

wird im Kapitel 3.1.4 erläutert.

3.1.1 Aufbau der Datenbank

Damit die Simulationsplattform mit der Ausführung einer Aufgabe starten kann, müssen dafür benötigte Daten in die Datenbank überführt werden. Die Übernahme der Daten aus einer Datei in die Datenbank erfolgt, wie bereits dargestellt, durch einen Integrator. In dieser Arbeit handelt es sich beim Integrator um einen PDI-Job, der das für das Einlesen der Informationen aus der UNV-Datei, die Transformation und die Speicherung dieser Informationen in die Datenbank verantwortlich ist. Die in der Datenbank abgespeicherten Daten dürfen dabei keine formatspezifischen Informationen enthalten sondern müssen in dem Datenmodell der zentralen Datenbank, dem sogenannten kanonischen Datenmodell, abgebildet werden. Der Integrator muss in der Lage sein, die eingelesenen Daten in das kanonische Datenmodell zu überführen. Dabei werden zwei Arten von Daten unterschieden. Die erste Art sind Daten, die das Bauteil beschreiben. Die zweite Art hingegen umfasst die Stammdaten. Mit Hilfe von Stammdaten wird das formatunabhängige Speichern der Daten realisiert. Die Datenbankstruktur legt fest, wie das allgemeine Datenformat auszusehen hat. Innerhalb der Datenbank gelten die folgenden Konventionen.

Alle Tabellennamen in der Datenbank werden kleingeschrieben.

Tabellen mit Stammdaten tragen das Präfix „dat_“.

Alle Bezeichnungen innerhalb der Datenbank sind auf Englisch.

Da die Datenformate geändert werden können oder neue Formate in die Plattform integriert werden sollen, soll die Datenbankstruktur leicht erweiterbar sein.

- 25 -

Die Berechnungen von Simulationen, die in der Plattform Verwendung finden, benötigen

geometrischen Informationen über ein Bauteil. Diese Informationen werden bei der Berechnung

mit der Finite-Elemente-Methode (FEM) verwendet. Die FEM ist ein numerisches Verfahren zur

Lösung von Differenzialgleichungen. [Klein 2010] beschreibt FEM in Verbindung mit CAD als:

“[…] ein wichtiges Basisverfahren, welches im Zuge der virtuellen Produkt- und Prozessentwicklung immer stärker angewandt wird.”

Bei der FEM wird ein Bauteil in Elemente aufgeteilt, deren Anzahl endlich ist. Dieser Vorgang

wird Diskretisierung genannt. Dabei entsteht ein Netz von Elementen, die das Bauteil imitiert.

Die Vernetzung besteht aus geometrischen Elementen wie beispielsweise Tetraedern, Hexaedern

oder Pentaedern, die von den Knoten und Kanten gebildet werden. Die Elemente werden in

dieser Arbeit auch als Zellen bezeichnet. Darüber hinaus wird ein Gleichungssystem aufgestellt,

mittels dem die unbekannten Parameter bestimmt werden können. Die unbekannten Parameter

sind beispielsweise Verschiebungen an den Knoten. Mit Hilfe von diesen Parametern werden

dann die physikalischen Eigenschaften vom Bauteil berechnet und somit das Verhalten simuliert

[Müller/Groth].

Die wichtigsten geometrischen Daten, die in dieser Arbeit betrachtet werden, sind Knoten,

Zellen und deren Attribute. Aus diesem Grund werden in der Datenbankstruktur die

entsprechenden Schlüsselwörter benutzt, die diese Informationen charakterisieren. So wird der

Name für die Datenbanktabelle, die Knoten enthält, mit dem englischen Wort „node“ bezeichnet,

dementsprechend heißt die Tabelle für Zellen „cell“. Die Namen der Attributetabellen fangen mit

dem Wort an, das die Entität bezeichnet, zu dem das Attribut zugehörig ist. So wird der Name

für Tabellen in denen die Integer-Attribute einer Zelle gespeichert werden, mit

„cellattributeintvalue“, für Float-Attribute mit „cellattributefloatvalue“ oder Double-Attribute

mit „cellattributedoublevalue“ bezeichnet. Abbildung 3–1 fasst die Darstellung von

Knotenattributen in der Datenstruktur zusammen. Außer Wertetabellen existiert eine Tabelle

namens „simulationstep“. Diese enthält Informationen über den Simulationsschritt, der gerade

berechnet wird und auf den sich die Daten beziehen. Diese Informationen werden von der

Simulationsplattform automatisch bestimmt und sind für diese Arbeit nicht relevant.

- 26 -

- 26 - Abbildung 3–1: Tabellennamen am Beispiel der Knotentabellen Es bilden sich Tabellengruppen, die durch

Abbildung 3–1: Tabellennamen am Beispiel der Knotentabellen

Es bilden sich Tabellengruppen, die durch ihr Präfix unterschieden werden können. In der Abbildung 3–2 sind die Tabellen, die zurzeit in der Datenstruktur des Integrationssystems abgebildet sind, dargestellt. Es sind, wie oben erwähnt, Tabellengruppen für geometrische Objekte und deren Attribute Knoten (node) und Zellen (cell), aber auch Tabellengruppen für Geometrien (geometry) und Prozesse (process). In der Datenbank können Daten von unterschiedlichen Simulationsschritten gleichzeitig gespeichert werden, deswegen würden im Datenbankschema Tabellen eingeführt, die zur Identifikation des aktuellen Prozesses verwendet werden. Diese Tabelle heißt „process“. Ein Prozess kann verschiedene Geometrien z.B. Geometrien, die ein Bauteil entsprechend der zeitlichen Veränderung beschreiben, enthalten. Die entsprechende Tabelle trägt den Namen „geometry“.

Für eine eindeutige Identifikation einer Zelle oder eines Knotens werden Identifikatoren für den aktuellen Prozess und die aktuelle Geometrie als auch für die Zelle oder die Knoten verwendet. Das gleiche gilt auch für die Attribute. In dem Kapitel 3.1.3 wird die Identifikation von Objekten näher beschrieben.

- 27 -

- 27 - Abbildung 3–2: Datenbankrelationen 3.1.2 Stammdaten Bis jetzt wurden die Tabellen beschrieben, in denen

Abbildung 3–2: Datenbankrelationen

3.1.2

Stammdaten

Bis jetzt wurden die Tabellen beschrieben, in denen die zentralen Entitäten einer FEM- Berechnung abgebildet werden können. Wie weiter oben bereits erwähnt existieren in der Datenbank Tabellen, die Stammdaten enthalten. Diese Stammdaten sind formatspezifische Bezeichnungen für verschiedene Datensätze, die für die richtige Zuordnung verschiedener Daten verwendet werden. Diese Tabellen enthalten Mapping-Informationen über verschiedene Datensätze, und haben besondere Namen, die mit dem Präfix „dat_“ ausgezeichnet sind. Als Beispieltabelle für Stammdaten wird die Tabelle 3-1 vorgestellt.

- 28 -

Simulation_ID

Name

Filter

1

larstran

.*\.pep

2

abaqus_odb

.*\.odb

3

vtk

.*\.vtk

4

casts

.*\.vtk

9
9
universal
universal
.*\.unv
.*\.unv

Tabelle 3-1: Beispiel der „dat_simulation“

In der Tabelle 3-1 werden Datenformate, die In der Plattform integriert sind, aufgelistet. Diese Tabelle heißt „dat_simulation“. Dem in dieser Arbeit betrachteten UNV-Format ist der Identifikator „9“ und der Name „universal“ zugewiesen. Der Filter „.*\.unv“ entspricht der Endung einer UNV-Datei.

Unterschiedliche Datenformate benutzen verschiedene Strukturen und Bezeichnungen für ihre Daten. Dies verhindert eine direkte Übernahme der Daten aus einem Format in das andere. Die Daten müssen dementsprechend übersetzt werden. Das Beispiel für die plattformspezifische Darstellung von verschiedenen Zelltypen wird in der Tabelle 3-2 gezeigt. Der Identifikator „CellType_ID“ ist eine plattformspezifische Nummerierung von Zelltypen. Die Spalte „CellType“ bezeichnet die Art einer Zelle, beispielsweise bedeutet die Bezeichnung „3D8“, dass die Zelle dreidimensional ist und acht Knoten enthält. Die Spalte „Num_of_Nodes“ enthält die Anzahl von Knoten in der entsprechenden Zelle. Alle kommenden Zellelemente werden entsprechend diesem Schema gespeichert.

CellType_ID

CellType

Num_of_Nodes

1

2D2

2

4

3D4

4

6
6
3D8
3D8
8
8

Tabelle 3-2: Ausschnitt aus der Tabelle „dat_celltype“

Die Tabelle 3-3 mit dem Namen „dat_simcelltype“ zeigt im Vergleich zu der Tabelle 3-2, die Informationen über Zellen von verschiedenen Datenformaten. Die Zelldarstellungen aller in der Integrationsplattform bis jetzt verwendeten Formate werden in dieser Tabelle gespeichert. Aus dieser Tabelle wird beispielsweise entnommen, dass eine Zelle aus dem UNV-Format („Simulation_ID“ = 9, vgl. Tabelle 3-1) mit dem Zellentype 115 (Spalte „SimCelltype“) acht

- 29 -

Knoten umfasst (Spalte Num_of_Nodes) und unter der Identitätsnummer (SimCellType_ID = 54) zu finden ist (markierte Zeile).

SimCellType_ID

Simulation_ID

SimCelltype

Num_of_Nodes

1

2

C3D4

4

4

2

C3D8

8

16

1

Octagon

8

33

4

11

8

54
54
9
9
115
115
8
8

Tabelle 3-3: Ausschnitt aus der Tabelle „dat_simcelltype“

Damit die Überführung der Zelldaten zwischen den verschiedenen Datenformaten stattfinden kann, müssen die Tabelle 3-2 und Tabelle 3-3 zusammen verknüpft werden. Diese Verknüpfung wird in Tabelle „dat_celltypemapping“ realisiert. Ein Fragment dieser Mapping-Tabelle ist in der Tabelle 3-4 abgebildet.

CellTypeMapping_ID

CellType_ID

SimCellType_ID

1

4

1

2

4

2

41
41
6
6
54
54

Tabelle 3-4: Mapping-Tabelle für die Zelltypen namens „dat_celltypemapping“

Das obige Beispiel in Tabelle 3-3 zeigt, dass Zelltype 115 aus dem UNV_Format als Identifikator „SimCellType_ID“ den Wert 54 hat. Diesem Wert wird über die dat_celltypemapping-Tabelle der Wert 6 aus der Spalte „CellType_ID“ (Tabelle 3-4, markiert) zugewiesen. Aus der Tabelle 3-2 (rosa markiert) wird entnommen, dass der Identifikator „CellType_ID“ mit dem Wert 6 dem plattformspezifischen Zelltype 3D8 entspricht. Analog kann der plattformspezifische CellType mit Hilfe der Tabelle „dat_celltypemapping“ in seine äquivalente Darstellung im kanonischen Datenmodell überführt werden.

3.1.3 Aufbau der Datensatztabellen

Die Tabellenstruktur legt fest, wie der aktuelle Datensatz gespeichert werden soll. Zum Beispiel zeigt Tabelle 3-5 die Speicherung einer Zelle in der Datenbank. Das Attribut Cell_ID weißt jeder Zelle eine Identifikationsnummer zu. Geometry_ID legt die Zugehörigkeit der Zelle einer Geometrie fest. CellType_ID bestimmt die Art der Zelle. Attribute NodeOrder enthält die

- 30 -

Knoten, die eine Zelle umschließt. Dabei werden Knotenidentitätsnummern getrennt durch ein Komma dargestellt.

Knoten

als

Folge

von

Surrogate_ID

Geometriy_ID

Cell_ID

NodeOrder

CellType_ID

1

1

1

1,2,4,3,5,6,8,7

6

2

1

2

9,6,5,10,11,8,7,12

6

3

1

3

13,14,16,15,6,5,10,9

6

Tabelle 3-5: Datenbanktabelle „cell“

3.1.4 Materialdarstellung in der Datenbank

Nachfolgend wird die Darstellung von Materialeigenschaften im UNV-Format beschrieben. Ein Eintrag im Zelldatensatz verweist auf eine Tabelle, die alle Materialeigenschaften enthält. Dieser Eintrag wird im UNV-Format durch „physical property table number“ ausgezeichnet. Die Datenbank kann diese Struktur nicht direkt erfassen und ein Teil der vorliegenden Arbeit besteht in der Erweiterung der Datenbank, um eben diese Strukturen erfassen zu können, so dass die Speicherung und Weiterverwendung der Materialeigenschaften des UNV-Formats möglich wird. Der Materialeigenschaftseintrag wird als Geometrieeigenschaft definiert. Die Datenbank wird um die Tabellen „material“ und „material_property“ und „doublepropertyvalue“ erweitert. Die Tabelle „material“ enthält die Namen von dem Material und deren eindeutige Zuordnung zu der entsprechenden Geometrie. Die Tabelle 3-6 zeigt die Materialtabelle.

Mat_ID

Mat_Number

MatName

Geometry_ID

GeometrieAttribute_ID

1
1
1
1

MATERIAL1

1
1
1
1

2

2 MATERIAL2

1

1

3

3 MATERIAL3

1

1

4

4 MATERIAL4

1

1

Tabelle 3-6: Tabelle „material“

Jedes Material kann verschiedene Eigenschaften besitzen. Für diese Eigenschaften wurde die Tabelle 3-7 „material_property“ erstellt. Aus dieser Tabelle wird deutlich, dass beispielsweise die Temperatureigenschaft „temperatur“ (Zeile 1) mit dem „AttributeType_ID“=1 dem Material mit dem „Mat_Number“=1 gehört, das den Namen „MATERIAL1“ trägt und „Mat_ID“=1 in der Tabelle 3-6 (Zeile 1) hat.

- 31 -

MaterialProperty_ID

Mat_Number

AttributeType_ID

MatPropertyName

Components

1
1
1
1
1
1

temperature

 
Null
Null

2

1 15

 

stress

Null

3

2 33

 

POISSONS RATIO

Null

4

3 35

 

YOUNG MODULUS

Null

Tabelle 3-7:

Tabelle „material_property“

Der Wert einer Materialeigenschaft selbst wird in der Tabelle namens „doublepropertyvalue“, falls der Wert den Type double hat, gespeichert. Diese Tabelle wird in der Tabelle 3-8 präsentiert.

DoublePropertyValue_ID

MaterialProperty_ID

Value

Position

1

1

20

0

2

2

0.234

0

3

3

0.28999

0

4

4

1234567

0

Tabelle 3-8:

Tabelle für die Werte von Materialeigenschaften „doublepropertyvalue“

3.2

UNV-Format

3.2.1

Übersicht

Das UNV-Format, auch Universal File Format (UFF) genannt, wurde ursprünglich von der Structural Dynamics Research Corporation (SDRC) in den späten 1960er und frühen 1970er Jahren entwickelt [UNV-SDRC], um die Datenübertragung zwischen Anwendungen aus den Bereichen Computer Aided Design (CAD) und Computer Aided Test (CAT) zu ermöglichen und damit Computer Aided Engineering (CAE) zu erleichtern. SDRC als Teil des Unternehmens Electronic Data Systems (EDS) unterstützt und verwendet weiterhin das UNV-Format als Teil ihrer CAE-Software.

Die Formate wurden ursprünglich als 80-Spalten-Format (card image) entwickelt und in ASCII geschrieben. Jedes Format hat seine eigene Struktur und erfasst Informationen über einen bestimmten Datensatz. Eine UNV-Datei stellt eine Konkatenation von solchen Formaten dar.

Die Dateien können zum Speichern oder zur Übertragung der Informationen zwischen verschiedenen Computern verwendet werden.

- 32 -

3.2.2 Syntax und Semantik

Jede UNV-Datei ist sequentiell aufgebaut. Eine UNV-Datei besteht aus den Informationsblöcken, die Datasets genannt werden [UNV-Online]. Diese Informationsblöcke beinhalten verschiedene Informationen über das zu berechnende Model und stellen die Basisstruktur von UNV-Dateien dar. Die Datasets haben keine homogene Struktur, so dass jedes Dataset über eine eigene Syntax und Semantik verfügt.

Ein Dataset beginnt und endet mit einem Begrenzungssymbol "-1". Dabei steht das Minuszeichen in Spalte 5 und die Eins in Spalte 6. Der Rest der Zeile bleibt leer. Zwischen diesen Begrenzungssymbolen stehen die Daten, die dem Dataset zugeordnet sind. Abbildung 3–3 zeigt die Aufbaustruktur eines Informationsblocks.

3–3 zeigt die Aufbaustruktur eines Informationsblocks. Abbildung 3–3: Aufbaustruktur von einem Dataset Nach dem

Abbildung 3–3:

Aufbaustruktur von einem Dataset

Nach dem ersten Begrenzungssymbol ist die Nummer des Datasets angegeben. Diese Nummer ist wichtig, da sie das Dataset und damit die Syntax und Semantik der Daten, die nachfolgend beschrieben werden, festlegt.

Es gibt ungefähr Eintausend verschiedene Datasets. Die Abbildung 3–4 zeigt einige Beispiele für sie. Für diese Arbeit sind aber nur Daten relevant, die geometrische Eigenschaften sowie Materialeigenschaften beinhalten (vrgl. Kap. x.y). Später werden diese ausführlicher betrachtet.

- 33 -

- 33 - Abbildung 3–4: Beispiele für Datasets 3.2.3 Datasetssyntax Wie oben erwähnt hat jedes Dataset

Abbildung 3–4:

Beispiele für Datasets

3.2.3

Datasetssyntax

Wie oben erwähnt hat jedes Dataset im UNV-Format seine eigene Syntax. Dies bedeutet, dass für jedes Dataset eine andere Vorgehensweise für das Einlesen der Daten benötigt wird. Im Folgenden werden zunächst die Datasets beschrieben, die geometrierelevanten Daten enthalten. Solche sind Datasets für Knoten und für Zellen (Elemente). Anschließend wird auf das Dataset eingegangen, das einige ausgewählte Materialdaten enthält. Es werden diejenigen Materialeigenschaften beschrieben und auch durch den Integrator eingelesen, die für diese Arbeit relevant sind. Das Einlesen aller möglichen Eigenschaften ist im Rahmen dieser Arbeit nicht möglich.

3.2.3.1

Knotendarstellung

Knoten werden im UNV-Format durch das Dataset mit der Nummer 2411 festgelegt. Jeder Knoten wird in zwei Zeilen beschrieben. In der ersten Zeile stehen die Parameter, die den Knoten identifizieren, und in der zweiten Zeile die Koordinaten selbst. Abbildung 3–5 veranschaulicht die Knotendarstellung.

- 34 -

- 34 - Abbildung 3–5: UNV-Dataset für Knotendarstellung Die Parameter aus der ersten Zeile sind folgende:

Abbildung 3–5:

UNV-Dataset für Knotendarstellung

Die Parameter aus der ersten Zeile sind folgende: Identitätsnummer (node label), export coordinate system number, displacement coordinate system number und color. Neben den Koordinaten sind nur die Identitätsnummern für diese Arbeit von Relevanz.

3.2.3.2

Zellendarstellung

Ein Dataset mit der Nummer 2412 enthält Informationen über Zellen. Jede Zelle wird, ebenso wie Knoten, in zwei Zeilen beschrieben. Die Parameter aus der ersten Zeile enthalten Informationen, die die aktuelle Zelle spezifizieren. Zu diesen Informationen gehören:

Identitätsnummer (element label), der Zellidentifikator (fe descriptor id) (vgl.Abbildung 3–4), physical property table number, material property table number, color und die Anzahl von Knoten. Abbildung 3–6 illustriert die Darstellung der Zellen.

In der zweiten Zeile stehen die Knoten, repräsentiert durch die Knotenidentitätsnummer aus dem Dataset 2411, die die Zelle enthält. Wichtig sind für diese Arbeit die Identitätsnummer, Zellidentifikator, „material property table number“ und die Anzahl von Knoten. Die „material property table number“ bezeichnet dabei die Tabelle der Materialeigenschaften, die in der Tabelle 3-7 abgebildet ist.

der Materialeigenschaften, die in der Tabelle 3-7 abgebildet ist. Abbildung 3–6: UNV-Dataset für Zellendarstellung

- 35 -

- 35 - Abbildung 3–7: UNV-Format, FE Descriptor Id definitions 3.2.3.3 Materialdarstellung Materialeigenschaften werden

Abbildung 3–7:

UNV-Format, FE Descriptor Id definitions

3.2.3.3

Materialdarstellung

Materialeigenschaften werden in dem Dataset mit der Nummer 1716 bzw. 1710 spezifiziert. Dieses Dataset wird für jedes Material neu geschrieben und besteht aus drei Teilen – Header, Body und Footer. Der Header enthält Beschriftung zwischen den Trenndoppellinien. Danach stehen die Identitätsnummer und der Name des Materials. Am Ende des Headers zwischen den Trennlinien steht die Anzahl von Materialeigenschaften und deren Beschriftung „MATERIAL PROPERT(IES)“.

Als Body sind die Materialeigenschaften selbst hintereinander aufgelistet. Sie werden durch die Kommentarlinien getrennt. Eine Materialeigenschaft enthält einen Namen, Einheit, Art der Variable und den Wert selbst.

Der Footer .enthält „DEFAULT MATERIAL PROPERTIES“, die Art der Anwendung z.B. „FEM“ steht für Finite Elemente Methode und die Art der Berechnung. Auf der Abbildung 3–8 wird das Dataset 1716 veranschaulicht.

- 36 -

- 36 - Abbildung 3–8: Darstellung der Materialeigenschaften 3.3 UNV-Integrator In diesem Kapitel wird die Überführung

Abbildung 3–8:

Darstellung der Materialeigenschaften

3.3

UNV-Integrator

In diesem Kapitel wird die Überführung von Daten, repräsentiert im UNV-Format, in das kanonische Datenmodell der Simulationsplattform beschrieben. Wie bereits erwähnt, erfolgt die Integration des UNV-Formats unter Verwendung des PDI. Der Integrations-Job besteht aus einer Kette von Aktionen, die für ein korrektes Einlesen, oder wenn das korrekte Einlesen nicht möglich ist, für eine aussagekräftige Fehlermeldung sorgen. Die Abbildung 3–9 zeigt den PDI- Job, der für das Einlesen des UNV-Formats verwendet wird.

- 37 -

- 37 - Abbildung 3–9: UNV-Integrator als PDI-Job Abhängig von der Simulation kann ein Konverter verschiedene

Abbildung 3–9:

UNV-Integrator als PDI-Job

Abhängig von der Simulation kann ein Konverter verschiedene Funktionalitäten haben. Jedoch besitzt jeder Konverter eine Grundstruktur. Ein Teil der Grundstruktur sind die Funktionen, die als Präprozessor bezeichnet werden können. Das sind Funktionen, die die Korrektheit der Daten überprüfen, bevor der eigentliche Einleseprozess gestartet wird. Zu diesen Funktionen gehört unter anderen die Überprüfung ob die Variable (FILENAME), die den Dateinamen bezeichnet, ordnungsgemäß gesetzt ist. Auf der Abbildung 3–9 folgt diese Überprüfung sofort nach dem Start und wird als „Check: Filename“ bezeichnet. Falls die Variable nicht gesetzt ist oder Fehler aufweißt, wird die Ausführung mit dem Schritt „Abort job 1“, der die entsprechende Meldung wiedergibt, abgebrochen.

Als Nächstes wird die Existenz dieser Datei geprüft. Der Schritt, der dies realisiert, wird „Check:

File exists“ genannt. Falls die Datei nicht existiert, wird die Ausführung ebenfalls durch einen kontrollierten Fehler beendet.

Anschließend werden in der Transformation „GetArguments“ die Startwerte des Jobs ausgelesen. Als Startwerte können zwei Arten von Informationen auftreten. Eine Art sind Argumente. Argumente besitzen keine Namen sondern werden durch ihre Position und ihren Wert beschrieben. Die zweite Art von Informationen sind Parameter. Parameter besitzen im Vergleich zu den Argumenten einen Namen, dem ein Wert zugewiesen wird, dabei spielt die Reihenfolge, in der die Parameter angegeben werden, keine Rolle. Als Standardargumente werden in der Transformation „GetArguments“ die Informationen zur Datenbankverbindung ausgelesen.

Anschließend wird im Job die Transformation „GetSimulation_ID“ ausgeführt, die die Simulationsidentifikationsnummer abfragt. Die Identifikationsnummer der Simulationen kann sich in der Datenbank ändern, deswegen muss sie bei jedem Prozess abgerufen werden.

- 38 -

Bevor die Daten in die Datenbank geschrieben werden, muss die Geometrie bestimmt werden, zu der die Daten gehören. In der Transformation „SetGeometry_ID“ wird die Geometrienummer von der Datenbank generiert und als Variable für eine spätere Nutzung zurückgegeben. Diese Präprozessorfunktionen sind bereits in der Simulationsplattform implementiert und verfügbar.

Nachdem die Geometrie bestimmt ist, müssen die Geometrieattribute festgelegt werden. Da bei dem UNV-Format die Materialeigenschaft als Geometrieattribute behandelt wird (vgl. Kap. 3.1.4), müssen diese zuerst in der Datenbank angelegt werden. Das wird in dem Schritt „FindAttribute“ vollzogen. In diesem Schritt wird spezifiziert, welche Attribute (in diesem Fall Materialeigenschaft) die aktuelle Geometrie enthält. Dabei wird das UNV-spezifische Attribut mit Hilfe der Tabelle „dat_simattributetype“ auf die plattformspezifische Darstellung abgebildet. Der Ausschnitt dieser Tabelle ist in der Tabelle 3-9 gezeigt. Unter anderem zeigt die Tabelle, dass die plattformspezifische Bezeichnung der Materialeigenschaft in der Spalte „AttributeType_ID“ eingetragen und mit der Nummer „55“ besetzt ist (türkis markiert). Aus der Spalte „Name“ (grellgrün markiert) kann entnommen werden, welche Namen die verschiedenen Simulationen für die Materialeigenschaft benutzen. Die entsprechende Simulation ist in der Spalte „Simulation_ID“ eingetragen. Für das Einlesen des UNV-Formats wird die Zeile mit der

„SimAttributeType_ID“=214 (blaugrün (

o
o

) markiert) als Mapping-Funktion benutzt.

SimAttributeType_ID

Simulation_ID

AttributeTipe_ID

Unit_ID

Name
Name

214
214
9
9
55
55
1
1
grain
grain
…

165

7

55
55

1

material
material

178

3

55
55

1

Material_id

 

243

9

36
36

1

SHEAR MODULUS

114

1

55
55

1

26
26

Tabelle 3-9:

Tabelle der Eigenschaften „dat_simattributetype“

Der nächste Schritt im PDI-Job ist eine Transformation namens „UNVRead“. In diesem Schritt werden die geometrischen Daten eingelesen und in die Datenbank geschrieben. Da die UNV- Datei blockweise aufgebaut ist, wird zuerst nach den Blockbegrenzern „-1“ (vgl. Kap.3.2.2) gesucht. Diese Suche wird in der vorliegenden Transformation mit Hilfe von JavaScript durchgeführt. Dabei wird jede Zeile, die in den Spalten fünf und sechs ein Begrenzungssymbol enthält, mit einem Bezeichner „BlockStart“ markiert und der Bezeichner wird den Wert 0 für das gerade bzw. 1 für das ungerade Vorkommen des Begrenzungssymbols annehmen. Damit wird der Anfang und das Ende eines Datasets markiert.

- 39 -

Parallel in demselben JavaScript wird die Nummer des Datasets bestimmt. Alles was sich zwischen dem Anfangs- und Endbegrenzer des aktuellen Datasets befindet, wird mit dem Bezeichner „BlockType“ und dazugehörigen Nummer markiert. So wird es später klar zu welchem Dataset die Zeile gehört.

So wird die ganze Datei der Reihe nach von Anfang bis zum Ende durchgelesen und markiert. Das widerspiegelt die ganze Arbeitsweise des PDI. Die ganze Datei wird in Bereiche unterteilt, was einer Tabelle ähnelt. Die zusätzlichen Markierungen, die neu gewonnene Informationen darstellen, werden als Spalten hinten hinzugefügt und sind jede Zeit zugreifbar. Anhand dieser neuen Markierungen wird erkannt, welche Daten die aktuelle Zeile beinhaltet.

Die nächste Phase ist einfach die Trennung der Datei. Mit Hilfe von Switch-Anweisung werden nur für die Simulationen benötigte Datasets weiter betrachtet. Die übrig gebliebene Daten werden nicht mehr berücksichtigt und weggeworfen. Weiter werden die Datasets, die Knoten und Zellen beinhalten, parallel untersucht.

3.3.1 Das Einlesen von Knoten

Da die Beschreibung eines Knotens in einer UNV-Datei auf jeweils zwei Zeilen erfolgt (vgl. Kap.3.2.3.1), werden die beiden Zeilen zunächst zusammengefügt. Damit enthält eine Zeile alle Informationen über einen Knoten. Danach wird das Datenfeld (ehemalige Zeile 2), das unmittelbar die Koordinaten enthält, als ein regulärer Ausdruck durchgesucht. Dabei werden die Koordinateneinträge getrennt erkannt und ausgeschrieben. Auf demselben Weg werden andere Daten aus dem anderen Datenfeld (ehemalige Zeile 1) entnommen. Alle anderen Informationen, die nicht mehr gebraucht werden, werden anschließend verworfen. Außerdem werden die Knoten zu der aktuellen Geometrie hinzugefügt. Da die Koordinatenwerte nicht immer in einer datenbankkonformen Form stehen, müssen sie konvertiert werden. Das passiert in den folgenden Schritten. In dem vorletzten Schritt werden die Daten nochmals bereinigt und anschließend in die Datenbanktabelle „node“ geschrieben. Die Abbildung 3–10 zeigt wie die Knoten aus dem UNV-Format in die Datenbank überführt werden.

- 40 -

- 40 - Abbildung 3–10: Knotenüberführung in die Datenbank 3.3.2 Das Einlesen von Zellen Anfangs werden

Abbildung 3–10:

Knotenüberführung in die Datenbank

3.3.2 Das Einlesen von Zellen

Anfangs werden Zellendaten (vgl. Kap.3.2.3.2) (genau wie bei den Knoten) in die einzeilige Darstellung überführt. Anschließend werden, mittels eines regulären Ausdrucks, die Daten des ersten Datenfeldes extrahiert. Das zweite Datenfeld (ehemalige Zeile 2) besteht nur aus Knoten, die die aktuelle Zelle enthält. Diese Daten werden in die datenbankkonforme Darstellung überführt werden (vgl. Kap.3.1.3), indem die Knoten zuerst extrahiert werden und anschließend die trennenden Leerzeichen durch Kommata ersetzt werden. In dieser Form werden die Knoten in die Datenbank geschrieben. Weiter wird jede Zelle der aktuellen Geometrie zugeordnet. Als nächstes wird die plattformspezifische Art (CellType_ID, vgl. Tabelle 3-2) der Zelle ermittelt, die der aktuellen UNV-Zelle entspricht. Dazu wird eine Anfrage an die Datenbank gestellt, und die benötigten Zuordnungsdaten ausgelesen (vgl. Kap. 3.1.2). Zu guter Letzt werden die Daten in den entsprechenden Datenbanktabellen gespeichert. Die Überführung der Zellen in die Datenbank wird in der Abbildung 3–11 dargestellt.

- 41 -

- 41 - Abbildung 3–11: Zellenüberführung in die Datenbank 3.3.3 Einlesen von Materialnamen Als letztes werden

Abbildung 3–11:

Zellenüberführung in die Datenbank

3.3.3 Einlesen von Materialnamen

Als letztes werden in der PDI-Transformation „UNV_read“ die Materialnamen eingelesen. Ähnlich wie bei der vorhergegangenen Aktionen wird es in der Datei nach dem entsprechenden

- 42 -

Dataset gesucht. Der Materialname und die Materialnummer werden anschließend ermittelt und mit der aktuellen Geometrie verknüpft und in die Datenbank geschrieben. Wichtig ist dabei die Materialnummer die der „material property table number“ bei der Zellendarstellung entspricht. Diese gewährleistet die eindeutige Zuweisung des Materials einer Zelle. Die Materialnamen werden der entsprechenden Geometrie und dem entsprechenden Geometrieattribute zugeordnet. Die Abbildung 3–12 veranschaulicht diese Zuordnung.

Die Abbildung 3–12 veranschaulicht diese Zuordnung. Abbildung 3–12: Speicherung der Materialnamen in die DB

Abbildung 3–12:

Speicherung der Materialnamen in die DB

- 43 -

3.3.4 Einlesen von Materialeigenschaften

Die letzte Transformation des UNV-Integrators heißt „UNVMatRead“ (Abbildung 3–9). In dieser PDI-Transformation werden die Materialeigenschaften und deren Werte ausgelesen und in die Datenbank gespeichert. Nachdem das entsprechende Dataset gefunden ist, wird es auf die Namen der Materialeigenschaften durchgesucht. Die Materialeigenschafsnamen werden mit den Namen aus der Tabelle 3-9 verglichen und dementsprechend zugeordnet (vgl. Kap. 3.2.3.3). Abbildung 3–13 stellt diese Überführung dar.

3.2.3.3). Abbildung 3–13 stellt diese Überführung dar. Abbildung 3–13: Überführung von Materialeigenschaften

Abbildung 3–13:

Überführung von Materialeigenschaften und deren Werten in die DB

Es werden nur drei Materialeigenschaften realisiert, weil die Realisierung aller Materialeigenschaften den Rahmen dieser Arbeit sprengen würde. Diese sind Elastizitätsmodul (Modulus of Elasticity), Poissonzahl (Poissons Ratio) und Schubmodul (Shear Modulus). Diese

- 44 -

Eigenschaften beschreiben wichtige Materialdaten, die auch durch die Verformung der Geometrie des Bauteils bestimmt werden.

3.4

UNV-Extraktor

Der Extraktor (Abbildung 3–14) startet, wie auch Integrator, mit der Überprüfung der Parameter. Die Aktion „Check Filename“ prüft ob der Parameter „FILENAME“ richtig gesetzt ist. Über diesen Parameter wird der Pfad der Name für die Ausgabedatei festgelegt. Falls dieser Parameter keinen Wert hat, muss die Ausführung gestoppt und ein Fehler ausgegeben werden.

die Ausführung gestoppt und ein Fehler ausgegeben werden. Abbildung 3–14: UNV-Extraktor als PDI-Job Mit dem Schritt

Abbildung 3–14:

UNV-Extraktor als PDI-Job

Mit dem Schritt „Get Arguments“ werden Standardargumente ausgelesen und als Parameter gespeichert.

Der Schritt „Get Geometry_ID“ liefert die Geometrienummer, die die auszuschreibenden Informationen eindeutig zu identifizieren lässt. Diese wird als Parameter abgespeichert.

In dem Schritt „Get Simulation_ID“ wird die Nummer der Simulation ermittelt und als Parameter „SIMULATION_ID“ abgespeichert.

Der nächste Schritt heißt „Get_Geometryattribute“. In diesem Schritt wird festgestellt ob die auszuschreibende Geometrie die Materialeigenschaft enthält. Dieser Attribute wird als Parameter „GEOMETRYATTRIBUTE_ID“ gespeichert. Anhand des Geometrieattributes werden Materialeigenschaften identifiziert, die ausgeschrieben werden müssen.

In dem Schritt „Nodes Output“ werden Knoten gemäß UNV-Format ausgeschrieben.

In dem Schritt „Cell Output“ werden die Zellen gemäß UNV-Format ausgeschrieben.

- 45 -

In dem vorletzten Schritt „GetMaterial“ werden Materialnamen ausgeschrieben.

Beim letzten Schritt werden Materialeigenschaften und deren Werte, falls sie existieren, ausgeschrieben. Damit wird die Extraktion abgeschlössen.

4.

Datenvorbereitung

- 46 -

In diesem Kapitel werden weitere Teile vom Dataintegrator betrachtet. Zuerst werden Funktionen und Ziele der Data Enrichment Komponente erläutert, sowie seine Bestandteile erklärt. Anschließend werden die im Rahmen dieser Arbeit identifizierten und durchgeführten Anpassungen an dieser Komponente vorgestellt.

4.1 Data Enrichment

Die Aufgabe des Data Enrichments besteht darin, eine Datentransformation zu ermitteln, so dass die vorliegenden Daten in das Datenformat der Simulation überführt werden können. Dabei muss Data Enrichment in der Lage sein die Eingabedaten zu erkennen, die für eine erfolgreiche Kopplung notwendig sind [Schilberg 2010]. Die Simulationen können direkt gekoppelt werden, wenn alle dazu notwendigen Informationen vorliegen. Falls das nicht der Fall ist, muss das Data Enrichment in der Lage sein zu entscheiden, ob die benötigten Informationen aus den schon vorhandenen hergeleitet werden können. Dabei sollen - falls nötig - bei einer Simulation erzeugte Ergebnisse für die Berechnung der weiteren Simulationen verwendet werden. Um solche Entscheidungen treffen zu können, muss das Data Enrichment zum einen wissen, um welche Informationen es sich handelt, und zum anderen muss es in die Lage versetzt werden diese Informationen zu interpretieren, um zu bestimmen, welche Daten für die Ausführung der nächsten Simulation fehlen. Um das zu erreichen, muss Data Enrichment Schlüsse aus dem vorliegenden Wissen ziehen können. Das ist möglich bei auf Logik basierten Ontologien (vgl. Kap. 2.3), daher wird das Wissen in einer Wissensbasis abgebildet und in einer Ontologie formal repräsentiert. In den nachfolgenden Kapiteln werden die Wissensbasis und die zugrunde Ontologie liegende erläutert.

4.2 Wissensbasis

Wissensbasis wird mit der Ontologiesprache OWL repräsentiert. In der Wissensbasis wird die Struktur der Datenbank abgebildet. Als Anwendung, das die Arbeit mit OWL erleichtert, wird die OWL-Editor Protege benutzt.

- 47 -

Das Wissen wird in drei Bereiche unterteilt, nämlich Classes, Object Properties und Data Properties. In dem Bereich Classes werden die Klassen modelliert. Der Bereich Object Properties enthält Relationen. Die Datenwerte werden im Bereich Data Properties festgesetzt. Weiter werden diese Bereiche näher betrachtet.

Classes

Im Classes wird die Klassenhierarchie erstellt. Die oberste Klasse, wie in der OWL üblich ist, ist Konzept Thing. Die Oberklasse Thing enthält als Unterklassen die Konzepte Application, Axiom, Object, OntologyConfiguration und Predicate. Auf der Abbildung 4–1 wird der Ausschnitt aus der Klassenhierarchie dargestellt.

wird der Ausschnitt aus der Klassenhierarchie dargestellt. Abbildung 4–1: Wissensbasisauschnitt für

Abbildung 4–1:

Wissensbasisauschnitt für Klassenhierarchie

Eine wichtige Unterklasse der Klasse Object ist das Konzept Dataset. Dieses Konzept enthält als Unterklassen die Konzepte, die eine Menge von Individuen enthalten. Zu diesen gehören beispielsweise Konzepte, die geometrischen Informationen darstellen. Unter diesen Konzepten sind Node, Cell, Geometrie usw. Wie auf der Abbildung ersichtlich sind die Klasse Geometry und zum Beispiel Klasse Node als Unterklasse von Dataset gleichwertig.

Für jede Klasse werden einige Eigenschaften definiert. Als Beispiel werden Eigenschaften der Klasse Node dargestellt. Als Oberklasse (Superclasses) von Node ist die Klasse Dataset eingetragen. Weiter werden diejenigen Klassen aufgelistet, die disjunkt zu der beobachteten Klasse sind. Für die Klasse Node sind beispielsweise Klassen CellType, Nodeset, Unit, Cell, Geometry, Interface u.a. als disjunkt eingetragen. Außer Eigenschaften haben Klassen

- 48 -

Anmerkungen (annotations), die später im Kapitel 4.2.1 erläutert werden. Als konkrete Mitglieder einer Klasse werden Individuen definiert. Die geometrischen Informationen werden

nicht in die Wissensbasis übertragen, dafür ist die Ontologie nicht geeignet (vgl. Kapitel 4.2.1). Dagegen werden die Individuen von Klassen, die die Stammdaten repräsentieren, in der Wissensbasis abgebildet. Beispielsweise wird ein Individuum der Klasse CellType (vgl. Tabelle 3-2) in der Wissensbasis auf folgende Weise presäntiert:

CellType_3D8

Types:

Annotations:

Object Properties

CellType

dbName „3D8“

Object Properties auch Objekteigenschaften genannt verknüpfen die Classes miteinander. In der Wissensbasis ist Objekteigenschaft topObjectProperty als Oberklasse definiert. topObjectProperty hat als Unterklassen beispielsweise hasCell, hasNode, isCellOf, hasParameter. An dem Beispiel von hasNode wird die Definitionsweise von Objekteigenschaften erklärt.

hasNode

Domain:

Geometry

Range:

Node

Super Properties:

topObjectProperty

Inverse Properties:

isNodeOf

Die Domain beschränkt den Definitionsbereich auf die Individuen der Klasse Geometry, das bedeutet, dass die Individuen, die Objekteigenschaft hasNode nutzen, müssen der Klasse Geometry angehören. Als Range wird der Wertebereich auf die Individuen der Klasse Node eingeschränkt, was bedeutet, dass die Individuen, auf die diese Objekteigenschaft sich bezieht, müssen der Klasse Node angehören. Mit der „Super Properties“ wird die Oberklasse von der aktuellen Objekteigenschaft festgelegt. Die „Inverse Peoperties“ zeigt auf die inverse Objekteigenschaft zu der aktuellen. Die Abbildung 4–2 illustriert die inverse Verknüpfung zweier Individuen.

- 49 -

- 49 - Abbildung 4–2: Inverse Objekteigenschaft (Tenbrock) Data Properties Data Properties zu Deutsch

Abbildung 4–2:

Inverse Objekteigenschaft (Tenbrock)

Data Properties

Data Properties zu Deutsch Datentypeigenschaften verknüpfen Individuen mit Datenwerten wie Integer, Strings oder Gleitkommazahlen. Datentypeigenschaften erlauben nur als 1:1- Beziehungen.

4.2.1

Annotations

In diesem Kapitel wird die Bedeutung von Annotations erklärt. Annotations selbst sind keine logischen Elemente der Ontologie, sondern lediglich Anmerkungen zur Beschreibung anderer Ontologieelemente. In der Simulationsplattform werden Annotations benutzt, um die Ontologieelemente (Klassen, Individuen, Objekteigenschaften, Datentypeigenschaften) mit den Datenbankelementen zu verknüpfen. Ontologiesysteme sind nicht für Bearbeitung großer Datenmenge wie beispielsweise Datenbanken spezialisiert. Die Zeit, die gebraucht wird, um Klassifizierungsprozess zum Beispiel einer Geometrie mit Hilfe eines Reasoners duchzuführen, wächst mit der Anzahl von Knoten exponentiell. Reasoner ist Teil einer Ontologie, der für die Ableitung neuen Wissens zuständig ist. Die Tabelle Tabelle 4-1 zeigt die zeitliche Entwicklung bei wachsender Anzahl von Knoten einer Geometrie.

Zahl der Knoten

Benötigte Zeit

100

0,5 sec

500

27

sec

1000

3 min 28 sec

2000

26

min 39 sec

Tabelle 4-1:

Benötigte Zeit zur Klassifizierung (Tenbrock)

Die Annotations enthalten Informationen über die Position von Daten in der Datenbank. Am Beispiel von CellType wird gezeigt, wie das funktioniert.

CellType

- 50 -

Annotations:

dbTable dat_celltype

dbIDColumn CellType_ID

dbNameColumn CellType

Dabei zeigt dbTable in welcher Datenbanktabelle sich der benötigte Datensatz befindet. dbIDColumn teilt mit, in welcher Spalte die eindeutigen IDs der Objekte stehen. Diese werden als Primärschlüssel verwendet. Falls ein Objekt über einen Namen verfügt, wird auf diesen mittels dbNameColumn an die entsprechende Spalte verwiesen.

Entsprechend der Annotations wird eine SQL-Anfrage an die Datenbank gestellt, mit der die benötigten Daten geholt werden.

4.2.2

Merkmale

Ein Merkmal spiegelt den Datenzustand wider. Die Merkmale werden in der Ontologie definiert und auf Erfüllbarkeit getestet. Bei Unerfüllbarkeit werden entsprechende Aktionen gestartet, zum Beispiel Transformationen, die die bestehenden Daten anreichern. Wenn alle Merkmale erfüllt sind, wird die nächste Simulation gestartet.

Ein Merkmal wird durch eine eigene Klasse dargestellt. Diese Klasse wird als Unterklasse von Konzept Feature definiert (vgl. Abbildung 4–1). Ein Merkmal kann beliebig viele Parameter besitzen. Diese müssen unter Objekteigenschaft hasParameter definiert sein, und können zur Definition mehrerer Merkmalen verwendet werden. Ein Beispiel für die Definition eines Merkmals SortedNodesFeature:

SortedNodesFeature

Super classes

Feature

hasGeometryParameter some (Geometry and SortedNodesGeometry

and (hasMinNodeIDValue some Number))

hasStartIndexParameter some Number

Dieses Merkmal hat zwei Parameter nämlich hasGeometryParameter und hasStartIndexParameter. Der erste Parameter besagt, dass es eine Geometrie und ein Individuum

- 51 -

der Klasse SortedNodesGeomtry geben muss, so dass es eine bestimmte Nummer existiert. Diese Nummer ist von Type hasMinNodeIDValue und ist äquivalent der Nummer des Types hasStartIndexParameter des zweiten Parameters. Das bedeutet, dass in der Geometrie die Knoten sortiert sind und der Knoten mit der kleinsten Nummer auch ein Startknoten sein muss.

Im folgenden Kapitel werden Änderungen am System erklärt.

4.3

Systemanpassung

In diesem Teil werden die Veränderungen erläutert, die notwendig sind, um Ziele der Arbeit zu erreichen. Im Kapitel 4.3.1 wird erläutert, wie die Datenbank angepasst wurde. Im Kapitel 4.3.2 wird die Erweiterung der Wissensbasis erklärt. Im Kapitel 4.3.3 wird Algorithmus zur Interfacebestimmung dargestellt.

4.3.1

Datenbankerweiterung

Die Datenbank enthält geometrische Informationen, die mit Hilfe von Knoten und Zellen dargestellt sind. Bis jetzt wurden die Flächen nicht in der Datenbank abgebildet (vgl. Kap. 3.1.1). Das Speichern der Flächen ist platzaufwändig und verkompliziert die Datenstruktur, außerdem können Flächen jede Zeit aus der Zelldarstellung ausgerechnet werden, was die Darstellung von Flächen allgemein überflüssig macht. Nun bei bestimmten Berechnungen wie beispielsweise Diskontinuitätenberechnung werden Informationen über Interfaces gebraucht und müssen bereitgestellt werden.

Flächen werden (wie auch Zellen) als Folge von Knoten dargestellt. Knoten markieren dabei die Eckpunkte einer Fläche und im vergleich zu den Zellen liegen auf einer Ebene.

Die Datenbankstruktur wird um Tabelle „interface“ erweitert. Diese soll die Interfaces aufnehmen. Diese Tabelle enthält fünf Spalten. Die erste Spalte wird mit der eindeutigen Nummer „Surrogate_ID“ gefüllt. Die zweite Spalte speichert die Geometrienummer „Geometry_ID“, zu der das Interface gehört. In der dritten Spalte wird die Nummer der Zelle „Zell_ID“ abgelegt, zu der die Fläche gehört. Die vierte Spalte nimmt die Identitätsnummer „Interface_ID“ der Fläche auf. Schließlich wird in der letzten Spalte die Nummer „SurfaceNumber“ gespeichert, die die Position einer Fläche in einer Zelle markiert (vgl. Kap.

- 52 -

4.3.3). Die Datenbanktabelle „interface“ ist in der Tabelle 4-2 mit möglichen Anfangswerten dargestellt.

Surrogate_ID

Geometriy_ID

Cell_ID

Interface_ID

SurfaceNumber

1

1

1

1

1

2

1

1

2

2

3

1

1

3

3

Tabelle 4-2:

Datenbanktabelle „interface“

4.3.2

Wissensbasiserweiterung

Die Wissensbasis muss auf das Konzept Interface erweitert werden. Diese Klasse bekommt den Namen Interface und ist eine Unterklasse von Dataset. Sie wird definiert wie folgt:

Interface

Annotations:

dbTable interface

dbIDColumn Interface_ID

Superclasses:

Dataset

Disjoint classes:

CellType, Node, Unit, Cellset, Cell, Geometry, Nodeset, usw.

Außer Interface werden die Objekteigenschaften hasInterface und hasInterfaceParameter

definiert. Die hasInterface ist als Unterklasse von topObjectProperty und hasInterfaceParameter als Unterklasse von hasParameter definiert. Die hasInterfaceParameter wird als Parameter bei dem Merkmal ExistsInterfaceFeature verwendet, das die Existenz von Interfaces prüfen soll. Außer diesen Objekteigenschaften wird noch eine Objekteigenschaft festgelegt, die invers zu der hasInterface ist, nämlich die isInterfaceOf. Diese Definitionen von diesen Objekteigenschaften werden wie folgt in der Wissensbasis abgebildet:

hasInterface

Domains:

Geometry

Ranges:

Interface

Super properties:

topObjectProperty

Inverse properties:

isInterfaceOf

isInterfaceOf

Annotations:

Super properties:

Inverse properties:

hasInterfaceParameter

- 53 -

dbForeignKey Geometry_IDtopObjectProperty hasInterface

Ranges:

Interface

Super properties:

hasParameter

Wie oben schon erwähnt wird in der Wissensbasis das Merkmal ExistsInterfaceFeature definiert, das von Dataanalalyser gebraucht wird. Vor der Berechnung einer Simulation überprüft das Dataanalyser den Datenzustand, dabei werden alle in der Wissensbasis existierenden Merkmale auf die Erfüllbarkeit getestet. Das Merkmal ExistsInterfaceFeature prüft für die Homat- Simulation ob Interfaces, die dabei gebraucht werden, in der Interface-Tabelle enthalten sind. Es wird angenommen, dass wenn diese Tabelle nicht leer ist, dann soll sie mit korrekten Daten gefüllt sein. Diese Annahme wurde so getroffen, weil die Korrektheitsüberprüfung aller Interfaces so lange dauern würde wie die Berechnung von Interfaces selbst.

Das Merkmal ExistsInterfaceFeature ist als Unterklasse von Feature wie folgt definiert:

ExistsInterfaceFeature

Super classes

Feature

hasGeometryParameter some (Geometry and (hasInterface some Interface))

hasInterfaceParameter some Interface

4.3.3 Transformation zur Interfacebestimmung

In diesem Kapitel wird Algorithmus beschrieben, der als Transformation für die Interfaceberechnung verwendet wird.

Als erstes bildet der Algorithmus eine Liste mit allen Flächen (flae_index), die einer Geometrie.angehören. Diese Liste wird gemäß einer Konvention erstellt, und soll alle Flächen mit Knoten in einer festen Reihenfolge enthalten. Die Konvention gibt vor, wie Flächen mit den Knoten aus einer Zelle gebildet werden und wird mit folgenden Graphiken verdeutlicht. In

- 54 -

Abbildung 4–3 werden Volumenelemente (Hexaeder, Pentaeder und Tetraeder) mit einer festen Knotenreihenfolge gezeigt.

und Tetraeder) mit einer festen Knotenreihenfolge gezeigt. Abbildung 4–3: Knotenreihenfolge bei Volumenelementen Die

Abbildung 4–3: Knotenreihenfolge bei Volumenelementen

Die Tabelle Tabelle 4-3 legt fest, mit welchen Knoten die einzelnen Flächen markiert werden. Dabei bezeichnen die Tabelleneinträge die Positionen von Knoten in einer Auflistung. Bei dem UNV-Integrator wird Knotenauflistung aus der Datei übernommen, was in Abbildung 4–4 verdeutlicht wird (vgl. Tabelle 3-5). Die Flächennummer entspricht der SurfaceNumber aus der Tabelle 4-2. Diese Nummer wird bei der Simulation HOMAT verwendet, um eine Fläche zu identifizieren.

Flächennummer

Hexaeder

Pentaeder

Tetraeder

1. Fläche

1

2

3

4

1

2

3

-

1 2

3

-

2. Fläche

5

6

7

8

4

5

6

-

1 2

4

-

3. Fläche

2

6

7

3

2

5

6

3

2 4

3

-

4. Fläche

1

5

8

4

1

4

6

3

1 4

3

-

5. Fläche

1

2

6

5

1

2

5

4

- -

-

-

6. Fläche

4

3

7

8

-

-

-

-

- -

-

-

Tabelle 4-3:

Knotenpositionen bei Flächen von Volumenelementen

- 55 -

- 55 - Abbildung 4–4: Knotenpositionen bei UNV-Format Die Idee des Algorithmus ist in aufsteigender Reihenfolge

Abbildung 4–4: Knotenpositionen bei UNV-Format

Die Idee des Algorithmus ist in aufsteigender Reihenfolge sortierte Flächen mit sortierten Flächenknoten paarweise zu vergleichen. Dabei werden die Flächen mit den gleichen Knoten als Interface und Flächen, die einzeln vorhanden sind, automatisch als Oberflächen gespeichert.

5.

Zusammenfassung

- 56 -

Das Ziel der Arbeit war die Entwicklung und die Implementierung eines Wissenscompilers, der SGPLAN6 lieferten hierfür die besten Ergebnisse.

- 57 -

6. Abbildungsverzeichnis Abbildung 1–1: Facharchitektur der Simulationsplattform [Reinhard 2011]

Abbildung 1–2: Simulationskette zum Herstellung eines Getriebezahnrads [Schilberg 2009] 5

Abbildung 2–1: Mögliche Darstellung von Knoten und Zellen in einer relationalen Datenbank

4

 

10

Abbildung

2–2: Interface vom PDI

12

Abbildung 2–3: Beispiel für Ontologieklassen und Individuen

15

Abbildung 2–4: Schichtung der Ontologiesprachen [Kuhnt 2003]

17

Abbildung 2–5: OWL Teilsprachen [Wichmann 2007]

19

Abbildung 2–6: Definition von Konzepten in OWL

20

Abbildung 2–7: Definition von Unterkonzepten und Anmerkungen in OWL

21

Abbildung 2–8: Definition von Individuen in OWL

21

Abbildung 2–9: Explizite Definition von Individuen in OWL

22

Abbildung 2–10: Definition von abstrakten Relationen in OWL mit owl:ObjectProperty22 Abbildung 2–11: Definition von abstrakten Relationen in OWL mit owl:DatatypeProperty

 

22

Abbildung 2–12: Definition von konkreten Relationen in OWL

23

Abbildung 3–1: Tabellennamen am Beispiel der Knotentabellen

26

Abbildung

3–2: Datenbankrelationen

 

27

Abbildung 3–3: Aufbaustruktur von einem Dataset

32

Abbildung

3–4: Beispiele für Datasets

 

33

Abbildung

3–5:

UNV-Dataset

für

Knotendarstellung

34

Abbildung

3–6:

UNV-Dataset

für

Zellendarstellung

34

Abbildung 3–7: UNV-Format, FE Descriptor Id definitions

35

Abbildung

3–8: Darstellung der Materialeigenschaften

36

Abbildung

3–9:

UNV-Integrator als

PDI-Job

37

Abbildung 3–10: Knotenüberführung in die Datenbank

40

Abbildung 3–11: Zellenüberführung in die Datenbank

41

Abbildung 3–12: Speicherung der Materialnamen in die DB

42

Abbildung 3–13: Überführung von Materialeigenschaften und deren Werten in die DB43

Abbildung

3–14: UNV-Extraktor als PDI-Job

44

Abbildung

4–1: Wissensbasisauschnitt für Klassenhierarchie

47

Abbildung

4–2: Inverse Objekteigenschaft (Tenbrock)

49

- 58 -

Abbildung 4–3: Knotenreihenfolge bei Volumenelementen

54

Abbildung 4–4: Knotenreihenfolge bei Volumenelementen

55

7. Tabellenverzeichnis

- 59 -

Tabelle

3-1: Beispiel der „dat_simulation“

 

28

Tabelle

3-2: Ausschnitt

aus

der

Tabelle

„dat_celltype“

28

Tabelle

3-3: Ausschnitt

aus

der

Tabelle

„dat_simcelltype“

29

Tabelle 3-4: Mapping-Tabelle für die Zelltypen namens „dat_celltypemapping“

29

Tabelle

3-5: Datenbanktabelle

„cell“

30

Tabelle

3-6: Tabelle

„material“

30

Tabelle

3-7: Tabelle

„material_property“

 

31

Tabelle 3-8: Tabelle für die Werte von Materialeigenschaften „doublepropertyvalue“

31

Tabelle

3-9: Tabelle

der Eigenschaften „dat_simattributetype“

38

Tabelle 4-1: Benötigte Zeit zur Klassifizierung (Tenbrock)

49

Tabelle 4-2: Datenbanktabelle „interface“

 

52

Tabelle

4-3: Topologie von Volumenelementen

54

8.

Literatur

- 60 -

Cristiani 2000 Cristiani, N., Sahwe-Taylor, J.: An Introduction to Support Vector Machines and other kernel-based learning methods Cambridge Uniiversity Press, Cambridge. 2000

Elmasri 2002

Ramez Elmasri, Shamkant B. Navathe: Grundlagenn von Datenbanksystemen. © 2002 Pearson Studium, publishing as ADDISON WESLEY LONGMAN.

Leser 2007 Ulf Leser, Felix Naumann: Informationsintegration: Architekturen und Methoden zur Integration verteilter und heterogener Datenquellen.2007 dpunkt.verlag GmbH

Riemer 2007

Petra Riemer, Elena Bauer: Datenbanksysteme: Theorie und Praxis mit SQL2003, Oracle und MySQL. © 2007 Pearson Studium.

Roldan 2010

Maria Carina Roldan: Pentaho 3.2 Data Integration. Packt Publishing Ltd. (2010)

Schilberg 2010

D. Schilberg: Architektur eines Datenintegrators zur durchgängigen Kopplung von verteilten numerischen Simulationen. © VDI Verlag GmbH Düsseldorf 2010

Schmitz 2011

G. J. Schmitz, U. Prahl, G. Laschet: Toward integrative

computational materials engigeering of steel components. © German Academic Society for Production Engineering (WGP)

2011

Schneider 2004

Markus, Schneider: Implementierungskonzepte für Datenbanksysteme. © Springer-Verlag Berlin Heidelberg 2004

Yu 1995

King Chun Yu: Object-oriented File Translator for the MEMCAD System. Massachusetts Institute of Technology. May 1995

- 61 -

Schilberg 2009 Schilberg Daniel, Gramatke Arno, Henning Klaus: Verkettung von Prozesssimulationen für die virtuelle Produktion. In: Tagungsband "Digitales Engineering zum Planen, Testen und Betreiben technischer Systeme 6. Fachtagung zur Virtual Reality" 12. IFF- Wissenschaftstage, 16.-18. Juni 2009, Magdeburg. Hrsg. v. Schenk, Michael: Magdeburg: Fraunhofer-Institut für Fabrikbetrieb und - automatisierung, 2009: 197-206.

PDI

Pentaho

Datta

Integrator,

URL:

http://www.pentaho.com/,

22.04.2011.

 

Müller/Groth

Günter Müller, Clemens Groth (2007): FEM für Praktiker – Band 1: Grundlagen. © Expert Verlag

UNV-Online

I-DEAS

Online

Help,

http://ol.cadfamily.com/i-

deas/sdrchelp/lang/english/unv_ug/book.htm, 11.06.2011

UNV-SDRC

http://www.sdrl.uc.edu/universal-file-formats-for-modal-analysis- testing-1/, 23.11.2010

Klein 2010 Bernd Klein: FEM Grundlagen und Anwendungen der Finite- Elemente-Methode im Maschinen- und Fahrzeugbau. Auflage 8, © Vierweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2010

Hepp/Moor 2008 Martin Hepp, Pieter De Leenheer, Aldo de Moor, York Sure (2008): Ontology Management: Semantic Web, Semantic Web Services, and Business Applications. © 2008 Springer Science+Business Media, LLC

Geisler 2009

Matthias Geisler: Semantic Web schnell+kompakt. © 2009 entwickler.press, ein Imprint der Software & Support Verlag GmbH.

- 62 -

Studer 1999

Rudi Studer, Andreas Abecker, Stefan Decker (1999): Informatik- Methoden für das Wissensmanagement. Institut AIFB Karlsruhe.

Stuckenschmidt 2009

Heiner Stuckenschmidt: Ontologie: Konzepte, Technologien und Anwendungen. © Springer-Verlag Berlin Heidelberg 2009.

Wichmann 2007

Gabriele Wichmann: Entwurf Semantic Web: Entwicklung, Werkzeuge, Sprachen. © 2007 VDM Verlag Dr. Müller.

Voss 2003

Jakob Voss (2003): Modelierung von Ontologien. Humboldt Universität zu Berlin.

Kuhnt 2003

Markus Kuhnt: Ontologiesprachen im Kontext des Semantik Web. Universität Ulm 2003

Hitzler 2008 Pascal Hitzler, Markus Krötzsch, Sebastian Rudolph, York Sure:

Semantic Web: Grundlagen. © (2008) Springer-Verlag Berlin Heidelberg.

Fensel 2007 Dieter Fensel, Holger Lausen, Jos de Bruijn, Michael Stollberg, Dumitru Roman (2007): Enabling Semantic Web Services: The Web Service Modeling Ontologie. © Springer-Verlag Berlin Heidelberg 2007.

Reinhard 2011 Tobias Meisen, Rudolf Reinhard, Daniel Schilberg, Sabina Jeschke (2011): A Framework for Adaptive Data Integration in Digital Production. ICPR21

Vassiliadis 2003

Sergio Lujan-Mora, Panos Vassiliadis, Juan Trujillo (2003): Data Mapping Diagrams for Data Warehouse Design with UML. © Springer-Verlag Berlin Heidelberg 2003.