基于故障树的汽车故障诊断专家系统的设计.docx

《基于故障树的汽车故障诊断专家系统的设计.docx》由会员分享，可在线阅读，更多相关《基于故障树的汽车故障诊断专家系统的设计.docx（31页珍藏版）》请在三一办公上搜索。

1、 摘 要本文介绍了汽车故障诊断专系统的基本结构及其开发的基本方法，论述了汽车故障诊断专家系统软件的开发研究的意义和设计中的难点，针对汽车故障的复杂性特点模拟经验丰富的维修专家的诊断思路及方法，利用Delphi7进行编程，建立友好的人机界面，依据计算机数据结构原理，采用故障树的数据结构和关系数据库原理完成知识表示建立完善的知识库，实现了确定性故障诊断所需的知识库和推理机。从而可使用户通过人机对话的形式方便、快速、准确地找出故障原因，大大地提高汽修行业的效益及汽车的使用寿命。关键字：汽车 故障诊断 专家系统AbstractThe paper introduces Automobile Fault

2、Diagnosis Expert System of basic structure and development of basic methods. Discusses the software of Automobile Fault Diagnosis Expert System s research meaning and the difficulty in the design. Aiming at the complexity characteristic of the fault ,simulating the way that experienced diagnosis mai

3、ntenance of expert thinking, using Delphi7, established friendly human-machine interface. According to the principle structure data of the computer , adopt the fault trees data structure and relation theories of database to accomplish the representation of knowledge, and realized the uncertainty of

4、knowledge base for fault diagnosis and reasoning machine. The user could find fault convenient, fast and accurately through the man-machine dialogue form , greatly improve the automobile industrys efficiency and the automobiles service life.Key words：automobile fault diagnosis expert system目录1 绪论- 1

5、 -1.1 汽车故障诊断技术的发展趋势- 1 -1.1.1 国外发展概况- 1 -1.1.2 国内发展概况- 1 -1.1.3 汽车故障诊断技术的发展趋势- 2 -1.2 汽车故障诊断专家系统简介- 3 -1.2.1 汽车诊断专家系统的功能与特点- 3 -1.2.2 研究汽车诊断专家系统的意义- 4 -2. delphi7.0软件简介- 5 -3. 汽车系统的故障分析- 8 -3.1 汽车故障的产生- 8 -3.2 汽车故障的特点- 9 -3.3 本章小结- 9 -4. 汽车故障诊断专家系统设计与开发- 10 -4.1 汽车故障诊断专家系统的一般结构- 10 -4.2 基于Delphi的汽车故

6、障诊断专家系统的特点- 10 -4.3 故障诊断专家系统各模块的建立- 11 -4.3.1 故障诊断模块- 11 -4.3.2 故障诊断知识库的建立- 17 -4.3.3 知识库的基本管理- 18 -4.3.4 知识库检索模块- 22 -4.3.5 推理机制- 24 -4.4 结论- 24 -5. 总结和展望- 25 -5.1 总结- 25 -5.2 展望- 25 -6. 致谢- 27 -7. 参考文献- 28 -1 绪论1.1 汽车故障诊断技术的发展趋势汽车故障诊断是在不解体（或仅卸下个别小件）的条件下，确定汽车技术状况，查明故障部位及原因的检查和分析。有效的汽车故障诊断是维护汽车最佳车况的

7、一个先决条件。随着制造业水平的提高、计算机技术在汽车上的广泛应用，车辆的安全性、可靠性和操控性能得到大大的提高，同时也使得汽车结构复杂化，增加了汽车的诊断维修保养难度，对汽车维修人员的各方面知识和维修技能提出了更高的要求。汽车故障诊断从传统的听、看、闻等经验诊断方式，发展为以集成化、智能化的诊断设备为手段，以信息技术为依托的现代汽车故障诊断技术。1.1.1 国外发展概况20世纪50年代之前，国外就研发了以故障诊断和性能调试为主的单项检测技术。早期的检测诊断设备是以机械结构为主，单机人工操作。上世纪60年代，随着机电一体化的产生，研制了单机自动化的设备，如四轮定位仪、非接触式速度计等；80年代，

