1. Что такое OCPP и почему руководителям операционных служб это должно быть важно.

OCPP (Open Charge Point Protocol) — это стандарт связи между зарядными станциями и центральной системой управления зарядными станциями (CSMS). Он определяет, как зарядное устройство передает информацию о своем состоянии на платформу, как оно получает удаленные команды, как обрабатывает авторизацию платежей и как сообщает о неисправностях. Вкратце: он определяет, является ли ваша сеть зарядных станций открытой или привязанной к одному поставщику.

Каждый директор по персоналу должен понимать две вещи:

Во-первых, OCPP — это открытый стандарт. Он поддерживается Open Charge Alliance (OCA) и не принадлежит ни одному производителю оборудования или программной платформе. Зарядное устройство, совместимое с OCPP, может взаимодействовать с любой системой управления зарядными устройствами (CSMS), совместимой с OCPP. Это означает, что вы не привязаны к конкретному производителю на уровне оборудования — если вы захотите сменить поставщика платформы через три года или подключить зарядные устройства другого производителя к той же сети, затраты на миграцию будут практически нулевыми, если обе стороны поддерживают OCPP.

Во-вторых, OCPP — это не OCPI. OCPI (Open Charge Point Interface) отвечает за роуминг и расчеты между различными зарядными сетями — например, водитель электромобиля использует приложение сети A для зарядки на станции сети B. OCPP отвечает за связь между зарядным устройством и его собственной платформой управления. Они решают разные задачи. В этом руководстве рассматривается OCPP.

2. Чего удалось достичь в рамках OCPP 1.6 — и в чём заключаются его недостатки.

OCPP 1.6 (выпущен в 2015 году, обновлен до версии 1.6J в 2017 году) — наиболее распространенная в мире версия протокола зарядки. Она выполнила основную задачу OCPP: стандартизацию базовых рабочих процессов для управления сеансами зарядки, удаленного запуска/остановки, формирования отчетов и обновления прошивки.

Однако у версии 1.6 есть три структурных ограничения:

1. Отсутствует стандартизированная модель данных устройства. В стандарте OCPP 1.6 отсутствует единая модель данных для переменных зарядных устройств. Каждый производитель по-разному представляет параметры “мощность зарядки”, “датчик температуры” и “код ошибки”. Когда оператор зарядного устройства управляет сетью зарядных устройств разных марок, один и тот же параметр может использовать совершенно разные названия полей, единицы измерения и диапазоны значений для разных марок зарядных устройств. Это затрудняет унифицированный мониторинг и диагностику.

2. Обеспечение безопасности является необязательным, а не обязательным. Спецификации безопасности OCPP 1.6 являются необязательными дополнениями. Шифрование TLS, управление сертификатами и безопасные обновления прошивки присутствуют в версии 1.6, но не являются обязательными. Во многих реальных системах используются незашифрованные соединения WebSocket или самоподписанные сертификаты. К 2026 году это уже недопустимо для операционной системы, обрабатывающей платежные данные и информацию о конфиденциальности пользователей.

3. Поддержка интеллектуальной зарядки ограничена. Функционал интеллектуальной зарядки OCPP 1.6 позволяет применять профили зарядки (ограничения мощности, временные окна), но в нем отсутствует встроенная поддержка динамического управления нагрузкой, интеграции возобновляемых источников энергии и двусторонней зарядки V2G. Это не сценарии использования в будущем, а оперативные требования, внедряемые в масштабах всей системы.

3. OCPP 2.0.1: Ключевые улучшения с точки зрения директора по персоналу.

OCPP 2.0.1 (выпущен в 2020 году, первое сертификационное тестирование завершено в 2023 году) не является поэтапным обновлением OCPP 1.6. Это архитектурная переработка. Ниже перечислены пять изменений, наиболее важных для CPO.

3.1 Улучшение 1: Модель устройства — Единый язык управления

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

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

3.2 Улучшение 2: Архитектура безопасности — TLS и управление сертификатами становятся обязательными.

В OCPP 2.0.1 следующие функции безопасности перестают быть необязательными и становятся обязательными:

• Шифрование TLS 1.2 (или выше): Все коммуникации между зарядным устройством и CSMS должны быть зашифрованы. Соединения WebSocket в открытом виде больше не допускаются.

• Управление сертификатами X.509: версия 2.0.1 определяет полный жизненный цикл управления сертификатами зарядных устройств — установку, продление и аннулирование. Это позволяет CPO создавать цепочки доверия на основе сертификатов, предотвращая атаки типа «человек посередине» и несанкционированный доступ.

