1 Motivation

Das Konzept der X-in-the-Loop-Simulation (XiLS) ermöglicht die virtuelle Auslegung sowie Inbetriebnahme von Steuerungssystemen in frühen Entwicklungsphasen des Maschinen- und Anlagenbaus und findet vermehrt Einsatz im mechatronischen Entwicklungsprozess. Die XiLS umfasst die Model-in-the-Loop Simulation (MiLS), Software-in-the-Loop Simulation (SiLS) und Hardware-in-the-Loop Simulation (HiLS), deren Gemeinsamkeit die Kopplung einer Steuerungsausprägung (als Modell, Software oder Hardware) mit einer simulierten Maschine oder Anlage ist. Die daraus resultierenden Digitalen Zwillinge werden mit Geometrie- und Verhaltensmodellen beschrieben, die das Anlagenverhalten nachbilden.

Die im Rahmen des mechatronischen Entwicklungsprozesses entstehenden Digitalen Zwillinge werden bislang primär für dezidierte Fragestellungen im Entwicklungs- und Inbetriebnahmeprozess eingesetzt, obwohl vielfältige Anwendungspotenziale über den gesamten Lebenszyklus einer Anlage vorhanden sind. Beispiele dafür sind der Einsatz Digitaler Zwillinge zur Zustandsüberwachung, Predictive Maintenance, Mitarbeiterschulung oder Wartungs- und Vertriebsunterstützung von Maschinen und Anlagen.

Die dargestellten Einsatzmöglichkeiten erfordern gleichermaßen eine standort- und endgeräteunabhängige Verfügbarkeit sowie Vernetzungsfähigkeit und Skalierbarkeit der Digitalen Zwillinge. Moderne Paradigmen der Cloud- und Webtechnologien fördern die dafür notwendigen flexiblen Softwarearchitekturen.

Während Cloudtechnologien wie Virtualisierungs- und Containerkonzepte skalierbare, netzwerkzentrierte, abstrahierte IT-Infrastrukturen [1] eröffnen, ermöglichen Entwicklungen der Webtechnologien wie Webserver und -browser oder standardisierte Programmierschnittstellen und Kommunikationsprotokolle (wie WebSockets, WebRTC, WebGL) eine endgeräteunabhängige Auslieferung und Verfügbarkeit der Daten und Softwareanwendungen.

Diese Technologien sind zentrale Treiber für die große Flexibilität und Funktionsvielfalt sowie die dynamische Entwicklungsgeschwindigkeit in der Webentwicklung und bieten großes Potenzial für Anwendungen mit Digitalen Zwillingen. Abb. 15.1 zeigt die Verknüpfung der Cloud- und Webtechnologien mit dem Digitalen Zwilling zu einem Digital Twin as a Service (DTaaS) Ansatz.

Abb. 15.1
figure 1

Digital Twin as a Service (DTaaS) Ansatz

Full size image

Die systematische Verknüpfung von Digitalen Zwillingen mit Cloud- und Webtechnologien eröffnet wechselseitige Mehrwerte:

  • Cloud- und Webtechnologien als Mehrwerte für Digitale Zwillinge:

    Durch die Integration von Web- und Cloudtechnologien kann der Funktionsumfang der Digitalen Zwillinge grundlegend erweitert werden. Neben der Verwendung von Basistechnologien wie Webbrowsern oder Webservern kann an der Weiterentwicklung von Softwaremodulen und Bibliotheken im Rahmen weltweiter Beiträge der Cloud- und Web-Community partizipiert werden. Als Beispiele können Speicherdienste, Dienste zur Nutzerverwaltung, Sprachverarbeitungsdienste sowie Algorithmen zur Geometrieverarbeitung, Physikberechnung, Bildverarbeitung und Künstlichen Intelligenz (KI) genannt werden.

  • Digitale Zwillinge als Mehrwerte für Cloud- und Webtechnologien:

    Digitale Zwillinge bilden eine wertvolle Funktions- und Datenbasis für unterschiedliche Anwendungen der Cloud- und Webtechnologien im Maschinen- und Anlagenbau. Sie können beispielsweise als Referenzmodell für cloudbasierte Predictive Maintenance Dienste, zur Erzeugung synthetischer Trainingsdaten für KI-Anwendungen, in Mixed Reality-Anwendungen zur Mitarbeiterschulung oder als datenbasiertes Assistenzsystem eingesetzt werden.

2 Interoperabilität zwischen Digitalen Zwillingen sowie Cloud- und Webtechnologien

Für die Erschließung der dargestellten Mehrwerte aus der bidirektionalen Verknüpfung zwischen Digitalen Zwillingen sowie Cloud- und Webtechnologien werden folgende technische Leitziele formuliert:

  • Interoperabilität zwischen Digitalen Zwillingen sowie Cloud- und Webtechnologien:

    Für die symbiotische Verbindung Digitaler Zwillinge mit Cloud- und Webtechnologien ist die Bereitstellung bidirektionaler Verbindungsmöglichkeiten notwendig. Für eine flexible Interoperabilität sollten die Schnittstellen des Digitalen Zwillings den standardisierten Schnittstellen folgen, die in der Cloud- und Web-Domäne dominieren.

  • Verfügbarmachung industrieller Assets für Cloud- und Webtechnologien:

    Digitale Zwillinge erfordern die Zugänglichkeit zu industriellen Systemen, wie Hardware-in-the-Loop Simulatoren, Programmiersystemen oder industriellen Steuerungen. Die Kommunikation mit diesen sogenannten Assets wird durch Protokolle auf der Maschinen- und Anlagenebene bestimmt (OT: Operational Technology). Demgegenüber stehen die Kommunikationsprotokolle der Cloud- und Webtechnologien (IT: Information Technology). Das Zusammenführen und effektive Zusammenspiel der beiden Kommunikationsebenen OT und IT, wie in Abb. 15.2 dargestellt, ist eine der entscheidenden Herausforderungen im Kontext des Industrial Internet of Things (IIoT).