8、随着计算机技术的发展和应用，实现了汽车诊断控制自动化，出现了集检测工艺、操作、数据采集、存储和打印等功能于一体的系统软件。目前，车载自诊断系统和车外诊断系统正在进一步发展。车载自诊断系统（OBD）利用安装在汽车内各个部位的传感器，自动检测系统故障，以故障代码形式显示并将故障信息存入电子控制单元ECU的RAM中，在维修车辆时，维修人员能调出故障代码，找出故障部位。1994年，美国汽车工程师协会（SAE）在第1代OBD基础上，制定了第2代在线诊断标准OBD，OBD除了对电子控制系统检测外，还对与排放有关的系统监测，更注重绿色环保问题。车外诊断系统，通过传感器采集信号，送至车外仪器，在相应诊断软件的

9、支持下，完成各种诊断。例如：发动机综合分析仪等。1.1.2 国内发展概况我国是20世纪60年代开始研究检测技术，如发动机气缸漏气量检测仪等。80年代，随着汽车工业的发展，汽车诊断技术得到了迅速发展，到90年代，相继研制了侧滑试验台、制动试验台、汽车检测站以及我国自主开发的发动机故障诊断仪、四轮定位仪等。汽车检测站综合运用现代检测技术和设备对汽车进行不解体或不完全解体条件下的性能检测诊断，实现了以汽车安全性能为主到综合性能的检测。国产车在汽车电子控制方面上也广泛应用了OBD，但根据我国目前的排放法规，OBD还没有在国产车上广泛使用。我国汽车诊断技术正在快速发展，但与国外先进水平相比，还有一定差距

10、，主要突出在以下几个方面：（1）管理水平还须进一步提高。我国已基本建立了车辆检测诊断制度，实施了“定期检测、强制维护、视情修理”的汽车维修制度，但我国各地区经济和技术水平不一致，大部分地区尚未进行汽车维修行业的电脑化管理和信息化建设，甚至还有“事后维修”现象。汽车诊断技术的滞后，与高速发展的汽车技术和迅猛增长的汽车保有量严重脱节，这是一个值得重视的问题。（2）诊断设备和仪器的国产化研发能力欠佳，而进口诊断设备价格昂贵，阻碍了我国汽车诊断技术的发展。（3）汽车维修人员的素质普遍不高。汽车的高科技化，现代检测设备本身的高性能，要求维修人员具备一定的汽车专业、机电专业理论知识，懂计算机、会英语，综合

11、职业能力强，但这种技能型专门人才紧缺。目前我国汽车保有量正在快速增加，进口车也越来越多，且车型复杂、种类繁多，因而使许多维修单位由于缺乏有关维修专家的技术指导而不能维修或难以满足维修的需要。为了提高车辆的利用率减少经济损失，开发汽车故障诊断专家系统，利用计算机这种先进的设备进行故障诊断是形势发展的需要和必然趋势。1.1.3 汽车故障诊断技术的发展趋势高科技的发展，信息化的网络，使得汽车故障诊断技术必将向着智能化、集成化方向发展。（1）基于神经网络的故障诊断专家系统神经网络具有较好的容错性，较强的自学习功能、自适应能力，大规模并行处理能力等。把神经网络应用于诊断专家系统是新一类知识表达体系，在知

12、识获取、并行推理等方面有明显的优越性，解决了传统专家系统在知识获取上的瓶颈问题，提高了诊断系统的智能水平。（2）基于网络的集成故障诊断专家系统由于汽车故障诊断实例丰富、诊断信息量大，不确定因素多，因此，探索适合汽车领域的专家系统，集成规则、案例、模糊和神经网络理论，集成推理机制，以网络为框架，以多媒体技术为载体，研究多种诊断模型融合技术必将是发展方向。集成故障诊断专家系统能自动选择合适的诊断模型，灵活处理诊断知识和应用推理方式，满足内在机理上的融合，避免诊断的冗余问题。多媒体技术集图形、音像、文本于一体，使诊断系统具有良好的人机界面和交互环境，增加了系统的可靠性，提高了诊断的效率。通过局域网、

