首页 > 解决方案 > 不明白为什么 UDS 长度对我来说似乎是错误的

问题描述

我正在学习 UDS,在此过程中我遇到了从汽车记录的这个数据框

Tester,02 10 01 
Car.  ,10 18 50 01 AA AA AA AA  
Tester,30 00 00 .. FLOW CONTROL  
Car.  ,21 AA AA AA AA AA AA AA  
Car.  ,22 AA AA AA AA AA AA AA  
Car.  ,23 AA AA AA AA 00 00 00  

我不明白的是:测试帧中的长度是 2,后跟两个字节,这是正确的。请注意,函数和子函数都计入长度。但是在测试仪中,长度是 18,但是当我计算字节数(在我的示例中为 AA)时,它们是 22 字节,不包括肯定响应和子功能,如果我们包含它们,它将变为 24。ISO-TP 中的长度也是如此只参考以下帧而不是第一个?因为如果我们不计算包含位置消息的第一帧,那么 AA 字节的长度为 18。

另外,有人可以指导我到一个实现UDS的好库(现在最好是Python,因为我仍在学习过程中),因为我只是在做所有硬编码的事情,而且我不喜欢我最终得到的混乱.

标签: pythonprotocolscan-busdiagnosticsautomotive

解决方案


消息中的长度是正确的 - 它是在完整的有效负载上计算的:包括 SID、子功能等,但不包括:

  • 长度本身
  • 控制信息(即连续帧计数器)
  • 最后的填充(即 0x00)

在单帧中,长度仅占用 1 个字节,而在第一帧中,长度本身占用 12 位(因此占用 2 个字节,包括控制信息 0x1 以表明帧类型为第一帧)。

Car.  ,10 18 50 01 AA AA AA AA  
Tester,30 00 00 .. FLOW CONTROL  
Car.  ,21 AA AA AA AA AA AA AA  
Car.  ,22 AA AA AA AA AA AA AA  
Car.  ,23 AA AA AA AA 00 00 00  

在您的示例中,第一帧的长度为 0x18 - 第一帧的前 2 个字节(0x10、0x18)不计入长度。因此,如果您计算从 0x50 开始且不包括连续帧计数器(0x21、0x22、0x23、...)的字节:

      0x50, 0x01, 0xAA, 0xAA, 0xAA, 0xAA,
0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA 
0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA 
0xAA, 0xAA, 0xAA, 0xAA

正好有 24 个字节(十六进制的 0x18 个字节)。

在 Python 中,您可以使用udsoncan库来获取基于 UDS 服务的抽象,或者使用python-can-isotp来为您处理传输层。


推荐阅读