Erschienen am: 14.11.2017, Ausgabe SPS-MAGAZIN SPS-Special 2017

Die industrielle Kommunikation der Zukunft - Teil 3/4

Paradigmenwechsel

Mit dem Aufruf zu Industrie 4.0 wurde die Achtsamkeit für die möglichen Paradigmenwechsel geweckt - und zahlreiche davon zugleich angeregt. So wird beispielsweise die SPS-Programmierung zunehmend durch Softwarehäuser unterstützt. Dieses Eindringen der IT in die OT bringt auch neue Protokolle, Arbeitskulturen und Begriffe mit in die Fabrikhalle.


Serie Industrielle Kommunikation

Teil 1: Eigenschaften technischer Sprachen (SPS 10/17)

Teil 2: Performanz & Echtzeitfähigkeit (SPS 11/17)

Bild: Sick AG

Teil 3: Neue Protokolle für Paradigmenwechsel (SPS Special)

Teil 4: Ersetzt OPC UA die Feldbusse? (SPS 12/17)

Der Informatiker ist jetzt nicht so sehr auf kompatible Protokolle zwischen Komponenten angewiesen. Er ist es gewohnt, so genannte Adapter zu programmieren - was nicht passt, wird passend gemacht.

Webservices und ReST

Die IT-Branche wurde in den letzten Jahren stark durch die Webtechnologie beeinflusst. Es ist daher nicht verwunderlich, dass sich die so genannten Webservices über die ReST-Schnittstelle nicht nur weit verbreitet, sondern auch durch zahlreiche Unterstützungen wie Software-Werkzeuge oder Software-Bibliotheken in allen möglichen Sprachen bis annähernd zur Perfektion weiterentwickelt haben. JSON - optimiert gegenüber XML - ist eine einfache und selbsterklärende Serialisierung von strukturierten Datenobjekten. Die Strukturinformation ist enthalten, so dass ein Blick in die Spezifikation oft nicht notwendig ist und kleine Veränderungen in der Struktur kompatibel überlesen werden können. ReST (Representational State Transfer) ist eigentlich ein Programmierparadigma für das Internet. Der Begriff wird aber gerne als Applikationsprotokoll mit JSON auf http verwendet. Und diese Protokoll-Format-Kombination wird heute von den meisten großen Softwaresystemen als Kommunikation zwischen Softwarekomponenten genutzt. Die ReST Technologie oder ein Nachfolger davon wird für bestimmte Anwendungen auch in der Automatisierungstechnik einen bedeutsamen Marktanteil einnehmen.

CoAP

Während die oben beschriebene ReST-Schnittstelle bzw. auch das berühmte HTTP sich so großer Beliebtheit erfreut, wird mit CoAP (Constrained Application Protocol) eine Alternative zu TCP/IP und HTTP geschaffen. CoAP setzt auf UDP/IP auf und bedarf damit viel weniger Ressourcen auf den Geräten. Es bildet auf pragmatische Weise die fehlende Übertragungssicherung von UDP nach und erweitert das Protokoll um einen Publish/Subscribe Mechanismus, welcher der klassischen ReST Spezifikation fehlt. Man darf gespannt sein, welches Schicksal für CoAP bestimmt ist. Während sich Pragmatiker darüber freuen, wird das Protokoll von einigen Spezialisten genau wegen seines pragmatischen Ansatzes regelrecht verurteilt.

OPC UA

OPC UA darf zwischen der OT- und der IT-Welt als Hybrid oder als Vermittler betrachtet werden. Wie die Feldbusorganisationen wird die Technologie von Herstellern der Automatisierungsbranche getrieben und ist auch hier zuhause. Daneben wird die Technologie aber auch von großen Softwarehäusern unterstützt. Auch technisch ist OPC UA ein Mittelweg zwischen der Feldbuswelt und der eher ressourcenhungrigen IT-Welt. Der eigentliche Kern von OPC ist ein objektorientiertes Gerätemodell (oder auch API). Für dieses Gerätemodell gibt es eine Hand voll möglicher Technologien, wie selbiges über das Netzwerk verfügbar gemacht wird. Für die Konformität ist ein binäres Protokoll zwingend zu implementieren. Für die Interoperabilität zwischen Komponenten verschiedener Hersteller wird man daher von diesem OPC UA Binary ausgehen können. Die klassische Definition von OPC UA schreibt die detaillierte Auskunft über einzelne Metadaten (Browsen der Datenknoten) vor, was die Technologie im Moment noch unattraktiv für Geräte mit unveränderlichem Datenmodell und beschränkten Ressourcen macht. Während man bei dem klassischen OPC UA die Geräte in Clients und Server unterteilt, teilt die neue Technologie OPC UA Pub/Sub die Teilnehmer in Talker und Listener ein, wobei ein Gerät sowohl Talker als auch Listener sein kann. Dieser neue Ansatz ist sehr schlank und kann technisch effektiv mit UDP/IP umgesetzt werden. Die fehlende Transportsicherung von UDP wird durch OPC UA Pub/Sub gelöst, in dem per Definition nach einer festgelegten Zeit Nachrichten auch dann übertragen werden, wenn sie keine neuen Informationen enthalten. Relativ niederfrequent gesendete sogenannte Keyframes stellen neben den Event gesteuerten Nachrichten sicher, dass die Verbindung überwacht werden kann. Besonders für Kommunikation zwischen Steuerungen eignet sich dieser eher symmetrische Ansatz, da es allgemein keine hierarchischen Unterschiede zwischen den einzelnen Steuerungen im Feld gibt.

