目前，针对中重型车用柴油机尾气的排放，主要有两种技术路线，一是EGR（废气再循环）+DPF（柴油颗粒捕捉）或DOC（氧化催化转化）；二是优化燃烧+SCR（选择催化还原）。SCR技术具有对硫不敏感、油耗低、技术可持续性好等优点^[1]，我国普遍采用的是SCR技术。为了及时发现SCR系统存在的故障并提醒驾驶员，根据国家法规HJ437中规定，满足国IV阶段排放要求的车辆必须配备OBD（车载诊断）系统，所以对OBD系统的研究具有实际应用价值。

1 OBD诊断策略制定

汽车正常运行时，ECU的输入、输出信号的电压值都有一定的变化范围。当某一信号超出了这一范围，并且这一现象在一段时间内不会消失时，ECU便判断为这一部分出现故障^[2]。本文设计的OBD模块主要监测对象有传感器、执行器、CAN通讯及NOX排放监测等。

1.1 传感器的诊断策略

传感器包括尿素箱温度及液位传感器、添蓝计量泵蓄压腔和混合腔压力传感器、催化器前后温度传感器、NOX传感器。

当尿素箱内的温度低于-11 ℃，需对尿素进行加热化冰处理。在OBD诊断过程中，若循环监测传感器输出的电压信号超出标定的上限值，报告温度传感器对电源短路故障；反之，报告对地短路故障。若两次输出的电压信号差值大于标定值时，认为温度传感器存在信号不可信故障。

液位传感器与温度传感器的诊断策略相似，不同之处在于若液位传感器两次输出的电压信号相等时，报告液位传感器存在停滞故障。同时液位传感器在OBD诊断过程中还要监测尿素存量，当液位低于10%时，点亮MIL（故障指示灯），发出尿素存量不足警告。

压力传感器用于监测蓄压腔和混合腔内的压力变化。催化器前后温度传感器用来测定催化器前后两端温度，确保催化器的反应始终保持在合适的温度范围内。其诊断策略跟尿素温度传感器类似，不再赘述。

NO_X传感器同样安装在催化器前后，主要用来测定排放的NO_X浓度是否超过排放限值，也可以作为催化器是否老化，是否需要拆除的依据。本文所使用的NOX传感器带有自诊断的功能, NO_X传感器的故障都是通过CAN总线传来的报文信息来辨别的。OBD系统对NOX传感器的信号不合理故障的检测贯穿于整个加热过程中。在NO_X传感器自检并确定无故障后,DCU便发送对NOX传感器加热的指令。在加热的过程中，若没有收到温度信号但是已经超过了加热的最大时间限值，则报告NOX传感器加热信号不合理故障。

1.2 执行器的诊断策略

执行器包括尿素喷射阀和冷却液加热控制阀。

SCR系统在进行初始化后，计量泵进行建压，若一段时间后检测的压力仍达不到标定值，需重复建压，当重建次数超过最大标定值，压力仍达不到，则报告尿素喷射阀有常开故障。若压力正常建立后，则喷射阀的占空比为标定值，若一段时间后监测到压力值高于标定值，则报告喷射阀有常闭故障。

化冰处理加热至7℃停止，加热过程中，若在标定时间内检测温度仍低于下限温度，则报告冷却水加热控制阀有常开故障；若加热一段时间后温度持续高于上限温度，则报告冷却水加热控制阀有常闭故障。

1.3 CAN通讯诊断及NOX排放监测诊断策略

OBD模块实时检测CAN总线通讯故障，若发生故障，则由CAN总线的硬件报出。OBD模块还会周期性地检测EEC1（发动机电控信息1）和AMB（环境状态）等相关的CAN总线信息，一旦检测到错误，系统就会自动报错。

OBD法规要求，与排放控制有关的发动机系统异常运转应通过对NOX排放水平进行监测来确定。根据要求，NOX排放控制的限值分别为5.0 g/kwh和7.0 g/kwh。当NOX排放量超过5.0 g/kwh时，激活MIL；当NOX排放量超过7.0 g/kwh时，扭矩限制器起作用。

