chevron_left
chevron_right

Das Internet of Things: Am Rande Blau?

Das Internet of Things, IoT, «verlängert» das Internet von der virtuellen Welt in die physische Welt. Sprich, der User kann sich in seinem Web-Browser nicht nur die Resultate von Datenbankabfragen anzeigen lassen, sondern auch Informationen über Zustände der realen Welt – sei dies im professionellen oder privaten Umfeld.

 

Relevante oder interessante Informationen oder Fragen könnten zum Beispiel folgende sein: Sind alle Tore eines Areals geschlossen? Wie ist der Ladezustand meines Elektrofahrzeugs? Wie ist die aktuelle Schadstoffbelastung in meinem Wohnquartier? Umgekehrt liessen sich auch physische Aktionen über das Internet auslösen, z.B. vom Smartphone aus das Wochenendhäuschen vorheizen.

Internetprotokolle sind allgegenwärtig

Vor Jahren hatte ich für mein Buch «Getting Started with the Internet of Things» folgende Definition gewählt: The Internet of Things is a global network of computers, sensors and actuators connected through Internet protocols. Meiner Meinung nach spielen Internetprotokolle eine zentrale Rolle beim IoT.

Dies ist die langfristige Vision einer durchgängig nutzbaren Technologie, bei der IP-Pakete zwischen Sensoren, «Cloud»-Rechen-zentren und Aktuatoren versendet werden. Es gibt intensive Bestrebungen am Markt, diese Vision zu realisieren. Die Hürde dabei ist der «Rand des Internets», sind «die letzten Meter» bis zum Sensor oder Aktuator. Tradi- tionell kommen hier andere Technologien zum Einsatz, z.B. der CANbus. Feldbusse sind auch ein Beispiel, mit wie viel Nachdruck versucht wird, Internetprotokolle näher an die Sensoren zu bringen, z.B. die Evolution von Modbus zu Modbus/TCP.

Auch im Wireless-Bereich versucht man, mehr IP-Kompatibilität herzustellen, selbst bei stromsparenden Low-Data-Rate-Protokollen (6LoWPAN, ZigBee IP, 920IP, Thread, IEEE 802.11af usw.). Da ein IP-Header riesig ist im Vergleich zu typischen Meldungen über Low-Data-Rate-Protokolle, sind spezielle Kompressionsverfahren nötig.

Sind Internetprotokolle unausweichlich?

Während der Trend eindeutig zu sein scheint, ist es interessant, dass sich manche Standards erstaunlich immun gegenüber IP-Protokollen erweisen, obwohl grundsätzlich ein «IP-Tunneling» darüber möglich ist: USB und Bluetooth. Diese Technologien sind offenbar hinreichend nützlich und preiswert – und dank PCs und Laptops verbreitet genug – dass sie eine eigenständige Bedeutung gewinnen und erhalten konnten.

Smart: Bluetooth Low Energy

2006 hörten wir von einer neuen Funktechnologie namens Wibree, entwickelt in einem Nokia-Forschungszentrum. Sie erschien vielversprechend für Low-Power-Szenarien mit kurzer Reichweite, etwa im Bereich Hausautomation, für medizinische Anwendungen und weitere Anwendungsfälle. Ein paar Jahre später hat Nokia in einem cleveren Schachzug die Kontrolle über Wibree an die «Bluetooth Special Interest Group» übergeben. 2010 wurde sie, leicht modifiziert, ein offizieller Bestandteil des Bluetooth-4.0-Standards, heute bekannt unter den Bezeichnungen Bluetooth Low Energy (BLE) oder kurz Bluetooth Smart.

Das gegenwärtig rasante Wachstum von BLE kommt nicht zuletzt daher, dass es vernachlässigbare Zusatzkosten zum klassischen Bluetooth verursacht: Es kostet wenig, in neue Versionen bestehender Bluetooth-Produkte zusätzlich BLE zu integrieren – ein paar Prozent mehr Siliziumfläche auf dem Funkchip.

