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.
- Reserved for diagnostic
Diagnostic & continuous communication between ECUs
- Longer data packets can be
CAN frame is max. 8 bytes: encapsulation of request required
- Configurable communication
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
Wire + required HW component already exists
- Additional SW Driver for Layer
Drivers already exist, only sw of diagnostic communication must be
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.
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).
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).
Bit-mapped graphics and digital photos, as shown in Figure 7, of actual product front panels can be easily animated for use.