Scientific journal
Modern high technologies
ISSN 1812-7320
"Перечень" ВАК
ИФ РИНЦ = 1,279
DATA WAREHOUSE PROJECT FOR FANS SELECTION ACCORDING TO THEIR OPERATING CONDITIONS IN THE VENTILATION SYSTEM
Введение
Современные здания все чаще оснащаются вентиляционными системами для обеспечения комфортных условий проживания и работы. Основным элементом такой системы является вентилятор – прибор, назначением которого является перемещение воздушных масс, циркуляция которых происходит за счет разности между входным и выходным давлением. При осуществлении выбора вентилятора учитывается множество параметров, определяющих функционирование, назначение и условия эксплуатации; способ монтажа и подключения к электроприводу, а также его технические характеристики [1]. К последним следует отнести: класс защиты IP, производительность, уровень создаваемого давления, класс энергопотребления, шумовые характеристики и температуру перемещаемой среды.
Значения большинства указанных параметров определяются особенностями конструкции вентиляторов. Их можно классифицировать на пять типов: осевые, диагональные, центробежные, тангенциальные и безлопастные, а по условиям работы – на два типа: общего и особого назначения (пыле-, термо-, дымо-, взрывозащищенные). Таким образом, при проектировании принудительной вытяжки либо приточной вентиляции необходимо учитывать большое число параметров [2]. Кроме того, подбор оборудования производится индивидуально исходя из конкретных характеристик объекта (планировки и площади помещений, внутреннего объема и температуры воздуха, протяженности и формы воздуховода), где планируется его установка [3, 4]. Поэтому вопрос предоставления инструмента автоматизированного выбора правильного вентилятора и его комплектующих, при учете еще и стоимостных показателей, а также климатических факторов внешней среды, является весьма актуальным. Основным критерием такого выбора определен минимум расстояния до идеальной точки, где в качестве координат идеальной точки выступают значения параметров системы вентиляции, полученные по результатам расчета при ее проектировании.
Цель исследования – предоставление возможности проектировщикам автоматизировать процесс подбора вентиляторов на основе полученных расчетных данных, для повышения эффективности их работы посредством разработки хранилища данных.
Правильно спроектированная и настроенная система регулирования воздуха приточно-вытяжной вентиляционной установки позволяет достичь оптимального баланса между энергопотреблением и качеством поддержания заданных параметров внутри помещения [5].
Материалы и методы исследования
Согласно существующей практике подбор вентиляционного оборудования производится вручную на основе данных каталога производителя, расчет всех параметров которого выполнен при учете нормальных условий его работы.
Эффективность системы вентиляции зависит от множества показателей, расчетные значения некоторых из них определяются по формулам, представленным в табл. 1.
Высокий КПД означает, что вентилятор эффективно работает в системе, а потребляемая мощность будет минимальной при заданном объеме воздуха [6]. Аэродинамический КПД определяет, насколько эффективно воздушный поток передается через систему без значительных потерь давления. Если его значение низкое, то потребуется больше энергии для преодоления сопротивления воздушного потока, что приведет к увеличению потребляемой мощности вентилятора [7, 8].
Правильно подобранный вентилятор способствует не только качественной работе всей системы в целом, но и снижению потребляемой энергии. В связи с этим для принятия верного решения нужно обрабатывать большие массивы информации (нормативную документацию СП, ГОСТ, СНиП, каталоги и паспорта производителей). Предпочтение при решении данной задачи отдается созданию хранилища данных, поскольку для эффективного выполнения аналитики требуется хранилище [9], которое разрабатывается как слой поверх другой базы или баз данных. Оно компонует все эти данные и создает слой, оптимизированный для быстрой и простой аналитики.
Таблица 1
Расчетные формулы режимов работы вентилятора
|
Критерии подбора |
Формула расчета |
Параметры |
|
КПД вентилятора на рабочем режиме |
η = (Pv∙Q) / N |
Pv – полное давление вентилятора (Па), Q – производительность вентилятора (м3/ч), N – мощность, потребляемая вентилятором (кВт) |
|
Аэродинамические характеристики |
Давление: Pv = Psv + Pdv Расход: Q = V / t |
Psv – статическое давление вентилятора (Па), Pdv – динамическое давление (Па), V – объем пропускаемого воздуха, t – интервал времени |
|
Потребляемая мощность из электрической сети |
N = (Q∙ρ) / η |
Q – производительность вентилятора (м3/ч), ρ – плотность перемещаемого воздуха (кг/м3), η – КПД вентилятора в рабочем режиме |
Примечание: составлена авторами на основе полученных данных в ходе исследования.
Таблица 2
Сравнительная таблица базы и хранилища данных
|
Параметр |
База данных |
Хранилище данных |
|
Типы |
Существуют различные типы баз данных, но этот термин обычно применяется к базе данных программы OLTP |
Хранилище данных – это база данных OLAP, поверх OLTP или других баз данных для выполнения аналитики |
|
Сходство |
Обе системы OLTP и OLAP хранят и управляют данными в виде таблиц, столбцов, индексов, ключей, представлений и типов данных и используют SQL для запроса данных |
|
|
Использование |
Обычно ограничивается одной программой: одна программа – это одна база данных. OLTP позволяет быстро обрабатывать транзакцию в режиме реального времени |
Сохраняет данные для любого количества приложений и баз данных. OLAP позволяет организовать один источник информации, используемой для анализа и принятия решения |
Примечание: составлена авторами на основе полученных данных в ходе исследования
В отличие от базы, организованной для хранения, доступа и поиска информации, хранилище объединяет копии данных транзакций из различных исходных систем и предоставляет их для аналитического использования [10]. Сравнение баз и хранилищ данных приведено в табл. 2.
Операционные онлайн-системы баз данных, выполняющие транзакции и обработку запросов в реальном времени, следует отнести к системам (Online Transaction Processing (OLTP)). В целом системы OLTP предоставляют исходные данные в хранилища, в то время как системы OLAP помогают их анализировать [11, 12]. Основной упор для систем OLTP делается на очень быстрой обработке запросов, поддержании целостности данных в средах с доступом многих клиентов и эффективности, измеряемой количеством транзакций в секунду.
Системы же, способные упорядочивать информацию и представлять ее в разных форматах в соответствии с потребностями пользователей, – это системы онлайн-аналитической обработки OLAP [13]. OLAP характеризуется относительно небольшим объемом транзакций. Запросы часто очень сложны и подразумевают агрегацию. Для систем OLAP мерой эффективности является время отзыва. В этой базе имеются агрегированные исторические данные, хранящиеся в многомерных схемах. Поскольку OLAP работает с такими большими наборами данных, она сильно загружает пропускную способность центрального процессора (ЦП) и диска, поэтому использование хранилища устранит нагрузку на производительность, которую аналитика создаст для транзакционной системы.
Данные, внесенные в хранилище, обладают следующими характеристиками:
‒ предметно-ориентированность – данные логически организованы вокруг основных предметов организации, например клиентов;
‒ интегрированность – все данные о предмете объединены и могут быть проанализированы вместе;
‒ сменность во времени – исторические данные хранятся в подробной форме;
‒ энергонезависимость – данные доступны только для чтения, они не изменяются пользователями.
Результаты исследования и их обсуждение
В ходе проведенного исследования составлена схема процессов загрузки и извлечения данных из хранилища (рис. 1). Данные поступают от поставщиков, в качестве которых выступают датчики температуры перемещаемой и наружной среды. Вся информация фиксируется в реальном времени, что позволяет сформировать операционные базы данных с рабочими характеристиками вентиляторов. Сохраненные данные считываются с оборудования и благодаря процессам извлечения информации передаются в хранилище.
Для представления логических связей между процессами и объектами данных на рис. 2 приведена диаграмма потока данных в нотации DFD. Элементы диаграммы ведут непосредственно к физическому проектированию, где процессы соответствуют программам и процедурам, внешние сущности – системам, из которых поступают или куда поступают данные, а хранилища данных – объектам, файлам и базам данных.
Рис. 1. Схема процессов загрузки и извлечения данных из хранилища Примечание: составлен авторами по результатам данного исследования
Рис. 2. Диаграмма потока данных Примечание: составлен авторами по результатам данного исследования
Разработка проекта хранилища данных проведена в шесть этапов.
1. Анализ требований. На этом этапе осуществлен сбор требований и анализ данных для уточнения. Выполнен подробный обзор имеющейся информации о совокупности параметров, определяющих условия работы вентиляторов, и ознакомление с существующими базами данных. Этап завершен после просмотра результатов и утверждения.
2. Планировка. На этапе планирования проведено определение целей и задач, стоящих перед разработкой проекта хранилища данных, а также создание плана его реализации [14].
3. Проектирование. На данном этапе разработан проект архитектуры и создана структура модели данных (рис. 3). Концепция отражает структуру информации, хранящуюся в базе данных. На модели данных первичные ключи обозначены символом (
), внешние ключи названы в формате <ИмяРодительскойТаблицы>_id. Связи между таблицами отражают зависимость «один ко многим», где сторона «один» представлена одинарным входом в родительскую таблицу (
), а сторона «многие» – символом вороньей лапки (
).
4. Реализация. Реализация начинается с написания скриптов для создания операционной базы и хранилища данных. Построены алгоритмы процедур миграции в хранилища и запросы для работы с данными, а также функция архивирования [15, 16]. Развертывание хранилища проводится в облачной среде для предоставления при необходимости возможности гибкого масштабирования и безопасного доступа к данным из любого места [17, 18].
5. Тестирование. На этапе тестирования заполняется база данных и проверяется работоспособность миграции, запросов и архивирования.
6. Завершение проекта. Заключительный этап разработки завершается оформлением отчетной документации и приемом-передачей проекта хранилища данных.
Для реализации и тестирования был установлен сервер MariaDB версии 10.6 вместе с клиентом управления базами данных HeidiSQL. Затем база была наполнена тестовыми данными для дальнейшей разработки. Хотя наполнение хранилища происходит еженедельно, в то же время есть данные, которые должны попадать в хранилище после добавления в базу, что обеспечивает единообразие идентификаторов в базе и хранилище для более простого манипулирования данными.
Рис. 3. Структура модели хранилища данных Примечание: составлен авторами по результатам данного исследования
В каждой функции создаются временные таблицы Create temporary table. В этом случае создание временных таблиц, продолжительность жизни которых равна только текущему сеансу, очень полезно. Они пригодятся при выполнении множества запросов к особо обширной таблице. Вместо того, чтобы повторно выполнять все запросы в большую таблицу, можно создать временную и затем выполнять запросы в нее. Также временные таблицы, использованные в функциях, характеризуются тем, что они созданы с использованием объединений Join, поэтому работа с временной таблицей более удобна.
Для архивирования данных из хранилища используется .CSV файл. Невозможно создать скрипт автоматического архивирования, используя только язык структурированных запросов (SQL). Поэтому существует несколько способов решения этой задачи: архивировать данные вручную или автоматизировать этот процесс, используя PHP. Для сохранения данных необходимо сделать выборку из хранилища и просто передать полученный массив в функцию export_to_csv.
Для развертывания в облачной среде была выбрана облачная платформа Amazon Web Services (AWS) и веб-сервис Amazon Relational Database Service (Amazon RDS) для работы с реляционными базами данных в облаке. RDS отличается гибким масштабированием и экономичностью емкости.
Необходимо выбрать систему управления базами данных и ее версию. RDS предлагает выбор Amazon Aurora, MySQl, PostgreSQL, Oracle и Microsoft SQL Server. Вместе с системой следует выбрать ее версию. Далее в настройках указывается название базы и параметры входа (имя и пароль) главного пользователя.
Amazon RDS управляет резервным копированием, предоставляет услугу автоматического обнаружения сбоев и восстановления в случае их возникновения. Можно либо включить автоматическое резервное копирование для восстановления базы данных, либо производить его вручную. Процесс обновления RDS работает надежно и эффективно. RDS поддерживает автоматическое масштабирование и обеспечивает большой объем работы.
Для обеспечения целостности были использованы стандартные инструменты СУБД, такие как декларативные ограничения целостности и триггеры, вызываемые при модификации данных. Контроль доступа к сервисам и ограничение уровня разрешений для каждой задачи значительно снизит вероятность атаки изнутри организации. Для защиты данных можно использовать сервис AWS Secrets Manager и политику управления идентификацией и доступом (IAM), чтобы доступ получали только авторизованные пользователи.
В качестве примера расчета «расстояния до идеальной точки» для конкретных моделей вентиляторов продемонстрирована работоспособность представленной модели посредством сравнения характеристик реального вентилятора с целевыми параметрами системы вентиляции (табл. 3).
Эти значения получены из расчета сети воздуховодов, требуемого воздухообмена и ограничений по энергоэффективности (табл. 4).
Нормализованное отклонение характеристики X для каждой модели:
. dX = |Xфакт – Хид| / Хид
Результаты расчета представлены в табл. 5.
Взвешенное евклидово расстояние до идеальной точки:
Dвзв = 
,
где wi – весовой показатель i-й характеристики вентилятора, полученной при использовании метода экспертных оценок.
Расчет для модели C (табл. 6):
Dвзв(С) = 
Таблица 3
Целевые параметры системы вентиляции
|
Параметр |
Обозначение |
Идеальное значение |
|
Производительность |
Qид |
5000 м³/ч |
|
Полное давление |
Pv,ид |
600 Па |
|
КПД |
ηид |
0,75 |
|
Потребляемая мощность |
Nид |
1,8 кВт |
|
Уровень шума |
Lид |
55 дБА |
Примечание: составлена авторами на основе полученных данных в ходе исследования.
Таблица 4
Характеристики моделей вентиляторов
|
Модель |
Q (м³/ч) |
Pv (Па) |
η |
N (кВт) |
L (дБА) |
|
A |
4800 |
620 |
0,72 |
1,90 |
58 |
|
B |
5100 |
590 |
0,74 |
1,85 |
57 |
|
C |
4950 |
605 |
0,76 |
1,78 |
56 |
|
D |
4700 |
630 |
0,70 |
2,00 |
59 |
|
E |
5050 |
595 |
0,73 |
1,82 |
54 |
Примечание: составлена авторами на основе полученных данных в ходе исследования.
Таблица 5
Отклонения характеристик вентиляторов от целевых значений
|
Модель |
dQ |
dP |
dη |
dN |
dL |
|
A |
0,0400 |
0,0333 |
0,0400 |
0,0556 |
0,0545 |
|
B |
0,0200 |
0,0167 |
0,0133 |
0,0278 |
0,0364 |
|
C |
0,0100 |
0,0083 |
0,0133 |
0,0111 |
0,0182 |
|
D |
0,0600 |
0,0500 |
0,0667 |
0,1111 |
0,0727 |
|
E |
0,0100 |
0,0083 |
0,0267 |
0,0111 |
0,0182 |
Примечание: составлена авторами на основе полученных данных в ходе исследования.
Таблица 6
Итоговая таблица для проектировщика
|
Модель |
Q |
Pv |
η |
N |
L |
Dвзв |
Рекомендация |
|
B |
5100 |
590 |
0,74 |
1,85 |
57 |
0,00972 |
★ ВЫБОР |
|
E |
5050 |
595 |
0,73 |
1,82 |
54 |
0,00978 |
Альтернатива |
|
C |
4950 |
605 |
0,76 |
1,78 |
56 |
0,01212 |
Запасной вариант |
|
A |
4800 |
620 |
0,72 |
1,90 |
58 |
0,02207 |
Не оптимально |
|
D |
4700 |
630 |
0,70 |
2,00 |
59 |
0,04289 |
Исключить |
Примечание: составлена авторами на основе полученных данных в ходе исследования.
Результаты сравнительного анализа пяти моделей вентиляторов с применением взвешенного евклидова расстояния до идеальной точки показали, что наилучшее соответствие проектным параметрам обеспечивает модель B (Dвзв = 0,00972), которая имеет высокий КПД (0,74), производительность (5100 м³/ч), близкую к требуемой (5000 м³/ч), и умеренное энергопотребление (1,85 кВт). Модель E (Dвзв = 0,00978) является близкой альтернативой, предпочтительной в условиях повышенных требований к акустическому комфорту. Модели A и D (Dвзв > 0,022) не рекомендуются к применению из-за существенных отклонений по совокупности параметров. Таким образом, предложенная методика на основе разработанного хранилища данных позволяет автоматизировать обоснованный выбор вентилятора с учетом заданных приоритетов (КПД, энергопотребление, производительность) и снизить нагрузку на проектировщика.
Заключение
Созданное централизованное хранилище данных выступает в качестве информационного ресурса, предоставляющего возможность проектировщику произвести автоматизированный выбор наилучшего варианта вентилятора для системы вентиляции конкретного объекта. Предпочтение при этом отдается тем моделям оборудования, совокупность характеристик которого наиболее близка к идеальной точке, соответствующей расчетным проектным параметрам, а также позволяющим достичь оптимального баланса между энергопотреблением и качеством поддержания заданных параметров внутри помещений. Полученную информацию следует предоставлять через отдельные витрины данных для того, чтобы каждый проектировщик, выступающий в качестве пользователя, имел к ней доступ.
Таким образом, в ходе данного исследования:
‒ определены конструктивные, технические и эксплуатационные характеристики энергоэффективности вентиляторов, положенные в основу модели хранилища данных;
‒ проведен анализ предметной области и выделен ключевой критерий выбора вентиляторов для системы вентиляции конкретного объекта;
‒ разработаны процессы и программный код для процедур загрузки-выгрузки данных в хранилище.
Для развертывания базы и хранилища данных была выбрана облачная платформа и веб-сервис с учетом параметров защиты, доступности и эффективности.
Conflict of interest
Financing
Библиографическая ссылка
Соболева В. В., Садчиков П. Н., Дейнега Н. В. ПРОЕКТ ХРАНИЛИЩА ДАННЫХ ДЛЯ ПОДБОРА ВЕНТИЛЯТОРОВ В СООТВЕТСТВИИ С УСЛОВИЯМИ ИХ РАБОТЫ В СИСТЕМЕ ВЕНТИЛЯЦИИ // Современные наукоемкие технологии. 2026. № 4. С. 140-147;URL: https://top-technologies.ru/en/article/view?id=40740 (дата обращения: 10.05.2026).
DOI: https://doi.org/10.17513/snt.40740