【CAN通讯系列1】需求解析（上）

1 CAN通讯用来做什么

现代汽车有非常多的控制器（ECU，Electronic Control Unit）, 这些控制器可以实现各种各样的功能。有些功能只需要一个控制器就可以实现，而更多功能是需要多个控制器联合控制才能实现，这就意味着这些控制器之间需要进行信息交互，比如电机控制功能，电机控制器（MCU，Motor Control Unit）一方面需要获取整车控制器（VCU，Vehicle Control Unit）的目标电机扭矩或目标电机转速等信息，另一方面MCU需要反馈实际电机扭矩或实际电机转速等信息给VCU。当然不仅仅只有MCU和VCU的信息交互，还有MCU与其他控制器(ABS, BMS和BCM等)的信息交互。

因此，需要采取怎样的方法来实现它们之间的信息交互呢？目前，汽车控制器之间的通讯主要使用控制器区域网络(CAN, Controller Area Network)、局域互联网络(LIN, Local Interconnect Network)和 FlexRay等。随着汽车车载网络架构向着高度集成的域控制器发展，以太网（Ethernet）也将被使用。这样整车的车载网络发展趋势就会越来越复杂，也越来越多样化，如下所示：

source：车身电子的未来发展 - 白皮书 (nxp.com)

通过上图不难发现，虽然通讯方式更复杂了，但CAN通讯仍将无处不在，仍然对控制器之间的信息交互起着至关重要的作用。因此，只要在稍微复杂一点的控制器上，都会采用CAN通讯。那么对于CAN通讯，一般都会提一些怎样的需求呢？

2 CAN通讯需求有哪些

汽车控制器的最常见开发方式都是采用V流程。即首先提出了产品的功能或性能要求，然后经过系统（System）分析与评估，再分配给软件（Software）和硬件（Hardware），接着软件和硬件进行相应的设计，测试和验证，最后由系统进行测试，验证和确认。

source：automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf

本文仅限于CAN通讯需求层面的探讨，以MCU为例，在客户层面，可能客户会提出：

• MCU需要几条CAN

• 每条CAN具体怎么用

• 每条CAN需要具备哪些功能

• 每条CAN传输速率要求是怎样

• 每条CAN是否需要终端电阻

这些需求就是控制器V流程开发的发起点，一般称为客户需求或者利益相关者需求（stakeholder requirement），然后在系统层面，系统工程师会拉上相关利益者（客户，软硬件成员和项目管理成员等）一起来评估这些需求，双方经过多次详细沟通，最终确定这些需求，这个过程对应Aspice的SYS.1需求挖掘阶段。接着在系统层面将确定的利益相关者需求进行分解，对应着Aspice的SYS.2系统需求分析，接着上面的例子，CAN通讯的利益相关者需求被分解得到系统需求如下：

• MCU需要两条CAN，一条用于控制器间通讯CAN1，另一条用于诊断和标定CAN2

• CAN1需要支持Classical CAN和CAN FD

• CAN1需要支持标准和扩展两种格式的数据帧

• CAN1需要根据已提供的CAN报文协议（CAN matrix）进行开发

• CAN1需要配置1个终端电阻

• CAN1需要支持报文唤醒功能

• CAN1需要支持传输速率可标定等

3 CAN通讯需求解析

下面就一条一条来解析上面提出CAN通讯的系统需求。

3.1 MCU需要两路CAN，一路用于控制器间通讯CAN1，另一路用于诊断和标定CAN2

对于这条需求，为什么MCU需要两路CAN？

一般是为了降低单路CAN总线上的负载率，所以主机厂（OEM）在开发过程中会一般会设置两路CAN，一路用作基本通讯，上面挂载整车控制器，电机控制器和电池管理控制器等节点。另一路则用于车辆开发过程中通过标定协议XCP读取控制器内部变量或诊断协议UDS服务进行诊断通讯，通常叫做诊断CAN或标定CAN，量产后一般会被禁用。

