Die Verwaltungsschale (AAS - Asset Administration Shell) in der Praxis

Die Asset Administration Shell, auf Deutsch Verwaltungsschale, ist im Umfeld von Industrie 4.0 gut dokumentiert und schlecht erklärt. Die Spezifikation beschreibt präzise, wie eine Verwaltungsschale aufgebaut ist. Sie beschreibt nicht, warum man eine haben möchte.

Ausgangslage

In einer gewachsenen Fertigung beschreibt jedes System dieselbe Maschine anders: das ERP kennt eine Anlagennummer, die Instandhaltung eine Seriennummer, die Steuerung eine IP-Adresse. Wer eine Frage über die Maschine beantworten will, muss zuerst wissen, wo er fragen darf.

Eine Ebene tiefer, bei der zugelieferten Komponente, wiederholt sich das Muster: Der Hersteller der Pumpe hat ihre Daten vollständig vorliegen, als Katalog-PDF, als Tabelle im Vertrieb, als Handbuch im Versandkarton. Beim Kunden wird daraus abgetippt, was gerade gebraucht wird, und der Rest bleibt liegen.

Und eine Ebene weiter, beim eigenen Produkt, das das Werk verlässt: Mitgeliefert wird ein Papierstapel oder ein Downloadlink. Einbau, Wartung, Weiterverkauf und Entsorgung finden dann außerhalb der eigenen Sicht statt.

Dreimal dasselbe Problem. Die Beschreibung existiert jeweils, aber in einer Form, die nur Menschen lesen können, und an jeder Station neu.

Die Verwaltungsschale legt diese Beschreibung einmal standardisiert ab, und zwar für jedes Asset nach denselben Regeln, ob es eine Maschine ist, eine Komponente oder ein Produkt. Damit ist sie das, was gemeinhin digitaler Zwilling heißt, nur in festgelegter Form: Der Begriff beschreibt die Idee, die Verwaltungsschale gibt ihr ein Format, auf das sich zwei Unternehmen einigen können, ohne vorher miteinander gesprochen zu haben.

Unterschied zu einem eigenen Format

Eine einheitliche Ablage könnte sich jedes Unternehmen auch selbst definieren. Der Unterschied zu einer solchen Hausstruktur ist weniger technischer als organisatorischer Natur. Die Verwaltungsschale wird von der Industrial Digital Twin Association gepflegt, liegt in Version 3 vor, und ihr Metamodell ist in der Normenreihe IEC 63278 standardisiert. Der Zugriff läuft über eine einheitliche API statt über eine Schnittstelle, die mit jedem Partner neu verhandelt wird.

Praktisch heißt das: Ein Lieferant erzeugt die Beschreibung seiner Komponente einmal, und jeder Kunde kann sie lesen, ohne vorher ein Datenmodell abzustimmen. Das ist der eigentliche Gewinn. Er entsteht erst, wenn beide Seiten denselben Standard auch tatsächlich verwenden.

Typ und Instanz

Einmal erzeugt, aber für die Baureihe oder für jedes einzelne Stück? Die Spezifikation beantwortet das mit zwei Arten von Verwaltungsschalen, und die Unterscheidung erklärt in der Praxis viel.

Die Typ-Verwaltungsschale beschreibt ein Produkt oder eine Produktreihe, inhaltlich das, was früher der Katalog war: Maße, Leistungsdaten, zulässige Betriebsbedingungen, Handbuch. Sie gilt für alle Exemplare gleichermaßen und bildet immer den aktuellen Stand ab.

Die Instanz-Verwaltungsschale gehört zu einem einzelnen, tatsächlich gefertigten Exemplar: Seriennummer, Fertigungsdaten, später Wartungshistorie. Sie ist der digitale Zwilling im engeren Sinn: der Zwilling dieses einen Stücks, nicht der Bauart.

Für den Betrieb zählt meist die Instanz, für den Vertrieb der Typ. Beide gehören zusammen: Die Instanz verweist auf ihren Typ, statt dessen Angaben noch einmal zu führen. Was auf der Bauart gilt, steht genau einmal da.

Produktbeschreibung und Dokumentation an einer Stelle

Gefüllt werden beide auf dieselbe Weise: mit Teilmodellen. Die IDTA standardisiert diese Teilmodelle einzeln; inzwischen sind über 70 verfügbar. Drei davon decken zusammen ab, was man gemeinhin Produktunterlagen nennt:

• Digital Nameplate: das digitale Typenschild mit Hersteller, Typbezeichnung, Seriennummer und Baujahr, maschinenlesbar statt als Aufkleber am Gehäuse.
• Technical Data: technische Merkmale, klassifiziert nach ECLASS oder IEC CDD, also als vergleichbare Eigenschaften statt als Fließtext im Datenblatt.
• Handover Documentation: die Übergabedokumentation mit Zeichnungen, Handbüchern und Zertifikaten, nach VDI 2770 klassifiziert und als Datei referenziert.

Damit wird die Verwaltungsschale zur Produktbeschreibung einschließlich Dokumentation, an einer Stelle statt verteilt auf Datenblatt, PDF-Ordner und ERP-Feld.

