Jak AI czyta zmienne procesowe i alarmy z Asix.Evo i co z tego ma kierownik produkcji?

Tak, to możliwe. AI może czytać dane zgromadzone przez Asix.Evo, korzystając z bazy SQL, w której system archiwizuje zmienne procesowe i alarmy. Nie ma do tego gotowego publicznego API, ale dostęp do bazy z uprawnieniami tylko do odczytu wystarczy. Kierownik produkcji dostaje wtedy poranne podsumowanie z hali, zanim zadzwoni do brygadzisty.

Gdzie dziś ucieka czas w zakładzie pracującym na Asix.Evo?

Asix.Evo pracuje na wielu stanowiskach jednocześnie: inżynierowie automatycy pilnują trendów, operatorzy reagują na alarmy, kierownik produkcji co rano pyta o wyniki. W praktyce każdy widzi swój wycinek. Nikt nie ma widoku na całość w jednym miejscu, bez klikania między ekranami.

Typowy poranek wygląda tak. Kierownik produkcji dzwoni do brygadzisty, żeby dowiedzieć się, dlaczego linia nr 2 stała dwie godziny w nocy. Brygadzista otwiera historię alarmów, sprawdza zapis zmiany, cofa się do trendów ciśnienia. Odpowiedź zajmuje dwadzieścia minut. Przez cały ten czas nie wiadomo, czy tamta partia z nocnej wymaga inspekcji.

Gdzie konkretnie ucieka czas:

• Analiza alarmów po fakcie: historia alarmów istnieje w systemie, ale przeglądanie jej ręcznie po każdej zmianie to praca, której nikt nie lubi robić co rano.
• Łączenie danych z różnych ekranów i systemów: trend parametru procesowego jest w jednym miejscu, zlecenie w ERP, receptura u technologa. Połączenie tych trzech to kilkanaście minut dla doświadczonego człowieka.
• Raporty przestojów i OEE: Asix może generować raporty, ale ich przygotowanie na żądanie zajmuje czas, a ad hoc nikt nie pyta systemu SCADA w biegu.
• Obsługa pytań z innych działów: handlowiec pyta planistę, planista pyta technologa, technolog patrzy w trendy Asix. Łańcuch komunikacji dla jednego pytania o partię.
• Szukanie przyczyny niezgodności: gdy pojawi się reklamacja albo wynik poza tolerancją, ktoś musi przekopać się przez archiwum parametrów z czasu produkcji tej konkretnej partii.

AI nie zastępuje operatora przy pulpicie. Ale radzi sobie świetnie z tym, co teraz leży między ekranami i działami.

Jakie dane trzyma Asix.Evo i które z nich czytamy?

Asix.Evo to pakiet HMI/SCADA/MES polskiego producenta, firmy ASKOM z Gliwic. System zbiera dane bezpośrednio ze sterowników PLC, między innymi Siemens S7, i archiwizuje je w bazie danych SQL. Ta baza jest głównym punktem dostępu dla AI.

Co konkretnie Asix przechowuje i co czytamy:

• Zmienne procesowe: wartości z czujników i sterowników, archiwizowane w określonych interwałach. Temperatura pieca, ciśnienie w sieci pneumatycznej, prędkość taśmy, licznik cykli maszyny. Każdy pomiar ma znacznik czasu, co pozwala AI odtworzyć, jak wyglądał parametr na godzinę przed alarmem.
• Alarmy i zdarzenia: każde wyjście zmiennej poza granicę, każde potwierdzenie alarmu przez operatora, każde przejście w stan awaryjny. Z datą, godziną, identyfikatorem zmiennej i treścią komunikatu.
• Archiwum trendów: historia wartości zmiennych w czasie. Z niej można odtworzyć przebieg każdego parametru procesowego w dowolnym oknie czasowym, od ostatniej godziny do ostatniego roku.
• Dane z modułu raportowania: Asix ma moduł raportowania, który może zbierać dane w strukturach zbliżonych do MES: liczniki produkcji, czasy pracy i przestojów, wydajność w poszczególnych zmianach.

