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 follow with the protocol. You can run KWP2000 on several transport layers such as K-line (serial) or CAN.
Because KWP2000 uses variable byte message lengths, a storage protocol is required with only a well-defined (short) message length, such as CAN. The transport protocol divides a long KWP2000 message into bits that can be transmitted over the network and puts them together to restore 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, Automotive Diagnostic Command Set only supports ISO TP (standardized in ISO 15765-2) and manufacturer-specific VW TP 2.0 transport protocols.
The diagnostic services available in KWP2000 are grouped into functional units and identified by a single-byte (ServiceId) code. 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. Automotive Diagnostic Command Set supports the following services:
• Diagnostic management
• Data transfer
• Stored data transfer (diagnostic problem codes)
• Input / output control
• Remote activation of routine
Upload / Download and Extended Services are not included in the Automotive Diagnostic Command Set.
Diagnostic service format
Diagnostic services have a common message format. Each service defines an inquiry message, positive response message and negative response message. Inquiry The message has ServiceId as the first byte, plus additional service-defined parameters. Positive response message has an echo of ServiceId with bit 6 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 service id as the first byte, an echo of the original service id as the second byte, and a response code 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 ResponseCode. The KWP2000 standard partially defines ResponseCodes, but there is still room for manufacturer-specific extensions. For some of the ResponseCodes, KWP2000 defines an error management procedure. Since both positive and negative responses have an echo of the requested service, you can always assign the answers to their corresponding request.
Connect / Disconnect
KWP2000 expects a diagnostic session to start with StartDiagnosticSession and ends with StopDiagnosticSession. However, StartDiagnosticSession has a DiagnosticMode parameter that determines the type of diagnostics. Depending on this type, the ECU may or may not support other diagnostic services or operate in a limited mode where not all EC functions are available. The DiagnosticMode parameter values are the manufacturer's specific and not defined in the standard. In order for a diagnostic session to remain active, it must perform the TesterPresent service periodically if no other service is performed. If the TesterPresent service is missing for a certain period, the diagnostic period ends and the ECU returns to normal operating mode.
GetSeed / Unlock
A GetSeed / Unlock mechanism can protect some diagnostic services. However, the applicable services are provided to the manufacturer and are not defined by the standard. You can perform the GetSeed / Unlock mechanism through the SecurityAccess service. This defines several security levels, 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 of one ECU. The address is a three-byte quantity in KWP2000 and a fembyte quantity (four byte address and one byte extension) in the calibration protocols. Feature upload / download features are very specific manufacturers and not well-defined in the standard, so they are not a good way to provide a general upload / download mechanism.
Use the ReadDataByLocal / CommonIdentifier services to access ECU data in the same way as a DAQ list. A local / commonIdentifier describes a list of ecu quantities that are then transferred from the ECU to the tester. The transmission can be either single or periodic, with slow, medium or fast transmission rate. The transfer rates are the manufacturer's specific; You can use the SetDataRates service to set them, but this setting is the manufacturer's specific. Automotive Diagnostic Command Set supports single point measurements.
Diagnostic problem codes
An important diagnostic feature is the reading of diagnostic problem codes (DTCs). KWP2000 defines multiple services as access to DTCs based on their group or status.
Input / output control
KWP2000 defines services for changing internal or external echo signals. One example is to redirect the ECU sensor's inputs to stimulated signals. The control parameters for these commands are the manufacturer's specific and not defined in the standard.
Remote activation of a routine
These services are similar to CCP's ActionService and DiagService features. You can invoke an internal internal routine identified by a Local / CommonIdentifier or a memory address. In contrast to the CCP case, the execution of this routine may be asynchronous; that is, there are separate Start, Stop and RequestResult services. The control parameters for these commands are the manufacturer's specific and not defined in the standard.
More information about the KWP2000 standard is available in the ISO 14230-3 standard.