Architektura produktu opartego o Bluetooth LE

Typowy system Bluetooth Low Energy składa się z kilku warstw, które muszą ze sobą współpracować. Po stronie urządzenia znajduje się hardware, czyli własna płytka PCB albo zestaw rozwojowy wykorzystywany na etapie prototypu. Na hardware działa mikrokontroler lub SoC z obsługą BLE. Na nim uruchomiony jest firmware odpowiedzialny za odczyt sensorów, sterowanie urządzeniem, zarządzanie energią, logikę produktu i komunikację radiową.

Warstwą łączącą firmware z aplikacją mobilną jest najczęściej BLE GATT. To model komunikacji, w którym urządzenie udostępnia usługi i charakterystyki. Aplikacja mobilna może odczytywać wartości, zapisywać komendy, subskrybować powiadomienia i reagować na zmiany stanu urządzenia. Dobrze zaprojektowany GATT jest jednym z najważniejszych elementów całego systemu, ponieważ definiuje sposób komunikacji między aplikacją a firmware.

Po stronie telefonu działa aplikacja mobilna, na przykład napisana we Flutterze, natywnie dla Androida i iOS albo w innej technologii cross-platformowej. Aplikacja odpowiada za wyszukiwanie urządzeń, onboarding, połączenie, konfigurację, diagnostykę, wizualizację danych i obsługę błędów. W bardziej rozbudowanych produktach aplikacja komunikuje się też z backendem, panelem administracyjnym, bazą danych i zewnętrznymi integracjami.

Właśnie dlatego w projektach BLE nie projektuje się tylko aplikacji mobilnej. Trzeba równolegle zaprojektować firmware, strukturę usług GATT, format danych, bezpieczeństwo, aktualizacje OTA, obsługę błędów połączenia, zachowanie aplikacji w tle, diagnostykę i logowanie. Jeśli te decyzje są podejmowane osobno przez różne zespoły, rośnie ryzyko problemów integracyjnych, opóźnień i kosztownych zmian na późniejszym etapie.

Usługi rozwoju oprogramowania embedded

Budujesz produkt BLE od hardware po aplikację mobilną? Nasz zespół z Polski projektuje firmware, GATT, OTA i aplikacje towarzyszące — od warsztatów architektonicznych po produkcję.

Poznaj usługi rozwoju oprogramowania embedded

Dlaczego GATT jest tak ważny

GATT można potraktować jako kontrakt między firmware a aplikacją mobilną. To on określa, jakie dane są dostępne, w jaki sposób aplikacja może wysłać komendę, jak urządzenie informuje o zmianach i jak wygląda komunikacja w różnych stanach pracy. Dobrze zaprojektowany GATT jest prosty, przewidywalny, wersjonowany i przygotowany na rozwój produktu.

W praktyce warto oddzielić dane konfiguracyjne, dane telemetryczne, informacje diagnostyczne i komendy sterujące. Aplikacja powinna wiedzieć, które wartości może odczytywać, które może zapisywać i które będą przychodziły jako powiadomienia. Firmware powinien natomiast jasno określać, jak reaguje na nieprawidłowe komendy, błędy połączenia, starszą wersję aplikacji albo próbę wykonania operacji w niewłaściwym stanie urządzenia.

Bardzo ważne jest też wersjonowanie protokołu. Produkt BLE zwykle rozwija się w czasie. Zmienia się firmware, aplikacja, hardware i wymagania biznesowe. Jeśli format danych nie jest wersjonowany, każda aktualizacja może stać się ryzykowna. Dlatego już w MVP warto zaprojektować komunikację tak, aby można było ją bezpiecznie rozwijać.

OTA i DFU jako element ograniczania ryzyka produktowego

W produktach Bluetooth Low Energy aktualizacje firmware są kluczowe. Urządzenie embedded po sprzedaży trafia do użytkownika, pracuje w różnych warunkach, na różnych telefonach i często przez wiele miesięcy lub lat. Jeśli nie ma możliwości aktualizacji firmware, każda większa poprawka błędu może wymagać fizycznego dostępu do urządzenia, zwrotu produktu albo serwisu. To ogromne ryzyko biznesowe.

OTA, czyli over the air update, pozwala aktualizować firmware bezprzewodowo, najczęściej przez aplikację mobilną. DFU, czyli device firmware update, to proces bezpiecznego wgrania nowego firmware na urządzenie. W dobrze zaprojektowanym produkcie aktualizacja powinna uwzględniać podpisywanie firmware, kontrolę wersji, obsługę przerwanego połączenia, sprawdzanie poziomu baterii i możliwość odzyskania urządzenia po nieudanej aktualizacji.

Dla MVP aktualizacje OTA mogą wydawać się dodatkiem, ale w praktyce są jednym z najważniejszych mechanizmów zmniejszających ryzyko. Pozwalają szybciej testować produkt, poprawiać błędy po pilotażu, rozwijać funkcje i reagować na problemy bez wymiany hardware. Dlatego w projektach BLE warto planować OTA od początku, nawet jeśli pierwsza wersja produktu ma ograniczony zakres.