ГОСТ Р 71809-2024 Цифровая промышленность. Унифицированная архитектура OPC. Часть 4. Сервисы

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

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

ГОСТР

71809—

2024

Цифровая промышленность

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

Часть 4

Сервисы

(IEC 62541-4:2020, NEQ)

Издание официальное

Москва Российский институт стандартизации 2025

ГОСТ Р 71809—2024

Предисловие

1 РАЗРАБОТАН Ассоциацией «Цифровые инновации в машиностроении» (АЦИМ) и Федеральным государственным бюджетным учреждением «Российский институт стандартизации» (ФГБУ «Институт стандартизации»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 306 «Измерения, управление и автоматизация в промышленных процессах»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 ноября 2024 г. № 1805-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта МЭК 62541-4:2020 «Унифицированная архитектура ОРС. Часть 4. Сервисы» (IEC 62541-4:2020 «ОРС unified architecture — Part 4: Services», NEQ)

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

©Оформление. ФГБУ «Институт стандартизации», 2025

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

II

ГОСТ Р 71809—2024

Содержание

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

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

3 Термины, определения и сокращения....................................................2

3.1 Термины и определения............................................................2

3.2 Сокращения......................................................................2

4 Общие положения....................................................................3

4.1 Условные обозначения для определения служб........................................3

4.2 Модель набора служб..............................................................4

4.3 Процедуры службы «запрос/ответ»...................................................8

5 Наборы служб........................................................................8

5.1 Общие положения.................................................................8

5.2 Заголовок ответа и заголовок запроса службы..........................................8

5.3 Результаты службы................................................................8

5.4 Набор служб обнаружения..........................................................9

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

5.6 Набор служб сессии..............................................................24

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

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

5.9 Набор служб запросов............................................................50

5.10 Набор службы атрибутов.........................................................56

5.11 Набор службы метода............................................................66

5.12 Набор служб элемента мониторинга................................................69

5.13 Набор службы подписки..........................................................84

6 Поведение при использовании служб..................................................103

6.1 Безопасность...................................................................103

6.2 Службы авторизации.............................................................111

6.3 Вызов службы без сессии.........................................................113

6.4 Сертификаты программного обеспечения............................................115

6.5 Аудит..........................................................................115

6.6 Резервирование.................................................................118

6.7 Восстановление соединений......................................................132

6.8 Долговечные подписки...........................................................133

7 Определения типов основных параметров..............................................134

7.1 Описание приложения...........................................................134

7.2 Сертификат экземпляра приложения...............................................135

7.3 Результат просмотра.............................................................136

7.4 Фильтр контента.................................................................136

7.5 Счетчик........................................................................147

7.6 Точка продолжения..............................................................147

7.7 Значение данных................................................................148

7.8 Диагностическая информация.....................................................150

7.9 Параметры конфигурации обнаружения.............................................151

7.10 Описание конечной точки........................................................151

7.11 Расширенный идентификатор узла................................................152

III

ГОСТ Р 71809—2024

7.12 Расширяемый параметр.........................................................153

7.13 Индекс.......................................................................153

7.14 Идентификатор целого числа.....................................................153

7.15 Режим безопасности сообщений..................................................153

7.16 Параметры контроля............................................................154

7.17 Параметры фильтра мониторинга.................................................155

7.18 Режим мониторинга.............................................................161

7.19 Параметры атрибута узла........................................................161

7.20 Параметры данных уведомления..................................................167

7.21 Уведомительное сообщение......................................................169

7.22 Область числовых значений......................................................169

7.23 Набор данных запроса..........................................................170

7.24 Идентификатор «чтение значения»................................................171

7.25 Ссылочное описание............................................................172

7.26 Относительный путь............................................................172

7.27 Зарегистрированный сервер.....................................................173

7.28 Заголовок запроса..............................................................174

7.29 Заголовок ответа...............................................................176

7.30 Отказ службы..................................................................177

7.31 Токен аутентификации сессии....................................................177

7.32 Дата подписи..................................................................178

7.33 Подписанный сертификат программного обеспечения................................179

7.34 Код состояния.................................................................179

7.35 Временные отметки для возврата.................................................187

7.36 Параметры токена идентификации пользователя....................................187

7.37 Политика токенов пользователя...................................................195

7.38 Время версии..................................................................196

7.39 Описание представления........................................................196

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

IV

ГОСТ Р 71809—2024

Введение

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

Настоящий стандарт определяет концепцию вызова служб без участия сессий, а также общую структуру служб, позволяющую передавать любое количество атрибутов в службу добавления узлов с возможностями: повторной отправки всех данных элементов мониторинга в подписке с помощью метода Resend Data, поддержки долговременных подписок (время жизни — часы или дни), поддержки обнаружения в масштабах всей сети с помощью фильтров возможностей.

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

В связи с тем, что некоторые элементы данного стандарта могут являться объектом патентных прав, ТК 306 не несет ответственности за выявление любых таких патентных прав.

V

ГОСТ Р 71809—2024

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

Цифровая промышленность

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

Часть 4

Сервисы

ОРС unified architecture. Part 4. Services

Дата введения — 2025—02—01

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

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

Службы, поддерживаемые для реализации сервисами ОРС UA, определяют ряд отображений. Например, в ГОСТ Р 71811 сервисы реализуют методы сетевых служб XML, а также WSDL. Стандарт МЭК 62541-7 [1] определяет службы, которые должны быть реализованы, чтобы соответствовать определенному профилю.

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

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

ГОСТ Р 71807 Цифровая промышленность. Унифицированная архитектура ОРС. Часть 2. Модель безопасности

ГОСТ Р 71808 Цифровая промышленность. Унифицированная архитектура ОРС. Часть 3. Модель адресного пространства

ГОСТ Р 71810—2024 Цифровая промышленность. Унифицированная архитектура ОРС. Часть 5. Информационная модель

ГОСТ Р 71811 Цифровая промышленность. Унифицированная архитектура ОРС. Часть 6. Сопоставления

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.

Издание официальное

1

ГОСТ Р 71809—2024

3 Термины, определения и сокращения

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

3.1.1 неисправный сервер (failed server): Сервер, который не может работать.

Примечание — В системах с резервированием ОРС UA отказавший сервер — сервер, который недоступен или не может обслуживать данные.

3.1.2 обход отказа (failover): Акт переключения источника или цели информации.

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

3.1.3 сервер-шлюз (gateway server): Сервер, который выступает в качестве посредника для одного или нескольких серверов.

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

3.1.4 имя хоста (host name): Уникальный идентификатор машины в сети.

Примечание — Данный идентификатор является уникальным в пределах локальной сети, но может быть уникальным в глобальном масштабе. Например, идентификатором может быть IP-адрес.

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

Примечание — Это может относиться к серверам, клиентам или сетям.

3.1.6 набор резервных серверов (redundant server set): Два или более сервера, которые являются резервными по отношению друг к другу.

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

3.1.7 токен безопасности (security token): Идентификатор для набора криптографических ключей.

Примечание — Все токены безопасности принадлежат контексту безопасности. Для ОРС UA контекстом безопасности является защищенный канал.

3.1.8 сертификат программного обеспечения (software certificate): Цифровой сертификат для программного продукта, который может быть установлен на нескольких хостах для описания возможностей программного продукта.

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

3.2 Сокращения

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

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

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

IP — интернет-протокол (Internet protocol);

NAT — преобразование сетевых адресов (Network Address Translation);

OPC — система стандартов открытой платформы взаимодействия (Open Platform Communication);

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

2

ГОСТ Р 71809—2024

URI — унифицированный идентификатор ресурса (Uniform Resource Identifier);

URL — унифицированный указатель местонахождения ресурса (Uniform Resource Locator);

UTC — всемирное координированное время (Coordinated Universal Time);

HTTP — протокол передачи гипертекста (HyperText Transfer Protocol);

HTTPS — расширение протокола HTTP для поддержки шифрования в целях повышения безопасности (данные передаются поверх криптографических протоколов);

СДС — список доверия сертификатов (Certificate Trust List);

СО — центр сертификации (Certificate Authority);

СОС — список отозванных сертификатов (Certificate Revocation List).

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

4.1 Условные обозначения для определения служб

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

Таблица 1—Таблица определения служб

Графы «Имя», «Тип» и «Описание» содержат имя, тип данных и описание каждого параметра. Все параметры являются обязательными, хотя некоторые могут не использоваться при определенных обстоятельствах. В графе «Описание» указывается значение, которое должно быть предоставлено, если параметр не используется.

В этих таблицах определены два типа параметров: простые и сконструированные. Простые параметры имеют простой тип данных, например «Булево» или «Строка».

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

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

Таблица 2 — Типы параметров, определенные в ГОСТ Р 71808

Тип параметра

Base Data Type

Boolean

Byte String

Double

Duration

3

ГОСТ Р 71809—2024

Параметры сервисных примитивов «Запрос» и «Указание» представлены в таблице 1 как параметры запроса. Аналогично параметры сервисных примитивов «Ответ» и «Подтверждение» представлены в таблице 1 как параметры ответа. Все параметры запроса и ответа передаются между отправителем и получателем без изменений. Поэтому отдельные графы для значений параметров запроса, указания, ответа и подтверждения не требуются и намеренно опущены для улучшения понимания контента.

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

В настоящий стандарт включены термины и определения, дано описание других частей серии стандартов «Цифровая промышленность. Унифицированная архитектура ОРС», совместно с которыми его следует использовать.

4.2 Модель набора служб

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

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

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

Службы обнаружения

Рисунок 1 — Набор служб обнаружения

4

ГОСТ Р 71809—2024

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

Службы защищенного канала

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

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

Службы сессионного уровня

Сервер

Сессия

Рисунок 3 — Набор служб уровня сессий

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

Рисунок 4 — Набор служб управления узлами

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

5

ГОСТ Р 71809—2024

Рисунок 5 — Набор служб представления

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

Рисунок 6 — Набор служб атрибутов

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

6

ГОСТ Р 71809—2024

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

Рисунок 8 — Наборы служб элемента мониторинга и подписок

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

Эти уведомления ставятся в очередь для передачи клиенту по подпискам.

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

7

ГОСТ Р 71809—2024

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

4.3 Процедуры службы «запрос/ответ»

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

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

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

Для выполнения этих операций и клиент, и сервер могут использовать API стека связи для создания и интерпретации сообщений и для доступа к запрошенной операции.

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

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

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

В настоящем разделе определены наборы служб ОРС UA и их службы. Раздел 7 содержит определения общих параметров, используемых этими службами. В 6.5 описаны требования к аудиту для всех служб.

Поддерживает ли сервер набор служб или службу в наборе служб, определяется его профилем. Профили описаны в МЭК 62541-7 [1].

5.2 Заголовок ответа и заголовок запроса службы

Каждый запрос службы имеет заголовок запроса, а каждый ответ службы имеет заголовок ответа.

Структура заголовка запроса определена в 7.28 и содержит общие параметры запроса, такие как токен аутентификации, временную отметку и обработку запроса.

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

5.3 Результаты службы

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

Результаты службы определяются через код состояния (см. 7.34).

Статус вызова службы представлен результатом службы, содержащимся в заголовке ответа (см. 7.29). Механизм возврата этого параметра зависит от технологии связи, используемой для передачи ответа службы, и определен в ГОСТ Р 71811.

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

Следующие случаи определяют использование этих параметров.

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

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

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

Службы определяют различные конкретные коды состояния, и сервер должен использовать эти конкретные коды состояния, как описано в службе. Клиент должен иметь возможность обрабатывать 8

ГОСТ Р 71809—2024

эти специфические для службы коды состояния. Кроме того, клиент должен ожидать другие общие коды состояния, определенные в таблицах 177 и 178. Дополнительные подробности по обработке клиентом конкретных кодов состояния могут быть определены в МЭК 62541-7 [1].

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

Синтаксический анализ сообщения может завершиться отказом из-за синтаксических ошибок или если данные, содержащиеся в сообщении, превышают диапазоны, поддерживаемые получателем. Когда это происходит, сообщения должны быть отклонены получателем. Если получателем является сервер, то он должен вернуть ответ сбой службы с кодом результата «Некорректно_Ошибка декодирования» или «Некорректно_Превышены пределы кодирования». Если получателем является клиент, то стек связи должен сообщить об этих ошибках клиентскому приложению.

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

Клиенты, которые получают от сервера отказы «Некорректно_Превышены пределы кодирования», вероятно, должны будут переформулировать свои запросы. Администратору может потребоваться увеличить лимиты для клиента, если он получает ответ от сервера с этим сбоем.

В некоторых случаях ошибки синтаксического анализа являются непоправимыми, и вернуть ошибку невозможно. Например, входящее сообщение может превышать буферный объем получателя. В этих случаях эти ошибки могут рассматриваться как сбой связи, требующий восстановления защищенного канала (см. 5.5).

Клиент и сервер уменьшают вероятность непоправимой ошибки, обменивая свои ограничения на размер сообщения в службе создания сессии. Это позволит любой из сторон избежать отправки сообщения, вызывающего сбой связи. Сервер должен вернуть сбой «Некорректно_Ответ слишком велик», если сериализованное ответное сообщение превышает размер сообщения, указанного клиентом. Точно так же стек связи с клиентом должен сообщать приложению об ошибке «Некорректно_3апрос слишком велик» перед отправкой сообщения, превышающего лимит сервера.

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

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

5.4.1 Обзор

Настоящий набор служб определяет службы, используемые для обнаружения конечных точек, реализуемых сервером, и чтения конфигурации безопасности для этих конечных точек. Службы обнаружения реализуются отдельными серверами и выделенными серверами обнаружения. В МЭК 62541-12 [2] описано, как использовать службы обнаружения с выделенными серверами обнаружения.

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

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

Процесс обнаружения с использованием поиска сервера проиллюстрирован на рисунке 9. Для ясности в поиске серверов и получении конечных точек на рисунке 9 опущено установление защищенного канала (с режимом безопасности сообщений «ОТСУТСТВУЕТ»),

9

ГОСТ Р 71809—2024

Конечная точка Конечная Конечная

обнаружения точка сессии точка сессии

Рисунок 9 — Процесс обнаружения

URL-адрес конечной точки обнаружения должен предоставлять всю информацию, которая необходима клиенту для подключения к конечной точке обнаружения.

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

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

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

a) URI приложения, указанные в сертификате сервера, являются такими же, как URI приложения, указанные в описании конечной точки;

