VW Transport Protocol 2.0 (TP 2.0) for CAN bus

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.

Byte0123456
DescriptionDestOpcodeKWP DataResp ReqResp Req

Field description

FieldDescription
DestLogical address of destination module, e.g. 0x01 for the engine control unit
Opcode0x23Broadcast request
0x24Broadcast response
KWP DataKWP2000 SID and parameters
Resp Req0x00Response expected
0x55 or 0xAANo 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.

Byte0123456
DescriptionDestOpcodeRX IDVRX PrefTX IDVTX PrefApp

Field description

FieldDescription
DestLogical address of destination module, e.g. 0x01 for the engine control unit
Opcode0xC0Setup request
0xD0Positive response
0xD6..0xD8Negative response
RX IDTells destination module which CAN ID to listen to
RX PrefRX ID Prefix
TX IDTells destination module which CAN ID to transmit from
TX PrefTX ID Prefix
V0x0CAN ID is valid
0x1CAN ID is invalid
AppApplication 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.

Byte0
DescriptionOpcode

OR

Byte012345
DescriptionOpcodeBST1T2T3T4

Field description

FieldDescription
Opcode0xA0Parameters request, used for destination module to initiator (6 byte)
0xA1Parameters respsonse, used for initiator to destination module (6 byte)
0xA3Channel test, response is same as parameters response. Used to keep channel alive. (1 byte)
0xA4Break, receiver discards all data since last ACK (1 byte)
0xA8Disconnect, channel is no longer open. Receiver should reply with a disconnect (1 byte)
BSBlock size, number of packets to send before expecting a ACK response
T1Timing parameter 1, time to wait for ACK. T1 should be greater than 4*T3
T2Timing parameter 2, always 0xFF
T3Timing parameter 3, interval between two packets
T4Timing parameter 4, always 0xFF

Timing parameters

Bits76543210
DescriptionUnitsScale
Field description
FieldDescription
Units0x00.1ms
0x11ms
0x210ms
0x3100ms
ScaleNumber 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.

Byte01234567
DescriptionOpSeqPayload

Field description

FieldDescription
Op0x0Waiting for ACK, more packets to follow (i.e. reached max block size value as specified above)
0x1Waiting for ACK, this is last packet
0x2Not waiting for ACK, more packets to follow
0x3Not waiting for ACK, this is last packet
0xBACK, ready for next packet
0x9ACK, not ready for next packet
SeqSequence number, increments up to 0xF then back to 0x0
PayloadKWP2000 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 IDDataFormatDescription
20001 C0 00 10 00 03 01Chan setupInitiate channel setup with ECU module, request it use CAN ID 0x300
20100 D0 00 03 40 07 01Chan setupECU module replies, says to use CAN ID 0x740
740A0 0F 8A FF 32 FFChan paramTell ECU module to send 16 packets at a time, and set timing parameters
300A1 0F 8A FF 4A FFChan paramECU module responds with its parameters
74010 00 02 10 89DataLast packet, expecting ACK. Length is 2 bytes. Send KWP2000 startDiagnosticSession request 0x10 with 0x89 as a parameter
300B1DataECU sends ACK response.
30010 00 02 50 89DataLast packet, expecting ACK. Length is 2 bytes. ECU sends KWP2000 positive response to startDiagnosticSession
740B1DataWe send ACK response.
74011 00 02 21 01DataLast packet, expecting ACK. Length is 2 bytes. Send KWP2000 readDataByLocalIdentifier request 0x21 with 0x01 as a parameter
300B2DataECU sends ACK response.
30021 00 1A 61 01 01 00 00DataPacket to follow, not expecting ACK. Length is 26 bytes. ECU sends KWP2000 positive response to readDataByLocalIdentifier followed by the requested data
30022 27 00 00 22 00 80 1ADataPacket to follow, not expecting ACK. KWP2000 data continued.
30023 32 4B 25 02 7A 25 00DataPacket to follow, not expecting ACK. KWP2000 data continued.
30014 00 25 00 00 25 00 00DataLast packet, expecting ACK. KWP2000 data continued.
740B5DataWe send ACK response.
740A8Chan paramWe send disconnect.

References

Comments

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,
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,

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.

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 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.

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 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/

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/

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.

Hi Permalik

Could you find some information about VW protocol ? I' m trying read with J1939 protocol, but does't works.

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

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?

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 have had a ton of spam bypassing the captcha on this website so I only just saw your comment.

Add new comment