EV-роуминг. Страх и ужас OCPI
Электрокары все чаще встречаются на улицах и мелькают в новостных лентах. Вместе с развитием рынка электроавтомобилей неизбежно, хотя и запаздывающими темпами, развивается зарядная инфраструктура.
Владельцы новеньких электиричек сталкиваются с новыми, доселе незнакомыми для себя, проблемами, среди которых:
- зоопарк операторов зарядных станций и их мобильных приложений
- низкое качество доступных мобильных приложений (иногда вкусовщина)
- низкое качество услуг по зарядке
- низкий показатель доступности станций (часто uptime ниже 95%)
Суть проблемы проста: относительно низкий порог входа операторов и владельцев зарядных станций (в отличие от рынка продажи нефтепродуктов) привлекает большое количество средних и мелких игроков, каждый из которых предлагает свой набор услуг, свой тип зарядок, свою тарификацию, свой софт и мобильные приложения.
В результате клиент, попав на зарядную станцию, не используемого им ранее, вынужден проходить полный путь самурая:
- устанавливать новое мобильное приложение;
- авторизоваться, указывая свои персональные данные и предоставля разрешение на их обработку;
- разбираться в нюансах тарификации;
- разбираться в особенностях пользовательского интерфейса и специфических функциях.
Зачастую мобильные решения от провайдеров не отличаются качеством и надежностью, что делает жизнь любителя электрокара еще более сложной. Представьте, если бы в каждом городе при использовании мобильного телефона, вам приходилось бы переключаться на сим-карту местного оператора....
Протокол OCPI и роуминг
И что же с этим делать? Взглянув на зрелый рынок мобильной связи, имевший примерно те же исходные проблемы, становится понятно, что решением является внутренняя интеграция между операторами зарядной инфраструктуры с предоставлением максимального унифицированного набора услуг конечным клиентам.
В этом и состоит суть процессов ev-роуминга: единый отраслевой стандарт взаимодействия между всеми участниками рынка с целью предоставить клиенту максимально безболезненный и приятный опыт при владении электрокаром. Наши западные партнеры, которые в силу объективных обстоятельств столкнулись с данной проблемой гораздо раньше нас, разработали и приняли де-факто стандартом протокол OCPI.
OCPI (Open Charge Point Interface) - протокол, разработанный EvRoaming Foundation и призванный стандартизировать интеграционные процессы межды операторами зарядных сетей (CPO - Charge Point Operator) и поставщиками решений для конечных пользователей (EMSP - eMobility Service Provider).
Казалось бы, проблема решена, во всяком случае переведена из плоскости концептуальной в плоскость техническую. Однако, не все так радужно...
История протокола началась в 2014 году и на текущий момент претерпела не менее десятка редакций. Сам протокол по общепризнанному мнению игроков рынка получился излишне сложным, неудобным для реализации, противоречивым и имеющим определенные проблемы с логической структурой сущностей и процессов взаимодействия. Однако, имеем что имеем...
Основные игроки на западе приняли стандарт и научились с ним жить. В России OCPI долгое время не принимался по совокупности факторов. Были попытки реализации кастомных протоколов, ни один из которых не получил статус национального стандарта. В последнее время, в связи с увеличением размера рынка и количества игроков, ev-роуминг в России получил новый драйвер развития и, как следствие, все больше компаний ищет способ быстро и надежно интегрироваться со своими партнерами.
Проблемы реализации ev-роуминга на базе протокола OCPI
Теперь немного о конкретных проблемах, связанных с реализацией OCPI протокола.Компании, включившиеся в процесс разработки интеграций по протоколу OCPI, столкнулись со следующими проблемами:
- противоречивость и недосказанность в рамках некоторых ключевых процессов, отсутствие единой логически-стройной модели;
- сложный и запутанный процесс авторизации, требующий первоначального обмена токенами вне рамках протокола;
- одновременное использование игроками рынка различных версий протокола, несовместимых между собой;
- проблемы с совместимостью различных реализаций даже одной версии протокола, связанные с неоднозначностью и разночтениями нюансов взаимодействия;
- необходимость поддержки одновременно push и pull модели взаимодействия. Теоретически, протокол обязывает реализовать только pull модель, однако, при увеличении кол-ва данных, такая модель становится неэффективной;
- отсутствие понятного и однозначного процесса обмена контрагентами. Изначально протокол подразумевал только две базовые роли (CPO и EMSP) и не предполагал появления более сложных схем взаимодействия между игроками рынка. Роли, добавленные в последующих редакциях протокола (например HUB), заставили разработчиков протокола прикручивать их "сбоку" и в несогласованном с общей моделью формате (HubClientInfo). Кроме того, сама модель ролей вызывает массу вопросов;
- система тарификации "на все случаи жизни" получилась громоздкой и непрактичной. Кроме того, создатели протокола не продумали нюансы, связанные с поддержкой историчности тарифов и по сути оставили это вопрос на откуп реализации;
- механизм ретраев внутри интеграционных событий противопоказан на уровне протокола. С другой стороны никакой альтернативы по реализации механизмов отказоустойчивости протокол не предлагает;
- распределение атрибутов между сущностями LOCATION(местоположение станции), EVSE (станция) и CONNECTOR(коннектор внутри станции) не соответствует физической модели большинства зарядных станций. Например в OCPI статус вынесен на уровень EVSE (станции), в то время как в реальном мире статус - атрибут коннектора;
- финансовая модель взаимодействия преимущественно вынесена за пределы протокола. При этом имеющиеся сущности вносят неодназначность при реализации данных процессов. Например, протокол не раскрывает, каким образом должен происходить финальный расчет зарядной сессии для клиента, однако дает понять, что единственная сущность, которая для этого подходит (CDR), может формироваться спустя произвольный период времени, что автоматически исключает возможность использования CDR для выставления счета клиенту в момент зарядки;
- OCPI имеет свою логическую модель и сложную систему тарификации, скорее всего вам не удастся адаптировать свой бэкенд без значительных переработок. Например, для поддержания всего многообразия вариантов тарификации вы будете вынуждены поддержать аналогичную модель и в вашей системе.
Отдельно хотелось бы отметить сложность тестирования интеграции в процессе разработки в связи с отсутствием общедоступных эмуляторов и сложностью построения интеграционной среды тестирования. Лидеры рынка признаются, что процесс тестирования происходит в рамках реальных интеграций с системами партнеров, что вряд ли можно отнести к общепринятым практикам разработки надежного ПО.
Здесь приведены лишь некоторые, но далеко не все, проблемы, с которыми сталкиваются разработчики OCPI интеграции. Вцелом, можно заключить, что разработка и подержка протокола OCPI - это сложный и дорогостоящий процесс, требующий глубоко понимания специфики бизнеса, квалификации и опыта команды бэкенд-разработки, отлаженных процессов тестирования и поддержки.
Решение OCPI от ev2Go
Мы в компании ev2Go прошли долгий путь по реализации и внедрению OCPI протокола. Понимая сложность и неоднозначность OCPI, мы изначально решили не просто реализовать интеграцию своей системы, а разработать независимый продукт, который взял бы на себя всю сложность и нюансы OCPI протокола, предложил бы потенциальным пользователям более простой и понятный способ интеграции своих бэкенд систем, способствовал бы созданию единой сети зарядных станций в РоссииСреди преимуществ нашего решения по сравнению с непосредственной реализацией протокола можно выделить:
- поддержка различных вариантов развертывания: cloud и on-premise
- упрощенный и адаптированный REST API взаимодействия с вашим бэкендом, не требующим понимания внутренних процессов и нюансов OCPI
- гарантия полной поддержки текущей, а также всех последующих редакций протокола. Поддержка устаревших версий возможна и обсуждается отдельно
- различные варианты уведомлений вашего бэкенда о входящих событиях (вебхуки, очереди(kafka, rabbitMQ, NATS), grpc)
- логирование, аудит и мониторинг интеграционных процессов с возможностью интеграции с инфраструктурой заказчика
- поддержка горизонтального масштабирования
- возможность использования эмулятора OCPI платформы для построения тестового контура, а также для отладки в процессе разработки
- golang-sdk (C#, js, Python ожидается в будущих релизах)
- техническая поддержка вашей команды разработки при интеграции
- ваша система сразу получает доступ к станциям наших интегрированных OCPI-партнеров (при отсутствие ограничений со стороны партнера)
- возможность интеграции вашего бэкенда с сервисом тарификации ev2Go, реализованного в полном соответствие с тарифной моделью OCPI
Варианты развертывания
Мы предлагаем два основных варианта развертывания:
on-premise(сервис OCPI разворачивается на инфраструктуре заказчика)
cloud (сервис OCPI разворачивается в ev2Go cloud)
Заключение
Мы верим в дальнейшее развитие и консолидацию рынка зарядной инфраструктуры в России. Возможно, в будущем мы будем причастны к созданию более логичного и простого способа интеграции, чем тот, который предлагается в рамках OCPI протокола. Однако, в данный момент, мы прикладываем максимум усилий, чтобы сделать опыт интеграции наших партнеров в рамках #OCPI безболезненным и эффективным.
Посмотреть информацию и почитать про наш продукт можно здесь