基于SCR控制器的国_柴油机OBD系统设计
- 格式:pdf
- 大小:479.53 KB
- 文档页数:6
收稿日期:2009211230;修回日期:2010201220作者简介:蔡永祥(1982)),男,硕士,研究方向为柴油机检测诊断与电子控制;cyx _wh ut2008@ 。
基于SCR 控制器的国Ô柴油机OBD 系统设计蔡永祥,金华标,喻方平(武汉理工大学能源与动力工程学院,湖北武汉 430063)摘要:在SCR 控制器硬件基础上进行了国Ô柴油机OBD 系统设计,介绍了基于SAE J1939与ISO 15765协议的通信功能实现,设计了针对NO x 排放控制系统与发动机燃油系统的故障监测、诊断和报警,对发动机端DM1代码进行了解析并遵循ISO 15031)6规定重新组装发送,还对OBD 系统中未定义的故障代码(DT C)进行了自定义。
目前已完成玉柴YC6L 系列单体泵国Ô柴油机匹配标定,并已通过中国汽车技术中心OBD 功能认证。
关键词:柴油机;选择性催化还原;车载诊断系统;故障代码中图分类号:U472.9 文献标志码:B 文章编号:100122222(2010)0120005206GB 17691)2005规定国Ô阶段开始增加车载诊断(OBD)系统,并且国Ô型式核准执行日期之后一年起凡不满足本标准要求的新车及新发动机不得销售和投入使用。
因此,随着国Ô核准执行日期的临近,OBD 系统在国内的应用提上了日程。
OBD 系统对发动机及排气后处理系统进行在线监测和诊断,排放超限时OBD 系统能诊断出特定的故障并设置故障代码、存储冻结帧,依据法规要求激活故障指示器或扭矩限制器[1],并能通过标准诊断仪读取存储的故障代码及冻结帧数据。
OBD 系统硬件包括为了实现检测、诊断功能必须配置的传感器和执行器;软件包括系统模块间的通信协议解析、故障诊断策略及标定接口代码。
实现OBD 功能可以有两种方案:一是,将OBD 功能嵌入发动机电控单元(EECU );二是,将OBD 功能嵌入排气后处理单元SCR 控制器。
车用柴油机SCR喷射系统的设计及研究车用柴油机SCR喷射系统是一种通过尿素水溶液喷射来实现经济性和环保性的技术,可以大幅度降低氮氧化物(NOx)的排放量。
本文将介绍车用柴油机SCR喷射系统的设计及研究。
首先,该系统由SCR催化剂、尿素水溶液喷嘴、尿素水溶液储存罐及电控系统组成。
其中,SCR催化剂位于尾气处理系统的后段,主要作用是将NOx与尿素水溶液在恰当的温度下催化还原为无害的氮气和水蒸气。
其次,尿素水溶液喷嘴安装在SCR催化剂的前沿,由电控系统控制喷嘴的喷射时间和量。
这样,当发动机运行时,在SCR催化剂中形成了一定量的NOx后,系统便能够根据车辆的运行状态和路况实时供应适量的尿素水溶液,使其在SCR催化剂上与NOx发生反应。
最后,尿素水溶液储存罐是尿素水溶液的存储和供应装置,储存罐的大小和容量因车型和制造商而异。
电控系统则可以自动检测尿素水溶液的容量和质量,为车主提供及时的提醒。
该系统的研究包括喷嘴设计、尿素水溶液的热稳定性、尿素水溶液对系统组件的腐蚀性以及系统对发动机性能的影响等方面。
为了实现技术上的进步和推广应用,需要解决系统的稳定性和可靠性问题,并提高系统的制造工艺和设计水平。
综上所述,车用柴油机SCR喷射系统是一项十分有用的技术,其能够在不影响发动机性能的情况下大幅度降低氮氧化物的排放量。
未来,我们可以通过更加精细的设计和更高的制造水平来不断推进该技术的发展,为更加环保的出行提供更好的保障。
在车用柴油机SCR喷射系统的研究和设计中,喷嘴的设计显得尤为重要。
合适的喷嘴能够确保尿素水溶液均匀地分散到催化剂表面,从而保证反应的充分进行。
此外,喷嘴的尺寸和形状也会直接影响到喷射效率和稳定性,因此在设计时需要进行全方位的考虑和测试。
尿素水溶液的热稳定性也是研究的重点,因为该溶液需要在高温下被喷射出来。
在气候闷热或者高海拔环境下,高温会导致溶液分解,产生悬浮在空气中的尿素晶体。
这种情况不仅会降低喷射效率,还会对发动机的性能产生负面影响。
第8 3 2018 8 月机械设计与制造Machinery Design&Manufacture181柴油机SCR控制单元检测系统模块化设计李捷辉,段畅,周大伟(江苏大学汽车与交通工程学院,江苏镇江212013)摘要:针对柴油机S C R控制单元提出一种硬件电路的检测策略,结合模块化设计理念,开发出一套柴油机S C R控制单 元检测系统。
在CodeWarrior环境下进行测试程序的编写;运用LabVIEW图形化的语言特点,设计检测系统上位机检测 界面;通过信号发生器、电压显示仪表、稳压电源、步进电机、数据采集卡、USBCAN调试器等设备搭建硬件测试平台,并 完成检测系统试验验证。
结果表明:检测系统可准确地反应出控制单元元器件的优劣、线路连接的可靠性以及控制单元 各功能实现的完好性,该检测系统操作方便、工作可靠、检测效率高。
关键词%SCR;电控单元;LabV旧W;检测系统中图分类号:文献标识码:,文章编号:1001-3997(2018)08-0181-03Modular Design of the Detection System of SCRElectronic Control Unit for Diesel EngineLI Jie-hui,DUAN Chang,ZHOU Da-wei(School of Automotive and Traffic Engineering,Jiangsu University,Jiangsu Zhenjiang212013,China)Ahstr&ct'Propose a hardware c irc u it de tection m ethod against the e le ctro n ic co n tro l u n it o f SC&system f o r d iese l engine.D evelop a d iese l engine SCR e le ctro n ic c o n tro l u n it de tection system co m b in e d w ith the m o d u la r design concept.U sing CodeWarrior to w rite the test pro g ra m a cco rd in g to the d e te ctio n m ethod.U sing LabVIEW cha racte rized w ith graphic language to com plete PC m o n ito rin g interface design.U sing sig n a l g e n e ra to r,voltage in d ic a to r,p o w e r s u p p ly,stepper m o to r,data a c q u is itio n c a rd and USBCAN debugger to b u ild the hardware test-be d and v e rify the de tection system.The results show that the de tection system can a ccu ra te ly re fle ct the m erits o f the co n tro l u n it co m p o n e n ts,the r e lia b ility o f wires co n nection and the in te g rity o f the c o n tro l f u n c tio n s.The de tection system ca n w ork re lia b ly and operate e a s ily an d the test m ethod can g re a tly im prove the de tection e ffic ie n c y.Key Words:SCR;Electronic ControlUnit;LabVIEW;DetectionSysteml引言随着排放法规的日益严格,柴油车排放污染成为社会关注 的热点,车用柴油机排放控制面临前所未有的 w柴油机厂科研院校 研究工,研究 M,SCR(Selec-tive Catalyst Reduction,选择性催化还原)技术是目前实现国!及 以上排放法规的最有 柴油机SCR,控制单元(Dosing Control Unit,以下简称DCU)作为系统的控制核 ,通 发动机 排 工控制 工,排 的IO k专D CU的输人输出通道多、性能要高,动、油污等原弓I,DCU性 SCR 减排 DCU前 为重要,电路检测的 ,手工目前 SCR的研究 控制 法 的设计上M,DCU关注少,D CU的检产品投人市场前必不可少的一个环节。
收稿日期:2009211230;修回日期:2010201220作者简介:蔡永祥(1982—),男,硕士,研究方向为柴油机检测诊断与电子控制;cyx_whut2008@ 。
基于SCR 控制器的国Ⅳ柴油机OBD 系统设计蔡永祥,金华标,喻方平(武汉理工大学能源与动力工程学院,湖北武汉 430063) 摘要:在SCR 控制器硬件基础上进行了国Ⅳ柴油机OBD 系统设计,介绍了基于SA E J 1939与ISO 15765协议的通信功能实现,设计了针对NO x 排放控制系统与发动机燃油系统的故障监测、诊断和报警,对发动机端DM1代码进行了解析并遵循ISO 15031—6规定重新组装发送,还对OBD 系统中未定义的故障代码(D TC )进行了自定义。
目前已完成玉柴YC6L 系列单体泵国Ⅳ柴油机匹配标定,并已通过中国汽车技术中心OBD 功能认证。
关键词:柴油机;选择性催化还原;车载诊断系统;故障代码中图分类号:U472.9 文献标志码:B 文章编号:100122222(2010)0120005206 G B 17691—2005规定国Ⅳ阶段开始增加车载诊断(OBD )系统,并且国Ⅳ型式核准执行日期之后一年起凡不满足本标准要求的新车及新发动机不得销售和投入使用。
因此,随着国Ⅳ核准执行日期的临近,OBD 系统在国内的应用提上了日程。
OBD 系统对发动机及排气后处理系统进行在线监测和诊断,排放超限时OBD 系统能诊断出特定的故障并设置故障代码、存储冻结帧,依据法规要求激活故障指示器或扭矩限制器[1],并能通过标准诊断仪读取存储的故障代码及冻结帧数据。
OBD 系统硬件包括为了实现检测、诊断功能必须配置的传感器和执行器;软件包括系统模块间的通信协议解析、故障诊断策略及标定接口代码。
实现OBD 功能可以有两种方案:一是,将OBD 功能嵌入发动机电控单元(EECU );二是,将OBD 功能嵌入排气后处理单元SCR 控制器。
本研究采用第二种方案。
1 硬件组成SCR 控制器硬件系统主要包含电源模块、微处理器模块、信号输入调理模块、输出驱动模块、数据存储模块[2],如图1虚线部分所示。
为了实现OBD 功能,需要在原有SCR 控制器基础上扩展实时时钟电路、故障指示器驱动电路、扭矩限制器控制电路。
故障指示器驱动电路和扭矩限制器控制电路利用SCR 控制器输出端口进行扩展;实时时钟电路利用SCR 控制器GIO 端口模拟I 2C 接口进行扩展。
图1 系统硬件组成2 软件组成在SCR 控制器硬件基础上要满足HJ 437—2008及G B 17691—2005要求,软件部分至少应具有与标准诊断仪连接交互、尾气NO x 浓度控制、故障诊断和故障处理等功能。
本研究所设计的OBD 系统软件部分主要包括初始化模块、通信模块、传感器采集模块、故障诊断模块、故障处理模块(见图2)。
第1期(总第186期)2010年2月车 用 发 动 机V EHICL E EN GIN E No.1(Serial No.186)Feb.2010图2 系统软件框图2.1 通信功能OBD 系统通信功能包括三部分:一是,符合SA E J 1939协议的数据采集模块与发动机电控单元、格兰副定量供给泵及NO x 传感器的数据通信;二是,符合SA E J 1939协议的数据标定模块与标定平台的握手标定;三是,符合ISO 15765协议的软件接口与标准诊断仪连接交互。
2.1.1 基于SA E J 1939协议的通信功能实现SA E J 1939协议是以CAN2.0为核心,可在多个ECU 之间高速通信的网络协议。
它遵循7层开放系统互连(OSI )网络结构,对其中的物理层、数据链路层、网络层和应用层进行了定义并用不同文件来描述,在应用层增加了故障诊断定义。
协议物理层实现网络中电控单元的电器连接,对传输介质、电气特性、兼容性、总线错误及传输速率进行了描述;数据链路层规定发送的CAN 数据帧具有必需的同步控制、顺序控制、错误控制和流控制,采用协议数据单元(PDU )传送信息,每个PDU 由29位标志符和0~8个字节的数据组成,相当于CAN 协议中的一帧,J 1939PDU 组成见图3;网络层定义了网络互联ECU 的需求和服务,负责不同SA E J 1939网络段之间的互联;应用层详述了用于SA E J 1939网络的每个参数和参数组,包括其数据长度、数据类型、分辨率、范围及参考标签,并为每个参数和参数组分配了可疑参数编号(SPN )和参数组编号(P GN )。
SA E J 1939应用层定义了用于诊断服务的诊断报文(DM )及诊断故障代码,诊断报文见表1。
图3 J1939PDU 组成表1 诊断报文种类DM 作用DM 作用DM1当前D TC DM12排放相关的当前D TC DM2历史D TC DM13停止/开始广播DM3历史D TC 清除/复位DM14存储器访问请求DM4冻结帧参数DM15存储器访问响应DM5诊断准备就绪DM16二进制数据传输DM6连续监测系统测试结果DM17引导装载数据DM7命令非连续监测进行测试DM18数据安全DM8非连续监测系统测试结果DM19标定信息DM9氧传感器测试结果DM20监测工作比率DM10非连续监测系统测试标志符支持DM21MI 激活时的行程距离DM11当前D TC 清除/复位2.1.2 基于ISO 15765协议的通信功能实现ISO 15765针对基于CAN 的汽车故障诊断系统一般诊断要求而制定。
依据OSI 7层参考模型将通信系统分为4层(见图4)。
图4 ISO 15765通信系统模型 ISO 15765通信模型中,应用层依据ISO 14229—1和ISO 15031—5而定义,并兼容了汽车厂商规范中定义的诊断服务,具有检测、监控、诊断管理等功能;网络层主要为应用层提供服务及实现不同结点网络层间的数据通信(如外部诊断设备与・6・ 车 用 发 动 机 2010年第1期ECU之间),为数据通信提供分段、传送流控制帧和重组等处理方法。
ISO 15765针对服务数据量不同定义了单帧和多帧两种数据传送模式。
上层诊断服务请求的数据可在一帧数据中传送时采用单帧传送模式。
上层诊断服务请求的数据无法使用单帧模式传送时,采用多帧传送模式。
多帧传送模式中,网络层首先将诊断数据进行拆分,形成一个首帧和多个后续连续帧。
首帧是第一段数据组成的CAN帧,其中包含了分段数据总长度及后续连续帧数目;连续帧是其余分段数据组成的CAN帧,每个数据帧包含拆分的顺序编号。
接收端依据接收数据帧的编号重组服务数据[3]。
在多帧传送模式通信中,为解决通信双方数据同步问题,采用了流控制管理机制。
该机制能协调双方的通信速率,使发送端适应接收端的接收能力。
流控制帧实现通信双方的管理,对发送端有重新发送、停止发送和暂停发送3种控制操作,为避免发送实体因接收实体的某种错误而陷入永久等待状态,连续发送的等待流控制帧数目有上限要求。
接收端连续发送最大数目等待流控制帧后,仍然无法继续接收数据时,将中止数据接收,并向上层发出缓冲区溢出的指示服务。
发送端则因未收到等待流控制帧而超时,数据发送中止,同时向上层发出等待数据帧超时的确认服务。
2.2 故障诊断系统所诊断故障信息有两种来源:一是,通过CAN总线获取,包括定量供给单元故障信息、NO x 传感器故障信息、发动机端DM1故障代码信息;二是,通过传感器采集获取,包括添蓝液位传感器采集信息、添蓝温度传感器采集信息、催化器进口温度传感器采集信息和催化器出口温度传感器采集信息。
2.2.1 NO x排放控制系统故障诊断系统所采用的定量供给单元及NO x传感器具有故障自诊断功能,可把自身诊断信息整合打包后广播发送到CAN总线上。
所以,系统直接采集CAN总线上两部件广播的故障标志位,通过标志位信息判断故障是否发生。
通过传感器采集的数据与预设标定值的比较,可以诊断此类传感器电故障(开路、短路)。
2.2.2 发动机端故障诊断发动机端当前故障信息包含在发动机电控单元发送到CAN总线上的DM1(当前D TC)代码中, DM1代码包含监测参数号(SPN)、故障类型号(FM I)、故障发生次数(OC)、可疑参数转化方式(CM)等信息。
OBD系统通过对DM1代码的解析可获得发动机端具体故障信息,并依据解析得到的SPN和FM I把符合SA E J1939格式的D TC转换成符合ISO 15031—6格式的D TC。
根据服务数据量不同,DM1代码同样定义了单帧和多帧两种数据帧传送方式。
2.2.2.1 单帧DM1信息发动机端故障信息可用一帧CAN数据传送时采用单帧模式,单帧DM1数据长度为6个字节,发送周期为1s,对应的数据解析方法见图5。
图5 单帧DM1解析方法2.2.2.2 多帧DM1信息发动机端故障信息不能用一帧CAN数据传送完毕时采用多帧模式,多帧DM1数据长度为8个字节,包含DM1控制帧与后续帧,控制帧包含当前数据发送模式(点对点或广播发送)、分段数据总长度及DM1后续帧数目。
DM1代码控制帧发送完毕后会相应地发送DM1后续帧数据,后续帧之间间隔为50ms,每一后续帧的最低位字节声明了后续帧的帧序列号,多帧DM1数据解析与单帧DM1解析方法一致。
2.3 故障代码HJ 437—2008规定故障代码的选取有两种方案:方案一,故障代码应与ISO 15031—6:2005附录B一致,如不能符合识别要求,制造企业可以在ISO 15031—6:2005允许制造商自定义区间定义;方案二,制造商可采用SA E J2012或SA E J1939—73规定最合适的故障代码来识别故障。
为了与国际标准接轨,本研究所设计OBD系统故障代码选取遵从ISO 15031—6:2005。
ISO 15031—6定义的故障代码包含ISO/ SA E定义和制造厂商自定义两部分,涉及车身、底盘、电力及网络四大系统。
ISO/SA E所定义的范围包括B0xxx,B3xxx,C0xxx,C3xxx,P0xxx,P2xxx 和U0xxx;制造厂商定义范围包括B1xxx,B2xxx, C1xxx,C2xxx,P1xxx,U1xxx和U2xxx;ISO/SA E 与造厂商共同定义的范围包括P3xxx和U3xxx。
・7・2010年2月 蔡永祥,等:基于SCR控制器的国Ⅳ柴油机OBD系统设计 其中区间B0xxx ~B3xxx 表示车身故障,C0xxx ~C3xxx 表示底盘故障,P0xxx ~P3xxx 表示电力系统故障,U0xxx ~U3xxx 表示网络系统故障,每个故障代码由5部分组成,第1部分表示故障所属的系统类别,第2部分表示故障代码定义来源,其余3部分定义了故障的种类及故障等级[4],图6示出故障代码的结构。