Przewodnik po danych procesowych: zrozumieć OPC UA, historię danych i potrzeby modeli AI

Dane procesowe jako fundament AI w przemyśle

Różnica między danymi procesowymi a biznesowymi

Dane biznesowe to najczęściej zamknięte zdarzenia: dokument sprzedaży, faktura, zlecenie, rekord w CRM. Zmieniają się stosunkowo rzadko, są dobrze opisane i mają wyraźne klucze (ID, numery zamówień). Dane procesowe działają inaczej – są ciągłe, napływają w sposób strumieniowy i są niemal zawsze osadzone w czasie.

W danych procesowych czas jest pierwszorzędnym wymiarem. Każda próbka ma znacznik czasu, a kolejność występowania ma znaczenie większe niż sam poziom wartości. Liczy się kształt przebiegu, trend, dynamika. Dodatkowo ważna jest ciągłość i gęstość próbkowania: czasem próbka pojawia się co 100 ms, czasem co minutę, a czasem tylko przy zmianie stanu.

Dane biznesowe są zwykle przechowywane w relacyjnych bazach danych, natomiast dane procesowe często trafiają do historianów lub baz time-series. Modele AI, które mają wspierać produkcję, muszą poruszać się po obu tych światach jednocześnie, ale to właśnie dane procesowe determinują, czy system będzie w stanie reagować na bieżącą sytuację technologii.

Główne źródła danych procesowych

W typowym zakładzie przemysłowym dane procesowe pojawiają się w wielu warstwach. Źródła najczęściej spotykane w projektach AI to:

• PLC (Programmable Logic Controllers) – sterowniki bezpośrednio obsługujące sygnały z czujników i do siłowników. To najbliższa warstwa fizycznego procesu. Dane są surowe, szybkie, często o wysokiej częstotliwości.
• SCADA/HMI – systemy wizualizacji i nadzoru. Zbierają dane z wielu PLC, standaryzują je, dodają alarmy, stany, sygnały sterujące. Dane mają już pewien kontekst operacyjny.
• DCS (Distributed Control System) – stosowane często w chemii, energetyce, rafineriach. Integrują wiele pętli regulacji, logikę sekwencyjną, zaawansowaną automatykę. Dane z DCS są bogate w informację o stanie procesu i algorytmach regulacji.
• MES – system realizacji produkcji. Łączy dane procesowe z kontekstem zleceń, partii, receptur. Przechowuje informacje o przestojach, przyczynach awarii, zmianach operatorów.
• IoT / sensory sieciowe – dodatkowe czujniki montowane np. na łożyskach, silnikach, instalacjach. Zbierają wibracje, temperatury, ciśnienia, dane z kamer czy mikrofonów. Często komunikują się po MQTT, REST, OPC UA lub własnych protokołach.

Źródła te rzadko są od razu spójne. Część danych płynie klasycznym OPC, część OPC UA, część przez dedykowane gatewaye. Projektant rozwiązań AI musi zrozumieć, na którym poziomie „odciąć” dane: czy bliżej PLC (więcej szczegółów, większy wolumen), czy raczej bliżej MES (większy kontekst, mniej hałasu).

Typowe zastosowania AI wykorzystujące dane procesowe

Dane procesowe w połączeniu z historią zdarzeń otwierają szereg konkretnych scenariuszy. Najczęściej spotykane to:

• Predykcyjne utrzymanie ruchu (predictive maintenance) – przewidywanie awarii maszyn na podstawie wibracji, temperatur, prądów silników, liczby cykli. Wymaga długiej historii i dobrej jakości sygnałów z czujników.
• Optymalizacja parametrów procesu – dobór nastaw (setpointów), prędkości linii, temperatur, ciśnień tak, aby utrzymać jakość produktu i jednocześnie zminimalizować zużycie energii czy surowców. AI musi tu korzystać z historii i z bieżącego stanu pętli regulacji.
• Detekcja anomalii – wychwytywanie nietypowych wzorców pracy, które jeszcze nie są awarią, ale mogą do niej prowadzić. Modele uczą się „normalnego” przebiegu sygnałów i oznaczają odchylenia.
• Soft-sensory (wirtualne czujniki) – estymacja wielkości, których nie da się łatwo zmierzyć (np. skład chemiczny, stopień zużycia), na podstawie innych sygnałów procesowych i wyników jakości.

Każde z tych zastosowań stawia nieco inne wymagania wobec danych: predykcja awarii turbiny będzie potrzebowała wysokiej częstotliwości i danych wibracyjnych, a optymalizacja pieca do wypału – długich trendów temperatur, przepływów i składu wsadu.

Ilość danych kontra jakość i kontekst

Duża liczba tagów w historianie nie oznacza jeszcze, że zakład jest gotowy na AI. Liczy się przede wszystkim:

• Stabilność źródeł – czy sygnały nie znikają, nie resetują się, czy znaczniki czasu nie „skaczą” o minuty lub godziny.
• Spójność jednostek i zakresów – ten sam typ sygnału powinien być mierzony w tych samych jednostkach i sensownych zakresach (np. °C vs K, bar vs kPa).
• Kontekst procesowy – dane z czujników muszą być powiązane z informacją, co było produkowane, jaką recepturą, na której linii, w jakim trybie pracy.
• Jakość sygnału – konieczna jest informacja, czy próbka jest ważna: sygnały „Bad”, „Uncertain”, ręczne nadpisania, tryby serwisowe.

Modele AI „zatruwają się” chaotycznymi, nieoznaczonymi zmianami w konfiguracji, brakami w sygnałach i błędną synchronizacją czasu. Zwykle większy efekt przynosi uporządkowanie kilkuset dobrze opisanych tagów niż zassanie setek tysięcy punktów bez kontekstu.

Krótkie wprowadzenie do OPC UA z perspektywy danych

