Case Study: Predykcja awarii w zakładzie produkcyjnym

Kontekst projektu - realne wyzwanie, konkretne rozwiązanie

Poniższe case study przedstawia rzeczywiste wdrożenie systemu predykcyjnego utrzymania ruchu w średniej wielkości zakładzie produkcyjnym, zrealizowane przez GCAIT jako partnera wdrożeniowego. Projekt pokazuje, jak systematyczne podejście, od diagnozy przez pilotaż po skalowanie, może przynieść wymierne korzyści biznesowe.

Klient - charakterystyka zakładu

Klientem był średniej wielkości zakład produkcyjny w branży automotive, specjalizujący się w produkcji komponentów samochodowych. Zakład zatrudniał około 500 osób i osiągał obroty rzędu 200 milionów złotych rocznie. Produkcja odbywała się w trybie zmianowym - trzy zmiany, 24 godziny na dobę, 7 dni w tygodniu, co oznaczało, że maszyny pracowały praktycznie bez przerwy.

To intensywne wykorzystanie maszyn sprawiało, że każda awaria powodowała znaczące straty - nie tylko w utraconej produkcji, ale także w karach umownych za nieterminowe dostawy i potencjalnej utracie zaufania klientów.

Wyzwanie - chroniczne problemy z przestojami

Klient zmagał się z chronicznymi problemami z nieplanowanymi przestojami na linii produkcyjnej obróbki mechanicznej. Kluczowe maszyny - centra obróbcze CNC - ulegały awariom średnio 2-3 razy w miesiącu, co przekładało się na około 30-40 awarii rocznie.

Każda awaria powodowała średni przestój trwający 4-8 godzin, co przy koszcie godziny przestoju wynoszącym około 25 000 złotych oznaczało, że pojedyncza awaria kosztowała firmę od 100 000 do 200 000 złotych. W skali roku, szacunkowy koszt przestojów wynosił 1.5-2 miliony złotych, co stanowiło znaczący problem dla rentowności zakładu.

Dotychczasowa strategia prewencyjna, polegająca na przeglądach maszyn co 3 miesiące, nie była skuteczna. Awarie zdarzały się mimo regularnych przeglądów, co pokazywało, że harmonogramy przeglądów nie były dostosowane do faktycznego stanu maszyn. Co więcej, część wymienianych podczas przeglądów podzespołów była w dobrym stanie, co oznaczało marnotrawstwo zasobów - wymieniano części, które mogły pracować jeszcze długo.

Faza 1: Diagnoza - zrozumienie problemu przed rozwiązaniem

Pierwsza faza projektu trwała 4 tygodnie i miała na celu dokładne zrozumienie problemu, infrastruktury i dostępnych danych. To pozwoliło na zaprojektowanie rozwiązania dostosowanego do specyfiki zakładu i zapewnienie, że projekt będzie oparty na rzeczywistych potrzebach, a nie tylko na ogólnych założeniach.

Audyt infrastruktury - poznanie środowiska

Rozpoczęliśmy od szczegółowego audytu infrastruktury, który pozwolił zrozumieć, z jakimi maszynami i systemami mamy do czynienia. W zakładzie znajdowało się 12 centrów obróbczych CNC od różnych producentów - DMG Mori, Mazak, Fanuc - co oznaczało różnorodność technologii i protokołów komunikacyjnych.

Wiek maszyn wahał się od 3 do 15 lat, co pokazywało, że niektóre maszyny były stosunkowo nowe, podczas gdy inne były już w zaawansowanym wieku. To różnorodność wymagała indywidualnego podejścia do każdej maszyny, ponieważ starsze maszyny mogą mieć inne wzorce awarii niż nowe.

Istniejące systemy obejmowały SCADA (Siemens WinCC) do monitorowania procesów, własny system MES do zarządzania produkcją, oraz CMMS (IBM Maximo) do zarządzania utrzymaniem ruchu. To pokazywało, że zakład miał już pewną infrastrukturę cyfrową, którą można było wykorzystać.

Dostępne dane obejmowały logi maszyn z systemów SCADA, historię awarii w systemie CMMS, oraz parametry procesu w systemie MES. To było dobry punkt wyjścia, ale analiza pokazała, że dane te nie były wykorzystywane do przewidywania awarii - były tylko rejestrowane po fakcie.

Analiza historii awarii - identyfikacja wzorców

Przeanalizowaliśmy 3 lata historii awarii z systemu CMMS, co pozwoliło zidentyfikować wzorce i zrozumieć, które awarie są najczęstsze i najkosztowniejsze.

