UDS Protocol

Introduction to UDS Protocol

The UDS Protocol is the latest automotive vehicle diagnostic protocol used to diagnose any vehicle all over the world. This protocol is defined in ISO-14229 standard so that every automobile OEM will follow this standard to provide a very common computer system that can be used to diagnose any vehicle. But before that, I want to clear your doubt what is the difference between the communication protocol and diagnostic protocol.

The communication protocol is used to communicate between two or more machines or computers. In the automotive field, we are saying it ECU. So here we will be using as ECU so don’t be confused. If you have any health issues as a human you can understand and get cured after taking a solution from a doctor.

UDS Implementation In Automotive ECU

But how a machine can explain what is the problem in its processor or any I/O peripheral, or any short circuit or anything. So to get this feature in a machine we can write some diagnostic programs which can run periodically inside the processor and if there is any fault nothing but the DTC and it can store in the Non-Volatile memory of the processor so that later the human can read this and to repair the vehicle easily.

So to make this possible in ECU, ISO technical Committee and SAE Committee made this standard that having different services and subfunctions to identify and run these services by requesting these service commands from any computer system and get the results. So that the ECUs also can tell the human what is the problem inside it to fix it easily.

ISO-14229 Standards Available

The UDS protocol specification is defined in different sub-standards of ISO 14229. The ISO-14229 Standard UDS Protocol consists of the following parts, under the general title Road vehicles — Unified diagnostic services (UDS):

• ISO 14229-1: Specification and requirements for UDS Protocol.
• ISO 14229-2: Session layer services for UDS Protocol.
• ISO 14229-3: Unified diagnostic services on CAN implementation (UDSonCAN).
• ISO 14229-4: Unified diagnostic services on FlexRay implementation (UDSonFR).
• ISO 14229-5: Unified diagnostic services on Internet Protocol implementation (UDSonIP).
• ISO 14229-6: Unified diagnostic services on K-Line implementation (UDSonK-Line).
• ISO 14229-7: Unified diagnostic services on Local Interconnect Network implementation (UDSonLIN) (Under ongoing research for implementation).
• ISO 14229-8: Unified diagnostic services on UDSon… will be prepared gradually and added here

How UDS Protocol Does diagnostic?

Let me explain to you a story for new engineers to understand. Suppose you are a human and if you have any health issues you are going to the hospital. In the hospital, there are different floors for different diagnostic purposes. As you can say the first floor is for General or emergency purposes, The 2nd floor is for diagnostic centers where each room is for different services like blood, skin, eye, etc. 3rd floor is for Operation Center, the 4th floor is for safety as you can say before happening anything you can take protection from doctor to not happen anything.

The same scenario can also happen in the machine, so resolve this the diagnostic protocol needs. So that any human or another machine can do the diagnostic on another machine using this protocol called as UDS Protocol

What is UDS Protocol?

