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 operate KWP2000 on multiple transport layers such as K-Line (serial) or CAN.
transport protocol
Since KWP2000 uses messages with variable byte length, a transport protocol on layers with only a well-defined (short) message length like CAN is required. The transport protocol breaks a long KWP2000 message into parts that can be transmitted over the network and reassembles those parts to recreate the original message.
KWP2000 runs on CAN on different transport protocols like ISO TP (ISO 15765-2), TP 1.6, TP 2.0 (Volkswagen) and SAE J1939-21. For KWP2000, the Automotive Diagnostic Command Set only supports the transport protocols ISO TP (standardized in ISO 15765-2) and manufacturer-specific VW TP 2.0.
diagnostic services
The diagnostic services available in 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, others are reserved for manufacturer-specific extensions. The Automotive Diagnostic Command Set supports the following services:
• Diagnosis management
• Data transfer
• Saved data transmission (diagnostic error codes)
• Entry/Exit Control
• Remote activation of the routine
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 service-defined parameters. The Positive Response Message has an echo of the ServiceId with bit 6 set as the first byte, plus the service-defined response parameters.
The Negative Response Message is usually 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 a 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 ResponseCode. The KWP2000 standard partially defines the ResponseCodes, but there is still room for manufacturer-specific extensions. KWP2000 defines an error handling procedure for some of the ResponseCodes. Because both positive and negative responses have an echo of the requested service, you can always match the responses to the appropriate request.
Connect/Disconnect
KWP2000 expects a diagnostic session to be started with StartDiagnosticSession and ended with StopDiagnosticSession. However, StartDiagnosticSession has a DiagnosticMode parameter that determines the diagnostic session type. 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 DiagnosticMode parameter values are manufacturer specific and not defined in the standard. For a diagnostic session to remain active, it must run the TesterPresent service periodically when no other service is running. If the TesterPresent service is absent for a period of time, the diagnostic session will be terminated and the ECU will return to normal operating mode.
GetSeed/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. You can run the GetSeed/Unlock mechanism through the SecurityAccess service. This defines several security levels, which the manufacturer assigns to specific services.
read/write memory
Use the Read/WriteMemoryByAddress services to upload/download data to specific memory addresses on an ECU. The address is a three byte size in KWP2000 and a five byte size (four byte address and one byte extension) in the calibration records. The upload/download engine services are highly vendor specific and not well defined in the standard, so they are not a good way to provide a generic 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 variables that are then transmitted from the ECU to the tester. The transmission can be either a single value or periodic, with a slow, medium or fast transmission rate. The transmission rates are manufacturer-specific; You can use the SetDataRates service to set them, but this setting is vendor 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 multiple services that access DTCs based on their group or status.
Entry/Exit Control
KWP2000 defines services to modify internal or external ECU signals. An example is the redirection of ECU sensor inputs to stimulated signals. The control parameters of these commands are manufacturer-specific and not defined in the standard.
Remote activation of a routine
These services are similar to CCP’s ActionService and DiagService capabilities. You can call an ECU internal routine identified by a Local/CommonIdentifier or a memory address. Unlike the CCP case, 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 not defined in the standard.
External references
For more information on the KWP2000 standard, see the ISO 14230-3 standard.