Predictive maintenance w przemyśle: jak AI przewiduje awarie maszyn

Od reakcyjnego do predykcyjnego utrzymania ruchu

Klasyczne strategie utrzymania ruchu

Utrzymanie ruchu w większości zakładów przemysłowych przechodziło podobną drogę: od napraw „po fakcie”, przez przeglądy kalendarzowe, aż do podejść opartych na stanie maszyn. Predictive maintenance z użyciem AI jest kolejnym krokiem w tej ewolucji, ale nie zastępuje wszystkiego, tylko rozszerza arsenał narzędzi.

W uproszczeniu można wyróżnić trzy główne strategie:

Strategia reakcyjna jest najprostsza organizacyjnie: maszyna się psuje, wchodzi zespół UR, naprawia, zamawia części. W krótkiej perspektywie bywa akceptowalna przy tanich i niekrytycznych urządzeniach. W dłuższej skali generuje jednak ukryte koszty: nieplanowane postoje, nadgodziny, ekspresowe dostawy części, utratę jakości produkcji.

Strategia prewencyjna porządkuje chaos. Masz listy przeglądów, harmonogramy, okresowe wymiany łożysk czy filtrów. Zespół wie, co ma robić, a ryzyko nagłych awarii maleje. Problem w tym, że przeglądy są robione „na wszelki wypadek”. Często wymienia się elementy, które mogłyby bezpiecznie pracować dłużej, tylko dlatego, że tak wynika z kalendarza lub instrukcji producenta.

Predictive maintenance przenosi ciężar z kalendarza na stan faktyczny maszyn. Zamiast wymieniać łożysko „co 6 miesięcy”, system ostrzega, że łożysko nr 3 na linii X zaczyna się zachowywać inaczej i jego pozostały czas życia (RUL) jest krótszy od zakładanego. Dzięki temu można skupić zasoby tam, gdzie ryzyko awarii jest realne, a nie teoretyczne.

Typowe problemy w klasycznym utrzymaniu ruchu

Nawet dobrze zorganizowany dział UR bez analityki predykcyjnej boryka się z powtarzalnymi problemami. Najczęściej pojawiają się:

• nieplanowane postoje linii o wysokiej krytyczności,
• awarie, które „wracają” mimo wcześniejszych napraw,
• brak dostępnych części lub długi czas dostawy,
• trudność w udowodnieniu zarządowi sensu inwestycji w nowe maszyny lub remonty,
• brak spójnych danych historycznych o stanie maszyn i realnych przyczynach awarii.

Bez danych i analityki przewidywanie zachowania parku maszynowego odbywa się intuicyjnie. Jeden doświadczony mechanik „słyszy po dźwięku”, że coś jest nie tak z przekładnią. Problem pojawia się, gdy odchodzi na emeryturę lub gdy nadzoruje kilkadziesiąt urządzeń jednocześnie. Wtedy subiekwne obserwacje przestają wystarczać.

Predictive maintenance z AI systematyzuje tę wiedzę. Zamiast liczyć na to, że ktoś „usłyszy” zmianę w pracy maszyny, system śledzi trendy drgań, temperatury czy prądu i informuje, że poziomy odbiegają od typowego profilu danej maszyny w podobnych warunkach obciążenia.

Gdzie predictive maintenance naprawdę ma sens

Nie każda maszyna i nie każdy zakład potrzebuje od razu zaawansowanego systemu predykcyjnego. Kluczowe jest dobranie skali i obszaru wdrożenia. Największy sens ekonomiczny predictive maintenance ma wtedy, gdy:

• maszyny są krytyczne dla ciągłości produkcji (awaria zatrzymuje całą linię lub fabrykę),
• koszt nieplanowanego przestoju jest wysoki (utrata produkcji, kary umowne, marnotrawstwo surowca),
• awarie są powtarzalne, ale ich dokładny moment jest trudny do przewidzenia,
• części zamienne są drogie lub mają długi czas dostawy,
• masz dane z czujników lub możliwość ich relatywnie taniego dołożenia.

Dobrym kandydatem są np. linie pakujące, linie rozlewnicze, sprężarkownie, piece, przenośniki główne, maszyny w ruchu ciągłym. Dla tych obiektów godzina przestoju może oznaczać istotny koszt, a niekontrolowana awaria może dodatkowo uszkodzić inne elementy lub pogorszyć jakość produktów.

Mniej sensowne jest rozwijanie zaawansowanego systemu AI dla pojedynczej, małej pompy pomocniczej, której wymiana jest tania, a przestój nie wpływa istotnie na całą produkcję. Tam zwykle wystarczy dobrze zorganizowana prewencja lub prosty monitoring stanu online z progami alarmowymi.

