OBD诊断

OBD系统的首要任务和设计初衷，就是为了确保汽车在整个生命周期内，其尾气排放都能符合环保法规要求，从而保护大气环境和公众健康。

它不是为了提高性能或舒适度，而是一个由政府法规强制推行的、用于环保监督的系统。当它亮起那个黄色的发动机故障灯时，本质上是在说：“我的排放系统出问题了，现在排出的尾气可能超标，对环境不友好，需要尽快检修！”

主要的有害排放物有哪些？

1. 一氧化碳 (CO)：一种无色无味的有毒气体。可以把它理解为“燃料不完全燃烧的产物”。它会阻碍血液输送氧气，高浓度时致命。

2. 碳氢化合物 (HC)：本质上就是未燃烧的燃油。它和氮氧化物在阳光下会发生反应，形成光化学烟雾，刺激人眼和呼吸道。

3. 氮氧化物 (NOx)：包括NO和NO₂等。是在高温高压下，空气中氮气和氧气反应的产物。它是形成酸雨和雾霾（PM2.5） 的重要元凶，也会对人体肺部造成损害。

4. 颗粒物 (PM)：特别是柴油车产生的“黑烟”，就是由大量颗粒物组成的。这些微小的颗粒可以深入肺部，引发呼吸系统和心血管疾病。

OBD如何“关注”排放？

OBD系统本身不直接减少排放，它扮演的是一个 “7x24小时不间断的排放系统监督员” 的角色。它的工作逻辑是：

监控 → 发现异常 → 报警 → 确保可维修

它通过监控与排放相关的几十个甚至上百个传感器、执行器和子系统，来确保整个“消化和排泄系统”工作正常。具体来说：

• 监控“消化”效率：

  • 发动机燃烧状况：通过氧传感器、曲轴位置传感器等，监控燃烧是否充分。如果燃烧不好，就会导致CO和HC飙升。

  • 燃油系统：监控喷油嘴的工作情况，确保喷油量精确。喷油过多或过少都会影响排放。

• 监控“垃圾处理”系统：

  • 三元催化器 (TWC)：这是最重要的尾气净化装置，能同时净化CO、HC和NOx。OBD系统会通过催化器前后端的氧传感器，来实时监测它的净化效率。如果效率下降到阈值以下，OBD就会立刻报警。

  • 颗粒捕集器 (DPF)：用于捕捉柴油车产生的颗粒物。OBD会监控它的堵塞情况，并在需要时提醒司机进行“再生”清理。

  • 废气再循环 (EGR)：通过将部分废气再次引入气缸，降低燃烧温度，从而减少NOx的生成。OBD会监控EGR阀的工作是否正常。

OBD诊断和UDS诊断对比

OBD和UDS虽然都用于车载诊断，但定位和能力不同。

OBD是满足法规要求的“基础体检”，重点关注排放；UDS则是用于深度开发、调试和维修的“全面精准检查”。

简单来说，可以把OBD理解为运行在ISO-TP之上的一套固定的、专用的诊断服务集，而UDS则是一套丰富的、可配置的诊断服务集。在AUTOSAR架构中，来自诊断工具的OBD请求和UDS请求，都会由DCM模块统一接收和处理，并根据请求的服务ID（SID）分发给相应的处理程序。

AUTOSAR中实现OBD诊断的核心模块

在AUTOSAR (汽车开放系统架构) 软件架构中，OBD功能的实现主要由以下核心模块协同完成：

• DCM (诊断通信管理器) : DCM是诊断请求的“总调度室”。它遵循OBD及相关诊断通信标准，当你用诊断工具发送OBD请求时，DCM负责接收、解析，并确保请求被正确响应。它内部通常由DSL (会话层)、DSD (服务分发器) 和DSP (服务处理) 子模块构成，共同管理诊断会话状态、分发请求并协调响应。

• DEM (诊断事件管理器) : DEM是故障信息的“档案管理员”。与排放相关的监控系统（如燃油系统）检测到故障时，会报告给DEM。DEM则负责处理和存储这些“诊断事件”（包括与之相关的故障码DTC），并记录故障发生时的“冻结帧”数据（如当时的车速、发动机转速）。此外，OBD法规要求的IUMPR (在用监测性能比率) 计算也由DEM负责。

