AI w przemyśle 4.0 a stare maszyny: jak połączyć nowe algorytmy z legacy systemami

Dlaczego AI w Przemyśle 4.0 nie wymaga wymiany wszystkich maszyn

Rzeczywistość większości zakładów: miks starego i nowego

Hale produkcyjne rzadko wyglądają jak foldery reklamowe dostawców technologii. Zamiast idealnie nowych linii, częściej stoi tam mieszanka: kilka świeżych gniazd z nowoczesnymi robotami, obok prasy z lat 90., starych tokarek CNC i analogowych urządzeń z ręcznym sterowaniem. Do tego dochodzą różne generacje PLC (Programmable Logic Controller), fragmentaryczna automatyka oraz rozproszone systemy SCADA z różnym stopniem aktualności.

Ten miks generuje wrażenie, że „prawdziwy Przemysł 4.0” jest możliwy dopiero po generalnej wymianie parku maszynowego. To mit. Z punktu widzenia AI i analityki kluczowe jest nie to, z którego roku jest maszyna, lecz czy można z niej w sposób powtarzalny i wiarygodny pobierać sygnały oraz czy da się je powiązać z kontekstem procesu (produkt, partia, zmiana, receptura).

W praktyce oznacza to, że nawet maszyna z lat 80., bez jakiejkolwiek automatyki, może stać się elementem ekosystemu Przemysłu 4.0, jeśli dołożymy kilka czujników, prosty moduł zbierający dane i minimalną integrację z siecią OT. To właśnie podejście retrofit, znane także jako „brownfield AI” – rozwijanie inteligentnej warstwy nad zastaną infrastrukturą.

Koszty i ryzyka „greenfield” vs. retrofit / brownfield AI

Budowa nowej, „zielonej” fabryki (greenfield) to komfort projektowania architektury od zera: spójne protokoły, jednolite standardy, ustandaryzowane sterowniki, centralna platforma danych. Problem w tym, że mało kogo stać na wyłączenie produkcji na lata i inwestycje liczone w ogromnych budżetach. Ryzyko technologiczne (niedopasowanie rozwiązań do realnych potrzeb) oraz organizacyjne (brak kompetencji, opór załogi) jest równie wysokie jak koszt.

Retrofit / brownfield AI działa inaczej: zamiast wymieniać wszystko, identyfikuje się kluczowe maszyny i procesy, a następnie dodaje tam czujniki, bramy IoT, warstwę edge computing i integrację z istniejącym SCADA czy MES. Inwestycję rozkłada się na etapy, testuje się rozwiązania na pojedynczych liniach i rozwija tam, gdzie widać faktyczny zwrot (np. mniej awarii, niższe zużycie energii, krótsze przezbrojenia).

Takie podejście redukuje ryzyko, pozwala uczyć się na mniejszych pilotażach i lepiej dopasować architekturę do realnych ograniczeń – zarówno technicznych (stare kable, zakłócenia elektromagnetyczne, brak miejsca na szafę sterowniczą), jak i ludzkich (przyzwyczajenia operatorów, procedury utrzymania ruchu).

Czego AI faktycznie potrzebuje od maszyn

Nowe algorytmy nie wymagają katalogowo nowych maszyn. AI potrzebuje trzech rzeczy:

• sygnałów i danych – pomiary prądu, wibracji, temperatury, ciśnienia, prędkości, stany wejść/wyjść cyfrowych, kody błędów, receptury, parametry nastaw;
• stabilnej, powtarzalnej pracy – modele uczą się na wzorcach; im bardziej chaotyczna eksploatacja, tym trudniejsze modelowanie;
• kontekstu biznesowego – informacja, co było produkowane, na której maszynie, z jakiej partii surowca, przy jakich ustawieniach.

Roczniki maszyn interesują głównie serwis i księgowość. Modele AI są „obojętne”, czy sygnał prądu pochodzi z falownika z 1995 roku podpiętego przez Modbus, czy z najnowszego napędu z wbudowanym IoT – pod warunkiem, że sygnał jest wystarczająco częsty, spójnie oznaczony czasowo i opisany (metadane).

Dlatego integracja AI z PLC, modernizacja legacy systemów i retrofit czujnikowy są ważniejsze niż wymiana całych maszyn. Zamiast kupować nową prasę, lepiej dołożyć monitoring wibracji i analizę anomalii, która zmniejszy liczbę awarii o kilkadziesiąt procent – to często realniejszy scenariusz niż wymiana całej linii.

Przykład z praktyki: prasy hydrauliczne z lat 90.

Dla zobrazowania: zakład tłoczników dysponował kilkoma prasami hydraulicznymi z końca lat 90. Maszyny miały podstawowe sterowanie, bez rozbudowanego SCADA, tylko kilka sygnałów binarnych oraz stare PLC. Problemem były nieprzewidywalne przestoje – awarie układu hydraulicznego i łożysk, generujące wysokie koszty postoju.

Zamiast wymieniać prasy, wdrożono prosty retrofit:

• dodatkowe czujniki wibracji i temperatury na kluczowych punktach konstrukcji,
• mierniki prądu na zasilaniu głównych silników,
• mini-komputery edge (małe przemysłowe PC) zbierające sygnały z czujników i PLC,
• lokalny model ML wykrywający anomalie sygnałów w czasie rzeczywistym.

Wynik: bez wymiany maszyn zaczęto identyfikować nietypowe wzorce drgań i obciążenia prądem na kilka dni przed wystąpieniem awarii. Utrzymanie ruchu otrzymywało alarmy z wyprzedzeniem i mogło planować prace serwisowe. Kluczowe było to, że stare prasy zapewniały wystarczająco powtarzalną pracę, a dołożone czujniki i bramy IoT w przemyśle wprowadziły je w świat Przemysłu 4.0 bez gigantycznych nakładów.

Inwentaryzacja legacy systemów – z czym naprawdę trzeba się zintegrować

Klasyfikacja parku maszynowego według poziomu „cyfrowości”

Zanim pojawią się jakiekolwiek modele AI, potrzebny jest porządek w wiedzy o tym, co faktycznie stoi na hali. Dobrze sprawdza się prosta klasyfikacja maszyn według poziomu cyfrowej „dojrzałości”:

• Maszyny całkowicie analogowe – brak PLC, proste przekaźniki, wskaźniki zegarowe, brak interfejsów komunikacyjnych. Wymagają retrofit czujnikowy i ewentualnie doposażenie w prosty sterownik.
• Maszyny z prostym PLC – sterowniki bez sieci przemysłowych lub z ograniczonymi protokołami (np. stare wersje Modbus RTU, RS-232/RS-485). Zwykle jest możliwość odczytu podstawowych rejestrów, choć często brak dokumentacji.
• Maszyny z systemami HMI/SCADA – lokalne panele operatorskie, czasem połączone ze starszymi systemami SCADA, często przy użyciu fieldbusów (Profibus, CANopen, DeviceNet). Dane dostępne, ale rozproszone i niespójne.
• Maszyny „pół-OT/IT” – wyposażone w stare serwery OPC, archiwizatory danych (historians), czasem własne bazy SQL, z którymi można się zintegrować. Często jest to dobry punkt zaczepienia dla integracji SCADA z AI.

Taka segmentacja od razu pokazuje, gdzie integracja AI z PLC będzie prosta (nowe sterowniki z otwartymi protokołami), a gdzie trzeba będzie uruchomić sniffing protokołów szeregowych lub budować warstwę pomiarową od zera.

Jak zrobić techniczną inwentaryzację systemów legacy

Inwentaryzacja nie powinna ograniczać się do wpisania nazwy maszyny i rocznika. Potrzebna jest dokumentacja na poziomie, który zaspokaja potrzeby architektury danych i planowania modeli AI. Minimalny zakres dla każdej maszyny:

• typ i producent maszyny, model, rok produkcji, numer seryjny,
• rodzaj sterowania (PLC – jaki, HMI – jaki, brak),
• dostępne interfejsy komunikacyjne (RS-232, RS-485, Profibus, Profinet, Ethernet/IP, CAN, Modbus RTU/TCP, inne),
• lista dostępnych sygnałów procesowych (wejścia/wyjścia analogowe i cyfrowe, liczniki, enkodery, sygnały diagnostyczne),
• istniejąca archiwizacja danych (lokalna baza, SCADA, pliki CSV, brak),
• dokumentacja: schematy elektryczne, schematy pneumatyczne/hydrauliczne, opis zmiennych w PLC (tagi), opisy ekranów HMI.

Dobrym narzędziem jest arkusz kalkulacyjny lub prosty system CMMS/MES, w którym każde urządzenie ma własną „kartę technologiczno-cyfrową”. Celem jest wskazanie, do których maszyn da się podpiąć bramy IoT w przemyśle praktycznie „od ręki”, a które wymagają własnych mini-projektów modernizacji.

Identyfikacja punktów zaczepienia dla AI

Po inwentaryzacji warto wskazać „punkty zaczepienia” – miejsca, gdzie dane już są, ale nie są jeszcze wykorzystywane przez AI. Typowe przykłady:

• PLC z wolnymi portami komunikacyjnymi, z których można odczytywać rejestry procesowe,
• istniejący serwer SCADA, który zbiera dane, ale nikt nie robi na nich analityki zaawansowanej,
• stare serwery OPC lub systemy historians, które można odczytywać przez nowe konektory,
• panele HMI z logowaniem alarmów i zdarzeń – często trzymane w plikach, które da się zaciągnąć do centralnego magazynu.

W drugim kroku identyfikuje się miejsca „prawie gotowe” – tam brakuje jednego lub dwóch czujników, aby zamknąć sensowny zestaw danych dla AI. Przykładowo: tokarka CNC ma sygnały osi i sterowanie, ale brak monitoringu temperatury wrzeciona lub wibracji – dodanie kilku sensorów otwiera drogę do predykcyjnego utrzymania ruchu.

Ocena stanu sieci OT i rola utrzymania ruchu

Integracja Przemysł 4.0 z AI wymaga nie tylko znajomości maszyn, ale i topologii sieci OT (Operational Technology). Należy przeanalizować:

