Jak AI łączy się z Cognite Data Fusion i co agenci robią z danymi OT i IT na Waszym serwerze?

Cognite Data Fusion to platforma, która zbiera dane z maszyn, sterowników PLC i systemów IT, a potem nadaje im kontekst: wie, który czujnik dotyczy której pompy i że ta pompa stoi na linii numer 3. Kiedy podłączamy do niej agentów AI przez oficjalne API lub Python SDK, agenci pobierają te skontekstualizowane dane OT i IT i przetwarzają je na Waszym własnym serwerze. Wynikiem są konkretne rzeczy: gotowy raport dla zmianowego, alert dla mechanika zanim łożysko zacznie się przegrzewać, albo odpowiedź na pytanie inżyniera bez klikania po czterech systemach. Cognite porządkuje dane. Agenci RedAI zamieniają je w decyzje.

Co Cognite Data Fusion robi z danymi i co z tego czytamy przez API

Nie każda platforma przemysłowa kontekstualizuje dane. Większość zbiera odczyty i na tym koniec. CDF idzie krok dalej: tworzy graf zależności między obiektami fizycznymi a danymi pomiarowymi. Agent AI, który czyta z CDF, nie dostaje tylko liczby "94,3" z jakiegoś czujnika. Dostaje: "temperatura łożyska napędowego wentylatora FAN-03 na linii głównej ciągu, jednostka stopnie Celsius, zakres pracy nominalnej 80-88°C". To jest różnica między surowym sygnałem a informacją, z którą można coś zrobić.

Przez Python SDK (pakiet cognite-sdk) lub REST API czytamy kilka typów zasobów:

• Time series: ciągłe odczyty procesowe, temperatura, ciśnienie, przepływ, prąd silnika, drgania. Każda seria ma swoje ID, jednostkę i powiązanie z asset'em.
• Assets: hierarchia obiektów fizycznych od zakładu przez linię po pojedynczy komponent. W metadanych asset'u mogą siedzieć wartości nominalne, daty produkcji, numery DTR.
• Events: alarmy z SCADA, wpisy z CMMS, zdarzenia procesowe, każde z timestampem i klasyfikacją.
• Relationships: połączenia między zasobami, np. że czujnik TE-201 mierzy temperaturę na wyjściu wymiennika HE-12.
• Files: dokumenty techniczne, schematy P&ID, karty DTR w PDF, dostępne przez to samo API.

Typowe zapytanie agenta wygląda tak: pobierz time series o ID "pump-P101-pressure-outlet" za ostatnie 48 godzin, z rozdzielczością 5 minut. CDF zwraca JSON z punktami pomiarowymi i metadanymi. Agent wie od razu, na jakiej linii stoi pompa i jakie są wartości nominalne, bo to wszystko siedzi w assets metadata. Kontekst jest wbudowany w dane, nie trzeba go rekonstruować z oddzielnych tabel.

Gdzie działa agent i co to znaczy dla bezpieczeństwa Waszych danych

Agenta instalujemy na Waszym serwerze, w tej samej sieci co CDF. Samo CDF może być u Was w chmurze (Azure, AWS, na osobnym tenancie) lub on-premise, zależnie od Waszej konfiguracji z Cognite.

Przetwarzanie danych odbywa się lokalnie. Agent pobiera dane z CDF, przetwarza je na Waszym sprzęcie, generuje wynik. Jeśli korzystacie z lokalnego modelu językowego (np. przez Ollama), cały łańcuch zostaje w firmie. Jeśli zdecydujecie się na zewnętrzne API modelu, konfigurujemy, żeby trafiały do niego tylko zagregowane wartości i treść pytania, bez surowych danych procesowych.

Dostęp agenta do CDF konfigurujemy przez OAuth 2.0, z granularnymi uprawnieniami: agent ma dostęp tylko do tych asset groups, które mu przyznaliście. Jeśli macie kilka zakładów w jednym CDF, agent jednego zakładu nie widzi danych drugiego.

Pięć scenariuszy, gdzie agent realnie pracuje z danymi z CDF

To serce tego wdrożenia. Dane w CDF to potencjał. Agent zamienia go w konkretną pracę.

Raport zmianowy bez zbierania danych z czterech ekranów. Przed końcem każdej zmiany agent odpytuje CDF o ostatnie 8 godzin: time series z wybranych punktów pomiarowych, events z kategorią "ALARM" lub "WARNING", odchylenia od norm z metadanych asset'ów. Generuje tabelę lub plik PDF: co pracowało normalnie, co wykazało odchylenie, co warto odnotować dla kolejnej zmiany. Kierownik zmiany dostaje gotowy dokument w Teams albo na maila, zamiast zbierać dane ręcznie z kilku systemów.

