Verwaltungsschale ASSEine Vita für den digitalen Zwilling
Von
konstruktionspraxis
16 min Lesedauer
Die Verwaltungsschale (Asset Administration Shell, AAS) liefert eine Basis, um „digitale Zwillinge“ von physischen Produkten standardisiert und maschinenlesbar zu beschreiben. Wie ist die AAS aufgebaut und was macht sie für Konstrukteure und Entwickler wichtig?
Die Verwaltungsschale liefert eine Basis, um „digitale Zwillinge“ physischer Produkte standardisiert und maschinenlesbar zu beschreiben.
Die AAS beschreibt ein physisches Asset wie Maschinen, Geräte, Produkte oder auch Software‑Komponenten als „digitaler Zwilling“ in Industrie‑4.0‑Umgebungen in einer einheitlichen, maschinenlesbaren Struktur mit Metadaten, technischen Parametern sowie Konfigurations‑ und Zustandsdaten über den gesamten Lebenszyklus. Sie ist mit der IEC 63278 international als Grundlage des digitalen Zwillings normiert und ermöglicht herstellerübergreifende Interoperabilität in Industrie‑4.0‑Ökosystemen.
das lesen sie in diesem Beitrag
Die Definition der AAS
Aufbau der AAS und Zusammensetzung der Teilmodelle
Kernbausteine der AAS für Konstrukteure (mit Tabelle)
Teilmodelle mit Konstruktionsbezug (mit Tabelle)
Einsatz der Teilmodelle in der Praxis
5 Schritte vom „Minimalmodell“ zum ausgereiften digitalen Zwilling (mit Tabelle)
Schnittstellen und Protokolle zur Unterstützung von Konstrukteuren (mit Tabelle)
AAS im Kontext von „Digitaler Produktpass“ und Ökodesign-Verordnung
Die Industrial Digital Twin Association (IDTA) positioniert als Branchenverband (u. a. ZVEI, VDMA, Bitkom, zahlreiche Hersteller) die AAS als globalen Standard für digitale Zwillinge und als „Enabler“ für Anwendungen wie den digitalen Produktpass (DPP). Die IDTA erarbeitet hierzu u.a. Spezifikationen, Referenzmodelle und Open‑Source‑Bausteine für die AAS und veröffentlicht AAS‑Metamodelle, Submodel-Templates und Implementierungshilfen.[1]
Wie ist eine AAS aufgebaut und aus welchen Teilmodellen setzt sie sich zusammen?
Eine AAS ist eindeutig identifiziert und immer genau einem Asset zugeordnet, etwa einem Motor, Ventil, einer Anlage oder einem Softwaremodul. Als digitale Hülle zur Bündelung aller relevanten Informationen und Services enthält sie Metadaten, wie zum Beispiel Version, Verantwortlicher, Referenzen, und eine Liste von Teilmodellen als strukturierende Container.
Die wichtigsten strukturellen Elemente sind neben dem Asset der AAS-Header, die Teilmodelle (Submodels) und die SubmodelElements:
Der Header enthält globale Informationen zum Asset wie ID, Version, Sprachen, Kontakt und Berechtigungen für die Zusammenarbeit mit Partnern.
Die Submodels (Teilmodelle) gruppieren inhaltlich zusammengehörige Informationen, etwa alle Stammdaten, alle Simulationsmodelle oder alle Wartungsinformationen. Ein Submodel beschreibt somit jeweils genau einen konkreten Aspekt des Assets, darunter technische Daten, Dokumentation, Betriebsdaten, Schnittstellen oder Nachhaltigkeit. Die Teilmodelle sind unabhängig voneinander versionierbar und können über strukturell und semantisch standardisierte Templates (IDTA Submodel Templates) vorgegeben werden (etwa „Digital Nameplate“, „Handover Documentation“, „Provision of Simulation Models“, „Carbon Footprint“). Konstrukteure können diese Templates nutzen, um sicherzustellen, dass ihre AAS-Teilmodelle von Tools und Partnern interoperabel verstanden werden (mehr hierzu weiter unten).
Die SubmodelElements wiederum sind strukturierte feinstufige ergänzende Informationen innerhalb eines Teilmodells, etwa Eigenschaften, Dateien, Operationen oder Ereignisse.
Hier ein Auszug wichtiger Submodel-Templates:
Digital Nameplate: Stammdaten zu Hersteller, Typ, Seriennummer, Zulassungen
Handover Documentation: strukturierte Übergabe von technischen Unterlagen im Sinne von VDI 2770
Provision of Simulation Models: Beschreibung und Bereitstellung von Simulationsmodellen inklusive Metadaten und Download-Links
Carbon Footprint: Struktur für den CO2-Fußabdruck des Produktes (Product Carbon Footprint – PCF) und zugehörige Bilanzierungsdaten.[2]
Kernbausteine der AAS für Konstrukteure:
Baustein
Rolle im digitalen Zwilling aus Konstruktionssicht
Asset
Physische oder logische Einheit, etwa Ventil, Achse, Antrieb, Baugruppe.
Asset Administration Shell
Digitale Hülle, die alle relevanten Informationen und Services zum Asset bündelt.
Submodel
Fachlicher Ausschnitt, etwa Nameplate, Engineering, Maintenance, Sustainability.
SubmodelElement
Kleinste Informationseinheit wie Eigenschaft, Datei, Ereignis oder Operation.
Typische Teilmodelle der AAS mit Konstruktionsbezug (Beispiel):
Wie können Konstrukteure die Teilmodelle in der Praxis nutzen?
Durch den Einsatz der Teilmodelle im AAS lassen sich vor allem wiederkehrende Medienbrüche im Engineering vermeiden und Daten einheitlich zwischen CAD/CAE, PDM/PLM und Kunden austauschen. Nachfolgend die zentralen Teilmodelle und deren Vorteile in der Praxis:
Technische Daten und Typenschild im Engineering: Über Technical‑Data‑ und Nameplate‑Teilmodelle stehen Leistungsdaten, Anschlussdaten, Medien, Umgebungsbedingungen und Identifikation des Bauteils in strukturierter Form für Auslegungstools und Konfiguratoren bereit. Vorteile: Solche Daten können direkt aus der AAS in CAD‑/CAE‑Systeme übernommen werden, ohne sie manuell erfassen zu müssen.
Handover Documentation nach VDI 2770: Mit dem Submodel „Handover Documentation“ lassen sich technische Unterlagen (Zeichnungen, Manuals, Zertifikate) nach VDI 2770 klassifizieren und als digitale Dateien (z. B. PDF/A, STEP) im Teilmodell referenzieren. Vorteile: Relevante Dokumente werden einmalig exakt für Betreiber, Service oder Behörden strukturiert. PLM‑Prozesse wie Produktänderungsmitteilungen lassen sich anschließend weitgehend automatisieren.
Simulation und virtuelle Erprobung: Das IDTA‑Teilmodel „Provision of Simulation Models“ ermöglicht die Bereitstellung von Simulationsmodellen (etwa DAE‑Modelle, CAD‑basierte Modelle, FMEA‑Modelle) samt Metadaten zu Gültigkeit, Parametern und Einsatzgrenzen. Vorteile: Zu einem Bauteil können mehrere Modelle für unterschiedliche Analysezwecke hinterlegt und diese zielgerichtet in CAE‑Workflows eingebunden werden.
Wiederverwendung in Varianten und Baukästen: Teilmodelle lassen sich auf Typ‑Ebene (Baureihe, Variante) definieren und für konkrete Instanzen erneut verwenden. Vorteile: Katalogkomponenten oder modulare Baukästen können effizient verwaltet werden. Für neue Varianten müssen nur Delta‑relevante Eigenschaften oder Dokumentenverweise angepasst werden, während Struktur und Semantik des Teilmodells gleichbleiben.
Integration in PDM/PLM und Datenräume: In vielen Pilotanwendungen werden PDM/PLM‑Daten über Mapping‑Mechanismen automatisiert in AAS‑Teilmodelle überführt. Vorteile: Konstrukteure nutzen ihre gewohnten Systeme, erzeugen aber gleichzeitig AAS‑konforme Zwillinge. Diese Teilmodelle lassen sich anschließend in Lieferketten, DPP‑Szenarien oder Manufacturing‑X‑Datenräumen verwenden, ohne dass für jeden Einzelfall neue Datenstrukturen definiert werden müssen.
5 Schritte vom „Minimalmodell“ zum umfassenden digitalen Zwilling
Ein sinnvoller Einstieg in die AAS besteht darin, mit wenigen, klar umrissenen Anwendungsfällen zu beginnen, diese gut zu strukturieren und dann schrittweise zu erweitern, um vorhandene Produktdaten aus CAD/CAE und PDM/ERP sukzessive in standardisierte Teilmodelle zu überführen.
Zunächst sollten hierzu grundlegende Ziele definiert werden, etwa weniger Medienbrüche im Engineering, bessere Wiederverwendung von Produktdaten, Vorbereitung auf verschiedene DPP‑Szenarien.
Anschließend können einige wenige konkrete Anwendungsfälle priorisiert werden, beispielsweise: digitales Typenschild, strukturierte Übergabedokumentation oder Bereitstellung von Simulationsmodellen. Abschließend geht es an die Umsetzung. Hier beispielhaft 5 konkrete Schritte:
Minimalen Datenumfang festlegen Für jeden Anwendungsfall wird zunächst ein minimaler und an bereits bestehenden Dokumenten sowie Stammdaten orientierter Datensatz definiert. Hierbei wird schnell deutlich, welche Informationen wirklich Bestandteil eines Teilmodels sein müssen. Konstrukteure legen dann gemeinsam mit der IT und dem Produktmanagement fest, welche Eigenschaften, Dokumente und Modelle zunächst für den konkreten Fall ausreichen.
Teilmodelle konzipieren und strukturieren Auf Basis dieses Minimaldatensatzes werden ein bis zwei Teilmodelle entworfen (etwa „Nameplate/Technical Data“, „Handover Documentation“, „Simulation“), die diesen Inhalt strukturiert aufnehmen. Damit einer späteren Automatisierung und Tool‑Integration nichts im Wege steht, ist eine stabile Struktur notwendig, also klar benannte Eigenschaften, nachvollziehbare Gruppierungen und eindeutige Identifikatoren, etc.
Daten aus bestehenden Systemen einpflegen Danach werden Zuordnungen (Mappings) aus bestehenden Quellen wie CAD, CAE, PDM, ERP und DMS auf die Elemente der Teilmodelle übertragen, um eine manuelle Datenerfassung zu vermeiden. In einem ersten Schritt können hierzu einfache Exporte und Skripte genügen. Entscheidend ist, dass die AAS aus vorhandenen Engineering-Daten „gefüttert“ werden kann.
Pilot mit einer Produktfamilie Ein typischer Einstiegspfad ist ein Pilotprojekt mit einer Baureihe oder einem klar umrissenen Baukasten (etwa Ventile, Antriebe), um die erarbeiteten Teilmodelle auszuprobieren, damit Struktur, Datenqualität und Nutzen im Alltag validiert werden können. In diesem Piloten sollte bewusst mit echten Projekten gearbeitet werden (beispielsweise Angebot, Anlagenlayout, Variantenkonfiguration), denn nur so sind Schwachstellen in Struktur oder Daten deutlich erkennbar.
Rückmeldung, Nachschärfung (Optimierung), Skalierung Aus dem Pilotprojekt leiten Konstrukteure und IT gemeinsam ab, welche Felder fehlen, welche redundant sind und wo mitunter Vereinfachungen möglich sind. Erst danach lohnt sich ein breites „Roll-out“. Auf der geschaffenen Basis lassen sich anschließend weitere Teilmodelle ergänzen (etwa Wartung, Betriebsdaten, Nachhaltigkeit), sodass sich das Set für die AAS schrittweise vom „Minimalmodell“ zum umfassenden digitalen Zwilling entwickelt.[4]
Reifes, ausbaufähiges AAS‑Set, das Schritt für Schritt zum digitalen Zwilling wird.
Welche Schnittstellen und Protokolle unterstützen Konstrukteure?
Zur einfachen Integration in CAD/CAE, PDM/PLM und Engineering-IT sind für Konstrukteure insbesondere spezifische Schnittstellen und Protokolle relevant. Im Mittelpunkt stehen hierbei HTTP/REST‑APIs und OPC UA, ergänzt durch MQTT in IoT‑/Cloud-Szenarien.
HTTP/REST und JSON Viele AAS-Server und Tools stellen eine REST‑API bereit, über die Teilmodelle und SubmodelElements per HTTP(S) mit JSON-Strukturen gelesen und geschrieben werden können. Das ist für Konstrukteure ideal, um PDM-/PLM- oder Konfigurator-Systeme über Skripte, Middleware oder Low-Code-Plattformen anzubinden, ohne tiefer in OT-Protokolle (OT – Operational Technology) einsteigen zu müssen.
OPC UA / I4AAS OPC UA bietet als standardisiertes Protokoll eine robuste, semantische Kommunikationsschicht, über die AAS-Informationsmodelle direkt im Automatisierungsumfeld zugänglich werden. Hiervon profitieren Konstrukteure, denn identische AAS-Teilmodelle können sowohl in Engineering-Tools als auch in Leitsystemen oder Edge-Geräten genutzt werden.
MQTT und Publish/Subscribe Im nahen IoT- und Cloud-Kontext lassen sich AAS-Daten über MQTT transportieren, etwa Status- oder Ereignisinformationen aus Teilmodellen, die in Dashboards oder Analyse-Anwendungen einfließen. Für Konstrukteure kann dies interessant sein, wenn Betriebs- und Lastdaten aus dem Feld zurück in den digitalen Zwilling gespiegelt werden sollen, um Auslegung und Materialwahl zu optimieren.
AASX-Dateiformat und Austauschwerkzeuge Mit dem Containerformat AASX können AAS und Teilmodelle inklusive eingebetteter Dateien (Zeichnungen, 3D-Modelle, PDFs) paketweise etwa zwischen OEM und Zulieferer ausgetauscht werden. Verschiedenste Werkzeuge wie bspw. der Eclipse AASX Package Explorer und zugehörige Server unterstützen sowohl REST als auch OPC UA und MQTT, wodurch Konstrukteuren eine praxisnahe Umgebung für erste Integrationen zur Verfügung steht.[5]
Die Übersicht der Schnittstellen und Protokolle[6]:
Schnittstelle / Protokoll
Rolle für Konstrukteure
Typische Verwendung im AAS-Kontext
HTTP/REST + JSON
Einfache Integration mit IT-/Engineering-Systemen
Zugriff auf Teilmodelle aus CAD/CAE-, PDM/PLM- oder Konfigurator-Anbindungen.
OPC UA (I4AAS Mapping)
Verbindung zur Automatisierungs- und Leittechnik
Gemeinsame Nutzung von AAS-Daten in Engineering, Leitsystemen und Edge-Geräten.
MQTT (Publish/Subscribe)
Ereignis- und Zustandsübertragung in IoT-/Cloud-Szenarien
Rückführung von Betriebs- und Lastdaten in den digitalen Zwilling zur Auslegung.
Austausch von Typdaten, Dokumentation und Modellen zwischen OEM und Zulieferern.
AAS-Server / Explorer-Tools
Praktische Umgebung und Integrationsplattform
Testen von Lese-/Schreibzugriffen, Validierung und erste End-to-End-Flows.
AAS im Kontext von DPP und ESPR
Der digitale Produktpass (DPP – Digital Product Passport) ist in der EU als zentrales Instrument in der 2024 eingeführten Ökodesign-Verordnung (ESPR – Ecodesign for Sustainable Products Regulation) verankert. Die ESPR schreibt in diesem Zusammenhang vor, dass die Informationen für den DPP auf offenen, interoperablen Standards basieren und über einen eindeutigen Produktidentifikator entlang der Lieferkette zugänglich sein müssen. Die AAS schafft eine technische Basis, in der die Daten für den DPP strukturiert und maschinenlesbar umgesetzt werden können, wobei die IDTA die AAS explizit als digitale Hülle positioniert, um DPP‑Informationen gemäß ESPR in Form von Submodellen bereitzustellen (Konzept DPP4.0).
Für Konstrukteure bedeutet das: Künftige Nachhaltigkeits‑, Material‑ und Produktdatenanforderungen aus der ESPR lassen sich direkt in AAS‑Teilmodellen modellieren und als DPP bereitstellen. Die Submodel-Templates liefern hierzu fertige Strukturen, in denen die für den DPP verlangten Daten maschinenlesbar und semantisch eindeutig abgelegt werden können.
Konstrukteure pflegen heute schon einen Großteil der künftig für den DPP relevanten Daten (Material, Masse, Lebensdauerannahmen, Austauschbarkeit, Dokumentation), die sich über die AAS‑Teilmodelle einmalig strukturiert hinterlegen und später für den DPP einsetzen lassen. Für Hersteller entsteht damit ein durchgängiger Pfad: Das Engineering erzeugt und pflegt AAS‑Teilmodelle und nutzt hierzu IT/Compliance, um hieraus DPP‑Instanzen zu generieren und ESPR‑Anforderungen im Markt erfüllen zu können.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel Communications Group GmbH & Co. KG, Max-Planckstr. 7-9, 97082 Würzburg einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von redaktionellen Newslettern nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung, Abschnitt Redaktionelle Newsletter.
Industrieverbände wie IDTA, VDMA und die OPC Foundation betrachten die AAS als Kerntechnologie für den DPP. Gleichwohl betonen EU‑ und Branchenpapiere, dass DPP‑Lösungen auf einem Zusammenspiel mehrerer offener Standards beruhen und daher nicht zwangsläufig auf einen einzigen Technologiepfad festgelegt sind. Für Konstrukteure ist es daher vermutlich sinnvoll, AAS-konform und zugleich GS1-/ECLASS‑kompatibel zu modellieren, statt ausschließlich auf einen Standard zu setzen.[7]