Der IoT Hub

Der IoT Hub implementiert den plattformseitigen Endpunkt für den Datenaustausch zwischen der IoT-Plattform und den angebundenen Geräten. Prinzipiell kann die Kommunikation zwischen den Geräten und dem IoT Hub auf der Basis beliebiger Anwendungsprotokolle erfolgen, die von beiden Endpunkten unterstützt werden. Da Rechnernetze selbst eine Schichtenarchitektur besitzen, sind stets mehrere hierarchisch organisierte Netzwerkprotokolle am Datenaustausch beteiligt (vgl. Protokollstapel). In der oberen Protokollschicht, d. h. in der Anwendungsschicht hat sich mit Message Queuing Telemetry Transport (MQTT) ein De-facto-Standard durchgesetzt, der nahezu in jedem IoT Hub implementiert ist und darüber hinaus auch in der API zum Einsatz kommt. Gleichwohl sind geräteseitig auch andere Protokolle in Verwendung, die nicht von jedem IoT Hub unterstützt werden, sodass in solchen Fällen Gateways zu deren Konvertierung erforderlich sind. Insbesondere findet im industriellen Umfeld eine Datenübertragung oftmals nur innerhalb der Automatisierungsebene, d. h. in den untersten Protokollschichten statt, die dort einer Vielzahl unterschiedlicher Feldbussysteme entsprechen (bspw. CAN, Modbus oder Profibus). In dieser Ausgangslage werden zunächst Ethernet-Feldbus-Koppler benötigt, um überhaupt eine Netzwerkverbindung herzustellen.

Ist die Konnektivität innerhalb der Anwendungsschicht hergestellt, impliziert dies nicht, dass der Empfänger die übertragenen Nutzdaten zu interpretieren weiß. Der IoT Hub muss dazu in der Lage sein, innerhalb der empfangenen Nutzdaten einzelne Informationseinheiten zu identifizieren und diese in Datenstrukturen zu überführen, welche die Verarbeitungslogik der IoT-Plattform semantisch korrekt zu interpretieren vermag. Damit seitens der Plattform auch schreibend auf ein Gerät zugegriffen werden kann, muss der IoT Hub überdies alle schreibenden Operationen in die spezifischen Steuersignale des jeweiligen Gerätes übersetzen können. Bei den speicherprogrammierbaren Steuerungen von Maschinen und Produktionsanlagen bedeutet das, die richtigen Bits in die richtigen Speicheradressen zu schreiben. Der IoT Hub übernimmt somit die Funktion, die ein Gerätetreiber in einem Betriebssystem erfüllt. Das Spektrum der vom IoT Hub unterstützen Gerätesteuerungen ist ausschlaggebend dafür, in welchem Umfeld eine IoT-Plattform überhaupt sinnvoll eingesetzt werden kann bzw. für welche Anwendungsbereiche sie geeignet ist.

Verarbeitungslogik und Datenpersistierung

Die Verarbeitungslogik der Plattform zeichnet alle über den IoT Hub eintreffenden Daten chronologisch auf und stellt sie der Anwendungsprogrammierschnittstelle in aufbereiteter Form zur Verfügung. Anwendungsseitig initiierte Steuersignale werden dem IoT Hub zur weiteren Vermittlung an die Gerätesteuerungen übergeben. Ferner werden die von den Geräten empfangen Daten miteinander verknüpft und verdichtet. Graphische Benutzeroberflächen oder auch HTTP-Konfigurationsschnittstellen erlauben die Pflege der Stammdaten und die Konfiguration eines der Verarbeitungslogik zugrunde liegenden Regelwerks. Außerdem werden aus den eintreffenden Nachrichten komplexe, d. h. auf Anwendungsebene relevante Ereignismeldungen abgeleitet. Verarbeitungstechniken wie Complex Event Processing (CEP) ermöglichen es, Anwendungen in Echtzeit über relevante Ereignisse zu unterrichten.

