OBD（On-Board-Diagnose）

---

前言

---

  早在20世纪80年代初，汽车工业发达国家的许多汽车制造商就开始广泛使用电喷发动机。为了监控排放相关的参数，例如尾气中的氧含量，发动机转速等，使其满足国家的排放标准，美国和欧洲制定了OBD（On-Board-Diagnose）标准，其实质就是通过监测汽车的动力和排放控制系统来监控汽车的排放。OBD定义了排放相关系统必须支持的诊断服务和数据传输格式，支撑OBD数据传输的底层数据链路可以是K线，也可以是CAN线，目前大多数车的OBD接口都是CAN总线。OBD是与UDS并列的一套应用层协议，对于与排放相关的ECU来说，通常这种ECU上既要实现OBD，也实现UDS。

一、OBD发展史

---

  OBD的概念最早是由通用汽车（GM）于1982年引入，其目的是监测排放控制系统。一旦发现故障，OBD系统就会点亮仪表板上的一个指示灯通知驾驶员，同时在车载计算机（通常称作发动机控制单元或模块，即ECU或ECM）内记录一个代码，这个代码可通过相应设备获取便于故障排除。

  通用汽车提出这一概念引起加州空气资源委员会（CARB）的重视。CARB于1985年采用SAE所制定的标准，要求从MY1988年所有在加州销售的车辆都必须具有一些基本的OBD功能。之后，美国环保局（EPA）要求自1991年起所有在美销售的新车必须满足相关OBD技术要求，这就是后面的OBD-I。
  汽车工程师协会（SAE）对诊断接口和通讯方式等技术细节进一步标准化，在OBD-I基础上发展成第二代OBD，即OBD-II。OBD-II在诊断功能和标准化方面都有较大的进步。故障指示灯、诊断连接口、外部设备和ECU之间的通讯协议以及故障码都通过相应标准进行了规范。此外，OBD-II可以提供更多的数据被外部设备读取。这些数据包括故障码、一些重要信号或指标的实时数据，以及冻结桢信息等。此后的1998年10月13日欧盟委托ISO组织在OBD-II制定了EOBD标准，我国也在2005年4月5日在EOBD标准上制定了一套COBD标准。
  新一代的无线传输系统OBDIII系统能够利用小型车载无线收发系统，通过无线蜂窝通信，卫星通信或者GPS系统将车辆的VIN,故障码及所在位置等信息自动通告管理部门。管理部门根据该车辆排放问题的等级对其发出指令，包括去何处维修的建议，解决排放问题的时限等。这些信息可在相关法规的基础上对维护不当从而造成过多排放污染的车辆惩罚。

二.汽车标准OBD-Ⅱ(自诊断接头)针脚定义

汽车上的OBD-II接口（母）：

ELM327用到的引脚：

2: SAE-J1850 PWM和SAE-1850 VPW总线(+)
4. 车身接地
5. 信号接地
6. CAN high (ISO 15765-4和SAE-J2284)
7. ISO 9141-2和ISO 14230-4总线的K线
10. SAE-J1850 PWM协议总线(-)
14. CAN low (ISO 15765-4和SAE-J2284)
15. ISO 9141-2和ISO 14230-4总线的L线
16. 蓄电池电压

全部引脚定义：

1. Manufacturer discretion. GM: J2411 GMLAN/SWC/Single-Wire CAN.
2. Bus positive Line of SAE-J1850 PWM and SAE-1850 VPW
3. Ford DCL(+) Argentina, Brazil (pre OBD-II) 1997-2000, USA,
4. Chassis ground
5. Signal ground
6. CAN high (ISO 15765-4 and SAE-J2284)
7. K line of ISO 9141-2 and ISO 14230-4
8. –
9. –
10. Bus negative Line of SAE-J1850 PWM only (not SAE-1850 VPW)
    Europe, etc. Chrysler CCD Bus(+)
11. Ford DCL(-) Argentina, Brazil (pre OBD-II) 1997-2000, USA, Europe, etc. Chrysler CCD Bus(-)
12. –
13. –
14. CAN low (ISO 15765-4 and SAE-J2284)
15. L line of ISO 9141-2 and ISO 14230-4
16. Battery voltage

