Koppeln von Echtzeitelementen im IoT: Eine Voraussetzung für Industrie 4.0

Zusammenfassung: Abgesehen davon, dass völlig neue Geräte und Systemkonzepte auf den Markt kommen und der Begriff „Dinge“ enorm viel umfasst, erfordert das Internet der Dinge, dass in der Regel interoperable, integrierte und eng zusammengehörige Teile in lose zusammenhängenden Funktionsclustern zusammenwirken. Dies ist in Ordnung, wenn die Kopplung zwischen bekannten Objekten mit losen Timing-Beschränkungen erfolgt. Bei eingebetteten Echtzeitsystemen, wie sie für Industrie 4.0 benötigt werden, sieht die Sache jedoch völlig anders aus. In diesem Beitrag werden Probleme bei der Kopplung von eingebetteten Echtzeit-Elementen unter besonderer Berücksichtigung der Kopplung über das Internet untersucht. Protokolle wie MQTT, Twisted Engine von Python, Jini (inzwischen Apache River), Node.js und PBOs werden mit ihren Vor- und Nachteilen vorgestellt. Ziel dessen ist die Beschleunigung der Entwicklung eines offenen Standards und eines Lenkungsgremiums.

Vorwort

Wenn es möglich ist, dass Geräte mittels eines etablierten Kommunikationsstandards über das Internet kommunizieren und dieser Standard Vorbote von Industrie 4.0 und IoT ist, warum sollte es dann nicht auch möglich sein, IoT-Geräte ohne den Umweg über eine proprietäre Cloud-Lösung mit anderen zu koppeln? Wir können jede Bluetooth-basierte Maus mit jedem Laptop verbinden. Genauso sollte es möglich sein, jedes hinreichend beschriebene IoT-Gerät mit jedem Smartphone zu verbinden, ohne dazu auf eine proprietäre Lösung zurückgreifen zu müssen. Beide Enden der Verbindung müssten wissen, wie sie miteinander kommunizieren können, auch wenn die Geräte in verschiedenen Subnetzen im selben oder einem anderen physischen Netzwerk und unabhängig von den verwendeten physischen Medien arbeiten. Das hieße uneingeschränkte Interoperabilität. Das erinnert an Universal-Fernbedienungen. Sämtliche Fernbedienungen, die mit Ihrem Fernseher, Ihrer Stereoanlage, Ihrem Heimkino, Ihrem Blu-Ray-Player usw. geliefert wurden, können Sie durch ein Universalgerät ersetzen. Das Problem ist nur, dass der Funktionsumfang nie ganz derselbe ist. Das einzig Universelle an diesen Geräten ist, dass sie alle mit Infrarot-LEDs arbeiten. Diese Fernbedienungen speichern die eindeutigen Codes aller bedienten Geräte. Es wäre machbar, dass alle Geräte dieselben Codes verwenden. Brauchen wir wirklich so viele Codes für „Lautstärke erhöhen“ oder „nächster Sender“, wie es Fernsehhersteller gibt?

Dieser Artikel entstand, weil es keinen offenen und allgemein akzeptierten Standard und keine Spezifikation dafür gibt, wie physikalische Endgeräte in TCP/IP-basierten Netzwerken interagieren können, um Möglichkeiten der Verknüpfung, vielleicht sogar der selbstständigen Verknüpfung zu komplexeren Echtzeitsystemen zu schaffen. Der Artikel soll die Entwicklung eines nicht-proprietären, offenen Standards einläuten und die Möglichkeit für die Entwicklung eines offenen Standards aufzeigen, auf dessen Grundlage jeder oder jede beliebige Gruppe Dienste implementieren kann, über die Geräte unterschiedlicher Hersteller miteinander interagieren können, ohne ein „geschlossenes“ System zu benötigen.

Gerade noch rechtzeitig für diesen Artikel erschienen, heißt es im Artikel von Fischer¹, dass Unternehmen, die sich im IIoT-Bereich engagieren, sehr gute Aussichten haben. Der Autor dieses Beitrags ist der Meinung, dass diese mehr Leistungen und Produkte verkaufen können – zum Teil dadurch, dass sie mit anderen Firmen zusammenarbeiten, „um Kundendaten, die sie auf ihren Geräten speichern und teilen, wertvoller zu machen. Mit denselben Produkten könnten sie Kunden neue Dienstleistungen anbieten und damit ihren Kundenstamm ausbauen.“ In einem weiteren Artikel² wird geschätzt, dass „aus der Integration, Speicherung, Analyse und Präsentation von IoT-Daten“ allein 2015 rund 5,7 Mrd. USD erlöst wurden! Für mich klingt das nach einem heftigen Eingriff in die Privatsphäre und einer Marketing-Goldgrube. Mit anderen Worten: Es ist ein gutes Geschäft, das System geschlossen zu halten. Im Gesagten schwingt zudem mit, dass eine solche Geräte-Geräte-Kopplung von den Unternehmen bewerkstelligt werden muss – nicht von Ihnen. Genau das wird eintreten, wenn wir nichts unternehmen. Dieses Szenario ist die Antithese zu meinem Artikel. Es ist in Ordnung, dass es solche Angebote gibt, aber sie sollten nicht die einzige Option sein. Apple und Weaved können Lösungen für die Leute anbieten, die sich nicht mit den Details herumschlagen wollen. Es gibt Menschen, die genau das wollen. Wenn Sie aber eher der Linux-Typ sind, wünschen Sie sich wahrscheinlich einen übergreifenden offenen Standard.

