Товары в корзине: 0 шт Оформить заказ
Стр. 1
 

24 страницы

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

 Скачать PDF

Идентичен ISO 13374-3:2012

Оглавление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов национальным стандартам Российской Федерации

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

 

24 страницы

Дата введения01.12.2016
Добавлен в базу01.02.2017
Актуализация01.01.2019

Этот ГОСТ находится в:

Организации:

20.10.2015УтвержденФедеральное агентство по техническому регулированию и метрологии1580-ст
ИзданСтандартинформ2016 г.
РазработанАО НИЦ КД

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

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24

ГОСТ Р исо

13374-3—

2015

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

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

Часть 3

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

(ISO 13374-3:2012, ЮТ)

Издание официальное

Москва

Стандартинформ

2016

Предисловие

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

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

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

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

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

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

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

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

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

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

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

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

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

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

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

DataGenerator: DataGenerator

DataConsumer: ConsumerDataService

notifylnformationQ

preparelnformation

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

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

5.4.1    Соединения

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

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

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

7

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 — Типы информации

Информация

Обязательность

включения

Значения

Событие данных (DataEvent)

Да

Обеспечивает передачу данных с выходов каждого блока системы контроля состояния и диагностирования. Например, модуль на уровне DA передает информацию о датчике в форме DataEvent блока DA. Модуль на блочном уровне DM передает обработанную информацию в форме DataEvent блока DM

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

Нет

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

Управление

Нет

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


Окончание таблицы 1

Информация

Обязательность

включения

Значения

Определение

Нет

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

Приложение

Нет

Определяет информацию, специфичную для данного приложения

Отправитель

Да

Указывает на источник информации. Должен быть указан способ указания на отправителя информации

Получатель

Нет

Указывает на место направления информации. Используется некоторыми (но не всеми) видами коммуникации. Применение зависит от типа приложения


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

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


Блоки обработки

•    Сбор данных

•    Преобразование данных

•    Обнаружение неисправностей

•    Определение состояния

•    Составление прогноза

•    Составление рекомендаций


Обработка в блоках

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

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

•    Управление

•    Определение

•    Приложение

•    Отправитель/получатель


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

•    Сервисы собранных данных

о Хранение о Поиск и выборка

•    Сервисы внешних систем

о Обслуживание о Консультативное управление

•    Управление конфигурациями

•    Служба сервисов


Типы технологий

•    Языки программирования

•    Протоколы обмена данными

•    Форматы данных_


Типы интерфейса

•    Сервисы провайдера

о Асинхронные о Тип 1 о Тип 2 о Синхронные

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


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


9


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

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

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

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

А. 1.1.1 Введение

Документ данных

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

Инициирующие действия: GET (получить), CHANGE (изменить), CANCEL (отменить), PROCESS (обработать), SYNC (синхронизировать)

Ответные действия: SHOW (показать), CONFIRM (подтвердить правильность), ACKNOWLEDGE (подтвердить прием), RESPOND (ответить)

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

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

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

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

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

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

А.1.1.3.1.1 Обзор

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

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

Идентифицирует отправителя сообщения Идентифицирует обратный адрес отправителя Определяет вариант подтверждения Другая информация об отправителе

Определяет дату и время создания сообщения Определяет форму сообщения Определяет другую информацию о сообщении

Рисунок А.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 (информация принята, но соответствующим образом модифицирована получателем). Не требует обратного сообщения от получателя

11

Окончание таблицы А. 2

Ответное действие

Значение действия

CONFIRM

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

RESPOND

Ответ в подтверждение и выполнение действий по запросу CHANGE. Содержит в себе один из следующих элементов: ACCEPTED, REJECTED или MODIFIED. Не требует обратного сообщения от получателя

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

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

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

Провайдер

информации

Пользователь

информации

GET

Локальная обработка

SHOW

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

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

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

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

А.1.1.3.1.2.2 PROCESS

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

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

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

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

Имя

Описание

Never

Сообщение ACKNOWLEDGE о подтверждении получения не требуется

Always

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

А.1.1.3.1.2.3 CHANGE

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

12

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

Рисунок А.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 (удалить).

13

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

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

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

Провайдер

информации

Пользователь

информации

SYNC ADD с CONFIRM

CONFIRM

Локальная обработка

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

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

А.1.1.3.1.2.6 SYNC DELETE

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

Провайдер

информации

Пользователь

информации

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

14

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

Провайдер

информации

Пользователь

информации

GET (Confirm Always)

При локальной обработке ошибок не обнаружено

CONFIRM

SHOW

Рисунок А.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).

Получатель

информации

Отправитель

информации

PROCESS

Локальная обработка

ACKNOWLEDGE

Рисунок А.9 — Транзакция PROCESS —ACKNOWLEDGE Таблица А.5 — Дополнительные элементы запроса сообщения ACKNOWLEDGE

Имя

Описание

ACCEPTED

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

Rejected

Информация отклонена получателем информации и не обработана получателем. Область данных сообщения должна содержать описание причины отклонения

Modified

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

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

15

сообщение 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

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

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

Содержание

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

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

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

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

системы контроля состояния и диагностирования.........................................2

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

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

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

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

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

обработки данных системы контроля состояния и диагностирования..........................3

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

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

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

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

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

Приложение А (обязательное) Открытая информационная архитектура систем

контроля состояния и диагностирования на основе МЭК 62264-5 [1]...............10

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам Российской Федерации...........................18

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


Порядок поступления сообщения 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] рассматриваются модели транзакции, которые могут быть использованы в целях интеграции приложений предприятия.


17


Введение

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

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

IV

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

Контроль состояния и диагностика машин ОБРАБОТКА, ПЕРЕДАЧА И ПРЕДСТАВЛЕНИЕ ДАННЫХ Часть 3 Передача данных

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

Part 3. Communication

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

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

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

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

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

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

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

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

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

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

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

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

Издание официальное

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

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

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

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

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

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

Определения информационного документа

Уровень 5

Библиотечная информация

Уровень 4

Модель реализации данных

Уровень 3

Концептуальная информационная модель

Уровень 2

Семантические определения

Уровень 1

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

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

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

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

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

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

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

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

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

Датчик / Преобразователь / Ручной ввод

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

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

3

сбора данных (DA) в цифровом формате, после соответствующих преобразований приобретают вид соответствующих рекомендаций на выходе блока составления рекомендаций (AG). По мере продвижения от блока DAk блоку 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 с помощью универсального преобразователя.

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

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

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

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

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

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

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

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

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

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

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

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

DataUser: DataUser

SvnchProvider: EntrvPointSvnchronous

requestlnformationO


preparelnformation


return information


Ч


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

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

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

5

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

DataUser: DataUser

SvnchProvider: EntrvPointSvnchronous

Т

notifylnformationO

preparelnformation

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


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

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

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

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

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

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

UserSink: EntrvPointSinkAsvnchronous


Provaider: EntrvPointAsvnchronous


requestConnectionQ

-►

I notityConnectionQ |

notityinformation()

\ш

notityinformation()

L--_

notityinformationQ

removeConnection()

1 connectionRemoved() 1

rM-1

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