Analiza pokazała, że najczęstsze awarie dotyczyły wrzecion (35% wszystkich awarii), układów hydraulicznych (25%), sterowania (20%), oraz innych komponentów (20%). To pokazywało, że wrzeciona były największym problemem, zarówno pod względem częstotliwości, jak i kosztów.

Najkosztowniejsze były awarie wrzecion - nie tylko ze względu na częstotliwość, ale także ze względu na najdłuższy czas naprawy i drogie części zamienne. Naprawa wrzeciona wymagała często sprowadzenia specjalistów z zewnątrz i części zamiennych, co wydłużało czas przestoju.

Co ważne, analiza pokazała, że awarie wrzecion często były poprzedzone wzrostem temperatury i wibracji. To było kluczowe odkrycie - jeśli moglibyśmy wykryć te wzrosty z wyprzedzeniem, moglibyśmy przewidzieć awarie i zaplanować naprawy podczas zaplanowanych postojów, zamiast reagować na awarie w najmniej odpowiednim momencie.

Rekomendacja GC AIT - strategiczne podejście do pilotażu

Na podstawie diagnozy zarekomendowaliśmy pilotaż na 3 najstarszych maszynach z najwyższym wskaźnikiem awarii, z fokusem na monitoring wrzecion. To podejście pozwoliło na zweryfikowanie założeń na małą skalę przed podjęciem decyzji o pełnym wdrożeniu, co zmniejszało ryzyko projektu i pozwalało na dostosowanie rozwiązania do specyfiki zakładu.

Faza 2: Pilotaż - weryfikacja koncepcji w praktyce

Druga faza projektu trwała 12 tygodni i miała na celu weryfikację koncepcji na małą skalę przed podjęciem decyzji o pełnym wdrożeniu. Pilotaż pozwolił na przetestowanie rozwiązania w rzeczywistych warunkach produkcyjnych, identyfikację problemów i dostosowanie rozwiązania do specyfiki zakładu.

Instalacja czujników - budowa infrastruktury monitoringu

Na każdej z 3 maszyn pilotażowych zainstalowaliśmy kompleksowy system monitoringu, który pozwalał na ciągłe śledzenie stanu maszyn. Czujniki wibracji - 3-osiowe akcelerometry zamontowane na wrzecionie i łożyskach głównych - pozwalały na wykrywanie zmian w charakterystyce wibracji, które są często pierwszym sygnałem problemów z łożyskami czy wrzecionem.

Czujniki temperatury PT100 zamontowane na wrzecionie i w oleju hydraulicznym pozwalały na monitorowanie temperatury, która jest kluczowym wskaźnikiem stanu maszyny. Wzrost temperatury może wskazywać na problemy z chłodzeniem, zużycie łożysk czy problemy z olejem hydraulicznym.

Czujniki prądu mierzące pobór mocy silnika wrzeciona pozwalały na wykrywanie zmian w obciążeniu, które mogą wskazywać na problemy z narzędziem, materiałem czy samą maszyną. Gateway IoT agregował dane z wszystkich czujników, buforował je w przypadku problemów z komunikacją i przesyłał do systemu analitycznego.

Integracja danych - łączenie różnych źródeł

Kluczowe dla skuteczności systemu było zintegrowanie danych z wielu różnych źródeł. Nowe czujniki dostarczały dane w czasie rzeczywistym, z częstotliwością 1 pomiaru na sekundę, co pozwalało na wykrywanie szybkich zmian w stanie maszyn.

Dane ze sterowników CNC pobierane przez OPC UA zawierały parametry procesu, takie jak prędkość obrotowa, posuw, głębokość skrawania, oraz alarmy z maszyn. To pozwalało na korelację parametrów procesu ze stanem maszyny i wykrywanie wzorców prowadzących do awarii.

Historia serwisowa z systemu CMMS Maximo zawierała informacje o poprzednich naprawach, wymienionych częściach, kosztach serwisów. To pozwalało na zrozumienie historii maszyn i identyfikację wzorców awarii. Dane z systemu MES - zlecenia produkcyjne, receptury, parametry procesu - pozwalały na zrozumienie kontekstu operacyjnego i korelację między parametrami procesu a stanem maszyn.

Budowa modelu AI - od danych do przewidywań

Model predykcyjny został zbudowany przy użyciu zaawansowanych technik uczenia maszynowego. Algorytm Ensemble łączył Random Forest, który jest skuteczny w wykrywaniu wzorców w danych statycznych, z LSTM (Long Short-Term Memory), który jest specjalnie zaprojektowany do analizy szeregów czasowych i wykrywania długoterminowych trendów.

Cechy wykorzystywane przez model obejmowały RMS wibracji (średnia kwadratowa), która jest dobrym wskaźnikiem ogólnego poziomu wibracji, spektrum częstotliwości, które pozwala na identyfikację konkretnych problemów (np. problemy z łożyskami często manifestują się w określonych pasmach częstotliwości), temperaturę, oraz trendy 7/14/30 dni, które pozwalają na wykrywanie długoterminowych zmian w stanie maszyn.

Trening modelu wykorzystywał 2 lata danych historycznych z systemu CMMS oraz 6 tygodni danych real-time z nowych czujników. To połączenie danych historycznych i rzeczywistych pozwoliło na zbudowanie modelu, który rozumie zarówno długoterminowe wzorce, jak i aktualny stan maszyn.

Walidacja modelu wykorzystywała 20% danych do testów oraz cross-validation, co pozwoliło na zapewnienie, że model nie jest przeuczony i będzie działał dobrze na nowych danych.

Wyniki pilotażu - pierwsze sukcesy

W ciągu 12 tygodni pilotażu system pokazał swoją skuteczność. Trzy awarie zostały przewidziane z wyprzedzeniem 2-7 dni, co pozwoliło na zaplanowanie napraw na weekendy, gdy produkcja i tak była zatrzymana. To pokazało, że system może znacząco zmniejszyć wpływ awarii na produkcję.

Wystąpił jeden fałszywy alarm, który został wykorzystany do korekty modelu - to pokazało, że system uczy się i poprawia z czasem. Co najważniejsze, na maszynach pilotażowych nie wystąpiła żadna nieprzewidziana awaria, co pokazało, że system skutecznie wykrywa problemy z wyprzedzeniem.

Szacowane oszczędności z pilotażu wyniosły około 200 000 złotych - głównie dzięki unikniętym przestojom. To pokazało, że inwestycja w system może się szybko zwrócić.

Faza 3: Skalowanie - rozszerzenie sukcesu na cały zakład

Po udanym pilotażu, który potwierdził skuteczność rozwiązania, przystąpiliśmy do rozszerzenia systemu na wszystkie maszyny w zakładzie. Faza skalowania trwała 8 tygodni i wykorzystywała doświadczenia z pilotażu do przyspieszenia wdrożenia i zapewnienia spójności rozwiązania.

Rozszerzenie na wszystkie maszyny - wykorzystanie doświadczeń

Po udanym pilotażu zainstalowaliśmy system na pozostałych 9 maszynach. Wykorzystaliśmy doświadczenia z pilotażu do przyspieszenia wdrożenia i zapewnienia spójności rozwiązania.

Standaryzacja instalacji czujników pozwoliła na szybkie i spójne wdrożenie na wszystkich maszynach. Opracowaliśmy szczegółowe procedury instalacji, które zapewniały, że czujniki są montowane w tych samych miejscach i w ten sam sposób na wszystkich maszynach, co ułatwiało późniejszą analizę i porównywanie danych.

Szablon integracji OPC UA dla różnych sterowników pozwolił na szybką integrację z maszynami od różnych producentów. Opracowaliśmy standardowy szablon mapowania danych, który można było łatwo dostosować do specyfiki konkretnych sterowników, co znacznie przyspieszyło proces integracji.

Transfer learning - wykorzystanie modelu z pilotażu jako bazy dla nowych maszyn - pozwolił na szybkie dostosowanie modeli do nowych maszyn. Zamiast trenować modele od zera, wykorzystaliśmy wiedzę z modeli pilotażowych i dostosowaliśmy je do specyfiki nowych maszyn, co znacznie przyspieszyło proces i poprawiło jakość przewidywań.

Integracja z procesami - włączenie systemu do codziennej pracy

Kluczowe dla sukcesu projektu było włączenie systemu do codziennych procesów pracy, tak aby stał się integralną częścią operacji, a nie tylko dodatkowym narzędziem.

Integracja z systemem CMMS pozwalała na automatyczne tworzenie zleceń serwisowych przy alertach z systemu AI. To eliminowało konieczność ręcznego wprowadzania zleceń i zapewniało, że wszystkie alerty są właściwie śledzone i realizowane. Technicy otrzymywali zlecenia bezpośrednio w systemie CMMS, który już używali na co dzień.

Powiadomienia email i SMS dla techników i kierowników zapewniały, że ważne alerty są natychmiast widoczne, nawet gdy technicy nie są przy komputerze. To było szczególnie ważne w trybie zmianowym, gdy technicy mogą być w różnych miejscach zakładu.

Dashboard dostosowany do potrzeb różnych użytkowników - widok dla dyżurnego pokazujący aktualne alerty i status maszyn, widok dla kierownika utrzymania ruchu pokazujący trendy i statystyki, widok dla zarządu pokazujący kluczowe wskaźniki i ROI - zapewniał, że każdy użytkownik otrzymuje informacje odpowiednie do swoich potrzeb.

Szkolenia - przygotowanie zespołu

Kompleksowy program szkoleń zapewnił, że wszyscy użytkownicy otrzymali odpowiednie umiejętności do korzystania z systemu.

Technicy utrzymania ruchu przeszli 2-dniowe warsztaty z obsługi systemu i interpretacji alertów. Uczyli się, jak interpretować różne typy alertów, jak ocenić ich ważność, jakie działania podjąć w odpowiedzi na różne sygnały. To było kluczowe, ponieważ technicy są użytkownikami końcowymi systemu i ich umiejętności decydują o skuteczności rozwiązania.

Operatorzy przeszli 4-godzinne szkolenie z podstaw, które pozwoliło im zrozumieć, jak system działa i jak interpretować podstawowe alerty. To było ważne, ponieważ operatorzy są często pierwszymi, którzy zauważają problemy z maszynami.

Kierownictwo otrzymało prezentację dashboardów i raportów, która pozwoliła im zrozumieć, jak wykorzystywać system do podejmowania decyzji strategicznych i monitorowania efektywności utrzymania ruchu.

Wyniki po 12 miesiącach

Kluczowe metryki

Metryka	Przed	Po	Zmiana
Nieplanowane przestoje	28 rocznie	8 rocznie	-71%
MTBF (dni)	45	85	+89%
Średni czas naprawy (h)	6.2	4.1	-34%
Koszty części zamiennych	480k PLN	320k PLN	-33%
Dostępność OEE	87%	94%	+7pp

Analiza finansowa

• Inwestycja całkowita: 420 000 PLN (czujniki, integracja, licencje, szkolenia)
• Oszczędności rok 1: 980 000 PLN (przestoje + części)
• ROI: 133% w pierwszym roku
• Okres zwrotu: 5 miesięcy

Wyzwania i lekcje - co nauczyliśmy się podczas projektu

Każdy projekt wdrożenia AI przynosi cenne lekcje. Poniżej przedstawiamy główne wyzwania, z którymi się zmierzyliśmy, oraz sposoby ich rozwiązania, które mogą być pomocne dla innych projektów.

Wyzwanie 1: Jakość danych historycznych - fundament analizy

Problem polegał na tym, że historia awarii w systemie CMMS była niekompletna - nie wszystkie interwencje były rejestrowane, opisy były niejednolite, niektóre awarie były klasyfikowane jako „inne" bez szczegółów. To utrudniało budowę modeli predykcyjnych, które wymagają wysokiej jakości danych historycznych.

Rozwiązanie obejmowało warsztaty z technikami, podczas których standaryzowaliśmy klasyfikację awarii i uczyliśmy techników, jak właściwie rejestrować interwencje. Uzupełniliśmy także historię na podstawie wywiadów z doświadczonymi technikami, którzy pamiętali szczegóły poprzednich awarii. To pokazało, jak ważna jest jakość danych na początku projektu.

Wyzwanie 2: Opór techników - zarządzanie zmianą

Problem polegał na tym, że część techników postrzegała system jako „kontrolę" lub zagrożenie dla ich ekspertyzy. Obawiali się, że system zastąpi ich wiedzę i doświadczenie, lub że będzie używany do oceny ich pracy.

Rozwiązanie obejmowało włączenie techników w proces walidacji alertów - technicy byli proszeni o ocenę, czy alerty są prawidłowe i użyteczne. To pokazało, że system jest narzędziem wspierającym ich wiedzę, nie zastępującym ją. Nagradzaliśmy także techników za zgłaszanie obserwacji i feedback, co pokazało, że ich wiedza jest wartościowa i doceniana.

Wyzwanie 3: Fałszywe alarmy - równowaga między czułością a precyzją

Problem polegał na tym, że początkowe modele generowały zbyt wiele alertów, co prowadziło do „zmęczenia alarmami" - technicy zaczęli ignorować alerty, ponieważ większość z nich była fałszywa. To zmniejszało skuteczność systemu, ponieważ nawet prawdziwe alerty były ignorowane.

Rozwiązanie obejmowało dostrojenie progów alertów, wprowadzenie poziomów alertów (ostrzeżenie vs krytyczny), oraz feedback loop od techników, który pozwalał na ciągłe doskonalenie modeli. To pokazało, jak ważne jest znalezienie równowagi między czułością systemu (wykrywanie wszystkich problemów) a precyzją (tylko prawdziwe problemy).

Wyzwanie 4: Integracja ze starszymi maszynami - kompatybilność wsteczna

Problem polegał na tym, że dwie najstarsze maszyny nie miały OPC UA, tylko starszy protokół Modbus. To wymagało dodatkowej integracji, która nie była planowana na początku projektu.

Rozwiązanie obejmowało instalację gateway Modbus→OPC UA, który konwertował dane z protokołu Modbus na OPC UA, oraz mapowanie rejestrów Modbus na semantyczny model danych OPC UA. To pokazało, jak ważna jest elastyczność rozwiązania i możliwość integracji z różnymi technologiami.

Co dalej? - przyszłe możliwości

Po udanym wdrożeniu systemu predykcyjnego utrzymania ruchu, klient planuje rozszerzenie systemu na kolejne obszary, co pokazuje, jak sukces jednego projektu może otworzyć drzwi do dalszych innowacji.

Linie montażu - roboty i prasy - to kolejny obszar, gdzie system może przynieść korzyści. Roboty i prasy mają swoje specyficzne wzorce awarii, które można przewidzieć przy użyciu podobnych technik, co pozwoli na rozszerzenie korzyści na cały zakład.

Optymalizacja parametrów procesu to naturalne rozszerzenie predykcji awarii. Zamiast tylko przewidywać awarie, system może także optymalizować parametry procesu, takie jak prędkość obrotowa, posuw, temperatura, aby maksymalizować efektywność i jakość przy jednoczesnym minimalizowaniu zużycia maszyn.

Predykcja jakości - wykrywanie dryfu procesowego przed powstaniem braków - to kolejny obszar, gdzie AI może przynieść korzyści. System może wykrywać zmiany w parametrach procesu, które prowadzą do powstania braków, zanim faktycznie powstaną, co pozwala na korektę procesu w czasie rzeczywistym.

Podsumowanie - kluczowe czynniki sukcesu

Ten case study pokazuje, że predykcyjne utrzymanie ruchu to nie science fiction ani przyszłość - to sprawdzona technologia, która przynosi wymierne korzyści już teraz. Kluczowe czynniki sukcesu tego projektu mogą być zastosowane w innych wdrożeniach.

Jasne cele biznesowe - redukcja przestojów, mierzalny ROI - były fundamentem projektu. Od początku wiedzieliśmy, co chcemy osiągnąć i jak to zmierzyć, co pozwoliło na podejmowanie świadomych decyzji i ocenę sukcesu projektu.

Pilotaż przed skalowaniem - udowodnienie wartości na małej próbie - pozwoliło na zweryfikowanie założeń i dostosowanie rozwiązania przed pełnym wdrożeniem. To zmniejszyło ryzyko projektu i zwiększyło prawdopodobieństwo sukcesu.

Zaangażowanie ludzi - technicy jako partnerzy, nie ofiary zmiany - było kluczowe dla sukcesu. Technicy byli włączeni w proces od początku, ich feedback był wartościowy, a ich wiedza była doceniana. To pokazało, że system jest narzędziem wspierającym ich pracę, nie zastępującym ją.

Integracja z procesami - system wbudowany w codzienną pracę - zapewniła, że system jest rzeczywiście wykorzystywany, a nie tylko zainstalowany. Integracja z CMMS, powiadomienia, dashboardy - wszystko to sprawiło, że system stał się integralną częścią codziennej pracy.

Ciągłe doskonalenie - feedback loop, iteracyjne poprawki - pozwoliło na ciągłe ulepszanie systemu. System nie był statyczny - uczył się i poprawiał z czasem, co zwiększało jego skuteczność i zaufanie użytkowników.

Jeśli rozważasz podobne wdrożenie w swoim zakładzie - porozmawiajmy. Eksperci GC AIT pomogą Ci przejść tę samą drogę, od diagnozy przez pilotaż po skalowanie, wykorzystując doświadczenia z podobnych projektów i unikając typowych pułapek. Każdy zakład jest inny, ale podstawowe zasady sukcesu pozostają takie same.