Entwicklung von intelligenten Anwendungen auf der Grundlage von Bluetooth Low Energy mit Bluetooth Mesh – 2. Teil

Anmerkung des Herausgebers: Der 1. Teil dieser zweiteiligen Artikelserie stellt die Architektur und die Möglichkeiten des Protokolls Bluetooth Mesh 1.0 im Detail vor. Hier in Teil 2 wird beschrieben, wie die Integration von Bluetooth Mesh in Bluetooth-Low-Energy-Designs mit Chips und Entwicklungskits erfolgt.

Bluetooth Mesh erweitert das beliebte Nahbereichsprotokoll Bluetooth um die bemerkenswerten Vorteile der Vernetzung. Damit haben wir uns in Teil 1 ausführlich befasst. Allerdings ist die Spezifikation auch mit neuen Herausforderungen hinsichtlich des Designs verknüpft, vor allem, wenn es um die Umsetzung seiner Modelle geht.

Der Schlüssel zur Bewältigung dieser Herausforderungen ist die Nutzung neuer Entwicklungstools, mit denen sich Designer intensiv mit Bluetooth Mesh vertraut machen können. In diesem Artikel wird beschrieben, wie Sie mithilfe ausgewählter Bluetooth-Hardware und -Software, mit Entwicklungskits (DKs) und Software-Entwicklungskits (SDKs) Anwendungen für Bluetooth Mesh einrichten und aufbauen können.

Entwicklungstools für Bluetooth Mesh

Der Stack von Bluetooth Mesh umfasst eine völlig neue Host-Schicht, die einige Konzepte mit der Host-Schicht von Bluetooth Low Energy gemeinsam hat, aber nicht mit ihr kompatibel ist. Derzeit werden erste Versionen des Bluetooth-Mesh-Stacks für Entwicklungszwecke verfügbar gemacht, in der Regel als Bestandteil eines SDK.

Da es sich bei Bluetooth Mesh um eine ergänzende Spezifikation zur Bluetooth-Core-Spezifikation handelt, besteht für die Anbieter keine Notwendigkeit von Upgrades ihrer physikalischen Schicht (PHY) oder der Software-Stacks von Bluetooth Low Energy (BLE), um Bluetooth Mesh zu unterstützen. Zur Ergänzung durch Bluetooth Mesh müssen die Anbieter jedoch ihre eigenen Implementierungen des Stacks für ihre Kunden bereitstellen.

So hat beispielsweise der BLE-Anbieter Nordic Semiconductor bereits das nRF5 SDK für Mesh vorgestellt. Das Kit umfasst einen Bluetooth-Mesh-Stack, eine Auswahl an Treibern und Bibliotheken sowie Beispiele für Anwendungen für Maschennetze. Das SDK ist unter mehreren integrierten Entwicklungsumgebungen (IDEs) und Compilern wie CMake und SEGGER Embedded Studio von Segger Microcontroller Systems lauffähig.

Da Bluetooth Mesh mit allen Versionen von BLE kompatibel ist (d. h. 4.0, 4.1, 4.2 und 5), kann das Mesh-SDK von Nordic letztlich mit allen BLE-Chips des Anbieters eingesetzt werden. Die aktuelle Version ist allerdings nur mit den aktuellen BLE-Lösungen von Nordic aus der nRF52-Serie verwendbar, wozu z. B. der Mid-Range Bluetooth-5-kompatible nRF52832-Chip zählt.

Da es keine Änderung an der BLE-PHY-Schicht oder dem Software-Stack gibt, kann die Bluetooth-Mesh-Entwicklungsarbeit mit einem vorhandenen DK unter Einbeziehung des Zielgeräts durchgeführt werden. Für den nRF52832 wird als DK das nRF52 DK empfohlen (Abbildung 1).

Abbildung 1: Das Mesh-SDK von Nordic Semiconductor arbeitet in Verbindung mit dem nRF52 DK, das ein nRF52832 SoC-Zielgerät umfasst. (Bildquelle: Nordic Semiconductor)

