RoutineControl (0x31)
UDS RoutineControl (0x31) starts, stops and reads routines on an ECU by routine identifier (RID). The request and response bytes and what to validate.
Updated This page as Markdown
In short
RoutineControl (0x31) runs a routine on an ECU, identified by a two-byte routine identifier (RID). The sub-function selects start (01), stop (02) or requestResults (03). The request 31 01 FF 01 starts routine 0xFF01, the positive response 71 01 FF 01 confirms it. Most routines need the extended session and often SecurityAccess, because they can erase memory or run self-tests. Which routines exist and what they require is a core validation target.
What is RoutineControl (0x31)?
RoutineControl runs a predefined routine on an ECU. The sub-function byte selects the operation and the two bytes after it are the routine identifier (RID). A routine can be a memory erase, a self-test, a calibration step or a check that returns a result.
A normal exchange:
| Direction | Bytes | Meaning |
|---|---|---|
| Request | 31 01 FF 01 | startRoutine, RID 0xFF01 |
| Positive response | 71 01 FF 01 | routine started |
| Negative response | 7F 31 33 | securityAccessDenied |
Other typical negative responses are 7F 31 31 (requestOutOfRange, unknown RID), 7F 31 12 (subFunctionNotSupported), 7F 31 13 (incorrectMessageLengthOrInvalidFormat), 7F 31 22 (conditionsNotCorrect) and 7F 31 24 (requestSequenceError, results requested before the routine ran).
Where is it defined?
ISO 14229-1:2020 defines RoutineControl (0x31) in the Routine functional unit. The standard specifies the three sub-functions, the two-byte routine identifier, the optional routineControlOptionRecord in the request and the routineStatusRecord in the response. The routines themselves, their identifiers and their input and output records, are defined by the OEM, usually in an ODX or CDD file (ISO 22901-1 for ODX).
What it means in practice
Routines are where the most powerful diagnostic actions live, which is why their access rules matter. The specification fixes which RID exists, what session and security level it needs, and what input it expects. In validation, engineers check:
- each routine answers only in the intended session and at the intended security level;
- an unknown RID gives NRC 0x31, not an unexpected action;
- requestResults before start gives NRC 0x24;
- a wrong-length option record gives NRC 0x13;
- the routine returns a sensible status and leaves the ECU in a defined state.
We regularly find routines that start in the extended session without the SecurityAccess the specification requires, which is a real finding when the routine touches memory or safety functions.
How AutoST tests it
AutoST never brute-forces routines. With an imported ODX, PDX or CDD file it calls only the routines the ECU actually defines, with the request payload you can override per routine, and stores the request and the response. It records in which session and at which security level each routine answers and with which negative response code, so a routine that runs below its required protection level stands out in the results.
FAQ
Frequently asked questions
What do the three sub-functions mean?
startRoutine (0x01) runs the routine, stopRoutine (0x02) stops a running one, and requestRoutineResults (0x03) reads its result. A routine may support all three or only start, depending on what it does.
Why are routines not brute-forced?
A routine identifier addresses a specific action, such as erasing a memory block or starting a self-test, and often needs a structured input record. Calling random RIDs is both meaningless and risky, so the identifiers come from the ODX or CDD file.
What is in the response?
The positive response echoes the sub-function and the two-byte RID, optionally followed by a routineStatusRecord and routine results. For requestRoutineResults the result bytes carry the outcome, for example a pass or fail code.
Sources
Related pages
- GlossaryRID (Routine Identifier)A RID is the two-byte identifier that RoutineControl (0x31) uses to start, stop and query a routine in an ECU, from erase memory (FF00) to manufacturer tests.
- GlossaryUDS (Unified Diagnostic Services)UDS (ISO 14229) is the diagnostic protocol of most automotive ECUs: sessions, services, DIDs and SecurityAccess. What it defines and why it is the first attack surface.
- GlossaryDiagnostic session (DiagnosticSessionControl 0x10)UDS DiagnosticSessionControl (0x10) switches an ECU between default, extended and programming session. Bytes, timing parameters and what to validate.
- PlatformYour ODX and CDD, turned into tests.AutoST imports ODX, PDX and Vector CDD files to name the DIDs it finds and run the right routines (0x31), with opt-in, clearly warned write-probing.
- PlatformKnow every door into the ECU.AutoST enumerates an ECU over UDS: diagnostic endpoints, sessions, all 255 services and readable DIDs, plus XCP/CCP discovery. Risky services are flagged automatically.
- InsightsFinding hidden diagnostic services on an ECUHow undocumented UDS services, sessions and DIDs are found by probing and reading response codes, why they exist, and what a hidden service means for the attack surface.
