Migracja AVEVA w automotive. Jak wykorzystać planowany postój, żeby usprawnić cały system?

W automotive każda godzina postoju wpływa na produkcję. Dlatego migracja systemu produkcyjnego nie może sprowadzać się do prostego wyłączenia starej wersji, zainstalowania nowej i sprawdzania czy działa. W tym projekcie wykorzystaliśmy planowany postój szerzej i migracja AVEVA do nowszej wersji odbyła się sprawnie, ale przy okazji uporządkowaliśmy dane, zoptymalizowaliśmy bazy i przygotowaliśmy system na kolejne lata pracy.

Migracja to kolejny etap naszej wieloletniej współpracy. Wcześniej wdrażaliśmy u klienta m.in. system traceability, wizualizacje procesów oparte na AVEVA oraz rozwiązania integrujące produkcję z systemem ERP. Tym razem celem było przejście na nowszą, sprawdzoną wersję systemu i ujednolicenie środowiska z innymi zakładami firmy.

Chodziło nie tylko o punkt widzenia IT, ale również o cyberbezpieczeństwo, łatwiejsze utrzymanie i możliwość dalszego korzystania ze wsparcia producenta. Gdy kilka lokalizacji pracuje na podobnych wersjach systemu, aktualizacje są bardziej przewidywalne, diagnostyka szybsza, a reakcja na potencjalne podatności nie wymaga za każdym razem osobnego podejścia do każdego zakładu.

Przy takim projekcie najgorszy możliwy scenariusz to odkrywanie problemów dopiero podczas właściwego postoju. Żeby ograniczyć ryzyko podczas właściwego przepięcia, nowe środowisko przygotowaliśmy równolegle do działającej produkcji. Przenieśliśmy dane i konfigurację, a następnie przeprowadziliśmy testy na sterowniku testowym.

Sprawdzaliśmy cały przepływ informacji od maszyny, przez MES i traceability, aż po księgowanie w ERP. Dopiero kiedy ten scenariusz działał poprawnie, można było przejść do właściwego przepięcia. Stary system nie został przy tym od razu usunięty, lecz pozostał dostępny jako zabezpieczenie na wypadek konieczności powrotu do poprzedniego środowiska.

W automotive takich okazji nie ma wiele, dlatego jeśli linia już stoi, warto zrobić także te rzeczy, których normalnie nie da się przeprowadzić bez wpływu na produkcję. W ramach projektu uporządkowaliśmy więc dane, wydzieliliśmy część archiwalną i wykonaliśmy dodatkowe prace optymalizacyjne przy bazach danych.

Nie były to kosmetyczne poprawki. Przy podobnych działaniach realizowanych wcześniej u tego klienta czas odpowiedzi systemu MES dla pojedynczej części udało się skrócić nawet o około 40–50%. Aktualizacja wersji może być koniecznością, ale sam postój staje się okazją do uporządkowania rzeczy, które przez miesiące odkłada się na później.

Kiedy przyszedł czas na właściwy postój, uruchamialiśmy nowe środowisko stopniowo, maszyna po maszynie. Najpierw sprawdzaliśmy komunikację z urządzeniami, później integrację z ERP, a na końcu operatorzy wykonywali już rzeczywistą produkcję testową na maszynach. Równolegle weryfikowaliśmy, czy dane poprawnie trafiają do MES i ERP.

W ten sposób łatwiej znaleźć źródło problemu. Przy środowisku, w którym działają automatyka, sieć, MES, traceability, ERP i zabezpieczenia IT, błąd nie zawsze wystąpi tam, gdzie pojawia się jego pierwszy objaw. Zatem w czasie przepięcia równie ważna jak technologia jest dobra koordynacja między wszystkimi zespołami po stronie klienta i integratora.

Po uruchomieniu wszystkich maszyn utrzymywaliśmy przez kolejne dwa tygodnie wzmożone wsparcie. To właśnie wtedy system zaczyna działać w normalnych warunkach produkcyjnych i mogą pojawić się sytuacje, których nie da się w stu procentach odtworzyć podczas testów.

Czasem źródłem problemu jest sama aplikacja, maszyna, sieć albo zmiana wykonana równolegle przez inny zespół. Szybka diagnoza po uruchomieniu jest wtedy równie ważna jak samo przepięcie i pozwala sprawnie oddzielić problemy związane z migracją od tych, które mają inne źródło.

W takim projekcie warto patrzeć na migrację nie tylko jak na techniczną aktualizację, ale jako na jeden z etapów rozwoju całego środowiska. Jeśli decyzja o zmianie wersji przychodzi dopiero wtedy, gdy dotychczasowe rozwiązanie zbliża się do końca wsparcia, czasu na przygotowanie, testy i uzgodnienia może być znacznie mniej. W efekcie projekt, który można było spokojnie zaplanować, zaczyna być realizowany pod presją.

Dlatego znacznie lepiej przygotować migrację z wyprzedzeniem i potraktować ją jako część szerszego planu rozwoju systemu. Zyskasz wtedy czas na zbudowanie środowiska testowego, sprawdzenie całego przepływu danych, przygotowanie scenariusza powrotu i uzgodnienie działań między zespołami, zanim rozpocznie się właściwe przepięcie. Im więcej takich kwestii uda się rozwiązać wcześniej, tym mniej decyzji musisz podjąć w trakcie samego uruchomienia.

W środowisku produkcyjnym każda nieprzewidziana sytuacja może wpływać na czas powrotu do normalnej pracy. Dobrze zaplanowana migracja pozwala ograniczyć to ryzyko i jednocześnie przygotować system na kolejne lata, zamiast reagować dopiero wtedy, gdy dalsze odkładanie zmiany przestaje być możliwe.

Tego typu projekty są szczególnie istotne tam, gdzie ciągłość produkcji, szybki przepływ danych i pełna identyfikowalność procesu mają kluczowe znaczenie. Dotyczy to m.in. automotive, produkcji komponentów, przemysłu maszynowego, metalowego i innych zakładów produkcji seryjnej.

W takich środowiskach migracja AVEVA często łączy się z szerszymi potrzebami: modernizacją systemu MES, wdrożeniem traceability, integracją MES z ERP oraz zwiększeniem cyberbezpieczeństwa systemów produkcyjnych.

Jeśli przygotowujesz migrację AVEVA, modernizację MES albo integrację systemów produkcyjnych z ERP, warto zaplanować ją tak, aby nie tylko ograniczyć ryzyko podczas przepięcia, ale też jak najlepiej wykorzystać samo okno serwisowe.