Predykcyjne utrzymanie ruchu z AI. Model nie ma z czego się uczyć, jeśli nikt nie zapisywał awarii

Trzy różne rzeczy, które sprzedaje się pod jedną nazwą

Pierwszym krokiem jest rozdzielenie pojęć, bo pod hasłem „predykcyjne utrzymanie ruchu” oferuje się trzy zupełnie różne produkty, o różnej cenie i różnym progu wejścia. Pomieszanie ich jest najczęstszą przyczyną tego, że projekt kończy się instalacją czujników, z których nikt nie korzysta.

• Monitoring stanu. Czujnik mierzy drgania, temperaturę, pobór prądu albo ciśnienie, a system alarmuje przy przekroczeniu progu. To nie jest AI, to termostat z historią — i w wielu firmach to właśnie on daje osiemdziesiąt procent korzyści z całego projektu, za kilka procent jego kosztu.
• Wykrywanie anomalii. Model uczy się, jak maszyna pracuje normalnie, i zgłasza odstępstwa od tego wzorca. Nie wymaga historii awarii, bo nie przewiduje awarii — mówi tylko „zachowuje się inaczej niż zwykle”. To realistyczny punkt startu i jednocześnie główne źródło fałszywych alarmów, bo „inaczej” to też nowy materiał, inny operator i zmiana ustawień.
• Przewidywanie awarii i czasu pozostałego do niej. Model mówi, że łożysko padnie w ciągu dwóch tygodni. To jedyny wariant wymagający oznaczonych przykładów awarii z przeszłości i jedyny, który naprawdę zasługuje na nazwę predykcyjnego. Jest też najrzadziej osiągalny w firmie, która nie prowadziła dotąd porządnej dokumentacji awarii.

Dlaczego brak historii awarii zatrzymuje projekt

Model przewidujący awarię jest klasyfikatorem uczonym na przykładach: oto przebieg sygnałów, po którym nastąpiła awaria łożyska, a oto przebieg, po którym nie nastąpiło nic. Żeby się czegokolwiek nauczył, potrzebuje wielu przykładów pierwszej kategorii. Tu pojawia się problem, którego nie widać na prezentacji: w dobrze utrzymanej firmie awarie są rzadkie. Jedna maszyna, która psuje się trzy razy w roku, przy pomiarach co minutę daje zbiór, w którym awarii dotyczy jedna część na kilkaset tysięcy. Dla modelu najprostszą strategią maksymalizującą poprawność jest wtedy odpowiadać zawsze „nic się nie stanie” — i mieć 99,9% trafności.

Dlatego w tym projekcie liczba „trafność 99%” nie znaczy nic i jest sygnałem ostrzegawczym, nie argumentem sprzedażowym. Pytania, które mają sens, są dwa: ile awarii system wykrył z tych, które faktycznie wystąpiły, i ile alarmów okazało się pustych. Te dwie liczby stoją w sprzeczności — każde obniżenie progu czułości wyłapuje więcej awarii i generuje więcej fałszywych alarmów — a wybór punktu równowagi jest decyzją biznesową, nie techniczną. Zależy od tego, co kosztuje więcej: przestój czy niepotrzebny przegląd.

Jest też druga, mniej oczywista przeszkoda. Awarie, które faktycznie wystąpiły, zwykle nie są opisane w sposób nadający się do uczenia. Zlecenie w CMMS mówi „wymiana silnika”, ale nie mówi, czy silnik padł nagle, czy był wymieniony prewencyjnie przy innej naprawie, ani kiedy zaczął się psuć. Bez momentu początku objawów nie da się określić, które dane oznaczyć jako „przed awarią”. To jest realna praca, której nie wykona żaden dostawca — wymaga pamięci ludzi z utrzymania ruchu i kilku tygodni przeglądania dokumentacji maszyna po maszynie.

Tę część warto zresztą zrobić niezależnie od wdrożenia. Uporządkowana historia awarii z przyczyną, czasem przestoju i kosztem to podstawa każdej decyzji o parku maszynowym, a w większości firm powstaje po raz pierwszy właśnie przy takim projekcie. O tym, że przygotowanie danych jest zwykle większą częścią pracy niż sam model, pisaliśmy szerzej w tekście o danych gotowych na AI.