б) сертификат сервера, возвращенный в ответе создания сессии, совпадает с сертификатом, использованным для создания защищенного канала;

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

Если клиент обнаруживает, что одно из вышеуказанных требований не выполняется, то клиент должен закрыть защищенный канал и сообщить об ошибке.

Клиент должен убедиться, что имя хоста, указанное в сертификате сервера, совпадает с именем хоста, указанным в URL конечной точки, указанном в описании конечной точки, возвращенном службой создания сессии. Если имеется разница, то клиент должен сообщить о разнице и служба может закрыть защищенный канал. Серверы должны добавить все возможные имена хоста, такие как MyHost и MyHost.local, в сертификат сервера. Сюда входят IP-адреса хоста или имени хоста, предоставленные маршрутизатором NAT, используемым для подключения к серверу.

10

ГОСТ Р 71809—2024

5.4.2 Поиск серверов

5.4.2.1 Описание

Служба поиска возвращает известные серверы соответствующему сервису или серверу обнаружения. Поведение серверов обнаружения подробно описано в МЭК 62541-12 [2].

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

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

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

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

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

Служба поиска не требует защиты сообщений, но требует безопасность на транспортном уровне.

Доступ к серверам допустимо получать через сервер шлюза, и он должен иметь значение, указанное для сервера шлюза URI в их описании приложения (см. 7.1). URL обнаружения, указанные в описании приложения, должны принадлежать серверу шлюза.

Серверам обнаружения допустимо возвращать несколько записей для одного и того же сервера, если к этому серверу можно получить доступ по нескольким путям. Службу поиска допустимо использовать без защиты, и поэтому она уязвима для атак типа «отказ в обслуживании» (DOS). Сервер должен минимизировать объем обработки, необходимый для отправки ответа для этой службы. В условиях высокого трафика сервер должен добавить небольшую задержку перед началом обработки запроса.

5.4.2.2 Параметры

Параметры службы поиска определены в таблице 3.

Таблица 3 — Параметры службы поиска серверов

11

ГОСТ Р 71809—2024

Окончание таблицы 3

5.4.2.3 Результаты службы

Общие коды состояния определены в таблице 177.

5.4.3 Поиск серверов в сети

5.4.3.1 Описание

Служба возвращает серверы, известные серверу обнаружения. В отличие от поиска серверов, эта служба реализуется только серверами обнаружения.

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

Эта служба не требует защиты сообщений, но может потребовать защиты транспортного уровня.

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

Службу поиска допустимо использовать без защиты, и поэтому она уязвима для атак типа «отказ в обслуживании» (DOS). Сервер должен минимизировать объем обработки, необходимый для отправки ответа для данной службы.

5.4.3.2 Параметры

Параметры службы поиска определены в таблице 4.

Таблица 4 — Параметры службы поиска серверов в сети

12

Окончание таблицы 4

ГОСТ Р 71809—2024

5.4.3.3 Результаты службы

Общие коды состояния определены в таблице 177.

5.4.4 Получение конечных точек

5.4.4.1 Описание

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

Эта служба не требует защиты сообщений, но может потребовать защиты транспортного уровня.

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

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

Конфигурация безопасности для конечной точки состоит из четырех компонентов:

- сертификат экземпляра серверного приложения;

- режим безопасности сообщений;

- политика безопасности;

- поддерживаемые токены идентификации пользователя.

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

Если для URI политики безопасности установлено значение «ОТСУТСТВИЕ» и ни одна из политик токенов пользователя не требует шифрования, клиент должен игнорировать экземпляр серверного приложения.

Каждое описание конечной точки также указывает URI для транспортного профиля, который поддерживает конечная точка. Транспортные профили определяют такую информацию, как формат кодирования сообщений и версия протокола, которые определены в МЭК 62541-7 [1].

13

ГОСТ Р 71809—2024

Сообщения защищаются путем применения стандартных алгоритмов криптографии к сообщениям перед их отправкой по сети. Точный набор используемых алгоритмов зависит от политики безопасности для конечной точки. Определение профилей для общих политик безопасности и присвоение им уникального URI — см. МЭК 62541-7 [1]. Приложения должны иметь встроенную информацию о поддерживаемых ими политиках безопасности, в результате в описании конечной точки указывается только URI профиля для политики безопасности. Клиент не может подключиться к конечной точке, которая не поддерживает политику безопасности, которую она распознает.

В описании конечной точки допустимо указание, что режим безопасности сообщения «ОТСУТСТВУЕТ». Эта конфигурация не рекомендуется, если приложения не обмениваются данными в физически изолированной сети, где риск вторжения чрезвычайно мал.

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

В случае, когда служба используется без защиты, она уязвима для атак типа «отказ в обслуживании» (DOS). Сервер должен минимизировать объем обработки, необходимый для отправки ответа для данной службы.

Описания конечных точек, возвращаемых в ответе, должны указывать информацию о конечной точке для сервера шлюза, которая определена для доступа к другому серверу. В названных ситуациях URI сервера шлюза указывается в описании конечной точки, и все проверки безопасности, используемые для проверки сертификатов, должны использовать URI сервера шлюза (см. 6.1.3) вместо URI сервера.

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

Конечная точка Конечная обнаружения точка сессии

Рисунок 10 — Использование сервера шлюза

5.4.4.2 Параметры

Параметры службы определены в таблице 5.

14

Таблица 5 — Описание службы получения конечных точек

ГОСТ Р 71809—2024

5.4.4.3 Результаты службы

Общие коды состояния определены в таблице 177.

5.4.5 Регистрация сервера

5.4.5.1 Описание

Данная служба реализуется серверами обнаружения.

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

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

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

Сервер предоставляет только свой URI сервера и URL-адрес конечных точек обнаружения на сервер обнаружения. Клиенты должны использовать службу получения конечных точек для получения самой последней информации о конфигурации непосредственно с сервера.

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

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

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

15

ГОСТ Р 71809—2024

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

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

Администратор

Сервер

Сервер обнаружения

Клиент

Начало

Истечение таймера регистрации

Регистрация сервера (Онлайн = Истина)

Регистрация сервера (Онлайн = Истина)

Поиск серверов ()

Срок онлайн-регистрации истекает, серверы должны регистрироваться не реже одного раза в 10 мин

Описания приложений[ ]

Остановка

Удаление истекших регистраций

Регистрация сервера (Онлайн = Истина)

Репострация сервера (Онлайн = Ложь)

Поиск серверов ()

Ничего не найдено

Поиск серверов ()

Ничего не найдено

Рисунок 11 — Процесс регистрации серверов, запускаемых вручную

Процесс регистрации для серверов, запускаемых автоматически, показан на рисунке 12.

Администратор

Сервер

Файловая система

Сервер обнаружения

Клиент

Установка

Создание файла семафора

Регистрация сервера

Загрузка регистрации при запуске

Проверка семафора

* Сохранение

। регистрации

D Проверка

файла семафора

Поиск серверов()

Деинсталляция

Удаление

Описания приложений[]

у Файл семафора

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

Проверка семафора

Удаление регистрации

Поиск серверов()

Рисунок 12 — Процесс регистрации серверов, запускаемых автоматически

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

16

ГОСТ Р 71809—2024

