Подсистемы регистрации параметров являются важной частью систем испытаний сложных изделий. Развитые системы испытаний могут регистрировать 100–500 параметров, при частоте их регистрации до 200 Гц [1]. Испытания при этом могут идти несколько часов. Качество таких подсистем определяется несколькими свойствами: отказоустойчивостью, долговечностью, скоростью записи, а также удобством извлечения и визуализации полученных данных.
Рассмотрим применяющийся в настоящее время способ сохранения информации при проведении испытаний газотурбинных установок газоперекачивающих агрегатов (ГТУ ГПА). Физические и «датчиковые» значения замеренных параметров (тренды) записываются во время испытаний в двоичный «плоский» файл. Для организации хранимых данных такой системы используется структура (совокупность таблиц), описывающая каждый из регистрируемых параметров, которая называется паспорт испытания. Паспорт испытания хранится в РСУБД, он содержит полное описание для каждого, измеряемого при испытаниях, параметра (см. рис. 1), в том числе: смещение для параметра относительно начала записи, характеристику канала измерения, включая тарированную характеристику и т.д. Идентификация испытания проходит по имени двоичного файла, в котором закодированы дата и номер испытания. Такая структура хранения показывает довольно высокую скорость записи, но при этом низкий уровень надежности. В целом способ является слабо гибким, т.к. отсутствуют высокоуровневые способы поиска информации, а также нет возможности сопоставлять результаты различных испытаний (они хранятся в разных файлах).
Для повышения уровня надежности и гибкости системы регистрации параметров испытаний естественно вместо набора двоичных файлов использовать базу данных. Таким образом, встает задача выбора базы данных и разработки методики сохранения регистрируемых параметров в выбранную БД.
Рис. 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.
Рис. 2. SubVI для создания BSON-документа
Рис. 3. Структура тестового приложения
Рис. 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 необходимо задействовать для того, чтобы получать значения физических величин с датчиков и записывать их в БД. Изменяя размер буфера, можно изменять скорость записи данных.