TesterPresent (0x3E)

Was ist TesterPresent (0x3E)?

TesterPresent ist der Keep-Alive von UDS. Ein Tester sendet ihn periodisch, um dem Steuergerät zu sagen, dass er noch da ist, damit das Steuergerät in der gewählten Session bleibt, statt in die Default Session zurückzufallen. Der Request hat zwei Bytes, 3E 00 (Sub-Funktion zeroSubFunction), die positive Antwort ist 7E 00. Mit gesetztem suppressPosRspMsgIndicationBit, 3E 80, antwortet das Steuergerät gar nicht, und so senden ihn die meisten Tester.

Der Service trägt keine Daten und löst im Steuergerät nichts aus. Seine einzige Aufgabe ist, den Session-Timer zurückzusetzen.

Wo ist es definiert?

ISO 14229-1:2020 definiert TesterPresent (0x3E) in Kapitel 9 (Diagnostic and communication management functional unit), zusammen mit DiagnosticSessionControl (0x10), ECUReset (0x11), SecurityAccess (0x27) und den anderen Services auf Session-Ebene. Das Timing, das er am Leben hält, ist der S3-Server-Timer der Session-Schicht (ISO 14229-2 für das generische Timing, üblicher Default 5000 ms). Läuft S3 in einer Non-Default Session ab, muss das Steuergerät in die Default Session zurückkehren; damit enden auch ein SecurityAccess-Unlock, und ControlDTCSetting sowie CommunicationControl fallen auf ihre Defaults zurück.

Auf CAN wird TesterPresent typischerweise funktional an alle Steuergeräte am Bus gesendet, zum Beispiel auf der 11-Bit-ID 0x7DF, als einzelner ISO-15765-2-Frame 02 3E 80 00 00 00 00 00, alle zwei bis vier Sekunden.

Was es in der Praxis bedeutet

Jeder automatisierte UDS-Test hängt an diesem Service. Bei der Enumeration der Extended Session, bei einem SecurityAccess-Seed/Key-Lauf oder beim Fuzzing wirft ein fehlender TesterPresent das Steuergerät still in die Default Session zurück, und ab dann antwortet jede Probe mit 7F xx 7F serviceNotSupportedInActiveSession. Tester, die den Keep-Alive vergessen, produzieren Ergebnisse, die wie ein dicht gemachtes Steuergerät aussehen.

Am Prüfstand ist die andere Richtung interessant. Wir sehen regelmäßig Steuergeräte, bei denen TesterPresent die Programming Session unbegrenzt am Leben hält, mit entsperrtem SecurityAccess, sodass der einmalige Unlock eines Flash-Tools zum Dauerzustand wird, solange jemand 3E 80 sendet. Wir sehen auch Steuergeräte ganz ohne S3: Der Tester wird abgezogen, und das Steuergerät bleibt in der Extended Session, während CommunicationControl weiter den normalen Busverkehr abschaltet. Und manche Steuergeräte antworten während eines Resets oder Absturzes weiter mit 7E 00, was naive Crash-Erkennung täuscht. Ein Liveness-Check braucht einen Service, der die Applikation wirklich fordert, oder mindestens eine Prüfung, dass die Session noch die erwartete ist.

Wie AutoST es testet

AutoST sendet TesterPresent als konfigurierbaren Keep-Alive jedes Scans, damit Sessions während Enumeration, DID-Scan und SecurityAccess-Prüfungen nicht abfallen. In der Fuzzing-Engine läuft nach jeder Iteration ein TesterPresent-Liveness-Check, immer aktiv; ein Steuergerät, das nicht mehr antwortet, wird als Crash mit dem exakten vorangegangenen Payload festgehalten. Die Enumeration hält außerdem fest, ob eine Non-Default Session ohne Keep-Alive überlebt, was Steuergeräte mit fehlendem oder viel zu langem S3-Timer sichtbar macht.

Häufige Missverständnisse

TesterPresent entsperrt nichts, verlängert SecurityAccess nicht von sich aus und zählt nicht als Aktivität für die P2-Timer; die gehören zu einzelnen Requests. Er hält nur die Session. Und dass 3E 80 keine Antwort bekommt, ist kein Fehler: Die Antwort ist absichtlich unterdrückt. Willst du wissen, ob das Steuergerät lebt, sende 3E 00 und erwarte 7E 00.