Startseite > Kommunikation > Kommunikative Sensoren

Unverzichtbar für IoT und Industrie 4.0

Kommunikative Sensoren

30. März 2016, 13:48 Uhr | Von Klaus-Dieter Walter

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Virtuelle Repräsentanz – die I4.0-Verwaltungsschale

Wie bereits erwähnt, existieren in der Unterhaltungselektronik heute schon echte IoT-Anwendungen mit vernetzten Sensoren. Sie eignen sich hinsichtlich der Architekturen, Bausteine und Komponenten als Beispiele für Smart-Connected-Sensoren. „Internet of Things – Architecture“ (IoT-A), ein Förderprojekt der Europäischen Union, bietet anbieterneutrale Orientierungshilfen. Sensoren, Aktoren und Devices bilden in diesem Modell die physischen Repräsentanzen. Zu jeder physischen gehört wiederum eine virtuelle Repräsentanz, die mit Hilfe eines IoT- bzw. Cloud Service im Internet realisiert werden kann. Auf einer solchen IoT-Service-Plattform wird zum Beispiel der aktuelle Zustand der Sensoren gespeichert und bei Bedarf – z.B. bei jeder Zustandsänderung – erneuert. Auf das jeweilige Datenabbild können andere Systeme und Benutzer mittels eines Application Programming Interface (API) – z.B. sogenannte REST-APIs – zugreifen. Auch in den I4.0-Dokumenten wurde die Idee der virtuellen Repräsentanz aufgegriffen, mit zusätzlichen Eigenschaften versehen und als „die Verwaltungsschale einer I4.0-Komponente“ betitelt.

SCS als Überwachungssensor

In unzähligen Maschinen und Anlagen existieren Schaltschränke mit der Automatisierungstechnik verschiedener Hersteller. Für den reibungslosen Betrieb einer solchen Multi-Vendor-Lösung sind häufig verschiedene Servicepartner zuständig, denen bei Bedarf jeweils Zugriff auf den Schaltschrank ermöglicht werden muss. Im Fehlerfall kommt es vor, dass über mögliche Ursachen diskutiert wird. Wenn es um die Kosten für einen Service-Einsatz geht, ist es innerhalb der Gewährleistungsphase beispielsweise hilfreich, anhand kontinuierlich aufgezeichneter Betriebsdaten den Nachweis ordnungsgemäß eingehaltener Umgebungsparameter bzw. des fehlerfreien Betriebs der jeweils anderen Baugruppen erbringen zu können. Dafür müssen diese Daten zum einen laufend in einer Datenbank erfasst und zum anderen ein einfacher Datenzugriff für verschiedene Nutzer – also ohne eine Spezial-Software – ermöglicht werden. Des Weiteren sollte den Servicepartnern ein selektiver Fernzugriff auf die aktuellen Anlagendaten und eine Benachrichtigung bei Störungen geboten werden. Ein Smart-Connected-Sensor (SCS) mit integriertem Datenlogger und Webschnittstelle erfüllt diese Anforderungen.

Bild 3 illustriert ein mögliches Anwendungsbeispiel zur Überwachung mit Datenlogging in einem Multi-Vendor-Schaltschrank. Der SCS selbst besitzt eine interne Sensorik für die Messgrößen Bewegung – z.B. Ultraschallbewegungsmelder, um das Öffnen der Schaltschranktür zu erkennen –, Temperatur und Luftfeuchtigkeit. Externe Steuerungen einzelner Meldungen können über einen externen Datenloggereingang an den SCS übergeben können. Zur Datenspeicherung besitzt der SCS eine eingebaute SD-Speicherkarte mit SQL-Datenbank. Die in der Datenbank gespeicherten Historiendaten lassen sich vor Ort jederzeit per Web-Browser betrachten. Hierfür kann ein Servicetechniker mit seinem Notebook oder Tablet auf den SCS-internen HTTP-Server zugreifen. Aus den Eingangsdaten des Loggers wird bei relevanten Datenänderungen ein JSON-Objekt (JavaScript Object Notation) konstruiert und über REST (Representational State Transfer) oder MQTT (Message Queue Telemetry Transport) an die Cloud übermittelt. Dadurch liegt in der Cloud jeweils ein aktuelles Datenabbild der Anlage vor. Auf diese Anlagenzustandsdaten können die Dashboards verschiedener Service-Partner zugreifen, um bei Bedarf den aktuellen Status zu visualisieren. Da SCS und Cloud per Internet miteinander kommunizieren, muss für eine ausreichende Sicherheit (IT Security) gesorgt werden. Aus diesem Grund wird die Verbindung per TLS (Transport Layer Security) abgesichert. Dieses vom Bundesamt für Sicherheit in der Informationstechnik (BSI) empfohlene Verfahren gewährleistet die erforderliche Authentifizierung, Datenintegrität und Vertraulichkeit. REST, MQTT, JSON und TLS sind im Internet der Dinge und in der M2M-Kommunikation weit verbreitete Technologiebausteine, die sich auch in einem SCS-Gateway implementieren lassen. Zahlreiche Cloud-Plattformen, zumindest wenn sie von ihren Anbietern für IoT-Anwendungen vorgesehen sind, unterstützen einen solchen Technologie-Stack ebenfalls. In der Cloud existiert darüber hinaus eine Datenbank – zum Beispiel If-This-Then-That – mit vorgegebenen Regelwerken, um die Frage „Bei welchem Anlagenzustand ist was zu tun?“ automatisch zu beantworten und entsprechende Handlungen in die Wege zu leiten. Die Regeln werden von einer sogenannten Regelmaschine laufend mit dem jeweils aktuellen Anlagenzustand abgeglichen. Als Folge dieser Auswertungen können Informationen an Mitarbeiter-Smartphones verschiedener Service-Partner und sogar automatische Ersatzteil- oder Betriebsmittelbestellungen über ein Benachrichtigungsmodul verschickt werden. Dafür wird direkt aus der Cloud heraus eine Bestellung oder Angebotsanfrage an die Lieferanten gesendet, die von der Customer Relationship Management Software (CRM) bzw. der Enterprise Resource Planning Software (ERP) autorisiert wurden.