Für die Entwicklung von Maschennetzwerken sind mindestens drei (vorzugsweise mehr) Geräte erforderlich, die miteinander kommunizieren und eine Maschennetzwerkumgebung simulieren. Idealerweise könnten mehrere DKs eingesetzt werden, um die Knoten in einem Maschennetz zu repräsentieren, das hätte aber den Nachteil deutlich höherer Kosten der Entwicklungshardware. Ein alternativer Ansatz ist der Einsatz von nur einem DK und der Kauf getesteter und verifizierter BLE-Module (basierend auf dem Zielgerät), um die zusätzlichen Knoten zu bilden. Gute Moduloptionen für die Entwicklungsarbeit mit dem nRF52832 von Nordic sind das BMD-300 von Rigado oder das BL652-SA-01-T/R vonLaird.

Cypress Semiconductor hat einen ähnlichen Ansatz gewählt wie Nordic. Das Unternehmen bietet ein Bluetooth-Mesh-SDK für sein BCM92073X WICED SMART-DK, das auf dem Bluetooth-v4.1-PHY BCM20736S von Cypress basiert. Ein geeignetes BLE-Modul zur Entwicklung von Maschennetzen auf der Grundlage dieser PHY-Schicht ist zum Beispiel dasISM20736S vonInventek.

Verständnis der Modelle

Die Hardware, die Software und die Entwicklungstools von Nordic und Cypress werden zusammen mit Beispielen und Tutorials geliefert, die Entwickler durch die Schritte zum Aufbau einer einfachen Anwendung für Bluetooth Mesh führen. Aber bevor wir uns einem ersten Design zuwenden, kann es hilfreich sein, die zugehörigen Tutorials zu absolvieren. Sie helfen beim Verständnis der spezifischen Merkmale der Bluetooth-Mesh-Architektur, weil diese großen Einfluss auf den Designprozess haben.

In diesen Tutorials wird betont, dass es zwar vier generische Typen von Bluetooth-Mesh-Knoten gibt (siehe Teil 1 dieser zweiteiligen Artikelserie), dass die Fähigkeiten jedes Typs jedoch vom jeweiligen Modell (bzw. Modellen) abhängen. Das Verständnis dieser Modelle ist der Schlüssel zur optimalen Nutzung der Fähigkeiten von Bluetooth Mesh.

Bluetooth Mesh bietet die erforderliche Flexibilität zum Aufbau neuartiger Anwendungen für Maschennetzwerke, weil die Entwickler Modelle erstellen können, die Geräte mit verschiedensten benutzerdefinierten Verhaltensweisen ermöglichen. Ein Modell definiert eine Reihe von Zuständen und Nachrichten, die auf der Grundlage dieser Zustände agieren, sowie das damit verbundene Verhalten. Die gesamte Kommunikation über ein Maschennetzwerk erfolgt über Nachrichten.

Ein Zustand ist ein Wert für eine Bedingung eines Elements. Ein Element ist eine adressierbare Entität eines Geräts oder Knotens. Jedes Gerät verfügt über mindestens ein (primäres) Element und kann über ein oder mehrere sekundäre Elemente verfügen. Anzahl und die Struktur der Elemente ändern sich über die gesamte Lebensdauer des Knotens hinweg nicht. Ein Element, das einen Zustand „ausgibt“, wird als Server bezeichnet. Ein Element, das auf einen Zustand „zugreift“, wird als Client bezeichnet.

Wichtig ist: Die Modelle entsprechen drei Typen: Server, Client und Steuerung. Ein Servermodell umfasst einen oder mehrere Zustände, die sich auf ein oder mehrere Elemente beziehen. Es definiert eine Reihe von obligatorischen Nachrichten, die gesendet oder empfangen werden können, das Verhalten des Elements beim Senden und Empfangen der Nachrichten sowie jegliches zusätzliche Verhalten, das auftritt, nachdem Nachrichten gesendet oder empfangen wurden.

Ein Clientmodell definiert eine Reihe von Nachrichten, die ein Client nutzt, um entsprechende Serverzustände anzufordern, zu ändern oder zu „verbrauchen“, wie das vom Servermodell vorgegeben ist. Das Clientmodell umfasst keine Zustände.

Ein Steuerungsmodell kann Clientmodell-Funktionalität (für die Kommunikation mit anderen Servermodellen) und Servermodell-Funktionalität (für die Kommunikation mit anderen Clientmodellen) kombinieren. Ein Steuerungsmodell kann auch Steuerungslogik enthalten, d. h. eine Reihe von Regeln und Verhaltensweisen, welche die Interaktionen des Steuerungsmodells mit anderen Modellen koordinieren, mit denen das Steuerungsmodell zusammenarbeitet (Abbildung 2).

