OBD(on-BoardDiagnostics)全称车载诊断系统，起源于19世纪80年代的美国，当时美国为了控制汽车排放，规定加州销售车辆装备车载诊断系统，也是最早的OBD系统。最早的OBD系统也称OBD-I，监控范围包括氧传感器、排气再循环系统、然后供给系统和发动机控制模块，只能检测到与排放有关部件的连续性故障，无法监测其渐进损坏情况。同时系统没有同意的标准，使用的协议也不相同，投入之后效果并不好。
针对OBD-I出现的缺陷，SAE(美国汽车工程师协议)制定了OBD-II系统，并制定了一系列相关的标准和规范。相对于之前的OBD-I，OBD-II采用了标准化的16针诊断座DL、相同的故障代码DTC和标准化通信协议，并且扩充了系统的检测项目，欧洲共同体基于也在同时规定了欧洲版的EOBD，也采用统一的诊断座、通信协议和故障代码等，两者基本原理和诊断项目类似。
OBD系统在我国发展较迟，在05年，国家环保总局颁布了规定在2007年7月1日实施国III排放法规，我国的排放法规与欧洲的排放标准类似。尽管OBD-II针对汽车排放起到明显的控制作用，为了更及时监测排放，OBD-III也出现了。增加了无线通信方式来读取发送机、变速器和ABS系统ECU中的数据，将车辆识别代码(VIN)、故障码等一些数据自动传送到交通管理部分，不过由于该系统可能涉及侵犯用户隐私，所以在考察中。
1.1工作原理
OBD系统的监控对象是传感器、执行器以及电子控制器本身，通过实时监测与排放相关的部件的工作信号，来判断汽车尾气排放是否超标，如果某些信号发生异常变化而出现排放超标的现象，系统会判断这一信号相关的部件或电路出现故障，点亮故障指示灯(MIL)并将对应故障码存入内部数据。故障信息可以通过诊断仪来读取。
1.2系统结构
车载中的诊断软件、传感器、执行器、诊断座以及外围的诊断仪设备共同组成了OBD系统，诊断口统一为16针，一般装在方向盘下方的内饰板中，分布如下图：
OBD输出参考标准为ISO15031，共6部分，包括诊断信息的通信方式、诊断数据的获取、故障码定义等多种标准，其中ISO15031-5排放有关诊断服务规定了诊断数据的输出格式和单位。此外SAEJ1979也是定义输出标准，功能与ISO15031一致。ISO15031和SAEJ1979的标准兼容CAN和K_line通讯
1.3OBD输出内容：
2.OBD各自子功能介绍
2.1关于Mode$01:读取动力系统诊断当前诊断数据
除所要求的冻结帧数据信息外，一旦需要，还应能够通过标准数据连接器的串口获得下述信息(如果车载电控单元具有、或通过车载电控单元能够被确定的信息)：诊断故障码、发动机冷却液温度、燃料控制系统状态(闭环/开环及其它)、燃油修正、点火正时提前、进气温度、歧管空气压力、空气流量、发动机转速、节气门位置传感器输出值、二次空气状态(上游、下游或大气)、计算的负荷值、车速和燃油压力。
以上是法规中的要求。
请求格式如下：
PID具体定义参考SAEJ1979
回复格式如下：
ECU支持的PID列表众多，我们可以通过发送特定的PID来查询是否支持。规定各个PID对应的范围表格如下：
如果你单独发送0100，表示查询在PID01-20之间，ECU支持哪些，如果支持的话，对应的bit位会置1。如果你发送010020406080A0，基本查询所有支持的PID，比如ECU#1支持的回复如下:
通过以上信息解读，该ECU#1支持PID03-08，PID0B-10，不支持PID29-30。
现在通过这个命令我们已经了解ECU支持的PID列表，我们可以查询具体的数据信息，比如PID05表示发送机冷却温度，PID0C表示发送机速度，我们可以发送指令：
Table136这个表里一次性发送查询很多信息，包括水温，转速，车速等信息。这个时候ECU#1回复了自己支持的PID具体数据信息，如下图：
上表里所有支持的数据都体现出来。如果简化来讲，我们只查询PID01,
发送：0101
回复：41018307EF63
PID01后面跟了4个字节，每个字节的bit表示不同含义，这里就不再详述了。
2.2关于Mode$02读取冻结帧数据法规要求如下描述:
一旦测定了任何部件或系统的首次故障，应将当时发动机状态的冻结帧存储在电控单元存储器中。如果随后发生了供油系统或失火故障，任何原存储的冻结帧应被供油系统或失火状态(取先发生者)所替代。存储的发动机状态应包括，但不限于：计算的负荷值、发动机转速、燃油修正值(如有)、燃油压力(如有)、车速(如有)、冷却液温度、进气支管压力(如有)、闭环或开环运转状态(如有)和引发上述数据被存储的故障代码………
必须按照IA.6.5.3的规定，以标准单位提供这些信号。实际信号必须能从默认值或跛行回家信号中被清晰地单独分辨出。
发送报文示例：
回复报文：
Frame表示组别，00是OBD标准规定的，如果主机厂自定义其他的帧，可以分其他编号，比如01,02等。
2.3关于Mode$03：读取排放相关动力系诊断故障码
Mode3使外部设备获取排放相关的动力系的确认的故障代码。如果同一故障在40个以上发动机暖机循环内不再出现，车载诊断系统可以清除该故障代码，Mode3不再输出该故障码。
发送格式：
回复格式：
2.4关于Mode$04：清除/重置排放相关诊断信息
Mode4使外部的测试设备能够清除ECU中排放相关的诊断信息，清除的信息包括：
发送指令：
回复指令：
如果无法清除，则会报负反馈，类似UDS服务中的NRC22响应码，条件不正确。
2.5Mode$05：读取氧传感器测试结果
Mode5读取氧传感器的监测结果。只有K_line的系统支持Mode5的输出，CAN通信系统氧传感器信息输出到Mode6。
ISO15031-5中定义了所有可以获得的氧传感器信息。每条信息都有一个TID与之相对应。Mode5支持输出哪些TID的输出是根据项目的具体配置设定的。
2.6Mode$06：读取指定监测系统OBD测试结果
对于所有需进行规定的车载评价试验(催化转化器、氧传感器等)的排放控制系统，除失火监测、供油系统监测和综合部件监测外，汽车最近进行的试验结果及用于比较的限值，均应能通过IA.6.5.3规定的标准数据连接器上的串行口获得。对于被监测部件和系统，除上述内容外，还应能通过数据连接器获得其最新试验结果的合格/不合格指示。
Mode6读取指定系统的监测结果。如氧传感器、催化器、VVT等系统，Mode6的输出也是根据项目配置而定。
发送格式：
回复报文：
CAN通信Mode6的输出包括OBDMID、TID、USID、测量值、最小值、最大值。OBDMID、部分TID、USID在ISO15031-5中有标准化定义。
Mode6输出的内容较多，ISO标准规定了Mode6的输出应遵循以下原则：
oMode6的输出要在诊断完成之后；新驾驶循环诊断完成前，Mode6的输出保持上一次的输出值
o对于无故障系统，Mode6输出的测量值在其上下限范围内
o如果诊断功能有Codeword控制，对于CodeWord关闭的情况，其Mode6的输出为不可见，如果输出是0就不行
o如果一个监测系统有多项输出，则其中任一项报出故障，其余监测项的输出都为0
oMode6的输出在fcmclr操作后，测量值、上、下限制全部清0，直到下一次诊断完成，才能输出。第一次刷软件后，诊断完成前，Mode6输出的测量值、最大值、最小值都为0
2.7Mode$07:读取当前或上一驾驶循环排放相关诊断故障码
ØMode7输出当前或上一驾驶循环的诊断故障码。这可以帮助维修人员在进行修理之后确认故障是否真的被移除了，而不必要进行多个驾驶循环；
ØMode7中显示的故障码并不一定表明系统一直存在相应的故障。Mode7的输出独立于Mode3。当故障被确认并且点亮了MIL灯，则该故障码就不再显示在Mode7中，而是显示在Mode3中了
发送格式：
回复格式：
2.8Mode$08:对OBD系统进行控制或测试
比如说：
发送请求打开OBD系统，控制或测试，关闭OBD系统，控制或测试，或者做循环操作，回复结果如汇报系统状态和测试结果等。
发送格式(这里举例读取支持的TIDs的示例)：
回复格式：
2.9Mode$09:读取车辆信息
其中一些信息被标准化规定，INFOTYPEs在SAEJ1979-DA中有定义。同样的，我们可以先发送查询支持哪些infotype，然后具体读取infotype的值
发送格式(查询支持的infotype)：
回复格式：
当我们查询到支持某个infotype之后，可以发送如下指令读取
发送:09XX
回复：49XXXXXX…
规定：INFOTYPE0x02:VIN
INFOTYPE0x04:Cal.ID
INFOTYPE0x06:Cal.CVN
2.10Mode$0A:读取排放相关永久DTC
功能是读取存储在NVRAM里的故障码，目的防止作弊，如通过清除故障码的方式消除故障。这些永久故障码可以通过ECU自身确认消除或者OBD系统自己决定这些出现的故障不会再出现。
发送指令：
回复指令：
引用资料：
[1]汽车OBD系统发展综述_陈传灿
[2]ISO15031-5-2011
广告：关注公众号：汽车电子工程师
全部评论 （0）