Jak połączyć DevOps i MLOps w środowisku OT: wdrażanie modeli AI na linie produkcyjne

Gdzie spotykają się DevOps, MLOps i OT: ustawienie sceny

Czym różni się IT, OT i „AI na hali produkcyjnej”

Środowisko IT, OT i uruchamianie modeli AI na liniach produkcyjnych to trzy światy o zupełnie innych priorytetach. Łączą się dopiero wtedy, gdy trzeba zrobić coś bardzo konkretnego: włączyć model uczony w Pythonie do codziennej pracy maszyn na hali. I wtedy nagle okazuje się, że piękny kod z laboratorium zderza się z PLC sprzed kilkunastu lat, brakiem internetu, oknami serwisowymi raz na kwartał i bardzo małą tolerancją na błędy.

Świat IT jest elastyczny. Aplikacje można zrestartować, przenieść między serwerami, zwiększyć zasoby w chmurze. Jeśli strona WWW będzie niedostępna kilka minut, większość firm to przeżyje. DevOps powstał właśnie tutaj – jako zestaw praktyk i kultury pracy, który łączy rozwój oprogramowania (Dev) z utrzymaniem (Ops), żeby szybciej i bezpieczniej dostarczać zmiany.

OT (Operational Technology) to inna historia. Tutaj królują sterowniki PLC, systemy SCADA, DCS, panele HMI i sieci przemysłowe. Wszystko jest podporządkowane ciągłości procesu, bezpieczeństwu ludzi i sprzętu oraz zgodności z normami. Nie ma mowy o częstych restartach, eksperymentach na żywym organizmie czy „spróbujmy i zobaczymy”. Zespół UR woli stabilne, przewidywalne rozwiązania, nawet jeśli będą technologicznie starsze.

AI na hali produkcyjnej siada dokładnie pomiędzy tymi światami. Modele wymagają zazwyczaj środowiska IT (serwer, kontener, biblioteki ML), ale mają wpływ na decyzje w świecie OT: poziom alarmu, parametr receptury, prędkość linii czy planowany postój. Do tego dochodzi presja na efektywność i automatyzację. Rezultat? Powstaje trzeci wymiar – AI w OT – który trzeba zaprojektować z pełną świadomością ograniczeń obu stron.

Dlaczego samo DevOps lub samo MLOps nie wystarcza w przemyśle

DevOps świetnie radzi sobie z ciągłym wdrażaniem aplikacji, ale zupełnie nie dotyka problemu jakości modeli ML, dryfu danych czy ponownego trenowania. Z kolei MLOps rozpisuje cykl życia modelu – od danych do monitoringu predykcji – ale zazwyczaj w świecie bliższym chmurze niż szafie sterowniczej przy prasie czy wtryskarce.

W realnej fabryce pojawiają się dodatkowe warstwy komplikacji:

• Komponenty AI muszą współpracować z systemami sterowania czasu rzeczywistego, które nie tolerują opóźnień i niespójności.
• Zmiany w systemach produkcyjnych wymagają formalnych procedur, testów FAT/SAT, przeglądów bezpieczeństwa.
• Infrastruktura jest często on-premise lub edge, odcięta od internetu, z restrykcyjną polityką dostępu.

Dlatego połączenie DevOps i MLOps w środowisku OT to nie jest „ładna nazwa w slajdach”, ale praktyczna konieczność. Procesy CI/CD trzeba rozszerzyć o zarządzanie modelami, a procesy MLOps – zakotwiczyć w realnych ograniczeniach OT. Jeżeli ograniczymy się tylko do podejścia DevOps, modele szybko się zestarzeją i staną się nieużyteczne. Jeżeli zostaniemy w czystym MLOps bez dyscypliny DevOps, wdrożenia będą chaotyczne i trudne do utrzymania.

Po co łączyć DevOps i MLOps w OT: perspektywa biznesowa

Firmy produkcyjne nie wdrażają AI dla samego wdrażania. Interesują je konkretne efekty: mniejsza liczba awarii, mniej braków jakościowych, krótsze przezbrojenia, stabilniejszy proces. Do tego dochodzi presja na standaryzację rozwiązań między zakładami i liniami, tak aby wiedza i modele nie były „jednorazowym eksperymentem” w jednej fabryce.

Połączenie DevOps i MLOps w OT daje kilka kluczowych korzyści biznesowych:

• Dostępność – zmiany w modelach i oprogramowaniu wspierającym AI nie wyłączają linii produkcyjnej i są planowane w uzgodnionych oknach.
• Przewidywalność – istnieje proces testowania, akceptacji i rollbacku, więc ryzyko „niespodzianek” spada.
• Standaryzacja – kolejne linie i zakłady korzystają z tej samej architektury, narzędzi i wzorców wdrożeniowych.
• Transparentność – wiadomo, jaka wersja modelu jest uruchomiona na którym edge’owym urządzeniu, kiedy była trenowana i na jakich danych.

Łącząc DevOps, MLOps i realia OT, buduje się po prostu powtarzalny, zautomatyzowany szkielet, w którym można bezpiecznie umieszczać kolejne modele – zamiast budować każdy projekt AI jako osobny, ręcznie klejony eksperyment.

Typowe scenariusze użycia AI na liniach produkcyjnych

Predykcyjne utrzymanie ruchu (predictive maintenance)

Predictive maintenance to jeden z pierwszych obszarów, gdzie pojawia się pytanie: jak zorganizować ciągłe wdrażanie modeli ML w środowisku OT? Modele monitorują wibracje, temperatury, prądy silników, czas cyklu, liczbę restartów, a następnie przewidują prawdopodobieństwo awarii lub potrzebę przeglądu.

Przepływ danych w tym scenariuszu wygląda zwykle tak: PLC zbiera sygnały z czujników i wysyła je (np. przez OPC UA, Modbus TCP, Profinet) do systemu zbierania danych – historians, system IIoT, broker OPC UA lub gateway. Stamtąd dane trafiają do platformy analitycznej lub bezpośrednio do komponentu inference modelu AI, umieszczonego na serwerze on-prem lub urządzeniu edge.

