Device-Integration mit Verwaltungsschalen und Eclipse BaSyx einfach machen

Digitale Zwillinge sind eine Schlüsseltechnologie zur Zielerreichung von Industrie 4.0. Sie dienen als vereinheitlichte virtuelle Repräsentation von Assets wie Geräten, Produkten oder Sensoren und deren Eigenschaften. Die Nutzung von Konzepten wie der Verwaltungsschale (kurz: VWS) ermöglicht die Schaffung einer standardisierten Schnittstelle hin zum Digitalen Zwilling des Assets. Um dieses Ziel aber erreichen zu können, müssen die Assets mit den Verwaltungsschalen integriert sein. Dieser Blog-Post zeigt auf, wie sich die Device-Integration durch unsere am Fraunhofer IESE entwickelte Lösung Eclipse BaSyx ganz einfach und mit minimalem Programmieraufwand umsetzen lässt – und das als Open Source. Eclipse BaSyx ermöglicht dies durch die Bereitstellung von vielseitigen OTS-Komponenten.

Die Digitalisierung der Produktion und Industrie 4.0 versprechen eine Fülle von Vorteilen, wie z. B. Prozesstransparenz, die Verlässlichkeit von Lieferketten oder die effiziente Produktion kleiner Losgrößen. Bei zahlreichen Anwendungsfällen wird aber eine teilweise Integration von Assets mit ihren Digitalen Zwillingen (kurz: DZ), also ihrer virtuellen Repräsentation, vorausgesetzt. Dabei müssen einerseits Daten aus dem Shopfloor in den Digitalen Zwilling integriert werden, aber auch umgekehrt Änderungen am Digitalen Zwilling direkt wieder mit dem realen Asset synchronisiert werden. Daraus leiten sich zwei große Herausforderungen ab, die folgende Fragen aufwerfen:

• Wie lassen sich Gerätedaten mit dem Digitalen Zwilling synchronisieren?
• Wie lassen sich Daten aus dem Digitalen Zwilling wieder zurück zum realen Gerät synchronisieren?

Besonders bei der Erstellung von DZs für ältere Geräte stellen diese beiden Punkte eine Herausforderung dar, da speziell ältere Geräte oft Klemmen oder Feldbusse zur Kommunikation nutzen. Um Konnektivität zu gewährleisten, müssen verschiedene Generationen von Protokollen und Bussystemen in den DZ integriert werden. Zum Beispiel wurde der Modbus erstmals 1979 implementiert, wohingegen zukünftig Automatisierungsprotokolle wie OPC UA eine große Rolle spielen werden. Integratoren müssen bei der Erstellung eines DZ oft synchrone und asynchrone Kommunikation berücksichtigen und neben den klassischen Automatisierungsprotokollen auch weitere Protokolle wie MQTT, das zum Beispiel für OPC UA Pub/Sub eingesetzt wird, miteinbeziehen. Ebenfalls müssen Integratoren unterschiedliche Nachrichtenformate für Nutzdaten integrieren können, wie zum Beispiel JSON, XML oder auch proprietäre Binärformate.

Zwar sind beide Herausforderungen bereits heute durch intensiv getailorte Anwendungen lösbar, es entsteht dabei aber ein hoher manueller Aufwand. Der Nachteil davon liegt auf der Hand: Selten entstehen bei diesem Vorgehen wiederverwendbare Artefakte, die bei der nächsten Integration eine signifikante Beschleunigung und damit auch eine signifikante Kostenreduktion ermöglichen.

 

Bereitstellung von Off-the-Shelf-Komponenten mittels Eclipse BaSyx

Eines der Ziele von Eclipse BaSyx ist die Bereitstellung von Off-the-Shelf-Komponenten, die genau diese Herausforderung adressieren. Diese Komponenten können mit minimalem Aufwand konfiguriert und deployed werden – sprich, einfach aus dem Regal genommen und in die Anwendung gebracht werden. Ein Kernkonzept von Eclipse BaSyx ist dabei die Verwaltungsschale (VWS). Aufbauend auf dem Konzept des Digitalen Zwillings wurde von der Plattform Industrie 4.0 mit der VWS eine Spezifikation geschaffen, welche ein einheitliches Verständnis schafft und über ein definiertes Metamodell sowie Zugriffs-APIs die Interoperabilität der Implementierung des DZs garantiert.

In diesem Blog-Beitrag wird anhand eines einfachen Beispiels aufgezeigt, welchen Beitrag Eclipse BaSyx zur Device-Integration liefern kann. Durch die Bereitstellung des Beispiels als direkt ausführbarem Code bzw. als einfach startbarem docker compose file auf GitHub kann das Beispiel direkt nachvollzogen und als Blaupause für eigene Projekte genutzt werden.

 

Beispiel: Die Integration eines Heizelements in dessen Verwaltungsschale

Im Folgenden wird die Device-Integration beispielhaft anhand eines Heizelements betrachtet. Das Heizelement verfügt dabei über eine einfache Schnittstelle:

• Ein Heizsollwert kann per http/REST in Grad Fahrenheit konfiguriert werden.
• Der zuletzt konfigurierte Sollwert kann per http/REST abgefragt werden.
• Jede Sekunde wird der aktuell gemessene Temperaturwert in Grad Fahrenheit als MQTT-Event zur Verfügung gestellt.

Im ersten Schritt erfolgt die Erstellung des Digitalen Zwillings in Form der Verwaltungsschale, z. B. mit dem AASX Package Explorer. In Abbildung 1 ist eine mögliche Abbildung des Assets auf der Verwaltungsschale dargestellt. Typischerweise würde das Asset noch weitere Teilmodelle wie etwa das Digital Nameplate enthalten – aus Gründen der Übersichtlichkeit wurde darauf aber im Folgenden verzichtet.

Abbildung 1 – Verwaltungsschale für das Heizelement

Konkret beinhaltet die VWS zwei Teilmodelle:

• TemperatureSensor: Repräsentiert den Temperatursensor-Aspekt des Assets und enthält die aktuell gemessene Temperatur in Grad Celsius
• HeaterControl: Repräsentiert den Heizelement-Aspekt des Assets und bietet eine Operation zum Setzen des Heizsollwerts an. Analog dazu stellt das Teilmodell den zuletzt gesetzten Heizsollwert über ein Property bereit. Der Heizsollwert wird in diesem Beispiel in Grad Fahrenheit angegeben. Zusätzlich sind beide SubmodelElemente mit Qualifiern annotiert. Die Bedeutung dieser Qualifier wird im späteren Verlauf dieses Artikels noch erklärt.

Im Beispielszenario wird das HeaterControl-Teilmodell mit einer Applikation aus den USA integriert, weswegen der native Temperaturmesswert in Grad Fahrenheit belassen wird. Das TemperatureSensor-Teilmodell dagegen dient zur Darstellung des aktuellen Prozesses in einer Dashboard-Anwendung für den europäischen Markt, weswegen hier Daten in Grad Celsius angeboten werden.

Die definierte Verwaltungsschale kann nun in VWS-Infrastruktur geladen werden  und es entsteht die in Abbildung 2 gezeigte Architektur. Dort existiert sie allerdings im ersten Schritt losgelöst vom reellen Device. Mit Eclipse BaSyx kann nun die Datenintegration auf einfache Art und Weise erfolgen. Dafür bietet Eclipse BaSyx verschiedene Mittel, die im Folgenden genauer vorgestellt werden:

• Integration per Property-Delegation
• Integration per Operation-Delegation
• Datenintegration mit der Eclipse BaSyx DataBridge

Abbildung 2 – Vereinfachte VWS-Architektur ohne Datenintegration

 

Device-Integration per Property-Delegation

