📚 课程目录第3章整车诊断协议栈基础

3. 整车诊断协议栈基础

在 S32G 整车诊断与 OTA 系统中，诊断协议栈是“诊断仪—网关—目标 ECU”之间所有交互的公共底座。它并不是单一协议，而是由应用层、传输层、网络层与链路层共同拼装起来的一套分层体系：UDS 定义“问什么、怎么答”，DoIP 与 CAN/CAN FD 定义“怎么把这段报文送到对端”，寻址与会话管理则决定“谁在跟谁说话、当前处于什么状态”。理解这三层如何咬合，是后续做诊断路由、OTA 刷写和远程运维的前提。

一、UDS ISO 14229：诊断服务的语义层

UDS（Unified Diagnostic Services，ISO 14229-1）位于应用层，它规定了诊断请求与响应的服务标识（SID）、子功能、数据参数以及肯定/否定响应规则。整车开发中最常用的服务大致分为几类：

诊断会话控制（0x10）：切换默认会话、编程会话、扩展会话，是所有后续操作的门槛。
安全访问（0x27）：通过种子—密钥（Seed/Key）算法解锁受保护服务，例如写入、刷写。
读写数据（0x22 / 0x2E）：按 DID（Data Identifier）读取或写入 ECU 内部数据。
例程控制（0x31）：启动、停止、请求例程结果，常用于自检、标定、擦除。
DTC 相关（0x19 / 0x14 / 0x85）：读取故障码、清除故障码、控制 DTC 设置。
传输相关（0x34 / 0x36 / 0x37）：请求下载、传输数据、请求退出传输，是 OTA 刷写的核心。

UDS 报文有明确的格式约定。请求报文首字节为 SID，若该服务带子功能，则第二字节为子功能并常带 suppressPosRspMsgIndicationBit（0x80）。响应分为肯定响应（SID+0x40）与否定响应（0x7F + 原SID + NRC）。例如请求 10 03（进入扩展会话），肯定响应为 50 03；若 ECU 当前不允许，则返回 7F 10 22，其中 0x22 表示 conditionsNotCorrect。NRC 是排障时最重要的线索之一，常见值包括 0x11（服务不支持）、0x12（子功能不支持）、0x13（报文长度错误）、0x22（条件不满足）、0x31（请求超出范围）、0x33（安全访问被拒）、0x78（响应挂起，需继续等待）。

二、DoIP ISO 13400：以太网上的诊断承载

随着 S32G 这类高性能网关引入车载以太网，DoIP（Diagnostic over IP，ISO 13400）成为 UDS 在以太网上的标准承载方式。DoIP 把 UDS 报文封装进 DoIP 消息，通过 TCP/UDP 传输：UDP 用于车辆发现与状态查询，TCP 用于诊断数据通道。DoIP 报文头固定 8 字节，包含协议版本、取反版本、载荷类型（Payload Type）、载荷长度，其后才是 UDS 数据。

典型流程是：诊断仪先通过 UDP 广播车辆识别请求（0x0001），车辆回应车辆识别响应（0x0004），其中携带逻辑地址与 VIN；随后诊断仪与目标建立 TCP 连接，发送路由激活请求（0x0005），车辆返回路由激活响应（0x0006）；激活成功后，诊断仪用诊断消息（0x8001）承载 UDS 请求，车辆用诊断消息肯定/否定响应（0x8002/0x8003）回传。DoIP 的关键参数包括逻辑地址（如诊断仪 0x0E00、网关 0x1000、目标 ECU 0x1A00 等示例值）、TCP 端口 13400、以及路由激活类型。逻辑地址是 DoIP 寻址的核心，它把“IP 地址”进一步细化为“车内哪个 ECU”。

三、CAN/CAN FD 诊断：经典链路与带宽升级

在 CAN 与 CAN FD 上，UDS 通过 ISO-TP（ISO 15765-2）传输。ISO-TP 解决的是“UDS 报文可能超过 8 字节”的问题，它定义了四种帧：单帧（SF）、首帧（FF）、连续帧（CF）、流控帧（FC）。发送方先发 FF 声明总长度，接收方回 FC 指示可以继续发送的块大小（BS）与最小间隔（STmin），发送方再按序发 CF。CAN FD 将单帧数据场扩展到最多 64 字节，使大量 UDS 报文可以单帧完成，显著减少分段与流控开销，这对 OTA 传输尤其有利。

