2025年汽车can报文帧id解析（汽车can报文dbc）

大家好，我是讯享网，很高兴认识大家。

来 源:汽车电子与软件 | 首图 图源:网络 | 作者:糊涂振

全文 3000+ 字，预计阅 读 15-25 分钟

在软件定义汽车这个时代，汽车功能越来越丰富，随之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

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

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

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

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

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

#02

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

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

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

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

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

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

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

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

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

source：CANFD an introduction, from Vector

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

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

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

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

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

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

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

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

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

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

#03

CAN通讯需求总结

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

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

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

<- 联系 & 声明 ->

转发、点赞、在看

，安排一下？