Научный журнал
Фундаментальные исследования
ISSN 1812-7339
"Перечень" ВАК
ИФ РИНЦ = 1,074

СИСТЕМА РЕГИСТРАЦИИ ПАРАМЕТРОВ ИСПЫТАНИЙ СЛОЖНЫХ ИЗДЕЛИЙ НА ОСНОВЕ ДОКУМЕНТНО-ОРИЕНТИРОВАННОЙ БАЗЫ ДАННЫХ

Васнев Н.В. 1 Шмидт И.А. 1
1 Пермский национальный исследовательский политехнический университет
В статье рассмотрен принцип работы подсистемы регистрации параметров при проведении испытаний сложных технических изделий, в частности, газотурбинных установок. Выявлены недостатки существующего решения по сохранению информации в виде набора файлов данных. Была предложена подсистема регистрации параметров, базирующаяся на применении документно-ориентированной базы данных MongoDB, обоснован выбор данной БД. Была предложена структура записи для рационального хранения набора трендов данных испытаний. Для проверки технологии сохранения параметров авторами было разработано тестовое приложении, воспроизводящее процесс испытаний. Приложение реализовано в пакете LabVIEW. Описан подробный принцип работы приложения, рассмотрена связь документно-ориентированной базы данных MongoDB и пакета LabVIEW, приведены результаты работы приложения при различных исходных параметрах, показана зависимость скорости записи параметров от размера буфера.
хранение и сбор данных
MongoDB
LabVIEW
1. Кавалеров Б.В., Казанцев В.П., Шмидт И.А. Компьютерные и полунатурные испытания средств управления энергетических газотурбинных установок // Информационно-управляющие системы. – 2011. – № 4. – С. 34–41.
2. Кайл Бэнкер. MongoDB в действии – М.: ДМК Пресс, 2012. – 395 с.
3. Попов Д.А., Шмидт И.А. Разработка системы управления архивными данными испытаний газотурбинных установок большой мощности // Современные проблемы науки и образования. – 2014. – № 2.; URL: http://science-education.ru/ru/article/view id=12035.
4. Попов Д.А., Шмидт И.А. Оперативный сбор параметров при испытаниях различных типов ГТУ на базе оборудования NATIONAL INSTRUMENTS // Научно-технический вестник Поволжья. – 2014. – № 2. – С. 192–196.
5. Попов Д.А., Шмидт И.А. Выбор методов реализации верхнего уровня проведения испытаний газотурбинных установок на базе аппаратных средств NATIONAL INSTRUMENTS // Научные исследования и инновации. – 2012. – Т. 6, № 1–4. – С. 249–254.
6. Попов Д.А., Шмидт И.А. Разработка функциональной структуры программного комплекса испытаний газотурбинных установок мощностью до 40 мвт // Научные исследования и инновации. – 2012. – Т. 6, № 1–4. – С. 264–270.

Подсистемы регистрации параметров являются важной частью систем испытаний сложных изделий. Развитые системы испытаний могут регистрировать 100–500 параметров, при частоте их регистрации до 200 Гц [1]. Испытания при этом могут идти несколько часов. Качество таких подсистем определяется несколькими свойствами: отказоустойчивостью, долговечностью, скоростью записи, а также удобством извлечения и визуализации полученных данных.

Рассмотрим применяющийся в настоящее время способ сохранения информации при проведении испытаний газотурбинных установок газоперекачивающих агрегатов (ГТУ ГПА). Физические и «датчиковые» значения замеренных параметров (тренды) записываются во время испытаний в двоичный «плоский» файл. Для организации хранимых данных такой системы используется структура (совокупность таблиц), описывающая каждый из регистрируемых параметров, которая называется паспорт испытания. Паспорт испытания хранится в РСУБД, он содержит полное описание для каждого, измеряемого при испытаниях, параметра (см. рис. 1), в том числе: смещение для параметра относительно начала записи, характеристику канала измерения, включая тарированную характеристику и т.д. Идентификация испытания проходит по имени двоичного файла, в котором закодированы дата и номер испытания. Такая структура хранения показывает довольно высокую скорость записи, но при этом низкий уровень надежности. В целом способ является слабо гибким, т.к. отсутствуют высокоуровневые способы поиска информации, а также нет возможности сопоставлять результаты различных испытаний (они хранятся в разных файлах).

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

vasen1.wmf

Рис. 1. Организация данных при сохранении в двоичный файл

В рамках данной задачи рассмотрим варианты применимых типов баз данных: РСУБД и документно-ориентированные БД. Применение РСУБД было бы целесообразно при хранении неизменного набора параметров, однако реальные испытания характеризуются различным набором параметров при проведении различных испытаний. Кроме этого механизмы транзакций и контроля целостности данных избыточны для хранения технологических параметров [3]. Применение документно-ориентированных баз данных, которые позиционируются как системы для хранения больших объемов данных без жесткой структуры, является разумной альтернативой. Из существующего многообразия документно-ориентированных баз данных была выбрана MongoDB [2]. Приведем ее характеристики.

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

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

Опишем кратко структуру подсистемы регистрации параметров на примере системы для испытаний ГТУ ГПА [4]. Все данные перед тем как попасть в БД, проходят три уровня обработки. Первый, нижний уровень подсистемы обеспечивает опрос модулей связи с объектом, получение данных и их транспортировку на второй уровень. На втором уровне проходит первичная обработка поступивших данных и их графическая визуализация для управления процессом испытаний. В качестве основы для программного обеспечения второго и первого уровня использована многофункциональная платформа LabVIEW.

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

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

