考虑有些同学没有项目开发经验，所以还是从专业术语开始讲起。
诊断服务是介于诊断设备和ECU之间的一种信息交互方式。通常由诊断设备发出请求，ECU做出回应。
Diagnostic Trouble Code （故障码）
Diagnostic Data （诊断数据）
- 当前数据：ECU正在运行的数据，比如车速、节气门开度，发动机转速等；
- 存储数据：被ECU存储在存储器中某时刻的数据，比如DTC；
- 静态数据：恒定不变的ECU内部数据，比如VIN码。
Diagnostic Session （诊断会话）
- 物理寻址，即1对1通信，用于知道确切的被诊断ECU的地址；
- 功能寻址，即1对n通信，或者说广播发送，用于不知道确切的被诊断的ECU的地址，向一组或者全体ECU发送请求；
Response（响应）
tester请求诊断服务执行后，从ECU的返回结果。可以有两种结果：
- Positive Response，正响应，即诊断请求执行成功；
- Negative Response，负响应，即诊断请求执行失败；
Service Identifier
Data Identifier
简称DID，2个字节无符号整数的ID，用来标识ECU中存储的某个诊断数据单元。它的好处是当要读取某个单元的诊断数据时，只要读对应的DID就可以，不必知道数据的具体地址。即使当ECU中的数据地址发生变化时，改变DID和地址单元的映射关系即可，对于使用者来说DID屏蔽了具体实现细节，而将重点放在了数据本身。
Negative Response Code
可以简称为NRC，或者叫负响应码，是一个字节的无符号整数。它是诊断协议为每种执行失败的诊断服务分配的失败原因代号。
Sub-function
有些诊断服务可以支持不同的诊断子服务，sub-function就是用来定义这种子服务的，它将某一个服务细分为更为具体的服务，是一个字节的无符号整数。比如ECU Reset这个服务就有0x01，0x02，0x03等sub-function指代具体的reset方式。
1 什么是UDS
UDS（Unified Diagnostic Services，统一诊断服务）诊断协议是用于汽车行业诊断通信的需求规范，由ISO-14229系列标准定义。应用于OSI七层模型的应用层（第7层），它只规定了与诊断相关的服务需求，并未涉及通信机制，所以，它可以在不同的汽车总线（例如CAN, LIN, Flexray, Ethernet 和 K-line）上实现。
ISO 14229-1 定义了诊断服务，只有应用层，不涉及网络及实现。
ISO 14229-3定义了UDS在CAN总线上的实现。
诊断通信用于建立诊断仪与ECU之间的通信连接，并负责将ECU中的诊断结果输送到诊断仪中。
2 UDS的作用
UDS的作用非常广泛，几乎跟随ECU软件开发的全过程。
-
ECU开发过程要用到它来构建bootloader，上传和下载数据，即软件刷写，控制器Reset； -
测试时要用它来读写存储，控制外设； -
产线上，要用它来校准机械件，控制例程，进行下线执行器测试，刷新软件，配置防盗，读取号码，下线配置等。 -
在行驶过程中，要用它来监测各种故障，并记下故障码； -
4S店里，技师需要读取当前故障、历史故障，读取故障发生时刻环境信息状态，清除故障，判断故障发生点，还可以用来升级ECU程序。
在使用ISO-14229时，下面的通信机制可以改变，比如基于CAN，基于LAN，基于FlexRay等。诊断通信过程其实很简单，诊断仪发送诊断请求(request)，ECU给出诊断响应（response），而UDS就是为不同诊断功能request和response定义统一的内容和格式。
其实诊断通信的机制很简单，事件驱动型，一问一答。
类比client-server通信方式，诊断仪即客户端，发送request，服务器即ECU，收到request之后进行处理，然后向诊断仪回复response。
有确认服务
但是，诊断协议有自己的特色，它规定了request和response的格式，在收到request的时候要做格式检查。同时由于寻址方式的不同，有无sub-function的支持等，也会影响request和response的处理方式和结果。
UDS寻址模式
-
物理寻址，点对点，一对一，可根据物理地址的不同进行访问，但只能访问单个节点，各个ECU也采用不同的CANID针对提问作出应答。
-
功能寻址，广播模式，一对多，根据功能的不同进行访问，它可以访问多个ECU节点，各个ECU也采用不同的CANID针对提问作出应答。其SID对于标准帧来说，通常是7DF。
比如，通过诊断仪请求各控制器进入编程模式（10 02）：
5 请求和响应
5.1 Request
归纳起来，诊断的request格式无非以下两种：
+ +
+
即有无sub-function的区别。Parameter可以是DID，可以是输入参数，可以是自定义的值，字节数视具体要求而定。
首先，了解下sub-function的定义方法。
功能寻址的客户端请求信息
物理寻址的客户端请求信息
需要注意的是，Bit7用来指示是否要抑制Positive Response。当Bit 7为1时，对该request的Positive Response要被抑制，即不发送Positive Response；当Bit7为0时，对该request的Positive Response不被抑制，正常发送。除了Bit 7，Sub-function有不同的值，具体的值和含义在协议中对每个服务的解释时都会有介绍。
无sub-function
不带sub-function的服务，就带parameter。Parameter可以是DID，可以是输入参数，可以是自定义的值，字节数目也是视具体要求而定。一般在协议内都会有表格，当遇到具体问题时，可查表确定。
5.2 Response
通常，response会在服务被request且执行之后发送，成功的话就发positive response，失败的话要发negative response，但是也有例外的时候。比如，ECUreset，诊断仪要求先发送response，然后再去执行具体的reset，因为如果先reset，那么ECU的通信模块shut down，是无法发送出去response的。像这种特殊情况，协议会在描述具体服务时标注出来。
Positive Response
基本格式：
+ +
+
要注意，第一个字节是由SID和0x40的和构成。这里的Parameter项是optional的，具体要看协议规定。
比如，session control这个服务：
Send：02 10 01（02中的0代表网络层单帧SF，2代表数据域有2个字节；10是SID，02是子功能）
肯定响应：
Receive：02 50 01 （02同上，10+40表示对SID的肯定回复，01是sub-funtion）
否定响应:
安全访问的过程
Negative Response
基本格式:
+ +
看起来比较简单，格式比较固定，只要是Negative Response，第一字节就是0x7F，第二字节照抄原来的SID，第三个字节是错误响应码，指示具体错误响应的原因，这个NRC可以在下文中参看。
比如，session control 这个服务：
Send：10 05（现在sun-function变为05了，假定系统不支持这个sub-function）
Receive：7F 10 12（7F即指代错误响应，10为SID，12是NRC，查协议可知其指代sub-function not supported 这个错误）
- 11：ServiceNotSupported/服务不支持，诊断仪发送的请求消息中服务标识符无法识别或不支持；
- 12：SubFunctionNotSupported/不支持子服务，诊断仪发送的请求消息中子服务无法识别或不支持；
- 13：IncorrectMessageLengthOrInvalidFormat/不正确的消息长度或无效的格式，请求消息长度与特定服务规定的长度不匹配或者是参数格式与特定服务规定的格式不匹配；
- 21：BusyRepeatRequest/重复请求忙，表明ECU太忙而不能去执行请求。一般来说，在这种情况下，诊断仪应进行重复请求工作；
- 22：conditionsNotCorrect/条件不正确，表明ECU的状态条件不允许支持该请求；
- 24：requestSequenceError/请求序列错误，表明收到的是非预期的请求消息序列；
- 25：noResponseFromSubnetComponent/子网节点无应答，表明ECU收到请求，但所请求的操作无法执行；
- 26：failurePreventsExecutionOfRequestedAction/故障阻值请求工作执行，表明请求的动作因一故障原因而没有执行；
- 31：requestOutOfRange/请求超出范围，请求消息包含一个超出允许范围的参数，或者是不支持的数据标识符/例程标识符的访问；
- 33：securityAccessDenied/安全访问拒绝，诊断仪无法通过ECU的安全策略；
- 35：invalidKey/密钥无效，诊断仪发送的密钥与ECU内存中的密钥不匹配；
- 36：exceedNumberOfAttempts/超出尝试次数，诊断仪尝试获得安全访问失败次数超过了ECU安全策略允许的值；
- 37：requiredTimeDelayNotExpired/所需时间延迟未到，在ECU所需的请求延迟时间过去之前诊断仪又执行了一次请求；
- 70：uploadDownloadNotAccepted/不允许上传下载，表明试图向ECU内存上传/下载数据失败的原因是条件不允许；
- 71：transferDataSuspended/数据传输暂停，表明由于错误导致数据传输操作的中止；
- 72：generalProgrammingFailure/一般编程失败，表明在不可擦除的内存设备中进行擦除或编程时ECU检测到错误发生；
- 73：wrongBlockSequenceCounter/错误的数据块序列计数器，ECU在数据块序列计数序列中检测到错误发生；
- 78：requestCorrectlyReceived-ResponsePending/正确接收请求消息-等待响应 表明ECU正确接收到请求消息，但是将执行的动作未完成且ECU未准备好接收其它请求；
- 7E：subFunctionNotSupportedInActiveSession/激活会话不支持该子服务，当前会话模式下ECU不支持请求的子服务；
- 7F：serviceNotSupportedInActiveSession/激活会话不支持该服务，当前会话模式下ECU不支持请求的服务；
- 92：voltageTooHigh/电压过高，当前电压值超过了编程允许的最大门限值；
- 93：voltageTooLow/电压过低，当前电压值低于了编程允许的最小门限值；
值得一提的是，在物理寻址和功能寻址情况下，Negative Response有所不同。
在物理寻址情况下，只要是Negative Response就应该按照规定格式发送。而在功能寻址情况下，有一点特殊，对于NRC为0x11（service not supported）、0x12（subfunction not supported）、0x31（request out of range）这三种情况，功能寻址是不会发送response的。
6 UDS的服务有哪些
UDS的服务包含了6大类，共26种，每种服务都有自己独立的ID，即SID（Service Identifier）。常用服务有10、11、27、28、3E、85、19、14、22、23、2C、2E、3D、2F、31、34、35、36、37、38。
|
诊断和通信控制功能 |
SID10 |
诊断会话控制服务 |
|
SID11 |
控制器重启服务 | |
|
SID27 |
身份认证服务 | |
|
SID28 |
通信控制服务 | |
|
SID3E |
握手服务 | |
|
SID85 |
DTC设置控制服务 | |
|
故障码传输功能 |
SID19 |
读取故障码信息服务 |
|
SID14 |
清除故障码服务 | |
|
数据传输功能 |
SID22 |
根据标识符读取数据服务 |
|
SID23 |
根据地址读取数据服务 | |
|
SID2C |
静态定义标识符服务 | |
|
SID2E |
根据标识符写入数据服务 | |
|
SID3D |
根据地址写入数据服务 | |
|
IO控制功能 |
SID2F |
输入输出控制 |
|
例程控制功能 |
SID31 |
例程控制 |
|
上传和下载功能 |
SID34 |
请求下载数据 |
|
SID35 |
请求上传数据 | |
|
SID36 |
请求上传或下载数据 | |
|
SID37 |
数据传输完成，请求退出 | |
|
SID38 |
文件传输请求 |
作者简介：
Demu，传统汽车电控向智能驾驶转变的汽车人。从事发动机控制器系统工程师和软件工程师多年，有丰富的ECU系统和软件设计经验。欢迎大家一起留言交流，共同进步。
