UDS is defined (Unified Diagnostic Services) in the standards ISO 14229 contains (the bus system-independent part) and ISO 15765-3 (CAN describes the specific implementation). Unlike OBD writes the UDS standards applicable to the general vehicle diagnostic no CAN identifier and no CAN baud rates. Here, then, any vehicle manufacturer is able to decide freely. be called The Standard, however, define how the SIDs and PIDs (hot at UDS Sub-level parameters). Unlike the OBD content of the messages in UDS is not defined in practice. That is, everyone can vehicle manufacturers specify how it defines data, under what parameters on the responsibility, as it codes etc.

The message structure of the UDS diagnostic services consistent with the structure of OBD: The first byte is the SID. Then a detail of the service follows the so-called sub-level identifiers (essentially corresponds to the PID in OBD).

At UDS, there is the possibility to give positive response to messages. For this, the diagnostic tester must be in the request, the top bit set of sub-level identifiers to 1. Negative responses on the other hand must always be sent. This absence of positive response messages is useful for example, to reduce the bus load in flashing.

There are a large number of UDS diagnostic services. The following two tables show an extract of it here. In the tables for comparison, the respective services for the predecessor of UDS, KWP 2000 are shown.

Extract the diagnostic services of UDS and KWP 2000

In the first column you will find the so-called functional group. It summarizes the diagnostic services along functional lines. In the second column contains the SID for UDS and KWP 2000th In many cases, the UDS diagnostic services and diagnostic services KWP 2000, at least for the SIDs are identical. In some cases, there are also differences. Then you see in the next column "Default" session, an indication that the service in the default diagnostic session is available or not. You remember, the default session is the default state in the safety concept of the vehicle diagnostics, see the section front. Then the description of the services listed. Here, too, between KWP 2000 and UDS changed a lot and at the end still a column that describes the diagnostic services in more detail.

Let's start with the top of the functional group "Diagnostics and Communication Management. So the function group that controls the diagnostic meetings and influences the communication during the diagnostic session. It begins with the diagnostic service Diagnostic Session Control. He has the identifier 0x10 and of course, is in the default session already available. Only with the service you get from the default session in any other diagnostic session, or at the end of a special diagnostic meeting, back to the default session. They see KWP 2000, these were two different services. When UDS was summarized from a service and is on the sub-level ID to control whether the diagnostic session to be started or stopped.

Then there are the service TesterPresent. He serves as a non-default session to obtain the consent session. Furthermore, Security AccessWe have met in connection with the diagnostic meetings already. Followed by the service ECU resetTo control devices and a service reset Communication ControlTo control the communication. This is typically the case during a diagnostic session to restrict the communication, as in the case of Flash programming. There one needs as much bus bandwidth. This is achieved most easily if one prohibits the other control devices to communicate through this service.

Then there are the service ControlDTCSettingWhich controls the storage of the error values. Here, for example, can be turned off within the shop to repair the fault memory. The second function group Data Transmission is essentially required to read or write data. Here we can distinguish essentially services that work with a parameter-identifier or services that directly address the memory. They are ReadDataByIdentifier or WriteDataByIdentifier and ReadMemoryByAdress or WriteMemoryByAdress. Over by the vehicle manufacturer predefined identifiers can then be decided which data is read or written. Via direct memory access, you can practically change everything, provided you know the correct memory address for the current software version.

Then we have a group of services than in the standard UDS Stored Data Transmission Function group is called. Actually, there are diagnostic services to access the error log. That is essentially what OBD provides. There are two main services: ReadDTDInformation and clear diagnostic information. With ReadDTDInformation can the error codes and freeze frame data read and clear diagnostic information You can clear the fault memory. KWP 2000, here a lot more services. These are at UDS not disappeared, but only consolidated in a service. Where the distinction is on the sub-level parameters.

Then we had already in OBD services that certain test functions, can enable, for example, the tank venting test. We have also in extended form with UDS. This is the function group Input-Output Control. In a very similar vein, the diagnostic services of the functional group Remote Activation Of Routine. The service routine control can, in principle, any, activated from the control unit development in the control unit pre-programmed functions, from the outside. This can be a test run, a routine for Flash programming or something else. Finally, we still find the function group Upload Download. Here services are combined with which one can read the ECU memory write in large blocks or slabs. They are usually used for reading or operating parameters for flash programming. The presented list of diagnostic services is by no means complete. We have omitted a number of seldom-used exotic features, but want to respond to a few specialties but a little more closely.

