简介ISO 15118-20-2022是国际标准化组织正式发布的电动汽车与电网通信接口标准聚焦第二代网络层和应用层技术规范目标人群覆盖充电桩制造商、整车企业、通信协议开发与测试工程师用于解决车辆与充电设施之间数据互联、身份认证、计费与安全传输等互操作性问题。资源为一份完整英文原版PDF标准文件共1个PDF压缩包整体34.74MB方便离线查阅和精读。标准内容从适用范围、规范性引用、术语与缩略语入手随后基于OSI分层模型给出服务定义和需求结构详细规定网络层的路由选择、错误检测机制以及应用层的身份验证、充电状态监控等功能要求可为协议栈实现、合规性验证和测试用例设计提供直接依据。对从事V2G系统预研与标准化落地的专业人员这份资料能有效支撑技术方案评估和产品开发当前已有157人学习下载属于充电通信领域的权威一手文献。1. 车辆与电网通信接口ISO 15118-20-2022 到底解决了什么插上充电枪扫码、App 启动、等待握手、再等鉴权这一套流程在公共充电桩上几乎成了固定动作。而 ISO 15118-20-2022 要做的就是把上面这套人工操作压缩成“插枪即充”。它是车辆与电网通信接口Vehicle to Grid Communication Interface的第二代正式版本2022 年发布核心变化是引入了双向能量传输BPT)、更强的即插即充PnC机制以及更严格的 TLS 1.3 安全通道。做充电桩协议栈、做车端充电控制器、做充电运营平台对接的人迟早要和这个标准打交道。这篇笔记从协议栈选型、最小通信链路、参数配置到现场踩坑按一条能复现的路径讲清楚。2. 协议栈选型为什么 2022 版坚持 TCP TLS 1.3而不是继续用 UDP和充电通信打过交道的人都会问一个问题15118-2 时代还能看到 UDP 和 TLS 1.2到了 15118-20 为什么几乎一刀切答案藏在充电安全性和互操作性要求里。2.1 15118-20 与 15118-2 的关键差异ISO 15118-20 不是对 15118-2 的小修小补而是把通信架构重新理了一遍。下面这张表是我在选型时最常拿出来对比的能力项15118-215118-20传输层TCP TLS 1.2DC 场景UDP SLACAC 场景TCP TLS 1.3 为主AC 场景保留自动连接简化流程双向能量传输V2G/V2H不支持支持 BPTPowerSchedule 可下发双向功率曲线即插即充PnC有但证书策略分散统一合同证书与 TLS 证书链支持证书续期数据编码EXI 但有较多可选分支EXI 状态更收敛schema-informed 是必选路径消息扩展每家厂商自己加私有字段引入 Entity/Attributes扩展方式标准化这个表格透露出的选型信号很明确如果你从零起步做车端或桩端协议栈直接基于 15118-20 是性价比最高的路径。因为 15118-2 里的 SLAC 流程在 AC 充电场景中依赖电力线通信PLC物理层调试时要在示波器上看电力线信号团队没有电力线通信经验的话周期会拉得很长。而 15118-20 在 AC 场景引入了更简化的连接识别流程虽然物理层还是 PLC但应用层的交互复杂度明显下降。2.2 传输层设计V2GTP 消息封装与 TCP 的关系15118 系列的核心传输协议叫 V2GTPVehicle to Grid Transport Protocol。V2GTP 做的事情很少就是在 TCP 或 UDP 之上加一个 8 字节的消息头用来标识消息类型和负载长度。15118-20 里最常见的组合是 V2GTP over TCP over TLS 1.3。为什么不是裸 TLS因为车端和桩端之间的会话状态机要求消息有明确的“会话标识”V2GTP 头里带上 session ID状态机才能把充电控制消息和 TLS 记录一一对应。我在做模拟项目 X 的协议栈时曾经纠结过要不要省掉 V2GTP 这层直接 TLS 包 XML。后来发现不行电力线通信链路的误码率比以太网高一个数量级TCP 重传还能接受但消息边界如果靠 TLS 记录自己切分到了链路质量差的现场充电桩经常出现半个消息的诡异问题。V2GTP 的 8 字节头让接收方可以先行校验载荷长度切包错误的概率明显下降。2.3 EXI 编码把 XML 压成二进制但没你想的那么玄15118-20 应用层消息本质是 XML Schema 定义的文档但传输时用 EXIEfficient XML Interchange编码。EXI 不是简单地把 XML 压缩成 zip而是利用 Schema 里的 grammar 规则把标签名和结构信息映射成紧凑的二进制事件码。比如一条ChargingStatus消息XML 文本可能要 300 字节EXI 编码后通常 30 字节左右这在低速电力线通信链路上非常关键。但 EXI 有一个容易翻车的地方编码器和解码器必须使用严格一致的 Schema。我遇到过现场桩端和车端 Schema 版本不一致车端发出来的 EXI 流桩端解码乱码最后定位是车端用了带扩展字段的 Schema桩端用的是基础 Schema。所以做协议栈时EXI 的 Schema 文件要作为版本管理的核心资产和固件版本号一起发布不能只锁代码版本不锁 Schema 版本。3. 跑通最小通信链路从 SDP 到 ChargeService 的完整消息流理论说完就上手。这一章的目标是在本地环境搭一对 EVCC车端和 SECC桩端协议栈跑通一次最小充电会话并用抓包工具验证每个关键节点。3.1 准备最小测试环境开源协议栈与抓包工具我常用的组合是某社区开源的 15118 协议栈实现跑 SECC另一套轻量 EVCC 模拟器跑车端加上 Wireshark 的 V2GTP 解析插件。做互通性测试前先用 openssl 生成临时的 TLS 证书链下面是初始化脚本# 生成临时根 CA、合同证书和 TLS 证书用于本地互通测试 mkdir -p /tmp/v2g_certs cd /tmp/v2g_certs # 1. 根 CA openssl req -x509 -newkey rsa:2048 -nodes \ -keyout rootCA.key -out rootCA.pem \ -subj /CNV2G Test Root CA -days 365 # 2. SECC 的 TLS 证书桩端证书叶子证书 openssl req -newkey rsa:2048 -nodes \ -keyout secc.key -out secc.csr \ -subj /CNsecc.test.local openssl x509 -req -in secc.csr -CA rootCA.pem -CAkey rootCA.key \ -CAcreateserial -out secc.pem -days 180 # 3. EVCC 的合同证书用于 PnC 鉴权演示 openssl req -newkey rsa:2048 -nodes \ -keyout evcc_contract.key -out evcc_contract.csr \ -subj /CNEVCC Contract Cert openssl x509 -req -in evcc_contract.csr -CA rootCA.pem -CAkey rootCA.key \ -CAcreateserial -out evcc_contract.pem -days 180 # 4. 将根 CA 放入双方信任库模拟桩端和车端都信任同一根 cp rootCA.pem /tmp/v2g_certs/trust_root.pem注意这里生成了两组证书TLS 证书用于建立安全通道合同证书用于 PnC 鉴权。很多第一次做 15118 的人会把这两个概念搞混以为 TLS 证书就是鉴权证书。实际上 TLS 证书保证通道安全合同证书才代表“这张卡是哪个运营商发的”。在 15118-20 里合同证书的扩展字段里包含了 e-mobility 运营商标识桩端拿到后会到后台做二次校验。3.2 先过 SDPEVCC 怎么找到 SECC 的 15118 端口EVCC 上电后不知道桩端的 IP 和端口需要先发一条 V2GTP SDPService Discovery Protocol消息。这条消息走 UDP目的端口固定是 15118。SECC 收到后回复一组端口信息EVCC 再拿着这个端口去建立 TLS 连接。用 tshark 抓这个过程的命令# 抓取 SDP 阶段的 UDP 15118 端口流量 tshark -i eth0 -f udp port 15118 -Y v2gtp -T fields \ -e frame.time_epoch \ -e ip.src -e ip.dst \ -e v2gtp.payload_type \ -e v2gtp.length正常会看到类似下面的输出EVCC 先发一条 payload type 为 0x0001SDP Request的消息SECC 回 0x0002SDP Responseresponse 里带着后续要连接的 TCP 端口号。如果这里只看到请求没有响应先别查协议栈用nc -u -p 15118探测一下 SECC 所在主机的 15118 端口是否真的在监听。一个非常常见的坑是 SECC 进程起来了但绑定的网卡不是 EVCC 能路由到的那块导致 UDP 不通。3.3 状态机最小会话从 SessionSetup 到 ChargeServiceSDP 通了之后EVCC 和 SECC 之间的消息流是严格按状态机走的。最小一个充电会话的消息顺序如下步骤消息方向消息类型作用1EVCC → SECCSessionSetupReq带上会话 ID双方开始新会话2SECC → EVCCSessionSetupRes返回会话 ID 和超时参数3EVCC → SECCServiceDiscoveryReq查询支持哪些服务AC/DC/BPT4SECC → EVCCServiceDiscoveryRes返回服务列表和选项5EVCC → SECCServiceDetailReq查询具体服务参数6SECC → EVCCServiceDetailRes返回功率限额、能量传输模式7EVCC → SECCPaymentServiceSelectionReq选择支付方式PnC 或外部支付8SECC → EVCCPaymentServiceSelectionRes确认支付方式9EVCC → SECCChargeServiceReq请求进入充电服务10SECC → EVCCChargeServiceRes确认并等待 CableCheck这一步我建议用协议栈自带的命令行工具逐步触发而不是直接跑完整自动流程。原因很简单手动控制每一步哪个环节字段填错一目了然。比如 ServiceDiscoveryRes 里的 ServiceID 如果与请求里的不匹配后续 ServiceDetail 阶段就会直接断掉。用自动流程出问题后你不知道是 SecureChannel 断的还是服务发现阶段断的。4. 参数配置证书、超时和 AC/DC 模式怎么设才对跑通最小链路只是第一步。真正到量产和现场部署决定成败的是参数配置。这一章列出我实测过的几个关键配置维度。4.1 证书体系PnC 模式下的信任链与 TLS 1.3 会话恢复15118-20 的 PnC 依赖两级 PKI根 CA 签发合同证书根 CA 同时也要签发桩端的 TLS 证书。做互通性测试最常见的做法是自建根 CA把根证书刷进车端和桩端的信任库。验证证书链是否有效可以用 openssl# 验证 SECC 的 TLS 证书是否由自建根 CA 签发 openssl verify -CAfile /tmp/v2g_certs/trust_root.pem \ /tmp/v2g_certs/secc.pem # 检查证书有效期和扩展字段注意 ISO 15118-20 要求 TLS 证书带 id-on-v2g 扩展 openssl x509 -in /tmp/v2g_certs/secc.pem -text -noout | grep -A 2 TLS WWWTLS 1.3 相比 1.2 有个重要变化会话恢复机制从 session ID 换成了 pre-shared keyPSK。EVCC 第一次和 SECC 建立 TLS 通道后SECC 可以下发一个 session ticket之后 EVCC 重连时用这个 ticket 直接恢复会话省掉一次完整的握手。但注意session ticket 的有效期默认往往只有几分钟到几小时而充电会话可能持续几十分钟。如果 SECC 实现里 ticket 生命周期太短充电中途网络抖动重连EVCC 带着过期 ticket 去恢复会话TLS 握手直接失败状态机退到 SessionSetup 从零开始。我一般把 session ticket 有效期设成至少 8 小时同时打开 TLS 1.3 的 early_data 支持减少握手往返。4.2 超时参数状态机不往前走的时候先查这里现场最让人抓狂的故障是“消息都发了但就是没响应”。绝大多数情况下不是协议栈 bug而是超时参数没配对。15118-20 里面几个关键超时参数参数名建议值影响V2GTP 消息响应超时5 秒超过后 EVCC 重发同一条消息TLS 握手超时10 秒超过后断开连接CableCheck 超时2 秒AC 场景可放宽超过后进入错误状态PowerDelivery 超时5 秒超过后停止充电流程SessionStop 等待超时3 秒超过后立刻断开 TCP注意 EVCC 和 SECC 两端的超时参数不一定是同一个值。比如 EVCC 端的消息重发间隔是 5 秒但 SECC 端的消息处理超时是 8 秒那 EVCC 在第一次消息还没超时前不会重发看起来一切正常。反过来如果 SECC 端超时设成 3 秒EVCC 5 秒才重发SECC 早就把连接断了。所以做联调时第一件事就是交换两边的超时配置表把重发机制和超时机制对齐。这条血泪经验是从某跨平台系统的联调里总结出来的双方各执一词说对方不回应最后发现一方超时 3 秒、另一方重发间隔 5 秒永远接不上。4.3 DC 与 AC 场景配置差异15118-20 对 DC 充电和 AC 充电的配置要求差异很大。DC 场景需要配置 CableCheck 的绝缘检测参数、电压电流限额AC 场景则要配置电源相位和通信方式。一个容易忽略的点DC 场景的 ChargingStatus 里会带物理电压电流值EVCC 可以根据这个值做闭环而 AC 场景的 ChargingStatus 只有目标功率没有实际电压电流反馈因为 AC 充电桩通常不配置直流侧采样电路。如果你的后台要实时展示充电功率AC 场景建议从电能表读取数据不要依赖 15118-20 消息里的状态值。5. 避坑指南现场最常见的 6 个 15118-20 互操作故障做了几个月的 15118 互通性测试我把问题分为几类。每一类我都按“现象 → 原因 → 解决”的顺序记录在这照着查能省一大半时间。5.1 现象插枪后 EVCC 发送 SDP 请求但 SECC 没有任何响应原因这是最常见的第一个故障。SECC 进程绑定的网卡和 EVCC 不在同一个广播域或者 SECC 主机防火墙把 UDP 15118 拦了。还有一种情况是 EVCC 用的是旧版 SLAC 流程先发 SLAC 配对再发 SDP而 SECC 只支持 15118-20 的自动连接两边跳不到一个频道。解决先用nc -u -l 15118在 SECC 主机上裸监听确认网络层能收到 UDP 包再逐步排查防火墙和网卡绑定。SLAC 版本不匹配的问题只能在协议栈配置里显式指定“仅使用 15118-20 自动连接”模式两端都用新流程。5.2 现象TLS 握手阶段失败openssl 报证书链不完整原因EVCC 的信任库里只有根 CA 证书但 SECC 在 TLS 握手里发送的是叶子证书 中间 CA 证书且中间 CA 不在 EVCC 信任库里。这和 HTTPS 证书链的问题一模一样。自建根 CA 测试时如果生成叶子证书时没有中间 CA理论上不会出现这个问题但只要用了企业 CA就一定会遇到。解决把中间 CA 证书一并刷进 EVCC 信任库或者让 SECC 在 TLS 握手时发送完整的证书链。用openssl s_client -connect secc_ip:port -showcerts可以看到 SECC 实际发了哪些证书。5.3 现象SDP 通了、TLS 通了但 EXI 解码乱码原因双方 Schema 不一致。最常见的是 EVCC 用的是 15118-20 Edition 1 的 Schema而 SECC 用的是 15118-20 AMD1 的 Schema两者在 ServiceDiscoveryRes 里新增了几个枚举值。EXI 是 grammar 驱动的编码任何一个枚举不匹配都会让整段二进制失效。解决确认两边的 EXI schema 文件哈希一致把 Schema 版本和固件版本绑定发布。这个比代码版本管理更严格Schema 文件一字不能差。5.4 现象充电到一半断开状态机回到 SessionSetup原因TLS 1.3 session ticket 过期。很多实现默认把 ticket 生命周期设为 5 分钟充电会话必然超过这个时间。如果链路闪断重连时 ticket 失效就得完整重新握手。虽然协议栈会重新走 SessionSetup但如果正好在 CableCheck 阶段就可能触发安全错误。解决把 SECC 端的 ticket 生命周期调到 8 小时以上同时让 EVCC 在重连时自动重新发起 ServiceDiscovery而不是认为之前的服务列表还有效。5.5 现象桩端后台显示充电功率为 0但车端显示正在充电原因AC 充电场景下桩端是继电器的“开关模式”只做通断不做调压而车端认为自己在以目标功率充电。实际功率在电能表里15118-20 的 ChargingStatus 里没有实时电流值后台如果直接读这个字段就会得到 0。解决后台的实时功率展示直接从电能表采集15118-20 状态机里的 ChargingStatus 只用来判断充电是否激活不做计量展示。计量以电能表为准这个习惯要建立起来。5.6 现象声望很高的互操作测试工具测过但现场就是连不上原因测试工具通常跑在理想网络条件下忽略了电力线上的噪声和丢包。电力线通信的物理层和以太网完全不同现场插座回路里的电器开关噪声会让 PLC 信号瞬间衰减。解决做现场测试时不要只看应用层消息先通过 Wireshark 的 PLC 解析插件看电力线链路的信噪比。如果信噪比低于某个阈值就要在桩端的 PLC 模块上增加发射功率或更换耦合电路。这是硬件层面的事软件改再多也没用。6. 进阶验证从最小会话到双向能量传输的检查清单如果你做的是 V2G 或 V2H 场景15118-20 的双向能量传输BPT是必须验证的模块。和普通单向充电相比BPT 验证多三个关键步骤。6.1 验证 PowerSchedule 的双向功率曲线BPT 的核心在 ServiceDetail 阶段的 PowerSchedule 参数里。对比单向充电BPT 会多出 DischargePowerLimit、DischargeEnergy 等字段。抓包时用下面的 tshark 过滤表达式# 抓取 PowerSchedule 相关消息确认双向功率参数 tshark -i eth0 -Y v2gtp (frame contains DischargePowerLimit || frame contains PowerSchedule) \ -T fields -e v2gtp.message_name -e v2gtp.payload正常情况下在 ServiceDiscovery 之后会看到 EVCC 请求 BPT 服务SECC 返回的 ServiceDetailRes 里带有放电功率上限。要注意的是有些 SECC 实现虽然返回了 BPT 服务但 ChargingStatus 里没有对应的物理量采样这时候 EVCC 会认为桩端不具备双向充电能力。验证时除了看协议消息还要看 SECC 后台是否真的为放电方向设置了功率调节算法。6.2 我的建议量产前补上这三项自动化检查第一做 TLS 会话恢复的自动化测试断开 TCP 连接 1 分钟、5 分钟、30 分钟分别验证重连是否走 PSK 恢复并记录恢复成功率和握手耗时。这个测试最容易暴露证书问题和超时参数问题。第二做 EXI Schema 一致性的 CI 检查把 EXI Schema 文件的哈希记入构建产物固件发布时自动比对订单版本和车端协议的 Schema 哈希。第三做断电恢复测试让充电桩在 CableCheck、PowerDelivery、ChargingStatus 三个阶段分别断电确认状态机可以回到 SessionSetup 或正确进入错误状态而不是卡死。我在早期做模拟项目 X 时一直以为 TLS 通道和 EXI 解码没问题整个充电流程就稳了。直到有一次现场测试中断电恢复后桩端进程直接退出才发现恢复逻辑只处理了断连事件没处理 TLS 重连事件。后来把所有异常路径写成了测试用例每次版本发布先跑一遍踩坑数量才真正降下来。希望这篇笔记能帮你少走几步弯路。本文还有配套的精品资源点击获取