DIY编程器网

 找回密码
 注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 1158|回复: 0
打印 上一主题 下一主题

[待整理] 基于CDMA/CAN的车辆故障远程监控系统

[复制链接]
跳转到指定楼层
楼主
发表于 2015-4-27 22:52:24 | 只看该作者 |只看大图 回帖奖励 |倒序浏览 |阅读模式
1 引言
          在美国制造和销售的所有的小汽车和轻型卡车从1996年1月1号起都必须装备有车载 自动诊断系统(OBD-II)。然而OBD-II主要用于排放系统的诊断,车辆的其他各个子系统能被OBD-II诊断的比较少。虽然这些诊断码对诊断部分 故障是很有用的,但是这些信息还不足以有效的区分特定的故障部位。通过接入OBD-II接口的扫描工具能获得故障码,但是各个生产厂商提供的手持式扫描工 具与OBD-II通信的标准并不统一,欧洲和大部分亚洲国家使用ISO9141标准与OBD-II通信,而通用汽车的小汽车和轻型卡车则使用sae j1850 vpwm标准,福特公司采用sae j1850pwm标准。
           
          这样就导致传统的汽车故障诊断有如下缺点:在不同汽车制造商之 间诊断技术没有形成标准,无疑这会导致车辆的诊断成本大幅增加;故障诊断需要驾驶车辆到特定的修理地点,这导致驾驶者的不方便,也不可能经常的进行定期的 诊断和维护;一次全面地诊断需要特定的设备和熟练的技术员,这会使诊断的成本很高;故障码提供的信息通常是不足够精确来指出故障的来源;随着汽车电子控制 系统变得越来越复杂,诊断各部分的故障也越来越困难。
           
          汽车上各种电子控制单元的数目不断增加,连接导线显著增加,因而提高控制单元间通 讯可靠性和降低导线成本已成为迫切需要解决的问题。为此以研发和生产汽车电子产品著称的德国Bosch公司开发了CAN总线协议,并使其成为国际标准 (ISO11898)。CAN协议的一个最大特点是废除了传统的站地址编码,而代之以对通信数据块编码,采用这种方法可使网络内节点个数在理论上不受限 制,还可使不同的节点同时收到相同的数据。
           
          随着远程通讯、总线技术、基于模型的诊断、电子和嵌入式技术的进步,车辆的故障诊断和监控技术得到很大发展,使得能够在车辆行驶的过程中实现远程诊断和监控。这些技术的具备和车主们越来越大的兴趣使得汽车界也投入了越来越多的精力来实现远程诊断和监控。
           
          2 系统结构设计
           
          2.1 系统原理
          车辆的远程故障诊断是一个多学科的复杂系统,包含车载故障诊断单元,远程车辆信息技术服务中心和无线通讯网络系统。近来出现了许多相关的专利和文章。
           
          图1是车辆的远程故障诊断系统的工作原理图,车载故障诊断单元和服务中心通过无线通讯来实现远程诊断:远程服务中心通过无线网络获得车载故障诊断单元发 送的状态信息,然后通过分析车辆的运行参数和故障码,远程信息技术服务中心通知车主故障的严重程度,并提供必要的支持服务,并安排必要的保养或者建议修理 来解决出现的故障。
           
         
           
          2.2 功能设计
            (1) 车辆能智能化的向远程服务中心提供故障码,关键传感器的值和其他相关运行参数,并具备获取下载或者系统软件升级的能力。
            (2) 车辆和远程服务中心均具备适当人机接口的先进实时诊断和监控模块。
            (3) 车辆的远程故障诊断服务中心具有权威的专家负责复杂的诊断和监控并与驾驶者交流。
            (4) 保证远程故障诊断服务中心和相应车辆的数据通讯以及与驾驶者通话的无线网络。
           
          从系统原理图(图1)分析可以得出:被诊断的车辆通过无线网络与车辆信息技术服务中心(telematics service providers,tsp)保持通信。车辆信息技术服务中心不但可以像传统ISP一样提供Internet服务,还可以提供安全,GPS,客户关系管理 等服务。而且,车辆信息技术服务中心还能够提供专业的故障诊断专家来为车主提供诊断服务。诊断专家通过从车载电子系统传来的故障码实时分析车辆的故障程 度。车主也可以通过移动电脑无线上网或者移动电话通过wap来浏览车辆信息技术服务中心提供的更加具体的故障码说明,以及其他导航服务。同时我们的车辆信 息技术服务中心还要掌握有以下资源,如车辆制造商数据中心,道路拯救车辆以及车辆修理,保养店面等。
           
          3 软件设计
          该系统的软件设计主要分为两部分:位于车辆信息技术服务中心的专家系统设计和位于车辆的车载故障诊断单元设计。
           
          3.1 专家系统设计
          这部分是位于车辆信息技术服务中心的应用程序,除了普通的web服务,GPS服务,跟踪服务等以外,最主要的是能提供故障的专家诊断。这部分功能由专家系统辅助以现场专家来完成。通过专家系统来尽可能快地给车主反馈故障诊断的信息,并提出解决的专家建议。
           
          开发专家系统,首先需要将汽车维修领域专家的大量实际维修经验进行汇总和提炼,编成知识库,构成专家系统的核心部分;然后建立推理机,推理机可根据车载 故障诊断单元发送过来的数据,利用知识库中的知识,按一定策略进行推理,从而得出诊断结果。专家系统的结构如图2所示:
           
         
           
          知识库的建立直接关系到车辆信息技术服务中心服务质量的高低,也影响着车主是否大量采用这个系统,所以收集,整理专家知识的工作特别重要,其难点主要在 于专家知识的收集与表述。因为现在的汽车制造厂商十分繁多,具体的车系更多。虽然现在大部分车辆都提供OBD-II接口,但是从接口中读出的故障码的信息 十分有限;各大汽车生产厂商检测故障用的手持设备与OBD-II通信的协议也各不一致,而且得到的故障码包含的信息大量的是靠维修工人的经验来判读。所以 专家知识的积累与整理显得十分重要。
           
          在归纳知识时要考虑的因素很多, 为了充分利用专家系统的符号推理能力, 凡是能用数学公式描述的知识, 均作为具体求解器的方法实现,其余的作为规则存储于知识库。
           
          规则知识的表示形式为:
           
          规则号 if (前提) then (结论)
           
          前提是一个条件或几个条件的“and”形式,若是后一种情况,只有在几个条件都成立时,结论才被接受。每个条件可以是若干项的“or”形式。
           
          以下是一条具体的规则:
            rule5:
            if
            (1) 收到故障码:p0201
            (2) 收到故障码:p0202
            (3) 收到故障码:p0203
            (4) 收到故障码:p0204
            (5) 发动机缸数:8
            then
            发动机喷油嘴故障严重,需马上修理。
           
          推理机设计时本系统采用了两级es推理控制策略。结合领域知识,将总体故障分析求解任务分解为不同的子任务,如发动机故障分析子任务、轮胎故障诊断子任 务等。每个子任务有各自的目标求解变量,服从不同的求解方法,彼此之间既相互独立又存在着相互联系。通过正向推理求解其目标变量,并将所求结果显示给车主。
        而汽车故障诊断的各子任务间是有一定的依赖关系的,各子任务的求解是有一定的前提条件的,例如,气缸喷油嘴子任务的求解必须在油嘴线路电压已知 的前提下才能进行,因而,各求解器中都设置了激活条件,只有满足了这些条件,求解器才能被激活从而进行目标变量的求解。元级推理机利用此关联对象集信息按 一定的顺序激活相关的求解器进行重新推理。
           
          解释机制通过与推理机输出的数据, 回答用户提出的how、why、what、whether等问题。
           
          3.2 车载故障诊断单元软件设计
          车载故障诊断单元主要负责车载故障数据的读取,并通过无线网络()将故障码实时送到远程车辆信息技术服务中心,简单的故障信息,如:一般故障 (不用马上处理),故障(需马上修理),严重故障(需请求交通拯救)需要及时反馈给车主(包括以文字的方式反馈到车主车载屏上,更紧急的时候通过语音或者 视频对话来沟通)。更详细的故障情况车主可以通过移动电脑或者移动电话访问相关远程车辆信息技术服务中心的网站来获取。
           
          车载故障诊断单 元的主程序在执行完初始化功能,再根据当前故障状态位的值设置定时中断的时间后,然后就进入低功耗模式。单元读取故障码和其他运行数据,以及这些数据的传 输都放置在中断程序,中断结束立即进入低功耗模式。车辆故障状态位正常时,可取60min定时中断一次,调用crc-16校验计算执行库后,通过无线方式 发送给远程车辆信息技术服务中心。在故障状态位出现多位数值为“1”时,缩短定时中断时间,增加数据采样及发送频率。定时中断程序流程如图3所示:
           
         
           
          数据接收程序在主程序完成初始化功能后,模块进入等待SPI数据工作状态。在接收到一个数据帧,crc校验(采用查表法实现,减小微控制器cpu占用时 间)和车辆信息技术服务中心id判断无误后,送液晶显示并点亮相应的指示灯以表示各模块工作正常。当某个模块出现故障时,启动led闪烁警告或蜂鸣器报 警。程序流程图如图4所示。
           
         
           
          4 硬件设计
           
          4.1 车载故障诊断单元
          车载故障诊断单元主要由无线模块(模块),微控制器(PIC16F874),CAN收发器(MCP2551),CAN控制器(MCP2510)组成,硬件结构如图5所示。车载通信协议统一采用CAN总线。
         
           
          Microchip公司的单片机PIC16F874采用risc指令系统,哈佛总线结构,低功耗,高速度。内部集成了ADC、串行外围接口 (SPI)和Flash程序存储器等,具有pwm输出、lcd驱动等功能。PIC16F874通过SPI接口可以实现与CAN控制器MCP2510的无缝 连接。PIC16F874的I/O资源丰富,共有五个I/O口,每个I/O口除了基本用途外还有一些特殊功能。
           
          CAN通信模块由CAN 控制器MCP2510和CAN收发器MCP2551组成。MCP2510可以完成CAN总线的物理层和数据链路层的所有功能,支持高速SPI接口(最高数 据传输速率可以达到5mb/s),支持CAN2.0a/CAN2.0b协议。CAN收发器MCP2551是CAN控制器与物理总线之间的接口,对物理总线 提供差动发送能力,对CAN控制器提供差动接收能力,同时它可以增大通信距离,提高CAN的抗干扰能力。
           
          考虑到与现有OBD-II接口兼容,我们利用微控制器的串口来完成和OBD-II接口的通信。
           
          4.2 车辆信息技术服务中心
          车辆信息技术服务中心的硬件设计符合现有标准即可,主要包括服务器的设计,网络的设计,这部分的硬件设计限于篇幅不再详细论述。
           
          5 结束语
          本文首先分析了车辆远程故障诊断的现状,指出了传统车辆故障诊断的缺点。在基于现有的无线通信网技术的基础上,首先在国内提出了基于的车辆信息 技术服务概念,包括了车辆故障智能诊断在内,将服务概念延伸到GPS城市导航,车辆跟踪等各个方面。然后,利用PIC16F874设计了基于CAN总线的 一种车辆远程故障诊断系统。该系统设计新颖,具备很好的应用前景,有关提供车辆信息技术服务(tsp)的网站也在筹建中。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友 微信微信
收藏收藏 分享分享 支持支持 反对反对
您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|文字版|手机版|DIY编程器网 ( 桂ICP备14005565号-1 )

GMT+8, 2024-11-16 19:57 , 耗时 0.114849 秒, 21 个查询请求 , Gzip 开启.

各位嘉宾言论仅代表个人观点,非属DIY编程器网立场。

桂公网安备 45031202000115号

DIY编程器群(超员):41210778 DIY编程器

DIY编程器群1(满员):3044634 DIY编程器1

diy编程器群2:551025008 diy编程器群2

QQ:28000622;Email:libyoufer@sina.com

本站由桂林市临桂区技兴电子商务经营部独家赞助。旨在技术交流,请自觉遵守国家法律法规,一旦发现将做封号删号处理。

快速回复 返回顶部 返回列表