读懂ISO 15118-20：电动汽车充电通信协议与即插即充实践

简介面向电动汽车充电、智能电网研发、测试及标准化人员的 ISO 15118-20:2022 英文标准原文聚焦道路车辆与电网通信接口第二代的网络层与应用层要求可用于协议设计、互操作性验证及充电通信系统开发对照。压缩包内共 1 个 PDF 文件大小约 34.74MB完整收录标准正文涵盖术语定义、OSI 服务约定、需求结构、XML 模式图示以及网络层、应用层相关规范便于按章节查阅。标准正文中的范围、规范性引用、缩略语和需求条目层级清晰能帮助快速定位充电服务、通信安全、错误检测与路由策略等条款。已有 161 人学习适合需要核对官方条款的工程师、测试人员与高校研究者。读者可据此梳理 V2G 通信的架构边界、身份验证与计费服务要求、安全与互操作思路并作为开发自测、方案评审和标准培训的案头参考。1. 汽车充电也有“网络协议”一句话看懂 ISO 15118-20给电动汽车充电外行看是插枪、扫码、等灯变绿三件事实际上在电流真正灌进电池之前车和充电桩已经隔着电缆来回聊过好几轮了。它们用的这套网络协议叫 ISO 15118而 ISO 15118-20:2022 是它的第二代官方全称是《道路车辆 车辆与电网通信接口 第 20 部分第二代网络层与应用层要求》。一句话定义它是车端通信控制器EVCC和充电设备端通信控制器SECC之间的对话规则手册规定了双方怎么互相找到对方、怎么验明身份、怎么协商这次到底要充多少电、按什么价钱结算、中途出错该由谁收场。搞清楚它有什么用它决定了你在充电桩前那十几分钟是顺畅还是卡壳能不能插上就充、自家车的电池能不能反向给房子供电、换了个品牌的桩还认不认同一张账单答案都写在这份文件里。看懂它你就知道充电这件事远不止“通电”两个字。2. 为什么要出第二代从“通电就行”到“车和网要谈条件”2.1 第一代解决了“能充”第二代要解决“充得明白”第一代标准面对的场面相当单纯——一辆车、一根线、一个方向电从桩流向车。协议要做的事情就是把几句话标准化“我是谁”“我能接受多大电流”“什么时候开始”“什么时候结束”。参与者只有两方话题只有充电本身报文数量有限状态机也简单。第二代遇到的场面变了。同一根线可能上午在充电、下午在放电可能根本没有线靠两块线圈隔空传能量可能一个充电站同时管理多路电源和多个接口还可能在充电的十几分钟里顺手把电费、停车费、服务费一起结清。对话的参与者从两方变成多方话题从“充不充”扩展到“怎么算账、出了问题谁负责、附加服务怎么开”。场景一多原来那套消息就不够用了。于是第二代重写了消息集合请求和应答的定义、复杂数据类型的定义、错误码的定义都被重新组织了一遍。所以它更准确的身份是一份重新设计的对话规则而非“第一代加几个补丁”。这一点在后面讲易混概念时还会细说因为它是最容易被误解的地方。2.2 三种新场景把协议逼到了墙角第一种是双向能量传输。车不再只是吃电的一方它可以在需要时把电送回电网或家里。功率方向可变意味着通信上要多几条通道当前是充还是放、放多少、什么时候必须停下来这些状态要能被对方实时感知还要能在能量反向的瞬间保证两边对状态的理解完全一致否则就是设备层面的翻车。围绕双向能力衍生出的车到家、车到负载等用法本质上是同一套通信能力的下游应用。第二种是无线充电。没有插枪这个动作也就没有“插到底了”这种物理确认。能量的发送端和接收端要先通过通信对齐位置、确认对方已就位、协商功率等级再开始传能。标准里专门写了与另一份无线供电信令标准协同的部分让通信状态机和物理信令对得上节拍。少一次握手线圈就可能在半对准的状态下硬上功率——那是硬件层面最不愿意看到的场面。第三种是大功率与增值服务。当充电功率往上涨、接口形态变多通信里要携带的参数也跟着膨胀电压电流的上限、导引电路的状态、每一路电源的可用能力。同时充电这件事被拆成了“服务”除了充电本身还可以有别的服务挂在同一次会话上比如充电时预约车位、结算停车费、关联某个账户的优惠。标准里单独有一节讲服务选择把“这次会话到底要干什么”作为可协商的选项列出来还留了附录讨论这类外部服务客户端如何与本次会话关联。2.3 为什么整份文档按“层”来组织翻目录你会发现它从数据链路层一路写到应用层中间还夹着网络层、传输层、表示层。这种写法的好处是每一层可以单独换掉今天用这种无线链路明天换成另一种只要网络层往上的约定不变上面的应用代码几乎不用改。分层还带来一个实际好处——出问题的时候知道往哪看。车连不上桩是物理链路没建立、IP 地址没分到、TLS 握手失败还是应用层协议版本对不上每一层都有明确的状态和处理规则排查时能一层层往下剥不用靠猜。做过现场调试的人大概都有体会没有分层日志的时候一个“连不上”能让人查一整天有了分层之后至少知道该盯哪一行的输出。2.4 时序图标准里最像剧本的部分标准里最像剧本的一节是通信时序。它把一次完整会话拆成了若干幕会话怎么建立、什么时候算“准备好可以充电”、充电过程中双方各自多久发一次状态、异常时怎么退出。更有意思的是它与既有信令的同步。现实中的充电桩还要兼容老的导引信号方式——靠一根线上的电平高低和占空比来传递“我能给多大电流”。新一代通信必须和这套老信号对上车在报文里说自己准备好了桩那边的电平也得同步到位否则就会出现“软件说可以、硬件没松手”的僵局。无线场景同理要和非接触供电的信令标准对齐。所以时序那一章读起来不像协议定义更像一份舞台调度表谁在第几拍说什么、灯光什么时候切。3. 拆开看网络层管“送得到”应用层管“送的是什么”3.1 一条报文从枪线到屏幕的六层旅程把一次充电想象成寄快递。你想告诉对方“我要 50 度电请按这个价格结算”这是应用层的内容——相当于箱子里装的东西。箱子本身要按约定格式打包这叫表示层。打包好的箱子交给快递快递公司选陆运还是空运这是传输层。运单上写清楚收件地址这是网络层。最后货车上路、进出小区这是数据链路层和物理层。对应到标准里这条旅程大致是链路建立并完成安全关联拿到 IP 地址建立一条可靠的传输通道并套上加密用一个自定义的传输协议把应用报文切成协议数据单元发出去对方把二进制解回结构化数据读出里面那条请求然后回一条应答。任何一环掉链子最终现象都是“屏幕上转圈”。而每一环在标准里都有独立编号的章节这就是为什么它厚得像本手册。3.2 网络层IP 地址怎么分TCP 与 UDP 各干什么活网络层要解决的核心问题是“谁是谁”。车接上桩之后双方要在同一个链路上互相可达就得有地址分配和冲突避免的规矩。标准里对适用的网络协议文档做了限定还规定了若干协议参数的取值——不是“随便实现能通就行”而是把窗口大小、重传策略这类细节钉死目的很简单让不同厂商的设备放在一起时行为尽量一致。传输层有两种性格完全不同的通道。一种是无连接的数据报方式发出去就不管了丢了也不会补另一种是有连接的字节流方式保证顺序、丢了重发。充电场景里两种都用找桩的那一步用前者因为本质是“在链路上喊一嗓子谁在谁答”速度快、开销小、不需要维护连接找到之后的正式对话全部走后者因为参数、计费、状态这些消息一条都不能丢也不能乱序。理解这个分工很有用。现场遇到“车找不到桩”先看广播那一层遇到“找到了但聊不下去”问题多半在连接和加密那一层。分界线清楚了排查范围立刻缩小一半。3.3 应用层发现、握手、选服务三步进入正题应用层的第一步叫设备发现。车在链路上发出询问桩回应自己的地址和端口。这一步的报文格式很轻就是为了让车快速知道“对面有个能聊的对象”。第二步是协议握手。双方各自列出自己支持的协议版本清单交换之后挑一个共同支持的最高版本。这是标准的兼容做法新设备遇到老设备自动降到老版本说话不至于当场翻脸。握手的请求和应答里还带着各自的通信参数为后续对话定调。第三步是服务选择。这次会话到底要做什么是纯粹充电还是充电加别的服务参数怎么定双方在这一步谈拢。谈拢之后才进入具体服务自己的消息流。# 会话建立的四步示意注释里的编号对应标准中的章节划分 def establish_session(evcc): secc evcc.discover_secc() # 7.10 设备发现链路上找桩拿到地址与端口 tls evcc.open_tls(secc) # 7.7 传输层安全先把通道加密再谈业务 proto evcc.handshake(tls) # 8.2 协议握手交换各自支持的协议版本取共同最高版 svc evcc.select_service(proto) # 8.4 服务选择确定服务类型与本次会话参数 return svc # 返回的服务对象供后续充电流程使用这段伪代码只表达顺序不代表真实接口。它想说的是加密通道在业务对话之前建立版本协商在服务选择之前完成。顺序颠倒就会出问题——先谈业务再加密等于把参数明文晾在链路上先选服务再握手双方可能连对方说的是哪个版本的方言都不知道。3.4 EXI为什么不用普通 XML 直接发消息内容用 XML 描述可读性好人一眼能看懂哪个字段是什么意思。但 XML 有个致命缺点太啰嗦。一个字段名要写一整串字符加上尖括号和缩进一条消息轻松几百字节。充电链路的带宽和时延都不宽裕每次都发这种文本效率低得离谱。标准给出的解法是另一种二进制编码。它不是把整段文本丢进压缩算法而是双方事先约定好一套数据结构定义编码时只发“第几个字段、值是什么”字段名根本不出现在报文里。打个比方普通 XML 是每次对话都把整本词典念一遍这种编码是双方各拿一本相同的词典只报词条编号。代价是双方必须持有完全一致的结构定义文件版本对不上就解不出内容。所以标准把结构定义作为规范性附录给出实现方要按它生成代码而不是手写解析。这一条踩坑的人不少自己拍脑袋写了个解析器测试环境能跑换一台设备就乱码。3.5 出错怎么办应答码那一套规矩每条请求都有应答每条应答都带一个结果码。这些码分成几类一切正常、有惊无险的警告、以及不同程度的失败。关键在于失败不等于立刻断开。有些错误是可协商的——比如对方不接受你提的某个参数回一个失败码你换一组参数重来就是有些错误是致命的比如身份验证没通过那就该干净地结束会话而不是反复重试把对方惹毛。标准里对“哪些错误可以重试、重试几次、重试时状态怎么回退”都做了规定还专门用附录描述了重新协商时的消息序列。现场最常见的错误处理写法是“失败就重连”这在简单场景下能用在多步骤会话里就容易出乱子重连之后状态没清干净双方对“现在进行到第几步”的理解不一致然后就开始互相等待日志里一片安静。按应答码分类处理比无脑重连靠谱得多。4. 安全不是一个开关证书、TLS 与消息签名怎么配合4.1 为什么充电桩非得验车的证书最直接的答案是为了让你不用掏手机。所谓即插即充本质是车用自己的证书证明“我是这辆车”桩把这份证明连同会话信息传给后台后台据此完成身份确认和账务绑定。整个过程没有扫码、没有刷卡、没有打开任何应用。如果没有这套机制桩就无法确认对面是谁只能退回到“先付钱再通电”的老路。所以证书不是可选项而是即插即充的地基。反过来一旦证书体系设计得不好——比如根证书太多、有效期太长、吊销机制缺失——后面所有的便利都建立在流沙上。4.2 证书链与有效期信任也有保质期证书不是一张纸而是一条链根证书签中间证书中间证书签终端证书。验证的时候从终端往上走一直走到一个“我本来就信任”的根为止。这条链上任何一环出问题整条链就不可信。标准里专门规定了根证书的数量上限和根证书的有效期。为什么要在标准里管这种事因为桩是个资源受限的设备存储有限、算力有限、还要用十几年。根证书塞进去几十个每次验证都要挨个试慢得让人怀疑人生根证书有效期定得太长等它过期那天满大街的桩都得连夜升级固件。这类规定看着琐碎其实是血泪经验的沉淀。# 按签发关系逐级校验一条证书链 openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem # leaf.pem 终端证书车端或桩端自己的那张 # -CAfile 信任锚我本来就信任谁这里是自签的根证书 # -untrusted 中间证书参与校验但不作为信任起点这条命令做的事和桩在现场做的事是同一件沿着签发关系往上爬直到撞上一个自己本来就信任的根。命令输出如果是 OK说明链路完整、签名有效、时间也在有效期内如果报错先看是哪一环过期再看是不是中间证书没带全。这个小技巧在排查“明明证书都装了却验不过”的时候特别省时间。4.3 传输层加密与消息级签名两道锁不重复很多人以为有了传输层加密就够了为什么还要对消息本身做安全处理区别在于保护的范围。传输层加密保护的是“这条管道”。数据在管道里是密文出了管道就是明文。如果链路上存在一个中间节点管道在它那里断成两截它看到的就是明文。而消息级的安全处理保护的是“这条消息本身”即使它在某个节点上被解开再转发接收方仍能验证它没有被改过、确实来自声称的发送方。类比一下前者是给整辆货车加封条后者是给车厢里每一件货物单独加封条。货车封条在转运站会被剪开货物封条不会。两个机制叠加覆盖的是不同的信任边界谈不上重复更谈不上“有一层就够了”。4.4 密钥保护与随机数最容易被跳过的一节私钥放哪里放在普通文件系统里等于把家门钥匙插在锁上。标准要求对密钥做专门保护通常落在安全芯片或受保护的存储区域里。这不是洁癖是因为私钥一旦泄露没有后悔药攻击者可以冒充这辆车去充电、去结算而你连什么时候泄的都不知道只能靠吊销列表亡羊补牢。随机数生成同样关键。所有会话密钥、挑战值都来自随机数发生器。如果它的输出可预测前面那些加密算法全部白搭——相当于你家防盗门是顶级货但钥匙是从流水线上随便捡的。标准把这两节单列出来就是提醒实现方密码学上的强度取决于最弱的那个环节。5. 四个最容易搞混的地方别把这几件事当成一回事5.1 易混点一第二代就是“第一代的升级补丁”易混在哪看到编号里带个“20”很容易理解成第一代加了一章、改了几段。为什么会混编号规则确实有迷惑性同一个系列下的不同部分看起来像版本递进。怎么区分看它改动的范围。第一代定的是“能充”的那套消息第二代重新组织了消息集合、复杂数据类型、错误码体系还加入了双向、无线、增值服务这些新场景所需的报文。数据结构变了编码规则要重新对齐会话流程也重排了。把它当补丁看最大的风险是实现时照着旧代码改改到一半发现字段语义全变了。更稳妥的判断方法是如果两端的协议版本不同能不能靠协商降级通上话能说明兼容机制有效不能说明你混用的是两代的消息定义。5.2 易混点二通信标准规定了插头长什么样易混在哪聊到充电标准很多人默认一份文件把所有事都管了从插头形状到通信协议全包。为什么会混现实中的标准确实是分工的但编号长得像外行很难分清谁管哪一段。一份管连接器的机械尺寸和电气安全一份管车与桩之间怎么对话各管一摊。怎么区分问一句“这事拔了线还成立吗”。插头几个针、针多粗、插拔力多大属于连接器标准插上之后双方怎么互相介绍、怎么报价、怎么传状态才归通信标准管。这个分界线很有用遇到“换了桩就充不上”先确认是物理连接不合规还是通信谈不拢两者的排查方向完全不同。5.3 易混点三有加密就等于能即插即充易混在哪看到协议里有证书、有加密通道就认为即插即充是顺带实现的。为什么会混两者确实都跟证书有关容易让人以为是一件事的两种说法。怎么区分加密解决的是“别被人偷看偷改”即插即充解决的是“你是谁、这单记在谁头上”。前者是通道属性后者是身份和账务属性。只做加密不做身份车和桩之间是安全地聊了一场但桩仍然不知道对面是哪位最后还是得扫码。判断方法很直接把网络断开看充电是否还需要额外操作——如果仍然需要人工确认说明身份这一环没打通。5.4 易混点四EXI 是一种压缩包易混在哪听说它能把消息体积变小就顺手理解成“发之前压一压”。为什么会混效果上确实是变小了直觉上就归到了压缩工具那一类。怎么区分压缩是对已有字节流做通用变换不需要知道内容结构这种编码依赖双方共享的数据结构定义本质是“换一种写法”而不是“把原文压小”。区别在实际表现上压缩后的数据必须完整接收才能解压而这种编码可以边收边解、按字段取值压缩对结构一无所知这种编码对每个字段的类型和取值范围都门儿清。所以结构定义文件版本不一致时解出来的不是乱码就是错位而压缩不会出现这类问题。6. 什么时候用它什么时候别硬套先给判断标准你要做的事是否需要车和桩在“通电之外”交换结构化信息。如果需要——身份、计费、双向功率、服务协商、状态上报——那这套东西就是正解如果不需要硬套只会给自己找麻烦。适合的场景很明确。做出口车型或多品牌兼容的充电设备必须按它来否则对方车辆认不出你做车队管理需要把每辆车的充电明细精确归到账户上这套消息体系能提供足够细的字段做双向充放电产品功率方向会变状态必须双向可见没有这套协商机制就只能靠私有协议而私有协议在换一个合作方时就要重写一遍做无线充电物理上没有插枪动作通信是唯一能确认“已就位”的手段。不太适合的场景同样明确。小规模的封闭场站、只服务自有车辆、只做单向慢充用一套私有协议反而更省事——报文自己定、调试自己说了算不必为了合规去实现一整套证书体系和状态机。还有一种常见误判把通信标准当成功能清单指望接上它就能自动获得即插即充、自动结算、远程诊断。它只规定“怎么对话”不规定“后台怎么记账”账务系统、证书签发、运营平台都得自己搭。场景建议主要理由多品牌车辆共用的公共充电设备采用互操作依赖统一的消息与握手规则双向充放电产品采用功率方向可变需要实时双向状态协商无线充电设备采用无物理插枪靠通信确认就位与功率等级单一车队的封闭慢充场站可不用参与方固定私有协议成本更低只想要“插上就充”的简易产品谨慎身份与账务体系需要额外投入不是接上就有把标准当功能清单直接采购不建议它定义对话规则不定义运营系统还有一条边界容易被忽略标准的规范性内容和资料性内容是分开的。规范性部分是实现时必须遵守的硬约束资料性附录更多是示例、说明和参考做法比如计费示例、测量精度与容差的讨论、证书应用的说明。做实现的时候如果把这些示例当成强制要求逐条对照会做很多无用功反过来把规范性附录里的结构定义当成“参考一下就行”那就是自找麻烦——它决定了解码能不能对上。我自己的教训来自一次联调。当时两端都能握手成功日志显示协议版本一致可一到服务选择就卡住双方都在等对方先发。查了两天才发现我们对某个可选字段的理解不一样我按资料性附录里的示例把它当成必填对方按规范性章节当成可省略。谁都没错错在我一开始就没分清哪部分是硬约束、哪部分是举例说明。从那以后我每次接手这类标准第一件事就是先把规范性附录和资料性附录分开标注再动代码。这个习惯看着笨救过我不少次。希望这些能帮你在下次遇到“车和桩互相不认识”的时候少走一点弯路。本文还有配套的精品资源点击获取