3、充电协议详解（GB/T 27930）：物理层与数据链路层、报文结构与类型、握手与辨识阶段流程
好，咱们进入第三章。这一章我打算把 GB/T 27930 协议的核心部分掰开揉碎了讲。你想想看，充电桩和车之间要“说话”，总得有个规矩吧？这个规矩就是 GB/T 27930。说白了，它就是电动车和充电桩之间的“普通话”。
我个人习惯，看协议先看它的骨架——也就是物理层和数据链路层。这两层搞明白了，后面的报文解析就是水到渠成的事。
3.1 物理层与数据链路层：通信的“高速公路”
物理层解决的是“怎么传”的问题。GB/T 27930 用的是 CAN 总线，也就是控制器局域网总线。为什么选它？因为 CAN 总线抗干扰能力强，实时性好，特别适合汽车这种电磁环境复杂的地方。
我记得有一次在实验室调试，发现通信老是丢包。查了半天，原来是 CAN 总线终端电阻没焊好。嗯，这里要注意：CAN 总线两端必须各接一个 120 欧姆的终端电阻，否则信号反射会搞得你怀疑人生。
物理层关键参数：
- 通信速率：250 kbps（这是国标规定的，别乱改）
- 总线电平：显性电平（逻辑0）和隐性电平（逻辑1）
- 最大通信距离：40米（实际工程中建议控制在20米以内）
数据链路层呢？它负责把物理层传来的比特流组织成“帧”。CAN 总线有四种帧类型：数据帧、远程帧、错误帧、过载帧。咱们充电桩通信主要用数据帧。
一个标准 CAN 数据帧长这样：
帧起始(1bit) + 仲裁场(12bit) + 控制场(6bit) + 数据场(0-8byte) + CRC场(16bit) + 应答场(2bit) + 帧结束(7bit)你可能会问：“为什么数据场最多只有 8 个字节？” 这是 CAN 总线设计之初就定下的，为了保证实时性。8 个字节对于充电桩的报文来说，其实够用了。我做过一个项目，需要传输电池的详细参数，8 个字节不够怎么办？那就拆成多个报文发呗。
3.2 报文结构与类型：读懂“车桩对话”
GB/T 27930 的报文结构，我习惯把它分成三层：
- 物理层：CAN 总线帧，咱们刚讲过
- 数据链路层：协议数据单元（PDU），包含标识符和数据
- 应用层：具体的充电控制信息
报文类型主要有这么几种：
| 报文类型 | 功能描述 | 典型例子 |
|---|---|---|
| 握手报文 | 建立通信连接 | CHM（充电机握手报文） |
| 辨识报文 | 确认双方身份 | BRM（电池辨识报文） |
| 参数配置报文 | 协商充电参数 | BCP（电池充电参数报文） |
| 充电控制报文 | 实时控制充电过程 | BCS（电池充电状态报文） |
| 结束报文 | 终止充电 | CST（充电机停止充电报文） |
每个报文都有固定的 ID 和数据格式。比如握手报文的 ID 是 0x1826F4F0（充电机发给车辆），数据场包含充电机编号、协议版本号等信息。
我的小技巧： 开发时建议准备一份报文 ID 速查表。我曾经因为记混了 ID，导致握手阶段一直失败，排查了整整一个下午。后来我把所有报文 ID 打印出来贴在工位上，再也没出过这种低级错误。
3.3 握手与辨识阶段流程：第一次“亲密接触”
握手和辨识，是充电桩和车辆建立通信的第一步。这一步要是没走好，后面全白搭。
握手阶段：
- 充电桩上电后，先发送 CHM（充电机握手报文），告诉车辆：“我准备好了，你是谁？”
- 车辆收到后，回复 BHM（车辆握手报文），告诉充电桩：“我是电动车，协议版本是 XX。”
- 双方确认协议版本一致，握手成功。
我曾经遇到过一个坑：某款车的 BHM 报文里，协议版本号写的是 0x02，但实际它只支持 0x01 的功能。结果握手是成功了，但后续参数配置阶段直接报错。嗯，这就是典型的“握手通过，但实际不兼容”。所以我的建议是：握手成功后，最好再加一个简单的功能测试。
辨识阶段：
- 握手成功后，充电桩发送 BRM（电池辨识报文），询问电池的详细信息。
- 车辆回复 BCP（电池充电参数报文），包含电池类型、额定容量、额定电压等。
- 充电桩根据这些参数，计算初始充电功率。
辨识阶段的数据很重要，直接决定了后续的功率分配策略。比如电池是磷酸铁锂还是三元锂，它们的充电曲线完全不同。磷酸铁锂的恒流充电时间更长，三元锂的恒压充电阶段更关键。
注意： 握手和辨识阶段有严格的时间限制。国标规定，充电桩发送 CHM 后，必须在 5 秒内收到 BHM，否则视为超时。同样，辨识阶段也有 5 秒的超时限制。我在现场调试时，经常遇到因为 CAN 总线干扰导致超时的情况。解决办法是：增加重试机制，一般重试 3 次，每次间隔 1 秒。
好了，这一章的内容就到这里。握手和辨识是充电流程的“敲门砖”，搞懂了它们，后面的参数配置和功率分配才能顺利进行。下一章咱们聊聊参数配置阶段，那才是真正考验算法的地方。