OPC UA Термины и Концепции

3.1 OPC UA термины
3.1.1 AddressSpace (Адресное пространство)
Сбор информации, которую сервер OPC UA делает видимой для своих клиентов.
Описание содержимого и структуры адресного пространства сервера приведено в части 3.
3.1.2 Alarm (Аварийный сигнал)
Тип события, связанного с состоянием, которое обычно требует подтверждения. Описание
аварийных сигналов приведено в части 9.
3.1.3 Attribute (Атрибут)
Элементарная характеристика узла. Все атрибуты определяются OPC UA и могут не
определяться клиентами или серверами. Атрибуты - это единственные элементы в
адресной области, которым разрешено иметь значения данных.
3.1.4 Certificate (Сертификат)
Структура данных с цифровой подписью, описывающая возможности Клиента или
сервера.
3.1.5 Client (Клиент)
Программное приложение, которое отправляет сообщения на серверы OPC UA,
соответствующие услугам, указанным в данном наборе спецификаций.
3.1.6 Condition (Условие)
Общий термин, который является расширением к событию. Условие представляет собой
состояние системы или одного из ее компонентов и всегда существует в некотором
состоянии.
3.1.7 Communication Stack (Коммуникационный стек)
Многоуровневый набор программных модулей между приложением и аппаратным
обеспечением, который предоставляет различные функции для кодирования, шифрования
и форматирования сообщения для отправки, а также для декодирования, расшифровки и
распаковки полученного сообщения.
3.1.8 Complex Data (Сложные данные)
Данные, состоящие из элементов или более чем одного примитивного типа данных,
например структуры.
3.1.9 Discovery (Обнаружение)
Процесс, с помощью которого клиенты OPC UA получают информацию о серверах OPC
UA, включая конечную точку и информацию о безопасности.
3.1.10 Event (Событие)
Общий термин, используемый для описания некоторого значимого события в системе или
системном компоненте.
3.1.11 Event Notifier(Уведомитель о событии)
Специальный атрибут узла, который означает, что Клиент может подписаться на этот
конкретный узел для получения уведомлений о наступлении событий.
3.1.12 Information Model (Информационная модель)
Организационная структура, которая определяет, характеризует и связывает
информационные ресурсы данной системы или набора систем. Базовая модель адресного
пространства поддерживает представление информационных моделей в адресном
пространстве. Описание базовой информационной модели OPC UA приведено в части 5.
3.1.13 Message (Сообщение)
Модуль данных, передаваемый между Клиентом и Сервером и представляющий
определенный запрос на обслуживание или ответ на него.
3.1.14 Method (Метод)
Вызываемая программная функция, которая является компонентом объекта.
3.1.15 MonitoredItem (Отслеживаемый объект)
Объект, определяемый клиентом на Сервере, используемый для отслеживания атрибутов
или EventNotifiers на предмет появления новых значений или событий и создания
уведомлений о них.
3.1.16 Node (Узел)
Основной компонент адресного пространства.
3.1.17 Node Class (Класс узла)
Класс узла в адресном пространстве. Классы узлов определяют метаданные для
компонентов объектной модели OPC UA. Они также определяют конструкции, такие как
представления, которые используются для организации адресного пространства.
3.1.18 Notification (Уведомление)
Общий термин для данных, сообщающих об обнаружении события или об изменении
значения атрибута. Уведомления отправляются в виде уведомительных сообщений.
3.1.19 NotificationMessage (Уведомительное сообщение)
Сообщение, опубликованное в рамках подписки, которое содержит одно или несколько
уведомлений.
3.1.20 Object (Объект)
Узел, представляющий физический или абстрактный элемент системы. Объекты
моделируются с использованием объектной модели OPC UA. Примерами объектов
являются системы, подсистемы и устройства. Объект может быть определен как
экземпляр ObjectType.
3.1.21 Object Instance (Экземпляр объекта)
Синоним слова Object. Не все объекты определяются с помощью ObjectTypes.
3.1.22 ObjectType Тип объекта
Узел, представляющий определение типа объекта.
3.1.23 Profile Профиль
Определенный набор возможностей, определенный в части 7, на соответствие которому
Сервер может претендовать. Каждый Сервер может претендовать на соответствие более
чем одному профилю.
3.1.24 Program Программа
Исполняемый объект, который при вызове немедленно возвращает ответ, указывающий
на то, что выполнение началось, а затем возвращает промежуточные и окончательные
результаты с помощью подписок, идентифицированных Клиентом во время вызова.
3.1.25 Reference Ссылка
Явная связь (именованный указатель) между одним узлом и другим. Узел, содержащий
ссылку, является исходным узлом, а узел, на который ссылается ссылка, является целевым
узлом. Все ссылки определяются ссылочными типами.
3.1.26 ReferenceType Ссылочный тип
Узел, представляющий определение типа ссылки. ReferenceType определяет семантику
ссылки. Имя ReferenceType определяет, как исходные узлы связаны с целевыми узлами, и,
как правило, отражает взаимодействие между ними, например, “A содержит B”.
3.1.27 RootNode Корневой узел
Начальный или верхний узел иерархии. Корневой узел адресного пространства OPC UA
определен в части 5.
3.1.28 Server Сервер
Программное приложение, которое реализует и предоставляет услуги, указанные в этом
наборе спецификаций.
3.1.29 Service Служба
Операция, вызываемая клиентом на сервере OPC UA. Службы определены в части 4.
Служба аналогична вызову метода на языке программирования или операции в WSDLконтракте веб-служб.
3.1.30 Service Set Набор сервисов
Группа связанных сервисов.
3.1.31 Session Сессия
Логическое долговременное соединение между Клиентом и Сервером. Сеанс
поддерживает информацию о состоянии между вызовами службы от Клиента к Серверу.
3.1.32 Subscription Подписка
Определяемая клиентом конечная точка на Сервере, используемая для отправки
уведомлений Клиенту. Общий термин, описывающий набор узлов, выбранных Клиентом
(1), которые Сервер периодически отслеживает на наличие некоторого состояния и (2) для
которых Сервер отправляет Клиенту уведомления при обнаружении состояния.
3.1.33 Переменная
Переменная — это узел, содержащий значение.
3.1.34 Вид
Специфический поднабор пространства адресов, представляющий интерес для клиента.
3.2 Сокращения и символы
A&E-Сигналы тревоги и события
API-Интерфейс прикладного программирования
COM-Модель компонентных объектов
DA-Доступ к данным
DCS-Система распределенного управления
DX-Обмен данными
HDA-Доступ к историческим данным
HMI-Человеко-машинный интерфейс
LDAP-Легковесный протокол доступа к каталогам
MES-Система исполнения производства
OPC-OPC Фонд (некоммерческая промышленная ассоциация)
PLC-Программируемый логический контроллер
SCADA-Супервизорное управление и сбор данных
SOAP-Простой протокол доступа к объектам
UA-Унифицированная архитектура
UDDI-Универсальное описание, обнаружение и интеграция
UML-Унифицированный язык моделирования
WSDL-Язык описания веб-сервисов
XML-Расширяемый язык разметки
5.2 Введение
OPC UA — это независимый от платформы стандарт, через который различные виды
систем и устройств могут общаться, отправляя сообщения между клиентами и серверами
по различным типам сетей. Он поддерживает надежную, безопасную коммуникацию,
которая обеспечивает идентичность клиентов и серверов и сопротивляется атакам. OPC
UA определяет наборы сервисов, которые серверы могут предоставлять, и отдельные
серверы указывают клиентам, какие наборы сервисов они поддерживают. Информация
передается с использованием определенных OPC UA и определенных поставщиком типов
данных, и серверы определяют модели объектов, которые клиенты могут динамически
обнаруживать. Серверы могут предоставлять доступ как к текущим, так и к историческим
данным, а также к сигналам тревоги и событиям для уведомления клиентов о важных
изменениях. OPC UA может сопоставляться с различными коммуникационными
протоколами, и данные могут кодироваться различными способами для баланса между
переносимостью и эффективностью.
5.3 Цели проектирования
OPC UA предоставляет последовательное, интегрированное пространство адресов и
модель сервисов. Это позволяет одному серверу OPC UA интегрировать данные, сигналы
тревоги и события, и историю в свое пространство адресов, и предоставлять доступ к ним
с использованием интегрированного набора сервисов. Эти сервисы также включают
интегрированную модель безопасности. OPC UA также позволяет серверам предоставлять
клиентам определения типов для объектов, доступных из пространства адресов. Это
позволяет использовать информационные модели для описания содержимого
пространства адресов. OPC UA позволяет данным отображаться во многих различных
форматах, включая бинарные структуры и XML-документы. Формат данных может
определяться OPC, другими стандартными организациями или поставщиками. Через
пространство адресов клиенты могут запрашивать у сервера метаданные, описывающие
формат данных. В многих случаях клиенты без предварительно запрограммированного
знания форматов данных смогут определять форматы во время выполнения и правильно
использовать данные. OPC UA добавляет поддержку многих отношений между узлами
вместо ограничения только одной иерархией. Таким образом, сервер OPC UA может
представлять данные в различных иерархиях, адаптированных к тому, как набор клиентов
обычно хотел бы просматривать данные. Эта гибкость, в сочетании с поддержкой
определений типов, делает OPC UA применимым к широкому спектру областей проблем.
Как показано ниже, OPC UA ориентирован не только на интерфейс SCADA, PLC и DCS,
но и как способ предоставления большей совместимости между функциями более
высокого уровня.
OPC UA предназначен для обеспечения устойчивости опубликованных данных. Основная
особенность всех серверов OPC - способность публиковать данные и уведомления о
событиях. OPC UA предоставляет механизмы для клиентов для быстрого обнаружения и
восстановления от сбоев связи, связанных с этими передачами, без необходимости ждать
длительных тайм-аутов, предоставляемых базовыми протоколами. OPC UA предназначен
для поддержки широкого диапазона серверов, от PLC на производстве до серверов
предприятия. Эти серверы характеризуются широким спектром размера,
производительности, платформ выполнения и функциональных возможностей. Поэтому
OPC UA определяет всеобъемлющий набор возможностей, и серверы могут
реализовывать подмножество этих возможностей. Для продвижения совместимости OPC
UA определяет подмножества, называемые профилями, на которые серверы могут
претендовать на соответствие. Клиенты могут затем обнаруживать профили сервера и
адаптировать свои взаимодействия с этим сервером на основе профилей. Профили
определяются в Части 7. Спецификации OPC UA разделены на слои для изоляции
основного дизайна от базовой вычислительной технологии и транспорта сети. Это
позволяет сопоставлять OPC UA с будущими технологиями по необходимости, без
отрицания базового дизайна. Сопоставления и кодировки данных описаны в Части 6.
Определены две кодировки данных:
XML/текст
UA Бинарный
Кроме того, определены три протокола транспорта:
OPC UA TCP
SOAP/HTTP
HTTPS
Клиенты и серверы, поддерживающие несколько транспортов и кодировок, позволят
конечным пользователям принимать решения о компромиссах между
производительностью и совместимостью XML веб-сервисов во время развертывания,
вместо того чтобы эти компромиссы определялись поставщиком OPC во время
определения продукта. OPC UA предназначен как путь миграции для клиентов и серверов
OPC, основанных на Microsoft COM технологии. В дизайне OPC UA было уделено
внимание, чтобы существующие данные, предоставляемые OPC COM серверами (DA,
HDA и A&E), могли легко сопоставляться и предоставляться через OPC UA. Поставщики
могут выбрать миграцию своих продуктов нативно на OPC UA или использовать внешние
обертки для преобразования из OPC COM в OPC UA и наоборот. Каждая из предыдущих
спецификаций OPC определяла свою собственную модель пространства адресов и свой
собственный набор сервисов. OPC UA объединяет предыдущие модели в единую
интегрированную модель пространства адресов с единым набором сервисов.
5.4 Интегрированные модели и сервисы
5.4.1 Модель безопасности
5.4.1.1 Общее
Безопасность OPC UA касается аутентификации клиентов и серверов, аутентификации
пользователей, целостности и конфиденциальности их коммуникаций и проверяемости
претензий на функциональность. Она не определяет обстоятельства, при которых
различные механизмы безопасности требуются. Эта спецификация имеет решающее
значение, но она делается дизайнерами системы на данном сайте и может быть указана
другими стандартами. Вместо этого OPC UA предоставляет модель безопасности,
описанную в Части 2, в которой меры безопасности могут быть выбраны и настроены для
удовлетворения потребностей безопасности данной установки. Эта модель включает
механизмы безопасности и параметры. В некоторых случаях определяется механизм
обмена параметрами безопасности, но способ, которым приложения используют эти
параметры, нет. Этот фреймворк также определяет минимальный набор профилей
безопасности, которые поддерживают все UA серверы, даже если они могут не
использоваться во всех установках. Профили безопасности определяются в Части 7.
5.4.1.2 Обнаружение и установление сеанса
Безопасность уровня приложения полагается на безопасный канал коммуникаций,
который активен на протяжении сеанса приложения и обеспечивает целостность всех
обмениваемых сообщений. Это означает, что пользователи должны аутентифицироваться
только один раз, когда сеанс приложения устанавливается.
Механизмы для обнаружения серверов OPC UA и установления безопасных каналов
коммуникаций и сеансов приложений описаны в Части 4 и Части 6. Дополнительная
информация о процессе обнаружения описана в Части 12. Когда сеанс устанавливается,
приложения клиента и сервера договариваются о безопасном канале коммуникаций.
Программные сертификаты используются для идентификации клиента и сервера и
возможностей, которые они предоставляют. Сертификаты, сгенерированные авторитетом,
указывают профили OPC UA, которые приложения реализуют, и уровень сертификации
OPC UA, достигнутый для каждого профиля1.
Детали каждого профиля определяются в Части 7. Сертификаты, выданные другими
организациями, также могут обмениваться во время установления сеанса. Сервер далее
аутентифицирует пользователя и авторизует последующие запросы на доступ к объектам
в сервере. Механизмы авторизации, такие как списки контроля доступа, не определяются
спецификацией OPC UA. Они специфичны для приложения или системы.
5.4.1.3 Аудит
OPC UA включает поддержку трасс аудита безопасности с отслеживанием между
журналами аудита клиента и сервера. Если проблема, связанная с безопасностью,
обнаружена на сервере, соответствующая запись журнала аудита клиента может быть
найдена и проверена. OPC UA также предоставляет возможность серверам генерировать
уведомления о событиях, которые сообщают о проверяемых событиях клиентам,
способным их обрабатывать и регистрировать. OPC UA определяет параметры аудита
безопасности, которые могут включаться в записи журнала аудита и в уведомления о
событиях аудита. Часть 5 определяет типы данных для этих параметров. Не все серверы и
клиенты предоставляют все функции аудита. Профили, найденные в Части 7, указывают,
какие функции поддерживаются.
5.4.1.4 Безопасность транспорта
Безопасность OPC UA дополняет инфраструктуру безопасности, предоставляемую
большинством платформ, способных к веб-сервисам. Безопасность уровня транспорта
может использоваться для шифрования и подписи сообщений. Шифрование и подписи
защищают от раскрытия информации и защищают целостность сообщений. Возможности
шифрования предоставляются базовой технологией коммуникаций, используемой для
обмена сообщениями между приложениями OPC UA. Часть 7 определяет алгоритмы
шифрования и подписи, которые должны использоваться для данного профиля.
5.4.2 Интегрированная модель пространства адресов
Набор объектов и связанной информации, которую сервер OPC UA делает доступной
клиентам, называется его пространством адресов. Пространство адресов OPC UA
представляет свое содержимое как набор узлов, соединенных ссылками.
Примитивные характеристики узлов описываются определенными OPC атрибутами.
Атрибуты являются единственным элементами сервера, которые имеют значения данных.
Типы данных, определяющие значения атрибутов, могут быть простыми или сложными.
Узлы в пространстве адресов типизируются в соответствии с их использованием и
значением. Классы узлов определяют метаданные для пространства адресов OPC UA.
Часть 3 определяет классы узлов OPC UA.
Базовый класс узла определяет атрибуты, общие для всех узлов, позволяющие
идентификацию, классификацию и именование. Каждый класс узла наследует эти
атрибуты и может дополнительно определять свои собственные атрибуты.
Для продвижения совместимости клиентов и серверов пространство адресов OPC UA
структурировано иерархически, с верхними уровнями, одинаковыми для всех серверов.
Хотя узлы в пространстве адресов обычно доступны через иерархию, они могут иметь
ссылки друг на друга, позволяя пространству адресов представлять взаимосвязанную сеть
узлов. Модель пространства адресов определяется в Части 3.
Серверы OPC UA могут подмножить пространство адресов в виды для упрощения
доступа клиента. Пункт 6.3.3.3 описывает виды пространства адресов более подробно.
5.4.3 Интегрированная модель объектов
Модель объектов OPC UA предоставляет последовательный, интегрированный набор
классов узлов для представления объектов в пространстве адресов. Эта модель
представляет объекты в терминах их переменных, событий и методов, и их отношений с
другими объектами. Часть 3 описывает эту модель.
Модель объектов OPC UA позволяет серверам предоставлять определения типов для
объектов и их компонентов. Определения типов могут быть подклассами. Они также
могут быть общими или специфичными для системы. Типы объектов могут определяться
организациями стандартов, поставщиками или конечными пользователями.
Эта модель позволяет интегрировать данные, сигналы тревоги и события, и их историю в
один сервер OPC UA.
Например, серверы OPC UA могут представлять передатчик температуры как объект,
состоящий из значения температуры, набора параметров тревоги и соответствующего
набора пределов тревоги.
5.4.4 Интегрированные сервисы
Интерфейс между клиентами OPC UA и серверами определяется как набор сервисов. Эти
сервисы организованы в наборы сервисов. Наборы сервисов обсуждаются в Пункте 7 и
определяются в Части 4. Сервисы OPC UA предоставляют две возможности клиентам.
Они позволяют клиентам выдавать запросы серверами получать ответы от них. Они также
позволяют клиентам подписываться на серверы для уведомлений.
Уведомления включают события, сигналы тревоги, изменения значений данных и
результаты выполнения программ.
Сообщения OPC UA могут кодироваться как XML-текст или в бинарном формате для
целей эффективности. Они могут передаваться с использованием нескольких базовых
транспортов, например TCP или веб-сервисов через HTTP.
Серверы могут предоставлять различные кодировки и транспорты как определено частью
6.
5.5 Сеансы
OPC UA требует модели с состоянием. Информация о состоянии поддерживается внутри
сеанса приложения. Примеры информации о состоянии — это подписки, учетные данные
пользователя и точки продолжения для операций, охватывающих несколько запросов.
Сеансы определяются как логические соединения между клиентами и серверами. Серверы
могут ограничивать количество одновременных сеансов на основе доступности ресурсов,
ограничений лицензии или других ограничений. Каждый сеанс независим от базовых
протоколов коммуникаций. Сбои этих протоколов не автоматически вызывают
завершение сеанса. Сеансы завершаются на основе запроса клиента или сервера или на
основе неактивности клиента. Интервал времени неактивности договаривается во время
установления сеанса.
5.6 Резервирование
Дизайн OPC UA обеспечивает, что поставщики могут создавать резервные клиенты и
резервные серверы в последовательной манере. Резервирование может использоваться для
высокой доступности, отказоустойчивости и балансировки нагрузки. Детали для
резервирования находятся в Части 4. Только некоторые профили Часть 7 потребуют
поддержку резервирования, но не базовый профиль.
6 Концепции систем
6.1 Обзор
Архитектура систем OPC UA моделирует клиентов и серверы OPC UA как
взаимодействующих партнеров.
Каждая система может содержать несколько клиентов и серверов. Каждый клиент может
взаимодействовать одновременно с одним или более серверами, и каждый сервер может
взаимодействовать одновременно с одним или более клиентами. Приложение может
комбинировать компоненты сервера и клиента для разрешения взаимодействия с другими
серверами и клиентами, как описано в Пункте 6.3.6.
Клиенты и серверы OPC UA описаны в следующих пунктах. Рисунок 3 иллюстрирует
архитектуру, включающую комбинированный сервер и клиент.
6.2 Клиенты OPC UA
Архитектура клиента OPC UA моделирует конечный пункт клиента клиент/серверных
взаимодействий. Рисунок 4 иллюстрирует основные элементы типичного клиента OPC UA
и как они относятся друг к другу.
Приложение клиента — это код, реализующий функцию клиента. Оно использует API
клиента OPC UA для отправки и получения запросов и ответов сервисов OPC UA к
серверу OPC UA.
Сервисы, определенные для OPC UA, описаны в Пункте 7 и определяются в Части 4.
Обратите внимание, что "API клиента OPC UA" — это внутренний интерфейс,
изолирующий код приложения клиента от стека коммуникаций OPC UA. Стек
коммуникаций OPC UA преобразует вызовы API клиента OPC UA в сообщения и
отправляет их через базовую сущность коммуникаций к серверу по запросу приложения
клиента. Стек коммуникаций OPC UA также получает ответы и сообщения уведомлений
от базовой сущности коммуникаций и доставляет их приложению клиента через API
клиента OPC UA.
6.3 Серверы OPC UA
Архитектура сервера OPC UA моделирует конечный пункт сервера клиент/серверных
взаимодействий. Рисунок 5 иллюстрирует основные элементы сервера OPC UA и как они
относятся друг к другу.
Рисунок 5 – Архитектура сервера OPC UA
6.3.1 Реальные объекты
Реальные объекты — это физические или программные объекты, доступные приложению
сервера OPC UA или поддерживаемые им внутренне. Примеры включают физические
устройства и счетчики диагностики.
6.3.2 Приложение сервера OPC UA
Приложение сервера OPC UA — это код, реализующий функцию сервера. Оно использует
API сервера OPC UA для отправки и получения сообщений OPC UA от клиентов OPC UA.
Обратите внимание, что "API сервера OPC UA" — это внутренний интерфейс,
изолирующий код приложения сервера от стека коммуникаций OPC UA.
6.3.3 Пространство адресов OPC UA
6.3.3.1 Узлы пространства адресов
Пространство адресов моделируется как набор узлов, доступных клиентам с
использованием сервисов OPC UA (интерфейсов и методов). Узлы в пространстве адресов
используются для представления реальных объектов, их определений и их ссылок друг на
друга.
6.3.3.2
Организация пространства адресов
Часть 3 содержит детали мета-модели "строительных блоков", используемых для создания
пространства адресов из взаимосвязанных узлов последовательным образом. Серверы
свободны организовывать свои узлы в пространстве адресов по своему усмотрению.
Использование ссылок между узлами позволяет серверам организовывать пространство
адресов в иерархии, полную сетку узлов или любой возможный микс. Часть 5 определяет
узлы и ссылки OPC UA и их ожидаемую организацию в пространстве адресов. Некоторые
профили не потребуют реализации всех узлов UA.
6.3.3.3 Виды пространства адресов
Вид — это подмножество пространства адресов. Виды используются для ограничения
узлов, которые сервер делает видимыми для клиента, тем самым ограничивая размер
пространства адресов для запросов сервисов, подаваемых клиентом. Вид по умолчанию —
это все пространство адресов. Серверы могут опционально определять другие виды. Виды
скрывают некоторые узлы или ссылки в пространстве адресов. Виды видимы через
пространство адресов, и клиенты могут просматривать виды для определения их
структуры. Виды часто являются иерархиями, которые легче для клиентов навигировать и
представлять в дереве.
6.3.3.4 Поддержка информационных моделей
Пространство адресов OPC UA поддерживает информационные модели. Эта поддержка
предоставляется через:
a) Ссылки узлов, позволяющие объектам в пространстве адресов быть связанными друг с
другом.
b) Узлы типов объектов, предоставляющие семантическую информацию для реальных
объектов (определения типов).
c) Узлы типов объектов для поддержки подклассов определений типов.
d) Определения типов данных, представленные в пространстве адресов, позволяющие
использовать специфичные для отрасли типы данных.
e) Сопутствующие стандарты OPC UA, позволяющие группам отраслей определять, как
их конкретные информационные модели должны представляться в пространствах адресов
серверов OPC UA.
6.3.4 Сущности публикатора/подписчика
6.3.4.1 Мониторируемые элементы
Мониторируемые элементы — это сущности в сервере, создаваемые клиентом, которые
мониторят узлы пространства адресов и их реальные аналоги. Когда они обнаруживают
изменение данных или возникновение события/тревоги, они генерируют уведомление,
которое передается клиенту через подписку.
6.3.4.2 Подписки
Подписка — это конечный пункт в сервере, публикующий уведомления клиентам.
Клиенты контролируют скорость, с которой происходит публикация, отправляя
сообщения публикации.
6.3.5 Интерфейс сервисов OPC UA
6.3.5.1 Общее
Сервисы, определенные для OPC UA, описаны в Пункте 7 и определяются в Части 4.
6.3.5.2 Сервисы запрос/ответ
Сервисы запрос/ответ — это сервисы, вызываемые клиентом через интерфейс сервисов
OPC UA
для выполнения конкретной задачи на одном или более узлах в пространстве адресов и
возврата ответа.
6.3.5.3 Сервисы публикатора
Сервисы публикатора — это сервисы, вызываемые через интерфейс сервисов OPC UA для
цели периодической отправки уведомлений клиентам. Уведомления включают события,
сигналы тревоги, изменения данных и выходы программ.
6.3.6 Взаимодействия серверов
Взаимодействия серверов — это взаимодействия, в которых один сервер действует как
клиент другого сервера.
Взаимодействия серверов позволяют для разработки серверов, которые:
f) обмениваются информацией друг с другом на равноправной основе, это может
включать резервирование или удаленные серверы, используемые для поддержания
системных определений типов(см. Рисунок 6),
g) цепляются в слоистой архитектуре серверов для предоставления:
-агрегации данных от серверов нижнего уровня,
-конструкций данных более высокого уровня клиентам, и
-интерфейсов концентраторов клиентам для единственных точек доступа к нескольким
базовым серверам.
Рисунок 6 – Равноправные взаимодействия между серверами
Рисунок 7 расширяет предыдущий пример и иллюстрирует цепочку серверов OPC UA
вместе для вертикального доступа к данным в предприятии.
7 Наборы Сервисов
7.1 Общее
Сервисы OPC UA разделены на Наборы Сервисов, каждый определяющий логическую
группировку сервисов, используемых для доступа к конкретному аспекту сервера. Наборы
Сервисов описаны ниже. Наборы Сервисов и их сервисы определяются в Части 4.
Поддерживает ли сервер набор сервисов или конкретный сервис внутри набора сервисов,
определяется его профилем. Профили описаны в Части 7.
7.2 Набор Сервисов Обнаружения
Этот набор сервисов определяет сервисы, используемые для обнаружения серверов OPC
UA, доступных в системе. Он также предоставляет способ, с помощью которой клиенты
могут читать конфигурацию безопасности, требуемую для подключения к серверу.
Сервисы обнаружения реализуются отдельными серверами и выделенными серверами
обнаружения. Хорошо известные выделенные серверы обнаружения предоставляют
способ клиентам обнаруживать все зарегистрированные серверы OPC UA. Часть 12
описывает, как использовать сервисы обнаружения с выделенными серверами
обнаружения.
7.3 Набор Сервисов Защищенного Канала
Этот набор сервисов определяет сервисы, используемые для открытия канала
коммуникаций, обеспечивающего конфиденциальность и целостность всех сообщений,
обмениваемых с сервером. Базовые концепции для безопасности UA определяются в
Части 2.
Сервисы защищенного канала отличаются от других сервисов, поскольку они обычно не
реализуются приложением UA напрямую. Вместо этого они предоставляются стеком
коммуникаций, на котором построено приложение UA. Например, сервер UA может быть
построен на стеке SOAP, который позволяет приложениям устанавливать защищенный
канал с использованием спецификации WS-SecureConversation. В этих случаях
приложение UA просто должно подтвердить, что WS-SecureConversation активно всякий
раз, когда оно получает сообщение. Часть 6 описывает, как сервисы защищенного канала
реализуются с различными типами стеков коммуникаций.
Защищенный канал — это долгосрочное логическое соединение между одним клиентом и
одним сервером.
Этот канал поддерживает набор ключей, известных только клиенту и серверу, которые
используются для аутентификации и шифрования сообщений, отправляемых по сети.
Сервисы защищенного канала позволяют клиенту и серверу безопасно договариваться о
ключах для использования.
Точные алгоритмы, используемые для аутентификации и шифрования сообщений,
описываются в политиках безопасности для сервера. Эти политики предоставляются через
набор сервисов обнаружения. Клиент выбирает соответствующую конечную точку,
поддерживающую желаемую политику безопасности сервером, когда он создает
защищенный канал.
Когда клиент и сервер общаются через защищенный канал, они проверяют, что все
входящие сообщения были подписаны и/или зашифрованы в соответствии с политикой
безопасности. Приложение UA ожидается игнорировать любое сообщение, которое не
соответствует политике безопасности для канала.
Защищенный канал отделен от сеанса приложения UA; однако, один сеанс приложения
UA может быть доступен только через один защищенный канал. Это подразумевает, что
приложение UA может определить, какой защищенный канал связан с каждым
сообщением. Стек коммуникаций, предоставляющий механизм защищенного канала, но
не позволяющий приложению знать, какой защищенный канал использовался для данного
сообщения, не может использоваться для реализации набора сервисов защищенного
канала.
Связь между сеансом приложения UA и защищенным каналом иллюстрирована на
Рисунке 8. Приложения UA используют стек коммуникаций для обмена сообщениями. Вопервых, сервисы защищенного канала используются для установления защищенного
канала между двумя стеками коммуникаций, позволяя им обмениваться сообщениями
безопасным способом. Во-вторых, приложения UA используют набор сервисов сеанса для
установления сеанса приложения UA.
7.4 Набор Сервисов Сеанса
Этот набор сервисов определяет сервисы, используемые для установления соединения
уровня приложения в контексте сеанса от имени конкретного пользователя.
7.5 Набор Сервисов Управления Узлами
Набор сервисов управления узлами позволяет клиентам добавлять, модифицировать и
удалять узлы в пространстве адресов. Эти сервисы предоставляют интерфейс для
конфигурации серверов.
7.6 Набор Сервисов Видов
Виды — это публично определенные, созданные сервером подмножества пространства
адресов. Полное пространство адресов является видом по умолчанию, и поэтому сервисы
видов способны работать на всем пространстве адресов. Будущие версии этой
спецификации также могут определять сервисы для создания клиентом определенных
видов.Набор сервисов видов позволяет клиентам обнаруживать узлы в виде путем
просмотра. Просмотр позволяет клиентам перемещаться вверх и вниз по иерархии или
следовать ссылкам между узлами, содержащимися в виде. Таким образом, просмотр также
позволяет клиентам обнаруживать структуру вида.
7.7 Набор Сервисов Запросов
Набор сервисов запросов позволяет пользователям обращаться к пространству адресов без
просмотра и без знания логической схемы, используемой для внутреннего хранения
данных.
Запросы позволяют клиентам выбирать подмножество узлов в виде на основе некоторых
предоставленных клиентом критериев фильтра. Узлы, выбранные из вида запросом,
называются набором результатов.
Серверы могут считать сложным обрабатывать запросы, требующие доступа к данным
времени выполнения, таким как данные устройства, включающим интенсивные операции
ресурсов или значительные задержки. В этих случаях сервер может считать необходимым
отклонить запрос.
7.8 Набор Сервисов Атрибутов
Набор сервисов атрибутов используется для чтения и записи значений атрибутов.
Атрибуты — примитивные характеристики узлов, определяемые OPC UA. Они не могут
определяться клиентами или серверами. Атрибуты — единственные элементы в
пространстве адресов, которым разрешено иметь значения данных. Специальный атрибут,
атрибут значения, используется для определения значения переменных.
7.9 Набор Сервисов Методов
Методы представляют вызовы функций объектов. Они определяются в Части 3. Методы
вызываются и возвращаются после завершения, успешного или неудачного. Времена
выполнения методов могут варьироваться в зависимости от выполняемой ими функции.
Набор сервисов методов определяет средства для вызова методов. Метод всегда является
компонентом объекта. Обнаружение предоставляется через сервисы просмотра и
запросов. Клиенты обнаруживают методы, поддерживаемые сервером, просматривая
владеющие объекты, которые идентифицируют их поддерживаемые методы.
Поскольку методы могут контролировать какой-то аспект операций завода, вызов метода
может зависеть от окружающих или других условий. Это может быть особенно верно при
попытке повторно вызвать метод сразу после завершения его выполнения. Условия,
требуемые для вызова метода, могут еще не вернулись в состояние, позволяющее методу
начать снова. Кроме того, некоторые методы могут поддерживать одновременные вызовы,
в то время как другие могут иметь один вызов, выполняющийся в данный момент.
7.10 Набор Сервисов Мониторируемых Элементов
Набор сервисов мониторируемых элементов используется клиентом для создания и
поддержания мониторируемых элементов.
Мониторируемые элементы мониторят переменные, атрибуты и уведомители событий.
Они генерируют уведомления, когда обнаруживают определенные условия. Они
мониторят переменные за изменением значения или статуса; атрибуты за изменением
значения; и уведомители событий за недавно сгенерированными отчетами о сигналах
тревоги и событиях.
Каждый мониторируемый элемент идентифицирует элемент для мониторинга и подписку
для использования для периодической публикации уведомлений клиенту (см. Пункт 7.11).
Каждый мониторируемый элемент также указывает скорость, с которой элемент должен
мониториться (сэмплироваться) и, для переменных и уведомителей событий, критерии
фильтра, используемые для определения, когда должно генерироваться уведомление.
Критерии фильтра для атрибутов указываются их определениями атрибутов в Части 4.
Скорость сэмплирования, определенная для мониторируемого элемента, может быть
быстрее, чем скорость публикации подписки. По этой причине мониторируемый элемент
может быть настроен либо на очередь всех уведомлений, либо на очередь только
последнего уведомления для передачи подпиской. В этом последнем случае размер
очереди равен одному.
Сервисы мониторируемых элементов также определяют режим мониторинга. Режим
мониторинга настроен на отключение сэмплирования и отчетности, на включение только
сэмплирования или на включение как сэмплирования, так и отчетности.
Когда сэмплирование включено, сервер сэмплирует элемент. Кроме того, каждый сэмпл
оценивается для определения, должно ли генерироваться уведомление. Если да,
уведомление ставится в очередь. Если отчетность включена, очередь делается доступной
для подписки для передачи.
Наконец, мониторируемые элементы могут быть настроены на триггер отчетности других
мониторируемых элементов. В этом случае режим мониторинга элементов для отчетности
обычно устанавливается только на сэмплирование, и когда триггерный элемент
генерирует уведомление, любые поставленные в очередь уведомления элементов для
отчетности делаются доступными для подписки для передачи.
7.11 Набор Сервисов Подписок
Набор сервисов подписок используется клиентом для создания и поддержания подписок.
Подписки — это сущности, которые периодически публикуют сообщения уведомлений
для мониторируемых элементов, назначенных им (см. Пункт 7.9). Сообщение
уведомления содержит общий заголовок, за которым следует серия уведомлений. Формат
уведомлений специфичен для типа мониторируемого элемента (т.е. переменные, атрибуты
и уведомители событий).
После создания существование подписки независимо от сеанса клиента с сервером.
Это позволяет одному клиенту создать подписку, а второму, возможно резервному
клиенту, получать сообщения уведомлений от нее. Для защиты от неиспользования
клиентами подписки имеют настроенный срок жизни, который клиенты периодически
обновляют. Если любой клиент не обновляет срок жизни, срок жизни истекает, и
подписка закрывается сервером. Когда подписка закрывается, все мониторируемые
элементы, назначенные подписке, удаляются.
Подписки включают функции, поддерживающие обнаружение и восстановление
потерянных сообщений. Каждое сообщение уведомления содержит номер
последовательности, позволяющий клиентам обнаруживать пропущенные сообщения.
Когда нет уведомлений для отправки в интервале времени keep-alive, сервер отправляет
сообщение keep-alive, содержащее номер последовательности следующего отправляемого
сообщения уведомления. Если клиент не получает сообщение после истечения интервала
keep-alive, или если он определяет, что пропустил сообщение, он может запросить у
сервера повторную отправку одного или более сообщений.