• Безопасные обновления прошивки: пакеты прошивки должны быть подписаны цифровой подписью, и зарядное устройство должно проверить подпись перед установкой. Это предотвращает внедрение вредоносной прошивки — известную уязвимость в развертываниях версии 1.6.

• Журнал безопасности: Зарядные устройства записывают все события, имеющие отношение к безопасности (сбои аутентификации, изменения конфигурации, операции с микропрограммным обеспечением), и система управления безопасностью (CSMS) может активно собирать и анализировать эти журналы.

Для платежных сетей, принимающих платежи с помощью кредитных карт или обрабатывающих персональные данные пользователей, эти требования безопасности являются базовым требованием соответствия, а не необязательным условием.

3.3 Улучшение 3: Интеллектуальная зарядка — от статических ограничений к динамической координации

Функция интеллектуальной зарядки в OCPP 1.6 по сути является статическим инструментом: вы задаете профиль зарядки (ограничение мощности, временной интервал), и зарядное устройство его выполняет. Оно не учитывает динамические условия сети, выработку солнечной энергии на месте или состояния заряда/разряда систем хранения энергии.

В OCPP 2.0.1 представлены более расширенные возможности интеллектуальной зарядки:

• Составное расписание: Зарядные устройства могут сообщать о своем запланированном потреблении электроэнергии за разные периоды времени, а система управления зарядными устройствами (CSMS) может корректировать расписание каждого зарядного устройства в зависимости от общей нагрузки на объекте.

• Интеграция с внешними системами управления энергопотреблением: версия 2.0.1 изначально поддерживает интерфейсы с внешними системами управления энергопотреблением (EMS), позволяя зарядным станциям реагировать на ценовые сигналы или команды диспетчеризации сети.

• Интеграция со стандартом ISO 15118: Поддерживает интеллектуальную связь с автомобилем при зарядке — автомобиль может сообщать зарядному устройству состояние батареи, целевой уровень заряда и ожидаемое время отправления, а зарядное устройство соответствующим образом оптимизирует кривую зарядки.

Практическое значение для операторов централизованного электроснабжения: если на вашем объекте установлены солнечные батареи или системы хранения энергии, или если на вашем рынке используется ценообразование на электроэнергию в зависимости от времени суток, возможности интеллектуальной зарядки в версии 2.0.1 напрямую приводят к снижению эксплуатационных расходов. Это не будущая функция — она доступна на текущем оборудовании и требует только поддержки на уровне протокола.

3.4 Улучшение 4: Обработка транзакций — Более надежное выставление счетов

В OCPP 2.0.1 переработан процесс обработки транзакций и внедрена более точная модель событий выставления счетов. Ключевые улучшения включают:

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

• Детализация событий выставления счетов: 1.6 счетов на уровне сессии. Версия 2.0.1 поддерживает несколько сегментов выставления счетов в рамках одной сессии — например, один тариф за первые 30 минут, другой — после этого. Это позволяет использовать более гибкие стратегии ценообразования.

• Поддержка по вопросам налогов и сборов: Данные о транзакциях могут включать подробную разбивку по налогам, что упрощает соблюдение налогового законодательства в нескольких юрисдикциях.

3.5 Улучшение 5: Отображение сообщений и пользовательский опыт

OCPP 2.0.1 стандартизирует формат сообщений для экранов отображения зарядных устройств. Система управления зарядкой (CSMS) может передавать структурированные сообщения — информацию о ценах, ходе зарядки, уведомления о неисправностях — и зарядное устройство отображает их пользователю в едином формате. Для общественных сетей зарядки это повышает согласованность пользовательского опыта: независимо от марки зарядного устройства, используемого водителем, информация на экране отображается в одном и том же формате.

4. Путь миграции: с версии 1.6 на 2.0.1

Переход на OCPP 2.0.1 — это не “обновление прошивки”. Это проект, включающий аппаратное обеспечение, платформу и операционные процессы. Ниже представлен поэтапный план миграции.

4.1 Этап 1: Оценка (1–2 недели)

Шаг 1: Аудит совместимости оборудования. Для работы OCPP 2.0.1 установлены минимальные аппаратные требования. Более старые контроллеры зарядных устройств могут не обладать достаточной вычислительной мощностью, памятью или аппаратным ускорением TLS, необходимыми для работы стека протоколов 2.0.1. Свяжитесь с производителем вашего зарядного устройства и уточните для каждой модели, поддерживает ли она OCPP 2.0.1 — и в какой степени (полный набор функций 2.0.1 или частичный набор функций).

