在车辆年检新标准的实施中，不仅增加了与排放相关部件的外观检查（如连接管路是否老化、龟裂、漏气等），还新增了OBD检测项目，并且要求在进行排放污染物检测的整个过程中，都不能断开OBD设备。
如此一来使得检测数据更加精准，无形中也使得车辆年检变得也更加严格。
简单来讲，新增的OBD检测项目主要还是为了检查尾气排放是否达标。
可对于汽修人而言，在实际使用中OBD的功能可不止如此！
OBD英文全称为On-Board Diagnostic，翻译过来就是车载诊断系统。是汽车发动机和排放相关故障的标准化诊断规范。该系统最直观的体现就是，我们在读取故障码时所要连接的诊断接口。
其工作原理可简单的理解为系统ECU通过实时监控发动机的运行状况和排放控制系统的工作状态。
当出现故障或排放不达标时，故障灯(MIL)或检查发动机(Check Engine)故障灯点亮，同时记录并存储对应的故障信息。
所存储的故障信息可通过诊断接口连接标准的诊断仪器以故障码的形式读取。
根据所读取的故障码和数据流等信息，可以帮助我们确定维修方向，更有针对性地去检查相关部位、元件和线路，并快速锁定故障进行维修。
虽说听上去就一两句话的事，可在实际的工作环境下OBD并没有那么简单，毕竟它涉及到的许多东西（如信息交互）并不像诊断接口那样，可以实实在在的展现在我们面前。
想要真正的了解它，我们不能只停留在表面。
OBD的发展进程
OBD首次出现在1982年，由通用汽车引入，其目的是监测排放控制系统。
直到美国环保局(EPA) 要求自1991年起所有在美国销售的新车必须满足相关OBD技术要求时，OBD才被小范围应用（在后期的迭代中称此版本为OBD-I）。
但此时的OBD系统只能监控部分部件的工作情况，且只有在其失效已经发生了的情况下故障灯才会点亮，无法监测到与排放有关的部件的渐进损坏情况。
同时由于通讯协议、外部设备和诊断接口也没有处于标准化而没有得到推广。
直到汽车工程师协会(SAE)对故障指示灯、诊断连接口（16针诊断座）、外部设备和ECU之间的通讯协议以及故障码（DTC）进行了标准化定义后，OBD-II应运而生。
此时的OBD-II不只是自诊断软件功能的升级，可提供更多的数据（如故障码、信号、实时数据、冻结帧信息等）被外部设备读取。
硬件方面也进行了很大升级，增加了1.5万个新的标定常数、可实现软件的重新编程、增加并改进排放控制系统组件（如EVAP系统中的排气电磁阀、燃油箱压力传感器和诊断测试装置等），实现更精准的监控。
在美国推出OBD-II的同时，欧盟于1998要求自2000年起所有新上市销售车辆必须配备EOBD即OBD-II的欧盟版。但其要求较OBD-II较为宽松（如不对油箱泄露进行诊断等）。
我们国家对OBD的强制实施时间较晚，于2005年才初次制定相应的法规标准（参考欧盟标准），也被称为COBD（中国版）。
自此OBD-II标准沿用至今。
OBD-III（也有另一种说法叫OBD-II+I/M）
OBD-III系统的发展方向是利用小型车载无线收发系统，通过无线蜂窝通信，卫星通信或者GPS系统将车辆的VIN,故障码及所在位置等信息自动通告管理部门。
管理部门根据该车辆排放问题的等级对其发出指令（包括去何处维修的建议，解决排放问题的时限等）。这些信息可在相关法规的基础上对维护不当从而造成过多排放污染的车辆惩罚。
完整的OBD-II系统包括警告部分、软件部分、硬件部分三部分。
警告部分：
当出现故障后的可视化警示，用来提醒驾驶员。
如发动机故障灯（MIL）
软件部分：
故障诊断控制策略代码和标定，与发动机系统控制部分构成整个发动机控制系统的软件包。
该部位内容以计算机语言写入控制单元中，是整个系统运转的核心。虽说它就在那里，但我们却无法触及。
硬件部分：
既是软件部分的载体，也是从发出指令到执行指令的中间媒介。主要包括ECU、传感器、执行器、通讯线路、诊断接口。由于车辆中的执行器和传感器众多，图中仅做部分展示。
OBD-II系统各部分组成已到位，是否可以进入工作状态了呢？
当然……不是！
想要进入工作状态，必须要先搞定通讯协议！
我们都知道OBD-II在制定标准化后，统一采用16针梯形诊断接口。但由于通讯协议的不同，其各针脚的定义也存在着差异。
除部分引脚定义是由ISO/SAE统一标准制定和预留外，其余引脚定义由厂家自定义。而OBD-II所使用的诊断通讯协议标准有：
SAEJ1850 PWM（脉冲宽度调制），主要用于福特，诊断通讯使用针2、10，脉冲宽度41.6kbps。
SAE J1850 VPM（可变脉冲宽度调制），主要用于通用汽车，诊断通讯使用针2通讯，可变脉冲宽度10.4 kbps/41.6 kbps。
ISO 9141-2,协议主要用于欧洲汽车（2000~2004年间），诊断通讯使用针7、15。
ISO/DIS 14230-4（KWP2000），2003年以后的常见通讯协议，诊断通讯使用针7。
ISO 15765-4（CAN-BUS），现在使用最多的通讯协议，诊断通讯使用针6、14，传输速率250kbit/s or 500kbit/s。
目前，SAE J1850基本上已被淘汰，大部分采用后三种协议，就是我们俗称的K线与CAN线（现阶段的主流选择）。
搞定了通讯协议，再加上有了软件和硬件作为基础，诊断接口作为信息交互端口。
接下来我们就可以让它开启工作模式，比如进行故障码的读取，这也是我们在故障维修中的必做项。
一般情况下，故障码（DTC）包含了五个字符。
第一个是字母，后边的四个是数字。（详情见上图）
首位字母表示所产生故障码的系统类型，有以下四类
Pxxxx
Bxxxx
Cxxxx
Uxxxx
第二位表示标准代码，有0~3四个数字。
第三位表示出现故障时对应的部件信息
第四和第五位表示部件/系统的标识代码。具体地表示了实际部件或特定的故障名称。
故障码编号是从00～99，不同的传感器、执行器和电路分配了不同区段的数字编号。这些数字提供了比较具体的信息，如电压低或高、响应慢、信号超出范围等。
根据故障是否对排放的影响程度可分为影响排放的故障码和不影响排放的故障码。
其中影响排放的故障码，根据其故障灯点亮的机制又可分为：
A类：故障发生一次就直接点亮发动机故障灯并记录故障码。
B类：故障在两个连续的工作循环中各发生一次时，点亮发动机故障灯并记录故障码。
E类：故障在三个连续的工作循环中各发生一次时，点亮发动机故障灯并记录故障码。
不影响排放的故障码
C类：故障发生时只记录故障码，不点亮发动机故障灯，但厂家可根据需要点亮另外一个报警灯。
D类：故障发生时只记录故障码，不点亮任何警告灯。
除了读取故障码以外，OBD-II还可以做什么？
从SAE J1979标准中我们可以了解到，OBD-II可提供九种模式的信息读取。
01. 显示当前数据
02. 显示冻结帧数据
03. 显示存储的故障诊断代码
04. 清除故障码和存储值
05. 测试结果，氧传感器监测
06. 测试结果，其他组件/系统监测
07. 显示待定诊断故障代码
08. 诊断组件/系统的控制操作
09. 显示车辆信息
汽车制造商并不需要支持所有的模式，每个制造商可以自行定义额外模式。
针对以上9种模式可读信息的进一步分析，将在下期内容中进一步说明。
我们下期，不见不散
