📚 课程目录第2章车载诊断基础

2. 车载诊断基础

车载诊断技术经历了从“排放法规驱动”到“软件定义汽车驱动”的深刻变革。OBD-II（On-Board Diagnostics II）是法规强制要求的排放相关诊断接口，UDS（Unified Diagnostic Services）是应用层统一诊断协议，而DoIP（Diagnostic over Internet Protocol）则是将UDS承载于以太网物理层的传输方案。理解三者的演进关系，是掌握现代诊断协议栈的基石。本章将梳理其技术脉络、协议分层与选型逻辑，帮助工程师建立从物理层到应用层的完整认知框架。

上图展示了三种诊断技术的演进脉络与协议栈分层关系。OBD-II 作为法规强制要求的基础诊断接口，主要面向排放相关系统；UDS 在应用层统一了诊断服务语义，使得不同 ECU 的诊断行为标准化；DoIP 则利用以太网的高带宽特性，将 UDS 服务扩展到高速刷写和远程诊断场景。三者并非简单的替代关系，而是在不同层级、不同应用场景下的互补组合。

2.1 核心原理：从法规驱动到功能驱动的技术跃迁

OBD-II 的本质是“排放法规的数字化接口”。它由 CARB（加州空气资源委员会）和 EPA（美国环保署）推动，1996年起在北美强制实施。OBD-II 规定了统一的诊断接口（DLC，16针）、标准化的故障码（DTC，如 P0100 表示空气流量计故障）、以及一组固定的 PID（Parameter ID，如 0x01 读取发动机转速）。其核心目标是确保车辆排放系统在生命周期内持续合规，因此诊断范围严格限定在排放相关部件（发动机、催化器、氧传感器、燃油系统等）。OBD-II 的传输层通常基于 CAN（ISO 15765）或早期的 K-Line（ISO 9141），波特率一般为 500kbps（CAN）或 10.4kbps（K-Line）。

UDS 是“统一诊断服务的应用层规范”，定义于 ISO 14229 标准。它不关心底层传输介质，而是规定了诊断服务的语义和格式。UDS 的核心是服务标识符（SID），例如 0x10（诊断会话控制）、0x22（按标识符读取数据）、0x2E（按标识符写入数据）、0x19（读取 DTC 信息）、0x27（安全访问）、0x34/0x36/0x37（请求下载、传输数据、请求退出传输，用于刷写）。UDS 引入了“会话管理”概念（默认会话、编程会话、扩展会话），不同会话下允许的服务集合不同，这为安全刷写和调试提供了分层权限控制。UDS 还定义了服务响应格式（正响应/负响应），负响应码（NRC）如 0x31（请求超出范围）、0x33（安全访问被拒绝）等，为故障定位提供了精确的语义。

DoIP 是“基于以太网的诊断传输协议”，定义于 ISO 13400 标准。它解决了 CAN 带宽不足（500kbps）和物理连接距离受限的问题。DoIP 使用 TCP 端口 13400 进行控制消息传输（如车辆识别、路由激活），使用 UDP 端口 13400 进行车辆发现（Vehicle Announcement）。DoIP 支持两种数据格式：DoIP header + payload，其中 payload 可以是 UDS 消息（通过 DoIP 的 Routing Activation 机制转发到目标 ECU）。DoIP 的典型应用场景包括：整车 OTA 刷写（需要高带宽）、产线 EOL 下线检测（需要快速配置多个 ECU）、远程诊断（通过 T-Box 连接云端）。

关键认知：OBD-II 是“法规接口”，UDS 是“应用语言”，DoIP 是“高速公路”。OBD-II 的 PID 是固定的、面向排放的；UDS 的 SID 是通用的、面向所有 ECU 功能的；DoIP 则提供了传输能力，使得 UDS 可以在更高带宽、更长距离的链路上运行。现代车辆诊断架构中，OBD-II 的 DLC 接口仍然保留（法规要求），但内部诊断流量已经全面转向 UDS over DoIP 或 UDS over CAN。

2.2 判断方法：如何根据场景选择诊断协议栈

在实际工程中，选择哪种诊断协议栈取决于三个关键维度：法规要求、带宽需求、物理层约束。以下判断流程可帮助工程师快速决策：

