车载 CAN 通讯需求工程化落地全梳理

前言

当前乘用车、商用车电控架构日趋复杂，一台整车搭载数十乃至上百套电子控制单元 ECU，动力、电池、底盘、智能驾驶、车身电器等模块需要持续交换扭矩、电压、故障、状态等实时信号。各类车载总线中，LIN 多用于低成本低速执行器，FlexRay 逐步退出主流，车载以太网面向高阶大带宽场景，而 CAN 总线凭借极强的抗干扰能力、成熟稳定的实时性与低廉硬件成本，依旧是整车电控交互的基础网络。

整车 CAN 通讯相关配置绝非简单选择波特率、增加一路总线，而是一套贯穿整车 V 型开发流程、贴合 ASPICE 质量管理体系、兼顾硬件电路、底层驱动、网络管理、功能安全的系统性工作。多数项目问题，根源都在于前期 CAN 需求梳理不完整、拆解不到位。本文结合主机厂实际项目开发经验，从需求来源、分项工程设计要点、系统统筹逻辑三个维度，完整梳理 CAN 通讯需求的落地思路，补充原文未细化的工程实操细节。

1

N 通讯需求的生成逻辑

整车控制器开发严格遵循 V 流程开发模型，通讯需求是所有软硬件设计的前置输入，需求分层、拆解、评审有着标准化流程，对应汽车行业 ASPICE 能力评估标准。

1. ** stakeholder 原始需求

   SYS.1 需求挖掘阶段，主机厂网络工程师结合整车拓扑，向零部件供应商输出基础通讯诉求，大多为直白、偏向应用层面的问题：控制器配备几路 CAN 通道、各通道功能划分、额定传输速率、是否需要支持休眠唤醒、是否板载终端电阻等。这一层需求只定义 “要实现什么功能”，不包含芯片、电路、软件底层实现方案，存在模糊、不可量化的问题，不能直接交付研发使用。

2.标准化系统需求拆解

SYS.2 系统需求分析阶段，系统工程师组织硬件、软件、测试、项目多方评审原始需求，剔除矛盾、不可实现的条款，补充量化指标、边界条件、异常处理规则，转化为可直接用于设计、测试、验收的系统需求规范。举个典型案例：主机厂仅提出 “电机控制器支持 CAN 通讯”，经过拆解后会细化为通道数量、CAN FD 兼容、报文周期、校验机制、休眠唤醒等数十条可落地细则，软硬件团队以此作为开发依据。

2

CAN 通讯核心需求分项工程拆解

（一）CAN 通道数量与功能分区设计

常规电控零部件采用双通道 CAN 架构，功能完全隔离，核心目的是分流总线负载，规避高周期报文抢占带宽，引发信号延迟、丢包：

• 动力交互 CAN：对接 VCU 整车控制器、BMS 电池管理系统、MCU 电机控制器等动力域节点，传输扭矩、转速、高压状态等实时控制信号，报文周期普遍 10ms/20ms，对实时性要求极高；

• 诊断标定 CAN：专供开发阶段 XCP 在线标定、UDS 故障诊断，量产车型下线后会通过软件逻辑屏蔽该通道通讯，避免外部设备干扰整车正常运行。高阶智能驾驶车型会新增第三路 ADAS 专用 CAN，传输摄像头、毫米波雷达、域控的感知信息；雨刮、门锁等简易车身执行器出于成本考量，常采用单路 CAN，正常交互、诊断标定复用同一通道。

硬件层面评审时容易忽略三类风险，原文未重点提及：MCU 内置 CAN 控制器资源上限、PCB 布局空间能否放下多路 CAN 收发器及滤波电路、接插件预留 CAN_H/CAN_L 差分引脚数量。若前期需求未核对硬件资源，项目中后期极易出现改板延期问题。

（二）Classic CAN 与 CAN FD 兼容设计

传统经典 CAN 存在两大天然短板：最高传输速率 1Mbps，单帧数据长度上限 8 字节。随着新能源车高压数据、自动驾驶多组感知信号交互需求上涨，单帧 8 字节容量不足以承载大批量参数；直接切换车载以太网会大幅增加线束、芯片成本，CAN FD 成为折中最优解。

CAN FD 核心优势分为两点：

• 一是分段变速传输，仲裁段沿用基础波特率保证总线兼容性，数据段提升传输速率，缩短单帧收发耗时；

