Введение

Рост числа подключённых устройств в жилом фонде и появление разнотипных протоколов обмена данными усиливают потребность в вендоронезависимых платформах управления инженерной инфраструктурой многоквартирных домов. Классические монолитные решения с привязкой к одному производителю ограничивают масштабирование и повышают совокупную стоимость владения. В ответ на эти вызовы в работе рассматривается прототип платформы «Умный дом», опирающийся на открытые стандарты и микросервисную архитектуру, что позволяет объединять датчики и актуаторы различных вендоров и строить единое информационное пространство для телеметрии и управления.

Практическая ценность системы заключается в автоматизации типовых бытовых сценариев: поддержании комфортной температуры, отключении освещения при отсутствии жильцов, обесточивании неиспользуемых силовых линий при запирании входной двери, а также в возможностях диспетчеризации и аналитики потребления ресурсов. Архитектурная основа решения включает шлюз на Raspberry Pi, брокер MQTT, адаптер MQTT2HTTP, прикладные REST-сервисы и хранилище PostgreSQL/TimescaleDB, поверх которых реализованы веб-клиент (PWA) и тонкий мобильный клиент.

Целью исследования является оценка эксплуатационной готовности прототипа к опытной эксплуатации в ограниченном контуре. Для этого проведены предварительные комплексные испытания, охватывающие функциональную корректность, интеграцию компонентов, производительность под нагрузкой, устойчивость к отказам и базовые аспекты информационной безопасности. Испытания выполнялись в соответствии с требованиями проектной документации и практиками испытаний автоматизированных систем, в том числе в рамках положений ГОСТ Р 59795–2021 и ГОСТ Р 59792–2021.

Научно-практический вклад работы состоит в: (1) демонстрации воспроизводимого подхода к сквозной верификации IoT-платформы в условиях гетерогенной предметной области; (2) фиксации количественных ориентиров производительности и восстановления после отказов для стендовой конфигурации; (3) формализации ограничений текущей версии (RBAC/MFA, идемпотентность приёма) и определении направлений дальнейшего развития. Раздел «Методы» излагает методику и охват испытаний, «Результаты» фиксируют ключевые показатели и их интерпретацию, в «Заключении» подводятся итоги готовности прототипа и намечаются дальнейшие шаги.

Методы

Методологический замысел исследования строился как последовательная оценка готовности прототипа «Умный дом» к опытной эксплуатации. Мы связывали типичные сценарии многоквартирного дома (сбор показаний, исполнение команд, автоматизация правил) с наблюдаемыми метриками качества — временем отклика, устойчивостью при нагрузке, корректностью безопасности и восстановлением после сбоев. Основанием служили практики испытаний для микросервисных систем и требования профильной документации проекта.

Архитектурный контекст (кратко) . Система реализована по схеме Edge–Middleware–Storage–UI. На краю (Raspberry Pi) датчики и актуаторы публикуют сообщения в MQTT; адаптер MQTT2HTTP переводит события в REST-эндпоинты прикладного слоя; данные сохраняются в PostgreSQL (с поддержкой временных рядов), а интерфейсы PWA/мобильного клиента обеспечивают наблюдение и управление. Такой контекст определяет «сквозную трассу» данных, по которой и проводились испытания: от публикации телеметрии до отображения в UI и обратной команды на устройство.

Дизайн и охват испытаний . Набор проверок объединял четыре класса тестов: модульные, интеграционные, нагрузочные и проверки безопасности. Карта покрытия показывает, какие микросервисы попадают в каждую категорию и где сосредоточены приоритеты (см. рисунок 1). Отдельно контролировались сценарии с участием шлюза, адаптера MQTT2HTTP, регистра устройств, API-шлюза, а также сервисов аутентификации и уведомлений.

Нагрузочные профили . Для имитации суточной динамики дома применялись два профиля потока телеметрии:

а) «ступенька» (последовательное повышение интенсивности), чтобы зафиксировать точку начала деградации;

б) «пила» (регулярные колебания), чтобы проверить удержание метрик при переменной активности.

Максимальная интенсивность публикаций доводилась до значения, реалистичного для стендовой конфигурации. Для REST-API использовалась смесь операций чтения и записи, близкая к ожидаемой эксплуатации; генераторы нагрузки размещались на отдельных узлах, предусматривался короткий прогрев.

Метрики и критерии . Для API отслеживались среднее время отклика и квантильные показатели (p95/p99), а также доля ошибок. Для телеметрии контролировались скорость приёма, отсутствие потерь и повторов (с учётом QoS), стабильность при длительном прогоне. Базовыми критериями приёмки считались: допустимое p95 для пользовательских операций, устойчивый приём заданного потока сообщений и успешная работа в длительном прогоне без ошибок.

