Приложение А (обязательное). Открытая информационная архитектура систем контроля состояния и диагностирования на основе МЭК 62264-5

Приложение А
(обязательное)

Открытая информационная архитектура
систем контроля состояния и диагностирования на основе МЭК 62264-5 [1]

А.1 Форматы сообщений

А.1.1 Типичная структура сообщения

А.1.1.1 Введение

Структуры сообщений, используемые при передаче данных, описаны в [1]. Настоящее приложение представляет собой пример совместимой открытой информационной архитектуры систем контроля состояния и диагностирования. В целях передачи данных [1] определяет две основные области, как показано на рисунке А.1: область идентификации приложения и область данных. Внутри области данных часто содержатся область действия и область объекта.

Рисунок А.1 - Структура сообщения по МЭК 62264-5

А.1.1.2 Область идентификации приложения

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

А.1.1.3 Область данных

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

А.1.1.3.1 Область действия

А.1.1.3.1.1 Обзор

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

Рисунок А.2 - Типовой формат области идентификации приложения

Таблица А.1 - Инициирующие действия

Инициирующее действие	Значение действия
GET	Запрос к получателю на информацию по одному или нескольким объектам. Получатель возвращает сообщение SHOW и CONFIRM
PROCESS	Запрос к получателю на обработку соответствующих объектов. Получатель возвращает сообщение ACKNOWLEDGE и CONFIRM
CHANGE	Запрос к получателю на изменение данных. Получатель возвращает сообщение RESPOND и CONFIRM
CANCEL	Запрос к получателю на удаление данных. Получатель возвращает сообщение CONFIRM
SYNC ADD	Сообщение от собственника информации о добавлении новой информации. Получатель возвращает сообщение CONFIRM
SYNC CHANGE	Сообщение от собственника информации подписчикам об изменениях объектов. Получатель возвращает сообщение CONFIRM
SYNC DELETE	Сообщение от собственника информации об удалении информации. Получатель возвращает сообщение CONFIRM

Таблица А.2 - Ответные действия

Ответное действие	Значение действия
SHOW	Ответ на сообщение GET Получатель возвращает сообщение CONFIRM
ACKNOWLEDGE	Ответ в подтверждение получения запроса PROCESS. Содержит в себе один из следующих элементов: ACCEPTED (информация принята и обработана по соответствующим правилам), REJECTED (информация отклонена и не обработана получателем) или MODIFIED (информация принята, но соответствующим образом модифицирована получателем). Не требует обратного сообщения от получателя
CONFIRM	Подтверждающий ответ на любое сообщение, кроме ACKNOWLEDGE, RESPOND и CONFIRM, в котором указан запрос "OnError" (отправлять подтверждение только при наличии ошибки) или "always" (отправлять подтверждение всегда). Не требует обратного сообщения от получателя. Если сообщение не может быть обработано, то возвращается сообщение об ошибке с описанием ошибки.
RESPOND	Ответ в подтверждение и выполнение действий по запросу CHANGE. Содержит в себе один из следующих элементов: ACCEPTED, REJECTED или MODIFIED. He требует обратного сообщения от получателя

A.1.1.3.1.2 Описание инициирующих действий

А.1.1.3.1.2.1 GET

Действие GET обеспечивает запрос информации об одном или нескольких объектах.

Ответом на сообщение GET является сообщение SHOW. Схема транзакции показана на рисунке А.3.

Рисунок А.3 - Транзакция GET - SHOW

Действие GET извлекает один или несколько объектов и любые вложенные объекты с помощью атрибутов идентификаторов.

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

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

А.1.1.3.1.2.2 PROCESS

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

Примечание - Действие PROCESS часто является эквивалентом команды о добавлении объекта. При этом получатель обычно выполняет дальнейшую обработку информации.

Область действия PROCESS может содержать один из следующих элементов: Never (никогда) или Always (всегда) (см. таблицу А.3). Если дополнительный элемент не указан, то по умолчанию он принимается как Never.

Таблица А.3 - Дополнительные элементы запроса сообщения ACKNOWLEDGE

Имя	Описание
Never	Сообщение ACKNOWLEDGE о подтверждении получения не требуется
Always	Сообщение ACKNOWLEDGE о подтверждении получения отправляется всегда

А.1.1.3.1.2.3 CHANGE

Действие CHANGE используется в сообщении, если отправитель сообщения отправляет запрос на изменение данных. Область объекта содержит новые данные. На рисунке А.4 показана схема транзакции GHANGE - RESPOND.

Рисунок А.4 - Транзакция CHANGE - RESPOND

Область действия CHANGE может содержать один из следующих элементов: Never (никогда) или Always (всегда) (см. таблицу А.4). Если дополнительный элемент не указан, то по умолчанию он принимается как Never.

Таблица А.4 - Дополнительные элементы запроса сообщения RESPOND

Имя	Описание
Never	Сообщение RESPOND не требуется
Always	Сообщение RESPOND отправляется всегда

А.1.1.3.1.2.4 CANCEL

Действие CANCEL используется в сообщении CANCEL, если отправитель сообщения отправляет запрос на отмену данных (см. рисунок А.5).

Рисунок А.5 - Сообщение CANCEL

А.1.1.3.1.2.5 SYNC

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

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

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

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

Сообщение SYNC должно содержать в области действия один из следующих модификаторов: ADD (добавить), CHANGE (изменить) или DELETE (удалить).

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

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

Сообщение SYNC ADD отправляется собственником информации и указывает, что собственник добавил новую информацию (см. рисунок А.6). Сообщение SYNC ADD включает в себя добавленные экземпляры объектов и значения всех атрибутов данных объектов.

