AI w utrzymaniu ruchu: od reakcji na awarię do predykcji usterek

Od gaszenia pożarów do predykcji – jak zmienia się utrzymanie ruchu

Reakcyjne, prewencyjne, predykcyjne i preskrypcyjne utrzymanie ruchu

Utrzymanie ruchu przez lata opierało się na trzech podejściach: reakcyjnym, prewencyjnym i predykcyjnym. Od kilku lat dochodzi do tego także poziom preskrypcyjny. Każdy z nich inaczej wpływa na koszty, dostępność maszyn i organizację pracy służb UR.

Utrzymanie reakcyjne to typowe „gaszenie pożarów”. Maszyna pracuje tak długo, aż się zatrzyma. Interwencja następuje dopiero po awarii. Proste, nie wymaga planowania, ale kończy się drogimi przestojami, nerwami i brakiem kontroli nad kosztami.

Utrzymanie prewencyjne polega na wykonywaniu przeglądów i wymian według harmonogramu: co ileś godzin pracy, co kwartał, raz w roku. Daje więcej kontroli i zmniejsza liczbę awarii, ale często prowadzi do wymiany elementów „na wszelki wypadek”, zanim realnie się zużyją.

Utrzymanie predykcyjne (predictive maintenance) opiera się na danych z maszyn. Zużycie ocenia się na podstawie drgań, temperatury, prądu, liczby cykli, alarmów sterownika. Zamiast „co pół roku”, element wymienia się wtedy, gdy model predykcji usterek maszyn wykazuje rosnące ryzyko awarii.

Utrzymanie preskrypcyjne (prescriptive maintenance) to krok dalej: system nie tylko przewiduje usterkę, ale też sugeruje konkretne działania, np. „zmniejsz prędkość o 10%”, „zaplanuj wymianę łożysk w ciągu 5 dni”, „zmodyfikuj parametry falownika”. To połączenie prognozy z rekomendacją.

Jak wyglądał typowy dzień UR przed wykorzystaniem AI

W wielu zakładach schemat był (i często nadal jest) podobny. Telefon z produkcji: „Linia 3 stoi, nie idzie podajnik”. Zespół UR rzuca to, co robi, biegnie na halę, próbuje rozpoznać przyczynę. Szybka diagnoza na podstawie doświadczenia, obejrzenie maszyny, nasłuchiwanie dźwięków, sprawdzanie temperatury ręką, analiza kilku komunikatów na HMI.

Jeżeli usterka jest prosta (czujnik, krańcówka, zerwany przewód) – uda się ją usunąć kilkunastoma minutami pracy. Gorzej, jeśli „rozsypało” się łożysko na ważnym wentylatorze lub pompie. Wtedy zaczyna się kombinowanie: czy jest część na magazynie, czy trzeba ją zamawiać, czy da się przełączyć proces na inną linię, jak to zakomunikować dyrektorowi. Presja rośnie z każdą minutą przestoju.

W takim trybie UR działa w permanentnym niedoczasie. Zamiast analizować przyczyny i planować działania, ludzie zajmują się głównie gaszeniem bieżących awarii. Dane z maszyn? Zwykle gdzieś są – w sterownikach, archiwum SCADA, raportach– ale nikt nie ma czasu ich spokojnie przejrzeć, uporządkować i przełożyć na konkretne decyzje.

Główne problemy podejścia reakcyjnego

Reakcyjne utrzymanie ruchu ma kilka konsekwencji, które szczególnie dobrze widać z perspektywy dyrektora produkcji i finansów:

• Nieplanowane przestoje – linia staje w najgorszym możliwym momencie (duże zlecenie, krótki deadline). Nawet krótka awaria potrafi rozwalić harmonogram produkcji na cały dzień.
• Chaos organizacyjny – priorytety zmieniają się z godziny na godzinę. Przeglądy przesuwają się „na kiedyś”, bo każde nagłe zatrzymanie maszyny ma pierwszeństwo.
• Trudność w pokazaniu wartości UR – służby utrzymania ruchu są często postrzegane jako „koszt”, a nie „inwestycja”. Bo w Excelu widać faktury za części i roboczogodziny, ale trudno pokazać, ile przestojów udało się uniknąć.
• Wypalenie pracowników – ciągłe telefony po godzinach, noce i weekendy spędzane na awariach, poczucie, że zawsze jest się „spóźnionym o krok”.

Sam fakt, że UR zaczyna zbierać więcej danych, nie rozwiązuje problemu. Bez narzędzi analitycznych i AI utrzymanie ruchu tonie w logach, wykresach i raportach, z których trudno wyciągnąć czytelne wnioski.

Co realnie obiecuje AI w utrzymaniu ruchu – i czego nie obiecuje

Sztuczna inteligencja w UR nie jest magiczną czarną skrzynką, która sama naprawi maszyny. Jej główna rola to przetwarzanie i analiza danych z czujników szybciej i dokładniej niż człowiek, aby wcześniej wychwycić symptomy nadchodzącej awarii.

AI dobrze sprawdza się w kilku obszarach:

• wykrywanie nietypowych wzorców w danych (np. subtelne zmiany w widmie drgań łożyska),
• prognozowanie pozostałego czasu pracy (RUL) elementu na podstawie historii danych,
• łączenie sygnałów z wielu źródeł (prąd, temperatura, drgania, liczba startów) w jedną ocenę „zdrowia” maszyny,
• wskazywanie, które maszyny wymagają uwagi w pierwszej kolejności.

Czego AI nie zrobi: nie zastąpi w pełni doświadczenia mechanika ani inżyniera utrzymania ruchu, nie naprawi błędów projektowych maszyn, nie rozwiąże problemów organizacyjnych (brak części, złe planowanie produkcji). Bez udziału ludzi i zmian w procesach AI stanie się kolejnym „ładnym wykresem”, z którego nikt nie korzysta.

