Predykcyjne utrzymanie maszyn z AI: praktyczne zastosowania w przemyśle

Cel wdrożenia predykcyjnego utrzymania maszyn z AI z perspektywy zakładu

Celem jest przejście od gaszenia pożarów do przewidywania awarii z wyprzedzeniem, tak aby produkcja, magazyn części i służby utrzymania ruchu pracowały w zaplanowany sposób. W praktyce chodzi o to, aby widzieć nadchodzący problem na maszynie kilka godzin, dni, a czasem tygodni przed zatrzymaniem linii – i mieć czas na reakcję.

Predykcyjne utrzymanie ruchu z AI łączy dane z czujników, historię serwisów oraz kontekst produkcyjny w spójny system wczesnego ostrzegania. Dobrze zaprojektowane pozwala jednocześnie zmniejszyć liczbę awarii, skrócić przestoje i zoptymalizować koszty części zamiennych oraz pracy ekip UR.

Czym jest predykcyjne utrzymanie maszyn z AI i czym różni się od „klasycznego” UR

Reakcyjne, prewencyjne, predykcyjne – trzy poziomy dojrzałości utrzymania ruchu

Większość zakładów przechodzi podobną drogę dojrzewania utrzymania ruchu. Zrozumienie, na którym etapie znajduje się organizacja, ułatwia zaplanowanie realnego wdrożenia AI.

Utrzymanie reakcyjne (naprawa po awarii) to podejście: „maszyna działa – nie ruszaj, zepsuje się – naprawimy”. Służby UR reagują na zgłoszenia z produkcji, często w trybie awaryjnym. Typowe skutki:

• nieplanowane przestoje całych linii,
• nadgodziny ekip serwisowych,
• ekspresowe zamówienia części zamiennych,
• chaotyczne planowanie produkcji.

Utrzymanie prewencyjne opiera się na harmonogramach przeglądów i wymian części. Co określony czas (np. co 3 miesiące lub co 2000 godzin pracy) maszyny są zatrzymywane w celu przeglądu. Przynosi to wyraźną poprawę w stosunku do reakcyjnego trybu pracy, ale wciąż ma słabe punkty:

• wymiany części często „na wszelki wypadek”, mimo że byłyby w stanie popracować dłużej,
• brak uwzględnienia realnego obciążenia maszyny (praca lekka vs ciężka),
• nadal zdarzają się nagłe awarie między przeglądami.

Utrzymanie predykcyjne wykorzystuje dane z maszyn, historię awarii i modele predykcyjne do oceny realnego stanu technicznego. Serwis i wymiany części są planowane wtedy, gdy ryzyko awarii przekracza akceptowalny poziom – nie wcześniej i nie później. Kluczowe elementy:

• ciągły lub regularny monitoring stanu maszyn,
• analiza drgań, temperatury, prądów, dźwięku, obrazów,
• modele predykcyjne awarii maszyn, oparte na AI,
• powiązanie wyników analizy z planem produkcji i CMMS.

AI nie zastępuje tu podstaw dobrej praktyki UR, ale pozwala przesunąć decyzje z „czasu kalendarzowego” na rzeczywisty stan urządzeń.

Co konkretnie wnosi AI do predykcji awarii

Klasyczny monitoring stanu maszyn opiera się głównie na prostych progach alarmowych. Jeśli temperatura przekroczy X stopni lub RMS drgań przekroczy wartość Y – generowany jest alarm. To dobry pierwszy krok, ale ma ograniczenia:

• nie uwzględnia kontekstu (obciążenie, prędkość, tryb pracy),
• często prowadzi do licznych fałszywych alarmów,
• nie wychwytuje subtelnych, wolno narastających zmian.

AI wnosi trzy kluczowe rzeczy:

1. Uczenie na historycznych danych – modele potrafią uczyć się z setek wcześniejszych przykładów pracy maszyny: okresów stabilnych, stanów przejściowych, czasów tuż przed awarią. Dzięki temu nie potrzebują ręcznego ustawiania wielu progów.
2. Wychwytywanie złożonych wzorców – sieci neuronowe czy modele gradient boosting potrafią dostrzegać kombinacje sygnałów (drgania + temperatura + prąd), które razem wskazują problem, choć każdy z osobna jeszcze mieści się w „normie”.
3. Dostosowanie do konkretnej maszyny – model może być „spersonalizowany” pod daną linię lub typ maszyny, uwzględniając jej indywidualne zachowanie, luz montażowy, typ pracy czy warunki środowiskowe.

AI szczególnie dobrze radzi sobie z analizą danych czasowych i sygnałów z czujników, takich jak:

• sygnały drgań z akcelerometrów (w tym widmo częstotliwościowe po FFT),
• prądy silników (charakterystyczne wzorce przeciążeń, zacięć),
• temperatury łożysk, uzwojeń, oleju,
• dźwięk (anomalie akustyczne),
• obrazy z kamer (zużycie wizualne, nieprawidłowa pozycja elementów).

Różnica między prostym monitoringiem stanu a modelami AI

Progi alarmowe (thresholdy) oraz proste logiki IF-THEN są szybkie i łatwe do wdrożenia, lecz mają ograniczoną elastyczność. Schemat jest prosty: jeśli sygnał przekroczy próg – alarm. Tego typu podejście:

• sprawdza się w prostych przypadkach (np. brak przepływu, brak ciśnienia),
• nie wymaga zaawansowanej infrastruktury danych,
• jest dobrze znane zespołom automatyki i UR.

Modele AI działają inaczej:

