allgosts.ru43. ДОРОЖНО-ТРАНСПОРТНАЯ ТЕХНИКА43.120. Электрические дорожно-транспортные средства

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

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

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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ


58123—

2018

(ИСО 15118-2: 2014)

ТРАНСПОРТ ДОРОЖНЫЙ Интерфейс связи

автомобиль — электрическая сеть

Часть 2

Требования к протоколу сетевого и прикладного уровней

(ISO 15118-2:2014, MOO)

Издание официальное

Москва

Стандартимформ

2018


Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием «Центральный ор-дена Трудового Красного Знамени научно-исследовательский автомобильный и автомоторный институт» (ФГУП «НАМИ») на основе собственного перевода на русский язык англоязычной версии стандарта. указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 56 «Дорожный транспорт»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 2 октября 2018 г. № 688-ст

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО 15118-2:2014 «Дорожные транспортные средства. Интерфейс связи транспортного средства и электросети. Часть 2. Требования к информационной сети и прикладному протоколу» (ISO 15118-2:2014 «Road vehicles — Vehicle-to-Grid Communication Interface — Part 2: Network and application protocol requirements», MOD) путем изменения отдельных фраз. слов, ссыпок, которые выделены в тексте курсивим, а также путем изменения его структуры для приведения в соответствие с правилами, приведенными в ГОСТ 1.5—2001 (пункт 3.12).

Внесение указанных технических отклонений направлено на учет особенностей объекта стандартизации. характерных для Российской Федерации, и целесообразности использования ссылочных национальных стандартов вместо ссылочных международных стандартов.

Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте, приведены в Дополнительном приложении ДА.

Сопоставление структуры настоящего стандарта со структурой примененного в нем международного стандарта приведено в дополнительном приложении ДБ

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N9 162-ФЗ «О стандартизации е Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — е ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано е ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© ISO, 2014 — Все права сохраняются © Стацдартинформ, оформление. 2018

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

Содержание

1 Область применения..................................................................1

2 Нормативные ссылки..................................................................1

3 Термины и определения.................................................................2

4 Обозначения и сокращения............................................................4

5 Понятия............................................................................5

5.1 Определение сервисов на базе стандарта взаимодействия открытых систем (OSI)...........5

5.2 Структура требований.............................................................5

5.3 Использование RFC-ссылок........................................................5

5.4 Представление, используемое для диаграмм XML-схем.................................5

6 Обзор документов....................................................................6

7 Базовые требования к связи V2G........................................................t

7.1 Общая информация...............................................................7

7.2 Концепция сервисного примитива уровневой архитектуры OSI............................7

7.3 Концепция безопасности...........................................................8

7.4 Состояния связи V2G и работа с каналом данных.....................................15

7.5 Канальный уровень..............................................................20

7.6 Сетевой уровень.................................................................20

7.7 Транспортный уровень............................................................21

7.8 Коммуникационный протокол V2G..................................................25

7.9 Представительский уровень.......................................................28

7.10 Уровень приложения............................................................37

8 Сообщения прикладного уровня.......................................................43

8.1 Общая информация и определения.................................................43

8.2 Определение подтверждения протокола.............................................44

8.3 Определение сообщения V2G......................................................47

8.4 Определения сеанса связи V2G и элементов тела сообщения...........................49

8.5 Комплексные типы данных........................................................86

8.6 Идентификационные режимы и определения наборов сообщений.......................119

8.7 Хронирование связи V2G.........................................................156

8.8 Задание последовательности сообщений и обработка ошибок..........................168

8.9 Примеры последовательностей сообщений запрос-ответ..............................189

Приложение А (справочное) Сводная таблица требований..................................197

Приложение В (обязательное) Профили сертификатов.....................................203

Приложение С (справочное) Применение сертификатов....................................213

Приложение D (справочное) Шифрование для распределения секретных ключей...............224

Приложение Е (справочное) Обзор XML-подписей.........................................226

Приложение F (рекомендуемое) Определения схем........................................230

Приложение G (обязательное) Требования к идентификаторам..............................258

Приложение Н (справочное) Задание последовательности сообщений для пересогласования .... 260 Приложение I (справочное) Привязка имен элементов сообщений ISO 15118 к терминам

SAE J2847/2 ............................................................ 264

Приложение J (справочное) Примеры сообщений.........................................268

Приложение К (справочное) Привязка элементов случаев использования части 1...............291

Приложение ДА (справочное) Сведения о соответствии ссылочных национальных стандартов

международным стандартам, испольэиванным в качестве ссылочных в примененном международном стандарте.................................331

Приложение ДБ (справочное) Сопоставление структуры настоящего стандарта со структурой

примененного в нем международного стандарта.............................332

Библиография.......................................................................333

Введение

Международная организация по стандартизации (ИСО) объединяет национальные организации по стандартизации (комитет — член ИСО). Разработка международных стандартов осуществляется, как правило, техническими комитетами ИСО. Каждый комитет — член ИСО. заинтересованный в участии в проектах по тематике, для которой был создан технический комитет, имеет право быть представленным в этом комитете. Международные правительственные и неправительственные организации, связанные с ИСО. также принимают участие в работе объединения. ИСО непосредственно сотрудничает с Международной электротехнической комиссией (МЭК) по всем вопросам стандартизации электротехнических изделий.

Методики, использованные для разработки настоящего стандарта и для его дальнейшего применения. содержатся в директивах ИСО/МЭК. часть 1. В частности, следует отметить различные критерии. используемые для утверждения разных типов документов ИСО. Настоящий стандарт составлен в соответствии с редакторскими правилами части 2 директив ИСО/МЭК (www.iso.org/directives).

Следует иметь в виду, что некоторые положения настоящего стандарта могут быть объектом патентных прав. ИСО не несет ответственности за идентификацию какого-либо одного или всех патентных прав. Детали любого патентного права, выявленного при разработке стандарта, должны находиться в введении и/или в перечне полученных патентных заявок ИСО (www.iso.org/patents).

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

Толкование значений специфических терминов ИСО и выражений, относящихся к оценке соответствия. а также информация о строгом соблюдении ИСО принципов Всемирной торговой организации (ВТО) в отношении технических барьеров в торговле (ТБТ) содержатся по URL-адресу: www.iso.org/ foreword.html.

Настоящий стандарт курирует Технический комитет ISO 22 «Дорожные транспортные средства». подкомитет SC 3 «Электрическое и электронное оборудование».

Настоящий стандарт разработан при сотрудничестве с Техническим комитетом МЭК/ТК 69 «Электромобили и грузовые электрокары промышленного назначения».

ИСО 15118 под общим названием «Транспорт дорожный. Интерфейс связи автомобиль — электрическая сеть» состоит из следующих частей:

- часть 1: Общая информация и определение случаев использования;

- часть 2: Требования к протоколу сетевого и прикладного уровней:

- часть 3: Требования к физическому и канальному уровням.

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

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

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

ГОСТ Р 58123—2018 (ИСО 15118-2:2014)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ТРАНСПОРТ ДОРОЖНЫЙ Интерфейс связи автомобиль — электрическая сеть

Часть 2

Требования к протоколу сетевого и прикладного уровней Road vehicles. Vehide-to-Grid Communication Interface. Part 2. Network and application protocol requirements

Дата введения —2019—06—01

1 Область применения

Настоящий стандарт определяет связь между аккумуляторными электромобилями (BEV). гибрид* ными автомобилями с подзарядкой от электросети (PHEV) и оборудованием электроснабжения электромобиля (EVSE). Набор команд для приложения, требования к которому устанавливает настоящий стандарт, служит для поддержки передачи энергии от EVSE к электроавтомобилю (EV). ГОСТ Р 58122 (ИСО 15118-1:2013) содержит дополнительные элементы случаев использования (часть 1. идентификаторы элементов случаев использования: F4 и F5), описывающие двунаправленную передачу энергии. Реализация указанных случаев использования требует оптимизации набора команд для приложения, описываемого в настоящем стандарте.

Настоящий стандарт распространяется на сети между EV (BEV или PHEV) и EVSE и устанавливает требования к особенностям обнаружения EV в коммуникационной сети и подключения по интернет-протоколу (IP) между EVCC и SECC (си. рисунок 1).

1 — прмимг иаетоаже ялиещла;

2 — определение сообщений учитывает случаи использования, которые определены для связи между SECC и SA

Рисунок 1 — Коммуникационные отношения между EVCC, SECC и вторичным субъектом

В настоящем стандарте описаны сообщения, модель данных, формат представления данных на базе XML/EXI, использующих протоколы связи V2GTP. безопасности транспортного уровня TLS. управления передачей TCP и IPv6. Также в нем описан доступ к сервисам канального уровня с точки зрения уровня 3. Функциональность канального уровня и физического уровня описана в [1].

2 Нормативные ссылки

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

ГОСТ Р 58122—2018 (ИСО 15118*1:2013) Транспорт дорожный. Интерфейс связи автомобиль — электрическая сеть. Часть 1. Общая информация и определение случаев использования

Издание официальное

ГОСТ Р МЭК 61851-1—2013 Система токопроводящей зарядки электромобилей. Часть 1. Общие требования

ГОСТ Р МЭК 62196*1—2013 Вилки, штепсельные розетки, соединители и вводы для транспортных средств. Кондуктивная зарядка для электромобилей. Часть 1. Общие требования

ГОСТ Р МЭК 62196*2—2013 Вилки, штепсельные розетки, соединители и вводы для транспортных средств. Кондуктивная зарядка для электромобилей. Часть 2. Требования размерной совместимости и взаимозаменяемости для штыревых разъемов и арматуры сети переменного тока

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на хоторый дана датированная осылка. то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения {принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная осылка. внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение. в котором дана ссылка на него, рекомендуется применять е части, на затрагивающей эту осыпку.

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ 58122 (ИСО 15118-1), а также следующие термины с соответствующими определениями:

3.1 базовая зарядка; ВС: Этап зарядки во время сеанса зарядки, управляемый в соответствии с ГОСТ Р МЭК 61851-1.

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

3.3 таймер установления связи: Таймер, отслеживающий время от подключения до сообщения об установлении сеанса.

3.4 сертификат контракта: Сертификат, выдаваемый EVCC либо корневым удостоверяющим органом (СА) коммуникации транспортного средства и электросети или подчиненным удостоверяющим органом (Sub-CA), который используется в XML-подписях на уровне приложения для того, чтобы SECC или вторичный субъект мог проверить контракт, выданный EVCC, и подписи, выданные EVCC.

3.5 состояние линии управления: Состояние EV. передаваемое по линии управления е соответствии с ГОСТ Р МЭК 61851-1.

3.6 удостоверение: Что-либо, обеспечивающее основу для уверенности, доверия, кредита и т. д.

Пример — Сертификаты, пароли, имена пользователя и т. д.

3.7 установление канала связи: Этап установления канала обмена данными.

Примечание 1 — Условие входа: тобой действительный сигнал линии управления 8 соответствии с ГОСТ Р МЭК 61851-1: условие выхода: D-LINK_READY.irxJication{DLINKSTATUS=LinkEstablisbed).

3.8 особые правила кодирования а правило кодирования ASN-1; DER: Метод кодирования объекта данных, например сертификата Х.509. подлежащего подписанию цифровой подписью или проверке подписи.

3.9 глобальный адрес: IP-адрес с неограниченным охватом.

3.10 зарядка со связью по протоколу высокого уровня; HLC-C: Один из этапов зарядки в соответствии с настоящим стандартом.

3.11 локальный адрес канала: IP-адрвс, действующий только для данной линии связи, который может быть использован для доступа к смежным интерфейсам, подключенным к той же линии связи.

3.12 идентификационный режим: Обязательные и факультативные сообщения и параметры для идентификации, относящиеся к сценариям зарядки, которые используют внешние средства идентификации (EIM). и к сценариям зарядки, использующим режим «Plug and Charge» (РпС).

Примечание 1 — Идентификационный режим охватывает набор схожих сценариев зарядки для конкретного средства идентификации.

3.13 IP-адрес: Идентификатор межсетевого уровня для интерфейса или набора интерфейсов.

3.14 максимальная единица передачи; MTU: Максимальный размер (в байтах) наибольшего блока протокольных данных, который канальный уровень может передать.

3.15 набор сообщений: Набор обязательных сообщений при взаимодействии транспортного средства и электросети (V2G) и параметров для EVCC или SECC. охватывающий один или несколько элементов случаев использования.

3.16 таймер сообщений: Таймер, осуществляющий мониторинг пары запрос-ответ.

3.17 сетевой сегмент: Совокупность устройств, которые могут обмениваться данными на канальном уровне непосредственно через канальные адреса.

Пример — Локальная сеть Ethernet: все устройства, которые могут видеть друг друга посредством МАС-адресов.

3.18 узел: Устройство, которое реализует IPv6.

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

3.20 время исполнения: Нефункциональное временное требование, определяющее время, которое не должно быть превышено объектом V2G при исполнении или обработке определенного задания.

Примечание 1 — Это фиксированное значение времени.

3.21 частная среда: Зона с ограниченным (физическим) доступом для небольшого числа транспортных средств (EV). Данная зона может быть частным парковочным гаражом или гаражом/парковоч-ной стоянкой компании, владеющей собственным парком EV. вместо общественных зарядных станций EVSE могут использоваться один или несколько частных настенных зарядных блоков. Для того чтобы частный настенный зарядный блок был простым и дешевым в производстве и эксплуатации, ему разрешается постоянно оставаться в режиме офлайн. Это позволяет частному настенному зарядному блоку использовать листовые сертификаты с более длительным максимальным сроком действия, чем разрешаемый для публичных зарядных станций, а также использовать личный корневой сертификат, который отличается от корневых сертификатов V2G и который должен быть установлен на каждое EV. Если зарядка EV разрешена в данной конкретной частной зоне, то результатом будет ограничение числа EV. принадлежащих котдельной частной среде. При этом отличие от «надежной среды» заключается в том. что в частной (собственно частной, а не обладающей дополнительной «надежностью») среде TLS. где соответствующее шифрование данных на уровне соединения всегда используется, обработка сертификатов упрощена для частного настенного зарядного модуля (EVSE). поскольку он может находиться в режиме офлайн постоянно, обеспечивая неограниченные сроки действия сертификатов, более короткую длину цепочки сертификатов, исключение OCSP и дополнительного «режима сопряжения».

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

3.23 пересогласование: Обмен сообщениями для актуализации графика зарядки, согласованного между EV и EVSE во время сеанса связи V2G. путем повторной передачи параметров SASchedule и Charging Profile.

3.24 пара сообщений запрос-ответ: Сообщение-запрос и соответствующее сообщение-ответ.

3.25 последовательность сообщений запрос-ответ: Предопределенная последовательность пар сообщений запрос-ответ.

3.26 клиент SOP: Субъект V2G. который использует сервер SDP, чтобы получить информацию о конфигурации SECC для обеспечения возможности доступа к SECC.

3.27 сервер SDP: Субъект V2G. предоставляющий информацию о конфигурации для доступа к SECC.

3.28 сертификат SECC: Сертификат, выдаваемый SECC либо корневым СА V2G. либо Sub-CA. который используется в TLS для того, чтобы EVCC мог проверить аутентичность SECC.

3.29 таймер последовательности: Таймер, осуществляющий мониторинг последовательности сообщений запрос-ответ.

3.30 Sub-CA: Подчиненный удостоверяющий орган, который выдает сертификаты SECC и/или сертификаты контракта от имени корневого СА V2G.

Примечание 1 — Полномочие на выдачу сертификатов делегируется корневым СА V2G. и он может отозвать сетрификаты Sub-CA в побое время.

3.31 сертификат Sub-CA: Сертификат, выдаваемый органом Sub-CA.

3.32 TCP.DATA: Порт/интерфейс для передачи данных на базе ТСР-соединения.

3.33 тайм-аут: Требование, определяющее время, в течение которого объект V2G осуществляет мониторинг системы связи до наступления определенного события.

Примечание 1 —Если заданное время превышено, соответствующий объект V2G инициирует обработку связанной с этим ошибки. Это фиксированное значение времени.

3.34 таймер: Устройство или элемент программного обеспечения, используемый для измерения времени.

Примечание 1 — В зависимости от конкретного случая использования таймер применяется для запуска определенных системных элементов.

3.35 безопасная зона: Закрытая пользовательская группа (например, участники системы по совместному пользованию транспортными средствами) с некоторым предварительно распределенным средством доступа к зарядному сервису SECC (например, ключ от домашнего гаража, радиочастотный брелок для совместного пользования транспортными средствами), т. е. группа, за которую кто-то отвечает. например владелец гаража, оператор системы совместного пользования транспортными средствами или оператор такси.

3.36 цикл V2G: Этап обмена сообщениями V2G для управления процессом зарядки в соответствии с настоящим стандартом.

3.37 сеанс связи V2G: Ассоциация двух конкретных субъектов V2G для обмена сообщениями V2G.

3.38 субъект V2G: Первичный субъект, участвующий в связи V2G с помощью обязательного или дополнительного коммуникационного протокола, требования к которому установлены в настоящем стандарте

3.39 сообщение V2G: Сообщение, обмен которым происходит на уровне приложения.

Примечание 1 — См. раздел 8 «Сообщения прикладного уровня».

3.40 установление V2G: Этап установления обмена сообщениями V2G.

Примечание 1 — Условие входа: D-LlNK_READY.tndicat>or*{DLINKSTATUS=LinkEstablished); условие выхода: PowerOeiiveryReq с ChargeProgress равен Start или Stop.

3.41 коммуникационный протокол V2G: Коммуникационный протокол для передачи сообщений V2G между двумя субъектами V2GTP.

3.42 субъект V2GTP: Субъект V2G. поддерживающий коммуникационный протокол V2G.

3.43 корневой СА V2G: Удостоверяющий орган (СА), который выдает сертификаты контракта и/или сертификаты SECC либо делегирует полномочие на выдачу таких сертификатов Sub-CA.

3.44 корневой сертификат V2G: Сертификат, выдаваемый корневому СА V2G.

4 Обозначения и сокращения

В настоящем стандарте применены следующие обозначения и сокращения:

BEV — аккумуляторное электрическое транспортное средство;

СА — удостоверяющий орган;

CRL — перечень аннулированных сертификатов:

DH — криптографический протокол Диффи — Хеллмана;

DER — особые правила кодирования;

ECDSA — алгоритм цифровой подписи на основе эллиптических кривых;

EMAIO — идентификатор аккаунта EVEV;

ЕМОСН — центр обработки данных оператора услуг для EV [см. также ГОСТР58122(15118-1:2013)}; EV — электрическое транспортное средство;

EVCC — контроллер связи электрического транспортного средства;

EVSE — оборудование электропитания электрических транспортных средств;

EXI — эффективный XML-обмен;

OCSP — протокол статуса онлайнового сертификата:

OEM — изготовитель транспортных средств;

NACK — отрицательное квитирование;

PDU — блок протокольных данных:

PHEV — подзаряжаемое гибридное электрическое транспортное средство;

PKI — инфраструктура открытых ключей;

PLC — связь по силовой линии электропередачи;

РпС — «Plug and Charge» («Подключай и заряжай»);

SA — вторичный субъект;

SDP — протокол обнаружения SECC;

SOU — блок сервисных данных:

SECC — контроллер связи оборудования электропитания:

TLC — безопасность транспортного уровня;

TCP — протокол управления передачей;

V2G — взаимодействие транспортных средств и электросети;

V2G Ci — интерфейс связи взаимодействия транспортных средств и электросети;

V2GTP — коммуникационный протокол V2G;

UDP — протокол пользовательских дейтаграмм;

XML — extensible Markup Language (расширяемый язык разметки).

5 Понятия

5.1 Определение сервисов на базе стандарта взаимодействия открытых систем (OSI)

Настоящий стандарт базируется на понятиях сервисов OSI (см. [2)) применительно к отдельным уровням, описанным в настоящем стандарте.

Настоящий стандарт описывает требования, применяющиеся к уровням 3—7 в соответствии с уровневой архитектурой OSI.

5.2 Структура требований

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

«(V2G"Y"-"XXXn» — текст требования, где:

> «V2G» характеризует объект требований настоящего стандарта,

• V идентифицирует номер части настоящего стандарта,

• XXX представляет собой номер индивидуального требования и

- «текст требования» включает фактический текст требования.

Пример — [V2G2-000]— это пример требования.

5.3 Использование RFC-ссылок

При использовании RFC-ссылок все требования «должен/не должен» являются обязательными.

Примечание — Номера требований описаны е приложении А.

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

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

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

5.4 Представление, используемое для диаграмм XML-схем

В настоящем стандарте в качестве формата для описания сообщений V2G используется XML. Подробности относительно обозначений XML-схем. используемых в настоящем стандарте, приведены в руководстве Р).

Для облегчения различения типов определений, используемых в XML-схемах, в настоящем стандарте для имен приняты следующие правила:

- у комплексных типов первые буквы прописные;

- у простых типов первые буквы строчные.

б Обзор документов

На рисунке 2 показаны требования, содержащиеся е настоящем стандарте, ГОСТ Р 58122 (ИСО 15118*1:2013) и[1}. и их распределение в соответствии с уровневой архитектурой OSI.

Полужирными рамками выделены требования, применяющиеся к уровням 3—7 в соответствии с уровневой архитектурой OSI, светлыми рамками — требования уровней 1 и 2. включая стандартизованный интерфейс сервисных примитивов V2G. данные в (1).


/-\

ХМИН»2

Ов)

