仅供个人学习，如有侵权，请联系博主删除，谢谢

一.联系？

（1）由来： 应对燃油车，监控排放，引入OBD，即OBD-I；但OBD-I百家争鸣，物理接口形式各异。
（2）改良： 由于开发性和接口统一形式需要，进而改良OBD-I，形成OBD-II；物理接口统一，软件协议=通用+OEM各自定义，由SAE（美国汽车工程学会）定义并推出的标准，监控汽车尾气排放的需求。
（3）发展： 车载电子设备功能变得复杂，引入了UDS(统一诊断服务），定义了服务格式和统一了接口接口的层次标准，UDS也使用OBD-II接口。

下图中，Vehicle manufacturer enhanced diagnostics（汽车制造商增强诊断）属于UDS分层OSI列，Legislated OBD属于OBD-II，Legislated WWH-OBD （全球统一车载诊断，标准化组织分配了ISO 27145（World-Wide Harmonized OBD）这个标准号来将OBD与UDS统一，使用UDS中的诊断服务来替代OBD相关的诊断服务。）

二. 区别？

（1）协议： OBD是排放相关的诊断内容，主要是ISO 15031-5协议，为法规强制要求燃油车满足的协议，燃油车必须满足（燃油车通常既满足UDS协议，又满足OBD协议，这两个协议不冲突），电动车是不需要满足的；UDS主要是14229-1协议，可以应用汽车上所有ECU。
（2）服务ID(SID)： SID < 0x10，是OBD。用于车辆排放检测。SID >=0x10，是UDS。接口是 ：诊断链接头(DLC)Data Link Connector 。UDS使用OBD-II接口。
（3）关注点： OBD是关注车辆实时排放的理念形成的行业规范，而UDS是诊断服务的统一化规范。
（4）适用范围： 而OBD是面向排放系统ECU的，UDS是面向整车所有ECU(电控单元)的。

三. 总结

OBD和UDS两者之间并不存在谁替代谁。

四. OBD的9大模式操作介绍

为了能够快速的了解OBD的各个模式，以下针对每个模式从2方面进行介绍；

1).模式的作用（使用场景）

2),模式如何使用

a.模式1-请求动力系统当前数据
1).模式的作用

从这个定义我们就了解到，通过该模式我们可以去请求车辆上动力系统的一些数据，但是这些数据都是需要预先定义好的，如何进行定义呢，那么ISO标准规定了一些参数标识符即PID（parameter Identifiers），每个PID代表一个变量参数，但是呢在CAN上传输怎么去识别这个参数呢，其实就是顶一个8bit的数据来代表这个参数，比如PID 0x01 表示DTC清除后的监控状态，比如PID 0x05 表示电机冷却液的温度 ，那么ISO15031-5它定义了很多这样的PID参数，这样定义是很有意义的，因为这可以保证所有厂家的OBD可以尽可能的统一，从而方便通用。

我们稍微总结一下，模式1的作用就是 通过预先标准定义好的一些PID参数，去请求动力系统当前的一些数据（如速度、里程、温度等），以此来了解当前车辆的一些状态。

2).模式如何使用

ISO其实定义了很多PID参数，但是并不要求所有的主机厂把这些参数都实现，也就是说PID参数是可以选择支持的。那么我们怎么知道这个厂家支持哪一些参数呢？其实模式1中它有一些PID 0x00\0x20\0x40\0x60\0x80等就是用来查询到底支持哪些服务的。具体如何使用如下：

PID 0x00 用于查询（0x01~0x20）之间支持的PID参数

PID 0x20 用于查询（0x21~0x40）之间支持的PID参数

PID 0x40 用于查询 （0x41~0x60）之间支持的PID参数

以此类推后面的0x60 0x80

使用第一步：查询支持的PID参数（req表示请求（request），res表示答复（response））

req：01 00

res：41 00 xx xx xx xx

左起第一个xx表示0x01~0x08之间的PID支持情况 将xx转为2进制 如xx=0x65 ->xx=0110 0101 从左往右 那么表示支持PID 0x02 0x03 0x06 0x08

左起第二个xx表示0x09~0x10之间的PID支持情况 按照同样的转化方式