• analizują wiele sygnałów jednocześnie,
• biorą pod uwagę historię, a nie tylko bieżącą wartość,
• zwracają nie tylko alarm, ale też prawdopodobieństwo awarii w określonym horyzoncie czasu,
• mogą adaptować się do zmian warunków pracy (konfiguracja linii, nowe receptury).

Dobrym podejściem jest połączenie obu metod: progi bezpieczeństwa jako warstwa ochrony dla oczywistych zagrożeń oraz AI jako „nadbudowa” zajmująca się subtelnymi, trudnymi do uchwycenia zjawiskami.

Wpływ predykcyjnego utrzymania na planowanie produkcji i UR

System predykcyjny ma sens dopiero wtedy, gdy jego wyniki przekładają się na decyzje operacyjne. Najważniejsze efekty na poziomie zakładu to:

• Planowanie okien serwisowych – zamiast nagłych zatrzymań, serwisy planowane są w okienkach, gdy produkcja ma niższe obciążenie lub przerwy między zleceniami.
• Logistyka części zamiennych – dane predykcyjne umożliwiają zamówienie części „just in time”, zmniejszając magazyn bezpieczeństwa, ale nie ryzykując przestojów z powodu braku komponentów.
• Priorytety pracy ekip UR – zamiast zbioru podobnie ważnych zadań, zespół dostaje listę interwencji uszeregowanych po ryzyku awarii i krytyczności maszyn.
• Lepsza współpraca produkcji z UR – produkcja widzi, że prośba UR o zatrzymanie maszyny ma oparcie w danych i realnym ryzyku, a nie w „przeczuciu serwisanta”.

W praktyce przekłada się to na spokojniejszą pracę: mniej telefonów „na już”, mniej paniki, więcej zaplanowanych działań i transparentne uzasadnienie decyzji przed kierownictwem.

Gdzie predykcyjne utrzymanie ma sens – typowe maszyny, procesy i branże

Priorytety: krytyczność maszyn vs. koszty przestojów

Nie każda maszyna w zakładzie wymaga zaawansowanego predykcyjnego utrzymania z AI. Koszt budowy systemu trzeba zestawić z potencjalnymi stratami z tytułu przestojów i awarii. Dobrym startem jest ocena:

• krytyczności maszyny dla przepływu produkcji,
• kosztu godziny przestoju (utracona produkcja, kary za opóźnienia),
• kosztu typowych awarii (części, roboczogodziny, straty jakościowe),
• dostępności obejścia (maszyny rezerwowe, alternatywne ścieżki).

Najlepsze kandydatury na pilota predykcyjnego utrzymania to:

• maszyny będące wąskimi gardłami całej linii,
• urządzenia o długim czasie naprawy (np. piec, duża sprężarka),
• maszyny o drogich, krytycznych komponentach (łożyska, wrzeciona),
• linie, których zatrzymanie generuje kary umowne lub utratę kluczowych klientów.

Dobrym podejściem jest stworzenie prostego rankingu maszyn pod kątem krytyczności i potencjalnego ROI predykcyjnego utrzymania. Dzięki temu decyzja, gdzie zacząć, przestaje opierać się na intuicji.

Typowe grupy maszyn, gdzie AI w utrzymaniu ruchu działa najlepiej

Niektóre typy urządzeń są szczególnie wdzięczne do zastosowania analizy danych z czujników i modeli predykcyjnych. Najczęstsze grupy to:

• Silniki elektryczne – od małych napędów pomp po duże silniki głównych napędów linii; sygnały prądu, drgań i temperatury dają bogaty materiał do analizy.
• Sprężarki – krytyczne dla całej infrastruktury sprężonego powietrza; awaria często zatrzymuje wiele linii naraz, a naprawy są kosztowne.
• Pompy i wentylatory – kluczowe w chemii, wod-kan, energetyce; analiza drgań i obciążenia pozwala wychwycić kawitację, niewyważenie, luzy.
• Przenośniki taśmowe i rolkowe – ich zatrzymanie zatrzymuje przepływ materiału; AI pomaga wykryć zużycie łożysk, rozciągnięcie taśmy, problemy z napinaniem.
• Obrabiarki CNC – wrzeciona, prowadnice, śruby kulowe; modele AI potrafią wykrywać pogarszający się stan zanim dojdzie do kosztownego uszkodzenia i utraty jakości.
• Piece, suszarnie, wtryskarki – wszędzie tam, gdzie stabilność temperatury i ciśnienia ma kluczowe znaczenie dla jakości produktu.
• Roboty przemysłowe – szczególnie przy intensywnej pracy i skomplikowanych trajektoriach; analiza momentów, prądów, czasów cyklu ujawnia narastające problemy mechaniczne.

Im więcej maszyna generuje danych (drgania, prąd, temperatura, pozycje), tym większy potencjał wykorzystania AI w predykcyjnym utrzymaniu ruchu.

Procesy ciągłe vs. dyskretne – różnice w podejściu do danych

Procesy ciągłe (chemia, petrochemia, rafinerie, produkcja cementu, wod-kan) charakteryzują się:

• nieprzerwanym przepływem medium (gaz, ciecz, proszek),
• małą tolerancją na zatrzymania,
• bogatym zestawem sygnałów procesowych (ciśnienie, przepływ, poziom, temperatura),
• zazwyczaj rozbudowanymi systemami DCS/SCADA.

W takich środowiskach predykcyjne utrzymanie z AI oparte jest często na:

