Национальный стандарт РФ ГОСТ Р ИСО 13374-3-2015 "Контроль состояния и диагностика машин. Обработка, передача и представление данных. Часть 3. Передача данных" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 20 октября 2015 г. N 1580-ст)

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

Дата введения - 1 декабря 2016 г.

Введен впервые

Предисловие

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

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

3 Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 20 октября 2015 г. N 1580-ст

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

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

5 Введен впервые

Введение

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

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

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. В ней также должен быть задан способ рассылки владельцем библиотеки уведомлений подписчикам об имевших место обновлениях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.1 Соединения

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

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

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

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

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

5.4.4 Управление

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

5.4.5 Описания

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

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

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

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

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

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

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

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

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

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

Информация	Обязательность включения	Значения
Событие данных (DataEvent)	Да	Обеспечивает передачу данных с выходов каждого блока системы контроля состояния и диагностирования. Например, модуль на уровне DA передает информацию о датчике в форме DataEvent блока DA. Модуль на блочном уровне DM передает обработанную информацию в форме DataEvent блока DM
Конфигурация	Нет	Указывает способ установки модуля в целях обработки информации. Включает в себя предпочтительные входные данные, алгоритмы описания и типы выходных данных. Может также включать список контролируемых компонентов и типы контролируемых отказов
Управление	Нет	Определяет способность изменить выполнение обработки модулем. Зависит от приложения
Определение	Нет	Дает возможность указать, какие данные использовались как выходные для конкретного блока. Выходными данными могут быть непосредственно данные, полученные в результате обработки внутри блока, либо некоторый указатель на эти данные
Приложение	Нет	Определяет информацию, специфичную для данного приложения
Отправитель	Да	Указывает на источник информации. Должен быть указан способ указания на отправителя информации
Получатель	Нет	Указывает на место направления информации. Используется некоторыми (но не всеми) видами коммуникации. Применение зависит от типа приложения

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

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

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

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

[1]

IEC 62264-5

Enterprise-control system integration - Part 5: Business to manufacturing transactions