13、因特网实现异地诊断和在线诊断，达到多个专家协同诊断、提高诊断准确性的目的，还可以对汽车诊断人员进行远程培训，在多媒体情境中，使诊断技术易懂好学，提高培训成效，保持诊断技术的先进性汽车技术的高科技性，对汽车故障诊断技术提出了很高的要求。智能化、集成化的现代汽车故障诊断技术必将成为汽车检测维修领域的发展方向。1.2 汽车故障诊断专家系统简介汽车故障诊断专家系统是一种能模拟维修专家的诊断思路进行故障诊断的计算机智能软件程序。研制专家系统的目的，就是要使计算机在特定领域中起到该领域人类专家应起的作用，设计专家系统的基本思想是使计算机的工作过程竭尽全力地来模拟人类专家解决实际问题的工作过程，也就是模拟人

14、类专家如何运用他的知识与经验来解决所要解决的问题的方法与步骤。本系统可利用计算机强大的信息处理能力，广泛收集各种车型的技术参数、故障征兆和判断处理程序及维修专家的经验，应用数据库及编程技术，依据汽车故障树建立动态知识库和推理库，利用强大数据库，在计算机提示下，完成诊断和修理工作，友好的人机交互操作界面及多媒体技术，将使诊断维修更为形象、直观。汽车故障诊断专家系统（FDES）是根据对症状的观察与分析，推断故障所在，并给出排除故障方案的系统。其实也可以把它定义为一个在某领域内，具有专家级水平的知识处理程序系统。在结构上它由一个专门领域的知识库与一个能获取和运用知识的机构组成。专家系统所处理的对象主

15、要是用符号表示的知识和信息，而不仅仅是数据。其智能行为除了能简单逻辑推理，目标查询之外，主要表现在启发性推理。专家系统得出结论时，能自己解释“为什么要如此做”，“是如何做的”等问题。这对判断它给出的结论是否合理或是否正确很有帮助1。1.2.1 汽车诊断专家系统的功能与特点汽车诊断专家系统的功能与特点概括地说就是“由计算机存储的专家知识，按照需要可以调用，即使初学者也能近似地如专家一样进行故障诊断”。目前，汽车故障诊断专家系统与其他诊断方式相比，具有以下特点：车内诊断和非车载诊断主要局限于汽车电器系统，而专家系统可以适用于电器和机械两方面的诊断；专家系统能利用车内诊断和非车载诊断的数据和信息，并

16、可以与检测子系统联接，有效地提高了诊断效率和精度；专家系统能与信息系统相联，在不断充实知识库的同时，通过改进各诊断系统的相互关系，可以充分发挥专家系统的优点。现代汽车诊断系统是由检测系统、专家系统和信息系统三部分构成。各系统的作用和相互关系是为了进行有效的故障诊断，有关故障诊断所必须的信息以及对每个故障现象进行处理后的结果都应该进行存储，以扩充必要的诊断知识。同时，通过信息系统还可以获得更多的诊断知识。另外，利用故障诊断设备或装置获得的车辆技术状态及自诊断结果等信息，可以通过专家系统按有效的方式进行组合，因而使诊断系统的智能化和信息化水平得到了十分有效的提高。以专家系统为核心的现代汽车故障诊断

17、系统的特点是：通过信息的网络化，沿着故障诊断流程能有效地利用相关的信息，提高了故障诊断和维修作业的正确性；应用专家系统，即使不是熟练的维修人员也能应用多种信息进行正确的故障诊断；应用多媒体技术提高了信息的交流速度和诊断工作的效率。因此，现代诊断系统具有知识库的使用效率高、诊断的适应能力强和信息的检索速度快等性能。1.2.2 研究汽车诊断专家系统的意义汽车诊断是汽车运用过程的一个重要组成部分，主要是确定在用汽车的技术状况是否正常，找出异常状况的故障原因及其部位。汽车只有在技术状况正常的情况下，才能可靠运行并充分发挥其性能，保证行驶过程中的安全性、经济性和排放性。汽车外部状况可以通过目视检查来确定

18、其状态，但在不解体的情况下，对其内部状况的判断却是十分复杂的工作。如果将汽车的总成或机构通过分解的方式进行检查，不仅费工费时，而且还可能对其可靠性和性能产生不利的影响。因此，采用汽车诊断技术对汽车技术状进行监测、检查汽车维修质量和判断汽车故障，是十分有效的方法。汽车诊断工作重点如下：对汽车的技术状态进行全面检查，确定汽车技术状况与标准状态相差的程度，从而决定汽车能否适合继续行驶，或采取何种维修措施保持和恢复技术状况；确定汽车的具体故障原因和寻找确切故障部位，制定合理的故障排除方案；预测汽车技术状态的变化趋势，在掌握汽车技术状况变化规律的前提下，确定适时的诊断周期或实现按需维修模式。2. Del