• modelach anomalii procesowych (detekcja odchyleń od typowego profilu),
• modelach zużycia pomp, wentylatorów, zaworów,
• prognozowaniu awarii na bazie trendów sygnałów procesowych.

Procesy dyskretne (motoryzacja, AGD, elektronika, opakowania) to produkcja sztukowa lub małoseryjna. Charakterystyka:

• wiele krótkich cykli,
• bardziej złożone sekwencje ruchów (roboty, manipulatory),
• mieszanka sygnałów procesowych i sygnałów sterowania ruchem (CNC, serwonapędy),
• częste zmiany asortymentu i receptur.

Tutaj AI w utrzymaniu ruchu często skupia się na:

• analizie drgań i prądów napędów w czasie cyklu,
• analizie czasów cyklu i mikroprzestojów (wzorce degradacji wydajności),
• powiązaniu jakości produktu z kondycją maszyny (np. zużycie narzędzi CNC).

Przykład: linia pakująca z nawracającymi zacięciami

Typowy scenariusz z zakładu produkcji FMCG: linia pakująca co jakiś czas zatrzymuje się z powodu zacięcia produktu. Mechanicy czyścić i regulują mechanikę, ale problem wraca nieregularnie, bez jasnego wzorca.

Zastosowanie predykcyjnego utrzymania z AI może wyglądać następująco:

• montaż czujników drgań i prądu na głównych napędach przenośników i mechanizmach pakujących,
• rejestracja kilkudziesięciu-kilkuset cykli pracy, w tym tych zakończonych zacięciem,
• oznaczenie w danych, które cykle zakończyły się błędem (etykiety),
• zbudowanie modelu, który rozpoznaje wzorzec narastających drgań / przeciążeń poprzedzających zacięcie,
• wdrożenie systemu ostrzegającego operatora kilkanaście lub kilkadziesiąt sekund wcześniej, że ryzyko zacięcia rośnie – z możliwością spowolnienia linii lub krótkiego zatrzymania w kontrolowanym momencie.

Takie podejście często pozwala zamienić kilka niekontrolowanych przestojów dziennie na jeden, ale za to zaplanowany postój na czyszczenie lub regulację.

Dane do predykcyjnego utrzymania: co zbierać, jak i z jaką częstotliwością

Kluczowe typy danych dla predykcyjnego utrzymania

Na początek trzeba rozdzielić dane na kilka podstawowych kategorii. Dopiero ich połączenie daje sensowne modele, a nie tylko ładne wykresy.

• Dane procesowe i sterujące – ciśnienia, temperatury, przepływy, poziomy, pozycje zaworów, czasy cyklu, stany wejść/wyjść PLC. To „tło” pracy maszyny.
• Dane drganiowe – przyspieszenia, prędkości, przemieszczenia z akcelerometrów; podstawa diagnostyki łożysk, niewyważenia, luzów, niewspółosiowości.
• Dane elektryczne – prądy fazowe, napięcia, THD, harmoniczne, cos φ; kluczowe przy silnikach, napędach, transformatorach.
• Dane termiczne – temperatury korpusu, łożysk, uzwojeń, oleju, medium; często pierwszy sygnał przegrzewania lub zatarcia.
• Dane eksploatacyjne – liczba cykli, czas pracy w różnych trybach, liczba uruchomień, ilość przetworzonego medium.
• Dane z UR – zlecenia pracy, typy awarii, wymienione części, czas naprawy, przyczyny źródłowe; bez tego model nie „zrozumie”, co jest faktyczną awarią.
• Dane jakościowe – odrzuty, reklamację, wyniki kontroli międzyoperacyjnych; ważne przy modelach łączących stan maszyny z jakością produktu.

Sama telemetria z czujników bez powiązania z rzeczywistymi awariami i działaniami UR da tylko modele anomalii. Żeby przejść na poziom prognozowania konkretnych usterek, potrzebne są też dane „miękkie” z systemów UR i jakości.

Jak pozyskiwać dane z maszyn i systemów – typowe źródła

Źródła danych najczęściej już istnieją w zakładzie. Sztuka polega na tym, żeby je połączyć w spójny strumień.

• PLC i sterowniki napędów – podstawowe sygnały procesowe, stany, liczniki, alarmy; komunikacja najczęściej po OPC UA, Modbus, Profinet, Ethernet/IP.
• SCADA / DCS – historyczne przebiegi sygnałów, alarmy, receptury; często najlepsze źródło danych historycznych do pierwszych analiz.
• Czujniki dodatkowe – akcelerometry, czujniki temperatury, przetworniki prądu; montowane na krytycznych punktach (łożyska, korpusy, szafy napędowe).
• System CMMS / EAM – zlecenia pracy UR, historia awarii, części zamienne; kluczowe źródło etykiet do modelowania (co, kiedy i dlaczego się zepsuło).
• MES / systemy produkcyjne – zlecenia produkcyjne, czasy cyklu, mikroprzestoje, zmiany asortymentu; potrzebne do łączenia stanu maszyny z kontekstem produkcji.
• Systemy jakości – wyniki kontroli, raporty braków, reklamacje; przydatne, gdy celem jest np. prognozowanie zużycia narzędzi przez spadek jakości.

Dobrą praktyką jest zmapowanie na jednej kartce A4: jakie sygnały mamy, w jakich systemach, z jaką rozdzielczością oraz kto jest „właścicielem” każdego źródła danych (automatyk, UR, IT, produkcja).

Częstotliwość zbierania danych: jak nie przesadzić ani w jedną, ani w drugą stronę

