REXS: Grundstruktur und Datenmodell
Der Standard für den Datenaustausch im Getriebedesign
Nach der Einführung in Motivation und Zielsetzung von REXS im ersten Teil dieser Reihe widmet sich Teil 2 dem Kern des Standards: seiner Grundstruktur und dem zugrunde liegenden Datenmodell. REXS beschreibt Getriebe und deren Bauteile mithilfe von drei zentralen Elementen – Komponenten, Attribute und Relationen. Diese ermöglichen eine eindeutige, konsistente und toolübergreifende Abbildung von Getriebedaten in unterschiedlichen Detaillierungsgraden. Der Beitrag erläutert den Aufbau dieser Strukturelemente, zeigt deren Zusammenspiel und gibt einen Überblick über die unterstützten Dateiformate des Standards.
1. Überblick
Im ersten Beitrag haben wir uns mit der Motivation und Zielsetzung von REXS beschäftigt und festgestellt, warum REXS ideal ist, um rund um die Getriebe- und Maschinenelemente herum anfallende Daten strukturiert abzubilden. Außerdem haben wir festgestellt, warum die Designprinzipien von REXS den Standard gleichzeitig flexibel und robust halten.
In diesem zweiten Beitrag soll nun das Datenmodell von REXS detaillierter betrachtet werden. Wir schauen uns die wesentlichen drei Grundstrukturelemente „Komponente“, „Attribut“ und „Relation“ an und werden erkennen, warum diese bestens geeignet sind, um auf relativ generische Art und Weise ein Getriebe und seine darin enthaltenen Bauteile in unterschiedlichen Detaillierungsgraden zu beschreiben.
2. Komponenten
Wenn man jemanden auf der Straße fragen würde “Woraus besteht ein Getriebe?”, dann würden relativ schnell Worte Fallen wir “Zahnräder”, “Gehäuse” oder, wenn derjenige etwas technische Vorerfahrung mitbringt, “Wellen” und “Lager”. Und genau hier beginnt auch die Definition von Komponenten in REXS. REXS-Komponenten sind in der ersten Abstraktionsebene konkrete Maschinenelemente. Konkret existieren die folgenden Maschinenelemente als direkte Komponenten in REXS:
Abbildung 1: Eine Stirnrad-Komponente in REXS ohne Attribute
- Kegelrad
- Stirnrad
- Passfeder
- Gehäuse
- Zahnwelle
- Schmierstoff
- Planetenträger
- Lager (Wälzlager, Hydrodynamisches Radialgleitlager, Gleitlager)
- Welle
- Schnecke/Schneckenrad
Diese benannten Komponenten bieten bereits die Möglichkeit ein vollständiges Getriebe zu beschreiben. In Abbildung 1 ist einmal beispielhaft die REXS-Repräsentation eines Stirnrades dargestellt.
Viele der Komponenten können bereits selbst als Baugruppen verstanden werden. So besteht beispielsweise das Wälzlager wiederrum aus Ringen und Wälzkörpern. Daher werden in REXS sowohl die Maschinenelemente (also im Beispiel das Wälzlager) als auch die Bestandteile der Maschinenelemente (Wälzlagerring und Wälzkörper) einheitlich als Komponenten beschrieben.
Dieses flexible Verständnis einer Komponente ermöglicht auch den Einsatz von relativ abstrakten Komponenten wie beispielsweise einem Werkstoff oder einer Zahnradflanke.
Zum heutigen Tag (Stand Version 2.0.0) enthält REXS 108 unterschiedliche Komponenten.
3. Attribute
Abbildung 2: Eine mit Attributen beschriebene Stirnrad-Komponente in REXS
Komponenten sind in REXS zuallererst einmal nur „Container“, d.h. eine Komponente unterscheidet sich auf dieser Ebene nur durch die zugeordnete ID, dem zugeordneten Komponenten-Typ und dem optional verfügbaren Namen von einer anderen Komponente. Zur vollständigen Beschreibung von Maschinenelementen sind jedoch noch Eigenschaften dieser Maschinenelemente erforderlich. Diese Eigenschaften werden in REXS Attribute genannt und definieren die konkrete Ausgestaltung einer Komponente. So könnte das im vorherigen Abschnitt definierte Stirnrad wie folgt über Attribute genauer definiert werden (siehe Abbildung 2).
Die Attribute sind dabei einerseits durch den REXS-Standard jeweils bezogen auf die einzelnen Komponenten definiert können aber auch flexibel durch die im REXS-Standard enthaltenen Mechanismen um eigene Attribute erweitert werden.
Der REXS-Standard setzt außerdem voraus, dass nicht immer alle einer Komponente zugeordneten Attribute auch in der jeweiligen REXS-Datei definiert sein müssen. Fehlende Attribute muss das einlesende Programm dann entsprechend ignorieren oder, falls für die Berechnung/Auswertung/Visualisierung oder ähnliches erforderlich programmspezifische Defaultwerte festlegen oder vom Nutzer einfordern.
Das Zusammenspiel aus Komponenten und Attributen ist in Abbildung 3-links allgemein und in Abbildung 3-rechts am Beispiel einer Kegelradstufe dargestellt.
Abbildung 3: Zusammenhang zwischen Komponenten und Attributen sowie Attributwerten
4. Relationen
Um nun aus den einzelnen Komponenten ein Getriebe oder einzelne Baugruppen zusammen zu stellen sind als dritter Grundbaustein im REXS die Relationen erforderlich. Relationen beschreiben dabei ganz abstrakt, wie zwei Komponenten zueinander in Verbindung stehen. Diese Verbindung kann physisch sein, d.h. ein Stirnrad kann auf einer Welle montiert sein (Abbildung 4-rechts), sie kann aber auch logisch sein, beispielsweise zur Definition von Fertigungsschritten auf einer Zahnradflanke mit verschiedenen Werkzeugen.
Abbildung 4: Zusammenhang zwischen Relationen, Rollen und Komponenten
REXS unterscheidet zum jetzigen Zeitpunkt (Stand Version 2.0.0) zwischen 13 verschiedenen Relationen.
Grundsätzlich gilt: Wenn alle Komponenten einer möglichen Relation im Modell vorhanden sind, dann ist auch die entsprechende Relation zwingend erforderlich.
Anhand eines Beispiels wird das deutlicher: Wenn im Modell eine gear_unit (Getriebeeinheit) und ein gear_casing (Gehäuse) vorhanden sind, dann muss auch die assembly-Relation zwischen diesen Komponenten erstellt werden.
Anders ausgedrückt ist bei der Verwendung von REXS anzustreben, dass keine Komponente „frei im Raum schwebt“ sondern immer in irgendeiner Weise an die übrigen Komponenten angebunden wird.
Diese Anforderungen können noch strikter sein, wenn eine konkrete REXS sogenannten Modellierungsrichtlinien entsprechen soll – dazu aber in einem späteren Post.
5. Dateiformate
Abbildung 5: Beispiele für die Darstellung der obersten Hierarchiestufen “Komponenten und Attribute” und “Relationen”
Damit die REXS-Modelle nicht nur im Rechner, sondern auch im Austausch zwischen Teams funktionieren, gibt es sie in zwei gängigen „Sprachen“ – XML (Dateiendung „.rexs“) und JSON (Dateiendung „.rexsj“). Beide sagen dasselbe, nur in unterschiedlichem Dialekt. Die XML und JSON Struktur sind dabei gleichwertig und können über den REXS-Konverter ineinander konvertiert werden. In Abbildung 5 sind die oberste Hierarchiestufe die Komponenten und Attribute sowie die Relationen in beiden Datenstrukturen beispielhaft dargestellt.
Um neben der REXS-Modelldatei auch weitere zugehörige Daten (Dateien, Ordner) geordnet zu speichern kann eine ZIP-Datei („.rexsz“) verwendet werden. Diese enthält genau eine XML oder JSON REXS Modelldatei sowie ggfs. weitere Dateien oder Unterordner. Weitere Dateien können hierbei beispielsweise FE- und/oder CAD-Daten von Baugruppen, erweiterte Beschreibungen von Verzahnungen wie GDE oder das Klingelnberg-Neutraldaten-Format sein.
Eine REXS ZIP-Datei muss dabei zwingend die ZIP-Komprimierung verwenden und wenn Dateien oder Ordner im Modell einer REXS ZIP-Datei referenziert werden sind relative Pfade zu verwenden.
Weitere Details zur Referenzierung von Dateien kommen in einem separaten Blogpost bzw. sind hier nachzulesen: Datei- und Ordnerreferenzen.
6. Up-Next: Modellierung eines einfachen Antriebsstrangs
In diesem Beitrag haben wir die Grundstruktur und das flexible Datenmodell hinter REXS kennen gelernt. Hierbei galt es die drei wesentlichen Bestandteile, namentlich Komponenten, Attribute und Relationen und deren Einsatzzwecke zu verstehen. Außerdem haben wir uns einen Überblick über die Dateiformate, die in REXS unterstützt werden, verschafft.
Im nächsten Beitrag setzen wir all das Gelernte in Bewegung: Wir bauen gemeinsam einen einfachen Antriebsstrang – Schritt für Schritt in REXS modelliert.