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

(утв. и введен в действие Приказом Росстандарта от 29.11.2024 № 1805-ст)

Утвержден и введен в действие Приказом Федерального

Предисловие

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание - Все токены безопасности принадлежат контексту безопасности. Для OPC 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);

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 Условные обозначения для определения служб

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

Таблица 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.1 Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.2.1 Описание

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

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

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

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

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

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

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

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

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

5.4.2.2 Параметры

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

Таблица 3

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

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

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

5.4.3.1 Описание

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

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

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

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

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

5.4.3.2 Параметры

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

Таблица 4

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

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

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

5.4.4.1 Описание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.4.2 Параметры

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

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

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

5.4.5.1 Описание

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

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

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

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

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

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

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

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

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

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

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

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

5.4.5.2 Параметры

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

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

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

5.4.6.1 Описание

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

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

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

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

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

5.4.6.2 Параметры

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

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

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

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

5.5.1 Обзор

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

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

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

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

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

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

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

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

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

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

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

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

5.5.2.1 Описание

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

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

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

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

5.5.2.2 Параметры

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

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

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

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

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

5.5.3.1 Описание

5.5.3.2 Параметры

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

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

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

5.6.1 Обзор

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

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

5.6.2.1 Описание

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

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

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

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

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

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

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

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

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

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

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

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

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

5.6.2.2 Параметры

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

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

5.6.3.1 Описание

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

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

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

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

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

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

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

5.6.3.2 Параметры

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

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

5.6.4.1 Описание

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

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

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

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

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

5.6.4.2 Параметры

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

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

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

5.6.5 Отмена

5.6.5.1 Описание

5.6.5.2 Параметры

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

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

5.7.1 Обзор

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

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

5.7.2.1 Описание

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

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

5.7.2.2 Параметры

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

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

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

5.7.3.1 Описание

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

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

5.7.3.2 Параметры

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

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

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

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

5.7.4.1 Описание

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

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

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

5.7.4.2 Параметры

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

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

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

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

5.7.5.1 Описание

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

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

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

Таблица 31

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

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

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

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

5.8.1 Обзор

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

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

5.8.2 Просмотр

5.8.2.1 Описание

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

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

5.8.2.2 Параметры

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

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

5.8.3.1 Описание

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

5.8.3.2 Параметры

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

Таблица 37

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

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

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

5.8.4.1 Описание

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

5.8.4.2 Параметры

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

Таблица 40

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

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

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

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

5.8.5.1 Описание

5.8.5.2 Параметры

Таблица 43

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

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

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

Таблица 44

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

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

5.8.6.1 Описание

5.8.6.2 Параметры

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

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

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

5.9.1 Обзор

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

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

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

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

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

5.9.3.1 Описание

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

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

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

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

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

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

Таблица 48

Параметры ответа «первый запрос»

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

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

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

5.9.4.1 Описания

5.9.4.2 Параметры

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

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

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

5.10.1 Обзор

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

5.10.2 Чтение

5.10.2.1 Описание

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

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

5.10.2.2 Параметры

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

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

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

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

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

Таблица 55

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

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

5.10.3.1 Описание

5.10.3.2 Параметры

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

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

5.10.4 Запись

5.10.4.1 Описание

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

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

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

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

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

5.10.4.2 Параметры

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

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

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

5.10.5.1 Описание

5.10.5.2 Параметры

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

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

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

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

5.11.1 Обзор

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

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

5.11.2 Вызов

5.11.2.1 Описание

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

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

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

5.11.2.2 Параметры

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

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

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

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

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

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

5.12.1.1 Обзор

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

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

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

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

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

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

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

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

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

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

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

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

5.12.1.4 Фильтр

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

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

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

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

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

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

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

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

100

111

100

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.12.2.1 Описание

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

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

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

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

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

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

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

5.12.2.2 Параметры

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

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

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

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

5.12.3.1 Описание

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

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

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

5.12.3.2 Параметры

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

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

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

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

5.12.4.1 Описание

5.12.4.2 Параметры

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

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

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

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

5.12.5.1 Описание

5.12.5.2 Параметры

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

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

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

5.12.6 Удаление элементов мониторинга

5.12.6.1 Описание

5.12.6.2 Параметры

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

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

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

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

Таблица 83

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

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

5.13.1 Модель подписки

5.13.1.1 Описание

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

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

и) Подписки имеют счетчик времени жизни, который подсчитывает количество последовательных циклов публикации, в которых не было доступных запросов публикации для отправки ответа публикации для подписки. Любой вызов службы, который использует идентификатор подписки или обработку ответа публикации, сбрасывает счетчик времени существования этой подписки. Когда этот счетчик достигает значения, рассчитанного для срока действия подписки на основе параметра «максимальное количество сообщений об активности соединения в службе создания подписки» (5.13.2), подписка закрывается. Закрытие подписки приводит к удалению элементов мониторинга. Кроме того, сервер должен отправить уведомительное сообщение — уведомление об изменении статуса с кодом состояния «Некорректно_БлокировкаПоПревышениюВремени». Тип уведомительного сообщения «уведомление об изменении статуса» определен в 7.20.4.

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

Порядковый номер — это 32-разрядное целое число без знака, которое увеличивается на единицу для каждого отправленного уведомительного сообщения. Значение 0 никогда не используется для порядкового номера. Первое уведомительное сообщение, отправленное в подписку, имеет порядковый номер 1. Если порядковый номер перемещается, он перемещается на 1.

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

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

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

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

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

Подписки предназначены для работы независимо от фактического коммуникационного соединения между клиентом OPC UA и сервером и независимо от сессии. Кратковременные прерывания связи можно обрабатывать без потери данных или событий. Чтобы гарантировать, что более длительные прерывания связи или запланированные отключения могут обрабатываться без потери данных или событий, сервер OPC UA может поддерживать длительные подписки. Если эта функция поддерживается, сервер принимает большое значение параметра «количество запрошенного срока действия подписки» и большое значение параметра «размер очереди элемента мониторинга». В 6.8 описано, как можно создавать и использовать долговечные подписки.

5.13.1.2 Таблица состояния

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

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

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

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

д) когда событие принято, определяется первый переход для текущего состояния, и поиск переходов выполняется последовательно на предмет первого перехода, который соответствует критериям события или условий. Если ничего не найдено, событие игнорируется;

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

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