Dobór częstotliwości próbkowania to częsty punkt sporny między UR, automatyką i IT. Prosty schemat pomaga urealnić oczekiwania.

• Szybkie zjawiska mechaniczne (drgania łożysk, uderzenia, kawitacja): częstotliwości od 1 kHz do 25 kHz i więcej, zwykle w krótkich „oknach pomiarowych” (np. kilka sekund co kilka minut). Dane takie rzadko idą „surowo” do chmury – lepiej liczyć lokalne cechy (RMS, widmo, obwiednia).
• Prądy silników przy analizie stanu: od kilkuset Hz do kilku kHz, zależnie od metody. Podobnie jak drgania – często przetwarzane na brzegu sieci.
• Typowe sygnały procesowe (temperatura, ciśnienie, przepływ): od 1 s do 1 minuty, w procesach bardzo dynamicznych szybciej. Dla większości modeli predykcyjnych w UR krok 1–5 s jest w zupełności wystarczający.
• Stany binarne, liczniki, czasy cykli: rejestrowane przy każdej zmianie stanu lub zdarzeniu (zmiana trybu, start/stop cyklu, błąd, reset).
• Dane UR / CMMS: z natury są „zdarzeniowe” – nowe zlecenie, nowa awaria, zakończenie naprawy.

Najczęstszy błąd na starcie to logowanie wszystkiego co 100 ms „na wszelki wypadek”. Serwery rosną, modele nie stają się lepsze. Lepiej jasno ustalić: co wymaga wysokiej częstotliwości, a co można próbować rzadko, ale z dobrą jakością opisową.

Format i struktura danych – jak ułatwić życie modelom i ludziom

Nawet najlepsze czujniki nic nie dadzą, jeśli dane będą niespójne i nieopisane. Kilka prostych zasad porządkujących sytuację:

• Ujednolicone nazewnictwo tagów – nazwy sygnałów powinny zawierać maszynę, lokalizację i typ wielkości (np. LINIA1_POMPA3_BRG_OUT_TEMP zamiast AI_23).
• Spójne jednostki – konwersje z bar na kPa czy z °F na °C trzeba wykonać raz i porządnie, najlepiej jak najbliżej źródła.
• Znaczniki czasu w jednym standardzie – najlepiej UTC, z jasno zdefiniowaną strefą i bez „cichych” zmian przy przejściu na czas letni/zimowy.
• Metadane – typ czujnika, zakres pomiarowy, lokalizacja montażu, sposób mocowania; bez tego interpretacja drgań czy temperatur jest mocno utrudniona.
• Opis stanów pracy – tryb auto/manual, praca/stop, rozruch, czyszczenie, awaria; modele muszą wiedzieć, w jakim stanie była maszyna w czasie danego pomiaru.

Dobrze przygotowany słownik tagów (prosty plik z opisami sygnałów i jego parametrami) przyspiesza cały projekt o tygodnie, bo nie trzeba za każdym razem odpytywać automatyki „co to jest AI_203?”.

Łączenie danych z różnych systemów – jak uniknąć „modeli bez kontekstu”

Modele AI potrzebują spójnego obrazu zdarzeń. Czyli trzeba zszyć dane z maszyn, UR, produkcji i jakości. Najważniejsze elementy tej „zszywki”:

• Czas – wszystkie systemy muszą być zsynchronizowane (NTP, jeden serwer czasu). Inaczej awaria zgłoszona w CMMS nie będzie się pokrywać z anomalią w sygnale.
• Identyfikatory maszyn – ten sam obiekt powinien mieć jeden globalny identyfikator w PLC, CMMS, MES i systemie AI.
• Powiązanie zleceń UR z sygnałami – np. każde zlecenie ma pola: „maszyna”, „początek”, „koniec”, „typ awarii”. To pozwala oznaczyć w danych czas „przed awarią” i „po naprawie”.
• Powiązanie zleceń produkcyjnych – numer zlecenia, produkt, receptura, zmiana; daje kontekst dla zmian w obciążeniu maszyny i jakości produktu.

Praktycznie oznacza to zwykle warstwę integracyjną (np. prosty data lake lub baza time-series plus tabela zdarzeń), a nie szukanie wszystkiego „ręcznie” w osobnych systemach.

Jakość danych: typowe problemy, które zabijają modele

Najwięcej projektów wykłada się nie na modelu, tylko na jakości danych. Kilka najczęstszych problemów:

• Brakujące fragmenty historii – dziury w logach po restartach serwerów, awariach sieci, zmianach konfiguracji; model „nie widzi” pełnego obrazu przed awarią.
• Przesunięte czasy – różne zegary, brak synchronizacji; anomalia w danych nie zgadza się z godziną zatrzymania zarejestrowaną przez operatora.
• Martwe czujniki – stała wartość 0 lub stała wartość niezmieniająca się od miesięcy, a alarmu brak.
• Błędna skala lub jednostki – np. temperatura w °F opisana jako °C, przepływ w Nm3/h jako m3/h.
• Nieopisane zmiany konfiguracji – wymiana czujnika, zmiana zakresu, zmiana punktu montażu, zmiana receptury – ale bez odnotowania w systemie.
• Ręczne „czyszczenie” logów – dopisywanie/zmienianie wpisów w CMMS, bo „źle kliknąłem”; dla modelu to fałszuje historię.

Prosty audyt danych przed startem projektu (kilka wykresów ciągłych trendów, statystyki braków, detekcja stałych wartości) pozwala wyłapać większość z tych problemów zanim zacznie się właściwe modelowanie.

