Co wybrać podczas implementacji interfejsu Bluetooth Low Energy

Dostępny już w wersji 5.0 Bluetooth ma wiele cech i opcji, które pozwalają dostosować go do konkretnych potrzeb projektowanej aplikacji. Jednym z najważniejszych aspektów tego interfejsu, z punktu widzenia aplikacji IoT, jest dostępność profilu Bluetooth Low Energy, cechującego się niskim poborem energii. Jednakże jest wiele rzeczy, na które warto zwrócić uwagę podczas projektowania rozwiązań wspierających BLE.

Implementowanie Bluetootha od zera jest skomplikowanym zadaniem, ale w większości aplikacji IoT, wcale nie jest konieczne. Istnieje mnóstwo dostępnych rozwiązań, które pozwalają łatwo zintegrować Bluetooth i BLE. Kluczem jest wybranie rozwiązania, które najlepiej spełnia wymagania danej aplikacji.

Jednym z podstawowych powodów, wskazujących na wybór BLE w projektach IoT, zamiast tradycyjnej wersji Bluetootha, jest obniżony pobór mocy. Twórcy BLE przyjęli, że w typowych implementacjach będzie konieczne przesyłanie jedynie małych pakietów danych w dużych odstępach czasowych. Połączenie może trwać nawet tylko kilka milisekund, a odczyty mogą być pobierane np. co sekundę, jeśli nie rzadziej. BLE oszczędza energię, ponieważ pozwala elektronice na przejście w stan uśpienia, o ile tylko nie musi ona nasłuchiwać, czy nadchodzą nowe pakiety danych. Konwencjonalne transceivery Bluetooth zazwyczaj pozostają w stanie wzbudzenia w trakcie tych okresów, by nasłuchiwać wiadomości, które by utrzymywały połączenie. Natomiast okres uśpienia może być dostosowywany dynamicznie. Jeśli faza aktywna nie wiąże się z transferem danych, protokół może przedłużyć sen.

Ponieważ prąd pobierany w trakcie odbioru i transmisji danych często mieści się w zakresie od 10 mA do 30 mA, możliwość uśpienia na dłuższy czas transceivera BLE i mikrokontrolera z nim podłączonego, pozwala na stosowanie zasilania z baterii pastylkowej. BLE tym bardziej zmniejsza pobór energii poprzez ograniczenie liczby kanałów, na których transceiver poszukuje innych urządzeń: zamiast 32 używanych w Bluetooth Classic, korzysta tylko z 3. To sprawia też, że wykrywanie urządzeń w okolicy jest szybsze.

Projektanci pracujący nad aplikacją IoT mogą wybrać specjalizowany układ scalony jako interfejs BLE, rozwiązanie w postaci gotowego modułu, lub mikrokontroler z wbudowaną obsługą BLE. Każda z tych opcji niesie ze sobą konsekwencje odnośnie czasu potrzebnego na wprowadzenie rozwiązania na rynek oraz całkowitego, fizycznego rozmiaru tak stworzonego urządzenia.

Wybór anteny radiowej

Antena ma kluczowy wpływ na tworzony produkt. Dobrze zaprojektowana antena jest niezbędna do zapewnienia zgodności produktu z wymaganiami odnośnie zasięgu i skuteczności oraz spełnienia wymogów lokalnych regulacji prawnych, ograniczających niepożądaną emisję fal radiowych.

Czas potrzebny na wprowadzenie na rynek rozwiązań Bluetooth, opartych o moduły takie jak Microchip Technology RN4020Microchip Technology RN4020Microchip Technology RN4020 lub Panasonic PAN1760APanasonic PAN1760APanasonic PAN1760A , jest o tyle krótszy, że antena może być zintegrowana w module. To znacząco skraca czas projektowania i testowania. Twórcy modułów przykładają dużo starań do optymalizacji anteny, by zapewnić, że będzie ona efektywnie pracowała w szerokiej gamie aplikacji.

