OCPP 1.6 и 2.0.1: в чём разница

Короткий ответ: OCPP 1.6 — протокол про то, чтобы станция работала. OCPP 2.0.1 — протокол про то, чтобы сетью из тысячи станций можно было управлять. Если у вас десять станций одного производителя и задача — снимать транзакции и перезагружать зависшую точку, 1.6J закрывает её полностью. Если станций сотни, они разнородны, а от платформы требуются умное распределение мощности, подписанные показания и внятная диагностика — 1.6 начинает мешать.

OCPP разрабатывает Open Charge Alliance. В обиходе живут 1.5, 1.6, 2.0, 2.0.1 и 2.1; фактическим отраслевым стандартом остаётся 1.6J — вариант с транспортом JSON поверх WebSocket. Вариант 1.6S на SOAP считается устаревшим.

Пять различий, которые ощущаются на практике

1. Модель устройства

В 1.6 станция — это набор коннекторов с номерами. Всё, что не коннектор, протоколу не видно: вентилятор, силовой модуль, счётчик, шкаф существуют только в прошивке.

В 2.0.1 введена иерархия ChargingStation → EVSE → Connector и типизированные компоненты с переменными. Каждый узел адресуем: у него можно прочитать состояние и задать параметр стандартным сообщением.

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

2. Транзакции

В 1.6 транзакция описывается парой StartTransaction / StopTransaction, а связь событий с сессией держится на transactionId, который выдаёт сервер. При обрыве связи в неудачный момент восстановить целостность тяжело — отсюда классическая беда 1.6: потерянные и задвоенные сессии, которые потом руками сводит биллинг.

В 2.0.1 всё сведено к одному сообщению TransactionEvent с типами Started / Updated / Ended и явным transactionId со стороны станции. Событийная модель переживает разрывы связи заметно лучше.

3. Безопасность

В 1.6 базовая спецификация не описывает ни аутентификацию, ни шифрование — на практике используют HTTP Basic поверх WSS. Профиль безопасности появился позже отдельным документом.

В 2.0.1 профили безопасности встроены: от базовой аутентификации до клиентских сертификатов с TLS, плюс управление сертификатами и подписанные показания счётчика. Для коммерческого учёта и для сетей, попадающих под требования регуляторов, это перестаёт быть опцией.

4. Smart Charging

В 1.6 профили зарядки существуют, но их выразительность ограничена. Управлять группой станций за одним вводом, не превышая выделенную мощность, приходится логикой на стороне платформы.

В 2.0.1 Smart Charging проработан существенно глубже, а в связке с ISO 15118 появляется двусторонний обмен с автомобилем. Для паркинга, где мощность ввода меньше суммы номиналов станций, разница принципиальная — подробнее в статье о балансировке мощности.

5. Диагностика

В 1.6 набор статусов невелик, а детали отказа уезжают в вендорские поля. Мониторинг разнородного парка превращается в набор частных интеграций.

В 2.0.1 есть подписка на переменные, пороги и уведомления. Платформа узнаёт о деградации до того, как водитель упрётся в неработающую станцию.

Сводная таблица

Когда мигрировать не нужно

Парк небольшой и однородный. Двадцать станций одного производителя, нужны транзакции и удалённый перезапуск. 1.6J справляется, миграция принесёт работу без выгоды.

Оборудование не поддерживает 2.0.1. Поддержка определяется прошивкой и аппаратной платформой. Часть станций обновляется по воздуху, часть не обновляется никогда. Замена парка ради версии протокола экономически не оправдана.

Мощность не дефицитна. Главный выигрыш 2.0.1 — управление ограниченной мощностью. Если ввода хватает с запасом, выигрыша нет.

Когда мигрировать стоит

Парк разнородный и растёт. Стандартная модель устройства окупается ровно там, где производителей много.

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

Нужен Plug&Charge. Он существует только через ISO 15118, а тот заходит в станцию через 2.0.1.

Требуются подписанные показания. Коммерческий учёт и требования регулятора закрываются только версией 2.0.1.

Как проходит миграция

Смена версии — это смена контракта между станцией и платформой, поэтому «переключить в понедельник» не получится.

1. Инвентаризация. Модель, прошивка, поддерживаемая версия, способ обновления — по каждой станции.
2. Совместимость платформы. CSMS должна одновременно вести и 1.6, и 2.0.1: парк не переедет за один день.
3. Стенд. По одной станции каждой модели, прогон полного цикла: авторизация, сессия, обрыв связи, восстановление, обновление прошивки.
4. Пилот. Небольшая группа в бою, две-три недели наблюдения.
5. Волнами. По моделям или площадкам, с возможностью отката на 1.6.
6. Сведение биллинга. Параллельный учёт, пока не сойдутся суммы.

Ключевое требование к платформе — одновременная поддержка обеих версий. Без неё миграция превращается в остановку сети.

Ключевые выводы

• 1.6J — рабочий отраслевой стандарт, для небольшого однородного парка его достаточно.
• 2.0.1 выигрывает на масштабе, разнородности и дефиците мощности.
• Главные приобретения 2.0.1: модель устройства, надёжные транзакции, встроенная безопасность, Smart Charging, Plug&Charge.
• Plug&Charge и подписанные показания в 1.6 недоступны в принципе.
• Миграция идёт волнами при одновременной поддержке версий на платформе.
• Обновляйтесь под задачу, а не под номер версии.