OCPP 2.0.1 vs OCPP 1.6 отличия и перспективы
Как говорят ведомости, с 1 Января 2025 года в России ожидаются следующие изменения:
– Зарядки должны будут поддерживать проток OCPP 2.0.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.
Почему OCPP 2.0.1 все еще не мейнстрим?
Здесь я рискну высказать результаты собственных размышлений и немного порассуждать с позиции разработчика центральной системы...
Во-первых, предлагаемые в рамках нового протокола изменения довольно серьезные. Для перехода на новый стандарт требуются высокие затраты ресурсов как со стороны производителей оборудования, так и со стороны разработчиков ПО. Статус-кво, сложившийся на рынке за последние несколько лет активного развития, вероятно, всех устраивает.
Протокол 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.