电动汽车充电通信协议 ISO 15118-20：协议栈、TLS 与互操作排错

简介：ISO 15118-20:2022 英文原版标准全文，面向电动汽车充电通信协议开发者、车桩互联方案工程师及智能电网研究人员，用于解决不同品牌车辆与充电设施之间网络层、应用层协议不统一导致的互操作难题。文档系统规定了第二代网络层的数据传输、路由与错误检测机制，以及应用层的身份验证、计费、充电状态监控等服务要求，并给出术语定义、缩略语、XML 模式图示与需求结构等规范内容，适合用于协议栈开发对照、一致性测试用例设计与技术文档编写。资源包内含 1 个 PDF 文件，大小约 34.74MB，为 ISO 官方排版的可检索正文，含目录、前言与条款编号，便于按章节定位查阅。目前已有 161 人学习，属于小众但专业性强的标准资料，适合需要权威原文依据而非二手解读的从业者长期留存备查。

1. 插入充电枪后的 300 毫秒，决定这套网络协议能否跑通

做电动汽车充电联调时，常遇到这样的场景：物理连接已经建立，绝缘检测通过，桩和车都在等待，界面却一直停在“正在建立通信”。抓包会发现：一边在反复发送 UDP 报文寻找对端，另一边既没有启用 IPv6，也没有加入组播组。这类问题几乎都落在同一份文档划定的边界内：2022 年发布的第一版 ISO 15118-20，第二代网络层与应用层要求。它不是讲原理的科普册子，而是把电动汽车充电通信从链路层一直规定到应用层消息的工程约定：TLS 怎么配、证书链分几层、PDU 怎么切帧、会话时序的容忍窗口有多大、失败回什么码，都有明确位置。手上这份全文五百多页，适合做桩端或车端协议栈、互操作测试、充电安全方案的人当作日常查阅的资料。

2. 六层协议栈怎么切：从数据链路到应用层的责任边界

刚拿到这份标准时，容易从第 8 章的消息定义开始读，因为那里字段最全。读两天就会发现走不通：消息里的每一个字段能不能用、什么时候发，最终都要回到第 7 章的基础要求。正确的读法是从下往上读，每一层只回答一个问题：“这一层负责什么，不负责什么。”把边界划清楚，后面写代码才知道某个报错该去哪一层找。

2.1 先读懂组织方式：服务原语与需求条目

标准的第 5 章是“约定”，看起来最枯燥，但它是整份文档的索引系统。它规定了三件事：基于 OSI 的服务如何描述、需求条目怎么写、XML schema 图用什么记号。

服务原语是理解整份文档的关键。它把每一层对外暴露的能力抽象成四个动作，桩端和车端的实现只要对齐这四个动作，内部怎么写都行：

这套抽象的直接好处是：TLS 握手、PDU 收发、消息编解码这三件事被拆成三个独立的可替换模块。你换了 EXI 编解码库，只要 Confirm 的语义不变，上层业务代码一行都不用改。

需求条目的写法同样重要。文档里每一条强制要求都带唯一编号，这些编号在一致性测试和互操作报告里会被反复引用。我的习惯是把需求号直接当成测试用例 ID：跑通一条就在表格里勾一条，失败时能立刻定位到原文哪一句。这比只写“TLS 握手失败”有用得多，至少你知道该翻到传输层那一章的哪一页。

提示：读第一遍时先只看第 5 章到第 7 章，把第 8 章的消息定义当成附录查，效率会高很多。

2.2 数据链路层与网络层：WLAN 安全、RFC 适用范围与 IP 寻址

第 7.5 节讲数据链路层，重点在 WLAN 场景下的链路层安全。这里有一个容易被忽略的边界：链路层加密和应用层 TLS 是两套机制，不能互相替代。现实中见过不少方案，觉得 Wi-Fi 已经加密了就不再配 TLS，结果在互操作测试里第一批就被拒。

第 7.6 节是网络层，内容分三块：适用的 RFC 清单及其限制、协议参数设置、IP 寻址。这里提到的 RFC 清单是裁剪过的，标准明确列出了哪些可以用、哪些能力必须关掉。工程上最常见的做法是：车辆侧和充电设施侧都只启用 IPv6 链路本地地址通信，不做路由转发，不接入外部网络。

