16. Dez. 2025
Automatisierte Erstellung von AAS
Regelbasierte Konfiguration für maximale Flexibilität
Die Asset Administration Shell (AAS) gilt als zentraler Baustein für die Digitalisierung in der Industrie. Sie bietet eine standardisierte Implementierung des digitalen Zwillings und ermöglicht so die Interoperabilität in Industrie 4.0-Ökosystemen. Doch wie kann die Erstellung von AAS effizient und automatisiert gestaltet werden? In diesem Blogartikel geht es um die Weiterentwicklung unseres Eclipse Mnestix AAS-Generators.
1. Motivation
Die Einführung von AAS-basierten Systemen bietet enorme Chancen, aber auch Herausforderungen. Eine der größten Herausforderungen stellt das Überführen bestehender Daten in die AAS-Struktur da. In den meisten Anwendungsfällen liegen die relevanten Daten jedoch schon in gleichmäßigen Strukturen vor, wie beispielsweise ERP oder MES Systemen. Um diese Daten in das standardisierte, strukturierte und semantisch annotierte AAS Format zu überführen, benötigt es einen automatisierten Generator mit welchem sich diese Daten effizient, konsistent und fehlerarm überführen lassen.
2. Grundlagen der AAS
Die AAS besteht aus einem Header mit Identifikationsdaten und mehreren Submodellen, die verschiedene Aspekte eines Assets – von technischen Eigenschaften über Produktionsdaten bis hin zu Lebenszyklusinformationen – abbilden. Diese Submodelle werden aus verschiedenen SubmodelElements (SMEs) zusammengebaut. Mit sogenannten Qualifers können Meta-Informationen über Submodels SMEs dargestellt werden.
3. Generierung von Submodels in Eclipse Mnestix
In Eclipse Mnestix lassen sich im Bereich Templates & Blueprints aus verschiedenen standardisierten Templates sog. Blueprints erstellen. Bei den Templates handelt es sich um eine Auswahl standardisierter IDTA-Templates, wie beispielsweise das Nameplate oder die Bill Of Materials. Hat man sich für ein Template entschieden, kann man den daraus entstandenen Blueprint mit Mapping-Regeln anreichern. Diese Regeln definieren, wie die Eingabedaten aus einem JSON-Objekt in ein AAS-Submodel überführt werden sollen. Aus technischer Sicht sind Blueprints Submodels des kind „Template“, die mit Regeln angereichert werden.
Mit beliebig vieler solcher Blueprints und den Eingabedaten in einem JSON-Objekt, kann anschließend die AAS-Generierung per REST-API gestartet werden. In der Anfrage werden die IDs der Blueprints, die ID der Ziel-AAS und die eigentlichen Eingabedaten mitgegeben. Der AAS Generator erstellt die Submodelle, fügt sie der gewünschten AAS hinzu und speichert die Änderungen in einem ausgewählten AAS-Repository (z.B. Eclipse Basyx).
Alternativ kann auch direkt eine neue AAS erstellt werden, in der die generierten Submodelle gespeichert werden.
Die erstellten Submodelle können dann im Mnestix AAS Browser visualisiert werden.
Regeltypen
Die Regeln werden grundsätzlich in AAS-Qualifiers abgebildet. Es werden die folgenden Qualifier-Types für die verschiedenen Regeln definiert. :
- Pfadregeln: `SMT/CollectionMappingInfo`
- Listenregeln: `SMT/CollectionMappingInfo`
- Filterregeln: `SMT/FilterMappingInfo`
- Kardinalitätsregeln: `SMT/Cardinality`
Legende für die folgende Notation:
- [SM] Submodel (<Kind>)
- [SMC] SubmodelElementCollection
- [P] Property
- [MQ: <Pfad>] Template-Qualifier SMT/MappingInfo mit Pfadangabe
- [CMQ: <Pfad>] Template-Qualifier SMT/CollectionMappingInfo mit Pfadangabe
- [FMQ: <Bedingung>] Template-Qualifier SMT/FilterMappingInfo mit Bedingung
- [CQ: <Kardinalität>] Template-Qualifier SMT/Cardinality mit Kardinalität
- = <Wert> Statischer Wert
- (<Kind>) Art des Submodels (Template/Instance)
Pfadregeln
Mit Pfadregeln können simple Datentypen wie Strings oder Zahlen aus den Eingabedaten in ein Property-SME gemappt werden.
Eingabedaten:
Blueprint:
Instanz-Submodel:
Die Seriennummer wurde erfolgreich in das Submodel übernommen.
Listenregeln
Mit Listenregeln können Daten, die unterschiedlich oft aber immer gleich strukturiert vorkommen (z.B. Zeitreihendaten), in SME-Collections oder SME-Lists überführt werden.
Eingabedaten:
Blueprint:
Instanz-Submodel:
Es wurden zwei SMCs für die beiden Personen aus den Eingabedaten angelegt und mit den jeweiligen Werten befüllt.
Filterregeln
Mit Filterregeln kann für einzelne SMEs definiert werden, ob sie aus dem Blueprint in das erstellte Submodel übernommen werden. Diese Funktion ist besonders relevant für die sog. 150%-AASs, bei denen in der Type-AAS bewusst zu viele Informationen angelegt worden sind, die zur Instanziierung dann entfernt werden.
Dieser Regeltyp ist zum jetzigen Stand noch nicht in Eclipse Mnestix implementiert, kann jedoch in Zukunft in das bestehende System integriert werden.
Eingabedaten:
Blueprint:
Instanz-Submodel:
Da es sich bei den Eingangsdaten um ein elektrisches Fahrzeug handelt, wurde nur die Batterie-Info in das Submodel übernommen.
Kardinalitätsregeln
Es kann für jede der zuvor definierten Regeln zusätzlich festgelegt werden, ob das entsprechende SME optional oder verpflichtend ist. Fehlt ein verpflichtender Datensatz, bricht die Generierung ab. Fehlt ein optionaler Datensatz wird diese Regel einfach übersprungen.
Eingabedaten:
Blueprint:
Instanz-Submodel:
Da es sich bei den Eingangsdaten um ein elektrisches Fahrzeug handelt, wurde nur die Batterie-Info in das Submodel übernommen.
Implementierung & Architektur
Für die Implementierung der Rules-Engine wurde eine Pipeline-Architektur (Pipes & Filters nach Buschmann et al.) ausgewählt, da sie für das Hinzufügen oder Verändern neuer Regeltypen eine große Flexibilität bietet. Außerdem ist sie im hier verwendeten .net-Framework ein geläufiges Designpattern.
Die Implementierung der Pipeline läuft in fünf Schritten ab.
1. Aufteilung der Gesamtaufgabe
Die Generierung wird in die folgenden Schritte aufgeteilt:
- Deep Clone Template Aas Generator Pipeline Step:
Kopie des Submodel-Templates als Arbeitsgrundlage - Set Kind Instance Aas Generator Pipeline Step:
Setzen von kind zu „Instance“ - Duplicate Collections Aas Generator Pipeline Step:
Duplizierung von Elementen basierend auf SMT/Collection Mapping Info-Qualifiers - Map Data To Instance Aas Generator Pipeline Step:
Mapping von Daten basierend auf SMT/Mapping Info-Qualifiers - Remove Top Level Qualifiers Aas Generator Pipeline Step:
Entfernung der Submodel-Qualifier - Replace Identification Aas Generator Pipeline Step:
Zuweisung der neuen Submodel-ID
2. Definierung der Formate
Um die Daten konsistent zwischen den einzelnen Schritten auszutauschen, wird ein ein-heitliches Kontext-Objekt definiert, welches im folgenden Code-Ausschnitt gezeigt wird.
In der SubmodelInstance wird der aktuelle Stand des Submodels transportiert. Die Eingabedaten werden als unveränderliche Eigenschaften weitergegeben. Zusätzlich werden Parameter für das Logging und Fehlerhandling definiert.
3. Implementierung der Kanäle
Die Datenübertragung zwischen Schritten erfolgt über eine zentrales Pipeline-Objekt:
Alle Schritte werden in einer Liste abgelegt und anschließend in einem Loop ausgeführt. Bei jeder Ausführung wird das Kontext-Objekt weitergegeben.
Alle Schritte werden von einem zentralen IPipelineStep-Interface abgeleitet und als eigene Klassen implementiert.
4. Fehlerbehandlung und Logging
Wie bereits in Schritt 2 definiert, werden alle Logs, die bei der Generierung anfallen im Kon-text-Objekt gespeichert. Zusätzlich wird auch der aktuell zu verarbeitende Regel-Qualifier hier abgelegt. Tritt nun ein Fehler bei der Generierung auf, werden diese Informationen über die API zurückgegeben und helfen dem Aufrufer dabei den Fehler zu debuggen.
5. Zusammenstellung der Pipeline
Mithilfe eines Pipelinebuilders kann die Pipeline erstellt werden und jeder Schritt in der ge-wünschten Reihenfolge registriert werden. An die erstellte Pipeline wird dann ein initiales Kontext-Objekt übergeben, um die Generierung zu starten.
Visualisierung der Regeln im Mnestix AAS Browser
Die Blueprints können im Mnestix Browser im Abschnitt Blueprints und Templates visuali-siert werden. Dabei kann für jedes SME individuell Mapping-Regeln festgelegt werden
Fazit
Die automatisierte Erstellung digitaler Zwillinge ist eine zentrale Herausforderung der Industrie 4.0. Regelbasierte Ansätze, wie der in Eclipse Mnestix verwendete, eignen sich besonders gut für homogen strukturierte Daten, bei denen nur inital die Mapping-Regeln festgelegt werden müssen. Je nach Anwendungsfall können aber auch andere Ansätze wie das Einbeziehen semantischer Kataloge (z.B. e-class) oder die Verwendung von maschinellem Lernen von Vorteil sein.
Sie können die gesamte Bachelorarbeit in diesem gitHub-Repository finden oder sich hier über Eclipse Mnestix informieren.
Basierend auf der Bachelorarbeit von Luis Schweinberger
Co-Autoren
Dr. Alwin Hoffmann
Moritz Hofer