Bezpieczna integracja AI z istniejącymi systemami SCADA oraz OT w zakładach przemysłowych

Kontekst zastosowania AI w istniejących systemach SCADA i OT

Charakterystyka dojrzałego środowiska SCADA/OT

Typowy zakład z dojrzałym systemem automatyki ma za sobą lata inwestycji w SCADA i OT. Funkcjonują tam sterowniki PLC, systemy DCS, panele HMI, przemysłowe sieci komunikacyjne oraz serwery historyczne (historian). Infrastruktura jest stabilna, dobrze znana zespołowi utrzymania ruchu i zwykle krytyczna dla ciągłości produkcji.

Logika procesu jest zaszyta głównie w sterownikach, czasem w DCS. Operatorzy korzystają z wizualizacji HMI/SCADA, reagują na alarmy, wykonują receptury. Dane z procesu trafiają do historianów, gdzie przechowywane są przez lata i używane do raportowania, analiz jakościowych oraz wsparcia audytów.

Ważną cechą takiego środowiska jest konserwatywna polityka zmian. Każda modyfikacja kodu PLC, konfiguracji SCADA czy sieci przemysłowej wymaga procedur, testów, często przestojów. Dlatego integracja AI nie może zakładać swobodnego „majstrowania” przy sterownikach ani ryzykownych eksperymentów na żywym procesie.

Problemy, które realnie rozwiązuje AI w SCADA/OT

Rozwiązania AI w środowisku przemysłowym nie są celem samym w sobie. Mają rozwiązać konkretne problemy, których nie zaadresowano klasyczną automatyką i prostą analityką. W praktyce najczęściej pojawiają się cztery obszary:

• Predykcja awarii – modele uczą się typowych wzorców pracy maszyn, wykrywają odchylenia sugerujące zużycie, rozregulowanie lub zbliżającą się awarię. Przykład: wykrywanie anomalii w drganiach łożysk, nietypowych profilach prądowych silników, powolnych dryfów temperatury.
• Optymalizacja zużycia energii – analiza dużej liczby zmiennych procesowych pozwala wskazać ustawienia, które dają tę samą lub lepszą jakość przy mniejszym poborze energii, pary, sprężonego powietrza czy gazu technologicznego.
• Poprawa jakości produkcji – modele uczą się związku między parametrami procesu a wynikiem jakościowym (np. wyniki z laboratoriów LIMS). Na tej podstawie można ograniczyć odrzuty, stabilizować parametry, szybciej reagować na dryfy.
• Wsparcie operatora – AI analizuje bieżący stan i historię, podpowiada operatorowi prawdopodobne przyczyny alarmów, sugeruje korekty nastaw, porównuje bieżącą sytuację z wcześniejszymi podobnymi przypadkami.

W każdym z tych zastosowań kluczem jest wykorzystanie danych już zbieranych przez SCADA/OT, bez gwałtownej ingerencji w istniejący kod sterowników. AI staje się dodatkową warstwą analityczną nad tym, co już działa.

AI jako gadżet vs AI jako element procesu

AI jako „gadżet” to sytuacja, w której wdraża się modną technologię bez realnego wpływu na proces. Powstaje dashboard, kilka ładnych wykresów, czasem chatbot do zadawania pytań o dane procesowe. Operatorzy szybko tracą zainteresowanie, bo narzędzie nie pomaga im w rzeczywistych decyzjach.

AI jako element procesu technologicznego działa inaczej. Jest wpięta w codzienne procedury. Rekomendacje pojawiają się w HMI obok standardowych alarmów, są omawiane na porannych odprawach, uwzględnione w instrukcjach pracy. Wyniki modeli wpływają na planowanie przeglądów, zmiany receptur, a czasem – w ściśle kontrolowany sposób – na automatyczne nastawy.

Różnica jest też w odpowiedzialności. W podejściu „gadżetowym” nikt nie bierze odpowiedzialności za korzystanie z AI. W podejściu procesowym jasno określa się, kto zatwierdza rekomendacje, jak są dokumentowane zmiany oraz kiedy wolno włączać tryb półautomatyczny lub automatyczny sterowania.

Główne obawy związane z integracją AI ze SCADA/OT

Decydenci w zakładach przemysłowych mają powtarzający się zestaw obaw, gdy słyszą o integracji AI:

• Bezpieczeństwo – lęk, że nowe serwery, połączenia i oprogramowanie otworzą sieć OT na ataki z zewnątrz, a awaria systemu AI wpłynie na systemy sterowania.
• Stabilność produkcji – obawa przed przestojem przy wdrożeniu lub nieprzewidywalnymi reakcjami procesu, jeśli AI poda błędne rekomendacje.
• Odpowiedzialność za decyzje – pytania: kto odpowiada za błędną sugestię AI, co gdy model „przegapi” awarię, jak udowodnić poprawność działania przy audytach i w środowisku regulowanym.
• Kompetencje – niepewność, czy zespół OT i utrzymanie ruchu poradzi sobie z utrzymaniem modeli i nowej infrastruktury.

Bezpieczna integracja AI z SCADA/OT oznacza takie zaprojektowanie architektury i procesu wdrożenia, aby te obawy były adresowane od pierwszego dnia: AI na początku pracuje pasywnie, ma ograniczone uprawnienia, jest monitorowana, a ścieżka eskalacji problemów jest znana i przećwiczona.

