Mit dem Digitalen Produktpass (DPP) entstehen neue Anforderungen an die Bereitstellung von Produktinformationen. Gleichzeitig stellt sich für viele Unternehmen die Frage, wie eine technische Grundlage aussehen muss, die nicht nur heutige Vorgaben erfüllt, sondern auch zukünftige Entwicklungen berücksichtigt.
Der Digitale Produktpass ist dabei keine eigenständige Produktdatenbasis. Er stellt die Informationen bereit, die für einen bestimmten regulatorischen oder fachlichen Zweck erforderlich sind. Unternehmen benötigen jedoch deutlich mehr Produktinformationen, die über den gesamten Produktlebenszyklus hinweg aus unterschiedlichen Quellsystemen zusammengeführt und für verschiedene Anwendungsfälle genutzt werden.
Genau dafür wurde die Asset Administration Shell (AAS) entwickelt. Sie bildet den standardisierten Digitalen Zwilling eines Assets und schafft eine einheitliche Struktur für Produktinformationen. Dadurch entsteht eine gemeinsame Grundlage, aus der unterschiedliche Anwendungsfälle bedient werden können – darunter auch der Digitale Produktpass. Die AAS ist dabei nicht mit dem vollständigen DPP-System gleichzusetzen. Sie schafft die standardisierte und semantische Grundlage für die Produktinformationen. Für eine vollständige DPP-Lösung müssen zusätzlich unter anderem Produktidentifikation und Data Carrier, Zugriffsrechte, Registrierung, dauerhafte Verfügbarkeit und die konkreten Anforderungen der jeweiligen Produktregulierung berücksichtigt werden.
Der Digitale Produktpass beschreibt, welche Informationen für einen bestimmten regulatorischen oder fachlichen Zweck bereitgestellt werden müssen. Er bildet damit eine definierte Sicht auf ein Produkt. Der Digitale Zwilling verfolgt dagegen einen umfassenderen Ansatz. Er führt Informationen aus unterschiedlichen Quellen zusammen und stellt sie über den gesamten Produktlebenszyklus hinweg bereit.
Genau diesem Prinzip folgt die Asset Administration Shell. Sie organisiert Produktinformationen in standardisierten Submodellen und bildet den Digitalen Zwilling eines Assets. Für den Digitalen Produktpass werden daraus die jeweils benötigten Informationen bereitgestellt, während weitere Daten beispielsweise für Service, technische Dokumentation oder andere digitale Anwendungen verfügbar bleiben.
Dieses Architekturprinzip ist aus anderen Informationssystemen bekannt. Ein ERP-System speichert Informationen ebenfalls nicht als Geschäftsbericht oder Rechnung, sondern verwaltet strukturierte Daten, aus denen unterschiedliche Auswertungen entstehen. Mit der Asset Administration Shell verhält es sich ähnlich.
| Digitaler Produktpass | Digitaler Zwilling mit AAS |
|---|---|
| Definierte Sicht | Vollständiges Produktmodell |
| Regulatorischer Fokus | Gesamter Lebenszyklus |
| Enthält ausgewählte Informationen | Enthält Informationen aus vielen Quellen |
| Ein Anwendungsfall | Grundlage für viele Anwendungsfälle |
In der industriellen Praxis sollte daraus kein künstlicher Wettbewerb zwischen Asset Administration Shell und OPC UA entstehen. Beide Technologien verfolgen unterschiedliche Ziele und ergänzen sich innerhalb einer gemeinsamen Architektur.
OPC UA verfügt über etablierte Stärken bei der sicheren OT-Kommunikation, der Anbindung von Maschinen und etablierten Informationsmodellen. Die Asset Administration Shell ergänzt diesen Ansatz um einen standardisierten Digitalen Zwilling mit konsequentem Lebenszyklusbezug und fachlich strukturierten Submodellen.
Beide Technologien können daher Teil derselben Architektur sein. Produktions- und Gerätedaten können über OPC UA bereitgestellt und in den Digitalen Zwilling eingebunden werden. Die Asset Administration Shell strukturiert diese Informationen gemeinsam mit Daten aus ERP-, PLM- oder PDM-Systemen, technischer Dokumentation und weiteren Quellen. Aus dieser gemeinsamen Datenbasis kann anschließend die für den Digitalen Produktpass benötigte Sicht erzeugt und über standardisierte Schnittstellen oder Datenräume bereitgestellt werden.
Diese Kombination entspricht auch dem erklärten Ziel der beteiligten Standardisierungsorganisationen: systemagnostische, herstellerunabhängige und interoperable DPP-Lösungen. Für Unternehmen steht deshalb weniger die Entscheidung zwischen einzelnen Technologien im Vordergrund. Entscheidend ist eine Gesamtarchitektur, die Datenquellen, semantische Produktinformationen und die regulatorische Bereitstellung sinnvoll miteinander verbindet.
|
Jetzt kostenlos herunterladen |
Datenquellen und Datenqualität klären
Der erste Schritt besteht darin, Transparenz über die vorhandenen Produktdaten zu schaffen. Unternehmen sollten prüfen, welche der für den Digitalen Produktpass benötigten Informationen bereits in bestehenden Systemen wie ERP, PLM, PIM, Dokumentations- oder Lieferantensystemen verfügbar sind. Gleichzeitig sollte bewertet werden, ob diese Daten vollständig, aktuell und in ausreichender Qualität vorliegen oder ob Lücken geschlossen werden müssen.
AAS- und DPP-Architektur festlegen
Im nächsten Schritt wird die technische Grundlage definiert. Dazu gehört die Festlegung, welche AAS-Submodelle verwendet werden, welche Identifikatoren zum Einsatz kommen und wie die Daten bereitgestellt werden. Ebenso sollten Schnittstellen, Zugriffsrechte und Bereitstellungsmechanismen frühzeitig geplant werden, damit die Informationen standardisiert und interoperabel verfügbar sind.
Mit einem konkreten Produktszenario starten
Anstatt den Digitalen Produktpass sofort für das gesamte Produktportfolio einzuführen, empfiehlt sich ein Pilotprojekt mit einem klar abgegrenzten Produktszenario. So können die relevanten Daten automatisiert in AAS-Strukturen überführt und die Bereitstellung des Digitalen Produktpasses unter realen Bedingungen getestet werden. Die dabei gewonnenen Erfahrungen bilden eine solide Grundlage für die schrittweise Skalierung auf weitere Produkte und Produktgruppen.
Der Digitale Produktpass wird sich in den kommenden Jahren weiterentwickeln. Datenanforderungen werden präzisiert, neue Produktgruppen kommen hinzu und technische Vorgaben können sich verändern.
Unternehmen benötigen deshalb keine Architektur für den heutigen Digitalen Produktpass, sondern eine Architektur, die neue Anforderungen aufnehmen kann. Genau dafür schafft die Asset Administration Shell eine standardisierte Grundlage.
Die entscheidende Frage lautet daher nicht, wie der heutige Digitale Produktpass umgesetzt wird. Entscheidend ist, ob die gewählte Architektur auch zukünftige Anforderungen aufnehmen kann, ohne wieder bei null zu beginnen.
Über den Autor:
|
Christian Günther
|
|