Abb. 15.2
figure 2

Heterogene Kommunikation zwischen den Cloud- und Webtechnologien und industriellen Assets

Full size image

Die Interoperabilität zwischen Digitalen Zwillingen sowie Cloud- und Webtechnologien erfordert die Überwindung technischer Herausforderungen, die aus den hohen Anforderungen an die Erreichbarkeit und der Weiterverwendung Digitaler Zwillinge resultieren. Die Einsatzmöglichkeit bestehender Clouddienste zur Erweiterung von Digitalen Zwillingen motiviert die Integration von standardisierten Kommunikationsprotokollen der Web- und Cloudtechnologien. In diesem Abschnitt werden Kommunikationsprotokolle, moderne Softwarearchitekturen und Softwarebereitstellungsarten vorgestellt, die den genannten Anforderungen gerecht werden.

Standardprotokolle HTTP und Websockets

Bereits bei der Bereitstellung der ersten Webseite von Tim Berners-Lee im CERN im Jahr 1989 (vgl. [2]), wurden präzise spezifizierte Schnittstellen verwendet. Dies war aus Sicht von Berners-Lee erforderlich, da am CERN unterschiedliche IT-Infrastrukturen zur Datenhaltung vorherrschten, die einen Datenaustausch erschwerten (vgl. [3]). Für die Kommunikation und zum Transfer der Daten wurde das Hypertext Transfer Protocol (HTTP) entwickelt. Die semantische Darstellung der Webseite wurde durch die Seitenbeschreibungssprache Hypertext Markup Language (HTML) beschrieben und die Auffindbarkeit der Webseite wurde durch den später Uniform Resource Locator (URL) genannten Standard umgesetzt. Diese Form der Bereitstellung ist bis heute in den Grundzügen erhalten geblieben und hat sich zum Standard im Internet entwickelt. Das World Wide Web, wie es heute verstanden wird, basiert auf Webservern zur Webseitenbereitstellung und Webbrowsern zur endgeräteunabhängigen Anzeige der Webseiten über HTTP als Übertragungsprotokoll und HTML als Beschreibungssprache.

Für den Abruf von Informationen wird bei HTTP auf eine synchrone Kommunikation basierend auf dem Client-Server-Prinzip gesetzt. Dabei stellt der Client eine Anfrage (Request) an einen verfügbaren Webserver und erhält auf diese spezifische Anfrage eine Antwort (Response). Die HTTP-Anfragemethoden erlauben die Übertragung von Argumenten und ermöglichen somit auch eine Informationsübermittlung an den Server, der eine spezifische Antwort erstellt. Mittlerweile findet das Protokoll Anwendung in Webbrowsern unterschiedlicher internetfähiger Endgeräte. HTTP hat sich über die Auslieferung von Webseiten hinaus als Standard für zahlreiche weitere Anwendungen entwickelt und macht mittlerweile Daten für Mobile Apps sowie Dienste der Cloud verfügbar. In modernen Clouddiensten wird auf das HTTP Protokoll das Representational State Transfer (REST) Paradigma aufgesetzt [4]. Die verfügbaren Eigenschaften von Objekten werden über Uniform Ressource Identifier (URI) beschrieben und enthalten Informationen über den Ort und Namen verfügbarer Eigenschaften. Die REST-Routen erlauben einen Zugriff auf Eigenschaften der vorhandenen Objekte, sodass etwa die Route „/Maschine1/Motor1/Temperatur“ Zugriff auf die gewünschte Information erlaubt. Dem REST-Paradigma folgend werden Informationen zustandslos zwischen Server und Client ausgetauscht, so dass alle notwendigen Informationen bei der Anfrage (Request) und Antwort (Response) übertragen werden.

Für die bidirektionale, zyklische und asynchrone Kommunikation zwischen Client und Server wird in den Cloud- und Webtechnologien das sogenannte Websocket-Protokoll verwendet (vgl. [5]). Im Gegensatz zu HTTP, halten Websockets (WS) die darunterliegende zustandsbehaftete Transmission Control Protocol (TCP) Verbindung aufrecht, bis diese aktiv durch einen Teilnehmer beendet wird. Nach Aufbau der Verbindung durch den Client kann gleichberechtigt eine bidirektionale Datenübertragung von Client und Server erfolgen.

Microservice Architektur

Moderne Cloud- und Webanwendungen werden als modulare Softwareanwendungen mit sogenannten Microservices umgesetzt. Microservices sind abgeschlossene Softwareeinheiten, die jeweils eine definierte Funktion über die Protokolle HTTP und WS anbieten (vgl. Abb. 15.3). Dabei können Microservices eigene User-Interfaces bereitstellen, jedoch ist dies nicht zwingend erforderlich.