Rola OPC UA w warstwie OT

OPC UA to standard komunikacji, który zastąpił starszy OPC DA/AE/HD oparty o COM/DCOM. Najważniejsza zmiana z perspektywy danych procesowych: OPC UA nie jest tylko „rurą do wartości”. Zawiera model informacyjny, który pozwala opisać strukturę obiektów technologicznych, ich atrybuty, relacje i metadane.

OPC UA pracuje niezależnie od platformy i systemu operacyjnego. Może działać w sterowniku, gatewayu, serwerze SCADA lub w chmurze. Dzięki temu staje się warstwą integracyjną między OT i IT. Dla modeli AI oznacza to potencjał dostępu do danych w sposób ustrukturyzowany, z opisem, a nie tylko po numerach rejestrów PLC.

W projektach przemysłowych OPC UA często jest punktem, w którym system AI „wpina się” w linię produkcyjną: subskrybuje wybrane zmienne, zbiera dane i wysyła rekomendacje lub nastawy z powrotem, z zachowaniem bezpiecznego zakresu sterowania.

Model informacyjny OPC UA: węzły i zmienne

W OPC UA wszystko jest węzłem (Node). Istnieją różne typy węzłów, m.in. obiekty, zmienne, typy danych, metody. Z punktu widzenia danych procesowych kluczowe są:

• Variable Nodes – reprezentują zmienne procesowe, stany, liczniki, parametry konfiguracji.
• Object Nodes – grupują zmienne wewnątrz obiektu technologicznego (np. silnik, pompa, linia produkcyjna).
• DataType Nodes – opisują typ danych, w tym typy złożone, struktury, wyliczenia.
• Reference Nodes – relacje między obiektami (część, należy do, powiązany z).

Przestrzeń adresowa OPC UA jest hierarchiczna i bogatsza niż klasyczne „tagi” w SCADA. Dobry serwer OPC UA może wystawić dane tak, że można np. odczytać wszystkie parametry danego silnika jako jedną strukturę, zamiast szukać pojedynczych nazw. Dla AI ułatwia to budowanie zrozumiałych featurów oraz automatyczne wykrywanie powiązań między sygnałami.

Subskrypcje, odczyty „on demand” i publish/subscribe

Z perspektywy integracji danych z OPC UA istnieją trzy główne mechanizmy:

• Odczyty na żądanie (Read) – klient pyta serwer o aktualną wartość zmiennej w danym momencie. Proste, ale przy większej liczbie tagów może przeciążyć serwer i sieć.
• Subskrypcje (Subscriptions, Monitored Items) – klient rejestruje zainteresowanie zestawem zmiennych. Serwer wysyła aktualizacje, gdy wartość się zmieni, lub w zadanym odstępie. To podstawowy mechanizm strumieniowania danych do AI.
• Model publish/subscribe (PubSub) – dane są rozgłaszane na kanałach (np. UDP, MQTT). Klienci je subskrybują, często bez bezpośredniego połączenia klient–serwer. Dobre rozwiązanie do szerszych architektur z brokerem danych.

Dla projektanta pipeline’u danych ważne są parametry subskrypcji: publishing interval, filtrowanie po zmianie wartości, limity bufora, priorytety. Zbyt gęsty interwał i brak filtracji po zmianie może „zatopić” zarówno serwer OPC UA, jak i dalsze elementy systemu AI.

Ograniczenia i pułapki wykorzystania OPC UA

OPC UA jest elastyczny, ale nie jest darmowy zasobowo. Typowe problemy, które wychodzą przy projektach AI:

• Zbyt wysoka częstotliwość odczytu – próbkowanie co 100 ms dla setek tagów z kilku serwerów może przekroczyć możliwości sieci i CPU serwera.
• Wąskie gardła na serwerze – niektóre implementacje OPC UA w PLC mają ograniczoną liczbę jednoczesnych subskrypcji lub zbyt małe bufory.
• Brak standaryzacji nazw – różne linie opisane inaczej, mimo że technologicznie są podobne. To komplikuje budowę skalowalnych modeli AI.
• Niespójne znaczniki czasu – część serwerów korzysta z czasu PLC, inne z czasu systemowego, bez synchronizacji NTP. Rezultatem są przesunięcia między sygnałami.

Przy planowaniu integracji warto przeprowadzić test wydajnościowy: stopniowo zwiększać liczbę subskrybowanych tagów i częstotliwość, obserwując opóźnienia i wykorzystanie zasobów. Dobrą praktyką jest też wstępne filtrowanie sygnałów po stronie serwera (np. wyłączenie tagów serwisowych, rzadko używanych).

Historian i archiwa danych procesowych – jak naprawdę działają

Rola historianów w ekosystemie danych

Historian to wyspecjalizowany system do zbierania i przechowywania danych procesowych w czasie. Przykłady to OSIsoft PI, Honeywell PHD, Aspen IP.21, a także nowsze bazy time-series jak InfluxDB czy TimescaleDB. Ich podstawowe zadania:

• zebrać dane z wielu źródeł (OPC, OPC UA, Modbus, MQTT, SCADA),
• zapisać je efektywnie z użyciem kompresji i indeksowania po czasie,
• udostępnić je do raportowania, analizy, modeli AI.

Historian jest zwykle centralnym punktem, w którym gromadzi się historia kilku–kilkunastu lat pracy instalacji. Modele AI do predykcji awarii czy optymalizacji często buduje się właśnie na tej długiej historii, a bieżące decyzje opiera na kombinacji danych „live” z OPC UA i danych historycznych z historiana.

Strategie zapisu w historianie

To, jak dane trafiają do historiana, ma ogromny wpływ na ich użyteczność. Stosuje się trzy podstawowe strategie:

• On-change – zapis tylko wtedy, gdy wartość zmieni się o więcej niż zadany próg (deadband). Dobrze redukuje objętość przy sygnałach powoli się zmieniających.
• Cyklicznie – zapis co określony interwał czasu (np. co 1 s, 10 s, 1 min). Zapewnia równomierny szereg czasowy, ale może marnować miejsce przy sygnałach „płaskich”.
• Event-based – zapis przy konkretnym zdarzeniu (np. start/stop linii, zmiana trybu, wygenerowanie alarmu). Dobrze nadaje się do logów i stanów.

W praktyce łączy się te podejścia. Dla kluczowych sygnałów procesowych stosuje się zapis „on-change” z małym progiem i minimalną częstotliwością (np. nie częściej niż co 200 ms). Dla sygnałów powolnych – zapis co kilka sekund lub minut. Sygnały stanów i alarmów loguje się zdarzeniowo.

Projektowanie tej strategii powinno być robione świadomie, najlepiej razem z zespołem AI. Zbyt silna kompresja lub za duże interwały zapisów sprawią, że przebieg sygnału zostanie „spłaszczony” i model straci istotne informacje, np. krótkie oscylacje czy wahania.

Agregacje historyczne i ich wpływ na modele

Historiany oferują gotowe funkcje agregacji: średnie, minimum, maksimum, odchylenie standardowe, interpolacje. To wygodne w raportowaniu, ale bywa pułapką dla AI. Różnica między pracą na surowych próbkach a na agregatach jest zasadnicza.

Typowe typy agregacji to:

• Time-weighted average – średnia ważona czasem, bazująca na liniowej interpolacji między punktami.
• Minimum/maximum z danego okna czasowego.
• Interpolacja liniowa – wartości „pomiędzy” rzeczywistymi próbkami.
• Count, sum – liczba lub suma próbek z danego okresu.

Skutki korzystania z agregatów zamiast danych surowych

Jeśli dane z historiana są pobierane wyłącznie jako agregaty, modele AI „widzą” wygładzony, uśredniony świat. To często zbyt mało, aby wykryć subtelne symptomy awarii czy rozjeżdżania się procesu.

Typowe skutki nadmiernego polegania na agregatach:

• Utrata dynamiki – w 1‑minutowych średnich zanikają szybkie fluktuacje, które poprzedzają drgania czy niestabilność pętli PID.
• Fałszywe korelacje – dwa sygnały wyglądają podobnie po uśrednieniu, choć w rzeczywistości przesunięcie fazowe między nimi jest istotne.
• Spłaszczona zmienność – odchylenie ze średnich jest inne niż odchylenie na próbkach surowych, model mylnie ocenia ryzyko.

Częsta praktyka: do trenowania modeli wykorzystuje się dane surowe lub minimalnie przetworzone, a do wizualizacji i raportów – agregaty. Ułatwia to diagnozowanie, gdzie model „coś zobaczył”, bez rezygnacji z bogactwa informacji w sygnale.

Jakość danych w historianie: luki, flagi i rekonstrukcja

Historian przechowuje nie tylko wartości, ale też statusy jakości, czasem dodatkowe flagi (np. „Manual”, „Substituted”). Przy integracji pod AI te informacje często giną po drodze.

Typowe problemy w danych historycznych:

• Luki w danych – awaria sieci, restart serwera, przepełnienie bufora. Na wykresie to „dziury”, które dla modelu są niewidoczne, jeśli zostaną niejawnie zinterpolowane.
• Manualne nadpisania – operator wpisuje wartość ręcznie, ale flaga „Manual” nie jest przenoszona do hurtowni danych.
• Przesunięcia czasowe – opóźnienia pomiędzy źródłem a historianem, brak synchronizacji między różnymi collectorami.

Do pipeline’u AI warto włączyć osobny kanał na flagi jakości oraz zasady obchodzenia się z lukami. Inaczej model nauczy się „łatać” brakujące dane na własną rękę, co zwykle kończy się spadkiem wiarygodności predykcji.

Przestrzeń nazw i wersjonowanie tagów w historianie

W długich instalacjach konfiguracja historiana żyje swoim życiem: tagi są przenoszone, łączone, dzielone, czasem kasowane. Dla projektu AI, który opiera się na kilkuletniej historii, ma to krytyczne znaczenie.

Problemy, które wychodzą dopiero przy trenowaniu:

• zmiana nazwy taga bez migracji historii,
• ten sam tag logiczny reprezentowany kolejnymi fizycznymi tagami po modernizacjach,
• „dziwne” skoki wartości po zmianie zakresu skalowania lub jednostek.

Pomaga dyscyplina konfiguracji: słownik tagów z identyfikatorami logicznymi, mapowanie na fizyczne tagi z okresami ważności, opis zmian. To dodatkowa praca, ale chroni przed trenowaniem modelu na posklejanych, niespójnych szeregach czasowych.

Charakterystyka danych procesowych z punktu widzenia modeli AI

Szeregi czasowe o różnych częstotliwościach

Dane procesowe to głównie szeregi czasowe, ale z różną gęstością próbkowania: od milisekund w napędach do minut w raportach produkcyjnych. Model AI zwykle oczekuje ujednoliconej siatki czasowej.

W praktyce prowadzi to do:

• resamplingu – np. sprowadzenia wszystkich sygnałów do 1‑sekundowej lub 10‑sekundowej siatki,
• różnych „poziomów” modeli – oddzielne modele dla szybkiej dynamiki (drgania, napędy) i wolnej (bilans zmiany, zużycie energii).

Projektując architekturę, lepiej od razu zdefiniować 2–3 standardowe częstotliwości robocze i pod nie budować pipeline’y i featury.

Stany, sygnały binarne i zmienne dyskretne

W AI dla procesów ciągłych łatwo skupić się na analogach. Tymczasem sygnały binarne i dyskretne często niosą kluczowy kontekst: tryb pracy, stany awaryjne, potwierdzenia operatora.