诊断寻址在 CAN 上体现为诊断 ID 的分配。物理寻址（Physical Addressing）是点对点，例如功能寻址（Functional Addressing）用于广播，如 0x7DF 请求、各 ECU 在 0x7E8~0x7EF 响应。物理寻址请求通常为 0x7E0，响应为 0x7E8。功能寻址可以让多个 ECU 同时收到请求，但只有支持该服务的 ECU 才响应，因此常用于快速读取多 ECU 的会话状态或 DTC 数量。

四、会话管理与安全访问的配合

会话管理是 UDS 的“状态机”。ECU 上电后处于默认会话，只允许读取基本数据；要执行写入、例程或刷写，必须先通过 0x10 切换到扩展会话或编程会话。切换成功后，ECU 启动 S3 定时器（常见示例为 5000 ms），若在超时前没有收到任何诊断请求，则自动回落到默认会话。因此诊断仪在长时间操作中需要发送 TesterPresent（0x3E 0x80）来维持会话。

安全访问 0x27 通常与会话绑定：在扩展会话下请求种子（0x27 0x01），ECU 返回种子；诊断仪用约定算法计算密钥并发送（0x27 0x02 + Key），ECU 校验通过后解锁。若密钥错误，返回 NRC 0x35（invalidKey）；若尝试次数超限，可能返回 0x36（exceedNumberOfAttempts）或 0x37（requiredTimeDelayNotExpired）。在 S32G 网关场景中，网关自身也可能需要安全访问才能执行路由配置或刷写代理，因此会话与安全状态需要按 ECU 分别维护，不能混用。

五、一个可复现的诊断交互示例

假设诊断仪通过 DoIP 连接 S32G 网关，目标为某 ECU，逻辑地址 0x1A00。示例流程如下（参数为教学示例，非实测值）：

1) UDP 车辆识别请求  →  车辆识别响应（含 VIN、逻辑地址）
2) TCP 连接 13400，发送路由激活 0x0005  →  0x0006 成功
3) DoIP 诊断消息 0x8001 承载：10 03        →  50 03（进入扩展会话）
4) 27 01                                   →  67 01 + Seed
5) 27 02 + Key                             →  67 02（安全解锁）
6) 22 F1 90                                →  62 F1 90 + VIN 数据
7) 3E 80                                   →  7E 00（维持会话）
8) 10 01                                   →  50 01（回到默认会话）

观察要点：第 3 步若返回 7F 10 22，说明 ECU 当前条件不满足，可能是电压、车速或其它前置条件未满足；第 5 步若返回 7F 27 35，说明密钥计算错误；第 6 步若返回 7F 22 31，说明 DID 超出支持范围。每一步的 NRC 都直接指向不同的排查方向，这是 UDS 排障的基本方法。

在 S32G 网关上做诊断路由时，建议先确认三件事：目标 ECU 的逻辑地址或 CAN 诊断 ID 是否正确、当前会话是否允许该服务、安全访问是否已解锁。三者任一不满足，都会以 NRC 形式返回，而不是“无响应”。

六、CAN 与 DoIP 的选型与协同

CAN/CAN FD 诊断适合低带宽、确定性强的场景，如读取 DTC、常规数据流；DoIP 适合高带宽、大数据量场景，如 OTA 刷写、日志上传、远程诊断。S32G 作为网关，往往同时具备 CAN/CAN FD 与以太网接口，需要在内部完成协议转换与路由：诊断仪通过 DoIP 发来的 UDS 请求，网关解析逻辑地址后，可能转换为 CAN 上的 ISO-TP 报文转发给目标 ECU，再把响应回传为 DoIP 诊断消息。这个过程中，网关必须保持会话状态、安全状态与寻址映射的一致性，否则会出现“请求发出但目标不响应”或“响应回来了但诊断仪不认”的问题。

因此，整车诊断协议栈的基础可以概括为：UDS 定义服务语义，DoIP 与 CAN/CAN FD 定义承载方式，寻址决定目标，会话与安全决定权限。四者共同构成诊断交互的完整闭环，也是后续 OTA 与远程运维功能能够稳定运行的前提。