Zur Persistierung der eintreffenden Daten werden bisweilen mehrere Datenbanksysteme parallel eingesetzt. Üblich sind sowohl speziell für Zeitreihen ausgelegte Datenbanksysteme als auch dokumentenorientierte Datenbanken wie MongoDB. Um einen größeren und schnelleren Datendurchsatz zu erreichen, werden häufig auch speicherzentrierte, verteilte Datenbank-, Caching- und Verarbeitungsplattformen wie Apache Ignite in die IoT-Plattform integriert.

Viele der im industriellen Umfeld betriebenen IoT-Plattformen bieten spezielle Schnittstellen für den wechselseitigen Datenaustausch und die Interaktion mit Drittsystemen an. Zumeist handelt es sich dabei um Schnittstellen zu ERP-Systemen verschiedener Hersteller. Regeln für die Interaktion mit diesen Drittsystemen werden in graphischen Benutzeroberflächen konfiguriert und von der Verarbeitungslogik der Plattform umgesetzt. Zur schnelleren Anbindung der ERP-Systeme an die IoT-Plattform stellen einige Anbieter sogenannte ERP-Adapter zur Verfügung, die als Modul innerhalb des jeweiligen ERP-Systems ausgeführt werden. Für die in der Produktion eingesetzten IoT-Plattformen ist der Datenaustausch mit ERP-Systemen unabdingbar, weil darin die Fertigungsaufträge zur bedarfsorientierten Steuerung der Produktion generiert werden.

Die Anwendungsprogrammierschnittstelle

In der Anwendungsprogrammierschnittstelle wird ein digitales, d. h. maschinenlesbares Abbild der an die IoT-Plattform angebundenen Geräte implementiert. In der Regel handelt es sich dabei um die Teilmenge eines umfassenderen Abbildes physischer und virtueller Gegenstände, in dem die Geräte jenen physischen Gegenständen zugeordnet werden, deren Bestandteil sie sind. Physische Gegenstände, wie etwa ein Fahrzeug oder eine Maschine, sind dadurch gekennzeichnet, dass sie zu jedem Zeitpunkt anhand ihres Aufenthaltsortes (englisch Location) lokalisierbar sind. Einem virtuellen Gegenstand, beispielsweise einem Lieferauftrag, kann dagegen weder ein Ort noch ein Gerät zugeordnet werden.

Anwendungen interagieren mit den angebundenen Geräten ausschließlich über die API. Infolge etablierter IoT-Standards weisen die Anwendungsprogrammierschnittstellen verschiedener IoT-Plattformen nur geringfügige Unterschiede auf. Aus diesem Grunde lassen sich Anwendungen, welche für eine bestimmte IoT-Plattform entwickelt wurden, mit geringem Aufwand auf andere Plattformen portieren. Physische und virtuelle Gegenstände werden in der API als Ressourcen abgebildet, die über einen Uniform Resource Locator (URL) adressiert und eindeutig identifiziert werden können. Ebenso werden die angebundenen Geräte und die Zeitreihen der von den Geräten übertragenen sensorischen Messwerte als Ressourcen abgebildet. Für den Zugriff auf all jene Ressourcen stehen ausschließlich die im Hypertext Transfer Protocol (HTTP) definierten Methoden zur Verfügung. Sie bilden eine für alle IoT-Plattformen uniforme Schnittstelle und gewährleisten dadurch die strukturelle Interoperabilität verschiedener Plattformen. Die gebräuchlichsten Methoden sind:

• GET zum Anfordern einer Ressource
• PUT zum Ändern einer Ressource
• DELETE zum Löschen einer Ressource
• POST unter anderem zum Erzeugen einer Ressource

HTTP abstrahiert insofern von einer konkreten Repräsentation der Ressourcen, als diese in beliebigen Formaten repräsentiert werden können. Prinzipiell kommen für eine API hierzu alle maschinenlesbaren Formate in Frage. Gleichwohl verwenden die marktgängigen IoT-Plattformen ausschließlich die JavaScript Object Notation (JSON) als Repräsentationsformat und gewährleisten damit auch die syntaktische Interoperabilität verschiedener Plattformen. Anwendungsprogrammierschnittstellen auf der Grundlage von HTTP und JSON werden mittlerweile als REST-like oder REST API bezeichnet, wenngleich letzterer Bezeichnung ein Missverständnis zugrunde liegt. REST als Abkürzung für REpresentational State Transfer beschreibt eigentlich nur eine bestimmte Ausprägung ressourcenorientierter Architekturen und kein konkretes Protokoll oder Format.

REST-like API

Jede IoT-Plattform stellt zur Entwicklung und Ausführung von Anwendungen diesen ein digitales Abbild der angebundenen Geräte in Form einer REST-like API bereit. Die API erlaubt in der Regel den lesenden Zugriff auf eine Liste aller an die IoT-Plattform angebundenen Geräte, auf ein einzelnes Gerät und auf die von einem Gerät aufgezeichneten Zeitreihen sensorischer Messwerte. Einzelne Geräte können durch die Angabe einer universell eindeutigen technischen ID (englisch Universally Unique Identifier, kurz UUID) adressiert werden. Der lesende Zugriff auf ein Gerät wird anwendungsseitig gewöhnlich mit der folgenden Anfrage (Request) initiiert:

GET …/devices/{deviceId}

Die geschweiften Klammern symbolisieren einen Platzhalter für die jeweilige UUID. Der Methodenaufruf wird im fehlerfreien Fall mit einer Datenstruktur beantwortet (Response), wie sie nachfolgend exemplarisch dargestellt ist.

{
   "id": "ebc1822f-268e-4bdb-97b0-af1b270a12a9",
   "name": "PLC - CNC Turning Center 3",
   "description": "SIMATIC S7-300",
   "recordedPhysicalQuantities": [
      {
         "tag": "f1",
         "name": "Rotation turning spindle",
         "physicalQuantity": "frequency",
         "unit": "Hz"
      },
      ...
   ]
}

Im vorliegenden Beispiel beinhaltet die Response folgende Properties: UUID, Bezeichnung und Beschreibung des Gerätes sowie ein Array mit den sensorisch erfassten physikalischen Messgrößen. Jedes Element des Arrays besteht aus einem sogenannten Tag als Kürzel, einer Bezeichnung dessen, was gemessen wird, sowie der physikalischen Messgröße und der physikalischen Einheit, in der die Messwerte aufgezeichnet werden. Bei den aufgezeichneten Zeitreihen handelt es sich stets um Listenressourcen, deren Listenelemente die Messwerte beinhalten. Nachfolgend sind die Properties eines einzelnen Listenelements beispielhaft dargestellt. Diese sind ein Zeitstempel, mit dem Zeitpunkt der Messung, ein Tag für die Zuordnung des Messwertes zu einer im Gerät definierten Messgröße und der Messwert selbst.

{
   "timestamp": "2019-10-23T07:07:32.939Z",
   "tag": "f1",
   "value": "83.32"
}

Um die Antwortzeiten zu verringern, sollte sich die in der Response zu übertragende Datenmenge in einem vertretbaren Rahmen bewegen. Zu diesem Zweck kann der betrachtete Vergangenheitszeitraum durch Filterparameter für den Starttermin und den Endtermin eingeschränkt werden, die beim Aufruf der GET-Methode als URL-Parameter übergeben werden:

GET …/devices/{id}/recordedTimeSeries?startDate=2019-10-23T07:00:00.000Z&endDate=2019-10-23T08:00:00.000Z

Ferner wird die Response beim lesenden Zugriff auf Listenressourcen generell durch das Konzept der Paginierung begrenzt. Damit ist die Aufteilung einer Liste in kleinere Listenausschnitte gemeint, die als Seiten (englisch page) bezeichnet werden. Für die Seitengröße, d. h. die Anzahl der pro Seite übertragenen Listenelemente, wird gewöhnlich ein Maximalwert festgelegt. Überschreitet die Anzahl der in der Response enthaltenen Listenelemente die maximale Seitengröße, sind mehrerer iterativer Methodenaufrufe erforderlich.

Ereignismeldungen per MQTT

