2. 汽车诊断基础
汽车诊断并不是“插上诊断仪读故障码”这么简单。它背后是一整套分层、分工明确的标准体系：法规层规定“必须能读什么”，应用层规定“用什么服务读”，传输层规定“报文怎么发、怎么分段、怎么确认”，物理层规定“用哪对引脚、什么电平、什么波特率”。理解这套体系，是后续学习 AUTOSAR 诊断通信与传输工程的前提。
一、核心原理：四层标准各司其职
可以把汽车诊断标准体系理解为一条自下而上的“信号链”：物理层负责电气连接，数据链路层负责帧的收发与仲裁，网络/传输层负责长报文的分段与重组，应用层负责诊断服务的语义。OBD、UDS、ISO 14229、ISO 15765 分别落在不同层，彼此不是替代关系，而是协作关系。
- OBD（On-Board Diagnostics）：法规驱动的排放相关诊断，主要面向尾气排放与发动机相关系统，强调“统一接口、统一故障码、统一就绪状态”，典型标准为 ISO 15031 / SAE J1979。
- UDS（Unified Diagnostic Services）：统一诊断服务，面向整车所有 ECU 的通用诊断，覆盖读取、写入、例程、刷写、安全访问等，核心标准为 ISO 14229。
- ISO 14229：定义 UDS 的应用层服务、服务标识符（SID）、请求/响应格式、否定响应码（NRC）等，是“诊断服务语义”的权威来源。
- ISO 15765：定义基于 CAN 的诊断传输协议（DoCAN），包括单帧、首帧、连续帧、流控帧，以及网络层地址格式，是“诊断报文怎么在 CAN 上跑”的关键标准。
一句话记忆：OBD 是法规要求，UDS 是通用服务，ISO 14229 是服务字典，ISO 15765 是 CAN 上的运输规则。
二、方法流程：一次诊断请求的完整旅程
以“读取故障码”为例，诊断仪发出请求后，报文会经历如下过程：应用层按 ISO 14229 组装服务请求（如 0x19 0x02），传输层按 ISO 15765 判断长度并选择单帧或首帧+连续帧，数据链路层按 CAN 帧格式发送，目标 ECU 收到后逐层解析并返回响应。若请求过长，还会出现流控帧（FC）协调发送节奏。
诊断请求示例（读取 DTC 信息）：
请求：19 02 FF // SID=0x19，子功能=0x02，状态掩码=0xFF
肯定响应：59 02 ... // SID+0x40 表示肯定响应
否定响应：7F 19 13 // 7F + 原SID + NRC=0x13（请求长度或格式错误）
ISO 15765-2 帧类型：
0x0 单帧 SF | 0x1 首帧 FF | 0x2 连续帧 CF | 0x3 流控帧 FC
这条链路说明：诊断工程师排障时，不能只看应用层服务对不对，还要看传输层分段是否正确、流控参数是否匹配、CAN ID 是否配置一致。很多“诊断仪无响应”的问题，根因其实在传输层或网络层。
三、诊断服务分类与典型应用场景
ISO 14229 将 UDS 服务按功能划分为多个类别，常见分类如下表所示。理解分类有助于在 AUTOSAR 配置中快速定位服务处理模块与安全策略。
| 服务类别 | 典型 SID | 作用 | 典型场景 |
|---|---|---|---|
| 诊断与通信管理 | 0x10、0x11、0x27、0x3E | 会话切换、复位、安全访问、保持连接 | 进入扩展会话后执行刷写或标定 |
| 数据传输 | 0x22、0x2E、0x23、0x3D | 按 DID 读写数据、按地址读写内存 | 读取软件版本、写入配置参数 |
| 故障码与状态 | 0x19、0x14、0x85 | 读取/清除 DTC、控制 DTC 设置 | 售后读码、下线检测、排放就绪状态 |
| 例程与输入输出 | 0x31、0x2F | 启动例程、控制 IO 状态 | 执行自检、激活执行器、EOL 标定 |
| 上传下载 | 0x34、0x36、0x37 | 请求下载、传输数据、退出传输 | ECU 软件刷写、Bootloader 升级 |
OBD 服务则更聚焦排放相关：如 Mode 01 读取实时数据、Mode 02 读取冻结帧、Mode 03 读取排放相关 DTC、Mode 04 清除 DTC、Mode 06 读取特定监测结果。它与 UDS 可以共存于同一物理 CAN 通道，但寻址方式与服务语义不同。
四、案例与场景：OBD 与 UDS 如何在同一车上共存
某车型同时支持 OBD 与 UDS：OBD 使用 11 位标准 CAN ID（如 0x7DF 功能寻址、0x7E8 响应），UDS 使用 29 位扩展 CAN ID 或不同的 11 位 ID 对。诊断仪进入 OBD 模式时，按 J1979 发送 Mode 请求；进入 UDS 模式时，按 ISO 14229 发送 0x10 0x03 进入扩展会话，再执行 0x27 安全访问，最后通过 0x34/0x36/0x37 完成刷写。
工程提示：在 AUTOSAR 中，OBD 与 UDS 通常由不同的诊断服务处理模块或不同的诊断连接配置承载。配置时要明确：哪些服务走 OBD 通道，哪些走 UDS 通道，避免功能寻址与物理寻址混用导致响应冲突。
五、误区与复盘
- 误区一：把 OBD 等同于 UDS。OBD 是法规排放诊断，服务集有限；UDS 是通用诊断，服务集更广。两者标准来源、寻址方式、应用目标都不同。
- 误区二：只关注 ISO 14229，忽略 ISO 15765。应用层服务正确，但传输层分段或流控参数错误，诊断依然失败。排障要自下而上：物理层→数据链路层→传输层→应用层。
- 误区三：忽视否定响应码。NRC 是定位问题的关键线索，如 0x13 表示长度错误、0x22 表示条件不满足、0x31 表示请求超出范围、0x33 表示安全访问被拒。
- 复盘建议：建立“服务—会话—安全等级—寻址方式—传输参数”五维检查表，每次诊断异常时逐项核对，可显著缩短排障时间。
掌握上述标准体系与数据流后，再看 AUTOSAR 诊断栈（Dcm、Dem、CanTp、PduR 等模块）时，就能清楚每个模块对应哪一层标准、承担哪一段职责。诊断工程的核心能力，正是把“标准分层”与“实际报文”对应起来，做到既能读服务，也能看帧、查流控、定位 NRC。