UDS 由 ISO-14229系列标准定义，ISO 14229-1 定义了诊断服务，不涉及网络及实
现，只有应用层的内容。而 ISO 14229-3则定义了 UDS 在 CAN总线上的实现。
诊断通信的过程从用户角度来看非常容易理解，诊断仪发送诊断请求(request)，
ECU给出诊断响应（response），而 UDS 就是为不同的诊断功能的 request 和
response定义了统一的内容和格式。
最近关于 UDS 的一系列专栏文章只关注应用层的诊断服务，忽略下层的通信机制。
Diagnostic request 的格式： ：
Diagnostic request 的格式可以分为两类：一类是拥有 sub-function 的，另一类是没
有 sub-function的，如下面两张图所示。Service ID(以下简称 SID)的长度固定为 1
个字节，代表了这条诊断命令执行的什么功能。sub-function 的长度也是 1 个字节，
它通常表示对这个诊断服务的具体操作，比如是启动、停止还是查询这个诊断服务。
而后面的 parameter则根据各个诊断服务的不同具有不同的内容，长度和格式并没
有统一规格，它用于限定诊断服务执行的条件，比如某个诊断服务执行的时间等。
parameter的一个重要应用是作为标识符，标识诊断请求要读出的数据内容，我会
在后续的文章里详细讲述各个诊断服务的应用。
拥有 sub-function 的诊断请求
无 sub-function 的诊断请求
有一点要补充的是，其实 sub-function 严格来说是 7个 bit，而不是 1个 byte，因为
它的最高位 bit 被用于抑制正响应（suppress positive response,SPR），如果这个 bit
被置 1，则 ECU不会给出正响应（positive response）； 如果这个 bit 被置 0，则
ECU会给出正响应。这样做的目的是可以告诉 ECU不要发不必要的 response，从
而节约通信资源。
Diagnostic response 的格式： ：
Diagnostic response分为 positive和 negative 两类。positive response 意味着诊断仪发
过来的诊断请求被执行了，而 negative response则意味着 ECU因为某种原因无法
执行诊断仪发过来的诊断请求，而无法执行的原因则存在于 negative response的报
文中。 
positive response的格式如上图所示，也基本上是由三部分组成，其中的 response
SID这个字节作为诊断请求的 echo，它等于 SID + 0X40。后面的两个部分则视具
体的诊断服务而定。 
negative response的格式固定为 3个字节，第一个字节为 0x7F，第二个字节是被拒
绝掉的 SID，第三个字节是这个诊断服务无法被执行的原因。下面这张图列举了部
分原因代码，比如，如果 ECU给出 7F 22 13 这个 negative response，则说明 22这
个服务因为诊断请求数据长度不对的原因无法执行。
总结：诊断通信的过程就是诊断仪和 ECU交换数据，前者发的是 request，后者发
的是 response，而 UDS 最重要的作用就是定义了这些 request 和 response的格式和
内容。本文对 request 和 response进行了简要介绍，在后面描述各种诊断服务的文
章中我会通过更多的示例来说明这两个基本概念。