Abb. 15.3
figure 3

Beispielhafte Struktur einer Softwareanwendung mit Microservice-Architektur: Aufteilung von einzelnen Funktionalitäten auf mehrere unabhängige Microservices

Full size image

Die Bereitstellung von Software, die der Microservice-Architektur folgt, hat zahlreiche Vorteile:

  • Lose Kopplung:

    Die Software ist in funktionelle Einheiten aufgeteilt, die lose gekoppelt sind. Bei der Entwicklung eines Microservice liegt der Fokus auf der Lösung eines definierten Problems, sodass die Entwicklung ohne Abhängigkeiten zu anderen Microservices umgesetzt werden kann.

  • Robustheit:

    Durch die lose Kopplung eines Microservice ist dessen Lauffähigkeit nicht von weiteren Softwarebestandteilen abhängig und damit weniger fehleranfällig. Die Abgeschlossenheit der Funktionalität erlaubt zudem ein effizientes Testen der definierten Anforderungen ohne aufwändig zustandsbehaftete Szenarien zu integrieren.

  • Wiederverwendbarkeit:

    Die Verwendung eines Microservice beschränkt sich nicht nur auf den Einsatz in einer einzigen Anwendung, sondern kann grundsätzlich in weiteren Anwendungen aufgrund der Verfügbarkeit unter Einsatz von Standardschnittstellen wiederverwendet werden.

  • Skalierbarkeit:

    Die Abgeschlossenheit eines Microservice erlaubt auf einfache Weise eine skalierbare Bereitstellung, da lediglich die für den Microservice erforderlichen Ressourcen den Anwendungen zur Verfügung gestellt werden müssen. Der schnittstellenbasierte Ansatz ermöglicht die Verteilung von Softwarekomponenten auf unterschiedlichen Hardwaresystemen.

  • Austauschbarkeit:

    Die schnittstellenbasierte Architektur erleichtert zudem einen Austausch von Microservices und die Erweiterungsmöglichkeit durch zusätzliche Microservices. Für den Austausch von Microservices müssen durch das REST-Paradigma lediglich die gleichen REST-Routen mit den analogen Informationen bereitgestellt werden.

Digital Twin as a Service

Zur Umsetzung der geforderten Interoperabilität von Digitalen Zwillingen und den Cloud- und Webtechnologien wird im Folgenden ein Konzept präsentiert, das die Bereitstellung Digitaler Zwillinge über eine Microservice-Architektur vorsieht. Hierfür müssen die Softwarekomponenten modular als abgeschlossene Funktionseinheiten bereitgestellt werden sowie über HTTP und Websocket Schnittstellen zur Vernetzung mit weiteren Microservices verfügen.

Die Bereitstellung von IT-Dienstleistungen ist in den letzten Jahrzehnten vermehrt vom lokalen Rechner in Cloud-Infrastrukturen gewandert. Bei der Bereitstellung der Dienstleistungen kann zwischen verschiedenen Ansätzen unterschieden werden. Als Infrastructure as a Service (IaaS) werden Rechen-, Speicher-, Netzwerk- und weitere Basisressourcen zur Verfügung gestellt. Wenn die Infrastruktur darüber hinaus um eine Laufzeitumgebung inklusive des Betriebssystems erweitert wird, spricht man von Plattform as a Service (PaaS). Eine als Cloud-Service bereitgestellte Software stellt die vollständige Funktionalität einer Applikation als Software as a Service (SaaS) zur Verfügung (vgl. [6]). Die Erweiterung einzelner Applikationen als Cloud-Service zu zusammenhängenden Software-Umgebungen können in verschiedenen Formen auftreten und werden aufgrund ihres generalistischen Ansatzes als Anything oder Everything as a Service (XaaS) bezeichnet.

Die Verfügbarmachung von Funktionalitäten und Eigenschaften des Digitalen Zwillings für eine Vielzahl von Anwendungen kann durch die Erweiterung des XaaS Ansatzes um den Digital Twin as a Service (DTaaS) realisiert werden (vgl. Abb. 15.4).

Abb. 15.4
figure 4

Erweiterung des XaaS Ansatzes um den Digital Twin as a Service (DTaaS)

Full size image

Die servicebasierte Bereitstellung des Digitalen Zwillings (Englisch: Digital Twin-DT) wird durch eine Kombination von Microservices in drei IT-Funktionsebenen realisiert (vgl. Abb. 15.5):

Abb. 15.5
figure 5

Architektur des Digital Twin as a Service Ansatzes