Wykrywanie odchyleń zanim operator to zauważy. Agent śledzi wybrane time series w trybie ciągłym. U jednego klienta skonfigurowaliśmy monitoring temperatury łożysk na wentylatorach ciągu głównego: wartości bazowe dla każdego sezonu były wpisane w metadata każdego asset'u. Kiedy odczyt przekroczył próg przez 15 minut z rzędu, agent wysłał powiadomienie do brygadzisty przez Teams: ID czujnika, asset, lokalizacja, wartość obecna, norma, trend z ostatnich 2 godzin. Nie "coś jest nie tak", tylko "FAN-03, linia 2, temperatura łożyska 94°C, norma 86°C, wzrost od 09:40".

Inżynier zadaje pytanie, agent odpowiada po polsku. Inżynier procesu pisze na czacie: "Jak wyglądało ciśnienie na wyjściu P-101 w środę między 14 a 16?". Agent przeszukuje CDF, pobiera właściwą time series, liczy min, max i średnią dla tego okna czasowego, odpowiada po polsku. Może dodać kontekst z pliku DTR powiązanego z danym asset'em w CDF. Minutę roboty zamiast kwadransu klikania po systemach.

Analiza przyczyny zatrzymania. Po każdym nieplanowanym przestoju agent pobiera z CDF events z ostatnich 2 godzin przed zatrzymaniem i nakłada je na time series wybranych parametrów procesowych. Układa chronologię: o której pojawił się alarm, jak zachowywały się wartości, co się zmieniło jako pierwsze. To nie zastępuje analizy 5-why prowadzonej przez inżyniera, ale daje mu gotowy punkt startowy zamiast kilku godzin zbierania danych z różnych systemów.

Planowanie przeglądów na podstawie rzeczywistego stanu. Agent raz dziennie sprawdza wskaźniki eksploatacyjne dla urządzeń objętych harmonogramem PPM: godziny pracy, liczbę cykli, temperatury eksploatacyjne z time series w CDF. Porównuje je z progami serwisowymi z metadanych asset'ów, np. "przegląd co 2000 godzin roboczych". Jeśli urządzenie zbliża się do progu, agent tworzy draft zlecenia lub wysyła powiadomienie do planisty. Nie reaguje na datę w kalendarzu. Reaguje na rzeczywiste dane.

Jak wygląda wdrożenie od audytu do działającego agenta

Zaczynamy od przeglądu danych w CDF: sprawdzamy, jak wypełnione są metadane asset'ów, czy hierarchia obiektów odpowiada rzeczywistości zakładu, które time series mają ciągłe odczyty bez długich luk. Ten etap trwa jeden, dwa dni, ale warunkuje jakość całej reszty. Agent jest tak dobry, jak dane, z których korzysta.

• Dostęp API: konfiguracja OAuth 2.0, service account z uprawnieniami do wybranych asset groups
• Mapowanie scenariuszy: razem z Waszym zespołem ustalamy, które dane, dla których ról w firmie, w jakim trybie: raport cykliczny, alert w czasie zbliżonym do rzeczywistości czy pytania na czacie
• Instalacja agenta: Docker lub konfiguracja bezpośrednia na Waszym serwerze, w Waszej sieci
• Testy na danych historycznych: agent pracuje na historii z CDF zanim wejdzie w tryb produkcyjny, weryfikujemy jakość odpowiedzi i alertów razem z Waszym zespołem
• Pilot z jedną linią lub działem: pierwsza prawdziwa praca, zbieramy feedback od operatorów i inżynierów przez 2-4 tygodnie
• Rozszerzenie: dołączamy kolejne asset groups, scenariusze i role użytkowników

Od pierwszego spotkania do działającego pilota to zazwyczaj kilka tygodni. Dużo zależy od stanu danych w CDF na starcie: zakład z dobrze opisanymi metadanymi idzie szybciej niż taki, gdzie trzeba najpierw uzupełnić opisy asset'ów i sprawdzić ciągłość time series.

Co zostaje u Was po zakończeniu projektu

Agent działa na Waszym serwerze i po zakończeniu projektu zostaje w Waszych rękach. Nie ma uzależnienia od naszej infrastruktury. Dostarczamy kod źródłowy w Waszym repozytorium Git oraz dokumentację: jakie endpoints są używane, jakie asset groups, jak modyfikować progi alertów i jak dodawać nowe scenariusze bez pisania kodu od zera.

Dane z CDF nie opuszczają Waszej infrastruktury podczas przetwarzania przez agenta. Surowe odczyty procesowe zostają tam, gdzie były. To istotne szczególnie dla zakładów z rygorystycznymi wymaganiami dotyczącymi danych produkcyjnych i OT, gdzie każdy ruch danych poza sieć zakładową wymaga uzasadnienia.

Jeśli macie CDF z danymi, które dziś głównie zalegają w bazie i nikt nie przetwarza ich na bieżąco, sprawdźcie, co agent AI może z nimi zrobić. Zacznijcie od bezpłatnego audytu. Jeśli chcecie zobaczyć, jak podobne wdrożenia wyglądają u innych firm, zajrzyjcie do realnych wdrożeń.