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.


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.

DescriptionDestOpcodeKWP DataResp ReqResp Req

Field description

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.

DescriptionDestOpcodeRX IDVRX PrefTX IDVTX PrefApp

Field description

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.




Field description

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

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


Field description

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.


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.



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.

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.

Add new comment