19、phi7.0软件简介DELPHI是著名的Borland公司开发的可视化软件开发工具。DELPHI被称为第四代编程语言，简单、高效、功能强大。产生背景：在DOS年代，程序员可以选择的开发工具是非常有限的。随着Windows平台的推出，这种情况有所改善，人们可以使用C+语言或者Visual Basic语言。但是C+功能强大但是使用困难，VB使用简单但是语言本身具有重大局限。因此人们迫切需要一种能够集两者优点而舍弃两者缺点的开发工具。在这种情况下DELPHI产生，DELPHI兼备了VC功能强大和VB简单易学的特点。DELPHI已经从DELPHI 1.0 发展到现在的DELPHI 7.02。（1）可视

20、化开发环境可视化开发环境通常分为三个组成部分：编辑器、调试器和窗体设计器。和大多数现代RAD(快速应用开发)工具一样，这三部分是协同工作的。当你在窗体设计器中工作时，Delphi在后台自动为你正在窗体中操纵的控件生成代码。你还可以自己在编辑器中加入代码来定义应用程序的行为，同时还可以在同一个编辑器中通过设置断点和监控点等来调试程序。总的来说Delphi的编辑器和其他工具的编辑器类似，但它的CodeInsight技术却省去了许多输入工作的麻烦。这一技术是建立在编译器信息之上的，而不是基于像Visual Basic 等使用的类型库，因此应用范围更广泛。在版本5里，Delphi的调试器已具备了许多先

21、进的功能，如远程调试、过程关联、DLL和包调试、自动本地监控以及CPU窗口等。Delphi还支持在调试时随意放置和停靠窗口并把这一状态保存为命令的桌面设置。由此，Delphi的IDE实现了对调试功能的良好支持。对RAD工具来说，窗体设计器是一项独特的功能。一些更为经典的开发环境，如VC+和BC+，都提供了对话编辑器，但却没有将窗体设计器集成到开发流程中。Delphi的窗体设计器的与众不同之处在于，Delphi是建立在一个真正面向对象的框架结构基础之上的。这样，你对基类所做的改变都将会传递给所有的派生类。这里涉及的一项关键技术就是VFI(visual form inheritance)，即可视化

22、窗体继承。VFI技术使你能够动态地继承当前项目或对象库中的任何其他窗体。一旦基窗体发生改变，派生的窗体会立即予以更新。（2）编译器的速度和已编译代码的效率快速的编译器可以使你逐步递进地开发软件，经常地修改源代码、重新编译、测试、再修改、再编译、再测试形成这样一个良好的开发循环。如果编译速度很慢，开发者就不得不分批地修改代码，每次编译前进行多处修改以适应一个低效率的循环过程。提高运行效率、节约运行时间、生成的二进制代码更为短小，其优越性是不言而喻的。Pascal编译器最著名的特点就是速度快，而Delphi正是建立在这种编译器的基础之上的。事实上，它是针对Windows的最快的高级语言本地代码编译

23、器。编译速度一定能与运行效率成正比吗？当然不是。Delphi和C+Builder共享同一种编译器后端，因此生成的代码等效于由一个优秀的C+编译器生成的代码。（3）编程语言的功能及其复杂性从根本上来说，汇编是一种最有力的语言。用它你几乎无所不能。但是，即便是用汇编开发最简单的应用程序，难度也非常大，还可能一无所获。因此，我们对汇编的评价很低，它虽然功能很强大，但对几乎所有的开发者来说都太复杂了。C+是另一种极为有力的语言。在它的潜在功能(如预处理器宏、模板、操作符加载等等)的帮助下，你几乎可以使用C+设计你自己的语言。只要合理地使用其丰富的功能选项，就可以开发出简洁直观、易于维护的代码。但这种语

24、言自己不会朝着好的设计方向前进-这由开发者决定。Object Pascal和Java给我们的感觉很相似，因为它们很好地把握住了复杂性和功能性的平衡。它们都采取了这样一种途径，即限制其可用功能以加强开发者的逻辑设计。例如，两者都避免了完全面向对象但却容易被滥用的多重继承的观念，而是实现了一个执行多重接口功能的类。两者都不支持美观却危险的操作符加载。两者都有一些强大的功能，诸如异常处理、运行期类型信息(RTTI)和生存期内存自管理字符串。同时，两种语言都不是由专门的编委会写出来的，而是来自于单个组织中对这种语言有着共同理解的个人或小组。（4） 数据库结构的灵活性和可扩展性由于Borland缺少一种

25、数据库计划，因此Delphi保留了我们认为是所有工具中最灵活的数据库结构。对大多数基于本地、客户/服务器和ODBC数据库平台的应用程序来说，Delphi采用的独特的数据库引擎BDE（Borland database engine）对数据库进行操作，通过BDE与各种数据库的接口，可以访问oracleSybasems accessdbaseparadox和interlace等数据库4。BDE还可以与Borland的SQL Link链接，访问各种网络数据库。它具有编程简单，移植方便的特点。如果你对此不满意，可以避开使用BDE以支持新的本地ADO组件。如果你没有装ADO，可以自己创建数据访问类或者购买

26、第三方数据访问解决方案。此外，MIDAS使对数据源的多层访问更易于实现。Microsoft的工具(ODBC、OLEDB或者其他)从逻辑上来说趋向于支持Microsoft自己的数据库和数据访问解决方案。（5）框架对设计和使用模式的扩充这是一项经常被其他软件设计工具忽略了的重要功能。VCL是Delphi最重要的组成部分。在设计时操纵组件、创建组件、使用OO(面向对象)技术继承其他组件的行为，这些能力都是决定Delphi效率的关键因素。在许多场合，编写VCL组件都采用固定的OO设计方法。相比之下，其他基于组件的框架经常过于死板或过于复杂。比如ActiveX控件具有和VCL控件相同的设计期性能，但却不

27、能被继承以创建一个具有其他不同行为的新类。传统的类框架，如OWL和MFC，需要你有大量的内部结构知识，而且如果没有RAD工具的设计期支持，其功能将会受到抑制。将来能够与VCL的功能相媲美的一个工具是Visual J+的WFC( Windows Foundation Classes)，即Windows基础类。但是由于Sun Microsystems对Java问题的诉讼仍悬而未决，Visual J+的前景还不确定5。3. 汽车系统的故障分析3.1 汽车故障的产生汽车在复杂的环境中行驶或停放，由于物理变化和化学变化，引起汽车零件磨损、腐蚀和机械性损坏等，使汽车的技术性能(动力性、经济性、可靠性)逐步

28、变坏，致使汽车不能正常运行，汽车便发生了故障。引起汽车故障的因素有:使用不当、维护不当、材料选用不当、制造质量差、气温条件恶劣、道路条件差、低质燃油、低质润滑油等。上述引起汽车故障的因素不一定立即影响到汽车的正常运行，但是能够形成故障隐患，严重时会导致车辆彻底抛锚。使用不当，如猛然放松离合器踏板等操作不规范现象，这种违反操作规程的现象，就易使汽车发生故障。还有超载和不合理时速等运行现象，超载时，汽车通过一些不平路面时，易引起机件变形，加快零部件的损坏，不合理时速，汽车运行时，驾驶员若不能正确估计发动机动力和行驶阻力，盲目行驶，即发动机高转速低档位，或高档位低速行驶，也容易使发动机和传动机件损坏

29、。随着行驶里程的增加，汽车的技术状况相应的逐步变坏。对汽车实行定期维护或者视情维护十分重要。若维护不当，便会引起汽车故障。汽车维护一般以检查、调整、润滑、清洁、紧固等作业项目为主，其次是及时排除故障。根据汽车运行的特点，除了合理的设计和制造时采用新技术、新工艺外，合理选用材料也很重要。如果材料选用不当，就会引起汽车故障。汽车寿命的长短和制造质量有密切关系，若制造质量低劣，汽车就会经常发生故障。制造质量包括焊接质量、机械加工质量、装质量等。气温条件恶劣即气温过高或者过低，都不利汽车的使用，如果按照操作规程采取防范措施，则对汽车的寿命影响较小，否则，就容易使汽车发生故障。气温过低，会使润滑油变稠，

