Jak przygotować infrastrukturę OT i IT w fabryce na skalowanie rozwiązań AI

Dlaczego infrastruktura OT i IT decyduje o sukcesie AI w fabryce

OT kontra IT – dwa światy, które muszą zacząć grać razem

Technologie operacyjne (Operational Technology, OT) to cały świat sterowników PLC, systemów SCADA, DCS, sieci przemysłowych, szaf sterowniczych i maszyn. Ich główny cel: stabilnie, bezpiecznie i przewidywalnie produkować. Z kolei IT to serwery, sieci biurowe, aplikacje biznesowe, systemy ERP, MES, systemy jakości i bezpieczeństwa informacji. Ich domena: dane, integracje i użytkownicy.

AI w fabryce powstaje dokładnie na styku tych dwóch światów. Model predykcyjnego utrzymania ruchu nie zadziała bez wiarygodnych danych z czujników (OT) i bez infrastruktury, która je przyjmie, przetworzy i udostępni (IT). System wizji maszynowej potrzebuje kamer i miejsca na linii (OT), ale też mocy obliczeniowej, serwerów i narzędzi do zarządzania modelami (IT). Brak świadomej współpracy OT i IT powoduje, że inicjatywy AI kończą jako pojedyncze „wyspy” bez szans na skalowanie.

W wielu zakładach oba działy przez lata działały osobno. OT raportowało do produkcji, IT do finansów lub centrali. AI wymusza zmianę tego podziału – nie da się już podzielić odpowiedzialności na „twoje kable i moje serwery”. Pojawiają się wspólne decyzje dotyczące architektury danych, bezpieczeństwa, lokalizacji mocy obliczeniowej czy standardów integracji. Bez takiej wspólnej mapy infrastruktura zaczyna blokować rozwój AI, nawet jeśli modele są bardzo dobre.

Dlaczego wiele projektów AI zatrzymuje się na PoC

Proof of Concept (PoC) w przemyśle często udaje się uruchomić na skróty: dane eksportowane ręcznie, laptop z modelem postawiony w biurze, kamera podłączona „tymczasowo”, dostęp po VPN-ie „załatwiony na chwilę”. Na tym etapie algorytm zwykle pokazuje potencjał. Problem pojawia się, gdy trzeba:

• podłączyć więcej maszyn i linii,
• przenieść rozwiązanie z trybu „offline” do pracy w czasie zbliżonym do rzeczywistego,
• wdrożyć polityki bezpieczeństwa i dostępów zgodne z wymaganiami IT oraz cyberbezpieczeństwa OT,
• zapewnić monitoring, aktualizacje i wsparcie 24/7, a nie „jak będzie czas”.

Często okazuje się, że:

• sieć przemysłowa nie wyrabia z transmisją obrazu z kamer,
• maszyny nie mają jak wyeksportować danych w nowoczesnym protokole,
• brakuje serwerów lub edge device’ów z GPU,
• IT blokuje połączenia i dostęp do danych ze względu na brak zgodności z polityką bezpieczeństwa.

W efekcie projekt, który jako PoC dawał świetne wyniki, nie ma gdzie „fizycznie” zadziałać w produkcji. To nie wina algorytmu, tylko infrastruktury i braku przemyślanej architektury OT/IT.

Jakie zastosowania AI najmocniej obciążają infrastrukturę

Nie wszystkie projekty AI mają takie same wymagania. Jedne obciążają głównie sieć, inne pamięć masową lub GPU. Kilka typów use case’ów szczególnie mocno wpływa na wymagania dla infrastruktury OT i IT:

• Wizja maszynowa – systemy kontroli jakości oparte na obrazie. Generują strumienie danych z kamer (kilka–kilkanaście klatek na sekundę, wiele kamer na linii), wymagają niskich opóźnień i często GPU na brzegu (edge). Bez wydajnej sieci i edge computing nie ma szans na stabilną pracę.
• Predykcyjne utrzymanie ruchu – analiza danych z czujników wibracji, temperatur, prądów, logów maszyn. Mniej wymagające na poziomie pojedynczego czujnika, ale w skali całej fabryki generują duże ilości danych czasowych i wymagają solidnej architektury przechowywania (np. bazy typu time-series, hurtownie danych).
• Optymalizacja procesów w czasie zbliżonym do rzeczywistego – np. dynamiczne sterowanie parametrami pieca, mieszalnika, linii pakującej. Wymaga dobrej integracji z PLC/SCADA, niskich opóźnień oraz bardzo wysokiej dostępności, bo błędna rekomendacja może przełożyć się na straty produkcyjne.
• Optymalizacja planowania i logistyki – systemy planowania produkcji, przydziału zleceń, optymalizacji stanów magazynowych. Zwykle mniej wymagające jeśli chodzi o czas reakcji, ale integrują wiele źródeł danych (ERP, MES, WMS, dane z linii), co stawia wymagania dla integracji IT i jakości danych.

Projekty AI pracujące „blisko procesu” (wizja, sterowanie, monitorowanie w czasie rzeczywistym) mocniej obciążają warstwę OT i sieć. Projekty „decyzyjne” (planowanie, analizy, raportowanie) – przede wszystkim warstwę IT, systemy biznesowe i hurtownie danych.

Krótki przykład z wizji maszynowej, która nie ma się gdzie uruchomić

W średniej wielkości fabryce opakowań zespół R&D przygotował świetny model wizji maszynowej do wykrywania mikropęknięć. PoC działał na jednym stanowisku: kamera podłączona do wydajnego laptopa, inferencja lokalnie, wyniki zapisywane do pliku. Skuteczność – bardzo wysoka, zadowolenie – ogromne.

Kiedy przyszło do wdrożenia na linię produkcyjną, pojawiły się problemy:

• w szafie sterowniczej nie było miejsca na dodatkowy komputer z GPU,
• sieć przemysłowa nie była przygotowana na strumienie wideo z kilku kamer,
• IT nie zgodziło się na „luźny” PC przy maszynie bez centralnego zarządzania i aktualizacji,
• nie istniał standardowy sposób integracji decyzji modelu z istniejącym PLC.

Projekt utknął na etapie dyskusji, bo trzeba było „wymyślić od zera” architekturę edge computing, zasady podłączania kamer, wymagania dla sieci i sposób integracji z PLC. Gdyby wcześniej opracowano ogólną koncepcję infrastruktury OT/IT pod AI, wdrożenie kolejnych modeli wizji maszynowej byłoby znacznie prostsze i szybsze.

Punkt startu – jak ocenić gotowość obecnej infrastruktury OT/IT

Mapa krajobrazu systemów OT i IT w typowej fabryce

Przygotowanie infrastruktury pod AI zaczyna się od zrozumienia, co już istnieje. W większości zakładów produkcyjnych da się wyróżnić kilka kluczowych grup systemów:

• Warstwa OT:
  • PLC (Programmable Logic Controllers) – sterowniki linii i maszyn,
  • SCADA / DCS – systemy wizualizacji i nadzoru procesów,
  • HMI – panele operatorskie,
  • przemysłowe sieci komunikacyjne (Profinet, EtherNet/IP, Modbus TCP, Profibus, itp.),
  • czujniki, napędy, kamery przemysłowe, rejestratory danych.
• Warstwa IT produkcyjna:
  • MES (Manufacturing Execution System) – realizacja i śledzenie produkcji,
  • LIMS / systemy jakości – wyniki badań, odrzucone partie, certyfikacja,
  • systemy utrzymania ruchu (CMMS/EAM) – zlecenia serwisowe, historia awarii,
  • bazy danych, serwery aplikacyjne, lokalne data center.
• Warstwa IT biznesowa:
  • ERP – planowanie zasobów przedsiębiorstwa,
  • WMS – zarządzanie magazynem,
  • CRM, systemy finansowe, BI / hurtownie danych.

Do tego dochodzą różne integracje, często historyczne: skrypty importu/eksportu danych, pliki CSV przenoszone ręcznie, dedykowane interfejsy pomiędzy konkretnymi systemami. AI wymaga, by na tę mozaikę spojrzeć bardziej systemowo, z myślą o skalowaniu: gdzie są dane, jak przepływają, które systemy mogą stać się źródłem zasilania dla modeli, a które tylko konsumentem wyników.

Szybki audyt „AI readiness” infrastruktury

Prosty, ale uporządkowany audyt pozwala odpowiedzieć na pytanie, jak daleko infrastruktura jest od punktu, w którym da się bezboleśnie skalować AI. Pomocna może być lista kontrolna obejmująca cztery obszary: dane, sieć, moc obliczeniowa, bezpieczeństwo.

Checklista gotowości pod AI – infrastruktura OT/IT

• Dostępność danych:
  • Czy masz listę głównych źródeł danych (PLC, SCADA, MES, ERP, systemy jakości)?
  • Czy dane z maszyn są dostępne w standardowych protokołach (np. OPC UA, MQTT)?
  • Czy istnieje centralne miejsce przechowywania danych procesowych (historyk, baza time-series)?
  • Czy dane są oznaczone czasem (timestamp) i powiązane z kontekstem (zlecenie, produkt, linia)?
• Przepustowość i topologia sieci:
  • Czy sieć przemysłowa i IT są logicznie rozdzielone (strefy, VLAN-y, DMZ)?
  • Czy istnieją wolne zasoby przepustowości dla nowych strumieni danych (np. wideo z kamer)?
  • Czy w krytycznych punktach sieci jest redundancja (łącz, przełączników)?
  • Czy masz monitoring obciążenia i jakości sieci (opóźnienia, utrata pakietów)?
• Moc obliczeniowa i pamięć masowa:
  • Czy w serwerowni są zasoby (serwery, GPU, storage), które można przeznaczyć pod AI?
  • Czy istnieje infrastruktura edge (komputery przemysłowe, gateway’e) przy liniach?
  • Czy planowany jest cykl odświeżania sprzętu, który można zsynchronizować z projektami AI?
• Zasady bezpieczeństwa i dostępów:
  • Czy polityka bezpieczeństwa IT przewiduje nowe komponenty (edge, serwery AI, połączenia z chmurą)?
  • Czy istnieje proces zatwierdzania nowych integracji OT–IT z udziałem cyberbezpieczeństwa?
  • Czy zarządzanie kontami i uprawnieniami obejmuje użytkowników i usługi AI?

Taki audyt nie zastępuje formalnego assessmentu cyberbezpieczeństwa czy pełnego projektu architektury, ale pozwala szybko zidentyfikować obszary, bez których skalowanie AI będzie się ślimaczyło lub stanie w miejscu.

Identyfikacja „wąskich gardeł” infrastruktury

Następny krok to wskazanie elementów, które blokują więcej niż jeden potencjalny use case AI. Typowe wąskie gardła to:

• Brak standaryzacji danych – każda linia raportuje inne nazwy zmiennych, inne jednostki, inny format timestampu. Zespół ds. danych spędza większość czasu na „tłumaczeniu” danych między systemami zamiast na budowaniu modeli.
• Dane zamknięte w maszynach – stare PLC lub sterowniki, które nie mają nowoczesnych protokołów komunikacyjnych. Dane są, ale bez dodatkowego gateway’a lub modernizacji nie da się ich „wyciągnąć”.
• Sieci „na styk” – sieć działa poprawnie dla obecnych celów, ale nie ma rezerwy na wideo, dodatkowe sensory czy intensywną telemetrię. Dodanie kilku kamer lub strumieni danych powoduje spadki jakości i nieprzewidywalne opóźnienia.
• Polityki bezpieczeństwa blokujące eksperymenty – każda nowa integracja wymaga długiego procesu zatwierdzania, brak wydzielonego środowiska testowego dla AI, brak zdefiniowanych wzorców bezpieczeństwa dla typowych projektów.