Przykład z praktyki: łożyska wentylatorów i analiza drgań z wykorzystaniem AI

Dobrym punktem startu są awarie łożysk w wentylatorach. Klasycznie UR działa tak: wentylator pracuje, aż zaczyna się hałas, wzrastają drgania, obudowa się grzeje. Ktoś to zauważa, zgłasza, czasem jest już za późno – łożysko się rozsypuje, wirnik ociera, maszyna staje.

W podejściu predykcyjnym zakłada się czujnik drgań i temperatury. Dane trafiają do systemu, gdzie modele AI analizują zmiany w charakterystyce drgań (amplituda, częstotliwość, widmo). Algorytm uczy się, jak wyglądają drgania zdrowego łożyska i jak stopniowo zmieniają się w miarę zużycia. Na tej podstawie może:

• wcześniej wygenerować alarm „wysokie ryzyko uszkodzenia łożyska w ciągu X dni”,
• oszacować, ile czasu zostało do awarii przy aktualnym obciążeniu (prognostyka i diagnostyka maszyn),
• pokazać UR i produkcji okno czasowe, kiedy najlepiej zaplanować postój na wymianę.

Efekt: mniej „nagłych” awarii, lepsze planowanie prac, mniejsza presja czasu i większe poczucie kontroli nad parkiem maszynowym. To właśnie przejście od czystej reakcji na awarię do przewidywania usterek dzięki AI.

Podstawy techniczne – co musi rozumieć szef UR i inżynier

Klasyczna diagnostyka vs modele uczenia maszynowego

Diagnostyka maszyn w wielu zakładach opiera się na prostych progach: jeśli temperatura przekroczy wartość X, wygeneruj alarm; jeśli drgania > Y, zatrzymaj maszynę. Taki model regułowy jest łatwy do zrozumienia, ale ma ograniczenia:

• jeden próg nie pasuje do wszystkich maszyn i warunków pracy,
• często generuje fałszywe alarmy, gdy maszyna pracuje w nietypowym, ale poprawnym trybie,
• nie wykorzystuje złożonych zależności między różnymi sygnałami.

Modele ML (machine learning) podchodzą do problemu inaczej. Nie definiuje się ręcznie wszystkich reguł. Zamiast tego pokazuje się modelowi wiele przykładów: okresów normalnej pracy, stopniowego pogarszania stanu, momentów awarii. Algorytm sam uczy się, jakie kombinacje sygnałów i ich zmiany w czasie prowadzą do problemu.

Przykład: zamiast ustawiać „drgania > 5 mm/s = alarm”, model analizuje jednocześnie drgania w kilku osiach, widmo częstotliwości, temperaturę, prąd silnika i liczbę startów na dobę. Na tej podstawie wylicza „zdrowie” maszyny w skali 0–100% albo prawdopodobieństwo awarii w określonym horyzoncie czasu.

Jakie dane wykorzystuje predykcyjne utrzymanie ruchu

AI w UR korzysta z kilku klas danych, z których każda wnosi inne informacje.

Dane czasowe (szereg czasowy):

• drgania (akcelerometry, czujniki piezoelektryczne),
• temperatura (łożysk, uzwojeń, oleju, otoczenia),
• prąd i napięcie silników,
• ciśnienia, przepływy, poziomy mediów,
• liczba cykli, czas pracy, częstotliwość start-stop.

Dane zdarzeniowe:

• logi błędów sterowników PLC i falowników,
• sekwencje alarmów w SCADA/HMI,
• informacje o zatrzymaniach awaryjnych, resetach, restartach.

Dane tekstowe i opisowe:

• raporty brygadzistów,
• notatki z CMMS („dziwny hałas”, „trudny start rano”),
• zdjęcia usterek, nagrania dźwięku.

Modele predykcji usterek maszyn potrafią łączyć te warstwy danych. Na przykład: rosnące drgania + częstsze alarmy falownika + notatki o „nierównym starcie” to mocniejszy sygnał niż sam wzrost drgań.

Podstawowe pojęcia AI bez zbędnego żargonu

Wystarczy zrozumieć kilka kluczowych terminów, żeby swobodnie rozmawiać z dostawcami rozwiązań AI i działem IT/OT.

• Model – matematyczne narzędzie, które przyjmuje dane wejściowe (np. sygnał drgań, temperaturę, prąd) i zwraca wynik (np. ryzyko awarii, pozostały czas pracy, informację „anomalne zachowanie”).
• Uczenie nadzorowane – sposób trenowania modelu, w którym pokazuje się mu dane wraz z etykietami, np. „tu była awaria łożyska”, „tu praca normalna”. Model uczy się rozróżniać te przypadki.
• Cechy (features) – przekształcone dane wejściowe, np. średnia drgań w oknie 10 sekund, energia w określonym paśmie częstotliwości, liczba startów na godzinę. Z cech model „wyciąga wnioski”.
• Trening – proces uczenia modelu na danych historycznych, w którym dobierane są parametry modelu tak, aby jak najlepiej pasowały do znanych przypadków.
• Inferencja – wykorzystanie wytrenowanego modelu „na żywo”: dane z bieżącej pracy są podawane na wejście modelu, a ten generuje aktualną prognozę lub alarm.

Rola eksperta utrzymania ruchu w projektach AI

Bez inżyniera utrzymania ruchu i doświadczonych mechaników projekty AI w fabryce zwykle kończą się rozczarowaniem. Zespół data science widzi tylko liczby, nie zna technologii procesu, nie wie, kiedy dane są „normalne”, a kiedy wynikają z błędu pomiarowego lub nietypowego trybu pracy.

