Auf der Überholspur zum Bluetooth-5-Maschennetzwerk

Mit der Verfügbarkeit von Maschennetzwerkfunktionen für Bluetooth 5 können Entwickler die Reichweite und Netzwerkverfügbarkeit von drahtlos verbundenen Systemen (z.B. IoT-Geräte) verbessern. Allerdings bringen Maschennetzwerke weitere Stufen an Komplexität ins Spiel, angefangen bei der Konzeption drahtloser energiesparender Hardware bis hin zur Entwicklung von Software für das Maschennetzwerk, in denen sich Entwickler leicht verstricken können und die Projektplanungen schnell zur Makulatur werden lassen.

Mit der Einführung von Bluetooth-5-fähigen Smartphones und anderen mobilen Plattformen wird die Zeit zu einem entscheidenden Faktor: Entwickler müssen schnell auf die zu erwartende Explosion der Nachfrage nach Maschennetzwerken für Bluetooth in fast jeder Branche und Anwendung reagieren. Andererseits stellen Komponenten- und Softwareanbieter immer mehr Lösungen vor, mit denen sich der Entwicklungsprozess vereinfachen und beschleunigen lässt.

In diesem Artikel soll es zunächst um die logische Grundlage für Maschennetzwerke für Bluetooth gehen. Anschließend folgt eine schrittweise Erläuterung des Entwicklungsprozesses, wozu eine konkrete Komponente aus den maschennetzwerkfähigen Bluetooth-5-Modulen von Silicon Labs als Beispiel verwendet wird. Mithilfe einer solchen integrierten Bluetooth-5-Lösung können Entwickler schnell vernetzte Geräte und Anwendungen bereitstellen, mit denen sich die Vorteile des Bluetooth-Maschennetzwerks optimal nutzen lassen.

Der Artikel schließt mit einer Beschreibung des Softwareentwicklungspakets für Bluetooth-Maschennetzwerke, einschließlich einer detaillierten Betrachtung des ereignisgesteuerten Modells, das anhand von Beispielen für Anwendungscode für Maschennetze veranschaulicht wird.

Die Nachfrage nach Bluetooth Mesh

Bluetooth Mesh übersteigt bei Weitem die Punkt-zu-Punkt-Verbindungsfähigkeiten herkömmlicher Bluetooth-Technologie. Indem Nachrichten über benachbarte vernetzte Geräte weitergeleitet werden, erweitert Bluetooth Mesh die effektive Reichweite von energiesparenden Geräten über deren eigentliche Reichweite hinaus, die sich aus ihrer Sendeleistung und Empfängerempfindlichkeit ergibt. Am wichtigsten ist, dass sich Bluetooth Mesh die allgemeine Vertrautheit mit Bluetooth-fähigen Apps auf Smartphones und anderen Mobilgeräten zunutze macht und damit eine natürliche Weiterentwicklung in Richtung anspruchsvollerer Anwendungen mit Maschenvernetzung darstellt.

Dank der Unterstützung von Maschennetzwerken stehen Entwicklern mit Bluetooth jetzt leistungsfähige Optionen zur Verfügung, um ganz einfach eine große Anzahl von Geräten in den Bereichen Home Automation, Gebäudemanagement und einer beliebigen Anzahl von IoT-Anwendungen miteinander zu vernetzen.

Wie Bluetooth Mesh funktioniert

Bluetooth Mesh baut auf einem konzeptionell einfachen Modell auf: auf der Interaktion zwischen Knoten in einem Netzwerk (Abbildung 1). Spezielle Knotentypen verfügen dabei über zusätzliche Funktionen, die für die Weiterleitung von Mitteilungen zwischen den Knoten benötigt werden. Sie erweitern somit die effektive Reichweite eines Netzwerks, das über einen Proxy-Knoten mit einem Bluetooth-fähigen Mobilgerät interagiert.

Abbildung 1: Neben den grundlegenden Randknoten kommen in einem Maschennetzwerk spezielle Knotentypen zum Einsatz: Sie leiten Nachrichten an andere Knoten weiter (Relay), dienen als Zwischenspeicher (Friend) für energiesparende Knoten oder verbinden das Netzwerk (Proxy) mit einem Bluetooth-fähigen Mobilgerät. (Bildquelle: Silicon Labs)

Andere spezialisierte Knotentypen sind speziell auf Anforderungen zur Senkung des Stromverbrauchs hin konzipiert. Sie nutzen Friend-Knoten zur Zwischenspeicherung von Nachrichten, die von energiesparenden Knoten zwischen längeren Phasen im Schlafmodus regelmäßig abgefragt werden. Ungeachtet dieser neuen Zusatzfunktionen können Bluetooth-Mesh-Geräte weiterhin GATT-Dienste (Generic Attribute Profile) nutzen, um die Vernetzung mit älteren Geräten zu gewährleisten, die mit früheren Bluetooth-Versionen arbeiten. Damit können Maschengeräte im vollen Umfang die Vorteile der bestehenden BLE-Möglichkeiten (Bluetooth Low Energy) nutzen, wie etwa Beacons zur Generierung gebietsspezifischer Nachrichten an Smartphones oder die Eigenidentifizierung gegenüber Asset-Management-Anwendungen.