Рисунок А.6 - Транзакция SYNC ADD с подтверждением

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

А.1.1.3.1.2.6 SYNC DELETE

Сообщение SYNC DELETE отправляется собственником информации. Оно указывает, что провайдер информации удалил ее (см. рисунок А.7). Сообщение SYNC DELETE включает в себя удаленные экземпляры объекта.

Рисунок А.7 - Транзакция SYNC DELETE без подтверждения

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

А.1.1.3.1.3 Описание ответных действий

А.1.1.3.1.3.1 SHOW

Действие SHOW используется для ответа на сообщение GET.

На рисунке А.8 показана транзакция с сообщением GET и последующими сообщениями SHOW и CONFIRM (если используется опция Confirm Always - см. А.1.1.3.1.2.1).

Рисунок А.8 - Транзакция GET - SHOW с опцией Confirm Always

Примечание - Порядок поступления сообщений CONFIRM и SHOW, а также каких-либо других ответных сообщений не определен.

А.1.1.3.1.3.2 ACKNOWLEDGE

Действие ACKNOWLEDGE используется для подтверждения получения приложением запроса PROCESS. Ответом на сообщение PROCESS является сообщение ACKNOWLEDGE (см. рисунок А.9). Сообщение ACKNOWLEDGE может возвращать исходные или модифицированные данные

Область действия сообщения ACKNOWLEDGE содержит один из следующих элементов: ACCEPTED (принято), REJECTED (отклонено) или MODIFIED (модифицировано) (см. таблицу А.5).

Рисунок А.9 - Транзакция PROCESS - ACKNOWLEDGE

Таблица А.5 - Дополнительные элементы запроса сообщения ACKNOWLEDGE

Имя	Описание
ACCEPTED	Информация принята получателем информации и обработана в соответствии с правилами получателя
Rejected	Информация отклонена получателем информации и не обработана получателем. Область данных сообщения должна содержать описание причины отклонения
Modified	Информация принята получателем информации, но модифицирована для корректности обработки. Модифицированные данные возвращаются сообщением ACKNOWLEDGE. Область данных сообщения должна содержать идентификацию типа модификаций

Пример - На рисунке А.10 показана последовательность сообщений в системе контроля состояния и диагностирования, идущих от планирующей подсистемы к исполнительной подсистеме. Получено исходное сообщение PROCESS с графиком контроля с заданной периодичностью. Возвращено сообщение ACKNOWLEDGE с флагом MODIFIED с графиком, где период между последовательными процедурами контроля увеличен, поскольку исполнительная подсистема определила невозможность реализации графика с предлагаемой периодичностью контроля. По получении предложения о модификации планирующая подсистема принимает решение о сокращении времени контроля за счет исключения одного из датчиков, но сохранения изначально предложенной периодичности контроля и повторно направляет сообщение PROCESS исполнительной подсистеме. Исполнительная подсистема принимает график контроля и возвращает сообщение ACKNOWLEDGE с флагом ACCEPTED.

Рисунок А.10 - Пример действия ACKNOWLEDGE в ответ на запрос PROCESS

А.1.1.3.1.3.3 CONFIRM

Действие CONFIRM используется в сообщении CONFIRM для подтверждения получения и обработки какого-либо сообщения за исключением сообщений CONFIRM, RESPOND или ACKNOWLEDGE. Пример подтверждения в случае обнаружения ошибки показан на рисунке А.11.

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

В сообщении CONFIRM указывается идентификатор исходного сообщения, на которое посылается подтверждение.

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

Если при обработке исходного сообщения получающим приложением возникает ошибка, а отправитель исходного сообщения установил атрибут подтверждения OnError или Always, то получающее приложение должно создать сообщение CONFIRM. Если опция подтверждения не установлена, то по умолчанию будет принято Confirm Never.

Обработка ошибки на уровне приложения осуществляется через элемент подтверждения в области идентификации приложения.

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

Опции запроса подтверждения указаны в таблице А.6

Таблица А.6 - Дополнительные элементы запроса CONFIRMATION

Имя	Описание
Never	Запрос на подтверждение отсутствует
OnError	Подтверждение отправляется только при наличии ошибки
Always	Подтверждение отправляется всегда вне зависимости от результатов локальной обработки

Порядок поступления сообщения CONFIRM или какого-либо другого ответного сообщения в настоящем стандарте не определен.

Описание ошибки, кода или текста, связанных с сообщением CONFIRM, содержится в области объекта сообщения (см. рисунок А.11).

Рисунок А.11 - Сообщение CONFIRM

Специальные коды ошибок или текстовые ошибки в настоящем стандарте не рассматриваются.

А.1.1.3.1.3.4 RESPOND

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

Область действия сообщения RESPOND содержит один из следующих элементов: ACCEPTED (принято), REJECTED (отклонено) или MODIFIED (модифицировано) (см. таблицу А.7).

Таблица А.7 - Дополнительные элементы запроса сообщения RESPOND

Имя	Описание
ACCEPTED	Информация принята получателем информации и изменена в соответствии с правилами получателя
Rejected	Информация отклонена получателем информации и не изменена получателем. Область данных сообщения должна содержать описание причины отклонения
Modified	Информация принята получателем информации, но модифицирована для корректности обработки. Модифицированные данные возвращаются сообщением RESPOND. Область данных сообщения должна содержать идентификацию типа модификаций

А.1.2 Область объекта

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

А.2 Методы транзакций

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