In diesem Artikel werden Ausschnitte aus den Forschungsergebnissen und Frameworks für verschiedene Technologien und Techniken aus unterschiedlichen Quellen untersucht. Ich habe Technologien ausgewählt, die mich vor dem Hintergrund des angestrebten Ziels faszinieren. Es gibt noch viel mehr zu beachten, als ich hier in der Kürze erläutert habe. Das ist nicht mehr als ein Anfang, auf dem andere aufbauen können. Im Weiteren erläutere ich in meinem Artikel, was meiner Meinung nach für Kommunikation und Sicherheit benötigt wird. Dann befasse ich mich damit, was für Echtzeitsysteme erforderlich ist, um dann abschließend einige konkrete Implementierungen unter die Lupe zu nehmen, die schon sehr weit sind, aber nicht alle von uns geforderten Merkmale aufweisen.

Erfordernisse in Sachen Kommunikation

Konnektivität sowie Erkennung von Geräten und Netzwerken

Die Probleme der Interkonnektivität sind nicht neu³. Schon das Open Systems Interconnection Model (OSI) aus den frühen 1980er-Jahren war ein erster Versuch, das Konnektivitätsproblem anzugehen; es hat uns gute Dienste geleistet, aber das Problem der Erkennung von Geräten und Netzwerken ist nach wie vor ungelöst.

Die Association for Computing Machinery (ACM) hat zu diesem Thema umfangreich geforscht. Die untersuchten Anwendungen sind breit gefächert und reichen von der Fahrzeugvernetzung bis hin zu stationären, netzwerkfähigen Speichergeräten⁴. Auf der 2012 in Helsinki abgehaltenen ACM-Konferenz gab es Vorträge zum Thema „Fog Networking“⁵, und die Princeton University beteiligt sich aktiv an der Entwicklung dieses Konzepts. „Fog“ wurde als Bild für das Konzept einer Wolke auf Bodenhöhe gewählt – was eine weitaus umfassendere Konnektivität auf niedrigerem Niveau ermöglicht. Diese Forschung und die Beschäftigung mit dem softwaredefinierten Networking (SDN)⁶ könnten durchaus den Rahmen schaffen, den wir letztendlich nutzen werden. Während die theoretische Grundlagenarbeit läuft, kommen jedoch weiterhin proprietäre Lösungen auf den Markt. Was gibt es für den Pragmatiker?

Der Universal Serial Bus (USB) dient als Inspiration für die Erkennungsproblematik. Diese erfolgt zum Teil über hinreichend spezifizierte „Klassen“ von Geräten⁷. Dadurch kann nahezu jedes Gerät einfach an nahezu jeden Host angebunden werden. Sobald ein Gerät definiert ist, kann seine Grundfunktionalität für die Nutzung durch eine beliebige Plattform entwickelt werden.

Ein USB-Host übernimmt die Rolle des Gerätekoordinators. Die in¹ implizierten IIoT-Dienste sind Cloud-Dienste, die im Wesentlichen wie Hosts agieren. Die zwingende Notwendigkeit eines Hosts ist jedoch problematisch. Dadurch sah sich das USB Implementers Forum, Inc. veranlasst, USB On-The-Go einzuführen, damit USB-Geräte „sowohl mit USB-Peripheriegeräten als auch direkt miteinander kommunizieren können, wenn kein PC verfügbar ist“⁸. Dasselbe brauchen wir auch für das IoT: eine Kopplung, die direkt von Gerät zu Gerät oder über einen Host oder beides erfolgt.

Sicherheit

Themen und Lösungen für die IoT-Sicherheit sind überschaubar. Am häufigsten wird der Advanced Encryption Standard (AES) 128 eingesetzt. Es gibt Grund zu der Annahme, dass jeder ernsthafte Einsatz von IIoT eine Verschlüsselung erfordert. Stellen Sie sich eine Fabrik mit IoT-gekoppelten Geräten vor, die versehentlich oder mit böswilliger Absicht per Man-in-the-Middle angegriffen werden. Da die meisten IoT-Geräte ihre Verbindungen drahtlos herstellen (z. B. Bluetooth, Wi-Fi, zellulares MODEM, LoRa), müssen Verschlüsselung und Authentifizierung Bestandteil eines neuen Standards sein. Artikel 9 untersucht einige der damit verbundenen Probleme.

Echtzeit-Anforderungen

Stewart beschreibt die Anforderungen an eingebettete Echtzeitsysteme¹⁰. Industrie 4.0 und das IIoT erfordern eine gewisse Echtzeit-Performance, wenn unsere Maschinen und Fabriken auf diese Art gesteuert werden sollen.