Krytyczne jest rozróżnienie między sytuacją „to się jakoś da uruchomić” a „to da się rozsądnie skalować”. Jednorazowy mostek pomiędzy systemami, ręczny eksport CSV lub eksperymentalny VPN mogą pomóc w PoC, ale nie nadadzą się jako wzorzec dla kilkunastu linii i wielu aplikacji AI.

„Da się uruchomić” kontra „da się skalować”

System AI w trybie PoC można często porównać do tymczasowej instalacji: przedłużacze, przejściówki, ręczne przełączanie. W normalnej produkcji taki sposób działania jest nie do zaakceptowania. Skalowanie wymaga:

• powtarzalnych wzorców integracji – np. standardowy sposób podłączenia nowej linii do platformy danych, z określoną listą kroków i odpowiedzialności,
• automatyzacji – deploy modeli, zbieranie logów, monitorowanie, aktualizacje muszą dziać się półautomatycznie, inaczej zespoły się „zatkają”,
• centralnego zarządzania – zarządzanie konfiguracją, wersjami modeli i dostępami z jednego miejsca,
• przewidywalnej infrastruktury – zapasu mocy obliczeniowej, pasma sieciowego i pamięci masowej.

Dobrym testem jest pytanie: czy ten sam zespół byłby w stanie wdrożyć podobny use case na kolejnych trzech liniach w czasie krótszym niż połowa czasu pierwotnego projektu? Jeśli nie – prawdopodobnie brakuje odpowiedniej architektury i standardów infrastrukturalnych.

Dane z maszyn jako paliwo – jak ułożyć przepływy danych pod AI

Jakie dane są potrzebne pod najczęstsze zastosowania AI

AI w fabryce żyje z danych. Bez odpowiednio dobranych, opisanych i ciągłych danych z maszyn nawet najlepszy algorytm staje się bezużyteczny. Dla typowych use case’ów przydają się różne typy informacji:

Typy danych a konkretne scenariusze zastosowania

Najczęściej stosowane scenariusze AI w fabryce można powiązać z kilkoma grupami danych. Uporządkowanie ich na start ułatwia później projektowanie przepływów.

• Predykcyjne utrzymanie ruchu (predictive maintenance):
  • ciągłe pomiary procesowe: temperatura, ciśnienie, prądy silników, wibracje,
  • stany maszyn: tryb pracy, alarmy, kody błędów,
  • historia awarii i napraw: z systemów CMMS/EAM,
  • informacje o warunkach pracy: produkt, prędkość linii, zmiana.
• Optymalizacja parametrów procesu:
  • ciągłe dane z PLC i SCADA: setpointy, wartości mierzone, sygnały sterujące,
  • wyniki jakości z laboratoriów (LIMS) lub kontroli wizualnej,
  • dane o recepturach i partiach produktu z MES/ERP,
  • dane o zużyciu mediów: energia, gaz, woda.
• Wizja maszynowa i kontrola jakości:
  • strumienie wideo lub zdjęcia z kamer,
  • sygnały synchronizacyjne z PLC (np. trigger zdjęcia, identyfikator sztuki),
  • etykiety jakości: OK/NOK, kategoria wady, źródło odrzutu.
• Planowanie i logistyka wewnętrzna:
  • harmonogramy zleceń z MES i ERP,
  • stany magazynowe z WMS,
  • czasy przezbrojeń, przestojów, postoje planowane i nieplanowane,
  • przepływy materiałowe: skanery kodów, RFID, systemy śledzenia partii.

Wspólnym mianownikiem jest nie sam dostęp do danych, ale ich ciągłość, poprawne znaczniki czasu i kontekst produkcyjny – bez tego model łatwo „uczy się” błędnych zależności.

Synchronizacja czasu i kontekstu – klej dla danych pod AI

Gdy łączy się dane z wielu źródeł, najtrudniejsza bywa nie sama integracja techniczna, lecz uzgodnienie, co działo się w tym samym momencie na linii. Synchronizacja czasu staje się fundamentem.

• Spójne źródło czasu – serwery NTP lub PTP (dokładniejszy protokół czasu) ustawiają zegary w PLC, serwerach, historykach i urządzeniach edge. Brak spójnego czasu prowadzi do sytuacji, gdzie według jednego systemu awaria była „przed” zmianą receptury, a według innego – „po”.
• Normalizacja timestampów – jednolity format czasu (np. UTC), jasno zdefiniowane strefy czasowe i sposób zapisu milisekund. To drobiazg, który wielokrotnie psuł analizy offline.
• Kontekst produkcyjny – do danych czasowych trzeba dopiąć: numer zlecenia, numer partii, produkt, linię, zmianę, operatora. Często oznacza to połączenie danych z PLC/MES z danymi transakcyjnymi z ERP.

W praktyce dobrze działa prosty wzorzec: strumień danych z maszyny zawiera minimalny zestaw identyfikatorów kontekstowych (ID linii, ID produktu, ID zlecenia), które pozwalają potem połączyć go z resztą informacji w hurtowni lub platformie danych.

Standardy integracji danych z maszyn – od „kabelka” do modelu

Dane można przenosić na wiele sposobów: od ręcznego eksportu CSV po zaawansowane strumienie zdarzeń. Dla AI znaczenie ma przede wszystkim powtarzalność i łatwość skalowania.

