W monitoringu środowiska nie ma jednego protokołu komunikacji, który pasuje wszędzie. O wyborze technologii decydują fizyczne warunki w miejscu instalacji.
Projekt obejmujący całą gminę nieuchronnie zamienia się w mozaikę standardów. Czujniki głęboko w betonowych studzienkach wymagają NB-IoT, który najlepiej przebija się przez przeszkody. Starsze stacje meteorologiczne na wsi korzystają ze zwykłej sieci GSM. A grupa czujników wilgotności gleby w gęstym lesie bez zasięgu komórkowego może działać tylko przez prywatną bramkę LoRaWAN.
Taka różnorodność to inżynierska konieczność. Ale dla osób, które zarządzają siecią i podejmują decyzje, szybko staje się koszmarem organizacyjnym - pułapką wielu sieci.
Koszt rozproszonej komunikacji
W przeciwieństwie do uzależnienia od producenta sprzętu - gdzie producent zmusza Cię do korzystania z jego chmury - rozproszenie sieci to problem infrastrukturalny. Nawet jeśli używasz otwartego sprzętu, dane wysłane przez LoRaWAN trafiają na inny serwer sieciowy (np. The Things Network) niż dane wysłane przez infrastrukturę NB-IoT operatora.
Jeśli integrator nie uwzględni tego w oprogramowaniu, klienci szybko to odczują:
- Praca na kilku platformach: operator loguje się do jednej, żeby sprawdzić czujniki LoRaWAN w lesie, i do drugiej, żeby śledzić boje hydrologiczne na GSM. Każde przełączenie kosztuje czas i zwiększa ryzyko pomyłki.
- Luki w analizie: zestawienie danych staje się prawie niemożliwe. Jeśli ulewa zarejestrowana przez stację GSM wywołuje wezbranie w dole rzeki, które rejestruje czujnik LoRaWAN, system nie pokaże tych dwóch zdarzeń na jednej osi czasu bez ręcznych eksportów CSV i pracy w arkuszu.
- Chaos w alertach: reakcja na zdarzenia jest mocno opóźniona, gdy progi ostrzegawcze są rozrzucone po kilku osobnych systemach. Krytyczne ostrzeżenia giną nie dlatego, że czujniki zawiodły, tylko dlatego, że nikt nie jest w stanie pilnować trzech ekranów jednocześnie.
Rozwiązanie: oddzielić dane od drogi, którą przyszły
Żeby wyjść z pułapki wielu sieci, warstwa wizualizacji i analizy musi być całkowicie niezależna od warstwy transmisji. Sieć to tylko środek transportu, a nie miejsce docelowe. To ta sama zasada, którą stosuję, gdy rozbijam silosy danych powstałe przez sprzęt różnych producentów.
W Silentbits buduję platformy telemetryczne, które działają jak centralny punkt zbierania danych. Zamiast zmuszać klienta do dostosowania się do ograniczeń każdej sieci, backend przyjmuje dane z każdego kanału:
- Webhooki dla LoRaWAN: odbieranie lekkich paczek danych z prywatnych bramek w momencie, gdy przychodzą - bez opóźnień związanych z odpytywaniem.
- API REST dla NB-IoT: regularne pobieranie danych z chmur operatorów z użyciem znacznika ostatniego zapisu, który uzupełnia luki po przerwach w łączności.
- Bezpieczny FTP dla GSM: przetwarzanie plików CSV zostawianych przez zdalne stacje działające w trybie „zapisz i wyślij później”, z obsługą nieregularnych wysyłek i automatycznym uzupełnianiem luk w historii.
Wszystkie te strumienie są ujednolicane, opatrywane znacznikiem czasu i zapisywane w jednej bazie szeregów czasowych. Moduł zbierający dane działa jak tłumacz, który rozumie każdy język Twojej infrastruktury.
Jeden dashboard, pełna kontrola
Gdy strumienie z różnych sieci są połączone po stronie backendu, praca użytkownika wygląda zupełnie inaczej. W interfejsie cała złożoność fal radiowych i kart SIM po prostu znika.
Hydrolog czy urzędnik otwiera dashboard i widzi całą swoją infrastrukturę na jednej interaktywnej mapie. Radarowy czujnik poziomu wody na LoRaWAN stoi tuż obok deszczomierza na GSM. Dane można zestawić na wspólnych wykresach z dwiema osiami, a centralny moduł alertów może wysyłać ostrzeżenia SMS na podstawie danych z całej sieci.
Tę architekturę wdrożyłem w platformie Wodowskaz, gdzie czujniki sześciu producentów - każdy z własnym formatem danych - trafiły do jednego interfejsu. Operatorzy zamiast osobnych logowań mają teraz wszystko na jednym ekranie.
Dostęp publiczny bez dodatkowej pracy
Wspólny backend pozwala też udostępniać dane w sposób, na który rozproszona architektura po prostu nie pozwala. Gdy wszystkie dane trafiają do jednej platformy, publiczny dostęp łatwo kontrolować i skalować.
Gminy coraz częściej wymagają publicznych dashboardów - mieszkańcy sprawdzają stan lokalnej rzeki, naukowcy pobierają dane historyczne. Mając jedną warstwę danych, możesz wdrożyć publiczne widżety z pamięcią podręczną i eksporty działające w tle, nie ruszając głównego modułu zbierania danych. Szczegóły opisuję w artykule o telemetrii publicznej - jak obsłużyć mieszkańców z tej samej infrastruktury, która obsługuje jednego inżyniera w terenie.
Korzyść biznesowa dla integratorów
Dla integratorów połączenie sieci to wyraźna przewaga w przetargach publicznych. Gdy gmina albo instytucja ochrony środowiska ocenia oferty, jedna platforma obsługująca wszystkie rodzaje łączności to rzadki wyróżnik - większość konkurentów proponuje trzy osobne systemy połączone ręcznymi eksportami.
Instalacje IoT w terenie zawsze będą wymagały różnych rozwiązań komunikacyjnych, żeby sprostać trudnym warunkom. Ale to, jak skomplikowany jest teren, nie powinno decydować o tym, jak wygodne jest oprogramowanie. Łącząc wiele protokołów w jednej platformie integracyjnej, organizacje odzyskują pełny wgląd w dane środowiskowe i kontrolę nad nimi - bez względu na to, jaką drogą radiową dotarły.
Pułapka wielu sieci to problem infrastrukturalny, który wymaga rozwiązania na poziomie oprogramowania. Traktując LoRaWAN, NB-IoT i GSM jako wymienne kanały transportu, które zasilają jeden punkt zbierania danych, integratorzy mogą dać klientom publicznym i przemysłowym jeden spójny system. Jeśli Twoi operatorzy muszą żonglować kilkoma platformami, czas przemyśleć architekturę. Zobacz, jak poradziłem sobie ze sprzętem wielu producentów w artykule o uzależnieniu od dostawcy, albo sprawdź, jak moje dashboardy telemetryczne zbierają wszystkie źródła danych w jednym czytelnym interfejsie.
