简介这份ISO 15118-20:2022英文原版标准面向电动汽车充电通信协议开发、车网互动V2G研究与测试认证人员聚焦第二代网络层与应用层要求为不同品牌车辆与充电设施之间的互操作、安全通信和智能电网调度提供统一技术依据。压缩包内共1个文件为标准全文PDF体积约34.74MB内含前言、引言、范围、规范性引用文件、术语与定义、缩略语、OSI服务定义、需求结构说明以及XML架构图等内容可直接检索条款原文。已有161人学习。读者可从中获取身份验证、计费、充电状态监控等应用层服务的规范描述以及数据传输、路由策略与错误检测等网络层机制要求并对照附录梳理实施步骤与测试要点适合协议栈开发、充电标准对标及科研教学时查证引用。1. 先看清一个画面车插上枪之后到底在跟桩聊什么很多人第一次看到 ISO 15118-20-2022 这串编号是在某个充电项目的资料夹里名字写着“车辆与电网通信接口”副标题是第二代网络层和应用层要求2022 年第一版。看着像天书其实它讲的事情特别朴素一根充电枪插上以后车和桩双方先说什么、后说什么、每句话长什么样。你看到的是指示灯变绿看不到的是底下跑着一套网络协议车先喊一嗓子“有人在吗”桩回一句“我在我会讲哪几种话”双方谈妥再交换身份、充电需求、价格、进度。电动汽车充电这件事只要是两家不同厂商的设备对接就得靠同一本剧本来对台词这本剧本就是它。它适合谁刚进充电桩软件组的新人、做车端通信模块的初级工程师、要给对接项目写文档的产品和测试同学。完全零基础也能读因为它本质上是一份写得很细的对话规则不是电路图。2. 为什么要学它一份 2022 年的第二代规则解决的是“充得上”之外的事2.1 “插上就充”听着简单为什么要写成几百页先想一个最朴素的场景你开一辆车去充电站插枪刷卡充电拔枪走人。这套动作在人看来是五步在机器看来是几十条消息来回。第一条消息可能只是“对面有没有人”最后一条消息可能是“这次一共用了多少度电、按什么价格结算”。中间任何一步对不上用户看到的就是“充电失败请重新插枪”。第一代规则能解决“能不能充上”的问题车和桩知道彼此在充电电流电压能对上。但一旦涉及更细的事比如车想告诉桩“我这张证书证明我是谁别让我刷卡”或者桩想告诉车“现在电价是这个数你愿不愿意等到便宜的时候再充”或者车想把电池里的电反向送回去第一代就不够用了。ISO 15118-20 这份第二代规则就是把这些“不够用”的地方补上。它补的方式很工程先把网络分层重新梳理一遍从数据链路层怎么加密无线连接到网络层用哪些 RFC、IP 地址怎么分配到传输层 TCP 和 UDP 各自干什么、TLS 怎么用再到表示层怎么把 XML 压成 EXI 省带宽最后到应用层定义一条条具体的消息长什么样。你可以把它理解成第一代规定了“两个人能对话”第二代规定了“这两个人能用暗号对话、能谈价钱、能签合同、还能中途换话题”。所以学它不是为了背条款是为了在联调现场看到某条报文被拒的时候知道该翻到文档的哪一节去找答案。2.2 第二代多出来的东西身份、价格、反向送电和无线充电从文档目录能很清楚地看出重心在往哪儿移。安全概念这一块占了极大篇幅证书和密钥怎么管、根证书放几个、有效期多长、密钥怎么保护、随机数怎么生成、防火墙怎么设。这些内容在第一代里也有但这一版写得更细因为它要支撑“即插即充”这类体验——车主不用刷卡车自己拿证书证明身份桩验证完直接开始充。再往下是服务选择和通信时序。直流充电被单独拎出来讲从会话建立、到“就绪可充电”这个状态怎么进入都配了时序说明。无线充电也有对应章节讲的是这套消息怎么和另一套充电控制信号保持同步。还有一个容易被忽略但很实用的部分绝对价格示例也就是桩怎么把电价信息准确地告诉车。对新手来说这些内容的价值在于你写代码的时候会碰到一堆状态字段和返回码它们不是随便定的每一个都对应文档里一段场景描述。你读懂场景代码里的分支就写得出来你只抄字段名遇到没见过的返回码就只能干瞪眼。2.3 学了它能对上哪些活说几个具体的。车端做通信模块你要实现的是发起握手、上报充电参数、处理桩返回的响应码桩端做控制单元你要实现的是发现协议应答、协议协商、下发价格和进度测试岗位要搭台架按文档里的时序图造异常场景比如故意在会话中途丢一条消息看对方怎么处理产品岗位写对接文档得知道哪些字段是必填、哪些是双方约定不能凭感觉填。这些岗位有一个共同点都不需要你把整份文档背下来但都需要你在遇到问题时能在三分钟内翻到对的那一页。这就是第 3 章要解决的技能。有一点要提前说清楚这份标准管的是“怎么说话”不管“说得多快”。充电功率、硬件选型、商业模式都不在它的范围内。别指望读完它就会设计充电桩它只保证两台设备能互相听懂。3. 拿到文档先翻哪几页给零基础的一张阅读地图3.1 前四章别跳术语和缩略语是你的后悔药新手最常见的做法是从第一页开始顺序读读到第五页就被一串缩写淹没了。我的建议正好相反先花二十分钟把术语定义和缩略语这两章扫一遍不求记住只求眼熟。这份文档里大量使用“服务原语”“协议数据单元”“会话”这类词它们在这里的含义和日常聊天里的意思并不完全一样。比如“会话”这个词在文档里指的是从握手成功到断开之间那一段有状态的过程不是一次聊天。再比如“服务原语”它描述的是上下层之间怎么传参数是一种描述方法不是某个具体的函数。这些词你要是按日常理解去读后面所有章节都会歪。第一章讲范围告诉你这份文档覆盖什么、不覆盖什么第二章是规范性引用列了一堆其他文档和网络协议规范你不用现在去读但要知道它们存在因为后面讲网络层参数时会反复提到第五章讲约定包括需求怎么写、XML 示意图怎么画。这几章加起来可能不到二十页但它们是后面几百页的地基。我第一次读这类文档时的血泪经验是跳过术语表省下的十分钟后面要用两个小时补回来。3.2 第七章是骨架从数据链路一路盖到应用层第七章的标题是 V2G 通信的基本要求它是整份文档的骨架而且是按网络分层从下往上写的。读的时候不要平推要带着问题读。先看安全概念那一大块。它讲证书和密钥怎么管、根证书数量和有效期、TLS 怎么支持、防火墙怎么设、密钥怎么保护、随机数怎么生成。这一块内容多但逻辑很顺先有身份才谈得上信任先有信任才敢传数据。你把它当成“充电世界的门禁系统”来理解就行。再看数据链路层和网络层。前者讲无线连接怎么加密后者讲用哪些网络协议规范、有哪些限制、IP 地址怎么分配。这一层对做应用开发的人不是重点但联调时网络不通问题往往出在这儿。然后是传输层TCP 和 UDP 各有一节TLS 单独一大节。这里要建立一个直觉需要可靠送达的消息走 TCP需要快速广播的发现类消息走 UDP。文档里会发现协议那一节用的就是后者。再往上是 V2G 传输协议讲支持的端口和协议数据单元的结构表示层讲 XML 和 EXI 怎么互转、消息怎么加密应用层讲发现协议也就是车怎么在网络上找到桩。这六层读下来你就有了一个完整的纵向视图一条消息从应用层写出来往下包了几层最后从网线或天线出去。顺便说一句端口号这种东西别凭印象填。文档里有专门一节列出支持的端口用哪个、什么时候用去那儿看比我在这儿说任何数字都靠谱。3.3 第八章是血肉消息、时序、错误处理三件套如果说第七章讲的是“路怎么修”第八章讲的就是“车上跑什么货”。这一章分三大块读的顺序建议是消息定义、时序、错误处理。消息定义部分先讲协议握手也就是双方一见面确认“咱们讲第几版、用哪套数据结构”。文档里给了握手序列、请求和响应消息的定义、语义说明还配了示例。这部分建议你对着示例看比看定义快得多。再往下是一条条具体的 V2G 消息从头部定义到请求响应再到复杂数据类型。头部是每条消息都带的东西先把它搞清楚后面所有消息你都能拆成“头 身体”两半来看。时序部分讲的是这些消息按什么顺序发。直流充电单独有一节从会话建立一直讲到可以开始充电。这里有个容易忽略的细节这套消息不是孤立的它还要和另一套充电控制信号保持同步文档里专门讲了同步关系。你在台架上跑的时候如果发现状态机卡住八成是这两边的节奏没对上。错误处理部分是新手最该看、也最容易跳过的。它定义了基本的错误处理概念、返回码怎么用、请求和响应之间必须满足什么顺序要求还给了大量消息序列图。返回码这一节要重点看因为实际联调时你收到的九成异常都是某个返回码而每个返回码对应的问题类型是不一样的。是格式不对、是状态不允许、还是权限不够看码就知道往哪个方向查。3.4 附录不是凑数Schema 和证书配置文件才是干活工具很多人读到附录就停了觉得那是参考材料。恰恰相反附录里有两样东西是你真正动手时会反复打开的一是数据结构定义二是证书配置文件。数据结构定义告诉你每条消息的字段类型、取值范围、必填还是可选。你在写序列化代码的时候这是唯一可信的来源不要靠猜也不要靠抄别人的代码。证书配置文件则规定了证书里每个字段该填什么格式你做即插即充的时候绕不开它。剩下的附录里还有标识符规范、无线充电相关的内容、互操作相关的基础配置、重协商的消息序列、以及测量精度和容差、价格示例。这些不是每个人都要读但知道自己需要的时候去哪儿找比现在硬啃有用得多。4. 第一个能跑的例子一次插枪握手五步走完4.1 第一步先找到对端SECC 发现协议在车能跟桩“谈正事”之前它得先知道桩在哪儿。这一步由发现协议负责文档在应用层那一节专门写了它。你可以把它想成进商场找服务台车在本地网络里喊一声桩听到后回一个应答告诉车自己的地址和一些基本信息车拿到之后才能建立连接。这个环节对新手最不友好的地方是它走的是无连接的传输方式不保证送达所以你在抓包时可能看到车喊了好几次才有人应。这不是 bug是设计如此。你在写测试用例的时候要专门造一个“没人应答”的场景看看超时之后车怎么退出来而不是一直傻等。文档里这一节还会说明发现消息里该带哪些信息、桩怎么组织应答。你在实现的时候只要保证两件事喊话的内容符合规定应答的地址是对的。剩下的细节可以等第一遍跑通再回头抠。提示抓包时如果一条发现消息都看不到先检查网络配置别急着怀疑协议实现。4.2 第二步谈妥“讲哪种话”supportedAppProtocol 握手找到对端以后双方要做的第一件事不是充电而是确认彼此会讲哪几套协议、各自的版本是什么。文档里把这个过程叫协议握手用一对请求和响应消息完成车把自己支持的协议列表发过去桩从中挑一个双方都支持的回给车。这个设计的意义在于兼容。同一台桩可能既要服务新车也要服务老车同一辆车也可能插到不同厂商的桩上。列表加优先级的方式让双方能在没有人工干预的情况下自动选出一个共同语言。握手失败是最常见的第一道坎。失败的表现通常是桩返回一个表示“没有共同协议”的响应码然后会话直接结束。这时候不要怀疑网络去检查两边的协议列表里有没有交集、版本号对不对、优先级有没有配反。4.3 第三步看懂一条 V2G 消息的骨架握手成功之后所有消息都长一个样一个头部加一个身体。头部带的是这次会话的标识和时间戳身体才是具体内容。理解这个结构非常重要因为你在日志里看到的一大坨数据拆开就是这两块。下面是一段示意片段用来展示结构字段名请以你手上那份文档的数据结构定义为准不要直接照抄去生产环境!-- 示意一条 V2G 消息的最小骨架 -- V2G_Message Header !-- 会话标识握手成功时双方约定后续每条消息都带 -- SessionID6A1F0000C3D2/SessionID !-- 时间戳用于判断消息新旧避免处理过期报文 -- TimeStamp2024-05-11T09:30:00Z/TimeStamp /Header Body !-- 身体部分放具体消息这里以协议握手请求为例 -- supportedAppProtocolReq AppProtocol !-- 协议命名空间标识这是哪一套协议 -- ProtocolNamespaceurn:example:v2g:app/ProtocolNamespace !-- 主版本号和次版本号双方靠它判断能不能对上 -- VersionNumberMajor2/VersionNumberMajor VersionNumberMinor0/VersionNumberMinor !-- 数据结构编号与优先级数字越小越优先 -- SchemaID1/SchemaID Priority1/Priority /AppProtocol /supportedAppProtocolReq /Body /V2G_Message这段里有几个点值得单独说。会话标识是后面所有消息的“户口”对不上就会被丢弃时间戳不是给你看的是给对方判断消息是否过期的协议命名空间加版本号是双方判断兼容性的依据优先级决定桩在多个共同支持的协议里挑哪个。把这四个东西记住你再看文档里那一长串消息定义就不会觉得是一堆陌生名词了它们只是同一个骨架换了不同的身体。4.4 第四步用 Python 把报文拆开看看懂了结构接下来做一件很有成就感的事写十几行代码把一条报文里的关键信息读出来。这一步不需要连真实设备拿一段报文样本就能跑。import xml.etree.ElementTree as ET # 读取本地保存的一条报文样本先抓一条或手写一条 with open(sample_v2g.xml, encodingutf-8) as f: raw f.read() root ET.fromstring(raw) # 1) 先取头部会话标识和时间戳用来判断这条报文属于哪次会话 header root.find(Header) print(会话标识:, header.findtext(SessionID)) print(时间戳 :, header.findtext(TimeStamp)) # 2) 再取身体看这次带的是什么类型的消息 body root.find(Body) for child in body: print(消息类型:, child.tag) # 3) 如果是对端支持的协议列表把每个协议的版本和优先级打出来 for proto in child.findall(AppProtocol): major proto.findtext(VersionNumberMajor) minor proto.findtext(VersionNumberMinor) prio proto.findtext(Priority) print(f 协议版本 {major}.{minor}优先级 {prio})这段代码做三件事解析报文、取头部、遍历身体。跑通之后你可以把它改成一个小工具批量读日志文件统计每种消息出现的次数。别小看这个改造联调时你手里有几百条日志人工翻是翻不过来的有个统计脚本能让你一眼看出卡在哪一步。参数上唯一需要注意的是编码。报文里如果有中文或者特殊字符读取时指定 utf-8否则解析会报错。另外实际报文可能带命名空间前缀find的写法要相应调整遇到取不到值的情况先打印整棵树看看结构别急着改代码逻辑。4.5 第五步把五步串成一条线到这儿你已经走完一个最小闭环发现对端、协商协议、看懂消息结构、解析一条报文。这四件事合起来就是一次插枪握手的核心。真实的会话还会继续往下走涉及服务选择、参数配置、充电状态上报、结束结算但那些都是在这个骨架上加消息不是换一套逻辑。建议你第一次跑的时候别急着连真实设备。先用样本报文在自己的电脑上把这套解析跑通再去找台架。顺序反了你会同时面对“协议不懂”和“设备不听话”两个问题排查起来非常痛苦。5. 新手最容易翻车的五个地方现象、原因和补救5.1 报文发出去了对端一直不回现象很典型你这边日志显示消息已发送对面毫无反应等几秒超时退出。原因通常不在应用层。第一种可能是发现阶段就没成功你连的地址压根不是对端第二种可能是端口填错了文档里有专门一节列支持的端口凭印象填是常见错误第三种是传输方式选错发现类消息和无连接的方式才匹配你用了面向连接的通道对方自然收不到。解决办法是分层排查先用最简单的网络工具确认能通再看发现消息有没有应答最后才看应用层消息。别一上来就怀疑协议实现十次里有八次是地址和端口的问题。5.2 证书装好了握手还是被拒现象是证书文件明明放进去了对方仍然返回表示安全相关的错误码。原因往往出在证书内容而不是证书文件本身。文档里有专门的证书配置文件附录规定了每个字段的格式和取值要求。根证书放几个、有效期怎么算、密钥怎么保护这些都有明确说法。你从别处拷来的证书格式可能对内容不符合这份规则。解决办法是拿附录里的配置要求逐项对照尤其是有效期和用途字段。另外要注意密钥保护那一节的要求密钥存放方式不合规验证一样过不去。5.3 XML 和 EXI 混着用对不上现象是你在本地用明文 XML 调得好好的一上真实链路就解析失败。原因在于表示层对消息做了压缩编码双方的编码方式必须一致。文档在表示层那一节专门讲了这套转换关系。你本地调试用的是可读的文本格式实际链路上跑的可能是压缩后的二进制两者看起来完全不同。解决办法是调通之前先确认双方约定的编码方式调试阶段可以让两端都用明文等逻辑跑通再切回压缩格式。切换的时候记得留一份明文日志不然出了问题你连报文内容都看不见。5.4 把时序图当参考会话中途断掉现象是充电进行到一半会话突然结束日志里只有一个表示状态不允许的返回码。原因是顺序要求被当成了建议。文档在消息序列和错误处理那一节写得很清楚哪些消息必须按什么顺序发哪些请求在没有前置条件时不能发。你少发了一条该发的或者多发了一条不该发的对方就会按规则终止会话。解决办法是把时序图打印出来贴在显示器边上每实现一个状态就对着图走一遍。尤其是直流充电那一段会话建立到就绪充电之间的步骤比较多跳步是最常见的翻车点。5.5 只读正文不读附录字段名全靠猜现象是代码能编译报文能发出但对端一直返回格式错误。原因是字段名和类型是猜的。正文讲的是语义和流程具体的字段定义在附录的数据结构定义里。你按自己的理解起名字序列化出来的东西对方当然不认。解决办法只有一条所有字段名从数据结构定义里抄不要自己造。抄完之后用第 4 章那个小脚本验证一遍能把值读出来说明结构是对的。6. 下一步学什么从“读得懂”到“能自己搭一次会话”第一遍读完你大概知道这份文档长什么样了。接下来怎么走我给一条三阶段的路线按顺序来别跳。阶段目标主要看哪几节怎么算过关第一阶段读能把一条报文拆成头和身体说出每个字段干什么术语与缩略语、应用层消息定义、附录数据结构随便给你一条报文你能口述出它属于哪次会话、是什么消息第二阶段拆能对着时序图说出一条完整会话经过哪些状态通信时序、消息序列与错误处理、返回码你能手绘一张从发现到就绪充电的流程图标出每一步失败会怎样第三阶段搭能在台架上跑通一次最小会话并故意制造三种异常安全概念、传输层、发现协议你造的异常能被对端正确拒绝且返回码和文档对得上第一阶段的关键是克制。不要一上来就啃安全概念那一大块那是最厚的部分先放一放。把消息结构吃透你后面读什么都快。第二阶段建议动手画图。文档里的时序图很全但看图和自己画一遍是两回事。画的时候重点标两样东西每步的前置条件、每步失败时的返回码。画完你会发现之前觉得零散的条款其实是一条线。第三阶段才是真正上设备。搭台架之前先把三种异常场景想好一种是对方不回一种是对方回错码一种是对方中途消失。这三种覆盖了绝大多数现场问题你能造出来就能认出来。关于安全那一块我建议放在第二阶段和第三阶段之间补。因为你在搭会话的时候一定会碰到证书和密钥那时候带着具体问题去读比空读效率高好几倍。最后说个习惯。我最早做联调的时候遇到问题就凭记忆翻文档经常翻半天找不到后来强制自己每遇到一个新返回码就在笔记里记下它对应的章节号和触发场景。半年下来那本笔记成了我查得最快的东西比任何搜索都灵。你现在开始记成本很低回报很高。希望帮到你。本文还有配套的精品资源点击获取