ГОСТ Р ИСО 13374-3-2015 Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 3. Передача данных

ГОСТ Р ИСО 13374-3-2015

Группа Т58

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

Контроль состояния и диагностика машин

ОБРАБОТКА, ПЕРЕДАЧА И ПРЕДСТАВЛЕНИЕ ДАННЫХ

Часть 3

Передача данных

Condition monitoring and diagnostics of machines. Data processing, communication and presentation. Part 3. Communication

ОКС 35.240.99

17.160

Дата введения 2016-12-01

Предисловие

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

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 183 "Вибрация, удар и контроль технического состояния"

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

4 Настоящий стандарт идентичен международному стандарту ИСО 13374-3:2012* "Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 3. Передача данных" (ISO 13374-3:2012 "Condition monitoring and diagnostics of machines - Data processing, communication and presentation - Part 3: Communication", IDT).

________________

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

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

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

6 ПЕРЕИЗДАНИЕ. Ноябрь 2018 г.

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

Введение

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

Общее представление об обработке, передаче и представлении данных в целях контроля состояния и диагностирования машин дано ИСО 13374-1. В ИСО 13374-2 более подробно рассмотрены методология и требования обработки данных применительно к современным автоматизированным системам. В настоящем стандарте рассматриваются требования к архитектуре передачи данных в открытых системах контроля состояния и диагностирования.

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

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

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

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

_______________

* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

ISO 8601, Data elements and interchange formats - Information interchange - Representation of dates and times (Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени)

ISO 13372 Condition monitoring and diagnostics of machines - Vocabulary (Контроль состояния и диагностика машин. Словарь)

IS013374-1:2003 Condition monitoring and diagnostics of machines - Data processing, communication and presentation - Part 1: General guidelines (Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 1. Общее руководство)

IS013374-2:2007 Condition monitoring and diagnostics of machines - Data processing, communication and presentation - Part 2: Data processing (Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 2. Обработка данных)

ISO/IEC 19501 Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2 [Информационные технологии. Взаимосвязь открытых систем. Унифицированный язык моделирования (UML), версия 1.4.2]

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

В настоящем стандарте применены термины по ИСО 13372.

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

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

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

Содержание сообщений, используемых в процессе обмена данными между приложениями открытой информационной архитектуры системы контроля состояния и диагностирования, должно соответствовать определениям, установленным на уровне 5 информационной архитектуры, и данным ссылок, установленным на уровне 4. Применение сообщений зависит от требований приложения (см. приложение А).

4.2 Требования доступа к библиотечной информации

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

Рисунок 1 - Уровни информационной архитектуры системы контроля состояния и диагностирования (по ИСО 13374-2)

4.3 Требования к инициированию передачи данных

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

4.4 Требования к содержанию сообщения

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

5 Требования обмена информацией в открытой архитектуре обработки данных системы контроля состояния и диагностирования

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

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

Рисунок 2 - Блок-схема потока информации и этапов обработки данных

Эта архитектура определена в виде блоков, реализующих разные функции обработки данных. Каждый блок должен быть соответствующим образом конфигурирован. Данные, полученные из блока сбора данных (DA) в цифровом формате, после соответствующих преобразований приобретают вид соответствующих рекомендаций на выходе блока составления рекомендаций (AG). По мере продвижения от блока DA к блоку AG данные поступают на очередной блок преобразования вместе с дополнительной информацией от внешних систем, а с выхода этого блока также могут быть посланы внешним системам. При этом данные, вовлекаемые в информационный поток, нуждаются в соответствующем стандартном отображении и простом графическом представлении. Многие приложения в целях сохранения результатов преобразования информации каждым блоком системы требуют, чтобы соответствующие данные были архивированы. Блоки DA, DM и SD отвечают за оценку качества данных, которое может быть высоким, низким или неопределенным.

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

5.2 Технологии и представления унифицированного языка моделирования (UML)

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

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

После этого данные подвергаются обработке блоками системы для представления в формате, удобном для оценки и прогнозирования технического состояния, а также для выработки рекомендаций. Указанные процедуры могут быть реализованы с помощью разных технологических решений. Технологии и программные средства, используемые в блоках обработки НА, РА и AG (блоки анализа), часто отличаются от используемых в блоках обработки DA, DM и SD (блоках данных).

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

