AI w utrzymaniu ruchu przestaje być hasłem z konferencji. Na naszym ostatnim live razem z Wojciechem Piwońskim z firmy Operivo pokazaliśmy pełną ścieżkę: od czerwonej diody na wyspie ET 200SP, przez diagnozę z agentem AI podłączonym do projektu TIA Portal V21 i do sterownika S7-1200 G2, aż po domknięte zlecenie pracy w CMMS.
W tym wpisie znajdziesz najważniejsze slajdy z prezentacji i wnioski, które możesz sprawdzić u siebie w dziale UR jeszcze w tym tygodniu.
Kto prowadził webinar?
Część techniczną (agent AI, TIA Openness, PLC Web API) poprowadził Kamil Biedulski z ControlByte. Część procesową, czyli to, co musi się wydarzyć w organizacji UR, żeby z diagnozy została realna wartość, poprowadził Wojciech Piwoński z Operivo. Operivo zajmuje się audytami utrzymania ruchu, analizą krytyczności majątku, strategiami prewencji i operacjonalizacją systemów CMMS/EAM.
Dlaczego AI w utrzymaniu ruchu potrzebuje dobrych danych?
Utrzymanie ruchu pracuje w wielu systemach naraz: ERP, MES, CMMS, SCADA, historian, a na dole PLC i projekt TIA. W praktyce te systemy rzadko są ze sobą powiązane, a łącznikiem między nimi jest zwykle człowiek, nie dane.
Agent AI potrafi czytać dane ze wszystkich warstw. Nie tworzy ich jednak sam: korzysta z tego, co ktoś wcześniej wpisał i powiązał. Kluczowy warunek to ten sam identyfikator obiektu w ERP, CMMS, SCADA i projekcie PLC. Bez tego agent nie połączy alarmu z historią awarii.
Gdzie wdrożenia AI w UR się wykładają
Wojtek wskazał cztery obszary, na których najczęściej kończą się ambitne plany:
- Dane w CMMS: zlecenia z opisem „naprawiono”, bez kodu przyczyny i użytych części, awarie przypisane do całej linii zamiast do konkretnego obiektu.
- Dokumentacja: schematy niezgodne ze stanem po modyfikacjach, projekt PLC u integratora inny niż wgrany do sterownika. Z jego doświadczenia poniżej 10% firm ma dokumentację cyfrową i czytelną dla AI.
- Procesy: zgłoszenia telefonem albo „na korytarzu”, zmiany bez procesu MOC.
- Odpowiedzialność: brak właściciela danych zasobu, nikt nie weryfikuje wpisów ani nie zatwierdza zamknięcia zlecenia.
AI nie naprawia danych ani procesów. Dobre fundamenty skaluje, słabe powiela szybciej. Zdigitalizowany chaos to nadal chaos.
Cykl życia zlecenia pracy i miejsce dla agenta AI
Zlecenie pracy przechodzi przez siedem kroków: zgłoszenie, ocena i decyzja, zlecenie pracy (WO), wykonanie, wpis technika, zarządzanie zmianą oraz zamknięcie i analiza. Dane z kroków 1, 3 i 5 zasilają diagnozę AI przy kolejnej awarii. Pusty CMMS oznacza działanie bez kontekstu, a AI bez kontekstu halucynuje albo jest bezużyteczne.
Przed pracą liczy się jakość zgłoszenia: konkretny obiekt z hierarchii maszyn, symptom, priorytet wynikający z krytyczności (a nie „wszystko na najwyższym”), historia obiektu oraz zaplanowane części, uprawnienia i LOTO. W trakcie pracy wchodzi agent AI. Po pracy technik domyka zlecenie: kod przyczyny, czynności, części, czas przestoju.
W procesie usuwania awarii AI skraca kroki od diagnozy zdalnej, przez lokalizację, po przyczynę i procedurę, a na końcu domyka dokumentację. Naprawę fizyczną nadal wykonuje technik.
Narzędzia: TIA Openness i PLC Web API
Agent, którego użyliśmy, to Claude Code z naszym narzędziem ControlByteTiaCli. Dostał dwie drogi do danych:
- Offline, czyli projekt: przez TIA Openness V21 agent czyta sprzęt, tagi, kod i parametry kanałów. Odpowiada na pytania „co” i „gdzie”.
- Online, czyli sterownik: przez PLC Web API (HTTPS, JSON-RPC 2.0) agent czyta bufor diagnostyczny, alarmy i wartości. Odpowiada na pytanie „co się dzieje”.
Agent łączy oba źródła: alarm ze sterownika dostaje adres, moduł, kanał i typ czujnika z projektu.
Trzecim, docelowym źródłem jest CMMS. Agent może przed diagnozą pobrać historię awarii maszyny i wcześniejsze przyczyny, a po naprawie przygotować szkic wpisu. Zapis do CMMS zawsze następuje po akceptacji technika.
Stanowisko demo
Na stanowisku pracował sterownik S7-1200 G2 (CPU 1212FC), napęd SINAMICS G120 i wyspa ET 200SP. Na wyspie zasymulowaliśmy uszkodzony obwód czujnika temperatury Pt100.
Klasyczna diagnostyka: technik z laptopem w TIA online
W klasycznym podejściu technik potrzebuje laptopa z TIA Portal V21 i licencją, projektu zgodnego z tym, co jest w PLC, oraz połączenia online. Musi wiedzieć, gdzie szukać (bufor diagnostyczny, widok urządzenia, tabela obserwacji) i co oznaczają wartości: 32767 to przerwa obwodu, a QI = FALSE to wartość nieważna. Do tego schematy, żeby znaleźć moduł i zaciski.
Dane są te same co u agenta. Różnica polega na tym, kto je zbiera, łączy i tłumaczy na kroki naprawy.
TIA Openness V21: projekt dostępny z kodu
TIA Openness to oficjalne API .NET Siemensa do pracy z projektem TIA Portal, dostępne w praktycznie każdej instalacji. Żeby z niego korzystać, konto Windows musi należeć do grupy „Siemens TIA Openness”. W V21 jeden plik Siemens.Engineering.dll podzielono na moduły (Base, Step7, WinCC). Tryby diagnostyczne naszego narzędzia tylko czytają projekt: nie zapisują i nie kompilują.
Workflow wygląda tak: CLI dołącza się do otwartego projektu, robi snapshot (sprzęt, adresy I/O, tagi, kod każdego bloku), a potem możesz po prostu zapytać agenta: „Gdzie jest czujnik B1?” albo „Kto steruje Q0.3?”. Dwa snapshoty można porównać i zobaczyć, co ktoś zmienił w programie.
Z projektu agent zna mapę I/O, parametry kanałów, cross-reference i dane sprzętu: numery zamówieniowe, firmware, adresy IP. Dodatkowo generuje automatyczne uwagi, np. podwójną cewkę, wyjście, którego żaden kod nie ustawia, czy mieszane wersje firmware przy tym samym numerze zamówieniowym.
Demo: gdzie jest czujnik B1?
Technik dostaje zgłoszenie „błąd czujnika temperatury B1” i jeszcze nie widzi maszyny. Pyta agenta, na którym module i kanale jest B1. Odpowiedź przychodzi po kilkunastu sekundach: ET 200SP, slot 2, moduł AI 4xRTD/TC, kanał 0, czujnik Pt100 w podłączeniu 4-przewodowym, wraz z nazwą zmiennej, bitem statusu i wersją firmware modułu.
To ważne, bo technik wie, co zabrać z magazynu, zanim w ogóle otworzy szafę. Jak zauważył Wojtek, czasem do czujnika można dostać się dopiero po kilku godzinach, gdy miejsce montażu wystygnie.
PLC Web API w S7-1200 G2
PLC Web API jest wbudowane w CPU S7-1500 i, od niedawna, S7-1200 G2. Działa przez HTTPS (JSON-RPC 2.0, endpoint /api/jsonrpc) i nie wymaga TIA Portal: wystarczy sieć do sterownika i użytkownik z uprawnieniami. Agent korzystał z metod Api.Login, Plc.ReadOperatingMode, DiagnosticBuffer.Browse, Alarms.Browse i PlcProgram.Read. Uwaga: PlcProgram.Read przyjmuje tylko zmienne symboliczne.
Konfiguracja w TIA V21 sprowadza się do czterech kroków: włączenie serwera WWW (tylko HTTPS), utworzenie użytkownika tylko do odczytu w runtime rights, download i test, a na koniec przechowywanie hasła poza zasięgiem AI. Bez logowania każda metoda zwraca „Permission denied”, więc dostęp nadajemy świadomie.
Jedno polecenie --plc-diag przechodzi przez logowanie, tryb pracy, bufor, alarmy i wartości I/O, a następnie samo interpretuje wynik: 7FFFh to przepełnienie lub przerwa przewodu, 8000h to niedomiar lub zwarcie, QI = FALSE to wartość oznaczona przez moduł jako nieważna.
Wynik diagnozy i naprawa
Wniosek agenta: moduł działa i raportuje, otwarty jest obwód pomiarowy (czujnik lub kabel). Sprawdź około 108 Ω przy 20 °C, OL na mierniku oznacza przerwę.
Po pomiarze i ponownym podłączeniu czujnika diody zgasły, a agent zdalnie potwierdził, że alarm nie jest aktywny i odczyt temperatury (21,6 °C) jest wiarygodny. Przy okazji wyłapał, że zegar sterownika jest ustawiony na 2012 rok, co przy certyfikatach OPC UA może szybko stać się kolejnym problemem.
HMI vs agent AI: ten sam alarm, inny zakres pomocy
Panel HMI mówi tylko „Wire break” z numerem modułu. Agent dokłada: co się stało, gdzie, dlaczego, co zrobić, jakie części wziąć i co zrobić po naprawie. HMI odpowiada na pytanie CO. Agent dodaje GDZIE, DLACZEGO i CO ZROBIĆ.
Dla doświadczonego automatyka część tych wskazówek będzie oczywista. Dla osoby, która dopiero przyszła do UR po technikum czy studiach, taka ścieżka krok po kroku jest na wagę złota.
Bezpieczeństwo: agent pomaga, człowiek decyduje
Zanim wdrożysz takie rozwiązanie na produkcji, przeanalizuj sześć obszarów:
- Minimalne uprawnienia: osobne konto PLC tylko do odczytu, nigdy Admin.
- Hasła poza AI: dane logowania zapisuje technik w swoim profilu, agent ich nie widzi.
- Domyślnie tylko odczyt: snapshot i diagnostyka nie zapisują ani nie kompilują projektu.
- Sieć OT: stacja inżynierska w segmencie OT, PLC niedostępny z internetu, tylko HTTPS.
- Dane w chmurze: treść projektu trafia do modelu AI, więc musi to być zgodne z polityką firmy. Alternatywą są lokalne modele LLM na serwerze firmowym.
- Ślad i odpowiedzialność: logi narzędzia, zapis do CMMS po akceptacji. Za naprawę odpowiada technik.
Po naprawie: domknięcie zlecenia pracy
Naprawa skończona, ale zlecenie jeszcze nie. Najczęstsze luki to przyczyna wpisana jako „inne” albo „naprawiono”, części wymienione, ale niewpisane, przestój wpisany z pamięci i zmiana w PLC bez śladu w dokumentacji. Każda z tych luk wraca przy następnej awarii jako brak danych do diagnozy.
Tu AI realnie oszczędza czas. Agent brał udział w diagnozie, więc przygotowuje szkic zlecenia: obiekt, symptom, przyczynę, czynności, przestój z bufora diagnostycznego i weryfikację. Technik sprawdza, poprawia to, czego AI nie widzi w warstwie fizycznej, i zatwierdza. Odpowiedzialność za wpis nadal zostaje po jego stronie.
Zarządzanie zmianą (MOC)
Management of Change jest szczególnie istotny w automatyce i elektryce, a w branżach regulowanych, jak rafinerie czy chemia, wręcz wymagany. AI pomaga wykryć zmianę (porównanie projektu offline ze sterownikiem, snapshotów, wersji firmware), przygotować szkic wniosku MOC i przypilnować, żeby dokumentacja nadążała za zmianą. Ryzyko ocenia i zmianę zatwierdza człowiek.
Każde domknięte zlecenie zasila kolejną diagnozę. Bez wpisu technika i bez MOC pętla się rwie, a kolejny technik przy następnej awarii znowu zaczyna od zera. Na bazie zgromadzonej historii AI może też zasugerować lepszy plan prewencyjny.
3 rzeczy do sprawdzenia w najbliższym tygodniu
- Przeanalizujcie 20 ostatnich zleceń awaryjnych. Czy mają obiekt z hierarchii, kod przyczyny i wpisane części?
- Porównajcie projekt PLC z archiwum z tym w sterowniku na jednej krytycznej maszynie. Czy są identyczne?
- Ustalcie, kto akceptuje wpis technika i jak aktualizujecie dokumentację. Jeśli nikt, AI nie będzie miało kontekstu.
Jeśli chcesz przejść przez swój cykl zlecenia z ekspertem, Operivo proponuje 30-minutową rozmowę: operivo.com.
Najczęstsze pytania
Czy agent AI może zmieniać program w sterowniku?
Technicznie tak: przez Openness i Web API z pełnymi uprawnieniami agent mógłby nadpisywać wartości, a nawet uruchomić napęd. Dlatego w utrzymaniu ruchu konfigurujemy konto tylko do odczytu, a każda zmiana w PLC lub projekcie wymaga decyzji człowieka.
Które sterowniki Siemens mają PLC Web API?
S7-1500 oraz S7-1200 drugiej generacji (G2). W starszych S7-1200 tej funkcji nie ma.
Czy dane z projektu muszą trafiać do chmury?
Nie. Jeśli polityka firmy nie pozwala na wysyłanie programu PLC czy dokumentacji poza zakład, można użyć lokalnych modeli LLM na serwerze firmowym. Coraz częściej takie lokalne modele oferują też dostawcy systemów CMMS.
Od czego zacząć wdrożenie AI w utrzymaniu ruchu?
Od danych i procesu, nie od narzędzia. Uporządkuj hierarchię obiektów, kody przyczyn i zasady domykania zleceń w CMMS. Dopiero na takim fundamencie agent AI daje powtarzalną wartość.
Podsumowanie
AI w utrzymaniu ruchu skraca drogę od alarmu do właściwego zacisku, zanim ktoś otworzy szafę. Projekt mówi agentowi co i gdzie, sterownik mówi co się dzieje, a CMMS dostarcza historię. Warunek jest jeden: dane i procesy w UR muszą być uporządkowane, a każdą rekomendację AI weryfikuje i zatwierdza człowiek.
Więcej o AI w automatyce przeczytasz we wpisach o analizie dokumentacji technicznej z ChatGPT, lokalnym agencie AI w CODESYS, predykcyjnym utrzymaniu ruchu z MLnext oraz wersjonowaniu projektów TIA Portal w Git. Szczegóły PLC Web API znajdziesz w dokumentacji Siemens Industry Online Support.
Jeśli chcesz samodzielnie podłączyć Claude Code czy Codex do TIA Portal przez Openness i generować kod PLC z pomocą AI, sprawdź nasz kurs:
