基于CDMA和CAN总线的车辆远程故障诊断系统

　　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等问题。