Ямлынв

К_>



□ —уровни ОЯ и лрмпямьв трнОомыии, опмаиныи в нвствацан етацдотв;

I Ч — урони03 клриимиммвтробоиимя огжакнь»» РОСТР№122(И001W.-JWS? иff} Рисунок 2 — Обзор связи документов V2G

7 Базовые требования к связи V2G

7.1 Общая информация

В настоящем стандарте описана реализация элементов случаев использования V2G. определения которых даны в ГОСТ Р 58122 (ИСО 15118-1:2013).

7.2 Концепция сервисного примитива уровневой архитектуры OSI

7.2.1 Обзор

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

Требования к сервисам устанавливаются путем описания сервисных примитивов и параметров, характеризующих сервис. Это абстрактное определение сервисов, не требующее конкретной реали* зации.

На рисунке 3 показан упрощенный вид взаимодействия уровней OSI. достаточный для понимания принципов уровневой архитектуры OSI в контексте настоящего стандарта.

Сущность V2G m Сущность V2G m+1



POU — блок протокольных ванных сетевого объекта; PCI — информация управления протоколом:

SOU — блок сервисных ванных сетевого объекта


Рисунок 3 — Принципы уровневой архитектуры OSI

Когда экземпляр пт субъекта V2G уровня i+1 обменивается данными с экземпляром гп+1 субъекта V2G уровня i+1. каждый экземпляр использует сервисы экземпляра уровня i. Сервис определяется как набор сервисных примитивов.

7.2.2 Синтаксис сервисных примитивов

Сервисные примитивы описываются следующим синтаксисом:

(Инициал уровня]-[ИМЯ].[тип примитива}(список параметров), где

• (инициал уровня} один из следующих семи: (Физический, Канальный. Сетевой. Транспортный. Сеансный. Представительский. Приложение}:

- (ИМЯ] есть имя примитива.

Пример— Типичными примерами для поля (ИМЯ] являются СОЕДИНИТЬ. РАЗЪЕДИНИТЬ, ДАННЫЕ. В настоящем стандарте и в [1] используются также другие имена:

■ [тип примитива] один из следующих четырех: (запрос, индикация, ответ, подтверждение];

♦ (список параметров) включает список отделяемых запятой параметров, которые пользователь сервиса должен предоставлять при использовании соответствующего сервисного примитива; факультативные параметры отмечены скобками «[..}».

Примечание — В настояцем стандарте тип примитива «indication» (индикация) всегда указывает на событие асинхронно по отношению к верхнему уровню.

7.3 Концепция безопасности

7.3.1 Потоки вызовов (блок-схемы)

На рисунках 4 и 5 проиллюстрированы примеры связи в полуонлайновом и онлайновом режимах с точки зрения безопасности и показаны необходимые применяемые сервисы безопасности, а также абстрактный вид различных данных, необходимых для работы.

Полные схемы потока данных/последоеательности приведены е подразделе 8.8 настоящего стандарта. На данных обзорных рисунках следует выделять только информацию, относящуюся к безопасности.

Концепция безопасности обеспечивает базовый защитный механизм для осуществления связи в сети таким образом, чтобы предотвратить несанкционированный доступ. Для определенных сценариев требуется применение безопасности транспортного уровня (TLS) для связи между EVCC и SECC. Для некоторых других сценариев использование TLS является факультативным. Конкретные сообщения защищаются на уровне приложения (XML-сообщения). если данные необходимо защитить на пути от вторичного субъекта или к нему или если защита должна существовать дольше, чем существует TLS. Кроме того, концепция не зависит от дополнительных защитных механизмов на уровнях ниже уровня 3 уровневой модели OSI.

На рисунке 4 показан пример использования дежурного соединения для режима РпС.

В режиме идентификации РпС вся связь на базе TCP/IP защищается с помощью аутентифицируемого е одностороннем порядке канала TLS между двумя одноранговыми субъектами (TLS не обязательна для некоторых режимов, кроме режима идентификации РпС).

Конечным пунктом всей связи является SECC. Показания прибора учета периодически подписываются транспортным средством для поддержки процесса расчета (см. 8.4.3.13.1). Эта информация может быть использована для расчета, если местные правила это разрешают. EVSE предоставляет учетные данные о зарядке, содержащие подписанные показания прибора учета для дальнейшей обработки.

Примечание 1 — Связь между SECC и SA на рисунке 4 показана только с целью информации и не служит для установления конкретной последовательности сообщений.

На рисунке 5 показан пример в онлайновой режиме связи для случая использования РлС.

Как и в полуонлайновом режиме, в данном примере в режиме РпС вся связь на базе TCP/IP защищается с помощью аутентифицируемого в одностороннем порядке канала TLS между двумя одноранговыми сущностями (TLS не обязательна для некоторых режимов, кроме режима РпС).

Может потребоваться передача вторичному субъекту для дальнейшей обработки части информации. предоставляемой транспортным средством, например удостоверений транспортного средства, чтобы обеспечить возможность подписания информации о тарифе. EVCC рассчитывает профиль зарядки (см. 8.4.3.9.2) и посылает его SECC. который может направить его системам SA. Дальнейший процесс аналогичен полуонлайновому режиму, за исключением того, что окончательные данные о зарядке могут быть предоставлены SA напрямую. Предполагается, что SECC будут также использовать безопасное транспортное соединение с SA. хотя безопасность связи транспортного средства с SA обеспечивается на прикладном уровне.

Примечание 2 — Связь между SECC и SA на рисунке 5 показана только с цепью информации и не служит для установления конкретной последовательности сообщений.

twee


Нечапо Процессе середке


L


Установке сакм


на


Ф*


Зеб»


втсриюмй субиел ISA)


мый (полу-)


еидейяоеыа овтеои

упоеттерепиами боюпосиести. янрчор ответы 06СР. пергой еииулиревмям а

серпфиаетоа. сертяфмвты

(не ездит а объем иестоааей одеиифмкеиии)


I

1

1

1

1

7


Установи«овне» TLS


(lexMleO


lanwMrtoIl


предеясеение в соответствии

с а. Т.7 J


SwSTSmo


Нтйтлпн


сертификат (VM Дна ироае реи сортифиеето TLS

см оероервУЭв


саряо>м<МгрДсеесо*ее1)


ырсоА«иерет«еес<*п|)


. продвлвевнив в соответствии cc.it


Идентификация. аутеитифмсмамивоторитаиииУ


Необеадем сертнфиат юатрмтас овочом аяепочеоЯ


Pevneni&cceMcaM


т

Намедиие мелея и форчшрпоичю плене


Цикл еонтролн и•


Pav>*«*tOvu<*iMO

AwlhertUlioMeil)

_ продетвкие ■ coereerci СС 84

ими имл»

Неовмчми есриееоа сертнфике* V2O


Т

<---

Оилртц&ИмЯт|)

W 4

и


Опция учета


Нео&юви!

еоитректа с ключом

МстептмаекврМиц)

Зеаерменме процессе аеридси /

■ « п.4.8


... маерцмимо в ооответст

Отпря


■ |галыее


дпяРпС|У'


СГ


(полу) сипим мои» обмен подпиеи«»1ми кветморееи приборе учете яре профиля мрядеи а режиме (ио ресометраммтсж о местоацем стендерте)


ь,

Необседяи яормевой сертифиеет еои треста


Рисунок 4 — Пример связи в полуонлайновом режиме

I I I


Рисунок 5 — Пример связи в онлайновом режиме


Имеются случаи дополнительного использования связей, в которых механизмы безопасности не* обходимы на уровне приложения. Речь идет о начальной регистрации контрактных ключей и сертификата, а также об обновлении сертификата. В этих случаях используются ключи изготовителя для кон* кретного транспортного средства. Обзор всех необходимых сертификатов содержится в приложении В.

7.3.2 Управление сертификатами и ключами

Потоки вызовов, описанные в 7.3.1. требуют наличия нескольких сертификатов, применяемых для разных уровней безопасности. Используют сертификаты SECC, применяемые на уровне TLS для их аутентификации EVCC. сертификаты контрактов, применяемые на уровне приложения для аутентификации SECC и/или вторичного субъекта, корневые сертификаты V2G и сертификаты Sub-CA. которые удостоверяют сертификаты SECC и сертификаты контрактов.

Кроме вышеуказанных сертификатов, могут испогъэоеатъся корневые сертификаты изготовителя и сервисные сертификаты изготовителя, применяемые для установки и обновления сертификатов контрактов.

Обзор всех возможных профилей приведен в приложении В.

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

В таблице 1 показано, из каких полей состоит сертификат X.509v3.

Таблица 1 — Базовые поля сертификата

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

Описание

Версия

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

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

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

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

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

Эмитент

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

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

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

Субъект

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

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

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

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

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

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

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

Расширения

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

Подпись

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

Примечание 1 — Информацию о полях сертификата см. в/4/.

В зависимости от случая использования сертификата X.509v3 в него может быть включена до* полнительная информация о так называемых расширениях сертификатов. В таблице 2 обобщены рас* пространенные расширения сертификатов.

Таблица 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).

Окончание таблицы 2

Расширения

сертификатов

Описание

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

Microsoft SGC (2.16.840.1.113730.4.1).

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

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

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

OCSP

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

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

информация

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

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

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

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

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

Примечание 2 — Информация об идентификаторах объектов, например 1.3.6.1.5.5.7.3.1, приведена в /б/.

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

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

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

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

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

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

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

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

Примечание 3 — Эго требование теоретически даже позволяет применять точность, например до одного года. Реализующий должен тщательно взвесить последствия в отношении безопасности такого решения.

Примечание 4 — Если соединение TLS успешно установлено. EVCC может использовать время от поля EVSETimeStamp, посылаемое от SECC через указанное соединение, для синхронизации своего внутреннего генератора синхроимпульсов, однако реализующий должен тщательно взвесить последствия в отношении безопасности такого решения.

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

