IoT-Plattform

IoT-Plattformen stellen die heute gängige technische Umsetzung des mit dem Internet der Dinge (englisch Internet of Things, Kurzform: IoT) verfolgten Zieles dar, physische und virtuelle Gegenstände miteinander zu vernetzen und sie durch Informations- und Kommunikationstechniken zusammenarbeiten zu lassen. Einhergehend mit einer wachsenden Anzahl technisch konvergenter IoT-Implementierungen bildeten sich in den 2010er Jahren De-facto-Standards heraus, die ihrerseits die Vermarktung von IoT-Plattformen zunehmend erleichtert haben. Begünstigt wird diese Entwicklung weiterhin dadurch, dass fortschreitend mehr Geräte mit Sensoren, einem eingebetteten Computersystem und einem Kommunikationsprozessor zur Verbindung mit einem Rechnernetz ausgestattet werden. Das Spektrum solcher sogenannten Smart Devices reicht von Haushaltsgeräten über Transport- und Logistiksysteme bis hin zu Industrieanlagen. Mittlerweile bedeutet die Vernetzung jener Geräte in der Praxis deren Anbindung an eine IoT-Plattform. Die Plattform erfüllt dabei die Funktion eines Betriebssystems, welches Anwendungsprogrammen ermöglicht, auf Basis standardisierter Internettechnologien aus den verschiedenartigen Geräten Daten auszulesen und Steuersignale an die Geräte zu senden. IoT-Plattformen schaffen so eine wesentliche Voraussetzung dafür, dass die angebundenen Geräte durch innovative Anwendungen dem Menschen einen größeren Nutzen bringen, als sie es an sich vermögen.

Abgrenzung gegenüber Plattformmärkten

Als ökonomisches Phänomen wird unter einer Plattform jede Institution verstanden, ohne deren Inanspruchnahme die Wettbewerbsfähigkeit vermindert oder eine Marktteilnahme gar unmöglich wird. Eine Plattformökonomie ist durch ökonomisch verwertbare Eigentumsrechte an einer solchen oder privilegierte Gestaltungsmöglichkeiten in Hinblick auf eine solche Institution gekennzeichnet. Plattformen sind in der Wirtschaft kein neues Phänomen. Im Zuge der fortschreitenden Digitalisierung wurden Plattform-Unternehmen jedoch zur dominanten Erscheinungsform der Plattformökonomie.

Im Gegensatz dazu ist der Begriff der Plattform hier in einem informationstechnologischen Sinne zu verstehen, d. h. als eine einheitliche Grundlage, auf der Anwendungsprogramme ausgeführt und entwickelt werden können. Derzeit sind die Marktpotentiale der IoT-Plattformen noch weitestgehend unerschlossen. Inwieweit sich daraus zukünftige Plattformmärkte entwickeln werden, hängt von zahlreichen Einflussfaktoren ab. Maßgeblich ist unter anderem, in welchem Ausmaß erfolgreiche Marktleistungen an spezifische Cloud-Infrastrukturen anknüpfen oder in die Ökosysteme führender Plattformbetreiber eingebunden werden. Unter rein technischen Gesichtspunkten können IoT-Plattformen sowohl in einer Cloud als auch lokal auf eigenen Servern (On Premises) betrieben werden. Beim Edge Computing ist die IoT-Plattform vor Ort installiert, was jedoch nicht ausschließt, einzelne Anwendungen und Dienste verschiedener Cloud-Betreiber in Anspruch zu nehmen.

Schichtenarchitektur einer IoT-Plattform

Alle IoT-Plattformen kennzeichnet die nachfolgend abgebildete Schichtenarchitektur mit einem IoT Hub zur Anbindung von Geräten und einer Anwendungsprogrammierschnittstelle (englisch Application Programming Interface, Kurzform: API) zur Entwicklung und Ausführung von Anwendungen.

Schichtenarchitektur einer IoT-Plattform

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.

IoT-Standards

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

Device API in der Swagger UI

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).

Individuelle Ausprägungen

Verschiedene IoT-Plattformen unterscheiden sich im Wesentlichen durch das Spektrum der im IoT Hub unterstützten Geräte, die Gestaltung der digitalen Abbilder von Dingen in der API und deren Offenheit.

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

Digitales Abbild von Dingen in einer generisch konzipierten 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 die diskrete Fertigung

