Einfluss des Internet of Things (IoT) auf die Produktentwicklung

Um ein x-beliebiges Produkt beziehungsweise System als „Thing“ in das Internet der Dinge einzubinden, sind drei Voraussetzungen zu erfüllen. Erstens muss es eine systemfähige Geräteschnittstelle aufweisen. Für diese Schnittstelle wird eine direkte oder indirekte Internetfähigkeit benötigt. Direkt bedeutet, dass ein Thing entweder per LAN beziehungsweise Wi-Fi mit einem Router verbunden ist oder ein integriertes 2G/3G/4G-Mobilfunkmodem besitzt und mit anderen Systemen im Internet kommunizieren kann. Eine indirekte Internetverbindung kann zum Beispiel über ein zwischengeschaltetes Smartphone mit entsprechender App erfolgen. Thing und App kommunizieren beispielsweise per Bluetooth miteinander.
Eine ähnliche Konfiguration existiert in Wireless Sensor Networks. Die einzelnen Sensoren sind als Things über ein Nahbereichsfunkprotokoll (etwa ZigBee) mit einem IoT Edge Gateway gekoppelt, das wiederum per LAN oder Wi-Fi mit dem Router kommuniziert oder aber ein integriertes Mobilfunkmodem nutzt, um den Things eine indirekte Verbindung ins Internet zu ermöglichen.
Zweitens benötigt das Produkt beziehungsweise System eine Cloud-Anbindung. Über die Kommunikationsschnittstelle des Things werden Daten mit einer IoT- beziehungsweise Cloud-Serviceplattform ausgetauscht. Ohne die Cloud ist IoT nicht möglich. Über die Cloud werden für eine physische Repräsentanz ein jeweils aktuelles Datenabbild als virtuelle Repräsentanz und eine Historie geschaffen.

Drittens muss die gesamte Kommunikation aktuellen IT-Security-Anforderungen entsprechen. Je nach Zielgruppe existieren für eine IoT-Anwendung stark unterschiedliche Sicherheitsanforderungen. Die Nutzer von Fitness-Armbändern sind zurzeit noch sehr tolerant. Sie interessieren sich nicht sonderlich dafür, wie ihre Daten übertragen und auf den Servern des Anbieters geschützt werden. Bei einem PKW mit einer IoT-basierten Monitoring- beziehungsweise Komfort-Anwendung (etwa BMW ConnectedDrive) sieht es jedoch schon ganz anders aus.
Die gesamte Entwicklung sollte sich daher am Security-by-Design-Gedanken und dem aktuellen Stand der Technik orientieren und auch die Möglichkeit für nachträgliche Sicherheits-Updates einbeziehen.

Der virtuelle Clon

In IT, Consumer- und Automotive-Elektronik findet man heute bereits zahlreiche echte IoT-Anwendungen. Sie eignen sich mit Blick auf die Architekturen, Bausteine und Komponenten auch als Beispiele für eigene Entwicklungsvorhaben. Anbieterneutrale Orientierungshilfen findet man aber auch im Förderprojekt „Internet of Things Architecture“ (IoT-A) der Europäischen Union.
Durch dieses EU-Flagship-Projekt soll ein möglichst universelles Referenzmodell für künftige IoT-Anwendungen entwickelt werden. Sensoren, Aktoren und Devices – sprich „Things“ – bilden in diesem Modell die physischen Repräsentanzen. Zu jeder physischen Repräsentanz gehört ein virtuelles Pendant, das mit Hilfe eines IoT- beziehungsweise Cloud-Service im Internet realisiert werden kann.
Auf einer solchen IoT-Serviceplattform wird der aktuelle Zustand der Sensoren und Aktoren beziehungsweise einer Systemhardware gespeichert und bei Bedarf (zum Beispiel bei jeder Zustandsänderung) erneuert. Auf das jeweilige Datenabbild können andere Systeme und Benutzer mittels eines Application Programming Interface (API) zugreifen.
Ein solches Cloud-/IoT-Service-API muss in der Regel unterschiedliche M2M- und IT-Protokolle sowie plattformunabhängige Datenformate unterstützen und da­rüber hinaus geeignete Sicherheitsmechanismen anbieten. Die Daten der virtuellen Repräsentanzen und die dazugehörenden APIs bilden den eigentlichen Funktionskern einer IoT-Anwendung. Über die APIs sind alle externen Embedded-Systems-Komponenten – vom Sensor/Aktor bis zu den übergeordneten IT-Systemen (etwa Scada, ERP, CRM, MES, SQL-Datenbank) – sowie Smartphone-Apps und Webanwendungen in eine IoT-Applikation eingebunden. Mit Hilfe der Service-APIs werden Datenobjekte angelegt, verwaltet, die einzelnen Datenelemente gelesen, mit neuen Werten versehen und – falls erforderlich – auch wieder gelöscht. Die Daten selbst werden in der Regel in einer speziellen Datenbank gehalten.

