Inhaltsverzeichnis: 1. Einfhrung ....................................................................................................................... 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 Aufbau der Datenbank .................................................................................... 24 3.1.2 Festgelegte Daten (Stammdaten) .................................................................... 27 3.1.3 Aufbau der Datensatztabellen ......................................................................... 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 3.4 UNV-Extraktor ......................................................................................................... 44

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

Einfhrung Motivation der Arbeit

In der modernen Welt werden von neuen Produkten und den darin verarbeiteten Materialien immer hhere Anforderungen abverlangt. Gleichzeitig steigt die Komplexitt 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 ermglicht. Eine solche Plattform ist die Integrierte Plattform fr verteilte numerische Simulationen (ICD B-1.2), die im Rahmen des Excellenzclusters Integrative Produktionstechnik fr Hochlohnlnder entwickelt wird. Diese Plattform stellt Methoden und Konzepte zur Kopplung von heterogenen numerischen Simulationswerkzeugen bereit, wodurch eine vollstndige Simulation von Fertigungsprozessen realisiert werden kann. Die Plattform ist in der Lage, zur Laufzeit definierte Simulationsprozesse zu erfassen, auszufhren und zu simulieren. Das bedeutet, dass die tatschliche Reihenfolge der Kopplung zunchst unbekannt ist, und erst zur Laufzeit vom Benutzer festgelegt wird. Aufgrund der Heterogenitt verschiedener Simulationsprogramme sowohl in ihrer technischen Anbindung, wie auch in ihrer Datenreprsentation 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 11 dargestellt. Der Datenintergator sowie Datenextraktor sind Dienste, die von einem Service Provider bereitgestellt werden. Die Anfragen von Applikationen Dienste benutzen zu knnen, werden durch Service Registry angenommen und verwaltet. Der Process Manager ist fr die Ausfhrung der Integrationsprozesse zustndig [Reinhard 2011].

-4-

Abbildung 11: Facharchitektur der Simulationsplattform [Reinhard 2011] Aufgrund der Dynamik in Form von unbekannten Kopplungspartnern sowie komplexen Datenformaten und -strukturen wird eine Integrationslsung bentigt, die sich adaptiv verhlt. Damit ist gemeint, dass die Integrationslsung zur Laufzeit bestimmen muss, welche Datentransformationen zur Anreicherung der Daten bentigt werden. Dabei kommen Algorithmen und Methoden aus der knstlichen 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 fr die Simulation von Gieprozessen und der Wrmebehandlung. 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 durchfhrt. Mit Untersuchungen im Mikrometerskalenbereich wird versucht die Informationen ber die Struktur und Kinetik zu gewinnen. Solche Informationen sind beispielsweise Kristallmorphologie, Korngren, Wrmeund Stofftransporte oder elastischer Spannungszustand und Mikrospannungen [----]. Da die Ergebnisse aus der Mikrostruktursimulation wegen den Skalenunterschieden nicht direkt verwendet werden knnen, mssen 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 12 gezeigt. Am Beispiel der Herstellung eines Getriebezahnrades wird die Verkettung von verschiedenen Simulationen dargestellt. Whrend eines Herstellungsprozess wird der Rohling mehrfach wrmebehandelt und umgeformt, bis aus ihm ein Zahnrad wird. Dabei finden die Simulationsprozesse auf zwei Ebenen statt. Die Makroebene, in der Umform-, Wrmebehandlungs- und Schweisimulationen verwendet werden, und die Mikroebene, in der das Gefge untersucht wird. Zwischen Makro- und Mikroebene liegt eine Transferebene, in der die Daten aus der Mikroebene fr die Verwendung in der Makroebene homogenisiert werden. Die Softwarewerkzeuge, die zum Einsatz kommen, sind eigenstndig und besitzen keine gemeinsame Schnittstellen Datenformaten, Datenstrukturen und Datenreprsentation [Schilberg 2009].
Rohling Rohling wrmbebehandelt
Wrmebehandlungen Umformungen

Zahnrad

Zahnrad wrmebehandelt
Wrmebehandlungen Schweien

Getriebezahnrad

Abbildung 12: Simulationskette zum Herstellung eines Getriebezahnrads [Schilberg 2009]

-6-

Bei Homogenisierungssimulationen werden unter anderem die Diskontinuitten berechnet. Eine Diskontinuitt entsteht an den Grenzbereichen an denen zwei verschiedene Materialgruppen mit verschiedenen Eigenschaften aneinander stoen. Diese Informationen sind notwendig, da an diesen Grenzbereichen die Materialen verschiedene Eigenschaften aufweisen. Um

Diskontinuitten berechnen zu knnen 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 angehren. 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 knnen, darzustellen. An dem Beispiel der Berechnung von Diskontinuitten werden Daten fr HOMAT um Interfaceinformationen angereichert. Die Anreicherung wird durchgefhrt, indem die bestehende Daten analysiert und implizite Informationen (hier Interfaces) expliziert werden. Als Interfaces werden diejenigen Flchen bezeichnet, die zwischen zwei Volumenelementen verschiedener Materialgruppen liegen. Interfaceflchen werden identifiziert, indem alle Flchen sortiert und danach paarweise verglichen werden. Diejenigen Flchen, die doppelt vorkommen, sind dabei Interfaces. Wichtig sind in diesem Zusammenhang auch freie, also uere Flchen, an welche keine weiteren Flchen des Bauteils angrenzen. Die Trennung von Materialgruppen passiert durch Verdoppelung von Knoten, die die entsprechende Interfaceflche darstellen. Das bedeutet, dass aus einer Interfaceflche zwei einfache Flchen entstehen, die den verschiedenen Materialgruppen gehren. 1.2 Problemstellung

Die Anbindung der Simulationssoftware CASTS erfordert die Erweiterung der im Rahmen des Exzellenzclusters entwickelten Simulationsplattform, um das von CASTS verwendete UNVFormats zu untersttzen. Des Weiteren mssen Datentransformationen bereitgestellt werden, um die bentigten Informationen (uere Flchen und Interfaceflchen) in existierenden Datenstzen anreichern zu knnen.

-7-

Um diese Anreicherung in das bestehende System integrieren zu knnen, 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, zunchst Merkmale zu identifizieren, die durch die gegebenen Daten erfllt werden. Ein Merkmal ist z.B. die Dimensionalitt von Bauteildaten (2D oder 3D). Anschlieend wird anhand der gegebenen sowie der definierten, zu erfllenden Merkmale (bestimmt durch das Datenformat) eine Transformationskette bestimmt, die auf den existierenden Datentransformationen basiert. Fr die freien Flchen und Interfaceflchen mssen entsprechende Merkmale bestimmt werden, die diese Eigenschaften beschreiben. Die Datenanalyse-Komponente muss zur Anbindung von CASTS um eben diese Merkmale erweitert werden. Aufgrund der Komplexitt 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 Mglichkeit erffnet werden, herauszufinden, ob Interfaceflchen sowie freie Flchen 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 ergnzt werden, so dass eine Abbildung der Merkmale mglich wird. 1.3 Ziele der Arbeit

Fr die Arbeit ergeben sich somit die nachfolgenden Ziele: 1. 2. Integration des UNV-Formats in die Simulationsplattform (Integrator und Extraktor). Identifikation der Merkmale, so dass freie Flchen und Interfaceflchen in einem gegebenen Datensatz analysiert werden knnen. 3. Erweiterung der Datenanalyse-Komponente, so dass komplexere Merkmale als bisher abgebildet und analysiert werden knnen.

-8-

4.

Implementierung der bentigten Datentransformationen, die freie Flchen und Interfaceflchen 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 fr 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 Nchstes 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 reprsentiert, mit deren Hilfe die Wissensbasis formuliert wurde. Es werden Bestandteile einer Ontologie sowie Ontologiesprachen, darunter OWL, erlutert. Im Kapitel 3 wird zuerst vorgestellt, wie die Datenstruktur von der Simulationsplattform aufgebaut ist. Als Nchstes wird gezeigt, wie das UNV-Format organisiert ist. Schlielich 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 nher betrachtet. Als Nchstes wird gezeigt, wie das System erweitert wurde. Dabei werden nderungen an der Datenbank und Wissensbasis erlutert. Zum Schluss wird der Algorithmus zur Interfaceberechnung vorgestellt. Kapitel 5 schliet die Arbeit mit einer Zusammenfassung ab.