еще раз и указать, что он отключен. Период повторной регистрации должен быть настраиваемым. Максимальное время составляет 10 мин. При возникновении ошибки во время регистрации (например, сервер обнаружения не запущен) сервер должен периодически повторять попытки регистрации. Частота этих попыток должна начинаться с 1 с, но постепенно увеличиваться до тех пор, пока частота регистрации не станет такой же, как при отсутствии ошибок. Рекомендуемый подход состоит в том, чтобы удвоить период каждой попытки до достижения максимума.

Когда автоматически запускаемый сервер (или его программа установки) регистрируется на сервере обнаружения, он должен предоставить путь к файлу семафора, который сервер обнаружения может использовать, чтобы определить, был ли сервер удален с машины. Сервер обнаружения должен иметь доступ на чтение к файловой системе, содержащей файл.

5.4.5.2 Параметры

Параметры службы определены в таблице 6.

Таблица 6 — Параметры службы регистрации сервера

5.4.5.3 Результаты службы

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

Таблица 7 — Результирующие коды службы регистрации сервера

5.4.6 Регистрация сервера 2

5.4.6.1 Описание

Эта служба регистрации используется серверами обнаружения.

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

Серверы, поддерживающие регистрацию сервера 2, должны попытаться зарегистрироваться на сервере обнаружения, использующем эту службу, и должны вернуться к регистрации сервера, если регистрация сервера 2 завершается неудачно со статусом «Некорректно_Служба не поддерживается».

17

ГОСТ Р 71809—2024

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

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

5.4.6.2 Параметры

Параметры службы регистрации определены в таблице 8.

Таблица 8 — Регистрации сервера 2

5.4.6.3 Результаты службы регистрации

В таблице 9 определены результаты службы регистрации. Общие коды состояния определены в таблице 177.

Таблица 9 — Результирующие коды службы регистрации сервера 2

5.4.6.4 Коды состояния

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

18

Таблица 10 — Результирующие коды уровня работы регистрации сервера 2

ГОСТ Р 71809—2024

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

5.5.1 Обзор

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

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

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

Логические соединения могут быть инициированы клиентом или сервером, как описано в ГОСТ Р 71811.

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

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

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

Политики безопасности, определенные в МЭК 62541-7 [1], отключают аутентификацию и шифрование, в результате чего создается защищенный канал, не обеспечивающий безопасности.

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

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

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

19

ГОСТ Р 71809—2024

Клиент ОРС UA

Сервер ОРС UA

Приложение ОРС UA

Сессия

Приложение ОРС UA

Стек связи

4

Защищенный канал

Стек связи

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

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

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

5.5.2 Открытие защищенного канала

5.5.2.1 Описание

Настоящая служба используется для открытия или обновления защищенного канала, который может применяться для обеспечения конфиденциальности и целостности обмена сообщениями во время сессии. Эта служба требует, чтобы стек связи применял различные алгоритмы безопасности к сообщениям по мере их отправки и получения. Конкретные реализации этой службы для различных стеков связи описаны в ГОСТ Р 71811.

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

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

а) клиенты должны запрашивать новый токен безопасности по истечении 75 % его срока действия. Это должно гарантировать, что клиенты получат новый токен безопасности до истечения срока действия старого;

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

20

ГОСТ Р 71809—2024

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

в) клиенты должны принимать сообщения, защищенные истекшим токеном безопасности, в течение максимум 25 % времени срока использования токена. Это должно гарантировать, что сообщения, отправленные сервером до истечения срока действия токена, не будут отклонены из-за сетевых задержек.

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

Сообщения запроса и ответа открытия защищенного канала должны быть подписаны закрытым ключом отправителя. Эти сообщения должны всегда быть зашифрованы. Если транспортный уровень не обеспечивает шифрование, то эти сообщения должны быть зашифрованы открытым ключом получателя. Эти требования для службы открытия защищенного канала применяются только в том случае, если для параметра политики безопасности URI установлено значение «ОТСУТСТВУЕТ».

Если протокол, представленный в ГОСТ Р 71811, требует, чтобы сертификаты экземпляров приложения использовались в службе открытия защищенного канала, то клиенты и серверы должны проверить, что одни и те же сертификаты используются в службах создания сессии и активации сессии. Сертификаты не предоставляются и не подлежат проверке, если для URI политики безопасности установлено значение «ОТСУТСТВУЕТ».

Если политика безопасности URI не отображает значение «ОТСУТСТВУЕТ», клиент должен проверить, что имя хоста, указанное в сертификате сервера, совпадает с именем хоста, указанным в URL конечной точки. Если имеется разница, то клиент должен сообщить о разнице и может не открывать защищенный канал. Серверы должны добавить все возможные имена хоста, такие как MyHost и MyHost. local, в сертификат сервера. Сюда входят IP-адреса хоста или имя хоста, предоставленные маршрутизатором NAT, используемым для подключения к серверу.

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

5.5.2.2 Параметры

Параметры службы определены в таблице 11.

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

Таблица 11 — Параметры службы открытия защищенного канала

21

ГОСТ Р 71809—2024

Продолжение таблицы 11

22

Окончание таблицы 11

ГОСТ Р 71809—2024

5.5.2.3 Результаты службы

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

Таблица 12 — Результирующие коды службы открытия защищенного канала

23

ГОСТ Р 71809—2024

Окончание таблицы 12

5.5.3 Закрытие защищенного канала

5.5.3.1 Описание

Служба используется для отключения защищенного канала.

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

5.5.3.2 Параметры

Параметры службы определены в таблице 13.

При отображении конкретных протоколов, представленных в ГОСТ Р 71811, ответ может быть пропущен.

Таблица 13 — Параметры службы закрытия защищенного канала

5.5.3.3 Результаты службы

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

Таблица 14 — Результирующие коды службы закрытия защищенного канала

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

5.6.1 Обзор

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

24

ГОСТ Р 71809—2024

5.6.2 Создание сессии

5.6.2.1 Описание

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

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

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

В зависимости от политики безопасности и защищенного канала, обмен сертификатов экземпляра приложения и случайного кода может быть необязательным, а подписи могут быть пустыми. Определение политик безопасности и обработки этих параметров — см. МЭК 62451-7 [1].

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

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

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

Параметр сертификатов программного обеспечения в ответе сервера является нерекомендуемым, для того чтобы уменьшить размер сообщения для приложений ОРС UA с ограниченными ресурсами. Сертификаты программного обеспечения предоставляются в адресном пространстве сервера, как определено в ГОСТ Р 71810. Сертификат программного обеспечения определяет возможности сервера, а также содержит список профилей ОРС UA, поддерживаемых сервером. Профили ОРС UA определены в МЭК 62541-7 [1].

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

При создании сессии сервер добавляет запись для клиента в свою переменную массива данных диагностики сессии. Описание этой переменной — по ГОСТ Р 71810.

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

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

25

ГОСТ Р 71809—2024

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

Когда сессия завершается, все неотправленные запросы на сессию прерываются, а коды состояния «Некорректно_Сессия завершена» возвращаются клиенту. Сервер удаляет запись для клиента из своей переменной массива данных диагностики сессии и уведомляет других клиентов, которые были подписаны на эту запись.

Если клиент вызывает службу закрытия сессии, то все подписки, связанные с сессией, удаляются, если для метки удаления подписки установлено значение «ИСТИНА». Если сервер завершает сессию по любой другой причине, подписки, связанные с сессией, не удаляются. Каждая подписка имеет свой срок действия для защиты от потери данных в случае прекращения работы сессии. В этих случаях подписку можно переназначить другому клиенту до истечения срока ее действия.

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

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

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

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

Клиенты обычно поддерживают одного пользователя системы

Агрегирующий сервер устанавливает отдельную сессию со своими базовыми серверами

Рисунок 14 — Мультиплексирование пользователей в сессии

5.6.2.2 Параметры

Параметры службы определены в таблице 15.

26

Таблица 15 — Описание службы создания сессии

ГОСТ Р 71809—2024

27

ГОСТ Р 71809—2024

Продолжение таблицы 15

28

Окончание таблицы 15

ГОСТ Р 71809—2024

5.6.2.3 Результаты службы

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

Таблица 16 — Результирующие коды службы создания сессии

29

ГОСТ Р 71809—2024

Окончание таблицы 16

5.6.3 Активация сессии

5.6.3.1 Описание

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

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

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

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

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

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

30

ГОСТ Р 71809—2024

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

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

Когда клиент предоставляет список идентификаторов языковых стандартов в запросе, каждый идентификатор языкового стандарта должен содержать языковой компонент. Допускается дополнительно вводить компонент <страна/регион>. Когда сервер возвращает локализованный текст в контексте сессии, он может возвращать как язык, так и страну/регион или только язык в качестве идентификатора языковых стандартов по умолчанию.

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

Если нет точных совпадений, то сервер игнорирует компонент <страна/регион> идентификатора языкового стандарта и возвращает строку, компонент <язык> которой соответствует компоненту <язык> идентификатора языкового стандарта с наивысшим приоритетом в предоставленном клиентом списке.

Если совпадений по-прежнему нет, сервер возвращает имеющуюся у него строку с идентификатором языкового стандарта.

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

5.6.3.2 Параметры

Параметры службы определены в таблице 17.

Таблица 17 — Описание службы активации сессии

31

ГОСТ Р 71809—2024

Окончание таблицы 17

5.6.3.3 Результаты службы

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

32

Таблица 18 — Результирующие коды службы активации сессии

ГОСТ Р 71809—2024

5.6.4 Закрытие сессии

5.6.4.1 Описание

Служба закрытие сессии используется для прекращения сессии. При получении запроса «закрыть сессию» сервер выполняет следующие действия:

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

б) возвращает отрицательные ответы с кода состояния «некорректно_сессия закрыта» на все запросы, которые в настоящее время не выполнены, для обеспечения своевременного возврата ответа «закрытьсессию». Клиентам настоятельно рекомендуется дождаться завершения всех невыполненных запросов, прежде чем отправлять запрос «закрытьсессию»;

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

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

5.6.4.2 Параметры

Параметры службы определены в таблице 19.

Таблица 19 — Описание службы закрытия сессии

33

ГОСТ Р 71809—2024

5.6.4.3 Результаты службы

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

Таблица 20 — Результирующие коды службы закрытия сессии

5.6.5 Отмена

5.6.5.1 Описание

Данная служба используется для отмены невыполненных запросов службы. Успешно отмененные запросы службы должны отвечать «Некорректно_ЗапросОтмененКлиентом».

5.6.5.2 Параметры

Параметры службы отмены определены в таблице 21.

Таблица 21—Параметры службы отмены

5.6.5.3 Результаты службы

Общие коды состояния определены в таблице 177.

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

5.7.1 Обзор

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

5.7.2 Добавление узлов

5.7.2.1 Описание

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