Smartphones und Appcessories

Ein Schub für BLE kam mit dem iPhone 4s; seither hat Apple praktisch überall BLE-Unterstützung eingebaut. Und zwar nicht nur die nötige Hardware; mit dem Core Bluetooth Framework stehen Entwicklern auch die nötigen APIs zur Verfügung. Damit lassen sich Apps entwickeln, die auf BLE-Geräte zugreifen. Diese Kombination wird manchmal als «App-cessory» bezeichnet: eine App für Accessories. So könnte z.B. ein Servicetechniker sein Smartphone benutzen, um ein neues Gerät über BLE in Betrieb zu nehmen, ohne dass das Gerät dazu über ein LCD oder USB-Stecker verfügen muss. Das Smartphone kann sogar als temporärer Gateway zwischen dem Gerät und dem Internet dienen, um die Firmware zu aktualisieren oder gespeicherte Logdaten an einen Server zu übermitteln.

Inzwischen hat auch Google BLE-Unterstützung in Android eingeführt und Microsoft für Windows Phone. Dadurch wird BLE zu einer herstellerübergreifenden Technologie für Appcessories, von Fitnessarmbändern zu Smart Watches und allem, was man in seiner Umgebung kontrollieren möchte: Türen, Fernseher, Sprinkleranlagen usw.

Noch ist die Technologie neu, und insbesondere die BLE-Unterstützung in Android hat noch ihre Macken. Die Situation verbessert sich jedoch stetig, und ein Erfahrungsaustausch zwischen Entwicklern ist in Gang gekommen. Einer meiner Mitarbeiter hat dazu eine populäre «Core-Bluetooth-Gruppe» innerhalb Facebook aufgesetzt (auf Einladung).

Erfolg jenseits von IP?

BLE ist vermutlich eine der wenigen neuen Kommunikationstechnologien, die auch ohne Internetprotokolle erfolgreich sein kann. Obwohl noch jung und kaum bekannt, hat BLE bereits begonnen, andere Technologien zu verdrängen. So habe ich kürzlich von einer Ausschreibung erfahren, in der BLE vorgegeben war. Und zwar im Beleuchtungssektor – ein Bereich, in dem ich ZigBee erwartet hätte, das dort schon gut etabliert ist und über sein Mesh-Protokoll eine grössere Reichweite erlaubt. Anscheinend besiegt das Argument «du kannst es von deinem Smartphone aus kont-rollieren» jedoch fast jedes Gegenargument.

Manchmal wird dies surreal: Wir wurden von einer amerikanischen Firma kontaktiert, deren gesamte Geschäftsidee darauf beruhte, dass man mit BLE Hunderte Sensoren mit nur einem GSM Gateway verbinden kann, über mehrere Stockwerke und Flügel eines grossen Gebäudes hinweg. Dies ist leider unrealistisch, obwohl BLE tendenziell eine leicht grössere Reichweite als klassisches Bluetooth hat.

Service-orientierte Architektur für Geräte

Als Systemarchitekt finde ich einen Aspekt von BLE besonders spannend: Das GATT-Protokoll. GATT steht für Generic Attribute Profile. Dabei geht es mir nicht primär um die drahtlos übermittelten Lese- und Schreibzugriffe auf die sogenannten Characteristics. Viele Protokolle arbeiten ähnlich. Eine Characteristic kann z.B. die Lufttemperatur eines Sensors repräsentieren oder den (änderbaren) Zustand eines Ventils bei einem Aktuator (offen/geschlossen).

Characteristics kann man zu Services bündeln; Profiles sind Sammlungen von Services. Ein «Profile» entspricht einem Anwendungsfall. So dient z.B. das «Blood Pressure Profile» zum Messen des Blutdrucks.

