Die Verwaltungsschale (Asset Administration Shell, AAS) ist der Industrie-4.0-Standard, der jedem Industrie-Asset einen strukturierten, maschinenlesbaren digitalen Zwilling gibt. In diesem Artikel erfahren Sie, wie eine Verwaltungsschale aus Teilmodellen und semantischen IDs aufgebaut ist, wie sich die drei AAS-Typen unterscheiden und wie Sie Live-Werte von Teilmodellen mit MQTT-Daten, die über einen Broker strömen, aktuell halten.
Eine breitere Einführung in Zwillinge bietet unser Leitfaden zur Digital-Twin-Technologie.
Was ist eine Verwaltungsschale?
Eine Verwaltungsschale ist eine standardisierte digitale Repräsentation eines Assets: eines Motors, eines Antriebs, eines Roboters, einer ganzen Fertigungszelle oder sogar einer Software. Sie wurde in Deutschland im Rahmen der Plattform Industrie 4.0 als Umsetzung der Verwaltungsschale aus dem Referenzarchitekturmodell RAMI 4.0 definiert und wird heute von der Industrial Digital Twin Association (IDTA) gepflegt; ihr Metamodell ist international als IEC 63278 standardisiert.
Die Kernidee ist Interoperabilität. Ein Antrieb des einen Lieferanten und eine Pumpe des anderen sollen ihr Typenschild, ihre technischen Daten, ihre Dokumentation und ihre Betriebsdaten auf dieselbe Weise beschreiben, sodass ein Anlageningenieur, ein MES oder ein Instandhaltungstool sie ohne herstellerspezifische Integration lesen kann. Die AAS gibt jedem Asset dieselbe „Hülle", und der Inhalt darin ist in Teilmodelle gegliedert.
Der Aufbau einer AAS
Eine AAS besteht aus wenigen Bausteinen:
| Element | Zweck |
|---|---|
| Verwaltungsschale | Der Zwilling selbst, mit eigener ID, der genau ein Asset referenziert |
| Asset-Information | Globale Asset-ID und Art (Typ oder Instanz) |
| Teilmodell | Ein in sich geschlossener Aspekt des Assets, etwa Typenschild oder Betriebsdaten |
| Teilmodell-Element | Der eigentliche Inhalt: Properties, Bereiche, Dateien, Collections, Operationen |
| Semantische ID | Ein Verweis auf eine Wörterbuchdefinition, die festlegt, was ein Element bedeutet |
| Concept Description | Die Definition einer semantischen ID, mit Einheiten und Datentyp |
Teilmodelle
Teilmodelle sind das Herzstück der Verwaltungsschale. Jedes deckt einen Aspekt des Assets ab und kann von einer anderen Partei gepflegt werden. Der Hersteller liefert das digitale Typenschild und die technischen Daten; der Betreiber ergänzt Instandhaltungsaufzeichnungen und Live-Betriebsdaten.
Die IDTA veröffentlicht Teilmodellvorlagen, damit gängige Aspekte überall gleich aussehen. Weit verbreitete Vorlagen sind unter anderem Digital Nameplate, Technical Data, Contact Information, Handover Documentation und Time Series Data. Eine Vorlage zu nutzen, statt eine eigene Struktur zu erfinden, ist das, was die AAS interoperabel macht.
Teilmodell-Elemente
Innerhalb eines Teilmodells wird der Inhalt als typisierte Elemente ausgedrückt. Diese begegnen Ihnen am häufigsten:
- Property: ein einzelner Wert mit Datentyp, zum Beispiel
MaxRotationSpeedals Double. - MultiLanguageProperty: Text in mehreren Sprachen.
- Range: ein Minimum und ein Maximum.
- File und Blob: Dokumente, Bilder, CAD-Dateien.
- SubmodelElementCollection und SubmodelElementList: Gruppierung und Wiederholung.
- ReferenceElement und RelationshipElement: Verknüpfungen zwischen Elementen oder Assets.
- Operation: eine aufrufbare Funktion mit Ein- und Ausgabevariablen.
Semantische IDs
Jedes Element kann eine semantische ID tragen, die auf eine Definition in einem Wörterbuch wie ECLASS oder dem IEC Common Data Dictionary verweist. Dadurch erkennt Software, dass eine Property namens NenndrehzahlMax in der einen AAS und MaxSpeed in einer anderen dasselbe bedeuten. Ohne semantische IDs ist eine AAS nur ein weiteres JSON-Format.
Die drei Typen der Verwaltungsschale
| AAS-Typ | Form | Typische Verwendung |
|---|---|---|
| Typ 1 | Eine Datei, meist ein AASX-Paket | Der Hersteller liefert Zwillingsdaten mit dem Produkt aus |
| Typ 2 | Ein Server, der die AAS über eine API bereitstellt | Anlagensysteme lesen und aktualisieren Zwillinge zur Laufzeit |
| Typ 3 | Proaktive Schalen, die miteinander interagieren | Autonome Verhandlung zwischen Assets, noch im Entstehen |
Die meisten Industrieprojekte arbeiten heute mit Typ 1 für Engineering- und Übergabedaten und mit Typ 2 für Laufzeitzwillinge. Open-Source-Implementierungen wie Eclipse BaSyx bieten AAS-Server und -Registries, und der AASX Package Explorer wird häufig verwendet, um AASX-Dateien zu erstellen und zu prüfen.
Wo MQTT ins Spiel kommt: Live-Daten für eine Verwaltungsschale
Der AAS-Standard definiert das Informationsmodell und die APIs, schreibt aber nicht vor, wie Live-Werte aus der Fertigung ankommen. In der Praxis fließen Betriebsdaten wie Temperaturen, Drehzahlen und Zustände bereits über MQTT von SPS und Edge-Gateways. Das praxisnahe Muster lautet: MQTT bleibt der Echtzeittransport, und ein Adapter aktualisiert das betreffende AAS-Teilmodell.
PLC / sensor -> edge gateway -> MQTT broker -> AAS adapter -> AAS server (Type 2)
|
+-> dashboards, 3D twins, historians
So bleiben schnelle Konsumenten (Dashboards, Alarme, 3D-Echtzeitzwillinge) auf MQTT, während der AAS-Server die standardisierte, semantisch annotierte Sicht vorhält, die MES, ERP und Engineering-Tools lesen.
Topic-Design, das sich sauber auf Teilmodelle abbilden lässt
Wählen Sie Topics, die das Mapping auf die AAS offensichtlich machen. Am besten gelingt das mit einem Unified Namespace (UNS): Die ISA-95-Hierarchie Enterprise → Site → Area → Line → Cell wird zur Topic-Struktur auf dem MQTT-Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Der ISA-95-Pfad identifiziert das Asset, die letzten Ebenen das Teilmodell:
acme/plant1/assembly/line3/drive07/operational live values, retained
acme/plant1/assembly/line3/drive07/status online/offline, retained
Der Adapter führt eine Mapping-Tabelle von MQTT-Asset-Pfaden zu AAS-IDs und von JSON-Feldern zu idShorts der Teilmodell-Elemente. Sparkplug-B-Payloads funktionieren ebenfalls: ConnectMQ dekodiert Sparkplug B und kann es in ISA-95-Topics republizieren, sodass der Adapter einen einfachen JSON-Strom konsumieren kann.
Ein minimaler MQTT-zu-AAS-Adapter
Dieser Python-Adapter abonniert Betriebsdaten und aktualisiert Property-Werte auf einem AAS-Server per PATCH. Der REST-Pfad folgt dem API-Stil aus AAS Teil 2, wie ihn Server wie Eclipse BaSyx verwenden, bei dem Kennungen base64url-kodiert sind; den genauen Endpunkt und die Version entnehmen Sie der Dokumentation Ihres Servers.
import base64
import json
import paho.mqtt.client as mqtt
import requests
AAS_SERVER = "http://localhost:8081"
SUBMODEL_IDS = {
"acme/plant1/assembly/line3/drive07": "https://acme.example/ids/sm/drive07-operational",
}
FIELD_TO_IDSHORT = {"speed_rpm": "RotationSpeed", "temp_c": "MotorTemperature", "state": "OperatingState"}
def b64url(value: str) -> str:
return base64.urlsafe_b64encode(value.encode()).decode().rstrip("=")
def on_connect(client, userdata, flags, reason_code, properties):
client.subscribe("acme/plant1/+/+/+/operational", qos=1)
def on_message(client, userdata, msg):
asset_path = msg.topic.rsplit("/", 1)[0]
submodel_id = SUBMODEL_IDS.get(asset_path)
if not submodel_id:
return
data = json.loads(msg.payload)
for field, id_short in FIELD_TO_IDSHORT.items():
if field in data:
url = f"{AAS_SERVER}/submodels/{b64url(submodel_id)}/submodel-elements/{id_short}/$value"
requests.patch(url, json=data[field], timeout=5)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883)
client.loop_forever()
Zwei Hinweise zum Design. Erstens: Schieben Sie nicht jeden hochfrequenten Messwert in den AAS-Server; aktualisieren Sie ihn mit einer sinnvollen Rate, zum Beispiel einmal pro Sekunde oder bei Änderung, und halten Sie die Daten in voller Auflösung in einem Historian. Zweitens: Halten Sie die Mapping-Tabellen in der Konfiguration, idealerweise aus der AAS selbst generiert, damit das Hinzufügen eines Assets keine Codeänderung erfordert.
Die MQTT-Seite können Sie sofort mit dem öffentlichen MQTT-Broker testen – nur mit Testdaten, denn er ist für jeden lesbar und nicht für Produktivdaten gedacht –, indem Sie statt acme/... ein eindeutiges Präfix wie connectmq/demo/c58d/... verwenden und das Abonnement entsprechend anpassen.
Checkliste für die Einführung der Verwaltungsschale
- Die Assets im Scope festlegen und stabile globale Asset-IDs vergeben.
- Mit IDTA-Teilmodellvorlagen beginnen, bevor eigene Teilmodelle entstehen.
- Jeder bereitgestellten Property semantische IDs aus ECLASS oder IEC CDD zuordnen.
- Entscheiden, welche Daten in Typ-1-Dateien und welche in einem Typ-2-Server liegen.
- MQTT-Topics so entwerfen, dass Asset-Pfade eins zu eins auf AAS-IDs abgebildet werden.
- Einen Adapter schreiben oder bereitstellen, der Live-Werte von Teilmodellen mit kontrollierter Rate aktualisiert.
- Den MQTT-Pfad mit TLS und Zugangsdaten pro Gateway absichern.
- Teilmodelle versionieren und die Mapping-Konfiguration unter Versionskontrolle halten.
AAS im Vergleich mit anderen Zwillingsmodellen
Die AAS ist am stärksten bei Industrie-Assets, die zwischen Herstellern, Integratoren und Betreibern den Besitzer wechseln, weil ihre Teilmodellvorlagen und semantischen IDs mit dem Asset mitreisen. DTDL ist schlanker und entwicklerorientiert, mit Fokus auf Telemetry, Properties und Commands. Eclipse Ditto modelliert Zwillinge als Things mit Attributen und Features und verbindet sich nativ mit MQTT; siehe Eclipse Ditto mit MQTT. Viele Werke kombinieren sie: die AAS für die standardisierte Asset-Beschreibung, MQTT und den UNS für Live-Daten und eine schlanke Zwillingsschicht für die Visualisierung. Unser Leitfaden zu Sparkplug B und Unified Namespace behandelt die Seite der Live-Daten.
Speisen Sie Ihre Verwaltungsschale mit ConnectMQ
ConnectMQ liefert die Echtzeitschicht: einen Cloud-MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS auf Port 8883, ISA-95-Topic-Erkennung, einer nach ISA-95-Ebenen organisierten Geräteansicht und Sparkplug-B-Dekodierung. Ihr AAS-Server und Ihr Adapter laufen daneben als normale MQTT-Clients. Registrieren Sie sich unter app.connectmq.com, starten Sie im kostenlosen Serverless-Plan ohne Kreditkarte und streamen Sie die Betriebsdaten Ihres ersten Assets in seine Verwaltungsschale.
Häufig gestellte Fragen
Ist die Verwaltungsschale ein Softwareprodukt?
Nein. Sie ist ein standardisiertes Informationsmodell und eine API-Spezifikation. Produkte und Open-Source-Projekte wie Eclipse BaSyx implementieren sie.
Was ist ein Teilmodell in der AAS?
Ein Teilmodell ist ein in sich geschlossener Aspekt eines Assets, etwa sein Typenschild, seine technischen Daten oder seine Betriebsdaten, aufgebaut aus typisierten Elementen mit semantischen IDs.
Ersetzt die AAS MQTT oder OPC UA?
Nein. Die AAS beschreibt Assets und stellt sie über APIs bereit; MQTT und OPC UA transportieren Live-Daten. Ein gängiges Muster ist MQTT für Echtzeitströme, kombiniert mit einem Adapter, der die AAS aktualisiert.
Was ist eine AASX-Datei?
Eine AASX-Datei ist ein Paketformat für Verwaltungsschalen vom Typ 1, das die AAS, ihre Teilmodelle und ergänzende Dateien wie Handbücher für den Austausch in einer Datei bündelt.
