UDS教程——1.1 应用层协议整体介绍
01
概述
本文我们先从整体的维度来介绍一下应用层协议，每个UDS服务都遵循本文中的协议。这篇大多是一些比较通用和基础的概念。具体内容包括：
一、诊断通讯的基本流程
二、寻址方式
三、SI（Service ID）
四、诊断请求格式
五、肯定响应格式
六、否定响应格式
七、诊断报文示例
02
诊断通讯的基本流程
如前文所述，当我们想要获取ECU中存储的故障码时，需要先给ECU发送一个诊断请求，ECU接到诊断请求后，就会将故障码发送给诊断仪，我们称之为诊断响应。这是用的最多的诊断通讯方式，即一条请求对应一条响应。
但有些情况下，我们可能只需要给ECU发送请求，而不需要ECU返回响应，例如用诊断命令雨刷动两下，我们可以通过雨刷的动作来判断诊断指令是否执行成功。这种通讯方式是单向无反馈的，也是允许的。具体ECU什么时候需要发送响应什么时候不需要发送，我们后文会详述。
03
寻址方式
再介绍一下寻址的概念。诊断仪想要将ECU中的故障码信息读出来，就要给ECU发送诊断指令，但是车上有这么多的ECU，诊断仪应该怎么才能只给其中的一个ECU发指令呢？这就涉及到了寻址。简单来说就是给每个ECU分配一个单独的ID，使诊断仪能够通过这个ID定位到某个ECU。
CAN网络上的寻址是用CAN报文的ID来实现的，例如，预先定义ABS的诊断ID=0x722，诊断仪想要给ABS发诊断指令，就需要把CAN报文ID设置为0x722，然后发送到总线上。ABS监测到总线上出现ID=0x722的报文后，就知道这是发给它的诊断指令，就会进行相应的处理和响应。
ECU发送响应的时候，响应报文的ID也是预先定义好的，诊断仪接收到ID为响应ID的报文，就会把它当做ECU的响应来进行处理。在11位ID的标准CAN帧网络中，响应ID通常是请求ID+0x008，对上文说的ABS来说，发送诊断响应的时候通常就是0x72A。当然这个关系也不是强制要求的。
实际上ECU的寻址方式有两种，我们上文说的这种是一对一的寻址方式，叫做物理寻址（PhysicalAddress），还有一种叫做功能寻址（FunctionalAddress），它是一对多的，例如，定义车上所有ECU的功能寻址ID都为0x7DF，那么诊断仪发送ID=0x7DF的诊断请求时，网络上的所有ECU都要进行处理，并按规则发送响应。
04
SI（Service ID）
SI是UDS指令的第一个字节，我们第一篇文章中提到的10等服务就是指这个服务的SI=0x10，它是服务的标识，每个服务的SI都是唯一的。
它是1字节无符号数，范围0x00-0xFF。
上表就是标准中对SI范围的划分。我们最常用的就是标记了颜色的三个范围。
标黄的范围是诊断请求SI的范围，我们前文提到的诊断服务SI都在这个范围内。
标绿的范围是诊断肯定响应SI的范围，肯定响应SI是在请求SI的基础上+0x40，例如，10服务的诊断请求SI是0x10，响应SI 就是0x10+0x40=0x50。
标红的0x7F是诊断否定响应SI。对于所有服务，否定响应都用这个SI，我们后面还会详细展开讲否定响应。
05
诊断请求格式
1. 带子功能的服务
有的服务会带一个字节的子功能参数，类似于一个诊断功能的二级分类，请求格式如下：
这个子功能参数是一个字节无符号数，它还进一步被划分成两部分：
① Bit 7：禁止肯定响应指示位（suppressPosRspMsgIndicationBit）
这个指示位是子功能参数这个字节的最高位，它为1的时候，表示禁止肯定响应，也就是说如果ECU即将返回的是肯定响应，那么就不需要发送响应了，而如果ECU即将返回的是否定响应，那么还是照常发送。
这种情况多用于功能寻址，诊断仪用功能寻址向所有ECU发送指令，这个时候如果所有ECU都发送肯定响应，总线上将会有许多个肯定响应，必要性不大，所以我们就可以把禁止肯定响应指示位置为1，这时成功执行了诊断请求的ECU就不会再返回肯定响应，而因为某些原因没有成功执行诊断指令的ECU仍然返回否定响应，诊断仪还是可以判断哪个ECU没能执行成功。
② Bit 6-0 - 子功能参数值（0x00-0x7F）
这个字节的其余7位就是子功能参数值了，每个服务的子功能参数定义不同，我们会在讲每个服务的时候详细讲。
第三个字节及后面的字节是诊断参数或数据，这个需要会根据具体服务来变化，有的服务有参数有的没有参数。
2. 不带子功能的服务
不带子功能的服务请求格式就比较简单，就是服务标识符SI+其它参数或数据。同样，后面的参数也不是每个服务都有。
对比可知，只有带子功能的服务，才有禁止肯定响应指示位，才能被禁止肯定响应，没有子功能的服务不能被禁止肯定响应。
06
肯定响应格式
以上两种诊断请求格式，所对应的诊断肯定响应格式如下：
带子功能诊断请求的肯定响应格式：
不带子功能诊断请求的肯定响应格式：
要注意的是响应中的子功能参数和请求中相同，但其它参数和请求中的参数通常都不同。
07
否定响应格式
诊断仪发给ECU诊断请求之后，ECU会判断当前指令是否能够执行，如果能执行则返回肯定响应，不能执行则返回否定响应。举个例子来说，当想用22读取数据服务指令来读取一条数据信息的时候，如果ECU中没有该数据信息，则会返回否定响应。
否定响应的格式如下：
字节3的否定响应码指示了否定响应的原因，是一字节无符号数，范围划分如下：
0x00：肯定响应参数值，保留给ECU内部使用。
0x01-0x7F：通讯相关的否定响应码。
0x80-0xFF：当想要返回NRC 22（条件不满足）的时候，如果能进一步确定是哪个条件不满足，这个范围内的否定响应码就可以用来指示条件不满足的具体情况。
常见的否定响应码如下，更为详细的内容请查阅14229-1 附录A：
大多数否定响应码都可以根据字面意思知道它所代表的含义，这里着重解释几个否定响应码：
0x22-条件不满足：这个的意思是ECU收到诊断请求的时候，一些内外部条件不允许执行这个指令，比如某些诊断指令执行的时候要求车速为零，如果不为零就会返回0x22。这个条件通常指内外部一些硬件或车辆运行环境的条件。
0x31-请求超出范围：我们上文在讲诊断请求格式的时候提到，请求中有时会带有参数，如果这个参数ECU不支持，就会返回0x31。要注意它和NRC 0x12-子功能不支持的区别。
0x21和0x78的区别：0x21表示ECU正在忙于处于其它诊断请求，当前收到的诊断请求不能再执行，相当于直接拒绝了；而0x78表示ECU已经正确接收到当前的诊断请求，但处理这个请求需要的时间比较长，没有办法在预定的时间内返回响应，要求诊断仪延长等待时间。这块儿的时间处理我会在讲传输层时间参数的时候再详细讲。
当寻址方式为功能寻址时，如果否定响应码为某些特定的否定响应码，标准规定ECU应不发送否定响应，如NRC 0x11（服务不支持），因为功能寻址是一对多的，如果某个ECU不支持这个服务，那可能诊断仪的目的就不是为了让你执行的，也就没必要发送否定响应了。这些否定响应码包括：0x11/0x12/0x31/0x7E/0x7F。
其中0x7E/0x7F两个NRC在ISO 14229-1-2006版本中是要求返回的，但2013版本中不要求返回了，开发的时候要注意版本的区别。
08
报文示例
下面给大家展示一个诊断报文示例，这个是返回肯定响应的：
我们先不要管蓝色框中的字节，那是传输层的内容，我们后面再讲。
红框中的字节是诊断指令，这个是10服务，SI=0x10，子功能参数=0x01，请求中没有其他参数。
响应中SI=0x10+0x40=0x50，子功能参数和请求中相同，后面四个字节是参数。
绿色框中的内容就是CANoe软件在加载了CDD（诊断数据库）之后自动解析出来的诊断指令内容。
我们再来看一个否定响应的诊断请求：
图中，我们使用22服务读取数据的时候，发送的DID 00AA ECU不支持，所以返回了否定响应，NRC=0x31，代表请求超出范围。