Meta-Modelle für große Datenmengen im digitalen Zwilling

Die Verwaltungsschale (Asset Administration Shell, AAS) dient der Erstellung und dem Austausch industrieller digitaler Zwillinge. Aus Sicht der Autoren sind digitale Zwillinge eine Datensammlung mit mehr oder weniger ausgeprägten Eigenschaften und Verhalten. Dabei unterscheidet man unter anderem Typ 1 (serialisierte Daten sind in einem standardisierten Dateiformat abgelegt, typischerweise JSON- oder XML-basiert) und Typ 2 (Serverprotokoll, das die aktuellen Daten ausliefert oder aktualisiert).

Projekt lotet Grenzen aus

Im Zuge des Projekts Tooling (Digitaler Zwilling für den KI-unterstützten Werkzeugentstehungsprozess) sollte ein digitaler Zwilling des Werkzeugentstehungsprozesses erstellt und mit Daten der beteiligten Partner gefüttert werden. Ein erster Ansatz mit der AAS musste nach recht kurzer Zeit verworfen werden: Die zu speichernde Datenmenge war mit letztlich mehr als 100 Gigabyte schlicht zu groß. Dieser Beitrag soll die im Projekt vorliegende Problemstellung beleuchten und Handlungsempfehlungen für andere Betroffene bieten. Bei Nutzung von ähnlichen Standards, wie AutomationML besteht das Problem ebenso. Es ist ein systematisches Problem der Daten-basierten digitalen Zwillinge.

Speicherinfrastruktur bei AAS

Bei der AAS des Typs 1 (oder AMLX) werden die Daten des Zwillings in gezippter Form als .aasx-Datei abgelegt. In dem Archiv befindet sich eine XML-Datei, genannt Manifest, die die eigentlichen Daten enthält. Es lassen sich zusätzliche Anhänge einbinden. Somit können grundsätzlich beliebige Daten und Dateiformate in einer AAS eingebettet und weiterverarbeitet werden. Das Problem mit diesem Ansatz ist der Fokus auf das Manifest. Die Annahme ist, dass die Daten in XML kodiert ablegbar sind. Für nicht-komplexe Daten wie Texte, Zahlen und Wahrheitswerte ist das auch direkt möglich. Bei Nutzung externer Daten, sogenannter Blobs, stößt der Ansatz schnell an seine Grenzen, wenn eine gewisse Größe erreicht ist: Der Algorithmus zum (Ent-)Packen benötigt nun signifikante Speicher- und Rechen-Ressourcen.

BaSyx/FA3ST ist keine Lösung

Ein erster Lösungsansatz dieses Problems könnte in der Nutzung von AAS Typ 2 liegen. Es existieren Referenz-Implementierungen wie etwa BaSyx oder FA3ST, welche einen Server bereitstellen. Diese nutzen allerdings zur Speicherung der ausgetauschten Daten intern dennoch eine Typ-1-AAS. Damit erbt dieser Ansatz quasi die Probleme des Typs 1 und kann ebenso schlecht mit großen Daten umgehen, wie ein direkt auf .aasx-Dateien basierender Ansatz. Um die Blobs nicht im Archiv abzulegen, ist es nötig, diese außerhalb zu speichern. Bestehende Bibliotheken für die AAS stellen nur die Interaktion mit aasx-Dateien bereit. Damit geht ein Mehraufwand für die Verwaltung und das Management der externen Dateien und gegebenenfalls ihrer Versionen einher. In der AAS werden dann im Manifest nur noch die Informationen gespeichert, wo die binären Blobs zu finden sind (einfachster Fall: URI oder Dateipfad in einem String).

Freiheit bedeutet Mehraufwand