组播是这一段的关键。对端发现阶段依赖 IPv6 链路本地全节点组播，接口没加入组播组，报文就发不出去，也收不到。排查时先看网卡状态：

# 查看接口是否拿到 IPv6 链路本地地址，以及组播标志 ip -6 addr show dev eth0 ip -6 maddr show dev eth0 # 抓对端发现阶段的报文，只看 UDP 15118 端口 sudo tcpdump -i eth0 -n -vv 'udp port 15118' # 同时观察邻居发现是否正常，地址解析失败会表现为“发得出去收不回来” sudo tcpdump -i eth0 -n 'icmp6'

第一条命令确认接口有没有 fe80:: 开头的地址，没有的话后面全是空谈；第二条看 ff02::1 有没有被加入，没有就说明内核没把这块接口当多播接口用；第三条是核心过滤条件，对端发现走的就是这个 UDP 端口；第四条经常被跳过，但只要邻居发现不通，表现出的现象和“对端不响应”一模一样，很容易误判。

参数上还有两个细节值得注意。一是 MTU，链路层如果配得比默认值小，大数据量的证书链传输会被分片，分片丢一个就整包重传，握手时间会成倍上涨。二是接口的自动配置开关，测试环境里手工配死地址反而更容易复现问题，正式环境再交还给自动配置。

2.3 传输层与 V2G 传输协议：TCP、UDP 与 PDU 切帧

第 7.7 节讲传输层，把 TCP、UDP 和 TLS 三件事放在一起说，这个编排是有讲究的：它们的分工是固定的。UDP 只用于最开始的对端发现，一次请求一次响应，不重传；一旦确定对端地址和端口，后续所有控制消息走 TCP，再在 TCP 之上套 TLS。

第 7.8 节是 V2G 传输协议，管两件事：端口约定和协议数据单元。端口是固定的，实现里不要做成可配置项，否则互操作时对不上。协议数据单元解决的是 TCP 流的分帧问题：TCP 是字节流，不保证一次读到的就是一个完整消息，必须靠头部里的长度字段自己切。

import struct HDR_LEN = 8 def split_pdus(buf: bytearray): """从 TCP 缓冲区里切出完整的 V2G 传输协议数据单元。 返回 (完整帧列表, 剩余未成帧的字节)，由调用方把剩余部分留到下次 recv 再拼。 """ frames = [] while len(buf) >= HDR_LEN: version, inv_version, payload_type, payload_len = struct.unpack( ">BBHI", bytes(buf[:HDR_LEN]) ) # 版本字节与其取反字节互为校验，不一致说明流已错位，必须断开重建 if version ^ inv_version != 0xFF: raise ValueError("frame desync, drop the connection") total = HDR_LEN + payload_len if len(buf) < total: break # 半包，等下一次 recv frames.append({ "type": payload_type, "payload": bytes(buf[HDR_LEN:total]), }) del buf[:total] return frames, buf

这段代码有三处值得说。第一处是>BBHI这个格式串，大于号表示大端字节序，两个 B 是单字节字段，H 是双字节的负载类型，I 是四字节的负载长度，加起来正好八字节头部。第二处是版本互补校验，它不是可选项，TCP 流一旦错位，后面所有帧都会跟着错，早失败比晚失败好。第三处是半包处理，break之后把剩余字节返回给调用方缓存，这是流式协议解码的标准写法，少了这一步，在高吞吐场景下必然出现随机的解析异常。

负载类型字段决定了这段负载该怎么解释：是应用层消息、会话控制指令，还是别的类型。写解码器时建议先按类型分支，再进具体解析，别写成一个巨大的 if-else 嵌套。

2.4 表示层与应用层：EXI 编码、消息安全与对端发现

第 7.9 节是表示层，只做两件事：把 XML 压成 EXI，以及消息级安全。EXI 的选择理由很实际：应用层消息结构复杂、字段多，纯文本 XML 在带宽和解析开销上都不划算，而 EXI 是 schema 驱动的压缩，编解码双方拿着同一份 schema，压出来的字节流可以做到很小。

