Prawie każdy artykuł o niezawodności IoT opisuje ten sam scenariusz awarii: czujnik milknie, włącza się alert, ktoś jedzie go naprawić. To łatwy przypadek. Groźny jest czujnik, który dalej wysyła wiarygodnie wyglądające, mieszczące się w normie liczby, a jednocześnie po cichu mierzy coś innego, niż powinien.
Radarowy czujnik poziomu do połowy pokryty lodem. Zaparowany obiektyw kamery skierowanej na łatę wodowskazową. Przetwornik ciśnienia, który przez starzejącą się membranę co miesiąc przesuwa wynik o pół centymetra (dryf czujnika). Żadna z tych sytuacji nie wywołuje komunikatu o błędzie. Na dashboardzie dane wyglądają dobrze, a w rzeczywistości są błędne - i z samych danych nie da się tego odróżnić.
Rozwiązanie, które wdrożyłem w Wodowskazie, to nie kolejny czujnik. To człowiek, który patrzy na wodę, krótki formularz z pięcioma polami i znacznik czasu.
Dlaczego czujniki „kłamią”, choć się nie psują
Automatyczne wykrywanie anomalii służy do wychwytywania czujników, które psują się w widoczny sposób: płaska linia sygnału, wartość poza fizycznym zakresem, napięcie baterii spadające do zera. Robi to bardzo dobrze. Ale z założenia nie zauważy czujnika, który zawodzi po cichu - czyli dalej podaje liczby w oczekiwanym zakresie, choć sam pomiar rozjechał się z rzeczywistością.
W hydrologii zdarza się to ciągle: lód zafałszowuje odczyt radaru, osady w korycie przesuwają się pod zamocowanym czujnikiem, roślinność wrasta w tor pomiaru, a stała kalibracyjna ustawiona przy montażu z czasem przestaje pasować do miejsca. W każdej z tych sytuacji czujnik podaje liczbę, której alert oparty na progach nie ma powodu oznaczyć.
Najtańszy czujnik, jaki już masz
Pracownicy terenowi i tak odwiedzają stacje - wymieniają baterie, czyszczą, sprawdzają stan urządzeń. Do tej pory taka wizyta nie dawała platformie żadnych danych: technik spojrzał na wodę, spojrzał na czujnik i pojechał dalej. Zbudowałem funkcję „Obserwator” (w wersji przeglądarkowej i mobilnej), żeby to spojrzenie zapisać, zanim przepadnie.
To celowo nie jest wolne pole tekstowe. Formularz odwzorowuje strukturę prawdziwej obserwacji hydrologicznej, bo właśnie ta struktura sprawia, że odczyt jest użyteczny, a nie anegdotyczny:
- Data i godzina wizyty - przypisuje obserwację do konkretnego momentu na osi czasu czujnika, a nie do „gdzieś w tym tygodniu”.
- Odczyt z łaty wodowskazowej - ręczny odczyt stanu wody ze stałej, fizycznej podziałki, niezależny od jakiegokolwiek czujnika elektronicznego.
- Zjawiska lodowe - pełna pokrywa lodowa, częściowa, kra albo brak - bo lód to jedna z najczęstszych cichych przyczyn błędów czujników radarowych i ciśnieniowych.
- Roślinność i zamulenie - roślinność pływająca, zanurzona, wynurzona albo zatarasowane koryto. Każda z tych rzeczy fizycznie zakłóca pomiar w stałym punkcie.
- Uwagi - miejsce na wszystko, czego lista nie przewiduje: od widocznych uszkodzeń po nietypowe śmieci w rzece.
Wypełnienie formularza w terenie zajmuje mniej niż minutę. W zamian nie dostajesz ogólnikowego „sprawdzone, wygląda OK”, tylko uporządkowaną obserwację z dokładnym czasem - podobną do obserwacji IMGW - z której hydrolog może wyciągać wnioski.
Jeden odczyt jako sygnał zaufania
Obserwacja zapisana w osobnej tabeli, której nikt nie otwiera, jest bezwartościowa. Cała wartość funkcji wynika z tego, gdzie ją widać: każde zgłoszenie pojawia się jako znacznik bezpośrednio na tym samym wykresie stanu wody, co automatyczne odczyty czujnika - dokładnie w momencie, którego dotyczy.
Ten jeden znacznik na wykresie załatwia dwie sprawy naraz. Gdy leży na linii czujnika, jest potwierdzeniem - sprawdzonym przez człowieka sygnałem „ta stacja pokazuje prawdę”, którego żaden algorytm sam nie da. Gdy leży obok linii, jest wczesnym ostrzeżeniem, że konkretna stacja wymaga kalibracji albo konserwacji. Dowiadujesz się o tym w kilka minut, a nie przy następnym planowym przeglądzie - albo, co gorsza, po tym, jak ktoś podjął decyzję na podstawie złych danych.
To inny problem niż ten z artykułu o przerwach w łączności. Tamten tekst dotyczy tego, żeby każdy odczyt z urządzenia faktycznie trafił do bazy. Ten dotyczy sytuacji, w której odczyt dotarł w całości, a mimo to jest błędny. Kompletność danych i ich poprawność to dwie różne gwarancje - i platforma potrzebuje mechanizmu dla obu.
Nie tylko stan wody: wzorzec ogólny
Ten wzorzec nie dotyczy wyłącznie hydrologii. W każdej sieci terenowej - stacjach jakości powietrza, czujnikach wilgotności gleby, czujnikach procesów przemysłowych - pracownicy odwiedzają stanowiska i odchodzą, nie zostawiając żadnych danych weryfikacyjnych. Koszt zapisania ich obserwacji to jeden formularz. Korzyść to informacja o kalibracji, którą inaczej dałby dopiero pełny ręczny audyt.
Naturalny kolejny krok, który już planuję, to pełna automatyzacja: gdy obserwacja z terenu różni się od odczytu czujnika bardziej niż o ustaloną tolerancję, uruchamia się ta sama logika alertów, która pilnuje awarii sprzętu. Tyle że ten alert nie szuka sprzętu, który milczy, tylko sprzętu, który kłamie.
Sieci czujników ocenia się zwykle po dostępności i łączności. Tymczasem czujnik, który jest online, ma zasięg i po cichu podaje błędne wartości, to gorsza awaria niż taki, który po prostu przestał nadawać. Dodanie do danych obserwacji pracowników terenowych - tanio, w uporządkowany sposób i na tym samym wykresie, co automatyczne odczyty - zamyka lukę, której nie zamknie samo podejście niezależne od sprzętu, opisane w moim artykule o uzależnieniu od dostawcy. Cały proces „Obserwatora” zobaczysz w realizacji Wodowskaz.
