1 ПОДГОТОВЛЕН Акционерным обществом "Всероссийский научно-исследовательский институт сертификации" (АО "ВНИИС") и Акционерным обществом "Российская венчурная компания" (АО "РВК") на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 194 "Кибер-физические системы"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 августа 2020 г. N 57-пнст

4 Настоящий стандарт является модифицированным по отношению к международному документу IEC/TR 62541-1:2016 "Унифицированная архитектура OPC. Часть 1. Общие положения" (IEC TR 62541-1:2016 "OPC unified architecture - Part 1: Overview and concepts", MOD) путем изменения отдельных фраз (слов, значений показателей, ссылок), которые выделены в тексте курсивом. Внесение указанных технических отклонений направлено на учет потребностей национальной экономики Российской Федерации.

Сопоставление структуры настоящего стандарта со структурой указанного международного документа приведено в дополнительном приложении ДА

5 Некоторые элементы настоящего стандарта могут быть объектами патентных прав. Международная электротехническая комиссия (МЭК) не несет ответственности за установление подлинности каких-либо или всех таких патентных прав

Настоящий стандарт устанавливает концепции и общие положения унифицированной архитектуры OPC (OPC UA).

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 адресное пространство (address space): Набор адресов объектов, который сервер OPC UA делает видимым для своих клиентов.

3.2 сигнал предупреждения (alarm): Уведомление о событии, связанном с состоянием.

3.3 атрибут (attribute): Базовая характеристика узла.

Примечание - Все атрибуты определяются в OPC UA и не могут быть определены клиентами или серверами. Атрибуты являются единственными элементами в адресном пространстве со значениями данных.

3.4 сертификат (certificate): Структура данных с цифровой подписью, которая описывает возможности клиента или сервера.

3.5 клиент (client): Программное приложение, которое отправляет сообщения на серверы OPC UA в соответствии со службами.

3.6 состояние (condition): Следствие события.

Примечание - Представляет состояния системы или одного из ее компонентов и всегда имеет определенный статус.

3.7 стек связи (communication stack): Многоуровневый набор программных модулей между приложением и аппаратным обеспечением, который обеспечивает различные функции для кодирования, шифрования и форматирования отправляемого сообщения, а также для декодирования, дешифрования и распаковки полученного сообщения.

3.8 сложные данные (complex data): Данные, которые состоят из элементов более чем одного простого типа данных, например структура.

3.9 обнаружение (discovery): Процесс, с помощью которого клиент OPC UA получает информацию о серверах OPC UA, включая информацию об оконечной точке и информацию о безопасности.

3.10 событие (event): Явление в системе или компоненте системы.

3.11 уведомитель событий (event notifier): Специальный атрибут узла, определяющий подписку клиента на данный узел для получения уведомлений о событиях.

3.12 информационная модель (information model): Организационная структура, которая определяет, характеризует и связывает информационные ресурсы данной системы или набора систем.

Примечание - Базовая модель адресного пространства поддерживает представление информационных моделей в адресном пространстве [1].

3.13 сообщение (message): Блок данных, передаваемый между клиентом и сервером и представляющий запрос или ответ службы.

3.14 метод (method): Способ выполнения действия с помощью вызываемой функции программного обеспечения, которая является компонентом объекта.

3.15 контролируемый элемент (monitored item): Определенная клиентом сущность на сервере, используемая для мониторинга атрибутов или уведомителей событий на предмет новых значений или событий и генерации уведомлений для них.

3.16 узел (node): Базовый компонент адресного пространства.

3.17 класс узла (node class): Класс узла в адресном пространстве.

Примечание - Классы узла определяют метаданные для компонентов объектной модели OPC UA, а также определяют конструкции для организации адресного пространства, такие как представления.

3.18 уведомление (notification): Объявление об обнаружении события или измененного значения атрибута.

Примечание - Уведомления отправляются в сообщениях-уведомлениях.

3.19 сообщение-уведомление (notification message): Сообщение, публикуемое через подписку и содержащее одно или несколько уведомлений.

3.20 объект/экземпляр объекта (object/object instance): Узел, представляющий физический или абстрактный элемент системы.

Примечание - Объекты моделируются с использованием объектной модели OPC UA. Примерами объектов являются системы, подсистемы и устройства. Объект может быть определен как экземпляр типа объекта.

3.21 профиль (profile): Набор возможностей, к которому сервер может требовать соответствия.

