ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

UDS诊断入门(文章后面还附有其他资源)

2020-01-16 14:38:31  阅读:1423  来源: 互联网

标签:UDS 入门 附有 网络层 诊断 PCI ISO SN


最近在研究汽车诊断数据的解析,逐渐找到以下资源记录下来.

 

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

 

零点零一 发布了303 篇原创文章 · 获赞 269 · 访问量 271万+ 他的留言板 关注

标签:UDS,入门,附有,网络层,诊断,PCI,ISO,SN
来源: https://blog.csdn.net/thanklife/article/details/104004019

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有