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

Быстрый ответ: 

Архитектура приложения для зарядных станций EV строится на связке из трёх слоёв — станция обменивается данными с центральной системой управления (CSMS) по протоколу OCPP, центральная система передаёт статусы в мобильное приложение и формирует биллинг по данным счётчика. OCPP — открытый стандарт, но на практике под каждого производителя оборудования нужен отдельный слой адаптеров. Разбираем 8 компонентов, без которых такая архитектура не будет работать надёжно.

1. Связь со станцией: OCPP и выбор версии
OCPP (Open Charge Point Protocol) — стандарт обмена данными между станцией (Charge Point) и центральной системой. В 2026 году большинство станций в эксплуатации работает на OCPP 1.6 (обычно в варианте OCPP-1.6J, JSON по WebSocket) — он проще и дешевле в реализации. OCPP 2.0.1 быстро набирает долю среди новых коммерческих проектов и публичных быстрых станций за счёт продвинутой безопасности и smart charging. OCPP 2.1, с поддержкой V2G (vehicle-to-grid) и Plug & Charge, пока встречается редко, но спрос на него растёт вместе с распространением двунаправленной зарядки. Архитектуру нужно закладывать с поддержкой минимум 1.6 и 2.0.1 одновременно — переход целой сети станций на одну версию протокола занимает годы.

2. Центральная система (CSMS)
CSMS принимает WebSocket-соединения от станций и обрабатывает базовые сообщения протокола: BootNotification (станция сообщает о включении), StatusNotification (статус порта — Available, Occupied, Faulted), Authorize (проверка права на зарядку), StartTransaction и StopTransaction (начало и конец сессии), MeterValues (показания счётчика во время зарядки). Это ядро системы, через которое проходят все события до того, как попасть в биллинг или приложение.

3. Адаптеры под производителей оборудования
OCPP — стандарт, но не гарантия совместимости из коробки. В нашей практике интеграция станций китайских производителей и европейского оборудования CircControl потребовала отдельного слоя адаптеров: у каждого вендора — свои расширения протокола, нестандартные поля в сообщениях, особенности обработки ошибок. Адаптер нормализует данные от любого производителя в единую внутреннюю модель, прежде чем они попадут в биллинг и приложение.

4. Биллинговый движок
Биллинг получает данные MeterValues (потреблённые кВт·ч) и рассчитывает итоговую стоимость по факту, а не по предварительной оценке. В тарифную логику закладывается: разные ставки для AC и DC портов и отдельный тариф за простой — режим парковки, если автомобиль не забрали после завершения зарядки. Для B2B-клиентов биллинг должен поддерживать лимиты расходов на сотрудника или автомобиль и сводные отчёты по подразделениям.

5. Платёжный слой
Платёжный слой работает по балансовой модели: пользователь пополняет баланс в приложении, и стоимость зарядки списывается с баланса по факту использования — без предавторизации на каждую сессию. Резервирование суммы на карте применяется только в сценарии без приложения, когда на самой станции установлен платёжный терминал: терминал держит резерв, а после StopTransaction и финального показания счётчика списывает фактическую стоимость и возвращает остаток. В обоих случаях расчёт должен обрабатываться асинхронно, чтобы задержка между концом зарядки и финальным MeterValues не блокировала пользователя.

6. Клиентский API и push-уведомления
Мобильное приложение получает статусы станций и сессии зарядки через API, а не опрашивает CSMS напрямую. Push-уведомления о начале и завершении зарядки, а также об ошибках формируются на основе тех же событий OCPP (StatusNotification, StopTransaction), которые CSMS обрабатывает для биллинга, — это исключает рассинхронизацию между приложением и реальным статусом станции.

7. Операторская панель
Отдельный интерфейс для оператора сети: статус каждой станции в реальном времени, выручка, история сессий и аварийные события. При Faulted-статусе или сбое система уведомлений должна оповещать оператора немедленно — push, email или интеграция с внутренними каналами, — а не только показывать это в дашборде, который не открывают каждую минуту.

8. Очереди и отказоустойчивость
Станция может потерять связь с интернетом во время зарядки — в этом случае она должна продолжать заряжать локально и синхронизировать данные сессии (MeterValues, StopTransaction) при восстановлении соединения. Архитектура должна обрабатывать повторные или задержанные сообщения идемпотентно: если StopTransaction придёт два раза из-за сетевого сбоя, биллинг не должен списать оплату дважды.

ilab.md проектирует и разрабатывает архитектуру для зарядных станций EV — от интеграции оборудования через OCPP, включая китайских производителей и CircControl, до биллинга и мобильного приложения на React Native. Эта экспертиза переносится на рынки за пределами Молдовы.

Источники по версиям OCPP: chargelab.co, lembergsolutions.com, codibly.com.