Moduły platformy ITS — jeden system, wiele warstw funkcjonalnych.

Dwanaście modułów w czterech warstwach oraz otoczenie systemowe platformy.

Moduły ITS pogrupowane są tematycznie — od zarządzania i nadzoru, przez zbieranie i przepływ danych, po automatyzację, wizualizację i analitykę. Osobno opisane zostało otoczenie systemowe, czyli udostępnianie danych narzędziom pracującym poza platformą.

Panel administratora — centralna konfiguracja modułów i dostępów.

Panel administratora to miejsce zarządzania modułami platformy ITS i ich konfiguracją. Ustawiane są w nim główne parametry pracy instancji, ustawienia sieciowe, konfiguracja poszczególnych modułów oraz ustawienia dostępów — użytkownicy, role i poziomy uprawnień.

Konfiguracja modułów jest utrzymywana w jednym miejscu i stamtąd rozchodzi się do modułów platformy.

Monitoring danych — progi, alarmy i odchylenia w danych.

Monitoring danych obserwuje pomiary napływające do platformy i porównuje je ze zdefiniowanymi progami. Dla metryki dostępnych jest sześć poziomów progowych — trzy po stronie dolnej i trzy po stronie górnej — co pozwala odróżnić lekkie odchylenie od stanu wymagającego natychmiastowej reakcji.

Poziomy oznaczane są kolejno jako 3Low, LowLow i Low po stronie dolnej oraz Hi, HiHi i 3Hi po stronie górnej. Progi Low i Hi wyznaczają granicę zakresu normalnej pracy, LowLow i HiHi odpowiadają odchyleniu wymagającemu uwagi, a 3Low i 3Hi — przekroczeniu krytycznemu. Poziomy definiowane są osobno dla poszczególnych metryk, więc ta sama skala nie musi obowiązywać dla temperatury i dla ciśnienia.

Stopniowanie progów ma znaczenie praktyczne: pozwala rozdzielić powiadomienia. Wejście w zakres Low lub Hi może trafiać wyłącznie na pulpit operatora, LowLow i HiHi uruchamiać powiadomienie do utrzymania ruchu, a 3Low i 3Hi — alarm o najwyższym priorytecie. Dzięki temu odbiorcy nie są zasypywani zdarzeniami o niskiej istotności.

Gdy wartość przekroczy zdefiniowany próg, moduł rejestruje zdarzenie alarmowe, które może zostać wykorzystane przez moduł dashboardowy do wizualizacji lub przez moduł automatyzacji do uruchomienia dalszej reakcji.

Zdarzenie alarmowe nie jest pojedynczym punktem w czasie. Jeśli w trakcie jego trwania wartość wejdzie na kolejny próg, moduł rejestruje zmianę istotności — na przykład przejście z poziomu Hi na HiHi — bez zamykania i otwierania nowego zdarzenia. Dla przebiegu, który kilkukrotnie zmienia poziom, powstaje jeden wpis, a nie seria niepowiązanych alarmów.

Zapisywane są przy tym dwie informacje o istotności: poziom, od którego alarm się zaczął, oraz najwyższy poziom osiągnięty przez cały czas trwania stanu alarmowego. To rozróżnienie ma znaczenie przy analizie — pokazuje zarówno moment, w którym proces zaczął wychodzić poza zakres, jak i to, jak daleko odszedł od normy zanim wrócił.

Historia alarmów zawiera więc dla poszczególnych metryk: moment pierwszego przekroczenia wraz z jego poziomem, najwyższy odnotowany poziom, moment powrotu w zakres oraz łączny czas trwania stanu alarmowego.

Progi nie są konfiguracją oderwaną od danych. Do rekordów historii metryki dopisywane są progi obowiązujące w momencie zapisu, więc konfiguracja z danego okresu zostaje w historii razem z odczytami.

