Po co w ogóle przygotowywać dane z PLC i SCADA pod uczenie maszynowe
Dane dla operatora kontra dane dla modelu
Dane z PLC i SCADA były projektowane głównie po to, aby operator i automatyk mogli bezpiecznie prowadzić proces, a nie po to, aby trenować modele uczenia maszynowego. To kluczowa różnica. Ekran synoptyczny, trendy i alarmy muszą „tylko” umożliwić szybką reakcję człowieka. Model potrzebuje natomiast spójnego, opisowego, przewidywalnego strumienia liczb, który da się przełożyć na zjawiska procesowe.
Dlatego to, co z perspektywy sterowania działa świetnie (np. agresywna kompresja trendów, brak jednostek, brak pełnego opisu tagów), z perspektywy algorytmu bywa katastrofą. Człowiek domyśli się, że „T101.PV” to temperatura dolnej strefy pieca, zwykle między 600 a 800 stopni, a dziwne skoki wynikają z czyszczenia czujnika. Model takiej wiedzy nie ma – widzi jedynie ciąg liczb z czasem.
Jeśli dane zostaną „podane” modelowi w takim surowym, niespójnym kształcie, algorytm zacznie się uczyć przypadkowych zależności: zniekształceń archiwizacji, luk w rejestracji, błędów kalibracji. Z perspektywy produkcji oznacza to stratę czasu i budżetu na analitykę, która nie ma szans wejść na produkcję.
Jak słabe dane neutralizują nawet dobry algorytm
Wiele projektów AI w zakładach przemysłowych kończy się prezentacją „ładnych wykresów”, które nigdy nie trafiają do realnego sterowania czy systemów wspomagania decyzji. Technicznie modele działają, ale są oparte na zbyt losowych, nieopisanych danych. Przykładowo: model predykcji awarii łożysk silników zbudowany na sygnałach z SCADA, gdzie wartości prądów były logowane co minutę z kompresją deadband, a zdarzenia awarii oznaczano „na oko” z raportów utrzymania ruchu. Na danych historycznych wygląda to sensownie, ale po wdrożeniu sygnał prądu jest za rzadki i za zaszumiony, by wyłapać subtelne wzorce degradacji.
Najczęstszy wzorzec porażki wygląda tak:
Eksport „jak leci” setek tagów z historianu.
Trenowanie kilku modeli „co się uda”, bez jasnego celu.
Kilka początkowo obiecujących wykresów z korelacjami.
Problem przy próbie wdrożenia on-line: brak stabilnego, synchronicznego strumienia danych.
Projekt zostaje zamrożony z komentarzem „AI u nas nie działa”.
Prawie zawsze problemem jest nie sam algorytm, ale przygotowanie danych: brak spójnej osi czasu, brak jednoznacznego kontekstu procesowego, brak rzetelnych etykiet (co było awarią, co normalną pracą, co rozruchem).
Najczęstsze cele wykorzystania danych z PLC/SCADA w projektach ML
Aby wiedzieć, jak przygotować dane, trzeba najpierw wiedzieć, do czego będą użyte. W środowisku przemysłowym najczęściej spotyka się kilka rodzin zastosowań:
Predykcja awarii (predictive maintenance) – przewidywanie uszkodzeń maszyn na podstawie prądów, temperatur, wibracji, liczby cykli czy stanów alarmowych.
Optymalizacja sterowania – szukanie nastaw i strategii prowadzenia procesu, które minimalizują zużycie energii, surowców lub czas cyklu, przy zachowaniu jakości i bezpieczeństwa.
Detekcja anomalii – wykrywanie nietypowych stanów procesu, które nie zostały wcześniej opisane w klasycznych alarmach (np. powolne rozjeżdżanie się kalibracji czujnika).
Predykcja jakości produktu – przewidywanie parametrów jakościowych (wilgotność, wytrzymałość, barwa) na podstawie warunków procesu, zanim wynik pokaże laboratorium.
Każdy z tych celów wymaga innego zestawu zmiennych, innej granularności czasowej oraz innego podejścia do etykietowania danych (szczególnie w predykcji awarii i jakości). Zbieranie „wszystkiego co jest” zwykle kończy się problemem utrzymania i brakiem jasności, po co zbieramy konkretny tag.
Ograniczenia praktyczne: budżet, czas i dostęp do systemów
W wielu zakładach barierą nie jest technologia, tylko logistyka: ograniczone zasoby IT, brak admina SCADA na miejscu, polityka bezpieczeństwa, konieczność przechodzenia przez wielostopniowe zgody. Do tego dochodzi klasyczny problem: czas automatyka i technologa jest najdroższym zasobem.
Z tego powodu bardziej opłaca się zacząć od prostego, „budżetowego” podejścia: eksport danych z już istniejącego historianu lub raportów do plików i praca w ograniczonym zakresie, niż walczyć o wielomiesięczny projekt budowy data lake. Ważne, by architektura była rozszerzalna: żeby proste prototypy dało się potem płynnie przenieść do bardziej zaawansowanego środowiska, gdy pojawi się budżet i pozytywne wyniki.
Punkt startowy nie musi być idealny. Liczy się to, czy po kilku tygodniach da się odpowiedzieć na pytanie: „czy dane, które mamy, pozwalają zbudować choćby prosty, użyteczny model?”. Dopiero wtedy sensowne jest inwestowanie w rozbudowane integracje.
Rozpoznanie terenu – jak wyglądają dane w typowym systemie PLC/SCADA
Rodzaje tagów w praktyce produkcyjnej
W typowym systemie PLC/SCADA spotyka się kilka podstawowych grup tagów, które z perspektywy uczenia maszynowego zachowują się inaczej:
Tagi analogowe – temperatury, ciśnienia, przepływy, poziomy, prądy, napięcia, wibracje. Mogą być skalowane (np. 4–20 mA na wartość fizyczną) lub w surowych jednostkach. Są kluczowym źródłem dla większości modeli.
Tagi cyfrowe (binarne) – stany czujników, sygnały „start/stop”, tryby pracy, stany awaryjne. Są dyskretne, ale niezwykle cenne do nadawania kontekstu (np. czy linia pracowała, czy stała).
Liczniki i rejestry – zliczanie cykli, sztuk, godzin pracy, ilości medium. Często służą jako wejście do modeli wydajnościowych lub jako podstawa do inżynierii cech (np. liczba cykli od ostatniego serwisu).
Statusy i alarmy – informacje o przekroczeniu progów, awariach, blokadach. Dla modeli predykcyjnych i diagnostycznych są naturalnym kandydatem na etykiety zdarzeń.
Receptury i nastawy (setpointy) – zadane wartości temperatur, prędkości, ciśnień, przepływów. Niezbędne, jeśli model ma zrozumieć intencje sterowania, a nie tylko reakcje procesu.
Wiele tagów w systemach SCADA ma znaczenie wyłącznie wizualne lub pomocnicze (np. pozycje graficzne, wyniki pośrednich obliczeń dla ekranów). Dla modeli zwykle są to śmieci, które lepiej od razu odfiltrować.
Jak działa archiwizacja w SCADA/DCS
Systemy SCADA, DCS i dedykowane historiany stosują szereg mechanizmów, które są świetne dla operatorów, ale komplikują życie modelom:
Deadband – wartość jest zapisywana tylko wtedy, gdy zmiana przekroczy określony próg. Oszczędza to miejsce, ale powoduje nieregularne próbki i ukrywa drobne fluktuacje.
Kompresja – historyczny zapis jest dodatkowo „wygładzany”, aby zmniejszyć liczbę punktów. Drobne szumy i szybkie zmiany mogą być bezpowrotnie tracone.
Różne częstotliwości próbkowania – niektóre tagi są logowane co sekundę, inne co minutę, inne tylko „na zmianę wartości”. To tworzy duży problem przy późniejszej synchronizacji.
Model uczenia maszynowego preferuje ujednoliconą siatkę czasową (np. co 10 sekund lub co minutę). Historyczny zapis musi więc zostać przekształcony – przeważnie przez resampling i interpolację. Bez zrozumienia, jak SCADA zapisuje dane, łatwo popełnić błąd i uznać artefakty archiwizacji za realne zachowanie procesu.
Dane on-line, dane historyczne i raporty – co jest czym
W zakładzie zwykle funkcjonują trzy główne „warstwy” danych procesowych:
Dane on-line – aktualne wartości w PLC i SCADA, odświeżane często (np. co 100–500 ms). Są potrzebne do wdrożeń modeli w czasie rzeczywistym, ale do trenowania modeli offline zazwyczaj bardziej nadają się dane historyczne.
Dane historyczne – przechowywane w historianie SCADA, PI System, bazię SQL z logami, itp. To główne źródło do trenowania modeli ML, ponieważ obejmuje dłuższy okres i różne stany pracy.
Raporty (MES, SQL, CSV) – raporty produkcyjne, jakościowe, zużycia mediów. Często zawierają już zagregowane dane (np. na zmianę, na partię). Są nieocenione przy etykietowaniu danych (np. jakość partii, przyczyny przestojów).
Uczenie maszynowe wymaga zwykle połączenia kilku warstw: surowe sygnały procesowe z historianu, plus etykiety jakości, awarii czy wydajności z raportów. Kluczem jest znalezienie wspólnego mianownika: czas (timestamps), identyfikator partii, numer zlecenia, ID maszyny.
Typowe ograniczenia jakości danych z PLC/SCADA
Dane z PLC i SCADA są „prawdziwe”, ale nie zawsze „czyste”. Najczęstsze problemy:
Brak skalowania – sygnały w surowych jednostkach (np. 0–4095 z przetwornika A/C) bez mapy na wartości fizyczne.
Brak jednostek i opisów – nazwy w stylu „FIC101_PV” bez informacji, czy chodzi o przepływ masowy, objętościowy, parę czy powietrze.
Niestabilne sygnały – wahania wynikające z błędów czujników, zakłóceń, rozkalibrowania, które nie mają znaczenia dla operatora, ale mylą model.
Ręczne nadpisy operatorów – wartości wpisywane ręcznie (np. korekty jakości, ręczne nastawy) mogą być niespójne, bez historii kto/ kiedy/ dlaczego zmienił.
Bez przygotowania i udokumentowania takich artefaktów trudno jest budować wiarygodne modele. Z tego powodu dobrze jest poświęcić kilka dni na spokojny „przegląd terenu” zamiast od razu eksportować i trenować wszystko naraz.
Co trzeba mieć spisane, zanim ruszy się dalej
Najprostsze, a często najskuteczniejsze narzędzie to zwykły arkusz Excel z listą kluczowych tagów. Dobrze przygotowany arkusz powinien zawierać przynajmniej:
Nazwę taga (jak w SCADA/PLC).
Opis technologiczny (co to jest fizycznie).
Jednostkę i typ (analog, cyfrowy, licznik, alarm).
Zakres typowy i skrajny (wartości minimalne/maksymalne w normalnej pracy).
Źródło (który PLC, które urządzenie).
Miejsce przechowywania danych historycznych (historia w SCADA, baza SQL, raporty).
Taki „mini katalog tagów” jest bezcenny na każdym kolejnym etapie. Pozwala szybko stwierdzić, czy dane wyglądają wiarygodnie, oraz ułatwia komunikację między technologią, automatyką a zespołem data science.
Wybór źródeł danych i architektura minimalna pod projekty ML
Najtańszy scenariusz startowy: eksport do plików
Najprostszym i najtańszym sposobem, aby zacząć, jest korzystanie z eksportu danych z istniejącego historianu lub SCADA do plików – zwykle CSV lub, jeśli to możliwe, Parquet. W praktyce wygląda to tak:
Admin SCADA lub automatyk konfiguruje cykliczny eksport wybranych tagów (np. raz dziennie, raz na zmianę) do pliku CSV na serwerze.
Pliki są kopiowane w bezpieczne miejsce (np. wydzielony serwer analityczny lub zasób sieciowy).
Analityk/ML engineer pracuje na tych plikach w Pythonie, R lub innym narzędziu (Jupyter, VS Code, itp.).
Ograniczenia tego podejścia są oczywiste: brak danych prawie „na żywo”, możliwe opóźnienia, ręczne kroki. Jednak na etapie pilotażu z reguły wystarcza to w zupełności, a koszty wdrożenia takiego rozwiązania są minimalne – często sprowadzają się do jednorazowej konfiguracji eksportu.
Jeśli pliki CSV stają się kłopotliwe (duże rozmiary, powolne wczytywanie), można przejść na bardziej efektywne formaty kolumnowe (Parquet) lub prostą bazę danych (np. PostgreSQL), ale to nadal pozostaje w zasięgu rozsądnego budżetu.
Scenariusz „średni”: dedykowana baza pod dane procesowe
Kolejny krok to dedykowany serwer/baza danych pod projekty ML. Zamiast dziesiątek plików CSV, dane są przechowywane w ustrukturyzowanej formie, co ułatwia:
Współdzielenie danych między zespołami.
Budowę powtarzalnych pipeline’ów ETL.
Tworzenie widoków pod konkretne modele (np. połączonych z danymi jakościowymi).
Połączenie się z historianem i innymi źródłami
Przy bardziej zaawansowanych projektach sensownie jest zbudować trwałe połączenia z głównymi źródłami danych procesowych zamiast ręcznych eksportów. W praktyce oznacza to zwykle:
konektor ODBC/JDBC do bazy historianu lub PI System,
API (REST/SDK) do systemu MES/ERP po etykiety jakości i raporty,
połączenie do bazy SQL, gdzie lądują np. dane laboratoryjne,
opcjonalnie lekką integrację z OPC UA po dane on-line (gdy planowane jest wdrożenie modelu w RT).
Nie trzeba od razu stawiać rozbudowanej platformy integracyjnej. Często wystarczy jeden serwer w strefie IT, który ma:
dostęp „tylko do odczytu” do historianu i kilku baz SQL,
prostą aplikację (np. skrypty Pythona lub mały serwis), która cyklicznie pobiera nowe dane i zapisuje je w spójnym formacie,
dostęp dla zespołu analitycznego (VPN, RDP, Jupyter na serwerze).
Taka lekka integracja zwykle wystarcza na kilka pierwszych projektów. Na bardziej złożone rozwiązania (ESB, platformy IIoT) można się decydować dopiero wtedy, gdy pojawi się realne obciążenie – kilka modeli w produkcji, dużo linii, duża liczba użytkowników.
Minimalny „data lake” na potrzeby ML – wersja budżetowa
Z punktu widzenia uczenia maszynowego przydaje się jedno miejsce, gdzie lądują już oczyszczone i zintegrowane dane. Nie musi to być od razu chmurowy data lake z pełną orkiestracją. Na początek wystarczy:
jeden serwer plików (lub obiektowy storage on-prem/chmura) z ustaloną strukturą katalogów,
konwencja nazewnictwa plików (linia, zakres dat, typ danych),
prosty harmonogram (np. cron, Windows Task Scheduler) odpalający skrypty ETL.
Typowy, „tani” układ katalogów może wyglądać tak:
/raw/ – surowe eksporty z historianu, MES, laboratoryjnych CSV (tylko do odczytu, nic nie kasujemy),
/processed/ – dane po ujednoliceniu czasu, podstawowym czyszczeniu, scaleniu sygnałów,
/features/ – gotowe zestawy cech pod konkretne modele (np. „pred_awaria_prasy”, „pred_jakosc_partii”).
Nawet przy tak prostej architekturze łatwiej rozwijać kolejne modele. Zamiast za każdym razem łączyć się z production historianem, analityk korzysta z powtarzalnych, lokalnych zestawów danych, których przygotowanie jest zautomatyzowane.
Bezpieczeństwo i separacja OT/IT przy projektach ML
Przy integracji z PLC/SCADA często wyzwaniem nie jest technologia, tylko polityka bezpieczeństwa. Kilka pragmatycznych zasad pozwala uniknąć sporów z działem automatyki i cyberbezpieczeństwa:
modele i analizy działają wyłącznie w strefie IT, bez bezpośredniego dostępu do sieci PLC,
dane są ciągnięte z historianu lub pośredniej bazy, a nie bezpośrednio z kontrolerów,
proces jest jednokierunkowy: z OT do IT; żadne automatyczne komendy nie wracają do PLC bez osobnych uzgodnień,
dostępy są nadawane „tylko do odczytu”, z jasno określonym zakresem tagów.
Takie podejście uspokaja służby utrzymania ruchu – projekty ML nie dotykają logiki sterowania, a jedynie oglądają historię i stany pracy. Dopiero przy późniejszej automatyzacji zaleceń (np. wysyłanie rekomendacji do HMI) warto planować bardziej formalną integrację.
Źródło: Pexels | Autor: Markus Winkler
Jak wybrać właściwe sygnały z tysięcy tagów
Filtrowanie „śmieci” – prosty pre-filter oszczędzający tygodnie pracy
W dużej instalacji liczba tagów idzie w tysiące. Zostawienie wszystkiego „bo może się przyda” zwykle kończy się chaosem i przepełnionymi dyskami. Zanim zacznie się cokolwiek trenować, dobrze jest odsiać oczywiste śmieci. Kilka prostych kryteriów:
tagi czysto wizualne (położenie obiektów na ekranach, pomocnicze flagi HMI),
sygnały testowe, serwisowe, niewykorzystywane (stałe zera, brak historii),
logiczne kombinacje innych sygnałów (np. OR/AND alarmów), jeśli można je odtworzyć później,
tymczasowe tagi z kampanii uruchomieniowych, które już dawno nie są używane.
Taki „pre-filter” da się przygotować wspólnie z technologiem i automatykiem w jedno popołudnie, patrząc na ekran SCADA i katalog tagów. Oszczędza to potem dziesiątki godzin analiz danych, które z definicji nie wniosą niczego do modelu.
Mapowanie procesu na sygnały – od schematu P&ID do shortlisty tagów
Zamiast zaczynać od listy tagów, lepiej zacząć od schematu technologicznego (P&ID, layout linii). Dla każdego z głównych etapów procesu można zadać trzy pytania:
Co tu steruje procesem? (zawory, napędy, regulatory PID) – to kandydaci na tagi nastaw i sygnałów sterujących.
Co tu mierzymy? (temperatury, ciśnienia, poziomy, prądy silników) – to potencjalne zmienne wejściowe.
Jak oceniamy, że etap się udał/nie udał? (jakość, awaria, wydajność) – to kandydaci na etykiety i KPI.
Efektem jest krótka lista kilkudziesięciu–kilkuset tagów na start, zamiast kilku tysięcy. Resztę można dobierać stopniowo, kiedy analizy pokazują brakujące elementy (np. nie mamy informacji o otwarciu konkretnego zaworu).
Wybór sygnałów pod konkretny typ modelu
Dobór tagów zależy od tego, co model ma przewidywać. Kilka typowych scenariuszy:
Modele jakości partii – sygnały opisujące przebieg partii (temperatury, czasy etapów, przepływy, mieszanie), nastawy receptur, warunki otoczenia, wybrane alarmy i przestoje w trakcie partii.
Modele predykcyjnego utrzymania ruchu – wibracje, prądy, temperatury łożysk, liczniki cykli, liczba start/stop, warunki pracy (obciążenie, prędkość), zdarzenia serwisowe.
Modele zużycia mediów/energii – liczniki zużycia, obciążenia silników, tryb pracy, tempo produkcji, typ produktu.
Da się zastosować prostą zasadę: jeśli technolog lub automatyk nie jest w stanie powiedzieć, w jaki sposób dany tag mógłby wpłynąć na cel modelu, sygnał ląduje na liście „do późniejszego rozważenia”, a nie w pierwszej wersji datasetu.
Szybki przegląd statystyk – odsianie martwych i podejrzanych tagów
Po wstępnym wyborze tagów przydaje się krótki etap „screeningu” w Pythonie/R. Dla każdego sygnału można policzyć proste statystyki, które odsiewają kolejne problemy:
procent czasu z wartością stałą (np. 0 lub 1),
liczbę unikalnych wartości (skrajnie mała liczba przy sygnale analogowym bywa podejrzana),
procent braków (NaN) i wartości poza typowym zakresem,
częstotliwość zmiany dla sygnałów, które teoretycznie powinny się ruszać.
Taki skrypt można napisać raz, a potem uruchamiać na kolejnych projektach. Wynikowe tabelki pomagają zdecydować, które tagi wyrzucić, a które wymagają wyjaśnień z technologiem („dlaczego ta temperatura jest od miesięcy idealnie płaska?”).
Na start lepiej mieć za mało, ale dobrze rozumianych sygnałów niż przyduszający model nadmiarem danych. Praktyczny schemat:
Budowa pierwszego, prostego modelu na podstawowym zestawie tagów.
Analiza ważności cech (feature importance, SHAP, itp.) i błędów modelu.
Dołożenie nowych sygnałów tylko tam, gdzie błędy wskazują braki (np. brak informacji o trybie maszyny, zmianie operatora, przepływie pomocniczym).
Każda iteracja jest szybka i tania. Dopiero gdy kolejne modele wciąż nie osiągają sensownych wyników, warto zainwestować czas w trudniejsze integracje (np. dodatkowe czujniki, szczegółowe dane laboratoryjne, dane z systemów zewnętrznych).
Czas, synchronizacja i próbkowanie – fundament danych pod modele
Jedna oś czasu dla wszystkich źródeł
Uczenie maszynowe nie lubi niespodzianek w czasie. PLC, SCADA, MES, LIMS, ERP – każdy system może mieć własne zegary i formaty timestampów. Pierwszym krokiem jest ujednolicenie strefy czasowej i formatu:
wybór jednej strefy (często UTC lub czas lokalny bez DST dla analiz historycznych),
konwersja wszystkich timestampów do jednego standardu (np. ISO 8601),
usunięcie podwójnych godzin przy zmianie czasu, jasne oznaczenie luk.
Jeśli zakład działa w kilku strefach lub ma złożone przełączenia czasu letni/zimowy, najbezpieczniej jest w warstwie analitycznej trzymać się UTC, a czas lokalny przeliczać tylko dla raportów dla ludzi.
Dobór kroku czasowego pod model – nie zawsze „im gęściej, tym lepiej”
W historianie część sygnałów jest zapisywana co sekundę, część co minutę, część tylko przy zmianie. Modele zwykle wymagają regularnej siatki czasowej. Typowe podejście:
wybór kroku bazowego (np. 1 s, 5 s, 10 s, 1 min) w zależności od dynamiki procesu,
resampling wszystkich sygnałów do tego kroku,
zapis wyników jako nowej, „modelowej” wersji danych.
Dla powolnych procesów ciągłych (chemia, energetyka) często wystarczy krok 30–60 s. Dla szybkich maszyn pakujących czy pras mechanicznych czasem potrzebne jest 100–200 ms, ale to rzadziej dotyczy pierwszych projektów. Zbyt gęsty sampling powoduje gigantyczne pliki i spowalnia trening bez proporcjonalnego zysku w jakości modelu.
Resampling i interpolacja – jak nie wyprodukować sztucznych danych
Przy resamplingu trzeba dobrać metodę agregacji do natury sygnału:
dla sygnałów „ciągłych” (temperatury, ciśnienia) – średnia lub mediana w oknie czasowym często dobrze oddaje stan,
dla liczników rosnących (np. liczba sztuk, zużycie energii) – suma przy agregacji do większych okien, a przy wysokiej rozdzielczości można operować na przyrostach,
dla sygnałów binarnych – większość czasu w stanie 0/1, ewentualnie liczba przełączeń w oknie,
dla statusów/trybów – ostatnia wartość w oknie (forward fill), bo status zwykle obowiązuje aż do zmiany.
Interpolację między punktami trzeba stosować z głową. Dla sygnałów fizycznie ciągłych liniowa interpolacja ma sens. Natomiast nie interpoluje się:
alarmów i statusów (lepiej zostawić je jako zdarzenia),
liczników całkowitych (zamiast tego operować na przyrostach),
wartości jakości/klasyfikacji (np. wyniki laboratoryjne).
Synchronizacja między systemami – jak skleić historian, MES i jakość
Gdy dane pochodzą z wielu systemów, brakuje często wspólnego klucza innego niż czas. Typowe przypadki:
dane jakości partii z LIMS/MES z timestampem „czas poboru próbki”,
dane o awariach i przestojach z systemu utrzymania ruchu z czasem rozpoczęcia i zakończenia zdarzenia,
raporty produkcyjne z ERP z czasami realizacji zlecenia.
Praktyczne techniki łączenia:
join po najbliższym czasie – np. dopasowanie wyniku jakości do stanu procesu 5–10 minut przed pobraniem próbki,
join po przedziale – dla zdarzeń trwających w czasie (awarie, przestoje) przypisanie im wszystkich punktów z historianu, które wpadły w dany przedział,
join po identyfikatorze partii – jeśli MES nadaje ID partii, a SCADA zapisuje je jako tag w czasie produkcji.
Tutaj często wychodzi na jaw, czy w systemie dobrze skonfigurowano identyfikatory partii i zleceń. Czasem wystarczy dodać jeden tag w SCADA (np. aktualny numer zlecenia) i zacząć go archiwizować, by znacznie uprościć późniejsze łączenie danych.
Okna czasowe i opóźnienia – przygotowanie danych sekwencyjnych
Duża część modeli procesowych bazuje na sekwencjach: model nie patrzy tylko na bieżący punkt, ale na historię pewnej długości. Trzeba więc zdefiniować:
Dobór długości okna i horyzontu predykcji
Przy danych sekwencyjnych kluczowe są dwa parametry:
długość okna wejściowego – ile czasu wstecz model „widzi” (np. 5, 30, 120 minut),
horyzont predykcji – na jak długo naprzód ma przewidywać (np. za 5 minut, za godzinę, do końca partii).
Te wartości nie biorą się z sufitu. Dobry punkt startowy to czas reakcji procesu znany technologom: ile trwa, zanim zmiana nastawy przełoży się na stabilizację temperatury, poziomu czy jakości. Dla wolnych pieców można patrzeć na kilka godzin wstecz, dla szybkich linii pakujących często wystarczy kilka–kilkanaście minut.
W praktyce opłaca się przygotować dane tak, aby długość okna była parametrem konfigurowalnym (np. generować cechy typu „średnia z ostatnich X minut”, gdzie X można łatwo zmienić w skrypcie). Pozwala to testować różne warianty bez ponownego zgrywania danych z historianu.
Lagowanie sygnałów – opóźnienia fizyczne i czas próby
Fizyczny proces prawie nigdy nie reaguje natychmiast. Między zmianą zaworu a zmianą jakości na końcu linii może minąć kilkanaście minut. To opóźnienie trzeba odzwierciedlić w danych:
dla modeli regresyjnych/tablicowych – dodawanie cech opóźnionych (lagów), np. temperatura sprzed 5, 10, 20 minut,
dla modeli sekwencyjnych (LSTM, 1D-CNN) – odpowiednie przesunięcie etykiety względem okna wejściowego.
W prostych projektach wystarczy kilka ręcznie dobranych lagów (np. 5, 15, 30 minut). Bardziej wyrafinowane strojenie można zostawić na później. Lepiej mieć 3–4 dobrze przemyślane opóźnienia niż 50 losowych kolumn „lag_1…lag_50”, które tylko spowalniają trening.
Okna kroczące vs. próbkowanie co partię/cykl
Dane można ciąć na dwa główne sposoby:
okna kroczące – każde okno to osobna próbka (np. 30 minut historii co 5 minut),
agregacja po partii/cyklu – jedna próbka na partię, cykl maszyny, zlecenie.
Okna kroczące generują dużo danych, ale wymagają więcej mocy obliczeniowej i sprytniejszej walidacji (żeby okna treningowe nie przeciekały w czas do testowych). Agregacja po partii jest znacznie tańsza obliczeniowo i często wystarcza na początek przy modelach jakości. Rozsądnym podejściem jest rozpoczęcie od prostych cech „na partię” (średnie, min/max, czas trwania) i dopiero przy ograniczeniach takiego modelu przejście do pełnych sekwencji.
Czyszczenie danych procesowych: luki, błędy, ręczne nadpisy
Identyfikacja typów braków i anomalii w danych
W danych z PLC/SCADA występuje kilka powtarzalnych klas problemów:
luki w czasie (brak zapisów przez dłuższy okres),
wartości skrajne lub fizycznie niemożliwe (np. -100 °C na czujniku wody),
ręczne nadpisy (force w PLC, ręczne wpisy w SCADA),
flagi błędu i jakości (Bad/Uncertain, status czujnika),
martwe sygnały (ciągłe 0 lub stała wartość przez miesiące).
Zanim zacznie się je automatycznie „naprawiać”, opłaca się przygotować prosty raport diagnostyczny: ile punktów danego typu problemu przypada na każdy tag. To często zamyka temat kilkoma szybkimi decyzjami (np. „ten czujnik był odłączony cały rok, wyrzucamy” zamiast budowania skomplikowanej interpolacji).
Luki w danych – kiedy wypełniać, a kiedy wycinać
Luki można traktować na trzy sposoby:
ignorować całe okresy – jeśli brakuje kluczowych sygnałów przez dłuższy czas (np. awaria serwera historianu), lepiej wyciąć ten fragment z datasetu,
interpolować krótkie przerwy – przy procesach wolnozmiennych kilkusekundowe czy kilkuminutowe dziury można wypełnić liniowo,
zastępować wartościami „technicznymi” (np. NaN) – gdy brak wynika ze stanu maszyny (postój, czyszczenie) i sam w sobie jest informacją.
Dobry, tani kompromis: ustalić maksymalną akceptowalną długość luki do interpolacji (np. 2–5 interwałów próbkowania). Krótsze luki są wypełniane, dłuższe powodują wycięcie okna lub partii z treningu. Unika się w ten sposób tworzenia długich odcinków „sztucznych” danych tylko po to, by nie mieć kilku NaN w tabeli.
Wykrywanie i obsługa wartości nierealnych
Większość sygnałów procesowych ma znany, fizyczny zakres. Wykorzystanie go jest jedną z najtańszych metod czyszczenia:
zdefiniowanie dla każdego tagu zakresu akceptowalnych wartości (np. z P&ID, kart katalogowych, nastaw alarmów w SCADA),
zamiana wartości poza zakresem na NaN lub specjalną flagę,
opcjonalnie: oznaczanie okolicznych punktów jako podejrzanych (np. po dużym skoku).
Przy pierwszym projekcie nie ma sensu tworzyć superdokładnych progów dla setek tagów. Wystarczą proste limity typu „poniżej zera → błąd” albo „powyżej maksymalnego alarmu → NaN”. Szczegółowe dostrajanie można robić tylko dla kluczowych czujników, gdy model wyraźnie się na nich „wywraca”.
Flagi jakości danych i statusy czujników
Wielu producentów PLC/SCADA umożliwia zapisywanie jakości danych razem z wartością (Good/Bad/Uncertain). Ta informacja często jest ignorowana przy raportach, ale dla modeli jest bardzo użyteczna:
punkty „Bad” można bez wahania usuwać lub zamieniać na NaN,
punkty „Uncertain” można zachować, ale dodać osobną cechę binarną typu „measurement_uncertain”,
długie ciągi „Bad” traktować jak luki w danych.
Jeśli system źródłowy nie zapisywał flag jakości, da się je z grubsza odtworzyć prostymi regułami (np. „jeżeli temperatura nagle skacze o kilkaset stopni i wraca po sekundzie, oznacz jako Bad”). Tworzenie takiej „pseudo-flagi” dla kilku kluczowych tagów zwykle poprawia jakość danych bardziej niż kolejne godziny interpolacji.
Ręczne nadpisy i force w PLC
Ręczne nadpisy to cichy zabójca modeli. Podczas testów instalacji, obejść awaryjnych czy prób technologicznych wartości tagów mogą być ustawiane na sztywno, niezależnie od rzeczywistego procesu. Jeśli te okresy trafią do treningu bez oznaczenia, model będzie się uczył zachowań, które nigdy nie występują w normalnej pracy.
Prosty, niskokosztowy sposób ograniczenia ryzyka:
jeżeli system pozwala – archiwizować tag stanu „force/manual” dla kluczowych sygnałów,
w danych analitycznych usuwać okresy, gdy sygnał był w trybie force, lub oznaczać je binarną cechą „forced=1”,
w przypadku braku takiego tagu – szukać podejrzanie idealnie płaskich odcinków w sygnałach, które w normalnej pracy delikatnie „pływają”.
Już samo dodanie jednego wspólnego sygnału „tryb pracy (AUTO/MANUAL)” dla linii i zapisanie go w historianie potrafi w kilku projektach zwrócić się wielokrotnie w postaci prostszego czyszczenia i lepszych modeli.
Postoje, rozruchy i stany niestabilne
Dane z okresów postoju czy rozruchu mają zupełnie inną charakterystykę niż praca ustalona. Dla wielu przypadków biznesowych (np. prognoza jakości przy pełnej produkcji) włączanie ich do treningu tylko zwiększa szum.
Najtańsza metoda radzenia sobie z tym problemem to tag „tryb procesu”, wyliczany choćby bardzo prosto:
„STOP” – produkcja = 0, napędy w bezruchu,
„RAMP-UP/RAMP-DOWN” – zmienna prędkość, częste zmiany nastaw,
„STEADY” – stabilna produkcja, parametry w okolicach zadanych.
Taki tryb można obliczyć offline ze znanych sygnałów (np. prędkość linii, stan głównego napędu). Przy budowie datasetu pod model jakości pierwszym filtrem jest zazwyczaj odrzucenie wszystkiego poza „STEADY”. Dopiero jeśli pojawia się potrzeba modelowania właśnie rozruchów (np. optymalizacja ich czasu), przygotowuje się osobny zbiór danych tylko z tych okresów.
Normalizacja wartości a stabilność modeli
Większość modeli numerycznych lepiej działa na danych zgrubnie znormalizowanych. Nie trzeba od razu wdrażać wymyślnych metod – w zupełności wystarczą:
standaryzacja (odjęcie średniej, podzielenie przez odchylenie) dla sygnałów o mniej więcej stałej wariancji,
skalowanie do zakresu (np. 0–1) dla liczników, przepływów, zużyć.
Ważniejsza od wyboru konkretnej formuły jest spójność: parametry normalizacji (średnie, odchylenia, minima, maksima) muszą być policzone na zbiorze treningowym i zapisane, aby używać dokładnie tych samych wartości przy inferencji na produkcji. Najprostszy sposób to mały plik konfiguracyjny (JSON, YAML) generowany razem z datasetem i dołączany do paczki modelu.
Bez prostej dokumentacji łatwo wpaść w pułapkę: „nie wiemy już, co zrobiliśmy z tymi danymi rok temu”. Nie trzeba od razu budować katalogów danych klasy enterprise. Wystarczy kilka lekkich praktyk:
skrypt ETL w repozytorium (Git) jako jedyne źródło prawdy o tym, jak powstał dataset,
krótki plik README z wypunktowanymi decyzjami typu „wycięto okres X–Y z powodu awarii historianu”,
wersjonowanie plików z danymi wejściowymi/wyjściowymi przynajmniej na poziomie dataset_v1.h5, dataset_v2.h5.
Taki „budżetowy” data lineage rozwiązuje 80% typowych problemów przy ułamku kosztu dużych platform. Gdy projekty ML zaczną się mnożyć, zawsze można go rozbudować – najważniejsze, by nie startować od zera za każdym razem.
Kluczowe Wnioski
Dane z PLC/SCADA są projektowane pod potrzeby operatora, a nie algorytmu – bez doprecyzowania jednostek, opisów tagów i kontekstu procesowego model będzie uczył się losowych zniekształceń zamiast realnego zachowania instalacji.
Nawet dobry algorytm nic nie da, jeśli zasilimy go niespójnymi i słabo opisanymi danymi: brak wspólnej osi czasu, rzadkie logowanie z kompresją czy „na oko” oznaczane awarie skutecznie zabijają szanse na wdrożenie modelu on-line.
Masowe zrzucanie „wszystkich tagów z historianu” bez jasno zdefiniowanego celu kończy się zwykle prezentacją ładnych wykresów, których nie da się przełożyć na stabilne działanie w rzeczywistym sterowaniu.
Konkretny cel biznesowy (predykcja awarii, optymalizacja sterowania, detekcja anomalii, predykcja jakości) determinuje dobór zmiennych, rozdzielczość czasową i sposób etykietowania – inaczej buduje się dataset pod utrzymanie ruchu, a inaczej pod poprawę jakości.
Lepsze jest szybkie, „budżetowe” podejście (eksport z istniejącego historianu, proste pliki), które po kilku tygodniach pozwala sprawdzić, czy da się zbudować choć prosty model, niż wielomiesięczna budowa idealnego data lake bez gwarancji efektu.
Architektura zbierania danych powinna być rozszerzalna: najpierw ma obsłużyć tani prototyp, a dopiero po potwierdzeniu wartości biznesowej skalować się do bardziej zaawansowanych integracji i infrastruktury.
