The KWP2000 protocol for automotive diagnostic applications

The KWP2000 protocol is a de facto standard for automotive diagnostic applications. ISO standard 14230-3. KWP2000 describes the implementation of various diagnostic services that can be overridden by the protocol. You can run KWP2000 on multiple transport layers, such as K-Line (Serial) or CAN.

Transport Protocol

Because KWP2000 uses variable byte length messages, a delivery protocol with only well-defined (short) message length layers, such as CAN, is required. The transport protocol delivers a long long KWP2000 message to pieces that can be transmitted over the network and assembles these pieces to restore the original message.

KWP2000 runs on different CAN protocols, such as ISO TP (ISO 15765-2), TP 1.6, TP2.0 (Volkswagen), and SAE J1939-21. For KWP2000, the Automotive Diagnostic Command Set only supports ISO TP (ISO 15765-2) and manufacturer-specific VW TP 2.0 transport protocols

Diagnostic Services

The diagnostic features available in KWP2000 can be grouped in functional units and identified by a byte code (ServiceId). The standard does not specify all the 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 features:

• Diagnostic Management

• Data Transmission

• Stored Data Transfer (Diagnostic Trouble Codes)

• Input / output control

• Routine

upload / download and extended services are not part of the Diagnostic Service Format of the Automotive Diagnostic Command Set

Diagnostic services have a common message format. All services define a request message, positive response messages, and negative response messages. The Request Message contains ServiceId as the first byte, complemented by parameters defined by the service. The positive response message echoes ServiceId's bits 6 set in the first byte and the response parameters defined by the service

The negative response message is usually a three byte message: the Negative Response ServiceId is the first byte, the original ServiceId echoes as the second source, and ResponseCode as the third byte. The only exception to this format is the negative response to EscapeCode; here, the third byte is the echo of the user-defined service code, and the fourth byte is the ResponseCode. The KWP2000 standard partially defines ResponseCode, but there is still room for manufacturer-specific extensions. For some response codes, the KWP2000 defect management procedure is defined. Since both positive and negative responses reflect the echo of the requested service, you can always answer replies to the right request.

Connection / Interrupt

KWP2000 expects to start a diagnostic session with StartDiagnosticSession and terminate with StopDiagnosticSession. However, StartDiagnosticSession has a diagnostic mode parameter that specifies the type of diagnostic session. Depending on the type, the ECU can support other diagnostic features or operate in limited mode if not all ECU functions are available. Values ​​for the DiagnosticMode parameters are manufacturer-specific and are not defined in the standard. If the diagnostic workflow remains active, you must perform TesterPresent on a regular basis if no other service is performed. If the TesterPresent service is missing for a certain period, the diagnostic session stops and the ECU returns to normal mode

GetSeed / Unlock

The GetSeed / Unlock mechanism can protect some diagnostic features. However, the services to be used are left out by the manufacturer and are not specified by the standard. GetSeed / Unlock can be implemented through SecurityAccess. This defines a number of security levels but the manufacturer can assign these levels to certain services

Read / Write Memory

Read / WriteMemoryByAddress allows you to upload / download data to each memory address of an ECU. The address is a three byte amount in KWP2000 and a 5 bytes (four byte address and one byte extension) in calibration protocols. The services of upload / download functional units are largely manufacturer-type and are not well-defined in the standard and are therefore not a good way to provide a general upload / download mechanism.


With ReadDataByLocal / CommonIdentifier you can access ECU data in the same way as a DAQ list. Local / CommonIdentifier describes a list of ECU quantities that are transmitted from the ECU to the tester. Transmission can be either single or periodic, slow, medium or fast. Transmission charges are specific to the manufacturer; you can set them using SetDataRates, but this setting is manufacturer-specific. The Automotive Diagnostic Command Set supports single point measurements.

Diagnostic Trouble Codes

The most important diagnostic feature is reading diagnostic trouble codes (DTCs). KWP2000 defines services that have access to DTCs based on their group or status.

Input / output control

KWP2000 defines services for modifying internal or external ECU signals. One example is the redirection of the ECU sensor inputs to the stimulated signals. The control parameters for these commands are manufacturer-specific and are not defined in the standard.

Routine Remote Operation

These services are similar to those of CCP ActionService and DiagService. The ECU identified by the Local / CommonIdentifier can call an internal procedure or a memory address. Contrary to CCP, routine implementation can be asynchronous; ie, there is a separate Start, Stop, and RequestResult service. 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 ISO 14230-3.

Source by sbobet

Leave a Reply

Your email address will not be published. Required fields are marked *