Full Text

1. Цель и методика проведения испытаний. Испытание - это экспериментальное определение количественных и (или) качественных характеристик свойств объекта испытаний как результата воздействия на него при его функционировании, при моделировании объекта и (или) воздействий [1]. Испытание является крайне важной стадией технологического цикла продукции, так как позволяет выявить показатели качества конечного продукта и их соответствие предъявленным требованиям. Для проведения испытаний продукции в машиностроительной отрасли создаются целые испытательные производства. Они обеспечивают основные виды испытаний: доводочные, предварительные, приёмо-сдаточные и др. Вкратце, на сегодняшний день стендовое испытание сложного технического изделия (СТИ) выглядит следующим образом. Изделие помещается на стенд, далее создаются условия, приближенные к эксплуатационным или превышающие их (это зависит от вида испытания). В это же время с определённой частотой опроса по каналам измерения поступают данные с нижнего уровня (датчиков) на верхний уровень (контроллер). Эти данные сохраняются в виде бинарных файлов - так называемых трендов. Информация о каналах измерения (обозначение измеряемого параметра, допустимая погрешность, наименование датчика и др.) записывается в отдельный конфигурационный файл - паспорт. Затем, после окончания испытания, тренды и все остальные данные об испытании и его объекте поступают в специальное подразделение, которое занимается обработкой этих данных и исследованием причин дефектов изделия. Остановимся поподробнее на последнем этапе. Бинарный файл тренда конвертируется в формат профессионального пакета послеэкспериментальной обработки измерительной информации WinПОС (MERA) [2]. Таким образом, основной объем данных о поведении испытуемого изделия хранится в специфическом формате MERA. После обработки тренда делается расчёт параметров. Расчёт представляет собой вычисление показателей качества изделия (например, КПД) на основе измеренных параметров (например, число оборотов в минуту). Результаты расчётов сохраняются в файле протокола, протокол является Excel-документом, который содержит в себе метаинформацию об испытании, измеренные и расчётные параметры на точках (режимах), графики основных расчётных параметров, заключение по параметрам. 2. Оценка объёма хранимых данных. Результаты всех проведённых испытаний являются ценными с точки зрения аналитики и предоставления отчётности предприятия, поэтому их необходимо сохранять. Проведём оценку объёма данных, подлежащих хранению. Большую часть хранимой информации представляют тренды испытаний. При наблюдении значения параметров фиксируются и привязываются к моменту наблюдения, т.е. являются временными рядами [3, 4]. Для примера рассмотрим испытания турбин. В среднем, чтобы испытать одну турбину, делается 2-6 запусков. В каждом запуске регистрируется порядка 130 параметров, при этом в тренд записывается около 50 000 замеров на каждый параметр, таким образом, объем хранимых данных для каждого тренда составляет около 60 Мб. Помимо тренда около 10 Мб отводится на другие файлы: протокол, паспорт и различные конфигурационные и журнальные файлы. На текущий момент испытано около 80 турбин. Примерно каждый месяц испытывается новая турбина. С расчётом на 10 лет для хранения всех данных потребуется около 100 Гб. 3. Способ хранения данных. Все эти файлы о проведённых испытаниях (тренды, протоколы, паспорта, файлы WinПОС, коэффициенты калибровки, фотографии видимых дефектов образца и т.д.) на сегодняшний день хранятся только в файловой системе. Следовательно, для каждого испытанного изделия информация о проведенных работах размещается в некоторой типовой структуре каталогов (рис. 1). Рис. 1. Данные испытаний в файловой системе Структура подкаталогов отражает процесс испытания каждого изделия. СТИ испытывается сериями работ - постановками на стенд. В разных постановках могут использоваться разные составные элементы изделия. В примере с турбиной это статор, ротор и коллектор. Основной же единицей испытания является работа - запуск изделия. В директории каждой работы хранятся тренд, протокол, коэффициенты калибровки, каталог файлов MERA и другие файлы. Для описания всего набора проведенных испытаний как единого целого создается файл в формате Excel, так называемый «Контроль стабильности». Он хранит в себе метаинформацию по каждой проведённой работе: дату, номер протокола, номера составных частей испытанного изделия, вид испытания, условия проведения, заключение и др. После проведения очередной работы на испытательном стенде в существующую систему хранения вносятся новые данные. Делается это следующим образом: создаётся новая директория в папке со всеми испытаниями, туда помещаются все файлы с рабочей станции стенда; в ней же создаются файл протокола испытания и MERA-файлы. Затем вносятся изменения в файл контроля стабильности. Всё это делается вручную, т.е. имеет место человеческий фактор. Это один из недостатков существующего способа хранения. 4. Проблемы имеющейся технологии хранения и обработки данных. У существующего способа хранения есть ряд недостатков: - разделение и изоляция данных [5]. Поскольку данные хранятся в разных файлах, то собрать информацию из разных файлов достаточно сложно, приходится создавать некоторый временный файл, в который собирается вся необходимая информация, так как приходится организовывать синхронную обработку данных сразу в нескольких файлах; - дублирование данных. Из-за того, что данные хранятся в разных файлах, очень часто приходится повторять некоторую информацию, чтобы не потерять смысл; - зависимость от данных. В файловых системах все данные, а также их структура жестко прописаны, поэтому любое изменение в данных или в структуре требует значительных усилий для внесения такого изменения; - человеческий фактор. Вследствие него могут быть нарушены установленная структура подкаталогов и правила именования файлов. Это может затруднить автоматизированную обработку; - отсутствие механизма поиска данных. Проблема, с которой сталкиваются инженеры при обработке архивных данных испытаний, - это поиск информации об этих испытаниях по определённым критериям, которые затрагивают параметры, хранящиеся в файлах трендов. Например, необходимо вывести номера протоколов и даты всех испытаний, в тренде которых параметр N превышал значение 15 000. Для этого потребуется найти все файлы трендов испытаний и каким-то образом сопоставить их с файлами протоколов. В файловой системе это сделать проблематично, так как тренд и протокол могут вследствие человеческого фактора быть расположены в разных директориях и под разными названиями от испытания к испытанию. 5. Концепция системы сбора, обработки и хранения данных, требования к системе. Для устранения всех вышеперечисленных недостатков предлагается создать единую систему сбора, обработки и хранения данных о проведённых испытаниях, т.е. можно сформировать цель исследования как разработку системы сбора, обработки и хранения данных. Разрабатываемая система должна удовлетворять определённым требованиям. Основное требование к системе - это решить существующие проблемы хранения послеэкспериментальных данных испытаний. Для этого необходимо хранить данные в единой БД, под которой будем понимать совокупность программ и языковых средств, предназначенных для управления данными и обеспечения взаимодействия их с прикладными программами (ГОСТ 20886-85). Отсюда вытекает следующее требование - сам переход от существующего способа хранения. Все накопленные данные в файловой системе нужно перенести в БД, т.е. в системе должен быть реализован механизм импорта. Далее, после того как выбран способ хранения, требуется разработать функционал поиска и отображения испытаний по различным параметрам. Это могут быть как параметры самого испытания, так и параметры тренда. Для проведения обработки послеэкспериментальных данных необходимо реализовать автоматизированное выделение режимов испытания и расчёт параметров на этих режимах. Автоматизированное выделение означает, что все режимы, которые явно представлены в тренде в каком-либо параметре, система должна распознавать. Пользователь, в свою очередь, должен иметь возможность редактировать набор режимов. Функционал проведения расчётов должен включать в себя хранение и обработку данных расчётных параметров - как минимум, обозначений и расчётных формул. Используя эти данные, система должна автоматически вычислять и отображать значения расчётных параметров на каждом режиме. Также требуется, чтобы система имела возможность интеграции с другими программами, участвующими в технологическом процессе обработки послеэкспериментальных данных. Для этого нужно разработать алгоритмы экспорта в такие форматы, как MERA (для экспорта тренда) и CSV (для информации, представленной в таблицах). 6. Выбор и обоснование способа хранения, обзор имеющихся подходов. Проблему выбора адекватного задаче способа хранения можно считать самостоятельной научной проблемой. Осознание важности проблемы хранения данных испытаний сложных изделий и построение такой системы применительно к процессу испытаний газотурбинных двигателей (ГТД) представлено в [6]. Вся информация о стендовых испытаниях ГТД сохраняется в базе данных на основе языка разметки XML. Такой способ хранения хорошо подходит для сохранения слабо структурированной, разнородной информации об изделии и об условиях и конфигурациях испытаний, но неудобен для записи переходных режимов, т.е. собственно трендов. Есть две проблемы при выборе способа хранения данных об испытаниях. Первая проблема - это то, что временные ряды неудобно хранить в традиционных реляционных СУБД (РСУБД). Существует класс специализированных баз данных временных рядов (Time-series databases) [7, 8]. Большинство таких БД организовано в структуры, которые записывают значения для одного элемента. Например, можно создать таблицу для отслеживания температуры процессора. Внутри каждое значение будет состоять из временной метки и показателя температуры. В таблице может быть несколько метрик. Таким образом, эти базы не приспособлены для хранения какой-либо другой информации, не являющейся временными рядами. А в нашем случае временные ряды являются важной, но не единственной информацией, описывающей испытания. Второй проблемой является то, что для хранения информации об испытаниях РСУБД приспособлены плохо, так как набор регистрируемых параметров (столбцы в таблице данных) меняется от испытания к испытанию. Также РСУБД плохо подходят для сохранения разнородных дополнительных данных (фото, файлы документов и пр.). Проблема, заключающаяся в том, что каждая серия экспериментов имеет свой набор разнообразных измеряемых и вычисляемых параметров, что существенно усложняет создание единой структуры БД, была отмечена в [9]. Для решения этой проблемы был предложен вариант организации данных, когда база содержит только однотипную для всех экспериментов информацию, а остальные данные сохраняются в прикрепленных файлах на сервере. Эта же проблема в [10] решается так: все данные всех параметров записываются в одну огромную таблицу, имеющую следующую структуру полей: - testing_data_id - уникальный идентификатор; - testing_id - идентификатор испытания; - parameter_id - идентификатор параметра; - Value - данные тестирования. Учитывая проведенную выше оценку объёма хранимых данных, количество записей в этой таблице для нашего случая превысит 10 миллиардов, что делает такую реализацию явно неработоспособной. Как альтернатива РСУБД предлагается использование документоориентированной СУБД MongoDB [11], которая обладает следующими преимуществами: - возможно хранение больших объёмов неструктурированной информации в отличие от РСУБД; - не загромождена механизмом контроля целостности данных, который является избыточным для решения нашей задачи; - предоставляет развитые механизмы запросов; - большие возможности резервного копирования (репликация); - балансировка нагрузки (шардинг); - базовая (community) версия является бесплатной. Способ хранения временных рядов в документо-ориентированной базе данных рассмотрен в [12-15]. Практическая реализация выбранного способа хранения, как показано ниже, подтвердила правильность сделанного выбора. 7. Использование JSON-сценария импорта. Первой задачей, возникающей при создании предлагаемой системы, является импорт уже накопленных данных об испытаниях в документо-ориентированную БД. Эти данные не имеют жёсткой структуры, так как формировались пользователями вручную на протяжении нескольких лет. Чтобы решить эту проблему, была реализована идея импорта по JSON-сценарию. Сценарий - это JSON-документ [16], который фактически содержит указания для модуля импорта: откуда и какую информацию брать и куда и в каком виде размещать. Как уже было отмечено, данные об испытаниях изделия хранятся в виде набора файлов различных форматов (MERA, текстовых, документах Excel), при этом размещение файлов задается специалистами по обработке данных испытаний со значительными вариациями. Для проведения импорта данных для каждого испытанного изделия формируется JSON-файл, куда записывается метаинформация обо всех постановках и запусках и пути к файлам трендов, коэффициентов калибровки, паспортов и т.д. Все параметры, описанные в этом файле, делятся на два типа - пользовательские и служебные. Пользовательские параметры представляют собой реквизиты проведённых испытаний - дата, номер турбины и т.д. При импорте таких параметров не задействуется какая-либо бизнес-логика; они просто сохраняются в базе и отображаются на интерфейсе системы в формате «ключ-значение». К служебным параметрам относятся пути к необходимым файлам испытания, а также параметры навигации по файлу протокола испытания. Такие параметры система распознаёт и обрабатывает особым образом. Общая схема импорта представлена на рис. 2. Рис. 2. Cхема импорта при помощи JSON-файла импорта Рис. 3. Иерархическая структура файла импорта Чтобы импортировать все данные по испытанному изделию с учетом иерархии данных (изделие - серия работ - постановка), в файле импорта создаётся иерархия узлов, отвечающих за каждый уровень испытания (рис. 3). Набор параметров для каждой работы, как и иерархия работ и постановок в рамках испытания, не фиксирован. Для описания такой динамической структуры формат JSON подходит как нельзя лучше. Кроме того, JSON-файл легко читается и пишется человеком, а также десериализуется в структуры данных современных языков программирования, что является несомненным плюсом при разработке программ для импорта. Использование json-модели для хранения результатов испытаний рассмотрено в [17]. 8. Архитектура системы (экосистемы хранения данных испытаний). Вся системы сбора, обработки и хранения данных является комплексом различных приложений, которые вместе составляют так называемую экосистему хранения данных испытаний (рис. 4). Рис. 4. Экосистема хранения и обработки послеэкспериментальных данных Основную часть функций системы покрывает программа для работы с архивными данными испытаний. Это центральный компонент системы, который содержит в себе сервисы работы с данными, расчётно-аналитический функционал и связывает остальные компоненты системы в единое целое с помощью импорта и экспорта данных. 9. Функции клиентского приложения. Данные всех испытаний, которые были импортированы в БД, представлены пользователям в виде иерархического дерева, отображающего исходную структуру испытаний (рис. 5). В левой части окна располагается «дерево» испытаний, в правой - параметры выделенного узла в «дереве» (они же реквизиты). С любым из узлов могут быть ассоциированы файлы, имеющие отношение к данному уровню испытаний. Рис. 5. Отображение дерева испытаний Основная задача, стоящая перед специалистами, обрабатывающими информацию об испытаниях, - обеспечить поиск данных в трендах по заданным критериям. Рассмотрению задачи поиска данных во временных рядах посвящены следующие источники [18-20]. Для обнаружения особенностей во временных рядах в них используются методы, основанные на прогнозировании, при этом под объектами поиска, как правило, подразумеваются те или иные аномалии данных. Для анализа данных об испытаниях такие методы поиска не соответствуют требованиям, предъявляемым к способам анализа трендов. Специалисты по обработке данных должны иметь возможность непосредственно описывать объект поиска, задавая условия поискового запроса. Из-за огромного объема хранящихся в базе данных поиск по всем трендам делать бесперспективно. Поэтому необходимо предварительно определить область поиска. Область может быть определена вручную выбором определенных наборов узлов, при этом расположение узлов соответствует исходной иерархии испытаний. Поиск будет производиться от выбранного узла по всем дочерним рекурсивно - вплоть до узла-запуска. Другим способом является предварительный отбор узлов по параметрам узла или параметрам статического режима, тем самым производится отбор трендов, по которым будет осуществляться поиск. На каждом уровне заданной иерархии (Испытание, Серия, Работа) пользователю доступен поиск определенного набора параметров, заданного при импорте данных в БД. На уровне тренда параметры могут характеризовать как весь узел (тренд) в целом, так и отдельные режимы тренда. В зависимости от типа данных параметра для ввода условий поиска предусмотрены различные способы их ввода - задание диапазона искомых значений или по совпадению (полному или частичному) строкового параметра. Поиск особенностей в трендах сводится к поиску набора событий, характеризующих поведение тренда. В качестве этих событий рассматриваются такие, как попадание значения параметра (или его производной) в заданный диапазон, достижение минимума/максимума значения параметра, переключение состояния дискретного параметра и т.д. Каждое из перечисленных событий, в свою очередь, может описываться набором параметров. Так, событие типа «попадание в заданный диапазон» описывается заданием верхней и нижней границы диапазона, ожидаемым временем появления второго события после появления первого, в течение которого значение параметра не должно выходить за указанный интервал значений, размер окна усреднения при применении сглаживания параметра по алгоритму скользящего среднего (окна). Искомые события могут происходить как одновременно, так и с временным сдвигом (с заданием времени ожидания, т.е. времени появления второго события после появления первого). В условиях поиска может быть задано несколько событий, при этом события могут группироваться при помощи логических операций И, ИЛИ. Для пользователя комбинирование условий при помощи И, ИЛИ представлено в виде дерева, которое также отображается в виде строки. Например, для условия поиска, который можно описать так: «найти моменты времени, когда во время режима «0,65» происходит переход параметра K2_close из 0 в 1 или из 1 в 0», строковое представление будет иметь вид: (Режим=0,65) AND ((K2_close Переход в 1) OR (K2_close Переход в 0)) Для пользователя поисковый запрос имеет древовидную структуру, при этом сложность структуры запроса ограничена только возможностями специалиста в формулировании цели поиска. Пример дерева поиска особенностей представлен на рис. 6. Рис. 6. Дерево поиска событий, характеризующих поведение тренда Описание условий поиска составляет поисковый запрос. Поисковые запросы могут сохраняться пользователями для повторного использования. После получения результатов поиска возможна их дальнейшая обработка, также найденные тренды можно сразу просмотреть с помощью WinПОС. Выводы. Разработанный комплекс приложений обеспечивает импорт информации об испытаниях, хранение и предоставление по запросу пользователей всей требуемой информации обо всех когда-либо проведенных испытаниях с возможностью экспорта в выбранный формат. Механизм поисковых запросов предоставляет специалистам по обработке данных мощный инструмент анализа.

About the authors

I. A Shmidt

Perm National Research Polytechnic University

A. S ZHeltyshev

Perm National Research Polytechnic University

References

Statistics

Views

Abstract - 33

PDF (Russian) - 5

Refbacks

• There are currently no refbacks.