Jak AI czyta dane z maszyn przez OPC UA i sterowniki PLC Siemens i Beckhoff bez systemu SCADA?

Tak, da się podłączyć AI bezpośrednio do sterownika maszyny i wyciągać z niego liczniki sztuk, alarmy i czasy przestojów bez kupowania pełnego systemu SCADA. Sterowniki Siemens S7-1500 (firmware 2.0 i wyżej) mają wbudowany serwer OPC UA, Beckhoff TwinCAT udostępnia dane przez protokół ADS, a dla starszych maszyn wystarczy mała bramka, np. Kepware KEPServerEX albo Ignition Edge zainstalowane na komputerze przemysłowym przy maszynie. AI czyta te dane, liczy OEE, odpowiada mistrzowi zmiany i przygotowuje raport zmianowy bez ręcznego przepisywania liczb.

Co siedzi w sterowniku i jakie tagi naprawdę warto zbierać?

Sterownik PLC to w dużym uproszczeniu komputer, który liczy sztuki, mierzy czasy, reaguje na czujniki i zapisuje alarmy. Te dane są w nim cały czas. Tylko nikt ich nie zbiera w sposób przydatny dla mistrza zmiany albo planisty produkcji. Typowe tagi, czyli zmienne w sterowniku, które interesują AI:

• Liczniki sztuk: np. tag DB100.DBD0 w notacji Siemens S7 albo MAIN.nProducedParts w Beckhoff TwinCAT, wartość rośnie z każdym wyrobem opuszczającym maszynę
• Stan pracy i postoju: wartość 0 to postój, 1 to praca automatyczna, 2 to przezbrojenie albo awaria, różni producenci kodują to nieco inaczej, ale schemat jest podobny
• Alarmy z kodami i znacznikami czasu: np. alarm E101 to przegrzanie strefy 2, E203 to brak materiału, każdy alarm ma pole czasu startu i zakończenia, które normalnie nikt nie analizuje
• Czas cyklu: ile sekund trwało zrobienie jednej sztuki, mierzony wewnętrznie albo przez licznik i zegar sterownika
• Temperatury i ciśnienia: np. temperatura formy wtryskowej w stopniach Celsjusza albo ciśnienie hydrauliki w barach, bezpośrednio z przetworników podpiętych do sterownika

U jednego klienta z branży wtrysku tworzyw pracowaliśmy z Siemens S7-1500, gdzie każda maszyna miała osobny blok danych DB100 z polem ProducedParts, MachineState i tablicą alarmów AlarmBuffer[0..19]. Mistrz odczytywał te liczby raz na zmianę, chodząc fizycznie od maszyny do maszyny z kartką. Nikt nie wiązał ich z numerem zlecenia z ERP. Dane były, nikt ich nie używał.

Jak fizycznie wygląda podłączenie: OPC UA, S7comm, ADS i Modbus TCP

Tu są cztery drogi, zależnie od tego, co stoi na hali. Każda wymaga czegoś innego od automatyka i od infrastruktury sieciowej.

OPC UA to dzisiaj najczystsze podejście. Siemens S7-1500 z firmware 2.0 i wyżej oraz Beckhoff TwinCAT 3.1 Build 4024+ mają wbudowany serwer OPC UA, który włącza się w konfiguracji sterownika w TIA Portal (dla Siemensa) albo w XAE (dla Beckhoffa). Serwer słucha domyślnie na porcie 4840 TCP, AI łączy się z nim przez sieć, uwierzytelnia certyfikatem X.509 albo nazwą użytkownika i hasłem, i czyta tagi po ich NodeID, np. ns=3;s="DB100"."ProducedParts". Nie trzeba żadnego dodatkowego oprogramowania pośredniczącego.

S7comm działa dla starszych Siemens S7-1200 i S7-300/400, które OPC UA nie mają. Biblioteki takie jak python-snap7 albo sterowniki w Node-RED czytają bloki danych DB bezpośrednio przez port 102 TCP. Wymaga to dostępu sieciowego do CPU i wyłączenia ochrony bloku (PUT/GET access musi być włączony w właściwościach CPU w TIA Portal). Wiele polskich firm ma właśnie te sterowniki, kupione 10-15 lat temu, i nadal działają bez zarzutu.

