AI na krawędzi sieci: edge computing w przemyśle i czasie rzeczywistym

Od chmury do krawędzi – po co przenosić AI bliżej maszyn

AI w chmurze kontra AI na brzegu sieci

Klasyczny model zakłada wysyłanie danych z maszyn i czujników do chmury, przetwarzanie ich w centralnym systemie AI i odsyłanie wyników z powrotem. To działa dobrze tam, gdzie opóźnienie nie jest krytyczne, a łącze jest stabilne i tanie.

Edge AI przesuwa logikę i inferencję bliżej źródła danych: do sterowników, bramek przemysłowych, lokalnych serwerów lub nawet bezpośrednio do kamer i czujników. Dane surowe często w ogóle nie opuszczają zakładu, a do chmury trafiają tylko agregaty, metadane lub dane treningowe.

W praktyce większość dojrzałych wdrożeń łączy oba podejścia: trening modeli i ciężka analityka w chmurze, inferencja i decyzje czasokrytyczne na brzegu sieci.

Motywacje biznesowe i techniczne: opóźnienia, niezawodność, koszty

W przemyśle i infrastrukturze krytycznej głównym powodem przejścia na edge AI są opóźnienia. Wysyłanie klatek wideo z kamer lub strumienia danych z czujników do odległego regionu chmurowego może dodać dziesiątki–setki milisekund latencji, nie licząc czasu inferencji. Dla wielu procesów to za dużo.

Drugi powód to niezawodność. Fabryki często działają w trybie 24/7, w lokalizacjach z niepewnym łączem. System sterowania bezpieczeństwem nie może zależeć od tego, czy router operatora komórkowego akurat się przeładowuje. Edge AI pozwala podejmować decyzje lokalnie, nawet przy chwilowej utracie dostępu do chmury.

Trzeci argument to koszty transferu. Strumień z kilkunastu kamer HD lub sygnałów wysokoczęstotliwościowych szybko generuje duże wolumeny danych. Wysyłanie wszystkiego do chmury jest nie tylko wolne, ale i drogie. Przetwarzanie na brzegu pozwala wysyłać wyłącznie wyniki lub podsumowania.

Dochodzi jeszcze prywatność i zgodność z regulacjami. Nagrania wideo z pracownikami, dane z linii farmaceutycznych czy z infrastruktury energetycznej często nie mogą opuścić danego kraju, a czasem nawet zakładu. Edge AI ułatwia spełnienie wymogów audytowych.

Specyfika środowisk przemysłowych

Zakłady produkcyjne to środowisko z dużą liczbą urządzeń, generujących dane w różnych protokołach, z różną częstotliwością i jakością. Do tego dochodzą stare linie produkcyjne, gdzie PLC pamięta jeszcze lata 90. i nie przewidywał analizy AI w czasie rzeczywistym.

Typowe ograniczenia, które wypychają AI na krawędź sieci:

• brak gwarantowanej przepustowości do internetu lub do chmury publicznej,
• obecność obszarów z ograniczonym dostępem sieci (hale, podziemia, strefy ATEX),
• systemy krytyczne, które muszą działać nawet przy braku połączenia z zewnętrznym światem,
• ograniczona możliwość modernizacji istniejącego OT: wymiana całych sterowników jest kosztowna i ryzykowna.

Edge computing pozwala „dolepić” inteligencję tam, gdzie nie ma sensu ruszać istniejącej automatyki: na bramkach, małych przemysłowych PC, a coraz częściej bezpośrednio w inteligentnych czujnikach i kamerach.

Przykład: kontrola jakości wizyjnej zbyt wolna w chmurze

Linia pakująca sortuje produkty na taśmie. Kamera nad taśmą robi zdjęcia każdej sztuki. Model AI rozpoznaje defekty i w czasie krótszym niż kilkadziesiąt milisekund musi zdecydować, czy wyrzucić element na bok, czy puścić dalej.

Jeśli każda klatka wideo miałaby lecieć do chmury, przechodzić tam inferencję i wracać z decyzją, taśma musiałaby zwalniać, by nadążyć. W praktyce operatorzy i tak wyłączyliby taki system po kilku godzinach, bo zabijałby przepustowość linii.

Umieszczenie modelu na przemysłowym komputerze obok taśmy (edge box), z bezpośrednim połączeniem do kamery i siłownika, rozwiązuje problem. Do chmury trafiają już tylko statystyki: ile odrzuconych sztuk, jakie typy defektów, zdjęcia wybranych przypadków do dalszego doskonalenia modelu.

Podstawowe pojęcia: edge, fog, on-prem, embedded – co jest czym

Co oznacza edge computing w przemyśle

W kontekście przemysłowym edge to każdy punkt przetwarzania położony blisko procesu fizycznego: czujnika, maszyny, robota, kamery, linii produkcyjnej. Mogą to być:

• inteligentne czujniki z wbudowanym mikrokontrolerem i prostym modelem AI,
• sterownik PLC z dodatkową jednostką obliczeniową,
• przemysłowy gateway zbierający dane z wielu urządzeń,
• mały, wzmocniony komputer (IPC) przy szafie sterowniczej.

Kluczowym kryterium jest bliskość źródła danych i możliwość działania niezależnie od chmury, przynajmniej w podstawowym zakresie funkcji.

Fog computing i lokalne centra danych

Fog computing w praktyce przemysłowej oznacza pośredni poziom między pojedynczym urządzeniem edge a chmurą. Może to być:

• lokalny klaster serwerów w serwerowni zakładu,
• węzeł obliczeniowy obsługujący kilka linii produkcyjnych,
• regionalny węzeł w sieci energetycznej czy logistycznej.

Fog zwykle ma większą moc obliczeniową niż pojedyncze urządzenia edge, ale jest nadal blisko geograficznie, z dużo niższą latencją niż chmura. Często pełni rolę bufora: agreguje dane, wykonuje bardziej zaawansowaną analitykę, przechowuje lokalnie logi i wyniki.

On-prem data center to klasyczne lokalne centrum danych w firmie. Może pełnić funkcję zarówno warstwy fog, jak i lokalnej „chmury” do treningu modeli czy systemów MES/ERP. Nie jest edge, ale może zarządzać flotą urządzeń edge AI.

AI on-device, AI na bramce, AI w lokalnym klastrze

Architektura systemu edge AI zależy od tego, gdzie dokładnie uruchamiasz model:

• AI on-device – model działa bezpośrednio na czujniku, kamerze, robocie, PLC. Przykład: kamera z wbudowanym modułem detekcji obiektów, która do systemu nadrzędnego wysyła już tylko bounding boxy i etykiety, nie surowe wideo.
• AI na bramce przemysłowej – dedykowany gateway zbiera dane z wielu urządzeń (Modbus, OPC UA, Profinet) i wykonuje inference. Przykład: analiza drgań kilku silników na jednej bramce przy linii.
• AI w lokalnym klastrze – kilka serwerów (czasem z GPU) w zakładowej serwerowni, które wykonują cięższe zadania: trening lokalny, symulacje, harmonogramowanie produkcji, zaawansowaną optymalizację.

W wielu projektach używa się wszystkich trzech poziomów jednocześnie, dopasowując lokalizację modelu do wymagań czasu rzeczywistego i dostępnych zasobów.

Rola robotów, kamer, PLC, SCADA i MES

W typowym środowisku przemysłowym występuje kilka kluczowych elementów:

• robot – wykonuje fizyczne operacje, często w cyklu milisekundowym. AI może pomagać w planowaniu trajektorii, adaptacyjnym chwytaniu, unikaniu kolizji.
• kamera – źródło danych wizyjnych do kontroli jakości, bezpieczeństwa, śledzenia produktów. Edge AI pozwala przetwarzać obraz lokalnie.
• PLC – sterownik logiczny obsługujący bezpośrednią pętlę sterowania. Zwykle nie jest miejscem na ciężkie modele AI, ale może odbierać decyzje z bramki edge.
• SCADA/MES – systemy nadzoru i zarządzania produkcją. Integrują dane z wielu źródeł, ale rzadko wykonują inferencję AI, raczej korzystają z jej wyników.

Edge AI zwykle wchodzi pomiędzy te warstwy: np. gateway z AI analizuje obraz z kamer, wysyła wyniki do PLC w postaci prostych sygnałów (OK/NOK), a do SCADA tylko statystyki jakości.

Wymagania czasu rzeczywistego: jak szybko „szybko” oznacza w fabryce

Soft real-time, hard real-time i near-real-time w praktyce

W systemach przemysłowych pojęcie „czasu rzeczywistego” nie jest jednorodne. W uproszczeniu:

• hard real-time – opóźnienie jest ściśle ograniczone i przewidywalne. Przekroczenie limitu może prowadzić do uszkodzenia maszyny lub zagrożenia bezpieczeństwa. Przykład: sterowanie napędami w robotach.
• soft real-time – system dąży do zachowania limitu czasowego, ale sporadyczne przekroczenia nie są krytyczne. Przykład: system wizyjny wspierający operatora.
• near-real-time – głównie chodzi o ogólną szybkość reakcji, ale nie ma ścisłego limitu. Przykład: predykcyjne utrzymanie ruchu aktualizowane co kilka sekund lub minut.

Edge AI najczęściej obsługuje soft i near-real-time. Do hard real-time wciąż zwykle stosuje się klasyczne sterowniki i pętle PID, chociaż pojawiają się rozwiązania, w których lekkie modele AI działają na RTOS-ach w mikrokontrolerach.

Typowe zakresy opóźnień w zastosowaniach przemysłowych

Warto przełożyć pojęcia na liczby, chociaż każda aplikacja ma własną specyfikę:

• sterowanie ruchem, robotyka – rząd pojedynczych–kilkunastu milisekund na pełen cykl (odczyt, obliczenie, sterowanie).
• wizyjna kontrola jakości na szybko poruszającej się taśmie – zwykle 10–50 ms na przetworzenie klatki i decyzję o odrzucie.
• predykcja awarii na podstawie drgań, hałasu – często wystarczy kilka setek milisekund, czasem sekundy, jeśli decyzja nie zatrzymuje nagle maszyny, a tylko zgłasza alert.
• optymalizacja procesu (np. regulacja temperatury, mieszania) – od sekund do minut, zależnie od bezwładności procesu technologicznego.

Każda dodatkowa warstwa sieci, kopia danych, serializacja czy wywołanie zdalne dodaje milisekundy. Sumaryczny budżet czasowy szybko się kurczy.

Co generuje opóźnienia w systemie edge AI

Pełen łańcuch od zdarzenia fizycznego do reakcji aktuatora składa się z kilku kroków:

• akwizycja danych (np. naświetlenie i odczyt z kamery, pomiar z czujnika),
• przesłanie do urządzenia obliczeniowego (interfejs kamerowy, magistrala przemysłowa, sieć),
• preprocessing (normalizacja, filtrowanie, segmentacja, FFT),
• inferencja modelu AI,
• postprocessing wyników (agregacja, proste reguły, histereza),
• przesłanie decyzji do PLC/aktuatora,
• fizyczna reakcja (uruchomienie siłownika, zmiana prędkości, sygnał do operatora).

W architekturach chmurowych trzeba dodać jeszcze transfer do chmury i z powrotem. W zastosowaniach przemysłowych to zwykle dyskwalifikuje chmurę jako warstwę wykonywania inference w pętlach czasokrytycznych.

Dlaczego chmura zabija część zastosowań czasu rzeczywistego

Wyobraź sobie system sortowania części na taśmie. Kamera widzi element nadjeżdżający na stanowisko wyrzutnika. Model ma kilkadziesiąt milisekund, by podjąć decyzję: wyrzucić czy nie. Dodatkowo trzeba uwzględnić czas reakcji siłownika i fakt, że części poruszają się w stałym tempie.

Jeśli wstawisz w środek połączenie z chmurą, dorzucasz nie tylko dodatkową latencję, ale też jej zmienność (jitter). System może przeciętnie mieścić się w 50 ms, ale raz na jakiś czas połączenie dociąży inny ruch i nagle masz 200 ms. Efekt: wyrzucany jest nie ten element, który miał zostać odrzucony.

Edge AI wykonuje inferencję lokalnie, więc eliminuje dużą i nieprzewidywalną składową opóźnienia. Chmura wciąż ma rolę: zarządza modelami, gromadzi dane, uczy nowe wersje, ale nie siedzi w pętli sterowania.

Kluczowe zastosowania edge AI w przemyśle i infrastrukturze

Wizyjna kontrola jakości na linii produkcyjnej

Systemy wizyjne są naturalnym polem dla edge AI. Kamery generują ogromne ilości danych, a decyzje trzeba podejmować w locie. Zamiast wysyłać wideo do chmury, umieszcza się model detekcji defektów bezpośrednio na:

• inteligentnej kamerze z akceleratorem AI,
• przemysłowym komputerze (IPC) przy taśmie,
• bramce edge obsługującej kilka stanowisk.

Przykłady praktyczne:

• detekcja pęknięć, zarysowań, braków etykiety, błędnych nadruków,
• sprawdzanie kompletności zestawów (czy wszystkie elementy znajdują się w opakowaniu),
• weryfikacja montażu (czy śrubki są dokręcone, złącza wpięte).

Najważniejsze punkty

• Edge AI przenosi inferencję bliżej maszyn i czujników, dzięki czemu dane surowe często w ogóle nie opuszczają zakładu, a do chmury trafiają jedynie agregaty i metadane.
• W zastosowaniach przemysłowych kluczowe są niskie opóźnienia, niezależność od łącza oraz niższe koszty transferu – dlatego decyzje czasokrytyczne realizuje się na brzegu sieci zamiast w chmurze.
• Edge AI pomaga spełnić wymogi regulacyjne i prywatności, bo wrażliwe dane z produkcji, energetyki czy farmacji mogą pozostać w obrębie zakładu lub kraju.
• Środowiska przemysłowe są różnorodne i często oparte na starych systemach OT, więc inteligencję „dokleja się” na bramkach, IPC czy inteligentnych czujnikach, bez wymiany istniejących sterowników.
• Przykłady takie jak kontrola jakości wizyjnej na szybkiej linii pokazują, że przetwarzanie obrazu w chmurze bywa zbyt wolne; umieszczenie modelu na lokalnym edge boxie usuwa wąskie gardło.
• Fog computing i lokalne centra danych pełnią rolę pośrednią między pojedynczym urządzeniem edge a chmurą, agregując dane, wykonując cięższą analitykę i zarządzając flotą urządzeń na brzegu.
• Architektura systemu może obejmować AI on-device (bezpośrednio w kamerze, czujniku, PLC), na bramce przemysłowej lub w lokalnym klastrze, co pozwala dobrać kompromis między mocą obliczeniową, opóźnieniami i kosztami.

Źródła

• IEEE Standard for Fog Computing: Conceptual Model. IEEE Standards Association (2018) – Model i definicje fog/edge w systemach rozproszonych
• NIST Definition of Edge Computing. National Institute of Standards and Technology (2020) – Definicje edge, relacja do chmury i przetwarzania rozproszonego
• Industrial Edge Computing: Enabling Digital Transformation at the Edge. Siemens (2021) – Zastosowania edge w przemyśle, integracja z PLC i SCADA
• Edge Computing in the Industrial Internet of Things. Industrial Internet Consortium (2019) – Architektury edge/fog dla środowisk przemysłowych
• Reference Architecture Model Industrie 4.0 (RAMI 4.0). Plattform Industrie 4.0 (2015) – Model referencyjny dla systemów przemysłowych, warstwy edge
• Distributed Computing in the 5G Era: Fog and Edge Computing for Industrial Applications. 5G-ACIA (2020) – Latencja, niezawodność i wymagania czasu rzeczywistego
• Artificial Intelligence at the Edge: A Survey. ACM Computing Surveys (2022) – Przegląd technik AI na urządzeniach edge i bramkach
• Edge AI: Vision Processing for Industrial Automation. Texas Instruments (2020) – Przykłady kontroli wizyjnej i inferencji na brzegu sieci
• Deploying AI at the Edge in Manufacturing. McKinsey & Company (2021) – Motywacje biznesowe: koszty, opóźnienia, niezawodność, ROI