Herzlich Willkommen beim beam-Verlag in Marburg, dem Fachverlag für anspruchsvolle Elektronik-Literatur.


Wir freuen uns, Sie auf unserem ePaper-Kiosk begrüßen zu können.

Aufrufe
vor 7 Jahren

10-2016

  • Text
  • Software
  • Elektromechanik
  • Positioniersysteme
  • Antriebe
  • Stromversorgung
  • Feldbusse
  • Kommunikation
  • Robotik
  • Qualitaetssicherung
  • Bildverarbeitung
  • Automatisierungstechnik
  • Sensorik
  • Messtechnik
  • Visualisieren
  • Regeln
  • Msr
  • Boards
  • Systeme
  • Sbc
  • Ipc
Fachzeitschrift für Industrielle Automation, Mess-, Steuer- und Regeltechnik

Kommunikation

Kommunikation Messaging-Technologien für das IIoT Die Qual der Wahl? Es gibt viele unterschiedliche Messaging-Protokolle, die man für vernetzte industrielle IoT- Applikationen einsetzen könnte. Welches sollten Entwickler nutzen, wenn sie hochperformante Applikationen umsetzen wollen, bei denen viele Embedded Computer Systeme miteinander und auch mit Clouds in Echtzeit kommunizieren müssen? eigene C und C++ JMS API Mappings entwickelt haben, die mit dem JMS Broker genutzt werden können. Als API Standard kann JMS aber keine Interoperabilität garantieren. Hersteller und Nutzer können also unterschiedliche JMS Implementierungen nicht bedarfsgerecht kombinieren. Applikationen sind folglich in sich geschlossen und damit proprietär, was für viele neue IoT- Applikationen nicht gewünscht ist, denn was hilft es – einfach gesagt – wenn das Fenster meldet ‚Ich bin offen‘, die Heizung aber nicht versteht, dass sie sich dann abschalten soll. MQTT: Zusammenarbeit muss organisiert werden Autor: Daniel Piper ist Marketing Manager bei ADLINK Technology Bild 1: Reichweite der Messaging-Protokolle über unterschiedliche Infrastrukturen hinweg. Nur DDS und MQTT kann überall eingesetzt werden Vernetzte Applikationen mit vielen verteilten Embedded Computer Systemen gibt es viele. Nicht alle müssen auch dezentral untereinander kommunizieren können. Auch haben nicht alle Echtzeitanforderungen oder hohe Performanceansprüche. Doch nahezu jede vernetzte industrielle IoT-Applikation hat genau diese Anforderung: Unterschiedlichste Maschinen- und Anlagenbestandteile müssen stets miteinander in Echtzeit kommunizieren, um zum Beispiel interaktive modulare (Multivendor-)anlagen umsetzen zu können. Ähnlich ist es auch in Windparks oder in Microgrids, wo unterschiedliche Energiequellen und Verbraucher in Echtzeit synchronisiert werden müssen. Der Schienenverkehr muss für Smart Railway Applikationen vernetzte, durchgängig echtzeitfähige Infrastrukturen und Züge bekommen. Gleiches gilt für smartes Straßenverkehrsmanagement, smartes Lighting und smarte Cities sowie auch autonome Roboter und Fahrzeuge aller Art. Wer für solche vernetzten IoT- Applikationen das richtige Messaging-Protokoll aussuchen muss, der steht vor einem Problem. Es gibt zwar viele Protokolle und jedes Protokoll hat seine eigenen Vorteile, die in der Architektur oder in der Art des Messaging begründet liegen. Doch nur wenige sind wirklich dafür prädestiniert, als universelles Echtzeit-Protokoll eingesetzt zu werden, wie ein Überblick über die sieben wichtigsten industrietauglichen Protokolle AMQP und JMS, MQTT, REST, CoAP, XMPP sowie DDS zeigt. Die wichtigsten Protokolle im Überblick Die Protokolle AMQP und JMS wurden für schnelle und zuverlässige Business-Transaktionen entwickelt, also beispielsweise um den elektronischen Zahlungsverkehr zu regeln oder Börsenhandel zu betreiben. JMS fokussiert dabei auf Java-zentrierte Systeme. Es gibt aber auch einige Hersteller, die MQTT ist weniger komplex und für eine einfache und schlanke Datenerfassungslösung für Devices aller Art gemacht. Allerdrings kann auch hier nur teilweise eine Interoperabilität zwischen einem MQTT Publisher und Abonnenten garantiert werden. Nachrichten können zwar problemlos zwischen verschiedenen MQTT Implementierungen ausgetauscht werden. Aber die Nachricht kann nicht verstanden werden, wenn es zwischen Sender und Empfänger keine Vereinbarung über das Schema des Nachrichteninhalts gibt. Das setzt das aktive Aufsetzen einer koordinierten Zusammenarbeit zwischen den einzelnen Teilnehmern voraus, was bei komplexen Installationen ein kompliziertes, fehleranfälliges und teures Unterfangen werden kann. REST: Einfach aber rechenintensiv REST bietet mit Request & Reply zwar eine einfache Art der Client- Server Kommunikation, die man für Systeme nutzen kann, die über das Internet kommunizieren müssen. REST unterstützt aber nicht den lose gekoppelten, asynchronen Publish & Subscribe Datenaustausch. Das Modell der Zustandslosigkeit von HTTP kann zwar Server-Designs vereinfachen. Das hat 14 PC & Industrie 10/2016