Разработанное авторами тестовое приложение, которое относится к третьему уровню, позволяет решить следующие задачи:

  • Проверка возможности записи данных в БД MongoDB средствами LabVIEW.
  • Определение и изменение структуры документа, пригодной для сохранения текущих параметров процесса.
  • Определение времени сохранения данных в зависимости от количества регистрируемых параметров и записей в БД.

Для работы с базой данных MongoDB из пакета LabVIEW необходимо добавить в проект библиотеки MongoDB.Bson.dll и MongoDB.Driver.dll. После этого в LabVIEW будут доступны компоненты .NET, которые позволяют создавать BSON-классы и получать доступ к их функциям. С помощью .NET-компонент происходит подключение к серверу, на котором хранится БД, далее подключение к БД, затем подключение к необходимым коллекциям, из которых можно считывать или записывать данные.

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

db.collection_name.insert({sensor_name: [{time:0.1, value:0.21},{ time:0.2, value:0.25}]}).

Входными параметрами такой структуры являются время записи и значение физической величины, которые необходимо перевести в числовой BSON-формат. Так как MongoDB работает с JSON-структурой, которая состоит из пары ключ – значение, то необходимо привязать значение параметра и времени к нужным ключам. Предварительно создается объект класса BsonDocument. Полученные с помощью .NET-компонент пары ключ-значения для времени и величины параметра объединяются в список для записи в BSON-документ. Чтобы занести объединенные параметры в документ, вызывается функция Add(), которая входным значением принимает список элементов. На рис. 2 представлен SubVI для формирования BSON-документа.

Выходом SubVI будет ссылка на BSON-документ. При испытании исследовательских систем производится сбор параметров с сотен датчиков. Каждый параметр имеет свою частоту записи. Частота записи некоторых параметров может совпадать. Поэтому для достижения требуемой скорости сохранения данных в БД параметры с одинаковыми частотами можно записывать за один кадр. Кадр – набор значений параметров, относящихся к одной временной отметке. Кроме этого будет использован буфер, который будет записывать все параметры (как набор кадров) в оперативную память, затем сохранять массив данных в БД.

Тестовое приложение разбито на фреймы структуры «Последовательность» (Sequence Structure). В первых фреймах проходит инициализация базы данных и подключение к необходимой коллекции. В последних проходит закрытие БД и вывод возникших ошибок. Между этими фреймами происходит генерация сигналов и формирование массива документов. Структура приложения показана на рис. 3.

vasen2.tif

Рис. 2. SubVI для создания BSON-документа

vasen3.tif

Рис. 3. Структура тестового приложения

vasen4.tif

Рис. 4. Формирование массива документов

Зависимость скорости записи от размера буфера

N

tо, мс

t1, мс

Примечания

Min tо, мс

Max tо, мс

1

11

11

Стабильная скорость записи

11

12

10

32,5

3,25

Небольшой разброс во времени

25

40

100

202

2,02

Редкие скачки Max tо > = 380

330

360

500

1125

2,25

Очень редко скачки Max tо < = 1160

1112

1138

1000

2724

2,724

После 25000 записей увеличивается частота скачков Max tо > = 2800. С увеличением количества записей величина при скачке увеличивается. При 70000 записей скачки Max tо > = 2900

2688

2760

 

Перед тем как сформировать выходной BSON-документ, необходимо создать объект типа BsonArray, который будет хранить документы с полученными значениями времени и физической величины. Далее происходит формирование случайных сигналов и их передача в SubVI, рассмотренный выше. SubVI возвращает ссылку на сформированный документ, который с помощью функции Add () у класса BsonArray добавляется в созданный ранее массив. Работа всех компонентов проходит в цикле. Регулируя количество итераций, изменяют количество величин параметров для внесения в БД. Функция Add () класса BsonArray возвращает ссылку на массив. Для того чтобы можно было обращаться к массиву, ему так же присваивается ключ. Полученная пара добавляется в BSON-документ, который заносится в БД. В кадрах модели были расположены компоненты, отсчитывающие время от начала работы каждого кадра, благодаря чему можно было рассчитать время записи одного сформированного документа в БД. На рис. 4 представлены компоненты, отвечающие за формирование массива для одного датчика.

Результаты работы представлены в таблице, где N – количество записанных величин параметра, t0 – общее время записи, Min t0 – минимальное наблюдаемое время записи, Max t0 – максимальное наблюдаемое время записи.

Таблица отражает зависимость скорости записи параметров от размера буфера. Изменяя размер буфера, можно добиться требуемой скорости записи.

Заключение

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


Библиографическая ссылка

Васнев Н.В., Шмидт И.А. СИСТЕМА РЕГИСТРАЦИИ ПАРАМЕТРОВ ИСПЫТАНИЙ СЛОЖНЫХ ИЗДЕЛИЙ НА ОСНОВЕ ДОКУМЕНТНО-ОРИЕНТИРОВАННОЙ БАЗЫ ДАННЫХ // Фундаментальные исследования. – 2016. – № 11-3. – С. 500-504;
URL: http://www.fundamental-research.ru/ru/article/view?id=41005 (дата обращения: 29.01.2020).

Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»
(Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления)

«Фундаментальные исследования» список ВАК ИФ РИНЦ = 1.074