Короткий ответ: 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 есть подписка на переменные, пороги и уведомления. Платформа узнаёт о деградации до того, как водитель упрётся в неработающую станцию.
Сводная таблица
| OCPP 1.6J | OCPP 2.0.1 | |
|---|---|---|
| Транспорт | JSON поверх WebSocket | JSON поверх WebSocket |
| Модель устройства | Коннекторы с номерами | Station → EVSE → Connector, компоненты |
| Транзакции | Start/Stop | TransactionEvent |
| Безопасность | Отдельным профилем | Встроены три профиля, TLS, сертификаты |
| Подписанные показания | Нет | Да |
| Smart Charging | Базовый | Развитый, связка с ISO 15118 |
| Plug&Charge | Нет | Да, через ISO 15118 |
| Диагностика | Ограниченная | Мониторинг переменных с порогами |
| Распространённость | Массовая | Растёт |
Когда мигрировать не нужно
Парк небольшой и однородный. Двадцать станций одного производителя, нужны транзакции и удалённый перезапуск. 1.6J справляется, миграция принесёт работу без выгоды.
Оборудование не поддерживает 2.0.1. Поддержка определяется прошивкой и аппаратной платформой. Часть станций обновляется по воздуху, часть не обновляется никогда. Замена парка ради версии протокола экономически не оправдана.
Мощность не дефицитна. Главный выигрыш 2.0.1 — управление ограниченной мощностью. Если ввода хватает с запасом, выигрыша нет.
Когда мигрировать стоит
Парк разнородный и растёт. Стандартная модель устройства окупается ровно там, где производителей много.
Мощность ввода меньше суммы номиналов. Обычная ситуация на паркингах и в существующих зданиях.
Нужен Plug&Charge. Он существует только через ISO 15118, а тот заходит в станцию через 2.0.1.
Требуются подписанные показания. Коммерческий учёт и требования регулятора закрываются только версией 2.0.1.
Как проходит миграция
Смена версии — это смена контракта между станцией и платформой, поэтому «переключить в понедельник» не получится.
- Инвентаризация. Модель, прошивка, поддерживаемая версия, способ обновления — по каждой станции.
- Совместимость платформы. CSMS должна одновременно вести и 1.6, и 2.0.1: парк не переедет за один день.
- Стенд. По одной станции каждой модели, прогон полного цикла: авторизация, сессия, обрыв связи, восстановление, обновление прошивки.
- Пилот. Небольшая группа в бою, две-три недели наблюдения.
- Волнами. По моделям или площадкам, с возможностью отката на 1.6.
- Сведение биллинга. Параллельный учёт, пока не сойдутся суммы.
Ключевое требование к платформе — одновременная поддержка обеих версий. Без неё миграция превращается в остановку сети.
Ключевые выводы
- 1.6J — рабочий отраслевой стандарт, для небольшого однородного парка его достаточно.
- 2.0.1 выигрывает на масштабе, разнородности и дефиците мощности.
- Главные приобретения 2.0.1: модель устройства, надёжные транзакции, встроенная безопасность, Smart Charging, Plug&Charge.
- Plug&Charge и подписанные показания в 1.6 недоступны в принципе.
- Миграция идёт волнами при одновременной поддержке версий на платформе.
- Обновляйтесь под задачу, а не под номер версии.