Jak zaprojektować system monitoringu maszyn z wykorzystaniem AI i internetu rzeczy (IoT)

Dlaczego w ogóle myśleć o monitoringu maszyn z AI i IoT?

Jakie problemy naprawdę chcesz rozwiązać?

Czy twoje maszyny psują się „nagle”, a ty i tak słyszysz od załogi, że „od tygodnia coś dziwnie chodziło”? Czy plan postoju linii produkcyjnej istnieje tylko na papierze, bo i tak rządzą go nieplanowane awarie? Jeżeli tak, monitoring maszyn z wykorzystaniem internetu rzeczy (IoT) i sztucznej inteligencji (AI) nie jest dla ciebie gadżetem, ale narzędziem do opanowania chaosu.

Typowe bóle głowy, które można adresować systemem monitoringu, to przede wszystkim:

• nagłe awarie krytycznych maszyn – szczególnie tam, gdzie nie ma redundancji, a zatrzymanie jednej maszyny blokuje cały ciąg technologiczny,
• częste mikropostoje, które nie są raportowane, ale skutecznie zjadają OEE,
• słaba widoczność stanu technicznego – decyzje serwisowe oparte bardziej na przeczuciu niż na danych,
• chaos w zarządzaniu częściami zamiennymi – zamawianie „na wszelki wypadek” albo przeciwnie, ciągłe braki i przyspieszone przesyłki.

Pytanie do ciebie: co dokładnie boli najbardziej – przestoje, koszty serwisu, czy nieprzewidywalność? Bez odpowiedzi na to pytanie bardzo łatwo zbudować system pełen danych, który nie zmieni nic w praktyce.

Różnica między ładnymi wykresami a efektem biznesowym

System monitoringu maszyn z AI i IoT potrafi generować dziesiątki paneli, wykresów, alarmów. Problem w tym, że część z nich służy bardziej do prezentacji na konferencji niż do codziennej pracy utrzymania ruchu. Kluczowy punkt wyjścia: z czym porównasz efekt tego systemu?

Najczęściej sensownymi wskaźnikami są:

• OEE – całkowita efektywność wyposażenia; jeżeli monitoring ma sens, po kilku miesiącach powinieneś zauważyć mniejszy udział nieplanowanych przestojów,
• MTBF i MTTR – średni czas między awariami i średni czas naprawy; modele predykcyjne skracają MTTR (lepsza diagnoza) i wydłużają MTBF (wcześniejsza reakcja),
• koszty części zamiennych i usług zewnętrznych – zmiana z „gaszenia pożarów” na zaplanowane działania powinna wygładzić i docelowo obniżyć te koszty,
• liczba interwencji awaryjnych – jeżeli wciąż dzwonisz po serwis w nocy, coś poszło nie tak w projekcie.

Zanim wybierzesz platformę IoT, czujniki czy modele AI, odpowiedz sobie: który z tych wskaźników chcesz ruszyć jako pierwszy? Bez tego zamiast systemu utrzymania ruchu zyskasz „centrum dowodzenia wykresami”.

Od prostego monitoringu do predykcyjnego utrzymania – po co ci AI?

Monitoring maszyn może mieć bardzo różny poziom dojrzałości. AI nie jest potrzebne wszystkim od razu. Jak to rozróżnić?

Monitoring reaktywny – masz proste sygnały: alarm temperatury, przekroczenie prądu, błąd z PLC. Reagujesz, gdy coś już jest nie tak. To poziom „zauważmy szybciej, że jest źle”.

Monitoring warunkowy (condition-based) – obserwujesz trendy: rosnącą temperaturę, zmieniające się drgania, rosnące czasy cyklu. Decyzje serwisowe podejmujesz na podstawie zmian, nie tylko przekroczeń progów. AI może pomóc w wykrywaniu subtelnych anomalii, ale wciąż dużo opiera się na ludzkiej interpretacji.

Monitoring predykcyjny (predictive maintenance) – na bazie historii danych i znanych awarii budujesz modele ML, które wskazują: „na tej maszynie ryzyko awarii łożyska w ciągu dwóch tygodni”. To już moment, w którym mówisz: „wiemy, kiedy zadziałać, zanim się zepsuje”. Tu AI jest sercem systemu.

Jeśli dopiero zaczynasz, zadaj sobie pytanie: czy najpierw potrzebujesz widzieć dane, czy już prognozować awarie? W wielu zakładach logicznym krokiem jest start od prostego monitoringu warunkowego i dopiero po kilku miesiącach przejście do modeli predykcyjnych.

Przykład małego zakładu, który zaczął od jednego silnika

W średniej wielkości zakładzie produkcyjnym kierownik utrzymania ruchu miał jeden szczególny problem: krytyczny wentylator wyciągowy w procesie, którego awaria zatrzymywała całą produkcję. Zamiast wdrażać IoT wszędzie, zespół zdecydował się na pilotaż na jednym silniku:

• zamontowano czujnik drgań i temperatury na łożyskach wentylatora,
• zastosowano proste urządzenie brzegowe zbierające dane i wysyłające je do lokalnego serwera,
• ustanowiono progi alarmowe i prosty model wykrywający nagłą zmianę charakterystyki drgań.

Po kilku miesiącach udało się złapać dwie sytuacje, w których łożysko „wstawało bokiem” i można było zaplanować wymianę w czasie postoju weekendowego. Zamiast wielkiej transformacji, zespół dostał konkretny dowód, że nawet mały, dobrze dobrany projekt potrafi wprost uniknąć poważnej awarii. Pytanie do ciebie: czy masz w swoim parku maszynowym taki „krytyczny wentylator”?

Na czym polega system monitoringu maszyn – od czujnika po decyzję?

Łańcuch wartości: od maszyny do decyzji serwisowej

Żeby nie utknąć w szczegółach technicznych, dobrze jest patrzeć na system monitoringu maszyn jak na prosty łańcuch:

maszyna → czujnik → urządzenie brzegowe (edge) → sieć → platforma danych (serwer / chmura) → model AI / algorytmy → człowiek lub system CMMS.

Co to oznacza w praktyce?

• Maszyna – fizyczne urządzenie: silnik, prasa, pompa, wentylator, linia pakująca.
• Czujnik – „oczy i uszy” systemu: zbiera informacje o drganiach, temperaturze, prądzie, ciśnieniu itd.
• Urządzenie brzegowe – mały komputer (gateway, sterownik, moduł IoT), który zczytuje dane z czujników, wstępnie je przetwarza i wysyła dalej.
• Sieć – przewodowa lub bezprzewodowa komunikacja (Ethernet, Wi-Fi, sieć przemysłowa, 4G/5G).
• Platforma danych – system, w którym dane są gromadzone, przechowywane i udostępniane (baza czasowa, broker MQTT, system SCADA z modułem danych, platforma chmurowa).
• Model AI / algorytmy – logika, która z danych wyciąga wnioski: wykrywa anomalie, trend zużycia, klasyfikuje typy usterek.
• Człowiek / CMMS – utrzymanie ruchu, planista lub system do zarządzania utrzymaniem (CMMS), który przekształca alarm w zlecenie pracy.

Pytanie kontrolne: na którym etapie tego łańcucha masz dziś największą lukę – brak danych, brak obróbki, czy brak decyzji?

Typy danych z maszyn: co ma sens w twoim przypadku?

Świat czujników daje ogromne możliwości, ale nie każde źródło danych przyniesie realną wartość. Najczęstsze typy danych w systemach monitoringu maszyn to:

• Drgania – klasyka diagnostyki łożysk, niewyważenia, niewspółosiowości. Dobre dla silników, wentylatorów, pomp, przekładni.
• Temperatura – przegrzewanie się silników, przekładni, układów hydraulicznych, elektroniki.
• Prąd / energia – przeciążenia, zablokowania ruchu, zmiany charakterystyki pracy.
• Ciśnienie i przepływ – pompy, instalacje hydrauliczne i pneumatyczne, filtry, układy chłodzenia.
• Dźwięk – detekcja nietypowych odgłosów, kawitacji, luzów; często wykorzystywany w połączeniu z AI.
• Logi PLC i SCADA – błędy, stany awaryjne, tryby pracy, zmiany nastaw, sekwencje start/stop.

Zanim zaczniesz kupować czujniki, odpowiedz na pytanie: jaką awarię chcesz wykryć wcześniej i która wielkość fizyczna „zdradza” jej nadejście? Przykładowo, zużycie łożyska będzie bardziej widoczne w sygnale drgań niż w temperaturze, która podnosi się dopiero na późnym etapie.

Monitoring online, pomiary okresowe i inspekcje ręczne

Monitoring maszyn z wykorzystaniem IoT kojarzy się z pracą online – dane spływają ciągle, a alerty są generowane w czasie zbliżonym do rzeczywistego. Nie zawsze jednak jest to konieczne. Masz kilka możliwości:

• Monitoring online – ciągłe zbieranie danych, idealne dla maszyn krytycznych, pracujących non stop, gdzie liczy się reakcja w ciągu minut lub godzin.
• Pomiary okresowe – np. raz dziennie, raz na zmianę, raz w tygodniu. Wystarczające dla urządzeń o wolno narastających uszkodzeniach.
• Inspekcje ręczne – przeglądy realizowane przez diagnostów z przenośnymi miernikami (drgań, temperatury), uzupełnione notatkami w systemie.

Pytanie: jak szybko naprawdę musisz reagować na problemy na danej maszynie? Czasem nadmiernie rozbudowany monitoring online generuje mnóstwo danych i kosztów, a wystarczyłby sensownie zorganizowany pomiar okresowy z wykorzystaniem prostych urządzeń IoT.

Po więcej kontekstu i dodatkowych materiałów możesz zerknąć na praktyczne wskazówki: informatyka.

Ostrzeżenia „wcześniej” czy lepsza diagnoza „po fakcie”?

AI w systemach monitoringu maszyn może mieć dwa główne zadania:

• wczesne ostrzeganie – wykrywanie subtelnych zmian w danych, zanim przekroczą klasyczne progi alarmowe,
• lepsza diagnoza po awarii – analiza danych z okresu przed awarią, klasyfikacja przyczyn (root cause), budowanie wiedzy na przyszłość.

Jeśli twoje awarie są rzadkie, ale bardzo kosztowne, możesz skupić się na wczesnym ostrzeganiu. Jeżeli awarie zdarzają się często, a największym problemem jest powtarzalność i brak nauki z przeszłości – lepsza analiza po fakcie (logów, trendów, sygnałów) może przynieść większy zysk na początek. Zastanów się: czy chcesz przede wszystkim zapobiegać, czy rozumieć? Oba cele są ważne, ale inaczej wpływają na projekt systemu.

Diagnoza startowa: które maszyny i procesy w ogóle monitorować?

Inwentaryzacja parku maszynowego z myślą o IoT

Zanim kupisz pierwszy czujnik, zrób ćwiczenie przy biurku i na hali. Spisz listę kluczowych maszyn i zadaj do każdej z nich kilka pytań:

• Jak krytyczna jest ta maszyna dla produkcji (czy jest obejście/redundancja)?
• Jak często ulega awariom i z jakich przyczyn?
• Jaki jest koszt przestoju tej maszyny na godzinę lub dzień (utracona produkcja, kary, nadgodziny)?
• Jak łatwo jest zapewnić dostęp fizyczny do montażu czujników (bezpieczeństwo, warunki środowiskowe)?
• Jak wygląda dostępność części zamiennych i czas ich dostawy?

To pierwsze, bardzo proste spojrzenie na priorytety. Czy już masz taką listę w formie arkusza lub w systemie CMMS? Jeśli nie – to pierwszy konkretny krok, który możesz wykonać jeszcze przed rozmową z dostawcą IoT.

Prosty scoring maszyn – tabela priorytetów

Aby zbudować logiczną kolejność wdrażania monitoringu, można zastosować prosty scoring. Przykładowa tabela może wyglądać następująco:

Możesz ten schemat uprościć do skali punktowej (np. 1–3 lub 1–5) i policzyć sumę albo wagę ważniejszych kryteriów. Pytanie do ciebie: czy potrafisz jednym zdaniem uzasadnić, dlaczego dana maszyna ma iść „na monitorowanie” jako pierwsza?

Najpierw „wąskie gardła”, dopiero potem „reszta świata”

Dobrym filtrem startowym jest proste pytanie: co zatrzyma produkcję najszybciej i na najdłużej? Tam zazwyczaj powinien wylądować pierwszy projekt IoT. W praktyce często są to:

• główne linie pakujące lub rozlewnicze (bo bez nich nie ma wysyłki),
• centralne media: sprężone powietrze, para, chłód technologiczny,
• maszyny z bardzo długim czasem rozruchu lub skomplikowanym przezbrojeniem.

Zadaj sobie jeszcze jedno pytanie: gdzie dziś najczęściej „gasicie pożary” na telefon od produkcji? To bardzo dobry kandydat do pilotażu monitoringu.

Procesy technologiczne vs. pojedyncze maszyny

Niektóre awarie nie biorą się z jednej maszyny, ale z całego łańcucha procesu. Przykład: jakość produktu spada, bo:

• temperatura medium jest za niska,
• przepływ jest niestabilny,
• czas cyklu w jednej sekcji się wydłuża.

Czy w takim przypadku monitorować każdą maszynę osobno, czy cały proces? Odpowiedź zależy od tego, gdzie chcesz podejmować decyzję:

• jeśli priorytetem jest utrzymanie jakości – skup się na parametrach procesu (temperatura, czas, przepływ, ciśnienia),
• jeśli priorytetem jest unikanie twardych awarii – wejdź głębiej w podzespoły maszyn (łożyska, przekładnie, napędy).

Dobrze jest wybrać 1–2 procesy „przekrojowe” (np. wytwarzanie medium, proces mycia CIP, linia mieszania) i zastanowić się: które trzy parametry musiałbym widzieć na ekranie, żeby spać spokojniej?

Czujniki i hardware: co wybrać, żeby nie przedobrzyć?

Minimum sensownych czujników na start

Typowy błąd wdrożeń IoT to „choinka z czujników”: wszystko mierzone, nic wykorzystane. Rozsądniejsze podejście to minimum sensownego zestawu. Co to może oznaczać w praktyce?

• Na silnikach, pompach, wentylatorach – 1–3 punkty drganiowe + temperatura obudowy.
• Na przekładniach – drgania na obudowie + temperatura oleju (albo czujnik poziomu/ciśnienia oleju).
• Na sprężarkach – ciśnienie na wejściu/wyjściu, temperatura, kilka punktów drganiowych na zespole napędowym.
• Na pompach procesowych – przepływ, ciśnienie różnicowe, sygnał prądu silnika.

Zapytaj siebie: czy wiem, jakie zjawisko chcę uchwycić tym czujnikiem? Jeżeli nie potrafisz tego nazwać (np. kawitacja, przegrzanie, niewyważenie), być może dany pomiar jest na razie „ładnym dodatkiem”, a nie koniecznością.

Czujniki przewodowe czy bezprzewodowe?

Decyzja „kabel czy radio” zależy od kilku praktycznych czynników. W skrócie:

• Przewodowe – stabilne, nie wymagają baterii, dobre do nowych instalacji lub tam, gdzie kable i tak prowadzone są w korytach kablowych.
• Bezprzewodowe – szybszy montaż, mniejsze ingerencje w instalację, ale trzeba liczyć się z bateriami, zasięgiem i zakłóceniami.

Zastanów się nad trzema pytaniami:

1. Jak długo ma działać system bez ingerencji (wymiany baterii, serwisu)?
2. Jak trudne i kosztowne jest prowadzenie nowych kabli w danym miejscu?
3. Jak krytyczne są dane w czasie – czy mierzenie co 5 minut zamiast co sekundę coś zmienia?

Dla wielu zastosowań predykcyjnych wystarczy próbkowanie okresowe (np. co 10–15 minut próbka drgań, temperatura co minutę). To otwiera drogę do tańszych czujników bezprzewodowych z dłuższą żywotnością baterii.

Klasy środowiskowe i bezpieczeństwo ATEX

Fabryka to nie biuro. Kurz, woda, wibracje konstrukcji, wysokie i niskie temperatury, strefy zagrożone wybuchem – to wszystko wpływa na wybór sprzętu. Podstawowe pytania kontrolne:

• Czy miejsce montażu wymaga IP65/IP67 lub wyżej (mycie ciśnieniowe, pył)?
• Czy masz strefy ATEX (pyły, gazy palne) i czy sprzęt musi mieć odpowiednie certyfikaty?
• Czy urządzenie będzie narażone na silne drgania mechaniczne lub udary (np. na prasie)?

Jeśli odpowiedź na któreś pytanie brzmi „tak”, w specyfikacji czujników od razu filtruj po odpowiednich klasach – inaczej pozorna oszczędność zamieni się w serię awarii samego systemu monitoringu.

Edge: małe komputery, duże decyzje

Czujniki to dopiero początek. Gdzieś pomiędzy maszyną a chmurą pojawia się urządzenie brzegowe (edge):

• zbiera sygnały z kilku–kilkudziesięciu czujników,
• wstępnie filtruje dane (np. usuwa szum, wylicza proste cechy: RMS, max, min),
• czasem uruchamia proste algorytmy AI lokalnie, bez wysyłania wszystkiego do chmury,
• komunikuje się z siecią fabryczną i/lub internetem.

Przed wyborem konkretnego hardware’u zadaj trzy pytania:

1. Jakie interfejsy potrzebujesz: analogowe (4–20 mA), cyfrowe, Modbus, Profinet, OPC UA, MQTT?
2. Czy chcesz mieć możliwość lokalnej analizy (Linux, Docker, Python) czy wystarczy prosty gateway?
3. Jak zamierzasz aktualizować oprogramowanie na tych urządzeniach (zdalnie czy ręcznie)?

Jeśli już dziś korzystasz z określonej marki sterowników PLC, rozejrzyj się, czy ten producent nie ma modułów IoT lub edge, które łatwo zintegrujesz. Czasem lepiej mieć jeden ekosystem niż dziesięć „pudełek” od różnych dostawców.

Integracja z istniejącym PLC vs. dodatkowy system

Przed tobą wybór: dokleić monitoring do istniejących sterowników, czy postawić go zupełnie obok?

• Integracja z PLC – wykorzystanie istniejących wejść, sygnałów i logiki. Mniej nowych pudełek, ale trzeba uważać, żeby nie obciążyć sterownika odpowiedzialnego za sterowanie.
• Osobny system IoT – czujniki idą do dedykowanych gatewayów, które tylko „podsłuchują” i analizują. Większa niezależność, ale więcej elementów do utrzymania.

Zapytaj automatyków: na ile komfortowo czują się z dołożeniem kolejnych zadań do obecnych PLC? Jeśli odpowiedź jest pełna obaw, bezpieczniejsze będzie odseparowanie warstwy monitoringu od sterowania procesem.

Architektura systemu IoT w fabryce: od sterownika PLC do chmury

Warstwa fizyczna, logiczna i biznesowa – trzy spojrzenia

Żeby nie zagubić się w kablach i protokołach, przydatny bywa podział architektury na trzy warstwy:

• Fizyczna – czujniki, kable, urządzenia edge, routery, switche.
• Logiczna – protokoły komunikacyjne, topic’i MQTT, modele danych, integracje z PLC/SCADA.
• Biznesowa – aplikacje, raporty, integracja z CMMS/ERP, powiadomienia, dashboardy.

Zastanów się, w której warstwie masz dziś największy chaos. Czy brakuje kabla do maszyny, czy raczej pomysłu, jak dane z tej maszyny mają wyglądać w systemie utrzymania ruchu?

Topologia: punkt–punkt czy hub–spoke?

Prosta instalacja pilotażowa często przypomina połączenia punkt–punkt: czujnik → gateway → serwer. Gdy jednak zaczynasz dodawać kolejne maszyny, potrzebujesz struktury:

• kilka–kilkanaście gatewayów zbierających dane z grup maszyn,
• jeden wspólny broker danych (np. MQTT) lub bus przemysłowy,
• centralną platformę bazodanową (lokalną lub w chmurze).

Dobra praktyka: kategoryzuj urządzenia edge według obszarów produkcji (hala 1, hala 2, linia X). Ułatwia to zarówno zarządzanie siecią, jak i późniejsze analizy – szybciej zobaczysz, że np. jedna hala ma większe problemy z jakością zasilania.

W tym miejscu przyda się jeszcze jeden praktyczny punkt odniesienia: Testy modeli w warunkach przemysłowych: drift, zmiana partii materiału i sezonowość.

Komunikacja: klasyczne protokoły automatyki czy MQTT?

W świecie IoT często pojawia się skrót MQTT – lekki protokół oparty na modelu publish–subscribe. Jak to pogodzić z istniejącymi standardami typu Modbus, Profinet czy OPC UA?

• Poziom maszyna–edge: dominują protokoły automatyki (Modbus, Profinet, Profibus, CAN), sygnały analogowe i dyskretne.
• Poziom edge–platforma danych: tutaj dobrze sprawdza się MQTT lub HTTP/REST, zwłaszcza gdy dane mają trafić do chmury.
• Integracja z SCADA/PLC: często przez OPC UA lub natywne drivery producentów.

Jeśli zaczynasz od zera, sensownym kierunkiem jest: użyć tego, co już masz na poziomie sterowania, a dopiero wyżej standaryzować komunikację (np. wszystko zasilane do chmury przez MQTT i ujednolicony schemat topiców).

Lokalnie, w chmurze czy hybrydowo?

Decyzja o miejscu przetwarzania danych bywa polityczna, ale technicznie sprowadza się do kilku pytań:

• Czy masz stabilne i bezpieczne połączenie z internetem o odpowiedniej przepustowości?
• Czy wymagania bezpieczeństwa (np. branża chemiczna, farmacja) dopuszczają wyniesienie danych do chmury publicznej?
• Czy potrzebujesz niskich opóźnień (reakcje w sekundach) czy wystarczy analiza po czasie (minuty, godziny)?

Najpraktyczniejszy w wielu zakładach bywa model hybrydowy:

• podstawowe dane i proste alarmy są dostępne lokalnie (SCADA, serwer w zakładzie),
• szersza historia i cięższe analizy AI działają w chmurze, dokąd wysyłane są dane zagregowane i zanonimizowane.

Zadaj sobie pytanie: czego się najbardziej obawiasz – braku internetu, RODO/kontrahentów, czy kosztów serwerów lokalnych? Od tego zwykle zaczyna się racjonalna rozmowa o architekturze.

Bezpieczeństwo: segmentacja sieci i dostęp zdalny

IoT kusi możliwością zdalnego podglądu maszyn z domu czy z biura centrali. Zanim jednak otworzysz bramę na szeroko, uporządkuj podstawy bezpieczeństwa:

• Segmentacja sieci – oddziel sieć produkcyjną (OT) od biurowej (IT) oraz od internetu.
• Dostęp zdalny przez VPN – żadnych otwartych portów na surowo do urządzeń edge.
• Kontrola uprawnień – kto może tylko oglądać dane, a kto ma prawo zmieniać konfigurację, progi alarmowe, firmware?

Porozmawiaj z działem IT/bezpieczeństwa: jakie są twarde zasady, których nie możesz naruszyć? Dużo lepiej dopasować się do nich od razu niż później gasić konflikt między produkcją a IT.

Dane, które mają sens: jak je zbierać, oczyszczać i opisywać?

Strumienie, serie czasowe i „zdjęcia” stanu

Dane z maszyn mogą wyglądać bardzo różnie. Żeby nie robić z tego magii, rozbij to na trzy kategorie:

• Strumienie ciągłe – np. drgania, prądy, dźwięk; dużo próbek na sekundę.
• Serie czasowe wolniejsze – temperatura, ciśnienie, przepływ mierzone co kilka sekund lub minut.
• „Zdjęcia” stanu – logi zdarzeń z PLC, statusy alarmów, informacje o zleceniach produkcyjnych.

Zapytaj siebie: które z tych danych są naprawdę potrzebne w wysokiej rozdzielczości? Być może nie musisz trzymać surowego sygnału drgań z ostatnich dwóch lat, a wystarczą wyliczone cechy (np. RMS, pasmo łożyskowe) plus fragmenty sygnału wokół podejrzanych zdarzeń.

Jak często próbkujesz – częściej nie znaczy lepiej

Spotykane często podejście „zbieramy wszystko co sekundę” kończy się szybko problemami z:

• przepustowością sieci,

Redukcja danych u źródła: agregacja, cechy, okna czasowe

Jeśli próbkujesz szybko, nie musisz wszystkiego przechowywać w oryginale. Zastanów się: która postać sygnału