Przygotowanie danych do modelowania – praktyczna sekwencja kroków

Żeby przejść od „surowych sygnałów” do zbioru danych gotowego do trenowania modeli, przydaje się powtarzalna sekwencja.

1. Wybór maszyn i sygnałów – na start nie potrzeba całego zakładu. Lepiej wybrać 1–3 krytyczne maszyny i kilka–kilkanaście kluczowych sygnałów (drgania, prąd, temperatura, wybrane sygnały procesowe).
2. Oczyszczenie i synchronizacja – usunięcie oczywistych błędów (stałe wartości, oczywiste skoki z powodu restartów), ujednolicenie formatów daty i czasu, dopasowanie próbkowania (resampling).
3. Dodanie kontekstu – do każdego rekordu dopięcie stanu pracy (auto/manual, praca/postój, typ produktu, receptura, numer zlecenia, zmiana).
4. Etykietowanie zdarzeń – oznaczenie przedziałów czasowych prowadzących do awarii (np. 2–24 h przed zgłoszeniem awarii danego typu) oraz okresów normalnej pracy.
5. Ekstrakcja cech – zamiast podawać modelowi surowe próbki w wysokiej częstotliwości, wyliczenie cech w określonym oknie czasowym (np. 30 s, 5 min).
6. Podział na zbiory uczące i walidacyjne – zwykle na osi czasu (starsze dane do trenowania, nowsze do walidacji), bez mieszania okresów z różnych faz życia maszyny.

Ta sekwencja może brzmieć jak praca „danych” a nie UR, ale bez zaangażowania ludzi z utrzymania (przy definiowaniu etykiet i cech) projekty szybko odlatują w stronę abstrakcyjnych modeli bez zastosowania.

Przykładowe cechy wyliczane z sygnałów – co faktycznie trafia do modelu

Modele rzadko pracują na surowych przebiegach. Zwykle dostają zestaw cech liczonych w ruchomych oknach. Kilka praktycznych przykładów:

• Z danych drganiowych:
  • wartość RMS i szczytowa przyspieszenia w osi X/Y/Z,
  • energia w wybranych pasmach częstotliwości (np. odpowiadających obrotom wału, uszkodzeniom łożysk),
  • współczynniki kurtozy i skośności (impulsowość sygnału),
  • indeks obwiedni dla wykrywania uszkodzeń bieżni łożysk.
• Z prądu silnika:
  • średnia i odchylenie standardowe prądu faz w oknie czasowym,
  • procentowy udział wybranych harmonicznych,
  • indeks asymetrii faz,
  • zmiany prądu przy rozruchu w stosunku do „zdrowego” wzorca.
• Z sygnałów procesowych:
  • tempo zmian (pochodna) temperatury, ciśnienia, przepływu,
  • liczba przekroczeń niskich progów ostrzegawczych,
  • czas przebywania w określonych zakresach,
  • wskaźniki stabilności (np. odchylenie standardowe w oknie).
• Z danych eksploatacyjnych:
  • liczba cykli od ostatniej wymiany kluczowego komponentu,
  • łączny czas pracy w warunkach „ciężkich” (wysokie obciążenie, wysoka temperatura medium),
  • liczba rozruchów na godzinę/dobę.

Ten etap to miejsce, gdzie doświadczenie inżyniera UR najbardziej się opłaca – to on wie, które zjawiska fizyczne są kluczowe dla danej maszyny i jak je przełożyć na liczby.

Dlaczego „złe” dane z CMMS potrafią zepsuć dobry model

Część projektów ma świetne sygnały z maszyn, ale słabe opisy awarii. Efekt: model nauczy się przewidywać nie to, co trzeba. Kilka typowych pułapek:

• Ogólnikowe opisy typu „nie działa” – brak rozróżnienia: awaria elektryczna, mechaniczna, procesowa. Model nie wie, co ma prognozować.
• Mieszanie działań planowych z awaryjnymi – wymiana łożyska przy postoju planowym zapisane jak awaria. Model wyciąga błędne wnioski z wcześniej „zdrowych” danych.

Jak sprytnie wykorzystać „miękkie” dane od operatorów i serwisów

Modele oparte wyłącznie na sygnałach z czujników często przeoczają detale, które ludzie widzą od razu. Chodzi o wszystkie „dziwne dźwięki”, „inny zapach”, „dziwnie długie rozruchy”. Tego nie ma w PLC, a bywa świetnym sygnałem wczesnego ostrzegania.

Żeby takie informacje trafiły do AI w formie nadającej się do analizy, trzeba je trochę zorganizować:

• Proste słowniki opisów – zamiast wolnego tekstu „dziwnie chodzi”, lista rozwijana:
  • „nietypowy hałas”,
  • „wibracje wyczuwalne ręką”,
  • „zapach spalenizny”,
  • „wydłużony rozruch”,
  • „częste zatrzymania z brytu/zaklejeń”.

  Każdy z takich opisów można dalej potraktować jak zdarzenie w danych.

• Ocena subiektywna w skali – prosty suwak 1–5: „ogólny stan maszyny wg operatora na koniec zmiany”. To nie jest precyzyjne, ale świetnie nadaje się jako dodatkowa cecha dla modeli.
• Krótka checklista przy zgłoszeniu awarii – np. 3–5 pytań „tak/nie”: „czy wcześniej występowały nietypowe drgania?”, „czy wystąpiły alarmy temperatury?”, „czy były niedawno prace przy instalacji? ”.