Bluetooth Mesh wird auch der wachsenden Sorge um die Sicherheit in geschützten Netzwerken gerecht – ein Grundbedürfnis in der Gebäudeautomatisierung oder anderen IoT-Anwendungen. Im Gegensatz zu BLE, wo die Sicherheit optional ist und dem Schutz eines einzelnen Geräts dient, basiert das Sicherheitskonzept von Bluetooth Mesh darauf, das Maschennetzwerk insgesamt zu schützen.

Insbesondere dieser Ansatz für die Maschensicherheit ist interessant. Es beruht auf einem Konzept der klaren Trennung in mehrere Problembereiche des Maschennetzwerks. Dabei werden getrennte Sicherheitsmaßnahmen für jedes Gerät, das Netzwerk und die gesamte Anwendung implementiert. Ein privater Geräteschlüssel (DevKey), der jedem Gerät zugeordnet ist, sorgt für die Sicherheit bei Operationen wie etwa Konfiguration und Bereitstellung, an denen nur dieser Knoten allein beteiligt ist. Für die Kommunikation mit anderen Knoten in einem Netzwerk oder Teilnetzwerk benötigt jedes Gerät einen Netzwerkschlüssel (NetKey). Und für Interaktionen auf Anwendungsebene, etwa zum Senden einer Nachricht zum Einschalten eines Lichts, ist schließlich ein Anwendungsschlüssel (AppKey) erforderlich. Weitere Sicherheitsmaßnahmen dienen dem Schutz vor allgemeinen Bedrohungen wie z. B. Man-in-the-Middle- oder Replay-Angriffen. In Kombination miteinander bilden die Sicherheitsmechanismen in Bluetooth Mesh eine wichtige Vertrauensbasis – die Voraussetzung für anspruchsvollere IoT-Anwendungen.

Trotzdem stellt die Implementierung einer per Bluetooth-Mesh vernetzten Anwendung die Entwickler vor erhebliche Schwierigkeiten. Die meisten Anwendungen für Maschennetzwerke basieren auf energieeffizienten Geräten, die sich das Maschennetzwerk zu eigen machen, um die effektive Reichweite von energiesparenden Funksubsystemen zu erweitern. Die Herausforderungen bei der Konzeption von maschennetzwerkfähigen energiesparenden Hardwaregeräten sind selbst für erfahrene Hardwareentwickler nicht zu unterschätzen. Auch nach Fertigstellung ihrer benutzerdefinierten Bluetooth-Designs können bei den Entwicklern durch die Einhaltung nationaler Zertifizierungsanforderungen erhebliche Kosten und langwierige Verzögerungen entstehen. Die Softwareentwickler erleben ihre eigenen spezifischen Verzögerungen: bei der Suche nach kompatiblen Bluetooth-Mesh-Stacks und deren Einsatz zum Aufbau von Softwareschichten zur Unterstützung ihrer eigenen Anwendungen. Dank der Bluetooth-Hardware und -Software von Silicon Laboratories können Entwickler jedoch die Bluetooth-Mesh-Funktionalität in energiesparenden Geräten für ihre eigenen Anwendungen schneller bereitstellen.

Das Bluetooth-Modul

Die Bluetooth-Mesh-Lösung von Silicon Labs baut auf dem eigenen energiesparenden Bluetooth-Modul BGM13P auf. Dieses Modul bietet die Kombination aus einem Funk-Prozessor und einem vollständigen Bluetooth-Stack und ermöglicht damit ein vollständiges, zertifiziertes Bluetooth-System in einem nur 12,9 × 15,0 × 2,2 mm großen Gehäuse. Herzstück des Moduls ist ein EFR32BG13 Blue Gecko-Drahtlos-SoC (System-on-Chip), das für die Kernfunktionen verantwortlich ist. Das SoC des EFR32BG13 vereint einen 32-Bit-ARM®-Cortex®-M4-Core, ein 2,4-GHz-Funktsubsystem, 512 KByte an Flash und 64 KByte an RAM sowie eine umfangreiche Palette an analogen und digitalen Peripherieeinrichtungen. Zusammen mit einem On-Chip-Hardware-Crypto-Beschleuniger wird das SoC der wachsenden Nachfrage nach mehr Sicherheit gerecht: mit einer Security-Management-Einheit, welche dieselbe fein abgestufte Zugriffssteuerung auf Peripherieeinrichtungen ermöglicht wie die Memory-Protection-Einheit auf den Speicher.