Kommunikation Bildt 2: Eine Architektur mit Brokern verbraucht Ressourcen produziert Latenzen. Nicht immer lässt sich das jedoch vermeiden. Beispielsweise in Richtung Feld oder auch in Richtung Enterprise Level. Zwischen den verteilten Devices ist es jedoch sinnvoll, auf ein einheitliches Protokoll wie beispielsweise DDS zu setzen aber den Nachteil, dass es notwendig sein kann, die fehlende Zustandsbeschreibung als zusätzliche Information in jede Anfrage integrieren zu müssen. Und diese muss sodann auch zusätzlich vom Server interpretiert werden. Dies kann sich sehr ineffizient auf die Verarbeitungszeiten von Anfragen auswirken und wertvolle Ressourcen verbrauchen (wie zum Beispiel die Anzahl der möglichen TCP/IP-Verbindungen). Damit eignet sich auch REST nicht für große Installationen. CoAP: Latenzen unvermeidbar CoAP wurde entwickelt, um die Konnektivität von einfachen elektronischen Low-Power-Devices (z. B. drahtlosen Sensoren) mit Internetbasierten Systemen zu unterstützen. Es eignet sich sehr gut für die Datenerfassung in Systemen. Voraussetzung ist aber, dass weder eine sehr hohe Leistung noch ein Echtzeit- Daten-Sharing oder eine Echtzeit- Gerätesteuerung erforderlich sind. In vielen Fällen werden Daten für eine nachträgliche ‚Offline‘-Verarbeitung gesammelt. Ein CoAP-Gerät wird dabei mit einem Cloud-basierten System über einen HTTP-Proxy verbunden, der ein Standard CoAP- HTTP-Mapping verwendet. Der Einsatz eines solchen Proxys oder einer Brücke erhöht dabei sowohl den Kommunikationsaufwand als auch die Nachrichtenlatenz. XMPP: Zu komplex für Low Power Das XMPP Protokoll basiert auf der Extensible Markup Language (XML) und wurde ursprünglich für das Instant Messaging (IM) und die Online-Anwesenheitserkennung entwickelt. Die Kernstandards dieses Protokolls bilden ein Framework für den Aufbau von Messaging-Anwendungen wie Mehrparteien-Chats, Sprach- und Videoanrufe, Kollaboration, Lightweight Middleware, Content-Syndication und generalisiertes Routing von XML-Daten. Obwohl XMPP Sicherheitsfunktionen wie Authentifizierung und die Verschlüsselung von Nachrichten unterstützt, bietet es keine Unterstützung für die Quality-of-Service Anforderungen, wie sie typischerweise in Industrial Internet-Systemen benötigt werden. Das XML-Parsing erfordert zusätzlichen Verarbeitungsaufwand und ein XML-Parser addiert zusätzlichen Speicherbedarf, sodass sich XMPP nicht für den Einsatz in Low-Power Embedded-Systemen eignet. DDS: Datenzentrisches Publish & Subscribe Das DDS-Protokoll ist eine datenzentrische Publish & Subscribe Technologie, die für missions- und geschäftskritische Applikationen Bild3: Der DDS Datenbus kann unterschiedliche Publisher und Subscriber verwalten (tunneln) und je nach Topic bedarfsgerecht verbinden wie den Finanzhandel, die Flugsicherung, das Smart Grid Mangement und andere Big-Data Applikationen entwickelt wurde. DDS unterstützt dynamische Discovery- Prozesse, benötigt also anders als AMQP, MQTT oder JMS keinen einen Broker/Makler. DDS wird zudem auch zunehmend als Schlüsselprotokoll für das interoperable Messaging zwischen Echtzeit-Devicenetzwerken und cloudbasierten Datencentern eingesetzt. Implementierungen von DDS können zudem auch innerhalb der Devices (Intra-Nodal) einen hochperformanten Datenaustausch ermöglichen. Kernstück ist der datenzentrische Publish & Subscribe Layer, der über ein kohärentes Set an standardisierten Profilen einen Informationsaustausch in Echtzeit ermöglicht. DDS ist unabhängig von Programmiersprachen und Betriebssystemen. Es gibt standardisiert APIs für zahlreiche Programmiersprachen wie Ada, C, C++, C#, Java, Scala, Lua und Ruby die auch eine Portierung zwischen den Implementierungen unterschiedlicher Hersteller sicherstellen. Sicherheit gewährleisten Die Sicherheit eines Systems, das potenziell mit vielen tausenden Geräten fehlertolerant und sicher kommunizieren muss, ist von großer Bedeutung. Die meisten vorgestellten Messaging-Technologien widmen sich dieser Fragestellung jedoch nur mittelbar. Führende Anbieter ergänzen ihre Implementierungen beispielsweise in der Regel um proprietäre Lösungen auf Basis von erprobten Third-Party-Sicherheitstechnologien wie SSL oder TLS. So binden AMQP und XMPP die Schnittstelle SASL zur Nachrichten-Authentifizierung an und die kürzlich (Juni 2016) verabschiedete OMG DDS Sicherheitsspezifikation liefert nun auch einen umfassenden Rahmen für die Standardisierung der Sicherheit von DDSbasierten Systemen. Offen bleiben Es sollte auch noch erwähnt werden, dass es in einigen Fällen – zum Beispiel aus Legacy-Gründen – sinnvoll sein kann, ein System zu entwickeln, das mehr als nur eine Messaging-Technologie innerhalb der gleichen Architektur verwendet. In diesem Fall werden zum Datenaustausch individuelle Vermittlungsschemata und Bridges zwischen Clients mit unterschiedlichen Protokollen erforderlich. Dies ist zwar nicht die optimale Lösung. Es ist aber ein gängiges Szenario. Besonders wenn man IoT-Systeme entwickelt, die sowohl neue und Legacy- Devices integrieren müssen. Bild 4: Die Adlink SEMA Cloud Lösung unterstützt MQTT und wird in Kürze auch DDS unterstützen PC & Industrie 10/2016 15

hf-praxis

PC & Industrie

© beam-Verlag Dipl.-Ing. Reinhard Birchel