Jednakże użycie modułu może narzucić ograniczenia na projekt płytki i obudowy, które nie pasują do założeń całej aplikacji. Szczególnie, jeśli zostały one wcześniej ściśle określone. Przykładowo, urządzenie noszone na ciele zazwyczaj musi mieć obudowę, która będzie wygodna dla użytkownika. Często anteny w takim sprzęcie są zintegrowane z obudowami, co oznacza że konieczne staje się sięgnięcie po własne rozwiązanie. W tym przypadku dobrym wyborem będzie specjalny, bluetoothowy układ scalony, pracujący z oddzielnie zaprojektowaną anteną. Natomiast ograniczenia rozmiarów urządzenia sprawiają, że faworyzowane będą układy SoC ze zintegrowaną obsługą Bluetootha, pełniące zarówno funkcje komunikacyjne, jak i wykonujące program aplikacji. Jeśli celem jest dodanie obsługi interfejsu Bluetooth do istniejącej rodziny produktów, dla której stworzono już dużo przygotowanego wcześniej oprogramowania, sięganie po nowy, zintegrowany SoC może nie być dobrym wyborem.

Wsparcie protokołu

Jedną z kluczowych zalet modułu lub oddzielnego transceivera Bluetooth jest fakt, że pozwalają one na zdjęcie z jednostki centralnej obciążenia, spowodowanego obsługą większości funkcji komunikacyjnych. Rodzina układów Kinetis KW35/36 firmy NXP zawiera rdzeń ARM Cortex-M0+, taktowany zegarem 48 MHz, który obsługuje stos protokołu Bluetooth oraz dodatkowo interfejsy CAN-FD i LIN, jakie stosuje się w motoryzacji. Rdzeń ten jest wystarczająco wydajny, by poza samą obsługą protokołu BLE, mógł też wykonywać inne operacje, dzięki czemu może pracować zarówno jako kompletny SoC, jak i jako inteligentny transceiver. Typowe przykłady zastosowania KW35/36 obejmują zdalny, bezkluczykowy dostęp do pojazdów oraz monitorowanie stanu opon. Układ obsługuje do 8 jednoczesnych, bezpiecznych połączeń. Natomiast moduł Panasonic PAN1760A, w którym zintegrowano obwody filtrujące i antenę (by ułatwić jego użycie), jest zbudowany w oparciu o transceiver

CC2540CC2540CC2540 marki Texas Instruments. Obsługa stosu protokołów odbywa się za pomocą zintegrowanego rdzenia 8051. Tymczasem RN4020 RN4020 RN4020

opracowany przez Microchip Technology może pracować jako moduł BLE dla większych systemów, lub – przy użyciu skryptowalnego firmware’u, pracującego na wbudowanym rdzeniu PIC24, działać niezależnie, obsługując nie tylko stos protokołów, ale i samą aplikację użytkownika.

Większą wydajność, potrzebną do pracy w bardziej złożonych aplikacjach z interfejsem BLE można uzyskać dzięki takiemu układowi jak

Nordic Semiconductor nRF52832Nordic Semiconductor nRF52832Nordic Semiconductor nRF52832 , w którym zintegrowano rdzeń ARM Cortex-M4F, 512 kB pamięci Flash i 64 kB pamięci RAM. Układy i moduły wspierające Bluetooth Low Energy umożliwiają obsługę protokołu radiowego w aplikacji na kilka sposobów. Moduł Microchip RN4020 RN4020 RN4020

może pracować w trybie skryptowalnym, dzięki czemu ułatwia szybkie prototypowanie i implementacje BLE w aplikacjach. Język skryptowy może zostać użyty do budowy aplikacji, które odczytują dane z czujników i przekazują je przez łącze Bluetooth do sparowanego urządzenia.

Wewnątrz protokołu BLE