根据ISO DIS 15031–3中相关内容，DLC是一个如下16针的插座： 各个针脚定义如下：
针脚 分配定义
1 厂家定义 [1]
2 SAE J1850 总线正 [2]
3 厂家定义[1]
4 车身地
5 信号地
6 ISO 15765–4定义的CAN高 [2]
7 ISO9141?2和ISO14230?4定义的K线 [2]
8 厂家定义 [1]
9 厂家定义 [1]
10 SAE J1850 总线负 [2]
11 厂家定义 [1]
12 厂家定义 [1]
13 厂家定义 [1]
14 ISO 15765–4定义的CAN低 [2]
15 ISO9141?2和ISO14230?4定义的L线 [2]
16 永久正电压
[1] 1, 3, 8, 9, 11, 12 和13 未做分配，可由车辆制造厂定义。
[2] 2, 6, 7, 10, 14 和 15 使用作诊断通讯的。根据实际使用的通讯协议的不同，它们往往不会都被使用，为使用的可由车辆制造厂定义。 更详细的定义和要求参见ISO/DIS 15031–3。对于不同的通讯协议，有效的针脚也不同。在选购诊断线的时候需要注意诊断线上的针脚是否符合要求.

---

三、美标和欧标区别

1.诊断座接头定义区别

  美国和欧洲的车载故障诊断系统的诊断连接器结构相同，采用统一的16端子诊断连接器，但端子的定义略有不同。 1、3、4、5、8、9、11、12、13、16端子定义相同，其中4号端子为机箱接地，5号端子为信号接地，16号端子为电池正极，其余为厂家预留利用。美国OBD-II使用2、6、10、14号端子作为数据传输终端，其中2、10号端子为SAE J1850通讯数据传输终端。如果在汽车电控系统中使用CAN总线技术，则端子6和14定义为CAN数据传输端子，分别连接CAN总线的两条信号线CAN High和CAN Low。如果使用 CAN 总线，则端子 6 和 14 为制造商保留。端子 7 和 15 为制造商保留。
  欧洲OBD-II使用7号和15号端子作为ISO 9141-2或ISO/DIS 14230的通信数据传输终端。根据通信协议，汽车电子控制单元（ECU）通过诊断连接器与测试仪器进行通信，可以使用单线（K线）通讯，或双线（K线和L线）通讯。使用单线通讯时，7号端子接K线，端子 15 为制造商保留。使用双线通讯时，端子 7 接 K 线，端子 15 接 L 线。端子 2、6、10 和 14 为制造商保留。

2.通讯协议定义区别

  OBD-II标准使用的通讯协议有三个：SAE J1850 PWM（脉冲宽度调制），SAE J1850 VPM（可变脉冲宽度调制），ISO 9141-2（或 ISO/DIS 14230-4）,其他通讯引脚定义待定。
  欧洲车系使用ISO 9141-2通讯协议，其他通讯引脚定义待定。

---

四、OBD诊断服务介绍

与OBD相关标准主要为ISO15031和SAE J1979等，其OSI模型如下图所示：

ISO为OBD分配了ISO-15031系列标准号，总共7本。而美国的SAE也为OBD分配了相应的标准号。它们在内容上是相同的。具体对应关系如下。

本文只重点关注ISO-15031-5，即OBD所用的诊断服务。在理解了这些诊断服务之后，其他的内容也就很容易理解了。

OBD总共定义了9个诊断服务，每个服务用一个byte来代表，即所谓的Service
ID（SID），从0x01到0x09。

Service 01 - Request Current Powertrain Diagnostic Data：

该服务用于读取动力系统当前的诊断数据，比如某个传感器的状态、发动机转速、DTC数量、故障指示灯是否亮起等，命令格式是SID + 若干PID（Parameter ID）。每个PID也是一个byte，所以理论上PID取值范围是0x00至0xFF，但是ISO-15031-5只明确定义了部分PID，其余的值都保留。问题来了，OBD定义了如此多的PID，那么某个ECU到底支持哪些PID，诊断仪是如何获知的呢？实际上，PID分为两类，一类用于表征具体的数据，而另一类则用于指出该ECU支持哪些PID。用于第二种目的的PID分别是0x00 , 0x20 , 0x40…. 读取其中一个ID后ECU会返回4个字节的结果，这4个字节中的每个bit表示其所对应的PID是否被支持。以下面这个例子来说明就很容易理解了：

OBD request for SID 01

OBD response for SID 01

通常来说，诊断仪要首先读取00、20、40这些ID，然后就知道ECU支持哪些其他的PID了，而其他的PID就是很直接地表示某种数据，在ISO-15031-5的附录中有全部数据格式的定义。

Service 02 - Request Powertrain Freeze Frame Data

一旦ECU确定了某个故障，就要把这个故障被确定时的相关状态信息“冻结”下来，即所谓的冻结帧，这些状态信息对车辆故障的确定非常重要，因为它们记录了车辆发生故障时的很多相关信息，这些状态信息数据必须在ISO-15031-5的PID列表中选择（与Service 01使用的PID列表相同）。02命令和01命令的使用方式非常相似，只不过02读取的是故障发生时的数据，而01读取的当前数据，数据格式和含义都是相同的。与01命令不同的是，02命令中多了一个frame字节，如下图所示：

