The KWP2000 protocol is a de facto standard for automotive diagnostic applications. ISO standard 14230-3. The KWP2000 demonstrates 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.
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
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
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: Negative Response ServiceId is the first byte, the original ServiceId is the second source echo, 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
For more information on the KWP2000 standard, see ISO 14230-3.
Source by visit sbobet thailand