Po co w ogóle dane z maszyn? Rzeczywiste decyzje zamiast „AI dla AI”
AI w produkcji to tylko narzędzie do poprawy wskaźników
Algorytmy AI w zakładach produkcyjnych mają sens wyłącznie wtedy, gdy przekładają się na konkretne liczby: wyższe OEE, mniej braków, niższa awaryjność i mniejsze zużycie energii. Dane z maszyn nie są celem samym w sobie. To paliwo do modeli, które mają zmienić sposób podejmowania decyzji na hali: kiedy zatrzymać maszynę, jak ustawić parametry procesu, który produkt puścić jako następny, gdzie wysłać ekipę utrzymania ruchu.
Najczęściej pierwszym realnym celem wdrożeń AI nie jest „sztuczna inteligencja w fabryce”, tylko ograniczenie:
nieplanowanych przestojów kluczowych maszyn,
powstawania braków przy zmianach receptur lub przezbrojeniach,
skoków zużycia energii przy szczytowym obciążeniu,
czasochłonnych, ręcznych analiz raportów i danych z Excela.
Mit kontra rzeczywistość: popularna wizja „fabryki AI”, w której algorytmy same zarządzają produkcją end‑to‑end, jest dziś głównie materiałem marketingowym. Realne projekty zaczynają się od pojedynczych, dobrze zawężonych problemów, gdzie dane z kilku maszyn zasilają jeden konkretny model predykcyjny albo system detekcji anomalii.
Dashboard to nie decyzja
W wielu zakładach dane z maszyn już są zbierane, ale kończą żywot na „ładnym dashboardzie” – kilku wykresach w systemie SCADA lub w BI, które ogląda się raz na tydzień na spotkaniu produkcyjnym. To przydatne, ale daleko od prawdziwego wykorzystania AI. Różnica jest prosta: dashboard mówi, co było, a algorytm AI wskazuje, co zrobić dalej.
Przykład: system wizualizacji pokazuje, że przez ostatnie dwie zmiany temperatura w strefie grzania wtryskarki była zbyt wysoka, a ilość braków wzrosła. To wiedza post factum. Model AI, zasilany danymi z czujników i informacjami o jakości, potrafi zasugerować korektę temperatury lub prędkości ślimaka przed tym, jak scrap przekroczy akceptowalny poziom. Podobnie w utrzymaniu ruchu – raporty z CMMS pokazują, co się popsuło, ale algorytm predykcyjny wskazuje, która maszyna wymaga interwencji w najbliższych dniach.
Różnicę dobrze oddaje pytanie, które warto sobie zadawać przy każdym projekcie danych: kto i na jaką decyzję ma zareagować na wynik modelu? Jeśli trudno to wskazać, projekt grozi skończeniem w szufladzie „fajny PoC, ale nic z tego nie wyszło”.
Przykład z linii pakującej: od sygnałów do działania
Na prostej linii pakującej dane do AI można zebrać niemal od ręki. Z typowego sterownika PLC i czujników najczęściej są dostępne:
liczba sztuk na wejściu i wyjściu linii,
prędkość taśmociągu,
stany czujników zacięć (fotokomórki, czujniki obecności),
czasy zatrzymań i ponownych startów,
informacje z systemu wizyjnego o odrzuconych paczkach.
Jeśli te sygnały zostaną połączone z informacją o zmianie, typie produktu i planie produkcji, model AI może np.:
wykrywać wczesne oznaki zbliżającego się zacięcia (wzrost czasu przejazdu paczki między czujnikami, nietypowy rozkład odrzuceń),
rekomendować obniżenie prędkości przy konkretnych kombinacjach produktu i opakowania,
podpowiadać optymalny moment na krótką przerwę czyszczącą, zanim ilość zacięć wymusi dłuższy postój.
Decyzja przestaje być intuicyjna („chyba za szybko jedziemy, zwolnijmy trochę”), a staje się oparta o statystykę i wzorce z danych. Planista może zmienić kolejność zleceń, utrzymanie ruchu – przełożyć planowany przegląd, a kierownik zmiany – szybciej zareagować na powtarzające się mikroprzestoje.
Dlaczego „najpierw kupmy AI, dane się później ogarnie” nie działa
Mit „najpierw wybierzmy platformę AI, dane do niej potem podłączymy” kończy się prawie zawsze tak samo: drogim systemem, który stoi i czeka na sensowne dane. Algorytmy uczące się, szczególnie modele predykcyjne w utrzymaniu ruchu czy systemy detekcji anomalii w procesie, są skrajnie wrażliwe na jakość i spójność danych z maszyn.
Bez:
stabilnych sygnałów pomiarowych,
spójnych znaczników czasu (timestampów),
czytelnych etykiet zdarzeń typu „awaria”, „postój planowany”, „produkt wadliwy”,
kontekstu procesu (jaka receptura, jakie zlecenie, jaka zmiana),
najlepsza platforma AI nie wyciągnie z danych niczego poza ładnymi wykresami. Zdrowa kolejność to: cel biznesowy → sygnały z maszyn → architektura zbierania danych → przygotowanie danych → dobór modelu AI. Dopiero na samym końcu jest pytanie „w czym to wdrożymy” – w chmurze, w lokalnym serwerze, na edge.
Myślenie w kategoriach pełnej pętli: czujnik → model → decyzja → działanie
Samo „wytrenowanie modelu” nie poprawia OEE. Korzyści pojawiają się dopiero wtedy, gdy wyniki modeli AI są wplecione w codzienną pracę: jako alerty, sugestie ustawień, rekomendacje zadań dla UR, a w bardziej zaawansowanych przypadkach – jako automatyczne korekty parametrów maszyny (closed loop).
Praktycznie można to ująć w prostej pętli:
Czujnik zbiera sygnał (np. wibracje łożyska, temperaturę, prąd silnika).
System zbierania danych zapisuje sygnały z odpowiednią częstotliwością i z dokładnym czasem.
Model AI analizuje strumień danych, wykrywa wzorce lub prognozuje awarie.
Rekomendacja trafia w zrozumiałej formie do człowieka (ekran HMI, e‑mail, zadanie w CMMS) lub do sterownika.
Działanie – operator zmienia nastawę, UR planuje ingerencję, sterownik koryguje parametry automatycznie.
Jeśli na którymkolwiek z tych etapów pętla się urywa (np. model generuje wyniki, ale nikt ich nie widzi albo nikt nie wie, co z nimi zrobić), projekt AI zamienia się w ciekawy eksperyment zamiast w narzędzie decyzyjne. Dane z maszyn mają sens wtedy, gdy zamykają taką pętlę i regularnie prowadzą do konkretnych działań na hali.
Jakie dane z maszyn są naprawdę potrzebne? Od sygnału do informacji
Podstawowe typy danych z maszyn
Na hali produkcyjnej krąży wiele różnych rodzajów danych. Z punktu widzenia algorytmów AI, szczególnie tych używanych w przemyśle, kluczowe są cztery kategorie:
Dane procesowe – pomiary ciągłe, np. temperatura, ciśnienie, poziom, przepływ, prądy silników, prędkości obrotowe, pozycje siłowników, napięcie, moment obrotowy, wartości analogowe z czujników wibracji.
Dane jakościowe – wyniki kontroli jakości: wymiary, waga, zgodność z tolerancją, wyniki testów funkcjonalnych, informacje z systemów wizyjnych (np. wykryte defekty).
Dane zdarzeniowe – stany „ON/OFF”, sygnały start/stop, alarmy, awarie, zmiany receptur, zmiany trybu pracy, mikroprzestoje, przezbrojenia.
Dane konfiguracyjne i kontekstowe – receptury, parametry setpointów, identyfikacja produktu, numer zlecenia, operator, zmiana, numer narzędzia, wersja oprogramowania sterownika.
Dla modeli predykcyjnych w utrzymaniu ruchu najważniejsze są dane procesowe i zdarzeniowe, natomiast dla modeli jakościowych – kombinacja danych procesowych i jakościowych, wzmocniona kontekstem (np. receptura, dostawca surowca). Bez tego ostatniego model „widzi” jedynie liczby, ale nie rozumie, w jakich warunkach proces przebiegał.
Dane „ładne” kontra dane naprawdę użyteczne
Częstym zaskoczeniem jest to, że dane najmniej efektowne graficznie bywają najbardziej wartościowe. Wykres pięknie wygładzonej temperatury nic nie powie modelowi predykcyjnemu o nadchodzącej awarii, jeśli wszystkie istotne fluktuacje zostały przefiltrowane przez sterownik. Z kolei rzadko występujące, ale skrajnie ważne zdarzenia – krótkie skoki prądu, wibracje przy konkretnym obciążeniu – decydują o tym, czy model zdoła wykryć zbliżający się problem.
Rzeczywiście użyteczne dane z maszyn zazwyczaj:
są surowe lub możliwie bliskie surowym (przed nadmiernym filtrowaniem w PLC),
zawierają zdarzenia graniczne – awarie, przekroczenia progów, przejścia między stanami,
są powiązane z kontekstem technologicznym: który produkt, która receptura, jaka zmiana, jaki operator,
mają spójny i precyzyjny czas, by móc je łączyć z innymi źródłami (np. systemem jakości).
Mit kontra rzeczywistość: powszechne przekonanie „im więcej danych, tym lepiej” często kończy się morzem nieopisanych tagów i godzinami spędzonymi na ich ręcznym porządkowaniu. Dużo większą wartość ma mniejsza liczba sensownie opisanych sygnałów, połączonych z jasno zdefiniowanymi zdarzeniami procesu i wynikami jakości.
Jak rozpoznać sygnały z potencjałem predykcyjnym
Nie każdy sygnał z maszyny nadaje się na wejście do modelu predykcyjnego. Prosty stan binarny typu „silnik ON/OFF” ma małą wartość diagnostyczną – mówi tyle, że silnik pracuje lub stoi. Znacznie większy potencjał mają:
ciągłe sygnały pomiarowe – prąd silnika, temperatura łożysk, ciśnienie medium, poziom wibracji,
sygnały o wysokiej częstotliwości próbkowania – np. wibracje łożysk czy drgania prasy,
wzorce czasowe – narastanie wartości w czasie, częstotliwość krótkich skoków, zmiany kształtu przebiegu,
połączone sygnały – np. kombinacja prądu silnika, temperatury i prędkości obrotowej.
Dobrym wskaźnikiem jest proste pytanie do doświadczonego mechanika czy technologa: „po czym poznajesz, że z tą maszyną dzieje się coś niepokojącego?”. Jeśli odpowiedź brzmi: „inaczej brzmi”, „bardziej wibruje”, „nagle bierze więcej prądu”, „częściej się zacina”, to wiesz, które sygnały mają potencjał predykcyjny i powinny znaleźć się w systemie zbierania danych.
Przykład: prasa mimośrodowa i kluczowe sygnały
Dla prasy mimośrodowej, na której zależy utrzymaniu ruchu, sensowne jest zbudowanie prostego modelu predykcyjnego dla krytycznych elementów, takich jak łożyska czy tłumik drgań. Wbrew pozorom, nie trzeba od razu zbierać dziesiątek sygnałów. Często wystarczy dobrze dobrane 3–5 zmiennych:
wibracje na ramie lub w okolicy łożysk (1–2 punkty pomiarowe),
prąd silnika głównego (AC lub DC, najlepiej w formie sygnału analogowego, nie tylko binarnego „zabezpieczenie zadziałało”),
temperatura w newralgicznych punktach (np. łożyska, olej),
licznik cykli (ile uderzeń wykonała prasa od ostatniego przeglądu lub wymiany elementu),
podstawowe dane kontekstowe: typ narzędzia, materiał wsadu, nastawa siły.
Z takiego zestawu można nauczyć model, który będzie wskazywał odchylenia od typowego zachowania maszyny przy danym narzędziu i materiale. Nie trzeba od razu kompletnych cyfrowych bliźniaków – kluczowe jest uchwycenie zmian, które poprzedzają awarię.
Dlaczego „więcej danych” często przegrywa z „lepszą strukturą”
Surowa ilość danych bywa myląca. Fabryka może mieć milion tagów w systemie SCADA, z czego większość to pomocnicze stany sterownika, sygnały diagnostyczne i setki powielonych lub nieużywanych zmiennych. Dla AI to głównie szum. Tymczasem sensowna struktura i porządne etykiety mogą z mniejszej liczby sygnałów wycisnąć znacznie więcej.
Praktycznie sprowadza się to do kilku prostych wymogów:
konsekwentne nazewnictwo (np. Linia1/Prasa2/Silnik_Glowny/Prad zamiast DB10.DBW12),
przypisanie tagów do maszyn, stacji i komponentów,
rozróżnienie, które sygnały są procesowe, a które diagnostyczne,
powiązanie parametrów z konkretnym produktem i operacją,
opis jednostek, zakresów, częstotliwości próbkowania.
Mit jest taki, że „AI sobie to ogarnie”. Rzeczywistość: jeśli człowiek z UR lub technologii nie wie, co oznacza dany tag, to model też się tego nie „domyśli” – najwyżej dopasuje się do przypadku i będzie generował losowo wyglądające alarmy.
Jak stopniowo porządkować istniejące dane z maszyn
Pełna inwentaryzacja wszystkich tagów na raz zwykle kończy się blokadą – projekt utknie na etapie Excela z kilkunastoma tysiącami wierszy. Dużo rozsądniej jest podejść do tego iteracyjnie, wokół konkretnych przypadków użycia.
Praktyczny scenariusz wygląda tak:
Wybór jednej linii lub jednego typu maszyny krytycznej z punktu widzenia OEE lub kosztów UR.
Spisanie tylko tych sygnałów, które są potrzebne dla zaplanowanego przypadku użycia (np. predykcja awarii, poprawa jakości, redukcja mikroprzestojów).
Wspólna sesja UR + technologia + automatyk, podczas której sygnały są:
nazwane po ludzku,
przypisane do konkretnego komponentu maszyny,
opisane jednostką, zakresem i znaczeniem.
Wprowadzenie tej struktury do systemu OT/IT (SCADA, historian, data lake) jako „wzoru” dla kolejnych linii.
Po jednej–dwóch takich iteracjach zespół łapie schemat i kolejne maszyny da się ogarnąć znacznie szybciej. AI dostaje dane, z których da się coś wytrenować, a ludzie – widok, który jest zrozumiały również bez doktoratu z automatyki.
Źródło: Pexels | Autor: Google DeepMind
Czujniki i źródła danych w zakładzie: co już masz, a czego brakuje
Mapa aktualnych źródeł danych na hali
Zanim ktokolwiek zacznie kupować nowe czujniki „pod AI”, warto zobaczyć, co już jest w zakładzie. W większości fabryk dane płyną z wielu źródeł, tylko są rozproszone i niespójne:
PLC i sterowniki maszyn – podstawowe sygnały procesowe, stany, alarmy, liczniki, tryby pracy.
SCADA / HMI – zagregowane dane do wizualizacji, często z historią, ale po wstępnej obróbce.
Rejestratory procesowe i loggery – osobne urządzenia zapisujące temperatury, ciśnienia czy przebiegi prądów.
Systemy jakości (LIMS, SPC, systemy wizyjne) – wyniki pomiarów, etykiety typu „OK / NOK”, kody przyczyn odrzutu.
CMMS / systemy UR – awarie, zgłoszenia, interwencje, planowane przeglądy, wymiany części.
MES / ERP – zlecenia produkcyjne, czasy zadań, produkty, partie materiału, zmiany.
Problemem rzadko jest całkowity brak danych. Częściej – brak spójnego sposobu, by połączyć te strumienie w jedną chronologiczną historię tego, co działo się z konkretną maszyną i konkretną partią produktu.
Typowe luki w danych pod projekty AI
Kiedy zaczyna się konkretny projekt (np. predykcyjne utrzymanie ruchu), nagle okazuje się, że brakuje kilku kluczowych elementów układanki. Najczęstsze braki to:
brak sygnałów o zużyciu komponentów – np. brak licznika cykli narzędzia, czasu pracy łożyska, historii regulacji,
brak precyzyjnego czasu – sterowniki i systemy nie są zsynchronizowane, każde urządzenie ma własny zegar,
brak danych o awariach w formie maszynowo czytelnej – awarie są w CMMS, ale bez powiązania z konkretnymi tagami i czasem,
niedostateczna rozdzielczość czasowa – wartości są zapisywane co minutę, podczas gdy istotne zjawiska trwają sekundy lub ułamki sekund,
brak sygnałów wibracyjnych lub akustycznych dla elementów szybkoobrotowych.
W praktyce często wychodzi na to, że lepiej dołożyć dwa dodatkowe czujniki i zsynchronizować zegary niż gromadzić kolejne gigabajty mało przydatnych informacji.
Kiedy warto dodać nowe czujniki
Nowe czujniki mają sens wtedy, gdy wiadomo, jaką decyzję umożliwią. Przykład: jeśli od lat łożyska w konkretnym wentylatorze padają „niespodziewanie”, a jedyne dostępne informacje to „wentylator ON/OFF” i zabezpieczenie termiczne, to:
dodanie czujnika wibracji na obudowie łożyska,
plus pomiar prądu silnika w formie analogowej,
połączone z licznikiem godzin pracy lub cykli,
otwierają drogę do sensownego modelu predykcyjnego. Bez tego AI ma tylko dwie klasy: „żyje” i „umarło”, więc nie ma się czego nauczyć.
Z drugiej strony, montaż kilkunastu drogich akcelerometrów na każdej, nawet mało krytycznej maszynie, w nadziei że „AI kiedyś to wykorzysta”, kończy się zazwyczaj plikami pełnymi widm częstotliwości, których nikt nie analizuje. Cel powinien prowadzić dobór czujników, nie odwrotnie.
Czujniki dyskretne vs analogowe i wysokoczęstotliwościowe
W wielu zakładach dominuje myślenie w kategoriach sygnałów dyskretnych: krańcówka, fotokomórka, „czujnik obecności”. Z punktu widzenia AI to za mało – dostajemy tylko informację „jest/nie ma”. Zdecydowanie bogatsze są:
sygnały wysokoczęstotliwościowe – wibracje, dźwięk, czasem prąd silników przy dużym oversamplingu.
Prosta modernizacja polegająca na wymianie kilku krańcówek na czujniki analogowe (np. liniał pozycjonujący, czujnik z wyjściem 4–20 mA) potrafi udostępnić znacznie bogatszy obraz procesu, bez rewolucji w konstrukcji maszyny.
Dane z ludzi jako uzupełnienie danych z czujników
Wiele zjawisk, które AI ma wykrywać, jest dziś rozpoznawanych wyłącznie „na słuch” lub „na czuja”. Nie oznacza to, że trzeba je ignorować. Wprost przeciwnie – da się je ustrukturyzować.
Dobrym podejściem są proste formularze lub aplikacje dla operatorów i służb UR, które pozwalają:
szybko oznaczyć nietypowe zachowanie maszyny („dziwny dźwięk”, „spadek siły”, „częstsze zacięcia”),
opisać przyczyny i działania przy awariach (wybór z listy + krótki komentarz),
powiązać te obserwacje z konkretną maszyną, zleceniem i czasem.
Mit, że „AI działa tylko na twardych liczbach”, jest mylący. Modele uczą się też z etykiet, a etykietę może nadać człowiek. Jeżeli operator jeden raz oznaczy w systemie moment, kiedy maszyna „dziwnie zabrzmiała”, a w tym samym czasie zbieramy dane z czujników, to mamy bezcenny materiał treningowy poprzedzający potencjalną awarię.
Od hali do serwera: architektura zbierania danych IIoT pod AI
Warstwa OT, edge i IT – kto za co odpowiada
Sprawnie działająca architektura danych dla AI zaczyna się od jasnego podziału ról między trzema warstwami:
OT (Operational Technology) – sterowniki, sieci przemysłowe, SCADA. Tu nie ma miejsca na eksperymenty, wszystko musi działać deterministycznie i bezpiecznie.
Edge – urządzenia pośrednie (gatewaye, przemysłowe komputery), które pobierają dane z OT, wstępnie je przetwarzają i przekazują dalej. Tu można już liczyć, agregować, filtrować.
IT / chmura – serwery, bazy danych, data lake, środowiska obliczeniowe do trenowania i wdrażania modeli.
Z perspektywy bezpieczeństwa i stabilności maszyn kluczowe jest to, by AI nie „wchodziła z butami” do sterowników. Modele mogą doradzać, ale ostatnie słowo przy krytycznych interwencjach ma logika w PLC lub dedykowane funkcje bezpieczeństwa.
Prosty schemat przepływu danych pod AI
W wielu zakładach wystarczy stosunkowo prosty schemat, aby zacząć działać:
Gateway / edge łączy się z PLC i SCADA (Modbus, OPC UA, Profinet – w zależności od parku maszynowego).
Na edge odbywa się pierwsze filtrowanie: usuwanie ewidentnych błędów, agregacja, nadawanie znaczników czasu.
Dane trafiają do historyzatora lub bazy typu time-series (na serwerze lokalnym lub w chmurze).
AI ma dostęp do takiego repozytorium, gdzie może:
trenować modele na danych historycznych,
przetwarzać strumień danych w czasie zbliżonym do rzeczywistego.
Wyniki modeli wracają w formie alertów, wskaźników lub rekomendacji – do HMI, SCADA, CMMS, MES.
Taka architektura pozwala trzymać „świat AI” z dala od krytycznych pętli sterowania, a jednocześnie regularnie zasilać algorytmy świeżymi danymi z hali.
Synchronizacja czasu – mały szczegół, duży problem
Jedną z najczęstszych przeszkód przy wykorzystywaniu danych z wielu systemów jest niespójny czas. Jeden sterownik jest o trzy minuty do przodu, inny o dwie do tyłu, system jakości rejestruje pomiary w swojej strefie czasowej, a CMMS w jeszcze innej.
Z punktu widzenia AI wygląda to tak, jakby produkt został przebadany godzinę przed swoją produkcją albo awaria nastąpiła przed wystąpieniem objawów w danych procesowych. Modele da się wprawdzie „dopasować” ręcznie, ale skala bałaganu rośnie z każdą kolejną linią.
Rozwiązaniem jest konsekwentne wprowadzenie:
jednego źródła czasu (NTP) dla wszystkich urządzeń i systemów,
spójnej strefy czasowej w systemach IT i OT,
jasnej polityki dotyczącej zmiany czasu (np. zapis w UTC).
Brzmi trywialnie, ale to dokładnie ten rodzaj „nudnej” pracy infrastrukturalnej, który decyduje, czy dane z maszyn dadzą się w ogóle złożyć w koherentną historię procesu.
Jak nie zabić sieci przemysłowej przesyłem danych do AI
Lęk, że „AI zapcha sieć” jest uzasadniony, jeśli ktoś planuje wysyłać wszystkie surowe próbki wibracji co milisekundę do chmury. Na szczęście są inne opcje.
Rozsądny kompromis to:
agregacja na edge – liczenie statystyk (np. RMS, kurtosis, peak-to-peak) z wysokoczęstotliwościowych sygnałów i wysyłanie tylko tych parametrów,
buforowanie lokalne – przechowywanie pełnych przebiegów tylko „wokół zdarzeń” (np. 10 sekund przed i po alarmie),
różne poziomy rozdzielczości – np. surowe dane przez kilka dni, dane zagregowane (średnie, min, max) przez miesiące.
Rzeczywistość jest taka, że do detekcji anomalii często wystarczą gęstsze dane tylko z kilku krytycznych sygnałów. Reszta może płynąć rzadziej, bez obciążania sieci i serwerów.
Bezpieczeństwo i dostęp do danych pod AI
Dostęp AI do danych z maszyn nie może osłabiać bezpieczeństwa OT. Oznacza to kilka prostych zasad:
komunikacja z maszynami jedynie przez kontrolowane gatewaye, nigdy bezpośrednio z chmury do PLC,
segmentacja sieci – wyraźny podział na strefę OT i IT z kontrolowanymi punktami styku,
kontrola dostępu oparta na rolach – inne uprawnienia dla zespołu AI, inne dla UR, jeszcze inne dla dostawców.
Mit, że „dla AI trzeba otworzyć wszystko”, jest po prostu ryzykowny. Modele nie muszą mieć pełnych praw do sterowników; wystarczy im spójny i bezpieczny dostęp do odczytu danych oraz kanał do przekazywania sugestii lub alarmów.
Przygotowanie danych pod AI: czyszczenie, etykietowanie, kontekst
Dlaczego dane z maszyn są „brudne” z punktu widzenia AI
Z perspektywy automatyka sygnał, który „skacze”, bywa czymś normalnym. Dla modelu AI to już problem: trudno z niego wyciągnąć powtarzalne wzorce. Do tego dochodzą:
braki w rejestracji (dziury czasowe, restarty sterowników),
zmiany zakresów i skalowania bez udokumentowania,
nowe wersje oprogramowania PLC zmieniające logikę sygnałów,
ręczne korekty wpisów w systemach jakości.
Podstawowe kroki czyszczenia danych procesowych
Zanim jakikolwiek model zobaczy dane z maszyn, trzeba je doprowadzić do stanu „używalności”. W praktyce sprowadza się to do kilku powtarzalnych kroków, które da się częściowo zautomatyzować:
detekcja i uzupełnianie braków – identyfikacja dziur w szeregach czasowych, decyzja, czy dane interpolować, czy oznaczyć jako brakujące i pominąć w trenowaniu,
usuwanie oczywistych błędów – wartości fizycznie niemożliwe (np. temperatura -100°C w procesie obróbki cieplnej) lub krótkie „piki” wynikające z błędów pomiaru,
ujednolicenie jednostek i zakresów – przeskalowanie sygnałów tak, by 100% znaczyło zawsze to samo, niezależnie od wersji maszyny,
filtracja szumu – proste filtry (np. średnia krocząca, filtry cyfrowe) tam, gdzie zmienność nie niesie informacji, tylko zaciemnia obraz.
Mit, że „AI sama sobie poradzi z brudnymi danymi”, kończy się rozczarowaniem. Modele rzeczywiście są odporne na pewien poziom chaosu, ale gdy każdy sygnał „skacze inaczej”, algorytm uczy się przypadkowych wzorców zamiast zjawisk procesowych.
Stabilizacja sygnałów i wykrywanie zmian w konfiguracji
Jednym z większych wyzwań są zmiany, które dzieją się „po cichu”: serwisant zmienia nastawy, ktoś wymienia przetwornik na inny typ, linia zostaje zmodernizowana, ale nazwy zmiennych pozostają te same. Z punktu widzenia AI wygląda to jak nagła zmiana zachowania maszyny, choć w rzeczywistości zmienił się sposób pomiaru.
Dlatego oprócz samego czyszczenia danych potrzebne są mechanizmy, które wykryją, że:
zmienił się zakres pracy sygnału (np. prąd silnika nagle „przeskoczył” na stałe o pewną wartość),
pojawiła się nowa wersja programu PLC lub receptury,
doszło do wymiany czujnika na inny model z inną charakterystyką.
Praktycznym podejściem jest powiązanie danych procesowych z rejestrem zmian technicznych (np. w CMMS lub systemie do zarządzania projektami). Każda istotna zmiana w konfiguracji maszyny powinna być oznaczona w czasie, tak aby modele mogły uwzględnić „przed” i „po” jako dwa różne okresy uczenia.
Etykietowanie zdarzeń: z chaosu alarmów do czytelnych klas
Bez sensownie nadanych etykiet dane z maszyn to tylko liczby. Algorytm potrzebuje informacji, co jest stanem normalnym, a co awarią, zużyciem, błędem operatora czy zmianą surowca. Problem w tym, że surowe logi alarmów rzadko nadają się do bezpośredniego użycia.
W typowym zakładzie ten sam fizyczny problem (np. zacięcie podajnika) bywa zapisany jako kilka różnych alarmów w zależności od miejsca wykrycia i wersji sterownika. Dodatkowo operatorzy nie zawsze kasują alarmy od razu; czas trwania zdarzenia w logu jest więc w dużej mierze przypadkowy.
Efektywniejsze od „wrzucenia do modelu wszystkich alarmów” jest zrobienie krótkiej, ale dobrze przemyślanej pracy koncepcyjnej:
zgrupowanie alarmów w klasy problemów (np. „brak materiału”, „błąd pozycjonowania”, „przeciążenie napędu”),
ustalenie, które klasy są dla AI najciekawsze (np. te poprzedzające kosztowne postoje),
stworzenie prostych reguł łączenia alarmów w zdarzenia (np. sekwencja kilku alarmów w krótkim czasie to jeden przypadek awarii).
Rzeczywistość jest taka, że godzina rozmowy z doświadczonym mechanikiem, który pomoże zinterpretować logi zdarzeń, daje modelowi więcej niż tygodnie „ślepej” analizy surowych alarmów.
Łączenie danych procesowych z danymi jakościowymi i produkcyjnymi
Maszyna może pracować „idealnie” z punktu widzenia czujników, a mimo to produkować złe wyroby. Dla AI sygnały z PLC to tylko jedna warstwa. Druga to dane z systemów jakości i produkcji:
wyniki kontroli wymiarów, wytrzymałości, szczelności,
informacje o reklamacjach i zwrotach,
dane o partiach surowców, dostawcach, recepturach.
Dopiero połączenie przebiegu procesu (temperatury, prędkości, naciski) z wynikami jakości pozwala budować modele, które przewidują nie tylko awarie, ale też ryzyko powstania wadliwego produktu. Trzeba jednak zadbać o wspólne „klucze”:
jednoznaczne identyfikatory partii i zleceń,
spójne oznaczenia maszyn i linii w różnych systemach,
zgranie czasowe między rejestracją procesu a momentem badania jakości.
Częsty mit mówi, że „wystarczy wziąć wszystkie dostępne dane i AI sama znajdzie korelacje”. Bez poprawnego powiązania sztuka nie wie, który przebieg procesu dotyczy którego wyrobu. W efekcie model widzi mieszankę przypadkowych historii, z której trudno wyciągnąć sensowną zależność.
Ten sam odczyt z czujnika może oznaczać coś zupełnie innego w zależności od kontekstu. Prędkość taśmy „50” ma inny sens przy produkcji detali ciężkich, a inny przy lekkich. Dla AI kontekst to m.in.:
identyfikator produktu lub receptury,
numer zmiany i brygady,
tryb pracy maszyny (setup, produkcja, czyszczenie, test).
Jeżeli te informacje nie są jednoznacznie zapisane w danych, modele najczęściej uczą się „średniego” zachowania, które jest poprawne dla nikogo. W lepszym scenariuszu trzeba trenować osobne modele dla każdej konfiguracji; w gorszym – model myli anomalię z normalną zmianą trybu pracy.
Dobrym wzorcem jest eksplicytne oznaczanie w danych:
momentów przezbrojeń i zmian receptur,
okresów rozruchu i zatrzymania (oddzielnie od stabilnej pracy),
okresów prac serwisowych i testów (tak, by modele nie uznawały ich za anomalie).
Normalizacja i standaryzacja zmiennych dla modeli
Maszyny generują dziesiątki, czasem setki zmiennych o różnych zakresach i jednostkach. Dla człowieka to oczywiste, że 200°C to inna skala niż 5 bar, ale większość algorytmów wymaga wcześniejszej normalizacji, inaczej sygnały o dużych liczbach „przykryją” pozostałe.
Typowe metody to:
skalowanie do zera-jedynki – przeliczenie wartości względem minimalnego i maksymalnego zakresu pracy,
standaryzacja – odjęcie średniej i podzielenie przez odchylenie standardowe (przydatne, gdy rozkłady są w miarę „normalne”),
skalowanie względem limitów technologicznych – wyrażanie wielkości jako procentu dopuszczalnego zakresu (np. 0–100% zakresu bezpiecznej pracy).
Dobrą praktyką jest dokumentowanie przyjętych skal i limitów technologicznych razem z modelem. Inaczej każda zmiana w konfiguracji procesu (np. podniesienie maksymalnej prędkości) może niepostrzeżenie wypaczyć znaczenie przeskalowanych sygnałów.
Ekstrakcja cech z sygnałów czasowych
Modele rzadko pracują bezpośrednio na surowych przebiegach czasowych. Dużo łatwiej uczy się im z tzw. cech (features), które opisują zachowanie sygnału w krótkich oknach czasowych. Dotyczy to zarówno prostych sygnałów procesowych, jak i wibracji czy dźwięku.
Z podstawowego okna danych (np. 10 sekund, 1 minuta) można wyciągnąć m.in.:
miary kształtu rozkładu – skośność, kurtoza, liczba przekroczeń progu,
cechy częstotliwościowe – widma FFT, energia w określonych pasmach,
cechy trendu – lokalne nachylenie, przyspieszenie zmiany, kierunek trendu.
Mit, że „im więcej cech, tym lepiej”, mści się, gdy do modelu trafiają setki słabo przemyślanych parametrów. Sensowniejsze jest zacząć od kilkunastu–kilkudziesięciu dobrze zrozumianych cech, które inżynierowie potrafią powiązać z fizyką procesu, a dopiero potem rozbudowywać zestaw.
Okna czasowe i wyrównywanie wielu sygnałów
Zdarzenia w maszynie mają swoją dynamikę: rozbieg, narastanie, wygaszanie. Model musi widzieć tę sekwencję, a nie pojedynczy „strzał” wartości. Dlatego dane do uczenia składa się zwykle z wielu sygnałów w tym samym przedziale czasu.
Kluczowe decyzje to:
długość okna – zależna od zjawiska: inne dla mikrozacięcia, inne dla procesu nagrzewania pieca,
krok przesuwania okna – czy każde okno zachodzi na poprzednie (większa liczba przykładów), czy jest od niego niezależne,
wyrównanie sygnałów – sprowadzenie wszystkich zmiennych do wspólnej siatki czasowej mimo różnych częstotliwości próbkowania.
Od jakości tak przygotowanych „klocków czasowych” zależy, czy model będzie w stanie wychwycić subtelne zmiany poprzedzające awarię albo pogorszenie jakości, czy też zobaczy tylko przypadkowe fluktuacje.
Balans klas: mało awarii, dużo normalnej pracy
Z punktu widzenia eksploatacji „mało awarii” to dobra wiadomość. Z punktu widzenia modelu – kłopot. Dane z maszyn są zwykle skrajnie niezrównoważone: tysiące godzin poprawnej pracy i kilka krótkich epizodów z problemami.
Jeżeli problemu nie uwzględni się na etapie przygotowania danych, otrzymuje się model, który zawsze przewiduje „wszystko w porządku” i ma 99% trafności – na papierze. Aby uniknąć tej pułapki, stosuje się m.in.:
nadpróbkowanie rzadkich klas – wielokrotne użycie fragmentów z awariami (czasem z drobnymi modyfikacjami),
podpróbkowanie klasy większościowej – ograniczenie liczby przykładów normalnej pracy,
modele detekcji anomalii – uczenie się wyłącznie z danych „zdrowych” i traktowanie odchyleń jako potencjalnych problemów.
Często najbardziej praktyczne okazuje się połączenie podejścia klasycznego (klasy „awaria X”, „awaria Y”) z detekcją anomalii. Pierwsze odpowiada na pytanie „co się prawdopodobnie stanie?”, drugie – „czy to zachowanie w ogóle mieści się w historycznie obserwowanych ramach?”.
Walidacja danych: test „zdrowego rozsądku” przed AI
Zanim dane trafią do trenowania, warto przepuścić je przez prosty filtr „zdrowego rozsądku”. Nie musi to być skomplikowana analityka – często wystarczy kilka prostych wykresów i zaproszenie do stołu ludzi z UR, produkcji i jakości.
Kilka pytań, które warto zadać przy takiej weryfikacji:
czy przebiegi głównych sygnałów odpowiadają znanemu zachowaniu maszyny w różnych trybach pracy,
czy okresy oznaczone jako „awaria” faktycznie wyglądają inaczej niż normalna praca,
czy opis przyczyn w CMMS pokrywa się z tym, co widać na wykresach (np. wzrost wibracji przed wymianą łożyska),
czy nie ma oczywistych rozbieżności czasowych między procesem a jakością.
Mit, że „AI zauważy rzeczy, których człowiek nie jest w stanie zobaczyć”, jest częściowo prawdziwy, ale pod jednym warunkiem: model musi startować z danych, które przechodzą podstawowy test spójności. Inaczej „odkryje” głównie artefakty błędów w rejestracji.
Ciągłe utrzymanie jakości danych: proces, nie jednorazowy projekt
Przygotowanie pierwszego zestawu danych do projektu AI jest trudne, ale jednorazowa akcja nie wystarczy. Zmienią się maszyny, surowce, ludzie, oprogramowanie PLC. Dane, które dziś są uporządkowane, za rok znów mogą się rozjechać.
Dlatego wraz z wdrażaniem AI pojawia się konieczność stałego procesu utrzymania jakości danych, obejmującego m.in.:
monitorowanie kompletności i spójności strumieni danych z maszyn,
procedury zgłaszania i dokumentowania zmian w konfiguracji,
okresowe przeglądy mapowania sygnałów między OT, MES, CMMS i systemami jakości,
mechanizmy automatycznego wykrywania nietypowych zachowań nie tylko w maszynach, ale też w samych danych (np. nagły spadek częstości próbkowania).
Zbudowanie prostego, ale konsekwentnego „data governance” dla danych z maszyn często decyduje, czy projekty AI da się skalować z jednej linii na cały zakład, a potem na kilka fabryk, czy każdy nowy model będzie powstawał od zera w swoim małym, nieporównywalnym świecie.
Najczęściej zadawane pytania (FAQ)
Jakie dane z maszyn są naprawdę potrzebne do wdrożenia AI w produkcji?
Najczęściej kluczowe są cztery grupy: dane procesowe (np. temperatura, ciśnienie, prądy silników, prędkości obrotowe), dane jakościowe (wyniki pomiarów, testów, systemów wizyjnych), dane zdarzeniowe (start/stop, alarmy, awarie, przezbrojenia, mikroprzestoje) oraz dane konfiguracyjne i kontekstowe (receptury, numer zlecenia, produkt, zmiana, operator). To dopiero ich połączenie pozwala modelowi powiązać zachowanie maszyn z jakością, awaryjnością czy wydajnością.
Mit brzmi: „im więcej danych, tym lepiej”. W praktyce ważniejsze od masy sygnałów jest to, czy są spójne w czasie, poprawnie opisane (awaria vs postój planowany) i powiązane z kontekstem procesu. Surowe, gęsto próbkowane dane procesowe plus proste, ale wiarygodne etykiety zdarzeń bywają cenniejsze niż pięknie „wypolerowane” wykresy z systemu SCADA.
Od czego zacząć wykorzystanie AI na hali produkcyjnej – od platformy, od danych czy od celu?
Najrozsądniejsza kolejność to: najpierw konkretny cel biznesowy, później sygnały z maszyn, architektura zbierania danych, przygotowanie danych, a dopiero potem dobór modelu AI i technologii wdrożenia. Inaczej łatwo skończyć z drogą platformą, która „czeka na dane”, a realnych decyzji nadal nikt nie podejmuje inaczej niż wcześniej.
Przykład: zamiast ogólnego hasła „chcemy AI w fabryce”, lepszym startem jest „chcemy zmniejszyć nieplanowane przestoje tej jednej kluczowej maszyny o kilka procent” albo „chcemy ograniczyć braki przy zmianach receptur na tej linii”. Dopiero pod taki cel dobiera się konkretne czujniki, sposób logowania danych i typ modelu (predykcja awarii, detekcja anomalii, model jakościowy).
Czym różni się zwykły dashboard od prawdziwego wykorzystania AI w produkcji?
Dashboard pokazuje, co się stało: trendy, wskaźniki, raporty z ostatniej zmiany czy tygodnia. To narzędzie do przeglądu historii. Algorytm AI idzie krok dalej – na podstawie danych z czujników i informacji kontekstowych proponuje, co zrobić teraz lub za chwilę: obniżyć temperaturę, zwolnić taśmociąg, zaplanować przegląd konkretnego silnika.
Mit: „jak mamy ładne wykresy, to już wykorzystujemy AI”. Rzeczywistość jest taka, że dopóki wynik analizy danych nie prowadzi do jasnej decyzji i działania (np. konkretnego zadania dla utrzymania ruchu lub zmiany ustawień maszyny), potencjał zostaje na poziomie „cotygodniowego spotkania z raportami”. AI ma skracać drogę od danych do decyzji, a nie tylko ozdabiać raporty.
Jakie realne problemy w fabryce można rozwiązać danymi z maszyn i AI?
Najczęściej pierwsze sukcesy dotyczą bardzo konkretnych obszarów: ograniczanie nieplanowanych przestojów kluczowych maszyn (predykcyjne utrzymanie ruchu), zmniejszanie braków przy zmianach receptur lub przezbrojeniach (modele jakościowe), stabilizacja zużycia energii przy szczytowym obciążeniu (modele optymalizujące parametry pracy) oraz automatyzacja żmudnych analiz danych (systemy, które same wyłapują wzorce zamiast ręcznego „przeklikiwania” Excela).
Na prostej linii pakującej można np. wykrywać wczesne oznaki zbliżającego się zacięcia na podstawie czasów przejazdu paczek między czujnikami i rozkładu odrzuceń z systemu wizyjnego. Zamiast reagować dopiero na zatrzymanie linii, operator dostaje sygnał: „za 10–15 minut ryzyko zacięcia wzrośnie, zrób krótką przerwę czyszczącą lub zwolnij taśmę dla tego produktu”.
Dlaczego podejście „najpierw kupmy AI, dane się później ogarnie” zwykle nie działa?
Modele predykcyjne i systemy detekcji anomalii są bardzo wrażliwe na jakość i spójność danych. Bez stabilnych pomiarów, jednolitych znaczników czasu oraz sensownie opisanych zdarzeń (awaria, postój planowany, zmiana receptury) algorytmy widzą szum, a nie wzorce. W efekcie system generuje albo losowe alarmy, albo „nic się nie dzieje” – obie wersje są bezużyteczne dla produkcji.
Rzeczywisty problem nie leży najczęściej w „słabym algorytmie”, tylko w tym, że dane są dziurawe, niespójne między maszynami, brakuje kontekstu (produkt, zmiana, operator). Dopiero gdy ten fundament jest uporządkowany, wybór konkretnej platformy AI ma sens i nie kończy się na serii PoC, które nigdy nie wchodzą do codziennej pracy.
Jak wygląda w praktyce pełna pętla: czujnik → model AI → decyzja → działanie?
Typowy przepływ jest prosty, ale musi być domknięty. Czujniki na maszynie zbierają sygnały (np. wibracje, temperaturę, prąd, pozycje elementów). System akwizycji zapisuje je z odpowiednią częstotliwością i dokładnym czasem. Model AI analizuje te dane na bieżąco, wykrywa odchylenia lub prognozuje awarie, a wynik jest prezentowany w zrozumiałej formie: alert na ekranie HMI, e‑mail, zadanie w CMMS lub sygnał do sterownika.
Kluczowy krok to reakcja: operator zmienia nastawy, utrzymanie ruchu planuje interwencję, a w bardziej zaawansowanych wdrożeniach sterownik sam koryguje parametry (zamknięta pętla sterowania). Jeśli model produkuje wyniki, których nikt nie ogląda albo nikt nie wie, co na ich podstawie zrobić, projekt zostaje w strefie „laboratoryjnego eksperymentu”, a nie realnego wsparcia decyzji na hali.
Czy do sensownego wykorzystania AI w zakładzie produkcyjnym potrzebna jest od razu „fabryka 4.0”?
Nie. Wizja w pełni autonomicznej „fabryki AI”, gdzie algorytmy sterują wszystkim od surowca po wysyłkę, to na razie głównie materiał marketingowy. W praktyce większość skutecznych wdrożeń zaczyna się od jednego procesu, kilku kluczowych maszyn i dobrze zawężonego problemu – np. konkretnego typu awarii lub wybranej przyczyny braków.
Mit: „albo mamy pełną transformację 4.0, albo nie ma sensu zaczynać”. Rzeczywistość: wystarczy stabilne zbieranie kilkunastu–kilkudziesięciu sygnałów z jednej linii, połączenie ich z danymi jakościowymi i kontekstem produkcji oraz jasno określona decyzja, którą chcemy usprawnić. Pierwsze realne oszczędności zwykle pojawiają się właśnie na takich „małych”, ale dobrze domkniętych projektach.
Najważniejsze wnioski
AI w produkcji ma sens wyłącznie wtedy, gdy przekłada się na twarde wskaźniki (OEE, braki, awaryjność, energia), a nie na „AI dla prestiżu” – celem jest lepsza decyzja na hali, nie kolejny projekt technologiczny.
Mit: „fabryka sterowana w 100% przez AI”. Rzeczywistość: skuteczne wdrożenia startują od jednego, dobrze zawężonego problemu (np. zacięcia na linii pakującej, skoki scrapu przy przezbrojeniu) i jednego konkretnego modelu.
Same dashboardy nie wystarczą – pokazują, co się stało, ale nie podpowiadają, co zrobić. Przewaga AI polega na tym, że na bazie danych z czujników sugeruje konkretną akcję przed wystąpieniem problemu (np. korekta temperatury, obniżenie prędkości, wcześniejszy przegląd).
Każdy projekt AI musi mieć jasno określonego „właściciela decyzji” – wiadomo, kto ma zareagować i na co. Jeśli nie da się wskazać osoby ani decyzji (operator, planista, UR, kierownik zmiany), ryzyko skończenia w szufladzie „fajny PoC” jest bardzo wysokie.
Mit: „najpierw kupmy platformę AI, dane się podłączą później”. Rzeczywistość: bez stabilnych sygnałów, spójnych timestampów, sensownych etykiet zdarzeń i kontekstu procesu nawet najlepsza platforma wygeneruje co najwyżej ładne wykresy.
Zdrowa sekwencja działań to: cel biznesowy → konkretne sygnały z maszyn → architektura zbierania danych → przygotowanie danych → dopiero wtedy dobór modelu i technologii wdrożenia (chmura, on‑prem, edge), zamiast odwrotnego podejścia „technologia najpierw”.
