Serie: Konzeption & Aufbau einer IIoT-Lösung Topologie und Protokolle im IIoT

Anbieter zum Thema

Parasoft® Deutschland GmbH

NetModule AG

TXOne Networks

Amazon Web Services Germany GmbH

Siemens AG

mehr weniger

Amazon Web Services EMEA SARL,

weniger

In dieser wöchentlich erscheinenden Serie konzentrieren wir uns auf die Entwicklung einer erfolgreichen IIoT-Plattform. In diesem siebten Teil behandeln wir die Integration verschiedener Systeme in eine flexible Komplettlösung.

Ein wesentliches Merkmal jeder IIoT-Anwendung besteht in der Erfassung und Zusammenführung von Daten, die aus dezentral verteilten Industrieanlagen stammen. IIoT-Plattformen müssen in der Lage sein, diesen kontinuierlichen Datenstrom zu verarbeiten. Außerdem sollten sie es ermöglichen, bereits vorhandene Geräte-Datenquellen von Plattformkunden auf sichere Weise einzubinden.

Dies wiederum erfordert eine nahtlose Integration des Plattform-Betriebssystems und der Software aller angebundenen Geräte. Das betrifft zum Beispiel die Clientsoftware zur Kommunikation mit Clouddiensten oder Containern sowie Protokolladapter von dezentralen Geräten, die ihrerseits Daten von anderen Systemen erfassen. Insbesondere die Integration proprietärer Geräte in den Anlagen- und Maschinenparks stellt im Hinblick auf die IT-Sicherheit oftmals eine nicht zu unterschätzende Herausforderung dar.

Die Wahl der passenden Gerätetopologie

Im einfachsten Fall kommuniziert ein IoT-Gerät direkt mit der Cloud-Plattform. In solchen Fällen handelt es sich um eine 1:1-Zuordnung zwischen Datenquelle und Übertragungssystem. Die Cloud agiert dabei als Datenempfänger und interpretiert und verarbeitet die Daten.

Komplizierter wird es jedoch, wenn mehrere Geräte über Gateways angebunden sind. In diesem Fall sieht ein Clouddienst immer nur das Gateway des betreffenden Datenstroms. Das bedeutet, die IIoT-Plattform muss unterscheiden können, von welchem Gerät ein bestimmter Datensatz stammt. Diese eindeutige Identifikation erfordert folglich die genaue Kenntnis der vollständigen Gateway-Topologie. Noch komplexer wird diese Herausforderung, wenn sich hinter einem Gateway keine direkte Datenquelle, sondern weitere Gateways verbergen. Ratsam ist es daher, eine klare virtuelle Trennung zwischen Quellgeräten und Gateways einzuführen. Dies gilt auch dann, wenn einzelne Geräte eine Doppelrolle spielen und gleichzeitig beide Funktionen erfüllen. In fortgeschrittenen Lösungen beherrscht das Gerätemanagement der Plattform den Umgang mit verschiedenen Hierarchien aus reinen Datenquellen, Gateways und deren Mischformen. Außerdem ist es in der Lage, eventuell notwendige Datenmodell- und Protokolltransformation schon während der Übertragung mit zu erledigen.

Technologie

IoT-Gateway-Devices: Orientierung im Gerätedschungel

Die Entscheidung für ein passendes Protokoll

Bei komplexen Gerätetopologien muss die IIoT-Plattform unterschiedliche Protokolle und Protokolltransformationen unterstützen. Dabei geht es sowohl um Protokolle, die Produktionsdaten in die Cloud transportieren, als auch um solche, die dezentrale IoT-Geräte mit Aktualisierungen und Konfigurationsinformationen versorgen. Als Firewall-freundlich gelten dabei meist solche Protokolle, die zum Beispiel über die ausgehenden http- beziehungsweise https-Ports 80 oder 442 kommunizieren.

Welche Protokolle konkret verwendet werden sollen, ergibt sich in der Regel aus dem Dialog mit den IT-Sicherheitsverantwortlichen des Kunden. Viele Unternehmen formulieren dabei spezielle Anforderungen insbesondere an solche Protokolle, die Daten aus ihren Produktionsnetzwerken in die Cloud transferieren, etwa im Hinblick auf Verschlüsselung. Manche von ihnen lassen beispielsweise keine Protokollumschaltung von http auf den WebSocket-Port 80 zu. Oder sie wünschen für den ausgehenden Datenverkehr eine Begrenzung auf bestimmte IP-Adressen. Plattformseitig hat dies Konsequenzen – vor allem für den Lastenausgleich.

Multi-Cloud-Szenarien, Container, DDoS-Bedrohungen

Cloud Load Balancing gewinnt an Relevanz

Vielfalt der Protokolle beherrschen

Beim Lösungsdesign sollten solche Auswirkungen verschiedener Protokollalternativen stets mitbedacht werden. Die AWS-Cloud nutzt intern das offene Maschine-zu-Maschine-Protokoll MQTT (Message Queuing Telemetry Transport) für den Datentransfer von IoT-Geräten zum Nachrichtenbroker in der Cloud. Optional stellt AWS dafür aber auch eine Firewall-freundliche https-Version zur Verfügung.

Umgekehrt muss die IIoT-Plattform zur Kommunikation von der Cloud in Richtung dezentraler IoT-Geräte aber auch etliche branchen- und gerätespezifische Protokolle unterstützen. In der Automatisierungsbranche betrifft dies zum Beispiel die Protokollfamilie OPC UA oder den BACnet-Standard in der Gebäudeautomatisierung. Da inzwischen viele hundert solcher Spezialprotokolle existieren, benötigt eine offene IIoT-Plattform einen Mechanismus, um neue Protokolle schnell und aufwandsarm zu integrieren.

#experte

Internet of Things

HTTP, XMPP, CoAPP und MQTT: IoT-Protokolle für die Kommunikation

Überlegungen zum Datentransfer

In der Praxis liefern viele dezentrale Quellgeräte ihre Daten keineswegs in protokollkonformer Form: Sofern das Quellprotokoll nicht Cloud-kompatibel ist, muss es zunächst auf das jeweilige Transportprotokoll transformiert werden. OPC UA-Nachrichten lassen sich beispielsweise in eine MQTT-Nachricht einhüllen und via https transportieren. Denn ein guter Core Message Broker terminiert sowohl MQTT als auch https und leitet die Nutzlast anschließend an nachgelagerte Systeme weiter.

Da viele industrielle Protokolle ihr jeweiliges Datenmodell zusammen mit einem Transportmodell definieren, setzt ein erfolgreiches Plattformdesign auch ein semantisches Verständnis der Protokolle voraus. Nur dann nämlich lassen sich die damit transferierten Daten in der Cloud adäquat weiterverarbeiten.

Im nächsten Teil der Serie geht es um die Frage der Anbindung verschiedener Komponenten und die Frage, wie die IoT-Daten in die Cloud kommen. Gerade diese Faktoren spielen für den Erfolg einer IIoT-Plattform eine wichtige Rolle.

* Kathleen deValk arbeitet als Chief Architect Siemens MindSphere.

(ID:46416564)