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(传输层)使用。

 

UDS诊断入门(文章后面还附有其他资源)UDS诊断入门(文章后面还附有其他资源) 零点零一 发布了303 篇原创文章 · 获赞 269 · 访问量 271万+ 他的留言板 关注
上一篇:BUG搬运工-LAP/WLC MIC or SSC lifetime expiration causes DTLS failure


下一篇:P2585 [ZJOI2006]三色二叉树