仅供个人学习，如有侵权，请联系博主删除，谢谢
一.联系？
（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]/q1449516487/article/details/84990160?utm_medium=distribute.pc_relevant.none-task-blog-2defaultbaidujs_title~default-5.pc_relevant_default&spm=1001.2101.3001.4242.4&utm_relevant_index=8
[2]https://chilaidashi./article/details/107978450
