Jak AI łączy się z AVEVA PI System i co agenci robią z Waszymi danymi procesowymi?

AVEVA PI System, znany wcześniej jako OSIsoft PI, to jeden z najszerzej stosowanych systemów do archiwizacji danych procesowych w przemyśle. Jeśli macie PI w zakładzie, macie historiana wypełnionego tagami: temperatury, ciśnienia, przepływy, stany maszyn, liczniki. Agenci AI zainstalowani na Waszym serwerze mogą czytać te dane przez PI Web API i robić z nimi to, czego PI sam z siebie nie robi: wykrywać anomalie, pisać raporty zmianowe, podpowiadać decyzje. PI zostaje źródłem prawdy, redAI dokłada warstwę analizy.

Co PI System robi u klienta i jakie dane przechowuje?

PI Data Archive to serce systemu. Gromadzi dane z sensorów, sterowników PLC i systemów SCADA w postaci tagów. Każdy tag ma nazwę (np. Reaktor_01.Temp_Wejscie albo Linia_03.Cisnienie_Bar), wartość, znacznik czasu i kod jakości. Dane trafiają do archiwum z różną częstotliwością: od milisekund przy szybkich procesach chemicznych do kilku minut przy pomiarach środowiskowych.

PI Asset Framework, czyli PI AF, dodaje kontekst. Łączy tagi w hierarchię aktywów, definiuje jednostki, wylicza atrybuty pochodne. Typowy zakład ma od kilkuset do dziesiątek tysięcy tagów, a zapis sięga lat wstecz. PI stosuje kompresję wyjątkową: zapisuje punkt tylko wtedy, gdy wartość zmienia się ponad ustalony próg, więc archiwum jest zwarte, ale dostęp do historii wymaga zapytania z interpolacją.

PI Event Frames rejestrują zdarzenia z polami StartTime, EndTime, EventName i powiązanymi wartościami atrybutów. Kiedy alarm się włączył, jak długo trwał postój, kiedy parametr wyszedł poza specyfikację. To dane kontekstowe, które w zestawieniu z szeregiem czasowym dają pełen obraz incydentu.

Jak redAI łączy się z PI: API, tagi i typy danych

Połączenie przebiega przez PI Web API zainstalowane na serwerze PI lub osobnej maszynie w sieci OT. PI Web API udostępnia interfejs REST, przez który nasz system pobiera:

• wartości tagów w czasie rzeczywistym (endpoint /streams/{webId}/value)
• historię z dowolnego zakresu dat (endpoint /streams/{webId}/recorded z parametrami startTime i endTime)
• listę aktywów i atrybutów z PI AF (endpointy /elements i /attributes)
• Event Frames: zdarzenia z polami czasu, nazwy i wartości powiązanych atrybutów
• bulk query: dane z wielu tagów jednocześnie przez /streamsets, bez sekwencyjnego odpytywania

Przy starszych instalacjach bez PI Web API sięgamy po PI OLEDB Enterprise (zapytania SQL do archiwum) albo bibliotekę PIthon i oficjalne AF SDK dla Pythona. Każda metoda daje dostęp do tych samych danych.

Dane, które odczytujemy, to przede wszystkim: float32 i float64 dla wartości analogowych, integer dla liczników i stanów cyfrowych, string dla komunikatów sterownika, timestamp z dokładnością do mikrosekund oraz quality flag informujący o wiarygodności pomiaru (Good, Questionable, Bad). Quality flag jest ważny. Zanim agent AI wciągnie dane do analizy, odrzucamy punkty z flagą Bad, żeby nie budować wniosków na awaryjnych odczytach z uszkodzonego sensora.

Co agenci AI robią z danymi procesowymi: pięć scenariuszy

Tu jest istota całego wdrożenia. PI dostarcza dane, agenci AI na Waszym serwerze robią z nimi robotę, której sam historianus nie wykona.

Wykrywanie anomalii w parametrach procesu. Agent co godzinę pobiera ostatnie N punktów wybranych tagów: temperatura wejścia reaktora, ciśnienie przed zaworem, lepkość surowca. Porównuje je ze wzorcem z analogicznego okresu poprzednich tygodni. Jeśli odchylenie przekracza normę statystyczną, generuje alert ze wskazaniem, który tag odskoczył i kiedy odchylenie się zaczęło. Nie jest to zwykłe przekroczenie progu alarmowego z PI. Agent łączy kilka tagów i szuka wzorca, który sam w sobie nie wygląda groźnie, ale w zestawieniu sygnalizuje problem wcześniej niż alarm.

