Устанавливает требования к передаче данных в открытой эталонной информационной архитектуре систем контроля состояния и диагностирования и эталонной архитектуре систем обработки данных. Стандарт предназначен для разработчиков систем программного обеспечения процедур обмена данными между различными приложениями системы контроля состояния и диагностирования предприятия и обеспечивает операционную совместимость этих систем.
Идентичен ISO 13374-3:2012
Переиздание. Ноябрь 2018 г.
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.2021 |
20.10.2015 | Утвержден | Федеральное агентство по техническому регулированию и метрологии | 1580-ст |
---|---|---|---|
Разработан | АО НИЦ КД | ||
Издан | Стандартинформ | 2016 г. | |
Издан | Стандартинформ | 2018 г. |
Чтобы бесплатно скачать этот документ в формате PDF, поддержите наш сайт и нажмите кнопку:
ГОСТ Р исо
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
Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии
Потребитель должен иметь возможность указать на требуемый объем информации, который должен поступить на приемник. Потребитель должен реализовать интерфейс приемника, обеспечивающий получение всех типов данных, на которые он подписался и которые провайдер способен передать. Приемник должен также принимать от провайдера незапрошенную информацию.
Интерфейс данного вида позволяет реализовать разные режимы передачи данных. Среди них должны быть реализованы режимы: «передача всех данных», «передача данных выше порогового уровня», «передача данных только по запросу». Пользователь сообщает провайдеру, какой режим является предпочтительным. Возможности провайдера должны позволять ему передавать информацию больше той, что запрашивает потребитель, но не менее той, что он запрашивает.
5.3.2.3.3 Асинхронный интерфейс, тип 2
Встроенные системы контроля часто предъявляют особые требования к передаче данных. Таким требованием может быть установление неблокирующего одностороннего соединения. Такие системы могут иметь ограничения на конфигурацию, не позволяющие ей осуществлять передачу данных множественным пользователям в асинхронном режиме.
Для систем с указанными типами ограничений соединение с потребителями через канал приемника должно быть установлено через процесс инициализации. Потребители должны получать от провайдера данные асинхронным способом по мере их появления. Единственное требование для систем данного типа — возможность скорейшей отправки данных в стандартном формате, определенном потребителем. От пользователя требуется реализовать интерфейс приемника, обеспечивающий получение информации всех типов информации, которую может отправить провайдер.
Сервисы потребителя, такие как хранение/архивация данных, система планово-предупредительного обслуживания или система обучения команд операций, могут быть настроены на использование результатов системы контроля состояния и диагностирования. Сервис потребителя должен обеспечить интерфейс, позволяющий провайдеру данных отправлять потребителю незапрашиваемую информацию. Сервис потребителя отвечает индикацией, показывающей, была ли информация успешно получена и обработана или же имели место какие-либо ошибки. Ошибки могут относиться как к процессу передачи, так и к процедурам обработки данных. Пример сервиса потребителя показан на рисунке 7.
| ||||||
notifylnformationQ |
preparelnformation | |
Рисунок 7 — Пример реализации сервиса потребителя |
Асинхронный интерфейс типа 1 должен обеспечивать способы информирования об установлении и удалении соединения. Соответствующий асинхронный интерфейс приемника должен иметь индикации установленного и удаленного соединения.
Каждый блок в архитектуре обработки данных по ИСО 13374-2 предусматривает вывод данных. В каждом типе интерфейса должен быть реализован метод передачи событий данных. Синхронный и асинхронный интерфейсы типа 1 должны обеспечивать запрос выходных данных. Приемник асинхронного интерфейса типа 1 должен обеспечивать получение событий данных. Асинхронный интерфейс типа 1 для провайдера должен реализовать метод передачи событий данных.
7
Каждый блок в архитектуре обработки данных по ИСО 13374-2 предусматривает ввод и вывод информации о конфигурации. Синхронный и асинхронный интерфейсы типа 1 должны реализовать метод ввода и вывода информации о конфигурации. Провайдер должен определить объем данных об имеющейся конфигурации, который необходимо поддерживать в соответствии с потребностями приложения. Если данные в требуемом объеме не поддерживаются, то об этом должно быть сообщено потребителю.
Управляющая информация определяет возможности модификации блока обработки. Эта информация может быть в форме ожидаемых рабочих параметров или в виде предпочтительных пороговых значений предупреждения. Синхронные и асинхронные интерфейсы типа 1 должны реализовать метод возвращения установок параметра управления, а также изменения этого параметра. Провайдер должен определить объем управляющей информации, поддерживаемой в соответствии с потребностями приложения. Если информация в требуемом объеме не поддерживается, то об этом должно быть сообщено потребителю.
Описания — информация, которая использовалась для разработки вывода данных блока обработки. Данная информация имеет вспомогательный характер. Если она поддерживается, то синхронный и асинхронный интерфейсы типа 1 должны реализовать способ ее возврата. Провайдер должен определить объем данных об описаниях, который необходимо поддерживать в соответствии с потребностями приложения. Если данные в требуемом объеме не поддерживаются, то об этом должно быть сообщено потребителю.
Каждое приложение запрашивает информацию, связанную с инициализацией, и, возможно, дополнительную специализированную информацию. Синхронные и асинхронные интерфейсы типа 1 должны реализовать метод ввода и возврата специализированной информации. Провайдер должен определить объем специализированной информации, поддерживаемой в соответствии с потребностями приложения. Если информация в требуемом объеме не поддерживается, то об этом должно быть сообщено потребителю. Сервис пользователя поддерживать специализированную информацию не обязан.
Должны поддерживаться методы передачи метаданных об отправителе информации. Должны также поддерживаться метаданные относительно приложения получателя, работающего с передаваемыми данными.
Каждое приложение требует наличия метода индикации ошибок при выполнении внутренних операции и уведомления пользователей.
В таблице 1 приведены основные методы обработки данных, которые должны использоваться каждым блоком в открытой архитектуре обработки данных системы контроля состояния и диагностирования.
Таблица 1 — Типы информации | ||||||||||||
|
Окончание таблицы 1 | |||||||||||||||
|
5.5 Поддержка спецификации данных провайдера
Провайдер информации выбирает блоки обработки данных, например, DA, DM, SD, НА, РА или AG, которые он поддерживает, а также поддерживаемые им методы обработки данных для каждого такого блока. Провайдер также выбирает обеспечивающие поддержку дополнительные интерфейсы и сервисы в зависимости от особенностей конкретного приложения. Рисунок 8 суммирует области, которые должны быть определены. Области поддержи спецификации данных провайдера показаны на рисунке 8.
Блоки обработки
• Сбор данных
• Преобразование данных
• Обнаружение неисправностей
• Определение состояния
• Составление прогноза
• Составление рекомендаций
Обработка в блоках
• События данных
• Конфигурация
• Управление
• Определение
• Приложение
• Отправитель/получатель
Сервисы потребителя
• Сервисы собранных данных
о Хранение о Поиск и выборка
• Сервисы внешних систем
о Обслуживание о Консультативное управление
• Управление конфигурациями
• Служба сервисов
Типы технологий
• Языки программирования
• Протоколы обмена данными
• Форматы данных_
Типы интерфейса
• Сервисы провайдера
о Асинхронные о Тип 1 о Тип 2 о Синхронные
• Сервисы потребителя
Рисунок 8 — Области поддержки спецификации данных провайдера
9
Открытая информационная архитектура систем контроля состояния и диагностирования на основе МЭК 62264-5 [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.
Идентифицирует отправителя сообщения Идентифицирует обратный адрес отправителя Определяет вариант подтверждения Другая информация об отправителе
Определяет дату и время создания сообщения Определяет форму сообщения Определяет другую информацию о сообщении
Рисунок А.2 — Типовой формат области идентификации приложения Таблица А. 1 — Инициирующие действия
| ||||||||||||||||
Таблица А.2 — Ответные действия |
| ||||||
11 |
Окончание таблицы А. 2 | ||||||
|
А.1.1.3.1.2 Описание инициирующих действий А.1.1.3.1.2.1 GET
Действие GET обеспечивает запрос информации об одном или нескольких объектах.
Ответом на сообщение 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
Рисунок А.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 включаете себя удаленные экземпляры объекта.
| |||||||||||||||||
Рисунок А.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
Провайдер информации |
Пользователь информации | ||||
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).
| ||||||||||||||||||||
Рисунок А.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 | ||||||||
|
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. Область данных сообщения должна содержать идентификацию типа модификаций |
Область объекта содержит объекты и ассоциированные элементы, представляющие один или несколько объектов источников данных, определенных таким образом, чтобы исключить неоднозначность понимания передаваемых сообщений.
А.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
Настоящий стандарт устанавливает требования к передаче данных в открытой эталонной информационной архитектуре систем контроля состояния и диагностирования и эталонной архитектуре систем обработки данных. Настоящий стандарт предназначен для разработчиков систем программного обеспечения процедур обмена данными между различными приложениями системы контроля состояния и диагностирования предприятия и обеспечивает операционную совместимость этих систем.
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ИСО 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]
В настоящем стандарте применены термины по ИСО 13372.
Издание официальное
Информационная архитектура описывает все объекты данных и их свойства (атрибуты), типы свойств, соотношения между объектами данных, ссылочные данные и источники данных для заданной системы или приложения. Открытая спецификация информационной архитектуры, системы контроля состояния и диагностирования машин должна описывать каждый из пяти уровней, показанных на рисунке 1.
Содержание сообщений, используемых в процессе обмена данными между приложениями открытой информационной архитектуры системы контроля состояния и диагностирования, должно соответствовать определениям, установленным на уровне 5 информационной архитектуры, и данным ссылок, установленным на уровне 4. Применение сообщений зависит от требований приложения (см. приложение А).
Открытая информационная архитектура системы контроля состояния и диагностирования должна устанавливать метод, посредством которого получатели сообщений могут иметь доступ к библиотечной информации, определенной на уровне 4. В ней также должен быть задан способ рассылки владельцем библиотеки уведомлений подписчикам об имевших место обновлениях.
| |||||||||||||||
Рисунок 1 — Уровни информационной архитектуры системы контроля состояния и диагностирования (по ИСО 13374-2) |
Открытая информационная архитектура системы контроля состояния и диагностирования должна определить требования инициирования приложения провайдера для каждого метода передачи данных, входящих в архитектуру. Представления даты и времени в информации об инициировании должны ссылаться на григорианский календарь в соответствии с ИСО 8601. Инициирование передачи данных должно также ссылаться на определенные уровнем 5 определения информационного документа, которым подчиняется содержание передаваемых сообщений.
Открытая спецификация информационной архитектуры систем контроля состояния и диагностирования должна определять требования к содержанию сообщений приложений провайдера для каждого метода передачи, предусматриваемого архитектурой. Определение содержания сообщения должно ссылаться на соответствующее определение информационного документа с учетом возможной интерпретации формата информационного документа, включая его сжатие и используемое кодирование.
Архитектура обработки данных описывает все интеракции и транзакции между внутренними модулями программной системы, которые одновременно являются внешними модулями для конечного пользователя и других программных средств. Как установлено в ИСО 13374-2, открытая архитектура обработки данных системы контроля состояния и диагностирования должна иметь вид, показанный на рисунке 2.
Датчик / Преобразователь / Ручной ввод |
Рисунок 2 — Блок-схема потока информации и этапов обработки данных |
Эта архитектура определена в виде блоков, реализующих разные функции обработки данных. Каждый блок должен быть соответствующим образом конфигурирован. Данные, полученные из блока
3
сбора данных (DA) в цифровом формате, после соответствующих преобразований приобретают вид соответствующих рекомендаций на выходе блока составления рекомендаций (AG). По мере продвижения от блока DAk блоку AG данные поступают на очередной блок преобразования вместе с дополнительной информацией от внешних систем, а с выхода этого блока также могут быть посланы внешним системам. При этом данные, вовлекаемые в информационный поток, нуждаются в соответствующем стандартном отображении и простом графическом представлении. Многие приложения в целях сохранения результатов преобразования информации каждым блоком системы требуют, чтобы соответствующие данные были архивированы. Блоки DA, DM и SD отвечают за оценку качества данных, которое может быть высоким, низким или неопределенным.
Настоящий стандарт определяет требования к передаче данных для любой открытой архитектуры обработки данных системы контроля состояния и диагностирования. Это позволяет интегрировать в единую функциональную систему блоки обработки данных, получаемые от разных поставщиков.
Обычно возможность приема данных от датчиков с последующим их анализом на более высоких уровнях системы контроля состояния и диагностирования может быть реализована в разных программных средах разными аппаратными средствами. Часто отправной точкой работы системы является сбор данных в реальном масштабе времени со стационарно установленных преобразователей.
После этого данные подвергаются обработке блоками системы для представления в формате, удобном для оценки и прогнозирования технического состояния, а также для выработки рекомендаций. Указанные процедуры могут быть реализованы с помощью разных технологических решений. Технологии и программные средства, используемые в блоках обработки НА, РА и AG (блоки анализа), часто отличаются от используемых в блоках обработки DA, DM и SD (блоках данных).
Объем информации, передаваемой в блоки данных, существенно превышает объем информации, генерируемый блоками анализа. Блоки данных обычно проектируют из расчета высокой скорости обработки информации зачастую в реальном масштабе времени. Выходные данные результатов обработки в блоках анализа должны поступать своевременно, однако, как правило, не в масштабе миллисекунд и не в реальном масштабе времени. Следует учитывать также непрерывный процесс развития технологий, включая развитие языков программирования, сетевых протоколов и методов хранения данных.
Для поддержки передачи данных в открытой архитектуре обработки данных системы контроля состояния и диагностирования должна быть определена модель унифицированного языка моделирования (UML), совместимая с ИСО/МЭК 19501, поддерживающая основные информационные классы и требуемые интерфейсы. Как показано на рисунке 3, UML должен быть реализован в конкретных технологиях, таких как веб-сервисы на основе языка XML или встроенные системы передачи двоичных данных.
Рисунок 3 — Применение UML к конкретной технологии 5.2.2 Стандартное содержание данных Если содержание данных стандартизовано, то преобразование из формата одной технологии в формат другой становится предметом взаимно-однозначного отображения. Так, сообщение в двоичном формате при необходимости может быть переведено в код XML с помощью универсального преобразователя. |
При проектировании и управлении операциями обработки данных в системе контроля состояния и диагностирования важно иметь информационно-управляющую систему, совместимую с открытой информационной архитектурой системы (см. раздел 4). Информационно-управляющая система содержит не только информацию об операциях, но также метаданные, описывающие информационные потоки в системе. Они могут включать в себя описание сигналов сдатчиков и их источников, алгоритмы преобразования этих сигналов, а также информацию об исполнителе (человеке или программном средстве), осуществляющем анализ данных.
Метаданные обеспечивают возможность проведения технического анализа данных и позволяют использовать результаты анализа в приложениях более высокого уровня, обслуживающих бизнес-процессы, логистические операции и процедуры принятия решений.
Разнообразный набор технологий, применяемых в системах контроля состояния и диагностирования, которые используют информацию, предоставленную этими же системами, требует сопряжения интерфейсов. Известны два основных типа коммуникационных сервисов: провайдера и потребителя (DataUser). .Сервисы провайдера собирают и обрабатывают информацию и предоставляют результаты заинтересованным пользователям. Сервисы потребителя используют данные системы контроля состояния и диагностирования от провайдера, чтобы создать новые возможности.
Подсистема обработки данных в системе контроля состояния и диагностирования должна поддерживать реализацию сервисов потребителя и/или провайдера и обеспечить интерфейс конкретного сервиса через EntryPoint (точку входа).
5.3.2.1 Общие положения
На рисунке 2 все стрелки, идущие вниз от блоков, указывают на передачу данных определенного содержания через интерфейс провайдера. Выходные данные каждого блока представляют собой информацию от провайдера, в которой нуждается заинтересованный потребитель. Существуют два основных типа интерфейсов провайдера: синхронный и асинхронный. В системе может быть реализован один из этих типов или оба.
5.3.2.2 Синхронный интерфейс
| ||||||
requestlnformationO |
preparelnformation |
return information
Ч
Провайдеры, поддерживающие синхронный интерфейс, применяют прямой механизм вызова/ возврата. Блок потребителя посылает обращение с указанием интересующей информации, и это обращение не возвращается, пока затребованная информация не станет доступна. После этого осуществляется передача затребованной информации. Типичной реализацией интерфейса данного типа является веб-сервис. Пример реализации синхронного интерфейса показан на рисунке 4.
Рисунок 4 — Пример применения синхронного интерфейса «запрос-ответ»
В дополнение к обработке запроса данных любым блоком или внешним приложением система провайдера должна поддерживать возможность запроса модификации алгоритма обработки. Примерами модификаций являются установка конфигурации блока и контроль пороговых значений.
5
Провайдер должен выполнить модификацию (если это возможно) и возвратить статус выполнения операции (успешное выполнение или ошибка с указанием кода) в соответствии с его возможностью обработать модификацию. Пример реализации показан на рисунке 5.
| ||||||
Т |
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 | ||||||||||||||||||
| ||||||||||||||||||
Рисунок 6 — Пример применения асинхронного интерфейса «запрос-ответ» |