• Protokoły OT (OPC UA, Modbus, inne fieldbusy) – często pierwszy poziom dostępu. Tu dobrze mieć:
  • standardowe szablony tagów dla podobnych maszyn lub linii,
  • zdefiniowane profile uprawnień (co można tylko czytać, co ewentualnie zapisywać),
  • ustalone interwały odczytu danych pod AI (np. co 100 ms, co 1 s).
• Gateway’e danych – urządzenia lub oprogramowanie, które:
  • zbierają dane z wielu PLC, czujników, kamer,
  • mapują tagi do jednolitego modelu informacji,
  • wysyłają dane dalej protokołami przyjaznymi dla IT (MQTT, HTTPS, AMQP).
• Architektura publish/subscribe (np. MQTT) – maszyny i urządzenia publikują dane na określone tematy, a konsumenci (historyki, modele AI, systemy monitoringu) je subskrybują. Pozwala to łatwo dołączać nowe aplikacje bez modyfikacji PLC.

Dobry standard integracji to taki, który nowy projekt AI może po prostu „dokręcić” do istniejącego systemu brokerów i topiców, zamiast za każdym razem negocjować nowe połączenia z każdą maszyną osobno.

Projektowanie strumieni danych pod różne klasy modeli

Modele AI różnie „jedzą” dane. Inaczej wygląda strumień pod wizję maszynową, a inaczej pod prognozowanie awarii łożyska. Kilka typowych wzorców:

• Strumienie wysokoczęstotliwościowe (wibracje, prądy, część sygnałów z kamer):
  • wymagają buforowania blisko źródła (edge),
  • często z nich wylicza się cechy (np. widmo częstotliwości) na brzegu, a do centrum wysyła już zagregowane dane,
  • pełny surowy sygnał przechowuje się krótko, długoterminowo tylko wybrane fragmenty.
• Strumienie niskoczęstotliwościowe (setpointy, wartości procesowe, statusy):
  • dobrze trafiają do historyków i baz typu time-series,
  • mogą być łatwo łączone z danymi z MES czy ERP,
  • są głównym paliwem dla optymalizacji procesu i prostszego predictive maintenance.
• Dane zdarzeniowe (awarie, przezbrojenia, start/stop linii):
  • z natury nieregularne,
  • ważne jako znaczniki w strumieniach czasowych: model rozumie, co działo się „przed awarią” czy „podczas rozruchu”,
  • często pochodzą z kilku systemów naraz (PLC, SCADA, CMMS).

Projektując architekturę danych, dobrze jest na wczesnym etapie rozrysować, które modele będą działały na danych „tu i teraz” (online), a które offline, na historycznych danych w hurtowni. Od tego zależy wybór technologii przechowywania i przesyłania danych.

Minimalna „platforma danych” w fabryce – co musi się w niej znaleźć

Wielu producentów boi się słowa „platforma”, bo kojarzy się z wieloletnim, kosztownym projektem IT. W praktyce w fabryce często wystarcza rozsądne minimum, ale przygotowane z myślą o rozbudowie.

• Historyk procesowy / baza time-series – centralne miejsce na dane z maszyn:
  • ujednolicone nazwy tagów i jednostek,
  • spójne znaczniki czasu,
  • API lub konektory dla zespołów data science i narzędzi analitycznych.
• Repozytorium plików i obrazów – dla wizji maszynowej:
  • przemyślany sposób nadawania nazw plikom (ID linii, timestamp, wynik klasyfikacji),
  • metadane z kontekstem produkcyjnym w bazie towarzyszącej,
  • mechanizmy retencji: co, kiedy i jak długo trzymać.
• Warstwa integracji z systemami biznesowymi – czy to w postaci ESB (Enterprise Service Bus), czy prostszych API:
  • standardowe interfejsy do MES, ERP, WMS, CMMS,
  • możliwość czytania i zapisywania statusów zleceń, partii, zasobów.
• Warstwa udostępniania danych pod AI:
  • dostęp programistyczny (API, konektory do notebooków, narzędzi ML),
  • kontrola dostępu na poziomie zbiorów danych (kto może widzieć jakie linie, jakie zmienne),
  • logowanie zapytań i użycia (przydatne przy skalowaniu i rozliczeniach kosztów).

Takie „minimum” może powstać etapami, równolegle z pierwszymi pilotażami AI, ale z jasnym założeniem, że kolejne projekty będą go używać zamiast budować własne, równoległe kanały danych.

Architektura – od pilota do skalowalnej platformy AI w fabryce

Ewolucja typowego projektu: od laptopa data scientista do platformy

W wielu zakładach pierwsze modele powstają w dość prostym środowisku: dane zgrane ręcznie do plików, analiza na laptopie lub jednorazowym serwerze, ręczne wdrożenie w jednym miejscu. To naturalny etap, ale nie nadaje się jako wzorzec.

Żeby przejść od jednorazowych rozwiązań do platformy, zwykle zachodzi kilka zmian:

• Automatyzacja pobierania danych – koniec z ręcznym eksportem CSV, dane z historyków i systemów trafiają do modeli przez stałe, opisane konektory.
• Standaryzacja środowisk – te same kontenery, biblioteki, wersje frameworków ML w testach i na produkcji. Znika sytuacja „u mnie działa, na serwerze już nie”.
• Wdrożenie mechanizmów MLOps – monitorowanie jakości modeli, automatyczne ponowne trenowanie, wersjonowanie modeli i danych.

Zmiana nie musi być rewolucyjna – często wystarczy, że drugi i trzeci projekt wykorzystają te same klocki: broker wiadomości, serwer funkcji, magazyn modeli.

Kluczowe komponenty platformy AI w fabryce