Cechy charakterystyczne:

• Wymogi czasowe – często wystarczy predykcja co minutę, co kilka minut, a czasem raz na zmianę. To nie zawsze jest system czasu rzeczywistego.
• Zależność biznesowa – błąd modelu może oznaczać niepotrzebny postój lub przegapienie nadchodzącej awarii. Skutki są kosztowne, ale zwykle nie zagrażają bezpośrednio bezpieczeństwu ludzi.
• Miejsce uruchomienia – w wielu zakładach sprawdza się serwer on-prem zintegrowany z systemem UR, ewentualnie hybryda: przetwarzanie wstępne na edge, trenowanie w chmurze.

DevOps i MLOps pomagają tu zautomatyzować proces: od zbierania danych, przez trening i wersjonowanie modeli, aż po kontrolowane wdrażanie nowej wersji na serwerze produkcyjnym. Dobrze zorganizowany pipeline pozwala np. wypuścić nową wersję modelu najpierw na jedną linię (canary), obserwować wyniki, a dopiero później rozpropagować go na cały zakład.

Kontrola jakości i wizja maszynowa

Drugi, bardzo dynamicznie rosnący obszar to wizja maszynowa. Kamery lub systemy 3D oceniają jakość produktów: wykrywają rysy, zabrudzenia, deformacje, nieprawidłowe nadruki, brak elementów. Przykładowo na linii pakowania model ma ułamki sekund na ocenę, czy opakowanie jest poprawne, zanim produkt wjedzie do kartonu.

Przepływ danych jest tutaj inny niż w predykcyjnym utrzymaniu ruchu. Dane są duże (obrazy, strumienie wideo), wymagają niskich opóźnień i bardzo często nie mogą opuszczać hali produkcyjnej ze względu na przepustowość i bezpieczeństwo. W efekcie inference modeli wizji maszynowej prawie zawsze ląduje na edge – przemysłowym PC, GPU-boxie lub specjalizowanym urządzeniu przy linii.

Konsekwencje dla DevOps/MLOps:

• Modele muszą być spakowane z całym środowiskiem inference w kontener lub obraz systemu, który da się zaktualizować w kontrolowany sposób.
• Monitoring musi zbierać nie tylko logi z predykcji, ale też metryki czasu odpowiedzi, obciążenia CPU/GPU i ewentualne kolejki ramek.
• Okna serwisowe na aktualizacje są krótkie – często trzeba zastosować blue/green deployment: dwie równoległe instancje i przełączanie ruchu między nimi.

Model AI w takiej konfiguracji staje się elementem „łańcucha reakcji” na linii. Jeżeli przestanie działać lub zacznie działać wolno, cała linia może przejść w tryb awaryjny albo wyłączać zbyt wiele dobrych produktów. Stąd ogromne znaczenie połączenia dyscypliny DevOps (CI/CD, monitoring, rollback) z cyklem MLOps (wersjonowanie, monitoring jakości predykcji).

Optymalizacja procesów i parametrów produkcji

Trzeci scenariusz to optymalizacja ustawień maszyn i procesów. Modele uczą się, jakie kombinacje parametrów (temperatury, ciśnienia, prędkości, dozowania) dają najlepszą jakość i wydajność przy minimalnym zużyciu energii czy surowca. Mogą działać jako system rekomendacji dla operatora lub bezpośrednio korygować nastawy w PLC.

Tu napięcie między IT, OT i AI jest szczególnie odczuwalne. Zespół procesu i UR obawia się, że „czarna skrzynka” zacznie sterować produkcją. Zespół data science chciałby za to automatyzować jak najwięcej. Praktyczny kompromis często wygląda tak, że model działa najpierw jako doradca – generuje propozycje nastaw na osobnym ekranie HMI lub w systemie MES. Po zbudowaniu zaufania możliwe jest częściowe zautomatyzowanie reakcji, np. w wąskim zakresie parametrów.

W tym scenariuszu bardzo istotna jest współpraca z ekspertami procesu. Walidacja modelu nie polega tylko na AUC czy MAPE w Jupyter Notebooku, ale na wspólnej ocenie: czy rekomendacje są stabilne, zrozumiałe, zgodne z zasadami bezpieczeństwa procesu. To wymusza specyficzne podejście MLOps: włączenie ekspertów OT do procesu walidacji modelu przed wdrożeniem.

Pod względem architektury miejsce uruchomienia modelu zależy od wymogów czasowych i krytyczności. Jeżeli model będzie korygował nastawy co kilka minut, wystarczy on-prem klaster ML z integracją do PLC przez OPC UA lub brokera komunikatów. Jeżeli korekty muszą być co kilka sekund – rośnie presja na edge i deterministyczną komunikację z PLC. W obu przypadkach proces DevOps/MLOps musi przewidywać bezpieczny fallback: co się dzieje, gdy model przestaje działać lub zostaje zdezaktywowany.

Architektura referencyjna: jak ułożyć AI między IT, OT i chmurą

Warstwa danych: od czujnika do feature store

Żeby modele mogły sensownie działać, ich „paliwo” – dane – musi być zebrane, oczyszczone i dostępne w powtarzalny sposób. W środowisku OT przepływ danych jest wieloetapowy. Wszystko zaczyna się od czujników podłączonych do sterowników PLC, modułów I/O lub bezpośrednio do systemów SCADA/DCS. Tam dane są próbkowane i agregowane zgodnie z logiką procesu.

Typowa ścieżka wygląda następująco:

1. PLC/SCADA zbiera surowe sygnały procesowe.
2. OT gateway / serwer OPC UA udostępnia dane w ustandaryzowanej formie dla świata IT.
3. System IIoT / data platform on-prem buforuje, zapisuje i udostępnia strumienie danych do dalszej analizy.
4. Feature store (on-prem lub hybrydowy) przechowuje już przetworzone cechy wykorzystywane przez modele ML.

