来源：电控知识搬运工
车辆的诊断需要有Tester端和ECU端，Tester端和ECU端通过一问一答的形式进行通信，因而Tester端和ECU端都需要遵循同样的诊断通信协议，常用的诊断协议有ISO 14230，ISO 15031，ISO 15765，还有我们熟悉的ISO 14229就是UDS协议，在协议里面定义了诊断的请求，诊断响应的报文格式，以及ECU怎样处理诊断请求报文，以及诊断服务的应用。
UDS是Unified Diagnostic Services的缩写，在国际标准ISO 14229-1中定义，UDS标准中除了定义服务的用法，以及服务的格式以外，还定义了一些标准化的数据，而到OEM要使用UDS协议时，除了要使用标准定义的服务以及标准数据以外，还要依据自身的情况，定义属于OEM的特定数据，比如说，定义所要遵循的服务，需要支持的DID，需要支持的DTC等这些内容，这样形成的符合某OEM的诊断规范才能用于ECU诊断功能的开发以及验证。
随着车辆ECU的增多，车辆网络拓扑结构也越来越负责，比如说一辆车需要有多种总线（CAN总线，LIN，以太网，FlexRay），所以在2013年释放的UDS协议中，除了对通用诊断服务的定义以外，还增加了关于UDS在各个总线中应用的定义。
如果我们说UDS诊断服务是实现人或设备与ECU控制器交流的一种语言，那么诊断服务的响应规则就如同是语法，而SID（Service ID）定义就如同词汇。因此了解响应规则和SID的意义就基本能了解与ECU沟通的方法和含义。本文先来介绍一下响应规则。
1.寻址方式
在总线上往往有着众多ECU设备，作为诊断设备既可以与所有的ECU一起沟通，也可以指定某一个ECU单独沟通。所以寻址方式就有功能寻址（Functionally Addressed）和物理寻址（Physically Addressed）两种。
功能寻址
功能寻址可以广播诊断请求Request，同时等待总线上的ECU给与响应。
物理寻址
物理寻址指定发送特定诊断请求Request，等待指定ECU给与响应。
因此我们的诊断报文一般会有三个CAN ID，其中DiagRequest（诊断物理请求报文）和DiagState（诊断功能请求报文）是ECU接收来自Client的报文，而DiagRespone（诊断响应报文）是ECU反馈的报文。
例如下图的0x7FF和0x731分别是功能请求报文和物理请求报文，而0x7B1则是诊断响应报文。
2.请求和响应格式
诊断请求Request
UDS服务中共定义了26个服务请求SID（Service ID），每个SID代表了一类指令。由于有些服务请求还需要表达具体的功能类型，比如是开启还是关闭，是读取还是修改等，因此UDS中还定义了Sub-function来补充SID的意图。另外服务请求有时候还需要告知ECU具体的参数信息Parameter，例如计数信息。因此诊断请求的格式基本上是SID + Sub-function + Parameter三部分组成的，其中SID一个byte，Sub-function一个byte（其中最高位是禁止肯定响应指示位，0则表示需要肯定响应，1则表示禁止肯定响应），Parameter根据具体情况定义。
肯定响应Postive Response
收到Client的诊断请求后，ECU可能反馈肯定响应或者否定响应。肯定响应在诊断请求的SID上+0x40表示确认。例如诊断请求SID为0x10，则肯定响应反馈0x50。
否定响应Negative Response
USD诊断服务的否定响应中包含有导致否定响应原因的编码，称为否定响应码(NRC, Negative Response Code)。否定响应码的取值范围为0x00 - 0xFF，被分为三组：
0x00：服务器内部实现否定响应码判断逻辑时使用，表示要给出肯定响应。
0x01 – 0x7F：诊断通信相关的否定响应码。
0x80 – 0xFF：服务器收到诊断服务请求时，由于某些条件不满足要求而给出的否定响应码。给出这些否定响应码而不是给出0x22的目的是为了提供请求的服务不能被执行的更详细的原因。
当ECU反馈为否应响应时格式为，NR_SI(否定响应服务码0x7F) + SID（否定的请求服务SID）+ NRC（否定响应码，表示否定的理由）。
这里列举了常用的诊断服务所支持的否定响应码。如下表：
否定响应码定义及其取值
下表中列出了ISO14229-1:2013(E)中定义的否定响应码及其使用条件。