第一步：检查法规强制项。如果车辆需要满足 OBD-II 法规（北美市场）或 EOBD（欧洲市场），则必须保留 OBD-II 兼容的 DLC 接口和排放相关 PID 服务。即使内部使用 UDS，也必须提供 OBD-II 模式（ISO 15031-5）的映射。
第二步：评估带宽需求。如果诊断任务涉及 ECU 软件刷写（如升级 ADAS 控制器，固件大小可能超过 2GB），CAN 的 500kbps 带宽将导致刷写时间过长（理论需要 9 小时以上），此时必须选择 DoIP（100Mbps/1Gbps 以太网）。如果只是读取故障码、实时数据流（如发动机转速、车速），CAN 带宽足够。
第三步：考虑物理层约束。如果车辆已有以太网骨干网（如基于 SOME/IP 的域控制器架构），DoIP 是自然选择。如果车辆仍采用分布式 CAN 网络（如传统 BCM、门窗控制器），则 UDS over CAN 更经济。
第四步：评估远程诊断需求。若需要 T-Box 远程连接诊断仪，DoIP 是唯一可行方案（因为 CAN 无法直接穿透 IP 网络）。

维度	OBD-II	UDS over CAN	UDS over DoIP
法规驱动	强制（排放）	非强制（OEM 自选）	非强制（OEM 自选）
典型带宽	500 kbps	500 kbps	100 Mbps / 1 Gbps
诊断范围	排放相关 ECU	所有 ECU	所有 ECU，尤其域控制器
刷写能力	不支持（仅读）	支持（但慢）	支持（高速）
远程诊断	不支持	需网关转换	原生支持（IP 网络）
物理层	CAN / K-Line	CAN / LIN / FlexRay	以太网（100BASE-T1 / 1000BASE-T1）
典型工具	通用 OBD 扫描仪	OEM 诊断仪（如 VAS PC）	以太网诊断仪（如 CANoe.DiVa）

经验提醒：在混合架构中（如同时存在 CAN 和以太网），诊断仪需要支持“路由转换”。例如，诊断仪通过 DoIP 连接网关，网关再将 UDS 请求通过 CAN 转发到目标 ECU。此时，网关扮演了“DoIP-to-CAN 桥接器”的角色，需要处理地址映射（DoIP 的逻辑地址 ↔ CAN 的物理地址）和时序转换（以太网延迟 vs CAN 延迟）。

2.3 案例拆解：OTA 刷写中的协议栈协同

以某新能源车型的 OTA 升级为例，展示三种协议如何协同工作。该车型采用“中央网关 + 域控制器”架构，网关连接以太网骨干网和多个 CAN 子网。

背景与约束：需要升级智能座舱域控制器（固件大小 1.8GB）和 BCM（固件大小 2MB）。OTA 服务器通过 4G/5G 网络将固件包下发至车端 T-Box。升级时间要求：座舱域控制器不超过 15 分钟，BCM 不超过 5 分钟。

初始现象与目标：若采用 UDS over CAN 刷写座舱域控制器，CAN 有效数据速率约 400kbps（考虑协议开销），1.8GB 需要约 10 小时，远超目标。因此，座舱域控制器必须走 DoIP 链路。BCM 位于 CAN 子网，但固件较小，CAN 刷写可接受。

关键输入数据：座舱域控制器 DoIP 地址为 0x0001，BCM 的 CAN 物理地址为 0x01。网关的 DoIP 逻辑地址为 0x000E。T-Box 作为 DoIP 客户端，诊断仪（云端）通过 T-Box 转发诊断请求。

分析判断过程：诊断仪首先通过 DoIP 的 Vehicle Identification Request 发现车辆，获取 VIN 和网关地址。然后建立 TCP 连接，发送 Routing Activation Request 激活路由。对于座舱域控制器，诊断仪直接通过 DoIP 发送 UDS 0x34（请求下载）和 0x36（传输数据），数据块大小设置为 4KB（以太网 MTU 友好）。对于 BCM，诊断仪将 UDS 请求封装在 DoIP 消息中发送给网关，网关解析后转换为 CAN 帧（ISO 15765-2 的 CAN TP 协议），发送到 BCM 的物理地址。

实际操作步骤：