Ekspert dziedzinowy jest potrzebny do:

• wyboru maszyn i sygnałów, które mają sens z punktu widzenia awaryjności i wpływu na produkcję,
• interpretacji wykresów – np. rozróżnienia: „to anomalia” vs „to efekt przejścia między recepturami”,
• definiowania etykiet dla uczenia nadzorowanego (co uznajemy za awarię, co za drobną usterkę, a co za normalny stan pracy),
• przekładania wyników modelu na procedury UR (kiedy zrobić przegląd, co wymienić, jaki zakres kontroli wykonać).

Modele bez eksperta są ślepe. Ekspert bez modeli – „głuchy” na subtelne sygnały ukryte w danych. Dobre wdrożenie AI w utrzymaniu ruchu łączy obie perspektywy.

Miejsce AI w piramidzie automatyki zakładowej

Pojawienie się AI nie wywraca całej struktury automatyki. Raczej wpasowuje się w istniejącą piramidę:

• Poziom czujników – akcelerometry, termopary, czujniki prądu, enkodery, liczniki cykli.
• Poziom sterowania (PLC, DCS) – podstawowa logika sterowania, progi alarmowe, sekwencje start-stop.
• Poziom SCADA/HMI – wizualizacja, alarmy, archiwizacja podstawowych danych procesowych.
• Poziom MES – raportowanie produkcji, OEE, śledzenie zleceń, przestojów.
• Poziom ERP – planowanie, zakupy, koszty, fakturowanie.

AI w utrzymaniu ruchu zwykle pojawia się jako „warstwa analityczna” pomiędzy SCADA/MES a CMMS. Modele korzystają z danych z czujników (bezpośrednio lub przez SCADA), a wyniki trafiają do:

• paneli operatorskich (informacja o stanie „zdrowia” maszyny),

Jak AI komunikuje się z istniejącymi systemami UR

Warstwa AI nie działa w próżni. Musi się spinać z tym, co już funkcjonuje na zakładzie, inaczej skończy jako kolejne osobne „okienko” w przeglądarce.

Typowe kierunki integracji są trzy:

• CMMS / EAM – z modeli wychodzą rekomendacje w formie zleceń lub sugestii zadań: „sprawdź łożyska linii X w ciągu 3 dni”, „zaplanuj smarowanie wentylatora Y przed weekendem”.
• SCADA / HMI – operator widzi nie tylko bieżące odczyty, ale prostą ocenę stanu: wskaźnik zdrowia, trend ryzyka awarii, komunikat „praca poza typowym wzorcem”.
• MES / systemy raportowe – raporty przestojów mogą być uzupełnione o „przyczynę przewidywaną” vs „przyczynę rzeczywistą”, co później karmi modele i usprawnia analizy RCA.

Przy integracji najlepiej od razu ustalić z IT/OT, jakie decyzje mogą wynikać z modelu. Np.:

• czy model może sam utworzyć zlecenie w CMMS, czy tylko zaproponować szkic do akceptacji,
• czy alarm predykcyjny może zatrzymać maszynę, czy ma być wyłącznie „miękkim” ostrzeżeniem dla UR.

Dane w utrzymaniu ruchu – z czego „karmi się” AI

Jakość danych ważniejsza niż ich ilość

Przy projektach AI w UR pada często pytanie: „Ile danych trzeba?”. Zwykle istotniejsze są inne kwestie:

• czy dane są spójne w czasie (bez przerw, przesunięć zegara, dziur w archiwum),
• czy znane są punkty odniesienia – kiedy faktycznie nastąpiła awaria, remont, wymiana części,
• czy opis zdarzeń w CMMS/raportach odpowiada rzeczywistości, a nie tylko „awaria maszyny”.

Przydaje się prosty „przegląd sanitarno-porządkowy” danych przed startem projektu. Kilka krótkich kroków:

1. Wybrać 3–5 najbardziej krytycznych maszyn lub linii.
2. Sprawdzić, czy dla nich istnieje historia sygnałów (np. z SCADA) na poziomie minut lub sekund.
3. Zestawić to z historią zleceń w CMMS – czy widać daty awarii i większych remontów.
4. Ocenić, ile jest braków: pustych okresów, sensowność wartości (np. temperatura 1500°C na linii pakowania – oczywisty błąd).

Taka szybka weryfikacja oszczędza później dużo nerwów i nieporozumień z dostawcą rozwiązania AI.

Jak poprawić dane bez wielkich inwestycji

Nie zawsze trzeba od razu wymieniać całą infrastrukturę. Często pomagają proste ruchy:

• uzgodnienie wspólnego słownika usterek i przyczyn w CMMS (kilkanaście kategorii zamiast wolnego tekstu),
• dodanie kilku kluczowych pól obowiązkowych przy zamknięciu zlecenia, np. „główna przyczyna”, „część wymieniona/naprawiona”,
• uspójnienie stref czasowych i zegarów – PLC, SCADA, serwer baz danych i CMMS muszą „żyć w tym samym czasie”,
• oznaczanie w danych momentów nietypowych trybów pracy (rozruch po remoncie, testy, praca na pusto) – to później filtr przy trenowaniu modeli.

Dobry zwyczaj: przy większych awariach UR robi krótki „pakiet danych do analizy” – ID zlecenia, wykresy z kilku kluczowych czujników z okresu przed awarią, krótki opis inżyniera. To potem świetny materiał treningowy.

Łączenie danych procesowych z biznesowymi

Same dane z czujników to za mało, żeby podejmować decyzje, kiedy zatrzymać maszynę i co wymienić. Modele AI można uzupełnić o perspektywę kosztową.

Przy predykcyjnym UR liczy się m.in.:

• koszt przestoju linii na godzinę (utracona produkcja),
• czas przygotowania części lub podzespołów,
• dostępność ekip (zmiany, weekendy, noc),
• plan produkcji – kiedy i jak bardzo potrzebna jest dana linia.

Po połączeniu tych danych model nie tylko sygnalizuje, że „łożysko ma wysokie ryzyko awarii w ciągu 5 dni”, ale też sugeruje, które okno postoju minimalizuje łączny koszt. Nawet prosty algorytm priorytetyzacji oparty na kilku regułach może dać UR silną podkładkę do rozmów z produkcją.

Kluczowe przypadki użycia AI w utrzymaniu ruchu

Predykcja usterek kluczowych napędów

Silniki, przekładnie, pompy, wentylatory – to najczęstszy cel pierwszych wdrożeń. Są istotne dla produkcji i dobrze mierzalne (prąd, drgania, temperatura, liczba startów).

Przykładowe zastosowania:

• wczesne wykrywanie niewyważenia, niewspółosiowości, luzów i uszkodzeń łożysk,
• ocena stopnia zużycia przekładni na podstawie charakterystyki drgań i obciążenia,
• wykrywanie nieprawidłowych warunków pracy pompy (praca na sucho, kawitacja, zablokowany filtr).

Modele mogą tu działać w dwóch trybach:

• detekcja anomalii – uczą się „normalnego” wzorca pracy i sygnalizują odchylenia bez konieczności znajomości wszystkich typów awarii,
• klasyfikacja usterek – gdy jest historia zdarzeń, można próbować rozróżniać: „łożysko”, „niewspółosiowość”, „luz fundamentu”.

Monitorowanie stanu maszyn wirujących na podstawie drgań

Czujniki drgań i AI dobrze się uzupełniają. Klasyczna analiza widmowa wymaga sporego doświadczenia diagnosty. Modele mogą pomóc w preselekcji.

Praktyczne podejście:

• na wszystkich kluczowych maszynach montuje się stałe czujniki drgań z transmisją online,
• modele wyliczają bieżące wskaźniki zdrowia i typ anomalnego zachowania,
• diagnosta dostaje krótką listę maszyn „do głębszego zbadania”, zamiast przekopywać się przez setki wykresów.

Przykład z życia: w jednej z fabryk drganiowiec raz w tygodniu objeżdżał kilkadziesiąt maszyn z przenośnym analizatorem. Po wprowadzeniu stałych czujników i modeli AI jego praca przesunęła się z „zbierania danych” na interpretację i planowanie działań. Tego czasu wcześniej brakowało.

Predykcja zużycia części eksploatacyjnych

Nie wszystkie elementy da się monitorować czujnikami bezpośrednio. AI można jednak wykorzystać do szacowania ich zużycia pośrednio, na podstawie obciążenia i trybu pracy.

Przykłady:

• okładziny hamulców i sprzęgieł na podstawie liczby cykli i energii każdego hamowania,
• uszczelnienia pomp w zależności od czasu pracy w warunkach kawitacji lub pracy na granicy parametrów.

W prostszym wariancie wystarczy model, który koryguje harmonogram wymian „kalendarzowych” o faktyczną intensywność pracy. Efekt: mniej niepotrzebnych wymian „na wszelki wypadek” oraz mniej niespodzianek, gdy element szybciej się zużyje w trudnych warunkach.

Analiza przyczyn powtarzalnych awarii (RCA z pomocą AI)

W wielu zakładach te same komponenty „palą się” cyklicznie. Czasem przyczyna jest oczywista, ale często składa się z kilku czynników: sposób pracy operatorów, jakość medium, parametry procesu, pogoda.

Modele AI mogą wspierać analizy RCA poprzez:

• wyszukiwanie wspólnych wzorców w danych przed awariami,
• porównywanie przebiegu parametrów w okresach z awarią i bez,
• wskazywanie nietypowych kombinacji sygnałów, które „zawsze” pojawiają się przed problemem.

UR może to wykorzystać do potwierdzania lub obalania hipotez. Zamiast dyskusji „wydaje nam się, że…”, dane pokazują, że np. awarie najczęściej pojawiają się po określonej sekwencji przezbrojeń lub przy jednym konkretnym surowcu.

Optymalizacja przeglądów i strategii PPM

Klasyczny PPM (przeglądy okresowe) opiera się na czasie kalendarzowym lub liczbie godzin pracy. AI umożliwia przejście do przeglądów opartych o rzeczywisty stan.

Prosty scenariusz:

• dla każdej grupy maszyn definiuje się kilka wskaźników zdrowia (drgania, temperatura, stabilność pracy),
• modele określają trend pogarszania się stanu,
• przeglądy są planowane tak, aby „łapać” maszyny w punkcie, gdy ryzyko rośnie, ale jeszcze daleko do awarii.

Dzięki temu część przeglądów można skrócić lub wykonywać rzadziej, inne – robić wcześniej i w większym zakresie. Harmonogramy UR przestają być sztywne, a stają się dynamicallyzowane na podstawie danych.

Wirtualne czujniki (soft-sensory)

Są obszary, gdzie montaż fizycznego czujnika jest trudny lub nieopłacalny (np. wewnątrz zamkniętej obudowy, w strefie ATEX). Tu wchodzą tzw. wirtualne czujniki.

Model AI uczy się szacować daną wielkość na podstawie innych, łatwo mierzalnych parametrów. Przykład: temperatura uzwojeń silnika oszacowana z prądu, napięcia, temperatury otoczenia i historii obciążenia.

Takie wirtualne czujniki mogą potem służyć jako wejście do kolejnych modeli predykcyjnych albo jako dodatkowy parametr przy decyzjach UR. Zyskuje się „nowy pomiar” bez fizycznego montażu przetwornika.