Die Grundlage für den digitalen Produktpass

Damit ist beisammen, was ein Produkt über sein Leben hinweg begleiten müsste. Genau das verlangt der Gesetzgeber inzwischen. Der Digital Product Passport stammt aus der Ökodesign-Verordnung (EU) 2024/1781, seit dem 18. Juli 2024 in Kraft. Sie verlangt einen strukturierten Datensatz, der ein Produkt über seinen Lebenszyklus begleitet und Materialzusammensetzung, Rezyklatanteil, Reparierbarkeit und Entsorgung dokumentiert. Verfügbar bleiben muss er über die Lebensdauer des Produkts hinaus noch zehn Jahre.

Zurück zu Typ und Instanz: Ein Produktpass liegt nah an der Instanz, fällt aber nicht mit ihr zusammen. Die Grundidee ist dieselbe: eine standardisierte Beschreibung, die am Gegenstand hängt. Hinzu kommen geregelte Zugriffsrechte und regulatorisch vorgegebene Inhalte, und ein anderer Adressat: nicht der Betreiber, sondern Kunden, Prüfstellen und am Ende der Recyclingbetrieb.

Wie nah, entscheidet der Gesetzgeber von Fall zu Fall. Die Ökodesign-Verordnung schreibt nicht vor, dass ein Pass zu genau einem gefertigten Stück gehört; ob er auf Modell, Charge oder Artikel liegt, bestimmt der jeweilige delegierte Rechtsakt. Für die Verwaltungsschale ist das kein fremdes Gelände: Ein Pass auf Modellebene trifft den Typ, einer auf Artikelebene die Instanz, die Charge liegt dazwischen.

Konkret wird es zuerst bei Batterien: Ab dem 18. Februar 2027 brauchen Traktionsbatterien, Batterien für leichte Verkehrsmittel und Industriebatterien über 2 kWh einen Batteriepass. Der Arbeitsplan zur Ökodesign-Verordnung nennt danach Eisen und Stahl, Textilien, Reifen, Aluminium und Möbel.

Der Arbeitsplan ist allerdings keine Zusage. Zwischen dem Erlass eines delegierten Rechtsakts und seiner Anwendung liegen mindestens 18 Monate, und Verschiebungen waren bisher eher die Regel als die Ausnahme. Wer heute anfängt, sollte das nicht wegen einer Frist tun, sondern weil die Daten ohnehin gebraucht werden.

Grenzen des Standards

So weit die Aussicht. Die Teilmodelle geben die Felder vor. Sie geben nicht vor, welche Werte hineingehören, woher sie kommen und wer sie aktuell hält. Genau dort liegt die Arbeit.

Ein digitales Typenschild ist schnell gefüllt. Bei den technischen Merkmalen beginnt die erste echte Entscheidung: Welche ECLASS-Eigenschaften sind für dieses Produkt die richtigen? Bei der Übergabedokumentation die zweite: Welches der PDFs im Projektordner ist die gültige Fassung, und wer merkt es, wenn eine neue dazukommt? Und wenn ERP und Instandhaltung derselben Maschine unterschiedliche Angaben zuordnen, entscheidet das kein Format, sondern jemand im Unternehmen.

Das ist kein Einwand gegen die Verwaltungsschale, sondern ihre Nebenwirkung: Sie ist eine Sicht auf vorhandene Daten, keine Datenquelle. Wo die Stammdaten schlecht gepflegt sind, macht sie das sichtbar. Besser macht sie es nicht.

Wann sich der Aufwand lohnt

Drei Situationen, in denen die Rechnung aufgeht. Erstens: Dieselbe Information wird mehrfach gebraucht, über Werke hinweg, über Systemgrenzen hinweg, gegenüber Kunden und Lieferanten. Zweitens: Sie liefern Komponenten, und der Einkauf Ihrer Kunden fragt die Verwaltungsschale zunehmend mit der Lieferung ab; dann ist sie weniger ein IT-Projekt als ein Teil des Produkts. Drittens: Ihr Produkt fällt unter eine Produktpass-Pflicht. Dann steht nicht mehr zur Debatte, ob, sondern nur noch wann.

Bleibt der Fall, in dem nichts davon zutrifft: eine einzelne Anlage in einer einzelnen Halle, niemand fragt von außen danach, keine Verordnung greift. Dort ist eine Verwaltungsschale Aufwand ohne Ertrag. Die richtige Antwort ist dann, zu warten und nicht vorsorglich eine halbe zu bauen.

Zum Ausprobieren

Die AAS-Suite ist unsere eigene Plattform zum Erstellen, Ansehen und Verwalten von Verwaltungsschalen. Sie ist IDTA-konform und seit Kurzem als Open Source verfügbar.

Unter aas-ecosystem.de zeigen wir gemeinsam mit der M&M Software, wie sich bestehende Open-Source-Bausteine zu einer laufenden Umgebung zusammensetzen lassen: BaSyx als AAS-Server, die AAS-Suite als Oberfläche, die AAS Twin Engine zur Erzeugung der Instanzen. Startpunkt ist ein Docker Compose, das erste umgesetzte Beispiel ein digitaler Produktpass.