Design-Optionen für Bluetooth Low Energy

In seiner fünften Hauptversion des Systems verfügt Bluetooth mittlerweile über viele Funktionen und Optionen, die es ermöglichen, die drahtlose Kommunikation auf die genauen Bedürfnisse einer Anwendung abzustimmen. Einer der wichtigsten Faktoren für IoT-Anwendungen ist die Verfügbarkeit des Bluetooth-Energiesparprofils BLE. Es gibt jedoch eine Reihe von Faktoren, die berücksichtigt werden müssen, wenn es um die Integration von BLE in Endgeräte geht.

Bluetooth von Grund auf neu zu implementieren ist ein komplexes Unterfangen, für die meisten IoT-Anwendungen jedoch nicht notwendig. Es gibt zahlreiche Lösungen, die eine Bluetooth- und BLE-Integration ermöglichen. Der Schlüssel besteht in der Auswahl einer Lösung, welche die Anforderungen einer Anwendung am besten erfüllt.

Einer der Hauptgründe für die Wahl von BLE in IoT-Designs gegenüber herkömmlichem Bluetooth ist der geringere Stromverbrauch. Die Entwickler von BLE erkannten, dass es ausreicht, wenn typische Implementierungen nur kleine Pakete in weit voneinander entfernten Intervallen senden. Eine Verbindung wird nur für wenige Millisekunden aufgebaut, wobei Messungen mit einem Abstand von mindestens einer Sekunde vorgenommen werden. BLE spart Energie, indem es der Schnittstelle und ihrer Steuerelektronik ermöglicht, in einen Energiesparmodus zu wechseln, wenn sie nicht auf eingehende Pakete warten muss. Herkömmliche Bluetooth-Transceiver bleiben während dieser ruhigen Perioden oft aktiv, um Keep-Alive-Nachrichten erhalten zu können. Der Ruhemodus ist dynamisch. Wenn eine aktive Phase nicht zur Übertragung von Anwendungsdaten führt, kann das Protokoll die Ruhezeit verlängern.

Abb.1 Bild von Texas Instruments

Da die Empfangs- und Sendeleistung typischerweise zwischen 10 mA und 30 mA liegt, bedeutet eine lange Ruhezeit, dass BLE-Transceiver und ihre Host-MCUs auf Geräten arbeiten können, die mit Stromquellen wie Lithium-Knopfzellen betrieben werden. BLE reduziert die Energiebelastung weiter, indem es die Anzahl der Kanäle einschränkt, auf denen ein Transceiver die Geräterkennung durchführen muss – drei im Vergleich zu 32 bei herkömmlichem Bluetooth. Dies beschleunigt die Suche mit weitaus weniger Suchvorgängen.

Entwickler von IoT-Anwendungen können einen dedizierten BLE-Schnittstellen-IC, eine Modulebene-Lösung oder eine integrierte MCU mit integrierter BLE-Unterstützung verwenden. Jede dieser Optionen hat Auswirkungen auf das Projekt, z. B. auf die Markteinführungszeit und den Formfaktor.

HF-Antennenoptionen

Die Auswahl der Antenne ist ein wichtiger Faktor. Ein effektives Antennendesign ist erforderlich, um sicherzustellen, dass das Endprodukt die Benutzeranforderungen hinsichtlich Reichweite und Leistungseffizienz sowie der Einhaltung regionaler Standards erfüllt, die störende HF-Emissionen verhindern sollen.

Eine modulbasierte Bluetooth-Implementierung, wie das RN4020 von Microchip Technology oder das PAN1760A von Panasonic, hat mit Blick auf die Markteinführungszeit den Vorteil, dass die Antenne direkt in das Modul integriert werden kann. Dies reduziert die Design- und Testzeit erheblich. Die Modulimplementierer sind sehr darauf bedacht, das Antennendesign zu optimieren, um sicherzustellen, dass es über eine große Reichweite sowie einen hohen Wirkungsgrad verfügt.

