车载诊断 OBD（CCR 1968.2 / WWH-OBD / OBDonUDS / AUTOSAR Dem-Dcm-FiM）

加州空气资源委员会（CARB）是 OBD 的发源地，其 OBD-II 要求写在 California Code of Regulations 第 13 编 1968.2 节（CCR 1968.2），美国联邦环保署（EPA）随后采纳为联邦要求。欧盟的 OBD 要求嵌在 Euro 6（已实施）与 Euro 7（2025 年落地）排放法规里，并叠加实路排放测试（RDE，Real Driving Emissions）。中国国六（GB 18352.6，轻型车）则同时借鉴美欧两套，监测项与频率要求比照 EPA，并新增远程 OBD（把 OBD 信息周期性上传监管平台）。

三套体系各写各的会让 Tier-1 为同一辆车维护三份诊断实现，成本高且易出错。联合国世界车辆法规协调论坛（WP.29）因此推出全球技术法规 GTR No.5，即 WWH-OBD（World-Wide Harmonized OBD），把"监测什么、DTC 怎么编、诊断怎么通信"对齐到统一标准。WWH-OBD 最关键的两个动作：一是把 DTC 从 legacy 的 2 字节升级为 3 字节失效码加 1 字节状态字节（status byte），二是规定诊断走 ISO 14229（UDS）而非 SAE J1979 的固定模式——这直接催生了下一章的协议栈演进。

法规真正强制的三件事是点灯、就绪、在用频率，它们分别回答"出了问题怎么通知""系统自检了没""自检够不够勤"。MIL（Malfunction Indicator Lamp，故障指示灯，俗称发动机故障灯）的点灯逻辑是：监测器检出排放相关失效后先记为 pending，第二个行程复现才确认点灯；但失火率超过催化器损伤门限这类严重故障可在单次行程内立即点灯。

readiness（就绪位）记录每个监测器是否已完整跑过一次诊断，年检时若大量监测器"未就绪"会被判为可能清过码、拒绝放行。IUMPR（In-Use Monitor Performance Ratio，在用监测性能比，欧盟同义词 IUPR）则防止车厂把监测条件设得极苛刻以逃避真实检测，其机制是一个分数：

法规对该比值设下限（典型量级 0.336），逼着监测器在真实驾驶里足够频繁地真正运行，而不是永远"等不到条件"。

无论应用层怎么变，车主和年检站接触到的物理接口始终是 SAE J1962 定义的 16 针梯形诊断座，传输层则由 ISO 15765-4 规定为诊断 CAN（CAN over CAN，即在 CAN/CAN-FD 上跑诊断报文，带 ISO-TP 分段传输）。这层稳定不变，是整个 OBD 体系唯一不被法规演进推动的部分，因为它只管"把字节可靠送到"，与"读什么"解耦。

最初的 J1979 把诊断设计成 10 个固定服务模式（0x01–0x0A：0x01 读当前数据、0x02 读 freeze frame、0x03 读 confirmed DTC、0x04 清码、0x05-0x0A 等），每个模式背后是一张固定的 PID（Parameter ID，参数标识）表。这套设计简单，但有个结构性缺陷：它和 OEM 自己的增强诊断（售后用的、走 ISO 14229 UDS）是两套完全不同的协议，ECU 里要同时实现两个诊断栈，既费 ROM 又难维护。

解决思路很直接：既然 OEM 增强诊断已经用 UDS，就把法规诊断也搬到 UDS 上，两套栈合一。J1979-2（OBDonUDS）正是这么做的——它把原来的固定模式映射到 UDS 服务：读数据用 0x22（ReadDataByIdentifier）、读 DTC 用 0x19（ReadDTCInformation）、清码用 0x14（ClearDiagnosticInformation）、控灯/IO 用 0x85/0x2F。CARB 已经把 OBDonUDS 列为强制：2027 车型年起新认证车型必须支持。这意味着法规诊断与 OEM 增强诊断从此共用一套 UDS 实现，并可顺势承载到 DoIP（Diagnostics over IP，以太网诊断）上。

DTC（Diagnostic Trouble Code，诊断故障码）的编码由 SAE J2012 / ISO 15031-6 规定。面向车主和年检的"5 字符码"首字符表系统：P 动力总成、C 底盘、B 车身、U 网络；其后数字区分标准码（第二位 0，如 P0xxx，全球统一含义）与厂商自定义码（第二位 1，如 P1xxx）；P2xxx、P34xx-P39xx 等区段是标准码在 P0 段写满后扩展出来的。

在 UDS/WWH-OBD 层，DTC 是 4 字节：前 3 字节是失效码（high/mid/low byte，对应 SAE J2012 的数字部分加失效类型 FTB），第 4 字节是 status byte，用 8 个 bit 分别标记 testFailed、confirmedDTC、pendingDTC、warningIndicatorRequested 等状态——这把"故障是什么"和"故障当前处于生命周期哪个阶段"清晰分离，正是下一章状态机的存储载体。