Soll ein einfacher Datenpunkt direkt, also ohne Transformation, mit einem Teilmodell integriert werden, ist die Property-Delegation ein geeigneter Ansatz. Bei diesem Integrationsmechanismus wird die Abfrage eines Propertys durch die VWS-Applikation vom VWS-Server weiterdelegiert. Der Datenpunkt wird also vom VWS-Server bei einem Asset abgefragt und an die VWS-Applikation zurückgegeben. Folglich ist diese Delegation bzw. Weiterleitung dabei voll transparent und damit für die VWS-Applikation unsichtbar. Der Vorteil ist deutlich: Änderungen an Device-Integrationen lassen sich so ohne jegliche Änderungen an den VWS-Applikationen durchführen. Somit lassen sich auch noch nachträglich Design-Entscheidungen ändern, ohne dass zusätzlicher Tailoring-Aufwand entsteht. Die aus diesem Vorgehen resultierende Architektur ist in Abbildung 3 dargestellt.

Abbildung 3 – Property-Abfrage über Property-Delegation

Wie aber ist diese Integration nun per Property-Delegation mit Eclipse BaSyx möglich? Die gute Nachricht lautet: Ganz einfach – und das ohne eine einzige Zeile Code. Die VWS-Server-Komponente von BaSyx unterstützt die Property-Delegation mit einer einfachen Konfiguration. Konkret muss zur Nutzung und Konfiguration der Property-Delegation nur der »delegatedTo«-Qualifier eines Properties gesetzt werden. In Abbildung 1 ist dieser Qualifier auf den Wert http://host.docker.internal:8082/heater/targetTemperature/last gesetzt – jede Anfrage an dieses Property wird also automatisch an die genannte URL delegiert und dadurch aufgelöst. Die Annahme hierbei ist, dass das Asset unter dem delegierten Endpunkt die Daten bereits in einem für das Teilmodell passenden Format bereitstellt. Sind Datentransformationen notwendig, dann ist die DataBridge eine sinnvolle Alternative. Was das genau bedeutet, wird im weiteren Verlauf dieses Artikels geschildert.

 

Device-Integration per Operation-Delegation

Oft bieten Assets Interaktionspunkte wie z. B. http/REST Endpunkte an, über die sich Konfigurationen vornehmen oder Aktionen auslösen lassen. Diese Endpunkte können ebenfalls über einen Delegationsmechanismus mit Teilmodellen integriert werden. Analog zur Property-Delegation bietet BaSyx mit der Operation-Delegation ein einfach zu konfigurierendes Feature, das genau diesen Use Case adressiert. Ein an den VWS-Server übermittelter Operationsaufruf kann also ebenfalls volltransparent delegiert werden. Dieses Feature ermöglicht denselben Vorteil wie die Property-Delegation: Designentscheidungen lassen sich einfach ändern, ohne eine übergeordnete Anpassung von Applikationen vornehmen zu müssen. Die Konfiguration dieses Features gestaltet sich ähnlich zur Property-Delegation:

Eine einfache Nutzung des »invocationDelegation«-Qualifiers mit der Ziel-URL als Wert reicht. In Abbildung 1 ist dieser Wert auf »http://host.docker.internal:8082/heater/setTargetTemperature/invoke« gesetzt – jeder Aufruf dieser Operation wird also automatisch an die genannte URL delegiert. Die sich aus diesem Feature ergebende Architektur ist in Abbildung 4 veranschaulicht.

Abbildung 4 – Operationsaufruf über Operation-Delegation

 

Device-Integration mit der Eclipse BaSyx DataBridge

Wie bereits im Kapitel »Integration per Property-Delegation« angesprochen, eignet sich der dort aufzeigte Integrationsmechanismus vor allem für einfache Integrationen. Sind komplexe Transformationen von Datenpunkten notwendig, eignet er sich nicht. Aber auch in diesen Szenarien kann BaSyx unterstützen: Die Lösung liegt in der BaSyx DataBridge.

Bei der BaSyx DataBridge handelt es sich um eine einfach nutzbare Off-the-Shelf-Komponente, die als Docker Image auf DockerHub zu finden ist. Sie unterstützt die Datenintegration mit einer Vielzahl an Protokollen wie OPC UA, http/REST, MQTT, ActiveMQ oder auch Kafka. Zusätzlich ermöglicht sie die Transformation der über die Protokolle bereitgestellten Daten. Beispielsweise können JSON-Dateien über einfache Ausdrücke in JSONata – eine Transformationssprache für JSON – umgerechnet werden.