Die Verwendung eines Moduls kann jedoch Einschränkungen für das Design der Basisplatine und des Gehäuses mit sich bringen, die nicht für die Endanwendung geeignet sind. Das gilt insbesondere dann, wenn spezielle Anforderungen an das Gerät gestellt werden. Zum Beispiel sollte ein Wearable ein Gehäuse verwenden, das für den Benutzer angenehm zu tragen ist. Oft integrierten diese Geräte die Antenne in das Gehäusedesign, welches eine maßgeschneiderte Lösung erfordert. In diesem Fall ist ein dedizierter Bluetooth-Transceiver-IC erforderlich, der für die Arbeit mit einer benutzerdefinierten Antenne ausgelegt ist. Platzbeschränkungen sprechen für den Einsatz eines zentralen Bluetooth-fähigen SoC, der Anwendungs- und Kommunikationsfunktionen ausführt. Wenn das Ziel darin besteht, Bluetooth zu einer bestehenden Produktlinie hinzuzufügen, für die bereits eine umfangreiche Firmware-Basis entwickelt wurde, ist die integrierte SoC-Lösung möglicherweise keine praktikable Option.

Protokollunterstützung

Ein wichtiger Vorteil eines Bluetooth-Moduls oder eines dedizierten Transceivers besteht darin, dass die meisten Kommunikationsfunktionen von der Host-CPU ausgelagert werden können. Die BLE-ICs der Baureihe Kinetis KW35/36 von NXP enthalten einen ARM Cortex-M0+-Prozessorkern mit 48 MHz, um das Bluetooth-Protokollstack zusätzlich zu den CAN-FD- und LIN-Standards in der Karosserieelektronik zu verarbeiten. Dieser Prozessorkern ist so leistungsfähig, dass er neben dem BLE-Protokoll auch andere Anwendungen ausführen kann. So lässt er sich sowohl als kompletter SoC als auch als Smart-Transceiver einsetzen. Typische Anwendungsfälle für den KW35/36 sind Keyless Entry und die Überwachung des Reifenzustands. Das Gerät unterstützt bis zu acht parallele sichere Verbindungen. Das Modul der Baureihe PAN1760A von Panasonic, das Filterelektronik und eine Antenne für eine einfache Integration kombiniert, basiert auf dem Transceiver der Baureihe CC2540 von Texas Instruments. Die Protokoll-Stack-Verarbeitung wird von einem integrierten 8051-Prozessorkern durchgeführt. Das RN4020 von Microchip Technology kann als BLE-Modul für ein größeres System eingesetzt werden oder unter Verwendung von scriptfähiger Firmware, die auf dem PIC24-Prozessorkern ausgeführt wird, unabhängig arbeiten und sowohl das Protokoll-Stack als auch die Endanwendung unterstützen.

Abb.2 Bild von Panasonic

Eine höhere Leistung zur Unterstützung von Hochleistungsanwendungen, die BLE-Konnektivität erfordern, ist auf Geräten wie dem nRF52832 von Nordic Semiconductor mit einem ARM Cortex-M4F-Kern, 512 KB Flash-Speicher und 64 KB RAM verfügbar.

BLE-SoCs und -Module bieten verschiedene Möglichkeiten zur Integration des Wireless-Protokolls in eine Anwendung. Das RN4020 von Microchip bietet einen skriptfähigen Modus zur Unterstützung von einer schnellen Prototypenerstellung und zur Implementierung von BLE-fähigen Anwendungen. Die Skriptsprache kann zum Erstellen von Anwendungen verwendet werden, die Sensordaten lesen und die Informationen über eine Bluetooth-Verbindung an ein gekoppeltes Gerät weitergeben.

Innerhalb des BLE-Stacks

In den meisten Fällen wird ein integrierter SoC mit BLE-Unterstützung Firmware-Bibliotheken bereitstellen, die Zugriff auf die Funktionen des Protokoll-Stacks bieten. Das BLE-Stack selbst ist in mehrere Schichten und Bauelemente unterteilt, die auf einem Echtzeitbetriebssystem (RTOS) implementiert werden können, welches von einem Hersteller, durch eine kundenspezifische Lösung oder von einem Drittanbieter bereitgestellt werden kann. Das Stack kommuniziert häufig über Semaphore, Flags und Callback-Funktionen mit dem RTOS. Es kann etwas aufwändig sein, die Funktionsaufrufe vom BLE-Stack eines Anbieters dem zugrunde liegenden Kernel zuzuordnen, wenn ein benutzerdefiniertes ROTS oder das eines Drittanbieters verwendet wird. Schlüsselelemente des BLE-Stacks sind das Generic Access Profile (GAP), das Generic Attribute Profile (GATT) und der Security Manager (SM).

