转载：https://www.cnblogs.com/still-smile/p/12022080.html
UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线（例如CAN, LIN, Flexray, Ethernet 和 K-line）上实现。UDS协议的应用层定义是ISO 14229-1，目前大部分汽车厂商均采用UDS on CAN的诊断协议。
UDS本质上是一系列的服务，共包含6大类26种。每种服务都有自己独立的ID，即SID。
- SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给ECU发送指定的请求数据（Request），这条数据中需要包含SID。
- 如果是肯定的响应（Positive Response），回复
[SID+0x40]，如请求10，响应50；请求22，响应62。 - 如果是否定的响应（Negative Response），回复7F+SID+NRC，回复的是一个声明。
肯定响应和否定响应的形式一定要熟记。
UDS的26种服务中，有7种很重要。它们分别是：
- $10 Diagnostic Session Control（诊断会话），
- $14 Clear Diagnostic Information（清除诊断信息），
- $19 Read DTC Information，
- $22 Read Data By Identifier（通过ID读数据），
- $27 Security Access（安全访问），
- $2E Write Data By Identifier（通过ID写数据），
- $3E Tester Present（待机握手）。
下面对这7个服务进行解读。
1 $10诊断会话
$10包含3个子功能，
- 01 Default，
- 02 Programming，
- 03 Extended，
ECU上电时，进入的是默认会话（Default）。如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01。当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。
报文包含4种类型，即
- SID，
- SID+SF（Sub-function），
- SID+DID（Data Identifier）（读写用），
- SID+SF+DID。
NRC：Negative Response Code（否定响应码)。如果ECU拒绝了一个请求，它会回应一个NRC。不同的NRC有不同的含义。
举例子前首先看下网络层帧：
- 第一个字节的高位是0的为单帧信息；
- 第一个字节的高位是1的为多帧中的首帧；
- 第一个字节的高位是2的为多帧中的后续帧；
- 第一个字节的高位是3的为流控帧；
举例1：以can总线为例子
八个数据字节，第一字节被网络层占用。
- 请求（Request）:
02 10 02 xx xx xx xx xx
02中的0代表网络层单帧SF，2代表 数据域有2个字节；10是SID，02是子功能。
- 肯定响应:
02 50 02 xx xx xx xx xx
02同上，10+40表示对SID的肯定回复，02是子功能。
- 否定响应:
03 7F 10 22 xx xx xx xx；
03同上，7F表示否定响应，10是SID，22是NRC。
3.$19 读DTC
DTC（diagnostic trouble code）：如果系统检测到了一个错误，它将其存储为DTC。DTC可表现为：一个显而易见的故障:通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节，OBD II占用两个字节。
故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码。
| DTCHighByte | DTCMiddleByte | DTCLowByte | DTCStatus |
|---|---|---|---|
| Byte 1 | Byte 2 | Byte 3 | Byte 4 |
$19 拥有28个子服务（Sub-Function）。常用的子服务有02（通过DTC状态掩码读取DTC），04（读取快照信息），06（读取扩展信息），0A（读ECU支持的所有DTC数据）。
3.$14清除DTC
清除（复位）DTC格式，它可以改变DTC的状态。3个FF代表清除所有DTC。
Request：14+FF+FF+FF；
Response：54 。
2诊断报文解析
UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构
CAN Message =CAN ID + CAN DATA
根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data.
网络层 PDU（协议数据单元）PCI（协议控制信息）格式：具体如下图所示：
| 帧类型 | bit7-4 | bit3-0 | Byte 2 | Byte 3 |
|---|---|---|---|---|
| 单帧 | PCItype=0 | SF_DL | N/A | N/A |
| 首帧 | PCItype=1 | FF_DL | FF_DL | N/A |
| 连续帧 | PCItype=2 | SN | N/A | N/A |
| 流控帧 | PCItype=3 | FS | BS | ST_min |
综上所述，N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三个字节，N_DATA值主要集中在后面7位字节。其中，
SF_DL代表单帧中数据字节数（取值0-7），FF_DL代表 连续帧中的数据字节数(12bit可表四8~4095)，SN代表此帧为连续帧中的第几帧，（0、1、2...E、F、0、1...）FS流控制帧，有三种状态：继续发送0、保持等待1、数据溢出2BS规定发送端允许持续传输连续帧数目的最大值（0~255），STmin限定连续帧相互之间所允许的最小时间间隔。
先面用连个例子进行说明，请参考！
2|1例子 1--- 单帧的数据传输与接收
[图片上传失败...(image-b66bab-1538824826939)]
数据发送： 02 27 09
数据反馈： 03 7F 27 7E ---==否定的响应==（Negative Response），回复==7F+SID+NRC==，回复的是一个声明
数据发送： 02 10 40
数据反馈： 06 50 40 00 32 01 F4 ---==肯定的响应==（Positive Response），回复[==SID+0x40==]，就是请求10，响应40；回复的是一组数据
由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个字节的低四位，02，03，02，06代表的为此帧数据含有几个字节，多余的数据位都用 00或者AA行填充。
2|2例子2 --- 多帧的数据接收与传输
[图片上传失败...(image-b5e84b-1538824826939)]
数据发送：
- 06 19 04 00 01 00 00 00
数据反馈：
- 10 1E 59 04 00 01 00 27
- 30 00 00 00 00 00 00 00
- 21 00 0B FF FF FF FF FF
- 22 FF FF FF FF FF FF FF
- 23 FF FF FF FF FF FF FF
- 24 FF FF FF AA AA AA AA
数据发送为单帧，所以06代表发送的数据中含有6个字节，
回复为Positive Response，为连续帧。
- 10中的1代表连续帧的首帧，==01E代表此连续帧含有30个字节==，
- 30代表此连续帧的流控制帧，
- 21，22，23，24代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中AA为填充位。