UDS tester之Tdrm

最新推荐文章于 2025-06-27 21:18:54 发布

随想ustb

最新推荐文章于 2025-06-27 21:18:54 发布

阅读量2.4k

点赞数

CC 4.0 BY-SA版权

分类专栏：汽车电子文章标签： UDS Tester Tdrm

本文链接：https://blog.youkuaiyun.com/daniellee_ustb/article/details/79330774

汽车电子专栏收录该内容

4 篇文章

订阅专栏

本文介绍了UDS Tester的工作原理，包括其内部状态机定义、四个关键定时器的作用及Tdrm的工作流程。并探讨了Tdrm在实际应用中的局限性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

UDS tester之Tdrm

2018-1-16

Tdrm叫做 tester diagnostic request manager,或者叫做诊断请求测试管理器，今天以vector的Tdrm为例，研究下它的工作流程。

一、Tdrm的作用

如果你在做汽车ECU，那么当做诊断服务的时候一定会用到UDS，而如果恰好你所开发的ECU也有诊断其他ECU的需求，那么就一定会用到tester端软件。Tester可以调用TP层，向其他ecu发起诊断请求，实现全车诊断、ECU软件刷写的功能，十分有用。它也可以处理ecu的反馈，供用户层使用。

二、一个状态机，四个timer

先看下内部状态机的定义,tester一共定义了8个状态，空闲状态; 默认会话下的空闲状态（用于查询当前是否可以进行诊断操作，只有在idle的条件下才可以发起下一次诊断）; 诊断请求发送过程中;等待请求发送完成;等待ecu应答;接收进行中（无请求的接收）; 请求接收结果接收中; 等待下一次进入idle的delay。

typedef enum _tTdrmState

{

kTdrmStateIdle, /* System in idle state */

kTdrmStateIdleSessionActive, /* System session is active (just for TdrmGetStatus() when in idle mode) */

kTdrmStateTxInProgress, /* Temporary state while sending data */

kTdrmStateWaitSendReqConfirm, /* Request issued to TP. Waiting for confirmation */

kTdrmStateWaitEcuResponse, /* Service successfully transmitted to ECU. Wait for ECU response */

kTdrmStateRxInProgress /* Temporary state while receiving data */

kTdrmStateWaitRxInProgress /* Temporary state while receiving data */

kTdrmStateWaitIdle /* Temporary state after a transmission */

} tTdrmState;

四个timer P2, P2Star, S3, P3

P2: 客户端请求到ECU的响应时间, typical 100ms。

P2Star: 增强延时时间，当client收到 0x78的否定响应时，会多延长一会等待时间，典型值为 5000ms。

S3:client发送两次test present（3E,00）的间隔。

P3:在没有应答的条件下，两次请求之间（从第一次请求timeout到第二次请求发出）插入的延时时间。

三、Tdrm的工作流程分析

下面用一张图表示这几个状态是如何转换的：

(1)tester 初始化

Tdrm 正常工作前应该首先调用TdrmInitPowerOn()来初始化状态机用到的几个timer，根据当前MCU执行的周期，计算出所有时间参数对应的循环数量; 调用TdrmInit()来初始化状态机到idle状态，关闭定时器以及清除请求标志等，此时状态机停留在S1状态。需要周期性调用TdrmTask()，来推动状态机转换。

(2)tester 发送请求

当应用层调用TdrmServiceRequest()来请求某一个服务时，此时App需要把请求服务的数据字和长度填充好，再调用TP层将数据发送出去;此处就直接返回发送成功，之后就就进入等待ECU应答的S4状态。与此同时，TP发送完请求后会调用CanTp_NUSDataIndication进而调用TdrmSendConfirm,这里会判断这个请求是否需要ecu应答，如果需要就进入到S5状态，如果不需要应答肯定响应，就进入S8，继而回到S1 idle状态。

(3)tester 接收响应

在S5 等待ECU应答状态下，会启动一个定时器P2，如果在规定的时间内TP收到了SF或者FF，那就会调用TdrmPrepareReception，使其进入到S7也就是等待接收过程中;如果接收完成或这接收失败都会重新回到S1。如果在规定的时间内没有收到任何应答，待P2超时后回到S1,此时重试次数减一，重置P2，待进行下一次重新发送。