7.3.3 Число корневых сертификатов и срок их действия, глубина и размер сертификата [V2G2-008} Каждый EVCC должен поддерживать не менее одного корневого сертификата V2G. [V2G2-877J Каждый SECC должен поддерживать хранение не менее чем 10 корневых сертифи-

катов V2G.

Примечание 1 — Ввиду наложения сроков действия могут существовать до 10 одновременно действительных сертификатов (см. (V2G2-012)}.

Примечание 2 — Настоятельно рекомендуется число корневых сертификатов V2G. равное 5. При этом только один является обязательным. Наличие меньше пяти или только одного сертификата связано с риском для изготовителя. Наличие только одного корневого сертификате V2G позволяет осуществлять зарядку транспортного средства только в одном регионе. Изготовитель должен будет указать в руководстве и во время предложения транспортного средства потребителям, что зарядка транспортного средства возможна только в «домашнем» регионе. Если изготовитель опасается, что пяти корневых сертификатов V2G недостаточно для покрытия «радиуса использования» его транспортных средств, он может обеспечтть больше мест хранения корневых сертификатов.

Примечание 3 — Предполагается, что корневые сертификаты V2G. применяемые на уровне 4 OSI. также используются на уровне 7 OS!. Предполагается также, что в Европе будет один удостоверяющий орган для корневых сертификатов, аналогичный доверительному центру, который был создан для EURO5/EU5, что другие регионы мира будут также иметь удостоверяющий орган для корневых сертификатов, охватывающих большее число субъектов. Это позволяет предположить, что пяти корневых сертификатов для пяти регионов мира достаточно. Если будет принято решение о дополнительном пространстве для сертификатов, то это не повлияет на совместимость. Для SECC. однако, является обязательным хранение большего числа сертификатов, поскольку может существовать 10 одновременно действующих корневых сертификатов для каждого региона мира.

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

Примечание 4 — Ограничение длины пути определяет число несамоподписных сертификатов в пути удостоверения, т. е. имеется до трех уровней сертификатов, производных от корневого сертификата.

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

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

[V2G2-012] В любой момент времени должен быть в наличии корневой сертификат V2G. действительный для каждого СА корневых сертификатов V2G по крайней мере в течение последующих 35 лет.

Примечание 5 — Пояснения относительно срока действия сертификата, числа корневых сертификатов, глубины и размера сертификата приведены в С.1 (приложение С).

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

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

Примечание 6 — Только Sub-CAмогут выдавать листовые сертификаты.

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

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

Следующие требования обеспечивают упрощенную обработку сертификатов в условиях частного пользования. Более подробное пояснение приведено в С.2 (приложение С).

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

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

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

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

Примечание 7 — Это означает, что корневой сертификат частного оператора напрямую подписывает листовой сертификат.

7.3.4 Поддержка и применение TLS

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

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

На базе установления TCP или TLS на транспортном уровне действуют следующие ограничения: [V2G2-632] Если используется сеанс связи без TLS, SECC должен только обеспечивать идентификационный режим EIM и наборы сообщений зарядки переменным током с EIM или зарядки постоянным током с EIM. указав «ExtemalPayment» в параметре

PaymentOptionList сообщения ServiceDiscoveryRes. как указано в 8.4.3.3.3.

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

[V2G2-634] Если используется ованс связи без TLS. SECC не должен выдавать наборы сообщений РпС. [V2G2-635] Если используется сеанс связи без TLS. EVCC не должен применять наборы сообще

ний РпС.

[V2G2-636) Если используется сеанс связи без TLS. SECC не должен выдавать набор сообщений ДУ. (V2G2-637) Если используется сеанс связи без TLS. EVCC не должен применять набор сообщений ДУ. [V2G2-638] Меры безопасности для дополнительных услуг, разрешаемых набором сообщений ДУ

(предлагаемых в ServiceDiscoveryRes), не рассматриваются в настоящем стандарте.

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

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

Поддержка, использование и ограничения TLS приведены в таблицах 3 и 4.

Таблица 3 — Поддержка TLS для идентификационных режимов EIM

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

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

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

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

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

с EIM

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

Переменный ток с£»М. ДУ

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

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

Постоянный

tokcEIM.

ДУ

Переменный ток с Е1М.ДУ

EVCC

Поддержка

TLS

Факульта

тивно

Факульта

тивно

Обязатель

но

Обязатель

но

Факульта

тивно

Факульта

тивно

Обяза

тельно

Обяза

тельно

SECC

Поддержка

TLS

Обяза

тельно

Обяза

тельно

Обяза

тельно

Обяза

тельно

Факульта

тивно

Факульта

тивно

Обяза

тельно

Обяза

тельно

Согла

сование

использования TLS с помощью SOP*

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

Окончание таблицы 3

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

й Отклонение означает прекращение коммуникации. с См. определение в (1}.

Примечание 1 — Отсутствие поддержки TLS SECC может привести в общем случав к прекращению сеанса зарядки конкретных EV. поскольку за одобрение сеансов без TLS отвечает EV.

Таблица 4 — Подтверждение SDP при зарядке переменным и постоянным током с идентификационным режимом Е1М в безопасной среде

Поддержка TLS EVCC

Поддержка TLS SECC

Запрос SOP EVCC

Отеет SDP or 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

Примечание 2 — Для набора сообщений кЕ1М АС» («зарядка переменным током с Е1М») и «Е1М ОС» («зарядка постоянным током с Е1М») EV отвечает за решение о неиспользовании TLS и принятие риска небезопасного соединения.

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

Примечание 4 — Меры в отношении каких-либо связанных с функциональной безопасностью рисков вследствие перенапряжений и перегрузок по току (случайных или преднамеренных) должны приниматься путем реализации соответствующих стандартов эпектробеэопасности (например. ГОСТ Р МЭК 61851-1. (8), (9).{10[).

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

[V2G2-643] EVSE должно поддерживать меры безопасности, описанные в ГОСТ РМЭК 61851-1 и [8].

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

[V2G2-644] EVSE должно поддерживать меры безопасности, описанные в ГОСТ РМЭК61851-1 и [9].

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

7.4 Состояния связи V2G и работа с каналом данных

Обмен сообщениями V2G на уровне приложения требует установления протоколов нижнего уровня для обеспечения обмена сообщениями V2G между EVCC и SECC. В настоящем стандарте рассматриваются упомянутые выше протоколы канального уровня. Канальный уровень описан в [1].

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

Значения таймеров, тайм-аута и времени исполнения, используемые в данном подразделе, описаны в 8.8. На рисунке 6 показан обзор коммуникационных состояний EVCC. К EVCC применяются следующие требования:

(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-017J EVCC должен остановить механизм присваивания IP-адресов, как указано в 7.6.3.2 и 7.6.3.3. когда V2G_EVCC_CommunicationSetup_Timer равен или больше V2G_EVCC_ CommunicationSetup_Timeout.

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

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

[V2G2-645] 8 зависимости от протокола безопасности и транспортного протокола, запрошенно

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

[V2G2-020] EVCC должен остановить SDP. когда V2G_EVCC_CommunicationSetup_Timer равен или больше V2G_EVCC_CommunicaUonSetup_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_Communicat»onSetup_Timer равен или больше V2G_EVCC_ CommunicationSetup_Timeout.

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

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

(V2G2-717) Если EVCC отправил сообщение SessionStopReq с параметром Charging Session, равным «Terminate», он должен прекратить Data-Link {D-LINK_TERMINATE.request0) после получения сообщения SessionStopRes.

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

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

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

На рисунке 7 показан обзор состояний SECC во время сеанса коммуникации V2G.

К SECC применяются следующие требования:

[V2G2-721] После указания на успешное установление канала обмена данными (D-LINK_READY.

indication(DLINKSTATUS=Link established) SECC должен инициировать механизм присваивания адресов.

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

Примечание 1 — Описание присвоения адреса SECC для его интеграции в различные коммуникационные инфраструктуры не рассматривается в настоящем стандарте. Это позволяет оператору самому назначить надлежащий механизм. Например, оператор может выбрать любой существующий механизм, дающий действительный IP-адрес. как. например, статический IP. или механизм, описанный е 7.6.3.2 и 7.6.3.3.

Примечание 2 — SECC должен быть сконфигурирован с действительным IP-адресом для обеспечения соединения с EVCC. Механизм присвоения IP-адресов для SECC не влияет на совместимость. В настоящем стандарте он не рассматривается.

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

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

[V2G2-723] SECC должен остановить сервер SDP. когда SECC_CommunicabonSetup_Timer равен или больше V2G_SECC _CommunicaUonSetup_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-031J SECC должен ожидать установления соединения с TLS или TCP.

[V2G2-032] SECC должен прекратить ожидание установления соединения cTLS, когда V2G_SECC_

CommunicationSetup_Timer равен или больше V2G_SECC_CommunicationSetup_ Performance/Time.

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

[V2G2-722J Если (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()}H продолжить выполнение (V2G2-721).

7.5 Канальный уровень

Канальный уровень поддерживает транспорт пакетов IP. В ^/описаны необходимые дополнительные сведения о канальном уровне.

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

7.6 Сетевой уровень

7.6.1 Общие положения

Протокол, описанный в настоящем стандарте, базируется на интернет-протоколе, известном как IPv6 (см. [11]).

7.6.2 Применимые нормы RFC, ограничения и настройки параметров протокола

7.6.2.1 IPv6

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

(V2G2-038J Хотя [11] описывает IPsec как обязательный, от субъекта V2G не требуется реализа

ция IPsec.

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

Примечание 1 — Указания по назначению для поля типа маршрутизации в заголовке маршрутизации IPv6 даны в [13]. Рекомендуется придерживаться этих указаний.

[V2G2-040] Субъект V2G должен реализовывать определение MTU в соответствии с [14). (V2G2-0411 Субъект V2G должен поддерживать обработку наложений фрагментов IP в соответ

ствии с [15).

Примечание 2 — Субъект V2G должен соответствовать спецификации [16]. которая дополняет специфи-кацюо в соответствии с [11].

(V2G2-042) При отправлении пакета IPv6 от EVCC к SECC или от SECC к EVCC 1Р-фрагментация не должна использоваться.

Примечание 3 — Связь между EVCC и вторичными субъектами не рассматривается в настоящем стандарте. Она может использовать или не использовать 1Р-фрагментацию.

7.6.2.2 Протокол динамического управления хостами (DHCPV6)

Требования к каналу обмена данными описаны в [1]. EVCC начинает присвоение адресов, запускаемое каналом обмена данными, когда канальное соединение установлено. Это выполняется в соответствии с 7.6.3.2 с использованием SLAAC. которое является обязательным в соответствии с настоящим стандартом. DHCPv6 может быть реализован как факультативный метод конфигурирования IP.

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

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

7.6.2.3 Обнаружение соседних объектов (ОСО)

EVCC использует автоконфигурирование адресов без состояния для IPv6, чтобы генерировать адреса для его интерфейса. Все интерфейсы имеют локальный адрес канала. Для обеспечения уникальности адресов и для поддержки глобальных адресов используется протокол обнаружения соседних объектов.

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

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

7.6.2.4 Протокол управления сообщениями в сети Интернет (ICMP)

Протокол управления сообщениями в сети Интернет (ICMP) используется для отправки сообщений об ошибках (например, запрашиваемый сервис отсутствует, хост не доступен и т. д.).

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

[V2G2-049] Каждый субъект V2G должен реализовывать нормы RFC. на которые даются ссылки в колонке «Ссылка* таблицы 5. описывающей детали реализации для соответствующих типов сообщений ICMP.

Таблица 5 — Обязательный набор сообщений протокола управления сообщениями в сети Интернет (ICMP)

Тип сообщения 1CMP

Имя сообщения 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}

7.6.3 IP-адресация

7.6.3.1 Общие положения

В настоящем пункте описывается, как EVCC получает действительные IP-адреса для связи по сети на базе IP. Следующие адреса учитываются в настоящем стандарте:

- локальный IP-адрес канала EVCC:

- глобальный IP-адрес EVCC. если маршрутизатор присутствует в локальном канале;

- IP-адрес SECC.

Примечание — Хост IPv6 может иметь несколько IP-адресов, присвоенных одному физическому интерфейсу сети, например локальный адрес канала и глобальный адрес.

7.6.3.2 Автоконфигурирование адресов без состояния (SLAAC)

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

[V2G2-051} Идентификатор интерфейса локального адреса канала субъекта V2G должен генерироваться из его 48-битового МАС-идентификатора IEEE в соответствии с [22}.

[V2G2-052] EVCC должен поддерживать автоконфигурирование адресов IP6. как описано в [23}. (V2G2-053) Если SECC выдает наборы сообщений установки сертификатов, обновления серти

фикатов или дополнительные услуги, как указано в 8.6.2. он должен поддерживать варианты объявления маршрутизатора IPv6 в соответствии с (24} для предоставления адреса сервера DNS.

7.6.3.3 Выбор адресов

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

7.7 Транспортный уровень

7.7.1 Протокол управления передачей (TCP)

7.7.1.1 Обзор

Протокол управления передачей (TCP) позволяет приложениям субъектов V2G устанавливать надежное соединение для обмена данными с другими субъектами. Для надежного обмена и передачи данных от отправителя к получателю TCP дополнительно обеспечивает управление потоками и управление в условиях перегрузки, а также обеспечивает различные алгоритмы для осуществления контроля над перегрузкой и влиянием потоков.

7.7.1.2 Применимые RFC. ограничения и настройки параметров протокола (TCP)

(V2G2-055) Каждый субъект V2G должен осуществлять реализацию TCP, как указано в /26/.

7.7.1.3 Требования к производительности TCP и контрольной сумме

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

Рекомендуется использовать следующие алгоритмы повторной передачи дополнительно к стандартным методам TCP и управления в условиях перегрузки:

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

[V2G2-058J Каждый субъект 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/.

7.7.2 Протокол пользовательских дейтаграмм (UDP)

7.7.2.1 Обзор

Протокол пользовательских дейтаграмм (UDP) является протоколом без установления соединения. UDP не обеспечивает надежность и гарантии упорядочения, которые обеспечивает TCP. Пакеты могут приходить неупорядоченно или могут быть потеряны без уведомления отправителя или получателя. Однако UDP быстрее и более эффективен для многих легких или чувствительных ко времени задач. UDP находится на транспортном уровне модели уровнееой архитектуры OSI.

Случаи использования UDP с механизмами безопасности описаны в ГОСТ Р 58122 (ИС015118-1:2013) (приложение В).

7.7.2.2 Применимые RFC. ограничения и настройки параметров протокола

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

7.7.3 Безопасность транспортного уровня (TLS)

7.7.3.1 Обзор

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

7.7.3.2 Применимые RFC

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

EVCC аутентифицирует SECC в соответствии с [V2G2-067], что может быть также использовано для защиты циклического считывания показаний прибора учета между SECC и EVCC. Применение TLS с односторонней аутентификацией исключает необходимость дополнительной цифровой подписи показаний прибора со стороны SECC благодаря осуществлению безопасного сеанса.

Примечание 1 — В случав оплаты на SECC цикгычвское считывание показаний прибора учета на SECC прекращается и их не требуется посылать третьей стороне. Таким образом, отсутствует необходимость в последующей подписи данных, относящихся к расчету.

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

7.7.3.3 Применение безопасности транспортного уровня

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

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

Примечание 1 — Не предусматривается, что EVCC запрашивает ответ OCSP для листового сертификата SECC во время подтверждения TLS.

«Режим сопряжения» поддерживает простое управление сертификатами в частной среде [см. С.2 (приложение С)].

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

Примечание 2 — «Режим сопряжения» может быть повторно активирован в любое время.

Примечание 3 — Изготовителю предлагается пояснить использование и риски «режима сопряжения», например, в руководстве пользователя.

[V2G2-649] SECC должен обновлять (помещать в кэш) ответ OCSP не реже чем раз в неделю.

Одним из решений для обновления может быть, например, онлайновое соединение.

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

Примечание 4 — Это увязывается со сроком действия листового сертификата SECC.

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

Примечание 5 — Обработка ошибок не рассматривается в настоящем стандарте. Обработка таких ошибок осуществляется по усмотрению изготовителя.

[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.

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

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

(V2G2-924] Если SECC выдал цепочку сертификатов, которая не прослеживается до корневого сертификата в списке надежных сертификатов. EVCC должен принять такой сертификат. только если он выполнил успешную валидацию цепочки сертификатов с помо-

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

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

Примечание 7 — Это поддерживает «режим сопряжения».

[V2G2-873] Если EVCC запросил ответ OCSP через «client hello» TLS и сервер TLS не отправил ответы OCSP в «server hello», EVCC должен выполнить следующее:

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

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

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

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

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

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

7.7.3.4 Удостоверения транспортного уровня и наборы шифров безопасности

Для безопасности транспортного уровня EVCC аутентифицирует SECC с использованием серти

фиката SECC. Это достигается вследствие наличия у SECC закрытого ключа, который соответствует сертификату SECC, наличия у EVCC корневого сертификата V2G и проверки цепочки сертификатов от корневого сертификата V2G до сертификата SECC. Проверка действительности сертификата Sub-CA в цепочке сертификатов осуществляется через ответ OCSP. получаемый во время подтверждения TLS (подробности см. в /36/). Механизмы отзыва сертификатов SECC не требуются, но вместо этого требуются краткосрочные сертификаты.

SECC неизвестно, какой корневой сертификат V2G имеет EVCC из 10 действительных в настоящее время корневых сертификатов V2G для одного региона. Отсюда наличие 50 действительных в настоящее время корневых сертификатов V2G для всего мира. Поэтому необходимо, чтобы EVCC предоставил список корневых сертификатов V2G. которые он имеет, посредством подтверждения TLS. SECC выдает цепочку своего собственного сертификата SECC. корневой сертификат которого передается EVCC вместе с ответом OCSP для сертификатов Sub-CA в цепочке. Настоятельно рекомендуется обновлять ответ OCSP не реже чем раз в неделю.

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

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

Таблица 6 — Аутентификация TLS

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

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

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

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

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

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

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

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

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

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

Дополнительные наборы шифров могут поддерживаться любым субъектом V2G.

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

Таблица 7 — Поддерживаемые наборы шифров

Набор шифров

RFC

TLS ECDH ECDSA WITH AES 128 CBC SHA256

138)

TLS ECDHE ECDSA WITH AES 128 CBC SHA256

138)

7.8 Коммуникационный протокол V2G

7.8.1 Общая информация

Коммуникационный протокол V2G (V2GTP) является компактным протоколом связи для передачи сообщений V2G между двумя субъектами V2GTP. Он в основном состоит из определения заголовка и полезных данных, что позволяет разделять и эффективно обрабатывать сообщения V2G. V2GTP является стандартным коммуникационным протоколом между EVCC и SECC. но может быть также ис-пользован для связи с другими субъектами V2G. которые поддерживают протокол V2GTP.

7.8.2 Поддерживаемые порты

V2GTP базируется на TLS+TCP. которые используют пару IP-адресов (адрес-источник и адрес назначения) и пару номеров портов (порт-источник и порт назначения) для установления и идентификации соединения. Соединение устанавливается от адреса-источника и порта-источника к адресу назначения и порту назначения. Порты, перечисленные в таблице 8. используются субъектами V2GTP. Таблица 8 — Поддерживаемые порты TLS для V2GTP

Имя

Протокол

Номер порта

Описание

V2G_SRC_TCP_DATA

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

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

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

V2G_DST_TC P.DATA

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

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

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

Для субъектов V2GTP, реализующих V2GTP, действуют следующие общие требования: [V2G2-073] Субъект V2GTP, предоставляющий порт назначения, должен поддерживать не ме

нее одного соединения на локальном порте V2G_DST_TCP_DATA. как указано е таблице 8.

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

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

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

Для EVCC и SECC особо действуют следующие требования:

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

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

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

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

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

7.8.3 Блок протокольных данных

7.8.3.1 Структура POU V2GTP

POU V2GTP состоит из заголовка и основной части, или тепа, как показано на рисунке 8.

Заголовок

Полезные данные

(8 байт)

(0-4294967295 байт)

Рисунок 8 — Структура сообщения V2GTP

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

Структура заголовка сообщения V2GTP показана на рисунке 9 и описана в таблице 9. Поддерживаемые типы полезных данных описаны в таблице 10.

N» байта

Попе

заголовка

1

2

3

4

5

6

7

8

Версия

протокола

Обратная

версия

протокола

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

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

Рисунок 9 — Структура заголовка сообщения V2GTP

[V2G2-082) Субъект V2GTP должен использовать структуру заголовка, показанную на рисунке 9. [V2G2-083] Субъект V2GTP должен отправить 8 байтов заголовка V2GTP в порядке, показанном

на рисунке 9.

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

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

Таблица 9 — Типовая структура заголовка V2GTP

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

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

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

Версия

протоколе

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

0x01:

V2GTP версия 1

0x00, 0x02-0xFF:

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

документом

Обратная

версия

протокола

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

Эквивалентно функции: <Protocol Versxxr> XOR OxFF

OxFE: V2GTP версия 1

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

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

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

Длина полезных

данных

(GH.PL)

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

0...4294967296 (= <d>)

Таблица 10 — Обзор типов полезных данных V2GTP

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

Иыя шла полезных данных

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

0x0000

0x8000

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

Неприменимо

0x8001

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

7.9.1.2

0x8002

0X8FFF

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

Неприменимо

0x9000

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

7.10.1.4

0x9001

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

7.10.1.5

0x9002

0X9FFF

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

Неприменимо

ОхАООО

OxFFFF

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

Неприменимо

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

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

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

Примечание — Из требования [V2G2-088] вытекает, что попе полезных данных не может включать ни часть сообщения, ни несколько сообщений.

7.8.3.2 Обработка заголовка

Для обработки полезных данных субъект V2GTP должен сначала обработать заголовок. Для этого субъект V2GTP. получивший сообщение V2GTP. проверяет поле заголовка шаг за шагом. Описанная ниже обработка заголовка проиллюстрирована на рисунке 10.

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

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

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

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

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

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

Нвшло лроирм авголмм

О

fltBMWO ямм ведом н обратной версия

р2в2МВД

Лроотровтяпв полом ыж донных

СЛО2-0ВЯ

Провал* ело ми соовийт

[V2Qz-oeeq

Остаимкя фовврт млтюол Рисунок 10—Обрвбопв типового «голмл V2GTF

7.9 Представительский уровень

7.9.1 XML и эффективный XML-обмен (EXI)

7.9.1.1 Обзор

Для описания набора сообщений V2G представительский уровень использует широко применяемое XML представление данных. 8 настоящем стандарте описаны сообщения (т. е. структуры данных и типы данных) на основе XML-схемы, что позволяет использовать XML с учетом типов и обеспечивает упрощенную оценку действительности сообщений, которые являются объектом обмена.

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

7.9.1.2 Эффективный XML-обмен

Формат эффективного XML-обмена (EXI) позволяет использовать и обрабатывать сообщения на базе XML на уровне двоичных кодов. Таким образом, формат EXI увеличивает скорость обработки данных на базе XML. а также сокращает использование памяти. EXI является рекомендацией W3C. Формат EXI использует для кодирования относительно простой подход на основе грамматики, обеспечивающий очень эффективное кодирование для широкого ряда случаев применения. Нередко EXI-сообщения бывают до 100 раз меньше, чем эквивалентные XML-докумвнгы. Спецификация EXI описывает с помощью предопределенного процесса, как информация схемы должна трансформироваться в грамматику EXI. Основанием для этого является то. что грамматику ЕХ1 гораздо легче обрабатывать по сравнению с информацией XML-схемы. При этом грамматический раэбор может быть осуществлен так же точно, как и в XML.

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

EXI-потоки могут быть созданы очень эффективным способом, если вся кодированная информация (элементы/атрибуты) определена XML-схемой. Информация с отклонениями на основе знания XML-схемы кодируется более общим способом. Кодер EXI кодирует классифицированные имена (область имен и имя элемента/атрибута) неизвестной информации на базе операций со строками. Однако простые типы отклонений схемы могут по-прежнему кодироваться с учетом типа.

Декодеры EXI способны декодировать эффективные EXI-потоки, используя ту же лежащую в основе XML-схему, которая была использована для процесса кодирования. Отклонения от схемы определяются в потоке EXI. Данные отклонения (неизвестные элементы или атрибуты) могут быть обработаны или пропущены.

На рисунке 11 обобщается концепция эффективного XML-обмена для домена. Вследствие больших ограничений, связанных с лимитом ресурсов. EVCC может быть способен только обрабатывать данные на базе XML используя соответствующее представление структуры данных. Тахие структуры данных могут быть использованы для оереалиэации или десвреализации сообщений приложения. При этом SECC может быть способен обрабатывать данные как структуру данных и/или как требующую более интенсивной работы ресуроов объектную модель документов (ОМД) или как традиционный вариант простого текста XML

Совместно используемые значения

XML-cxeua

Рисунок 11 — Применение базовой концепции EXI к связи V2G

7.9.1.3 Настройки EXI для сообщений прикладного уровня Следующие настройки EXI используются для связи V2G на базе EXI:

[V2G2-098] XML-схема с областью имен «um:iso:15118:2:2013:msgDef», которая представляет собой версию ISO 15118 2.0 (основной номер версии «2». дополнительный — «0»), должна использоваться для кодирования и декодирования ЕХЬлотоков.

[V2G2-099J EXI-кодер для кодирования и декодирования коммуникации в соответствии с [1].

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

Таблице 11 — Настройки опций EXI

Опция EXI

Описание

Значение

гос г р (исо г s j та- >

vaJueParttionCapacity

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

0

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

[У2С2-101)Элемект/атрибут. который не олределене области имен «um:iso:15118:2:2013:msgDef», должен кодироваться и декодироваться как случай отклонения схемы в соответствии с (40}(пункт «Adding Productions wtien Strict is False»).

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

Примечание — Дополнительное описание профиля EXI см. в (42).

Таблица 12 — Настройки профиля EXI

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

Описание

Значение по ГОСТ Р S6t22 (ИСО)5})д-}.20)3)

maximumNumberOfBuiltlnElementGrammars

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

0

maximumNumberOfBuiltlnProductions

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

0

[V2G2-102] Простой тип/эначение элемента/атрибута. который не определен в области имен «urn:iso:15118:2:2013:msgDef». должен кодироваться и декодироваться с учетом типа.

7.9.2 Безопасность сообщений

7.9.2.1 Обзор

XML-лодпись является рекомендацией [41). которая направлена на удовлетворение требований аутентичности некоторых фрагментов данных (например, информация об учете) V2G на базе XML. XML-лодпись определяет механизм, с помощью которого сообщения и части сообщений могут быть подписаны цифровой подписью для проведения аутентификации, обеспечения сохранности, исключения искажений. Для защиты конфиденциальности применяется схема гибридного шифрования на базе протокола Диффи — Хеллмана.

7.9.2.2 Удостоверения и наборы шифров безопасности прикладного уровня

Удостоверения, применяемые на уровне приложения, должны быть нацелены на безопасность

XML. XML-подпись выбрана для защиты информации, относящейся к расчетам между EVCC. SECC и/или SA. Двоичное шифрование обеспечивает способ предоставления закрытого ключа EVCC с защитой конфиденциальности и без доступа посредников к данному закрытому ключу. Оба подхода требуют ассиметричного материала ключей. Удостоверения для подписания EVCC обеспечиваются сертификатом контракта, удостоверения для получения EVCC зашифрованных данных обеспечиваются обменом ключей ECDH. как описано в приложении О.

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

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

Примечание 1 — Пояснения относительно срока действия сертификата см. в С.1 (приложение С).

Примечание 2 — Если сертификат не используется для зарядки, он может быть использован для сервиса. Сервисный сертификат изготовителя позволяет EVCC запросить действительный сертификат контракта для режима РпС.

Примечание 3 — Закрытые ключи сертификата контракта и сервисного сертификата изготовителя являются денными, требующими защиты. После того как закрытый ключ взломан, ему нельзя больше доверять и поэтому им больше нельзя пользоваться. Если один из этих закрытых ключей может быть прочтен злоумышленником, то злоумышленник может выдать себя за исходный EVCC и получить электроэнергию за счет настоящего владельца транспортного средства. В качестве контрмеры EVCC гложет применить дополнительную защиту указанных ключей. Это может варьироваться от простых мер безопасности, таких как настройка предохранигегъных битое защиты от считывания в микроконтроллере EVCC. до более продвинутой защиты за счет средств защищенной загрузки, защиты при доступе для отладки и встроенных аппаратных модулей безопасности (АМБ). Последние обеспечивают высокий уровень безопасности, включая защиту против физических атак. Надлежащий АМБ обеспечивает безопасную среду для операций с закрытым ключом. Он предлагает интерфейсам использовать закрытый ключ, но обеспечивает невозможность считывания или манипулирования кгьочом даже для программы, которая работает s EVCC. Специализированный АМБ может даже допускать ввод зашифрованного закрытого ключа сертификата контракта с тем. чтобы закрытый ключ никогда не был доступен вне АМБ в простой незашифрованной форме. Такой АМБ может быть интегрирован в EVCC как отдельный физический модуль или как расширение кристалла микроконтроллера.

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

7.9.2.3 Сертификаты контракта как удостоверения XML-подписи

Сертификат контракта привязан к EMAID и используется в XML-подписи для авторизации зарядки транспортного средства. Сертификат контракта может быть проверен, даже если SECC находится в режиме офлайн. Связывание контракта осуществляется следующим образом:

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

7.3.2.4 Специфика безопасности XML для набора(ое) сообщений РпС

7.9.2.4.1 Структуры XML-данных для безопасности прикладного уровня

Безопасность на уровне приложения обеспечивается с помощью подписи и шифрования сообщений. Обмен информацией, предназначаемой для сервисов SA. осуществляется с использованием структур данных XML. Поэтому эта информация может быть целиком защищена с помощью средств безопасности XML.

Типичная информация, которой обмениваются EVCC и SECC, это согласование подписанных показаний прибора учета от транспортного средства, используемых для онлайновых и полуонлай-новых соединений. Показания прибора учета от SECC отправляются через защищенный канал TLS. Они могут включать подпись счетчика электроэнергии, обеспечивающую аутентификацию источника для дополнительной защиты. Транспортное средство, в свою очередь, подписывает показания прибора учета для поддержки процесса расчета, если местные правила это допускают. Такой подход позволяет экономить подписи показаний прибора учета со стороны SECC. Показания прибора учета накапливаются, поэтому самое последнее показание прибора учета служит основой для расчета. Используются XML-подписи. которые обеспечивают защиту сохранности информации. давая возможность всем промежуточным и участвующим субъектам полагаться на эту информацию.

7.Э.2.4.2 Механизм XML-подписи

В данном пункте описан механизм XML-подписи.

Примечание 1 — Обзор XML-подписейсм. также в приложении Е.

XML-подписи, которые соответствуют синтаксису и версии обработки 1.1 XML-подписи {41}. могут быть применены к произвольному цифровому содержанию (объектам данных) так же. как и при расчете цифровых подписей. При применении цифровой подписи к объектам данных они сначала обрабатываются (хешируются), и результат затем подписывается с помощью асимметричного алгоритма, такого как RSA (алгоритм цифровой подписи Ривеста — Шамира — Адельмана) или ECOSA. В случае XML свертка помещается в XML-элемент вместе с дополнительной информацией. Этот элемент затем хешируется и криптографически подписывается. В настоящем стандарте используются обособленные XML-подписи. которые соответствуют синтаксису и версии обработки 1.1 XML-подписи (см. {41}). Это означает, что подпись и данные могут быть в отдельном (внешне обособленные) или в одном и том же XML-документе (внутренне обособленные) как родственные элементы одного уровня. Подпись может охватывать только часть XML-документа, на который ссылается ObjectID.

На рисунке 12 показана диаграмма схемы элемента XML-подписи. включенного в заголовок сообщения V2G.

dtSignalureType

■— Щ attributes

— г— pdaiSignBcHfifo ф-г


ds^ignedlnfoTyp» !— Oetotoutes

I— ^d»£at>onlc«ta«tk>nM>thod ф

^d»£lgn«tur»MBthod^


>— авЛГвгвпе*

f —**


1..«


— »d«:S>flnaturtV«lu» ф "diiiyinfo Э

О.а

Рисунок 12 —Диаграмма — XML-подпись

На рисунке 13 показана диаграмма элемента Reference, включенного в элемент Signedlnfo. который является частью XML-подписи, показанной на рисунке 12.

с(вЯ»Гвг«псвТур»

Рисунок 13 — Диаграмма — Элемент Reference, включенный в элемент Signedlnfo


dcTransform* Q »d»:Plfl4tMathod ф — ^da^OgeetValueJ

Примечание 2 — Значения прибора учета от SECC могут быть уже подписанными. Это значение подписи рассматривается как информационный элемент и требуется для процесса измерений. Подпись может также включать идентификатор прибора учета.

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

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

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

[V2G2-765] Каждое сообщение, требующее структуры XML-подписи. должно использовать значение «http://www.w3.org/TR/canonical-exi/» в качестве атрибута алгоритма в элементе Canon icalizationMethod.

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

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

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

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

(V2G2-770) Каждое сообщение, требующее структуры XML-подписи. должно использовать значение «http://www.w3.Org/2001/04/xmtenc#sha256» в качестве атрибута алгоритма в элементе DigestMethod.

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

- Id (attribute in Signedlnfo);

« ##any in Signedlnfo — CanonicalizationMethod:

- HMACOutputLength in Signedlnfo — SignatureMethod;

- ##other in Signedlnfo — SignatureMethod;

« Type (attribute in Signedlnfo-Reference):

• ##other in Signedlnfo — Reference — Transforms — Transform;

- XPath in Signedlnfo — Reference — Transforms — Transform;

- ##other in Signedlnfo — Reference — DigestMethod:

- Id (attribute in SignatureValue);

- Object (in Signature):

• Keylnfo.

[V2G2-909J Подпись не должна относиться к более чем четырем подписываемым элементам. Примечание 3 — Это позволяет определить верхнюю границу для размера заголовка подписи.

Для применения XMLDstg любой элемент, который должен быть подписан, должен быть адресуемым. В настоящем стандарте это обеспечивается ссылкой универсального индикатора ресурсов (URI) на идентификационный атрибут такого элемента. Таким образом, любой подписанный элемент сообщения несет идентификационный атрибут. Если конкретный элемент должен подписываться во всех случаях использования, то идентификационный атрибут обязательно помечается в XSD. Однако если он подписывается только в некоторых случаях использования, то идентификационный атрибут помечается как факультативный и может быть опущен, когда он не требуется.

Примечание 4 — Присутствие идентификационного атрибута не обязательно означает, что подпись используется. т. е. если подпись не используется, идентификатор может тем не менее присутствовать.

7.9.2.4.3 Механизм шифрования

Закрытые ключи, принадлежащие сертификатам контрактов, требуют защиты (т. е. шифрования) при передаче от SAk EVCC. Более подробные пояснения приведены в приложении D.

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

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

[V2G2-814] Закрытый ключ, соответствующий сертификату контракта, должен передаваться только в зашифрованном формате в сообщениях CertificatelnstallationRes и CertificatellpdateRes — в составе ContractSignatureEncryptedPrivateKey.

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

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

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

Примечание 2 — Поскольку используется ECOSA с кривой secp256r1. закрытый ключ имеет длину 256 бит.

Примечание 3 — Дополнение нешифрованного текста (закрытый ключ) не требуется, поскольку его длина кратна размеру блока используемого алгоритма шифрования.

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

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

Примечание 4 —Аутентичность передачи обеспечивается окружающей подписью. Проверка аутентичности обязательна для безопасности протокола ECDH.

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

Примечание 5 — XML-эпеменг oDHpubhckey* имеег длину 65 байтов. Первый байг имеет фиксированное значение 0x04. что указывает на несжатую форму.

[V2G2-820] в сообщении CertificatelnstallatronRes открытый ключ получателя QV должен быть открытым ключом, содержащимся в существующем сервисном сертификате изготовителя.

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

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

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

7.9.2.4.4 Генерирование случайных чисел

Алгоритм ECDSA в большей степени полагается на тот факт, что злоумышленник не имеет информации о случайном числе. В противном случае подписи будут допускать утечку информации о секретном ключе. Несовершенство реализации генератора случайных чисел может позволить злоумышленнику извлечь секретный ключ после прочтения определенного числа подписей. В худшем случае простое повторное использование случайного числа позволит злоумышленнику рассчитать закрытый ключ после прочтения только двух подписей. Поэтому чрезвычайно важно иметь надлежащий генератор случайных чисел (ГСЧ), так называемый криптографически безопасный ГСЧ. Кроме того, криптографически безопасный ГСЧ необходим для генерирования вектора инициализации в AES-CBC и для генерирования вызова.

[V2G2-835] Каждый раз. когда в настоящем стандарте субъект V2G требует случайных чисел.

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

Примечание — В реализации может присутствовать подходящий криптографически безопасный генератор случайных '«сел. Поскольку фактическая реализация не влияет на функциональную совместимость, настоящий стандарт не предписывает конкретных мер. чтобы соответствовать требованиям завтрашнего дня и избежать дублирования. Однахо установленные стандарты должны соблюдаться, например {46] vi (47).

7.3.2.4.5 Применение механизмов безопасности к XML-сообщению

Поддерживаются две пары механизмов безопасности:

- аутентичность и сохранность: Генерирование подписи. Проверка подписи.

Применяется подпись на базе XML. Субъект, который создает XML-сообщение. подписывает определенные или все поля XML-сообщения. Получатель проверяет подпись:

- конфиденциальность: Шифрование. Дешифрование.

Применяется асимметричное шифрование. Субъект, который создает сообщение, шифрует единое двоичное поле XML-сообщения. Получатель расшифровывает это двоичное поле.

В таблицах 13 и 14 дается обзор применяемых механизмов безопасности.

Таблица 13 — Обзор применяемых подписей на основе XML

XML-сообщение

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

Подписывающий

субъект

(отравитель)

Проверяющий

субъект

(получатель)

AuthonzationReq

Тело сообщенияГВсе поля {если присутствует GenChaftenge)

EVCC

SECC

CertificateUpdateReq

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

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

Вторичный

субъект

Окончание таблицы 13

XML-сообщение

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

Подписывающий

субъект

(отравитель)

Проверяющий

субъект

(получатель)

CertificateUpdateRes

ContractSignatureCertChain

ContractSignatureEncryptedPrivateKey

DHpuWckey

eMAID

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

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

CertificatelnstallabonReq

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

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

Вторичный

субъект

CertificatelnstallabonRes

ContractSignatureCertChain

ContradSignatureEncryptedPrivateKey

DHpuWickey

Contr acUO

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

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

MetenngReceiptReq

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

EVCC

SECC

ChargeParameterDiscoveryRes

SaiesTariff (допогыительно. требуется для РпС)

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

EVCC

Таблица 14 — Обэор шифрования на уровне приложения

XML-сообщение

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

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

Дешифрующий

субъект

(получатель)

CertificateUpdateRes

Contr acts ignatureEncryptedPrivateKey

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

EVCC

CertificatetnstallalionRes

ContractSignatureEncryptedPrivateKey

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

EVCC

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

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

7.Э.2.5 Выдача сертификатов

Оператор услуг для EV создает удостоверения для EVCC, состоящие из сертификата кон* тракта, закрытого ключа, который был асимметрично зашифрован специально для данного EVCC. Затем оператор услуг для EV направляет удостоверения службе выдачи сертификатов. Сервис выдачи сертификатов подтверждает корректность и аутентичность удостоверений своей подписью и передает подписанный фрагмент сообщения SECC, который составляет сообщение CertificatelnstallationRes или CertificateUpdateRes и передает его EVCC. Служба выдачи сертифи* катов считается надежной, поэтому не требуется, чтобы EVCC был способен проверять сертификат. который он получил.

На рисунке 14 приведен процесс для CertificatelnstallationRes и CertificateUpdateRes.

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

Рисунок 14 — Процесс для CerhftcatetnstallalionRss и CertificateUpdateRes

7.10 Уровень приложения

7.10.1 Протокол обнаружения SECC

7.10.1.1 Общая информация

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

После того как EVCC получил IP-адрес и номер порта SECC, он может установить соединение транспортного уровня с SECC (см. 7.3.4).

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

Примечание — Как эго часто встречается в интернет-технологиях, сервер SOP может быть реализован на одном физическом устройстве с SECC и может быть связанным с тем же самым IP-адрвоом. Если это не тот случай, то оптимистическое определение дублирования адресов, описанное в /T9/, не приведет к преимуществам.

7.10.1.2 Поддерживаемые порты

SOP — это протокол на основе UDP. Порты, перечисленные в таблице 15. используются SDP.

Таблица 15 — Поддерживаемые порты UDP для SDP

Имя

Протокол

Номер порта

Описание

V2G_UDP_SDP_CUENT

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

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

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

V2G_UDP_SDP_SERVER

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

По ГОСТ Р 58123

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

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

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

Примечание — ВзависимостиотреализацииЕУССдинамичесп1ЮЭначэеыыйпорт726_иОР_80Р_СиЕМТ будет назначен однажды во время или перед первой передачей пакета UDP SECC или может быть динамически переназначен для каждого индивидуального сообщения-запроса UDP и ответа. Также в зависимости от того, посылаются ли сообщения повторно, сообщения-ответы могут приходить асинхронно и уже не могут быть ассоциированы с конкретным соответствующим запросом.

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

7.10.1.3 Блок протокольных данных

7.10.1.3.1 Структура

Сообщение SDP базируется на формате сообщения V2GTP. как указано е 7.8.3.1.

[V2G2-127] Клиент SOP должен поддерживать определения 7.8.3.1.

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

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

(V2G2-130} Сервер SDP должен поддерживать определения 7.8.3.1.

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

[V2G2-1321 Сервер SDP должен поместить первый байт заголовка сообщения-ответа, показанно

го на рисунке 9 и в таблице 9. в первом байте полезных данных пакета UDP.

7.10.1.3.2 Обработка заголовка

Обработка заголовка SDP базируется на обработке заголовка сообщения V2GTP. как указано в 7.8.3.2.

[V2G2-1331 Клиент SOP должен применяться для обработки заголовка, как указано в 7.8.3.2. [V2G2-134} Сервер SDP должен применяться для обработки заголовка, как указано в 7.8.3.2.

7.10.1.4 Сообщение-запрос об обнаружении SECC

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

[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-140J Клиент SOP должен отправлять сообщение-запрос об обнаружении SECC со значением 0x9000 типа полезных данных, как указано в таблице 10.

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

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

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

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

Byte No.

1

2

Рисунок 15 — Полезные данные сообщения-запроса об обнаружении SECC

Таблица 16 — Кодирование безопасности SDP и опций протокола

Описание

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

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

№ байга сообщения-запроса SOP

1

2

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

19

20

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

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

OxOI-OxOF = зарезервировано

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

0x00= TCP

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

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

7.10.1.5 Сообщение-ответ об обнаружении SECC

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

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

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

Примечание 1 — Эго требование обеспечивает возможность доступа к серверу SDP. обслуживающему несколько кгыентав. в любое время. Это поддерживает зарядку нескольких EV на EVSE одним SECC.

[V2G2-145) Клиент SOP не должен отвечать на любое сообщение-запрос об обнаружении SECC. (V2G2-146) Сервер SDP должен отправлять сообщения-ответы только после получения сообще

ния с запросом об обнаружении SECC.

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

Примечание 2 — Подробные требования по хронированию см. в требованиях (V2G2-159J—[V2G2-162]

[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) Сервер SOP должен отправлять сообщение-ответ об обнаружении SECC с полезными данными, показанными на рисунке 16.

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

[V2G2-156] Сереер SOP должен отправлять поля «SECC IP Address» и «SECC Port» в формате с обратным порядком следования байтов: старший байт передается первым, младший байт — последним.

Примечание 3 — Механизм, используемый сервером SDP для определения своего собственного IP-адреса, не рассматривается в настоящем стандарте.

Примечание 4 — IP-адрес источника и порт источника полученного пакета UDP обычно предоставляются стеком TCP/IP

12 3 4 6


Byte No.


6 7 8

В 1w[ 111 1Я[ 131141 1б| 1б| 171 1б| 181 20

8ЕСС1РАМлмв

SECC

Port

l

Рисунок 16 — Полезные данные сообщения об обнаружении SECC

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

7.10.1.6 Хронирование и обработка ошибок

Процесс обнаружения SECC основан на определениях тайм-аута из приложения, как описано в 7.10.1. В этом пункте описываются дополнительное хронирование и обработка ошибок для протокола обнаружения SECC.

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

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

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

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

[V2G2-161} Если клиент БОРне получил никакого сообщения-ответа об обнаружении SECC после последовательного отправления максимум 50 сообщений-запросов об обнаружении SECC, он должен остановить обнаружение SECC.

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

7.10.1.7 Протокол и обработка опций безопасности

Для обработки запросов и ответов SOP клиент SDP и сервер SDP должны выполнять следующие требования:

[V2G2-625] Если клиент SOP отправляет запрос SOP с кодом опции протокола для TCP («ТСР» в таблице 16). SECC должен отправить ответ SDP с кодом опции протокола «ТСР».

[V2G2-626] Если клиент SDP отправляет запрос SDP с кодом опции безопасности для TLS («защищено TLS» в таблице 16) и SECC поддерживает TLS. сервер SOP должен отправить ответ SOP с кедом опции безопасности «TLS».

[V2G2-627) Если клиент SDP отправляет запрос SDP с кодом опции безопасности для TLS («защищено TLS» в таблице 16) и SECC не поддерживает TLS. сервер SDP должен отправить ответ SDPc кодом опции отсутствия безопасности «Нет безопасности транспортного уровня».

Для установления TCP/TLS действуют следующие требования:

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

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

[V2G2-163] Если SOP выдает глобальный 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.

7.10.2 Сообщения прикладного уровня V2G

Определения сообщений взаимодействия транспортного средства с электросетью на уровне приложения описывают обмен сообщениями типа клиент — сервер между EVCC и SECC с целью инициализации и конфигурирования процесса зарядки EV. Этот набор сообщений предназначен для случаев использования, которые описаны в ГОСТ Р 58122 (ИСО 15118-1). Сообщения и необходимый поток сообщений {т. е. протокол связи) представляют собой прикладной уровень в соответствии с моделью уровневой архитектуры OSI.

Набор сообщений, поток сообщений и поведение, характерное для конкретных сообщений, описаны в разделе 8.

7.10.3 Сервисные примитивы прикладного уровня

7.10.3.1 A-Data.request

А-Data.request объявляет действия по обмену сообщениями V2G. В таблице 17 описываются сервисный примитив и его параметр(ы).

Таблица 17 — Сервисный примитив A-Data.request

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

A-Data.request

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

EVCC

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

Описание

A_Msg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Запрос тока

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

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

A-Data.request (A_msg = «message name») запрашивает более низкий уровень для отправления сообщения-запроса V2G типа сообщения V2G, который задается параметром A_msg.

Пример — A-Data.request (A_msg = Session Setup) инициирует отправление сообщения SessionSetupReq. как указано в 8.4 3.2.1.

7.10.3.2 A-Data.indication

А-Data.indication объявляет действия по обмену сообщениями V2G. В таблице 18 описываются сервисный примитив и его параметр(ы).

Таблица 18 — Сервисный примитив A-Data.indication

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

A-Data.indicabon

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

SECC

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

Описание

A_Msg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Запрос тока

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

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

А-Data.indication (A_msg = «message name») указывает на получение сообщения-запроса V2G типа сообщения V2G. который задан верхнему уровню параметром A_msg.

Пример — A-Data.indication (Ajmsg - Session Setup) инициирует получение сообщения SesstionSetupReq, как указано е 8.4.3.2.1.

7.10.3.3 А-Data. response

А-Data.response уведомляет о статусе обмена сообщениями V2G. В таблице 19 описываются сервисный примитив и его параметр(ы).

Таблица 19 — Сервисный примитив А-Data. response

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

A-Data.response

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

SECC

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

Описание

A_msg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Запрос тока

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

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

А-Data.response (A_msg = «message name») указывает нижнему уровню на необходимость отправления сообщения-ответа V2G с типом сообщения V2G. который задан параметром A_msg.

Пример — A-Data.response (A_msg = Session Setup) инициирует отправление сообщения SesstionSetupRes. как указано в 8.4.3.2.2.

7.10.3.4 A-Data.confirmation

А-Data.confirmation уведомляет о статусе обмена сообщениями V2G. В таблице 20 описываются сервисный примитив и его параметр(ы).

Таблица 20 — Сервисный примитив A-Oata .confirmation

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

A-Data.confirmation

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

EVCC

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

Описание

A_msg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Запрос тока

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

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

A-Data.confirmation (A_msg = «message лате») указывает на успешное получение сообщения-ответа для сообщения V2G. которое дано верхнему уровню параметром A_msg.

Пример—A-Data.confirmation (A_msg - Session Setup) указывает на успешное получение сообщения SessionSetupRes, как указано в 8.4.3.2.2.

8 Сообщения прикладного уровня

8.1 Общая информация и определения

Сообщение V2G использует представительский уровень на базе EXI, как описано в 7.9.1. Коммуникация между EVCC и SECC на прикладном уровне основана на архитектуре клиент/сервер. EVCC всегда выступает в качестве клиента (запрашивающего сервис) во время всего процесса зарядки. в то время как SECC всегда выступает в качестве обслуживающего устройства (отвечающего на запрос о сервисе). Поэтому EVCC всегда инициирует связь путем отправления сообщения-запроса SECC, который затем возвращает соответствующее сообщение-ответ. Все сообщения, обмен которыми происходит между EVCC и SECC, описываются их синтаксисом и их семантикой в 8.2. 8.3 и 8.5. Полное определение XML-схемы. описывающее оба набора сообщений V2G. содержится в приложении F.

В 8.6 описываются сообщение V2G и соответствующие элементы сообщений, поддержка которых требуется для определенного набора элементов случаев использования, приведенных в ГОСТ 58122 (15118-1:2013).

В 8.7 описываются хронирование сообщений и обработка ошибок для обмена сообщениями V2G. Примеры типичных последовательностей сообщений даны в 8.8.

Коммуникация V2G состоит из двух разных наборов сообщений:

- сообщения подтверждения протокола V2G на уровне приложения (см. 8.2):

- сообщения V2G на уровне приложения (см. 8.3).

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

8.2 Определение подтверждения протокола

8.2.1 Последовательность подтверждения

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

Для согласования протокола между EVCC и SECC осуществляется следующее подтверждение протокола прикладного уровня:

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

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

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

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

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

Примечание — Болев высокое значение VersionNumberMinor указывает на то. что (по сравнению с меньшим значением) дополнительные элементы данных будут передаваться либо от EVCC. либо от SECC. Реализации, поддерживающие только более низкое значение VersionNumberMinor. могут быть не способны обрабатывать данные и могут быть вынуждены их игнорировать, однако разница значения VersionNumberMinor между EVCC и SECC не приводит к несовместимости. См. 8.2.4 с примерами успешного согласования протокола.

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

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

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

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

8.2.2 Определение сообщения supportedAppProtocolReq и supportedAppProtocolRes [V2G2-175] EVCC и SECC должны реализовывать сообщение и элементы сообщения V2G. как

показано на рисунке 17.

AppProtoeolType

—|~ProtocolNim»ip»ce | — "VertlonNumberMijor |

eupportedAppProtocolReq AppProtocol --“VerelonNumberMlnor |

— "SchemalD

— “Priority |

Рисунок 17 — Диаграмма — supportedAppProtocolReq

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

"FteeponaeCode

supportedAppProtocolRaa

SchemalD

Рисунок 18 — Диаграмма — supportedAppProtocolRes

8.2.3 Описание семантики сообщений supportedAppProtocol

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

Таблица 21 — Семантика и определение типа для элементов сообщения supportedAppProtocolReq

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

Тип

Семантика

AppProtocol

comptexType:

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

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

ProtocotNamespace

simpleType:

protocotNamespaceType цепочка (макс, дшна: 100) см. определение типа в F.2 (приложение F)

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

VersionNumberMajor

simpleType: unsignedlnt см. определение типа в F.2 (приложение F)

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

VersionNumberMinor

simpleType: unsignedlnt см. определение типа в F.2 (приложение F)

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

SchemalD

simpleType: unstgnedByte см. определение типа в F.2 (приложение F)

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

Окончание таблицы 21

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

Тип

Сеыаитим

Priority

simpleType: priorityType unsignedByte {диапазон 1 ..20) см. определение типа F.2 (приложение F)

type definition

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

Таблица 22 — Семантика и определение типа для элементов сообщения supporledAppProtocolRes

Имя элсмснта|'пр»:жака

Тип

Семантика

ScftemalD

simpleType: unsignedByte см. определение типа в F.2 (приложение F)

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

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

ResponseCode

simpleType:

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

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

8.2.4 Примеры сообщений

8.2.4.1 Приоригизация протоколов

Примеры 1 и 2 сообщения V2G иллюстрируют обмен сообщениями supportedAppProtocol между EVCC и SECC. В сообщении-запросе EVCC посылает SECC список поддерживаемых протоколов на уровне приложения с обозначенным приоритетом (ИСО 15118:2:2013 версия 2.0, ИСО 15118:2:2010 версия 1.0). где первый протокол имеет наивысший приоритет. В ответном сообщении SECC подтверждает протокол ИСО 15118:2:2013 версия 2.0 с использованием ResponseCode. равного OK_SuccessfulNegotiation, и SchemalD, равного десяти (10).

vertion«'l СГ encotf*ig»"UTF.e*’>

<n1.supponedAppP(OtocolResKsi.«heinaLocabon>"uml« 1511B2 20lOAppProlocol ./V2G_CI_Appf>rotMolj»d* xmins.n1«'um ао:15118 2 2010 AppProtocof xmin$:xsi»TMp/Avww.w3 org/2001/XMLScftema-irtsttnce*>

<AppPrott»col>

<ProtocoMam»spaoe>um:«o:l5tl8:2:2013:MsgDet<<ProtixolNemesp3ce>

<Vefs*3nNumberM9»w>2<zvefs«onNumberMa|O<»

<Vers«nNumb»rMinor>0<'VewonNufnbeiMinor>

«SchemalDMCK-SchemalO»

<Pnorrty>t</Pr*y»ty>

<.'AppProtoco*>

<AppProtocol>

<ProtocolNamMp»c«>i>rn »ol5l»82 2O10kfcflDef<.Pro<ocolNamespaa3>

<V«fs>o<iNun*erMajor>1<A/«f*io<tNun*«rMajjr>

<Ve<*>onNun<)etM>noi>0<.lVenionNumbeiMin>r>

<SchemalD>20<rsaiemaIO>

<Pfttrtly>2<jPfiorty>

c.’AppPfOtOCOfc»

</nl suppo<tedAppProtoooiReq>

Пример 1 сообщения V2G — supportedAppProtocolReq: приоритизация протоколов

<Txml version*’! 0" encodi(*9»T/TF-8“>>

<n1 supportodAppPiotocolRes x# scTitmaLoc»!ioi«“um «15118 2 2010 AppPiotocol Л/20_С1_АррРго1осо1 x$d*

xmMenls'um «о:1511в2 20ЮАррРго4осоГ

xmhrs x$i='http //www wSorpttOOt/XMlSchema-instance’»

<ResponseCode»OK.Si»ccessftjlNe9Miation<jResp3nKCcdo -<SchemalO>10</SchemalD>

</n 1 supporiedAppProtoooiRes>

Пример 2 сообщения V2G — supportedAppProtoco/Res: приоритизация протоколов

8.2.4.2 Отклонение младшего номера версии

Примеры 3 и 4 сообщения V2G иллюстрируют обмен сообщениями supportedAppProtocol между EVCC и SECC. В сообщении-запросе EVCC посыпает SECC только один поддерживаемый про-4б

токол прикладного уровня {ИСО 15118:2:2013 версия 2.0). SECC поддерживает только версию 2.1 протокола. 8 сообщении-ответе SECC подтверждает протокол ИСО15118:2:2013 посредством VersionNumberMajor. равного двум (2), используя SchemalD. равный одному (1}. Однако ResponseCode равен OK_SuccessfutNegotiationWithMinorDeviation. что указывает на то. что имеет место отклонение младшего номера версии. EVCC может в таком случае ожидать элементов сообщений, которые неизвестны EVCC и могут быть проигнорированы.

<ТхяМ v»rsior>="t (Г •псойяд='иТР-в"'>»

<n1 supporieelAppProtocoAes w schcmalocabonB'umiso t51182 2010AppProlocol /V2G_CI_AppPiolocol x*d‘

xmlns nle'um so-15118 2 2010 AppProtocol*

xmlns xsi®’hflp:Wwww w3 org/2001/XMlSchefna-instance’>

<AppProtoeol>

<ProtocoftUmespaoe>urn iso 15118:2 2013 MsgOef<<ProiocoiKarnespoce> <Ve'$‘enNumbfrfM^or>2<<VeriionMumbe<MifOr>

«VtrbonNumbfrfMinor-O^ersionNumbertAnor-

<SchemaiD>KScftemalO>

<Pnonty>1 <fPrio<ty>

</AppPro*ocoi>

<M1 $upport«dAppProtoooiReq>

Пример 3 сообщения V2G — supportedAppProtocolReq: отклонение младшего номера версии

<">xmi vemons'1 O’ •ncodi('9s”UTF-8’'>>

<n1 supportodAppProtocoiRes x» setiemaLocation«'*ixn eolSl t8 2 2010 AppProtocol A/2G_CI_AppProlocol xsd*

xmlns n1«’um iso: 15118 2 2010 AppProtocol'

xmlns xsi®*http/>Wwww3or^2001/XMLSchems.inslance*>

<RMponteCode>OK_SucceeafulNe90tiaUonWlthMinor06vitton</R«soont6Co<le>

<ScftemalD>l </SchemalD>

</n1 support>dAppProtocolRes>

Пример 4 сообщения V2G — supportedAppProtocolRes: отклонение младшего номера версии

8.3 Определение сообщения V2G

8.3.1 Обзор

В данном подразделе описываются сообщения V2G и их содержание. Он состоит из следующих трех пунктов:

- определение сообщения V2G {см. 8.3.2);

- определение заголовка сообщения V2G {см. 8.3.3);

- определение тела сообщения V2G (см. 8.3.4).

Примечание — Код XML-схеыы приведен в приложении F.

На набор сообщений на уровне приложения указывает область имен XML-схемы «um:tso:15118:2:2013:MsgDef». Подробности относительно определений областей дополнительных имен, используемых для определения сообщения, приведены в определении XML-схемы в приложении F.

8.3.2 Определение сообщения

На рисунке 19 показано определение схемы сообщения V2G прикладного уровня.

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

i v2gci_hMeesageHBaderType

Рисунок 19 — Диаграмма — Сообщение V2G

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

Таблица 23 — Семантика и определение типа для сообщения V2G

Имя элемента

Тип

Семантика

Сообщение V2G

compiexType

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

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

Заголовок

compiexType:

MessageHeaderType см. 8.3.3

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

Тело

compiexType:

BodyType см. 8.3.4

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

Пример 5 сообщения V2G показывает образец сообщения SessionSetupReq. Заголовок содержит SessionlD. равный нулю (0). потому что новый сеанс связи должен вскоре качаться. Тело заключает в себе специфичное содержание сообщения. В этом случае сообщение содержит элемент сообщения EVCCID.

<?«ni versw»’i 0* encoding*'UTF-e’’»

<v2gci_d:V2G_Message xmtne:v2gci_bs"urfl:iso:15118:2:2Ol3:MsgBo0y’ xmbt$ xml»g3'http/tawww3 org^OOO-’OSVxmldsig#’ xmlns v2gci_d='’um:«6o:15l 18 2:2013 MsgDef xrrfctt v2gci_t«’um во 1511S 2 20l3MsgDataTypes' xmlns v2gci_hs"um:iso:15118:2:2013.MsgHesder xnWvs x»i«4Mtp//w«w w3org/200i/XMLScnema-insiance’» <v2gci_d:Header>

<v2gcl_h SetSK>nlD»00<Ar2go_b Session©» <v2ga_dKeader>

<v2gci_d Body>

<v2gci b SessionSetupReq»

<v2gci.b EVCCIO>0123456789AB<A-2gci.b EVCCtD>

<v2go_b Session SetupReq»

</v2go_d Body»

</v2ao d:V2G Messaoe>

Пример 5 сообщения V2G — Пример сообщения SessionSetupReq

8.3.3 Определение заголовка сообщения

Заголовок сообщения содержит общую информацию, которая включена во все сообщения. На рисунке 20 показано определение схемы заголовка сообщения V2G.

I— SessionlD

QdesBageHBaderType^T^I—■ i Notification Ijl

- - - -_s_

, xm Is lg Signature Щ

Рисунок 20 — Диаграмма — Заголовок сообщения

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

Таблица 24 — Семантика и определение типа для заголовка сообщения V2G

Имя элемента

Тип

Семантика

SessionlD

simpleType:

SessronlDType: hexBinary (макс, длина: в)

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

Notification

comptexType:

NotrhcationType см. в.5.2.8

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

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

xmls*g:Signature

separate namespace:

«http://www.w3.org/2000/09/

xmldsig#»

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

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

[V2G2-182] Каждое сообщение V2G. содержащее подписанные элементы, должно включать в заголовке элемент xmtsig:Stgnatufe. чтобы сделать возможной передачу подписи, сопровождающей элементы сообщения подписанного тела соответствующего сообщения.

8.3.4 Определение тела сообщения

Тело сообщения содержит данные, относящиеся к конкретному сообщению. На рисунке 21 показано определение схемы тела сообщения V2G. Сообщения, описанные ниже, являются производными от BodyBaseType. который представляет собой абстрактное содержание сообщения (см. 8.3.2). Различные прикладные сообщения определяются элементом BodyEtement.

Рисунок 21 — Диаграмма — Тело сообщения

[V2G2-183) BodyEtement должен использоваться, как определено е таблице 25. Таблица 25 — Семантика и определение типа для тела сообщения V2G

Имя элемента

Тип

Семантика

BodyEtement

comptexType:

BodyBaseType

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

8.4 Определения сеанса связи V2G и элементов тела сообщения

8.4.1 Общие положения

Сеанс связи V2G в настоящем стандарте определяется как ассоциация двух конкретных субъектов V2G для обмена сообщениями V2G в предопределенной последовательности (см. 8.8) для управления процессом зарядки. Сеанс связи V2G всегда начинается с пары сообщений SessionSetupReq/Res и всегда заканчивается парой сообщений SesstonStopReq/Res.

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

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

Пауза сеанса связи V2G управляется параметром ChargtngSession в SessionStopReq со значе-ниями «Terminate» и «Pausing». Параметр может быть использован независимо от профиля зарядки. Это означает, что EV может инициировать паузу в любое время после отправки PowerOeiiveryReq с ChargeProgress. равным «Stop» и в соответствии с [V2G2-739],

На рисунке 22 показана обработка сеанса связи V2G.

SaMKnSab*»AegSaiU3ciO*6>Ra>>(S*ttMi<<0«?3)


Зм*юп&Ю(Ам}>Ам<О<йпдИ9&м)м)п>А|Мма)


S«Mo,S«usAaq($<u»<rtO<?3)R«>(SatiKnO»2n


Зй*Моп&осА»аЯа|»|С>м<фпд£«И'11в»«Т)л<ап1Й*)


Поакгаонемне


С«внС СВЯЗИ V2G 1

(Semorfcj» 23)


Соединение ТСРГП-S


Канал обмена данными


Пеуэа


Сеенс связи


Сеанс СИЭИ V2G 2

(Session^ г 23)


Соею*<ение tcp/tls


Канал обмена дагмыми


Время


Отключение


Рисунок 22 — Обработка сеанса связи V2G


8.4.2 Обработка сеанса К EVCC применяются следующие требования:

(V2G2-739J EVCC должен сделать паузу в сеансе связи V2G с помощью параметра ChargingSession.

установленного на значение «Pause» в сообщении SessionStopReq. и должен остано-вить сеанс связи V2G (прекратить связь на транспортном уровне).

Примечание 1 — При паузе сеанса связи V2G EVCC прекращает свою связь на транспортном уровне, что вызывает также паузу в процессе зарядки. Во время паузы зарядки также невозможно использование дополнительных услуг.

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

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

- SeiectedPaymentOption (PaymentServiceSelectionReq):

- RequestedEnergyTransferMode (ChargeParameterDiscoveryReq).

[V2G2-742J Если EVCC желает возобновить ранее приостановленный сеанс связи V2G. он должен отправить параметр Departure Time в ChargeParameterDiscoveryReq. уменьшенный на прошедшее время.

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

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

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

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

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

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


К SECC применяются следующие требования:

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

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

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

- ChargeService (ServiceDiscoveryRes);

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

Примечание 2 — Необходимо, чтобы ChargingProfile. рассчитанный EVCC во время предыдущего(их) сеанса(ов) связи V2G. оставался действительным после прерывания зарядки для всего сеанса зарядки.

Примечание 3 — EV может делать выбор между следованием сохраненному ChargingProfile или созданием нового ChargingProfile на базе дополнительных SAScheduleTuples. которые даны в SAScheduleList сообщения ChargeParameterDiscoveryRes.

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

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

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

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

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

(V2G2-754) Если значение SessionlD. полученное в текущем SessionSetupReq. равно значению.

сохраненному из предшествующего сеанса связи V2G. SECC должен подтвердить продолжение сеанса зарядки путем отправки сообщения SessionSetupRes. включив сохраненное значение SessionlD и указав на возобновление сеанса связи V2G посредством ResponseCode. установленного в значение «OK_OldSessionJoined» (см. также (V2G2-463) относительно выбора надлежащего кода ответа).

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

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

Примечание 4 — Дополнительные требования относительно использования описанных в настоящем стандарте ходов ответов, которые применимы к параметру SessionlD, cu. в 8.8.3.

8.4.3 Общие сообщения

8.4.3.1 Обзор

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

6.4.3.2 SessionSetupReq/Res

8.4.3.2.1 SessionSetupReq

С помощью сообщения SessionSetupReq EVCC устанавливает сеанс связи V2G.

[V2G2-188] В зависимости от еыбранного(ых) набора(ов) сообщений, олисанного(ых) в 8.6.2.

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

SeseionSetupReqType SessionSetupReq Л ‘=В/СС1Р

Рисунок 23 — Диаграмма — SesskxiSelupReq

[V2G2-189] Элементы данного сообщения должны использоваться, как определено в таблице 26. Таблица 26 — Семантика и определение типа для SessionSetupReq

Имя элемента

Тип

Сенемтмка

EVCCID

simpleType:

EVCCIDType hexBinary (макс, длина: в) см. определение типа в F.6 (приложение F)

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

[V2G2-879] EVCC должен передать EVCCIO длиной шесть байтов и должен заполнить его своим МАС-адресом.

8.4.3.2.2 SessionSetupRes

SECC отвечает на SessionSetupReq сообщением SessionSetupRes. Посредством ResponseCode. включенного в сообщение SessionSetupRes. SECC сообщает EVCC. успешным или нет было установление нового сеанса или присоединение к предыдущему сеансу связи.

[V2G2-190] В зависимости от выбранного(ых) набора(ов} сообщений, описанного(ых) в 8.6.2.

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

SesetonSetupResType

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

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

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

EVSEID

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

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

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

EVSETtmeStamp

simpleType: long

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

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

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

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

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

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

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

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

8.4.3.3 ServiceDiscoveryReq/Res

8.4.3.3.1 Обработка ServiceDiscoveryReq/Res

Служба обнаружения сервисов (Service Discovery) позволяет EVCC найти все услуги, предоставляемые SECC. 8 настоящем стандарте описаны свойства интерфейса между EVCC и SECC. относящиеся к зарядке EV. Служба обнаружения сервисов различает типы и объемы услуг.

8.4.3.3.2 ServiceDiscoveryReq

Отправив сообщение ServiceDiscoveryReq. EVCC побуждает SECC к отправке информации о всех услугах, предлагаемых SECC. Кроме того, EVCC может ввести ограничения для определенных сервисов с помощью элементов объема сервиса и типа сервиса.

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

Service DiecoveryReqType
-Service Scope
ServiceDiscoveryReq {-•••-'EH

Имя элемента

Тип

Семантика

ServiceScope

simpleType: serviceScopeType строка (макс, длина: 32) см. определение типа в F.6 (приложение F)

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

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

С применением диапазона к обнаружению сервисов итоговый перечень услуг, передаваемый в ServioeDiscoveryRes. может быть ограничен определенным объемом, что обеспечивает предварительный отбор. SECC всегда передает все поддерживаемые сервисы всех видов, если никакой конкретный объем услуг ServiceScope не был указан в сообщении-запросе. Определение URI (унифицированный идентификатор ресурса) описано в {46} и зависит от специфики реализации

ServiceCategory

simpleType:

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

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

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

8.4.3.3.3 ServiceDiscoveryRes

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

[V2G2-195] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообще* ний. как определено в таблице 104 и в соответствии с рисунком 26.

Service DiscoveryResType

■— "ResponseCode

Service Dis cove ry Re s[^—


— PaymentOptionList


CherqeServtce


L-.


ServiceList


Имя элемента

Тип

Семантика

ResponseCode

simpleType:

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

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

PaymentOpbonUst

comptexType:

PaymentOpbonListType см. 8.5.2.9

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

ChargeService

comptexType:

ChargeServtceType см. 8.5.2.3

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

ServiceList

comptexType:

ServiceListType cm. 8.5.2.2

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

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

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

8.4.3.4 ServiceDetailRe<yRes

8.4.3.4.1 ServiceDetailReq

Отправив сообщение ServiceDetailReq. EVCC запрашивает SECC об отправке конкретной дополнительной информации о сервисах, предлагаемых EVSE.

[V2G2-197] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

Зе rvica Da tallRi qType

^ServiceDetailReq^^—

Рисунок 27 — Диаграмма — ServiceDetailReq

[V2G2-198] Элементы данного сообщения должны использоваться, как определено в таблице 30. Таблица 30 — Семантика и определение типа для ServiceDetailReq

Имя элемента

Тип

Семантика

ServtcelD

simpleType:

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

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

8.4.3.4.2 ServiceDetailRes

После получения сообщения ServiceDetailReq от EVCC SECC посылает сообщение ServiceDetailRes и предоставляет подробности о сервисах.

[V2G2-199J В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

Рисунок 28 — Диаграмма — ServiceDetailRes


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

Таблица 31 — Семантика и определение типа для ServiceDetailRes

Имя элемем!а

Тип

Семпмтика

ResponseCode

simpleType:

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

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

ServicelD

simpleType:

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

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

ServiceParameterList

compiexType: ServiceParameterListType cm. 8.5.2.21

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

8.4.3.5 PaymentServiceSetectionReq/Res

8.4.3.5.1 Обработка выбора оплаты и сервиса

На основе услуг и соответствующих опций оплаты, предоставляемых SECC. эта пара сообщений позволяет передавать выбранные опции платежа (PaymentOption). выбранные услуги (SelectedServices) и соответствующие наборы параметров (ParameterSets). 8 зависимости от выбранного типа оплаты происходит обмен дополнительными сообщениями (пара сообщений PaymentDetails).

8.4.3.5.2 PaymentServiceSeiectionReq

Это сообщение-запрос передает информацию о выбранных услугах и о том. как все выбранные услуги оплачиваются (см. 8.6.3.1).

[V2G2-201J В зависимости от еыбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

PaymentServiceSelecttonRsqType

PaymentServiceSeiectionReq


— "SelectedPaymentOptlonJ-


i— SelectedServiceLtet

Имя элемент

Тип

Семантика

SelectedPaymentOption

simpleType:

paymentOptionType enumeration см. определение типа е F.6 (приложение F,

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

SetectedServiceList

comptexType: SelectedServiceListType см. 8.5.2.24

Слисок содержит идентификаторы всех выбранных сервисов {ServicelDs} и факультативный parameterSetID для соответствующего servicelD

8.4.3.5.3 PaymentServiceSeiectionRes

Этим сообщением SECC информирует EVCC. были ли приняты выбранные услуги и опция опла* ты. в зависимости от выбранного типа оплаты происходит обмен дополнительными сообщениями (пара сообщений PaymentDetails).

[V2G2-203J В зависимости от еыбранного(ых) набора(ов) сообщений, олисанкого(ых) в 8.6.2.

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

PaymentServlceSelectionRasType

PaymentServlceSelectlonRBS Г^—*ReeponeeCode

Рисунок 30 — Диаграмма — PaymentServiceSelecbonRes

[V2G2-204] Элементы данного сообщения должны использоваться, как определено в таблице 33. Таблица 33 — Семантика и определение типа для PaymentServiceSelecbonRes

Имя элемента

Тил

Семантика

ResponseCode

simpleType:

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

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

8.4.3.6 PaymentDetailsReq/Res

8.4.3.6.1 Обработка ServiceDiscoveryReq/Res

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

8.4.3.6.2 PaymentDetailsReq

Посредством PaymentDetailsReq EVCC предоставляет платежные реквизиты, если выбранный способ оплаты был «Contract». EVCC запрашивает у SECC отправку вызова, используя сертификат подписи и eMAID.

[V2G2-205] В зависимости от еыбранного(ых) набора(ов) сообщений, олисанкого(ых) в 8.6.2.

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

PaymentDa tilts ReqType

“eMAIO


P»ym«ntD»tall«R>q~^—


— Contract SignrtureCertChalnjtj

Рисунок 31 —Диаграмма — PaymentDetailsReq

[V2G2-206J Элементы данного сообщения должны использоваться, как определено в таблице 34. Таблица 34 — Семантика и определение типа для PaymenlDelaisReq

Имя элемента

Тип

Семантика

eMAID

simpleType: eMAIDType строка (мин. длина: 14, макс, длина: 15) см. определение типа в F.6 (приложение F)

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

ContractSignatureCert

Chain

comptoxType:

CertificateChainType см. 8.5.2.4

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

8.4.3.6.3 PaymentDetailsRes

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

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

Ржут • ntOa tails Re • Ту ре

"ResponseCode

PaymentDetailsRes


' GenChallenge


"EVSETtmeStamp

Рисунок 32 — Диаграмма — PaymentDetailsRes

[V2G2-209] Элементы данного сообщения должны использоваться, как определено в таблице 35. Таблица 35 — Семантика и определение типа для PaymentDetaisRes

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

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

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

Окончание таблицы 35

Имя элемента

Тип

Сеыаигим

GenChallenge

simpleType:

genChallengeType base64Binary (длжа 15)

см. определение типа в 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] В случае выполнения идентификационного режима РпС EVCC должен отправить

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

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

8.4.3.7 AuthorizationReq/Res

8.4.3.7.1 AuthorizationReq

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

[V2G2-210] В зависимости от выбранного(ых) набора(ов) сообщений, олисанного(ых) е 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице1О4 и в соответствии с рисунком 33.

AuthortzattonReqType

Рисунок 33 —Диаграмма —AuthorizationReq

[V2G2-211] Элементы данного сообщений должны использоваться, как определено в таблице 36. Таблица 36 — Семантика и определение типа для AuthorizationReq

Имя элемента

Тип

Семантика

ю

simpleType: ID цепочка

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

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

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

GenChallenge

simpleType:

genChaltengeType base648inary (длина 16)

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

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

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

[V2G2-697J Поле GenChallenge должно быть длиной 128 бит.

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

8.4.3.7.2 AuthorizationRes

В заключение SECC проверяет подпись вызова (и цепочку сертификата, если это не сделано раньше) и посылает соответствующее сообщение-ответ с авторизацией.

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

AuthorizationResType

AuthorizationRes —j3~~


^ResponseCode |


EVSgh-ocessIng


Рисунок 34 —Диаграмма —AuthorizationRes

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

Таблица 37 — Семантика и определение типа для AuthorizationRes

Имя элемента

Тип

Семантика

EVSEProcessing

simpleType:

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

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

ResponseCode

simpleType:

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

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

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

(V2G2-901) В случае выполнения идентификационного режима РпС SECC должен удостовериться в том. что элемент тела AuthorizationReq правильно подписан закрытым ключом, соответствующим сертификату контракта, ранее полученному в сообщении PaymentDetailsReq

данного сеанса, и что поле GenChallenge имеет такое же содержание, как поле GenChallenge. ранее отправленное SECC в сообщении PaymentsDetailsRes. Если какая-либо из указанных проверок и валидаций не удается. SECC должен считать подпись недействительной. См. также (V2G2-475).

8.4.3.8 ChargeParameterOiscoveryReqZRes

8.4.3.8.1 Обработка ChargeParameterDiscoveryRe<yRes

После авторизации зарядки на EVSE (SECC) EVCC и SECC согласовывают параметры зарядки с помощью пары сообщений ChargeParameterDiscoveryReq/Res.

Примечание — Последовательность сообщений для пересогласования описана в приложении Н.

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

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

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

8.4.3.8.2 ChargeParameterOiscoveryReq

При отправлении сообщения ChargeParameterOiscoveryReq EVCC передает параметры зарядки SECC. Данное сообщение содержит информацию о статусе EV и дополнительных параметрах зарядки, таких как примерное количество энергии для подзарядки EV. возможности системы для зарядки EV. время, когда водитель намерен уехать со станции EVSE.

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

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

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

Charge ParameterDU cove ryReqTypt

- ^Max&trteaMScheduieTupte ’

ChargeParameterDtecoveryFhtq '^—--eRaque»tedEnergyTran»ferMode

p v2gci_t£VChargeParameter Й

AC EVChargeParameter

DC EVChargeParameter ф

Рисунок 35 — Диаграмма — ChargeParameterOiscoveryReq

[V2G2-216] Элементы данного сообщения должны использоваться, как определено в таблице 38. Таблица 38 — Семантика и определение типа для ChargeParamelerOiscoveryReq

Имя элемента

Тил

Сеиаитии

MaxEntriesSASchedule

Tuple

simpleType: unsignedShort см. определение типа a F.6 (приложение F)

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

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

RequestedEnergyTransfer

Mode

simpleType:

EnergyTransferModeType

enumeration

см. определение типа a F.6 (приложение F) и таблице 63

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

AC_EVChargeParameter

comptexType:

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

EV ChargeParameterType см-8.5.32

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

DC_EVChargeParameter

comptexType:

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

EV ChargeParameterType см._8.5.4.3

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

Определение EnergyTransferModeType поддерживает соединители типа 1. 2 и 3 в соответствии с ГОСТ Р МЭК 62196-2 и соединители в соответствии с [49] (приложения сс. dd, ее и ff). С учетом поддерживаемых соединителей EVCC может выбирать услуги по зарядке, как указано в 8.5.2.4.

[V2G2-784] EVCC должен поддерживать 12 записей для элементов PMaxScheduleEntry и SatesTariffEntry внутри одного SAScheduleTuple. если MaxEntriesSAScheduleTuple не передается в сообщении ChargeParameterDiscoveryReq.

[V2G2-786] SECC должен поддерживать минимум 12 записей для элементов PMaxScheduleEntry и SatesTariffEntry внутри одного SAScheduleTuple.

(V2G2-785J Если SECC не может обеспечить число записей для элементов PMaxScheduleEntry и SatesTariffEntry внутри одного SAScheduleTupie. которое требуется для MAXEntriesSAScheduleTuple. он должен отправить максимальное число записей. ко-торое поддерживается в SAScheduleTuple.

6.4.3.8.3 ChargeParameterOiscoveryRes

Посредством сообщения ChargeParameterDiscoveryRes SECC передает параметры зарядки, которые применимы для электросети. В дополнение к общим параметрам зарядки для EVSE это сообщение может включать дополнительную информацию о стоимости электроэнергии в зависимости от времени, запроса, потребления или сочетания этих параметров. Термин «стоимость» относится к любого рода стоимости (см. 8.5.2.20). указанной в настоящем стандарте, и не ограничивается стоимостью в денежном выражении. На основе указанной информации о стоимости EV может оптимизировать график своей зарядки по запрашиваемому количеству энергии.

Примечание 1 —Посредством «стоимости» EVSE может стимулировать (не принуждать) EVк зарядке в периоды, которые благоприятны для электросети (например, при излишках получения ветровой энергии и т. п.).

(V2G2-218) В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

PchirgePiremeterEXecoveryReeType ' I—^ReaponaaCoda |

B/S^roeaaaingJ

Charge Ра ram е te rDtecove ту Re*


t v2gcHSASchaduiea ' 4’ - -- -- -- -' SASchaduleLiet^T)

,v2gci t:B/$eCharge Parameter

| AC EySSChargeParameter

DC_B^SBChargeParameter ф

Рисунок 36 — Диаграмма — ChargeParameterOiscoveryRes

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

[V2G2-220J Элементы данного сообщения должны использоваться, как определено в таблице 39. Таблица 39 — Семантика и определение типа для ChargeParameterOiscoveryRes

Имя элемента

Тип

Семантика

EVSEProcessing

simpleType:

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

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

ResponseCode

simpleType:

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

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

SASchedulebst

comptexType:

SASchedulebstType заменяет абстрактный тип SASchedulesType см. 8.5.2.12

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

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

AC.EVSECharge

Parameter

comptexType:

AC_EVSEChargeParameterType заменяет абстрактный тип EVSE_ChargeParameterType см. 8.5.3.3

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

DC.EVSECharge

Parameter

comptexType:

OC.EVSEChargeParameterType заменяет абстрактный тип EVSE_ChargeParameterType см. 8.5.4.4

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

Примечание 2 — С помощью параметра EVSEProcessing EVSE может указать EVCC на то. что обработка информации не завершилась, но сообщение с ответом должно быть отправлено для выполнения требований по тайм-ауту и производительности, изложенных в 8.7.2. Это позволяет продолжить сеанс связи, выполняя требования по производительности и тайм-ауту.

8.4.3.9 PowerDetiveryReq/Res

8.4.3.9.1 Обработка PowerDelrveryReq/Res

Обмен сообщениями о начале зарядки указывает на момент времени, когда EVSE подает напряжение на зарядный разъем.

[V2G2-286] Элемент SAScheduleTuplelD должен идентифицировать выбранный элемент SAScheduleTupIeType (см. 8.5.2.13}е списке элементов SAScheduleTuple (см. 8.5.2.12). переданном в сообщении ChargeParameterDiscoveryRes (см. 8.4.3.8.3).

8.4.3.9.2 PowerDeliveryReq

С помощью сообщения PowerDeliveryReq EVCC запрашивает у SECC передачу электроэнергии и передает ChargingProfile. которому EVCC будет следовать во время зарядки.

Примечание 1 — Момент отправления этого сообщения не обязательно соответствует началу процесса зарядки. EV может корректировать параметры графика зарядки, когда процесс зарядки уже начался.

[V2G2-221] В зависимости от выбракного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

PowerOeDveryRaqType

I—|=ChargeProgr^«

PowrOeMwryWaq


-LSASchxMeTupt>C

I г —*1

г -' ChargingProfile

- • ^v2gcl_tCVPowtrOelheryParameter

\ DC_EVPowerO»ltoryParameter ф

Рисунок 37 — Диаграмма — PowerDeliveryReq

[V2G2-222J Элементы данного сообщения должны использоваться, как определено в таблице 40. Таблица 40 — Семантика и определение типа для PowerDeliveryReq

Имя элемента

Тип

Семантике

ChargeProgress

simpleType:

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

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

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

SAScheduleT uplel D

simpleType:

SAlDType short

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

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

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

Окончание таблицы 40

Имя элемента

Тип

Сеыаигим

ChargingProfile

comptexType:

ChargingProfileType см. 8.5.2.10

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

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

DC_EVPower Delivery Parameter

comptoxType:

DC_EVPowerDeliveryParameterType заменяет абстрактный тип EVPowerDeirveryParameter см. 8.5.4.5

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

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

Примечание 2 — В ГОСТ Р 58122 (ИСО 15118-1:2013) термин «ChargingProfile» («профиль зарядки») также называется «графиком зарядки».

8.4.3.9.3 PowerDeliveryRes

SECC после получения сообщения PowerDeliveryReq EVCC направляет сообщение PowerDeliveryRes. включая информацию об объеме электроэнергии.

[V2G2-223J В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

Powe rOe Hve ryfti вТуре

PowerpBliveryWBB ф—С~***~^~


— "ReaponeeCode |


v2gci t:£VSEStatu»


j AC EVSEBUtuB

DC BZSGStetuB

Рисунок 38 — Диаграмма — PowerDeliveryRes

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

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

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

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

Таблица 41 — Семантика и определение типа для PowerOeliveryRes

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

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

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

AC.EVSEStatus

compiexType:

AC.EVSEStatusType заменяет абстрактный тип EVSEStatusType см. 8.5.3.1

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

OC.EVSEStatus

compiexType:

DC.EVSEStatusType заменяет абстрактный тип EVSEStatusType см. 8.5.4.1

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

8.4.3.10 CertificateUpdateReq/Res

8.4.3.10.1 Обработка CertificateUpdateReq/Res

Обновление сертификата EVCC необходимо, когда срок его действия близится к завершению. В этом случае EVCC запрашивает новый сертификат от SECC для установки его в EVCC.

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

Примечание 1 — Если SECC не может предоставить запрошенный сертификат, то должна быть выполнена обработка ошибки, см. [V2G2-471]. Если EVSE не способно поддерживать данную функцию, оно должно быть идентифицировано, например, как «офлайновое EVSE».

Примечание 2 — Разрешается использовать обновление сертификата (как описано в данном пункте), только если цель ContractSignatureCertChain не повреждена, т. е. она должна быть полностью действительна для еыпотения данной процедуры. В противном случае должна быть использована такая же процедура, как для изначального сохранения сертификата контракта в EVCC. Один из вариантов выполнения процедуры — использование сообщений типа CertiftcalelnstallationReq и CertificatelnstallationRes.

8.4.3.10.2 CertificateUpdateReq

Отправляя сообщение CertificateUpdateReq. EV запрашивает SECC о представлении нового сертификата. который принадлежит действующему в текущее время контракту EV.

[V2G2-228] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

Certificate Update ПедТуре

Qattn'd(4e$

Id

[^erttf^te^dateRe^^-


— ContrectWgnatureCertChatn jjj

eMAIO


I

— LietOfReotCertificatelDe [jj

Рисунок 39 — Диаграмма — CertificateUpdateReq

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

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

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

Таблица 42 — Семантика и определение типа для CertificateUpdateReq

Имя элемента

Тип

Семантика

U

simpleType: ID цепочка

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

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

ContractSignatureCert

Chain

comptexType:

CertificateChainType см. 8.5.2.5

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

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

eMAID

simpleType: eMAIDType цепочка (мин. длина: 14. макс, длина: 15) см. определение типа в F.6 (приложение F)

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

ListOfRootCertificatelDs

comptexType:

ListOfRootCertificalelDsType см. 8.5.2.27

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

8.4.3.10.3 CertificateUpdateRes

SECC после получения CertificateUpdateReq EVCC извлекает запрошенный сертификат у SA. поэтому необходимо установитьонлайноеое соединение. Затем SECC посылает EVCC CertificateUpdateRes. включая новый сертификат. В заключение EVCC устанавливает данный сертификат.

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

[V2G2-2311 В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

Certificate Update RaeType

RetponteCode |

SAProHalonkigCe rtflcateChaln~^j 'ContractStgnaUjreCartChalnJp

Certificate Update R>T~^—— "ContrectSloneture&cryptedPrlwteKey — gOHpubltckey [£|

—j'eMAID ф

RetryCounter

Рисунок 40 — Диаграмма — CertificateUpdaleRes

[V2G2-232J Элементы данного сообщения должны использоваться, как определено е таблице 43. (V2G2-928J Если ResponseCode в этом сообщении указывает на неудачу (т. е. начинается с FAILED).

EVCC должен игнорировать все другие элементы, за исключением RetryCounter. Таблица 43 — Семантика и определение типа для CertificateUpdaleRes

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

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

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

SAProvisioningCertificate

Chain

comptexType:

CertificateChainType см. 8.5.2.5

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

ContractSignatureCert

Chain

comptexType:

CertificateChainType cm. S.5.2.5

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

ContractSignature

EncryptedPriva-teKey

comptexType:

ContractSignatureEncryptedPrivate

KeyType

cm. 8.5.2.28

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

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

DHpublkAey

comptexType:

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

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

eMAID

comptexType:

EMAIDType

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

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

Окончание таблицы 43

Имя элемента

Тип

Семантика

RetryCounter

simpleType short

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

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

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

если ResponseCode был «FAlLED_NoCertificate Available» или «FAILED.ContractCanceted», то это поле содержит информацию о том. когда EVCC должен попытаться получить новый сертификат еще раз. Возможны следующие записи: х > 0: после «х» дней:

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

-1: никогда

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

[V2G2-696J В случае ответа с информацией об ошибке сообщение должно также включать эле

мент RetryCounter.

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

Примечание 2 — Если SECC не мажет предоставить запрошенный сертификат, то должна быть выполнена надлежащая обработка ошибки, см. [V2G2-469], Если EVSE не способно поддерживать данную функцию, оно должно быть идентифицировано, например, как «офлайновое EVSE».

Примечание 3 — Разрешается использовать обновление сертификата, только если ContraciSignatureCert не был испорчен, т. в. он должен быть полностью действителен для выполнения процедуры. В противном случае должна быть использована такая же процедура, как для изначального сохранения сертификата контракта в EVCC. Один из вариантов выполнения процедуры — использование сообщений типа CertificalelnstallabonReq и CertHtcatelnstallationRes.

[V2G2-827] Сертификат контракта, предназначенный для замены установленного сертификата.

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

Примечание 4 — Это необходимо для исключения необходимости для EVCC хранения и обращения с двумя сертификатами контракта.

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

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

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

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

8.4.3.11 CertrficatelnstallationReq/Res

8.4.3.11.1 Обработка CertificatelnstallationReq/Res

Установка сертификата контракта в EVCC необходима, если EVCC в настоящее время не имеет действительного сертификата контракта, например не хранится ни один из сертификатов контракта, или у имеющихся сертификатов истек срок действия, или они отозваны. В этом случае EVCC запрашивает сертификат у SECC для установки в EVCC. Эта процедура, как правило, имеет место до начала процесса зарядки, потому что зарядка с авторизацией может начаться, только если у EVCC имеется действительный сертификат. SECC может запросить сертификат у SA. После установки данного сертификата может начинаться процесс зарядки на EVSE. к которому подклю-чено EV.

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

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

Примечание 2 — Если SECC не может предоставить запрошенный сертификат, то необходимо выполнить обработку ошибки. Если EVSE не поддерживает данную функцию, то оно должно быть идентифицировано. например, как «офлайновое EVSE». Если EVCC не имеет действующего сертификата, присвоенного контракту, режим «подключи и заряжай» не может использоваться до успешного выполнения процесса установки сертификата.

8.4.3.11.2 CertificatelnstallationReq

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

[V2G2-235] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

CertfficatelnetallattonReqType

Certificate Ins taltatto n Ав q

Рисунок 41 — Диаграмма — CertificatelnstallationReq

[V2G2-236] Элементы данного сообщения должны использоваться, как определено в таблице 44. Таблица 44 — Семантика и определение типа дпя CertificatelnstallationReq

Имя элемента

Тип

Семантика

W

simpleType: ID строка

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

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

Окончание таблицы 44

Имя элемента

Тип

Семантика

OEMProvisioningCert

simpleType:

certificateType base64Binary (макс, длина 800) см. определение типа в F.6 (приложение F)

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

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

Сертификат закодирован в соответствии с особыми правилами кодирования DER (Distinguished Encoding Rules).

См. также С.1 (приложение С)

ListOfRootCertificatelDs

comptexType:

ListOfRootCertificatelDsType см. 8.5.2.27

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

[V2G2-893] EVCC должен подписать элемент тела CertificateInstallationReq, используя свой сертификат изготовителя.

[V2G2-894] Служба выдачи сертификатов должна проверить подпись элемента тела сообщения CertificatelnstaKationReq с помощью включенного сертификата изготовителя из поля OEMProvisioningCert. Служба выдачи сертификатов должна выполнить валидацию указанного сертификата изготовителя, включая цепочку из того же поля, и убедиться в том. что он прослеживается до безопасного корневого сертификата изготовителя. Служба выдачи сертификатов должна убедиться в том, что сертификат изготовителя имеет установленный DC (доменный компонент) «ОЕМ». Если что-либо из вышеуказанного не выполняется, служба выдачи сертификатов должна рассматривать подпись как недействительную. прекратить процедуру и вызвать сообщение об ошибке от SECC.

8.4.3.11.3 CertificatelnstallationRes

После получения от EVCC CertificatelnstallationRes SECC направляет CertificatelnstallationRes, включая запрошенный сертификат. Затем EVCC устанавливает данный сертификат.

В EVCC предоставляется только один сертификат: сертификат для подписания сообщений. Он принадлежит действующему в настоящее время контракту EV.

[V2G2-237] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 42.

Се rtrficate Ina teltattonRe • Type

f— ~R»sponseCode

— SAProvtetonlngCerttficeteChaln {*J

CertlflcetelneUtlatlonRes


— ^ontractSignetureCertChalnJ^J

— ConlractStgnitureEncryptedPrlviteKey цЗ

—I^PHpubfickey^

=eMAtog}

Рисунок 42 — Диаграмма — CertificatelnstallationRes

[V2G2-238J Элементы данного сообщения должны использоваться, как определено в таблице 45.

Таблица 45 — Семантика и определение типа для CertificatelnstailabonRes

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

responseCodeType enumeration см. определение типа в Еб (приложение Е6)

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

SAProvisioningCertificate

Chain

comptoxType:

CertificateChainT урв см. 8.5.2.5

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

ContractSignatureCert

Chain

comptoxType:

CertificateChainT уре см. 8.5.2.5

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

ContractSignature

EncryptedPrivateKey

comptexType:

ContractSignatureEncryptedPnvate КеуТурвсм. 8.5.2.28

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

Эти данные должны быть зашифрованы с помощью предоставленного сертификата изготовителя EVCC (не базе OEMProvisioningCert. содержащегося в сообщении Certificate Installation Request) и с помощью секретного ключа Диффи — Хеллмана для шифрования, как описано в 7.9.2.4.3

DHpublickey

comptoxType:

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

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

eMAID

comptoxType:

EMAIDType

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

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

[V2G2-895J Служба выдачи сертификатов должна подписать следующие элементы сообщения CertificatelnstaKationRes с использованием сертификата службы выдачи сертификатов: ContractSignatureCertChain, ContractSignatureEncryptedPrivateKey. DHpublickey. ContractiD. CertificatelnstallationRes должно включать цепочку сертификата для про* верки этой подписи в поле SAProvisioningCertChain. Служба выдачи сертификатов также должна убедиться в том. что данные, которые удостоверяются этой подписью, получены от предыдущего SA надежным способом.

[V2G2-896] EVCC должен проверить подпись сообщения CertificatelnstallationRes. используя це> почку сертификатов подписчика SAProvisioningCertificateChain, проверить указанную цепочку и убедиться, что она вернулась к действительному корневому сертификату V2G. Он должен гарантировать, что сертификат подписчика имеет поле DC (DomainComponent) с содержимым «CPS». Он должен обеспечить включение в подпись следующих элементов: ContractSignatureCertChain. ContractSignatureEncrypted PrivateKey. DHpublickey, ContractiD. Если какое-либо из вышеперечисленных условий не выполняется. EVCC считает сообщение недействительным и отбрасывает его. Кроме того. EVCC должен хранить части цепочки сертификатов, которых она еще не имеет.

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

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

8.4.3.11.4 Офлайновая установка сертификата

В качестве альтернативы описанной ранее процедуре сертификат контракта может быть передан на транспортное средство без использования протокола зарядки. Это может быть необходимо, например, если инфраструктура. SA или транспортное средство не поддерживает CertificatelnstaltationReq/Response. В таких случаях сертификат контракта, который должен быть установлен, передается потребителю (например, почтой, электронной почтой) и затем EV (напри* мер. с использованием диагностического интерфейса транспортного средства или интернет-досту* ла к транспортному средству). Это означает, что все указанные передачи осуществляются в офлайновом режиме, а не через протокол зарядки. Файл (передаваемый потребителю) содержит цепочку сертификата и соответствующий закрытый ключ (аналогично CertificatelnstallationRes). Чтобы из* бежать несовместимости форматов файлов и необходимости реализации алгоритмов трансформации. единообразные форматы файлов должны использоваться всеми SA при рассылке файлов сертификата контракта.

[V2G2-848] При передаче SA файла, который содержит сертификат контракта, цепочку сертификата и закрытый ключ подписи, файл должен быть предоставлен в формате PKCSS12.

Примечание — Решение о шифровании данных, содержащихся в данном файле, принимается SA. Если данные шифруются, потребителю должен быть дололнитегъно передан пароль. Для передачи пароля должен использоваться безопасный канал. Как альтернатива, данные, содержащиеся в файле PKCS#12. могут не шифроваться. а передаваться лично безопасным путем (например, вручаться лично).

8.4.3.12 SessionStopReq/Res

8.4.3.12.1 SessionStopReq/Res Handling

Эта пара сообщений V2G должна использоваться для прекращения сеанса связи V2G. инициированного предшествующим сообщением SessionSetupReq.

8.4.3.12.2 SessionStopReq

С помощью сообщения SessionStopReq EVCC запрашивает о разрешении прекращения процесса зарядки.

[V2G2-239] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 43.

SessionStopReq


SessionStopRsqType Г ! ChargingSession

Рисунок 43 — Диаграмма — SessionStopReq

[V2G2-738] Элементы данного сообщения должны использоваться, как определено в таблице 46.

Таблица 46 — Семантика и определение типа для SessionStopReq

Имя элемента

Тип

Семантика

ChargingSession

simpleType:

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

ChargingSession указывает на намерение EVCC сделать паузу или прекратить сеанс связи V2G

8.4.3.12.3 SessionStopRes

SECC после получения SessionStopReq от EVCC посылает SessionStopRes. информируя EVCC об успешном прекращении процесса зарядки.

[V2G2-240] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 44.

SeeeionStopFteaType

SessionStopRes ^ResponseCode

Рисунок 44 — Диаграмма — SessionStopRes

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

Таблица 47 — Семантика и определение типа для SessionStopRes

Имя элемента

Тип

Сеыаитиы

ResponseCods

simpleType:

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

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

8.4.3.13 MeteringReceiptReq/Res

8.4.3.13.1 MeteringReceiptReq/Res Handling

При отправлении сообщения MeteringReceiptReq EVCC подтверждает, что элементы данных Meterlnfo. SessionlD и SAScheduleTupIelD, включенные в сообщение ChargingStatusRes до этого запроса, были получены от SECC. Это подтверждение реализуется подписью к телу сообщения MeteringReceiptReq. Подпись, применяемая EVCC. предназначена только для подтверждения, что EVCC вместе с действующим сертификатом контракта на зарядку, который был выбран для данного сеанса зарядки, получил элементы данных Meterlnfo record. SessionlD и SAScheduleTupIelD в составе сообщения Charging Status Res до данного запроса. Она не предназначена для подтверждения, что количество энергии, указанное в предыдущем Meterlnfo record, верно. Однако подписанная информация о показаниях счетчика может быть использована любым оператором услуг для EV для расчета. Определение процесса расчета, который подчиняется локальным правилам, не рассматривается в настоящем стандарте.

[V2G2-902] Элемент Meterlnfo. отправленный SECC в сообщении ChargingStatusRes, должен содержать такие же данные, какие выдает прибор учета. Он должен содержать необработанные показания прибора учета в форме, которая в целом поддается машинному чтению.

Примечание — Это позволит EVCC в общем случае анагызировать показания прибора учета.

8.4.3.13.2 MeteringReceiptReq

При отправлении MeteringReceiptReq EVCC подтверждает, что элементы данных Meterlnfo record. SessionlD и SAScheduleTupIelD были получены от SECC. Это подтверждение реализуется путем применения подписи к телу сообщения MeteringReceiptReq.

[V2G2-245] В зависимости от еыбранного(ых) набора(ов) сообщений, олисанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 45.

MataringRecelptftoqType

□ attributes I

MeteringReceiptReq —


SessionlD


—( —Jg- ■ SAScheduteTuplelD

Meterlnfo


§

Рисунок 45 — Диаграмма — MeteringReceiptReq

[V2G2-246J Элементы данного сообщения должны использоваться, как определено в таблице 48. Таблица 48 — Семантика и определение типа для MeteringReceiptReq

Имя элемента

Тип

Семантика

W

simpleType: ID цепочка

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

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

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

SessionlD

simpleType:

SessionlDType

SessionlDType: hexBinary (макс, длина: В) см. определение типа в F.6 (приложение F)

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

SAScheduteTuplelD

simpleType:

SAIDType short

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

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

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

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

SAScheduleTuple во время сеанса зарядки. Этот элемент является лишь повторением значения, полученного or SECC либо в ChargingStatusRes (во время зарядки переменным током), либо в сообщении CurrentDemandRes (во время зарядки постоянным током).

Идентификатор SA(SAID) остается уникальным идентификатором для одного графика в течение сеанса зарядки

Meterlnfo

comptoxType:

MelerlnfoType см. S.5.2.6

Если SECC указал в ChargingStatusRes (зарядка переменным TOKOMXCurrentDemandRes (зарядка постоянным током), что MeteringReceiptReq необходим, то этот элемент сообщения является повторением элемента Meterlnfo. полученного от SECC в ChargingStatusRes (зарядка переменным TOKOMXCurrentDemandRes (зарядка постоянным током)

[V2G2-776] Элемент сообщения SAScheduleTuplelD. если он включен, должен быть всегда равен значению SAScheduleTuptelD. полученному в предыдущем сообщении ChargingStatusRes (зарядка переменным TOKOMXCurrentDemandRes (зарядка постоянным током).

[V2G2-903J EVCC должен подписать тело сообщения MetenngReceiptReq с помощью закрытого ключа, принадлежащего сертификату контракта, который он отправил в данном сеан* се в сообщении PaymentDetailsReq.

[V2G2-904J SECC/SA может проверить подпись элемента тела сообщения MetenngReceiptReq.

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

Примечание 1 — SECC может представить сертификат контракта для SA вместе с подписанной MeteringReceipt с тем чтобы SA мог позднее перепроверить квитанцию. В случав, если SA уже сохранил сертификат контракта, то идентификатора и SA. выдавшего сертификат контракта, мажет быть достаточно.

Примечание 2 — EVCC мажет быть не способен проверить подпись SigMeterReadirtg. которая была сгенерирована SECC и которая включена в элемент Meterlrrfo. например, потому что некоторые данные, необходимые для подписи, не переданы. Поэтому применяемая EVCC подпись, которая описывается в настоящем пункте, служит только в качестве подтверждения, что EVCC получил эти данные, и не составляет какого-тмбо подтверждежя корректности.

8.4.3.13.3 MeteringReceiptRes

SECC после получения MetenngReceiptReq от EVCC посылает MeteringReceiptRes. информируя EVCC о том. была ли квитанция успешно получена и принята SECC.

[V2G2-247] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 46.

MeteringRecelptResType

' ResponseCode

— ^vaflciJfVSEStatus

AC EVSEStatua

4 DC_EVSBtatue ф

Рисунок 46 — Диаграмма — MeteringReceptRes

(V2G2-248) Элементы данного сообщения должны использоваться, как определено в таблице 49. Таблица 49 — Семантика и определение типа для MeteringReceiptRes

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

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

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

AC.EVSEStatus

comptexType:

AC.EVSEStatusType заменяет абстрактный тип EVSEStatusType см. 8.5.3.1

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

DC.EVSEStatus

comptexType:

DC.EVSEStatusType заменяет абстрактный тип EVSEStatusType см. 8.5.4.1

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

8.4.4 Сообщения для зарядки переменным током

8.4.4.1 Обзор

Сообщения, описываемые как сообщения для зарядки переменным током, принадлежат к набору(ам) сообщений для зарядки переменным током.

8.4.4.2 ChargingStatusReq/Res

8.4.4.2.1 Обработка ChargingStatusReq/Res

Пара сообщений Charging Status обеспечивает проверку работоспособности по показаниям при* бора учета, предоставляемых SECC. На основе повторяемого обмена сообщениями Charging Status EV имеет средство проверки и валидации мощности, отобранной у EVSE. Это также позволяет SECC запросить EVCC о подписании информации прибора учета, включенной в сообщение ChargingStatusRes с использованием пары сообщений-квитанций прибора учета. Использование данной подписанной информации прибора учета для расчета может быть предметом регулирования в определенных странах. Дополнительно сообщение-запрос используется для продолжения сеанса связи (сведения об обработке сеанса см. в 8.7.2).

8.4.4.2.2 ChargingStatusReq

[V2G2-242] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 47.

CharglngStstusFtoqType

^ChargingStstusRsq

Рисунок 47 — Диаграмма — ChargingStatusReq

8.4.4.2.3 ChargingStatusRes

SECC после получения ChargingStatusReq от EVCC посылает ChargingStatusRes. В случае успешного запроса статуса прибора учета (Metering Status Request) ответ предоставляет текущие показания прибора учета, установленного на EVSE. 8 случае неудачного считывания показаний прибора учета показание прибора не выдается. На неудачу указывает ResponseCode.

[V2G2-243J В зависимости от еыбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 48.

ChargingStstusRssType

’ResponseCode *EVSBD sSAScheduteTuptolC

ChsrglngSUtusRes l^~~f •—— EVSBrtaxCurrent A

Meterlnfo

AC^SEStatu^J^

Рисунок 48 — Диаграмма — ChargingStatusRes

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

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

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

EVSEID

simpleType:

evselDType

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

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

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

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

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

SAScheduleTuplelD

simpleType:

SAIOType short

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

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

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

Идентификатор SA(SAID) остается уникальным идентификатором для одного графика в течение сеанса эарядхи

EVSEMaxCurrent

comptoxType:

PhystcalVaiueType см. 8.5.2J

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

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

Meterlnfo

comptoxType:

MelerlnfoType см. 8.Б.2.6

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

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

ReceiptRequired

simpleType

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

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

данный элемент используется SECC для указания на то. что SECC запрашивает отправку сообщения MeteringReceiptReq с целью под-гысания информации прибора учета. Если ReceiptRequired равно True, от SECC запрашивается отправка сообщения MeteringReceiptReq. включая подпись. Если ReceiptRequired равно False, от EVCC не требуется отправлять сообщение MeteringReceiptReq

AC_EVS EStatus

comptoxType:

AC.EVSEStatusType заменяет абстрактный тип EVSEStatusType см. 8.5.3.1

Этот элемент используется SECC для указания своего статуса

8.4.5 XML-сообщения

8.4.5.1 Обзор

Сообщения, определяемые как сообщения для зарядки постоянным током (DC-Messages), при* надлежат к набору(ам) сообщений для зарядки постоянным током {см. 8.6.2.4).

8.4.5.2 CableCheckReq/Res

8.4.5.2.1 Обработка CabieCheckReq/Res

Для безопасной зарядки постоянным током должна быть выполнена проверка кабеля.

8.4.5.2.2 CableCheckReq

CableCheckReq запрашивает статус проверки кабеля EVSE и. например, сообщает EVSE. зафиксирован ли кабель на стороне EV и о готовности EV к зарядке.

[V2G2-249J В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 49.

CabteCheckRaqType

CabteCheckReq 3 DC_B/Statua

Рисунок 49 — Диаграмма — CabteCheckReq

[V2G2-250] Элементы данного сообщения должны использоваться, как определено в таблице 51.

Таблица 51 — Семантика и определение типа для CabteCheckReq

Имя элемента

Тил

Семантика

DC.EVStatus

comptexType:

ОС EVStatusType см. 8.5.4.2

Актуальное значение тока зарядки EV

8.4.5.2.3 CableCheckRes

SECC после получения CabteCheckReq от EVCC посылает CableCheckRes, информируя EVCC о результатах проверки кабеля и статусе EVSE.

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

CabteCheekResType

|— "ResponseCode | — =EVSS’roceeeing

CableCheckRes


ОС BZSEStatue


Рисунок 50 — Диаграмма — CableCheckRes

[V2G2-252J Элементы данного сообщения должны использоваться, как определено в таблице 52.

Таблица 52 — Семантика и определение типа для CableCheckRes

Имя элемента

Тип

Семантика

EVSEPracessing

simpleType:

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

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

ResponseCode

simpleType:

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

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

Окончание таблицы 52

Имя элемента

Тип

Семантика

DC.EVSEStatus

comptexType:

ОС EVSEStatusType см.8.5.4.1

Актуальное значение тока зарядки EVSE

Примечание — С помощью параметра EVSEProcessing EVSE может показать EVCC. что обработка не завершилась, но сообщение-ответ должно быть отправлено для выполнения требований по тайм-ауту и производительности. изложенных в 8.7.2. Это позволяет продолжить сеанс связи с выполнением требований по производительности и тайм-ауту.

8.4.5.3 PreChargeReq/Res

8.4.5.3.1 Обработка PreChargeReq/Res

Предэарядка используется для адаптации выходного напряжения EVSE к напряжению аккумуляторной батареи EV.

8.4.5.3.2 PreChargeReq

PreChargeReq используется для запуска процесса предэарядки со стороны EV.

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

PreChargeReqType

!— ОС EVStatue

PreChargeReq ■3~~( “ EVTargetVoltage

— -^VTargetCurrent^J

Рисунок 51 — Диаграмма — PreChargeReq

(V2G2-254) Элементы данного сообщения должны использоваться, как определено в таблице 53.

Таблица 53 — Семантика и определение типа для PreChargeReq

Имя элемента

Тил

Семантика

DC_EVStatus

comptexType:

ОС EVStatusType см. 8.5.4.2

Актуальное значение тока зарядки EV

EVTargetVoltage

comptexType:

PhysrcalValueType см. в.5.2.7

Целевое напряжение, запрошенное EV

EVTargetCurrent

comptexType:

PhystcalVblueType см. в.5.2.7

Ток. запрошенный EV

8.4.5.3.3 PreChargeRes

SECC после получения PreChargeReq от EVCC посылает PreChargeRes. информируя EV о статусе EVSE и текущем выходном напряжении EVSE.

[V2G2-255] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 52.

PreChargeResType

PreChargeRes

ReaponaeCode

DC B/SEStatua

— B/SB^eeentVoltage ф

Рисунок 52 — Диаграмма — PreChargeRes

[V2G2-256} Элементы данного сообщения должны использоваться, как определено е таблице 54.

Таблица 54 — Семантика и определение типа для PreChargeRes

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

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

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

DC.EVSEStatus

comptexType:

DC EVSEStatusType cm.8.5.4.1

Актуальное значение тока зарядки EVSE

EVSEPresentVoltage

comptexType:

PhystcalVBIueType cm. 8.5.2.7

Выходное напряжение EVSE по /9/

8.4.5.4 CurrentDemandReq/Res

8.4.5.4.1 Обработка CurrentDemandReq/Res

Для управления зарядкой постоянным током EV требуется периодически передавать запрашиваемый ток. Также передаются целевое напряжение и разница (между целевыми и фактическими значениями) тока и напряжения.

8.4.5.4.2 CurrentOemandReq

С помощью сообщения CurrentOemandReq EV запрашивает определенный ток у EVSE. Также передаются целевое напряжение и разница (между целевыми и фактическими значениями) тока и напряжения.

[V2G2-257] В зависимости от еыбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

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

вт

CurrentDamandFfcqType

DC В/Status — B/TargetCurrent

i —

■ ' EVMaxImumVoftageLimit [Й B/MaximumCurrentLimrt j+J

EVMaximumPowtrLimtt

CurrentOemandRaq


BuikCtiargingComptete !

—|^Ch»rgingCf>mpkita|

RemainingTimeToFultSoC

R»mainingTirneToBulkSoCj£j —f B/TargetVottage

Рисунок 53 — Диаграмма — CurrentOemandReq

[V2G2-258J Элементы данного сообщения должны использоваться, как определено в таблице 55. Таблица 55 — Семантика и определение типа для CurrentOemandReq

Имя элемента

Тип

Семантика

DC.EVStaius

comptoxType:

DC EVStatusType см. 8.5Л.2

Актуальное значение тока зарядки EV

EVTargetCurrent

comptoxType:

PhysicalVaiueType cm. 8.5.27

Ток. запрашиваемый EV е данный момент времени

EVMaximumVoitagebmit

comptoxType:

PhystoalVaiueType cm. 8.5.27

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

максимальное напряжение, допускаемое EV

EVMaximumCurrentbmit

comptoxType:

PhystoalVaiueType cm. 8.5.27

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

максимальный ток. допускаемый EV

EVMaximumPowerbmit

comptoxType:

PhysicalValueType cm. 8.5.27

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

максимальная мощность, допускаемая EV

BuffcCbargingComplete

simpleType

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

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

если установлено значение True, то EV сообщает. что основная зарядка (ствпек» заряда около 80 %) завершена

ChargingComptete

simpleType:

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

Если установлено значение True. EV сообщает, что полная зарядка (степень заряда 100 %) завершена

Окончание таблицы 55

Имя элемента

Тип

Семантика

RemainingTimeToFullSoC

comptoxType:

PhysicalValueType cm. 8.5.2.7

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

оценочное или рассчитанное время до выполнения полной зарядки (степень заряда 100 %)

RemanngTaneToBtASoC

comptoxType

PhysicalValueType cm. 8.5.2.7

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

оценочное или рассчитанное время до выполнения основной зарядки (степень заряда 80 %>

EVTargetVoltage

comptoxType

PhysicalVblueType cm. 8.5.2.7

Целевое напряжение, запрашиваемое EV

8.4.5.4.3 CurrentDemandRes

SECC после получения CurrentOemandReq от EVCC посылает CurrentDemandRes, информируя EV о статусе EVSE и текущих выходных значениях напряжения и тока.

[V2G2-259} В зависимости от выбранного(ых) набора(св) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать сообщения и элементы сообщений, как опрв-делено в таблице 104 и в соответствии с рисунком 54.

CurrentDemandRssType

— “ResponeeCode

DC EVSEStatus

— ^/SffresentVoHag^^ £


— BfSS’resentCurrent


— EVSECurrentLimltAchieved

’ EVSBfoitageLim KAchleve d

^urrentDemandRe^^—


— “BTSB’owerLimltAchieved


BTSBVaxlm um Voltage Um it


BFSEMaximumCurrentLimit A

■«' BfSMaximumPowerLimit

"EVSBD

SAScheduteTupletC

Meterlnfo

ReceiptRequired

Рисунок 54 — Диаграмма — CurrentDemandRes

[V2G2-260] Элементы данного сообщения должны использоваться, как определено в таблице 56.

Таблица 56 — Семантика и определение типа для CurrentOemandRes

Имя элемента

Тип

CeuaMTxia

ResponseCode

simpleType:

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

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

DC.EVSEStatus

comptoxType:

DC EVSEStatusType см. 8.5.4.1

Актуальное значение тока зарядки EVSE

EVSEPresentVoltage

comptoxType:

PhysicaMilueType см. 8.5.2.7

Текущее выходное напряжение EVSE.

См. таблицу сопоставления SAE — ИСО’

EVSEPresentCurrenl

comptoxType:

PhysicalVblueType cm. S.5.2.7

Текущий выходной ток EVSE.

См. таблицу сопоставления SAE — ИСО*

EVSECurrentbmit

Achieved

simpleType

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

Если установлено значение True. EVSE достигло своего предела по току

EVSEVollagebmit

Achieved

simpleType

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

Если установлено значение True. EVSE достигло своего предела по напряжению

EVSEPowerbmit

Achieved

simpleType

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

Если установлено значение True, EVSE достигло своего предела по мощности

EVSEMaximum Voltage Limit

comptoxType:

PhysicalVblueType см. 8.5.2.7

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

максимальное напряжение EVSE

EVSEMaximumCurrent

Limit

comptoxType:

PhysicalVblueType см. в.5.2.7

Факультативно: максимальный ток EVSE

EVSEMaximumPower

Limit

comptoxType:

PhysicalVblueType см. 8.5.2J

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

максимальная мощность EVSE

EVSEID

simpleType: evselDType SessionlDType: hexBinary (макс, длина: 32) см. определение типа в F.6 (приложение F)

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

SAScheduieTuplelO

simpleType:

SAlDType short

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

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

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

SAScheduieTuple на протяжении сеанса зарядки. Используется SECC для указания тарифа который применяется в настоящее время. Идентификатор SA(SAID) остается уникальным идентификатором для одного графика в течение сеанса зарядки

Окончание таблицы 56

Имя элемента

Тип

Сеыаигим

Melerlnfo

comptexType: MeterlntoTypa см. 8.5.2.6

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

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

ReceiptRequired

simpleType

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

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

этот элемент используется SECC для отправки сообщения MeteringReceipIReq с целью подписания записи прибора учета. Если ReceiptRequired равно True, от EVCC запрашивается отправка сообщения MeteringReceiptReq. включая подпись. Если ReceiptRequired равно False, от EVCC не требуется отправлять сообщение MeteringReceiptReq

* Таблица сопоставления SAE — ИСО приведена в приложении 1.

8.4.5.5 WeldingDetectionReq/Res

8.4.5.5.1 Обработка WeldingDetecbonReq/Res

Сообщения об определении сваривания контактов, описанные е настоящем пункте, позволяют реализовать механизм определения сваривания контактов, как описано в [9].

8.4.5.5.2 WeidingDetectionReq

С помощью сообщения WeidingDetectionReq EV запрашивает определение сваривания контактов на EVSE.

[V2G2-261] В зависимости от еыбракного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 55.

WekUngDetecUonReqType

WeidingDetectionReq h-j DC_B/Statue_^]

Рисунок 55 — Диаграмма — WeidingDetectionReq

[V2G2-262) Элементы данного сообщения должны использоваться, как определено в таблице 57.

Таблица 57 — Семантика и определение типа для WeidingDetectionReq

Имя элемента

Тип

Семантика

DC.EVStatus

comptexType:

DC EVStatusType см.8.5.4.2

Актуальное значение тока зарядки EV

8.4.5.5.3 WeldingDetectionResponse

SECC после получения WeidingDetectionReq от EVCC посылает Welding DetectionResponse, информируя EV о статусе EVSE и текущем выходном напряжении EVSE.

[V2G2-263] В зависимости от еыбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать обязательные сообщения и элементы сообщений. как определено в таблице 104 и в соответствии с рисунком 56.

WetdingDeteetionReeType

ResponseCode

WeldingDetectionRes —( «— --DC_EVSEStatU8

EVSEPresentVoltagB ф

Рисунок 56 —Диаграмма — WeklingDetectionRes

[V2G2-264] Элементы данного сообщения должны использоваться, как определено в таблице 58. Таблица 58 — Семантика и определение типа для WeklingDetectionRes

Имя элемента

Тип

Семантика

ResponseCode

simpleType:

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

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

DC.EVSEStatus

comptoxType:

DC EVSEStatusType cm. 8.5.4.1

Актуальное значение тока зарядки EVSE

EVSEPresentVoltage

comptoxType:

PhysicalVblueType cm. S.5.2.7

Текущее напряжение EVSE, см. выходное напряжение SAE

8.5 Комплексные типы данных

8.5.1 Обзор

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

8.5.2 Общие сведения

8.5.2.1 ServtceType

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

[V2G2-265} В зависимости от еыбранного(ых) набора(ов) сообщений, олисанкого(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 57.

kelD^


ServicelD


Service Name

--^Service CaUqoryJ

Service Scope ЛЬАв.......

FreeSe rvice

Рисунок 57 — Диаграмма — ServiceType

[V2G2-266] Элемент сообщений должен использоваться, как определено в таблице 59. Таблица 59 — Семантика и определение типа для ServiceType

Имя элемента

Тип

Семантика

ServrceiO

simpleType: unsignedShort см. определение типа a F.6 (приложение F)

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

ServiceName

simpleType: service NameType цепочка (макс, длина: 32) см. определение типа в F.6 (приложение F)

Факультативно: удобочитаемое имя сервиса

ServiceCategory

simpleType:

serviceCategoryType enumeration см. определение типа a F.6 (приложение F,

Категория сервиса соответствует определенным сервисам, полученным из базовых сервисов

ServiceScope

simpleType: serviceScopeType цепочка (макс, длина: 64) см. определение типа a F.6 (приложение F)

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

дополнительная информация об использовании данного сервиса

FreeService

simpleType

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

Элемент используется SECC для указания, может или нет EVCC использовать данный сервис бесплатно. Если FreeService равно True. EV может использовать предлагаемый сервис бесплатно. Если FreeService равно False, сервис, если он используется EV. будет оплачиваться с помощью метода оплаты, согласованного с помощью элемента сообщения PaymentOptionListType

8.5.2.2 ServiceListType

[V2G2-267] В зависимости от еыбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 58.

ServiceListType

Рисунок 58 — Диаграмма — ServiceListType

[V2G2-268J Элемент сообщений должен использоваться, как определено в таблице 60. Таблица 60 — Семантика и определение типа для ServiceListType

Имя элемента

Тип

Семантика

Service

compiexType:

ServiceType

Содержит всю информацию для идентификации сервиса. ServrceList включает не менее одного сервиса и может включать до восьми сервисов

8.5.2.3 ChargeServiceType

Данный тип — это конкретный сервис по зарядке EV. производный от ServiceType (см. 8.5.2.1). содержащий дополнительную информацию о SupportedEnergyTransferMode(s). предлагаемых EVSE.

[V2G2-271J В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 59.


[V2G2-272) Элемент сообщений должен использоваться, как определено в таблице 61. Таблица 61 — Семантика и определение типа для ChargeServiceType

Имя элемента

Тип

Сенемтмка

ServtceType (extension}

compiexType:

ServiceType

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

e 8.5.2.1

Этот набор элементов сообщений перечислен в ServiceType, См. описание семантики данных элементов сообщений в таблице 59

SupportedEnergyTransfer Mode

compiexType

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

Имеющиеся режимы передачи энергии, которые поддерживает EVSE

Определение и использование EnergyTransferModeType в SupportedEnergyTransferModeType поддерживают разъемы типа 1.2 и 3 в соответствии с ГОСТ Р МЭК 62196-2 и разъемы в соответствии с (49).

8.5.2.4 SupportedEnergyTransferModeType

[V2G2-7571 В зависимости от выбранного(ых) набора(ов) сообщений, олисанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 62 и в соответствии с рисунком 60.

^SupportedEnergyTransferModeType

^EnergyTranaferMode


Рисунок 60 — Диаграмма — SupportedEnergyTransferModeType

(V2G2-758J Элемент сообщения должен использоваться, как определено в таблице 62.

Таблица 62 — Семантика и определение типа для SupportedEnergyTransferModeType

Имя элемента

Тип

Семеитми

EnergyTransferMode

simpleType:

EnergyTransferModeType

enumeration

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

Режим передачи энерпли для зарядки, который поддерживается SECC.

См. подробности в таблице 63. Максимальное вхождение 6

[V2G2-759] EVCC и SECC должны использовать EnergyTransferModeType, какописано в таблице 63. Таблица 63 — Семантика для EnergyTransferModeType

EneigyTransteiModo

Предлагаемый зарядный сервис

AC_single_phase_core

Зарядка однофазным переменным током в соответствии с ГОСТ РМЭК 62196-1. ГОСТ Р МЭК 62196-2 и (49)

AC_three_phase_core

Зарядка трехфазным переменным током в соответствии с ГОСТ РМЭК 62196-1, ГОСТ Р МЭК 62196-2 и (49)

DC_core

Зарядка постоянным током в соответствии с ГОСТ Р МЭК 62196-1. ГОСТ Р МЭК 62196-2 и (49) через основные контакты

OC_extended

Зарядка постоянным током с использованием дополнительных контактов разъемов конфигурации ЕЕ или FF по (49)

DC_combo_core

Зарядка постоянным током с использованием основных контактов конфигурации ЕЕ или FF по (49)

DC_unique

Зарядка постоянным током с использованием специального разъема для постоянного тока

Примечание — SECC может обеспечивать несколько вариантов услуг по зарядке. В зависимости от данных опций EVCC должен выбрать одну из предлагаемых опций. Например, если EVSE предлагает AC_sing1e_phase_core и DC_core. EVCC должен выбрать либо AC_singfe_phase_core. либо ОС.соге. потому что обе опции одновременно не могут технически поддерживаться (см. EnergyTransferModeType. F.6 {приложение F)].

8.5.2.5 CertificateChainType

Этот тип данных сохраняет сертификат клиента и все сертификаты в цепочке. Корневой сертификат не входит в этот тип данных. В особом (маловероятном) случае сертификат клиента подписывается непосредственно корнем, поле «SubCertificates» остается пустым. Во всех других случаях это попе содержит запрошенный слиоок сертификатов Sub-CA-certificates для прослеживания пути от сертификата клиента до корня.

[V2G2-274J В зависимости от еыбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и е соответствии с рисунком 61.

Рисунок 61 — Диаграмма — CertificateChainType

[V2G2-275] Элемент сообщения должен использоваться, как определено в таблице 64.

Таблица 64 — Семантика и определение типа для CertificateChatnType

Имя элемента

Тип

Сеыамтиы

W

simpleType: ID цепочка

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

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

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

Certificate

simpleType:

certificateType

SessionlDType: hexBinary (макс, длина: 800} см. определение типа a F.6 (приложение F)

Сертификат x.509v3 («клиентский» сертификат). Сертификат, кодированный по правилам DER

SubCertrficales

comptexType:

SubCertificatesType см. 8.5.2.26

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

цепочка со всеми субсертификагами до корневого сертификата (исключая корневой сертификат)

8.5.2.6 MeterlnfoType

[V2G2-276] В зависимости от еыбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 62.

J MeterReading !+] ^MeterlnfoTy^---'^igMeterReadktgJj

*£]


- *'~MeterStatus


Рисунок 62 —Диаграмма — MeterlnfoType

[V2G2-277] Элемент сообщения должен использоваться, как определено в таблице 65.

Таблица 65 — Семантика и определение типа для MeterlnfoType

Имя элемента

Тип

Сеыамтим

MeterlD

simpleType: meterlDType цепочка (макс, длина: 32) см. определение типа в F.6 (приложение F)

Идентификатор прибора учета EVSE

MeterReading

simpleType:

unsignedtong

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

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

текущее показание прибора учета EVSE в ватт-часах

Окончание таблицы 65

Имя элемента

Тип

Сеыаигим

S+g MeterReading

simpleType:

sigMeterReadmgType

SessionlDType: hexBinary (макс, длина: 64) см. определение типа е F.6 (приложение F)

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

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

MeterStatus

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

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

текущее состояние прибора учета. Определение содержания MeterStatus не входит в область применения настоящего стандарта. Это содержание может быть определено оператором EVSE или электросетью

TMeter

simpleType: short

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

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

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

метка текущего времени прибора учета в формате метки времени системы Unix

[V2G2-830] При обработке элемента сообщений MeterReading SECC и EVCC должны применять базовую единицу измерения ватт-час (Втч).

[V2G2-831] При использовании элемента сообщений MeterReading SECC и EVCC должны применять определение диапазона значения в соответствии с таблицей 66.

Таблица 66 — Определение диапазона значения элемента сообщения MeterReading

Имя элемента

Условное

обозначение

единицы

Единица

физической

величины

Минимальное

значение

Максимальное

значение

MeterReading

Wh

ватт-час

0

999.999.999

8.5.27 PhysicalValueType

[V2G2-278] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 63.

PhysicalValueType — j

)—1

“Multiplier |

"Unit |

Р

' Value Ь

Рисунок 63 — Диаграмма — PhysicalValueType

[V2G2-279] Элемент сообщения должен использоваться, как определено в таблице 67. Таблица 67 — Семантика и определение типа для PhysicalValueType

Имя элемента

Тип

Семантика

Multiplier

simpleType: unitMultiplierType байт (диапазон: -3...+3) см. определение типа в F.6 (приложение F)

Множитель определяет показатель степени для основания 10 (десять). Окончательная физическая величина определяется выражением: Значение ’ 10 А Множитель (в единицах измерения]

Окончание таблицы 67

Имя элемента

Тип

Семантика

Unit

simpleType:

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

Единица измерения физической величины

Value

simpleType:

short

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

Значение, которое должно быть умножено

[V2G2-832} Для всех элементов сообщений типа PhysicalValueType SECC и EVCC должны применять диапазон значений и определение единиц измерения в соответствии с таблицей 68.

Таблица 68 — Диапазон значений и определение единиц изменения для элементов сообщений, использующих PhysrcalValueType

Имя элемента

Обозначение

типа величины

Наименование

единицы

измерения

физической

величины

Минимальное

значение

Максимальное

значение

ChargingProfileEntryMaxPower

W

ватт

0

200 000

Eamount

Wh

ватт-час

0

200 000

EVEnergyCapacrty

Wh

ватт-час

0

200 000

EVEnergyRequest

Wh

ватт-час

0

200 000

EVMaxCurrent

A

ампер

0

400

EVMaximumCufrentLsmit

A

актер

0

400

EVMaximumPowerlimft

W

ватт

0

200 000

EVMaximumVoitageLimit

V

вольт

0

1000

EVMaxVoitage

V

вольт

0

1000

EVMinCurrent

A

ампер

0

400

EVSECurrentRegulabonToleranoe

A

ампер

0

400

EVSEEnergyToBeDelivered

Wh

ватт-час

0

200 000

EVSEMaxCurrent

A

ампер

0

400

EVSEMaximumCurrentLimit

A

ампер

0

400

EVSEMaximumPowerLimil

W

ватт

0

200 000

EVSEMaximumVoltageLimit

V

вольт

0

1000

EVSENominalVollage

V

вольт

0

1000

EVSEMrnimumCurrentLimit

A

ампер

0

400

EVSEMinimumVottageLimit

V

вольт

0

1000

EVSEPeakCurrentRippie

A

актер

0

400

EVSEPresentCurrent

A

ампер

0

400

EVSEPresentVoltage

V

вольт

0

1000

Окончание таблицы 68

Имя элемента

Обозначение

типа величины

Наименование

единицы

измерение

физической

величины

Минимальное

значение

Максимальное

значение

EVTargetCurrent

А

ампер

0

400

EVTargetVoltage

V

вольт

0

1000

Ртах

W

ватт

0

200 000

RemainingTimeToBulkSoC

S

секунда

0

172800

RemainingTimeToFullSoC

S

секунда

0

172800

siartValue

W

ватт

0

200 000

8.S.2.8 NotificationType

[V2G2-280J Этот необязательный элемент сообщения включен а заголовок сообщения V2G и по* зволяет уведомить принимающее устройство о синтаксической ошибке анализа или любой другой ошибке, связанной с расшифровкой сообщения V2G. Элемент сообщения должен быть реализован в соответствии с рисунком 64.


Fault Cod»


Рисунок 64 —Диаграмма — NotificationType

[V2G2-281] Элемент сообщения должен использоваться, как определено в таблице 69. Таблица 69 — Семантика и определение типа для NotificationType

Имя элемента

Тип

Семантика

FauItCode

simpleType:

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

Определяет ошибку синтаксического анализа или какую-либо другую ошибку, относящуюся к декодированию сообщения V2G

FaultMsg

simpleType:

цепочка (макс, дгына: 64) см. определение типа в F.6 (приложение F)

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

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

8.S.2.9 PaymentOptionListType

[V2G2-282] В зависимости от еыбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 65.

^PaymentOptionListType ~Р»УтentOptton

1.2

Рисунок 65 — Диаграмма — PaymentOptionListType

[V2G2-283J Элемент сообщений должен использоваться, как определено в таблице 70. Таблица 70 — Семантика и определение типа для PaymentOptionListType

Имя элемента

Тип

Семантика

PaymentOption

simpleType:

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

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

8.5.2.10 ChargingProfileType

[V2G2-284] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 66.

^ChargingProfileType ■— ProfileEntry Гь|

1..»

Рисунок 66 — Диаграмма — ChargingProfileType

[V2G2-606] Элемент сообщения должен использоваться, как определено в таблице 71. Таблица 71 — Семантика и определение типа для ChargingProfileType

Имя элемента

Тил

Семантика

ProfileEntry

complexType:

ProfileEntryType см. 8.5.2.11

Элемент, используемый для формирования записи индивидуального профиля зарядки. Число сервисных элементов ProfileEntry ограничивается восемью

8.5.2.11 ProfileEntryType

[V2G2-288] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 67.

—I ChargingProfileEntryStart

^ProfileEntryType — ChargingProtlleEntryMaxPower

ChargingProfileEntryMaxNumberOfPhasesInUee

мвмммвмммммсс-- - —

Рисунок 67 — Диаграмма — ProfileEntryType

[V2G2-607] Элемент сообщения должен использоваться, как определено в таблице 72. Таблица 72 — Семантика и определение типа для ProfileEntryType

Имя элемента

Тип

Семантика

ChargingProfileEntryStart

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

Время, когда chargingProfiteEntry начинает действовать. Сдвиг в секундах от настоящего момента времени

Окончание таблицы 72

Имя элемента

Тип

Семантика

ChargingProfileEntryMax

Power

comptexType:

PhysicalVaiueType см. 8.5.2.7

Максимальная мощность в ваттах, потребляемая EV в рамках текущей записи профиля зарядки (начиная от ChargingProfiieEntryStart)

ChargingProfileEntryMax

NumberOfPhasesInUse

simpleType: byte (мин. значение: 1; макс, значение: 3) см. определение типа в F.6 (приложение F)

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

этот элемент используется EV для указания максимального количества фаз. которые будут использоваться в течение периода, определенного ChargingProfiieEntryStart. этого ProfileEntry

[V2G2-289] Значение элемента ChargingProfiieEntryStart должно определяться как точка во времени. когда элемент ProfileEntryType становится активным.

[V2G2-290] Значение элемента ChargingProfiieEntryStart в списке элементов ProfileEntryType должно определяться моментом времени, когда элемент ProfileEntryType становится неактивным.

Примечание 1 — [V2G2-289] и (V2G2-290] определяет период времени, в течение которого элемент ProfileEntryType активен

[V2G2-291] Последний элемент в списке элементов типа ProfileEntryType активен до обновления списка в соответствии с [V2G2-305].

[V2G2-292] Значение элемента ChargingProfileEntryMaxPower должно определяться как максимальная мощность в ваттах, потребляемая EV в течение активного периода элемента типа ProfileEntryType.

[V2G2-293] Значения элемента ChargingProfileEntryMaxPower должны быть равны или меньше, чем предельные значения в соответствующих элементах PMaxScheduleType (см. 8.5.2.14), которые даны в сообщении ChargeParameterDiscoveryRes.

[V2G2-829] Если EV может определить количество фаз. которое будет использоваться в течение отдельного интервала времени (ChargingProfiieEntryStart). EVCC должен указать для каждого интервала времени максимальное количество фаз. которое он намерен использовать в данный интервал времени, путем использования параметра ChargingProfileEntryMaxNumberOfPhasesInllse.

Примечание 2 — Информация об использовании фаз в определенный интервал времени может быть учтена SECC для оптимизации распределения энергии по имеющимся фазам.

8.5.2.12 SAScheduleListType

(V2G2-294] В зависимости от выбранного(ых) набора(ов) сообщений, описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 68.

^SAScheduleListType —SAScheduleTuple^^ 1..3

Рисунок 68 — Диаграмма — SAScheduleListType

[V2G2-608] Элемент сообщения должен использоваться, как определено в таблице 73. Таблица 73 — Семантика и определение типа для SAScheduleListType

Имя элемента

Тип

Семантика

SAScheduleT uple

comptexType:

SAScheduleT upleType см. 8.5.2.13

Включает несколько кортежей трафиков от SA. Число сервисных элементов SAScheduleTuple ограничивается тремя

[V2G2-296] EVCC может реализовать механизм для сравнения различных элементов SAScheduleTupIe с целью оптимизации графика зарядки с учетом любой конкретной стоимости в соответствии с [V2G2- 803] и [V2G2-337]

[V2G2-297] Первый элемент SAScheduleTupIe в SAScheduIeListType должен определяться как SASchedule по умолчанию.

[V2G2-298] Если EVCC не способен сравнивать различные элементы SAScheduleTupIe или сравнение не удается. EVCC должен выбрать SAScheduleTupIe в соответствии с (V2G2-297].

8.5.2.13 SAScheduIeTupleType

[V2G2-299] В зависимости от выбранного(ых) набора(ов) сообщений. описанного(ых) в 8.6.2.

EVCC и SECC должны реализовывать данный тип. как определено в таблице 104 и в соответствии с рисунком 69.

"SAScheduleTupletO

— PMaxSchedule

SaiesTariff

Рисунок 69 — Диаграмма — SAScheduIeTupleType

[V2G2-609] Элемент сообщения должен использоваться, как определено в таблице 74. Таблица 74 — Семантика и определение типа для SAScheduIeTupleType

Имя элемента

Тип

Секемтмка

SAScheduleTupielD

simpleType:

SAlDType

unsignedByte

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

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

PMaxSchedule

complexType:

PMaxScheduleType см. 8.5.2.14

Инкапсулирующий элемент, описывающий все релевантные детали для одного PMaxSchedule crrSA

SaiesTariff

complexType:

SatesTariffType cm. 8.5.2.16

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

инкапсулирующий элемент, описывающий все релевантные детали для одного SaiesTariff от SA

(V2G2-773] SECC должен использовать значения 1—255 для параметра SAScheduleTupielD. [V2G2-300] Элемент SAScheduleTupielD должен быть уникальным среди всех элементов

SAScheduleTupIe в SAScheduIeListType и уникально идентифицировать кортеж эле* ментов PMaxSchedule и SaiesTariff во время всего сеанса зарядки.

[V2G2>301] SECC должен предоставлять элемент PMaxSchedule на основе предельных параме* трое локальной инфраструктуры, если ни один из SA не предоставляет график элек* ipuueTH.

[V2G2-303] Сумма индивидуальных интервалов времени, описанных в PMaxSchedule (см. 8.5.2.14) и SaiesTariff (см. 8.5.2.16). которая дана в сообщении ChargeParameterDiscoveryRes. должна соответствовать периоду времени, указанному EVCC в элементе DepartureTime сообщения ChargeParameterDiscoveryReq.

(V2G2-304] Если EVCC не дал целевую настройку DepartureTime (см. 8.4.3.8.2 и 8.5.3.2) в со* общении ChargeParameterDiscoveryReq. сумма индивидуальных интервалов времени, описанных в PMaxSchedule и SaiesTariff. которые даны в сообщении ChargeParameterDiscoveryRes, должна быть больше или равна 24 ч.



96