Internet of Things mit Bluetooth LE - Teil 2

Im Blogpost "IoT mit Bluetooth LE - Teil 1" beschrieb ich, für welche Gegebenheiten die Nutzung von Bluetooth LE für IoT-Projekte sinnvoll sein kann und machte ein Beispiel eines Kaffeevollautomaten. Dieser Blogpost knüpft daran an und beschreibt, wie man damit umgehen kann, wenn komplexere Daten ausgetauscht werden sollen oder die Architektur die Bluetooth-Schnittstelle nicht so frei konfiguriert werden kann, wie im Beispiel. Gründe dafür könnten sein, dass hinter dem IoT-Device schon ein umfangreicheres System steckt, in welches dieses integriert ist.

von: Felix Lieb
Senior Developer, 
fl@next-munich.com

Inhalt

  1. Logische Kommunikationsschichten
    1.1. Datentransfer
  2. Strukturierte Daten
    2.1. CBOR
    2.2. CBOR-Standardisierung
  3. Fazit
  4. Unsere IoT Referenzen

Logische Kommunikationsschichten

Die Entwicklung für IoT-Devices, oft auch "Embedded Systems" genannt ist häufig schwieriger, als die Entwicklug einer App, da die Hardware deutlich eingeschränkter ist, was Rechenleistung und Speicher angeht. Daher ist es in der Regel einfacher bestehende Kommunikationsmethoden oder -Protokolle auf die Bluetooth-Kommunikation auszuweiten, statt sie für die Bluetooth-Kommunikation, wie sie gedacht war, neu aufzubereiten.

In solchen Fällen kann Bluetooth LE so verwendet werden, dass es einer klassischen Senden-/Empfangen-Schnittstelle gleicht. Dies kann umgesetzt werden, in dem eine Characteristic als Kanal zum Senden (Write) dient und eine Characteristic als Kanal zum Empfangen (Read & Notify). Notify ist deshalb nötig, damit die App "mitbekommt", wenn Daten auf dem Kanal zum Lesen eintreffen.

Zusätzlich wird manchmal eine dritte oder gar vierte Characteristic als Kanal für Datenflusssteuerung (flow control) eingesetzt und dient, bzw. dienen dem Aushandeln des Senden und Empfangen von Daten. So können über die Kanäle zum Senden und Empfangen ausschließlich Daten ausgetauscht werden, während auf den Flow-Control-Characteristics Kontrollnachrichten, wie bspw Ankündigungen von Daten, Bestätigungen des Empfangs von Daten oder Signalisieren von Fehlern stattfinden.

Jegliche logische Kommunikationsschicht, welche mit Read, Write und Notify umgesetzt werden kann ist hier denkbar.

Datentransfer

Ein weiterer Aspekt der Kommunikation mit IoT-Devices kann die Übertragung von Firmware sein. Bei diesen handelt es sich meist um Binärdaten von einigen Kilo- bis Megabytes. Bluetooth LE ist nicht für solche Datenübertragungen gemacht. Doch sowohl durch die Einschränkungen der Embedded Systems, als auch der Komplexität der Entwicklung für diese, wird es oft nötig, auch solche Daten mittels Bluetooth zu übertragen.

Hierfür sind oben genannte logische Kommunikationsschichten notwendig, da die derzeit gängige maximale Größe eines Werts einer Characteristic bei ungefähr 250 Bytes liegt. Es muss also eine Logik geben, die in der Lage ist, größere Daten aufzuteilen und die Übertragung zwischen Central und Peripheral abzustimmen.

Als Beispiel, mit Erfahrungswerten aus Projekten, war es möglich, unter optimalen Bedingungen, ca. 2,2 bis 2,5 Kilobytes pro Sekunde zu übertragen. Das bedeutet für die Übertragung einer Firmware in der Größe von 1 Megabyte, ca. 7 Minuten Übertragung. Zum Vergleich: Der beispielhafte Aufruf der Webseite des Spiegels führte zur Datenübertragung von ca. 250 Kilobytes. Der Aufruf der New York Times führt gar zu einer Datenübertragung von mehreren Megabytes. ISDN war bereits mehr als 3-mal so schnell.

Ob die Übertragung von solchen Daten mit Bluetooth (noch) sinnvoll ist, hängt damit stark von der Datenmenge ab, da die Übertragungsgeschwindigkeit sehr, sehr langsam ist. Dennoch ist Bluetooth aus den genannten Gründen eine gängige Kommunikationsmethode dafür.

Strukturierte Daten

Daten sind oft komplexer, als "eine Zahl", wie bspw. ein Füllstand oder ein Text. Dann werden sie in Objekte gruppiert und strukturiert, um besser damit umgehen zu können. So könnten beispielsweise die Füllstände so strukturiert werden, dass mehrere Modelle unterstützt, und Füllstände für unterschiedliche Zutaten dargestellt werden können. Ein Objekt, welches einen Füllstand einer bestimmten Zutat repräsentiert, könnte dann so aussehen:

{
  "Zutat": "Kaffeebohnen",
  "Füllstand": 0.5
}

Diese könnten nun vom Kaffeevollautomaten in nur einer Characteristic für Füllstände als Liste angeboten werden:

[
  {
    "Zutat": "Kaffeebohnen",
    "Füllstand": 0.5
  },
  {
    "Zutat": "Milchpulver",
    "Füllstand": 0.7
  },
  {
    "Zutat": "Kakaopulver",
    "Füllstand": 0.8
  },
  {
    "Zutat": "Wasser",
    "Füllstand": 0.2
  }
]

Für bessere Verständlichkeit des Beispiels verwendete ich deutsche Begriffe. In der Praxis würden entweder englische Begriffe verwendet oder in diesem konkreten Beispiel gar die Begriffe mit Zahlen ersetzt, da diese weniger Speicher benötigen und somit schneller übertragbar sind.

CBOR

Um solche, in Objekte strukturierte Daten übertragen zu können, bedarf es einer Repräsentation, damit sie zunächst kodiert, dann übertragen und schließlich beim Empfänger wieder dekodiert und verstanden werden können. Diese Repräsentation, bzw. die Kodierung in diese wird "Serialisierung" genannt. Die Dekodierung heißt entsprechend "Deserialisierung".

Ein relativ junger Standard einer solchen Serialisierung, der insbesondere mit Hinblick auf IoT entwickelt wurde, ist CBOR, "Concise Binary Object Representation". Der Name beschreibt Eigenschaften, die für IoT wichtig sind:

  • "Concise": Kurz gefasst. Die Daten sollen möglichst kompakt repräsentiert werden um Speicher und Übertragungsvolumen klein zu halten.
  • "Binary": Ein binäres Format. Das heißt, die Daten werden nicht in Text umgewandelt, wie es bspw. mit JSON oder XML der Fall wäre, sondern direkt in Binärdaten. Der Hintergrund ist, sehr verkürzt gesagt, dass Text "mehr Speicherbedarf" hat und seine Verarbeitung (Parsing) leistungsintensiver ist.

CBOR ist also eine möglichst kurz gefasste, binäre Repräsentation von strukturierten Daten (Objekten) und bringt damit wichtige Voraussetzungen für die Verwendung in IoT-Projekten mit.

Bisher scheint CBOR noch nicht all zu weit verbreitet zu sein, was sich auch in der Verfügbarkeit von Libraries zur Verwendung von CBOR widerspiegelt. Ich halte CBOR jedoch für den wichtigsten Standard für die Verarbeitung strukturierter Daten in IoT-Projekten.

CBOR-Standardisierung

CBOR wurde zunächst als Entwurf im RFC 7049 spezifiziert, welcher durch RFC 8949 abgelöst wurde.

Im Zusammenhang mit CBOR stehen auch die Spezifikationen "Concise Data Definition Language (CDDL)" (RFC 8610) zur Spezifizierung von Datenstrukturen, sowie "CBOR Object Signing and Encryption (COSE)" (RFC 1852) zur Prüfung der Authentizität, als auch der Verschlüsselung von Daten.

Umfangreiche Informationen zum Thema CBOR bietet die Webseite zum Standard cbor.io.

Fazit

Auch in komplexeren Systemen, welche schon eine Architektur mitbringen und eine Gestaltung der Bluetooth-Schnittstelle im Sinne von Bluetooth LE nicht sinnvoll oder gar nicht machbar ist, kann Bluetooth, durch die Nutzung von logischen Kommunikationsschichten und Standards für komplexe Daten, wie CBOR, als Kommunikationstechnologie in IoT-Projekten verwendet werden.

Gerade solche komplexeren Systeme stellen eine spannende Herausforderung dar, der wir uns mit Freude und Erfahrung stellen.

Unsere IoT Referenzen

 

Hier geht's zu Internet of Things mit Bluetooth LE - Teil 1