Примечание - Сервер может требовать соответствия более чем одному профилю.

3.22 программа (program): Исполняемый объект, который при вызове возвращает ответ, указывающий о начале выполнения, а затем возвращает промежуточные и окончательные результаты через подписки, определенные клиентом во время вызова.

3.23 ссылка (reference): Явная связь (именованный указатель) от одного узла к другому.

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

3.24 тип ссылки (reference type): Узел, который представляет определение типа ссылки.

Примечание - Тип ссылки определяет семантику ссылки. Имя типа ссылки определяет связь исходного и целевого узлов и, как правило, отражает операцию между ними, например "A содержит B".

3.25 корневой узел (root node): Начальный или верхний узел в иерархии.

3.26 сервер (server): Программное приложение, которое реализует и предоставляет службы.

3.27 служба (service): Операция на сервере OPC UA, вызываемая клиентом.

Примечание - Служба подобна вызову метода в языке программирования или операции в контракте WSDL веб-служб.

3.28 сессия (session): Логическое длительное соединение между клиентом и сервером.

Примечание - Сессия управляет информацией о состоянии между вызовами службы от клиента к серверу.

3.29 подписка (subscription): Определяемая клиентом оконечная точка на сервере, используемая для отправки уведомлений клиенту.

Примечание - "Подписка" - это общий термин, который описывает набор узлов, выбранных клиентом, (1) который сервер периодически отслеживает на наличие какого-либо состояния и (2) для которого сервер отправляет уведомления клиенту при обнаружении состояния.

3.30 переменная (variable): Узел, который содержит значение.

3.31 представление (view): Определенное подмножество адресного пространства, которое представляет интерес для клиента.

3.32 сущность (entity): Любой конкретный или абстрактный объект.

A&E - сигналы и события (Alarms and Events);

API - программный интерфейс приложения (Application Programming Interface);

COM - модель компонентного объекта (Component Object Model);

DA - доступ к данным (Data Access);

DCS - распределенная система управления (Distributed Control System);

MES - система управления производственными процессами (Manufacturing Execution System);

OPC - набор спецификаций стандартов для промышленных средств связи (Open Platform Communications);

OPC UA - унифицированная архитектура OPC (OPC Unified Architecture);

SCADA - диспетчерское управление и сбор данных (Supervisory Control And Data Acquisition);

SOAP - простой протокол доступа к объектам (Simple Object Access Protocol);

WSDL - язык описания веб-сервисов (Web Services Definition Language);

XML - расширяемый язык разметки (Extensible Mark-up Language);

ПЛК - программируемый логический контроллер (Programmable Logic Controller, PLC);

ЧМИ - человеко-машинный интерфейс (Human-Machine Interface, HMI).

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

- информационную модель для представления структуры, поведения и семантики;

- модель сообщений для взаимодействия между приложениями;

- модель связи для передачи данных между оконечными точками;

- модель соответствия для обеспечения интероперабельности между системами.

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

OPC UA предоставляет согласованную, интегрированную модель адресного пространства и службы. Это позволяет одному серверу OPC UA интегрировать данные, сигналы предупреждения, события и исторические данные в свое адресное пространство и предоставлять доступ к ним с помощью интегрированного набора служб. Службы включают в себя интегрированную модель обеспечения защиты.

OPC UA позволяет серверам предоставлять клиентам определения типов для объектов, к которым осуществляется доступ из адресного пространства. Это позволяет использовать информационные модели для описания содержимого адресного пространства. OPC UA позволяет отображать данные в различных форматах, включая двоичные структуры и документы XML. Формат данных может быть определен OPC, организациями по разработке стандартов или поставщиками. Через адресное пространство клиенты могут запрашивать у сервера метаданные с описанием формата данных. Клиенты, не имеющие заранее запрограммированных знаний о форматах данных, могут определять форматы во время выполнения и правильно использовать данные.

OPC UA поддерживает разные взаимосвязи между узлами и не ограничивается только иерархией. Сервер OPC UA может представлять данные в различных иерархиях, приспособленных к необходимому способу просмотра для клиентов. Гибкость в сочетании с поддержкой определений типов делает OPC UA применимой для широкого спектра областей. Как показано на рисунке 1, OPC UA предназначена для интерфейсов SCADA, ПЛК и DCS, а также для обеспечения интероперабельности между высокоуровневыми функциями.

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