-9-

2.

Grundlegende Technologien

In diesem Kapitel werden Technologien dargestellt, die in der Simulationspattform verwendet werden. Es fngt mit dem Kapitel 2.1, wo die relationale Datenbank betrachtet wird. Im Kapitel 2.2 wird der Pentaho Data Integrator vorgestellt und seine Vorteile erlutert. Kapitel 2.3 berichtet ber die Entwicklung von Ontologien. Hier werden Bestandteile einer Ontologie dargestellt. Weiter werden im Kapitel 2.3.2 Ontologiesprachen prsentiert. Schlielich wird im Kapitel 2.3.3 die Ontologiesprache OWL vorgestellt und mit einem Beispiel erlutert. 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 Datenstzen, die in einer bestimmten Beziehung zueinander stehen. Dabei reprsentiert jede Zeile der Tabelle eine Liste zusammenhngender Datenwerte und wird in der formalen Terminologie des relationales Modells als Tupel bezeichnet. Die Spaltenberschrift 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 knnen in einer Beziehung zueinander stehen. Ein Verbindungsglied zwischen diesen Tabellen ist ein Schlssel. [Schneider 2004] beschreibt einen Schlssel als: [] eine minimale Menge von Attributen einer Datei, so dass ein Datensatz hierdurch eindeutig identifiziert wird. In einer Relation knnen mehrere Schlssel existieren, wobei einer von diesen Schlsseln in der Regel den Primrschlssel (primary key) der Relation darstellt. Der Primrschlssel identifiziert den Datensatz whrend seiner gesamten Lebenszeit eindeutig im System und sollte in seinem Wert unvernderlich sein. Eine Attributkombination, die ebenfalls zur eindeutigen Identifikation des Datensatzes herangezogen werden kann, jedoch ungleich dem Primrschlssel ist, wird Sekundrschlssel (secondary key) genannt [Schneider 2004]. Die Abbildung 21 zeigt ein Beispiel fr eine relationale Datenbank. Die Tabelle Knoten enthlt als Attribute eine Identifikationsnummer (Knoten_ID) und Koordinaten (Pos. X, Pos. Y, Pos. Z) fr 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_IDs 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 enthlt das Attribute Zellen_ID, das die gegebene Eigenschaft einer bestimmten Zelle zuordnet.

Abbildung 21: Mgliche Darstellung von Knoten und Zellen in einer relationalen Datenbank Fr 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, Datenstze aus der Datenbank ausgelesen werden knnen. DQL untersttzt 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) durchgefhrt. Der Pentaho Data Integrator, auch als Kettle bekannt, ist ein in Java geschriebenes ETL-Tool. ETL steht fr Extracting (Extraktion), Transforming

- 11 -

(Transformation) und Loading (Laden) und beschreibt einen Prozess zur Datenintegration [Vassiliadis 2003]. Dieser wird in der Regel eingesetzt um groe Datenmengen aus unterschiedlichen Datenquellen in eine Datenquelle, dem sogenannten Data Warehouse zu bertragen. Hierbei umfasst die Extraktion alle Vorgnge, die notwendig sind, um die in den Datenquellen gehaltenen Daten zu extrahieren [Leser 2007]. Dieser Vorgang wird beispielsweise durch das gesteuerte Ausfhren 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 hierfr wre die Transformation aus der Form 10 Juni 2011 in die alternative Darstellung 10.06.2011. Das Laden bezeichnet das tatschliche berfhren der Daten in die endgltige

Datenreprsentation, 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 fr andere Zwecke, wie die Realisierung vom Datentransfer zwischen verschiedenen Anwendungen oder Datenbanken verwendet [Roldan 2010]. Abbildung 22 zeigt das Arbeitsfenster vom PDI. Links befindet sich eine strukturierte Leiste mit verschiedenen Optionen. Die verwendeten Optionen werden auf die Arbeitsflche (grte Flche in der Abbildung) gezogen und miteinander verkettet, abhngend davon, was der Benutzer erreichen will.

- 12 -

Abbildung 22: Interface vom PDI Die ETL-Fhigkeiten sind dabei vielfltig. Eine fr diese Arbeit wichtige Fhigkeit vom PDI ist die Mglichkeit eine Textdatei zeilenweise parallel abzuarbeiten. Das bedeutet, dass alle Zeilen gleichzeitig bearbeitet werden knnen. Der PDI enthlt Werkzeuge, die verschiedene Manipulationen von Datenbankinhalten erlauben und untersttzt standardmig weit verbreitete Formate wie z.B. Excel und XML. Darber hinaus wird die Programmiersprache Java und die Skriptsprache JavaScript untersttzt, die eine Individualisierung einzelner Arbeitsschritte ermglichen. 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 gehren, wird als Job bezeichneten. Ein PDI-Job kann verschiedene Parameter und Argumente enthalten, die fr alle Transformationen, die zu diesem Job gehren, sichtbar sind. Die Parameter knnen beispielsweise zum Speicherung von Zugriffsinformationen fr 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 ursprnglich aus der Philosophie [Hepp/Moor 2008] und bildet sich aus den griechischen Wrtern 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 Fhigkeit der Ontologie die Interoperabilitt zwischen mehreren Reprsentationen der Realitt herzustellen. Ein Beispiel ist die Realisierung der Interoperabilitt zwischen Datenprozessmodellen innerhalb von Computersystemen [Hepp/Moor 2008]. Ein weiterer entscheidender Vorteil von Ontologie ist die Fhigkeit Schlussfolgerungen aus dem formalisierten Wissen ziehen zu knnen. Als formalisiertes Wissen wird der mit Hilfe der Ontologie dargestellte Zustand der Teilrealitt 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 Verfgung, 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 Verfgung. Also beschreibt eine Ontologie einen Teil der Realitt. Diese Beschreibung lsst sich mit logischen Formeln ausdrcken. 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 erfllen muss, sind nach [Geisler 2009] folgende:

Eine Ontologie soll formal aufgebaut sein, um von Maschinen gelesen werden zu knnen. Das durch die Ontologie ausgedrckte 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 erwhnt, enthlt das Data Enrichment eine Wissensbasis. Diese Wissensbasis wird mit Hilfe von Ontologien reprsentiert. 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 ausgefhrt werden mssen, 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 erlutert. 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 dafr benutzt werden. Wichtig ist dabei auch die Subsumptionsbeziehung zwischen Klassen von Objekten [Stuckenschmidt 2009]. Als Subsumption werden die Teilmengenbeziehungen bezeichnet. Es sollen nur fr den Kontext sinnvolle Objekte abgebildet werden, um Komplexitt 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 23 veranschaulicht mgliche 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. Auerdem besitzt Pilsner ein Individuum namens Jever.

- 15 -

Abbildung 23: Beispiel fr Ontologieklassen und Individuen Relationen Nachdem die Klassenhierarchie festgelegt ist, werden die Relationen (auch Beziehungen genannt) zwischen den Klassen identifiziert. Die Relationen verknpfen verschiedene Objektklassen miteinander. Die Art der Relation wird entsprechend dem Kontext bestimmt. Beziehungen werden so gewhlt, dass sie eine hierarchische Einstufung (Teilmengebeziehung) ausdrcken. Ein Beispiel fr eine Hierarchie wre Rotwein isA Wein und Rotwein hatFarbe rot Eine andere Art von Beziehungen zeigt Zugehrigkeit einer Eigenschaft einer Klasse Es knnen parallel auch inverse Beziehungen definiert werden. [Voss 2003] hlt folgende Relationsarten sinnvoll: Hierarchische Relationen generische Relation Instanzrelation (Klasse/Instanz) Vererbungsrelation (Ober/Unterklasse)

