Модернизиране на HMI интерфейсите на Bailey INFI 90 Symphony, работещи под OpenVMS Alpha

Модернизиране на HMI без замяна на цялата система INFI 90

Много системи Bailey INFI 90 продължават да работят надеждно десетилетия след първоначалното си инсталиране. Техните контролери, комуникационни модули, терминиращи устройства и полеви I/O може все още да изпълняват необходимите функции за управление.

Най-неотложният проблем, свързан с жизнения цикъл, често се намира над слоя на контролерите.

Операторските станции може да зависят от остарял хардуер AlphaStation, неподдържани графични адаптери, остарели устройства за съхранение и стари софтуерни среди OpenVMS Alpha. Резервните части стават все по-трудни за намиране, а опитните инженери по OpenVMS и Bailey Symphony са все по-малко достъпни.

Разглежданият тук пример включва четири работни станции AlphaStation 255. Всяка станция работи с OpenVMS Alpha и хоства функции на операторския интерфейс Bailey Symphony за разпределена система за управление Bailey INFI 90.

Целта не е непременно да се замени целият DCS. По-практична цел е да се премахне зависимостта от остарелия хардуер AlphaStation, като същевременно се запазят стабилните контролери, полевото окабеляване, I/O модулите, управляващата логика и технологичните операции.

Това различие променя стратегията за модернизация.

Проектът е предимно миграция на операторския интерфейс и изчислителната платформа. Той се превръща в пълна миграция на DCS едва когато жизненият цикъл на контролерите, изискванията за киберсигурност, производствените цели или условията за поддръжка оправдават замяната на долните слоеве за управление.

Съществуват няколко възможни подхода за модернизация. Те обаче запазват различни части от съществуващата система.

Емулаторът на Alpha може да запази почти цялата софтуерна среда. Миграцията към OpenVMS x86 запазва семейството на операционната система, но изисква миграция на приложенията. Замяната на HMI, базирана на OPC, запазва слоя на контролерите, като същевременно изгражда наново операторския интерфейс. Стратегията за развитие към ABB може поетапно да модернизира по-широката архитектура Symphony.

Нито един подход не бива да се описва като обикновена замяна с компютър.

Фигура 1. Три основни подхода за модернизация могат да запазят различни части от направените инвестиции в Bailey INFI 90 и Symphony.

Защо клонирането на диска на AlphaStation не е достатъчно

Клонирането на диска е полезно за запазване на инсталирана среда OpenVMS Alpha. То може да съхрани операционната система, файловете на приложенията, конфигурацията на устройствата, потребителските акаунти, софтуера Bailey, базите данни, графиките и специфичните за обекта настройки.

Клонирането на диск обаче не преобразува софтуера за Alpha в софтуер за x86.

Клонираната операционна система все още съдържа инструкции за процесори Alpha. Нейното ядро, зареждащата програма, системните библиотеки, приложенията и хардуерните драйвери са създадени за архитектурата Alpha.

Стандартният съвременен компютър използва процесор x86-64. Той също така предоставя различни контролери за съхранение, мрежови устройства, структури за прекъсвания, графичен хардуер, интерфейси за фърмуер и периферни шини.

VMware, VirtualBox, Hyper-V и конвенционалните x86 хипервайзори виртуализират x86-съвместим хардуер. Те обикновено не превеждат инструкциите на Alpha процесора в x86 инструкции.

Следователно поставянето на образ на диск с OpenVMS Alpha в обикновена x86 виртуална машина не прави този образ стартиращ.

Виртуалната машина може да предоставя виртуален диск, виртуален мрежов адаптер и виртуално графично устройство. OpenVMS Alpha все пак очаква Alpha процесор и поддържани устройства от ерата на Alpha.

Затова тези две понятия трябва да се разграничават:

Виртуализацията обикновено предоставя виртуален хардуер, използващ същата процесорна архитектура като хост системата.

Емулацията на различна архитектура възпроизвежда друг процесор и хардуерна среда чрез софтуер.

OpenVMS Alpha изисква втория подход, когато оригиналните Alpha двоични файлове и операционната система трябва да останат непроменени.

Следователно клонирането на диска е приложимо в три ограничени ситуации.

Първият вариант е възстановяване върху същия модел AlphaStation със съвместими устройства за съхранение и периферни устройства.

Вторият вариант е възстановяване върху друга поддържана Alpha система след извършване на необходимите промени по устройствата и конфигурацията.

Третият вариант е възстановяване в емулатор на Alpha, който възпроизвежда съвместима среда на AlphaServer или AlphaStation.

Самото клониране не решава архитектурния проблем. Целевата среда все пак трябва да разбира и изпълнява машинни инструкции на Alpha.

Емулацията на Alpha запазва най-голямата част от съществуващата инвестиция

