Automotive Hub: UDS vs KWP2000

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

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.

What are the difference between KWP2000 & UDS?

1. Event triggering and periodic transmission are applicable only in UDS.

2. Positive response supression for tester present is not present in KWP2000.

3. Transfer of measurement values, only two-byte identifers are available in UDS. In KWP2000 one byte record Local Identifer and Two Byte Common Identifer

4. Error memory management.

Differences between KWP 2000 and UDS

The classic diagnostic communication with KWP protocols has favored a symmetrical number of requests and responses. In contrast, UDS provides event-driven and periodic services, for which the number of requests and responses can differ greatly. The KWP 2000 principles to transfer measurement values and to manage the ECU´s error memory were re-engineered for the UDS standard.

Transfer of measurement values

For the transfer of measurement values, only the two-byte dataIdentifiers are available with UDS. KWP 2000 specifies a one-byte recordLocalIdentifier and two-byte commonIdentifier.

To increase data transmission efficiency, several measurement values can be requested with one UDS service request, and there are two different response types. The specified data identifiers are more comprehensive (see ISO 14229-1 annex C.1). Examples include:

• $F100 … $F19F: for example, KWP 2000 identifier, calibration data, and ODX file identifier

• $F2xx: Periodic data identifier

• $F3xx: Dynamically defined data identifier

• $F4xx … $F8xx: OBD according to ISO 15031-5

When measured values or bigger memory areas have to be transmitted via memory addressing,the addressAndLengthFormatIdentifier of the UDS standard provides more capable addressing.

TheblockSequenceCounter constructs a more efficient data transfer, because a complete reset of the process in case of an error is not necessary.

Error memory management

KWP 2000 contains four services for the management of the error memory. These are $14 (clearDiagnosticInformation), $18 (readDTCByStatus), $17 (readStatusOfDTC), and $12 (readFreezeFrameData).

In contrast, the UDS standard specifies only two services for the error memory management: $14 (clearDiagnosticInformation) and $19 (readDTCInformation). But due to the fact that there are 21 different sub-functions for the service request $19 (readDTCInformation), the abilities of these services are enhanced widely. The UDS standard contains approximately 60 pages of specifications for error memory management.

Documents:

Presentation_Debrecen_En_2008_03_27

K-Line CAN

Reserved for diagnostic communication Diagnostic & continuous communication between ECUs
Longer data packets can be transmitted A CAN frame is max. 8 bytes: encapsulation of request required
Configurable communication speed Fixed speed: because of the continuous bus configuration
Arbitration must be implemented by SW (UART) Bus arbitration, CAN-frame structure is handled by HW
Additional wire + HW Component (Layer1) Wire + required HW component already exists
Additional SW Driver for Layer 2 SW Drivers already exist, only sw of diagnostic communication must be implemented

Differences between CANalyzer and CANoe:The CANalyzer and CANoe tools were developed to meet the essential needs of the CAN-based module or systemdeveloper by combining a comprehensive set of measurement and simulation capabilities.Both CANalyzer and CANoe can interface to multiple CAN networks (or other common small area network protocols),and provide accurate time-stamped measurements for all communication transfers, including both acknowledgedmessages and communication errors. Recording and playback operations are standard. Users can record themessages from one system and e-mail them to another engineer for playback and analysis.Both tools basically operate like a multi-channel oscilloscope, a multi-channel logic analyzer, and a customalphanumeric display unit - all using an integrated database.In addition, both tools are capable of creating any message generation pattern, much like a programmable functiongenerator, with complete control of all network data variables (or signals).As shown in Figure 3, both CANoe and CANalyzer share a major portion of the same network analysis interface.

Figure 3 – CANalyzer & CANoe Major Network Analysis Interfaces

One Key Difference – Level of Node Control

One key difference between CANalyzer and CANoe is in the level of node control. Essentially, a single CANalyzer toolcan act as a single network member, but CANoe has no limit as to the number of modules with which it may substitute.As shown in Figure 4, CANalyzer supports the control of a single node (a single tester, or a single module simulation),while CANoe supports the control of a collection of multiple nodes (any number of module simulations or any number of testers).

Figure 4 - Level of Node Control Distinguishes Between CANalyzer and CANoe

In CANoe, each node may be enabled to evaluate a simulation, or each node may be disabled to allow connection of areal module to the “remaining network simulation”. This can be done in real time for any number of nodes and for oneor more communication networks.As shown in Figure 5, the ability to interconnect a real module to CANoe that represents “all the other remainingnetwork members” provides a significant testing advantage in distributed product architecture.

Figure 5 – Using CANoe to Simulate the Rest of the System

The limitations when using CANoe depend on both the speed of the available PC and the amount of CAN hardwarethat can be placed on a single PC. While laptops are typically limited to 4 CAN network connections (2 PCMCIA cardswith 2 CAN channels each), desktop configurations with up to 32 CAN channels have been created for specialapplications.

Graphic Panels – The Other Major Difference

The second and quite distinctive difference from CANalyzer is that CANoe supports “graphic panels” for both inputsand outputs. This allows the user to construct “higher-level application” behavior to simulate actual inputs and outputs.For example, let's assume that your new project requires you to build a tester. Traditionally, you would typically choosebetween two alternatives:

• Build a custom electronic module - design all the hardware and software yourself

• Build a semi-customized PC-based system

However, another choice is now available - you could construct the entire tester in CANoe and write the entireapplication in CAPL.CANoe allows you to construct tester panel interfaces to give inputs and outputs. You can add the necessary CAPLsoftware to interconnect your switch presses to the corresponding CAN transmit messages that you wish the tester to send. It is also easy to connect incoming CAN receive messages to your front panel graphic output devices. Inaddition, moving meters, blinking lights, and numerical display graphics are easy to create (see Figure 6).