Czego nie będziemy szukać w Asix: zleceń produkcyjnych, receptur z wagami składników, danych kontrahentów, historii reklamacji. Te informacje są zwykle w ERP albo w systemie technologa. Asystent AI, który naprawdę pomaga zakładowi, czyta z kilku źródeł jednocześnie. Asix daje mu warstwy procesową i alarmową, ERP daje zlecenia i partie. Razem odpowiada na pytania, których żaden z tych systemów z osobna nie jest w stanie obsłużyć.

Jak fizycznie podłączyć AI do Asix.Evo?

Asix.Evo nie ma publicznie opisanego REST API. Producent, firma ASKOM z Gliwic, nie dokumentuje na swoich stronach interfejsu, przez który zewnętrzna aplikacja mogłaby odpytywać system zapytaniami HTTP. Mówimy o tym wprost, bo inaczej po miesiącu okazałoby się, że czegoś nie ma.

Realna droga dostępu prowadzi przez bazę danych SQL, w której Asix archiwizuje dane procesowe. To podejście, które stosujemy przy takich wdrożeniach: czytamy tabele archiwum bezpośrednio, z konta tylko do odczytu, bez jakiejkolwiek ingerencji w warstwy sterowania.

Co trzeba zorganizować po stronie firmy:

• Dostęp do serwera bazy danych: Asix archiwizuje dane w SQL Server lub innym silniku SQL skonfigurowanym przy wdrożeniu. Potrzebne jest konto z uprawnieniami wyłącznie do odczytu (SELECT) na tabelach archiwum, alarmów i zdarzeń. Żadnych uprawnień do zapisu ani do tabel konfiguracyjnych.
• Mapowanie struktury tabel: nazwy i struktura tabel archiwum zależą od konkretnej instalacji Asix i od tego, jak ją skonfigurował automatyk wdrażający system. Przy starcie mapujemy te tabele razem z automatykiem, który tę instalację zna.
• Reguły sieciowe OT/IT: serwer SCADA często siedzi w sieci OT oddzielonej od sieci IT. Dostęp do bazy SQL z segmentu IT wymaga ustalonych reguł firewalla i decyzji działu automatyki oraz IT o tym, co i skąd jest dopuszczalne. Asystent AI pracuje po stronie IT. Warstwy sterowania nie dotykamy.
• Eksporty jako plan awaryjny: jeśli bezpośredni dostęp do bazy jest niemożliwy z powodu polityki sieci, AI może pracować na eksportach. Asix może generować raporty i pliki odkładane w ustalonym folderze sieciowym. To wolniejsze podejście, ale realne tam, gdzie dział OT nie zgodzi się na bezpośrednie połączenie z bazą.

Czego nie ruszamy nigdy: sterowników PLC, warstwy komunikacyjnej OPC, konfiguracji projektów Asix. AI nie pisze do żadnej tabeli, nie modyfikuje zmiennych, nie wchodzi w logikę sterowania. To nienaruszalna granica i od tego nie robimy wyjątków.

Pięć scenariuszy z życia zakładu: pytanie i co dostaje człowiek

Scenariusz 1: Poranne podsumowanie dla kierownika produkcji.

Kierownik produkcji zaczyna zmianę od pytania: "Co się działo na nocnej?" Zamiast dzwonić do brygadzisty, otwiera asystenta. AI przejrzało archiwum alarmów z ostatnich ośmiu godzin, wyciągnęło przestoje dłuższe niż pięć minut i zestawiło je z wartościami zmiennych procesowych z tamtego okresu. Wynik: trzy alarmy na linii 2, przestój 47 minut od 02:14 do 03:01, temperatura w strefie grzania spadła poniżej dolnego progu i wtedy właśnie automat zatrzymał linię. Brygadzista dostaje to samo zestawienie, zanim przyjdzie na odprawę.