Abbildung 2: Element-Modellstruktur eines Bluetooth-Mesh-Geräts mit Implementierung eines Steuerungsmodells. Gerät C kann mit Servermodellen (innerhalb der Geräte A und B) als Client (Nachrichten X, Y und Z bzw. Nachrichten R, S und T) und Clientmodellen (innerhalb des Geräts D) als Server (unterstützende Nachrichten A, B und C) kommunizieren. (Bildquelle: Bluetooth SIG)

Nehmen wir eine Steckdosenleiste, um die Nutzung von Modellen in einem praktischen Beispiel zu veranschaulichen. Sie besteht aus zwei unabhängigen Steckdosen, deren Ausgabeleistung jeweils steuerbar ist, und aus einem BLE-Funkmodul, das die Vernetzung der Leiste in einem Bluetooth-Maschennetzwerk ermöglicht.

Damit umfasst das Gerät (die Steckdosenleiste) zwei Elemente, die für jede der beiden Steckdosen stehen. Die Funktion jedes Elements wird durch das Servermodell „Generic Power Level“ definiert. Es legt eine Reihe von Zuständen auf einem Server fest sowie eine Reihe von Nachrichten, die auf der Grundlage dieser Zustände agieren. Eine Nachricht „Generic Power Level Set“ kann zu dem Gerät gesendet werden, um die Ausgabeleistung zu steuern. Die Nachricht ist an eines der Steckdosenelemente adressiert.

Die Steckdosen können auch durch ein generisches Gerät, wie z. B. einen Dimmer, gesteuert werden, der das Generic-Level-Clientmodell implementiert. Dieses Modell stellt einen gewünschten Pegel auf null, auf einen Maximalwert oder auf einen Wert dazwischen. Die an die Steckdose gelieferte Leistung wird durch Bindung an Zustände gesteuert. In jeder Steckdose ist der Zustand „Generic Power Actual“ an den Zustand „Generic Level“ gebunden. Ein Generic-Level-Client sendet Generic-Level-Nachrichten an den Generic-Level-Server. Der Zustand „Generic Level“ wird geändert, was wiederum (über die definierte Bindung) zur Änderung des Zustands „Generic Power Actual“ führt, der die Leistungsausgabe steuert.

Da die Elemente Zustände melden können, kann jede Steckdose den Strompegel sowie den Energieverbrauch eines Geräts melden, das an diese Steckdose angeschlossen ist. Der Energieverbrauch wird anhand von Meldungen berichtet, die durch das Sensor-Servermodell definiert sind.

Aufbau eines Bluetooth-Maschennetzwerks

Vorausgesetzt, der Entwickler hat sich eine gewisse Vertrautheit mit der Architektur von Bluetooth Mesh und der BLE-Entwicklung erarbeitet (siehe DigiKey Artikel: „Mit Bluetooth 4.1, 4.2 und 5 kompatible Bluetooth-Low-Energy-SoCs und -Tools stellen sich den Herausforderungen des Internets der Dinge“ zu weiteren Informationen zum allgemeinen BLE-Design) und er verfügt über ein Bluetooth-Mesh-SDK, ein Host-SDK, ein DK und zusätzliche Module oder DKs zum Einrichten eines Netzwerks, dann kann der Entwickler relativ einfach ein Bluetooth-Maschennetzwerk implementieren.

Der erste Schritt ist der Aufbau des Mesh-Stacks. Im Fall von Nordic beruht der Stack auf dem ausgewählten IDE. Beim Beispiel von SEGGER Embedded Studio wird der Stack erstellt, indem eines der Beispiele genutzt wird, das im Bluetooth-Mesh-SDK enthalten ist (z. B. „Lichtschalter“), und die Kompilierung mit der IDE erfolgt.

Dann wird die Ziel-PHY-Schicht auf dem DK gelöscht und mit dem kompilierten Bluetooth-Mesh-Stack und dem BLE-Stack neu programmiert. Sobald die Stacks programmiert und geprüft wurden, kann das SDK zur Einrichtung und zum Aufbau von Maschennetzwerken verwendet werden.