Client/Server reicht nicht

Für den erfolgreichen SCS-Einsatz reichen die bisher in IP-Netzwerken überwiegend zum Einsatz kommenden Client/Server-Protokolle – z.B. HTTP bzw. HTTPS – nicht aus. Das bereits erwähnte MQTT ist deutlich besser geeignet, um Sensoren und Aktoren miteinander zu koppeln. Aus diesem Grund spielt das Protokoll bereits heute im Internet der Dinge sowie in einem typischen SCS-Technologie-Stack eine sehr wichtige Rolle. Ursprünglich war MQTT als M2M-Protokoll zur Telemetrie-Datenübertragung über satellitengestützte Funkverbindungen gedacht. Zu den wichtigsten MQTT-Entwicklungszielen gehörte daher die Übermittlung kleiner Datenmengen über relativ schlechte Übertragungswege mit geringer Bandbreite.

MQTT arbeitet nach einem ereignisgesteuerten Publish/Subscribe-Prinzip (Bild 4). Dabei verbinden sich die einzelnen Client-Systeme – wie Sensoren, Aktoren, Smartphone-Apps – mit einem zentralen Server, dem MQTT-Broker, der als Informationsvermittler zwischen den Datenquellen und Datensenken dient. Ein Client kann bestimmte Informationen über spezielle Nachrichtenkanäle verschicken (Publish) oder abonnieren (Subscribe). Die einzelnen Nachrichtenkanäle werden als Topics bezeichnet und sind baumförmig organisiert. Topics bilden praktisch die Namen der Nachrichtenkanäle. MQTT ist datenagnostisch, also nicht auf ein bestimmtes Datenformat festgelegt. Es können sowohl die Rohdaten einer einzelnen Messgröße als auch komplexe JSON- oder XML-Datenstrukturen übertragen werden. Darüber hinaus ermöglicht MQTT die für die Sensordatenkommunikation wichtigen 1:n-Beziehungen: Ein Publisher als Datenquelle verschickt Informationen, die von vielen (n) Subscribern als Datensenken empfangen werden. Sensoren sind in einer MQTT-basierten Umgebung die Publisher. Sie verbinden sich als Client mit einem MQTT-Broker und schicken bei jeder Änderung die jeweils aktuellen Messdaten zusammen mit einem Topic-Namen – z.B. „/rtdc/temperatur“ – an den Broker. Ein Aktor oder eine Smartphone-App ist typischerweise ein Subscriber. Er meldet sich beim Broker als zentrale Anlaufstelle an und teilt diesem unter Angabe des Topic-Namens mit, an welchen Nachrichten ein Interesse besteht bzw. welcher Topic abonniert wird. In der einfachsten Betriebsart muss der Broker beim Erhalt eines Topic von einem Publisher nur prüfen, ob es für den jeweiligen Topic-Namen einen Subscriber gibt. Falls ja, werden die Daten unverzüglich an den oder die Abonnenten weitergeleitet, andernfalls einfach verworfen.

Bild 5 zeigt eine Umsetzung dieses Mechanismus. Für höherwertige Betriebsarten – zum Beispiel MQTT Retained Messages – ist eine Datenbank erforderlich, da der Broker die von einem Publisher erhaltenen Daten speichern muss, auch wenn es im Moment keinen Subscriber gibt. Da MQTT einen TCP/IP-Stack für den Datentransport benutzt, spielt es keine Rolle, ob sich Publisher, Broker und Subscriber im gleichen LAN befinden oder über das Internet miteinander kommunizieren. Publisher und Subscriber müssen noch nicht einmal die IP-Adresse bzw. den DNS-Namen des jeweils anderen kennen. Beide, also sowohl der Publisher-Client also auch ein Subscriber-Client, müssen allerdings den MQTT-Broker als zentrale Instanz per IP-Adresse oder DNS-Namen adressieren können. Damit wird auch deutlich, dass Publisher und Subscriber geschützt hinter einer Firewall betrieben werden können, da sie von außen keinerlei Verbindungen entgegennehmen müssen. Der Broker muss allerdings wie jeder andere Server ausreichend gegen Cyber-Angriffe geschützt werden.

Nicht warten, jetzt handeln

Ohne ein entsprechendes Angebot an Sensoren mit IoT- bzw. Industrie-4.0-Kommunikationsfähigkeiten wird es besonders im industriellen Umfeld sehr lange dauern, bis es zu einem nennenswerten Marktdurchbruch kommt. Die meisten Sensorhersteller warten – aus welchen Gründen auch immer – noch ab. Anwender oder andere Marktteilnehmer müssen zur Zeit den benötigten Sensor selbst mit den erforderlichen Schnittstellen ausstatten und mit einer Cloud oder einem IT-System verbinden. In der Unterhaltungselektronik hat dies zu neuen Anbietern geführt, die mit disruptiven Innovationen in Marktsegmente eindringen. Da bleibt zu hoffen, dass die ansonsten sehr starke deutsche Sensorbranche diesmal nicht zu lange wartet.

Der Autor

Klaus-Dieter Walter
ist Geschäftsführer von SSV Software Systems in Hannover und Vereinsmitgründer der M2M Alliance und von VHPready. Seit einigen Jahren unterstützt Walter den Nationalen IT-Gipfel durch Mitarbeit in der M2M-Initiative Deutschland.

kdw@ssv-embedded.de