MQTT

Das Message Queue Telemetry Transport (MQTT) wurde von IBM im Jahre 1999 entwickelt und gilt damit heute als bewährte Technologie. MQTT gehört zu den berühmtesten Vertretern einer Publish/Subscribe-Realisierung. Neben der logischen Adressierung im Netzwerk führt MQTT eine höher liegende Adressierung der so genannten Topics ein. Ein Topic kann man abonnieren (subscribe) und erhält ab sofort alle Nachrichten, welche dieses Topic sendet. Dies können allgemeine Informationen (Meldungen) oder beispielsweise Zustandsänderungen eines Messwertes sein. Der Vorteil dieser Technik ist, dass Nachrichten nun durch so genannte Broker vermittelt werden können. Ein MQTT-Broker ist ein Server, welcher mit einem bis vielen Nachrichtenproduzenten - zum Beispiel Sensoren - verbunden ist und viele oder alle Topics abonniert hat. Diese Topics kann er selbst als Vermittler wieder veröffentlichen (publish). Das Prinzip ist beliebig kaskadierbar, denn für die Applikationssoftware ist es transparent, ob das Topic direkt vom ursprünglichen Sender stammt oder über einen oder viele Broker vermittelt wurde. Das Datenformat ist in MQTT nicht festgeschrieben. Meist wird auch hier JSON verwendet.

AMQP

Die Spezifikation des Advanced Message Queuing Protocol (AMQP) ist eine logische Weiterentwicklung des Konzeptes, mittels Broker Nachrichten von IoT-Geräten (kleinen Netzwerkteilnehmern) mit großen Servern (Brokern) performant im großen Netzwerk zu verteilen. Eine Besonderheit von AMQP ist die Flusskontrolle, die mittels so genannter Link Credits direkt zwischen Empfänger und Sender vermittelt, wie viel Daten aktuell übertragen werden sollen. Die AMQP-Spezifikation wird von der offenen Non-Profit-Organisation OASIS (oasis-open.org) veröffentlicht. Sie ist eine offene, von großen Firmen konsortial finanzierte Spezifikation. Dennoch sollte die Unterstützung durch Microsoft nicht unerwähnt bleiben. Der Microsoft Azure Service Bus ist eine Implementierung von AMQP und wird nicht nur als Backplane für die Cloud sondern vor allem durch den Azure IoT-Hub zur Anbindung beliebiger Geräte verwendet.

Gibt es ein Esperanto-Protokoll?

Betrachtet man die verschiedenen Eigenschaften einer Kommunikationstechnologie, so läge es unter Umständen nahe, ein Technologie zu entwickeln oder aus vorhandenen Technologien auszuwählen, die für jeden passt und alle Vorteile in sich vereint - ähnlich wie es die Kunst-Sprache Esperanto seit mittlerweile 130 Jahren versucht. Selbst im Umfeld von Industrie 4.0 wären damit nicht alle Probleme gelöst, denn je nach Use Case können unterschiedliche Eigenschaften mehr oder weniger bedeutsam sein. So kommt es in einem Fall darauf an, dass eine besonders einfache und kostengünstige und gut beherrschbare Technologie verwendet wird. In einem anderen Fall kann die potentiell weltweite Vernetzung mit fast beliebigen anderen Systemen im Vordergrund stehen. Für unterschiedliche Applikationen können also unterschiedliche Eigenschaften wichtig sein. Aus Sicht der Experten wird es daher wohl kein allumfassendes Protokoll geben - zumal weltweit gültige industrielle Standards generell immer noch die Ausnahme sind und auch Esperanto alles andere als eine weltumfassende Sprache geworden ist.

Neue IT-Protokolle erfüllen I4.0-Anforderungen

Durch die Sicherheit einer vollständigen, getakteten Ende-zu-Ende-Übertragung von Kommunikationsströmen mit harten Echtzeitbedingungen, wie sie beispielsweise der Datenverkehr zwischen einer Steuerung und einem Roboter darstellt, unterstützt TSN den informationstechnischen Paradigmenwechsel, der mit Industrie 4.0 einhergeht. Mit TSN wird Standard-Ethernet potenziell echtzeitfähig. Und wenn das klassische Netzwerk durch eine mögliche Netzwerkplanung durchgehend diese Fähigkeit erreicht hat, spielt der Abstand zwischen einem Sensor, der verarbeitenden Automatisierungslogiklogik und dem darauf reagierenden Aktor keine Rolle mehr. Die Steuerung kann in Rechenzentren oder außerhalb der Firma platziert sein.