Модернизация интерфейсов HMI Bailey INFI 90 Symphony на OpenVMS Alpha

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

Многие системы Bailey INFI 90 продолжают надёжно работать спустя десятилетия после первоначальной установки. Их контроллеры, коммуникационные модули, оконечные устройства и полевые модули ввода-вывода по-прежнему могут выполнять необходимые функции управления.

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

Операторские станции могут зависеть от устаревающего оборудования AlphaStation, неподдерживаемых графических адаптеров, устаревших устройств хранения данных и старых программных сред OpenVMS Alpha. Запасные части становится трудно достать, а опытных инженеров по OpenVMS и Bailey Symphony — всё сложнее найти.

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

Цель не обязательно заключается в замене всей DCS. Более практичная цель — устранить зависимость от устаревающего оборудования AlphaStation, сохранив стабильные контроллеры, полевую проводку, модули ввода-вывода, логику управления и производственные операции.

Это различие меняет стратегию модернизации.

Проект в первую очередь представляет собой миграцию интерфейса оператора и вычислительной платформы. Он становится полноценной миграцией 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, но представляет OpenVMS виртуальную систему Alpha. Исходные операционная система и приложения продолжают видеть аппаратную среду, совместимую с 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 или проприетарные службы.

• Параметры последовательных портов, если применимо.

• Любые внешние лицензионные ключи или аппаратные ключи защиты.

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

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

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

Поставщик эмулятора может поддерживать распространённые устройства Alpha Ethernet и хранения данных. Однако это автоматически не подтверждает поддержку каждого проприетарного интерфейса Bailey.

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

Поэтому проект должен включать стендовые испытания с использованием клонированной станции и доступом к репрезентативной сети Bailey.

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

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

OpenVMS x86-64 — это другой путь миграции

Современная OpenVMS доступна для архитектуры x86-64. Она может работать в поддерживаемых виртуализированных средах на современных серверах.

Это создаёт дополнительный вариант миграции, недоступный во время многих более ранних обсуждений модернизации INFI 90.

Однако OpenVMS x86-64 не запускает напрямую двоичные файлы OpenVMS Alpha так, как будто это нативные приложения x86.

Необходимо перенести среду приложения.

Исходный код может потребоваться перенести, проверить, перекомпилировать, скомпилировать в единый модуль и протестировать для x86-64. Сторонние библиотеки и дополнительные продукты также должны быть доступны для целевой версии.

Главный вопрос заключается в том, существует ли версия установленного программного обеспечения Bailey Symphony для OpenVMS x86, совместимая с 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 может сохранить отдельные части установленной архитектуры управления и ввода-вывода, одновременно внедряя более новые операторские, инженерные, сетевые компоненты, контроллеры или модули ввода-вывода.

Этот вариант может быть привлекательным, если организация хочет получить поддерживаемую поставщиком стратегию жизненного цикла, а не независимую замену HMI.

Сначала проект может модернизировать операторскую среду. Контроллеры и модули ввода-вывода могут оставаться в эксплуатации, пока их жизненный цикл или эксплуатационная ценность не оправдают замену.

На последующих этапах можно заняться связью, контроллерами, инженерными инструментами и полевыми интерфейсами.

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

Системы Bailey INFI 90, INFI 90 OPEN, Network 90, Harmony, Symphony и Symphony Plus не используют одинаковые интерфейсы.

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

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

Эта внутренняя ссылка актуальна, поскольку проекты модернизации часто требуют сохранения старой системы в рабочем состоянии на этапах проектирования, тестирования и поэтапного переключения.

Наличие подходящих резервных контроллеров, модулей связи, источников питания и модулей ввода-вывода может снизить риски в период перехода.

Пользовательская или HMI с открытым исходным кодом возможна, но требует ответственности за сопровождение

Пользовательскую HMI можно разработать с использованием фреймворков с открытым исходным кодом или коммерческих программных фреймворков.

В исходных материалах упоминается сервер на базе VMS с современным клиентом на основе Qt. Архитектуры такого типа могут разделять подключение к данным на стороне сервера и операторский клиент.