Lange Zeit überwog die Ansicht, dass IoT-Plattformen das MES ergänzen, nicht jedoch ersetzen werden. Denn die Anwendungen der den Markt dominierenden IoT-Plattformen decken nicht den Funktionsumfang eines MES ab. Vollkommen generische Datenmodelle erlauben in der Theorie zwar ein unbegrenztes Spektrum an Anwendungen, gewährleisten aber nicht deren semantische Interoperabilität untereinander und mit den im produzierenden Umfeld üblichen Drittsystemen. Anwendungen aus dem Bereich des maschinellen Lernens bedürfen keinerlei Semantik, weil sie eigenständig dazu imstande sind, wiederauftretende Muster als semantisch bewertbare Entitäten in den aufgezeichneten Zeitreihen zu identifizieren. So können etwa die vor einer technischen Störung wiederkehrend auftretenden Muster innerhalb der aufgezeichneten Prozessparameter zur Prognose von drohenden Stillständen herangezogen werden, ohne die physikalische Bedeutung der betreffenden Prozessparameter zu kennen. Die vorausschauende Instandhaltung (englisch Predictive Maintenance) von Anlagen und Maschinen auf der Grundlage derart prognostizierter Stillstände ist darum das Anwendungsszenario für IIoT-Plattformen, welches am häufigsten angeführt wird. Anders verhält es sich aber bei Aufgabenstellungen, die einer algorithmischen Lösung unter Berücksichtigung zahlreicher fachlich begründeter Rahmenbedingungen bedürfen. Anwendungsentwickler müssen Daten semantisch bewerten können, um sie algorithmisch, d. h. in einem logischen Zusammenhang miteinander zu verknüpfen. Für die Feinplanung der Fertigungsaufträge und die Steuerung der Produktion sind dabei sowohl die Vorgabewerte aus dem ERP-System als auch die Daten der Erfassungssysteme von Relevanz. Um eine einheitliche, semantisch bewertbare Datengrundlage auf der Anwendungsebene bereitzustellen, bedarf es verbindlicher Datenmodelle, die in der Anwendungsprogrammierschnittstelle vorgegeben werden. Konkrete Datenmodelle sind zwar notwendigerweise einem spezifischen Anwendungsbereich (domain specific) zuzuordnen; eine ressourcenorientierte Architektur erlaubt aber dennoch, eine API innerhalb ihres Anwendungsbereichs weitestgehend anwendungsoffen zu gestalten, sodass genügend Spielraum für die Entwicklung von innovativen und neuartigen Anwendungen bleibt.

Digitales Abbild der Produktion in der API

Um das Anwendungsspektrum von IIoT-Plattformen im produzierenden Umfeld zu erweitern, wurde 2018 FORCE Bridge API als Open API für Smart Manufacturing veröffentlicht. Die Veröffentlichung der Swagger Specification erfolgte unter der Creative Commons Attribution-NoDerivs 3.0 Unported License, sodass einzelne oder alle Schnittstellen der API in jeder IoT-Plattform implementiert werden können. Die API ersetzt die abstrakten Things bzw. die generischen Collections in Predix durch konkrete Objekte der Produktion. Dazu gehören die Arbeitsplätze (englisch Workplaces), welche Maschinen oder Handarbeitsplätze sein können, Werkzeuge (englisch Tools) und das Fertigungspersonal (eng. Staff Members). Fertigungsmappen (Folders) beinhalten die zur Herstellung eines bestimmten Produktes erforderlichen Dokumente (englisch Documents), wie beispielsweise NC-Programme oder Montageanleitungen. In der API werden ferner auch virtuelle Gegenstände wie Fertigungsaufträge (englisch Production Orders) einschließlich ihrer einzelnen Arbeitsvorgänge (englisch Operations) abgebildet. Microsoft stellt Hochschulen und Bildungseinrichtungen eine virtuelle Fabrik mit der API unter vergünstigten Konditionen in der Azure Cloud zur Verfügung. Darin sind Teile der FORCE Bridge API implementiert, jedoch fehlen die zur Fertigungssteuerung erforderlichen Schnittstellen.

Plattformen für die Öl- und Gasindustrie

