ISO 15118-20充电通信入门：分层、SDP发现与TLS证书实战

简介2022年发布的ISO 15118-20国际标准正式文本聚焦道路车辆与电网之间通信接口的第二代网络层与应用层要求面向电动汽车充电协议开发、车桩互联互通测试及智能电网研究领域的中高级技术人员帮助解决不同品牌车型与充电设施之间协议不统一、互操作与信息安全难以验证的问题。压缩包内为1份PDF文档约34.74MB完整收录标准的范围界定、术语与缩略语、基于OSI的服务定义、需求结构、XML模式图示约定以及网络层传输路由、错误检测和应用层身份验证、计费、充电状态监控等章节并含前言、引言与规范性引用文件可直接用于协议对照开发与合规自查。该文档已有161人学习下载适合作为充电通信协议设计、测试用例编写和标准解读的案头参考资料。1. 插上枪为什么还要“谈条件”ISO 15118-20 到底在管什么很多人第一次听说电动汽车充电还要跑一套网络协议反应都是插上枪、通电、开始充不就完了吗其实充电枪插上的那一刻车和桩才开始“打招呼”。ISO 15118-20 就是管这场对话的规则书全名是车辆与电网通信接口的第二代网络层与应用层要求2022 年发布的第一版。它不教你造充电桩而是规定车端和桩端在网络上说什么、按什么顺序说、说错了怎么办。它适合三类零基础的人做充电桩固件的、做车端通信模块的、做充电运营后台的。你不需要先懂电力电子只要能看懂“两个程序互相发消息”就能入门。2. 先画一张对话地图一条充电报文要爬几层楼2.1 从插枪到结算报文其实在爬七层楼刚翻开这份文档的人最容易出现的反应是“怎么什么都有”一会儿讲证书一会儿讲 IPv6一会儿又跳到 XML。这不奇怪因为它本来就是按“分层”写的。你可以把一次充电对话想成寄一件快递你先决定寄什么内容装进箱子贴上面单表示层交给快递公司选路线网络层最后卡车把箱子拉到门口物理链路。任何一层出问题收件人都收不到。标准里第 7 章基本就是照这个顺序排下来的7.3 讲安全概念7.4 讲通信状态和数据链路怎么处理7.5 讲无线链路的安全7.6 讲网络层IP 地址怎么分配、引用哪些既有网络规范7.7 讲传输层TCP、UDP 和 TLS7.8 讲 V2G 传输协议端口、协议数据单元7.9 讲表示层XML 与 EXI 编码、消息安全7.10 讲应用层的发现协议。第 8 章才是真正的“台词本”握手消息、业务消息、服务选择、时序、错误处理。新手最容易犯的错是一头扎进 8.3 的消息定义里那里有几百页的请求和响应结构体看一眼就想关掉。正确的走法是先建立“分层地图”知道每条消息该出现在哪一层再回头看细节你会发现它其实很有秩序。2.2 第一次打开文档先读这三处先跳过那几处拿到一份几百页的标准最省时间的做法不是从头读到尾而是先读能建立全局观的部分。我的建议是这样第一处看目录加第 7.1 节的总体说明先弄清这套协议分了几个阶段每个阶段干什么。第二处直接翻到 8.2 节的协议握手这段很短讲的是车和桩刚连上时怎么互相报“我支持哪些应用协议”它是整场对话的开场白读完你就有画面感了。第三处看 8.5 节的通信时序尤其是“会话建立与准备好充电”那一段它会告诉你一条完整充电流程里消息的先后顺序。可以先跳过的是什么附录里的证书配置文件、标识符规范、schema 定义这些是当字典查的不是拿来通读的。还有附录里关于自动充电连接装置、无线充电的特殊流程、重协商消息序列、增值服务客户端关联、测量精度与容差、绝对电价示例这些内容它们是给已经跑通主流程的人做扩展用的。新手一开始就啃这些等于还没学会走路先研究跑步姿势。提示读标准时手边备一张纸把“阶段名 → 谁发 → 谁收 → 大概干什么”画成四列比反复翻页有效得多。2.3 EVCC、SECC、V2GTP先记住三个名字文档里到处是缩写不先认人读起来就是天书。入门阶段只需要先认三个。EVCC 是车端那台负责通信的控制器你可以理解成“车里负责说话的嘴”。SECC 是桩端负责通信的控制器是“桩里负责回话的耳朵”。这两个名字会贯穿全篇几乎所有消息定义都会标明方向是 EVCC 发往 SECC还是反过来。V2GTP 是传输层的“信封格式”它规定了数据包怎么开头、版本号放哪、载荷多长、载荷类型是什么。你可以把它想成快递面单不管箱子里装的是申请书还是账单面单的格式是固定的。第 7.8 节讲的就是它包括支持哪些端口、协议数据单元怎么组织。还有一个词你会频繁看到SDP也就是 SECC 发现协议在第 7.10 节。它的作用是车刚连上网络时还不知道桩的 IP 和端口于是先喊一嗓子“谁在”桩回一句“我在这我的地址是 X端口是 Y”。这个动作极其简单却是我最推荐新手第一个动手跑的东西下一章就干这件事。3. 第一个能跑的例子在电脑上模拟一次“谁在充电”3.1 先把发现协议想成停车场里喊一嗓子你开车进地下车库不知道哪个桩是空的于是喊一声“有空位吗”某个桩回你“3 号位过来”。SECC 发现协议就是这个逻辑车端还不知道桩端的地址就先发一个很短的小包出去桩端收到后回一个包含自己地址和端口的小包。整个交互只有一来一回不需要证书不需要复杂编码甚至不需要真的充电桩。这就是它适合做第一个例子的原因。你可以完全在自己电脑上用两个小程序互发 UDP 包把这条链路跑通先建立起“我真的能让车端和桩端说上话”的信心。下面两段代码是入门简化版字段长度做了削减目的是让你看懂流程不是一份合规实现。真实字段布局以文档第 7.10 节的发现协议定义为准。3.2 二十行 Python 起一个“假充电桩”先写服务端也就是假 SECC。它干的事只有一件在本机某个端口上蹲着收到请求就回一个应答。# fake_secc.py —— 在本机模拟桩端的“发现应答” import socket SDP_PORT 15118 # 发现协议使用的端口 LISTEN_ADDR 127.0.0.1 # 本机回环不接真实硬件也能跑 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) # UDP无连接 sock.bind((LISTEN_ADDR, SDP_PORT)) print(f假 SECC 已启动监听 {LISTEN_ADDR}:{SDP_PORT}) while True: data, peer sock.recvfrom(1024) # 收请求最多读 1024 字节 print(f收到来自 {peer} 的请求{len(data)} 字节: {data.hex()}) # 应答内容安全方式(1B) 传输协议(1B) 桩端地址(4B) 端口(2B) security 0x00 # 0x00 表示不启用 TLS transport 0x00 # 0x00 表示后续用 TCP reply ( bytes([security, transport]) socket.inet_aton(127.0.0.1) # 简化成 IPv4真实标准用 IPv6 (15118).to_bytes(2, big) # 大端序存端口 ) sock.sendto(reply, peer) # 原路回给对方这段代码里SOCK_DGRAM表示用 UDP因为发现阶段双方还没建立连接只能“扔一个包出去”。recvfrom会同时拿到数据和对方地址sendto就按这个地址原路返回。to_bytes(2, big)的意思是把这个端口号用两个字节表示并且高位在前网络传输里默认都是这个顺序。socket.inet_aton是把点分字符串转成四字节。跑起来之后它会一直挂着等什么都不打印这是正常的因为还没有客户端来问。3.3 客户端发两个字节收回地址和端口再写客户端也就是假 EVCC。它先构造一个很短的请求发出去然后把收到的应答拆开。# sdp_client.py —— 模拟车端发起一次发现请求 import socket SECC_ADDR (127.0.0.1, 15118) def build_request(use_tls: bool, use_udp: bool) - bytes: 构造发现请求两个字节分别表示安全方式和传输协议 security 0x10 if use_tls else 0x00 # 0x10 表示要求启用 TLS transport 0x10 if use_udp else 0x00 # 0x10 表示后续走 UDP return bytes([security, transport]) def parse_response(payload: bytes) - dict: 解析应答安全方式 传输协议 地址 端口 if len(payload) 8: raise ValueError(f应答太短只有 {len(payload)} 字节检查服务端是否正常) return { security: payload[0], transport: payload[1], ip: socket.inet_ntoa(payload[2:6]), port: int.from_bytes(payload[6:8], big), } sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(3) # 三秒收不到就报错别一直等 sock.sendto(build_request(use_tlsFalse, use_udpFalse), SECC_ADDR) try: data, _ sock.recvfrom(1024) info parse_response(data) print(桩端地址:, info[ip]) print(桩端端口:, info[port]) print(是否启用 TLS:, 是 if info[security] 0x10 else 否) except socket.timeout: print(超时检查假 SECC 是否已启动端口是否被占用)settimeout(3)是这段代码里最实用的一行。新手调试网络程序最常见的状态是“卡住不动”加了超时程序会主动告诉你“没人理我”而不是永远挂着。parse_response里先判断长度再切片是因为真实环境里收到的可能是残缺包不判断就会在你意想不到的地方抛异常。3.4 跑通之后问自己三个问题先开一个终端跑python fake_secc.py再开另一个终端跑python sdp_client.py。如果一切正常客户端会打印出地址和端口服务端会打印出收到的字节。第一次看到这两行输出的时候你其实已经完成了一次“车端问、桩端答”的完整交互。跑通之后别急着往下翻问自己三个问题。第一个如果把客户端里的use_tls改成True服务端的回复会变吗答案是不会因为这段假服务端写死了返回值这说明“客户端提要求”和“服务端怎么答”是两件独立的事。第二个把端口改成 15119 会怎样会超时因为没人监听那个端口。第三个如果把 UDP 换成 TCP这段代码还能跑吗不能要改成SOCK_STREAM并先建立连接。这三个问题的答案恰好对应文档里三种最常见的翻车场景。注意这个例子里把 IPv6 简化成了 IPv4真实标准用的是更长的地址字段。入门阶段先用短的跑通等你能读懂流程了再把字段长度改回标准里的定义。4. 安全、证书、编码三条线新手怎么不被绕晕4.1 TLS 在这套协议里到底挡住了什么很多人对 TLS 的印象是“网站那个小锁”放到充电场景就觉得抽象。你换个角度想车和桩在网络上说话中间可能经过路由器、交换机、运营商设备如果没有保护别人完全可以伪装成桩让车把钱付给他或者在中途改掉“允许的最大电流”这种关键参数。第 7.7 节把传输层安全单独列出来讲讲的就是这件事。它规定了 TLS 怎么用、握手时双方怎么验证身份、加密套件怎么选。第 7.5 节还专门提到无线链路的数据链路层安全因为无线场景下“谁都能收到信号”风险更高。你不用一上来就搞懂每个加密算法的区别先记住一句话就够TLS 保证“对面确实是那个桩”和“中间没人改内容”。跟 TLS 配套的还有一组防护要求第 7.3 节里提到了防火墙、密钥保护和随机数生成。这三样听起来像运维的事其实和写代码的人关系很大。比如随机数如果生成得不合格密钥就可能被猜出来前面所有加密都白做。新手最容易忽略这类“看起来不归我管”的要求等到出事才发现是最基础的地方漏了。4.2 证书和密钥先只记三件套证书这部分是新手最容易劝退的地方因为文档里附录专门有一大块讲证书配置文件字段密密麻麻。入门阶段你只需要建立一个三段式理解。第一件谁签发。证书不是自己说自己是誰就算数的要有上一级来背书。第二件给谁用。同一套系统里车端证书和桩端证书是分开的用途也不同拿错了就是用错钥匙。第三件什么时候过期。这是最容易被忽略的一条第 7.3 节专门讨论了根证书的数量和有效期因为根证书一过期底下所有证书全部失效现场表现就是“昨天还好好的今天全连不上”。我第一次接触这类系统时踩过一个坑本地开发环境的时间是手动改过的证书在另一台机器上生成两边时间差了几个小时握手一直失败日志里只有一句很含糊的报错。查了大半天才发现是时间问题。从那以后我养成习惯排查证书问题第一件事就是核对两台机器的时间。4.3 EXI 不是压缩包是另一种“写法”第 7.9 节讲表示层核心是两个词XML 和 EXI。XML 你大概见过就是一堆尖括号标签人读起来很友好。但在充电这种实时性要求高的场景一条消息里大量重复的标签名会占掉很多字节传输效率低。EXI 做的事情是把这些结构化的信息用一套更紧凑的二进制方式表示。注意它不是把 XML 打包压缩而是换了一种“写法”同样的信息用更少的字节表达而且可以按预先约定好的规则来编码和解码。所以你会遇到一个经典现象抓包看到的是一堆十六进制数字完全不像文本这是正常的不是加密。理解这一点很重要因为新手看到“乱码”的第一反应往往是“是不是被加密了”或者“是不是抓包工具坏了”然后顺着错误的方向排查很久。实际原因往往只是编码方式不同。文档附录里提供了 schema 定义它的作用就是告诉你每种消息的结构长什么样有了它才能把二进制还原成人能看懂的内容。4.4 一条命令把证书里的人话信息翻出来理论说再多不如自己看一眼真实证书长什么样。手边有任意一个证书文件就可以用这条命令把关键信息打印出来# 打印证书的持有者、签发者、有效期不输出完整内容 openssl x509 -in secc_cert.pem -noout -subject -issuer -dates-in后面跟证书文件路径-noout表示不要把那串长长的编码打印出来-subject打出“这张证书是给谁的”-issuer打出“谁签的”-dates打出生效时间和失效时间。跑完你会看到类似notBefore和notAfter两行那就是有效期。拿到这三行信息你就能回答三个排查问题这张证书是不是本来就快过期了签发者和我信任的根证书是不是同一条链持有者名字和我预期的是不是一致这三个问题能解决掉相当一部分“握手失败但看不出原因”的情况。真实项目里证书的字段要求更严格具体规定在文档的证书配置文件附录里等你需要对接真实桩的时候再逐条核对。5. 新手最常翻车的五个地方一份排查清单5.1 报文层面的三个坑第一个坑抓包全是十六进制看不懂在说什么。现象是打开抓包工具内容区一片数字没有任何可读文本于是怀疑自己抓错了包。原因很可能是消息用了紧凑编码本来就不可读和加密无关。解决办法是先确认这条消息处在哪个阶段发现阶段和握手阶段的早期消息通常结构简单可以手工对照文档拆进入业务消息之后再想读懂就必须拿到 schema 定义用工具按结构解码。别指望肉眼读二进制。第二个坑端口是通的但对方毫无反应。现象是能连上但发完消息就石沉大海或者一直等到超时。最常见的原因是搞混了两个阶段用的传输方式发现阶段对方在等一个无连接的短包你却在上面建了连接或者反过来会话阶段你在无连接地发包对面根本不接。解决办法是先把流程分成“找人”和“说话”两段找人那段用短包说话那段用连接各查各的。第三个坑自己拼的消息结构对不上对方直接拒绝。现象是消息发出去了对方回了一个表示错误的响应码。原因多半是消息头、命名空间或者版本字段填得和对方预期不一致这类字段错了后面内容写得再对也没用。解决办法是从 schema 定义出发生成消息结构而不是手写字符串拼接。手写看着快改起来全是血泪经验。5.2 时序和证书层面的两个坑第四个坑证书链看着是对的握手就是过不去。现象是证书能打开、签发者也能对上但连接建立不起来。原因通常藏在细节里两台机器时间不同步、证书用途字段和实际使用场景不匹配、根证书已经过期。解决办法是按顺序核对三件事——时间、用途、有效期一个都不跳。第 7.3 节对这些有明确要求别凭感觉判断。第五个坑报错了只盯着自己的代码改不看响应码。现象是流程走到某一步就断了于是反复改代码越改越乱。原因是这套协议对错误处理有专门的规定第 8.6 节定义了各种响应码的含义对方其实已经告诉你哪里不对了只是你没查。解决办法是先把收到的响应码对照文档查一遍再决定改哪里。这个习惯能省掉大量瞎猜的时间。协议在这种地方其实很贴心它把出错原因写在了消息里只是新手常常把它当成一个普通数字忽略掉。6. 下一步怎么学一份能落地的六周路线跑通发现协议之后最容易出现的状态是“然后呢”。这里给一条我自己验证过、节奏不至于崩的路线按周拆开每周都有明确的产出物。周次主要动作本周产出第 1 周通读第 7 章的分层说明和第 8.2 节握手一页纸的分层笔记第 2 周把发现协议的例子改成标准字段长度能收发标准格式报文的小工具第 3 周读 8.5 节时序把一次充电的消息顺序画出来一张时序草图第 4 周用 schema 定义解码一条真实业务消息能打印出可读字段的解析脚本第 5 周读 7.7 节和证书配置文件附录配一套测试证书本地能完成一次加密连接第 6 周读 8.6 节错误处理故意造三种错误看响应码一份自己的排查对照表几个提醒。第三周画时序图的时候不要追求一次画全先把主流程画出来分支和重协商先空着。第四周的解码是最有成就感的一步因为你会第一次“看见”消息里到底装了什么。第五周配证书如果卡住先回到第 4 章那三个问题时间、用途、有效期。还有一个小技巧值得单独说给自己建一个“错误码本”。每次遇到一个新的响应码就记下它出现时的上下文、当时在哪个阶段、最后怎么解决的。这本子越长你排查的速度越快。别人眼里的玄学问题在你这里会慢慢变成条件反射。我自己的教训是关于跳步的。刚开始学这套协议时我觉得握手和发现都太简单直接跳去读业务消息定义结果看了一周完全没进展因为我不知道那些消息是在什么上下文里被发出来的。后来老老实实退回去把时序和状态从头走了一遍前面的内容反而一天就看完了。从那以后我每次接触新协议都强制先跑通最小的那条链路再往上加东西绝不跳步。希望帮到你。本文还有配套的精品资源点击获取