Sieci Czujników IoT: MQTT, Obliczenia Brzegowe i Filtr Kalmana

Sieć czujników to w zasadzie problem z przesyłaniem wiadomości

Rozmieszczenie urządzeń IoT – inteligentny budynek, farmę, halę produkcyjną – może składać się z tysięcy czujników zasilanych baterią, które raportują temperaturę, wibracje, zajętość lub wilgotność co kilka sekund przez niezawodny, ale niepewny łącze bezprzewodowe. Trudnym zadaniem rzadko jest fizyka czujnika; chodzi o niezawodne przesyłanie tych danych bez rozładowywania baterii w ciągu tygodnia lub zalewania sieci. Dlatego prawie każda platforma IoT opiera się na MQTT (Message Queuing Telemetry Transport), protokole publish/subscribe zaprojektowanym w 1999 roku dla telemetrii rurociągów ropy naftowej nad drogimi, niezawodnymi satelitarnymi linkami – dokładnie te niskobudżetowe, o dużej opóźnieniu warunki, z którymi mierzy się dzisiejsze IoT.

Publikuj, subskrybuj i trzy poziomy "Obiecuję"

W MQTT czujnik nigdy nie rozmawia bezpośrednio z panelem. Publikuje mały komunikat do nazwanego tematu, np. building/floor3/room12/temp, na centralnym brokerze; wszystko, co subskrybowało ten temat – lub gwiazdka jak building/floor3/+/temp – otrzymuje go natychmiast. Publisher i subscriber nigdy nie muszą się o sobie wiedzieć, co umożliwia dodanie setek nowych paneli bez ingerencji w żaden czujnik.

QoS 0 "w miarę możliwości raz" - ogień i zapomnienie, brak potwierdzenia – najtańszy QoS 1 "przynajmniej raz" - broker potwierdza, nadawca próbuje do skutku, dopóki nie zostanie potwierdzona – może się powtórzyć QoS 2 "dokładnie raz" - czteroetapowy rękawiatka gwarantuje pojedynczą dostawę – najdroższy Czujnik wibracji strumieniujący co 200 ms używa QoS 0 – utracony przykład jest bez znaczenia, a próba ponownego wysłania marnowałby czas. Sygnał alarmu pożarowy używa QoS 1 lub 2, ponieważ utrata tego jednego komunikatu nie jest opcją. Ta możliwość dostosowania, mała nagłówka binarna i trwała połączenie TCP, które unika ponownych rękawiatek, to powód, dla którego MQTT oszczędza baterię w porównaniu z pollingiem REST API co kilka sekund.

QoS 0  "at most once"   fire and forget, no acknowledgement — cheapest
QoS 1  "at least once"  broker acks, sender retries until confirmed — may duplicate
QoS 2  "exactly once"   a four-step handshake guarantees single delivery — costliest

Komputyństwo brzegowe: filtrowanie przed przesyłaniem danych

Wysyłanie każdego surawego odczytu do centrum danych w chmurze nie skaluje się. Bramka lub mikrokontroler na "brzegu" — fizycznie blisko czujników — robi to zamiast tego trzy rzeczy przed opuszczeniem budynku: agreguje (średnia/maksymalna/minimalna z okna zamiast pojedynczych próbek), filtruje (odrzuca wartości, które nie spełniają testu spójności) i łączy dane z wielu czujników w jedną lepszą estymację. Tylko połączone wyniki lub zdarzenie warte zauważenia są przesyłane dalej. To również skraca czas reakcji dla wszystkiego, co musi działać lokalnie — silnik wyłącza się z powodu odczytu o przegrzaniu i nie musi czekać na podróż do centrum danych na drugim końcu kontynentu.

Filtrowanie Kalmana: optymalne łączenie pomiarów

Poszczególne czujniki są szumowe i czasami się nie zgadzają – tani inclinometr oparty na akcelerometrze odchyla się, a sonda temperatury w pobliżu drzwi gwałtownie rośnie, gdy zostaną otwarte. Filtrowanie Kalmana (Rudolf Kálmán, 1960) jest standardowym narzędziem do łączenia szumowatego przewidywania z szumowatym pomiarem w pojedynczą wycenę, która jest dowodowo lepsza niż każda z nich sama, dla systemów liniowych z szumem gaussowskim. Działa w dwóch krokach, powtarzanych za każdym razem, gdy pojawia się nowa wartość,:

PRZEWIDUJ (wykorzystując model ruchu/zachowania systemu) x_pred = F * x_prev // projekcja stanu do przodu P_pred = F * P_prev * F^T + Q // wzrost niepewności z powodu szumu procesowego Q AKTUALIZUJ (włączenie nowego pomiaru z) K = P_pred * H^T / (H * P_pred * H^T + R) // wygranej Kalmana, ważenie zaufania x_new = x_pred + K * (z - H * x_pred) // przyciągnięcie oszacowania w kierunku z P_new = (I - K * H) * P_pred // niepewność maleje R jest znanym odchyleniem pomiarowym szumu czujnika, a Q określa, jak bardzo prawdziwy stan oczekiwany jest na przesunięcie między aktualizacjami. Gdy R jest małe (dokładny czujnik), wygrana K jest bliska 1 i filtr w dużym stopniu ufa nowemu odczytowi; gdy R jest duże (szumowy czujnik), K zmniejsza się, a filtr opiera się na własnym przewidywaniu zamiast tego. Łączenie dwóch niezależnych czujników tej samej wielkości – np. barometrycznego i ultradźwiękowego czujnika wysokości – w ten sposób daje wycenę, której wariancja jest zawsze mniejsza lub równa niż najlepszy z dwóch wejść samych w sobie, co stanowi sedno fuzji czujników.

PREDICT (using the system's motion/behaviour model)
  x_pred = F * x_prev              // project the state forward
  P_pred = F * P_prev * F^T + Q    // grow the uncertainty by process noise Q

UPDATE (fold in the new measurement z)
  K = P_pred * H^T / (H * P_pred * H^T + R)   // Kalman gain, weighs trust
  x_new = x_pred + K * (z - H * x_pred)       // pull estimate toward z
  P_new = (I - K * H) * P_pred                // uncertainty shrinks

Frequently asked questions

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz IoT Sensor Network i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.