从ECU系统视角理解CAN通讯需求

在软件定义汽车这个时代，汽车功能越来越丰富，随之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软硬件进行相应的开发与验证，最后由系统进行验证和确认。

Source: 一文了解汽车功能开发要做什么？怎么做？

本文将侧重点在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驱动的配置，CAN报文的收发，CAN报文信号的提取和转换等。对于CAN通讯矩阵中的信号不再做详细解释，这里了解下报文中包含保护或校验信息，比如校验和（Checksum）和滚动计数器（Rolling Counter）。

Checksum。它是用来判断CAN报文传输过程是否会出现错误，报文的发送方采用特定的Checksum校验算法计算一条报文的CRC校验码，再将该校验码放到该报文数据中，与报文中的其他信号一起发送到CAN总线。然后报文的接收方会读取到该校验码，同时采用相同的Checksum校验算法计算出CRC校验码，再对比这两个校验码，如果一致，则说明报文传输过程没有出现错误，否则认为报文传输过程有误，这条报文有问题。
Rolling counter。它是用来判断报文传输过程是否出现丢帧，报文的发送方发送一条报文就计数器加1，从0累加到15，然后不断循环。如果出现计数器不连续或首尾值不对，报文的接收方会认为丢帧。

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