Jak AI czyta dane z systemu SCADA i co z nimi robi: alarmy, postoje i raport zmianowy w Ignition, Wonderware i WinCC

AI połączone z systemem SCADA nie zmienia niczego w sterowaniu maszyną. Łączy się z bazą historiana tylko do odczytu, pobiera to, co SCADA już zebrał przez miesiące i lata: przebiegi parametrów, dziennik alarmów, czasy postojów, stany linii. Z tych danych robi to, czego kierownik zmiany zwykle nie ma czasu zrobić ręcznie: tłumaczy kody alarmów na zrozumiały opis, zestawia powody przestojów, wychwytuje odchylenia parametrów zanim linia stanie i pisze raport zmianowy bez udziału człowieka.

Co kryje historian SCADA i skąd AI bierze dane

Każdy nowoczesny system SCADA prowadzi bazę historiana: zapisuje wartości tagów co określony interwał albo przy każdej zmianie wartości. W Ignition te dane siedzą w tabelach sqlth_te (definicje tagów: nazwa, typ danych, jednostka, zakres) i sqlt_data_1_1 (wartości z timestampem i flagą jakości). W AVEVA Wonderware to IndustrialSQL Server z widokami takimi jak History i Live, a zapytania można pisać z parametrami wwRetrievalMode (np. Cyclic albo Delta) i wwVersion. WinCC (Siemens) trzyma archiwa procesowe w bazie dostępnej przez WinCC OLE DB Provider, z osobnymi archiwami dla wartości ciągłych i dla stanów binarnych.

AI nie dotyka sterownika PLC. Nie ma dostępu do warstwy sterowania. Czyta bazę danych, tak jak czytałby ją analityk z laptopem: zapytaniami SQL albo przez API. Ignition od wersji 8.x ma wbudowane REST API i Named Query dostępne z sieci IT przez odpowiednio skonfigurowaną bramę. To tam AI szuka tagów takich jak [default]Linia1/Temperatura_wejscia czy [default]Piec1/Cisnienie_robocze. Wonderware wystawia dostęp przez IntelliSOURCE albo bezpośrednie zapytania do IndustrialSQL, gdy jest dostęp sieciowy do tego serwera.

Zanim w ogóle pojawi się AI, trzeba wiedzieć, jakie tagi są logowane do historiana i w jakim interwale. U jednego klienta okazało się, że historianowi brakuje temperatur z trzeciej sekcji pieca, bo operator wyłączył logowanie kilka lat wcześniej i nikt tego nie zauważył. AI wykryło lukę natychmiast: zapytania o ten zakres tagów zwracały puste wyniki zamiast wartości. Dlatego od integracji zaczynamy zawsze od przeglądu, co faktycznie leci do bazy.

Jak AI tłumaczy alarmy na język brygadzisty

Dziennik alarmów w Ignition to tabela sqlt_alarm z polami: source (ścieżka tagu), displaypath, eventtime, eventtype (active, clear, ack) i priority (diagnostic, low, medium, high, critical). W Wonderware odpowiada temu tabela AlarmHistory z analogicznymi kolumnami. Operatorzy widzą te dane na ekranie podczas zmiany, ale rzadko ktoś do nich wraca po fakcie.

Typowy komunikat alarmowy wygląda tak: E_HH_TC1_045 HIGH-HIGH TEMP ZONE 3. Operator wie, że to poważny alarm temperaturowy. Ale nie zawsze wie od razu, czy to temperatura materiału, nadmuchu czy oleju hydraulicznego w tej strefie. I nie pamięta, jak ten alarm zachowywał się trzy miesiące temu.

AI, podpięte do bazy tagów i krótkiego słownika technologicznego linii, przetłumaczy to na: "Temperatura w strefie grzewczej nr 3 przekroczyła górną granicę bezpieczeństwa ustawioną na 185°C. Ostatni raz ten alarm był aktywny 14 dni temu, trwał 22 minuty i doprowadził do postoju. W historii tego tagu widać trend wzrostowy od 6 godzin. Sprawdź chłodzenie strefy i zawór regulacyjny CV-031." Brygadzista dostaje tę informację na telefon lub tablet na hali, zanim zdąży przez magazyn dojść do szafy sterowniczej.