Безопасность и отказоустойчивость . Проверки безопасности включали подтверждение наличия шифрования на внешних интерфейсах, корректной обработки токенов и отсутствия передачи секретов в открытом виде; минимальная ролевая модель использовалась для валидации доступа к защищённым эндпоинтам. Отказоустойчивость оценивалась через контролируемые сбои (останов брокера, недоступность БД, разрыв связи на Edge) с измерением времени восстановления и проверкой согласованности данных после возврата в нормальный режим.

Инструментирование и воспроизводимость . Системные и прикладные метрики (нагрузка CPU/RAM, очереди брокера, задержки API, показатели СУБД) собирались и визуализировались на единой панели мониторинга. Конфигурации сервисов и профили тестов зафиксированы в артефактах испытаний, что позволяет повторить прогоны на сопоставимом оборудовании и сверить полученные значения.

Ограничения . Результаты относятся к стендовой конфигурации прототипа и синтетическому профилю телеметрии; расширенные механизмы разграничения прав и MFA учитывались как ограничение текущей версии и выносятся в план последующих работ.

Рис. 1. Карта тестового покрытия микросервисов по типам испытаний

Диаграмма отражает распределение модульных, интеграционных, нагрузочных и security-проверок по ключевым компонентам (шлюз, MQTT2HTTP, реестр устройств, аутентификация/доступ, API, уведомления, аналитика).

Результаты

В этом разделе приведены наблюдаемые эффекты и численные показатели по каждому классу испытаний, сформулированных в «Методах». Подача следует «сквозной трассе» системы: от функциональной корректности и интеграции — к производительности, отказоустойчивости и безопасности. Для удобства сводные значения сведены в таблицу 1; распределения задержек и времена восстановления показаны на рисунках 2 и 3 соответственно. Напомним, состав и охват тестов суммированы на карте покрытия (см. рисунок 1 в разделе «Методы»).

Функциональные испытания . Все заявленные сценарии (регистрация/учёт устройств, приём телеметрии, визуализация, исполнение команд, базовые правила автоматизации) выполнены успешно: 220/220 (100 %). Критических дефектов не выявлено; четыре некритических замечания устранены до повторного прогона. Повторная регрессия — 100 % успешности.

Интеграционные проверки и целостность данных . Взаимодействия MQTT ↔ MQTT2HTTP ↔ REST-API ↔ БД отработали штатно (100/100 прогонов). Нарушений согласованности не зафиксировано; при кратковременных разрывах связи буферизация на Edge и QoS≥1 обеспечивали доставку без потерь. Дубликаты сообщений в операционных срезах не обнаружены; для промышленных сборок рекомендована явная идемпотентность приёма по msgId/ts.

Производительность и устойчивость под нагрузкой . Поток телеметрии выдержан на уровнях, близких к эксплуатационным:

а) профиль «ступенька» устойчив до 120 msg/s без потерь; при 140–150 msg/s наблюдались единичные ретраи с последующей доставкой;

б) профиль «пила» (0–120 msg/s, период 5 мин, длительность 60 мин) не привёл к деградации p95.

Для REST-API при смешанной нагрузке 600 RPS (≈70 % чтения / 30 % записи) за 30 мин: среднее ≈ 820 мс, p95 ≈ 1 280 мс, p99 ≈ 1 900 мс, ошибок 5xx — 0 %. Ресурсные показатели на приложении: CPU 55–68 %, RAM 58–65 %. Распределения задержек и процентили показаны на рисунке 2.

Длительный прогон . Непрерывная работа в течение 8 часов (100 msg/s, фоновые запросы к API) — без аварий и накопления очередей; показатели latency в пределах допусков, утечек ресурсов не выявлено.

Отказоустойчивость и восстановление . Инъекции сбоев подтвердили требуемые характеристики восстановления: останов брокера — 11 мин, недоступность БД — 16 мин, сбой подсистемы бэкапов/переключение тома — 15 мин, среднее MTTR 13 мин при нормативе ≤ 60 мин. После восстановления зафиксирована полная доставка буферизованных сообщений и сохранение целостности в БД. Сводные значения по сценариям отказов приведены на рисунке 3.

