Watchdog w IoT to sprzętowy mechanizm, który automatycznie resetuje mikrokontroler, gdy firmware przestaje odpowiadać. Urządzenie zamontowane na dachu hali, w szafie technicznej hotelu czy na kontenerze chłodniczym nie ma operatora, który naciśnie przycisk reset. Jeden zakleszczony wątek, wyciek pamięci albo zawieszony stos sieciowy oznacza wyjazd serwisanta. W tym artykule pokazujemy, jak działa watchdog, jakie są jego rodzaje i jak zaprojektować strategię nadzoru firmware w systemach RTOS.
W skrócie: watchdog w IoT to niezależny licznik, który firmware musi regularnie „karmić” (kick, refresh); jeśli tego nie zrobi w zadanym czasie, układ wykonuje reset i urządzenie wraca do pracy bez interwencji człowieka — pod warunkiem że kick jest uzależniony od zdrowia wszystkich krytycznych zadań, a nie tylko od działania jednej pętli.
Czym jest watchdog w IoT i jak działa?
Watchdog to licznik sprzętowy odliczający od wartości początkowej do zera, taktowany z własnego, niezależnego źródła zegara. Firmware w normalnej pracy okresowo przeładowuje licznik. Gdy oprogramowanie się zawiesi, licznik dochodzi do zera i generuje sygnał resetu procesora.
Kluczowa cecha dobrego watchdoga to niezależność: osobny oscylator (np. LSI ok. 32 kHz w STM32), brak możliwości wyłączenia po starcie i reset sprzętowy, a nie przerwanie, które zawieszony kod mógłby zignorować. Po restarcie firmware odczytuje rejestr przyczyny resetu (np. flagę IWDGRSTF w RCC_CSR na STM32) i może zgłosić incydent do chmury.
Rodzaje watchdogów: wewnętrzny, okienkowy i zewnętrzny
Rodzaj watchdoga to wybór między kosztem, odpornością na błędy a złożonością projektu. W urządzeniach IoT spotyka się trzy podstawowe warianty, często łączone ze sobą.
- Niezależny watchdog wewnętrzny — np. IWDG w STM32 (12-bitowy licznik, preskaler do /256, timeout od ok. 0,125 ms do ok. 32 s) lub WDT w nRF52. Najtańszy, bo wbudowany w MCU.
- Watchdog okienkowy (window watchdog) — np. WWDG w STM32. Kick jest poprawny tylko w określonym oknie czasowym; zbyt wczesne odświeżenie też wywołuje reset. Wykrywa kod, który „zapętlił się” wokół instrukcji kick.
- Watchdog zewnętrzny — osobny układ nadzorczy (np. rodziny TPS3430 lub MAX6369) z własnym zegarem. Działa nawet wtedy, gdy zawiedzie zegar lub zasilanie rdzenia MCU, dlatego stosuje się go w IIoT i urządzeniach o wymaganiach funkcjonalnego bezpieczeństwa.
ESP32 ma dodatkowo watchdogi programowo-sprzętowe ESP-IDF: Task Watchdog Timer (domyślnie 5 s) nadzorujący zadania FreeRTOS oraz Interrupt Watchdog (domyślnie 300 ms) wykrywający zbyt długo zablokowane przerwania.
Jak poprawnie karmić watchdog w systemie RTOS?
Poprawne karmienie watchdoga to uzależnienie kick-u od potwierdzonego postępu każdego krytycznego zadania. Najczęstszy błąd to odświeżanie licznika z przerwania timera lub z zadania o najniższym priorytecie — wtedy reszta systemu może być martwa, a watchdog niczego nie zauważy.
Wzorzec zadania nadzorcy
Zalecany wzorzec w firmware opartym na FreeRTOS to zadanie nadzorcy (supervisor task). Każde krytyczne zadanie — odczyt czujników, stos sieciowy, obsługa MQTT — ustawia swój bit w grupie zdarzeń. Nadzorca odświeża watchdog tylko wtedy, gdy w danym oknie zgłosiły się wszystkie zadania.
- Zdefiniuj listę zadań krytycznych i maksymalny czas cyklu każdego z nich.
- Ustaw timeout watchdoga na 2–5-krotność najdłuższego cyklu.
- Nie karm watchdoga w pętlach oczekujących na sieć — tam stosuj własne timeouty.
- Przed resetem zapisz w pamięci podtrzymywanej identyfikator zadania, które się nie zgłosiło.
W Zephyr RTOS ten wzorzec jest gotowy jako podsystem task_wdt, który multipleksuje wiele kanałów programowych na jeden watchdog sprzętowy.
Watchdog a aktualizacje OTA i bezpieczny rozruch
Watchdog jest niezbędnym elementem bezpiecznego wdrażania nowych wersji oprogramowania. Przy aktualizacjach OTA firmware na dużą skalę bootloader taki jak MCUboot uruchamia nowy obraz w trybie testowym. Jeśli aplikacja nie potwierdzi poprawności obrazu, bo zawiesi się i zostanie zresetowana przez watchdog, bootloader przywraca poprzednią wersję.
Ten mechanizm rollbacku powinien współpracować z secure boot: weryfikacja podpisu chroni przed złośliwym obrazem, a watchdog — przed obrazem poprawnie podpisanym, ale wadliwym. Potwierdzenie obrazu warto wykonywać dopiero po udanym połączeniu z chmurą, nie zaraz po starcie.
Kiedy stosować watchdog zewnętrzny i jak pogodzić go z oszczędzaniem energii?
Watchdog zewnętrzny stosuje się, gdy awaria samego mikrokontrolera, zegara lub zasilania musi zostać wykryta niezależnie od MCU. Dotyczy to sterowników przemysłowych, urządzeń kontroli dostępu i systemów objętych normami bezpieczeństwa funkcjonalnego (IEC 61508, IEC 60730 klasa B).
W urządzeniach bateryjnych watchdog musi pasować do cyklu uśpienia. Niezależny watchdog zwykle liczy także w trybie Stop, więc urządzenie śpiące 15 minut zostałoby zresetowane. Rozwiązania to: zamrożenie IWDG w trybie uśpienia bitami opcji, krótkie wybudzenia tylko na kick (kilka µA średnio) albo zewnętrzny watchdog z timeoutem 60–120 s. Więcej o budżecie prądowym piszemy w artykule o energooszczędności w IoT i pracy na baterii.
Jak monitorować resety watchdoga we flocie urządzeń?
Monitorowanie resetów to zamiana watchdoga z „cichego naprawiacza” w źródło danych diagnostycznych. Każdy reset powinien trafiać do telemetrii z przyczyną, licznikiem resetów, wersją firmware i identyfikatorem zawieszonego zadania.
- Licznik resetów z watchdoga na urządzenie i na wersję firmware — wzrost po wdrożeniu to sygnał do wstrzymania rolloutu.
- Ochrona przed pętlą resetów: po 3–5 resetach w krótkim czasie urządzenie przechodzi w tryb awaryjny z minimalną funkcjonalnością i kanałem OTA.
- Alerty w platformie zarządzania flotą grupujące incydenty według wersji, partii sprzętu i regionu.
Najczęściej zadawane pytania (FAQ)
Czy watchdog w IoT może zastąpić testy firmware?
Nie. Watchdog w IoT to ostatnia linia obrony, a nie metoda zapewnienia jakości. Przywraca urządzenie do pracy po zawieszeniu, ale nie usuwa przyczyny błędu. Dlatego każdy reset z watchdoga powinien być logowany z rejestrem przyczyny resetu i raportowany do chmury, aby zespół mógł znaleźć i naprawić źródło problemu.
Jaki timeout watchdoga wybrać w urządzeniu IoT?
Typowo timeout ustawia się na 2–5-krotność najdłuższego normalnego cyklu pętli głównej lub zadania nadzorcy. W praktyce dla czujników to zwykle 1–10 s, a dla urządzeń z długimi operacjami (zapis flash, zestawianie połączenia LTE-M) nawet 30 s. Zbyt krótki timeout powoduje fałszywe resety, zbyt długi wydłuża przestój.
Czy watchdog działa w trybie uśpienia mikrokontrolera?
Zależy od układu. Niezależny watchdog STM32 (IWDG) taktowany z LSI zwykle liczy także w trybach Stop i Standby, chyba że wyłączy się to bitami opcji. Wtedy urządzenie musi budzić się przed upływem timeoutu albo korzystać z zewnętrznego watchdoga o długim czasie, np. 60–120 s, dopasowanego do cyklu pracy baterii.
Podsumowanie
Dobrze zaprojektowany watchdog w IoT to nie jedna linijka kodu, lecz strategia: niezależny zegar, kick uzależniony od zdrowia wszystkich zadań, współpraca z rollbackiem OTA, zgodność z trybami uśpienia i telemetria resetów. Najważniejsze wnioski: unikaj karmienia watchdoga z przerwań, rozważ watchdog zewnętrzny tam, gdzie liczy się bezpieczeństwo, i traktuj każdy reset jako błąd do naprawienia. Zespół FSS projektuje hardware, firmware i backend chmurowy urządzeń IoT działających latami bez nadzoru — sprawdź, jak budujemy niezawodne urządzenia połączone.