Ein Service ist eine wiederverwendbare Schnittstelle, die von jedem Gerät implementiert werden kann. Dies erleichtert es, Geräte kompatibel zu machen, z.B. kann jedes BLE-Gerät den Device Information Service implementieren, der ganz generisch Informationen über Hersteller und Modell des Geräts liefert. Wir haben hier eine Service-orientierte Architektur auch für kleinste Geräte, in welche die Erfahrung mit Kompatibilitätsproblemen beim klassischen Bluetooth eingeflossen ist.

Firmware-Hölle, die IoT-Variante der DLL-Hölle?

Services sind ein Schlüsselkonzept von BLE. Ein Service ist eine unveränderliche Definition von Characteristics. Wieso unveränderlich? Der Grund liegt darin, dass die meisten Low-Cost-Geräte nicht dafür gemacht sind, dass man ihre Firmware leicht (oder überhaupt) aktualisieren kann. Nehmen wir an, Sie haben ein Gerät erfolgreich im Markt. Nach einer Weile möchten Sie einen Service dieses Geräts erweitern. Mindestens für eine gewisse Zeit, meist sehr lange, sind nun beide Versionen des Service im Umlauf.

Was passiert, wenn nun eine aktuelle Smartphone-App auf den erweiterten Service zugreifen möchte, jedoch ein altes Gerät erwischt? Ein solcher Versionskonflikt zwischen Komponenten ist in der Software-Welt als «DLL-Hölle» bekannt. Wenn man jedoch eine Menge inkompatibler Geräte hat, ohne die Chance, mit Firmware-Updates alle Geräte synchron auf den gleichen Stand zu bringen, befindet man sich in einer noch unangenehmeren Situation.

Deshalb die Vorgabe innerhalb BLE, die Definition eines Service A nie mehr zu verändern ab dem Zeitpunkt, zu dem Geräte mit diesem Service unkontrollierbar im Umlauf sind. Falls man später die Funktionalität des Geräts erweitern möchte, definiert man einen neuen Service A1: eine Obermenge von Service A mit einer zusätzlichen Characteristic. Neue Geräte bieten beide Services an, was billig zu realisieren ist, falls sie bis auf die zusätzliche Characteristic identisch sind. Es gibt vier Konstellationen, in welchen der Anbieter des Service (Peripheral) auf einen Benutzer des Service (Central) treffen kann. Jede davon kann wohldefiniert behandelt werden.

Wie weiter?

BLE bietet sich an, um Wearables mit einem Smartphone zu verbinden, aber auch für Heimgeräte wie z.B. Waagen oder Pflanzensensoren. Es sind auch Gateways in Entwicklung, welche eine standardisierte Abbildung zwischen GATT und HTTP realisieren, z.B. unser Limmat Board, das BLE-Geräte mit mobilen Datennetzen verbindet. Damit können BLE-Geräte unabhängig von Smartphones am IoT teilhaben. Weitere Entwicklungen sind zu erwarten, so unterstützt z.B. Apple mit ihrem neuen HomeKit GATT und BLE. Interessant ist, dass Apple dabei dieselbe Art von Gerätezugriff auch über WLAN unterstützt. Dies deutet an, dass GATT auch das Potenzial zu einem universellen High-Level-Applikationsprotokoll haben könnte, welches neben BLE auch WLAN, Ethernet, und poten-ziell weitere Protokolle wie AMQP als Transportprotokolle nutzt. Umgekehrt könnte man sich auch OPC UA Server vorstellen, die via GATT auf industrielle BLE-Feldgeräte zugreifen.

Ich erwarte nicht, dass sich eine einzige Technologie «am Rande des Internets» durchsetzen wird. Ein Regenbogen von Protokollen scheint eher wahrscheinlich. Viele davon IP-basiert, andere nicht. Bei Letzteren würde ich jedoch darauf setzen, dass BLE einen erheblichen Anteil ausmachen wird.

Infoservice

Oberon microsystems AG
Technoparkstrasse 1, 8005 Zürich
Tel. 044 445 17 51, Fax 044 445 17 52
pfister@oberon.ch, www.oberon.ch