Przykładowo: linia pakująca obsługująca głównego klienta, pracująca na trzy zmiany, jest typowym celem wdrożenia predictive maintenance. Każdy przestój to realny ubytek produkcji i ryzyko niezrealizowania dostaw. Z kolei mała pompa w układzie chłodzenia, która ma tani zamiennik na magazynie i szybki czas wymiany, zwykle nie uzasadnia inwestycji w model AI – wystarczy sensowny plan przeglądów i podstawowe alarmy.

Podstawy predictive maintenance: co faktycznie robi AI

Predykcja awarii a wczesne wykrywanie anomalii

Predykcyjne utrzymanie ruchu z użyciem AI opiera się głównie na dwóch podejściach: wykrywaniu anomalii oraz prognozowaniu czasu do awarii. Oba korzystają z danych z maszyn, ale odpowiadają na inne pytania.

Wczesne wykrywanie anomalii polega na zbudowaniu modelu, który uczy się, jak „normalnie” zachowuje się maszyna. Analizuje rozkłady drgań, temperatur, prądów, ciśnień przy różnych obciążeniach i warunkach pracy. Gdy aktualne sygnały zaczynają odbiegać od tego wzorca ponad ustalony poziom, system zgłasza anomalię. Nie zawsze oznacza ona natychmiastową awarię, ale sygnalizuje zmianę, którą powinien przeanalizować inżynier UR.

Predykcja awarii idzie krok dalej. Zamiast tylko wykrywać, że „coś się zmieniło”, model ML próbuje oszacować, kiedy prawdopodobnie nastąpi awaria lub kiedy ryzyko stanie się na tyle wysokie, że należy wykonać interwencję. Tu wchodzą modele prognostyczne RUL (Remaining Useful Life), które dają odpowiedź typu: „przy aktualnym trendzie drgań to łożysko ma przed sobą około X godzin bezpiecznej pracy”.

W praktycznych wdrożeniach obie metody często się łączy. Anomalia może być pierwszym sygnałem, a RUL pomaga zaplanować, kiedy faktycznie zarezerwować okienko na przestój i wymianę elementu. Dobrze dobrany próg anomalii i wiarygodny model RUL pozwalają uniknąć zarówno pochopnych działań, jak i niebezpiecznego odwlekania decyzji.

RUL – szacowanie pozostałego czasu życia maszyny

Modele prognostyczne RUL są kluczowe, gdy celem jest planowanie prac z wyprzedzeniem i minimalizacja łącznego czasu postoju. Z perspektywy użytkownika istotne są trzy elementy: jak model jest liczony, z czego korzysta oraz jak interpretować jego wyniki.

Do obliczania RUL wykorzystuje się dane historyczne, w których widać pełny „cykl życia” elementów – od montażu, przez okres pracy, aż po awarię lub wymianę. Model uczy się związków między przebiegiem sygnałów (np. drgań, temperatury, prądu) a momentem wystąpienia awarii. Im więcej przykładów różnych scenariuszy zużycia, tym bardziej wiarygodna prognoza.

Typowy model RUL wykorzystuje:

• dane z czujników (czasowe przebiegi parametrów),
• stany pracy (obciążenie, prędkość, tryb),
• informacje z CMMS: daty awarii, przeglądów, wymian, opisy usterek,
• czasem również dane środowiskowe (temperatura otoczenia, wilgotność, warunki pracy).

Wynik modelu RUL zwykle nie jest pojedynczą „sztywną” liczbą. Częściej dostajemy przedział ufności: np. z dużym prawdopodobieństwem element wytrzyma jeszcze między 120 a 200 godzin. Dla inżyniera UR ważniejsze od samej liczby jest to, jak szybko RUL się skraca, jak wygląda trend oraz na ile model jest stabilny w czasie.

Z czasem, gdy pojawiają się nowe dane i kolejne cykle awaryjne, modele RUL należy aktualizować. Bez okresowej weryfikacji przewidywania mogą się rozjechać z rzeczywistością, bo zmieniły się warunki pracy, typ smaru, dostawca części lub sposób obsługi maszyny.

Jak AI uczy się z danych historycznych

Modele AI w predictive maintenance bazują na danych historycznych – bez nich nie ma mowy o sensownych prognozach. Kluczowe są trzy rodzaje informacji: sygnały procesowe, zdarzenia i decyzje serwisowe.

Sygnały procesowe to przebiegi parametrów: drgań, temperatur, prądów silników, ciśnień, przepływów, pozycje siłowników, stany PLC. AI analizuje, jak te sygnały zmieniały się w czasie i jak wyglądał „typowy” profil dla danej maszyny przy konkretnym obciążeniu.

Zdarzenia to m.in. alarmy, zatrzymania awaryjne, błędy sterownika, zadziałania zabezpieczeń. One pozwalają powiązać nietypowe zachowanie sygnałów z konkretnymi problemami. Informacje o tych zdarzeniach często są rozproszone między SCADA, PLC i raportami operatorów – trzeba je scalić.