Das EFR32BG13-SoC kann als Grundlage für benutzerdefinierte Bluetooth-Hardwaredesigns dienen. Mit Verwendung des SoC übernehmen Entwickler nicht nur die Verantwortung für Designanforderungen wie die Schaltung zur SoC-Unterstützung, sondern auch für die erforderliche Zertifizierung des fertigen Designs. Das Modul liefert ein vollständig zertifiziertes Design, einschließlich des EFR32BG13 samt der erforderlichen Unterstützungsschaltungen und mehreren Oszillatorquellen, zwei Quarzen und Porttreibern. Gleichzeitig werden mit dem Modul eine Reihe von Energiesparfunktionen bereitgestellt. Sie ermöglichen es Entwicklern, der wachsenden Nachfrage nach energiesparenden Geräten gerecht zu werden.

Das Modul verbraucht im aktiven Modus nur 87 Mikroampere (µA) pro MHz und im Tiefschlafmodus lediglich 1,4 μA bei vollständiger RAM-Erhaltung. Um die Zeit zu maximieren, die das Modul in diesem energiesparenden Tiefschlafmodus verbringt, stehen Entwicklern besondere Funktionen zur Verfügung, etwa eine Sensorschnittstelle mit geringer Leistungsaufnahme und ein energiesparender Timer. Die Sensorschnittstelle mit geringer Leistungsaufnahme ermöglicht es Ingenieuren, die in das Modul integrierte Finite-State-Maschine und die analogen Peripheriegeräte so zu programmieren, dass Sensorsignale erfasst und verarbeitet werden können, obwohl der Prozessor im Tiefschlafmodus verbleibt. Mit dem energiesparenden Timer können Ingenieure einfache Wellenformen ausgeben und die Echtzeituhr bzw. den Echtzeitzähler überwachen lassen, um in vorgegebenen Zeitabständen Aktionen ausführen zu lassen, ohne dazu den Prozessor zu beanspruchen.

Natürlich hängt der Stromverbrauch drahtloser Geräte ganz allgemein von der Effizienz des Funksubsystems ab. Hier verbraucht das 2,4-GHz-Funksubsystem des Moduls gerade einmal 9,9 Milliampere (mA) im Empfangsmodus und 8,5 mA im Sendemodus bei 0 dBm Ausgangsleistung. Trotzdem bietet das Modul noch eine zusätzliche Funktion, mit der sich durch HF-Steuerung weitere Energieeinsparung erzielen lässt. Entwickler können eine HF-Sensorfunktion in dem Modul so programmieren, dass der Prozessor aufgeweckt wird, wenn Breitband-HF-Energie erkannt wird. Mit diesem Ansatz können Entwickler das Modul in Inaktivitätsperioden im Tiefschlafmodus halten, ohne dass es zu Kommunikationsverlusten kommt. Wie bereits erwähnt, können Entwickler ein Gerät auch so konfigurieren, dass es als energiesparender Bluetooth-5-Knoten agiert, der einfach nur regelmäßig aus dem Tiefschlaf geweckt wird, um einen Friend-Knoten auf zwischengespeicherte Nachrichten abzufragen.

Systementwicklung

Alle diese Funktionen des Moduls lassen sich ohne große Schwierigkeiten implementieren. Entwickler können das Modul einfach in ein Design mit vorhandenem Prozessor einsetzen, um es als Bluetooth-Netzwerk-Coprozessor zu nutzen (Abbildung 2A). Alternativ kann das Modul auch als komplette Systemlösung eingesetzt werden (Abbildung 2B). In diesem Standalone-Modus können Entwickler ihren Anwendungscode auf dem EFR32BG13-Prozessor des Moduls ausführen und die integrierten analogen und digitalen Peripheriegeräte des EFR32BG13 zur Signalerfassung in einem einfachen IoT-Design verwenden.

Abbildung 2: Designer können das BGM13P-Modul als Bluetooth-Coprozessor für eine Host-CPU (A) oder als eigenständiges System (B) einsetzen. Dazu steht ihnen das integrierte SoC des EFR32BG13 zur Ausführung von Anwendungscode und sogar zur Erfassung von Sensordaten zur Verfügung. (Bildquelle: Silicon Labs)

Eine weitere Vereinfachung des Bluetooth-Designs kann mit dem BGM13P22F512GA-V2 erzielt werden – einer Modulversion mit integrierter Antenne. Für Designs, die für eine anspruchsvollere HF-Umgebung angedacht sind, steht Entwicklern der BGM13P22F512GE-V2 zur Verfügung. Diese Version bietet einen U.FL-Steckverbinder zum Anschluss einer Bluetooth-kompatiblen Flat-Patch-Antenne, zum Beispiel der FXP74.07.0100A von Taoglas.

Mit seinem SLWSTK6101C-Entwicklungskit umgeht Silicon Labs selbst diesen Schritt der Hardwareimplementierung. Das SLWSTK6101C wurde speziell für die Zusammenarbeit mit Steckplatinen für die verschiedenen Bluetooth-Komponenten von Silicon Labs entwickelt und bietet ein repräsentatives IoT-Design mit einem 8-Mbit-Flash des Typs MX25R8035F von Macronix, ein 128-x-128-LCD des Typs LS013B7DH03 von Sharp Microelectronics sowie den Si7021-Temperatur- und Feuchtigkeitssensor von Silicon Labs. In diesem Fall stecken Entwickler einfach nur die SLWRB4306A-Drahtlosfunkplatine ein, wodurch das BGM13P-Modul mit der SLWSTK6101C-Platine integriert wird.