partitive Relation (Ganzes/Teile)

- 16 -

Eigenschaftsrelation

Ordnungsrelation 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 Domne ohne Beweis immer gltig sind. [Stuckenschmidt 2009] beschreibt einen Einsatz sogenannter Closure-Axiome, die den Wertebereich einer bestimmten Eigenschaft einschrnkt. 2.3.2 Ontologiesprachen

Ontologien werden mit Ontologiesprachen modelliert. Ontologiesprachen ermglichen Teile der Realitt entsprechend einem bestimmten Kontext zu formalisieren und logisch zu beschreiben. Die Abbildung 24 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 fr die Simulationsplattform benutzt. Mehr zu der OWL in dem Kapitel 2.3.3. Weiter in diesem Kapitel werden Ontologiesprachen aus Abbildung 24 nher betrachtet.

- 17 -

Abbildung 24: Schichtung der Ontologiesprachen [Kuhnt 2003] Auf die ganz unten in der Abbildung liegenden Sprachen wird im Rahmen der Arbeit nicht nher aufgegangen. Als Nchste Sprache wird die Ontologiesprache RDF vorgestellt. RDF Ein einfaches Datenmodell zur Reprsentation von Wissen im Internet, das der

Ontologiesprachen vorangegangen ist, ist das Resource Description Framework (RDF). Die zentrale Idee von RDF besteht darin binre Relationen zwischen eindeutig bezeichneten Ressourcen zu beschreiben. Ressourcen knnen hierbei Objekte, Klassen, Relationen oder konkrete Werte bezeichnen. Binre Relationen werden im RDF in Form eines Tripels (Subjekt, Prdikat, Objekt) dargestellt Stuckenschmidt 2009. RDFS RDFS (Resource Description Framework Schema) ist eine Weiterentwicklung der

Reprsentationssprache RDF, d.h. RDFS basiert auf dem Modellierungsprimitiven des RDFAnsatzes [Kuhnt 2003]. Mittels der Aussagen, die mit RDF formuliert wurden, knnen mit RDFS Klassen und Properties definiert und Vererbungshierarchien fr Klassen und Eigenschaften erzeugt werden. RDFS hat Mglichkeit den Ursprungsbereich (domain) und Bildbereich (range) einer Objekteigenschaft zu beschrnken. Das bedeutet, dass die Individuen, die diese Objekteigenschaft verknpft, mssen der Klasse angehren, 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 fr DARPA Agent Markup Language und ist ebenfalls eine Erweiterung von RDFS. DAML ist eine ausdruckstrkere 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 Zusammenfgen von DAML und OIL hervorgegangen ist. Das Zusammenfgen wurde aufgrund der hnlichen Zielsetzung veranlasst. DAML&OIL ist weitaus ausdruckstrkere als die einzelnen Teilsprachen [Wichmann 2007]. 2.3.3 Web Ontology Language

Die Web Ontology Language (OWL) ist eine Ontologiesprache, die auf der Prdikatenlogik 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 knnen mit OWL-Konzepte einer beliebigen Domne sowie deren Beziehungen zueinander formal so beschrieben werden, dass deren Bedeutung auch fr Maschinen (Software) verarbeitbar (verstehbar) ist. Dabei geht OWL weit ber die Ausdruckmglichkeiten von RDFS hinaus, sodass insbesondere auch komplexeste Zusammenhnge, z. B. in natrlichsprachigen Stzen, hinreichend genau modelliert werden knnen OWL ist in drei Teilsprachen unterteilt. Die Teilsprachen unterscheiden sich in der Ausdrucksstrke, 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 25. Auf die einzelnen Teilsprachen wird im Folgenden im Detail eingegangen.

- 19 -

Abbildung 25: OWL Teilsprachen [Wichmann 2007] OWL Lite OWL Lite ist die OWL-Teilsprache mit der geringsten Ausdrucksmchtigkeit. Sie untersttzt die Klassifikationshierarchien mit Relationen wie bei RDFS und erlaubt einfache Restriktionen wie beispielsweise fr den lokalen Range-Bereich. Zu den einfachen Restriktionen zhlt auch die Einschrnkung der Zahlenkardinalitt, die nur die Werte 0 und 1 erlaubt. OWL Lite untersttzt ebenfalls verschiedene Eigenschaften wie zum Beispiel Transitivitt, Symmetrie und Umkehrung [Fensel 2007]. OWL Lite ist entscheidbar und hat ExpTime Komplexitt [Hitzler 2008]. OWL DL DL steht fr Description Logic und drckt die hnlichkeit von OWL DL zur Beschreibungslogik SHOIN aus. Diese OWL-Teilsprache stellt die maximale Ausdrucksmchtigkeit zur Verfgung und wird von aktuellen Softwarewerkzeugen fast vollstndig untersttzt[Hitzler 2008]. OWL DL erlaubt volle Untersttzung fr Negation, Disjunktion, Kardinalittsrestriktion und Aufzhlung [Fensel 2007]. Die OWL DL bleibt bei der maximalen Ausdrucksmchtigkeit entscheidbar und lsst vollstndige und korrekte Inferenz mit der Komplexitt NExpTime. OWL Full Die OWL Full enthlt als einzige OWL-Teilsprache das komplettes RDF-Schema (RDFS). Die Ausdrucksmchtigkeit von OWL Full ermglicht Aussagen, die die Entscheidungsfhigkeit einer Beschreibungslogik bersteigen, daher ist OWL Full unentscheidbar und verliert das volle Schlussfolgerungsvermgen.

- 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 26 am Beispiel einer Bier-Ontologie gezeigt. In diesem Fall werden Konzepte Beer, BottomFermentedBeer und Pilsner eingefhrt.

Abbildung 26: Definition von Konzepten in OWL Abbildung 27 zeigt, wie eine Teilmengenbeziehung in OWL definiert werden kann. Um die Teilmengenbeziehung auszudrcken, wird das Konstrukt rdfs:subClassOf benutzt. Dabei stehen zwei Varianten zur Verfgung. Bei der ersten Variante a wird BottomFermentedBeer als ein Unterkonzept von Beer definiert, indem das Schlsselwort rdf:resource verwendet wird. Bei der zweiten Variante b wird dem Konzept BottomFermentedBeer das Konzept Pilsner als Unterkonzept zugeordnet. In diesem Fall wird das Schlsselwort rdf:about benutzt. Mit den Schlsselwrtern rdf:resource und rdf:about kann innerhalb einer Ontologie auf die Konzepte verwiesen werden.

- 21 -

Abbildung 27: Definition von Unterkonzepten und Anmerkungen in OWL Auer Teilmengenbeziehungen wird in Abbildung 27 gezeigt, wie bei OWL Anmerkungen definiert werden knnen. Dies geschieht durch das Konstrukt rdfs:label. In diesem Beispiel wird das Schlsselwort xml:lang verwendet, was auf die zustzliche Sprachanmerkung (Language) hindeutet. In OWL existieren zwei vordefinierten Konzepte, nmlich 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 enthlt. Jedes Individuum muss mindestens einem Konzept angehren, somit wird es mindestens dem Konzept ows:Thing zugeordnet. Das Konzept owl:Nothing wird beispielsweise bei der berprfung von Klassenkonsistenz benutzt. Die Konsistenzberprfung hilft

Modellierungsfehler aufzuspren. Dabei wird eine Klasse inkonsistent genannt, wenn sie quivalent zu owl:Nothing ist. Individuen Individuen knnen als Instanzen von Konzepten definiert werden. Als Beispiel dafr wird in Abbildung 28 die Deklaration des Individuums Jever vorgestellt, das dem Konzept Pilsner angehrt.

Abbildung 28: Definition von Individuen in OWL

- 22 -

Die Abbildung 29 stellt die quivalente Definition zu der aus Abbildung 28 des Individuums Jever, dabei wird die Zugehrigkeit dem Konzept Pilsner explizit mit rdf:type angegeben.