Specyfika środowiska OT i ograniczenia decydujące o integracji AI

Priorytety w OT: dostępność i bezpieczeństwo procesu

Środowisko OT rządzi się inną logiką niż klasyczne IT. W IT da się zaakceptować krótką przerwę w działaniu systemu CRM czy portalu, jeśli poprawia to bezpieczeństwo lub wydajność. W OT priorytetem numer jeden jest ciągłość i bezpieczeństwo procesu technologicznego.

To oznacza, że:

• Zmiany wprowadza się rzadko, w zaplanowanych oknach serwisowych.
• Nowe elementy infrastruktury są traktowane z dużą ostrożnością.
• Każda integracja musi być możliwa do wyłączenia bez wpływu na podstawową logikę sterowania.

AI musi się do tego dostosować. Modele mogą się zmieniać, oprogramowanie do trenowania może być aktualizowane częściej, ale granica z systemami krytycznymi musi pozostać stabilna i dobrze kontrolowana.

Długie cykle życia i technologiczna różnorodność

Systemy SCADA/OT pracują latami. Często obok siebie działają rozwiązania sprzed kilkunastu lat i nowsze instalacje. W jednej linii mogą pojawić się:

• stare sterowniki komunikujące się po Modbus RTU,
• nowsze PLC z OPC UA,
• systemy DCS zamknięte w dedykowanych sieciach,
• różne wersje SCADA kilku dostawców.

Ta różnorodność komplikuje integrację AI. Nie można zakładać ujednoliconego interfejsu ani łatwej aktualizacji wszystkich komponentów. Stąd tak istotna staje się warstwa pośrednia, która potrafi rozmawiać z każdym systemem w jego „języku”, a na zewnątrz udostępnia jednolite API czy strumień danych.

Zasada ostrożności: brak bezpośrednich zmian w logice sterowników

Bezpieczna integracja AI zakłada brak bezpośrednich modyfikacji logiki sterowników PLC i DCS na potrzeby AI, przynajmniej w pierwszych etapach. Logika procesu jest z reguły dobrze przetestowana, certyfikowana, często powiązana z wymaganiami regulacyjnymi.

Wprowadzanie AI bezpośrednio do kodu sterownika (np. w postaci skomplikowanej logiki rozmytej czy fragmentów kodu generowanych automatycznie) oznaczałoby bardzo wysokie ryzyko i długi cykl testów. Dużo bezpieczniej jest:

• pozyskiwać dane ze sterownika przez SCADA lub historian,
• przetwarzać je poza krytyczną pętlą sterowania,
• zwracać rekomendacje jako dodatkowe sugerowane nastawy lub sygnały „miękkich alarmów”,
• ewentualne automatyczne sterowanie realizować przez dedykowaną warstwę logiki pośredniej, którą można łatwo odłączyć.

Wymóg przewidywalności i prostoty w OT

Modele AI bywają trudne do wytłumaczenia. Tymczasem w OT ceniona jest przewidywalność, prosta logika i możliwość szybkiej diagnozy błędu. Każdy dodatkowy element zwiększa złożoność systemu i potencjalne punkty awarii.

Dlatego sposób wdrażania AI różni się od tego znanego z aplikacji webowych czy mobilnych. Zamiast ciągłego „eksperymentowania na produkcji” stosuje się bardziej konserwatywne podejście:

• dłuższa faza shadow mode (model działa równolegle, ale nie wpływa na sterowanie),
• manualne zatwierdzanie rekomendacji przez operatora,
• proste, jasno określone interfejsy danych,
• silne ograniczenia w uprawnieniach i zakresie działania modeli.

Im prostsze i bardziej przewidywalne jest miejsce integracji AI, tym łatwiej przekonać zespół OT i operatorów do jej używania.

Architektura SCADA/OT i przestrzeń na warstwę AI

Standardowe warstwy w zakładzie przemysłowym

Uporządkowanie architektury SCADA/OT pomaga wskazać, gdzie najlepiej umieścić komponenty AI. W uproszczeniu można wyróżnić kilka warstw:

• Urządzenia polowe – czujniki, przetworniki, napędy, zawory, liczniki, analizatory.
• Warstwa sterowania – sterowniki PLC, DCS, regulatory, czasem systemy safety.
• Warstwa nadzorcza – SCADA, HMI, serwery alarmowe, serwery raportowe.
• Warstwa danych procesowych – historyczne bazy danych (historian), bazy alarmów, systemy LIMS, systemy jakości.
• Warstwa produkcyjna – systemy MES, APS, czasem CMMS.
• Warstwa biznesowa – ERP, systemy finansowe, systemy raportowania korporacyjnego.

AI może korzystać z danych na różnych poziomach. Bezpieczne podejście preferuje korzystanie z warstwy danych procesowych i produkcyjnej, aby nie wchodzić bezpośrednio w pętlę sterowania.

Typowe punkty wpięcia AI w istniejącą infrastrukturę

Najczęściej wybierane „miejsca” integracji AI w typowym zakładzie to:

• Serwer historian – główne źródło danych czasowych, z którego można pobierać dane wsadowo lub strumieniowo.
• Serwery raportowe SCADA – systemy generujące raporty dzienne, miesięczne, zbiory danych do analiz.
• Repliki baz danych – kopie baz z historianów lub systemów MES, tworzone specjalnie do celów analitycznych.
• Bramy OT/IT – dedykowane serwery lub urządzenia integrujące sieć przemysłową z siecią IT, np. przez OPC UA, MQTT.

W każdym przypadku dąży się do tego, aby:

• AI czytała dane z kopii lub interfejsu, który nie obciąża krytycznego systemu SCADA/OT,
• połączenia były kontrolowane i monitorowane,
• można było w dowolnym momencie odłączyć system AI bez zatrzymania produkcji.

Warstwa pośrednia AI: edge lub serwer analityczny

Bezpieczna integracja AI opiera się zazwyczaj na koncepcji warstwy pośredniej. To dedykowany serwer lub zestaw serwerów (on-prem, edge), które:

• zbierają dane z SCADA, historianów, MES, LIMS,
• przetwarzają je na potrzeby modeli (feature engineering, agregacje),
• uruchamiają modele AI i generują wyniki (rekomendacje, prognozy, wskaźniki),
• udostępniają wyniki z powrotem do SCADA, MES lub aplikacji webowych.

Warstwa pośrednia izoluje systemy krytyczne od złożoności technologii AI. To tu można stosować nowoczesne biblioteki, kontenery, orkiestrację, a jednocześnie zachować prosty i stabilny interfejs w kierunku OT.

AI jako dodatkowy moduł analityczny wspierający operatora

Practicalnym przykładem jest moduł AI zintegrowany z istniejącą wizualizacją SCADA. Działa to następująco:

• Dane procesowe z historianu są przesyłane do serwera AI.
• Model analizuje aktualny stan oraz ostatnie godziny/dni pracy.
• Wyniki (np. przewidywana awaria w najbliższych dniach, rekomendowana zmiana nastawy) są zapisywane w specjalnej tabeli lub udostępniane przez OPC UA.
• SCADA odczytuje te wyniki i prezentuje je jako dodatkowe „miękkie alarmy” lub informacje na ekranie HMI.

Operator widzi więc w znanym sobie środowisku nowe komunikaty: zamiast zmuszać go do otwierania osobnego systemu AI, integracja przenosi rekomendacje do miejsca, w którym operator spędza większość czasu.

Modele integracji AI z istniejącą infrastrukturą

Integracja pasywna: tryb tylko do odczytu

Najbezpieczniejsze i zalecane na początek podejście to integracja pasywna. System AI ma wyłącznie dostęp odczytu do danych z SCADA/OT i nie generuje żadnych automatycznych sygnałów sterujących.

W praktyce oznacza to, że:

• modele AI pobierają dane z historianu lub replik baz,
• analizują je i zapisują wyniki w swojej bazie lub udostępniają przez API,
• operatorzy i inżynierowie mogą oglądać rekomendacje w panelach webowych lub raportach,
• nie ma bezpośredniego wpływu na nastawy w PLC/DCS.

Integracja półaktywna: rekomendacje z możliwością półautomatu

Kolejny krok po trybie tylko do odczytu to integracja, w której AI nadal nie podejmuje decyzji samodzielnie, ale może inicjować działania, które człowiek zatwierdza lub koryguje.

Najprostsza forma to sugerowane nastawy. Model oblicza nową wartość zadawaną (np. temperaturę, ciśnienie, prędkość linii) i przekazuje ją do SCADA jako propozycję. Operator widzi obecną wartość, propozycję AI oraz uzasadnienie lub kluczowe wskaźniki. Zmianę zatwierdza jednym kliknięciem.

Inny wariant to półautomatyczne procedury. AI wykrywa stan, który zwykle kończy się zatrzymaniem linii, i proponuje sekwencję kroków (np. obniżenie obciążenia, przełączenie pompy, zmiana receptury). SCADA prezentuje procedurę w formie listy kroków, a operator odhacza kolejne punkty. Logika sterowania pozostaje w PLC, AI działa tylko jako doradca.

Taki model integracji ogranicza ryzyko i jednocześnie pozwala sprawdzić, czy rekomendacje AI są praktyczne, czy nie powodują konfliktu z rzeczywistą eksploatacją urządzeń.

Integracja aktywna: sterowanie pod nadzorem z mechanizmem „kill switch”

Integracja aktywna oznacza, że AI może wpływać na sterowanie, ale wciąż w sposób kontrolowany. Stosuje się ją dopiero wtedy, gdy:

• model był długo testowany w trybie pasywnym i półaktywnym,
• dostępne są dane o jego skuteczności i błędach,
• zespół OT rozumie logikę i ograniczenia działania systemu.

Technicznie polega to na wprowadzeniu dodatkowej warstwy logiki pośredniej, która:

• odbiera rekomendacje AI,
• weryfikuje je pod kątem dopuszczalnych przedziałów i szybkości zmian,
• konwertuje na sygnały sterujące wysyłane do PLC lub DCS.

Ta warstwa ma zawsze możliwość natychmiastowego odłączenia, najlepiej poprzez prosty przełącznik w SCADA lub fizyczny przełącznik trybu pracy (AI / manual / klasyczna automatyka). W praktyce stosuje się też ograniczenia czasowe: AI może wykonywać tylko określoną liczbę zmian w ciągu godziny, a każda większa zmiana wymaga potwierdzenia człowieka.

