Po co przewidywać awarie: perspektywa kosztów i ryzyka
Reagowanie, prewencja kalendarzowa i predykcja – trzy różne światy kosztów
Większość zakładów przechodzi podobną drogę: od gaszenia pożarów, przez przeglądy „z kalendarza”, aż po predykcję awarii maszyn opartą na danych. Każdy z tych modeli ma inną strukturę kosztów i ryzyk.
Reagowanie na awarie (run-to-failure) to podejście najprostsze organizacyjnie, ale często najdroższe w skutkach. Maszyna pracuje, aż się zatrzyma. Z punktu widzenia finansów oznacza to nieplanowane przestoje, nadgodziny, ekspresowe dostawy części, nerwowe przeplanowywanie produkcji. Czasem ma sens dla bardzo prostych, tanich urządzeń, ale przy maszynach krytycznych zwykle mści się wysokim kosztem przestoju.
Prewencja kalendarzowa próbuje ograniczyć ryzyko, ustawiając przeglądy i wymiany części według czasu lub przebiegu (np. co 6 miesięcy, co 1 000 godzin, co 100 000 cykli). Jest znacznie bezpieczniejsza niż pełne reagowanie, ale generuje sporo prac wykonywanych „na wszelki wypadek”. W efekcie część komponentów wymienia się zbyt wcześnie, a inne i tak potrafią paść pomiędzy przeglądami.
Predykcja awarii z pomocą AI dodaje do gry dane z czujników, systemów sterowania i historii awarii. Celem jest przewidywanie pogarszającego się stanu maszyny w czasie, a nie jedynie odhaczanie przeglądów. W idealnym scenariuszu przegląd lub wymiana są robione „w ostatnim bezpiecznym momencie”, z wyprzedzeniem wystarczającym do zaplanowania postoju i zaopatrzenia części.
Gdzie predykcja awarii daje największy zwrot z inwestycji
Nie każda maszyna jest dobrym kandydatem do predictive maintenance. Wdrażanie modeli ML w przemyśle bez selekcji prowadzi do przepalenia budżetu i rozczarowania. Zwrot bywa najwyższy tam, gdzie spotykają się trzy czynniki:
Wysoki koszt przestoju – maszyny, których zatrzymanie blokuje całą linię albo wymaga zatrudnienia zewnętrznego serwisu.
Powtarzalne awarie – elementy, które regularnie sprawiają kłopoty i których zachowanie da się zaobserwować w danych.
Dostępność sygnałów – istniejące czujniki lub możliwość taniego dołożenia prostych sensorów.
Typowe „złote punkty” to sprężarki, pompy, wentylatory, przenośniki, silniki główne, łożyska na kluczowych wałach. Te elementy są często tańsze w monitorowaniu i modelowaniu niż rozbudowane, niestandardowe linie montażowe, a generują realne ryzyko dla całego ciągu produkcyjnego.
Maszyna krytyczna to niekoniecznie ta najdroższa. Czasem mała, tania pompa jest jedynym źródłem chłodziwa czy medium procesowego i jej awaria zatrzymuje kilka wydziałów. Predykcja awarii takiego komponentu może szybko się zwrócić, nawet jeśli sama pompa kosztuje niewiele – kluczowy jest łańcuch skutków.
Jak szacować koszt przestoju pod kątem przyszłego ROI
Bez policzenia choćby przybliżonego kosztu przestoju ciężko później obronić projekt przed zarządem. Wystarczy prosty, konsekwentnie stosowany schemat. Dla każdej rozważanej maszyny określ:
Średni czas przestoju przy typowej awarii (w godzinach lub minutach).
Utraconą produkcję na godzinę (sztuki, tony, m², zależnie od produktu).
Marżę lub wartość dodaną na jednostkę produktu – nie przychód, lecz to, co faktycznie „ucieka z kieszeni”.
Typowe koszty dodatkowe – nadgodziny, serwis zewnętrzny, przyspieszone dostawy części.
W prostym wariancie: koszt przestoju = (czas przestoju × strata marży na godzinę) + koszty dodatkowe. Te liczby nie muszą być idealne, ważne, żeby były spójne i zapisane. Dobrze przechowywać je w prostym arkuszu lub w CMMS. Gdy predictive maintenance ograniczy liczbę lub długość przestojów, będzie można pokazać różnicę w twardych złotówkach.
Do tego dochodzi koszt ryzyka – kary umowne za opóźnienia, utrata zamówień od kluczowych klientów, wizerunek firmy. Tego nie da się zawsze dokładnie policzyć, ale warto mieć choćby kilka opisanych przypadków, kiedy awaria „zrobiła bałagan” wykraczający poza produkcję.
Kiedy predykcja awarii nie ma sensu ekonomicznego
Nie każdą maszynę opłaca się obejmować systemem predykcji awarii z pomocą AI. Pewna część parku maszynowego lepiej nadaje się do prostszych metod utrzymania ruchu. Typowe przypadki, kiedy można odpuścić modele ML:
Bardzo tanie, standaryzowane maszyny, które łatwo wymienić na zapasowe (np. małe wentylatory, pompki pomocnicze).
Urządzenia o krótkim cyklu życia, gdzie koszt zbierania danych i budowy modelu przekroczy zysk z przewidywania kilku awarii.
Maszyny pracujące sporadycznie, tylko w awaryjnych scenariuszach – brak wystarczającej historii danych.
Elementy jednorazowe, których nie naprawia się, tylko wymienia przy pierwszych oznakach problemu.
W takich miejscach lepszy efekt przyniosą proste checklisty przeglądowe, szkolenie operatorów i sensownie ustawione alarmy warunkowe. Predykcja awarii oparta na danych powinna celować w tamte 20–30% maszyn, które generują 70–80% ryzyka i kosztów.
Co w praktyce oznacza „predykcja awarii z pomocą AI”
Monitoring warunkowy, progi i modele ML – co je odróżnia
Wiele firm nazywa predykcją AW cokolwiek, co monitoruje maszynę. Tymczasem jest istotna różnica pomiędzy prostym monitoringiem warunkowym, regulami progowymi a modelami machine learning.
Monitoring warunkowy polega na obserwowaniu kilku parametrów (np. temperatury, ciśnienia, drgań) i reagowaniu, gdy przekroczą ustalone zakresy. To często wbudowane funkcje sterowników lub SCADA. Daje to szybkie ostrzeżenia, ale zwykle w fazie, gdy problem już jest zaawansowany.
Reguły progowe i logika if/then to rozwinięcie monitoringu: „jeśli temperatura > 80°C i równocześnie prąd silnika > 120% nominalnego przez 30 sekund, to zatrzymaj maszynę”. Te podejścia są zrozumiałe dla automatyka, łatwe do audytu, ale sztywne – nie dostosowują się do zmieniających się warunków pracy.
Modele ML w predykcji awarii uczą się na bazie historycznych danych zachowania maszyny w różnych stanach: normalnym, pogarszającym się, przedawaryjnym. Potrafią uwzględnić jednocześnie dziesiątki parametrów, statystyk, zależności nieliniowych, których człowiek nie zapisze prostą regułą. Zamiast sztywnych progów, model oblicza prawdopodobieństwo awarii lub odchylenie od typowego wzorca.
Typowe zadania: wykrywanie anomalii, klasyfikacja stanów i RUL
Predykcja awarii maszyn to nie jest jedno zadanie, lecz kilka możliwych podejść. Najpopularniejsze typy modeli to:
Wykrywanie anomalii – model uczy się, jak wygląda „normalna” praca maszyny, a następnie sygnalizuje nietypowe zachowanie. Przydaje się szczególnie wtedy, gdy brakuje solidnie opisanej historii awarii.
Klasyfikacja stanów – model przypisuje aktualny stan maszyny do jednej z klas, np. „OK”, „stan pogorszony”, „wysokie ryzyko awarii”, „awaria konkretnego podzespołu”. Wymaga to sensownie opisanych etykiet awarii i stanów przejściowych.
Prognoza czasu do awarii (RUL – Remaining Useful Life) – model stara się oszacować, ile czasu pozostało do przekroczenia pewnego krytycznego poziomu zużycia. To najbardziej zaawansowana forma i wymaga dobrej, długiej historii danych.
W praktyce wiele udanych wdrożeń zaczyna od wczesnego wykrywania anomalii, bo ten typ modeli jest mniej zależny od etykiet, a i tak daje wymierną korzyść: informację, że „coś się dzieje” dużo wcześniej niż standardowe alarmy.
Co tak naprawdę „przewiduje” model AI
Modele AI nie przewidują przyszłości w sensie absolutnym. Operują na prawdopodobieństwach i wzorcach. W predykcji awarii model zwykle odpowiada na jedno z pytań:
Na ile obecny stan różni się od tego, co uznajemy za zdrowe? (anomalie, odchylenia).
Do jakiej kategorii stanu można zakwalifikować bieżącą pracę? (klasyfikacja, np. „wzrost drgań łożyska”).
Z jakim prawdopodobieństwem w określonym horyzoncie czasowym nastąpi awaria? (prognoza ryzyka).
Jak długo można bezpiecznie pracować do planowanego postoju? (szacowanie RUL).
To istotne z punktu widzenia oczekiwań. Modele nie powiedzą: „łożysko padnie 17 maja o 14:35”. Bardziej sensowna forma to: „ryzyko awarii łożyska w ciągu najbliższych 7 dni wzrosło do wysokiego poziomu”. Dlatego predykcja powinna być powiązana z procesem decyzyjnym w utrzymaniu ruchu, a nie traktowana jako wyrocznia.
Predykcja awarii można budować stopniowo. Nie trzeba od razu inwestować w skomplikowane modele i pełną integrację wszystkich systemów. Prostą, praktyczną ścieżkę rozwoju można rozpisać na kilka poziomów:
Poziom 0 – czysto reaktywny: naprawy po awarii, brak spójnych danych o zdarzeniach, ewentualnie proste alarmy w PLC.
Poziom 1 – inteligentna prewencja kalendarzowa: uporządkowany CMMS, przeglądy planowane na bazie danych o awariach, ale bez zaawansowanej analizy sygnałów.
Poziom 2 – monitoring warunkowy + progi: zbieranie podstawowych sygnałów (temperatura, prąd, wibracje) i ustawianie progów, także dynamicznych (np. w zależności od obciążenia).
Poziom 3 – proste modele anomalii: modele budowane np. na jednej grupie maszyn, bez pełnej integracji z CMMS, ale już dające sygnały o nietypowym zachowaniu.
Poziom 4 – zaawansowane modele predykcji: integracja sygnałów, zdarzeń awaryjnych i danych produkcyjnych, automatyczne generowanie zleceń w CMMS na podstawie wyników modeli.
Dla wielu zakładów skok z poziomu 1 do 3 daje największy efekt vs. wysiłek. Zamiast od razu mierzyć w perfekcyjną prognozę RUL, lepiej postawić na to, by wcześniej wiedzieć, że maszyna zachowuje się inaczej niż zwykle – i połączyć to z procedurą reakcji utrzymania ruchu.
Jakie maszyny i procesy wybrać na start
Kryteria wyboru: krytyczność, awaryjność, dane
Dobór maszyn na pierwszy projekt predictive maintenance decyduje o tym, czy całość zostanie później rozwinięta, czy zamknie się jako „nieudany eksperyment”. Bezpieczniej jest poprzeć się twardymi kryteriami niż intuicją.
Podstawowe trzy kryteria:
Krytyczność dla ciągu produkcyjnego – czy awaria tej maszyny zatrzymuje linię, wydział, całą fabrykę, czy tylko spowalnia jeden etap?
Częstotliwość i dotkliwość awarii – ile razy w ostatnim roku dochodziło do istotnych zatrzymań i jak bardzo bolały finansowo.
Dostępność i jakość danych – czy maszyna już generuje mierzalne sygnały (SCADA, PLC, czujniki), czy wszystko trzeba dopiero zainstalować.
Na liście kandydatów najlepiej umieścić 10–20 maszyn, a później z pomocą utrzymania ruchu i produkcji zawęzić tę listę do 3–5 najbardziej sensownych na start. To ogranicza ryzyko rozpraszania zasobów i pozwala szybciej uzyskać pierwsze efekty.
Unikanie zbyt ambitnych startów: jedna linia zamiast całej fabryki
Częsty błąd: próba ogarnięcia całego zakładu jednym projektem. W efekcie powstaje rozległa, kosztowna infrastruktura, a modele AI są zbyt ogólne, by komukolwiek pomóc w codziennej pracy. Lepiej potraktować początek jako prosty pilot AI, dobrze ograniczony zakresowo.
Rozsądne podejście:
Wybrać jedną linię produkcyjną albo jedną grupę podobnych maszyn (np. wszystkie sprężarki o podobnej konstrukcji).
Skupić się na kilku punktach krytycznych – np. silnik główny, kluczowe łożyska, pompa obiegowa.
Zaplanować czas trwania pilota tak, aby objął minimum kilka awarii, zmian trybów pracy lub kampanii produkcyjnych.
Mały, ale mierzalny sukces na początku
Pilot powinien mieć jasno zdefiniowany cel biznesowy i techniczny, które da się policzyć po kilku miesiącach. Bez tego dyskusja szybko schodzi na poziom „czy wykres wygląda fajnie”.
Dwa przykładowe, realistyczne cele pilota:
Redukcja nieplanowanych przestojów wybranej linii o określony procent lub liczbę godzin w kwartale.
Wydłużenie czasu pracy między wymianami konkretnego podzespołu (np. łożyska) bez zwiększenia ryzyka awarii.
Dobrze działa podejście: niech pilot „spłaci się” na jednej–dwóch większych unikniętych awariach. Jeśli się uda – łatwiej obronić dalsze inwestycje. Jeśli nie – straty są ograniczone.
Źródło: Pexels | Autor: Marianna Zuzanna
Fundament: jakie dane są kluczowe dla predykcji awarii
Trzy główne kategorie danych
Skuteczne modele predykcyjne karmią się nie jednym, a kilkoma typami danych. Zwykle da się je podzielić na trzy koszyki:
Dane procesowe i operacyjne – to, co „widzi” sterownik: temperatury, prądy, ciśnienia, przepływy, pozycje, prędkości, stany wejść/wyjść cyfrowych.
Dane o zdarzeniach i serwisie – awarie, alarmy, przeglądy, wymiany części, krótkie postoje, zmiany nastaw.
Dane kontekstowe – rodzaj produkowanego asortymentu, zmiana, operator, tryb pracy, warunki otoczenia (np. temperatura hali).
W wielu zakładach istnieje już przynajmniej część z nich, tylko są rozsypane po systemach: PLC, SCADA, rejestry alarmów, CMMS, Excel operatorów. Zanim dołoży się choćby jeden czujnik, lepiej zebrać przegląd tego, co już jest.
Dane procesowe: co jest „must have”, a co „nice to have”
Przy pierwszym projekcie łatwo ulec pokusie: „zbierzmy wszystko, co się da”. Technicznie bywa to możliwe, ale biznesowo rzadko uzasadnione.
Przy wyborze sygnałów pomocne są cztery proste pytania:
Czy sygnał faktycznie reaguje na degradację podzespołu? Np. wzrost drgań łożyska vs. status „linia pracuje”.
Czy da się go wiarygodnie mierzyć w czasie? Sygnały, które często „znikają” lub są ręcznie nadpisywane, niewiele pomogą.
Czy jest powiązany z obciążeniem lub warunkami pracy? Przydają się sygnały, które pozwalają zrozumieć, co maszyna robiła, gdy nastąpiła awaria.
Czy da się go zbierać bez dużych inwestycji? Jeśli pozyskanie jednego parametru wymaga ingerencji w certyfikowany układ bezpieczeństwa, lepiej poszukać tańszego zastępstwa.
W praktyce jako „minimum sensowne” sprawdzają się:
prąd/pobór mocy silników kluczowych,
temperatury podzespołów narażonych na przegrzanie,
drgania w krytycznych łożyskach (nawet z prostych czujników przyspieszeń),
prędkości, pozycje, ciśnienia – tam, gdzie odchylone wartości są symptomem zacięć, nieszczelności czy zapowietrzeń,
liczniki cykli, uruchomień, godzin pracy.
Rozbudowane sygnały wysokoczęstotliwościowe (pełne widmo drgań, akustyka ultradźwiękowa) mogą dać większą dokładność, ale pochłaniają sporo budżetu i uwagi. Sensownie jest zacząć od kilku wolniejszych, stabilnych parametrów, które da się wygodnie zarejestrować i przeanalizować.
Dane o sterowaniu i trybach pracy
Modele, które widzą tylko temperaturę czy prąd, ale nie wiedzą, w jakim trybie pracowała maszyna, zachowują się jak lekarz badający tętno bez informacji, czy pacjent właśnie biegał, czy spał.
Praktyczne, często pomijane sygnały:
informacje o trybach pracy: automatyczny/ręczny/serwis, praca/stop, rozruch/hamowanie,
informacja o rodzaju produktu lub receptury,
sygnały o zmianie nastaw (setpointów), np. prędkości linii, ciśnienia zadawanego.
Te parametry nie zawsze są fizycznymi pomiarami, ale mocno pomagają modelowi odróżnić zmianę zachowania z powodu innego obciążenia od rzeczywistego symptomu awarii.
Dane o awariach i zdarzeniach: „brudne złoto” projektu
Dlaczego historia awarii jest ważniejsza niż kolejne czujniki
Bez wiarygodnej informacji, co było awarią, a co zwykłym postojem, najdroższy system zbierania sygnałów pozostanie tylko lepszą wizualizacją trendów. To właśnie dane o zdarzeniach mówią modelowi, kiedy maszyna „naprawdę miała problem”.
Źródła takiej wiedzy to m.in.:
zlecenia w CMMS (typ awarii, opis, wykonane prace, wymienione części),
dzienniki operatorów: papierowe, w Excelu, w aplikacjach na tablecie,
logi alarmów ze sterowników i SCADA,
raporty jakościowe (np. serie z dużą ilością braków z powodu konkretnej maszyny).
Te dane są często niekompletne, rozjechane czasowo, pełne skrótów i błędów. Mimo to to one pozwalają później połączyć konkretne anomalie sygnałów z realnym uszkodzeniem części.
Minimalny standard opisu zdarzenia
Nie trzeba od razu przebudowywać całego CMMS. Z punktu widzenia projektów predykcyjnych wystarczy kilka kluczowych pól opisanych w miarę konsekwentnie.
Przy każdym istotnym zdarzeniu (awaria, poważny alarm, większy postój) dobrze jest mieć przynajmniej:
czas początku i końca zdarzenia (z dokładnością do minut),
maszynę/podzespoły, których dotyczy problem,
typ zdarzenia – np. awaria – zatrzymanie, awaria – spadek wydajności, przegląd planowy, wymiana profilaktyczna,
przyczynę główną (jeśli znana) w formie listy wyboru, a nie wyłącznie wolnego tekstu,
oznaczenie, czy wymieniono istotne części i jakie.
Wolny opis tekstowy nadal jest przydatny, ale nie zastąpi znormalizowanego oznaczenia przyczyny i typu zdarzenia. Krótkie szkolenie brygadzistów i serwisantów, jak wybierać te kategorie, zwraca się szybko – nie tylko dla AI, ale i dla zwykłej analizy awaryjności.
Sprzątanie danych o zdarzeniach małymi krokami
Pełne uporządkowanie historii awarii z ostatnich kilku lat bywa kosztowne i mało realistyczne. Da się to zrobić bardziej „budżetowo”:
skupić się na wybranych maszynach pilotażowych, a nie na całym parku,
zacząć od ostatnich 6–12 miesięcy, gdzie pamięć zespołu jeszcze działa,
przygotować krótkie warsztaty z utrzymaniem ruchu, gdzie wspólnie doprecyzowuje się najważniejsze zdarzenia (co się naprawdę stało, kiedy, co wymieniono),
wprowadzić prostą zasadę: od dziś każde nowe istotne zdarzenie opisujemy już „po nowemu”, bez bezsensownego cofania się pięć lat wstecz.
Taki wariant nie da idealnej bazy, ale zwykle wystarcza, by zbudować pierwsze działające modele i jednocześnie nie sparaliżować codziennej pracy działu UR.
Czujniki i infrastruktura danych: minimum sensowne vs „złoty pałac”
Kiedy dołożyć czujnik, a kiedy da się bez niego
Nowe czujniki to nie tylko koszt zakupu. To także montaż, okablowanie lub komunikacja bezprzewodowa, integracja ze sterownikiem lub systemem zbierania danych, konserwacja i kalibracja. Zanim kupi się pierwsze urządzenie, przydaje się prosty filtr decyzyjny.
Czujnik ma sens, jeśli:
monitoruje podzespół o wysokiej krytyczności (awaria mocno boli finansowo lub bezpieczeństwowo),
typowe symptomy awarii tego podzespołu da się uchwycić pomiarem (np. drgania, temperatura, wycieki),
nie ma obecnie innego, pośredniego sygnału, który by to częściowo pokazywał (np. wzrost poboru prądu),
koszt zainstalowania i utrzymania czujnika jest kilkukrotnie niższy niż potencjalna oszczędność wynikająca z unikniętej awarii.
Jeśli dwa–trzy warunki nie są spełnione, lepiej najpierw wycisnąć więcej z sygnałów, które już istnieją, oraz z lepszego opisu awarii.
„Minimum sensowne” dla pilota
Dla większości projektów na start wystarczy prosty zestaw:
wyprowadzenie kluczowych sygnałów procesowych z PLC/SCADA do systemu zbierania danych (historia w czasie, nie tylko wizualizacja na ekranie),
kilka dodatkowych czujników na rzeczywistych „punktach bólu” – np. łożyska, które najczęściej padają, pompy, na których zatrzymuje się produkcja,
jeden centralny magazyn danych dla pilota (może to być prosty serwer z bazą czasową lub rozwiązanie chmurowe),
podstawowe narzędzie do wizualizacji trendów (czasem wystarcza SCADA plus eksport do narzędzia analitycznego).
Zaawansowane platformy IoT, chmurowe hurtownie danych, streaming w czasie rzeczywistym – to wszystko może mieć sens, ale dopiero gdy pierwszy pilot pokaże, że dana linia lub grupa maszyn rzeczywiście zasługuje na „złoty pałac”. Wcześniej wystarczy solidna „blaszana hala” – proste, ale stabilne rozwiązanie.
Lokalne loggery vs systemy centralne
Przy mocno rozproszonych maszynach (np. sprężarki, pompy w kilku halach) często tańsze na początku są lokalne loggery danych, które zapisują sygnały na karcie SD lub w prostym buforze, a następnie okresowo zgrywa się je do centralnego repozytorium.
Taki wariant:
redukuje wymagania co do sieci przemysłowej i IT,
pozwala zacząć bez dużej ingerencji w istniejące sterowniki,
sprawdza się szczególnie tam, gdzie nie ma potrzeby reagowania w sekundach, lecz w godzinach lub dniach.
Gdy projekt się obroni i pojawi się potrzeba bieżących alertów online, loggery można stopniowo zastępować trwalszym rozwiązaniem centralnym, zamiast od razu kupować kompleksowy system dla całego zakładu.
Źródło: Pexels | Autor: Brett Sayles
Jak zbierać i łączyć dane: od sygnałów do „historii życia” maszyny
Synchronizacja czasu – drobny detal, który potrafi zabić projekt
Jeśli zegary sterowników, SCADA, CMMS i baz danych „pływają” względem siebie nawet o kilka minut, późniejsze powiązanie ich w jedną historię życia maszyny robi się wyjątkowo upierdliwe. Modele predykcyjne bardzo cierpią na takich przesunięciach.
Przy wdrożeniu pilota dobrze jest od razu:
uzgodnić jedno źródło czasu referencyjnego (np. serwer NTP w sieci zakładowej),
ustawić synchronizację zegarów w kluczowych sterownikach i systemach (przynajmniej tych, które biorą udział w pilocie),
zastosować wspólną strefę czasową i zasady dla czasu letniego/zimowego,
zarezerwować w projekcie trochę czasu na weryfikację spójności zegarów w praktyce, a nie tylko „na papierze”.
Ten krok często nie kosztuje prawie nic, a potrafi oszczędzić dziesiątki godzin późniejszego ręcznego dopasowywania logów i trendów.
Nadawanie kontekstu: od „liczb” do zdarzeń eksploatacyjnych
Sygnały z czujników same w sobie są mało zrozumiałe. Przydatne stają się dopiero wtedy, gdy zostaną powiązane z tym, co rzeczywiście działo się z maszyną: rozruchem, czyszczeniem, przezbrojeniem, wymianą części, awarią.
Prosty, lecz skuteczny schemat to budowa oś czasu maszyny, na której obok siebie odkłada się:
ciągłe pomiary (temperatury, prądy, drgania),
stany pracy (praca/stop, rozruch, tryb automatyczny/ręczny),
zdarzenia z CMMS (awarie, przeglądy, wymiany),
logi alarmów i komunikatów błędów.
Nawet prosty widok takiej osi czasu w narzędziu analitycznym pomaga na starcie: zespół UR i inżynier procesu może wtedy ręcznie „przeklikać” dane wokół znanych awarii i zobaczyć, jakie symptomy poprzedzały problem. To jest często pierwszy krok do zdefiniowania cech i etykiet pod modele AI.
Okna czasowe i „życie” podzespołu
Modele predykcyjne rzadko patrzą na pojedynczy odczyt czujnika. Zwykle analizują fragment historii – np. ostatnie 10 minut, 2 godziny czy 3 dni pracy. Taki fragment to tzw. okno czasowe.
Przy budowie danych pod AI praktyczne są dwa równoległe spojrzenia:
okna krótkie – minuty, czasem sekundy przed awarią lub alarmem (szukamy bezpośrednich symptomów),
okna długie – godziny lub dni od poprzedniej interwencji serwisu (patrzymy na „zmęczenie” podzespołu).
Dobrym nawykiem jest oznaczanie w danych cykli życia podzespołu: od montażu lub wymiany do kolejnej wymiany/awarii. Każdy taki cykl dostaje swoje ID. Dzięki temu można później łatwo odpowiadać na pytania typu „jak zachowują się drgania łożyska w pierwszej połowie życia vs tuż przed wymianą”.
Jeżeli CMMS nie wspiera tego wprost, wystarczy prosta konwencja nazewnicza w danych eksportowanych do analizy, np. LOZYSKO_M1_PRAWY_2023_10_12_01 jako identyfikator konkretnej sztuki i cyklu.
Łączenie danych z wielu systemów bez „doktoratu z integracji”
Pełna integracja CMMS, SCADA, PLC i MES w jednym „super systemie” to inwestycja na lata. Do pilota predykcyjnego da się podejść lżej, etapami.
Prosty, ale skuteczny wariant:
z każdego systemu (SCADA, CMMS, loggery) eksport danych do plików w powtarzalnym formacie (CSV, Parquet),
jeden skrypt lub proste narzędzie ETL, które scala dane po czasie i ID maszyny,
zapis scalonego zestawu w jednym repozytorium analitycznym (np. osobna baza lub folder w chmurze).
Na starcie często wystarczy cykl: raz dziennie eksport + scalanie. To pozwala analitykom i zespołowi UR pracować na pełnym obrazie bez od razu budowania kosztownego, real-time’owego rozwiązania integracyjnego. Gdy projekt pokaże zwrot, można dokładać kolejne elementy automatyzacji.
Radzenie sobie z brakami i „dziurami” w danych
W praktyce wiele linii ma okresy, gdy czujniki nie działały, logger się zawiesił albo ktoś odłączył zasilanie. Zamiast próbować wszystko naprawić ręcznie, lepiej z góry założyć, że dane będą niepełne i zaplanować, co z tym zrobić.
Przygotowując dane do modeli, opłaca się:
jawnie oznaczać przerwy (np. flagą „data_gap”), a nie udawać, że ich nie ma,
zastosować prostą politykę: krótkie braki (sekundy, pojedyncze minuty) można interpolować, długie (godziny, dni) – wycinać z uczenia,
nie mieszać w jednym zbiorze okresów pracy ze sprawnymi czujnikami i takich, gdzie ktoś testował nowe ustawienia lub serwisował sterownik (osobne etykiety w danych).
Model „nauczony” na bałaganie z okresów testowych będzie potem generował fałszywe alarmy. Dużo taniej jest od razu oznaczyć te okresy jako „nieprodukcyjne” i pominąć je w trenowaniu.
Tworzenie cech – czyli tłumaczenie sygnałów na coś zrozumiałego dla modelu
Surowy sygnał z czujnika to dopiero początek. Modele lepiej radzą sobie z cechami pochodnymi, które opisują kształt i zmiany sygnału. Zamiast przekazywać tysiąc próbek drgań, można opisać okno czasowe kilkunastoma liczbami.
Typowe, niedrogie obliczeniowo cechy to m.in.:
statystyki z okna: średnia, odchylenie, min, max, mediany,
proste miary dynamiki: nachylenie trendu, liczba przekroczeń progu, różnica między maksimum a minimum,
proporcje czasu spędzonego w poszczególnych stanach pracy (np. rozruch vs stabilna praca),
w przypadku drgań – energia w wybranych pasmach częstotliwości, ale tylko tam, gdzie rzeczywiście to pomaga (np. łożyska, przekładnie).
Na start przydaje się zasada „najpierw prosto”: kilkanaście–kilkadziesiąt cech na okno wystarczy, by zbudować pierwsze modele i zobaczyć, które z nich realnie odróżniają zdrową pracę od pogarszającego się stanu. Dopiero potem jest sens inwestować czas w bardziej wyrafinowane transformacje sygnału.
Samoucząca się baza wiedzy z awarii
Każda nowa awaria to szansa na „dokarmienie” modelu. Zamiast traktować projekt AI jako jednorazowy strzał, lepiej potraktować go jak systematyczne zbieranie doświadczeń z życia parku maszynowego.
Praktyczny schemat wygląda tak:
po istotnej awarii zespół UR i inżynier procesu krotko opisują zdarzenie w ustalonym formacie,
analityk lub osoba techniczna zdejmuje z systemu dane z ustalonego okna (np. 3 dni przed awarią) i dokleja etykietę,
raz na kwartał modele są aktualizowane o nowe przypadki – bez wielkiej ceremonii.
Taki rytm nie wymaga pełnoetatowego data scientist w zakładzie. Wystarczy jasno zaplanowana odpowiedzialność: kto „łapie” nowe przypadki i jak trafiają one do wspólnego repozytorium danych.
Od pierwszego modelu do użytecznych alarmów
Poziomy dojrzałości – od wykresu w Excelu do alarmu na hali
Dużo projektów zatrzymuje się na etapie „ładnych wykresów” w prezentacji. Często dlatego, że zespół rzuca się od razu na ambitną integrację z systemami produkcyjnymi. Rozsądniej jest przejść przez kilka prostych etapów.
Typowy, budżetowy tor rozwoju:
Poziom 1 – analiza offline. Dane z wybranego okresu są eksportowane, model trenowany jest „na boku”, a wyniki ogląda się z zespołem UR na spotkaniach (np. raz w miesiącu).
Poziom 2 – półautomatyczne scoringi. Raz na dobę (lub tydzień) uruchamiany jest skrypt, który liczy ryzyko awarii na podstawie danych z ostatnich dni. Raport (np. CSV czy PDF) ląduje w mailu brygadzisty.
Poziom 3 – integracja z systemem alarmów. Model działa ciągle lub co kilka minut, a przekroczenie progu ryzyka generuje sygnał do SCADA, CMMS lub komunikat SMS/email.
Przeskok z Poziomu 1 na 2 to zwykle kwestia dziesiątek godzin pracy, nie miesięcy. W wielu zakładach już ten poziom daje realne korzyści, bez inwestowania w infrastrukturę „na lata”.
Jak ustawić progi alarmowe, żeby nie „zatruć” użytkowników
Nawet świetny model da się zabić złym ustawieniem progów alarmowych. Zbyt niski próg – i utrzymanie ruchu zaczyna ignorować komunikaty. Zbyt wysoki – i system będzie „mądry” tylko na slajdach po awarii.
Sprawdza się podejście etapowe:
Faza cicha. Model liczy oceny ryzyka, ale nie wysyła alarmów. Zespół analizuje po fakcie, czy w okresach znanych awarii model faktycznie „widzi” rosnące ryzyko.
Faza miękkich alertów. Alerty wysyłane są np. raz dziennie w mailu lub do raportu, bez natychmiastowej reakcji wymaganej od brygady. Użytkownicy oceniają ich przydatność.
Faza twardych alarmów. Dopiero gdy precyzja jest akceptowalna, alarm trafia do kanału, który domyślnie wymaga reakcji (SCADA, SMS dyżurnego, zlecenie w CMMS).
Pod kątem kosztów uczenia się na błędach dużo taniej jest popełniać je w „cichej” i „miękkiej” fazie niż robić od razu integrację z głównym systemem alarmowym.
Łączenie predykcji z istniejącymi procedurami UR
Sam alarm z modelu nie naprawi maszyny. Jeżeli nie wiadomo, co z nim zrobić, będzie lądować w koszu mailowym. Dlatego predykcja musi być powiązana z konkretnymi działaniami serwisowymi.
Dobrym minimum jest prosty schemat reakcji dla każdego typu alertu, np.:
„wysokie ryzyko uszkodzenia łożyska M1 w ciągu 7 dni” → w ciągu 24h wykonać dogłębną diagnostykę (pomiar drgań offline, termowizja),
„rośnie ryzyko przeciążenia silnika M2” → sprawdzić obciążenie linii, ustawienia napędu i stan mechaniczny sprzęgła podczas najbliższego zaplanowanego postoju.
Procedury nie muszą być rozbudowane. Często wystarczy jedna strona w instrukcji UR i krótka narada przed startem pilota, żeby brygady wiedziały, co zrobić z nowym typem informacji.
Współpraca ludzi z modelem – kto „ma ostatnie słowo”
Przy predykcji awarii lepiej traktować model jako doradcę, a nie „szefa”. Ostatnie słowo i tak ma zespół UR i kierownik produkcji. Świadomość tego zmniejsza opór przed wdrożeniem AI.
Praktyczne podejście:
każdy alert ma możliwość „odkliknięcia” oceny przez człowieka: przydatny / zbędny / fałszywy,
raz na miesiąc krótka sesja, gdzie przegląda się kilka ostatnich alertów i decyzje zespołu,
dane o tym, które alerty były trafione, trafiają z powrotem do zespołu analitycznego jako materiał do ulepszenia progów i cech.
Taki prosty mechanizm informacji zwrotnej działa jak dodatkowy „czujnik”, który mówi modelowi, gdzie jego przewidywania nie mają sensu z perspektywy praktyki.
Najczęstsze błędy przy projektach predykcji awarii i jak ich uniknąć
Zaczynanie od „rakiety kosmicznej”, zamiast od prostego pilota
Częsty błąd to próba objęcia jednym projektem całego zakładu, wszystkich maszyn i pełnej chmury IoT. Kończy się to wielomiesięcznymi analizami, a brak jest szybkich efektów, które przekonują zarząd.
Bezpieczniejsza ścieżka to:
wybrać 1–3 maszyny o wysokiej krytyczności i w miarę sensownych danych,
zbudować wokół nich minimalny zestaw czujników i integracji,
w ciągu kilku miesięcy sprawdzić, czy da się z danych wyciągnąć przynajmniej kilka sensownych alertów.
Pilot na jednej linii kosztuje ułamek dużego wdrożenia, a dostarcza konkretnej wiedzy: które dane są naprawdę przydatne i gdzie są „wąskie gardła” organizacyjne.
Ignorowanie ludzi z utrzymania ruchu
Projekty prowadzone wyłącznie przez IT lub zewnętrznego dostawcę bez zaangażowania UR prawie zawsze lądują w szufladzie. Brakuje praktycznej wiedzy: jakie symptomy są istotne, jak często zdarzają się fałszywe alarmy, co da się zrobić w planowym postoju, a co wymaga dłuższego wyłączenia.
Dobry nawyk to minimalny „trójkąt” zespołu projektowego:
przedstawiciel utrzymania ruchu (znający praktykę, krytyczność maszyn),
osoba z automatyki/IT (dostęp do sterowników, SCADA, sieci),
analityk / dostawca AI (projektowanie modelu, przetwarzanie danych).
Nawet jeśli formalnie projekt prowadzi dostawca zewnętrzny, ktoś z UR powinien mieć prawo „veto” przy wyborze maszyn i interpretacji wyników.
Brak jasnych kryteriów sukcesu
„Chcemy AI do predykcji awarii” – to za mało, żeby ocenić, czy projekt ma sens ekonomiczny. Proste, mierzalne wskaźniki pomagają później podjąć decyzję, czy kontynuować inwestycje.
Przydatne, realistyczne kryteria na poziomie pilota:
liczba wczesnych ostrzeżeń (np. co najmniej dzień przed zdarzeniem), które faktycznie zakończyły się interwencją serwisu,
spadek nieplanowanych przestojów na wybranej maszynie w porównaniu do analogicznego okresu,
czas, jaki zespół UR spędza na analizie alertów vs. uzyskane oszczędności lub uniknięte koszty.
Nawet szacunkowe liczby pomagają rozmawiać z zarządem w języku pieniędzy, a nie ogólnych wrażeń.
Przeinwestowanie w hardware przy braku podstawowych danych eksploatacyjnych
Co warto zapamiętać
Predykcja awarii to trzeci, najbardziej opłacalny etap dojrzewania utrzymania ruchu po „gaszeniu pożarów” i prewencji kalendarzowej – celem jest działanie w ostatnim bezpiecznym momencie, a nie wymiany „na wszelki wypadek”.
Najwyższy zwrot z inwestycji w AI daje skupienie się na maszynach o wysokim koszcie przestoju, powtarzalnych awariach i z sensownym dostępem do sygnałów z czujników (np. sprężarki, pompy, wentylatory, kluczowe łożyska).
Maszyna krytyczna to ta, której awaria pociąga za sobą duży łańcuch skutków dla produkcji, a niekoniecznie najdroższe urządzenie – tania pompa chłodziwa potrafi zatrzymać kilka wydziałów naraz.
Bez policzonego kosztu przestoju (czas postoju, utracona marża na godzinę, nadgodziny, serwis, ekspresowe dostawy) trudno obronić projekt przed zarządem i potem pokazać realny efekt w złotówkach.
Nie opłaca się budować modeli ML dla tanich, łatwo wymienialnych maszyn, krótkoserii, urządzeń pracujących sporadycznie czy elementów jednorazowych – tam lepiej działają checklisty, przeglądy okresowe i proste alarmy.
Predykcja awarii powinna celować w 20–30% parku, który generuje 70–80% ryzyka i kosztów; resztę obsłużą tańsze metody utrzymania ruchu bez angażowania zespołu data science.
