The KWP2000 Protocol in Automotive Diagnostic Applications

[ad_1]

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 you can accethrough the protocol. You can run KWP2000 on several transport layers such as K-line (serial) or CAN.

Transport Protocol

As KWP2000 uses messages of variable byte lengths, a transport protocol is necessary on layers with only a well defined (short) message length, such as CAN. The transport protocol splits a long KWP2000 message into pieces that can be transferred over the network and reassembles those pieces 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 the ISO TP (standardized in ISO 15765-2) and manufacturer-specific VW TP 2.0 transport protocols.

Diagnostic Services

The diagnostic services available in KWP2000 are grouped in 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

• Stored Data Transmission (Diagnostic Trouble Codes)

• Input/Output Control

• Remote Activation of 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, Positive Response Message, and Negative Response Message. The Request Message has the ServiceId as first byte, plus additional service-defined parameters. The Positive Response Message has an echo of the ServiceId with bit 6 set as 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 first byte, an echo of the original ServiceId as second byte, and a ResponseCode as 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 partly defines the ResponseCodes, but there is room left for manufacturer-specific extensions. For some of the ResponseCodes, KWP2000 defines an error handling procedure. Because 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 be started with StartDiagnosticSession and terminated 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 execute the TesterPresent service periodically if no other service is executed. If the TesterPresent service is missing for a certain period of time, the diagnostic session is terminated, and the ECU returns to normal operation mode.

GetSeed/Unlock

A GetSeed/Unlock mechanism may protect some diagnostic services. However, the applicable services are left to the manufacturer and not defined by the standard.You can execute the GetSeed/Unlock mechanism through the SecurityAccess service. 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 three-byte quantity in KWP2000 and a five-byte quantity (four-byte address and one-byte extension) in the calibration protocols. The Upload/Download functional unit services are highly manufacturer 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 in a way 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 either single value or periodic, with a slow, medium, or fast transfer rate. The transfer rates are manufacturer specific; you can use the SetDataRates service to set them, but this setting is manufacturer specific. The Automotive Diagnostic Command Set supports single-point measurements.

Diagnostic Trouble Codes

A major diagnostic feature is the readout of Diagnostic Trouble Codes (DTCs). KWP2000 defines several services that access DTCs based on their group or status.

Input/Output Control

KWP2000 defines services to modify internal or external ECU signals. One example is redirecting 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 the ActionService and DiagService functions of CCP. You can invoke an ECU internal routine identified by a Local/CommonIdentifier or a memory address. Contrary to 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 about the KWP2000 Standard, refer to the ISO 14230-3 standard.

[ad_2]

Source by Amos Huang