UDS tester之Tdrm
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，待进行下一次重新发送。
(4)tester 维持会话
作为client端，请求服务器进入非default session后，如果没有请求，要周期发送tester present报文来保持会话，如果应用层发起了其他请求从而使状态机进入非idle状态后，就不需要发送tester present报文了。
四、Tdrm的局限性
在这个架构下是无法多路并发的。不过在实际的情况下，如果需要诊断总数不多的ecu，一般的做法是轮询，但如果所在ecu需要诊断、刷写的ecu比较多，论询是非常耗时的，如果能把这个过程与ecu之间的诊断或刷新顺序进行解偶，同时对多个ecu进行操作，就可以极大提升诊断或刷写速度了。