ГОСТ Р 58123-2018 (ИСО 15118-2:2014) Транспорт дорожный. Интерфейс связи автомобиль - электрическая сеть. Часть 2. Требования к протоколу сетевого и прикладного уровней
8.2 Определение подтверждения протокола
8.2.1 Последовательность подтверждения
[V2G2-165] | Перед началом обмена сообщениями на уровне приложения между EVCC и SECC должен быть согласован надлежащий протокол прикладного уровня, включая его версию. |
Для согласования протокола между EVCC и SECC осуществляется следующее подтверждение протокола прикладного уровня:
[V2G2-166] | EVCC должен инициировать подтверждение, отправив SECC сообщение supportedAppProtocolReq, как показано на рисунке 17. Это сообщение-запрос дает перечень протоколов зарядки, поддерживаемых EVCC. |
[V2G2-167] | Каждая запись в списке поддерживаемых EVCC протоколов должна включать ProtocolNamespace, VersionNumberMajor и VersionNumberMinor, уникальный SchemaID, динамически назначенный EVCC, и приоритет (Priority) позиции протокола в списке. Приоритет в сообщении-запросе EVCC позволяет EVCC объявить предпочтительный протокол на уровне приложения, где Priority, равный 1, указывает на наивысший приоритет и Priority, равный 20, указывает на низший приоритет. Число протоколов, включенных в сообщение-запрос, ограничивается 20. |
[V2G2-168] | SECC должен отвечать сообщением supportedAppProtocolRes, как показано на рисунке 18, указав протокол, подлежащий использованию при последующем обмене сообщениями EVCC и SECC. |
[V2G2-169] | Сообщение-ответ должно включать ResponseCode и SchemaID протокола/схемы, согласованных в качестве прикладного протокола для последующего сеанса связи. Таким образом, SECC должен выбрать из собственного списка поддерживаемых протоколов протокол с наибольшим приоритетом, имеющийся в списке EVCC. |
[V2G2-170] | SECC должен подтвердить (положительно ответить на) поддерживаемый EVCC протокол, даже если значение VersionNumberMinor в сообщении-запросе EVCC не соответствует VersionNumberMinor поддерживаемого SECC протокола, в то время как VersionNumberMajor совпадает. |
Примечание - Более высокое значение 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, указывая на то, что согласование протокола не было успешным. В этом сценарии ошибки сообщение с ответом не должно включать SchemaID. |
[V2G2-173] | Если успешное согласование протокола не может быть достигнуто, то EVCC не должен инициализировать сеанс связи. |
[V2G2-174] | Данное подтверждение протокола между EVCC и SECC должно выполняться до непосредственного обмена сообщениями на уровне приложения V2G. За исключением незначительных отклонений, в потоке сообщений V2G должен использоваться только набор сообщений, определенный в согласованном протоколе. |
8.2.2 Определение сообщения supportedAppProtocolReq и supportedAppProtocolRes
[V2G2-175] | EVCC и SECC должны реализовывать сообщение и элементы сообщения V2G, как показано на рисунке 17. |
|
Рисунок 17 - Диаграмма - supportedAppProtocolReq