Przygotowując dane dla modelu, trzeba te stany przełożyć na coś, co algorytm zrozumie:

• kodowanie „one-hot” dla trybów pracy (np. AUTO, MANUAL, OFF),
• okna czasowe od ostatniego wystąpienia zdarzenia (czas od ostatniego alarmu, restartu),
• liczniki narastające – liczba restartów w ostatnich godzinach.

Bez takiej reprezentacji model uczy się wyłącznie z „kształtu” analogów, ignorując to, że część anomalii pojawia się wyłącznie w określonych stanach linii.

Nieliniowości, histereza i zmiany reżimu pracy

Procesy przemysłowe rzadko są liniowe. Zmienny punkt pracy, histereza zaworów, różne surowce – wszystko to powoduje, że zależności między sygnałami zmieniają się w czasie.

Modele AI radzą sobie z tym lepiej, jeśli dostaną informację o reżimach pracy. Przykłady:

• oddzielne etykiety lub featury dla „rozruch”, „praca stabilna”, „zatrzymanie”,
• oznaczenie typu produktu lub surowca jako osobnego sygnału kategorycznego,
• parametry zadane (setpointy) jako referencja dla wartości rzeczywistych.

Bez tego model próbuje dopasować jedno „prawo” do całej historii, co w praktyce daje średnie wyniki we wszystkich reżimach.

Autokorelacja i opóźnienia między sygnałami

W procesach technologicznych efekt jednego działania widać po czasie: zmiana zaworu wpływa na temperaturę po kilkudziesięciu sekundach, a na jakość produktu po kilku minutach. Modele, które nie uwzględniają opóźnień, tworzą pozorne zależności.

Przy przygotowaniu danych trzeba wyraźnie zaszyć informację o historii sygnałów:

• okna czasowe – wektor cech obejmujący ostatnie n próbek,
• opóźnione wersje sygnałów (lag features) – np. temperatura sprzed 30, 60, 90 sekund,
• miary dynamiki – różnice i pochodne: Δx, d(x)/dt.

Dodatkowo warto oszacować (choćby empirycznie) typowe opóźnienia między kluczowymi sygnałami. Modele sekwencyjne (LSTM, Transformers) potrafią to częściowo uchwycić, ale dobre featury znacząco im pomagają.

Projektowanie architektury przepływu danych OT–IT pod kątem AI

Warstwy i granice odpowiedzialności

Największe problemy we wdrożeniach AI w przemyśle wynikają z braku jasnego podziału, gdzie kończy się OT, a zaczyna IT i analityka. Dlatego dobrze jest zdefiniować kilka prostych warstw.

Przykładowy podział:

• Warstwa akwizycji OT – sterowniki, SCADA, serwery OPC UA, collectory historiana.
• Warstwa buforowania i dystrybucji – broker MQTT/Kafka, time-series DB, edge gateways.
• Warstwa przetwarzania i modeli – środowiska analityczne, serwisy scoringowe, MLOps.
• Warstwa aplikacyjna – kokpity, systemy wsparcia operatora, integracja z MES/ERP.

Każda warstwa powinna mieć jasno opisane SLA, odpowiedzialności i politykę zmian. Modele AI są wtedy „zwykłym” klientem danych, a nie specjalnym bytem wymagającym wyjątków.

Architektura strumieniowa vs wsadowa

Decyzja, czy dane dla AI będą przetwarzane w trybie strumieniowym, wsadowym, czy mieszanym, ma wpływ na cały projekt, od sieci po wybór bibliotek.

W praktyce stosuje się kombinację:

• Wsad (batch) – zaciąganie danych historycznych z historiana do trenowania, re‑trainów, analiz offline.
• Strumień (stream) – bieżące dane z OPC UA lub brokera do scoringu online, detekcji anomalii, systemów doradczych.

Często sensowne jest wprowadzenie wewnętrznej „historyjki strumieniowej”: dane bieżące trafiają do bufora (np. Kafka, InfluxDB), skąd zarówno modele online, jak i procesy wsadowe mogą je pobierać w jednolity sposób.

Buforowanie i odsprzęganie od systemów produkcyjnych

Systemy sterowania i SCADA nie są projektowane do obsługi ciężkiego ruchu analitycznego. Bezpośrednie podpięcie wielu klientów AI pod serwery OPC UA zwykle kończy się skargami działu automatyki.

Rozwiązaniem jest warstwa buforująco‑dystrybucyjna:

• jeden lub kilka dedykowanych collectorów/klientów OPC UA,
• lokalna baza time-series lub broker komunikatów na poziomie zakładu,
• dalsza dystrybucja danych do chmury, hurtowni, środowisk ML.

W takiej architekturze serwery OT widzą niewielką, kontrolowaną liczbę połączeń, a obciążenie generowane przez eksperymenty AI nie wpływa na ciągłość produkcji.

Bezpieczeństwo, segmentacja sieci i dostęp modeli

Modele AI często działają w środowiskach IT lub chmurowych, podczas gdy dane źródłowe leżą głęboko w sieci OT, za firewallami i strefami DMZ. Należy przyjąć, że ruch z IT do OT jest wyjątkiem, nie normą.

Praktyczne podejście:

• wyraźna strefa DMZ z serwerem danych (np. repliką historiana, brokerem),
• dane wypychane z OT na zewnątrz (push), zamiast wciągane z zewnątrz (pull),
• kontrakt na rodzaj danych, częstotliwość i kierunki przepływu, zatwierdzony przez cyberbezpieczeństwo.

Dla modeli, które muszą działać blisko procesu (np. sterowanie optymalne), sensowne bywa wdrożenie ich w strefie OT lub na edge’u, z ograniczoną komunikacją na zewnątrz tylko do logów i metadanych.