OPC UA предназначена для поддержки широкого спектра серверов с большим диапазоном размеров, производительности, платформ исполнения и функциональных возможностей от ПЛК производственных цехов до корпоративных серверов. Поэтому OPC UA определяет полный набор возможностей, и серверы могут реализовывать подмножество этих возможностей. Для обеспечения интероперабельности OPC UA определяет подмножества, называемые профилями, соответствия которым могут требовать серверы. Клиенты могут обнаруживать профили сервера и взаимодействовать с сервером на основе профилей.

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

- XML/текст,

- UA Binary.

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

- OPC UA TCP,

- SOAP/HTTP,

- HTTPS.

Если клиенты и серверы поддерживают несколько протоколов передачи и кодировок, то таким образом они предоставляют конечным пользователям возможность выбирать компромисс между производительностью и совместимостью веб-служб XML во время развертывания.

OPC UA разработана как путь перехода для клиентов и серверов OPC, основанных на технологии Microsoft COM. При разработке OPC UA были предприняты меры предосторожности, чтобы существующие данные, предоставляемые COM-серверами OPC (DA, HDA и A&E), могли быть легко сопоставлены и отображены через OPC UA. Поставщики могут по своему усмотрению перенести свои продукты в OPC UA или использовать внешние оболочки для преобразования из OPC COM в OPC UA и наоборот. Каждая из предыдущих спецификаций OPC определяла свою собственную модель адресного пространства и свой собственный набор служб. OPC UA объединяет предыдущие модели в единое интегрированное адресное пространство с единым набором служб.

5.4.1.1 Общие положения

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

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

5.4.1.2 Обнаружение и установление сессии

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

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

5.4.1.3 Аудит

OPC UA включает поддержку журналов аудита защищенности с возможностью сопоставления между журналами аудита клиента и сервера. При обнаружении проблемы защиты на сервере может быть найдена и изучена соответствующая запись в журнале аудита клиента. OPC UA предоставляет возможность серверам генерировать уведомления о событиях аудита клиентам для их обработки и регистрации. OPC UA определяет параметры аудита защищенности, которые могут быть включены в записи журнала аудита и уведомления о событиях аудита. Типы данных для параметров аудита определены в [1]. Не все серверы и клиенты предоставляют функции аудита. Предоставляемые функции указываются в профилях [2].

5.4.1.4 Защищенность транспортного уровня

Защищенность OPC UA дополняет инфраструктуру защиты, предоставляемую большинством платформ с поддержкой веб-служб.

Адресное пространство OPC UA представляет его содержимое в виде набора узлов, связанных ссылками.

Простейшие характеристики узлов определяются атрибутами OPC. Атрибуты являются единственными элементами сервера со значениями данных. Типы данных, которые определяют значения атрибутов, могут быть простыми или сложными.

Узлы в адресном пространстве определяются в соответствии с их использованием и значением. Классы узлов определяют метаданные для адресного пространства OPC UA. Классы узлов OPC UA определены в [3].

Базовый класс узла определяет атрибуты, общие для всех узлов, обеспечивая идентификацию, классификацию и именование. Каждый класс узла наследует эти атрибуты и может дополнительно определять собственные атрибуты.

Для обеспечения интероперабельности клиентов и серверов адресное пространство OPC UA имеет иерархическую структуру с верхними уровнями, одинаковыми для всех серверов. Хотя узлы в адресном пространстве обычно доступны через иерархию, они могут иметь ссылки друг на друга, что позволяет адресному пространству представлять взаимосвязанную сеть узлов. Модель адресного пространства определена в [3].

Серверы OPC UA могут размещать адресное пространство в представлениях для упрощения доступа клиентов. Более подробная информация об адресном пространстве приведена в 6.3.4.3.

Объектная модель OPC UA предоставляет согласованный, интегрированный набор классов узлов для представления объектов в адресном пространстве. Объектная модель представляет объекты с точки зрения переменных, событий и методов, а также отношений с другими объектами [3].

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

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

Интерфейс между клиентами и серверами OPC UA определяется как набор служб. Службы организованы в логические группы, называемые наборами служб. Наборы служб определены в разделе 7 и [4].

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

В целях эффективности сообщения OPC UA могут быть закодированы в виде текста XML или в двоичном формате. Передача сообщений может проводиться с использованием нескольких базовых протоколов передачи, например TCP или веб-служб по HTTP. Службы могут предоставлять разные кодировки и протоколы передачи [5].

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

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

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