Full size image

  • DT Communication: Die Kommunikation des Digitalen Zwillings wird durch eine Reihe von skalierbaren Microservices für verschiedene Kommunikationsprotokolle zur Verfügung gestellt. Zum einen sollen in der Ebene DT Communication Web die Daten des Digitalen Zwillings über HTTP und Websockets für verschiedene Dienste bereitgestellt werden und zum anderen sollen über die Ebene DT Communication Assets Microservices zur Verfügung stehen, die eine Verbindung zur OT-Ebene zu verschiedenen Assets aufbauen. Die Anbindung unterschiedlicher Assettypen und dadurch benötigter industrieller Protokolle (OPC UA, MQTT, …) werden durch jeweils einen Microservice umgesetzt.

  • DT Model: Diese Ebene stellt die Bestandteile der Digitalen Zwillinge auf Grundlage einer zentralen Beschreibung bereit. Diensten aus den Cloud- und Webtechnologien werden durch die zentrale Bereitstellung unterschiedliche Möglichkeiten des Zugriffs und der Bearbeitung ermöglicht. Die Digitalen Zwillinge umfassen unter anderem das Verhaltens- und Interaktionsmodell, die geometrischen Repräsentationen sowie das Mapping zwischen Modell und Realdaten von Assets.

  • DT Runtime: Die DT Runtime führt den Digitalen Zwilling entsprechend des DT Model aus und etabliert über die Microservices der DT Communication die benötigte Kommunikation zu Assets und zu Anwendungen der Cloud- und Webtechnologien.

Abb. 15.5 zeigt den DTaaS Ansatz mit seinen Komponenten im Zusammenspiel mit Systemen und Technologien der Cloud- und Webtechnologien.

Die Interoperabilität zwischen Digitalen Zwillingen und den Cloud- und Webtechnologien ist über HTTP und Websockets in der DT Communication Web realisiert. So wird sichergestellt, dass die Digitalen Zwillinge innerhalb von Anwendungen der Cloud- und Webtechnologien weiterverwendet werden können und darüber hinaus auf einfache Weise erreichbar sind. Gleichzeitig kann der Funktionsumfang der Digitalen Zwillinge durch verfügbare Dienste in der Cloud erweitert werden. Der DTaaS Ansatz bietet die Möglichkeit bestehende Systeme, wie Services in der Cloud, in einem Digitalen Zwilling zu vereinen und diesen damit zu erweitern.

3 Verfügbarmachung industrieller Assets für Cloud- und Webtechnologien

Basierend auf der im vorausgegangenen Abschnitt beschriebenen Interoperabilität zwischen Digitalen Zwillingen sowie Cloud- und Webtechnologien wird im Folgenden auf die Kommunikation mit industriellen Assets eingegangen.

Kommunikation industrieller Assets

Die industrielle Kommunikation zwischen Steuerungen, Sensoren und Aktoren erfolgt zumeist über Feldbusse, die nicht nur spezielle Schnittstellen zur Kommunikation, sondern auch spezielle Hardware erfordern. Zunehmend wird die Kommunikation der Assets auf Ethernet-basierte Computernetzwerke übertragen, die auf standardisierte Technologien setzen. Dabei geht im Kontext von Internet of Things (IoT)-Anwendungen der Trend zum Message Queuing Telemetry Transport (MQTT) Protokoll und insbesondere in industriellen Anwendungen vermehrt zum Open Platform Communications Unified Architecture (OPC UA) Protokoll.

Das MQTT Protokoll findet vor allem Anwendung in der Machine-to-Machine Kommunikation (horizontal) und erfährt aufgrund geringer Latenzen und niedriger Bandbreitenanforderungen eine weite Verbreitung. Das Protokoll kommt aber auch für die Machine-to-Cloud Kommunikation (vertikal) zum Einsatz. Die Kommunikation des MQTT Protokolls folgt einem Publish/Subscribe Mechanismus nach dem Client-Server-Prinzip. Dabei steht der MQTT Broker als zentraler Server im Mittelpunkt der Kommunikation, zu dem MQTT Clients eine Verbindung aufbauen. Die Clients abonnieren in diesem Protokoll Topics (subscribe), die als Kanäle verstanden werden können, um Daten auf diesen zu empfangen. Im Beispiel in Abb. 15.6 sendet Client A ein Datenpaket unter Angabe eines Topic T an den Broker (publish). Client B und C haben das entsprechende Topic T beim Broker abonniert (subscribe). Das von Client A übermittelte Datenpaket wird anschließend vom Broker an die Clients B und C gesendet (publish).

Abb. 15.6
figure 6

MQTT Kommunikationsschema mit publish/subscribe Mechanismus

Full size image

Einen weiteren Kommunikationsstandard für Assets stellt OPC UA dar, der über den reinen Datenaustausch hinaus noch zahlreiche weitere Informationen des Assets bereitstellt. OPC UA zielt auf eine Machine-to-Machine Kommunikation (horizontal) ab, erlaubt aber gleichzeitig auch eine vertikale Vernetzung von Assets sowie zu unterschiedlichen Anwendungen in der Automatisierung wie zum Beispiel Leitsystemen. Die OPC UA Kommunikation erfolgt überwiegend nach dem Client-Server-Prinzip (vgl. Abb. 15.7). Assets können gleichzeitig Client und Server sein. Zur Bereitstellung von Daten wird die Serverrolle und zur Nutzung der Daten anderer OPC UA Teilnehmer wird die Rolle des Clients eingenommen. Damit beide Rollen eingenommen werden können, müssen diese auch entsprechend implementiert sein.

Abb. 15.7
figure 7

OPC UA Client-Server-Prinzip mit unterschiedlichen Teilnehmern

Full size image

