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

之前在专栏里面写过一篇关于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. 具体如下图所示:

UDS 诊断数据流解析(车辆控制单元诊断系统开发)_第1张图片

综上所述,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里面的数据截图,请参考

UDS 诊断数据流解析(车辆控制单元诊断系统开发)_第2张图片

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

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

数据发送:19 04 00 01 00 00

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

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

UDS 诊断数据流解析(车辆控制单元诊断系统开发)_第3张图片

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

通过这个介绍,希望大家能够清晰的了解到数据流中的数据含义,希望对大家的开发工作有所帮助。

如果大家第一次看这个文章,请参考本专栏的前篇UDS的介绍,下雨天搭配在一起看,更配呦,请参考!

你可能感兴趣的:(UDS 诊断数据流解析(车辆控制单元诊断系统开发))