Der digitale Zwilling zählt seit Jahren zu den zentralen Themen der Automatisierungstechnik. Gemeint ist gemäß der Publikation "Die Rolle der Industrie 4.0 ‚Verwaltungsschale‘ und des ‚digitalen Zwillings‘ im Lebenszyklus einer Anlage: Navigationshilfe" [1] die Verwaltungsschale eines Assets (Asset Administration Shell, AAS). Ein Asset kann dabei eine Einzelkomponente, ein Feldgerät, eine Anlage oder Software sein. Zu den derzeit häufig diskutierten Anwendungsfällen der AAS gehören:

• das digitale Typenschild (Digital Nameplate),
• die papierlose Dokumentation durch Ablage digitaler Unterlagen in der AAS,
• die Bereitstellung technischer Produktmerkmale in der AAS sowie
• die Bereitstellung des CO₂-Fußabdrucks in der AAS.

Darüber hinaus können digitale Zwillinge ein durchgängiges Anlagen-Engineering in der industriellen Fertigung unterstützen und damit die Effizienz im Engineering von Produktionsanlagen erhöhen.

Der vorliegende Beitrag behandelt insbesondere das Software-Management, also das Speichern und Verwalten mit AAS sowie das Verteilen von Software über OPC UA DI. Dazu führt der Artikel zunächst in die AAS-Technologie, insbesondere in das Teilmodell "Software Nameplate", sowie in das "Software Update Model" des OPC-UA-DI-Standards ein. Anschließend wird gezeigt, wie sich Software in AAS-Software-Repositorys ablegen, versionieren und referenzieren lässt. Danach wird erläutert, wie Software aus Repositorys abgerufen und über den OPC-UA-DI-Standard auf Geräte geladen werden kann. Abschließend wird bewertet, inwieweit ein herstellerneutrales ganzheitliches Software-Management mit AAS und OPC UA derzeit realisierbar ist.

AAS-Informationen liegen in Teilmodellen vor

Die AAS-Technologie wird von der Industrial Digital Twin Association e.V. (IDTA) betreut und weiterentwickelt. Das allgemeine AAS-Metamodell wurde inzwischen in die Norm IEC 63278-1:2023[2] überführt. Asset Administration Shells unterscheiden – angelehnt an eine Klassen-Objekt-Beziehung – zwischen Typ- und Instanz-AAS. Eine Typ-AAS repräsentiert den Typ eines Assets. Die Instanz-AAS steht für ein konkretes Asset. Sie wird bei der Herstellung erzeugt und gegebenenfalls von einer Typ-AAS abgeleitet.

Die eigentlichen Informationen einer Asset Administration Shell liegen in Teilmodellen (Submodels) vor. Stand Juli 2025 listet die IDTA insgesamt 98 veröffentlichte oder in Ausarbeitung befindliche Teilmodelle auf. Diese decken unter anderem die genannten Basisanwendungsfälle ab. Auf Grundlage des vordefinierten Submodels "Hierarchical Structures" [3] lassen sich hierarchische Strukturen der AAS als Referenzlisten auf unterlagerte AAS abbilden. Asset Administration Shells werden in AAS-Repositorys auf AAS-Servern gehostet. Der Zugriff erfolgt über eine REST-API. Sicherheitsmechanismen wie ein feingranulares Rechtemanagement sind bereits Bestandteil der AAS-Technologie. Einzelgeräte und Komponenten verfügen produktionsseitig über einen QR-Code[4], der auf die jeweilige AAS verlinkt.

Software-Pakete können im Teilmodell hinterlegt werden

Ziel des Teilmodells "Software Nameplate"[5] ist es, softwarebezogene Informationen standardisiert und interoperabel bereitzustellen. Das Teilmodell besteht aus zwei Aspekten: 

• dem SoftwareNameplateType, der typbezogene Eigenschaften wie Produktbezeichnung, Version, Herstellerinformationen oder Installationsquelle beschreibt,
• der SoftwareNameplateInstance, die instanzspezifische Details wie Seriennummer, Installationspfad, verwendete Architektur und Kontaktinformationen umfasst.

Software-Pakete können direkt im Typ-Aspekt des Teilmodells hinterlegt werden. Alternativ ermöglicht das Teilmodell die Referenzierung externer Bezugsquellen, beispielsweise eines nachgelagerten Software-Repositorys. Dabei werden Informationen zur Download-URL hinterlegt.

Software Update Model definiert einheitliche Download-Schnittstelle

Beim OPC-UA-DI-Standard (Device Integration)^[6] handelt es sich um eine Erweiterung des OPC-UA-Standards zur einheitlichen Modellierung und Integration von Geräten in Automatisierungssysteme. Der Standard definiert Informationsmodelle und Schnittstellen, um Geräte unterschiedlicher Hersteller interoperabel darzustellen und anzusteuern. Der DI-Standard bildet die Grundlage für weitere Spezifikationen wie "OPC UA for Profinet", "OPC UA for IO-Link" oder "OPC UA for PLCopen".

Die DI-Spezifikation beschreibt drei aufeinander aufbauende Modelle: das ‚(Base) Device Model‘, das ‚Device Communication Model‘ und das ‚Device Integration Host Model‘. Zusätzlich sind die Add-ins ‚Locking Model‘ und ‚Software Update Model‘ definiert.

Bild 1: Das Software Update Model OPC-UA-DI im Adressraum einer PLCnext Control von Phoenix Contact. © Phoenix Contact

Das Software Update Model definiert eine einheitliche Schnittstelle, um Software, zum Beispiel Firmware, über OPC UA auf ein Gerät zu übertragen. Download und Installation können dabei voneinander getrennt erfolgen. Firmware-Updates lassen sich so zunächst auf mehrere Geräte ausrollen und zu einem späteren Zeitpunkt auf allen Geräten gleichzeitig installieren. Um die Funktion eines Geräts bei einem fehlgeschlagenen Update sicherzustellen, kann über das Modell eine Rückfallversion definiert werden. Bild 1 zeigt das Software Update Model im Adressraum des OPC-UA-Servers einer Steuerung von Phoenix Contact.

Software-Repositorys für die Nachverfolgung von Abhängigkeiten Bild 2 zeigt, wie sich Software-Repositorys mithilfe der Teilmodelle "Hierarchical Structures" und "Software Nameplate" umsetzen lassen. Das Repository kann dabei entweder ein AAS-Server oder eine Auflistung der AAS einzelner Software-Module sein.