Когда сервер создает экземпляр типа определения узла, он должен создать ту же иерархию узлов под новым объектом или переменной в зависимости от правила моделирования каждой декларации экземпляра. Должны быть созданы все узлы с правилом моделирования «обязательно» или должна быть сделана ссылка на существующий узел, соответствующий декларации экземпляра. Создание узлов с другими правилами моделирования зависит от конкретного сервера.

5.7.2.2 Параметры

Параметры службы определены в таблице 22.

34

Таблица 22 — Описание службы добавления узлов

ГОСТ Р 71809—2024

35

ГОСТ Р 71809—2024

Окончание таблицы 22

5.7.2.3 Результаты службы

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

Таблица 23 — Результирующие коды службы добавления узлов

5.7.2.4 Коды состояния

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

Таблица 24 — Коды результатов уровня операций добавления узлов

5.7.3 Добавление ссылок

5.7.3.1 Описание

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

36

ГОСТ Р 71809—2024

емая ссылка соответствует классу узла целевого узла. Этот параметр не проверяется, если ссылка ссылается на целевой узел на удаленном сервере.

Добавление новых ссылок на адресное пространство требует, чтобы сервер добавил новые идентификаторы сервера в переменную массива сервера. Поэтому удаленные серверы идентифицируются по их URI, а не по индексу массива сервера. Это позволяет серверу добавлять удаленные URI сервера к своему массиву сервера.

5.7.3.2 Параметры

Параметры службы определены в таблице 25.

Таблица 25 — Параметры службы добавления ссылок

5.7.3.3 Результаты службы

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

37

ГОСТ Р 71809—2024

Таблица 26 — Результирующие коды службы добавления ссылок

5.7.3.4 Коды состояния

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

Таблица 27 — Результирующие коды рабочего уровня добавления ссылок

5.7.4 Удаление узлов

5.7.4.1 Описание

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

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

Когда отслеживается какой-либо из узлов, удаленных при вызове этой службы, то клиенту мониторинга отправляется уведомление, содержащее код состояния «некорректно_идентификаторузлане-известен», указывающее, что узел был удален.

5.7.4.2 Параметры

Параметры службы определены в таблице 28.

38

Таблица 28 — Параметры службы удаления узлов

ГОСТ Р 71809—2024

5.7.4.3 Результаты службы

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

Таблица 29 — Результирующие коды службы удаления узлов

5.7.4.4 Коды состояния

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

Таблица 30 — Результирующие коды рабочего уровня удаления узлов

39

ГОСТ Р 71809—2024

Окончание таблицы 30

5.7.5 Удаление ссылок

5.7.5.1 Описание

Эта служба используется для удаления одной или нескольких ссылок на узел.

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

Описание службы определено в таблице 31.

Таблица 31 — Параметры службы удаления ссылок

40

ГОСТ Р 71809—2024

5.7.5.2 Результаты службы

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

Таблица 32 — Результирующие коды службы удаления ссылок

5.7.5.3 Коды состояния

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

Таблица 33 — Результирующие коды рабочего уровня удаления ссылок

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

5.8.1 Обзор

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

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

5.8.2 Просмотр

5.8.2.1 Описание

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

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

5.8.2.2 Параметры

Параметры службы определены в таблице 34.

41

ГОСТ Р 71809—2024

Таблица 34 — Параметры службы поиска

42

Окончание таблицы 34

ГОСТ Р 71809—2024

5.8.2.3 Результаты службы

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

Таблица 35 — Результирующие коды службы просмотра

5.8.2.4 Коды состояния

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

43

ГОСТ Р 71809—2024

Таблица 36 — Результирующие коды рабочего уровня просмотра

5.8.3 Дальнейший поиск

5.8.3.1 Описание

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

5.8.3.2 Параметры

Параметры службы определены в таблице 37.

Таблица 37 — Параметры службы дальнейшего поиска

44

Окончание таблицы 37

ГОСТ Р 71809—2024

5.8.3.3 Результаты службы

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

Таблица 38 — Результирующие коды службы дальнейшего поиска

5.8.3.4 Коды состояния

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

Таблица 39 — Результирующие коды рабочего уровня дальнейшего поиска

45

ГОСТ Р 71809—2024

Окончание таблицы 39

5.8.4 Преобразование путей просмотра в идентификаторы узлов

5.8.4.1 Описание

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

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

Пример — тип объекта «котел» может иметь переменную «датчик температуры». В качестве декларации экземпляра графический элемент, запрограммированный на «котел», требует отображения значения «теплового датчика». Если графический элемент будет вызываться на «котел1», тогда для вызова экземпляра «котел» необходимо вызвать службу преобразования путей просмотра, указав идентификатор узла «котел1» в качестве начального узла и поисковое имя «датчик температуры» в качестве поискового пути. Служба вернет идентификатор узла «теплового датчика» «котла1», и графический элемент сможет подписаться на его атрибут значения.

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

5.8.4.2 Параметры

В таблице 40 определены параметры для службы.

Таблица 40 — Параметры службы преобразования путей просмотра в идентификаторы узлов

46

Окончание таблицы 40

ГОСТ Р 71809—2024

5.8.4.3 Результаты службы

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

Таблица 41 — Результирующие коды службы преобразования путей просмотра в идентификаторы узлов

5.8.4.4 Коды состояния

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

47

ГОСТ Р 71809—2024

Таблица 42 — Результирующие коды рабочего уровня преобразования путей просмотра в идентификаторы узлов

5.8.5 Регистрация узлов

5.8.5.1 Описание

Допускается, что сервер не имеет прямого доступа к информации, которой он управляет. Если переменные или службы находятся в базовых системах, где требуются дополнительные усилия для установления соединения с этими системами, применяется служба регистрации узлов. Регистрация узлов, к которым обращаются клиенты (например, для записи, вызова), позволяет серверам настраивать необходимые атрибуты, определяющие эффективность операции доступа. Меры по оптимизации производительности при использовании зарегистрированных идентификаторов зависят от поставщика. Зарегистрированные идентификаторы узлов действительны только в течение текущей сессии. Для освобождения ресурсов клиенты должны отменять регистрацию ненужных идентификаторов.

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

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

5.8.5.2 Параметры

Параметры службы определены в таблице 43.

Таблица 43 — Параметры службы регистрации узлов

48

Окончание таблицы 43

ГОСТ Р 71809—2024

5.8.5.3 Результаты службы

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

Таблица 44 — Результирующие коды службы регистрации узлов

5.8.6 Разрегистрация узлов

5.8.6.1 Описание

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

Разрегистрация узлов (отмена регистрации) не проверяет идентификаторы узла из запроса. Серверы просто отменяют регистрацию идентификаторов узла, которые известны как зарегистрированные идентификаторы узла. Любые идентификаторы узла, которые есть в списке, но не зарегистрированы, игнорируются.

5.8.6.2 Параметры

Параметры службы разрегистрации узлов определены в таблице 45.

Таблица 45 — Параметры службы разрегистрации узлов

49

ГОСТ Р 71809—2024

5.8.6.3 Результаты службы

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

Таблица 46 — Результирующие коды службы разрегистрации узлов

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

5.9.1 Обзор

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

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

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

5.9.2 Запрашиваемые представления

Представление — подмножество адресного пространства, доступного на сервере. Для описания организации представлений в адресном пространстве см. ГОСТ Р 71810.

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

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

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

5.9.3 Первый запрос

5.9.3.1 Описание

Служба «первый запрос» используется для отправки запроса на сервер. Допускаются вариации сложности запроса от простого до сложного. Запрос запрашивает данные из экземпляров узла опреде-

50

ГОСТ Р 71809—2024

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

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

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

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

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

В таблице 47 определены параметры запроса. В таблице 48 определены параметры ответа для службы «первый запрос».

Таблица 47 — Параметры запроса «первый запрос»

51

ГОСТ Р 71809—2024

Окончание таблицы 47

52

Таблица 48 — Параметры ответа «первый запрос»

ГОСТ Р 71809—2024

53

ГОСТ Р 71809—2024

5.9.3.2 Результаты службы

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

Таблица 49 — Результирующие коды службы «первый запрос»

5.9.3.3 Коды состояния

В таблице 50 определены значения параметра «результаты грамматического разбора кода состояния», специфичные для этого службы. Общие коды состояния определены в таблице 178.

Таблица 50 — Результирующие коды рабочего уровня

54

ГОСТ Р 71809—2024

5.9.4 Следующий запрос

5.9.4.1 Описания

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

5.9.4.2 Параметры

В таблице 51 определены параметры для службы.

Таблица 51 — Параметры службы «следующий запрос»

5.9.4.3 Результаты службы

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

55

ГОСТ Р 71809—2024

Таблица 52 — Результирующие коды службы «следующий запрос»

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

5.10.1 Обзор

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

5.10.2 Чтение

5.10.2.1 Описание

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

Параметр maxage (максимальное время действия) используется для указания серверу доступа к значению из базового источника данных, такого как устройство, если его копия данных старше, чем указано в maxage. Если сервер не может соответствовать запрошенному максимальному времени действия, он возвращает значение «лучшее из возможного» вместо отклонения запроса.

5.10.2.2 Параметры

Параметры службы определены в таблице 53.

Таблица 53 — Параметры службы чтения

56

Окончание таблицы 53

ГОСТ Р 71809—2024

5.10.2.3 Результаты службы

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

Таблица 54 — Результирующие коды службы чтения

5.10.2.4 Коды состояния

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

57

ГОСТ Р 71809—2024

Таблица 55 — Чтение результирующих кодов рабочего уровня

5.10.3 Чтение истории

5.10.3.1 Описание

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

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

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

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

Дополнительные сведения о чтении исторических данных и исторических событий см. в МЭК 62451-11 [3].

5.10.3.2 Параметры

Параметры службы определены в таблице 56.

58

Таблица 56 — Параметры службы «чтение истории»

ГОСТ Р 71809—2024

59

ГОСТ Р 71809—2024

Продолжение таблицы 56

60

Окончание таблицы 56

ГОСТ Р 71809—2024

5.10.3.3 Результаты службы

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

Таблица 57 — Результирующие коды службы чтения истории

5.10.3.4 Коды состояния

В таблице 58 определены значения параметра «код состояния уровня операции», специфичные для данной службы. Общие коды состояния определены в таблице 178. Конкретные коды состояния доступа к истории определены в МЭК 62541-11 [3].

Таблица 58 — Результирующие коды рабочего уровня чтения истории

61

ГОСТ Р 71809—2024

Окончание таблицы 58

5.10.4 Запись

5.10.4.1 Описание

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

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

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

Возможно, что сервер может успешно записать одни атрибуты, но не другие. Ответственность за откат (возврат) лежит на клиенте.

