UDS诊断：ClearDiagnosticInformation（SID 0x14）

做 UDS 抓包时，0x14 常被一句“发送清除故障，ECU 返回成功”带过。真正落到项目上，最容易出错的是清除范围、groupOfDTC 的取值，以及收到 0x54 后如何验证结果。

ClearDiagnosticInformation（SID：0x14）负责清除 ECU 保存的诊断信息。下面从一组最小报文开始，说明请求格式、响应判断和工程排查方法。

1. 先看完整报文

假设项目把 0xFFFF33 定义为一个可清除的 DTC 组，诊断工具发送：

方向	CAN ID	数据区
诊断仪 → ECU	0x7E0	04 14 FF FF 33 00 00 00
ECU → 诊断仪	0x7E8	01 54 00 00 00 00 00 00

其中第一个字节 0x04 或 0x01 是 ISO-TP PCI，真正属于 UDS 应用层的数据是“14 FF FF 33”和“54”。CAN ID、PCI 与填充字节不能当成 0x14 的参数。

2. 0x14 清除的内容

ClearDiagnosticInformation 清除的是 ECU 保存的诊断信息，通常包括：

DTC 状态字节 statusOfDTC；
快照数据 DTCSnapshotData（Freeze Frame）；
扩展数据 DTCExtendedData；
首次故障、最近一次故障等记录；
计数器、标志位、定时器及项目定义的其他存储内容。

因此，执行 0x14 前应先用 0x19 保存状态、快照和扩展数据。清除后现场的转速、电压、温度、里程等信息可能无法恢复。0x14 也不等于关闭故障策略：故障仍存在时，监控程序可能再次置位 DTC，保护或失效策略也可能继续保持。

3. 请求格式与 groupOfDTC

0x14 没有 SubFunction，基本请求由 SID 加 3 字节 groupOfDTC 组成：

字节	含义
1	SID，固定为 0x14
2	groupOfDTC 高字节
3	groupOfDTC 中间字节
4	groupOfDTC 低字节
5	MemorySelection，可选，由项目定义

例如 groupOfDTC = 0x123456，线上发送顺序是“12 34 56”，不能因为 ECU 内部采用小端存储就写成“56 34 12”。具体组和值域由 ODX、诊断数据库或 ECU 诊断规范定义；0xFFFFFF 是否代表“全部 DTC”也不能凭经验推断。

只有一个 DTC memory 时，常见请求为“14 12 34 56”；多个用户定义的 memory 可以追加一个 MemorySelection，例如“14 12 34 56 01”。最后这个 01 的含义同样由项目定义。

4. 客户端构造与响应判断

下面的示例只负责组装应用层数据，并区分正响应、传输错误和 NRC：

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>

#define SID_CLEAR_DIAGNOSTIC_INFORMATION 0x14u
#define SID_NEGATIVE_RESPONSE 0x7Fu
#define SID_CLEAR_DIAGNOSTIC_INFORMATION_PR 0x54u

typedef enum {
    UDS_CLEAR_OK = 0,
    UDS_CLEAR_INVALID_ARGUMENT,
    UDS_CLEAR_TRANSPORT_ERROR,
    UDS_CLEAR_PROTOCOL_ERROR,
    UDS_CLEAR_NRC
} UdsClearResult;

UdsClearResult Uds_ClearDiagnosticInformation(
    IsoTpRequestFn isotp_request,
    uint32_t group_of_dtc,
    bool has_memory_selection,
    uint8_t memory_selection,
    uint8_t *negative_response_code)
{
    uint8_t request[5];
    size_t request_length = 4u;
    uint8_t response[3];
    size_t response_length = 0u;

    if (isotp_request == NULL || group_of_dtc > 0x00FFFFFFu)
        return UDS_CLEAR_INVALID_ARGUMENT;

    request[0] = SID_CLEAR_DIAGNOSTIC_INFORMATION;
    request[1] = (uint8_t)(group_of_dtc >> 16);
    request[2] = (uint8_t)(group_of_dtc >> 8);
    request[3] = (uint8_t)group_of_dtc;
    if (has_memory_selection) {
        request[4] = memory_selection;
        request_length = 5u;
    }

    if (isotp_request(request, request_length, response, sizeof(response),
                      &response_length, 2000u) != 0)
        return UDS_CLEAR_TRANSPORT_ERROR;

    if (response_length == 1u && response[0] == SID_CLEAR_DIAGNOSTIC_INFORMATION_PR)
        return UDS_CLEAR_OK;

    if (response_length == 3u && response[0] == SID_NEGATIVE_RESPONSE &&
        response[1] == SID_CLEAR_DIAGNOSTIC_INFORMATION) {
        if (negative_response_code != NULL)
            *negative_response_code = response[2];
        return UDS_CLEAR_NRC;
    }
    return UDS_CLEAR_PROTOCOL_ERROR;
}

收到“54”表示服务处理完成，它不返回“清除了几条 DTC”的列表。收到“7F 14 NRC”时，应按 NRC 定位问题：

“0x13”：长度或格式错误，检查是否至少包含 SID 和 3 字节 groupOfDTC；
“0x22”：条件不满足，检查会话、车辆状态、存储器是否忙；
“0x31”：请求范围不支持，回到项目的 DTC 分组定义；
“0x72”：非易失性存储写入失败，检查存储器和电源条件。

5. ECU 端处理顺序

ECU 端通常先检查长度和 SID，再读取 MemorySelection，按大端顺序组合 groupOfDTC，随后检查清除条件、DTC 组支持情况和存储器写入结果。错误分别返回“7F 14 13”“7F 14 22”“7F 14 31”或“7F 14 72”；全部通过后返回“54”。项目若只支持一种请求长度，应进一步收紧长度判断。

6. 清除后的验证

比较稳妥的流程是：

先用 0x19 保存目标 DTC 的状态、快照和扩展数据；
按 ECU 规范决定是否需要 0x10 会话切换或 0x27 安全访问；
发送“14 + groupOfDTC [+ MemorySelection]”，等待“54”或“7F 14 NRC”；
再次读取 0x19，结合状态位和故障是否复现确认结果。

清除后 statusOfDTC 不一定是 0x00。没有新的故障测试结果时，常见值是 0x50：Bit4 和 Bit6 表示清除后相关测试尚未完成，其余故障状态位已经复位。若故障再次出现，应区分“清除动作成功”和“故障被再次检测到”。

7. 现场排查要点

如果收到 54 后 DTC 又出现，先确认车辆或台架条件是否仍会触发故障、0x19 查询的是否是同一个 DTC memory，以及状态位是否只是 Bit4/Bit6 为 1。如果收到“7F 14 31”，不要继续盲试 0xFFFFFF 或 0x000000，应查项目定义。如果使用功能寻址，还要明确多个 ECU 的响应和清除后的分别验证。

结语

0x14 的应用层格式很短：请求是“14 groupOfDTC[3字节] [MemorySelection]”，正响应是“54”，负响应是“7F 14 NRC”。工程上最重要的是按项目定义填写 groupOfDTC、清除前保存现场、收到 54 后再次读取 0x19，并按状态位和故障是否复现判断结果。CAN ID 和 ISO-TP PCI 属于传输层配置，不属于 0x14 服务定义。

参考：ISO 14229-1:2020，第 12.2 节 ClearDiagnosticInformation，以及附录 D.2 DTC 状态位定义。