Stewart et al. entwickelten ein Framework zur Unterstützung komponentenbasierter Software in einer Abstraktion, die sie Port Based Object (PBO) nannten¹¹. Ihr Ziel war die Entwicklung wiederverwendbarer Echtzeit-Softwarekomponenten. IoT-Geräte kann man sich auch als wiederverwendbare Softwarekomponenten vorstellen. Die Logik dahinter ist Folgende: Wenn wir die Interface-Konzepte von Stewart auf das IoT anwenden, hätten wir ein Framework, auf dessen Basis ein Cyber Physical System (CPS) entstehen könnte. Da das PBO-Konzept ausgereift ist, sind die Untersuchung seiner Einführung sowie die Gründe, die für und gegen sie sprechen, äußerst ergiebig. Kern dieses Konzepts bildet die Notwendigkeit der Darstellung von Echtzeit-Performance. Im Folgenden werden die Bedingungen erläutert, die das Stewartsche Framework adressiert.

Unabhängige Prozesse

Stewart argumentiert in seinem Beitrag¹⁰, dass eingebettete Echtzeitsysteme unabhängige Prozesse einschließen, die untereinander mit relativ hoher Häufigkeit relativ kleine Datenmengen austauschen müssen. Diese Häufigkeiten sind mit Sicherheit höher als vom Internet realisierbar. Auch wenn die heutigen Internet-Bitraten Hunderte von Megabit pro Sekunde betragen, machen die Nutzlastgröße und die Notwendigkeit von Handshakes die internetbasierte Kommunikation in den meisten modernen, eingebetteten Echtzeitsystemen unmöglich. Die Kommunikationsdichte für Echtzeit-IoT-Geräte ist beeinträchtigt. Möglicherweise können Kommunikationsnutzlasten aus mehreren Prozessen gebündelt werden, um die Nutzlasteffizienz zu erhöhen und die Anzahl der Übertragungsinstanzen zu minimieren.

Aufgrund der Verarbeitungslast der TCP/IP-Kommunikation muss eine Anwendung, die sonst nur einen 8-Bit-Host-Prozessor benötigt, in der Regel eine 32-Bit-Lösung sein. Glücklicherweise kostet ein 32-Bit-Gerät in moderater Menge weniger als 0,50 USD. Daher gehe ich davon aus, dass IoT-Geräte 32-Bit-Kerne enthalten.

Bindung zwischen unabhängigen Prozessen

Diese unabhängigen Prozesse müssen miteinander verbunden werden, um einen Ausgangswert aus verschiedenen Eingängen zu ermitteln, und mehrere Ausgangswerte könnten erforderlich sein, um noch weitere Ausgänge zu verarbeiten. Stewart argumentiert, dass diese Bindungen vorzugsweise so aussehen, dass sie dynamisch rekonfigurierbar sind und innerhalb bestimmter Fristen miteinander gekoppelt werden können. Beispielsweise könnte ein Gerät online gehen oder erkannt werden, das in der Lage ist, die Kommunikationslast eines vorgeschalteten Gerätes zu reduzieren und dadurch eine nachgeschaltete Senke dynamisch zu trennen und mit einer neuen vorgeschalteten Quelle erneut zu verbinden. Es wäre vorteilhaft, dem in unserem Standard Rechnung zu tragen. Geräte sollten die Möglichkeit bieten, Daten zu analysieren, zu puffern und zu verteilen/umzuverteilen. Das bedeutet, dass wir neben der Definition von verteilten Gerätetypen wahrscheinlich auch verteilte Funktionen und Rollen spezifizieren müssen. Diese Funktionen und Rollen können als „virtuelle“ oder „abstrakte“ IoT-Geräte betrachtet werden.

Erste USB-basierte Entwicklungstools hatten ein Problem, wenn der Host beschäftigt war. Sie hatten keine Möglichkeit, den Host zu zwingen, sie zur Kenntnis zu nehmen. Das hatte zur Folge, dass sie sporadische Aussetzer hatten und „buggy“ waren. Erst als diese Tools intelligenter wurden (z. B. mehr Arbeitsspeicher hatten, für eine zeitnahe Antwort weniger abhängig von einer Remote-CPU waren), wurde dieses Problem minimiert. IoT-Geräte müssen intelligent sein.

Mehrere CPUs

Häufig wird zum Erreichen der Leistungsziele bei Echtzeit-Embedded-Systemen mindestens eine CPU genutzt. Das kann in Form von mehreren Mikroprozessoren, Programmierlogik-Chips oder beidem realisiert werden. Es muss eine Multiplizitätszuordnung von CPUs zu IoT-Geräten geben.

