在软件定义汽车这个时代，汽车功能越来越丰富，随之ECU越来越多，有些功能靠ECU独立实现，有些功能则需要多个ECU联合实现。总体来说，ECU绝大多数情况下都需要与其他ECU进行信息交互，比如充电功能，车载充电机OBC需要联合电池管理系统BMS和整车控制器VCU等联合才能实现。因此，这些ECU采取怎样的通讯方式来实现信息交互？目前，常用的ECU通讯方式有 CAN，LIN和FlexRay，同时随着汽车电子电器架构朝着中央集成控制方向发展，以太网的应用也越来越广泛。

source：the software Car: Building ICT Architectures for Future Electric Vehicles

当然不管汽车电子电器架构发展多么迅速，CAN通讯仍将无处不在，持续对ECU之间的信息交互扮演着极其关键的角色。因此，本文从ECU系统层级角度来探讨CAN通讯都会有怎样的需求，以及如何去理解与评估这些需求。

#01 CAN通讯需求的分析与分解

汽车ECU基本都采用V流程开发，先由OEM提供功能开发需求，然后经过ECU系统的分析与评估，再分配给ECU软硬件进行相应的开发与验证，最后由系统进行验证和确认。

本文将侧重点在ECU系统层面视角来看这些CAN通讯需求。通常ECU系统收到在客户关于CAN通讯的需求会涉及以下几个点:

ECU需要具备几路CAN，每路CAN的基本要求是什么；

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

CAN通讯矩阵或DBC是怎样的。

这些需求就是ECU CAN通讯开发的起点，一般称为客户需求或者利益相关者需求Stakeholder requirement。在ECU系统层面，系统工程师收到这些需求后，会拉上相关利益者一起来评估这些需求，包括硬件，软件和功能安全等项目内部成员，同时也会和客户多次对齐，最终明确好这些CAN通讯需求。

接着系统工程师将在ECU系统层面将需求细化为ECU系统需求，比如:

ECU需要两路CAN，CAN1用于ECU之间的信息交互，CAN2用于诊断和标定；

两路CAN都为CAN FD，仲裁段波特率500Kbps，数据段波特率为2Mbps，采样点均为80%，都支持标准帧和扩展帧格式；

CAN1需要根据已提供的CAN通讯矩阵或DBC进行开发；

CAN1需要支持特定帧报文唤醒，支持局部网络唤醒功能等。

当然需求细化分解出来了很重要，但有没有彻底吃透呢？接下来我们就再进一步来探讨。

#02 如何理解CAN通讯需求

就系统工程师的经历来说，当看到这些需求，一方面要理解需求本身，另一方面需要知道这些需求将会涉及的相关利益方。下面我们就逐一解析上面所列举的CAN通讯需求。

2.1 ECU需要两路CAN，CAN1用于ECU之间的信息交互，CAN2用于诊断和标定

为什么ECU通常需要两路CAN或者更多？主要考虑因素有CAN总线的负载率以及功能需求等。所以OEM定义一路用作通讯，比如动力总成域上挂VCU, MCU, BMS 和OBC等。另一路则用于车辆的标定和诊断通讯功能，其中标定功能在量产会被禁用，这路CAN与OBD接口相连，如下所示：

当然也有有些控制器只有1路CAN，既用于通讯也用于诊断标定，比如有些电子泵产品。

对于这条需求，该如何评估，考虑点有：

主要评估当前的控制器硬件是否满足，即从接插件Pin数量是否足够提供两路CAN_H和CAN_L；

PCB是否有足够空间布置两颗CAN收发器及其相应的处理电路；

微控制器芯片中CAN控制器数量是否足够。

因此实现的关键点在于硬件，而对于软件来说，主要涉及工作量。

2.2 两路CAN都为CAN FD，仲裁段波特率500Kbps，数据段波特率为2Mbps，采样点均为80%，都支持标准帧和扩展帧格式；

对于这条需求，考虑因素有两个方面：

一方面是控制器硬件，即CAN收发器和MCU的CAN控制器需要支持CAN FD；

另一方面是控制器软件，CAN通讯功能模块需要支持CAN FD报文的处理。

另外针对CAN数据帧格式，传输速率及采样，主要涉及软件开发的内容，另外可能需要确保测试设备支持CAN FD的测试验证。

source：CANFD an introduction, from Vector

为了更好地理解这些需求，这里对这些术语稍作解释:

CAN FD的可变速率。CAN FD采用了两种位速率：从控制场中的BRS位到ACK场之前（含CRC分界符）称为数据段速率，如上图蓝色部分，其余部分仲裁段速率。两种速率各有一套位时间定义寄存器，它们除了采用不同的位时间单位TQ外，位时间各段的分配比例也可不同，所以两者可以设置不同的波特率和采样点。500Kbps表示1秒钟可以传输500,000bit的数据，2000Kbps表示1秒钟可以传输2000,000bit的数据。

标准和扩展格式的数据帧。两者的区别在仲裁段，标准格式的仲裁段包含11位基本ID位和RTR位，而扩展格式的仲裁段除了11位基本ID位和RTR位外，还包含SRR位，IDE位和18位扩展ID位。即标准格式可表示的CAN ID（11位）范围为 0X000~0X7FF，而扩展格式可表示的CAN ID（29位）范围为0X00000000~0X1FFFFFFF。如下所示：

source：CAN_E: Data Frame (vector.com)

2.3 CAN1需要根据已提供的CAN通讯矩阵或DBC进行开发

对于这条需求的理解，可以参考很不错的两篇文章（写的非常清楚）：

一文了解CAN矩阵与DBC文件；

CAN矩阵和DBC里有哪些隐藏信息？

主要工作内容在软件，包括CAN驱动的配置，CAN报文的收发，CAN报文信号的提取和转换等。对于CAN通讯矩阵中的信号不再做详细解释，这里了解下报文中包含保护或校验信息，比如校验和（Checksum）和滚动计数器（Rolling Counter）。

Checksum。它是用来判断CAN报文传输过程是否会出现错误，报文的发送方采用特定的Checksum校验算法计算一条报文的CRC校验码，再将该校验码放到该报文数据中，与报文中的其他信号一起发送到CAN总线。然后报文的接收方会读取到该校验码，同时采用相同的Checksum校验算法计算出CRC校验码，再对比这两个校验码，如果一致，则说明报文传输过程没有出现错误，否则认为报文传输过程有误，这条报文有问题。

Rolling counter。它是用来判断报文传输过程是否出现丢帧，报文的发送方发送一条报文就计数器加1，从0累加到15，然后不断循环。如果出现计数器不连续或首尾值不对，报文的接收方会认为丢帧。

其实对于整个CAN通讯需求开发内容，CAN通讯矩阵涉及内容最多，并且贯穿整个软件开发的周期。

2.4 CAN1需要支持特定帧报文唤醒，支持局部网络唤醒功能等

对于这条需求，需求明确要特定帧报文唤醒功能，即对控制器硬件设计有要求，选用的CAN收发器芯片要支持特定帧唤醒。其次需求要求支持局部网络唤醒功能，因此涉及到复杂的网络管理策略。以底盘域的网络唤醒例子来理解，如下所示：

一个ECU可能存本地唤醒和网络唤醒等，比如上图中假设IEB的本地唤醒源是制动踏板行程传感器BPS，即某个唤醒场景下，BPS感知到变化，以硬线信号形式传给IEB，那么处于休眠的IEB将被唤醒，对应着图中1区域。IEB唤醒后将请求唤醒EPS和VCU参与功能控制，这部分与网络唤醒策略相关。

以上就列举了一个典型的网络管理场景，要实现这样的场景，会涉及几个方面内容:

唤醒功能逻辑需求，以怎样的逻辑精准识别唤醒源；

网络管理状态机需求，采用怎么样形式,AutoSAR NM吗？以及状态之间的跳转条件和每个状态下的动作是怎样定义的；

网络管理报文需求。网络管理报文内容是怎么定义，接收与发送的规则是怎样的等。

上述这些内容唤醒源检测会涉及到硬件设计，在硬件具备的情况下，那么开发的内容均由软件来实现。关于网络管理需求的实现，除了单个ECU自身需求实现，其实与其他ECU强相关，因为这些唤醒场景由这些ECU共同实现。

#03 CAN通讯需求总结

上文就从ECU系统视角介绍完了CAN通讯主要需求有哪些，怎么理解这些需求以及这些需求需要谁来实现。

当然还有很多CAN通讯需求本文还未提及展开，比如：

CAN总线Bus off处理需求；

CAN报文的诊断需求，比如ID检测，超时检测，Checksum校验和故障后处理措施等；

功能安全相关的E2E保护需求。

总之，CAN通讯其实是一个非常大的话题，内容非常多非常复杂，不管在主机厂还是供应商，不管是ECU系统还是ECU软硬件，都有很多相关的工作需要做，很多细节需要把控