30、若预热不良就会造成润滑不良；对于气压制动汽车，气温过低易造成气压制动失灵。柴油在低温时易凝固，易造成油路堵塞发动机不容易发动或者启动后熄火等故障。气温过高，易引起爆震，“气阻”燃油供应中断，功率下降，润滑油粘度降低润滑不良等故障现象。道路的好坏直接影响汽车的寿命，如果汽车在不良的道路上行驶。容易使汽车发生故障。例如:汽车在崎岖不平的道路上行驶，由于行驶速度需要经常变化，换档次数频繁，离合器分离和结合次数增加，加剧摩擦片的磨损和压盘弹簧的疲劳;制动次数增多，加剧制动蹄片与制动鼓磨损;爬坡时间长，润滑油温度升高，粘度变小，润滑不良，各部机件磨损，同时轮胎也会加快磨损;在凹凸不平的道路上行驶，会引起

31、汽车振动，使悬架装置和支承机件受到冲击载荷，导致车架等机件变形或者断裂，造成汽车机械性能损坏。汽油质量的优劣，是对汽油的蒸发性、抗爆性、胶质含量、酸、碱、硫含量、机械杂质和水分等指标的评价。汽油质量的好坏，直接影响发动机的正常运转和寿命。汽车行驶的时候，各连接部件产生相对运动，必然引起磨损。为了减少磨损，延长机件使用寿命，要求两配合机件表面间需要有良好的润滑油作介质，将摩擦表面隔离，形成液体摩擦。如果润滑油油质低劣，便不能形成好的润滑油膜，会引起机件加速磨损。因此，对润滑油有一定的质量要求。3.2 汽车故障的特性汽车故障具有如下特性:（1)层次性:是故障的“纵向性”，由系统的结构的层次性所决定

32、。任何故障都是与系统的某一层次相联系的，高层次故障可以由低层次的故障所引起，而低层次故障必定引起高层次故障。(2)相关性:这是故障的“横向性”，是由系统各元素之间的联系所决定的。某个子系统的故障常常是与之相关的子系统或者下一级子系统故障传播所至，从而表现出相关性。故障传播途径的不唯一，又引起了多故障并存。(3)时间性:系统故障的产生与表现于时间有关，从原发性故障到系统级故障的发生、发展及形成，是一个由量变到质变的过程。这一特性提示人们，故障可以早期预测、诊断，达到“防患于未然”的目的。(4)不确定性:使系统故障的一个重要特性，具有模糊性和随机性两种特征。引起故障不确定性的因素有很多方面，如系统

33、的元素特性和联系特性的不确定性、状态描述方法与工作环境的不确定性等等。复杂系统诊断问题的不确定性，是基于知识的诊断推理的一个重要研究内容。3.3 本章小结本章主要分析了专家系统的研究对象:汽车的故障。详细分析汽车故障，了解故障产生的原因、背景以及特点，有助于更好的建立汽车故障诊断的知识库和相关的推理策略。4. 汽车故障诊断专家系统设计与开发4.1 汽车故障诊断专家系统的一般结构开发这样一个系统，首先需要将汽车维修领域专家的大量实际维修经验进行汇总和提炼，编成知识库，构成专家系统的核心部分；其次需要建立推理机，推理机可根据用户提供的故障迹象或异常现象，利用知识库中的知识，按一定推理策略进行推理，

34、进而得出诊断结果。专家系统结构一般包括6部分：知识库、推理机、综合数据库、人机接口、解释程序和知识库获取程序，该专家系统的结构如图所示6。人 机 接 口专 家用 户推理机知识库获取程序解释程序综合数据库知识库图1. 专家系统一般结构4.2 基于Delphi的汽车故障诊断专家系统的特点基于Delphi7.0开发的本故障诊断专家系统能满足如下要求：（1）有良好的扩充性；（2）易于发布，容量不能过大，即知识库中的素材不能占用过大存储空间；（3）人机交互，便于操作使用；（4）高效的推理策略，完善的数据库和图像库。（5）数据库是在DBMS（数据库管理系统）集中管理下，具有较高的数据独立性，较少的冗余，并