Datenformate

Für die externe Benutzer- beziehungsweise Anwendungssicht kommen Datenformate wie JSON oder XML zum Einsatz (siehe zum Beispiel die JSON-basierten Real Time Data Channels (RTDC) unter: http://tinyurl.com/pz7wpwr). Auf einer RTDC-basierten IoT-Serviceplattform bildet jede einzelne Anwendung ein separates Datenprojekt mit einem individuellen Schlüsselpaar für die Zugriffsberechtigung per API. Ein RTDC-Datenprojekt beinhaltet beliebig viele Datenobjekte, die sich wiederum aus einzelnen Daten-Items zusammensetzen. Limitierungen der Datenprojekt-, Objekt- und Item-Anzahl existieren lediglich durch die Hardware-Ressourcen der Server, auf denen die RTDC-IoT-Serviceplattform läuft.

Die Historie der Dinge

Neben dem Ist-Zustand (Was ist?) spielt im Internet der Dinge auch deren Vergangenheit (Was war?) eine wichtige Rolle. Die „Was ist?“-Frage lässt sich zum Beispiel jederzeit per RTDC beantworten. Um die Historie eines „Things“ abzubilden, müssen selektive Daten aus der virtuellen Repräsentanz entweder in festen Zeitintervallen oder, bei der Änderung mindestens eines Datenwerts, in eine Datenbank übertragen werden.
Aus der virtuellen Repräsentanz mit den zwei Temperaturwerten „T_SSV“ und „T_SC“ sowie verschiedenen Metadaten wird lediglich T_SSV bei jeder Änderung zusammen mit einem Zeitstempel im Unix-Zeitformat („1416655631“ entspricht „22.11.2014, 11:27:11“) in eine HDC-Datenbank (HDC = Historical Data Channels) übertragen.

Schnittstellen und Protokolle

Die Frage „Welches sind die wichtigsten physikalischen IoT-Schnittstellen?“ lässt sich relativ einfach beantworten. Kabelgebunden ist es Ethernet. Drahtlos (Wireless) sind 2G/3G/4G-Mobilfunk, Wi-Fi und Blue­tooth die wichtigsten Vertreter. Bei den logischen Schnittstellen – also den Kommunikationsprotokollen – ist zurzeit keine eindeutige Antwort möglich. Im Internet der Dinge kommt bereits heute eine nur schwer überschaubare Anzahl unterschiedlicher Protokolle zum Einsatz.

Hier einige wichtige Vertreter:
http – Dieses Protokoll wird täglich für unzählige Milliarden Client/Server-Verbindungen genutzt, weil es im Internet der Menschen die Kommunikation zwischen Webbrowser und Webserver regelt. Für das Internet der Dinge ist http zusammen mit Representational State Transfer (Rest) zwar unverzichtbar, allerdings aufgrund verschiedener Nachteile nicht für alle IoT-Aufgaben geeignet. http existiert in unzähligen Implementierungen auch auf ressourcenlimitierten Things, die noch nicht einmal ein Betriebssystem besitzen müssen. Für die Security wird TLS (https) verwendet.
MQTT – da MQTT ursprünglich für Monitoring-Anwendungen von Öl-Pipelines entwickelt wurde, die über Satellitenverbindungen mit einer IT-Infrastruktur verbunden sind, zeichnet sich dieses Message-Protokoll durch einen sehr effizienten Umgang mit der Bandbreite eines Übertragungskanals aus. MQTT benutzt ein Pub­lish-Subscribe-Konzept mit einem zentralen Message-Broker. Der Datentransport erfolgt per TCP, für die Security ist TLS einsetzbar. In IoT-Anwendungen ist MQTT eine hervorragende Ergänzung zu http, da es zum einen den fehlenden http-Server-Push durch einen Subscribe ersetzt und zum anderen auch über Websockets einsetzbar ist.   
XMPP ist ein sehr spezielles,  auf XML basierendes Nachrichten- und Anwesenheitsprotokoll (XMPP steht für Exten­sible Messaging and Presence Protocol). Per XMPP lassen sich Online-Konferenzen mit mehreren Benutzern, Statusabfragen, Dateiübertragungen und so weiter realisieren. Die Kommunikationsinfrastruktur und Teilnehmeradressierung erinnert an E-Mail-Lösungen (Client to Server, Server to Server). XMPP nutzt TCP oder http. Security ist somit per TLS möglich.
DDS – dieses Protokoll bildet eine Ausnahme, weil es primär für die Kommunikation der Things untereinander (Device to Device) geschaffen wurde. DDS wurde als datenzentrierte Middleware für zeitkritische, verteilte Anwendungen entwickelt. Dabei wird ein netzwerkbasiertes „Datenbus-Konzept“ genutzt. Aufgrund der DDS-Anforderungen bei Zeitverhalten und Flexibilität kommt UDP zum Einsatz. Die Security kann daher per DTLS hinzugefügt werden. DDS wird in den USA für verschiedene Industrial-Internet-of-Thing(IIoT)-Anwendungen im Factory-Automation-Umfeld eingesetzt. AMQP wurde als binäres Message-Protokoll von einem Konsortium aus Banken und IT-Firmen entwickelt. Entwicklungsziel war eine Message-orientierte Middleware, um große Mengen verschiedener Transaktionen zwischen Enterprise-Servern abzuwickeln. In der IoT-Welt könnte dieses Protokoll beispielsweise dazu dienen, die einzelnen Server einer größeren verteilten Anwendung zur Echtzeitdatenanalyse (Business Analytics) miteinander zu koppeln. AMQP nutzt TCP. Für die Security ist TLS einsetzbar.
OMA LWM2M ist ein sehr einfaches, objektbasiertes Client/Server-Protokoll, das wahlweise UDP oder SMS als Transportprotokoll benutzt. OMA LWM2M wurde in erster Linie für den Einsatz in Mobilfunknetzen entwickelt, also für die IoT-Kommunikation zwischen einem 2G/3G/4G-basierten Thing beziehungsweise IoT-Edge-Gateways und einer Cloud-Serviceplattform. Als Besonderheit ist die Device-Management-Unterstützung zu betrachten. Bei der Security ist der Einsatz von DTLS vorgesehen.

Noch etliche weitere Protokolle

Man könnte dieser Aufzählung noch etliche weitere Vertreter hinzufügen. Einige davon lösen spezielle Probleme der hier genannten Protokolle. Ein Beispiel ist ZeroMQ. Da jedes MQTT-basierte Thing vor der Inbetriebnahme mit der Adresse des Brokers konfiguriert werden muss, werden sowohl die erforderliche Vorkonfiguration als auch der Broker selbst als Schwachstelle angesehen. ZeroMQ löst genau dieses Problem. jbi |

Klaus-Dieter Walter ist Geschäftsführer von SSV Software Systems in Hannover.