Die Koordination zwischen mehreren CPUs sollte es jeder CPU ermöglichen, unabhängig von anderen CPUs zu arbeiten. Wie bei der Verarbeitung von Threads in den CPUs moderner PCs könnte jede verfügbare CPU möglicherweise dazu beitragen, die Kommunikationsbandbreite zu reduzieren, indem sie Informationen aus Rohdaten komprimiert bzw. extrahiert. Oder sie könnte ein gewisses Maß an Fehlertoleranz bieten. Unabhängig von der Anwendung sollte das System tolerant gegenüber verschiedenen Betriebsfrequenzen und unterschiedlichen Kommunikationsraten sein – wie Stewart es nennt –, damit mehrere CPUs (Knoten) unterstützt werden.

Verschiedene Frameworks

Im Folgenden beschreibe ich einige Frameworks, die einigen Bekanntheitsgrad erlangt haben und Merkmale aufweisen, die sie für unser Ziel geeignet machen. Ich werde erläutern, warum sie erfunden wurden und inwiefern sie sich eignen. Die Aufzählung beginnt mit Jini, erstreckt sich über Node.js und Twisted und endet mit MQTT, das sich nach meinem Dafürhalten zum De-facto-Standard für die geschlossenen Implementierungen entwickeln wird.

Jini (jetzt Apache River)^12 13

Venerable Jini wurde Ende der 90er-Jahre von Sun entwickelt und wird heute als Apache River-Projekt weitergeführt. Es basiert auf Java. Es wurde entwickelt, um es modularen Diensten zu ermöglichen, sich über ein Netzwerk miteinander zu verbinden und auf diesem Weg eine sogenannte Service-Objekt-orientierte Architektur zu etablieren. Interessant an Jini war u. a. die Fähigkeit, dass sich Netzwerkeinheiten (z. B. Dienste) selbst erkennen können. Dies erfolgt über einen zentralen Broker (ein Lookup-Service), den alle Clients kontaktieren, um Informationen über die anderen einzuholen. Einmal erkannt, können die Dienste miteinander interagieren. Es heißt, dass sich der Lookup-Service nicht gut auf sehr große Systeme skalieren lässt. Und beim IoT geht es um potenziell riesige Systeme.

Bei Jini gab es drei übergeordnete Ziele: (1) Clients sollten nicht wissen müssen, wo sich ein bestimmter Dienst befindet, (2) Clients sollten nicht fehlschlagen, wenn der Dienst nicht verfügbar ist oder während der Ausführung seine Verfügbarkeit einbüßt, und (3) Clients und Dienste sollten proaktiv sein, um Fehlerzustände zu erkennen. Das sind auch für unseren Standard angemessene Ziele.

Da Jini auf Java basiert, gibt es eine gewisse Verbindung zu eingebetteten Geräten, weil Java ja ursprünglich als Plattform für kleine, eingebettete Systeme in elektronischen Geräten wie Set-Top-Boxen gedacht war. So weit, so gut, aber Java ist die Sprache von IT-Abteilungen. Es ist heute keine Plattform für kleine eingebettete Systeme mehr, sofern es sich dabei nicht um Einplatinencomputer (SBC) wie den BeagleBone Black oder den Raspberry Pi handelt. Dennoch ist die Objekterkennung ein nettes Feature für unsere Spezifikation. Und auch das Konzept eines zentralisierten Brokers als optionale Komponente ist eine praktische Sache. Wie bereits erwähnt, handelt es sich bei den heute existierenden geschlossenen Systemen im Wesentlichen um zentralisierte Broker. Ich sehe darin einen gewissen Wert, aber nur als Option.

Node.js¹⁴

Node.js wurde 2009 entwickelt, um Webservern die Möglichkeit zu geben, in Eigenregie eine Verbindung zu den Clients herzustellen. Klingt gut: Unsere eingebetteten IoT-Geräte kann man sich vereinfacht als kleine Webserver vorstellen. Also könnte das zu unserem Szenario passen.

Auf der node.js-Website heißt es: „Node.js^® nutzt ein ereignisgesteuertes, nicht blockierendes I/O-Modell, wird dadurch schlank und effizient und eignet sich perfekt für datenintensive Echtzeit-Anwendungen, die auf verteilten Geräten laufen.“ Das klingt nach der perfekten Plattform. Allerdings basiert node.js auf der JavaScript-Laufzeitumgebung von Chrome, und „Echtzeit“ bedeutet hier websitzungsbasiert – und das ist etwas völlig anderes als Echtzeit in unserem Embedded-Kontext. Nehmen Sie beispielsweise die Datenrate, die für ein IoT-Gerät erforderlich ist, das Zyklen durchläuft, die eine Verpackungsmaschine ausführt. Diese Maschinen verpacken Waren mit einem Durchsatz von Tausenden Stück pro Minute. Node.js wurde einfach nicht für die Echtzeit-Performance entwickelt, wie sie die meisten IoT-Geräte benötigen.

Zudem würde das IoT-Gerät bei nicht modifiziertem Einsatz mindestens eine JavaScript-Engine benötigen. Nun sind JavaScript-Engines ja normalerweise in Webserver wie Apache integriert; es gibt zwar noch weitere Möglichkeiten wie V8¹⁵ und TraceMonkey¹⁶, aber keine davon ist für ihre Geschwindigkeit bekannt. Das bedeutet, dass node.js wahrscheinlich zu komplex für den Einsatz in IoT-Geräten ist. Diese Plattform eignet sich für Einplatinencomputer oder besser noch komplette PCs. Kurzum: node.js ist meines Erachtens keine gute Plattform für unseren Standard.