Dieses Platinen-Komplettset ist nicht nur ein bereits serienreifes Design, sondern bietet gleichzeitig ein bewährtes Referenzdesign, das Ingenieure einsetzen können, um verschiedene Ansätze für die Anbindung von Geräten wie etwa den Flash, das LCD oder den Sensor zu erproben.

Wenn zum Beispiel der 8-Mbit-Flash und das LCD mit dem Modul verbunden sind (über dessen SPI-Bus), teilt sich die I²C-Schnittstelle des Si7021-Sensors den Bus mit einem externen Header auf der Entwicklungsplatine. Silicon Labs präsentiert damit eine Methode zum Aufbau einer einfachen Schnittstelle, die dafür sorgt, dass der Sensor im Normalfall deaktiviert und von diesem gemeinsam verwendeten Bus elektrisch isoliert bleibt. Beim Anstieg des PD15-Moduleingangs steigt der SENSOR_ENABLE-Ausgang an, wodurch der Sensor mit der 3,3-V-VMCU-Stromschiene und dem I²C-Bus verbunden wird (Abbildung 3).

Abbildung 3: Mit seinem SLWSTK6101C-Entwicklungskit stellt Silicon Labs nicht nur eine Hardware-Evaluierungsplattform bereit, sondern liefert auch ein Referenzdesign zur Anbindung eines externen Geräts, wie etwa des hier dargestellten Si7021-Sensors von Silicon Labs. (Bildquelle: Silicon Labs)

Der gemeinsam verwendete I²C-Bus-Header ist nur eine von mehreren Funktionen, mit der diese Plattform Entwickler unterstützt (Abbildung 4). Neben einem integrierten J-Link-Debugger bietet die Platine auch eine Packet-Trace-Schnittstelle (PTI), mit der Ingenieure Pakete detailliert analysieren können. Die PTI baut auf einer in das EFR32BG13-SoC integrierten Paket- und Statusverfolgungseinheit auf und ermöglicht die nicht intrusive Erfassung sämtlicher vom System gesendeten und empfangenen Pakete. Zur Analyse komplexer Protokolle wie etwa Bluetooth Mesh bietet diese Paketverfolgungsfunktion ein Tool, das für die Optimierung und das Tuning der Low-Level-Netzwerkkommunikation entscheidend sein kann.

Abbildung 4: Das SLWSTK6101C-Kit von Silicon Labs bietet mehrere Schnittstellen für Paketverfolgung, Energieüberwachung und die ETM-Verfolgung (Embedded Trace Macrocell) auf niedriger Ebene im Arm-Prozessor. Damit steht Ingenieuren eine ganze Palette an Tools zur gründlichen Analyse von Designbetrieb und -leistung zur Verfügung. (Bildquelle: Silicon Labs)

Während Netzwerkexperten Funktionen wie die PTI zur Netzwerkoptimierung benötigen, brauchen Systementwickler Tools, mit denen sie mögliche Ineffizienzen in der Anwendung aufspüren können, die zu erhöhtem Energieverbrauch führen würden. Für diese Art der Energieoptimierung auf Anwendungsebene bietet Silicon Labs seinen Energy Profiler von Simplicity Studio, mit dem die Analyse des Energieverbrauchs auf Code-Ebene möglich ist.

Dieser Energy Profiler nutzt wie schon das Paketverfolgungstool die zugrunde liegende Hardware. In diesem Fall umfasst die Platine eine dedizierte Energieüberwachungsschaltung, bestehend aus einem Strommesswiderstand, einem Strommessverstärker und Verstärkerstufen, deren Ausgänge in den Controller der Platine gehen und dort einem Entwicklungs-Hostsystem zur Verfügung stehen (Abbildung 5). Parallele Verstärkerstufen ermöglichen dem Energiemonitor die Messung von Strömen von 0,1 μA bis 95 mA mit zwei verschiedenen Auflösungsstufen: 0,1 mA Auflösung über 250 μA und 1 μA Auflösung unterhalb der 250-μA-Schwelle.

Abbildung 5: Eine dedizierte Energieüberwachungsschaltung und ein Verarbeitungscontroller, die in das BGM13P-Bluetooth-Modul integriert sind, ermöglichen eine nicht invasive Strommessung von 0,1 μA bis 95 mA. (Bildquelle: Silicon Labs)

Während die Energieüberwachungsschaltung Strommessungen liefert, können die in das EFR32BG13 integrierten Low-Level-Verfolgungsmechanismen den Programmzähler des Prozessors in regelmäßigen Abständen abtasten und die Ergebnisse über den seriellen Kabelausgangspin der Komponente ausgeben. Durch die Kombination der Energieüberwachungsergebnisse mit der Ausgabe dieser Programmverfolgung kann der Energy Profiler eine Echtzeitanzeige des Energieverbrauchs in Bezug auf den aktuell auf dem Gerät ausgeführten Code liefern (Abbildung 6).

