ГОСТ Р ИСО 13374-3-2015. Национальный стандарт Российской Федерации. Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 3. Передача данных
Актуально на 03.11.2026.
Как цитировать: "ГОСТ Р ИСО 13374-3-2015. Национальный стандарт Российской Федерации. Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 3. Передача данных". ГОСТ Р ИСО 13374-3-2015. https://bukva.ai/docs/standart-gost-r-iso-13374-3-2015
(утв. и введен в действие Приказом Росстандарта от 20.10.2015 № 1580-ст)
Примечание
Документ введен в действие с 01.12.2016.
Утвержден и введен в действие
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 20 октября 2015 г. № 1580-ст
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
КОНТРОЛЬ СОСТОЯНИЯ И ДИАГНОСТИКА МАШИН
ОБРАБОТКА, ПЕРЕДАЧА И ПРЕДСТАВЛЕНИЕ ДАННЫХ
Condition monitoring and diagnostics of machines.
Data processing, communication and presentation.
Part 3. Communication
17.160
1 декабря 2016 года
1 ПОДГОТОВЛЕН Открытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (АО «НИЦ КД») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 183 «Вибрация, удар и контроль технического состояния»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 20 октября 2015 г. № 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).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Существующие программные средства работы с данными в процедурах контроля состояния и диагностирования машин зачастую не обеспечивают простоту и удобство обмена данными, а также могут требовать больших затрат по их интегрированию в системы мониторинга. Отсутствие многоцелевой системы обмена данными затрудняет интегрирование подсистем мониторинга в единый комплекс и препятствует выработке целостного представления о работе системы мониторинга. Настоящий стандарт входит в серию стандартов, устанавливающих общие требования к спецификации открытого программного обеспечения, применяемого в целях контроля состояния и диагностирования, в части обработки, передачи и представления данных безотносительно к используемым операционным средам и аппаратным средствам.
Общее представление об обработке, передаче и представлении данных в целях контроля состояния и диагностирования машин дано в ИСО 13374-1. В ИСО 13374-2 более подробно рассмотрены методология и требования обработки данных применительно к современным автоматизированным системам. В настоящем стандарте рассматриваются требования к архитектуре передачи данных в открытых системах контроля состояния и диагностирования.
Настоящий стандарт устанавливает требования к передаче данных в открытой эталонной информационной архитектуре систем контроля состояния и диагностирования и эталонной архитектуре систем обработки данных. Настоящий стандарт предназначен для разработчиков систем программного обеспечения процедур обмена данными между различными приложениями системы контроля состояния и диагностирования предприятия и обеспечивает операционную совместимость этих систем.
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ISO 8601, Data elements and interchange formats — Information interchange — Representation of dates and times (Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени)
ISO 13372 Condition monitoring and diagnostics of machines — Vocabulary (Контроль состояния и диагностика машин. Словарь)
ISO 13374-1:2003 Condition monitoring and diagnostics of machines — Data processing, communication and presentation — Part 1: General guidelines (Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 1. Общее руководство)
ISO 13374-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]
В настоящем стандарте применены термины по ИСО 13372.
4 Требования к передаче данных в открытой информационной архитектуре системы контроля состояния и диагностирования
4.1 Общие положения
Информационная архитектура описывает все объекты данных и их свойства (атрибуты), типы свойств, соотношения между объектами данных, ссылочные данные и источники данных для заданной системы или приложения. Открытая спецификация информационной архитектуры, системы контроля состояния и диагностирования машин должна описывать каждый из пяти уровней, показанных на рисунке 1.
Содержание сообщений, используемых в процессе обмена данными между приложениями открытой информационной архитектуры системы контроля состояния и диагностирования, должно соответствовать определениям, установленным на уровне 5 информационной архитектуры, и данным ссылок, установленным на уровне 4. Применение сообщений зависит от требований приложения (см. приложение A).
4.2 Требования доступа к библиотечной информации
Открытая информационная архитектура системы контроля состояния и диагностирования должна устанавливать метод, посредством которого получатели сообщений могут иметь доступ к библиотечной информации, определенной на уровне 4. В ней также должен быть задан способ рассылки владельцем библиотеки уведомлений подписчикам об имевших место обновлениях.
контроля состояния и диагностирования (по ИСО 13374-2)
4.3 Требования к инициированию передачи данных
Открытая информационная архитектура системы контроля состояния и диагностирования должна определить требования инициирования приложения провайдера для каждого метода передачи данных, входящих в архитектуру. Представления даты и времени в информации об инициировании должны ссылаться на григорианский календарь в соответствии с ИСО 8601. Инициирование передачи данных должно также ссылаться на установленные уровнем 5 определения информационного документа, которым подчиняется содержание передаваемых сообщений.
4.4 Требования к содержанию сообщения
Открытая спецификация информационной архитектуры систем контроля состояния и диагностирования должна определять требования к содержанию сообщений приложений провайдера для каждого метода передачи, предусматриваемого архитектурой. Определение содержания сообщения должно ссылаться на соответствующее определение информационного документа с учетом возможной интерпретации формата информационного документа, включая его сжатие и используемое кодирование.
5 Требования обмена информацией в открытой архитектуре обработки данных системы контроля состояния и диагностирования
5.1 Общие положения
Архитектура обработки данных описывает все интеракции и транзакции между внутренними модулями программной системы, которые одновременно являются внешними модулями для конечного пользователя и других программных средств. Как установлено в ИСО 13374-2, открытая архитектура обработки данных системы контроля состояния и диагностирования должна иметь вид, показанный на рисунке 2.
и этапов обработки данных
Эта архитектура определена в виде блоков, реализующих разные функции обработки данных. Каждый блок должен быть соответствующим образом конфигурирован. Данные, полученные из блока сбора данных (DA) в цифровом формате, после соответствующих преобразований приобретают вид соответствующих рекомендаций на выходе блока составления рекомендаций (AG). По мере продвижения от блока DA к блоку AG данные поступают на очередной блок преобразования вместе с дополнительной информацией от внешних систем, а с выхода этого блока также могут быть посланы внешним системам. При этом данные, вовлекаемые в информационный поток, нуждаются в соответствующем стандартном отображении и простом графическом представлении. Многие приложения в целях сохранения результатов преобразования информации каждым блоком системы требуют, чтобы соответствующие данные были архивированы. Блоки DA, DM и SD отвечают за оценку качества данных, которое может быть высоким, низким или неопределенным.
Настоящий стандарт определяет требования к передаче данных для любой открытой архитектуры обработки данных системы контроля состояния и диагностирования. Это позволяет интегрировать в единую функциональную систему блоки обработки данных, получаемые от разных поставщиков.
5.2 Технологии и представления унифицированного языка моделирования (UML)
5.2.1 Общие положения
Обычно возможность приема данных от датчиков с последующим их анализом на более высоких уровнях системы контроля состояния и диагностирования может быть реализована в разных программных средах разными аппаратными средствами. Часто отправной точкой работы системы является сбор данных в реальном масштабе времени со стационарно установленных преобразователей.
После этого данные подвергаются обработке блоками системы для представления в формате, удобном для оценки и прогнозирования технического состояния, а также для выработки рекомендаций. Указанные процедуры могут быть реализованы с помощью разных технологических решений. Технологии и программные средства, используемые в блоках обработки HA, PA и 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.
«запрос — ответ»
В дополнение к обработке запроса данных любым блоком или внешним приложением система провайдера должна поддерживать возможность запроса модификации алгоритма обработки. Примерами модификаций являются установка конфигурации блока и контроль пороговых значений. Провайдер должен выполнить модификацию (если это возможно) и возвратить статус выполнения операции (успешное выполнение или ошибка с указанием кода) в соответствии с его возможностью обработать модификацию. Пример реализации показан на рисунке 5.
«запрос — ответ» с модификацией процесса
5.3.2.3 Асинхронный интерфейс
5.3.2.3.1 Общие положения
Асинхронный интерфейс реализует механизм «вызов без ожидания». Асинхронный интерфейс позволяет провайдеру отправлять незапрашиваемую информацию потребителям, после того как от потребителя будет получено уведомление о том, каким образом информация должна быть доставлена. Устанавливаются способы соединения или каналы передачи данных, после чего требуемая информация передается через них в непрерывном режиме по мере ее появления.
5.3.2.3.2 Асинхронный интерфейс, тип 1
Асинхронный интерфейс типа 1 определяет способ и объем передачи информации потребителю по мере ее поступления. Интерфейс для получения информации при данном способе передачи называют приемником. Потребитель получает информацию от провайдера через приемник. Провайдер хранит информацию о том, как отправлять данные приемнику потребителя. Такой тип интерфейса работает по принципу рассылки публикаций подписчикам.
Асинхронный интерфейс типа 1 со стороны провайдера реализует метод «соединение с уведомлением» (notify connection), позволяющий потребителю определить, как получить информацию через приемник. Он позволяет также выполнить удаление соединения (remove Connection), в результате чего потребитель удаляется из списка провайдера. Интерфейс пользователя позволяет получать сообщения от провайдера об установлении и удалении соединения. Пример реализации данного интерфейса показан на рисунке 6.
«запрос — ответ»
Потребитель должен иметь возможность указать на требуемый объем информации, который должен поступить на приемник. Потребитель должен реализовать интерфейс приемника, обеспечивающий получение всех типов данных, на которые он подписался и которые провайдер способен передать. Приемник должен также принимать от провайдера незапрошенную информацию.
Интерфейс данного вида позволяет реализовать разные режимы передачи данных. Среди них должны быть реализованы режимы: «передача всех данных», «передача данных выше порогового уровня», «передача данных только по запросу». Пользователь сообщает провайдеру, какой режим является предпочтительным. Возможности провайдера должны позволять ему передавать информацию более той, что запрашивает потребитель, но не менее той, что он запрашивает.
5.3.2.3.3 Асинхронный интерфейс, тип 2
Встроенные системы контроля часто предъявляют особые требования к передаче данных. Таким требованием может быть установление неблокирующего одностороннего соединения. Такие системы могут иметь ограничения на конфигурацию, не позволяющие ей осуществлять передачу данных множественным пользователям в асинхронном режиме.
Для систем с указанными типами ограничений соединение с потребителями через канал приемника должно быть установлено через процесс инициализации. Потребители должны получать от провайдера данные асинхронным способом по мере их появления. Единственное требование для систем данного типа — возможность скорейшей отправки данных в стандартном формате, определенном потребителем. От пользователя требуется реализовать интерфейс приемника, обеспечивающий получение всех типов информации, которую может отправить провайдер.
5.3.3 Сервис потребителя
Сервисы потребителя, такие как хранение/архивация данных, система планово-предупредительного обслуживания или система обучения команд операций, могут быть настроены на использование результатов системы контроля состояния и диагностирования. Сервис потребителя должен обеспечить интерфейс, позволяющий провайдеру данных отправлять потребителю незапрашиваемую информацию. Сервис потребителя отвечает индикацией, показывающей, была ли информация успешно получена и обработана или имели место какие-либо ошибки. Ошибки могут относиться как к процессу передачи, так и к процедурам обработки данных. Пример сервиса потребителя показан на рисунке 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 приведены основные методы обработки данных, которые должны использоваться каждым блоком в открытой архитектуре обработки данных системы контроля состояния и диагностирования.
5.5 Поддержка спецификации данных провайдера
Провайдер информации выбирает блоки обработки данных, например DA, DM, SD, HA, PA или AG, которые он поддерживает, а также поддерживаемые им методы обработки данных для каждого такого блока. Провайдер также выбирает обеспечивающие поддержку дополнительные интерфейсы и сервисы в зависимости от особенностей конкретного приложения. На рисунке 8 суммированы области, которые должны быть определены. Области поддержки спецификации данных провайдера показаны на рисунке 8.
Рисунок 8 — Области поддержки спецификации данных провайдера
ОТКРЫТАЯ ИНФОРМАЦИОННАЯ АРХИТЕКТУРА СИСТЕМ КОНТРОЛЯ
СОСТОЯНИЯ И ДИАГНОСТИРОВАНИЯ НА ОСНОВЕ МЭК 62264-5 [1]
A.1.1 Типичная структура сообщения
Структуры сообщений, используемые при передаче данных, описаны в [1]. Настоящее приложение представляет собой пример совместимой открытой информационной архитектуры систем контроля состояния и диагностирования. В целях передачи данных [1] определяет две основные области, как показано на рисунке A.1: область идентификации приложения и область данных. Внутри области данных часто содержатся область действия и область объекта.
Рисунок A.1 — Структура сообщения по МЭК 62264-5
A.1.1.2 Область идентификации приложения
Область идентификации приложения должна содержать информацию, которую получающее приложение использует для обработки сообщений. Область идентификации приложения используется для установления уровня связи приложения, например указания требуемого подтверждения обработки сообщения. Данная информация обычно включает в себя электронный адрес отправителя, указание требования подтверждения, дату и время создания сообщения. Область идентификации приложения может также включать в себя другую информацию, необходимую для идентификации и аутентификации сообщения. На рисунке A.2 показан типовой формат для области идентификации приложения. Дата и время должны содержать информацию о временном поясе для однозначной идентификации времени. Например, можно использовать координатное универсальное время или расширенный календарный формат по ИСО 8601.
Область данных в сообщении обычно содержит область действия и область объекта. Сочетание области действия и области объекта обеспечивает уникальность сообщения и однозначность его понимания.
Область действия содержит само действие и ассоциированные элементы, которые представляют собой либо действия, выполняемые получающим приложением, либо ответ на запрос отправляющего приложения. Действия применяют для эффективного обмена данными между отправителем и получателем сообщения. Общепринятые инициирующие действия указаны в таблице A.1, а ответные действия — в таблице A.2.
Рисунок A.2 — Типовой формат области идентификации приложения
A.1.1.3.1.2 Описание инициирующих действий
Действие GET обеспечивает запрос информации об одном или нескольких объектах.
Ответом на сообщение GET является сообщение SHOW. Схема транзакции показана на рисунке A.3.
Рисунок A.3 — Транзакция GET — SHOW
Действие GET извлекает один или несколько объектов и любые вложенные объекты с помощью атрибутов идентификаторов.
Внутри сообщения GET идентификатор запрошенного объекта передается провайдеру информации. Если одного идентификатора недостаточно (например, когда требуется еще и свойство объекта), то провайдеру данных передается идентификатор охватывающего объекта и идентификатор (значение) охватываемого объекта (свойства). Указанные идентификаторы приведены в соответствующем разделе для каждого типа объекта.
Если рассматриваемый идентификатор использован в определении группового символа, то действие GET возвращает перечень объектов, согласующийся со спецификацией группового символа.
Действие PROCESS используется для запроса об обработке ассоциированного объекта приложением получателя. Сообщение PROCESS обращается к тому, что может обработать объект. В типовом сценарии обмена сообщение PROCESS рассматривается как эквивалент формальной команды.
Примечание - Действие PROCESS часто является эквивалентом команды о добавлении объекта. При этом получатель обычно выполняет дальнейшую обработку информации.
Область действия PROCESS может содержать один из следующих элементов: Never (никогда) или Always (всегда) (см. таблицу A.3). Если дополнительный элемент не указан, то по умолчанию он принимается как Never.
Дополнительные элементы запроса сообщения ACKNOWLEDGE
| Имя | Описание |
|---|---|
| Never | Сообщение ACKNOWLEDGE о подтверждении получения не требуется |
| Always | Сообщение ACKNOWLEDGE о подтверждении получения отправляется всегда |
Действие CHANGE используется в сообщении, если отправитель сообщения отправляет запрос на изменение данных. Область объекта содержит новые данные. На рисунке A.4 показана схема транзакции CHANGE — RESPOND.
Область действия CHANGE может содержать один из следующих элементов: Never (никогда) или Always (всегда) (см. таблицу A.4). Если дополнительный элемент не указан, то по умолчанию он принимается как Never.
| Имя | Описание |
|---|---|
| Never | Сообщение RESPOND не требуется |
| Always | Сообщение RESPOND отправляется всегда |
Действие CANCEL используется в сообщении CANCEL, если отправитель сообщения отправляет запрос на отмену данных (см. рисунок A.5).
Действие SYNC используется, когда собственник данных публикует информацию или изменяет информацию для подписчика.
Примечание 1 — Действие SYNC подразумевает синхронизацию и согласование данных и не имеет отношения к синхронизации процесса обмена данными.
Сообщение SYNC направляет собственник информации. Для отдельных элементов информации должно существовать единственное приложение, отправляющее сообщение SYNC в отношении этих элементов.
Примечание 2 — Другие приложения могут направлять сообщения SYNC в отношении тех данных, собственниками которых они являются.
Сообщение SYNC должно содержать в области действия один из следующих модификаторов: ADD (добавить), CHANGE (изменить) или DELETE (удалить).
Время публикации информации и область применения опубликованной информации в сообщении не указываются. Они определяются в рамках отдельного соглашения между тем, кто публикует сообщения, и подписчиком.
Пример - Данное действие обычно используется, когда необходимы большие изменения, например когда устройство публикует обновления для многих систем или когда механизмы публикации и подписки используют в качестве архитектуры интеграции компании.
Сообщение SYNC ADD отправляется собственником информации и указывает, что собственник добавил новую информацию (см. рисунок A.6). Сообщение SYNC ADD включает в себя добавленные экземпляры объектов и значения всех атрибутов данных объектов.
Сообщение SYNC CHANGE отправляется собственником информации и используется для распространения информации об измененных объектах среди подписчиков. Сообщение SYNC CHANGE включает в себя измененные экземпляры объектов и измененные значения атрибутов данных объектов.
Сообщение SYNC DELETE отправляется собственником информации. Оно указывает, что провайдер информации удалил ее (см. рисунок A.7). Сообщение SYNC DELETE включает в себя удаленные экземпляры объекта.
Рисунок A.7 — Транзакция SYNC DELETE без подтверждения
Примечание - Сообщение SYNC DELETE извещает только о том, что провайдер удалил информацию из публикации. Эта информация все еще может сохраняться в заархивированном виде или в соответствии с принятыми правилами ведения политики провайдера, но она недоступна для дальнейшего опубликования. Ответственность за корректность действий, связанных с удаленной информацией (например, ее архивирование или продолжение использования), несет пользователь информации.
A.1.1.3.1.3 Описание ответных действий
Действие SHOW используется для ответа на сообщение GET.
На рисунке A.8 показана транзакция с сообщением GET и последующими сообщениями SHOW и CONFIRM (если используется опция Confirm Always — см. A.1.1.3.1.2.1).
Рисунок A.8 — Транзакция GET — SHOW с опцией Confirm Always
Примечание - Порядок поступления сообщений CONFIRM и SHOW, а также других ответных сообщений не определен.
Действие ACKNOWLEDGE используется для подтверждения получения приложением запроса PROCESS. Ответом на сообщение PROCESS является сообщение ACKNOWLEDGE (см. рисунок A.9). Сообщение ACKNOWLEDGE может возвращать исходные или модифицированные данные.
Область действия сообщения ACKNOWLEDGE содержит один из следующих элементов: ACCEPTED (принято), REJECTED (отклонено) или MODIFIED (модифицировано) (см. таблицу A.5).
Рисунок A.9 — Транзакция PROCESS — ACKNOWLEDGE
Пример - На рисунке A.10 показана последовательность сообщений в системе контроля состояния и диагностирования, идущих от планирующей подсистемы к исполнительной подсистеме. Получено исходное сообщение PROCESS с графиком контроля с заданной периодичностью. Возвращено сообщение ACKNOWLEDGE с флагом MODIFIED с графиком, где период между последовательными процедурами контроля увеличен, поскольку исполнительная подсистема определила невозможность реализации графика с предлагаемой периодичностью контроля. По получении предложения о модификации планирующая подсистема принимает решение о сокращении времени контроля за счет исключения одного из датчиков, но сохранения изначально предложенной периодичности контроля, и повторно направляет сообщение PROCESS исполнительной подсистеме. Исполнительная подсистема принимает график контроля и возвращает сообщение ACKNOWLEDGE с флагом ACCEPTED.
в ответ на запрос PROCESS
Действие CONFIRM используется в сообщении CONFIRM для подтверждения получения и обработки какого-либо сообщения, за исключением сообщений CONFIRM, RESPOND или ACKNOWLEDGE. Пример подтверждения в случае обнаружения ошибки показан на рисунке A.11.
Подтверждение — это опция, управляемая отправляющим приложением. Получающее приложение запрашивается о возврате подтверждающего сообщения на сообщение, изначально посланное отправляющим приложением.
В сообщении CONFIRM указывается идентификатор исходного сообщения, на которое посылается подтверждение.
В сообщении CONFIRM указывается на успешную обработку исходного сообщения или возвращается сообщение об ошибке, если исходное сообщение обработано быть не может.
Если при обработке исходного сообщения получающим приложением возникает ошибка, а отправитель исходного сообщения установил атрибут подтверждения OnError или Always, то получающее приложение должно создать сообщение CONFIRM. Если опция подтверждения не установлена, то по умолчанию будет принято Confirm Never.
Обработка ошибки на уровне приложения осуществляется через элемент подтверждения в области идентификации приложения.
Обработка ошибок приложения осуществляется в дополнение к обработке ошибок уровня связи, обеспечиваемой в рамках конкретной инфраструктуры и сервисных служб сети с помощью связующего программного обеспечения.
Опции запроса подтверждения указаны в таблице A.6.
Порядок поступления сообщения CONFIRM или другого ответного сообщения в настоящем стандарте не определен.
Описание ошибки, кода или текста, связанных с сообщением CONFIRM, содержится в области объекта сообщения (см. рисунок A.11).
Рисунок A.11 — Сообщение CONFIRM
Специальные коды ошибок или текстовые ошибки в настоящем стандарте не рассматриваются.
Действие RESPOND используется в сообщении RESPOND для обозначения получения с обработки сообщения CHANGE. Сообщение RESPOND используется при ответе на сообщение CHANGE. Сообщение RESPOND может возвращать исходные или модифицированные данные.
Область действия сообщения RESPOND содержит один из следующих элементов: ACCEPTED (принято), REJECTED (отклонено) или MODIFIED (модифицировано) (см. таблицу A.7).
Дополнительные элементы запроса сообщения RESPOND
Область объекта содержит объекты и ассоциированные элементы, представляющие один или несколько объектов источников данных, определенных таким образом, чтобы исключить неоднозначность понимания передаваемых сообщений.
В [1] рассматриваются модели транзакции, которые могут быть использованы в целях интеграции приложений предприятия.
(справочное)
| Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
| ISO 8601 | - | <*> |
| ISO 13372 | IDT | ГОСТ Р ИСО 13372-2013 «Контроль состояния и диагностика машин. Термины и определения» |
| ISO 13374-1:2003 | IDT | ГОСТ Р ИСО 13374-1-2011 «Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 1. Общее руководство» |
| ISO 13374-2:2007 | IDT | ГОСТ Р ИСО 13374-2-2011 «Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 2. Обработка данных» |
| ISO/IEC 19501 | - | <*> |
| <*> Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта. Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT — идентичные стандарты. | ||
| [1] | IEC 62264-5 | Enterprise-control system integration — Part 5: Business to manufacturing transactions |
|---|
| УДК 534.322.3.08:006.354 | ОКС 35.240.99 17.160 | Т58 |
| Ключевые слова: контроль состояния, диагностика, передача данных, информационная схема, открытая архитектура, спецификации | ||