• obecną strukturę sieci (gwiazda, pierścień, segmenty VLAN, stare magistrale szeregowe),
• przepustowość i obciążenie – czy istniejące łącza wytrzymają dodatkowy ruch danych dla AI,
• separację OT i IT – czy sieć produkcyjna jest odizolowana, czy wszystkie urządzenia wpięte są do „jednego wielkiego LAN-u”,
• źródła zakłóceń i awarii – luźne złącza, błędne uziemienie, stare switche nieprzystosowane do przemysłowych warunków.

Bez utrzymania ruchu ta analiza zwykle kończy się na teoriach. Zespół UR zna „ciemne strony” instalacji: gdzie kabel jest przecięty i połączony na szybko, która szafa nie domyka się do końca, gdzie są największe drgania. Te drobiazgi potrafią zniweczyć projekt zbierania danych, jeśli nie zostaną ujęte w planie. Dlatego projekt integracji legacy systemów powinien zaczynać się i kończyć rozmową z UR, nie tylko z działem IT.

Warstwa danych – jak „wydobyć” dane ze starych maszyn

Trzy główne ścieżki pozyskiwania danych z legacy

Stare maszyny nie mają jednolitego standardu komunikacji, ale z perspektywy integracji AI można wyróżnić trzy główne ścieżki pozyskiwania danych:

1. Wykorzystanie istniejących sygnałów sterowniczych (PLC, SCADA)

Jeżeli maszyna ma PLC lub wpięcie do SCADA, najtańsza droga to wykorzystanie tych sygnałów. Robi się to poprzez:

• dodanie interfejsu komunikacyjnego (np. Modbus TCP, Profinet, Ethernet/IP) do istniejącego PLC,
• odczyt danych z serwera SCADA przez API, OPC UA lub bezpośrednie połączenie z bazą danych,
• ekspozycję danych przez gateway OPC UA, jeśli sterowniki są starsze i nie mają nowoczesnych protokołów.

Ta ścieżka jest szczególnie efektywna, gdy celem jest integracja SCADA z AI, czyli wykorzystanie już zebranych zmiennych procesowych do uczenia modeli prognozujących jakość, zużycie energii czy ryzyko awarii.

2. Retrofit czujnikowy – dodatkowe sensory

Gdy PLC nie oferuje wystarczającej liczby sygnałów lub maszyna jest analogowa, pozostaje retrofit czujnikowy. Najczęściej dodaje się:

• czujniki wibracji (akcelerometry) na łożyskach, silnikach, przekładniach,
• czujniki temperatury (np. PT100, termopary) na krytycznych elementach,
• przekładniki prądowe lub analizatory energii na zasilaniu maszyn,
• czujniki ciśnienia, przepływu, poziomu dla układów hydraulicznych i pneumatycznych.

Sygnały z tych czujników trafiają do lokalnych modułów wejściowych (wejścia analogowe), a następnie do urządzeń edge (mini-komputery przemysłowe, PLC z funkcją IoT). Tam można już stosować edge computing w hali produkcyjnej: wstępna filtracja, agregacja, a nawet inference (wnioskowanie) modeli AI bez wysyłania surowych danych do chmury czy serwerowni.

3. Sniffing protokołów szeregowych i fieldbus

Gdy sterownik jest stary i nie ma udokumentowanego interfejsu, można odczytać dane „podsłuchując” ruch w istniejącej magistrali:

• RS-232 / RS-485 – odczyt ramek, dekodowanie struktury protokołu (czasem producent udostępnia ją nieoficjalnie),
• fieldbusy typu Profibus, CAN, DeviceNet – specjalne interfejsy umożliwiają podsłuch komunikacji master–slave.

To podejście jest bardziej zaawansowane i wymaga doświadczenia w protokołach przemysłowych, ale bywa jedynym sposobem na integrację, gdy modyfikacja programu PLC jest niemożliwa (brak licencji, brak wsparcia producenta, zamknięty kod).

Buforowanie i agregacja – jak nie „zabić” starych maszyn zbieraniem danych

Legacy systemy zwykle pracują na granicy swoich możliwości komunikacyjnych. Dodatkowy polling rejestrów PLC „co 100 ms, bo AI potrzebuje wysokiej rozdzielczości” potrafi wywołać skutki uboczne: opóźnienia w cyklu sterowania, zawieszanie się paneli HMI, a nawet restarty sterownika. Dlatego pomiędzy światem maszyn a światem AI przydaje się warstwa buforowania i agregacji danych.

Praktyczny schemat:

• Rzadki odczyt z PLC – np. co 1–5 sekund, zgodnie z zaleceniami producenta, bez zmiany istniejących cykli komunikacyjnych.
• Gęsty sampling na edge – tam, gdzie potrzeba danych o wysokiej częstotliwości (wibracje, prąd), dokonuje go lokalny moduł pomiarowy, a nie PLC.
• Agregacja w oknach czasowych – zamiast wysyłać każdy pomiar, edge liczy statystyki (min/max/średnia, RMS, odchylenie standardowe) i tylko je wysyła do warstwy AI.

Taki układ daje z jednej strony szansę na wysoką rozdzielczość danych dla modeli ML, a z drugiej nie przeciąża starych magistrali i PLC, które były projektowane do sterowania, a nie do strumieniowego przesyłu danych.

