Товары в корзине: 0 шт Оформить заказ
Стр. 1 

341 страница

Купить ГОСТ Р 58123-2018 — бумажный документ с голограммой и синими печатями. подробнее

Цена на этот документ пока неизвестна. Нажмите кнопку "Купить" и сделайте заказ, и мы пришлем вам цену.

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

 Скачать PDF

Содержит требования ISO 15118-2:2014

Оглавление

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

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

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

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

5 Понятия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение H (справочное) Задание последовательности сообщений для пересогласования

Приложение I (справочное) Привязка имен элементов сообщений ISO 15118 к терминам SAE J847/2

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

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

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

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

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

 
Дата введения01.06.2019
Добавлен в базу01.02.2020
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

02.10.2018УтвержденФедеральное агентство по техническому регулированию и метрологии688-ст

Road vehicles. Vehicle-to-Grid Communication Interface. Part 2. Network and application protocol requirements

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

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

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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

58123—

2018

(ИСО 15118-2: 2014)

ТРАНСПОРТ ДОРОЖНЫЙ

Интерфейс связи автомобиль — электрическая сеть

Часть 2

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

(ISO 15118-2:2014, MOD)

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

Москва

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

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 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

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

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

II

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

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

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

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

7.2.1 Обзор

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

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

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

Сущность V2G m


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


PDU — блок протокольных данных сетевого объекта.

PCI — информация управления протоколом;

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

л

X

ф

о

о

о.

>

ф

т

о

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

Когда экземпляр m субъекта V2G уровня i+1 обменивается данными с экземпляром т+1 субъекта V2G уровня 1+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 показана только с целью информации и не служит для установления конкретной последовательности сообщений.

ГОСТ P 58123—2018


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

ИЯ*М1ИфикацйМ. ay f ом t ификациэ* и аяюриыцим


PnwtOfO-HAegO


*ay*re«tl>etebA*i<)

Autho'i/et-o'Aean


<-----------------


Нсоб.одим сертификат контракта с ключом и цепочкой


AulhO'uaitor^atO


<-----------------


СП. U

1 .


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


Отправление квитанции (только дли РпС) /

1

к

Необходим

корпело*

Y (полу*) онлайновый обмен пописанными ^ ■ аитакциям прибора учета дли профиля зарядки а режиме (не рассматрмаается

сертификат

контракта

а настоящем стандарте)


%


£


CVCC

1

1

ЯСС

1

1

Нгмло прочксд мрядки у

Ус«*ио*и сниш У

1

1

1

1


В<Сфмчм»м сувк*»" (SA)


Уствисмд соединения ма б«м IP J

1

1


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


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

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

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

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

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

[V2G2-004] Каждый субъект 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, приведена в 16].

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

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

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

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

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

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

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

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

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

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

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

7.3.3 Число корневых сертификатов и срок их действия, глубина и размер сертификата

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[V2G2-869] СА или 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-868] Для частной среды органы Sub-CA и ответы OCSP не поддерживаются.

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

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

[V2G2-630] Поддержка 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-633] Если используется сеанс связи без 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 — Поддержка Ивдля идентификационных режимов EIM

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

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

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

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

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

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

ДУ

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

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

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

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

ДУ

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

EVCC

Поддержка

TLS

Факульта

тивно

Факульта

тивно

Обязатель

но

Обязатель

но

Факульта

тивно

Факульта

тивно

Обяза

тельно

Обяза

тельно

SECC

Поддержка

TLS

Обяза

тельно

Обяза

тельно

Обяза

тельно

Обяза

тельно

Факульта

тивно

Факульта

тивно

Обяза

тельно

Обяза

тельно

Согласование использования TLS с ПОМОЩЬЮ SDP6

EV решает.

EVSE

должно

принять

решение

EV

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

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

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

См таблицу 4

См. таблицу 4

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

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

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

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


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

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

Поддержка TLS

EVCC

Поддержка TLS SECC

Запрос SDP EVCC

Ответ SDP от SECC

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

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

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

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

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

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

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

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

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

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

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

EVCC не имеет

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

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

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

поддержки TLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[V2G2-023] EVCC должен прекратить попытки установить соединение с TLS или TCP. когда V2G_EVCC_CommunicationSetup_Timer равен или больше V2G_EVCC_ Communicatk>nSetup_Timeout.

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

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

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

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

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

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

Содержание

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

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

Начало

Нет связи    Нет    канала


Рисунок в — Обзор коммуникационных состояний EVCC


Введение

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

Методики, использованные для разработки настоящего стандарта и для его дальнейшего применения. содержатся в директивах ИСО/МЭК. часть 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: Требования к физическому и канальному уровням.

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

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

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

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

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

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

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

Road vehicles Vehicle-to-Gnd 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— Условие входа: любой действительный сигнал линии управления в соответствии с ГОСТ Р МЭК 61851-1, условие выхода: D-LINK_READY indication(DLINKSTATUS=LinkEstablished)

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

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

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

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

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

Примечание 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 и ChargingProfile.

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

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

3 26 клиент SDP: Субъект 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-UNK_READYindicationDLINKSTATUS=linkEstablished). условие выхода PowerDeliveryReq с 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 — алгоритм цифровой подписи на основе эллиптических кривых;

ЕМАЮ — идентификатор аккаунта EVEV;

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

ЕV — электрическое транспортное средство;

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

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

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

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

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

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

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

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

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

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

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

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

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

SDU — блок сервисных данных;

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”-"XXX")» — текст требования, где:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[    |    —    уровни    OSI    и    применимые    требования,    описанные    а    настоящем    стандарте:

— уровни OSI и применимые требования, описанные в ГОСТ Р 58122 (ИСО 15119-1:2013) и [1J

Рисунок 2 — Обзор связи документов V2G