The UDS protocol is a diagnostic protocol used in Automotive Vehicles to find the cause of a problem for the health check. Basically, it is used in the automotive field for vehicle diagnostic, ECU new software flashing, etc. Nowadays the use of the protocol is increasing due to its flexibility. This protocol is defined in ISO-14229-1 standard and it is derived from the ISO 14230-3 (KWP-2000) and ISO 15765-3 (Diagnostic Communication over the CAN (DoCAN). 

The  UDS protocol services are using the 5th (Session layer) and 7th (Application) layer of the OSI model while the CAN protocol works on the 1st (Physical) and 2nd (Data Link layer) layer of the OSI model. Basically, the UDS protocol is working on the CAN protocol for the communication between the client by request and server by a response to do the diagnostic on the server by request and which we are telling as Diagnostic over CAN (DoCAN).

Why Diagnostic need in a vehicle?

When any problem is happening with a human and he is going to the hospital to do the diagnostic and getting a solution, like this for a vehicle also it needs to be diagnostic as to inform the human about his problem such as:

1. We may wish to see data stored within the system – such as Trouble codes – or some form of the identifications.
2. We may wish to see live data – such as the engine or vehicle speed.
3. We may want to transfer a large amount of data – for example re-flashing a module (ECU).
4. We may wish to take direct control of module I/O – for an example disabling individual cylinders to identify the fault.
5. We may wish to run specific routines already in a module – such as some form of self-calibration.
6. We may wish to apply security locks to certain services or to allow the normal function of a system to be disturbed to vary degrees.

UDS Protocol Physical and Functional Addressing:

There is a possibility for the diagnostic tester (client) to send physical or functional UDS requests. A functional request is a broadcast-type message which will be sent to all ECUs which are on the CAN network. The Physical UDS-requests are only sent to a single ECU on the network. Suppose already you know in which module or ECU the faults are happening, then the diagnostic engineer in the service center can directly connect to that ECU to send the diagnostic request (Physical addressing) and read the diagnostic data, and fix the issue.

If the engineer doesn’t know where is the fault happening obviously he will be sending the request (Functional addressing) globally to all the ECU available in the vehicle, read all the active DTC, and fix it. The UDS Protocol uses both the addressing method to give a spontaneous interface to the tester for easy diagnostic.

Session Layer Timings In The UDS-standard:

Contained within the UDS standard there is a standard governing the session layer services in the Open Systems Interconnection (OSI)-model called ISO 14229-2 nothing but UDS Protocol. The most important session layer timings in this project are the P2 and P2 extended timings that specify the maximum time the server (ECU) or client (tester) has to wait or respond to the UDS request.

These values are communicated by the ECU through the UDS-response to the Diagnostic Session Control service. The P2 specifies the default timing which should be used, the ECU has, however, the option to send an NRC 0x78, then the P2 extended timing value will be maximum time, which is the server (ECU) has to respond?

UDS Protocol Frame Format

Since the UDS protocol is working on the CAN protocol so that the maximum 8-bytes of the data can be requested and get to the response in a message. Like CAN protocol, in UDS protocol, there are 2-types of frames are available. The UDS protocol frame format is defined below.

1. Diagnostic request Frame (With/without Sub-function-ID).
2. Diagnostic Response Frame.

Again the Response frame is divided into two types:

• Positive Response.
• Negative Response.

UDS Protocol Request Frame Format:

Whenever the client wants to request anything from the data then the tester will send this request the frame to get the response from the server on the CAN data field. This frame had consisted of 3 fields:

• Service ID.
• Sub-Function ID  (optional: not exist for some diag. services).
• Data bytes.

NOTE: D1=BIT7(POSRESPONSEINDICATIONBIT) +SUB-FUNCTION ID(BIT0…BIT6)

• if Bit7=True; Then No response is required.
• if Bit7=False; Then the response required.

SID	SBF	Data Bytes
0x10	0x01	xx

UDS Protocol Response Frame Format:

Whenever a diagnostic engineer or tester will request any service to a vehicle, there is a possibility of two types of response from the vehicle or a particular ECU as per physical or functional request type.

Positive Response Frame Format:

Whenever the tester will request to the server if it is correct and the server has been executed the request successfully, then it will send the response message concerning this request by adding 0x40 to the respective service ID for reference. Positive response 1st byte should be Request Service ID + 0x40.

Negative Response Frame Format:

If the client did not request in a proper frame format or the server is not able to execute the request due to the internal problem, then it will send a negative response to the client.

• Negative response 1st byte should be 0x7F.
• Negative response 2nd byte should be Service ID.
• Negative response 3rd byte should be Response Code.

Request Frame (C–>S)	10	01	xx
+Ve Response Frame (S–>C)	50	01	00
-Ve Response Frame (S–>C)	7F	10	NRC

In the above table, I have given a demo request and response message format. Like this, if any diagnostic data is needed the tester can request from his computer to the vehicle or you can say a particular ECU to get the data as a response message. If the request will be received by the ECU or server successfully and executed also with all the preconditions then the ECU or server will send the message with +Ve response frame else it will be a -Ve response message with Negative Response Code (NRC).

Here I will explain only about the UDS frame format, if you are thinking to know more or total frame format like as I told you can not communicate using this protocol for that you need to use any communication protocol like as: CAN, LIN, etc. then you can read my Diagnostic Over CAN (DoCAN) Tutorial.

UDS Protocol Architecture

Those services allow a tester (client) to control diagnostic functions in an on-vehicle Electronic Control Unit (server) applied for example on the electronic fuel injection, automatic gearbox, anti-lock braking system, etc., connected on a serial data link embedded in a road vehicle.

Furthermore, this part of the standard specifies generic services that allow the diagnostic tester (client) to store or to resume non-diagnostic message transmission on the data link. However, part 1 of the standard does not specify any implementation requirements. Figure 7 shows a general configuration of the client-server connection within a vehicle network.

For vehicle 3, the servers are directly connected to the diagnostic data link, and vehicle 4 connects its server/gateway directly to the vehicle 3 server/gateway. For vehicle 4, the servers are connected over an internal data link and indirectly connected to the diagnostic data link through the gateways. ISO 14229-1 or UDS Protocol applies to the diagnostic communications over the diagnostic data link; the diagnostic communications over the internal data link may conform to the same or another protocol.

The server, usually a function that is part of the ECU, uses the application layer services to send response data, provided by the requested diagnostic service back to the client. The client is usually referred to as an External Test Equipment when it is off-board but can in some systems, also be an on-board tester. The usage of the application layer services is independent of the client being an off-board or on-board tester. It is a possibility to have more than one client on the same vehicle system.

The most typical network configuration of the client-server communication for the vehicle diagnostics: the client as an Off-board tester. Communication is based on a request-response model. In the context of diagnostics, the following concepts are useful for a better understanding of the semantics handled on the UDS standard environment:

1. Diagnostic Trouble Codes (DTC): The numerical common identifier fault condition identified by the on-board diagnostic system.
2. Diagnostic Data: Data that is located in the memory of an electronic control unit that may be inspected and/or possibly modified by the tester (diagnostic data includes analogue inputs and outputs, digital inputs and outputs, intermediate values and various status information). EXAMPLES: vehicle speed, throttle angle, mirror position, system status, etc.
3. Diagnostic Session: The current model of the server, which affects the level of diagnostic functionality.
4. Diagnostic Routine: The routine that is embedded in an electronic control unit and that may be started by a server upon a request from the client. NOTE: It could either run instead of the normal operating program or run concurrently to the normal operating program. In the first case, the normal operation of the ECU is not possible. In the second case, multiple diagnostic routines may be enabled that run while all other parts of the electronic control unit are functioning normally.
5. Tester: The system that controls functions such as test, inspection, monitoring or diagnosis of an in-vehicle electronic control unit and which may be dedicated to a specific type of operator (e.g. a scan tool dedicated to garage mechanics or a test tool dedicated to the assembly plant agents).

UDS Protocol Stack

As stated before, UDS is independent of lower-layer protocols. therefore, car diagnostics could be executed, for example, by using the Unified Diagnostic Services (UDS) on top at an application layer-level, generic network layer services at an intermediate level and employing the means of the controller area networks (CAN) or another communication bus protocol (like LIN, FlexRay or Ethernet) for the data link and physical layers’ levels, at lower stages.

Such an approach is compliant with the generic OSI model for the networks. Figure 9 shows the hierarchical arrangement of layers for the implementation of diagnostic services over the CAN according to standard ISO-15765-3.

When executing diagnostics over the CAN, the Client (diagnostic tester) initiates a request and waits for confirmation. The server (function in ECU) then receives the indication and sends a response.

Functions of Diagnostic Services In UDS Protocol

Besides specifying services’ primitives and protocols that describe the client-server interaction, UDS also defines within its framework several functional units that comprise several services each, identified with a hexadecimal code. These units are intended for the different individual purposes that support the overall diagnostic function/task. The UDS protocol having different services for the different types of work tasks to do on the server. These are having 6- types as: 

1. Diagnostic and communication management.
2. Data Transmission.
3. Stored Data Transmission.
4. Input/Output Control.
5. Remote activation of routine.
6. Upload/Download.

Each functional group has more than one service ID for different-2 tasks so to get the detail of the above functional group and related services.

Diagnostic and communication management:

There are 10 services are available in this module to control the diagnostic and the communication-related in the ECU.

1. Diagnostic Session Control (0x10)
2. ECU Reset (0x11)
3. Security Access (0x27)
4. Communication Control (0x28)
5. Tester Present (0x3E)
6. Access Timing Parameter (0x83)
7. Secure Data Transmission (0x84)
8. Control DTC setting (0x85)
9. Response To Event (0x86)
10. Link Control (0x87)

Diagnostic Session Control (0x10):

The heart of the UDS Protocol is the Diagnostic session control service. The diagnostic session control is the main door of the diagnostic server in the ECU by which the tester or the diagnostic engineer will enter into the diagnostic lab of the server and be able to take the decision that what is the status of the problem and to which session he has to go to do the session.

Basically, this service is used to enable the different diagnostic sessions in the server to work on it. In every session, they have defined some diagnostic services which only enable these sessions so that they will work perfectly without any negative impact on the server.

1. If the server is in default session and the client requests to start the default session, then the server shall re-initialize defaultSession completely.
2. If the server is in default session and the client requests to start a non-default session (extendedDiagnosticSession or programming session), then the server shall only reset the events that have been configured in the server via the ResponseOnEvent services before a transition to another session.
3. When the server transitions from a non-default session to the default session, then the server shall reset each event that has been configured in the server via the ResponseOnEvent service and security shall be enabled. Any configured periodic scheduler shall be disabled and communication control and ControlDTCSetting services shall be reset to default state. The server shall reset all activated/initiated/changed settings/controls during the activated session.
4. If the server is in a non-default Session and the client requests to start the same or another non-default Session, then the server shall (re-) initialize the non-default Session. Reset of events that have been configured in the server via the ResponseOnEvent service and enable Security shall be performed.

SBF ID	SBF NAME	Description
0x01	Default Session	After power on, ECU will stay in this session
0x02	Programming Session	ECU boot mode for new software flashing
0x03	Extended Diagnostic Session	A real diagnostic session where most of the diagnostic works done
0x04	System Safety Diagnostic Session	Used to test all the safety related ECUs. Ex: Airbag
0x05 – 0x3F	ISO SAE reserved	SAE team can define any extra diagnostic sessions under these SBF ID
0x40 – 0x5F	Vehicle Manufacturer Specific	Each OEM can define any extra diagnostic sessions under these SBF ID. Ex: Volvo, Audi, etc.
0x60 – 0x7E	System Supplier Specific	Any supplier can define any extra diagnostic sessions under these SBF ID. Ex: Robert BOSCH
0x7F	ISO SAE Reserved	It is still reserved for the future, still, it is not used for any feature

Basically, most of the OEMs are using 3-4 Sub-functions which are really important and we are also going to discuss only those here. mostly if you have any other doubt or any query please search to get in my blog post and Q&A forum page even if you can also write to us at piembsystech@gmail.com

1. Default Session (0x01).
2. Programming Session (0x02).
3. Extended Diagnostic Session (0x03).
4. System Safety Diagnostic Session (0x04).

Default Session (0x01)

Whenever any ECU will get powered on, the ECU will be activated with the default diagnostic session. In this session, only some basic diagnostic functionalities will have access that can be executed at the run time means if the vehicle is running you can do these tasks without any hamper or disturbance of the run time vehicle. Let’s go discuss the request and response frame format details as to how it is really working or implemented by a developer.

PCI	SID	SBF	DB4	DB3	DB2	DB1	DB0
02	10	01	00	00	00	00	00

Here I will explain the byte from left to right for better understanding, so please don’t make confusion yourself.

Where 1st byte is: 02–> PCI (Protocol Control Information) byte for CAN-TP.

The MSB 4-bit –> 0x0 –> CAN-TP frame type & 0x2 –> LSB 4-bit –> DLC.

2nd byte: SID –> 0x10

3rd byte: Sub-function –> 01.

Since for this request, 2-byte is sufficient, and 1-byte is used for PCI, except 3-byte others are not required.

NOTE: If you are not understanding what is PCI and CAN-TP please search in my main menu for CAN-TP, first learn the CAN-TP protocol and then come to this page for UDS protocol. Normally before learning this protocol, first you need to know the CAN protocol and CAN-TP protocol. If any doubt then you can comment in the comment below, else can send me the mail at piembsystech@gmail.com.

UDS Response: Server –>Client:

Positive Response:

06

50

01

00

19

07

D0

00

Byte [1]: 06 –> PCI (Protocol Control Information) byte for CAN-TP.

The MSB 4-bit –> 0x0 –> CAN-TP frame type & 0x6 –> LSB 4-bit –> DLC.

Byte [2]: SID –> 0x50 (Positive response = Request SID + 0x40).

Byte [3]: SFID –> 0X01.

Byte [4-5]: P2 Server timing parameter (0x19 –> 25 ms in decimal).

Byte [6-7]: P2* Server timing parameter (0x7D0 –> 2 second in decimal).

Negative Response:

03

7F

10

12/13/22

00

00

00

00

Where 1st byte is: 04 –> PCI (Protocol Control Information) byte for CAN-TP.

The MSB 4-bit –> 0x0 –> CAN-TP frame type & 0x4 –> LSB 4-bit –> DLC.

2nd byte: -Ve Response SID –> 0x7F.

3rd byte: 0x10 –> SID.

4th byte: 0x1 –> SFID.

5th byte: 0x12/13/22 –> -Ve response ID.

Diagnostic Session Control Request message layout:

Data byte	Parameter name	Hex value
0	PCI	0x01
1	Diagnostic Session Request Service ID	0x10
2	Diagnostic Session Type	0x01-0x05

Example: Request Programming Session:

Byte	0	1	2	3	4	5	6	7
Value	0x01	0x10	0x02	0x55	0x55	0x55	0x55	0x55

NOTE: All the negative response ID is defined below.

ECU Reset Service Identifier (0x11)

The objective of this service is to reset the particular target ECU or all the ECU nothing but the vehicle. There are different types of reset available or defined in the UDS Protocol standard document, Such as hard reset, soft reset, key off-on reset, etc for reset of any ECU. Each reset type has its own functionality for how to reset and what needs to be reset. To know more and deep about this service please select or click the above link to read the ECU Reset Service ID

Security Access (27X)

This service Identifier is used to unlock an ECU in a vehicle. To learn about security access I have written a separate tutorial for this. If you want to know more about it you can follow this link as Security Access SID

(4) Communication Control Setting: UDS Protocol

This service is used to control the communication with the server i.e enable or disable transmission and reception of messages from the server.

Sub-Function:

SBF-ID	SBF Name
0x00	Enable Rx & Tx
0x01	Enable Rx & Disable Tx
0x02	Disable Rx & Enable Tx
0x03	Disable Rx & Tx

Example:

Request: Client–>Server: 03 28 00 03
Where, 03 –> PCI (0–> Single Frame & 3–> TP Data Length)
28 –> SID
00–> SBF (Enable Rx & Tx)
03–> Communication Type as both (Normal & Diagnostic)
+Ve Response: 02 68 00
Where, 02 –> PCI (0–> Single Frame & 3–> TP Data Length)
0x68 –> +Ve response ID (0X28 + 0X40)
0X00 –> SBF

(5) TesterPresent (3E hex): UDS Protocol

The purpose of this service is that the Indication to a server (or servers) that a client is still connected to the vehicle and that certain diagnostic services and/or communications that have been previously activated are to remain active. To keep one or multiple servers in a diagnostic session other than the default Session. ServicesKeeps communication alive: avoid communication timeout. There is no Subfunction parameter like other services.

Example:

Request: Client–>Server: 02 3E 00
+Ve Response: Server–>Client: 02 7E 00

(6) Access Timing Parameter (0x83): UDS Protocol

This service is used to read and change the default timing parameters of a communication link for the duration of this communication link. By using this service the Timeout values and message separation time can be read /written.

SBF-ID	SBF Name
0x01	readExtendedTimingParameterSet.
0x02	setTimingParametersToDefaultValues.
0x03	readCurrentlyActiveTimingParameters.
0x04	setTimingParametersToGivenValues.

(7) Secure Data Transmission (0x84): UDS Protocol

The purpose of this service is to transmit data that is protected against attacks from third parties, which could endanger data security, according to ISO 15764. This service is applicable if a client-server intends to use diagnostic services defined in a secured mode. A secured mode in this context means that the data transmitted is protected by cryptographic methods. Security Sub Layer of the transmitter encodes the encapsulated service. Security Sub Layer of the receiver decodes the encapsulated service.

(8) Control DTC setting (0x85): UDS Protocol

The ControlDTCSetting service shall be used by a client to stop or resume the setting of diagnostic trouble codes (DTCs) in the ECU. It is used to Activate / Deactivate storing of errors into error memory. Mostly, it is used during flash programming and development.

SBF-ID	SBF Name
0x01	DTC On
0x02	DTC Off

Example:

Client –> Server (Request Message)
02 85 01
Where,02 –> PCI [0–> Single Frame & 2–> CAN_TP Length]
85 –> SID
01 –> SBF [DTC Control setting ON]
Server –> Client (+Ve Response)
02 C5 01
02 –> PCI [0–> Single Frame & 2–> CAN_TP Length]
C5 –> +Ve Response SID
01 –> +Ve response acceptance SBF

(9) Response On Event (0x86): UDS Protocol

The ResponseOnEvent service requests a server to start or stop the transmission of responses on a specified event. This service provides the possibility of automatically executing a diagnostic service if a specified event occurs in the server. The client specifies the event (including optional event parameters) and the service (including service parameters) to be executed if the event occurs. See Figure 12 for a brief overview of client and server behavior. Using this service you can Configure the ECU to send a response without a request in case of a defined event.

Sub-Functions:

SBF-ID	SBF Name
0x00	stopResponseOnEvent
0x01	onDTCStatusChange
0x02	onTimerInterrupt
0x03	onChangeOfDataIdentifier
0x04	reportActivatedEvents
0x05	startResponseOnEvent
0x06	clearResponseOnEvent
0x07	onComparisonOfValues

(10) Link Control (0x87): UDS Protocol

This service is used to control the communication link baud rate between the Tester and the ECU(s) for the exchange of diagnostic data. This service optionally applies to those data link layers which allow for a baud rate transition during an active diagnostic session.

Sub-Functions:

SBF-ID	SBF Name
0x1	verifyBaudrateTransitionWithFixedBaudrate
0x2	verifyBaudrateTransitionWithSpecificBaudrate
0x3	transitionBaudrate

The baudrateIdentifier value determines the Baudrate. For example, 11 – CAN 250 KBPS, 12 – CAN500KBPS, 13 – CAN 1 Mbps

Data transmission functional unit: UDS Protocol

These Services are used to read or write the data to/from the server for the different functional requirements.

Read Data By Identifier (22 hex): UDS Protocol

The ReadDataByIdentifier service allows the client to request data record values from the server identified by one or more data identifiers. The ECU may limit the number of data identifiers that can be read in one request. DataIdentifier – Identifies the ECU data record(s) that are being requested by the ECU.

For Example:

• F180 – bootSoftwareIdentificationDataIdentifier.
• F181- applicationSoftwareIdentificationDataIdentifier.
• F191 – vehicleManufacturerECUHardwareNumberDataIdentifier.

WriteDataByIdentifier (2E hex): UDS Protocol

This service allows the client/Tester to write information into the server/ECU at an internal location specified by the provided data identifier. The WriteDataByIdentifier service is used by the client to write a data Record to a server. The data is identified by a data identifier and may or may not be secured.

Dynamically defined data identifier(s) shall not be used with this service. It is the vehicle manufacturer’s responsibility that the server conditions are met when performing this service. Possible uses for this service are:

–> programming configuration information into the server (e.g. VIN);
–> clearing non-volatile memory;
–> resetting learned values.
–> setting option content.

ReadMemoryByAddress (0x23): UDS Protocol

The ReadMemoryByAddress service allows the client to request memory data from the server via a provided starting address and to specify the size of memory to be read.

The ReadMemoryByAddress request message is used to request memory data from the server identified by the parameter memory address and memory size. The number of bytes used for the memory address and memory size parameter is defined by addressAndLengthFormatIdentifier (low and high nibble). It is also possible to use a fixed addressAndLengthFormatIdentifier and unused bytes within the memory address or memory size parameter are padded with the value 00 hex in the higher range address locations.

WriteMemoryByAddress (0x3D): UDS Protocol

This service allows the client/Tester to write information into the server/ECU at one or more contiguous memory locations. The tester sends a memory address, and the number of bytes, and a data string (according to the number of bytes ). The ECU writes the data string into its memory. The addressAndLengthFormatIdentifier parameter in the request specifies The number of bytes used for the memory address and memory size parameter.

ReadScalingDataByIdentifier (24 hex): UDS Protocol

This service is used to read the scaling information of a record identified by a provided data identifier from the ECU. The client request message contains one data identifier value that identifies data record(s) maintained by the server. The format and definition of the data record shall be vehicle-manufacturer-specific and may include analog input and output signals, digital input and output signals, internal data, and system status information if supported by the server.

ReadDataByPeriodicIdentifier (2A hex): UDS Protocol

The UDS Protocol is used to read the periodic data identifier from the server by using a 0x21 service Identifier. This service allows the client to request the periodic transmission of data record values from the server identified by one or more periodicDataIdentifiers.The client request message contains one or more 1-byte periodicDataIdentifier values that identify data record(s) maintained by the server. The periodicDataIdentifier represents the low byte of a data identifier out of the data identifier range reserved for this service (F2xx hex, refer to C.1 for allowed periodicDataIdentifier values), e.g. the periodicDataIdentifier E3 hex used in this service is the data identifier F2E3 hex. The transmission mode is also specified in the request. For Ex :sendAtSlowRate, sendAtMediumRate, sendAtFastRate, stop sending and the values for above is manufacturer specific.

Dynamically Define Data Identifier (2C hex): UDS Protocol

The purpose of this service is to provide the client with the ability to group one or more data elements into a data superset that can be requested en masse via the ReadDataByIdentifier or ReadDataByPeriodicIdentifier service. The data elements to be grouped can be referenced by either. This provides the client with the ability to group one or more data elements into a data superset that can be requested. The data elements to be grouped can be reference by:

• a source data identifier, a position and size, or
• a memory address and a memory length, or
• a combination of the two methods.

Stored Data Transmission Functional Unit: UDS Protocol

ReadDTCInformation (19 hex): UDS Protocol

The 0x19 service is the heart of ISO 14229 standard UDS Protocol. The main intent of this service is to read the Diagnostic Trouble Codes from the server or ECU. It has multiple sub-functions by which you can read different data required for diagnostic analysis. You can follow this link to read more on the Read DTC Information (0x19) Service Identifier.

Clear Diagnostic Information (14 hex): UDS Protocol

Input-Output control functional unit: UDS Protocol

Input-Output Control By Identifier (2F hex): UDS Protocol

Remote activation of routine functional unit: UDS Protocol

Routine Control (31 hex): UDS Protocol

The Vehicle Diagnostics may require testing the faulty component in a given range of parameters. Moreover, during the vehicle testing phase, some system tests may be required to run over a period of time. to perform a test, a routine is triggered by the client, or to put it in another word, and a routine is started by the client in the server’s memory. There are two methods in this remote request service of UDS Protocol, one is where the client interrupts the routine to stop it, and the other is when the server/ECU finishes the routine after a specified time frame. Using this service, the client can start a routine, stop a routine, and check the result of the routine produced after a successful execution.

One of the Routine Control services defined in the UDS standard is the Erase Memory or Erase Flash routine. It will perform the erasure of EEPROM and flash memory before loading a new block. It has the routine identifier FF01, specified on bytes #3-4 in the UDS request. The remaining bytes of the request contain a routine control option record which is of variable length depending on vehicle manufacturing specification and which routine identifier is used. An example of a start Erase Flash Routine Control service.

Let me explain actually why we need this routine control service. the service diagnostic engineer in the garage may use this service to run the engine fan for a certain period of time and record the results. This would help him understand a particular issue well and rectify it without using any hit and trial method.

Requests: RoutineControlType:

1. startRoutine (01 hex).
2. stopRoutine (02 hex).
3. reqestRoutineControl (03 hex).

RoutineIdentifier: This parameter identifies a server’s local routine.

Routine Control Request message layout:

Data byte	Parameter name	Hex value
0	PCI	0x01
1	Routine Control SID	0x31
2	routine identifier	0x00-0xFF
3	routineControlType	0x01-0x03

Example:

A typical Erase Flash Routine Control UDS request. This request aims to start an erasure of an EEPROM or flash memory sector before downloading block 0x15.

Value	1	2	3	4	5	6	7	8
Byte	0x31	0x01	0xFF	0x00	0x01	0x15	–	–

Responses:

Positive response codes:

• routineControlType:This parameter is an echo of bits 6 – 0 of the sub-function parameter from the request message.
• routineIdentifier: This parameter is an echo of the routineIdentifier from the request message.

Negative response codes: 

• Sub Function Not Supported (12 hex): This code is returned if the requested sub-function is not supported.
• Incorrect Message Length Or Invalid Format (13 hex): The length of the message is wrong.
• Conditions Not Correct (22 hex): This code shall be returned if the criteria for the request RoutineControlare not met.
• Request Sequence Error (24 hex): This code shall be returned if the “stop routine” subfunction is received without first receiving a “start routine” for the requested routine identifier.
• Request Out Of Range (31 hex): This code shall be returned if the server does not support the requestedroutineIdentifier.
• Security Access Denied (33 hex): This code shall be sent if this code is returned if a client sends a request with a valid secure routine identifier and the server’s security feature is currently active.
• General Programming Failure (72 hex): This return code shall be sent if the server detects an error when performing a routine, which accesses server-internal memory. An example is when the routine erases or programmes a certain memory location in the permanent memory device (e.g. Flash Memory) and the access to that memory location fails.

Upload download functional unit: UDS Protocol

Request Download (34 hex): UDS Protocol

The request download service is called when data is to be transferred to the ECU. The request shall contain the size of the data to be transferred and the address to where it shall be placed. The ECU responds with the size of its buffer so that the sender can divide the data into appropriate-sized blocks and send them one at a time.

Requests: Four different request parameters can be included in the request.

1. Request Download Service Identifier: This parameter is the Service ID for any kind of download request.
2. DataFormatIdentifier: This data parameter is a one-byte value with each nibble encoded separately. The high nibble specifies the “compression Method” and the low nibble specifies the “encrypting Method”. The value 0x00 specifies that no compression Method or encrypting Method is used.
3. AddressAndLengthFormatIdentifier:
   • bit 7 – 4: Length (number of bytes) of the memory size parameter.
   • bit 3 – 0: Lenght (number of bytes) of the memory address parameter.
4. Memory Address: The parameter memory Address is the starting address of the server memory to which the data is to be written.
5.  memory Size (unCompressedMemorySize): This parameter shall be used by the server to compare the uncompressed memory size with the total amount of data transferred during the TransferData service.

Request Download Request message Format:

Data byte	Parameter name	Hex value
0	PCI	0x01
1	Request Download SID	0x34
2	data format identifier	0x00 – 0xFF
3	addressAndLengthFormatIdentifier	0x00 – 0xFF
4…n	memoryAddress	0x00-0xFF
n…m	memory Size	0x00-0xFF

Responses:

Positive response codes:

• Length Format Identifier:
  1. bit 7 – 4: length (number of bytes) of the maxNumberOfBlockLength parameter.
  2. bit 3 – 0: reserved by document, to be set to 0 hex.

Max Number Of Block Length: This parameter is used by the request download positive response message to inform the client how many data bytes (maxNumberOfBlockLength) shall be included in each TransferData request message from the client. This length reflects the complete message length, including the service identifier and the data parameters present in the TransferData request message. This parameter allows the client to adapt to the receive buffer size of the server before it starts transferring data to the server.

Request Download Response message LayOut:

Data byte	Parameter name	Hex value
0	PCI	0x01
1	Request Download RSID	0x74
2	lengthFormatIdentifier	0x00-0xFF
3	maxNumberOfBlockLength	0x00-0xFF

Example:

Client –> Server (Request)
34 00 45 01 00 04 00 00 00 09 93 78
Server –> Client (+Ve Response)
74 20 0F FA
Server –> Client (-Ve Response)
7F 74 13/22/31

The Request Download Service (0x34) Full tutorial is available in our new article. If you are interested to learn please click this RequestDownloadService(0x34) Tutorial.

Negative response codes:

• Incorrect Message Length Or Invalid Format (13 hex): The length of the message is wrong.
• Conditions Not Correct (22 hex): This return code shall be sent if a server receives a request for this service while in the process of receiving a download of a software or calibration module. This could occur if there is a data size mismatch between the server and the client during the download of a module.
• Request Out Of Range (31 hex): This return code shall be sent if:
  1. the specified data Format Identifier is not valid,
  2. the specified addressAndLengthFormatIdentifier is not valid, or
  3. the specified memory Address/memory Size is not valid.
• SecurityAccessDenied (33 hex): This return code shall be sent if the server is secure (for servers that support the SecurityAccess service) when a request for this service has been received.
• UploadDownloadNotAccepted (70 hex): This response code indicates that an attempt to download to a server’s memory cannot be accomplished due to fault conditions.

Request Upload (35 hex): UDS Protocol

The client requests the negotiation of a data transfer from the server to the client. This service is just the reverse of the 0x34 SID. Suppose you have downloaded some software or DID’s or PID’s, after some time it gets crashed, to check the original file what you downloaded and now either it crashed or not you can upload to your computer and compare also.

Data Byte	Parameter Name	Hex Value
1	RequestUpload SID	35
2	dataFormatIdentifier	00-FF
3	addressAndLengthFormatIdentifier	00-FF
4	memoryAddress[]=[Byte1(MSB) – Byten()LSB]	00-FF to 00-FF
5	memorySize[]= [Byte1(MSB) – Byten()LSB]	00-FF to 00-FF

Data Format Identifier: This data parameter is a one-byte value with each nibble encoded separately. The high nibble specifies the “compression Method”, and the low nibble specifies the “encrypting Method”. The value 00 hex specifies that no compression Method nor encrypting Method is used. Values other than 00 hex are vehicle manufacturer specific.

AddressAndLengthFormatIdentifier: This parameter is a one-byte value with each nibble encoded separately for identification of address and data in the memory array.

• Bit 7 – 4: length (number of bytes) of the “memory Size” parameter;
• Bit 3 – 0: length (number of bytes) of the “memory Address” parameter.

Memory Address: The parameter memory Address is the starting address of server memory from which data is to be retrieved. The number of bytes used for this address is defined by the low nibble (bit 3 – 0) of the address Format Identifier. Byte#m in the memory Address parameter is always the least significant byte of the address being referenced in the server. The most significant byte of the address can be used as a memory Identifier.

Memory Size: This parameter shall be used by the server to compare the uncompressed memory size with the total amount of data transferred during the Transfer Data service. This increases programming security. The number of bytes used for this site is defined by the high nibble (bit 7 – 4) of the address And Length Format Identifier.

Example:

Client –> Server (Request)
35 00 45 01 00 04 00 00 00 09 93 78
Server –> Client (Response)

Transfer Data (36 hex): UDS Protocol

The Transfer Data service receives blocks of data and checks so the blocks are received in the right order. If the right block is received, then it is written to the correct memory location and a positive response is sent.

Requests:

BlockSequenceCounter: The blockSequenceCounter parameter value starts at 01 hex with the first TransferData request that follows the RequestDownload (34 hex) service. its value is incremented by 1 for each subsequent TransferData request. At the value of FF hex, the blockSequenceCounter rolls over and starts at 00 hex with the next TransferData request message.

Transfer Data Request message Frame Format:

Data byte	Parameter name	Hex value
0	PCI	0x01/0x10/0x20-0x2F
1	Transfer Data SID	0x36
2	blockSequenceCounter	0x00-0xFF
3..n	data	0x00-0xFF

Responses:

Positive response codes:

• Block Sequence Counter.
• This parameter is an echo of the block Sequence Counter parameter from the request message.

Transfer Data Response message layout:

Data byte	Parameter name	Hex value
0	PCI	0x01/0x10/0x20-0x2F
1	Transfer Data SID	0x76
2	block Sequence Counter	0x00-0xFF

Negative response codes:

• Incorrect Message Length Or Invalid Format (13 hex): The length of the message is wrong (e.g. message length does not meet the requirements of the max Number Of Block Length parameter returned in the positive response to request Download).
• Request Sequence Error (24 hex)

The server shall use this response code:

• If the Request Download service is not active when a request for this service is received.
• If the Request Download service is active, but the server has already received all data as determined by the memory Size parameter in the active Request Download or Request Upload service.

Request Out Of Range (31 hex): This return code shall be sent if the transfer Request Parameter Record contains additional control parameters (e.g. additional address information) and this control information is invalid.

• Transfer Data Suspended (71 hex): This return code shall be sent if-
  1. The response code indicates that a data transfer operation was halted due to a fault.
  2. The download module length does not meet the requirements of the memory Size parameter sent in the request message of the request Download service.
• GeneralProgrammingFailure (72 hex): This return code shall be sent if the server detects an error when erasing or programming a memory location in the permanent memory device (e.g. Flash Memory) during the download of data.
• WrongBlockSequenceCounter (73 hex): This return code shall be sent if the server detects an error in the sequence of the blockSequenceCounter.

The repetition of a Transfer Data request message with a block Sequence Counter equal to the one included in the previous Transfer Data request message shall be accepted by the server.

Request TransferExit (37 hex): UDS Protocol

When the transfer of data is complete a message to the Request Transfer Exit service is sent. If Transfer Data is complete and has received all data a positive response is sent back.

Request:

Request Transfer Exit Request message layout:

Data byte	Parameter name	Hex value
0	PCI	0x01
1	Request Transfer Exit SID	0x37

Response:

Request Transfer Exit Response message layout:

Data byte	Parameter name	Hex value
0	PCI	0x01
1	Request Transfer Exit RSID	0x77

Negative response codes:

• Incorrect Message Length Or Invalid Format (13 hex): The length of the message is wrong.
• Request Sequence Error (24 hex): The server shall use this response code:
  1. The programming process is not completed when a request for this service is received.
  2. The RequestDownload service is not active.

Request File Transfer (38 hex): UDS Protocol

The Request File Transfer service is used to initiate a file data transfer from client to server or server to client by using the download or upload feature. This service is an alternate method of request download and request upload service for better protection and advanced data transfer method.

• AUTOSAR DCM
• Negative Response Codes (NRC): UDS Protocol
• Application Of UDS: ECU Flash Programming
• Request Download (0x34) Service: UDS Protocol
• Request File Transfer (0x38) Service: UDS Protocol