Емулацията на Alpha обикновено е най-малко disruptive пътят, когато съществуващият софтуер Symphony трябва да продължи да работи без промени в изходния код.

Емулаторът на Alpha работи върху съвременен x86 хардуер, но представя виртуална Alpha система пред OpenVMS. Оригиналната операционна система и приложенията продължават да виждат хардуерна среда, съвместима с Alpha.

Продукти като CHARON-AXP са предназначени за тази цел. Емулаторът заменя физическия Alpha процесор, архитектурата на паметта, контролерите за съхранение, Ethernet адаптерите и другите поддържани устройства със софтуерно дефинирани еквиваленти.

x86 сървърът изпълнява Windows или Linux като хост среда. Емулаторът на Alpha работи над тази хост система. След това OpenVMS Alpha работи вътре в емулираната Alpha система.

Този подход се различава от пренасянето на OpenVMS към x86.

Оригиналната инсталация на OpenVMS Alpha остава Alpha инсталация. Двоичните файлове на Bailey Symphony остават Alpha двоични файлове. Емулаторът превежда или възпроизвежда необходимото поведение на Alpha хардуера.

Това може да запази:

• Инсталираната операционна система OpenVMS Alpha.

• Съществуващи приложения на Bailey Symphony.

• Графики за операторите и бази данни за дисплеите.

• Конфигурации на алармите и исторически файлове.

• Потребителските акаунти и командните процедури.

• Съществуващите специфични за обекта помощни програми.

• Интерфейсите на приложението, които зависят от средата Alpha.

• Работните процеси на операторите, които иначе биха изисквали повторно обучение.

Практическата миграция обикновено включва създаване на проверен образ или резервно копие на оригиналните дискове на Alpha. Тези данни се възстановяват във виртуални дискови контейнери, използвани от емулатора.

Конфигурацията на емулатора трябва да възпроизвежда подходящи характеристики на процесора, паметта, диска, мрежата и периферните устройства. Екипът може също да трябва да свърже физическите серийни портове или мрежовите интерфейси чрез хост системата.

Емулацията на Alpha може значително да намали зависимостта от остарял физически хардуер. Тя може също да улесни архивирането, тъй като файловете на виртуалните дискове могат да се копират с помощта на съвременна инфраструктура за съхранение.

Въпреки това терминът „нулева промяна“ трябва да се използва предпазливо.

Кодът на приложението може да остане непроменен, но средата все пак изисква инженерна работа. Съответствията на устройствата трябва да бъдат проверени. Мрежовите интерфейси трябва да бъдат конфигурирани. Лицензите за OpenVMS и лицензите на приложението трябва да бъдат прегледани.

Емулаторът трябва да бъде тестван и с комуникационния интерфейс на Bailey, използван на обекта.

Едно общо приложение за OpenVMS може да работи правилно, докато специализиран DCS интерфейсът се повреди, защото зависи от конкретен мрежов адаптер, шинен интерфейс, сериен модул или времево поведение.

Следователно точната конфигурация на AlphaStation 255 трябва да бъде инвентаризирана, преди да се избере профил на емулатора.

Интерфейсът за комуникация на Bailey е критичният тест за емулацията

Най-важният въпрос при емулацията не е дали OpenVMS достига до подкана за вход.

Важният въпрос е дали емулираната станция комуникира правилно със системата Bailey INFI 90 при пълни работни условия.

Интерфейсът може да зависи от Ethernet, серийна комуникация, мрежов интерфейс на Bailey или специализиран комуникационен хардуер. Конфигурациите на обектите могат да се различават значително.

Преди да се вземе решение за емулация на Alpha, инженерите трябва да документират:

• Физическият мрежов интерфейс, инсталиран във всяка AlphaStation.

• Комуникационният протокол, използван между Symphony и INFI 90.

• Имената на устройствата, зададени в OpenVMS.

• Мрежовите адреси и дефинициите на възлите.

• Необходимите услуги DECnet, TCP/IP, LAT или патентовани услуги.

• Настройките на серийните портове, когато е приложимо.

• Всички външни лицензионни ключове или хардуерни донгъли.

• Поведението при резервиране и превключване между операторските станции.

• Изискванията за синхронизация на времето.

• Графичните функции и функциите на клавиатурата, използвани от операторите.

Доставчикът на емулатор може да поддържа стандартни Ethernet и устройства за съхранение Alpha. Това не потвърждава автоматично поддръжката на всеки патентован интерфейс на Bailey.

Ако съществуващият HMI зависи от специализиран физически адаптер, който не може да бъде виртуализиран, използването на емулатор може да изисква алтернативен комуникационен шлюз.

Затова проектът трябва да включва стендови тест с клонирана станция и достъп до представителна мрежа Bailey.

Тестът трябва да включва повече от статично четене на тагове. Операторите трябва да проверят стойностите в реално време, командите, алармите, потвърждаването, трендовете, навигацията в екраните, печатането, обработката на събития и възстановяването на станцията.