左起第三个xx表示0x11~0x18之间的PID 支持情况 按照同样的转化方式

左起第四个xx表示0x19~0x20之间的PID支持情况 按照同样的转化方式

是不是0x00就是查询0x01~0x20之间支持的PID情况？

同理对0x20 0x40等进行查询

使用第二步：就可以读取相关支持的PID参数的值了，假如支持PID 0x04 0x05 0x0d

req:01 04 05 0c

res:41 04 xx xx 05 xx 0d xx

其中xx表示支持的PID的值了，比如0d表示当前的车速，0d后面的xx的值是64，及对应的是100KM/h，即请求到的车速为当前100km/h

多说几句就是我们可以每次只请求一个PID，也可以一次请求多个，最多6个，而答复的话可能不会按照顺序来，如果在CAN上，答复的数据超过8个byte的话，那么它就会分出几个帧来进行答复。

b.模式2-请求冻结帧数据
1).模式的作用

首先解释一下冻结帧，所谓的冻结帧你可以理解为故障发生时刻的一些环境数据，冻结帧的存在就是为了尽可能了解故障发生时的一些参数，以此来方便分析故障。

因此我们可以这样说模式2的作用就是为了快速方便的了解，故障发生时刻的一个状态，以此来分析、排查以及定位故障，从而能够有效的提高售后维护的效率。

2).模式的使用

使用第一步：和模式1一样，先要查询支持的冻结帧的PID参数，格式也和模式1类似。

使用第二步：因为冻结帧是因为故障发生导致存储的，因此我们先要知道导致存储的冻结帧的故障码是什么。

req:02 02 xx //这里xx表示帧序号

res:42 0x xx xx xx //左起 第一个xx表示帧序号，第二个xx 表示DTC（故障码）高字节 第三个xx 表示DTC（故障码）低字节

使用第三步：请求相应的冻结帧数据，比如支持PID 0x0C(速度) 0x05（温度）参数 ,请求frame 00

req:02 0c 00 05 00 //这里00表示frame 00

res:43 0c 00 xx xx 05 00 xx 这里左起前两个xx表示速度 后面的xx表示温度

c.模式3-请求排放相关的故障码
1).模式的作用

首先我们了解一下故障码，所谓的故障码就是代表某一种故障的代码，比如氧气传感器短路的故障码为P0130 那么这些故障码在IDS15031-6中都有定义，对应can报文上两个字节DTC_H 和DTC_L 例如这里的P0130 对应的DTC_H = 0x01 DTC_L=0x30。

那么模式3的作用就是请求当前确认的故障（Comfirmed DTC）的故障码，以此就可以了解车辆发生故障时，是哪个故障导致的，进而就可以根据该故障的机理来分析故障，维修车辆。

2).模式的使用

req:03

res:43 03 01 41 01 45 01 48 // 03表示DTC的个数，后面三对颜色表示三个故障码P0141 P0145 P0148

如果没有故障则会回复 00 00…

d.模式4-清除排放相关的故障信息
1).模式的作用

为啥要清除故障信息呢，因为车子在出厂后，我们不能让车故障灯亮着就出厂吧，这是其一，其二就是每次维修好之后，有必要将故障清除掉，表示该故障已经解决，还有就是可以腾出内存空间，以便后续发生的故障进行存储。

2).模式的使用

该模式的使用比较简单；

req:04

res:44

就算没有故障，也会返回正响应；注意这里清除的数据比较多，包括故障码、冻结帧、测试数据等等排放相关的内存数据都会清除掉。

e.模式5-请求氧传感器的检测结果
1).模式的作用

显然根据名字我们就可以知道，这个模式的作用就是监控氧传感器的测试结果，因为氧气的浓度对燃烧过程有着重要的影响，因此对排放也有着重大的影响，因此有必要进行测试监控。一般支持模式6的话也可以通过模式6来代替模式5的功能。

2)模式的使用

使用第一步：查询支持的氧传感器支持的测试表示符TID（Test Identifiers），这是TID也在IDS15031-5的附录中有定义。如模式1和2查询PID一样，模式5查询TID也是类似使用0x00…来查询；

