Overview of RoutineControl (0x31) Service
If you are interested in learning more about the Unified Diagnostic Services (UDS) proto
col and how it can help you diagnose and control various features of your vehicle, then you have come to the right place! In this blog post, I will introduce you to one of the most useful services in UDS: the RoutineControl (31 hex) service.The RoutineControl service is supported by most ECUs that implement the UDS (Unified Diagnostic Services) protocol. However, the availability and functionality of the routines may vary depending on the ECU type, manufacturer and application. Therefore, it is important to consult the ECU documentation or specification to know which routines are supported and how they work.
Here we will discuss by using the UDS Protocol for Routine Control (0x31) service implementation and how does it works. You will also learn the request and response frame format of Routine Control (0x31) service with an example & explanation.
Terminologies Used in Routine Control (0x31) service of UDS Protocol
- STR: Start Routine.
- STPR: Stop Routine.
- RRR: Request Routine Results.
- SFNS: Sub-Function Not Supported.
- IMLOIF: Incorrect Message Length or Invalid Format.
- CNC: Conditions Not Correct.
- RSE: Request Sequence Error.
- ROOR: Request Out of Range.
- SAD: Security Access Denied.
- GPF: General Programming Failure.
- RCRSID: RoutineControl Request Service Id.
- SBF_ RCTP: Routine Control Sub-function Type.
- RID_B1: Routine Identifier Byte one.
- RCEOR: Routine Control Option Record.
- RCPR: Routine Control Positive Response Service Id
You will learn from this Routine Control (0x31) service Tutorial with below topics:
Table of contents
- Overview of RoutineControl (0x31) Service
- Introduction to RoutineControl (0x31) Service
- Features of RoutineControl (0x31) Service in UDS Protocol
- Sub-Function Parameters of RoutineControl (0x31) Service
- Supported NRC in RoutineControl (0x31) Service of UDS Protocol
- RoutineControl (0x31) Service Request Message Frame Format
- RoutineControl (0x31) Service Positive Response Message Frame Format
- RoutineControl (0x31) Service Negative Response Message Frame Format
- How does Routine Control (0x31) Service works in UDS Protocol?
- Example of RoutineControl (0x31) Service Message in UDS Protocol
- Future Development and Enhancement of RoutineControl (0x31) Service in UDS Protocol
- Related Links of RoutineControl (0x31) Service Tutorial
Introduction to RoutineControl (0x31) Service
The RoutineControl (0x31) Service is one of the diagnostic services defined by the ISO 14229-1 standard. It allows the tester to start, stop or request the results of a routine executed by the server (Ex:- ECU). A routine is a set of operations or tests that can be performed on the ECU to check its functionality, calibration or configuration.
This routine can be identified by an unique Routine Identifier. This Routine Identifier details can be found in our article in this link: RoutineIdentifier.
Features of RoutineControl (0x31) Service in UDS Protocol
The RoutineControl service is useful for performing various diagnostic tasks on the ECU, such as:
- Erasing fault memory.
- Programming or reprogramming ECU memory.
- Testing or checking of RAM or ROM memory.
- Testing ECU inputs or outputs.
- Checking ECU calibration or configuration.
- Performing self-tests or functional tests.
- Activating or deactivating certain functions or features of the ECU.
- Reading or writing calibration or configuration data from or to the ECU.
Sub-Function Parameters of RoutineControl (0x31) Service
The RoutineControl (0x31) service in UDS protocol allows the tester to start, stop or request the results of a routine on an ECU. A routine is a set of operations or tests that are performed by the ECU and can be used for diagnostic purposes, such as checking the integrity of memory or sensors, or for calibration or configuration tasks.
The RoutineControl service has three sub-functions: StartRoutine (0x01), StopRoutine (0x02) and RequestRoutineResults (0x03). Each sub-function has its own parameters that specify the routine identifier and the optional data required or returned by the routine.
Parameter Value | Parameter Name | Parameter Description | Mnemonic |
---|---|---|---|
0x00 | ISOSAEReserved | This document sets aside this value for defining it in the future. | ISOSAERESRVD |
0x01 | startRoutine | This parameter directs the server to begin the process identified by the routineIdentifier. | STR |
0x02 | stopRoutine | This parameter requires the server to end the process denoted by the routineIdentifier. | STPR |
0x03 | requestRoutineResults | This parameter indicates that the server should provide the outcome values for the process identified by the routineIdentifier. | RRR |
0x04 – 0x7F | ISOSAEReserved | This document holds this value for future clarification. | ISOSAERESRVD |
Start Routine (0x01) Sub-Function of RoutineControl (0x31) Service
The RoutineControl service has four sub-functions. Each sub-function has a specific identifier that is sent as the first byte of the service data. The startRoutine sub-function initiates the execution of a routine identified by a routine identifier. The stopRoutine sub-function terminates the execution of a routine identified by a routine identifier. The requestRoutineResults sub-function requests the results of a routine identified by a routine identifier. The requestRoutineResultsPositiveResponse sub-function sends the results of a routine identified by a routine identifier.
Once the StartRoutine request message is completed, the routine will commence in the server’s memory. It will occur sometime before the completion of the first response message, which could be positive or negative. A positive response message would indicate that the request has been executed successfully, while a negative response message would mean that the request is either already in progress or has been completed earlier.
There are two types of routines: one that replaces normal operating code with tests and another that runs concurrently with the normal operating code. In the first scenario, it may be necessary to activate a diagnostic session or unlock the server using the DiagnosticSessionControl or SecurityAccess service, respectively, before utilizing the StartRoutine service.
The StartRoutine sub-function initiates the execution of a routine on the ECU. The parameters of this sub-function are:
- RoutineIdentifier: a two-byte value that uniquely identifies the routine to be started.
- RoutineControlOptionRecord: an optional data record that contains additional information for the routine, such as input values or settings. The format and length of this record depend on the specific routine and are defined by the ECU manufacturer.
Stop Routine (0x02) Sub-Function of RoutineControl (0x31) Service
Once the StopRoutine request message has been completed, the server routine will cease running in the server’s memory. This will happen sometime after the first response message, which can either be positive or negative. A positive response message would indicate that the request to stop the routine has been executed successfully, while a negative response message would imply that the request is already in progress or has been completed previously.
The server routine can be stopped programmatically or as previously initialized in the server’s memory, at any given time.
The StopRoutine sub-function terminates the execution of a routine on the ECU. The parameters of this sub-function are:
- RoutineIdentifier: a two-byte value that uniquely identifies the routine to be stopped.
- RoutineControlOptionRecord: an optional data record that contains additional information for the routine, such as output values or status. The format and length of this record depend on the specific routine and are defined by the ECU manufacturer.
Request Routine Results (0x03) Sub-Function of RoutineControl (0x31) Service
The client employs this sub-function to request results, such as exit status information. These results are identified by a routineIdentifier and were generated by the routine executed in the server’s memory.
If routine results were obtained from the positive response message of the stopRoutine sub-function parameter, such as normal or abnormalExitWithResults, the requestRoutineResults sub-function should be utilized.
A sample of routineResults might be information gathered by the server that couldn’t be sent while the task was running due to the server’s performance restrictions.
The RequestRoutineResults sub-function requests the results of a routine that has been started or stopped on the ECU. The parameters of this sub-function are:
- RoutineIdentifier: a two-byte value that uniquely identifies the routine whose results are requested.
- RoutineStatusRecord: a data record that contains the results of the routine, such as output values, status or error codes. The format and length of this record depend on the specific routine and are defined by the ECU manufacturer.
Supported NRC in RoutineControl (0x31) Service of UDS Protocol
The UDS protocol defines a standard format for the RoutineControl service and its sub-functions, as well as a list of possible negative response codes (NRC) that indicate the reason for a service failure.
The UDS Protocol supported the NRC in RoutineControl service by implementing a function that checks the validity of the request parameters, such as the routine identifier, the routine control type and the routine option record. The function also verifies that the requested routine is supported by the server and that it is in an appropriate state to be executed. If any of these conditions are not met, the function returns an NRC according to the UDS specification. For example, if the routine identifier is unknown, the function returns NRC 0x31 (RequestOutOfRange).
RID_NRC Value | RID_NRC Name | RID_NRC Description | RID_NRC Mnemonic |
---|---|---|---|
0x12 | subFunctionNotSupported | This code appears when the requested sub-function isn’t supported. | SFNS |
0x13 | incorrectMessageLengthOrInvalidFormat | The message’s length is incorrect. | IMLOIF |
0x22 | conditionsNotCorrect | This code is given when the conditions for the RoutineControl request aren’t satisfied. | CNC |
0x24 | requestSequenceError | This code is sent when a “stopRoutine” or “requestRoutineResults” sub-function is received before getting a “startRoutine” for the requested routineIdentifier. | RSE |
0x31 | requestOutOfRange | This code is sent if: 1) the server doesn’t support the requested routineIdentifier; 2) the optional routineControlOptionRecord from the user has invalid data for the requested routineIdentifier. | ROOR |
0x33 | securityAccessDenied | This code is sent when a client sends a request using a valid secure routineIdentifier while the server’s security feature is active. | SAD |
0x72 | generalProgrammingFailure | This code is sent if the server finds an error while doing a task that involves accessing its internal memory. For example, if the task tries to erase or program a specific memory spot in a permanent memory device (like Flash Memory) and the access to that spot fails. | GPF |
RoutineControl (0x31) Service Request Message Frame Format
A_Data byte | Parameter Name | Value | Mnemonics |
---|---|---|---|
#1 | RoutineControl Request Service Id | 0x31 | RC |
#2 | sub-function = [ routineControlType ] | 0x00 – 0xFF | LEV_ RCTP |
#3 #4 | routineIdentifier [] = [ byte#1 (MSB) byte#2 ] | 0x00 – 0xFF 0x00 – 0xFF | RI_B1 RI_B2 |
#5 : #n | routineControlOptionRecord[] = [ routineControlOption#1 : routineControlOption#m ] | 0x00 – 0xFF 0x00 – 0xFF : 0x00 – 0xFF | RCEOR RCO_1 : RCO_m |
RoutineControl (0x31) Service Positive Response Message Frame Format
The RoutineControl service has a positive response message frame format that specifies the following fields:
A_Data byte | Parameter Name | Parameter Vaue | Mnemonic |
---|---|---|---|
#1 | RoutineControl Response Service Id | 0x71 | RCPR |
#2 | routineControlType | 0x00 – 0x7F | RCTP_ |
#3 #4 | routineIdentifier [] = [ byte#1 (MSB) byte#2 ] | 0x00 – 0xFF 0x00 – 0xFF | RID_B1 RID_B2 |
#5 : #n | routineStatusRecord[] = [ routineStatus#1 : routineStatus#m ] | 0x00 – 0xFF : 0x00 – 0xFF | RSR_RS1 : RSR_RSm |
- Service Identifier (SID): This is a single byte that indicates the service type. For RoutineControl, the SID is 0x71.
- Routine Identifier (RID): This is a two-byte field that identifies the routine to be controlled. The RID is assigned by the server and may vary depending on the server configuration.
- Routine Status Record: This is an optional field that contains additional information about the status of the routine. The length and format of this field depend on the RID and the server implementation.
- Routine Control Option Record: This is an optional field that contains additional parameters for the routine control. The length and format of this field depend on the RID and the server implementation.
RoutineControl (0x31) Service Negative Response Message Frame Format
A negative response message is sent by the server when it cannot execute the requested service or routine. The negative response message has a frame format that consists of three bytes: the negative response service identifier (0x7F), the original service identifier (0x31 in this case), and the negative response code (NRC). The NRC indicates the reason why the service or routine could not be performed.
A_Data byte | Parameter name | Parameter Value | Mnemonics |
---|---|---|---|
#1 | RoutineControl Response Service Id | 0x71 | RCPR |
#2 | routineControlType | 0x00 – 0x7F | RCTP |
#3 #4 | routineIdentifier [] = [ byte#1 (MSB) byte#2 ] | 0x00 – 0xFF 0x00 – 0xFF | RID_B1 RID_B2 |
#5 #n | routineStatusRecord[] = [ routineStatus#1 : routineStatus#m ] | 0x00 – 0xFF : 0x00 – 0xFF | RSR_RS1 : RSR_RSm |
How does Routine Control (0x31) Service works in UDS Protocol?
Routine Control (0x31) Service is a powerful and flexible service that allows the tester to control some specific programs defined by the OEM, such as starting, stopping, or requesting the results of a routine. A routine is a set of operations that perform a certain function on the ECU, such as checking the programming conditions, erasing the flash memory, or verifying the data validity. Each routine has a unique identifier (RID) that specifies its function and parameters.