Specialties of UDS

This concerns the communication parameters. CAN typically operates at a fixed bit rate. When switching to a different diagnostic session but it is quite possible to change the parameters of the bus system or the transport protocol. The ability to change the bit rate and formerly owned by the K-Line. When CAN is essentially only the parameters of the transport protocol, ie the time-outs between request and response or between Consecutive frames are converted. This is done primarily in Flash programming to increase the bandwidth of the bus system, which is available for the programming data. In addition, it blocks most communication here the other control devices and switches off the fault memory.

Among the other specific ways of UDS includes data recording, which you use at test benches or the driving test: Normally, readings from the ECU polled by polling. That is, the diagnostic tester sends a request query to the controller and the controller responds with exactly one response message. For intermittent readings of the tester should therefore periodically send requests. To reduce the bus load and simplification of communication, it is possible in UDS, the diagnosis service ReadDataByPeriodicIdentifier with only a request to receive periodic responses. The responses will then contain the identifier corresponding to the respective measured values. This service will be terminated as soon as the tester sends a further request.

Another special opportunity in UDS is the diagnostic service ResponseOnEventService. The control box sends its own initiative, subject to certain internal events, a list of answers to the tester. Typical events that trigger such a message can be Zeitgeberinterrupts, error log entries or the above or below certain thresholds.

In summary, one can say that UDS is a relatively complex standard that there are a number of optional or redundant functions and that it will therefore be rare in practice a 100 percent UDS implementation. Each manufacturer will typically opt for a particular subset. In addition, although the norm standardized many services, but that the content of services, such as error codes, PIDs, data, value ranges, etc., usually vendor-specific.

Example: Flash Programming I

As a practical example of the UDS diagnostic services, let us consider the typical structure of a flash programming, as illustrated. The diagnostic tester sends a Growl ReadDataByIdentifier. With this request, it reads the hardware ID and software ID from the controller to see which device it exactly right. Then, the diagnostic tester, the control unit switches to a special diagnostic session. Not the actual diagnosis session for the program, but a session in which there are a number of advanced services available. This is done with the diagnostic service diagnosticSession control. This advanced diagnostic session asks the diagnostic tester, the control unit whether the preconditions are met for flash programming. This is typically that the programming can be done only when the vehicle that the engine must be made, etc.

Basic sequence of a flash programming

Then, the diagnostic tester usually with the service Communication Control the fault memory and off the bus communication in other controllers. This advanced diagnostic session has served its purpose. Now the diagnostic tester on the diagnostic service diagnosticSession control to the programming session. At least now is a SecurityAccess necessary. Thereafter, the diagnostic tester usually sends the so-called fingerprint of the control unit. This is information that is stored in the ECU memory permanently, to indicate that programming. It typically has a workshop identifier in the memory of the controller is written, can be enacted so that afterwards who has reprogrammed the ECU.

Before the flash memory can be reprogrammed, it must be deleted. This is achieved by calling a routine in the ECU memory of the diagnostic service routine control done. Thereafter, the service request download the actual programming operation is initiated. This service allows the controller will also be notified of which are loaded into memory the data and how much data can be expected. Now starts the actual download of data in a loop with the service transfer data. The storage area is transmitted here in blocks. At the end of the diagnostic tester says the control device transfer exit Now that all data has been transferred. After examining the data transmitted in the control unit now takes place, the actual flash process. Typically, the programming operation will take some time. During this time the controller is not able to process requests from the tester. Therefore, the control unit the service transfer exit usually with a negative response and the error code ResponsePending . Reply Only when the programming is completed, the controller sends a positive confirmation transfer exit.

Then examine the diagnostic tester, whether programming was successful, he routine control a routine in the control unit is activated, which checks the memory. Thereafter, a further call to routine control different n dependence of the flash programming examined, such as whether the software or the corresponding record must be programmed. The download process is completed the controller, the controller is normally ECUReset reset. The controller will reboot and goes to normal operation, so back to the default diagnostic session.

In order for the other ECUs in the vehicle also restore the status quo, will Communication Control the normal bus communication again and the fault memory in the other control devices is turned on again. Hence the download process is complete

In the following section, we want to dwell on KWP 2000, the forerunner of UDS.