Modernizacja interfejsów HMI Bailey INFI 90 Symphony działających na OpenVMS Alpha

Modernizacja HMI bez wymiany całego systemu INFI 90

Wiele systemów Bailey INFI 90 nadal działa niezawodnie dziesiątki lat po pierwotnej instalacji. Ich sterowniki, moduły komunikacyjne, moduły terminacyjne i obiektowe moduły I/O mogą nadal realizować wymagane funkcje sterowania.

Najpilniejszy problem związany z cyklem życia często występuje powyżej warstwy sterowników.

Stacje operatorskie mogą zależeć od starzejącego się sprzętu AlphaStation, nieobsługiwanych kart graficznych, przestarzałych urządzeń pamięci masowej i starych środowisk programowych OpenVMS Alpha. Części zamienne stają się trudne do zdobycia, a doświadczeni inżynierowie OpenVMS i Bailey Symphony są coraz mniej dostępni.

Rozpatrywany przykład obejmuje cztery stacje robocze AlphaStation 255. Każda stacja korzysta z systemu OpenVMS Alpha i obsługuje funkcje interfejsu operatora Bailey Symphony dla rozproszonego systemu sterowania Bailey INFI 90.

Celem nie musi być wymiana całego systemu DCS. Bardziej praktycznym celem jest uniezależnienie się od starzejącego się sprzętu AlphaStation przy jednoczesnym zachowaniu stabilnych sterowników, okablowania obiektowego, modułów I/O, logiki sterowania i procesów produkcyjnych.

To rozróżnienie zmienia strategię modernizacji.

Projekt dotyczy przede wszystkim migracji interfejsu operatora i platformy obliczeniowej. Staje się pełną migracją DCS dopiero wtedy, gdy cykl życia sterowników, wymagania dotyczące cyberbezpieczeństwa, cele produkcyjne lub warunki wsparcia uzasadniają wymianę niższych warstw sterowania.

Istnieje kilka możliwych ścieżek modernizacji. Zachowują one jednak różne części istniejącego systemu.

Emulator Alpha może zachować niemal całe środowisko programowe. Migracja do OpenVMS x86 zachowuje rodzinę systemów operacyjnych, ale wymaga migracji aplikacji. Wymiana HMI oparta na OPC zachowuje warstwę sterowników, jednocześnie odtwarzając interfejs operatora. Strategia ewolucji ABB może etapami modernizować szerszą architekturę Symphony.

Żadnej z tych ścieżek nie należy opisywać jako zwykłej wymiany komputera na PC.

Rysunek 1. Trzy główne ścieżki modernizacji mogą zachować różne części zainstalowanych rozwiązań Bailey INFI 90 i Symphony.

Dlaczego samo sklonowanie dysku stacji AlphaStation nie wystarcza

Klonowanie dysku jest przydatne do zachowania zainstalowanego środowiska OpenVMS Alpha. Może ono obejmować system operacyjny, pliki aplikacji, konfigurację urządzeń, konta użytkowników, oprogramowanie Bailey, bazy danych, grafikę i ustawienia specyficzne dla danego obiektu.

Klonowanie dysku nie przekształca jednak oprogramowania Alpha w oprogramowanie x86.

Sklonowany system operacyjny nadal zawiera instrukcje procesora Alpha. Jego jądro, program rozruchowy, biblioteki systemowe, aplikacje i sterowniki sprzętowe zostały zbudowane dla architektury Alpha.

Standardowy nowoczesny komputer PC wykorzystuje procesor x86-64. Udostępnia również inne kontrolery pamięci masowej, urządzenia sieciowe, struktury przerwań, sprzęt graficzny, interfejsy oprogramowania układowego i magistrale urządzeń peryferyjnych.

VMware, VirtualBox, Hyper-V i konwencjonalne hipernadzorcy x86 wirtualizują sprzęt zgodny z x86. Zwykle nie tłumaczą instrukcji procesora Alpha na instrukcje x86.

Dlatego umieszczenie obrazu dysku OpenVMS Alpha w zwykłej maszynie wirtualnej x86 nie sprawi, że obraz ten będzie się uruchamiał.

Maszyna wirtualna może udostępniać wirtualny dysk, wirtualną kartę sieciową i wirtualne urządzenie graficzne. OpenVMS Alpha nadal oczekuje procesora Alpha i obsługiwanych urządzeń z epoki Alpha.

Dlatego te dwa pojęcia należy rozdzielić:

Wirtualizacja zwykle udostępnia wirtualny sprzęt wykorzystujący tę samą architekturę procesora co host.

Emulacja międzyarchitekturna odtwarza w oprogramowaniu inny procesor i środowisko sprzętowe.

OpenVMS Alpha wymaga drugiego podejścia, gdy oryginalne pliki binarne Alpha i system operacyjny muszą pozostać niezmienione.

Klonowanie dysku jest zatem wykonalne w trzech ograniczonych sytuacjach.

Pierwszą możliwością jest odtworzenie systemu na tym samym modelu AlphaStation, z użyciem zgodnych nośników danych i urządzeń peryferyjnych.

Drugą możliwością jest odtworzenie systemu na innym obsługiwanym systemie Alpha po wykonaniu wymaganych zmian urządzeń i konfiguracji.

Trzecią możliwością jest odtworzenie systemu w emulatorze Alpha, który odwzorowuje zgodne środowisko AlphaServer lub AlphaStation.

Samo klonowanie nie rozwiązuje problemu architektury. Środowisko docelowe nadal musi rozumieć i wykonywać instrukcje maszynowe Alpha.

Emulacja Alpha zachowuje największą część istniejących inwestycji

Emulacja Alpha jest zwykle najmniej zakłócającą ścieżką, gdy istniejące oprogramowanie Symphony musi nadal działać bez zmian w kodzie źródłowym.