DevOps i MLOps w tej warstwie objawia się w wersjonowaniu pipeline’ów ETL/ELT, transformacji i definicji cech. Zmiana sposobu liczenia cechy (np. innego okna czasowego dla średniej) wymaga tych samych rygorów co wdrożenie nowego modelu: przetestowania, zatwierdzenia, możliwości powrotu do poprzedniej wersji.

W praktyce bardzo pomaga zdefiniowanie wspólnego języka między IT, OT i data science: słowniki tagów, mapowanie tagów do cech, opis jednostek i zakresów wartości. Bez tego łatwo o klasyczną pułapkę: model „działał” w laboratorium, ale na produkcji dane mają inne skale lub offsety, co prowadzi do cichych błędów.

Warstwa obliczeniowa: edge, on-prem, chmura i ich kombinacje

W świecie DevOps chmura jest naturalnym wyborem. W świecie OT – już niekoniecznie. Aktualna praktyka w przemyśle to architektury hybrydowe, gdzie różne elementy cyklu życia modelu lądują w różnych miejscach.

Dobór lokalizacji zależy od kilku czynników:

• Wymogi czasowe – im krótszy czas reakcji modelu, tym bliżej maszyny musi znajdować się komponent inference.
• Bezpieczeństwo i regulacje – część firm i sektorów nie pozwala na przesyłanie danych produkcyjnych poza teren zakładu.

Warstwa zarządzania: kto, co i jak kontroluje

Między surowymi danymi a modelami uruchomionymi przy maszynach pojawia się jeszcze jedna, często niedoceniana warstwa: zarządzania i nadzoru. To tutaj spotykają się zespoły IT, OT, data science i bezpieczeństwa. Jeżeli w tej warstwie panuje chaos, reszta układanki też będzie chwiejna.

Kluczowy jest jasny podział ról i odpowiedzialności. W praktyce przydaje się prosty model:

• IT/DevOps odpowiada za infrastrukturę, sieci, konteneryzację, CI/CD i standardy bezpieczeństwa.
• Data science / MLOps odpowiada za cykl życia modeli: eksperymenty, trening, walidację, wersjonowanie, monitoring jakości predykcji.
• OT / inżynierowie procesu odpowiadają za integrację z liniami produkcyjnymi, scenariusze awaryjne, testy w warunkach zbliżonych do rzeczywistych.

Gdy każdy „wie swoje”, można ustalić konkretne interfejsy: kto zatwierdza nową wersję kontenera inference, kto decyduje o przejściu z trybu doradczego na automatyczny, kto może wcisnąć „stop” i wyłączyć model na linii. Taki „RACI” dla modeli AI pozwala uniknąć sytuacji, w której data scientist w piątek wieczorem wypuszcza nowy model, a w sobotę rano operatorzy zastanawiają się, czemu linia zachowuje się inaczej.

Na tej warstwie dobrze sprawdza się też wspólna „konsola wglądu” – dashboard, na którym w jednym miejscu widać status modeli (MLOps), status infrastruktury (DevOps) i podstawowe KPI produkcyjne (OT). Dzięki temu, gdy pojawia się problem, nie trwa długo wzajemne przerzucanie się pytaniem: „to wina modelu, sieci czy maszyny?”

Bezpieczeństwo i segmentacja: jak nie otworzyć OT na oścież

Włączenie AI do linii produkcyjnych oznacza więcej połączeń między siecią IT i OT. Dla zespołów bezpieczeństwa to często moment, w którym włącza się czerwona lampka – i słusznie. Model AI uruchomiony na edge to dodatkowy komponent w krytycznym środowisku, który trzeba włączyć w politykę bezpieczeństwa, a nie traktować jako „eksperyment data science”.

Typowe praktyki, które łączą świat DevSecOps z OT:

• Segmentacja sieci – strefy OT (linie produkcyjne, PLC) są odseparowane od IT, a komponenty AI wpinają się w strefę pośrednią (DMZ lub strefa IIoT). Komunikacja jest minimalna i kontrolowana.
• Kontenery jako jednostka bezpieczeństwa – wszystkie elementy inference (model, biblioteki, API) pakowane są w kontenery z minimalnym zestawem zależności. Obraz przechodzi skanowanie pod kątem podatności.
• „Zero trust” dla połączeń – każda komunikacja z chmurą, repozytorium artefaktów czy systemem CI/CD jest szyfrowana i autoryzowana, często z użyciem certyfikatów i pośrednich brokerów.
• Kontrola zmian – żadna aktualizacja modelu czy kontenera inference nie trafia na linię bez zatwierdzenia i odnotowania w systemie change management.

Dobrym wyznacznikiem dojrzałości jest odpowiedź na proste pytanie: czy potrafisz w godzinę wycofać każdą zmianę z ostatniej doby i wrócić do stabilnej wersji? Jeśli nie – trzeba wzmocnić zarówno procesy DevOps, jak i integrację z procedurami OT (np. z systemem zarządzania bezpieczeństwem funkcjonalnym).

Fundamenty: jak przełożyć zasady DevOps na środowisko OT

CI/CD dla modeli i komponentów inference

DevOps w IT to głównie automatyzacja budowania, testowania i wdrażania aplikacji. W OT dochodzą dodatkowe ograniczenia: okna serwisowe, wymogi walidacji, testy bezpieczeństwa. Mimo to da się zbudować skuteczne CI/CD dla modeli AI, trzeba tylko inaczej poukładać etapy.

Przykładowy pipeline CI/CD dla komponentu inference może wyglądać tak:

1. Build – z kodu i artefaktu modelu (np. z MLflow lub innego repozytorium) budowany jest kontener. W tym kroku od razu uruchamiane są testy jednostkowe logiki aplikacyjnej.
2. Testy symulacyjne – kontener odpalany jest w środowisku testowym z danymi historycznymi lub syntetycznymi, które odtwarzają typowe scenariusze z linii. Sprawdza się m.in. czasy odpowiedzi, stabilność, obsługę błędów.
3. Testy integracyjne z OT – w osobnej strefie testowej model komunikuje się z „wirtualnym PLC” lub kopią systemu SCADA/MES. Tutaj wykrywa się różnice w tagach, jednostkach, protokołach.
4. Deployment na środowisko pre-prod – często to osobna linia testowa lub odłączona gałąź infrastruktury, na której model może pracować równolegle do produkcji, ale bez wpływu na rzeczywiste sterowanie.
5. Odbiór OT – inżynierowie procesu i UR przeglądają wyniki, alarmy, stabilność. To etap, którego nie ma w klasycznym IT, a w OT jest kluczowy.
6. Kontrolowane wdrożenie na produkcję – np. canary deployment na jedną linię czy jedną zmianę, z gotowym planem powrotu.

