14. Aug. 2025
Data Space Konnektoren für den Austausch von Verwaltungsschalen

Sichere Datenräume für die Industrie 4.0

Als standardisiertes Datenformat hat sich in der Industrie 4.0 die Verwaltungsschale durchgesetzt. Eine Möglichkeit Daten sicher und effizient auszutauschen sind Data Spaces. Eine Kombination beider Technologien könnte zukünftig ermöglichen, Informationen bspw. zu Produkten oder Bauteilen über den gesamten Lebenszyklus und entlang der gesamten Wertschöpfungskette automatisiert auszutauschen und bereitzustellen.

Inhaltsverzeichnis

• Warum Verwaltungsschalen?
• Was sind Data Spaces?
• Wie sieht ein Ablauf eines Datenaustauschs innerhalb eines Data Space aus?
• Wie können Verwaltungsschalen in Data Spaces ausgetauscht werden?

Warum Verwaltungsschalen?

Die Verwaltungsschale (engl. „Asset Administration Shell“ oder „AAS“) ermöglicht die Implementierung von Digitalen Zwillingen, also digitalen Abbildungen und Datenspeichern für sämtliche Informationen eines bestimmten Assets. Ein Asset ist hier z. B. eine einzelne Maschine, eine gesamte Anlage oder aber auch nicht-physische Dinge, wie Prozesse oder Software – letztendlich alles, was für ein Unternehmen von Interesse sein kann. Die Verwaltungsschale ist darauf ausgelegt, die Informationen eines jeweiligen Assets über den gesamten Lebenszyklus bereitzustellen. Dies macht sie einerseits zu einem idealen Werkzeug um unternehmensintern als Datenspeicher für Produktinformationen eingesetzt zu werden, andererseits ist sie dadurch auch optimal geeignet um den von der Europäischen Union beschlossenen Digitalen Produktpass (DPP) umzusetzen.

Die Spezifikation der Verwaltungsschale wird von der Industrial Digital Twin Association (IDTA) entwickelt und beschreibt unter anderem das Metamodell und die Schnittstellen von Verwaltungsschalen.

Eine Möglichkeit Verwaltungsschalen benutzerfreundlich zu erstellen, zu speichern und zu betrachten ist die von XITASO entwickelte Open-Source-Lösung Eclipse Mnestix.

Was sind Data Spaces?

Datenräume bzw. Data Spaces bieten eine Möglichkeit einen sicheren und effizienten Datenaustausch zu realisieren. Anstelle von zentralen Datenspeichern, setzen Data Spaces auf dezentrale Dateninfrastrukturen, welche bspw. eine Region oder eine gesamte Branche umfassen können. Innerhalb eines Data Space können Teilnehmer mittels standardisierter Protokolle Daten direkt untereinander austauschen. Der Fokus liegt dabei darauf, dass der Austausch der Daten sicher erfolgt und ein Teilnehmer stets die volle Souveränität über die eigenen Daten behält. Damit die Teilnehmer von anderen Teilnehmern eines Data Space wissen können und Vertrauen zwischen den Teilnehmern herrschen kann, gibt es in jedem Data Space zudem eine zentrale Instanz, welche den Data Space betreibt. Dieser Data Space Betreiber sorgt dafür Teilnehmer im Data Space zu registrieren, es Data Providern und Data Consumern zu ermöglichen zusammenzufinden und dafür zu sorgen, Transaktionen innerhalb des Data Space für alle Beteiligten nachvollziehbar zu machen. Die Daten selbst bleiben aber stets unter den Teilnehmern eines Datenaustauschs. Data Spaces werden deshalb auch als „Federated Infrastructure“ bezeichnet.

Um einen reibungslosen Austausch der Daten ermöglichen zu können, werden die folgenden, in dem von der International Data Spaces Association (IDSA) entwickelten Referenzarchitekturmodell (RAM) spezifizierten, Komponenten benötigt:

• Connector: Der Konnektor bindet einen Teilnehmer an einen Data Space an und stellt die Schnittstelle dar, über welche sämtliche Kommunikation zu anderen Data Space Teilnehmern stattfindet.
• Identity Provider: Mithilfe des Identity Providers können die Teilnehmer eines Data Space authentifiziert werden. Während es sich beim Identity Provider um eine zentrale Data Space Komponente handelt, gibt es hierfür allerdings auch dezentrale Ansätze mithilfe von Self-Sovereign Identity (SSI).
• Metadata Broker: Der Metadata Broker ist eine zentrale Komponente, welche Informationen zu den im Data Space vorhandenen Assets zur Verfügung stellt.
• Clearing House: Die Clearing House-Komponente ist eine weitere zentrale Komponente, welche Informationen zu Transaktionen loggt, auf wessen Basis bspw. Rechnungen gestellt oder automatisierte Zahlungsabläufe angestoßen werden können.
• App Store: Über den App Store können Anwendungen zur Verfügung gestellt werden, welche einen Connector um Funktionalitäten wie bspw. Datenvorverarbeitung o. Ä. erweitern.
• Vocabulary Hub: Der Vocabulary Hub ist eine zentrale Komponente für gemeinsames Vokabular. Dieses Vokabular kann von Data Providern genutzt werden, um Metadaten zu beschreiben oder von Data Consumern genutzt werden, um Metadaten korrekt zu interpretieren.

Wie sieht ein Ablauf eines Datenaustauschs innerhalb eines Data Space aus?

Für den Austausch von Daten unter zwei Teilnehmern ist insbesondere der Data Space Connector relevant. Über diesen läuft die Kommunikation und der Austausch der Daten ab. Ein Connector besteht aus zwei Teilen: dem Control Plane und dem Data Plane.

Der Control Plane ist für die Kontrolle des Datenaustauschs verantwortlich und prüft, ob die Nutzungsbedingungen für einen Datenaustausch eingehalten werden. Außerdem kontrolliert dieser den Data Plane. Der Data Plane ist für das Übertragen der Daten verantwortlich. Eine Datenübertragung über den Data Plane kann bspw. über Streaming oder über das Anbieten eines API-Endpunkts geschehen.

Die Kommunikation zwischen zwei Teilnehmern besteht aus drei wesentlichen Schritten:

1. 1. 1. Anfrage an Consumer, welche Assets zur Verfügung stehen
      2. Contract Negotiation
      3. Datentransfer

Um herauszufinden, welche Assets ein Data Provider zur Verfügung stellt, gibt es mehrere Wege. Im einfachsten Fall können die verfügbaren Assets über einen Metadata Broker abgefragt werden. Dazu muss der Data Provider die Informationen zu seinen Assets allerdings auch dem Metadata Broker mitteilen. Alternativ können die verfügbaren Assets direkt per Anfrage an den Connector des Providers erhalten werden, sollte der Provider im Vorhinein bekannt sein. Eine weitere Möglichkeit an die verfügbaren Assets anderer Teilnehmer zu kommen ist über den Federated Catalog. Dabei werden Federated Catalog Crawler eingesetzt, um periodisch die zur Verfügung stehenden Assets anderer Teilnehmer anzufragen und in einem lokalen Cache zu speichern.

Um anschließend eine Datenübertragung einzuleiten, findet zunächst eine Contract Negotiation statt. Dazu wird basierend auf den verfügbaren Informationen eines Assets ein Angebot an den Data Provider geschickt.

Wenn das Angebot angenommen wird, kann die Datenübertragung entweder mittel push- (bspw. Streaming der Daten) oder pull-Mechanismus (Bereitstellen einer REST-Schnittstelle) gestartet werden.

Wie können Verwaltungsschalen in Data Spaces ausgetauscht werden?

In der Spezifikation für Verwaltungsschalen sind nicht nur die Struktur von Verwaltungsschalen und Teilmodellen, sondern auch die Infrastruktur und die Schnittstellen von Verwaltungsschalen und Teilmodellen definiert. Das umfasst Verwaltungsschalen- bzw. Teilmodellrepositorys, Discovery Services und Registries und die jeweils entsprechenden API-Endpunkte.

Während der AAS Dataspace for Everybody des Fraunhofer IESE bisher auf eine Lösung mit AAS Komponenten und einer zentrale Registry setzt, setzt das Tractus-X Projekt mit ihrem Digital Twin KIT auf einen alternativen Ansatz, bei welchem Komponenten aus beiden Welten kombiniert werden, um kompatibel mit der AAS Spezifikation der IDTA zu sein, zeitgleich aber auch kompatibel mit Data Spaces, welche auf der IDSA Spezifikation basieren zu sein. und somit sicher und effizient Verwaltungsschalen in einem Data Space auszutauschen. Aber wie kann das umgesetzt werden?

Für den Austausch von Verwaltungsschalen über den Data Space Connector eignet sich insbesondere der pull-Mechanismus des Data Planes. Dazu kann beim Anlegen eines Assets im Data Space der Endpunkt der Verwaltungsschale im AAS-Repository angegeben werden. Im Kontext von Data Spaces wird mit „Asset“ dabei eine Entität gemeint, welche innerhalb eines Data Spaces angeboten wird, also z. B. eine Data Addresse.

Wenn zusätzlich die ID der Verwaltungsschale als Asset ID angegeben wird, können Verwaltungsschalen problemlos anhand der AAS-ID im Data Space gefunden werden. Beim Anlegen eines Assets können über die Properties außerdem noch weitere Informationen angegeben werden. Diese eignen sich für Metainformationen zum Asset, also z. B. ob es sich bei dem Asset um eine Verwaltungsschale oder ein Teilmodell handelt, damit bei der Suche nach Assets dementsprechend gefiltert werden kann. Im Folgenden ist ein Beispiel zu sehen, wie ein solches Asset aussehen kann: