Agenty AI w przemysłowym IoT: od predykcyjnego utrzymania ruchu po autonomiczne operacje

Przez dwie dekady przemysłowe IoT oznaczało potoki danych: czujniki zasilały bazy szeregów czasowych, pulpity rysowały wykresy, a człowiek prędzej czy później coś klikał. Ten model wciąż sprawdza się w raportowaniu, ale rozpada się w chwili, gdy oczekujemy od systemu, by decydował. Agenty AI wypełniają tę lukę. Postrzegają surową telemetrię, wnioskują na jej podstawie z użyciem zarówno klasycznych modeli, jak i dużych modeli językowych, oraz uruchamiają działania przez te same kanały MQTT i OPC-UA, którymi już posługują się Twoje sterowniki PLC. W tym artykule pokazujemy, jak projektujemy agentowe systemy IoT w FSS, gdzie umieszczamy zabezpieczenia i dlaczego siłownia jachtu oraz instalacja HVAC w hotelu okazują się architektonicznie identyczne.

Czym agent AI naprawdę jest (a czym nie jest)

Agent AI to nie chatbot doczepiony do ekranu SCADA. To proces programowy o trzech trwałych właściwościach: obserwuje strumień stanu, utrzymuje wewnętrzną reprezentację celów i ograniczeń oraz wybiera działania przesuwające stan w kierunku celów. Tradycyjna automatyka – pętle PID, silniki regułowe, macierze alarmów – ma tę trzecią właściwość, lecz w żadnym elastycznym sensie brak jej dwóch pierwszych. Regulator PID nie potrafi wywnioskować, dlaczego dryf wartości zadanej koreluje z uszkadzającym się łożyskiem trzy metry wyżej w ciągu procesu. Agent potrafi, ponieważ przenosi kontekst w czasie i między sygnałami.

Kanoniczna pętla agenta to percepcja, planowanie, działanie. W środowisku przemysłowym percepcja oznacza pobieranie telemetrii z podłączonych urządzeń, danych wzbogacających z systemów ERP lub utrzymania ruchu oraz nieustrukturyzowanych sygnałów, takich jak notatki operatorów czy klatki z kamer. Planowanie to miejsce, w którym zachodzi wnioskowanie: klasyczne wykrywanie anomalii, wyszukiwanie podobieństw wektorowych względem historycznych sygnatur awarii lub wywołanie LLM na tle katalogu narzędzi. Działanie to zamknięcie pętli – opublikowanie zmiany wartości zadanej, otwarcie zgłoszenia, powiadomienie technika lub, w trybie w pełni autonomicznym, bezpośrednie wysterowanie elementu wykonawczego.

Architektura referencyjna agentowego IoT

Produkcyjny stos agentowy ma pięć warstw. Wdrażamy jego warianty na platformie Azure dla klientów z branży hotelarskiej oraz w hybrydowych topologiach edge-cloud dla klientów morskich, gdzie łącza satelitarne bywają przerywane.

Warstwa urządzeń – płytki PCB, czujniki, bramki. Firmware publikuje ustrukturyzowaną telemetrię przez MQTT z QoS 1, ze znacznikami czasu na poziomie pól z zdyscyplinowanego zegara RTC.
Pobieranie i normalizacja – Azure Event Hubs lub IoT Hub rozgałęzia komunikaty do procesora strumieniowego, który uzgadnia jednostki, stosuje bliźniaki urządzeń (device twins) i emituje kanoniczne zdarzenia.
Stan i pamięć – magazyn gorący (Redis, Cosmos DB) dla bieżącego stanu urządzeń, magazyn zimny (ADLS, Parquet) dla historycznego uczenia oraz magazyn wektorowy dla przywoływania opartego na osadzeniach.
Środowisko uruchomieniowe agenta – sama pętla, zwykle skonteneryzowana, z definicjami narzędzi, szablonami promptów oraz deterministycznym silnikiem polityk otaczającym wszelkie wywołania LLM.
Wykonanie i audyt – podpisane komunikaty poleceń z powrotem do urządzeń oraz niezmienny dziennik każdej decyzji agenta, każdego wywołanego narzędzia i każdego zaobserwowanego wejścia.

Warstwa audytu jest bezdyskusyjna. W chwili, gdy agent może zmienić stan fizyczny, musisz być w stanie odtworzyć, sześć miesięcy później, dokładnie dlaczego zrobił to, co zrobił. Traktujemy dziennik decyzji jako pełnoprawny produkt danych, przeszukiwalny po identyfikatorze zgłoszenia, identyfikatorze urządzenia i nazwisku operatora.

Wykrywanie anomalii sterowane przez LLM

Klasyczne wykrywanie anomalii – lasy izolacji, autoenkodery, statystyczne sterowanie procesem – wciąż wykonuje większość ciężkiej pracy. LLM wkraczają tam, gdzie metody klasyczne są najsłabsze: wyjaśnianie, korelacja między heterogenicznymi sygnałami oraz czytelna dla człowieka klasyfikacja zgłoszeń. Typowy wzorzec to detektor dwuetapowy. Etap pierwszy to szybki model statystyczny działający blisko danych. Etap drugi to agent, który, gdy etap pierwszy się uruchomi, pobiera ostatnią godzinę istotnych sygnałów, wyszukuje trzy najbardziej podobne incydenty historyczne z indeksu wektorowego i tworzy ustrukturyzowany raport triage.

Sztuką jest trzymanie LLM na krótkiej smyczy. Ograniczamy wynik do schematów JSON, wymuszamy wywołania narzędzi zamiast wolnego tekstu przy każdym pobieraniu danych i nigdy nie pozwalamy modelowi improwizować poleceń dla urządzeń. Model proponuje; deterministyczny silnik polityk rozstrzyga. To ta sama dyscyplina, którą stosujemy przy budowie asystentów kodu w stylu Codex dla naszych własnych zespołów inżynierskich – wnioskowanie jest generatywne, wykonanie jest bramkowane.

Osadzenia wektorowe w predykcyjnym utrzymaniu ruchu

Predykcyjne utrzymanie ruchu historycznie oznaczało modele per zasób: wytrenuj regresor na każdą pompę, przetrenuj kwartalnie, wdróż ponownie. To skaluje się słabo dla flot liczących tysiące jednostek. Przywoływanie oparte na osadzeniach zmienia ekonomikę. Wyodrębniamy wektory cech o stałej długości z każdego zdarzenia utrzymania ruchu – widmo drgań, przebieg temperatury, pobór prądu, wiek, ostatni serwis – i zapisujemy je w bazie wektorowej. Gdy nadejdzie nowe zdarzenie, wyszukiwanie podobieństw zwraca najbliższe dopasowania historyczne wraz z dołączonymi do nich rozwiązaniami.

# Pseudokod dla przywoływania awarii na podstawie osadzeń
event_vector = encode(telemetry_window, asset_metadata)
neighbors = vector_index.search(event_vector, k=5, filter={"asset_class": "centrifugal_pump"})
context = [n.payload for n in neighbors if n.score > 0.82]

proposal = agent.reason(
    current_event=event_vector,
    historical_context=context,
    available_tools=["open_work_order", "adjust_setpoint", "page_engineer"],
)

Ten wzorzec działa, ponieważ tryby awarii generalizują się między zasobami w sposób, w jaki nie robią tego wskaźniki nagłówkowe. Awaria łożyska w chłodziarce hotelowej wygląda, w przestrzeni cech, uderzająco podobnie do awarii łożyska w pompie stabilizatora jachtu. Mamy infrastrukturę AI dostrojoną dokładnie do tego rodzaju przywoływania między flotami i w naszych testach porównawczych konsekwentnie przewyższa ona modele per zasób, gdy tylko flota przekroczy kilkaset jednostek.

Integracja agentów z MQTT i OPC-UA

Agenty są bezużyteczne, jeśli nie potrafią porozumieć się z obiektem. MQTT to nasz domyślny wybór dla nowych wdrożeń, ponieważ czysto komponuje się z brokerami chmurowymi i wspiera semantykę QoS oraz komunikatów zatrzymanych (retained), której agenty potrzebują – jeśli nie masz tego jeszcze w małym palcu, nasz przewodnik po MQTT dla IoT omawia podstawy. Dla istniejących instalacji przemysłowych (brownfield) OPC-UA jest nie do uniknięcia, a właściwym ruchem jest bramka mostkująca przestrzenie adresowe OPC-UA na tematy MQTT ze stabilną konwencją nazewnictwa.

Agent subskrybuje wzorce tematów, a nie pojedyncze tematy. Agent fabryczny może obserwować plant/+/line/+/asset/+/telemetry, podczas gdy agent jachtowy obserwuje vessel/+/system/+/state. Konwencje tematów są częścią kontraktu; ustalamy je sztywno na wczesnym etapie każdego projektu i wersjonujemy w firmware urządzeń. Tematy poleceń są lustrzane: plant/.../command z podpisanymi ładunkami i krótkim TTL, tak aby przeterminowane polecenie nigdy nie zadziałało po naprawieniu się partycji sieci.

Zamykanie pętli: sterowanie autonomiczne z zabezpieczeniami

To tutaj większość zespołów słusznie się waha. Pozwolenie agentowi na zmianę stanu fizycznego to zupełnie inna kategoria ryzyka niż pozwolenie mu na redagowanie wiadomości na Slacku. Stosujemy czterostopniową drabinę autonomii, a każda klasa zasobów jest jawnie przypisana do stopnia:

Stopień 0 – tylko obserwacja. Agent raportuje, nigdy nie proponuje.
Stopień 1 – sugerowanie. Agent proponuje działania; człowiek musi je zatwierdzić przed wykonaniem.
Stopień 2 – działanie z prawem weta. Agent wykonuje po opóźnieniu (zwykle 30 do 300 sekund), podczas którego człowiek może anulować.
Stopień 3 – autonomia. Agent działa natychmiast w ściśle ograniczonej przestrzeni działań, z limitami częstotliwości i możliwością wycofania.

Większość zasobów pozostaje na Stopniu 1 lub 2 na zawsze i to jest w porządku. Stopień 3 jest zarezerwowany dla działań, które są rzeczywiście odwracalne, ograniczone i krytyczne czasowo – takich jak korekta wartości zadanej HVAC o mniej niż dwa stopnie lub włączenie pompy rezerwowej do pracy. Wszystko, co dotyka blokad bezpieczeństwa, pozostaje na Stopniu 0 z zasady. Stopień autonomii jest zakodowany w bliźniaku urządzenia i egzekwowany przez silnik polityk, a nie przez prompt agenta. Jeśli model zhalucynuje działanie Stopnia 3 na zasobie Stopnia 1, zostaje ono odrzucone, zanim w ogóle dotrze do brokera.

UX z człowiekiem w pętli

Stopień 1 i Stopień 2 działają tylko wtedy, gdy interfejs człowieka jest szybki. Powiadomienie push z zatwierdzeniem lub wetem jednym dotknięciem, jasne podsumowanie, dlaczego agent chce zadziałać, oraz odnośnik do wspierającej telemetrii. Tarcie zabija te przepływy pracy; jeśli zatwierdzenie zajmuje więcej niż dziesięć sekund, operatorzy przestają czytać i zaczynają przybijać pieczątki bez namysłu. Budujemy te interfejsy w ramach naszych dostaw sterowania mobilnego i traktujemy je z tą samą rzetelnością co firmware.

Wdrożenie agenta: edge kontra chmura

Miejsce działania agenta ma znaczenie. Wdrożenie w chmurze jest prostsze: pełny dostęp do modelu, łatwe iterowanie, scentralizowane dzienniki. Wdrożenie na brzegu sieci (edge) jest trudniejsze, ale nieuniknione, gdy liczy się opóźnienie, gdy łączność jest zawodna lub gdy ograniczenia suwerenności danych zabraniają ich wyprowadzania. Pragmatyczną odpowiedzią prawie zawsze jest hybryda. Mały, zdystylowany model działa na brzegu dla szybkich pętli – zwykle klasyfikacja anomalii i prosty wybór działań. Większy model w chmurze obsługuje wolne pętle – uczenie międzyflotowe, analizę przyczyn źródłowych i cotygodniowe przetrenowanie.

Na brzegu celujemy w sprzęt zdolny uruchomić model o 1–3 miliardach parametrów z precyzją int8: NVIDIA Jetson Orin Nano dla ciężkich obciążeń, i.MX 8M Plus dla średniego zakresu lub dobrze oprzyrządowany ESP32-S3 dla najprostszych zadań dopasowywania wzorców. Strona chmurowa działa na Azure z punktami końcowymi modeli osłoniętymi naszą warstwą polityk. Podział rządzi się prostą regułą: jeśli działanie musi nastąpić w mniej niż sekundę, decyzja mieszka na brzegu. W przeciwnym razie mieszka w chmurze.

Przypadki użycia w różnych branżach

Hala produkcyjna

Agent linii obserwuje w czasie rzeczywistym przepustowość, wskaźnik braków oraz OEE. Gdy braki narastają na prasie do tłoczenia, koreluje to z drganiami i temperaturą matrycy, pobiera trzy najbardziej podobne epizody historyczne i rekomenduje albo zmniejszenie prędkości podawania (Stopień 2), albo wymianę matrycy (Stopień 1). Dziennik decyzji jest co noc eksportowany do stosu BI zespołu jakości za pomocą tych samych wzorców integracji, których używamy do synchronizacji z ERP.

Hotel luksusowy

Agent obiektu jednocześnie odpowiada za komfort gości i zużycie energii. Uczy się odpowiedzi termicznej każdego pokoju, przewiduje obłożenie na podstawie zameldowań w systemie PMS i wstępnie przygotowuje pokoje przed przyjazdem – wszystko na Stopniu 3 w obrębie ciasnej obwiedni wartości zadanych. Gdy gość ręcznie zmieni wartość zadaną przez tablet w pokoju, agent natychmiast ustępuje i zapisuje tę zmianę jako dane treningowe. Oszczędności energii rzędu 15 do 25 procent są rutynowe, bez żadnej odczuwalnej dla gościa zmiany.

Superjacht

Agent jednostki działa w dużej mierze na brzegu, ponieważ łącze satelitarne jest drogie i przerywane. Monitoruje systemy obciążenia hotelowego – HVAC, wytwornice wody, pompy wód szarych – oraz podsystemy siłowni, z rygorystycznym rozdziałem między tymi dwiema domenami. Działania Stopnia 2 na systemach hotelowych, wyłącznie Stopień 0 na czymkolwiek związanym z napędem. Gdy jednostka wraca do mariny z niezawodną łącznością, agent brzegowy synchronizuje swój dziennik decyzji z chmurą na potrzeby uczenia obejmującego całą flotę innych jednostek armatora.

Budowanie zespołu i łańcucha narzędzi

Agentowe IoT to nie pojedyncza dyscyplina. Potrzebuje inżynierów firmware rozumiejących timing i zasilanie, inżynierów chmury rozumiejących systemy sterowane zdarzeniami, inżynierów ML rozumiejących ewaluację i dryf oraz ekspertów dziedzinowych rozumiejących, co w ich kontekście naprawdę znaczy „bezpieczny”. Największy błąd, jaki widujemy, to zespoły traktujące agenta jako problem ML, gdy w rzeczywistości jest to problem systemowy. Model to może dwadzieścia procent pracy. Pozostałe osiemdziesiąt to instalacja, obserwowalność i polityki.

Nasz własny łańcuch narzędzi mocno opiera się na wzorcach agentowych, które sproduktyzowaliśmy: rejestry narzędzi z silnymi schematami, wersjonowanie promptów powiązane z gitem, systemy ewaluacyjne odtwarzające historyczne incydenty wobec nowych wersji modeli oraz DSL polityk pozwalający ekspertom dziedzinowym wyrażać ograniczenia bez pisania w Pythonie. Nic z tego nie jest efektowne. Wszystko to jest różnicą między demem a systemem.

Od czego zacząć

Jeśli po raz pierwszy oceniasz agentowe IoT, nie zaczynaj od autonomii. Zacznij od wyjaśnień. Podłącz agenta Stopnia 0, który tworzy ustrukturyzowane raporty triage dla incydentów, które Twój zespół i tak już obsługuje ręcznie. Zmierz, jak często diagnoza agenta zgadza się z ostateczną przyczyną źródłową. Gdy ta liczba będzie konsekwentnie powyżej osiemdziesięciu procent na reprezentatywnej próbie, zapracujesz na prawo przejścia do Stopnia 1 na wąskim wycinku zasobów. Wypracuj każdy stopień; nie zakładaj go z góry.

Od czujnika przez wgląd po działanie to długa droga, a mosty między tymi etapami są miejscem, w którym upada większość projektów. Jeśli chcesz omówić, jak architektura agentowa mogłaby wyglądać dla Twojej floty, nasz zespół buduje takie systemy od początku do końca – od PCB przez firmware, chmurę po agenta. Zacznij od naszej usługi urządzeń podłączonych lub poznaj szerszą platformę IoT, którą budujemy na jej wierzchu.