Если сервер позволяет записывать атрибуты с типа данных «локализованный текст», клиент может добавить или перезаписать текст для языка, написав текст с соответствующим идентификатором языка. Запись пустой строки для текста для языкового стандарта приведет к удалению строки для этого языкового стандарта. Запись пустой строки для языкового стандарта и не пустой строки для текста устанавливает текст для инвариантного языкового стандарта. Запись пустой строки для текста и пустой строки для языкового стандарта удаляет записи для всех языковых стандартов. Если клиент пытается записать языковой стандарт, который либо синтаксически недействителен, либо не поддерживается, сервер возвращает «Некорректно_ЯзыковойСтандартНеПоддерживается». Поведение записи для атрибутов значения с типом данных «локализованный текст» зависит от сервера, но рекомендуется следовать тем же правилам.

5.10.4.2 Параметры

Параметры службы определены в таблице 59.

Таблица 59 — Параметры службы «запись»

62

Окончание таблицы 59

ГОСТ Р 71809—2024

63

ГОСТ Р 71809—2024

5.10.4.3 Результаты службы

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

Таблица 60 — Результирующие коды службы запись

5.10.4.4 Коды состояния

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

Таблица 61 — Результирующие коды рабочего уровня «запись»

64

Окончание таблицы 61

ГОСТ Р 71809—2024

5.10.5 Обновление истории

5.10.5.1 Описание

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

5.10.5.2 Параметры

Параметры службы определены в таблице 62.

Таблица 62 — Параметры службы обновления истории

65

ГОСТ Р 71809—2024

5.10.5.3 Результаты службы

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

Таблица 63 — Результирующие коды службы обновления истории

5.10.5.4 Коды состояния

В таблице 64 определены значения параметров кодов состояния и результатов операции, специфичные для этой службы. Общие коды состояния определены в таблице 178. Коды состояния, специфичные для доступа к истории, определены в МЭК 62451-11 [3].

Таблица 64 — Результирующие коды рабочего уровня «обновление истории»

5.11 Набор службы метода

5.11.1 Обзор

Методы представляют собой вызовы функций объектов. Они определены в ГОСТ Р 71808.

Методы вызываются и возвращаются только после завершения (успешного или неудачного). Время выполнения методов может варьироваться в зависимости от выполняемой ими функции.

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

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

5.11.2 Вызов

5.11.2.1 Описание

Данная служба используется для вызова (инициации) списка методов.

Служба обеспечивает передачу входных и выходных аргументов в/из метода. Эти аргументы определяются свойствами метода.

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

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

5.11.2.2 Параметры

Параметры службы определены в таблице 65.

66

Таблица 65 — Параметры службы «вызов»

ГОСТ Р 71809—2024

67

ГОСТ Р 71809—2024

Окончание таблицы 65

5.11.2.3 Результаты службы

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

Таблица 66 — Результирующие коды службы «вызов»

5.11.2.4 Коды состояния

В таблице 67 определены значения параметра «код состояния», а в таблице 68 определены значения параметра «результаты входных аргументов», специфичные для этой службы. Общие коды состояния определены в таблице 178.

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

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

Таблица 67 — Результирующие коды рабочего уровня вызова

68

Окончание таблицы 67

ГОСТ Р 71809—2024

Таблица 68 — Результирующие коды входного аргумента вызова

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

5.12.1 Модель элемента мониторинга

5.12.1.1 Обзор

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

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

Для элементов мониторинга определены четыре основных параметра, которые сообщают серверу, как элемент должен быть выбран, оценен, и должен быть составлен отчет. Эти параметры — интервал выборки, режим мониторинга, фильтр и параметр очереди. Рисунок 15 иллюстрирует эти концепции.

Отчеты могут быть включены или отключены для подписки

Отчеты для элемента мониторинга

Режим мониторинга определяет, включены или отключены выборка и отправка уведомлений

Выборка для элемента мониторинга

Подписка

Атрибуты очередности описывают очередь уведомлений для подписки

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

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

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

Фильтры используются для выбора образцов или событий для отчета

Атрибут

Переменная

Узел

Интервал выборки _____определяет циклическую скорость, используемую сервером для выборки реального элемента

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

Рисунок 15 — Модель элемента мониторинга

69

ГОСТ Р 71809—2024

Атрибуты, кроме атрибута значения, отслеживаются только на предмет изменения значения. Фильтр не используется для этих атрибутов. Любое изменение значения этих атрибутов вызывает создание уведомления.

Атрибут значения используется при мониторинге переменных. Значения переменных отслеживаются на предмет изменения значения или изменения их статуса. Фильтры, определенные в настоящем стандарте (см. 7.17.2) и в МЭК 62451-8 [4], используются для определения того, достаточно ли велико изменение значения, чтобы вызвать создание уведомления для переменной.

Объекты и представления могут использоваться для мониторинга событий. События доступны только с узлов, на которых установлен уведомитель события: флажок-признак подписки на события атрибута. Фильтр, определенный в настоящем стандарте (см. 7.17.3), используется для определения того, отправлено ли событие, полученное от узла, клиенту. Фильтр также позволяет выбирать поля «тип события», которые будут содержаться в событии, такие как идентификатор события, тип события, узел источника, время и описание. ОРС UA описывает модель события и базовые типы событий.

Свойства базовых типов событий и представление базовых типов событий в адресном пространстве указаны в ГОСТ Р 71810.

5.12.1.2 Интервал выборки

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

Клиент должен определить интервал выборки 0, если он подписывается на события.

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

Клиент также может указать 0 для интервала выборки, что указывает на то, что сервер должен использовать самую быструю практическую скорость. Ожидается, что серверы будут поддерживать только ограниченный набор интервалов выборки для оптимизации своей работы. Если точный интервал, запрошенный клиентом, не поддерживается сервером, то сервер назначает элементу мониторинга наиболее подходящий интервал, определенный сервером. Он возвращает этот назначенный интервал клиенту. Объект возможностей сервера, определенный в ГОСТ Р 71810, определяет интервалы выборки, поддерживаемые сервером.

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

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

Если поведение, с помощью которого базовая система обновляет элемент, известно, оно будет доступно через атрибут «минимальный интервал выборки», определенный в ГОСТ Р 71808. Если сервер указывает значение для атрибута «минимальный интервал выборки», он всегда должен возвращать пересмотренный интервал выборки, который равен или превышает минимальный интервал выборки, если клиент подписывается на атрибут значения.

70

ГОСТ Р 71809—2024

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

Цикл обнаружения базовой системы (каждые 15 с)

Фактическое изменение происход ит в прямых кавычках: «12»

Рисунок 16 — Типичная задержка при обнаружении изменений

5.12.1.3 Режим мониторинга

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

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

5.12.1.4 Фильтр

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

5.12.1.5 Параметры очереди

Если образец соответствует критериям фильтра, создается уведомление, которое ставится в очередь для передачи по подписке. Размер очереди определяется при создании элемента мониторинга. Когда очередь заполнена и получено новое уведомление, сервер либо отбрасывает самое старое уведомление и ставит в очередь новое, либо заменяет последнее добавленное в очередь значение новым. Элемент мониторинга настроен для использования одной из этих политик отмены при создании элемента мониторинга. Если уведомление отклоняется для значения данных и размер очереди больше единицы, то устанавливается флажок-признак (флаг) переполнения в части информационные флажки кода состояния «значение данных». Если «не учитывать самое старое» имеет значение «верно», самое старое значение удаляется из очереди, а следующее значение в очереди получает установленный

71

ГОСТ Р 71809—2024

флажок. Если «неучитыватьсамоестарое» имеет значение «ложь», последнее добавленное в очередь значение заменяется новым значением. Новое значение получает установленный флажок, чтобы указать потерянные значения в следующем уведомительном сообщении. На рисунке 17 показана обработка переполнения очереди.

Рисунок 17 — Обработка переполнения очереди

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

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

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

Если, например, абсолютная полоса нечувствительности в фильтре изменения данных равна «10», очередь может состоять из значений в следующем порядке:

100

111

100

89

100

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

72

ГОСТ Р 71809—2024

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

Размер очереди — это максимальное значение, поддерживаемое сервером при мониторинге событий. В этом случае за буфер событий отвечает сервер. Если события потеряны, в очередь помещается событие типа переполнение очереди событий. Это событие генерируется, когда первое событие отбрасывается в элемент мониторинга, подписанный на события. Он помещается в очередь элемента мониторинга в дополнение к размеру очереди, определенной для этого элемента мониторинга, без отбрасывания любого другого события. Если для параметра «неучитыватьсамоестарое» установлено значение верно, он помещается в начало очереди и никогда не отбрасывается, в противном случае — помещается в конце. Агрегирующий сервер не должен передавать такое событие. Он должен обрабатываться так же, как и другие сценарии ошибки соединения.

5.12.1.6 Триггерная модель

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

Триггерный элемент---------- определяет набор элементов, подвергнутых триггерам

Триггерные ссылки связывают триггерные элементы с элементами для отчета. Эти ссылки определены для

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

триггерного элемента и удаляются при удалении триггерного элемента

Рисунок 18 — Триггерная модель

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

Указаны следующие триггерные поведения:

а) если режим мониторинга триггерного элемента — отбор, то не сообщается, когда триггерный элемент запускает элементы для отчета;

б) если режим мониторинга триггерного элемента — отчет, то сообщается, когда триггерный элемент запускает элементы для отчета;

в) если режим мониторинга триггерного элемента — дезактивирован, то триггерный элемент не запускает элементы для отчета;

г) если режим мониторинга элемента для отчета — отбор, то сообщается, когда триггерный элемент запускает элементы для отчета;

д) если режим мониторинга элемента, о котором необходимо сообщить, — отчет, это фактически приводит к игнорированию триггерного элемента. Все уведомления об элементах для отчета отправляются после истечения интервала публикации;

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

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

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

73

ГОСТ Р 71809—2024

Удаление элемента мониторинга не следует путать с удалением контролируемого атрибута. Если узел, содержащий контролируемый атрибут, удален, элемент мониторинга генерирует уведомление с кодом состояния «Некорректно_ИдентификаторУзлаНеизвестен», который указывает на удаление, но элемент мониторинга не удаляется.

5.12.2 Создание элементов мониторинга

5.12.2.1 Описание

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

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

Когда добавляется элемент мониторинга, сервер выполняет для него обработку инициализации. Обработка инициализации определяется типом уведомления отслеживаемого элемента. Типы уведомлений указаны в спецификации типа доступа стандарта, например в МЭК 62451-8 [4].

Когда пользователь добавляет предмет контроля, к которому пользователю отказано в доступе для чтения, операция добавления для элемента должна быть успешной, и в ответе на публикацию должен быть возвращен отрицательный статус «Некорректно_НеЧитается» или «Некорректно_Доступ-ПользователяЗапрещен». Это то же самое поведение для случая, когда права доступа изменяются после вызова создания элементов мониторинга. Если права доступа меняются на права чтения, сервер должен начать отправку данных для элемента мониторинга. Та же процедура должна применяться к диапазону индексов, который не доставляет данные для текущего значения, но может доставлять данные в будущем.