Архитектура систем OPC UA моделирует клиентов и серверы OPC UA как взаимодействующих партнеров. Каждая система может содержать несколько клиентов и серверов. Каждый клиент может взаимодействовать одновременно с одним или несколькими серверами, и каждый сервер может взаимодействовать одновременно с одним или несколькими клиентами. Приложение может объединять компоненты сервера и клиента для обеспечения взаимодействия с другими серверами и клиентами согласно 6.3.7.

Клиенты и серверы OPC UA определены в 6.2 и 6.3. На рисунке 2 приведена архитектура с объединенным сервером и клиентом.

Клиентская архитектура OPC UA моделирует конечную точку клиента во взаимодействиях клиента и сервера. На рисунке 3 показаны основные элементы типичного клиента 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.

Архитектура сервера OPC UA моделирует оконечную точку сервера во взаимодействиях клиента и сервера. На рисунке 4 показаны основные элементы сервера OPC UA и их взаимосвязь.

Реальные объекты - это физические или программные объекты, которые доступны серверному приложению OPC UA или которые оно обслуживает внутри. Примеры включают физические устройства и диагностические счетчики.

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

6.3.4.1 Узлы адресного пространства

Адресное пространство моделируется как набор узлов, доступных клиентам с использованием служб OPC UA (интерфейсов и методов). Узлы в адресном пространстве используются для представления реальных объектов, их определений и ссылок друг на друга.

6.3.4.2 Организация адресного пространства

Подробная информация о блоках метамодели, используемых для последовательного создания адресного пространства из взаимосвязанных узлов, приведена в [3]. Серверы могут свободно организовывать свои узлы в адресном пространстве. Использование ссылок между узлами позволяет серверам организовывать адресное пространство в иерархию, полную ячеистую сеть узлов или любое возможное сочетание.

Узлы и ссылки OPC UA и их предполагаемая организация в пространстве адресов определены в [1]. Некоторые профили не требуют, чтобы были реализованы все узлы UA.

6.3.4.3 Представления адресного пространства

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

6.3.4.4 Поддержка информационных моделей

Адресное пространство OPC UA поддерживает информационные модели. Поддержка предоставляется через:

а) ссылки на узлы, которые позволяют объектам в адресном пространстве быть связанными друг с другом;

б) узлы типов объектов, которые предоставляют семантическую информацию для реальных объектов (определения типов);

в) узлы типов объектов для поддержки подклассов определений типов;

г) определения типов данных, представленных в адресном пространстве, которые позволяют использовать отраслевые типы данных;

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

6.3.5.1 Элементы мониторинга

Элементы мониторинга - это объекты на сервере, созданные клиентом и отслеживающие узлы адресного пространства и их реальные аналоги. При обнаружении изменения данных или возникновения события/сигнала предупреждения элементы мониторинга генерируют уведомление, которое передается клиенту посредством подписки.

6.3.5.2 Подписки

Подписка - это конечная точка на сервере, которая публикует уведомления для клиентов. Клиенты контролируют скорость публикаций путем отправки сообщения публикации.

6.3.6.1 Общие положения

Службы OPC UA определены в разделе 7 и [4].

6.3.6.2 Службы запроса/ответа

Службы запроса/ответа - это службы, вызываемые клиентом через интерфейс службы OPC UA для выполнения определенной задачи на одном или нескольких узлах в адресном пространстве и для возврата ответа.

6.3.6.3 Службы подписки

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

Межсерверные взаимодействия - это взаимодействия, при которых один сервер выступает в роли клиента другого сервера. Межсерверные взаимодействия позволяют разрабатывать серверы, которые:

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

б) объединяются в многоуровневую архитектуру серверов для обеспечения:

1) агрегации данных с серверов нижнего уровня;

2) высокоуровневой структуры данных для клиентов;

3) клиентские интерфейсы концентратора для единых точек доступа к нескольким базовым серверам.

На рисунке 5 показано взаимодействие между серверами.

На рисунке 6 представлено объединение серверов OPC UA для вертикального доступа к данным на предприятии.

Службы OPC UA разделены на наборы служб, каждый из которых определяет логическую группу служб для доступа к определенному аспекту сервера. Наборы служб определены далее и в [4]. Поддержка сервером набора служб или конкретной службы в наборе служб определяется в профиле [2].