W większości przypadków, układ SoC z obsługą BLE będzie oferować biblioteki programowe, które pozwolą na dostęp do funkcji stosu protokołu. Sam stos BLE jest podzielony na szereg warstw i komponentów, które można zaimplementować na systemie czasu rzeczywistego (RTOS), a który może być dostarczony przez twórcę oprogramowania, stanowić własne rozwiązanie, lub być zakupiony w firmie trzeciej. Stos często będzie się komunikować z RTOSem przez semafory, flagi i funkcje zwrotne. Trochę wysiłku trzeba będzie poświęcić na sportowanie systemu, by zmapować wywołania funkcji ze stosu BLE producenta na rdzeń RTOS, jeśli pochodzi on od firmy trzeciej. Kluczowe elementy protokołu BLE to Generic Access Profile (GAP), Generic Attribute Profile (GATT) i Security Manager (SM).

GAP wykonuje szereg zadań, wliczając w to wysyłanie danych rozgłoszeniowych, bez wcześniejszego ustanawiania połączenia punkt-punkt, a także wykrywanie pobliskich urządzeń oraz konfiguracja połączeń z urządzeniami, które zostały już sparowane. Natomiast GATT odpowiada za zadania przesyłania i odbierania danych z urządzeń już sparowanych. Pakiety wysyłane przez GATT mogą być skonfigurowane tak, by oczekiwały odpowiedzi, która pozwoli upewnić się, że zostały poprawnie dostarczone. Mogą też nie wymagać potwierdzeń.

Dane wysyłane przez warstwę GATT będą często dopasowane do wymagań jednego z wielu standardowych profili aplikacyjnych Bluetooth. Dzięki wykorzystaniu tych profili, zamiast tworzenia własnych formatów pakietów, twórcy węzłów IoT mogą zapewnić lepszą kompatybilność z innymi urządzeniami, takimi jak czujniki medyczne, które podają informację o ciśnieniu krwi, tętnie, czy też z systemami automatyki budynkowej, przekazującymi dane środowiskowe.

Security Manager implementuje funkcje, potrzebne do bezpiecznego sparowania urządzeń i przesyłania zabezpieczonych wiadomości po sparowaniu. SM obejmuje funkcje wymiany kluczy szyfrujących, a więc coraz ważniejszego elementu projektów IoT, potrzebne do szyfrowania danych przed ich transmisją. Bezpieczeństwo staje się kluczowym punktem zainteresowania wielu projektantów IoT. Oprócz samego szyfrowania przesyłanych danych, ważnym jest by systemy były odporne na ataki, takie jak BlueBorne. Dlatego czasem okazuje się istotne, by w urządzeniu Bluetooth zaimplementować prosty interfejs użytkownika, tak by osoba je instalująca mogła wprowadzić bezpieczny kod. Alternatywnie można wykorzystać dodatkowy kanał komunikacji radiowej – np. interfejs NFC, który umożliwi bezpieczną autentykację z użyciem telefonu komórkowego z odpowiednią aplikacją, albo dowolnego innego, specjalnego narzędzia sprzętowego, stosowanego podczas instalacji.

Rozważania na temat API

Decyzja odnośnie tego, czy interfejs Bluetooth będzie pracował w głównym mikrokontrolerze urządzenia, czy też zupełnie oddzielnie, wpłynie na strukturę oprogramowania. Producenci często dostarczają narzędzi, które pomagają przenosić kod z jednego rodzaju rozwiązania na drugie, jeśli zmiany w aplikacji tego wymagają. Jeśli aplikacja bazuje na samodzielnym mikrokontrolerze z wbudowanym Bluetoothem, dostęp do stosu odbywa się zazwyczaj za pomocą odwołań do funkcji w języku C. Jeśli układ ten działa jako zewnętrzny, inteligentny transceiver, te same funkcje API mogą być aktywowane w trybie koprocesora, poprzez interfejs szeregowy, taki jak UART. Protokół może bazować na komendach AT, podobnych do tych, jakie stosuje się w prostych modemach lub może zostać zbudowany zupełnie samodzielnie. Protokół będzie przenosił komendy z jednostki centralnej do obsługującej Bluetootha i generował odpowiedzi oraz reagował na zdarzenia, przekazując je z powrotem do hosta.

