Aktualizacje firmware OTA na dużą skalę: architektura aktualizacji floty IoT

Wysłanie firmware do 10 000 urządzeń jednocześnie to prosta droga do zablokowania (bricku) całej floty. Etapowe wdrożenia OTA z automatycznym rollbackiem nie są opcją — to różnica między kontrolowanym wydaniem a katastrofą.

Architektura OTA na ESP32

ota_0  app  ota_0  0x10000  1500K
ota_1  app  ota_1         , 1500K
// Po pobraniu + weryfikacji:
esp_ota_set_boot_partition(update_partition);
esp_restart();  // bootloader waliduje, wycofuje jeśli błędne

Etapowe wdrożenie przez Azure IoT Hub

az iot hub configuration create   --config-id "fw-2-1-0-canary"   --target-condition "tags.stage='canary'"   --priority 10

Aktualizacje delta dla wdrożeń o ograniczonym paśmie

Pełne obrazy firmware dla aplikacji ESP32-S3 mają zwykle 1,2–2 MB. Przy połączeniu komórkowym za 0,05 €/MB comiesięczna aktualizacja 5000 urządzeń kosztuje 500–500 € na wydanie. Aktualizacje delta (różnica binarna) redukują to o 60–80%, przesyłając tylko te bajty, które zmieniły się między wersjami firmware. Narzędzia takie jak JojoDiff czy bsdiff generują kompaktowe łaty binarne; urządzenie stosuje je w pamięci i weryfikuje wynik przed zatwierdzeniem.

Aktualizacje delta wymagają bardziej złożonej logiki aktualizacji firmware i starannego zarządzania zgodnością wersji bazowej — musisz dokładnie wiedzieć, jaką wersję firmware ma urządzenie, zanim wyślesz łatę. Azure IoT Hub Device Twins upraszczają to: urządzenie raportuje dokładny hash swojego firmware w sekcji “reported”, a chmura wybiera odpowiedni pakiet delta dla każdego urządzenia.

Architektura rollbacku w szczegółach

Solidny system rollbacku wymaga czegoś więcej niż tylko dwóch partycji. Urządzenie musi zwalidować nowe firmware przed zatwierdzeniem go jako partycji startowej i musi mieć bezpieczny mechanizm zgłaszania awarii, nawet jeśli nowe firmware nie może połączyć się z chmurą. Standardowy wzorzec:

Po zainstalowaniu nowego firmware bootloader oznacza nową partycję jako “oczekującą na weryfikację” i uruchamia ją. Aplikacja ma okres karencji (zwykle 5 minut), aby ukończyć autotest, pomyślnie połączyć się z chmurą i wywołać esp_ota_mark_app_valid_cancel_rollback(). Jeśli to wywołanie nigdy nie nastąpi — bo aplikacja uległa awarii, zawiesiła się lub utraciła łączność — bootloader przy następnym uruchomieniu wraca do poprzedniej partycji.

Zarządzanie flotą na dużą skalę

Przy 10 000+ urządzeń wdrożenia firmware wymagają automatyzacji. Wykorzystujemy konfiguracje automatycznego zarządzania urządzeniami w Azure IoT Hub, aby kierować aktualizacje na urządzenia według tagów: geografia, wersja sprzętu, poziom klienta. Typowy plan wydania trwa 7 dni: dzień 1 canary (1%), dzień 3 etap 1 (10%), dzień 5 etap 2 (50%), dzień 7 cała flota. Automatyczne alerty wyzwalają się, gdy poziom błędów na dowolnym etapie przekroczy 0,5% — wydanie zostaje wstrzymane, a inżynieria powiadomiona, zanim problem się rozskaluje.

Buduj infrastrukturę OTA jako priorytet pierwszej klasy, a nie coś dodanego po fakcie. Urządzenia, które dziś wysyłasz, będą potrzebować aktualizacji firmware przez 5–10 lat. Doposażenie istniejącego produktu w bezpieczny, niezawodny system OTA jest znacznie trudniejsze niż zaprojektowanie go od początku.