Kommunikation mit physikalischen Geräten

Manche Geräte werden zukünftig in der Lage sein, direkt über das Internet Daten zu senden und zu empfangen. Der im SPS-MAGAZIN 8/2015 erschienene Artikel ‚Datenaustausch über alle Netzwerkebenen und Protokolle‘ befasste sich ausführlich mit diesem Thema. Wie bei FDT üblich, wird ein Kommunikations-DTM genutzt, der das jeweilige, vom Gerät verwendete, IoT-Protokoll unterstützt – z.B. eines der typischen IoT Protokolle, wie AMQP oder DDS. Bei Industrie 4.0 wird derzeit sogar über das Tunneln von OPC UA über AMQP nachgedacht. Der Device-DTM nutzt ebenfalls die Dienste des Kommunikation-DTMs, um Daten mit dem Gerät auszutauschen. Der Kommunikation-DTM verwaltet die Verbindung mit dem Gerät; also wie das Gerät mit der Cloud gekoppelt oder die Verbindung gesichert wird. Ein solcher Kommunikations-DTM ist typischerweise integraler Bestandteil der Cloud-Frame-Applikation, da diese Funktionen stark mit anderen Applikationsfunktionen verbunden sind, z.B. mit der Benutzer- und Berechtigungsverwaltung. Werden viele Geräte auch zukünftig direkt mit dem Internet verbunden sein? Es scheint wahrscheinlicher, dass spezielle IIoT-Datensammler oder -Bridges zu Einsatz kommen. Diese verbinden die über klassische Industrienetzwerke angeschlossenen Sensoren/Aktoren mit der Cloud. In diesen Fällen werden Gateway-DTMs verwendet, die virtuelle Repräsentanten für die Datensammler oder Bridges darstellen und entsprechende Kommunikationsdienste bereitstellen.

Interaktion mit anderen IoT-Services

Andere IoT-Services verwenden Beschreibungsmodelle, um z.B. ein System zu planen oder zu simulieren (Stichwort: Digitale Fabrik). Damit ein FDT-Service sinnvoll mit anderen Services interagieren kann, werden Referenzen zwischen den Beschreibungsmodellen und den DTMs benötigt, die sich auf die gleichen Geräte beziehen. Die Beschreibungsmodelle werden in CAE-Tools verwendet, um den mechanischen und elektrischen Aufbau einer Maschine oder Anlage zu planen. Idealerweise beziehen diese Tools die Beschreibungsmodelle auch automatisch aus einem zentralen Store – und bieten damit völlige Transparenz für den Anwender. Die in den CAE Tools erzeugte mechanische/elektrische Systembeschreibung kann mittels standardisierter Beschreibungsmodelle (z.B. AutomationML) an die FDT-Service-Cloud weitergegeben werden. Diese nutzt die bereitgestellten Informationen dann, um entsprechende DTMs automatisch aus dem Store zu laden und sie für das Engineering, die Konfiguration und Diagnose der Automatisierung (z.B. SPSen, Sensoren/Aktoren, Antriebe oder HMIs) zu verwenden.

Fazit

Aus Sicherheitsgründen wird das Arbeiten aus der Cloud mitunter überhaupt nicht oder nur für bestimmte Anwendungsfälle erlaubt sein, auch wenn das technisch durchaus möglich wäre. Außerdem gibt es in der Praxis sicherlich Fälle, in denen keine Internetverbindung vorhanden ist, auch wenn das in Zukunft wohl nur noch vereinzelt vorkommen wird. Die vorgestellten FDT-Konzepte funktionieren sowohl lokal sowie in der Cloud und lassen sich beliebig kombinieren. DTMs können nicht nur in lokalen Software-Tools sondern auch in der Cloud verwendet werden. Lokale Tools können mit der Cloud synchronisiert werden – z.B. wenn der Anwender gerade im Büro ist und eine Internetverbindung hat. Bereits jetzt besteht ein großer Vorteil des FDT-Konzeptes darin, dass auch nicht internetfähige Geräte in einem IIoT-System über DTMs abgebildet werden können. FDT adressiert die Anwendungsfälle, die bei IoT-Plattformen typischerweise nicht adressiert werden und bringt somit schon das meiste mit, was für System Engineering, Konfiguration oder Diagnose benötigt wird. Einzig folgende Erweiterungen des Standards sind notwendig, um herstellerübergreifende Lösungen zu realisieren:

  • • Webfähige DTM-User-Interfaces
  • • Unterstützung von IoT-Protokollen
  • • Referenz zu anderen Beschreibungsmodellen, z.B. eCl@ass, AutomationML

Sobald diese Erweiterungen realisiert werden, steht der FDT-Technologie die Welt des IIoT endgültig offen.