Ппаспорт_проекта_Группа_2_AIoT_2025_слайды_Женя_+_Андрей_+_Алексей

1. Платформа управления и обслуживания Умный свет

КУРС «ИСКУССТВЕННЫЙ
ИНТЕЛЛЕКТ
ДЛЯ ИоТ»
Платформа управления и
обслуживания Умный
свет
Группа № 2:
Элина Куринина
Алексей Шуплецов
Андрей Майоров
Евгений Черноморцев
Декабрь 2025

2. Описание проекта

3. Описание персон

Потребитель
Бизнес-заказчик
Имя: Иннокентий
Имя: Александр Иванович
Возраст: 38 лет
Возраст: 54 года
Занятие: старший специалист департамента городского
хозяйства, оператор
Занятие: руководитель департамента городского хозяйства
Говорит: город должен быть светлым и безопасным
Говорит: у меня очень много работы и мне нужно успеть
сделать отчёт и организовать работу бригад
Делает: балансирует бюджет на городское хозяйство,
отвечает за эффективность тарт на электричество и
расходы на содержание и обслуживание
Думает: как снизить затраты на электроэнергию без
потери качества
Делает: принимает отчёты, встречи с другими, отвечает за
движение денежных средств и выполнение бюджета. Проводит
встречи с другими департаментами, заседание с мэром,
оперативки, еженедельные отчёты наверх, приёмный день по
вторникам
Думает: как улучшить показатели департамента
Чувствует: усталость от отчётов
Чувствует: большая нагрузка, отчёты, высокие тарифы
ограничивают мою эффективность

4. Какую проблему решаем

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

5. Фреймворк для формулировки гипотезы решения проблемы

1
-С использованием нашей системы затраты на ЭЭ с
учётом поддержки и обслуживания снизятся на 30%
-В зоне где используется новая система ниже
аварийность в периоды слабой освещённости
-Система позволит закупать меньше оборудования
ЗИП
-Маршрут бригады обслуживания станет короче на
40%, выезды эффективнее, количество меньше
3
2
Мы верим, что:
И измерим:
Расходную часть на ЭЭ по сравнению со
стандартными схемами включения
Расходную часть на обслуживание (бригады, ГСМ,
аренда оборудование, среднее время занятости
бригады за период)
Расходную часть на подменный фонд под замену
оборудования
Для того, чтобы это проверить:
Строим математическую модель,
показывающую основные алгоритмы
управления светом с расчётом эффектов
Рассчитываем эффект ФЭМ
Проводим тестирование на тестовой
области
4
Мы окажемся правы, если:
Заявленный эффект экономии ЭЭ будет
достигнут и окупится за пять лет
Затраты на обслуживание снизятся на 20%

6. HADI цикл проверки гипотез

ПЛАН
ГИПОТЕЗА (H)
Мы верим, что внедрение
системы умного освещения с
датчиками движения и
освещённости снизит
потребление электроэнергии
на 30% по сравнению с
текущим режимом работы.
Мы верим, что система
прогнозного обслуживания
(predictive maintenance) снизит
время простоя фонарей на
50% за счёт предсказания
выхода из строя ламп и
датчиков.
Мы верим, что единый
интерфейс управления
освещением сократит время
на рутинные задачи (отчёты,
мониторинг) на 40% для
ДЕЙСТВИЕ (A)
Развернуть пилотную зону из
30 фонарей с IoT-датчиками и
системой управления.
Сравнить с контрольной
группой без умного
управления.
Внедрить алгоритм анализа
данных с датчиков (ток,
напряжение, температура) для
прогноза поломок.
Фиксировать все случаи
поломок и время их
устранения.
Внедрить веб-интерфейс для
управления и мониторинга.
Провести обучение
сотрудников. Замерять время,
затрачиваемое на задачи до и
ДАННЫЕ (D)
Показания счётчиков энергии
по пилотной и контрольной
группам.
1. Данные о срабатывании
датчиков движения.
2. Уровень освещённости в
разное время суток.
3. Тарифы на электроэнергию.
1. История отказов
оборудования.
2. Данные с датчиков
(термопара, ток,
напряжение).
3. Время реакции служб и
продолжительность
простоя.
4. Затраты на замену ламп и
ремонт.
1. Логи использования
системы.
2. Опросы сотрудников
(Иннокентий, Александр
Иванович).
3. Время на подготовку
отчётов до/после.
ВЫВОДЫ (I)
ДЕЙСТВИЕ
Верна, если экономия
составит ≥30%.
Неверна, если экономия
<20%.
Успех: Масштабировать на
весь район.
Неудача: Пересмотреть
алгоритмы работы датчиков
или выбрать другие типы
датчиков.
Верна, если среднее время
простоя снизилось на 50%.
Неверна, если снижение
<20%.
Успех: Интегрировать
систему в работу
аварийных служб.
Неудача: Дообучить
модель на больших данных
или добавить новые
параметры мониторинга.
Верна, если время на задачи
снизилось на 40%. Неверна,
если снижение <15%.
Успех: Развивать
интерфейс, добавить
мобильное приложение.
Неудача: Провести UXаудит и доработать