使用第二步：通过PID 0x13 0x1D来查询氧传感器的位置，因为动力系统模块中，可能多个地方都有O2传感器，如图定义了字节信息对应传感器的位置

使用第三步:查询氧传感器的测试结果，

根据第一步获得的TID 如0x05 和第二步获得的O2传感器位置0x01，那么就可以进行获取氧传感器的测试结果。

req:05 05 01

res:45 05 01 12 00 19 //这里的12表示测试结果，00表示测试结果范围的最小值，19表示测试结果范围的最大值。

f.模式6-请求指定监控系统的测试结果
1).模式的作用

车上不仅仅氧传感器的结果需要监控，还有其他很多的地方需要结构，比如催化剂、蒸发系统等等，那么可以通过模式6来进行监控。

那么主机厂也可以根据需要去定义监控各个系统模块ID以及需要进行测试的参数TID。

2).模式的使用

使用第一步：也是查询支持的TID

使用第二步：查询支持的组件ID（若有的话）

使用第三步：请求测试结果 比如 TID 0x11 模块ID 0x01

req:06 11

res:46 11 01 xx xx xx xx //左起前两个xx表示测试结果，后两个xx表示测试值的限制值，意思就是表示测试结果是否在范围内。

g.模式7-请求当前或上一驱动周期检测到的排放相关的故障码
1).模式的作用

为啥有了03请求故障码，还需要07模式呢，我们可以看到，03模式主要请求的是确认的故障码（比如一个故障发生后，需要连续3个驱动周期才能发展为确认的故障），而这里07模式表示的是当前的或上一驱动周期发生的故障（这里强调的是上一驱动周期或当前驱动周期发生的，意思是pending），以上是他们请求的故障码的区别。那么需要请求pending类的故障呢？这是因为，每次维修人员修理完之后，会清理故障，为了了解这个故障是不是真正解决了，就需要重新试一下，然后看这个故障是不是又会出现，如果是通过模式3去了解，则至少需要三个操作循环，而模式7则可当前操作循环就可以知道。

总结一下可以这么说07模式就是帮助技术员快速了解故障问题是否解决。

2)模式的使用

同03模式，可参考03模式。

h.模式8-请求控制在线系统或组件
1).模式的作用

因为这个模式使用的比较少，比如我国的所有OBD是不支持08模式的，以下对其进行简单的介绍。

这个模式就是通过定义测试标识符TID以及测试数据，去操作ECU进行测试。

2).模式的使用

如定义了TID 0x01 测试数据 00 00 00 00 00

req:08 01 00 00 00 00 00

res:48 01 00 00 00 00 00

i.模式9-请求整车信息
1)模式的作用

大家知道车辆中，有一个很重要的信息就是VIN码，也就是车辆标识码，这个码可是这辆车的“身份证”，那么我们怎么读这个身份证信息呢，这就需要我们使用09模式了。

此外还包括一些标定ID 标定校验ID ECU名称 IPT等信息可以通过09模式来读取。

2)模式的使用

和前面提到的PID TID一样，这里定义了一个叫InfoType的，你可以理解为消息类型，其实也同样是用一个byte来表示某个信息，比如infoType = 0x02表示VIN码这个信息。

使用第一步：类似查询支持的PID TID一样，这里第一步也是查询支持的InfoType；

使用第二步：根据支持的InfoType来请求其对应的值，如请求VIN码 0x02为例

req:09 02

res:49 02 32 31 47 53 78 98 27 18 38 38 85 92 92 82 71 82 92 //这里标红部分就是VIN的内容，如果是CAN的话会采用多帧传输，这里仅仅是示意。

以上主要针对OBD进行说明，更多具有价值的是读者去体会和使用其中提到的PID TID以及InfoType，经过几次使用之后会对这个协议会有更深的理解。

转载自：[1]https://blog.csdn.net/q1449516487/article/details/84990160?utm_medium=distribute.pc_relevant.none-task-blog-2_defaultbaidujs_title~default-5.pc_relevant_default&spm=1001.2101.3001.4242.4&utm_relevant_index=8
[2]https://chilaidashi.blog.csdn.net/article/details/107978450