Introduction to UDS protocol
UDS stands for Unified Diagnostic Services. This protocol is defined in ISO-14229-1 standard. It is an independent protocol that allows an ECU (CAN) to communicate with a diagnostic tool. This makes it possible to communicate with any car brand. Besides UDS, KWP2000 and GMLAN are also protocols which can be used by vehicles. But because they are more outdated than UDS, many manufacturers don’t use them anymore. UDS is more up to date and controlled by ISO. This is why almost every car manufacturer uses it and have stopped using KWP2000 or GMLAN. In the live data log it is possible to read the UDS messages that are being sent to the vehicle and back. To be able to read UDS you have to understand its structure. Each new line in the log, specifically during communication between vehicle and diagnostic tool/script, is a new message. This line always starts with a time stamp of when it was sent. behind this it is stated between which components the message is sent. For example, the sender is displayed first with an arrow pointing to the recipient. These messages are sent between remote and local (diagnostic tool/script). Behind the clarification of which components are involved is the word “DATA” with an arrow shown. This is visable in the example below, the words that are described in this message are surrounded in red. After this arrow the contest of the message is displayed. The first two words in small letters (mod and cmd) and the info behind in parentheses are for the server and internal use. The third word “args” defines the ECU identification. This tells you to which ECU in the CAN-bus the message is being sent. You can find more info about this below. Behind the last word (data) in parentheses, the UDS message is displayed. This message starts with 0x and after this the content of the message is displayed (explained under “message frame format”).
Message frame format
The UDS protocol is a message based protocol to communicate with a vehicles ECU and its on-board diagnostics. Message based protocol means the communication is transfer by messages. At Jifeline we have our own built in-house format of displaying the UDS messages. When the diagnostic tool requests anything, it sends a request message to the vehicle. When received, the vehicle sends a message back with the requested data or confirmation. A message is made out of 8 bytes (sometimes this is exceeded, this is because of the plugins/profiles Jifeline uses). Displayed in hexadecimal format (explained below). These codes can translate to a meaning or definition. There are examples on the bottom on the page.
Request message frame
A request message is a message going from local to remote. It starts with a service identifier (SID). It is the first byte of the message. This is the “ID” of the function group and is so connected with a request. The SID indicates if there is a Sub-function byte. This is the next byte in the message. It depends on the specific SID if it has a Sub-function byte or not. The remainder of the bytes defines the data parameters. The SID’s and sub-functions that are defined by ISO are visible in the scheme below.
Response message frame
A response message is a message going from remote to local. The response format has 2 possibility’s: a positive response and a negative response. The response answers to the last send request.
The first Byte of the positive response is a SID. To indicate the request has been successfully executed it will add 40 to the SID byte (for example: when the request SID byte was 22, the response byte will be 62). This is followed a Sub-function byte, but only if the SID had one. If so, the sub-function will be shown unchanged in the second byte. After that a data response code will be shown, if this was requested. If this wasn’t requested the message will only contain a SID + 40 and Sub-function to indicate the task was successful. Below you can find a scheme with common data response codes.
With a negative response you will see another message. This is when the ECU or OBD could not preform the request or the request message was not a proper format. In this case the response message will start with the byte 7F. The following byte will be the requested SID. The remainder of the bytes will show a Negative response code with details of why the request was not successfully completed.
HEX code
Hexadecimal is a math and computer used numbering system. It expands the common numbering system by adding letters to it. The common numbering system uses 0 to 9 which gives you 10 options per symbol. Hexadecimal replaces 10 to 15 with the letters A to F. This represents a wider numeral system. this means there are now 16 options per symbol. UDS protocol uses bytes of 2 hex numbers. This means the possible spread isn’t 00 to 99 but it is 00 to FF. Giving it 256 possible codes per byte instead of 100.
ASCII
The data you receive from the ECU is written in HEX. Whenever you request data or information like the VIN of the vehicle, the data will response with a HEX code. When you convert this to ASCII, the real VIN will show up (Like in example 2). Converting a HEX line can be done with a converter tool. On the internet you can find these tool by searching for: HEX to ASCII converter. There are also conversion tables available on the internet where you can look thru al the HEX to ASCII characters.
Notice that not everything can be converted. The SID and sub-functions are defined by UDS and have a definition that is separate from HEX. This also goes for the common response codes. Besides that, it isn’t specified what can be converted. For example, when receiving a VIN, you convert it from HEX to ASCII. But when receiving a milage, you convert from HEX to decimals. In most cases you need to convert it to find out if it Is possible. When converted and not human-readable we can assume that the ASCII conversion is not valid for this case (Like: ” % Ö Ý # @). In these cases in can be converted to decimals or it is a UDS/manufacturer defined code.
ECU identification
In the message, the word args is displayed before data. This indicates to which ECU or server within the vehicle the message is being send. Each ECU has its own request and response address. So is there an engine control module, gateway module or a Milage Recalibration. The identification isn’t specified. This means manufacturers all use other identifier adresses. For example, when displayed: args[0x07E0,0x00,0x00,0x00], the first code indicates the ECU. In this case: 0x07E0. For multiple manufacturers this is the ECM (engine control module). This means the request will be sent to the ECM.
SID identification
In this window are all the ISO defined SID visible. When the SID isn’t specified in this window it is bonded to a manufacturer.
|
Functional unit |
Request SID |
Response SID |
Service name |
Has |
|
Diagnostic and Communications Management |
0x10 |
0x50 |
Diagnostic Session Control |
YES |
|
0x11 |
0x51 |
ECU Reset |
YES |
|
|
0x27 |
0x67 |
SecurityAccess |
YES |
|
|
0x28 |
0x68 |
Communication Control |
YES |
|
|
0x3E |
0x7E |
Tester Present |
YES |
|
|
0x83 |
0xC3 |
Access Timing Parameters |
YES |
|
|
0x84 |
0xC4 |
Secured Data Transmission |
NO |
|
|
0x85 |
0xC5 |
Control DTC Settings |
YES |
|
|
0x86 |
0xC6 |
Response On Event |
YES |
|
|
0x87 |
0xC7 |
Link Control |
YES |
|
|
Data Transmission |
0x22 |
0x62 |
Read Data By Identifier |
NO |
|
0x23 |
0x63 |
Read Memory By Address |
NO |
|
|
0x24 |
0x64 |
Read Scaling Data By Identifier |
NO |
|
|
0x2A |
0x6A |
Read Data By Identifier Periodic |
NO |
|
|
0x2C |
0x6C |
Dynamically Define Data Identifier |
YES |
|
|
0x2E |
0x6E |
Write Data By Identifier |
NO |
|
|
0x3D |
0x7D |
Write Memory By Address |
NO |
|
|
Stored Data Transmission |
0x14 |
0x54 |
Clear Diagnostic Information |
NO |
|
0x19 |
0x59 |
Read DTC Information |
YES |
|
|
Input / Output Control |
0x2F |
0x6F |
Input Output Control By Identifier |
NO |
|
Remote Activation of Routine |
0x31 |
0x71 |
Routine Control |
YES |
|
Upload / Download |
0x34 |
0x74 |
Request Download |
NO |
|
0x35 |
0x75 |
Request Upload |
NO |
|
|
0x36 |
0x76 |
Transfer Data |
NO |
|
|
0x37 |
0x77 |
Request Transfer Exit |
NO |
|
|
Negative response |
|
0x7F |
Negative Response |
NO |
Sub-functions
In this window are all the sub-functions visible that are connected to a SID above. When the sub-function isn’t specified in this window it is bonded to a manufacturer.
|
Request SID |
Sub-function ID |
Sub-function name |
|
0x10 |
0x01 |
Default session |
|
0x02 |
Programming session |
|
|
0x03 |
Extended diagnostic session |
|
|
0x04 |
system safety diagnostic session |
|
|
0x11 |
0x01 |
Hard reset |
|
0x02 |
Key Off On Reset |
|
|
0x03 |
Soft Reset |
|
|
0x04 |
Enable Rapid Power ShutDown |
|
|
0x05 |
Disable Rapid Power ShutDown |
|
|
0x27 |
0x01-41, all odd nr inbetween |
Request Seed |
|
0x02-42, all even nr inbetween |
Send Key |
|
|
0x5F |
Request Seed value |
|
|
0x44-60 |
Send Key value |
|
|
0x28 |
0x00 |
Enable Rx & Tx |
|
0x01 |
Enable Rx & disable Tx |
|
|
0x02 |
Enable Tx & disable Rx |
|
|
0x03 |
Disable Rx & Tx |
|
|
0x3E |
0x00 |
zero SubFunction |
|
0x80 |
zero SubFunction with no response message |
|
|
0x83 |
0x01 |
readExtendedTimingParameterSet |
|
0x02 |
setTimingParametersToDefaultValues |
|
|
0x03 |
readCurrentlyActiveTimingParameters |
|
|
0x04 |
setTimingParametersToGivenValues |
|
|
0x85 |
0x01 |
DTC On |
|
0x02 |
DTC Off |
|
|
0x86 |
0x00 |
stopResponseOnEvent |
|
0x01 |
onDTCStatusChange |
|
|
0x02 |
onTimerInterrupt |
|
|
0x03 |
onChangeOfDataIdentifier |
|
|
0x04 |
reportActivatedEvents |
|
|
0x05 |
startResponseOnEvent |
|
|
0x06 |
clearResponseOnEvent |
|
|
0x07 |
onComparisonOfValues |
|
|
0x87 |
0x01 |
verifyBaudrateTransitionWithFixedBaudrate |
|
0x02 |
verifyBaudrateTransitionWithSpecificBaudrate |
|
|
0x03 |
transitionBaudrate |
|
|
0x2C |
0x01 |
defineByIdentifier |
|
0x02 |
defineByMemoryAddress |
|
|
0x03 |
clearDynamicallyDefinedDataIdentifier |
|
|
0x19 |
0x01 |
reportNumberOfDTCByStatusMask |
|
0x02 |
reportDTCByStatusMask |
|
|
0x03 |
reportDTCSnapshotIdentification |
|
|
0x04 |
reportDTCSnapshotRecordByDTCNumber |
|
|
0x05 |
reportDTCSnapshotRecordByRecordNumber |
|
|
0x06 |
reportDTCExtendedDataRecordByDTCNumber |
|
|
0x07 |
reportNumberOfDTCBySeverityMaskRecord |
|
|
0x08 |
reportDTCBySeverityMaskRecord |
|
|
0x09 |
reportSeverityInformationOfDTC |
|
|
0x0A |
reportSupportedDTC |
|
|
0x0B |
reportFirstTestFailedDTC |
|
|
0x0C |
reportFirstConfirmedDTC |
|
|
0x0D |
reportMostRecentTestFailedDTC |
|
|
0x0E |
reportMostRecentConfirmedDTC |
|
|
0x0F |
reportMirrorMemoryDTCByStatusMask |
|
|
0x10 |
reportMirrorMemoryDTCExtendedDataRecordByDTCNumber |
|
|
0x11 |
reportNumberOfMirrorMemoryDTCByStatusMask |
|
|
0x12 |
reportNumberOfEmissionsRelatedOBDDTCByStatusMask |
|
|
0x13 |
reportEmissionsRelatedOBDDTCByStatusMask |
|
|
0x14 |
reportDTCFaultDetectionCounter |
|
|
0x15 |
reportDTCWithPermanentStatus |
|
|
0x31 |
0x01 |
Start Routine |
|
0x02 |
Stop Routine |
|
|
0x03 |
Request Routine Result |
Function description
Here you can find a description for all the SID's and Sub-functions.
|
Request SID |
Sub-function ID |
Discription |
|
0x10 |
0x01 |
Original session, when there is no other session requested, ECU will be in this one |
|
0x02 |
This diagnosticSession enables all diagnostic services required to support the memory programming of an ECU |
|
|
0x03 |
This opens a session where you can adjust functions in the memory of the ECU |
|
|
0x04 |
This diagnosticSession enables all diagnostic services required to support safety-system-related functions |
|
|
0x11 |
0x01 |
This simulates the power-on/start-up sequence typically performed after a ECU has been previously disconnected from its power supply |
|
0x02 |
This is similar to the driver turning the ignition key off and back on. |
|
|
0x03 |
This causes the ECU to immediately restart the application program if applicable. |
|
|
0x04 |
This requests the ECU to enable and perform a “rapid power shut down” function. (stand by mode) |
|
|
0x05 |
This requests the ECU to disable and perform a “rapid power shut down” function. (stand by mode) |
|
|
0x27 |
0x01-41, all odd nr inbetween |
RequestSeed with different levels of security defined by the vehicle manufacturer. request the ECU to “unlock” by sending the service SecurityAccess “requestSeed” message. |
|
0x02-42, all even nr inbetween |
SendKey with different levels of security defined by the vehicle manufacturer. Request a “key” number back to the ECU using the appropriate service SecurityAccess “sendKey” request message. |
|
|
0x5F |
RequestSeed security level defined in ISO Road vehicles — End of life activation of on-board pyrotechnic devices |
|
|
0x44-60 |
SendKey security level defined in ISO Road vehicles — End of life activation of on-board pyrotechnic devices |
|
|
0x28 |
0x00 |
This value indicates that the reception and transmission of messages shall be enabled for the specified communicationType. |
|
0x01 |
This value indicates that the reception of messages shall be enabled and the transmission shall be disabled for the specified communicationType. |
|
|
0x02 |
This value indicates that the reception of messages shall be disabled and the transmission shall be enabled for the specified communicationType. |
|
|
0x03 |
This value indicates that the reception and transmission of messages shall be disabled for the specified communicationType. |
|
|
0x3E |
0x00 |
tester present with positive response message |
|
0x80 |
tester present without response message |
|
|
0x83 |
0x01 |
the ECU shall read the extended timing parameter set, If the read access to the timing parameter set is successful, the ECU shall send an AccessTimingParameter response with the positive response parameters. |
|
0x02 |
the ECU shall change all timing parameters to the default values and send an AccessTimingParameter response primitive with the positive response parameters before the default timing parameters become active |
|
|
0x03 |
the ECU shall read the currently used timing parameters. |
|
|
0x04 |
the ECU shall perform all actions necessary to change the timing parameters to the requested value |
|
|
0x84 |
X |
The purpose of this service is to transmit data that is protected against attacks from third parties, which could endanger data security, |
|
0x85 |
0x01 |
The ECU(s) shall resume the setting of diagnostic trouble codes according to normal operating conditions. |
|
0x02 |
The ECU(s) shall stop the setting of diagnostic trouble codes. |
|
|
0x86 |
X |
This service provides the possibility of automatically executing a diagnostic service in the event that a specified event occurs in the ECU. The diagnostic tool specifies the event (including optional event parameters) and the service (including service parameters) to be executed if the event occurs. |
|
0x87 |
0x01 |
This parameter is used to verify if a transition to a predefined baud rate, which is specified by the baudrateIdentifier data parameter, can be performed. |
|
0x02 |
This parameter is used to verify if a transition to a specifically defined baud rate, which is specified by the linkBaudrateRecord data parameter, can be performed. |
|
|
0x03 |
This sub-function parameter requests the ECU(s) to transition the baud rate to the one that was specified in the preceding verification message. |
|
|
0x22 |
X |
The diagnostic tool requests to read the current value of a record identified by a provided by dataIdentifier. |
|
0x23 |
X |
The diagnostic tool requests to read the current value of the provided memory range. |
|
0x24 |
X |
The diagnostic tool requests to read the scaling information of a record identified by a provided dataIdentifier. |
|
0x2A |
X |
The diagnostic tool requests to schedule data in the server for periodic transmission. |
|
0x2C |
0x01 |
This value shall be used to specify to the ECU that definition of the dynamic data identifier shall occur via a data identifier reference. |
|
0x02 |
This value shall be used to specify to the ECU that definition of the dynamic data identifier shall occur via an address reference. |
|
|
0x03 |
This value shall be used to clear the specified dynamic data identifier. |
|
|
0x2E |
X |
The diagnostic tool requests to write a record specified by a provided dataIdentifier. |
|
0x3D |
X |
The diagnostic tool requests to overwrite a provided memory range. |
|
0x14 |
X |
Allows the diagnostic tool to clear diagnostic information from the server |
|
0x19 |
X |
Allows the diagnostic tool to request diagnostic information from the server |
|
0x2F |
X |
The InputOutputControlByIdentifier service is used by the diagnostic tool to substitute a value for an input signal, |
|
0x31 |
0x01 |
This parameter specifies that the ECU shall start the routine specified by the routineIdentifier. |
|
0x02 |
This parameter specifies that the ECU shall stop the routine specified by the routineIdentifier. |
|
|
0x03 |
This parameter specifies that the ECU shall return result values of the routine specified by the routineIdentifier. |
|
|
0x34 |
X |
The diagnostic tool requests the negotiation of a data transfer from the diagnostic tool to the ECU. |
|
0x35 |
X |
The diagnostic tool requests the negotiation of a data transfer from the ECU to the diagnostic tool. |
|
0x36 |
X |
The diagnostic tool transmits data to the ECU (download) or requests data from the server (upload). |
|
0x37 |
X |
The diagnostic tool requests the termination of a data transfer. |
Common response codes
In this window are all the ISO defined response codes visible. When the code isn’t specified in this window it can be bonded to a manufacturer or it is data which can be translated.
|
Response code |
Discription |
|
0x00 |
positiveResponse |
|
0x10 |
generalReject |
|
0x11 |
serviceNotSupported |
|
0x12 |
subFunctionNotSupported |
|
0x13 |
incorrectMessageLengthOrInvalidFormat |
|
0x14 |
responseTooLong |
|
0x21 |
busyRepeatReques |
|
0x22 |
conditionsNotCorrect |
|
0x24 |
requestSequenceError |
|
0x31 |
requestOutOfRange |
|
0x33 |
securityAccessDenied |
|
0x35 |
invalidKey |
|
0x36 |
exceedNumberOfAttempts |
|
0x37 |
requiredTimeDelayNotExpired |
|
0x70 |
uploadDownloadNotAccepted |
|
0x71 |
transferDataSuspended |
|
0x72 |
generalProgrammingFailure |
|
0x73 |
wrongBlockSequenceCounter |
|
0x78 |
requestCorrectlyReceived-ResponsePending |
|
0x7E |
subFunctionNotSupportedInActiveSession |
|
0x7F |
serviceNotSupportedInActiveSession |
|
0x81 |
rpmTooHigh |
|
0x82 |
rpmTooLow |
|
0x83 |
engineIsRunning |
|
0x84 |
engineIsNotRunning |
|
0x85 |
engineRunTimeTooLow |
|
0x86 |
temperatureTooHigh |
|
0x87 |
temperatureTooLow |
|
0x88 |
vehicleSpeedTooHigh |
|
0x89 |
vehicleSpeedTooLow |
|
0x8A |
throttle/PedalTooHigh |
|
0x8B |
throttle/PedalTooLow |
|
0x8C |
transmissionRangeNotInNeutral |
|
0x8D |
transmissionRangeNotInGear |
|
0x8F |
brakeSwitch(es)NotClosed (Brake Pedal not pressed or not applied) |
|
0x90 |
shifterLeverNotInPark |
|
0x91 |
torqueConverterClutchLocked |
|
0x92 |
voltageTooHigh |
|
0x93 |
voltageTooLow |
Examples
Example 1: request extend diagnostic session
Request message
data[0x1003]
SID = 1st byte = 0x10 – has sub-function
SBF (Sub-function) = 2nd byte = 0x03
0x03 means Extended diagnostic session
Positive response message
data[0x5003]
Response SID = 1ste byte = 0x50 = positive response
SBF = 2nd byte = 0x03
Negative response message
data[0x7F10XX]
0x7F = 1st byte = negative response byte
SID = 0x10 = 2nd byte
0xXX = this is an example for last bytes = indicates a negative response code
Example 2: Requesting a VIN
Request message
data[0x22F190]
SID = 1st byte = 0x22 = Read Data By Identifier = No SBF
0xF190 = 2nd & 3rd byte = read VIN identifier
Response message
data[0x62F1905756575A5A5A43445A4D57303030303030]
Response SID = 1ste byte = 0x62 = positive response
0xF190 = 2nd & 3rd byte = response to read VIN identifier
0x5756575A5A5A43445A4D57303030303030 = data response code = Vehicle VIN in HEX code
Possible to translate with ASCII (HEX to ASCII converter)
Real VIN becomes = WVWZZZCDZMW000000
Example 3: requesting vehicle-manufacturer-specific ECU hardware number (serial number)
Request message
data[0x22F191]
SID = 1st byte = 0x22 = Read Data By Identifier = No SBF
0xF191 = 2nd & 3rd byte = read vehicle-manufacturer-specific ECU hardware number
Response message
data[0x62F1913557413936323130303020]
Response SID = 1ste byte = 0x62 = positive response
0xF191 = 2nd & 3rd byte = response to read vehicle-manufacturer-specific ECU hardware number
0x3557413936323130303020 = data response code = vehicle-manufacturer-specific ECU hardware number in HEX
Possible to translate with ASCII (HEX to ASCII converter)
Real vehicle-manufacturer-specific ECU hardware number becomes = 5WA962000B
Example 4: Programming date when ECU was last programmed
Request message
data[0x2EF199210101]
SID = 1st byte = 0x2E = Write Data By Identifier = NO SBF
0xF199 = 2nd & 3rd byte = write programming Date Data Identifier
0x210101 = date (written as: year, month, day) = in this case: 1st of January 2021
Response message
data[0x6EF199]
SID = 1st byte = 0x6E = positive response
0xF199 = 2nd & 3rd byte = response to write programming Date Data Identifier
Example 5: check if tester is present. (i.e. check if remote is still connected to CAN-bus)
Request message
Data[0x3E80]
SID = 1st byte = 0x3E = Tester Present = has SBN
SFN = 2nd byte = 0x0 = zero Sub-Function without response message