Experience Embedded

Professionelle Schulungen, Beratung und Projektunterstützung

Projekt-Prototyping mit IoT-Entwicklerbaukasten

Autor: Klaus-Dieter Walter, SSV Software Systems GmbH

Beitrag - Embedded Software Engineering Kongress 2015 

 

Was genau kennzeichnet eigentlich ein IoT-Entwicklungsvorhaben, und wo liegen die funktionalen Schwerpunkte? Welche Ressourcen benötigt eine Embedded-Systems-Hardware in einer IoT-Anwendung? Wie wird diese Hardware mit der Cloud verbunden, und welche Protokolle bzw. APIs kommen dabei zum Einsatz? Hier einige grundlegende Betrachtungen zu den erforderlichen Bausteinen, die sich zu einem IoT-Entwicklerbaukasten zusammenfügen lassen, um die Risiken und Entwicklungszeiten zu reduzieren.

Durch das Internet der Dinge (Internet of Things = IoT) und die beständig wachsenden Ansprüche an die Funktionalität und Security werden viele neu zu entwickelnden Embedded-Systems-Anwendungen deutlich komplexer als jemals zuvor. Den Entwicklungsteams stehen aber trotz erheblich gestiegener Anforderungen nicht mehr Ressourcen und längere Produkt- und Lösungsentwicklungsphasen zur Verfügung. Das Gegenteil ist in der Praxis der Fall – die Produkte sollen auf Grund anspruchsvoller Konkurrenzsituationen und globaler Märkte immer schneller fertig werden. Dieser Beitrag liefert einen Überblick zu den Architekturen, Konzepten und Bausteinen.

Das Internet der Dinge steckt noch in den Kinderschuhen. Die einzelnen Bausteine und Komponenten existieren zwar schon, über Architektur und Baupläne wird allerdings noch sehr heftig diskutiert. Besonders störend und auch nicht wirklich hilfreich ist, dass viele Diskussionen von den Marketingabteilungen größerer US-IT-Firmen und einiger Silicon-Valley-Startups, hinter denen teilweise sehr finanzstarke Venture-Kapitalgeber stehen, gesteuert werden. Dadurch rücken die tatsächlich zu lösenden Probleme teilweise in den Hintergrund. Stattdessen werden die IoT-Pionierlösungen der jeweiligen Firmen in den Mittelpunkt gestellt, um dem Rest der Welt klar zu machen, woran man sich in Zukunft zu orientieren hat. Diese Vorgehensweise spiegelt sich auch in den Standardisierungs- und Normierungsgremien wider. Die Anzahl und Relevanz der Arbeitsgruppen, die für sich in Anspruch nehmen, einen wirklich wichtigen IoT-Standard zu schaffen, lässt sich im Moment nur schwer überblicken.

Für ein IoT-Entwicklungsvorhaben wird auf jeden Fall ein möglichst universelles Leitbild benötigt, um eine geeignete Architektur zu entwerfen, die später eine erfolgreiche Produkt- bzw. Lösungsvermarktung und eine lange Produktlebensdauer ermöglicht. Eine in sich geschlossene Silo-Lösung mit vertikaler Orientierung, hoher Kundenbindung und ohne horizontale Serviceschnittstellen ist auf jeden Fall zu vermeiden. Sie wäre für das Internet der Dinge völlig ungeeignet und mittel- bis langfristig auch nicht mehr wettbewerbsfähig.

Tabelle 1 (siehe PDF): Für die Ressourcenplanung des Embedded Systems ist die Art und Weise der Verbindung zwischen physischer und virtueller Repräsenzanz von entscheidender Bedeutung. Eine direkte Internetverbindung per Mobilfunkmodem oder externem Router erofrdert eine deutlich leistungsfähigere Hard- und Software als eine indirekte Verbindung mit Hilfe eienr Smartphone-App.