Abbildung 6: Der Energy Profiler von Simplicity Studio kombiniert die Ausgabe der Energieüberwachung mit Programmverfolgungsdaten und liefert eine Echtzeitanzeige des Energieverbrauchs bezogen auf den jeweils ausgeführten Code. (Bildquelle: Silicon Labs)

Entwicklung von Anwendungen für Maschennetzwerke

Während Hardwareentwickler das Entwicklungskit zur Optimierung ihrer Hardwaredesigns einsetzen können, steht Softwareentwicklern die umfangreiche Software-Entwicklungsumgebung von Silicon Labs zur Verfügung, um schnell maschennetzwerkfähige Anwendungen zu entwickeln. Der mit Simplicity Studio bereitgestellte Bluetooth-5-Mesh-Stack von Silicon Labs erweitert den Bluetooth-Basis-Stack um spezifische Ressourcen für Maschennetzwerke. Damit können Entwickler problemlos von herkömmlichen Bluetooth-Protokollen wie Beacon oder Punkt-zu-Punkt-Kommunikation auf vollständige Maschentopologien umsteigen (Abbildung 7).

Abbildung 7: Der Bluetooth-Mesh-Stack von Silicon Labs erweitert die bisherigen Bluetooth-Funktionen (blau) um Maschenebenen (grün), was Entwickler in die Lage versetzt, die gesamte Bandbreite der Bluetooth-Funktionen zu nutzen: von Beacon bis hin zu vollständigen Maschenkonfigurationen. (Bildquelle: Silicon Labs)

In Verbindung mit den auf dem BGM13P basierenden Entwicklungskarten SLWRB4306A und SLWSTK6101C von Silicon Labs ermöglicht Simplicity Studio Entwicklern die Konfiguration ihrer Umgebung mit den entsprechenden Software Development Kits (SDKs). Für die Bluetooth-Entwicklung bietet Simplicity Studio das Bluetooth-Mesh-SDK von Silicon Labs in Verbindung mit vorgefertigten Demo-Binärdateien und Quellcode. In dieser Umgebung können Entwickler mit Beispielcode arbeiten, mit dem sich eine komplette Bluetooth-Maschennetzwerkanwendung implementieren lässt.

Die Beispielanwendungen, die zur Veranschaulichung der Abläufe in einem Bluetooth-Maschennetzwerk entwickelt wurden, führen den Entwickler in Verbindung mit dem Entwicklungsboard und einer mobilen App schrittweise durch typische Abläufe im Maschennetzwerk, wozu Bereitstellung, Konfiguration und anwendungsbezogene Nutzung zählen. Zur Bereitstellung der Beispielanwendung setzen Ingenieure Simplicity Studio in Verbindung mit einer Reihe von getrennt konfigurierten Entwicklungskarten ein, die entsprechend ihrer Konfiguration als Licht oder Schalter in einer vernetzten Beleuchtungsanwendung dienen. Durch die Nutzung des Beispielcodes in Verbindung mit Hardware können Ingenieure ein besseres Verständnis von jeder Operationsphase einer typischen Maschennetzwerk-Anwendung erlangen, was mit dem Einschalten des Geräts beginnt.

Mit der Softwarearchitektur von Silicon Labs werden Bluetooth-Operationen nacheinander als eine Reihe von Ereignissen ausgeführt, unter Verwendung vordefinierter Ereignis-IDs, die den Charakter des jeweiligen Ereignisses angeben. In dem Beispielsoftwarepaket ruft die main()-Routine, die beim Einschalten oder Reset ausgeführt wird, einfach nur eine Reihe von Initialisierungsroutinen auf, bevor der Einstieg in ihre Hauptschleife erfolgt, die in diesem Fall aus lediglich zwei Codezeilen (Listing 1) besteht.

Kopieren
int main()
{
#ifdef FEATURE_SPI_FLASH
  /* Put the SPI flash into Deep Power Down mode for those radio boards where it is available */
  MX25_init();
  MX25_DP();
  /* We must disable SPI communication */
  USART_Reset(USART1);

#endif /* FEATURE_SPI_FLASH */

  enter_DefaultMode_from_RESET();

#if (EMBER_AF_BOARD_TYPE == BRD4304A)
  LNA_init();
#endif

  gecko_init(&config);

#ifdef FEATURE_PTI_SUPPORT
  APP_ConfigEnablePti();
#endif // FEATURE_PTI_SUPPORT

  RETARGET_SerialInit();

  /* initialize LEDs and buttons. Note: some radio boards share the same GPIO for button & LED.
   * Initialization is done in this order so that default configuration will be button for those
   * radio boards with shared pins. led_init() is called later as needed to (re)initialize the LEDs
   * */
  led_init();
  button_init();

  LCD_init();

  while (1) {
    struct gecko_cmd_packet *evt = gecko_wait_event();
    handle_gecko_event(BGLIB_MSG_ID(evt->header), evt);
  }
}

Listing 1: Simplicity Studio bietet eine umfassende Entwicklungsumgebung samt Beispielcode, wie diese Hauptroutine für eine Beleuchtungsanwendung im Maschennetzwerk. Sie veranschaulicht die Initialisierung und die Schleifen für die Ereignisbehandlung. (Codequelle: Silicon Labs)

In der ersten Zeile der Hauptschleife blockiert die Funktion gecko_wait_event() und wartet auf Ereignisse, die in einer Ereigniswarteschlange erscheinen, welche von unteren Ebenen bestückt wird. Obwohl Entwickler oftmals Blockierungsfunktionen vermeiden, ist dieser Ansatz in diesem Fall besonders effektiv, weil der Bluetooth-Stack in diesem blockierten Modus automatisch die energiesparenden Schlafmodi verwaltet. Für bestimmte Anwendungen, die keine blockierenden Wartezeiten tolerieren können, enthält das SDK auch eine nicht blockierende Funktion, welche das nächste Ereignis oder NULL zurückgibt, wenn die Warteschlange leer ist. Mit dieser Funktion müssen sich die Entwickler allerdings weiterhin mit der Verwaltung von energiesparenden Schlafmodi befassen.

In der zweiten Zeile der Hauptschleife verarbeitet die Handler-Funktion handle_gecko_event() das letzte Ereignis (evt) auf der Grundlage ihrer Ereignis-ID (Listing 2). Wenn ein Gerät eingeschaltet wird, gibt der Stack ein System-Boot-Ereignis (gecko_evt_system_boot_id) aus. Im Gegenzug ruft der Event-Handler eine Reihe von Initialisierungsfunktionen auf, einschließlich gecko_cmd_mesh_node_init(), wodurch der Bluetooth-Mesh-Stack initialisiert wird. Später ruft der Handler andere Funktionen auf, um die mit diesem Ereignistyp verknüpfte Funktionalität bereitzustellen, was durch die mit ihr verknüpfte Ereignis-ID angegeben wird.

Kopieren
/**
 * Handling of stack events. Both Bluetooth LE and Bluetooth mesh events are handled here.
 */
static void handle_gecko_event(uint32_t evt_id, struct gecko_cmd_packet *evt)
{
  struct gecko_bgapi_mesh_node_cmd_packet *node_evt;
  struct gecko_bgapi_mesh_generic_server_cmd_packet *server_evt;
  struct gecko_msg_mesh_node_provisioning_failed_evt_t  *prov_fail_evt;

  if (NULL == evt) {
    return;
  }

  switch (evt_id) {
    case gecko_evt_system_boot_id:
      // check pushbutton state at startup. If either PB0 or PB1 is held down then do factory reset
      if (GPIO_PinInGet(BSP_GPIO_PB0_PORT, BSP_GPIO_PB0_PIN) == 0 || GPIO_PinInGet(BSP_GPIO_PB1_PORT, BSP_GPIO_PB1_PIN) == 0) {
        initiate_factory_reset();
      } else {
        struct gecko_msg_system_get_bt_address_rsp_t *pAddr = gecko_cmd_system_get_bt_address();

        set_device_name(&pAddr->address);

        // Initialize Mesh stack in Node operation mode, wait for initialized event
        gecko_cmd_mesh_node_init();

        // re-initialize LEDs (needed for those radio board that share same GPIO for button/LED)
        led_init();
      }
      break;
      .
      .
      .
    case gecko_evt_mesh_node_initialized_id:
      printf(node initialized\r\n);

      struct gecko_msg_mesh_node_initialized_evt_t *pData = (struct gecko_msg_mesh_node_initialized_evt_t *)&(evt->data);

      if (pData->provisioned) {
      .
      .
      .
      } else {
        printf(node is unprovisioned\r\n);
        LCD_write(unprovisioned, LCD_ROW_STATUS);

        printf(starting unprovisioned beaconing...\r\n);
        gecko_cmd_mesh_node_start_unprov_beaconing(0x3);   // enable ADV and GATT provisioning bearer
      }
      break;

    case gecko_evt_mesh_node_provisioning_started_id:
      printf(Started provisioning\r\n);
      LCD_write(provisioning..., LCD_ROW_STATUS);
      // start timer for blinking LEDs to indicate which node is being provisioned
      gecko_cmd_hardware_set_soft_timer(32768 / 4, TIMER_ID_PROVISIONING, 0);
      break;

    case gecko_evt_mesh_node_provisioned_id:
      _my_index = 0;   // index of primary element hardcoded to zero in this example
      lightbulb_state_init();
      printf(node provisioned, got index=%x\r\n, _my_index);
      // stop LED blinking when provisioning complete
      gecko_cmd_hardware_set_soft_timer(0, TIMER_ID_PROVISIONING, 0);
      LED_set_state(LED_STATE_OFF);
      LCD_write(provisioned, LCD_ROW_STATUS);
      break;

    case gecko_evt_mesh_node_provisioning_failed_id:
      prov_fail_evt = (struct gecko_msg_mesh_node_provisioning_failed_evt_t  *)&(evt->data);
      printf(provisioning failed, code %x\r\n, prov_fail_evt->result);
      LCD_write(prov failed, LCD_ROW_STATUS);
      /* start a one-shot timer that will trigger soft reset after small delay */
      gecko_cmd_hardware_set_soft_timer(2 * 32768, TIMER_ID_RESTART, 1);
      break;
      .
      .
      .
  }
}

