Спецификация OPC UA

Несмотря на огромный успех и всеобщее признание, практика выявила следующие недостатки ОРС технологии:

• доступность только на операционных системах семейства Microsoft Windows;
• связь c технологией DCOM, исходные коды которой являются закрытыми. Это не позволяет решать вопросы надежности ПО, а также выявлять и устранять возникающие программные отказы;
• бывают проблемы конфигурирования, связанные с DCOM;
• неточные сообщения DCOM о прерываниях связи;
• неприспособленность DCOM для обмена данными через интернет;
• неприспособленность DCOM для обеспечения информационной безопасности.

В связи с этим в 2006 году OPC Foundation предложил новую стандартную спецификацию для обмена данными в системах промышленной автоматизации, получившую название "ОРС Unified Architecture" - "ОРС с унифицированной архитектурой", которая рассматривается как ОРС стандарт нового поколения.

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

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

OPC UA использует несколько различных форматов данных, основными из которых являются бинарные структуры и XML документы. Формат данных может быть определен поставщиком ОРС сервера или стандартом. Для работы с произвольными форматами клиент может запросить у сервера информацию об описании этого формата. Во многих случаях используется автоматическое распознавание формата данных во время их передачи.

OPC UA обладает высокой робастностью* данных и уведомлений о событиях. Робастность обеспечивается механизмом быстрого обнаружения ошибок коммуникации и восстановления данных.

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

Архитектура, ориентированная на сервисы
Основным отличием ОРС UA от OPC является отказ от технологии СОМ и DCOM фирмы Microsoft и переход к архитектуре SOA (Service Oriented Architecture - "Архитектура, ориентированная на сервисы") с целью обмена информацией и обеспечения совместимости c множеством различных аппаратно-программных платформ. Под сервисом в ОРС UA понимается некоторая функциональность, заключенная в программном компоненте, который может быть транспортирован от сервера к клиенту или обратно и вызван удаленно. Вызов сервиса аналогичен вызову метода в языках объектно-ориентированного программирования. Интерфейс между клиентом OPC UA и сервером определяется как набор сервисов. Основным принципом SOA является независимость от программной технологии, от вычислительной платформы, от языков программирования, от конкретных приложений, а также организация сервисов как слабосвязанных компонентов для построения систем. Сервисы включают в себя средства для обеспечения информационной безопасности.

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

Сервисы ОРС UA делятся на логические группы:

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

Независимость от COM, DCOM
Отказ от DCOM стал возможен благодаря появлению новых транспортных механизмов, основанных на SOAP, XML, HTTP и сервисах. Благодаря им OPC UA позволяет осуществить безопасную и надежную доставку информации и объединить в одном сервере функциональность OPC DA, OPC HDA и OPC A&E серверов.

Стандарт OPC UA не предназначен для замены существующих OPC спецификаций, а дополняет и расширяет их возможности.

Безопасность
Для обеспечения информационной безопасности в OPC UA используются стандартные Web сервисы безопасности, такие как WS-Security, WS-Trust или WS-SecureConversation. Диапазон возможностей средств безопасности простирается от простой аутентификации с помощью пароля и обмена цифровыми подписями до полного шифрования передаваемых сообщений.

ОРС сообщения в стандарте UA передаются с помощью сообщений SOAP в виде XML текста. Поскольку кодирование и декодирование текстового формата занимает довольно много времени, стандарт предусматривает альтернативный способ представления информации в виде бинарного файла.

Достоинства нового стандарта
Основными достоинствами OPC UA являются:

• реализация на языке программирования ANSI C для обеспечения переносимости на другие платформы, включая встраиваемые системы. Доступны также версии на .NET и Java (от OPC Foundation);
• ориентация на сервисы вместо ориентации на объекты, что позволяет использовать OPC UA на любых компьютерах, встраиваемых системах, в коммуникаторах и т.п. которые используют веб-сервисы;
• позволяет осуществить масштабирование OPC UA, т.е изменение объема программы в зависимости от вычислительных ресурсов процессора и требуемой функциональности. Может быть выполнена также компиляция в виде однопоточного или многопоточного приложения;
• поддержка надежного и современного транспортного механизма SOAP на базе XML c применением HTTP протокола;
• обеспечение хорошей информационной безопасности;
• конфигурируемый таймаут для каждого сервиса;
• использование открытых стандартов World Wide Web Consortium (W3C) вместо закрытого стандарта СОМ/DCOM.

Концепция системы на базе OPC UA
Система на базе ОРС UA может содержать множество клиентов и серверов. Каждый клиент может работать параллельно с несколькими серверами и каждый сервер может обслуживать нескольких клиентов. Пользовательское приложение (например, SCADA) может создавать комбинированные группы клиентов и серверов для ретрансляции сообщений, которыми оно обменивается с другими клиентами и серверами, как показано на рисунке.

Клиентом при взаимодействии с ОРС сервером является прикладная программа, например, SCADA. Структура клиента показана на рисунке. Клиентская программа выполняет запросы сервисов ОРС сервера через внутренний интерфейс, который является изолирующей прослойкой между программой и коммуникационным стеком. Коммуникационный стек конвертирует запросы клиентской прикладной программы в сообщения для вызова необходимого сервиса, которые посылает серверу. После получения ответа на запросы коммуникационный стек передает их в клиентскую программу.

Структура сервера ОРС UA представлена на рисунке. Модули ввода-вывода, ПЛК, интеллектуальные устройства и программы, которые могут поставлять данные через ОРС сервер, обозначены на рисунке как "реальные объекты". Серверное приложение представляет собой программную реализацию функций, которые должен выполнять сервер. Взаимодействие ОРС UA сервера с клиентом выполняется через интерфейс прикладной программы рисунке, путем отправления запросов и получения ответов.

Адресное пространство OPC сервера представляет собой множество узлов, доступных клиентской программе с помощью сервисов ОРС UA. "Узлы" в адресном пространстве используются, чтобы представить реальные объекты, их определения и перекрестные ссылки. В адресном пространстве выделяется подпространство узлов, которые сервер делает "видимыми" для клиента. Видимые узлы организуются в виде иерархической структуры, для удобства навигации их клиентской программой.

Обмен данными между клиентом и сервером может выполняться как путем получения мгновенных ответов на запросы, так и по схеме "издатель-подписчик". Во втором случае клиентская программа осуществляет "подписку" на получение определенных данных, которые сервер должен будет предоставить по мере их появления. Для реализации режима подписки сервер осуществляет непрерывный контроль (мониторинг) узлов и соответствующих им реальных объектов с целью обнаружения изменений. При обнаружении изменений в данных, событиях или аварийных сигналах (алармах) сервер генерирует уведомление, которое передается клиенту по каналу подписки.

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

Для защиты уже сделанных инвестиций в OPC на базе DCOM организация OPC Foundation разработала стратегию перехода на новую технологию с применением " UA-оболочки", которая допускает обмен данными между старыми и новыми продуктами. Такая оболочка позволяет, например, DCOM OPC серверу работать с OPC UA клиентом, и наоборот.

*Робастность - нечувствительность данных к помехам, сбоям, вычислительным ошибкам.
**Узел - представление объектов, их определений и перекрестных ссылок в адресном пространстве сервера OPC UA.

Источник: http://www.bookasutp.ru/Chapter9_2_4.aspx