这里的坑在“同一份 schema”。附录 A 给了规范性 schema 定义，但实际项目里经常出现一端用旧版本 schema、另一端用新版本的情况，症状是解码不报错但字段全空或者错位。判断方法很简单：拿同一段十六进制报文，两端分别用各自的 schema 解一遍，比对字段名和值。

消息安全是独立于 TLS 的一层。TLS 保护的是通道，消息安全保护的是消息本身，两者叠加使用。做方案设计时不要把它们混为一谈，也不要用其中一个去替代另一个。

第 7.10 节是应用层的对端发现协议，是整个会话的开始。它在 UDP 上完成一次极简的问答：请求报文固定两个字节，响应报文固定二十个字节，里面装着对端的 IP 地址、端口和它支持的传输与安全能力。

import socket, struct SDP_PORT = 15118 def discover(ifname: str, timeout=3.0): """在对端发现阶段发一次请求，返回对端地址与端口。 请求 2 字节：安全能力 1 字节 + 传输协议 1 字节。 响应 20 字节：IPv6 地址 16 字节 + 端口 2 字节 + 安全能力 1 字节 + 传输协议 1 字节。 """ req = bytes([0x00, 0x00]) # 明文 + TCP，按需改成实际能力位 s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) s.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_MULTICAST_IF, socket.if_nametoindex(ifname)) s.settimeout(timeout) s.sendto(req, ("ff02::1", SDP_PORT)) data, _ = s.recvfrom(64) if len(data) != 20: raise ValueError(f"unexpected response length: {len(data)}") addr = socket.inet_ntop(socket.AF_INET6, data[:16]) port, sec, proto = struct.unpack(">HBB", data[16:20]) return addr, port, sec, proto

几个参数要盯住。IPV6_MULTICAST_IF必须显式指定出接口，多网卡机器上不指定就会走到默认路由，报文发到错误的网卡上去。目标地址是链路本地全节点组播，只在本链路有效，不要试图跨网段。超时值建议设到秒级，短了容易在负载高的桩上误判。返回值的端口字段决定后续 TCP 连接打到哪里，这个值要原样透传给下一阶段，不能自己写死一个常量。

3. 安全体系怎么搭：证书链、TLS 参数与密钥保护

安全这一章在文档里占的篇幅最重，从第 7.3 节一直铺到第 7.9 节里的消息安全，附录里还有规范性的证书配置文件。篇幅重的原因是它同时约束三件事：证书怎么发、通道怎么建、密钥怎么存。这三件事任何一件出问题，表现都是“握手失败”，但原因天差地别。

3.1 证书层级与约束：根、子 CA、叶子各管什么

文档第 7.3 节把证书与密钥管理单独拎出来，还专门规定了根证书的数量上限和有效期。这个约束不是拍脑袋定的：车端要长期在野外运行，根证书换一次等于全量设备都要动，所以根证书的有效期必须足够长，而为了降低单点风险，根证书又不能无限堆积。

工程上比较稳的做法是三层结构：

叶子证书里最容易翻车的是扩展字段。服务端证书要能用于服务端认证，客户端证书要能用于客户端认证，两者不能混用。另外，标识符的规范在附录 C 里单独规定，不要把任意字符串塞进主体字段——互操作测试里对方很可能按规则解析。

注意：文档里根证书的数量和有效期是有明确数字约束的，做预置列表时先把这两条查出来，别等到现场再改。

3.2 TLS 落地：版本、双向认证与证书链顺序

第 7.7 节的 TLS 部分是全文密度最高的段落之一。要点归结起来三条：版本不能太旧、必须双向认证、证书链顺序要对。

双向认证意味着车端要验桩、桩也要验车，任何一端信任库里少一个中间 CA，握手就在 Certificate 消息之后直接失败。证书链顺序则是纯工程问题：服务端下发的链必须从叶子开始、逐级往上，最后可选带根。顺序错了，某些实现能靠自动补齐救回来，某些实现直接判失败，属于典型的“在我这好好的，到你那就挂”。

