На текущий момент зарядки электромобилей с серверами общаются преимущественно по протоколу OCPP. Самая распространенная в мире версия протокола — 1.6j. В ряде стран введено обязательство на использование 2.0.1.
Версия 2.0.1 получила распространение в США, где она обязательна с февраля 2024. Ситуация характерная именно для Северной Америки. Исторически там каждая сеть зарядных станций ваяла собственные протоколы. Далее для победы над хаосом была внедрена гос. программа NEVI (National EV Initiative), по которой все обязаны поддерживать OCPP и сразу 2.0.1, поскольку он уже был разработан к тому моменту. Даже ввели сертификацию и, конечно, переделили рынок заново, а заодно и освоили 7 млрд. дол. фед. бюджета на субсидии.
В Европе, Азии и на одной шестой части суши между ними зоопарка протоколов не было. Пара случаев (типа Энергии Москвы) не в счет. Поэтому на 2.0.1 (сейчас уже ver. 3) перебегать никто не торопился, но вот всё к этому уже идет и у нас.
Разработке и внедрению чего-либо, в том числе и нового протокола, обязательно должно предшествовать технико-экономическое обоснование. Вот и мы попробуем разобраться с этим обоснованием. Начнем с технического
Чем же отличается протокол 2.0.1 от 1.6
Основная проблема в том, что протоколы несовместимы. Вторая версия — это не расширение первой. Это другой протокол. В целом с отличиями можно ознакомиться в оригинале по ссылке.
Кратко приведем их список.
Передача характеристик зарядного устройства
Зарядка электромобиля сама в древовидной структуре расскажет, что она умеет: какие у нее порты, сколько, какой мощности. И не нужно это вручную заносить на сервер. При этом все равно на сервер нужно будет внести инфо о местоположении зарядки, ее фото, описание, как ее найти, и прочую крайне полезную для пользователя информацию. В итоге ручного внесения данных все равно никто не отменял, и снижение трудоемкости или уменьшение ошибочности предоставления данных не видится очевидным.
Дополнительно обещается большая информационная насыщенность в части диагностики неполадок в компонентах зарядной станции благодаря этому нововведению.
Далее цитата:
Параметры конфигурации теперь привязаны к физическим компонентам, таким как Connector, или логическим контроллерам, таким как компонент SmartChargingCtrlr. Это обеспечивает структуру для множества параметров конфигурации, которые существуют в более сложных зарядных станциях.
То есть видится усложнение конфигурации для сложных станций. Для простых зарядных устройств (AC, которых большинство) такое усложнение избыточно.
Настраиваемый мониторинг
Сервис-инженер может настроить станцию на передачу уведомлений, когда переменная определенного компонента превышает пороговое значение, или он может запросить периодическую выборку этих значений. Например, можно настроить получение уведомлений, когда переменная температуры преобразователя тока превышает определенное значение.
Будет меньше необходимости отправлять сервисного инженера на место, поскольку проблему можно обнаружить заранее и удаленно. Компоненты, которые начинают работать за пределами допустимых значений, могут быть заменены заранее в ходе планового ТО. Вроде, должно сокращаться время простоя зарядок за счет улучшения возможностей мониторинга и удаленной поддержки.
Но это теория. На практике имеем то, что операторы ЭЗС часто знают о проблемах в конкретной станции, знают, что с ней не так, но не могут организовать выезд сервис инженера по причинам организационного характера. То есть OCPP 2.0.1 дает возможность делать все «по красоте», но причины значительного простоя станций кроются не в отсутствии информации. Ко всем DC зарядкам (в т.ч. частным, а не публичным) инструкция производителя предписывает делать ТО раз в полгода. Кто его делает по регламенту? Но, конечно, в значительном проценте случаев оператор может более точно диагностировать проблему при звонке от пользователя. Этого не отнять.
Есть еще подвох — ошибок можно передать много, но коды ошибок не стандартизированы, и у каждого производителя набор кодов может быть свой. Оператору придется разбираться в кодах производителей всех станций, с которыми он работает.
Пересмотрена относительно OCPP 1.6 структура описания транзакции
Операторы отмечают, что это удобно, т.к. позволит лучше выявлять неучтенные сессии.
Введено сжатие данных
Но это решение проблемы, которую сам новый протокол и создает. Он увеличивает объем данных, но вводит их сжатие для уменьшения трафика.
Настраиваемые точки начала и остановки транзакции
Со стороны выглядит технически обоснованным при интегрировании зарядок со шлагбаумами и парковочными блокираторами. Нужно в ограниченном наборе случаев.
Улучшенное поведение зарядок в офлайн
В 1.6 идентификатор зарядной сессии давал сервер. В состоянии офлайн зарядка создавала временный ID, который потом заменяла постоянным от сервера после появления связи. По OCPP 2.0.1 идентификаторы создает сама зарядка, тем самым можно в теории и в состоянии офлайн записывать сессии более надежно. Хотя сколько операторов знаем, так столько и говорит, что работать станция должна только онлайн, и офлайн «костыли» — это зло.
Отображение дополнительной информации
Вывод на экран ЗУ информации по тарифам, стоимости, при том на разных языках. При применении приложений на телефоне не нужно абсолютно. Нужно только для следующего пункта.
Расширенная «умная зарядка»
Идентификация автомобиля в системе оператора и запуск зарядной сессии без команды с приложения после вставки коннектора по заданным настройкам в профиле (Plug and Charge). Удобство приятное, но нужное только для DC. И только для автомобилей с «родным» портом CCS2. Китайские производителей автомобилей плевать хотели на эту умную зарядку. Так что авто с GBT и с переделанным портом из GBT (Evolute, например) свои идентификационные данные зарядке не отдадут.
Повышенная безопасность и обязательность шифрования
При общении станции с сервером, установке обновлений и т.д. В целом нужно, хотя и на 1.6 это никто не мешал делать, просто в 2.0.1 это стало обязательным.
Итого технически OCPP 2.0.1 выглядит интересным для реализации в DC станциях, при том многоконнекторных, сложных. Или больших зарядных хабах. Для AC станций новый протокол выглядит излишним усложнением.
Попробуем обосновать экономическую необходимость
Доходная часть
Допустим, я владелец зарядной инфраструктуры. Я задаю простые вопросы по изменению доходов:
- Позволит ли мне 2.0.1 увеличить количество потребителей?
Ответ: нет. Количество клиентов зависит от других факторов. Например, размера налогового бремени на покупателях автомобилей.
- Увеличится ли аптайм (время работы) клиент-серверной структуры?
Ответ: скорее наоборот уменьшится. Любое усложнение системы уменьшает ее надежность при прочих равных условиях.
- Увеличится ли аптайм зарядных станций из-за повышения информированности оператора об ошибках?
Ответ: может быть, если оператор очень хорошо не жалея ресурсов выстроил сервисную службу. Нужно проверять практикой. Пока тут нет уверенности в каком-либо результате.
- Смогу ли я ставить цену на электроэнергию выше, если станции работают с протоколом 2.0.1?
Смогу только при совпадении условий, что появится серьезный брендинг в зарядной инфраструктуре и бренд, реализовав великолепный сервис (см п.3), сделает брендовую наценку и сможет «продать» ее потребителю. То есть ответ: нет. Место в ближайшем будущем будет всегда иметь более приоритетное значение.
Итого по доходам не видится увеличения количества и цены. Соответственно не предполагается увеличение доходности.
Расходная часть
По изменению расходов вопросы такие:
- Как повлияет переход на 2.0.1 на потребность в персонале?
Ответ: скорее увеличит потребность в IT специалистах, как следствие увеличит фонд оплаты труда. Но это не точно.
- Как повлияет переход на 2.0.1 на стоимость зарядных станций?
Ответ: увеличит стоимость. Так как во-первых, у производителей также вырастут косты на персонал, во-вторых, сузится предложение на рынке, а в-третьих, определенные круги очень желают внедрить «сертификацию» по «стандартам протоколов», а она не бесплатная.
- Как изменятся расходы на сервисное обслуживание?
Тут вопрос дискуссионный и нужно больше практических кейсов. Но скорее всего где-то увеличатся, где-то уменьшатся. Мат. ожидание будет около нуля. По крайней мере по сообщениям из тех же США что-то никто не приводит живого кейса, как снизились издержки на сервис после внедрения 2.0.1.
Итого по расходам видится только их рост.
В сумме имеем потенциальное снижение прибыли операторов ЭЗС вследствие применения протокола 2.0.1 без технической необходимости.
Приведем аналогию из другого рынка
В сентябре 2024 вышла 15-я версия Android. Но большинство электронных читалок эконом сегмента работают на Android 4х, большинство читалок среднего класса работают под Android 7х. И только самые топовые на Android 11. Происходит это по прозаичной причине — достаточности возможностей ОС и экономии ресурсов самого устройства, а также экономии труда разработчиков.
Автору неизвестны примеры общественных дискуссий на тему необходимости перевода читалок на более высокие версии Андройда. Производители это решают сами, когда им нужно получить определенный функционал своего устройства.
Вывод
Зарядные устройства, работающие на протоколе OCPP 2.0.1 обоснованы только, когда 1.6 не позволяют им функционировать в достаточной для потребителей и операторов степени. Как выше говорилось, для сложных систем. И решать это должны сами операторы/владельцы зарядной инфраструктуры, без навязывания технологии им извне. Благо пока Минпромторг ввел требование применения 2.0.1 только для субсидируемых новых DC-станций. Но как знать, куда заведет кривая делопроизводства дальше.
Специалисты приглашаются к коментариям.