国六轻型车车载诊断系统开发

2020-04-07吴向畅郭文军

汽车工程学报 2020年1期

吴向畅，石平，郭文军

（国家燃气汽车工程技术研究中心重庆凯瑞动力科技有限公司，重庆 401122；2. 四川广播电视大学，成都 610073）

随着国家汽车污染物排放法规要求的不断提高，对OBD 系统的要求也日益严格。OBD 系统通过车内发动机电子控制单元（Electronic Control Unit，ECU）监测车辆在实际使用时排放系统的工作状况，并能监测排放系统的故障，确保有效控制在用机动车的排放[1]。车辆出现故障时，OBD 系统可通过点亮故障指示灯（Malfunction Indicator Light，MIL）通知驾驶员，同时存储故障代码、冻结帧等信息。维修人员可通过诊断工具读取ECU内相关故障信息，便于对车辆进行维修。

国六排放法规GB 18352.6—2016 对OBD 系统的要求从测试循环、监测项目、检测条件、在用监测频率（In-Use Performance Ratio，IUPR）到污染物排放限值等方面较国五排放法规GB 18352.5—2013[2]均有不同程度的加严。表1 列举的是第一类车的OBD 阈值。此外，国六排放法规还新增了永久故障代码、曲轴箱强制通风（Positive Crankcase Ventilation，PCV）系统监测、发动机冷却系统监测等要求。因此，原国五OBD 系统已无法满足国六新法规的要求，需重新对OBD 系统软件进行开发，以适应新排放法规的要求。

表1 第一类车OBD 阈值

1 OBD 系统软件总体架构设计

OBD 系统软件由故障监测、故障管理、协议栈三个模块组成，其总体架构如图1 所示。

图1 OBD 系统软件总体架构

故障监测模块用于监测综合部件（传感器及执行器）、系统功能及ECU 自身是否出现性能劣化及异常。

故障管理模块是OBD 系统的中枢，主要进行故障监测频率的设置及计数、故障确认、故障相关数据存储、故障消失、故障修复、故障清除及MIL控制。

协议栈用于实现ECU 与诊断工具的通信。参照ISO 15765-4：2016[3]标准，进行了简化的OSI五层网络模型设计，由应用层、传输层、网络层、数据链路层及物理层构成。应用层主要负责通信管理、数据传输、输入输出控制、故障代码读取及清除。传输层和网络层将应用层生成的数据进行分包等相关处理，以符合ISO 11898-1：2015[4]的CAN 数据帧标准。数据链路层及物理层，定义了硬件接口相关参数。

2 故障管理模块设计

故障管理的流程如图2 所示。

图2 故障管理流程

IUPR 等于分子计数除以分母计数。催化器监测、氧传感器监测、VVT 系统监测的最小IUPR 应大于0.336。

分子及分母计数增加：按GB 18352.6—2016 标准要求，在环境温度、海拔高度、发动机运行时间、车速大小、怠速运行时间等相关参数同时满足特定条件时，相应的分母计数增加1 次；当故障监测中所必需的全部条件都满足时，相应的分子计数增加1 次。

每个驾驶循环，条件满足时，分子计数或分母计数加且仅增加整数1。

分子计数和分母计数中断及恢复条件：

（1）若监测到故障时，即存储了一个未决故障代码或确认故障代码，在10 s 内停止故障相对应的分子计数和分母计数的增加；当该故障不再出现时，在10 s 内恢复其分子计数及分母计数的增加。

（2）当分母计算规则中的测量环境温度、海拔高度、发动机工作时间等参数的部件发生故障时，在10 s 内停止所有的分子计数及分母计数的增加；当该故障不再出现时，在10 s 内恢复相应分子和分母计数的增加。

故障确认及相关数据存储：当前驾驶循环，监测到故障的次数超过特定条件（该循环内持续特定时间监测到特定的次数），即确认为未决故障，存储一个未决故障代码。若在下一驾驶循环再次监测到该故障，立即持续点亮MIL，存储冻结帧数据、一个未决故障代码和一个确定的故障代码，同时存储一个永久故障代码。

故障消失：若当前循环监测到故障不再出现，则清除该故障标志位。

故障修复：至少3 个连续驾驶循环中，OBD系统不再监测到故障，之前导致点亮MIL 的故障也不再出现，并且也没有检测到其它需要单独点亮MIL 的故障，熄灭MIL，同时清除该故障的永久故障代码。

故障清除：若OBD 系统在连续的40 个到41个暖机循环未再检测到该故障，且MIL 在连续的40 个到41 个驾驶循环中也没有被该故障点亮，则清除确认的故障代码，同时清除因该故障存储的冻结帧数据。

3 协议栈模块开发