Abbildung 29: 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 210 wird illustriert, wie die abstrakte Relation madeFrom als owl:ObjectProperty definiert ist. Dabei wird der Definitionsbereich mittels rdfs:domain (auf Individuen vom Konzept Beer beschrnkt) und der Wertebereich mittels rdfs:range (auf Individuen vom Konzept Ingredient beschrnkt) angegeben.

Abbildung 210: Definition von abstrakten Relationen in OWL mit owl:ObjectProperty In Abbildung 211 wird hingegen die Definition von einer abstrakten Relation mit Hilfe von owl:DatatypeProperty dargestellt. Dabei wird die Beschrnkung des Wertebereichs rdfs:range durch den Verweis auf eine Internetseite gesetzt.

Abbildung 211: Definition von abstrakten Relationen in OWL mit owl:DatatypeProperty

- 23 -

Ein Beispiel fr eine konkrete Relation wird in der Abbildung 212 prsentiert. Bei dieser Definition wird mit hasAlcoholicContent angegeben, welchen Alkoholgehalt das Pilsner Jever hat.

Abbildung 212: Definition von konkreten Relationen in OWL In dem nchsten Kapitel wir die praktische Realisierung von UNV-Integrator und UNVExtraktor vorgestellt.

- 24 -

3. 3.1

Integration des UNV-Dateiformats 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 erlutert, die Stammdaten enthalten. Die Stammdaten ermglichen das formatunabhngige Speichern der Daten. In dem Kapitel 3.1.3 wird die Aufbau einer Tabelle am Beispiel der Zellentabelle dargestellt. Die Datenbankerweiterung fr die Materialeigenschaften wird im Kapitel 3.1.4 erlutert. 3.1.1 Aufbau der Datenbank

Damit die Simulationsplattform mit der Ausfhrung einer Aufgabe starten kann, mssen dafr bentigte Daten in die Datenbank berfhrt 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 fr 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 drfen dabei keine formatspezifischen Informationen enthalten sondern mssen 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 berfhren. 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 formatunabhngige 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 Prfix dat_. Alle Bezeichnungen innerhalb der Datenbank sind auf Englisch.