35、且相互间有联系的文件集合7。它不仅能反映数据的本身，而且能够反映数据之间的联系，在多个表的之间进行操作。数据库还具有数据独立性，数据安全性，数据完整性，集中管理，控制冗余等。利用数据库构建专家系统的知识库，具有存储规则多，查询方便、快捷，且便于维护。在系统的应用程序开发过程中，主要采用分模块开发的调用程序结构，使其便于集体开发和软件功能的扩展。其总体结构方框图如图2 所示。图2. 总体结构方案图主菜单规则故障诊断实例故障诊断知识库辅助系统发动机系统底盘系统电器设备系统规则库实例库系统介绍使用说明发动机系统底盘系统电器设备系统4.3 故障诊断专家系统各模块的建立4.3.1 故障诊断模块故障诊断是

36、专家系统的重要组成部分，直接影响到用户对专家系统使用和维护的方便以及其功能的发挥。因此，构建该专家系统的时候，将以用户使用的简便性、可操作性为目标，针对这一要求，选用了可视化编程语言Object Pascal来编制程序。该专家系统将充分体现人性化，是图文并茂的完全诊断手册，在诊断中，配以相应的实物原形图来表示故障发生的具体部位以及维修使用的工具，并用相应的文字说明，让使用维修人员能够很快地识别，做出反应。其用户界面友好、灵活，由弹出菜单和屏幕菜单回答系统来实现，数据输入根据屏幕提出的问题由键盘响应来回答。该模块以人机对话的方式搜索用户所掌握的故障线索，模仿维修专家的诊断思路进行推理，进而一步步

37、找出故障部件及原因，其诊断流程框图如图3所示。根据汽车的具体情况将诊断模块分为三个部分，即发动机系统、底盘系统、电器设备系统。故障现象选择屏幕提示用户回答是否找到故障原因推理分析诊断报告NY图3. 诊断流程图以发动机系统为例，在建立发动机不能发动诊断子模块时，针对其故障特点，采用了较形象的树状图示诊断方案。当进行诊断时，系统根据用户对询问的回答确定下一步显示的树枝，直到诊断进行到树叶（找出故障原因）为止保存。此时，预览诊断按钮由失效变为可用（未诊断完则为失效状态），按下去后可弹出诊断报告屏幕，其人机界面见图4。(a) 故障诊断界面（b）诊断报告界面发动机不能发动有着车现象无着车现象确定起动困难

38、此项目正常继续诊断保存诊断结果预览诊断报告诊断报告界面(c)故障诊断流程图图4 故障诊断界面及流程图逐步寻找故障零部件此故障现象的原因及排除方案按返回按钮继续诊断单选故障现象相应代码如下：procedure TFDESForm.sure4_ButtonClick(Sender: TObject);/确定按钮响应事件beginshow4_Edit.text:=发动机不能启动，+ RadioGroup1.ItemsRadioGroup1.ItemIndex;Table1.Active:=True;/数据库表1生效Table1.First;continue4_Button.Enabled:=True

39、;/此项目正常继续诊断按钮可用save4_Button.Enabled:=True;i:=1;case RadioGroup1.ItemIndex of1: Table1.MoveBy(1);2: Table1.MoveBy(3);end;end;procedure TFDESForm.continue4_ButtonClick(Sender: TObject);/ 此项目正常继续诊断按钮响应事件beginsave4_Button.Enabled:=True;case RadioGroup1.ItemIndex of0: begin if i2 then Table1.Next else co