Standaryzacja tagów i semantyka danych

Surowe dane z legacy to zwykle mieszanka lokalnych nazw zmiennych, skrótów z lat 90. i opisów po polsku, niemiecku albo „po operatorowemu”. AI potrzebuje czegoś bardziej uporządkowanego. Chodzi o to, żeby model widział nie tylko „AI_45”, ale wiedział, że to np. „ciśnienie powietrza w układzie pneumatycznym prasy 3”.

Elementy, które usprawniają tę warstwę:

• Słownik tagów procesowych – centralna lista zmiennych z mapowaniem: nazwa w PLC / SCADA → nazwa kanoniczna (np. Press3.Pneumatic.Pressure), jednostka, zakres.
• Taksonomia obiektów – prosta struktura typu: linia → maszyna → podzespół → sygnał. Ułatwia budowę skalowalnych modeli (np. jeden model na wszystkie silniki 11 kW, nie osobny na każdy silnik).
• Adnotacje kontekstu – do sygnałów dokłada się informacje: czy jest krytyczny dla bezpieczeństwa, czy można go użyć w decyzjach sterujących AI, czy jest tylko pomocniczy (monitoring, raportowanie).

Tip: sensowne jest przyjęcie minimum prostego standardu nazewnictwa (np. ISA-95/ISA-88 jako inspiracja), bez „przewrotu kopernikańskiego” w obecnych systemach. Warstwa mapowania może być zrealizowana w middleware (np. w brokerze danych lub platformie integracyjnej), bez ruszania kodu PLC.

Zarządzanie historią danych (historians, bazy time-series)

Modele AI, szczególnie predykcyjne, wymagają długich historii danych – najlepiej obejmujących normalną eksploatację, awarie, przezbrojenia, przestoje. Stare systemy często trzymają dane krótko (kilka dni, tygodni) albo w formie, która nie nadaje się do trenowania (logi tekstowe, brak znaczników czasu co do sekundy).

Dlatego przy integracji Przemysł 4.0 z AI pojawia się konieczność wprowadzenia lub uporządkowania warstwy historycznej:

• Centralny historian / time-series DB – wyspecjalizowana baza czasowa (np. InfluxDB, OSIsoft PI, TimescaleDB), do której trafiają dane z PLC, sensorów retrofitowych i SCADA.
• Ujednolicone znaczniki czasu – upstream (na krawędzi) wszystkie urządzenia powinny korzystać z synchronizacji czasu (NTP, PTP w bardziej wymagających zastosowaniach), aby dane z różnych źródeł dało się złożyć w jedną oś czasu.
• Retencja i kompresja – definiuje się, jak długo dane mają być przechowywane w rozdzielczości „sekunda po sekundzie”, a kiedy można przejść na dane zagregowane (np. 1-minutowe lub 15-minutowe). Dla trenowania modeli często wystarczy część z nich w pełnej rozdzielczości.

Realistyczny przykład: zakład miał SCADA, która przechowywała 7 dni trendów. Po dodaniu warstwy AI wyeksportowano historyczne logi CSV, zbudowano nowy historian, a SCADA zaczęła wysyłać dane równolegle do niego. Dzięki temu modele predykcyjne dostały rok historii, a nie tydzień.

Architektury integracji: od „sensor + Raspberry Pi” po skalowalną platformę

Prosty retrofit „punkt do punktu”

Najbardziej bezpośredni wariant, który często pojawia się na początku drogi, to zestaw: czujnik → mini-komputer / gateway → chmura lub serwer lokalny. Typowa konfiguracja:

• akcelerometr i czujnik temperatury na silniku,
• moduł IO lub prosty PLC z wejściami analogowymi,
• Raspberry Pi lub przemysłowy PC, który zbiera dane, wykonuje podstawową obróbkę i wysyła je np. po MQTT do brokera.

Taka architektura ma sens jako pilot lub rozwiązanie dla pojedynczych, krytycznych maszyn. Dobrze nadaje się na warsztat z zespołem UR: można w kilka dni postawić działający proof-of-concept predykcyjnego utrzymania ruchu.

Ograniczenia pojawiają się przy większej skali: każde stanowisko jest inne, brakuje centralnego zarządzania wersjami oprogramowania, bezpieczeństwem i standardem danych. W pewnym momencie sensowniejsze staje się zbudowanie warstwy pośredniej.

Gateway OT/IT i lokalna warstwa zbierania danych

Kolejny krok to wprowadzenie jednolitej warstwy gateway’ów OT/IT (bramy, które „mówią” językiem PLC od strony hali, a MQTT/HTTP/OPC UA od strony IT). Ich rolą jest:

• obsługa wielu protokołów przemysłowych po stronie OT (Modbus, Profibus, Profinet, OPC DA itp.),
• normalizacja danych (jednolite nazwy, jednostki, zakresy),
• wstępne filtrowanie i agregacja danych przed wysłaniem wyżej,
• implementacja podstawowych reguł bezpieczeństwa (whitelisting, certyfikaty, szyfrowanie).