Bereitstellung: Die Entwicklungstools von Nordic umfassen eine Bereitstellungs-API (Application Programming Interface), die zum Hinzufügen neuer Geräte zu einem Maschennetzwerk verwendet wird. Die Bereitstellung erfolgt durch „Provisioner“ (Geräte, die bereits in das Netzwerk eingebunden sind und zuvor für die Bereitstellungsaufgabe konfiguriert wurden). Sie liefern neuen Geräten die Informationen, die diese benötigen, um einem Maschennetzwerk beizutreten. Zunächst wird dem Gerät ein Netzwerkschlüssel, eine Adresse und ein Geräteschlüssel zur Verfügung gestellt. Damit kann ein sicherer Kanal zur Konfiguration des Geräts nach seiner Bereitstellung eingerichtet werden.

Die API ermöglicht es dem Entwickler, das Abhören auf das Broadcast-Beacon des nicht bereitgestellten Knotens (des Geräts, das zum Netzwerk hinzugefügt werden soll, das als „Provisionee“ bezeichnet wird) zu starten. Dieses Beacon wird auf einem der drei BLE-Advertising-Kanäle gesendet. Bluetooth Mesh sendet und empfängt Nachrichten nicht über die 37 Datenkanäle mit voller Bandbreite, sondern über die BLE-Advertising-Kanäle. Auf dem Kanal eingehende Verbindungsanforderungen werden vom Provisioner automatisch akzeptiert.

Wenn die Verbindung aufgebaut wurde, wird sie über ein OOB-Verfahren (Out-of-Band) authentifiziert. Damit wird sichergestellt, dass es sich bei dem zum Netzwerk beitretenden Gerät auch wirklich um das beabsichtigte Ziel handelt. Durch Nutzung der OOB-Verfahren sinkt die Wahrscheinlichkeit von „Man-in-the-middle“-Angriffen durch Geräte, welche die BLE-Frequenzzuweisung überwachen. Ein API-Ereignis stellt dann die Bereitstellungsdaten und den Geräteschlüssel für das Gerät bereit.

Konfiguration: Die „Lichtschalter"-Anwendung von Nordic (im SDK enthalten) zeigt, wie die Entwicklung von Anwendungen mit den Provisioner- und Provisionee-Rollen erfolgt. In der Demo ist ein Lichtschalter-Clientmodell (der Schalter) der Provisioner und das Lichtschalter-Servermodell (die Lampe) ist der Provisionee.

Das Nordic-Beispiel zeigt am deutlichsten, dass der einfachste Server in der Bluetooth-Mesh-Spezifikation ein „Generic OnOff“-Server ist, der dafür steht, dass der Server entweder ein- oder ausgeschaltet ist. Das einfachste Beispiel für einen Client ist ein „Generic OnOff“-Client, der in der Lage ist, einen „Generic OnOff“-Server über Nachrichten zu steuern, die durch das „Generic OnOff“-Modell definiert werden.

Wenn dieses Servermodell eine GET- oder (zuverlässige) SET-Meldung von einem Clientmodell empfängt, sendet es als Antwort den aktuellen Wert des OnOff-Zustands. Dies hält den Client im Hinblick auf den Serverzustand auf dem neuesten Stand (Abbildung 3).

Abbildung 3: Vom Generic-OnOff-Modell unterstützte Nachrichten und ATT-Opcodes. (Bildquelle: Nordic Semiconductor)

Der Konfigurationsserver wird verwendet, um eine Maschennetzwerkkonfiguration eines Geräts darzustellen, und er ist eine zwingende Voraussetzung für Bluetooth-Mesh-Knoten. Der Konfigurationsserver wickelt die Kommunikation mit und Anweisungen von dem Konfigurationsclient ab (gesteuert durch den Provisioner).

Die Konfiguration startet nach Abschluss der Bereitstellung. Der Provisioner liest die Provisionee-Kompositionsdaten. Daraus ermittelt er die Metadaten des Geräts und welche Modelle an welches Element in dem Gerät gebunden sind. Als Nächstes werden der (oder die) Anwendungs- und/oder Netzwerkschlüssel hinzugefügt und an die verschiedenen Modelle gebunden (Abbildung 4).

Abbildung 4: Bereitstellungs- und Konfigurations-Flussdiagramm des nRF5-SDK für Maschennetzwerke. Die „nrf_mesh…“-Aufrufe sind API-Funktionen. (Bildquelle: Nordic Semiconductor)

Das Hinzufügen weiterer Geräte zu dem Netzwerk erfolgt einfach durch Wiederholung des Bereitstellungs- und Konfigurationsprozesses für jeden neuen Knoten.

