UDS SID2E & SID22

UDS SID2E & SID22

在SID2E和SID22中是否存在整帧长度会超过7字节的情况?

如果是,那么它将如何发送或写入数据字节?

是的,对 SID 0x22 (ReadDataByIdentifier) 的响应或对 SID 0x2E (WriteDataByIdentifier) 的请求长度超过 7 个字节是 UDS 中的常见用例。为此,由多个 CAN 帧组成的消息是 发送,利用传输层 (ISO-TP, ISO 15765-2)。

考虑一个普通的单帧消息,其中第一个字节的高半字节是 0x0

0x7E0   0x03 0x22 0xF1 0x90
0x7E8   0x04 0x62 0xF1 0x90 0x01

这里的有效载荷在7个字节以内(在请求和响应中),所以第一个字节的低半字节告诉我们确切的长度(请求中的0x03,在请求中的0x04响应)。由于完整的消息适合单个 CAN 帧,因此不需要其他任何东西。但是要发送更长的诊断消息,需要将其拆分为多个 CAN 帧(分段)。为此,需要 3 种不同类型的消息:

  1. 一个第一帧被发送到接收器开始传输。 这包含完整有效负载的长度(最多 4095 字节) 数据和消息的前 6 个字节。的高半字节 0x1 第一个字节表示消息是第一帧。
  2. 一个流量控制帧确认接收到第一帧是 回复第一帧的发件人。它包含额外的 预期的 STmin 时间和块大小等信息。这 第一个字节的高半字节 0x3 表示消息是 流量控制帧。
  3. 一个或多个连续帧被发送到接收方,这 包含最多 7 个字节的剩余有效载荷 - 连同 计数器以确保可以按正确的顺序对数据进行分段。 第一个字节的高半字节 0x2 表示消息是 一个连续的帧。

现在考虑以下场景:测试器应用程序发送单帧 0x7E0 0x03 0x22 0xF1 0x90 作为请求。 ECU 可能希望将响应 0x62 0xF1 0x90 0x01 0x02 0x03 0x04 0x05(8 字节有效负载)发送到测试器应用程序。

  1. 所以ECU会先发送第一帧

0x7E8 0x10 0x08 0x62 0xF1 0x90 0x01 0x02 0x03

  1. 并等待来自测试器应用程序的 流控制帧

0x7E0 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00

  1. 然后ECU会继续发送连续帧直到 完整消息已传输:

0x7E8 0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00

对于 SID 0x2E (WriteDataByIdentifier) 将非常相似,只是角色互换,因为测试应用程序通常希望在请求中发送长消息,而 ECU 将回复流量控制信息。即

0x7E0   0x10 0x08 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8   0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0   0x21 0x04 0x05 0x00 0x00 0x00 0x00 0x00
0x7E8   0x03 0x6E 0xF1 0x90 0x00 0x00 0x00 0x00

如果需要多个连续帧,第一个字节将简单地从0x21增加到0x2F,然后再次从0x20开始计数。

0x7E0   0x10 0x76 0x2E 0xF1 0x90 0x01 0x02 0x03
0x7E8   0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x7E0   0x21 0x04 0x05 0x06 0x07 0x08 0x09 0x0A
0x7E0   0x22 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11
...
0x7E0   0x2F 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
0x7E0   0x20 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF