Przewodnik aktualizacji oprogramowania sprzętowego 1756-L73: decyzja między wersją v19 a v21/v31

Wymiana uszkodzonego sterownika 1756-L73 i modernizacja jego oprogramowania układowego to dwa różne zadania inżynieryjne. Awaryjna wymiana ma na celu przywrócenie znanej aplikacji przy możliwie najmniejszym zakresie zmian. Migracja zmienia wersję sterownika, format projektu, narzędzia inżynieryjne, a potencjalnie także działanie lub status wsparcia podłączonych komponentów. Łączenie tych zadań podczas nieplanowanego przestoju zwiększa ryzyko dokładnie wtedy, gdy zakład ma najmniej czasu na zarządzanie nim.

Decyzję należy zacząć od celu utrzymania ruchu, a nie od porównania trzech numerów wersji oprogramowania układowego. Należy potwierdzić katalog i serię zainstalowanego sterownika, bieżącą wersję oprogramowania układowego, wersję projektu, dostępne oprogramowanie inżynieryjne, zweryfikowaną kopię zapasową, moduły chassis, sieci, ścieżkę HMI lub OPC, układy ruchu, napędy, tagi produkowane i konsumowane oraz instrukcje komunikatów. Oprogramowanie układowe jest tylko jedną z zależności w tym systemie.

Wymieniany sterownik musi pasować do projektu i otaczającej architektury, a nie tylko do numeru katalogowego wydrukowanego na jego obudowie.

Najpierw określ zakres, a dopiero potem wybierz wersję

Awaryjne przywrócenie działania

Gdy stabilnie działający sterownik produkcyjny ulegnie awarii, przywrócenie tej samej głównej wersji oprogramowania układowego i zgodnej wersji projektu jest zwykle rozwiązaniem wymagającym najmniejszej liczby zmian. Pozwala uniknąć konwersji aplikacji podczas usuwania awarii i zachowuje znane zależności między sterownikiem, HMI, komunikacją oraz zainstalowanymi modułami. „Ta sama wersja” nadal wymaga weryfikacji: należy potwierdzić, że dokładny pakiet oprogramowania układowego obsługuje identyfikator sterownika oraz że oryginalny projekt otwiera się w dostępnym oprogramowaniu.

Planowana migracja oprogramowania układowego

Planowana migracja może rozwiązać kwestie cyklu życia stacji inżynieryjnej, udokumentowanych anomalii istotnych dla aplikacji, zasad wsparcia, standaryzacji lub potrzeb związanych z odzyskiwaniem projektu. Wymaga pakietu zmian, przeglądu zgodności, planu przestoju, testów akceptacyjnych oraz zasobów do wycofania zmian. Sterownik, który pomyślnie przeszedł aktualizację, nie potwierdził jeszcze, że system sterowania działa.

Korzystaj z dokumentacji Rockwell jako dowodów właściwych dla danej wersji

Informacje o wydaniu ControlLogix Revision 19 firmy Rockwell wyraźnie obejmują model 1756-L73 i wskazują powiązane środowisko RSLogix 5000, obsługiwane wersje oprogramowania układowego, działania wstępne oraz znane lub usunięte anomalie. Dokument ten jest właściwą podstawą oceny aplikacji w wersji 19 — a nie ogólna tabela wersji skopiowana z innej platformy.

Informacje o wydaniu ControlLogix Revision 21 obejmują wczesną generację Studio 5000 oraz właściwe dla tej wersji usprawnienia, ograniczenia i anomalie. Zakład rozważający wersję 21 powinien porównać te szczegóły z rzeczywistymi funkcjami projektu i modułami, zamiast zakładać, że nowsza wersja jest automatycznie bezpieczniejsza.

W przypadku każdego późniejszego celu, w tym wersji 31, należy w momencie prac zweryfikować w centrum Product Compatibility and Download Center firmy Rockwell dokładny katalog sterownika, serię, wersję oprogramowania układowego, wersję Studio 5000, system operacyjny, profile modułów oraz powiązane oprogramowanie. Nie należy traktować stwierdzenia „L73 obsługuje v31” jako uniwersalnego, oderwanego od kombinacji sprzętu i oprogramowania.

Oprogramowanie układowe i pamięć fizyczna to różne właściwości

Zmiana oprogramowania układowego nie instaluje dodatkowej pamięci fizycznej w sterowniku 1756-L73. Pojemność sterownika jest właściwością sprzętu udokumentowaną dla danego katalogu i serii. Zużycie pamięci przez projekt może jednak zmienić się po konwersji, ponieważ instrukcje, tagi, struktury komunikacyjne, dokumentacja i usługi oprogramowania układowego mogą być reprezentowane w inny sposób.

Za pomocą docelowego oprogramowania inżynieryjnego należy oszacować rozmiar przekonwertowanego projektu, a następnie zachować zapas na edycje online i przyszłe zmiany. Oficjalny Podręcznik użytkownika sterowników ControlLogix 5570 i 5560 powinien być wykorzystywany jako źródło informacji o sprzęcie, pamięci masowej, instalacji i wymaganiach eksploatacyjnych. Należy unikać nieoficjalnych tabel przypisujących różne pojemności pamięci fizycznej temu samemu sterownikowi w zależności od wersji oprogramowania układowego.

Utwórz wykaz zgodności

Rozpocznij od wykazu chassis i sieci. Zapisz katalog, serię i wersję oprogramowania układowego sterownika; moduły komunikacyjne i specjalistyczne; oprogramowanie układowe modułów; elektroniczne kluczowanie; adaptery zdalnych wejść/wyjść; osie ruchu; zależności bezpieczeństwa; napędy oraz konfigurację sieci. Uwzględnij narzędzia do harmonogramowania i konfiguracji DeviceNet lub ControlNet, jeśli te starsze sieci nadal są używane.

Następnie zmapuj łańcuch oprogramowania: oryginalną wersję RSLogix 5000 lub Studio 5000, komponenty FactoryTalk Linx lub RSLinx, wersję HMI lub SCADA, serwery OPC, profile dodatków, pliki EDS, narzędzia do napędów oraz wszelkie narzędzia OEM. Wersja sterownika sama w sobie nie określa, czy każda jednostka HMI musi zostać zaktualizowana. Zgodność zależy od rzeczywistego sterownika komunikacyjnego, zestawu funkcji i obsługiwanej kombinacji.

Na koniec zmapuj interfejsy aplikacji. Zidentyfikuj tagi produkowane i konsumowane, instrukcje MSG, zdalne szafy, urządzenia EtherNet/IP innych producentów, układy ruchu, synchronizację czasu, rejestratory danych, systemy wsadowe i zewnętrzne blokady. Kolekcja Allen-Bradley ControlLogix pomaga zidentyfikować komponenty platformy, natomiast szersza kolekcja systemów PLC i PAC zapewnia kontekst dla architektur mieszanych. Źródłem nadrzędnym w kwestii zgodności pozostają dokumentacja zakładowa i dokumentacja producenta.

Zachowaj rzeczywistą możliwość wycofania zmian

Przed konwersją zapisz oryginalny plik ACD w jego oryginalnej wersji oprogramowania i potwierdź, że można go otworzyć. Zapisz bieżący katalog, serię i wersję oprogramowania układowego sterownika, ścieżki komunikacyjne, ustawienia IP lub sieci, stan karty SD oraz konfigurację chassis. Wyeksportuj zasoby pomocnicze, które nie są w pełni zawarte w projekcie sterownika, w tym konfiguracje HMI, sieci, napędów i urządzeń innych producentów.

Utwórz osobną kopię przekonwertowaną. Nie nadpisuj jedynego znanego, sprawnego projektu. Konwersja do nowszej wersji nie gwarantuje automatycznej konwersji wstecznej. Wiarygodne wycofanie zmian obejmuje zatem oryginalny zgodny pakiet oprogramowania układowego, oryginalne oprogramowanie inżynieryjne, oryginalny plik ACD, dane dostępowe lub licencje oraz procedurę przywracania komunikacji i urządzeń innych niż sterownik.

Konwersja projektu jest kontrolowaną zmianą inżynieryjną; przekonwertowany plik nigdy nie powinien zastępować jedynego możliwego do odzyskania oryginału.

Przed aktualizacją oprogramowania układowego przejrzyj przekonwertowaną aplikację

Otwórz kopię w docelowym oprogramowaniu i zarejestruj komunikaty konwersji. Przejrzyj właściwości sterownika, profile modułów, elektroniczne kluczowanie, komunikację, układy ruchu, instrukcje dodatkowe, typy danych, zależności bezpieczeństwa lub redundancji oraz wszelkie zachowania instrukcji wskazane w informacjach o wydaniu. Potwierdź, że wymagane profile dodatków i oprogramowanie pomocnicze są zainstalowane i zatwierdzone.

Porównaj zużycie pamięci projektu i zasobów. Zweryfikuj, czy tagi, programy, procedury, moduły, definicje osi, ścieżki MSG oraz połączenia tagów produkowanych i konsumowanych nadal istnieją. Jeśli migracja obejmuje wiele głównych wersji, zwróć szczególną uwagę na funkcje wprowadzone, zmienione lub wycofane między wersjami początkową i docelową. Projekt, który nie zgłasza błędów konwersji, nadal wymaga przeglądu funkcjonalnego.

Kontroluj proces aktualizacji oprogramowania układowego

Użyj obsługiwanej przez Rockwell procedury aktualizacji oprogramowania układowego oraz pakietu przeznaczonego dla zweryfikowanej wersji docelowej. Zapewnij stabilne zasilanie i niezawodną ścieżkę komunikacyjną, wyłącz sterownik z odpowiedzialności za produkcję i postępuj zgodnie z działaniami wstępnymi opisanymi w informacjach o wydaniu. Przed rozpoczęciem potwierdź sposób obsługi karty SD oraz ustawienia ładowania z pamięci nieulotnej; nieoczekiwany obraz lub tryb ładowania może uniemożliwić zamierzoną sekwencję odzyskiwania.

Po aktualizacji odczytaj rzeczywistą wersję sterownika przed pobraniem projektu. Pobierz wyłącznie sprawdzony projekt przeznaczony dla docelowej wersji. Zapisz ostrzeżenia i stan sterownika. Nie ogłaszaj sukcesu tylko dlatego, że sterownik przeszedł do trybu Run.

Testy akceptacyjne muszą obejmować całą ścieżkę sterowania

Stany wejść/wyjść i urządzeń

Zweryfikuj lokalne i zdalne wejścia oraz wyjścia, skalowanie, jakość kanałów, usterki modułów, stany zadane i zachowanie w trybie bezpiecznym. Potwierdź, że wyjścia pozostają zablokowane do czasu spełnienia warunków rozruchu zakładu.

Komunikacja

Przetestuj tagi produkowane i konsumowane, instrukcje MSG, odczyt i zapis z HMI oraz SCADA, połączenia OPC, dane rejestrowane w historianie, zdalne szafy, napędy i urządzenia innych producentów. Sprawdź zarówno normalną aktualizację, jak i zachowanie w przypadku przekroczenia limitu czasu oraz przywracania połączenia.

Sekwencjonowanie, alarmy i ruch

Przetestuj krytyczne zezwolenia, przejścia sekwencji, alarmy pierwszego zadziałania, polecenia operatora i działanie resetowania. Jeśli występuje ruch, postępuj zgodnie z właściwymi informacjami o wydaniu Rockwell oraz procedurą bezpieczeństwa maszyny, a następnie w kontrolowanych warunkach zweryfikuj bazowanie, ograniczenia, koordynację i odzyskiwanie po awarii.

Cykl zasilania i gotowość do wycofania zmian

Sprawdź zamierzone zachowanie podczas uruchamiania po kontrolowanym cyklu zasilania, w tym ustawienia karty SD lub pamięci nieulotnej. Potwierdź, że udokumentowane zasoby do wycofania zmian są nadal dostępne oraz że końcowa kopia zapasowa odpowiada projektowi uruchomionemu w sterowniku.

Jak podejść do wersji v19, v21 i v31

Wersja 19 jest racjonalnym celem przywracania, gdy odpowiada zweryfikowanemu projektowi produkcyjnemu i obsługiwanej stacji inżynieryjnej. Jej wiek jest kwestią związaną z cyklem życia, ale sam wiek nie dowodzi, że awaryjna migracja jest bezpieczniejsza.

Wersję 21 można oceniać jako celowy krok w kierunku generacji Studio 5000. Jej korzyści i anomalie należy ocenić na podstawie oficjalnych informacji o wydaniu oraz rzeczywistego wykorzystania przez projekt funkcji łączności HMI, dokumentacji, ruchu i komunikacji.

Wersja 31 lub inna późniejsza baza należy do planowanej decyzji modernizacyjnej. Wybierz wersję docelową dopiero po potwierdzeniu w aktualnych danych zgodności dokładnego sprzętu L73 i otaczającego oprogramowania. Większy skok między wersjami zwiększa zakres przeglądu, nawet jeśli konwersja zakończy się powodzeniem.

Właściwa decyzja jest zatem warunkowa, a nie uniwersalna: przywróć konfigurację możliwie identyczną, gdy jedynym zatwierdzonym celem jest usunięcie skutków przestoju; przeprowadź migrację, gdy zakład może zweryfikować zależności, przetestować całą aplikację i wycofać zmiany. Takie podejście traktuje oprogramowanie układowe jako jedną kontrolowaną warstwę systemu produkcyjnego, a nie liczbę, którą należy maksymalizować.