第3章：OBC CAN通信网络架构
大家好，我是老张。今天咱们聊聊OBC在整车CAN网络里到底扮演什么角色。说白了，就是搞清楚OBC这根“充电神经”是怎么跟整车其他“器官”连在一起的。
我记得刚入行那会儿，总觉得OBC就是个充电器，插上电就能充。后来踩过坑才明白——没有CAN通信，OBC就是个“睁眼瞎”。它得知道电池要充多少、整车现在啥状态、有没有故障，这些全靠CAN总线来传递。
3.1 OBC在整车CAN网络中的拓扑位置
先看一张典型的整车CAN网络拓扑图（我这里用文字描述，你脑子里想象一下）：
- 动力CAN（Powertrain CAN）：连接VCU、BMS、MCU、OBC等核心部件
- 车身CAN（Body CAN）：连接BCM、门窗、灯光等
- 信息娱乐CAN（Infotainment CAN）：连接中控屏、T-BOX等
OBC挂在哪个网络上？绝大多数车型，OBC挂在动力CAN上。为什么？因为OBC跟BMS、VCU的交互最频繁，而这些节点都在动力CAN上。
关键点：OBC不能挂在车身CAN或信息娱乐CAN上。我在一个项目中见过有人把OBC挂在车身CAN上，结果充电时车身控制信号干扰，导致充电中断。血的教训。
具体来说，OBC在动力CAN上的位置是这样的：
- OBC作为CAN节点，有自己的ID（后面会讲分配策略）
- OBC通过CAN总线与BMS、VCU直接通信
- OBC一般不与其他节点（如MCU、EPS）直接通信，除非有特殊需求
3.2 OBC与BMS、VCU的通信关系
这是OBC通信的核心。我把它分成两个维度来讲：
3.2.1 OBC与BMS的通信
BMS是OBC的“直接领导”。充电过程中，OBC必须听BMS的指令。为什么？因为电池的状态只有BMS最清楚。
典型的通信流程是这样的：
- BMS发送充电需求：目标电压、目标电流、充电模式（恒流/恒压）
- OBC响应并执行：调整输出参数，反馈当前状态
- BMS实时监控：如果电池温度过高或电压异常，BMS会发送停止充电指令
- OBC执行停止：切断输出，并上报故障码
我的经验：BMS和OBC之间的通信，一定要设计心跳机制。我曾经遇到一个项目，BMS死机了，OBC还在傻乎乎地充电，差点把电池充爆。后来我们加了一个100ms的心跳报文，BMS超过500ms没发心跳，OBC自动停止充电。
3.2.2 OBC与VCU的通信
VCU是整车的“总指挥”。OBC跟VCU的通信，主要是状态上报和指令接收。
举个例子：
- VCU告诉OBC：“现在可以充电了”（充电使能信号）
- OBC告诉VCU：“我正在充电，当前功率是6.6kW”
- VCU告诉OBC：“车辆需要行驶，请停止充电”（行车充电禁止）
说白了，VCU管的是“能不能充”，BMS管的是“怎么充”。OBC夹在中间，两头都得伺候好。
3.3 OBC CAN节点的ID分配策略
CAN ID分配，这是个技术活。分配不好，轻则报文冲突，重则整车通信瘫痪。
我一般遵循以下原则：
| 原则 | 说明 | 我的建议 |
|---|---|---|
| 优先级原则 | 高优先级报文用低ID（CAN总线仲裁机制） | 故障报文ID < 控制报文ID < 状态报文ID |
| 分组原则 | 同一功能模块的报文ID连续 | OBC的报文ID建议在0x180~0x1FF之间 |
| 预留原则 | 留出扩展空间 | 每个节点至少预留5~10个ID |
具体到OBC，我常用的ID分配方案（以11位标准帧为例）：
- 0x181：OBC状态报文1（输出电压、电流、功率）
- 0x182：OBC状态报文2（温度、效率、故障码）
- 0x183：OBC控制报文（来自VCU的使能指令）
- 0x184：OBC充电需求报文（来自BMS的目标参数）
注意：ID分配一定要跟整车厂协商一致。我见过一个项目，OBC和DCDC用了同一个ID，结果一上电两个节点互相干扰，整车直接进入保护模式。排查了三天才找到原因。
3.4 OBC CAN通信的波特率选择
波特率选择，说白了就是“快还是稳”的问题。
目前主流的选择有两个：
- 250kbps：经典选择，稳定可靠，传输距离远
- 500kbps：速度更快，但对总线要求更高
我个人更倾向于500kbps。为什么？
你想想看，OBC在充电过程中需要传输的数据量其实不小：电压、电流、功率、温度、故障码、心跳报文……如果波特率太低，报文周期就得拉长，控制实时性会受影响。
举个例子：
// 250kbps下，一个标准帧（11位ID + 8字节数据）的传输时间
// 帧起始(1) + 仲裁场(12) + 控制场(6) + 数据场(64) + CRC(16) + ACK(2) + 帧结束(7)
// 总位数 = 1 + 12 + 6 + 64 + 16 + 2 + 7 = 108位
// 传输时间 = 108 / 250000 = 0.432ms
// 500kbps下
// 传输时间 = 108 / 500000 = 0.216ms看到没？500kbps比250kbps快了一倍。对于充电控制这种实时性要求高的场景，快就是优势。
但是——凡事都有但是——500kbps对总线硬件要求更高。线束质量、终端电阻、节点数量都会影响通信质量。
我的建议：如果整车CAN网络支持，优先选500kbps。如果整车网络是250kbps（比如一些老平台），那就别硬上500kbps，保持一致最重要。我曾经在一个项目中强行把OBC改成500kbps，结果跟VCU的250kbps不匹配，整车通信全部乱套。
嗯，关于OBC的CAN通信网络架构，今天就聊到这儿。下一章咱们深入讲讲OBC的CAN报文格式和信号定义，那才是真正干活要用到的东西。
公众号:蓝海资料掘金营，微信deep3321