• 二是数据场最大扩容至 64 字节，DLC≤8 字节时与传统 CAN 完全兼容，旧节点可无缝接入同一条总线。

工程落地关键约束：软硬件必须同步适配。硬件上 MCU 片上 CAN 外设、外接收发器均需原生支持 CAN FD；软件底层驱动要区分两种帧格式的解析逻辑，新增 64 字节缓冲区处理逻辑。很多项目仅硬件支持 CAN FD，但驱动未做适配，最终无法发挥高速大容量传输优势。

（三）标准帧、扩展帧适配规则

CAN 数据帧分为 11 位 ID 标准帧、29 位 ID 扩展帧，

无论是Classical CAN还是CAN FD，数据帧都有标准格式和扩展格式之分。两者的核心区别在于仲裁段：

• 标准格式：仲裁段包含11位基本ID和RTR位；
• 扩展格式：仲裁段除了11位基本ID和RTR位外，还包含SRR位、IDE位和18位扩展ID。

ID范围的差异：

• 标准格式（11位ID）：0x000 ~ 0x7FF
• 扩展格式（29位ID）：0x00000000 ~ 0x1FFFFFFF

行业形成明确使用习惯：国内乘用车网络普遍使用标准帧，商用车、工程机械、特种车辆多采用扩展帧。

总线底层线与仲裁机制决定优先级：两条报文基础 11 位 ID 相同时，标准帧优先级高于扩展帧，该机制保障两种帧共存时总线不会出现仲裁冲突。设计需求时必须和主机厂确认统一帧格式，若总线内混合两种帧，需要提前规划 ID 区间，避免关键控制报文被低优先级报文阻塞。

（四）CAN 矩阵 DBC 与报文安全防护

CAN 矩阵是整车总线交互的 “规则手册”，有 Excel 表格、DBC 数据库文件两种通用载体，也是供应商软件开发的核心输入文件，完整定义节点收发关系、报文 ID、周期、信号解析规则：字节序、信号位起始位置、缩放系数、偏移量、物理值上下限。原文仅简单举例信号换算逻辑，实际项目中极易出现解析错误：大小端字节序混淆、缩放因子精度丢失、信号偏移位数计算错误，都会造成整车信号显示异常、动力控制逻辑出错。

DBC（CAN Database）文件是CAN通讯的标准化描述格式，广泛用于软件开发调试和测量标定工具。在DBC编辑器中，通过定义网络节点、报文和信号，并将它们相互关联，即可完成通讯矩阵的配置。DBC与Excel表格表达的是相同的信息，只是形式不同。

为应对总线干扰、线束接触不良导致的数据失真，主机厂会强制要求报文增加两层安全校验机制：

1. Checksum 校验和：发送端通过固定算法生成校验码放入报文，接收端重新计算比对，校验不一致直接丢弃当前帧，判定为传输故障；
2. Rolling Counter 循环计数器：每发送一帧计数器自增，0~15 循环往复，接收端检测计数器跳变、断号，判定报文丢失，触发故障记录与故障降级逻辑。

功能安全等级 ASIL-B 及以上控制器，两项校验为强制需求，不可省略。

（五）120Ω 终端电阻硬件配置

高速 CAN 总线特性阻抗标准为 120Ω，总线拓扑两端节点必须匹配终端电阻，原理是阻抗匹配消除信号反射、抑制波形振铃。缺少匹配电阻会导致差分信号畸变，高速工况下频繁出现通讯掉线。

CAN总线终端电阻的作用有3个：

• 提高抗干扰能力，让高频低能量的信号迅速走掉
• 确保总线快速进入隐性状态，让寄生电容的能量更快走掉；
• 提高信号质量，放置在总线的两端，让反射能量降低。

为什么选120Ω？

什么是阻抗？在电学中，常把对电路中电流所起的阻碍作用叫做阻抗。阻抗单位为欧姆，常用Z表示，是一个复数Z= R+i( ωL–1/（ωC）)。具体说来阻抗可分为两个部分，电阻（实部）和电抗（虚部）。其中电抗又包括容抗和感抗，由电容引起的电流阻碍称为容抗，由电感引起的电流阻碍称为感抗。这里的阻抗是指Z的模。