In der Öl- und Gasindustrie wird nicht nur ein wachsender Absatzmarkt für IIoT-Plattformen gesehen, deren Einsatz stellt auch in Aussicht, die Umweltauswirkungen durch eine Steigerung der Effizienz sowie die Verringerung von CO₂-Emissionen und Sicherheitsrisiken zu reduzieren. Vor allem Cloud-Anbieter mit integrierten Services aus dem Bereich des maschinellen Lernens und der Künstlichen Intelligenz (KI) – obgleich die meisten davon nicht aus der industriellen Branche kommen – sehen in der Öl- und Gasindustrie ein Einsatzgebiet ihrer IoT-Plattformen. So sollen Kognitive Systeme alle Daten des Bohrsensors in Echtzeit überwachen und mit früheren Bohrberichten sowie geologischen Daten vergleichen, um drohende Störungen und Ausfälle im Vorfeld zu erkennen.

Speziell für die Öl- und Gasindustrie entwickelte IoT-Plattformen zeichnen sich durch die breite Unterstützung der verschiedenartigen Sensoren und Steuerungen von Bohranlagen und Leitungssystemen aus, die sie im IoT Hub anbinden und in der API einheitlich abbilden. Die IoT-Plattform des 2016 gegründeten Unternehmens Cognite verfügt über eine Open API und stellt zudem ein Software Development Kit (SDK) für JavaScript und Python zur Verfügung. Die generisch konzipierte API ist vergleichsweise schlank und übersichtlich dokumentiert. Für die Nutzer der Plattform ergibt sich aus der Open API der Vorteil, herstellerunabhängig bei der Auswahl der verschiedenen Anbieter von KI-Services zu bleiben und gegebenenfalls auch eigene Anwendungen entwickeln zu können.

Plattformen für die Elektronikindustrie

Die Oberflächenmontage (englisch surface-mounting technology, kurz: SMT) von SMD-Bauelementen auf Leiterplatten ist in hohem Maße automatisiert. Eine SMT-Linie besteht aus mehreren Stationen, die in der Regel von unterschiedlichen Herstellern bezogen werden. Hierzu gehören ein Lotpastendrucker, SMD-Bestückungsautomat, SMD-Ofen sowie mehrere Inspektions- und Reparaturstationen. Um die Leiterplatten selbst und die dazugehörenden Produktdaten sowie Informationen zu Maschineneinstellungen und Prozessrückmeldungen zwischen den verbundenen Stationen zu übergeben (horizontale Integration), existieren schon seit einigen Jahren Standards wie die SEMI SMT Equipment Link Standards (SEMI SMT-ELS), der IPC-SMEMA-9851-Standard und der neuere IPC-HERMES-9852-Standard. Die Kommunikation zwischen den einzelnen Stationen einer SMT-Linie erfolgt bei all diesen Standards synchron unter Verwendung des Transmission Control Protocol (TCP).

Zur Anbindung von SMT und THT-Linien an eine IoT-Plattform (vertikale Integration) wurde 2019 Connected Factory Exchange (CFX) von dem IPC offiziell veröffentlicht. Auf der Grundlage von AMQP erlaubt IPC CFX neben dem asynchronen Austausch von Nachrichten auch eine auf Anfragen und Antworten basierende Kommunikation. Bereits seit November 2017 steht mit der CFX Messaging Library ein für Microsofts .Net-Framework entwickeltes SDK als Open Source zur Verfügung. Prinzipiell kann IPC CFX nicht nur zur Anbindung von Linien in der Elektronikfertigung an eine IoT-Plattform, sondern auch selbst als Anwendungsprogrammierschnittstelle verwendet werden. Die auf diese Weise für die Elektronikfertigung entwickelten Anwendungen könnten dann aber auf einer den üblichen IoT-Standards entsprechenden Plattform nicht ausgeführt werden. Dies ist für Anwendungen praktikabel, die speziell für Linien der Elektronikfertigung konzipiert sind. Der IPC-CFX Standard entwickelt sich aber rasant weiter. So wurde im August 2022 die Version 1.5 veröffentlicht.

Während der Einsatz von IoT-Plattformen in den meisten industriellen Bereichen auf die vorausschauende Wartung von Anlagen und Maschinen abzielt, steht in der Elektronikindustrie auch die vorausschauende und proaktive Qualitätssicherung im Fokus. Durch die automatische optische Inspektion (AOI) an verschiedenen Stationen einer SMT-Linie, werden mangelhaft verarbeitete Teile sofort erkannt und dem nachfolgenden Arbeitsschritt erst gar nicht zugeführt (Prozessverriegelung). Stattdessen werden sie entweder auf einer Reparaturstation korrigiert und daraufhin erneut der Inspektionsstation zugeteilt oder – falls eine Korrektur nicht möglich ist – als Ausschussteile von der Linie genommen. Methoden des maschinellen Lernens erlauben, die bei der AOI anfallenden Massendaten mit weiteren Prozessparametern zu verknüpfen und auf wiederkehrende Abweichungsmuster zu analysieren, die bereits im Vorfeld auf drohende Qualitätsmängel hinweisen. Ziel ist es, den Anteil der Platinen, die bereits nach dem ersten Fertigungsdurchlauf ohne Reparaturschritte fehlerfrei sind, den sogenannten First Pass Yield (FPY), auf 100 Prozent zu steigern.

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.

Vor- und Nachteile

Der wesentliche Vorteil von IoT-Plattformen besteht darin, dass sie De-facto-Standards geschaffen haben, die es einem breiten Kreis von Softwareentwicklern ermöglichen, Anwendungen für das Internet der Dinge zu entwickeln. Das implizite Architekturkonzept, Erfassungssysteme und die darauf operierenden Anwendungen durch eine API voneinander zu trennen, führt gewöhnlich zu einer Verringerung von Seiteneffekten und Fehleranfälligkeit und verbessert die Wartbarkeit des Quellcodes gegenüber monolithischen Systemen. Die Nutzer von IoT-Plattformen mit einer Open API haben den Vorteil, jede einzelne Anwendung herstellerunabhängig entsprechend den individuellen Anforderungen auswählen zu können. Je offener eine IoT-Plattform ist, umso geringer sind die mit deren Einführung verbundenen Transaktionskosten und Investitionsrisiken. Weil auch Drittanbieter auf eine Open API zugreifen können, begünstigen offene IoT-Plattformen ein breiteres Anbieterspektrum und die Entwicklung innovativer neuer Anwendungen.

Als Nachteil von IoT-Plattformen ist anzuführen, dass diese im Vergleich zu monolithischen Systemen potentiell mehr Sicherheitslücken haben können. Ob offene Anwendungs­programmier­schnittstellen per se ein höheres Risiko implizieren, ist eine viel diskutierte Frage. Einerseits sind sie leichter anzugreifen, andererseits sind die Sicherheitsrisiken allseits bekannt, sodass potentielle Sicherheitslücken schneller geschlossen werden können. Ein entscheidendes Kriterium ist dabei, ob die Plattform in einem nach außen abgeschlossenen privaten Netzwerk oder in der Cloud betrieben wird (vgl. rechtliche Fragen beim Cloud Computing). Dessen ungeachtet birgt jede mobile Anwendung die Gefahr, unerkannt über das Funknetz Daten an unberechtigte Dritte weiterzuleiten. Die ungewünschte Weiterleitung von Daten kann auch nach dem Transport des mobilen Endgerätes und anschließender Verbindung mit einem anderen an das Internet angebundenen Netzwerk erfolgen. Handelt es sich dabei lediglich um Prozessdaten, ist der zu erwartende Schaden geringer als im Falle von geheimen Entwicklungsdokumenten oder personenbezogenen Daten. Daher verlangen verschiedene Schnittstellen unterschiedliche Zugriffsrechte mit mehr oder weniger strengen Restriktionen.

Siehe auch

• Internet der Dinge
• Swagger

Weblinks

• Swagger Tools
• ReDoc
• Swagger2Markup
• AsyncAPI

Einzelnachweise