Standaryzacja interfejsów danych dla zespołów AI

Z zespołu AI nie można robić ekspertów od każdego historianu i serwera OPC UA. Potrzebna jest ustandaryzowana „półka z danymi”, z którą zespół pracuje niezależnie od tego, jak wygląda instalacja źródłowa.

To zwykle oznacza:

• jednolitą warstwę API (REST/GraphQL) lub konektory do systemów analitycznych,
• standardowy schemat: tabela „tags”, tabela „time_series”, słownik jednostek i kategorii,
• zestaw gotowych narzędzi do pobierania przedziałów czasowych, resamplingu, filtrowania po jakości.

Im mniej zespół AI grzebie w protokołach i specyfikach vendorów, tym szybciej może iterować nad samymi modelami.

Pozyskanie i przygotowanie danych z OPC UA i historianów

Projektowanie zakresu danych pod konkretne use case’y

Najpierw wybiera się przypadek użycia, dopiero potem tagi i zakres historii. Zbieranie „wszystkiego na wszelki wypadek” kończy się chaosem i kosztami storage’u.

Praktyczny schemat:

1. Opisać decyzję lub wskaźnik, który AI ma poprawić (np. przewidywanie awarii łożysk konkretnej pompy).
2. Wspólnie z technologiem wskazać powiązane obiekty i zmienne procesowe.
3. Sprawdzić dostępność tych zmiennych w OPC UA / historianie z pełnym kontekstem (jednostki, zakresy, statusy jakości).
4. Dobrać okno czasowe historii, które ma sens dla danego zjawiska (miesiące, lata, sezony).

Taka selekcja na wejściu pozwala lepiej dopracować jakość danych dla kilkuset tagów, zamiast walczyć z milionem punktów bez jasnego celu.

Pobieranie danych z OPC UA: snapshoty vs długotrwałe strumienie

Z OPC UA można ciągnąć dane do trenowania na dwa sposoby: wykonywać snapshoty w trakcie testów lub rejestrować długotrwałe strumienie.

Snapshoty (krótsze kampanie zbierania):

• sprawdzają się przy pilotażach, gdy nie ma dostępu do historiana,
• wymagają dobrze ustawionych subskrypcji i niezawodnego zapisu na dysk,
• są podatne na utratę danych przy restartach i zmianach konfiguracji.

Długotrwałe strumienie:

• dobrze jest przepuścić przez lokalny broker lub kolejkę,
• powinny mieć monitoring opóźnień i wolumenów,
• mogą służyć równocześnie do trenowania i do późniejszego scoringu online.

Często optymalny układ to: historia z historiana + świeży strumień z OPC UA, spięte wspólnym systemem identyfikatorów tagów.

Dostęp do danych z historiana: API, eksporty, replikacje

Historiany „klasyczne” mają swoje biblioteki i API, nowsze time-series DB często oferują SQL lub REST. Z punktu widzenia AI kluczowa jest możliwość pobierania dużych zakresów danych bez obciążania systemów produkcyjnych.

Stosuje się kilka wzorców:

• Eksporty wsadowe – nocne zrzuty do plików lub baz pośrednich, potem ładowanie do środowiska ML.
• Replikacja – drugi, „analityczny” historian lub time-series, zasilany strumieniowo z produkcyjnego.
• Bezpośrednie API – używane raczej do mniejszych zakresów danych lub do odczytu uzupełniającego.

Radzenie sobie z brakami, duplikatami i niespójnościami czasowymi

Dane z OPC UA i historianów rzadko są idealnie równomierne. Przerwy w komunikacji, restarty sterowników, zmiany konfiguracji tagów – wszystko to zostawia ślady w szeregach czasowych.

Przygotowanie danych pod modele zaczyna się od zmapowania tych problemów:

• identyfikacja luk czasowych w poszczególnych tagach,
• wyszukiwanie duplikatów znaczników czasu,
• sprawdzanie spójności zegarów między źródłami.

Strategia uzupełniania braków zależy od natury sygnału. Dla stanów dyskretnych zwykle stosuje się forward fill (ostatnia znana wartość), dla sygnałów ciągłych – interpolację w rozsądnym horyzoncie. Duże luki lepiej oznaczyć flagą i ewentualnie wyciąć z trenowania.

Duplikaty i punkty „szpilki” (pojedyncze odchylenia bez fizycznego sensu) dobrze jest czyścić według prostych reguł: medianowy filtr w oknie, odrzucanie punktów wykraczających poza realistyczne tempo zmian sygnału.

Synchronizacja wielu źródeł czasowych

Modele zwykle zakładają jedną, wspólną oś czasu. Systemy OT tak nie działają – każdy sterownik, historian, system MES może mieć swoje opóźnienia i offsety.

Przed agregacją danych warto:

• zweryfikować synchronizację NTP/Time Server w kluczowych systemach,
• wyznaczyć typowe opóźnienia ścieżek (np. OPC UA → broker → TSDB),
• wprowadzić jedną „czas referencyjny” (np. UTC) w warstwie analitycznej.

Przy łączeniu wielu strumieni sensowne bywa „doklejenie” metadanych o źródle i opóźnieniu szacowanym, a następnie wyrównanie danych do wspólnej siatki czasowej (resampling). Dla modeli online krytyczne jest monitorowanie dryftu zegarów – drobne różnice potrafią zaburzyć zależności między sygnałami.

Normalizacja jednostek, zakresów i kodów jakości

Ten sam fizyczny parametr bywa mierzony w różnych jednostkach w zależności od linii, kraju czy dostawcy urządzeń. Z punktu widzenia modelu musi to być spójne.

Przy integracji tagów z wielu źródeł dobrze działa prosta zasada:

• zdefiniować słownik „jednostek kanonicznych” (np. °C, bar, m³/h),
• dla każdego taga zapisać jednostkę źródłową i przeliczenie do kanonicznej,
• przechowywać zarówno wartość surową, jak i przeliczoną, ale trenować na przeliczonej.

Podobnie trzeba ujednolicić kody jakości i statusy alarmowe. Historiany i OPC UA mają własne kody, natomiast na potrzeby modeli zwykle wystarczy kilka kategorii: OK, brak, poza zakresem, w trybie manualnym, w trakcie awarii.

Dokumentacja techniczna jako źródło metadanych

Schematy P&ID, listy I/O, opisy funkcji sterowników, procedury rozruchowe – to wszystko jest nieformalnym „słownikiem” danych procesowych.

Przed poważnym projektem AI sensowne jest:

• zmapowanie tagów do obiektów technologicznych (pompy, zawory, kolumny),
• zebranie typowych zakresów operacyjnych i stanów pracy,
• opisanie zależności przyczynowych z punktu widzenia technologa.

Nawet prosta tabela: „tag – opis – jednostka – obiekt – rola (wejście, wyjście, zakłócenie)” znacząco upraszcza późniejsze featurowanie i diagnostykę modeli.

Przetwarzanie wstępne danych procesowych dla modeli AI

Resampling i tworzenie jednolitej siatki czasowej

Tagi z OPC UA i historianów mają różne częstotliwości zapisu i tryby (on change, on time, exception-based). Modelom łatwiej pracować na ujednoliconej siatce próbkowania.

Typowy proces wygląda tak:

1. wybór interwału docelowego (np. 1 s, 5 s, 1 min) zależnie od dynamiki procesu,
2. agregacja lub interpolacja sygnałów do tej siatki, osobno dla każdej zmiennej,
3. oznaczenie próbek, gdzie interpolacja przekracza maksymalny horyzont (flagi braków).

Dla szybkich procesów (napędy, roboty) resampling poniżej sekundy ma sens, ale często wymaga dedykowanej infrastruktury i bardzo ostrego filtrowania szumów.

Agregaty okienne i statystyki ruchome

Modele rzadko korzystają wyłącznie z pojedynczej próbki w czasie. Dużo więcej informacji niosą cechy opisujące zachowanie w krótkim oknie.

Przykładowe agregaty ruchome:

• średnia, minimum, maksimum z ostatnich n próbek,
• odchylenie standardowe, wariancja, współczynnik zmienności,
• liczba przekroczeń progów alarmowych w oknie,
• miary trendu w oknie (nachylenie liniowej regresji, znaki zmian).

Takie statystyki są szczególnie przydatne w detekcji anomalii mechanicznych i jakościowych – model widzi nie tylko bieżący poziom sygnału, lecz także „kontekst” jego historii.

Redukcja wymiarowości i selekcja zmiennych

Instalacje mają tysiące tagów, natomiast większość przypadków użycia wymaga dziesiątek lub setek dobrze dobranych sygnałów. Ślepe trenowanie na wszystkich zmiennych zwiększa ryzyko przeuczenia i utrudnia interpretację.

Praktyczny proces selekcji obejmuje:

• filtrowanie „oczywistych” sygnałów pomocniczych (liczniki komunikatów, wewnętrzne flagi PLC),
• analizę korelacji i współwystępowania zmiennych w typowych reżimach,
• wstępne modele prostsze (np. lasy losowe) do oceny ważności cech,
• przegląd z technologiem – czy wybrane sygnały mają sens fizyczny.

Przy bardzo dużej liczbie cech można rozważyć metody redukcji wymiarowości (PCA, autoenkodery), ale w przemyśle liczy się interpretowalność, więc lepiej zacząć od jawnej selekcji.

Normalizacja, skalowanie i kodowanie kategorii

Większość algorytmów ML lepiej działa, gdy skale zmiennych są wyrównane. Dodatkowo trzeba wprowadzić sensowną reprezentację zmiennych kategorycznych (typ produktu, tryb pracy).

Typowe kroki:

• skalowanie sygnałów ciągłych (standard scaler, min-max, robust scaler), konsystentne między treningiem i scoringiem,
• kodowanie kategorii: one-hot dla kilku wartości, target/embedding dla wielu typów,
• zachowanie oryginalnych jednostek w metadanych, aby inżynier mógł interpretować wyniki.

Krytyczne jest „zamrożenie” parametrów skalowania (średnia, odchylenie, minima, maksima) po treningu i wykorzystanie ich w środowisku produkcyjnym. W przeciwnym razie model zobaczy inne rozkłady niż w trakcie uczenia.

Wykrywanie i obsługa stanów nienormalnych w treningu

Przerwy awaryjne, rozruchy, testy serwisowe – to okresy, w których sygnały zachowują się inaczej niż w stabilnej produkcji. W zależności od celu modelu można je włączyć lub wykluczyć.

Dobrą praktyką jest:

• oznaczenie okresów rozruchu, postoju, awarii na podstawie stanu kluczowych urządzeń i flag w MES/SCADA,
• oddzielne modele lub co najmniej oddzielne zestawy cech dla reżimów (start/stop vs steady-state),
• świadome ograniczenie treningu do reżimów, w których model ma podejmować decyzje.

Przykład: model jakości produktu trenuje się zwykle tylko na stabilnej pracy, bo rozruchy mają inne reguły i są zarządzane proceduralnie, nie przez AI.

Reprezentacja sekwencji i epizodów procesowych

Część zjawisk w przemyśle ma naturalny charakter epizodyczny: cykle partii, przepłukiwania, receptury, kampanie produkcyjne. W takich przypadkach pojedyncza oś czasu to za mało.

Można przyjąć dwie warstwy identyfikacji:

• czas absolutny (timestamp) – do synchronizacji z innymi systemami,
• identyfikator epizodu/cyklu – do budowy sekwencji wejściowych dla modelu.

