# RID (Routine Identifier)

> 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.

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.

Source: https://auto-st.com/glossary/rid · Updated: 2026-10-07

## 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

**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

- [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer, clause 15.2 (RoutineControl) and Annex F (routine identifier definitions)](https://www.iso.org/standard/72439.html)
- [ISO 22901-1:2008 Road vehicles, Open diagnostic data exchange (ODX), Part 1: Data model specification](https://www.iso.org/standard/41207.html)

## Related

- [RoutineControl (0x31)](https://auto-st.com/glossary/routine-control-0x31)
- [DID (Data Identifier)](https://auto-st.com/glossary/did)
- [ODX (Open Diagnostic Data Exchange)](https://auto-st.com/glossary/odx)
- [CDD (CANdela Diagnostic Description)](https://auto-st.com/glossary/cdd)
- [Your ODX and CDD, turned into tests.](https://auto-st.com/did-routine-scanning)
- [Know every door into the ECU.](https://auto-st.com/uds-enumeration)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/rid