• FIM (功能抑制管理器) : FIM是系统功能的“安全开关”。它与DEM协同工作，当诊断确认某些特定故障时，FIM会根据预设策略禁止或启用ECU的某些功能，以防止故障扩大或确保安全，例如在检测到相关故障时禁止进行排放诊断测试或停止递增IUMPR计数器。

OBD诊断协议详解

OBD-II作为一个法规强制系统，其协议的核心特点是标准化、固定化，这与UDS的高度可配置性形成鲜明对比。

支持的核心诊断服务

OBD-II标准强制定义了一组用于排放相关诊断的9种模式（Mode），这些模式在UDS中大致对应不同的诊断服务（Service）。下表详细列出了这些模式及其与UDS的对比：

与UDS的关键区别：

• 服务ID固定：OBD的服务（模式）是预定义的，范围是01-0A，而UDS的服务ID范围更广（如10, 22, 2E等），且允许厂商自定义。
• 参数化访问：OBD严重依赖PID、TID等参数来访问特定数据，结构固定。UDS则通过DID（Data Identifier）来读写任意数据，更加灵活。

请求与响应格式

OBD的报文格式非常规整，这与UDS的可变长度格式有所不同。

• 请求格式：
  [模式 Mode] [参数 PID/TID]

  • 例如 01 0C 表示请求模式01下的PID $0C（发动机转速）数据。
  • 非常简洁，没有UDS中可能存在的子功能码或复杂的数据参数。

• 正响应格式：
  [模式 + 0x40] [请求的 PID/TID] [数据 1] [数据 2] ...

  • 例如，对 01 0C 的正响应是 41 0C 1A F8。
  • 41 = 01 + 40，这是OBD响应报文的固定规则。
  • 1A F8 是两个字节的原始数据，需要根据标准公式转换为有意义的物理值（如转速 = (256 * 0x1A + 0xF8) / 4 = 1728 RPM）。

物理寻址与功能寻址

OBD明确支持物理寻址和功能寻址，这是其协议架构的基础。

• 功能寻址：

  • 目的：用于广播诊断请求。所有监听在OBD功能地址上的ECU都必须接收并处理该请求。
  • 地址：在CAN总线中，OBD-II法规规定的功能请求地址是 0x7DF。
  • 场景：当诊断工具发送一条请求到0x7DF时，所有支持该请求的ECU（主要是动力系统相关的ECU）都应当处理。

• 物理寻址：

  • 目的：用于单播响应。每个ECU必须使用自己唯一的物理地址进行回复，以避免总线冲突。
  • 地址：在CAN总线中，ECU的物理响应地址范围是 0x7E8 到 0x7EF。通常，发动机ECU会使用0x7E8，变速箱ECU使用0x7E9，以此类推。
  • 工作流程：
    1. 诊断工具发送功能寻址请求到 0x7DF。
    2. 支持该请求的ECU（例如发动机ECU）处理请求。
    3. 该ECU使用自己的物理地址（例如 0x7E8）将响应发送回诊断工具。

与UDS的对比：
概念上与UDS完全一致。UDS中使用功能地址（如0x7DF）进行广播请求，使用物理地址（如0x7E0/0x7E8）进行一对一通信。OBD可以看作是UDS在这方面的一个具体应用实例。

传输层协议

OBD over CAN 必须支持TP。

• 协议：当OBD诊断报文在CAN总线上传输，且单帧无法容纳所有数据时，必须使用ISO 15765-4（也就是我们常说的ISO-TP）作为传输层协议。
• 作用：与UDS over CAN完全一样，ISO-TP负责将长于8字节（对于经典CAN）的诊断报文进行分段、传输和重组。
• 示例：
  • 请求车辆VIN（Mode 09, PID $02）时，VIN字符串长度超过7字节，就无法在一个CAN数据帧中装下。
  • 此时，ECU的响应会使用ISO-TP的多帧传输：
    • 首帧：指示总数据长度。
    • 连续帧：携带剩余的数据。

参考

汽车诊断及OBD和UDS协议的基础概念介绍 - 知乎

OBD 诊断 初入门 - 知乎

OBD(On-Board Diagnostic)介绍 - 知乎