任何一根线缆的特征阻抗都可以通过实验的方式得出。线缆的一端接方波发生器，另一端接一个可调电阻，并通过示波器观察电阻上的波形。调整电阻阻值的大小，直到电阻上的信号是一个良好的无振铃的方波，此时的电阻值可以认为与线缆的特征阻抗一致。

采用两根汽车使用的典型线缆，将它们扭制成双绞线，就可根据上述方法得到特征阻抗大约为120Ω，这也是CAN标准推荐的终端电阻阻值，所以这个120Ω是测出来的，不是算出来的，都是根据实际的线束特性进行计算得到的。当然在ISO 11898-2这个标准里面也是有定义的。

补充细节：主机厂网络拓扑会指定总线两端控制器板载电阻，中间节点禁止焊接 120Ω 电阻；部分控制器设计硬件跳线，可通过针脚短接切换电阻是否接入，适配不同整车项目拓扑，提升零部件通用性。

（六）总线报文唤醒，整车低功耗管理核心

整车 ECU 供电分为两类：K15 点火开关供电（上电工作，下电直接断电）、K30 常电供电（车辆熄火后保持休眠，降低静态功耗），报文唤醒功能仅针对常电控制器。

休眠状态下 MCU 主芯片断电，CAN 收发器保持低功耗监听模式，当总线检测到有效报文（可配置任意报文唤醒、指定专属唤醒 ID），收发器输出唤醒电平给到 PMIC 电源管理芯片，重新给 MCU 上电唤醒整车控制器。

远程唤醒的工作机制：支持远程唤醒的ECU在休眠时，CAN收发器仍然保持对总线的监听能力。当检测到唤醒报文（可能是任意报文，也可能是指定ID的报文，取决于具体实现）时，CAN收发器会触发电源管理芯片（PMIC）为微控制器供电，使ECU从休眠状态进入正常工作模式。

需求阶段必须明确唤醒规则：允许哪种报文唤醒、休眠静态电流上限、唤醒后通讯恢复时效，直接决定收发器芯片选型与电源外围电路设计，若需求模糊容易出现车辆停放亏电、唤醒失效问题。

（七）波特率可标定适配多项目平台

主流 CAN 总线常用波特率分为 250Kbps、500Kbps、1Mbps，平台化控制器需要支持多速率切换，适配不同车型网络架构。传输速率由 MCU 晶振频率、预分频系数 BRP、位时间分段参数共同计算得出，所有参数在 CAN 驱动初始化阶段固化配置。需要重点注意：通过标定参数修改波特率后，无法即时生效，必须重启 CAN 控制器初始化流程，该边界条件需要在需求文档中明确，避免测试阶段误判功能失效。

3

CAN 需求设计的全局统筹思维

所有通讯参数不能单独拆分设计，必须结合整车多维度因素综合权衡，项目前期评审需要覆盖六大核心维度：

1. 通道数量：结合整车交互节点数量、总线负载率阈值划分独立通道；
2. 传输速率：匹配同总线所有 ECU 速率，控制总线平均负载率不超过 30%；
3. CAN FD 需求：根据单帧数据量、传输延迟要求判断是否启用；
4. 帧格式：按乘用车 / 商用车车型统一标准帧或扩展帧；
5. 终端电阻：依据主机厂总线拓扑确认板载或外置；
6. 唤醒功能：结合 ECU 供电方案、整车静态功耗指标确定唤醒逻辑；

单一维度需求变更，会连锁影响硬件电路、底层驱动、网络管理、测试用例，前期统筹不足会带来大量设计变更与重复测试工作。

4

行业发展总结与落地启示

CAN 总线问世近四十年，经过持续迭代至今仍是车载网络基石，CAN FD 作为兼容升级方案，有效弥补传统 CAN 带宽短板，在中低端乘用车、商用车市场中长期无法被以太网完全替代。

对电控研发从业者而言，梳理 CAN 通讯需求不能只停留在读取技术参数，更要理解 V 流程分层需求逻辑、整车网络拓扑约束、功能安全与低功耗设计要求。完整、量化、可验证的通讯需求，是减少开发返工、保障整车电控稳定交互的前置基础；只关注表层通讯参数、忽略硬件资源、异常校验、休眠功耗等隐性需求，是绝大多数车载 CAN 项目故障的核心诱因。

来源：新能源汽车电控开发与测试