Gatewaye mogą być urządzeniami dedykowanymi (appliance przemysłowe) albo oprogramowaniem zainstalowanym na przemysłowych PC w szafach sterowniczych. Ważne, by można było nimi centralnie zarządzać: aktualizować, konfigurować nowe przepływy danych, włączać/wyłączać konektory.

Edge computing – lokalne wnioskowanie AI blisko maszyn

W wielu przypadkach opłaca się przenieść część AI na krawędź sieci (edge). Zamiast wysyłać wszystkie dane surowe do chmury, modele inference działają lokalnie na gatewayu lub przemysłowym PC. Typowe scenariusze:

• detekcja anomalii w wibracjach łożysk w czasie rzeczywistym,
• klasyfikacja stanów pracy maszyny (produkcja, przezbrojenie, microdowntime),
• lokalne alarmowanie (np. SMS, sygnał na HMI) w oparciu o predykcyjne wyniki modelu.

Edge computing ma kilka zalet: mniejszy ruch sieciowy, krótsze czasy reakcji, mniejsza wrażliwość na przerwy w łączności. W kontekście legacy maszyn dodatkowym plusem jest to, że można wprowadzić elementy inteligentnego sterowania bez zmiany programu PLC: edge wysyła do PLC tylko prosty sygnał binarny „ok/nie ok” lub wartość nastawy korekcyjnej (setpoint) w ramach z góry przewidzianych granic.

Centralna platforma danych przemysłowych

Kiedy liczba maszyn, linii i lokalizacji rośnie, nie da się uciec przed centralnym komponentem – platformą danych przemysłowych (czasem nazywaną „industrial data hub”). To miejsce, w którym kończy się OT, a zaczyna świat analityki, AI i aplikacji biznesowych.

Główne elementy takiej platformy:

• Broker komunikatów (MQTT, Kafka lub inny) – odpowiedzialny za niezawodną dystrybucję danych z edge/gateway’ów do konsumentów (systemów AI, raportowania, MES).
• Warstwa integracji i API – usługi, które wystawiają ustandaryzowane interfejsy do pobierania danych czasowych, zdarzeń, alarmów czy metadanych o maszynach.
• Magazyny danych – obok historiana pojawia się często data lake lub hurtownia danych, gdzie łączy się dane procesowe z ERP, MES, CMMS i innymi systemami.
• Zarządzanie tożsamością i uprawnieniami – kto może widzieć które dane, kto może publikować, kto może zmieniać konfigurację źródeł.

Taka platforma jest fundamentem dla skalowania AI – pozwala przestać budować każde wdrożenie jako osobny projekt integracyjny. W kontekście legacy daje też osłonę: zmiany po stronie starych maszyn są minimalne, a ciężar „cyfrowości” rośnie po stronie IT.

Bezpieczeństwo OT/IT w architekturze integracji

Stare maszyny i sieci OT często projektowano w czasach, gdy nikt nie zakładał ich ekspozycji na sieć IT, a tym bardziej na internet. Dodanie gateway’ów i platform danych bez rozsądnej strategii bezpieczeństwa może otworzyć drzwi dla incydentów, które zatrzymają produkcję.

Kluczowe praktyki przy architekturze:

• Segmentacja sieci – wydzielone VLAN-y dla OT, strefy DMZ pomiędzy OT a IT, wyraźnie zdefiniowane punkty styku (firewalle przemysłowe).
• Minimalny zestaw protokołów – im mniej translacji i otwartych portów, tym lepiej. MQTT/OPC UA/HTTPS zamiast „wszystko dla wszystkich”.
• Zero-trust po stronie IT – uwierzytelnianie urządzeń edge, certyfikaty, szyfrowane kanały. Brak „otwartych” brokerów MQTT widocznych z całego LAN-u.
• Współpraca z UR i BHP – każda ingerencja w sterowanie (nawet pośrednia, przez AI) musi być przegadana z osobami odpowiedzialnymi za bezpieczeństwo funkcjonalne.

Dane do AI z legacy – jakość, synchronizacja, etykietowanie

Typowe problemy jakości danych ze starych maszyn

Dane z legacy maszyn rzadko są „od linijki”. Typowe zjawiska:

• brak skalowania i jednostek – w PLC zapisany jest surowy odczyt z przetwornika (np. 0–27648), a dopiero ekran HMI pokazuje wartości w barach; system AI widzi tylko liczby bez kontekstu,
• przeskoki i „schody” – stare przetworniki i 10-bitowe wejścia analogowe dają bardzo „kanciasty” sygnał, co komplikuje wykrywanie subtelnych anomalii,
• brak spójnych kodów stanów – każdy producent maszyny inaczej definiuje kody alarmów, trybów pracy i przyczyn zatrzymań.

Przed uruchomieniem poważniejszych modeli AI przydaje się etap „sanity check” danych: analizy prostych statystyk, wizualizacji trendów, wykrycia braków i nielogicznych wartości (np. ujemne ciśnienie tam, gdzie nie powinno występować).

Synchronizacja czasowa wielu źródeł