W jednym z zakładów chemicznych AI sterowała tylko prędkością narastania temperatury, ale nie samą temperaturą docelową. Celem było skrócenie czasu nagrzewania przy niezmienionych limitach bezpieczeństwa. Dzięki wąskiemu zakresowi działania łatwiej było przeprowadzić analizę ryzyka i uzgodnić scenariusze awaryjne.

Integracja zewnętrzna: AI poza siecią OT, tylko przez bezpieczną bramę

W wielu organizacjach zakłada się, że żaden komponent AI nie powinien znaleźć się bezpośrednio w sieci OT. Modele działają w sieci IT lub w wydzielonej strefie DMZ, a jedyny kontakt z OT odbywa się przez ściśle kontrolowaną bramę.

Taka brama może przyjmować postać:

• serwera OPC UA w strefie pośredniej, który subskrybuje dane z OT i publikuje je dalej,
• brokera MQTT w DMZ, odbierającego dane z edge gateway i przekazującego je do systemów AI,
• dedykowanego API, które udostępnia dane tylko w jedną stronę (pull z replik bazy).

W kierunku zwrotnym, z AI do OT, zaleca się kilka poziomów buforowania i walidacji. Dane z AI nie trafiają bezpośrednio do PLC, lecz do serwera aplikacyjnego w DMZ, potem do SCADA lub systemu pośredniego, a dopiero na końcu – w ściśle kontrolowanej formie – do sterowników.

Takie podejście jest szczególnie sensowne, gdy AI działa w chmurze lub gdy korzysta się z zewnętrznych usług analitycznych. Brama pełni wtedy rolę filtra, rejestratora ruchu i punktu, który można odłączyć bez wpływu na proces.

Bezpieczeństwo i segmentacja przy integracji AI

Strefy i konwencje sieciowe dla komponentów AI

Podstawą bezpiecznej integracji AI jest jasne umiejscowienie jej komponentów w architekturze sieciowej. W praktyce wyróżnia się zwykle:

• strefę OT (sterowniki, SCADA, serwery alarmowe),
• strefę pośrednią / DMZ przemysłową,
• strefę IT (systemy biznesowe, inżynierskie, AI).

Elementy AI – serwery trenowania, serwery inference, repozytoria modeli – powinny znajdować się w strefie IT lub DMZ, nie w tej samej podsieci co PLC. Jeśli konieczny jest edge (np. z powodu opóźnień lub dostępności łączy), rozsądne jest wydzielenie osobnej podsieci VLAN i zastosowanie firewalli z regułami dopuszczającymi tylko niezbędny ruch.

Konfigurując adresację i routing, lepiej unikać sytuacji, w której serwer AI ma bezpośrednią trasę do wielu segmentów OT. Komunikacja powinna być skupiona wokół jednego kontrolowanego punktu – najczęściej bramy OPC UA lub dedykowanego serwera integracyjnego.

Minimalny dostęp: zasada najmniejszych uprawnień dla AI

Modele AI z punktu widzenia bezpieczeństwa są po prostu kolejnymi aplikacjami. Należy traktować je jak potencjalne źródło podatności, tym bardziej że często używają złożonych bibliotek i frameworków.

Przydzielając uprawnienia, stosuje się zasadę najmniejszych uprawnień:

• dostęp tylko do tych tagów i tabel, które są niezbędne do obliczeń,
• brak uprawnień zapisu do baz produkcyjnych – ewentualnie tylko do osobnych schematów lub widoków,
• brak możliwości „skanowania” całej sieci OT, otwarte tylko konkretne porty i adresy,
• osobne konta serwisowe dla czytania danych i zapisu rekomendacji.

Jeżeli AI musi pisać do systemu OT (np. w trybie aktywnym), warto utworzyć dedykowaną przestrzeń danych: oddzielne tagi, zmienne lub tabele na rekomendacje. PLC lub SCADA odczytują je i dopiero w ramach własnej logiki decydują, które z nich uwzględnić.

Segmentacja logiczna: oddzielenie trenowania od inference

Systemy AI składają się zazwyczaj z dwóch klas komponentów: środowiska trenowania (często z szerokim dostępem do danych, dużą złożonością bibliotek) oraz środowiska inference (modele produkcyjne odpowiadające na zapytania). Bezpieczna architektura zakłada ich separację.

Środowisko trenowania można trzymać całkowicie poza siecią OT, często nawet w innej infrastrukturze (np. chmura prywatna lub publiczna). Dane z OT trafiają tam w formie zanonimizowanej lub zagregowanej, zwykle wsadowo przez bezpieczne łącza lub fizyczne transfery.

Środowisko inference, które komunikuje się z historianem lub bramą OT/IT, jest możliwie małe i proste: zawiera tylko niezbędne biblioteki do wykonania modelu, bez narzędzi do eksploracji danych czy ad-hoc analiz. Dzięki temu zmniejsza się powierzchnia ataku i ułatwia aktualizację zabezpieczeń.

Monitorowanie bezpieczeństwa modeli i infrastruktury AI

