The KWP2000 Protocol in Automotive Diagnostic Purposes


The KWP2000 protocol has change into a de facto customary in automotive diagnostic purposes. It’s standardized as ISO 14230-Three. KWP2000 describes the implementation of varied diagnostic companies you’ll be able to accethrough the protocol. You’ll be able to run KWP2000 on a number of transport layers akin to Okay-line (serial) or CAN.

Transport Protocol

As KWP2000 makes use of messages of variable byte lengths, a transport protocol is important on layers with solely a properly outlined (quick) message size, akin to CAN. The transport protocol splits a protracted KWP2000 message into items that may be transferred over the community and reassembles these items to recuperate the unique message.

KWP2000 runs on CAN on varied transport protocols akin to ISO TP (ISO 15765-2), TP 1.6, TP 2. zero (Volkswagen), and SAE J1939-21. For KWP2000, the Automotive Diagnostic Command Set helps solely the ISO TP (standardized in ISO 15765-2) and manufacturer-specific VW TP transport protocols.

Diagnostic Companies

The diagnostic companies obtainable in KWP2000 are grouped in purposeful items and recognized by a one-byte code (ServiceId). The usual doesn’t outline all codes; for some codes, the usual refers to different SAE or ISO requirements, and a few are reserved for manufacturer-specific extensions. The Automotive Diagnostic Command Set helps the next companies:

• Diagnostic Administration

• Information Transmission

• Saved Information Transmission (Diagnostic Bother Codes)

• Enter/Output Management

• Distant Activation of Routine

Add/Obtain and Prolonged companies are usually not a part of the Automotive Diagnostic Command Set.

Diagnostic Service Format

Diagnostic companies have a typical message format. Every service defines a Request Message, Constructive Response Message, and Damaging Response Message. The Request Message has the ServiceId as first byte, plus further service-defined parameters. The Constructive Response Message has an echo of the ServiceId with bit 6 set as first byte, plus the service-defined response parameters.

The Damaging Response Message is often a three-byte message: it has the Damaging Response ServiceId as first byte, an echo of the unique ServiceId as second byte, and a ResponseCode as third byte. The one exception to this format is the destructive response to an EscapeCode service; right here, the third byte is an echo of the user-defined service code, and the fourth byte is the ResponseCode. The KWP2000 customary partly defines the ResponseCodes, however there’s room left for manufacturer-specific extensions. For among the ResponseCodes, KWP2000 defines an error dealing with process. As a result of each constructive and destructive responses have an echo of the requested service, you’ll be able to at all times assign the responses to their corresponding request.


KWP2000 expects a diagnostic session to be began with StartDiagnosticSession and terminated with StopDiagnosticSession. Nonetheless, StartDiagnosticSession has a DiagnosticMode parameter that determines the diagnostic session kind. Relying on this kind, the ECU could or could not assist different diagnostic companies, or function in a restricted mode the place not all ECU capabilities can be found. The DiagnosticMode parameter values are producer particular and never outlined in the usual. For a diagnostic session to stay energetic, it should execute the TesterPresent service periodically if no different service is executed. If the TesterPresent service is lacking for a sure time frame, the diagnostic session is terminated, and the ECU returns to regular operation mode.


A GetSeed/Unlock mechanism could defend some diagnostic companies. Nonetheless, the relevant companies are left to the producer and never outlined by the usual.You’ll be able to execute the GetSeed/Unlock mechanism via the SecurityAccess service. This defines a number of ranges of safety, however the producer assigns these ranges to sure companies.

Learn/Write Reminiscence

Use the Learn/WriteMemoryByAddress companies to add/obtain information to sure reminiscence addresses on an ECU. The tackle is a three-byte amount in KWP2000 and a five-byte amount (four-byte tackle and one-byte extension) within the calibration protocols. The Add/Obtain purposeful unit companies are extremely producer particular and never properly outlined in the usual, so they don’t seem to be a great way to supply a normal add/obtain mechanism.


Use the ReadDataByLocal/CommonIdentifier companies to entry ECU information in a manner just like a DAQ listing. A Native/CommonIdentifier describes an inventory of ECU portions which can be then transferred from the ECU to the tester. The switch could be both single worth or periodic, with a sluggish, medium, or quick switch fee. The switch charges are producer particular; you need to use the SetDataRates service to set them, however this setting is producer particular. The Automotive Diagnostic Command Set helps single-point measurements.

Diagnostic Bother Codes

A serious diagnostic function is the readout of Diagnostic Bother Codes (DTCs). KWP2000 defines a number of companies that entry DTCs based mostly on their group or standing.

Enter/Output Management

KWP2000 defines companies to switch inner or exterior ECU alerts. One instance is redirecting ECU sensor inputs to stimulated alerts. The management parameters of those instructions are producer particular and never outlined in the usual.

Distant Activation of a Routine

These companies are just like the ActionService and DiagService capabilities of CCP. You’ll be able to invoke an ECU inner routine recognized by a Native/CommonIdentifier or a reminiscence tackle. Opposite to the CCP case, execution of this routine could be asynchronous; that’s, there are separate Begin, Cease, and RequestResult companies. The management parameters of those instructions are producer particular and never outlined in the usual.

Exterior References

For extra details about the KWP2000 Commonplace, confer with the ISO 14230-Three customary.