本文主要是介绍车载测试之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诊断协议的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