Die OPC UA Spezifikation wird in 15 Teilspezifikationen beschrieben. Auszugsweise werden im Folgenden die wichtigsten Eigenschaften zum Datenaustausch zusammengefasst:

  • Security Model: Die Spezifikation sieht eine verschlüsselte und somit sichere Kommunikation vor.

  • Information Model: Das Information Model gibt Aufschluss über die verfügbaren Informationen und Funktionalitäten. Diese sind in einer Baumstruktur abgebildet. Die Baumknoten beschreiben eine Maschine oder Anlage über Objekte, Eigenschaften, Regeln, Funktionen und Ereignisse.

  • Data Access: Das Information Model und die angebotenen Informationen sind über synchrone Standardfunktionen wie browse, read und write verfügbar. Mit den genannten Standardfunktionen können die Knoten und die über diese bereitgestellten Daten abgerufen und bearbeitet werden. Darüber hinaus ist ein Datenmonitoring über subscriptions vorgesehen, wobei die Daten asynchron zum Zeitpunkt der Änderung einer Variablen übertragen werden können. Die Datenübertragung findet über die zustandsbehaftete Kommunikation TCP statt und ermöglicht damit eine direkte Verbindung zwischen Client und Server (one-to-one).

  • PubSub: Über das zustandlose User Datagram Protocol (UDP) wird eine voneinander unabhängige Verbindung von OPC UA Publisher und Subscriber möglich. Die OPC UA Publisher senden über Multicast Internet Protocol (IP)-Adressen Daten in ein Netzwerk (one-to-many). OPC UA Subscriber können die entsprechenden Datenströme empfangen, ohne eine direkte Verbindung zum OPC UA Publisher aufzubauen. Die Anforderung der Datenströme muss hierfür im Netzwerk bekannt gemacht werden. Die darunterliegende Technologie der IP-Multicasts beschränkt sich auf lokal kontrollierte Subnetze, da ein Multicast in das Internet durch die Internet Service Provider eingeschränkt wird.

DTaaS mit Zugang zu industriellen Daten

Das DTaaS-Konzept ermöglicht durch den DT Model Service die Beschreibung des Digitalen Zwillings inklusive der Verknüpfung mit den für die jeweilige Anwendung benötigten Assetdaten. Darüber hinaus ist auch ein bidirektionaler Zugriff auf die Realdaten industrieller Assets durch Cloud- und Webdienste über die DT Runtime möglich. Für die Kommunikation mit industriellen Assets wird über die DT Communication Assets eine Abstraktionsschicht für die Einbindung verschiedener Kommunikationsprotokolle für Assets bereitgestellt. Demzufolge fungiert der DTaaS als abstrakte Middleware für die Kommunikation zwischen industriellen Assets und dem Digitalen Zwilling sowie weiteren Cloud- und Webanwendungen (vgl. Abb. 15.5). Der DTaaS als abstrakte Middleware führt zu den folgenden Vorteilen:

  • Reduktion der Kommunikationslast:

    Mit Datenverbindungen für \(m\) Anwendungsinstanzen des Digitalen Zwillings und \(n\) Assets ergeben sich über die Middleware insgesamt \(n+m\) Kommunikationsschnittstellen. Würden die \(m\) Anwendungsinstanzen dagegen mit den \(n\) Assets jeweils one-to-one verbunden werden, wären \(n\cdot m\) Kommunikationsschnittstellen erforderlich. Durch die Middleware ist nicht nur der Implementierungsaufwand für die Schnittstellen deutlich geringer, sondern auch die Kommunikationslast, da deutlich weniger Einzelverbindungen instanziiert werden müssen. Die Reduktion und die Begrenzung der Kommunikationslast für die Assets ist eine wichtige Eigenschaft, um den Digitalen Zwilling skalierbar zur Verfügung zu stellen. Eine one-to-one Verbindung mit mehreren Anwendungen kann außerdem bei leistungsschwachen Assets (z. B. industrielle Steuerungssysteme mit begrenzten Rechenressourcen) zu einer zu hohen Kommunikationslast führen und damit Störungen verursachen. Durch die Kontrolle des Kommunikationsflusses können redundante Abfragen gebündelt werden. Dies reduziert unter anderem den Aufwand, der in den Ausbau der lokalen Kommunikationsinfrastruktur investiert werden muss.

  • Zugriffsschutz:

    Der zentrale Zugriff erlaubt die Nutzung von Berechtigungskonzepten bei lesenden und schreibenden Zugriffen. Dieser Schritt ist unabdingbar zur Vermeidung von Missbrauch und einer unberechtigten Informationsbeschaffung, insbesondere von sensiblen technischen oder personenbezogenen Daten.

  • Übergang zur Echtzeitkommunikation:

    Die Bündelung von Datenströmen über eine zentrale Instanz erlaubt einen definierten Übergang von der Echtzeitkommunikation zur Nicht-Echtzeitkommunikation. Dabei können Daten bedarfsgerecht gepuffert und vorgefiltert bereitgestellt werden.

4 Realisierung einer Digital Twin as a Service Plattform

Am Virtual Automation Lab (VAL) der Hochschule Esslingen wird eine Digital Twin as Service Plattform (VAL DTaaSP) entwickelt, welche auf den vorgestellten Konzepten basiert. Mit der VAL DTaaSP können verschiedene Microservices kombiniert werden, sodass die Erstellung, der Betrieb und die Verfügbarmachung Digitaler Zwillinge standortübergreifend und endgeräteunabhängig ermöglicht wird.