Różnica w stosunku do świata „czysto IT” polega na tym, że etapów z udziałem ludzi jest więcej i są one integralną częścią pipeline’u. Nic nie stoi na przeszkodzie, by wykorzystać te same narzędzia co w DevOps (GitLab CI, GitHub Actions, Jenkins, Argo CD), ale kroki muszą odzwierciedlać rytm produkcji, a nie tylko rytm sprintów deweloperskich.

Infrastruktura jako kod w realiach hal produkcyjnych

Infrastruktura jako kod (IaC) w fabryce brzmi czasem jak science fiction. A jednak wiele elementów da się ująć w kod: konfigurację serwerów on-prem, maszyn wirtualnych pod inferencję, klastrów Kubernetesa, a nawet konfigurację gatewayów IIoT. Dzięki temu środowiska można odtwarzać, porównywać i wersjonować tak samo jak kod aplikacji.

Dobrą strategią jest zaczęcie od tego, co „blisko IT”: klastrów ML on-prem i komponentów edge, które działają w strefie pośredniej między IT a OT. Z czasem, w porozumieniu z zespołem OT, można stopniowo włączać kolejne elementy, np. szablony konfiguracji dla serwerów OPC UA czy brokerów MQTT.

Przykład z praktyki: w jednej z fabryk nowy serwer pod inferencję wizji maszynowej był wcześniej przygotowany jako kod Terraform + Ansible. Gdy okazało się, że trzeba go wymienić po awarii sprzętu, odtworzenie środowiska zajęło kilka godzin, a nie kilka dni ręcznego konfigurowania. To właśnie moment, w którym DevOps pokazuje swoją wartość zespołowi UR.

Monitoring, SLO i incident management w wersji OT

Monitoring systemów AI na linii produkcyjnej nie może kończyć się na metrykach technicznych. Sam CPU, RAM czy latency nie wystarczą – trzeba je powiązać z tym, co widzi produkcja. Dopiero wtedy da się sensownie zdefiniować SLO (Service Level Objectives) dla komponentów AI.

Przykładowe perspektywy monitoringu:

• Perspektywa techniczna – stan usług, wykorzystanie CPU/GPU, pamięci, opóźnienia inference, błędy aplikacji, opóźnienia w dostępie do danych.
• Perspektywa modelu – rozkład przewidywań, drift danych, zmiana rozkładów cech, liczba przypadków „out of distribution”, proste wskaźniki jakości (np. porównanie z późniejszymi obserwacjami).
• Perspektywa procesu – wpływ na KPI (liczba fałszywych odrzutów, ilość nieplanowanych postojów, zużycie energii). To jest język, którym mówi OT.

Do tego dochodzi incident management, czyli uzgodniony sposób reagowania na problemy. Dobrą praktyką jest scenariusz: jeżeli trzy razy z rzędu przekroczony zostanie ustalony próg (np. liczba błędów predykcji lub opóźnień), system automatycznie przełącza się w tryb „model off / manual override”, a do zespołów trafia zgłoszenie. Operator nie musi wtedy zgadywać, co się dzieje – wie, że model się wyłączył i produkcja działa według klasycznych reguł.

Standardy jakości i testy niefunkcjonalne

Środowisko OT jest bezlitosne dla „demo quality”. Model, który w laboratorium działał „w miarę”, na linii szybko ujawnia wszystkie słabości: wolne czasy startu, problemy z pamięcią, zawieszanie się przy gorszej jakości danych. Dlatego tak ważne są testy niefunkcjonalne, planowane tak samo poważnie jak optymalizacja metryki ML.

Przydatne kategorie testów:

• Testy wydajnościowe – sprawdzenie, jak model zachowuje się przy obciążeniu gorszym niż nominalne: więcej ramek na sekundę, większa liczba tagów, zmienny jitter sieci.
• Testy odporności na błędy danych – zerwane połączenia, brakujące wartości, skoki w sygnałach z czujników, zmiana jednostek (np. °C vs °F). Dobrze odtworzyć błędy, które już kiedyś wydarzyły się w systemie SCADA.
• Testy zachowania przy restarcie – czy kontener inference startuje wystarczająco szybko po zaniku zasilania lub restarcie edge? Czy wraca do poprawnej konfiguracji?
• Testy bezpieczeństwa procesu – szczególnie gdy model wpływa na nastawy. Sprawdza się, czy w każdej sytuacji istnieje twardy limit, którego model nie przekroczy, nawet jeśli „zwariuje”.

Te testy można w dużej mierze zautomatyzować w pipeline’ach CI/CD, a część przeprowadzać okresowo na wydzielonych środowiskach, zanim nowa wersja modelu trafi na linię. Wspólnym mianownikiem jest przeniesienie dyscypliny DevOps do świata, gdzie „testem produkcyjnym” nie może być eksperyment na realnej instalacji.

Specyfika MLOps w OT: rozszerzony cykl życia modelu

Od PoC do produkcji: dodatkowe etapy w fabryce

Wielu producentów ma za sobą udane PoC z AI, które nigdy nie trafiły na linię. Powód jest prosty: klasyczny cykl MLOps (eksperymenty – trening – wdrożenie – monitoring) w OT trzeba rozszerzyć o kilka dodatkowych faz, związanych z bezpieczeństwem, regulacjami i kulturą pracy na produkcji.

Rozszerzony cykl życia modelu w środowisku OT obejmuje m.in.:

1. Analizę procesu i ryzyka – wspólnie z OT definiuje się, na co model będzie miał wpływ, jakie są scenariusze awaryjne i gdzie leżą twarde granice bezpieczeństwa.
2. Formalną specyfikację funkcjonalną – model przestaje być „magiczna skrzynką”, a staje się komponentem z opisanym interfejsem, wymaganiami i oczekiwaniami (np. czasy odpowiedzi, zakres danych wejściowych).
3. Fazę „shadow mode” – model działa równolegle do istniejącego systemu, ale nie wpływa na sterowanie. Dane z tej fazy są złotem dla walidacji.
4. Tryb doradczy – model generuje rekomendacje, które trafiają do operatorów. To etap budowania zaufania i uczenia się „jak model myśli”.
5. Tryb automatyczny z ograniczeniami – dopiero tutaj model wchodzi w pętlę sterowania, zazwyczaj w wąskim zakresie i z mocnym fallbackiem.
6. Okresową rewalidację – cykliczna ocena modelu z udziałem OT, biznesu i data science, z decyzją: zostaje, wymaga retrainingu, czy wycofujemy.

Te etapy można częściowo ująć w narzędziach MLOps (statusy modeli, policy na przejście między trybami), ale kluczowa jest transparentna komunikacja. Dla wielu operatorów różnica między „modelem w shadow” a „modelem sterującym” musi być jasna na pierwszy rzut oka, np. w HMI.

Wersjonowanie modeli, danych i konfiguracji OT

W MLOps dużo mówi się o wersjonowaniu modeli i datasetów. W OT trzeba do tego dodać jeszcze jeden element: wersje konfiguracji linii, receptur, parametrów technologicznych. Często to właśnie one decydują, czy model „działa tak jak kiedyś”.

Przydatny jest zestaw zasad:

• Każda wersja modelu powinna być powiązana z zakresem obowiązywania: na jakich liniach, typach produktów, konfiguracjach maszyn jest wspierana.
• W logach inference warto zapisywać identyfikator konfiguracji OT (np. wersję receptury czy konfiguracji PLC), co pozwala później zrozumieć, dlaczego model działał inaczej po zmianie nastaw.
• Zmiany w konfiguracji procesu (nowy produkt, nowa receptura) powinny uruchamiać procedurę oceny wpływu na modele – może potrzebne będzie ponowne trenowanie albo przynajmniej testy symulacyjne.

W praktyce kończy się to na integracji narzędzi MLOps z istniejącymi systemami w zakładzie: MES, systemem zarządzania recepturami, a czasem nawet z systemem dokumentacji technologicznej. To dodatkowy wysiłek, ale bez niego szybko pojawia się sytuacja, że model „przestaje działać” po zmianie procesu, a nikt nie jest w stanie tego powiązać.

Monitoring drif­tu i zarządzanie starzeniem się modelu

W środowisku OT procesy rzadko są w pełni stabilne. Zmienia się surowiec, zużywają się narzędzia, modernizowane są maszyny. Model, który rok temu był idealny, po kolejnych modyfikacjach linii może przynosić znacznie gorsze wyniki. Dlatego monitoring driftu danych i jakości modelu ma tu szczególne znaczenie.

Kluczowe elementy:

Praktyczne metryki driftu dla linii produkcyjnych

Monitorowanie driftu w fabryce musi być przyziemne. Zamiast wymyślnych wskaźników statystycznych, które rozumie tylko data scientist, przydają się proste metryki przekładające się na obraz procesu. Inaczej trudno włączyć OT w dyskusję o „starzeniu się modelu”.

Sprawdzają się m.in. takie sygnały:

• Zmiana rozkładu podstawowych cech – różnice w średniej, odchyleniu czy percentylach dla kilku kluczowych zmiennych procesowych (np. temperatura, ciśnienie, prędkość linii). Można je porównać z referencją z okresu trenowania modelu.
• Wskaźniki jakości powiązane z procesem – procent braków, ilość reklamacji, czas między awariami. Jeśli model ma przewidywać odrzuty, to nagły wzrost braków przy niezmienionej jakości predykcji jest sygnałem ostrzegawczym.
• Odsetek decyzji „na granicy” – np. ile przewidywań znajduje się w strefie niepewności modelu albo ile razy model jest nadpisywany przez operatora (manual override).
• Porównanie z referencyjną logiką – jeśli równolegle istnieje prosty algorytm regułowy (np. progi alarmowe w PLC), można liczyć, jak często model nie zgadza się z tymi regułami i co z tego wynika.

Dane do takich metryk da się zbierać „przy okazji”: z logów inference, z systemów SCADA/MES i z rejestrów jakości. Ważne, żeby dashboard driftu nie był tylko kolejnym wykresem dla IT, ale regularnym punktem w przeglądach z zespołem produkcji.

Strategie retrainingu i zarządzania wersjami w czasie

Gdy drift jest potwierdzony, pojawia się pytanie: trenować od nowa, czy jeszcze poczekać? W środowisku OT każda zmiana ma koszt – testy, walidacja, często także formalna dokumentacja. Dlatego przydaje się jasna strategia utrzymania modeli w czasie.

Najczęściej spotykane podejścia:

• Retraining okresowy – np. raz na kwartał lub po większej modernizacji linii. Sprawdza się tam, gdzie dane są stabilne, a zmiany mają charakter „skokowy” (nowy produkt, nowa maszyna).
• Retraining warunkowy – uruchamiany, gdy spełnione są określone kryteria: spadek wybranej metryki jakości poniżej progu, utrzymujący się drift przez dłuższy czas, zmiana konfiguracji procesu.
• Modele sezonowe – w niektórych zakładach proces różni się między porami roku (np. wpływ temperatury otoczenia) czy zmianami. Wówczas utrzymuje się kilka wariantów modelu i przełącza je zgodnie z kalendarzem lub warunkami środowiska.

Bez względu na strategię, kluczem jest przejrzyste oznaczanie modeli w rejestrze: numer wersji, data trenowania, zakres ważności, użyty zbiór danych i powiązana wersja konfiguracji OT. W razie problemu z produkcją można wtedy cofnąć się krok po kroku i zobaczyć, co się zmieniło.