故障第一次被监测器判失效时记为 pending DTC，此时不点灯、不打扰车主，只暗中观察。若在第二个 driving cycle（一次满足监测器使能条件的完整行程）里再次复现，则升级为 confirmed DTC，写入 KAM（Keep-Alive Memory，掉电保持存储）并连同 freeze frame（故障置位瞬间的转速/负荷/温度等工况快照）一起保存；达到点灯条件即点亮 MIL。confirmed 的同时会同步写一份 permanent DTC——这是 OBD-II 后期为防作弊引入的：即使车主断电或用工具清了 confirmed DTC，permanent 也删不掉，必须靠车辆自己重新监测确认故障真的修好了才会消。

法规也给了正当修复后退出故障态的路径，避免修好后灯还一直亮。confirmed DTC 在连续 3 个无故障的 driving cycle 后熄灭 MIL；pending DTC 单次无故障行程即清除。permanent DTC 最严格：要监测器自测 OK，且累计满足一定数量的 warm-up cycle（暖机循环，冷启动后冷却液温度升高 22 摄氏度且达到 70 摄氏度算一次）才自动清除（典型为相关监测器跑通即清，超时则 40 个暖机循环兜底自清）。这套非对称设计——点灯快、灭灯慢——本质是为排放结果负责而非为用户体验负责。

Dem（Diagnostic Event Manager，诊断事件管理器）是故障逻辑的大脑：诊断监测器（实现为 SWC，软件组件）只负责报告"我这次测下来 Pre-passed 还是 Pre-failed"，由 Dem 做去抖计数（debounce）、维护 DTC 状态机、存 freeze frame 与扩展数据、计算 IUMPR 分子分母、维护 readiness、触发 permanent 与 MIL 请求，所有故障事件经 NvM 落到 KAM。Dcm（Diagnostic Communication Manager，诊断通信管理器）是对外的壳：它把第 2 章的 UDS 服务（0x19/0x14/0x22/0x85）路由到 Dem 取数。FiM（Function Inhibition Manager，功能抑制管理器）是联动：某 DTC 置位后，FiM 通知相关功能停止运行（例如某传感器坏了就抑制依赖它的监测器，避免误触发更多故障）。

监测器按是否随时运行分两类，调度方式不同。连续型监测器（失火、燃油系统、综合元件电路）只要发动机在运行就持续监测；非连续型监测器（催化器、EGR、氧传感器、蒸发系统）需要特定工况窗口才跑一次，因而是 IUMPR 分母的主要约束来源。每个非连续监测器每个行程向 Dem 报告"本行程是否完成了一次完整监测"，Dem 据此累加分子；同时只要该行程满足该监测器的通用使能条件（车速、时长等）就累加分母——年检工具通过 0x19 子功能读出这个比值核验车厂没有作弊。

法规诊断与 OEM 增强诊断（售后刷写、参数标定、执行器测试）在 J1979-2 之后共用同一套 UDS 栈，这正是把它们搬到 UDS 的收益。0x19（读 DTC 信息）既服务年检读 confirmed/permanent，也服务售后读全部增强 DTC；0x14（清码）、0x85（控制 DTC 设置，售后维修时临时关闭故障记录）同理。差别仅在权限与会话：增强诊断往往要 0x27（SecurityAccess）解锁与扩展会话，法规 OBD 数据则默认会话即可读，保证年检站不需要厂商密钥。

OBD 排放监测的目的是环保合规：保护对象是大气排放，可接受的检出到响应时间窗是"以行程为单位"（多个 driving cycle 才点灯），响应动作是点灯告知车主去修，本质是事后审计。ISO 26262 安全机制的目的是避免人身伤害：保护对象是整车可控性，时间窗是 FTTI（Fault Tolerant Time Interval，故障容错时间区间，常在毫秒级），响应动作是立即进入安全状态（如切扭矩、主动放电）。

两者在 AUTOSAR 里也走不同链路：OBD 经 Dem/Dcm，安全机制经看门狗、E2E、监控分区等。但二者会在同一个传感器上相遇——例如电机位置传感器既是扭矩安全的输入，也可能是 ZEV OBD 的监测项，此时一个故障会同时触发安全降级和 DTC 记录，需要在 FMEA 里统一规划，避免重复或矛盾的响应。

纯电动车没有尾气，传统排放监测项（催化器、EGR、失火）几乎全部失效，于是 CARB 的 ZEV（Zero-Emission Vehicle）OBD 要求把监测对象转向电驱动系统本身的健康：逆变器/功率模块过温监测、电机位置/转速传感器合理性、HV 高压绝缘电阻监测、电池与热管理相关故障，都被纳入 OBD 框架，按同一套 DTC 生命周期管理并对年检可读。架构上这是好消息——这些监测项本就大多已存在于功能安全或 BMS 里，接入同一个 Dem 即可复用状态机与存储，无需另起炉灶。EV OBD 因此更像是把已有的电驱健康监测"法规化、可审计化"，而非新增一套独立诊断。