Legacy systemy często korzystają z własnych, niesynchronizowanych zegarów. Jeden PLC ma inną godzinę niż serwer SCADA, a panele HMI jeszcze inną. Przy budowie modeli, które łączą dane z kilku maszyn, robi się z tego poważny problem.

Rozwiązaniem jest wdrożenie spójnej polityki czasu:

• centralne serwery NTP – dostępne z podsieci OT, z których korzystają PLC, serwery SCADA, gatewaye i edge PC (tam, gdzie jest to wspierane),
• czas „nadpisywany” na krawędzi – gdy nie da się ustawić zegara w legacy urządzeniu, edge przy odbiorze ramki dodaje własny, zsynchronizowany timestamp,
• okresowa kalibracja – monitoring odchyłek czasu pomiędzy kluczowymi źródłami (np. logi porównawcze) i korekta w razie potrzeby.

W praktyce chodzi o to, by móc odpowiedzieć na proste pytanie: czy skok temperatury na maszynie A i spadek ciśnienia na maszynie B zdarzyły się jednocześnie, czy to złudzenie wynikające z przesuniętego zegara.

Etykietowanie zdarzeń procesowych i awarii

Bez sensownego etykietowania (labellingu) danych nawet najlepsza architektura nie pozwoli na zbudowanie przydatnych modeli nadzorowanych (supervised learning). W legacy środowisku źródłem etykiet bywają:

• logi alarmów i zdarzeń z HMI/SCADA,
• raporty UR (awarie, wymiany części, przeglądy),
• raporty jakości (odrzuty, reklamacje, wyniki inspekcji),
• czasem – ręczne notatki operatorów lub zeszyty zmianowe.

Te dane zazwyczaj nie są zintegrowane z sygnałami procesowymi. Trzeba je połączyć, najczęściej po znacznikach czasu i identyfikatorach maszyn/partii. Dobrze sprawdza się podejście krokowe:

1. zebrać historyczne logi alarmów i raporty UR,
2. zbudować prostą regułę łączenia ich z danymi procesowymi (np. okno czasowe ±5 minut wokół alarmu),
3. zweryfikować na kilku przypadkach wspólnie z UR, czy etykiety są sensowne (czy „awaria łożyska” rzeczywiście odpowiada temu, co widać na trendach).

Półautomatyczne etykietowanie na bazie reguł i prostych modeli

Ręczne etykietowanie lat historii produkcji jest nierealne. Dlatego opłaca się zbudować półautomatyczne mechanizmy, które generują „kandydatów etykiet”, a człowiek tylko je zatwierdza lub poprawia.

Praktyczna ścieżka wygląda często tak:

• reguły oparte na alarmach – każdy alarm o określonym kodzie (np. „ALM_BEARING_FAIL”) tworzy kandydackie zdarzenie „awaria łożyska” dla danej maszyny w określonym oknie czasowym,
• heurystyki czasowe – jeśli linia stoi > X minut bez planowanego postoju i bez zmiany zlecenia, generowane jest zdarzenie „nieplanowany przestój”,
• clustering prostych cech – na początek bez „prawdziwego” AI: grupowanie fragmentów sygnału (np. wibracje + temperatura) w klastry i wspólne etykietowanie całych klastrów z UR.

Takie podejście pozwala „wykroić” pierwsze zbiory uczące bez wtłaczania operatorom nowych formularzy do wypełniania. Z czasem można dołożyć interfejs webowy, w którym technolog lub inżynier UR przegląda sygnały wraz z proponowaną etykietą i ją akceptuje albo zmienia. Taki, nawet prosty, workflow jakości etykiet szybko podnosi poziom modeli.

Radzenie sobie z niepełnymi i sprzecznymi etykietami

W legacy środowisku etykiety są często niekompletne albo wzajemnie sprzeczne: ten sam typ awarii opisany różnymi słowami, różne kody w SCADA i w systemie CMMS, brak informacji, kiedy awaria się faktycznie zaczęła. Zamiast próbować „wyczyścić” wszystko ręcznie, lepiej przyjąć kilka zasad:

• normalizacja słowników – mapowanie różnych opisów i kodów na słowniki referencyjne (np. wszystkie „uszkodzenie łożyska / bearing fault / LOZYSKO_USZK” → BEARING_FAILURE),
• priorytety źródeł – ustalenie, które źródło jest „bardziej prawdziwe” w razie konfliktu (np. CMMS ma pierwszeństwo nad SCADA przy opisie awarii mechanicznej),
• etykiety wieloklasowe – czasem rozsądniej jest zaakceptować, że jedno zdarzenie ma kilka atrybutów (np. „awaria mechaniczna” + „przegrzanie”), niż losowo wybierać jedną etykietę.

Nie trzeba mieć idealnych etykiet, by modele dawały wartość. Nawet „szumne” dane etykietowane według spójnych zasad są lepsze niż brak etykiet w ogóle – szczególnie przy modelach detekcji awarii, gdzie koszt fałszywego alarmu bywa niższy niż koszt przeoczenia prawdziwego problemu.

Jakie przypadki użycia AI mają sens przy starych maszynach

Predictive maintenance bez ingerencji w PLC