Zmiana progów obowiązuje od chwili jej wprowadzenia — dla danych bieżących i kolejnych zdarzeń. Historia pozostaje jednak czytelna: przy wpisach sprzed zmiany widoczne są progi, które wtedy obowiązywały. Dzięki temu da się odtworzyć, dlaczego dany odczyt wywołał alarm albo dlaczego go nie wywołał, mimo że dziś ta sama wartość byłaby oceniona inaczej.

Ma to znaczenie przy analizie wstecznej i przy audytach. Bez zapisanych progów ocena zdarzenia sprzed kilku miesięcy wymagałaby pamiętania, jaka konfiguracja obowiązywała w tamtym czasie — a przy kilkuset metrykach jest to niewykonalne.

Replikacja — replikacja pełnego stanu między instancjami.

Moduł replikacji odpowiada za przenoszenie danych pomiędzy instancjami platformy ITS. Replikacji podlega pełny stan: telemetria, alarmy, progi i zdarzenia, a nie wyłącznie surowe odczyty.

Kierunek replikacji nie jest narzucony. Instancja źródłowa może przekazywać dane do wielu instancji docelowych, ale możliwy jest też układ odwrotny — wiele instancji lokalnych replikuje dane do jednej instancji nadrzędnej. Ten drugi model jest podstawą konsolidacji: rozproszone zakłady, obiekty czy lokalizacje trafiają do jednego obrazu bez budowania osobnej integracji dla poszczególnych z nich.

Zreplikowany wpis niesie ze sobą metadane o swoim pochodzeniu — unikalny identyfikator, dokładny znacznik czasu oraz informację o instancji źródłowej. Dzięki temu dane z wielu lokalizacji można łączyć w jeden spójny obraz, z zachowaniem pełnej historii ich pochodzenia.

Replikacja nie ogranicza się do jednego rodzaju danych. Obejmuje moduły platformy, które gromadzą informacje o instalacji — od stanu infrastruktury, przez pomiary i alarmy, po identyfikowalność i wskaźniki produkcyjne. Zakres replikacji zależy od tego, które moduły są uruchomione w instancji źródłowej.

Z replikacją wiąże się osobne zagadnienie — pojedynczy punkt awarii, określany skrótem SPOF. Jest to element architektury, którego zatrzymanie przerywa zbieranie danych albo dostęp do nich. W systemach pomiarowych ma to konsekwencję trudną do odrobienia: pomiar, który nie został zapisany w czasie awarii, nie istnieje i nie da się go odtworzyć później.

W układzie, w którym jedna instancja zbiera dane z całej instalacji, tym punktem jest właśnie ona. Zatrzymanie usługi, awaria hosta albo zerwane łącze do obiektu oznacza lukę w danych cyklicznych za cały czas trwania przerwy. Ryzyko rośnie wraz z liczbą obiektów podłączonych do tej samej instancji.

Replikacja zmienia rozkład tego ryzyka. Zapis prowadzi instancja lokalna, umieszczona blisko źródła — na ITS Edge Box w obiekcie albo na osobnej maszynie wirtualnej. Dane powstają i pozostają na miejscu, więc awaria instancji nadrzędnej albo łącza nie zatrzymuje rejestracji. Po przywróceniu połączenia zaległe zapisy są replikowane wyżej i skonsolidowany obraz uzupełnia się o okres przerwy.

Broker MQTT — wiele brokerów w ramach jednej instancji.

Moduł pozwala tworzyć i zarządzać wieloma niezależnymi brokerami MQTT w ramach jednej instancji ITS. Brokery działają w oddzieleniu od siebie, co pozwala oddzielić ruch danych dla różnych zastosowań, klientów lub części instalacji.

Dla poszczególnych brokerów zarządza się osobno użytkownikami i ich uprawnieniami dostępu, a także listenerami — czyli adresem IP i portem, na których broker nasłuchuje połączeń przychodzących. Broker może pracować z szyfrowaniem TLS albo bez niego. Pozwala to zbudować odizolowane od siebie kanały komunikacji w ramach jednej platformy.

