Po co w ogóle wykrywać anomalie na liniach produkcyjnych?
Czym jest anomalia w realnej produkcji
Anomalia na linii produkcyjnej to każde zachowanie procesu, maszyny lub operatora, które odbiega od normalnego wzorca pracy. Nie zawsze oznacza to od razu awarię – często są to drobne odchylenia, które same w sobie nie zatrzymają produkcji, ale zwiększają ryzyko defektów, mikroprzestojów lub przyspieszonego zużycia sprzętu.
W praktyce anomalia może oznaczać na przykład:
nienaturalny wzrost wibracji łożyska przy tej samej prędkości silnika,
nagłe wahania temperatury w komorze grzewczej mimo stałych nastaw,
serię krótkich zatrzymań przenośnika, które nie wywołują alarmu PLC, ale obniżają OEE,
inny niż zwykle rozkład jasności na kamerze wizyjnej, jeszcze bez widocznej wady,
nietypową sekwencję działań operatora przy przezbrojeniu maszyny.
Kluczowe jest to, że anomalia to pojęcie względne: ta sama wartość temperatury może być normalna dla jednej receptury, a krytyczna dla innej. Dlatego skuteczne wykrywanie anomalii musi uwzględniać kontekst procesu, a nie tylko proste progi na pojedynczych sygnałach.
Cele biznesowe: jakość, OEE, bezpieczeństwo, koszty
Bez jasnych celów biznesowych projekt wykrywania anomalii szybko zamienia się w zabawkę dla działu R&D. Zwykle chodzi o jeden lub kilka z poniższych obszarów:
Jakość produktu – zmniejszenie odsetka braków, ograniczenie reklamacji, stabilność parametrów krytycznych (np. grubość powłoki, moment dokręcania, szczelność opakowań).
Bezpieczeństwo – wczesne wykrycie stanów potencjalnie niebezpiecznych (przegrzew, nadciśnienie, drgania przekraczające bezpieczny poziom) zanim klastry alarmów zaleją SCADA.
Koszty serwisu i części – przejście z „gaszenia pożarów” do kontrolowanej wymiany elementów na bazie rzeczywistego stanu, zamiast sztywnego kalendarza lub awarii.
Dobrze zdefiniowany cel pozwala później dobrać czujniki, modele oraz sposób integracji z automatyką. Bez tego trudno stwierdzić, czy projekt przyniósł realny zwrot inwestycji, czy jedynie kilka efektownych dashboardów.
Od diagnostyki reaktywnej do predykcyjnej
Większość zakładów działa w trybie reaktywnym: coś się dzieje (alarm, awaria, braki jakościowe), a zespół reaguje. Następny krok to diagnostyka proaktywna – gdy monitoring stanu maszyn oraz analiza trendów pozwalają wcześniej zauważyć nadchodzący problem.
Wykrywanie anomalii, szczególnie z użyciem modeli uczenia maszynowego, umożliwia przejście w stronę predykcyjnej diagnostyki. System nie tylko rejestruje alarm, ale potrafi wskazać:
„to zachowanie silnika nie było dotąd obserwowane w normalnych warunkach pracy”,
„rozkład parametrów procesu powoli dryfuje i zbliża się do obszaru, gdzie rosła liczba braków”.
Ta zmiana ma konsekwencje organizacyjne: trzeba ustalić, jak reagować na wczesne ostrzeżenia, kto decyduje o zatrzymaniu linii i jak unikać „paraliżu decyzyjnego” przy nadmiarze sygnałów ostrzegawczych.
Progi i alarmy kontra systemy AI
Klasyczny monitoring opiera się na prostych zasadach: jeśli temperatura > X lub ciśnienie < Y, generuj alarm. Takie reguły są czytelne i łatwe do wdrożenia w PLC czy SCADA, ale mają oczywiste ograniczenia:
nie łapią subtelnych zmian w kształcie sygnału (np. zmiana charakteru drgań przy tej samej amplitudzie),
ignorują zależności między parametrami (np. zależność temperatury od prędkości),
są statyczne – trudno je dostosować do zmian procesu, materiału, receptur.
Systemy oparte na AI starają się modelować „normalny” wzorzec zachowania całego procesu lub wybranego podsystemu, a następnie wykrywać odchylenia od tego wzorca. Dzięki temu mogą wykrywać anomalie:
przy braku jednoznacznych progów alarmowych,
w sytuacjach, gdzie awarie są rzadkie i trudno z góry spisać wszystkie reguły,
w danych wielowymiarowych (wiele czujników, wiele faz procesu).
Różnica nie polega więc na „magii AI”, tylko na tym, że modele uczą się zależności z danych, zamiast polegać wyłącznie na ręcznie ustawianych progach i regułach eksperckich.
Kiedy projekt ma sens ekonomiczny
Wykrywanie anomalii na liniach produkcyjnych ma sens, gdy:
koszt awarii, braku jakości lub przestoju jest istotny względem budżetu projektu,
awarie lub wady są na tyle złożone, że klasyczne progi i alarmy nie wystarczają,
dostępne są dane z linii lub można je rozsądnie pozyskać (czujniki, logi, wizja),
istnieje gotowość organizacyjna, by korzystać z sygnałów systemu (zmiana procedur serwisu, jakości, utrzymania ruchu).
Z kolei projekt bywa sztuką dla sztuki, gdy celem jest tylko „wdrożenie AI”, awarie są rzadkie i tanie, linia jest prosta, a dane biedne i niestabilne. W takich przypadkach często lepiej zainwestować w klasyczną automatykę, lepsze czujniki, szkolenie operatorów i porządny SPC niż w skomplikowane modele uczenia maszynowego.
Źródło: Pexels | Autor: Mark Stebnicki
Rodzaje anomalii na liniach produkcyjnych i jak je klasyfikować
Anomalie procesowe, jakościowe, sprzętowe i operatorskie
Żeby sensownie projektować system wykrywania anomalii w produkcji, trzeba uporządkować, czego tak naprawdę się szuka. W praktyce występują co najmniej cztery kategorie:
Anomalie procesowe – odchylenia parametrów procesu (temperatura, ciśnienie, przepływ, prędkości, momenty) od typowych przebiegów. Nie zawsze od razu powodują wadę, ale zwiększają jej prawdopodobieństwo.
Anomalie jakościowe – bezpośrednio dotyczą produktu: deformacje, rysy, nieszczelności, odbarwienia, nieprawidłowa masa, zły wymiar. Często wykrywane przez systemy wizyjne lub kontrolno-pomiarowe.
Anomalie sprzętowe – odnoszą się do stanu maszyn: wzrost wibracji, zmiany poboru prądu, nadmierne grzanie się łożysk, luzy mechaniczne, niestandardowe dźwięki.
Anomalie operatorskie – nietypowe działania człowieka: zmiany w sekwencji przezbrojeń, wydłużony czas określonych operacji, omijanie standardowych procedur.
Każda z tych kategorii wymaga innego podejścia. Przykładowo, anomalie jakościowe często wykrywa się na końcu linii (np. wizja maszynowa), natomiast anomalie sprzętowe – na poziomie monitoringu stanu maszyn. Dobrze zaprojektowany system łączy te perspektywy, aby nie tylko stwierdzić, że wada wystąpiła, ale także zidentyfikować, który element procesu zmienił zachowanie.
Anomalie punktowe, kontekstowe i sekwencyjne w danych czasowych
Dane z linii produkcyjnej są z natury danymi czasowymi. Sygnały z czujników mają strukturę sekwencji, więc typologia anomalii musi uwzględniać czas:
Anomalie kontekstowe – wartość sama w sobie nie jest „zła”, ale jest nietypowa w danym kontekście. Np. taka sama temperatura może być normalna przy wysokiej prędkości, a nietypowa przy niskiej.
Anomalie sekwencyjne – dotykają całego przebiegu w czasie, np. zmiana kształtu cyklu, wydłużenie się pewnej fazy, inny rozkład energii w widmie częstotliwości.
Modele i reguły, które świetnie radzą sobie z anomaliami punktowymi (progi, karty kontrolne), często zawodzą przy sekwencjach. Z kolei rozbudowane modele sekwencyjne (np. LSTM) bywają przerostem formy, gdy problem dotyczy prostych pików w danych. Dobranie metody do typu anomalii to jedna z kluczowych decyzji projektowych.
Odchylenie od standardu a błąd krytyczny
Statystyczna anomalia (wynik nietypowy względem historii) nie zawsze oznacza błąd krytyczny. Z punktu widzenia biznesu liczy się próg istotności. Inaczej traktuje się:
niewielką zmianę trendu wibracji łożyska, która może sygnalizować awarię za tygodnie,
gwałtowny spadek ciśnienia w układzie hydraulicznym, który za kilka sekund zatrzyma linię.
System wykrywania anomalii powinien odróżniać:
sygnały wczesnego ostrzegania – użyteczne do planowania przeglądów i korekt procesu,
stany krytyczne – wymagające natychmiastowej reakcji, często już dobrze opisane w klasycznych alarmach PLC.
Dlatego same modele statystyczne czy ML nie wystarczą – potrzebne jest zdefiniowanie logiki biznesowej, która określi, kiedy anomalia generuje rekomendację działania, a kiedy tylko wzbogaca wiedzę o stanie linii.
Dlaczego próba opisania wszystkich awarii z góry jest złudzeniem
Naturalnym odruchem przy wdrażaniu systemu detekcji anomalii jest chęć spisania pełnej listy awarii i scenariuszy. Taka lista pomaga, ale ma poważne ograniczenia:
w praktyce nigdy nie obejmuje wszystkich scenariuszy – rzadkie, złożone awarie wymykają się sztywnym klasyfikacjom,
proces i sprzęt zmieniają się w czasie – pojawiają się nowe materiały, nowe receptury, modernizacje, co czyni pierwotny katalog niekompletnym,
zbyt szczegółowe modele regułowe prowadzą do nadmiaru false positive i szybkiego ich ignorowania.
Znacznie skuteczniejsze jest podejście, w którym:
w krytycznych obszarach definiuje się kilka kluczowych scenariuszy (np. przegrzew, niedosmarowanie, rozcentrowanie),
resztę pozostawia się modelom uczącym się „normalnego” zachowania i sygnalizującym odchylenia, które potem inżynierowie klasyfikują i opisują.
Taki układ pozwala ewoluować system wykrywania anomalii wraz z procesem, zamiast próbować jednorazowo „zamrozić” całą wiedzę o awariach.
Przykład: linia pakująca – prędkość taśmy a defekt etykiety
Na prostej linii pakującej mogą wystąpić dwa na pozór niezależne problemy:
niewielkie fluktuacje prędkości taśmy transportowej,
wady etykiet: krzywo naklejone, pofałdowane, częściowo odklejone.
Klasyczny system może mieć osobne alarmy: jeden na prędkość taśmy (np. gdy spadnie poniżej określonego progu), drugi wizyjny – gdy liczba wadliwych etykiet przekroczy threshold. System wykrywania anomalii patrzy inaczej:
uczy się typowego profilu prędkości taśmy przy prawidłowym znakowaniu,
uczy się typowego rozkładu pozycji etykiet na obrazach z kamer przy danej prędkości,
wykrywa sekwencyjne anomalie, gdy wzorzec ruchu i rozkład etykiet zaczynają odbiegać od normalnego stanu, zanim liczba braków przekroczy twardy próg.
W praktyce można wychwycić np. zużycie rolek prowadzących lub pogarszające się warunki klejenia (temperatura, wilgotność) wcześniej, niż zauważą to sami operatorzy. Warunkiem jest jednak dobre spięcie danych z prędkości, systemu wizyjnego i informacji o jakości.
Dane i czujniki – fundament, który najczęściej jest ignorowany
Jakie dane są zwykle dostępne w fabryce
Większość zakładów ma już sporą ilość danych, chociaż często rozproszonych w różnych systemach. Typowe źródła to:
SCADA – historyczne przebiegi parametrów, alarmy, trendy, często z archiwizacją w bazie danych,
MES – dane o zleceniach, partiach, recepturach, statusach produkcyjnych, przestojach,
Systemy jakości / laboratoryjne – wyniki pomiarów offline, testów, kontroli końcowej,
Źródła danych, o których zwykle się zapomina
Poza klasycznymi systemami sterowania istnieje kilka nieoczywistych źródeł informacji, które potrafią przesądzić o skuteczności systemu wykrywania anomalii:
Dane serwisowe i utrzymaniowe – historię napraw, wymian części, regulacji można zgrać z danymi z czujników. Bez tego trudno zweryfikować, czy sygnały „przed awarią” rzeczywiście coś zapowiadały.
Logi maszyn i sterowników – komunikaty błędów, restarty, zmiany parametrów serwisowych. Często są kompletnie ignorowane, a bywają kluczem do zrozumienia „dziwnych” epizodów w danych.
Systemy wizyjne – nie tylko wynik OK/NOK, ale także surowe obrazy lub cechy wyekstrahowane z obrazu (np. odchyłka położenia, liczba defektów na powierzchni).
Dane operatorskie – zmiany nastaw, ręczne interwencje, komentarze w systemach zgłoszeniowych. Nie są czyste ani ustandaryzowane, ale często najlepiej tłumaczą anomalie w sygnałach.
Warunki otoczenia – temperatura hali, wilgotność, wibracje otoczenia, zmiany w zasilaniu. W wielu branżach „niewytłumaczalne” serie defektów są powiązane właśnie z tymi czynnikami.
Bez spięcia tych źródeł powstaje iluzja, że „dane z czujników nic nie mówią”. Same w sobie rzadko powiedzą wszystko – dopiero z korelacją z serwisem, recepturami, warunkami zewnętrznymi dają pełniejszy obraz.
Rozdzielczość czasowa – między „za rzadko” a „za gęsto”
Jednym z częstszych błędów jest niewłaściwy dobór częstotliwości próbkowania i archiwizacji. Skrajności są dwie:
logowanie co kilkanaście sekund lub minut, co kompletnie gubi dynamikę cyklu,
logowanie z częstotliwością kilkuset Hz, „bo czujnik tak wysyła”, bez realnej potrzeby i bez infrastruktury do przechowywania.
Rozsądny punkt leży zwykle gdzieś pośrodku i zależy od typu zjawiska: wolnozmienne trendy (np. temperatura medium) wymagają innego próbkowania niż drgania łożyska czy dźwięk. Zbyt rzadka rejestracja powoduje, że model widzi jedynie „wygładzoną” wersję procesu – anomalie krótkotrwałe, ale istotne, znikają. Zbyt gęsta kończy się tym, że nikt nie jest w stanie tych danych sensownie wykorzystać ani nawet poprawnie oznakować.
Dodatkowa pułapka: wiele systemów SCADA domyślnie stosuje logowanie „po zmianie” (change-based). Przy małej zmienności parametrów daje to złudzenie, że próbkowanie jest gęste, choć tak naprawdę między próbkami mogą mijać długie okresy, w których potencjalnie coś się działo, ale nie przebiło minimalnego progu zmiany.
Synchronizacja czasów – cichy zabójca projektów analitycznych
Łączenie danych z PLC, SCADA, MES, wizji i systemów jakości wymaga jednego, bardzo przyziemnego elementu: wspólnego, wiarygodnego czasu. Gdy:
każdy sterownik ma własny zegar,
kamery działają w innej strefie czasowej niż serwer SCADA,
MES zapisuje zdarzenia z opóźnieniem lub z zaokrągleniem
— powstaje chaos, który w praktyce uniemożliwia prawidłowe etykietowanie i łączenie sygnałów z konkretnym wyrobem czy cyklem. Na etapie koncepcji rzadko się o tym mówi; problem wychodzi dopiero wtedy, gdy trzeba odpowiedzieć na pozornie proste pytanie: „jak wyglądały przebiegi z czujników dla tych pięciu wadliwych sztuk?”.
Rozwiązania nie są skomplikowane technicznie (NTP, synchronizacja z nadrzędnym serwerem czasu, ujednolicenie stref czasowych), ale wymagają konsekwencji i współpracy automatyków, IT i dostawców maszyn. Bez tego każdy bardziej ambitny projekt detekcji anomalii będzie się rozbijał o drobiazgi.
Jakość danych – szum, braki, błędy kalibracji
Nawet przy dobrych czujnikach realne dane są dalekie od „książkowych”:
pojawiają się okresy martwe (brak rejestracji po restarcie systemu),
czujniki „pływają” po rozkalibrowaniu,
usterka instalacji (np. luźne złącze) imituje anomalie procesowe,
operacje ręczne (np. test serwisowy) mieszają się z normalną produkcją.
Algorytmy wykrywania anomalii będą reagować na wszystkie te zjawiska, jeśli ich nie odfiltrujemy lub przynajmniej nie oznaczymy. Z punktu widzenia modelu krótkotrwałe „odpięcie” czujnika bywa nieodróżnialne od realnego skoku parametru. Dlatego częścią projektu musi być zarządzanie jakością samych danych: procedury kalibracji, walidacja sygnałów, flagowanie okresów testowych i serwisowych.
Wybór czujników – nadmiar, niedomiar i złudzenia
Kiedy pojawia się temat „AI na linii”, odruchową reakcją jest propozycja dołożenia kolejnych czujników. Czasem jest to konieczne, ale typowe błędy to:
dokładanie nowych punktów pomiarowych tam, gdzie obecne sygnały procesowe już dobrze opisują zjawisko,
ignorowanie prostych, tanich pomiarów (np. temperatury otoczenia), które tłumaczą pozornie losowe odchyłki jakości,
ślepa wiara w „magiczne” sensory (np. jeden czujnik wibracji na całą linię ma rzekomo rozpoznawać wszystkie stany awaryjne).
Decyzja o dołożeniu czujników powinna wynikać z analizy luk informacyjnych: czego nie da się wywnioskować z istniejących sygnałów, a ma realny wpływ na awarie lub jakość. Często wystarczy poprawić istniejące pomiary (np. zwiększyć częstotliwość próbkowania, zmniejszyć histerezę, uszczelnić montaż) zamiast montować kolejne sensory.
Źródło: Pexels | Autor: Mark Stebnicki
Przygotowanie danych z linii – od „surowych bitów” do sensownych cech
Segmentacja procesu: cykle, partie, operacje
Dane procesowe przychodzą jako ciągły strumień, natomiast produkcja organizuje się wokół jednostek: sztuki, partii, cyklu maszyny. Pierwszym krokiem jest więc podział strumienia na logiczne segmenty. Robi się to na różne sposoby:
wykorzystując sygnał „start/stop cyklu” lub „część pod głowicą”,
opierając się na impulsach z enkodera taśmy,
łącząc znaczniki z systemu MES (ID zlecenia, ID partii) z czasem sygnałów.
Bez takiej segmentacji model często „widzi” mieszankę różnych stanów (np. rozruch, produkcja, czyszczenie, awaria) w jednym ciągu, co prowadzi do wypaczenia pojęcia „normalności”. Dodatkowo, segmentacja umożliwia powiązanie danych z wynikami jakości (OK/NOK dla danej sztuki lub partii), co jest kluczowe w fazie walidacji.
Oznaczanie stanów pracy – normalny, rozruch, postój, czyszczenie
Anomalie w fazie rozruchu czy po czyszczeniu mają inny sens niż w stabilnej produkcji. W wielu zakładach sygnały z różnych stanów są wrzucane do jednego worka. To prowadzi do dwóch skutków:
model uznaje „dziwne” przebiegi z rozruchu za część normalnego zachowania,
alarmuje w fazach, w których wahania są naturalne i nieszkodliwe.
Dobrym podejściem jest jawne oznaczanie trybów pracy na podstawie sygnałów sterujących (np. tryb AUTO/MANUAL), flag z PLC, sekwencji kroków, a w razie potrzeby – prostych reguł czasowych (np. pierwsze X cykli po starcie). Następnie tworzy się osobne modele normalności dla różnych stanów lub przynajmniej filtruje się okresy, w których reguły powinny być inne.
Czyszczenie i filtracja sygnałów
„Surowe” dane z hal produkcyjnych prawie nigdy nie nadają się wprost do modelowania. Zazwyczaj potrzebne są co najmniej:
usuwanie lub imputacja braków (z zachowaniem informacji, że brak wystąpił),
łagodna filtracja szumu (np. filtry średniej kroczącej, filtry cyfrowe),
normalizacja i skalowanie (szczególnie przy modelach uczących się),
detekcja i oznaczanie artefaktów technicznych (np. przesterowania, „przeskoki” wartości przy zmianie zakresu pomiarowego).
Nadmierne wygładzanie potrafi jednak wyciąć właśnie to, co chcemy wykrywać: krótkotrwałe, ale znaczące anomalie. Stąd filtrację trzeba dobierać pod kątem konkretnych zjawisk. W diagnostyce drgań korzysta się np. z innych filtrów niż w kontroli temperatury pieca.
Feature engineering: od prostych statystyk do cech dziedzinowych
Zamiast podawać modelowi całe surowe przebiegi, lepiej opisać segment (cykl, okno czasowe) zestawem cech. Najprostsze z nich to:
miary kształtu: skośność, kurtoza, liczba przekroczeń progów.
Dla zjawisk dynamicznych dochodzą bardziej zaawansowane cechy:
parametry z dziedziny częstotliwości (FFT, energia w wybranych pasmach),
czas trwania poszczególnych faz cyklu (np. czas napełniania, zgrzewania, chłodzenia),
relacje między sygnałami (opóźnienia, korelacje).
Najcenniejsze bywają cechy dziedzinowe zaproponowane przez inżynierów procesu: różnice temperatur w konkretnych punktach, stosunki ciśnień, wskaźniki jakości smarowania, stopnie obciążenia w poszczególnych krokach cyklu. To one często decydują, czy model będzie wykrywał sensowne odstępstwa, czy jedynie matematyczne ciekawostki.
Łączenie danych jakościowych z procesowymi
Bez powiązania z wynikami jakości (online lub offline) trudno ocenić, czy wykrywane anomalie mają praktyczne znaczenie. Typowy problem: wyniki kontroli końcowej są dostępne dopiero po kilku godzinach lub dniach, często zgraniane w raporcie PDF albo arkuszu kalkulacyjnym. Trzeba więc:
zidentyfikować klucz, który łączy produkt (lub partię) z danymi procesowymi: czas, numer partii, ID palety, numer formy itp.,
jasno określić, jak rozumiany jest wynik jakości (binarny OK/NOK, kilka klas defektów, wynik liczbowy),
zbudować mechanizm mapowania tych danych do segmentów procesowych.
Dopiero wtedy można uczciwie ocenić, czy system detekcji anomalii rzeczywiście przewiduje lub uprzedza defekty, czy jedynie sygnalizuje abstrakcyjne odchylenia od statystycznej normy.
Balans między złożonością a interpretowalnością cech
Zaawansowane transformacje (np. wielowymiarowe transformaty falkowe, głębokie autoenkodery cech) potrafią poprawić wyniki na papierze, ale szybko gubią interpretowalność. W praktyce dział utrzymania ruchu lub jakości chce wiedzieć, co się zmieniło: czy to wibracje konkretnego łożyska, czy czas trwania konkretnej fazy. Dlatego zwykle lepszy efekt daje warstwowe podejście:
na dole – proste, zrozumiałe cechy powiązane z fizyką procesu,
nad nimi – ewentualne modele, które łączą te cechy w trudniej uchwytne wzorce, ale wciąż pozwalają wrócić do poziomu sygnałów.
Im bardziej „magiczny” jest wektor cech, tym trudniej później uzasadnić operatorowi, dlaczego system wygenerował alarm. A brak zaufania użytkowników końcowych zabija najsprawniejszy technicznie projekt.
Przegląd podejść i modeli do wykrywania anomalii w przemyśle
Klasyczne progi, reguły i SPC – wciąż punkt odniesienia
Najprostsze podejścia opierają się na progach, regułach eksperckich i klasycznej statystyce procesowej (SPC). Mimo mody na ML, to wciąż trzon wielu skutecznych systemów:
stałe progi alarmowe dla krytycznych parametrów (ciśnienie, temperatura, prąd),
karty kontrolne (np. Shewharta, CUSUM, EWMA) do monitorowania stabilności procesu,
logika w PLC i SCADA: sekwencje, interlocki, powiązania między sygnałami.
Ich zalety są oczywiste: łatwo je wdrożyć, zrozumieć i wytłumaczyć. Ograniczenia także: słabo radzą sobie z:
zjawiskami sekwencyjnymi (zmiana kształtu przebiegu, a nie tylko jego poziomu),
relacjami między wieloma sygnałami,
powolnymi, nieliniowymi dryfami procesu.
Dlatego rozsądne projekty nie wyrzucają istniejących progów i SPC, tylko traktują je jako warstwę bazową, a modele anomalii jako element uzupełniający.
Modele nadzorowane – gdy mamy etykiety awarii i defektów
Uczenie nadzorowane kontra detekcja anomalii – różne pytania, różne narzędzia
Gdy dostępne są etykiety awarii, defektów lub konkretnych usterek, naturalną pokusą jest zbudowanie klasyfikatora: „na podstawie sygnałów przewidź, czy będzie defekt/awaria”. To ma sens, o ile kilka warunków jest spełnionych jednocześnie:
liczba przypadków negatywnych (awaria, NOK) jest wystarczająca, by coś się dało nauczyć,
proces i sprzęt nie zmieniają się co chwilę (częste przezbrojenia, modernizacje),
defekt ma przyczynę widoczną w danych procesowych (a nie np. w wadliwym materiale od dostawcy bez śladu w sygnałach).
Modele nadzorowane – od prostych drzew decyzyjnych, przez lasy losowe, po gradient boosting i sieci neuronowe – odpowiadają na pytanie: „czy obserwowana sytuacja jest podobna do znanych przypadków defektu?”. Detekcja anomalii (nienadzorowana) z kolei odpowiada: „czy ta sytuacja jest nietypowa względem historii tego procesu?”. To dwie różne klasy problemów, których nie warto mylić.
Nadmierne poleganie na klasyfikatorach przy skrajnej nierównowadze klas (tłum NOK-ów jest śladowy) prowadzi do modelu, który w praktyce „nauczy się” mówić zawsze OK i będzie miał świetne metryki na papierze. Konieczne jest wtedy stosowanie technik typu:
dostosowane funkcje kosztu (większa kara za przeoczenie defektu niż za fałszywy alarm),
sensowne, a nie kosmetyczne, nadpróbkowanie/undersampling,
metody specyficzne dla rzadkich zdarzeń (np. one-class SVM, modele rankingowe).
W wielu projektach rozsądne okazuje się połączenie: model nadzorowany do przewidywania dobrze zdefiniowanych, częstszych defektów oraz warstwa detekcji anomalii do polowania na „nieznane nieznane”.
Modele nienadzorowane – gdy defekty są rzadkie lub słabo opisane
W większości linii liczba jawnie oznaczonych awarii i defektów jest niewielka, a część usterek przechodzi „pod radarem” (naprawa bez formalnej rejestracji, brak powiązania z danymi). W takim środowisku dominują podejścia nienadzorowane – uczą się one, jak wygląda typowe zachowanie, a potem mierzą odległość od tej „normalności”. Najczęstsze grupy metod to:
metody oparte na odległości/gęstości: k-NN, LOF, izolacyjny las (Isolation Forest),
modele sekwencyjne: HMM, autoenkodery czasowe, LSTM do prognozowania sygnałów,
uczenie reprezentacji: autoenkodery, modele głębokie do kompresji wielowymiarowych przebiegów.
Kluczowy kompromis dotyczy tego, jak wrażliwy ma być system. Zbyt czuły model generuje lawinę „anomalii”, które są po prostu normalnymi zmianami receptur, materiału czy trybu pracy. Zbyt mała czułość – i system nie widzi nic poza najbardziej spektakularnymi awariami, które i tak zauważy operator.
Dobry punkt wyjścia to proste modele (np. PCA + odległość Mahalanobisa, Isolation Forest) zbudowane na stabilnych okresach produkcji jednej konkretnej rodziny produktów, a dopiero potem eksperymentowanie z bardziej złożonymi architekturami.
Modele prognostyczne (RUL, prognoza trendu) jako forma detekcji anomalii
Nie każda anomalia jest skokowym odchyleniem. Część istotnych zjawisk to powolne zużycie lub dryf, które można uchwycić tylko w perspektywie długoterminowej. Tutaj pojawiają się modele prognostyczne:
RUL (Remaining Useful Life) – modele szacujące pozostały czas do uszkodzenia (częste w łożyskach, napędach, pompach),
modele trendu – prognozujące przyszłe wartości sygnałów kluczowych (np. rosnący prąd silnika, spadająca wydajność pompy),
modele degradacji – łączące kilka cech w pojedynczy indeks kondycji (health index).
Detekcja anomalii może wtedy polegać na wykrywaniu przyspieszonej degradacji (np. nagłe skrócenie prognozowanego RUL) lub odchyłek od przewidywanego trendu. Modele te wymagają zazwyczaj dłuższych historii i lepszej kontroli nad zmianami warunków pracy – jeśli co kilka tygodni zmienia się receptura, temperatura otoczenia i obciążenie, to „stabilny trend” bywa fikcją.
Modele hybrydowe – łączenie reguł, statystyki i ML
Typowa pułapka: zbudować jeden „magiczny” model, który ma wykrywać wszystko. W praktyce skuteczniejsza jest architektura warstwowa, w której różne metody zajmują się różnymi typami problemów. Przykładowo:
na poziomie sterownika/SCADA – twarde interlocki i progi bezpieczeństwa,
nad nimi – SPC i karty kontrolne dla wybranych wskaźników procesu,
dla złożonych relacji między wieloma sygnałami – PCA/Isolation Forest lub autoenkoder,
dla konkretnych, częstszych defektów – klasyfikator nadzorowany.
Taki układ ma kilka zalet: łatwiej przypisać odpowiedzialność (który moduł „podniósł rękę”), można stopniowo zwiększać złożoność i nie trzeba wszystkiego przerabiać na ML. Dodatkowo, proste reguły pełnią funkcję sanity check – jeśli zaawansowany model ignoruje ewidentne przekroczenie progu, to wiadomo, że coś poszło nie tak.
Praktyczna walidacja modeli – poza ładnymi wykresami ROC
Przy projektach przemysłowych kluczowe jest pytanie: „co się stanie na hali, gdy model błędnie zadziała?”. Stąd walidacja nie może kończyć się na dokładności, F1 czy AUC. Potrzebne są metryki i procedury bliższe operacyjnej rzeczywistości:
fałszywe alarmy na dobę/zmianę/linię – bo powyżej pewnego progu operatorzy zaczną ignorować wszystko,
średni czas wyprzedzenia alarmu przed awarią – czy model daje czas reakcji, czy tylko „mądrzy się” po fakcie,
pokrycie defektów – jaki odsetek realnych, interesujących usterek jest wychwytywany,
utracona produkcja przez fałszywe alarmy – jeśli reakcją na alarm jest zatrzymanie linii lub dodatkowa kontrola.
Dobrym zwyczajem jest symulacja działania systemu na danych historycznych w trybie „co by było, gdyby”. Czyli: na podstawie danych z ostatniego roku zasymulować, kiedy model by alarmował, jak wcześnie przed realnymi awariami i z jaką częstością w normalnej pracy. To często weryfikuje zbyt optymistyczne oczekiwania.
Uczenie ciągłe i dryf danych – żywy proces zamiast „zamrożonego” modelu
Linie produkcyjne żyją: zmieniają się receptury, dostawcy, narzędzia, a nawet sami operatorzy. Model trenowany na danych z określonego okresu traci aktualność. Pojawia się zjawisko dryfu danych (data drift) i dryfu konceptu (concept drift). Typowe objawy: wzrost liczby alarmów przy braku zmian w realnej awaryjności lub odwrotnie – „cichnięcie” systemu mimo rosnącej liczby usterek.
Dlatego architektura rozwiązania powinna przewidywać:
monitoring rozkładów cech i wyników modelu w czasie (porównanie z okresem referencyjnym),
procedury okresowego odświeżania modeli (np. co kwartał, pół roku),
kontrolę jakości etykiet nowych defektów (czy są spójnie opisywane),
bezpieczne wdrażanie nowej wersji modelu (np. równoległe działanie starej i nowej wersji, shadow mode).
Uczenie ciągłe nie musi oznaczać skomplikowanych algorytmów online learning. W wielu przypadkach wystarczy cykliczne przeuczenie modelu na rozszerzonym zbiorze danych, przy zachowaniu wersjonowania i możliwości powrotu do poprzedniej wersji.
Transfer learning i modele między liniami – kiedy można „przenieść inteligencję”
Częste pytanie: skoro jedna linia ma działający system detekcji anomalii, to czy można go po prostu skopiować na kolejne? Odpowiedź brzmi: „czasem tak, ale zwykle z zastrzeżeniami”. Kilka scenariuszy:
identyczne maszyny, ten sam produkt – można zacząć od wspólnego modelu, a potem delikatnie dostosowywać progi i parametry pod lokalne różnice (np. inne fundamenty, różne środowisko),
podobna technologia, inne parametry – da się wykorzystać część cech lub architekturę modelu, ale trzeba go uczyć od nowa na lokalnych danych,
różne procesy – transfer jest raczej konceptualny (architektura rozwiązania, pipeline danych, dobre praktyki) niż bezpośrednio modelowy.
Bezrefleksyjny transfer modeli między zakładami często kończy się serią rozczarowań: inna kultura utrzymania ruchu, inny poziom hałasu elektrycznego na sygnałach, inne procedury czyszczenia. Lepiej traktować model z pierwszej linii jako „szablon do adaptacji” niż produkt gotowy do kopiowania.
Wybór podejścia do konkretnego przypadku – punkty startowe zamiast dogmatów
Zamiast próbować stworzyć uniwersalną „matrycę decyzyjną”, praktyczniejsze jest myślenie w kategoriach kilku typowych scenariuszy i punktów startowych. Poniżej kilka często spotykanych konfiguracji.
Scenariusz 1: Krytyczne maszyny wirujące, sporo historii awarii
Przykład: łożyska silników, pompy, wentylatory na instalacji, gdzie każda nieplanowana awaria oznacza zatrzymanie całej linii. Dane: sygnały drgań, prądy, temperatury, plus rejestr awarii z systemu CMMS.
Rozsądny punkt startu:
stabilne, dobrze opisane czujniki drgań (często już istnieją),
klasyczne wskaźniki wibracyjne (RMS, crest factor, energia w pasmach) oraz temperatury łożysk,
progi i SPC dla kluczowych wskaźników jako pierwsza linia obrony,
model prognostyczny (np. prosty health index + trend) dla RUL, jeśli historii awarii jest dość,
dodatkowo prosty model nienadzorowany (np. PCA+Mahalanobis) do wykrywania nietypowych kombinacji sygnałów.
Tu łatwo popaść w przesadę i od razu wdrażać głębokie sieci. W praktyce regularnie kalibrowany, dobrze zestrojony system progów plus prosty model degradacji potrafi wychwycić większość istotnych przypadków.
Scenariusz 2: Linia pakująca / montażowa, wiele krótkich cykli, defekty jakości
Przykład: linia montażu elementów, pakowanie do kartonów, zgrzewanie folii. Dane: czasy trwania faz, siły, pozycje, sygnały z enkoderów, wyniki kontroli końcowej (OK/NOK, czasem rodzaj defektu).
Możliwe podejście:
dobra segmentacja cykli oraz oznaczanie trybów pracy (rozruch, stabilna produkcja, testy),
zestaw prostych cech na cykl: czasy faz, max/min sił, integralne (praca), odchylenia od nominalnych profili,
detekcja anomalii na poziomie pojedynczego cyklu (Isolation Forest, PCA) lub krótkiego okna cykli,
jeśli dostępnych jest wystarczająco dużo przypadków NOK – lekki klasyfikator nadzorowany do przewidywania ryzyka defektu,
powiązanie sygnałów z konkretnym gniazdem/stanowiskiem, żeby lokalizować źródła problemiu.
Kluczową pułapką jest chaotyczne mapowanie danych jakości do cykli procesu. Gdy nie da się z dużą pewnością powiedzieć, który cykl odpowiada konkretnemu NOK-owi, modele nadzorowane stają się wątpliwe. Wtedy lepiej oprzeć się na nienadzorowanej anomalii plus analizie przyczyn po stronie inżynierów.
Scenariusz 3: Proces ciągły (chemia, rafineria, hutnictwo), wiele punktów pomiarowych
Przykład: reaktory chemiczne, linie ciągłego walcowania, procesy termiczne. Dane: dziesiątki lub setki sygnałów PID, przepływy, temperatury, ciśnienia, analizy laboratoryjne jakości produktu.
Startowa strategia:
stabilne tagowanie faz procesu (rozruch, ustalony stan, przejścia, czyszczenie),
wybór podzbioru najistotniejszych zmiennych zamiast bezkrytycznego wrzucenia wszystkiego do jednego modelu,
modele wielowymiarowe (PCA, PLS) do opisu normalnej współzależności między zmiennymi,
detekcja anomalii jako odchylenie od tych wielowymiarowych relacji (statystyki T², Q),
integracja z klasycznym APC (Advanced Process Control), tak aby alarmy z modelu były spójne z logiką sterowania,
mapowanie anomalii do wpływu na jakość (korelacja z analizami labów).
Najczęściej zadawane pytania (FAQ)
Co to jest wykrywanie anomalii na linii produkcyjnej i czym różni się od zwykłych alarmów z PLC/SCADA?
Wykrywanie anomalii polega na wychwytywaniu zachowań procesu, maszyn lub operatorów, które odbiegają od typowego, „zdrowego” wzorca pracy. Nie chodzi wyłącznie o klasyczne awarie, ale również o drobne odchylenia, które zwiększają ryzyko braków jakościowych, mikroprzestojów czy przyspieszonego zużycia sprzętu.
Klasyczne alarmy PLC/SCADA opierają się na prostych progach: jeśli temperatura przekroczy X albo ciśnienie spadnie poniżej Y, wywołaj alarm. Systemy wykrywania anomalii (często z użyciem AI) modelują całe zachowanie procesu w czasie i szukają nienaturalnych wzorców, również wtedy, gdy pojedyncze wartości dalej mieszczą się „w normie”. Dzięki temu mogą wychwycić problemy wcześniej, ale wymagają lepiej przemyślanej interpretacji i procedur reakcji.
Jakie typy anomalii występują najczęściej na liniach produkcyjnych?
W praktyce na liniach produkcyjnych pojawia się kilka głównych klas anomalii, które dotykają różnych obszarów:
Anomalie procesowe – odchylenia temperatur, ciśnień, przepływów, prędkości czy momentów od typowych przebiegów. Mogą nie dawać jeszcze widocznych wad, ale zwiększają ich prawdopodobieństwo.
Anomalie jakościowe – bezpośrednio związane z produktem, np. deformacje, rysy, nieszczelności, nieprawidłowa masa lub wymiary, odbarwienia. Zwykle wychwytywane przez systemy wizyjne lub pomiary końcowe.
Anomalie sprzętowe – wskazujące na stan maszyn: rosnące wibracje, zmiana poboru prądu, nadmierne grzanie łożysk, luzy mechaniczne, nietypowe dźwięki.
Anomalie operatorskie – nietypowe zachowania ludzi: inna kolejność czynności przy przezbrojeniu, znacząco dłuższy czas operacji, omijanie standardowych procedur.
Dobrze zaprojektowany system nie zatrzymuje się na stwierdzeniu „wystąpiła anomalia”, ale łączy te kategorie, żeby wskazać, gdzie dokładnie zmieniło się zachowanie: w procesie, w maszynie czy po stronie operatora.
Kiedy wykrywanie anomalii z użyciem AI ma realny sens biznesowy?
Projekt zwykle ma sens wtedy, gdy spełnionych jest kilka warunków jednocześnie. Po pierwsze, koszt awarii, braków jakościowych lub przestojów jest na tyle duży, że opłaca się inwestować w bardziej złożony system niż proste progi w PLC. Po drugie, przyczyny problemów są na tyle złożone, że ręczne ustawienie sensownych progów i reguł jest trudne albo niestabilne w czasie.
Znaczenie ma również dostępność danych (sensowne czujniki, logi, ewentualnie wizja) oraz gotowość organizacji, żeby na te sygnały reagować. Jeśli firmy nie stać na zmianę procedur serwisu, jakości i utrzymania ruchu, system AI skończy jako „ładny dashboard” bez wpływu na wyniki. Tam, gdzie awarie są tanie i rzadkie, a linia jest prosta, częściej lepszy zwrot da klasyczna automatyka, doposażenie czujników i porządny SPC.
Jakie czujniki są potrzebne do skutecznego wykrywania anomalii na produkcji?
Nie ma jednego „magicznego zestawu” czujników – dobór zależy od celu biznesowego i rodzaju anomalii, które chcemy wychwycić. Zwykle wykorzystuje się kombinację istniejących sygnałów z PLC/SCADA (temperatury, ciśnienia, przepływy, prędkości, pozycje) oraz dodatkowych sensorów, np. wibracji, temperatury łożysk, prądu silników czy systemów wizyjnych do jakości.
Kluczowe pytanie nie brzmi „ile czujników?”, tylko „czy dostępne sygnały pozwalają odróżnić zachowanie normalne od nienormalnego w konkretnym przypadku?”. Częsty błąd to inwestowanie w dużą liczbę czujników bez jasnej hipotezy, jak ich dane przełożą się na wcześniejsze wykrycie awarii albo wady. Zwykle rozsądniej jest zacząć od kilku dobrze dobranych punktów pomiarowych i stopniowo je rozszerzać.
Czy systemy AI do wykrywania anomalii zastąpią klasyczne progi i alarmy?
W większości zakładów nie chodzi o zastąpienie, tylko o uzupełnienie. Proste progi nadal są najlepszym narzędziem do pilnowania twardych limitów bezpieczeństwa i parametrów technologicznych (np. maksymalna temperatura, minimalne ciśnienie). Są łatwe do zrozumienia, audytu i wdrożenia w PLC.
AI ma przewagę tam, gdzie problem jest subtelny: w danych złożonych, wielowymiarowych, zależnych od kontekstu (receptura, prędkość, materiał). Modele uczą się zależności z danych, a nie z ręcznie pisanych reguł. Trzeba jednak brać pod uwagę, że ich decyzje są trudniejsze do wyjaśnienia, a zbyt agresywne wdrożenie bez jasnych procedur reakcji może skończyć się „paraliżem alarmowym”. Rozsądne podejście to warstwa AI nad klasycznymi alarmami, a nie zamiast nich.
Jak zmienia się praca utrzymania ruchu i jakości po wdrożeniu wykrywania anomalii?
Największa zmiana to przesunięcie akcentu z reakcji na gotowe awarie na wcześniejsze interwencje. Zespół nie czeka, aż zatrzyma się linia albo pojawi się fala braków, tylko dostaje sygnał: „to zachowanie silnika nie było wcześniej obserwowane w normalnych warunkach” albo „parametry procesu stopniowo dryfują w kierunku obszaru, gdzie historycznie rosła liczba braków”.
To brzmi atrakcyjnie, ale w praktyce wymaga nowych procedur: kto ocenia zasadność ostrzeżenia, na jakiej podstawie decyduje się o zatrzymaniu linii, jaki jest dopuszczalny poziom „fałszywych alarmów”. Bez takiej ramy organizacyjnej system AI zaczyna albo generować ignorowane ostrzeżenia, albo powoduje nadmierne, kosztowne interwencje.
Czy każda anomalia oznacza błąd krytyczny i konieczność zatrzymania linii?
Nie. Z perspektywy statystycznej anomalia to po prostu obserwacja nietypowa względem dotychczasowej historii, ale z perspektywy biznesu liczy się próg istotności. Niewielkie odchylenia mogą być sygnałem do obserwacji lub zaplanowania przeglądu, natomiast tylko część z nich powinna prowadzić do natychmiastowych działań, np. zatrzymania produkcji.
Przy projektowaniu systemu trzeba rozróżnić: jakie odchylenia traktujemy jako „do analizy przy najbliższym przeglądzie”, jakie jako „wymagane szybkie sprawdzenie”, a które jako „stan krytyczny”. Próba wrzucenia wszystkiego do jednego worka „awaria” kończy się albo nadmiarem fałszywych alarmów, albo bagatelizowaniem sygnałów, które faktycznie ostrzegają przed poważnym problemem.
Najważniejsze punkty
Anomalia to nie tylko awaria, ale każde odchylenie od normalnego wzorca pracy maszyny, procesu lub operatora; samo w sobie może nie zatrzymać linii, ale zwiększa ryzyko braków, mikroprzestojów i przyspieszonego zużycia sprzętu.
Definicja anomalii jest względna i silnie zależy od kontekstu (receptury, materiału, fazy procesu), więc proste, sztywne progi na pojedynczych sygnałach często prowadzą albo do nadmiaru fałszywych alarmów, albo do przegapiania istotnych odchyleń.
Bez jasno określonych celów biznesowych (jakość, OEE, bezpieczeństwo, koszty serwisu) projekty wykrywania anomalii łatwo zamieniają się w efektowne, ale mało użyteczne „zabawki AI”, których realnego zwrotu z inwestycji nie da się obronić.
Przejście od reaktywnej diagnostyki do podejścia predykcyjnego wymaga nie tylko modeli, ale też ustalenia zasad reakcji na wczesne ostrzeżenia (kto decyduje o zatrzymaniu linii, jak filtrować sygnały, by uniknąć paraliżu decyzyjnego).
Klasyczne progi i alarmy są proste i przejrzyste, ale słabo radzą sobie z subtelnymi zmianami kształtu sygnału i zależnościami między parametrami; modele AI uczą się wzorca „normalności” z danych, dzięki czemu mogą wyłapać złożone, wielowymiarowe anomalie, choć kosztem większej złożoności i trudniejszej interpretacji.
