The Uds Protocol Has Become A Defacto Standard In Automotive Diagnostic Applications
The UDS protocol has become a de facto standard in automotive diagnostic applications. It is standardized as ISO 15765-3. UDS describes the implementation of various diagnostic services you can access through the protocol.
As UDS uses messages of variable byte lengths, a transport protocol is necessary on layers with only a well defined (short) message length, such as CAN. The transport protocol splits a long UDS message into pieces that can be transferred over the network a nd reassembles those pieces to recover the original message. UDS runs on CAN on various transport protocols. The Automotive Diagnostic Command Set supports only the ISO TP (standardized in ISO 15765-2) and manufacturer-specific VW TP 2.0 transport protocols.
Diagnostic Services
The diagnostic services available in UDS are grouped in functional units and identified by a one-byte code (ServiceId). Not all codes are defined in the standard; for some codes, the standard refers to other standards, and some are reserved for manufacturer-specific extensions. The Automotive Diagnostic Command Set supports the following services:
Diagnostic Management
Data Transmission
Stored Data Transmission (Diagnostic Trouble Codes)
Input/Output Control
Remote Activation of Routine
Diagnostic Service Format
Diagnostic services have a common me ssage format. Each service defines a Request Message, a Positive Re sponse Message, and a Negative Response Message. The general format of the diagnostic services complies with the KWP2000 definition; most of the Service Ids also comply with KWP2000. The Request Message has the ServiceId as first byte, plus additional service-defined parameters. The Positive Response Message has an echo of the ServiceId with bit 6 set as first byte, plus the service-defined response parameters. Some parameters to both the Request and Positive Response Messages are optional. Each service defines these parameters. Also, the standard does not define all parameters.
The Negative Response Message is usually a three-byte message: it has the Negative Response ServiceId (0x7F) as first byte, an echo of the original ServiceId as second byte, and a Re sponseCode as third byte. The UDS standard partly defines the ResponseCodes, but there is room left for manufacturer-specific extensions. For some of the ResponseCodes, UDS defines an error handling procedure. Because both positive and negative responses have an echo of the requested service, you always can assign the responses to their corresponding request.
External References
For more information about the UDS Standard, refer to the ISO 15765-3 standard.