Architekturübersicht der VAL DTaaSP

Entsprechend der in Abb. 15.8 dargestellten Architekturübersicht besteht die VAL DTaaSP aus verschiedenen internen Basisfunktionen, wie einer Benutzerverwaltung, der Verwaltung von Microservices und einfachen Diensten zum Speichern von Daten.

Abb. 15.8
figure 8

Architekturbild der VAL Digital Twin as a Service Plattform (VAL DTaaSP)

Full size image

Durch die DT Communication Assets wird die Kommunikation über die unterstützten Protokolle (OPC UA, MQTT, …) zu den industriellen Assets abstrahiert und über die einheitliche Schnittstelle DT Communication Web verfügbar gemacht. Zu integrierende Assets müssen in DT Communication Assets lediglich bekannt gemacht werden. Hierzu wird die Zugänglichkeit über eine IP-Adresse, das eingesetzte darunterliegende Protokoll und ein Zugangs-Port konfiguriert. Fortan stehen die Daten der Assets für Cloud- und Webanwendungen zur Verfügung. In der VAL DTaaSP bündelt die DT Communication Assets protokollspezifische Anfragen identischer Informationen und sorgt damit für eine Reduktion des Kommunikationsaufwandes bei einzelnen Assets sowie für eine Reduktion der Kommunikationslast im Netzwerk. Darüber hinaus können Datenflüsse auch hinsichtlich vorhandener Zugriffsbeschränkungen limitiert werden.

Die DT Model und DT Runtime ermöglichen die Auslieferung an externe Dienste sowie Instanziierung und Ausführung eines Digitalen Zwillings. Aufgrund der Microservice-Architektur kann die Plattform beliebig skaliert werden und lässt somit die gleichzeitige Nutzung durch eine Vielzahl von Anwendungen von unterschiedlichen Standorten zu.

Die benötigte Infrastruktur für die VAL DTaaSP kann in Public Cloud oder in Edge Cloud Umgebungen zur Verfügung gestellt werden. Die Vorteile der Public Cloud liegen in der einfachen Verfügbarmachung und der Nutzung von schnell skalierbaren Ressourcen. In der Edge Cloud hingegen können aufgrund der lokalen Netzwerkinfrastruktur niedrigere Kommunikationslatenzen erreicht werden. Unter dem Einsatz von Time Sensitive Networking (TSN) kann dies bis zu einer deterministischen und echtzeitfähigen Kommunikation weiterentwickelt werden.

VAL 3D-Webstudio

Das VAL 3D-Webstudio stellt das User-Frontend zur Modellierung und Visualisierung der Digitalen Zwillinge auf der VAL DTaaSP bereit. Es ist ein zentraler Webdienst um die geometrische Darstellung, die Verhaltensmodellierung und die Interaktionsmöglichkeiten zu erstellen und zu bearbeiten. Darüber hinaus ermöglicht das VAL 3D-Webstudio die Modellierung der Verknüpfungen zwischen Live-Daten der industriellen Assets mit den Szenenvariablen des Digitalen Zwillings. Die Szenenvariablen dienen zur Manipulation von Objekteigenschaften zur Änderung von Eigenschaften zur Laufzeit des Digitalen Zwillings. Das VAL 3D-Webstudio wird als browserbasierte Webanwendung bereitgestellt und ermöglicht damit eine standortunabhängige Modellierung und Visualisierung der Digitalen Zwillinge auf allen internetfähigen Endgeräten mit Webbrowsern. Für die Modellierung im VAL 3D-Webstudio können Geometriemodelle über verschiedene CAD Austauschformate importiert werden. Die integrierten Geometriemodelle lassen sich anschließend durch Definition von Freiheitsgraden kinematisieren und mit Szenenvariablen verbinden, sodass Objekteigenschaften (z. B. Position, Rotation oder Sichtbarkeit) in Abhängigkeit von Realdaten dynamisch beeinflusst werden. Die dynamischen Änderungen erfolgen auf Grundlage eines objektspezifischen Verhaltensmodells. Neben der grafischen Modellierung in der 3D-Szene und über einen Objektbaum steht zur Programmierung spezifischer Modelleigenschaften ein browserbasierter JavaScript Code-Editor zur Verfügung.

Über die Beschreibung des Digitalen Zwillings hinaus wird im VAL 3D-Webstudio die Integration von Services aus externen Cloudplattformen ermöglicht. Die Anbindung erfolgt ebenfalls über den JavaScript Code-Editor, womit die Funktionen direkt in den Digitalen Zwilling integriert werden können.

Der auf diese Weise modellierte Digitale Zwilling wird aus dem DT Model Service abgerufen und anschließend in dem DT Runtime Service unter Berücksichtigung der Live-Daten industrieller Assets und Daten externer Microservices zyklisch zur Ausführung gebracht.

VAL HoloDesk

