【OBD II 简介 -基于SAE J1979和GB 18352.6标准】

一、OBD II诊断简介

OBD II（On-Board Diagnostics II）即第二代车载自动诊断系统，是汽车电子化、智能化进程中的关键技术标准。OBD II诊断系统已从单一的排放监测工具演变为车辆智能化的核心基础设施。其标准化接口、实时监测能力及数据交互功能，不仅提升了维修效率与行车安全，还为车联网、自动驾驶等前沿技术提供了数据支撑。随着技术融合与法规升级，OBD II将在智能交通生态中发挥更关键的作用。

1.核心功能

（1）排放监控与合规性

• 持续监测发动机、催化转化器、氧传感器等部件，确保尾气排放符合美国EPA、欧洲EURO及中国国六等法规标准。
• 故障时点亮MIL灯（“Check Engine”警告灯），并存储故障码（DTC），如P0420（催化转化器效率低）。**

（2）实时故障诊断

• 通过传感器网络（如节气门位置传感器、冷却液温度传感器）采集数据，ECU对比预设阈值，发现异常时生成故障码。
• 支持短期燃油修正（STFT）和长期燃油修正（LTFT），动态调整空燃比以优化燃烧效率。

（3）数据记录与传输

• 记录车辆行驶数据（车速、油耗、发动机转速），支持通过标准化16PIN接口（SAE J1962）读取。
• 采用CAN总线通信协议，数据传输速率达500kbps，兼容ISO 15765-4标准。

2.技术特点

（1）标准化与兼容性

统一诊断接口位置（方向盘下方）及通信协议（如CAN、ISO 9141-2），实现跨品牌诊断设备通用。

（2）故障码标准化

（如P0xxx为动力总成故障，B0xxx为车身故障），提升维修效率。

（3）增强型监测能力

• 连续监测（Continuous Monitoring）采样率≥2次/秒，覆盖发动机、变速器、ABS等系统。
• 引入“冻结帧”功能，记录故障发生时的瞬时数据（如车速、发动机负荷），辅助故障复现。

（4）安全与权限管理

• 支持安全访问（Security Access）机制，防止非法篡改车辆数据。
• 通过诊断会话控制（Diagnostic Session Control）区分常规诊断与编程模式。

3.应用场景

（1）维修诊断

• 技师使用诊断仪读取故障码、数据流，定位问题部件（如氧传感器失效）。
  示例：P0171（系统过稀）可能由进气歧管漏气或燃油压力不足导致。

（2）排放检测

• 年检时通过OBD II接口读取排放相关故障码，确保车辆环保合规。
• 部分地区（如中国）要求OBD数据实时上传至监管平台。

（3）车联网与远程诊断

• 集成T-Box模块，实现车辆数据远程传输（如发动机状态、故障预警）。
• 支持预测性维护，如通过机油寿命监测提醒更换周期。

（4）性能优化与改装

• 调校ECU参数（如点火提前角、涡轮增压压力）提升动力输出。
  示例：通过修改“Base Fuel Schedule”优化燃油经济性。

二、规范的适用性以及相互关系

三、OBD 系统故障诊断开发要求

1.驾驶循环

2.暖机循环

3.其他相关术语定义

4.故障码的记录与清除以及MIL的亮灭条件

（1）MIL

（2）点亮MIL和存储故障代码

四、OBD 服务

Service $01 - Request Current Powertrain Diagnostic Data .

本服务的目的是提供当前与排放相关的数据值访问，包括模拟输入和输出、数字输入和输出以及系统状态信息。请求信息中包含一个参数标识（PID）值，该值用于指示车载系统所请求的具体信息。

ECU(s)将通过发送系统最后确定的请求数据值来响应此消息。返回的所有传感器读数数据值均为实际读数，而非因该传感器故障而由系统使用的默认或替代值。

并非所有PID都适用于或被所有系统支持。PID 00是一种位编码的PID，用于指示每个ECU支持哪些PID。所有响应服务01请求的ECU都应支持PID 00,PID 0x00、0x20、0x40这些用于响应支持的PID, 1bit对应一个PID,示例见下图。

Service $02 - Request Powertrain Freeze Frame Data

ECU将通过发送系统存储的请求数据值来响应此消息。返回的所有传感器读数数据值均为实际存储的读数，而非因该传感器出现故障而由系统使用的默认或替代值

并非所有PID都适用于或被所有系统支持。PID 00是一种位编码的PID，用于指示每个ECU支持哪些PID。因此，所有响应服务02请求的ECU都应支持PID 00，即使该ECU在请求时没有冻结帧存储。

PID 02表示导致冻结帧数据被存储的故障诊断代码。如果冻结帧数据未存储在ECU中，系统应报告00 00作为故障诊断代码。当存储的故障诊断代码为00 00时所回复的任何数据可能无效。