Twisted¹³

Twisted ist in Python geschrieben und wurde für die Entwicklung von Internetanwendungen, insbesondere von Spielen, entwickelt. Es ist ein ereignisgesteuertes Netzwerk-Programmier-Framework. Entwickler schreiben Callback-Routinen, die vom Framework aufgerufen werden. Twisted sollte Spieleentwicklern damals die Möglichkeit geben, internetbasierte Kommunikation in ihre Spiele einzubetten. TCP- und UDP-Dienste sowie ein Unix-Socket-Interfacing-Modell bilden den Kern dieses Frameworks.

Ein Vorteil von Twisted mit seiner Python-Basis ist der, dass die zugrunde liegende Engine, die Python-Engine, unter anderem in C geschrieben ist. Das ist ein großer Vorteil im Hinblick auf die Lauffähigkeit auf eingebetteten Geräten, weil fast alle eingebetteten Geräte für C entwickelt werden. CPython¹⁷ ist die Python-Haupt-Engine, es gibt aber auch Engines wie PyMite¹⁸, die auf 8-Bit-Geräten mit nur 64 KB nichtflüchtigem Speicher und 4 KB RAM laufen. Das heißt aber nicht, dass ein IoT-Gerät zwangsläufig ein 8-Bit-Gerät sein sollte. Ich erwähne das nur, um zu verdeutlichen, wie kompakt eine Python-Engine sein kann. Aufgrund der erwähnten Lasten durch TCP/IP wird von IoT-Geräten erwartet, dass sie 32-Bit-Kerne einbetten. Twisted scheint ein würdiger Rahmen für unseren Standard zu sein.

Python kann auch in Produkte eingebettet werden, um Endanwendern eine integrierte Programmierschnittstelle zur Verfügung zu stellen¹⁹. Bei Twisted sieht das sogar noch besser aus. Programmierbare IoT-Geräte können jetzt von Endanwendern in Python programmiert werden. Sehr schön!

Die von Twisted benötigten Callback-Routinen heißen „deferreds“. Sie laufen asynchron zur sonstigen Verarbeitung. Das erfordert eine andere Denkweise, damit die Echtzeitverarbeitung funktioniert. Normalerweise werden Aufgaben mit hoher Priorität in einer Interrupt-Service-Routine platziert. Asynchrone Callbacks erfordern jedoch alternative Ansätze zur Unterbrechung von Routinen, z. B. semaphorenbasiertes Gating. Das Endergebnis kann nur eine Fast-Echtzeit-Performance sein – ein Zustand, in dem gelegentliche Verluste von Echtzeit-Ereignissen toleriert werden.

Twisted ist so konzipiert, dass es an einem oder beiden Enden einer Client-Server-Verbindung implementiert werden kann. Da der Mechanismus beliebige Informationen über die TCP/IP-Suite von Diensten senden kann, bleibt er ein guter Kandidat.

Twisted umfasst jedoch keine Klassentypdefinitionen im USB-Stil. Dadurch ist Twisted für jede Ad-hoc-Anwendung bzw. jedes Produkt, das über eine TCP/IP-basierte Schnittstelle verfügt, einfach einzusetzen. Für die Einbindung eines Gerätes in eine Anwendung wird jedoch benutzerdefinierter Code benötigt. Twisted benötigt eine Gerätetypspezifikation wie USB On-The-Go, damit bekannte Geräte ohne Neuentwicklung in die Anwendung eingebunden werden können. Diese Spezifikation muss an einem der Enden oder an beiden Enden einer Verbindung vorliegen.

OASIS MQTT (Message Queue Telemetry Transport)²⁰

MQTT ist ein schlankes Publish/Subscribe-Nachrichtenprotokoll. Ursprünglich entwickelt von IBM und Arcom wurde es 2014 zu einem offenen Standard von OASIS. OASIS sieht seine Aufgabe darin, die Entwicklung, Konvergenz und Durchsetzung offener Standards für die globale Datenkommunikation voranzutreiben.

MQTT wird als äußerst einfach und schlank beschrieben und ist für Geräte mit Beschränkungen sowie Netzwerke mit geringer Bandbreite, hoher Latenz oder schwankender Zuverlässigkeit ausgelegt. Ziel ist es, die Netzwerkbandbreite und den Ressourcenbedarf der Geräte ohne Beeinträchtigung der Zuverlässigkeit zu minimieren und die Zustellung der Nachrichten zu garantieren. MQTT wurde als ideal für das IoT angepriesen, und es hat eine weite Verbreitung.

Als Protokoll muss es implementiert werden, um zum vollständigen Framework zu werden. Eine solche Implementierung ist das Eclipse-Paho-Projekt. Es unterstützt MQTT in einer Vielzahl von Sprachen, darunter C/C++, Java, JavaScript und Python²¹. Die meisten Implementierungen sind für die Client-Seite vorgesehen, aber auch serverseitige Implementierungen sind verfügbar.

