为了监控排放相关系统，比如发动机和变速箱，美国和欧洲制定了OBD(On-Board-Diagnose)标准。OBD定义了排放相关系统必须支持的诊断服务和数据传输格式，支撑OBD数据传输的底层数据链路可以是K线，也可以是CAN线，目前大多数车的OBD接口都是CAN总线。OBD是与UDS并列的一套应用层协议，对于与排放相关的ECU来说，通常这种ECU上既要实现OBD，也实现UDS。下图展示了UDS与OBD在整个诊断通信协议栈中的位置。

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 01OBD 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 03OBD 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服务的request06服务的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服务的request07服务的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服务来实现(配合上不同的状态掩码和读取参数)。