车桩协议：从第一性原理理解一次安全充电如何发生

把一辆电动汽车接到充电桩上，看起来只是“插枪，然后送电”。但从控制系统的角度看，车辆和充电桩是两个彼此独立的设备：

• 车辆知道电池当前能承受多少电压、电流和温升；
• 充电桩知道自己此刻能提供多少功率；
• 双方一开始并不知道对方的能力、状态和故障；
• 电池允许的充电功率会随着SOC、温度和单体电压不断变化；
• 通信可能中断，传感器、接触器和功率模块也可能故障；
• 一旦在错误的时间接通或断开高压，可能产生冲击电流、电弧或设备损坏。

因此，车桩协议要解决的根本问题不是“怎样传输几组数据”，而是：

两个能力未知、状态持续变化的独立设备，如何在安全约束下建立共同认知，并协同完成可控、可停止、可追溯的能量传输？

这使车桩通信成为一种跨设备、实时、带安全约束的分布式控制过程。

第一层：所有协议都面对四个共同目标

无论采用GB/T、CHAdeMO还是ISO 15118，协议族首先都要面对四个无法绕开的目标。

1. 能力必须匹配

车辆需要的电压和电流必须处于充电桩能够提供的范围内。实际输出还不能超过枪线、功率模块、温度降额和站级功率分配的限制。

可以把最终允许输出理解为所有边界的交集：

最终允许功率 = min（车辆允许，充电桩能力，连接器能力，温度限制，站级限制）

因此，“120 kW充电桩”不等于车辆在整个充电过程中都能获得120 kW。

2. 高压动作必须遵守安全时序

开始充电时，系统不能先接通高压再检查条件，而应依次完成：

确认连接
→ 检查接地、锁止和绝缘
→ 交换双方能力
→ 确认双方就绪
→ 建立接近电池电压的桩端输出
→ 闭合高压回路
→ 逐步提升电流

停止时顺序大体相反：

停止升功率
→ 降低电流
→ 关闭功率输出
→ 断开接触器
→ 泄放残余电压
→ 确认枪口安全
→ 允许解锁拔枪

3. 充电功率必须动态调整

电池的允许能力并非常数。BMS会根据SOC、温度、单体电压和健康状态持续重新计算充电边界。

车辆BMS计算允许能力
        ↓
发送目标电压、电流或功率约束
        ↓
充电桩结合自身限制进行仲裁
        ↓
控制功率模块输出
        ↓
反馈实际电压、电流和状态
        ↓
车辆BMS再次计算

这就是车桩之间的实时控制闭环。

4. 任何失败都必须导向安全状态

协议不仅要描述正常充电，还必须处理：

• 通信超时或链路中断；
• 车辆请求值越界；
• 实际输出偏离目标；
• 绝缘下降、枪口过温或接地异常；
• 接触器粘连；
• 车辆或充电桩主动报故障；
• 用户、平台或急停装置发出停止指令。

不同故障可能触发降额、受控停机或紧急切断，但最终都必须使系统回到可证明安全的状态。

第二层：把根本问题拆成九个子问题

一次完整充电可以通过九个问题逐步建立双方的共同认知。

子问题	必须得到的答案	主要实现位置
1. 是否连接可靠？	插枪、接地、锁止和辅助电源是否正常	控制导引、硬件、公共框架
2. 能否正常通信？	链路、协议版本、消息收发和对端存活是否正常	协议传输层和状态机
3. 对方是谁？	车辆、电池、充电机和可选合同身份是什么	协议报文与身份服务
4. 双方能力是否匹配？	电压、电流、功率和功率方向是否存在交集	协议适配器与公共模型
5. 当前是否允许供能？	授权、安全检查和双方就绪是否全部成立	公共安全框架最终裁决
6. 如何安全接通高压？	预充、电压差和接触器时序是否正确	公共框架与硬件控制
7. 此刻应该输出多少？	车辆需求与所有设备限制的交集是多少	协议提供需求，公共框架仲裁
8. 系统是否仍然健康？	数据是否新鲜，通信和实际输出是否正常	看门狗、诊断和安全监督
9. 如何停止并留下记录？	怎样安全下电，停止原因和统计结果是什么	公共框架、协议和运营系统

这九个问题并不都由一本“通信协议”单独解决。完整的车桩体系通常由连接器标准、控制导引、数字通信、电气安全和一致性测试共同组成。

例如，当前传统国标直流体系包括GB/T 20234.3连接装置、GB/T 18487.5充电系统以及GB/T 27930.2数字通信等标准。GB/T 27930.2规定非车载充电机与车辆之间的数字通信，而充电系统和接口的安全要求还要由配套标准共同完成。¹

第三层：观察一次车桩交互

下面的动画以传统国标直流充电为例，把车和桩的交互压缩为八个阶段。可以自动播放，也可以逐步查看。

如果当前阅读器没有显示动画，可以 单独打开车桩协议演示。

演示边界

动画用于解释共同的控制逻辑和职责边界。阶段名称、报文名称、先后顺序、定时要求和故障动作，应以产品适用的正式标准版本为准。

连接：先证明物理关系成立

车辆和桩首先通过控制导引确认枪已插入、保护接地正常、电子锁锁止。此时数字通信可能尚未建立，高压输出必须保持关闭。

握手和辨识：建立“我们正在和谁通信”

双方建立CAN、PLC或其他通信链路，确认协议版本和对端存活。随后交换车辆、电池和充电机的身份或能力信息。

不同协议从这里开始表现出明显差异：

• GB/T和CHAdeMO主要使用CAN短报文；
• CCS体系通常使用PLC建立IP通信；
• ISO 15118还可能建立TLS安全会话并处理合同证书。

协商：建立双方都能接受的边界

车辆给出电池允许的最大电压、电流或功率约束，充电桩给出自身输出范围。协议帮助双方交换信息，但最终输出还要受到公共安全和设备能力限制。

就绪和预充：协议同意不等于立即供电

即使车辆通过协议报告“已准备好”，公共框架仍要检查：

• 用户是否已授权；
• 绝缘和接地是否正常；
• 枪是否锁止；
• 接触器是否存在粘连；
• 功率模块是否可用；
• 是否存在急停或严重故障。

只有全部条件满足，系统才允许预充和闭合高压回路。

实时充电：协议建立闭环，公共框架控制边界

以常见CAN直流协议为例：

车辆：请求 400 V、180 A
充电桩：当前只能安全提供 120 A
公共框架：批准 400 V、120 A
充电桩：实际输出 398 V、118 A
车辆：根据温度和SOC重新计算下一周期需求

协议负责传递需求和反馈；公共框架负责判断是否允许执行，以及最多执行多少。

停止和统计：先处理能量，再处理消息

正常停止时，双方通过协议交换停止请求和原因，同时公共框架执行降流、关闭输出、断开接触器和残压确认。

如果发生严重电气故障，安全动作不能等待协议握手完成：

安全监督器发现严重故障
→ 立即禁止危险能量
→ 协议模块尽可能通知对端并记录原因

会话结束后，车桩协议可以交换最终SOC、温度和停止原因；电量计费、订单和支付通常由桩云及运营系统完成。

第四层：协议与公共框架如何分工

理解多协议架构的关键，是不要把“协议流程”和“整桩控制”混成一套巨大状态机。

责任	协议适配器	公共充电框架	硬件执行层
建立CAN或PLC通信	主责	监控结果	收发器、PLC模块
报文编解码和协议定时	主责	不理解原始字段	—
车辆身份和能力解析	主责	保存统一模型	—
车辆就绪和停止事件	产生事件	汇总条件并决策	—
绝缘、接地和枪温	接收结果并通知车辆	监督和裁决	检测及采样
最终功率计算	提供车辆需求	主责	—
预充和接触器动作	配合协议状态	主责	执行动作
功率模块输出	反馈协议状态	下发安全目标	执行和反馈
安全停止	发送或接收停止信息	主责	切断和泄放
订单、计费和桩云	提供车辆侧信息	主责	电表提供数据

可以用一句话记忆：

协议负责让双方形成共同认知；公共框架负责作出安全决策；硬件负责执行能量动作。

正确的数据边界是：

协议 → 公共框架：
车辆是谁、能接受什么、现在需要什么、是否就绪、是否要停止

公共框架 → 协议：
充电桩能提供什么、实际输出了什么、是否发生故障、会话处于什么状态

协议模块不应直接调用“闭合接触器”或“输出200 A”之类的硬件函数，否则每增加一种协议，都要重新证明一套安全逻辑。

多协议共享架构

下面的架构图展示了支持多种车桩协议时，哪些部分应该独立，哪些能力可以共享。点击GB/T、CHAdeMO或ISO 15118，可以查看各自的接入路径和预计复用范围。

如果当前阅读器没有显示架构图，可以 单独打开多协议共享架构。

图中的关键边界是“统一车辆需求与事件模型”。协议适配器在边界之上处理各自的通信介质、报文和状态机；边界之下的会话管理、安全监督、功率仲裁、硬件控制、计量和桩云能力可以被多种协议共同使用。

复用比例的含义

图中的共享比例是用于架构和工作量判断的经验区间，不是标准给出的固定数值。实际比例取决于连接器硬件、协议版本、PnC、V2G、认证范围以及现有公共框架的抽象质量。

第五层：不同协议怎样回答相同的问题

主流协议面对的物理问题相同，但采用的通信技术和业务范围不同。

