文章目录

---

前言

随着技术不断提高，驾驶员对车辆的要求也在不断提高，因此车身控制器的数量也在与日俱增。控制器实现的功能：安全功能（防抱死系统等）、驾驶功能（助力转向等）、影音娱乐（车载娱乐系统，抬显系统），当然也包括今天索要分享的内容：诊断功能。

---

一、车载诊断功能是什么？

诊断功能的作用在上文已谈到：起初是为了快速界定车身发生故障部位，现完善和扩充很多功能（定义DID读取车辆运行状态信息、Software update刷写）。它的经典模型如下：

 Tester与车辆直接通信（直接通信方式），Tester发送请求（Request）到车身控制器，控制器基于收到的诊断请求给予响应（Response）。因全球有诸多OEM以及供应商，为了避免社会资源浪费，需定义通用的诊断协议。诊断协议中定义诊断服务的类型、诊断请求和响应的格式、ECU响应的机制等等。

今天我想跟大家聊聊UDS这个诊断协议（ISO 14229），全名：Road vehicles — Unified diagnostic services (UDS)。目前为止有7个子类：

注：上图标红的内容，当某一天一种新的总线引用到车载网络中，UDS协议照样适用在新的总线，不会因为时间推移，需求变更而被淘汰。

---ISO 1429-1中主要定义诊断服务类型（如2013版中定义26个诊断服务，也预留给用户自定义的内容）、诊断服务请求的格式、ECU收到诊断请求响应机制和格式；

---ISO 14229-2定义诊断功能实现过程中通信参数；

---ISO 14229-3、ISO 14229-4、ISO 14229-5、ISO 14229-6、ISO 14229-7是UDS协议在不同车载总线（车载通信介质）的具体应用和相应限制。比如ISO 14229-5定义了UDSonIP的具体应用和相应限制：

车载以太网通信过程中，是TCP搭建链接。在做会话模式切换以及Reset重启，搭建好的TCP链接会断开，再进行通信，需要重新搭建TCP链接（其实质是连接IP地址和Port端口的Socket）。

如果将UDS协议与计算机经典七层模型做一个Map：

 

每个层级对应不同的总线协议。这里以CAN总线为例，做个简单分享：

1、在物理层以及数据链路层，对应的协议ISO 11898。定义CAN总线电气特性，物理Pin脚。硬件工程师需重点关注这方面的内容；

2、传输层对应的协议是ISO 15765-2，定义数据传输的规则。里面详细解释CAN单帧和多帧数据传输规则：

（1）多帧中首帧First Frame、流控制Flow Control、连续帧Consecutive Frame标识符，格式在协议中都做了详细定义（在后续文章中会分享这个协议内容）；

（2）协议定义不同的寻址方式格式

3、会话层映射ISO 14229-2，定义了通信参数；

4、表示层中定义OEM Specific数据内容（DID）；

5、应用层14229-1配合ISO 14229-5,共同规范UDS协议在CAN总线的应用。

UDS协议定义了26服务类型：

 如上图，是以UDS 2013版为例，列举了26服务的类型。但在OEM诊断需求规范中，不会每个控制器都用到这26个服务，是根据新款车型控制器需求，基于UDS协议根据所需定义控制器的诊断需求规范。服务是1 byte的长度，除了上述的26服务，UDS也预留一些位给用户自定义：

UDS也定义了请求和响应的格式

 

诊断请求以Service ID来识别，肯定响应的规则是SID+40，否定响应的标识符是7F，后＋SID表示否定那个服务，再＋NRC告诉工程师为何给你否定响应。

截至目前，ISO 14229发布了2006/2013/2020三个不同版本。经常用的是06版和13版。现对这两个版本做一个简单区分：

1、在功能寻址情况下，如果出现7E/7F两个NRC，06版协议定义ECU必须给响应，13版为了降低总线负载，不用响应；

2、在13版UDS协议中对NRC优先级做了响应规定，而06版没有；

3、13版协议中ECU刷写做了描述，而06版没有。

2020版UDS协议多了Service 29：

通过安全认证，才能获取通信权限，更加好的保护数据安全。 

 

总结

如上是对ISO 14229协议进行汇总总结，对比了不同版本的协议主要区别。