Założenie, które psuje harmonogramy przeglądów

Prewencyjne utrzymanie ruchu opiera się na założeniu, że części zużywają się z czasem i że istnieje moment, w którym warto je wymienić przed awarią. Dla części sprzętu to prawda. Dla większości nie — i to jest ustalenie znane w branży od dekad, od analiz niezawodności prowadzonych w lotnictwie, które pokazały, że dla znacznej większości elementów prawdopodobieństwo awarii nie rośnie wraz z wiekiem. Awarie mają charakter losowy albo pojawiają się najczęściej zaraz po ingerencji serwisowej.

Z tego wynikają dwa wnioski, które warto mieć w głowie przy rozmowie z dostawcą. Pierwszy: harmonogram przeglądów oparty na przebiegu albo na kalendarzu w wielu przypadkach nie zmniejsza liczby awarii, a generuje koszt i ryzyko — bo każda rozkręcona maszyna to okazja do wprowadzenia nowego błędu. Drugi, ważniejszy: skoro awaria nie wynika z wieku, to przewidzieć ją można tylko przez pomiar aktualnego stanu. Model karmiony samym przebiegiem i datami przeglądów nie ma dostępu do informacji, która jest potrzebna — i żadna ilość uczenia maszynowego tego nie nadrobi.

Dotyczy to także tego, czym maszyna jest obciążana. Ta sama prasa pracująca na cieńszej blasze zużywa się inaczej, a model, który nie zna parametrów produkcji, będzie każdą zmianę asortymentu widział jako anomalię. Dane produkcyjne z MES albo ERP są w tym projekcie równie ważne jak dane z czujników, co zwykle odkrywa się po pierwszym miesiącu fałszywych alarmów.

Ostrzeżenie, które przychodzi za późno, żeby cokolwiek zmienić

W utrzymaniu ruchu istnieje pojęcie opisujące to lepiej niż jakikolwiek slajd: odstęp między momentem, w którym awarię można już wykryć, a momentem, w którym maszyna faktycznie staje. Cała wartość wdrożenia mieści się w tym odstępie — i tylko wtedy, gdy jest on dłuższy niż czas potrzebny na reakcję.

Reakcja oznacza zwykle: zamówić część, czekać na dostawę, znaleźć okno w planie produkcji, przeprowadzić wymianę. Jeśli część ma czas dostawy trzech tygodni, a system ostrzega cztery dni przed awarią, to ostrzeżenie jest trafne i bezwartościowe — zmienia nieplanowany przestój w nieplanowany przestój, o którym wiedzieliście wcześniej. Dlatego pierwszą liczbą, którą trzeba ustalić dla każdej maszyny w zakresie, nie jest dokładność modelu, a wymagany czas wyprzedzenia. Dopiero on mówi, czy dana metoda pomiaru w ogóle się do tego nadaje: niektóre objawy pojawiają się tygodnie przed awarią, inne godziny.

Praktyczna konsekwencja dla zakresu projektu: zaczyna się od maszyn, które są wąskim gardłem i mają długie czasy dostaw części zamiennych. Maszyna, którą można obejść w pięć minut przestawieniem produkcji, nie jest kandydatem na pierwsze wdrożenie, nawet jeśli psuje się najczęściej w całej hali.

Fałszywe alarmy, czyli jak wdrożenie umiera cicho

Projekty tego typu przestają być używane rzadziej z powodu przeoczonych awarii, a częściej z powodu alarmów, które do niczego nie prowadziły. Mechanizm jest zawsze ten sam i rozgrywa się w ciągu kilku miesięcy: system zgłasza podejrzenie, mechanik idzie, sprawdza, nie znajduje nic. Przy trzecim albo czwartym takim przypadku zgłoszenia przestają być sprawdzane od razu, przy dziesiątym nikt ich nie czyta. Potem system wykrywa coś prawdziwego i ten jeden alarm też zostaje zignorowany — a wnioskiem w firmie jest, że „AI nie zadziałało”.

