2. 诊断工具链与标准
驾驶辅助系统的故障诊断，本质上是在“车辆网络—控制单元—传感器/执行器—诊断仪”之间建立一条可解释的数据通路。Bosch 驾驶辅助系统（如雷达、摄像头、域控制器）通常同时支持多种诊断入口：产线/售后使用的 Bosch 专用诊断仪（如 Bosch KTS 系列配合 ESI[tronic] 或相关诊断软件）、通用 OBD-II 接口，以及基于 UDS（ISO 14229）的诊断服务。理解这三者的分工与边界，是后续读码、清码、看数据流和写报告的前提。
一、工具链的三层结构：物理层、协议层、应用层
从工程视角看，诊断工具链可以拆成三层：物理接入层决定“用什么插头、走哪条总线”；协议层决定“用什么语言对话”；应用层决定“读什么、怎么解释”。Bosch 专用诊断仪的优势在于应用层：它内置了针对 Bosch 雷达、摄像头、域控的 ODX/OTX 描述文件，能直接给出 DTC 的故障描述、可能原因、引导型测试步骤和维修建议。通用 OBD 接口的优势在于物理层与排放相关服务的普适性，但面对 ADAS 私有 DTC 和标定数据时往往只能看到“冰山一角”。UDS 则是两者共同依赖的“会话语言”。
二、UDS 服务：读码与清码的实际操作
UDS 不是“一个按钮”，而是一组带子功能的服务。诊断仪与 ECU 的典型交互如下：
# 进入扩展会话（0x10 0x03）
发送: 10 03
响应: 50 03 00 32 01 F4
# 安全访问（0x27）：请求种子
发送: 27 01
响应: 67 01 12 34 56 78
# 发送密钥（示例，实际由算法生成）
发送: 27 02 87 65 43 21
响应: 67 02
# 读取 DTC（0x19 0x02，报告已确认的 DTC）
发送: 19 02 FF
响应: 59 02 FF 00 01 2A 08 24 00 01 2B 08 25 00
# 清除 DTC（0x14 0xFFFFFF）
发送: 14 FF FF FF
响应: 54这里有两个容易踩坑的点。第一，会话与安全等级不匹配：很多 ADAS ECU 要求先进入扩展会话（0x03），再通过 0x27 解锁，否则 0x14 清除请求会返回否定响应 0x7F 14 33（安全访问被拒）。第二，DTC 状态字节：响应中的 08 表示“已确认 + 测试失败”，24 表示“已确认 + 测试未完成”，25 表示“已确认 + 测试失败 + 警告指示”。只看 DTC 编号不看状态字节，容易把“历史码”误判为“当前故障”。
三、DTC 读取与清除的工程判断
读码不是目的，判断“这个码该不该清、清完会不会回来”才是。建议按以下顺序处理：
- 先读冻结帧：用 0x19 0x04 读取 DTC 快照，关注车速、电压、温度、雷达目标数量等环境参数。若冻结帧显示故障发生在 9V 低压瞬间，优先查供电而非换件。
- 再读扩展数据：用 0x19 0x06 读取 DTC 扩展信息，包括发生次数、老化计数器、上次清除后的里程。发生次数高但老化计数器已归零，说明故障可能已自愈。
- 清码前记录：清除前务必导出报告或截图，因为 0x14 会同时清掉冻结帧和扩展数据，这些是后续复现和判责的关键证据。
- 清码后验证：清除后不要立即交车。应执行一次完整的驾驶循环（如车速 > 30 km/h、转向角变化、雷达目标出现），再用 0x19 0x02 复读。若同一 DTC 在 1 个循环内重现，说明是硬故障；若 3 个循环后才重现，多为间歇性接触不良。
四、诊断报告解读：从“码”到“结论”
一份可用的诊断报告至少应包含：车辆识别信息（VIN、里程）、诊断仪与软件版本、ECU 硬件/软件版本、DTC 列表（编号 + 状态字节 + 冻结帧摘要）、清除前后对比、以及结论与建议。解读时重点关注三类信息：
| 报告字段 | 示例值 | 解读要点 |
|---|---|---|
| DTC 编号 | C1A00-01 | Bosch 私有码，需查 ODX 描述；通用 OBD 可能只显示 P 码 |
| 状态字节 | 0x08 / 0x24 / 0x25 | 区分当前故障、历史故障、警告指示 |
| 冻结帧电压 | 10.8 V | 低于 11 V 优先查电源与搭铁 |
| 发生次数 / 老化 | 12 次 / 0 | 次数高但老化归零，倾向间歇性 |
| 软件版本 | SW 03.12.00 | 与已知 TSB 或召回版本比对 |
最后强调一个原则：诊断报告不是“码的堆砌”，而是“证据链”。每一个结论都应有对应的 DTC、冻结帧或数据流支撑。例如，报告写“雷达传感器通信故障”，应附上 UDS 响应中的 0x7F 否定码、总线负载率或网关路由状态；报告写“建议更换雷达”，应说明已排除供电、搭铁、插接件和标定问题。只有这样，诊断报告才能被售后、质量或研发环节真正采信。