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

ГОСТ Р ИСО 13374-1-2011

Группа Т34

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

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

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

Часть 1

Общее руководство

Condition monitoring and diagnostics of machines. Data processing, communication and presentation. Part 1. General guidelines

ОКС 17.160

35.240.99

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

Предисловие

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

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

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

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

________________

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

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

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

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

Введение

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

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

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

2 Обработка данных

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

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

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

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

2.2 Блоки обработки данных

2.2.1 Блоки оценки состояния машины

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

- контроль перемещения вала;

- контроль вибрации подшипников;

- трибологический анализ;

- инфракрасная термография;

- контроль акустических сигналов;

- контроль электрических параметров.

К числу блоков со специфическими методами обработки и функциями, ими реализуемыми, относятся:

a) блок сбора данных (DA): преобразует выходной сигнал преобразователя в цифровые данные, представляющие некую физическую величину и связанную с ней информацию (например, время измерений, результаты калибровки, качество данных, используемый сборщик данных, конфигурация датчиков);

b) блок преобразования данных (DM): выполняет анализ и фильтрацию сигнала, вычисляет значимые параметры;

c) блок определения состояния (SD): устанавливает и поддерживает базовую линию для контроля состояния, исследует отклонения по новому массиву собранных данных и определяет, в какую зону состояния эти данные попадают (например, выше или ниже уровня уведомления или предупреждения).

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

d) блок составления диагноза (НА): выявляет возможные неисправности и скорости их развития на основе информации о техническом состоянии машины;

e) блок составления прогноза (РА): определяет техническое состояние и возможные виды отказов в будущие моменты времени на основе данных о текущем техническом состоянии и информации о планируемом использовании машины, предсказывает остаточный ресурс;

f) блок составления рекомендаций (AG): составляет рекомендации по техническому обслуживанию машины или внесению изменений в ее работу, необходимых для оптимизации срока службы машины.

2.2.2 Отображение данных

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

2.2.3 Представление данных

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

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

2.2.4 Внешние системы

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

2.2.5 Архивирование данных

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

2.2.6 Конфигурирование блоков

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

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

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

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

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

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

- различные отношения или таблицы, в которых хранится информация;

- столбцы данных в таблицах;

- типы данных, содержащихся в столбцах (вещественное число с плавающей запятой, целое число, строка и т.д.);

- может ли столбец содержать только пустые значения;

- уникальные идентификаторы строк ("первичные ключи").

Таблицы могут быть связаны друг с другом через "внешние ключи".

Расширяемый язык разметки (XML) представляет собой проект Консорциума Всемирной паутины [World Wide Web Consortium (W3C)], и разработка его спецификаций находится под контролем рабочей группы этого консорциума. XML - открытый стандарт, являющийся подмножеством стандартного обобщенного языка разметки (SGML) [1] и предназначенный для определения описания структуры электронных документов разных типов.

Этот язык называют расширяемым, поскольку он не имеет жесткого формата, подобно языку разметки гипертекста (HTML), представляющему собой язык разметки со строго определенной структурой. Наоборот, XML по сути является метаязыком (т.е. языком описания других языков), позволяющим пользователю конструировать собственный язык разметки для документов самых разнообразных типов. XML использует стандартизованный (см. [2]) 31-битный набор символов, позволяющий охватить большинство человеческих (и ряд искусственных) языков. В настоящее время он совместим с Юникодом (Unicode) и в будущем должен стать его расширением. XML предназначен обеспечить удобный способ применения SGML для сетевых документов: простоту определения типов документа, легкость в составлении и управлении документом, в его передаче по сети и в обеспечении к нему совместного доступа. Таким образом, XML можно считать упрощенным подмножеством языка SGML, полностью определенным через его спецификацию, который должен позволить обеспечить такое же удобство применения SGML в сетевых технологиях, какое сейчас возможно с применением HTML. Как следствие, XML изначально проектировался с учетом легкости его применения и совместимости с SGML и HTML.

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

