O krawędzi sieci

Wyobraź sobie elektrownię. Spala węgiel, wytwarza parę, para kręci turbiną, turbina kręci generatorem, powstaje energia elektryczna, dalej transformator podnosi napięcie i dopiero wtedy energia rusza w drogę do odbiorcy. Nikt nie wysyła pary wodnej rurociągiem do Twojego mieszkania, żebyś sobie sam kręcił turbiną w piwnicy. To byłoby absurdalne - straty byłyby ogromne, infrastruktura kosmicznie droga, a efekt końcowy identyczny - prąd w gniazdku.

A jednak dokładnie to robimy z danymi z urządzeń IoT, gdy każdy surowy odczyt pakujemy w pakiet i wysyłamy prosto do chmury. Wysyłamy „parę" zamiast „prądu" - surowy, nieprzetworzony strumień, który dopiero gdzieś daleko ktoś musi zamienić w coś użytecznego.

Skala

Weźmy konkretny przykład. Typowy licznik energii z profilem piętnastominutowym generuje 96 rekordów dziennie (przy założeniu, że czytamy tylko energię czynną pobraną). Każdy rekord to jakieś 100 bajtów - czas pomiaru, wartość, oznaczenie jakości, trochę metadanych. Około 10 kilobajtów na dobę. Brzmi niewinnie.

Ale operator zarządzający tysiącem liczników ma już 10 megabajtów dziennie i 300 megabajtów miesięcznie. Przy dziesięciu tysiącach - 3 gigabajty. Przy stu tysiącach - 30 gigabajtów miesięcznie, i to tylko z liczników energii. Teraz dorzuć czujniki temperatury raportujące co sekundę, przepływomierze na rurociągach ciepłowniczych, analizatory jakości energii mierzące setki parametrów elektrycznych jednocześnie. Nagle rozmawiasz o terabajtach, a Twoja faktura za chmurę wygląda jak rachunek za ogrzewanie kamienicy przed termomodernizacją.

Surowe dane to nie informacja

Problemem nie jest sam wolumen. Problemem jest to, co w tym wolumenie siedzi.

Zacznijmy od szumu. Czujnik temperatury trafo na stacji SN mierzy co sekundę. Przez 99% czasu pokazuje to samo: 123,4°C, 123,4°C, 123,4°C. Trzy tysiące sześćset identycznych wartości na godzinę. Każda z nich przesyłana osobno, zapisywana osobno, opłacana osobno - a żadna nie niesie nowej informacji.

Potem są błędy. Analizator na niskim napięciu nagle zaczyna wskazywać moc czynną rzędu megawatów. To nie fizyka - to awaria pomiaru. Jeśli tego nie wychwycimy, zanim dane trafią do systemu analitycznego, algorytmy zaczną podejmować decyzje na podstawie fikcji.

Dalej - luki. Bramka LTE na stacji trafo traci zasięg, bateria w czujniku się wyczerpuje, gateway restartuje się po aktualizacji. Surowy strumień danych jest dziurawy jak sito, a każdą lukę trzeba jakoś obsłużyć, zanim dane będą się nadawały do czegokolwiek.

I wreszcie formaty. Licznik Iskra gada w protokole IEC, Landis+Gyr w DLMS, ustrojstwo Socomec’a w Modbus RTU. Każdy producent ma swój protokół, swoją strukturę danych, swoje konwencje. Zanim to wszystko trafi do analizy, ktoś musi to sprowadzić do wspólnego mianownika.

Robienie tego wszystkiego po stronie chmury oznacza, że płacisz za przesłanie śmieci, za przechowywanie śmieci i za przetworzenie śmieci - żeby na końcu większość wyrzucić.

Rozwiązanie jest takie samo jak w przykładzie z parą wodną: przetwórz surowiec tam, gdzie powstaje. W świecie danych to się nazywa przetwarzaniem brzegowym, a rolę urządzenia przetwarzającego pełni koncentrator obiektowy - niewielkie urządzenie przemysłowe instalowane tam, gdzie pracują czujniki czy urządzenia pomiarowe. Może to być bramka IoT, komputer przemysłowy, czasem po prostu dobrze skonfigurowany sterownik PLC z dodatkowym modułem komunikacyjnym.

Taki koncentrator robi wszystko to, czego nie powinno się robić w chmurze. Zbiera dane z lokalnych urządzeń przez Modbus, M-Bus, DLMS czy cokolwiek innego. Waliduje - odrzuca wartości, które fizycznie nie mogą wystąpić. Agreguje - zamiast wysyłać trzy tysiące sześćset odczytów temperatury z jednej godziny, wylicza średnią, minimum i maksimum i wysyła jedno podsumowanie. Kompresuje i normalizuje - pakuje dane w spójny, lekki format. Buforuje, gdy umrze BTS i nie ma zasięgu sieci komórkowej. I dopiero wtedy wysyła do centrum to, co naprawdę ma wartość.

Różnica w liczbach

Weźmy monitoring temperatury oleju w transformatorze. Bez przetwarzania brzegowego czujnik mierzący co sekundę generuje 86 400 transmisji dziennie. Każda to osobny pakiet danych, osobna sesja komunikacyjna, osobny rekord w bazie.

Z koncentratorem na obiekcie ten sam czujnik produkuje 24 transmisje dziennie - jedną zagregowaną paczkę na godzinę, zawierającą średnią, minimum, maksimum i odchylenie standardowe. Redukcja wolumenu o 99,97 procent, przy zachowaniu pełnej wartości informacyjnej dla każdego realistycznego zastosowania operacyjnego.

A jeśli temperatura nagle skoczy - koncentrator i tak wyśle alert natychmiast, bo działa lokalnie, “widzi”, że dzieje się coś złego i reaguje wysyłając zdarzenie do operatora.

Od prostych bramek do AI na krawędzi

Możliwości przetwarzania brzegowego rozciągają się od bardzo podstawowych po zaawansowane. Na najprostszym poziomie każda przyzwoita bramka IoT potrafi buforować dane, gdy łączność zawiedzie, agregować odczyty w interwałach czasowych i odfiltrowywać wartości oczywiście błędne.

Bardziej zaawansowane koncentratory idą dalej. Potrafią wykrywać anomalie lokalnie - na przykład rozpoznać, że temperatura w rozdzielni rośnie o pięć stopni na minutę, co oznacza pożar, i natychmiast uruchomić alarm, zanim chmura w ogóle dowie się o problemie. Mogą realizować lokalną logikę sterowania: jeśli moc pobierana przez obiekt przekroczy 110% wartości mocy umownej, zrób zrzut mocy, nie czekając na decyzję operatora. Mogą analizować trendy i przygotowywać raporty bez łączności z centralą.

Na najwyższym poziomie pojawiają się modele AI działające bezpośrednio na urządzeniach brzegowych. Lokalna predykcja awarii transformatora na podstawie analizy wibracji i temperatury. Klasyfikacja zdarzeń sieciowych w czasie rzeczywistym. Rozpoznawanie wzorców zużycia energii, które sugerują nieautoryzowany pobór lub usterkę instalacji. Wszystko bez wysyłania czegokolwiek do chmury - przetwarzane na miejscu, w milisekundach.

Dlaczego to się opłaca?

Pierwsza i najbardziej oczywista korzyść to pieniądze. Transmisja danych przez sieci komórkowe kosztuje, a w lokalizacjach typu stacje transformatorowe, farmy wiatrowe czy odcinki sieci ciepłowniczej często nie ma innej opcji niż LTE. Redukcja wolumenu o 90-99 procent to proporcjonalna redukcja rachunku za transmisję. Mniejszy wolumen oznacza też mniejsze bazy danych, tańsze serwery, niższe opłaty za chmurę.

Druga korzyść to czas reakcji. Decyzja podjęta lokalnie trwa milisekundy. Ta sama decyzja podjęta w chmurze - setki milisekund albo sekundy na transmisję, przetworzenie, odesłanie odpowiedzi. W automatyce przemysłowej i systemach bezpieczeństwa ta różnica może decydować o tym, czy transformator się wyłączy w porę, czy spłonie.

Trzecia to odporność. Kiedy łączność z chmurą zniknie - a w terenie znika regularnie - system z przetwarzaniem brzegowym dalej zbiera dane, dalej reaguje na alarmy, dalej steruje procesem. Buforuje to, czego nie może wysłać, i dosyła, gdy łączność wróci. System zależny wyłącznie od chmury po prostu przestaje działać.

I wreszcie - jakość. Dane przechodzące walidację i normalizację u źródła trafiają do systemów centralnych czyste, spójne i gotowe do analizy. Zamiast inwestować czas analityków w detekcję anomalii pomiarowych i konwersję formatów, można go poświęcić na faktyczne wnioski biznesowe.

Na czym to postawić?

Rynek oferuje trzy klasy urządzeń brzegowych. Proste bramki - takie jak rozwiązania Teltoniki, Moxy, czy Advantecha - kosztują od kilkuset do dwóch tysięcy złotych i radzą sobie z konwersją protokołów, buforowaniem i podstawową logiką. Dla większości punktów pomiarowych to wystarczy.

Komputery przemysłowe - Advantech, Wago, Phoenix Contact - w przedziale dwóch do pięciu tysięcy złotych dają dostęp do pełnego Linuxa, możliwość uruchamiania kontenerów Docker, lokalnych baz danych i własnych skryptów. To najczęstszy wybór, gdy potrzeba czegoś więcej niż proste przekazywanie danych.

Serwery brzegowe - Dell Edge, HPE Edgeline - zaczynają się od dziesięciu tysięcy wzwyż i oferują pełną moc obliczeniową łącznie z GPU. Sensowne tam, gdzie na krawędzi sieci trzeba uruchomić modele AI, przetwarzać obraz z kamer termowizyjnych albo analizować sygnały w czasie rzeczywistym.

Po stronie oprogramowania praktycznie wszystko opiera się na otwartych narzędziach. Linux jako system operacyjny, Telegraf lub Node-RED do zbierania danych, SQLite albo InfluxDB jako lokalna baza, Python lub Go do logiki biznesowej, MQTT lub HTTP do komunikacji z centralą. Zarządzanie flotą urządzeń zapewniają platformy takie jak Balena, AWS IoT Greengrass czy Azure IoT Edge.

Kiedy to nie ma sensu?

Przetwarzanie brzegowe nie jest odpowiedzią na każdy problem. Jeśli masz dziesięć czujników odpytywanych co minutę, system nadrzędny obsłuży to bez problemu i nie potrzebujesz dodatkowej warstwy sprzętowej. Jeśli Twój czujnik kosztuje pięćdziesiąt złotych, inwestowanie dwóch tysięcy w bramkę, która będzie przy nim stała, jest ekonomicznym nonsensem. I jeśli prowadzisz badania naukowe, gdzie potrzebujesz dosłownie każdego punktu pomiarowego z pełną rozdzielczością czasową, agregacja na brzegu sieci zniszczyłaby to, co próbujesz zbadać.

Na koniec

Inteligencja powinna być tam, gdzie powstają dane. Koncentrator na stacji transformatorowej, bramka na farmie fotowoltaicznej, komputer przemysłowy w elektrociepłowni - to lokalne węzły, które zamieniają surowy strumień danych w czysty, wartościowy sygnał informacyjny. Do centrum trafia tylko to, co ma znaczenie.

Mniej transferu. Mniej chaosu. Mniej kosztów. Więcej porządku, więcej odporności, szybsze decyzje.