Najbardziej naturalny przypadek użycia dla legacy to utrzymanie ruchu oparte na predykcji. Stare maszyny często nie mają żadnej „wbudowanej” diagnostyki poza kilkoma alarmami progowymi. Dołożenie czujników i prostego edge sprawia, że można:

• monitorować ciągłe sygnały z wibracji, temperatury, prądu silnika,
• uczyć modele wykrywające odchylenia od „normalnego” wzorca pracy (anomaly detection),
• generować zalecenia UR typu „sprawdź łożysko na osi X w ciągu 72 godzin”.

Nie trzeba wchodzić w logikę PLC. Wystarczy, że system predykcyjny wysyła powiadomienia do CMMS lub e-mail/SMS do brygadzisty. Tam, gdzie jest większa dojrzałość, można dodać prosty interfejs: sygnał binarny do PLC, który wyzwala np. kontrolowany zjazd z produkcji albo obniżenie prędkości linii.

OEE i analiza przyczyn strat na bazie danych z edge

Drugim „niskowiszącym” owocem jest lepsza widoczność kluczowych wskaźników (OEE, MTBF, MTTR) bez generalnego remontu automatyki. Stare maszyny często nie mają sensownych liczników cykli, części dobrych/złych czy kodów przestojów.

Da się to obejść, korzystając z kombinacji:

• sygnałów binarnych/analogowych z istniejących wejść (np. „maszyna pracuje / stoi”, „czujnik sztuki gotowej”),
• kamer lub fotokomórek zliczających części na wyjściu,
• prostych inputów operatorskich na panelu webowym (wybór przyczyny przestoju na tablecie).

Dane zebrane na edge trafiają do centralnej platformy, gdzie liczone są wskaźniki i budowane analizy przyczyn (loss tree). To nadal nie jest „pełny” MES, ale już pozwala zidentyfikować, które maszyny i zmiany generują największe straty. AI może tu wejść w momencie, kiedy chcemy:

• automatycznie klasyfikować przyczyny microdowntime na bazie wzorców sygnałów,
• prognozować OEE na kolejne zmiany przy danych planach produkcyjnych.

Optymalizacja parametrów procesu na istniejących recepturach

Stare linie często działają na ustalonych dawno temu nastawach (setpointach), które rzadko ktoś systematycznie weryfikuje. AI nie musi od razu sterować procesem; może w pierwszym kroku pełnić rolę „asystenta technologa”:

• analiza historycznych danych: które kombinacje nastaw dawały stabilny proces i mało odrzutów,
• budowa prostego modelu regresyjnego przewidującego kluczowe parametry jakości na bazie nastaw i warunków wejściowych (np. temperatura otoczenia, wilgotność surowca),
• propozycje drobnych korekt nastaw dla aktualnych kampanii produkcyjnych.

W pierwszym etapie model może podpowiadać rekomendacje w raporcie lub interfejsie webowym. Dopiero po okresie pilotażowym, gdy technolodzy nabiorą zaufania, można rozważyć zamknięcie pętli i automatyczne korygowanie jednego wybranego parametru, z twardymi limitami bezpieczeństwa narzuconymi po stronie PLC.

Wizja maszynowa jako „nowy zmysł” dla starej linii

Jeżeli maszyna nie udostępnia wielu sygnałów użytecznych dla AI, najprostszym sposobem rozszerzenia jej „obserwowalności” jest kamera. W praktyce kamera + edge z modelem CV (computer vision) daje kilka szybkich wygranych:

• automatyczne zliczanie sztuk, także przy chaotycznym strumieniu na przenośniku,
• podstawowa kontrola jakości (obecność/nieobecność elementu, wymiary zgrubne, kolorystyka),
• monitoring obecności operatora w strefie stanowiska (np. pod kątem wsparcia ergonomii, nie zastępując systemów BHP).

Wszystko to bez dotykania logiki sterownika. Integracja z maszyną może ograniczyć się do kilku sygnałów: gotowość, zablokuj wyrzut sztuki, sygnał NG (not good). W razie potrzeby system wizyjny działa całkowicie równolegle, wysyłając wyniki tylko do systemów raportowych.

Modele pomocnicze dla planowania produkcji i logistyki wewnętrznej

Legacy maszyny rzadko integrują się płynnie z systemami APS (Advanced Planning and Scheduling) czy WMS. A jednak dzięki danych z gateway’ów i platformy można budować modele, które pomagają lepiej planować:

• prognozy czasów realizacji zleceń w oparciu o aktualną kondycję maszyn, historię awarii i typ produktu,
• predykcja kolejek przed określonymi stanowiskami (bottleneck prediction),
• optymalizacja sekwencji zleceń na maszynach, które mają kosztowne przezbrojenia.

Te zastosowania dotykają AI bardziej po stronie IT niż OT. Modele uczą się na danych z produkcji, UR i logistyki, ale nie ingerują w sterowanie maszynami. Dla wielu firm to wygodna „pierwsza liga” zastosowań AI: mierzalna wartość biznesowa, bez ryzyka zaburzenia bezpieczeństwa funkcjonalnego.

Systemy rekomendacji dla operatorów i standardyzacja najlepszych praktyk