这条需求通常由主机厂（OEM）发起，供应商需要怎么评估呢？对于供应商来说，主要评估当前的控制器硬件是否满足，即从接插件Pin数量是否足够提供两路CAN_H和CAN_L，PCB是否有足够空间布置两颗CAN收发器及其相应的处理电路，以及微控制器芯片中CAN控制器数量是否足够。

这条需求要求的是2路CAN的情况，那还有其他情况吗？

随着汽车智能驾驶功能的增加，主机厂一般会需要再增加一路CAN，即所谓的ADAS CAN。当然也有些控制器只是负责简单的执行功能，这时可能就只需要1路CAN，即与其他控制通讯以及诊断标定共用一路CAN。

3.2 CAN1需要支持Classical CAN和CAN FD

对于这条需求，毫无疑问肯定支持Classical CAN ，而要支持CAN FD，那么需要考虑哪些因素呢？

主要考虑两个方面：一方面是控制器硬件，即CAN收发器和MCU的CAN控制器是否支持CAN FD；另一方面是控制器软件，CAN通讯功能模块需是否支持CAN FD报文的处理。

这里对CAN FD稍作描述：

1） CAN FD产生的原因。随着电动汽车和智能驾驶汽车技术的快速发展，仅使用Classical CAN面临传输的速度不够快，一次传输的数据不够多的问题，即带宽和数据场长度受到制约。因此，为了避免使用其他通讯形式而造成大幅提高成本的问题，就提出了CAN FD总线方案，即可变速率和新的数据场长度。

2）CAN FD的可变速率。它是指CAN FD采用了两种位速率：从控制场中的BRS位到ACK场之前（含CRC分界符）为可变速率，如下图蓝色部分，其余部分为原CAN总线用的速率。两种速率各有一套位时间定义寄存器，它们除了采用不同的位时间单位TQ外，位时间各段的分配比例也可不同。

source：CANFD an introduction, from Vector

3）CAN FD的数据场长度。它是指CAN FD对数据场的长度作了很大的扩充，DLC最大支持64个字节，在DLC小于等于8时与原CAN总线是一样的，大于8时有一个非线性的增长，所以最大的数据场长度可达64字节，如下所示。

source：CANFD an introduction, from Vector

因此使用CAN FD时，还需要提可变速率和数据长度的需求。

3.3 CAN1需要支持标准和扩展两种格式的数据帧

对于这条需求，不管是Classical CAN 还是CAN FD都适用，涉及的变更在控制器软件。为了更好地理解这条需求，这里详细解释下标准格式和扩展格式的区别。

首先，对于Classical CAN，标准格式和扩展格式的区别在仲裁段，即：标准格式的仲裁段包含11位基本ID位和RTR位，而扩展格式的仲裁段除了11位基本ID位和RTR位外，还包含SRR位，IDE位和18位扩展ID位，如下所示：

source：CAN_E: Data Frame (vector.com)

这样，标准格式可表示的CAN ID（11位） 范围为 0X000~0X7FF，而扩展格式可表示的CAN ID（29位）范围为0X00000000~0X1FFFFFFF。一般乘用车上常用标准格式的CAN ID，而商用车上常用扩展格式的CAN ID。

注意：标准格式的RTR位对应扩展格式SRR位，为什么这样设置呢？因为标准格式的RTR位恒为显性，扩展格式的SRR位恒为隐性，根据线与机制，当前11位基本ID位相同时，使得标准格式的数据帧优先级高于扩展格式的数据帧。关于仲裁段中其他位的作用因与本文主题无关，故此处不作说明，可参考: 一篇易懂的CAN通讯协议指南1 - 知乎 (zhihu.com)

然后，对于CAN FD，标准格式和扩展格式的区别同样也在仲裁段，其机制与Classical CAN情况完全一样，如下所示：

限于篇幅控制，本文暂且介绍到此，想要继续了解剩余需求解析，请期待续文。

---------------------------------------------------------------------------------------------------------------------------------

创作不易，欢迎点赞收藏关注。

汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车行业从业人员。