UDS?tester之Tdrm?

2018-1-16

????????Tdrm叫做?tester?diagnostic?request?manager,或者叫做診斷請求測試管理器，今天以vector的Tdrm為例，研究下它的工作流程。

一、Tdrm的作用

????????如果你在做汽車ECU，那么當(dāng)做診斷服務(wù)的時候一定會用到UDS，而如果恰好你所開發(fā)的ECU也有診斷其他ECU的需求，那么就一定會用到tester端軟件。Tester可以調(diào)用TP層，向其他ecu發(fā)起診斷請求，實(shí)現(xiàn)全車診斷、ECU軟件刷寫的功能，十分有用。它也可以處理ecu的反饋，供用戶層使用。

二、一個狀態(tài)機(jī)，四個timer

????????先看下內(nèi)部狀態(tài)機(jī)的定義,tester一共定義了8個狀態(tài)，空閑狀態(tài);?默認(rèn)會話下的空閑狀態(tài)（用于查詢當(dāng)前是否可以進(jìn)行診斷操作，只有在idle的條件下才可以發(fā)起下一次診斷）;?診斷請求發(fā)送過程中;等待請求發(fā)送完成;等待ecu應(yīng)答;接收進(jìn)行中（無請求的接收）;?請求接收結(jié)果接收中;?等待下一次進(jìn)入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的響應(yīng)時間,?typical?100ms。

????????P2Star:?增強(qiáng)延時時間，當(dāng)client收到?0x78的否定響應(yīng)時，會多延長一會等待時間，典型值為?5000ms。

????????S3:client發(fā)送兩次test?present（3E,00）的間隔。

????????P3:在沒有應(yīng)答的條件下，兩次請求之間（從第一次請求timeout到第二次請求發(fā)出）插入的延時時間。

三、Tdrm的工作流程分析

????????下面用一張圖表示這幾個狀態(tài)是如何轉(zhuǎn)換的：

?

????????(1)tester?初始化

????????Tdrm?正常工作前應(yīng)該首先調(diào)用TdrmInitPowerOn()來初始化狀態(tài)機(jī)用到的幾個timer，根據(jù)當(dāng)前MCU執(zhí)行的周期，計(jì)算出所有時間參數(shù)對應(yīng)的循環(huán)數(shù)量;?調(diào)用TdrmInit()來初始化狀態(tài)機(jī)到idle狀態(tài)，關(guān)閉定時器以及清除請求標(biāo)志等，此時狀態(tài)機(jī)停留在S1狀態(tài)。需要周期性調(diào)用TdrmTask()，來推動狀態(tài)機(jī)轉(zhuǎn)換。

????????(2)tester?發(fā)送請求

????????當(dāng)應(yīng)用層調(diào)用TdrmServiceRequest()來請求某一個服務(wù)時，此時App需要把請求服務(wù)的數(shù)據(jù)字和長度填充好，再調(diào)用TP層將數(shù)據(jù)發(fā)送出去;此處就直接返回發(fā)送成功，之后就就進(jìn)入等待ECU應(yīng)答的S4狀態(tài)。與此同時，TP發(fā)送完請求后會調(diào)用CanTp_NUSDataIndication進(jìn)而調(diào)用TdrmSendConfirm,這里會判斷這個請求是否需要ecu應(yīng)答，如果需要就進(jìn)入到S5狀態(tài)，如果不需要應(yīng)答肯定響應(yīng)，就進(jìn)入S8，繼而回到S1?idle狀態(tài)。

????????(3)tester?接收響應(yīng)

????在S5?等待ECU應(yīng)答狀態(tài)下，會啟動一個定時器P2，如果在規(guī)定的時間內(nèi)TP收到了SF或者FF，那就會調(diào)用TdrmPrepareReception，使其進(jìn)入到S7也就是等待接收過程中;如果接收完成或這接收失敗都會重新回到S1。如果在規(guī)定的時間內(nèi)沒有收到任何應(yīng)答，待P2超時后回到S1,此時重試次數(shù)減一，重置P2，待進(jìn)行下一次重新發(fā)送。

????????(4)tester?維持會話

????????作為client端，請求服務(wù)器進(jìn)入非default?session后，如果沒有請求，要周期發(fā)送tester?present報(bào)文來保持會話，如果應(yīng)用層發(fā)起了其他請求從而使?fàn)顟B(tài)機(jī)進(jìn)入非idle狀態(tài)后，就不需要發(fā)送tester?present報(bào)文了。

四、Tdrm的局限性

????????在這個架構(gòu)下是無法多路并發(fā)的。不過在實(shí)際的情況下，如果需要診斷總數(shù)不多的ecu，一般的做法是輪詢，但如果所在ecu需要診斷、刷寫的ecu比較多，論詢是非常耗時的，如果能把這個過程與ecu之間的診斷或刷新順序進(jìn)行解偶，同時對多個ecu進(jìn)行操作，就可以極大提升診斷或刷寫速度了。

總結(jié)

以上是生活随笔為你收集整理的UDS tester之Tdrm的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。