// 诊断仪侧伪代码
1. DoIP_Connect(IP: 192.168.1.10, Port: 13400);
2. DoIP_VehicleIdentificationRequest();
3. DoIP_RoutingActivation(SourceAddr: 0x0E00, TargetAddr: 0x000E);
4. // 刷写座舱域控制器
5. UDS_Send(0x10 0x02); // 进入编程会话
6. UDS_Send(0x27 0x01); // 请求种子
7. UDS_Send(0x27 0x02, Key); // 发送密钥
8. UDS_Send(0x34 0x00 0x44, DataLen: 0x00080000); // 请求下载 512KB
9. UDS_Send(0x36 0x01, DataBlock); // 传输数据块
10. // 刷写 BCM（通过网关转发）
11. UDS_Send(0x10 0x02, TargetAddr: 0x01); // 网关转发到 CAN
12. UDS_Send(0x34 0x00 0x44, DataLen: 0x00002000, TargetAddr: 0x01);

结果对比：座舱域控制器通过 DoIP 刷写耗时 12 分钟（实际吞吐量约 25MB/s），BCM 通过 CAN 刷写耗时 4 分钟。总升级时间 16 分钟，满足目标。若全部走 CAN，座舱域控制器需 10 小时，完全不可接受。

风险与代价：DoIP 刷写过程中，以太网链路对电磁干扰敏感，若车辆处于强干扰环境（如充电桩附近），可能导致 TCP 重传，延长刷写时间。为此，诊断仪实现了断点续传机制（记录已传输的块序号），并在 TCP 超时后自动重连。此外，网关的 DoIP-to-CAN 转发存在延迟（约 5ms/帧），对于 BCM 的刷写，需要适当增大 CAN TP 的块序列超时时间（从默认 1000ms 调整为 2000ms），避免误报超时错误。

风险提示：在 DoIP 刷写过程中，必须确保 ECU 的编程会话超时时间（P2*）设置合理。若 ECU 在接收数据块时处理缓慢，可能触发 P2* 超时（默认 5000ms），导致诊断仪误判为通信中断。建议在刷写前通过 0x10 服务进入扩展会话，并适当延长 P2* 定时器（通过 0x28 服务关闭通信或 0x85 服务设置 DTC 记录模式）。

复盘经验：协议栈的选择不是孤立的，需要结合整车网络架构、固件大小、升级频率和法规要求综合决策。对于新平台，建议优先考虑 DoIP 作为骨干诊断通道，同时保留 CAN 诊断作为子网兜底。此外，诊断仪软件需要支持“多路并发”能力（同时通过 DoIP 和 CAN 刷写不同 ECU），以缩短总升级时间。

2.4 常见误区与总结复盘

误区一：认为 OBD-II 与 UDS 是互斥的。实际上，OBD-II 是法规接口，UDS 是应用协议，两者可以共存。现代车辆在 DLC 接口上同时提供 OBD-II 模式（ISO 15031-5）和 UDS 模式（ISO 14229-4 定义了 UDS on CAN 的映射）。诊断仪通过发送特定的服务 ID（如 0x09 读取 VIN）来区分模式。OBD-II 的 PID 0x01-0x20 是固定的，而 UDS 的 0x22 服务可以读取任意 DID（Data Identifier），包括非排放数据。

误区二：DoIP 只是“更快的 CAN”。DoIP 不仅仅是带宽提升，它引入了 IP 网络的概念，如路由、寻址、连接管理、安全认证（TLS）。DoIP 支持多个诊断仪同时连接（通过 Routing Activation 的 Socket 管理），而 CAN 诊断通常是点对点的。此外，DoIP 的物理层（100BASE-T1）是单对双绞线，支持车载环境，但需要专门的 PHY 芯片和 EMC 设计。

误区三：忽略 OBD-II 的法规更新。OBD-II 法规在持续演进，例如加州 CARB 2022 年要求增加对混合动力和纯电动汽车的电池健康状态监测（PID 0x1A 等）。工程师在设计诊断协议栈时，必须预留 OBD-II 服务的扩展空间，避免后期硬件改动。

总结复盘：车载诊断协议栈的演进反映了汽车电子架构从分布式到域集中式、再到中央计算式的转变。OBD-II 是“过去”的法规基石，UDS 是“现在”的应用标准，DoIP 是“未来”的传输趋势。作为诊断工程师，需要具备“分层思维”：物理层决定带宽和距离，传输层决定可靠性和寻址，应用层决定语义和流程。在实际项目中，建议采用“UDS 作为统一应用层 + DoIP/CAN 作为可选传输层”的架构，既满足法规，又兼顾性能和成本。最后，务必关注 ISO 14229 和 ISO 13400 的最新修订版本（如 2020 版增加了安全日志记录、SOVD 服务），确保设计的前瞻性。