4、国标GB/T 27930通信协议：CAN通信基础、报文结构（BCP/CTS/CRM等）、充电参数协商流程、绝缘检测与握手

各位工程师朋友，咱们今天聊聊国标GB/T 27930这个协议。说实话，这个协议是我入行时啃得最久的一份文档。你想想看，OBC要跟充电桩“对话”，全靠它定规矩。搞不懂这个，充电就充不进去。

4.1 CAN通信基础：OBC与桩的“对话语言”

GB/T 27930用的是CAN 2.0B协议，扩展帧，250kbps波特率。为什么选这个？说白了，就是抗干扰能力强，实时性好。我在实验室里见过太多因为CAN总线问题导致充电失败的案例了。

几个关键点，我列出来：

• 帧类型：数据帧和远程帧。咱们主要用数据帧。
• ID分配：每个报文都有唯一的ID。比如BCP是0x1801F456，CTS是0x1807F456。这个ID决定了优先级。
• 数据长度：通常是8字节。别小看这8个字节，里面塞满了关键信息。

4.2 报文结构：BCP、CTS、CRM到底在说什么？

报文结构是协议的核心。我习惯把报文分成三类：握手报文、参数协商报文、实时控制报文。咱们一个个看。

4.2.1 BCP（电池充电参数）报文

BCP是BMS发给充电桩的。它告诉桩：“我的电池长什么样”。

字节	内容	说明
Byte0-1	电池类型	0x01=铅酸，0x02=锂电
Byte2-3	电池额定容量	单位Ah，比如100Ah
Byte4-5	电池额定电压	单位V，比如350V
Byte6-7	电池系统阻抗	单位mΩ，这个参数很关键

嗯，这里要注意。BCP报文只在握手阶段发一次。如果发错了，整个充电流程就断了。我建议你在代码里加个校验，确保BCP数据合理。

4.2.2 CTS（充电机辨识）报文

CTS是充电桩回复给BMS的。它说：“我收到你的参数了，这是我的能力”。

CTS报文里有个重要字段——充电机编号。这个编号在国标里是唯一的。我记得有一次，一个桩的编号写错了，导致BMS不认它。排查了半天才发现是固件里写死了0x00。

4.2.3 CRM（充电机辨识确认）报文

CRM是BMS收到CTS后的确认。它告诉桩：“好的，我确认你的身份”。

CRM报文很简单，就一个字节：0xAA表示确认，0x55表示拒绝。但千万别小看它。如果BMS发了0x55，桩就得重新开始握手流程。

4.3 充电参数协商流程：一场“讨价还价”

参数协商，说白了就是BMS和充电桩在“讨价还价”。BMS说“我要500V”，桩说“我只能到400V”。最后达成一致。

流程是这样的：

1. BMS发BCP：告诉桩电池参数。
2. 桩发CTS：告诉BMS自己的能力。
3. BMS发CRM：确认或拒绝。
4. 桩发CML：充电机最大输出能力。
5. BMS发BRO：电池充电需求。
6. 桩发BCS：充电机充电状态。

你想想看，这就像两个人谈生意。BMS是买家，桩是卖家。买家说“我要100A”，卖家说“我只能给80A”。最后成交价就是80A。

4.4 绝缘检测与握手：安全第一

绝缘检测是充电前的“体检”。不通过？对不起，不能充电。

握手阶段，BMS和桩要互相确认绝缘状态。流程如下：

• BMS发BRM：握手开始，包含BMS版本号。
• 桩发BRM：握手确认，包含充电机版本号。
• BMS发BCP：开始参数协商。

绝缘检测是在握手之后、参数协商之前进行的。桩会检测正极对地、负极对地的绝缘电阻。如果小于500Ω/V，就报绝缘故障。

我记得有一次在测试现场，一辆车插上枪就报绝缘故障。查了半天，发现是充电枪插座里有个水滴。擦干就好了。所以，绝缘检测对环境影响很敏感。

4.5 实战中的常见问题

最后，我分享几个实战中常见的问题：

• CAN ID冲突：多台设备共用总线时，ID不能重复。我建议用CAN分析仪抓一下总线，看看有没有ID冲突。
• 报文超时：每个报文都有超时时间。比如BCP必须在5秒内收到。超时了，就报错。
• 数据解析错误：字节顺序搞反了。国标用的是Intel格式，低字节在前。我见过有人用Motorola格式解析，结果数据全乱了。

好了，关于GB/T 27930的CAN通信基础、报文结构和参数协商流程，今天就聊到这里。下一章咱们聊聊欧标CCS协议，看看它跟国标有什么不同。