To nie wymaga żadnej dodatkowej konfiguracji w SCADA. AI czyta te same tabele, które system ma od lat. Słownik technologiczny, czyli mapowanie kodów tagów na zrozumiałe opisy, budujemy razem z automatykiem zakładu. Kilka godzin pracy. Ale bez tego tłumaczenie alarmów pozostaje powierzchowne i mało użyteczne dla kogoś z produkcji.

Zestawienie postojów: co ginie w zeszytach i arkuszach

Czas pracy linii i czasy przestojów są w historianach. Problem polega na tym, że są rozproszone po tagach stanu. W Ignition tag [default]Linia1/Stan_linii może mieć wartości 0 (stop), 1 (bieg), 2 (awaria), 3 (planowana przerwa), 4 (czyszczenie). Żeby zestawić postoje według przyczyn, trzeba te wartości połączyć z alarmami z tego samego okna czasowego i z ewentualnymi wpisami operatora w module raportów Ignition albo w papierowej książce awarii.

AI robi to zapytaniem do kilku tabel jednocześnie. Na wyjściu dostajemy zestawienie dla konkretnej zmiany albo tygodnia:

• Awaria elektrozaworu EV-012: 3 zdarzenia w tygodniu, łącznie 47 minut postoju, każde poprzedzone spadkiem ciśnienia poniżej 4 bar przez co najmniej 2 minuty
• Brak materiału na wejściu linii: 2 zdarzenia, łącznie 31 minut, oba między godziną 6:00 a 7:00
• Przegrzanie strefy 2 pieca: 1 zdarzenie, 19 minut, alarm TC2_HH
• Planowane mycie CIP: 4 zdarzenia, łącznie 108 minut
• Przyczyna nieustalona (brak alarmu): 2 zdarzenia, łącznie 23 minuty, stan linii: 0, żaden alarm nie był aktywny

Ten ostatni punkt jest cenny. Postój bez aktywnego alarmu to sygnał, że ktoś wyłączył linię ręcznie albo że przyczyną był czynnik, którego SCADA nie monitoruje. Bez automatycznego zestawienia nikt by tego nie wyłapał i nie szukał przyczyny.

Dotąd takie zestawienie robił kierownik zmiany ręcznie, przepisując z papierowej książki awarii albo z pamięci. Jeden z klientów w branży spożywczej odkrył dzięki automatycznemu zestawieniu, że ponad połowa niezaplanowanych postojów w jednym miesiącu miała ten sam kod alarmu z jednego przetwornika ciśnienia. Każda zmiana traktowała to jako osobne zdarzenie, bo każde trwało tylko kilkanaście minut. Nikt nie łączył tych incydentów w całość. Wymiana przetwornika kosztowała mniej niż jeden dzień przestoju linii.

Sygnalizacja odchyleń zanim linia stanie

Historyczny przebieg parametrów pozwala AI wykrywać wzorce, które poprzedzają awarię. Nie wymaga to osobnego modelu predykcyjnego ani dużego projektu data science. Wystarczy zdefiniować reguły na bazie historii tagów z konkretnego zakładu.

Przykład z produkcji: temperatura łożyska silnika napędowego przez rok rosła stabilnie o 2 stopnie tygodniowo. Przed awarią silnika, trzy tygodnie wcześniej, tempo wzrostu wyraźnie przyspieszało. AI, odpytując historian co godzinę, porównuje bieżące tempo wzrostu wartości tagu ze wzorcem z ostatnich 30 dni. Gdy tempo jest wyraźnie wyższe niż mediana z tego okresu, wysyła sygnał do działu utrzymania ruchu. Nie "silnik za gorący", tylko: "temperatura łożyska L3 rośnie szybciej niż w ostatnim miesiącu, zbliża się do wartości obserwowanej trzy tygodnie przed awarią z 12 marca."

W Ignition te dane są dostępne w historianach tagów: kolumny t_stamp (timestamp w milisekundach Unix), floatvalue i quality. AI wylicza pochodną trendu na prostym zapytaniu SQL z oknem czasowym. Bez zewnętrznych bibliotek ML, bez platformy analitycznej. Działa na każdej bazie historiana, nawet starszej generacji.

Ważne ograniczenie: AI sygnalizuje odchylenie, ale nie diagnozuje przyczyny. Decyzja, czy wezwać serwis zewnętrzny, zatrzymać linię profilaktycznie czy tylko zwiększyć częstotliwość monitoringu, należy do technika utrzymania ruchu. AI dostarcza kontekst i historię. Człowiek decyduje.

Raport zmianowy: co AI pisze zamiast kierownika

Raport zmianowy w wielu polskich zakładach to albo kartka papieru przy zegarach, albo plik Excel otwierany raz w miesiącu przez dyrektora produkcji. Albo nie istnieje, bo zmiana skończyła się o 22:00 i nikt nie miał zamiaru zostać, żeby to wypełniać.

AI może generować raport zmianowy automatycznie na koniec każdej zmiany. Bierze dane z historiana za ostatnie 8 godzin i wypełnia szablon ustalony wcześniej z kierownikiem produkcji:

• Czas pracy linii vs. plan: ile godzin linia pracowała, ile stała i jaka jest przyczyna każdego postoju
• Odchylenia parametrów: które tagi wyszły poza zakres normalny, na jak długo i o ile
• Alarmy aktywne i skwitowane: ile alarmów, priorytet, czas od aktywacji do skwitowania
• Numer partii produkcyjnych: z tagu [default]Linia1/Nr_partii, jeśli jest logowany w historianach
• Uwagi dla następnej zmiany: generowane na podstawie aktywnych alarmów i trendów, które mogą rozwinąć się w kolejnych godzinach

Raport trafia mailem do kierownika produkcji i dyrektora przed końcem zmiany lub tuż po jej zakończeniu. Kierownik wchodzi rano i ma obraz tego, co działo się w nocy, bez dzwonienia do brygadzisty i bez szukania zeszytu na hali.

W Wonderware dane do raportu pobieramy z widoków History i tabeli AlarmHistory. W WinCC przez WinCC OLE DB Provider z archiwów procesowych i archiwum alarmów. Ignition ma wbudowany moduł Reporting, ale AI generuje raport w formacie czytelnym dla managera, nie tylko dla operatora: zdania zamiast tabelek, priorytety zamiast kodów, kontekst zamiast surowej wartości tagu.

Od czego zaczynamy spinanie AI z SCADA

Pierwsze pytanie to dostęp sieciowy. Sieć OT jest w większości polskich zakładów odseparowana od sieci IT i od Internetu. Dobrze: tak powinno być. AI nie potrzebuje bezpośredniego dostępu do sieci OT. Typowa architektura wygląda tak:

• SCADA zapisuje dane do historiana w sieci OT lub w strefie DMZ
• Serwer AI łączy się z repliką bazy w DMZ albo z serwerem pośrednim odpytującym historiana
• Zapytania idą wyłącznie w kierunku odczytu, przez dedykowane konto bez uprawnień do zapisu ani do konfiguracji SCADA
• AI nie ma połączenia do serwera SCADA ani do sterowników PLC

Przed wdrożeniem potrzebujemy kilku rzeczy. Listy tagów logowanych do historiana: eksport z Ignition Tag Browser albo z Wonderware Object Viewer. Dostępu do schematu bazy: nazwy tabel, typy danych, interwały logowania. I kontaktu z automatykiem, który zna logikę alarmów w tym konkretnym zakładzie.

Bez automatyka słownik alarmów pozostaje ogólny i mało użyteczny. Kody w Ignition wyglądają tak: [default]Press/P1/PressureHH. AI musi wiedzieć, że P1 to prasa nr 1 na stanowisku 3, że PressureHH to ciśnienie hydrauliczne (nie powietrzne), że normalny zakres roboczy to 60-80 bar i że w tym zakładzie mówi się na to "prasa główna". Ten słownik budujemy z automatykiem, nie z dokumentacji producenta SCADA. To kilka godzin pracy, ale ona w dużej mierze decyduje o tym, czy tłumaczenie alarmów jest faktycznie użyteczne dla brygadzisty.

Pierwsze wdrożenie zaczynamy od jednego, konkretnego zadania: albo automatyczny raport zmianowy, albo zestawienie przestojów po przyczynach. Jedno działające solidnie przez tydzień robi więcej dla zaufania do systemu niż pięć funkcji zrobionych na pół gwizdka. Dopiero potem dokładamy kolejne warstwy.

Jeśli chcesz zobaczyć, jak wyglądało to w innych zakładach, zajrzyj do realnych wdrożeń. Albo umów 15 minut rozmowy i powiedz nam, jaki system SCADA macie i co sprawia wam dziś największy ból przy raportowaniu zmianowym. Powiemy wprost, co da się zrobić szybko, a co wymaga więcej przygotowania.