Dla modeli sekwencyjnych (LSTM, Transformers) tworzy się zbiory danych w postaci „jeden epizod = jedna sekwencja”, z dodatkowymi cechami globalnymi (receptura, typ zlecenia). Pozwala to uchwycić powtarzalne wzorce w ramach kolejnych cykli, mimo że między nimi upływa czas kalendarzowy.

Łączenie danych procesowych z kontekstem biznesowym i jakościowym

Mapowanie tagów do zleceń, partii i klientów

Same sygnały procesowe mówią „jak” proces przebiega, ale nie „dla kogo”, „co” i „z jakim wynikiem biznesowym”. Dlatego konieczne jest połączenie zleceń produkcyjnych, partii, a czasem nawet numerów seryjnych.

Typowy wzorzec integracji obejmuje:

• wskazanie w MES/ERP tabel zawierających identyfikatory zleceń, produkty, czasy start/stop,
• zestawienie tych informacji z timeline’em danych procesowych (przecięcie przedziałów czasowych),
• nadanie każdej próbce procesowej identyfikatora zlecenia lub partii, jeśli w danym momencie była aktywna.

Przy procesach ciągłych relacja bywa bardziej złożona (mieszanie surowców, wieloetapowe linie). Wtedy przydają się modele „śledzenia materiału” (traceability) lub przynajmniej proste założenia, który odcinek rurociągu czy zbiornik odpowiada danemu produktowi.

Integracja danych jakościowych (laboratorium, inline QA)

Wiele kluczowych zmiennych docelowych (y) dla modeli pochodzi z systemów jakości: wyniki badań laboratoryjnych, pomiary offline, oceny wizualne. Te dane są rzadsze, często opóźnione względem procesu.

Aby je połączyć z szeregami czasowymi:

• określa się czas ważności wyniku (np. próbka reprezentuje uśredniony stan z ostatnich 30 minut),
• definiuje się reguły przypisania: do świata procesowego trafia etykieta jakościowa z odpowiednim przesunięciem w czasie,
• w razie potrzeby wykorzystuje się okna danych procesowych wokół czasu poboru próbki (przed i po), a nie tylko punkt w którym wpisano wynik do systemu.

Modele predykcji jakości wymagają szczególnie starannego odwzorowania tego związku czasowego. Proste „przyklejenie” wyniku labu do najbliższej próbki sygnału często prowadzi do mylnych zależności.

Łączenie z danymi kosztowymi i wskaźnikami efektywności

Aby modele miały realny wpływ na biznes, trzeba przełożyć efekty procesowe na koszty i przychody. Do tego służą dane z ERP, systemów utrzymania ruchu, modułów finansowych.

Przydatne kroki:

• zmapowanie zużycia mediów (energia, para, gaz, woda) do kosztów jednostkowych,
• powiązanie przestojów i awarii z kosztami utraconej produkcji,
• przeliczenie strat jakościowych (scrap, rework) na wartości pieniężne.

Na tej podstawie można definiować zmienne docelowe wprost w walucie (np. koszt na tonę, strata na zleceniu) i trenować modele nie tylko „techniczne”, ale także optymalizujące wynik finansowy.

Wzbogacanie danych procesowych o informacje kontekstowe

Część kluczowego kontekstu nie pochodzi ani z OPC UA, ani z klasycznych baz biznesowych. Chodzi o informacje typu: zmiana obsady zmiany, doświadczenie operatora, zastosowane obejścia procedur, występowanie nietypowych warunków zewnętrznych.

Nie wszystko da się zautomatyzować, ale można dodać kilka źródeł:

• dane o zmianach i zespołach z systemu kadrowego lub MES, sprowadzone do anonimowych identyfikatorów,
• dodatkowe pomiary środowiskowe (temperatura/ wilgotność otoczenia, pogoda przy instalacjach zewnętrznych),
• proste formularze dla operatorów do oznaczania niestandardowych zdarzeń (np. „niestandardowy wsad surowca”).

Takie informacje jako cechy kategoryczne często tłumaczą „niewyjaśnialne” wcześniej rozrzuty i pozwalają uniknąć przypisywania winy procesowi, gdy problem leży w organizacji pracy lub logistyce.

Spójny model danych i słownik pojęć między OT, IT i biznesem

Bez wspólnego języka łatwo o nieporozumienia: to samo słowo „wydajność” może oznaczać coś innego dla automatyka, planisty i kontrolera finansowego. Dla modeli AI każdy taki konflikt kończy się niespójnymi etykietami i trudnymi do zinterpretowania wynikami.

W praktyce pomaga:

• spisanie słownika kluczowych pojęć: jak liczony jest OEE, co to jest „partia”, kiedy zlecenie jest uznane za zakończone,
• ustalenie, które systemy są „źródłem prawdy” dla danego typu informacji (proces, jakość, koszty),
• utrzymywanie modelu danych (np. w postaci prostego katalogu lub narzędzia data catalog) z mapowaniem pól między systemami.

Dzięki temu modele uczą się na danych, które odzwierciedlają wspólnie uzgodnioną definicję rzeczywistości, a nie sumę lokalnych interpretacji.

Najczęściej zadawane pytania (FAQ)

Czym różnią się dane procesowe od danych biznesowych w przemyśle?

Dane biznesowe opisują zamknięte zdarzenia, takie jak faktury, zlecenia, zamówienia, rekordy w CRM. Zmieniają się stosunkowo rzadko, są powiązane z jednoznacznymi identyfikatorami i dobrze mieszczą się w relacyjnych bazach danych.

Dane procesowe napływają w sposób ciągły, są znaczone czasem i kluczowy jest ich przebieg w czasie: trend, dynamika, kształt sygnału. Często są przechowywane w historianach lub bazach time-series i wykorzystywane do analityki czasu rzeczywistego oraz modeli AI działających „przy linii”.