Abb.3 Bluetooth-Stack, der das GAP-Modul (Generic Access Profile) markiert – Bild von Microchip

Das GAP führt eine Reihe von Aufgaben aus, einschließlich das Übertragen von Daten, ohne zuerst Punkt-zu-Punkt-Verbindungen aufzubauen, die Erkennung von Geräten in der Nähe und das Einrichten und Abbauen von Verbindungen zwischen Peers, die gekoppelt wurden. Das GATT übernimmt die Aufgabe, Daten von gekoppelten Peers zu senden und zu empfangen. Pakete, die vom GATT gesendet werden, können so konfiguriert werden, dass sie eine Antwort anfordern, um eine korrekte Zustellung sicherzustellen. Alternativ können sie dahingehend konfiguriert werden, dass keine Bestätigung erwartet wird.

Die Daten, die unter Verwendung der GATT-Layer gesendet werden, passen oft in einen der Bluetooth-Standards vieler anwendungsspezifischer Profile. Durch die Verwendung dieser Profile anstelle von benutzerdefinierten Paketformaten können IoT-Knotenanbieter die Interoperabilität mit einer Vielzahl von Peer-Geräten sicherstellen, z. B. medizinische Sensorknoten, die Blutdruck und Herzfrequenz melden, oder Gebäudeautomatisierungssysteme, die Umweltdaten übermitteln.

Der SM implementiert die Funktionen, die benötigt werden, um Geräte sicher zu koppeln und anschließend geschützte Nachrichten zu senden. Zudem umfasst der SM Funktionen zum Austausch von Kodierungsschlüsseln und zur Verschlüsselung von Daten vor der Übertragung. Letzteres spielt in IoT-Designs eine zunehmend wichtige Rolle. Sicherheit wird für viele IoT-Entwickler immer wichtiger. Neben der Verschlüsselung von Flugdaten ist es wichtig, dass Systeme gegen Angriffsvektoren wie BlueBorne resistent gemacht werden. Dies kann es erforderlich machen, eine einfache Benutzerschnittstelle auf das Gerät zu legen, damit ein Installateur während der Inbetriebnahme einen sicheren Code eingeben kann. Alternativ kann ein zusätzlicher HF-Kanal wie NFC die erforderliche Authentifizierung von einem Mobiltelefon bereitstellen, auf dem eine entsprechende App oder ein benutzerdefiniertes Hardwaretool zur Installation und Inbetriebnahme läuft.

Wichtige Überlegungen bei der Auswahl der API

Die Entscheidung, ob die Bluetooth-Schnittstelle innerhalb der Host-MCU oder separat ausgeführt wird, beeinflusst die Struktur der Software. Häufig bieten Anbieter jedoch Tools an, mit denen sie von einer Lösung zur nächsten wechseln können, falls Änderungen in Anwendungen dies erfordern. Wenn die Anwendung auf einer eigenständigen Bluetooth-fähigen MCU basiert, wird normalerweise über C-Funktionsaufrufe auf das Stack zugegriffen. Als externer Smart-Transceiver-IC kann auf die gleichen API-Funktionen in einem Co-Prozessormodus über eine serielle Schnittstelle, wie z. B. eine UART, zugegriffen werden. Das serielle Protokoll kann auf AT-Befehlen basieren, die denen ähnlich sind, die ursprünglich für einfache Modems oder für ein benutzerdefiniertes Protokoll verwendet wurden. Serielle Protokolle übertragen Befehle vom Host zum Bluetooth-Stack und Antworten und Ereignisse vom Bluetooth-Stack zurück an den Host.