Производителността също трябва да бъде тествана по време на пикове на алармите и висока активност при обновяване на таговете.

OpenVMS x86-64 е различен маршрут за миграция

Съвременният OpenVMS е наличен за архитектурата x86-64. Той може да работи в поддържани виртуализирани среди на съвременни сървъри.

Това създава допълнителна опция за миграция, която не е била налична по време на много от по-ранните обсъждания за модернизация на INFI 90.

OpenVMS x86-64 обаче не изпълнява директно двоични файлове на OpenVMS Alpha така, сякаш са нативни x86 приложения.

Средата на приложението трябва да бъде мигрирана.

Изходният код може да трябва да бъде прехвърлен, прегледан, компилиран наново, свързан и тестван за x86-64. Библиотеките на трети страни и допълнителните продукти също трябва да са налични за целевата версия.

Основният въпрос е дали инсталираният софтуер Bailey Symphony има версия на OpenVMS, съвместима с x86.

Ако производителят на софтуера никога не е пускал това приложение за OpenVMS x86-64, самостоятелното преместване на операционната система не запазва HMI.

Програмите, разработени от потребителя, може да са преносими, когато изходният им код и средата за компилиране са налични. Затворените комерсиални приложения обикновено не могат да бъдат изградени наново без поддръжка от доставчика.

Този подход все пак може да е практичен за персонализирани сървъри за данни, архиватори, помощни програми, отчети и интеграционни приложения, които работят наред с HMI на Symphony.

По-малко вероятно е да запази старата собствена операторска среда Symphony без поддържана версия на приложението.

Оценката на миграцията към OpenVMS x86 трябва да установи:

• Всеки инсталиран изпълним файл и всеки допълнителен продукт.

• Наличен изходен код и процедури за компилиране.

• Зависимости от компилатори и среди за изпълнение.

• Продукти за бази данни и файлови формати.

• Собствени комуникационни библиотеки.

• Зависимости от графична система или прозоречна система.

• Наличност на лицензи за x86-64.

• Необходими промени, породени от различията в архитектурите.

• Предположения за производителността и времето.

Този подход има по-голям дългосрочен потенциал от преминаването от Alpha към друга спрена хардуерна архитектура. Той може да прехвърли съвместими работни натоварвания на OpenVMS към поддържана инфраструктура за виртуализация на x86.

Въпреки това тя трябва да бъде описана като проект за миграция на приложения, а не като проект за клониране на дискове.

Защо миграцията към Itanium обикновено е преходна опция

OpenVMS беше пуснат и за сървъри HPE Integrity, използващи архитектурата Itanium.

Съществуват инструменти за миграция и инженерни методи за преместване на някои приложения на Alpha към OpenVMS Integrity. Това някога осигуряваше поддържан път за отказ от остаряващия хардуер Alpha.

Днес обаче самият хардуер Itanium вече е наследена платформа.

Преминаването от Alpha към Integrity може да премахне една зависимост от остарял хардуер, но да създаде друга. Подходящите сървъри, резервни части, интерфейси за съхранение и специализирани експертни умения ще продължат да стават все по-недостъпни.

Itanium все още може да бъде актуален, когато обектът вече разполага с поддържана инфраструктура Integrity. Той може да бъде актуален и когато даден необходим многослоен продукт съществува за Integrity, но не и за x86-64.

За нов проект за модернизация това по принцип трябва да се оценява като междинен маршрут за съвместимост.

Бизнес обосновката трябва да обясни защо преминаването към Integrity е за предпочитане пред емулация на Alpha, миграция на OpenVMS x86 или преплатформиране на HMI.

Преплатформирането чрез OPC запазва контролния слой

Преплатформирането чрез OPC заменя слоя на операторския интерфейс, като запазва съществуващите контролери INFI 90 и полевите входно-изходни модули.

Комуникационен сървър се свързва към системата Bailey и предоставя технологичните тагове на съвременна HMI или SCADA платформа.

Новият HMI управлява екраните, алармите, трендовете, сигурността, операторските команди, отчетите и услугите на работните станции.

Този подход премахва зависимостта от оригиналното операторско приложение Symphony. Той също така избягва необходимостта от използване на OpenVMS Alpha на новите операторски станции.

Архитектурата обикновено включва:

• Съществуващи контролери и входно-изходни модули Bailey INFI 90.

• Съвместим комуникационен интерфейс Bailey.

• OPC DA, OPC UA или специфичен за доставчика сървър за данни.

• Съвременна HMI или SCADA платформа.

• Операторски и инженерни работни станции.

• Незадължителни услуги за архивиране на данни, отчетност и анализ на аларми.

Полеви пример, посочен в изходните материали, използва OPC сървър RoviSys с GE CIMPLICITY. Докладваната система е работила успешно, но проектът е изисквал възстановяване на операторските екрани и логиката за анимация.