Inne narzędzia, które pomagają w tworzeniu profili mogą obejmować kompilatory, które na wejściu przyjmują pliki XML, definiujące wymagania odnośnie przesyłanych wiadomości i konwertują je do postaci kodu C i plików nagłówkowych. To czyni przesyłanie niektórych danych łatwiejszym, czego dobrym przykładem są odczyty ciśnienia krwi, wpasowujące się w jeden ze standardowych profili Bluetooth.

Wielordzeniowe implementacje węzłów IoT, takie w których zastosowano oddzielny transceiver lub cały moduł Bluetooth, pozwalają optymalizować zużycie energii poprzez koordynację cykli usypiania. Mając inteligentny transceiver, nie ma potrzeby by jednostka centralna pozostawała w stanie wybudzenia, gdy odbywa się komunikacja radiowa. W momencie, gdy wydana została komenda do przesłania danych, a treść pakietu została umieszczona w odpowiednim buforze, CPU może przejść do stanu uśpienia, podczas gdy odbiór czy wysyłka danych odbędzie się niezależnie.

Inteligentny transceiver może monitorować nadchodzące pakiety i analizować ich treść, upewniając się, że tylko te z ważnymi danymi spowodują wybudzenie CPU. Rozgłaszane komunikaty, które odnoszą się jedynie do zarządzania siecią, mogą być w pełni obsłużone przez wbudowany rdzeń transceivera Bluetooth. Dzięki temu funkcje takie jak przekazywanie pakietów, dostępne w sieciach o topologii kraty w standardzie Bluetooth 5.0. mogą być wykonywane bez odwoływania się do głównej jednostki centralnej urządzenia. Natomiast komunikaty, które wpływają na węzeł IoT, ale mają niski priorytet, np. odnoszące się do aktualizacji stanu serwera, mogą być buforowane lokalnie. Jednostka centralna sama po nie sięgnie i opróżni bufor, gdy się obudzi, lub gdy zostanie wzbudzona w momencie nadejścia ważniejszego polecenia z serwera, wymagającego reakcji urządzenia. Aby zaimplementować tę funkcję, wystarczy zrealizować programową maszynę stanów, która będzie interpretować nadchodzące dane. Można ją dopisać „na wierzchu” firmware’u Bluetooth, dostarczonego przez producenta transceivera.

Ponieważ transceiver BLE musi być w stanie wybudzenia, by móc nasłuchiwać nadchodzących pakietów, może skutkować poborem energii większym niż planowano. W typowym scenariuszu, warstwa GATT przesyła pakiety, które wymagają odpowiedzi od odbiorcy. W rezultacie, węzeł nie będzie mógł przejść w stan uśpienia do momentu, gdy otrzyma potwierdzenie lub minie czas oczekiwania na nie. Niektóre krytycznie ważne pakiety również będą wymagały stosowania potwierdzeń. Jednakże wiele danych będzie można przesyłać bez konieczności natychmiastowego odbierania potwierdzeń. Zamiast tego, gwarancję poprawności dostarczenia danych można zrealizować na protokołach w warstwie aplikacji. Przykładowo, indywidualnie zaprojektowany protokół może synchronizować się ze zdalnym węzłem, gdy wzbudzi się przy następnej okazji. Może w tym celu skorzystać z numerów sekwencyjnych pakietów lub innych kodów. To pozwala węzłowi przechodzić w stan uśpienia, jak tylko wyśle ostatni pakiet w ramach danego cyklu wybudzenia i uśpienia. Funkcja sniff subrating w BLE pozwala synchronizować ze sobą dwa węzły w taki sposób, że ten nadrzędny będzie przechowywał dane aż do następnego wybudzenia.

Podsumowanie

Dzięki stworzeniu inteligentnych modułów i transceiverów, wspieranych przez zaawansowane biblioteki programowe, producenci osiągnęli cel w postaci uczynienia interfejsu BLE dostępnym dla praktycznie wszystkich projektów IoT. Wybór rozwiązania, które najlepiej pasuje do danego projektu będzie zależeć od jego wymagań i celów, jakie obrano w aplikacji, ale duża liczba dostępnych opcji sprawia, że jedno z nich powinno całkiem dobrze pasować.

Artykuły powiązane:

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

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

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