Ein solcher offener Cloud-API-Ansatz kann aber nur so stark sein wie das Ökosystem, das ihn unterstützt. Alle wichtigen Anbieter von Embedded-Computer-Technologie sowie von Peripheriebaugruppen und Clouds müssten idealerweise ein solches Cloud-API unterstützen, damit Systemlösungen wirklich per Plug-and-play zusammengestellt werden können. Dnn für jede Hardware bedarf es einer entsprechenden Sensor-Engine und für jede Cloud die passende Cloud-Engine. Je nach erforderlicher Entscheidungslogik im Gateway sind nur noch spezifische Ausführungen der Rule-Engine erforderlich. So lässt sich der Entwicklungsaufwand für die Anbindung an Clouds auf ein Minimum reduzieren. In Standardinstallationen wird es so möglich, mit zertifizierten applikationsfertigen Modulen zu arbeiten, ohne auch nur eine Zeile zusätzlichen Programmcode schreiben zu müssen. Plug & Play sowie Parametrierung statt Programmierung sind also die Devisen.
Sind alle Standardmodule korrekt in¬stalliert, werden die Daten direkt nach ihrer Erfassung von der mitgelieferten Sensor-Engine ausgelesen, übersetzt und im IoT-Gateway für die Sprache der Cloud aufbereitet. Im Ergebnis kann der Anwender die aufbereiteten Informa¬tionen auf einer automatisch erstellten Web-App ablesen, anstatt für jeden einzelnen Sensor den gesamten Prozess einzeln deklinieren und individuell entwickeln zu müssen. Alle gewünschten Daten gelangen so künftig automatisch in die Cloud und zum Anwender.
Die Standardisierung bietet aber noch weitere Vorteile: Mit standardisierten Funktionsbausteinen sind die Kunden nicht mehr auf einen Lieferanten festgelegt. Zudem reduziert die Standardisierung solcher APIs den Portierungsaufwand. So brauchen Entwickler ihre IoT-Applikation nur einmal zu entwickeln und können sie anschließend auf beliebige Sensoren, Gateways und Cloud-Kombinationen für neue Applikationen portieren. Eine solche Portierbarkeit ist höchst komfortabel, denn eine Cloud-Lösung, die vor Ort beispielsweise Feldbusse anbindet und dann über WLAN an eine Microsoft Azure Cloud kommuniziert, sieht anders aus als eine, die vor Ort via WLAN oder LoRa Daten sammelt und sie dann via 3G/4G an eine Telekom-Cloud übermittelt. Unterstützen die individuellen Gateways ein standardisiertes Cloud-API, brauchen Entwickler nur die Cloud-Engine auszuwechseln, alles andere kann bleiben, wie es ist. So lassen sich auch sehr individuelle Anforderungen mit applikationsfertigen Standardbausteinen effizient umsetzen.
Dazu eine kurze Beispielrechnung: Eine IoT-Lösung mit vier alternativen Sensornetzen und drei möglichen Clouds für unterschiedliche Applikationen erforderte bisher zwölf durchgängig unterschiedliche Implementierungen auf dem IoT-Gateway (3×4). Ein standardisiertes Cloud-API reduziert den Integationsaufwand drastisch auf die Anpassung oder Implementierung von lediglich sieben Engines (drei Cloud-Engines plus vier Sensor-En¬gines). Sollten bereits einzelne dieser Engines vorhanden sein, so sinkt der Aufwand noch weiter. All das sind zudem Optionen, die die Langzeitverfügbarkeit von Lösungen unterstützen.
Da eine solche offene Standardisierung extrem viele Vorteile für OEMs und IoT-Applikationsanbieter mit sich bringt, gründete bereits vor zwei Jahren das Standardisierungsgremium SGET (Standardization Group for Embedded Technologies, www.sget.org) hierzu eine Arbeitsgruppe. Das vorläufige Ergebnis: Sie konnte auf der diesjährigen Embedded World bereits ein erstes Demosystem dieser Art vorstellen. Derzeit arbeitet die Gruppe daran, die Version 1.0 des neuen Cloud-API-Standards für Embedded-Systeme und Erweiterungsbaugruppen zu finalisieren. Das Ziel ist, den Standard offiziell Anfang 2018 zu verabschieden. Bis dahin sind weitere Hersteller aufgerufen, sich zu beteiligen – denn je breiter die Unterstützungsbasis, desto größer ist die Chance, diesen Standard langfristig zu etablieren. Eine immense Schwungkraft würde das standardisierte Cloud-API erhalten, wenn neben den Herstellern von Embedded-Computer-Technologie der SGET auch Hersteller von Peripheriebaugruppen sowie führende Cloud-Anbieter diesen offenen Standard.unterstützen würden. Eine wichtige Aufgabe der SGET innerhalb des Standardisierungsprozesses ist es deshalb, auch diese Stakeholder für den Support des Standards zu gewinnen.
Die Autoren
Dipl. Ing. (FH) Carsten Rebmann
arbeitet seit 2004 als Entwickler, Projekt-Manager, Product-Sales-Marketing-Manager, technischer Berater und Director R&D in der Embedded-Computing-Industrie. Er ist Gründungsmitglied der SGET und seitdem Vorstandsmitglied. Er war aktiv beteiligt an Standardisierungen der PICMG für COM Express sowie der SGET für Qseven und eNUC und ist Vorsitzender der SDT.04.
Carsten.Rebmann@congatec.com
Dipl.-Ing. Jens Uhlig
hat Technische Informatik studiert und erwarb sich zu Beginn seiner Karriere tiefes Wissen in Bereich M2M bei Siemens Wireless Module. Danach folgten diverse Projekte im Bereich Web 2.0 und System-Integration. In den letzten Jahren lag der Fokus auf innovativen System- und Lösungsarchitekturen im Bereich Internet der Dinge und der digitalen Transformation mit einem starkem Bezug auf Domain Driven Design, Event Driven und Mirco Service Architecture.
Kevin-Louis Pawelke
ist diplomierter Wirtschaftssoziologe der FU Berlin. Während der beruflichen Laufbahn in der IT erwarb er verschiedene Skills in den Gebieten Business Development und Sales, Projektmanagement, Beratung und Interimsmanagement. Die Arbeitgeber und Projekte der letzten 15 Jahre waren unterschiedlich groß und gehörten den Branchen Aerospace, Automotive und Logistik an.