Z tego wynika projektowa zasada, którą warto zapisać w umowie: alarm musi mieć adresata, treść i zamknięcie. Adresat to konkretna osoba albo rola, nie wspólna skrzynka. Treść to nie „anomalia na maszynie 7”, ale wskazanie, który pomiar odbiega i od kiedy — bez tego nie da się zweryfikować zgłoszenia, więc nie da się go też odrzucić z czystym sumieniem. Zamknięcie to jedno kliknięcie i jedno zdanie od mechanika: potwierdzone, niepotwierdzone, inna przyczyna. Ta trzecia część jest w praktyce najważniejsza, bo stanowi jedyne źródło danych do poprawiania progów — a jednocześnie jest tym, co dostawcy najczęściej pomijają w wycenie.

Warto też z góry przyjąć, że pierwsze tygodnie będą pełne pustych alarmów, i zaplanować na to budżet czasu utrzymania ruchu. Problem nie leży w modelu, a w tym, że każdy park maszyn ma własny zestaw normalnych dziwności — remont hali, nowy wózek jeżdżący obok, zmiana dostawcy surowca. Okres kalibracji liczony w miesiącach jest regułą, nie usterką. Ogólną metodę budowania zestawów testowych i progów akceptacji opisaliśmy w tekście o testowaniu wdrożenia AI, a to, co dzieje się z takim systemem po uruchomieniu, w tekście o utrzymaniu AI po wdrożeniu.

Rachunek na własnym parku maszyn

Branżowe materiały podają redukcje przestojów rzędu kilkudziesięciu procent i zwrot w kilkanaście miesięcy. Te liczby pochodzą z firm o innym parku maszynowym, innym poziomie dokumentacji i zwykle o kilka rzędów wielkości większej skali, więc nie nadają się do Waszej decyzji. Policzcie trzy własne liczby.

• Koszt godziny przestoju maszyny, która jest wąskim gardłem. Nie koszt mechanika, a utracona marża z produkcji, która się w tym czasie nie odbyła, plus koszty opóźnionych dostaw do klientów. W firmach, które liczą tylko robociznę, ten rachunek wychodzi kilkukrotnie za nisko.
• Liczba nieplanowanych przestojów w ostatnich dwóch latach, z podziałem na maszyny i przyczyny. Jeśli nie da się tego wyciągnąć w ciągu dnia, to jest jednocześnie odpowiedź na pytanie, czy macie dane do uczenia modelu.
• Udział tych przestojów, które dałoby się wykryć zawczasu pomiarem. Przegląd z utrzymaniem ruchu, awaria po awarii. Zwykle okazuje się, że część awarii była nagła i niewykrywalna, część wynikła z błędu obsługi, a część z braku części na magazynie — i żadnej z tych trzech kategorii model nie dotknie.

Kiedy tego nie wdrażać

Jest kilka sytuacji, w których uczciwa odpowiedź brzmi: nie teraz. Nie dlatego, że technologia nie działa, ale dlatego, że pieniądze leżą w tym momencie w innym miejscu.

• Park maszyn liczy kilka sztuk. Przy pięciu maszynach i kilku awariach rocznie nie ma zbioru danych i nie będzie — a osoba, która te maszyny obsługuje, wie o nich więcej niż jakikolwiek model. Sensowną inwestycją jest tu monitoring progowy i zapas części krytycznych.
• Nie wiecie, ile Was kosztuje godzina przestoju. Bez tej liczby nie da się ustawić progu czułości ani ocenić oferty, bo nie wiadomo, co jest droższe: przeoczona awaria czy niepotrzebny przegląd.
• Większość awarii wynika z błędów obsługi albo z braku części na magazynie. To są problemy procesowe i rozwiązuje się je instrukcją, szkoleniem i polityką zapasu. Model przewidujący awarię nie zmieni ani jednego, ani drugiego.
• Maszyny nie mają sterowników, z których da się cokolwiek odczytać, a budżet nie przewiduje czujników. Projekt zamienia się wtedy w inwestycję w infrastrukturę pomiarową, co jest decyzją zupełnie innego rodzaju niż wdrożenie AI — i powinna być tak nazwana w rozmowie z zarządem.

Wdrożenie w osiem tygodni

Harmonogram jest dłuższy niż w projektach biurowych i pierwsze cztery tygodnie nie zawierają ani jednego modelu. To jest cecha, nie wada — w tym wdrożeniu kolejność decyduje o wyniku bardziej niż wybór narzędzia.

