The tdrm of the UDS tester

the tdrm of the UDS tester

2018-1-16

TDRM is called Tester Diagnostic request Manager, or the diagnostic Request Test Manager, and today takes the tdrm of vectors as an example to study its workflow.

first, the role of TDRM

If you're working on a car ECU, you'll use the UDs as a diagnostic service, and if you're developing an ECU that also has the need to diagnose other ECUs, then you're sure to use the tester end software. Tester can call the TP layer, to initiate the diagnostic request to other ECU, realize the whole vehicle diagnosis, the ECU software brush writes the function, is very useful. It can also handle the feedback from the ECU for use by the user layer.

second state machine, four timer

First look at the definition of the internal state machine, tester altogether defined 8 states, idle state; Idle state under the default session (used to query whether diagnostic operations are currently available, the next diagnosis can be initiated only under idle conditions); The diagnostic request is sent, waiting for the request to be sent, waiting for the ECU to answer, receiving in progress (no request received); Receiving the result of receiving the request; Wait for the next time to enter idle delay.

typedef enum _TTDRMSTATE

{

Ktdrmstateidle,/* System in idle state */

Ktdrmstateidlesessionactive,/* System session is active (just for Tdrmgetstatus () if 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;

Four timer P2, P2star, S3, P3

P2: The client requests the response time to the ECU, typical 100ms.

P2star: Enhanced delay time, when the client receives 0x78 negative response, it will prolong the wait time, the typical value is 5000ms.

S3:client sends two times the interval of test present (3e,00).

P3: In the absence of an answer, the time delay between two requests (from the first request timeout to the second request) is inserted.

three, the work flow analysis of TDRM

The following diagram shows how these states are converted:

(1) Tester initialization

TDRM before normal work should call Tdrminitpoweron () to initialize the state machine to use a few timer, according to the current MCU execution cycle, calculate all the time parameters corresponding to the number of cycles; Call Tdrminit () to initialize the state machine to the idle state, turn off the timer, and clear the request flag, and the state machine stays in the S1 state. A periodic call to Tdrmtask () is required to push the state machine transformation.

(2) Tester Send request

When the application layer calls Tdrmservicerequest () to request a service, the app needs to fill in the data word and length of the requested service, and then call the TP layer to send the data out, and then return to the sending success, and then enter the S4 state waiting for the ECU to answer. At the same time, TP send the request will call Cantp_nusdataindication and then call Tdrmsendconfirm, here will determine whether the request requires an ECU response, if necessary to enter the S5 state, if you do not need to answer affirmative response, enter S8, Then return to the S1 idle state.

(3) Tester receive response

When the S5 waits for the ECU to be answered, a timer P2 is initiated, and if the TP receives SF or FF within the specified time, then tdrmpreparereception is called to go to S7, which is waiting for the receiving process; If the receive is complete or the receive fails, it will return to S1. If no response is received within the specified time, wait for the P2 timeout to return to S1, at which time the number of retries is reduced by one, resetting the P2, pending the next resend.

(4) Tester Maintenance session

As the client side, after the request server enters the non-default session, if there is no request, to periodically send the tester present message to maintain the session, if the application layer initiates other requests so that the state machine enters the non-idle state, it does not need to send tester Present the message.

Iv. Limitations of TDRM

         cannot be multiplexed in this architecture. However, in the actual case, if the need to diagnose the total number of ECUs, the general practice is polling, but if the ECU needs to diagnose, brush write more ECU, the inquiry is very time-consuming, if it can be the process with the ECU diagnostic or refresh sequence to be coupled to the operation of multiple ECUs, Can greatly improve the speed of diagnosis or brush writing.