Ключевая информация, которую необходимо получить: модель процессора, доступный объем памяти, поддержка оборудования TLS и путь обновления с текущей версии микропрограммы.

Шаг 2: Подтверждение совместимости CSMS. Поддерживает ли ваша платформа управления OCPP 2.0.1? Если да, то это полная поддержка или частичный набор функций? Поддержка версии 2.0.1 обычно требует значительной работы по разработке на стороне платформы — это не переключатель в настройках.

Шаг 3: Приоритизация функций. Не все функции версии 2.0.1 одинаково важны для вашей работы. Если вы управляете общедоступной сетью быстрой зарядки, приоритетными могут быть улучшения безопасности и обработки транзакций. Если же вы управляете автопарком с собственной солнечной энергией и системами хранения, на первом месте могут оказаться возможности интеллектуальной зарядки. Четко определите свои приоритеты — не пытайтесь включить все сразу.

4.2 Этап 2: Планирование (2–4 недели)

Шаг 4: Выберите стратегию развертывания. Доступны три стратегии:

• С нуля: Развертывание OCPP 2.0.1 непосредственно на новых площадках. Это наиболее оптимальный путь, позволяющий избежать будущих затрат на миграцию.

• Параллельный запуск: Выберите 1–2 существующих объекта в качестве пилотных. Переведите часть зарядных устройств на версию 2.0.1, оставив остальные на версии 1.6. Система управления зарядными устройствами (CSMS) должна одновременно поддерживать обе версии протокола.

• Big Bang: Модернизация всей сети за один раз. Подходит только для небольших сетей (<20 зарядных устройств) или в случаях, когда совместимость оборудования и платформы была тщательно проверена.

Шаг 5: Разработайте план отмены.. Каждая миграция требует проверенного пути отката. Перед началом пакетной миграции проверьте весь процесс понижения версии с 2.0.1 до 1.6 на одном тестовом устройстве. Откат должен быть запланированным шагом, а не экстренной мерой.

4.3 Этап 3: Выполнение (продолжительность зависит от масштаба)

Шаг 6: Проверка тестовой среды. Выполните следующие тесты в изолированной среде:

• 2.0.1 Установление и поддержание соединения между зарядным устройством и CSMS

• Полный цикл сеанса зарядки (запуск/остановка, выставление счетов, отчетность по данным)

• Установка, продление и обработка TLS-сертификатов

• Составление отчетов и анализ журналов безопасности

• Моделирование неисправностей (потеря связи, недействительный сертификат, сбой проверки подписи микропрограммы)

Шаг 7: Пилотный производственный проект. Для первой партии миграции выберите сайт с низким уровнем риска — с меньшим трафиком и управляемым влиянием сбоев. Проводите мониторинг в течение как минимум двух недель и подтвердите соответствие следующих показателей базовым значениям до миграции: процент успешных списаний, точность выставления счетов, среднее время реагирования на сбои, процент успешных платежей пользователей.

Шаг 8: Поэтапное внедрение. После каждой партии переноса оборудования необходимо выждать не менее недели для наблюдения, прежде чем начинать следующую партию. Не переносите более 201 TP3T зарядных устройств за один период технического обслуживания — в случае возникновения проблем радиус воздействия останется под контролем.

4.4 Этап 4: Валидация и оптимизация (продолжается)

После миграции необходимо постоянно отслеживать следующие показатели по сравнению с исходными значениями до миграции:

• Показатель успешности сеансов зарядки

• Частота прерываний связи и время восстановления

• Распределение количества и типов событий безопасности

• Целостность данных о транзакциях и точность выставления счетов

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

5. Распространенные ошибки и как их избежать

Ниже перечислены наиболее часто встречающиеся ошибки, наблюдаемые в реальных проектах миграции.

Ошибка 1: Игнорирование аппаратных ограничений. Самая дорогостоящая ошибка — это предположение, что существующее оборудование поддерживает OCPP 2.0.1, а затем обнаружение в процессе миграции того факта, что контроллер недостаточно мощный — зарядные устройства испытывают скачки задержки во время установления TLS-соединения, что ухудшает пользовательский опыт. Чтобы избежать этого, проведите аудит оборудования на этапе оценки.

