Аттестация ЭЗС в «Россетях»: как кейс E-Prom превратить в защищаемую ВКР
В марте 2026 года компания E-Prom первой в стране получила заключение аттестационной комиссии ПАО «Россети» на зарядные станции для электромобилей (ЭЗС). Формально это новость из энергетики, но для выпускника ИТ-направления здесь спрятан готовый каркас диплома: аттестация — это всегда про требования, протоколы, интеграцию с диспетчерскими системами и доказуемое качество. Если ваша тема связана с IoT, микросервисами, промышленной автоматизацией или мониторингом, свежий кейс даёт вам «живую» отсылку в первой главе и понятную цель для проектной части. Ниже — как это применить без воды и выдуманных цифр.
Семантический разбор: что здесь ищем и почему
Прежде чем браться за текст, зафиксируем смысловые опоры. Их удобно использовать и в подзаголовках ВКР, и в поиске источников.
| Категория | Что берём из кейса |
|---|---|
| Основной запрос | зарядные станции ЭЗС для ВКР, аттестация ЭЗС, диплом по электрозарядной инфраструктуре |
| LSI-запросы | OCPP 2.0.1, OCPI, IEC 61851, ISO 15118, MQTT, REST/gRPC, Kubernetes, OpenTelemetry, ГОСТ 34.602-89, ISO/IEC 25010 |
| Сущности | ПАО «Россети» как заказчик требований, протокол зарядки, диспетчерский центр, телеметрия, пайплайны CI/CD |
| Вопросы студентов | Обязательно ли писать код? Где брать метрики? Как обосновать стек по ГОСТ? Нужны ли нагрузочные тесты? |
Три темы ВКР, которые опираются на кейс E-Prom
Тема 1. Сервис удалённого мониторинга парка ЭЗС
Актуальность. Появление аттестованного оборудования у «Россетей» означает, что станции будут объединяться в сеть с едиными требованиями к обмену данными. Значит, вопрос сбора телеметрии и статусов становится инженерной задачей, а не гипотезой.
Цель: разработать сервис сбора и визуализации состояния ЭЗС с обработкой отказов.
- Проанализировать протоколы обмена (OCPP 2.0.1, MQTT) и выбрать транспорт.
- Спроектировать модель данных зарядной сессии и статусов.
- Реализовать приём телеметрии и правила оповещений.
- Оценить нагрузочную устойчивость и время реакции на отказ.
Структура: Глава 1 — обзор стандартов и архитектурных подходов; Глава 2 — проектирование сервиса, диаграммы UML, схема развёртывания; Глава 3 — тестирование, метрики, оценка экономии на обслуживании.
Тема 2. Интеграция ЭЗС с диспетчерским контуром энергосети
Актуальность. Аттестация невозможна без подтверждённого регламента информационного обмена. Отсюда естественная задача для ВКР: спроектировать интеграционный слой между зарядной инфраструктурой и системой оператора.
Цель: построить шлюз обмена данными с разграничением прав и журналированием.
- Формализовать требования к интеграции в виде ТЗ по ГОСТ 34.602-89.
- Описать сценарии обмена и обработку конфликтов.
- Реализовать шлюз и проверить его под нагрузкой.
- Проверить соответствие характеристик по ISO/IEC 25010.
Тема 3. Прогнозирование загрузки зарядных сессий
Актуальность. Сеть станций, прошедшая аттестацию, начинает накапливать статистику. Данные о сессиях — отличная основа для учебной аналитической модели.
Цель: построить модель прогноза суточной загрузки ЭЗС.
- Собрать и очистить выборку зарядных сессий.
- Сравнить 2–3 алгоритма прогнозирования.
- Оценить точность (MAE, RMSE) и устойчивость модели.
- Описать сценарий применения прогноза в планировании мощностей.
Аналитическая глава: как обосновать выбор, не скатываясь в пересказ
Первая глава часто превращается в список определений. Возьмите кейс E-Prom как точку отсчёта: требования аттестационной комиссии — это и есть ваш набор критериев сравнения. Стройте таблицу по столбцам «требование → решение → обоснование → риск».
| Критерий | Вариант A | Вариант B | Вывод для ВКР |
|---|---|---|---|
| Транспорт телеметрии | MQTT | HTTP REST | MQTT выигрывает при частых коротких сообщениях |
| Протокол зарядки | OCPP 2.0.1 | проприетарный | Стандарт обязателен для аттестуемого оборудования |
| Развёртывание | Kubernetes | одна ВМ | Выбор зависит от числа станций, обоснуйте порог |
| Наблюдаемость | OpenTelemetry | логи в файл | Трассировка упрощает разбор инцидентов |
Такую таблицу можно смело ставить в первую главу: она показывает инженерное мышление, а не компиляцию чужих статей.
Проектная часть: схемы, которые ждёт комиссия
Здесь ценятся не объём кода, а объяснимость решений. Минимальный набор:
- диаграмма компонентов (клиент станции, шлюз, брокер, хранилище, панель оператора);
- диаграмма последовательности для сценария «старт зарядной сессии»;
- ER-модель: станция, коннектор, сессия, тариф, событие;
- схема развёртывания с зонами доступности.
Если пишете код — не гонитесь за объёмом. Достаточно работающего прототипа приёма телеметрии и обработки двух-трёх типов событий. Для этого хватит Python/Java/Go плюс брокер сообщений.
# фрагмент обработчика события зарядной сессии
def handle_event(msg):
session = parse(msg.payload)
if session.status == "faulted":
alerter.raise_event(session, severity="high")
metrics.observe_latency(session.started_at, session.ended_at)
Тестирование и метрики: чем доказывать работоспособность
Комиссия любит цифры. Возьмите четыре группы показателей:
- Производительность: пропускная способность сообщений в секунду, задержка p95.
- Надёжность: RTO и RPO при отказе узла, доля потерянных событий.
- Качество: характеристики по ISO/IEC 25010 — надёжность, сопровождаемость, производительность.
- Экономика: сокращение времени ручного обхода станций, стоимость часа простоя.
Методику нагрузочного теста описывайте так, чтобы её можно было повторить: инструмент, профиль нагрузки, длительность, окружение, результат. Один честный график убедительнее десяти абстрактных фраз.
Чему вы научитесь на такой теме
- Читать нормативные и отраслевые требования и превращать их в техническое задание.
- Обосновывать архитектуру и стек, а не выбирать «модное».
- Работать с протоколами промышленного уровня и инструментами наблюдаемости.
- Оформлять проектную документацию по ГОСТ 34 и защищать решения перед комиссией.
Типичные ошибки студентов
- Отсутствие метрик эффективности. Работа «работает, потому что запустилась» — не результат. Добавьте измеримые показатели до и после.
- Игнорирование ГОСТ 34.602-89 при оформлении ТЗ. Требования к системе оформляются по структуре стандарта, иначе замечания гарантированы.
- Подмена терминов без обоснования. Не путайте SaaS, PaaS и IaaS в тексте: комиссия почти всегда задаёт вопрос именно здесь.
Частые вопросы
Обязательно ли писать код в дипломе?
Не всегда. Если тема проектная, достаточно архитектуры, диаграмм и расчётов. Но прототип, подтверждающий ключевую гипотезу, заметно усиливает защиту.
Где брать тестовые данные по зарядным сессиям?
Синтетический генератор по реалистичному профилю: время суток, длительность, тип коннектора. Опишите методику генерации — это тоже результат.
Нужно ли делать нагрузочное тестирование?
Да, если в задачах есть производительность или масштабирование. Хватит одного сценария с понятной методикой и выводом.
Как оформить UML-диаграммы?
Единый нотариальный стиль по всему тексту, подписи на русском, ссылки на диаграммы в тексте. Инструмент вторичен.
Чек-лист перед сдачей
- Каждая задача из введения имеет вывод в заключении.
- Источники оформлены, ссылка на отраслевой кейс присутствует.
- Схемы читаемы, подписаны, упомянуты в тексте.
- Требования и ТЗ соответствуют ГОСТ 34.602-89.
- Метрики измеримы, а методика воспроизводима.
Источник: E-Prom получило заключение аттестационной комиссии ПАО «Россети» на ЭЗС (опубликовано 2026-03-25)