Scenariusz 2: "Dlaczego ta partia wyszła poza tolerancją?"

Kontroler jakości przychodzi z wynikiem pomiaru: parametr końcowy partii numer 2847 jest poza granicą specyfikacji. Chce wiedzieć, co działo się na hali podczas jej produkcji. AI bierze numer partii z ERP, wyciąga okno czasowe produkcji, a potem w archiwum Asix przegląda wszystkie zmienne procesowe z tamtego okresu. Raport: temperatura w strefie 3 była powyżej górnej granicy procesu przez 12 minut, alarm był potwierdzony przez operatora o 11:43, produkcja trwała dalej. To są fakty do karty niezgodności. Kontroler decyduje, co z nimi zrobić.

Scenariusz 3: Przygotowanie danych do karty reklamacji 8D.

Klient złożył reklamację na partię z zeszłego tygodnia. Dział jakości musi wypełnić kartę 8D: opis problemu, warunki produkcji, dowody zebrania danych. Ręcznie to kilkugodzinne szukanie w trzech systemach. AI wyciąga z ERP numer partii, recepturę i zlecenie. Z Asix pobiera archiwum parametrów procesowych z czasu produkcji. Z historii alarmów sprawdza, czy były odchylenia i kiedy. Oddaje gotowy zbiór danych z datami, godzinami, wartościami. Człowiek pisze wnioski, przyczynę główną i działania korygujące, bo to jego odpowiedzialność i jego wiedza procesowa.

Scenariusz 4: Wczesne ostrzeganie dla utrzymania ruchu.

Dział UR chce śledzić temperaturę łożyska pompy numer 7 z ostatnich czterech tygodni. Nie ma jeszcze alarmu, ale ostatni przegląd wykazał lekkie zużycie. AI przegląda archiwum zmiennej procesowej dla tego czujnika i pokazuje trend w czasie: wartość systematycznie rośnie, aktualnie jest o kilka stopni wyżej niż cztery tygodnie temu, do górnej granicy procesu zostało tyle a tyle. Dział UR sam ocenia, kiedy zaplanować wymianę, bo zna specyfikę tej pompy i cykl remontowy lepiej niż jakikolwiek system.

Scenariusz 5: Odpowiedź handlowcowi na pytanie o realny termin.

Handlowiec pyta planistę: "Kiedy realnie wyjdzie zlecenie dla klienta X?" Żeby odpowiedzieć rzetelnie, planista musi wiedzieć nie tylko, kiedy linia jest wolna w planie, ale też jak długo faktycznie pracuje na podobnych zleceniach. Plan to jedno, historia przestojów to drugie. AI łączy dane zlecenia z ERP z historyczną dostępnością linii z Asix. Daje planistce kontekst: przez ostatnie cztery tygodnie linia 1 miała dwa przestoje dłuższe niż godzinę, wydajność była stabilna z wyjątkiem wtorkowych porannych rozruchów. Planistka wyciąga wniosek o terminie i komunikuje go handlowcowi. Bez telefonowania na halę.

Co zostaje przy człowieku i gdzie są granice tej integracji?

AI nie steruje halą. Nie zatrzymuje maszyn, nie zmienia parametrów procesowych, nie reaguje na alarmy w czasie rzeczywistym. To absolutna granica. Chodzi nie tylko o możliwości techniczne, ale o bezpieczeństwo i odpowiedzialność. Automatyk, operator i kierownik zmiany decydują o tym, co dzieje się ze sterownikami.

Co jeszcze zostaje przy człowieku:

• Ocena jakości danych: AI czyta to, co jest w bazie. Jeśli sensor jest rozregulowany albo operator błędnie potwierdził alarm, AI tego samodzielnie nie wykryje. Walidacja jakości danych procesowych to praca automatyków.
• Decyzje produkcyjne: "Czy puścić tę partię dalej?" to pytanie do kierownika produkcji i technologa. AI daje im fakty do podjęcia tej decyzji szybciej i bez szukania w trzech miejscach.
• Zarządzanie progami alarmów: AI może powiedzieć, że jeden konkretny alarm w strefie 4 włączał się przez ostatnie trzy miesiące kilkadziesiąt razy i za każdym razem był potwierdzany bez zmiany parametrów. To sygnał do przeglądu konfiguracji progów przez automatyka. Decyzję o zmianie podejmuje automatyk, nie AI.
• Konfiguracja Asix: projekty, progi, receptury alarmowe, konfiguracja sterowników i topologia komunikacyjna. Żadna z tych warstw nie jest dostępna dla AI i tak powinno zostać.

Granica jest też po stronie danych. Asix archiwizuje to, co zbierają czujniki i sterowniki. Nie ma tam wiedzy o tym, dlaczego klient zmienił zamówienie w ostatniej chwili, dlaczego dostawa surowca się spóźniła albo dlaczego zmieniono recepturę w połowie serii. AI sięga po te informacje przez inne systemy: ERP, e-mail, dokumenty jakościowe. Wartość tej integracji rośnie, gdy Asix nie jest jedynym źródłem.

Jak zacząć, żeby nie ugrzęznąć na etapie uzgodnień?

Nie zaczynamy od podłączenia wszystkich zmiennych naraz. Zakłady produkcyjne z Asix mają w archiwum tysiące zmiennych procesowych. Zaczynamy od jednego konkretnego problemu, który naprawdę boli, i jednej linii albo jednej maszyny.

• Krok 1: Wybór problemu startowego. Jedno pytanie, na które kierownik produkcji dzwoni kilka razy w tygodniu: przestoje na konkretnej linii, trendy jednego parametru, historia alarmów jednej maszyny. Jeden problem, jeden sprint.
• Krok 2: Mapowanie bazy SQL Asix. Razem z automatykiem, który zna tę instalację, identyfikujemy tabele archiwum: gdzie są wartości zmiennych, gdzie są alarmy, jak są nazwane zmienne w tej konkretnej instalacji. Zazwyczaj jeden lub dwa dni pracy.
• Krok 3: Konto tylko do odczytu i reguły sieciowe. Konto SQL z uprawnieniami SELECT, zaakceptowane przez dział IT i OT. Żadnych wyjątków w zakresie uprawnień. Uzgodnienie zasad dostępu między siecią IT i OT. To etap, który w praktyce trwa najdłużej, bo wymaga decyzji po stronie firmy.
• Krok 4: Uruchomienie asystenta na danych historycznych. Pierwsze tygodnie to praca na danych z ostatnich miesięcy, nie na bieżących. Sprawdzamy, czy AI poprawnie interpretuje strukturę tabel, czy odpowiedzi mają sens dla automatyka, który zna te dane.
• Krok 5: Połączenie z ERP lub innym systemem. Gdy odpowiedzi z samego Asix są trafne, dopinamy kolejne źródło: zlecenia z ERP, receptury z systemu technologa. Wartość asystenta rośnie tu skokowo.
• Krok 6: Oddanie kierownikowi i działowi jakości. Poranne podsumowanie, możliwość zadania pytania przez przeglądarkę, raport przygotowany automatycznie przed odprawą. Zbieramy opinie, poprawiamy.

U jednego klienta z branży przetwórstwa spożywczego cały cykl od mapowania bazy do działającego porannego podsumowania zajął niecałe trzy tygodnie. Największe opóźnienie nie leżało po stronie systemu. Leżało po stronie uzgodnienia dostępu sieciowego między OT i IT. To jest typowe i warto to wiedzieć na wejściu, żeby zaplanować czas realnie.

Jeśli chcecie sprawdzić, czy taka integracja ma sens w Waszym zakładzie i od czego konkretnie zacząć, umówcie się na 15 minut rozmowy. Możemy też pokazać, jak wyglądają realne wdrożenia u producentów, zanim podejmiecie decyzję.