Ошибка 2: Начало миграции при неполной поддержке платформы. Некоторые поставщики CSMS заявляют о “поддержке OCPP 2.0.1”, но реализовали только базовый набор сообщений, упустив расширенные функции, такие как интеллектуальная зарядка или ведение журналов безопасности. Перед миграцией потребуйте от поставщика предоставить подробный список функций его реализации OCPP 2.0.1 — не принимайте ответ “мы это поддерживаем”. Требуйте конкретики вплоть до типа сообщения.

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

Ошибка 4: Одновременная миграция всей сети. Независимо от размера сети, поэтапная миграция с пакетной проверкой и периодами отката — единственный безопасный путь. Максимальный объем миграции в рамках одного периода технического обслуживания определяется возможностями реагирования вашей оперативной группы в случае сбоя.

Ошибка 5: Отслеживание только технических показателей, игнорирование операционных. Успешность миграции определяется не как “зарядное устройство обменивается данными”, а как “оперативные данные соответствуют или превышают базовые показатели до миграции”. Точность выставления счетов, процент успешных платежей и объем жалоб пользователей должны быть частью критериев завершения миграции, а не только технической проверки.

6. Краткое содержание документа по безопасности

Архитектура безопасности OCPP 2.0.1 построена на следующих принципах:

Многоуровневая защита: безопасность не зависит от одного механизма. Шифрование TLS защищает транспортный уровень. Управление сертификатами защищает идентификацию и аутентификацию. Подписание микропрограммы обеспечивает целостность кода. Ведение журналов безопасности обеспечивает контрольные записи. Сбой любого отдельного уровня не должен привести к краху общей системы безопасности.

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

Управление жизненным циклом безопасности: Сертификаты имеют сроки действия. Ключи подписи микропрограммного обеспечения могут быть заменены. Журналы безопасности автоматически удаляются по истечении срока их хранения. Безопасность — это не разовая настройка, а процесс жизненного цикла, требующий постоянного оперативного внимания.

Что это означает для операторов безопасности на практике: развертывание OCPP 2.0.1 не гарантирует автоматическую безопасность. Вам необходимо настроить TLS-сертификаты, управлять жизненным циклом сертификатов, отслеживать журналы безопасности и обрабатывать события истечения срока действия и отзыва сертификатов. Версия 2.0.1 предоставляет возможности обеспечения безопасности — преобразование этих возможностей в реальную безопасность остается ответственностью оператора.

7. Протоколы OCPP против собственных протоколов: долгосрочные риски для CPO.

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

Привязка к поставщику. Использование проприетарного протокола означает, что ваша зарядная сеть может работать только с конкретной платформой определенного производителя. Если вас не устроит производительность оборудования, цена или качество обслуживания, стоимость смены поставщика будет равна стоимости перестройки всего коммуникационного уровня вашей сети. Стоимость и сроки такой миграции, как правило, превышают любую экономию от первоначальной покупки оборудования.

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

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

Направление развития отрасли очевидно. Программа сертификации OCA стимулирует тестирование на соответствие стандарту OCPP 2.0.1. Крупные поставщики платформ и оборудования завершили или завершают внедрение версии 2.0.1. Если вы принимаете решения о закупках сегодня, требование поддержки OCPP 2.0.1 не является гарантией соответствия будущим требованиям — это базовый уровень для текущей технической оценки.

8. Контрольный список действий CPO

Если вы в настоящее время используете сеть OCPP 1.6:

1. Запросите у поставщика оборудования информацию о совместимости с OCPP 2.0.1 для каждой модели зарядного устройства (не рекламные материалы, а технические характеристики).

2. Запросите у поставщика CSMS подробный список поддерживаемых функций OCPP 2.0.1.

3. Определить 1–2 участка с низким уровнем риска и разработать пилотный план миграции.

4. Включить поддержку OCPP 2.0.1 в технические требования к закупке всего нового оборудования.

Если вы приобретаете новое оборудование и строите новые объекты:

1. В тендерной документации следует явно указать требование поддержки OCPP 2.0.1 (полной версии, а не её подмножества).

2. Требовать от поставщиков предоставления сертификатов OCA или эквивалентных отчетов о результатах испытаний на соответствие от третьих лиц.

3. Требовать от CSMS поддержки как OCPP 1.6, так и 2.0.1 — это обеспечит совместимость с будущими дополнениями к оборудованию версии 1.6.

4. Включите полную функциональную проверку набора сообщений OCPP 2.0.1 в приемочное тестирование.