Быстрое реагирование на сбои и резервирование передачи данных

OPC UA разделяет несколько уровней взаимодействия OPC — клиентов и OPC — серверов. Во-первых, каждый из клиентов устанавливают с сервером свое защищенное сетевое соединение. При этом если в «классической» OPC право доступа клиента к серверу определялось, исходя из прав пользователей Windows, от чьего имени они запускались на соответствующих компьютерах, то в OPC UA клиент и сервер идентифицируют себя цифровыми сертификатами. Во-вторых, в рамках соединения создается сессия — логическое соединение клиента и сервера. Параметром сессии являются уже права отдельного пользователя, использующего OPC — клиент, так как OPC — сервер может вводить ограничения на операции чтения/записи отдельных элементов для разных пользователей. Уже в рамках сессии производится собственно передача данных (выполнение запросов на чтение/запись), а также производится инициализация списка элементов, об изменениях значений которых сервер направляет клиенту уведомление (рис. 4 — между соединением, сессией, пропиской, элементом отношения «один ко многим»).

Рисунок 4.

Если сбой в канале передачи данных приводит к разрыву сетевого соединения, то после установления нового соединения созданную ранее сессию можно «привязать» к нему и продолжить работу без повторной инициализации, то есть обеспечивается возможность быстрого восстановления передачи данных. Аналогично при реализации сценария резервирования: если есть основной и резервный OPC — клиенты, ведущие опрос одного OPC — сервера, то соединение с сервером устанавливают оба, а создает сессию и ведет опрос основной OPC — клиент. В случае его краха резервный OPC — клиент подключает сохраненную на сервере сессию к своему соединению и продолжает получение данных.

Отдельно отметим изменения в концепции отправки OPC — сервером уведомлений об изменениях значений отдельных параметров клиентам (механизмы так называемого спонтанного уведомления об изменениях SRBX — spontaneous report by exception). В OPC DA этот механизм был реализован через обратный вызов методов клиента, в OPC UA межпрограммное взаимодействие не используется, а отправляются сообщения. Важной особенностью их отправки является то, что сервер сам определяет момент отправки (по факту изменения значений отдельных параметров), но не создает новых сообщений, а выбирает их из очереди ранее полученных «заготовок» от данного клиента. То есть сначала клиент направляет серверу массив запросов об изменениях (с уникальными ID), сервер их кэширует и по мере появления изменений (или при прохождении заданного периода времени без изменений) отправляет клиенту; далее клиент подтверждает факт получения сообщения. Периодически клиент пополняет очередь на сервере сообщениями с новыми ID. Таким образом исключается возможность неконтролируемого роста числа отправляемых сервером сообщений об изменениях.

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

Транзакционная передача данных

Как уже отмечалось, OPC UA реализует важные изменения и в части организации данных сервера, то есть адресного пространства. Напомним, что в OPC DA теги были сгруппированы иерархически с помощью папок. У каждого тега были обязательные свойства: значение (скалярное или векторное, одного из предопределённых простых типов данных — Int16, Float, String ит.п.); признак достоверности (quality); метка времени. Разработчик OPC сервера мог определять дополнительные свойства для тегов, такие как описание единиц измерения и т. п.; было желательным, чтобы OPC клиент мог считывать значения этих дополнительных свойств наряду с обязательными свойствами. В OPC UA адресное пространство организовано иерархически за счёт введения объектов (в терминах объектно ориентированного программмирования), то есть экземпляров классов.

Класс (и объект) может содержать переменные, ссылки на другие объек ты и даже методы — функции, доступные для вызова OPC клиентом. При этом тип переменной может быть сложным, аналогично понятию структуры из языка программирования, объединяя поля разных типов, включая таблицы (массивы) и т. д. В частности, это даёт возможность отойти от традиционной для систем контроля и управления передачи значений отдельных сигналов и обеспечить передачу наборов данных — таблиц, фиксирующих значения целого ряда параметров на выбранный момент времени, что более приемлемо для MES и ERP систем. Можно предположить, что формирование этих сложно структурированных переменных будет также происходить не автоматически, а по команде, то есть при вызове специального метода в OPC сервере клиентом.

Адаптивность задачи информационного стыка с OPC сервером

В адресном пространстве OPC UA сервера может быть реализована явная типизация объектов, то есть сопоставление однотипных групп технологических параметров шаблону (классу). Благодаря этому появляется возможность в приложении клиенте контролировать полноту получаемой информации и в случае изменения её объёмов в сервере автоматически на это реагировать. OPC UA клиент может отойти от принятой в настоящее время схемы, когда перечень сигналов обмена с OPC сервером определяется в виде списка имён тегов. Явное предоставление семантической информации в OPC UA сервере и, в частности, наличие ссылок от описания класса к его экземплярам позволяет задать шаблон перечня объектов, а не вводить на клиенте список имён экземпляров класса, существующих на момент настройки стыка. OPC UA клиент также может подписаться на получение уведомлений от сервера об изменениях в адресном пространстве. И, например, в случае систем, формирующих на выходе сводные отчёты, возможность автоматически отреагировать на увеличение или уменьшение количества анализируемых объектов, несомненно, полезна.

Рисунок 5.

На рис. 5 показан пример: в адресном пространстве OPC UA сервера может быть задано определение класса со списком параметров, поступающих от систем автоматизации и характеризующих режим работы скважины на подземном хранилище или месторождении газа, нефти. OPC клиент, формирующий отчёт по добыче за предыдущий час, может получить список обратных ссылок типа HasTypeDefinition, указывающих от объектов на их класс, то есть получить массив имен объектов и составить запрос на чтение значений переменных QLH из каждого объекта.

При обнаружении изменения в списке ссылок клиент обновляет свой перечень имен и идентификаторов объектов (то есть проводит повторную частичную инициализацию без прерывания соединения, если говорить на техническом языке). Однако участие человека требуется на этапе начальной настройки стыка, так как отличить смысловую нагрузку значения, хранимого в переменной QLH, от значений переменных P или Т можно, только прочитав атрибут — текстовое описание переменной — или проанализировав сами имена. Разработчики OPC UA рассматривают это как ограничение и предусматривают в будущем выпуск специализированных информационных моделей — документов в текстовом и XML форматах, определяющих правила использования имён переменных для отдельных предметных областей.