比较项	GB/T国标直流	CHAdeMO	CCS / ISO 15118
主要通信方式	CAN	CAN	PLC上的IP通信
典型控制方式	BMS周期请求，桩限幅执行	车辆周期请求，桩限幅执行	当前需求或功率计划协商
身份认证	通常由App、卡或云平台完成	通常由外部系统完成	可使用合同证书Plug & Charge
信息安全	相对基础，依赖系统整体保护	依版本和外部体系	TLS、PKI和数字证书
双向充放电	取决于具体系统和版本	实际应用和认证经验较早	ISO 15118-20定义双向传输消息和时序
主要实现难点	CAN定时、状态机和车型兼容	专用导引、状态机及V2G	PLC、IP、TLS、EXI、证书和计划

ISO 15118系列不仅讨论能量传输，还覆盖身份、支付相关信息、负荷平衡、网络安全和隐私等使用场景。² ISO 15118-20进一步规定了双向功率传输的通信消息和时序要求。³

CHAdeMO同样使用CAN控制直流充电，并较早发展了V2H/V2G应用和认证体系。⁴

所以，不同协议并不是解决完全不同的问题，而是在共同问题之上选择了不同方案：

基础层：连接、安全、能力匹配、动态控制和安全停止
                    ↓
技术选择：CAN、PLC/IP、周期报文或网络会话
                    ↓
高级业务：自动认证、证书、价格、功率计划和双向调度

第六层：最终要实现哪些软件部分

从工程实现看，一套车桩协议可以继续拆成五类模块。

1. 传输层

• CAN、PLC或其他通信驱动；
• 发送和接收队列；
• 链路建立及恢复；
• Bus-off、断线和网络错误处理；
• 原始报文记录。

2. 报文层

• 报文识别、编码和解码；
• 字节序、比例和偏移换算；
• 多包传输；
• 字段范围与保留值校验；
• 未知或非法消息处理。

3. 协议状态机

• 建链和握手；
• 身份辨识；
• 能力协商；
• 双方就绪；
• 能量传输；
• 停止；
• 统计和会话结束。

4. 定时、异常和诊断

• 周期发送；
• 每个阶段的等待超时；
• 关键数据的新鲜度；
• 报文错序和重复；
• 通信看门狗；
• 故障分级、快照和恢复。

5. 公共模型适配

协议原始字段应转换为稳定的通用对象，例如：

VehicleIdentity：车辆是谁
VehicleCapability：车辆能够接受什么
VehicleDemand：车辆此刻需要什么
ProtocolEvent：车辆就绪、停止或故障事件
ChargerStatus：充电桩实际做了什么

这样增加新协议时，只需要增加新的通信栈、报文和协议状态机，而不必复制安全监督、功率仲裁、接触器控制、计量、订单和桩云系统。

第七层：为什么协议代码不是全部工作量

把正常报文发送出来，只能说明“正常路径可能跑通”。量产能力还包括：

• 每个阶段的超时、错序和非法数据；
• 通信突然中断时的安全动作；
• 功率目标和实际输出的偏差监控；
• 多品牌车辆的非理想实现兼容；
• 一致性测试和正式认证；
• 高压硬件在环测试；
• 真实车辆互操作；
• 长时间重复充电和现场问题追踪。

因此，评估新协议的增量工作量，应使用：

新增工作量 =
通信硬件
+ 协议软件栈
+ 新业务子系统
+ 公共框架改造
+ 测试认证
+ 车型互操作和长期维护

例如，从GB/T增加CHAdeMO时，CAN基础和公共安全、功率控制可以大量复用；增加ISO 15118时，则还要引入PLC、IP、TLS、EXI以及证书体系，增量明显更大。

结语

从第一性原理看，车桩协议解决的是一个“受安全约束的跨设备能量协同”问题。

它一步一步建立：

物理连接关系
→ 通信关系
→ 身份和能力认知
→ 安全许可
→ 动态功率闭环
→ 故障与停止共识
→ 可追溯的会话结果

不同协议的接口、报文和技术栈会变化，但这些基本问题不会消失。理解一种新协议时，不必先记忆全部字段，而应依次追问：

1. 它怎样确认连接和建立通信？
2. 车辆和桩分别提供哪些信息？
3. 怎样得出允许的能量传输边界？
4. 谁负责最终安全裁决和硬件动作？
5. 通信或设备发生故障时怎样回到安全状态？
6. 它比现有协议多增加了哪些身份、计划或双向能力？

只要沿着这条主线，就能同时理解协议的工作原理、实现边界以及支持更多协议时真正增加的工程工作量。

参考资料

1. 国家市场监督管理总局、国家标准化管理委员会，GB/T 27930.2-2024《非车载传导式充电机与电动汽车之间的数字通信协议 第2部分：用于GB/T 20234.3的通信协议》。
2. ISO，ISO 15118-1:2019 — Road vehicles — Vehicle to grid communication interface — General information and use-case definition。
3. ISO，ISO 15118-20:2022 — 2nd generation network layer and application layer requirements。
4. CHAdeMO Association，V2G/VGI。
5. CharIN，Basic Technical Details of the Combined Charging System。