Для всех объектов, приведенных в настоящем стандарте, атрибуты должны быть установлены так, как указано в таблице 2.
Таблица 2
Для всех переменных, приведенных в настоящем стандарте, атрибуты должны быть установлены так, как указано в таблице 3.
Таблица 3
Для всех типов переменных, приведенных в настоящем стандарте, атрибуты должны быть установлены так, как указано в таблице 4.
Таблица 4
Для всех методов, приведенных в настоящем стандарте, атрибуты должны быть установлены так, как указано в таблице 5.
Таблица 5
Как правило, компоненты типа объекта являются фиксированными и могут быть расширены с помощью подтипов. Однако, поскольку каждый объект типа объекта может быть расширен посредством дополнительных компонентов, возможно дополнять стандартные типы объектов, приведенные в настоящем стандарте, новыми компонентами. Таким образом, в определении типа можно указать дополнительную информацию, которая содержится в каждом объекте. Некоторые типы объектов уже предоставляют точки входа для расширений, зависящих от сервера. Однако не разрешается ограничивать компоненты стандартных типов объектов, определенных в настоящем стандарте. Пример расширения типов объектов - это добавление стандартных свойств версий узла в соответствии с ГОСТ Р 71809. В базовом типе объектов указывается, что каждый объект сервера будет предоставлять версию узла.
Базовый тип объектов неизменно используется в качестве определения типа при наличии такого объекта, для которого недоступны более конкретные определения типа. Серверам не следует применять этот тип объекта.
Данный тип объектов, определенный в таблице 6, является базовым, и все остальные типы должны прямо или косвенно соответствовать его атрибутам (см. ГОСТ Р 70988). Однако серверы могут и не предоставить все ссылки на его подтипы, и поэтому предоставлять данную информацию не требуется.
Таблица 6
Этот тип объекта, представленный в таблице 7, определяет возможности, поддерживаемые сервером OPC UA.
Таблица 7
Массив серверов определяет массив URI серверов. Эта переменная также называется таблицей сервера. Каждый URI в данном массиве представляет собой уникальное в глобальном масштабе логическое имя сервера в рамках сети, в которой он установлен. Каждый экземпляр сервера OPC UA имеет отдельный URI, который используется в таблице серверов других серверов OPC UA. Индекс 0 зарезервирован для URI локального сервера. Значения выше 0 применяют для идентификации удаленных серверов и относят к конкретному серверу. В ГОСТ Р 71809 описан механизм обнаружения, который можно использовать для преобразования URI в URL-адреса. В URI сервера учитывается регистр символов.
URI сервера с индексом 0 должен быть идентичен URI пространства с индексом 1, так как оба они представляют локальный сервер.
Индексы в таблице сервера называются индексами сервера или именами серверов. Они используются в службах OPC UA для определения целевых узлов ссылок, которые находятся на удаленных серверах. Клиенты могут читать всю таблицу целиком или отдельные записи в таблице. Сервер не должен изменять или удалять записи этой таблицы, пока у любого клиента открыт сеанс связи с сервером, поскольку клиенты могут структурировать данные, реализующие интерфейс ассоциативного массива в серверную таблицу. Сервер может добавлять записи в таблицу сервера, даже если клиенты подключены к серверу.
Пространство множества определяет массив URI пространства имен (см. [1]). Эта переменная также называется таблицей пространства имен. Индексы в таблице пространства имен именуются индексами пространства имен. Индексы пространства имен используются в идентификаторах узлов в службах OPC UA, а не в более длинном URI пространства имен. Индекс 0 зарезервирован для пространства имен OPC UA, а индекс 1 - для локального сервера. Клиенты могут читать всю таблицу пространства имен или отдельные записи в таблице пространства имен. Сервер не должен изменять или удалять записи таблицы пространства имен, пока у любого клиента открыт сеанс связи с сервером, поскольку клиенты могут хешировать таблицу пространства имен. Рекомендуется, чтобы серверы не изменяли индексы таблицы пространства имен, а только добавляли записи, так как клиент может хешировать идентификаторы узлов, посредством индексов. Тем не менее серверы не во всех ситуациях могут игнорировать изменения индексов в таблице пространства имен. Клиенты, которые хешируют индексы пространства имен узла D, должны неизменно проверять индексы при запуске сеанса, чтобы убедиться в том, что хешированные индексы пространства имен не изменились (см. [2]).
Версия URIs определяет множество служб сервера и множество наименований. Каждый раз, когда изменяются службы сервера и множества наименований, значение версии URIs должно быть обновлено до превышения предыдущего значения. Свойство версии URIs используется в сочетании с сервисом вызова без сеанса, определенным в ГОСТ Р 71809. Если сервер поддерживает эту службу, он должен поддерживать и такое свойство. Сервер несет ответственность за предоставление согласованного набора значений для свойств предоставленных ему служб с множеством наименований и версий URIs. Тип данных версии "Время" определен в ГОСТ Р 71809.
Сервер статуса содержит элементы, описывающие состояние его элементов, приведенное в 12.10.
Уровень обслуживания описывает способность сервера предоставлять свои данные клиенту. Диапазон значений составляет от 0 до 255, где 0 указывает на наихудшее значение, а 255 - на наилучшее. В ГОСТ Р 71809 определены требуемые поддиапазоны для различных сценариев. Цель состоит в том, чтобы предоставить клиентам информацию о доступности резервных серверов.
Служба аудита определяет логическое значение, указывающее, генерирует ли сервер события, контролируемые в данный момент. Значение ПРАВДА устанавливается, если сервер генерирует контролируемые события, в противном случае - значение ЛОЖЬ. Профили в соответствии с [3] определяют, какие события аудита генерируются сервером.
Служба указывает время, в течение которого сервер, как предполагается, будет иметь статус "Состояние запущенного_0". Клиент, который наблюдает завершение работы или уровень обслуживания, равный 0, должен либо дождаться истечения этого времени, чтобы попытаться повторно подключиться к этому серверу, либо ввести логику медленных повторных попыток. Например, большинство клиентов непосредственно после сбоя пытаются восстановить соединение, а затем постепенно увеличивают задержку между попытками до достижения некоторой максимальной задержки. Это время может быть использовано для запуска клиентом логики повторного подключения с определенной задержкой (подробнее см. [4]).
Локальное время - это структура, характеризуемая наличием флага перехода на летнее время со смещением. Значение смещения определяет разницу во времени, мин, между серверным временем в UTC и местным временем в местоположении сервера. Если значение параметра "Переход на летнее время со смещением" равно значению ПРАВДА, то в местоположении сервера действует стандартное/летнее время (DST), а смещение включает коррекцию летнего времени. Если имеется значение ЛОЖЬ, то смещение не включает коррекцию летнего времени, и летнее время может как действовать, так и не действовать.
Сервер возможностей определяет допустимые функции, поддерживаемые сервером OPC UA (см. 6.3.2).
Сервер диагностики определяет информацию о сервере OPC UA (см. 6.3.3).
Сервер поставщика информации представляет собой точку входа для просмотра информации, указанной поставщиком. Эта точка входа должна быть определена, даже если объекты, перечисленные поставщиком, отсутствуют (см. 6.3.6).
Служба, описывающая возможности резервирования, предоставляемые сервером, необходима, даже если сервер не поддерживает резервирование. Если сервер поддерживает резервирование, то для описания его возможностей используется подтип сервера поддержки избыточности. В противном случае он предоставляет объект типа сервера поддержки избыточности со свойством <нет> (см. 6.3.7).
Пространство имен предоставляет список объектов типа метаданных с дополнительной информацией об именах, используемых на сервере (см. 6.3.13).
Метод получения отслеживаемых элементов используют для контроля элементов подписки, что определено в 9.1. Предполагаемое применение данного метода определено в ГОСТ Р 71809.
Для получения последних значений отслеживаемых элементов подписки используют метод повторной отправки данных, предполагаемое применение которого определено в ГОСТ Р 71809.
Метод установления продолжительности подписки определен в 9.3. Он используется для перевода подписки в тот режим, при котором данные результатов мониторинга и очереди событий сохраняются и доставляются, даже если клиент OPC UA отключен на длительное время или сервер OPC UA перезапущен. Предполагаемое использование определено в ГОСТ Р 71809. Метод запроса информации об изменении состояния сервера позволяет клиенту получить данные о таком изменении согласно 9.4. Предполагаемое использование определено в ГОСТ Р 71809.
Этот тип объекта определяет возможности, поддерживаемые сервером OPC UA. Формально данный тип определен в таблице 8.
Таблица 8
Сервер множества профилей перечисляет поддерживаемые им профили. Определение профилей сервера приведено в [3]. Этот список должен быть ограничен профилями, которые сервер поддерживает в своей текущей конфигурации.
Массив идентификаторов локализации - это массив идентификаторов локаций, которые, как известно, поддерживаются сервером. Сервер может не знать обо всех идентификаторах локаций, которые он поддерживает, так как он может предоставлять доступ к базовым серверам, системам или устройствам, которые не сообщают идентификаторы локаций ID, которые они поддерживают.
Сервером поддерживаются службы, определяющие минимальную поддерживаемую частоту дискретизации, включая 0, и максимальное количество параллельных точек продолжения службы просмотра, которые сервер может поддерживать за сеанс. Такие значения указывают максимум, который сервер может поддерживать при нормальных обстоятельствах, но отсутствуют гарантии того, что сервер при любых обстоятельствах сможет поддерживать максимум. Клиент не должен открывать вызовов браузера с открытыми точками продолжения больше, чем указано в этой переменной. Значение 0 указывает, что сервер не ограничивает количество параллельных точек продолжения, которые должен использовать клиент.
Сервис определяет максимальное количество параллельных точек обеспечения качественного начала, которые сервер может поддерживать за сеанс. Значение указывает максимум, который сервер может поддерживать при нормальных обстоятельствах, поэтому отсутствует гарантия того, что сервер при любых обстоятельствах сможет поддерживать максимум, поэтому клиент не должен открывать точек больше, чем указано в переменной <Качественное начало>.
Сертификаты программного обеспечения - это массив цифрового представления сертификатов программного обеспечения, описываемых сервером. Сертификат программного обеспечения идентифицирует возможности сервера. Он содержит список профилей, поддерживаемых сервером и описанных в [3].
Свойство максимума длины массива указывает максимальную длину одномерного или многомерного массива, поддерживаемого переменными сервера. В многомерном массиве оно указывает общую длину. Например, трехмерный массив размером 2 x 3 x 10 имеет длину массива 60. Сервер может дополнительно ограничить длину отдельных переменных без уведомления клиента. Серверы могут использовать свойство максимума длины массива, определенное в ГОСТ Р 71808, для его представления в цифровой записи, чтобы указать размер отдельных значений. Отдельное свойство может иметь большее или меньшее значение, чем в максимуме длины массива (см. [5]).
Свойство максимального количества байтов, поддерживаемое переменными сервера, также определяет максимальный размер по умолчанию буферов чтения и записи объекта "Тип файла". Серверы могут переопределить этот параметр, добавив свойство максимума количества байтов, определенное в ГОСТ Р 71808, для отдельного объекта возможностей, или тип файла. Если сервер не устанавливает максимального количества байтов или не может определить максимальное количество байтов, данное свойство не предоставляется.
Ограничения операций - это точка входа для доступа к информации об ограничениях операций сервера, например о максимальной длине массива в вызове службы чтения.
Роли моделирования - это точка входа для просмотра всех ролей моделирования, поддерживаемых сервером. Все роли моделирования, поддерживаемые сервером, должны иметь возможность просмотра.
Объединение функций - это точка входа для просмотра всех объединенных функций, поддерживаемых сервером. Все объединенные функции, поддерживаемые сервером, должны иметь возможность просмотра (подробнее см. [6]).
Объект публикации ролей используется для всех ролей, поддерживаемых сервером. Когда поставщики раскрывают свои возможности, им следует добавить дополнительные узлы к стандартной модификации объекта возможностей сервера.
Этот тип объекта определяет диагностическую информацию о сервере OPC UA, представленную в таблице 9.
Таблица 9
Сервер общей диагностики содержит сводную диагностическую информацию для сервера, как определено в 12.9.
Массив диагностической информации для каждой частоты выборки определен в 12.8. Для каждой частоты дискретизации, используемой в данный момент сервером, имеется одна запись. Наименование типа его узла представляет собой переменную для каждой записи в массиве, как определено в 7.9.
Диагностика интервала выборки собирается только теми серверами, которые используют фиксированный набор интервалов выборки. В этих случаях длина массива и набор содержащихся в нем переменных будут определены конфигурацией сервера, а наименование, присвоенное данной диагностической переменной интервала выборки, не будет меняться до тех пор, пока не изменится конфигурация сервера. Сервер не может предоставлять множество интервальной диагностики, если он не использует фиксированные частоты выборки. Массив диагностической информации о подписке для каждой подписки определен в 12.15. Для каждого фактически установленного канала уведомлений имеется одна запись - это возможный тип.
В сервере каждая запись типа массива диагностики подписок, определенного в 7.11, предоставляет характеристики, на которые могут ссылаться другие переменные. Сессия обобщенной диагностики содержит диагностическую информацию для каждого сеанса (см. 6.3.4).
Установление флага допустимости определяет, собирается ли сервером диагностическая информация. Такой флажок может быть использован клиентом для включения или отключения сбора диагностической информации сервера.
Применяют следующие настройки логического значения: ПРАВДА указывает, что сервер собирает диагностическую информацию, а установка значения ПРАВДА приводит к сбросу и включению сбора. ЛОЖЬ указывает, что диагностическая информация не собирается, а установка значения ЛОЖЬ отключает сбор без сброса диагностических значений.
Когда диагностика отключена, сервер может возвращать информацию для всех статических диагностических узлов, кроме свойства флага допустимости. Узлы динамической диагностики (например, узлы сеансов) не будут отображаться в адресном пространстве. Если сбор диагностической информации не поддерживается, свойство флага допустимости используется только для чтения.
Объект этого типа определяет диагностическую информацию о сессиях OPC UA, представленную в таблице 10.
Таблица 10
Примечание - Последняя строка не представляет узел в адресном пространстве. Заполняющий таблицу указывает, что информация относится к характеристикам конкретных экземпляров объектов данного типа.
Сессия предоставляет массив с записью для каждого активного сеанса на сервере, содержащей диагностическую информацию, связанную с безопасностью. Поскольку эта информация связана с безопасностью, она не должна быть доступной только авторизованным пользователям.
Для каждого сеанса сервера объект этого типа также предоставляет сеанс, обозначенный <имя клиента>. Имя просмотра может быть получено из наименования сессии, определенного в службе создания сессии (см. ГОСТ Р 71809) или в некоторых других механизмах, специфичных для сервера. Как определено в 6.3.5, объект имеет наименование типа сессии объекта диагностики.
Этот тип объекта определяет диагностическую информацию о сеансе сервера OPC UA, представленную в таблице 11.
Таблица 11
Сессия диагностики содержит общую диагностическую информацию о сеансе; переменная сессии закрытой диагностики содержит диагностическую информацию, связанную с безопасностью. Поскольку информация второй переменной связана с безопасностью, она должна быть доступной только авторизованным пользователям.
Массив диагностической информации о подписке на каждую открытую подписку определен в 12.15. Наименование его возможного типа указывает на тип узла. Наименование типа диагностического множества представляет собой переменную для каждой записи в массиве (см. 7.11).
Тип объекта, представленный в таблице 12, устанавливает значение информации конкретного поставщика о сервере OPC UA. Поставщики должны присваивать ему подтипы для определения информации, специфичной для конкретного поставщика.
Таблица 12
Этот тип объекта определяет возможности резервирования, поддерживаемые сервером OPC UA, представленные в таблице 13.
Таблица 13
Поддержка резервирования указывает, какая избыточность поддерживается, и ее значения определены в 12.5. Сервер должен быть установлен в ПРОЗРАЧНОСТЬ_0 для всех экземпляров напрямую посредством наименования типа объекта (без подтипа).
Этот тип объекта представлен в таблице 14, он является подтипом типа "Резервирование сервера" и используется для определения возможностей сервера OPC UA для управления сервером резервирования с прозрачным переключением для клиента.
Таблица 14
Поддержка резервирования наследуется от типа сервера резервирования. Для всех экземпляров этого типа должно быть присвоено значение ПРОЗРАЧНОСТЬ_4. Хотя в сценарии прозрачного переключения все резервные серверы обслуживают клиента под одним и тем же URI, может потребоваться отслеживать точный источник данных на клиенте. Таким образом, текущий идентификатор сервера содержит идентификатор используемого в данный момент сервера в резервном наборе. Этот сервер действителен только внутри сеанса; если клиент открывает несколько сессий, разные серверы из резервного набора серверов могут обслуживать его в разных сессиях. Значение идентификатора сервера может измениться из-за аварийного переключения или балансировки нагрузки, поэтому клиент, которому необходимо отслеживать свой источник данных, должен подписаться на указанную переменную.
В качестве диагностической информации избыточный серверный массив содержит данные с доступных серверов в резервном наборе, включая их уровни обслуживания (см. 12.7). Этот массив может измениться во время сеанса.
Этот тип объекта, представленный в таблице 15, является подтипом типа "Резервирование сервера" и используется для определения возможностей сервера OPC UA при непрозрачной избыточности.
Таблица 15
Массив URI резервных серверов OPC UA, представленный в ГОСТ Р 71809, в настоящем стандарте используется для определения резервирования. В непрозрачной среде резервирования клиент несет ответственность за подписку на резервные серверы, поэтому клиент может открыть сеанс с одним или несколькими резервными серверами этого массива. Массив серверов URI должен содержать локальный сервер.
Поддержка резервирования является следствием применения типа "Резервирование сервера". Он должен быть установлен на ХОЛОД_1, ТЕПЛО_2, ГОРЯЧО_3 или ГОРЯЧО_И_ОТРАЖЕНИЕ_5 для всех экземпляров типа "Непрозрачное резервирование" и определяет поддержку резервирования, предоставляемую сервером. Предполагаемое использование данного типа определено в ГОСТ Р 71809.
Этот тип объекта, представленный в таблице 16, является подтипом типа "Непрозрачное резервирование" и используется для определения возможностей сервера OPC UA для непрозрачного резервирования сети.
Таблица 16
Клиенты, переключающиеся в избыточности между сетевыми путями к одному и тому же серверу, ведут себя так же, как "Горячий" и "Зеркальный". Резервирование сервера и сети можно комбинировать. При комбинированном подходе клиенту следует знать, какие серверы URIs принадлежат одному и тому же серверу, представляющему разные сетевые пути, и какие серверы URIs представляют разные серверы.
Следовательно, для идентификации поддержки избыточности сервер, реализующий непрозрачную избыточность сети, должен использовать тип непрозрачного сетевого резервирования.
Поддержка резервирования наследуется от типа "Резервирование сервера". Он должен быть установлен в ХОЛОД_1, ТЕПЛО_2, ГОРЯЧО_3 или ГОРЯЧО_И_ОТРАЖЕНИЕ_5 для всех экземпляров типа непрозрачного резервирования сети. Если избыточность сервера не поддерживается (массив URI сервера содержит только одну запись), поддержка резервного копирования должна быть установлена в ГОРЯЧО_И_ОТРАЖЕНИЕ_5.
Сетевые группы сервера содержат массив типа данных сетевой группы. URI серверов в этом массиве (в сервере URI структуры) должны быть точно такими же, как и те, которые предоставляются в сервере массива URI. Однако порядок может быть другим. Таким образом, массив представляет собой список резервных серверов Hot And Mirrored. Если сервер поддерживает только резервирование сети, он имеет только одну запись сетевой группы. Сетевые рабочие пути в структуре представляют резервные сетевые пути для каждого из серверов. Сетевые пути описывают различные пути (одна запись для каждого пути), упорядоченные по приоритету. Каждый сетевой путь содержит список адресов URI конечных точек, содержащий массив строк, каждая из которых содержит URL-адрес конечной точки. Это позволяет использовать разные варианты протокола для одного и того же сетевого пути. Предоставленные конечные точки должны совпадать с конечными точками, определенными службой получения конечных точек соответствующего сервера (подробнее см. [1]).
6.3.11 Тип "Эксплуатационные ограничения"
Этот тип, представленный в таблице 17, является подтипом типа "Папка" и используется для определения ограничений работы сервера OPC UA.
Таблица 17
Любое предоставленное свойство эксплуатационных ограничений должно иметь ненулевое значение. Свойство <Максимальное количество узлов для считывания> указывает максимальный размер массива узлов для считывания, когда клиент вызывает службу считывания.
Свойство <Максимальное количество узлов в истории считывания данных> указывает максимальный размер массива узлов для считывания, когда клиент вызывает службу "История считывания" посредством истории считывания деталей RAW, PROCESSED, MODIFIED или ATTIME.
Свойство <Максимальное количество узлов в истории считывания событий> указывает максимальный размер массива узлов для чтения, когда клиент вызывает службу <История чтения> с использованием события <История чтения в деталях>.
Свойство <Максимальное количество узлов на одну запись> указывает максимальный размер массива узлов для записи, когда клиент вызывает службу записи.
Свойство <Максимальное количество узлов в истории динамики данных> указывает максимальный размер массива <Детали обновления истории>, поддерживаемого сервером, когда клиент вызывает службу истории обновления.
Свойство <Максимальное количество узлов в событиях обновления истории> указывает максимальный размер массива истории обновления в деталях, когда клиент вызывает службу истории обновления.
Свойство <Максимальное количество узлов на вызов> указывает максимальный размер массива методов на вызов, когда клиент вызывает службу вызовов.
Свойство <Максимальное количество узлов в одном просмотре> указывает максимальный размер массива узлов для просмотра при вызове службы просмотра или массива продолжения рассмотрения позиций, когда клиент вызывает службу следующего просмотра.
Свойство <Максимальное количество узлов на один регистр узлов> указывает максимальный размер массива <Узлы для регистрации>, когда клиент вызывает службу регистрации узлов, и максимальный размер узлов для снятия с регистрации при вызове службы <Снятие с регистрации узлов>.
Свойство <Максимальное количество узлов для перевода> при просмотре путей к заданному узлу указывает максимальный размер массива просмотра путей, когда клиент вызывает службу просмотра путей перехода к идентификаторам узлов.
Свойство <Максимального количества узлов на один узел управления> указывает максимальный размер массива "Узлы для добавления", когда клиент вызывает службу "Дополнительные узлы", и свойство <Максимальный размер массива ссылок для добавления>, когда клиент вызывает службу добавления ссылок, а также <Максимальный размер массива узлов для удаления>, когда клиент вызывает службу удаления узлов, и <Максимальный размер массива удаления ссылок>, когда клиент вызывает службу удаления ссылок. Свойство <Максимальное количество отслеживаемых элементов за один вызов> указывает максимальный размер:
- массива элементов для создания, когда клиент вызывает службу создания массива отслеживаемых элементов;
- массива элементов, которые необходимо изменить при вызове клиентом службы изменения отслеживаемых элементов;
- массива отслеживаемых идентификаторов элементов, когда клиент вызывает службу установления режима мониторинга или службу удаления отслеживаемых элементов;
- суммы массивов ссылки для добавления и ссылки для удаления, когда клиент вызывает службу настройки.
6.3.12 Тип "Адресное пространство файла"
В таблице 18 представлен файл пространства имен, определенного сервером OPC UA, который показывает адресное пространство XML, использующее схему XML по ГОСТ Р 71811.
Таблица 18
Метод экспорта адресного пространства представляет собой способ перемещения пространства имен с сервера. Адресное пространство в XML-файле - это тип файлов с атрибутами значений, экспортируемыми в том случае, если они содержат статическую информацию о конфигурации. Предполагается, что клиент сначала воспользуется методом экспорта пространства имен, чтобы обновить XML-файл, а затем получит доступ к файлу с помощью методов, определенных в типе файла.
Серверы могут предоставлять некоторые зависящие от поставщика механизмы, импортирующие части адресного пространства как подтип этого типа объекта, например путем определения соответствующих методов (см. ГОСТ Р 71808).
Этот типа объекта, приведенный в таблице 19, определяет метаданные для пространства имен, предоставляемого сервером.
Таблица 19
Экземпляры данного объекта позволяют серверам предоставлять дополнительную информацию, например информацию о версии, в дополнение к URI пространства имен. Наиболее значимой информацией для агрегирования серверов являются следующие параметры: типы идентификаторов узлов, статический числовой диапазон идентификаторов узлов и статический строковый шаблон идентификаторов узлов.
Имя просмотра экземпляров этого типа должно быть получено из описанного пространства имен. Например, это можно сделать посредством индекса в множестве пространства имен (определение имени) и в URI пространства имен как имя <определение имени>. Наименование просмотра экземпляров этого типа должно быть получено из представленного пространства имен, например: посредством индекса пространства имен в множестве пространства имен как индекса определенного имени в пространстве имен и в URI пространства имен.
Значение свойства <Публикации версии пространства имен> предоставляет дату этой публикации. Оно может быть использовано клиентами для определения последней версии, если разные версии направлены разными серверами. Если для пространства имен не приведена официальная дата публикации, для этого свойства должно быть установлено нулевое значение времени - даты.
Свойство <Подсистема пространства имен> определяет доступность всех узлов пространства имен на сервере или только их подмножества. Данному свойству присваивают значение ЛОЖЬ, если указано полное пространство имен, и ПРАВДА, если полное пространство имен не указано.
Статические узлы идентичны для всех атрибутов на всех серверах, включая атрибут значения. Тип узла "Описание", а также декларативное представление должны быть идентичными. Это означает, что для статических узлов семантика неизменно одинаковая. Данная информация необходима для объединения серверов. Если пространство имен динамическое и используется на нескольких серверах, агрегирующему серверу следует различать пространство имен для каждого агрегируемого сервера. Статические узлы пространства имен допускается обрабатывать только один раз, даже если они задействованы на нескольких объединенных серверах (см. ГОСТ Р 71811).
Свойство типа <Статические узлы> предоставляет список типов идентификаторов, задействованных для статических узлов. Все узлы в адресном пространстве пространства имен, использующие один из типов идентификаторов в массиве, должны быть статическими узлами.
Свойство <Диапазон статических числовых идентификаторов узлов> предоставляет список <Числовые диапазоны>, используемый для числовых идентификаторов статических узлов. Если свойство типов статических узлов содержит запись для числовых идентификаторов узла, это свойство игнорируется.
Свойство <Шаблон статической строки узла d> предоставляет выражение, определенное для свойства <Схожесть>, используемого оператором в соответствии с ГОСТ Р 71809 для фильтрации строковых записей статических узлов. Если свойство типов статических узлов содержит запись для их строковых идентификаторов, то это свойство игнорируется.
Объект "Файл пространства имен" содержит все узлы и ссылки пространства имен в XML-файле, где XML-схема информационной модели определена в ГОСТ Р 71811. XML-файл предоставляется через объект "Файл типа пространства имен".
Свойство <Разрешения для ролей по умолчанию> предоставляет разрешения по умолчанию, если сервер поддерживает атрибут <Роль права доступа> для пространства имен. Узел в пространстве имен переопределяет это значение по умолчанию, добавляя атрибут <Роль права доступа в файл> узла. Если сервер реализует атрибут <Роль права доступа>, зависящий от поставщика, для пространства имен, он по умолчанию не добавляет атрибут <Роль права доступа> к объекту метаданные пространства имен.
Атрибут пользователя <Роль права доступа> предоставляет права доступа по умолчанию, если сервер поддерживает для пользователя данный атрибут для пространства имен. Узел в пространстве имен переопределяет это по умолчанию, добавив атрибут пользователя <Роль> и <Роль права доступа в файл узла>. Если сервер реализует модель права доступа к роли пользователя, зависящую от поставщика, для пространства имен, он не добавляет свойство разрешения роли пользователя по умолчанию к объекту "Метаданные пространства имен".
Свойство <Ограничение доступа по умолчанию> присутствует, если сервер поддерживает его для пространства имен и предоставляет значения по умолчанию. Узел в пространстве имен переопределяет это значение по умолчанию, добавляя атрибут ограничения доступа в файл узла. Если сервер реализует модель ограничения доступа, зависящую от поставщика, для пространства имен, он не добавляет ограничения доступа по умолчанию.
6.3.14 Тип "Пространство имен"
Данный тип (см. таблицу 20) определяет список объектов метаданных пространства имен, предоставляемых сервером.
Таблица 20
Наименование просмотра объекта должно быть получено из пространства имен, представленного объектом. Например, индекс пространства имен можно применять для анализа множества пространства имен и URI пространства. Клиенты не должны предполагать, что все пространства имен, описанные сервером, присутствуют в этом списке. Тип "Пространство имен" имеет возможность не предоставлять информацию, необходимую для заполнения всех обязательных свойств типа метаданных пространства имен.
6.4.1 Общие положения
Настоящий стандарт определяет нормативно фиксированные типы событий, представленные в адресном пространстве как типы в соответствии с ГОСТ Р 71808.
Данный тип определен в ГОСТ Р 71808. Его представление в адресном пространстве представлено в таблице 21.
Таблица 21
Информация о типе события генерируется сервером для его идентификации и конкретном уведомлении. Сервер несет ответственность за то, чтобы каждое событие имело свой уникальный идентификатор (подробнее см. [2]). При этом серверу не разрешается возвращать код статуса типа события, указывающий на ошибку. Например, если поместить электронный уникальный идентификатор в битовую строку, то пользователи могут использовать это событие, чтобы минимизировать или устранить пробелы и дублирования, которые могут возникнуть во время переключения при резервировании.
Свойство идентификации узла указывает на узел, на котором произошло событие. Если событие не относится к конкретному узлу, это свойство обозначается значением NULL. Некоторые подтипы типа базовых событий могут определять дополнительные правила для характеристики свойства сервиса узла.
Если событие относится к узлу или к какой-либо нотации, специфичной для сервера, то описание источника события допускается в виде строковой части имени его источника, представленного на мониторе по умолчанию.
Переменная <Время> указывает время, когда произошло событие. Ее значение устанавливается как можно ближе к генератору событий из базовой системы или устройства. После установки промежуточные серверы OPC UA не должны изменять это значение.
Время получения определяет то время, когда на сервере OPC UA произошло событие, поступившее от базового устройства другого сервера. Время приема аналогично времени приема сервером, определенным в ГОСТ Р 71809, т.е. в том случае, когда сервер OPC UA получает информацию о событии от другого сервера OPC UA, каждый сервер применяет собственное время приема. Это означает, что у клиента может произойти одно и то же событие, имеющее одно и то же происхождение, от разных серверов, имеющих разные значения атрибута <Происхождение>.
Время приема неизменно должно возвращаться как значение, и серверу не разрешено возвращать код состояния для времени приема, указывающий на ошибку.
<Местное время> - это структура, содержащая флаг <Смещение> и флаг <Экономия дневного освещения при смещении>. Смещение указывает разницу во времени, мин, между свойством <Время> и временем в том месте, в котором создано событие. Если экономия дневного освещения при смещении имеет значение ПРАВДА, то в исходном местоположении действует стандартное/летнее время, а смещение включает поправку на летнее время; если значение ЛОЖЬ, то смещение не включает поправку на летнее время, поэтому летнее время может или действовать, или не действовать.
Сообщение представляет собой локализуемое текстовое описание события. Сервер может возвратить подходящий текст для описания мероприятия. Нулевая строка не допустима; если у сервера отсутствует описание, он должен вернуть строковую часть узла <Наименование просмотра>, связанного с событием.
Показателем значимости совершения события является его существенность, эту характеристику можно называть "приоритет". Допустимо, что значения оценок существенности могут варьироваться от 1 до 1000, где 1 соответствует наиболее низкой значительности, а 1000 - наиболее высокой. Уровень значительности 1 указывает на событие информационного характера, а значение 1000 - на событие катастрофического характера, которое потенциально может привести к существенным финансовым потерям или гибели людей.
Предполагается, что незначительное количество реализаций сервера будут поддерживать 1000 различных уровней существенности, поэтому разработчики серверов несут ответственность за распределение соответствующих уровней в диапазоне от 1 до 1000 таким образом, чтобы клиенты могли предположить линейное распределение. Например, клиент, который решает предоставить пользователю пять уровней надежности (см. рисунок 1), должен иметь возможность выполнить надлежащее сопоставление.
Во многих случаях строгое линейное сопоставление существенности базового источника с диапазоном точности OPC не совпадает. В этом случае разработчик сервера интеллектуально сопоставляет уровни точности базового источника с диапазоном точности OPC от 1 до 1000 другим способом. В частности, разработчикам серверов рекомендуется сопоставлять: события высокой срочности с диапазоном точности OPC от 667 до 1000, события средней срочности с диапазоном точности OPC от 334 до 666, а события низкой срочности с уровнями точности OPC от 1 до 333.
Например, если источник поддерживает 16 уровней точности, которые сгруппированы таким образом, что уровни существенности от 0 до 2 считают низкими, от 3 до 7 - средними и от 8 до 15 - высокими, тогда надлежащее сопоставление представлено на рисунке 2.
Одни серверы могут не поддерживать события катастрофического характера, поэтому могут отображать все их уровни существенности в подмножестве диапазона от 1 до 1000 (например, от 1 до 666). Другие серверы могут не поддерживать какие-либо события, которые носят информационный характер, поэтому могут отобразить все их уровни существенности в другое подмножество диапазона от 1 до 1000 (например, от 334 до 1000).
Цель этого подхода - позволить клиентам использовать значения оценок существенности с нескольких серверов от разных поставщиков на постоянной основе. Дополнительная информация о существенности приведена в [2].
Описание характеристики данного типа события приведено в ГОСТ Р 71808. Его представление в адресном пространстве определено в таблице 22.
Таблица 22
Данный тип событий наследует все свойства типа "Базовое событие". Их семантика определена в 6.4.2.
Идентификатор сервера однозначно идентифицирует сервер, генерирующий событие, а также сервер в сценарии прозрачной избыточности, управляемой сервером, когда несколько серверов могут использовать один и тот же URI.
Идентификатор записи аудита клиента содержит идентификатор записи аудита, определенный в ГОСТ Р 71808.
Идентификатор пользователя идентифицирует пользователя клиента, запрашивающего действие. Идентификатор пользователя можно получить из токена идентификации пользователя, переданного в вызове активации сеанса. Если токен идентификации пользователя является именем пользователя идентификационного токена, то идентификатор пользователя - это имя пользователя. Если токен идентификации пользователя - это токен идентификации X509, то идентификатор клиента - это имя субъекта X509 сертификата. Если токен идентификации пользователя является выданным идентификационным токеном, то идентификатор пользователя должен быть строкой, которая представляет владельца токена.
Наиболее соответствующий выбор строки зависит от типа выданного идентификационного токена. Если применялся токен анонимной идентификации, значение равно нулю.
Этот тип события определен в ГОСТ Р 71808. Его представление в адресном пространстве формально приведено в таблице 23.
Таблица 23
Тип события "Аудит безопасности" наследует все свойства типа события "Аудит", семантика которых определена в 6.4.3. Для типа события "Аудит безопасности" не установлено дополнительных свойств.
Необязательное свойство "Идентификатор кода состояния" предоставляет точную информацию об ошибке безопасности, ответственной за создание события.
Этот тип события определен в ГОСТ Р 71808. Его представление в адресном пространстве формально приведено в таблице 24.
Таблица 24
Тип события "Канал аудита" наследует все свойства типа события "Аудит безопасности", семантика которых определена в 6.4.4. Свойство узла источника для типа события "Канал аудита" должно быть присвоено объекту сервера. Для этого типа событий должны быть имя источника "Безопасный канал" и служба, которая генерирует событие (например, "Безопасный канал/открыть безопасный канал" или "Безопасный канал/закрыть безопасный канал"). Если идентификатор пользователя клиента недоступен для вызова по закрытому защищенному каналу, то этот параметр должен быть установлен в значение "Система/закрытый защищенный канал".
Идентификатор безопасного канала должен однозначно идентифицировать безопасный канал. Приложение должно использовать один и тот же идентификатор во всех событиях аудита, связанных с набором служб сессии (типы события "Аудит создания сессии", "Аудит активации сессии" и их подтипы) и с набором служб защищенного канала (тип события "Канал аудита" и его подтипы).
Этот тип события определен в ГОСТ Р 71808. Его представление в адресном пространстве формально приведено в таблице 25.
Таблица 25
защищенного канала"
Этот тип события наследует все свойства типа события "Канал аудита", семантика которых определена в 6.4.5. Имя источника для событий данного типа должно быть "Безопасный канал/открытый безопасный канал". Идентификатор пользователя недоступен для этого вызова, поэтому для данного параметра должно быть установлено значение "Система/открытый безопасный канал".
Дополнительные свойства, определенные для данного типа события, отражают параметры вызова службы, который запускает событие.
Параметры вызова службы открытого безопасного канала:
- сертификат клиента;
- эскиз сертификата клиента - отпечаток сертификата клиента. Подробная информация об отпечатках приведена в ГОСТ Р 71811;
- тип заявки;
- политика безопасности URI;
- режим безопасности;
- запрашиваемый срок службы.
Тип события определен в ГОСТ Р 71808. Его представление в адресном пространстве формально показано в таблице 26.
Таблица 26
Данный тип события наследует все свойства типа события "Аудит безопасности", семантика которых определена в 6.4.4.
Если событие генерируется вызовом службы передачи подписки, свойство исходного узла должно быть назначено объекту диагностики сеансов, который представляет сеанс. Имя источника для событий этого типа должно быть "Подписки на сеансы/передачи".
В противном случае свойство исходного узла для событий этого типа должно быть присвоено серверу.
Имя источника для событий этого типа должно быть "Сеанс", а также услугой или причиной, которая генерирует событие.
Идентификатор сеанса должен содержать код сеанса, в котором выполнен вызов службы. В службе создания сессии для него должен быть установлен вновь созданный идентификатор сеанса. Если контекст сеанса не существует (например, для несостоявшегося вызова службы создания сеанса), идентификатор сеанса должен быть нулевым.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 27.
Таблица 27
Этот тип события наследует все свойства типа события "Аудит сессии". Имя источника для событий данного типа должно быть "Атрибут/запись", семантика которых определена в 6.4.24.
Идентификатор атрибута определяет тот атрибут, который записан. Свойство узла источника идентифицирует тот узел, который записан.
Диапазон индексов определяет диапазон индексов записанного атрибута, если атрибут является массивом. Если атрибут не является массивом или был записан весь массив, диапазон индексов устанавливается на ноль.
Новое значение идентифицирует значение, которое записано. Если определен диапазон индексов, будут показаны только значения в указанном диапазоне.
Прежнее значение идентифицирует значение, которое содержал атрибут до его записи. Если указан диапазон индексов, отображаются только значения этого диапазона. Для сервера, не имеющего данной информации, допустимо сообщить нулевое значение. Новое значение и прежнее значение будут содержать значение в типе данных и кодировке, использованной для записи значения (см. ГОСТ Р 70988).
Данный тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 28.
Таблица 28
Тип события наследует все свойства типа события "Аудит создания сеанса", семантика которых определена в 6.4.8.
Дополнительные свойства, определенные для этого типа события, отражают параметры вызова службы, которая запускает событие.
Конечная точка Url - параметр точки Url вызова службы создания сессии.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 29.
Таблица 29
Этот тип события наследует все свойства типа события "Аудит сессии", семантика которых определена в 6.4.7. Имя источника для событий данного типа должно быть "Сессии/активация сессии". Дополнительные свойства, определенные для типа события "Аудит активации сеанса", отражают параметры вызова служб, которые вызывают событие.
Сертификаты клиентского программного обеспечения - параметр сертификатов клиентского программного обеспечения вызова службы активации сессии (см. [7]).
Токен идентификации пользователя - параметр токена идентификации пользователя вызова службы активации сессии. Пароль для токенов имени пользователя/пароля не должен быть включен.
Идентификатор защищенного канала должен однозначно определять защищенный канал. Приложение должно использовать один и тот же идентификатор во всех событиях аудита, связанных с набором служб сессии (тип события "Создание сессии аудита", тип события "Активация сессии аудита" и их подтипы) и с набором служб защищенного канала (тип события "Канал аудита" и его подтипы).
Данный тип события наследует все свойства типа события "Аудит сессии", семантика которых определена в 6.4.7. Имя источника для событий этого типа должно быть "Сессия/активация сессии". Дополнительные свойства, определенные для этого типа события, отражают параметры вызова службы, который запускает событие.
Сертификаты клиентского программного обеспечения - это параметр вызова службы активации сессии. Токен идентификации пользователя отражает параметр службы вызова активации сеанса. Пароль для токенов имени пользователя/пароля не должен включаться.
Идентификатор защищенного канала должен однозначно идентифицировать защищенный канал. Приложение должно использовать один и тот же идентификатор для всех аудиторских мероприятий, связанных с набором служб сеанса (тип события "Аудит создания сеанса", тип события "Аудит активации сеанса" и их подтипы) и с набором служб безопасного канала (тип события "Канал аудита" и его подтипы).
В адресном пространстве его представление формально дано в таблице 30.
Таблица 30
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 31.
Таблица 31
Этот тип события наследует все свойства типа "Аудит сессии", семантика которых определена в 6.4.7. Имя источника для событий данного типа должно быть "Сеанс/отмена". Дополнительные свойства, определенные для типа события "Сертификат аудита", отражают параметры вызова службы, который запускает событие. Ручка запроса - это параметр вызова службы отмены.
Тип события наследует все свойства типа события "Аудит безопасности", семантика которых определена в 6.4.4. Имя источника для событий этого типа должно быть "Безопасность/сертификат".
Сертификат - это сертификат, в котором возникла проблема с проверкой. В связи с чем будут определены дополнительные подтипы этого типа события, представляющие отдельные ошибки проверки. Данный сертификат можно сопоставить со службой, которая его передала (набор служб сеанса или безопасный канал), так как в мероприятиях по аудиту для таких служб также включен сертификат (см. [6]).
Данный тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 32.
Таблица 32
сертификата аудита"
Тип события наследует все свойства типа события "Сертификат аудита", семантика которых определена в 6.4.12. Имя источника для событий этого типа должно быть "Безопасность/сертификат". InvalIDHostname - это строка, представляющая имя хоста, переданное как часть URL-адреса, который оказался недействительным. Если имя хоста не было недействительным, оно может быть нулевым. InvalIDURI - это URI, который передан и оказался не соответствующим тому, что содержится в сертификате. Если URI не был недействительным, он может быть нулевым. Должно быть указано либо InvalIDHostname, либо InvalIDURI.
Данный тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 33.
Таблица 33
аудита истек"
Данный тип события наследует все свойства типа события "Сертификат аудита", семантика которых определена в 6.4.12. Имя источника для событий этого типа должно быть "Безопасность/сертификат". Переменная сообщения должна включать описание того, почему срок действия сертификата истек (т.е. время до начала или время после окончания). Для этого типа события не определены дополнительные свойства.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 34.
Таблица 34
сертификат аудита"
Данный тип события наследует все свойства типа события "Сертификат аудита", семантика которых определена в 6.4.12. Имя источника для событий этого типа должно быть "Безопасность/сертификат". Переменная сообщения должна включать описание того, почему сертификату не доверяют. Если задействована цепочка доверия, следует описать сертификат, который не прошел в цепочке доверия. Для этого типа события не определены дополнительные свойства.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 35.
Таблица 35
Данный тип события наследует все свойства типа события "Сертификат аудита", семантика которых определена в 6.4.12. Имя источника для событий этого типа должно быть "Безопасность/сертификат". Переменная сообщения должна включать описание того, почему сертификат отозван (был ли список отзыва недоступен или сертификат был в списке). Для этого типа события не определены дополнительные свойства.
Данный тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 36.
Таблица 36
Этот тип события наследует все свойства типа события "Сертификат аудита", семантика которых определена в 6.4.12. Имя источника для событий данного типа должно быть "Безопасность/сертификат". Переменная сообщения должна включать описание неправильного использования сертификата. Для событий такого типа не определены дополнительные свойства.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 37.
Таблица 37
Этот тип события наследует все свойства типа события "Сертификат аудита", семантика которых определена в 6.4.12. Имя источника для событий этого типа должно быть "Безопасность/сертификат". Переменная сообщения должна включать описание неправильного использования сертификата. Для этого типа события не определены дополнительные свойства.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 38.
Таблица 38
Тип события наследует все свойства типа события "Аудит", семантика которых описана в 6.4.3. Для данного типа события не определены дополнительные свойства согласно источнику Node. Свойство для этого типа событий должно быть присвоено объекту "Сервер". Имя источника для событий этого типа должно быть NodeManagement, а служба, генерирующая событие, например, AddNodes, AddReferences, DeleteNodes, DeleteReferences.
6.4.20 Тип события "Добавление узлов аудита"
Данный тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 39.
Таблица 39
Тип события наследует все свойства типа события "Управление узлами аудита", семантика которых определена в 6.4.19. Имя источника для событий этого типа должно быть "Управление узлами/добавление узлов".
Дополнительные свойства, определенные для этого типа событий, отражают параметры вызова службы, который запускает событие. NodesToAdd - это параметр узлов для добавления вызова службы добавления узлов.
6.4.21 Тип события "Удаление узлов аудита"
Этот тип события определен в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 40.
Таблица 40
Данный тип события наследует все свойства типа события "Управление узлами аудита", семантика которых определена в 6.4.19. Имя источника для этого типа событий должно быть "Управление узлами/удаление узлов".
Дополнительные свойства, определенные для этого типа события, отражают параметры вызова службы, которая вызывает событие.
Узлы для удаления - это параметр узлов для удаления вызова службы удаления узлов.
6.4.22 Тип события "Добавление ссылок аудита"
Этот тип события определен в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 41.
Таблица 41
Данный тип события наследует все свойства типа события "Управление узлом аудита", семантика которых определена в 6.4.19. Имя источника для этого типа событий должно быть "Управление узлами/дополнительные ссылки".
Дополнительные свойства, определенные для события этого типа, отражают параметры вызова службы, которая запускает данное событие.
ReferencesToAdd - параметр ссылок для добавления вызова службы добавления ссылок.
6.4.23 Тип события "Аудит удаления ссылок"
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 42.
Таблица 42
Данный тип события наследует все свойства типа события "Управление узлами аудита", семантика которых определена в 6.4.19. Имя источника для событий этого типа должно быть "Управление узлами/удаление ссылок".
Дополнительные свойства, определенные для события этого типа, отражают параметры вызова службы, которая вызывает событие.
Узлы для удаления - это параметр ссылок для удаления вызова службы удаления ссылок.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 43.
Таблица 43
Этот тип события наследует все свойства типа события "Аудит", семантика которых определена в 6.4.3. Свойство узла источника для этого типа событий должно быть присвоено идентификатору узла, который изменен. Имя источника для этого типа событий должно быть "Атрибут/", и служба, которая сгенерировала событие, должна быть, например, "Запись", "Обновление истории". Один вызов службы может генерировать несколько событий этого типа, по одному на каждое измененное значение.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 44.
Таблица 44
Этот тип события наследует все свойства типа события "Обновление аудита". Имя источника для этого типа событий должно быть "Атрибут/запись", семантика которых определена в 6.4.24.
Идентификатор атрибута определяет тот атрибут, который записан. Свойство узла источника идентифицирует записанный узел.
Диапазон индексов определяет диапазон индексов записанного атрибута, если атрибут является массивом. Если атрибут не является массивом или был записан весь массив, диапазон индексов устанавливается на ноль.
Новое значение идентифицирует значение, которое записано. Если указан диапазон индексов, показываются только значения в указанном диапазоне.
Прежнее значение идентифицирует значение, которое содержал атрибут до записи. Если указан диапазон индексов, отображаются только значения этого диапазона. Для сервера, не имеющего данной информации, допустимо сообщить нулевое значение.
Новое значение и прежнее значение будут содержать значение типа данных и кодировку, используемую для записи значения.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 45.
Таблица 45
Этот тип события наследует все свойства типа события "Обновление аудита", семантика которых определена в 6.4.24.
Идентификатор типа данных параметра определяет идентификатор типа данных для расширяемого параметра, используемого обновлением истории. Этот параметр указывает на тип выполняемого обновления истории.
Подтипы этого типа события определены в [4], представляя различные возможности манипулирования данными истории.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 46.
Таблица 46
Этот тип события наследует все свойства типа события "Аудит", семантика которых определена в 6.4.3. Свойство узла источника для этого типа событий должно быть назначено на идентификатор узла объекта, на котором находится метод. Имя источника для этого типа событий должно быть "Атрибут/вызов". Допускается, что один вызов службы может генерировать несколько событий этого типа, по одному на каждый вызванный метод. Событие этого типа должно быть дополнительно подтипизировано, чтобы более четко охарактеризовать функциональность метода и отразить изменения в адресном пространстве или обновленные значения, вызванные методом.
Идентификатор метода определяет метод, который вызван.
Вводные аргументы определяют входные аргументы для метода. Этот параметр может быть равен нулю, если входные аргументы не предоставлены.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 47.
Таблица 47
Данный тип события наследует все свойства типа "Базовое событие", семантика которых определена в 6.4.2. Для этого типа события не определены дополнительные свойства.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 48.
Таблица 48
Этот тип события наследует все свойства типа события "Система", семантика которых определена в 6.4.28. Для данного типа события не определены дополнительные свойства.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 49.
Таблица 49
Данный тип события наследует все свойства типа события "Система", семантика которых определена в 6.4.28. Свойство узла источника и имя источника должны идентифицировать систему. Системой может быть как непосредственно сервер, так и какая-либо базовая система.
Состояние системы определяет ее текущее состояние. Изменения состояния сервера системы должны вызывать событие изменения состояния системы, если это событие поддерживается системой.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 50.
Таблица 50
Данный тип события наследует все свойства типа "Базовое событие", семантика которых приведена в 6.4.2. Дополнительные свойства для этого типа событий не определены. Свойство узла источника для этого типа событий должно быть узлом представления, которое дает контекст изменений. Если контекстом является все адресное пространство, то свойство узла источника настраивается на идентификатор узла объекта сервера. Имя источника для этого типа событий должно быть частью строки поискового имени представления; для всего адресного пространства - это имя "Сервер".
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 51.
Таблица 51
Этот тип события наследует все свойства типа события "Изменение общей модели", семантика которых определена в 6.4.31.
Дополнительное свойство, определенное для этого типа события, отражает изменения, вызвавшие событие изменения модели. Оно должно содержать как минимум одну запись в своем массиве, структура которого представлена в 12.16.
Этот тип события описан в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 52.
Таблица 52
Событие этого типа наследует все свойства типа "Базовое событие", семантика которых представлена в 6.4.2. Дополнительные свойства для данного типа события не определены. Свойство узла источника для этого типа событий должно быть узлом представления, дающего контекст изменений. Если контекстом является все адресное пространство, свойство узла источника устанавливается в идентификатор узла объекта сервера. Имя источника для этого типа событий должно быть частью строки поискового имени представления, для всего адресного пространства - это имя "Сервер".
Дополнительное свойство, определенное для этого типа события, отражает изменения, которые вызвали событие "Семантическое представление смены". Его структура определена в 12.17.
Тип события "Переполнение очереди событий" генерируется, когда внутренняя очередь элемента мониторинга, подписывающегося на события в сервере, переполняется. В ГОСТ Р 71809 определено, когда должны генерироваться внутренние события переполнения очереди событий.
Тип события "Переполнение очереди событий" формально определен в таблице 53.
Таблица 53
Данный тип события наследует все свойства типа "Базовое событие", семантика которых определена в 6.4.2. Свойство узла источника для этого типа событий должно быть присвоено идентификатору узла объекта сервера. Имя источника для этого типа событий должно быть "Внутреннее/переполнение очереди событий".
Тип события "Прогресс" генерируется для определения хода выполнения операции. Операция может быть вызовом службы или чем-то специфическим для приложения, например выполнение программы.
Тип события "Прогресс" формально определен в таблице 54.
Таблица 54
Этот тип события наследует все свойства типа "Базовое событие", семантика которых определена в 6.4.2. Свойство узла источника для этого типа событий должно быть присвоено идентификатору узла объекта сессии, в котором инициирована операция. Узел источника для этого типа событий должен быть "Сервис/<имя сервиса>", если ход отображается вызовом службы.
Дополнительное свойство контекста содержит контекстную информацию о том, какой ход операции сообщается. В случае вызовов службы это должен быть UInt32, содержащий дескриптор запроса заголовка запроса вызова службы.
Дополнительное свойство прогресса содержит процент выполнения. Значение должно находиться в диапазоне от 0 до 100, где 100 означает, что операция завершена.
Рекомендуется, чтобы серверы передавали события прогресса для вызовов служб сессии, которая службу вызвала.
Правила моделирования определены в ГОСТ Р 71808. Этот тип объекта использован в качестве типа "Правила моделирования". Его формальное определение приведено в таблице 55.
Таблица 55
Правило наименования свойств идентифицирует правило наименования правил моделирования, как определено в ГОСТ Р 71808.
Экземпляры этого типа объектов используют для организации адресного пространства в иерархию узлов. Они представляют корневой узел поддерева и не имеют другой семантики, связанной с ними. Однако отображаемое имя экземпляра типа "Папка", например "Типы объектов", должно подразумевать семантику, связанную с его использованием. Для этого типа объектов ссылки не установлены. Его формальное определение приведено в таблице 56.
Таблица 56
Кодирование данных определено в ГОСТ Р 71808. Этот тип объекта используют в качестве типа для кодировок типа данных. Для данного типа объектов ссылки не установлены. Его формальное определение приведено в таблице 57.
Таблица 57
Этот тип объекта устанавливает агрегатную функцию, поддерживаемую сервером UA. Его формальное определение приведено в таблице 58.
Таблица 58
Для типа агрегатной функции атрибут описания является обязательным. Атрибут описания обеспечивает локализованное описание агрегатной функции. Конкретные агрегатные функции определены в ГОСТ Р 71806.
Как правило, компоненты сложного типа переменных фиксированы и могут быть расширены с помощью подтипов. Однако, поскольку каждая переменная типа переменных может быть расширена дополнительными компонентами, настоящий стандарт позволяет расширить стандартные типы переменных, определенные в нем, дополнительными компонентами. Это дает возможность выразить в определении типа дополнительную информацию, которая в любом случае будет содержаться в каждой переменной. Однако не допускается ограничивать компоненты стандартных типов переменных, приведенных в настоящем стандарте. Примером расширения типов переменных может быть включение стандартного свойства версии узла, определенного в ГОСТ Р 71808, в тип базовой переменной данных, утверждающий, что каждая переменная данных сервера будет предоставлять версию узла.
Тип базовой переменной - это абстрактный базовый тип для всех остальных типов переменных. Однако от этого типа наследуются напрямую только тип свойства и тип базовой переменной данных.
Для этого типа переменных определены только ссылки на наличие подтипа. Его формальное определение приведено в таблице 59.
Таблица 59
Тип свойства является подтипом типа базовой переменной. Он используется в качестве определения типа для всех свойств. Свойства устанавливаются в соответствии с их поисковым именем, поэтому им не требуется специализированного определения типа. Выделение подтипа данного типа переменной не допускается.
Для данного типа переменных не определены ссылки, что формально отражено в таблице 60.
Таблица 60
Тип переменной базовых данных является подтипом типа базовой переменной. Он используется в качестве определения типа, когда для переменной отсутствуют данные более конкретного определения типа. Такой тип переменной является базовым типом переменной для типов переменных данных, и все остальные типы переменных данных должны прямо или косвенно наследоваться от него. Допускается, что серверы не смогут предоставить все ссылки на наличие подтипа от этого типа переменных к его подтипам, и поэтому предоставлять подобного рода информацию не требуется.
Для этого типа переменных определены ссылки только на наличие подтипа, что формально отражено в таблице 61.
Таблица 61
Данный тип переменной является абстрактным типом, подтипы которого определяют возможности сервера. Поставщики могут определять подтипы этого типа, что формально отражено в таблице 62.
Таблица 62
Данный комплексный тип переменной используют для информации о состоянии сервера. Его переменные данных отражают тип данных с такой же семантикой, которая отражена в 12.10. Формальное определение типа переменной приведено в таблице 63.
Таблица 63
Данный комплексный тип переменной используется для информации о состоянии сервера. Его переменные данных отражают тип данных, имея такую же семантику, которая определена в 12.4. Формально тип переменной приведен в таблице 64.
Таблица 64
Этот сложный тип переменной используют для диагностической информации. Его переменные данных отражают тип данных, имея такую же семантику, которая определена в 12.9. Формально тип переменной приведен в таблице 65.
Таблица 65
Данный сложный тип переменной используют для диагностической информации. Для каждого элемента массива экземпляры этого типа будут предоставлять переменную типа диагностики интервала выборки. Тип переменной имеет частоту выборки как поисковое имя. Формальное определение типа переменной приведено в таблице 66.
Таблица 66
Данный сложный тип переменной используют для диагностической информации. Его переменные данных отражают тип данных, имея такую же семантику, которая представлена в 12.9. Формальное определение типа переменной приведено в таблице 67.
Таблица 67
Данный сложный тип переменной используют для диагностической информации. Для каждой записи массива экземпляры этого типа будут предоставлять переменную типа диагностики переменной. Тип переменной с идентификатором подписки в качестве поискового имени. Формальное определение типа переменной приведено в таблице 68.
Таблица 68
Этот сложный тип переменных используют для диагностической информации. Его переменные данные отражают его тип данных, имея такую же семантику, которая определена в 12.15. Тип переменной формально определен в таблице 69.
Таблица 69
Этот комплексный тип переменных используют для диагностической информации. Для каждой записи массива экземпляры этого типа будут предоставлять переменную типа переменной массива диагностики сессии. Тип переменной имеет диагностику сессии в качестве поискового имени. На данные переменные также будут ссылаться объекты диагностики сессии, установленные их типом в 6.3.5. Формальное определение типа переменной приведено в таблице 70.
Таблица 70
Данный комплексный тип переменных используют для диагностической информации. Его переменные данных отражают тип данных и имеют такую же семантику, которая определена в 12.11. Формальное определение типа переменной приведено в таблице 71.
Таблица 71
Данный комплексный тип переменных используют для диагностической информации. Для каждой записи массива экземпляры этого типа будут предоставлять переменную типа диагностики безопасности сессии. Тип переменной имеет в качестве поискового имени диагностику безопасности сессии. На эти переменные также будут ссылаться объекты диагностики сессии, определенные их типом в 6.3.5. Тип переменной формально определен в таблице 72. Поскольку эта информация связана с безопасностью, она должна быть доступна только авторизованным пользователям.
Таблица 72
Этот комплексный тип переменной используется для диагностической информации. Его переменные данных отражают его тип данных, имея такую же семантику, которая определена в 12.12. Формальное определение типа переменной приведено в таблице 73. Так как эта информация связана с безопасностью, она должна быть доступна не всем пользователям, а только авторизованным.
Таблица 73
Тип переменной набора опций используют для представления битовой маски. Каждый элемент массива свойства значения набора опций содержит либо читаемое человеком представление для соответствующего бита, используемого в наборе опций, либо пустой локализованный текст для бита, не имеющего конкретное значение. Порядок битов битовой маски соответствует позиции массива, т.е. первый бит (младший значащий бит) соответствует первой записи в массиве и т.д.
В дополнение к этому типу переменных для представления битовой маски можно альтернативно применять опцию набора типа данных. Как правило, тип данных используется, когда битовая маска фиксирована и применяется к нескольким переменным. Тип переменной используется, когда битовая маска специфична только для этой переменной.
Тип данных этого типа переменной должен быть способен представлять битовую маску. Это должен быть либо числовой тип данных, представляющий знаковое или беззнаковое целое число, либо строка байтов, например: это может быть тип данных маска поля битов.
Необязательное свойство маски бита предоставляет маску бита в виде массива булевых значений. Это позволяет подписываться на отдельные записи битовой маски. Порядок битов битовой маски указывает на позицию массива, т.е. первый бит указывает на первую запись в массиве и т.д. Формальное определение типа переменной приведено в таблице 74.
Таблица 74
Тип переменной типа списка выбора используют для той переменной, которая возможные значения представляет набором значений.
Свойство выборов содержит массив значений, которые представляют собой допустимые значения для значения данного типа переменной.
Тип данных массива свойства выборов должен быть такого же типа данных, как и тип переменной.
Каждый элемент массива необязательного свойства описания выборов содержит понятное человеку представление соответствующего значения в свойстве выборов и должен иметь такой же размер массива, как и свойство выборов.
Значение этого типа переменной может быть ограничено только значениями, определенными в свойстве выборов, путем установки необязательного свойства "Ограничение списком" в значение ПРАВДА. Если свойство "Ограничение списком" отсутствует или имеет значение ЛОЖЬ, то значение не ограничивается набором, определенным свойством выборов.
Формальное определение типа переменной приведено в таблице 75.
Таблица 75
Тип аудиопеременной определяет тип свойства "Слышимый звук" мультимедиа многоцелевых почтовых расширений Интернета (MIME). Тип аудиопеременной ссылается на тип содержимого, который определяют как часть типа MIME и обычно используют как ссылку на конкретное MIME. Медиатип верхнего уровня применяют для объявления общего типа данных, в то время как подтип определяет конкретный формат для этого типа данных. Медиатип audio/xyz является достаточным описанием для агента пользователя для того, чтобы понять, что данные являются аудиофайлом, даже если агент пользователя не имеет представления о конкретном формате аудио xyz.
Формальное определение типа переменной приведено в таблице 76.
Таблица 76
Объекты и переменные, описанные в нижеприведенных пунктах, могут быть расширены за счет дополнительных свойств или ссылок на другие узлы, за исключением тех случаев, когда в тексте указано, что это ограничено.
8.2.1 Аннотация
Для обеспечения совместимости клиентов и серверов адресное пространство OPC UA структурировано в виде иерархии, верхние уровни которой стандартизованы для всех серверов. Остальная часть данного адресного пространства содержит описание стандартных узлов и организацию узлов под ними. Допустимо, чтобы серверы реализовывали подмножество стандартных узлов в зависимости от заложенных в них возможностей.
8.2.2 Корень
Данный стандартный объект является точкой входа для просмотра адресного пространства. Он содержит набор организации ссылок, которые указывают на другие стандартные объекты. Корневой объект не должен ссылаться на другие классы узлов. Он формально определен в таблице 77.
Таблица 77
Данный стандартный объект является точкой входа для просмотра представлений. Для связи узлов представлений со стандартным объектом "Представления" применяются только ссылки представлений. Все узлы представлений в адресном пространстве должны ссылаться на этот узел, напрямую или косвенно. Объект представлений может ссылаться на другие объекты с помощью ссылок организации. Эти объекты могут ссылаться на дополнительные представления. Стандартный объект "Представление" напрямую ссылается на представления "Представление 1" и "Представление 2" и косвенно на "Представление 3", ссылаясь на другой объект под наименованием "Проектирование".
Объект "Представление" не должен ссылаться на другие классы узлов. Данный объект формально определен в таблице 78.
Таблица 78
Данный стандартный объект - это точка входа для поиска узлов объектов. Для связи объектов со стандартным объектом "Объекты" используются только организующие ссылки. Допускается применение представления как точки входа в подмножество адресного пространства, содержащего объекты и переменные. Допустимо, чтобы объект "Объекты" ссылался на узлы представления с помощью организующих ссылок. Целью объекта "Объекты" является то, что все объекты и переменные, которые не используются для определения типов или других организационных целей (организация представлений), доступны через иерархические ссылки, начиная с этого узла. Данное требование не является обязательным, так как не все серверы могут поддерживать возможность ссылки конкретного объекта на стандартный объект сервера, определенный в 8.3.2.
Объект "Объекты" не должен ссылаться на другие классы узла. Объект "Объекты" формально определен в таблица 79.
Таблица 79
Данный стандартный узел объекта является точкой входа для просмотра узлов типа. Для связи объектов со стандартным объектом "Типы" используются только организации ссылок. Объект "Типы" не должен ссылаться на другие классы узла и формально определен в таблице 80.
Таблица 80
Данный стандартный узел объекта является точкой входа для поиска узлов типа объектов. Для связи объектов и типов объектов со стандартным объектом "Типы объектов" используются только организации ссылок. Объект "Типы объектов" не должен ссылаться на другие классы узлов.
Цель применения объекта "Типы объектов" - обеспечение прямой или косвенной доступности всех типов объектов сервера при просмотре иерархических ссылок, начиная с узла точки входа. Данная норма не является обязательной, так как ряд серверов не представляют широко известные типы объектов, например тип "Сервер", определенный в 6.3.1.
Данный объект косвенно ссылается на тип базовых событий, определенный в 6.4.2, который является базовым типом всех типов событий. Таким образом, это точка входа для всех типов событий, предоставляемых сервером. Требуется, чтобы сервер выставлял все свои типы событий, чтобы клиент мог с пользой подписываться на события.
Объект "Типы объектов" формально определен в таблице 81.
Таблица 81
Данный стандартный объект является точкой входа для поиска узлов типа переменной. Для связи объектов и типов переменных со стандартным объектом "Типы переменных" используются только организации ссылок. Объект "Типы переменных" не должен ссылаться на другие классы узлов.
Целью объекта "Типы переменных" является обеспечение прямой или косвенной доступности всех типов переменных сервера при просмотре иерархическими референсами, начиная с узла точки входа. Допустимо, что серверы могут не предоставлять некоторые из своих типов переменных, так как они могут быть широко известны в отрасли, например "Тип базовой переменной", определенный в 7.2.
Объект "Типы переменных" формально определен в таблице 82.
Таблица 82
Данный стандартный объект является точкой входа для просмотра узлов типа ссылки. Организации ссылки применяются для определения типов ссылок и объектов, на которые ссылается объект "Типы ссылок". Объект "Типы ссылок" не должен ссылаться на другие классы узлов. Стандартные типы ссылок, которые отображены под объектом "Типы ссылок", описаны в разделе 11.
Так как типы ссылок применены в качестве фильтров в службе просмотра и в запросах, сервер должен предоставить все свои типы ссылок, напрямую или косвенно следуя иерархическим ссылкам, начиная с объекта "Типы ссылок". Данная норма означает, что каждый раз, когда клиент следует по ссылке, сервер должен предоставлять тип этой ссылки в иерархии типов ссылок. Он должен предоставить все типы ссылок, чтобы клиент мог, следуя обратному подтипу ссылок, прийти к базовому типу ссылок. Сервер должен предоставить типы ссылок, которые клиент еще не использовал.
Объект "Типы ссылок" формально определен в таблице 83.
Таблица 83
Данный стандартный объект является точкой входа для просмотра типов данных, которые сервер может раскрыть в адресном пространстве (см. ГОСТ Р 71808).
Узлы типа данных должны быть доступны с помощью организации ссылок, указывающих либо напрямую из объекта "Типы данных" на узлы типа данных, либо с помощью дополнительных объектов папки для целей группировки. Цель состоит в том, чтобы все типы данных сервера, представленные в адресном пространстве, были доступны после иерархических ссылок начиная с объекта "Типы данных". Объект "Типы данных" формально определен в таблица 84.
Таблица 84
Данный стандартный объект является точкой входа для просмотра узлов типа события. Для связи объектов и типов объектов со стандартным объектом "Типы событий" применяются только организации ссылок. Объект "Типы событий" не должен ссылаться на другие классы узлов.
Целью объекта "Типы событий" является обеспечение прямой или косвенной доступности путем просмотра иерархических ссылок, начиная с входного узла.
Для всех типов событий сервера требуется, чтобы сервер раскрывал все свои типы событий, чтобы клиент мог с пользой подписаться на события.
Объект "Типы событий" формально определен в таблице 85.
Таблица 85
8.3.1 Общие положения
Объект сервера и содержащиеся в нем объекты и переменные построены так, что информацию допустимо получать несколькими способами, подходящими для разных типов клиентов с разными требованиями.
Объект сводки диагностики сессии имеет один объект на сессию и переменную с массивом с одной записью на сессию. Массив имеет сложный тип данных, содержащий диагностическую информацию о сессии. Каждый объект, определяющий сессию, ссылается на сложную переменную, содержащую информацию о сеансе, посредством тот же тип данных, что и массив, содержащий информацию обо всех сессиях. Такая переменная также представляет всю свою информацию как переменные с простыми типами данных, содержащие такую же информацию, как и в сложном типе данных.
Сервер предоставляет массив с записью на подписку, содержащей диагностическую информацию об этой подписке. Каждая запись этого массива также определена как сложная переменная с переменными для каждого отдельного значения. Каждый объект, представляющий сессию, также предоставляет такой массив, как обеспечивающий подписки сессии.
Массивы, содержащие информацию о сессиях или подписках, могут иметь разную длину для разных подключений с разными учетными данными пользователя, так как не все пользователи могут видеть все записи массива. Это также подразумевает, что длина массива может измениться, если пользователь идентифицируется. Поэтому клиенты, которые подписываются на определенный диапазон индексов, могут получить непрогнозируемые результаты.
Данный объект применяют как точку входа для просмотра информации о сервере. Содержимое этого объекта определено как представление типа в 6.3.1. Формально оно приведено в таблице 86. Объект сервера служит корневым уведомителем, т.е. его атрибут уведомителя о событиях должен быть установлен, предоставляя события. Все события сервера должны быть доступны клиентам, подписанным на события объекта сервера.
Таблица 86
8.4.1 Объект "Раскрытие массива"
Правило моделирования (раскрытие массива) приведено в ГОСТ Р 71808, которое представлено в адресном пространстве. Объект "Раскрытие массива" формально определен в таблице 87.
Таблица 87
8.4.2 Обязательное правило моделирования
Обязательное правило моделирования является определенным в ГОСТ Р 71808. В таблице 88 определено представление в адресном пространстве обязательного правила моделирования.
Таблица 88
8.4.3 Необязательное правило моделирования
Необязательное правило моделирования определено в ГОСТ Р 71808. В адресном пространстве необязательное правило моделирования формально представлено в таблице 89.
Таблица 89
8.4.4 Правило моделирования "Необязательный заполнитель"
Правило моделирования "Необязательный заполнитель" определено в ГОСТ Р 71808. Его представление в адресном пространстве формально определено в таблице 90.
Таблица 90
"Необязательный заполнитель"
8.4.5 Правило моделирования "Обязательный заполнитель"
Правило моделирования "Обязательный заполнитель" определено в ГОСТ Р 71808. Его представительство в адресном пространстве формально определено в таблице 91.
Таблица 91
Метод получения элементов мониторинга используют для поиска информации о контролируемых элементах мониторинга. Способы его применения перечислены в ГОСТ Р 71809. Формальное описание определений представлено в таблице 92.
Таблица 92
Коды результатов метода получения данных определены в службе вызовов, которые формально представлены в таблице 93.
Таблица 93
В таблице 94 представлено адресное пространство для метода получения элементов мониторинга.
Таблица 94
элементов мониторинга
Метод повторной отправки данных используют для получения текущих значений параметров отслеживаемых элементов данных подписки, где режим мониторинга установлен на отчет. Алгоритм и условие его применения определены в ГОСТ Р 71809 и в таблице 95.
Таблица 95
В таблице 96 представлены определения кодов в службе вызовов текущих значений параметров отслеживаемых элементов данных подписки.
Таблица 96
В таблица 97 представлено адресное пространство для метода повторной отправки данных.
Таблица 97
повторной отправки данных
Метод установки продолжительности подписки применяют для установки подписки в тот режим, в котором данные элементов мониторинга и очереди событий сохраняются и доставляются, даже если клиент OPC UA отключен в течение длительного времени или сервер OPC UA перезапущен. Алгоритм его использования представлен в ГОСТ Р 71809. Формальное определение установки режима подписки приведено в таблице 98.
Таблица 98
Формальное представление кодов результата запроса, определенных в службе вызовов, приведено в таблице 99.
Таблица 99
В таблице 100 представлено адресное пространство для метода установки продолжительности подписки.
Таблица 100
продолжительности подписки
Метод запроса изменения состояния сервера позволяет клиенту запросить сервер об изменении состояния. При вызове данного метода на сервере клиент должен дать учетные данные с правами администратора. В таблице 101 приведено описание аргументов, определяющих предоставление учетных данных от сервера.
Таблица 101
В таблице 102 приведено описание ограничений в предоставлении службой вызовов учетных данных, поступивших от сервера.
Таблица 102
учетных данных
В таблице 103 представлено адресное пространство для метода изменения запроса состояния сервера.
Таблица 103
в адресном пространстве
Базовые представления OPC UA не определены.
Данный стандартный тип ссылки определен в ГОСТ Р 71808. В таблице 104 тип ссылки представлен в адресном пространстве.
Таблица 104
Данный стандартный тип ссылки определен в ГОСТ Р 71808. В таблице 105 тип иерархических ссылок представлен в адресном пространстве.
Таблица 105
Данный стандартный тип ссылки определен в ГОСТ Р 71808. В таблице 106 тип неиерархических ссылок представлен в адресном пространстве.
Таблица 106
Данный стандартный тип ссылки определен в ГОСТ Р 71808. В таблице 107 этот тип представлен в адресном пространстве.
Таблица 107
Данный стандартный тип ссылки определен в ГОСТ Р 71808. В таблице 108 этот тип представлен в адресном пространстве.
Таблица 108
Данный стандартный тип ссылки определен в ГОСТ Р 71808. В таблице 109 этот тип представлен в адресном пространстве.
Таблица 109
Данный стандартный тип ссылки определен в ГОСТ Р 71808. В таблице 110 этот тип представлен в адресном пространстве.
Таблица 110
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 111 этот тип представлен в адресном пространстве.
Таблица 111
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 112 этот тип представлен в адресном пространстве.
Таблица 112
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 113 этот тип представлен в адресном пространстве.
Таблица 113
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 114 этот тип представлен в адресном пространстве.
Таблица 114
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 115 этот тип представлен в адресном пространстве.
Таблица 115
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 116 этот тип представлен в адресном пространстве.
Таблица 116
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 117 этот тип представлен в адресном пространстве.
Таблица 117
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 118 этот тип представлен в адресном пространстве.
Таблица 118
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 119 этот тип представлен в адресном пространстве.
Таблица 119
Данный стандартный тип ссылки определен в ГОСТ Р 71808.
В таблице 120 этот тип представлен в адресном пространстве.
Таблица 120
Сервер OPC UA не должен раскрывать свои типы данных в собственном адресном пространстве. Независимо от раскрытия типов данных он должен поддерживать типы данных, как описано в нижеприведенных подразделах.
12.2 Типы данных, определенные в ГОСТ Р 71808
Набор этих данных определен в ГОСТ Р 71808. Его представление в адресном пространстве приведено в таблице 121.
Таблица 121
Определения типа данных в ГОСТ Р 71808
Только некоторые из типов данных, определенных в таблице 121, являются источниками ссылок в соответствии с таблицей 124.
Ссылки типа базовых данных определены в таблице 122.
Таблица 122
Ссылки на структуру определены в таблице 123.
Таблица 123
Ссылки перечисления определены в таблице 124.
Таблица 124
Ссылки строки байтов определены в таблице 125.
Таблица 125
Ссылки на числа определены в таблице 126.
Таблица 126
Ссылки удвоения определены в таблице 127.
Таблица 127
Ссылки целого числа определены в таблице 128.
Таблица 128
Ссылки времени и даты определены в таблице 129.
Таблица 129
Ссылки на строку определены в таблице 130.
Таблица 130
Ссылки на целое число U определены в таблице 131.
Таблица 131
Ссылки на изображение определены в таблице 132.
Таблица 132
Ссылки UInt64 определены в таблице 133.
Таблица 133
Ссылки определения типа даты определены в таблице 134.
Таблица 134
Ссылки типа значения перечисления определены в таблице 135.
Таблица 135
12.3 Типы данных, определенные в ГОСТ Р 71809
В ГОСТ Р 71809 определен набор типов данных. Его представление в адресном пространстве указано в таблице 136.
Таблица 136
Тип запроса токена безопасности - это перечисление, которое определяется как тип параметра типа запроса службы открытого защищенного канала в ГОСТ Р 71809.
Элемент добавления узлов - это структура, которая определяется как тип параметра узлов для добавления службы добавления узлов в ГОСТ Р 71809. Элемент добавления ссылок - это структура, которая определяется как тип параметра ссылок для добавления службы добавления ссылок в ГОСТ Р 71809. Элемент удаления узлов - это структура, которая определяется как тип параметра узлов для удаления службы удаления узлов в ГОСТ Р 71809.
Элемент удаления ссылок - это структура, которая определяется как тип параметра ссылок для удаления службы удаления ссылок в ГОСТ Р 71809.
Ссылки токена идентификации пользователя определены в таблице 137.
Таблица 137
Данная структура содержит элементы, описывающие информацию о сборе сервера. Ее элементы определены в таблице 138.
Таблица 138
Представление сборки в адресном пространстве описано в таблице 139.
Таблица 139
Тип данных (перечисление), которое определяет поддержку резервирования сервера, представлен в таблице 140.
Таблица 140
Более подробное описание различных значений приведено в ГОСТ Р 71809. Его представление в адресном пространстве определено в таблице 141.
Таблица 141
Данный тип данных - перечисление, которое определяет состояние выполнения сервера. Его значения приведены в таблице 142.
Таблица 142
Представление состояния сервера в адресном пространстве определено в таблице 143.
Таблица 143
Данная структура состоит из элементов, описывающих статус сервера. Его значения определены в таблице 144.
Таблица 144
Представление типа данных резервного сервера в адресном пространстве определено в таблице 145.
Таблица 145
Данная структура состоит из элементов, описывающих статус сервера. Его значения определены в таблице 146.
Таблица 146
Представление типа данных диагностики интервалов выборки в адресном пространстве определено в таблице 147.
Таблица 147
Данная структура содержит диагностическую краткую информацию для сервера. Ее элементы определены в таблице 148.
Таблица 148
Представление типа данных сводки диагностики сервера в адресном пространстве определено в таблице 149.
Таблица 149
Данная структура содержит элементы, описывающие состояние сервера. Ее состав определен в таблице 150.
Таблица 150
Представление типа данных состояния сервера в адресном пространстве определено в таблице 151.
Таблица 151
Данная структура содержит диагностическую информацию о клиентских сеансах. Ее элементы определены в таблице 152. Большинство значений, представленных в этой структуре, дают информацию о количестве вызовов службы, количестве используемых в данный момент элементов мониторинга и т.д. Допускается, что числа необязательно должны предоставлять точное значение; они должны предоставлять приблизительное число, чтобы сервер не был обременен предоставлением точных чисел.
Таблица 152
Представление типа данных диагностики сессии в адресном пространстве определено в таблице 153.
Таблица 153
Данная структура содержит диагностическую информацию, связанную с безопасностью, о клиентских сеансах. Ее элементы определены в таблице 154. Так как эта информация связана с безопасностью, доступ к ней имеют только авторизованные пользователи.
Таблица 154
Представление объекта "Тип данных диагностики безопасности сессии" в адресном пространстве определено в таблице 155.
Таблица 155
Данная структура содержит диагностическую информацию о подписках. Ее элементы определены в таблице 156.
Таблица 156
Представление типа данных счетчика услуг в адресном пространстве определено в таблице 157.
Таблица 157
Данная структура объединяет код состояния и диагностическую информацию и может быть использована с помощью методов возврата нескольких кодов состояния и соответствующей диагностической информации, которые не обрабатываются в параметрах службы вызова. Элементы этого типа данных определены в таблице 158. Причем возвращение диагностической информации зависит от настройки вызовов службы.
Таблица 158
Представление состояния в адресном пространстве определено в таблице 159.
Таблица 159
Данная структура содержит диагностическую информацию о подписках. Ее элементы определены в таблице 160.
Таблица 160
Представление в адресном пространстве данных диагностики подписки определено в таблице 161.
Таблица 161
Данная структура содержит элементы, описывающие изменения модели. Ее состав определен в таблице 162.
Таблица 162
Глагол представляет собой 8-битовое беззнаковое целое число, используемое в качестве битовой маски со структурой, определенной в таблице 163.
Таблица 163
Глагол может идентифицировать несколько изменений на затронутом типе одновременно. Эту функцию следует использовать, если применяется сжатие событий (см. ГОСТ Р 71808 для получения подробной информации).
Все глаголы должны быть рассмотрены в том контексте, в котором использован тип данных структуры изменения модели.
Удаленный узел может указывать на то, что узел удален из одного представления, но существует в других представлениях.
Представление в адресном пространстве данных структуры изменения модели определено в таблице 164.
Таблица 164
Данная структура содержит элементы, описывающие изменение модели. Ее состав определен в таблице 165.
Таблица 165
Представление данных семантического изменения в адресном пространстве определено в таблице 166.
Таблица 166
Этот простой тип данных является подтипом UInt64 и представляет собой битовую маску длиной не более 32 бит, в которой отдельные биты могут быть записаны без изменения других битов.
Первые 32 бита (наименее значимые биты) типа данных маски поля битов представляют собой битовую маску, а вторые 32 бита - действительность битов в битовой маске. Когда сервер возвращает значение клиенту, действительность предоставляет информацию о том, какие биты в битовой маске имеют значение. Когда клиент передает значение серверу, действительность определяет, какие биты должны быть записаны. Только те биты, которые определены в действительность, изменяются в битовой маске, все остальные остаются прежними. Тип данных маски поля битов допускается использовать как тип данных в типе переменной типа установки опции.
Его представление в адресном пространстве определено в таблице 167.
Таблица 167
Данная структура содержит информацию о сетевых путях для сервера. Ее состав определен в таблице 168.
Таблица 168
Представление в адресном пространстве данных сетевой группы определено в таблице 169.
Таблица 169
Данная структура представляет собой список URL-адресов конечной точки. Ее состав определен в таблице 170.
Таблица 170
Представление данных списка конечных точек в адресном пространстве определено в таблице 171.
Таблица 171
Данный тип данных применяется для предоставления пары "ключ-значение", формально определенной в таблице 172.
Таблица 172
Данная структура описывает конечную точку, тип которой формально определен в таблице 173.
Таблица 173
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/16/gost_22407.html
На правах рекламы:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||