После создания элемента мониторинга допускается удаление узлов мониторинга из адресного пространства. Это не влияет на истинность элемента мониторинга, но «Некорректно_Идентификатор УзлаНеизвестен» должен быть возвращен в ответе публикации. Элемент мониторинга снова станет истинным, если узел будет снова добавлен в адресное пространство, а элемент мониторинга все еще существует. Если известно, что идентификатор узла является истинным для сервера, но соответствующие атрибуты узла в настоящее время недоступны, сервер может разрешить создание элемента мониторинга и вернуть соответствующий код состояния «неверно» в ответе публикации.

Параметр возврата создания элементов мониторинга или последней службы изменения элементов мониторинга применяется к элементам мониторинга и используется в качестве параметров диагностической информации при отправке уведомлений в ответе «публикация».

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

ОРС UA рекомендует, чтобы клиент повторно использовал подписку после короткого прерывания сети, активировав существующую сессию на новом защищенном канале, как описано в 6.7. Если клиент вызвал службу создания элементов мониторинга во время прерывания сети и вызов на сервере был успешным, но не вернулся клиенту, тогда клиент не знает, являлся ли вызов успешным. Клиент может получать изменения данных для этих отслеживаемых элементов, но не может их удалить, поскольку ему неизвестен дескриптор сервера для каждого элемента мониторинга. Клиент также не может определить, было ли создание успешным. Удаление и повторное создание подписки также не является вариантом, поскольку может быть несколько элементов контроля, работающих в обычном режиме, которые не следует прерывать. Для разрешения ситуации объект сервера предоставляет метод получения элементов мониторинга, возвращающий список дескрипторов сервера и клиента для элементов мониторинга в подписке. Этот метод определен в ГОСТ Р 71810.

5.12.2.2 Параметры

Параметры службы определены в таблице 69.

74

Таблица 69 — Параметры службы создания элементов мониторинга

ГОСТ Р 71809—2024

75

ГОСТ Р 71809—2024

Окончание таблицы 69

5.12.2.3 Результаты службы

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

Таблица 70 — Результирующие коды службы создания элементов мониторинга

5.12.2.4 Коды состояния

В таблице 71 определены значения рабочего уровня параметра «код состояния, специфичный для данной службы». Общие коды состояния определены в таблице 178.

Таблица 71 — Результирующие коды рабочего уровня создания элементов мониторинга

76

Окончание таблицы 71

ГОСТ Р 71809—2024

5.12.3 Изменение элементов мониторинга

5.12.3.1 Описание

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

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

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

5.12.3.2 Параметры

Параметры службы определены в таблице 72.

77

ГОСТ Р 71809—2024

Таблица 72 — Параметры службы изменения элементов мониторинга

78

Окончание таблицы 72

ГОСТ Р 71809—2024

5.12.3.3 Результаты службы

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

Таблица 73 — Результирующие коды службы изменения элементов мониторинга

5.12.3.4 Коды состояния

В таблице 74 определены значения для рабочего уровня параметра «код состояния», специфичного для данной службы. Общие коды состояния определены в таблице 178.

Таблица 74 — Результирующие коды рабочего уровня изменения элементов мониторинга

5.12.4 Набор «режим контроля»

5.12.4.1 Описание

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

5.12.4.2 Параметры

Параметры службы определены в таблице 75.

79

ГОСТ Р 71809—2024

Таблица 75 — Параметры службы набора режима мониторинга

5.12.4.3 Результаты службы

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

Таблица 76 — Результирующие коды служб набора режима мониторинга

5.12.4.4 Коды состояния

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

80

Таблица 77 — Результирующие коды рабочего уровня набора режима мониторинга

ГОСТ Р 71809—2024

5.12.5 Набор взведения триггера

5.12.5.1 Описание

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

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

Для описания триггерной модели см. 5.12.1.6.

5.12.5.2 Параметры

Параметры службы определены в таблице 78.

Таблица 78 — Параметры службы набора взведения триггера

81

ГОСТ Р 71809—2024

Окончание таблицы 78

5.12.5.3 Результаты службы

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

Таблица 79 — Результирующие коды службы набора взведения триггера

5.12.5.4 Коды состояния

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

Таблица 80 — Результирующие коды рабочего уровня набора взведения триггера

5.12.6 Удаление элементов мониторинга

5.12.6.1 Описание

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

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

5.12.6.2 Параметры

Параметры службы определены в таблице 81.

82

Таблица 81 — Параметры службы удаления элементов мониторинга

ГОСТ Р 71809—2024

5.12.6.3 Результаты службы

В таблице 82 определены результаты службы, специфичные для этого службы. Общие коды состояния определены в таблице 177.

Таблица 82 — Результирующие коды службы удаления элементов мониторинга

5.12.6.4 Коды состояния

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

Таблица 83 — Результирующие коды рабочего уровня удаления элементов мониторинга

83

ГОСТ Р 71809—2024

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

5.13.1 Модель подписки

5.13.1.1 Описание

(описание элементов мониторинга см. в 5.12.1).

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

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

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

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

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

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

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

и) Подписки имеют счетчик времени жизни, который подсчитывает количество последовательных циклов публикации, в которых не было доступных запросов публикации для отправки ответа публикации для подписки. Любой вызов службы, который использует идентификатор подписки или обработку ответа публикации, сбрасывает счетчик времени существования этой подписки. Когда этот счетчик достигает значения, рассчитанного для срока действия подписки на основе параметра «максимальное количество сообщений об активности соединения в службе создания подписки» (5.13.2), подписка закрывается. Закрытие подписки приводит к удалению элементов мониторинга. Кроме того, сервер должен отправить уведомительное сообщение — уведомление об изменении статуса с кодом состояния «Некорректно_БлокировкаПоПревышениюВремени». Тип уведомительного сообщения «уведомление об изменении статуса» определен в 7.20.4.

к) Сессии поддерживают очередь повторной передачи отправленных уведомительных сообщений. Уведомительные сообщения сохраняются в этой очереди до тех пор, пока они не будут подтверждены. Сессия должна поддерживать размер очереди на повторную передачу, по крайней мере, в два раза превышающий количество запросов публикации за сессию, поддерживаемых сервером. Минимальный размер очереди на повторную передачу может быть изменен профилем в МЭК 62541-7 [1].

84

ГОСТ Р 71809—2024

Минимальное количество запросов публикации за сессию, которое должен поддерживать сервер, определено в МЭК 62541-7 [1]. Клиенты должны подтверждать уведомительные сообщения по мере их получения. В случае переполнения очереди повторной передачи самое старое отправленное уведомительное сообщение удаляется. Если подписка передается в другую сессию, помещенные в очередь уведомительные сообщения для этой подписки перемещаются из старого сообщения сессии в новое.

Порядковый номер — это 32-разрядное целое число без знака, которое увеличивается на единицу для каждого отправленного уведомительного сообщения. Значение 0 никогда не используется для порядкового номера. Первое уведомительное сообщение, отправленное в подписку, имеет порядковый номер 1. Если порядковый номер перемещается, он перемещается на 1.

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

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

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

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

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

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

5.13.1.2 Таблица состояния

Таблица состояний формально описывает работу подписки. Данная таблица описывает следующую модель операций. Это описание применяется, когда публикация включена или отключена для подписки.

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

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

85

ГОСТ Р 71809—2024

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

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

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

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

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

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

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

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

Состояния подписки определены в таблице 84.

Таблица 84 — Состояния подписки

Таблица состояний описана в таблице 85. Применяются следующие правила и соглашения:

а) события представляют собой получение запросов службы и возникновение внутренних событий, таких как истечение срока действия таймера;

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

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

г) запрос службы и внутренние события могут сопровождаться условиями, представленными функциями, возвращаемое значение которых проверяется. Функции обозначаются знаком «()» после имени. Они описаны в 5.13.1.4;

86

ГОСТ Р 71809—2024

д) когда событие принято, определяется первый переход для текущего состояния, и поиск переходов выполняется последовательно на предмет первого перехода, который соответствует критериям события или условий. Если ничего не найдено, событие игнорируется;

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

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

Таблица 85 — Таблица состояний подписки

87

ГОСТ Р 71809—2024

Продолжение таблицы 85

88

Продолжение таблицы 85

ГОСТ Р 71809—2024

89

ГОСТ Р 71809—2024

Окончание таблицы 85

5.13.1.3 Параметр состояния и параметры

Параметры состояния определены в алфавитном порядке в таблице 86.

90

Таблица 86 — Переменные состояния и параметры

ГОСТ Р 71809—2024

5.13.1.4 Функции

Функции действий определены в алфавитном порядке в таблице 87.

Таблица 87 — Функции

91

ГОСТ Р 71809—2024

Продолжение таблицы 87

92

Окончание таблицы 87

ГОСТ Р 71809—2024

5.13.2 Создание подписки

5.13.2.1 Описание

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

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

5.13.2.2 Параметры

Параметры службы определены в таблице 88.

Таблица 88 — Параметры службы создания подписки

93

ГОСТ Р 71809—2024

Окончание таблицы 88

94

ГОСТ Р 71809—2024

5.13.2.3 Результаты службы

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

Таблица 89 — Результирующие коды службы создания подписки

5.13.3 Изменение подписки

5.13.3.1 Описание

Данная служба используется для изменения подписки.

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

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

5.13.3.2 Параметры

Параметры службы определены в таблице 90.

Таблица 90 — Параметры службы изменения подписки

95

ГОСТ Р 71809—2024

Окончание таблицы 90

5.13.3.3 Результаты службы

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

Таблица 91 — Результирующие коды службы изменения подписки

5.13.4 Установка режима публикации

5.13.4.1 Описание

Данная служба используется для разрешения отправки уведомлений по одной или нескольким подпискам.

5.13.4.2 Параметры

Параметры службы определены в таблице 92.

96

Таблица 92 — Параметры службы установки режима публикации

ГОСТ Р 71809—2024

5.13.4.3 Результаты службы

В таблице 93 определены результаты службы, специфичные для этого службы. Общие коды состояния определены в таблице 177.

Таблица 93 — Результирующие коды службы установки режима публикации

5.13.4.4 Коды состояния

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

Таблица 94 — Результирующие коды рабочего уровня установки режима публикации

97

ГОСТ Р 71809—2024

5.13.5 Публикация

5.13.5.1 Описание

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

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

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

Сервер должен ограничить количество активных запросов публикации, чтобы избежать бесконечного числа, поскольку ожидается, что запросы публикации будут поставлены в очередь на сервере. Но сервер должен принимать больше запросов на публикацию в очереди, чем созданных подписок. Ожидается, что сервер поддерживает несколько запросов на публикацию на одну подписку. Когда сервер получает новый запрос на публикацию, превышающий его предел, он должен исключить из очереди самый старый запрос на публикацию и вернуть ответ с результатом, установленным на «Некорректно_ СлишкомМногоЗапросовНаПубликацию». Если клиент получает этот результат службы для запроса на публикацию, он не должен выдавать другой запрос на публикацию до тех пор, пока один из его невыполненных запросов на публикацию не будет возвращен сервером.

