Submodel Templates für AAS

In der Vergangenheit haben wir auf diesem Blog die Verwaltungsschale (AAS) mit ihrem Meta-Modell und ihrer API vorgestellt. Submodels sind die zentralen Informationsträger, deren Struktur Daten an erwartbaren Orten auffindbar macht. Die Geschäftslogik weiß genau, wie die Daten zu interpretieren sind und löst damit ein zentrales Versprechen von Standardisierung ein: Programmieren gegen die Typdefinition. Dahinter steckt die simple Idee, dass nicht jede Datenquelle einzeln verstanden und angeschlossen werden muss, sondern dass Wissen über die Konformität ausreicht. Nur so werden skalierte verteilte Systeme realistisch, weil der Integrationsaufwand sonst mit jeder Datenquelle mehr als proportional steigen würde.

Submodel Templates bergen Risiken

Ein Submodel Template besteht aus einem erklärenden PDF-Dokument und einer AASX-Datei, die das Template enthält. Die IDTA koordiniert dazu diverse Arbeitsgruppen, die sich ähnlich clustern lassen wie bei OPC UA CS (Standards-Mapping, Grundbausteine, Domain-Modelle). Denn für die Verwaltungsschale sind Herausforderung und Ehrgeiz ganz ähnlich wie für OPC UA: Es lohnt sich, über das Meta-Modell hinaus die innere Struktur von Domänenmodellen zu standardisieren, um semantische Eindeutigkeit herzustellen. Es gibt trotzdem einige Gründe, warum bisher unklar ist, ob sich das Prinzip der Submodel Templates durchsetzen wird.

• Tooling: Der AASX-Package-Explorer ist aktuell der einzige verbreitete visuelle Editor für AAS und Submodel Templates. Seine Bedienung setzt viel Wissen über das Meta-Model voraus, was eine Hürde für Einsteiger ist. (“Warum muss das Submodel jetzt drei unterschiedliche IDs bekommen?!”)
• Format: AASX-Dateien, die Submodel-Templates beinhalten, können nicht zur Validierung genutzt werden. Obwohl die AAS ja Serialisierungen zur JSON, XML, RDF kennt, gibt es für die Submodel Templates keine entsprechenden Schemadateien (JSON-Schema, XSD, SHACL). Das verunmöglicht einen zentralen Use-Case, nämlich die Beantwortung der Frage: “Hält sich dieses Submodel auch wirklich an den Standard, den es vorgibt und wenn nein, was stimmt nicht?”
• Komplexität: Die Modellierung von Submodels in der AAS ist kompliziert. Es gibt wahnsinnig viele Freiheitsgrade und vor allem die Verlinkungen zu anderen Standards (SemanticIds/Concept Descriptions) machen es schwierig sich an alle expliziten und impliziten Konventionen zu halten. Umso näher liegt die Sehnsucht aus bestehenden Standards (Ontologien/OPC UA CS) automatisch Submodels zu generieren.
• Doppelarbeit: Wenn sich das Meta-Modell ändert, ist im Falle fehlender Rückwärtskompatibilität ein Submodel nicht mehr notwendigerweise kompatibel zur aktuellen Version des Meta-Modells. Parser können die Submodels im Zweifel nicht mehr lesen. Zum Glück werden solche “breaking changes” wo es geht vermieden, aber auch Änderungen, die weniger weitreichend sind, ziehen zwingend eine Prüfung aller Domänen-Erweiterungen nach sich.

Wie geht es weiter?

Modellierung ist immer ein Trade-Off zwischen Simplizität und Vollständigkeit. Die AAS nimmt einen sehr formalen Zugang und ist im Detail wahnsinnig komplex. Submodel Templates haben die Aufgabe, möglichst viel von dieser Komplexität für Modellierer und Entwicklerinnen zu verstecken. Nur wenn es der Community gelingt, verständliche und breit anwendbare Submodel Templates zu standardisieren, wird die Initiative erfolgreich.