Nasza strona korzysta z analitycznych narzędzi takich jak Google Analytics, czy Matomo, aby zbierać anonimowe informacje o liczbie odwiedzin strony, czy najbardziej popularnych artykułach.
Pozostawiając tę opcję włączoną pozwalasz nam nieustannie poprawiać swoje odczucia.
Please enable Strictly Necessary Cookies first so that we can save your preferences!
Aktualizacje OTA przez MQTT: Jak przesyłać firmware na urządzeniach IoT z ograniczonymi zasobami
W świecie Internetu Rzeczy (IoT) regularne aktualizacje firmware są kluczowe dla bezpieczeństwa, stabilności i dodawania nowych funkcji. Jednak w urządzeniach o ograniczonych zasobach, takich jak te działające na modemach 2G i mikrokontrolerach RP2350, proces aktualizacji Over-The-Air (OTA) staje się wyzwaniem. W tym wpisie podzielę się doświadczeniami z projektu, w którym wykorzystaliśmy protokół MQTT do bezpiecznego i efektywnego przesyłania aktualizacji firmware. Przyjrzymy się wybranemu rozwiązaniu, jego zaletom i problemom, z jakimi się zmierzyliśmy.
Dlaczego MQTT?
MQTT jest protokołem do przesyłania “wiadomości” (gdzie wiadomością jest zwykle tekst lub inne dane) na podstawie publikacji i subskrybcji. W protokole MQTT wyróżniamy broker (czyli serwer mqtt) oraz klientów (na przykład program komputerowy lub jakieś urządzenie IoT). Klienci łączą się do serwera i proszą o subskrybcję na danym kanale (lub kanałach). W takiej sytuacji, broker po otrzymaniu na tym kanale wiadomości, przesyła ją do wszystkich klientów, którzy ten kanał subskrybują. Klienci również mogą publikować wiadomości na kanałach. Dodatkowo, budowa protokołu MQTT zapewnia dobrą niezawodność w wypadku niestabilnych połączeń sieciowych.
Dodatkowo protokół MQTT można zabezpieczyć, wykorzystując między innymi szyfrowanie TLS lub mutual TLS oraz listy kontroli dostępu (ACL). Szyfrowanie oczywiście zapewnia nam poufność i autentyczność przesyłanych danych, natomiast listy kontroli dostępu mówią kto może subskrybować i publikować na danych kanałach. Pozwala to na przykład uniemożliwić komunikacje urządzeń IoT między sobą, ale zezwolić na komunikację urządzeń IoT z systemem zarządzającym.
Jak widać, protokół MQTT ma wiele zalet w zakresie projektów IoT. Dlaczego więc zdecydowaliśmy się na implementacje aktualizacji przez protokół MQTT?
Przebieg procesu aktualizacji OTA, który zrealizowałem
Po decyzji o wykorzystaniu MQTT, zaimplementowałem następujący proces aktualizacji firmware:
SecretDevice/SerialNumber/ota/startpayload zawierający długość (rozmiar, w bajtach) aktualizacji.SecretDevice/SerialNumber/ota/feedbackpayloadstart.SecretDevice/SerialNumber/ota/bytespierwszą paczkę danych (o długości 768 bajtów – wyjaśnienie rozmiaru za chwile).SecretDevice/SerialNumber/ota/feedbackpayloadbytes.SecretDevice/SerialNumber/ota/endpusty payloadSecretDevice/SerialNumber/ota/feedbackpayloadend.W tym projekcie nie zostały wykorzystane mechanizmy zapewniające integralność danych takie jak weryfikacja podpisu cyfrowego przesłanego kodu oraz secureboot, ponieważ korzyści z tych konkretnie funkcji nie zostały uznane za warte wysiłku wymaganego do ich wdrożenia. MQTT wykorzystuje mutual TLS z pełną weryfikacją certyfikatów zarówno po stronie brokera jak i urządzenia, natomiast listy ACL brokera zapewniają, że tylko system zarządzający jest w stanie przesyłać aktualizacje. Nie uważam jednak, że podpisy cyfrowe aktualizacji oraz secureboot są niepotrzebne – zapewne wiele projektów będzie takich zabezpieczeń wymagać, tutaj jednak zostały uznane za zbędne.
Przesyłając aktualizację w ten sposób przez połączenie 2G, byłem w stanie uzyskać prędkości na poziomie 1.8kB/s. Nie jest to jakoś bardzo dużo, jednak to ograniczenie wynika przede wszystkim z przepustowości wykorzystanego modemu 2G. Nie stanowi to również dużego problemu, ponieważ skompilowany kod aplikacji zajmuje mniej niż 200kB. Dodatkowo, podczas przeprowadzania aktualizacji, aplikacja cały czas funkcjonuje.
Dane przesyłane są w paczkach po 768 bajtów, ponieważ wykorzystana biblioteka do MQTT statycznie alokuje bufory na przychodzące i wychodzące wiadomości. Rozmiar bufora ustawiony jest na 1024 bajty, z czego 768 to przesyłane dane, a reszta zostaje do wykorzystania przez nazwę kanału i inne informacje o przychodzącej wiadomości. Warto w tym momencie wspomnieć, że zgodnie ze specyfikacją protokołu MQTT, maksymalna długość wiadomości to 256 MiB, jednak tak duża wiadomość nie ma szans zmieścić się w pamięci RAM mikrokontrolera.
Inne problemy na które natknąłem się przy realizacji tego projektu, niekoniecznie związane z samymi aktualizacjami, to ograniczony rozmiar buforów wykorzystanej biblioteki do TLS. Zmniejszony rozmiar buforów pozwalał na komunikację w jedną stronę. Nie stanowiłoby to problemu w wypadku komunikacji HTTPS, gdzie w większości wypadków komunikacja faktycznie odbywa się tylko w jednym kierunku na raz. Jednak przy połączeniach MQTT, broker może przesłać do klienta dane w dowolnym momencie. Rozwiązanie tego problemu wymagało zmiany opcji w wykorzystanej bibliotece do połączeń TLS.
Podsumowując, mimo, że przesyłanie aktualizacji OTA przez protokół MQTT nie jest szczególnie często spotykaną opcją, w niektórych sytuacjach może okazać się najprostszą z punktu widzenia złożoności infrastruktury oraz ograniczenia wykorzystywanych zasobów. Dodatkowo, istniejące już zabezpieczenia infrastruktury zapewniają odpowiedni dla tego projektu poziom bezpieczeństwa przesyłanych aktualizacji.
Mam nadzieję, że ten wpis przybliżył Wam wyzwania związane z aktualizacją firmware urządzeń IoT o ograniczonych zasobach. Wykorzystanie protokołu MQTT okazało się skutecznym rozwiązaniem, ale wymagało uwzględnienia specyficznych ograniczeń i znalezienia kreatywnych rozwiązań.