UDS诊断入门(文章后面还附有其他资源)
最近在研究汽车诊断数据的解析,逐渐找到以下资源记录下来.
UDS诊断入门(文章后面还附有其他资源)
https://blog.csdn.net/u012252959/article/details/83063899
摘要:
UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线（例如CAN, LIN, Flexray, Internet 和K-line）上实现。UDS协议的应用层定义是ISO 14229-1，目前大部分汽车厂商均采用UDS on CAN的诊断协议。
ISO 14229-1也就是UDS协议仅对应用层做出了定义，物理层有双绞线和光纤供用户选择，数据链路层采用CAN总线的ISO 11898-1协议，针对Classical CAN仅有8个字节的数据场与应用层可处理多帧数据的矛盾，ISO 15765-2对网络层进行了定义。CAN的8字节数据场会腾出一帧来表示网络层的信息。下图右侧是排放相关的协议，ISO 15031-5主要针对OBD协议，为法规强制要求车厂满足的协议。学习时，我们应在了解CAN总线基本知识的前提下，着重学习ISO 15765-2和ISO 11898-1的协议内容，并通过BootLoader作为例子，对UDS有一个大致的了解。
学习资料:
1.统一诊断服务 (Unified diagnostic services ， UDS) （一）
2.统一诊断服务 (Unified diagnostic services ， UDS) （二）
3.统一诊断服务 (Unified diagnostic services ， UDS) （三）
4.统一诊断服务 (Unified diagnostic services ， UDS) （四）
5.统一诊断服务 (Unified diagnostic services ， UDS) （五）
6.统一诊断服务 (Unified diagnostic services ， UDS) （六）
7.统一诊断服务 (Unified diagnostic services ， UDS) （七）
8.基于CAN总线实现的UDS诊断（DoCAN）
9.【图文】UDS诊断服务_百度文库
10.CAN诊断基础-上部分_图文_百度文库
11.CAN诊断-下_已读_图文_百度文库
12.ISO 14229+统一诊断服务
13.FlashBootloader_图文_百度文库
14.帐号登录
15.ISO 15031-5-2015
16.ISO 15765-3车载诊断标准-详细中文版
17.吉利汽车基于CAN线诊断技术规范_百度文库
代码参考：
1.SAE J1939 协议源代码分析(一)-程序结构框架
2.基于CAN总线的汽车诊断协议UDS(上位机开发网络层及错误代码解析) - CSDN博客
3.基于CAN总线的汽车诊断协议UDS(ECU底层模块移植开发) - CSDN博客
4.基于CAN总线的汽车诊断协议UDS (网络层 ISO 15765)
车载诊断标准网络层ISO15765-2中文
基于CAN总线的汽车诊断协议UDS (网络层 ISO 15765)
https://blog.csdn.net/qq_28086637/article/details/73699677
摘要:
Protocol control information specification
Table 3描述各种类型的N_PDU 的N_PCI bytes的定义。
N_PCI byte的第一个字节的高4位为N_PCItype，标识该N_PDU(数据单元)的类型。
0，SF（单帧）
1，FF（首帧）
2，CF（连续帧）
3，FC（流控帧）
4-F，保留定义
我在程序中接收到一条诊断报文后，通过一条宏定义获取N_PCItype
#define NT_GET_PCI_TYPE(n_pci) (n_pci>>4)
pci_type = NT_GET_PCI_TYPE (frame_buf[0]);
然后根据pci_type进行不同的处理。
(1)单帧的情况下，N_PCI byte第一个字节的低4位为SF_DL(消息长度)，范围在1-6(扩展地址和混合地址)或者1-7(普通地址)之间，如果SF_DL错误，网络层应该忽略这条N_PDU
(2)首帧的情况下，N_PCI bytes 第一个字节的低4位和第二个字节共同组成FF_DL(消息长度)，范围在8-FFF（扩展地址和混合地址）或者7-FFF（普通地址）之间，如果FF_DL大于接收者的接收缓存，网络层应该丢弃这条消息，并且发送FC with FlowStatus = Overflow
(3)连续帧情况下，N_PCI byte第一个字节的低4位为SN（SequenceNumber），
在每开始发送一段数据的时候SN必须从零开始，FF（首帧）没有SN字段，但应该被认为是SN = 0，
FF之后的第一个CF的SN应该为1，
每发送一个新的CF，SN都应该增加1，
CF的值不应该受FC的影响，
当SN的值达到15的时候，下次发送的CF，SN应被重置为0，
如果SN出错，网络层应该丢弃已接收到的消息，并且调用N_USData.indication服务，with N_WRONG_SN
(4)流控帧情况下，
N_PCI bytes第一个字节的低4位为FS（Flow status），FS有4个定义，
0， CTS ，代表发送者可以正常发送
1， WT ，代表发送者应该再等待下一个FC，并且重启N_BS timer
2， OVFLW，代表接收方缓存溢出，发送方收到此FS后，应该终止发送，调用N_USData.confirm 服务，with N_BUFFER_OVFLW
3-F， Reserved
如果发送者收到的FS出错，网络层应该停止消息发送，并且调用 N_USData.confirm 服务，with N_INVALID_FS
————————————————
版权声明：本文为CSDN博主「qq_28086637」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_28086637/article/details/73699677
关于ISO 15765-2的解读
关于15765-2的解读
1、传输层只有4中frame。
SF
FF
CF
FC
每种帧的PCI是不一样的。占的字节数也不一样。
注意，对于SN。其实FF，可以认为FF是有SN的，为0。但是，制定协议的人不是程序员，所以，数数是从1开始数的。所以对于第一个CF，它的SN是1。
2、在UDS和OBD（15031-5）中会被当作tp（传输层）使用。