Veröffentlichen und Abonnieren: Die letzte Phase des Einrichtens und Aufbauens einer ersten Anwendung ist das Konfigurieren des Veröffentlichungszustands der Modelle. Das umfasst zum Beispiel die Adresse, die zum Veröffentlichen von Zustandsereignissen verwendet wird, welcher Schlüssel und welcher TTL-Wert (Time-To-Live) verwendet werden soll, und das Festlegen von Abonnements.

Nachrichten werden gesendet, wenn sie von der Veröffentlichungsadresse jedes Modells veröffentlicht werden. Die Veröffentlichung wird beispielsweise durch einen Sensorknoten verwendet, der in regelmäßigen Abständen Daten sendet. Nachrichten können nur einmal oder wiederholt veröffentlicht werden, und sie werden entweder an ein Unicast, eine Gruppe oder eine virtuelle Adresse gesendet (siehe Teil 1 dieses Artikels). Die Veröffentlichung wird auch von Clientmodellen verwendet, um Nachrichten an Servermodelle zu senden.

Die Konfiguration von Zuständen in Bezug auf die Veröffentlichung wird in der Regel durch einen Provisioner über das Konfigurationsmodell gesteuert.

Bei Verwendung des Nordic-SDK werden Nachrichten mit der API-Funktion „access_model_publish()“ veröffentlicht. Sie veröffentlicht eine Nachricht gemäß den Veröffentlichungseinstellungen (Intervall, Ziel) des Veröffentlichungsmodells.

Abonnements ermöglichen Modellen das Abhören auf eingehende Nachrichten von bestimmten Adressen. Sie können zum Beispiel verwendet werden, um die von Sensorknoten regelmäßig veröffentlichten Nachrichten abzuhören. Das Nordic-SDK ermöglicht es Modellen, eine Adresse zu abonnieren, indem mithilfe der API-Funktion „access_model_subscription_list_alloc()“ eine Abonnementliste zugewiesen wird.

Beachten Sie, dass es bei Verwendung eines Clientmodells nicht erforderlich ist, die Adresse zu abonnieren, von der Nachrichten gesendet werden, um Antworten auf diese Nachrichten zu empfangen. Abonnements werden nur zum Empfangen von unerbetenen Nachrichten von Knoten verwendet.

Während des Entwicklungsprozesses kann es vorteilhaft sein, ein nicht Bluetooth-Mesh-fähiges Gerät in das Bluetooth-Maschennetzwerk einzubinden. Ein Beispiel hierfür könnte ein Smartphone sein, dass der Entwickler zur Steuerung einer Prototyp-Anwendung für ein intelligentes Maschennetz für Beleuchtungen verwenden möchte. Die Interaktion zwischen dem Mobilgerät und dem Maschennetz erfolgt nicht über den Bluetooth-Mesh-Stack, sondern über eine GATT-Schnittstelle (Generic Attribute Profile) zwischen dem Smartphone und dem Knotengerät.

Zusammenfassung

Bluetooth Mesh erweitert BLE-Anwendungen um neue Funktionen. Da Maschennetzwerkfunktionen jedoch kein Bestandteil der ursprünglichen Core-Spezifikation sind, mussten bei seiner Einführung einige Kompromisse eingegangen werden, und der Designprozess hat sich um einiges verkompliziert. Entwickler, die mit dem Designen unter Verwendung des Bluetooth-Protokollstacks vertraut sind, sind hier im Vorteil gegenüber denjenigen, die diese Kenntnisse nicht besitzen. Doch selbst erfahrene Entwickler müssen sich zur Implementierung von Bluetooth Mesh mit einer neuen Architektur und deren Einzelheiten wie Zuständen, Elementen und Modellen vertraut machen.

Diese Herausforderung lässt sich durch Zusammenarbeit mit Anbietern wie Nordic Semiconductor oder Cypress Semiconductor besser beherrschen. Diese Anbieter haben inzwischen zur Ergänzung ihrer ausgereiften BLE-Lösungen Bluetooth-Mesh-Stacks veröffentlicht. Für die Stacks sind speziell entwickelte SDKs verfügbar, die es dem Entwickler ermöglichen, ihnen vertraute Chips, Firmware und Designtools einzusetzen, um den Lernprozess beim Designen von Bluetooth-Anwendungen für Maschennetzwerke zu beschleunigen.

Referenz

1. „Mesh Profile“, Bluetooth-Spezifikation v1.0, Bluetooth SIG, Juli 2017.