Emulator Alpha działa na nowoczesnym sprzęcie x86, ale udostępnia systemowi OpenVMS wirtualny system Alpha. Oryginalny system operacyjny i aplikacje nadal widzą środowisko sprzętowe zgodne z Alpha.

Produkty takie jak CHARON-AXP są przeznaczone do tego celu. Emulator zastępuje fizyczny procesor Alpha, architekturę pamięci, kontrolery pamięci masowej, karty Ethernet i inne obsługiwane urządzenia odpowiednikami definiowanymi programowo.

Serwer x86 uruchamia system Windows lub Linux jako środowisko hosta. Emulator Alpha działa ponad tym hostem. OpenVMS Alpha działa następnie wewnątrz emulowanego systemu Alpha.

To podejście różni się od przenoszenia OpenVMS na architekturę x86.

Oryginalna instalacja OpenVMS Alpha pozostaje instalacją Alpha. Pliki binarne Bailey Symphony pozostają plikami binarnymi Alpha. Emulator tłumaczy lub odtwarza wymagane działanie sprzętu Alpha.

Może to zachować:

• Zainstalowany system operacyjny OpenVMS Alpha.

• Istniejące aplikacje Bailey Symphony.

• Grafiki operatora i bazy danych ekranów.

• Konfiguracje alarmów i pliki historyczne.

• Konta użytkowników i procedury poleceń.

• Istniejące narzędzia specyficzne dla danego obiektu.

• Interfejsy aplikacji zależne od środowiska Alpha.

• Przepływy pracy operatorów, które w przeciwnym razie wymagałyby ponownego szkolenia.

Praktyczna migracja zwykle obejmuje utworzenie zweryfikowanego obrazu lub kopii zapasowej oryginalnych dysków systemu Alpha. Dane te są przywracane do kontenerów dysków wirtualnych używanych przez emulator.

Konfiguracja emulatora musi odtwarzać odpowiednie charakterystyki procesora, pamięci, dysku, sieci i urządzeń peryferyjnych. Zespół może również需要 mapować fizyczne porty szeregowe lub interfejsy sieciowe za pośrednictwem systemu hosta.

Emulacja systemu Alpha może znacznie zmniejszyć zależność od przestarzałego sprzętu fizycznego. Może również uprościć tworzenie kopii zapasowych, ponieważ pliki dysków wirtualnych można kopiować z użyciem nowoczesnej infrastruktury pamięci masowej.

Jednak określenia „zero zmian” należy używać ostrożnie.

Kod aplikacji może pozostać niezmieniony, ale środowisko nadal wymaga prac inżynieryjnych. Należy sprawdzić mapowania urządzeń. Trzeba skonfigurować interfejsy sieciowe. Należy przeanalizować licencje OpenVMS i licencje aplikacji.

Emulator należy również przetestować z używanym w obiekcie interfejsem komunikacyjnym Bailey.

Ogólna aplikacja OpenVMS może działać prawidłowo, podczas gdy specjalistyczny interfejs DCS zawiedzie, ponieważ zależy od konkretnego adaptera sieciowego, interfejsu magistrali, urządzenia szeregowego lub charakterystyki czasowej.

Dlatego przed wybraniem profilu emulatora należy zinwentaryzować dokładną konfigurację stacji AlphaStation 255.

Interfejs komunikacyjny Bailey jest kluczowym testem emulacji

Najważniejsze pytanie dotyczące emulacji nie brzmi: czy system OpenVMS dochodzi do znaku zachęty logowania.

Najważniejsze pytanie brzmi, czy emulowana stacja prawidłowo komunikuje się z systemem Bailey INFI 90 w pełnych warunkach pracy.

Interfejs może zależeć od sieci Ethernet, komunikacji szeregowej, interfejsu sieciowego Bailey lub specjalistycznego sprzętu komunikacyjnego. Konfiguracje obiektowe mogą znacznie się różnić.

Przed podjęciem decyzji o emulacji systemu Alpha inżynierowie powinni udokumentować:

• Fizyczny interfejs sieciowy zainstalowany w każdej stacji AlphaStation.

• Protokół komunikacyjny używany między systemami Symphony i INFI 90.

• Nazwy urządzeń przypisane w systemie OpenVMS.

• Adresy sieciowe i definicje węzłów.

• Wymagane usługi DECnet, TCP/IP, LAT lub usługi zastrzeżone.

• Ustawienia portów szeregowych, jeśli mają zastosowanie.

• Wszelkie zewnętrzne klucze licencyjne lub sprzętowe klucze zabezpieczające.

• Działanie nadmiarowości i przełączania awaryjnego między stacjami operatorskimi.

• Wymagania dotyczące synchronizacji czasu.

• Funkcje graficzne i klawiaturowe używane przez operatorów.

Dostawca emulatora może obsługiwać popularne urządzenia Ethernet i pamięci masowej firmy Alpha. Nie potwierdza to automatycznie obsługi każdego zastrzeżonego interfejsu firmy Bailey.

Jeśli istniejący HMI zależy od specjalistycznego fizycznego adaptera, którego nie można zwirtualizować, podejście z emulatorem może wymagać alternatywnej bramy komunikacyjnej.

Projekt powinien zatem obejmować test stanowiskowy z wykorzystaniem sklonowanej stacji oraz dostępem do reprezentatywnej sieci Bailey.

Test musi obejmować więcej niż statyczny odczyt znaczników. Operatorzy powinni sprawdzić wartości w czasie rzeczywistym, polecenia, alarmy, potwierdzanie, trendy, nawigację po ekranach, drukowanie, obsługę zdarzeń i odzyskiwanie stacji.

Wydajność należy również testować podczas nagłych wzrostów liczby alarmów i intensywnej aktualizacji znaczników.

OpenVMS x86-64 to inna ścieżka migracji

Nowoczesny OpenVMS jest dostępny dla architektury x86-64. Może działać we wspieranych środowiskach zwirtualizowanych na nowoczesnych serwerach.

Tworzy to dodatkową opcję migracji, która nie była dostępna podczas wielu wcześniejszych dyskusji dotyczących modernizacji INFI 90.

OpenVMS x86-64 nie uruchamia jednak bezpośrednio plików binarnych OpenVMS Alpha tak, jakby były natywnymi aplikacjami x86.

Należy przeprowadzić migrację środowiska aplikacyjnego.

Kod źródłowy może wymagać przeniesienia, przeglądu, ponownej kompilacji, konsolidacji i przetestowania dla x86-64. Biblioteki innych firm i produkty warstwowe również muszą być dostępne dla wersji docelowej.

Kluczowe pytanie brzmi, czy zainstalowane oprogramowanie Bailey Symphony ma wersję OpenVMS zgodną z x86.

Jeśli dostawca oprogramowania nigdy nie wydał tej aplikacji dla OpenVMS x86-64, samo przeniesienie systemu operacyjnego nie zachowa interfejsu HMI.

Programy opracowane na miejscu mogą być przenośne, jeśli ich kod źródłowy i środowisko budowania są nadal dostępne. Zamkniętych aplikacji komercyjnych zazwyczaj nie można ponownie zbudować bez wsparcia producenta.

Ta ścieżka może jednak nadal być praktyczna dla niestandardowych serwerów danych, archiwizatorów, narzędzi, raportów i aplikacji integracyjnych działających obok interfejsu HMI Symphony.

Mniej prawdopodobne jest zachowanie starego, zastrzeżonego środowiska operatorskiego Symphony bez wspieranej wersji aplikacji.

Ocena migracji OpenVMS x86 powinna obejmować:

• Każdy zainstalowany plik wykonywalny i produkt warstwowy.

• Dostępny kod źródłowy i procedury budowania.

• Zależności kompilatora i środowiska uruchomieniowego.

• Produkty bazodanowe i formaty plików.

• Zastrzeżone biblioteki komunikacyjne.

• Zależności dotyczące grafiki lub systemu okien.

• Dostępność licencji dla x86-64.

• Wymagane zmiany wynikające z różnic architektonicznych.

• Założenia dotyczące wydajności i synchronizacji czasowej.

Ta ścieżka ma większy potencjał długoterminowy niż przejście z platformy Alpha na inną wycofaną architekturę sprzętową. Może umożliwić uruchomienie zgodnych obciążeń OpenVMS na wspieranej infrastrukturze wirtualizacyjnej x86.

Należy ją jednak opisywać jako projekt migracji aplikacji, a nie klonowania dysku.

Dlaczego migracja z Itanium jest zazwyczaj opcją przejściową

OpenVMS wydano również dla serwerów HPE Integrity wykorzystujących architekturę Itanium.

Istnieją narzędzia migracyjne i metody inżynieryjne umożliwiające przenoszenie niektórych aplikacji Alpha do OpenVMS Integrity. Zapewniało to niegdyś wspieraną ścieżkę odejścia od starzejącego się sprzętu Alpha.

Dziś jednak sprzęt Itanium sam w sobie jest platformą starszej generacji.

Przejście z Alpha na Integrity może usunąć jedną zależność od przestarzałego sprzętu, jednocześnie tworząc kolejną. Odpowiednie serwery, części, interfejsy pamięci masowej i specjalistyczna wiedza będą nadal coraz mniej dostępne.

Itanium nadal może mieć znaczenie, gdy zakład posiada już obsługiwaną infrastrukturę Integrity. Może być również istotny, gdy wymagany produkt warstwowy istnieje dla Integrity, ale nie dla x86-64.

W przypadku nowego projektu modernizacyjnego należy ją zasadniczo oceniać jako pośrednią ścieżkę zapewnienia zgodności.

Uzasadnienie biznesowe musi wyjaśniać, dlaczego przejście na Integrity jest korzystniejsze niż emulacja Alpha, migracja OpenVMS x86 lub replatformizacja HMI.

Replatformizacja OPC zachowuje warstwę sterowania

Replatformizacja OPC zastępuje warstwę interfejsu operatorskiego, zachowując istniejące sterowniki INFI 90 i polowe moduły wejścia/wyjścia.

Serwer komunikacyjny łączy się z systemem Bailey i udostępnia tagi procesowe nowoczesnej platformie HMI lub SCADA.

Nowy system HMI obsługuje ekrany, alarmy, trendy, bezpieczeństwo, polecenia operatora, raporty i usługi stacji roboczych.

Ta ścieżka eliminuje zależność od oryginalnej aplikacji operatorskiej Symphony. Pozwala również uniknąć konieczności uruchamiania OpenVMS Alpha na nowych stacjach operatorskich.

Architektura zwykle obejmuje:

• Istniejące sterowniki i moduły wejścia/wyjścia Bailey INFI 90.

• Zgodny interfejs komunikacyjny Bailey.

• Serwer danych OPC DA, OPC UA lub serwer właściwy dla danego dostawcy.

• Nowoczesna platforma HMI lub SCADA.

• Operatorskie i inżynierskie stacje robocze.

• Opcjonalne usługi archiwizacji danych, raportowania i analizy alarmów.

W materiale źródłowym przywołano przykład z zastosowaniem serwera OPC RoviSys wraz z GE CIMPLICITY. Zgłoszono, że system działał prawidłowo, jednak projekt wymagał odtworzenia ekranów operatorskich i logiki animacji.

Tego przykładu nie należy interpretować jako automatycznej rekomendacji produktu dla każdej instalacji INFI 90.

Wybrany serwer musi obsługiwać konkretną sieć Bailey, moduły komunikacyjne, generację sterowników, liczbę tagów, częstotliwość aktualizacji, wymagania dotyczące redundancji oraz funkcje sterowania stosowane w danym zakładzie.

To samo dotyczy platformy HMI.

GE CIMPLICITY to jedna z możliwych platform HMI/SCADA dla przedsiębiorstwa. Inne systemy również mogą się sprawdzić, jeśli zapewniają wymaganą łączność OPC, grafikę, alarmy, skrypty, redundancję, bezpieczeństwo i wsparcie przez cały cykl życia.

Rysunek 2. Migracja oparta na OPC zachowuje warstwę sterowania INFI 90, zastępując jednocześnie starsze środowisko operatorskie Symphony.

Łączność OPC nie konwertuje istniejących ekranów

Serwer OPC zapewnia łączność z danymi. Zwykle nie konwertuje starych ekranów HMI do nowego formatu HMI.

Oryginalne ekrany Symphony mogą zawierać statyczną grafikę, symbole dynamiczne, zmiany kolorów, wartości liczbowe, wykresy słupkowe, wskaźniki alarmów, przyciski nawigacyjne, elementy sterowania, trendy oraz niestandardowe szablony funkcji.

Elementy te muszą zostać odtworzone w docelowym interfejsie HMI.

Proste ekrany można przerysować bezpośrednio. Złożone ekrany mogą zawierać ukryte skrypty lub wyrażenia, które nie są od razu widoczne.

Inżynierowie muszą rozumieć, w jaki sposób każdy animowany obiekt pobiera i przetwarza swoje dane.

Symbol zaworu nie musi po prostu podążać za jednym tagiem wyjściowym. Jego kolor i położenie mogą zależeć od potwierdzenia otwarcia, potwierdzenia zamknięcia, stanu polecenia, statusu blokady, jakości komunikacji i trybu pracy urządzenia.

Symbol silnika może wykorzystywać osobne tagi dla polecenia uruchomienia, potwierdzenia pracy, stanu zatrzymania, zadziałania zabezpieczenia, sterowania lokalnego, stanu konserwacji, zezwoleń i blokady alarmu.

Samo przeniesienie widocznych grafik może zatem doprowadzić do powstania interfejsu HMI, który wygląda poprawnie, ale działa nieprawidłowo.

Zespół migracyjny musi udokumentować znaczenie funkcjonalne każdego elementu ekranu.

Zakres tych prac obejmuje:

• Powiązanie każdego obiektu dynamicznego z jego źródłem danych.

• Odtworzenie wyrażeń animacji.

• Weryfikacja potwierdzania poleceń i zabezpieczeń.

• Odtworzenie nawigacji i hierarchii ekranów.

• Odtworzenie klas i priorytetów alarmów.

• Potwierdzenie jednostek inżynierskich i precyzji miejsc dziesiętnych.

• Odtworzenie trendów historycznych i czasu rzeczywistego.

• Testowanie stanów nieprawidłowych, niepewnych i związanych z utratą komunikacji.

• Odtworzenie komunikatów i wskazówek dla operatora.

• Zastąpienie nieobsługiwanych czcionek i symboli.

Nakład pracy zależy zatem od złożoności ekranów, a nie tylko od ich liczby.

Nowoczesny interfejs HMI nie powinien bezkrytycznie kopiować każdego starszego ekranu

Ręczne odtworzenie stwarza możliwość ulepszenia interfejsu operatora.

Starsze grafiki HMI często wykorzystują jaskrawe kolory dla urządzeń pracujących normalnie, gęste diagramy procesowe, dekoracyjne rurociągi i niespójne sygnalizowanie alarmów.

Konwencje te mogły być uzasadnione w chwili opracowywania oryginalnego systemu. Nie zawsze są idealne dla obecnych praktyk w sterowniach.

Projekt modernizacji powinien obejmować przegląd:

• Hierarchia ekranów.

• Widoczność alarmów.

• Spójność nawigacji.

• Prezentacja stanu urządzeń.

• Zastosowanie kolorów.

• Dostępność trendów.

• Wymagania dotyczące reakcji operatora.

• Rozdzielczość ekranu i układ stanowiska pracy.

• Dostępność i czytelność.

Normalne warunki pracy powinny pozostać wizualnie stonowane. Wyraziste kolory powinny wskazywać stany nieprawidłowe wymagające uwagi.

Operatorzy powinni móc przejść z widoku całej instalacji do widoku objętego problemem obiektu, panelu czołowego urządzenia, trendu, historii alarmów i ekranu diagnostycznego bez nadmiernej liczby kroków nawigacji.

Jednak nadmierne przeprojektowanie może stworzyć inne ryzyko.

Operatorzy mogli korzystać z oryginalnych ekranów przez wiele lat. Zmiana każdego symbolu, koloru i ścieżki nawigacji w ramach tego samego projektu może zwiększyć wymagania szkoleniowe i ryzyko przełączenia.

Zrównoważone podejście zachowuje znane zależności procesowe, jednocześnie usprawniając prezentację alarmów i nawigację.

Ekstrakcję tagów należy traktować jako pakiet prac inżynieryjnych

Materiały źródłowe wskazują na możliwość eksportowania danych tagów Bailey do formatu CSV. Nie przedstawiają jednak potwierdzonej, uniwersalnej procedury.

Dlatego nie należy zakładać, że jedno polecenie eksportu utworzy kompletną i uporządkowaną bazę danych HMI.

Możliwe źródła informacji o tagach obejmują:

• Bazy danych konfiguracji Symphony.

• Istniejące definicje ekranów.

• Konfiguracja sterowników i dokumentacja inżynierska.

• Bazy danych serwera komunikacyjnego Bailey.

• Funkcje przeglądania serwera OPC.

• Pliki konfiguracji alarmów.

• Historyczne bazy danych.

• Wydrukowane lub zarchiwizowane listy tagów.

• Arkusze kalkulacyjne działu inżynierii zakładu.

Przeglądanie OPC może stanowić praktyczny punkt wyjścia po nawiązaniu przez serwer komunikacji z systemem Bailey.

Może udostępniać nazwy tagów, identyfikatory elementów, opisy, jakość i bieżące wartości. Niektóre serwery obsługują również eksport przeglądanej przestrzeni nazw.

Jednak przestrzeń nazw OPC może nie zawierać wszystkich pól potrzebnych przez nowy system HMI.

Priorytety alarmów, limity inżynierskie, grupowanie na ekranach, notatki operatora, zabezpieczenia poleceń oraz powiązania z urządzeniami mogą być przechowywane w innych miejscach.

Niektóre serwery OPC udostępniają tagi za pomocą wygenerowanych nazw różniących się od oryginalnych nazw Symphony.

Projekt powinien utworzyć kontrolowany rejestr tagów zawierający co najmniej:

• Oryginalna nazwa tagu.

• Nazwa nowego tagu HMI.

• Identyfikator elementu OPC.

• Opis.

• Typ danych.

• Uprawnienie do odczytu lub zapisu.

• Jednostki inżynierskie.

• Informacje o skalowaniu.

• Limity alarmowe i priorytet.

• Częstotliwość aktualizacji.

• Powiązany ekran.

• Status walidacji.

• Wynik testu.

Ten wzorzec będzie pełnił funkcję rejestru uzgodnień między systemem starszym a nowym.

Liczba tagów nie jest jedynym wymaganiem komunikacyjnym

Pomyślne przetestowanie przeglądania nie dowodzi, że architektura OPC może obsłużyć kompletny system HMI.

Inżynierowie muszą ocenić liczbę aktywnych tagów, żądaną częstotliwość aktualizacji, częstotliwość zmian, aktywność alarmów, ruch poleceń oraz redundancję serwera.

System może zawierać dziesiątki tysięcy skonfigurowanych tagów. W danym momencie na ekranach operatora może być aktywna tylko ich część.

Serwer i HMI powinny zostać przetestowane w realistycznych warunkach.

Do najważniejszych kontroli wydajności należą:

• Czas wymagany do otwarcia złożonego ekranu.

• Opóźnienie między zmianą w polu a animacją na HMI.

• Dostarczanie alarmów podczas gwałtownego napływu zdarzeń.

• Zbieranie trendów z wymaganą częstotliwością próbkowania.

• Czas wykonania polecenia i otrzymania potwierdzenia zwrotnego.

• Odzyskiwanie po przerwie w sieci.

• Przełączanie awaryjne między redundantnymi serwerami.

• Zachowanie po ponownym uruchomieniu sterownika.

• Stan jakości podczas awarii komunikacji.

• Obciążenie procesora, pamięci i sieci.

Polecenia wymagają szczególnej uwagi.

Odczyt wartości za pośrednictwem OPC może być stosunkowo prosty. Bezpieczny zapis wartości wymaga kontroli dostępu, walidacji poleceń, potwierdzenia zwrotnego oraz prawidłowej obsługi awarii komunikacji.

Zespół powinien przetestować każdy typ polecenia operatora, a nie tylko jeden reprezentatywny tag.

ABB Symphony Plus zapewnia szerszą ścieżkę rozwoju

Zastąpienie OPC nie jest jedyną ścieżką dla zainstalowanego systemu Bailey.

ABB nadal przedstawia Symphony Plus jako platformę rozwojową dla starszych instalacji Bailey, INFI 90, Harmony Rack i Symphony.

Etapowa modernizacja ABB może zachować części zainstalowanej architektury sterowania i wejść/wyjść, jednocześnie wprowadzając nowsze komponenty operatorskie, inżynieryjne, sieciowe, sterowniki lub moduły wejść/wyjść.

Ta ścieżka może być atrakcyjna, gdy organizacja chce korzystać ze wspieranej przez dostawcę strategii utrzymania w całym cyklu życia, zamiast niezależnej wymiany systemu HMI.

W pierwszej kolejności projekt może zmodernizować środowisko operatorskie. Sterowniki i moduły wejść/wyjść mogą pozostać w eksploatacji do czasu, gdy ich cykl życia lub wartość operacyjna uzasadnią wymianę.

Kolejne etapy mogą objąć komunikację, sterowniki, narzędzia inżynieryjne i interfejsy obiektowe.

Dokładna architektura migracji zależy od generacji zainstalowanego systemu.

Instalacje Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony i Symphony Plus nie korzystają ze wszystkich tych samych interfejsów.

Nazwy modułów i terminologia sieciowa muszą zostać zweryfikowane na podstawie rysunków obiektu i ewidencji sprzętu.

Organizacje utrzymujące istniejącą warstwę sterowania mogą również sprawdzić dostępne komponenty ABB Bailey INFI 90 i Network 90 podczas planowania zapasu części, wsparcia w całym cyklu życia oraz etapowej modernizacji.

Ten odnośnik wewnętrzny jest istotny, ponieważ projekty modernizacyjne często wymagają, aby stary system pozostał operacyjny podczas prac inżynieryjnych, testów i etapowego przełączania.

Utrzymywanie odpowiednich sterowników zapasowych, modułów komunikacyjnych, zasilaczy i modułów wejść/wyjść może zmniejszyć ryzyko w okresie przejściowym.

Niestandardowy lub otwartoźródłowy system HMI jest możliwy, ale wymaga przejęcia odpowiedzialności

Niestandardowy system HMI można opracować z wykorzystaniem otwartoźródłowych lub komercyjnych frameworków programistycznych.

Materiał źródłowy wspomina o serwerze działającym w środowisku VMS oraz nowoczesnym kliencie opartym na Qt. Architektury tego typu mogą oddzielać połączenie danych po stronie serwera od klienta operatorskiego.

Ta ścieżka może zapewnić elastyczność i pozwolić uniknąć uzależnienia od jednego dostawcy systemu HMI.

Może się to również stać długoterminowym zobowiązaniem do rozwoju oprogramowania.

Organizacja musi posiadać lub utrzymywać:

• Serwer komunikacyjny.

• Baza danych zmiennych.

• Aplikacja kliencka.

• Framework graficzny.

• Przetwarzanie alarmów.

• Integracja z archiwizatorem danych.

• Uwierzytelnianie użytkowników.

• Aktualizacje cyberbezpieczeństwa.

• Wdrażanie i kontrola wersji.

• Dokumentacja i szkolenia.

Qt, Python, C++, technologie webowe i inne frameworki mogą służyć do tworzenia wydajnych interfejsów przemysłowych. Trudność nie polega na narysowaniu grafiki procesu.

Trudność polega na stworzeniu niezawodnego systemu operatorskiego, który działa prawidłowo podczas awarii komunikacji, ponownego uruchamiania serwerów, lawin alarmów, zmian użytkowników i nietypowych warunków pracy instalacji.

Niestandardową platformę należy wybierać tylko wtedy, gdy organizacja dysponuje stabilnym zespołem inżynieryjnym lub rzetelnym integratorem gwarantującym długoterminowe wsparcie.

Licencjonowanie może decydować o praktycznej wykonalności ścieżki technicznej

Starsze oprogramowanie przemysłowe często korzysta z mechanizmów licencjonowania powiązanych z identyfikatorami sprzętu, adresami Ethernet, bazami licencji, kluczami sprzętowymi lub kluczami autoryzacyjnymi wydanymi przez dostawcę.

Sklonowany system może uruchomić się poprawnie, ale odmówić uruchomienia aplikacji Symphony, ponieważ zmieniła się tożsamość sprzętu wirtualnego.

Inwentaryzacja migracyjna powinna obejmować:

• Licencje systemu operacyjnego OpenVMS.

• Licencje aplikacji Bailey Symphony.

• Licencje baz danych.

• Licencje sieciowe i komunikacyjne.

• Licencje emulatora.

• Licencje HMI i licencje określające liczbę punktów OPC.

• Licencje modułu archiwizacji danych.

• Opcje redundancji.

• Licencje klientów inżynierskich.

• Licencje klientów wykonawczych.

Przed wyborem ostatecznej platformy należy uzyskać pisemne potwierdzenie.

Zgodność techniczna bez dostępności wymaganych licencji prawnych nie zapewnia rozwiązania możliwego do wdrożenia.

Cyberbezpieczeństwo należy uwzględnić w projekcie rozwiązania zastępczego

Starsze systemy AlphaStation były często instalowane, zanim nowoczesne praktyki cyberbezpieczeństwa przemysłowego stały się standardem.

Mogą działać w odizolowanych sieciach z ograniczonym dostępem zdalnym. Zastąpienie ich serwerami Windows, nowoczesnymi klientami SCADA, serwerami OPC i infrastrukturą Ethernet zmienia powierzchnię ataku.

Nowa architektura powinna definiować oddzielne strefy sieci sterowania, serwerów, inżynierską i korporacyjną.

Zapory sieciowe powinny zezwalać wyłącznie na wymagane ścieżki komunikacji. Dostęp zdalny powinien wykorzystywać zarządzane uwierzytelnianie i rejestrowanie.

Konta operatorów powinny korzystać z uprawnień opartych na rolach. Funkcje inżynierskie nie powinny być dostępne z każdego klienta HMI.

Dostęp do zapisu OPC powinien być ograniczony do tagów i stacji, które go wymagają.

Projekt powinien również uwzględniać:

• Instalowanie poprawek systemu operacyjnego.

• Ochrona antywirusowa lub kontrola aplikacji.

• Tworzenie kopii zapasowych i odzyskiwanie.

• Synchronizacja czasu.

• Rejestrowanie zdarzeń bezpieczeństwa.

• Kontrola nośników wymiennych.

• Zdalne wsparcie dostawcy.

• Zarządzanie certyfikatami dla OPC UA.

• Zarządzanie cyklem życia kont.

Mechanizmy cyberbezpieczeństwa nie mogą uniemożliwiać operatorom reagowania podczas zdarzeń w zakładzie. Projekt powinien równoważyć ochronę z dostępnością i deterministycznym działaniem.

Migrację należy rozpocząć od inwentaryzacji opartej na dowodach

Przed wyborem ścieżki inżynierowie powinni szczegółowo udokumentować istniejący system.

Inwentaryzacja powinna obejmować wszystkie cztery stacje AlphaStation i określać, czy ich konfiguracje są rzeczywiście identyczne.

Zapis:

• Model AlphaStation i konfiguracja procesora.

• Pojemność pamięci.

• Typ dysków i woluminy logiczne.

• Wersja OpenVMS i poziom poprawek.

• Zainstalowane wersje oprogramowania Bailey.

• Produkty warstwowe i bazy danych.

• Sprzęt graficzny i rozdzielczość ekranu.

• Karty sieciowe.

• Interfejsy szeregowe.

• Sprzęt komunikacyjny Bailey.

• Nazwy i adresy węzłów.

• Procedury poleceń uruchamiania.

• Pliki licencyjne.

• Procedury tworzenia kopii zapasowych.

• Nadmiarowość stacji operatorskich.

• Podłączone drukarki i urządzenia zewnętrzne.

• Przechowywanie danych historycznych i alarmów.

Zespół powinien również gromadzić zrzuty ekranu każdego ekranu. W miarę możliwości należy rejestrować stany dynamiczne.

Należy rejestrować stany normalne, zatrzymania, pracy, alarmowe, zablokowania, lokalne, ręczne, automatyczne oraz awarii komunikacji.

Dowody te są niezbędne podczas testowania nowych ekranów.

Stanowisko testowe jest obowiązkowe

Żadnej ścieżki modernizacji nie należy po raz pierwszy testować na działającym systemie produkcyjnym.

Środowisko stanowiskowe powinno odtwarzać wystarczającą część zainstalowanej architektury, aby zweryfikować komunikację i funkcje operatorskie.

W przypadku projektu emulatora stanowisko powinno zawierać sklonowane środowisko OpenVMS Alpha oraz proponowaną konfigurację emulatora.

W przypadku projektu OPC powinien obejmować wybrany serwer komunikacyjny, oprogramowanie HMI, reprezentatywną grafikę oraz dostęp do bezpiecznego węzła testowego Bailey lub symulowanego źródła danych.

Test stanowiskowy powinien zweryfikować:

• Uruchamianie systemu i aplikacji.

• Komunikacja z systemem Bailey.

• Łączna liczba dostępnych znaczników.

• Operacje odczytu i zapisu.

• Skalowanie znaczników i jednostki inżynierskie.

• Generowanie i potwierdzanie alarmów.

• Gromadzenie trendów.

• Animacja ekranów.

• Bezpieczeństwo poleceń.

• Funkcje drukowania i raportowania.

• Zachowanie podczas ponownego uruchamiania serwera.

• Zachowanie podczas awarii sieci.

• Nadmiarowość i przełączanie awaryjne.

• Odtwarzanie kopii zapasowej.

• Czas reakcji operatora.

Wyniki testów powinni obserwować przedstawiciele działów eksploatacji, inżynierii sterowania, utrzymania ruchu i cyberbezpieczeństwa.

Praca równoległa zmniejsza ryzyko przełączenia

Oryginalne stacje AlphaStations powinny pozostać dostępne podczas początkowego wdrażania systemu zastępczego.

Nowy interfejs HMI może działać równolegle, podczas gdy inżynierowie porównują wartości, alarmy, trendy i polecenia.

Praca równoległa umożliwia wykrycie niezgodności przed usunięciem starszej stacji.

Zespół powinien uzgodnić:

• Wyświetlane wartości procesowe.

• Wskazania stanu.

• Priorytety alarmów.

• Znaczniki czasu alarmów.

• Wyniki poleceń.

• Wartości trendów.

• Tryb pracy urządzenia.

• Jakość komunikacji.

• Uprawnienia bezpieczeństwa.

Nie każda różnica oznacza błąd. Nowy system może stosować ulepszone skalowanie lub prezentację alarmów.

Każdą różnicę należy mimo to wyjaśnić i zatwierdzić.

Starsze stacje powinny pozostać możliwe do przywrócenia do czasu, aż nowy interfejs HMI przejdzie obserwowany test odbioru w zakładzie oraz uzgodniony okres eksploatacji.

Wybór właściwej ścieżki migracji

Wybierz emulację Alpha, gdy:

Istniejąca aplikacja Symphony musi pozostać niezmieniona. Kod źródłowy jest niedostępny. Grafika operatorska jest złożona. Należy ograniczyć ponowne szkolenia do minimum. Interfejs komunikacyjny Bailey może być obsługiwany przez architekturę emulatora.

Wybierz migrację OpenVMS x86, gdy:

Wymagane aplikacje są dostępne dla architektury x86-64 lub można je przebudować. Kod źródłowy i wiedza inżynierska są nadal dostępne. Organizacja chce zachować OpenVMS, przechodząc jednocześnie do obsługiwanego środowiska x86.

Wybierz zmianę platformy na OPC, gdy:

Sterownik INFI 90 i warstwy wejścia/wyjścia pozostają niezawodne. Organizacja chce nowoczesnej platformy HMI. Dostępne są zasoby inżynierskie umożliwiające odtworzenie i walidację ekranów, alarmów, tagów oraz logiki poleceń.

Wybierz ścieżkę rozwoju ABB, gdy:

Organizacja chce szerszego programu modernizacji wspieranego przez dostawcę. Przyszłe etapy mogą obejmować systemy operatorskie, narzędzia inżynierskie, interfejsy sieciowe, sterowniki i moduły wejścia/wyjścia.

Wybierz niestandardowy interfejs HMI, gdy:

Organizacja ma wyspecjalizowane wymagania i może zapewnić długoterminowy rozwój oprogramowania, testowanie, cyberbezpieczeństwo oraz utrzymanie w całym cyklu życia.

Tymczasowo zachowaj istniejący system, gdy:

Interfejsy migracji pozostają niejasne. Kopie zapasowe są niekompletne. Kwestia licencjonowania pozostaje nierozstrzygnięta. Bazy danych tagów są niedostępne. Testy stanowiskowe nie pozwalają jeszcze odtworzyć ścieżki komunikacji Bailey.

Praktyczny etapowy plan modernizacji

Faza 1: Zachowaj istniejące środowisko.

Utwórz zweryfikowane kopie obrazów każdej stacji AlphaStation. Zapisz informacje o sprzęcie, oprogramowaniu, sieci, licencjonowaniu i uruchamianiu. W miarę możliwości przetestuj odtwarzanie.

Faza 2: Zidentyfikuj architekturę komunikacji.

Dokładnie udokumentuj sposób komunikacji każdej stacji Symphony z INFI 90. Potwierdź, czy interfejs można emulować lub zastąpić obsługiwanym serwerem.

Faza 3: Zbuduj prototyp weryfikacyjny.

Przetestuj jedną sklonowaną stację na emulatorze Alpha lub podłącz jeden serwer OPC do reprezentatywnego węzła Bailey.

Faza 4: Utwórz główny rejestr tagów.

Uzgodnij tagi sterowników, identyfikatory elementów OPC, jednostki inżynierskie, polecenia, alarmy i sposób wykorzystywania ekranów.

Faza 5: Odtwórz reprezentatywne ekrany.

Wybierz kilka ekranów zawierających różne wymagania dotyczące animacji, alarmów, poleceń i trendów.

Faza 6: Zakończ akceptację stanowiskową.

Przetestuj pełne ładowanie tagów, awarie komunikacji, ponowne uruchamianie serwera, nagłe serie alarmów, działanie poleceń i odtwarzanie kopii zapasowej.

Faza 7: Wdróż rozwiązanie równolegle.

Uruchamiaj nowe i stare interfejsy HMI jednocześnie. Porównuj wartości i reakcje operatorów.

Faza 8: Przeprowadź przełączenie w obecności świadków.

Stosuj zatwierdzoną procedurę testową. Zachowaj stacje AlphaStation jako rozwiązanie awaryjne.

Faza 9: Stopniowo wycofuj starszy sprzęt.

Nie niszcz oryginalnych obrazów, rekordów konfiguracji, licencji ani sprzętu do czasu zakończenia długoterminowej akceptacji.

Najczęściej zadawane pytania

Czy dysk stacji AlphaStation z OpenVMS można bezpośrednio sklonować na nowoczesny komputer?

Nie. Obraz zawiera kod maszynowy Alpha i wymaga sprzętu zgodnego z architekturą Alpha. Nowoczesny komputer x86 nie może uruchomić go bezpośrednio. Obraz należy odtworzyć na zgodnym sprzęcie Alpha lub w emulatorze Alpha.

Czy VMware lub VirtualBox mogą uruchomić OpenVMS?

Mogą uruchamiać obsługiwane wydania OpenVMS x86-64. Nie konwertują starej instalacji OpenVMS Alpha na aplikację x86. OpenVMS Alpha wymaga emulacji procesora Alpha.

Czy można zachować oryginalne wyświetlacze Symphony?

Zwykle można je zachować, gdy kompletne środowisko Alpha działa w zgodnym emulatorze. Przy przenoszeniu na inną platformę HMI zazwyczaj wymagają ręcznego odtworzenia.

Czy serwer OPC automatycznie eksportuje każdy tag Bailey?

Niekoniecznie. Przeglądanie OPC może zapewnić użyteczną przestrzeń nazw, ale konfiguracja alarmów, powiązania ekranów, polecenia, opisy i metadane inżynieryjne mogą wymagać dodatkowego wyodrębnienia i uzgodnienia.

Czy GE CIMPLICITY jest jedynym zamiennikiem HMI?

Nie. Jest to jedna z możliwych platform i pojawia się w przykładzie wdrożenia przedstawionym w źródle. Ostateczny wybór powinien zależeć od obsługi komunikacji, redundancji, licencjonowania, cyberbezpieczeństwa, zasobów inżynieryjnych i wymagań operatorów.

Czy migracja z Alpha na Itanium nadal ma sens?

Może to być uzasadnione, gdy wymagane oprogramowanie jest dostępne wyłącznie dla systemów Integrity lub gdy istniejąca infrastruktura Integrity jest już obsługiwana. Zasadniczo jest to jednak ścieżka przejściowa, a nie najsilniejsza strategia długoterminowej modernizacji.

Czy sterowniki i moduły I/O INFI 90 mogą pozostać zainstalowane?

Tak, jeśli nadal są niezawodne, a wybrana architektura komunikacyjna je obsługuje. Modernizację HMI można przeprowadzić niezależnie od wymiany sterowników i modułów I/O.

Czy stare stacje AlphaStation należy usunąć natychmiast po przełączeniu?

Nie. Powinny pozostać dostępne jako przetestowane rozwiązanie awaryjne do czasu, aż nowe środowisko operatorskie przejdzie odbiór funkcjonalny, wydajnościowy i operacyjny.

Właściwe rozwiązanie zależy od tego, co należy zachować

Głównym błędem technicznym w wielu planach modernizacji starszych HMI jest traktowanie stacji operatorskiej jak zwykłego komputera PC.

AlphaStation z systemem OpenVMS Alpha i Bailey Symphony stanowi kompletne środowisko sprzętowe i programowe. Jego architektura procesora, system operacyjny, interfejsy komunikacyjne, pliki binarne aplikacji, licencje, grafika oraz połączenia z systemem sterowania są wzajemnie zależne.

Klon dysku zachowuje dane. Nie tłumaczy jednak tego środowiska na inną architekturę.

Emulacja Alpha zapewnia najbardziej bezpośrednią ścieżkę, gdy cała instalacja Symphony musi działać bez zmian.

OpenVMS x86-64 zapewnia nowoczesną ścieżkę systemu operacyjnego, gdy aplikacje można zmigrować lub przebudować.

Zmiana platformy OPC zapewnia praktyczną ścieżkę, gdy warstwa sterowania INFI 90 pozostaje wartościowa, ale warstwę operatorską należy zastąpić.

Ewolucja ABB Symphony Plus może zapewnić szerszą, etapową strategię, gdy organizacja chce zmodernizować system wykraczając poza HMI.

Ostateczna decyzja powinna opierać się na zweryfikowanej inwentaryzacji, analizie interfejsów komunikacyjnych, przeglądzie licencji, weryfikacji koncepcji, testach stanowiskowych oraz przeprowadzonym odbiorze operacyjnym.

Nie istnieje migracja bez nakładu pracy. Istnieje jednak kilka kontrolowanych ścieżek migracji, które mogą chronić dotychczasowe inwestycje w system sterowania procesem, jednocześnie eliminując zależność od starzejącego się sprzętu AlphaStation.