Jakie źródła danych procesowych są najważniejsze dla projektów AI w zakładzie produkcyjnym?

Najczęściej wykorzystywane są: PLC (sterowniki), SCADA/HMI, systemy DCS, MES oraz dodatkowe sensory IoT. Każde z tych źródeł dostarcza nieco inny poziom szczegółowości i kontekstu.

Na przykład: z PLC dostajesz bardzo szybkie, surowe sygnały z czujników, a z MES informacje o zleceniach, partiach i przestojach. W praktycznym projekcie AI zwykle łączy się kilka warstw, np. wibracje z czujników IoT + kontekst partii z MES.

Do czego w praktyce wykorzystuje się dane procesowe w modelach AI?

Najczęstsze zastosowania to predykcyjne utrzymanie ruchu, optymalizacja parametrów procesu, detekcja anomalii oraz soft-sensory (wirtualne czujniki). Każdy z tych przypadków ma inne wymagania co do częstotliwości próbkowania, długości historii i jakości sygnałów.

Przykład: do prognozowania awarii łożysk istotne są szybkie dane wibracyjne, natomiast do optymalizacji pieca kluczowe są długie trendy temperatur, przepływów i składu wsadu, nawet jeśli są próbkowane rzadziej.

Jak ocenić, czy moje dane procesowe nadają się do projektów AI?

Sam duży wolumen tagów w historianie nie wystarczy. Sprawdź stabilność źródeł (brak zaników, poprawne znaczniki czasu), spójność jednostek i zakresów oraz jakość sygnałów (oznaczenia „Bad”, „Uncertain”, tryby serwisowe).

Kluczowy jest też kontekst procesowy: powiązanie tagów z informacją, co, gdzie i jak było produkowane (linia, receptura, zlecenie, tryb pracy). Często lepsze efekty daje uporządkowanie kilkuset kluczowych sygnałów niż zbieranie setek tysięcy tagów bez opisu.

Czym jest OPC UA i dlaczego jest ważny dla danych procesowych i AI?

OPC UA to standard komunikacji w warstwie OT, który zastąpił starszy OPC oparty na COM/DCOM. Oprócz samej transmisji wartości zawiera model informacyjny: opisuje obiekty technologiczne, ich atrybuty, relacje i metadane.

Dzięki temu systemy AI mogą pobierać dane w sposób ustrukturyzowany, np. cały zestaw parametrów silnika jako jeden obiekt, a nie pojedyncze rejestry PLC. OPC UA działa na różnych platformach (od sterownika po chmurę) i często jest miejscem, gdzie pipeline danych AI „wpina się” w linię produkcyjną.

Jak najlepiej zbierać dane z OPC UA do systemów AI: odczyty, subskrypcje czy PubSub?

Do zasilania modeli AI zwykle stosuje się subskrypcje OPC UA (Monitored Items). Klient rejestruje zainteresowanie zestawem zmiennych, a serwer wysyła aktualizacje przy zmianie wartości lub w zadanych odstępach czasu, co ogranicza obciążenie sieci względem ciągłych odczytów „na żądanie”.

Model publish/subscribe (PubSub) jest wygodny w większych architekturach z brokerem (np. MQTT), gdy wiele systemów ma korzystać z tych samych strumieni danych. Klasyczne odczyty Read mają sens głównie do okazjonalnego pobierania konfiguracji lub diagnozy, a nie do ciągłego strumieniowania pod AI.

Na jakim poziomie architektury OT „odcinać” dane dla AI: PLC, SCADA, czy MES?

Niższe poziomy (PLC, surowe sensory) dają więcej szczegółów i wyższą częstotliwość, ale też większy wolumen i więcej szumu. Wyższe (SCADA, DCS, MES) wnoszą interpretację, alarmy, stany pracy i kontekst zleceń, ale często kosztem rozdzielczości sygnału.

W praktyce łączy się poziomy: np. do predykcyjnego utrzymania ruchu pobiera się dane blisko PLC/sensorów, a do analizy OEE i optymalizacji zmian – bliżej MES. Decyzja zależy od konkretnego przypadku użycia, możliwości sieci oraz tego, gdzie dane są najstabilniejsze i najlepiej opisane.

Co warto zapamiętać

• Dane procesowe różnią się od biznesowych tym, że są ciągłe, strumieniowe i silnie związane z czasem; kluczowe są przebiegi, trendy i dynamika, a nie pojedyncze wartości.
• Fundamentem projektów AI w przemyśle są dane procesowe pochodzące z wielu warstw (PLC, SCADA/DCS, MES, IoT), które trzeba świadomie „odciąć” na odpowiednim poziomie szczegółowości i kontekstu.
• Typowe zastosowania AI, takie jak predictive maintenance, optymalizacja procesu, detekcja anomalii czy soft-sensory, wymagają różnych częstotliwości próbkowania, długości historii i typów sygnałów.
• Sam wolumen danych (setki tysięcy tagów w historianie) nie gwarantuje gotowości na AI; przewagę dają uporządkowane, dobrze opisane i stabilne sygnały.
• Jakość i spójność danych procesowych obejmuje m.in. stabilne znaczniki czasu, jednolite jednostki i zakresy, oznaczanie jakości próbek (Good/Bad/Uncertain) oraz jasne powiązanie z kontekstem produkcji.
• Chaotyczne zmiany konfiguracji, brak synchronizacji czasu i nieoznaczone przerwy w sygnałach „trują” modele AI, prowadząc do błędnych wniosków i niestabilnych rekomendacji.
• OPC UA pełni kluczową rolę jako warstwa integracyjna OT/IT, udostępniając nie tylko wartości, lecz także model informacyjny (strukturę obiektów, atrybuty, relacje), co znacząco ułatwia zasilanie modeli AI ustrukturyzowanymi danymi.