Rola monitoringu środowiska się zmienia. Kiedyś dane telemetryczne były tylko do użytku wewnętrznego - zamknięty obieg, w którym inżynierowie śledzili przepompownie, stany wód czy jakość powietrza na swoich ekranach. Dziś wygląda to zupełnie inaczej.
Jeśli startujesz jako integrator w przetargach gmin i instytucji, dobrze znasz nową rzeczywistość. Instytucje publiczne nie kupują już samego sprzętu - kupują przejrzystość. Wymagają publicznych widżetów dla mieszkańców, aktualnych wykresów osadzanych na portalach miejskich (IFrame) i dużych eksportów danych historycznych dla naukowców.
Tu zaczynają się schody. Gdy próbujesz zrobić publiczny portal danych z zamkniętej chmury producenta sprzętu, architektura się sypie.
Dylemat integratora: duży ruch na zamkniętym systemie
Producenci sprzętu budują swoje chmury do zarządzania urządzeniami, a nie do publicznego udostępniania danych. Są zoptymalizowane pod zapis danych, a nie pod obsługę tysięcy zapytań od mieszkańców sprawdzających stan lokalnej rzeki.
Integrator, który próbuje zrealizować publiczny przetarg na gotowym oprogramowaniu producenta, od razu trafia na trzy ściany:
- Limity zapytań API: chmury producentów mocno ograniczają, jak często można pobierać dane. Nagły wzrost ruchu (np. mieszkańcy sprawdzający ostrzeżenia powodziowe) kończy się blokadą API - dashboard przestaje działać dokładnie wtedy, gdy jest najbardziej potrzebny.
- Ograniczenia eksportu: naukowcy nie potrzebują ładnych wykresów, tylko surowych danych. Gdy chcą półrocznego eksportu kilku parametrów naraz (np. stanu wody, przepływu i napięcia baterii), zamknięte platformy zwykle się zawieszają, przekraczają czas odpowiedzi albo pozwalają pobrać tylko 30 dni i jeden parametr w pliku CSV.
- Ryzyko bezpieczeństwa: nie dasz urzędnikowi ani pracownikowi uczelni dostępu administratora do głównej platformy IoT tylko po to, żeby pobrał raport.
Rozwiązanie: oddzielić zbieranie danych od ich udostępniania
Dlatego przy telemetrii publicznej system trzeba rozdzielić na dwie części. Moduł, który zbiera dane z czujników, i moduł, który udostępnia je na zewnątrz, muszą być od siebie oddzielone - fizycznie i logicznie.
Zamiast kierować ruch publiczny bezpośrednio do głównej bazy danych albo do API producenta, użyj lekkich punktów dostępu tylko do odczytu:
- Dla mieszkańców: widżety i ramki IFrame z pamięcią podręczną. Gdy gmina osadza wykres stanu wody na swojej stronie głównej, ruch trafia do pamięci podręcznej, a nie do bazy. Niezależnie od tego, czy widżet ogląda dziesięć, czy dziesięć tysięcy osób, obciążenie głównego systemu IoT pozostaje dokładnie takie samo.
- Dla naukowców: osobne usługi eksportu działające w tle. Gdy hydrolog zleca złożony eksport CSV z kilkoma parametrami z sześciu miesięcy, zapytanie wykonuje się w tle, poza głównym ruchem. Baza korzysta z indeksów i zmaterializowanych widoków, żeby zebrać dane bez blokowania systemu innym użytkownikom - a na końcu dostarcza czytelny plik.
Korzyść biznesowa: wygrane przetargi publiczne
Dla integratorów taka zmiana architektury to ogromna przewaga konkurencyjna.
Startując w przetargu, nie sprzedajesz już tylko masztu, panelu słonecznego i czujnika radarowego. Oferujesz „publiczny portal danych”. Możesz zaoferować gminie dostęp mieszkańców do bieżących danych środowiskowych, a uczelni półroczne eksporty CSV bez sztucznych ograniczeń platformy.
Mając własną warstwę oprogramowania, sam ustalasz zasady udostępniania danych. Przestajesz walczyć z limitami API producentów i zaczynasz dostarczać dokładnie to, za co płacą instytucje: dostępne, niezawodne i bezpieczne informacje o środowisku.
Precyzyjny sprzęt zasługuje na precyzyjne oprogramowanie - takie, które obsłuży zarówno jednego inżyniera, jak i mieszkańców. Jeśli Twój obecny system ma kłopot z eksportem danych albo dostępem publicznym, czas przemyśleć architekturę. Zobacz, jak podchodzę do pełnej własności danych w artykule o uzależnieniu od dostawcy, albo sprawdź, jak moje dashboardy telemetryczne obsługują jednocześnie inżynierów i mieszkańców.
