Suchen

Interface-Programmierung IoT-Schnittstellen einfach verdrahten

| Autor / Redakteur: Klaus-Dieter Walter * / Franz Graser

Die Open-Source-Software Node-RED bietet einen geeigneten Baukasten, um per Datenflussprogrammierung die notwendigen Verbindungen zwischen IoT-Systemen zu schaffen.

Firmen zum Thema

Eine Hardware,viele Schnittstellen: Das Open-Source-Set Node-RED erlaubt es, IoT-Geräte praktisch beliebig miteinander zu verknüpfen.
Eine Hardware,viele Schnittstellen: Das Open-Source-Set Node-RED erlaubt es, IoT-Geräte praktisch beliebig miteinander zu verknüpfen.
(Bild: SSV Software Systems)

Das Internet of Things verspricht offene Kommunikationsbeziehungen zwischen völlig unterschiedlichen Systemen und Anwendungen über Anbieter- und Herstellergrenzen hinweg, um Mehrwert für die Nutzer zu schaffen. Es existieren allerdings auch noch unzählige technische Hürden, die praktikable Lösungen benötigen.

So muss sich beispielsweise ein Smart Connected Sensor (SCS) für IoT- oder Industrie-4.0-Anwendungen mit praktisch jeder Cloud-Serviceplattform im Internet verbinden lassen. Diese Verbindung muss während des SCS-Lebenszyklus auch mehrfach änderbar oder um Zusatzfunktionen erweiterbar sein. Außerdem sollte der SCS auch einer lokalen Anwendung direkt vor Ort den Zugriff auf die Sensordaten ermöglichen, etwa mit Hilfe eines integrierten OPC UA-Servers.

Die größte Herausforderung dabei ist die Protokoll- und Schnittstellenvielfalt. Dafür sind nicht, wie häufig vermutet, fehlende Standards die Ursache. Es existieren einfach zu viele konkurrierende Standards, denen in den meisten Fällen auch noch die semantischen Komponenten fehlen.

Analysiert man die Entwicklungen der vergangenen Jahre, so fällt auf, dass praktisch alle Cloud-Serviceplattformen zunächst einmal mit einem REST-basierten HTTP-Interface begonnen haben. HTTP ist durch HTML und das Web ein sehr verbreitetes Client/Server-Applikationsprotokoll. REST ist aber anders als HTML kein Standard mit umfassender Spezifikation, sondern lediglich ein datenagnostisches Programmierparadigma für verteilte Systeme.

Dadurch besitzt praktisch jede Cloud eine spezifische REST-API, an die sich der jeweilige Client anpassen muss. Mittels welcher Details eine bestimmte Servicefunktion aufgerufen wird, legen die jeweiligen API-Entwickler unabhängig voneinander fest. Die Daten selbst können im XML-, JSON- oder anderen Formaten zwischen Client und Server ausgetauscht werden.

Durch die starke Zunahme von IoT-Anwendungen bieten unzählige Cloud-Plattformen neben REST und HTTP inzwischen auch eine MQTT-Protokollunterstützung. MQTT ist zwar ein OASIS-Standard, aber hinsichtlich der Daten ebenso unspezifisch wie REST. Mit anderen Worten: Jeder MQTT-Cloud-Service nutzt eigene Datenformate, so dass praktisch keine Kompatibilität zwischen unterschiedlichen Plattformen existiert. Die Anpassung an die gewünschte Cloud wird dem jeweiligen „Thing“ überlassen.

Anforderungen an einen IoT-Sensor

Ein Sensor für das Internet der Dinge, wie der in Schaubild 1 dargestellte SCS, benötigt eine besonders flexible Konfigurationsschnittstelle, die die speziellen Bedürfnisse und Anforderungen der IoT-Welt berücksichtigt. Sie sollte auf jeden Fall die folgenden Anforderungen erfüllen:

Schaubild 1: Physisch besteht ein SCS aus den Sensorelementen zur Messgrößenerfassung, einer analogen Signalkonditionierung, einem Analog/Digitalwandler (A/D-Wandler) und einem Kommunikations-Interface (Comm I/F). Für die Verbindungen zu verschiedenen Public und Private Clouds muss das Comm I/F die entsprechenden Protokolle und Datenformate unterstützen.
Schaubild 1: Physisch besteht ein SCS aus den Sensorelementen zur Messgrößenerfassung, einer analogen Signalkonditionierung, einem Analog/Digitalwandler (A/D-Wandler) und einem Kommunikations-Interface (Comm I/F). Für die Verbindungen zu verschiedenen Public und Private Clouds muss das Comm I/F die entsprechenden Protokolle und Datenformate unterstützen.
(Bild: SSV Software Systems)

1. SCS-IoT-Verbindung ist in einer für den Anwender einfach zugänglichen Abstraktionsebene vorkonfiguriert

Die IoT-Anbindung sollte auf keinen Fall „fest“ im SCS-Firmware-Code isoliert werden und sich nur durch ein Firmware-Update verändern lassen. Eine solche SCS-Eigenschaft wäre allein schon aus IT-Security-Sicht problematisch. Bei einem zukünftigen Industrie 4.0-SCS kann zum Beispiel eine Public-Key-Infrastruktur (PKI) zum Einsatz kommen. Das digitale Zertifikat muss dann über die Abstraktionsebene austauschbar sein.

2. Protokoll- und Datenschnittstellencode nachladen, konfigurieren und den Treibercode ausführen

Soll der SCS als IoT-Daten-Frontend beispielsweise mit einer anderen Cloud verbunden werden und statt der bisher genutzten REST-basierten Kommunikation nun MQTT zur Sensordatenübermittlung zum Einsatz kommen, muss zunächst einmal ein neuer „IoT-Treiber“ nachinstalliert werden. Die erforderlichen Zugangsdaten der jeweiligen IoT-Serviceplattform müssen sich einstellen lassen. Das finale Ergebnis sollte als Komponente in einer Laufzeitumgebung – möglichst ereignisgesteuert – ausgeführt werden. Über diese SCS-Eigenschaft lassen sich auch zukünftige IT-Security-Anforderungen umsetzen.

3. Test- und Diagnosemöglichkeiten für die Schnittstellenverbindung zwischen IoT-Frontend und IoT-Backend schaffen

Um die vom Sensor als IoT-Daten-Frontend an das Backend geschickten Messwerte und die daraufhin erhaltenen Antworten bei der Inbetriebnahme oder im Fehlerfall vor Ort am SCS prüfen zu können, ist eine praxistaugliche Debug-Schnittstelle erforderlich.

4. Datenformate zwischen Backend und Frontend angleichen

Ist zum Beispiel ein anderes Datenformat für die Sensordatenübermittlung erforderlich, so muss sich die entsprechende Datenstruktur durch den SCS-Anwender verändern und an die Bedürfnisse anpassen lassen.

5. Einfache Bedienbarkeit und Langzeitverfügbarkeit

Eine intuitive Bedienung ist erforderlich, um ohne spezielle Programmierkenntnisse, Seminare und Handbuchstudium die nötigen Anpassungen vorzunehmen. Auch nach 10 Jahren muss sich der SCS noch mit einer anderen IoT-Plattform verbinden lassen. Es sollte daher keine Spezialsoftware (App, lizenzpflichtige PC-Software) zum Einsatz kommen.

6. Duplizierbare und weitestgehend Device-unabhängige Konfigurationsdaten

Die Konfigurationseinstellungen eines SCS müssen sich einfach auf andere SCS übertragen lassen, um eine ausgetestete IoT-Plattform-anbindung auf weitere IoT-Devices zu duplizieren. Weiter sollte die IoT-Anbindung möglichst unabhängig von einer bestimmten SCS-Hardwarearchitektur sein, so dass sich komplexe Konfigurationsdaten (Protokoll- und Datenschnittstellencode, Datenkonvertierungen usw.) auch nach einigen Jahren auf Nachfolgeprodukte übertragen lassen. Dabei sind IT-Security-Anforderungen zu beachten, beispielsweise die Verankerung digitaler Identitäten auf einer bestimmten Hardware.

