CAN allows for data packets with a payload of up to 8 bytes, to send messages longer than 8 bytes it is necessary to use a transport protocol. The OBD-II specification for example makes use of ISO-TP (ISO 15765-2). Volkswagen however uses it's own transport protocol in its vehicles, known as VW TP 2.0.
This page gives a run down on how TP 2.0 works. Please note that there is an older VW TP 1.6 which was used in some vehicles. TP 1.6 is fairly similar but some of the parameters are fixed. Its also worth noting that I have worked all of this out from various presentations and documents that I have found on the net and from logging data. I have not had any access to the official documentation from VW so take any information with a grain of salt.
Typically the payload of TP 2.0 will be ISO 14230-3, Keyword Protocol 2000 (KWP2000) application layer messages.
The four message types
TP 2.0 works by opening data "channels" between two communicating devices. Once a channel is opened data packets can be exchanged by the two devices. To do this TP 2.0 uses four message types - broadcast, channel setup, channel parameters and data transmission.
Broadcast
The broadcast type has a fixed length of 7 bytes. It is sent 5 times in case of packet loss. Not sure what it is actually used for yet.
Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
---|---|---|---|---|---|---|---|
Description | Dest | Opcode | KWP Data | Resp Req | Resp Req |
Field description
Field | Description | |
---|---|---|
Dest | Logical address of destination module, e.g. 0x01 for the engine control unit | |
Opcode | 0x23 | Broadcast request |
0x24 | Broadcast response | |
KWP Data | KWP2000 SID and parameters | |
Resp Req | 0x00 | Response expected |
0x55 or 0xAA | No response expected |
Channel setup
The channel setup type has a fixed length of 7 bytes. It is used to establish a data channel between two modules.
The channel setup request message should be sent from CAN ID 0x200 and the response will sent with CAN ID 0x200 + the destination modules logical address e.g. for the engine control unit (0x01) the response would be 0x201.
The communication then switches to using the CAN IDs which were negotiated during channel setup.
You should request the destination module to transmit using CAN ID 0x300 to 0x310 and set the validity nibble for RX ID to invalid. The VW modules seem to respond that you 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
Field | Description | |
---|---|---|
Dest | Logical address of destination module, e.g. 0x01 for the engine control unit | |
Opcode | 0xC0 | Setup request |
0xD0 | Positive response | |
0xD6..0xD8 | Negative response | |
RX ID | Tells destination module which CAN ID to listen to | |
RX Pref | RX ID Prefix | |
TX ID | Tells destination module which CAN ID to transmit from | |
TX Pref | TX ID Prefix | |
V | 0x0 | CAN ID is valid |
0x1 | CAN ID is invalid | |
App | Application type, seems to always be 0x01 (maybe only for KWP) |
Channel parameters
The channel parameters type has a length of 1 or 6 bytes. It is used to setup parameters for an open channel and to send test, break and disconnect signals
You should send a parameters request straight after channel setup using the CAN IDs negotiated.
Byte | 0 |
---|---|
Description | Opcode |
OR
Byte | 0 | 1 | 2 | 3 | 4 | 5 |
---|---|---|---|---|---|---|
Description | Opcode | BS | T1 | T2 | T3 | T4 |
Field description
Field | Description | |
---|---|---|
Opcode | 0xA0 | Parameters request, used for destination module to initiator (6 byte) |
0xA1 | Parameters respsonse, used for initiator to destination module (6 byte) | |
0xA3 | Channel test, response is same as parameters response. Used to keep channel alive. (1 byte) | |
0xA4 | Break, receiver discards all data since last ACK (1 byte) | |
0xA8 | Disconnect, channel is no longer open. Receiver should reply with a disconnect (1 byte) | |
BS | Block size, number of packets to send before expecting a ACK response | |
T1 | Timing parameter 1, time to wait for ACK. T1 should be greater than 4*T3 | |
T2 | Timing parameter 2, always 0xFF | |
T3 | Timing parameter 3, interval between two packets | |
T4 | Timing parameter 4, always 0xFF |
Timing parameters
Bits | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
---|---|---|---|---|---|---|---|---|
Description | Units | Scale |
Field description
Field | Description | |
---|---|---|
Units | 0x0 | 0.1ms |
0x1 | 1ms | |
0x2 | 10ms | |
0x3 | 100ms | |
Scale | Number to scale the units by |
Data transmission
The data transmission type has a length of 2 to 8 bytes. It is used for the transmission of actual data/payload bytes.
Data transmission should only occur after channel setup and parameter negotiation.
Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | |
---|---|---|---|---|---|---|---|---|---|
Description | Op | Seq | Payload |
Field description
Field | Description | |
---|---|---|
Op | 0x0 | Waiting for ACK, more packets to follow (i.e. reached max block size value as specified above) |
0x1 | Waiting for ACK, this is last packet | |
0x2 | Not waiting for ACK, more packets to follow | |
0x3 | Not waiting for ACK, this is last packet | |
0xB | ACK, ready for next packet | |
0x9 | ACK, not ready for next packet | |
Seq | Sequence number, increments up to 0xF then back to 0x0 | |
Payload | KWP2000 payload. The first 2 bytes of the first packet sent contain the length of the message. |
Example
This example shows how to open a channel to and read measuring block 1 from the engine control unit. Data values and the CAN IDs are in hex.
CAN ID | Data | Format | Description |
---|---|---|---|
200 | 01 C0 00 10 00 03 01 | Chan setup | Initiate channel setup with ECU module, request it use CAN ID 0x300 |
201 | 00 D0 00 03 40 07 01 | Chan setup | ECU module replies, says to use CAN ID 0x740 |
740 | A0 0F 8A FF 32 FF | Chan param | Tell ECU module to send 16 packets at a time, and set timing parameters |
300 | A1 0F 8A FF 4A FF | Chan param | ECU module responds with its parameters |
740 | 10 00 02 10 89 | Data | Last packet, expecting ACK. Length is 2 bytes. Send KWP2000 startDiagnosticSession request 0x10 with 0x89 as a parameter |
300 | B1 | Data | ECU sends ACK response. |
300 | 10 00 02 50 89 | Data | Last packet, expecting ACK. Length is 2 bytes. ECU sends KWP2000 positive response to startDiagnosticSession |
740 | B1 | Data | We send ACK response. |
740 | 11 00 02 21 01 | Data | Last packet, expecting ACK. Length is 2 bytes. Send KWP2000 readDataByLocalIdentifier request 0x21 with 0x01 as a parameter |
300 | B2 | Data | ECU sends ACK response. |
300 | 21 00 1A 61 01 01 00 00 | Data | Packet to follow, not expecting ACK. Length is 26 bytes. ECU sends KWP2000 positive response to readDataByLocalIdentifier followed by the requested data |
300 | 22 27 00 00 22 00 80 1A | Data | Packet to follow, not expecting ACK. KWP2000 data continued. |
300 | 23 32 4B 25 02 7A 25 00 | Data | Packet to follow, not expecting ACK. KWP2000 data continued. |
300 | 14 00 25 00 00 25 00 00 | Data | Last packet, expecting ACK. KWP2000 data continued. |
740 | B5 | Data | We send ACK response. |
740 | A8 | Chan param | We send disconnect. |
Comments
Protocol Can-TP2.0
Dear Sir,
I'm looking for a documentation of Protocol Can-TP2.0? do you have it and can you offer it?
Have you implemented protocol Can-TP2.0? would like to sell software?
Please send me information.
Hi,
Hi,
Thanks to your post I coded an TP2.0 and KWP2000 stack and implemented a simple diagnostic adaptor. My info on my blog http://jas-hacks.blogspot.co.uk/2017/01/imx6sx-prototype-vw-vag-vehicle.... .
Dear Friend,
Dear Friend,
I am experimenting with TP2.0 implementation, but I can not find information on which vehicles this protocol is actually used. Could you tell me exactly which model(s) use TP2.0. I would then buy some used ECUs to test on. Thank you.
Communication between control units
Hi Jared,
thanks for this informative article! I'm presently trying to build a simple CAN bus emulator whose specific task it will be to feed some data (ignition, ACC switch, speed...) to a VW radio (the RNS210) and make it think that it's connected to a vehicle with CAN. Do you know if the documentation you provided here will be at all helpful? It seems that TP2.0 and the payload specifications (KWP2000) are aimed at performing vehicle diagnostics and not for communication between ECUs.
I'm not all that sure how to approach my particular problem yet. I'd assume that the central electrics control module (Unit ID 09) probably broadcasts some general vehicle information such as ignition status, speed, dashboard illumination intensity and so on at regular intervals and those ECUs which need this information simply read it but I could be wrong.
Thanks a lot!
Its been an age since I've
Its been an age since I've look at any of this stuff, but for my car at least TP 2.0 was definitely the transport protocol used everywhere on the CAN bus including to the radio.
I think you are right that some of the data is broadcast on the infotainment network but I'm not sure its in KWP format.
Read VAG DTCs using elm 327 and Hyperterminal
I am using PuTTY (similar to hyperterminal) and an elm 327 device for reading DTCs in my VW Polo 2013 model, but have not made progress because I couldn't get past the initialization step. The commands that I send to the elm327 device is
AT SH 200 (I get reply as 'OK')
01 C0 00 10 00 03 01
and the reply I get is 'NO DATA'.
Can someone please help me get the complete list of AT commands that I should send to a VAG car to start reading DTCs.
Hi, I coded an app that
Hi, I coded an app that communicate with car dashboard via elm327:
https://apps.apple.com/om/app/vag-virtual-cockpit/id1468103297
At first you need to setup elm327 to send and receive CAN commands:
atz
at e0 // disable echo
at l0 // disable new line
at sh 714 // CAN Response Address
at cra 77e // CAN Receive Address
at fc sh 714 // Flow control for ID 714
at fc sd 30 00 00 // data to flow control
at fc sm 1 // Flow Control mode when user set id and data
at al // accept messages more than 7 bytes
at sp 6 // ISO 15764-4 CAN (11 bit ID, 500kbaud)
at ca f0 // CAN auto formating off
Then you can send CAN requests
03 22 22 0d 55 55 55 55 // get oil temp
05 62 22 0D 55 65 AA AA // response
About VAG Virtual Cockpit project:
https://habr.com/ru/post/442184/
ELM327
Hi, I coded an app that communicate with car dashboard via elm327:
https://apps.apple.com/om/app/vag-virtual-cockpit/id1468103297
At first you need to setup elm327 to send and receive CAN commands:
atz
at e0 // disable echo
at l0 // disable new line
at sh 714 // CAN Response Address
at cra 77e // CAN Receive Address
at fc sh 714 // Flow control for ID 714
at fc sd 30 00 00 // data to flow control
at fc sm 1 // Flow Control mode when user set id and data
at al // accept messages more than 7 bytes
at sp 6 // ISO 15764-4 CAN (11 bit ID, 500kbaud)
at ca f0 // CAN auto formating off
Then you can send CAN requests
03 22 22 0d 55 55 55 55 // get oil temp
05 62 22 0D 55 65 AA AA // response
About VAG Virtual Cockpit project:
https://habr.com/ru/post/442184/
PID
Hi Jared,
thanks for this informative article! I'm presently trying to build a simple CAN bus emulator whose specific task it will act as diagnostic tools. I am using Raspberry Pi with Python language but the PID format in VW is not similar to other protocol. If I want to explain more, for example, the request that sent by the tester for reading DTC is similar but the respond from ECU is not similar. I really appreciate you if you give me some comments on this issue.
VW protocol
Hi Permalik
Could you find some information about VW protocol ? I' m trying read with J1939 protocol, but does't works.
How single frame is handled
Thanks for the article, Can you please explain how single frame is transmitted by ECU when the payload is less than or equal to 7 bytes ? Thanks, Anil
Dear sir or madam
Dear sir or madam
Hello
I'm an Iranian student from shahid beheshti university and I need your car's sensors can ids for my project.would you mind helping me with that please?
Dear sir or madam
Hello
I'm an Iranian student from shahid beheshti university and I need your car's sensors can ids for my project.would you mind helping me with that please?
Pingback / OVMS TP2.0 implementation
Hi Jared,
just wanted to give you a pingback for your incredible work. I've implemented TP2.0 support for the OVMS based on your protocol description. Hope you don't mind I've added a text version of your document to the OVMS tree:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/ma...
Protocol implementation is here:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/ma...
Regards,
Michael
Thanks! No problem at all. I
Thanks! No problem at all. I have had a ton of spam bypassing the captcha on this website so I only just saw your comment.
Add new comment