In der Anwendungsprogrammierschnittstelle ergänzt MQTT die auf Anfragen und Antworten basierende Kommunikation per HTTP. Bei einem Request/Response-Protokoll wie HTTP initiiert die Anwendung die Kommunikation durch einen Request. Mit einem Publish/Subscribe-Netzwerkprotokoll wie MQTT werden Anwendungen dagegen über Ereignisse unterrichtet, sobald diese eintreten. Ein solches Ereignis kann beispielsweise die Änderung eines sensorischen Messwertes sein. Bei einer ausschließlich auf HTTP basierenden API müssten die Anwendungen regelmäßige Anfragen stellen, ob sich ein Messwert geändert hat, um darüber zeitnahe Kenntnis zu erlangen. In der Anwendungsprogrammierschnittstelle einer IoT-Plattform dient MQTT somit nicht als Alternative, sondern als Ergänzung zu HTTP. Die HTTP-API ermöglicht bei Nachfrage den Zugriff auf die in der Vergangenheit aufgezeichneten Zeitreihen sensorischer Messdaten. Die MQTT-API ermöglicht es, dass Anwendungen ohne Zeitverzug über aktuelle Änderungen der Messwerte benachrichtigt werden. Je nachdem, welche Geräte für eine Anwendung von Interesse sind, registriert sich diese für ein oder mehrere Topics. Letztere entsprechen häufig dem relativen Pfad des betreffenden URL:

…/devices/{deviceId}

Die Registrierung kann sich auch auf Nachrichten bezüglich einer konkreten Messgröße beschränken:

…/devices/{deviceId}/{tag}

Nach der Registrierung muss anwendungsseitig keine weitere Anfrage gestellt werden. Stattdessen empfängt die registrierte Anwendung eine kontinuierliche Abfolge einzelner Nachrichten, welche dieselbe Datenstruktur wie die Listenelemente der aufgezeichneten Zeitreihen haben:

{
   "timestamp": "2019-10-23T07:07:32.939Z",
   "tag": "f1",
   "value": "83.32"
}

Neben der Übertragung sensorischer Messwerte wird MQTT auch dazu verwendet, über besondere Ereignisse, wie etwa die Überschreitung von Grenzwerten, zu unterrichten.

MQTT ist als Kommunikationsprotokoll für das Internet der Dinge unter anderem deshalb zu einem De-facto-Standard geworden, weil es in jeder gängigen Programmiersprache unterstützt wird und die Anwendungsprogrammierschnittstelle wie auch das Protokoll selbst schlicht und einfach gestaltet sind. Wie HTTP stellt auch MQTT mit nur wenigen Methoden eine uniforme Schnittstelle zur Anwendungsprogrammierung bereit. Dank der umfassenden Unterstützung von Cloud-Anbietern wie Amazon Web Services (AWS), Google und Microsoft hat sich MQTT mittlerweile auch für die Erfassung von Maschinendaten zu einem führenden IoT-Protokoll entwickelt.

Swagger bzw. OpenAPI Specification

Mit Swagger steht ein offener Industriestandard zur Spezifikation und Dokumentation einer REST-like API zur Verfügung. Ab der Version 3.0 lautet der offizielle Name OpenAPI Specification. Im Swagger User Interface (Swagger UI) wird eine mit Swagger spezifizierte API dokumentiert. Die rechte Abbildung stellt die Swagger UI am Beispiel einer Device API dar. Die Adressen der Ressourcen sind darin nicht vollständig angeführt, sondern nur der hintere Teil des URL, welcher als relativer Pfad bezeichnet wird. Der vordere Adressteil – bestehend aus Domain, Port und Basispfad – variiert in Abhängigkeit von dem Server, auf dem die API installiert ist. Nahezu jede IoT-Plattform mit einer offenen, d. h. im World Wide Web dokumentierten API (Open API) verwendet heute die Swagger Specification. Zu deren Dokumentation werden die interaktive Swagger UI, Swagger2Markup und ReDoc als alternative Open-Source-Tools bereitgestellt.