2 OBD模块的整体设计

本文开发的OBD模块是基于飞思卡尔MC9S12XET256单片机开发平台^[3]，编程软件采用的是Code Warrior IDE软件。所设计的OBD模块是嵌入到SCR电控单元（DCU）中的，其与发动机控制单元（ECU）上的OBD模块分别控制各自的故障诊断。DCU将诊断的结果通过CAN总线广播到网络里，ECU根据接收到的故障情况和发动机实际运行状况综合判断，来控制MIL或者扭矩限制器的激活与否[4]。OBD总体方案设计如图1所示。

OBD模块在SCR系统中完成的主要功能有信息采集、信息转换、故障诊断、故障码存储及故障码传送。OBD模块的基本框架如图2所示。

图2 OBD模块的基本框架图

3 基于CAN总线OBD模块程序设计

根据J1939协议的规定，CAN报文信息主要在数据帧中，OBD监测到系统出现故障要及时向CAN总线发送当前故障信息，以通知总线上其他节点，故障信息都包含在DM1（当前故障诊断代码）中^[5]。DM1包含的故障诊断信息仅仅是当前情况下处于激活状态并且可以改变故障指示灯状态的故障代码，所以DM1被传输的前提就是要有DTC（故障诊断码）成为激活的故障码。每个DM1的更新周期为1 s，如果故障激活的时间大于1 s，然后又变为不激活状态，则应传输DM1消息来反应这种状态的改变，DM1的SPN为0xFECA。

DTC由四部分组成：SPN，可疑参数编号，是用以识别特定的元素组件或与ECU相关的参数；FMI，故障模式标志，定义了为SPN所识别的子系统中发现的故障类型；OC，发生次数，包括了一个故障从先前激活状态到激活状态的变化次数，最大值为126；CM，SPN的转化方式，一般来说，CM=0。

本文针对监测对象定义了以下故障信息，如表1所示，现举例说明DM1的组成。假设一个尿素箱温度传感器发生对地短路故障，在表1中可以看出SPN=3031，FMI=4；此时假设故障发生了一次，则OC=1，CM=0，点亮故障指示灯为0x40，则根据表2可得DTC=0xD70B0401，DM1报文内容则为0x4000D70B0401FFFF。

若需发送的故障信息小于8 B，则DM1在一帧CAN数据中传送时采用单包模式，更新周期为1 s，若需要发送包含两个以上故障的当前故障信息时，单帧CAN报文就不足以容纳全部的信息了，此时需要采用多包发送模式。

当使用多包模式发送DM1时，就不能像单帧DM1那样发送，而需要遵循J1939协议^[6]。按照规定的传输协议进行发送，发送分为两个步骤：

(1)发送一条连接管理消息（PGN=0xEC00），公告要发送一条广播消息（BAM），目标地址为全局目标地址，作为一个长消息预告发送给网络上的节点。BAM消息包含了即将广播的长消息的参数组编号、消息大小和它被拆装的数据包的数目，具体格式如表2所示。

(2)将数据拆分打包，并通过数条数据传送消息(PGN=0xEB00)发送，发送周期为50 ms。每一数据包的第一字节内容为数据包序列号和灯的状态信息，所有的DTC依次排列在后续的字节当中。当最后一个数据包不足8 B数据时，没使用的字节均以0xFF填充，多包DM1中DTC解析方法与单包DM1一致。

4 CANoe-MATLAB/Simulink联合仿真验证

为了验证所开发的OBD模块是否满足要求并完善OBD模块的程序设计，必须进行试验验证。而一般的试验验证不可能人为地制造出所有的故障，因为有些传感器是集成在计量泵内部的，如果加以破坏，势必影响计量泵本身的性能，而且增加了试验成本。针对这种情况，本文设计了基于CANoe-MATLAB/Simulink联合仿真验证^[7]，充分结合了CANoe中的总线仿真优势和MATLAB/Simulink构建复杂功能模型的优势。