AI wprowadza nowe typy ryzyka: oprócz klasycznego włamania dochodzi np. możliwość „zatruwania” danych treningowych lub manipulacji wejściami w sposób, który prowadzi do błędnych rekomendacji.

Podstawowe mechanizmy bezpieczeństwa obejmują:

• logowanie wszystkich połączeń z i do serwerów AI,
• śledzenie wersji modeli oraz powiązanie wyników z konkretną wersją,
• monitoring anomalii w wejściach (np. nagłe skoki wartości spoza fizycznie możliwego zakresu),
• kontrolę integralności modeli (podpisy cyfrowe, checksumy).

W praktyce przydają się dashboardy, na których zespół OT/IT widzi, jak często model jest wywoływany, jakie zakresy rekomendacji proponuje, ile razy został „odcięty” przez warstwę bezpieczeństwa. To pozwala wychwycić zarówno błędy techniczne, jak i próby nadużyć.

Zbieranie i przygotowanie danych z systemów SCADA/OT

Źródła danych: nie tylko historian

Choć historian jest głównym źródłem danych dla AI, często okazuje się niewystarczający. Do modeli przydatne są także:

• dane z systemów MES (zlecenia, receptury, czasy przezbrojeń),
• informacje z CMMS (awarie, przestoje, wykonane przeglądy),
• dane laboratoryjne z LIMS (parametry jakości),
• logi alarmów z SCADA, często w osobnych bazach.

Łącząc te źródła, uzyskuje się pełniejszy obraz procesu: nie tylko „co się działo na czujniku”, ale także „jakie zadanie było wykonywane” i „w jakim stanie były urządzenia”. Bez takiego kontekstu trudno jest zbudować solidne modele predykcyjne.

Problemy jakości danych w środowisku przemysłowym

Dane z OT są zwykle bogate, ale dalekie od ideału. Najczęstsze problemy to:

• brakujące fragmenty czasowe (awarie komunikacji, przerwy serwisowe),
• zmiany nazw tagów lub jednostek bez odpowiedniej dokumentacji,
• różne częstotliwości próbkowania dla powiązanych sygnałów,
• wartości zastępcze (np. 9999) oznaczające błąd, ale nieoznaczone formalnie.

Przygotowując dane do AI, warto zautomatyzować wykrywanie takich sytuacji. Typowe techniki to tworzenie „mask” jakościowych (flagi, które informują model, że w danej chwili dane były niepewne) oraz standaryzacja jednostek i zakresów na etapie ekstrakcji.

Jeśli w procesie często przeprowadza się testy lub operacje nietypowe (np. rozruchy, czyszczenia), dobrze jest je odpowiednio oznaczyć. Modele trenowane na mieszance danych z rozruchu i stabilnej produkcji będą generowały mylące wyniki.

Synchronizacja czasowa i łączenie strumieni

Proces przemysłowy to wiele sygnałów o różnych częstotliwościach. Aby model mógł z nich korzystać, trzeba je odpowiednio zsynchronizować.

Praktyczne podejście obejmuje kilka kroków:

• wspólny zegar referencyjny (NTP) dla systemów zbierających dane,
• agregację do ustalonego interwału (np. 1 s, 10 s, 1 min) z jasną definicją funkcji (średnia, maksimum, wartość na końcu okresu),
• wyrównanie opóźnień – niektóre sygnały reagują z czasem, więc trzeba skorygować ich przesunięcie.

Przykład: aby przewidywać temperaturę wyjściową reaktora, model może potrzebować przepływu, temperatury na wejściu i mocy grzałek z przesunięciem o kilka minut. Bez takiego dopasowania model będzie „uczył się” przypadkowych zależności.

Etykietowanie zdarzeń i budowa „prawdy referencyjnej”

Dla wielu zastosowań kluczowe jest zbudowanie wiarygodnej „prawdy referencyjnej” – np. etykiet awarii, stanów niepożądanych, sytuacji wymagających interwencji. Sam historian ich nie zawiera.

Źródłem etykiet mogą być:

• zapisy w CMMS (awarie, przestoje),
• raporty zmianowe operatorów,
• dzienniki alarmów (np. wystąpienie alarmu wysokiego ciśnienia),
• ręczne oznaczenia inżynierów procesu na podstawie analizy historii.

Proces budowy etykiet często wymaga pracy warsztatowej: zespół OT i data scientist wspólnie przeglądają historyczne sytuacje, definiują kryteria „zdarzenia” (np. spadek wydajności poniżej określonego progu przez określony czas) i automatyzują ich wykrywanie w danych.

Standaryzacja i katalogowanie zmiennych procesowych

W wielu zakładach te same wielkości fizyczne są różnie nazywane w różnych systemach i liniach. Integracja AI jest dobrym impulsem do uporządkowania tego chaosu.

Pomocne jest stworzenie katalogu zmiennych procesowych, który zawiera:

• nazwa fizyczna (np. „temperatura zasilania pieca 1”),
• lokalne nazwy tagów w SCADA, DCS, MES,
• jednostki, zakresy fizyczne i operacyjne,
• informację o roli (wejście sterujące, pomiar, stan binarny).

Na tej podstawie projektuje się warstwę semantyczną, która dla AI prezentuje spójny zestaw zmiennych, niezależnie od tego, z jakiego konkretnego systemu pochodzą. Ułatwia to nie tylko trenowanie modeli, ale też późniejsze utrzymanie i migracje.

