ПНСТ 448-2020 Умное производство. Унифицированная архитектура ОРС. Часть 1. Общие положения

        ПНСТ 448-2020

(IEC/TR 62541-1:2016)

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Умное производство

УНИФИЦИРОВАННАЯ АРХИТЕКТУРА ОРС

Часть 1

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

Smart manufacturing. ОРС unified architecture. Part 1. Overview and concepts

ОКС 25.040.020

Срок действия с 2021-01-01

до 2024-01-01

Предисловие

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

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

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

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

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

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

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011** (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 123112, Москва, Инновационный центр Сколково, улица Нобеля, 1, e-mail: [email protected] и/или в Федеральное агентство по техническому регулированию и метрологии: 109074 Москва, Пресненская набережная, дом 10, стр.2.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе "Национальные стандарты" и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет ()

1 Область применения

Настоящий стандарт устанавливает концепции и общие положения унифицированной архитектуры ОРС (ОРС UА).

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

2 Нормативные ссылки

В настоящем стандарте нормативные ссылки не используются.

3 Термины и определения

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

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

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

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

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

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

3.5 клиент (client): Программное приложение, которое отправляет сообщения на серверы ОРС 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): Любой конкретный или абстрактный объект.

4 Сокращения

А&Е - сигналы и события (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).

5 Общие положения OPC UA

5.1 Область действия

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

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

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

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

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

5.2 Общие сведения

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

5.3 Цели проектирования

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

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

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

Рисунок 1 - Целевые приложения ОРС UA

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

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

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

- ХМL/текст,

- UA Binary.

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

- ОРС UA TCP,

- SOAP/HTTP,

- HTTPS.

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

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

5.4 Интегрированные модели и службы

5.4.1 Модель защищенности

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

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

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

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

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

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

5.4.1.3 Аудит

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

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

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

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

5.4.2 Интегрированная модель адресного пространства

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

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

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

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

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

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

5.4.3 Интегрированная объектная модель

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

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

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

5.4.4 Интегрированные службы

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

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

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

5.5 Сессии

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

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

5.6 Резервирование

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

6 Концепции системы

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

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

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

Рисунок 2 - Архитектура системы ОРС UA

6.2 Клиенты ОРС UA

Клиентская архитектура ОРС UA моделирует конечную точку клиента во взаимодействиях клиента и сервера. На рисунке 3 показаны основные элементы типичного клиента ОРС UA и их взаимосвязь.

Рисунок 3 - Архитектура клиента ОРС UA

Клиентское приложение - это код, который реализует функцию клиента. Приложение использует API клиента ОРС UA для отправки и получения запросов служб ОРС UA и ответов на сервер ОРС UA. Службы ОРС UA определены в разделе 7 и [4].

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

6.3 Серверы ОРС UA

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

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

Рисунок 4 - Архитектура сервера ОРС UA

6.3.2 Реальные объекты

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

6.3.3 Серверное приложение ОРС UA

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

6.3.4 Адресное пространство ОРС UA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.3.5 Сущности издателя/подписчика

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

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

6.3.5.2 Подписки

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

6.3.6 Интерфейс службы ОРС UA

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

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

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

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

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

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

6.3.7 Межсерверные взаимодействия

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

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

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

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

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

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

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

Рисунок 5 - Одноранговое взаимодействие между серверами

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

Рисунок 6 - Пример объединения серверов

7 Наборы служб

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

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

7.2 Набор служб обнаружения

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

7.3 Набор служб защищенного канала

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

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

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

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

Рисунок 7 - Защищенный канал и службы сессии

7.4 Набор служб сессии

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

7.5 Набор служб управления узлами

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

7.6 Набор служб представлений

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

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

7.7 Набор служб запросов

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

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

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

7.8 Набор служб атрибутов

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

7.9 Набор служб методов

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

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

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

7.10 Набор служб элементов мониторинга

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

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

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

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

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

7.11 Набор служб подписки

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

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

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

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

Приложение ДА

(справочное)

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

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

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

Библиография