Decyzje serwisowe (z CMMS) to daty i zakres przeglądów, wymian podzespołów, remontów. Dla modelu AI to sygnał, że dany stan maszyny można traktować jako „odnowiony” lub „naprawiony”. Bez połączenia danych serwisowych z sygnałami z czujników trudno jest nauczyć model odróżniać naturalne zużycie od innych zjawisk.

Różnica między prostymi progami a modelami ML jest istotna. Progi działają lokalnie: „jeśli temperatura > 80°C, zgłoś alarm”. Nie uwzględniają trendu, zależności między parametrami ani kontekstu (np. wyższe obciążenie). Modele ML potrafią uwzględnić wiele zmiennych jednocześnie i skupić się na zmianach istotnych statystycznie, ignorując te, które są naturalną konsekwencją cyklu pracy.

Rola inżyniera utrzymania ruchu przy interpretacji wyników

AI nie zastępuje inżyniera utrzymania ruchu. Zmienia tylko sposób, w jaki dostarcza mu informacje. Zamiast prostego „alarm: przekroczony próg”, pojawiają się komunikaty typu „wzrost składowej drgań w określonym paśmie częstotliwości” albo „spadek przewidywanego RUL dla łożyska o 40% w ciągu tygodnia”. To wymaga interpretacji i decyzji.

Inżynier UR jest kluczowy na kilku etapach:

• dobór maszyn i elementów do monitorowania,
• weryfikacja, czy sygnały sugerujące anomalię mają sens techniczny,
• ustalanie priorytetów – kiedy reagować natychmiast, a kiedy obserwować,
• dostarczanie informacji zwrotnej do zespołu ds. danych: które alarmy były „fałszywe”, a które trafione.

Bez udziału praktyków modele będą generowały wiele nieprzydatnych alarmów albo „przegapiały” istotne zjawiska. Dopiero połączenie wiedzy domenowej (jak powinno zachowywać się konkretne urządzenie) z analityką AI daje efekt w postaci realnych oszczędności czasu i pieniędzy.

Dane z maszyn: fundament każdego systemu predictive maintenance

Jakie sygnały zbierać z maszyn

Jakość predictive maintenance zależy od jakości danych. Nawet najlepszy algorytm nie pomoże, jeśli brakuje podstawowych sygnałów albo są one zanieczyszczone błędami. Punktem wyjścia jest przegląd tego, co już jest dostępne w PLC, SCADA i istniejących systemach pomiarowych.

Najważniejsze typy danych przy predykcyjnym utrzymaniu ruchu:

• Drgania – kluczowe dla silników, przekładni, łożysk, wentylatorów, pomp. Zmiany amplitudy i widma częstotliwości pozwalają wykryć niewyważenie, niewspółosiowość, uszkodzenia bieżni łożysk, luz mechaniczny.
• Temperatura – pozwala monitorować przegrzewanie się silników, łożysk, przekładni, szaf sterowniczych, elektroniki mocy.
• Prąd i napięcie – przebieg prądu silnika sygnalizuje m.in. przeciążenie, zatarcia, zablokowanie mechanizmu, problemy w zasilaniu.
• Ciśnienie i przepływ – w układach hydraulicznych i pneumatycznych ujawniają nieszczelności, zapychanie filtrów, spadek wydajności pomp.
• Parametry procesowe z PLC/SCADA – prędkości linii, obciążenia, stany zaworów, licznik cykli, informacje o trybie pracy.
• Dane binarne – stany „ON/OFF”, zadziałania krańcówek, liczniki awaryjnych stopów, wyłączenia zabezpieczeń.

Częstotliwość próbkowania i ilość danych

Przy predictive maintenance szybko pojawia się pytanie: jak gęsto próbkujemy sygnały i ile danych trzymamy. Zbyt rzadkie próbkowanie „wygładzi” zjawiska, które mają znaczenie diagnostyczne, zbyt gęste wygeneruje lawinę danych trudną do przesłania i przechowywania.

Dla drgań łożysk w napędach szybkoobrotowych typowe częstotliwości to od kilku do kilkudziesięciu kHz. Dla temperatury, ciśnienia czy przepływu często wystarczy próbkowanie co sekundę lub rzadziej. Nie ma jednego uniwersalnego ustawienia – parametry dobiera się pod konkretną klasę zjawisk i czas ich narastania.

Żeby ograniczyć ilość danych, często stosuje się podejście mieszane: krótkie okna sygnału wysokiej częstotliwości przy wybranych zdarzeniach (np. start, zatrzymanie, zmiana obciążenia) plus sygnały zgrubne (średnie, min/max, odchylenia) zapisywane ciągle.

Jakość danych: szumy, braki i kalibracja