W praktyce wystarczy proste rozszerzenie formularzy w CMMS/MES i krótka instrukcja dla operatorów. Po kilku miesiącach takich zapisów modele mają dużo bogatszy kontekst, bez inwestycji w dodatkową automatykę.

Modelowanie: jakie podejścia sprawdzają się w predykcyjnym UR

Kiedy dane są już przygotowane, dochodzimy do wyboru podejścia modelowego. Dobrze jest zacząć od najprostszych metod, a dopiero później dokładać bardziej złożone modele.

• Proste modele progowe + statystyka – rozszerzenie klasycznego monitoringu:
  • dynamiczne progi bazujące na średniej i odchyleniu standardowym w danym trybie pracy,
  • współczynniki trendu (np. narastanie RMS drgań w czasie),
  • statystyczne wskaźniki stabilności (np. indeks Cp/Cpk dla krytycznych sygnałów).

  To często daje 80% wartości przy minimalnej złożoności.

• Modele anomalii (unsupervised) – szczególnie gdy brakuje dobrze opisanych awarii:
  • autoenkodery,
  • modele gęstości (np. Gaussian Mixture Models),
  • klasteryzacja stanów normalnych.

  Uczą się „normalności” i sygnalizują odchylenia, nawet jeśli typ awarii nie jest znany.

• Klasyfikatory nadzorowane – gdy mamy sensownie otagowane incydenty:
  • las losowy, gradient boosting,
  • proste sieci neuronowe,
  • modele liniowe z dobrze dobranymi cechami.

  Pozwalają przewidywać określony typ awarii (np. uszkodzenie łożyska) w horyzoncie czasowym.

• Modele szeregów czasowych – tam, gdzie kluczowa jest dynamika zjawisk:
  • LSTM/GRU,
  • Temporal Convolutional Networks,
  • klasyczne ARIMA/VAR dla prostszych przypadków.

Na starcie lepiej mieć kilka prostych modeli do różnych celów (np. anomalia drgań, anomalia zużycia energii, trend temperatury), niż jednego „magicznego” potwora, który ma przewidywać wszystko naraz.

Jak zbudować pierwszy, mały „stack” AI w UR

Zamiast od razu wdrażać duży system klasy enterprise, da się postawić mały, działający „stack” z kilku prostych klocków. Sprawdza się to zwłaszcza w średnich zakładach.

1. Źródło danych – PLC/SCADA + eksport z CMMS/MES.
2. Magazyn time-series – np. baza TSDB lub moduł historii w already używanym systemie, byle:
   • trzymał dane z sensowną rozdzielczością,
   • pozwalał szybko wyciągać fragmenty historii.
3. Warstwa przetwarzania – proste skrypty (Python, R) lub narzędzie typu notebook, w którym:
   • liczone są cechy,
   • trening i walidacja modeli,
   • proste raporty jakości danych.
4. Warstwa inferencji (online) – niewielki serwis, który:
   • pobiera świeże dane,
   • liczy cechy w ruchomych oknach,
   • przepuszcza je przez model i zapisuje wynik (np. „ryzyko awarii w 24 h”).
5. Prezentacja i alarmy – najlepiej w miejscu, gdzie ludzie już patrzą:
   • widok w SCADA,
   • raport mailowy raz na zmianę,
   • notyfikacje lub zlecenia w CMMS, gdy ryzyko przekroczy próg.

W praktyce najwięcej czasu pochłania nie model, tylko „sklejenie” tych elementów tak, by działały automatycznie i bez ręcznego odpalania skryptów.

Integracja predykcyjnego UR z CMMS – jak to zrobić sensownie

System AI bez połączenia z CMMS kończy jako ciekawostka. Żeby przewidywania faktycznie przekładały się na działania, trzeba włączyć je w normalny obieg pracy UR.