Da die Datenformate gendert werden knnen 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, bentigen 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 Lsung von Differenzialgleichungen. [Klein 2010] beschreibt FEM in Verbindung mit CAD als: [] ein wichtiges Basisverfahren, welches im Zuge der virtuellen Produkt- und Prozessentwicklung immer strker 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. Darber hinaus wird ein Gleichungssystem aufgestellt, mittels dem die unbekannten Parameter bestimmt werden knnen. 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 [Mller/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 Schlsselwrter benutzt, die diese Informationen charakterisieren. So wird der Name fr die Datenbanktabelle, die Knoten enthlt, mit dem englischen Wort node bezeichnet, dementsprechend heit die Tabelle fr Zellen cell. Die Namen der Attributetabellen fangen mit dem Wort an, das die Entitt bezeichnet, zu dem das Attribut zugehrig ist. So wird der Name fr Tabellen in denen die Integer-Attribute einer Zelle gespeichert werden, mit

cellattributeintvalue, fr Float-Attribute mit cellattributefloatvalue oder Double-Attribute mit cellattributedoublevalue bezeichnet. Abbildung 31 fasst die Darstellung von Knotenattributen in der Datenstruktur zusammen. Auer Wertetabellen existiert eine Tabelle namens simulationstep. Diese enthlt 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 fr diese Arbeit nicht relevant.

- 26 -

Abbildung 31: Tabellennamen am Beispiel der Knotentabellen Es bilden sich Tabellengruppen, die durch ihr Prfix unterschieden werden knnen. In der Abbildung 32 sind die Tabellen, die zurzeit in der Datenstruktur des Integrationssystems abgebildet sind, dargestellt. Es sind, wie oben erwhnt, Tabellengruppen fr geometrische Objekte und deren Attribute Knoten (node) und Zellen (cell), aber auch Tabellengruppen fr Geometrien (geometry) und Prozesse (process). In der Datenbank knnen Daten von unterschiedlichen Simulationsschritten gleichzeitig gespeichert werden, deswegen wrden im Datenbankschema Tabellen eingefhrt, die zur Identifikation des aktuellen Prozesses verwendet werden. Diese Tabelle heit process. Ein Prozess kann verschiedene Geometrien z.B. Geometrien, die ein Bauteil entsprechend der zeitlichen Vernderung beschreiben, enthalten. Die entsprechende Tabelle trgt den Namen geometry. Fr eine eindeutige Identifikation einer Zelle oder eines Knotens werden Identifikatoren fr den aktuellen Prozess und die aktuelle Geometrie als auch fr die Zelle oder die Knoten verwendet. Das gleiche gilt auch fr die Attribute. In dem Kapitel 3.1.3 wird die Identifikation von Objekten nher beschrieben.

- 27 -

Abbildung 32: Datenbankrelationen 3.1.2 Stammdaten

Bis jetzt wurden die Tabellen beschrieben, in denen die zentralen Entitten einer FEMBerechnung abgebildet werden knnen. Wie weiter oben bereits erwhnt existieren in der Datenbank Tabellen, die Stammdaten enthalten. Diese Stammdaten sind formatspezifische Bezeichnungen fr verschiedene Datenstze, die fr die richtige Zuordnung verschiedener Daten verwendet werden. Diese Tabellen enthalten Mapping-Informationen ber verschiedene Datenstze, und haben besondere Namen, die mit dem Prfix dat_ ausgezeichnet sind. Als Beispieltabelle fr Stammdaten wird die Tabelle 3-1 vorgestellt.

- 28 -

Simulation_ID 1 2 3 4 9

Name larstran abaqus_odb vtk casts universal

Filter .*\.pep .*\.odb .*\.vtk .*\.vtk .*\.unv

Tabelle 3-1: Beispiel der dat_simulation In der Tabelle 3-1 werden Datenformate, die In der Plattform integriert sind, aufgelistet. Diese Tabelle heit 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 fr ihre Daten. Dies verhindert eine direkte bernahme der Daten aus einem Format in das andere. Die Daten mssen dementsprechend bersetzt werden. Das Beispiel fr 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 enthlt. Die Spalte Num_of_Nodes enthlt die Anzahl von Knoten in der entsprechenden Zelle. Alle kommenden Zellelemente werden entsprechend diesem Schema gespeichert.
CellType_ID 1 4 6 CellType 2D2 3D4 3D8 Num_of_Nodes 2 4 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 Identittsnummer (SimCellType_ID = 54) zu finden ist (markierte Zeile).
SimCellType_ID 1 4 16 33 54 Simulation_ID 2 2 1 4 9 SimCelltype C3D4 C3D8 Octagon 11 115 Num_of_Nodes 4 8 8 8 8

Tabelle 3-3: Ausschnitt aus der Tabelle dat_simcelltype Damit die berfhrung der Zelldaten zwischen den verschiedenen Datenformaten stattfinden kann, mssen die Tabelle 3-2 und Tabelle 3-3 zusammen verknpft werden. Diese Verknpfung wird in Tabelle dat_celltypemapping realisiert. Ein Fragment dieser Mapping-Tabelle ist in der Tabelle 3-4 abgebildet.
CellTypeMapping_ID 1 2 41 CellType_ID 4 4 6 SimCellType_ID 1 2 54

Tabelle 3-4: Mapping-Tabelle fr 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 berfhrt 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 weit jeder Zelle eine Identifikationsnummer zu. Geometry_ID legt die Zugehrigkeit der Zelle einer Geometrie fest. CellType_ID bestimmt die Art der Zelle. Attribute NodeOrder enthlt die

- 30 -

Knoten,

die

eine

Zelle

umschliet.

Dabei

werden

Knoten

als

Folge

von

Knotenidentittsnummern getrennt durch ein Komma dargestellt.

Surrogate_ID 1 2 3 Geometriy_ID 1 1 1 Cell_ID 1 2 3 NodeOrder 1,2,4,3,5,6,8,7 9,6,5,10,11,8,7,12 13,14,16,15,6,5,10,9 CellType_ID 6 6 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 enthlt. 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 knnen, so dass die Speicherung und Weiterverwendung der Materialeigenschaften des UNV-Formats mglich wird. Der Materialeigenschaftseintrag wird als Geometrieeigenschaft definiert. Die Datenbank wird um die Tabellen material und material_property und doublepropertyvalue erweitert. Die Tabelle material enthlt die Namen von dem Material und deren eindeutige Zuordnung zu der entsprechenden Geometrie. Die Tabelle 3-6 zeigt die Materialtabelle.
Mat_ID 1 2 3 4 Mat_Number 1 2 3 4 MatName MATERIAL1 MATERIAL2 MATERIAL3 MATERIAL4 Geometry_ID 1 1 1 1 GeometrieAttribute_ID 1 1 1 1

Tabelle 3-6: Tabelle material Jedes Material kann verschiedene Eigenschaften besitzen. Fr 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 gehrt, das den Namen MATERIAL1 trgt und Mat_ID=1 in der Tabelle 3-6 (Zeile 1) hat.

- 31 -

MaterialProperty_ID 1 2 3 4

Mat_Number 1 1 2 3

AttributeType_ID 1 15 33 35

MatPropertyName temperature stress POISSONS RATIO YOUNG MODULUS

Components Null Null Null 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 prsentiert.
DoublePropertyValue_ID 1 2 3 4 MaterialProperty_ID 1 2 3 4 Value 20 0.234 0.28999 1234567 Position 0 0 0 0

Tabelle 3-8: 3.2 3.2.1

Tabelle fr die Werte von Materialeigenschaften doublepropertyvalue

UNV-Format bersicht

Das UNV-Format, auch Universal File Format (UFF) genannt, wurde ursprnglich von der Structural Dynamics Research Corporation (SDRC) in den spten 1960er und frhen 1970er Jahren entwickelt [UNV-SDRC], um die Datenbertragung zwischen Anwendungen aus den Bereichen Computer Aided Design (CAD) und Computer Aided Test (CAT) zu ermglichen und damit Computer Aided Engineering (CAE) zu erleichtern. SDRC als Teil des Unternehmens Electronic Data Systems (EDS) untersttzt und verwendet weiterhin das UNV-Format als Teil ihrer CAE-Software. Die Formate wurden ursprnglich 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 knnen zum Speichern oder zur bertragung der Informationen zwischen verschiedenen Computern verwendet werden.

- 32 -

3.2.2 Jede

Syntax und Semantik UNV-Datei ist sequentiell aufgebaut. Eine UNV-Datei besteht aus den

Informationsblcken, die Datasets genannt werden [UNV-Online]. Diese Informationsblcke 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 verfgt. 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 33 zeigt die Aufbaustruktur eines Informationsblocks.

Abbildung 33:

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 ungefhr Eintausend verschiedene Datasets. Die Abbildung 34 zeigt einige Beispiele fr sie. Fr diese Arbeit sind aber nur Daten relevant, die geometrische Eigenschaften sowie Materialeigenschaften beinhalten (vrgl. Kap. x.y). Spter werden diese ausfhrlicher betrachtet.

- 33 -

Abbildung 34: 3.2.3

Beispiele fr Datasets

Datasetssyntax

Wie oben erwhnt hat jedes Dataset im UNV-Format seine eigene Syntax. Dies bedeutet, dass fr jedes Dataset eine andere Vorgehensweise fr das Einlesen der Daten bentigt wird. Im Folgenden werden zunchst die Datasets beschrieben, die geometrierelevanten Daten enthalten. Solche sind Datasets fr Knoten und fr Zellen (Elemente). Anschlieend wird auf das Dataset eingegangen, das einige ausgewhlte Materialdaten enthlt. Es werden diejenigen

Materialeigenschaften beschrieben und auch durch den Integrator eingelesen, die fr diese Arbeit relevant sind. Das Einlesen aller mglichen Eigenschaften ist im Rahmen dieser Arbeit nicht mglich. 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 35 veranschaulicht die Knotendarstellung.

- 34 -

Abbildung 35:

UNV-Dataset fr Knotendarstellung

Die Parameter aus der ersten Zeile sind folgende: Identittsnummer (node label), export coordinate system number, displacement coordinate system number und color. Neben den Koordinaten sind nur die Identittsnummern fr diese Arbeit von Relevanz. 3.2.3.2 Zellendarstellung

Ein Dataset mit der Nummer 2412 enthlt 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 gehren: Identittsnummer (element label), der Zellidentifikator (fe descriptor id) (vgl.Abbildung 34), physical property table number, material property table number, color und die Anzahl von Knoten. Abbildung 36 illustriert die Darstellung der Zellen. In der zweiten Zeile stehen die Knoten, reprsentiert durch die Knotenidentittsnummer aus dem Dataset 2411, die die Zelle enthlt. Wichtig sind fr diese Arbeit die Identittsnummer, 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.

Abbildung 36:

UNV-Dataset fr Zellendarstellung

- 35 -

Abbildung 37: 3.2.3.3

UNV-Format, FE Descriptor Id definitions

Materialdarstellung

Materialeigenschaften werden in dem Dataset mit der Nummer 1716 bzw. 1710 spezifiziert. Dieses Dataset wird fr jedes Material neu geschrieben und besteht aus drei Teilen Header, Body und Footer. Der Header enthlt Beschriftung zwischen den Trenndoppellinien. Danach stehen die Identittsnummer 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 enthlt einen Namen, Einheit, Art der Variable und den Wert selbst. Der Footer .enthlt DEFAULT MATERIAL PROPERTIES, die Art der Anwendung z.B. FEM steht fr Finite Elemente Methode und die Art der Berechnung. Auf der Abbildung 38 wird das Dataset 1716 veranschaulicht.

- 36 -

Abbildung 38: 3.3

Darstellung der Materialeigenschaften

UNV-Integrator

In diesem Kapitel wird die berfhrung von Daten, reprsentiert im UNV-Format, in das kanonische Datenmodell der Simulationsplattform beschrieben. Wie bereits erwhnt, erfolgt die Integration des UNV-Formats unter Verwendung des PDI. Der Integrations-Job besteht aus einer Kette von Aktionen, die fr ein korrektes Einlesen, oder wenn das korrekte Einlesen nicht mglich ist, fr eine aussagekrftige Fehlermeldung sorgen. Die Abbildung 39 zeigt den PDIJob, der fr das Einlesen des UNV-Formats verwendet wird.

- 37 -

Abbildung 39:

UNV-Integrator als PDI-Job

Abhngig von der Simulation kann ein Konverter verschiedene Funktionalitten haben. Jedoch besitzt jeder Konverter eine Grundstruktur. Ein Teil der Grundstruktur sind die Funktionen, die als Prprozessor bezeichnet werden knnen. Das sind Funktionen, die die Korrektheit der Daten berprfen, bevor der eigentliche Einleseprozess gestartet wird. Zu diesen Funktionen gehrt unter anderen die berprfung ob die Variable (FILENAME), die den Dateinamen bezeichnet, ordnungsgem gesetzt ist. Auf der Abbildung 39 folgt diese berprfung sofort nach dem Start und wird als Check: Filename bezeichnet. Falls die Variable nicht gesetzt ist oder Fehler aufweit, wird die Ausfhrung mit dem Schritt Abort job 1, der die entsprechende Meldung wiedergibt, abgebrochen. Als Nchstes wird die Existenz dieser Datei geprft. Der Schritt, der dies realisiert, wird Check: File exists genannt. Falls die Datei nicht existiert, wird die Ausfhrung ebenfalls durch einen kontrollierten Fehler beendet. Anschlieend werden in der Transformation GetArguments die Startwerte des Jobs ausgelesen. Als Startwerte knnen 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. Anschlieend wird im Job die Transformation GetSimulation_ID ausgefhrt, 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 gehren. In der Transformation SetGeometry_ID wird die Geometrienummer von der Datenbank generiert und als Variable fr eine sptere Nutzung zurckgegeben. Diese Prprozessorfunktionen sind bereits in der Simulationsplattform implementiert und verfgbar. Nachdem die Geometrie bestimmt ist, mssen die Geometrieattribute festgelegt werden. Da bei dem UNV-Format die Materialeigenschaft als Geometrieattribute behandelt wird (vgl. Kap. 3.1.4), mssen 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 enthlt. 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 (trkis markiert). Aus der Spalte Name (grellgrn markiert) kann entnommen werden, welche Namen die verschiedenen Simulationen fr die Materialeigenschaft benutzen. Die entsprechende Simulation ist in der Spalte Simulation_ID eingetragen. Fr das Einlesen des UNV-Formats wird die Zeile mit der SimAttributeType_ID=214 (blaugrn (o) markiert) als Mapping-Funktion benutzt.
SimAttributeType_ID 214 165 178 243 114 Simulation_ID 9 7 3 9 1 AttributeTipe_ID 55 55 55 36 55 Unit_ID 1 1 1 1 1 Name grain material Material_id SHEAR MODULUS 26

Tabelle 3-9:

Tabelle der Eigenschaften dat_simattributetype

Der nchste Schritt im PDI-Job ist eine Transformation namens UNVRead. In diesem Schritt werden die geometrischen Daten eingelesen und in die Datenbank geschrieben. Da die UNVDatei 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 durchgefhrt. Dabei wird jede Zeile, die in den Spalten fnf und sechs ein Begrenzungssymbol enthlt, mit einem Bezeichner BlockStart markiert und der Bezeichner wird den Wert 0 fr das gerade bzw. 1 fr 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 dazugehrigen Nummer markiert. So wird es spter klar zu welchem Dataset die Zeile gehrt. 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 zustzlichen Markierungen, die neu gewonnene Informationen darstellen, werden als Spalten hinten hinzugefgt und sind jede Zeit zugreifbar. Anhand dieser neuen Markierungen wird erkannt, welche Daten die aktuelle Zeile beinhaltet. Die nchste Phase ist einfach die Trennung der Datei. Mit Hilfe von Switch-Anweisung werden nur fr die Simulationen bentigte Datasets weiter betrachtet. Die brig gebliebene Daten werden nicht mehr bercksichtigt 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 zunchst zusammengefgt. Damit enthlt eine Zeile alle Informationen ber einen Knoten. Danach wird das Datenfeld (ehemalige Zeile 2), das unmittelbar die Koordinaten enthlt, als ein regulrer Ausdruck durchgesucht. Dabei werden die Koordinateneintrge 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 anschlieend verworfen. Auerdem werden die Knoten zu der aktuellen Geometrie hinzugefgt. Da die Koordinatenwerte nicht immer in einer datenbankkonformen Form stehen, mssen sie konvertiert werden. Das passiert in den folgenden Schritten. In dem vorletzten Schritt werden die Daten nochmals bereinigt und anschlieend in die Datenbanktabelle node geschrieben. Die Abbildung 310 zeigt wie die Knoten aus dem UNV-Format in die Datenbank berfhrt werden.

- 40 -

Abbildung 310: 3.3.2

Knotenberfhrung in die Datenbank

Das Einlesen von Zellen

Anfangs werden Zellendaten (vgl. Kap.3.2.3.2) (genau wie bei den Knoten) in die einzeilige Darstellung berfhrt. Anschlieend werden, mittels eines regulren Ausdrucks, die Daten des ersten Datenfeldes extrahiert. Das zweite Datenfeld (ehemalige Zeile 2) besteht nur aus Knoten, die die aktuelle Zelle enthlt. Diese Daten werden in die datenbankkonforme Darstellung berfhrt werden (vgl. Kap.3.1.3), indem die Knoten zuerst extrahiert werden und anschlieend 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 nchstes 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 bentigten Zuordnungsdaten ausgelesen (vgl. Kap. 3.1.2). Zu guter Letzt werden die Daten in den entsprechenden Datenbanktabellen gespeichert. Die berfhrung der Zellen in die Datenbank wird in der Abbildung 311 dargestellt.

- 41 -

Abbildung 311: 3.3.3

Zellenberfhrung in die Datenbank

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 anschlieend ermittelt und mit der aktuellen Geometrie verknpft und in die Datenbank geschrieben. Wichtig ist dabei die Materialnummer die der material property table number bei der Zellendarstellung entspricht. Diese gewhrleistet die eindeutige Zuweisung des Materials einer Zelle. Die Materialnamen werden der entsprechenden Geometrie und dem entsprechenden Geometrieattribute zugeordnet. Die Abbildung 312 veranschaulicht diese Zuordnung.

Abbildung 312:

Speicherung der Materialnamen in die DB

- 43 -

3.3.4

Einlesen von Materialeigenschaften

Die letzte Transformation des UNV-Integrators heit UNVMatRead (Abbildung 39). 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 313 stellt diese berfhrung dar.

Abbildung 313: Es werden nur

berfhrung von Materialeigenschaften und deren Werten in die DB drei Materialeigenschaften realisiert, weil die Realisierung aller

Materialeigenschaften den Rahmen dieser Arbeit sprengen wrde. Diese sind Elastizittsmodul (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 314) startet, wie auch Integrator, mit der berprfung der Parameter. Die Aktion Check Filename prft ob der Parameter FILENAME richtig gesetzt ist. ber diesen Parameter wird der Pfad der Name fr die Ausgabedatei festgelegt. Falls dieser Parameter keinen Wert hat, muss die Ausfhrung gestoppt und ein Fehler ausgegeben werden.

Abbildung 314:

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 lsst. Diese wird als Parameter abgespeichert. In dem Schritt Get Simulation_ID wird die Nummer der Simulation ermittelt und als Parameter SIMULATION_ID abgespeichert. Der nchste Schritt heit Get_Geometryattribute. In diesem Schritt wird festgestellt ob die auszuschreibende Geometrie die Materialeigenschaft enthlt. Dieser Attribute wird als Parameter GEOMETRYATTRIBUTE_ID gespeichert. Anhand des Geometrieattributes werden

Materialeigenschaften identifiziert, die ausgeschrieben werden mssen. 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 abgeschlssen.

- 46 -

4.

Datenvorbereitung

In diesem Kapitel werden weitere Teile vom Dataintegrator betrachtet. Zuerst werden Funktionen und Ziele der Data Enrichment Komponente erlutert, sowie seine Bestandteile erklrt. Anschlieend werden die im Rahmen dieser Arbeit identifizierten und durchgefhrten 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 berfhrt werden knnen. Dabei muss Data Enrichment in der Lage sein die Eingabedaten zu erkennen, die fr eine erfolgreiche Kopplung notwendig sind [Schilberg 2010]. Die Simulationen knnen 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 bentigten Informationen aus den schon vorhandenen hergeleitet werden knnen. Dabei sollen - falls ntig - bei einer Simulation erzeugte Ergebnisse fr die Berechnung der weiteren Simulationen verwendet werden. Um solche Entscheidungen treffen zu knnen, 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 fr die Ausfhrung der nchsten Simulation fehlen. Um das zu erreichen, muss Data Enrichment Schlsse aus dem vorliegenden Wissen ziehen knnen. Das ist mglich bei auf Logik basierten Ontologien (vgl. Kap. 2.3), daher wird das Wissen in einer Wissensbasis abgebildet und in einer Ontologie formal reprsentiert. In den nachfolgenden Kapiteln werden die Wissensbasis und die zugrunde Ontologie liegende erlutert. 4.2 Wissensbasis

Wissensbasis wird mit der Ontologiesprache OWL reprsentiert. 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, nmlich Classes, Object Properties und Data Properties. In dem Bereich Classes werden die Klassen modelliert. Der Bereich Object Properties enthlt Relationen. Die Datenwerte werden im Bereich Data Properties festgesetzt. Weiter werden diese Bereiche nher betrachtet. Classes Im Classes wird die Klassenhierarchie erstellt. Die oberste Klasse, wie in der OWL blich ist, ist Konzept Thing. Die Oberklasse Thing enthlt als Unterklassen die Konzepte Application, Axiom, Object, OntologyConfiguration und Predicate. Auf der Abbildung 41 wird der Ausschnitt aus der Klassenhierarchie dargestellt.

Abbildung 41:

Wissensbasisauschnitt fr Klassenhierarchie

Eine wichtige Unterklasse der Klasse Object ist das Konzept Dataset. Dieses Konzept enthlt als Unterklassen die Konzepte, die eine Menge von Individuen enthalten. Zu diesen gehren 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. Fr 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. Fr die Klasse Node sind beispielsweise Klassen CellType, Nodeset, Unit, Cell, Geometry, Interface u.a. als disjunkt eingetragen. Auer Eigenschaften haben Klassen

- 48 -

Anmerkungen (annotations), die spter im Kapitel 4.2.1 erlutert werden. Als konkrete Mitglieder einer Klasse werden Individuen definiert. Die geometrischen Informationen werden nicht in die Wissensbasis bertragen, dafr ist die Ontologie nicht geeignet (vgl. Kapitel 4.2.1). Dagegen werden die Individuen von Klassen, die die Stammdaten reprsentieren, in der Wissensbasis abgebildet. Beispielsweise wird ein Individuum der Klasse CellType (vgl. Tabelle 3-2) in der Wissensbasis auf folgende Weise presntiert:

CellType_3D8

Types: Annotations:

CellType dbName 3D8

Object Properties Object Properties auch Objekteigenschaften genannt verknpfen die Classes miteinander. In der Wissensbasis ist Objekteigenschaft hat als topObjectProperty beispielsweise hasNode wird als Oberklasse hasNode, definiert. isCellOf, von

topObjectProperty hasParameter. An

Unterklassen Beispiel von

hasCell, die

dem

Definitionsweise

Objekteigenschaften erklrt.

hasNode

Domain: Range: Super Properties: Inverse Properties:

Geometry Node topObjectProperty isNodeOf

Die Domain beschrnkt den Definitionsbereich auf die Individuen der Klasse Geometry, das bedeutet, dass die Individuen, die Objekteigenschaft hasNode nutzen, mssen der Klasse Geometry angehren. Als Range wird der Wertebereich auf die Individuen der Klasse Node eingeschrnkt, was bedeutet, dass die Individuen, auf die diese Objekteigenschaft sich bezieht, mssen der Klasse Node angehren. 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 42 illustriert die inverse Verknpfung zweier Individuen.

- 49 -

Abbildung 42: Data Properties

Inverse Objekteigenschaft (Tenbrock)

Data Properties zu Deutsch Datentypeigenschaften verknpfen Individuen mit Datenwerten wie Integer, Strings oder Gleitkommazahlen. Datentypeigenschaften erlauben nur als 1:1Beziehungen. 4.2.1 Annotations

In diesem Kapitel wird die Bedeutung von Annotations erklrt. 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 verknpfen. Ontologiesysteme sind nicht fr Bearbeitung groer Datenmenge wie beispielsweise Datenbanken spezialisiert. Die Zeit, die gebraucht wird, um Klassifizierungsprozess zum Beispiel einer Geometrie mit Hilfe eines Reasoners duchzufhren, wchst mit der Anzahl von Knoten exponentiell. Reasoner ist Teil einer Ontologie, der fr die Ableitung neuen Wissens zustndig ist. Die Tabelle Tabelle 4-1 zeigt die zeitliche Entwicklung bei wachsender Anzahl von Knoten einer Geometrie.
Zahl der Knoten 100 500 1000 2000 Bentigte Zeit 0,5 sec 27 sec 3 min 28 sec 26 min 39 sec

Tabelle 4-1:

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

- 50 -

CellType

Annotations:

dbTable dat_celltype dbIDColumn CellType_ID dbNameColumn CellType

Dabei zeigt dbTable in welcher Datenbanktabelle sich der bentigte Datensatz befindet. dbIDColumn teilt mit, in welcher Spalte die eindeutigen IDs der Objekte stehen. Diese werden als Primrschlssel verwendet. Falls ein Objekt ber einen Namen verfgt, wird auf diesen mittels dbNameColumn an die entsprechende Spalte verwiesen. Entsprechend der Annotations wird eine SQL-Anfrage an die Datenbank gestellt, mit der die bentigten Daten geholt werden. 4.2.2 Merkmale

Ein Merkmal spiegelt den Datenzustand wider. Die Merkmale werden in der Ontologie definiert und auf Erfllbarkeit getestet. Bei Unerfllbarkeit werden entsprechende Aktionen gestartet, zum Beispiel Transformationen, die die bestehenden Daten anreichern. Wenn alle Merkmale erfllt sind, wird die nchste Simulation gestartet. Ein Merkmal wird durch eine eigene Klasse dargestellt. Diese Klasse wird als Unterklasse von Konzept Feature definiert (vgl. Abbildung 41). Ein Merkmal kann beliebig viele Parameter besitzen. Diese mssen unter Objekteigenschaft hasParameter definiert sein, und knnen zur Definition mehrerer Merkmalen verwendet werden. Ein Beispiel fr die Definition eines Merkmals SortedNodesFeature: SortedNodesFeature

Super classes

Feature hasGeometryParameter some (Geometry and SortedNodesGeometry and (hasMinNodeIDValue some Number)) hasStartIndexParameter some Number Merkmal hat zwei Parameter nmlich hasGeometryParameter und

Dieses

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 erklrt. 4.3 Systemanpassung

In diesem Teil werden die Vernderungen erlutert, die notwendig sind, um Ziele der Arbeit zu erreichen. Im Kapitel 4.3.1 wird erlutert, wie die Datenbank angepasst wurde. Im Kapitel 4.3.2 wird die Erweiterung der Wissensbasis erklrt. Im Kapitel 4.3.3 wird Algorithmus zur Interfacebestimmung dargestellt. 4.3.1 Datenbankerweiterung

Die Datenbank enthlt geometrische Informationen, die mit Hilfe von Knoten und Zellen dargestellt sind. Bis jetzt wurden die Flchen nicht in der Datenbank abgebildet (vgl. Kap. 3.1.1). Das Speichern der Flchen ist platzaufwndig und verkompliziert die Datenstruktur, auerdem knnen Flchen jede Zeit aus der Zelldarstellung ausgerechnet werden, was die Darstellung von Flchen allgemein berflssig macht. Nun bei bestimmten Berechnungen wie beispielsweise Diskontinuittenberechnung werden Informationen ber Interfaces gebraucht und mssen bereitgestellt werden. Flchen werden (wie auch Zellen) als Folge von Knoten dargestellt. Knoten markieren dabei die Eckpunkte einer Flche und im vergleich zu den Zellen liegen auf einer Ebene. Die Datenbankstruktur wird um Tabelle interface erweitert. Diese soll die Interfaces aufnehmen. Diese Tabelle enthlt fnf Spalten. Die erste Spalte wird mit der eindeutigen Nummer Surrogate_ID gefllt. Die zweite Spalte speichert die Geometrienummer Geometry_ID, zu der das Interface gehrt. In der dritten Spalte wird die Nummer der Zelle Zell_ID abgelegt, zu der die Flche gehrt. Die vierte Spalte nimmt die Identittsnummer Interface_ID der Flche auf. Schlielich wird in der letzten Spalte die Nummer SurfaceNumber gespeichert, die die Position einer Flche in einer Zelle markiert (vgl. Kap.

- 52 -

4.3.3). Die Datenbanktabelle interface ist in der Tabelle 4-2 mit mglichen Anfangswerten dargestellt.
Surrogate_ID 1 2 3 Geometriy_ID 1 1 1 Cell_ID 1 1 1 Interface_ID 1 2 3 SurfaceNumber 1 2 3

Tabelle 4-2: 4.3.2

Datenbanktabelle interface

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: Disjoint classes:

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

Auer 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 prfen soll. Auer diesen Objekteigenschaften wird noch eine Objekteigenschaft festgelegt, die invers zu der hasInterface ist, nmlich die isInterfaceOf. Diese Definitionen von diesen Objekteigenschaften werden wie folgt in der Wissensbasis abgebildet:

hasInterface

Domains: Ranges: Super properties: Inverse properties:

Geometry Interface topObjectProperty isInterfaceOf

isInterfaceOf

- 53 -

Annotations: Super properties: Inverse properties:

dbForeignKey Geometry_ID topObjectProperty hasInterface

hasInterfaceParameter

Ranges: Super properties:

Interface hasParameter

Wie oben schon erwhnt wird in der Wissensbasis das Merkmal ExistsInterfaceFeature definiert, das von Dataanalalyser gebraucht wird. Vor der Berechnung einer Simulation berprft das Dataanalyser den Datenzustand, dabei werden alle in der Wissensbasis existierenden Merkmale auf die Erfllbarkeit getestet. Das Merkmal ExistsInterfaceFeature prft fr die HomatSimulation 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 gefllt sein. Diese Annahme wurde so getroffen, weil die Korrektheitsberprfung aller Interfaces so lange dauern wrde 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 Transformation zur Interfacebestimmung

4.3.3

In diesem Kapitel wird Algorithmus beschrieben, der als Transformation fr die Interfaceberechnung verwendet wird. Als erstes bildet der Algorithmus eine Liste mit allen Flchen (flae_index), die einer Geometrie.angehren. Diese Liste wird gem einer Konvention erstellt, und soll alle Flchen mit Knoten in einer festen Reihenfolge enthalten. Die Konvention gibt vor, wie Flchen mit den Knoten aus einer Zelle gebildet werden und wird mit folgenden Graphiken verdeutlicht. In

- 54 -

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

Abbildung 43: Knotenreihenfolge bei Volumenelementen Die Tabelle Tabelle 4-3 legt fest, mit welchen Knoten die einzelnen Flchen markiert werden. Dabei bezeichnen die Tabelleneintrge die Positionen von Knoten in einer Auflistung. Bei dem UNV-Integrator wird Knotenauflistung aus der Datei bernommen, was in Abbildung 44 verdeutlicht wird (vgl. Tabelle 3-5). Die Flchennummer entspricht der SurfaceNumber aus der Tabelle 4-2. Diese Nummer wird bei der Simulation HOMAT verwendet, um eine Flche zu identifizieren.
Flchennummer 1. Flche 2. Flche 3. Flche 4. Flche 5. Flche 6. Flche Hexaeder 1 5 2 1 1 4 2 6 6 5 2 3 3 7 7 8 6 7 4 8 3 4 5 8 Pentaeder 1 4 2 1 1 2 5 5 4 2 3 6 6 6 5 3 3 4 Tetraeder 1 1 2 1 2 2 4 4 3 4 3 3 -

Tabelle 4-3:

Knotenpositionen bei Flchen von Volumenelementen

- 55 -

Abbildung 44: Knotenpositionen bei UNV-Format Die Idee des Algorithmus ist in aufsteigender Reihenfolge sortierte Flchen mit sortierten Flchenknoten paarweise zu vergleichen. Dabei werden die Flchen mit den gleichen Knoten als Interface und Flchen, die einzeln vorhanden sind, automatisch als Oberflchen gespeichert.

- 56 -

5.

Zusammenfassung

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

- 57 -

6.

Abbildungsverzeichnis

Abbildung 11: Facharchitektur der Simulationsplattform [Reinhard 2011] ........................ 4 Abbildung 12: Simulationskette zum Herstellung eines Getriebezahnrads [Schilberg 2009] 5

Abbildung 21: Mgliche Darstellung von Knoten und Zellen in einer relationalen Datenbank .......................................................................................................................... 10 Abbildung 22: Interface vom PDI ...................................................................................... 12 Abbildung 23: Beispiel fr Ontologieklassen und Individuen ........................................... 15 Abbildung 24: Schichtung der Ontologiesprachen [Kuhnt 2003]...................................... 17 Abbildung 25: OWL Teilsprachen [Wichmann 2007] ....................................................... 19 Abbildung 26: Definition von Konzepten in OWL............................................................ 20 Abbildung 27: Definition von Unterkonzepten und Anmerkungen in OWL..................... 21 Abbildung 28: Definition von Individuen in OWL............................................................ 21 Abbildung 29: Explizite Definition von Individuen in OWL ............................................ 22 Abbildung 210: Definition von abstrakten Relationen in OWL mit owl:ObjectProperty22 Abbildung 211: Definition von abstrakten Relationen in OWL mit owl:DatatypeProperty .......................................................................................................................... 22 Abbildung 212: Definition von konkreten Relationen in OWL......................................... 23 Abbildung 31: Abbildung 32: Abbildung 33: Abbildung 34: Abbildung 35: Abbildung 36: Abbildung 37: Abbildung 38: Abbildung 39: Abbildung 310: Abbildung 311: Abbildung 312: Abbildung 313: Abbildung 314: Abbildung 41: Abbildung 42: Tabellennamen am Beispiel der Knotentabellen ............................... 26 Datenbankrelationen .......................................................................... 27 Aufbaustruktur von einem Dataset .................................................... 32 Beispiele fr Datasets ........................................................................ 33 UNV-Dataset fr Knotendarstellung ................................................. 34 UNV-Dataset fr Zellendarstellung................................................... 34 UNV-Format, FE Descriptor Id definitions ....................................... 35 Darstellung der Materialeigenschaften .............................................. 36 UNV-Integrator als PDI-Job.............................................................. 37 Knotenberfhrung in die Datenbank ............................................... 40 Zellenberfhrung in die Datenbank ................................................. 41 Speicherung der Materialnamen in die DB ....................................... 42 berfhrung von Materialeigenschaften und deren Werten in die DB43 UNV-Extraktor als PDI-Job .............................................................. 44 Wissensbasisauschnitt fr Klassenhierarchie .................................... 47 Inverse Objekteigenschaft (Tenbrock) .............................................. 49

- 58 -

Abbildung 43: Knotenreihenfolge bei Volumenelementen ............................................... 54 Abbildung 44: Knotenreihenfolge bei Volumenelementen ............................................... 55

- 59 -

7.

Tabellenverzeichnis

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 fr 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 fr die Werte von Materialeigenschaften doublepropertyvalue....... 31 Tabelle 3-9: Tabelle der Eigenschaften dat_simattributetype ........................................... 38 Tabelle 4-1: Bentigte Zeit zur Klassifizierung (Tenbrock) ................................................ 49 Tabelle 4-2: Datenbanktabelle interface ........................................................................... 52 Tabelle 4-3: Topologie von Volumenelementen .................................................................. 54

- 60 -

8.

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

Cristiani 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 durchgngigen Kopplung von verteilten numerischen Simulationen. VDI Verlag GmbH Dsseldorf 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 fr

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 fr die virtuelle Produktion. In: Tagungsband "Digitales Engineering zum Planen, Testen und Betreiben technischer Systeme 6. Fachtagung zur Virtual Reality" 12. IFFWissenschaftstage, 16.-18. Juni 2009, Magdeburg. Hrsg. v. Schenk, Michael: Magdeburg: Fraunhofer-Institut fr Fabrikbetrieb und automatisierung, 2009: 197-206.

PDI

Pentaho

Datta

Integrator,

URL:

http://www.pentaho.com/,

22.04.2011. Mller/Groth Gnter Mller, Clemens Groth (2007): FEM fr 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-analysistesting-1/, 23.11.2010 Klein 2010 Bernd Klein: FEM Grundlagen und Anwendungen der FiniteElemente-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): InformatikMethoden fr 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. Mller.

Voss 2003

Jakob Voss (2003): Modelierung von Ontologien. Humboldt Universitt zu Berlin.

Kuhnt 2003

Markus Kuhnt: Ontologiesprachen im Kontext des Semantik Web. Universitt Ulm 2003

Hitzler 2008

Pascal Hitzler, Markus Krtzsch, 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.