Node-RED als Protokoll- und Datenbindeglied

Ein Werkzeug, mit dem sich diese Anforderungen umsetzen lassen und das sich direkt in einen SCS integrieren lässt, ist die Open-Source-Software Node-RED. Dieses relativ neue Werkzeug wurde von IBM entwickelt und 2013 veröffentlicht. Node-RED steckt zwar noch in den Kinderschuhen, die Entwickler-, Unterstützer- und Anwendergemeinde wächst aber in einem rasanten Tempo.

Node-RED besteht aus einer ereignisgesteuerten JavaScript-Laufzeitumgebung, einem integrierten Webserver und einer komfortablen Web-basierten Benutzerschnittstelle, die mit jedem modernen HTML5-konformen Browser nutzbar ist. Node-RED isoliert nahezu die gesamte Komplexität der Schnittstellenverbindung zwischen IoT-Device und IoT-Plattform in vorgefertigten grafischen Funktionsbausteinen (sogenannten Nodes). Diese werden in der Weboberfläche per Copy&Paste aus einem mitgelieferten Baukasten als einzelne Grafikobjekte entnommen, auf einer Arbeitsfläche platziert und miteinander verbunden (verdrahtet). Dabei entsteht ein Node-RED-Flow.

Schaubild 2: Node-RED bietet eine Web-basierte Benutzeroberfläche mit integriertem Flow-Editor. Im Arbeitsbereich des Editors werden nach dem Prinzip der Datenflussprogrammierung vorgefertigte Funktionsbausteine (sogenannte Nodes) platziert, durch entsprechende Eingaben konfiguriert und per Mausklick verdrahtet. Das Ergebnis ist ein Node-RED-Flow, der über die Weboberfläche ausgeführt wird.
Schaubild 2: Node-RED bietet eine Web-basierte Benutzeroberfläche mit integriertem Flow-Editor. Im Arbeitsbereich des Editors werden nach dem Prinzip der Datenflussprogrammierung vorgefertigte Funktionsbausteine (sogenannte Nodes) platziert, durch entsprechende Eingaben konfiguriert und per Mausklick verdrahtet. Das Ergebnis ist ein Node-RED-Flow, der über die Weboberfläche ausgeführt wird.
(Bild: SSV Software Systems)

Schaubild 2 zeigt im Arbeitsbereich der Weboberfläche das denkbar einfachste Beispiel mit jeweils einem Input-Node und Output-Node. Der Input-Node auf der linken Seite bildet einen MQTT-Subscriber, der per Internet mit einem Broker verbunden ist, um Nachrichten (MQTT-Topics) entgegenzunehmen und an den Output-Node auf der rechten Seite weiterzuleiten.

Als Output-Node wird ein Debug-Node verwendet. Dieser gibt in einem speziellen Fenster der Weboberfläche die vom Input-Node erhaltenen Nachrichten zusammen mit einem Zeitstempel und weiteren Informationen aus.

Will man etwa das Datenformat des MQTT-Topics- vor der Weitergabe an den Output-Node verändern, so wird zwischen die beiden Nodes ein zusätzlicher Function-Node aus dem Funktionsvorrat am linken Rand der Weboberfläche eingefügt und die Verdrahtung angepasst. In diesem Node lässt sich dann JavaScript-Programmcode für Datenumwandlungen jeglicher Art und andere Aufgaben ablegen.

Neben dem Platzieren und Verdrahten der Funktionsbausteine ist die Konfiguration der einzelnen Nodes in einem Flow sehr wichtig. Dazu wird im Node-RED-Flow-Editor mit einem Doppelklick auf das entsprechende Grafikobjekt jeweils ein Dialogfenster geöffnet. In diesem Fenster werden dann die erforderlichen Daten – zum Beispiel die Adresse eines MQTT-Brokers oder der JavaScript-Programmcode – eingegeben.

Datenflussprogrammierung und JavaScript als Basis