Der Server wird in MQTT als „Message Broker“ bezeichnet. Im Gegensatz zu Twisted, bei dem Endgeräte direkt miteinander kommunizieren können, muss dies bei MQTT in der Regel über diesen Message Broker erfolgen.

Eine Python-Implementierung eines MQTT-Brokers ist beispielsweise Mosquitto; mit Apache ActiveMQ wäre eine weitere zu nennen. ActiveMQ ist eine Java-Implementierung mit Anbindungen an viele weitere Sprachen. Mit RabbitMQ und ZeroMQ gibt es noch weitere Message Broker. Darüber hinaus gibt es noch Broker, die verschiedene andere IT-Protokolle unterstützen.

Wie bereits erwähnt, greifen viele proprietäre IoT-Lösungen für das Messaging auf MQTT zurück. Das Problem dabei ist, dass kein Standard regelt, welche Daten von welchen IoT-Geräten kommuniziert werden müssen. Die existierenden MQTT-Implementierungen sind nur mit sich selbst kompatibel. Das Protokoll ermöglicht zwar die Kommunikation von Nachrichten, aber nur die IoT-Geräte, die für diese Nachrichten konzipiert wurden, verstehen, was sie bedeuten. Für jedes andere Gerät, das die Informationen eigentlich nutzen könnte, sind die Nachrichten nur Kauderwelsch. Dasselbe gilt für Twisted. Perfekt wäre es, Twisted mit MQTT als Protokoll zu verwenden. Dann muss es aber für jede Art von IoT-Funktion einen Nachrichteninhaltsstandard geben.

Weitere Forschungsprojekte und Protokolle

In der Tat gibt es eine verwirrende Vielzahl von Wahlmöglichkeiten für Protokolle und Frameworks, die es zu berücksichtigen gilt; die meisten von ihnen sind rein akademischer Natur. Sehr aktiv im Bereich der Cyber Physical Systems (CPS)²² ist das Center for Intelligent Maintenance Systems. Chef des Zentrums ist Dr. Jay Lee. Er leitet die Entwicklung eines Konzepts, das als 5C-Architektur^23 24 25 bezeichnet wird. 5C steht für Connection, Conversion, Cyber, Cognition und Configuration (Verbindung, Konvertierung, Cyber, Erkennung und Konfiguration). Das ist ein allgemeiner Rahmen, der sich auf unser Vorhaben anwenden ließe, weil es gegenwärtig Systeme gibt, die dieses Schema nutzen.

Weitere Protokolle sind in Quelle²⁶ aufgeführt. Erwähnt sind dort das Advanced Message Queuing Protocol (AMQP) und das Simple/Streaming Text Oriented Messaging Protocol (STOMP). Zudem gibt es weit verbreitete Datenformate wie XML und JSON. Es gibt viel Material, das in Betracht gezogen werden kann, aber es gibt auch genug, um noch heute mit der Entwicklung eines Standards und eines Development Frameworks zu beginnen.

Beispiele für proprietäre Lösungen

Wunder Bar ist ein IoT-Starter-Kit, das von Conrad gesponsert, von relayr entwickelt wurde und von Mikroelektronika²⁷ produziert wird. Es besteht aus IoT-Modulen zur Erfassung von Licht, Temperatur, Beschleunigung, Infrarot, Schall, Feuchtigkeit und mehr. Diese Module kommunizieren ihrerseits über eine Bluetooth-Verbindung mit einem Hauptmodul. Das Hauptmodul hat keine Sensoren. Seine Aufgabe ist es, über ein MQTT-basiertes Kommunikationsschema mit dem von relayr bereitgestellten Cloud-Service zu kommunizieren. Über den Cloud-Service können die Nutzer auf ihren Android- oder iOS-basierten Smartphones oder PCs auf die Daten aus diesen Modulen zugreifen. Es ist ein cleveres und gut durchdachtes Paket. Ohne die Hardware zur Verfügung zu stellen, bietet Weaved vergleichbare Cloud-Services an, die jedoch nicht mit relayr kompatibel sind. Selbst wenn sie MQTT verwenden, ist keine Verwechslung möglich.

Die Cloud-Software von relayr ist Closed-Source-Software, aber der Code des Hauptmoduls müsste bis zur Embedded World 2015 als Open-Source-Code verfügbar sein. Dann sollten die Anwender in der Lage sein, ihre eigene Cloud-Lösung zu entwickeln. Unabhängig davon bleibt das Problem, dass es keine offene Plattform gibt, die sofort einsatzbereit wäre. Für jede benutzerdefinierte Lösung müssen die bestehenden Funktionen umgeschrieben werden, um eine benutzerdefinierte oder offene Cloud zu ermöglichen.