Projektowanie architektury AI w środowisku przemysłowym

Modele uruchamiane na edge kontra centralny serwer

Decyzja, gdzie uruchomić modele AI, wpływa na bezpieczeństwo, niezawodność i koszty. Dwa skrajne podejścia to:

• edge – małe urządzenia lub serwery przy linii, blisko sterowników,
• centralny serwer on-prem lub w chmurze – obsługujący wiele linii i zakładów.

Edge ma sens tam, gdzie wymagane są bardzo małe opóźnienia lub gdy łącza do centrum są niestabilne. Modele działają lokalnie, korzystają z danych z tej samej sieci i mogą podjąć decyzję nawet przy braku połączenia z serwerem centralnym. Zwykle stosuje się tu proste modele inference, a trenowanie realizuje się gdzie indziej.

Modele w chmurze prywatnej i publicznej

Chmura kusi elastycznością i mocą obliczeniową, ale w środowisku OT wymaga bardzo czytelnych granic. Najczęściej wykorzystuje się ją do trenowania modeli, analizy wsadowej i testowania nowych pomysłów, nie do bezpośredniego sterowania procesem.

Bezpieczny układ zakłada, że do chmury trafiają dane odseparowane od identyfikatorów urządzeń i ludzi, po wstępnej agregacji. Modele trenowane w chmurze są następnie „paczkujące” i przenoszone do środowiska on-prem/edge w formie artefaktów (np. plik modeli, kontenery).

Lepiej unikać sytuacji, w której chmurowy serwis ma bezpośredni dostęp do sieci OT lub do systemu SCADA/DCS. Jeśli trzeba go podłączyć online, robi się to przez dobrze pilnowaną warstwę pośrednią w sieci IT z dodatkowym proxy, filtrowaniem protokołów i jednoznacznymi regułami ruchu wychodzącego.

Redundancja i tryb degradacji funkcji AI

AI nie może być pojedynczym punktem awarii. Dla procesów krytycznych projektuje się tryby pracy, w których brak modelu nie zatrzymuje produkcji, a jedynie ją „ogłupia” do klasycznych algorytmów.

Typowy schemat to:

• warstwa sterowania podstawowego (PLC, DCS) – zawsze aktywna i samowystarczalna,
• warstwa optymalizacyjna z AI – nadpisuje tylko wybrane nastawy w ramach dopuszczalnych zakresów,
• mechanizm przełączenia w tryb ręczny/bez AI w razie awarii modelu, braku danych lub podejrzenia błędu.

Modele inference można dublować na dwóch niezależnych instancjach (np. dwa serwery w tym samym segmencie). SCADA porównuje odpowiedzi, a jeśli rozjazd przekroczy próg, system automatycznie przełącza się w tryb bez AI i generuje alarm.

Aktualizacje, wersjonowanie i „roll-back” modeli

Model AI jest oprogramowaniem, które zmienia się częściej niż klasyczny kod PLC. Bez jasnego systemu wersjonowania łatwo o chaos i trudne do odtworzenia sytuacje procesowe.

Praktyczne podejście obejmuje:

• repozytorium modeli z jednoznacznymi wersjami i metadanymi (data trenowania, zakres danych, parametry),
• procedurę wdrożeń z etapem testów offline, a następnie „shadow mode” – model liczy rekomendacje, ale nie ma wpływu na proces,
• mechanizm roll-back: szybki powrót do poprzedniej wersji w razie pogorszenia wskaźników.

Przy zmianie modelu dobrze jest prowadzić krótkie okno obserwacji z podwyższoną czujnością operatorów i inżynierów procesu. Często mały błąd w przeskalowaniu zmiennej ujawnia się dopiero pod konkretnym obciążeniem linii.

Integracja logiczna AI z SCADA, PLC i DCS

Wzorce wymiany danych: od odczytu pasywnego do sterowania aktywnego

Ze względu na ryzyko, integrację AI prowadzi się etapami. Zaczyna się od odczytu pasywnego, gdzie model tylko obserwuje proces i generuje wskazówki offline, a kończy na sterowaniu aktywnym z ograniczonym dostępem do nastaw.

Praktyczny podział wygląda tak:

• tryb obserwacyjny – AI czyta dane historyczne lub strumień online, ale niczego nie zapisuje,
• tryb doradczy – AI publikuje rekomendacje w dedykowanych tagach/tabelach, operator decyduje o działaniu,
• tryb półautomatyczny – AI proponuje zmianę nastawy, SCADA/DCS stosuje ją po dodatkowym warunku (np. akceptacja operatora, brak alarmu),
• tryb automatyczny – AI ma prawo zmieniać wybrane nastawy w wąskich granicach; nadrzędna logika PLC/DCS pilnuje ograniczeń bezpieczeństwa.

Przeskok między trybami powinien być świadomą decyzją zarządzaną procedurą, a nie „cichą” zmianą konfiguracji serwera.

Interfejsy komunikacyjne i protokoły

Do połączenia AI z systemami automatyki używa się standardowych interfejsów, które działają już w zakładzie. Dzięki temu unika się wprowadzania egzotycznych protokołów bez wsparcia producentów.