Platforma AI nie jest jednym produktem. To zestaw współpracujących elementów, z których część może być już w zakładzie, tylko używana do innych celów.

• Warstwa orkiestracji kontenerów (np. Kubernetes on-premise lub zarządzany w chmurze):
  • pozwala uruchamiać modele w formie usług (mikroserwisów),
  • ułatwia skalowanie – dodanie kolejnej instancji modelu to kwestia konfiguracji, nie nowego serwera,
  • umożliwia centralne logowanie i monitoring.
• Repozytorium modeli (model registry):
  • przechowuje wersje modeli wraz z opisem danych treningowych,
  • pozwala śledzić, który model jest wdrożony na której linii,
  • ułatwia cofnięcie zmian, gdy nowa wersja modelu spisuje się gorzej.
• Pipeline’y danych i trenowania:
  • zautomatyzowane przepływy: zbieranie danych, przygotowanie, trenowanie, walidacja,
  • możliwość okresowego trenowania modeli na świeżych danych bez ręcznej pracy data scientistów.
• Warstwa interfejsów do OT:
  • zestaw standaryzowanych modułów integracyjnych: do OPC UA, MQTT, SCADA, MES,
  • jasne API do wywoływania decyzji modeli z poziomu PLC czy aplikacji operatorskich.

W wielu projektach dobrą praktyką jest potraktowanie każdego modelu jako usługi: przyjmuje dane wejściowe (np. pomiary z kilku sekund), zwraca rekomendację lub klasyfikację, a reszta systemu decyduje, co z tym zrobić.

Wzorce integracji decyzji AI z procesem produkcyjnym

Sam model to dopiero połowa sukcesu. Trzeba jeszcze podłączyć jego wynik z powrotem do procesu tak, aby dawał korzyść, a jednocześnie nie naruszał bezpieczeństwa i spójności produkcji.

• Tryb doradczy (advisory):
  • model generuje rekomendację dla operatora,
  • decyzja wykonawcza pozostaje po stronie człowieka,
  • prostsze od strony bezpieczeństwa – AI nie ingeruje bezpośrednio w sterowanie.
• Tryb półautomatyczny:
  • AI proponuje zmianę parametru (np. setpointu),
  • SCADA/PLC wdraża ją automatycznie, ale w ściśle ograniczonym zakresie (limity parametrów, warunki bezpieczeństwa),
  • operator ma możliwość wstrzymania lub cofnięcia zmian.
• Tryb automatyczny:
  • model działa jako element pętli sterowania,
  • wymaga formalnych analiz bezpieczeństwa funkcjonalnego i procedur walidacji,
  • stosowany raczej w dojrzałych środowiskach z dobrze kontrolowaną infrastrukturą.

Już na etapie architektury platformy warto zdefiniować, które modele mogą działać w którym trybie oraz jakie są standardowe ścieżki integracji z PLC (np. poprzez dedykowane bloki funkcyjne, serwery OPC UA, REST API w warstwie pośredniej).

Projektowanie pod wielokrotne użycie – jeden model, wiele linii

Największe zyski z AI pojawiają się wtedy, gdy ten sam pomysł można skopiować na kilka linii, wydziałów czy zakładów. Żeby to było realne, już pierwsze wdrożenia muszą być projektowane jak „produkty”, a nie jednorazowe eksperymenty.

• Parametryzacja, nie twarde zakodowanie:
  • różnice między liniami (zakresy pracy, typ produktu, nazwy tagów) powinny być opisane w konfiguracji,
  • ten sam obraz kontenera modelu działa wtedy w wielu miejscach, a lokalne różnice są „wczytywane” z configu.
• Profile linii i maszyn:
  • dla każdej linii powstaje profil: zestaw zmiennych, częstotliwości próbkowania, istotne zdarzenia,
  • modele korzystają z profilu zamiast z „twardych” nazw tagów zakodowanych w skrypcie.
• Wspólne moduły funkcjonalne:
  • detekcja anomalii, prognoza trendu, klasyfikacja jakości mogą być tymi samymi komponentami,
  • różni się tylko „nakładka” domenowa – czyli z jakich zmiennych korzystają i jak interpretują wynik.

W praktyce bardzo pomaga katalog projektów AI: krótki opis, z jakich klocków i danych korzystają, na ilu liniach działają. Dzięki temu kolejne zespoły nie zaczynają od zera, tylko adaptują istniejące rozwiązania.

Standardy wdrożeniowe – jak uniknąć „zoo technologicznego”

Gdy w fabryce ruszy kilka pilotaży AI naraz, bardzo łatwo o chaos: każdy dostawca proponuje własny stos technologiczny, własne serwery, własne mechanizmy integracji. Bez minimalnych standardów po dwóch latach utrzymanie tego staje się koszmarem.

Przydaje się krótka, ale czytelna „książeczka standardów” uzgodniona między OT, IT i biznesem. Zwykle obejmuje ona:

• Preferowane protokoły integracji:
  • w warstwie OT: OPC UA, MQTT, czasem Modbus jako „last resort”,
  • w warstwie IT: REST/HTTP, gRPC lub wiadomości na brokerze (np. Kafka, MQTT).
• Standardy bezpieczeństwa:
  • jak uwierzytelniają się usługi (np. certyfikaty, tokeny),
  • kto może wołać model z poziomu SCADA/PLC i w jakim trybie.
• Standardy wdrażania:
  • modele jako kontenery, nie „gołe” skrypty na serwerze,
  • opisany proces: środowisko testowe → pilotaż → produkcja.

Taki zestaw zasad nie blokuje innowacji, ale sprawia, że każdy nowy projekt naturalnie dokłada się do wspólnej platformy zamiast ją obchodzić.

Edge, serwerownia czy chmura? Dobór mocy obliczeniowej pod AI w fabryce

