OCPP 2.0.1 vs OCPP 1.6 отличия и перспективы

Как говорят ведомости, с 1 Января 2025 года в России ожидаются следующие изменения:

– Зарядки должны будут поддерживать проток OCPP 2.0.1 (разберемся чуть дальше по тексту, что это значит)

– Системы управления зарядными станциями должны поддерживать возможность интеграции между собой в роуминг по протоколу OCPI 2.2.1 (про это мы писали тут и тут)

На сегодняшний день наиболее распространены две версии протокола OCPP: 1.6(j) и 2.0.1. При этом старые станции реализует и предыдущие версии, такие как 1.5, 1.6(S), и даже встречаются те, кто работает на 1.2.

OCPP Протокол версии 1.6(j) является в текущий момент наиболее востребованным и поддерживаемым среди производителей зарядной инфраструктуры. Он обладает рядом недостатоков, но при этом прост в реализации.

Протокол версии 2.0.1 является продолжением и исправлением протокола 2.0, который снят с поддержки из-за большого количества ошибок и недочетов. Версии 2.X имеют концептуальные отличия от 1.6 и не поддерживают обратную совместимость.

Давайте разберемся, в чем основное преимущества и недостатки обоих протоколов и стоит ли в ближайшее время ожидать массового перехода на OCPP 2.0.1.

Для начала попробуем сформулировать недостатки OCPP 1.6, которые заставили разработчиков протокола настолько радикально его переработать и отказаться от обратной совместимости.

И так имеем:

• низкий уровень стандартов безопасности при обмене между станцией и центральной системой, не отвечающих уровню современных кибер-угроз. В подтверждение этому достаточно вспомнить несколько недавних эпизодов взлома зарядных станций;

• протокол не рассчитан на высокую нагрузку и большое количество данных, что с каждым днем становится актуальнее. Протокол никак не формализует правила сжатия данных. Не предусмотрен пакетный обмен сообщениями. Кроме того, первоначальная версия протокола 1.6 и предыдущие версии основывались на стандарте SOAP, который сам по себе достаточно громоздкий и "многословный". Сейчас преимущественно используется обмен в стандарте json;

• авторизация зарядных сессий ограничена двумя базовыми сценариями (RFID карта, токен приложения). В текущии момент актуальных сценариев гораздо больше (Plug & Charge, платежные карты, QR коды, NFC);

• зарядная станция не предоставляет пользователю информацию о тарификации и стоимости транзакции. Функции тарификации полностью отдаются на откуп прикладного ПО;

• логическая модель зарядной станции представлена двумя уровнями (станция- коннектор), что не отражает топологии современных станций и ограничивает возможности управления;

• не предусмотрена возможность расширения и конфигурации набора метрик, метрики только на уровне транзакции;

• наличие недостатков в протоколе обмена данными транзакций. Например, нумерация на стороне центральной системы приводит к проблемам при offline режиме, а отсутствие идентификатора при удаленном старте транзакции вызывает серьезные проблемы с интерпретацией последовательности событий;

• ограниченные и неудобные для использования возможности диагностики и мониторинга;

• сложность миграции станции с однои системы на другую.

Стоит заметить, что предыдущие версии протокола, в том числе 1.6, подразумевали (и мне это кажется разумным) ограниченный набор функций на уровне ПО зарядной станции в целях простоты протокола, тогда как продвинутые сценарии должны были реализовываться в прикладном ПО. Вероятно, этим и объясняются многие из описанных выше проблем и недостатков.

Теперь давайте перечислим основные новшества протокола OCPP 2.0.1 по сравнению с 1.6:

• первое, что бросается в глаза, - это изменение формата документации. Она стала более стройнои и структурированной. Вся информация разбита по функциональным блокам. Внутри каждого блока разбираются сценарии в виде вариантов использования, сопровождаемых UML-диаграммами;

• расширена модель станции. Теперь она имеет 3 уровня: станция, EVSE, коннектор. EVSE представляет собой физический контроллер, который имеет один или более коннекторов. Модель большинства событий расширена параметром evseId;

• добавлена возможность пакетного обмена сообщениями и сжатие данных, что призвано повысить пропускную способность и эффективность обмена данными;

• улучшена безопасность. Введено понятие профиля безопасности, за счет которого реализуются наиболее востребованные сценарии: Basic авторизация и авторизация на основе клиентских сертификатов. Предусмотрена возможность обновления авторизационных данных. Предусмотрена отправка нотификационных событий со стороны станции;

• улучшена функция рестарта станции со стороны центральной системы. Появилась возможность рестарта отдельного EVSE, а также корректная обработка действующих транзакций;

• в части метрик произошли также значительные изменения: добавлена поддержка нетранзакционных метрик, модель метрик изменилась;

• расширен набор поддерживаемых Smart Charging сценариев. Некоторые из тех, которые надо было моделировать на стороне центральной системы, теперь поддерживаются "из коробки", например балансировка нагрузки между evse/коннекторами станций;

• значительно расширены возможности авторизации зарядной сессии, например, с помощью пин-кода или кредитной карты водителя;

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

• информация о действующем для водителя тарифе, а также предварительной, текущей и финальной стоимостях, может быть передана со стороны центральной системы и отображена на станции;

• расширен набор сценариев в рамках зарядной транзакции. Например, предусмотрена поддержка использования платежного терминала;

• улучшены функции отчетности, мониторинга и алертинга. Например, центральная система может подписаться на определенные события внутри станции и получать уведомления;

• добавлена поддержка стандарта ISO 15118, который формализует протокол обмена между электрокарами и зарядными сетями, что позволяет реализовать как Plug & Charge сценарии, так и продвинутые сценарии взаимодействия с энергосетями.

Это далеко не все изменения...

Спецификация протокола OCPP 2.0.1 доступна на github.

Здесь я рискну высказать результаты собственных размышлений и немного порассуждать с позиции разработчика центральной системы...

Во-первых, предлагаемые в рамках нового протокола изменения довольно серьезные. Для перехода на новый стандарт требуются высокие затраты ресурсов как со стороны производителей оборудования, так и со стороны разработчиков ПО. Статус-кво, сложившийся на рынке за последние несколько лет активного развития, вероятно, всех устраивает.

Протокол 1.6, несмотря на его несовершенство, достиг необходимого уровня зрелости, и большинство игроков научились его довольно точно и корректно реализовывать. Таким образом, спустя несколько лет, протокол стал именно отраслевым стандартом. Несмотря на то, что на рынке до сих пор присутсвуют производители, которые поддерживают протокол не точно или не в полной мере, можно утверждать, что большинство крупных и средних игроков понимают и реализуют протокол одинаково. Появление нового протокола, который обладает на порядок более высоким уровнем сложности, приведет к откату в стабильности обмена между ПО и станциями и, как следствие, к ухудшению пользовательского опыта.

Развивая тему сложности, стоит сказать, что версия 2.0.1 стала чересчур сложной. Особенно для реализации на уровне ПО станций. Общаясь с производителями, мы знаем, какие сложности возникают даже при реализации 1.6 на уровне контроллера. На реализацию протокола 2.0.1 у производителей, не обладающих огромным запасом ресурсов, могут уйти годы разработки и отладки. Увеличатся затраты на поддержку и эксплуатацию станций как со стороны производителей (затраты на предоставление гарантииного обслуживания), так и со стороны владельцев сетей(взаимодеиствие с производителями, упущенная выгода и клиенты из-за возникающих проблем).

А является ли протокол 2.0.1 настолько прорывным с точки зрения конечного пользователя? Безусловно, он предоставляет дополнительный уровень удобства и новые сценарии. Но, заметим, что многие из этих сценариев более или менее успешно уже реализуются на уровне прикладного ПО. Другие функции, хотя и являются приятными бонусами, сложно отнести к маст-хэв.

Теперь давайте посмотрим на процесс со стороны разработчика прикладного софта. Скажем откровенно: сложность адаптации протокола 2.0.1 под разработанные для 1.6 бизнес-процессы - крайне сложная и дорогостоящая задача. Пока протокол не получил массового распространения, поставщики ПО предпочитают не инвестировать в эту тему и занимать выжидательную позицию. Максимум, ограничиваются реализацией веб-сокетного обмена без глубокой переработки бизнес-процессов. Формально, такой подход позволяет утверждать о наличии в системе поддержки протокола версии 2.0.1, но при реальном внедрении потребует дополнительных затрат.

Возможен ли в ближайшее время массовый переход на протокол OCPP 2.0.1 ? В этой игре правила определяются в первую очередь производителями оборудования и гос. заказчиками. Наше мнение сходится с мнением знакомых нам производителей станций и владельцев сетей, - в ближайшее время массовый переход маловероятен. Просто потому, что в этом нет острой необходимости и заинтересованности ни одной из сторон.

Но не стоит исключать тот факт, что для производителей станций новый стандарт - это всегда новые продажи и рынки. Кроме того, не стоит забывать про вероятность дерективного внедрения протокола в РФ со стороны гос. органов и национальных производителей.

Мы "желаем мира, но готовимся к войне":

• реализовали сам протокол на уровне веб-сокетного обмена;

• заложили в архитектуру максимальный уровень изоляции бизнес-процессов от особенностей протокола, в том числе за счет размещения в разных сервисах;

• адаптируем бизнес-процессы в той части, в которой можем это сделать без высоких затрат ресурсов;

• продумываем и планируем, что конкретно и с каким приоритетом надо будет реализовать при возникновении необходимости подключения станций по протоколу 2.0.1.