1. M. S. Schmid: Der Wettbewerb zwischen Business Webs Strategien konkurrierender Unternehmensnetzwerke im IPTV-Markt. Springer Gabler, 2010
2. A. Baums: Digitale Plattformen – DNA der Industrie 4.0, gesichtet am 27. Oktober 2019.
3. M. Friedemann, T.U. Trapp, J. Stoldt, T. Langer, M. Putz: A framework for information-driven manufacturing. Procedia CIRP 57 (2016), S. 38–43, gesichtet am 28. Oktober 2019.
4. Darrel Miller auf GitHub: Supporting multiple transfer protocols with OpenAPI #777. Comment from 03 Dec 2016
5. R. T. Fielding: Architectural Styles and the Design of Networkbased Software Architectures. Diss. (2000)
6. Design News: Edge Devices Leverage MQTT for IIoT, 4. September 2019, gesichtet am 31. Oktober 2019.
7. SMARTBEAR: The State of API 2019 Report, gesichtet am 31. Oktober 2019.
8. The OpenAPI Initiative (OAI). Website.
9. Async API. Website.
10. Gartner Inc.: Industrial IoT Platforms Market, gesichtet am 30. Oktober 2019.
11. Information Services Group (ISG) : Neue ISG-Anbieterstudie zum „Internet of Things“ (IoT), gesichtet am 30. Oktober 2019.
12. Microsoft Azure IoT API Reference: Get Twin, gesichtet am 30. Oktober 2019.
13. SAP Leonardo API Reference: Things, gesichtet am 30. Oktober 2019.
14. Bosch IoT Suite API Reference: Bosch IoT Things HTTP API V2, gesichtet am 31. Oktober 2019.
15. Siemens Mindsphere API Reference: Asset Management Service V 3.12.0, gesichtet am 31. Oktober 2019.
16. GE Predix: API Documentation - Asset, gesichtet am 31. Oktober 2019.
17. AWS IoT API Reference: List Thing Types, gesichtet am 31. Oktober 2019.
18. Watson IoT API Reference: IBM Watson IoT Platform HTTP REST API, gesichtet am 31. Oktober 2019.
19. Industrial Internet Consortium - Website, gesichtet am 30. Oktober 2019.
20. S. Luber, N. Litzel: Was ist das Industrial Internet of Things (IIoT)?, Bigdata Insider, 20. Oktober 2017, gesichtet am 30. Oktober 2019.
21. GE: Predix - Ihre Plattform für das Industrial Internet (PDF), gesichtet am 30. Oktober 2019.
22. N. Hunke, Z. Yusuf, M. Rüßmann, F. Schmieg, A. Bhatia and N. Kalra: Winning in IoT: It’s All About the Business Processes, gesichtet am 31. Oktober 2019.
23. C. Gupta: What Does IIoT Mean for MES?, Automation World, 8. Januar 2018, gesichtet am 31. Oktober 2019.
24. G. Giles: What’s Really New About IIoT?, Automation World, 6. Februar 2017, gesichtet am 31. Oktober 2019.
25. FORCE Bridge API: Swagger Specification als ReDoc, gesichtet am 31. Oktober 2019. Eine mit dem Swagger Codegen fehlerfrei generierbare und vollständige Swagger Specification der FORCE Bridge API (Version 2) findet sich hier unter Online Plus auf der Springer Website.
26. Webseite der virtuellen Lernfabrik, gesichtet am 31. Oktober 2019.
27. API Reference der virtuellen Lernfabrik: Swagger Specification, gesichtet am 31. Oktober 2019.
28. Prakash Chakravarthi: 5 Ways IIoT Will Revolutionize the Oil and Gas Industry, IoT for all, 30. Juli 2018, abgerufen am 2. November 2019.
29. IBM Whitepaper: Exploring the power of cognitive IoT (PDF), 2016, abgerufen am 2. November 2019.
30. Cognite API (v1): Swagger Specification als ReDoc, abgerufen am 2. November 2019.
31. SEMI: SEMI SMT-ELS: SMT Equipment Link Standards, abgerufen am 16. November 2019.
32. IPC: The Hermes Standard IPC-HERMES-9852, abgerufen am 16. November 2019. Download unter https://www.the-hermes-standard.info/download/.
33. IPC: Der IPC veröffentlicht die Richtlinie IPC-2591, Connected Factory Exchange (CFX), abgerufen am 16. November 2019.
34. IPC: IPC-2591, abgerufen am 16. November 2019.
35. IPC: Das neue Software-Toolkit CFX Messaging Library beschleunigt die Implementierung von Connected Factory Exchange, abgerufen am 16. November 2019.
36. Github: IPC Connected Factory Exchange (CFX) auf Github, abgerufen am 16. November 2019. Dokumentation auf Getting Started with the SDK
37. IPC-CFX FAQ:[1], abgerufen am 30. Oktober 2022.
38. https://shop.ipc.org/general-electronics/standards/2591-5-0v1-5-english
39. Website von ProgrammableWeb: Category: Home Automation, abgerufen am 3. November 2019.
40. A. Sinsel, C. Bangert, J. Stoldt, T. Büttner: Wirtschaftlichkeitsbewertung der Smart Factory. ZWF 112 (2017) 9, S. 602–606.
41. IIoT World: An overview of the IoT Security Market Report 2017-2022, abgerufen am 2. November 2019.
42. G. Levin: TOP 7 REST API Security Threats. REST CASE, 9. Januar 2019, abgerufen am 2. November 2019.
43. G. Levin: State of API Security. REST CASE, 25. Oktober 2019, abgerufen am 2. November 2019.