Source: jazdw
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. |
Тож самое но по русски
Источник: тут
VW Transport Protocol 2.0 (TP 2.0) for CAN bus
CAN позволяет передать пакет данных до 8-ми байт, чтобы отправить сообщение длиннее 8 байт необходимо использовать транспортный протокол. Например, OBD-II спецификация использует ISO-TP (ISO 15765-2). Однако, Volkswagen использует на своих автомобилях собственный транспортный протокол, известный как VW TP 2.0.
Эта страница дает краткое изложение о том, как работает TP 2,0. Пожалуйста, обратите внимание, что есть более старый протокол VW TP 1.6, который использовался в некоторых автомобилях. TP 1.6 очень похож, но некоторые параметры фиксированы. Также стоит отметить, что я выработал все это из различных презентаций и документов, которые я нашел в сети. У меня не было доступа к официальной документации от VW, поэтому вся информация может быть не точной.
TP 2.0 это ISO 14230-3, Протокол 2000 (KWP2000).
Четыре типа сообщений
TP 2.0 работает путем открытия данных "каналы" между двумя взаимодействующими устройствами. Как только канал открыт, два устройства могут обмениваться данными. Для этого используются четыре типа сообщений -
- трансляция,
- настройка каналов,
- параметры каналов,
- передача данных.
1. Трансляция
Тип трансляции имеет фиксированную длину 7 байт. Отправляется 5 раз в случае потери пакетов. Не уверен, что это на самом деле используется до сих пор.
| Byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|---|
| Description | Dest | Opcode | KWP Data | Resp Req | Resp Req | ||
Описание полей
| Поле | Описание | |
|---|---|---|
| Dest | Логический адрес модуля назначения, например 0x01 для Блока Управления Двигателем. | |
| Opcode | 0x23 | Запрос трансляции |
| 0x24 | Ответ трансляции | |
| KWP Data | KWP2000 SID and parameters | |
| Resp Req | 0x00 | С ожиданием ответа |
| 0x55 or 0xAA | Без ожидания ответа | |
2. Настройка канала
Тип установки канал имеет фиксированную длину 7 байт. 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. |
Source: now
CAN FD
The improved CAN data link layer protocol (also known as CAN FD) uses a second higher bit-rate in the data-phase (see Figure 1). In the arbitration phase and the ACK phase, the bit-rate is still limited to 1 Mbit/s depending on the network overall length. The in-bit-time detection is limited by the internal transceiver delays and the bus-line delay, which shall be smaller than the time segment before the sample-point (TSEG1). The “free” transmission in the data phase is limited by the transceiver-internal low-pass filter capability. In addition, the data-field as has been prolonged to up to 64 byte. Both improvements lead to higher throughputs in CAN networks. The improved efficiency (frame overall length divided by the payload) combined with the higher speed increases the throughput significantly
To distinguish between the classic CAN data frame and the improved CAN data frame, one of the reserved bits is used (EDL = extended data length). In order to code the larger payloads (data-fields with more than 8 byte), the remaining DLC (data length code) bit combinations are used. Data field length of 12, 16, 20, 24, 32, 48, and 64 are supported additionally. The control field comprises additional bits (see Figure 2). The RTR bit is reserved, meaning that there is no improved CAN remote frame. The EDL bit substituting the r1 in the classic CAN data frame is transmitted recessively indicating that the following bits shall be interpreted according to the improved CAN protocol. The next bit is reserved followed by the BRS (bit rate switch) bit. The BRS bit is used to switch to the higher configured bit-rate. The next bit (ESI = error state indicator) informs, if the transmitter is in error active (dominant) or error passive (recessive) state.
SOF = Start of frame (bit is always of dominant state)
ID = Identifier (frame priority and content indication)
RTR = Remote transmission request (dominant, if data frame)
IDE = ID extension (dominant for base frame format)
EDL = Extended data length (recessive, if data field is longer than 8 byte)
r0/1 = reserved bit BRS = Bit rate switch (recessive, if switched to alternate bit-rate)
ESI = Error state indicator (recessive, if transmitting node is in error passive state)
DLC = Data length code (indicates the length of the following data field)
CRC = Cyclic redundancy check (15-bit, 17-bit, or 21-bit)
D = Delimiter of CRC/ACK field (bit is always of recessive state)
ACK = Acknowledgment slot (correctly receiving node sends a dominant bit)
EOF = End of frame (all bits are always of recessive state)
IFS = Inter-frame space (the first two bits are always of recessive state)
IDLE = bus is in recessive state
In order to keep the reliability of the classic CAN protocol, the CRC polynomial are changed. The introduced 17-bit CRC polynomial is used for improved CAN data frames up to 16-byte payloads. For larger frames, the 21-bit CRC polynomial is used. This means the improved CAN controllers supporting the classic and the improved CAN protocol starts all three CRC polynomials. If the bit following the IDE bit is recessive, the classic 15-bit CRC polynomial is discontinued. After processing the DLC bits, the CAN controller stops calculating one of the other CRC polynomials. The improved CAN protocol is backwards compatible. This means, the support the classic CAN data and remote frames. However, if a CAN controller supporting just the classic CAN protocol sees an improved CAN data frame, it will send error flags. Therefore migration paths are necessary. One option is the usage of partial networking. Another is to separate nodes in two independent CAN network segments. It is also possible, to set the classic CAN controllers in listen-only mode.