Информационная схема программных объектов все более широко используется в программировании. "Объекты" определяются посредством языка описания объектов, включающего их внешние характеристики и функции, уникальные ключи, атрибуты данных, типы данных, отношения и т.д. Унифицированный язык моделирования (UML) стал доминирующим языком моделирования в компьютерной отрасли. Консорциумом OMG (Object Management Group) UML был одобрен в качестве стандартного языка моделирования.

2.3.2 Требования к информационной схеме

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

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

Независимость информационной схемы от технической реализации является ее ключевым свойством. Поставщики и пользователи систем мониторинга используют самые разнообразные способы хранения информации. Открытая информационная схема должна обеспечивать интеграцию разных источников данных, связанных с машиной и ее состоянием, поддерживать пиринговые базы данных, допускать самостоятельное определение пользователем способа их просмотра и использовать стандартизованные метки времени и единицы измерения. Схема должна поддерживать уникальные идентификаторы места и источника данных, чтобы различать данные, полученные от разных физических источников. Кроме того, она должна поддерживать уникальные общесистемные иерархические идентификаторы участков производства (сервисных сегментов), на которых установлены обследуемые машины, а также уникальные иерархические идентификаторы их отдельных узлов. Спецификацией схемы должны быть определены принципы работы с информацией о местах сбора данных и базами этих данных, с информацией о производственных участках, наблюдаемых машинах и их узлах, о заявленных рабочих характеристиках и других данных изготовителя, точках измерений, источниках данных измерений, преобразователях, порядке сбора данных и выходных сигналах системы мониторинга. Схема должна поддерживать форматы для передачи регистрируемых числовых данных, временных реализаций, Фурье-преобразований, спектров с постоянной относительной шириной полосы, результатов контроля образцов, термографических изображений и двоичных больших объектов. Схема должна поддерживать функцию указания даты (времени) в формате согласно [3].

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

3 Форматы передачи данных и методы обмена информацией

3.1 Методологии, используемые в целях передачи данных

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

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

3.1.2 Программа экспорта/импорта файлов данных

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

3.1.3 Применение удаленного доступа к базам данных

Удаленный доступ к базам данных (RDA) представляет собой протокол обмена (подробнее см. в [4]) для доступа к удаленной реляционной базе данных или ей подобному объекту. RDA используется для получения доступа к данным, распределенным по разнородным платформам в сети. RDA применяют в модели "клиент-сервер", в которой клиент просматривает или управляет данными на сервере с помощью языка RDA.

3.1.4 Применение языка структурированных запросов

Язык структурированных запросов (SQL) - язык, применяемый для доступа к данным и управления ими в реляционных базах данных (подробнее см. [5]). SQL интерпретирует базу данных как набор таблиц, представляющих собой упорядочивание собранных данных в фиксированном числе столбцов и изменяемом числе строк. Стандарт SQL определяет синтаксис встраивания запросов SQL в разные языки программирования. Данные размещают на SQL-сервере, к которому клиентские приложения могут обращаться с запросами, написанными на языке SQL.

3.1.5 Применение спецификации производственных сообщений

Спецификация производственных сообщений (MMS) (подробнее см. [6]) обеспечивает большой набор сервисных функций для мониторинга и управления распределенными системами в реальном масштабе времени. Она определяет правила кодирования, грамматику и синтаксис передачи данных процесса от одного компьютера к другому в почти реальном масштабе времени. MMS применяют в модели клиент-сервер, в которой клиент осуществляет мониторинг и управление сервером. При работе сервер создает модель виртуальной производственной системы (VMD), под управлением которой осуществляется доступ к данным.

3.1.6 Применение расширяемого языка разметки

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

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

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

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

3.1.7 Общая архитектура брокера объектных запросов и язык описания интерфейсов

Общая архитектура брокера объектных запросов (CORBA) представляет собой стандарт (подробнее см. [7]) для создания программ коммуникации между объектами, который включает в себя брокер объектных запросов (ORB). Данная спецификация соответствует стандарту [8] на открытую распределенную обработку информации.