帧号字节将指示$00作为强制冻结帧数据。制造商可以选择保存额外的冻结帧，并通过在请求消息中指定冻结帧编号来获取这些数据。如果制造商使用这些额外的冻结帧，它们将在制造商指定的条件下存储，并包含制造商指定的数据。

指令格式：

首先请求支持的PID信息，假设支持PID 02，那么进一步发送指令读取PID 02的冻结帧数据。

案例一：已存储冻结帧

案例二：未存储冻结帧

Service $03 - Request Emission-Related Diagnostic Trouble Codes

本服务的目的是使外部测试设备能够获取“确认”的排放相关故障诊断码（DTC）。这一过程分为两个步骤。

第一步，发送服务$01，PID $01请求，以从所有具备此功能的ECU中获取排放相关的DTC数量。每个存储了DTC的ECU将返回一条消息，其中包含要报告的代码数量。如果某个ECU能够存储排放相关的DTC但没有存储任何DTC，则该ECU将返回一条消息，表明没有存储任何DTC。

第二步，发送服务$03请求，以获取所有排放相关的DTC。每个存储了DTC的ECU将返回一条或多条消息，每条消息最多包含三个DTC。如果ECU中没有存储任何排放相关的DTC，则可能不会对此请求作出响应。

如果在ECU报告DTC数量的时间点与ECU报告DTC之间设置了额外的DTC，那么报告的DTC数量可能会超过外部测试设备预期的数量。在这种情况下，外部测试设备应重复此循环，直到报告的DTC数量与基于服务$01、PID $01响应的预期数量相等。

DTC每个信息由两个字节传输。每个DTC的第一个字节的前两位（高位）用于指示DTC是动力系统、底盘、车身还是网络DTC（有关此结构的详细解释，请参阅SAE J2012）。接下来的两位用于指示DTC的第一位数字（0到3）。第一个字节的第二个半字节和整个第二个字节是实际报告的DTC的三个十六进制字符。例如，传输为$0143的动力系统DTC将显示为P0143（见下图）。

如果报告的故障诊断代码（DTC）少于三个(3)，用于报告DTC的响应消息应将未使用的字节设置为零，以确保所有消息的固定长度。若无DTC需要报告，则允许发送响应消息，但对SAE J1850和ISO 9141-2接口而言并非强制要求。对于ISO 14230-4接口，ECU将返回一个不包含任何DTC的报告（DTC#1、DTC#2和DTC#3均应设置为$00）。

案例一：有3个DTC

案例二：不足3个DTC

Service $04 - Clear/Reset Emission-Related Diagnostic Information

本服务的目的是为外部测试设备提供一种命令ECU清除所有排放相关诊断信息的方法。这包括：


根据ISO 14230-4协议，如果ECU未能满足清除或重置排放相关诊断信息的条件,需发送了一个带有“条件不正确”响应码的否定响应消息。外部测试设备应在用户更改车辆条件后重复请求。现在，所有ECU应向外部测试设备发送一个肯定的响应消息，以确认清除或重置排放相关诊断信息服务的成功运行。

Service $07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle

这项服务的目的是让外部测试设备能够获取在当前或最近一次完成的驾驶循环中检测到的“pending”诊断故障代码，这些故障码涉及在正常驾驶条件下测试或持续监控的排放相关部件/系统。所有诊断故障代码（DTC）都需要进行服务$07，且独立于服务$03。这项服务的数据旨在帮助维修技师在车辆修复后，以及清除诊断信息后，通过报告单次驾驶循环后的测试结果来提供支持。如果在驾驶循环中测试失败，将报告与该测试相关的诊断故障代码（DTC）。这项服务报告的测试结果不一定意味着部件/系统的故障。如果测试结果显示故障，并且在额外驾驶后仍然存在，则故障指示灯（MIL）将亮起，诊断故障代码（DTC）将被设置并报告，同时服务$03也会显示部件/系统的故障。这项服务可以随时请求最新的测试结果，无论诊断故障代码（DTC）的状态如何。

如果失败测试报告的DTC值少于三个(3)，则用于报告测试结果的响应消息应使用$00填充七个(7)数据字节。这将保持所有消息所需的固定消息长度。

Service $09 - Request Vehicle Information

本服务的目的是使外部测试设备能够请求车辆特定的车辆信息，例如车辆识别号（VIN）和校准ID。其中一些信息可能是法规要求的，而另一些信息如果得到车辆制造商的支持，则希望以标准格式报告。

该服务的一个可选功能是ECU指示支持哪些信息类型（ISO 9141-2要求支持INFOTYPE$00）。INFOTYPE $00是一个位编码值，表示支持从$01到$20的信息类型。INFOTYPE $20表示支持从$21到$40的信息类型，以此类推。这一概念与附录A中规定的服务$01和$02中的PID支持相同。如果不支持PID（参数ID）/TID（测试ID)/INFOTYPE $00，ECU将不会使用此功能来指示PID（参数ID）/TID（测试ID)/INFOTYPE的支持。