Listing 2: Entwickler können den Beispielcode für Maschennetzwerke von Silicon Labs auf wichtige Designmuster untersuchen, wie die Bereitstellung der Ereignisverarbeitung, die in diesem Snippet aus der handle_gecko_event() Event-Handler-Routine dargestellt ist, die in der Hauptroutine zur Beleuchtungsanwendung für Maschennetze aufgerufen wird (siehe Listing 1). (Codequelle: Silicon Labs)

Eine der wichtigsten Abfolgen von Ereignissen in einem Maschennetzwerk bezieht sich auf den Bereitstellungsprozess. Nachdem ein Gerät eingeschaltet wurde und seine Initialisierungssequenz abgeschlossen hat, geht es in den Beacon-Modus über und kündigt sich beim Netzwerk zur Bereitstellung an. Während die Bereitstellung mit dem Abschluss (oder dem Fehlschlagen) fortfährt, verwendet der Beispielcode das LCD und die LEDs des Entwicklungskits, um den Status anzuzeigen. Durch die Untersuchung des Event-Handler-Code-Blocks für jeden Bereitstellungsstatus können sich Entwickler schnell ein besseres Verständnis für diese Bereitstellungssequenz und deren Optionen verschaffen.

Ebenso können Softwareentwickler den Beispiel-Handler-Code als Leitfaden für die Erstellung eigener Funktionalität auf Anwendungsebene nutzen. Zum Beispiel ist ein zentrales Konzept beim Bluetooth-Maschennetzwerk die Verwendung eines Publish-Subscribe-Modells zur Zuordnung von Knoten, die gemeinsam eine bestimmte Funktionsbeziehung verwenden (Abbildung 8).

Abbildung 8: Anwendungsentwickler verwenden das Publish-Subscribe-Modell von Bluetooths, um Geräte in Funktionsgruppen zu kombinieren, wie eine Gruppe von Lichtern, die durch einen oder mehrere Schalter gesteuert werden. (Bildquelle: Silicon Labs)

Mit diesem Ansatz könnten mehrere intelligente Glühlampen einen Schalter-Publisher abonnieren. Wenn der Endbenutzer den Schalter aktiviert, würde der Schalter das ON/OFF-Ereignis veröffentlichen. Dieses Ereignis würde durch das Maschennetzwerk bis zu den abonnierten intelligenten Glühlampen kaskadiert werden, deren Ereignis-Handler die entsprechende Maßnahme ergreifen würden. Der Beispielcode von Silicon Labs veranschaulicht diesen Prozess – zunächst mit einer veröffentlichten ON/OFF-Anforderung in dem Maschenvernetzten Schalter (Listing 3) und dann mit einer entsprechenden Reaktion in der vernetzten Leuchte (Listing 4).

Kopieren
/**
 * This function publishes one on/off request to change the state of light(s) in the group.
 * Global variable switch_pos holds the latest desired light state, possible values are
 * switch_pos = 1 -> PB1 was pressed, turn lights on
 * switch_pos = 0 -> PB0 was pressed, turn lights off
 *
 * This application sends multiple requests for each button press to improve reliability.
 * Parameter retrans indicates whether this is the first request or a re-transmission.
 * The transaction ID is not incremented in case of a re-transmission.
 */
void send_onoff_request(int retrans)
{
  uint16 resp;
  uint16 delay;
  struct mesh_generic_request req;

  req.kind = mesh_generic_request_on_off;
  req.on_off = switch_pos ? MESH_GENERIC_ON_OFF_STATE_ON : MESH_GENERIC_ON_OFF_STATE_OFF;

  // increment transaction ID for each request, unless it's a retransmission
  if (retrans == 0) {
    trid++;
  }

  /* delay for the request is calculated so that the last request will have a zero delay and each
   * of the previous request have delay that increases in 50 ms steps. For example, when using three
   * on/off requests per button press the delays are set as 100, 50, 0 ms
   */
  delay = (request_count - 1) * 50;

  resp = gecko_cmd_mesh_generic_client_publish(
    MESH_GENERIC_ON_OFF_CLIENT_MODEL_ID,
    _my_index,
    trid,
    0,     // transition
    delay,
    0,     // flags
    mesh_generic_request_on_off,     // type
    1,     // param len
    &req.on_off     /// parameters data
    )->result;

  if (resp) {
    printf(gecko_cmd_mesh_generic_client_publish failed,code %x\r\n, resp);
  } else {
    printf(request sent, trid = %u, delay = %d\r\n, trid, delay);
  }
}

