Routine Control (0x31) Service in UDS Protocol

RoutineControl (0x31) Service: UDS Protocol

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:

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 DescriptionMnemonic
0x00ISOSAEReservedThis document sets aside this value for defining it in the future.ISOSAERESRVD
0x01startRoutineThis parameter directs the server to begin the process identified by the routineIdentifier.STR
0x02stopRoutineThis parameter requires the server to end the process denoted by the routineIdentifier.STPR
0x03requestRoutineResultsThis parameter indicates that the server should provide the outcome values for the process identified by the routineIdentifier.RRR
0x04 – 0x7FISOSAEReservedThis document holds this value for future clarification.ISOSAERESRVD
Sub-Function Parameters of RoutineControl (0x31) Service

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 ValueRID_NRC NameRID_NRC DescriptionRID_NRC Mnemonic
0x12subFunctionNotSupportedThis code appears when the requested sub-function isn’t supported.SFNS
0x13incorrectMessageLengthOrInvalidFormatThe message’s length is incorrect.IMLOIF
0x22conditionsNotCorrectThis code is given when the conditions for the RoutineControl request aren’t satisfied.CNC
0x24requestSequenceErrorThis code is sent when a “stopRoutine” or “requestRoutineResults” sub-function is received before getting a “startRoutine” for the requested routineIdentifier.RSE
0x31requestOutOfRangeThis 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
0x33securityAccessDeniedThis code is sent when a client sends a request using a valid secure routineIdentifier while the server’s security feature is active.SAD
0x72generalProgrammingFailureThis 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
Supported NRC in RoutineControl (0x31) Service of UDS Protocol

RoutineControl (0x31) Service Request Message Frame Format

A_Data byteParameter NameValueMnemonics
#1RoutineControl Request Service Id0x31RC
#2sub-function = [ routineControlType ]0x00 – 0xFFLEV_ 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 Request Message Frame Format

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 byteParameter NameParameter VaueMnemonic
#1RoutineControl Response Service Id0x71RCPR
#2routineControlType0x00 – 0x7FRCTP_
#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
RoutineControl (0x31) Service Positive Response Message Frame Format
  • 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 byteParameter nameParameter ValueMnemonics
#1RoutineControl Response Service Id0x71RCPR
#2routineControlType0x00 – 0x7FRCTP
#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
RoutineControl (0x31) Service Negative Response Message Frame Format of UDS Protocol

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.

Routine Control (0x31) Service in UDS Protocol

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.

PCIRIDSIDRID_SBFRID_B1RID_B2NULLNULLNULL
0x020x310x010x020x01xxxxxx
Example of RoutineControl (0x31) Service Request in UDS Protocol

Below example shows that how to stop a routine for checking this by using the 0x02 sub-function of RoutineControl (0x31) Service.

PCIRIDSIDRID_SBFRID_B1RID_B2NULLNULLNULL
0x020x310x020x020x01xxxxxx
Example of RoutineControl (0x31) Service Request in UDS Protocol

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.

PCIRIDSIDRID_SBFRID_B1RID_B2NULLNULLNULL
0x020x310x030x020x01xxxxxx
Example of RoutineControl (0x31) Service Request in UDS Protocol

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:

PCIRIDSIDRID_SBFRID_B1RID_B2NULLNULLNULL
0x040x710x010x020x01xxxxxx
Example of RoutineControl (0x31) Service Request in UDS Protocol
PCIRIDSIDRID_SBFRID_B1RID_B2NULLNULLNULL
0x040x710x020x020x01xxxxxx
Example of RoutineControl (0x31) Service Request in UDS Protocol

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].
PCIRIDSIDRID_SBFRID_B1RID_B2RSR_B1RSR_B2RSR_B3
0x070x710x030x020x010x570x330x8F
Example of RoutineControl (0x31) Service Request in UDS Protocol

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:

PCIRIDSIDRID_SBFRID_NRCNULLNULLNULLNULL
0x030x7F0x310x12xxxxxxxx
Example of RoutineControl (0x31) Service Request in UDS Protocol
  • 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.


Discover more from PiEmbSysTech

Subscribe to get the latest posts sent to your email.

Leave a Reply

Scroll to Top

Discover more from PiEmbSysTech

Subscribe now to keep reading and get access to the full archive.

Continue reading