Proces decyzyjny: kto zatwierdza nowy model na linię

Zatwierdzanie modeli w OT przypomina zatwierdzanie zmian w recepturze technologicznej. Nie może decydować o tym wyłącznie data science ani tylko dział IT, ponieważ konsekwencje ponosi przede wszystkim produkcja.

Przejrzysty proces zwykle obejmuje kilka ról:

• Data scientist / inżynier ML – prezentuje wyniki walidacji, różnice względem poprzedniej wersji, ryzyka techniczne i scenariusze porażki.
• Przedstawiciel OT / UR – ocenia wpływ na proces, wiarygodność scenariuszy awaryjnych, możliwość manualnego sterowania i przełączenia w tryb „bez modelu”.
• Owner procesu / produkcji – akceptuje zmianę z perspektywy KPI, bezpieczeństwa i obciążenia ludzi na zmianie.
• IT / cyberbezpieczeństwo – sprawdza zgodność z politykami bezpieczeństwa, backupem, procedurami disaster recovery.

Dobrą praktyką jest wspólny „go/no-go meeting” poprzedzony krótką fazą testów na wydzielonej części linii albo w trybie shadow/advisory. Zespół patrzy wtedy nie tylko na metryki, ale też na doświadczenia operatorów – czy rozumieją decyzje modelu, czy HMI jest czytelne, czy nie przybyło im skomplikowanych zadań.

Rola operatora i UR w codziennym MLOps

Modele w fabryce nie żyją same z siebie – ich stan sygnalizują często osoby, które nawet nie mają w tytule słowa „AI”. Operator na zmianie, mistrz, technik UR – to oni pierwsi widzą, że „coś jest nie tak” z predykcją czy alarmami.

Żeby ten sygnał nie ginął, przydaje się kilka prostych mechanizmów:

• Prosty kanał zgłaszania problemów – przycisk „zgłoś błąd modelu” w HMI, krótki formularz w systemie zgłoszeń czy dedykowany typ ticketu w systemie utrzymania ruchu.
• Oznaczanie decyzji modelu – operator powinien widzieć, które decyzje pochodzą z AI, a które z klasycznej logiki. To ułatwia zarówno zaufanie, jak i świadome nadpisanie decyzji.
• Szybka ścieżka wyłączenia modelu – jasny przycisk albo procedura „model off”, bez dzwonienia po trzech działach. To nie tylko zwiększa bezpieczeństwo, ale też od razu poprawia komfort pracy załogi.

W jednej z fabryk metalurgicznych prosty formularz „zgłoś dziwną decyzję modelu” w HMI pozwolił w ciągu kilku tygodni zebrać kilkadziesiąt przykładów trudnych przypadków, których nie było w danych treningowych. Z tych danych powstała kolejna wersja modelu, znacznie bliższa realnej pracy pieca.

Wspólny język: jak tłumaczyć modele OT

Jeżeli model ma wejść do sterowania procesem, jego decyzje muszą być chociaż częściowo wytłumaczalne. Nie zawsze da się opowiedzieć szczegóły algorytmu, ale można pokazać, które sygnały były kluczowe dla danej decyzji i w jakim kierunku je „interpretował”.

Pomagają w tym m.in.:

• Proste wskaźniki wpływu cech – na przykład lista trzech–pięciu sygnałów, które w danej decyzji miały największy wpływ, prezentowana obok rekomendacji modelu.
• „Dlaczego?” w HMI – dodatkowy ekran lub panel pokazujący uzasadnienie: „Model obniżył temperaturę, ponieważ w ostatnich X minutach wzrosło zużycie energii przy stałej jakości wyrobu”.
• Warsztaty interpretacyjne – sesje, podczas których zespół OT i data science wspólnie przegląda przykładowe sytuacje, porównuje decyzje modelu z decyzjami operatorów i dyskutuje różnice.

Takie praktyki nie tylko zwiększają zaufanie, ale też pomagają wychwycić sytuacje, w których model uczy się nie tego, co trzeba (np. reaguje na sygnały pośrednie, które w procesie nie mają sensu). To trochę jak nauka nowego pracownika – dopóki nie porozmawiamy, nie wiemy, jak podejmuje decyzje.

Projektowanie HMI i interakcji z modelem

Interfejs człowiek–maszyna w OT jest często bardziej krytyczny niż sam algorytm. Źle zaprojektowane HMI potrafi zabić nawet najlepszy model, bo operator będzie go omijał szerokim łukiem albo błędnie interpretował jego rekomendacje.

Przy projektowaniu interfejsów dla AI na linii sprawdzają się proste zasady:

• Wyraźny status modelu – czy model jest w trybie shadow, doradczym, czy automatycznym. Można to pokazać kolorami, ikonami albo krótkim opisem na ekranie głównym.
• Poziom pewności zamiast „wyroczni” – zamiast pojedynczej decyzji warto pokazać też poziom pewności lub klasy trywialnej/niepewnej sytuacji. Operator szybko uczy się, kiedy ufać modelowi, a kiedy spojrzeć dwa razy.
• Minimalizacja klikania – jeśli model wymaga wielu dodatkowych kroków od operatora, stanie się wrogiem, a nie pomocą. Dobrze, gdy interakcja z AI wpisuje się w istniejący rytm pracy, a nie go wywraca.
• Bezpieczne domyślne zachowanie – w razie wątpliwości interfejs powinien prowadzić do opcji bezpieczniejszej dla procesu, a nie „bardziej optymalnej według modelu”.

Dobrym ćwiczeniem jest przejście przez scenariusze awaryjne razem z operatorami, na prawdziwym stanowisku HMI. Już po kilku takich sesjach widać, które elementy interfejsu są niejasne albo zbyt obciążające w sytuacji stresowej.

Bezpieczeństwo i compliance dla modeli w OT

Model AI, który wpływa na proces przemysłowy, jest elementem systemu technicznego podlegającego regulacjom, normom i audytom. To oznacza, że DevOps i MLOps muszą współpracować z osobami odpowiedzialnymi za bezpieczeństwo funkcjonalne, BHP i compliance.

Najważniejsze obszary to zazwyczaj:

• Bezpieczeństwo funkcjonalne – jeżeli model ma wpływ na parametry procesu, trzeba pokazać, że nie może obniżyć poziomu bezpieczeństwa określonego w normach (np. IEC 61508, ISO 13849). Często oznacza to, że AI działa w warstwie „nad doradczej”, a twarde ograniczenia wymusza PLC lub dedykowane zabezpieczenia.
• Ścieżka audytowa – rejestrowanie decyzji modelu, wersji, na podstawie której zostały podjęte, oraz danych wejściowych. W razie incydentu technicznego lub audytu trzeba móc odtworzyć, „co myślał” model.
• Kontrola zmian – każda aktualizacja modelu czy pipeline’u powinna być objęta procedurą change management obowiązującą w zakładzie. Zmiany „po cichu” są nie do przyjęcia.
• Cyberbezpieczeństwo – komponenty AI są kolejnymi usługami, które trzeba chronić: segmentacja sieci, kontrola dostępu, aktualizacje bezpieczeństwa, skanowanie obrazów kontenerów.

Ujęcie tych wymogów w pipeline’ach CI/CD i repozytoriach konfiguracji pozwala zautomatyzować sporą część papierologii: generować raporty z testów, checklisty bezpieczeństwa, logi zmian. Dzięki temu data science nie musi za każdym razem ręcznie wypełniać tych samych formularzy, a dział bezpieczeństwa dostaje spójne, powtarzalne dane.

Automatyzacja testów w kontekście regulacji i audytów

Testy niefunkcjonalne i funkcjonalne, o których była mowa wcześniej, można zamienić w uporządkowany zestaw „dowodów” na zgodność systemu z wymaganiami. Wiele zakładów i audytorów patrzy na AI z rezerwą, ale dobrze opisany i zautomatyzowany proces testów potrafi tę rezerwę znacząco zmniejszyć.

Szczególnie przydatne są:

• Zestawy testów regresyjnych – scenariusze odtworzenia znanych awarii, problemów jakości, skoków parametrów. Każda nowa wersja modelu przechodzi te scenariusze automatycznie.
• Testy graniczne – sprawdzenie zachowania modelu przy ekstremalnych, ale możliwych wartościach sygnałów. Wyniki testów mogą być załącznikiem do dokumentacji bezpieczeństwa.
• Raporty z pipeline’ów – automatycznie generowane dokumenty zawierające wersje modeli, dane treningowe, wyniki testów, podpisane cyfrowo i archiwizowane.

W jednej z firm farmaceutycznych taki „pakiet dowodowy” z pipeline’u CI/CD stał się integralną częścią dokumentacji dla działu jakości i regulatora. Z czasem nowe wersje modelu zaczęto zatwierdzać szybciej, bo proces był przejrzysty i powtarzalny.

Skalowanie podejścia: od jednego PoC do portfolio modeli

Gdy pierwszy model na linii zacznie stabilnie pracować, pojawia się naturalna pokusa: „to może jeszcze tu, tu i tu”. Bez przygotowania łatwo skończyć z kilkunastoma PoC, które każdy działa inaczej, na innych narzędziach, z innymi procedurami.

Skalowanie sensowne z punktu widzenia OT wymaga kilku kroków:

• Wspólnych standardów – katalogu „jak robimy AI w tej fabryce”: od zbierania danych, przez naming, po schematy HMI i workflow zmian. Nie chodzi o biurokrację, tylko o zestaw dobrych praktyk, który można skopiować do kolejnych projektów.
• Platformy MLOps – nie zawsze musi to być od razu pełnowymiarowa chmura. Czasem wystarczy wspólny rejestr modeli, standardowy sposób logowania i kilka szablonów pipeline’ów dostosowanych do ograniczeń OT.
• Repozytorium wzorców – zbiór gotowych fragmentów: integracja z OPC UA, typowy serwis inference, wzór dashboardu driftu, schemat HMI. Nowe projekty zaczynają wtedy z poziomu „copy–adapt”, a nie „greenfield”.
• Zespół „AI dla OT” – mała, interdyscyplinarna grupa (DevOps, ML, OT, UR), która odpowiada za standardy, przegląd projektów i wsparcie przy trudniejszych wdrożeniach.

Takie podejście pozwala uniknąć sytuacji, w której każda linia ma „swoje własne AI”, a po roku nikt nie jest w stanie powiedzieć, co gdzie działa i w jakiej wersji.

Budowanie kultury współpracy między DevOps, MLOps i OT

Najczęściej zadawane pytania (FAQ)

Co to jest połączenie DevOps i MLOps w środowisku OT?

Połączenie DevOps i MLOps w OT oznacza zbudowanie jednego, wspólnego procesu, który obejmuje zarówno klasyczne wdrażanie oprogramowania, jak i pełny cykl życia modeli ML – ale w realiach hali produkcyjnej. Chodzi o to, żeby model nie kończył życia w Jupyter Notebooku, tylko działał stabilnie obok PLC, SCADA i systemów UR.

W praktyce wygląda to tak: DevOps odpowiada za CI/CD, wersjonowanie, monitoring i bezpieczne wdrażanie zmian na serwerach on‑prem lub urządzeniach edge. MLOps dokłada do tego zbieranie danych, trenowanie, walidację i retraining modeli. Całość musi uwzględniać ograniczenia OT: brak internetu, okna serwisowe, wymagania bezpieczeństwa i bardzo małą tolerancję na błędy.

Czym różni się DevOps, MLOps i OT w kontekście AI na hali produkcyjnej?

DevOps wywodzi się z IT – skupia się na szybkim i bezpiecznym dostarczaniu zmian w aplikacjach. MLOps koncentruje się na jakości modelu: danych, trenowaniu, monitoringu predykcji, dryfie danych. OT natomiast to świat sterowników PLC, SCADA, DCS i sieci przemysłowych, gdzie priorytetem jest ciągłość procesu, bezpieczeństwo ludzi i sprzętu oraz zgodność z normami.