Клиенты могут ограничить размер ответов публикации с помощью параметра «максимальное количество уведомлений за публикацию», передаваемого в службу создания подписки. Однако это все равно может привести к тому, что сообщение будет слишком большим для обработки клиентом или сервером. В этой ситуации если клиент обнаружит, что либо защищенный канал переходит в состояние сбоя и его необходимо восстановить, либо ответ публикации возвращает ошибку, а вызов службы повторной публикации также возвращает ошибку, если возникает любая из ситуаций, клиент должен скорректировать свои ограничения на обработку сообщений или параметры подписки и/или элементов мониторинга (см. ГОСТ Р 71807).

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

5.13.5.2 Параметры

Параметры службы определены в таблице 95.

Таблица 95 — Параметры службы «публикация»

98

Окончание таблицы 95

ГОСТ Р 71809—2024

5.13.5.3 Результирующие коды службы «публикация»

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

Таблица 96 — Результирующие коды службы «публикация»

5.13.5.4 Коды состояния

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

99

ГОСТ Р 71809—2024

Таблица 97 — Результирующие коды рабочего уровня «публикация»

5.13.6 Повторная публикация

5.13.6.1 Описание

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

Подробное описание поведения этой службы см. в 5.13.1.2.

Для описания проблем и стратегий, касающихся обработки повторного подключения и повторной публикации, см. 6.7.

5.13.6.2 Параметры

Параметры службы определены в таблице 98.

Таблица 98 — Параметры службы «повторная публикация»

5.13.6.3 Результаты службы

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

Таблица 99 — Результирующие коды службы «повторная публикация»

5.13.7 Передача подписки

5.13.7.1 Описание

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

100

ГОСТ Р 71809—2024

передать подписки в службу «сессия». Она также может использоваться одним клиентом для получения подписки от другого клиента путем передачи подписки в службу «сессия».

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

Если сервер передает подписку в новой сессии, сервер должен выдать уведомительное сообщение «уведомление об изменении статуса» с кодом состояния «БезОшибки_ПодпискаПереданаСтарой-Сессии». Тип уведомительное «сообщение уведомление об изменении статуса» определен в 7.20.4.

5.13.7.2 Параметры

Параметры службы определены в таблице 100.

Таблица 100 — Параметры службы передачи подписки

101

ГОСТ Р 71809—2024

Окончание таблицы 100

5.13.7.3 Результаты службы

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

Таблица 101 — Результирующие коды службы передачи подписки

5.13.7.4 Коды состояния

В таблице 102 определены значения параметра «код состояния уровня операции», специфичные для данной службы. Общие коды состояния определены в таблице 178.

Таблица 102 — Результирующие коды рабочего уровня передачи подписки

5.13.8 Удаление подписки

5.13.8.1 Описание

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

Успешное завершение этой службы приводит к удалению всех элементов мониторинга, использующих подписку. Если это последняя подписка для сессии, то все запросы публикации, все еще находящиеся в очереди для этой сессии, удаляются из очереди и должны быть возвращены с «Некоррек-тно_НетПодписки».

Подписки, которые были перенесены на другую сессию, удаляются клиентом, которому принадлежит сессия.

5.13.8.2 Параметры

Параметры службы определены в таблице 103.

Таблица 103 — Параметры службы удаления подписки

102

Окончание таблицы 103

ГОСТ Р 71809—2024

5.13.8.3 Результаты службы

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

Таблица 104 — Результирующие коды службы удаления подписки

5.13.8.4 Коды состояния

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

Таблица 105 — Результирующие коды рабочего уровня удаления подписки

6 Поведение при использовании служб

6.1 Безопасность

6.1.1 Обзор

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

6.1.2 Получение и установка сертификата экземпляра приложения

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

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

- название организации, которая управляет приложением или владеет им;

- название приложения;

- URI экземпляра приложения;

- название сертификационного органа, выдавшего сертификат;

- дата выдачи и срок действия сертификата;

103

ГОСТ Р 71809—2024

- открытый ключ, выданный приложению сертификационного органа (СО);

- цифровая подпись, созданная сертификационным органом (СО).

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

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

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

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

„ , Сертификационный

Приложение Администратор ^г орган

1 Установка приложения

Сетевое имя или адрес аппарата.

Название организации

2 Создание самозаверяющега сертификата

Рисунок 19 — Получение и установка сертификата экземпляра приложения

104

ГОСТ Р 71809—2024

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

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

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

6.1.3 Определение доверия к сертификату

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

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

Для построения цепочки доверия требуется доступ ко всем сертификатам в цепочке. Эти сертификаты могут храниться локально или они могут быть предоставлены вместе с сертификатом приложения. Обработка завершается сообщением «некорректно_проверкабезопасностинеудалась», если сертификат СО не может быть найден.

В таблице 106 указаны шаги, используемые для проверки сертификата, в том порядке, в котором они должны выполняться. Эти шаги повторяются для каждого сертификата в цепочке. Каждый шаг проверки имеет уникальный статус ошибки и тип события аудита, о котором должно быть сообщено, если проверка не удалась. Событие аудита добавляется к любому событию аудита, которое было создано для конкретной вызванной службы. Событие аудита службы в тексте сообщения должно включать в себя идентификатор события аудита типа события аудита сертификата (для получения дополнительной информации см. 6.5). При возникновении ошибки обработка останавливается, если только она не является некритической и не была блокирована.

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

105

ГОСТ Р 71809—2024

Таблица 106 — Этапы проверки сертификата

106

Окончание таблицы 106

ГОСТ Р 71809—2024

Сертификаты размещаются в центральном хранилище сертификатов. На рисунке 20 показано взаимодействие между приложением, администратором и хранилищем сертификатов. Хранилище сертификатов находится на локальном компьютере или на центральном сервере. Точные механизмы, применяемые для доступа к хранилищу сертификатов, зависят от приложения и среды ИОК, настроенной администратором.

107

ГОСТ Р 71809—2024

Администратор

Приложение

Магазин сертификатов

1 Настройка приложения

Политики проверки сертификатов. Расположение сертификатов СО. Расположение списка отозванных сертификатов.

Распространение списка доверенных сертификатов

Удаленное приложение

2 Предоставление сертификата

PI экземпляра

6 Принятие сертификата экземпляра

3 Поиск сертификата эмитента

Проверка сертификата эмитента. Проверка сертификата в цепи доверия. Проверка сертификата экземпляра.

4 Поиск списка (списков) отозванных сертификатов

Проверка сертификата экземпляра.

Проверка сертификата эмитента.

5 Поиск списков доверенных сертификатов

Поиск сертификата экземпляра

или

поиск сертификата эмитента,

или

поиск любого сертификата в цепи

доверия

Рисунок 20 — Определение, является ли сертификат экземпляра приложения доверенным

6.1.4 Создание защищенного канала

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

Этапы, участвующие в создании защищенного канала, показаны на рисунке 21.

108

Клиент

Сервер

1 Запрос на получение конечных точек

Не требуется, если клиент предконфигурирован с учетом политик сервера

2 Ответ получения конечных точек

Сертификат сервера.

Режим безопасности сообщений.

Политика безопасности.

Политики токенов идентификации пользователей

ГОСТ Р 71809—2024

Сертификационный орган

3 Подтверждение сертификата сервера

4 Запрос на открытие защищенного канала

Подпись СО.

Дата выдачи и истечения срока действия.

Список отзывов СО

Сертификат клиента.

Одноразовый номер клиента.

Подпись закрытым ключом клиента.

Шифрование открытым ключом сервера

6 Ответ открытия защищенного канала

Одноразовый номер клиента.

Токен безопасности.

Срок действия токена.

Подпись закрытым ключом сервера.

Шифрование открытым ключом клиента

7 Обновление маркера безопасности

5 Подтверждение сертификата клиента

Подпись СО.

Дата выдачи и истечения срока действия.

Список отзывов СО

Рисунок 21 — Установление защищенного канала

На рисунке 21 предполагается, что клиент и сервер имеют онлайн-доступ к сертификационному органу (СО). Если онлайн-доступ недоступен и если администратор установил открытый ключ СО на локальном устройстве, то клиент и сервер все еще должны подтвердить сертификаты приложений, используя этот ключ. На рисунке показан только один СО, однако не требуется, чтобы сертификаты клиента и сервера были выданы одной и той же компанией. Самозаверяющий сертификат экземпляра приложения не должен быть подтвержден СО. Любой сертификат должен быть отклонен, если он не находится в списке доверия сертификатов, предоставляемых администратором.

Клиент и сервер должны иметь список сертификатов, которые были настроены на доверие — список доверия сертификатов (СДС). Эти доверенные сертификаты являются сертификатами для сертификационного органа, они являются сертификатами экземпляра приложений ОРС UA. Приложения ОРС UA должны быть настроены на отклонение соединений с приложениями, которые не имеют доверенного сертификата.

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

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

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

109

ГОСТ Р 71809—2024

что сертификат сервера в описании конечной точки является доверенным сертификатом, прежде чем он вызывает службу создания «сессия».

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

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

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

6.1.5 Создание сессии

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

Клиент

Сервер

Сертификационный орган

Поставщик удостоверений

1 Запрос на создание сессии

Сертификат экземпляра клиента. Одноразовый номер клиента

3 Ответ создания сессии

Сертификат экземпляра сервера. Подпись сертификата сервера. Сертификаты ПО сервера.

Одноразовый номер сервера

5 Запрос на активацию сессии

Сертификаты ПО клиента.

Подпись сертификата клиента.

Токен идентификации пользователя.

Подпись токена идентификации пользователя

7 Ответ активации сессии

Одноразовый номер сервера

2 Подтверждение сертификата клиента

4 Подтверждение сертификата сервера

6 Подтверждение токена идентификации сервера

Рисунок 22 — Установка сессии

На рисунке 22 показано взаимодействие между клиентом, сервером, СО и поставщиком удостоверений. СО отвечает за выдачу сертификатов экземпляра приложения. Если у клиента или сервера нет онлайн-доступа к СО, они должны проверить сертификаты экземпляра приложения, используя открытый ключ СО, который администратор должен установить на локальном устройстве.

Допустимо, что поставщик удостоверений является центральной базой данных, которой дано право проверять токен пользователя, предоставленный клиентом. Поставщик удостоверений может сообщать серверу, какие права доступа имеет пользователь. Поставщик удостоверений зависит от токена идентификации пользователя. Он может быть сертификационным органом, службой предоставления талонов протокола «цербер» (kerberos), сервером ws-trust или какой-либо коммерческой базой данных (с закрытым исходным кодом).

110

ГОСТ Р 71809—2024

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

