TesterPresent (0x3E)

What is TesterPresent (0x3E)?

TesterPresent is the UDS keep-alive. A tester sends it periodically to tell the ECU that it is still there, so the ECU stays in the session the tester selected instead of falling back to the default session. The request is two bytes, 3E 00 (sub-function zeroSubFunction), the positive response is 7E 00. With the suppressPosRspMsgIndicationBit set, 3E 80, the ECU does not answer at all, which is how most testers send it.

The service carries no data and triggers nothing in the ECU. Its only job is to reset the session timer.

Where is it defined?

ISO 14229-1:2020 defines TesterPresent (0x3E) in clause 9 (Diagnostic and communication management functional unit), together with DiagnosticSessionControl (0x10), ECUReset (0x11), SecurityAccess (0x27) and the other session-level services. The timing it keeps alive is the S3 server timer defined by the session layer (ISO 14229-2 for the generic timing, with a common default of 5000 ms). When S3 expires in a non-default session, the ECU must return to the default session, which also ends any SecurityAccess unlock and resets ControlDTCSetting and CommunicationControl to their defaults.

On CAN, TesterPresent is typically sent functionally to all ECUs on the bus, for example on the 11-bit ID 0x7DF, as a single ISO 15765-2 frame 02 3E 80 00 00 00 00 00, every two to four seconds.

What it means in practice

Every automated UDS test depends on this service. During enumeration of the extended session, during a SecurityAccess seed/key run or during fuzzing, a missing TesterPresent silently drops the ECU back into default session, and from then on every probe answers 7F xx 7F serviceNotSupportedInActiveSession. Testers that forget the keep-alive produce results that look like a locked-down ECU.

On the bench the interesting part is the other direction. We regularly see ECUs where TesterPresent keeps the programming session alive indefinitely, with SecurityAccess unlocked, so the one-time unlock of a flash tool becomes a permanent state as long as someone keeps sending 3E 80. We also see ECUs that do not implement S3 at all: the tester disconnects and the ECU stays in the extended session, with CommunicationControl still disabling normal traffic. And some ECUs answer 7E 00 to TesterPresent during a reset or a crash, which fools naive crash detection. A liveness check needs a service that actually exercises the application, or at least a check that the session is still the expected one.

How AutoST tests it

AutoST sends TesterPresent as the configurable keep-alive of every scan, so sessions do not drop during enumeration, DID scanning and SecurityAccess checks. In the fuzzing engine a TesterPresent liveness check runs after every iteration and is always on; an ECU that stops answering it is recorded as a crash with the exact payload that preceded it. Enumeration also records whether a non-default session survives without keep-alive, which exposes ECUs with a missing or far too long S3 timer.

Common misunderstandings

TesterPresent does not unlock anything, does not extend SecurityAccess on its own and does not count as activity for the P2 timers; those belong to individual requests. It only keeps the session. And 3E 80 getting no answer is not an error: the response is suppressed by design. If you want to know whether the ECU is alive, send 3E 00 and expect 7E 00.