Unbestritten ist inzwischen, dass klassische Feldbus-Systeme wie Devicenet oder Profibus durch industrielle Ethernet Busse wie Profinet, Ethercat oder Ethernet/IP mittelfristig abgelöst werden. Dies belegt auch die jährliche Betrachtung der Marktanteile von Bussystemen durch die Firma HMS, in der 2019 klassische Feldbusse erstmals rückläufig sind. Somit ist zumindest klar, dass analog zur IT auch in der Automatisierung Ethernet als Übertragungsmedium bei kabelgebundenen Verbindungen zukünftig gesetzt ist. Dennoch beherrschen mit den Industrial Ethernets weiterhin proprietäre Standards die Feld- und Steuerungsebene. Das erschwert aktuell noch deutlich eine herstellerübergreifende Kommunikation. Doch auch hier zeigt sich durch breite Unterstützung von OPC UA als einheitlichen Standard Licht am Ende des Tunnels, auf dem Weg hin zu einer gemeinsamen und offenen Kommunikation in horizontaler und vertikaler Richtung. Zusätzlich gewinnen auch die aus der IT stammenden Ansätze des Datenaustauschs via API (Application Program Interface) oder via Protokollen wie MQTT und AMQP immer mehr Bedeutung in der Automatisierung, da es immer stärker darum geht, Daten von Automatisierungsgeräten in IT-Systeme zu übermitteln. Nachfolgend wird detailliert auf die einzelnen Technologien eingegangen und deren Vor- und Nachteile aufgezeigt.
MQTT
Message Queuing Telemetry Transport ist ein leichtgewichtiges Protokoll zur Datenübertragung. Im besten Fall können Pakete von lediglich zwei Byte realisiert werden, was speziell bei einer Vielzahl von Geräten und Nachrichten von Vorteil ist. Das, zusammen mit der einfachen Implementierung von MQTT, hat in den vergangenen Jahren dazu geführt, dass MQTT im IoT Umfeld sehr starke Verwendung gefunden hat. Allerdings ist bei MQTT zu beachten, dass es entgegen OPC UA ein reines Übertragungsprotokoll ist und kein erweitertes Framework liefert mit Funktionen wie einer semantische Datenbeschreibung oder Sicherheitsmechanismen. Das bedeutet, dass Sicherheitsmechanismen zur Absicherung der Verbindung separat implementiert werden müssen und auf beiden Seiten der Kommunikation deklariert werden muss, um was für eine Art von Daten es sich handelt und wie diese zu verstehen sind. Vom Aufbau her ist MQTT ein offenes Publish/Subscribe-Protokoll für indirekte 1-zu-n-Kommunikation. Das bedeutet, dass ein Publisher basierend auf Events Nachrichten mit einem bestimmten Topic an einen sogenannten Broker sendet. Der Broker leitet die entsprechende Nachricht an alle Subscriber weiter, die das entsprechende Topic abonniert haben. Bezogen auf einen Motor kann das z.B. bedeuten, dass dieser unter dem Topic Diagnose/Überstrom seine Serial-Nummer und den zugehörigen Wert an einen Broker übermittelt, wenn der eingestellte Grenzwert überschritten wird. Der Broker leitet die Nachricht dann an alle Abonnenten wie beispielsweise mobile Endgeräte von Servicetechnikern, Leitsysteme oder Cloud-Applikationen weiter.
Bei der Konfiguration der Publish/Subscribe-Kommunikation bietet MQTT noch einige nützliche Features. Retained Messages ermöglichen es zum Beispiel, dass die letzte gesendete Nachricht zu einem Topic beim Broker hinterlegt bleibt und einem neuen Subscriber direkt bei Anmeldung übermittelt wird. Daneben gibt es noch eine Last Will Nachricht, die ein Publisher beim Broker hinterlegen kann. Diese wird an alle Subscriber verschickt, wenn ein Gerät nicht mehr verbunden ist und sich zuvor nicht richtig abgemeldet hat. Auch wenn auf Seiten der Subscriber Verbindungsabbrüche vorkommen bietet, das Feature Persistent Session die Möglichkeit, dass verpasste Nachrichten im Broker gepuffert werden und dem Subscriber bei erneuter Anmeldung übermittelt werden. Als letztes bieten verschieden Quality-of-Service-Einstellungen noch drei Möglichkeiten, um sicher zu gehen, dass versendete Nachrichten bei genau einem, bei mehr als einem oder bei mindestens einem Subscriber angekommen sind. MQTT ist somit ein leicht zu beherrschendes Protokoll, dass sich ideal eignet, auf sehr ressourcenarmen Geräten implementiert zu werden und auch bei Unterbrechungen der Verbindung gewährleisten kann, dass die Daten ihr Ziel erreichen. Allerdings muss auf beiden Seiten bekannt sein, welche Daten kommuniziert werden und für die Datensicherheit vor allem des Brokers muss auf anderen Wegen gesorgt werden.
AMQP
Das Advanced Message Queuing Protocol ist neben MQTT das am weitesten verbreitetste Kommunikationsprotokoll im IoT-Umfeld. AMQP arbeitet dabei wie MQTT ebenfalls mit einem Broker und dem Publish/Subscribe-Prinzip.
Bei AMQP besitzt jeder Subscriber eine Warteschlange, in die Nachrichten mit abonnierten Topics vom Broker abgelegt werden. Die Nachrichten bleiben so lange in einer Warteschlange bis der Subscriber bestätigt hat, dass er die Nachricht empfangen hat. Die Warteschlangen sind somit auch ein Puffer für Nachrichten, falls ein Subscriber nicht immer verbunden ist. Kann eine Nachricht nicht an einen Empfänger übermittelt werden, bekommt der Publisher eine entsprechende Nachricht. Zudem können bei AMQP die Nachrichten auch um Meta-Daten ergänzt werden, die die Daten der Nachricht in Form von Attributen beschreiben und die vom Empfänger genutzt werden können. Der größte Unterschied zu MQTT stellt somit der erweiterte Funktionsumfang bei der Nachrichtenübermittlung von AMQP dar. Dieser bringt aber auch einen höheren Implementierungsaufwand und einen größeren Ressourcenbedarf mit sich. Die kleinste mögliche Paketgröße bei AMQP beträgt bereits 60 Byte. Daher gilt hier die Abwägung, ob die erweiterte Funktionalität von AMQP benötigt wird oder doch das noch einfachere MQTT ausreicht.
API/REST API
Application Program Interfaces entstammen dem Ansatz, Programme in funktionsbasierte Module zu unterteilen. Die einzelnen Module stellen Ihre öffentlichen Daten anderen Module über APIs zur Verfügung und holen benötigte Daten bei APIs anderer Module ab. APIs sind Strukturen mit verschiedenen Variablen, die vom zugehörigen Modul beschrieben werden und von anderen Modulen gelesen werden können. Sie entkoppeln somit den „privaten“ Code der Module von der Außenwelt. Das ermöglicht es, leichter wartbare Module zu erzeugen und fehlerhaften Code schneller zu identifizieren, da jedes Modul durch das Beschreiben der API mit den geplanten Kommandos und das Prüfen der erwarteten Ergebnisse für sich getestet werden kann. APIs lassen sich generell somit auf jeden Anwendungsfall exakt zuschneiden, sind aber hersteller-, anwendungs- und modulspezifisch und nicht standardisiert. Daher müssen APIs beschrieben werden, wie sie erreicht werden, welche Variablen sie enthalten und ob die Variablen nur Lese- oder auch Schreibrechte haben. Gerade beim Datenaustausch mit anderen Herstellern über APIs oder bei öffentlichen APIs ist die detaillierte Beschreibung wichtig, damit die „externen“ Programmierer wissen, wie sie die Schnittstelle nutzen können, da Ihnen das Wissen fehlt wie die hinter der API liegende Applikation arbeitet. REST steht für Representational State Transfer. REST ist kein eigener Standard oder ein Protokoll, sondern ein Architekturansatz für die Kommunikation innerhalb von verteilten Systemen.