搭测试环境时我习惯用脚本一次性生成整条链，避免手工操作漏字段：

# 1) 根证书：自签，长期有效 openssl req -x509 -newkey rsa:3072 -nodes -days 7300 \ -keyout root.key -out root.crt \ -subj "/CN=Test Root CA" \ -addext "basicConstraints=critical,CA:TRUE" \ -addext "keyUsage=critical,keyCertSign,cRLSign" # 2) 中间 CA：由根签发，注意必须带 CA:TRUE 与 pathlen openssl req -newkey rsa:3072 -nodes -keyout sub.key -out sub.csr \ -subj "/CN=Test Sub CA" openssl x509 -req -in sub.csr -CA root.crt -CAkey root.key -CAcreateserial \ -days 3650 -out sub.crt \ -extfile <(printf "basicConstraints=critical,CA:TRUE,pathlen:0\nkeyUsage=critical,keyCertSign,cRLSign\n") # 3) 叶子证书：区分服务端/客户端用途，SAN 必须写对 openssl req -newkey rsa:2048 -nodes -keyout secc.key -out secc.csr \ -subj "/CN=secc.test" openssl x509 -req -in secc.csr -CA sub.crt -CAkey sub.key -CAcreateserial \ -days 365 -out secc.crt \ -extfile <(printf "basicConstraints=critical,CA:FALSE\nkeyUsage=critical,digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth,clientAuth\nsubjectAltName=DNS:secc.test,IP:fe80::1\n") # 4) 验证链是否完整、顺序是否正确 openssl verify -CAfile root.crt -untrusted sub.crt secc.crt

第一段的关键是CA:TRUE和签名用途，少了这两个，后面所有由它签出来的证书都不被认。第二段的pathlen:0限制了中间 CA 之下不能再挂 CA，这是收敛风险的标准手段。第三段里extendedKeyUsage同时给了两种用途，方便一个证书在测试环境里两种角色都跑，正式环境建议拆成两张。第四段的-untrusted参数就是喂中间证书，输出必须是 OK，这一步别省——省下来的时间会在联调现场十倍还回去。

还有一个非常隐蔽的问题：设备时间。证书有效期校验依赖系统时钟，车端断电久了时钟漂移，握手就会报证书过期或未生效，而日志往往只写一句“握手失败”。排查时先对时间，再怀疑证书。

3.3 密钥保护与随机数：别把安全做在纸面上

文档对密钥保护和随机数生成都有专门要求，这两条在实际项目里最容易被降级处理。

密钥保护的核心问题是私钥存在哪。放在普通文件系统里，只要设备被物理接触，私钥就等于公开。合理做法是放进受保护的存储区或者独立的安全芯片，私钥不出芯片，签名运算在芯片内完成。做到这一步，即使系统被拿到 root，私钥也拿不走。

随机数这一条更微妙。所有密钥生成、会话随机数、挑战值都依赖熵源，熵源质量差，密钥的可预测性就上去了。嵌入式设备常见的毛病是启动早期熵池没攒够就去生成密钥，出来的东西看着是随机的，实际熵很低。工程上的做法是延迟到熵池可用再生成，或者使用硬件随机源。

还有防火墙那一条，文档把它放在安全概念里而不是网络层里，意思很明确：默认拒绝，只放行必要的端口和方向。这条在测试阶段经常被关掉图方便，然后忘了打开。

4. 应用层消息与时序：握手、服务选择与充电会话怎么排

从第 8 章开始进入应用层，这里的篇幅最长，从消息定义到复杂数据类型，再到时序和错误处理。读这一章的正确姿势是先看时序图，把阶段划分清楚，再回头逐个查消息字段。反过来读，会被几百个字段名淹没。

4.1 从对端发现到会话建立：身份是怎么被“认领”的

一次完整会话的第一步是应用层协议握手，通过一对supportedAppProtocol请求和响应完成。这一步协商的是双方支持的协议版本和能力集合，谈不拢就没有后续。握手成功后进入会话建立，服务端分配一个会话标识，之后所有消息都要带这个标识。

