-
Die Erfindung betrifft ein Verfahren zum Etablieren einer Kommunikation zwischen einem ersten digitalen Zwilling und einem zweiten digitalen Zwilling, wobei dem ersten digitalen Zwilling eine erste REST-basierte API zugeordnet ist und wobei dem zweiten digitalen Zwilling eine zweite REST-basierte API zugeordnet ist.
-
Aus dem Stand der Technik sind bereits Automatisierungskomponenten bekannt geworden, die in industriellen Anlagen zum Einsatz kommen. Beispielsweise werden Feldgeräte als Automatisierungskomponenten eingesetzt, welche in der Prozessautomatisierungstechnik ebenso wie in der Fertigungsautomatisierungstechnik zum Einsatz kommen. Als Feldgeräte werden im Prinzip alle Geräte bezeichnet, welche prozessnah eingesetzt werden und welche prozessrelevante Informationen liefern oder verarbeiten. So werden Feldgeräte zur Erfassung und/oder Beeinflussung von Prozessgrößen verwendet. Zur Erfassung von Prozessgrößen dienen Messgeräte, bzw. Sensoren. Diese werden beispielsweise zur Druck- und Temperaturmessung, Leitfähigkeitsmessung, Durchflussmessung, pH-Messung, Füllstandmessung, etc. verwendet und erfassen die entsprechenden Prozessvariablen Druck, Temperatur, Leitfähigkeit, pH-Wert, Füllstand, Durchfluss etc. Zur Beeinflussung von Prozessgrößen werden Aktoren verwendet. Diese sind beispielsweise Pumpen oder Ventile, die den Durchfluss einer Flüssigkeit in einem Rohr oder den Füllstand in einem Behälter beeinflussen können. Neben den zuvor genannten Feldgeräten werden unter Automatisierungskomponenten auch Gateways, Edge Devices, Remote I/Os, Funkadapter bzw. allgemein Geräte verstanden, die auf der Feldebene angeordnet sind.
-
Eine Vielzahl solcher Automatisierungskomponenten wird von der Endress+Hauser-Gruppe produziert und vertrieben.
-
In modernen Industrieanlagen sind Feldgeräte in der Regel über Kommunikationsnetzwerke wie beispielsweise Feldbusse (Profibus®, Foundation® Fieldbus, HART®, etc.) mit übergeordneten Einheiten verbunden. Normalerweise handelt es sich bei den übergeordneten Einheiten um Leitsysteme (DCS) bzw. Steuereinheiten, wie beispielsweise eine SPS (speicherprogrammierbare Steuerung). Die übergeordneten Einheiten dienen unter anderem zur Prozesssteuerung, Prozessvisualisierung, Prozessüberwachung sowie zur Inbetriebnahme der Feldgeräte. Die von den Feldgeräten, insbesondere von Sensoren, erfassten Messwerte werden über das jeweilige Bussystem an eine (oder gegebenenfalls mehrere) übergeordnete Einheit(en) übermittelt. Daneben ist auch eine Datenübertragung von der übergeordneten Einheit über das Bussystem an die Feldgeräte erforderlich, insbesondere zur Konfiguration und Parametrierung von Feldgeräten sowie zur Ansteuerung von Aktoren.
-
Im Zuge der Industrie 4.0, bzw. IIoT („Industrial Internet of Things“) werden die von den Feldgeräten erzeugten Daten auch häufig direkt aus dem Feld mithilfe sogenannter Datenumsetzungseinheiten, welche beispielsweise als „Edge Devices“ oder „Cloud Gateways“ bezeichnet werden, erhoben und automatisiert an eine zentrale cloudfähige Datenbank (auch vereinfacht „Cloud“ genannt) übermittelt, auf welcher sich eine oder mehrere Applikationen befinden. Auf diese Applikationen, welche beispielsweise Funktionen zur Visualisierung und weiteren Bearbeitung der auf der Datenbank gespeicherten Daten bieten, kann von einem Benutzer mittels Internet zugegriffen werden.
-
Es ist vorgesehen, dass es zu jeder der Automatisierungskomponenten in der Anlage einen digitalen Zwilling gibt. Ein digitaler Zwilling (englisch: „digital twin“), auch digitales Abbild genannt, ist eine virtuelle Repräsentation der Automatisierungskomponente, welcher die identische Konfiguration, Parameterwerter, aktuelle Gerätestatus, Algorithmen, etc. der Automatisierungskomponente aufweist. Der digitale Zwilling weist somit alle relevanten Eigenschaften der Automatisierungskomponente auf, welche die Automatisierungskomponente für ihren bestimmungsgemäßen Zweck vollumfänglich beschreiben. Es ist vorgesehen, dass die Automatisierungskomponente und der digitale Zwilling bezogen auf die relevanten Eigenschaften stets identisch sind. Eine Änderung von Eigenschaften der Automatisierungskomponente führt zu einer Synchronisation (über Industrie 4.0-, bzw. IIoT-Techniken), so dass die Eigenschaften des digitalen Zwillings entsprechend aktualisiert werden.
-
Jedoch existieren digitale Zwillinge nicht nur für Automatisierungskomponente, sondern können für jegliches physische oder digitale Objekt erstellt werden. Beispielsweise ist es auch vorgesehen, dass Applikationen (Softwareprogramme), welche beispielweise von einer Cloud ausgeführt werden, einen zugeordneten digitalen Zwilling aufweisen, welcher die jeweilige Applikation hinsichtlich ihrer Funktion vollumfänglich beschreibt.
-
Stand heute gibt es somit verschiedenste Arten von digitalen Zwillingen. Diese weisen überwiegend nicht standardisierte Schnittstellen auf. Die Kommunikation zwischen solchen digitalen Zwillingen erfordert einen hohen Aufwand hinsichtlich des Mappings, also des Verfahrens, die von einer Schnittstelle zur Verfügung gestellten Daten hinsichtlich des Formats und der Semantik für die andere Schnittstelle zugänglich zu machen. Die Pflege dieses Mappings muss manuell durchgeführt werden. Aktualisierungen, z.B. Firmware-Updates auf Seite der Automatisierungskomponente müssen daher ebenfalls in der entsprechenden Schnittstelle nachgezogen werden. Es reicht dabei nicht aus, dass die Schnittstellen zweiter digitaler Zwilling beispielsweise REST-basiert sind - sie müssen sich außerdem auch dieselbe Semantik teilen.
-
Ausgehend von dieser Problematik liegt der Erfindung die Aufgabe zugrunde, ein Verfahren vorzustellen, welches eine gegenseitige Kommunikation zweier einander unbekannter digitaler Zwillinge erlaubt.
-
Die Aufgabe wird durch ein Verfahren zum Etablieren einer Kommunikation zwischen einem ersten digitalen Zwilling und einem zweiten digitalen Zwilling gelöst, wobei dem ersten digitalen Zwilling eine erste REST-basierte API zugeordnet ist und wobei dem zweiten digitalen Zwilling eine zweite REST-basierte API zugeordnet ist, umfassend:
- - Senden einer Anfrage an zumindest einen Endpunkt der ersten API und Empfangen von zumindest einer Antwort der ersten API;
- - Senden einer Anfrage an zumindest einen Endpunkt der zweiten API und Empfangen von zumindest einer Antwort der zweiten API;
- - Vergleichen und Analysieren der zumindest einen Antwort des ersten API mit der zumindest einen Antwort der zweiten API;
- - Erstellen von zumindest einem Mappingmodell anhand des Vergleichens und des Analysierens, wobei das Mappingmodell semantische und technische Anforderungen der ersten API und der zweiten API enthält; und
- - Verwenden des Mappingmodells zur gegenseitigen Kommunikation zwischen dem ersten digitalen Zwilling und dem zweiten digitalen Zwilling, wobei das Mappingmodell eine Datenübertragung von einem der beiden digitalen Zwillinge konform der technischen und semantischen Anforderungen der API des anderen der beiden digitalen Zwillinge übersetzt.
-
Das erfindungsgemäße Verfahren erlaubt es somit, ein Mapping zwischen den beiden digitalen Zwillingen zur gegenseitigen Kommunikation durchzuführen. Von beiden APIs werden die Semantik und das Format der Antworten und/oder der erwarteten Eingaben an den Endpunkten erlernt. Das daraus gebildete Mappingmodell dient fortan als eine Art Dolmetscher zwischen dem ersten digitalen Zwilling und dem zweiten digitalen Zwilling.
-
REST („Representational State Transfer“) stellt ein einheitliches Konzept einer Softwarearchitektur von verteilten Systemen, insbesondere Webservices, dar.
-
Eine API („Application Programming Interface“) ist eine Schnittstelle, die es Applikationen ermöglicht, miteinander zu kommunizieren. Eine REST-basierte API ist also eine API, die auf der REST-Architektur aufgebaut ist und insbesondere für die Machine-to-Machine-Kommunikation verwendet wird. Mithilfe einer solchen RESTbasierten API ist es möglich, Informationen von einer Applikation beispielsweise mittels eine HTTP-Requests anzufordern. Der HTTP-Request richtet sich an dedizierte Endpunkte der APIs.
-
Ein Endpunkt ist, vereinfacht ausgedrückt, das eine Ende eines Kommunikationskanals. Wenn eine API mit einem anderen System interagiert, werden die Berührungspunkte dieser Kommunikation als Endpunkte betrachtet. Eine API besteht aus einer Vielzahl von Endpunkten, die angesprochen werden können. Es gibt hierbei Typen von Endpunkten, die mittels eines Requests („GET“, „READ“, etc.) angefragt werden können und als Informationen als Antwort ausgeben. Die Antwort hat hierbei eine API-eigene Technik, Logik und Semantik. Andere Typen von Endpunkten können Befehle („PUT“, „WRITE“, etc.) erhalten, welche ein Schreiben oder Setzen eines Werts in die mit der API verbundenen Applikation erlauben. Der Befehl muss hierbei der vorgegebenen API-eigene Technik, Logik und Semantik entsprechen.
-
Es kann vorgesehen sein, dass das Mappingmodell die Kommunikation zwischen mehr als zwei digitalen Zwillingen regelt. Das erfindungsgemäße Verfahren kann dadurch auf eine beliebige Zahl digitaler Zwillinge angewendet werden.
-
Gemäß einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens ist vorgesehen, dass vorab zumindest eine Liste von zumindest einem Teil aller Endpunkte der ersten API und der zweiten API durch Auslesen der entsprechenden ersten API, bzw. zweiten API erstellt wird. Die jeweilige API wird also angefragt und liefert als Antwort auf die Anfrage die Endpunkte, die später im erfindungsgemäßen Verfahren angefragt werden.
-
Eine vorteilhafte Ausgestaltung des erfindungsgemäßen Verfahrens sieht vor, dass die Antwort der ersten API und/oder der zweiten API eine Zusatzinformation aufweist, welche für die Schritte des Vergleichens und des Analysierens mitverwendet wird. Bei den Zusatzinformationen, auch „payload“ genannt, kann es sich beispielsweise um Zusatzinformationen, die von dem entsprechenden digitalen Zwilling bereitgestellt werden, handeln. Bezieht sich ein digitaler Zwilling beispielsweise auf eine Automatisierungskomponente, so können die Zusatzinformationen beispielsweise Diagnose- oder Statusdaten, insbesondere als String vorliegend, enthalten.
-
In einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens ist vorgesehen, dass für die Schritte des Vergleichens, des Analysierens und des Erstellens des Mappingmodells eine Cloud-Applikation verwendet wird. Die Cloud-Applikation greift also auf die APIs beider digitale Zwillinge zu und stellt die entsprechenden Anfragen bezüglich an die zur Verfügung stehenden Endpunkte. Bei der Cloud-Applikation kann es sich vorteilhaft um einen sogenannten „API-Mapper“ oder um einen Kommunikationsbroker handeln.
-
Hierbei ist vorgesehen, dass für die Schritte des Vergleichens, des Analysierens und des Erstellens des Mappingsmodells ein KI-Algorithmus verwendet wird. Der KI-Algorithmus ist mit entsprechenden Trainingsdaten eingelernt und darauf trainiert, Muster oder bekannte Strukturen in den von den APIs enthaltenen Antworten zu erkennen, um die Funktionsweise, Struktur und Semantik der jeweiligen Endpunkte identifizieren zu können.
-
Der KI-Algorithmus greift bevorzugterweise für die Schritte des Vergleichens, des Analysierens und des Erstellens des Mappingsmodells zusätzliche Informationen einer der Cloud-Applikation zugeordneten oder zuordenbaren Instanz zu, wobei die Instanz ein Klassifikationsmodell, insbesondere basierend auf ECLASS, oder eine ständig erweiterbare Datenbank enthaltend eine Vielzahl weiterer Mappingmodelle und zugeordneter Antworten von weiteren APIs ist.
-
Weiter kann vorgesehen sein, dass der KI-Algorithmus das erstellte Mappingmodell updatet, im Falle, dass die Instanz über neue zusätzliche Informationen verfügt. Über die Zeit betrachtet wird das Mappingmodell somit stetig verfeinert, so dass dessen Genauigkeit und Zuverlässigkeit erhöht wird.
-
Gemäß einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens ist vorgesehen, dass für das Senden der Anfrage erste API und/oder zweite API und für das Empfangen der entsprechenden Antwort ein Webservice verwendet wird. Ein Webservice ist ein Standard zur Machine-to-Machine-Kommunikation, welcher von der Cloud-Applikation, welche auf die jeweiligen APIs zugreift, verwendet wird.
-
Gemäß einer ersten vorteilhaften Variante des erfindungsgemäßen Verfahrens ist vorgesehen, dass sich der erste digitale Zwilling auf eine erste Feldgerät der Automatisierungskomponente bezieht.
-
In einer vorteilhaften Ausgestaltung der ersten Variante des erfindungsgemäßen Verfahrens ist vorgesehen, dass sich der zweite digitale Zwilling auf eine zweite Automatisierungskomponente bezieht, oder wobei sich der zweite digitale Zwilling auf eine Applikation, insbesondere auf eine Cloud-Applikation, bezieht.
-
Gemäß einer zweiten vorteilhaften Variante des erfindungsgemäßen Verfahrens ist vorgesehen, dass sich der erste digitale Zwilling auf eine erste Applikation, insbesondere auf eine Cloud-Applikation bezieht und wobei sich der zweite digitale Zwilling auf eine zweite Applikation, insbesondere auf eine Cloud-Applikation bezieht.
-
Beispiele für Automatisierungskomponenten, insbesondere Feldgeräte und Netzwerkgeräte wie Gateways, Edge Devices, etc., sind bereits im einleitenden Teil der Beschreibung beispielhaft aufgeführt worden.
-
Eine Applikation, auch Anwendungssoftware genannt, ist ein Computerprogramm, welches Funktionen ausführt, welche nicht das System betreffen, auf welchem sie ausgeführt werden. Eine solche Applikation muss nicht zwingend von einer Cloud ausgeführt werden, sondern kann prinzipiell auf einem beliebigen System, bzw. Host aufgebracht sein, solange dieser eine Verbindung mit seinem digitalen Zwilling herstellen kann. So kann das System, bzw. der Host ein Server, ein PC, ein mobiles Endgerät (Smartphone, Tablet, etc.) oder ähnliches sein.
-
Die Erfindung wird anhand der nachfolgenden Figur näher erläutert. Es zeigt
- 1: ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens.
-
In 1 ist eine beispielhafte Anwendung des erfindungsgemäßen Verfahrens gezeigt. Es sind hierfür zwei digitale Zwilling DT1, DT2 vorgesehen. Die digitalen Zwillinge DT1, DT2 befinden sich auf einer Cloud oder einem Server und sind per Internet kontaktierbar. Der erste digitale Zwilling DT1 bezieht sich im vorliegenden Beispiel auf eine Automatisierungskomponente, genauer ein Feldgerät in Gestalt eines Temperatursensors. Der zweite digitale Zwilling DT2 bezieht sich auf eine weitere Automatisierungskomponente, genauer ein Feldgerät in Gestalt eines Temperatursensors von einem anderen Hersteller.
-
Zur Kommunikation mit den digitalen Zwillingen DT1, DT2 ist jedem digitalen Zwilling DT1, DT2 eine REST-basierte API API1, API2 zugeordnet. Beide APIs API1, API2 unterscheiden sich in der Struktur und Semantik der erwarteten Befehle, bzw. ausgegebenen Daten, so dass diese nicht ohne Weiteres miteinander kommunizieren können.
-
Um die gegenseitige Kommunikation etablieren zu könne, wird eine Cloud-Applikation CA verwendet. Die Cloud-Applikation CA kann mittels Webservices mit den APIs API1, API2 der digitalen Zwillinge DT1, DT2 kommunizieren.
-
In einem vorgelagerten Verfahrensschritt sendet die Cloud-Applikation CA eine Anfrage an beide APIs API1, API2 mit der Bitte, alle Endpunkte („GET“, „READ“, etc.) zu übergeben, anhand derer ein Anfragender Daten des jeweiligen Temperatursensors erhalten kann, sowie derjenigen Endpunkte („PUT“, „WRITE“, etc.), anhand derer Befehle gesendet werden können. Die APIs API1, API2 stellen der Cloud-Applikation CA anschließend Listen der entsprechenden Endpunkte zur Verfügung.
-
In einem ersten Verfahrensschritt a) fragt die Cloud-Applikation CA gezielt die einzelnen Endpunkte der API API1 des ersten digitalen Zwillings DT1 ab. Beispielsweise kann der folgende Endpunkt angefragt werden:
- „GET_SENSOR_DATE (Device-ID)“
-
Als Antwort gibt die API API1 die folgende erste Zeichenkette zurück:
- „23D65H2, 36.43, 16-12-2021 13:32:09, OK“
-
In einem zweiten Verfahrensschritt b) fragt die Cloud-Applikation CA gezielt die einzelnen Endpunkte der API API2 des ersten digitalen Zwillings DT2 ab. Beispielsweise kann der folgende Endpunkt angefragt werden:
- „READ_Data (Device-ID-Vendor ID)“
-
Als Antwort gibt die API API2 die folgende zweite Zeichenkette zurück:
- „F43G456, 33xx, 35.56, 1, OK, 3F7, 16.13.35 2021/12/16“
-
Die beiden Zeichenketten werden gespeichert. Im Anschluss werden in den Verfahrensschritten c) bis e) sequenziell oder gleichzeitig auf mehrere Instanzen und/oder Methoden zurückgegriffen. So wird ein Kl-Algorithmus (Schritt d)) verwendet, insbesondere basierend auf Machine Learning, welcher die einzelnen Zeichenketten analysiert und die Semantik und Form der Antworten analysiert, um ein Mappingmodell MO zu erstellen. Ein solches Mappingmodell MO enthält die Technik, Form und Semantik der beiden APIs API1, API2, bzw. derer einzelner Endpunkte, und erlaubt eine gegenseitige Übersetzung von Nachrichten zueinander, entsprechend der Anforderungen der APIs API1, API2.
-
Es kann (Verfahrensschritt c)) auf eine oder mehrere bereits existierende Mappingmodelle, welche in einer Datenbank DB gespeichert sind, zugegriffen werden. Erkannte Muster in den Zeichenkette können anhand Zusatzinformationen, welche in einer externen Instanz IN gespeichert sind (bspw. ECLASS-Klassifikationen) identifiziert und interpretiert werden.
-
Nach Abschluss der Analyse liegt das Mappingmodell MO vor. In diesem sind die einzelnen Formate und Semantiken der Endpunkte beider APIs API1, API2 aufgeführt.
-
Der in diesem Beispiel angefragte Endpunkt der API API1 des ersten digitalen Zwillings DT1, welcher als Antwort die erste Zeichenkette ausgab, befolgt folgende Struktur:
- „Device-ID, Messwert (PV), Timestamp, Geräte-Status“.
-
Der in diesem Beispiel angefragte Endpunkt der API API2 des zweiten digitalen Zwillings DT2, welcher als Antwort die zweite Zeichenkette ausgab, befolgt folgende Struktur:
- „Device-ID, Vendor-ID, Messwert (PV), Temperature_UNIT, Health-Status_IO-Link_Master, Timestamp“
-
Das Mappingmodell MO enthält des Weiteren eine Zuordnung beider APIs API1, API2 der digitalen Zwillinge DT1, DT2 zueinander, sodass auf technischer und semantischer Ebene ein Kommunikations-Interface zwischen den digitalen Zwillingen DT1, DT2 entsteht. Beispielsweise wird erkannt, dass beide genannten Endpunkte im Prinzip dieselbe Aussage über den jeweiligen Temperatursensor zulassen.
-
Ebenso wird festgestellt, dass die Struktur und Semantik beider Endpunkte zwar ähnlich sind, aber dennoch nicht ganz dieselbe Anzahl von Übergabe- und Ausgabeparameter aufweisen. Auch die Syntax für den Timestamp unterscheidet sich. API 1 verwendet dabei das Format „DD-MM-YYYY HH:ii:ss“, wohingegen REST-API 2 folgende Notation verwendet: „hh.ii.ss YYYY/mm/dd“.
-
Während REST-API 2 den Parameter „Temperature_UNIT“ verwendet, um beispielsweise anzugeben, ob es sich beim Messwert um „Grad Celsius“ oder um „Fahrenheit“ handelt, findet sich kein entsprechender Parameter in dem Endpunkt von API1.
-
Die API1 des erste digitalen Zwillings DT1 bietet jedoch noch eine weiteren Endpunkt an:
- „GET_ALL_DEVICE_CONFIGURATION_VALUES“
-
Darin enthalten ist auch die aktuelle Einstellung für den Temperaturwert.
-
All dies muss nun der API API2 des zweiten digitalen Zwillings DT2 beigebracht werden („teach-in“). Sie muss also die Semantik und den logischen Aufbau der API1 des ersten digitalen Zwillings DT1 verstehen. Im Zweifel müssten „Dummy“- oder „Defaultwerte“ generiert werden, um eine Methode der jeweils anderen API ausführen zu können, falls die entsprechenden Werte nicht vorhanden sind.
-
Beispiel: Die API API2 des zweiten digitalen Zwillings DT2 verlangt den Health Status des angeschlossenen IO-Link Masters. Dieser Wert mag aber gar nicht bekannt sein. Folglich wird ein Dummy-Wert generiert, der für „Device OK“ steht.
-
Alle diese Regeln und Zuordnungen sind im Mappingmodell MO enthalten. Das Mappingmodell MO kann somit als eine Art Dolmetscher zwischen den beiden digitalen Zwillingen DT1, DT2 betrachtet werden.
-
Für ein Beispiel zur Kommunikation der digitalen Zwillinge untereinander wird ein dritter digitaler Zwilling eingeführt (nicht abgebildet). Dieser dritte digitale Zwilling bezieht sich auf einen Temperaturregler. Mittels des erfindungsgemäßen Verfahrens wird die API dieses digitalen Zwillings angefragt und die Semantik und Form des folgenden Endpunkts ermittelt:
-
Dieser Endpunkt erlaubt es, Soll- und Istwerte in den Temperaturregler zu schreiben. Der Temperaturregler erwartet eine Zeichenkette der Form:
- „Device-ID, Role („Sollwert, Istwert, Regelabweichung“) , Actual Value, Temperature_UNIT, Timestamp"
-
Das Mappingmodell MO enthält nun eine Zuordnung des ersten und des zweiten digitalen Zwillings DT1, DT2 zu dem dritten digitalen Zwilling. Somit lässt sich beispielsweise ein Regelkreis aufbauen. Hierfür benötigt der dritte digitale Zwilling entsprechend des oben genannten Endpunkts die Sollwerte der den digitalen Zwillingen DT1, DT2 zugeordneten Temperatursensoren. Diese sind jeweils in den Ausdrücken „Messwert (PV)“ der jeweiligen Endpunkte enthalten. Das Mappingmodell MO identifiziert nun alle von dem Endpunkt der API des dritten Zwillings benötigten Ausdrücke (Device-ID, „Sollwert“, etc.), identifiziert die entsprechend korrespondierenden Werte in den Endpunkten der beiden APIs API1, API2 und erstellt eine entsprechende Zeichenkette, die an den „WRITE_INPUTS“-Endpunkt der API des dritten digitalen Zwillings gesendet wird. Diese kann direkt verarbeitet werden, da sie das korrekte Format und die korrekte Semantik aufweist.
-
In einem alternativen Beispiel bezieht sich der zweite digitale Zwilling DT2 auf eine weitere Cloud-Applikation, beispielsweise auf ein Asset Management-System. Dieses erwartet in regelmäßigen Abständen Aktualisierungen des Gerätestatus des Temperatursensors, der dem ersten digitalen Zwilling DT1 zugeordnet ist. Das Mappingmodell erlaubt es zum einen, die Anfragen des zweiten digitalen Zwillings nach den Gerätestatus entsprechend den Anforderungen des jeweiligen Endpunkts der API1 aufzubereiten. Zum anderen wird die Antwort des Endpunkts der API API1 des ersten digitalen Zwillings mittels des Mappingmodells MO so aufbereitet, dass diese die Anforderungen des entsprechenden Endpunkts (beispielsweise ein „PUT_DATA“-Befehl) erfüllt und der Gerätestatus korrekt in der weiteren Cloud-Applikation gespeichert werden kann.
-
Bezugszeichenliste
-
- a), b), ..., d)
- Verfahrensschritte
- API1
- erste REST-basierte API
- API2
- zweite REST-basierte API
- CA
- Cloud-Applikation
- DB
- Datenbank
- DT1
- erster digitaler Zwilling
- DT2
- zweiter digitaler Zwilling
- IN
- Instanz
- KI
- KI-Algorithmus
- MO
- Mappingmodell