Zur Spezifikation und Dokumentation ereignisgesteuerter Architekturen wurde basierend auf der OpenAPI Specification die AsyncAPI Specification als weiteres Open-Source-Tool entworfen. Mit ihr können Anwendungsprogrammierschnittstellen auf Grundlage von MQTT aber auch andere nachrichtenbasierte Kommunikationsprotokolle wie beispielsweise Advanced Message Queuing Protocol (AMQP) in gleicher Weise wie in der Swagger-UI dokumentiert werden. Die in den Nachrichten übertragenen Datenmodelle (Schemas) sind mit denen in den Anfragen und Antworten der zugehörigen REST API oft identisch. Sie können in der AsyncAPI Specification direkt aus der OpenAPI Specification übernommen werden. Anstelle der URLs treten Topics und anstelle der HTTP-Methoden treten die Methoden PUBLISH (PUP) und SUBSCRIBE (SUB).

Offenheit der Plattform

Nicht bei allen IoT-Plattformen ist die API im World Wide Web dokumentiert. Markt- und Technologieforschungsunternehmen wie Gartner oder ISG veröffentlichen für die industriell relevanten IoT-Plattformen regelmäßige Marktuntersuchungen und Anbietervergleiche. Bei einigen der darin aufgeführten Plattformen liefert die Google-Suche nach einer dokumentierten API bis heute keine Ergebnisse.

Eine Open API vergrößert die Vielfalt der für eine Plattform angebotenen Anwendungen und steigert damit die Attraktivität der Plattform selbst. Ist eine Anwendungsprogrammierschnittstelle allerdings einmal öffentlich, führen inkompatible Änderungen im Nachhinein zum Vertrauensverlust. Aus diesen Gründen stellen viele Anbieter die API ihrer Plattform zunächst nur einem kleinen Kreis von Entwicklungspartnern zur Verfügung und veröffentlichen diese erst, wenn sie sich in der Praxis bewährt hat. Seit 2015 wurden erste Anwendungsprogrammierschnittstellen der IoT-Plattformen führender Cloud-Anbieter und einiger großen Industriekonzerne im World Wide Web veröffentlicht. Sie alle zeichnen sich durch generisch konzipierte, abstrakte Ressourcen aus, die keine Festlegung auf bestimmte Anwendungsbereiche treffen.

Plattformen mit generisch konzipierter API

Durch die uniforme Schnittstelle einer REST-like API bleiben die individuellen Gestaltungsmöglichkeiten der einzelnen Plattformanbieter auf das Datenmodell, d. h. auf den Ressourcenentwurf beschränkt. Der denkbar einfachste Ressourcenentwurf belässt es bei der schlichten Abbildung der angebundenen Geräte. Dies ist bei der Azure IoT Plattform von Microsoft der Fall, wobei aber jedem Gerät (device) noch ein digitaler Zwilling (twin) zugeordnet wird. Der Unterschied zwischen den beiden Ressourcentypen besteht darin, dass der digitale Zwilling der Geräte um eine generische Datenstruktur zur beliebigen Beschreibung der Geräteeigenschaften erweitert ist.

Die IoT-Plattformen führender Cloud-Anbieter und einiger großen Industriekonzerne charakterisiert eine vollkommen generisch konzipierte API zum Anlegen, Lesen, Ändern und Löschen beliebiger Dinge (things), denen gegebenenfalls ein oder mehrere Geräte (devices) zugeordnet sind. In der Leonardo IoT-Plattform von SAP und der IoT Suite von Bosch werden dazu die folgenden fünf Schnittstellen bereitgestellt:

• GET .../things/ zum Anfordern einer Liste aller Entitäten
• GET .../things/{id} zum Anfordern einer bestimmten Entität
• PUT .../things/{id} zum Ändern einer bestimmten Entität
• DELETE .../things/{id} zum Löschen einer bestimmten Entität
• POST .../things/ zum Erzeugen einer neuen Entität

Andere IoT-Plattformen haben geringfügig abweichende Schnittstellen. In Mindsphere von Siemens wird anstelle von Things der Begriff Assets verwendet. Auch in Predix von General Electric (GE) werden Assets in der API abgebildet, wobei der Begriff jedoch nicht in der URL der Ressourcen auftritt. In der vollkommen generischen API können stattdessen beliebige Listen von Ressourcen (Collections) instanziiert werden, welche den fachlichen Objekten (Domain Objects) des jeweiligen Gegenstandsbereichs entsprechen:

