The KWP2000 protocol in automotive diagnostic applications
The KWP2000 protocol has become a de facto standard in automotive diagnostic applications. It is standardized as ISO 14230-3. KWP2000 describes the implementation of various diagnostic services that you can access through the protocol. You can run KWP2000 on various transport layers such as K-line (serial) or CAN.
transport protocol
Since KWP2000 uses messages of variable byte lengths, a layered transport protocol with only a well-defined (short) message length, such as CAN, is necessary. The transport protocol divides a long KWP2000 message into parts that can be transferred over the network and reassembles those parts to recover the original message.
KWP2000 runs on CAN on various transport protocols such as ISO TP (ISO 15765-2), TP 1.6, TP 2.0 (Volkswagen) and SAE J1939-21. For KWP2000, the automotive diagnostic command set supports only manufacturer-specific ISO TP (standardized to ISO 15765-2) and VW TP 2.0 transport protocols.
Diagnostic Services
The diagnostic services available in the KWP2000 are grouped into functional units and identified by a one-byte code (ServiceId). The standard does not define all codes; for some codes, the standard refers to other SAE or ISO standards, and some are reserved for manufacturer-specific extensions. The Automotive Diagnostic Command Set supports the following services:
• Diagnostic Management
• Data transmission
• Transmission of stored data (diagnostic trouble codes)
• Entry/exit control
• Routine Remote Activation
The upload/download and extended services are not part of the automotive diagnostic command set.
Diagnostic Service Format
Diagnostic services have a common message format. Each service defines a request message, a positive response message, and a negative response message. The request message has the ServiceId as the first byte, plus additional parameters defined by the service. The positive response message has an echo of ServiceId with bit 6 set as the first byte, plus the response parameters defined by the service.
The negative response message is typically a three-byte message: it has the negative response ServiceId as the first byte, an echo of the original ServiceId as the second byte, and a ResponseCode as the third byte. The only exception to this format is the negative response to an EscapeCode service; here, the third byte is an echo of the user-defined service code and the fourth byte is the response code. The KWP2000 standard partly defines the ResponseCodes, but there is room for manufacturer-specific extensions. For some of the ResponseCodes, KWP2000 defines an error handling procedure. Since both positive and negative responses have an echo of the requested service, you can always assign the responses to their corresponding request.
Connect disconnect
KWP2000 expects a diagnostic session to start with StartDiagnosticSession and end with StopDiagnosticSession. However, StartDiagnosticSession has a DiagnosticMode parameter that determines the type of diagnostic session. Depending on this type, the ECU may or may not support other diagnostic services, or operate in a restricted mode where not all ECU functions are available. The values of the DiagnosticMode parameter are manufacturer-specific and not defined in the standard. For a diagnostic session to remain active, you must run the TesterPresent service periodically if no other service is running. If the TesterPresent service is missing for a certain period of time, the diagnostic session ends and the ECU returns to normal operating mode.
Get Seed/Unlock
A GetSeed/Unlock mechanism can protect some diagnostic services. However, the applicable services are left to the manufacturer and are not defined by the standard. This defines several levels of security, but the manufacturer assigns these levels to certain services.
Read/write memory
Use the Read/WriteMemoryByAddress services to upload/download data to certain memory addresses on an ECU. The address is a 3-byte quantity in KWP2000 and a 5-byte quantity (4-byte address and 1-byte length) in calibration protocols. The Upload/Download functional unit services are very vendor specific and not well defined in the standard, so they are not a good way to provide a general upload/download mechanism.
measurements
Use the ReadDataByLocal/CommonIdentifier services to access ECU data similar to a DAQ list. A Local/CommonIdentifier describes a list of ECU quantities that are then transferred from the ECU to the tester. The transfer can be single value or periodic, with a slow, medium, or fast transfer rate. Transfer rates are manufacturer specific; you can use the SetDataRates service to set them, but these settings are manufacturer specific. The automotive diagnostic command set supports single point measurements.
Diagnostic Trouble Codes
An important diagnostic function is reading Diagnostic Trouble Codes (DTCs). KWP2000 defines various services that access DTCs based on their group or status.
input/output control
KWP2000 defines services to modify internal or external ECU signals. An example is redirecting the ECU sensor inputs to stimulated signals. The control parameters of these commands are manufacturer specific and are not defined in the standard.
Remote activation of a routine
These services are similar to CCP’s ActionService and DiagService functions. It can call an internal ECU routine identified by a Local/CommonIdentifier or a memory address. Contrary to the case of the CCP, the execution of this routine can be asynchronous; that is, there are separate Start, Stop, and RequestResult services. The control parameters of these commands are manufacturer specific and are not defined in the standard.
external references
For more information on the KWP2000 standard, see the ISO 14230-3 standard.