Eine weitere, in Kürze verfügbare Lösung stammt von Adafruit²⁸. Im Vorwort des Blog-Eintrags, in dem die Lösung angekündigt wird, heißt es: „Adafruit verkauft all diese beindruckenden Komponenten, fand aber keinen Weg, über das Internet mit ihnen zu interagieren. Sicherlich gibt es eine Menge großartiger Dienste für die Protokollierung von Daten oder die webbasierte Kommunikation mit Ihrem Mikrocontroller, aber diese Dienste sind entweder zu kompliziert, um als Ausgangspunkt zu dienen, oder ihre Nutzung ist nicht gerade die reine Freude.“ Besser hätte ich es nicht formulieren können.

Herzstück des Adafruit-Angebots ist die Nutzung und Anzeige von Echtzeitdaten über ein einfach zu bedienendes Dashboard. Die 2-Wege-Interaktion realisiert Adafruit über eine RESTful-API. Zudem wird in gewissem Maß auch MQTT unterstützt. Das Framework basiert auf node.js (bereits besprochen), Ruby on Rails, Postgresql, Redis und Memcached.

Mit Adafruit haben wir ein Unternehmen, das sich für Open Source starkmacht. Dennoch muss Adafruit mit einer proprietären Lösung arbeiten, weil es noch keine offene Lösung gibt.

Organisationen, die an offenen Lösungen für das IoT arbeiten

Das Thema IoT ist definitiv ein viel diskutiertes Thema. Interessant ist in diesem Zusammenhang ein Blick auf die Eröffnungsrede der Consumer Electronics Show 2015, die Adafruit für uns archiviert hat²⁹. Samsung verspricht darin, offen zu sein. Das klingt erstmal gut.

Ich erwähnte bereits, dass Quelle¹ gerade noch rechtzeitig für diesen Artikel erschien. Als ich den vorliegenden Artikel schrieb, erschien ein anderer Artikel. Dort war die Rede von Unternehmen und Organisationen, die Allianzen bilden, um am Problem der Etablierung von Standards und der Schaffung kollektiver Möglichkeiten³⁰ zu arbeiten.

Eine dieser Organisationen ist das „Internet of Things Consortium“ (IoTC). Die eingangs erwähnte Sorge, dass das Internet der Dinge zu einer Marketing-Goldgrube wird, scheint begründet zu sein. Auf der Homepage des IoTC heißt es: „Das IoTC Research Lab führt Forschungsprojekte durch, mit denen in erster Linie Kaufabsichten, Nutzungsmuster und der Bekanntheitsgrad von IoT-Produkten ermittelt werden sollen.“ Die Organisationen, die auf der IoTC-Website aufgelistet sind, wollen Geld verdienen. Für die Nutzer von Industrie 4.0 und IIoT-Geräten wird dies meines Erachtens aber keine Rolle spielen. Das IoTC ist ein verbraucherorientiertes Gremium.

Als weitere Organisation dieser Art wird die Allseen Alliance³¹ genannt. Die Website sieht zwar wie die einer Marketingfirma aus, enthält aber seriöse technische Informationen für Entwickler. Das „AllJoyn“-Code-Framework der Alliance ist Open-Source, unterstützt aber nur die Sprachen C-, C++, Objective-C und Java.

Angesichts dessen wage ich zu behaupten, dass es keinen einheitlichen Standard für das IoT geben wird. Ich glaube nicht einmal, dass es einen für das IIoT und Industrie 4.0 geben wird. Die Debatte darüber überlasse ich gern den Akademikern.

Fazit

Es gibt viele Technologien, aber kein offenes Komplettpaket, das unsere Bedürfnisse erfüllt. Die auf dem Markt angebotenen Lösungen sind limitiert, geschlossen oder dazu vorgesehen, von bestimmten Interessengruppen ausgenutzt zu werden. Vergleichbar mit den Amateurfunk-Enthusiasten ist das die Gruppe, die viel herumexperimentieren kann – was notwendig ist, damit sich ein Basisstandard durchsetzt. Mir gefällt die Vorstellung von einem Wettstreit der Ideen. Diese Ideen sollen jedoch offen sein und nicht von großen Unternehmen gesponsert werden.

Es mag unrealistisch klingen, aber mir schwebt ein offener Standard vor, der Folgendes ermöglicht:

• Verbinden von IoT-Geräten über TCP/IP-basierte Protokolle, Wi-Fi, Ethernet, Bluetooth, USB usw. mit und ohne zentralen Server
• Wiederverwendung oder Integration von Software mit minimalem Entwicklungs- oder Refactoring-Aufwand
• Integration von Geräten, die von verschiedenen Parteien entwickelt und eingesetzt werden, über Selbsterkennung oder automatische Erkennung und Schnittstellen
• Programmieren in C oder C++ und Python
• Implementierung eines eigenen Cloud-Service

Das lässt sich meines Erachtens realisieren mit:

• Python und C/C++
• MQTT
• Modifikation von Twisted, damit es als Code-Framework für diesen Standard dienen kann
• Einbindung von im USB-Stil definierten Klassen
• Eine unabhängige Organisation, die Folgendes pflegt:
  • den Standard
  • die Dokumentation und den Code des Frameworks als herunterladbare Module, damit für hinreichend definierte Geräte kein neuer Code entwickelt werden muss
  • Akzeptanz und Registrierung von IoT-definierten Klassen
  • Rolle als Message Broker als Grundlage für die Geräteerkennung

