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.
Najpierw o tym, skąd to piszemy: w ploch.ai budujemy rejestry awarii, asystentów nad dokumentacją techniczną i historią napraw oraz audyty danych — fundament, bez którego predykcja nie działa, a który często sam rozwiązuje problem. Jeżeli test wypadnie u Was na „nie”, zaczynamy od projektu, który tę historię 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, czyli program do zarządzania utrzymaniem ruchu, oraz sterowniki maszyn (PLC) i systemy nadzoru produkcji (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 data scientist 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ć pomiar, w którym widać objaw postaci uszkodzenia wybranej w pytaniu pierwszym, zapisywany na tyle często, żeby ten objaw było widać. Archiwum niewłaściwego pomiaru albo jedna wartość na zmianę to „nie” udające „tak”.
„Nie” ma trzy postacie. Sterownik zna bieżącą wartość, ale w tym przypadku nikt nie zapisuje historii pomiarów — sam sterownik PLC nie zastępuje programu do archiwizacji pomiarów (tak zwanego historiana). SCADA archiwizuje, lecz raportuje na poziomie linii, więc przebiegu nie przypiszecie do maszyny, która stanęła. Urządzenie zbierające dane z czujników (brama czujnikowa) nadpisuje starsze pomiary — o to, jak daleko wstecz sięga zapisana w nim historia, trzeba najpierw zapytać 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ń |
| Pomiary z okresu tuż przed tym momentem | 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, archiwum pomiarów — nazw punktów pomiarowych (tak zwanych 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 innego zegara niż ten, który zapisuje godzinę przy pomiarach.
- 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 awarii tego samego rodzaju zapisaliście dla tej klasy 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.
Wynika to ze sposobu, w jaki model się uczy. Przewidywanie awarii z historii własnych maszyn to uczenie nadzorowane, czyli uczenie na przykładach z zapisanym wynikiem. Jak opisuje poradnik Microsoftu, bierze się pełną historię życia serii urządzeń i na tej podstawie opisuje, jak zachowałyby się inne, których model nie widział, ale które uznaje się 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 w wydaniu z 2004 r. (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, czyli zapisy, że w danym momencie wystąpiła awaria danego typu, 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. Zamiast procentów 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 inny zakup, z którym lepiej poczekać do kolejnego etapu.
| 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ą |
| Czego można oczekiwać | 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ę zdarzeń, z której da się uczyć. Jeżeli powiązanie działa, ale w rejestrze jest tylko kilka zdarzeń danej postaci uszkodzenia, zakład jeszcze tu nie należy. Idzie wtedy tą samą drogą, co zakład z sygnałami bez rejestru: rejestr dalej zbiera zdarzenia tej postaci, a w międzyczasie warto sprawdzić, czy wykrywanie anomalii na już archiwizowanych sygnałach daje technikom cokolwiek użytecznego. 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 (analizę możliwych uszkodzeń i ich skutków), ż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.), czyli najpierw postać uszkodzenia, potem czujnik.
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, awarie, którym zapobiega, przestałyby się zdarzać — a to właśnie na nich model się uczy. W takim przypadku ponowne uczenie na danych bez tych zdarzeń pogarszałoby model.
W tym samym poradniku wynik modelu albo uruchamia zlecenie utrzymania ruchu, albo trafia do eksperta, który na tej podstawie decyduje, gdzie skierować ograniczone zasoby. W tej drugiej drodze decyzję podejmuje człowiek na podstawie wyniku modelu (human in the loop). 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 odpowiedź na pytanie z tytułu brzmi: najpierw historia danych. W tych sytuacjach lepszym punktem startu jest inny krok:
- Postać uszkodzenia nie daje mierzalnego objawu. ISO 17359:2018 mówi wprost w §7.4: konieczne może być wtedy zastosowanie innej strategii — burn-in (próbnej pracy urządzenia przed oddaniem do użytku, która ma ujawnić wczesne usterki), 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.
Predykcję budujemy wyłącznie na historii danych — to jedna z zasad opisanych na stronie nasze standardy. Ten tekst pokazuje, jak samodzielnie sprawdzić, czy Wasza historia już na to pozwala — zanim ktoś wystawi 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, w ploch.ai przejrzymy te dwa pliki razem z Wami i powiemy, od którego kroku zacząć — zanim kupicie czujniki.
Źródła i stan na 9 października 2026 roku
- NIST, NISTIR 8012 „Standards Related to Prognostics and Health Management (PHM) for Manufacturing” (2014) — diagnostyka a prognostyka, progi ostrzegawcze, szacowanie czasu do awarii; odczyt 9 października 2026 r.
- ISO 17359:2018 — wytyczne programu monitorowania stanu maszyn (karta katalogowa); odczyt 9 października 2026 r.
- ISO 13381-1:2025 i wycofane wydanie z 2015 r. — prognozowanie stanu maszyn (karty katalogowe); odczyt 9 października 2026 r.
- Microsoft Learn (archiwum), J. Ehrlinger, „Care and Feeding of Predictive Maintenance Solutions” (2018) — uczenie nadzorowane, liczba zdarzeń na cechę, wykrywanie anomalii; odczyt 9 października 2026 r.
- Microsoft Learn, „Predictive Maintenance Architecture With Real-Time Intelligence” — CMMS, PLC i SCADA jako źródła danych; odczyt 9 października 2026 r.
- ASTOR, „Predykcja zaczyna się od prewencji”, „AI w utrzymaniu ruchu” i „Analiza predykcyjna: jak skutecznie zapobiegać awariom?”; odczyt 9 października 2026 r.
- AndonCloud, „Strategie utrzymania ruchu: reaktywne, prewencyjne, predykcyjne”; odczyt 9 października 2026 r.
- codescriptum, „Automatyzacja produkcji z AI — od czego zacząć i ile kosztuje w 2026”; odczyt 9 października 2026 r.
- Staleo, „Jak wdrożyć predykcyjne utrzymanie ruchu?”; odczyt 9 października 2026 r.
- Signalo, „Predykcyjne utrzymanie ruchu – jak działa i kiedy ma sens”; odczyt 9 października 2026 r.