OBD规定，用frame = 0x00来代表读取冻结帧。如果主机厂想自己再定义些什么其他的帧，或者多定义几个冻结帧，则可以给frame分配上其他的编号。

需要指出的是，OBD只规定了ECU需要为一个DTC存储冻结帧，当ECU中同时存在多个DTC时，就要根据优先级来判定存储谁的冻结帧了。

Service 03 - Request Emission-Related Diagnostic Trouble Codes

服务03用于读取存储在ECU中的与排放相关的“confirmed” DTC（可以参见本专栏中“汽车控制器（ECU）中DTC的状态位”一文），用法非常简单，它没有任何参数，诊断仪只需要发送03即可。下面两张图分别展示了03命令的请求和响应格式。

OBD request for SID 03

OBD response for SID 03

在03命令的响应中，第2个字节表示DTC数量，后面每两个字节表示一个DTC。

Service 04 - Clear/Reset Emission-Related Diagnostic Information

04服务用于清空ECU中存储的与排放相关的DTC。除了DTC以外，以下的信息也要被清除。

执行04命令时被清理的信息

它的使用非常简单，请求是一个字节的04，响应是一个字节的44。只有在发动机没有运转的时候才可以执行这个服务，否则ECU应该给出NRC 0x22（条件不满足）来拒绝该服务。

Service 05 - Request Oxygen Sensor Monitoring Test Results

05服务用于读取氧传感器的状态，对于OBDonCAN来说不支持该服务，相应的功能由06服务实现。

Service 06 - Request On-Board Monitoring Test Results for Specific Monitored Systems

该服务用于请求对特定被监测系统的监测结果。OBD中定义了一个MID（Monitor ID）的表格，来标识被监测系统。一个ECU不一定需要支持所有的MID，获知具体支持哪些MID的方法与01和02服务所使用的方法相同，也是先读取00，20，40等ID。06服务的命令格式是SID + 若干MID，命令格式如下

06服务的request

06服务的response

06服务的response中，针对某一个MID，可能有多个TID（Test ID），因为针对一个系统可能有多个测试项目。TID表格也在OBD中定义。06服务的response格式固定，每个MID的每个TID有6部分组成，可以在上面的例子中看出：

1. MID

2. TID

3. Unit And Scaling ID，用于标识这个TID的测试内容是什么，比如电压、时间、计数器之类的。

4. Test Value，实际测量值

5. Min. Test Value，这个测量值的最小值

6. Max. Test Value，这个测量值的最大值

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

07服务也是获取DTC，但是它与03服务区别在于，它用于获取在当前以及上一个驾驶循环中出现的处于“pending”状态的DTC（可以参见本专栏中“汽车控制器（ECU）中DTC的状态位”一文），而03服务获取的是confirmed DTC。

它的请求格式和响应格式如下两幅图：

07服务的request

07服务的response

Service 08 - Request Control of On-Board System, Test or Component

08服务用于对系统进行控制，进行元件测试操作。它相当于UDS中定义的2F和31服务。它的使用方法是SID + TID，注意这个TID与05和06服务的TID不同，在OBD中有一个专门给08服务使用的TID表格。

Service 09 - Request Vehicle Information

09服务用于读取车辆信息，它的命令请求格式是SID + 若干InfoType ，InfoType在OBD标准中有定义。并不是所有的InfoType都需要被支持，具体哪些InfoType被支持，可以采用和01服务相同的方法来获知，读取00，20，40等ID。比如InfoType = 02代表17个ASCII的Vehicle Identification Number。

目前，UDS和OBD是两套应用层协议，而OBD所提供诊断服务其实属于UDS所提供服务的一个子集，理论上来说UDS中的诊断服务都可以实现OBD中的要求。为了降低同时需要实现两套协议的成本，所以标准化组织分配了ISO 27145（World-Wide Harmonized OBD）这个标准号来将OBD与UDS统一，使用UDS中的诊断服务来替代OBD相关的诊断服务。具体替换方案如下表：

WWH-OBD中UDS与OBD服务的对应关系

比如，在OBD中，使用02，03，07分别读取confirmed DTC，DTC环境数据，pending DTC，而这些功能都可以通过UDS中的19服务来实现（配合上不同的状态掩码和读取参数）。

参考内容：
1.https://wenku.baidu.com/view/e195b9f8910ef12d2af9e71b.html
2.http://www.360doc.com/content/21/0106/08/30375878_955427156.shtml