Danksagung

Ich danke Travis Dazell von Digi-Key, der meine Aufmerksamkeit auf das Thema Fog Networking gelenkt hat.

Verwendete Literatur

1. B. Fischer, „How High Tech Can Pursue Industrial Internet of Things Market“, 30. Dezember 2014. Online. Abgerufen am 6. Januar 2015.
2. Business Wire, „Market for IoT Analytics to Reach US$5.7 Billion in 2015, with Startups Driving the Innovation, According to ABI Resear“, Business Wire, 13. Januar 2015. Online. Abgerufen am 15. Januar 2015.
3. S. P. Kumar und C.-Y. Chong, „Sensor Networks: Evolution, Opportunities, and Challenges“, PROCEEDINGS OF THE IEEE, Bd. 91, Nr. 8, S. 1247–1256, 2003.
4. F. Bonomi, „Connected vehicles, the internet of things, and fog computing“, in VANET 2011, Las Vegas, USA, 2011.
5. F. Bonomi, R. Milito, J. Zhu und S. Addepalli, „Fog Computing and Its Role in the Internet of Things“, in „Proceedings of the first edition of the MCC workshop on Mobile cloud computing“, Helsinki, 2012.
6. D. Kreutz, F. Ramos, P. Verissimo, C. Rothenberg, S. Azodolmolky und S. Uhlig, „Software-Defined Networking: A Comprehinsive Survey“, Proceedings of the IEEE, Bd. 103, Nr. 1, S. 14–76, 2015.
7. USB.org, „USB Class Codes“, Online. Abgerufen am 6. Januar 2015.
8. USB.org, „USB On-The-Go and Embedded Host“, Online. Abgerufen am 10. Januar 2015.
9. B. Boldt, „Is the Internet of Things just a toy?“, 2. Januar 2015. Online. Abgerufen am 6. Januar 2015.
10. D. B. Stewart, „Software components for real time“, Embedded Systems Programming, S. 100–138, Dezember 2000.
11. D. B. Stewart, R. A. Volpe und P. K. Khosla, „Design of dynamically reconfigurable real-time software using port-based objects“, IEEE Transactions on Software Engineering, Bd. 23, Nr. 12, S. 759–776, 1997.
12. S. Oaks und H. Wong, JINI in a Nutshell, Sebastopol: O'Reilly, 2000.
13. Twisted Matrix, „Twisted Matrix Labs“, Online. Abgerufen am 8. Januar 2015.
14. node.js, „node.js“, Online. Abgerufen am 8. Januar 2015.
15. Wikipedia, „V8 (JavaScript engine)“, Online. Abgerufen am 9. Januar 2015.
16. Wikipedia, „SpiderMonkey (software)“, Online. Abgerufen am 9. Januar 2015.
17. python.org, „EmbeddedPython“, Online. Abgerufen am 9. Januar 2015.
18. python.org, „PyMite“, Online. Abgerufen am 9. Januar 2015.
19. Python Community, „5. Embedding Python in Another Application“, Online. Abgerufen am 8. Januar 2015.
20. MQTT Community, „MQTT“, Online. Abgerufen am 8. Januar 2015.
21. eclipse.org, „paho“, eclipse.org, Online. Abgerufen am 12. Januar 2015.
22. „Center for Intelligent Maintenance Systems“, Online. Abgerufen am 13. Januar 2015.
23. J. Lee, B. Bagheri und H.-A. Kao, „A Cyber-Physical Systems architecture for Industry 4.0-based manufacturing systems“, Manufacturing Letters, S. 18–23, Januar 2015.
24. Center for Intelligent Maintenance Systems, „IMS_CPS“, Center for Intelligent Maintenance Systems, Online. Abgerufen am 13. Januar 2015.
25. „Cyber-physical system“, wikipedia.org, Online. Abgerufen am 13. Januar 2015.
26. vFabric Team, „Choosing Your Messaging Protocol: AMQP, MQTT, or STOMP“, VMware, 19. Februar 2013. Online. Abgerufen am 12. Januar 2015.
27. Mikroelektronika, „Wunder Bar“, Mikroelektronika, Online. Abgerufen am 13. Januar 2015.
28. adadfruit.com, „Coming Soon: Adafruit IO“, adadfruit.com, Online. Abgerufen am 13. Januar 2015.
29. adafruit, „Samsung promises to be open for IoT components and devices @Samsungtweets #samsung #Iot #CES #ces2015“, adafruit.com, 6. Januar 2015. Online. Abgerufen am 16. Januar 2015.
30. B. Cha, „A Beginner’s Guide to Understanding the Internet of Things“, recode.net, 15. Januar 2015. Online. Abgerufen am 16. Januar 2015.
31. „Allseen Alliance“, Online. Abgerufen am 18. Januar 2015.