随着技术不断提高，驾驶员对车辆的要求也在不断提高，因此车身控制器的数量也在与日俱增。控制器实现的功能：安全功能（防抱死系统等）、驾驶功能（助力转向等）、影音娱乐（车载娱乐系统，抬显系统），当然也包括今天索要分享的内容：诊断功能。
诊断功能的作用在上文已谈到：起初是为了快速界定车身发生故障部位，现完善和扩充很多功能（定义DID读取车辆运行状态信息、Softwareupdate刷写）。它的经典模型如下：
Tester与车辆直接通信（直接通信方式），Tester发送请求（Request）到车身控制器，控制器基于收到的诊断请求给予响应（Response）。因全球有诸多OEM以及供应商，为了避免社会资源浪费，需定义通用的诊断协议。诊断协议中定义诊断服务的类型、诊断请求和响应的格式、ECU响应的机制等等。
今天想跟大家聊聊UDS这个诊断协议（ISO14229），全名：Roadvehicles — Unified diagnostic services (UDS)。目前为止有7个子类：
注：上图标红的内容，当某一天一种新的总线引用到车载网络中，UDS协议照样适用在新的总线，不会因为时间推移，需求变更而被淘汰。
---ISO 1429-1中主要定义诊断服务类型（如2013版中定义26个诊断服务，也预留给用户自定义的内容）、诊断服务请求的格式、ECU收到诊断请求响应机制和格式；
---ISO 14229-2定义诊断功能实现过程中通信参数；
---ISO 14229-3、ISO14229-4、ISO14229-5、ISO14229-6、ISO14229-7是UDS协议在不同车载总线（车载通信介质）的具体应用和相应限制。比如ISO14229-5定义了UDSonIP的具体应用和相应限制：
车载以太网通信过程中，是TCP搭建链接。在做会话模式切换以及Reset重启，搭建好的TCP链接会断开，再进行通信，需要重新搭建TCP链接（其实质是连接IP地址和Port端口的Socket）。
如果将UDS协议与计算机经典七层模型做一个Map：
每个层级对应不同的总线协议。这里以CAN总线为例，做个简单分享：
1. 在物理层以及数据链路层，对应的协议ISO11898。定义CAN总线电气特性，物理Pin脚。硬件工程师需重点关注这方面的内容；
2. 传输层对应的协议是ISO15765-2，定义数据传输的规则。里面详细解释CAN单帧和多帧数据传输规则：
1) 多帧中首帧FirstFrame、流控制FlowControl、连续帧ConsecutiveFrame标识符，格式在协议中都做了详细定义（在后续文章中会分享这个协议内容）；
2) 协议定义不同的寻址方式格式；
3. 会话层映射ISO14229-2，定义了通信参数；
4. 表示层中定义OEMSpecific数据内容（DID）；
5. 应用层14229-1配合ISO 14229-5,共同规范UDS协议在CAN总线的应用。
UDS协议定义了26服务类型：
如上图，是以UDS2013版为例，列举了26个服务的类型。但在OEM诊断需求规范中，不会每个控制器都用到这26个服务，是根据新款车型控制器需求，基于UDS协议根据所需定义控制器的诊断需求规范。服务是1byte的长度，除了上述的26个服务，UDS也预留一些位给用户自定义：
UDS也定义了请求和响应的格式：
诊断请求以ServiceID来识别，肯定响应的规则是SID+40，否定响应的标识符是7F，后＋SID表示否定那个服务，再＋NRC告诉工程师为何给你否定响应。
截至目前，ISO14229发布了2006/2013/2020三个不同版本。经常用的是06版和13版。现对这两个版本做一个简单区分：
1、在功能寻址情况下，如果出现7E/7F两个NRC，06版协议定义ECU必须给响应，13版为了降低总线负载，不用响应；
2、在13版UDS协议中对NRC优先级做了响应规定，而06版没有；
3、13版协议中ECU刷写做了描述，而06版没有。
2020版UDS协议多了Service29：
通过安全认证，才能获取通信权限，更加好的保护数据安全。
下周跟大家分享：诊断协议中定义26个服务常用服务格式，功能。
-----------------------------------------
作者简介|穿拖鞋的汉子
汽车电子工程师
来，每天进步一点点！