Od pomysłu do pilotażu – jak wystartować z AI w UR

Wybór pierwszego obszaru – gdzie AI ma największą szansę się obronić

Zamiast zaczynać „od całej fabryki”, lepiej skupić się na kilku spójnych obiektach. Dobre kryteria wyboru:

• wysoki koszt przestoju lub duży wpływ na ciągłość produkcji,
• dostępne dane historyczne lub możliwość szybkiego doposażenia w czujniki,
• powtarzalne awarie, które UR „czuje”, ale trudno im uchwycić wzorzec,
• zespół UR i produkcji chętny do współpracy i testowania nowych rozwiązań.

W praktyce często pada na: sprężarkownię, linie pakowania, kluczowe pompy obiegowe, wentylatory procesowe, napędy główne linii.

Minimalny zakres pilotażu, który ma sens

Pilot powinien być na tyle mały, żeby go „udźwignąć”, ale na tyle szeroki, żeby dał miarodajne wnioski. Typowy zakres:

• 5–20 maszyn jednego typu lub zbliżonych (np. wszystkie wentylatory procesu suszenia),
• kilka kluczowych sygnałów na każdą maszynę (drgania, temperatura, prąd, wybrane alarmy PLC),
• co najmniej kilka miesięcy historii pracy lub 3–6 miesięcy nowej zbiórki danych przy częstym próbkowaniu.

Do tego potrzebny jest określony zakres decyzji, jakie mają wynikać z pilota: np. czy UR będzie na podstawie modelu realnie przesuwać przeglądy, czy tylko „patrzeć na wykresy”. Bez tego trudno później ocenić, czy projekt przyniósł wartość.

Jak zbudować zespół projektowy

Nawet mały pilotaż wymaga kilku ról. W wielu zakładach łączy się je w jedna–dwie osoby, ale funkcje muszą być pokryte:

• lider z UR – zna maszyny, priorytety i ludzi na zmianach,
• automatyk/OT – ogarnia PLC, SCADA, sieć przemysłową i bezpieczeństwo,
• przedstawiciel IT – serwery, chmura, dostęp do danych, backup, bezpieczeństwo,
• data scientist / inżynier AI – projektuje model, integrację danych, testy,
• ktoś z produkcji – żeby od początku włączać ich w temat postoju, alarmów, okien serwisowych.

Rolą lidera UR jest trzymanie projektu „na ziemi”: pilnowanie, by scenariusze były przydatne, a nie tylko efektowne. Jeżeli coś nie odpowiada realiom pracy na hali, lepiej to poprawić na etapie pilotażu niż walczyć przy wdrożeniu.

Definiowanie mierników sukcesu (KPI dla projektu AI)

Bez jasnych wskaźników projekt wisi w próżni. Przy starcie pilotażu dobrze zdefiniować kilka twardych KPI, np.:

• liczbę niespodziewanych awarii na obserwowanych maszynach przed i po wdrożeniu,
• średni czas reakcji UR na problem vs czas wyprzedzenia, jaki dał model,

Jak przygotować dane i etykiety do pilotażu

Większość problemów projektów AI nie leży w modelu, tylko w danych. Dobrze ułożony etap przygotowania danych potrafi zaoszczędzić miesiące nerwów.

Podstawowe kroki:

• inwentaryzacja źródeł – PLC, SCADA, rejestratory drgań, system jakości, CMMS, arkusze operatorów,
• ustalenie wspólnego czasu – synchronizacja zegarów (NTP dla PLC, serwerów, rejestratorów),
• mapa sygnałów – lista zmiennych z opisem: nazwa, jednostka, zakres, częstotliwość próbkowania, miejsce pomiaru,
• powiązanie z awariami – dla każdej maszyny: daty awarii, opisy w CMMS, zdjęcia, notatki z UR.

Szczególnie krytyczne jest zrobienie porządku z opisami awarii. Jeżeli historia w CMMS to „nie działa”, „naprawiono”, „wymiana”, model nic z tego nie wyciągnie. Potrzebne są krótkie, ale konkretne kody lub tagi awarii (np. „łożysko”, „niewspółosiowość”, „przegrzanie silnika”, „zapchany filtr”). Wystarczy kilkanaście sensownych kategorii, resztę można doprecyzować w komentarzu tekstowym.

Warsztat startowy z UR i produkcją

Zanim ruszy zbieranie danych, dobrze jest posadzić przy jednym stole ludzi od maszyn i od danych. Prosty, półdniowy warsztat daje dużo:

• przegląd kluczowych usterek na wybranych maszynach,
• omówienie, jak wygląda typowy „dzień z problemem” z perspektywy UR i operatora,
• wspólne narysowanie timeline’u: co się dzieje na godzinę przed awarią, 10 minut przed i w momencie stopu,
• lista sygnałów, które realnie można zebrać (bez demolki instalacji).

Z takiego warsztatu wychodzi pierwsza wersja „scenariusza predykcji” – czyli, na co model ma zwracać uwagę i jaką decyzję ma wspierać. To lepsze podejście niż budowanie modelu „na ślepo”, tylko z tabelki sygnałów.

Techniczne minimum dla środowiska pilotażowego

Nie trzeba od razu stawiać całej platformy przemysłowej AI, ale pewne elementy muszą się pojawić, inaczej pilot utknie.

• miejsce na dane – serwer plików, baza time-series, ewentualnie chmura; kluczowe, żeby dane były zebrane w jednym logicznym miejscu,
• mechanizm zrzutu z OT – prosty broker OPC UA, konektor do SCADA lub eksport plików z rejestratora,
• środowisko analityczne – cokolwiek, na czym data scientist będzie mógł bezpiecznie pracować (VM, kontener, notebooki),
• dostęp do CMMS – API, raport CSV lub inne regularne zrzuty historii zleceń.