Die Node-RED-Methodik nutzt das seit vielen Jahren in der IT-Welt verbreitete Konzept der Datenflussprogrammierung (Flow-based Programming, FBP). Die FBP-Grundlage bilden grafische Module mit Ausgängen zum Versenden von Daten (Datenquellen), Datenempfangsmodule mit Eingängen (Datensenken) sowie Module mit Ein- und Ausgängen, die auf der einen Seite Daten empfangen und auf der anderen Seite modifizierte Daten wieder versenden. Die Ein- und Ausgänge der Module werden zu einem Netzwerk verbunden. Über diese vordefinierten Verbindungen fließen dann die Daten einer Anwendung.

Schaubild 3: Ein ausgetesteter Node-RED-Flow lässt sich als JSON-Objekt exportieren, archivieren und in andere IoT-Devices importieren. Dadurch lassen sich zum Beispiel alle Konfigurationsdaten und weitere Parameter einer Schnittstellenverbindung zwischen IoT-Device und IoT-Plattform beliebig oft duplizieren. Export und Import werden von Node-RED durch spezielle Funktionen der Weboberfläche unterstützt.
Schaubild 3: Ein ausgetesteter Node-RED-Flow lässt sich als JSON-Objekt exportieren, archivieren und in andere IoT-Devices importieren. Dadurch lassen sich zum Beispiel alle Konfigurationsdaten und weitere Parameter einer Schnittstellenverbindung zwischen IoT-Device und IoT-Plattform beliebig oft duplizieren. Export und Import werden von Node-RED durch spezielle Funktionen der Weboberfläche unterstützt.
(Bild: SSV Software Systems)

Eine Node-RED-Implementierung basiert auf der JavaScript-Laufzeitumgebung Node.js (https://nodejs.org/), die für die Entwicklung und den Betrieb serverseitiger Netzwerkanwendungen vorgesehen ist. Node.js lässt sich sowohl auf Embedded-Systemen als auch auf PCs installieren und nutzen. Dadurch ist Node-RED plattformunabhängig und kann auf intelligenten Sensoren, IoT-Edge-Gateways, PCs und sonstigen Automatisierungsbaugruppen eingesetzt werden.

Die zu einer Node-RED-Installation gehörenden Funktionsbausteine decken zahlreiche IoT-Anbindungen, etwa per HTTP/REST und MQTT, ab. Auch Websocket-Funktionen, E-Mail-Versand und Twitter-Anbindungen sind vorhanden. Weitere Bausteine sind jederzeit nachinstallierbar. Ein SCS-Anbieter kann seinen Kunden somit spezielle Erweiterungsbausteine zur Verfügung stellen, die sich relativ einfach nachinstallieren lassen und den Funktionsvorrat der Input-, Output- und Function-Nodes erweitern. Damit lässt sich etwa ein kompletter OPC-UA-Server in einem Node-RED-Funktionsbaustein isolieren und vom Anwender per Copy&Paste in einen Flow implementieren.

Der im Node-RED-Editor erstellte Flow lässt sich durch spezielle Funktionen der Weboberfläche als JSON-Objekt exportieren, archivieren und in andere IoT-Devices importieren. Dadurch sind alle Konfigurationsdaten und weitere Parameter einer IoT-Schnittstellenverbindung beliebig oft duplizierbar.

Klaus-Dieter Walter
Klaus-Dieter Walter
(Bild: SSV Software Systems)

Insgesamt ist Node-RED zwar eine Expertenlösung. Sie lässt sich allerdings aufgrund der einfachen Struktur mit relativ geringen Vorkenntnissen per Webbrowser bedienen. Durch die Erweiterbarkeit des Funktionsvorrats und die Flow-Importmöglichkeit kann ein IoT-Device-Anbieter seinen Kunden hochkomplexe Konfigurationen zur Verfügung stellen, die sich mit wenigen Mausklicks anpassen und einsetzen lassen.

* Klaus-Dieter Walter ist als CEO für SSV Software Systems in Hannover tätig. Der Autor ist zudem durch Vorträge sowie Beiträge in Fachzeitschriften bekannt.

Dieser Beitrag ist ursprünglich auf unserem Schwesterportal Embedded-Software-Engineering.de (eine Publikation von Elektronikpraxis.de) erschienen.

(ID:44532792)