Im Gegensatz zu den anspruchsvollen Prozessen in der Produktionstechnik mit sehr vielen Beteiligten und langen Lieferketten wurde in der etwas einfacher strukturierten Kommunikationstechnik schon vor Jahrzehnten mit der durchgängigen Digitalisierung begonnen. Angetrieben durch die kontinuierlichen Fortschritte der Halbleitertechnik und Embedded-Softwareentwicklung sowie die Nähe zur IT-Welt existiert hier insgesamt ein sehr hoher Digitalisierungsgrad. Über die Softwarefunktionen für Anwendungs-Proxy-Server, Datenagenten und Middleware-Lösungen ist auch die Idee des digitalen Zwillings in unzähligen Kommunikationsanwendungen zu finden. Daher gibt es beispielsweise im Internet der Dinge auch etliche allgemein anerkannte Standards in Bezug auf Protokolle und Datenschnittstellen, auf die die Produktionstechnik wohl noch etwas warten muss. Zwei einfache IoT-Praxisbeispiele für den Einsatz digitaler Zwillinge:

Beispiel 1: Der Daten-Stellvertreter

Bild 1. Für IoT-Funkverbindungen gibt es inzwischen zahlreiche Alternativen, die als Verbund eine nahezu weltweite Funkabdeckung ermöglichen. In Bezug auf den Datendurchsatz per Zeiteinheit existieren allerdings erhebliche Unterschiede. Um in einer größeren Anwendung einheitliche Benutzer- und Datenschnittstellen zu realisieren, lassen sich digitale Zwillinge als „Daten-Stellvertreter“ einsetzen. Mit einem solchen Funktionsbaustein sind dann auch Low Earth Orbit (LEO)-Satelliten für extraterrestrische IoT-Datenverbindungen zur Maschinenwartung nutzbar.

© SSV

IoT-Anwendungen bestehen in der Regel aus vier übereinander liegenden Schichten (Layer):

• 1. IoT-Device,
• 2. Connectivity,
• 3. Middleware und
• 4. der eigentlichen Applikationssoftware.

Hinzu kommt mit der IoT-Security eine fünfte funktionale Ebene als Querschnittstechnologie für die vier Layer. Die Middleware spielt in diesem Schichtenmodell eine besondere Rolle: Sie verbindet verschiedene, oft komplexe und bereits vorhandene Softwarebausteine, die ursprünglich nicht für einen gemeinsamen Einsatz konzipiert wurden.

Im letzten Teil dieser Artikelserie des IoT-Hotspot wurde unter dem Titel „Der digitale Zwilling im Praxiseinsatz“ ein industrielles IoT-Anwendungsbeispiel vorgestellt, in dem verschiedene Wireless Wide Area Network (WWAN) Verbindungen mit völlig unterschiedlichen Funkschnittstellen und Datendurchsätzen zum Einsatz kommen. Unabhängig von der WWAN-Bandbreite und den damit zusammenhängenden Latenzzeiten sowie Datenmengen pro Zeiteinheit sollen die Nutzer über einheitliche Schnittstellen – Webbrowser, VNC-Client, Remote Desktop – jederzeit auf aktuelle Maschinendatenbilder zugreifen können. Als mögliche alternative Funkverbindungen zwischen einem IoT-Maschinenmodem und einem Cloudservice sind LTE, NB-IoT oder IoT-LEO-Satelliten (LEO = Low Earth Orbit) vorgesehen, um einem Maschinenbauer den weltweiten Einsatz einer IoT-Retrofit-Lösung zu ermöglichen. Funkverbindungen zu Mobilfunkbasis- stationen sind technisch relativ einfach und daher weit verbreitet. Etwas anders sieht es mit der IoT-Satellitenkommunikation aus. Hier ist zurzeit noch etwas Pionierarbeit der Anwendungsentwickler erforderlich, um einige besondere Herausforderungen zu lösen.

LEO-Satelliten umkreisen die Erde in einer Höhe von einigen 100 km. Dadurch entstehen Umlaufzeiten zwischen 90 und 100 Minuten. Mit einem solchen Satellitenorbit ist keine permanente Funkverbindung zwischen der IoT-Kommunikationsbaugruppe in einer Maschine vor Ort und einem bestimmten Satelliten möglich. LEO-Satellitenbetreiber nutzen daher größere Satellitenschwärme, um die Erdoberfläche weitestgehend vollständig abzudecken und die Intervallzeiten der Funkverbindung je Standort zu reduzieren. Eine Kommunikationsbaugruppe (IoT Device) in der Maschine muss also permanent versuchen, eine (IoT-) Satelliten(daten)verbindung zu erzeugen, um ein Kommunikationszeitfenster zu finden. Alternativ lassen sich natürlich die täglichen Zeitspannen für mögliche (IoT-) Satelliten(funk)verbindungen pro Standort auch errechnen und in der IoT Device-Firmware hinterlegen. Einige LEO-Satellitenprovider stellen dafür spezielle Werkzeuge zur Verfügung (siehe Swarm Pass Checker in Bild 1).