Na tym etapie wystarczy, żeby przepływ był powtarzalny i zrozumiały: skąd, kiedy i w jakim formacie bierzemy dane. „Ręczne” kopiowanie plików przez pendrive między halą a biurem zawsze kończy się bałaganem i brakami w historii.

Testy „na sucho” przed wejściem na halę

Zanim model zacznie wyświetlać alarmy na panelu operatora, powinien przejść kilka prostych testów offline.

Dobry zestaw testów obejmuje:

• test na danych historycznych – czy model „zauważa” znane awarie, ile czasu przed faktycznym zdarzeniem,
• symulację alarmów – ręczne wyliczenie progów i sprawdzenie, ile byłoby fałszywych alarmów w ostatnich miesiącach,
• przegląd z diagnostą – wspólne oglądanie wykresów i alarmów z minionych przypadków.

Jeżeli model nie jest w stanie poprawnie „odtworzyć” kilku starych awarii, raczej nie będzie lepszy w nowych. Lepiej wtedy wrócić krok wcześniej: poszerzyć zbiory danych, dołożyć sygnał, poprawić etykiety awarii.

Jak komunikować wyniki pilotażu w firmie

Po kilku miesiącach zbierania danych i testów przychodzi moment rozliczenia projektu. Sposób prezentacji ma duży wpływ na to, czy będzie zielone światło na rozszerzenie.

Przydatne elementy:

• konkretne przypadki, gdzie model pomógł (np. wykrycie wczesnej fazy uszkodzenia, przesunięcie przeglądu, skrócenie postoju),
• liczby, ale proste: o ile spadła liczba niespodziewanych awarii, ile godzin postoju udało się uniknąć,
• lista ograniczeń – gdzie AI jeszcze sobie nie radzi, jakie są ryzyka,
• propozycja kolejnego kroku: rozszerzenie na kolejne maszyny, doposażenie w czujniki, integracja z CMMS.

Ważne, żeby nie obiecywać „zero awarii”. Dobrze zadziała prosty przekaz: „Na tych maszynach jesteśmy w stanie wcześniej wychwycić X typów problemów, reszta nadal wymaga klasycznych przeglądów”.

Architektura rozwiązania – od czujnika do modelu i z powrotem na halę

Warstwa pomiarowa – czujniki, które „robią różnicę”

Na poziomie czujników kluczowa jest nie ilość, tylko jakość i sensowny dobór punktów pomiarowych. Typowe komponenty:

• czujniki drgań – akcelerometry, często w wersji zintegrowanej (drgania + temperatura), montowane na łożyskach, korpusach przekładni,
• czujniki temperatury – PT100, termopary, pirometry bezkontaktowe dla trudno dostępnych elementów,
• pomiar prądu i napięcia – przekładniki, analizatory sieci, moduły we/wy w szafach zasilających,
• ciśnienie, przepływ, poziom – szczególnie przy pompach, sprężarkach, układach hydraulicznych.

Przy projektowaniu nowej instalacji łatwo zarezerwować kilka wejść w PLC i zainstalować dodatkowe przetworniki. Najtrudniejsze są modernizacje starych linii – wtedy często lepiej zacząć od 2–3 krytycznych sygnałów, niż próbować „okablować wszystko”.

Warstwa OT – PLC, SCADA i edge

Między czujnikiem a światem IT stoi warstwa sterowania. To tutaj zapada dużo decyzji, które potem determinują łatwość wdrożenia AI.

Kluczowe elementy warstwy OT:

• sterowniki PLC – zbierają sygnały, realizują logikę maszyn, często mają ograniczone możliwości archiwizacji,
• system SCADA – wizualizacja i podstawowy logging, czasem wystarczający do prostych analiz,
• urządzenia edge – małe przemysłowe komputery, które lokalnie buforują dane, robią wstępne obliczenia i filtrację,
• bramy komunikacyjne – konwertują protokoły (Modbus, Profibus, Profinet, CAN) na OPC UA lub MQTT.

Dobra praktyka to odseparowanie logiki sterowania od logiki analitycznej. Modele AI nie powinny „grzebać” w kodzie PLC. Zamiast tego warto wykorzystać edge lub serwery pośrednie, które odbierają dane z PLC i przekazują je do świata IT w kontrolowany sposób.

Warstwa danych – magazyn i przetwarzanie strumieniowe

W projektach AI do UR pojawiają się dwa główne typy danych: historyczne (do trenowania modeli) i bieżące (do ich działania online). Architektura musi obsłużyć oba.

• baza zdarzeń / timeseries – zapis sygnałów w funkcji czasu, z możliwością szybkiego filtrowania po maszynie, sygnale, okresie,
• hurtownia danych UR – integruje historię awarii, zlecenia z CMMS, wyniki inspekcji,
• silnik strumieniowy – komponent, który odbiera dane „na żywo” (MQTT, Kafka, inny broker) i przekazuje je do modeli,
• repozytorium modeli – miejsce, gdzie przechowuje się wersje modeli, metadane, informacje o treningu.

Jeżeli firma nie ma rozbudowanej infrastruktury IT, można zacząć od prostszego układu: jedna baza timeseries (np. na serwerze w DMZ) plus skrypty do eksportu danych dla zespołu AI. Ważne, żeby ten układ dało się potem rozbudować, a nie wyrzucać do kosza.

Warstwa AI – trening, wersjonowanie, monitorowanie

Sama „skrzynka z modelem” to tylko część układanki. Żeby rozwiązanie było utrzymywalne, trzeba zadbać o kilka funkcji wokół:

• pipeline treningowy – powtarzalna procedura: pobranie danych, czyszczenie, ekstrakcja cech, trening, walidacja,
• wersjonowanie modeli – oznaczanie, który model działa na której maszynie, kiedy był trenowany, na jakich danych,
• monitoring jakości – śledzenie liczby fałszywych alarmów, przypadków niezłapanych awarii, stabilności progów,
• mechanizm rollback – możliwość szybkiego cofnięcia się do poprzedniej wersji modelu, gdy nowa działa gorzej.

Do zarządzania tym obszarem można wykorzystać gotowe platformy MLOps albo prostszy zestaw narzędzi (system kontroli wersji + skrypty + dashboard). Istotne, żeby nie „wgrywać modelu ręcznie” na poszczególne maszyny bez śladu po tym, co zostało zrobione.

Warstwa prezentacji – jak dostarczyć informacje ludziom na hali

Nawet najlepszy model nic nie zmieni, jeśli wyniki będą ukryte w narzędziu, do którego zajrzy raz w tygodniu tylko analityk. Informacja musi trafić tam, gdzie zapadają decyzje na co dzień.

Najczęstsze sposoby prezentacji:

• pulpity UR – dashboardy z listą maszyn w kolorach (zielony/żółty/czerwony), trendami wskaźników zdrowia, historią alarmów,
• integracja z CMMS – model generuje sugestię zlecenia przeglądu lub inspekcji, która trafia do kolejki UR,
• panele HMI – proste komunikaty dla operatora: „zwiększone drgania – zgłoś UR”, „zalecana inspekcja w ciągu 24 h”,
• powiadomienia mobilne – e-mail, SMS lub aplikacja z powiadomieniami dla dyżurnego inżyniera.

Komunikaty powinny być krótkie i konkretne: „Wzrost drgań łożyska 2, trend rosnący od 12 h, sugerowana inspekcja dziś”. Lepszy jeden dobrze opisany alarm niż dziesięć sygnałów „coś jest nie tak”.

Bezpieczeństwo i rozdział sieci OT/IT

Integracja czujników, PLC, serwerów i chmury niesie ryzyko dla cyberbezpieczeństwa. Dział IT i automatyk muszą tu grać w jednej drużynie.

Podstawowe zasady:

• segmentacja sieci – wyraźny podział na sieć produkcyjną (OT), strefę pośrednią (DMZ) i sieć biurową/IT,
• jednokierunkowy przepływ danych tam, gdzie to możliwe (dane wychodzą z OT, ale polecenia nie wracają tą samą ścieżką),
• uwierzytelnianie i szyfrowanie w komunikacji między warstwami, szczególnie przy dostępie zewnętrznym / chmurowym,
• procedura zmian – każda nowa integracja (nowy konektor, port, użytkownik) przechodzi przez wspólną akceptację OT/IT.

Dobrą praktyką jest rozpoczęcie od małego, odseparowanego segmentu sieci dla pilotażu AI. Ułatwia to testy, audyt bezpieczeństwa i pozwala spokojnie wypracować standardy przed skalowaniem na całą fabrykę.

Scenariusz przepływu informacji – przykład end-to-end

Dla uporządkowania, jak może wyglądać pełny przepływ od czujnika do decyzji na hali, poniżej skrócony, praktyczny scenariusz.

1. Czujnik drgań na łożysku silnika zbiera dane z częstotliwością kilkudziesięciu Hz.
2. Sygnał trafia do modułu wejściowego i dalej do PLC, który przekazuje uśrednione wartości do urządzenia edge.
3. Edge oblicza podstawowe cechy (RMS, widmo w kilku pasmach) i co kilka sekund wysyła je protokołem MQTT do serwera w DMZ.
4. Silnik strumieniowy na serwerze łączy strumień cech z innymi danymi z tej maszyny (prąd, temperatura, obroty) i przekazuje do modelu anomalii.
5. Model oblicza „indeks zdrowia” i, jeśli przekroczy próg, generuje zdarzenie „ryzyko uszkodzenia łożyska > 70% w horyzoncie 7 dni”.
6. Zdarzenie trafia do:
   • pulpitu UR – maszyna oznacza się na żółto, widać trend i szczegóły,
   • CMMS – automatycznie tworzy się sugestia zlecenia inspekcji z opisem i załączonym wykresem,
   • panelu HMI – operator widzi komunikat o zalecanej inspekcji przy najbliższej możliwości postoju.

Najczęściej zadawane pytania (FAQ)

Na czym polega predykcyjne utrzymanie ruchu i czym różni się od prewencyjnego?

Utrzymanie prewencyjne opiera się na harmonogramie: przeglądy i wymiany „co pół roku”, „co 2000 godzin”. Maszyna może być jeszcze w dobrym stanie, ale i tak wymieniasz element „na wszelki wypadek”.

Predykcyjne utrzymanie ruchu bazuje na danych z maszyn – drganiach, temperaturach, prądzie, liczbie cykli, alarmach z PLC. System na bieżąco ocenia „zdrowie” podzespołów i wskazuje, kiedy realnie rośnie ryzyko awarii. W efekcie wymieniasz części wtedy, gdy faktycznie zbliża się koniec ich życia, a nie tylko dlatego, że tak mówi kalendarz.

Jakie konkretne korzyści daje AI w utrzymaniu ruchu?

Największa zmiana to przejście z trybu „gaszenia pożarów” do planowanej pracy. Dzięki AI da się wcześniej wykryć symptomy usterek (np. zmiana widma drgań łożyska) i zaplanować postój na dogodny termin, zamiast zatrzymywać linię w środku dużego zlecenia.

W praktyce przekłada się to na:

• mniej nieplanowanych przestojów i mniejszy stres na produkcji,
• lepsze wykorzystanie brygady UR (mniej nocnych i weekendowych „akcji ratunkowych”),
• łatwiejsze pokazanie wartości UR w liczbach – ile awarii udało się uniknąć.

