4. 诊断协议入门
在车载网关诊断路由与OTA工程中，诊断协议是贯穿始终的“语言体系”。无论是产线EOL检测、售后故障读取，还是OTA升级前的条件校验，都依赖一套分层协作的协议栈。本节从工程视角梳理UDS、OBD、DoIP、ISO-TP四类协议的基本概念、服务类型、会话管理与典型应用场景，帮助建立“谁在什么位置、解决什么问题”的整体认知。
一、核心原理：四类协议的分层协作
诊断通信不是单一协议，而是分层协作的结果。可以按“应用层—传输层—网络层”来理解：
- UDS（ISO 14229）：统一诊断服务，位于应用层，定义诊断请求与响应的服务语义，如读取故障码、写入数据、刷写程序。它不关心底层是CAN还是以太网。
- OBD（ISO 15031 / SAE J1979）：排放相关诊断，位于应用层，服务集较小，主要面向法规要求的排放与排放相关故障读取，常见于OBD-II接口。
- DoIP（ISO 13400）：基于IP的诊断，位于传输/网络层，把UDS消息封装到TCP/UDP之上，适用于以太网高带宽场景，如OTA刷写、大数据量日志读取。
- ISO-TP（ISO 15765-2）：CAN传输层，解决CAN帧只有8字节（经典CAN）或64字节（CAN FD）时，如何传输长诊断报文的问题，通过分帧、流控、重组实现。
四者关系可以概括为：UDS和OBD是“说什么”，ISO-TP和DoIP是“怎么送”。网关在中间承担路由与协议转换，把来自诊断仪的请求分发到目标ECU，再把响应回传。
二、服务类型：UDS与OBD的差异
UDS服务以SID（Service Identifier）标识，常用服务包括：
| SID | 服务名称 | 典型用途 | 会话依赖 |
|---|---|---|---|
| 0x10 | DiagnosticSessionControl | 切换默认/编程/扩展会话 | 默认会话可执行 |
| 0x11 | ECUReset | 复位ECU | 默认/扩展 |
| 0x14 | ClearDiagnosticInformation | 清除故障码 | 默认/扩展 |
| 0x19 | ReadDTCInformation | 读取故障码及状态 | 默认/扩展 |
| 0x22 | ReadDataByIdentifier | 按DID读取数据 | 默认/扩展 |
| 0x2E | WriteDataByIdentifier | 按DID写入配置 | 扩展/编程 |
| 0x27 | SecurityAccess | 安全解锁 | 扩展/编程 |
| 0x31 | RoutineControl | 执行例程（自检、擦除） | 扩展/编程 |
| 0x34/0x36/0x37 | RequestDownload/TransferData/RequestTransferExit | 刷写数据传输 | 编程会话 |
OBD服务则更精简，常见模式包括：0x01读取当前动力系统数据、0x02读取冻结帧、0x03读取排放相关故障码、0x04清除故障码、0x09读取车辆识别信息。OBD强调法规一致性与通用性，UDS强调功能覆盖与厂商可扩展性。
三、会话管理与安全访问
UDS的会话管理是诊断流程的“门禁系统”。默认会话下只能执行基础读取；进入扩展会话后可执行写入、例程；进入编程会话后才能进行刷写。典型流程如下：
1. 诊断仪发送 10 03 → 请求进入扩展会话
2. ECU 回复 50 03 00 32 01 F4 → 正响应，P2=50ms，P2*=5000ms
3. 诊断仪发送 27 01 → 请求安全访问种子
4. ECU 回复 67 01 XX XX → 返回种子
5. 诊断仪发送 27 02 YY YY → 发送密钥
6. ECU 回复 67 02 → 安全解锁成功
7. 诊断仪发送 2E F1 90 ... → 写入配置数据
8. ECU 回复 6E F1 90 → 写入成功会话超时是常见工程约束。若在P2时间内未收到响应，诊断仪会重试或报错；若会话保持时间S3超时，ECU会自动退回默认会话，正在进行的写入或刷写会被中断。因此，OTA刷写前必须确保会话保持与安全访问状态稳定。
四、应用场景与网关路由案例
不同协议对应不同场景：
- 产线EOL：通过DoIP或CAN，使用UDS 0x10/0x2E/0x31完成配置写入与功能自检。
- 售后诊断：OBD读取排放故障码，UDS读取全车DTC与冻结帧。
- OTA刷写：DoIP承载UDS 0x34/0x36/0x37，高带宽传输刷写包；网关负责将刷写请求路由到目标域控制器。
- 远程诊断：T-Box通过DoIP接入网关，网关再转换为CAN ISO-TP访问传统ECU。
以一个典型网关路由为例：诊断仪通过DoIP发送UDS 0x22 F1 90（读取VIN），目标地址为0x18DAF110。网关收到后，解析目标地址，判断该ECU位于CAN总线上，于是将UDS消息交给ISO-TP模块分帧，通过CAN发送；ECU响应后，网关再重组为DoIP报文回传诊断仪。整个过程对诊断仪透明，诊断仪只需面向UDS服务编程。
五、常见误区与复盘
- 误区一：把UDS等同于CAN。UDS是应用层协议，可跑在CAN、CAN FD、DoIP、LIN甚至FlexRay上。网关做协议转换时，必须区分“服务语义”与“承载方式”。
- 误区二：忽略会话与安全状态。很多写入失败并非报文错误，而是会话超时或安全访问未通过。排查时应先读0x10会话状态与0x27解锁状态。
- 误区三：OBD与UDS混用。OBD的0x03与UDS的0x19都能读故障码，但DTC格式、状态位、清除条件不同。网关路由时需按目标ECU支持的协议选择，不能简单透传。
- 误区四：DoIP只用于刷写。DoIP同样可用于常规诊断，尤其适合大数据量DTC快照、日志读取。网关需支持DoIP激活线、车辆声明、路由激活等状态管理。
复盘建议：在网关诊断路由开发中，先建立“协议—服务—会话—承载”四维矩阵，明确每个目标ECU支持哪些SID、需要什么会话、走哪条总线。再针对ISO-TP分帧参数、DoIP连接管理、会话超时做专项测试。只有把协议语义与路由行为对齐，才能保证诊断与OTA流程稳定可靠。