Prawie każda polska strona o predykcyjnym utrzymaniu ruchu tłumaczy, czym ono jest. Prawie żadna nie odpowiada na pytanie praktyczne: czy ten konkretny zakład ma dziś z czego przewidywać awarie. Odpowiedź nie zależy od tego, jaki model ktoś Wam zaproponuje, tylko od tego, co leży w Waszym systemie zgłoszeń i w systemie sterowania.
Definicja w dwóch zdaniach. Prognostyka jest przewidywaniem tego, co dopiero ma nadejść, a ocena stanu maszyny na dziś nazywa się w normach diagnostyką (NIST, raport NISTIR 8012 z 2014 r., odczytany 8 września 2026 r.). Po polsku na tę pierwszą rzecz mówi się predykcyjne utrzymanie ruchu albo konserwacja predykcyjna.
Że liczy się historia, nie jest odkryciem — ASTOR pisze, że „fundamentem skutecznej predykcji jest dobrze funkcjonująca prewencja” (17 marca 2025 r.) i że bez historii awarii, przeglądów i napraw AI „będzie jedynie zgadywać” (tekst o AI w utrzymaniu ruchu, 21 lipca 2026 r.; obie strony odczytane 8 września 2026 r.). Ten tekst zaczyna się tam, gdzie tamte się kończą: przy dwóch plikach, które trzeba złożyć w jeden.
Uczciwie o tym, skąd to piszemy: nie sprzedajemy modeli predykcyjnych. Robimy rejestry awarii, asystentów nad dokumentacją techniczną i historią napraw oraz audyty danych — rzeczy sprzed predykcji, a często zamiast niej. Jeżeli test wypadnie u Was na „nie”, nie mamy Wam w miejsce modelu nic poza projektem, który tę historię dopiero zbuduje.
Test w jedno popołudnie: dwa eksporty za ten sam okres
Cały test sprowadza się do jednego polecenia: wyeksportujcie dwanaście miesięcy sygnałów i awarie z rejestru za ten sam okres — dla jednej maszyny, a jeżeli macie kilka identycznych, dla całej tej klasy. Ogólniejsza wersja — sto ostatnich przypadków dowolnego procesu jako jedna tabela — jest w Kroku 3 przewodnika po wdrażaniu AI. Przy maszynach sto przypadków zwykle nie istnieje, a trudność leży w złożeniu dwóch plików w jeden.
Dlaczego akurat tych dwóch, wynika z normy. Prognoza — w rozumieniu ISO 13381-1 z 2015 r. — stoi na znajomości spodziewanych postaci uszkodzenia i obciążeń maszyny; norma dodaje, że może do tego być potrzebne to, co nazywa „run-to-failure data”: zapisy przebiegów zakończonych awarią (odczytane 8 września 2026 r.; wydanie zastąpione w 2025 r.). Architektura referencyjna Microsoftu (Predictive Maintenance Architecture With Real-Time Intelligence, learn.microsoft.com, 12 lutego 2026 r.) wskazuje te same źródła po nazwie: CMMS oraz sterowniki PLC i systemy SCADA.
Pięć pytań, które rozstrzygają, czy predykcyjne utrzymanie ruchu jest u Was wykonalne
1. Czy istnieje rejestr awarii — i czy da się z niego zrobić tabelę?
„Tak” brzmi tylko wtedy, gdy ktoś potrafi w kwadrans wyprodukować plik, w którym jeden wiersz to jedna awaria. Pytać należy kierownika utrzymania ruchu; dowodem jest eksport z CMMS-a albo arkusza z identyfikatorem maszyny, momentem wystąpienia i momentem zakończenia.
„Nie” wygląda zwykle tak: rejestr jest zeszytem na warsztacie albo siedzi w systemie, tylko pole opisu usterki to wolny tekst i połowa wpisów brzmi „awaria”. Wolne pole nie dyskwalifikuje rejestru, tylko przesuwa pracę: ktoś musi te opisy sprowadzić do skończonej liczby postaci uszkodzenia. To praca do wykonania raz, nie przeszkoda nie do przejścia.
2. Czy zdarzenia mają znaczniki czasu, którym można ufać?
„Tak” znaczy: w rejestrze jest moment wystąpienia awarii, a nie moment, w którym ktoś ją zauważył albo wpisał do systemu. Pytać należy tego, kto administruje CMMS-em; dowodem jest kolumna z godziną zdarzenia — jeżeli wszystkie wartości w niej pokrywają się z początkami zmian, to w rejestrze jest godzina zmiany, nie godzina awarii.
Nie jest to przytyk do polskich zakładów. Problem opisuje inżynier Microsoftu, John Ehrlinger, w archiwalnym poradniku Care and Feeding of Predictive Maintenance Solutions: awarię często odnotowuje się dopiero podczas wizyty serwisowej, co utrudnia ustalenie, kiedy naprawdę wystąpiła (learn.microsoft.com, 23 stycznia 2018 r., odczytany 8 września 2026 r.). Ten sam poradnik dodaje, że zapisy przeglądów pozwalają wnioskować, iż maszyna wtedy działała poprawnie.
3. Czy da się wyeksportować sygnały — na poziomie maszyny, nie linii?
„Tak” znaczy: istnieje plik z historią pomiarów tej jednej maszyny, z datą i godziną przy każdej wartości. Pytać należy automatyka albo dostawcę SCADA: czy te wartości są gdzieś archiwizowane i za jaki okres wstecz. Do tej odpowiedzi dochodzi jeszcze jeden warunek: archiwum musi zawierać parametr, który niesie objaw postaci uszkodzenia wybranej w pytaniu pierwszym, próbkowany dość gęsto, żeby ten objaw było widać — archiwum złego parametru albo jedna wartość na zmianę to „nie” w przebraniu „tak”.
„Nie” ma trzy postacie. Sterownik zna bieżącą wartość, ale nikt jej nie zapisuje — PLC nie jest historianem. SCADA archiwizuje, lecz raportuje na poziomie linii, więc przebiegu nie przypiszecie do maszyny, która stanęła. Brama czujnikowa nadpisuje starsze pomiary — jak dawno wstecz sięga, jest pierwszą rzeczą, o którą trzeba zapytać jej dostawcę.
Zanim ktokolwiek zacznie mówić o zakupach, warto zrobić to, co ISO 17359:2018 zaleca w §8.3: sprawdzić, czy interesujące nas parametry mierzą już istniejące systemy nadzoru lub sterowania. AndonCloud pisze to samo po polsku — predykcyjne utrzymanie ruchu „nie zawsze musi zaczynać się od drogich czujników IoT” — i wskazuje statusy stanowisk, wskaźniki OEE i czasy awarii (strona bez daty publikacji, odczytana 8 września 2026 r.).
4. Czy jedno i drugie łączy ten sam identyfikator maszyny?
„Tak” znaczy: identyfikator maszyny z rejestru występuje w eksporcie sygnałów w tej samej postaci, bez tłumaczenia w niczyjej głowie. Model nie uczy się z rejestru ani z sygnałów osobno — uczy się z połączenia. Wśród siedemnastu polskich stron, które przeczytaliśmy przy pisaniu tego tekstu, tego pytania nie zadaje żadna, a waży ono w projekcie więcej niż wybór algorytmu.
| Co model musi złożyć w jedną parę | Skąd to pochodzi |
|---|---|
| Zdarzenie: identyfikator maszyny, moment wystąpienia, postać uszkodzenia | rejestr awarii — CMMS, arkusz, system zgłoszeń |
| Okno sygnałów bezpośrednio poprzedzające ten moment | historian, SCADA, brama czujnikowa, sterownik z archiwizacją |
Zestawienie ilustracyjne, bez danych rzeczywistych: para powstaje albo nie powstaje na poziomie pojedynczej maszyny.
Cztery rzeczy rozbijają to połączenie i wszystkie zobaczycie w kwadrans po otwarciu obu plików.
- Brak wspólnego identyfikatora. Rejestr używa numerów inwentarzowych, historian nazw tagów, a tabeli łączącej jedno z drugim nie ma. ISO 17359:2018 zaleca w §8.8 jednoznaczną identyfikację punktów pomiarowych i rekomenduje trwałe oznaczenie.
- Zbyt zgrubny albo cudzy znacznik czasu. Godzina początku zmiany zamiast godziny zdarzenia; czas z zegara innego niż ten, którym stemplowane są sygnały.
- Data wizyty zamiast daty awarii. Psuje konkretnie okno oznaczone jako „przed awarią”.
- Zmiana obciążenia wzięta za usterkę. Norma zaznacza w §8.4, że zmianę parametru wywołaną usterką trzeba umieć odróżnić od tej wywołanej zmianą warunków pracy — bez informacji, co maszyna wtedy robiła, przezbrojenie wygląda w danych jak początek awarii.
Tak to wygląda w praktyce. Zakład na sto dwadzieścia osób, CMMS z 2022 r., SCADA raportująca na poziomie linii; wszyscy pewni, że dane do predykcji są, bo rejestr miał trzy lata wpisów. Projekt zatrzymało pytanie czwarte: CMMS operował numerami inwentarzowymi, SCADA nazwami tagów, a mapowania nie było nigdzie poza pamięcią jednego automatyka.
Przykład złożony z kilku audytów, nie opis jednego klienta. Liczby są ilustracyjne i służą pokazaniu struktury, nie rynku.
5. Ile zdarzeń tego samego typu ma zapisanych ta klasa maszyn?
Liczba zdarzeń, nie liczba miesięcy — to jednostka, w której trzeba liczyć, i to ona odróżnia zakład gotowy od niegotowego przy równie długiej historii rejestru. Dowodem jest jedna liczba: ile razy ta konkretna postać uszkodzenia pojawia się w eksporcie z CMMS-a, o który poprosiliście w pytaniu pierwszym.
Powód jest metodyczny. Przewidywanie awarii z historii własnych maszyn jest uczeniem nadzorowanym: jak opisuje poradnik Microsoftu, dysponuje się pełną historią życia serii urządzeń i na tej podstawie charakteryzuje, jak zachowałyby się inne, niewidziane, ale przyjęte za identyczne. Flota dwudziestu takich samych pomp to dwadzieścia historii tego samego urządzenia; unikatowa prasa to jedna i żadnego urządzenia, na które można by wynik przenieść. Maszyny, które się nie zepsuły, też się liczą — ten sam poradnik zaleca użycie urządzeń z awariami i bez nich, bo dopiero razem pomagają odróżnić jedno zachowanie od drugiego.
Progu nie podamy, bo dla Waszej prasy żaden prawdziwy próg nie istnieje. Podamy jednostkę: liczba zapisanych zdarzeń tej postaci uszkodzenia w obrębie jednej klasy maszyn. Wśród przeczytanych przez nas stron te, które podają tu liczbę, podają czas — codescriptum, jedyna z własną checklistą gotowości zakładu, pyta o historię awarii „min. 12 miesięcy” (20 kwietnia 2026 r.), AndonCloud o „minimum rok” (bez daty publikacji); obie odczytane 8 września 2026 r. Obie liczby są rozsądnym przybliżeniem i obie mierzą nie to, co trzeba: miesiące są skutkiem, nie warunkiem — biorą się z tego, jak często psuje się dana maszyna.
W przykładzie z pytania czwartego najciekawsze okazało się właśnie to. Dla prasy, od której zaczęto rozmowę, interesująca postać uszkodzenia wystąpiła trzy razy w roku; dla dwunastu identycznych pomp, o których nikt nie myślał, bo „rzadko się psują” — kilkadziesiąt. Maszyna, od której zaczyna się rozmowa, rzadko jest tą, od której warto zacząć projekt.
Alarm progowy, wykrywanie anomalii i przewidywanie awarii to trzy różne rzeczy
Alarm progowy to reguła, którą ktoś wpisał. Wartość progu wyznacza się z norm, wytycznych producenta i doświadczenia, a progi ostrzegawcze ustawia poniżej progu awaryjnego — tak opisuje to NIST, referując ISO 13381-1 (NISTIR 8012 z 2014 r., odczytany 8 września 2026 r.). Historii awarii ten mechanizm nie potrzebuje, bo niczego się nie uczy.
Wykrywanie anomalii buduje model normy z samych sygnałów i alarmuje, gdy przebieg z niego wypada — bez ani jednej zapisanej awarii. Microsoft opisuje je jako typowe podejście tam, gdzie zakład działa reaktywnie, i pisze, że potrafi być dokładniejsze od prostych reguł progowych (ten sam poradnik archiwalny). Czyli: rzecz warta kupienia właśnie tam, gdzie predykcji się jeszcze nie robi.
Przewidywanie awarii wymaga par: zdarzenie i okno sygnałów, które je poprzedzało. Jest metodą nadzorowaną, więc etykiety muszą skądś pochodzić — a w zakładzie, który przewiduje awarie własnych maszyn, tym źródłem jest rejestr awarii.
Stąd sprostowanie najczęstszej obietnicy na rynku. Staleo prowadzi czytelnika przez model wdrożenia, w którym „zbieranie danych” zajmuje „kilka tygodni”, i podaje „redukcję przestojów o 20–40%” bez wskazania badania czy źródła (15 maja 2026 r., odczytane 8 września 2026 r.). Kilka tygodni danych z czujników kupuje wykrywanie anomalii; przewidywania awarii nie kupuje. Własnych procentów nie podajemy, bo nie mamy ich skąd wziąć — podajemy to, co sprawdzicie sami: że strona, która je podaje, źródła nie podaje.
Samo rozróżnienie istnieje zresztą już po polsku: Signalo pisze, że „monitoring nie jest jeszcze predykcją”, a ASTOR robi to samo językiem automatyka, na przykładzie wykresu temperatury (Poradnik Automatyka, 5 września 2023 r.; obie strony odczytane 8 września 2026 r.). Brakuje w nich jednego zdania: monitoring stanu nie potrzebuje rejestru awarii, a predykcja uczona na Waszych maszynach bez niego nie istnieje. Stąd test na samą ofertę — jeżeli nikt nie pyta, ile awarii danego typu macie zapisanych, to jest oferta na projekt zbierania danych wyceniony jak projekt predykcji; piszemy o tym przy AI w produkcji.
Cztery możliwe wyniki testu i pierwszy projekt dla każdego
Test kończy się w jednym z czterech miejsc, a każde z nich ma inny pierwszy projekt — i inną rzecz, której w tym kwartale nie warto kupować.
| Rejestr i sygnały, powiązane | Rejestr bez sygnałów | Sygnały bez rejestru | Ani jedno, ani drugie | |
|---|---|---|---|---|
| Pierwszy projekt | pilotaż na jednej klasie maszyn i jednej postaci uszkodzenia, jeżeli piąte pytanie daje dość zdarzeń tej postaci | koszt awarii tej maszyny, potem decyzja o oprzyrządowaniu | rejestr awarii, a na istniejących sygnałach wykrywanie anomalii | rejestr awarii i asystent nad dokumentacją |
| Co można uczciwie obiecać | ostrzeżenie dla jednej postaci uszkodzenia, z określonym wyprzedzeniem | podstawę decyzji inwestycyjnej, nie prognozę | sygnał, że maszyna zachowuje się inaczej niż zwykle — bez nazwy usterki | krótszy czas dojścia do przyczyny i historię na przyszłość |
| Czego nie kupować w tym kwartale | rozszerzenia na cały park maszynowy | czujników przed policzeniem kosztu awarii | modelu predykcyjnego — nie ma etykiet, z których mógłby się uczyć | modelu — nie ma na czym go uczyć |
Tabela decyzyjna, nie wycena. Kosztów nie zawiera celowo.
Rejestr i sygnały są, i da się je połączyć
Ta kolumna zakłada, że piąte pytanie dało liczbę, z której da się uczyć. Jeżeli powiązanie działa, ale danej postaci uszkodzenia jest w rejestrze zaledwie kilka zdarzeń, zakład jeszcze tu nie należy: idzie tą samą drogą, co zakład z sygnałami bez rejestru — rejestr zbiera dalej zdarzenia tej postaci, w międzyczasie warto sprawdzić, czy wykrywanie anomalii na już archiwizowanych sygnałach daje technikom cokolwiek użytecznego, a do piątego pytania wraca się w dacie przeglądu wyznaczonej dziś.
Pierwsza decyzja dotyczy nie modelu, tylko maszyny. ISO 17359:2018 zaleca w §7.2 ocenę krytyczności wszystkich maszyn — po dziewięciu czynnikach, wśród nich koszcie przestoju, częstości awarii i wpływie na bezpieczeństwo — żeby powstała lista maszyn objętych monitorowaniem „(or not)”, czyli świadomie także niewłączonych. Ten nawias jest najbardziej użyteczną rzeczą w całej normie: wykluczenie maszyny jest normalnym wynikiem analizy, nie porażką.
Druga decyzja dotyczy postaci uszkodzenia i ma tę samą kolejność — §7.3 zaleca analizę FMEA lub FMECA, żeby najpierw zidentyfikować spodziewane usterki i objawy, a dopiero potem parametry warte mierzenia. Signalo streszcza to jednym zdaniem: „Najpierw failure mode, potem sensor” (odczytane 8 września 2026 r.).
Zakres pierwszego projektu AI — u nas i u każdego innego wykonawcy — opisaliśmy przy wdrożeniu AI w firmie, a podział na fazy w metodyce wdrożenia. Pięć pytań do dostawcy, który taki pilotaż poprowadzi:
- Którą postać uszkodzenia model ma przewidywać? Odpowiedź „awarie” nie jest odpowiedzią.
- Ile zdarzeń tej postaci jest w naszym rejestrze — i czy widzieliście ten eksport?
- Z jakim wyprzedzeniem ma ostrzegać? Czas między wykryciem usterki a awarią ISO 17359:2018 nazywa w §8.5 lead time to failure i zaznacza, że wpływa on szczególnie na częstotliwość pomiarów i rodzaj systemu monitorowania.
- Metoda nadzorowana czy nienadzorowana? Czyli: przewidywanie awarii czy wykrywanie anomalii.
- Co się stanie z modelem w drugim roku? Zwraca na to uwagę sam Microsoft: gdyby model był doskonały, usunąłby z populacji zdarzenia awarii — a skoro to na nich uczy się metoda nadzorowana, ponowne uczenie takiego rozwiązania model pogarsza.
W tym samym poradniku wynik modelu albo uruchamia zlecenie utrzymania ruchu, albo trafia do eksperta — „human in the loop” — który decyduje, gdzie skierować ograniczone zasoby. Która z tych dróg obowiązuje u Was, jest decyzją do podjęcia przed pilotażem, nie po nim.
Jest rejestr, nie ma sygnałów
Decyzja brzmi: policzyć koszt awarii tej maszyny, zanim ktokolwiek wybierze czujnik. ISO 17359:2018 stawia w §5 analizę wykonalności i korzyści przed wyborem metody monitorowania, a do rozważenia wymienia koszt cyklu życia, koszt utraconej produkcji, szkody wtórne oraz gwarancje i ubezpieczenie. Te cztery pozycje policzone dla jednej maszyny znaczą więcej niż dowolna prezentacja.
Koszt po drugiej stronie da się nazwać bez widełek: liczba maszyn objętych pomiarem, to, czy archiwizację wystarczy skonfigurować w istniejących sterownikach i SCADA, czy budować od zera, oraz to, czy w zakładzie w ogóle jest CMMS. Dopóki te trzy rzeczy nie są rozstrzygnięte, liczba w ofercie nie jest wyceną — rozkład kosztów opisaliśmy w tekście o tym, ile kosztuje wdrożenie AI.
Są sygnały, nie ma rejestru
Ten wynik wygląda najbardziej obiecująco i najłatwiej go przecenić. Archiwum pomiarów bez rejestru awarii nie daje etykiet, a bez etykiet nie ma uczenia nadzorowanego — czyli nie ma przewidywania awarii uczonego na tych maszynach. Daje natomiast to, co daje każde archiwum sygnałów: wykrywanie anomalii, opisane wyżej, uczy się z samych sygnałów.
Pierwszy projekt jest więc podwójny. Rejestr — ten sam, którego pola wymieniamy niżej — zaczyna od jutra zbierać etykiety. Równolegle warto sprawdzić, czy wykrywanie anomalii na sygnałach, które już archiwizujecie, daje technikom coś użytecznego; wszędzie tam, gdzie sygnały są archiwizowane, to jedyna rzecz, która działa bez czekania na historię. Do pytania piątego wracacie z liczbą zdarzeń zamiast domysłu — kiedy nowy rejestr ma już zdarzenia tej postaci uszkodzenia do policzenia albo w wyznaczonym dziś dniu przeglądu, zależnie od tego, co nastąpi wcześniej.
Nie ma ani rejestru, ani sygnałów
To najczęstsza odpowiedź i najmniej dramatyczna, bo daje projekt wykonalny od jutra. Rejestr, który warto założyć, ma siedem pól:
- identyfikator maszyny — ten sam, którego używa automatyka, nie osobny;
- moment wystąpienia i moment zakończenia — dwie kolumny, obie z godziną;
- zaobserwowany objaw — z listy, nie z klawiatury;
- stwierdzona przyczyna — również z listy, uzupełnianej po pierwszym kwartale;
- wymieniona część;
- czas postoju.
Lista opracowana na podstawie ISO 17359:2018 §8.7 (minimalna zawartość zapisu monitorowanych parametrów) — nie jest cytatem z normy. Norma odczytana 8 września 2026 r. Sam formularz raportu awarii nie jest w polskim piśmiennictwie nowością; nowe jest to, po co się go wypełnia — każde z tych pól jest kolumną, na której kiedyś uczy się model.
Drugą połowę tego projektu opisujemy przy wdrożeniach AI w firmie produkcyjnej: asystent nad dokumentacją techniczno-ruchową i historią napraw. Działa on w obie strony — technik, który dostaje sensowną odpowiedź, chętniej zamyka zgłoszenie opisem niż słowem „naprawione”, a to właśnie tej treści rejestrowi brakuje.
Kiedy predykcyjne utrzymanie ruchu nie jest Waszym pierwszym problemem
Najczęstsza uczciwa odpowiedź na pytanie z tytułu brzmi „jeszcze nie” — i lepiej usłyszeć to od kogoś, kto nie ma Wam wtedy czego sprzedać w zamian.
- Postać uszkodzenia nie daje mierzalnego objawu. ISO 17359:2018 mówi wprost w §7.4: konieczne może być wtedy zastosowanie innej strategii — wypalania wstępnego, pracy do awarii, utrzymania korekcyjnego, prewencyjnego albo przekonstruowania. Praca do awarii jest w normie strategią, nie zaniedbaniem.
- Prewencja nie działa. Przy nieuporządkowanych przeglądach dane też są nieuporządkowane, więc model dostaje z nich nie wzorzec, tylko szum — to teza ASTOR-a, cytowana na wstępie.
- Maszyna jest jedyna w swoim rodzaju i psuje się rzadko. Brzmi jak zła wiadomość, a jest dobra: pieniądze, które poszłyby na model, zostają na części zamienne i na przegląd.
- Nikt nie weźmie na siebie decyzji na podstawie ostrzeżenia. Nawet po wykryciu usterki oszacowanie czasu do awarii wymaga opinii eksperta albo metod empirycznych (NISTIR 8012 z 2014 r.). Bez osoby, która zatrzyma maszynę i weźmie za to odpowiedzialność, model produkuje powiadomienia, a nie decyzje.
Predykcja bez historii danych jest na naszej liście rzeczy, których nie robimy. Ten tekst opisuje, jak się do tej odmowy dochodzi samodzielnie — zanim ktoś wystawi za nią fakturę.
Co zrobić w to popołudnie
- Wybierzcie jedną klasę identycznych maszyn, a jeżeli takiej nie ma — jedną maszynę. Nie najdroższą, tylko tę, przy której ktoś wymieni z pamięci postać uszkodzenia, która wraca.
- Zamówcie dwa eksporty za te same dwanaście miesięcy: zgłoszenia dla wybranych maszyn u kierownika utrzymania ruchu, historię ich sygnałów u automatyka albo dostawcy SCADA — na poziomie maszyny, nie linii, z identyfikatorem maszyny przy każdym zdarzeniu i przy każdym pomiarze.
- Otwórzcie oba pliki obok siebie i sprawdźcie dwie rzeczy: czy identyfikator z pierwszego występuje w drugim w tej samej postaci, i ile razy wystąpiła ta jedna postać uszkodzenia.
Wtedy wiecie — z plików, nie z deklaracji — w której kolumnie tabeli z wynikami testu stoi Wasz zakład. Jeżeli chcecie, żeby ktoś przeszedł przez te dwa pliki razem z Wami, robimy to; również wtedy, gdy wynikiem jest „jeszcze nie warto”. To też jest wynik, tylko tańszy niż ten sam wniosek po zakupie czujników.