Набор служб обнаружения определяет службы, используемые для обнаружения доступных серверов OPC UA. Набор также обеспечивает клиентам способ чтения конфигурации защищенности для подключения к серверу. Службы обнаружения реализуются отдельными серверами и выделенными серверами обнаружения. Известные выделенные серверы обнаружения предоставляют клиентам возможность обнаружить все зарегистрированные серверы OPC UA. Использование служб обнаружения с выделенными серверами обнаружения определено в [6].

Набор служб защищенного канала определяет службы для открытия канала связи, который обеспечивает конфиденциальность и целостность всех сообщений обмена с сервером.

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

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

Набор служб сессии определяет службы для установления соединения на прикладном уровне в контексте сессии от имени конкретного пользователя.

Набор служб управления узлами позволяет клиентам добавлять, изменять и удалять узлы в адресном пространстве. Службы управления узлами предоставляют интерфейс для конфигурирования серверов.

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

Набор служб представлений позволяет клиентам обнаруживать узлы в представлении путем просмотра. Просмотр позволяет клиентам перемещаться вверх и вниз по иерархии или следовать ссылкам между узлами в представлении. Таким образом, просмотр позволяет клиентам обнаруживать структуру представления.

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

Запросы позволяют клиентам выбирать подмножество узлов в представлении на основе критериев фильтра, предоставляемых клиентом. Узлы, выбранные в представлении по результатам запроса, называются набором результатов.

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

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

Методы представляют вызовы функций объектов [3]. Методы вызываются и возвращаются после завершения независимо от результата. Время выполнения методов может варьироваться в зависимости от выполняемой ими функции.

Набор служб методов определяет средства для вызова методов. Метод всегда является компонентом объекта. Обнаружение осуществляется через службы просмотра и запроса. Клиенты обнаруживают методы, поддерживаемые сервером, путем просмотра имеющихся объектов, которые идентифицируют поддерживаемые методы.

Поскольку методы могут контролировать некоторые аспекты производственной работы, вызов метода может зависеть от условий окружающей среды или других условий. Это может быть особенно актуально при попытке повторно вызвать метод сразу после завершения выполнения. Условия вызова метода могут еще не вернуться в состояние, позволяющее повторный запуск метода. Методы могут поддерживать одновременные вызовы или иметь один вызов, выполняемый в данный момент времени.

Набор служб элементов мониторинга используется клиентом для создания и обслуживания элементов мониторинга. Элементы мониторинга отслеживают переменные, атрибуты и уведомители событий. Элементы мониторинга генерируют уведомления при обнаружении определенных условий, а также отслеживают переменные на предмет изменения значения или статуса, атрибуты на предмет изменения значения и уведомители событий на предмет созданных отчетов о сигналах предупреждения и событиях.

Каждый элемент мониторинга идентифицирует элемент для мониторинга и подписку для периодической публикации уведомлений для клиента (см. 7.11). Каждый элемент мониторинга определяет скорость мониторинга (измерения) элемента, а для переменных и уведомителей событий - критерии фильтрации для генерации уведомления. Критерии фильтра для атрибутов определяются их определениями атрибутов [4].

Частота измерения элемента мониторинга может быть выше, чем частота публикации подписки. По этой причине элемент мониторинга может быть настроен на очередь всех уведомлений или на очередь только последних уведомлений для передачи по подписке. В последнем случае размер очереди равен единице.

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

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

Набор служб подписки используется клиентом для создания и обслуживания подписок. Подписки - это сущности, которые периодически публикуют сообщения уведомления для назначенного им элемента мониторинга (см. 7.9). Сообщение уведомления содержит общий заголовок, за которым следует серия уведомлений. Формат уведомлений зависит от типа элемента мониторинга (т.е. переменных, атрибутов и уведомлений о событиях).

После создания существование подписки не зависит от сессии клиента с сервером. Это позволяет одному клиенту создать подписку, а второму, возможно резервному клиенту, получать от нее сообщения уведомления.

Для защиты от неиспользования клиентами подписки имеют настроенный срок службы, который клиенты периодически обновляют. Если клиент не может продлить срок действия, срок действия истекает, и сервер закрывает подписку. Когда подписка закрыта, все элементы мониторинга, назначенные подписке, удаляются.

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

В таблице ДА.1 приведено сопоставление структуры настоящего стандарта со структурой примененного в нем международного документа.