Bei einer LTE-Verbindung zwischen Maschine und Cloudservice steht in der Regel ausreichend Bandbreite zur Verfügung, um einen Servicemitarbeiter direkt auf eine Webseite beziehungsweise den VNC-Remote-Desktop einer Maschinensteuerung zugreifen zu lassen. Basiert die Verbindung zwischen dem IoT-Maschinenmodem und einem Cloudservice allerdings auf einem LEO-Satellitenlink, ist das nicht möglich. In diesem Fall wird eine entsprechende Proxy-Webseite beziehungsweise ein Proxy-Remote-Desktop im digitalen Zwilling implementiert und mit den zuletzt von der Maschine erhaltenen Daten ausgestattet. Ein menschlicher Datennutzer sieht also die gewohnte Webseite bzw. VNC-Remote-Desktop-Darstellung. Der zugehörende Serverprozess läuft aber im digitalen Zwilling, also innerhalb der Cloudservice-Plattform und nicht in der Maschinensteuerung vor Ort. Zur Art und Weise des Fernzugriffs im Einzelfall, also entweder direkt auf die Server in der Maschinensteuerung oder aber alternativ auf Stell- vertreter-Instanzen in der Cloud, sollte der Nutzer über einen Datenqualitätsindikator informiert werden.

Um trotz der sporadischen LEO-Sattelitendatenübertragung eine ausreichende Datenqualität zu gewährleisten, lässt sich der digitale Zwilling mit einer Zeitreihendatenbank und einem Machine-Learning-basierten Algorithmus zur Zeitreihen- datenanalyse und Trendvorhersage ausstatten. Mit dieser Erweiterung lassen sich die unterschiedlichen Intervallzeiten einer Messdatenübertragung per LTE- oder LEO-Satellitenverbindung weitestgehend ausgleichen.

Beispiel 2: Der Sicherheits-Stellvertreter

Eine zum Daten-Zwilling vergleichbare Problematik ergibt sich, wenn bei den zuvor angesprochenen WWAN-Alternativen (LTE, NB-IoT, LEO-Satellit) eine Ende-zu-Ende-Sicherheitslösung auf der Basis von X.509-Zertifikaten nötig ist. Das dabei zum Einsatz kommende TLS- /DTLS-Protokoll lässt sich zwar problemlos mit einer IP-basierten LTE-Verbindung nutzen, aber schon beim NB-IoT-Einsatz ergeben sich in der Regel die ersten Hürden durch das zusätzlich verursachte Datenvolumen und die monatlichen Kosten des Datenplans. Da die LEO-Satellitenkommunikation überwiegend nicht einmal IP als Netzwerkprotokoll einsetzt, sondern stattdessen an die technisch bedingten Limitierungen angepasste Spezialprotokolle verwendet, ist der TLS/DTLS-Einsatz hier nicht möglich. Innerhalb einer Applikation mit derart unterschiedlichen WWAN-Technologien lässt sich daher kein einheitlich hohes X.509-Zertifikat-basiertes Cybersicherheitsniveau realisieren. Um den im ersten Beispiel angesprochenen Datennutzern für die Webbrowser- und VNC-Remote-Desktop-Fernzugriffe auf Maschinendaten eine einheitliche TLS-basierte Ende-zu-Ende-Security zu bieten, dient im Falle einer LEO-Satellitenverbindung der digitale Zwilling und nicht die Maschine als Endpunkt für eine beidseitige Authentifizierung (Mutual Authentication) mit X.509-Zertifikaten. Bild 2 illustriert die Zusammenhänge.

Der Autor: Klaus-Dieter Walter ist Mitglied der Geschäftsführung bei SSV Software Systems.

© SSV Software

Bei einer Mutual Authentication besitzen beide Kommunikationspartner jeweils ein eigenes X.509-Zertifkat mit dem dazugehörenden privaten Schlüssel (Server Key und Client Key). Darüber hinaus existiert auf beiden Seiten mindestens ein CA-Zertifikat (X.509 CA), um andere Zertifikate prüfen zu können. Der gesamte beidseitige Authentifizierungsprozess läuft in fünf Schritten ab. Es beginnt mit einem „Client Hallo“, das durch ein „Server Hello“ beantwortet wird. Gleichzeitig sendet der Server sein X.509-Zertifikat und fordert das Client-Zertifikat an. Der Client prüft die digitale Unterschrift des Server-Zertifikats mit Hilfe des X.509 CA. Verläuft diese Prüfung positiv, antwortet der Client mit seinem Zertifikat. Bei einer negativen Prüfung bricht der Client die Verbindung ab. Abschließend erfolgt die Server-seitige Prüfung des Client-Zertifikats. Nur bei einem ebenfalls positiven Prüfergebnis erfolgt anschließend die Nutzdatenübertragungsphase, ansonsten ein Verbindungsabbruch. Im Falle einer LTE-Verbindung lässt sich die Mutual Authentication direkt zwischen dem Rechnersystem des Datennutzers und dem IoT-Maschinenmodem als Server vor Ort durchführen – das sicherheitstechnische Optimum. Beim Einsatz eines LEO-Satellitenlinks bildet hingegen der digitale Zwilling den Server-Endpunkt. Die Datenauthentizität und Integrität sind also relativ unsicher. Verbessern lässt sicher dieser Zustand durch den Einsatz eines Message Authentication Codes (z. B. ein HMAC-Verfahren) für die Satellitenverbindung zum digitalen Zwilling.