包含OBD（On-Board Diagnostic）指的是在线诊断系统，是汽车上的一种用于监控车辆状况以及控制排放的一种在线诊断系统。本篇文章主要围绕OBD的九种模式进行介绍，当然也会辅助介绍一些OBD相关的内容。
对于一般的车主，可能有接触过OBD口，可以用它来查看一些车内的参数等等，但是OBD它到底用来做什么用呢？
还是以一贯的思路，进行分点说明：
a.用于监控车辆基本参数，例如监控里程、车速、油门踏板位置、冷却液温度等等的一些参数；
b.用于监控排放相关的参数，这是OBD很核心的一个功能，比如各种尾气的含量，氧含量等等，以此来保证满足各国的标准；
c.用于车辆故障的诊断，例如我们车故障灯亮了，送到维修店后，维修人员就会拿出诊断仪，请求发生的故障内容，以及故障时刻的冻结帧数据，以此来方便故障排查；
d.当然还有小部分会使用OBD进行一些控制功能，这部分在中国是没有的。
大家看过我前面的文章的话，也有对UDS进行介绍，那么UDS和OBD都是车上诊断的标准，他们有什么区别呢？
首先从适用对象来说，OBD出现的更早，那么它主要针对传统燃油车，并且OBD主要是用于排放相关的诊断，而UDS是统一诊断系统，那么它的适用性则更广一点，它囊括了非排放相关的车身上所有ECU的诊断。可以简单的理解OBD就是用于排放相关的ECU，如发送机控制单元，减速器控制器等；而UDS则包含了车身上几乎所有ECU的诊断，例如VCU BCM DCDC等等。
第二点：也是因为他们适用对象的不同，所以他们支持的服务是不一样的，这点看标准就知道了。
稍微总结一下就是OBD主要用于与排放相关的ECU的诊断，而UDS则是排放除外的其他ECU的统一诊断标准。OBD的使用对象主要是传统燃油车中排放相关的ECU，而UDS使用对象既可以是燃油车中的ECU也可以是混动纯电动中的ECU。一般传统燃油或混动车中与排放相关的ECU既要支持OBD也要支持UDS，而其他的ECU一般仅仅需要支持UDS。
从图中我们也知道，各个引脚之间的关系，那么这个端口也是通过国际标准进行定义的OBD-II端口，在使用时，我们需要买对应的端口来进行与汽车诊断端口进行通信。
一般汽车这个诊断端口在我们的方向盘下面，油门踏板上面（不同厂家可能不一致）。
从图中我们也知道，各个引脚之间的关系，那么这个端口也是通过国际标准进行定义的OBD-II端口，在使用时，我们需要买对应的端口来进行与汽车诊断端口进行通信。
为了能够快速的了解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的话会采用多帧传输，这里仅仅是示意。
版权声明：本文为CSDN博主「摸鱼的攻城狮」的原创文章，遵循CC 4.0 BY-SA版权协议，获得作者转载许可。
关于 ASPICE 的理解
CAN FD网络设计提示和建议
详解汽车Bootloader设计
特斯拉Autopilot系统安全研究|附dbc下载
详解功能安全概念阶段
详细揭秘大众ID.4的高压系统
特斯拉Model 3的BMS系统
结合AUTOSAR和DDS实现灵活的车辆架构
