【AUTOSAR案例分析】CANFD 诊断路由为CAN诊断，诊断仪显示超时问题分析

不懂叫啥名

已于 2023-06-18 17:14:20 修改

阅读量1k

点赞数 5

分类专栏： AUTOSAR案例分析文章标签：汽车 mcu c语言

于 2023-06-18 17:10:07 首次发布

本文链接：https://blog.csdn.net/u010074542/article/details/131273519

版权

AUTOSAR案例分析专栏收录该内容

3 篇文章 3 订阅

订阅专栏

文章讨论了在汽车诊断过程中，TestTool通过GWECU向DESTECU传输数据时遇到的效率问题。当使用CANFD的高速传输与DESTECU仅支持CAN诊断的不匹配时，GWECU需将CANFD数据转换为CAN。为解决转发延迟导致的响应超时，提出在TPThreshold设置为DESTECU一帧CAN报文长度，允许GWECU在接收到一定量数据后即开始转发，实现更高效的并行传输。

摘要由CSDN通过智能技术生成

一. 背景

在车上，诊断仪（Test Tool）需要诊断其他ECU很多需要通过GW ECU路由诊断报文给到目标ECU，大多数时候为了节省链路上交互的时间，Test Tool和GW ECU会通过CAN FD 64 Byte的形式传输诊断数据，提高一次传输的速度和一次传输的长度，但是有些时候DEST ECU只支持CAN诊断的形式，因此GW ECU就需要实现基于CAN TP模块的路由，将CAN FD（64 Byte）诊断转换成CAN(8 Byte)的诊断，如下图所示：

部分ECU在实现的时候，GW ECU是在接收完诊断仪的完整一包数据之后，在转发给到DEST ECU，由于GW ECU转发给到DEST ECU的时候用的是CAN诊断，速率比较慢，长度比较短，传输完完整一包耗费的时间△t会比较久，因此会导致Tester ECU等待响应超时的问题（如下图所示），因此可以考虑配置成在Tester给GW发送包的中间，GW也同步给DEST_ECU发送数据，类似于并行传输数据。

二. 解决方法

在PDUs-->Routing Paths-->需设置的PduR-->TP Threshold，设置为DEST一帧CAN报文的长度，如8个Byte，这样，当GW ECU接收到Tester Tool发送的诊断数据长度达到8 Byte时，其就开始转发给到DEST ECU了，这样避免需要等待GW ECU接收完完整诊断数据之后才能转发导致的延时