Beckhoff ADS to protokół komunikacyjny TwinCAT. Aplikacja na serwerze AI łączy się z ADS Routerem przez port 48898, podaje NetID sterownika i czyta symbolicznie po nazwie zmiennej, np. MAIN.nCounter albo MAIN.bRunning. Beckhoff dostarcza oficjalne biblioteki ADS dla .NET, Python i C++. NetID to sześciocyfrowy identyfikator sterownika, który automatyk zna z konfiguracji XAE.

Modbus TCP obsługuje starsze maszyny, napędy, falowniki i sprzęt, który nie ma nic innego. AI czyta rejestry holding (funkcja 03) albo coils (funkcja 01) pod konkretnymi adresami. Bywa, że jedyna dokumentacja to tabela w PDF od producenta maszyny z listą rejestrów i ich znaczeń. Tę tabelę trzeba mieć, bez niej nie wiadomo, co kryje się pod adresem 40001.

Gdy maszyny mają różne protokoły albo sieć OT jest słabo ustrukturyzowana, wchodzi w grę bramka: Kepware KEPServerEX albo Ignition Edge od Inductive Automation, zainstalowane na komputerze przemysłowym przy maszynie lub w szafie sterowniczej. Kepware ma gotowe sterowniki (tzw. drivers) do S7, Modbus, Mitsubishi, Fanuc i kilkudziesięciu innych protokołów. Zbiera dane z różnych źródeł i wystawia jedno, spójne drzewo tagów przez OPC UA albo REST. AI widzi jeden serwer, nie cztery różne protokoły i trzy różne biblioteki.

Dostęp do serwera OPC UA wymaga: adresu IP serwera lub bramki, numeru portu (domyślnie 4840), certyfikatu klienta albo nazwy użytkownika i hasła, oraz listy NodeID-ów tagów do odczytu. Tę listę eksportuje się z TIA Portal (plik XML z przestrzeniami nazw OPC UA) albo uzupełnia ręcznie z pomocą automatyka. Bez tej listy AI nie wie, pod jakim adresem w drzewie szukać licznika sztuk na tej konkretnej maszynie.

Co AI robi z tymi danymi każdego dnia na hali?

Samo zbieranie tagów to dopiero połowa roboty. Ważniejsze jest to, co AI robi z ciągiem wartości, które co kilka sekund napływają z kilkunastu maszyn.

• OEE na bieżąco: AI liczy dostępność (czas pracy podzielony przez czas planowany), wydajność (wyprodukowane sztuki względem nominalnego tempa) i jakość (jeśli jest licznik braków w sterowniku). Bez Excela, bez czekania do końca zmiany.
• Odpowiedź na pytanie "która maszyna stoi i od kiedy?": mistrz zmiany pisze na czacie albo w komunikatorze, AI sprawdza aktualny stan tagów i odpowiada: "Maszyna M04 jest zatrzymana od 14:32, ostatni alarm E101: przegrzanie strefy 2, czas trwania 23 minuty."
• Liczniki per zmiana i per zlecenie: AI zna czas startu zmiany z harmonogramu albo z sygnału w sterowniku i sumuje sztuki od tego momentu. Jeśli jest połączenie z ERP, wiąże licznik ze zleceniem produkcyjnym i pokazuje, ile brakuje do planu.
• Historia przestojów z przyczyną: nie tylko "maszyna stała 47 minut", ale "stała z powodu alarmu E203: brak granulatu, trzy razy w trakcie zmiany rannej, łącznie 1 godzina 12 minut". AI grupuje przestoje według kodu alarmu.
• Raport zmianowy: o zakończeniu zmiany AI generuje dokument z liczbą sztuk, OEE, listą przestojów z kodami i flagą odchylenia czasu cyklu. Mistrz dostaje go na maila albo w aplikacji, bez ręcznego przepisywania z karty zmiany.
• Sygnał przed awarią: jeśli czas cyklu zaczyna rosnąć (np. przez ostatnią godzinę skoczył z 12 sekund do 15-16), AI sygnalizuje odchylenie przed zatrzymaniem maszyny. To nie przepowiednia, to obserwacja trendu na danych, które zawsze tam były, tylko nikt ich nie śledził w czasie rzeczywistym.

