车载测试之UDS诊断协议

本文主要是介绍车载测试之UDS诊断协议，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

什么是UDS诊断

也被称为离线诊断或者增强型诊断,面向汽车上的所有ECU的诊断,可以通过UDS进行读取、写入ECU运行时的一些数据,刷写ECU、获取故障信息等,UDS是一套统一的诊断服务命令,分为6大类26个服务

26个诊断服务

UDS中的26个服务是规定在ISO的14229-1协议中

诊断和通信管理功能单元

故障码传输功能单元

数据传输类功能单元

输入输出控制功能单元

例行程序功能单元

上传和下载功能单元

诊断的请求与响应

UDS协议规定诊断的整个过程是是请求响应模式,其实这个做web的就很好理解了，就如同我们http请求,基于请求响应的,发送请求获取响应,在USD诊断中是由诊断仪发送诊断请求,ECU接收到诊断请求后处理,再发回给诊断仪

诊断请求和诊断响应的本质就是一段符合UDS协议规范的16进制的报文

下图所示:

这里我们看到开头SID是22,可以回头去看是6大服务内的哪个功能,可以找到是数据传输类功能单元里面包含22,作用是通过ID读取数据,实际上这段诊断请求就是读取ECU当前工作的电压信息

这里的7F 22 11 这个其实是负响应(否定响应),是失败的,这个之前工作中没有Zenzifi认证经常碰到这个否定响应

下面会肯定响应,才代表这次诊断请求响应正常的

否定响应码

否定响应码也叫NRC(Negative Response Code),当一次UDS诊断请求失败的时候ECU会返回一个否定响应码

常见的否定响应码

11:代表ECU不支持该服务

12:代表EUC不支持当前服务的子功能

22:某一项诊断请求需要在某个更高级的扩展会话下进行

31:很多请求需要提供一些数据参数,有些数据参数是不被支持的

33:权限问题

请求和响应的寻址

CAN总线上面会有很多个ECU是如何实现将诊断请求发送给某个具体的ECU呢？

在UDS诊断协议中除了规定26个服务的服务细节,还规定了诊断请求和响应报文发送时必须要指明寻址信息,寻址信息包含了源地址和目标地址

基于CAN总线的诊断通信,由于每个ECU可以根据事先设定只处理总线上指定CAN报文ID的报文,因此UUS协议中的诊断请求响应的地址信息本质上就是CAN报文的地址ID

诊断请求之物理寻址

物理寻址其实是诊断仪与单个ECU之间的通信,只有指向的ECU可以响应报文

诊断请求之功能寻址

诊断仪与多个ECU之间的通信，可以理解为群发，一般企业都把功能寻址的CAN报文ID设置为7DF

诊断会话控制

首先要知道会话有哪些:

10 01:默认会话

10 02:编程会话

10 03:扩展会话

不同会话下所能操作的诊断请求是不同的

10服务请求和响应的报文格式

 

这篇关于车载测试之UDS诊断协议的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---