AI nie naprawi jednak błędów konstrukcyjnych maszyn ani złego planowania produkcji, więc trzeba równolegle porządkować procesy.

Czy AI zastąpi mechaników i inżynierów utrzymania ruchu?

Nie. AI jest narzędziem do analizy danych, a nie „wirtualnym mechanikiem”. Algorytmy potrafią wychwycić subtelne zmiany w danych, policzyć prawdopodobieństwo awarii czy oszacować pozostały czas pracy elementu, ale nadal ktoś musi podjąć decyzję, co z tym zrobić i jak to wykonać technicznie.

Najlepsze efekty są wtedy, gdy AI wspiera doświadczony zespół UR. System podpowiada: „uwaga, rośnie ryzyko uszkodzenia łożyska na wentylatorze 3 w ciągu 5–10 dni”, a mechanik potwierdza diagnostyką i planuje wymianę przy najbliższym postoju.

Jakie dane są potrzebne do predykcyjnego utrzymania ruchu z AI?

Podstawą są dane czasowe z maszyn, czyli szereg czasowy. W praktyce najczęściej wykorzystuje się:

• drgania z czujników na łożyskach i konstrukcji,
• temperatury (łożysk, uzwojeń, oleju, otoczenia),
• prąd i napięcie silników,
• liczbę startów, godziny pracy, cykle.

Do tego dochodzą dane zdarzeniowe: logi błędów z PLC, sekwencje alarmów z SCADA/HMI, informacje o przestojach.

Nie trzeba mieć od razu „wszystkiego ze wszystkiego”. Często sensowny start to 1–2 krytyczne maszyny, dołożenie czujników drgań i temperatury oraz zebranie historii alarmów z istniejącego systemu.

Od czego zacząć wdrażanie AI w utrzymaniu ruchu w istniejącym zakładzie?

Bezpieczny start to mały, konkretny use case zamiast „rewolucji w całym parku”. Dobrze sprawdzają się:

• łożyska wentylatorów i pomp,
• krytyczne silniki, których awaria zatrzymuje całą linię.

Na początek:

• wskazuj 2–3 maszyny o największym wpływie na produkcję,
• sprawdź, jakie dane już masz (SCADA, PLC, rejestr awarii),
• dołóż brakujące czujniki (np. drgań, temperatury),
• uruchom pilotażowy model AI i porównuj jego wskazania z realnymi awariami.

Po kilku miesiącach widać, czy model faktycznie trafnie ostrzega przed usterkami i gdzie ma luki.

Czym różni się predykcyjne od preskrypcyjnego utrzymania ruchu?

Predykcyjne utrzymanie ruchu odpowiada głównie na pytanie „kiedy może wystąpić awaria?”. System wykrywa symptomy zużycia i prognozuje czas do usterki, ale niekoniecznie mówi, jak dokładnie zareagować.

Preskrypcyjne utrzymanie ruchu idzie krok dalej. Na podstawie prognoz i danych z procesu generuje konkretne rekomendacje, np. „zredukuj prędkość przenośnika o 10% na 3 dni”, „zaplanuj wymianę łożysk w oknie postoju weekendowego”, „zmień parametry falownika, aby zmniejszyć udary przy rozruchu”. To połączenie diagnostyki, prognostyki i wsparcia decyzji dla UR i produkcji.

Czy AI w UR opłaca się w mniejszych i średnich zakładach produkcyjnych?

Tak, ale pod warunkiem rozsądnego zakresu. W mniejszej firmie kluczowe są 2 pytania: które maszyny generują największe koszty przestojów i gdzie trudno „na oko” złapać początek problemu. Często wychodzi, że wystarczy objąć AI kilka wentylatorów procesowych, główne pompy albo kluczowe linie pakujące.

Jeśli każda nieplanowana godzina postoju liczy się w dużych stratach, nawet prosta analityka drgań i temperatury z modelem ML potrafi się zwrócić bardzo szybko. Z kolei tam, gdzie awarie są rzadkie i tanie, można pozostać przy klasycznej prewencji i prostych progach alarmowych.

Najważniejsze wnioski

• Tradycyjne podejścia do utrzymania ruchu (reakcyjne i prewencyjne) generują wysokie koszty, chaos organizacyjny i wypalenie załogi, bo większość energii idzie na gaszenie awarii zamiast na planowanie.
• Przejście na predykcyjne i preskrypcyjne utrzymanie ruchu przesuwa firmę z trybu „maszyna pracuje, aż padnie” do trybu „wiemy z wyprzedzeniem, co się psuje i jak zareagować”.
• Same dane z maszyn nie wystarczą – bez analityki i AI zespoły UR toną w logach i raportach, z których trudno wyciągnąć konkretne decyzje operacyjne.
• AI w UR realnie pomaga w trzech rzeczach: wczesnym wykrywaniu anomalii, szacowaniu pozostałego czasu życia elementów oraz priorytetyzacji maszyn, którymi trzeba zająć się najpierw.
• AI nie zastąpi mechanika ani nie naprawi bałaganu organizacyjnego – bez zmian w procesach, dostępności części i planowaniu produkcji stanie się tylko kolejnym „ładnym wykresem”.
• Przykład z łożyskami wentylatorów pokazuje prosty scenariusz wdrożenia: czujniki drgań i temperatury, model uczący się „zdrowych” drgań i wczesne alarmy z oknem czasowym na zaplanowany postój.
• Największa wartość z AI pojawia się wtedy, gdy łączy się prognozę z rekomendacją działania (np. zmiana prędkości, termin wymiany, korekta nastaw), a UR i produkcja faktycznie z tych wskazówek korzystają.