之前在专栏里面写过一篇关于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 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
下图为在Canlyzer里面的数据截图，请参考
数据发送为单帧，所以06代表发送的数据中含有6个字节，回复为正反馈，为连续帧，10 代表连续帧的首帧，1E代表此连续帧含有30个字节，30代表此连续帧的流控制帧，21，22，23，24代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中AA为填充位。
通过这个介绍，希望大家能够清晰的了解到数据流中的数据含义，希望对大家的开发工作有所帮助。
如果大家第一次看这个文章，请参考本专栏的前篇UDS的介绍，下雨天搭配在一起看，更配呦，请参考！