RID (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.
Updated This page as Markdown
In short
A routine identifier (RID) is a 16-bit value that names a function an ECU can execute on request through RoutineControl (service 0x31): erase flash, check programming dependencies, run an actuator test, start a self-test. ISO 14229-1 Annex F reserves a few RIDs such as FF00 eraseMemory and FF01 checkProgrammingDependencies; most of the space is vehicle manufacturer or system supplier specific and is defined in the ODX or CDD file of the ECU.
What is a RID?
A routine identifier is a two-byte number that selects a routine, a function the ECU executes when asked. Routines are the catch-all of UDS: everything that is not reading or writing a data record and not transferring memory is modelled as a routine. The tester starts it with 31 01 <RID> [routineControlOptionRecord], stops it with 31 02 <RID> and asks for the result with 31 03 <RID>. The ECU answers 71 01 <RID> [routineInfo] [routineStatusRecord].
Typical routines are erasing a flash block before programming (31 01 FF 00 with the memory range as option record), checking programming dependencies after flashing (31 01 FF 01), running an actuator or self-test, resetting learned values or clearing a protection flag.
Where is it defined?
ISO 14229-1:2020 clause 15.2 defines RoutineControl and Annex F the routine identifier ranges. 0x0000 to 0x00FF are ISO/SAE reserved, 0x0100 to 0x01FF belong to tachograph test IDs, 0x0200 to 0xDFFF are vehicle manufacturer specific, 0xE000 to 0xE1FF map the OBD test IDs, 0xE200 is DeployLoopRoutineID for airbag systems and 0xE201 to 0xE2FF are safety system routines. 0xF000 to 0xFEFF are system supplier specific. The block 0xFF00 to 0xFF02 is the one most testers know: FF00 eraseMemory, FF01 checkProgrammingDependencies, FF02 eraseMirrorMemoryDTCs. The meaning of every manufacturer RID, its option record and its result come from the ECU’s ODX or CDD file.
What it means in practice
RIDs are the service where a diagnostic request has a physical effect. Erase memory bricks the application until it is reprogrammed, an actuator test moves something, a calibration reset changes how the ECU behaves on the road. On the bench, the question is never only which RIDs exist, but in which session they start and whether SecurityAccess stands in front of them.
We regularly see routines that start in the extended session without SecurityAccess although they change persistent state, routines that accept option records of any length, and FF00 eraseMemory reachable in the programming session with a weak seed/key in front of it. We also see ECUs that answer 0x78 responsePending for a long routine and then never deliver the final response.
How AutoST tests it
AutoST does not brute-force routine identifiers. It imports the ODX, PDX or CDD file of the ECU, extracts the defined routines and calls exactly those with RoutineControl (0x31), using the payload from the file or one you override per routine, and records request and response. Enumeration flags 0x31 as a risky service wherever it answers, and the risk score weights it.
Common misunderstandings
A RID is not a DID. Both are two bytes and both come from ODX or CDD, but a DID names a data record and a RID names an action, and the two identifier spaces are independent. And a routine that answers 7F 31 22 conditionsNotCorrect exists; the ECU only refuses to run it right now, for example because the engine is running or the voltage is out of range.
FAQ
Frequently asked questions
Can RIDs be brute-forced like DIDs?
Not sensibly. Starting an unknown routine can erase memory, move an actuator or put the ECU into a state it does not leave. A RID sweep is therefore a destructive test, and a responsible scan calls only the routines the ODX or CDD file defines, with the payload the file expects.
What does the ECU answer when a routine is started?
A positive response 71 01 followed by the RID and optionally a routineInfo byte and a routineStatusRecord. 31 01 FF 01 is answered with 71 01 FF 01 plus the result of the dependency check. Unknown RIDs get 7F 31 31, protected ones 7F 31 33.
Which RIDs should be protected by SecurityAccess?
Every routine that changes the ECU or the vehicle: erase memory, write protection changes, actuator tests, calibration resets, end-of-line functions. A read-only self-test may be acceptable in the extended session, but the manufacturer specification decides.
Sources
Related pages
- GlossaryRoutineControl (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.
- GlossaryDID (Data Identifier)A DID is the 16-bit identifier UDS uses to address a data record, read with 0x22 and written with 0x2E. Standard ranges from ISO 14229-1 Annex C and writable DIDs.
- GlossaryODX (Open Diagnostic Data Exchange)ODX (ISO 22901-1, ASAM MCD-2 D) is the XML format that describes how an ECU speaks UDS: services, DIDs and routines. How it is structured and what testers do with it.
- GlossaryCDD (CANdela Diagnostic Description)A CDD file is the Vector CANdela description of an ECU diagnostic interface: sessions, services, DIDs, routines and security levels. What it holds and how testers use it.
- 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.