Najczęstsze opcje to:

• OPC UA – jako główna „warstwa semantyczna” między AI a SCADA/DCS,
• REST/HTTP lub MQTT – przy integracji z middleware w sieci IT (broker, ESB, platforma IoT),
• bazy danych SQL/NoSQL – gdy AI pracuje na danych z historiana i systemów MES/CMMS.

Bezpośrednie łączenie AI z PLC przez protokoły przemysłowe (np. Modbus/TCP, Profinet) stosuje się ostrożnie i zwykle tylko w prostych, lokalnych zastosowaniach na edge. Tam również model działa w tej samej sieci, a ruch jest filtrowany przez zapory na poziomie komórki/obszaru.

Warstwa pośrednia: broker komunikatów i API

Aby nie każda aplikacja AI „dotykała” SCADA i historiana, przydaje się warstwa pośrednia w sieci IT. Jest to często broker komunikatów lub zestaw serwisów API, które wystawiają dane procesowe w formie ujednoliconej dla wszystkich modeli.

Taka warstwa:

• tłumaczy protokoły OT na standardy IT (OPC UA → REST/MQTT),
• implementuje autoryzację i limity wykorzystania danych,
• pozwala podłączyć wiele modeli bez kaskadowego obciążania SCADA/historiana.

W dużych organizacjach buduje się „platformę danych przemysłowych”, w której AI jest tylko jednym z konsumentów. Dzięki temu zmiana konkretnego modelu nie pociąga za sobą zmian w konfiguracji sterowników.

Reprezentacja rekomendacji AI w SCADA i DCS

Aby operatorzy ufali modelowi, muszą widzieć jego rekomendacje w znany sobie sposób. AI nie powinna być „czarną skrzynką”, która działa gdzieś w tle bez śladu na ekranach synoptycznych.

Typowo rekomendacje prezentuje się jako:

• oddzielne wskaźniki (np. „zalecana nastawa temperatury”, „szacowany czas do awarii”),
• paski trendów zestawione z faktycznym przebiegiem sygnału,
• komentarze tekstowe w raporcie zmianowym (np. „model sugeruje obniżenie przepływu o 5%”).

Logika DCS/SCADA powinna jednoznacznie oznaczać, czy podana nastawa pochodzi z AI, czy z ręcznej ingerencji operatora. Pomaga to przy analizie incydentów i przy szkoleniach.

Logika nadrzędna: bezpieczne „opakowanie” decyzji AI

Nawet najlepszy model może się pomylić lub otrzymać błędne dane. Dlatego jego decyzje przechodzą przez dodatkową warstwę logiki w SCADA/PLC/DCS, która wymusza ograniczenia bezpieczeństwa i procesowe.

W praktyce stosuje się m.in.:

• limity zmian w czasie (np. maksymalna zmiana zaworu na minutę),
• okna dopuszczalnych wartości (min/max) ustalone przez inżynierów procesu,
• blokady w stanach nienormalnych (alarmy wysokiego/ niskiego poziomu, tryb awaryjny).

AI nie powinna mieć możliwości wyłączenia zabezpieczeń procesowych ani ingerowania w logikę ESD/SIS. Jakiekolwiek sygnały związane z bezpieczeństwem funkcjonalnym pozostają pod pełną kontrolą systemów certyfikowanych.

Obsługa błędów i sytuacji wyjątkowych

Integracja z AI wymaga jasnych scenariuszy zachowania systemu na wypadek błędów: brak odpowiedzi modelu, przekroczenie czasów odpowiedzi, wyniki poza fizycznym zakresem.

Najprostszy schemat to:

• timeout na odpowiedź modelu, po którym obowiązuje wartość domyślna lub ostatnia dobra,
• walidacja zakresów po stronie SCADA/PLC/DCS i odrzucanie poleceń spoza dopuszczalnych granic,
• alarm dla operatora z informacją, że rekomendacje AI są chwilowo niedostępne lub odrzucone.

Równie ważne jest logowanie tych sytuacji. Analiza historii odrzuconych rekomendacji często prowadzi do poprawy modelu albo do wykrycia problemów w danych wejściowych (np. błędnie skalibrowanego czujnika).

Współpraca zespołów OT, IT i data science

Integracja logiczna to nie tylko technika, ale też organizacja pracy. Bez stałej współpracy między automatykami, zespołem infrastruktury IT i specjalistami od danych modele szybko rozmijają się z praktyką produkcji.

Dobrą praktyką są regularne przeglądy:

• sesje wspólnej analizy trendów i zdarzeń,
• omówienie przypadków, w których operatorzy zignorowali rekomendacje AI i dlaczego,
• planowanie zmian w modelu równolegle z planowanymi modernizacjami linii.

Proste narzędzie, jak wspólny dziennik obserwacji (operatorzy notują, kiedy model „mówi głupoty”), bywa cenniejsze niż rozbudowane raporty. Na tej podstawie data scientist wie, które fragmenty danych i które scenariusze eksploatacyjne wymagają dopracowania.

Najczęściej zadawane pytania (FAQ)

Jak bezpiecznie zacząć integrację AI z istniejącym systemem SCADA/OT?