Gdy wprowadzamy AI na linię produkcyjną, te trzy światy stykają się w jednym punkcie: model ML, który musi podjąć decyzję wpływającą na produkcję (np. stopień zużycia łożyska, odrzut produktu, korekta parametru receptury). Dlatego nie wystarczy znać DevOps z IT ani MLOps z chmury – trzeba je „włożyć” w ograniczenia i procedury OT.

Dlaczego samo DevOps albo samo MLOps nie wystarcza w fabryce?

Samo DevOps zapewni sprawne wdrażanie kodu, ale nie odpowie na pytania: kiedy model się zestarzał, czy dane zmieniły się na tyle, że trzeba go trenować od nowa, jak porównywać wersje modeli. Bez MLOps model szybko stanie się „czarną skrzynką”, której nikt nie kontroluje jakości.

Z kolei „czyste” MLOps, bez dyscypliny DevOps, kończy się często ręcznym kopiowaniem modeli na serwery, brakiem automatycznych testów i nieprzewidywalnymi wdrożeniami. W środowisku OT, gdzie nie można „spróbować i zobaczyć”, takie podejście jest po prostu zbyt ryzykowne.

Jakie są typowe zastosowania AI na liniach produkcyjnych wymagające DevOps + MLOps + OT?

Najczęściej spotykane scenariusze to:

• Predykcyjne utrzymanie ruchu – modele analizują sygnały z czujników (wibracje, temperatury, prądy, czasy cyklu) i prognozują awarie lub potrzebę przeglądu. Dane zwykle płyną z PLC do systemu historians/IIoT, a inference odbywa się na serwerze on‑prem lub edge.
• Kontrola jakości i wizja maszynowa – kamery weryfikują jakość produktów w ułamkach sekund. Tutaj inference musi być na edge, bo obrazy są duże, wymagane opóźnienia niskie, a dane często nie mogą opuszczać zakładu.
• Optymalizacja parametrów procesu – modele sugerują optymalne nastawy (temperatury, ciśnienia, prędkości) tak, by zmniejszyć braki albo zużycie energii, a jednocześnie nie zatrzymać produkcji.

W każdym z tych scenariuszy potrzebny jest zautomatyzowany pipeline: od zbierania danych, przez trenowanie i testy, po bezpieczne wdrażanie modeli w otoczeniu PLC i SCADA.

Jak wygląda praktyczne wdrażanie modeli AI na edge w fabryce?

Najczęściej model wraz z całym środowiskiem inference jest pakowany w kontener lub obraz systemu (np. dla przemysłowego PC albo GPU‑boxa). Taki „pakiet” można zaktualizować z centralnego repozytorium, ale samo przełączenie wersji musi być zsynchronizowane z oknami serwisowymi lub mechanizmem blue/green deployment.

W rozwiązaniach wizji maszynowej stosuje się często dwa równoległe środowiska: jedno pracuje, drugie jest aktualizowane. Po przełączeniu ruchu na nową wersję można szybko zrobić rollback, jeśli model działa gorzej lub wolniej. Całość wymaga monitoringu nie tylko jakości predykcji, ale też czasu odpowiedzi, obciążenia CPU/GPU i wpływu na takt linii.

Jak zapewnić bezpieczeństwo i ciągłość produkcji przy aktualizacji modeli AI?

Strategia jest podobna jak przy krytycznych systemach OT, tylko rozszerzona o specyfikę modeli. Kluczowe elementy to:

• formalny proces zmian (Change Management) obejmujący modele i oprogramowanie inference,
• testy FAT/SAT nowej wersji modelu na danych z danej linii, zanim trafi on na produkcję,
• mechanizmy rollbacku – szybki powrót do poprzedniej wersji modelu lub trybu „bez AI”,
• monitoring jakości predykcji i alarmy, gdy model zaczyna „odjeżdżać” (np. rośnie liczba błędnych odrzutów).

Dobrym podejściem jest też wdrażanie nowej wersji najpierw na jednej linii (canary), obserwacja wyników i dopiero potem skalowanie na cały zakład. To daje realne dane o zachowaniu modelu w warunkach produkcyjnych, a nie tylko w laboratorium.

Jakie korzyści biznesowe daje połączenie DevOps i MLOps w środowisku OT?

Z punktu widzenia zarządu i dyrektora produkcji kluczowe są cztery obszary: dostępność, przewidywalność, standaryzacja i transparentność. Oznacza to, że zmiany w modelach nie wyłączają linii, wdrożenia nie zaskakują operatorów, a kolejne zakłady korzystają z tych samych wzorców architektonicznych i narzędzi.

Dodatkowo, dzięki wersjonowaniu modeli i danych, wiadomo dokładnie, jaka wersja działa na którym urządzeniu edge, kiedy była trenowana i na jakim zbiorze. To ułatwia audyty, rozwiązywanie problemów i – co najważniejsze – pozwala skalować rozwiązania AI z poziomu „jeden fajny pilotaż” do „standardu w całej grupie produkcyjnej”.

Bibliografia

• DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press (2016) – Praktyki i kultura DevOps, CI/CD, automatyzacja wdrożeń w IT
• MLOps: Continuous Delivery and Automation Pipelines in Machine Learning. O’Reilly Media (2020) – Koncepcje MLOps, cykl życia modeli, automatyzacja trenowania i wdrożeń
• ISA‑95 Enterprise-Control System Integration. International Society of Automation – Standard integracji systemów IT i OT w przemyśle
• IEC 62443 Industrial communication networks – IT security for networks and systems. International Electrotechnical Commission – Wymagania bezpieczeństwa cybernetycznego dla systemów OT
• NIST Special Publication 800‑82: Guide to Industrial Control Systems (ICS) Security. National Institute of Standards and Technology (2015) – Charakterystyka ICS/OT, wymagania bezpieczeństwa i ciągłości pracy
• Industry 4.0: The Industrial Internet of Things. Springer (2017) – Architektury IIoT, edge, integracja systemów produkcyjnych i analityki