To use Routine Control (0x31) Service, the tester sends a request message with the following format:
//Client --> Server Request for erase memory using the 0xFF00 RID
31 01 02 01
- The first byte is 0x31, which indicates the service identifier.
- The second byte is routineControlType, which indicates the action to be performed on the routine. The possible values are 0x01 (startRoutine), 0x02 (stopRoutine), or 0x03 (requestRoutineResults).
- The third and fourth bytes are routineIdentifier, which indicate the specific routine to be controlled. The RID values are defined by the OEM and may vary depending on the ECU model and software version.
- The optional bytes are routineControlOptionRecord, which indicate additional information or parameters for the routine. The format and meaning of these bytes depend on the specific routine and are also defined by the OEM.
The ECU responds with a positive response message with the following format:
71 01 02 01
- The first byte is 0x71, which indicates a positive response to service 0x31.
- The second byte is routineControlType, which echoes the action requested by the tester.
- The third and fourth bytes are routineIdentifier, which echo the specific routine controlled by the tester.
- The optional bytes are routineStatusRecord, which indicate the status or results of the routine. The format and meaning of these bytes depend on the specific routine and are also defined by the OEM.
Routine Control (0x31) Service is a useful service for performing various functions on the ECU that are not covered by other services. It can also be used for diagnostic purposes, such as checking the ECU’s health or functionality. However, it should be used with caution, as some routines may have side effects or require certain preconditions to be met. The tester should always consult the OEM’s documentation for more details on how to use Routine Control (0x31) Service safely and effectively.
Example of RoutineControl (0x31) Service Message in UDS Protocol
This example explains the requirements for initiating a server routine that will continuously and rapidly check all input and output signals for any interruptions. This is to be done while a technician manipulates the wiring harness connectors of the system being tested. The routine is identified by the hexadecimal identifier 0201, referred to as the routineIdentifier.
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph].
The client wants to receive a response message. They do this by setting the “suppressPosRspMsgIndicationBit” to “FALSE” (0). This bit is located in the 7th position of the subfunction parameter.
Example of RoutineControl (0x31) Service Request Message in UDS Protocol
This example request can be of 3 types for any routine to complete the test from end to end.
Below example shows that how to start a routine for checking this by using the 0x01 sub-function of RoutineControl (0x31) Service.
PCI | RIDSID | RID_SBF | RID_B1 | RID_B2 | NULL | NULL | NULL |
---|---|---|---|---|---|---|---|
0x02 | 0x31 | 0x01 | 0x02 | 0x01 | xx | xx | xx |
Below example shows that how to stop a routine for checking this by using the 0x02 sub-function of RoutineControl (0x31) Service.
PCI | RIDSID | RID_SBF | RID_B1 | RID_B2 | NULL | NULL | NULL |
---|---|---|---|---|---|---|---|
0x02 | 0x31 | 0x02 | 0x02 | 0x01 | xx | xx | xx |
Below example shows that how to get the result of a routine for checking this by using the 0x03 sub-function of RoutineControl (0x31) Service.
PCI | RIDSID | RID_SBF | RID_B1 | RID_B2 | NULL | NULL | NULL |
---|---|---|---|---|---|---|---|
0x02 | 0x31 | 0x03 | 0x02 | 0x01 | xx | xx | xx |
Example of RoutineControl (0x31) Service Positive Response Message
A positive response message for the RoutineControl (0x31) Service would indicate that the requested routine has been successfully executed or that the requested information has been provided. Here is an example of a positive response message for this service:
PCI | RIDSID | RID_SBF | RID_B1 | RID_B2 | NULL | NULL | NULL |
---|---|---|---|---|---|---|---|
0x04 | 0x71 | 0x01 | 0x02 | 0x01 | xx | xx | xx |
PCI | RIDSID | RID_SBF | RID_B1 | RID_B2 | NULL | NULL | NULL |
---|---|---|---|---|---|---|---|
0x04 | 0x71 | 0x02 | 0x02 | 0x01 | xx | xx | xx |
Here’s how to get the results after a routine is done. The routine checks all input and output signals for interruptions as quickly as possible, while a technician moves the wiring harness connectors of the system being tested. The routine can be identified using the identifier 0201 in hexadecimal form. This identifier is referred to as the “routineIdentifier.”
Test conditions: ignition = on, engine = off, vehicle speed = 0 [kph].
PCI | RIDSID | RID_SBF | RID_B1 | RID_B2 | RSR_B1 | RSR_B2 | RSR_B3 |
---|---|---|---|---|---|---|---|
0x07 | 0x71 | 0x03 | 0x02 | 0x01 | 0x57 | 0x33 | 0x8F |
The client wants a response message. They turn it on by setting the “suppressPosRspMsgIndicationBit” to “FALSE” (0). This bit is found in the sub-function parameter, in the 7th position.
Example of RoutineControl (0x31) Service Negative Response Message
A negative response message for the RoutineControl (0x31) Service would indicate that the requested routine has not been executed or that the requested information could not be provided. Here is an example of a negative response message for this service:
PCI | RIDSID | RID_SBF | RID_NRC | NULL | NULL | NULL | NULL |
---|---|---|---|---|---|---|---|
0x03 | 0x7F | 0x31 | 0x12 | xx | xx | xx | xx |
- The message ID (0x7F) indicates that this is a response message. The response type (0x7F) indicates that this is a negative response message.
- The service ID (0x31) specifies that the message is related to the RoutineControl Service.
- The subfunction (0x01) confirms that the requested routine has not been started.
- The error code (0x12) provides specific information about the reason for the failure, in this case “Request Out of Range,” indicating that the request is outside of the acceptable range of values.
Future Development and Enhancement of RoutineControl (0x31) Service in UDS Protocol
The future development and enhancement of the RoutineControl (0x31) Service in the UDS Protocol will likely be driven by the evolving needs of the automotive industry and advancements in technology. Possible improvements could include adding new features and capabilities, as well as enhancing existing ones to make the service more efficient, secure, and capable of handling a higher volume of data transfer.
The focus may also shift towards making the RoutineControl Service more user-friendly and accessible to a wider range of users. Ultimately, the exact direction of future development will depend on the needs of the industry and the advancements in technology.
Related Links of RoutineControl (0x31) Service Tutorial
Discover more from PiEmbSysTech
Subscribe to get the latest posts sent to your email.