Modele AI są bardzo wrażliwe na jakość danych. Błędy kalibracji czujników, przeskoki w skalowaniu, brakujące fragmenty i „dziury” w rejestracji potrafią zniszczyć użyteczność modelu.

Częste problemy, które widać w projektach:

• czujniki zamontowane w niewłaściwym miejscu (np. drgania mierzone na obudowie, która tłumi sygnał z łożyska),
• przestawione zakresy pomiarowe – sygnał przez większość czasu „przyklejony” do dołu skali albo obcięty na górze,
• nieregularne próbkowanie i brak synchronizacji czasowej między źródłami,
• ręczne zmiany konfiguracji w PLC, które nie są nigdzie logowane.

Prosty audyt danych przed startem projektu predykcyjnego – kilka dni rejestracji i ich dokładna analiza – często pozwala wychwycić większość takich błędów taniej niż późniejsze próby „ratowania” modelu.

Łączenie danych procesowych, serwisowych i kontekstowych

Dane z czujników to tylko część obrazu. Żeby uczenie maszynowe miało sens, trzeba je połączyć z informacjami o zdarzeniach i pracach serwisowych oraz z kontekstem procesu.

Podstawowe źródła, które warto spiąć:

• SCADA/PLC – sygnały procesowe, alarmy, stany pracy, receptury,
• CMMS/ERP – zlecenia prac, opisy usterek, historia wymian, koszty,
• MES – zmiany, produkty, partie, OEE, czasy przezbrojeń,
• dane środowiskowe – temperatura hali, wilgotność, kurz, wibracje z otoczenia.

Dopiero w takim połączonym zbiorze można rzetelnie odpowiedzieć, czy np. wzrost drgań jest wynikiem faktycznego zużycia, czy po prostu innego trybu pracy i przeciążenia linii.

Technologie i architektura: od czujnika do modelu AI

Warstwa czujników i akwizycji danych

Na dole architektury są czujniki i moduły zbierające dane. Mogą to być klasyczne przetworniki 4–20 mA, moduły wejść analogowych w PLC, ale coraz częściej także inteligentne czujniki z interfejsami cyfrowymi (Ethernet, IO-Link, bezprzewodowe).

Kluczowe decyzje na tym poziomie:

• czy używać istniejących czujników procesowych, czy dołożyć specjalistyczne (np. akcelerometry do drgań),
• czy sygnał będzie próbkowany w PLC, czy przez osobny rejestrator (DAQ),
• jak zapewnić zasilanie i odporność na warunki przemysłowe (IP, temperatura, zakłócenia EMC).

Na tym etapie często oszczędza się najbardziej, a to on decyduje, czy dane w ogóle będą się nadawały do analizy AI.

Edge computing: przetwarzanie przy maszynie

Przesyłanie surowych, wysokoczęstotliwościowych sygnałów do chmury jest kosztowne i technicznie trudne. Dlatego w predictive maintenance szeroko wykorzystuje się komputery brzegowe (edge), które stoją fizycznie blisko maszyn.

Edge realizuje m.in.:

• wstępne filtrowanie i agregację sygnałów (średnie, odchylenia, FFT),
• wykrywanie prostych anomalii w czasie rzeczywistym,
• lokalne buforowanie danych przy problemach z siecią,
• czasem także inferencję modeli AI – szczególnie tam, gdzie liczy się opóźnienie.

Przykład z praktyki: na sprężarkowni edge liczy widma drgań co kilka sekund, do systemu centralnego wysyła już tylko kilkadziesiąt wybranych cech i wyniki klasyfikacji, a nie strumień kilkuset tysięcy próbek na sekundę.

Warstwa komunikacji i integracji z OT/IT

Między maszynami a platformą analityczną potrzebna jest stabilna komunikacja. W przemyśle dominuje OPC UA, MQTT, czasem jeszcze starsze protokoły (Modbus, Profinet z gatewayami).

Kilka kwestii, które pojawiają się przy projektowaniu tej warstwy:

• separacja sieci OT od IT i bezpieczne „mosty” komunikacyjne,
• standaryzacja nazw sygnałów i jednostek,
• mechanizmy buforowania i powtórnej wysyłki przy utracie łączności,
• kompresja i ewentualne szyfrowanie danych, jeśli idą poza zakład.

Brak porządku na tym poziomie kończy się tym, że każdy projekt AI ma swój własny, niestandardowy sposób podłączania się do maszyn – to zabija skalowalność.

Platforma danych i miejsce działania modeli AI

Na górze jest zwykle platforma danych: lokalny klaster, prywatna chmura lub publiczna chmura. Tam lądują zintegrowane dane i tam pracują cięższe modele.

Typowe elementy takiej platformy:

• hurtownia danych lub lakehouse – do przechowywania historii,
• silnik strumieniowy – do przetwarzania danych w czasie zbliżonym do rzeczywistego,
• środowisko do trenowania modeli (notebooki, pipeline’y ML),
• repozytorium modeli i narzędzia do ich wdrażania (MLOps).

Modele mogą działać wyłącznie w chmurze (inferencja po stronie serwera) lub być „wypychane” na edge. W praktyce często łączy się oba podejścia: szybka detekcja anomalii na brzegu, bardziej złożona analiza prognostyczna w centrum.

Bezpieczeństwo i dostępność systemu

Predictive maintenance dotyka bezpośrednio infrastruktury OT, więc kwestie bezpieczeństwa nie są dodatkiem, ale warunkiem koniecznym.

Trzeba zaplanować m.in.:

• uprawnienia dostępu do maszyn i danych (kto może oglądać, kto zmieniać konfigurację),
• aktualizacje oprogramowania na edge bez zatrzymywania produkcji,
• mechanizmy „fail-safe” – awaria systemu AI nie może zatrzymać linii,
• audytowalność – kto i kiedy zmienił model, progi, konfigurację alarmów.

W wielu zakładach system predykcyjny jest traktowany jak doradca: może generować rekomendacje, ale nie ma prawa samodzielnie ingerować w sterowanie maszyną.

Podejścia AI w predictive maintenance – przegląd praktyczny

Proste modele statystyczne i progowe

Na początku nie trzeba od razu sięgać po głębokie sieci neuronowe. Często wystarczą rozszerzone wersje znanych inżynierom metod: adaptive thresholding, kontrola statystyczna procesu (SPC), modele ARIMA dla sygnałów czasowych.

Takie podejścia:

• są łatwe do wytłumaczenia i zaakceptowania przez UR,
• działają dobrze przy stabilnych warunkach pracy,
• mają niskie wymagania obliczeniowe – nadają się na PLC lub prosty edge.

Ich ograniczeniem jest brak elastyczności przy zmiennych trybach pracy i złożonych relacjach między parametrami.

Modele nadzorowane: klasyfikacja i regresja

Gdy mamy oznaczone dane historyczne (które okresy poprzedzały konkretną awarię, jakie były tryby pracy), można budować modele nadzorowane: klasyfikatory (awaria/bez awarii, typ uszkodzenia) lub regresję (czas do awarii – RUL, poziom zużycia).

W praktyce często używa się:

• drzew decyzyjnych i lasów losowych – dobre przy danych tabelarycznych i mniejszej liczbie przykładów,
• gradient boosting (XGBoost, LightGBM) – gdy zależy na wysokiej skuteczności i wciąż dobrej interpretowalności,
• prostszych sieci neuronowych – gdy istotne są nieliniowe relacje i wiele cech.

Warunek powodzenia jest jeden: rzetelne etykiety. Bez spójnej historii awarii, dat wymian i opisów usterek model będzie „uczył się” na szumie.

Uczenie nienadzorowane i wykrywanie anomalii

W wielu zakładach poważnych awarii jest mało. To dobrze z punktu widzenia produkcji, ale źle dla klasycznych modeli nadzorowanych. Tu pojawia się uczenie nienadzorowane.

Popularne podejścia do detekcji anomalii:

• modele gęstości (np. Gaussian Mixture Models) – uczą się rozkładu „normalnych” danych,
• metody oparte na odległości (k-NN, Isolation Forest) – wykrywają punkty odbiegające od reszty,
• autoenkodery – sieci neuronowe kompresujące sygnał i mierzące błąd rekonstrukcji.

Ich zaletą jest to, że nie wymagają danych z awariami. Wadą – większa liczba fałszywych alarmów, jeśli nie są dobrze dostrojone i zweryfikowane z praktykami.

Modele sekwencyjne do danych czasowych

Sygnały z maszyn mają strukturę czasową: istotne są nie tylko bieżące wartości, ale ich historia i kolejność zdarzeń. Dlatego stosuje się modele sekwencyjne.

W praktycznych wdrożeniach można spotkać m.in.:

• LSTM/GRU – sieci rekurencyjne uczące się dłuższych zależności w czasie,
• 1D CNN – konwolucyjne sieci do analizy okien czasowych (np. fragmenty drgań),
• modele bazujące na Transformerach – coraz częściej w projektach pilotażowych.

Są one szczególnie przydatne przy prognozowaniu RUL na podstawie pełnych przebiegów z okresu zużycia elementu, a nie tylko pojedynczych „statycznych” cech.

Modele hybrydowe: połączenie fizyki i danych

W wielu przypadkach widać już gotowe modele fizyczne urządzeń: charakterystyki pomp, równania zużycia, modele cieplne silników. Łączenie ich z AI zwykle daje najbardziej stabilne efekty.

Przykłady takich hybrydowych podejść:

• model fizyczny oblicza oczekiwane parametry przy danym obciążeniu, AI ocenia odchylenie jako funkcję „kondycji” maszyny,
• AI uczy się korekt do uproszczonego modelu fizycznego, aby lepiej dopasować go do rzeczywistych warunków procesu,
• reguły oparte na wiedzy eksperckiej (if–then) filtrują wyniki modeli ML, redukując fałszywe alarmy.

Takie rozwiązania są łatwiej akceptowane przez inżynierów, bo nie zastępują ich wiedzy, tylko ją uzupełniają.

Przygotowanie danych i inżynieria cech z sygnałów maszynowych

Czyszczenie i synchronizacja danych

Surowe dane z maszyny rzadko nadają się wprost do karmienia modelu. Najpierw trzeba je oczyścić i zsynchronizować między różnymi źródłami.

Typowe kroki obejmują:

• usunięcie oczywistych błędów (wartości nierealne, skoki wynikające z resetu),
• interpolację lub oznaczanie braków danych,
• normalizację jednostek i skal,
• spójne ustawienie znaczników czasu (uwzględnienie opóźnień w transmisji).

Dla danych z wielu linii czy zakładów potrzebne jest też ujednolicenie słowników: te same typy usterek i stanów pracy muszą mieć wspólne kody i nazwy.

Segmentacja sygnałów: okna czasowe i cykle pracy

AI nie analizuje zwykle całego, wielomiesięcznego przebiegu w jednym kawałku. Sygnały dzieli się na krótsze fragmenty – okna czasowe – albo na kompletne cykle pracy maszyny.

Możliwe podejścia:

• okna o stałej długości (np. kilka sekund drgań) z określonym nakładaniem,
• segmentacja według zdarzeń procesowych: start/stop, zmiana receptury, zakończenie cyklu,
• segmentacja według stanu pracy (np. stabilna prędkość, przyspieszanie, hamowanie).

To, jak podzielimy sygnał, decyduje potem o tym, jakie cechy da się wyciągnąć i jak model „rozumie” kontekst pracy maszyny.

Inżynieria cech z sygnałów czasowych

Samo podawanie surowych próbek do modelu ma sens tylko przy bardzo zaawansowanych sieciach neuronowych i dużych zbiorach danych. W wielu projektach lepiej zadziała klasyczna inżynieria cech.

Dla sygnałów takich jak drgania, prąd czy ciśnienie typowo wyznacza się:

• cechy w dziedzinie czasu – średnia, RMS, odchylenie standardowe, kurtoza, skośność, współczynniki szczytu,
• cechy w dziedzinie częstotliwości – widmo FFT, moc w wybranych pasmach, częstotliwości charakterystyczne dla elementów (np. bieżnie łożysk),

Cecha cech nierównomiernych i przejściowych

Wiele usterek ujawnia się nie w stabilnej pracy, ale w momentach przejściowych: rozruch, zatrzymanie, nagła zmiana obciążenia. Warto wtedy wycinać osobne okna z tych faz i liczyć cechy opisujące dynamikę zmian.

Przydają się m.in.:

• tempo zmian (pochodne pierwszego i drugiego rzędu sygnału),
• czas dojścia do stanu ustalonego po rozruchu,
• przeregulowanie – maksymalne odchylenie względem wartości zadanej,
• liczba i amplituda „oscylacji” przed ustaleniem się sygnału.

Takie cechy często lepiej odzwierciedlają „zmęczenie” układu niż wartości w stanie ustalonym.

Fuzja cech z wielu czujników i systemów

Jedna maszyna zazwyczaj ma więcej niż jeden sygnał diagnostyczny. Prawdziwa siła predictive maintenance pojawia się, gdy łączy się cechy z drgań, prądu, temperatury, parametrów procesu i danych z systemów MES/CMMS.

Przykładowe sposoby łączenia:

• tworzenie cech relacyjnych (np. stosunek prądu do obciążenia, różnica temperatur między łożyskami),
• agregacja cech po poziomie: element–maszyna–linia (np. maksymalny poziom drgań na wszystkich łożyskach danej pompy),
• łączenie fizycznych sygnałów z kontekstem procesowym (receptura, zmiana, operator, partia).

Nawet prosty model, który widzi jednocześnie stan maszyny i kontekst produkcji, bywa skuteczniejszy niż skomplikowana sieć działająca tylko na jednym sygnale.

Redukcja wymiaru i selekcja cech

Po kilku iteracjach inżynierii cech liczba kolumn w tabeli rośnie lawinowo. To utrudnia trenowanie modeli, a często wręcz pogarsza wyniki przez przeuczenie.

W praktyce stosuje się kombinację metod:

• proste filtry statystyczne (usuwanie cech o zerowej wariancji, wysokiej korelacji między sobą),
• selekcję opartą na modelach (np. ważności cech z lasów losowych lub gradient boosting),
• metody redukcji wymiaru (PCA, UMAP) do tworzenia kilku „syntetycznych” cech opisujących główne kierunki zmienności.

Dobrym krokiem jest także odrzucanie cech, których inżynierowie nie są w stanie zinterpretować lub powiązać z fizyką procesu – zmniejsza to ryzyko artefaktów.

Etykietowanie danych pod kątem awarii i stanów pracy

Bez sensownego etykietowania nawet najlepsze cechy nie zadziałają. Chodzi nie tylko o zaznaczenie momentu awarii, ale też okresów poprzedzających, trybów pracy i działań serwisowych.

Najczęściej wprowadza się kilka typów etykiet:

• stan techniczny: normalny, podejrzany, uszkodzony, po naprawie,
• typ usterki: łożysko, niewyważenie, niewspółosiowość, problemy elektryczne,
• tryb pracy: rozruch, praca ciągła, praca przerywana, testy, postój planowy,
• zdarzenia serwisowe: przegląd, wymiana części, awaryjny stop.

Etykietowanie wymaga współpracy z UR i produkcją. Dobrą praktyką jest wspólne przeglądanie historii danych przy konkretnych awariach i budowa prostych „timeline’ów” z naniesionymi zdarzeniami.

Radzenie sobie z rzadkimi awariami i niezrównoważonymi danymi

Awarie są rzadkie, więc w danych dominuje stan „wszystko ok”. Klasyczne modele uczą się wtedy głównie przewidywać brak awarii.

W praktycznych projektach stosuje się kilka dróg:

• przekształcenie problemu na detekcję anomalii, gdy przypadków awarii jest bardzo mało,
• ważenie klas lub kosztów błędów (większa kara za przeoczenie awarii niż za fałszywy alarm),
• tworzenie „okien przedawaryjnych” – okresów bezpośrednio przed awarią, które oznacza się jako „wysokie ryzyko”,
• ostrożne oversampling/undersampling, głównie na poziomie okien, nie całych przebiegów.

Kluczowe jest, żeby data scientist nie „rozcieńczył” nielicznych awarii w oceanie normalnej pracy podczas przygotowywania zbioru treningowego.

Projektowanie etykiet dla czasu do awarii (RUL)

Szacowanie pozostałego czasu do awarii (Remaining Useful Life) wymaga innych etykiet niż klasyfikacja „awaria/ok”. Każdy fragment sygnału musi dostać wartość liczbową – liczbę godzin, cykli lub metrów produkcji do uszkodzenia.

Często stosuje się proste podejście:

• ustalenie momentu odniesienia: data wymiany części lub wystąpienia awarii,
• obliczenie różnicy czasu (lub liczby cykli) między danym oknem a tym momentem,
• normalizację RUL (np. przycięcie maksymalnej wartości, aby skrócić „ogon” daleko od awarii).

Warto też zdecydować, od kiedy zaczyna się „istotny” okres zużycia. Pierwsza faza życia komponentu zwykle nie wnosi wiele do prognostyki i generuje tylko szum w modelu.

Walidacja krzyżowa w czasie i unikanie przecieku informacji

Przy danych czasowych standardowa walidacja krzyżowa (losowe dzielenie na foldy) łatwo prowadzi do przecieku informacji. Model dostaje do uczenia dane z przyszłości względem tego, co ma przewidywać.

Rozwiązaniem jest walidacja z zachowaniem porządku czasowego:

• podział na bloki czasowe (train na starszych danych, test na nowszych),
• rolling window – kolejne iteracje z przesuwanym oknem treningowym i testowym,
• oddzielanie całych cykli życia komponentów (uczenie na jednych, test na innych).

Ten sam schemat warto stosować również przy strojenia progów alarmowych, aby nie dostrajać ich „pod historię”, której system w praktyce nie zobaczy.

Projektowanie progów alarmowych z myślą o operacjach

Model zwracający prawdopodobieństwo awarii lub wartość RUL to dopiero początek. Potrzebny jest jeszcze prosty, zrozumiały dla UR mechanizm przełożenia tego na konkretne alarmy i rekomendacje.

W praktyce definiuje się zwykle kilka poziomów:

• informacja – sygnał o pogarszającym się trendzie, bez natychmiastowej akcji,
• ostrzeżenie – konieczność zaplanowania inspekcji lub części zamiennej,
• alarm – rekomendacja zatrzymania maszyny lub natychmiastowego przeglądu.

Progi pomiędzy tymi poziomami wyznacza się w oparciu o:

• statystykę błędów modelu (np. rozkład przewidywanego RUL vs. rzeczywisty),
• konkretne wymagania biznesowe (koszt przestoju vs. koszt fałszywego alarmu),
• doświadczenie UR – ile czasu realnie potrzeba na przygotowanie przestoju.