Anbieterneutrale Orientierungshilfen findet man zum Beispiel über das Internet-of-Things-Architecture-Förderprojekt der Europäischen Union. Über dieses EU-Flagship-Projekt aus dem FP7-Forschungsprogramm sollte ein möglichst universelles Referenzmodell für zukünftige IoT-Anwendungen entwickelt werden. Embedded Systeme mit ihren Sensoren und Aktoren – also die Things des Internet of Things – bilden in diesem Modell die physischen Repräsentanzen. Zu jeder physischen Repräsentanz gehört wiederum eine virtuelle Repräsentanz, die zum Beispiel durch einen Cloud- bzw. IoT-Service im Internet realisiert werden kann. Auf einer solchen IoT-Serviceplattform wird der aktuelle Zustand der Sensoren und Aktoren des Embedded Systems gespeichert und bei Bedarf (zum Beispiel bei jeder Zustandsänderung) erneuert. Auf das jeweils aktuelle Datenabbild können andere Systeme und Benutzer mittels eines Application Programming Interface (zum Beispiel ein REST-API) zugreifen. Ein solches Cloud- bzw. IoT-Service-API muss in der Regel unterschiedliche Protokolle und plattformunabhängige Datenformate unterstützen und darüber hinaus geeignete Sicherheitsmechanismen anbieten.

Als einfaches aber repräsentatives Beispiel für das Zusammenspiel zwischen physischer und virtueller Repräsentanz kann ein Fitness-Armband dienen, wie es inzwischen unzählige Menschen für das Self-Tracking nutzen. Die Blockschaltung einer sehr simplen Variante zeigt Abbildung 2 (siehe PDF). Als einziger Sensor dient in diesem Fall ein 3-Achsen-Gyroskop. Dieser MEMS-Sensor ist mit einem Bluetooth-SoC aus der TI-CC2540-Familie verbunden. Zum Fitness-Armband gehört eine App für Apple- und Android-Smartphones.

Abbildung 1 (siehe PDF): In einem IoT-Projekt sollten Embedded Systeme mit ihren Sensoren und Aktoren als physische Repräsentanzen ein jeweils aktuelles Datanabbild an eine virtuelle Repräsentanz liefern. Diese wird in der Regel über eine Cloud- bzw. IoT-Serviceplattform realisiert. Für den Zugriff durch Benutzer und andere Systeme stellt eine solche Plattform offene Serviceschnittstellen zur Verfügung.

Abbildung 2 (siehe PDF): Blockschaltung eines typischen Fitness-Armbands. Ein solcher Wearable bildet die typische physische Repräsentanz in unzähligen IoT-Self-Tracking-Anwendungen. Über ein 3-Achsen-Gyroskop werden die Schritte des Trägers gezählt und per Bluetooth an ein Smartphone weitergegeben. Dieses leitet die Schrittzählerdaten an die virtuelle Repräsentanz in der Cloud weiter. Sie bildet das Bindeglied zwischen dem Wearable als physische Repräsentanz und dem virtuellen Datenabbild auf den Internet-Servern des Herstellers. Über die Körpergröße und das Gewicht, die bei einem Setup in die Smartphone-App eingetippt werden, lassen sich aus den Schrittzählerdaten der tägliche Kalorienverbrauch und verschiedene andere Aktivitätsdaten, wie zum Beispiel das Schlafverhalten, ermitteln.

Direkte oder indirekte Verbindung

Eine wichtige Fragestellung mit weitreichenden Auswirkungen auf die Ressourcen des zum Einsatz kommenden Embedded Systems sind die Details der Kommunikationsverbindung zur virtuellen Repräsentanz. Grundsätzlich sind drei unterschiedliche Lösungen in einer IoT-Anwendung denkbar (Abbildung 3, PDF):

  1. Das Embedded System ist als Thing per Internet direkt mit einem IoT- bzw. Cloud-Service verbunden. Diese Direktverbindung kann durch die LAN/WLAN-Einbindung des Embedded Systems in ein vorhandenes Netzwerk mit Internet-Zugang per Router oder mit Hilfe eines integrierten Mobilfunkmodems – also über eine GSM/UMTS/LTE-Funkverbindung – erfolgen.
  2. Ein Embedded System ist durch ein spezielles Gateway indirekt mit der virtuellen Repräsentanz in einer Cloud-Serviceplattform gekoppelt. Die Verbindung zwischen Gateway und Embedded System erfolgt in der Regel per Kabel- oder ISM-Funkverbindung.
  3. Das Embedded System ist mit einer Smartphone-App verbunden, die für die Verbindung zur virtuellen Repräsentanz auf einer IoT- bzw. Cloud-Serviceplattform verantwortlich ist. In den meisten Fällen wird das Embedded System dann per Bluetooth mit dem Smartphone kommunizieren. Grundsätzlich wäre allerdings auch eine USB-Kabelverbindung denkbar, da zumindest neuere Android-Smartphones eine offene USB-Schnittstelle besitzen, die über ein Accessory Development Kit (ADK) entsprechend unterstützt wird. 