7. Метрики HEART

H
E
A
R
T
Happiness
Engagement
Adoption
Retention
Task Success
Цели
Цели
Цели
Цели
Цели
NPS диспетчеров >8, снижение
стресса от срочных вызовов на 70%
>75% бригад ежедневно
используют дашборд
>80% пользователей активны
после 90 дней
Снижение простоев на 50%,
оптимизация склада
Сигналы
Сигналы
85-95% сети фонарей
подключено за месяц
Сигналы
Сигналы
Сигналы
Удача:
Положительные отзывы о точности AI-предсказаний
(>90%), отсутствие ложных срабатываний
Провал:
Негативные отзывы, увеличение расходов на
обслуживание
Просмотр метрик
освещенности/погоды,
оптимизация маршрутов по AI
Легкая интеграция датчиков
(освещенность, влажность,
температура)
Переход на AI-планирование ТО
без возврата к рутине.
Предиктивные замены вместо
аварийных, оптимальные
маршруты.
Метрики
Метрики
Метрики
Метрики
Метрики
Ежемесячные опросы (5-балльная
шкала), время реакции на поломки
Длительность сессий (>10 мин/день), клики по
уведомлениям, частота проверок аналитики
% устройств в системе, среднее
время onboard (цель <2 дней),
успешные подключения/день
DAU/MAU >0.4, % бригад
использующих рекомендации,
churn rate <15%
% поломок по прогнозу, экономия
на выездах (40%), точность
запасных частей (±10%)

8. Обзор похожих решений

1. AWADA Systems
Что делает: Лидер комплексных решений "под ключ" для smart city. Специализируется на human-centric
lighting с IoT-управлением.
Системы и оборудование:
•Light Logic платформа — облачная IoT-система с диммированием, геозональным управлением, интеграцией с
погодой/камерами
•Умные контроллеры AWADA — встроенные в плафоны, поддержка Zigbee, LoRaWAN, NB-IoT
•LED-плафоны с датчиками — освещённость + движение, энергосбережение до 70%​
2. Econex
Что делает: Производитель оборудования и ПО для АСУНО, фокус на уличное освещение крупных сетей.
Системы и оборудование:
•Econex Outdoor/Smart — система диспетчеризации с телеметрией (ток, напряжение, яркость)
•Шлюзы и контроллеры — Powerline (PLC), радио (LoRa), поддержка до 10к устройств на сервер
•Умные реле и диммеры — для существующих плафонов без замены​
3. АСУНО "Гелиос"
Что делает: Импортозамещённая система управления от IVT/МЭИ, государственные тендеры и ЖКХ.
Системы и оборудование:
•АСУНО Гелиос 2.0 — SCADA-система с мониторингом 24/7, аварийные уведомления SMS/мобильное app
•Контроллеры КРУНО — проводные/беспроводные, датчики освещённости, ветра, температуры
•Умные шкафы управления — для районов по 5-10к фонарей
•ПО "Диспетчер" — маршрутизация бригад, учёт энергопотребления​