Безопасность . Автоматизированные и ручные проверки подтвердили наличие шифрования на внешних HTTP-интерфейсах (TLS), корректную обработку JWT-токенов и отсутствие передачи секретов в открытом виде. По результатам сканирования: критические — 0, высокие — 0, средние — 2 (устранены). На защищённых эндпоинтах попытки эскалации прав корректно блокируются (403). Расширенная матрица RBAC и MFA в прототипе не активирована и рассматривается как ограничение текущей версии.

UI/PWA . Панели показаний и статусов отработали без сбоев; команды (вкл/выкл освещения, перевод в «эко-режим») исполнялись с подтверждением доставки. Ошибки коммуникации корректно визуализировались, механизм повторной отправки работал штатно.

Итоговая оценка соответствия критериям . Минимальные критерии приёмки выполнены (см. таблицу 1): p95 для пользовательских операций — в пределах допусков; устойчивый приём заданного потока телеметрии; успешный длительный прогон; базовые гарантии безопасности подтверждены. Оставшиеся ограничения касаются полноты RBAC/MFA и формализации идемпотентности приёма.

Таблица 1

Сводные результаты испытаний

Пояснение к таблице 1: при 150 msg/s фиксировались единичные ретрай с последующей доставкой (QoS≥1); потерь данных не наблюдалось.

Рис. 2. Распределение времени отклика REST-API при 600 RPS (среднее, p95, p99)

Рис. 3. Среднее время восстановления после сбоев по сценариям (MTTR)

Заключение

Проведённые испытания показали, что выбранная архитектура «Умного дома» — с разделением на край, прикладной слой и хранилище, а также с использованием адаптера MQTT2HTTP — обеспечивает устойчивый сквозной поток данных и предсказуемое поведение при типичных для многоквартирного дома сценариях. Система уверенно переносит изменения нагрузки и восстановление после контролируемых сбоев, сохраняя целостность данных и управляемость сервисов. В пользовательском контуре это выражается в стабильном отображении показаний и корректном выполнении команд без необходимости ручного вмешательства.

С практической точки зрения платформа подтверждает жизнеспособность вендоронезависимого подхода, разнородные датчики и актуаторы интегрируются без жёсткой привязки к одному производителю, а телеметрия накапливается в форме, удобной для последующего анализа и автоматизации. Наблюдаемая динамика задержек и поведение очередей указывает на достаточный резерв для расширения числа устройств в контуре опытной эксплуатации, при условии сохранения принятых режимов и политики мониторинга.

Ограничения текущей версии носят инженерный характер и очерчивают естественный план развития системы, детализация разграничения прав и включение многофакторной аутентификации, формализация идемпотентности приёма телеметрии, усиление наблюдаемости (журналы, трассировки, алертинг) и уточнение схем хранения временных рядов для промышленной сборки. Эти шаги не меняют общего вывода, прототип готов к опытной эксплуатации в ограниченном контуре и может служить основой для поэтапного наращивания функциональности и масштаба.

Литература:

1. ГОСТ Р 59795–2021. Информационные технологии. Комплекс стандартов на автоматизированные системы. Требования к содержанию документов. — М.: Стандартинформ, 2021. — 32 с.
2. ГОСТ Р 59792–2021. Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем. — М.: Стандартинформ, 2022. — 8 с.
3. ГОСТ 28195–89. Оценка качества программных средств. Общие положения. — М.: Издательство стандартов, 2001. — 39 с.
4. Apache JMeter: User’s Manual. — URL: https://jmeter.apache.org/usermanual/ (дата обращения: 29.10.2025).
5. OWASP Top 10:2021 — The Ten Most Critical Web Application Security Risks. — URL: https://owasp.org/Top10/ (дата обращения: 29.10.2025).
6. OPENVAS — Open Vulnerability Assessment Scanner. — URL: https://www.openvas.org/ (дата обращения: 29.10.2025).
7. Cypress — Fast, Easy and Reliable Testing for Anything That Runs in a Browser. — URL: https://www.cypress.io/ (дата обращения: 29.10.2025).
8. PostgreSQL 17 Documentation. — URL: https://www.postgresql.org/docs/ (дата обращения: 29.10.2025).
9. TimescaleDB — Hypertables (официальная документация). — URL: https://docs.tigerdata.com/use-timescale/latest/hypertables/ (дата обращения: 29.10.2025).
10. Eclipse Mosquitto — An Open Source MQTT Broker. — URL: https://mosquitto.org/ (дата обращения: 29.10.2025).
11. Grafana k6 — Documentation. — URL: https://grafana.com/docs/k6/latest/ (дата обращения: 29.10.2025).
12. OWASP Zed Attack Proxy (ZAP) — Official Site. — URL: https://www.zaproxy.org/ (дата обращения: 29.10.2025).