4.1 仿真模型建立

利用CANoe建立总线网络，并在总线网络上建立相关的节点。为了配合所设计的OBD模块仿真，本文建立了EMS(发动机控制单元)、UDS(计量泵单元)、DCU(SCR电子控制单元)、Control Panel(监控面板)4个节点，如图3所示。

建立完网络节点后，利用CANdb++进行整个系统数据库的建立，包括信号、环境变量、报文的建立等并关联。然后利用PanelEditor对控制面板进行设计，并和刚刚创建的数据库进行关联。创建的OBD控制面板如图4所示。之后用CAPL语言对节点和测试环境进行编程设计，用来控制节点动作。最后根据仿真需要修改系统参数。

4.2 OBD仿真分析

故障分单个故障和多个故障，基于CANoe的Diagnostic和DTC Monitor工具跟踪和观察了发生单个和多个故障时的情形。图5为单个故障发生的仿真过程。单击OBD控制面板上温度传感器短路后的OK键，单个故障发生，从DTC Monitor上可以看出UDS节点上出现了红点闪烁，UDS节点向CAN总线发送单包故障信息DM1(PGN=0xFECA)，通知其他节点发生故障的节点及类型。下面列出出现错误的节点为UDS：SPN=0x7F5FD、OC=1、FMI为“Voltage below normal（电压低于正常值）”故障。此时，车上的OBD系统监测到有故障发生，点亮MIL。

图6为多个故障的仿真过程，依次点击OBD控制面板上液位传感器开路和催化器后温度后的OK键，同时产生两个故障，DCU和UDS节点同时出现红点闪烁。两个节点向CAN总线发送多包故障信息，首先发送一条连接管理消息(PGN=0xEC00)，公告要发送一条广播消息(BAM)，预告其他的节点。然后将数据拆分打包，分多条消息进行传送（PGN=0xEB00）。然后通知其他节点发生故障的节点及类型，车上的OBD系统监测到故障，点亮MIL。

由以上的仿真过程可以看出，该模型很好地模拟了OBD的诊断过程，从而说明了制定的OBD诊断策略及设计的程序的正确性，可以对SCR系统中所出现的故障进行诊断并能及时地把诊断的结果通过CAN总线发给DCU，控制点亮MIL。该仿真结果对程序设计的完善也具有指导意义。

对OBD模块制定了诊断策略并进行了总体的设计，基于飞思卡尔MC9S12XET256单片机对OBD进行了程序设计，为了验证制定的诊断策略及程序设计的合理性，基于Simulink建立了OBD仿真模型，对SCR系统中OBD的工作过程进行了联合仿真，结果表明建立的模型可以模拟OBD诊断过程，验证了制定的OBD诊断策略及程序设计的正确性，并根据仿真结果完善了程序设计。

参考文献

[1] SITSHEBO S，TSOLAKIS A，THEINNOI K.Promoting hydrocarbon-SCR of NOx in diesel engine exhaust by hydrogen and fuel reforming[J].International Journal of Hydrogen Energy，2009，34(18)：7842-7850.

[2] 戴耀辉，于建国．汽车检测与故障诊断[M]．北京：机械工业出版社，2007.

[3] MC9S12XET256开发平台实验指导手册[EB/OL](2011-10)[2014-05].http：//fxfreefly.taobao.com.

[4] 张伟，徐正飞，邓成林，等.柴油机SCR系统OBD功能的诊断策略研究[J].汽车工程，2011，33(1)：23-25.

[5] 代妮娜，蔡黎，邱刚，等.一种新型汽车OBD信息无线发射机设计[J].电子技术应用，2012，38(11)：97-99.

[6] SAE J1939/73，SAE J1939 protocol part 7-3：application layer-diagnostics[S].2006，9.

[7] 李顶根，曹晶，张杰.基于CANoe_Matlab的车辆CAN总线的联合仿真[J].计算机原理，2009(11)：57-61.