Typowo wygląda to tak, że po uruchomieniu mistrz zmiany przestaje chodzić od maszyny do maszyny i zamiast tego pyta AI przez telefon. Dział utrzymania ruchu dostaje cotygodniowe zestawienie maszyn z największą liczbą powtarzających się alarmów tego samego kodu. Zamiast odkrywać to po kolejnej awarii.

Bezpieczeństwo: sieć OT osobno, brama jednokierunkowa i tylko odczyt

To temat, który pada zawsze przy takich rozmowach. I dobrze.

Zasada jest prosta: AI czyta, nie pisze. Sterownik PLC steruje maszyną i nie może dostać polecenia od zewnętrznego systemu IT. To nie jest kwestia zaufania do AI, to kwestia bezpieczeństwa instalacji i odpowiedzialności za proces.

W praktyce architektura wygląda tak:

• Sieć OT (Operational Technology) jest fizycznie albo logicznie oddzielona od sieci biurowej IT. Maszyny rozmawiają ze sterownikami, ale nie mają bezpośredniego dostępu do internetu ani do serwera ERP.
• Brama lub firewall przemysłowy między siecią OT a serwerem zbierającym dane: dane płyną tylko w jedną stronę, od sterownika do kolektora danych. Serwer AI siedzi po stronie IT i nigdy nie wchodzi do sieci OT.
• Konto OPC UA z uprawnieniami tylko do odczytu: w konfiguracji serwera OPC UA (w TIA Portal lub Kepware) tworzymy konto, które może wyłącznie czytać tagi. Próba zapisu zwraca błąd uprawnień.
• Logi połączeń: Kepware i Ignition Edge zapisują każde połączenie i każdy odczyt. Jeśli coś się dzieje, historia jest dostępna.

Na hali nie budujemy AI, która "mówi maszynie, żeby zwolniła" albo "zmienia parametry procesu". Jeśli ktoś proponuje taką architekturę na starcie, warto zatrzymać rozmowę i powiedzieć wprost o ryzyku zanim zaczniemy cokolwiek instalować.

Od czego zacząć, jeśli chcesz sprawdzić to na swoich maszynach?

Pierwsza rozmowa jest z automatykiem lub firmą serwisującą maszyny. Pytamy o trzy rzeczy: jakie sterowniki stoją na hali, które mają port Ethernet, i czy na S7-1500 jest już włączony serwer OPC UA. Często automatyk odpowie w ciągu godziny, bo to informacja z dokumentacji maszyny albo z TIA Portal.

Potem wybieramy jedną maszynę pilotażową, najlepiej tę z S7-1500. Automatyk eksportuje listę tagów do XML z TIA Portal, włącza konto odczytowe OPC UA i informuje, pod jakim adresem IP słucha serwer. Na tej podstawie stawiamy kolektor danych, może to być prosty skrypt Pythonowy z biblioteką opcua albo asyncua na małym serwerze.

Pierwsze pytania do AI: "ile sztuk zrobiła zmiana dzienna na M04?", "jakie alarmy były dziś rano na M02?". Pierwsze odpowiedzi pokazują, czy dane mają sens i gdzie brakuje kontekstu, zazwyczaj jest to brak wiązania z numerem zlecenia z ERP albo brak informacji o nominalnym czasie cyklu, bez której OEE wychodzi bez sensu.

Python-snap7 i asyncua są open source. Serwer OPC UA w S7-1500 nie wymaga dodatkowej licencji od Siemensa. Kepware i Ignition Edge mają wersje trial do testów. Bariera wejścia jest niska, a po tygodniu pilotażu widać, jakie dane naprawdę wychodzą ze sterownika i co z nimi zrobić.

Jeśli chcesz sprawdzić, co da się wyciągnąć z maszyn w Twojej firmie i jak podpiąć to pod AI, zamów bezpłatny audyt. Możesz też zobaczyć, jak wyglądają realne wdrożenia w polskich zakładach produkcyjnych.