Dipl Th Andreas

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 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 Einführung 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]. Die Software CASTS verwendet die Finite Elemente Methode (FEM) zur Simulationsberechnung. Drei dieser Simulationsprogramme sind die bei der ACCESS e.V. Als Simulationswerkzeuge werden unterschiedliche Simulationsprogramme verwendet. Die technische Kopplung der Simulationen erfolgt mittels einer Grid Middleware. CASTS ist eine Software für die Simulation von Gießprozessen und der Wärmebehandlung. dass die Integrationslösung zur Laufzeit bestimmen muss. die sich adaptiv verhält. Dabei kommen Algorithmen und Methoden aus der künstlichen Intelligenz und des Semantic Web zum Einsatz.-4- 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. welche Datentransformationen zur Anreicherung der Daten benötigt werden. Die Besonderheit von CASTS liegt in der . MICRESS und HOMAT. Damit ist gemeint. entwickelten Applikationen CASTS. müssen sie konvertiert und transformiert werden. Rohling Rohling wärmbebehandelt Wärmebehandlungen Umformungen Zahnrad Zahnrad wärmebehandelt Wärmebehandlungen Schweißen Getriebezahnrad Abbildung 1–2: Simulationskette zum Herstellung eines Getriebezahnrads [Schilberg 2009] . Die Softwarewerkzeuge. MICRESS hingegen ist eine Mikrostruktursimulation mit der man Untersuchungen im Mikrometerskalenbereich durchführt. Die Software HOMAT übernimmt diese Konvertierung und Transformation der Ergebnisse aus der Mikrostruktursimulation. Wärmeund Stofftransporte oder elastischer Spannungszustand und Mikrospannungen [----]. da Gas. Dabei wird ein heterogener Werkstoff durch einen äquivalenten homogenen Werkstoff ersetzt [----]. Datenstrukturen und Datenrepräsentation [Schilberg 2009]. Zwischen Makro.-5- Betrachtung der teilerstarrten Bauteilen. sind eigenständig und besitzen keine gemeinsame Schnittstellen Datenformaten. in der Umform-. Schmelze und Erstarrtes gleichzeitig als getrennte Phasen behandelt werden [----]. Am Beispiel der Herstellung eines Getriebezahnrades wird die Verkettung von verschiedenen Simulationen dargestellt. Dabei finden die Simulationsprozesse auf zwei Ebenen statt. Der Einsatz der Simulationen wird in Abbildung 1–2 gezeigt.und Mikroebene liegt eine Transferebene. Während eines Herstellungsprozess wird der Rohling mehrfach wärmebehandelt und umgeformt. Korngrößen. in der die Daten aus der Mikroebene für die Verwendung in der Makroebene homogenisiert werden.und Schweißsimulationen verwendet werden. Mit Untersuchungen im Mikrometerskalenbereich wird versucht die Informationen über die Struktur und Kinetik zu gewinnen. Die Makroebene. Solche Informationen sind beispielsweise Kristallmorphologie. und die Mikroebene. Da die Ergebnisse aus der Mikrostruktursimulation wegen den Skalenunterschieden nicht direkt verwendet werden können. in der das Gefüge untersucht wird. die zum Einsatz kommen. Wärmebehandlungs. bis aus ihm ein Zahnrad wird. die doppelt vorkommen. Diejenigen Flächen. eine Materialgruppe von den anderen Materialgruppen getrennt wird. 1. Als Interfaces werden diejenigen Flächen bezeichnet. um die benötigten Informationen (äußere Flächen und Interfaceflächen) in existierenden Datensätzen anreichern zu können. Eine Diskontinuität entsteht an den Grenzbereichen an denen zwei verschiedene Materialgruppen mit verschiedenen Eigenschaften aneinander stoßen. . Das bedeutet dass. um Bauteile als endliche Menge von Elementen bzw. An dem Beispiel der Berechnung von Diskontinuitäten werden Daten für HOMAT um Interfaceinformationen angereichert. die geometrisch beschrieben werden können. an welche keine weiteren Flächen des Bauteils angrenzen. Eine Materialgruppe wird dabei als eine Menge von Volumenelementen angesehen.-6- Bei Homogenisierungssimulationen werden unter anderem die Diskontinuitäten berechnet. da an diesen Grenzbereichen die Materialen verschiedene Eigenschaften aufweisen. also äußere Flächen. um das von CASTS verwendete UNVFormats zu unterstützen. Des Weiteren müssen Datentransformationen bereitgestellt werden. die zwischen zwei Volumenelementen verschiedener Materialgruppen liegen. Die Anreicherung wird durchgeführt.B. die die entsprechende Interfacefläche darstellen. die den verschiedenen Materialgruppen gehören. Pentaeder. die dem gleichen Material angehören. indem die bestehende Daten analysiert und implizite Informationen (hier Interfaces) expliziert werden. Die Trennung von Materialgruppen passiert durch Verdoppelung von Knoten. sind dabei Interfaces. dass aus einer Interfacefläche zwei einfache Flächen entstehen.2 Problemstellung Die Anbindung der Simulationssoftware CASTS erfordert die Erweiterung der im Rahmen des Exzellenzclusters entwickelten Simulationsplattform. Hexaeder. Diese Informationen sind notwendig. indem alle Flächen sortiert und danach paarweise verglichen werden. Wichtig sind in diesem Zusammenhang auch freie. Interfaceflächen werden identifiziert. Das bedeutet. Um Diskontinuitäten berechnen zu können wird die Diskretisierung von Materialgruppen vorgenommen. Tetraeder). Volumenelementen (z. darzustellen. Bei HOMAT kommt der Finite-Elemente (FE) Ansatz zum Einsatz. Die Wissensbasis muss untersucht und um Konzepte und Individuen ergänzt werden. Aufgrund der Komplexität der Merkmalsdefinitionen ist die bisherige Implementierung der Datenanalyse-Komponente nicht in der Lage. herauszufinden. 1. Erweiterung der Datenanalyse-Komponente. Anschließend wird anhand der gegebenen sowie der definierten. so dass komplexere Merkmale als bisher abgebildet und analysiert werden können. oder nicht. Für die freien Flächen und Interfaceflächen müssen entsprechende Merkmale bestimmt werden. Diese Komponente setzt die beschriebene adaptive Anreicherung der vorliegenden Daten um. die Dimensionalität von Bauteildaten (2D oder 3D). die auf den existierenden Datentransformationen basiert.B. so dass eine Abbildung der Merkmale möglich wird.-7- Um diese Anreicherung in das bestehende System integrieren zu können. Merkmale werden in der Wissensbasis definiert. Daher besteht der Hauptteil der Arbeit in der Definition von diesen Merkmalen und in der Erweiterung der Datenanalyse-Komponente. 3. .3 Ziele der Arbeit Für die Arbeit ergeben sich somit die nachfolgenden Ziele: 1. zunächst Merkmale zu identifizieren. zu erfüllenden Merkmale (bestimmt durch das Datenformat) eine Transformationskette bestimmt. Der Analyse-Algorithmus sieht dabei vor. muss die in der Simulationsplattform eingesetzte Datenanalyse-Komponente angepasst werden. Die Datenanalyse-Komponente muss zur Anbindung von CASTS um eben diese Merkmale erweitert werden. Die Wissensbasis ist ein Teil der Datenanalyse-Komponente. Identifikation der Merkmale. diese Merkmale abzubilden und zu analysieren. die durch die gegebenen Daten erfüllt werden. ob Interfaceflächen sowie freie Flächen in einem Datensatz bereits identifiziert wurden. so dass freie Flächen und Interfaceflächen in einem gegebenen Datensatz analysiert werden können. 2. Dadurch soll die Möglichkeit eröffnet werden. Ein Merkmal ist z. Integration des UNV-Formats in die Simulationsplattform (Integrator und Extraktor). die diese Eigenschaften beschreiben. der zur Beschreibung von Informationen und Beziehungen über Datenbestand in der Simulationspattform verwendet wird. -8- 4. die freie Flächen und Interfaceflächen berechnen. Anfragen an die Datenbank mit der Anfragesprache SQL. Im Kapitel 3 wird zuerst vorgestellt. erläutert.und Datenanreicherungsmechanismus vorgenommen. Kapitel 5 schließt die Arbeit mit einer Zusammenfassung ab. . 1. mit deren Hilfe die Wissensbasis formuliert wurde. Schließlich werden der UNV-Integrator und UNV-Extraktor beschrieben und in das System integriert. Als Nächstes wird gezeigt. mit deren Hilfe der UNV-Integrator und der UNV-Extraktor implementiert wurden. Hauptteile der Wissensbasis wie Annotationen und Merkmale werden näher betrachtet. wie das UNV-Format organisiert ist. Es werden Bestandteile einer Ontologie sowie Ontologiesprachen. die in der Simulationsplattform zu Einsatz kommen und für diese Arbeit relevant sind. Als Nächstes wir der Pentaho Data Integrator beschrieben. darunter Speicherung der Daten mit der relationalen Datenbank. Implementierung der benötigten Datentransformationen. darunter OWL. Auch wird in diesem Kapitel die Ontologie repräsentiert. Dabei wird die Datenverwaltung beschrieben. wie die Datenstruktur von der Simulationsplattform aufgebaut ist. Zum Schluss wird der Algorithmus zur Interfaceberechnung vorgestellt. Im Kapitel 4 wird die Erweiterung des Datenerkennungs.4 Gliederung der Arbeit Als erstes wird im Kapitel 2 der Überblick über Technologien vorgestellt. wie das System erweitert wurde. Dazu wird zuerst der Aufbau der Wissensbasis vorgestellt. Als Nächstes wird gezeigt. Dabei werden Änderungen an der Datenbank und Wissensbasis erläutert. wobei einer von diesen Schlüsseln in der Regel den Primärschlüssel (primary key) der Relation darstellt. Pos.1 Relationale Datenbanken und SQL Die in der Simulationsplattform integrierten Daten werden innerhalb einer relationalen Datenbank persistiert.3 berichtet über die Entwicklung von Ontologien. Es fängt mit dem Kapitel 2.3.2 wird der Pentaho Data Integrator vorgestellt und seine Vorteile erläutert. Ein Tupel stellt somit einen Datensatz dar. Hier werden Bestandteile einer Ontologie dargestellt. Grundlegende Technologien In diesem Kapitel werden Technologien dargestellt. Genauso identifizieren die Attribute „Zellen_ID“. „Knoten“ und „Type_ID“ eine Zelle. die in der Simulationspattform verwendet werden. Die Tabelle „Knoten“ enthält als Attribute eine Identifikationsnummer (Knoten_ID) und Koordinaten (Pos. so dass ein Datensatz hierdurch eindeutig identifiziert wird. Ein Verbindungsglied zwischen diesen Tabellen ist ein Schlüssel. Eine Attributkombination. Schließlich wird im Kapitel 2. X. Die . Dabei repräsentiert jede Zeile der Tabelle eine Liste zusammenhängender Datenwerte und wird in der formalen Terminologie des relationales Modells als Tupel bezeichnet.1. Diese Attribute stehen in einer Relation zu einander. Im Kapitel 2. die ebenfalls zur eindeutigen Identifikation des Datensatzes herangezogen werden kann. [Schneider 2004] beschreibt einen Schlüssel als: “[…] eine minimale Menge von Attributen einer Datei. die in einer bestimmten Beziehung zueinander stehen. Die Spaltenüberschrift eines Tupels wird Attribut genannt [Elmasri 2002]. wird Sekundärschlüssel (secondary key) genannt [Schneider 2004]. Die Abbildung 2–1 zeigt ein Beispiel für eine relationale Datenbank. dessen Attribute die Eigenschaften eines Objekts in der realen Welt beschreiben. Pos.3. Der Primärschlüssel identifiziert den Datensatz während seiner gesamten Lebenszeit eindeutig im System und sollte in seinem Wert unveränderlich sein.3 die Ontologiesprache OWL vorgestellt und mit einem Beispiel erläutert.” In einer Relation können mehrere Schlüssel existieren. jedoch ungleich dem Primärschlüssel ist. Z) für ein dreidimensionales Koordinatensystem. Y. Weiter werden im Kapitel 2. Zwei oder mehrere Tabellen können in einer Beziehung zueinander stehen. 2. wo die relationale Datenbank betrachtet wird. Eine Relation ähnelt dabei einer Tabelle mit Datensätzen. Kapitel 2.2 Ontologiesprachen präsentiert.-9- 2. die auch bei der vorliegenden Arbeit Anwendung finden. Die DQL hat hierbei einen besonderen Stellenwert. ETL steht für Extracting (Extraktion). Die Tabelle „Zellen_Eigenschaft“ stellt eine Zelleneigenschaft dar. DQL unterstützt die Erweiterung von Anfragen um mathematische Bedienungen. Datensätze aus der Datenbank ausgelesen werden können. ist ein in Java geschriebenes ETL-Tool.2 Pentaho Data Integrator [PDI] Die Integration vom UNV-Format in die Integrationsplattform wird mit Hilfe des Pentaho Data Integrators (PDI) durchgeführt. sind die Datendefinitionssprache (DDL). Diese Tabelle enthält das Attribute „Zellen_ID“. 2. da mittels der dort enthaltenen SELECT-Anweisung. [Riemer 2007] nennt SQL “[…] eine enorm wichtige Sprache.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. Transforming . das die gegebene Eigenschaft einer bestimmten Zelle zuordnet. Der Pentaho Data Integrator. die Datenmanipulationssprache (DML) und die Datenabfragesprache (DQL). Eine Zelle kann weitere Eigenschaften besitzen. 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. auch als Kettle bekannt.. ohne die kein Datenbankentwickler auskommt.” Einige Sprachbestandteile von SQL. dem sogenannten Data Warehouse zu übertragen. Das Laden bezeichnet das tatsächliche Überführen der Daten in die endgültige Datenrepräsentation.06. Der PDI ist aber nicht nur ein ETL-Werkzeug. Bei einer Anwendung entspricht das Laden somit dem Schreiben der Daten im anwendungsspezifischen Datenformat.2011“. um die in den Datenquellen gehaltenen Daten zu extrahieren [Leser 2007]. sondern wird auch für andere Zwecke.11 - (Transformation) und Loading (Laden) und beschreibt einen Prozess zur Datenintegration [Vassiliadis 2003]. wie die Realisierung vom Datentransfer zwischen verschiedenen Anwendungen oder Datenbanken verwendet [Roldan 2010].Kapitel 2. Links befindet sich eine strukturierte Leiste mit verschiedenen Optionen. Ein Beispiel hierfür wäre die Transformation aus der Form „10 Juni 2011“ in die alternative Darstellung „10. Dies beinhaltet zum Beispiel die Umformung von Datumsangaben.. Dieser wird in der Regel eingesetzt um große Datenmengen aus unterschiedlichen Datenquellen in eine Datenquelle. also beispielsweise in ein Data Warehouse. abhängend davon. Die verwendeten Optionen werden auf die Arbeitsfläche (größte Fläche in der Abbildung) gezogen und miteinander verkettet. . was der Benutzer erreichen will. Die Transformation hingegen bezeichnet die Schritte zur Transformation der extrahierten Daten in das Format die Struktur und die Semantik der Zielanwendung. Abbildung 2–2 zeigt das Arbeitsfenster vom PDI. Hierbei umfasst die Extraktion alle Vorgänge.1). die notwendig sind. Dieser Vorgang wird beispielsweise durch das gesteuerte Ausführen von SQL-Skripten in einer relationalen Datenbank als Datenquelle realisiert (vgl. sichtbar sind. Der PDI enthält Werkzeuge. was „die Lehre . Eine Kette von bestimmten Aufgaben wird in einer sogenannten PDI-Transformation realisiert (nicht zu verwechseln mit der ETL-Transformation).12 - Abbildung 2–2: Interface vom PDI Die ETL-Fähigkeiten sind dabei vielfältig. die verschiedene Manipulationen von Datenbankinhalten erlauben und unterstützt standardmäßig weit verbreitete Formate wie z. Eine für diese Arbeit wichtige Fähigkeit vom PDI ist die Möglichkeit eine Textdatei zeilenweise parallel abzuarbeiten. Ein PDI-Job kann verschiedene Parameter und Argumente enthalten. die eine Individualisierung einzelner Arbeitsschritte ermöglichen. Eine Folge von solchen Transformationen. Als Argument wird der Pfad und der Name der einzulesenden Datei verwendet (vgl. Die Parameter können beispielsweise zum Speicherung von Zugriffsinformationen für eine Datenbank verwendet werden. die für alle Transformationen. die zu einem Prozess gehören. 2. wird als Job bezeichneten. die zu diesem Job gehören. Excel und XML.B.. Kapitel 3. Darüber hinaus wird die Programmiersprache Java und die Skriptsprache JavaScript unterstützt. dass alle Zeilen gleichzeitig bearbeitet werden können. Das bedeutet.3).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). Diese Wissensbasis wird mit Hilfe von Ontologien repräsentiert. Diese Beschreibung lässt sich mit logischen Formeln ausdrücken. eines Unternehmensbereiches. sind nach [Geisler 2009] folgende: − − − − Eine Ontologie soll formal aufgebaut sein. Solch eine Ontologie stellt eine von dieser Personengruppe gemeinsam getragene Sicht auf einen Anwendungsbereich zur Verfügung. Es soll zumindest in einem kleinen Kreis. Ein weiterer entscheidender Vorteil von Ontologie ist die Fähigkeit Schlussfolgerungen aus dem formalisierten Wissen ziehen zu können. Die Wissensbasis strukturiert und kategorisiert die Informationen aus der Datenbank. formale Spezifikation einer gemeinsamen Konzeptualisierung (Begriffsbildung). Beziehungen und Regeln zur Verfügung. Ein Beispiel ist die Realisierung der Interoperabilität zwischen Datenprozessmodellen innerhalb von Computersystemen [Hepp/Moor 2008]. um von Maschinen gelesen werden zu können. z. Wie oben schon erwähnt.. Dies liegt an der Fähigkeit der Ontologie die Interoperabilität zwischen mehreren Repräsentationen der Realität herzustellen. Eine Ontologie soll mit Konzepten die Welt beschreiben.B. Konsens über diese Konzepte herrschen.13 - vom Seienden“ bedeutet [Geisler 2009]. enthält das Data Enrichment eine Wissensbasis. 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. Das Data Enrichment entscheidet anhand der . Die Anforderungen. die eine Ontologie erfüllen muss. 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 auf dem Konsens einer Gruppe von Personen. beruhen.” Also beschreibt eine Ontologie einen Teil der Realität. Das durch die Ontologie ausgedrückte Wissen soll explizit angegeben sein.” Entsprechend dieser Definition interpretiert [Studer 1999] die Ontologie auf folgende Weise: “Eine Ontologie stellt eine Sammlung von Konzepten. Seit zwanzig Jahren gewinnt die Ontologie in der Informatik an Bedeutung. Ein konkretes Objekt. um Komplexität gering zu halten.14 - Schlussfolgerungen aus der Ontologie. Klassen Als erstes werden bei der Erstellung einer Ontologie Konzepte (auch als Klassen bezeichnet) und deren Hierarchie festgelegt.3. das mit einem Konzept beschrieben ist.. Abbildung 2–3 veranschaulicht mögliche Klassen und deren Beziehungen in einer Bier-Ontologie. Pilsner und Bock sind Unterklassen von ihr. Es wird entschieden welche Objekte in der Wissensbasis abgebildet werden sollen und welche Terme dafür benutzt werden. Es sollen nur für den Kontext sinnvolle Objekte abgebildet werden. Wichtig ist dabei auch die Subsumptionsbeziehung zwischen Klassen von Objekten [Stuckenschmidt 2009]. Relationen zwischen den Begriffen.1 Bestandteile einer Ontologie Eine Ontologie besteht nach [Wichmann 2007] aus drei Teilen: − − − Konzepte (Klassen). 2. Die Objekte mit den relevanten gemeinsamen Eigenschaften bilden eine Kategorie. Begriffen. Außerdem besitzt Pilsner ein Individuum namens Jever. Regeln über die Relationen und Begriffe. Diese Begriffe werden im Folgenden kurz erläutert. Beim Festlegen von Kategorien werden Objekte nach Gemeinsamkeiten unterteilt. um fehlende Daten zu erzeugen. ob die Kopplung von Simulationen erfolgreich ist. Als Subsumption werden die Teilmengenbeziehungen bezeichnet. Dabei ist die Klasse Beer eine Oberklasse von der BottomFermentedBeer und die Klassen Lager. wird als Individuum bezeichnet. oder ob Transformationen ausgeführt werden müssen. . Die Art der Relation wird entsprechend dem Kontext bestimmt. Die Relationen verknüpfen verschiedene Objektklassen miteinander. dass sie eine hierarchische Einstufung (Teilmengebeziehung) ausdrücken. werden die Relationen (auch Beziehungen genannt) zwischen den Klassen identifiziert. Beziehungen werden so gewählt. 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.15 - Abbildung 2–3: Beispiel für Ontologieklassen und Individuen Relationen Nachdem die Klassenhierarchie festgelegt ist.. [Voss 2003] hält folgende Relationsarten sinnvoll: Hierarchische Relationen generische Relation Instanzrelation (Klasse/Instanz) Vererbungsrelation (Ober/Unterklasse) partitive Relation (Ganzes/Teile) . . Die Abbildung 2–4 zeigt Einordnung und Zusammenhang der einzelnen Sprachfamilien auf. Ontologiesprachen ermöglichen Teile der Realität entsprechend einem bestimmten Kontext zu formalisieren und logisch zu beschreiben. Weiter in diesem Kapitel werden Ontologiesprachen aus Abbildung 2–4 näher betrachtet. die in einer Domäne ohne Beweis immer gültig sind. Antynomie Assoziationsbeziehungen Regeln Logische Aussagen über Konzepte und Relationen werden als Regeln bezeichnet. die den Wertebereich einer bestimmten Eigenschaft einschränkt.3.2 Ontologiesprachen Ontologien werden mit Ontologiesprachen modelliert.3. Unter Regeln befinden sich beispielsweise die Axiome.16 - - Eigenschaftsrelation Ordnungsrelation Koordinative Beziehungen Synonymien. 2. Mehr zu der OWL in dem Kapitel 2.. Diese Sprache wird bei der Entwicklung von Ontologie für die Simulationsplattform benutzt.3. [Stuckenschmidt 2009] beschreibt einen Einsatz sogenannter „Closure-Axiome“. die zur Entstehung der Web Ontology Language (OWL) beigetragen haben. Im Fokus dieser Abbildung steht die Ontologiesprache OWL. ist das Resource Description Framework (RDF).. die als domain bzw.h. Prädikat. Objekt) dargestellt Stuckenschmidt 2009. Das bedeutet. OIL . Binäre Relationen werden im RDF in Form eines Tripels (Subjekt. müssen der Klasse angehören. Ressourcen können hierbei Objekte. RDF Ein einfaches Datenmodell zur Repräsentation von Wissen im Internet. RDFS basiert auf dem Modellierungsprimitiven des RDFAnsatzes [Kuhnt 2003]. RDFS hat Möglichkeit den Ursprungsbereich (domain) und Bildbereich (range) einer Objekteigenschaft zu beschränken. RDFS RDFS (Resource Description Framework Schema) ist eine Weiterentwicklung der Repräsentationssprache RDF. d. die diese Objekteigenschaft verknüpft. das der Ontologiesprachen vorangegangen ist. die mit RDF formuliert wurden. Mittels der Aussagen. Klassen.17 - 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. dass die Individuen. Die zentrale Idee von RDF besteht darin binäre Relationen zwischen eindeutig bezeichneten Ressourcen zu beschreiben. Als Nächste Sprache wird die Ontologiesprache RDF vorgestellt. range vordefiniert ist. Relationen oder konkrete Werte bezeichnen. können mit RDFS Klassen und Properties definiert und Vererbungshierarchien für Klassen und Eigenschaften erzeugt werden. 18 - OIL bedeutet “Ontology Inference Layer” oder “Ontology Interchange Language”. in natürlichsprachigen Sätzen. Sie wurde im Februar 2004 vom W3C standardisiert und empfohlen [Hitzler 2008].. DAML DAML steht für „DARPA Agent Markup Language“ und ist ebenfalls eine Erweiterung von RDFS. z.3 Web Ontology Language Die Web Ontology Language (OWL) ist eine Ontologiesprache. DAML ist die amerikanische Variante von OIL [Wichmann 2007]. 2. B. wie der deskriptiven Logik und den W3C Standards XML und RDF beeinflusst [Wichmann 2007]. so können mit OWL-Konzepte einer beliebigen Domäne sowie deren Beziehungen zueinander formal so beschrieben werden. je nach Anforderungen von Anwender [Hitzler 2008]. DAML & OIL DAML & OIL ist eine Ontologiesprache. Die Entwicklung von OIL wurde von framebasierten Systemen.3. Dabei ist die OWL Lite eine echte Teilsprache von OWL DL und OWL DL ist ihrerseits eine echte Teilsprache von OWL Full vgl. sodass insbesondere auch komplexeste Zusammenhänge. Das Zusammenfügen wurde aufgrund der ähnlichen Zielsetzung veranlasst. Die Teilsprachen sind die Folgenden: OWL Full. Diese Sprache ist eine Erweiterung von RDFS und wurde in Europa entwickelt. die auf der Prädikatenlogik basiert. dass deren Bedeutung auch für Maschinen (Software) verarbeitbar („verstehbar“) ist. OWL Lite. die aus dem Zusammenfügen von DAML und OIL hervorgegangen ist. DAML&OIL ist weitaus ausdruckstärkere als die einzelnen Teilsprachen [Wichmann 2007]. hinreichend genau modelliert werden können” OWL ist in drei Teilsprachen unterteilt. Dabei geht OWL weit über die Ausdruckmöglichkeiten von RDFS hinaus. OWL DL. Auf die einzelnen Teilsprachen wird im Folgenden im Detail eingegangen. Die Teilsprachen unterscheiden sich in der Ausdrucksstärke. . [Geisler 2009] schreibt über OWL folgendes: “Wie auch mit RDFS. DAML ist eine ausdruckstärkere Ontologiesprache und wurde entwickelt um den Anforderungen des Semantik Web nachzukommen. Abbildung 2–5. Die OWL baut auf RDF und RDFS auf. Symmetrie und Umkehrung [Fensel 2007]. Kardinalitätsrestriktion und Aufzählung [Fensel 2007]. . Sie unterstützt die Klassifikationshierarchien mit Relationen wie bei RDFS und erlaubt einfache Restriktionen wie beispielsweise für den lokalen Range-Bereich. Diese OWL-Teilsprache stellt die maximale Ausdrucksmächtigkeit zur Verfügung und wird von aktuellen Softwarewerkzeugen fast vollständig unterstützt[Hitzler 2008]. OWL Full Die OWL Full enthält als einzige OWL-Teilsprache das komplettes RDF-Schema (RDFS). Zu den einfachen Restriktionen zählt auch die Einschränkung der Zahlenkardinalität. OWL DL erlaubt volle Unterstützung für Negation. die die Entscheidungsfähigkeit einer Beschreibungslogik übersteigen.. die nur die Werte 0 und 1 erlaubt. Disjunktion. OWL DL DL steht für Description Logic und drückt die Ähnlichkeit von OWL DL zur Beschreibungslogik SHOIN aus. Die OWL DL bleibt bei der maximalen Ausdrucksmächtigkeit entscheidbar und lässt vollständige und korrekte Inferenz mit der Komplexität NExpTime. daher ist OWL Full unentscheidbar und verliert das volle Schlussfolgerungsvermögen. OWL Lite unterstützt ebenfalls verschiedene Eigenschaften wie zum Beispiel Transitivität. OWL Lite ist entscheidbar und hat ExpTime Komplexität [Hitzler 2008].19 - Abbildung 2–5: OWL Teilsprachen [Wichmann 2007] OWL Lite OWL Lite ist die OWL-Teilsprache mit der geringsten Ausdrucksmächtigkeit. Die Ausdrucksmächtigkeit von OWL Full ermöglicht Aussagen. In diesem Fall werden Konzepte Beer. wird das Konstrukt rdfs:subClassOf benutzt.3.20 - 2. Bei der ersten Variante a wird BottomFermentedBeer als ein Unterkonzept von Beer definiert. Konzepte Konzepte (Klassen) werden in OWL durch owl:Class definiert. In diesem Fall wird das Schlüsselwort rdf:about benutzt. wie eine Teilmengenbeziehung in OWL definiert werden kann.1 Funktionsweise von OWL In diesem Abschnitt wird ein Überblick über die grundlegenden Sprachelemente der OWL gegeben. BottomFermentedBeer und Pilsner eingeführt. indem das Schlüsselwort rdf:resource verwendet wird.3. Dabei stehen zwei Varianten zur Verfügung. Um die Teilmengenbeziehung auszudrücken. . Mit den Schlüsselwörtern rdf:resource und rdf:about kann innerhalb einer Ontologie auf die Konzepte verwiesen werden.. Die Klassendefinition wird in Abbildung 2–6 am Beispiel einer Bier-Ontologie gezeigt. Bei der zweiten Variante b wird dem Konzept BottomFermentedBeer das Konzept Pilsner als Unterkonzept zugeordnet. Abbildung 2–6: Definition von Konzepten in OWL Abbildung 2–7 zeigt. owl:Thing ist hingegen das allgemeinste Konzept. Das Konzept owl:Nothing wird beispielsweise bei der Überprüfung von Klassenkonsistenz benutzt. das alles enthält. Individuen Individuen können als Instanzen von Konzepten definiert werden. Dabei wird eine Klasse inkonsistent genannt. das die leere Menge bezeichnet und ein Unterkonzept aller Konzepte ist. Dies geschieht durch das Konstrukt rdfs:label. was auf die zusätzliche Sprachanmerkung (Language) hindeutet.. Als Beispiel dafür wird in Abbildung 2–8 die Deklaration des Individuums Jever vorgestellt. In diesem Beispiel wird das Schlüsselwort xml:lang verwendet. In OWL existieren zwei vordefinierten Konzepte. Jedes Individuum muss mindestens einem Konzept angehören. somit wird es mindestens dem Konzept ows:Thing zugeordnet. nämlich owl:Thing und owl:Nothing. das dem Konzept Pilsner angehört. wenn sie äquivalent zu owl:Nothing ist. Die Konsistenzüberprüfung hilft Modellierungsfehler aufzuspüren. wie bei OWL Anmerkungen definiert werden können.21 - Abbildung 2–7: Definition von Unterkonzepten und Anmerkungen in OWL Außer Teilmengenbeziehungen wird in Abbildung 2–7 gezeigt. Abbildung 2–8: Definition von Individuen in OWL . Das Konzept owl:Nothing ist ein leeres Konzept. - 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. 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. 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. 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. Abbildung 2–12: Definition von konkreten Relationen in OWL In dem nächsten 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 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. zu dem das Attribut zugehörig ist. dementsprechend heißt die Tabelle für Zellen „cell“. Die unbekannten Parameter sind beispielsweise Verschiebungen an den Knoten. Dieser Vorgang wird Diskretisierung genannt. die in der Plattform Verwendung finden. Außer Wertetabellen existiert eine Tabelle namens „simulationstep“. die von den Knoten und Kanten gebildet werden. das die Entität bezeichnet. Die Elemente werden in dieser Arbeit auch als Zellen bezeichnet. der gerade berechnet wird und auf den sich die Daten beziehen. welches im Zuge der virtuellen Produkt. benötigen geometrischen Informationen über ein Bauteil. mittels dem die unbekannten Parameter bestimmt werden können. Die Vernetzung besteht aus geometrischen Elementen wie beispielsweise Tetraedern. Hexaedern oder Pentaedern. Diese Informationen werden bei der Berechnung mit der Finite-Elemente-Methode (FEM) verwendet. Dabei entsteht ein Netz von Elementen..” Bei der FEM wird ein Bauteil in Elemente aufgeteilt. Die Namen der Attributetabellen fangen mit dem Wort an. die in dieser Arbeit betrachtet werden. Zellen und deren Attribute. [Klein 2010] beschreibt FEM in Verbindung mit CAD als: “[…] ein wichtiges Basisverfahren. die Knoten enthält. Die FEM ist ein numerisches Verfahren zur Lösung von Differenzialgleichungen. So wird der Name für die Datenbanktabelle. Diese Informationen werden von der Simulationsplattform automatisch bestimmt und sind für diese Arbeit nicht relevant. deren Anzahl endlich ist. für Float-Attribute mit „cellattributefloatvalue“ oder Double-Attribute mit „cellattributedoublevalue“ bezeichnet. die diese Informationen charakterisieren. . Aus diesem Grund werden in der Datenbankstruktur die entsprechenden Schlüsselwörter benutzt. die das Bauteil imitiert. Darüber hinaus wird ein Gleichungssystem aufgestellt. mit dem englischen Wort „node“ bezeichnet.und Prozessentwicklung immer stärker angewandt wird. mit „cellattributeintvalue“. Die wichtigsten geometrischen Daten. Abbildung 3–1 fasst die Darstellung von Knotenattributen in der Datenstruktur zusammen. So wird der Name für Tabellen in denen die Integer-Attribute einer Zelle gespeichert werden.25 - Die Berechnungen von Simulationen. Diese enthält Informationen über den Simulationsschritt. Mit Hilfe von diesen Parametern werden dann die physikalischen Eigenschaften vom Bauteil berechnet und somit das Verhalten simuliert [Müller/Groth]. sind Knoten. die zurzeit in der Datenstruktur des Integrationssystems abgebildet sind.B. dargestellt. enthalten.26 - Abbildung 3–1: Tabellennamen am Beispiel der Knotentabellen Es bilden sich Tabellengruppen. die durch ihr Präfix unterschieden werden können. Es sind. aber auch Tabellengruppen für Geometrien (geometry) und Prozesse (process). Geometrien. Diese Tabelle heißt „process“. Tabellengruppen für geometrische Objekte und deren Attribute Knoten (node) und Zellen (cell). 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. 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. In dem Kapitel 3. die ein Bauteil entsprechend der zeitlichen Veränderung beschreiben.3 wird die Identifikation von Objekten näher beschrieben.1. Ein Prozess kann verschiedene Geometrien z. Die entsprechende Tabelle trägt den Namen „geometry“. Das gleiche gilt auch für die Attribute. . wie oben erwähnt. In der Abbildung 3–2 sind die Tabellen. die für die richtige Zuordnung verschiedener Daten verwendet werden. Diese Tabellen enthalten Mapping-Informationen über verschiedene Datensätze. in denen die zentralen Entitäten einer FEMBerechnung abgebildet werden können. Wie weiter oben bereits erwähnt existieren in der Datenbank Tabellen. .. Als Beispieltabelle für Stammdaten wird die Tabelle 3-1 vorgestellt.27 - Abbildung 3–2: Datenbankrelationen 3.1.2 Stammdaten Bis jetzt wurden die Tabellen beschrieben. die Stammdaten enthalten. Diese Stammdaten sind formatspezifische Bezeichnungen für verschiedene Datensätze. und haben besondere Namen. die mit dem Präfix „dat_“ ausgezeichnet sind. Dem in dieser Arbeit betrachteten UNV-Format ist der Identifikator „9“ und der Name „universal“ zugewiesen. aufgelistet.28 - Simulation_ID 1 2 3 4 … 9 Name larstran abaqus_odb vtk casts … universal Filter . 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 In der Plattform integriert sind. Unterschiedliche Datenformate benutzen verschiedene Strukturen und Bezeichnungen für ihre Daten.*\. beispielsweise bedeutet die Bezeichnung „3D8“.*\. Tabelle 3-1) mit dem Zellentype 115 (Spalte „SimCelltype“) acht .*\. dass die Zelle dreidimensional ist und acht Knoten enthält.. Die Spalte „CellType“ bezeichnet die Art einer Zelle.*\. dass eine Zelle aus dem UNV-Format („Simulation_ID“ = 9. Alle kommenden Zellelemente werden entsprechend diesem Schema gespeichert.odb . vgl. Das Beispiel für die plattformspezifische Darstellung von verschiedenen Zelltypen wird in der Tabelle 3-2 gezeigt.vtk .unv“ entspricht der Endung einer UNV-Datei.*\. Die Daten müssen dementsprechend übersetzt werden. die Informationen über Zellen von verschiedenen Datenformaten. Diese Tabelle heißt „dat_simulation“. Die Zelldarstellungen aller in der Integrationsplattform bis jetzt verwendeten Formate werden in dieser Tabelle gespeichert.unv Tabelle 3-1: Beispiel der „dat_simulation“ In der Tabelle 3-1 werden Datenformate. Dies verhindert eine direkte Übernahme der Daten aus einem Format in das andere. Aus dieser Tabelle wird beispielsweise entnommen.vtk … . Der Identifikator „CellType_ID“ ist eine plattformspezifische Nummerierung von Zelltypen.*\. Die Spalte „Num_of_Nodes“ enthält die Anzahl von Knoten in der entsprechenden Zelle. Der Filter „.pep . wie der aktuelle Datensatz gespeichert werden soll. Geometry_ID legt die Zugehörigkeit der Zelle einer Geometrie fest. dass Zelltype 115 aus dem UNV_Format als Identifikator „SimCellType_ID“ den Wert 54 hat.1. CellType_ID bestimmt die Art der Zelle.29 - Knoten umfasst (Spalte Num_of_Nodes) und unter der Identitätsnummer (SimCellType_ID = 54) zu finden ist (markierte Zeile). Ein Fragment dieser Mapping-Tabelle ist in der Tabelle 3-4 abgebildet. Diesem Wert wird über die dat_celltypemapping-Tabelle der Wert 6 aus der Spalte „CellType_ID“ (Tabelle 3-4. Aus der Tabelle 3-2 (rosa markiert) wird entnommen. Zum Beispiel zeigt Tabelle 3-5 die Speicherung einer Zelle in der Datenbank.. 3. Analog kann der plattformspezifische CellType mit Hilfe der Tabelle „dat_celltypemapping“ in seine äquivalente Darstellung im kanonischen Datenmodell überführt werden. 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 Überführung der Zelldaten zwischen den verschiedenen Datenformaten stattfinden kann. dass der Identifikator „CellType_ID“ mit dem Wert 6 dem plattformspezifischen Zelltype 3D8 entspricht. markiert) zugewiesen.3 Aufbau der Datensatztabellen Die Tabellenstruktur legt fest. CellTypeMapping_ID 1 2 … 41 CellType_ID 4 4 … 6 SimCellType_ID 1 2 … 54 Tabelle 3-4: Mapping-Tabelle für die Zelltypen namens „dat_celltypemapping“ Das obige Beispiel in Tabelle 3-3 zeigt. Attribute NodeOrder enthält die . müssen die Tabelle 3-2 und Tabelle 3-3 zusammen verknüpft werden. Das Attribut Cell_ID weißt jeder Zelle eine Identifikationsnummer zu. Diese Verknüpfung wird in Tabelle „dat_celltypemapping“ realisiert. 5.1.6. Dieser Eintrag wird im UNV-Format durch „physical property table number“ ausgezeichnet. die alle Materialeigenschaften enthält.7 9.. Aus dieser Tabelle wird deutlich. Die Tabelle 3-6 zeigt die Materialtabelle.8.10.15.30 - Knoten.12 13.5.8.7.6. das den Namen „MATERIAL1“ trägt und „Mat_ID“=1 in der Tabelle 3-6 (Zeile 1) hat.11.4 Materialdarstellung in der Datenbank Nachfolgend wird die Darstellung von Materialeigenschaften im UNV-Format beschrieben. um eben diese Strukturen erfassen zu können.3. Die Tabelle „material“ enthält die Namen von dem Material und deren eindeutige Zuordnung zu der entsprechenden Geometrie. Surrogate_ID 1 2 3 … Geometriy_ID 1 1 1 … Cell_ID 1 2 3 … NodeOrder 1. Die Datenbank kann diese Struktur nicht direkt erfassen und ein Teil der vorliegenden Arbeit besteht in der Erweiterung der Datenbank.9 … CellType_ID 6 6 6 … Tabelle 3-5: Datenbanktabelle „cell“ 3. Der Materialeigenschaftseintrag wird als Geometrieeigenschaft definiert. Für diese Eigenschaften wurde die Tabelle 3-7 „material_property“ erstellt.4. dass beispielsweise die Temperatureigenschaft „temperatur“ (Zeile 1) mit dem „AttributeType_ID“=1 dem Material mit dem „Mat_Number“=1 gehört. die eine Zelle umschließt. 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. . Dabei werden Knoten als Folge von Knotenidentitätsnummern getrennt durch ein Komma dargestellt. so dass die Speicherung und Weiterverwendung der Materialeigenschaften des UNV-Formats möglich wird.6.10.16. Ein Eintrag im Zelldatensatz verweist auf eine Tabelle. Die Datenbank wird um die Tabellen „material“ und „material_property“ und „doublepropertyvalue“ erweitert.2.5.14. auch Universal File Format (UFF) genannt.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“.1 Tabelle für die Werte von Materialeigenschaften „doublepropertyvalue“ UNV-Format Übersicht Das UNV-Format.. gespeichert. 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. Diese Tabelle wird in der Tabelle 3-8 präsentiert.2.2 3.28999 1234567 Position 0 0 0 0 Tabelle 3-8: 3. falls der Wert den Type double hat. SDRC als Teil des Unternehmens Electronic Data Systems (EDS) unterstützt und verwendet weiterhin das UNV-Format als Teil ihrer CAE-Software. Eine UNV-Datei stellt eine Konkatenation von solchen Formaten dar. wurde ursprünglich von der Structural Dynamics Research Corporation (SDRC) in den späten 1960er und frühen 1970er Jahren entwickelt [UNV-SDRC].234 0. Jedes Format hat seine eigene Struktur und erfasst Informationen über einen bestimmten Datensatz. . Die Dateien können zum Speichern oder zur Übertragung der Informationen zwischen verschiedenen Computern verwendet werden. DoublePropertyValue_ID 1 2 3 4 MaterialProperty_ID 1 2 3 4 Value 20 0. Die Formate wurden ursprünglich als 80-Spalten-Format (card image) entwickelt und in ASCII geschrieben. x. Später werden diese ausführlicher betrachtet. Dabei steht das Minuszeichen in Spalte 5 und die Eins in Spalte 6. Für diese Arbeit sind aber nur Daten relevant. da sie das Dataset und damit die Syntax und Semantik der Daten. Zwischen diesen Begrenzungssymbolen stehen die Daten.2 Jede Syntax und Semantik UNV-Datei ist sequentiell aufgebaut. Ein Dataset beginnt und endet mit einem Begrenzungssymbol "-1". Die Datasets haben keine homogene Struktur. Es gibt ungefähr Eintausend verschiedene Datasets. die geometrische Eigenschaften sowie Materialeigenschaften beinhalten (vrgl.. Abbildung 3–3: Aufbaustruktur von einem Dataset Nach dem ersten Begrenzungssymbol ist die Nummer des Datasets angegeben. so dass jedes Dataset über eine eigene Syntax und Semantik verfügt. Eine UNV-Datei besteht aus den Informationsblöcken. Die Abbildung 3–4 zeigt einige Beispiele für sie. Kap.y). . die dem Dataset zugeordnet sind. Diese Nummer ist wichtig.32 - 3. Der Rest der Zeile bleibt leer. Diese Informationsblöcke beinhalten verschiedene Informationen über das zu berechnende Model und stellen die Basisstruktur von UNV-Dateien dar. die Datasets genannt werden [UNV-Online]. Abbildung 3–3 zeigt die Aufbaustruktur eines Informationsblocks. die nachfolgend beschrieben werden.2. festlegt. Es werden diejenigen Materialeigenschaften beschrieben und auch durch den Integrator eingelesen.3. Das Einlesen aller möglichen Eigenschaften ist im Rahmen dieser Arbeit nicht möglich. Jeder Knoten wird in zwei Zeilen beschrieben. Dies bedeutet. Abbildung 3–5 veranschaulicht die Knotendarstellung. Solche sind Datasets für Knoten und für Zellen (Elemente). . die den Knoten identifizieren.2.1 Knotendarstellung Knoten werden im UNV-Format durch das Dataset mit der Nummer 2411 festgelegt.33 - Abbildung 3–4: 3. dass für jedes Dataset eine andere Vorgehensweise für das Einlesen der Daten benötigt wird. das einige ausgewählte Materialdaten enthält. Anschließend wird auf das Dataset eingegangen.2. In der ersten Zeile stehen die Parameter. die für diese Arbeit relevant sind.. und in der zweiten Zeile die Koordinaten selbst. die geometrierelevanten Daten enthalten. 3. Im Folgenden werden zunächst die Datasets beschrieben.3 Beispiele für Datasets Datasetssyntax Wie oben erwähnt hat jedes Dataset im UNV-Format seine eigene Syntax. 34 - Abbildung 3–5: UNV-Dataset für Knotendarstellung Die Parameter aus der ersten Zeile sind folgende: Identitätsnummer (node label). der Zellidentifikator (fe descriptor id) (vgl. Die Parameter aus der ersten Zeile enthalten Informationen. material property table number. Jede Zelle wird. die die Zelle enthält. Zellidentifikator. repräsentiert durch die Knotenidentitätsnummer aus dem Dataset 2411.. physical property table number.2 Zellendarstellung Ein Dataset mit der Nummer 2412 enthält Informationen über Zellen. In der zweiten Zeile stehen die Knoten. export coordinate system number. 3. displacement coordinate system number und color. in zwei Zeilen beschrieben. Abbildung 3–6 illustriert die Darstellung der Zellen. Die „material property table number“ bezeichnet dabei die Tabelle der Materialeigenschaften. Zu diesen Informationen gehören: Identitätsnummer (element label). ebenso wie Knoten. Wichtig sind für diese Arbeit die Identitätsnummer. color und die Anzahl von Knoten. die die aktuelle Zelle spezifizieren. die in der Tabelle 3-7 abgebildet ist.2. Neben den Koordinaten sind nur die Identitätsnummern für diese Arbeit von Relevanz. „material property table number“ und die Anzahl von Knoten.Abbildung 3–4).3. Abbildung 3–6: UNV-Dataset für Zellendarstellung . Art der Variable und den Wert selbst. Eine Materialeigenschaft enthält einen Namen.3 UNV-Format. .35 - Abbildung 3–7: 3. Dieses Dataset wird für jedes Material neu geschrieben und besteht aus drei Teilen – Header. Body und Footer.B. die Art der Anwendung z. „FEM“ steht für Finite Elemente Methode und die Art der Berechnung.2. Der Footer . Einheit.3. Auf der Abbildung 3–8 wird das Dataset 1716 veranschaulicht. Der Header enthält Beschriftung zwischen den Trenndoppellinien. FE Descriptor Id definitions Materialdarstellung Materialeigenschaften werden in dem Dataset mit der Nummer 1716 bzw. Sie werden durch die Kommentarlinien getrennt. 1710 spezifiziert. Als Body sind die Materialeigenschaften selbst hintereinander aufgelistet. Am Ende des Headers zwischen den Trennlinien steht die Anzahl von Materialeigenschaften und deren Beschriftung „MATERIAL PROPERT(IES)“.enthält „DEFAULT MATERIAL PROPERTIES“. Danach stehen die Identitätsnummer und der Name des Materials.. .3 Darstellung der Materialeigenschaften UNV-Integrator In diesem Kapitel wird die Überführung von Daten. Die Abbildung 3–9 zeigt den PDIJob. . Wie bereits erwähnt. der für das Einlesen des UNV-Formats verwendet wird. Der Integrations-Job besteht aus einer Kette von Aktionen.36 - Abbildung 3–8: 3. oder wenn das korrekte Einlesen nicht möglich ist. repräsentiert im UNV-Format. die für ein korrektes Einlesen. erfolgt die Integration des UNV-Formats unter Verwendung des PDI. für eine aussagekräftige Fehlermeldung sorgen. in das kanonische Datenmodell der Simulationsplattform beschrieben. wird die Ausführung ebenfalls durch einen kontrollierten Fehler beendet. abgebrochen. die die Korrektheit der Daten überprüfen. Argumente besitzen keine Namen sondern werden durch ihre Position und ihren Wert beschrieben. die die Simulationsidentifikationsnummer abfragt. Falls die Variable nicht gesetzt ist oder Fehler aufweißt. die den Dateinamen bezeichnet. Die zweite Art von Informationen sind Parameter. wird „Check: File exists“ genannt. dabei spielt die Reihenfolge. Die Identifikationsnummer der Simulationen kann sich in der Datenbank ändern. wird die Ausführung mit dem Schritt „Abort job 1“. Als Nächstes wird die Existenz dieser Datei geprüft. ordnungsgemäß gesetzt ist. . Als Startwerte können zwei Arten von Informationen auftreten.37 - Abbildung 3–9: UNV-Integrator als PDI-Job Abhängig von der Simulation kann ein Konverter verschiedene Funktionalitäten haben. Falls die Datei nicht existiert. Der Schritt. Anschließend werden in der Transformation „GetArguments“ die Startwerte des Jobs ausgelesen. bevor der eigentliche Einleseprozess gestartet wird. Ein Teil der Grundstruktur sind die Funktionen. keine Rolle. Eine Art sind Argumente. Auf der Abbildung 3–9 folgt diese Überprüfung sofort nach dem Start und wird als „Check: Filename“ bezeichnet. der die entsprechende Meldung wiedergibt. Als Standardargumente werden in der Transformation „GetArguments“ die Informationen zur Datenbankverbindung ausgelesen. Anschließend wird im Job die Transformation „GetSimulation_ID“ ausgeführt. Zu diesen Funktionen gehört unter anderen die Überprüfung ob die Variable (FILENAME). Jedoch besitzt jeder Konverter eine Grundstruktur. Parameter besitzen im Vergleich zu den Argumenten einen Namen. dem ein Wert zugewiesen wird. die als Präprozessor bezeichnet werden können. Das sind Funktionen.. in der die Parameter angegeben werden. deswegen muss sie bei jedem Prozess abgerufen werden. der dies realisiert. muss die Geometrie bestimmt werden.2. Kap.2) gesucht. Unter anderem zeigt die Tabelle. Aus der Spalte „Name“ (grellgrün markiert) kann entnommen werden. Diese Präprozessorfunktionen sind bereits in der Simulationsplattform implementiert und verfügbar. In der Transformation „SetGeometry_ID“ wird die Geometrienummer von der Datenbank generiert und als Variable für eine spätere Nutzung zurückgegeben. . Da bei dem UNV-Format die Materialeigenschaft als Geometrieattribute behandelt wird (vgl. Dabei wird das UNV-spezifische Attribut mit Hilfe der Tabelle „dat_simattributetype“ auf die plattformspezifische Darstellung abgebildet. welche Attribute (in diesem Fall Materialeigenschaft) die aktuelle Geometrie enthält. müssen diese zuerst in der Datenbank angelegt werden.4). Das wird in dem Schritt „FindAttribute“ vollzogen. Die entsprechende Simulation ist in der Spalte „Simulation_ID“ eingetragen. Der Ausschnitt dieser Tabelle ist in der Tabelle 3-9 gezeigt. Nachdem die Geometrie bestimmt ist. wird zuerst nach den Blockbegrenzern „-1“ (vgl. 1 für das ungerade Vorkommen des Begrenzungssymbols annehmen. 3.38 - Bevor die Daten in die Datenbank geschrieben werden. In diesem Schritt werden die geometrischen Daten eingelesen und in die Datenbank geschrieben. Für das Einlesen des UNV-Formats wird die Zeile mit der „SimAttributeType_ID“=214 (blaugrün (o) markiert) als Mapping-Funktion benutzt.. Da die UNVDatei blockweise aufgebaut ist. zu der die Daten gehören. Dabei wird jede Zeile. In diesem Schritt wird spezifiziert. die in den Spalten fünf und sechs ein Begrenzungssymbol enthält. Damit wird der Anfang und das Ende eines Datasets markiert.3. 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 nächste Schritt im PDI-Job ist eine Transformation namens „UNVRead“. müssen die Geometrieattribute festgelegt werden. dass die plattformspezifische Bezeichnung der Materialeigenschaft in der Spalte „AttributeType_ID“ eingetragen und mit der Nummer „55“ besetzt ist (türkis markiert).1. welche Namen die verschiedenen Simulationen für die Materialeigenschaft benutzen. Diese Suche wird in der vorliegenden Transformation mit Hilfe von JavaScript durchgeführt. mit einem Bezeichner „BlockStart“ markiert und der Bezeichner wird den Wert 0 für das gerade bzw. Kap. Das passiert in den folgenden Schritten. In dem vorletzten Schritt werden die Daten nochmals bereinigt und anschließend in die Datenbanktabelle „node“ geschrieben.. Die zusätzlichen Markierungen. Mit Hilfe von Switch-Anweisung werden nur für die Simulationen benötigte Datasets weiter betrachtet. die nicht mehr gebraucht werden. die Knoten und Zellen beinhalten.3.1 Das Einlesen von Knoten Da die Beschreibung eines Knotens in einer UNV-Datei auf jeweils zwei Zeilen erfolgt (vgl. werden die beiden Zeilen zunächst zusammengefügt. . Die Abbildung 3–10 zeigt wie die Knoten aus dem UNV-Format in die Datenbank überführt werden. die neu gewonnene Informationen darstellen. wird mit dem Bezeichner „BlockType“ und dazugehörigen Nummer markiert. Die ganze Datei wird in Bereiche unterteilt. Alle anderen Informationen.3. Dabei werden die Koordinateneinträge getrennt erkannt und ausgeschrieben. was einer Tabelle ähnelt. So wird die ganze Datei der Reihe nach von Anfang bis zum Ende durchgelesen und markiert. Anhand dieser neuen Markierungen wird erkannt. Die nächste Phase ist einfach die Trennung der Datei. Weiter werden die Datasets. Auf demselben Weg werden andere Daten aus dem anderen Datenfeld (ehemalige Zeile 1) entnommen. werden als Spalten hinten hinzugefügt und sind jede Zeit zugreifbar. Außerdem werden die Knoten zu der aktuellen Geometrie hinzugefügt.2. werden anschließend verworfen. als ein regulärer Ausdruck durchgesucht. Da die Koordinatenwerte nicht immer in einer datenbankkonformen Form stehen.und Endbegrenzer des aktuellen Datasets befindet. Das widerspiegelt die ganze Arbeitsweise des PDI. müssen sie konvertiert werden. parallel untersucht. Damit enthält eine Zeile alle Informationen über einen Knoten.1). Kap. welche Daten die aktuelle Zeile beinhaltet. Danach wird das Datenfeld (ehemalige Zeile 2). Die übrig gebliebene Daten werden nicht mehr berücksichtigt und weggeworfen.39 - Parallel in demselben JavaScript wird die Nummer des Datasets bestimmt. Alles was sich zwischen dem Anfangs. 3. das unmittelbar die Koordinaten enthält. So wird es später klar zu welchem Dataset die Zeile gehört.3. 1. mittels eines regulären Ausdrucks.. Das zweite Datenfeld (ehemalige Zeile 2) besteht nur aus Knoten. und die benötigten Zuordnungsdaten ausgelesen (vgl. Kap. Dazu wird eine Anfrage an die Datenbank gestellt.3.3. Als nächstes wird die plattformspezifische Art (CellType_ID. In dieser Form werden die Knoten in die Datenbank geschrieben. . die Daten des ersten Datenfeldes extrahiert.2). Diese Daten werden in die datenbankkonforme Darstellung überführt werden (vgl. Tabelle 3-2) der Zelle ermittelt. Anschließend werden. 3. indem die Knoten zuerst extrahiert werden und anschließend die trennenden Leerzeichen durch Kommata ersetzt werden.1.3). Zu guter Letzt werden die Daten in den entsprechenden Datenbanktabellen gespeichert.40 - Abbildung 3–10: 3.2.3. vgl. die der aktuellen UNV-Zelle entspricht. Kap.3.2) (genau wie bei den Knoten) in die einzeilige Darstellung überführt. die die aktuelle Zelle enthält. Weiter wird jede Zelle der aktuellen Geometrie zugeordnet.2 Knotenüberführung in die Datenbank Das Einlesen von Zellen Anfangs werden Zellendaten (vgl. Die Überführung der Zellen in die Datenbank wird in der Abbildung 3–11 dargestellt. Kap. Ähnlich wie bei der vorhergegangenen Aktionen wird es in der Datei nach dem entsprechenden .3 Zellenüberführung in die Datenbank Einlesen von Materialnamen Als letztes werden in der PDI-Transformation „UNV_read“ die Materialnamen eingelesen..3.41 - Abbildung 3–11: 3. 42 - Dataset gesucht. Diese gewährleistet die eindeutige Zuweisung des Materials einer Zelle.. Wichtig ist dabei die Materialnummer die der „material property table number“ bei der Zellendarstellung entspricht. Die Materialnamen werden der entsprechenden Geometrie und dem entsprechenden Geometrieattribute zugeordnet. Die Abbildung 3–12 veranschaulicht diese Zuordnung. Der Materialname und die Materialnummer werden anschließend ermittelt und mit der aktuellen Geometrie verknüpft und in die Datenbank geschrieben. Abbildung 3–12: Speicherung der Materialnamen in die DB . 3). Nachdem das entsprechende Dataset gefunden ist. Diese . wird es auf die Namen der Materialeigenschaften durchgesucht.3.4 Einlesen von Materialeigenschaften Die letzte Transformation des UNV-Integrators heißt „UNVMatRead“ (Abbildung 3–9). Die Materialeigenschafsnamen werden mit den Namen aus der Tabelle 3-9 verglichen und dementsprechend zugeordnet (vgl. weil die Realisierung aller Materialeigenschaften den Rahmen dieser Arbeit sprengen würde.. Abbildung 3–13 stellt diese Überführung dar. Kap. Diese sind Elastizitätsmodul (Modulus of Elasticity). Abbildung 3–13: Es werden nur Überführung von Materialeigenschaften und deren Werten in die DB drei Materialeigenschaften realisiert.3.2. Poissonzahl (Poissons Ratio) und Schubmodul (Shear Modulus). 3. In dieser PDI-Transformation werden die Materialeigenschaften und deren Werte ausgelesen und in die Datenbank gespeichert.43 - 3. .4 UNV-Extraktor Der Extraktor (Abbildung 3–14) startet. mit der Überprüfung der Parameter. Diese wird als Parameter abgespeichert. muss die Ausführung gestoppt und ein Fehler ausgegeben werden. Der nächste Schritt heißt „Get_Geometryattribute“. Über diesen Parameter wird der Pfad der Name für die Ausgabedatei festgelegt. In dem Schritt „Get Simulation_ID“ wird die Nummer der Simulation ermittelt und als Parameter „SIMULATION_ID“ abgespeichert. die ausgeschrieben werden müssen. In dem Schritt „Nodes Output“ werden Knoten gemäß UNV-Format ausgeschrieben. . Abbildung 3–14: UNV-Extraktor als PDI-Job Mit dem Schritt „Get Arguments“ werden Standardargumente ausgelesen und als Parameter gespeichert. Dieser Attribute wird als Parameter „GEOMETRYATTRIBUTE_ID“ gespeichert. In dem Schritt „Cell Output“ werden die Zellen gemäß UNV-Format ausgeschrieben. Die Aktion „Check Filename“ prüft ob der Parameter „FILENAME“ richtig gesetzt ist.44 - Eigenschaften beschreiben wichtige Materialdaten. Der Schritt „Get Geometry_ID“ liefert die Geometrienummer. die auch durch die Verformung der Geometrie des Bauteils bestimmt werden. Anhand des Geometrieattributes werden Materialeigenschaften identifiziert. 3. wie auch Integrator. die die auszuschreibenden Informationen eindeutig zu identifizieren lässt. In diesem Schritt wird festgestellt ob die auszuschreibende Geometrie die Materialeigenschaft enthält. Falls dieser Parameter keinen Wert hat. ausgeschrieben.45 - In dem vorletzten Schritt „GetMaterial“ werden Materialnamen ausgeschrieben.. Beim letzten Schritt werden Materialeigenschaften und deren Werte. falls sie existieren. Damit wird die Extraktion abgeschlössen. . ob die benötigten Informationen aus den schon vorhandenen hergeleitet werden können. um zu bestimmen. Dabei muss Data Enrichment in der Lage sein die Eingabedaten zu erkennen. 4. . sowie seine Bestandteile erklärt. eine Datentransformation zu ermitteln. In den nachfolgenden Kapiteln werden die Wissensbasis und die zugrunde Ontologie liegende erläutert. wenn alle dazu notwendigen Informationen vorliegen. Kap.bei einer Simulation erzeugte Ergebnisse für die Berechnung der weiteren Simulationen verwendet werden. Falls das nicht der Fall ist.falls nötig .46 - 4. In der Wissensbasis wird die Struktur der Datenbank abgebildet. muss das Data Enrichment zum einen wissen. Das ist möglich bei auf Logik basierten Ontologien (vgl. muss das Data Enrichment in der Lage sein zu entscheiden. Anschließend werden die im Rahmen dieser Arbeit identifizierten und durchgeführten Anpassungen an dieser Komponente vorgestellt. muss Data Enrichment Schlüsse aus dem vorliegenden Wissen ziehen können. um welche Informationen es sich handelt. so dass die vorliegenden Daten in das Datenformat der Simulation überführt werden können. daher wird das Wissen in einer Wissensbasis abgebildet und in einer Ontologie formal repräsentiert. das die Arbeit mit OWL erleichtert.3). Als Anwendung. Um das zu erreichen. Die Simulationen können direkt gekoppelt werden.2 Wissensbasis Wissensbasis wird mit der Ontologiesprache OWL repräsentiert. die für eine erfolgreiche Kopplung notwendig sind [Schilberg 2010].. Datenvorbereitung In diesem Kapitel werden weitere Teile vom Dataintegrator betrachtet. 4. 2. welche Daten für die Ausführung der nächsten Simulation fehlen. Zuerst werden Funktionen und Ziele der Data Enrichment Komponente erläutert.1 Data Enrichment Die Aufgabe des Data Enrichments besteht darin. und zum anderen muss es in die Lage versetzt werden diese Informationen zu interpretieren. Dabei sollen . wird die OWL-Editor Protege benutzt. Um solche Entscheidungen treffen zu können. Object. Die oberste Klasse. Interface u. Als Beispiel werden Eigenschaften der Klasse Node dargestellt. Für die Klasse Node sind beispielsweise Klassen CellType. die eine Menge von Individuen enthalten. Außer Eigenschaften haben Klassen . nämlich Classes. Cell. Geometrie usw. OntologyConfiguration und Predicate.a.. Der Bereich Object Properties enthält Relationen. Weiter werden diejenigen Klassen aufgelistet. Geometry. Als Oberklasse (Superclasses) von Node ist die Klasse Dataset eingetragen. Die Datenwerte werden im Bereich Data Properties festgesetzt.47 - Das Wissen wird in drei Bereiche unterteilt. Classes Im Classes wird die Klassenhierarchie erstellt. Auf der Abbildung 4–1 wird der Ausschnitt aus der Klassenhierarchie dargestellt. wie in der OWL üblich ist. Dieses Konzept enthält als Unterklassen die Konzepte. die geometrischen Informationen darstellen. In dem Bereich Classes werden die Klassen modelliert. Zu diesen gehören beispielsweise Konzepte. Cell. Für jede Klasse werden einige Eigenschaften definiert. die disjunkt zu der beobachteten Klasse sind. Nodeset. Unit. Object Properties und Data Properties. als disjunkt eingetragen. Die Oberklasse Thing enthält als Unterklassen die Konzepte Application. Axiom. Unter diesen Konzepten sind Node. Wie auf der Abbildung ersichtlich sind die Klasse Geometry und zum Beispiel Klasse Node als Unterklasse von Dataset gleichwertig. ist Konzept Thing. Abbildung 4–1: Wissensbasisauschnitt für Klassenhierarchie Eine wichtige Unterklasse der Klasse Object ist das Konzept Dataset. Weiter werden diese Bereiche näher betrachtet. in der Wissensbasis abgebildet. . Beispielsweise wird ein Individuum der Klasse CellType (vgl. Die Abbildung 4–2 illustriert die inverse Verknüpfung zweier Individuen. was bedeutet. Dagegen werden die Individuen von Klassen. die dem Definitionsweise Objekteigenschaften erklärt.2. dafür ist die Ontologie nicht geeignet (vgl. Als Range wird der Wertebereich auf die Individuen der Klasse Node eingeschränkt. die später im Kapitel 4.2. von topObjectProperty hasParameter. dass die Individuen. Die geometrischen Informationen werden nicht in die Wissensbasis übertragen. Tabelle 3-2) in der Wissensbasis auf folgende Weise presäntiert: − CellType_3D8 − − Types: Annotations: CellType dbName „3D8“ Object Properties Object Properties auch Objekteigenschaften genannt verknüpfen die Classes miteinander.1 erläutert werden. auf die diese Objekteigenschaft sich bezieht. Kapitel 4. das bedeutet. Als konkrete Mitglieder einer Klasse werden Individuen definiert.. müssen der Klasse Node angehören. isCellOf. müssen der Klasse Geometry angehören. Die „Inverse Peoperties“ zeigt auf die inverse Objekteigenschaft zu der aktuellen. dass die Individuen.48 - Anmerkungen (annotations). Mit der „Super Properties“ wird die Oberklasse von der aktuellen Objekteigenschaft festgelegt. die die Stammdaten repräsentieren. − hasNode − − − − Domain: Range: Super Properties: Inverse Properties: Geometry Node topObjectProperty isNodeOf Die Domain beschränkt den Definitionsbereich auf die Individuen der Klasse Geometry. An Unterklassen Beispiel von hasCell.1). definiert. die Objekteigenschaft hasNode nutzen. In der Wissensbasis ist Objekteigenschaft hat als topObjectProperty beispielsweise hasNode wird als Oberklasse hasNode. wächst mit der Anzahl von Knoten exponentiell. 4. wie das funktioniert. Individuen. Reasoner ist Teil einer Ontologie. Die Zeit. Die Tabelle Tabelle 4-1 zeigt die zeitliche Entwicklung bei wachsender Anzahl von Knoten einer Geometrie. In der Simulationsplattform werden Annotations benutzt. um Klassifizierungsprozess zum Beispiel einer Geometrie mit Hilfe eines Reasoners duchzuführen.. Ontologiesysteme sind nicht für Bearbeitung großer Datenmenge wie beispielsweise Datenbanken spezialisiert. Objekteigenschaften. Zahl der Knoten 100 500 1000 2000 Benötigte Zeit 0. Datentypeigenschaften) mit den Datenbankelementen zu verknüpfen. Datentypeigenschaften erlauben nur als 1:1Beziehungen. sondern lediglich Anmerkungen zur Beschreibung anderer Ontologieelemente. . Am Beispiel von CellType wird gezeigt. die gebraucht wird.49 - Abbildung 4–2: Data Properties Inverse Objekteigenschaft (Tenbrock) Data Properties zu Deutsch Datentypeigenschaften verknüpfen Individuen mit Datenwerten wie Integer.2.5 sec 27 sec 3 min 28 sec 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. Strings oder Gleitkommazahlen. um die Ontologieelemente (Klassen. Annotations selbst sind keine logischen Elemente der Ontologie. der für die Ableitung neuen Wissens zuständig ist.1 Annotations In diesem Kapitel wird die Bedeutung von Annotations erklärt. Bei Unerfüllbarkeit werden entsprechende Aktionen gestartet. Ein Merkmal wird durch eine eigene Klasse dargestellt. 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 Merkmal hat zwei Parameter nämlich hasGeometryParameter und Dieses hasStartIndexParameter. Entsprechend der Annotations wird eine SQL-Anfrage an die Datenbank gestellt..50 - − CellType − − − Annotations: dbTable „dat_celltype“ dbIDColumn „CellType_ID“ dbNameColumn „CellType“ Dabei zeigt dbTable in welcher Datenbanktabelle sich der benötigte Datensatz befindet. Der erste Parameter besagt. dbIDColumn teilt mit. und können zur Definition mehrerer Merkmalen verwendet werden. Wenn alle Merkmale erfüllt sind. Abbildung 4–1). Diese Klasse wird als Unterklasse von Konzept Feature definiert (vgl.2. in welcher Spalte die eindeutigen IDs der Objekte stehen.2 Merkmale Ein Merkmal spiegelt den Datenzustand wider. wird auf diesen mittels dbNameColumn an die entsprechende Spalte verwiesen. Diese werden als Primärschlüssel verwendet. wird die nächste Simulation gestartet. dass es eine Geometrie und ein Individuum . Die Merkmale werden in der Ontologie definiert und auf Erfüllbarkeit getestet. die die bestehenden Daten anreichern. Diese müssen unter Objekteigenschaft hasParameter definiert sein. zum Beispiel Transformationen. mit der die benötigten Daten geholt werden. Ein Merkmal kann beliebig viele Parameter besitzen. Falls ein Objekt über einen Namen verfügt. 4. 3 wird Algorithmus zur Interfacebestimmung dargestellt.1. Im Kapitel 4. Im Kapitel 4. Diese Nummer ist von Type hasMinNodeIDValue und ist äquivalent der Nummer des Types hasStartIndexParameter des zweiten Parameters. Kap. Bis jetzt wurden die Flächen nicht in der Datenbank abgebildet (vgl. die notwendig sind.3. wie die Datenbank angepasst wurde. Diese Tabelle enthält fünf Spalten.51 - der Klasse SortedNodesGeomtry geben muss. die mit Hilfe von Knoten und Zellen dargestellt sind. so dass es eine bestimmte Nummer existiert. die die Position einer Fläche in einer Zelle markiert (vgl. Die Datenbankstruktur wird um Tabelle „interface“ erweitert. dass in der Geometrie die Knoten sortiert sind und der Knoten mit der kleinsten Nummer auch ein Startknoten sein muss. 4. Flächen werden (wie auch Zellen) als Folge von Knoten dargestellt. Die vierte Spalte nimmt die Identitätsnummer „Interface_ID“ der Fläche auf. Diese soll die Interfaces aufnehmen. um Ziele der Arbeit zu erreichen. Im folgenden Kapitel werden Änderungen am System erklärt. Die erste Spalte wird mit der eindeutigen Nummer „Surrogate_ID“ gefüllt. .3. Knoten markieren dabei die Eckpunkte einer Fläche und im vergleich zu den Zellen liegen auf einer Ebene. In der dritten Spalte wird die Nummer der Zelle „Zell_ID“ abgelegt.3.3. zu der die Fläche gehört.. Nun bei bestimmten Berechnungen wie beispielsweise Diskontinuitätenberechnung werden Informationen über Interfaces gebraucht und müssen bereitgestellt werden. Das bedeutet.3 Systemanpassung In diesem Teil werden die Veränderungen erläutert.1 wird erläutert. Schließlich wird in der letzten Spalte die Nummer „SurfaceNumber“ gespeichert. Die zweite Spalte speichert die Geometrienummer „Geometry_ID“. 4. Das Speichern der Flächen ist platzaufwändig und verkompliziert die Datenstruktur.1). außerdem können Flächen jede Zeit aus der Zelldarstellung ausgerechnet werden. Im Kapitel 4.2 wird die Erweiterung der Wissensbasis erklärt.1 Datenbankerweiterung Die Datenbank enthält geometrische Informationen. zu der das Interface gehört. Kap. 3. was die Darstellung von Flächen allgemein überflüssig macht. Außer Interface werden die Objekteigenschaften hasInterface und hasInterfaceParameter definiert. Außer diesen Objekteigenschaften wird noch eine Objekteigenschaft festgelegt. Sie wird definiert wie folgt: − Interface − − − − Annotations: dbTable „interface“ dbIDColumn „Interface_ID“ Superclasses: Disjoint classes: Dataset CellType.3..52 - 4. Die Datenbanktabelle „interface“ ist in der Tabelle 4-2 mit möglichen Anfangswerten dargestellt. Cell. Diese Definitionen von diesen Objekteigenschaften werden wie folgt in der Wissensbasis abgebildet: − hasInterface − − − − Domains: Ranges: Super properties: Inverse properties: Geometry Interface topObjectProperty isInterfaceOf − isInterfaceOf . Nodeset. Node. Die hasInterface ist als Unterklasse von topObjectProperty und hasInterfaceParameter als Unterklasse von hasParameter definiert. 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. Geometry.3). die invers zu der hasInterface ist. das die Existenz von Interfaces prüfen soll. usw. Cellset.2 Datenbanktabelle „interface“ Wissensbasiserweiterung Die Wissensbasis muss auf das Konzept Interface erweitert werden. nämlich die isInterfaceOf. Diese Klasse bekommt den Namen Interface und ist eine Unterklasse von Dataset.3. Unit. Die hasInterfaceParameter wird als Parameter bei dem Merkmal ExistsInterfaceFeature verwendet. Als erstes bildet der Algorithmus eine Liste mit allen Flächen (flae_index). Das Merkmal ExistsInterfaceFeature prüft für die HomatSimulation ob Interfaces. dass wenn diese Tabelle nicht leer ist. weil die Korrektheitsüberprüfung aller Interfaces so lange dauern würde wie die Berechnung von Interfaces selbst.3 In diesem Kapitel wird Algorithmus beschrieben. das von Dataanalalyser gebraucht wird. der als Transformation für die Interfaceberechnung verwendet wird. die einer Geometrie. und soll alle Flächen mit Knoten in einer festen Reihenfolge enthalten. in der Interface-Tabelle enthalten sind.. wie Flächen mit den Knoten aus einer Zelle gebildet werden und wird mit folgenden Graphiken verdeutlicht. Es wird angenommen. In . Die Konvention gibt vor. Vor der Berechnung einer Simulation überprüft das Dataanalyser den Datenzustand.angehören. die dabei gebraucht werden. Diese Liste wird gemäß einer Konvention erstellt.3. dann soll sie mit korrekten Daten gefüllt sein. dabei werden alle in der Wissensbasis existierenden Merkmale auf die Erfüllbarkeit getestet. 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. Diese Annahme wurde so getroffen.53 - − − − Annotations: Super properties: Inverse properties: dbForeignKey „Geometry_ID“ topObjectProperty hasInterface − hasInterfaceParameter − − Ranges: Super properties: Interface hasParameter Wie oben schon erwähnt wird in der Wissensbasis das Merkmal ExistsInterfaceFeature definiert. Fläche 4. Fläche 5. Fläche 3.54 - Abbildung 4–3 werden Volumenelemente (Hexaeder. Fläche 6. Die Flächennummer entspricht der SurfaceNumber aus der Tabelle 4-2. was in Abbildung 4–4 verdeutlicht wird (vgl. mit welchen Knoten die einzelnen Flächen markiert werden. Flächennummer 1. Pentaeder und Tetraeder) mit einer festen Knotenreihenfolge gezeigt. um eine Fläche zu identifizieren. Fläche 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 Flächen von Volumenelementen . Abbildung 4–3: Knotenreihenfolge bei Volumenelementen Die Tabelle Tabelle 4-3 legt fest. Fläche 2. Tabelle 3-5). Dabei bezeichnen die Tabelleneinträge die Positionen von Knoten in einer Auflistung. Diese Nummer wird bei der Simulation HOMAT verwendet.. Bei dem UNV-Integrator wird Knotenauflistung aus der Datei übernommen. Dabei werden die Flächen mit den gleichen Knoten als Interface und Flächen. die einzeln vorhanden sind. automatisch als Oberflächen gespeichert..55 - 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. . .56 - 5. Zusammenfassung Das Ziel der Arbeit war die Entwicklung und die Implementierung eines Wissenscompilers. der SGPLAN6 lieferten hierfür die besten Ergebnisse. . .............. 47 Inverse Objekteigenschaft (Tenbrock) .............. 20 Abbildung 2–7: Definition von Unterkonzepten und Anmerkungen in OWL........................................................................................................................................................................................................................................................................................................................................ 10 Abbildung 2–2: Interface vom PDI ................................................................................ 40 Zellenüberführung in die Datenbank ..................................................................................... 27 Aufbaustruktur von einem Dataset ............ 32 Beispiele für Datasets .......... 17 Abbildung 2–5: OWL Teilsprachen [Wichmann 2007] ............................................................................................................... 34 UNV-Format................ 26 Datenbankrelationen ......... 37 Knotenüberführung in die Datenbank ...........57 - 6................................ 15 Abbildung 2–4: Schichtung der Ontologiesprachen [Kuhnt 2003].... 49 ............................................ 21 Abbildung 2–9: Explizite Definition von Individuen in OWL . 44 Wissensbasisauschnitt für Klassenhierarchie ............................................................................................................................................... 33 UNV-Dataset für Knotendarstellung ............... 35 Darstellung der Materialeigenschaften .. 36 UNV-Integrator als PDI-Job..................... 22 Abbildung 2–12: Definition von konkreten Relationen in OWL............ 23 Abbildung 3–1: Abbildung 3–2: Abbildung 3–3: Abbildung 3–4: Abbildung 3–5: Abbildung 3–6: Abbildung 3–7: Abbildung 3–8: Abbildung 3–9: Abbildung 3–10: Abbildung 3–11: Abbildung 3–12: Abbildung 3–13: Abbildung 3–14: Abbildung 4–1: Abbildung 4–2: Tabellennamen am Beispiel der Knotentabellen ............................................................ 34 UNV-Dataset für Zellendarstellung................................................................................................................................................................. 42 Überführung von Materialeigenschaften und deren Werten in die DB43 UNV-Extraktor als PDI-Job .................................... FE Descriptor Id definitions ......... 12 Abbildung 2–3: Beispiel für Ontologieklassen und Individuen ......... Abbildungsverzeichnis Abbildung 1–1: Facharchitektur der Simulationsplattform [Reinhard 2011] .. 41 Speicherung der Materialnamen in die DB ....................................... 19 Abbildung 2–6: Definition von Konzepten in OWL. 21 Abbildung 2–8: 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 ................... 4 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 ..................................................................... ....................... 54 Abbildung 4–4: Knotenreihenfolge bei Volumenelementen ................ 55 ......................................58 - Abbildung 4–3: Knotenreihenfolge bei Volumenelementen ................... .......................................... 31 Tabelle 3-8: Tabelle für die Werte von Materialeigenschaften „doublepropertyvalue“...59 - 7............. 52 Tabelle 4-3: Topologie von Volumenelementen ...................................................................................................................................................................................................................................................... Tabellenverzeichnis Tabelle 3-1: Beispiel der „dat_simulation“.... 30 Tabelle 3-6: Tabelle „material“ ..... 31 Tabelle 3-9: Tabelle der Eigenschaften „dat_simattributetype“ ....... 38 Tabelle 4-1: Benötigte Zeit zur Klassifizierung (Tenbrock) ................................................................................................................. 29 Tabelle 3-5: Datenbanktabelle „cell“ ................................................................................................................................................... 54 ... 49 Tabelle 4-2: Datenbanktabelle „interface“ ............ 28 Tabelle 3-2: Ausschnitt aus der Tabelle „dat_celltype“ ... 29 Tabelle 3-4: Mapping-Tabelle für die Zelltypen namens „dat_celltypemapping“ .......................... 30 Tabelle 3-7: Tabelle „material_property“ ..................................................... 28 Tabelle 3-3: Ausschnitt aus der Tabelle „dat_simcelltype“ ............. Packt Publishing Ltd. Schneider: Implementierungskonzepte für Datenbanksysteme.2 Data Integration. 2000 Cristiani 2000 Elmasri 2002 Ramez Elmasri. J. Schilberg: Architektur eines Datenintegrators zur durchgängigen Kopplung von verteilten numerischen Simulationen. J. G. © 2002 Pearson Studium. Laschet: Toward integrative computational materials engigeering of steel components. publishing as ADDISON WESLEY LONGMAN. N..60 - 8. Roldan 2010 Maria Carina Roldan: Pentaho 3. (2010) Schilberg 2010 D. U.: An Introduction to Support Vector Machines and other kernel-based learning methods Cambridge Uniiversity Press. Leser 2007 Ulf Leser. Oracle und MySQL. © VDI Verlag GmbH Düsseldorf 2010 Schmitz 2011 G. Literatur Cristiani.verlag GmbH Riemer 2007 Petra Riemer. Cambridge.2007 dpunkt. © Springer-Verlag Berlin Heidelberg 2004 Yu 1995 King Chun Yu: Object-oriented File Translator for the MEMCAD System. Felix Naumann: Informationsintegration: Architekturen und Methoden zur Integration verteilter und heterogener Datenquellen. May 1995 . Sahwe-Taylor.. © German Academic Society for Production Engineering (WGP) 2011 Schneider 2004 Markus. Schmitz. Navathe: Grundlagenn von Datenbanksystemen. Massachusetts Institute of Technology. Prahl. Shamkant B. Elena Bauer: Datenbanksysteme: Theorie und Praxis mit SQL2003. © 2007 Pearson Studium. http://ol.2010 Klein 2010 Bernd Klein: FEM Grundlagen und Anwendungen der FiniteElemente-Methode im Maschinen. York Sure (2008): Ontology Management: Semantic Web.11. © 2009 entwickler. Schenk.press.04. LLC Geisler 2009 Matthias Geisler: Semantic Web schnell+kompakt. © Expert Verlag UNV-Online I-DEAS Online Help.edu/universal-file-formats-for-modal-analysistesting-1/. URL: http://www. PDI Pentaho Datta Integrator.2011.htm. ein Imprint der Software & Support Verlag GmbH. IFFWissenschaftstage.61 - Schilberg 2009 Schilberg Daniel. Hrsg.-18. 2009: 197-206. . 16. Müller/Groth Günter Müller. Testen und Betreiben technischer Systeme 6. 22. Aldo de Moor. © Vierweg+Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2010 Hepp/Moor 2008 Martin Hepp. and Business Applications.cadfamily. Magdeburg. Henning Klaus: Verkettung von Prozesssimulationen für die virtuelle Produktion.com/. In: Tagungsband "Digitales Engineering zum Planen.sdrl. Clemens Groth (2007): FEM für Praktiker – Band 1: Grundlagen.06..2011 UNV-SDRC http://www. Auflage 8. Fachtagung zur Virtual Reality" 12.com/i- deas/sdrchelp/lang/english/unv_ug/book. © 2008 Springer Science+Business Media. 11. Michael: Magdeburg: Fraunhofer-Institut für Fabrikbetrieb und automatisierung.pentaho. Juni 2009. v. Semantic Web Services. 23.uc. Pieter De Leenheer.und Fahrzeugbau. Gramatke Arno. Rudolf Reinhard. Holger Lausen. Dumitru Roman (2007): Enabling Semantic Web Services: The Web Service Modeling Ontologie. Sebastian Rudolph. Michael Stollberg. © Springer-Verlag Berlin Heidelberg 2009. Reinhard 2011 Tobias Meisen. Humboldt Universität zu Berlin. Kuhnt 2003 Markus Kuhnt: Ontologiesprachen im Kontext des Semantik Web. © 2007 VDM Verlag Dr. Werkzeuge. Markus Krötzsch. Sprachen. Wichmann 2007 Gabriele Wichmann: Entwurf Semantic Web: Entwicklung. Juan Trujillo (2003): Data Mapping Diagrams for Data Warehouse Design with UML. . Andreas Abecker. Stefan Decker (1999): InformatikMethoden für das Wissensmanagement. Sabina Jeschke (2011): A Framework for Adaptive Data Integration in Digital Production. © (2008) Springer-Verlag Berlin Heidelberg. © Springer-Verlag Berlin Heidelberg 2007. Technologien und Anwendungen. Institut AIFB Karlsruhe.. Universität Ulm 2003 Hitzler 2008 Pascal Hitzler. Fensel 2007 Dieter Fensel. Stuckenschmidt 2009 Heiner Stuckenschmidt: Ontologie: Konzepte. ICPR21 Vassiliadis 2003 Sergio Lujan-Mora. Müller. Voss 2003 Jakob Voss (2003): Modelierung von Ontologien. © Springer-Verlag Berlin Heidelberg 2003. Daniel Schilberg. Panos Vassiliadis. Jos de Bruijn.62 - Studer 1999 Rudi Studer. York Sure: Semantic Web: Grundlagen.