Predykcyjne utrzymanie ruchu. U jednego klienta z branży chemicznej trend temperatury łożysk pompy był wzrostowy od czterech dni, ale mieścił się w granicach alarmu. PI tego nie flagował. Agent zauważył korelację: temperatura i drgania (wibracje z osobnego tagu) rosły razem w tym samym tempie, co poprzednio, gdy pompa weszła w awarię. Trzy dni przed przekroczeniem progu agent wysłał raport do działu utrzymania ruchu z konkretnym zaleceniem: sprawdzić smarowanie i wyważenie. Wymiana elementu kosztowała ułamek tego, co kosztowałby postój linii.

Automatyczny raport zmiany. Brygadzista dostaje na koniec każdej zmiany krótki dokument tekstowy. Agent bierze dane z PI za ostatnie 8 godzin, wylicza średnie, maksima i minima dla kluczowych tagów, zestawia z Event Frames (ile alarmów, ile potwierdzeń, ile przestojów), a potem generuje narrację po polsku: co działało stabilnie, co wymagało interwencji, co warto sprawdzić na kolejnej zmianie. Raport idzie mailem albo do firmowego Teams. Brygadzista nie musi logować się do PI Vision, żeby dostać obraz zmiany.

Monitoring zużycia energii na partię. Tagi licznika energii są w PI od lat, ale nikt ich nie zestawiał z tagiem batch_ID ani z kartą technologiczną wyrobu. Agent po zakończeniu każdej partii liczy zużycie energii na tonę produktu, porównuje z historycznym medianem dla tego wyrobu i pokazuje odchylenie. Jeśli partia zużyła wyraźnie więcej, agent wskazuje godzinę i tag sugerujący powód: dłuższy czas grzania, wyższe ciśnienie, dodatkowy recyrkulat. Dane do analizy kosztowej trafiają do technologów, nie tylko do działu energetycznego.

Odpowiedzi na pytania bez otwierania PI. Kierownik produkcji pisze w Teams: "Kiedy ostatnio linia 3 miała postój dłuższy niż 30 minut i jaki był powód?". Agent zapytuje PI przez API o Event Frames z linii 3, filtruje zdarzenia typu Downtime z Duration powyżej 1800 sekund i zwraca listę z datami i nazwami zdarzeń. Odpowiedź pojawia się w ciągu kilku sekund. Kierownik nie loguje się do PI, nie szuka we właściwym module, nie czeka na raport z IT.

Jak wygląda wdrożenie krok po kroku?

• Audyt tagów: razem z Waszym zespołem identyfikujemy, które tagi są istotne dla pierwszego scenariusza. Przy tysiącach tagów nie analizujemy wszystkiego od razu, zaczynamy od jednego ciągu technologicznego.
• Dostęp do PI Web API: konfigurujemy konto serwisowe z prawami odczytu w PI, ustawiamy Kerberos lub Basic Auth, testujemy dostępność endpointów z serwera, na którym staje redAI.
• Instalacja agentów na Waszym serwerze: redAI ląduje na maszynie w Waszej sieci, w segmencie IT lub w strefie DMZ między OT a IT. Serwer może być fizyczny lub wirtualny.
• Konfiguracja pierwszego scenariusza: definiujemy listę tagów, okno czasowe, logikę wykrywania anomalii albo harmonogram raportów. Testujemy na danych historycznych, żeby skalibrować czułość agenta.
• Uruchomienie i strojenie: przez pierwsze dwa tygodnie monitorujemy alerty i raporty razem z Waszym zespołem. Dostosowujemy progi, dodajemy kontekst z PI AF, rozszerzamy na kolejne tagi.

Dane zostają na Waszym serwerze

Dane procesowe są wrażliwe. Zawierają receptury, parametry technologiczne, timing produkcji. Właśnie dlatego cały model językowy i logika agentów działają na Waszej infrastrukturze, nie w zewnętrznej chmurze. Agent czyta dane z PI przez sieć wewnętrzną. Przetwarza je lokalnie. Wyniki: alert, raport, odpowiedź na pytanie, trafiają do wskazanego kanału komunikacji. Surowe wartości tagów nigdy nie opuszczają Waszej sieci.

PI pozostaje jedynym źródłem prawdy o procesie. redAI tylko zadaje mu pytania i interpretuje odpowiedzi.

Od czego zaczynamy?

Punkt startowy to zwykle jedno konkretne pytanie, które ktoś w zakładzie zadaje regularnie i czeka na odpowiedź dłużej, niż powinien. "Kiedy ta linia ostatnio stała?", "Ile energii zjadła ta partia?", "Czy temperatura reaktora zachowuje się normalnie na tej zmianie?". Jeśli PI ma dane, agent AI może zacząć odpowiadać po konfiguracji dostępu.

Jeśli chcecie sprawdzić, które z Waszych tagów nadają się do pierwszego scenariusza, zapraszamy na bezpłatny audyt. Jak wyglądają takie wdrożenia w praktyce, pokazujemy w realnych wdrożeniach.