Konkret unterstützt die BaSyx DataBridge zwei Integrationsmuster:

• Zyklische Integration: Daten werden in regelmäßigen Abständen bzw. eventgetrieben abgefragt, transformiert und in die VWS integriert (-> Push).
• On-Demand Delegation: Auf Anfrage des VWS-Servers hin wird ein Datenpunkt abgefragt, transformiert und zurückgegeben (-> Pull).

Abbildung 5 stellt diese zwei Integrationsmuster gegenüber. Hauptunterschied hierbei ist der Kontrollfluss zwischen dem VWS-Server und der DataBridge.

 

Abbildung 5 – Gegenüberstellung der Integrationsmuster (a) Delegation und (b) zyklisches Update

Im Beispiel des Heizelements kommt die DataBridge im Zuge der sekündlichen Temperaturmesswertabfrage und der entsprechenden Transformation von Grad Fahrenheit in Grad Celsius sowie der Datenablage im »currentTemperature«-Property zum Einsatz. Für diese Integration sind verschiedene Beschreibungen als Konfiguration der DataBridge notwendig. Folgende Beschreibungen sind dabei am wichtigsten:

• Beschreibung des MQTT-Endpunkts, der den Temperaturwert bereitstellt
• Beschreibung der Datentransformation in JSONata, die den Temperaturwert selektiert und in Grad Celsius überführt
• Beschreibung des Teilmodell-Endpunkts und des Propertys, in dem die Daten abgelegt werden sollen
• Zusammenführung der einzelnen Elemente zu einer Datenintegrationsroute

Im Folgenden werden die unterschiedlichen Konfigurationen aufgezeigt. Diese sind analog auch auf GitHub verfügbar.

Der MQTT-Endpunkt wird wie folgt beschrieben:

{

„uniqueId“: „temperatureSensor“,

„serverUrl“: „host.docker.internal“,

„serverPort“: 1884,

„topic“: „heater/temperature“

}

Der uniqueId-Eintrag spezifiziert den Namen des Datenverarbeitungsknotens, der in der weiteren Integration genutzt wird. serverURL & serverPort beschreiben den Zugriffspunkt, unter dem der MQTT-Broker auffindbar ist. Der Eintrag topic beschreibt das MQTT-Topic, unter dem die Temperaturdaten veröffentlicht werden.

Im nächsten Schritt wird die Datentransformation beschrieben. Die per MQTT versendeten JSON-Nachrichten sehen beispielsweise wie folgt aus:

{

„temperature“: 32,

„timestamp“: 1674025471

}

 

Um die Temperatur zu selektieren und von Grad Fahrenheit in Grad Celsius umzurechnen, ist ein anschließender JSONata-Ausdruck notwendig:

 

$floor((temperature – 32) * 5 / 9)

 

$floor ist dabei eine JSONata-Funktion, die den errechneten Wert auf die nächste Ganzzahl abrundet.

 

Die Datei mit diesem JSONata-Ausdruck wird über folgende Konfiguration mit einem Routen-Eintrag verknüpft:

[

{

„uniqueId“: „temperatureTransformer“,

„queryPath“: „temperatureTransformer.jsonata“,

„inputType“: „JsonString“,

„outputType“: „JsonString“

}

]

 

Analog zur Endpunktbeschreibung von MQTT ist auch hier die uniqueId der Name des Datenverarbeitungsknoten. queryPath spezifiziert den Dateinamen, unter dem der vorherige JSONata-Ausdruck abgelegt ist. Der Eintrag JsonString für inputType & outputType gibt an, dass ein JSON verarbeitet werden soll.

Der nächste Schritt beschreibt den Teilmodell-Endpunkt und das Ziel-Property über folgende Konfiguration:

[

{

„uniqueId“: „TemperatureSubmodel“,

„submodelEndpoint „: „http://host.docker.internal:4001/aasServer/shells/heaterAAS/aas/submodels/ temperatureSensor /submodel“,

„idShortPath“: „currentTemperature“

}

]

 