6.1.6 Выдача себя за пользователя

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

Этапы, необходимые для выдачи себя за пользователя, показаны на рисунке 23.

Клиент Сервер

1 Запрос на активацию сессии

Поставщик удостоверений

Подпись сертификата клиента.

Токен идентификации пользователя. Подпись токена идентификации пользователя

3 Ответ активации сессии

Одноразовый номер сервера

2 Токен подтверждения идентификации пользователя

Рисунок 23 — Выдача себя за пользователя

6.2 Службы авторизации

6.2.1 Обзор

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

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

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

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

6.2.2 «Косвенное рукопожатие» с поставщиком удостоверений

Службы проверки подлинности (СПП) предоставляют доступ к поставщикам удостоверений, которые могут проверять учетные данные, предоставленные клиентами. Затем они предоставляют токены, которые могут быть переданы на сервер вместо учетных данных. Данные токены передаются как выданный токен идентификации, определенный в 7.36.6.

Протокол запроса токена зависит от СПП. Общие протоколы включают kerberos и oauth2. Oauth2 поддерживает авторизацию на основе утверждений, как описано в ГОСТ Р 71807. Серверы публикуют СПП, которые они поддерживают, в списке политик токенов пользователя, который возвращается с получением конечных точек. Поле выданного типа токена указывает протокол, используемый для связи с

111

ГОСТ Р 71809—2024

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

Базовое «Косвенное рукопожатие» показано на рисунке 24.

Рисунок 24 — «Косвенное рукопожатие» с поставщиком удостоверений

6.2.3 «Прямое рукопожатие» с поставщиком удостоверений

Службы проверки пользователя требуют, чтобы серверы были зарегистрированы на них, потому что токены доступа могут использоваться только с одним сервером. Такое положение может усложнить работу администраторов. Один из способов уменьшить эту сложность — использовать информацию сервера, которая уже управляется глобальной службой обнаружения (ГСО), описанной в МЭК 62541-12 [2]. В этой модели идентификационные данные пользователей управляются центральной службой проверки пользователя. Взаимодействия показаны на рисунке 25.

Политика токенов пользователя, возвращаемая сервером, предоставляет URL-адрес службы проверки пользователя и поставщика удостоверений. Если служба проверки приложений связана с ГСО, она знает все серверы, которым были выданы сертификаты. URI приложения используется в качестве идентификатора сервера, передаваемого в СПП.

112

Клиент

Сервер

Служба авторизации (СА)

Поставщик удостоверений

|--------Получение конечных точек-----►( К- - Конечные точки с политиками токена пользователя

И

-------------------Запрос токена с идентификацией пользователя ----------------г - Токен идентификации------|— — Запрос токена с токеном идентификации----------------►! | -----------Токен доступа----------------------{ Создание сессии---------►{

|—Активация сессии с токеном доступа—^ I I

Рисунок 25 — «Прямое рукопожатие» с поставщиком удостоверений

ГОСТ Р 71809—2024

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

6.3 Вызов службы без сессии

6.3.1 Описание

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

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

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

Любая конечная точка, применяемая для нормальной коммуникации, может использоваться для вызова службы без сессии при условии, что конечная точка поддерживает шифрование. Сервер возвращает сообщение «некорректно_службанеподдерживается», если он не поддерживает вызов без сессии для запроса, указанного в теле. Если он поддерживает вызов, но не с комбинацией используемых параметров конечной точки и безопасности, он возвращает сообщение «Некорректно_РежимБезо-пасностиНедостаточный».

Серверы могут предоставлять конечные точки, которые предназначены только для использования без вызова сессии. Конечные точки должны поддерживать получение конечных точек и поиск серверов в дополнение к службе вызова службы без сессии. Сервер возвращает «Некорректно_СлужбаНеПод-держивается» для других служб.

Сессия гарантирует, что индекс имен пространства или индекс сервера не изменится в течение всего времени существования сессии. Этого URI нельзя гарантировать между вызовами служб без сессии. Есть два варианта обеспечения соответствия индексов пространства имен в вызове ожидаемых имен пространства на сервере. Один из вариантов для вызывающей стороны — предоставить список URI пространства имен, используемых для построения индексов пространства имен. Данный вариант работает для одиночных вызовов службы без сессии. Второй вариант — предоставить версии URI для обеспечения согласованности массивов пространства имен между клиентом и сервером. Версия URI сначала считывается с сервера вместе с массивом пространства имен и массивом сервера. Его применение снижает накладные расходы на вызов для последовательности вызовов служб без сессии.

6.3.2 Параметры

Параметры службы определены в таблице 107.

113

ГОСТ Р 71809—2024

Таблица 107 — Параметры службы вызова «службы без сессии»

114

Окончание таблицы 107

ГОСТ Р 71809—2024

6.3.3 Результаты службы

В таблице 108 определены службы, специфичные для этой службы. Общие коды состояния определены в таблице 177.

Таблица 108 — Результирующие коды службы вызова «службы без сессии»

6.4 Сертификаты программного обеспечения

Примечание — Подробная информация о сертификатах программного обеспечения будет определена при пересмотре настоящего стандарта.

6.5 Аудит

6.5.1 Обзор

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

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

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

6.5.2 Журналы общего аудита

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

6.5.3 Общие события аудита

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

115

ГОСТ Р 71809—2024

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

6.5.4 Аудит для набора служб обнаружения

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

6.5.5 Аудит для набора служб защищенного канала

Все службы в данном наборе служб для серверов, поддерживающих аудит, могут создавать записи аудита и должны создавать события аудита для неудачных вызовов служб и для успешного вызова службы открытия защищенного канала и закрытия защищенного канала. Созданные клиентом записи аудита должны быть настроены до фактического вызова, что позволит предоставить правильный идентификатор записи аудита. Служба открытия защищенного канала должна сгенерировать событие аудита типа «тип события аудита открытия защищенного канала» или его подтип для типа запроса «доба-вить_0». События аудита для типа запроса «обновить_1» создаются только в случае сбоя обновления. Служба закрытия защищенного канала должна сгенерировать событие аудита типа события «канал аудита» или его подтипа. Оба типа событий являются подтипами типа события «канал аудита». Подробное описание узла источника, имени источника и дополнительных параметров см. в ГОСТ Р 71810. В случае сбоя сообщение для события этого типа должно включать описание причины сбоя службы. Это описание должно быть более подробным по сравнению с тем, которое было возвращено клиенту. С точки зрения безопасности клиенту необходимо знать только то, что произошел сбой, а с точки зрения аудита должна быть известна точная информация о сбое.

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

6.5.6 Аудит для набора служб сессии

Все службы в данном наборе служб для серверов, которые поддерживают аудит, могут создавать записи аудита и должны генерировать события аудита для как успешных, так и неудачных вызовов службы. Данные службы должны генерировать событие аудита типа «тип события сессии аудита» или его подтипа. Они должны сгенерировать базовый тип события или соответствующий подтип, в зависимости от вызванной службы. Служба создания сессии генерирует события «тип события создания сессии аудита» или их подтипы. Служба активации сессии генерирует события «тип события создания сессии аудита» или их подтипы. Когда служба активации сессии вызывается для изменения личности пользователя, сервер должен генерировать события тип события активации сессии аудита или их подтипы. Служба закрытия сессии генерирует события «тип события сессии аудита» или их подтипы. Он всегда генерируется, если сессия завершается, например из-за превышения времени ожидания сессии или завершения работы сервера. Имя источника для событий этого типа должно быть «сессия/превы-шение времени ожидания» для превышения времени ожидания сессии, «сессия/закрытие сессии» для вызова службы закрытия сессия и «сессия/прерывание» для всех других случаев. Подробное описание узла источника, имени источника и дополнительных параметров приведено в ГОСТ Р 71810. В случае сбоя сообщение о событиях этого типа должно включать описание причины сбоя службы. Дополнительные параметры должны включать детали запроса.

Настоящий набор служб также должен генерировать дополнительные события аудита в случаях, когда возникают ошибки проверки сертификата. Эти события аудита создаются в дополнение к событиям типа события «сессия аудита». Определение типа события «сертификат аудита» и его подтипы см. в ГОСТ Р 71808.

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

ГОСТ Р 71809—2024

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

6.5.7 Аудит для набора служб управления узлами

Все службы в этом наборе служб для серверов, которые поддерживают аудит, могут создавать записи аудита и должны генерировать события аудита как для успешных, так и для неудачных вызовов службы. Эти службы должны генерировать событие аудита типа «тип события управления узлом аудита» или его подтипы. Подробное описание узла источника, имя источника и дополнительные параметры приведены в ГОСТ Р 71810. В случае сбоя сообщение о событиях этого типа должно включать описание причины сбоя службы. Дополнительные параметры должны включать детали запроса.

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

6.5.8 Аудит набора служб атрибутов

Службы записи или обновления истории в этом наборе служб для серверов, поддерживающих аудит, могут создавать записи аудита и должны генерировать события аудита как для успешных, так и для неудачных вызовов службы. Эти службы должны генерировать событие аудита типа «тип события обновления аудита» или его подтипы. В частности, служба записи должна генерировать событие аудита типа «тип события обновления записи аудита» или его подтипа. Служба обновления истории должна генерировать событие аудита типа «тип события обновления истории аудита» или его подтипа. Три подтипа типа события обновления истории аудита определены как тип события обновления событий истории аудита, тип события обновления значения истории аудита и тип события удаления истории аудита. Подтип зависит от типа выполняемой операции, обновления событий истории, обновления значений данных истории или удаления истории. Для подробного описания узла источника, имени источника и дополнительных параметров см. ГОСТ Р 71810. В случае сбоя сообщение о событиях этого типа должно включать описание причины сбоя службы. Дополнительные параметры должны включать детали запроса.

Службы чтения и чтения истории могут создавать записи аудита и события аудита для неудачных вызовов службы. Эти службы должны генерировать событие аудита типа «тип события аудита» или его подтипа. Для получения подробных сведений о назначении узла источника, имени источника и дополнительных параметров см. ГОСТ Р 71810. Сообщение о событиях этого типа должно включать описание причины сбоя службы.

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

6.5.9 Аудит для набора служб метода

Все службы в данном наборе служб для серверов, которые поддерживают аудит, могут создавать записи аудита и должны генерировать события аудита, как для удачных, так и для неудачных вызовов службы, если вызов изменяет адресное пространство, записывает значение или изменяет состояние системы (подтверждение тревоги, пакетная последовательность или другие системные изменения). Эти вызовы методов должны генерировать событие аудита типа «тип события метода обновления аудита» или его подтипы. Методы, которые не изменяют адресное пространство, не записывают значения или не изменяют состояние системы, могут генерировать события. Для получения подробной информации о назначении узла источника, имени источника и дополнительных параметров см. ГОСТ Р 71810.

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

6.5.10 Аудит для набора служб представления, запроса, предмета контроля и подписки

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