ГОСТ Р 58123-2018 Транспорт дорожный. Интерфейс связи автомобиль-электрическая сеть. Часть 2. Требования к протоколу сетевого и прикладного уровней

[V2G2-001]

В настоящем стандарте, если RFC-ссылка была обновлена одним или несколькими RFC, то изменение применяется полностью.

[V2G2-002]

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

[V2G2-003]

Все опубликованные списки ошибок для RFC-ссылок полностью действительны для настоящего стандарта.

[V2G2-004]

Каждый субъект V2G должен использовать сертификаты X.509v3 вследствие необходимости расширений для хранения параметров криптосистемы на основе эллиптических кривых. Дополнительные сведения см. в [4].

Поле сертификата

Описание

Версия

Версия сертификата (для настоящего стандарта должна быть v3=0x2)

Серийный номер

Уникальный номер сертификата (в домене эмитента)

Алгоритм подписи

Используемый алгоритм подписи

Эмитент

Субъект, который выпустил и подписал сертификат

Срок действия

Период времени, в течение которого сертификат действителен

Субъект

Субъект, которому выдан сертификат

Открытый ключ

Открытый ключ, соответствующий закрытому ключу

Уникальный идентификатор эмитента

Факультативный уникальный идентификатор эмитента

Уникальный идентификатор субъекта

Факультативный уникальный идентификатор субъекта

Расширения

Дополнительно (см. таблицу 2)

Подпись

Подпись сертификата, генерируемая эмитентом

Расширения сертификатов

Описание

Применение ключей

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

Расширенное применение ключей

Дальнейшее описание применения ключей с использованием идентификаторов объекта, например:

аутентификация сервера (1.3.6.1.5.5.7.3.1),

аутентификация клиента (1.3.6.1.5.5.7.3.2).

Примечание - Иногда также кодируются следующие значения:

Netscape SGC (1.3.6.1.4.1.311.10.3.3),

Microsoft SGC (2.16.840.1.113730.4.1).

SGC расшифровывается как Server Gated Crypto (управляемая сервером криптография) и показывает, что сервер может также использовать криптографию для связи с браузером клиента. Это расширение использовалось во времена строгого криптографического экспортного контроля для обеспечения надлежащей защиты передачи данных финансовым веб-сайтом

Точка рассылки CRL

Место получения списков отозванных сертификатов

OCSP

Место получения ответа OCSP (существует только для сертификатов Sub-CA). См. подробности в [5]

Авторизационная информация

Дополнительная авторизационная информация

Альтернативное имя субъекта

Альтернативные имена субъекта

Базовое ограничение=CA

При условии, что сертификат является корневым сертификатом V2G или сертификатом Sub-CA

[V2G2-005]

Каждый субъект должен поддерживать хэш-функцию SHA-256 (процесс подписания) в соответствии с [7] [для идентификатора в случае использования по ГОСТ Р 58122 (ИСО 15118-1:2013):F1].

[V2G2-006]

Для каждого субъекта V2G процесс подписания должен быть на базе криптографии с использованием эллиптических кривых (secp256r1[представление SECG]) с алгоритмом подписи ECDSA [для идентификатора в случае использования по ГОСТ Р 58122 (ИСО 15118-1:2013):F1].

[V2G2-007]

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

[V2G2-885]

Все валидации сертификатов должны осуществляться в соответствии с [4]. EVCC и SECC могут помещать в кэш результаты валидации сертификатов во время одного сеанса зарядки.

[V2G2-926]

Должны поддерживаться расширения сертификатов, указанные в приложении B. Отклонения указаны, где это необходимо.

[V2G2-925]

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

[V2G2-910]

EVCC должен реализовывать механизм проверки сроков действия сертификатов и ответов OCSP.

[V2G2-886]

EVCC может выбирать точность своего источника времени по своему усмотрению, но он должен соблюдать выбранную точность при использовании этого источника времени. Точность должна быть по крайней мере равна одному дню.

[V2G2-887]

SECC должен обеспечивать наличие для себя в любой момент времени сертификата со сроком действия не менее чем на один час больше.

[V2G2-008]

Каждый EVCC должен поддерживать не менее одного корневого сертификата V2G.

[V2G2-877]

Каждый SECC должен поддерживать хранение не менее чем 10 корневых сертификатов V2G.

[V2G2-009]

Ограничение длины пути дерева сертификата PKI должно составлять 3.

[V2G2-010]

Размер сертификата в кодированной по DER форме должен быть не больше 800 байтов. Для передачи все сертификаты должны быть кодированными по DER.

[V2G2-011]

Срок действия любых корневых сертификатов V2G должен быть 40 лет.

[V2G2-012]

В любой момент времени должен быть в наличии корневой сертификат V2G, действительный для каждого CA корневых сертификатов V2G по крайней мере в течение последующих 35 лет.

[V2G2-878]

Максимальное число одновременно действительных корневых сертификатов V2G для одного корневого CA никогда не должно быть больше 10.

[V2G2-867]

Корень V2G не должен выдавать листовой сертификат.

[V2G2-869]

CA или Sub-CA не должен выпускать и подписывать сертификат, который действителен в течение срока действия, который больше, чем срок действия его самого как подписывающего субъекта.

[V2G2-911]

Если используется только один уровень Sub-CA, т.е. Sub-CA, подписанный корневым CA, непосредственно подписывает листовые сертификаты, профиль Sub-CA 2 должен действовать для данного Sub-CA.

[V2G2-882]

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

[V2G2-927]

EVCC должен рассматривать хранимые корневые сертификаты частного оператора как якоря доверия для проверки сертификатов SECC.

[V2G2-883]

Сроки действия сертификатов SECC, имеющих надежный корневой сертификат частного оператора в качестве их якоря доверия, могут быть выбраны подписывающим сертификат на его усмотрение.

[V2G2-868]

Для частной среды органы Sub-CA и ответы OCSP не поддерживаются.

[V2G2-630]

Поддержка TLS обязательна для EVCC для всех идентификационных режимов, кроме идентификационного режима EIM с набором сообщений зарядки переменным током с EIM и набором сообщений зарядки постоянным током с EIM, исключая в обоих случаях набор сообщений дополнительных услуг (ДУ), как указано в 8.6.

[V2G2-631]

Поддержка TLS обязательна для SECC для всех идентификационных режимов, кроме идентификационного режима EIM в безопасной среде с набором сообщений зарядки переменным током с EIM и набором сообщений зарядки постоянным током с EIM, исключая в обоих случаях набор сообщений ДУ, как указано в 8.6.

[V2G2-632]

Если используется сеанс связи без TLS, SECC должен только обеспечивать идентификационный режим EIM и наборы сообщений зарядки переменным током с EIM или зарядки постоянным током с EIM, указав "ExternalPayment" в параметре PaymentOptionList сообщения ServiceDiscoveryRes, как указано в 8.4.3.3.3.

[V2G2-633]

Если используется сеанс связи без TLS, EVCC должен принимать только идентификационный режим EIM с наборами сообщений зарядки переменным током с EIM или зарядки постоянным током с EIM независимо от предложения SECC также других идентификационных режимов и наборов сообщений.

[V2G2-634]

Если используется сеанс связи без TLS, SECC не должен выдавать наборы сообщений PnC.

[V2G2-635]

Если используется сеанс связи без TLS, EVCC не должен применять наборы сообщений PnC.

[V2G2-636]

Если используется сеанс связи без TLS, SECC не должен выдавать набор сообщений ДУ.

[V2G2-637]

Если используется сеанс связи без TLS, EVCC не должен применять набор сообщений ДУ.

[V2G2-638]

Меры безопасности для дополнительных услуг, разрешаемых набором сообщений ДУ (предлагаемых в ServiceDiscoveryRes), не рассматриваются в настоящем стандарте.

[V2G2-639]

Если TLS не применяется, обе стороны должны обеспечить невозможность изменения в текущем сеансе зарядки идентификационного режима EIM на другой идентификационный режим и изменения набора сообщений зарядки переменным током с EIM или набора сообщений постоянным током с EIM на другой набор сообщений (чтобы избежать снижения безопасности сеанса в результате изменений).

[V2G2-640]

Если применяется TLS, обе стороны должны обеспечить, чтобы выключение TLS приводило к завершению сеанса зарядки (чтобы избежать снижения безопасности сеанса в результате изменений).

Другая среда (небезопасная)

Безопасная среда

Разрешенные наборы сообщений

Постоянный ток с EIM

Переменный ток с EIM

Постоянный ток с EIM, ДУ

Переменный ток с EIM, ДУ

Постоянный ток с EIM

Переменный ток с EIM

Постоянный ток с EIM, ДУ

Переменный ток с EIM, ДУ

EVCC

Поддержка TLS

Факультативно

Факультативно

Обязательно

Обязательно

Факультативно

Факультативно

Обязательно

Обязательно

SECC

Поддержка TLS

Обязательно

Обязательно

Обязательно

Обязательно

Факультативно

Факультативно

Обязательно

Обязательно

Согласование использования TLS с помощью SDP

EV решает, EVSE должно принять решение EV

EV решает, EVSE должно принять решение EV

EV должно использовать TLS, EVSE должно отклонить, если EV не использует TLS

EV должно использовать TLS, EVSE должно отклонить, если EV не использует TLS

См. таблицу 4

См. таблицу 4

EV должно использовать TLS, EVSE должно отклонить, если EV не использует TLS

EV должно использовать TLS, EVSE должно отклонить, если EV не использует TLS

Относится к сообщениям, описанным в настоящем стандарте. В случае ДУ, конечно, возможны другие соединения (которые, не входят в настоящий стандарт).

Отклонение означает прекращение коммуникации.

См. определение в [1].

Поддержка TLS EVCC

Поддержка TLS SECC

Запрос SDP EVCC

Ответ SDP от SECC

EVCC имеет поддержку TLS

SECC имеет поддержку TLS

EVCC дает сигнал TLS

SECC должен ответить TLS

EVCC дает сигнал TCP

SECC должен ответить TCP

SECC не имеет поддержки TLS

EVCC дает сигнал TLS

SECC может показать, что он не поддерживает TLS, показав "0x10=нет безопасности транспортного уровня" в его ответе SDP. EV может принять решение о своем желании установить TCP без TLS или прекратить установление связи

EVCC дает сигнал TCP

SECC должен ответить TCP

EVCC не имеет поддержки TLS

SECC имеет поддержку TLS

EVCC дает сигнал TCP

SECC должен ответить TCP

SECC не имеет поддержки TLS

EVCC дает сигнал TCP

SECC должен ответить TCP

[V2G2-643]

EVSE должно поддерживать меры безопасности, описанные в ГОСТ Р МЭК 61851-1 и [8], для защиты от перенапряжений и перегрузок по току при использовании идентификационного режима EIM для зарядки переменным током.

[V2G2-644]

EVSE должно поддерживать меры безопасности, описанные в ГОСТ Р МЭК 61851-1 и [9], для защиты от перенапряжений и перегрузок по току при использовании идентификационного режима EIM для зарядки постоянным током.

[V2G2-014]

