Vehicles are being manufactured with constantly increasing numbers of control units and embedded systems. This rapid spread enables to add valuable features, but also presents new challenges for the automotive industry.
Most often, different suppliers develop and provide the required systems, while manufacturers are left with integrating everything together. This raises the issue of compatibility between different standards when troubleshooting any problems that arise while servicing the vehicles. The automotive industry has come up with many diagnostics protocols over the years - CAN, K-Line, KWP and others. Therefore, the need for a more unified communication protocol appeared and Unified Diagnostic Services (UDS) were developed.
What is UDS Protocol?
It is an automotive protocol that consolidates different standards like ISO 14230-3 (KWP2000), ISO 15765 and others. It is also used internationally across different companies and manufacturers. UDS protocol can be used to send requests to control units which must provide a response. This allows to read fault memory of individual control units, interact with their outputs, or use special functions (a.k.a. remote Activation of Routine), which help to understand the operating conditions of an ECU resulting in an ability to diagnose faults or unwanted behavior. The UDS standard is implemented to work over the CAN Bus and is generally accessed via the OBD-II port of the vehicle.
UDS protocol is described in more detail by the 14229-1:2013 International Organization for Standardization (ISO) specification. It is based on the Open System Interconnection (OSI) Reference Model, therefore it has a layered architecture. For example CAN protocol specifies the first and second layer of the OSI Model - that is the Physical Layer (ISO 11898-2) and the Data Link Layer (ISO 11898-2). Meanwhile UDS specifies the fifth (Session Layer) and seventh (Application Layer) layers of the OSI Model.
Unified Diagnostic Service (UDS) has 27 possible requests. Each service request has a uniquely assigned service identifier (SID), for example 0x10 = diagnostic session control request, 0x22 = read data by identifier request or 0x27 = security access. Each request has a defined positive response, meanwhile the response SID can be calculated by adding 0x40 to the SID of the request. The SID of a negative response in all cases is 0x7F. Please note that not all of the codes are defined by the ISO standard, there are some vehicle-manufacturer-specific services and functions which are not part of ISO 14229.
UDS vs Non-UDS
If you use OBDeleven, you might have noticed some differences between some UDS and Non-UDS functions, such as:
- Long Coding vs Long Coding UDS
- Adaptations vs Adaptations UDS
- Live Data vs Live Data UDS
- Output Test vs Output Test UDS and others
Or that some functions are only available for UDS control units, such as:
- Advanced ID
- Control Unit Reset
These functions differ due to different implementation and capabilities of various protocols and control units themselves. Therefore, there are small differences in user interface for UDS and non-UDS control unit functions. But there is no need for regular users to worry or know which protocol to use, everything is done automatically by the OBDeleven app and the appropriate functions are selected according to the specific control unit.
Conclusion
As the vehicles become more advanced and complex, ensuring compatibility between different electronic systems, troubleshooting any faults that occur has become crucial for the automotive industry. UDS protocol was created as a very versatile and capable diagnostic protocol that helps both vehicle and diagnostic equipment manufacturers to solve the newly appearing challenges.