Этот вариант обеспечивает гибкость и позволяет избежать зависимости от одного поставщика HMI.

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

Организация должна владеть следующими компонентами или обеспечивать их сопровождение:

• Сервер связи.

• База данных тегов.

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

• Графический фреймворк.

• Обработка аварийных сигналов.

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

• Аутентификация пользователей.

• Обновления кибербезопасности.

• Развёртывание и контроль версий.

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

Qt, Python, C++, веб-технологии и другие фреймворки позволяют создавать функциональные промышленные интерфейсы. Сложность заключается не в отрисовке мнемосхемы процесса.

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

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

Лицензирование может определить, является ли технический вариант практически реализуемым

Устаревшее промышленное программное обеспечение часто использует механизмы лицензирования, привязанные к идентификаторам оборудования, Ethernet-адресам, базам данных лицензий, электронным ключам или ключам авторизации, выданным поставщиком.

Клонированная система может корректно загрузиться, но отказаться запускать приложение Symphony из-за изменения идентификатора виртуального оборудования.

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

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

• Лицензии прикладного программного обеспечения Bailey Symphony.

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

• Лицензии на сеть и обмен данными.

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

• Лицензии HMI и на количество точек OPC.

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

• Возможности резервирования.

• Лицензии инженерных клиентов.

• Лицензии клиентов Runtime.

До выбора конечной платформы следует получить письменное подтверждение.

Техническая совместимость без доступности необходимых лицензий не создаёт решение, готовое к внедрению.

Кибербезопасность должна быть заложена в проект замены

Старые системы 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 и уровни ввода-вывода остаются надежными. Организация хочет современную платформу HMI. Имеются инженерные ресурсы для воссоздания и проверки дисплеев, аварийных сигналов, тегов и логики команд.

Выберите путь развития ABB, если:

Организация хочет более масштабную программу модернизации с поддержкой поставщика. Будущие этапы могут включать операторские системы, инженерные инструменты, сетевые интерфейсы, контроллеры и устройства ввода-вывода.

Выберите заказную 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?

Да, если они остаются надежными, а выбранная архитектура связи поддерживает их. Модернизацию HMI можно выполнить отдельно от замены контроллеров и модулей ввода-вывода.

Следует ли немедленно убрать старые AlphaStation после переключения?

Нет. Их следует оставить доступными в качестве протестированного резервного варианта до тех пор, пока новая операторская среда не пройдет функциональную, эксплуатационную и приемочную проверку.

Правильное решение зависит от того, что необходимо сохранить

Главная техническая ошибка многих планов модернизации устаревших HMI — рассматривать операторскую станцию как обычный ПК.

AlphaStation под управлением OpenVMS Alpha и Bailey Symphony представляет собой целостную аппаратно-программную среду. Архитектура процессора, операционная система, интерфейсы связи, исполняемые файлы приложений, лицензии, графика и соединения с системой управления взаимозависимы.

Клонирование диска сохраняет данные. Оно не переводит эту среду на другую архитектуру.

Эмуляция Alpha обеспечивает наиболее прямой путь, когда необходимо сохранить всю установку Symphony без изменений.

OpenVMS x86-64 предоставляет современный путь перехода на новую операционную систему, когда приложения можно перенести или пересобрать.

Перенос на новую платформу OPC — практичный путь, когда уровень управления INFI 90 по-прежнему ценен, но операторский уровень необходимо заменить.

Развитие ABB Symphony Plus может обеспечить более широкую поэтапную стратегию, если организация хочет модернизировать систему не только на уровне HMI.

Окончательное решение следует принимать после проверки инвентаризации, изучения интерфейсов связи, проверки лицензий, создания прототипа, стендовых испытаний и приемки работы под наблюдением.

Не существует замены, не требующей никаких усилий. Однако есть несколько контролируемых путей миграции, которые позволяют сохранить существующие инвестиции в систему управления технологическим процессом и одновременно отказаться от зависимости от устаревающего оборудования AlphaStation.