Bei einer direkten Verbindung zwischen physischer und virtueller Repräsentanz sind im Embedded System erhebliche Hard- und Software-Ressourcen erforderlich, um die umfangreichen Anforderungen hinsichtlich Funktionalität und Security umzusetzen. Im Falle einer indirekten Verbindung lassen sich die komplexen Aufgaben in das Gateway oder die Smartphone-App auslagern, so dass das Embedded System im einfachsten Fall durch einen Single-Chip-Mikrocontroller mit wenigen KByte internem Flash und SRAM realisierbar wäre (siehe Fitness-Armband-Beispiel in der Abbildung 2 (PDF). Die Tabelle 1 liefert eine Übersicht zu den unterschiedlichen Anforderungen.

Abbildung 3 (siehe PDF): Die Kommunikationsverbindung zwischen physischer Repräsentanz (dem Thing, also dem Embedded System einer IoT-Anwendung) und der virtuellen Repräsentanz in der Cloud kann direkt oder indirekt per Gateway bzw. Smartphone-App erfolgen. In Abhängigkeit vom Verbindungstyp muss das Embedded System unterschiedliche Protokolle und Sicherheitsfunktionen unterstützen.

REST und andere Schnittstellen

Der Zugriff auf die Daten und Strukturen der virtuellen Repräsentanzen in der Cloud bzw. auf einer IoT-Serviceplattform erfolgt wie bereits angesprochen über vordefinierte APIs. Die meisten IoT-Plattformen verwenden zurzeit REST-basierte Lösungen (REST = Representational State Transfer). REST ist ein Architekturmodell für Webservices, die mit Hilfe der HTTP-Methoden GET, PUT, POST und DELETE realisiert werden). REST orientiert sich dabei am in der IT verbreiteten CRUD-Modell (CRUD = Create, Read, Update, Delete – für alle Zugriffe auf eine Datenbank reichen in der Regel die vier CRUD-Operationen aus.

Das "State Transfer" in REST bedeutet, dass mit jedem HTTP-Request, bzw. jeder HTTP-Response, jeweils ein kompletter Status – also alle Daten, die einen bestimmten Zustand beschreiben – übertragen wird. Dadurch ergibt sich ein weiteres wichtiges REST-Merkmal: die Zustandslosigkeit. Ein REST-Server oder -Client muss sich zwischen zwei aufeinanderfolgenden Requests nichts merken. Die aus dem Web bekannten "HTTP-Cookies" sind für REST-Lösungen nicht erforderlich – das bedeutet: ein Embedded System muss Zustände nicht dauerhaft zwischenspeichern. Weiterhin ist ein HTTP-Request bzw. die HTTP-Response an keinen bestimmten Datentyp gebunden. Es können sowohl XML, als auch HTML, JSON oder einfache ASCII-Datenwerte übertragen werden.

Fazit

IoT-Anwendungen bestehen aus zahlreichen Komponenten. Die wichtigste und gleichzeitig auch die komplexeste Funktionseinheit ist eine Cloud- bzw. IoT-Serviceplattform. Dort wird über geeignete Datenstrukturen eine virtuelle Repräsentanz für die "Things" gebildet. Der Zugriff erfolgt in der Regel per REST-API. Solche HTTP-basierten APIs sind zwar im Moment bei nahezu allen IoT-Anwendungen die favorisierte Lösung. Der Grund dafür dürfte aber in erster Linie in der großen HTTP-Verbreitung durch das Internet der Menschen liegen. Technisch ist HTTP eigentlich für das Internet der Dinge nur sehr eingeschränkt geeignet. Als Protokoll für Embedded Systeme und Smartphone-Apps sollte stattdessen MQTT genutzt werden. Zum einen lassen sich dadurch Sensordaten sehr viel effizienter an eine IoT-Serviceplattform übermitteln. Zum anderen muss ein Aktor oder eine Smartphone-App nicht mit permanenten REST-GET-Polling einen IoT-Service abfragen, um eine Datenänderung in der virtuellen Repräsentanz mitzubekommen. Da nahezu alle IoT-Anwendungen die gleiche Architektur besitzen, sollten die erforderlichen Komponenten in einem Baukasten zusammengefügt werden.

 

Beitrag als PDF downloaden


System- und Hardwareentwicklung - unsere Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Internet of Things/System- und Hardwareentwicklung.

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.


System- und Hardwareentwicklung - Fachwissen

Wertvolles Fachwissen zum Thema Internet of Things/System- und Hardwareentwicklung steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.