协议栈基于CAN，按照ISO 15765 相关标准要求进行开发。基于事件驱动型，采用一问一答的方式进行通信，由诊断工具提问，ECU 进行应答。具体实现流程如图3 所示。

图3 协议栈报文处理流程

ECU 的地址信息、对应的诊断服务标识及诊断或故障相关数据在应用层中进行设置及处理。在传输层及网络层中，ECU 的地址信息被转换为11/29位的标识符。诊断服务标识、诊断或故障相关数据会合并为由多个单字节构成的数据。

若诊断相关的数据少于或等于8 个字节，ECU在接收到诊断工具的请求后，直接响应，发出该单帧数据即可，较为简单。

当诊断相关的数据超过8 个字节时，由于单帧CAN 数据最多只能传输8 个字节的数据，无法通过单帧数据发出。作为发送端的ECU 需要将数据进行分包，拆分为多帧数据再进行发送。

多帧数据的通信流程如下：

（1）ECU 接收到诊断工具的请求后，根据收到的服务类别请求，将分包后的第1 帧数据发出。

（2）诊断工具接收到ECU发出的第1帧数据后，将发出流控制帧。该帧包含诊断工具可接收的块大小（CAN 数据帧数）、流状态及连续两帧数的最短发送时间间隔。

（3）ECU 根据接收到的流控制信号，按规定的时间间隔要求，连续发送与块大小相匹配的数据帧。

（4）诊断工具接收完ECU 发送的连续帧后，将再次发送流控制帧。

上述步骤3、4 将反复执行，直到ECU 发出长度小于块大小的最后一块数据[5]。

需要注意的是，发出的每一帧数据都应填满8字节。若当前帧的数据未满8 字节，剩余字节需用0 进行填充。

4 诊断实施验证

前氧传感器的响应速率监测是系统功能监测中最为重要的监测项目之一。

4.1 故障监测

氧传感器主要用于监测发动机的空燃比，是发动机电控系统闭环控制系统的一个重要零件。氧传感器信号响应变慢将会造成空燃比反馈延迟，直接影响到电控系统空燃比的闭环控制及响应特性[6]，严重的还可能导致排放超标。

诊断原理：当发动机处于理论空燃比闭环控制，且发动机的转速、负荷、水温相关信号均满足监测工况要求时，若ECU 测得氧传感器输出电压信号从浓到稀，再到浓的循环时间超过阈值，就可监测到氧传感器的响应速率变慢。如图4 所示，实线为正常的氧传感器信号，虚线为劣化后响应速率已变慢的氧传感器信号，通过监测循环时间的长短，并与标准阈值进行比较，从而判断氧传感器是否已劣化。

其故障监测流程如图5 所示。

图4 氧传感器信号

图5 氧传感器响应速率监测流程

4.2 协议栈

与诊断工具通信的OBD 服务共10 类，可读取ECU 中的当前动力系统诊断数据、故障代码、冻结帧、车辆信息等相关OBD 数据。下面以第三类OBD 服务（读取确认故障代码）为例，介绍用诊断工具读取确认故障代码时，ECU 的相关工作流程，如图6 所示。

图6 与诊断工具通信流程

诊断工具通过CAN 发出的ID 为0x7DF 的服务请求信号。ECU 根据接收到的诊断服务请求类型进行相应的响应。当ECU 接收到的诊断服务请求数据的第2 个字节为0x03（即第三类服务请求）时，ECU 先判断当前是否存在已存储的确认故障代码，后按ISO 15031-5：2015[7]的相关要求进行答复。答复的数据见表2。

表2 第三类服务答复数据

若当前无确认的故障代码，则ECU 回复的单帧CAN 数据为“0x 02 43 00 00 00 00 00 00”。当ECU监测到当前有且仅有前氧传感器响应慢故障P0133时，ECU 回复的数据也为单帧数据“0x 04 43 01 01 33 00 00 00”。

当确认故障代码数超过2 个时，因故障代码的响应数据已超过8 个字节，无法通过单帧CAN 数据发送，需进行分包处理，通过多帧CAN 数据发送出来。具体的处理流程如图3 所示。CAN 的波特率设置为500 kBit/s。

4.3 验证试验

为验证ECU 中OBD 软件的功能，在某款燃气乘用车上，使用氧信号电子模拟器模拟劣化后响应变慢的氧传感器信号，并将该劣化后的信号输入ECU，如图7 所示。

将氧信号电子模拟器连接在车上并设置好，进行了一轮WLTC 循环的预处理后，通过诊断工具，可读取到未决故障代码P0133。预处理后，将车辆停在排放实验室进行冷浸处理。紧接着，进行WLTC 排放测试循环，同步测量汽车排放的污染物。在排放试验结束之前，ECU 再次检测到了该故障，点亮了MIL，同时存储了一个确认的故障代码P0133、一个永久故障代码P0133，和冻结帧数据。