Резервированный менеджер OPC (Exaquantum/ORM)
OpreX Эксплуатация и оптимизация активов (OpreX Asset Operations and Optimization)

Задача
При возникновении требования сбора технологических данных через протоколы OPC DA и OPC HDA с резервированных OPC серверов с целью минимизации потенциальных потерь данных, необходимо также учитывать следующие ограничения:

  • При использовании Exaopc-RD (резервируемый OPC-сервер Yokogawa), можно подключить до четырёх пар Exaopc к серверу Exaquantum
  • Ни имеется возможности серверов Exaquantum подключаться к другим парам резервируемых OPC-серверов, кроме Exaopc

Решение
Пакет Exaquantum/ORM (далее просто ‘ORM’) является решением по управлению резервированию OPC связи Yokogawa, позволяющим создавать одну или более пару резервирования каналов OPC DA и серверов HDA, подключаемых к одному серверу Exaquantum.

Выгоды

  • Повышает надёжность Exaquantum по сбору технологических данных
  • Помогает при сетевых сбоях и отказах оборудования
  • Поддерживает пять или более резервированных серверов Exaopc
  • Поддерживает резервированные пары других OPC-серверов, кроме Exaopc

Ключевые особенности

  • Поддержка ‘тёплого’ переключения между парами каналов OPC DA и HDA
  • Чтение несинхронизированных данных с пар OPC DA
  • Синхронизация записи данных с пар OPC DA
  • Считывание свойств пунктов OPC DA с поддерживаемых OPC-серверов
  • Синхронизированное считывание данных с OPC HDA с поддерживаемых OPC-серверов

Введение

Пакет ORM позволяет конфигурировать резервируемые пары OPC-серверов. В каждой паре один OPC-сервер назначается Основной, а другой – Резервный. Основной OPC-сервер передаёт технологические данные на сервер Exaquantum. Второй сервер, находящийся в режиме Резервный, подключён к серверу Exaquantum, с регистрацией всех тегов, но с неактивными группами.

При переходе текущего Основного OPC-сервера в состояние ‘недоступен’, пакет ORM переключит активные группы на второй, Резервный OPC-сервер, который сразу перейдёт в состояние - Основной.

Возможности

Данные OPC DA несинхронно считываются с OPC-сервера через стандартный механизм уведомления о cвязи групп OPC.

При потере связи сервера Exaquantum с обоими OPC-серверами (Основным и Резервным), пакет ORM, в момент, когда связь восстановится, будет пробовать возобновить работу с серверами в порядке “Основной - Резервный”, определённом до обрыва связи.

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

 

Основной OPC-сервер - Работает

Основной OPC-сервер – В отказе

Замена в готовности

Основной остаётся в режиме Основной

Резервный переходит в режим Основной

Замена не в готовности

Основной остаётся в режиме Основной

Регистрация отказа связи OPC для последующей
координации восстановления данных.

OPC-сервер, находившийся в режиме
Основной не меняется.

При нормальном «чистом» отключении текущего Основного OPC-сервера, при котором он отправляет уведомительный сигнал на ORM, то переключение осуществляется в кратчайший интервал. Если текущий Основной OPC-сервер отключается внезапно, например, при отказе в сети, то системы ORM OPC, отслеживающим его работу, сами обнаруживают это.

Пакет ORM способен поддерживать до 16 OPC-подключений (OPC пар), но это число можно расширить и далее, в зависимости от загрузки сервера Exaquantum по количеству получаемых данных.

Контроль серверных подключений

С заданным интервалом ORM будет выполнять проверку состояния каждого OPC-сервера. При неотвеченном запросе Основного сервера или если он перейдёт в состояние ‘недоступен/неактивен’, будет произведена попытка переключения на Резервный OPC-сервер. Если Резервный сервер также не доступен, то ORM производит регистрацию момента отказа, но Основным остаётся тот же сервер, что и был ранее (переключения не происходит). С заданной периодичностью ORM производит попытки восстановить связь с OPC-сервером(ами). При восстановлении связи ORM сохраняет предыдущую схему ‘Основной – Резервный’ если это возможно, так как именно этот сервер, скорее всего имеет последние OPC HDA данные.

Сбор данных OPC HDA

ORM считывает данные OPC HDA в следующих случаях:

  • Загрузка пропущенных исторических данных при включении Exaquantum
  • При восстановлении данных OPC

ORM считывает данные с Основного OPCсервера, при его доступности. Если Основной OPC-сервер становится недоступным в процессе загрузки накопленных исторических данных (при первом включении Exaquantum) или в процессе восстановления данных, ORM производит попытку переключиться на Резервный OPC-сервер, который, в случае успеха, автоматически становится Основным, для дальнейшего обновления блоков.

Для OPC-серверов типа Exaopc (Exaopc-STN, Exaopc-XL and Exaopc-µXL), данные OPC HDA запрашиваются по удельной частоте обновления каждого пункта.

Стоит обратить внимание, что ORM не включает в себя модуль синхронизации (Equalization Module) OPC HAD, который предоставляется Exaopc-RD обеспечивающий наличие одинаковых OPC HDA данных у обоих OPC-серверов резервированной пары. Данная функция обеспечивается Exaopc-RD, а не ПО Exaquantum. При работе Exaopc, OPC-сервер в режиме Резервный не ведёт сбор HDA, так как его группы не активны.

Запись данных OPC DA

ORM поддерживает синхронную запись данных OPC DA. Запись данных производится только на Основной OPC-сервер. Если попытка записи будет неудачной по причине перехода текущего Основного OPC-сервера в состояние ‘недоступен/неактивен’ до того, как это обнаружил ORM при выполнении периодической проверки, то попытка переключения серверов происходит немедленно и в случае успеха, запись происходит на OPC-сервер, назначенный Основным.

Доступ к свойствам OPC

ORM поддерживает доступ к свойствам OPC DA, где эти данные считываются в случаях:

  • При конфигурировании новых OPC тэгов в Exaquantum
  • При запросе обновления всех данных свойств для определённого OPC-шлюза через стандартные инструменты администрирования Exaquantum
  • При плановом обновлении данных свойств для всех OPC-шлюзов

Данные свойств считываются на асинхронном потоке, с текущего Основного OPC-сервера и передаются на Exaquantum OPC. Если попытка чтения данных свойств будет неудачной по причине перехода текущего Основного OPC-сервера в состояние ‘недоступен/неактивен’ до того, как это обнаружил ORM при выполнении периодической проверки, то запрос переадресовывается Резервному OPC-серверу.

Поддержка функций Exaquantum без резервирования

ORM поддерживает ряд функций Exaquantum, которые управляются через конфигурирование OPC-шлюзов и поддерживаются входящими в состав OPC-серверами:

  • OPC Синхронизация (Equalization)
  • Создание тэгов HIS
  • Тестирование связи при заходе на OPC-сервер (Logon Connection Test)

Хотите узнать больше о наших технологиях и решениях?

Контакты

Наверх