1. Tydzień pierwszy i drugi: inwentaryzacja awarii. Dwa lata historii, maszyna po maszynie: co się zepsuło, jak długo stało, ile kosztowało, czy było do przewidzenia. Wynikiem jest lista maszyn uszeregowana po koszcie przestojów, nie po liczbie awarii.
2. Tydzień trzeci: wybór jednej maszyny i jednego trybu awarii. Nie „monitoring linii”, a konkretnie: łożyska wrzeciona na tej jednej obrabiarce. Dla tego trybu ustalcie wymagany czas wyprzedzenia, czyli ile dni potrzebujecie na część i okno w produkcji.
3. Tydzień czwarty: pomiar. Sprawdźcie, co już macie w sterowniku i w systemie produkcyjnym, a czego brakuje. Dopiero tu podejmuje się decyzję o czujnikach — i dopiero tu wiadomo, jakich.
4. Tydzień piąty i szósty: zbieranie danych i próg bazowy. Najprostsza możliwa reguła progowa na tym jednym parametrze, uruchomiona równolegle z dotychczasową praktyką. To Wasz punkt odniesienia — model ma prawo wejść do projektu tylko wtedy, gdy ten próg pobije.
5. Tydzień siódmy: model wykrywania anomalii obok reguły progowej, oba zgłaszające do tej samej osoby, z obowiązkowym zamknięciem każdego zgłoszenia jednym zdaniem. Dwie liczby do pilnowania: ile zgłoszeń potwierdzono i ile awarii przeszło niezauważonych.
6. Tydzień ósmy: decyzja o rozszerzeniu. Jeśli na jednej maszynie i jednym trybie awarii nie wyszło, na dwudziestu nie wyjdzie tym bardziej. Jeśli wyszło — drugi tryb awarii na tej samej maszynie jest tańszy niż pierwszy tryb na nowej.

Co podpisujecie z dostawcą

Dwie rzeczy w tej umowie bywają rozstrzygane dopiero w momencie, gdy stają się problemem. Pierwsza to własność danych pomiarowych: kto ma do nich dostęp po zakończeniu współpracy i czy dostawca może ich użyć do budowania modeli dla innych klientów, w tym Waszej konkurencji. Druga to los modelu po wymianie maszyny albo zmianie profilu produkcji — czy ponowne nauczenie jest w cenie utrzymania, czy jest nowym projektem.

Warto też zapisać, czego system nie robi. Alarm z systemu predykcyjnego nie jest decyzją o zatrzymaniu maszyny i nie zdejmuje odpowiedzialności z osoby, która tę decyzję podejmuje — w szczególności w obszarach, gdzie w grę wchodzi bezpieczeństwo pracy i przepisy dozorowe. Granice odpowiedzialności, poziomy wsparcia i scenariusz wyjścia rozpisaliśmy w tekście o umowie z dostawcą AI.

Od czego zacząć

Jeden konkret na ten tydzień, bez czujników i bez budżetu: wypiszcie wszystkie nieplanowane przestoje z ostatnich dwóch lat i przy każdym dopiszcie jedno zdanie od utrzymania ruchu — czy dało się to zauważyć wcześniej i po czym. Dwa dni pracy, w większości rozmowy, nie analiza. Z tej jednej tabeli wyjdą trzy rzeczy: które maszyny naprawdę kosztują, jaka część awarii jest w zasięgu jakiegokolwiek pomiaru i czy macie dane do uczenia modelu. Firmy, które to robią, zwykle odkrywają, że połowa kosztu przestojów siedzi na dwóch maszynach, a jedna trzecia awarii nie ma nic wspólnego z techniką.

Takie projekty prowadzimy od tej strony: najpierw inwentaryzacja awarii i koszt przestoju, potem jedna maszyna i jeden tryb awarii, próg bazowy przed modelem, obowiązkowe zamykanie zgłoszeń i decyzja o rozszerzeniu podjęta na danych z ośmiu tygodni. Jeśli macie halę, w której nieplanowane przestoje są realnym kosztem, a historia awarii leży w zleceniach serwisowych i w pamięci dwóch osób, umówcie bezpłatną konsultację albo zobaczcie, jak wygląda nasz konsulting i wdrożenia AI.