Този пример не бива да се тълкува като автоматична препоръка за продукт за всяка инсталация INFI 90.

Избраният сървър трябва да поддържа конкретната мрежа Bailey, комуникационните модули, поколението на контролерите, броя на таговете, честотата на обновяване, изискванията за резервираност и командните функции на обекта.

Същото се отнася и за HMI платформата.

GE CIMPLICITY е една от възможните корпоративни HMI/SCADA платформи. Други системи също могат да бъдат подходящи, ако осигуряват необходимата OPC свързаност, графики, аларми, скриптове, резервираност, сигурност и поддръжка през жизнения цикъл.

Фигура 2. Миграцията, базирана на OPC, запазва контролния слой INFI 90, като заменя старата операторска среда Symphony.

OPC свързаността не преобразува съществуващите екрани

OPC сървърът осигурява свързаност за данни. Обикновено той не преобразува старите HMI екрани в нов HMI формат.

Оригиналните екрани на Symphony може да съдържат статични графики, динамични символи, промени в цветовете, числови стойности, стълбовидни графики, индикатори за аларми, навигационни бутони, командни контроли, трендове и шаблони за персонализирани функции.

Тези елементи трябва да бъдат пресъздадени в целевия HMI.

Простите екрани могат да бъдат прерисувани директно. Сложните екрани може да съдържат скрити скриптове или изрази, които не се виждат веднага.

Инженерите трябва да разбират как всеки анимиран обект получава и обработва данните си.

Символът на клапан може да не следва просто един изходен таг. Цветът и положението му може да зависят от обратната връзка за отворено и затворено положение, състоянието на командата, състоянието на блокировката, качеството на комуникацията и режима на оборудването.

Символът на двигател може да използва отделни тагове за команда за стартиране, обратна връзка за работа, състояние „спрян“, аварийно изключване, локално управление, състояние на техническо обслужване, разрешаващи условия и блокиране на алармата.

Следователно преместването само на видимата графика може да създаде HMI, който изглежда правилно, но функционира неправилно.

Екипът по миграцията трябва да документира функционалното значение зад всеки елемент на екрана.

Тази работа включва:

• Свързване на всеки динамичен обект с неговия източник на данни.

• Пресъздаване на изразите за анимация.

• Проверка на потвърждаването на командите и сигурността.

• Пресъздаване на навигацията и йерархиите на екраните.

• Пресъздаване на класовете и приоритетите на алармите.

• Потвърждаване на мерните единици и десетичната точност.

• Пресъздаване на исторически и реалновременни трендове.

• Тестване на състояния с невалидна, несигурна или прекъсната комуникация.

• Възпроизвеждане на операторските съобщения и указания.

• Замяна на неподдържаните шрифтове и символи.

Поради това усилието се определя от сложността на екраните, а не само от техния брой.

Съвременният HMI не трябва сляпо да копира всеки наследен екран

Ръчното пресъздаване създава възможност за подобряване на операторския интерфейс.

Графичните елементи на наследените HMI системи често използват ярки цветове за нормално работещо оборудване, плътни технологични диаграми, декоративни тръбопроводи и непоследователни индикации на аларми.

Тези конвенции може да са били разумни, когато е била разработена оригиналната система. Те невинаги са идеални за съвременните практики в контролната зала.

Проектът за модернизация трябва да прегледа:

• Йерархия на екраните.

• Видимост на алармите.

• Последователност на навигацията.

• Представяне на състоянието на оборудването.

• Използване на цветовете.

• Достъпност на трендовете.

• Изисквания за реакция на оператора.

• Разделителна способност на екрана и разположение на работното място.

• Достъпност и четливост.

Нормалните работни условия трябва да останат визуално ненатрапчиви. Ярките цветове трябва да обозначават ненормални състояния, изискващи внимание.

Операторите трябва да могат да преминават от общ преглед на инсталацията към засегнатия блок, лицевия панел на оборудването, тренда, историята на алармите и диагностичния екран без прекомерна навигация.

Прекомерното препроектиране обаче може да създаде друг риск.

Операторите може да са използвали оригиналните екрани в продължение на много години. Промяната на всеки символ, цвят и навигационен път в рамките на един и същ проект може да увеличи нуждата от обучение и риска при преминаването към новата система.

Балансираният подход запазва познатите взаимовръзки между процесите, като същевременно подобрява представянето на алармите и навигацията.

Извличането на тагове трябва да се разглежда като инженерна работна задача

Изходният материал допуска възможността за експортиране на данни за таговете на Bailey във формат CSV. Той не предоставя потвърдена универсална процедура.

Следователно не трябва да се приема, че една команда за експортиране ще създаде пълна и чиста база данни за HMI.

Възможните източници на информация за таговете включват:

• Конфигурационни бази данни на Symphony.

• Съществуващи дефиниции на екрани.

• Конфигурация на контролерите и инженерни записи.

• Бази данни на комуникационните сървъри на Bailey.

• Функции за преглеждане на OPC сървъра.

• Конфигурационни файлове на алармите.

• Исторически бази данни.

• Отпечатани или архивирани списъци с тагове.

• Инженерни електронни таблици от обекта.

Преглеждането на OPC може да осигури практична отправна точка, след като сървърът установи комуникация със системата Bailey.

То може да предоставя имена на тагове, идентификатори на елементи, описания, качество и текущи стойности. Някои сървъри поддържат и експортиране на прегледаното пространство от имена.

Въпреки това OPC пространството от имена може да не включва всички полета, необходими на новия HMI.

Приоритетите на алармите, инженерните граници, групирането по екрани, операторските бележки, сигурността на командите и връзките с оборудването може да се съхраняват на друго място.

Някои OPC сървъри предоставят тагове с генерирани имена, различни от оригиналните имена в Symphony.

Проектът трябва да създаде контролиран регистър на таговете, съдържащ най-малко:

• Оригинално име на тага.

• Ново име на HMI тага.

• Идентификатор на OPC елемента.

• Описание.

• Тип данни.

• Разрешение за четене или запис.

• Инженерни единици.

• Информация за мащабирането.

• Алармени граници и приоритет.

• Честота на обновяване.

• Свързан екран.

• Статус на валидирането.

• Резултат от теста.

Този регистър става записът за съгласуване между старата и новата система.

Броят на таговете не е единственото изискване към комуникацията

Успешният тест за преглеждане не доказва, че OPC архитектурата може да поддържа целия HMI.

Инженерите трябва да оценят броя на активните тагове, заявената честота на обновяване, честотата на промените, активността на алармите, командния трафик и резервирането на сървъра.

Една система може да съдържа десетки хиляди конфигурирани тагове. В даден момент само част от тях може да са активни на операторските екрани.

Сървърът и HMI трябва да бъдат тествани при реалистични условия.

Важните проверки на производителността включват:

• Необходимо време за отваряне на сложен екран.

• Забавяне между промяна на място и анимацията в HMI.

• Доставка на аларми при изблик на събития.

• Събиране на трендове с необходимата честота на дискретизация.

• Време за изпълнение на командата и получаване на обратна връзка.

• Възстановяване след прекъсване на мрежата.

• Превключване между резервирани сървъри.

• Поведение след рестартиране на контролера.

• Статус на качеството при комуникационен отказ.

• Натоварване на процесора, паметта и мрежата.

Командите изискват особено внимание.

Четенето на стойности чрез OPC може да е сравнително лесно. Безопасното записване на стойности изисква контрол на достъпа, проверка на командите, потвърждение на обратната връзка и правилно обработване на комуникационни откази.

Екипът трябва да тества всеки тип операторска команда, а не само един представителен таг.

ABB Symphony Plus предлага по-широк път за развитие

Подмяната на OPC не е единственият подход за инсталирана система Bailey.

ABB продължава да представя Symphony Plus като платформа за развитие на по-старите инсталации Bailey, INFI 90, Harmony Rack и Symphony.

Поетапната модернизация на ABB може да запази части от инсталираната архитектура за управление и I/O, като същевременно въведе по-нови операторски, инженерни, мрежови, контролерни или I/O компоненти.

Този подход може да бъде привлекателен, когато организацията желае стратегия за поддръжка през жизнения цикъл, подкрепяна от доставчика, вместо независима подмяна на HMI.

Проектът може първо да модернизира операторската среда. Контролерите и I/O могат да останат в експлоатация, докато техният жизнен цикъл или оперативната им стойност не оправдаят подмяната.

По-късните етапи могат да обхванат комуникациите, контролерите, инженерните инструменти и полевите интерфейси.

Точната архитектура на миграцията зависи от инсталираното поколение на системата.

Инсталациите Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony и Symphony Plus не използват непременно едни и същи интерфейси.

Имената на модулите и мрежовата терминология трябва да бъдат проверени по чертежите на обекта и описите на хардуера.

Организациите, които поддържат съществуващия слой за управление, могат също да прегледат наличните компоненти ABB Bailey INFI 90 и Network 90, когато планират резервното осигуряване, поддръжката през жизнения цикъл и поетапната модернизация.

Тази вътрешна връзка е релевантна, тъй като проектите за модернизация често изискват старата система да остане в експлоатация по време на инженерните дейности, тестването и поетапното преминаване.

Поддържането на подходящи резервни контролери, комуникационни модули, захранващи блокове и I/O модули може да намали риска по време на този преход.

Персонализиран HMI или HMI с отворен код е възможен, но изисква поемане на отговорност

Персонализиран HMI може да бъде разработен с помощта на софтуерни рамки с отворен код или търговски софтуерни рамки.

В изходния материал се споменава сървър, резидиращ във VMS, с модерен клиент, базиран на Qt. Архитектурите от този тип могат да разделят връзката с данните от страна на сървъра от операторския клиент.

Този подход може да осигури гъвкавост и да избегне зависимостта от един доставчик на HMI.

Това може да се превърне и в дългосрочен ангажимент за разработка на софтуер.

Организацията трябва да притежава или поддържа:

• Комуникационният сървър.

• База данни с тагове.

• Клиентско приложение.

• Графична рамка.

• Обработка на аларми.

• Интеграция с архиватор.

• Удостоверяване на потребителите.

• Актуализации за киберсигурност.

• Внедряване и контрол на версиите.

• Документация и обучение.

Qt, Python, C++, уеб технологии или други рамки могат да създадат функционални индустриални интерфейси. Трудността не е в изчертаването на технологична графика.

Трудността е да се създаде надеждна операторска система, която да работи коректно при комуникационни откази, рестартирания на сървъра, лавини от аларми, промени в потребителите и нештатни условия в инсталацията.

Персонализирана платформа трябва да се избира само когато организацията разполага с устойчив инженерен екип или надежден дългосрочен интегратор.

Лицензирането може да определи дали даден технически подход е практически приложим

Наследеният индустриален софтуер често използва лицензионни механизми, обвързани с хардуерни идентификатори, Ethernet адреси, лицензионни бази данни, хардуерни ключове или ключове за оторизация, издадени от доставчика.

Клонирана система може да се стартира правилно, но да откаже да стартира приложението Symphony, тъй като идентичността на виртуалния хардуер се е променила.

Инвентаризацията за миграцията трябва да включва:

• Лицензи за операционната система OpenVMS.

• Лицензи за приложенията Bailey Symphony.

• Лицензи за бази данни.

• Лицензи за мрежи и комуникации.

• Лицензи за емулатор.

• Лицензи за HMI и брой OPC точки.

• Лицензи за архиватор.

• Опции за резервираност.

• Лицензи за инженерни клиенти.

• Лицензи за клиенти за изпълнение.

Преди избора на окончателната платформа трябва да бъде получено писмено потвърждение.

Техническата съвместимост без налични законни лицензи не създава решение, готово за внедряване.

Киберсигурността трябва да бъде заложена в проекта за замяната

Старите системи AlphaStation често са били инсталирани преди съвременните практики за индустриална киберсигурност да се превърнат в стандарт.

Те могат да работят в изолирани мрежи с ограничен отдалечен достъп. Замяната им със сървъри с Windows, модерни SCADA клиенти, OPC сървъри и Ethernet инфраструктура променя повърхността за атаки.

Новата архитектура трябва да определи отделни зони за мрежите за управление, сървъри, инженеринг и предприятието.

Защитните стени трябва да разрешават само необходимите комуникационни пътища. Отдалеченият достъп трябва да използва управлявана автентикация и запис.

Акаунтите на операторите трябва да използват разрешения на базата на роли. Инженерните функции не трябва да са достъпни от всеки HMI клиент.

Достъпът за запис в OPC трябва да бъде ограничен до таговете и станциите, които го изискват.

Проектът трябва да разглежда и следното:

• Прилагане на пачове за операционната система.

• Антивирусна защита или контрол на приложенията.

• Архивиране и възстановяване.

• Синхронизация на времето.

• Регистриране на събитията по сигурността.

• Контрол на сменяемите носители.

• Отдалечена поддръжка от доставчика.

• Управление на сертификатите за OPC UA.

• Управление на жизнения цикъл на акаунтите.

Мерките за киберсигурност не трябва да възпрепятстват операторите да реагират по време на аварии в предприятието. Проектът трябва да балансира защитата с достъпността и детерминираното функциониране.

Миграцията трябва да започне с инвентаризация, основана на доказателства

Преди да изберат подход, инженерите трябва подробно да документират съществуващата система.

Инвентаризацията трябва да включва и четирите AlphaStation системи и да установи дали конфигурациите им са действително идентични.

Запишете:

• Моделът на AlphaStation и конфигурацията на процесора.

• Капацитет на паметта.

• Тип дискове и логически томове.

• Версия и ниво на пачовете на OpenVMS.

• Инсталирани версии на софтуера Bailey.

• Слоести продукти и бази данни.

• Графичен хардуер и разделителна способност на дисплея.

• Мрежови адаптери.

• Серийни интерфейси.

• Комуникационен хардуер Bailey.

• Имена и адреси на възлите.

• Процедури за команди при стартиране.

• Лицензионни файлове.

• Процедури за резервно копиране.

• Резервираност на операторските станции.

• Свързани принтери и външни устройства.

• Съхранение на исторически данни и данни за алармите.

Екипът трябва също да събере екранни снимки на всеки дисплей. Динамичните състояния трябва да бъдат заснемани, когато е възможно.

Документирайте нормално, спряно, работещо, алармирано, блокирано, локално, ръчно, автоматично и състояние на отказала комуникация.

Това доказателство е от съществено значение при тестването на новите екрани.

Стендовата система е задължителна

Никой път за модернизация не трябва да се тества за първи път в работещата производствена система.

Стендовата среда трябва да възпроизвежда достатъчна част от инсталираната архитектура, за да валидира комуникацията и операторските функции.

При проект с емулатор стендът трябва да съдържа клонирана OpenVMS Alpha среда и предложената конфигурация на емулатора.

При OPC проект той трябва да включва избрания комуникационен сървър, HMI софтуера, представителни графики и достъп до безопасен тестов възел Bailey или симулиран източник на данни.

Стендовият тест трябва да провери:

• Стартиране на системата и приложението.

• Комуникация със системата Bailey.

• Общ брой достъпни тагове.

• Операции за четене и запис.

• Мащабиране на таговете и инженерни единици.

• Генериране и потвърждаване на аларми.

• Събиране на трендове.

• Анимация на дисплея.

• Сигурност на командите.

• Функции за печат и отчети.

• Поведение при рестартиране на сървъра.

• Поведение при отказ на мрежата.

• Излишност и аварийно превключване.

• Възстановяване от резервно копие.

• Време за реакция на оператора.

Резултатите от тестовете трябва да бъдат удостоверени от представители на оперативния персонал, инженерите по управление, поддръжката и киберсигурността.

Паралелната експлоатация намалява риска при превключването

Оригиналните AlphaStation трябва да останат налични по време на първоначалното внедряване на заместващата система.

Новият HMI може да работи паралелно, докато инженерите сравняват стойности, аларми, трендове и команди.

Паралелната експлоатация позволява несъответствията да бъдат идентифицирани, преди старата станция да бъде премахната.

Екипът трябва да съгласува:

• Показани стойности на процеса.

• Индикации за състоянието.

• Приоритети на алармите.

• Времеви отпечатъци на алармите.

• Резултати от командите.

• Стойности на трендовете.

• Режим на оборудването.

• Качество на комуникацията.

• Разрешения за достъп.

Не всяка разлика представлява грешка. Новата система може да използва подобрено мащабиране или представяне на алармите.

Всяка разлика все пак трябва да бъде обяснена и одобрена.

Старите станции трябва да останат възстановими, докато новият HMI не премине наблюдаван приемателен тест на място и договорен оперативен период.

Избор на правилния път за миграция

Изберете емулация на Alpha, когато:

Съществуващото приложение Symphony трябва да остане непроменено. Изходният код не е наличен. Операторските графики са сложни. Преквалификацията трябва да бъде сведена до минимум. Комуникационният интерфейс Bailey може да бъде поддържан от архитектурата на емулатора.

Изберете миграция към OpenVMS x86, когато:

Необходимите приложения са налични за x86-64 или могат да бъдат възстановени. Изходният код и инженерните знания са все още налични. Организацията иска да запази OpenVMS, като премине към поддържана x86 среда.

Изберете преход към OPC платформа, когато:

Контролерът INFI 90 и слоевете за I/O остават надеждни. Организацията иска модерна HMI платформа. Налични са инженерни ресурси за възстановяване и валидиране на дисплеи, аларми, тагове и логика на командите.

Изберете еволюционен път на ABB, когато:

Организацията иска по-широка програма за модернизация, поддържана от доставчик. Бъдещите фази могат да включват операторски системи, инженерни инструменти, мрежови интерфейси, контролери и I/O.

Изберете персонализиран HMI, когато:

Организацията има специализирани изисквания и може да поддържа дългосрочна разработка на софтуер, тестване, киберсигурност и поддръжка през целия жизнен цикъл.

Временно запазете съществуващата система, когато:

Интерфейсите за миграция остават неясни. Резервните копия са непълни. Лицензирането не е уредено. Базите данни с тагове не са налични. Стендовото тестване все още не може да възпроизведе комуникационния път на Bailey.

Практически поетапен план за модернизация

Фаза 1: Запазване на съществуващата среда.

Създайте проверени резервни образи на всяка AlphaStation. Запишете данните за хардуера, софтуера, мрежата, лицензирането и стартирането. Тествайте възстановяването, когато е възможно.

Фаза 2: Идентифициране на комуникационната архитектура.

Документирайте точно как всяка станция Symphony комуникира с INFI 90. Потвърдете дали интерфейсът може да бъде емулиран или заменен от поддържан сървър.

Фаза 3: Изграждане на доказателство за концепцията.

Тествайте една клонирана станция в емулатор на Alpha или свържете един OPC сървър към представителен възел Bailey.

Фаза 4: Създаване на главен списък с тегове.

Сверете теговете на контролерите, идентификаторите на OPC елементите, инженерните единици, командите, алармите и използването на дисплеите.

Фаза 5: Възстановяване на представителни дисплеи.

Изберете няколко екрана с различни изисквания за анимация, аларми, команди и трендове.

Фаза 6: Приключване на приемането на стенд.

Тествайте пълното зареждане на теговете, отказ на комуникацията, рестартиране на сървъра, пикове от аларми, поведението на командите и възстановяването от резервно копие.

Фаза 7: Паралелно внедряване.

Експлоатирайте новите и старите HMI системи едновременно. Сравнявайте стойностите и реакциите на операторите.

Фаза 8: Извършване на контролирано превключване в присъствието на свидетели.

Използвайте одобрена процедура за тестване. Дръжте AlphaStation системите на разположение като резервен вариант.

Фаза 9: Постепенно извеждане от експлоатация на остарелия хардуер.

Не унищожавайте оригиналните образи, конфигурационни записи, лицензи или хардуер, докато дългосрочното приемане не приключи.

Често задавани въпроси

Може ли диск на OpenVMS AlphaStation да бъде клониран директно към съвременен компютър?

Не. Образът съдържа машинен код за Alpha и изисква хардуер, съвместим с Alpha. Съвременен x86 компютър не може да го стартира директно. Образът трябва да бъде възстановен върху съвместим хардуер Alpha или в емулатор на Alpha.

Могат ли VMware или VirtualBox да работят с OpenVMS?

Те могат да работят с поддържани версии на OpenVMS за x86-64. Те не преобразуват стара инсталация на OpenVMS Alpha в x86 приложение. OpenVMS Alpha изисква емулация на Alpha.

Могат ли оригиналните дисплеи Symphony да бъдат запазени?

Обикновено те могат да бъдат запазени, когато цялата Alpha среда работи под съвместим емулатор. При преминаване към друга HMI платформа обикновено се налага ръчното им пресъздаване.

OPC сървърът автоматично ли експортира всеки Bailey таг?

Не непременно. Преглеждането чрез OPC може да предостави полезно пространство от имена, но конфигурацията на алармите, взаимовръзките между екраните, командите, описанията и инженерните метаданни може да изискват допълнително извличане и съгласуване.

GE CIMPLICITY ли е единствената заместваща HMI система?

Не. Това е една възможна платформа и е посочена в предоставения с източника пример от практиката. Окончателният избор трябва да зависи от комуникационната поддръжка, резервирането, лицензирането, киберсигурността, инженерните ресурси и изискванията на операторите.

Има ли все още смисъл миграцията от Alpha към Itanium?

Това може да бъде оправдано, когато необходимият софтуер е наличен само за системи Integrity или когато съществуващата инфраструктура Integrity вече се поддържа. Като цяло това е преходен път, а не най-силната дългосрочна стратегия за модернизация.

Могат ли контролерите INFI 90 и I/O да останат инсталирани?

Да, когато останат надеждни и избраната комуникационна архитектура ги поддържа. Модернизирането на HMI може да бъде завършено отделно от подмяната на контролерите и I/O.

Трябва ли старите AlphaStation да бъдат премахнати веднага след превключването?

Не. Те трябва да останат налични като тестван резервен вариант, докато новата операторска среда не премине функционално, експлоатационно и оперативно приемане.

Правилното решение зависи от това какво трябва да бъде запазено

Основната техническа грешка в много планове за модернизиране на наследени HMI системи е операторската станция да се третира като обикновен компютър.

AlphaStation с OpenVMS Alpha и Bailey Symphony представлява цялостна хардуерна и софтуерна среда. Нейната процесорна архитектура, операционна система, комуникационни интерфейси, програмни двоични файлове, лицензи, графика и връзки със системата за управление са взаимозависими.

Клонирането на диска запазва данните. То не преобразува тази среда за друга архитектура.

Емулацията на Alpha предоставя най-прекия път, когато цялата инсталация Symphony трябва да продължи да работи без промени.

OpenVMS x86-64 предоставя път към модерна операционна система, когато приложенията могат да бъдат мигрирани или изградени наново.

Преплатформирането към OPC предоставя практичен път, когато слоят за управление INFI 90 запазва стойността си, но операторският слой трябва да бъде заменен.

Еволюцията към ABB Symphony Plus може да осигури по-широка поетапна стратегия, когато организацията иска да модернизира системата отвъд HMI.

Окончателното решение трябва да се вземе след проверена инвентаризация, проучване на комуникационните интерфейси, преглед на лицензите, доказване на концепцията, стендов тест и приемане на работещата система в присъствието на заинтересованите страни.

Няма замяна без усилия. Съществуват обаче няколко контролирани пътя за миграция, които могат да защитят съществуващите инвестиции в управлението на процесите, като същевременно премахнат зависимостта от остарелия хардуер AlphaStation.