Jakie obciążenia generują modele AI w produkcji

Zanim zapadnie decyzja „gdzie postawić AI”, trzeba z grubsza zrozumieć, jakie typy obliczeń będą dominować. W fabryce najczęściej pojawiają się trzy scenariusze:

• Wnioskowanie w czasie rzeczywistym (online inference):
  • modele reagujące na bieżące dane z maszyn: np. klasyfikacja wizyjna, szybka detekcja anomalii,
  • wymagają niskich opóźnień i przewidywalnego czasu odpowiedzi.
• Przetwarzanie wsadowe (batch):
  • okresowe analizy całych zmian, partii, tygodni produkcji,
  • mogą działać w nocy lub poza szczytem, bardziej liczy się koszt niż milisekundy opóźnienia.
• Trenowanie i ponowne trenowanie modeli:
  • intensywne obliczeniowo, ale możliwe do zaplanowania,
  • dobrze „czują się” w środowiskach z elastyczną mocą obliczeniową (wirtualne serwery, chmura).

W praktyce często kończy się kombinacją: szybkie decyzje blisko maszyn, ciężkie przeliczenia w centralnym środowisku, a trening tam, gdzie chwilowo jest dostępna moc GPU lub CPU.

Kiedy postawić na edge – AI na hali produkcyjnej

Edge computing, czyli „brzeg” sieci, to serwery lub urządzenia obliczeniowe stojące fizycznie blisko maszyn. Niektóre algorytmy po prostu muszą działać właśnie tam.

Typowe powody, żeby przenieść AI na edge:

• Wymagania czasowe:
  • sterowanie procesem w czasie rzeczywistym, gdzie opóźnienie rzędu milisekund ma znaczenie,
  • wizja maszynowa z kamer przy liniach szybkobieżnych – przesyłanie pełnego wideo do chmury byłoby za wolne i za drogie.
• Ograniczenia sieciowe:
  • linie w oddalonych lokalizacjach, ze słabym łączem do centrum lub internetu,
  • koszt transmisji wysokoczęstotliwościowych danych (np. z wielu kamer) jest nieakceptowalny.
• Wymogi bezpieczeństwa i regulacyjne:
  • dane nie mogą opuszczać strefy produkcyjnej lub kraju,
  • konieczność działania nawet przy odcięciu od reszty sieci.

Edge to jednak nie tylko „mały serwer w szafie”. To cały ekosystem: system operacyjny, kontenery, aktualizacje, monitoring. Najpraktyczniej traktować edge jak rozszerzenie fabrycznej platformy, a nie coś zupełnie innego.

Jak zorganizować „mini-platformę” AI na edge

Żeby edge nie zamienił się w zestaw niezarządzanych „pudełek”, przydaje się prosty, ale konsekwentny zestaw zasad:

• Standaryzowany sprzęt:
  • kilka typów urządzeń (np. z GPU do wizji, bez GPU do prostszych modeli),
  • szafy i zasilanie dostosowane do warunków hali (temperatura, kurz, wibracje).
• Ujednolicone środowisko uruchomieniowe:
  • kontenery (Docker/Podman) jako podstawowy sposób wdrażania modeli,
  • lekkie systemy orkiestracji edge, które integrują się z centralnym Kubernetesem.
• Zarządzanie z centrum:
  • aktualizacje modeli i konfiguracji pchane z centralnego repozytorium,
  • monitoring zdrowia edge: wykorzystanie CPU/GPU, temperatura, dostępność.

Dobrym wzorcem jest „podwójne wdrożenie”: nowa wersja modelu pracuje równolegle z dotychczasową (tzw. shadow mode), a ich wyniki są porównywane, zanim operatorzy przełączą się w tryb produkcyjny.

Rola centralnej serwerowni – „mózg” fabryki

Zakładowa serwerownia lub regionalne centrum danych to naturalne miejsce na wiele komponentów platformy AI. Tu zwykle ląduje orkiestracja kontenerów, historyki procesowe, hurtownie danych i systemy biznesowe.

Centralna serwerownia dobrze sprawdza się w kilku rolach:

• Warstwa integracyjna:
  • łączenie danych z wielu linii i wydziałów,
  • udostępnianie ich zespołom analizującym całą fabrykę.
• Środowisko uruchomieniowe dla modeli o średnim zapotrzebowaniu na moc:
  • modele przyjmujące dane z wielu punktów, ale bez wymogu milisekundowych opóźnień,
  • praktyczne dla aplikacji typu: prognoza awarii w horyzoncie godzin/dni, optymalizacja planowania.
• Bezpieczne „zaplecze” dla OT:
  • możliwość segmentacji sieci – OT ma kontrolowany, filtrowany dostęp do usług AI,
  • łatwiejsze wdrażanie mechanizmów bezpieczeństwa IT (backupy, antywirus, logowanie).

Dzięki centralizacji łatwiej też policzyć koszty: wiadomo, ile zasobów pochłaniają poszczególne projekty, które modele generują największy ruch, a które prawie nie są używane.

Kiedy chmura ma sens w środowisku przemysłowym

Wielu producentów podchodzi do chmury z rezerwą, głównie z powodu bezpieczeństwa i opóźnień. W dobrze zaprojektowanej architekturze chmura wcale nie musi widzieć sterowników i nie ingeruje bezpośrednio w sterowanie.

Chmura sprawdza się szczególnie w trzech obszarach:

• Trenowanie modeli i prace eksperymentalne:
  • szybki dostęp do dużej mocy obliczeniowej (GPU/CPU) na czas trenowania,
  • możliwość równoległego testowania wielu wariantów modelu bez inwestycji w lokalny sprzęt.
• Analizy przekrojowe dla wielu zakładów:
  • porównywanie wydajności linii z różnych fabryk,
  • centralne modele, które „uczą się” na danych z całej grupy kapitałowej.
• Usługi wspierające:
  • zarządzanie modelami (MLOps), które łączy się z on-prem tylko przez kontrolowane interfejsy,
  • backup i archiwizacja danych mniej wrażliwych.

Kluczowe jest rozdzielenie: modele trenują w chmurze, ale wnioskują blisko procesu (edge lub serwerownia). Do chmury mogą trafiać dane zanonimizowane, zagregowane lub opóźnione, co ogranicza ryzyka.

Architektura hybrydowa – jak połączyć edge, centrum i chmurę

Większość nowoczesnych fabryk kończy z rozwiązaniem hybrydowym. Poszczególne warstwy pełnią różne funkcje, ale są spięte wspólnymi standardami.

Prosty schemat, który często się sprawdza:

• Warstwa 1 – OT i edge:
  • sterowniki, SCADA i lokalne bramki IoT,
  • modele wymagające szybkiej reakcji, działające bezpośrednio przy maszynach.
• Warstwa 2 – serwerownia zakładowa lub regionalna:
  • klaster kontenerów, historyki, integracje z MES/ERP,
  • modele łączące dane z wielu linii, raportowanie dla zakładu.
• Warstwa 3 – chmura:
  • trening modeli, eksperymenty, analizy międzyzakładowe,
  • centralne repozytorium modeli i pipeline’ów, zarządzanie politykami.

Komunikacja między warstwami powinna być jak najprostsza i dobrze udokumentowana. Częsty wzorzec to broker wiadomości lub API w warstwie 2, które „tłumaczy” świat OT na świat IT/chmury i odwrotnie.

Bezpieczeństwo i niezawodność w hybrydowej infrastrukturze AI

Każda dodatkowa warstwa zwiększa złożoność. Bez spójnego podejścia do bezpieczeństwa łatwo stworzyć dziurawe połączenia między OT, IT i chmurą.

Kilka praktyk, które pomagają utrzymać porządek:

• Segmentacja sieci:
  • jasne rozdzielenie stref: OT, DMZ (strefa buforowa), IT, chmura,
  • modele AI w trybie doradczym często mogą pracować w strefie IT, bez dostępu bezpośrednio do PLC.
• „Fail-safe” w integracji z procesem:
  • gdy model nie odpowiada, proces ma przejść do bezpiecznego stanu (np. powrót do ustalonych ręcznie nastaw),
  • PLC powinien mieć logikę awaryjną niezależną od dostępności usług AI.
• Zarządzanie tożsamością i uprawnieniami:
  • każdy komponent (model, aplikacja, użytkownik) identyfikuje się i ma przypisane role,
  • logowanie, kto i kiedy korzystał z modeli oraz jakie decyzje zostały wdrożone.

Dobrą praktyką jest „ćwiczenie awarii”: symulacja braku łączności z chmurą, utraty jednego serwera edge czy restartu klastra. Lepiej odkryć luki w kontrolowanych warunkach niż podczas realnej usterki.

Planowanie rozwoju mocy obliczeniowej – jak nie przepłacić

AI potrafi apetyt na zasoby mieć ogromny, ale nie każda linia musi od razu dostać własny serwer z GPU. Sensowniejsze jest podejście etapowe, oparte na mierzonych potrzebach.

Najczęściej zadawane pytania (FAQ)

Od czego zacząć przygotowanie infrastruktury OT i IT pod projekty AI w fabryce?

Punkt startowy to inwentaryzacja tego, co już działa: sterowników, systemów SCADA/MES/ERP, sieci, serwerów, sposobów zbierania danych z maszyn. Bez takiej mapy bardzo łatwo zaplanować rozwiązanie, którego fizycznie nie da się wpiąć w obecne środowisko.

Drugi krok to szybki audyt „AI readiness” w czterech obszarach: dane (czy w ogóle je zbierasz i w jakiej formie), sieć (przepustowość i segmentacja), moc obliczeniowa (serwery, edge, GPU) oraz bezpieczeństwo (polityki IT, cyberbezpieczeństwo OT). Na tej podstawie powstaje pierwsza, prosta koncepcja architektury, którą można później rozwijać wraz z kolejnymi use case’ami AI.

Jak pogodzić wymagania działu OT i IT przy wdrażaniu AI na produkcji?

Kluczowe jest wyjście z logiki „moje–twoje” i potraktowanie AI jako wspólnego projektu biznesowego, a nie eksperymentu jednego działu. Pomaga powołanie małego zespołu OT+IT, który ma jasny mandat do podejmowania decyzji dotyczących architektury danych, lokalizacji mocy obliczeniowej, standardów komunikacji i zasad bezpieczeństwa.

Praktycznie sprawdza się: wspólna mapa systemów, wspólne standardy (np. „wszędzie, gdzie się da – OPC UA, MQTT”), uzgodniony katalog typowych rozwiązań (np. jak podłączamy kamery, jakie edge boxy są dopuszczone, jak integrujemy się z PLC). Dzięki temu każda kolejna aplikacja AI korzysta z tych samych klocków, zamiast za każdym razem „odkrywać Amerykę na nowo”.

Dlaczego tyle projektów AI w fabrykach zatrzymuje się na etapie PoC?

PoC można postawić „na skróty”: dane z CSV, model na laptopie, prowizoryczna kamera, dostęp na hasło „na chwilę”. Taki eksperyment pokazuje potencjał, ale zwykle nie bierze pod uwagę realnych ograniczeń sieci, szaf sterowniczych, polityk bezpieczeństwa IT ani tego, kto będzie to utrzymywał 24/7.

Schody zaczynają się, gdy trzeba: podłączyć wiele linii, przejść na pracę ciągłą, zapewnić niskie opóźnienia, zgodność z cyberbezpieczeństwem OT i procedurami ITSM. Wtedy wychodzi na jaw brak miejsca na edge, zbyt słaba sieć, brak standardu integracji z PLC czy brak serwerów z GPU. To nie jest problem AI jako takiej, tylko infrastruktury, która nie była planowana z myślą o skalowaniu.

Jakie zastosowania AI najbardziej obciążają infrastrukturę w fabryce?

Najbardziej wymagająca jest AI „blisko procesu”, czyli wszystko, co działa niemal w czasie rzeczywistym: wizja maszynowa, sterowanie parametrami procesu, monitorowanie wibracji czy temperatur pod kątem natychmiastowych alarmów. Takie scenariusze mocno obciążają warstwę OT, sieć przemysłową oraz warstwę edge (lokalne komputery, często z GPU).

Use case’y „decyzyjne” – jak optymalizacja planowania, harmonogramowanie zleceń, prognozowanie zużycia materiałów – bardziej wykorzystują systemy IT: ERP, MES, WMS, hurtownie danych i serwery analityczne. Wymagają dobrej jakości danych i integracji wielu systemów, ale zwykle nie potrzebują reakcji w ułamkach sekund.

Jak ocenić, czy obecna sieć i systemy OT/IT są przygotowane na wizję maszynową?

Najpierw warto policzyć skalę: ile kamer, jaka rozdzielczość, ile klatek na sekundę, czy obraz ma być przetwarzany lokalnie, czy przesyłany do centrum. Na tej podstawie można oszacować wymagania przepustowości sieci oraz potrzebę GPU w urządzeniach edge bezpośrednio przy linii.

Przydatna jest też lista pytań kontrolnych: czy sieć przemysłowa obsłuży strumienie wideo z wielu kamer, czy są dostępne zasilane PoE porty, czy w szafach sterowniczych jest miejsce na edge box z GPU, jak IT podchodzi do zarządzania i aktualizacji takiego sprzętu oraz czy istnieje standard integracji wyniku modelu z PLC (np. przez OPC UA lub dedykowane bloki funkcyjne).

Co to jest „edge computing” w kontekście AI w fabryce i kiedy jest potrzebny?

Edge computing to uruchamianie modeli AI blisko maszyn – na przemysłowych komputerach, sterownikach lub wyspecjalizowanych urządzeniach przy linii, zamiast w chmurze czy centralnym serwerowni. Dzięki temu decyzje (np. akceptacja/odrzut detalu z kamery) zapadają z minimalnym opóźnieniem, nawet gdy łącze do centrum jest przeciążone lub chwilowo niedostępne.

Edge jest potrzebny przede wszystkim tam, gdzie liczy się czas reakcji (milisekundy/sekundy) albo gdy nie ma sensu przesyłać całych strumieni danych (np. wideo) do centrum. W praktyce systemy wizji, szybkie alarmy procesowe i sterowanie parametrami linii to naturalni kandydaci na AI na brzegu, podczas gdy analizy historyczne czy planistyczne spokojnie mogą działać w data center lub chmurze.

Jak przygotować dane z maszyn, aby nadawały się do trenowania i wdrażania modeli AI?

Najważniejsze jest, aby dane były w ogóle zbierane, poprawnie otagowane (co z której maszyny i linii) oraz zsynchronizowane w czasie. Dobrą praktyką jest centralny historyk danych procesowych lub baza typu time-series, do której trafiają dane z PLC/SCADA w możliwie standardowych protokołach (np. OPC UA, MQTT).

Drugi element to ich „otwartość” na integrację: jasno zdefiniowane interfejsy do odczytu (API, konektory), opis metadanych oraz powiązanie z danymi biznesowymi (MES, ERP, jakość). Przykład z praktyki: dane wibracyjne z czujników mają większą wartość, gdy można je łatwo połączyć z informacją o numerze zlecenia, partii i historii awarii z systemu CMMS – wtedy model predykcyjnego utrzymania ruchu ma szansę nauczyć się czegoś sensownego.

Kluczowe Wnioski

• Skuteczne AI w fabryce powstaje na styku OT i IT – bez stabilnych danych z maszyn (OT) i wydajnej infrastruktury do ich przetworzenia (IT) nawet najlepszy model pozostaje tylko ciekawostką z laboratoriów.
• Brak współpracy działów OT i IT powoduje, że projekty kończą jako pojedyncze „wyspy” PoC, których nie da się skalować ani utrzymywać w trybie 24/7 na realnej produkcji.
• Niedostosowana infrastruktura (sieć, protokoły, brak edge z GPU, ograniczenia bezpieczeństwa IT/OT) jest jedną z głównych przyczyn, dla których udane PoC nie przechodzą do etapu stabilnego wdrożenia.
• Różne typy zastosowań AI obciążają inne elementy infrastruktury: wizja maszynowa i sterowanie w czasie zbliżonym do rzeczywistego „duszą” głównie warstwę OT i sieć, natomiast analityka, planowanie i logistyka – systemy IT oraz hurtownie danych.
• Use case’y „blisko procesu” (np. kontrola jakości na kamerach, optymalizacja parametrów linii) wymagają niskich opóźnień, edge computingu i ścisłej integracji z PLC/SCADA, bo nawet drobne opóźnienie może przełożyć się na złe decyzje w sterowaniu.
• Przykład z wizją maszynową pokazuje, że bez wcześniej zdefiniowanej architektury OT/IT pod AI (miejsca na sprzęt, zasady podłączania kamer, wymagania sieci, standardy integracji z PLC) każdy nowy projekt trzeba „wynajdować od zera”, co blokuje wdrożenia.