会话标识的意义在于多路复用。同一个物理连接上可能同时跑多个逻辑会话，靠标识区分。所以实现里不要把会话标识当成全局单例，也不要假设一个连接只有一个会话。

这一段最常见的失败是版本协商不匹配：车端只报了一个版本，桩端只支持另一个，双方都“按标准实现”，结果谈不拢。定位方法是把这一对消息原样打出来看，别只看最终的错误码。

4.2 服务选择与参数协商：交流与直流在这里分岔

握手之后是服务发现和服务选择，把“我要充什么、怎么充”讲清楚。之后进入充电参数协商阶段，交流充电和直流充电在这里开始走不同的路径：直流的控制粒度更细，涉及预充、绝缘检测、电流需求等一串阶段，交流相对来说简单一些。

服务选择阶段还有一个容易踩的点：服务参数是可以协商的，不是单方面宣布。车端提出一组参数，桩端可以接受、可以还价、也可以拒绝。实现时不要写成“要么全接受要么失败”，中间态是标准允许的。

时序上，标准为每个阶段定义了期望的完成窗口。这些窗口在秒级，目的是防止对端卡死导致整条链路挂住。实现里必须为每个等待状态配一个超时，超时后走错误处理流程，而不是无限等。见过不止一个实现把超时设成了“不超时”，理由是“现场网络慢”，结果是一个异常状态把整个充电站的服务线程全占了。

4.3 消息头、会话标识与 ResponseCode 的处理策略

所有应用层消息共用一个消息头结构，里面至少包含会话标识和时间戳。时间戳不是装饰，对端可以用它做重放检测和时序校验，做时钟不同步的容错时要考虑它。

响应码是这一章最需要下功夫的地方。它分两类：成功的码和失败的码。成功里有一种特殊情况需要单独处理——表示“会话是新建的”。收到这个码，客户端要更新本地会话标识，而不是当成普通成功继续走。

失败码的处理策略是工程分水岭。合格的实现会把失败码分类：可重试的、必须终止会话的、需要重新协商参数的。不合格的实现统一打一条日志然后断开。两者的差别在现网里非常明显，前者能在参数不匹配时自动降级跑通，后者只能靠人工介入。

<!-- 应用层消息骨架示意：头 + 请求体，实际传输时为 EXI 编码 --> <V2G_Message> <Header> <SessionID>0000000000000000</SessionID> <TimeStamp>2022-04-01T00:00:00.000Z</TimeStamp> </Header> <Body> <SessionSetupReq> <EVCCID>001122334455</EVCCID> </SessionSetupReq> </Body> </V2G_Message>

这段骨架的关键在层级：消息头是共用的，请求体按消息类型换。写编解码器时要按这个结构分层实现，别给每种消息单独写一套头部解析。会话标识在首次建立前是占位值，建立后填充服务端返回的值，这一步漏了，后面所有消息都会被判为会话不匹配。时间戳用带毫秒的 UTC 格式，本地时间会直接导致对端判定超时。

提示：附录 A 的 schema 是规范性的，字段顺序和必选性以它为准，示例只能当结构参考。

4.4 错误处理与消息序列：序列要求不是建议

第 8.6 节专门讲消息序列与错误处理，其中“请求-响应序列要求”这一条在互操作里权重很高。它规定的是：哪些消息必须先请求后响应、哪些可以乱序、哪些必须在特定状态下才能发。

实现上的做法是给每条连接维护一个状态机，收到消息先校验“当前状态下这条消息合不合法”，不合法直接回失败码，不要往下走业务逻辑。这个校验层的代码量不大，但能挡掉绝大多数互操作问题。

多路复用那一段也值得看。它规定了在同一连接上并发多个会话时的行为约束，包括消息如何归属到会话、冲突时怎么处理。如果你的实现是单会话的，至少要在收到别的会话标识时明确拒绝，而不是静默丢弃。

5. 排错与避坑：五类翻车现场的定位路径

这一节列的五个问题，都是在联调现场反复出现的。共同点是：日志里只有一句失败，真正的原因在另一层。