Dobrze sprawdzają się widoki, w których obok statusu alarmu można podejrzeć surowe sygnały i cechy – inżynier może wtedy sam ocenić, czy model „ma rację”.

Cykliczne doskonalenie cech na podstawie incydentów

Najlepsze pomysły na nowe cechy pojawiają się po konkretnych awariach lub fałszywych alarmach. Zespół przegląda wtedy historię sygnałów z okresu incydentu i szuka wzorców, które model przeoczył lub zinterpretował źle.

Typowy cykl wygląda tak:

1. incydent (prawdziwa awaria lub fałszywy alarm),
2. analiza post-mortem: przegląd przebiegów, komentarze UR,
3. zidentyfikowanie potencjalnej cechy (np. „różnica temperatur między łożyskami rośnie szybciej niż średnia”),
4. wdrożenie nowej cechy, retrening modelu, ponowna walidacja.

Bez takiego cyklu cała inżynieria cech szybko się „zamyka” i przestaje odzwierciedlać rzeczywiste wyzwania na hali.

Standaryzacja cech pomiędzy maszynami i zakładami

Jeśli predictive maintenance ma działać na dużą skalę, ten sam typ cechy powinien mieć taką samą definicję w różnych lokalizacjach. Inaczej każdy model będzie „szyty na miarę” jednej linii i nie da się go przenieść.

Pomaga tu kilka prostych zasad:

• wspólne szablony cech dla klas urządzeń (np. wspólny zestaw dla silników, wspólny dla pomp),
• jednolite okna czasowe i częstotliwości próbkowania dla danej kategorii assetu,
• słownik nazw i aliasów sygnałów z mapowaniem na standardowe pola (np. temp_bearing_in, vib_axial_out).

Taka standaryzacja pozwala trenować modele globalne lub szybciej adaptować je z jednego zakładu do drugiego, zamiast zaczynać od zera przy każdej nowej instalacji.

Monitorowanie jakości danych w czasie

Na starcie projektu dane bywają pilnowane, ale po kilku miesiącach nowy czujnik zostaje źle skalibrowany, ktoś zmienia konfigurację PLC, a strumień danych po cichu się psuje. Model nadal coś liczy, tylko wyniki przestają mieć sens.

Dlatego obok modeli predykcyjnych przydają się osobne mechanizmy kontroli jakości danych:

• monitoring zakresów i rozkładów sygnałów (czy nie przesunęły się trwale),
• kontrola spójności między powiązanymi sygnałami (np. moc ≈ napięcie × prąd),
• alarmy przy długich brakach danych lub niespodziewanych zmianach częstotliwości próbkowania,
• „heartbeat” z edge – potwierdzenie, że każdy czujnik i gateway żyje i wysyła dane.

Bez takiej warstwy nawet najlepsza inżynieria cech i modele AI stają się z czasem coraz mniej użyteczne, choć na pierwszy rzut oka wszystko „działa”.

Kluczowe Wnioski

• Utrzymanie ruchu przeszło drogę od reakcyjnego, przez prewencyjne, do predykcyjnego – predictive maintenance nie zastępuje poprzednich strategii, lecz je uzupełnia i porządkuje.
• Reakcyjne utrzymanie ruchu bywa akceptowalne przy tanich, niekrytycznych maszynach, ale w dłuższym czasie generuje wysokie, często ukryte koszty przestojów, nadgodzin i utraty jakości.
• Prewencyjne, kalendarzowe przeglądy stabilizują pracę zakładu, jednak prowadzą do przedwczesnych wymian części i „przepłacania” za serwis, bo decyzje nie wynikają z faktycznego stanu maszyn.
• Predictive maintenance wykorzystuje dane z czujników i AI, aby podejmować działania na podstawie realnego stanu i prognoz (np. RUL łożyska), co zmniejsza koszty przestojów i lepiej wykorzystuje części oraz zasoby.
• Największy sens ekonomiczny predictive maintenance ma w przypadku krytycznych maszyn o wysokim koszcie przestoju i drogich, trudno dostępnych częściach, zwłaszcza gdy dostępne są dane pomiarowe lub można je łatwo pozyskać.
• Małe, niekrytyczne urządzenia (np. tania pompa z szybkim czasem wymiany) zwykle nie wymagają zaawansowanej analityki AI – wystarcza dobrze zorganizowana prewencja i prosty monitoring z progami alarmowymi.
• AI w predictive maintenance opiera się głównie na dwóch funkcjach: wczesnym wykrywaniu anomalii w zachowaniu maszyn oraz prognozowaniu czasu do awarii, co systematyzuje wiedzę doświadczonych mechaników i uniezależnia zakład od „słuchu” pojedynczych ekspertów.