Спецификация коммуникации CORBA составлена на языке описания интерфейсов (IDL), стандартизованном в [9], который позволяет дать универсальное (не зависящее от языков программирования) описание интерфейса. Описание компонентов интерфейса через IDL сообщает о выполняемых ими функциях, поддерживаемых методах, параметрах, атрибутах, обработчиках ошибок и иерархических отношениях с другими компонентами.

3.2 Руководство по выбору методологии передачи данных

3.2.1 Методы доступа к данным

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

Метод передачи в системы "клиент-сервер" с использованием реляционных запросов (например, в формате RDA или SQL) требует от поставщика данных поддержки интерфейса уровня вызовов с некоторыми минимальными возможностями, определенными по выбору пользователя. Этот метод обмена данными непосредственно поддерживается реляционной схемой. Применяемый при этом формат схемы описания файлов требует перекодировки данных файла в соответствии с реляционной схемой для поддержания реляционных запросов. Если исходное описание данных сделано по информационной схеме программных объектов, то в этом случае также потребуется перекодировка в соответствии с реляционной схемой.

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

Метод обмена данными с использованием XML-сервера и XML-клиента требует создания XML-схемы или схемы определения типа документа (DTD), которые поддерживают транзакции между клиентом и сервером на основе стандартного словаря, соответствующего концептуальной информационной схеме. Для данных в формате схемы описания файлов, реляционной схемы или информационной схемы программных объектов необходима перекодировка данным для описания содержания в терминах XML.

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

3.2.2 Другие аспекты выбора

При выборе методологии передачи данных и доступа к данным необходимо принять во внимание также:

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

- необходимость представления отчета об ошибках на более высокий уровень системы передачи данных;

- скорость обновления данных при контроле состояния и разрешение по времени, необходимое для проведения их анализа;

- операционную среду и сетевые платформы.

4 Форматы представления и отображения данных

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

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

4.2 Определение этапов контроля состояния

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

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

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

Оценка технического состояния машины включает в себя более углубленные исследования имеющихся данных и применение известных методов анализа с целью установить причину изменения контролируемых параметров. Важным является также установление взаимосвязей между разными параметрами. Необычно высокая температура подшипника и одновременно наблюдаемое повышенное содержание частиц износа в масле является хорошим примером такой взаимосвязи. Обычно специалист начинает исследование с более сложного, но и более информативного анализа вибрационных характеристик, способного дать достаточно полное представление о поведении машины. Такой анализ может включать в себя (но не исчерпываться) выявление доминирующих частотных составляющих в спектре вибрации, определение фазовых соотношений, исследование орбит прецессии вала и установление причинно-следственных связей. На его основе можно выявить такие неисправности как дисбаланс, несоосность, ослабление в соединениях, износ подшипников и зубчатых колес, состояние резонанса. Полный диагностический анализ может быть дополнен исследованием эксплуатационных параметров, таких как нагрузка, частота вращения, скорость потока жидкости. Важно, чтобы результат диагностирования был представлен в легко читаемом информативном виде. Диагностирование объединяет разные виды анализа (вибрационный анализ, термографию, трибологический анализ). Вибрационный анализ, в свою очередь, использует разные подходы: анализ во временной области, анализ в частотной области, построение орбит, анализ переходных процессов при разгоне и выбеге, вейвлет-анализ, вычисление передаточных функций и функций когерентности. Аналогично, трибологический анализ включает в себя анализ частиц износа в масле, спектрографический и феррографический анализы.

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

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

- остаточный ресурс (показатель L10) подшипника;

- степень развития усталостного разрушения парового котла;

- средняя наработка до отказа при динамических нагрузках.

Наконец, вся указанная информация используется для составления обоснованных рекомендаций о дальнейших действиях по эксплуатации машины.

4.3 Общая архитектура отображения информации

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