Der uniqueId-Eintrag hat auch hier dieselbe Bedeutung wie in den obigen Beschreibungen. Über submodelEndpoint wird die URL des Teilmodell-Endpunkts angegeben, der idShortPath-Eintrag verweist auf das konkret zu befüllende Property.

Final kombiniert eine weitere Konfiguration die einzelnen Datenverarbeitungsknoten zu einer Route. Dies geschieht wie folgt:

 

[

{

„datasource“: „temperatureSensor“,

„transformers“: [„temperatureTransformer“],

„datasinks“: [„TemperatureSubmodel“],

„trigger“: „event“

}

]

 

Die DataBridge erstellt dann anhand der verschiedenen uniqueIds die Route von der datasource über die transformers zum datasink. Da es sich um eine eventgetriebene Route handelt, ist als trigger der Wert event angegeben. Auf GitHub finden sich auch Beispiele für eine zeitgetriebene Integration und eine delegierte Integration mittels der DataBridge.

 

Einfache Device-Integration mittels der BaSyx Off-the-Shelf-Komponenten

Wurden die zuvor genannten Konfigurationen vorgenommen, steht dem Start der VWS-Infrastruktur (sprich VWS Server, VWS Registry, VWS GUI), der DataBridge sowie des simulierten Assets nichts mehr im Wege. Im Beispiel lässt sich dafür docker compose einsetzen. Mehr Infos dazu stehen ebenfalls über GitHub bereit.

Nach dem Start der kompletten Container-Landschaft ergibt sich das in Abbildung 1 dargestellte Gesamtsystem.

Abbildung 6 – Containerlandschaft der Device-Integration

 

Das VWS-GUI ist danach per http://localhost:3000 im Browser aufrufbar und in Abbildung 7 dargestellt. Nach Konfiguration der Registry-URL als http://localhost:4000/registry sowie Aktivierung des Auto-Syncs im GUI per Button oben rechts ist ein direkter Zugriff auf die Verwaltungsschale mit ihren Teilmodellen möglich.

Abbildung 7 – Überblick über das VWS GUI

Über die setTargetTemperature-Operation im heaterControl-Teilmodell kann nun eine Zieltemperatur in Grad Fahrenheit eingestellt werden, die danach im lastTargetTemperature-Property abrufbar ist. Durch Auswahl des currentTemperature-Property kann per Mausklick im temperatureSensor-Teilmodell live verfolgt werden, wie die Temperatur eingeregelt wird.

 

Zusammenfassung & Ausblick: Nutzen und Zukunft der BaSyx DataBridge

Das in diesem Blog-Beitrag gezeigte Beispiel veranschaulicht, wie Eclipse BaSyx und die BaSyx DataBridge die Device-Integration mittels Verwaltungsschalen enorm vereinfachen können – und das ganz ohne jegliche Programmierkenntnisse. Über die Bereitstellung der DataBridge als Docker Image lässt sich die gezeigte Device-Integration ganz einfach nachvollziehen und als Blaupause für eigene Use Cases nutzen. Zusätzlich zeigt das Beispiel auf, welche weiteren Mehrwerte die OTS-Komponenten von BaSyx bieten.

Zukünftige Updates der DataBridge werden weitere Protokolle integrieren, wie z.B. Automatisierungsbusse. Zusätzlich wird die Spezifikation des Asset Interfaces Description Teilmodells der IDTA nach Release zur Konfiguration der DataBridge genutzt. In dieser Spezifikation werden zukünftig mehrere Teilmodelle definiert, die die Kommunkationsendpunkte sowie notwendige Datentransformationen der Assets (wie etwa Geräte) beschreiben.

Die verschiedenen Features sowie die enge Verzahnung der einzelnen BaSyx-Komponenten ermöglichen eine schnelle Umsetzung von Use Cases. BaSyx erlaubt es seinen Anwender*innen somit also, den Fokus auf die Mehrwerte ihrer Use Cases zu richten – die Infrastrukturarbeit übernimmt BaSyx.