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个服务进行解读。
$10诊断会话
$10包含3个子功能，
ECU上电时，进入的是默认会话（Default）。如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01。当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。
报文包含4种类型，即
NRC：Negative Response Code（否定响应码)。如果ECU拒绝了一个请求，它会回应一个NRC。不同的NRC有不同的含义。
例子：以CAN总线网络举例。
八个数据字节，第一字节被网络层占用。
- 请求（Request）:
02中的0代表网络层单帧SF，2代表 数据域有2个字节；10是SID，02是子功能。
- 肯定响应:
02同上，10+40表示对SID的肯定回复，02是子功能。
- 否定响应:
03同上，7F表示否定响应，10是SID，22是NRC。
$3E待机握手
$3E服务用于向服务器指示诊断仪仍然连接在网络上，之前已经激活的诊断服务功能可以仍然保持激活状态。
例子：
$27安全访问
27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。
比如下面的例子，2n-1是某个子服务，通过首轮种子的请求，首轮ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。之后第二轮，诊断端会利用种子进行运算（利用整车厂的算法），生成k1（不一定是1个字节），那么发送请求，27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时，解锁（Unlocked）成功。
- 例子：
$22读数据
$22读数据，
Request（请求）：
Response（响应）：
DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符，0xF187就是车厂备件号数据标识符，0xF188就是车厂ECU软件号码数据ID，0xF189就是车厂ECU软件版本号数据标识符。
$2E写数据
$22写数据，
Request（请求）：
Response（响应）：
注意，比如0xF186这个DID不支持直接写入数据，需要用$10来进行会话转换。也就是说，对于写数据的请求，一般来说需要在一个非默认会话，或解锁的状态下才能进行。
$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的故障码。
| Byte 1 | Byte 2 | Byte 3 | Byte 4 |
$19 拥有28个子服务（Sub-Function）。常用的子服务有02（通过DTC状态掩码读取DTC），04（读取快照信息），06（读取扩展信息），0A（读ECU支持的所有DTC数据）。
$14清除DTC
清除（复位）DTC格式，它可以改变DTC的状态。3个FF代表清除所有DTC。
诊断报文解析
UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构
根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data.
网络层 PDU（协议数据单元）PCI（协议控制信息）格式：具体如下图所示：
| 单帧 | 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限定连续帧相互之间所允许的最小时间间隔。
先面用连个例子进行说明，请参考！
例子 1--- 单帧的数据传输与接收
[图片上传失败...(image-b66bab-1538824826939)]
由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个字节的低四位，02，03，02，06代表的为此帧数据含有几个字节，多余的数据位都用 00或者AA行填充。
例子2 --- 多帧的数据接收与传输
[图片上传失败...(image-b5e84b-1538824826939)]
数据发送为单帧，所以06代表发送的数据中含有6个字节，
回复为Positive Response，为连续帧。
- 10中的1代表连续帧的首帧，==01E代表此连续帧含有30个字节==，
- 30代表此连续帧的流控制帧，
- 21，22，23，24代表连续帧中的第几帧，21代表第一帧，22代表第二帧，依此类推，其中AA为填充位。