После установления соединения на канальном уровне (D-LINK_READY.indication(DLINKSTATUS=Link established) EVCC должен инициировать механизм присваивания IP-адресов, как указано в 7.6.3.2 и 7.6.3.3.

[V2G2-016]

EVCC должен отработать механизм присваивания IP-адресов, как указано в 7.6.3.2 и 7.6.3.3.

[V2G2-017]

EVCC должен остановить механизм присваивания IP-адресов, как указано в 7.6.3.2 и 7.6.3.3, когда V2G_EVCC_CommunicationSetup_Timer равен или больше V2G_EVCC_CommunicationSetup_Timeout.

[V2G2-018]

После присвоения локального IP-адреса канала EVCC должен начать процесс обнаружения адреса SECC, как указано в 7.10.1.

[V2G2-019]

EVCC должен запустить клиента SDP в соответствии с 7.10.1.

[V2G2-645]

В зависимости от протокола безопасности и транспортного протокола, запрошенного в сообщении-запросе SDP, ожидаемого протокола безопасности и транспортного протокола, отправленного сервером SDP, EV должно принять решение о применении TLS.

[V2G2-020]

EVCC должен остановить SDP, когда V2G_EVCC_CommunicationSetup_Timer равен или больше V2G_EVCC_CommunicationSetup_Timeout.

[V2G2-021]

Если EV принимает решение о применении соединения с обеспечением безопасности, EVCC должен установить соединение TLS с SECC, как описано в 7.7.3, после обнаружения IP-адреса SECC, порта, имеющихся транспортного протокола и опций безопасности.

[V2G2-646]

Если EV принимает решение о применении соединения без обеспечения безопасности, EVCC должен установить подключение TCP к SECC, как описано в 7.7.1, после обнаружения IP-адреса SECC, порта, имеющихся транспортного протокола и опций безопасности.

[V2G2-022]

В зависимости от [V2G2-021] и [V2G2-646] EVCC должен попытаться установить соединение с TLS или TCP в соответствии с 7.7.3.

[V2G2-023]

EVCC должен прекратить попытки установить соединение с TLS или TCP, когда V2G_EVCC_CommunicationSetup_Timer равен или больше V2G_EVCC_CommunicationSetup_Timeout.

[V2G2-024]

После установления соединения с TLS или TCP EVCC должен инициировать сеанс связи V2G, как описано в разделе 8.

[V2G2-025]

EVCC должен прекратить соединение с TLS или TCP после остановки сеанса связи V2G.

[V2G2-717]

Если EVCC отправил сообщение SessionStopReq с параметром ChargingSession, равным "Terminate", он должен прекратить Data-Link (D-LINK_TERMINATE.request()) после получения сообщения SessionStopRes.

[V2G2-718]

Если EVCC отправил сообщение SessionStopReq с параметром ChargingSession, равным "Pause", он должен сделать паузу Data-Link (D-LINK_PAUSE.request()) после получения сообщения SessionStopRes и продолжить выполнение [V2G2-014].

[V2G2-719]

Каждый раз, когда EVCC получает указание на отсутствие канала обмена данными (D-LINK_READY.indication (DLINKSTATUS=No link), он должен продолжить выполнение [V2G2-014].

[V2G2-720]

Если EVCC определяет какую-либо ошибку, он должен указать на ошибку канала обмена данными (D-LINK_ERROR.request()) и продолжить выполнение [V2G2-014].

[V2G2-721]

После указания на успешное установление канала обмена данными (D-LINK_READY.indication(DLINKSTATUS=Link established) SECC должен инициировать механизм присваивания адресов.

[V2G2-026]

SECC должен сконфигурировать IP-адрес (статический или динамический) с помощью любого надлежащего механизма.

[V2G2-027]

После присвоения IP-адреса SECC должен запустить сервер SDP, как указано в 7.10.1.

[V2G2-723]

SECC должен остановить сервер SDP, когда SECC_CommunicationSetup_Timer равен или больше V2G_SECC_CommunicationSetup_Performance_Time.

[V2G2-029]

SECC должен остановить механизм присваивания IP-адресов, когда V2G_SECC_CommunicationSetup_Timer равен или больше V2G_SECC_CommunicationSetup_Performance_Time.

[V2G2-030]

После того как сервер SDP успешно запущен, SECC должен ожидать инициализации соединения с TLS или TCP в зависимости сообщения-ответа SDP, как указано в 7.10.1.5.

[V2G2-031]

SECC должен ожидать установления соединения с TLS или TCP.

[V2G2-032]

SECC должен прекратить ожидание установления соединения с TLS, когда V2G_SECC_CommunicationSetup_Timer равен или больше V2G_SECC_CommunicationSetup_Performance_Time.

[V2G2-033]

После установления соединения с TLS или TCP SECC должен ожидать инициализации сеанса связи V2G, как описано в разделе 8.

[V2G2-722]

Если [V2G2-033] применимо, SECC может остановить сервер SDP после успешного установления соединения с TLS или TCP.

[V2G2-034]

SECC должен прекратить соединение с TLS или TCP после остановки сеанса связи V2G.

[V2G2-724]

Если SECC получил сообщение SessionStopReq с параметром ChargingSession, равным "Terminate", он должен прекратить работу с каналом обмена данными (D-LINK_TERMINATE.request()) после отправления сообщения SessionStopRes.

[V2G2-725]

Если SECC получил сообщение SessionStopReq с параметром ChargingSession, равным "Pause", он должен сделать паузу в работе с каналом обмена данными (D-LINK_PAUSE.request()) после отправления сообщения SessionStopRes и продолжить выполнение [V2G2-721].

[V2G2-726]

Каждый раз, когда SECC получает указание на отсутствие канала обмена данными (D-LINK_READY.indication (DLINKSTATUS=No link), он продолжает выполнение [V2G2-721].

[V2G2-727]

Если SECC определяет какую-либо ошибку, он должен указать на ошибку канала обмена данными (D-LINK_ERROR.request()) и продолжить выполнение [V2G2-721].

[V2G2-035]

Если EVCC осуществляет связь через PLC, EVCC должен соответствовать [1].

[V2G2-036]

Если SECC осуществляет связь через PLC, SECC должен соответствовать [1].

[V2G2-037]

Субъект V2G должен поддерживать IPv6 в соответствии с [11].

[V2G2-038]

Хотя [11] описывает IPsec как обязательный, от субъекта V2G не требуется реализация IPsec.

[V2G2-039]

Ни от какого субъекта V2G не требуется реализации заголовка маршрутизации RH0, как указано в [12].

[V2G2-040]

Субъект V2G должен реализовывать определение MTU в соответствии с [14].

[V2G2-041]

Субъект V2G должен поддерживать обработку наложений фрагментов IP в соответствии с [15].

[V2G2-042]

При отправлении пакета IPv6 от EVCC к SECC или от SECC к EVCC IP-фрагментация не должна использоваться.

[V2G2-043]

Если EVCC решает ввести в действие клиента DHCPv6, то он должен осуществлять это, как описано в [17].

[V2G2-044]

Если инфраструктура, к которой подключено EV (EVSE), решает реализовать сервер DHCPv6, то она должна осуществлять это, как описано в [17].

[V2G2-045]

EVCC должен реализовывать обнаружение соседних объектов в соответствии с [18].

[V2G2-046]

EVCC должен соответствовать [19], допуская присвоение IP-адресов до завершения определения адресов-дубликатов.

[V2G2-047]

Каждый субъект V2G должен реализовывать ICMPv6, как описано в [20].

[V2G2-049]

Каждый субъект V2G должен реализовывать нормы RFC, на которые даются ссылки в колонке "Ссылка" таблицы 5, описывающей детали реализации для соответствующих типов сообщений ICMP.

Тип сообщения ICMP

Имя сообщения ICMP

Ссылка

1

Пункт назначения недостижим

[20]

2

Пакет слишком велик

[20]

3

Превышено время

[20]

4

Проблема параметра

[20]

128

Эхо запроса

[20]

129

Эхо ответа

[20]

133

Запрос маршрутизатора

[18]

134

Объявление маршрутизатора

[18]

135

Запрос соседнего объекта

[18]

136

Объявление соседнего объекта

[18]

137

Перенаправление сообщения

[18]

141

Обратное сообщение с запросом об обнаружении соседнего объекта

[21]

142

Обратное сообщение с объявлением об обнаружении соседнего объекта

[21]

[V2G2-050]

Каждый субъект V2G должен поддерживать конфигурацию индивидуального локального адреса канала IPv6, как указано в [22].

[V2G2-051]

Идентификатор интерфейса локального адреса канала субъекта V2G должен генерироваться из его 48-битового MAC-идентификатора IEEE в соответствии с [22].

[V2G2-052]

EVCC должен поддерживать автоконфигурирование адресов IP6, как описано в [23].

[V2G2-053]

Если SECC выдает наборы сообщений установки сертификатов, обновления сертификатов или дополнительные услуги, как указано в 8.6.2, он должен поддерживать варианты объявления маршрутизатора IPv6 в соответствии с [24] для предоставления адреса сервера DNS.

[V2G2-054]

Если поддерживаются несколько адресов IPv6, выбор адресов IPv6 по умолчанию должен выполняться в соответствии с [25].

[V2G2-055]

Каждый субъект V2G должен осуществлять реализацию TCP, как указано в [26].

[V2G2-057]

Каждый субъект V2G должен реализовывать управление TCP в условиях перегрузки в соответствии с [27].

[V2G2-058]

Каждый субъект V2G должен реализовывать модификацию NewReno к алгоритму быстрого восстановления TCP в соответствии с [28].

[V2G2-059]

Каждый субъект V2G должен рассчитать для TCP таймер повторной передачи в соответствии с [29].

[V2G2-060]

Для увеличения производительности TCP каждый субъект V2G должен реализовывать расширения TCP для повышения производительности в соответствии с [30].

[V2G2-061]

Каждый субъект V2G должен поддерживать опции избирательного подтверждения TCP в соответствии с [31].

[V2G2-062]

Каждый субъект V2G должен реализовывать опцию пользовательского тайм-аута в соответствии с [32].

[V2G2-063]

Указатель срочности для TCP не должен использоваться каким-либо субъектом V2G.

[V2G2-064]

Поля контрольной суммы, требующиеся в заголовках TCP, должны реализовываться в соответствии с [33].

[V2G2-065]

Каждый субъект V2G должен осуществлять реализацию протокола пользовательских дейтаграмм в соответствии с [34].

[V2G2-067]

Односторонняя аутентификация с TLS версии 1.2 в соответствии с [35] с расширениями в соответствии с [36] должна поддерживаться каждым субъектом V2G. EVCC аутентифицирует SECC путем проверки цепочки сертификатов SECC, передаваемой от SECC к EVCC.

[V2G2-068]

SECC должен всегда действовать как компонент сервера TLS.

[V2G2-070]

Каждый EVCC должен проверять действительность сертификатов Sub-CA (в цепочке сертификатов SECC) через ответ OCSP в соответствии с [5], когда используется TLS. Запросы OCSP должны транспортироваться как часть подтверждения TLS с использованием расширения, указанного в [37].

[V2G2-870]

"Режим сопряжения" EV может быть установлен с помощью фирменного механизма изготовителя. Данный "режим сопряжения" должен активироваться только определенным взаимодействием пользователя. Данный режим должен автоматически сбрасываться через 120 с.

[V2G2-649]

SECC должен обновлять (помещать в кэш) ответ OCSP не реже чем раз в неделю. Одним из решений для обновления может быть, например, онлайновое соединение.

[V2G2-876]

Срок действия ответа OCSP для Sub-CA 1 и Sub-CA 2 должен быть не дольше четырех недель.

[V2G2-650]

Хотя срок действия на EVCC не является обязательным, EVCC должен реализовывать механизм исключения устаревших сертификатов от SECC.

[V2G2-651]

EVCC должен отправить список корневых сертификатов V2G, которые он имеет, расширение типа "trusted_ca_keys" в (расширенном) приветствии клиента в соответствии с [36].

[V2G2-871]

Если SECC развернут в среде, которая не является частной средой, он должен отправить свой собственный сертификат и цепочку до корня (исключая сам корневой сертификат), который должен быть одним из тех корней, на которые ранее указал EVCC как на присутствующие в EVCC. Если EVCC запросил ответы OCSP для каждого сертификата, которому сервер TLS отвечает, ответ OCSP должен быть отправлен EVCC в соответствии с [5] (пункт 4.2.1). SECC должен также направить сертификат отвечающего OCSP, если он не использует расширение в соответствии с [37]. Ответчик OCSP должен заполнить поле "certs" в структуре ответа OCSP (BasicOCSPResponse) соответствующим Sub-CA.

[V2G2-923]

Если SECC не может предоставить сертификат с цепочкой до одного из корней, на который указывал EVCC как на присутствующий в EVCC, SECC должен представить в составе подтверждения TLS действительный сертификат, включая цепочку до корневого сертификата (сам корневой сертификат не должен передаваться).

[V2G2-924]

Если SECC выдал цепочку сертификатов, которая не прослеживается до корневого сертификата в списке надежных сертификатов, EVCC должен принять такой сертификат, только если он выполнил успешную валидацию цепочки сертификатов с помощью механизма внешней валидации (например, протокол валидации сертификатов на базе сервера, простой протокол валидации сертификатов SCVP). Если валидация с помощью такого сервиса не выполняется, дает отрицательный результат или не удается (например, вследствие отсутствия соединения), EVCC должен рассматривать цепочку сертификатов как не прошедшую валидацию.

[V2G2-872]

Если SECC развернут в частной среде, то он не должен отправлять ответ OCSP, а должен включить свой собственный частный корневой сертификат в цепочку сертификатов, которую он посылает.

[V2G2-873]

Если EVCC запросил ответ OCSP через "client hello" TLS и сервер TLS не отправил ответы OCSP в "server hello", EVCC должен выполнить следующее:

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

- если цепочка сертификатов сервера TLS привязана к корню V2G, EVCC должен прервать соединение TLS.

[V2G2-874]

Если режим сопряжения активирован, EVCC получает новый корневой сертификат от SECC во время подтверждения TLS и новый корневой сертификат выполняет требования для частного корневого сертификата (см. приложение B), то EVCC должен принять новый корневой сертификат, хранить его постоянно и обращаться с ним как с частным корневым сертификатом.

[V2G2-875]

EVCC должен проверить сертификат SECC, полную цепочку сертификатов и все ответы OCSP (если применимо, включая действительность ответчика OCSP). EVCC должен также проверить, что сертификат SECC имеет компонент домена, установленный на "CPO". Если результат хотя бы одной из этих проверок будет отрицательным, EVCC должен прекратить процесс установления TLS и применить [V2G2-023].

[V2G2-810]

SECC должен поддерживать согласование максимальной длины фрагмента в соответствии с [36].

[V2G2-811]

SECC должен быть способен поддерживать максимальную длину фрагмента байта, но не быть ограниченным этим числом, в соответствии с [36].

[V2G2-071]

Каждый субъект V2G должен предоставлять удостоверения и информацию о безопасности, указанную в таблице 6, если используется TLS.

Аутентификация TLS

Требования к EVCC

Требования к SECC

Односторонняя (сторона сервера)

Наличие корневых сертификатов для проверки аутентичности сертификата SECC.

Функциональная поддержка обработки запросов/ответов OCSP для проверки состояния валидации сертификата SECC во время подтверждения TLS

Ответ SECC в виде сертификата и соответствующего закрытого ключа OCSP для предоставления информации о состоянии валидации собственного сертификата SECC.

SECC должен помещать в кэш и сохранять внутри ответы OCSP для собственной цепочки сертификатов Sub-CA регулярно (не реже чем еженедельно)

[V2G2-602]

SECC должен поддерживать все наборы шифров, указанные в таблице 7, если используется TLS.

[V2G2-603]

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

Набор шифров

RFC

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

[38]

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

[38]

Имя

Протокол

Номер порта

Описание

V2G_SRC_TCP_DATA

TCP (с адресацией конкретному устройству)

Номер порта в диапазоне динамических портов (49152-65535), как описано в [39]

Порт-источник V2GTP первичного субъекта (например, EVCC), который реализует протокол V2GTP

V2G_DST_TCP_DATA

TCP (с адресацией конкретному устройству)

Номер порта субъекта V2GTP, предоставляющего номер порта назначения в диапазоне динамических портов (49152-65535), как описано в [39]. Для SECC он присваивается динамически механизмом SDP (7.10.1)

Порт назначения V2GTP первичного субъекта (например, SECC)

[V2G2-073]

Субъект V2GTP, предоставляющий порт назначения, должен поддерживать не менее одного соединения на локальном порте V2G_DST_TCP_DATA, как указано в таблице 8.

[V2G2-074]

Субъект V2GTP, предоставляющий порт назначения, может поддерживать несколько одновременных соединений на локальном порте V2G_DST_TCP_DATA, как указано в таблице 8.

[V2G2-075]

Субъект V2GTP, использующий порт-источник, должен поддерживать не менее одного соединения на локальном порте V2G_SRC_TCP_DATA, как указано в таблице 8.

[V2G2-076]

Субъект V2GTP, использующий порт-источник, может поддерживать несколько соединений на локальном порте V2G_SRC_TCP_DATA, как указано в таблице 8.

[V2G2-077]

EVCC должен использовать порт-источник V2G_SRC_TCP_DATA, как указано в таблице 8.

[V2G2-078]

SECC должен предоставлять порт назначения V2G_DST_TCP_DATA, как указано в таблице 8.

[V2G2-079]

EVCC должен поддерживать не менее одного соединения для сеанса связи V2G на порте V2G_SRC_TCP_DATA.

[V2G2-080]

SECC должен поддерживать не менее одного соединения для сеанса связи V2G на порте V2G_DST_TCP_DATA.

[V2G2-081]

EVCC должен использовать для соединения с SECC порт V2G_DST_TCP_DATA, выданный в последнем сообщении об обнаружении SECC (см. 7.10.1.5).

[V2G2-082]

Субъект V2GTP должен использовать структуру заголовка, показанную на рисунке 9.

[V2G2-083]

Субъект V2GTP должен отправить 8 байтов заголовка V2GTP в порядке, показанном на рисунке 9.

[V2G2-084]

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

[V2G2-085]

Субъект V2GTP должен отправлять поля "Тип полезных данных" и "Длина полезных данных" в формате с обратным порядком следования байтов: наиболее значимый байт передается первым, наименее значимый байт - последним.

Поле заголовка

Описание поля заголовка

Значения поля заголовка

Версия протокола

Идентифицирует версию протокола сообщений V2GTP

0x01:

V2GTP версия 1 0x00, 0x02-0xFF:

зарезервировано документом

Обратная версия протокола

Содержит обратное побитовое значение версии протокола и используется совместно с версией протокола V2GTP как схема проверки протокола, обеспечивающая получение правильно сформатированного сообщения V2GTP.

Эквивалентно функции: <Protocol_Version> XOR 0xFF

0xFE: V2GTP версия 1

Тип полезных данных (GH_PT)

Содержит информацию о том, как декодировать полезные данные, следующие после заголовка V2GTP

Полный перечень значений типов полезных данных см. в таблице 10

Длина полезных данных (GH_PL)

Содержит длину полезных данных сообщения V2GTP в байтах (т.е. исключая байты типового заголовка V2GTP)

0...4294967295 (= <d>)

Значение типа полезных данных

Имя типа полезных данных

Описывается в пункте

0x0000

-

0x8000

Зарезервировано

Неприменимо

0x8001

EXI-кодированное сообщение V2G

7.9.1.2

0x8002

-

0x8FFF

Зарезервировано

Неприменимо

0x9000

Сообщение с запросом SDP

7.10.1.4

0x9001

Сообщение с ответом SDP

7.10.1.5

0x9002

-

0x9FFF

Зарезервировано

Неприменимо

0xA000

-

0xFFFF

Специфичное использование изготовителя

Неприменимо

[V2G2-086]

Субъект V2GTP должен использовать структуру сообщения V2GTP, показанную на рисунке 8, для отправления сообщения V2G, как описано в разделе 8.

[V2G2-087]

Субъект V2GTP должен использовать определения, как указано в таблицах 9 и 10.

[V2G2-088]

Для EXI-кодированных сообщений V2G (полезные данные 0x8001) субъект V2GTP должен использовать отдельное сообщение V2GTP для каждого сообщения V2G.

[V2G2-089]

Субъект V2GTP должен обработать заголовок V2GTP, как указано в таблице 9, до обработки полезных данных, как определено в таблице 10.

[V2G2-090]

Субъект V2GTP должен проверить поля версии протокола и обратной версии протокола (последовательность синхронизирующих импульсов) перед какими-либо другими полями заголовка.

[V2G2-092]

Субъект V2GTP должен проверить тип полезных данных после успешной проверки поля версии и обратной версии протокола.

[V2G2-094]

Субъект V2GTP должен проверить длину полезных данных после успешной проверки типа полезных данных.

[V2G2-096]

Если обработка заголовка была успешной, субъект V2GTP должен обрабатывать полезные данные.

[V2G2-800]

Если заголовок V2GTP содержит неверные данные (например, не поддерживаемый тип полезных данных, неверную длину полезных данных или не поддерживаемую версию V2GTP), субъект V2GTP должен игнорировать это сообщение.

[V2G2-097]

При передаче сообщений V2G, описанных в настоящем стандарте, с использованием XML все субъекты V2G должны использовать формат кодирования в соответствии с определениями в [40].

[V2G2-098]

XML-схема с областью имен "urn:iso:15118:2:2013:msgDef", которая представляет собой версию ISO 15118 2.0 (основной номер версии "2", дополнительный - "0"), должна использоваться для кодирования и декодирования EXI-потоков.

[V2G2-099]

EXI-кодер для кодирования и декодирования коммуникации в соответствии с [1], ГОСТ Р 58122 (ИСО 15118-1) и настоящим стандартом должен использовать опции кодирования EXI по умолчанию в соответствии с [40] (см. пункт "EXI Options"), за исключением опций, перечисленных в таблице 11.

Опция EXI

Описание

Значение ГОСТ Р (ИСО 15118-1:2013)

valuePartitionCapacity

Указывает допустимый диапазон числа разделов в таблице строк

0

[V2G2-100]

EXI-заголовок (см. [40], пункт "Header") должен использоваться способом, отвечающим требованиям [1], ГОСТ Р 58122 (ИСО 15118-1) и настоящего стандарта. Это означает, что факультативный EXI Cookie-файл ($EXI) никогда не должен использоваться и бит присутствия для опций EXI должен быть всегда установлен в 0 (=false). Как следствие, факультативные опции EXI никогда не должны быть частью сообщения [1], ГОСТ Р 58122 (ИСО 15118-1) и настоящего стандарта. Каждая реализация EXI (на EVCC или SECC) должна отбрасывать сообщения, которые не соблюдают опции заголовка EXI [1], ГОСТ Р 58122 (ИСО 15118-1) и настоящего стандарта.

[V2G2-101]

Элемент/атрибут, который не определен в области имен "urn:iso:15118:2:2013:msgDef", должен кодироваться и декодироваться как случай отклонения схемы в соответствии с [40] (пункт "Adding Productions when Strict is False").

[V2G2-600]

EXI-кодер для кодирования и декодирования коммуникации по [1], ГОСТ Р 58122 (ИСО 15118-1) и настоящему стандарту должен использовать настройки профиля EXI в соответствии с таблицей 12.

Параметр профиля EXI

Описание

Значение по ГОСТ Р 58122 (ИСО 15118-1:2013)

maximumNumberOfBuiltInElementGrammars

Эта опция является максимальным числом встроенных грамматик элементов, для которых динамически были добавлены продукции, не являющиеся продукциями thAT(xsi:type)

0

maximumNumberOfBuiltInProductions

Эта опция является максимальным числом продукций верхнего уровня, которые могут быть динамически вставлены во встроенные грамматики элементов, за исключением продукций AT(xsi:type)

0

[V2G2-102]

Простой тип/значение элемента/атрибута, который не определен в области имен "urn:iso:15118:2:2013:msgDef", должен кодироваться и декодироваться с учетом типа.

[V2G2-103]

Максимальный срок действия сертификата контракта должен быть не более двух лет.

[V2G2-104]

Минимальный срок действия сертификата, используемого для XML-подписи и обеспечения механизма для шифрования, должен быть четыре недели. Если срок действия контракта меньше, срок действия сертификата должен быть адаптирован к сроку действия контракта.

[V2G2-108]

EMAID должен кодироваться в предмете сертификата.

[V2G2-117]

Каждый субъект V2G должен поддерживать обособленные XML-подписи.

[V2G2-119]

Для операций XML-подписей подписываемые данные должны быть EXI-представлением этих данных.

[V2G2-764]

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

[V2G2-765]

Каждое сообщение, требующее структуры XML-подписи, должно использовать значение "http://www.w3.org/TR/canonical-exi/" в качестве атрибута алгоритма в элементе CanonicalizationMethod.

[V2G2-766]

Каждое сообщение, требующее структуры XML-подписи, должно использовать значение "http://www.w3.org/TR/canonical-exi/" в качестве атрибута алгоритма в элементе Transform.

[V2G2-767]

Максимальное число алгоритмов Transform ограничивается одним (1) (т.е. на один элемент, на который делается ссылка и для которого передается подпись, может быть указан только один алгоритм Transform).

[V2G2-768]

Части, которые должны быть подписаны в сообщениях на базе XML, должны кодироваться как фрагмент, учитывающий EXI-схему.

[V2G2-769]

Каждое сообщение, требующее структуры XML-подписи, должно использовать значение "http://www.w3.org/2001/04/xmldsig-more#ECDSA-sha256" в качестве атрибута алгоритма в элементе SignatureMethod.

[V2G2-770]

Каждое сообщение, требующее структуры XML-подписи, должно использовать значение "http://www.w3.org/2001/04/xmlenc#sha256" в качестве атрибута алгоритма в элементе DigestMethod.

[V2G2-771]

Следующие элементы сообщений со структурой XML-подписи не должны использоваться при передаче подписей в заголовке сообщения V2G:

- Id (attribute in SignedInfo);

- ##any in SignedInfo-CanonicalizationMethod;

- HMACOutputLength in SignedInfo-SignatureMethod;

- ##other in SignedInfo-SignatureMethod;

- Type (attribute in SignedInfo-Reference);

- ##other in SignedInfo-Reference-Transforms-Transform;

- XPath in SignedInfo-Reference-Transforms-Transform;

- ##other in SignedInfo-Reference-DigestMethod;

- Id (attribute in SignatureValue);

- Object (in Signature);

- KeyInfo.

[V2G2-909]

Подпись не должна относиться к более чем четырем подписываемым элементам.

[V2G2-121]

EVCC должен поддерживать расчет секретной функции и функции установления ключа ECDH для расшифровки зашифрованной информации, такой как закрытые ключи.

[V2G2-122]

Каждый субъект V2G должен иметь механизмы для выполнения обмена ключами ECDH. Открытые параметры являются производными от открытых параметров ECDSA.

[V2G2-814]

Закрытый ключ, соответствующий сертификату контракта, должен передаваться только в зашифрованном формате в сообщениях CertificateInstallationRes и CertificateUpdateRes - в составе ContractSignatureEncryptedPrivateKey.

[V2G2-815]

Закрытый ключ, соответствующий сертификату контракта, должен шифроваться отправителем (SA) с использованием ключа сеанса, полученного в протоколе ECDH (см. [V2G2-818]), и алгоритма AES-CBC-128 в соответствии с [43]. Вектор инициализации IV должен случайно генерироваться перед шифрованием, иметь длину 128 бит и никогда повторно не использоваться. Вектор инициализации IV должен передаваться в 16 старших байтах поля ContractSignatureEncryptedPrivateKey.

[V2G2-816]

Порядок байтов закрытого ключа должен быть обратным, включая ведущие нули

[V2G2-817]

Закрытый ключ, соответствующий сертификату контракта, должен декодироваться получателем (EVCC) с помощью ключа сеанса, полученного в протоколе ECDH (см. [V2G2-818]), с применением алгоритма AES-CBC-128 в соответствии с [43]. Вектор инициализации IV должен считываться из 16 старших байтов поля ContractSignatureEncryptedPrivateKey.

[V2G2-818]

Для согласования ключа сеанса должен использоваться эфемерно-статический протокол публикации [44]. KDF должен быть "конканатенационным KDF", в котором функция хеширования должна быть SHA256. SA должен действовать как сторона U (в соответствии с [44]), и EVCC должен действовать как сторона V. Протокол должен использовать эллиптические кривые, как указано в приложении B. Идентификатор алгоритма должен быть обозначен одним символом 0x01. Имя отправителя IDU должно быть обозначено одним символом "U"=0x55, имя получателя IDV - одним символом "V"=0x56. Должен быть получен симметричный ключ шифрования - точно 128 бит.

[V2G2-819]

Эфемерные открытые ключи должны кодироваться как "Subject Public Key" в соответствии с [45] и содержаться в XML-элементе "DHpublickey". Должна использоваться исключительно несжатая форма.

[V2G2-820]

В сообщении CertificateInstallationRes открытый ключ получателя QV должен быть открытым ключом, содержащимся в существующем сервисном сертификате изготовителя.

[V2G2-821]

В сообщении CertificateUpdateRes открытый ключ получателя QV должен быть открытым ключом, содержащимся в существующем сертификате контракта.

[V2G2-822]

Сертификат, пара ключей которого используется для ECDH, должен иметь установленные в единицу флаги использования ключей keyAgreement. Это требование действует для всех сертификатов контракта и всех сервисных сертификатов изготовителя и должно выполняться всеми участвующими сторонами.

[V2G2-823]

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

[V2G2-835]

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

XML-сообщение

Защищаемые поля

Подписывающий субъект (отправитель)

Проверяющий субъект (получатель)

AuthorizationReq

Тело сообщения/Все поля (если присутствует GenChallenge)

EVCC

SECC

CertificateUpdateReq

Тело сообщения/Все поля

EVCC; подписывается сертификатом контракта, цепочка передается в элементе тела сообщения

Вторичный субъект

CertificateUpdateRes

ContractSignatureCertChain

ContractSignatureEncryptedPrivateKey

DHpublickey

eMAID

Вторичный субъект: служба выдачи сертификатов

EVCC; цепочка сертификата сохраняется после успешной проверки

CertificateInstallationReq

Тело сообщения/Все поля

EVCC; подписывается сертификатом изготовителя, передается в элементе тела сообщения

Вторичный субъект

CertificateInstallationRes

ContractSignatureCertChain

ContractSignatureEncryptedPrivateKey

DHpublickey

ContractID

Вторичный субъект: служба выдачи сертификатов

EVCC; цепочка сертификата сохраняется после успешной проверки

MeteringReceiptReq

Тело сообщения/Все поля (дополнительно)

EVCC

SECC

ChargeParameterDiscoveryRes

SalesTariff (дополнительно, требуется для PnC)

Вторичный субъект: оператор услуг EV Sub-CA 2

EVCC

XML-сообщение

Защищаемые поля

Шифрующий субъект (отправитель)

Дешифрующий субъект (получатель)

CertificateUpdateRes

ContractSignatureEncryptedPrivateKey

Вторичный субъект

EVCC

CertificateInstallationRes

ContractSignatureEncryptedPrivateKey

Вторичный субъект

EVCC

[V2G2-652]

Каждый субъект V2G должен быть способен генерировать XML-подписи, как указано в таблице 13.

[V2G2-653]

Каждый субъект V2G должен быть способен проверять XML-подписи, как указано в таблице 13.

[V2G2-123]

Сервер SDP должен быть доступен по локальному каналу.

Имя

Протокол

Номер порта

Описание

V2G_UDP_SDP_CLIENT

UDP (адресация конкретному устройству)

Номер порта в диапазоне динамических портов (49152-65535) в соответствии с [39]

Порт источника клиента SDP на EVCC

V2G_UDP_SDP_SERVER

UDP (групповая адресация)

По ГОСТ Р 58123

Порт сервера SDP, который принимает пакеты UDP с групповым локальным IP-адресом назначения

[V2G2-124]

Клиент SDP должен поддерживать порт V2G_UDP_SDP_CLIENT для отправления и получения сообщений SDP, как указано в таблице 15.

[V2G2-125]

Сервер SDP должен поддерживать порт V2G_UDP_SDP_SERVER для получения и отправления сообщений SDP, как указано в таблице 15.

[V2G2-126]

Клиент SDP должен быть способен обрабатывать асинхронно получаемые сообщения с ответом об обнаружении SECC.

[V2G2-127]

Клиент SDP должен поддерживать определения 7.8.3.1.

[V2G2-128]

Клиент SDP должен использовать отдельный пакет UDP для каждого сообщения с запросом.

[V2G2-129]

Клиент SDP должен поместить первый байт заголовка сообщения с запросом, показанного на рисунке 9 и в таблице 9, в первом байте полезных данных пакета UDP.

[V2G2-130]

Сервер SDP должен поддерживать определения 7.8.3.1.

[V2G2-131]

Сервер SDP должен использовать отдельный пакет UDP для каждого ответа.

[V2G2-132]

Сервер SDP должен поместить первый байт заголовка сообщения-ответа, показанного на рисунке 9 и в таблице 9, в первом байте полезных данных пакета UDP.

[V2G2-133]

Клиент SDP должен применяться для обработки заголовка, как указано в 7.8.3.2.

[V2G2-134]

Сервер SDP должен применяться для обработки заголовка, как указано в 7.8.3.2.

[V2G2-135]

Только клиент SDP должен отправлять сообщения-запросы об обнаружении SECC.

[V2G2-136]

Клиент SDP должен отправлять сообщения-запросы об обнаружении SECC с IP-адресом источника, по которому он ожидает сообщение с ответом об обнаружении SECC.

[V2G2-137]

Клиент SDP должен отправлять сообщения-запросы об обнаружении SECC на порт назначения V2G_UDP_SDP_SERVER, как указано в таблице 15.

[V2G2-138]

Клиент SDP должен отправлять сообщения-запросы об обнаружении SECC с указанием на порт-источник V2G_UDP_SDP_CLIENT, как указано в таблице 15, на который он ожидает сообщение-ответ об обнаружении SECC.

[V2G2-139]

Клиент SDP должен отправлять сообщение-запрос об обнаружении SECC на групповой локальный адрес канала назначения (FF02::1), как описано в [22].

[V2G2-140]

Клиент SDP должен отправлять сообщение-запрос об обнаружении SECC со значением 0x9000 типа полезных данных, как указано в таблице 10.

[V2G2-141]

Клиент SDP должен отправлять сообщение-запрос об обнаружении SECC с длиной 2 полезных данных.

[V2G2-142]

Клиент SDP должен отправлять сообщение-запрос об обнаружении SECC с полезными данными, показанными на рисунке 15.

[V2G2-622]

Клиент SDP должен отправлять полезные данные в порядке, показанном на рисунке 15. Байт с меньшим номером должен отправляться перед байтом с большим номером. Полезные данные начинаются с байта 1 и заканчиваются байтом 2.

[V2G2-623]

Клиент SDP должен использовать кодирование для запрашиваемой опции безопасности и запрашиваемого транспортного протокола, как указано в таблице 16.

Описание

Безопасность

Транспортный протокол

N байта сообщения-запроса SDP

1

2

N байта сообщения-ответа SDP

19

20

Применяемые значения

0x00=защищено TLS

0x00= TCP

0x01-0x0F=зарезервировано

0x01-0x0F=зарезервировано

0x10=нет безопасности транспортного уровня

0x10=зарезервировано для TCP

0x11-0xFF=зарезервировано

0x11-0xFF=зарезервировано

[V2G2-143]

Сервер SDP должен быть способен извлечь IP-адрес источника и номер порта источника полученного пакета UDP (IP-адрес и номер порта клиента) и отправить пакет UDP на идентифицированный IP-адрес и номер порта.

[V2G2-144]

Сервер SDP должен ответить на любое сообщение-запрос об обнаружении SECC сообщением-ответом об его обнаружении.

[V2G2-145]

Клиент SDP не должен отвечать на любое сообщение-запрос об обнаружении SECC.

[V2G2-146]

Сервер SDP должен отправлять сообщения-ответы только после получения сообщения с запросом об обнаружении SECC.

[V2G2-147]

Сервер SDP должен отправлять сообщения-ответы об обнаружении SECC только после получения сообщения-запроса об обнаружении SECC.

[V2G2-149]

Сервер SDP должен отправить ответ SDP с портом источника V2G_UDP_SDP_SERVER, как указано в таблице 15.

[V2G2-150]

Сервер SDP должен отправлять сообщение-ответ об обнаружении SECC клиенту SDP, который отправил сообщение-запрос об обнаружении SECC.

[V2G2-151]

Сервер SDP должен отправлять сообщение-ответ об обнаружении SECC на порт клиента SDP, который отправил сообщение-запрос об обнаружении SECC.

[V2G2-152]

Сервер SDP должен отправлять сообщение-ответ об обнаружении SECC со значением 0x9001 типа полезных данных, как указано в таблице 10.

[V2G2-153]

Сервер SDP должен отправлять сообщение-ответ об обнаружении SECC с длиной полезных данных, равной 20.

[V2G2-154]

Сервер SDP должен отправлять сообщение-ответ об обнаружении SECC с полезными данными, показанными на рисунке 16.

[V2G2-155]

Сервер SDP должен отправлять полезные данные в порядке, показанном на рисунке 16. Байт с меньшим номером должен отправляться перед байтом с большим номером. Полезные данные начинаются с байта 1 и заканчиваются байтом 20.

[V2G2-156]

Сервер SDP должен отправлять поля "SECC IP Address" и "SECC Port" в формате с обратным порядком следования байтов: старший байт передается первым, младший байт - последним.

[V2G2-624]

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

[V2G2-157]

Клиент SDP должен подсчитывать число сообщений-запросов об обнаружении SECC до получения действительного сообщения-ответа об обнаружении SECC.

[V2G2-158]

Клиент SDP должен сбросить счетчик отправленных сообщений-запросов об обнаружении SECC после получения действительного сообщения-ответа об обнаружении SECC.

[V2G2-159]

После отправления сообщения-запроса об обнаружении SECC клиент SDP должен ожидать сообщения-ответа об обнаружении SECC не менее 250 мс.

[V2G2-160]

После безуспешного ожидания сообщения-ответа об обнаружении SECC клиент SDP должен отправить новое сообщение-запрос об обнаружении SECC и инкрементировать счетчик отправленных сообщений-запросов об обнаружении SECC.

[V2G2-161]

Если клиент SDP не получил никакого сообщения-ответа об обнаружении SECC после последовательного отправления максимум 50 сообщений-запросов об обнаружении SECC, он должен остановить обнаружение SECC.

[V2G2-162]

После прекращения обнаружения SECC клиент SDP должен перейти в такое же состояние, как и для тайм-аута (см. [V2G2-020] и рисунок 6).

[V2G2-625]

Если клиент SDP отправляет запрос SDP с кодом опции протокола для TCP ("TCP" в таблице 16), SECC должен отправить ответ SDP с кодом опции протокола "TCP".

[V2G2-626]

Если клиент SDP отправляет запрос SDP с кодом опции безопасности для TLS ("защищено TLS" в таблице 16) и SECC поддерживает TLS, сервер SDP должен отправить ответ SDP с кодом опции безопасности "TLS".

[V2G2-627]

Если клиент SDP отправляет запрос SDP с кодом опции безопасности для TLS ("защищено TLS" в таблице 16) и SECC не поддерживает TLS, сервер SDP должен отправить ответ SDP с кодом опции отсутствия безопасности "Нет безопасности транспортного уровня".

[V2G2-628]

EVCC в зависимости от случая использования и требований безопасности должен либо использовать протокол, как указано в ответе SDP от сервера SDP, либо остановить установление связи.

[V2G2-629]

Если EVCC пытается осуществлять обмен данными с помощью транспортного протокола, указанного в таблице 16, который отличается от опций протокола, указанных в ответе SDP от сервера SDP, SECC не должен принимать эту коммуникацию.

[V2G2-163]

Если SDP выдает глобальный IP-адрес SECC, EVCC не должен указывать обнаруженный IP-адрес SECC до тех пор, пока EVCC не сконфигурирует глобальный IP-адрес, как указано в 7.6.3.2 и 7.6.3.3.

[V2G2-164]

Если SDP выдает глобальный IP-адрес SECC, EVCC должен указать обнаруженный IP-адрес SECC после присвоения глобального адреса в соответствии с 7.6.3.2 и 7.6.3.3.

Имя примитива

A-Data.request

Поддерживающий субъект

EVCC

Имя параметра

Описание

A_Msg

- Установление сеанса

- Обнаружение сервиса

- Параметры сервиса

- Выбор сервиса и оплаты

- Параметры оплаты

- Авторизация зарядки

- Получение информации о параметрах зарядки

- Передача энергии

- Статус зарядки

- Учетная квитанция

- Актуализация сертификата

- Установка сертификата

- Проверка кабеля

- Предзарядка

- Запрос тока

- Обнаружение сварки

- Остановка сеанса

Имя примитива

A-Data.indication

Поддерживающая субъект

SECC

Имя параметра

Описание

A_Msg

- Установление сеанса

- Обнаружение сервиса

- Параметры сервиса

- Выбор сервиса и оплаты

- Параметры оплаты

- Авторизация зарядки

- Получение информации о параметрах зарядки

- Передача энергии

- Статус зарядки

- Учетная квитанция

- Актуализация сертификата

- Установка сертификата

- Проверка кабеля

- Предзарядка

- Запрос тока

- Обнаружение сварки

- Остановка сеанса

Имя примитива

A-Data.response

Поддерживающий субъект

SECC

Имя параметра

Описание

A_msg

- Установление сеанса

- Обнаружение сервиса

- Параметры сервиса

- Выбор сервиса и оплаты

- Параметры оплаты

- Авторизация зарядки

- Получение информации о параметрах зарядки

- Передача энергии

- Статус зарядки

- Учетная квитанция

- Актуализация сертификата

- Установка сертификата

- Проверка кабеля

- Предзарядка

- Запрос тока

- Обнаружение сварки

- Остановка сеанса

Имя примитива

A-Data.confirmation

Поддерживающий субъект

EVCC

Имя параметра

Описание

A_msg

- Установление сеанса

- Обнаружение сервиса

- Параметры сервиса

- Выбор сервиса и оплаты

- Параметры оплаты

- Авторизация зарядки

- Получение информации о параметрах зарядки

- Передача энергии

- Статус зарядки

- Учетная квитанция

- Актуализация сертификата

- Установка сертификата

- Проверка кабеля

- Предзарядка

- Запрос тока

- Обнаружение сварки

- Остановка сеанса

[V2G2-809]

При передаче сообщений на уровне приложения должно применяться правило обратного порядка следования байтов: старший байт передается первым, младший байт - последним.

[V2G2-165]

Перед началом обмена сообщениями на уровне приложения между EVCC и SECC должен быть согласован надлежащий протокол прикладного уровня, включая его версию.

[V2G2-166]

EVCC должен инициировать подтверждение, отправив SECC сообщение supportedAppProtocolReq, как показано на рисунке 17. Это сообщение-запрос дает перечень протоколов зарядки, поддерживаемых EVCC.

[V2G2-167]

Каждая запись в списке поддерживаемых EVCC протоколов должна включать ProtocolNamespace, VersionNumberMajor и VersionNumberMinor, уникальный SchemaID, динамически назначенный EVCC, и приоритет (Priority) позиции протокола в списке. Приоритет в сообщении-запросе EVCC позволяет EVCC объявить предпочтительный протокол на уровне приложения, где Priority, равный 1, указывает на наивысший приоритет и Priority, равный 20, указывает на низший приоритет. Число протоколов, включенных в сообщение-запрос, ограничивается 20.

[V2G2-168]

SECC должен отвечать сообщением supportedAppProtocolRes, как показано на рисунке 18, указав протокол, подлежащий использованию при последующем обмене сообщениями EVCC и SECC.

[V2G2-169]

Сообщение-ответ должно включать ResponseCode и SchemaID протокола/схемы, согласованных в качестве прикладного протокола для последующего сеанса связи. Таким образом, SECC должен выбрать из собственного списка поддерживаемых протоколов протокол с наибольшим приоритетом, имеющийся в списке EVCC.

[V2G2-170]

SECC должен подтвердить (положительно ответить на) поддерживаемый EVCC протокол, даже если значение VersionNumberMinor в сообщении-запросе EVCC не соответствует VersionNumberMinor поддерживаемого SECC протокола, в то время как VersionNumberMajor совпадает.

[V2G2-171]

Все дополнительные элементы данных, которые определены соответствующей младшей версией, должны кодироваться как случай отклонения от схемы кодером EXI (см. также настройки опций EXI в 7.9.1.3).

[V2G2-172]

Обычно ожидается, что SECC способен поддерживать соответствующие протоколы прикладного уровня, указанные EVCC. Однако когда ни один из протоколов прикладного уровня, включенных в список, полученный от EVCC, не поддерживается SECC, ResponseCode в сообщении-ответе должен быть равен Failed_NoNegotiation, указывая на то, что согласование протокола не было успешным. В этом сценарии ошибки сообщение с ответом не должно включать SchemaID.

[V2G2-173]

Если успешное согласование протокола не может быть достигнуто, то EVCC не должен инициализировать сеанс связи.

[V2G2-174]

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

[V2G2-175]

EVCC и SECC должны реализовывать сообщение и элементы сообщения V2G, как показано на рисунке 17.

[V2G2-176]

EVCC и SECC должны реализовывать сообщение и элементы сообщения V2G, как показано на рисунке 18.

[V2G2-178]

Элементы сообщений, показанные на рисунках 17 и 18, должны использоваться, как определено в таблицах 21 и 22.

Имя элемента/признака

Тип

Семантика

AppProtocol

complexType:

включает элементы сообщений, которые описаны в этой таблице

Этот элемент сообщения используется EVCC для передачи списка поддерживаемых протоколов. Каждый протокол с конкретной версией, поддерживаемый EVCC, представляется одной записью AppProtocol в сообщении-запросе (максимальное число записей: 20)

ProtocolNamespace

simpleType:

protocolNamespaceType

цепочка (макс. длина: 100)

см. определение типа в F.2

(приложение F)

Этот элемент сообщения используется EVCC для уникальной идентификации Namespace URI конкретного протокола, поддерживаемого EVCC, т.е. это имя соответствующего протокола

VersionNumberMajor

simpleType: unsignedInt

см. определение типа в F.2

(приложение F)

Этот элемент сообщения используется EVCC для указания старшего номера версии протокола, указанного в элементе сообщения ProtocolNamespace

VersionNumberMinor

simpleType: unsignedInt

см. определение типа в F.2

(приложение F)

Этот элемент сообщения используется EVCC для указания младшего номера версии протокола, указанного в элементе сообщения ProtocolNamespace

SchemaID

simpleType: unsignedByte

см. определение типа в F.2

(приложение F)

Этот элемент сообщения используется EVCC для указания SchemaID, присвоенного EVCC протоколу, указанному в элементах сообщения ProtocolNamespace, VersionNumberMajor и VersionNumberMinor

Priority

simpleType: priorityType unsignedByte (диапазон 1..20)

см. определение типа F.2

(приложение F)

type definition

Этот элемент сообщения используется EVCC для указания приоритета конкретного протокола, что позволяет SECC выбрать протокол на основе приоритетов. См. также [V2G2-167]

Имя элемента/признака

Тип

Семантика

SchemaID

simpleType: unsignedByte

см. определение типа в F.2

(приложение F)

Дополнительно:

этот элемент сообщения используется SECC для ссылки на один из поддерживаемых EVCC протоколов, полученных в сообщении-запросе

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.2

(приложение F)

Этот элемент сообщения используется SECC для указания: включает ли список протоколов, полученный от EVCC, по крайней мере один протокол, соответствующий протоколам, поддерживаемым SECC

[V2G2-179]

EVCC и SECC должны реализовывать структуру сообщения V2G, как показано на рисунке 19.

[V2G2-180]

Элементы данного сообщения должны использоваться, как определено в таблице 23.

Имя элемента

Тип

Семантика

Сообщение V2G

complexType

включает элементы сообщений, которые описаны в данной таблице

Корневой элемент, который идентифицирует данный XML-документ как сообщение V2G. Он содержит два дочерних элемента: заголовок и тело

Заголовок

complexType:

MessageHeaderType

см. 8.3.3

Этот элемент заключает в себе содержание заголовка сообщения. Он включает общую информацию для потока протокола и не связан непосредственно с семантикой каждого конкретного сообщения, которое определено в пункте 0

Тело

complexType:

BodyType

см. 8.3.4

Этот элемент заключает в себе содержание тела сообщения. Тело сообщения дает фактическую семантику каждого сообщения, определенного в пункте 0

[V2G2-181]

Элементы заголовка сообщения должны использоваться, как определено в таблице 24.

Имя элемента

Тип

Семантика

SessionID

simpleType:

SessionIDType: hexBinary

(макс. длина: 8)

Этот элемент сообщения используется EVCC и SECC для уникальной идентификации сеанса связи V2G. Требования, касающиеся данного элемента сообщений, см. в 8.4.2

Notification

complexType:

NotificationType

см. 8.5.2.8

Дополнительно:

этот элемент используется SECC для передачи дополнительной информации об ошибке при ее возникновении на SECC

xmlsig:Signature

separate namespace:

"http://www.w3.org/2000/09/xmldsig#"

Дополнительно:

этот элемент используется, если требуется подписание определенного сообщения V2G

[V2G2-182]

Каждое сообщение V2G, содержащее подписанные элементы, должно включать в заголовке элемент xmlsig:Signature, чтобы сделать возможной передачу подписи, сопровождающей элементы сообщения подписанного тела соответствующего сообщения.

[V2G2-183]

BodyElement должен использоваться, как определено в таблице 25.

Имя элемента

Тип

Семантика

BodyElement

complexType:

BodyBaseType

BodyElement является начальным элементом группы подстановок и сам не входит в состав экземпляра сообщения. Вместо этого создается экземпляр одного из элементов тела

[V2G2-739]

EVCC должен сделать паузу в сеансе связи V2G с помощью параметра ChargingSession, установленного на значение "Pause" в сообщении SessionStopReq, и должен остановить сеанс связи V2G (прекратить связь на транспортном уровне).

[V2G2-740]

Если EVCC возобновляет ранее приостановленный сеанс связи V2G, следующие значения параметров, предоставленные EVCC в предыдущем сеансе связи V2G, должны быть предоставлены вновь для возобновляемого сеанса связи V2G:

- SessionID, который был передан в заголовке сообщения SessionSetupRes в предыдущем сеансе связи V2G (для всех сообщений-запросов, начиная с SessionSetupReq);

- SelectedPaymentOption (PaymentServiceSelectionReq);

- RequestedEnergyTransferMode (ChargeParameterDiscoveryReq).

[V2G2-742]

Если EVCC желает возобновить ранее приостановленный сеанс связи V2G, он должен отправить параметр DepartureTime в ChargeParameterDiscoveryReq, уменьшенный на прошедшее время.

[V2G2-743]

Если EVCC желает возобновить ранее приостановленный сеанс связи V2G, он должен отправить параметр EAmount в ChargeParameterDiscoveryReq, уменьшенный на уже отобранное количество энергии.

[V2G2-744]

Если применяется [V2G2-739], EVCC должен обеспечить выполнение [V2G2-740] при условии, что состояние A, E или F линии управления не было выявлено EVCC в соответствии с ГОСТ Р МЭК 61851-1.

[V2G2-746]

При отправлении первого сообщения SessionSetupReq после подключения EV к EVSE EVCC должен установить параметр SessionID в заголовке сообщения, равный нулю (0).

[V2G2-747]

Заголовок любого сообщения, отправленный EVCC во время активного сеанса связи V2G, должен включать значение SessionID, отправленное SECC в ответ на SessionSetupReq, инициирующий текущий активный сеанс связи V2G.

[V2G2-748]

EVCC может возобновить сеанс зарядки путем отправления SesstionSetupReq с заголовком сообщения, в который входит значение SessionID из ранее приостановленного сеанса связи V2G.

[V2G2-749]

Если сеанс связи V2G возобновляется в соответствии с [V2G2-754] и EVCC желает изменить параметры зарядки, перечисленные в [V2G2-740], он должен использовать механизм пересогласования, описанный в настоящем стандарте.

[V2G2-741]

Если EVCC возобновляет ранее приостановленный сеанс связи V2G, следующие значения параметров, предоставленные SECC в предыдущем сеансе связи V2G, должны быть предоставлены вновь для возобновляемого сеанса связи V2G:

- SessionID, который был передан в заголовке сообщения SessionSetupRes в предыдущем сеансе связи V2G, если SessionID, переданный в заголовке SessionSetupReq, соответствует сохраненному значению (для всех сообщений с запросом, начиная с SessionSetupReq);

- PaymentOptionList (ServiceDiscoveryRes). Должна предоставляться только опция оплаты, ранее выбранная EVCC;

- ChargeService (ServiceDiscoveryRes);

- SAScheduleTuple (ChargeParameterDiscoveryRes). Должен предоставляться по крайней мере SAScheduleTuple (включая соответствующие данные PMaxSchedule и SalesTariff), идентификатор которого был выбран EVCC в его ChargingProfile в предыдущем сеансе связи V2G. Этот идентификатор кортежа не должен меняться во время сеанса связи V2G. Период времени, в течение которого данный SAScheduleTuple применяется, должен быть уменьшен на уже прошедшее время.

[V2G2-745]

Если [V2G2-739] применяется, SECC должен обеспечить выполнение [V2G2-741] при условии, что состояние A, E или F не было выявлено EVCC в соответствии с ГОСТ Р МЭК 61851-1.

[V2G2-750]

При получении SessionSetupReq с параметром SessionID, равным нулю (0), SECC должен генерировать новое (несохраненное) значение SessionID, отличающееся от нуля (0), и отправить это значение в заголовке сообщения SessionSetupRes.

[V2G2-751]

Значение SessionID, отправленное SECC в сообщении SessionSetupRes, не должно изменяться до прекращения сеанса связи V2G (т.е. до установки параметра ChargingSession сообщения SessionStopReq в какой-либо момент времени в значение "Terminate").

[V2G2-752]

Заголовок любого сообщения, отправленный SECC во время активного сеанса связи V2G, должен включать значение SessionID, отправленное SECC в ответ на SessionSetupReq, инициирующий текущий активный сеанс связи V2G.

[V2G2-753]

Если EVCC решает возобновить сеанс зарядки, отправив SesstionSetupReq с заголовком сообщения, в который входит значение SessionID приостановленного ранее сеанса связи V2G, SECC должен сравнить это значение со значением, сохраненным в предшествующем сеансе связи V2G.

[V2G2-754]

Если значение SessionID, полученное в текущем SessionSetupReq, равно значению, сохраненному из предшествующего сеанса связи V2G, SECC должен подтвердить продолжение сеанса зарядки путем отправки сообщения SessionSetupRes, включив сохраненное значение SessionID и указав на возобновление сеанса связи V2G посредством ResponseCode, установленного в значение "OK_OldSessionJoined" (см. также [V2G2-463] относительно выбора надлежащего кода ответа).

[V2G2-755]

Если сеанс связи V2G возобновляется в соответствии с [V2G2-754] и SECC желает изменить параметры зарядки, перечисленные в [V2G2-741], он должен использовать механизм пересогласования, описанный в настоящем стандарте.

[V2G2-756]

Если SECC получает SessionSetupReq, включающее значение SessionID, которое не равно нулю (0) и не равно значению SessionID, сохраненному в предшествующем сеансе связи V2G, он должен отправить в сообщении SessionSetupRes значение SessionID, которое не равно "0" и не равно значению SessionID, сохраненному в предшествующем сеансе связи V2G, и указать на новый сеанс связи V2G посредством ResponseCode, установленного в значение "OK_NewSessionEstablishe" (см. также [V2G2-462] относительно применимости этого кода ответа).

[V2G2-188]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 23.

[V2G2-189]

Элементы данного сообщения должны использоваться, как определено в таблице 26.

Имя элемента

Тип

Семантика

EVCCID

simpleType:

EVCCIDType hexBinary

(макс. длина: 6) см.

определение типа в F.6

(приложение F)

Дает идентификатор EV в читаемом формате. Содержит MAC-адрес EVCC как шесть байтов в шестнадцатеричной кодировке, т.е. элемент должен иметь длину шесть байтов

[V2G2-879]

EVCC должен передать EVCCID длиной шесть байтов и должен заполнить его своим MAC-адресом.

[V2G2-190]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 24.

[V2G2-191]

Элементы данного сообщения должны использоваться, как определено в таблице 27.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

EVSEID

simpleType: evseIDType

строка (мин. длина: 7,

макс. длина: 37)

Любой идентификатор, уникальным образом идентифицирующий EVSE и точку отбора мощности, к которым подключено транспортное средство.

Формат этого элемента сообщения определен в приложении G. Если SECC не может предоставить такие идентификационные данные, значение EVSEID устанавливается на ноль ("ZZ00000")

EVSETimeStamp

simpleType: long

см. определение типа в F.6

(приложение F)

Дополнительно:

метка текущего времени SECC. Формат "Метка времени Unix".

Этот элемент сообщения может быть использован EVCC для решения о возможности использования конкретного сертификата контракта для зарядки во время текущего сеанса связи.

На основе этой информации EVCC может реализовать стратегию для обновления сертификатов.

На основе этой информации EV может синхронизировать свое внутреннее время, если другие средства на EV отсутствуют

[V2G2-192]

EVCC и SECC должны использовать формат для идентификатора EVSE (EVSEID), описанный в приложении G.

[V2G2-193]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 25.

[V2G2-194]

Элементы данного сообщения должны использоваться, как определено в таблице 28.

Имя элемента

Тип

Семантика

ServiceScope

simpleType:

serviceScopeType

строка (макс. длина: 32)

см. определение типа в F.6

(приложение F)

Дополнительно:

определяет диапазон обнаружения сервисов. Диапазон определяется уникальным унифицированным идентификатором ресурса (URI), который соответствует поставщику услуг (например, поставщику услуг для EV, поставщику дополнительных услуг и т.п.).

C применением диапазона к обнаружению сервисов итоговый перечень услуг, передаваемый в ServiceDiscoveryRes, может быть ограничен определенным объемом, что обеспечивает предварительный отбор. SECC всегда передает все поддерживаемые сервисы всех видов, если никакой конкретный объем услуг ServiceScope не был указан в сообщении-запросе.

Определение URI (унифицированный идентификатор ресурса) описано в [48] и зависит от специфики реализации

ServiceCategory

simpleType:

serviceCategoryType enumeration

см. определение типа в F.6

(приложение F)

Дополнительно:

определяет категорию услуги для обнаружения сервиса (например, зарядка EV, доступ к Интернету и т.д.). С применением категории к обнаружению сервиса итоговый перечень услуг, передаваемый в ServiceDiscoveryRes, может быть ограничен определенной категорией сервисов, что обеспечивает предварительный отбор. SECC всегда передает все поддерживаемые сервисы для всех категорий, если никакая конкретная категория не была указана в сообщении-запросе с помощью элемента ServiceCategory сообщения

[V2G2-195]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 26.

[V2G2-196]

Элементы данного сообщения должны использоваться, как определено в таблице 29.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

PaymentOptionList

complexType:

PaymentOptionListType

см. 8.5.2.9

Этот элемент включает список опций оплаты, который SECC предлагает EVCC, указывая методы, которые могут быть выбраны для оплаты услуг. EVCC может выбрать только один метод оплаты для всех услуг, используемых им

ChargeService

complexType:

ChargeServiceType

см. 8.5.2.3

Имеющиеся услуги зарядки, которые поддерживает EVSE

ServiceList

complexType:

ServiceListType

см. 8.5.2.2

Факультативно:

список, содержащий информацию о всех других услугах, кроме зарядных, которые предлагает EVSE. Возвращаемый список услуг является перечнем услуг, выбранных на основе ServiceScope и ServiceType, указанных в сообщении ServiceDiscoveryReq.

Число сервисных элементов ограничивается восемью

[V2G2-197]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 27.

[V2G2-198]

Элементы данного сообщения должны использоваться, как определено в таблице 30.

Имя элемента

Тип

Семантика

ServiceID

simpleType:

serviceIDType unsignedShort

см. определение типа в F.6

(приложение F)

Этот элемент идентифицирует сервис, который был предложен SECC в сообщении ServiceDiscoveryRes

[V2G2-199]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 28.

[V2G2-200]

Элементы данного сообщения должны использоваться, как определено в таблице 31.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

ServiceID

simpleType:

serviceIDType unsignedShort

см. определение типа в F.6

(приложение F)

Этот элемент идентифицирует сервис, который был предложен SECC в сообщении ServiceDiscoveryRes

ServiceParameterList

complexType:

ServiceParameterListType

см. 8.5.2.21

Включает список параметров для конкретного serviceID, полученный от SECC в сообщении ServiceDiscoveryRes

[V2G2-201]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 29.

[V2G2-202]

Элементы данного сообщения должны использоваться, как определено в таблице 32.

Имя элемента

Тип

Семантика

SelectedPaymentOption

simpleType:

paymentOptionType enumeration

см. определение типа в F.6

(приложение F)

Этот элемент используется для указания выбранного типа оплаты за использование всех выбранных сервисов в selectedServiceList

SelectedServiceList

complexType:

SelectedServiceListType

см. 8.5.2.24

Список содержит идентификаторы всех выбранных сервисов (ServiceIDs) и факультативный parameterSetID для соответствующего serviceID

[V2G2-203]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 30.

[V2G2-204]

Элементы данного сообщения должны использоваться, как определено в таблице 33.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

[V2G2-205]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 31.

[V2G2-206]

Элементы данного сообщения должны использоваться, как определено в таблице 34.

Имя элемента

Тип

Семантика

eMAID

simpleType: eMAIDType

строка (мин. длина: 14,

макс. длина: 15)

см. определение типа в F.6

(приложение F)

Этот элемент идентифицирует контракт на зарядку. Формат определен в приложении G

ContractSignatureCertChain

complexType:

CertificateChainType

см. 8.5.2.4

Этот элемент содержит сертификат контракта на зарядку и факультативные субсертификаты

[V2G2-208]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 32.

[V2G2-209]

Элементы данного сообщения должны использоваться, как определено в таблице 35.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения

GenChallenge

simpleType:

genChallengeType base64Binary

(длина 16)

см. определение типа в F.6

(приложение F)

Вызов, отправленный SECC. Этот элемент содержит генерированное произвольное число

EVSETimeStamp

simpleType: long

см. определение типа в F.6

(приложение F)

Метка текущего времени SECC. Формат "Метка времени Unix".

Этот элемент сообщения может быть использован EVCC для определения причины отклонения сертификата контракта со стороны SECC и/или цепочки сигналов, переданных от EVCC к SECC в сообщении "PaymentDetailsReq".

На основе этой информации EVCC может реализовать стратегию обновления сертификатов (для будущих сеансов).

На основе этой информации EV может синхронизировать свое внутреннее время, если другие средства отсутствуют

[V2G2-825]

Поле GenChallenge должно быть длиной 128 бит.

[V2G2-826]

Энтропия поля GenChallenge должна быть не менее 120 бит.

[V2G2-898]

В случае выполнения идентификационного режима PnC EVCC должен отправить свой сертификат контракта, включая цепочку сертификата (до корневого сертификата, но исключая его) в элементе ContractSignatureCertChain сообщения PaymentDetailsReq.

[V2G2-899]

В случае выполнения идентификационного режима PnC SECC должен получить сертификат контракта, включая цепочку сертификата, в элементе ContractSignatureCertChain сообщения PaymentDetailsReq. SECC должен выполнить валидацию сертификата, включая цепочку сертификата, проверить, прослеживается ли он до заслуживающего доверия корневого сертификата оператора услуг. Если какая-либо из вышеуказанных проверок и валидаций не удается, SECC должен считать сертификат контракта недействительным. SECC также не должен использовать указанный сертификат контракта для каких-либо дальнейших проверок.

[V2G2-210]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 33.

[V2G2-211]

Элементы данного сообщения должны использоваться, как определено в таблице 36.

Имя элемента

Тип

Семантика

Id

simpleType: ID

цепочка

см. определение типа в F.6

(приложение F)

Факультативно:

этот атрибут используется для ссылки на тело сообщения в заголовке подписи, если требуется применить подпись

GenChallenge

simpleType:

genChallengeType base64Binary

(длина 16)

см. определение типа в F.6

(приложение F)

Факультативно:

вызов, отправленный SECC в сообщении PaymentDetailsRes. Этот элемент содержит сгенерированное произвольное число

[V2G2-697]

Поле GenChallenge должно быть длиной 128 бит.

[V2G2-698]

Энтропия поля GenChallenge должна быть не менее 120 бит.

[V2G2-212]

В зависимости от выбранного набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 34.

[V2G2-213]

Элементы данного сообщения должны использоваться, как определено в таблице 37.

Имя элемента

Тип

Семантика

EVSEProcessing

simpleType:

EVSEProcessingType enumeration

см. определение типа в F.6

(приложение F)

Параметр, указывающий, что EVSE завершил обработку, которая была инициирована после AuthorizationReq, или, если EVSE в данное время продолжает обработку, что сообщение-ответ было отправлено

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

Параметр, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

[V2G2-900]

При выполнении идентификационного режима PnC, в случае если EVCC отправляет вызов (ранее полученный от SECC), EVCC должен подписать элемент тела AuthorizationReq, используя закрытый ключ сертификата контракта, который он отправил в PaymentDetailsReq в течение данного сеанса.

[V2G2-901]

В случае выполнения идентификационного режима PnC SECC должен удостовериться в том, что элемент тела AuthorizationReq правильно подписан закрытым ключом, соответствующим сертификату контракта, ранее полученному в сообщении PaymentDetailsReq данного сеанса, и что поле GenChallenge имеет такое же содержание, как поле GenChallenge, ранее отправленное SECC в сообщении PaymentsDetailsRes. Если какая-либо из указанных проверок и валидаций не удается, SECC должен считать подпись недействительной. См. также [V2G2-475].

[V2G2-214]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 35.

[V2G2-215]

При отсутствии информации DepartureTime EVCC не должен включать этот элемент сообщения в сообщение ChargeParameterDiscoveryReq.

[V2G2-761]

Если EVCC не посылает время отбытия в составе сообщения ChargeParameterDiscoveryReq, SECC должен исходить из того, что EV должен начать зарядку без какой-либо задержки.

[V2G2-216]

Элементы данного сообщения должны использоваться, как определено в таблице 38.

Имя элемента

Тип

Семантика

MaxEntriesSAScheduleTuple

simpleType:

unsignedShort

см. определение типа в F.6

(приложение F)

Факультативно:

указывает максимальное число записей в SAScheduleTuple (применятся к Pmax и Tariff). EVSE может передавать число записей до максимального числа, которое определено в параметре

RequestedEnergyTransferMode

simpleType:

EnergyTransferModeType enumeration

см. определение типа в F.6

(приложение F) и таблице 63

Выбранный режим передачи энергии для зарядки, который запрашивается SECC

AC_EVChargeParameter

complexType:

AC_EVChargeParameterType

заменяет абстрактный тип

EV_ChargeParameterType

см. 8.5.3.2

Этот элемент используется EVCC для инициирования процесса назначения целей для зарядки переменным током

DC_EVChargeParameter

complexType:

DC_EVChargeParameterType

заменяет абстрактный тип

EV_ChargeParameterType

см. 8.5.4.3

Этот элемент используется EVCC для инициирования процесса назначения целей для зарядки постоянным током

[V2G2-784]

EVCC должен поддерживать 12 записей для элементов PMaxScheduleEntry и SalesTariffEntry внутри одного SAScheduleTuple, если MaxEntriesSAScheduleTuple не передается в сообщении ChargeParameterDiscoveryReq.

[V2G2-786]

SECC должен поддерживать минимум 12 записей для элементов PMaxScheduleEntry и SalesTariffEntry внутри одного SAScheduleTuple.

[V2G2-785]

Если SECC не может обеспечить число записей для элементов PMaxScheduleEntry и SalesTariffEntry внутри одного SAScheduleTuple, которое требуется для MAXEntriesSAScheduleTuple, он должен отправить максимальное число записей, которое поддерживается в SAScheduleTuple.

[V2G2-218]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 36.

[V2G2-219]

Все тарифы, представленные в элементе SASchedules, должны исходить от одного и того же SA.

[V2G2-220]

Элементы данного сообщения должны использоваться, как определено в таблице 39.

Имя элемента

Тип

Семантика

EVSEProcessing

simpleType:

EVSEProcessingType enumeration

см. определение типа в F.6

(приложение F)

Параметр, показывающий, что EVSE завершил обработку, которая была инициирована после ChargeParameterDiscoveryReq, или что в это время EVSE продолжает обработку

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

SAScheduleList

complexType:

SAScheduleListType

заменяет абстрактный тип

SASchedulesType

см. 8.5.2.12

Факультативно:

включает несколько графиков от SA. SECC не должен применять параметр "SAScheduleList", если EVSEProcessing установлен в значение "Ongoing"

AC_EVSEChargeParameter

complexType:

AC_EVSEChargeParameterType

заменяет абстрактный тип

EVSE_ChargeParameterType

см. 8.5.3.3

Этот элемент используется EVCC для инициирования процесса назначения целей для зарядки переменным током

DC_EVSEChargeParameter

complexType:

DC_EVSEChargeParameterType

заменяет абстрактный тип

EVSE_ChargeParameterType

см. 8.5.4.4

Этот элемент используется EVCC для инициирования процесса назначения целей для зарядки постоянным током

[V2G2-286]

Элемент SAScheduleTupleID должен идентифицировать выбранный элемент SAScheduleTupleType (см. 8.5.2.13) в списке элементов SAScheduleTuple (см. 8.5.2.12), переданном в сообщении ChargeParameterDiscoveryRes (см. 8.4.3.8.3).

[V2G2-221]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны формировать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 37.

[V2G2-222]

Элементы данного сообщения должны использоваться, как определено в таблице 40.

Имя элемента

Тип

Семантика

ChargeProgress

simpleType:

chargeProgressType enumeration

см. определение типа в F.6

(приложение F)

Этот элемент сообщения используется для запроса EVSE о выполнении условий передачи электроэнергии после того, как бортовая система EV начнет получать электроэнергию (т.е. у EVSE запрашивается замыкание контактов).

Если ChargeProgress равен "Start", EVSE запрашивается о готовности к незамедлительному обеспечению электроэнергией. Если ChargeProgress равен "Stop", EVSE запрашивается о прекращении передачи электроэнергии. Если ChargeProgress равен "Renegotiate", энергия не передается и применяется механизм пересогласования, описанный в настоящем стандарте

SAScheduleTupleID

simpleType:

SAIDType short

см. определение типа в F.6

(приложение F)

Уникальный идентификатор сеанса зарядки для элемента SAScheduleTuple. Идентификатор SA остается уникальным идентификатором для одного графика в течение сеанса зарядки

ChargingProfile

complexType:

ChargingProfileType

см. 8.5.2.10

Факультативно:

позволяет EV резервировать конкретный профиль зарядки для текущего сеанса (т.е. максимальное количество получаемой энергии)

DC_EVPowerDeliveryParameter

complexType:

DC_EVPowerDeliveryParameterType

заменяет абстрактный тип

EVPowerDeliveryParameter

см. 8.5.4.5

Факультативно:

этот элемент используется EVCC для передачи параметров мощности

[V2G2-223]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны генерировать обязательные сообщения и элементы сообщений, как описано в таблице 104 и в соответствии с рисунком 38.

[V2G2-224]

SECC должен всегда согласовывать ChargingProfile EVCC (см. 8.5.2.10), если последний не превышает значений PMax элементов PMaxScheduleEntryType (см. 8.5.2.15) в соответствии с выбранным элементом SAScheduleTupleType (см. 8.5.2.13) в последнем сообщении ChargeParameterDiscoveryRes, отправленном SECC (см. 8.4.3.8.3).

[V2G2-777]

Максимальное время задержки, которое дается EV для адаптации к новому номинальному уровню мощности (задний фронт) во время зарядки, составляет 5 с. Если время задержки превышено и мощность, отбираемая EV, превышает номинальное значение более чем на 10%, EVSE может отключить EV.

[V2G2-225]

SECC должен отправить отрицательный ResponseCode FAILED_ChargingProfileInvalid в сообщении-ответе PowerDelivery, если EVCC посылает ChargingProfile (см. 8.5.2.10), который не соответствует значениям PMax всех элементов PMaxScheduleEntryType (см. 8.5.2.15) согласно выбранному элементу SAScheduleTupleType (см. 8.5.2.13) в последнем сообщении ChargeParameterDiscoveryRes, отправленном SECC (см. 8.4.3.8.3).

[V2G2-226]

Элементы данного сообщения должны использоваться, как определено в таблице 41.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

AC_EVSEStatus

complexType:

AC_EVSEStatusType

заменяет абстрактный тип

EVSEStatusType

см. 8.5.3.1

Этот элемент используется SECC для указания на статус EVSE и для сигнализации о событии, реакции на которое SECC ожидает от EVCC

DC_EVSEStatus

complexType:

DC_EVSEStatusType

заменяет абстрактный тип

EVSEStatusType

см. 8.5.4.1

Этот элемент используется SECC для указания на статус EVSE и для сигнализации о событии, реакции на которое SECC ожидает от EVCC

[V2G2-227]

EVCC должен запросить необходимый сертификат у SECC при условии, что SECC предоставляет данную услугу, как ранее было указано в элементе ServiceList сообщения ServiceDiscoveryRes.

[V2G2-228]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 39.

[V2G2-229]

Элементы данного сообщения должны использоваться, как определено в таблице 42.

[V2G2-888]

EVCC должен подписать элемент тела CertificateUpdateReq, используя сертификат контракта, обновление которого запрашивается.

[V2G2-889]

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

Имя элемента

Тип

Семантика

Id

simpleType: ID

цепочка

см. определение типа в F.6

(приложение F)

Этот элемент используется для ссылки на все тело сообщения в заголовке сообщения, когда необходимо применить подпись

ContractSignatureCertChain

complexType:

CertificateChainType

см. 8.5.2.5

Содержит имеющийся в настоящее время сертификат подписи, включая цепочку сертификата в EVCC. SECC использует этот сертификат (цепочку) для проверки подписи, включенной в заголовок сообщения.

Передается полная цепочка, что обеспечивает возможность автономной проверки подписи

eMAID

simpleType: eMAIDType

цепочка (мин. длина: 14,

макс. длина: 15)

см. определение типа в F.6

(приложение F)

Этот элемент идентифицирует контракт на зарядку. Формат определен в приложении G

ListOfRootCertificateIDs

complexType:

ListOfRootCertificateIDsType

см. 8.5.2.27

Этот список содержит идентификаторы сертификата всех корневых сертификатов, установленных в настоящее время в EVCC

[V2G2-230]

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

[V2G2-231]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 40.

[V2G2-232]

Элементы данного сообщения должны использоваться, как определено в таблице 43.

[V2G2-928]

Если ResponseCode в этом сообщении указывает на неудачу (т.е. начинается с FAILED), EVCC должен игнорировать все другие элементы, за исключением RetryCounter.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

SAProvisioningCertificateChain

complexType:

CertificateChainType

см. 8.5.2.5

Переданная цепочка сертификата используется EVCC для проверки подписи в заголовке сообщения

ContractSignatureCertChain

complexType:

CertificateChainType

см. 8.5.2.5

Новая цепочка сертификатов для подписей, которые должны быть установлены в EVCC

ContractSignatureEncryptedPrivateKey

complexType:

ContractSignatureEncryptedPrivateKeyType

см. 8.5.2.28

Закрытый ключ, который принадлежит новому сертификату для подписи. Он должен быть также установлен на EVCC.

Эти данные должны быть зашифрованы с помощью старого сертификата контракта EVCC (на базе ContractSignatureCertChain, содержащегося в сообщении CertificateUpdateReq) и рассчитанного секретного ключа Диффи-Хеллмана для шифрования, как описано в 7.9.2.4.3

DНpublickey

complexType:

DiffieHellmanPublickeyType

см. определение типа в 8.5.2.29

Параметр открытого ключа Диффи-Хеллмана от SA для генерирования ключа сеанса EVCC с целью шифрования закрытого ключа подписи контракта на стороне SA и его дешифрования на стороне EVCC

eMAID

complexType:

EMAIDType

см. определение типа в 8.5.2.30

Этот элемент идентифицирует контракт на зарядку. Формат определен в приложении G

RetryCounter

simpleType short

см. определение типа в F.6

(приложение F)

Факультативно:

если ResponseCode был "FAILED_NoCertificate Available" или "FAILED_ContractCanceled", то это поле содержит информацию о том, когда EVCC должен попытаться получить новый сертификат еще раз. Возможны следующие записи: x>0: после "x" дней;

0: незамедлительно (при следующей зарядке);

-1: никогда

[V2G2-233]

SECC должен запросить необходимый сертификат у вторичного субъекта.

[V2G2-696]

В случае ответа с информацией об ошибке сообщение должно также включать элемент RetryCounter.

[V2G2-827]

Сертификат контракта, предназначенный для замены установленного сертификата, должен быть пригоден для использования (в отношении срока действия) на EV сразу же после его передачи сообщением CertificateUpateRes.

[V2G2-890]

Служба выдачи сертификатов должна подписать следующие элементы сообщения CertificateUpdateRes: ContractSignatureCertChain, ContractSignatureEncryptedPrivateKey, DHpublickey, eMAID. Сообщение должно включать цепочку сертификата для проверки этой подписи в поле SAProvisioningCertChain. Служба выдачи сертификатов должна убедиться в том, что данные, на которые распространяется эта подпись, получены от предшествующего SA подтвержденным способом.

[V2G2-891]

EVCC должен проверить подпись сообщения CertificateUpdateRes, используя цепочку сертификатов подписчика SAProvisioningCertChain, проверить указанную цепочку и убедиться, что она вернулась к действительному корневому сертификату V2G. Он должен гарантировать, что сертификат подписчика имеет поле DC (DomainComponent) с содержимым "CPS". Он должен обеспечить включение в подпись следующих элементов: ContractSignatureCertChain, ContractSignatureEncryptedPrivateKey, DHpublickey, ContractID. EVCC должен подтвердить сертификат подписчика и убедиться, что он вернется к доверенному корневому сертификату V2G. Если что-либо из вышеперечисленного не выполняется, EVCC считает сообщение недействительным и отбрасывает его. Кроме того, EVCC должен хранить части цепочки сертификатов, которых она еще не имеет.

[V2G2-892]

ContractSignatureCertChain, полученная в сообщении CertificateUpdateRes, должна быть целенаправленно сохранена таким образом, чтобы она могла быть применена позднее для проверки таблиц тарифных ставок. Сертификат Sub-CA2 оператора услуг для EV необходим для проверки таблиц тарифных ставок.

[V2G2-234]

SECC должен запросить необходимый сертификат у SA, если он имеет возможность подключения онлайн.

[V2G2-235]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 41.

[V2G2-236]

Элементы данного сообщения должны использоваться, как определено в таблице 44.

Имя элемента

Тип

Семантика

Id

simpleType: ID

строка

см. определение типа в F.6 (приложение F)

Этот элемент используется для ссылки на все тело сообщения в заголовке сообщения, когда необходимо применить подпись

OEMProvisioningCert

simpleType:

certificateType base64Binary

(макс. длина 800)

см. определение типа в F.6

(приложение F)

Конкретный сертификат EV, который был ранее установлен в EVCC, как правило, изготовителем. Идентификатор данного сертификата вместе с информацией, хранящейся у SA (контрактный партнер), используется для идентификации действующего контракта EV.

Идентификатор сертификата выдается SA с использованием различных коммуникационных каналов. Сам сертификат (т.е. его открытый ключ) позднее используется для шифрования в CertificateInstallationRes.

Сертификат закодирован в соответствии с особыми правилами кодирования DER (Distinguished Encoding Rules).

См. также C.1 (приложение C)

ListOfRootCertificateIDs

complexType:

ListOfRootCertificateIDsType

см. 8.5.2.27

Этот список содержит идентификаторы сертификата всех корневых сертификатов, установленных в EVCC

[V2G2-893]

EVCC должен подписать элемент тела CertificatelnstallationReq, используя свой сертификат изготовителя.

[V2G2-894]

Служба выдачи сертификатов должна проверить подпись элемента тела сообщения CertificateInstallationReq с помощью включенного сертификата изготовителя из поля OEMProvisioningCert. Служба выдачи сертификатов должна выполнить валидацию указанного сертификата изготовителя, включая цепочку из того же поля, и убедиться в том, что он прослеживается до безопасного корневого сертификата изготовителя. Служба выдачи сертификатов должна убедиться в том, что сертификат изготовителя имеет установленный DC (доменный компонент) "OEM". Если что-либо из вышеуказанного не выполняется, служба выдачи сертификатов должна рассматривать подпись как недействительную, прекратить процедуру и вызвать сообщение об ошибке от SECC.

[V2G2-237]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 42.

[V2G2-238]

Элементы данного сообщения должны использоваться, как определено в таблице 45.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F.6)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

SAProvisioningCertificateChain

complexType:

CertificateChainType

см. 8.5.2.5

Переданная цепочка сертификата используется EVCC для проверки подписи в заголовке сообщения

ContractSignatureCertChain

complexType:

CertificateChainType

см. 8.5.2.5

Новая цепочка сертификата для подписи, которая должна быть установлена в EVCC

ContractSignatureEncryptedPrivateKey

complexType:

ContractSignatureEncryptedPrivateKeyType

см. 8.5.2.28

Закрытый ключ, который принадлежит новому сертификату для подписи. Он должен быть также установлен в EVCC.

Эти данные должны быть зашифрованы с помощью предоставленного сертификата изготовителя EVCC (на базе OEMProvisioningCert, содержащегося в сообщении Certificate Installation Request) и с помощью секретного ключа Диффи-Хеллмана для шифрования, как описано в 7.9.2.4.3

DНpublickey

complexType:

DiffieHellmanPublickeyType

см. определение типа в 8.5.2.29

Открытый ключ Диффи-Хеллмана от SA для генерирования ключа сеанса на стороне EVCC c целью дальнейшего шифрования закрытого ключа подписи контракта на стороне SA и дешифровывания его на стороне EVCC

eMAID

complexType:

EMAIDType

см. определение типа в 8.5.2.30

Этот элемент идентифицирует контракт на зарядку. Формат определен в приложении G

[V2G2-895]

Служба выдачи сертификатов должна подписать следующие элементы сообщения CertificateInstallationRes с использованием сертификата службы выдачи сертификатов: ContractSignatureCertChain, ContractSignatureEncryptedPrivateKey, DHpublickey, ContractID. CertificateInstallationRes должно включать цепочку сертификата для проверки этой подписи в поле SAProvisioningCertChain. Служба выдачи сертификатов также должна убедиться в том, что данные, которые удостоверяются этой подписью, получены от предыдущего SA надежным способом.

[V2G2-896]

EVCC должен проверить подпись сообщения CertificateInstallationRes, используя цепочку сертификатов подписчика SAProvisioningCertificateChain, проверить указанную цепочку и убедиться, что она вернулась к действительному корневому сертификату V2G. Он должен гарантировать, что сертификат подписчика имеет поле DC (DomainComponent) с содержимым "CPS". Он должен обеспечить включение в подпись следующих элементов: ContractSignatureCertChain, ContractSignatureEncrypted PrivateKey, DHpublickey, ContractID. Если какое-либо из вышеперечисленных условий не выполняется, EVCC считает сообщение недействительным и отбрасывает его. Кроме того, EVCC должен хранить части цепочки сертификатов, которых она еще не имеет.

[V2G2-897]

ContractSignatureCertChain, полученная в сообщении CertificateInstallationRes, должна быть сохранена таким образом, чтобы она могла быть применена позднее для проверки таблиц тарифных ставок. Сертификат Sub-CA 2 оператора услуг для EV необходим для проверки таблиц тарифных ставок.

[V2G2-648]

При передаче SA файла, который содержит сертификат контракта, цепочку сертификата и закрытый ключ подписи, файл должен быть предоставлен в формате PKCS#12.

[V2G2-239]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 43.

[V2G2-738]

Элементы данного сообщения должны использоваться, как определено в таблице 46.

Имя элемента

Тип

Семантика

ChargingSession

simpleType:

ChargingSessionType enumeration

см. определение типа в F.6

(приложение F)

ChargingSession указывает на намерение EVCC сделать паузу или прекратить сеанс связи V2G

[V2G2-240]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 44.

[V2G2-241]

Элементы данного сообщения должны использоваться, как определено в таблице 47.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

[V2G2-902]

Элемент MeterInfo, отправленный SECC в сообщении ChargingStatusRes, должен содержать такие же данные, какие выдает прибор учета. Он должен содержать необработанные показания прибора учета в форме, которая в целом поддается машинному чтению.

[V2G2-245]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 45.

[V2G2-246]

Элементы данного сообщения должны использоваться, как определено в таблице 48.

Имя элемента

Тип

Семантика

Id

simpleType: ID

цепочка

см. определение типа в F.6 приложение F)

Факультативно:

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

SessionID

simpleType:

SessionIDType

SessionIDType: hexBinary

(макс. длина: 8)

см. определение типа в F.6

(приложение F)

Этот элемент сообщения используется EVCC и SECC для уникальной идентификации сеанса связи V2G. Этот элемент идентичен элементу, включенному в заголовок сообщения. Он помещается в тело дополнительно, чтобы была возможность применить к нему подпись (подписывается все тело сообщения)

SAScheduleTupleID

simpleType:

SAIDType short

см. определение типа в F.6

(приложение F)

Факультативно:

уникальный идентификатор элемента SAScheduleTuple во время сеанса зарядки. Этот элемент является лишь повторением значения, полученного от SECC либо в ChargingStatusRes (во время зарядки переменным током), либо в сообщении CurrentDemandRes (во время зарядки постоянным током).

Идентификатор SA (SAID) остается уникальным идентификатором для одного графика в течение сеанса зарядки

MeterInfo

complexType:

MeterInfoType

см. 8.5.2.6

Если SECC указал в ChargingStatusRes (зарядка переменным током)/CurrentDemandRes (зарядка постоянным током), что MeteringReceiptReq необходим, то этот элемент сообщения является повторением элемента MeterInfo, полученного от SECC в ChargingStatusRes (зарядка переменным током)/CurrentDemandRes (зарядка постоянным током)

[V2G2-776]

Элемент сообщения SAScheduleTupleID, если он включен, должен быть всегда равен значению SAScheduleTupleID, полученному в предыдущем сообщении ChargingStatusRes (зарядка переменным током)/CurrentDemandRes (зарядка постоянным током).

[V2G2-903]

EVCC должен подписать тело сообщения MeteringReceiptReq с помощью закрытого ключа, принадлежащего сертификату контракта, который он отправил в данном сеансе в сообщении PaymentDetailsReq.

[V2G2-904]

SECC/SA может проверить подпись элемента тела сообщения MeteringReceiptReq, используя сертификат контракта, который он получил в данном сеансе в составе сообщения PaymentDetailsReq. Если результат проверки отрицателен, квитанция прибора учета должна рассматриваться как недействительная.

[V2G2-247]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 46.

[V2G2-248]

Элементы данного сообщения должны использоваться, как определено в таблице 49.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

AC_EVSEStatus

complexType:

AC_EVSEStatusType

заменяет абстрактный тип

EVSEStatusType

см. 8.5.3.1

Этот элемент используется SECC для указания на статус EVSE и для сигнализации о событии, реакции на которое SECC ожидает от EVCC

DC_EVSEStatus

complexType:

DC_EVSEStatusType

заменяет абстрактный тип

EVSEStatusType

см. 8.5.4.1

Этот элемент используется SECC для указания на статус EVSE и для сигнализации о событии, реакции на которое SECC ожидает от EVCC

[V2G2-242]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 47.

[V2G2-243]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 48.

[V2G2-244]

Элементы данного сообщения должны использоваться, как определено в таблице 50.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

EVSEID

simpleType:

evseIDType

строка (мин. длина: 7,

макс. длина: 37)

см. определение типа в F.6

(приложение F)

Любой идентификатор, который уникально идентифицирует EVSE и точку заряда, к которой подключено транспортное средство. Формат этого элемента сообщения определен в приложении G. Если SECC не может предоставить такие идентификационные данные, то значение EVSEID устанавливается на ноль ("ZZ00000")

SAScheduleTupleID

simpleType:

SAIDType short

см. определение типа в F.6

(приложение F)

Уникальный идентификатор в течение сеанса зарядки для элемента SAScheduleTuple. Используется SECC для указания, какой тариф применяется в настоящее время.

Идентификатор SA (SAID) остается уникальным идентификатором для одного графика в течение сеанса зарядки

EVSEMaxCurrent

complexType:

PhysicalValueType

см. 8.5.2.7

Факультативно:

этот элемент используется SECC для индикации максимального фазного тока по фазам, который EV может отбирать. Этот элемент не включается в сообщение, если был выбран какой-либо набор сообщений для зарядки переменным током в режиме PnC

MeterInfo

complexType:

MeterInfoType

см. 8.5.2.6

Факультативно:

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

ReceiptRequired

simpleType

логическое выражение

см. определение типа в F.6

(приложение F)

Факультативно:

данный элемент используется SECC для указания на то, что SECC запрашивает отправку сообщения MeteringReceiptReq с целью подписания информации прибора учета. Если ReceiptRequired равно True, от SECC запрашивается отправка сообщения MeteringReceiptReq, включая подпись. Если ReceiptRequired равно False, от EVCC не требуется отправлять сообщение MeteringReceiptReq

AC_EVSEStatus

complexType:

AC_EVSEStatusType

заменяет абстрактный тип

EVSEStatusType

см. 8.5.3.1

Этот элемент используется SECC для указания своего статуса

[V2G2-249]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 49.

[V2G2-250]

Элементы данного сообщения должны использоваться, как определено в таблице 51.

Имя элемента

Тип

Семантика

DC_EVStatus

complexType:

DC_EVStatusType

см. 8.5.4.2

Актуальное значение тока зарядки EV

[V2G2-251]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 50.

[V2G2-252]

Элементы данного сообщения должны использоваться, как определено в таблице 52.

Имя элемента

Тип

Семантика

EVSEProcessing

simpleType:

EVSEProcessingType enumeration

см. определение типа в F.6

(приложение F)

Параметр, показывающий, что EVSE завершило обработку, которая была инициирована CableCheckReq, или если EVSE ещe продолжает обработку в это время, что сообщение-ответ было отправлено

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

DC_EVSEStatus

complexType:

DC_EVSEStatusType

см. 8.5.4.1

Актуальное значение тока зарядки EVSE

[V2G2-253]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 51.

[V2G2-254]

Элементы данного сообщения должны использоваться, как определено в таблице 53.

Имя элемента

Тип

Семантика

DC_EVStatus

complexType:

DC_EVStatusType

см. 8.5.4.2

Актуальное значение тока зарядки EV

EVTargetVoltage

complexType:

PhysicalValueType

см. 8.5.2.7

Целевое напряжение, запрошенное EV

EVTargetCurrent

complexType:

PhysicalValueType

см. 8.5.2.7

Ток, запрошенный EV

[V2G2-255]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 52.

[V2G2-256]

Элементы данного сообщения должны использоваться, как определено в таблице 54.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

DC_EVSEStatus

complexType:

DC_EVSEStatusType

см. 8.5.4.1

Актуальное значение тока зарядки EVSE

EVSEPresentVoltage

complexType:

PhysicalValueType

см. 8.5.2.7

Выходное напряжение EVSE по [9]

[V2G2-257]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 53.

[V2G2-258]

Элементы данного сообщения должны использоваться, как определено в таблице 55.

Имя элемента

Тип

Семантика

DC_EVStatus

complexType:

DC_EVStatusType

см. 8.5.4.2

Актуальное значение тока зарядки EV

EVTargetCurrent

complexType:

PhysicalValueType

см. 8.5.2.7

Ток, запрашиваемый EV в данный момент времени

EVMaximumVoltageLimit

complexType:

PhysicalValueType

см. 8.5.2.7

Факультативно:

максимальное напряжение, допускаемое EV

EVMaximumCurrentLimit

complexType:

PhysicalValueType

см. 8.5.2.7

Факультативно:

максимальный ток, допускаемый EV

EVMaximumPowerLimit

complexType:

PhysicalValueType

см. 8.5.2.7

Факультативно:

максимальная мощность, допускаемая EV

BulkChargingComplete

simpleType

логическое выражение

см. определение типа в F.6

(приложение F)

Факультативно:

если установлено значение True, то EV сообщает, что основная зарядка (степень заряда около 80%) завершена

ChargingComplete

simpleType:

логическое выражение

см. определение типа в F.6

(приложение F)

Если установлено значение True, EV сообщает, что полная зарядка (степень заряда 100%) завершена

RemainingTimeToFullSoC

complexType:

PhysicalValueType

см. 8.5.2.7

Факультативно:

оценочное или рассчитанное время до выполнения полной зарядки (степень заряда 100%)

RemainingTimeToBulkSoC

complexType

PhysicalValueType

см. 8.5.2.7

Факультативно:

оценочное или рассчитанное время до выполнения основной зарядки (степень заряда 80%)

EVTargetVoltage

complexType

PhysicalValueType

см. 8.5.2.7

Целевое напряжение, запрашиваемое EV

[V2G2-259]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 54.

[V2G2-260]

Элементы данного сообщения должны использоваться, как определено в таблице 56.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

DC_EVSEStatus

complexType:

DC_EVSEStatusType

см. 8.5.4.1

Актуальное значение тока зарядки EVSE

EVSEPresentVoltage

complexType:

PhysicalValueType

см. 8.5.2.7

Текущее выходное напряжение EVSE.

См. таблицу сопоставления SAE - ИСО*

EVSEPresentCurrent

complexType:

PhysicalValueType

см. 8.5.2.7

Текущий выходной ток EVSE.

См. таблицу сопоставления SAE - ИСО*

EVSECurrentLimitAchieved

simpleType

логическое выражение

см. определение типа в F.6

(приложение F)

Если установлено значение True, EVSE достигло своего предела по току

EVSEVoltageLimitAchieved

simpleType

логическое выражение

см. определение типа в F.6

(приложение F)

Если установлено значение True, EVSE достигло своего предела по напряжению

EVSEPowerLimitAchieved

simpleType

логическое выражение

см. определение типа в F.6

(приложение F)

Если установлено значение True, EVSE достигло своего предела по мощности

EVSEMaximumVoltageLimit

complexType:

PhysicalValueType

см. 8.5.2.7

Факультативно:

максимальное напряжение EVSE

EVSEMaximumCurrentLimit

complexType:

PhysicalValueType

см. 8.5.2.7

Факультативно:

максимальный ток EVSE

EVSEMaximumPowerLimit

complexType:

PhysicalValueType

см. 8.5.2.7

Факультативно:

максимальная мощность EVSE

EVSEID

simpleType: evseIDType

SessionIDType: hexBinary

(макс. длина: 32)

см. определение типа в F.6

(приложение F)

Любой идентификатор, уникальным образом идентифицирующий EVSE и точку заряда, к которым подключено транспортное средство. Формат этого элемента сообщений определен в G.2 (приложение G). Если SECC не может предоставить такие идентификационные данные, значение EVSEID устанавливается на ноль (00hex)

SAScheduleTupleID

simpleType:

SAIDType short

см. определение типа в F.6

(приложение F)

Уникальный идентификатор элемента SAScheduleTuple на протяжении сеанса зарядки. Используется SECC для указания тарифа который применяется в настоящее время. Идентификатор SA (SAID) остается уникальным идентификатором для одного графика в течение сеанса зарядки

MeterInfo

complexType: MeterInfoType

см. 8.5.2.6

Факультативно:

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

ReceiptRequired

simpleType

логическое выражение

см. определение типа в F.6

(приложение F)

Факультативно:

этот элемент используется SECC для отправки сообщения MeteringReceiptReq с целью подписания записи прибора учета. Если ReceiptRequired равно True, от EVCC запрашивается отправка сообщения MeteringReceiptReq, включая подпись. Если ReceiptRequired равно False, от EVCC не требуется отправлять сообщение MeteringReceiptReq

* Таблица сопоставления SAE - ИСО приведена в приложении I.

[V2G2-261]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 55.

[V2G2-262]

Элементы данного сообщения должны использоваться, как определено в таблице 57.

Имя элемента

Тип

Семантика

DC_EVStatus

complexType:

DC_EVStatusType

см. 8.5.4.2

Актуальное значение тока зарядки EV

[V2G2-263]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений, как определено в таблице 104 и в соответствии с рисунком 56.

[V2G2-264]

Элементы данного сообщения должны использоваться, как определено в таблице 58.

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration

см. определение типа в F.6

(приложение F)

ResponseCode, показывающий статус подтверждения любого из сообщений V2G, полученных SECC

DC_EVSEStatus

complexType:

DC_EVSEStatusType

см. 8.5.4.1

Актуальное значение тока зарядки EVSE

EVSEPresentVoltage

complexType:

PhysicalValueType

см. 8.5.2.7

Текущее напряжение EVSE, см. выходное напряжение SAE

[V2G2-265]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать данный тип, как определено в таблице 104 и в соответствии с рисунком 57.

[V2G2-266]

Элемент сообщения должен использоваться, как определено в таблице 59.

Имя элемента

Тип

Семантика

ServiceID

simpleType:

unsignedShort

см. определение типа в F.6

(приложение F)

Уникальный идентификатор сервиса

ServiceName

simpleType:

serviceNameType

цепочка (макс. длина: 32)

см. определение типа в F.6

(приложение F)

Факультативно:

удобочитаемое имя сервиса

ServiceCategory

simpleType:

serviceCategoryType enumeration

см. определение типа в F.6

(приложение F)

Категория сервиса соответствует определенным сервисам, полученным из базовых сервисов

ServiceScope

simpleType:

serviceScopeType

цепочка (макс. длина: 64)

см. определение типа в F.6

(приложение F)

Факультативно:

дополнительная информация об использовании данного сервиса

FreeService

simpleType

логическое выражение

см. определение типа в F.6

(приложение F)

Элемент используется SECC для указания, может или нет EVCC использовать данный сервис бесплатно. Если FreeService равно True, EV может использовать предлагаемый сервис бесплатно. Если FreeService равно False, сервис, если он используется EV, будет оплачиваться с помощью метода оплаты, согласованного с помощью элемента сообщения PaymentOptionListType

[V2G2-267]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать данный тип, как определено в таблице 104 и в соответствии с рисунком 58.

[V2G2-268]

Элемент сообщения должен использоваться, как определено в таблице 60.

Имя элемента

Тип

Семантика

Service

complexType:

serviceType

Содержит всю информацию для идентификации сервиса. ServiceList включает не менее одного сервиса и может включать до восьми сервисов

[V2G2-271]

В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2, EVCC и SECC должны реализовывать данный тип, как определено в таблице 104 и в соответствии с рисунком 59.

[V2G2-272]

Элемент сообщения должен использоваться, как определено в таблице 61.

Имя элемента

Тип

Семантика