Brokery i konta użytkowników definiowane są dla całej infrastruktury z poziomu platformy. Daje to pełen zakres kontroli nad komunikacją przechodzącą przez system — wiadomo, kto się łączy, którym kanałem i z jakimi uprawnieniami.

Automatyzacja i integracje low-code — przepływy danych bez programowania.

Moduł pozwala budować przepływy danych i integracje między systemami w sposób wizualny — z gotowych bloków łączonych w schemat. Przepływ zestawia źródło danych, przekształcenie, warunek i miejsce docelowe, a jego działanie widać wprost na rysunku.

Przepływy uruchamiają się automatycznie w reakcji na zdarzenia z platformy — na przykład alarm zarejestrowany przez moduł Monitoring danych lub nowy wpis w module Traceability — i mogą prowadzić do akcji po stronie systemów zewnętrznych.

Środowisko nie jest zamkniętym konfiguratorem. Bloki funkcyjne programuje się w języku JavaScript, więc obok gotowych elementów dostępna jest własna logika: przeliczanie i normalizacja wartości, filtrowanie, łączenie kilku źródeł w jeden rekord, obsługę formatów niestandardowych czy wystawienie własnego interfejsu API. Prosty przepływ powstaje z samych bloków; tam, gdzie potrzeba czegoś więcej, kod dopisuje się w tym samym miejscu.

Takie podejście pozwala zbudować w ramach platformy własny obszar aplikacyjny — zestaw przepływów realizujących logikę specyficzną dla danej instalacji, bez stawiania osobnego systemu obok ITS i bez utrzymywania dodatkowej integracji między nimi.

Do dyspozycji jest szeroki zestaw gotowych bloków komunikacyjnych. Obejmuje protokoły spotykane w automatyce, standardowe protokoły sieciowe, wymianę plików i baz danych, powiadomienia, a także bloki łączące przepływ bezpośrednio z modułami platformy — zapis do IDC czy rejestrację wpisu w Traceability odbywa się jednym elementem, bez budowania warstwy pośredniej.

Skala tego katalogu jest znacznie większa, niż pokazują powyższe zestawienia. Publiczna biblioteka komponentów tego środowiska liczy ponad pięć tysięcy bloków i gotowych przepływów udostępnionych przez społeczność — od protokołów przemysłowych, przez usługi chmurowe i bazy danych, po narzędzia pomocnicze. Powyższe listy wskazują to, co najczęściej wykorzystywane w instalacjach przemysłowych, a nie granicę możliwości.

Za środowiskiem stoi duża i aktywna społeczność. W internecie dostępna jest obszerna dokumentacja, fora, kursy i tysiące gotowych przepływów do pobrania i przerobienia pod własne potrzeby, więc rozwiązania typowych problemów zwykle są już opisane. To realnie skraca czas budowy przepływu i obniża próg wejścia dla osoby, która nie programuje na co dzień.

Pomocne są tu również modele AI. Ponieważ bloki funkcyjne pisze się w JavaScript, a same przepływy zapisywane są w formacie JSON, modele językowe dobrze radzą sobie z przygotowaniem fragmentów kodu funkcji, przekształceń danych czy szkieletu całego przepływu. Otrzymany kod wystarczy wkleić do bloku i dostosować do własnych nazw metryk — to jeden z powodów, dla których budowanie integracji w tym module jest osiągalne również dla zespołów bez zaplecza programistycznego.

Poniżej kilka typowych obszarów zastosowania, pokazanych jako schematy przepływów. Bloki wejściowe zaznaczono kolorem cyjanowym, bloki modułów ITS — indygo, a bloki przekształceń i akcji pozostają neutralne.

Pokazane przepływy są przykładami układów, a nie zamkniętą listą. Kolejność bloków wynika z logiki procesu i można ją swobodnie układać, a raz zbudowany przepływ da się skopiować i wykorzystać w kolejnej instalacji.

Traceability — pełna historia procesu, osadzona w strukturze instalacji.

Traceability rejestruje dane powiązane z konkretnymi obiektami w instalacji — produktami, ich podzespołami czy punktami pomiarowymi, wynikami testów itp. Definiowane są typy obiektów oraz konkretne obiekty tego typu, a moduł rejestruje przypisane do nich wartości wraz z dokładnym znacznikiem czasu.

Dla bardziej złożonych zastosowań moduł oferuje Custom Data Blocks — możliwość rejestrowania wielowartościowego zestawu danych różnych typów pod jednym wspólnym znacznikiem czasu, dopasowanego do struktury danej instalacji. Dzięki temu do konkretnej części można przypisać cały zestaw pomiarów zebranych w trakcie jej wytwarzania — przebieg temperatury, ciśnienia czy innego parametru procesu. Historia identyfikowalności zawiera wtedy nie tylko rekord informacyjny z wartościami właściwości, ale też odpowiadający mu zbiór danych pomiarowych. Traceability korzysta z platformowego mechanizmu Replikacja, dzięki czemu pełna historia procesu jest dostępna na wielu instancjach ITS jednocześnie, z zachowaniem informacji o pochodzeniu wpisów.

Strukturę opisu buduje się na właściwościach obiektu — properties, w skrócie prop. Typ obiektu określa, jakie właściwości mają obiekty tego rodzaju: ich nazwy i typy danych, na przykład tekst dla numeru seryjnego, liczbę dla wyniku pomiaru, wartość logiczną dla rezultatu testu. Konkretny obiekt przechowuje wartości tych właściwości.

Właściwość można zapisać jednorazowo, jak numer seryjny nadany przy utworzeniu obiektu, albo rejestrować wielokrotnie, gdy wartość zmienia się na kolejnych etapach procesu. W obu przypadkach zapis ma dokładny znacznik czasu, więc widoczny jest nie tylko aktualny stan obiektu, ale też droga, którą do niego doszedł.

Identyfikowalność rzadko kończy się na jednym stanowisku. W praktyce zapis powstaje tam, gdzie realizowana jest operacja — przy gnieździe produkcyjnym, na linii, w konkretnym obiekcie — a obraz całości potrzebny jest poziom wyżej. Traceability w ITS jest zbudowane tak, żeby oba te poziomy dało się połączyć bez przenoszenia danych ręcznie.

Na poziomie stanowiska zapis prowadzi lokalna instancja, najczęściej na ITS Edge Box. Dane powstają i pozostają w miejscu produkcji, więc rejestracja działa również wtedy, gdy łącze do centrali jest chwilowo niedostępne. Zapisy są następnie replikowane wyżej — do instancji nadrzędnej, na przykład ITS VM — gdzie moduł Konsolidator zestawia je w jeden obraz. Metadane pochodzenia zostają przy wpisach, więc na poziomie systemowym nadal wiadomo, z którego gniazda i z której instancji pochodzą poszczególne zapisy.

Drugi wymiar tej struktury to genealogia wyrobu. Zapis identyfikowalności nie jest płaską listą zdarzeń — może odwoływać się do innych zapisów. Kiedy z dwóch komponentów powstaje wyrób złożony, nowy trace przechowuje odwołania do zapisów części, z których został zbudowany.

Przykład poniżej. Na jednym gnieździe produkowane jest kolanko i powstaje jego trace, na drugim trójnik ze swoim własnym zapisem. Oba trafiają na stanowisko montażu, gdzie powstaje nowy numer wyrobu wraz z nowym zapisem — a ten zawiera odwołania do obu zapisów składowych. Od gotowego wyrobu prowadzi to do konkretnych partii komponentów i warunków, w jakich powstały. Od strony komponentu — do wyrobów, w których został użyty.

Struktura ta jest wielopoziomowa. Wyrób złożony może być składnikiem kolejnego wyrobu, a jego trace stanie się wtedy zapisem podrzędnym na wyższym poziomie. Dzięki temu identyfikowalność prowadzona jest od pojedynczego komponentu aż po partię wysyłkową, również gdy kolejne etapy realizowane są w różnych gniazdach albo w różnych lokalizacjach.