汽车ECU系统层级的CAN通讯解析w1.jpg

在这个不断内卷的汽车行业，大家都在拼命卷价格卷配置卷功能，目前汽车的很多功能需要多个控制器联合实现，主流通讯方式仍然采用的是CAN通讯。通过CAN通讯实现各个控制器（ECU）之间信息交互，比如网络唤醒功能，最开始主动唤醒源唤醒某个ECU，然后该ECU再通过CAN特定帧发送网络管理报文给相关的各控制器，以此实现某个功能的唤醒场景。



source: 纯电动汽车DCDC唤醒系统及唤醒方法与流程在之前文章：

CAN矩阵和DBC里有哪些隐藏信息？(qq.com)一文了解CAN矩阵与DBC文件 (qq.com)

已经介绍了在OEM层面对CAN通讯所需要做的工作，这些工作往下传递到各个控制器系统，通常会输入给ECU系统工程师，这时正式进入CAN通讯落地的第二阶段。
1 ECU系统会收到哪些CAN通讯需求

OEM输入给ECU系统CAN通讯的需求会涉及以下几个点:

首先是最基本需求，ECU需要具备几路CAN，是否要支持CAN FD；每路CAN的传输速率和采样点要求，波特率是否需要支持可标定；

然后是CAN通讯矩阵开发需求；

其次是与功能安全相关的E2E保护需求；

最后是CAN网络管理需求。

这些需求都是目前ECU CAN通讯开发的通用需求，按照汽车控制器研发的标准V流程，这些需求称为客户需求或者利益相关者需求Stakeholder requirement，对应Aspice的SYS.1层级。因此，从研发流程上来说，在ECU系统层面，系统工程师收到这些需求后，会拉上相关利益者一起来评估这些需求，包括硬件，软件，功能安全和项目经理等项目内部成员，同时也会和客户多次对齐，一方面明确需求所需实现的内容，另一方面明确需求释放的软硬件版本和时间节点。


source: Automotive Software Process Improvement and Capacity Determination

在SYS.1阶段，ECU系统工程师的作用可大可小，取决于其对CAN通讯的掌握程度。那在ECU系统层面需要掌握到什么程度？以及具体需要掌握哪些内容？接下来基于输入的CAN通讯需求继续从ECU系统层级角度来探讨，ECU系统工程师该如何去理解与评估这些CAN通讯需求。这里先放上ECU系统工程师的交付物，即Aspice的SYS.2 系统需求，对于CAN通讯这块有:

ECU需要具备两路CAN，一路CAN用于ECU之间的通讯，根据已提供的CAN通讯矩阵或DBC进行开发；另一路CAN用于诊断通讯和XCP标定，满足ISO14229和ISO15765，以及XCP协议；

两路CAN都支持CAN FD，且仲裁段波特率为500Kbps，采样点为75%，数据段波特率为2Mbps，采样点为80%；

E2E保护采用AutoSAR所定义的Profile1；

通讯CAN需要支持任意帧报文唤醒，以及AutoSAR NM策略。

注意不管上面这些内容有没有理解，首先先将利益相关者需求细化分解ECU系统需求很重要，因为实际工作中交付第一，其次是搞清楚，最终谁来落地，谁来交作业。当然这里想抛开这两点，回归需求本身，探究CAN通讯需求为什么或怎么分解。2 如何理解ECU系统层级的CAN通讯需求  

就ECU系统工程师的经历来说，对于每一条系统需求，一方面要理解需求本身，即，另一方面也要知道与需求相关的角色，即相关利益方。

ECU需要具备两路CAN，一路CAN用于ECU之间的通讯，根据已提供的CAN通讯矩阵或DBC进行开发；另一路CAN用于诊断通讯和XCP标定，满足ISO14229和ISO15765，以及XCP协议。

解析：使用两路CAN的主要考虑因素有：总线负载率和产品功能需求等，因此，OEM定义一路用作ECU通讯，比如底盘域总线挂上XYZ,、EPB、CDC和IEB等；OEM定义另一路用于诊断通讯和标定功能。然后这里涉及的标准协议有几个，其中，ISO14229定义了诊断通讯的内容与方式，ISO15765定义了CAN通讯的单帧与多帧的通讯方法，XCP协议定义了上位机如何与ECU进行通讯交互。有了这些认识之后，那么对于这条需求的评估考虑有：

ECU硬件是否足够数量的接插件Pin以支持提供两路CAN_H和CAN_L，以及PCB是否有足够的大小来布置CAN收发器及其处理电路；微控制器MCU的CAN控制器是否足够。

由此可见，这条需求的关键点与硬件相关，硬件满足后，再考虑软件。

两路CAN都支持CAN FD，且仲裁段波特率为500Kbps，采样点为75%，数据段波特率为2Mbps，采样点为80%；

解析：此需求需要考虑两个方面：

一是ECU硬件，CAN收发器和MCU都需要支持CAN FD；二是ECU软件，CAN通讯协议栈支持CAN FD报文处理。

主要工作量在软件，但是在测试验证时，注意配置正确的波特率和采样点:


source：Vector - CAPL - CANoe硬件CAN&CANFD参数_canoe设置波特率这里对波特率/速率稍作解释；CAN FD采用了两种位速率：从控制场中的BRS位到ACK场之前（含CRC分界符）称为数据段速率，如上图蓝色部分，其余部分仲裁段速率，它俩可以分别设置不同的波特率和采样点。

E2E保护采用AutoSAR所定义的Profile1；

解析：E2E策略的整体思路是CRC校验和计数，在原始数据的基础上增加控制段形成E2E报头，AUTOSAR提供了多种E2E的配置来适用各种场景，E2E Profile 1的配置如下：


E2E Profile 1中发送到RTE的数据需要包含3个部分：4个bit的计数器，8个bit的CRC以及原数据。其中，计数器每发送一次值就加1；对Data ID、Counter和原数据进行CRC计算，并将结果填入CRC字节。这里对计数和CRC校验稍作解释：

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

通讯CAN需要支持任意帧报文唤醒，以及AutoSAR NM策略。

解析：这条需求明只要任意帧报文唤醒，则选用合适的CAN收发器即可；然后要求支持AutoSAR NM，那么就确定了网络管理状态机需求，不过这里仍然需要再明确NM各状态之间的跳转条件和动作，以及网络管理报文的发送要求，包括内容与时间等。

总的来说，网络管理功能通常会涉及到硬件和软件设计，另外除了上述这条需求，对于网络管理功能的实现，通常还需要唤醒场景的详细需求。
3 小结

上述大致描述了CAN通讯功能实现从OEM提出到ECU系统消化吸收，再细化，给软硬件。总的来说，最好的情况是在ECU系统层面能够进行有意义的细化成系统需求，然后在此基础上，硬件和软件分别细化成各自的需求，即硬件需求和软件需求，以此较好地将CAN通讯功能落地。

---

创作不易，欢迎点赞再看收藏关注！

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