Глава диплома по программированию на тему Разработка информационно-аналитической системы анализа и прогнозирования температуры воздуха для фрикулинг систем в дата-центрах

Фрикулинг-системы в дата-центрах используют более прохладный наружный воздух для охлаждения оборудования, что предоставляет возможность сократить энергопотребление и издержки в сравнении с классическими системами охлаждения. Система функционирует благодаря получению наружного воздуха через фильтры, подачи его в холодный коридор, прохождения через стойки с серверами, где воздух нагревается, а далее либо выводится наружу, либо смешивается с внешним воздухом для поддержания стабильной температуры. Подобная технология экономит энергию, поскольку не требует функционирования компрессоров и холодильных машин, при этом эффективность зависит от температуры окружающей среды [3, 40].
Для подобных систем необходимо разработать информационно-аналитическую систему, целью которой является анализ и прогнозирование внешней температуры воздуха. В первую очередь, необходимо представить функциональные требования.
Требования к сбору данных:
1) система должна обеспечивать автоматический сбор метеорологических данных (температура воздуха) из не менее чем одного внешнего погодного API с настраиваемой периодичностью (например, раз в час);
2) система должна поддерживать подключение и сбор данных с локальных температурных датчиков, установленных на территории ЦОД, по стандартным протоколам (например, через HTTP запросы или чтение из файла);
3) администратор системы должен иметь возможность добавлять, настраивать и удалять источники данных через пользовательский интерфейс.
4) система должна создавать резервную копию данных.
Требования к обработке и хранению данных:
1) все поступающие данные о температуре должны сохраняться в базе данных временных рядов для последующего анализа и использования в моделях прогнозирования;
2) система должна выполнять предварительную обработку данных, включая очистку от аномальных значений и заполнение пропусков (например, методами интерполяции);
3) система должна хранить историю прогнозов для их последующего сравнения с фактическими данными и оценки точности моделей;
4) система должна создавать резервную копию критических данных.
Требования к анализу исторических данных:
1) система должна рассчитывать и отображать следующие статистические показатели за заданный регламентом период: минимальная, максимальная и средняя температура;
2) система должна рассчитывать и отображать общее количество часов и процент времени, в течение которого температура находилась ниже или выше заданных пользователем пороговых значений для фрикулинга.
Требования к прогнозированию температуры:
1) система должна реализовывать функцию прогнозирования внешней температуры воздуха на основе модели глубокого обучения.
2) система должна генерировать почасовой прогноз температуры на неделю вперед;
3) результаты прогноза должны быть представлены в виде графика и таблицы с рекомендациями по переключению режимов. На графике должны быть визуально отмечены периоды, подходящие для активации режима фрикулинга.
Требования к пользовательскому интерфейсу и визуализации:
1) система должна предоставлять веб-интерфейс для взаимодействия с пользователями;
2) доступ к системе должен быть защищен механизмом аутентификации (логин и пароль);
3) система должна реализовывать ролевую модель доступа: «Инженер по эксплуатации» (доступ к функциям просмотра) и «Администратор» (полный доступ, включая настройки);
4) интерфейс должен быть интуитивно понятным и содержать интерактивные графики для визуализации временных рядов и прогнозов.
Функциональная модель TO-BE (IDEF0).
Система представляет собой информационно-аналитическую систему анализа и прогнозирования внешней температуры воздуха для фрикулинг-систем в дата-центрах.
Далее описаны контекстная диаграмма уровня A0, декомпозиция верхнего уровня A0 с подробным описанием каждой функции, подфункций и трассировка функций на ранее описанные функциональные требования.
A0 (Контекстная диаграмма — уровень «функция системы»)
Функция (верхнего уровня): анализ, прогнозирование и разработка рекомендаций по применению режима фрикулинга на основании внешней температуры воздуха.
IDEF0 блок (A0):
Входы (I):
- внешние погодные сведения (погодный API, периодические запросы);
- локальные показания температурных датчиков дата-центра;
- настройки порогов / политик (пользовательские);
- исторические данные / архив.
Управление (C):
- политики безопасности и доступа (аутентификация, управление доступов на основе ролей);
- регламенты обработки и хранения данных (сохранение, резервное копирование);
- параметры моделей (частота обучения, гиперпараметры);
- соглашение об уровне обслуживания и требования точности/времени ответа.
Механизмы (M):
- инфраструктура: серверы/контейнеры, базы данных временных рядов, объектное хранилище;
- компоненты программного обеспечения: модуль получения данных, ETL, ML-pipeline, развёртывание модели, пользовательский веб-интерфейс, сервис резервного копирования;
- операторы / администраторы.
Выходы (O):
- почасовой прогноз температуры на неделю (таблица с графиком);
- рекомендации по включению/выключению фрикулинга (значки, временные окна);
- статистическая отчётность и история прогнозов;
- уведомления/журналы и резервные копии данных.
A0 — декомпозиция верхнего уровня (пять главных функций):
A1 — сбор и управление источниками данных;
A2 — обработка, очистка и сохранение данных;
A3 — анализ исторических данных и отчёты;
A4 — прогнозирование температуры (глубокое обучение) и хранение прогнозов;
A5 — интерфейс, управление доступом, рекомендации и резервное копирование.
На рисунке 1 представлена контекстная диаграмма A0.
Далее представлены подробные описания каждой функции.
A1 — Сбор и управление источниками данных.
Цель — обеспечить автоматизированный надёжный сбор метеорологических данных из внешних API и локальных датчиков, а также управление перечнем источников посредством пользовательского интерфейса.
Входы: перечень конфигурируемых источников, расписание сбора, подключения от датчиков, запросы администратора.
Управление: политики частоты опроса, повтор/интервал задержки, форматы данных (JSON / CSV), аутентификация API-ключей.
Механизмы: модуль получения данных (адаптеры для внешнего API, локальных сенсоров), очерёдность сообщений/брокер (Kafka / MQTT), контроллер пользовательского интерфейса администрирования источников.
Выходы: поток необработанных данных передаётся в очередь, запись логов событий подключения/ошибок; уведомления об ошибках.
A1.1 — Интегратор внешних погодных API
Автоматический опрос (заданная периодичность, к примеру, каждый час).
Поддержка нескольких API (при падении одного — переключение/резервный план).
Проверка соответствия схемы ответа (реестр схем данных).
A1.2 — Сбор с локальных датчиков
Поддержка HTTP-уведомлений, периодических HTTP GET, чтения локальных файлов / CSV, адаптеров OPC-UA/MQTT.