9. Ожидания заказчика

Ограничения проекта:
1.
Как отрабатываем
1.
Стоимость внедрения системы
2.
Ограниченный бюджет на внедрение, что не позволит реализовать полный
функционал и основные «фишки» проекта
3.
Срок окупаемости проекта
Ожидания заказчика:
2.
1.
Снижение эксплуатационных затрат
2.
Повышение эффективности работы системы освещения на основе предиктивной
аналитики – снижение времени простоя
3.
Оптимизация затрат на логистику и склад

10. Процесс

02
Процесс

11. Описание процесса

01
Вход процесса
02
Шаги процесса и кто их выполняет
1. Сигнал о неисправности системы освещения
2. Сигнал о наступлении срока планового обслуживания
3. Данные с датчиков освещенности, гигрометра и тп
1. Датчик по определенным параметрам определяет неисправность
2. Создает сообщение с исчерпывающей информацией для локализации аварии
3. Отправка сообщения на диспетчерский пульт и мобильным бригадам
1. Анализ предиктивной аналитикой данных о сроке наработки на отказ осветительного оборудования
2. Расчет срока плановой замены до наступления отказа оборудования
3. Создание заявки на склад на перемещение ТМЦ в нужную бригаду
4. Планирование маршрута бригады
03
Выходы процесса
1. Пульт диспетчера
2. Планшеты мобильных бригад
3. ТГ-бот
4. Склад
04
Каково число исполнителей в настоящее время?
1. N датчиков в текущий момент времени, сформировавшие сигнал о аварии
2. Оперативный персонал 1-5 человек
3. Сотрудники склада

12. Описание процесса

05
Объем информации
1. 1 датчик ~250 байт\сек
2. ~10000 сообщений в минуту от всех датчиков города
3. 5-10 событий в день

13. Как выглядит решение

Схема

14. Описание процесса

Как изменится стоимость процесса
в целевом состоянии?

15. Данные

03
Данные

16. Данные

За какой период
собраны данные?
За три года эксплуатации в разных климатических
зонах, несколько крупных и средних городов
Какой объем данных
накоплен? Количество
диалогов? Средняя
длительность?
Данные – состояние датчиков освещённости, гигрометры,
ВАХ с датчиков. Логи и журналы – события по выходу из
строя, обслуживание. Датчики отправляют по LoRaWAN,
резервный канал LTE. Общий объём 11Тбайт. ИИ только
cloud-решения, данные так же реплицируются в облако.
Группа устройств объединена в сегменты – районе, где на
местном уровне агрегируются данные и принимается
решение о диммировании по району – fog уровень. Edge
уровень не используется.
В каком виде
хранятся данные?
- основная СУБД ClickHouse
- кэш и дашборды: Redis + Elasticsearch
- метаданные PostgreSQL
Какие есть риски или
сложности с
доступом к данным?
- отсутствие резервирования
- отсутствие шифрования
- доступ к системе хранения

17. Данные

Какие типы
диалогов вы
выделяете?
Каково распределение
диалогов по языкам ?
Русский (100%)
Запрос данных (60%)
Уведомления (30%)
Отчёты (5%)
Накат ПО и конфигурирование (5%)
Каково
распределение числа
диалогов по этим
типам?
Приведите
несколько сложных
диалогов
"Почему в районе Х потребление
выросло на 15%?"
"Спрогнозируй замены ламп на
следующую неделю"

18. Технические характеристики

19. Тип задачи

Пример
классификация
кластеризация
сегментация
предсказание
и другие

20. Архитектура

21. ИТ-ландшафт

Уровень приложения
• Веб-интерфейс для управления
• Чат-бот (Telegram/веб)
• Мобильное приложение (опционально)
Уровень данных и аналитики
• Data Lake / Хранилище данных
• Аналитический модуль (прогнозы, отчёты)
• API для интеграции с другими системами города
Уровень связи и шлюзов
• Шлюзы LPWAN (LoRaWAN, NB-IoT)
• Резервированные каналы связи (4G/проводные)
• MQTT-брокер для обмена сообщениями
Уровень управления оборудованием
• Контроллеры линий (управляют группами фонарей)
• Контроллеры светильников (в каждом фонаре)
• Датчики (движение, освещённость, температура)

22. Требования к программному обеспечению

Операционная система
Ubuntu 24.04 LTS Server
Языки программирования
Core сервис: Go 1.23 Backend/ML Python 3.12 Frontend TypeScript React Дашборды
Grafana Scripts/DevOps Bash + PythonAnsible
Базы данных
Hot data InfluxDB 2.8 (timeseries) — метрики 1сек интервал Redis 7.4 (cache) — статус
устройств, сессии PostgreSQL 16 — метаданные + geo Cold data ClickHouse — аналитика
MinIO (S3) — raw логи, ML datasets (Parquet)
Использование докеров
Контейнеры организованы по микросервисам: docker-compose.yml (dev) → Kubernetes manifests (prod)
Сервисы: mqtt-broker (Eclipse Mosquitto) — ingress от датчиков device-service (Go) —
регистрация/heartbeat устройств timeseries-ingester (Go) — InfluxDB writer ml-inference (Python FastAPI)
— предсказания отказов alert-engine (Go) — уведомления Telegram/Email/SMS api-gateway (Go Gin) —
REST/GraphQL для дашбордов grafana — дашборды postgres-timescale — метаданные redis-cluster —
кэш minio — S3 storage prometheus + grafana-loki — мониторинг nginx-ingress — внешний трафик
Доступ к интернету и другие вопросы
доступов
Internet (зелёная зона) HTTPS:443 (api-gateway) — дашборды, мобильное app WAF (Cloudflare/Nginx)
— DDoS защита Public DNS (CNAME → Load Balancer)
DMZ (серая зона) MQTT:8883 (TLS) — только от датчиков (LoRaWAN/NB-IoT) VPN WireGuard —
доступ админов (IP whitelist)
Internal (внутренняя сеть, VLAN 10) PostgreSQL:5432, Redis:6379, InfluxDB:8086 gRPC:9090 —
внутренний трафик микросервисов

23. Требования к железу

Архитектура центрального
процессора
Intel Xeon Gold 6444Y 3 nodes
Нужны ли GPU
Nvidia A100 / H100 (для ML inference и обучения)
Оперативная память
512GB DDR5 на node (ECC) 2TB всего
Диски
NVMe 4TB (hot) + HDD 20TB (cold) RAID-10/RAID-6
Масштабирование и кластеризация
K8s HPA + Cluster Autoscaler

24. Требования к размещению системы и информационная безопасность

Облако
Аутентификация и доступ
Двухфакторная аутентификация для администраторов
Ролевая модель доступа (оператор, администратор, гость)
Сессионные ключи с ограниченным сроком жизни
Шифрование данных
TLS 1.3 для передачи данных
Шифрование данных на уровне хранилища
Защищённое хранение ключей и сертификатов
Защита устройств
Уникальные идентификаторы для каждого контроллера
Регулярное обновление прошивок
Защита от DDoS-атак на уровень связи
Резервирование и отказоустойчивость
Гео-распределённые серверы
Резервные каналы связи (проводные + беспроводные)
Автоматическое переключение при сбоях
Соответствие стандартам
ГОСТ Р 57580.1–2017 (IoT-безопасность)
GDPR/ФЗ-152 (защита персональных данных)
Требованиям регуляторов города

25. Эффективность

05
Эффективность

26. Эффективность

Бизнес-метрики
PnL
ROI
DAU, MAU и т.п.
REVENUE,COGS,GROSS
PROFIT, NET PROFIT и
т.п.
Метрики ИИмодели
Зависит от типа модели