Unified Diagnostic Services (UDS) is a diagnostic communication protocol used in electronic control units (ECUs) within automotive electronics, which is specified in the ISO 14229-1. [1] It is derived from ISO 14230-3 (KWP2000) and the now obsolete ISO 15765-3 (Diagnostic Communication over Controller Area Network (DoCAN) [2] ). 'Unified' in this context means that it is an international and not a company-specific standard. By now this communication protocol is used in all new ECUs made by Tier 1 suppliers of Original Equipment Manufacturer (OEM), and is incorporated into other standards, such as AUTOSAR. The ECUs in modern vehicles control nearly all functions, including electronic fuel injection (EFI), engine control, the transmission, anti-lock braking system, door locks, braking, window operation, and more.
Diagnostic tools are able to contact all ECUs installed in a vehicle which has UDS services enabled. In contrast to the CAN bus protocol, which only uses the first and second layers of the OSI model, UDS utilizes the fifth and seventh layers of the OSI model. The Service ID (SID) and the parameters associated with the services are contained in the payload of a message frame.
Modern vehicles have a diagnostic interface for off-board diagnostics, which makes it possible to connect a computer (client) or diagnostics tool, which is referred to as tester, to the communication system of the vehicle. Thus, UDS requests can be sent to the controllers which must provide a response (this may be positive or negative). This makes it possible to interrogate the fault memory of the individual control units, to update them with new firmware, have low-level interaction with their hardware (e.g. to turn a specific output on or off), or to make use of special functions (referred to as routines) to attempt to understand the environment and operating conditions of an ECU to be able to diagnose faulty or otherwise undesirable behavior.
SID (Service Identifier)
Function group | Request SID | Response SID | Service | Description |
---|---|---|---|---|
Diagnostic and Communications Management | 0x10 | 0x50 | Diagnostic Session Control | UDS offers access levels called "sessions". Different sessions usually offer different levels of access to services and/or sub-functions. During normal use (on start), the session should be 0x01 Default Session. This "Diagnostic Session Control" service allows the user to switch between available sessions specific to the ECU. Some sessions may not have been implemented. Others may have access control measures, requiring authorization through services like 0x27 Security Access or 0x29 Authentication. Additionally, sessions may require certain operating conditions to be met, such as manufacturer specific "pre-production" or "boot modes", which are separate from UDS. The following sessions are standard, but vehicle manufacturer and supplier-specific sessions are often implemented in conjunction:
|
0x11 | 0x51 | ECU Reset | The service "ECU reset" is used to restart the control unit (ECU). Depending on the control unit hardware and implementation, different forms of reset can be used:
Again, there are reserved values that can be defined for vehicle manufacturers and vehicle suppliers specific use. | |
0x14 | 0x54 | Clear Diagnostic Information | Clears diagnostic trouble codes (DTC's) from ECU memory.
Like other sub-functions in this list, there are manufacturer-specific reserved values that offer unique and/or specific functionality. | |
0x27 | 0x67 | Security Access | Security check is available to enable the most security-critical services. For this purpose a "Seed" is generated and sent to the client by the control unit. From this "Seed" the client has to compute a "Key" and send it back to the control unit to unlock the security-critical services. | |
0x28 | 0x68 | Communication Control | With this service, both the sending and receiving of messages can be turned off in the control unit. | |
0x29 | 0x69 | Authentication | An update (2020) of the standard added this service to provide a standardized approach to more modern methods of authentication than are permitted by the Security Access (0x27) service, including bidirectional authentication with PKI-based Certificate Exchange. | |
0x3E | 0x7E | Tester Present | If no communication is exchanged with the client for a long time, the control unit automatically exits the current session and returns to the "Default Session" back, and might go to sleep mode. Therefore, there is an extra service which purpose is to signal to the device that the client is still present. | |
0x83 | 0xC3 | Access Timing Parameters | In the communication between the controllers and the client, certain times must be observed. If these are exceeded, without a message being sent, it must be assumed that the connection was interrupted. These times can be called up and changed. | |
0x84 | 0xC4 | Secured Data Transmission | ||
0x85 | 0xC5 | Control DTC Settings | Enables, disables, or otherwise controls the transmission of DTC's. This is helpful when maintenance or modification work is being performed on a vehicle to avoid anomalous or annoying behavior, like beeping on an instrument cluster or safety systems activating in response to an external DTC. Like most UDS settings, this does not typically persist after a reboot.
| |
0x86 | 0xC6 | Response On Event | ||
0x87 | 0xC7 | Link Control | The Service Link Control is used to set the baud rate of the diagnostic access. It is usually implemented only at the central gateway. | |
Data Transmission | 0x22 | 0x62 | Read Data By Identifier | With this service, it is possible to retrieve one or more values of a control unit. This can be information of all kinds and of different lengths such as Partnumber or the software version. Dynamic values such as the current state of the sensor can be queried. Each value is associated to a Data Identifier (DID) between 0 and 65535; for example, the VIN DID is 61840d (0xF190). Normal CAN signals are meant for information that some ECU uses in its functionality. DID data is sent on request only, and is for information that no ECU uses, but a service tool or a software tester can benefit from. |
0x23 | 0x63 | Read Memory By Address | Read data from the physical memory at the provided address. This function can be used by a testing tool, in order to read the internal behaviour of the software. | |
0x24 | 0x64 | Read Scaling Data By Identifier | ||
0x2A | 0x6A | Read Data By Identifier Periodic | With this service, values are sent periodically by a control unit. The values to be sent must be defined to only using the "Dynamically Define Data Identifier". | |
0x2C | 0x6C | Dynamically Define Data Identifier | This service offers the possibility of a fix for a device specified Data Identifier (DID) pool to configure another Data Identifier. This is usually a combination of parts of different DIDs or simply a concatenation of complete DIDs. The requested data may be configured or grouped in the following manner:
| |
0x2E | 0x6E | Write Data By Identifier | With the same Data Identifier (DID), values can also be changed. In addition to the identifier, the new value is sent along. | |
0x3D | 0x7D | Write Memory By Address | The “Write Memory By Address” service allows the external diagnostic tool to write information into the ECU at one or more contiguous memory locations. | |
Stored Data Transmission | 0x14 | 0x54 | Clear Diagnostic Information | Delete all stored DTC |
0x19 | 0x59 | Read DTC Information | DTC stands for "Diagnostic Trouble Codes". Each DTC handled by the control unit fault is stored with its own code in the error memory and can be read at any time. In addition to the error, additional information will be stored, which can also be read. | |
Input / Output Control | 0x2F | 0x6F | Input Output Control By Identifier | This service allows an external system intervention on internal / external signals via the diagnostic interface. By specifying a so-called option bytes additional conditions for a request can be specified, the following values are specified: ReturnControlToECU: The device must get back controls of the mentioned signals. ResetToDefault: The tester prompts to reset signals to the system wide default value. Freeze Current State: The device shall freeze the current signal value. ShortTermAdjustment: The device shall use the provided value for the signal |
Remote Activation of Routine | 0x31 | 0x71 | Routine Control | Control routine services of all kinds can be performed. There are three different message types:
The start and stop message parameters can be specified. This makes it possible to implement every possible project-specific service. |
Upload / Download | 0x34 | 0x74 | Request Download | Downloading new software or other data into the control unit is introduced using the "Request Download". Here, the location and size of the data is specified. In turn, the tester specifies how large the data packets can be. |
0x35 | 0x75 | Request Upload | The service "request upload" is almost identical to the service "Request Download". With this service, the software from the control unit is transferred to the tester. The location and size must be specified. Again, the size of the data blocks are specified by the tester. | |
0x36 | 0x76 | Transfer Data | For the actual transmission of data, the service "Transfer Data" is used. This service is used for both uploading and downloading data. The transfer direction is notified in advance by the service "Request Download" or "Upload Request". This service should try to send packets at maximum length, as specified in previous services. If the data set is larger than the maximum, the "Transfer Data" service must be used several times in succession until all data has arrived. | |
0x37 | 0x77 | Request Transfer Exit | A data transmission can be 'completed' when using the "Transfer Exit" service. This service is used for comparison between the control unit and the tester. When it is running, a control unit can answer negatively on this request to stop a data transfer request. This will be used when the amount of data (set in "Request Download" or "Upload Request") has not been transferred. | |
0x38 | 0x78 | Request File Transfer | This service is used to initiate a file download from the client to the server or upload from the server to the client. Additionally information about the file system are available by this service. | |
0x7F | Negative Response | This response is given when a service request could not be performed, for example having a not supported Data Identifier. A Negative Response Code will be included. |
Negative response from ECU contains SID 0x7F and two payload bytes: request's SID and error code. These codes can be found in freely available software (for example, BusMaster) as well as in the ISO itself.
NRC | Description |
---|---|
0x10 | General reject |
0x11 | Service not supported |
0x12 | Subfunction not supported |
0x13 | Incorrect message length or invalid format |
0x14 | Response too long |
0x21 | Busy, repeat request |
0x22 | Conditions not correct |
0x24 | Request sequence error |
0x25 | No response from subnet component |
0x26 | Failure prevents execution of requested action |
0x31 | Request out of range |
0x33 | Security access denied |
0x34 | Authentication failed |
0x35 | Invalid key |
0x36 | Exceeded number of attempts |
0x37 | Required time delay not expired |
0x38 | Secure data transmission required |
0x39 | Secure data transmission not allowed |
0x3A | Secure data verification failed |
0x50 | Certificate validation failed, invalid time period |
0x51 | Certificate validation failed, invalid signature |
0x52 | Certificate validation failed, invalid chain of trust |
0x53 | Certificate validation failed, invalid type |
0x54 | Certificate validation failed, invalid format |
0x55 | Certificate validation failed, invalid content |
0x56 | Certificate validation failed, invalid scope |
0x57 | Certificate validation failed, invalid certificate |
0x58 | Ownership verification failed |
0x59 | Challenge calculation failed |
0x5A | Setting access right failed |
0x5B | Session key creation/derivation failed |
0x5C | Configuration data usage failed |
0x5D | Deauthentication failed |
0x70 | Upload download not accepted |
0x71 | Transfer data suspended |
0x72 | General programming failure |
0x73 | Wrong block sequence number |
0x78 | Request correctly received, response pending |
0x7E | Subfunction not supported in active session |
0x7F | Service not supported in active session |
0x81 | RPM too high |
0x82 | RPM too low |
0x83 | Engine is running |
0x84 | Engine is not running |
0x85 | Engine run time too low |
0x86 | Temperature too high |
0x87 | Temperature too low |
0x88 | Vehicle speed too high |
0x89 | Vehicle speed too low |
0x8A | Throttle/pedal too high |
0x8B | Throttle/pedal too low |
0x8C | Transmission range not in neutral |
0x8D | Transmission range not in gear |
0x8F | Brake switch not closed |
0x90 | Shifter lever not in park |
0x91 | Torque converter clutch locked |
0x92 | Voltage too high |
0x93 | Voltage too low |
0x94 | Resource temporary unavailable |
The Open Systems Interconnection (OSI) model is a reference model from the International Organization for Standardization (ISO) that "provides a common basis for the coordination of standards development for the purpose of systems interconnection." In the OSI reference model, the communications between systems are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.
KNX is an open standard for commercial and residential building automation. KNX devices can manage lighting, blinds and shutters, HVAC, security systems, energy management, audio video, white goods, displays, remote control, etc. KNX evolved from three earlier standards; the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus.
A controller area network (CAN) is a vehicle bus standard designed to enable efficient communication primarily between electronic control units (ECUs). Originally developed to reduce the complexity and cost of electrical wiring in automobiles through multiplexing, the CAN bus protocol has since been adopted in various other contexts. This broadcast-based, message-oriented protocol ensures data integrity and prioritization through a process called arbitration, allowing the highest priority device to continue transmitting if multiple devices attempt to send data simultaneously, while others back off. Its reliability is enhanced by differential signaling, which mitigates electrical noise. Common versions of the CAN protocol include CAN 2.0, CAN FD, and CAN XL which vary in their data rate capabilities and maximum data payload sizes.
An electronic control unit (ECU), also known as an electronic control module (ECM), is an embedded system in automotive electronics that controls one or more of the electrical systems or subsystems in a car or other motor vehicle.
A vehicle bus is a specialized internal communications network that interconnects components inside a vehicle. In electronics, a bus is simply a device that connects multiple electrical or electronic devices together. Special requirements for vehicle control such as assurance of message delivery, of non-conflicting messages, of minimum time of delivery, of low cost, and of EMF noise resilience, as well as redundant routing and other characteristics mandate the use of less common networking protocols. Protocols include Controller Area Network (CAN), Local Interconnect Network (LIN) and others. Conventional computer networking technologies are rarely used, except in aircraft, where implementations of the ARINC 664 such as the Avionics Full-Duplex Switched Ethernet are used. Aircraft that use Avionics Full-Duplex Switched Ethernet (AFDX) include the B787, the A400M and the A380. Trains commonly use Ethernet Consist Network (ECN). All cars sold in the United States since 1996 are required to have an On-Board Diagnostics connector, for access to the car's electronic controllers.
Society of Automotive Engineers standard SAE J1939 is the vehicle bus recommended practice used for communication and diagnostics among vehicle components. Originating in the car and heavy-duty truck industry in the United States, it is now widely used in other parts of the world.
General Motors Local Area Network (GMLAN) is an application- and transport-layer protocol using controller area network for lower layer services. It was standardized as SAE J2411 for use in OBD-II vehicle networks.
On-board diagnostics (OBD) is a term referring to a vehicle's self-diagnostic and reporting capability. In the United States, this capability is a requirement to comply with federal emissions standards to detect failures that may increase the vehicle tailpipe emissions to more than 150% of the standard to which it was originally certified.
A fieldbus is a member of a family of industrial digital communication networks used for real-time distributed control. Fieldbus profiles are standardized by the International Electrotechnical Commission (IEC) as IEC 61784/61158.
AUTOSAR is a global development partnership founded in 2003 by automotive manufacturers, suppliers and other companies from the electronics, semiconductor and software industries. Its purpose is to develop and establish an open and standardized software architecture for automotive electronic control units (ECUs).
ISO 11783, known as Tractors and machinery for agriculture and forestry—Serial control and communications data network is a communication protocol for the agriculture industry based on, and harmonized with, the SAE J1939 protocol.
OBD-II PIDs are codes used to request data from a vehicle, used as a diagnostic tool.
Brake-by-wire technology in the automotive industry is the ability to control brakes through electronic means, without a mechanical connection that transfers force to the physical braking system from a driver input apparatus such as a pedal or lever.
Vector Informatik develops software tools and components for networking of electronic systems based on the serial bus systems CAN, LIN, FlexRay, MOST, Ethernet, AFDX, ARINC 429, and SAE J1708 as well as on CAN-based protocols such as SAE J1939, SAE J1587, ISO 11783, NMEA 2000, ARINC 825, CANaerospace, CANopen and more. The headquarters of the company Vector Informatik GmbH is in Stuttgart, Germany. Subsidiaries include Braunschweig, Munich, Hamburg, Regensburg along with international subsidiaries in Brazil, China, France, Italy, England, India, Japan, South Korea, Austria, Sweden, and the USA. Vector Informatik also includes Vector Consulting Services GmbH, a consultation firm specializing in optimization of technical product development. Altogether, these companies are referred to as the Vector Group.
Keyword Protocol 2000, abbreviated KWP2000, is a communications protocol used for on-board vehicle diagnostics systems (OBD). This protocol covers the application layer in the OSI model of computer networking. The protocol is standardized by International Organization for Standardization as ISO 14230.
CANape is a software tool from Vector Informatik. This development software, widely used by OEMs and ECU suppliers of automotive industries is used to calibrate algorithms in ECUs at runtime.
ISO 15765-2, or ISO-TP (Transport Layer), is an international standard for sending data packets over a CAN-Bus. The protocol allows for the transport of messages that exceed the eight byte maximum payload of CAN frames. ISO-TP segments longer messages into multiple frames, adding metadata (CAN-TP Header) that allows the interpretation of individual frames and reassembly into a complete message packet by the recipient. It can carry up to 232-1 (4294967295) bytes of payload per message packet starting from the 2016 version. Prior version were limited to a maximum payload size of 4095 bytes.
INCA is a measurement, calibration and diagnostic software published by ETAS. With its large installation base in the auto industry, this development software is deployed during all phases of the development of electronic control units (ECUs) and ECU software programs for measuring, calibration, diagnostics and programming.
CAN FD is a data-communication protocol used for broadcasting sensor data and control information on 2 wire interconnections between different parts of electronic instrumentation and control system. This protocol is used in modern high performance vehicles.
Automotive security refers to the branch of computer security focused on the cyber risks related to the automotive context. The increasingly high number of ECUs in vehicles and, alongside, the implementation of multiple different means of communication from and towards the vehicle in a remote and wireless manner led to the necessity of a branch of cybersecurity dedicated to the threats associated with vehicles. Not to be confused with automotive safety.