Standaryzacja danych z hali produkcyjnej: jak UNS i PackML zamieniają surowe sygnały z maszyn w użyteczną wiedzę operacyjną
Opublikowano 18 września 2026 w Przemysł 4.0
Wielu producentów, którzy zainwestowali w analitykę przemysłową, prędzej czy później dochodzi do tego samego niewygodnego wniosku: problem z analityką jest w rzeczywistości problemem z danymi.
Dashboardy są niekompletne, bo część maszyn nie łączy się w sposób niezawodny. Modele AI dają niespójne wyniki, bo ta sama zmienna na różnych liniach ma inną nazwę, jest mierzona w innych jednostkach i próbkowana z inną częstotliwością. Dodanie nowego strumienia danych na potrzeby projektu pilotażowego zajmuje tygodnie prac integracyjnych, bo nikt nie zna w całości schematu połączeń między halą produkcyjną a warstwą IT.
To objawy problemu architektonicznego, który pojawił się na długo przed ambicjami analitycznymi. Rozwiązują go dwa standardy stosowane razem, które tworzą kręgosłup nowoczesnej infrastruktury danych na hali produkcyjnej: Unified Namespace i PackML.
Problem z danymi i łącznością, który kryje się pod problemem z analityką
Urządzenia przemysłowe komunikują się za pomocą wielu różnych protokołów, takich jak OPC UA, Modbus, PROFINET, EtherNet/IP, a także zamkniętych formatów właściwych dla poszczególnych producentów maszyn. Każdy dostawca i każdy starszy system mówi innym językiem.
Każdy system na hali zwykle łączy się wyłącznie z tymi systemami, z którymi zintegrowano go w momencie instalacji. Z czasem powstaje gąszcz bezpośrednich połączeń punkt-punkt, który inżynierowie zwykle nazywają architekturą „spaghetti”.
Rodzi to dwa nakładające się na siebie problemy. Pierwszy to pułapka ciągłego odpytywania i wypychania danych (poll-and-push): systemy nieustannie odpytują się nawzajem o aktualizacje, niezależnie od tego, czy cokolwiek się zmieniło. Generuje to zbędny ruch sieciowy i opóźnienia, które utrudniają podejmowanie decyzji w czasie rzeczywistym. Drugi to chaos w danych: nawet jeśli dane są dostępne, są niespójne. Ta sama wielkość fizyczna, na przykład prędkość produkcji, może mieć inną etykietę, inne jednostki i inny typ danych w trzech maszynach na tej samej linii. Porównanie linii wymaga warstwy tłumaczącej, a analiza między zakładami – kilku takich warstw. Zanim powstanie jakakolwiek sensowna analityka, dane trzeba oczyścić, ujednolicić i osadzić w kontekście.
Gdy ktoś potrzebuje nowego strumienia danych dla dashboardu lub modelu AI, musi od zera zrozumieć cały schemat połączeń. W praktyce to jedna z najpoważniejszych barier dla przemysłowej AI i zaawansowanej analityki.
Unified Namespace
Unified Namespace (UNS) rozwiązuje problem integracji, zastępując model punkt-punkt architekturą publikuj/subskrybuj (publish/subscribe). Zamiast budować bezpośrednie połączenia między producentami a odbiorcami danych, każde źródło publikuje swoje dane w centralnym brokerze, a każdy odbiorca subskrybuje te strumienie, których potrzebuje. Dodanie nowego odbiorcy nie wymaga żadnych zmian w systemach źródłowych.
Najczęściej jako protokół komunikacyjny stosuje się MQTT (Message Queuing Telemetry Transport). To lekki protokół typu publikuj/subskrybuj, zaprojektowany dokładnie z myślą o warunkach panujących w środowisku przemysłowym: zawodnych sieciach, urządzeniach o ograniczonych zasobach i potrzebie dostarczania danych z minimalnym opóźnieniem. Specyfikacja Sparkplug B dodaje do tego mechanizm raportowania przez wyjątek (report by exception): urządzenia publikują aktualizacje tylko wtedy, gdy wartość zmieni się o więcej niż zdefiniowany próg, a nie w stałym cyklu odpytywania.
Struktura przestrzeni nazw odzwierciedla hierarchię ISA-95:
Przedsiębiorstwo
└── Zakład
└── Obszar
└── Linia
└── Gniazdo / Urządzenie
└── Tagi (stan, metryki, zdarzenia, alarmy)
Każdy punkt danych ma w tej hierarchii przewidywalny adres. Każdy system, który zna tę strukturę, dotrze do dowolnego punktu danych bez dedykowanych prac integracyjnych, dzięki czemu architektura jest z natury skalowalna.
PackML
UNS rozwiązuje problem architektury integracji danych. PackML odpowiada na inny, choć ściśle z nim związany problem: każda maszyna na linii opisuje swoje stany pracy na swój sposób.
Jedna maszyna raportuje „running”, „faulted” i „idle”. Inna – „auto”, „E-stop” i „standby”. Trzecia posługuje się kodami liczbowymi. Gdy w zakładzie pracują maszyny od wielu producentów (a to norma), każda analiza wykraczająca poza pojedynczą maszynę wymaga warstwy tłumaczącej. PackML eliminuje tę warstwę, definiując standardowy model stanów, który mogą przyjąć wszystkie maszyny:
Stopped ──► Resetting ──► Idle ──► Starting ──► Execute (Running) │ Completing │ Complete ──► Resetting
W środowisku zgodnym z PackML każda maszyna używa tych samych nazw stanów i przejść między nimi. Wskaźniki wydajności, takie jak rzeczywista prędkość, prędkość zadana, liczba wyprodukowanych sztuk czy liczba braków, są publikowane pod ustandaryzowanymi nazwami tagów. Jeśli maszyny różnych dostawców mówią w PackML, porównanie ich wydajności nie wymaga żadnego tłumaczenia. Dane są bezpośrednio porównywalne.
PackML + UNS: połączenie, które umożliwia analitykę między liniami
Gdy maszyny zgodne z PackML publikują ustandaryzowane dane o stanach i tagach w UNS za pośrednictwem MQTT, powstaje kręgosłup danych hali produkcyjnej, w którym:
- każda maszyna posługuje się tym samym słownikiem danych,
- każdy punkt danych ma przewidywalny adres w hierarchii ISA-95,
- każdy odbiorca otrzymuje dane tylko wtedy, gdy coś się zmienia – dzięki raportowaniu przez wyjątek w Sparkplug B.
Nakład pracy integracyjnej, przez który analityka między liniami była dotąd wielomiesięcznym projektem, sprowadza się do kwestii konfiguracji.
Filtrowanie danych na brzegu sieci
UNS i PackML tworzą przejrzystą, ustandaryzowaną architekturę danych. Jednak duża fabryka z setkami sterowników PLC, tysiącami czujników i dziesiątkami linii produkcyjnych z łatwością generuje dziesiątki milionów punktów danych na minutę. Przesyłanie tego wszystkiego do chmurowej platformy analitycznej jest kosztowne, wprowadza opóźnienia uniemożliwiające podejmowanie decyzji w czasie rzeczywistym na poziomie maszyny i pogarsza stosunek sygnału do szumu w modelach, które z tych danych korzystają.
Odpowiedzią jest inteligentne filtrowanie danych na brzegu sieci (edge). Warstwa edge to miejsce, w którym surowe dane OT ze sterowników PLC, czujników i sieci polowych są zbierane, tłumaczone na standardowe formaty, wstępnie przetwarzane i selektywnie przekazywane wyżej. To inteligentna granica między procesem fizycznym a systemami informatycznymi, które go analizują.
Większość pracy wykonują dwie techniki filtrowania. Filtrowanie ze strefą martwą (dead-band) blokuje aktualizacje, gdy wartość zmienia się o mniej niż zdefiniowany próg. Przykładowo czujnik temperatury, którego odczyt waha się o 0,1°C wokół stabilnej wartości zadanej, nie wysyła żadnej aktualizacji. Agregacja oblicza na brzegu sieci statystyki zbiorcze – średnie, wartości min./maks., odchylenia standardowe – w zdefiniowanym oknie czasowym i przekazuje jedną wartość podsumowującą zamiast tysięcy surowych odczytów.
Rachunek kosztów chmury
Argument finansowy za filtrowaniem na brzegu sieci jest prosty. Fabryka z 50 maszynami, z których każda udostępnia 200 tagów odpytywanych co sekundę, generuje około 10 000 punktów danych na sekundę, czyli 864 mln na dobę. Przy typowych stawkach chmurowych platform IoT wynoszących 0,10–0,30 € za milion wiadomości daje to 86–260 € dziennie wyłącznie za pozyskiwanie danych, jeszcze przed kosztami przechowywania i przetwarzania. Zastosowanie raportowania przez wyjątek i filtrowania ze strefą martwą na brzegu sieci, które zmniejsza liczbę wiadomości o 90%, istotnie zmienia ten obraz:
- Po filtrowaniu: 86 mln wiadomości na dobę → 9–26 € dziennie za pozyskiwanie danych
- Proporcjonalnie mniejsze wymagania dotyczące przechowywania danych
- Mniejsze obciążenie przetwarzania strumieniowego, co pozwala korzystać z mniejszych i tańszych zasobów obliczeniowych
W praktyce architektura oparta wyłącznie na chmurze kosztuje zakład tej wielkości około 3000–4500 € miesięcznie. Architektura z filtrowaniem na brzegu sieci obniża ten koszt do mniej więcej 400–600 € miesięcznie. Inwestycja w sprzęt edge zwraca się zwykle w niecałe trzy miesiące, a pięcioletnie oszczędności przekraczają 150 000 € dla jednego zakładu – i to bez uwzględnienia wartości szybszych i bardziej trafnych decyzji.
Od danych do decyzji: co umożliwia ta architektura
- Dashboardy produkcyjne w czasie rzeczywistym bez projektów integracyjnych. Gdy każda maszyna publikuje ustandaryzowane dane we wspólnej przestrzeni nazw, dashboard można zbudować, po prostu subskrybując odpowiednie tematy. Bez dedykowanej integracji i bez uzależnienia od API konkretnego dostawcy.
- Analityka porównawcza wielu linii i zakładów. Ponieważ PackML wymusza wspólny słownik, a UNS zapewnia spójną strukturę adresów, porównanie wydajności linii 3 w jednym zakładzie z linią 3 w innym staje się zwykłym zapytaniem do danych, a nie projektem integracyjnym.
- AI i uczenie maszynowe na czystych danych osadzonych w kontekście. Modele otrzymują ustrukturyzowane, opisane i spójnie sformatowane dane zamiast surowych, niespójnych sygnałów. Jakość danych wejściowych bezpośrednio decyduje o jakości wyników. Ta architektura usuwa jeden z najczęstszych powodów, dla których pilotażowe projekty AI nie trafiają do produkcji.
- Szybsze decyzje na poziomie maszyny bez zależności od chmury. Przeniesienie wnioskowania AI i logiki sterowania na brzeg sieci pozwala lokalnie realizować decyzje wymagające czasu reakcji liczonego w milisekundach – zamkniętą pętlę kontroli jakości, blokady bezpieczeństwa czy korekty procesu w czasie rzeczywistym – bez czekania na odpowiedź z chmury.
Jak może pomóc OMRON
Wdrożenie UNS i PackML nie wymaga wymiany istniejących maszyn ani systemów. Większość sterowników PLC i kontrolerów przemysłowych można skonfigurować tak, by publikowały dane do brokerów MQTT za pomocą standardowego oprogramowania bramek edge. Zgodność z PackML można z kolei doposażyć dzięki translacji na poziomie bramki w maszynach, które nie obsługują tego standardu natywnie. Typowym punktem wyjścia jest jedna linia produkcyjna lub jedno gniazdo: wdrożenie infrastruktury edge, walidacja modelu danych, a następnie skalowanie.
Serwis i-BELT firmy OMRON obejmuje właśnie tę warstwę transformacji: od projektu architektury IT-OT i definicji modelu danych, przez wdrożenie na brzegu sieci, aż po integrację z systemami korporacyjnymi – w ramach szerszej oceny, która łączy decyzje dotyczące infrastruktury danych z konkretnymi wskaźnikami KPI produkcji, które firma chce poprawić. Więcej informacji znajdziesz na stronie:
i-BELT Service (tcm:439-112230)
