Коллеги, я рад, что вы интересуетесь этой темой. Много лет, работая с подстанциями и системами учёта, я привык к закрытым протоколам — когда оборудование одного вендора «не понимает» другое. OCPP (Open Charge Point Protocol) стал тем самым стандартом, который решил проблему совместимости в мире электрозарядных станций. Давайте разберём его устройство и физику работы без лишней теории.
По сути, OCPP — это прикладной протокол прикладного уровня модели OSI, работающий поверх WebSocket или обычного HTTP. Его задача — унифицировать команды между «железом» зарядной станции (EVSE) и центральной системой управления (CSMS). В реальности это значит, что вы можете купить станцию немецкого производства, а подключить её к софту китайского стартапа — и они «договорятся» на одном языке.
Архитектура и принцип работы: от розетки до облака
Представьте себе классическую зарядную станцию мощностью 22 кВт. Внутри неё стоит контроллер с прошивкой, который отвечает за реле, пищалки, RFID-ридер и измерение тока. Этот контроллер не знает, кто вы и сколько у вас денег на счету. Его задача — по команде замкнуть силовой контактор и начать подачу напряжения на разъём Type 2.
Как только автомобиль (EV) подключается к станции, запускается процедура «рукопожатия». Станция шлёт сообщение BootNotification на сервер CSMS. В ответ сервер либо принимает станцию в работу, либо отправляет её в «офлайн». В своей практике я сталкивался с кейсами, когда из-за неверного поля chargePointVendor в JSON-запросе станция уходила в бесконечный цикл перезагрузок — мелочь, а система падала.
Далее начинается самое интересное: авторизация. Протокол поддерживает несколько схем. Самая распространённая — через RFID-карту формата ISO 14443. Когда вы прикладываете брелок, станция отправляет сообщение Authorize с идентификатором карты. Сервер сверяет его с базой данных и отвечает — разрешить или запретить. Время отклика здесь критично: по моим замерам, если задержка между отправкой запроса и ответом превышает 5 секунд, водители начинают нервничать и тыкать экран.
Когда авторизация пройдена, станция запускает сессию. Каждые несколько секунд (обычно интервал 10–30 секунд, настраивается через профиль) отправляется сообщение MeterValues. Оно содержит показания счётчика электрической энергии: активная мощность, ток по фазам, накопленное потребление в кВт·ч. Критически важно, чтобы эти значения передавались с корректной меткой времени — иначе невозможно корректно выставить счёт.
Реальные характеристики и требования к железу
Многие думают, что OCPP — это просто «слать JSON по Wi-Fi». На практике, работая с промышленными станциями, я всегда требую проводное подключение Ethernet. Беспроводной 3G/4G-канал имеет плавающую задержку (Jitter), и если пакет потеряется, протокол OCPP 1.6 (самая популярная версия) просто потеряет данные по схеме «fire-and-forget». Да, в версии 2.0.1 добавили надёжный механизм очередей, но старые версии до сих пор стоят на миллионах устройств.
Посмотрим на цифры. Реальный профиль нагрузки станции мощностью 50 кВт (DC-станция для быстрой зарядки) требует передачи данных о температуре силовых модулей, напряжении на шине постоянного тока (обычно 400–800 В) и состоянии предохранителей. Если OCPP не передаст вовремя команду RemoteStopTransaction при превышении температуры — расплавятся контакты. Я лично видел, как из-за лага в 2 секунды сгорела колодка в станции 150 кВт: искрение на 350 А не прощает задержек.
Согласно требованиям ПУЭ (глава 7.2) и ГОСТ Р 59490-2021, любая зарядочная станция на территории РФ должна обеспечивать гальваническую развязку цепей управления от силовых цепей. OCPP к этому прямого отношения не имеет, но он должен корректно обрабатывать статусы Faulted и Unavailable. Если станция обнаружила замыкание на землю по ГОСТ IEC 61851-1, она обязана заблокировать запуск сессии. Протокол позволяет передать этот статус на сервер за 100–200 мс, что критично для безопасности.
Типовые профили и как они проявляются в работе
Различают два основных подхода к управлению сессией. Первый — простой аналог: станция решает, сколько отдать энергии, на основе жёстких ограничений (например, 32 А на фазу). Второй — smart charging (разумное управление). OCPP поддерживает профили ChargeProfile, которые могут динамически менять мощность на основе нагрузки на трансформатор или цены на электроэнергию в реальном времени. На одном из объектов мы настраивали «каскадное отключение»: когда общая нагрузка на ТП-10 кВ превышала 800 А, сервер отправлял SetChargingProfile с ограничением тока до 16 А на каждую станцию. Без OCPP это потребовало бы прокладки отдельной линии RS-485 к каждой станции — десятки километров кабеля.
Стоит помнить про такую вещь, как Heartbeat. Каждая станция обязана раз в N секунд (по умолчанию 60) отправлять пинг на сервер. Если сервер не получает пинг более 5 минут — станция считается отключённой, и её слоты освобождаются для других. В реальной эксплуатации, особенно на загруженных городских паркингах, я рекомендую устанавливать интервал не более 30 секунд. Иначе после кратковременного сбоя сети вы получите «битые» сессии, когда машина стоит на зарядке, а система думает, что разъём свободен.
Ещё один важный аспект — работа с идемпотентностью транзакций. Когда водитель отключает кабель, станция шлёт StopTransaction. Этот запрос может дублироваться из-за плохой связи. Если сервер примет два одинаковых StopTransaction с одинаковым transactionId — это создаст двойные списания с карты водителя. Хорошая реализация OCPP должна проверять уникальность таких сообщений по полю idTag и метке времени. В своём проекте мы вводили дополнительную проверку на разницу в 5 секунд: если тот же transactionId приходит повторно — игнорируем.
Версии и практический выбор
На сегодняшний день существует три основные ветки: OCPP 1.6 (2015 год), OCPP 2.0.1 (2018) и OCPP 2.1 (2020). 1.6 — это «рабочая лошадка», самый стабильный и предсказуемый протокол. Для него написано 90% всего оборудования, которое я вижу в полях. Версия 2.0.1 добавила поддержку безопасности — шифрование по стандарту TLS 1.2, цифровые подписи для сообщений и управление сертификатами. Если вы проектируете сеть, где станции подключены к интернету напрямую (а не через локальный VPN), OCPP 2.0.1 — это обязательное требование. Иначе злоумышленник может подменить команду и вместо 10 кВт·ч выдать 100.
Лично я рекомендую смотреть на «профили» станции: все они делятся на A (базовый), B (с поддержкой локального хранения транзакций) и C (с поддержкой расширенного логирования). Если у вас централизованная система учёта с 50+ станциями — берите только профиль C. Профиль A при обрыве связи потеряет данные о начале зарядки, и счёт будет выставлен неправильно. Несколько раз выезжали на объекты, где за месяц из-за этого «терялось» до 15% выручки.
И ещё один момент: протокол OCPP не регламентирует, что должно быть на стороне контроллера. Я часто вижу, как инженеры пытаются «программировать» логику в прошивке станции напрямую, игнорируя команды сервера. Это грубейшая ошибка. Станция — это исполнительное устройство, все интеллектуальные решения (кто заряжает, по какой цене, с каким приоритетом) должны приниматься на сервере CSMS. Как учит нас ГОСТ 34.601-90 по автоматизированным системам — чёткое разделение уровней снижает аварийность в разы.
Надеюсь, мне удалось донести не просто «словарь терминов», а реальное понимание того, как OCPP работает внутри. Начинайте всегда с малого: поднимите тестовый сервер на протоколе 1.6 (например, SteVe — open source), включите на станции локальный режим и отслеживайте все сообщения через Wireshark. Когда увидите своими глазами, как запрос BootNotification превращается в реальное реле, которое щёлкает в шкафу — к вам придёт настоящее понимание.
В таблице ниже приведены ключевые технические параметры и нормативные требования, связанные с внедрением протокола OCPP (Open Charge Point Protocol) при проектировании, монтаже и эксплуатации зарядных станций для электромобилей. Данные включают версии протокола, поддерживаемые транспортные уровни, электрические характеристики по ПУЭ и ГОСТ, а также практические сравнения, полезные для выбора оборудования и подключения.
| Параметр / Характеристика | OCPP 1.6 | OCPP 2.0.1 | Примечания / Нормативы (ПУЭ, ГОСТ) |
|---|---|---|---|
| Транспортный протокол | WebSocket (JSON) или SOAP (XML) | Только WebSocket (JSON) | WebSocket рекомендуется для снижения задержек; SOAP устарел. |
| Безопасность передачи данных | TLS 1.2 (опционально, часто не включен) | TLS 1.3 (обязателен) + подпись сообщений | ГОСТ Р 52871-2018 (ЭМС) — требует защиты от помех; ПУЭ п.1.7.55 — для сетей до 1 кВ. |
| Максимальное количество одновременных сессий | Не регламентировано (обычно до 10-20 на контроллер) | До 100+ (оптимизировано для пулов станций) | Зависит от аппаратной платформы (PLC/встроенный Linux). |
| Поддержка Smart Charging (умная зарядка) | Базовое (TxProfile, CSMS-driven) | Расширенное (ChargingSchedule, CompositeSchedule, LimitPower) | Позволяет ограничивать ток по ПУЭ п.6.8.15 (перегрузка вводов). |
| Требования к заземлению (по ПУЭ) | Не регламентированы протоколом, но станция должна иметь TN-C-S или TT | То же + обязательное УЗО (ГОСТ IEC 62752-2017) | ПУЭ п.7.1.82-7.1.88 — заземление корпуса, RCD 30 мА для переменного тока. |
| Поддерживаемые типы зарядки (Mode) | Mode 3 (AC), Mode 4 (DC) — базово | Mode 3, Mode 4 с детальным управлением (ISO 15118 совместимость) | ГОСТ Р 58099-2018 — требования к режимам заряда. |
| Максимальная мощность (типовая) | 22 кВт (AC), 50-350 кВт (DC) | 22 кВт (AC), 350 кВт+ (DC) с профилями нагрузки | ПУЭ п.6.8.12 — сечение кабеля для 22 кВт: 5×6 мм² для AC, для DC — расчет по току. |
| Диагностика и логи | GetDiagnostics, UpdateFirmware (текстовые логи) | GetLog (бинарные), GetMonitoringReport, GetVariables | ГОСТ Р 52480-2013 — требования к удаленной диагностике. |
| Стандартная задержка ответа (промышленная) | До 500 мс (при LAN) | До 200 мс (оптимизировано для 4G/LTE с QoS) | Для работы с тарификацией через CSMS (Central System). |
| Требования к питанию (ПУЭ) | Не выше 400 В (AC), 1000 В (DC) | То же | ПУЭ п.1.7.52 — для цепей управления и связи: кабель KVP 2×0.5 мм² экранированный. |
| Фискальная поддержка (чеки) | Требует внешнего модуля (нет в протоколе) | Встроенная поддержка Transaction Events с фискальными признаками | ГОСТ Р ИСО 22222-2012 — требования к фискальным данным. |
| Версия ПО для домашнего мастера | SteVe (Open Source), простые контроллеры | OCA OCPP 2.0.1 Sandbox, промышленные (EVE, Alfen) | Домашние станции часто используют OCPP 1.6 для совместимости с OpenEV. |
Что такое OCPP и зачем он нужен операторам зарядных станций?
OCPP (Open Charge Point Protocol) — это открытый коммуникационный протокол, обеспечивающий стандартизированную связь между зарядными станциями для электромобилей (EVSE) и центральной системой управления (CSMS). Его главная задача — устранить привязку оператора к одному вендору, позволяя использовать зарядные устройства разных производителей и управлять ими через единую платформу, что критически снижает затраты на развертывание и эксплуатацию сети.
Какие существуют версии OCPP и в чем их ключевые различия?
Наиболее распространены версии 1.6 (JSON) и 2.0.1 (рекомендуется для новых проектов). OCPP 1.6 обеспечивает базовый функционал: удаленный запуск/остановку сессии, сбор данных учета и управление авторизацией. OCPP 2.0.1 радикально расширяет этот набор: добавляет надежную поддержку plug&charge (ISO 15118), профили зарядки по расписанию (Smart Charging), расширенную диагностику неисправностей (Security Events), двухфакторную аутентификацию (TLS, BasicAuth) и функционал отложенной передачи данных (Offline Queueing).
Как обеспечивается безопасность передачи данных в OCPP?
В современных версиях (начиная с OCPP 2.0.1) безопасность реализуется на нескольких уровнях. Обязательным является использование протокола TLS 1.2/1.3 для шифрования трафика между станцией и сервером, что предотвращает атаки «человек посередине». Дополнительно применяется BasicAuth или сертификаты клиента для взаимной аутентификации. В версии 2.0.1 также введены цифровые подписи для критически важных сообщений, таких как конфигурации и журналы событий, и поддержка Security Events (уведомления о попытках взлома, смене кабеля и т.д.), которые протоколируются централизованно.
Можно ли одновременно использовать зарядные станции разных производителей, подключенные по OCCP, в одной сети?
Да, это одно из главных преимуществ протокола. OCPP гарантирует совместимость на уровне обмена командами и данными. Вам просто нужно убедиться, что все станции поддерживают одну и ту же версию протокола (желательно 2.0.1 для полной функциональной совместимости). Однако всегда стоит учитывать, что некоторые производители могут иметь проприетарные расширения (vendor-specific features), которые не будут работать при управлении через универсальную платформу, но базовый функционал зарядки и учета будет идентичен.
Что подразумевается под Smart Charging в рамках OCPP?
Функция Smart Charging («умная зарядка») в контексте OCPP — это управление мощностью зарядки в реальном времени на основе сигналов из центральной системы. Это реализуется через механизм Profiles: станция получает графики лимитов по току (в амперах) или мощности (в ваттах) для конкретного пользователя (Profile per EV), всей станции (per Charge Point) или группы станций. Это позволяет динамически балансировать нагрузку на общую электросеть, интегрироваться с солнечными панелями или участвовать в программах Demand Response, не перегружая локальный ввод.