СТА 3/2010

подпиской, элементом отношения «один ко многим»). Если сбой в канале передачи данных приводит к разрыву сетевого соединения, то после установ ления нового соединения созданную ранее сессию можно «привязать» к нему и продолжить работу без повторной инициализации, то есть обеспечивается возможность быстрого восстановления передачи данных. Аналогично при реа лизации сценария резервирования: ес ли есть основной и резервный 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 клиент также может подписаться на получение уведомлений от сервера об изменениях в адресном простран стве. И, например, в случае систем, формирующих на выходе сводные от чёты, возможность автоматически от реагировать на увеличение или умень шение количества анализируемых объ ектов, несомненно, полезна. На рис. 4 показан пример: в адресном пространстве OPC UA сервера может быть задано определение класса со списком параметров, поступающих от систем автоматизации и характеризую щих режим работы скважины на под земном хранилище или месторождении газа, нефти. OPC клиент, формирую щий отчёт по добыче за предыдущий час, может получить список обратных ссылок типа HasTypeDefinition, указыва ющих от объектов на их класс, то есть получить массив имен объектов и со ставить запрос на чтение значений переменных QLH из каждого объекта. При обнаружении изменения в списке ссылок клиент обновляет свой перечень имён и идентификаторов объектов (то есть проводит повторную частичную инициализацию без прерывания соеди нения, если говорить на техническом 84 СТА 3/2010 П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ / ИНС Т Р УМЕ Н ТАЛ Ь НЫЕ СИС Т ЕМЫ www.cta.ru Well 1 Well 2 Объект Ссылка типа HasTypeDefinition Ссылка типа HasComponent Well 3 T P QLH Переменная Класс WellClass Рис. 4. Ссылки в адресном пространстве OPC UA сервера © СТА-ПРЕСС