• 426查看
  • 0回复

[网络开发] 汽车ECU系统层级的CAN通讯解析

[复制链接]


该用户从未签到

发表于 11-2-2025 18:54:48 | 显示全部楼层 |阅读模式

汽车零部件采购、销售通信录       填写你的培训需求,我们帮你找      招募汽车专业培训老师


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


汽车ECU系统层级的CAN通讯解析w1.jpg
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系统层面,系统工程师收到这些需求后,会拉上相关利益者一起来评估这些需求,包括硬件,软件,功能安全和项目经理等项目内部成员,同时也会和客户多次对齐,一方面明确需求所需实现的内容,另一方面明确需求释放的软硬件版本和时间节点。
汽车ECU系统层级的CAN通讯解析w2.jpg

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控制器是否足够。

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

由此可见,这条需求的关键点与硬件相关,硬件满足后,再考虑软件。
    两路CAN都支持CAN FD,且仲裁段波特率为500Kbps,采样点为75%,数据段波特率为2Mbps,采样点为80%;
解析:此需求需要考虑两个方面:
    一是ECU硬件,CAN收发器和MCU都需要支持CAN FD;二是ECU软件,CAN通讯协议栈支持CAN FD报文处理。

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

汽车ECU系统层级的CAN通讯解析w4.jpg
source:Vector - CAPL - CANoe硬件CAN&CANFD参数_canoe设置波特率这里对波特率/速率稍作解释;CAN FD采用了两种位速率:从控制场中的BRS位到ACK场之前(含CRC分界符)称为数据段速率,如上图蓝色部分,其余部分仲裁段速率,它俩可以分别设置不同的波特率和采样点。
    E2E保护采用AutoSAR所定义的Profile1;
解析:E2E策略的整体思路是CRC校验和计数,在原始数据的基础上增加控制段形成E2E报头,AUTOSAR提供了多种E2E的配置来适用各种场景,E2E Profile 1的配置如下:
汽车ECU系统层级的CAN通讯解析w5.jpg

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各状态之间的跳转条件和动作,以及网络管理报文的发送要求,包括内容与时间等。
汽车ECU系统层级的CAN通讯解析w6.jpg
总的来说,网络管理功能通常会涉及到硬件和软件设计,另外除了上述这条需求,对于网络管理功能的实现,通常还需要唤醒场景的详细需求。
3 小结

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


创作不易,欢迎点赞再看收藏关注!

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


该用户从未签到

发表于 11-3-2025 00:08:00 | 显示全部楼层
针对汽车ECU系统层级的CAN通讯解析,我们深知汽车行业在激烈竞争下对效率和性能的要求日益提升。关于CAN通讯作为主流通讯方式,它是汽车各控制器间信息交互的关键桥梁。在纯电动汽车DCDC唤醒系统及唤醒方法中,CAN矩阵和DBC文件扮演着至关重要的角色。这些文件不仅定义了数据的格式和结构,还包含了各ECU间的通讯协议和交互规则。在解析CAN通讯时,我们必须深入理解这些隐藏信息,确保信息准确快速地传递,实现网络唤醒功能及其他复杂功能。随着技术的发展,我们也需要不断挖掘CAN通讯的潜力,提升汽车性能和用户体验。

[内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 11-3-2025 00:08:00 | 显示全部楼层
针对汽车ECU系统层级的CAN通讯解析,我们深知汽车行业在激烈竞争下不断提升对控制器联合协作能力的需求。通过CAN通讯实现多个控制器间的信息交互已成为行业主流做法。对于CAN矩阵和DBC文件的应用,它们承载着CAN通讯中的关键信息,如信号定义、数据字典等,在OEM层面为CAN通讯提供了重要的规范与指导。随着电动汽车的发展,DC-DC唤醒系统及唤醒方法变得尤为重要。通过解析CAN通讯中的特定帧,我们可以理解网络唤醒功能的实现方式,即最初由主动唤醒源唤醒某个ECU,再由该ECU通过特定帧向其他相关控制器发送网络管理报文,最终实现功能的唤醒场景。以上信息在实际应用中是极其重要的,对于我们开发更高效的汽车系统具有指导意义。

[内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 11-3-2025 00:08:00 | 显示全部楼层
关于汽车ECU系统层级的CAN通讯解析,随着汽车行业的快速发展,多控制器联合实现功能已成为常态。CAN通讯作为主流通讯方式,是实现各控制器间信息交互的关键。在网络唤醒功能中,最初由主动唤醒源唤醒某个ECU,该ECU通过特定CAN帧发送网络管理报文给相关控制器,实现功能唤醒。在解析CAN矩阵和DBC文件时,隐藏着诸多重要信息,如信号定义、帧描述及节点地址等,这些信息对于准确解析通讯内容至关重要。为确保汽车ECU系统的稳定与安全,建议深入分析并合理利用这些隐藏信息,同时严格遵循OEM层面的通讯需求与规范。这样既能确保汽车功能完善,又能提升整车性能。以上内容供参考,可查阅相关资料文献以获取更多详细信息。

[内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
回复 支持 反对

使用道具 举报


  • TA的每日心情
    无聊
    1-7-2015 18:46
  • 签到天数: 1 天

    [LV.1]初来乍到

    发表于 11-3-2025 00:08:00 | 显示全部楼层
    关于汽车ECU系统层级的CAN通讯解析,这是汽车行业中的重要技术之一。随着功能需求的增长,汽车中的多个控制器需要协同工作,CAN通讯成为主流的信息交互方式。在CAN通讯中,ECU通过特定的帧来发送和接收信息,实现网络唤醒等功能。在DBC和CAN矩阵中,除了基本的通信参数,还包含了一些隐藏信息,如信号定义、帧类型等,这些都是实现功能的关键。对于纯电动汽车DCDC唤醒系统及唤醒方法与流程,我们需要深入了解CAN通讯的详细机制,包括帧结构、通信协议等。只有在充分理解这些基础内容后,才能更好地实现汽车的各种功能,并确保其稳定性和安全性。更多专业信息建议查阅相关技术文档或咨询专业人士。

    [内容由汽车工程师之家人工智能总结,欢迎免费使用,见贴尾]
    回复 支持 反对

    使用道具 举报

    快速发帖

    您需要登录后才可以回帖 登录 | 注册

    本版积分规则

    QQ|手机版|小黑屋|Archiver|汽车工程师之家 ( 渝ICP备18012993号-1 )

    GMT+8, 19-8-2025 02:21 , Processed in 0.431324 second(s), 38 queries .

    Powered by Discuz! X3.5

    © 2001-2013 Comsenz Inc.