关于OBD协议（ISO 15031）的学习
今天是2022年7月20日，上海天气晴朗。老规矩，分享一段喜欢的文字，避免自己成为高知识低文化的工科男：
“
生命的吊诡、可爱的地方就在于，你永远不知道在那一个转弯，碰到什么样的人，甚至拿起一本什么样的书，一看，就改变了一生。人生总有确幸的美好的时刻，有时候为了追寻这种时刻，就值得活下来。
”
Return to today‘s topic！
最近在做关于OBD的相关内容工作，这里做一个备注。
“
OBD是英文On-Board Diagnostic的缩写，即车载诊断系统。这个系统随时监控发动机的运行状况和尾气后处理系统的工作状态，若发现有可能引起排放超标的情况，会马上发出警示。当系统出现故障时，故障灯(MIL)或检查发动机(Check Engine)警告灯亮，同时OBD系统会将故障信息存入存储器，通过标准的诊断仪器和诊断接口可以以故障码的形式读取相关信息。根据故障码的提示，维修人员能迅速准确地确定故障的性质和部位。
”
在车载诊断范畴，可以分为两个方向：
1、偏向OEM定义内容
2、偏向Society and Legislative Authority
本文关于OBD协议内容，ISO为其分配了ISO-15031系列标准号，共有7个子类。同样在传统燃油车强国美国，其国内组织SAE也为OBD分配了相应的标准号。
本文分享ISO15031-5，即OBD所用的诊断服务（0x01-09），说明其：
1)模式的作用（使用场景）
2)模式如何使用
OBD协议协议中定义9个诊断服务，每个服务用一个byte来代表，即所谓的Service ID（SID），具体内容如下：
Service 01 - Request Current Powertrain Diagnostic Data：
通过该服务，Tester端可以获取车载动力系统当前的诊断数据：
-> 具体单个定义传感器的状态；
-> 发动机转速；
-> 动力域DTC数量；
-> 故障指示灯是否亮起等。
格式为：SID + PID（Parameter ID），PID也是一个Byte，取值范围是0x00-0xFF，类似于UDS协议，ISO 15031定义了部分PID内容，也做了相当部分的预留。
因为该协议具备法规效应，OBD协议定义了众多PID，对于ECU支持哪些PID，诊断仪是如何获知？在实际应用过程中，PID分为两类：
-> 用于表征具体的数据；
-> 用于指出该ECU支持哪些PID。
在第二种使用场景中，PID分别是0x00 , 0x20 , 0x40…. 读取其中一个PID后ECU会返回4个字节的结果，从返回的4个字节中的每个bit表示其所对应的PID是否被支持。
PID 0x00 用于查询（0x01~0x20）之间支持的PID参数；
PID 0x20 用于查询（0x21~0x40）之间支持的PID参数；
PID 0x40 用于查询 （0x41~0x60）之间支持的PID参数，以此类推。
例如：
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支持情况，注意二进制转换。
只能说一句，协议定制者是真牛逼！
接着使用第二步：就可以读取相关支持的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。
类比UDS协议，每次请求一个PID，也可以一次请求多个，最多6个。而对于最新版ISO 27145协议，通过Service 22来实现对OBD服务车辆信息读取，这个时候规定是最少支持6个DID读取。
Service 02 - Request Powertrain Freeze Frame Data
对车车辆ECU出现并界定出某个故障，会将这个故障被Confirm时的相关状态信息“冻结”下来（UDS协议中叫快照信息），也就是行业内所谓的冻结帧，这些状态信息对车辆故障的确定非常重要，因为它们记录了车辆发生故障时的很多相关信息，冻结帧的载体同样是PID。在ISO 15031协议中，Service 02与Service 01命令的使用方法相同。只不过02读取的是故障发生时的数据，而01读取的当前数据，数据格式和含义都是相同的。与01命令不同的是，02命令中多了一个frame字节：
需要注意的是在OBD协议中，用frame = 0x00来代表读取冻结帧。如果主机厂想自己再定义些什么其他的帧，或者多定义几个冻结帧，则可以给frame分配上其他的编号。OBD只规定了ECU需要为一个DTC存储冻结帧，当ECU中同时存在多个DTC时，就要根据优先级来判定存储谁的冻结帧了。模式2的作用就是为了快速方便的了解，故障发生时刻的一个状态，以此来分析、排查以及定位故障，从而能够有效的提高售后维护的效率。
Service 03 - Request Emission-Related Diagnostic Trouble Codes
服务03用于读取存储在ECU中的与排放相关的“confirmed” DTC。Service 03命令的请求和响应格式：
Service 03的作用就是请求当前确认的故障（Comfirmed DTC）的故障码，以此就可以了解车辆发生故障时，是哪个故障导致的，进而就可以根据该故障的机理来分析故障，维修车辆。
Service 04 - Clear/Reset Emission-Related Diagnostic Information
Service 04用于清空ECU中存储的与排放相关的DTC。同时清除包括故障码、冻结帧、测试数据等等排放相关的内存数据。
该服务格式请求是一个字节的04，响应是一个字节的44。只有在发动机没有运转的时候才可以执行这个服务，否则ECU应该给出NRC 0x22（条件不满足）来拒绝该服务。
Service 05 - Request Oxygen Sensor Monitoring Test Results
Service 05用于读氧传感器的状态，监控氧传感器的测试结果，因为氧气的浓度对燃烧过程有着重要的影响，因此对排放也有着重大的影响，因此有必要进行测试监控。一般支持模式6的话也可以通过模式6来代替模式5的功能(对于OBDonCAN来说不支持该服务).
Service 06 - Request On-Board Monitoring Test Results for Specific Monitored Systems
车上不仅仅氧传感器的结果需要监控，还有其他很多的地方需要结构，比如催化剂、蒸发系统等等，那么可以通过Service 06来进行监控。
主机厂也可以根据需要去定义监控各个系统模块ID以及需要进行测试的参数TID。该服务用于请求对特定被监测系统的监测结果。OBD中定义了一个MID（Monitor ID）的表格，来标识被监测系统。一个ECU不一定需要支持所有的MID，获知具体支持哪些MID的方法与01和02服务所使用的方法相同.
06服务的response中，针对某一个MID，可能有多个TID（Test ID），因为针对一个系统可能有多个测试项目。TID表格也在OBD中定义。06服务的response格式固定，每个MID的每个TID有6部分组成,具体如下：
MID；
TID；
Unit And Scaling ID，用于标识这个TID的测试内容是什么，比如电压、时间、计数器之类的；
Test Value，实际测量值；
Min. Test Value，这个测量值的最小值；
Max. Test Value，这个测量值的最大值。
Service 07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle
Service 07也是获取DTC，但是它与03服务区别在于，它用于获取在当前以及上一个驾驶循环中出现的处于“pending”状态的DTC，而Service 03则是获取的是confirmed DTC。
请求及相应格式如下：
该服务的作用：
每次维修人员修理完之后，会清理故障，为了了解这个故障是不是真正解决了，就需要重新试一下，然后看这个故障是不是又会出现，如果是通过模式3去了解，则至少需要三个操作循环，而模式7则可当前操作循环就可以知道。
Service 08 - Request Control of On-Board System, Test or Component
Sercie 08用于对系统进行控制，进行元件测试操作。它相当于UDS中定义的2F和31服务。它的使用方法是SID + TID，注意这个TID与05和06服务的TID不同，在OBD中有一个专门给08服务使用的TID表格。
注：因为这个模式使用的比较少，比如我国的所有OBD是不支持08模式的，以下对其进行简单的介绍。这个模式就是通过定义测试标识符TID以及测试数据，去操作ECU进行测试。
Service 09 - Request Vehicle Information
Service 09用于读取车辆信息，请求格式：
SID + InfoType（个数若干）
InfoType在OBD标准中有定义。并不是所有的InfoType都需要被支持，具体哪些InfoType被支持，可以采用和01服务相同的方法相似。
以上分享是关于诊断协议OBD的内容，在车载诊断范畴与UDS是两个不同范畴。并且OBD协议是针对传统燃油车的规范（有法律效应）。但现状是新能源车慢慢在崛起，特别是电池组逐步解决续航行程和充电效率的问题，对于大方向（节能、环保、碳中和）的布局，我国都是一个极好的弯道超车机遇。在以往传统汽车强国：
日本押宝氢能源，大方向错误；
德在新能源车的电池和软件捉襟见肘的现状。
作为一个国家工业皇冠上的一颗明珠，汽车对于国家经济的反哺能力，有着极其重要的作用。看好这个方向，也庆幸自己在这个行业。
页:
[1]