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