KWP2000 protocol is 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 divides the long KWP2000 message into pieces that can be transmitted over the network and assembles these pieces to restore the original message.
KWP2000 runs on different transport protocols on CAN, 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 only supports ISO TP (Standardized ISO 15765-2) and manufacturer-specific VW TP 2.0 transport protocols.
Diagnostic Services
The diagnostic features available in KWP2000 are 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 Remote Control
Charging / Downloading and Upgrading Not Included in the Automotive Diagnostic Command Set
Diagnostic Service Format
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 echo of the positive response message is ServiceId, bit 6 in the first byte, and the response parameters defined by the service.
A negative response message is usually a three byte message: negative response as first byte, original ServiceId as second source echo, and ResponseCode as 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 have the echo of the requested service, you can always assign answers to the right request.
Connection / Disconnection
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 this type, the ECU can support other diagnostic features or may work in limited mode where 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 TesterPresent 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 highly manufacturer-type and are not well-defined in the standard and are therefore not a good way to provide a general upload / download mechanism.
Measurements
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 Amos Huang