• Automatyczne zlecenia – przy przekroczeniu określonego progu ryzyka:
  • tworzy się zlecenie w CMMS z jasno opisanym powodem (np. „wysokie ryzyko uszkodzenia łożyska, model #DVG_V1”),
  • w zleceniu zapisują się podstawowe parametry z chwili alarmu (drgania, temperatura, obciążenie).
• Powód wizyty vs. faktyczna przyczyna – po zakończeniu zlecenia:
  • technik wybiera z listy faktyczną przyczynę (np. „poluzowane mocowanie”, „zużyte łożysko”, „brak nieprawidłowości”),
  • te informacje wracają do zespołu ds. danych jako etykiety dla poprawy modelu.
• Status predykcyjnych alarmów – przyda się krótka klasyfikacja:
  • „trafiony” – była usterka lub begunce uszkodzenie,
  • „fałszywy” – brak problemu,
  • „zbyt późny” – usterka wystąpiła przed interwencją.

  Taki log pozwala mierzyć skuteczność modelu w języku zrozumiałym dla UR, nie tylko w metrykach statystycznych.

Dobrym trikiem jest start od trybu „tylko podgląd” – AI generuje rekomendacje, ale nie tworzy automatycznych zleceń. Po kilku miesiącach, gdy zespół zobaczy, że modele faktycznie wyprzedzają awarie, można włączyć automatyzację.

Jak ustalić progi alarmowe dla modeli AI

Wyjście z modelu (np. prawdopodobieństwo awarii) to jedno, ale równie ważne jest przełożenie go na konkretną akcję. Zamiast jednego progu „alarm/ok”, lepiej zbudować logikę wielopoziomową.

• Strefa zielona – niskie ryzyko:
  • brak działań, tylko rejestracja historii,
  • monitorowanie czy model „trzyma” normalne stany.
• Strefa żółta – średnie ryzyko:
  • oznaczenie maszyny na liście przeglądów,
  • większa uwaga operatora (np. sprawdzenie wizualne, nasłuch),
  • planowana diagnostyka przy najbliższym postoju.
• Strefa czerwona – wysokie ryzyko w krótkim horyzoncie:
  • automatyczne zlecenie UR,
  • analiza sygnałów przez diagnostę (np. wibracje),
  • ew. planowany postój awaryjny, jeśli ryzyko dotyczy bezpieczeństwa lub drogiego komponentu.

Progi dla tych stref najlepiej ustalać empirycznie – na podstawie historii alarmów i faktycznych zdarzeń. Na początku można ustawić je konserwatywnie (większa liczba fałszywych alarmów), a potem stopniowo je wyostrzać.

Małe, szybkie pilotaże zamiast „wielkiego wdrożenia”

Z punktu widzenia UR dużo rozsądniejsze jest uruchomienie kilku małych pilotaży niż budowa wielkiego programu na cały zakład. Dobry pilot ma kilka cech wspólnych.

• Jasny, mierzalny cel – np. „zmniejszenie nieplanowanych postojów prasy X o 20% w ciągu 6 miesięcy” zamiast ogólnego „wdrożenie AI”.
• Ograniczony zakres – 1–2 maszyny, kilka kluczowych sygnałów, jeden typ awarii na początek.
• Krótki czas cyklu – od startu zbierania danych do pierwszych alarmów modelu nie powinno mijać wiele miesięcy; inaczej zespół traci zainteresowanie.
• Ścisła współpraca z UR i produkcją – cotygodniowe krótkie spotkania: co model wykrył, czy to miało sens, jakie były działania.

Po udanym pilotażu łatwiej uzasadnić dalsze inwestycje – już nie na poziomie obietnic, ale twardych liczb: mniej postojów, mniej „gaszenia pożarów”, bardziej przewidywalne remonty.

Rola ludzi UR w projektach AI – bez tego się nie uda

Modele nie zastąpią doświadczonych mechaników czy elektryków. Co więcej, bez nich nie powstaną sensowne rozwiązania. Kilka kluczowych ról po stronie UR:

• Wybór maszyn i przypadków użycia – to nie dział IT wie, które maszyny „bolą” najbardziej i ile kosztuje ich postój.
• Definiowanie etykiet zdarzeń – co traktujemy jako awarię, co jako działanie planowe, który okres czasu przed awarią jest istotny dla predykcji.
• Weryfikacja alarmów – szybka informacja zwrotna, czy alarm modelu miał sens, co faktycznie znaleziono na maszynie, czy i jak korelowało to z sygnałami.
• Wsparcie w interpretacji cech – np. czy wzrost kurtosis w danym paśmie drgań faktycznie oznacza wczesne stadium uszkodzenia, czy jest normalny dla tej konfiguracji.

Dobrym podejściem jest wyznaczenie „ambasadora AI” po stronie UR – jednej osoby, która ma kompetencje techniczne i cierpliwość, by tłumaczyć obie strony: ludziom od danych realia maszyn, a zespołowi UR – logikę modeli.

Szkolenia i zmiana sposobu pracy – jak przygotować zespół

Predykcyjne utrzymanie zmienia codzienną pracę. Mniej „gaszenia pożarów”, więcej analizy i decyzji na podstawie danych. Żeby to zadziałało, trzeba przygotować ludzi.

• Szkolenia praktyczne, nie marketingowe – krótkie warsztaty:
  • jak czytać wykresy z modeli,
  • co oznaczają podstawowe metryki (precision, recall, fałszywy alarm),
  • jak dokumentować wyniki interwencji pod kątem poprawy modeli.
• Standard pracy z alarmami predykcyjnymi – prosta instrukcja:
  • co robi operator po zobaczeniu alarmu,
  • co robi dyspozytor / mistrz zmiany,
  • kiedy wchodzi serwis z diagnostyką.
• Pokazywanie „wygranych” przypadków – konkretne historie: „model wykrył narastające drgania, zaplanowaliśmy wymianę łożyska na postój weekendowy, uniknęliśmy 8 godzin nieplanowanego postoju w tygodniu”.

Ludzie szybciej akceptują nowe narzędzia, jeśli widzą, że realnie ułatwiają życie, a nie dokładane są tylko jako kolejny obowiązek raportowy.

Skalowanie: od jednej linii do całego zakładu

Kiedy pierwsze projekty działają, pojawia się pytanie: jak to przenieść na dziesiątki lub setki maszyn? Kluczem jest standaryzacja.

• Biblioteka „szablonów modeli” – np. osobne szablony dla:
  • silników pomp i wentylatorów,
  • przekładni,
  • przenośników,
  • wytłaczarek, pras itp.

  Dla każdego szablonu zdefiniowany zestaw sygnałów, cech i typowych progów.

• Wspólne standardy tagów i metadanych – tak, by nowa linia „wpadała” w istniejącą strukturę bez rzeźbienia wyjątków.
• Proces onboardingu nowej maszyny – krótka checklista:
  • czy mamy sygnały X, Y, Z?
  • czy są poprawne zakresy i jednostki?
  • czy maszyna ma przypisany globalny identyfikator?
  • czy powiązano ją z obiektami w CMMS/MES?

Najczęściej zadawane pytania (FAQ)

Na czym dokładnie polega predykcyjne utrzymanie maszyn z AI?

Predykcyjne utrzymanie maszyn z AI polega na ciągłym lub regularnym zbieraniu danych z czujników (drgania, temperatura, prąd, dźwięk, obraz) i łączeniu ich z historią awarii oraz kontekstem produkcji. Na tej podstawie modele AI oceniają aktualny stan techniczny urządzeń i szacują ryzyko awarii w najbliższych godzinach, dniach czy tygodniach.

Praktycznie oznacza to, że zamiast czekać na awarię lub robić przeglądy „z kalendarza”, serwisujesz maszynę wtedy, gdy dane pokazują rosnące ryzyko. Dzięki temu spada liczba nagłych przestojów, a przeglądy i wymiany części są lepiej zaplanowane.

Czym różni się predykcyjne utrzymanie od prewencyjnego i reakcyjnego?

Utrzymanie reakcyjne to naprawa po awarii – maszyna stoi, produkcja czeka, ekipa UR gasi pożar. Utrzymanie prewencyjne opiera się na harmonogramach: co określony czas zatrzymujesz maszynę na przegląd, niezależnie od jej faktycznego stanu.

Utrzymanie predykcyjne wykorzystuje dane i AI, żeby ocenić rzeczywisty stan urządzenia. Przegląd lub wymianę części robisz, gdy ryzyko awarii przekroczy ustalony próg. Efekt:

• mniej nagłych awarii między przeglądami,
• mniej wymian „na wszelki wypadek”,
• lepsze dopasowanie serwisu do obciążenia maszyny i planu produkcji.

Jakie dane są potrzebne, żeby AI przewidywała awarie maszyn?

Podstawa to dane z czujników i systemów, które już masz lub możesz stosunkowo łatwo dołożyć. Typowy zestaw:

• drgania z akcelerometrów (często analizowane też w dziedzinie częstotliwości),
• prądy silników i parametry z falowników,
• temperatury łożysk, uzwojeń, oleju, mediów procesowych,
• dźwięk (mikrofony przemysłowe),
• obrazy z kamer (zużycie, pozycja elementów, nieszczelności).

Do tego dochodzą dane kontekstowe: historia awarii i napraw, typ produkcji, obciążenie linii, parametry pracy (prędkości, nastawy). Im lepiej połączysz dane techniczne z kontekstem produkcji, tym trafniejsze modele predykcyjne.

Jaki jest realny wpływ predykcyjnego utrzymania na planowanie produkcji?

Największa zmiana jest taka, że przestoje przestają być niespodzianką. Masz system wczesnego ostrzegania, który sugeruje okna serwisowe w czasie niższego obciążenia lub między zleceniami. Produkcja może wtedy spokojnie przeplanować zlecenia, zamiast reagować w trybie awaryjnym.

Dodatkowo:

• łatwiej zaplanować dostępność ekip UR i specjalistów zewnętrznych,
• logistyka części przechodzi z „na wszelki wypadek” na „just in time”,
• decyzje o zatrzymaniu maszyny można oprzeć na konkretnych danych i prognozach ryzyka, co ułatwia rozmowę między produkcją a UR i z kierownictwem.

Na jakich maszynach i w jakich branżach predykcyjne utrzymanie z AI ma największy sens?

Największy zwrot z inwestycji daje skupienie się na maszynach krytycznych dla przepływu produkcji i o wysokim koszcie przestoju. Typowe przykłady:

• silniki elektryczne (napędy główne linii, pomp, mieszadeł),
• sprężarki – często kluczowe dla wielu linii jednocześnie,
• pompy i wentylatory w chemii, wod-kan, HVAC,
• piece, suszarnie, duże prasy i inne urządzenia o długim czasie naprawy.

Sprawdza się to w motoryzacji, FMCG, chemii, hutnictwie, przetwórstwie tworzyw, energetyce – wszędzie tam, gdzie godzina przestoju kosztuje dużo, a masz ograniczone możliwości obejścia (brak maszyn rezerwowych).

Jak zacząć wdrożenie predykcyjnego utrzymania z AI w istniejącym zakładzie?

Praktyczny start to krótka lista kroków:

• ocena krytyczności maszyn (koszt przestoju, dostępność obejścia, czas naprawy),
• wybór 1–3 maszyn na pilota (wąskie gardła, drogie awarie),
• przegląd dostępnych danych z czujników i z CMMS/SCADA,
• dobór dodatkowych czujników tam, gdzie ich brakuje,
• zbudowanie prostego modelu predykcyjnego i jego test na realnych danych,
• włączenie wyników modelu w codzienny workflow UR i planowania produkcji.

Na początku nie chodzi o idealny system dla całego zakładu, tylko o szybkie pokazanie efektu na kilku krytycznych maszynach. To ułatwia dalsze decyzje inwestycyjne i buduje zaufanie zespołu do AI.

Czy progi alarmowe i klasyczne monitorowanie są jeszcze potrzebne przy AI?

Tak, progi alarmowe nadal są potrzebne. Działają jak warstwa bezpieczeństwa dla prostych, oczywistych sytuacji – brak przepływu, spadek ciśnienia, gwałtowny wzrost temperatury. Są szybkie, przewidywalne i dobrze znane automatykom.

AI stanowi nadbudowę nad tym systemem: analizuje wiele sygnałów naraz, patrzy na ich historię i kontekst pracy maszyny. Dzięki temu wychwytuje subtelne, wolno narastające problemy, które nie „wybijają” prostych progów, ale za kilka dni mogą zatrzymać linię. Najlepsze efekty daje połączenie obu podejść w jednym spójnym systemie.