Andere Tools, welche die Erstellung von Profilen unterstützen, können Compiler umfassen, die für die Eingabe XML-Dateien verwenden. Diese definieren die Messaging-Anforderungen der Anwendung und konvertieren sie in C-Code- und Header-Dateien. Dies erleichtert das Senden von Daten wie Blutdruckmesswerten, die in Standard-Bluetooth-Profile passen.

Multicore-IoT-Knoten-Implementierungen, z. B. solche, die ein separates Bluetooth-Transceiver-IC oder -Modul verwenden, können den Energieverbrauch durch eine Koordinierung der Ruhezyklen optimieren. Mit einem intelligenten Transceiver muss die Host-CPU nicht aktiv bleiben, während die HF-Kommunikation stattfindet. Sobald ein Befehl zum Senden von Daten ausgegeben und das Paket in einem geeigneten Puffer abgelegt wurde, kann die Host-CPU in einen Energiesparmodus fahren, während die Übertragung oder der Empfang stattfindet.

Ein intelligenter Transceiver kann eingehende Pakete auf deren Inhalt überwachen und sicherstellen, dass nur solche mit wichtigen Daten für die Host-CPU dafür sorgen, dass diese zur Verarbeitung aufwacht. Broadcast-Nachrichten, die nur die Netzwerkverwaltung betreffen, können vom eigenen Prozessor des Bluetooth-Transceivers verarbeitet werden. Dadurch lassen sich Funktionen wie Paketweiterleitung in einem Bluetooth 5.0-Mesh-Netzwerk ohne Störung der Host-CPU ausführen. Nachrichten, die den IoT-Knoten betreffen, jedoch eine niedrige Priorität aufweisen, wie z. B. Aktualisierungen des Serverstatus, können lokal gepuffert werden. Die Host-CPU muss nur aktiviert werden, um den Puffer zu leeren, oder wenn ein besonders wichtiger Befehl von einem Server empfangen wird. Um diese Funktionalität zu implementieren, muss ein Software-Zustandsautomat, der eingehende Daten interpretiert, auf die Kern-Bluetooth-Firmware geschrieben werden, die für die CPU des Transceivers bereitgestellt wird.

Da ein BLE-Transceiver aktiv bleiben muss, um auf eingehende Pakete zu warten, kann dies zu einem erhöhten Energieverbrauch führen. Ein typisches Szenario ist, wenn die GATT-Layer ein Paket sendet, das eine Antwort vom Empfänger erfordert. In diesem Fall kann der Knoten nicht in den Ruhemodus schalten, bis diese Bestätigung empfangen wird oder die Transaktion abläuft. Dringende Pakete, die unternehmenskritisch sind, müssen solche Bestätigungen verwenden. Es werden jedoch viele Datenelemente gesendet, die nicht sofort bestätigt werden müssen. Stattdessen kann die Garantie der Zustellung durch Protokolle auf Anwendungsebene durchgeführt werden. So kann ein benutzerdefiniertes Protokoll mit der Gegenstelle synchronisiert werden, wenn es als nächstes unter Verwendung von Paketfolgenummern oder -codes aktiviert wird. Dies ermöglicht es dem Knoten, in den Ruhemodus zu gehen, sobald er das letzte Aktualisierungspaket innerhalb des aktuellen Wach-Schlaf-Zyklus gesendet hat. Der von BLE verwendete Sniff-Subrating-Modus synchronisiert die beiden Endpunkte, so dass ein Master die Daten bis zum nächsten Aufwach- oder Sniff-Zeitraum festhält.

Zusammenfassung

Mit intelligenten Modulen und Transceivern, die von umfangreichen Firmware-Bibliotheken unterstützt werden, haben Hersteller das Ziel erreicht, BLE für praktisch alle IoT-Designs zugänglich zu machen. Welche Lösung für ein bestimmtes Design am besten geeignet ist, hängt von den Anforderungen und Anwendungszielen ab. Die große Auswahl an Optionen bedeutet jedoch, dass es für nahezu jeden Anwendungsfall eine Lösung geben sollte.

Verwandte Artikel

http://de.farnell.com/the-bluetooth-evolution

http://de.farnell.com/iot-security-part-4-bluetooth-battle-with-the-hackers-heats-up

http://de.farnell.com/bluetooth-smart-for-wearables-and-iot