Для поддержки передачи данных в открытой архитектуре обработки данных системы контроля состояния и диагностирования должна быть определена модель унифицированного языка моделирования (UML), совместимая с ИСО/МЭК 19501, поддерживающая основные информационные классы и требуемые интерфейсы. Как показано на рисунке 3, UML должен быть реализован в конкретных технологиях, таких как веб-сервисы на основе языка XML или встроенные системы передачи двоичных данных.

Рисунок 3 - Применение UML к конкретной технологии

5.2.2 Стандартное содержание данных

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

5.2.3 Соотношение с информационной системой менеджмента

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

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

5.3 Типы интерфейса и общие интеракции

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

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

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

5.3.2 Интерфейс провайдера

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

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

5.3.2.2 Синхронный интерфейс

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

Рисунок 4 - Пример применения синхронного интерфейса "запрос-ответ"

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

Рисунок 5 - Пример применения синхронного интерфейса "запрос-ответ" с модификацией процесса

5.3.2.3 Асинхронный интерфейс

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

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

5.3.2.3.2 Асинхронный интерфейс, тип 1

Асинхронный интерфейс типа 1 определяет способ и объем передачи информации потребителю по мере ее поступления. Интерфейс для получения информации при данном способе передачи называют приемником. Потребитель получает информацию от провайдера через приемник. Провайдер хранит информацию о том, как отправлять данные приемнику потребителя. Такой тип интерфейса работает по принципу рассылки публикаций подписчикам.

Асинхронный интерфейс типа 1 со стороны провайдера реализует метод "соединение с уведомлением" (notify connection), позволяющий потребителю определить, как получить информацию через приемник. Он позволяет также выполнить удаление соединения (remove Connection), в результате чего потребитель удаляется из списка провайдера. Интерфейс пользователя позволяет получать сообщения от провайдера об установлении и удалении соединения. Пример реализации данного интерфейса показан на рисунке 6.

Рисунок 6 - Пример применения асинхронного интерфейса "запрос-ответ"

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

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

5.3.2.3.3 Асинхронный интерфейс, тип 2

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

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

5.3.3 Сервис потребителя

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

Рисунок 7 - Пример реализации сервиса потребителя

5.4 Требования к интерфейсу по ИСО 13374-2

5.4.1 Соединения

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

5.4.2 События данных

Каждый блок в архитектуре обработки данных по ИСО 13374-2 предусматривает вывод данных. В каждом типе интерфейса должен быть реализован метод передачи событий данных. Синхронный и асинхронный интерфейсы типа 1 должны обеспечивать запрос выходных данных. Приемник асинхронного интерфейса типа 1 должен обеспечивать получение событий данных. Асинхронный интерфейс типа 1 для провайдера должен реализовать метод передачи событий данных.

5.4.3 Конфигурация

Каждый блок в архитектуре обработки данных по ИСО 13374-2 предусматривает ввод и вывод информации о конфигурации. Синхронный и асинхронный интерфейсы типа 1 должны реализовать метод ввода и вывода информации о конфигурации. Провайдер должен определить объем данных об имеющейся конфигурации, который необходимо поддерживать в соответствии с потребностями приложения. Если данные в требуемом объеме не поддерживаются, то об этом должно быть сообщено потребителю.

5.4.4 Управление

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

5.4.5 Описания

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

5.4.6 Специализированные приложения

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

5.4.7 Информация об отправителе и получателе

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

5.4.8 Сообщения об ошибках

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

5.4.9 Обработка данных в блоках

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

Таблица 1 - Типы информации

5.5 Поддержка спецификации данных провайдера

Провайдер информации выбирает блоки обработки данных, например, DA, DM, SD, НА, РА или AG, которые он поддерживает, а также поддерживаемые им методы обработки данных для каждого такого блока. Провайдер также выбирает обеспечивающие поддержку дополнительные интерфейсы и сервисы в зависимости от особенностей конкретного приложения. На рисунке 8 суммированы области, которые должны быть определены. Области поддержки спецификации данных провайдера показаны на рисунке 8.

Рисунок 8 - Области поддержки спецификации данных провайдера

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

Открытая информационная архитектура систем контроля состояния и диагностирования на основе МЭК 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 - Инициирующие действия

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

А.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

А.1.1.3.1.2.3 CHANGE

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

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

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

Таблица А.4 - Дополнительные элементы запроса сообщения 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

Пример - На рисунке А.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

Порядок поступления сообщения 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

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

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

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

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

Приложение ДА
(справочное)

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1

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

[1] IEC 62264-5 Enterprise-control system integration - Part 5: Business to manufacturing transactions

Электронный текст документа

и сверен по:

, 2018