Listing 3: Dieses Snippet aus der Beispielschaltanwendung für Maschennetze von Silicon Labs veranschaulicht die Verwendung des Bluetooth-5-Veröffentlichungsprozesses (gecko_cmd_meshr_generic_client_publish) zur Anforderung einer Statusänderung (On oder Off) in einem Licht, das diesen Ereignisstrom abonniert hat. (Codequelle: Silicon Labs)

Kopieren
static void onoff_request(uint16_t model_id,
                          uint16_t element_index,
                          uint16_t client_addr,
                          uint16_t server_addr,
                          uint16_t appkey_index,
                          const struct mesh_generic_request *request,
                          uint32_t transition_ms,
                          uint16_t delay_ms,
                          uint8_t request_flags)
{
  printf(ON/OFF request: requested state=<%s>, transition=%u, delay=%u\r\n,
         request->on_off ? ON : OFF, transition_ms, delay_ms);

  if (lightbulb_state.onoff_current == request->on_off) {
    printf(Request for current state received; no op\n);
  } else {
    printf(Turning lightbulb <%s>\r\n, request->on_off ? ON : OFF);
    if (transition_ms == 0 && delay_ms == 0) { // Immediate change
      lightbulb_state.onoff_current = request->on_off;
      lightbulb_state.onoff_target = request->on_off;
      if (lightbulb_state.onoff_current == MESH_GENERIC_ON_OFF_STATE_OFF) {
        LED_set_state(LED_STATE_OFF);
      } else {
        LED_set_state(LED_STATE_ON);
      }
    } else {
      // Current state remains as is for now
      lightbulb_state.onoff_target = request->on_off;
      LED_set_state(LED_STATE_TRANS); // set LEDs to transition mode
      gecko_cmd_hardware_set_soft_timer(TIMER_MS_2_TIMERTICK(delay_ms + transition_ms), TIMER_ID_TRANSITION, 1);
    }
    lightbulb_state_store();
  }

  if (request_flags & MESH_REQUEST_FLAG_RESPONSE_REQUIRED) {
    onoff_response(element_index, client_addr, appkey_index);
  } else {
    onoff_update(element_index);
  }
}

Listing 4: Das Beleuchtungsbeispiel für Maschennetze von Silicon Labs enthält Routinen für bestimmte Ereignisse auf Anwendungsebene, wie diese Funktion zum Ein- oder Ausschalten einer LED als Reaktion auf eine veröffentlichte Anforderung von dem Schalter (siehe Listing 3). (Codequelle: Silicon Labs)

Neben dem Bluetooth-Stack und dem SDK zur Knotenentwicklung stellt Silicon Labs auch das letzte Stück des Bluetooth-Mesh-Puzzles bereit – die Verbindung zu Mobilgeräten. Die meisten Mobilgeräte unterstützen Bluetooth 4, und obwohl ihre Funkmodule Bluetooth-5-Anforderungen unterstützen können, bieten sie keine Stack-Unterstützung für Bluetooth-5-Mesh-Ebenen. Silicon Labs umgeht diese Einschränkung, indem es Entwicklern von Mobil-Apps einen zusätzlichen Software-Stack anbietet, der die Funktionalität für Maschennetzwerke bereitstellt (Abbildung 9).

Abbildung 9: Entwickler können den Mesh-Stack für Mobilgeräte von Silicon Labs zu ihren Mobil-Apps hinzufügen und damit die Verwendung von Bluetooth-4-Mobilgeräten in Bluetooth-5-Maschennetzwerken ermöglichen. (Bildquelle: Silicon Labs)

Zusammenfassung

Bluetooth-5-Maschennetzwerkfunktionen bieten eine natürliche Umstiegsmöglichkeit für eine breite Palette von Anwendungen, die bereits Smartphones und andere Mobilgeräte für die Punkt-zu-Punkt-Kommunikation nutzen. Dennoch sind mit der Bereitstellung von Bluetooth-5-Maschennetzwerken erhebliche Herausforderungen an das Hard- und Softwaredesign verknüpft, insbesondere bei Anwendung mit niedrigem Energiebedarf wie das IoT. Außerdem müssen Hardwareentwickler Anforderungen in Bezug auf minimalen Platzbedarf und geringen Stromverbrauch erfüllen, und Softwareentwickler müssen Software konzipieren, die bei der Ausführung komplexer Kommunikationsprotokolle mit minimalen Ressourcen auskommt. Mit der Kombination aus BGM13P-Modul, SLWSTK6101C-Entwicklungsboard und Bluetooth-Stacks sowohl für Knoten als auch Mobilgeräte verfügen Entwickler über eine umfassende Plattform zur schnellen Entwicklung von Anwendungen zur Nutzung von Bluetooth-Maschennetzwerken.