In der IT ist es üblich, zu abstrahieren. Angewandt auf die AAS beschreibt Typ 2 nur noch ein Kommunikationsprotokoll (eine API). Wie die Daten gespeichert werden, ist nicht festgelegt (vgl. Abb. 1). Beispielsweise kann hier auch eine klassische Datenbank eingesetzt werden: Die Aufgabe klassischer Datenbanken ist die Speicherung (semi-)strukturierter Daten, wie sie auch im Manifest der AAS auftreten. Diese Programme wurden in jahrelanger Arbeit verbessert und für ihren Einsatz optimiert. Daher ergibt es Sinn, bei einem AAS-Typ-2-Server die Datenhaltung in Datenbanken auszulagern. Dies reduziert neben dem Ressourcenverbrauch auch den Aufwand zur Verwaltung des Manifests bei der Implementierung. Die hier genannten Möglichkeiten sind nicht erschöpfend. Das individuelle Optimum muss im Spektrum zwischen standardisierten und maßgeschneiderten Systemen gefunden werden. Je weiter man sich von der Standardisierung durch AAS/AML entfernt, desto mehr Freiheiten sind vorhanden, um die Speicherung zu optimieren. Dies muss allerdings durch einen Mehraufwand in der Implementierung erkauft werden. Beispielsweise bedeutet das Speichern in einem externen Storage, grundlegende Konzepte erneut zu prüfen: Der AAS-Typ-2-Server kennt Maßnahmen zur Rechte- und Rollenverwaltung. Diese müssen bei einem externen Server als zusätzliche Schutzebene erst eingebunden werden.

Interface für den Nutzer

Die AAS Typ 2 definiert eine Reihe REST-basierter Schnittstellen zur Navigation auf den Daten. Damit können sich Clients alle benötigten Daten beschaffen und eigene Daten ablegen. Das Interface ist jedoch sehr allgemein gehalten, da es sich bei der AAS um ein Meta-Modell handelt. Das Interface beschreibt deshalb kein konkretes Datenmodell für einen Anwendungsfall. Stattdessen definiert es generische Zugriffe, die dann kontextabhängig sind. In Ermangelung eines statischen Datenmodells ist Typsicherheit unmöglich und Anwender oder Nutzer sind dafür verantwortlich, die Daten auf Validität zu prüfen. Alternativ besteht die Möglichkeit, statt einem AAS-Typ-2- einen Problem-spezifischen REST-Server aufzubauen. In diesem Fall können die Endpunkte genau an den jeweiligen Use-Case angepasst werden. Damit ist der Gedanke der Standardisierung jedoch verloren gegangen und Interoperabilität zumindest fraglich. Je nach angestrebtem Einsatzszenario steht der Navigationsaufwand innerhalb der AAS in direkter Abhängigkeit zu ihrer Komplexität. Zum einen reduziert eine zugeschnittene API den Implementierungsaufwand des Clients. Zum anderen erlaubt ein generisches Interface (vgl. AAS-Server-Typ2-API) größtmögliche Flexibilität (vgl. Abb. 2).

Fazit

Der Einsatz von Meta-Modellen in der Industrie 4.0 (AAS/AML) ist im jeweiligen Einsatzszenario genau zu prüfen. Die Modelle wurden in den letzten Jahren stark in den Fokus der Industrie und Wissenschaft gerückt und von den Herausgebern gerne als allgemeingültige Lösung propagiert. Jedoch lässt sich keine eindeutige und pauschale Aussage dazu sinnvoll treffen. Stattdessen sollten in jedem Einsatzfall der Zweck und die Rahmenbedingungen geprüft werden. Es gibt viele Einsatzbereiche, in denen Meta-Modelle einen Beitrag zum industriellen Fortschritt leisten. Ebenso gibt es aber auch Fälle, bei denen ihr Einsatz zu einem erhöhten Aufwand führen wird. Eine individuelle Fall-Analyse wird daher dringend angeraten. Das Forschungsprojekt Tooling wurde von der Europäischen Union finanziert und vom Bundesministerium für Wirtschaft und Klimaschutz (BMWK) gefördert.