车辆控制单元诊断系统开发 --- UDS 诊断数据流解析

车辆控制单元诊断系统开发--- UDS 诊断数据流解析

屌丝小蚂蚁

4 个月前

之前在专栏里面写过一篇关于UDS诊断协议的介绍，对比于专栏文章的热度与一位朋友的咨询，决定在上篇文章的基础上，对UDS诊断协议开发进行进一步的解析。

UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构

CAN Message = CAN ID + CAN DATA

CAN ID 分为标准与扩展，两种类型，具体大家可以百度，百度上老多了。

在UDS的协议里面ID 的类型并没有对其进行具体的定义，可以根据自己的需求进行自己定义，在Autosar里面是个两个配置变量，一个配置ID值，一个配置ID类型，大家自己配置一下就可以，对于UDS数据流来说，需要重点分析一下CAN DATA. CAN DATA的最终形成是在网络层实现的，遵循

ISO15765-2的规则，在这个层里面吸收应用层的UDS诊断数据，同时增加了这个CAN 信息的控制信息，最终形成一个帧的CAN消息，放入物理层的数据收发器里面。

根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data. 具体如下图所示：

综上所述，N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三个字节，N_DATA值主要集中在后面7位字节。其中，SF_DL 代表单帧中数据的个数，FF_DL代表连续帧中的数据总数，SN代表此帧为连续帧中的第几帧，FS参数控制发送端是否能继续传输数据，BS规定发送端允许持续传输连续帧数目的最大值，STmin限定连续帧相互之间所允许的最小值。

先面用连个例子进行说明，请参考！

例子1--- 单帧的数据传输与接收

数据发送：27 09

数据反馈：7F 27 7E --- 负反馈

数据发送：10 40

数据反馈：50 40 00 32 01 F4

下图为在Canlyzer里面的数据截图，请参考

由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个数据位，02，03，02，06代表的为此帧数据含有几个数据位，多余的数据位都用00或者AA行填充。

例子2 --- 多帧的数据接收与传输

数据发送：19 04 00 01 00 00

数据反馈：59 04 00 01 00 27 00 0B FF FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

下图为在Canlyzer里面的数据截图，请参考

数据发送为单帧，所以06代表发送的数据中含有6个字节，回复为正反馈，为连续帧，10 代表连续帧的首帧，1E代表此连续帧含有30个字节，30代表此连续帧的流控制帧，21，22，23，24代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中AA为填充位。