Jak przekształcić diagnostykę PLC i SCADA w niezawodne utrzymanie ruchu bez zakłócania sterowania.
Sygnał już istnieje w warstwie sterowania
PLC często nadal działa, mimo że jego kondycja się pogarsza. Najpierw sprawdź historię diagnostyki, a nie ekran synoptyczny. Przerwy w komunikacji stopniowo się nasilają. Zdalny moduł I/O sygnalizuje sporadyczne usterki. W warstwie SCADA powtarzające się zaniki pojawiają się jeszcze przed zatrzymaniem produkcji. To wczesne ostrzeżenia, a nie szum. Nowoczesne sterowniki już udostępniają te dane. Nie zawsze potrzebujesz nowej sieci czujników. Trudność polega na przypisaniu każdemu sygnałowi użytecznego miejsca docelowego. Tym miejscem jest zapis konserwacji powiązany z rzeczywistym zasobem.
Krok 1 — Zbieraj rzeczywiste stany kondycji sterownika
Logika predykcyjna musi korzystać z sygnałów faktycznie obsługiwanych przez urządzenie. Nie zakładaj, że każdy PLC udostępnia te same dane o kondycji. W systemie Allen-Bradley ControlLogix (takim jak procesor Allen-Bradley ControlLogix) lub CompactLogix monitoruj liczniki błędów portów EtherNet/IP na kartach komunikacyjnych, takich jak moduł komunikacyjny 1756 ControlLogix. Śledź liczbę możliwych do usunięcia usterek dla każdej stacji zdalnej. W sterowniku Woodward dostępnym przez Modbus TCP (w systemach monitorujących z modułami I/O Woodward) odczytuj rejestry wymagające konserwacji oraz rejestry limitu żywotności. Niektóre urządzenia bezpośrednio zgłaszają usterki wewnętrzne lub nieprawidłowe napięcie zasilania.
-
Krok 1 — Wymień każdą informację diagnostyczną, którą rzeczywiście udostępnia dane urządzenie.
-
Krok 2 — Analizuj trendy liczników co tydzień, ponieważ częstotliwość lepiej ujawnia pogarszanie się stanu niż pojedyncze zdarzenie.
-
Krok 3 — Generuj alarm wyłącznie przy rosnącym trendzie lub określonym czasie trwania, a nie z powodu pojedynczego krótkiego zakłócenia.
-
Krok 4 — Powiąż każdy licznik z jednym oznaczonym zasobem, nigdy z ogólną szafą.
Krok 2 — Przestań zamieniać każdy alarm w zgłoszenie
SCADA przyciąga uwagę operatora. Utrzymanie ruchu decyduje, kto sięgnie po narzędzia. Mylenie tych ról zakopuje rzeczywiste pogarszanie się stanu pod lawiną niepotrzebnych zgłoszeń. Alarm wysokiej temperatury może po prostu oznaczać normalne zachowanie podczas produkcji. Krótki zanik może ustąpić samoczynnie. Dlatego przed utworzeniem zlecenia zweryfikuj warunek. Powtarzalność jest ważniejsza niż pojedyncze zdarzenie. Czas trwania często mówi więcej niż szczytowa wartość. Powolny dryf poniżej granicy alarmowej również może uzasadniać wizytę. Ponadto oddziel potwierdzenie od wykonania. Operator potwierdza, że usterka została zauważona. Nie dowodzi to, że urządzenie naprawiono.
-
Krok 1 — Dodaj regułę wymagającą trzech powtórzeń w ciągu siedmiu dni, aby uruchomić pracę.
-
Krok 2 — Dołącz kontekst: zasób, trend i wcześniejsze naprawy.
-
Krok 3 — Zamknij zgłoszenie dopiero po wykonaniu i zapisaniu prac.
Historia napraw zwiększa precyzję modelu
Dane z historianu pokazują, co wydarzyło się przed usterką. Historia utrzymania ruchu pokazuje, co stało się po przeprowadzeniu oględzin. Załóżmy, że błąd komunikacji wciąż generuje zgłoszenia. Technicy za każdym razem nie znajdują żadnej usterki sprzętowej. Wyzwalacz jest prawdopodobnie zbyt czuły. Jeśli jednak to samo zdarzenie zawsze kończy się wymianą jednego złącza, zaufaj temu wzorcowi. Zasługuje on na wcześniejszą uwagę. Zakończone prace pomagają oddzielić objaw od przyczyny. Pozorna usterka I/O może wynikać z utraty zasilania przez urządzenie obiektowe. Wymiana modułu naprawiłaby niewłaściwy zasób. Notatka końcowa zachowuje rzeczywistą przyczynę dla następnej zmiany.
Integruj bez zwiększania ryzyka
CMMS nie może stać się uprzywilejowanym klientem systemu sterowania. Przekazuj dane diagnostyczne przez warstwę danych. Pobieraj trendy z SCADA lub historianu. Korzystaj z tylko do odczytu OPC UA do standaryzowanych informacji o kondycji i diagnostyce. Następnie usługa integracyjna przekazuje zweryfikowane zdarzenia do platformy utrzymania ruchu za pośrednictwem API. Dzięki temu ruch związany z utrzymaniem ruchu pozostaje poza logiką krytyczną czasowo. Obliczenia predykcyjne nie muszą działać wewnątrz sterownika. Ponadto chroń sieć. Aplikacja utrzymania ruchu rzadko potrzebuje zapisu do pamięci PLC. Ogranicz ją do dostępu tylko do odczytu. Przed uruchomieniem jakiegokolwiek automatycznego połączenia z produkcją postępuj zgodnie z zakładowym procesem kontroli zmian. Na koniec zsynchronizuj zegary. Zdarzenie SCADA oznaczone czasem różniącym się o kilka minut od zapisu w CMMS utrudnia odtworzenie usterki.
Podsumowanie i zalecenia
Utrzymanie predykcyjne wymaga cierpliwości i czystego przepływu danych, a nie efektownych pulpitów. Najpierw zbieraj wyłącznie stany kondycji, które rzeczywiście udostępniają urządzenia. Następnie przed utworzeniem zgłoszenia weryfikuj warunek na podstawie powtarzalności i czasu trwania. Ponadto z czasem pozwól, aby zweryfikowana historia napraw dostrajała wyzwalacze. Nigdy jednak nie pozwalaj CMMS zapisywać danych w logice sterowania ani pomijać kontroli zmian. Dlatego zbuduj ścieżkę tylko do odczytu przez historian i OPC UA oraz zsynchronizuj czas. Na koniec traktuj samą infrastrukturę sterowania jako wyposażenie wymagające utrzymania. Zacznij w tym tygodniu od jednego krytycznego połączenia EtherNet/IP. Sprawdź cały obieg od początku do końca, zanim rozszerzysz go na cały zakład.
Autor: Sun Yifei jest inżynierem automatyki przemysłowej z ponad 10-letnim doświadczeniem w zakresie PLC, DCS i systemów sterowania.
