第三章 级联系统通信协议：CAN通信基础与OBC-DC/DC协议定义
各位工程师朋友，咱们接着聊。上一章我们把OBC和DC-DC的硬件接口理清了，这一章要啃的，是它们之间的“语言”——CAN通信。说白了，就是这两个模块怎么“对话”。
我做了这么多年系统联调，见过太多因为通信协议没对好，导致整个系统“鸡同鸭讲”的案例。有一次在客户现场，OBC明明已经输出400V了，DC-DC却死活不启动，查了两天，最后发现是CAN报文的ID定义差了一个比特。嗯，这种坑，踩过一次就忘不了。
3.1 CAN通信基础——为什么是CAN？
你可能会问，为什么OBC和DC-DC之间非得用CAN？用串口不行吗？
我个人的习惯是，先理解“为什么”，再学“怎么做”。CAN总线有几个特点，特别适合车载环境：
- 差分信号，抗干扰强——车里电磁环境多恶劣你懂的，CAN的CAN_H和CAN_L两根线绞在一起，共模干扰基本免疫。
- 多主通信，实时性好——任何一个节点都可以随时发消息，不需要等主机轮询。OBC要紧急降流，直接发报文就行。
- 错误检测机制完善——CRC校验、位填充、应答确认，一套组合拳下来，误码率极低。
我记得刚入行时，有个老工程师跟我说：“在车上，CAN就是普通话，谁都得会。” 现在想想，确实如此。
3.2 CAN报文解析——看懂“车语”
CAN报文长什么样？咱们直接看一个标准数据帧（2.0A格式）：
| SOF | 11位ID | RTR | IDE | r0 | DLC | 0~8字节数据 | CRC | ACK | EOF |
|-----|--------|-----|-----|----|-----|------------|-----|-----|-----|
| 1bit| 11bit | 1bit| 1bit|1bit| 4bit| 0~64bit |15bit| 2bit| 7bit|这里面，我们最关心的就两个东西：ID 和 数据段。
- ID：报文的“身份证”。ID越小，优先级越高。OBC和DC-DC的关键控制报文，我一般会给它分配一个较小的ID，确保紧急指令能优先通过。
- 数据段：最多8个字节。怎么解读这8个字节，就是协议定义的事了。
3.3 OBC与DC-DC之间的CAN协议定义
好了，基础讲完，咱们进入正题。OBC和DC-DC之间到底要传什么？我把它归纳为三大类：
3.3.1 充电模式指令
OBC是“大脑”，它告诉DC-DC现在处于什么阶段。常见的模式有：
| 模式名称 | 模式代码（1字节） | 说明 |
|---|---|---|
| 待机模式 | 0x00 | DC-DC不工作，等待指令 |
| 恒流充电 | 0x01 | 以设定电流给高压电池充电 |
| 恒压充电 | 0x02 | 电压达到目标值后，转为恒压 |
| 预充电 | 0x03 | 电池电压较低时，小电流预充 |
| 故障模式 | 0xFF | 检测到异常，立即停止输出 |
这里要注意，模式切换必须有序。你不能从待机直接跳到恒压，必须先恒流。我在项目中遇到过，有同事把模式跳转逻辑写错了，导致DC-DC在电池还没充满时就切恒压，电流瞬间掉到零，充电时间延长了一倍。
3.3.2 电压电流指令
OBC通过CAN报文，把目标电压和目标电流发给DC-DC。举个例子：
报文ID: 0x181（OBC -> DC-DC 控制指令）
数据段定义：
Byte 0: 充电模式（参考上表）
Byte 1-2: 目标电压，单位0.1V，小端格式
Byte 3-4: 目标电流，单位0.1A，小端格式
Byte 5-7: 保留（填0x00）
示例：
发送 0x01 0x10 0x27 0xE8 0x03 0x00 0x00 0x00
解读：模式=恒流充电，电压=0x2710=10000 -> 1000.0V？不对，注意单位是0.1V，所以是1000.0V？
等等，这里要小心！3.3.3 状态反馈与故障上报
DC-DC不能光听指令，它也得“回话”。我一般会定义另一个报文ID给DC-DC反馈：
报文ID: 0x182（DC-DC -> OBC 状态反馈）
数据段定义：
Byte 0: DC-DC当前状态（待机/运行/故障）
Byte 1-2: 实际输出电压，单位0.1V
Byte 3-4: 实际输出电流，单位0.1A
Byte 5: 故障码（0=无故障，1=过压，2=过流，3=过温...）
Byte 6-7: 保留OBC收到这个反馈后，会做闭环控制。比如，OBC发了目标电压400V，但DC-DC反馈回来只有380V，那OBC就要判断：是还在上升过程中？还是DC-DC带不动负载？还是通信出错了？
嗯，这里有个经验：OBC收到反馈后，不要立即调整指令，加一个50ms的滤波。为什么？因为CAN总线有抖动，DC-DC的采样也有噪声。不加滤波，指令会来回跳，系统反而不稳定。
3.4 实战中的通信调试要点
最后，我总结几个联调时容易出问题的地方：
- 波特率必须一致——OBC和DC-DC的CAN波特率要设成一样，常见的是250kbps或500kbps。差一点都不行。
- 终端电阻不能省——CAN总线两端各需要120Ω的终端电阻。少了它，信号反射会导致通信不稳定。我见过有人为了省成本没加，结果距离稍远就丢帧。
- 报文超时处理——OBC发指令后，如果DC-DC超过100ms没有回应，OBC应该认为通信中断，主动进入安全状态（停止输出）。这个逻辑一定要写。
- 先看波形，再看数据——用示波器抓CAN_H和CAN_L的差分波形，确认电平幅值对不对（显性位约1.5V，隐性位约2.5V）。波形对了，再拿CAN分析仪看数据内容。
核心一句话： CAN通信协议是OBC和DC-DC的“契约”。定义清楚、解析正确、容错到位，联调就成功了一半。
好了，这一章的内容就到这里。下一章，咱们要真正开始“联调”了——把OBC和DC-DC连起来，上电，看波形，调参数。那才是真正考验功力的时候。