In the realm of automotive diagnostics and communication, the Controller Area Network (CAN) bus stands as a critical backbone, enabling various electronic control units (ECUs) within a vehicle to exchange data. For enthusiasts and professionals working with Volkswagen, Audi Group (VAG) vehicles, understanding the intricacies of Vag Can communication is paramount. While the CAN bus protocol itself allows for data packets up to 8 bytes, transmitting larger messages necessitates a transport protocol. While the OBD-II standard utilizes ISO-TP (ISO 15765-2), Volkswagen employs its proprietary transport protocol known as VW TP 2.0 within its vehicles. This article delves into the workings of VW TP 2.0, shedding light on its mechanisms and significance in VAG diagnostics, making it an essential read for anyone involved in VAG CAN systems.
It’s important to note that VW TP 2.0 isn’t the only transport protocol used by Volkswagen. An earlier version, VW TP 1.6, existed in some older models. While TP 1.6 shares similarities with TP 2.0, certain parameters are fixed. The information presented here is derived from publicly available resources, presentations, online documents, and data logging efforts. As official documentation from VW hasn’t been directly accessed, it’s advisable to consider this information with a degree of caution and cross-reference with other reliable sources when working on critical systems.
Typically, the payload carried by VW TP 2.0 consists of ISO 14230-3, Keyword Protocol 2000 (KWP2000) application layer messages, a common standard in automotive diagnostics.
The Four Message Types of VW TP 2.0
VW TP 2.0 operates by establishing data “channels” between communicating devices within the VAG vehicle’s network. Once a channel is established, data packets can flow between these devices. This process is managed through four distinct message types: Broadcast, Channel Setup, Channel Parameters, and Data Transmission.
1. Broadcast Message
The Broadcast message type is characterized by a fixed length of 7 bytes and is transmitted five times to mitigate potential packet loss. While its precise application remains somewhat unclear, its structure is well-defined:
| Byte | 0 | 1 | 2-5 | 6 |
|---|---|---|---|---|
| Description | Dest | Opcode | KWP Data | Resp Req |
| Field Description | Destination Logical Address | Operation Code | KWP2000 SID and parameters | Response Expectation |
Field Descriptions:
- Dest (Destination Logical Address): Indicates the logical address of the target module, for example,
0x01for the engine control unit (ECU). - Opcode (Operation Code): Defines the message type.
0x23signifies a Broadcast request, and0x24indicates a Broadcast response. - KWP Data (KWP2000 SID and parameters): Carries the KWP2000 Service Identifier (SID) and associated parameters.
- Resp Req (Response Expectation): Determines whether a response is expected.
0x00means a response is expected, while0x55or0xAAindicate no response is anticipated.
2. Channel Setup Message
The Channel Setup message, also 7 bytes in length, is crucial for initiating a data channel between two modules within the VAG CAN network.
The channel setup request message is typically sent from CAN ID 0x200. The response from the destination module will then be sent using CAN ID 0x200 plus the destination module’s logical address. For instance, if the ECU (logical address 0x01) is the target, the response would be sent on CAN ID 0x201.
Following the initial handshake, communication shifts to the CAN IDs negotiated during this channel setup phase. The initiator typically requests the destination module to transmit using CAN IDs within the range of 0x300 to 0x310 and sets the validity nibble for the RX ID to invalid. However, VAG modules commonly respond by indicating that the initiator should transmit using CAN ID 0x740.
| Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|---|
| Description | Dest | Opcode | RX ID | V RX Pref | TX ID | V TX Pref | App |
| Field Description | Destination Logical Address | Operation Code | Receive CAN ID | RX Prefix Validity | Transmit CAN ID | TX Prefix Validity | Application Type |
Field Descriptions:
- Dest (Destination Logical Address): Logical address of the destination module (e.g.,
0x01for ECU). - Opcode (Operation Code):
0xC0denotes a Setup request,0xD0a positive response, and0xD6to0xD8negative responses. - RX ID (Receive CAN ID): Informs the destination module about the CAN ID the initiator will listen on for responses.
- RX Pref (RX ID Prefix): Prefix for the RX ID.
- TX ID (Transmit CAN ID): Specifies the CAN ID the initiator requests the destination module to transmit from.
- TX Pref (TX ID Prefix): Prefix for the TX ID.
- V (Validity): Indicates CAN ID validity.
0x0signifies a valid CAN ID, and0x1means the CAN ID is invalid. - App (Application Type): Application type, generally
0x01, possibly specifically for KWP.
3. Channel Parameters Message
The Channel Parameters message serves to configure parameters for an established channel and to transmit test, break, and disconnect signals. It can be either 1 or 6 bytes in length. Typically, a parameters request is sent immediately after channel setup, utilizing the negotiated CAN IDs.
1-Byte Format:
| Byte | 0 |
|---|---|
| Description | Opcode |
6-Byte Format:
| Byte | 0 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|---|
| Description | Opcode | BS | T1 | T2 | T3 | T4 |
| Field Description | Operation Code | Block Size | Timing Parameter 1 | Timing Parameter 2 | Timing Parameter 3 | Timing Parameter 4 |
Field Descriptions:
- Opcode (Operation Code):
0xA0: Parameters request (6 bytes), from destination module to initiator.0xA1: Parameters response (6 bytes), from initiator to destination module.0xA3: Channel test (1 byte), response is the same as parameters response. Used to maintain channel activity.0xA4: Break (1 byte), receiver discards data since the last ACK.0xA8: Disconnect (1 byte), channel closure. Receiver should reply with a disconnect.
- BS (Block Size): Number of packets sent before expecting an ACK response.
- T1 (Timing Parameter 1): Time to wait for ACK. T1 should be greater than 4*T3.
- T2 (Timing Parameter 2): Typically
0xFF. - T3 (Timing Parameter 3): Interval between consecutive packets.
- T4 (Timing Parameter 4): Typically
0xFF.
Timing Parameter Encoding:
Timing parameters (T1, T3) are encoded with units and scale:
| Bits | 7-6 | 5-4 | 3-2 | 1-0 |
|---|---|---|---|---|
| Description | Units | Scale | – | – |
| Field Description | Time Units | Scaling Factor | – | – |
Timing Units:
| Value | 0x0 | 0x1 | 0x2 | 0x3 |
|---|---|---|---|---|
| Units | 0.1ms | 1ms | 10ms | 100ms |
Scale: Number to multiply the units by.
4. Data Transmission Message
The Data Transmission message, ranging from 2 to 8 bytes, is used to transmit the actual data or payload bytes after successful channel setup and parameter negotiation.
| Byte | 0 | 1 | 2-7 |
|---|---|---|---|
| Description | Op | Seq | Payload |
| Field Description | Operation | Sequence Number | Data Payload |
Field Descriptions:
- Op (Operation):
0x0: Waiting for ACK, more packets to follow (block size limit reached).0x1: Waiting for ACK, last packet in the sequence.0x2: Not waiting for ACK, more packets to follow.0x3: Not waiting for ACK, last packet in the sequence.0xB: ACK, ready for the next packet.0x9: ACK, not ready for the next packet.
- Seq (Sequence Number): Increments from
0x0up to0xFand then wraps around to0x0. - Payload: Carries the KWP2000 payload. Notably, the first two bytes of the initial packet contain the total message length.
Example: VAG Diagnostics – Reading Measuring Block 1 from ECU
This example illustrates the process of opening a channel and reading measuring block 1 from the engine control unit (ECU) in a VAG vehicle using VW TP 2.0. All data values and CAN IDs are in hexadecimal format. This sequence is representative of a typical VAG diagnostic session, and understanding it is crucial for anyone working with VAG CAN tools.
| CAN ID | Data (Bytes) | Format | Description |
|---|---|---|---|
| 200 | 01 C0 00 10 00 03 01 |
Chan setup | Initiate channel setup with ECU module (address 01), request to use CAN ID 0x300 for reception. |
| 201 | 00 D0 00 03 40 07 01 |
Chan setup | ECU module replies, indicating to use CAN ID 0x740 for transmission. |
| 740 | A0 0F 8A FF 32 FF |
Chan param | Tell ECU module to send 16 packets per block (0F), and set timing parameters (T1=0x8A, T2=0xFF, T3=0x32, T4=0xFF). |
| 300 | A1 0F 8A FF 4A FF |
Chan param | ECU module responds with its parameter settings (T1=0x8A, T2=0xFF, T3=0x4A, T4=0xFF). |
| 740 | 10 00 02 10 89 |
Data | Last packet in block (Opcode 0x1), waiting for ACK. Length is 2 bytes. Send KWP2000 startDiagnosticSession request (0x10) with parameter 0x89. |
| 300 | B1 |
Data | ECU sends ACK response (Opcode 0xB). |
| 300 | 10 00 02 50 89 |
Data | Last packet, waiting for ACK. Length 2 bytes. ECU sends KWP2000 positive response to startDiagnosticSession (0x50) with parameter 0x89. |
| 740 | B1 |
Data | Initiator sends ACK response. |
| 740 | 11 00 02 21 01 |
Data | Last packet, waiting for ACK. Length 2 bytes. Send KWP2000 readDataByLocalIdentifier request (0x21) with parameter 0x01 (measuring block 1). |
| 300 | B2 |
Data | ECU sends ACK response. |
| 300 | 21 00 1A 61 01 01 00 00 |
Data | Packet to follow (Opcode 0x2), not waiting for ACK. Length 26 bytes. ECU sends KWP2000 positive response to readDataByLocalIdentifier (0x61) followed by data. |
| 300 | 22 27 00 00 22 00 80 1A |
Data | Packet to follow, not waiting for ACK. KWP2000 data continued. |
| 300 | 23 32 4B 25 02 7A 25 00 |
Data | Packet to follow, not waiting for ACK. KWP2000 data continued. |
| 300 | 14 00 25 00 00 25 00 00 |
Data | Last packet (Opcode 0x1), waiting for ACK. KWP2000 data continued. |
| 740 | B5 |
Data | Initiator sends ACK response. |
| 740 | A8 |
Chan param | Initiator sends disconnect message. |
This detailed example showcases the step-by-step communication flow using VW TP 2.0 for a fundamental VAG diagnostic task. Understanding these message exchanges is crucial for developing or utilizing VAG diagnostic tools and interpreting CAN bus traffic in VAG vehicles.
Practical Applications and VAG Diagnostics
VW TP 2.0 is the backbone for numerous diagnostic and communication procedures within VAG vehicles. From basic fault code reading and clearing to advanced functions like ECU coding, adaptations, and live data monitoring, VW TP 2.0 facilitates the necessary data exchange. Diagnostic tools like VCDS (VAG-COM Diagnostic System), ODIS (Offboard Diagnostic Information System), and other aftermarket VAG diagnostic solutions heavily rely on the principles of VW TP 2.0 to interact with VAG vehicle systems.
For anyone involved in automotive repair, diagnostics, or tuning of VAG vehicles, a solid grasp of VW TP 2.0 is invaluable. It enables a deeper understanding of how VAG vehicles communicate internally and how diagnostic tools interact with them. By understanding the nuances of channel setup, parameter negotiation, and data transmission within VW TP 2.0, professionals and enthusiasts can gain greater control and insight into VAG vehicle electronics.
References
- Vehicular Networks – Protocols Part 1 CAN-based Higher Layer Protocols
- Programming interfaces for embedded networks .. using the example of CAN (German)
- Diagnostics of electronic control units (Czech)
