Besonders bei der Erstellung von DZs f\u00fcr \u00e4ltere Ger\u00e4te stellen diese beiden Punkte eine Herausforderung dar, da speziell \u00e4ltere Ger\u00e4te oft Klemmen oder Feldbusse zur Kommunikation nutzen. Um Konnektivit\u00e4t zu gew\u00e4hrleisten, m\u00fcssen verschiedene Generationen von Protokollen und Bussystemen in den DZ integriert werden. Zum Beispiel wurde der Modbus erstmals 1979 implementiert, wohingegen zuk\u00fcnftig Automatisierungsprotokolle wie OPC UA eine gro\u00dfe Rolle spielen werden. Integratoren m\u00fcssen bei der Erstellung eines DZ oft synchrone und asynchrone Kommunikation ber\u00fccksichtigen und neben den klassischen Automatisierungsprotokollen auch weitere Protokolle wie MQTT, das zum Beispiel f\u00fcr OPC UA Pub\/Sub eingesetzt wird, miteinbeziehen. Ebenfalls m\u00fcssen Integratoren unterschiedliche Nachrichtenformate f\u00fcr Nutzdaten integrieren k\u00f6nnen, wie zum Beispiel JSON, XML oder auch propriet\u00e4re Bin\u00e4rformate.<\/p>\n
Zwar sind beide Herausforderungen bereits heute durch intensiv getailorte Anwendungen l\u00f6sbar, 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\u00e4chsten Integration eine signifikante Beschleunigung und damit auch eine signifikante Kostenreduktion erm\u00f6glichen.<\/p>\n
<\/p>\n
Bereitstellung von Off-the-Shelf-Komponenten mittels Eclipse BaSyx<\/h2>\n
Eines der Ziele von Eclipse BaSyx ist die Bereitstellung von Off-the-Shelf-Komponenten, die genau diese Herausforderung adressieren. Diese Komponenten k\u00f6nnen mit minimalem Aufwand konfiguriert und deployed werden \u2013 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\u00e4ndnis schafft und \u00fcber ein definiertes Metamodell sowie Zugriffs-APIs die Interoperabilit\u00e4t der Implementierung des DZs garantiert.<\/p>\n
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\u00fchrbarem Code bzw. als einfach startbarem docker compose file<\/em> auf GitHub<\/a> kann das Beispiel direkt nachvollzogen und als Blaupause f\u00fcr eigene Projekte genutzt werden.<\/p>\n <\/p>\n Im Folgenden wird die Device-Integration beispielhaft anhand eines Heizelements betrachtet. Das Heizelement verf\u00fcgt dabei \u00fcber eine einfache Schnittstelle:<\/p>\n Im ersten Schritt erfolgt die Erstellung des Digitalen Zwillings in Form der Verwaltungsschale, z. B. mit dem AASX Package Explorer<\/a>. In Abbildung 1 ist eine m\u00f6gliche Abbildung des Assets auf der Verwaltungsschale dargestellt. Typischerweise w\u00fcrde das Asset noch weitere Teilmodelle wie etwa das Digital Nameplate<\/a> enthalten \u2013 aus Gr\u00fcnden der \u00dcbersichtlichkeit wurde darauf aber im Folgenden verzichtet.<\/p>\n Abbildung 1 – Verwaltungsschale f\u00fcr das Heizelement<\/p>\n Konkret beinhaltet die VWS zwei Teilmodelle:<\/p>\n 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\u00fcr den europ\u00e4ischen Markt, weswegen hier Daten in Grad Celsius angeboten werden.<\/p>\n Die definierte Verwaltungsschale kann nun in VWS-Infrastruktur<\/a> geladen werden\u00a0 und es entsteht die in Abbildung 2 gezeigte Architektur. Dort existiert sie allerdings im ersten Schritt losgel\u00f6st vom reellen Device. Mit Eclipse BaSyx kann nun die Datenintegration auf einfache Art und Weise erfolgen. Daf\u00fcr bietet Eclipse BaSyx verschiedene Mittel, die im Folgenden genauer vorgestellt werden:<\/p>\n Abbildung 2 – Vereinfachte VWS-Architektur ohne Datenintegration<\/p>\n <\/p>\n 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\u00fcckgegeben. Folglich ist diese Delegation bzw. Weiterleitung dabei voll transparent und damit f\u00fcr die VWS-Applikation unsichtbar. Der Vorteil ist deutlich: \u00c4nderungen an Device-Integrationen lassen sich so ohne jegliche \u00c4nderungen an den VWS-Applikationen durchf\u00fchren. Somit lassen sich auch noch nachtr\u00e4glich Design-Entscheidungen \u00e4ndern, ohne dass zus\u00e4tzlicher Tailoring-Aufwand entsteht. Die aus diesem Vorgehen resultierende Architektur ist in Abbildung 3 dargestellt.<\/p>\n Abbildung 3 – Property-Abfrage \u00fcber Property-Delegation<\/p>\n Wie aber ist diese Integration nun per Property-Delegation mit Eclipse BaSyx m\u00f6glich? Die gute Nachricht lautet: Ganz einfach \u2013 und das ohne eine einzige Zeile Code. Die VWS-Server-Komponente<\/a> von BaSyx unterst\u00fctzt die Property-Delegation<\/a> mit einer einfachen Konfiguration. Konkret muss zur Nutzung und Konfiguration der Property-Delegation nur der \u00bbdelegatedTo\u00ab-Qualifier eines Properties gesetzt werden. In Abbildung 1 ist dieser Qualifier auf den Wert http:\/\/host.docker.internal:8082\/heater\/targetTemperature\/last<\/a> gesetzt \u2013 jede Anfrage an dieses Property wird also automatisch an die genannte URL delegiert und dadurch aufgel\u00f6st. Die Annahme hierbei ist, dass das Asset unter dem delegierten Endpunkt die Daten bereits in einem f\u00fcr 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.<\/p>\n <\/p>\n Oft bieten Assets Interaktionspunkte wie z. B. http\/REST Endpunkte an, \u00fcber die sich Konfigurationen vornehmen oder Aktionen ausl\u00f6sen lassen. Diese Endpunkte k\u00f6nnen ebenfalls \u00fcber einen Delegationsmechanismus mit Teilmodellen integriert werden. Analog zur Property-Delegation bietet BaSyx mit der Operation-Delegation<\/a> ein einfach zu konfigurierendes Feature, das genau diesen Use Case adressiert. Ein an den VWS-Server \u00fcbermittelter Operationsaufruf kann also ebenfalls volltransparent delegiert werden. Dieses Feature erm\u00f6glicht denselben Vorteil wie die Property-Delegation: Designentscheidungen lassen sich einfach \u00e4ndern, ohne eine \u00fcbergeordnete Anpassung von Applikationen vornehmen zu m\u00fcssen. Die Konfiguration dieses Features gestaltet sich \u00e4hnlich zur Property-Delegation:<\/p>\n Eine einfache Nutzung des \u00bbinvocationDelegation\u00ab-Qualifiers mit der Ziel-URL als Wert reicht. In Abbildung 1 ist dieser Wert auf \u00bbhttp:\/\/host.docker.internal:8082\/heater\/setTargetTemperature\/invoke<\/a>\u00ab gesetzt \u2013 jeder Aufruf dieser Operation wird also automatisch an die genannte URL delegiert. Die sich aus diesem Feature ergebende Architektur ist in Abbildung 4 veranschaulicht.<\/p>\n Abbildung 4 \u2013 Operationsaufruf \u00fcber Operation-Delegation<\/p>\n <\/p>\n Wie bereits im Kapitel \u00bbIntegration per Property-Delegation\u00ab angesprochen, eignet sich der dort aufzeigte Integrationsmechanismus vor allem f\u00fcr einfache Integrationen. Sind komplexe Transformationen von Datenpunkten notwendig, eignet er sich nicht. Aber auch in diesen Szenarien kann BaSyx unterst\u00fctzen: Die L\u00f6sung liegt in der BaSyx DataBridge<\/a>.<\/p>\n Bei der BaSyx DataBridge handelt es sich um eine einfach nutzbare Off-the-Shelf-Komponente, die als Docker Image auf DockerHub<\/a> zu finden ist. Sie unterst\u00fctzt die Datenintegration mit einer Vielzahl an Protokollen wie OPC UA, http\/REST, MQTT, ActiveMQ oder auch Kafka. Zus\u00e4tzlich erm\u00f6glicht sie die Transformation der \u00fcber die Protokolle bereitgestellten Daten. Beispielsweise k\u00f6nnen JSON-Dateien \u00fcber einfache Ausdr\u00fccke in JSONata<\/a> \u2013 eine Transformationssprache f\u00fcr JSON \u2013 umgerechnet werden.<\/p>\n Konkret unterst\u00fctzt die BaSyx DataBridge zwei Integrationsmuster:<\/p>\n Abbildung 5 stellt diese zwei Integrationsmuster gegen\u00fcber. Hauptunterschied hierbei ist der Kontrollfluss zwischen dem VWS-Server und der DataBridge.<\/p>\n <\/p>\n Abbildung 5 – Gegen\u00fcberstellung der Integrationsmuster (a) Delegation und (b) zyklisches Update<\/p>\n Im Beispiel des Heizelements kommt die DataBridge im Zuge der sek\u00fcndlichen Temperaturmesswertabfrage und der entsprechenden Transformation von Grad Fahrenheit in Grad Celsius sowie der Datenablage im \u00bbcurrentTemperature\u00ab-Property zum Einsatz. F\u00fcr diese Integration sind verschiedene Beschreibungen als Konfiguration der DataBridge notwendig. Folgende Beschreibungen sind dabei am wichtigsten:<\/p>\n Im Folgenden werden die unterschiedlichen Konfigurationen aufgezeigt. Diese sind analog auch auf GitHub<\/a> verf\u00fcgbar.<\/p>\n Der MQTT-Endpunkt wird wie folgt beschrieben:<\/p>\n {<\/em><\/p>\n „uniqueId“: „temperatureSensor“,<\/em><\/p>\n „serverUrl“: „host.docker.internal“,<\/em><\/p>\n „serverPort“: 1884,<\/em><\/p>\n „topic“: „heater\/temperature“<\/em><\/p>\n }<\/em><\/p>\n Der uniqueId<\/em>-Eintrag spezifiziert den Namen des Datenverarbeitungsknotens, der in der weiteren Integration genutzt wird. serverURL <\/em>& serverPort<\/em> beschreiben den Zugriffspunkt, unter dem der MQTT-Broker auffindbar ist. Der Eintrag topic<\/em> beschreibt das MQTT-Topic, unter dem die Temperaturdaten ver\u00f6ffentlicht werden.<\/p>\n Im n\u00e4chsten Schritt wird die Datentransformation beschrieben. Die per MQTT versendeten JSON-Nachrichten sehen beispielsweise wie folgt aus:<\/p>\n {<\/em><\/p>\n „temperature“: 32,<\/em><\/p>\n „timestamp“: 1674025471<\/em><\/p>\n }<\/em><\/p>\n <\/p>\n Um die Temperatur zu selektieren und von Grad Fahrenheit in Grad Celsius umzurechnen, ist ein anschlie\u00dfender JSONata-Ausdruck notwendig:<\/p>\n <\/p>\n $floor((temperature – 32) * 5 \/ 9)<\/em><\/p>\n <\/p>\n $floor<\/em> ist dabei eine JSONata-Funktion, die den errechneten Wert auf die n\u00e4chste Ganzzahl abrundet.<\/p>\n <\/p>\n Die Datei mit diesem JSONata-Ausdruck wird \u00fcber folgende Konfiguration mit einem Routen-Eintrag verkn\u00fcpft:<\/p>\n [<\/em><\/p>\n {<\/em><\/p>\n „uniqueId“: „temperatureTransformer“,<\/em><\/p>\n „queryPath“: „temperatureTransformer.jsonata“,<\/em><\/p>\n „inputType“: „JsonString“,<\/em><\/p>\n „outputType“: „JsonString“<\/em><\/p>\n }<\/em><\/p>\n ]<\/em><\/p>\n <\/p>\n Analog zur Endpunktbeschreibung von MQTT ist auch hier die uniqueId<\/em> der Name des Datenverarbeitungsknoten. queryPath<\/em> spezifiziert den Dateinamen, unter dem der vorherige JSONata-Ausdruck abgelegt ist. Der Eintrag JsonString <\/em>f\u00fcr inputType<\/em> & outputType <\/em>gibt an, dass ein JSON verarbeitet werden soll.<\/p>\n Der n\u00e4chste Schritt beschreibt den Teilmodell-Endpunkt und das Ziel-Property \u00fcber folgende Konfiguration:<\/p>\n [<\/em><\/p>\n {<\/em><\/p>\n „uniqueId“: „TemperatureSubmodel“,<\/em><\/p>\n „submodelEndpoint „: „http:\/\/host.docker.internal:4001\/aasServer\/shells\/heaterAAS\/aas\/submodels\/ temperatureSensor \/submodel“,<\/em><\/p>\n „idShortPath“: „currentTemperature“<\/em><\/p>\n }<\/em><\/p>\n ]<\/em><\/p>\n <\/p>\n Der uniqueId<\/em>-Eintrag hat auch hier dieselbe Bedeutung wie in den obigen Beschreibungen. \u00dcber submodelEndpoint <\/em>wird die URL des Teilmodell-Endpunkts angegeben, der idShortPath<\/em>-Eintrag verweist auf das konkret zu bef\u00fcllende Property.<\/p>\n Final kombiniert eine weitere Konfiguration die einzelnen Datenverarbeitungsknoten zu einer Route. Dies geschieht wie folgt:<\/p>\n <\/p>\n [<\/em><\/p>\n {<\/em><\/p>\n „datasource“: „temperatureSensor“,<\/em><\/p>\n „transformers“: [„temperatureTransformer“],<\/em><\/p>\n „datasinks“: [„TemperatureSubmodel“],<\/em><\/p>\n „trigger“: „event“<\/em><\/p>\n }<\/em><\/p>\n ]<\/em><\/p>\n <\/p>\n Die DataBridge erstellt dann anhand der verschiedenen uniqueIds <\/em>die Route von der datasource <\/em>\u00fcber die transformers <\/em>zum datasink. <\/em>Da es sich um eine eventgetriebene Route handelt, ist als trigger <\/em>der Wert event <\/em>angegeben. Auf GitHub finden sich auch Beispiele f\u00fcr eine zeitgetriebene Integration<\/a> und eine delegierte<\/a> Integration mittels der DataBridge.<\/p>\n <\/p>\n 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\u00e4sst sich daf\u00fcr docker compose<\/em> einsetzen. Mehr Infos dazu stehen ebenfalls \u00fcber GitHub bereit.<\/p>\n Nach dem Start der kompletten Container-Landschaft ergibt sich das in Abbildung 1 dargestellte Gesamtsystem.<\/p>\n Abbildung 6 – Containerlandschaft der Device-Integration<\/p>\n <\/p>\n Das VWS-GUI ist danach per http:\/\/localhost:3000<\/a> im Browser aufrufbar und in Abbildung 7 dargestellt. Nach Konfiguration der Registry-URL als http:\/\/localhost:4000\/registry<\/a> sowie Aktivierung des Auto-Syncs im GUI per Button oben rechts ist ein direkter Zugriff auf die Verwaltungsschale mit ihren Teilmodellen m\u00f6glich.<\/p>\n Abbildung 7 – \u00dcberblick \u00fcber das VWS GUI<\/p>\n \u00dcber die setTargetTemperature<\/em>-Operation im heaterControl<\/em>-Teilmodell kann nun eine Zieltemperatur in Grad Fahrenheit eingestellt werden, die danach im lastTargetTemperature<\/em>-Property abrufbar ist. Durch Auswahl des currentTemperature<\/em>-Property kann per Mausklick im temperatureSensor<\/em>-Teilmodell live verfolgt werden, wie die Temperatur eingeregelt wird.<\/p>\n <\/p>\n Das in diesem Blog-Beitrag gezeigte Beispiel veranschaulicht, wie Eclipse BaSyx und die BaSyx DataBridge die Device-Integration mittels Verwaltungsschalen enorm vereinfachen k\u00f6nnen \u2013 und das ganz ohne jegliche Programmierkenntnisse. \u00dcber die Bereitstellung der DataBridge als Docker Image l\u00e4sst sich die gezeigte Device-Integration ganz einfach nachvollziehen und als Blaupause f\u00fcr eigene Use Cases nutzen. Zus\u00e4tzlich zeigt das Beispiel auf, welche weiteren Mehrwerte die OTS-Komponenten von BaSyx bieten.<\/p>\n Zuk\u00fcnftige Updates der DataBridge werden weitere Protokolle integrieren, wie z.B. Automatisierungsbusse. Zus\u00e4tzlich wird die Spezifikation des Asset Interfaces Description <\/em>Teilmodells der IDTA nach Release zur Konfiguration der DataBridge genutzt. In dieser Spezifikation werden zuk\u00fcnftig mehrere Teilmodelle definiert, die die Kommunkationsendpunkte sowie notwendige Datentransformationen der Assets (wie etwa Ger\u00e4te) beschreiben.<\/p>\n Die verschiedenen Features sowie die enge Verzahnung der einzelnen BaSyx-Komponenten erm\u00f6glichen eine schnelle Umsetzung von Use Cases. BaSyx erlaubt es seinen Anwender*innen somit also, den Fokus auf die Mehrwerte ihrer Use Cases zu richten \u2013 die Infrastrukturarbeit \u00fcbernimmt BaSyx.<\/p>\n Sie haben noch Fragen und\/oder wollen noch mehr zum Thema \u00bbDevice-Integration mittels der Eclipse BaSyx DataBridge\u00ab erfahren? \u2013 Melden Sie sich gerne bei uns!<\/a><\/p>\n <\/p>\n Lesen Sie au\u00dferdem auch gerne unsere anderen Blog-Artikel zu Eclipse BaSyx:<\/p>\n <\/p>\n Digitale Zwillinge sind eine Schl\u00fcsseltechnologie zur Zielerreichung von Industrie 4.0. Sie dienen als vereinheitlichte virtuelle Repr\u00e4sentation von Assets wie Ger\u00e4ten, Produkten oder Sensoren und deren Eigenschaften. Die Nutzung von Konzepten wie der Verwaltungsschale (kurz: VWS) erm\u00f6glicht die Schaffung einer standardisierten…<\/p>\n","protected":false},"author":76,"featured_media":10291,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[211,94],"tags":[537,120,477],"coauthors":[317],"class_list":["post-10211","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-digitale-transformation","category-industrie-4-0","tag-basyx","tag-digitaler-zwilling","tag-virtual-engineering"],"yoast_head":"\nBeispiel: Die Integration eines Heizelements in dessen Verwaltungsschale<\/h2>\n
\n
![\"Darstellung](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2023\/02\/Bild1-698x156.png\")
<\/p>\n\n
\n
![\"\"](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2023\/02\/Bild2-698x121.png\")
<\/p>\nDevice-Integration per Property-Delegation<\/h2>\n
![\"\"](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2023\/02\/Bild3-698x206.png\")
<\/p>\nDevice-Integration per Operation-Delegation<\/h2>\n
![\"\"](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2023\/02\/Bild4-698x206.png\")
<\/p>\nDevice-Integration mit der Eclipse BaSyx DataBridge<\/h2>\n
\n
![\"\"](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2023\/02\/Bild5-698x357.png\")
<\/p>\n\n
Einfache Device-Integration mittels der BaSyx Off-the-Shelf-Komponenten<\/h2>\n
![\"\"](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2023\/02\/Bild6-698x465.png\")
<\/p>\n![\"\"](\"https:\/\/www.iese.fraunhofer.de\/blog\/wp-content\/uploads\/2023\/02\/Bild7-698x319.png\")
<\/p>\nZusammenfassung & Ausblick: Nutzen und Zukunft der BaSyx DataBridge<\/h2>\n
\n