Для разработки многопользовательских представлений из мультибазовых приложений широко применяют принцип трехсхемной архитектуры, позволяющий отделить определение логических отношений между данными и другими объектами приложения от реализуемого способа управления данными и от реализуемого способа взаимодействия пользователя с приложением. Этими схемами, взаимоотношения между которыми показаны на рисунке 2, являются внутренняя схема, концептуальная схема и внешняя схема. Внутренняя схема отвечает за представление данных и управление данными в компьютерной системе, а внешняя - за представление данных пользователю. Внешние схемы могут объединять самые разнообразные способы перекодировки данных, чем облегчается преодоление трудностей перекодировки в системе "клиент-сервер", указанных в 3.2.1. Концептуальная схема, описанная в 2.3, представляет собой единое обобщенное определение данных в рамках предприятия, независимое ни от конкретного приложения, ни от способов хранения данных и доступа к ним.

Рисунок 2 - Трехсхемная архитектура информационной системы

4.3.2 Форматы отображения

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

а) Оценка состояния

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

Рисунок 3 - Пример областей отображения информации о техническом состоянии авиационного двигателя

b) Диагноз

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

c) Прогноз

В этой области отображают результат прогнозирования. Если машина будет продолжать работать в существующем режиме, то по выработке прогнозируемого остаточного ресурса можно ожидать ее отказа. Однако при условии изменения режима время безопасной работы машины может быть увеличено. Для машин некоторых видов, где есть возможность выбора режима работы (например, скорости нагрева в процентах), может быть указан прогноз развития неисправности для каждого из режимов. Каждый из режимов обладает своими достоинствами и недостатками. Например, ускоренный нагрев может привести к нежелательным максимальным механическим напряжениям в конструкции и большой вероятности ее повреждения. Это обстоятельство должно быть учтено при выборе режима работы и организации технического обслуживания. Аналогично знание условий работы, например подшипника, таких как угол контакта, применяемая смазка, число оборотов вала в минуту, циклы нагружения, позволяет оценить показатель L10 остаточного ресурса упорного подшипника. Изменением, например, условий смазки или уменьшением нагрузки значение L10 может быть увеличено.

Рисунок 4 - Пример областей отображения информации о техническом состоянии парового котла

d) Рекомендуемые действия

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

e) Идентификация

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

5 Персонал

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

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

5.2 Оператор

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

5.3 Инженер-эксплуатационник

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

5.4 Специалист в области надежности

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

5.5 Менеджер

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

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

Спецификации Объединения открытых систем по управлению данными в машиностроении (MIMOSA)

А.1 Общие положения

Объединение открытых систем по управлению данными в машиностроении [Machinery Information Management Open Systems Alliance (MIMOSA)] представляет собой некоммерческое объединение, в состав которого входят ведущие представители разных отраслей промышленности, а также поставщиков системного оборудования, системных интеграторов, провайдеров услуг в области эксплуатации, контроля состояния и технического обслуживания оборудования.

А.2 Спецификация общей реляционной информационной схемы (CRIS)

Основной задачей Объединения является составление рекомендаций и соглашений с целью унификации данных производства, получаемых из систем контроля состояния, технического обслуживания, управления производством, журналов учета работ, чтобы облегчить заинтересованным организациям возможность создания информационно-управляющей системы производства. MIMOSA публикует концептуальные схемы, называемые общими реляционными информационными схемами (CRIS), которые размещены на его сайте http://www.mimosa.org в свободном доступе. Все опубликованные версии CRIS соответствуют настоящему стандарту и успешно применяются в области контроля состояния.

А.3 Спецификация Tech-XML

Объединение MIMOSA опубликовало ряд XML-схем определений интерфейсов для серверов и клиентов на основе CRIS, называемых спецификациями Tech-XML Server и Tech-XML Client соответственно. Эти спецификации позволяют компьютерным информационным системам обмениваться информацией друг с другом без использования протоколов пользователей. Эти спецификации также находятся в свободном доступе на сайте http://www.mimosa.org.

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

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

и сверен по:

, 2018