ISO 14229标准讲解：UDS协议

在上一篇文章《ISO 14229标准讲解：UDS简介》中，我们对汽车诊断、UDS协议的概念和其在OSI基础参考模型上的应用有了一个简单的认识，而本篇文章以ISO 14229-1标准为指导，聚焦于UDS协议本身，讲解其定义的诊断服务、诊断流程和通用化诊断数据格式。

1 诊断服务

UDS诊断服务实际就是各种诊断功能和操作的集合，旨在为车辆提供执行诊断、编程、配置和控制的能力。

在ISO 14229-1-2020版标准中，一共定义了26种UDS诊断服务，并为这些服务提供了标准化的接口和使用方法。每个UDS诊断服务都有唯一的服务标识符，即ServiceID(SID)，其用于在诊断流程中标识要执行或响应的诊断服务。部分UDS诊断服务还提供对子功能(sub-function)的支持。子功能是对诊断服务功能的细化和补充，其为Tester与ECU的交互提供了更详细的诊断指令集。Tester在请求诊断服务时，通过子功能可以更精细地控制诊断过程，使得诊断过程更加精确和高效。

在ISO 14229-1-2020版标准中定义的所有UDS诊断服务都被划分到六大功能单元，由下表分别可见，其中标绿的诊断服务为常用的诊断服务，需要重点关注和学习。

1.1 诊断和通信管理功能单元

1.2 数据传输功能单元

1.3 存储数据传输功能单元

1.4 输入输出控制功能单元

1.5 例程控制功能单元

1.6 上传下载功能单元

2 诊断流程

我们知道，在进行车辆诊断的时候，Tester与ECU是采用一问一答的形式进行通信。Tester首先向ECU发送诊断请求报文，在该诊断请求报文里，会包含一些必要的诊断信息，例如需要执行的诊断服务和执行诊断服务所需的参数。当ECU收到诊断请求报文后，会去解析诊断请求报文，并根据诊断请求的要求执行对应的诊断服务。若诊断服务执行成功，则将执行后的诊断结果数据打包到诊断响应报文并发送给Tester，这种诊断响应一般被称为肯定响应或正响应；若诊断服务执行失败，则将执行诊断服务失败的原因打包到诊断响应报文发送给Tester，这种诊断响应一般被称为否定响应或负响应。

车辆诊断具体流程如下所示：

• 第一步，Tester与车辆建立通信连接
• 第二步，Tester向ECU发送诊断请求报文
• 第三步，ECU接收诊断请求报文并解析
• 第四步，ECU执行诊断服务
• 第五步
  • 若执行成功，ECU向Tester发送诊断肯定响应报文
  • 若执行失败，ECU向Tester发送诊断否定响应报文
• 第六步，Tester接收诊断响应报文并解析

在肯定响应报文里，可能会包含车辆状态信息、ECU状态信息、故障码等关键数据，而在否定响应报文里，则会包含诊断服务执行失败的原因，汽车工程师可以利用这些数据对车辆做进一步分析。

3 诊断数据格式

虽然在ISO 14229-1标准中定义的诊断服务多达26种，但是，所有诊断服务的诊断请求数据格式和诊断响应数据格式都被UDS协议统一定义。

3.1 诊断请求数据格式

诊断请求用于Tester向车辆请求某个ECU或整车ECU执行某种诊断服务，要进行车辆诊断，必须先发起诊断请求。UDS诊断请求数据格式由三个参数组成，详细可见下表：

• ServiceID(SID)：诊断服务标识符，用于标识请求执行的诊断服务，其类型为1byte无符号整型
  • 对于所有的诊断请求，SID字节的bit6 = 0
• sub-function：子功能，用于标识诊断服务执行的具体细节，其类型为1byte无符号整型
  • 该参数为可选参数，某些诊断服务不支持子功能，因此也就不需要这个参数
  • 该1byte参数由bit7正响应抑制位（suppressPosRspMsgIndicationBit, SPR）和bit0-6子功能参数（sub-function parameter value）构成
    • SPR = 0，用于指示ECU需要给出正响应。若某个诊断服务不支持子功能，即没有本字节时，则默认需要ECU给出正响应
    • SPR = 1，用于指示ECU不要给出正响应。其目的在于减少ECU非必要响应的发送，从而节约系统通信资源
• diagnostic request data：诊断请求数据，其应包含执行诊断服务所需的所有数据
  • 该参数为可选参数，某些诊断服务的正常执行不需要该参数

UDS协议定义了两种不同寻址方式的诊断请求，分别为：物理寻址（physical addressing）和功能寻址（function addressing）

• 物理寻址：采用端对端的通信方式，Tester发送诊断请求给某个ECU
• 功能寻址：采用广播的通信方式，Tester发送诊断请求给整车ECU¹

3.2 诊断响应数据格式

当车辆ECU收到来自Tester的诊断请求后，会去执行对应的诊断服务，若诊断服务执行成功，则会向Tester回复肯定响应（Positive Response），反之，则向Tester回复否定响应（Negative Response），这两种诊断响应，都有统一的数据格式。

3.2.1 肯定响应

UDS诊断肯定响应数据格式由三个参数组成，详细可见下表：

• ServiceID(SID)：诊断服务标识符，用于标识肯定响应对应的诊断服务，其类型为1byte无符号整型
  • 对于所有的诊断肯定响应，SID字节的bit6 = 1，这也就是诊断肯定响应中SID参数值等于对应诊断请求中SID参数值加0x40的原因
• sub-function：子功能，回显对应诊断请求的sub-function参数，其类型为1byte无符号整型
• diagnostic response data：诊断响应数据，其应包含执行诊断服务成功后的所有诊断结果数据
  • 该参数为可选参数，某些诊断服务的正常执行不存在诊断结果数据

3.2.2 否定响应

诊断否定响应数据格式由三个参数组成，详细可见下表：

• Negative Response SID：诊断否定响应的特定标识符，其值为固定值：0x7F
• ServiceID(SID)：诊断服务标识符，用于标识否定响应对应的诊断服务，其类型为1byte无符号整型
• Negative Response Code(NRC)：诊断否定响应码，用于指示诊断请求否定响应的原因，其类型为1byte无符号整型

3.2.3 NRC

在UDS协议中，NRC码用于指示诊断服务执行失败（否定响应）的具体原因，其大小为一个字节，不同取值对应不同的否定响应原因。在ISO 14229-1-2020版标准中，NRC码的取值范围从0x00 — 0xFF被分成了三个部分：

• 0x00：positiveResponse参数，为ECU内部实现所保留，不能在否定响应中使用
• 0x01 — 0x7F：与通信相关的否定响应码
• 0x80 — 0xFF：指示不满足执行诊断服务特定条件的具体原因的否定响应码，这些NRC可以附加在NRC 0x22(conditionsNotCorrect)的后面，用于更加详细的解释为什么诊断请求无法被执行。

在ISO 14229-1-2020版标准中定义的所有NRC码可参见下表：

1. OEM会定义一个特殊的地址用于指示功能寻址，例如：吉利汽车的功能寻址地址即为0x1FFF。 ↩︎