Der Digitale Zwilling inklusive der berechneten Daten kann während der Ausführung von externen Diensten abgerufen und weiterverarbeitet werden. So können Digitale Zwillinge mit der am Virtual Automation Lab der Hochschule Esslingen entwickelten VAL HoloDesk-App in einer Mixed Reality-Anwendung auf modernen Visualisierungsendgeräten (z. B. Virtual Reality (VR)-Brillen, Augmented Reality (AR)-Brillen, Tablets) genutzt werden. Über die VAL DTaaSP kann das im VAL 3D-Webstudio erstellte Modell des Digitalen Zwillings an die VAL HoloDesk-App ausgeliefert und betrieben werden. Dabei bleiben alle Datenverbindungen zu den Assets bestehen. Somit ist beispielsweise eine steuerungsgekoppelte Visualisierung des Digitalen Zwillings einer Maschine oder Anlage über eine Virtual Reality-Brille oder Augmented Reality-Brille möglich.

5 Anwendungsbeispiele

Die VAL DTaaSP ermöglicht durch die servicebasierte Bereitstellung des Digitalen Zwillings vielfältige Anwendungen über den gesamten Lebenszyklus einer Anlage hinweg. Im Folgenden sind ausgewählte Anwendungen zusammengefasst.

Mixed-Reality-in-the-Loop Simulation (MRiLS)

Die Mixed-Reality-in-the-Loop Simulation koppelt Visualisierungs- und Interaktionsmethoden der Mixed Reality mit Methoden der X-in-the-Loop Simulation (vgl. [7]) und eröffnet mit der servicebasierten Bereitstellung des Digitalen Zwillings durch den DTaaS Ansatz vielfältige Anwendungspotenziale während des gesamten Lebenszyklus der Anlage. Beispielsweise kann der Digitale Zwilling für die Virtuelle Inbetriebnahme, die Schulung sowie für das 3D-Monitoring eingesetzt werden. Der Digitale Zwilling kann dadurch flexibel auf verschiedenen Mixed Reality-Endgeräten (VR-Brillen, AR-Brillen, Tablets) bereitgestellt und einfach mit externen Simulationstools und/oder einer industriellen Steuerung einer realen Anlage gekoppelt werden.

Abb. 15.9 zeigt eine Übersicht ausgewählter Einsatzszenarien, die unter Verwendung der VAL DTaaSP umgesetzt wurden.

Abb. 15.9
figure 9

Anwendungsmöglichkeiten der MRiLS basierend auf der VAL DTaaSP

Full size image

Sprachinteraktion mit einem Industrieroboter

Neben der immersiven Visualisierung und Bereitstellung des Digitalen Zwillings, ermöglicht der servicebasierte Ansatz der VAL DTaaSP eine intuitive Sprachinteraktion mit dem Digitalen Zwilling oder einer realen Anlage. Abb. 15.10 zeigt den beispielhaften Einsatz einer KI-basierten Sprachverarbeitung zur Kollaboration mit einem Digitalen Zwilling eines Kuka Knickarm-Roboters, der über eine Beckhoff-Steuerung betrieben wird. In der VAL DTaaSP steht ein entsprechender Digitaler Zwilling des Roboters zur Verfügung, der über OPC UA mit der Steuerung verbunden ist. Durch Sprachein- und ausgaben können Zustands- und Steuerungsinformationen des Roboters abgerufen werden. So kann der Anwender beispielsweise per Sprachbefehl den aktuell eingestellten Override abfragen. Dieser wird anschließend als Audio-Feedback an den Nutzer zurückgeliefert. Diese Erweiterung der Interaktionsmöglichkeiten um die Sprachinteraktion ist unter anderem zur Bedienerunterstützung und in Schulungsszenarien von zentraler Bedeutung, da beispielsweise komplizierte Menüführungen vereinfacht werden können und somit der visuelle Fokus nicht vom Ort des Geschehens abgelenkt werden muss.

Abb. 15.10
figure 10

Sprachinteraktion mit einem Industrieroboter unter Verwendung der VAL DTaaSP

Full size image

Durch den DTaaS Ansatz ist die Umsetzung des Szenarios, also die Kopplung von Sprachverarbeitungsdiensten und industriellen Steuerungen, auf einfache Weise möglich. Die Anwendung wurde so gestaltet, dass der Anwender über das Mikrofon der AR-Brille Sprachbefehle absetzen kann. Die entstehende Audiosignalsequenz wird an Clouddienste zur Sprachverarbeitung (Google Cloud, Amazon AWS, Microsoft Azure, …) übermittelt, dort mittels Speech-To-Text in einen String umgewandelt und wieder an die VAL DTaaSP zurückgegeben. Basierend auf den Strings werden die Befehle vom Digitalen Zwilling erkannt und weiterverarbeitet. So kann beispielsweise als Antwort eine Sprachausgabe erzeugt werden, indem die Antwort in Form eines Strings von der VAL DTaaSP generiert und an einen Sprachverarbeitungsdienst übermittelt wird, um dort mittels Text-To-Speech in ein Audiosignal umgewandelt zu werden. Das Audiosignal kann dann über die Lautsprecher der AR-Brille ausgegeben werden. Die VAL DTaaSP als Middleware erlaubt den einfachen Zugriff auf die Steuerungsdaten des Roboters und auf die externen Sprachverarbeitungsdienste. Gleichzeitig dient diese als Entwicklungs- und Ausführungsumgebung zur Umsetzung der Anwendungen, so dass weitere Clouddienste in die Umgebung einfach integriert werden können und somit bspw. unter Verwendung von Clouddiensten zur Sprachübersetzung eine integrierte Dolmetscherfunktion realisierbar wird.

Synthetische Trainingsdatenerzeugung

Kontextsensitives Einblenden von Informationen wie beispielsweise der Maschinen- und Prozess-Daten mittels AR ist eine weitere Assistenzfunktion, die durch das DTaaS-Konzept ermöglicht wird. Zu diesem Zweck ist es notwendig, dass die im Blickfeld des Nutzers befindlichen Maschinen- oder Anlagenkomponenten automatisch erkannt werden, um dem Nutzer die entsprechenden anlagenspezifischen Informationen anzeigen zu können. Die VAL DTaaSP ermöglicht dabei als Middleware den Zugriff auf maschinenspezifische Daten und verknüpft diese mit einem im Kamerabild der AR-Brille erkannten Objekt der Maschine oder Anlage. Zur Objekterkennung können bestehende Deep Learning Algorithmen eingesetzt werden.

Notwendige Bedingung für den Einsatz der Deep Learning Algorithmen zur Objekterkennung in Bildern oder Videosequenzen sind umfangreiche Trainingsdatensätze, in denen die Ausgangsdaten mit Objektklassen gelabelt sein müssen. Diese Datensätze anhand realer Bilder manuell zu labeln und aufzubauen ist sehr zeitintensiv und führt zwangsläufig zu kleinen Trainingsdatensätzen, was meist zu einer hohen Fehlerquote bei der Objekterkennung führt.

Zur Bewältigung dieser Problemstellung kann die VAL DTaaSP zur synthetischen Trainingsdatengenerierung eingesetzt werden [8]. Damit können Digitale Zwillinge von zu erkennenden Objekten für die synthetische Generierung von Bildern mit einer virtuellen 3D-Szene sowie das automatisierte Labeling genutzt werden. Der Prozess der Trainingsdatengenerierung kann mit diesem automatisierten Ansatz bedeutend beschleunigt und die Qualität sowie Reproduzierbarkeit der Trainingsdaten systematisch sichergestellt werden.

In Abb. 15.11 wird das Prinzip der synthetischen Trainingsdatengenerierung und der Objekterkennung mittels der VAL DTaaSP einer Anwendung zur Objekterkennung gezeigt. Anhand der VAL DTaaSP und dem darin modellierten Digitalen Zwilling des Roboters wird ein neuronales Netz als Microservice eingebunden und mit mehreren tausend synthetisch generierten und automatisch gelabelten Bildern trainiert. Das neuronale Netz benötigt zum Training keine realen Bilder des Roboters und erkennt diesen und seine Komponenten (annotiert in Abb. 15.11 rechts) mit sehr hoher Trefferquote.

Abb. 15.11
figure 11

Synthetische Trainingsdatenerzeugung aus dem Digitalen Zwilling für die Objekterkennung mit Deep Learning Algorithmen auf Basis der VAL DTaaSP

Full size image

Innerhalb der VAL DTaaSP können im VAL 3D-Webstudio Digitale Zwillinge auf einfache Weise ausgewählt und mit wenigen zu konfigurierenden Parametern dem Training eines neuronalen Netzes zugeführt werden. Durch die Verbindung von Digitalen Zwillingen mit Cloud- und Webtechnologien können die notwendigen Funktionen und erforderlichen Hardwareressourcen für das Training neuronaler Netze auf einfache Weise instanziiert und bereitgestellt werden. Das trainierte neuronale Netz wird dem entsprechenden Digitalen Zwilling zugeordnet und kann anschließend über die Schnittstellen der VAL DTaaSP abgerufen werden.

6 Zusammenfassung

Im Maschinen- und Anlagenbau entstehende Digitale Zwillinge bieten großes Anwendungspotenzial über die frühen Phasen des mechatronischen Entwicklungsprozesses hinaus. Die Verknüpfung von Digitalen Zwillingen mit modernen Cloud- und Webtechnologien wie Browsern, Webservern oder Clouddiensten bieten dabei wechselseitige Mehrwerte, die neue Anwendungspotenziale eröffnen. Beispiele sind die standort- und endgeräteunabhängige Verfügbarmachung von Digitalen Zwillingen über das Internet für Monitoring-Zwecke oder die Erweiterung von Digitalen Zwillingen um Sprachverarbeitungsdienste für virtuelle Schulungsszenarien. Der Beitrag beleuchtet dazu technologische Herausforderungen für die Verknüpfung zwischen Cloud- und Webtechnologien und den industriell geprägten Soft- und Hardwaresystemen des Anlagen- und Maschinenbaus. Das präsentierte Lösungskonzept der VAL Digital Twin as a Service Plattform erweitert Digitale Zwillinge um Kommunikations- und Serviceansätze der Cloud- und Webtechnologien und steigert damit die Verfügbarkeit und Vernetzungsfähigkeit von Digitalen Zwillingen. Die Tragfähigkeit des Digital Twin as a Service Ansatzes wird auf Basis der Anwendungsszenarien Mixed-Reality-in-the-Loop Simulation, Sprachinteraktion und synthetische Trainingsdatenerzeugung für KI-Anwendungen dargestellt.