• GET /v1 zum Anfordern einer Liste aller Collections
• POST /v1/{collection} zum Erzeugen eines konkreten Objektes innerhalb einer Collection
• GET v1/{collection}/{id} zum Anfordern eines konkreten Objektes innerhalb einer Collection

In der Watson IoT Plattform von IBM und der AWS IoT Plattform, die einem Tochterunternehmen von Amazon gehört, werden Things durch die Zuordnung zu verschiedenen Thing Types kategorisiert:

• GET /thing/types/{thingTypeId}/things/{thingId}
• PUT /thing/types/{thingTypeId}/things/{thingId}
• DELETE /thing/types/{thingTypeId}/things/{thingId}
• POST /thing/types/{thingTypeId}/things

Thing Types können ihrerseits wiederum generisch angelegt und gelöscht werden, sodass auch hierdurch keine konkreten Anwendungsbereiche vorgegeben oder ausgeschlossen sind.

Jede IoT-Anwendung, die gegen eine generisch konzipierte API entwickelt wurde, kann – solange sie keine plattformspezifischen Cloud-Services nutzt – ohne größere Aufwände von der einen auf die andere IoT-Plattform migriert werden.

IIoT-Plattformen

Für die industrielle Anwendung des Internets der Dinge wird häufig der Begriff Industrial Internet of Things (IIoT) verwendet und daran anknüpfend bisweilen von IIoT-Plattformen gesprochen. IIoT beinhaltet einen begrifflichen Verweis auf das Industrial Internet, dem US-amerikanische Pendant zur deutschen Industrie 4.0. Jenes wird vom Industrial Internet Consortium koordiniert und gefördert, dem nicht nur internationale Unternehmen, sondern auch Forschungsinstitute und öffentliche Einrichtungen angehören.

Die Anwendungsszenarien für IIoT-Plattformen beziehen sich vor allem auf den Bereich der industriellen Produktion. GE bezeichnet die eigene Plattform Predix explizit als Plattform für das Industrial Internet. Gleichwohl sehen die Anbieter aller IoT-Plattformen mit einer generischen API Anwendungsfälle im industriellen Umfeld, das in den kommenden Jahren die größten Markt- und Umsatzpotentiale für IoT-Plattformen verspricht. Weil jede generische API grundsätzlich anwendungsoffen ist, bestimmen die vom IoT Hub unterstützen Steuerungs- und Kommunikationsprotokolle maßgeblich, in welchem Umfang entsprechende IoT-Plattformen im industriellen und produzierenden Umfeld zum Einsatz gelangen können. Die meisten Produktionsbetriebe verfügen über einen heterogenen Maschinenpark, dessen Anlagen und Maschinen mit Steuerungen diverser Hersteller und unterschiedlicher Baujahre ausgestattet sind. In der Vergangenheit wurde das Auslesen dieser verschiedenartigen Maschinen- und Anlagensteuerungen im Rahmen der Maschinen- und Prozessdatenerfassung vorgenommen, die später zum integralen Bestandteil jedes Manufacturing Execution Systems (MES) wurde.

Plattformen für Gebäude- und Heimautomation (Smart Home)

Im Gegensatz zum Industrial Internet of Things ist der IoT-Markt im Bereich der Gebäudeautomation (englisch Home Automation) keineswegs ausschließlich als Business-to-Business (B2B), sondern gerade im Bereich des smarten Wohnen (englisch Smart Home) vorwiegend als Business-to-Consumer (B2C) zu klassifizieren. Das ist unter anderem daran zu erkennen, dass es hier eine größere Anzahl von Anbietern gibt und keine IoT-Plattform ohne eine offen dokumentierte API oder ein SDK existiert. Eine umfassende Übersicht findet sich bei ProgrammableWeb, wo verschiedene IoT-Plattformen für Home Automation und 69 Anwendungs­programmier­schnittstellen einschließlich einer Referenz auf deren Online-Dokumentation vorgestellt werden.