W zakładach z dużym parkiem legacy widać często ogromne różnice między zmianami: doświadczeni operatorzy „czują” maszynę i utrzymują stabilny proces, nowi popełniają te same błędy. AI może wesprzeć ujednolicenie praktyk bez wchodzenia w roli „autopilota”.

Na bazie danych z linii i historii interwencji operatorów można budować:

• szablony reakcji – dla typowych kombinacji alarmów i odchyleń parametrów system podpowiada 2–3 typowe działania z historią skuteczności,
• scoring ustawień – ocena „jak dobre” są obecne nastawy vs. historyczne wzorce przy podobnych warunkach produkcji,
• checklisty adaptacyjne – krótkie listy kroków do przejścia przy przezbrojeniu lub rozruchu po awarii, generowane dynamicznie w zależności od stanu maszyny.

Tego typu „miękkie” wsparcie AI często jest łatwiejsze do zaakceptowania przez zespoły produkcyjne niż automatyczne sterowanie, bo nie odbiera operatorom kontroli nad procesem, tylko dostarcza lepszego kontekstu i wiedzy z przeszłych zdarzeń.

Uczenie nienadzorowane i detekcja anomalii tam, gdzie brakuje etykiet

Na wielu starych liniach po prostu brakuje wiarygodnych etykiet awarii czy defektów jakości. W takim środowisku sprawdza się uczenie nienadzorowane (unsupervised learning) i półnadzorowane (semi-supervised). Zamiast uczyć model „co to jest awaria łożyska”, uczy się on, jak wygląda normalna praca, i sygnalizuje odchylenia.

Przykładowe podejścia:

• modele rekonstrukcyjne (autoenkodery) – uczone na długich fragmentach „zdrowych” danych, sygnalizują anomalie, gdy błąd rekonstrukcji przekracza próg,
• modele sekwencyjne (np. warianty LSTM lub Transformers) – wychwytują nienaturalne sekwencje w czasie, np. nietypową kombinację skoków ciśnienia i drgań,
• klastry „trybów pracy” – automatyczne grupowanie typowych stanów maszyny; pojawienie się nowego klastra bywa pierwszym sygnałem, że proces „chodzi inaczej”.

Bez dodatkowych etykiet nie da się jeszcze nazwać przyczyny problemu, ale często sama informacja „tu zaczął się inny stan pracy” jest wystarczająca, by UR lub technolog przyjrzeli się maszynie, zanim dojdzie do twardej awarii.

Integracja AI z procedurami UR i BHP zamiast „magii na boku”

Nawet najlepszy model nie ma sensu, jeśli jego wyniki nie są wpięte w istniejące procesy. Szczególnie przy legacy maszynach trzeba zadbać, by AI nie funkcjonowało jako „osobna wyspa”, tylko:

• tworzyło zlecenia w CMMS z odpowiednim priorytetem i opisem (a nie tylko wysyłało e-mail),
• konsultowało zmiany w nastawach z technologami oraz z osobami odpowiedzialnymi za bezpieczeństwo funkcjonalne,
• miało zdefiniowane ścieżki eskalacji: co się dzieje, gdy model wykryje poważną anomalię, ale nikt nie reaguje.

Tip: dobrym wzorcem jest potraktowanie systemu AI jak nowego „czujnika” w analizie HAZOP/LOPA i procedurach BHP. Zamiast traktować modele jak czarną skrzynkę, rozpisuje się, jaki mają wpływ na decyzje i jakie istnieją zabezpieczenia, gdy się mylą. Dzięki temu da się korzystać ze starych maszyn dłużej, a jednocześnie podnosić poziom bezpieczeństwa i niezawodności z pomocą nowych algorytmów.

Kluczowe Wnioski

• Przemysł 4.0 nie wymaga wymiany całego parku maszynowego – kluczowe jest pozyskanie stabilnych, opisanych danych z maszyn, niezależnie od ich wieku czy producenta.
• Strategia retrofit / brownfield AI pozwala etapowo dokładać czujniki, bramy IoT i warstwę edge do istniejących urządzeń, co znacząco obniża koszt i ryzyko względem budowy „idealnej” fabryki greenfield.
• Dla AI najważniejsze są: sygnały procesowe (np. prąd, wibracje, temperatura), powtarzalny tryb pracy oraz kontekst biznesowy (produkt, partia, ustawienia), a nie rocznik maszyny czy nowość sterownika.
• Integracja z istniejącymi PLC, SCADA i MES oraz sensowne opisanie danych (metadane, znaczniki czasu) jest zwykle bardziej opłacalne niż zakup nowych linii tylko po to, by „mieć IoT”.
• Retrofit czujnikowy na starych maszynach (np. prasy hydrauliczne z lat 90.) umożliwia wdrożenie predykcyjnego utrzymania ruchu – wykrywanie anomalii w drganiach czy poborze prądu przed awarią i planowanie serwisu z wyprzedzeniem.
• Inwentaryzacja parku maszynowego pod kątem „poziomu cyfrowości” (analogowe, z prostym PLC, z HMI/SCADA) porządkuje priorytety: wiadomo, gdzie wystarczy podpiąć się do istniejących sygnałów, a gdzie trzeba dodać sterownik i komplet czujników.