搜索
车辆控制单元诊断系统开发---UDS诊断数据流解析屌丝小蚂蚁4个月前之前在专栏里面写过一篇关于UDS诊断协议的介绍，对比于专栏文章的热度与一位朋友的咨询，决定在上篇文章的基础上，对UDS诊断协议开发进行进一步的解析。UDS的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CANMessage的架构CANMessage=CANID+CANDATACANID分为标准与扩展，两种类型，具体大家可以百度，百度上老多了。在UDS的协议里面ID的类型并没有对其进行具体的定义，可以根据自己的需求进行自己定义，在Autosar里面是个两个配置变量，一个配置ID值，一个配置ID类型，大家自己配置一下就可以，对于UDS数据流来说，需要重点分析一下CANDATA.CANDATA的最终形成是在网络层实现的，遵循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---单帧的数据传输与接收数据发送：2709数据反馈：7F277E---负反馈数据发送：1040数据反馈：5040003201F4下图为在Canlyzer里面的数据截图，请参考由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个数据位，02，03，02，06代表的为此帧数据含有几个数据位，多余的数据位都用00或者AA行填充。例子2---多帧的数据接收与传输数据发送：190400010000数据反馈：590400010027000BFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF下图为在Canlyzer里面的数据截图，请参考数据发送为单帧，所以06代表发送的数据中含有6个字节，回复为正反馈，为连续帧，10代表连续帧的首帧，1E代表此连续帧含有30个字节，30代表此连续帧的流控制帧，21，22，23，24代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中AA为填充位。