Резервированный менеджер OPC (Exaquantum/ORM)

Выгоды

• Повышает надёжность 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)