作为一个汽车产品人，不可避免的会接触到各种车端通信协议，其中的UDS（Unified Diagnostic Services）诊断协议，广泛应用于汽车电子系统的诊断和维护。这篇文章，我们来学习一下。

一、ECU

ECU（ Electronic Control Unit）电子控制单元，车上搭载着许多ECU，用来监控和控制车辆的各个系统，如变速器控制单元（TCU）、电子稳定程序控制单元（ESP）、动力电池管理模块（BMS）等。各ECU根据各种传感器提供的信号，按照预先编写的程序进行计算和判断，从而控制执行器工作，以实现对汽车各系统的精确控制。

二、UDS诊断协议

当我们身体的某个部位不舒服时，我们可以去医院看医生，这个时候医生会询问我们的感受，开具一些检查来了解情况。同样的，当车辆某个系统或部件有问题时，我们也需要通过某种手段获取车辆的数据信息，以更好的进行治疗。UDS诊断协议就是我们和车辆ECU进行诊断沟通的一个通用手段。

UDS(Unified Diagnostic Services，统一诊断服务)诊断协议是一种广泛应用于汽车电子控制系统中的标准化诊断协议，基于ISO 14229标准。它为汽车电子控制单元（ECU）之间的诊断通信提供了一套统一的框架和服务。这使得不同品牌的汽车和不同制造商的ECU可以使用相同的诊断工具进行诊断，大大提高了诊断的便利性和效率。

UDS诊断提供的能力包括

• 诊断通信：通过标准化的服务（如0x10会话控制、0x22读取数据、0x2E写入数据）与ECU交互。
• 故障管理：支持DTC（Diagnostic Trouble Code，故障码）的读取、清除和存储。
• ECU编程：用于固件更新（如通过0x34请求下载、0x36传输数据）。
• 安全访问：通过安全算法（如种子-密钥机制）防止未授权操作。

SID：UDS诊断协议定义了26种诊断服务，这些服务被分为6大类，每种服务都有一个唯一的服务标识符（SID）。

Sub-function：每个诊断服务下的子功能，有的诊断服务不需要指定子功能。Sub-function共有8个bit。

• bit7：正响应抑制位，全称Suppress Positive Response，bit7=1时，抑制正响应，此时不需要ECU给出响应，bit7=0时，需要ECU给出响应。
• bit6~bit0：这7个bit用来指定具体的Sub-function。

UDS诊断协议针对每一个服务，都详细介绍了服务的功能范围、给出了请求消息的定义要求、肯定响应消息的定义要求、受支持的否定响应代码（NRC），以及消息流示例。

三、UDS诊断服务

下面介绍几个车联网产品经理需要了解的常用服务

10服务：诊断会话控制

10服务用于启用ECU中的不同诊断会话。不同的诊断会话支持的服务权限不同。

请求消息

diagnosticSessionTypes诊断会话类型，第7位为正响应抑制位，第6至0位定义诊断会话类型。

• 默认会话（0x01）：这是ECU上电时的初始会话模式。在默认会话下，ECU支持一些基本的诊断服务，例如读取数据（0x22）、清除诊断信息（0x14）、读取诊断信息（0x19）等。
• 编程会话（0x02）：编程会话用于ECU的软件更新和配置。在编程会话下，ECU支持一些特定的诊断服务，例如编程服务（0x35、0x36、0x37）。
• 扩展会话（0x03）：扩展会话用于启用一组特定的诊断服务和功能。在扩展会话下，ECU支持一些高级的诊断服务，例如安全访问（0x27）、数据写入（0x2E）等。

肯定响应消息

sessionParameterRecord会话参数记录定义如下，其中

P2Server_max：表示ECU在应用层上对诊断命令的响应时间。如果ECU在该时间内未能响应，可以认为通信超时。

P2*Server_max：表示ECU在强化模式下对诊断命令的响应时间。强化模式通常用于ECU暂时无法处理当前诊断命令的情况，ECU会发送一个NRC 0x78（RequestCorrectlyReceivedResponsePending）响应，表示请求已接收但响应待定。P2*Server_max定义了服务器在这种情况下可以等待的最长时间。

19服务：读取DTC信息

19服务支持读取故障码（DTC，全称Diagnostic Trouble Code）信息。故障码由制造商预先定义，可以简单理解为给车辆的每个故障一个代号。当我们读到DTC时，根据代号就知道发生了什么故障。

19服务比较复杂，其下有27个子功能，常用的子功能包括：（Sub-function第7位为正响应抑制位，第6至0位定义具体子功能。）

• 0x01：reportNumberOfDTCByStatusMask – 读取符合状态掩码条件的DTC数量。
• 0x02：reportDTCByStatusMask – 读取符合状态掩码条件的DTC列表及其状态。
• 0x03：reportDTCSnapshotIdentification – 报告DTC快照记录的标识。
• 0x04：reportDTCSnapshotRecordByDTCNumber – 通过DTC编号报告DTC快照记录。
• 0x06：reportDTCExtendedDataRecordByDTCNumber – 通过DTC编号报告DTC扩展数据记录。
• 0x0A：reportSupportedDTC – 报告ECU支持的所有DTC及其状态。

1901（读取DTC数量）

比如我们要获取ECU中已确认DTC的数量。获取DTC数量需要使用19 01服务，我们先看下01服务的

请求消息的定义要求、肯定响应消息的定义要求。

请求消息

DTCStatusMask（DTC状态掩码）：

状态掩码共有8个状态位，通过状态掩码，我们可以精确地获取特定状态的DTC信息。比如我们请求消息的状态掩码的某一位设置为1，如果DTC的实际状态位中的这一位也为1（即请求掩码与DTC的实际状态进行位逻辑AND运算，并且结果不为零），那么认为DTC的状态与状态掩码是匹配的。

肯定响应消息

DTC状态可用性掩码：用于指示ECU支持的DTC状态位。比如某个ECU的DTC状态可用性掩码为0x09，表示仅支持以下状态位：Bit 0：Test Failed（测试结果是失败）、Bit 3：Confirmed DTC（确认的DTC）。

DTCFormatIdentifier(DTC格式标识符）：定义了ECU所报告DTC的格式

DTCCount(DTC计数）：DTC数量

示例

现在我们获取ECU中已确认DTC的数量，请求消息中的状态掩码应设置为0x08，所以请求消息为

若收到响应消息如下，说明该ECU支持的DTC状态可用性掩码为0x2F，DTC格式为14229，DTC数量为1。

22服务：通过DID读取数据

22服务支持读取ECU中通过一个或多个DID所识别的数据记录值。

DID（Data Identifier）数据标识符。DID的编码范围为16位（0x0000–0xFFFF），其具体含义和用途根据标准化定义或车辆制造商自定义而有所不同。由UDS协议进行标准化定义的DID中常用的有

• F190：车辆识别号（VIN）
• F191：ECU硬件号
• F189：ECU软件版本号
• F18C：ECU序列号

请求消息

肯定响应消息

示例

比如我们想读取VIN，VIN的DID为F190，所以请求消息

响应消息如下，VIN的数据格式为17字节，ASCII编码。

四、诊断与车联网

远程诊断与OTA

基于UDS诊断协议，再结合车联网技术，把原先通过线下诊断工具排查解决车辆问题的过程放到线上云端，就有了远程的车辆诊断。远程诊断可以实现车辆故障的高效诊断与快速响应，降低维修成本，提升用户体验。同样的，把原先通过线下刷写工具刷写软件放到线上云端，就有了OTA远程更新。