Najbezpieczniej wystartować od trybu pasywnego (shadow mode). AI tylko czyta dane z SCADA lub historianów i generuje rekomendacje „na boku”, bez wpływu na sterowanie. Zespół porównuje te sugestie z decyzjami operatorów i rzeczywistym zachowaniem procesu.

Dopiero gdy model pokaże stabilne i zrozumiałe wyniki, można wprowadzić rekomendacje na ekrany HMI jako dodatkowe informacje. Automatyczny wpływ na nastawy zostawia się na późniejszy etap i projektuje tak, by dało się go jednym ruchem odłączyć.

Czy integracja AI wymaga zmian w kodzie PLC lub DCS?

Na początku – nie. Bezpieczne podejście zakłada brak ingerencji w logikę sterowników. Dane pobiera się przez istniejące interfejsy (SCADA, historian, OPC, protokoły polowe), a AI działa poza krytyczną pętlą sterowania.

Model zwraca rekomendacje jako dodatkowe nastawy, miękkie alarmy lub wskaźniki zdrowia instalacji. Jeśli pojawia się warstwa półautomatyczna, działa ona w logice pośredniej, którą można łatwo wyłączyć bez zatrzymywania procesu.

Jakie realne problemy w zakładzie przemysłowym rozwiązuje AI w SCADA/OT?

Najczęściej AI pomaga tam, gdzie klasyczna automatyka i proste raporty nie wystarczają. Typowe obszary to predykcja awarii, optymalizacja zużycia energii, poprawa jakości i wsparcie operatora przy diagnozie przyczyn alarmów.

Przykład: model wykrywa nietypowy wzór drgań łożyska kilka dni przed klasycznym alarmem, albo wskazuje kombinację nastaw, która pozwala utrzymać jakość przy mniejszym poborze pary. Wszystko w oparciu o dane, które zakład już zbiera.

Jak ograniczyć ryzyko cyberbezpieczeństwa przy wdrażaniu AI w OT?

Kluczowe jest zachowanie wyraźnej granicy między siecią OT a infrastrukturą AI. Nowe serwery i usługi wprowadza się do dobrze kontrolowanej strefy (np. DMZ), z minimalnym zakresem otwartych połączeń i jasno zdefiniowanymi protokołami.

System AI powinien mieć tylko takie uprawnienia, jakie są konieczne: głównie odczyt danych procesowych, bez możliwości bezpośredniego programowania sterowników. Integrację projektuje się tak, by awaria komponentu AI nie wpływała na działanie PLC/DCS.

Kto odpowiada za decyzje podejmowane na podstawie zaleceń AI?

W środowisku OT odpowiedzialność nie może być „rozmyta”. Ustala się, kto zatwierdza rekomendacje (np. operator, mistrz zmianowy, inżynier procesu) i w jakich sytuacjach można zastosować je automatycznie. Te zasady powinny być opisane w procedurach i instrukcjach pracy.

Przy modelach predykcyjnych typowe podejście to: AI zgłasza ryzyko, człowiek decyduje o reakcji (np. wcześniejszy przegląd, zmiana nastaw). Logi z działania modelu i podjęte decyzje są archiwizowane tak, aby dało się je pokazać przy audycie lub analizie incydentu.

Jak włączyć AI w codzienną pracę operatorów, żeby nie była „gadżetem”?

AI musi pojawić się tam, gdzie operator faktycznie pracuje – na ekranach HMI/SCADA, w raportach zmianowych, w systemach planowania przeglądów. Same dodatkowe dashboardy w osobnym narzędziu zwykle kończą na marginesie.

Dobre praktyki to m.in. omawianie rekomendacji AI na porannych odprawach, dodanie ich do standardowych procedur reakcji na alarmy i powiązanie z harmonogramem utrzymania ruchu. Operator widzi wtedy, że model realnie wpływa na decyzje, a nie tylko generuje wykresy.

Czy da się zastosować AI w zakładzie z bardzo starymi systemami SCADA i sterownikami?

Tak, ale wymaga to warstwy pośredniej, która „przetłumaczy” różne protokoły i wersje systemów na jednolity strumień danych. AI nie łączy się bezpośrednio z każdym sterownikiem, tylko z jedną, dobrze zaprojektowaną bramą danych.

W praktyce oznacza to korzystanie z istniejących historianów, serwerów OPC lub dedykowanych gatewayów. Dzięki temu nawet linia z Modbus RTU i starym DCS może zasilać modele predykcyjne, bez wymiany całej infrastruktury automatyki.

Bibliografia i źródła

• IEC 62443 Industrial communication networks – IT security for networks and systems. International Electrotechnical Commission – Podstawowy zbiór norm cyberbezpieczeństwa dla systemów SCADA/OT
• NIST SP 800-82 Guide to Industrial Control Systems (ICS) Security. National Institute of Standards and Technology (2015) – Wytyczne bezpieczeństwa ICS, SCADA, DCS i PLC
• ISA-95 Enterprise-Control System Integration. International Society of Automation – Model integracji warstw biznesowych z systemami sterowania
• ISO 50001 Energy management systems – Requirements with guidance for use. International Organization for Standardization (2018) – Ramy zarządzania energią, kontekst optymalizacji zużycia energii
• Artificial Intelligence in Industry 4.0: A Survey. IEEE (2019) – Przegląd zastosowań AI w przemyśle i środowiskach OT