40、ntinue4_Button.Enabled:=false; end;1: begin if i3 then Table1.Next else continue4_Button.Enabled :=false; end;2:begin if i6 then Table1.Next else continue4_Button.Enabled:=false; end;end;i:=i+1;end;procedure TFDESForm.save4_ButtonClick(Sender: TObject);/保存此诊断结果按钮的响应事件beginMemo1.Linesa:=(故障现象: + show

41、4_Edit.Text +#13#10+ 故障原因：+DBMemo1.Lines0+DBMemo1.Lines1+ DBMemo1.Lines2+DBMemo1.Lines3+DBMemo1.Lines4+ #13#10+排除方法：+DBMemo2.Lines0+DBMemo2.Lines1+ DBMemo2.Lines2+DBMemo2.Lines3+DBMemo2.Lines4+ DBMemo2.Lines5+DBMemo2.Lines6);save4_Button.Enabled:=false;/ 保存此诊断结果按钮失效preview4_Button.Enabled:=True;/预览诊

42、断报告按钮生效a:=a+8;end;（1）诊断软件设计中的难点分析实现此故障树诊断法，首先在表单上画好所有的树状图，然后根据每个按钮、询问文件之间的逻辑关系，编写按下此按钮时要执行的动作（OnClick属性）。（2）错选反悔功能的设计有时，当用户按确定按钮后，在已显示出了相应的诊断内容后，发现选错了，反悔并回过来按下其上一级或上几级的某个按钮。系统必须允许这种错误的发生，并实现他的要求，即在每个按钮的OnClick属性内加入一些语句，使除了应该显示的内容Enabled:=true（可见）外，其余对象的属性均变回Enabled:=false（不可见），这就需要逐条的控制每一对象。用户在诊断过程中

43、，允许实现浏览功能。诊断完毕后还允许对诊断报告进行修改，以得到最佳的诊断效果。诊断过程中，以单击保存诊断结果将所对应的内容作为一个记录保存在诊断报告中，诊断完毕后即完成一份完整的诊断报告。当对某一次诊断结果的保存有误，允许执行取消命令取消单次的保存结果，也可在诊断报告界面进行人工修改。取消按钮的代码：procedure TFDESForm.concel4_ButtonClick(Sender: TObject);beginfor n:=a downto a-8 doMemo1.Lines n:=;a:=a-8 ;end;4.3.2 故障诊断知识库的建立该汽车故障诊断专家系统采用融合实例（cas

44、e）与规则（rule）的推理方法，为更好地对知识库进行管理和维护，把知识库分成2部分：实例库和规则库。其中实例库是指以前曾成功解决过的问题或案例。结合汽车结构特点，将实例库分为3个子库：发动机库、底盘库以及汽车电器库。每一个子库又划分为若干个小块，每一小块对应一张表。如可将汽车发动机部分划分为：发动机不能发动、发动机怠速不良、发动机无力、发动机温度油耗异常、发动机异响这5块。所以，汽车发动机子库包含5张表，每张表记录了该块的所有故障诊断实例。每个诊断实例看作是一条记录，诊断实例所需要的参数为一个字段，具体的实例表示方法如表1所示。表1. 发动机不能发动的实例表enginestart车型故障现象

45、故障原因排除方法图片1桑塔纳2000（时代超人）起动机运转正常，但不能着车汽油泵不运转拆下汽油泵分解检查，泵线圈烧毁，更换。规则是表达由一定的前提推出确定的结论的知识，故障诊断中的规则一般都是领域专家从长期的实践经验中得出的规律性的结论。规则的一般形式是if x then y其中x表示前提，y表示结论，如同实例库一样，规则库也分为发动机、底盘和电器3 部分，每一部分又划分为若干块，每一块对应一个规则表，规则采用表2的形式记录。表2. 发动机怠速不良的规则表idleengine故障现象故障原因排除方法规则率1怠速不稳1、电控系统异常检查怠速控制电机及电位计是否异常。正常则在游车状态下，观察节气门

46、是否能进行反馈调节，能说明怠速控制系统正常。用传感器模拟测试仪模拟空气流量计，如怠速不稳现象消失，则更换空气流量计。0.822、进气管漏气进气管处加装压力计和增压器，给进气管加气增压到25pa,保持一段时间后，观察其是否有下降趋势，有则说明漏气。仔细检查其漏气位置，针对不同位置采取不同的补救方案。0.64.3.3 知识库的基本管理知识库的管理是汽车故障诊断专家系统的重要组成部分，故障诊断专家系统运行过程中所需要的知识都是由知识库来提供的，系统的推理、决策都是围绕着运用知识库中存储的知识进行匹配、决策、归纳、演算等操作，从而得到最终结果8。因此，从某种意义上来说，知识库建造的好坏直接影响到整个汽车故障诊断专家系统是否成功，而构造高效、完善的知识库将会对整个汽车故障诊断专家系统性能的提高起到非常重要的作用。其编辑故障实例界面见图5：图5 编辑故障实例界面（1）知识的检验管理正确性检验：主要是对故障诊断知识库中的知识进行语法检查，对语法检查不合格的记录，将其状态设为不激活状态。为实现对知识库中不合法的知识进行检验，本系统采用SQL设计的关系数据库中的触发器在新知识增加时自动、及时地检验知识的合法性，保证了将这些错误消除在萌发阶段。多义性检验：对规则库中的规则来说，当已经给出完备的规则前提时应得到