现象一：插入充电枪后完全抓不到对端发现报文。原因通常是接口没有 IPv6 链路本地地址，或者没有加入链路本地组播组，报文发不出去；也可能是本机防火墙默认拒绝，把 UDP 入站挡了。解决路径是先用ip -6 addr确认地址、用ip -6 maddr确认组播成员，再临时放开防火墙验证，确认后再按最小放行原则加回规则。顺序别反，先改防火墙会掩盖真实原因。

现象二：报文发出去了，对端也能收到，但响应回不来。原因多半在邻居发现，地址解析没完成，报文被丢弃。这个现象和对端不响应几乎一模一样，唯一的区分办法是同时抓 ICMPv6。解决办法是检查链路上的地址冲突、确认两端在同一个链路本地网段、确认没有中间设备做隔离。

现象三：TLS 握手在证书阶段失败，对端只说“验证不通过”。常见原因有三个：一是证书链顺序错，服务端没有下发完整的中间证书；二是叶子证书缺少对应的用途扩展，服务端证书没有服务端认证用途，客户端证书没有客户端认证用途；三是设备时钟偏差导致有效期校验失败。解决时按这个顺序查：先用openssl verify在本地验一遍链，再看扩展字段，最后对时间。前三步能覆盖九成情况。

现象四：EXI 解码不报错，但字段值全是空或者错位。原因是两端 schema 版本不一致，或者 EXI 的编码选项不一致。这个问题的麻烦之处在于它是静默的，程序照常往下跑，直到某个业务字段取到空值才炸。解决办法是固定 schema 版本并在会话建立阶段交换版本信息，把不匹配挡在早期；同时在解码后加一层必填字段校验，不要信任解码结果。

现象五：会话跑到一半返回失败，重连又能跑一段。原因通常是会话标识丢失或被覆盖、等待超时设置不合理、多路复用下消息归属判断错误。解决办法是把每个阶段的进入和退出都打点，记录会话标识和耗时，复现时按时间轴对齐两端的日志。只打最终错误码的日志在这种问题面前基本没用。

注意：这五类问题里有三类是“看着像网络问题、实际是配置问题”，排查时先怀疑配置，再怀疑实现。

6. 把附录当检查表用：三个交叉验证习惯

正文读完只是开始，这份文档真正的价值有一半在附录里。附录 A 是规范性 schema，附录 B 是规范性证书配置文件，附录 C 规定标识符，附录 I 给测量精度与容差，附录 J 给绝对定价的算例，剩下几个信息性附录覆盖自动连接装置、互操作基础流程、重协商序列、增值服务会话关联和证书应用。

我的用法是把它们分成三组交叉验证。

第一组是附录 A 和附录 B，用来验“静态正确性”。写完编解码器和证书签发流程后，拿附录 A 的 schema 跑一遍样例消息，看能不能全部通过校验；拿附录 B 的配置文件逐条比对生成的证书扩展字段，一条一条勾。这一步花两小时，能省掉现场两天。表格形式更适合这种核对：

第二组是附录 I 和附录 J，用来验“数值一致性”。这两个附录容易被当成参考资料跳过，实际上它们定义了验收阈值。测量精度和容差决定了什么算“一致”，定价算例决定了金额怎么算。两端各自按自己的理解实现，跑起来数值差一点点，业务层就会判定失败。做法是直接把附录里的算例抄成单元测试用例，输入输出照抄，跑通即对齐。

第三组是那几个信息性附录，用来验“时序合理性”。它们不是强制要求，但描述了典型场景下消息该怎么排。重协商序列和增值服务会话关联这两个尤其值得看，因为它们描述的是主流程之外的支线，而支线往往是自己实现里最薄弱的部分。

最后一个具体技巧：把正文里每条带编号的需求抄进一张表，加上三列——“实现位置”“测试用例”“验证状态”。这张表会随着项目推进变成最可靠的进度看板。我吃过一次亏，某个错误处理分支在需求表里一直空着，评审时也没人注意，结果现网遇到对端返回异常码，程序直接卡死，重启才能恢复。从那以后，每次交付前都强制走一遍需求表，空着的行必须给出“不适用”的理由并写明依据，不允许留白。希望帮到你。

本文还有配套的精品资源，点击获取