汽車故障診斷專家系統(tǒng)的設計(共32頁)

1、精選優(yōu)質文檔-傾情為你奉上 中南大學課程設計說明書課 題 汽車故障診斷專家系統(tǒng)的設計 學 院 能源科學與工程學院 學生姓名 劉超 指導老師 專業(yè)班級 學 號 2012年9月19日摘要隨著社會的發(fā)展和技術的進步，汽車故障診斷技術已經(jīng)有了很大的發(fā)展。本文從汽車診斷技術的發(fā)展趨勢出發(fā)介紹了汽車故障診斷專家系統(tǒng)的基本結構及其開發(fā)的基本方法，論述了汽車故障診斷專家系統(tǒng)軟件的開發(fā)研究的意義和設計中的難點，針對汽車故障的復雜性特點模擬經(jīng)驗豐富的維修專家的診斷思路及方法，利用Delphi7進行編程，建立友好的人機界面，依據(jù)計算機數(shù)據(jù)結構原理，采用故障樹的數(shù)據(jù)結構和關系數(shù)據(jù)庫原理完成知識表示建立完善的知識庫，實

2、現(xiàn)了確定性故障診斷所需的知識庫和推理機。從而可使用戶通過人機對話的形式方便、快速、準確地找出故障原因，大大地提高汽修行業(yè)的效益及汽車的使用壽命。關鍵字：汽車 故障診斷 專家系統(tǒng)內(nèi)燃機課程設計任務書一、設計題目發(fā)動機電控系統(tǒng)設計以某一具體類型的發(fā)動機（如：凌志LS400轎車1UZ-FE型發(fā)動機）為對象，結合發(fā)動機電控系統(tǒng)設計的要求，選擇合適的傳感器和執(zhí)行器等硬件設備，對發(fā)動機的主要控制系統(tǒng)或某一控制系統(tǒng)進行硬件設計和軟件設計?？刂苾?nèi)容：發(fā)動機控制系統(tǒng)包括電子控制汽油噴射（EFI）、電子控制點火提前（ESA）、怠速控制（ISC）、廢氣再循環(huán)控制（EGR）、蒸發(fā)污染控制（ECS）、諧波進氣增壓系統(tǒng)控

3、制（ACIS）、故障診斷（DIAGN）、失效保護與后備功能和怠速混合氣濃度調節(jié)（CO排放控制）等內(nèi)容。二、設計內(nèi)容1原理簡介主要內(nèi)容：對發(fā)動機的構成與工作原理進行簡要介紹2對象特性描述 主要內(nèi)容：對所選擇的控制對象的特性進行分析和描述3控制系統(tǒng)設計發(fā)動機的電子控制系統(tǒng)設計。1）電子控制單元的設計；2）傳感器和控制開關；3）各類執(zhí)行器；4）控制系統(tǒng)的工作過程。主要內(nèi)容：控制方案的選擇與論證；被控參數(shù)與控制參數(shù)的選擇；輸入輸出系統(tǒng)的設計；畫出原理圖、方框圖和儀表流程圖、系統(tǒng)接線圖、梯形圖；進行程序設計。三、設計要求1課程設計說明書的格式應嚴格按照學校課程設計格式要求。2論理正確、邏輯性強、文理通顧

4、、層次分明、表達確切，并提出自己的見解和觀點。3課程設計說明書。前置部分：封面、摘要、設計任務書、目錄；主體部分：引言（設計目的、任務與要求等）、正文、結論、參考文獻；附錄部分：系統(tǒng)方框圖和電路原理圖、程序清單等。4課程設計說明書應包括按上述設計步驟進行設計的分析和思考內(nèi)容和引用的相關知識。5如有程序，必須提供清單。四、題目選擇汽車故障診斷專家系統(tǒng)的設計目錄1 緒論1.1 汽車故障診斷技術的發(fā)展趨勢汽車故障診斷是在不解體（或僅卸下個別小件）的條件下，確定汽車技術狀況，查明故障部位及原因的檢查和分析。有效的汽車故障診斷是維護汽車最佳車況的一個先決條件。隨著制造業(yè)水平的提高、計算機技術在汽車上的廣

5、泛應用，車輛的安全性、可靠性和操控性能得到大大的提高，同時也使得汽車結構復雜化，增加了汽車的診斷維修保養(yǎng)難度，對汽車維修人員的各方面知識和維修技能提出了更高的要求。汽車故障診斷從傳統(tǒng)的聽、看、聞等經(jīng)驗診斷方式，發(fā)展為以集成化、智能化的診斷設備為手段，以信息技術為依托的現(xiàn)代汽車故障診斷技術。1.1.1 國外發(fā)展概況20世紀50年代之前，國外就研發(fā)了以故障診斷和性能調試為主的單項檢測技術。早期的檢測診斷設備是以機械結構為主，單機人工操作。上世紀60年代，隨著機電一體化的產(chǎn)生，研制了單機自動化的設備，如四輪定位儀、非接觸式速度計等；80年代，隨著計算機技術的發(fā)展和應用，實現(xiàn)了汽車診斷控制自動化，出現(xiàn)

6、了集檢測工藝、操作、數(shù)據(jù)采集、存儲和打印等功能于一體的系統(tǒng)軟件。目前，車載自診斷系統(tǒng)和車外診斷系統(tǒng)正在進一步發(fā)展。車載自診斷系統(tǒng)（OBD）利用安裝在汽車內(nèi)各個部位的傳感器，自動檢測系統(tǒng)故障，以故障代碼形式顯示并將故障信息存入電子控制單元ECU的RAM中，在維修車輛時，維修人員能調出故障代碼，找出故障部位。1994年，美國汽車工程師協(xié)會（SAE）在第1代OBD基礎上，制定了第2代在線診斷標準OBD，OBD除了對電子控制系統(tǒng)檢測外，還對與排放有關的系統(tǒng)監(jiān)測，更注重綠色環(huán)保問題。車外診斷系統(tǒng)，通過傳感器采集信號，送至車外儀器，在相應診斷軟件的支持下，完成各種診斷。例如：發(fā)動機綜合分析儀等。1.1.2

7、 國內(nèi)發(fā)展概況我國是20世紀60年代開始研究檢測技術，如發(fā)動機氣缸漏氣量檢測儀等。80年代，隨著汽車工業(yè)的發(fā)展，汽車診斷技術得到了迅速發(fā)展，到90年代，相繼研制了側滑試驗臺、制動試驗臺、汽車檢測站以及我國自主開發(fā)的發(fā)動機故障診斷儀、四輪定位儀等。汽車檢測站綜合運用現(xiàn)代檢測技術和設備對汽車進行不解體或不完全解體條件下的性能檢測診斷，實現(xiàn)了以汽車安全性能為主到綜合性能的檢測。國產(chǎn)車在汽車電子控制方面上也廣泛應用了OBD，但根據(jù)我國目前的排放法規(guī)，OBD還沒有在國產(chǎn)車上廣泛使用。我國汽車診斷技術正在快速發(fā)展，但與國外先進水平相比，還有一定差距，主要突出在以下幾個方面：（1）管理水平還須進一步提高。我

8、國已基本建立了車輛檢測診斷制度，實施了“定期檢測、強制維護、視情修理”的汽車維修制度，但我國各地區(qū)經(jīng)濟和技術水平不一致，大部分地區(qū)尚未進行汽車維修行業(yè)的電腦化管理和信息化建設，甚至還有“事后維修”現(xiàn)象。汽車診斷技術的滯后，與高速發(fā)展的汽車技術和迅猛增長的汽車保有量嚴重脫節(jié)，這是一個值得重視的問題。（2）診斷設備和儀器的國產(chǎn)化研發(fā)能力欠佳，而進口診斷設備價格昂貴，阻礙了我國汽車診斷技術的發(fā)展。（3）汽車維修人員的素質普遍不高。汽車的高科技化，現(xiàn)代檢測設備本身的高性能，要求維修人員具備一定的汽車專業(yè)、機電專業(yè)理論知識，懂計算機、會英語，綜合職業(yè)能力強，但這種技能型專門人才緊缺。目前我國汽車保有量正

9、在快速增加，進口車也越來越多，且車型復雜、種類繁多，因而使許多維修單位由于缺乏有關維修專家的技術指導而不能維修或難以滿足維修的需要。為了提高車輛的利用率減少經(jīng)濟損失，開發(fā)汽車故障診斷專家系統(tǒng)，利用計算機這種先進的設備進行故障診斷是形勢發(fā)展的需要和必然趨勢。1.1.3 汽車故障診斷技術的發(fā)展趨勢高科技的發(fā)展，信息化的網(wǎng)絡，使得汽車故障診斷技術必將向著智能化、集成化方向發(fā)展。（1）基于神經(jīng)網(wǎng)絡的故障診斷專家系統(tǒng)神經(jīng)網(wǎng)絡具有較好的容錯性，較強的自學習功能、自適應能力，大規(guī)模并行處理能力等。把神經(jīng)網(wǎng)絡應用于診斷專家系統(tǒng)是新一類知識表達體系，在知識獲取、并行推理等方面有明顯的優(yōu)越性，解決了傳統(tǒng)專家系統(tǒng)在

10、知識獲取上的瓶頸問題，提高了診斷系統(tǒng)的智能水平。（2）基于網(wǎng)絡的集成故障診斷專家系統(tǒng)由于汽車故障診斷實例豐富、診斷信息量大，不確定因素多，因此，探索適合汽車領域的專家系統(tǒng)，集成規(guī)則、案例、模糊和神經(jīng)網(wǎng)絡理論，集成推理機制，以網(wǎng)絡為框架，以多媒體技術為載體，研究多種診斷模型融合技術必將是發(fā)展方向。集成故障診斷專家系統(tǒng)能自動選擇合適的診斷模型，靈活處理診斷知識和應用推理方式，滿足內(nèi)在機理上的融合，避免診斷的冗余問題。多媒體技術集圖形、音像、文本于一體，使診斷系統(tǒng)具有良好的人機界面和交互環(huán)境，增加了系統(tǒng)的可靠性，提高了診斷的效率。通過局域網(wǎng)、因特網(wǎng)實現(xiàn)異地診斷和在線診斷，達到多個專家協(xié)同診斷、提高診

11、斷準確性的目的，還可以對汽車診斷人員進行遠程培訓，在多媒體情境中，使診斷技術易懂好學，提高培訓成效，保持診斷技術的先進性汽車技術的高科技性，對汽車故障診斷技術提出了很高的要求。智能化、集成化的現(xiàn)代汽車故障診斷技術必將成為汽車檢測維修領域的發(fā)展方向。1.2 汽車故障診斷專家系統(tǒng)簡介汽車故障診斷專家系統(tǒng)是一種能模擬維修專家的診斷思路進行故障診斷的計算機智能軟件程序。研制專家系統(tǒng)的目的，就是要使計算機在特定領域中起到該領域人類專家應起的作用，設計專家系統(tǒng)的基本思想是使計算機的工作過程竭盡全力地來模擬人類專家解決實際問題的工作過程，也就是模擬人類專家如何運用他的知識與經(jīng)驗來解決所要解決的問題的方法與步

12、驟。本系統(tǒng)可利用計算機強大的信息處理能力，廣泛收集各種車型的技術參數(shù)、故障征兆和判斷處理程序及維修專家的經(jīng)驗，應用數(shù)據(jù)庫及編程技術，依據(jù)汽車故障樹建立動態(tài)知識庫和推理庫，利用強大數(shù)據(jù)庫，在計算機提示下，完成診斷和修理工作，友好的人機交互操作界面及多媒體技術，將使診斷維修更為形象、直觀。汽車故障診斷專家系統(tǒng)（FDES）是根據(jù)對癥狀的觀察與分析，推斷故障所在，并給出排除故障方案的系統(tǒng)。其實也可以把它定義為一個在某領域內(nèi)，具有專家級水平的知識處理程序系統(tǒng)。在結構上它由一個專門領域的知識庫與一個能獲取和運用知識的機構組成。專家系統(tǒng)所處理的對象主要是用符號表示的知識和信息，而不僅僅是數(shù)據(jù)。其智能行為除了

13、能簡單邏輯推理，目標查詢之外，主要表現(xiàn)在啟發(fā)性推理。專家系統(tǒng)得出結論時，能自己解釋“為什么要如此做”，“是如何做的”等問題。這對判斷它給出的結論是否合理或是否正確很有幫助1。1.2.1 汽車診斷專家系統(tǒng)的功能與特點汽車診斷專家系統(tǒng)的功能與特點概括地說就是“由計算機存儲的專家知識，按照需要可以調用，即使初學者也能近似地如專家一樣進行故障診斷”。目前，汽車故障診斷專家系統(tǒng)與其他診斷方式相比，具有以下特點：車內(nèi)診斷和非車載診斷主要局限于汽車電器系統(tǒng)，而專家系統(tǒng)可以適用于電器和機械兩方面的診斷；專家系統(tǒng)能利用車內(nèi)診斷和非車載診斷的數(shù)據(jù)和信息，并可以與檢測子系統(tǒng)聯(lián)接，有效地提高了診斷效率和精度；專家系統(tǒng)

14、能與信息系統(tǒng)相聯(lián)，在不斷充實知識庫的同時，通過改進各診斷系統(tǒng)的相互關系，可以充分發(fā)揮專家系統(tǒng)的優(yōu)點?，F(xiàn)代汽車診斷系統(tǒng)是由檢測系統(tǒng)、專家系統(tǒng)和信息系統(tǒng)三部分構成。各系統(tǒng)的作用和相互關系是為了進行有效的故障診斷，有關故障診斷所必須的信息以及對每個故障現(xiàn)象進行處理后的結果都應該進行存儲，以擴充必要的診斷知識。同時，通過信息系統(tǒng)還可以獲得更多的診斷知識。另外，利用故障診斷設備或裝置獲得的車輛技術狀態(tài)及自診斷結果等信息，可以通過專家系統(tǒng)按有效的方式進行組合，因而使診斷系統(tǒng)的智能化和信息化水平得到了十分有效的提高。以專家系統(tǒng)為核心的現(xiàn)代汽車故障診斷系統(tǒng)的特點是：通過信息的網(wǎng)絡化，沿著故障診斷流程能有效地利

15、用相關的信息，提高了故障診斷和維修作業(yè)的正確性；應用專家系統(tǒng)，即使不是熟練的維修人員也能應用多種信息進行正確的故障診斷；應用多媒體技術提高了信息的交流速度和診斷工作的效率。因此，現(xiàn)代診斷系統(tǒng)具有知識庫的使用效率高、診斷的適應能力強和信息的檢索速度快等性能。1.2.2 研究汽車診斷專家系統(tǒng)的意義汽車診斷是汽車運用過程的一個重要組成部分，主要是確定在用汽車的技術狀況是否正常，找出異常狀況的故障原因及其部位。汽車只有在技術狀況正常的情況下，才能可靠運行并充分發(fā)揮其性能，保證行駛過程中的安全性、經(jīng)濟性和排放性。汽車外部狀況可以通過目視檢查來確定其狀態(tài)，但在不解體的情況下，對其內(nèi)部狀況的判斷卻是十分復雜

16、的工作。如果將汽車的總成或機構通過分解的方式進行檢查，不僅費工費時，而且還可能對其可靠性和性能產(chǎn)生不利的影響。因此，采用汽車診斷技術對汽車技術狀進行監(jiān)測、檢查汽車維修質量和判斷汽車故障，是十分有效的方法。汽車診斷工作重點如下：對汽車的技術狀態(tài)進行全面檢查，確定汽車技術狀況與標準狀態(tài)相差的程度，從而決定汽車能否適合繼續(xù)行駛，或采取何種維修措施保持和恢復技術狀況；確定汽車的具體故障原因和尋找確切故障部位，制定合理的故障排除方案；預測汽車技術狀態(tài)的變化趨勢，在掌握汽車技術狀況變化規(guī)律的前提下，確定適時的診斷周期或實現(xiàn)按需維修模式。專心-專注-專業(yè)2. Delphi7.0軟件簡介DELPHI是著名的B

17、orland公司開發(fā)的可視化軟件開發(fā)工具。DELPHI被稱為第四代編程語言，簡單、高效、功能強大。產(chǎn)生背景：在DOS年代，程序員可以選擇的開發(fā)工具是非常有限的。隨著Windows平臺的推出，這種情況有所改善，人們可以使用C+語言或者Visual Basic語言。但是C+功能強大但是使用困難，VB使用簡單但是語言本身具有重大局限。因此人們迫切需要一種能夠集兩者優(yōu)點而舍棄兩者缺點的開發(fā)工具。在這種情況下DELPHI產(chǎn)生，DELPHI兼?zhèn)淞薞C功能強大和VB簡單易學的特點。DELPHI已經(jīng)從DELPHI 1.0 發(fā)展到現(xiàn)在的DELPHI 7.02。（1）可視化開發(fā)環(huán)境可視化開發(fā)環(huán)境通常分為三個組成部

18、分：編輯器、調試器和窗體設計器。和大多數(shù)現(xiàn)代RAD(快速應用開發(fā))工具一樣，這三部分是協(xié)同工作的。當你在窗體設計器中工作時，Delphi在后臺自動為你正在窗體中操縱的控件生成代碼。你還可以自己在編輯器中加入代碼來定義應用程序的行為，同時還可以在同一個編輯器中通過設置斷點和監(jiān)控點等來調試程序?？偟膩碚fDelphi的編輯器和其他工具的編輯器類似，但它的CodeInsight技術卻省去了許多輸入工作的麻煩。這一技術是建立在編譯器信息之上的，而不是基于像Visual Basic 等使用的類型庫，因此應用范圍更廣泛。在版本5里，Delphi的調試器已具備了許多先進的功能，如遠程調試、過程關聯(lián)、DLL和包

19、調試、自動本地監(jiān)控以及CPU窗口等。Delphi還支持在調試時隨意放置和?？看翱诓堰@一狀態(tài)保存為命令的桌面設置。由此，Delphi的IDE實現(xiàn)了對調試功能的良好支持。對RAD工具來說，窗體設計器是一項獨特的功能。一些更為經(jīng)典的開發(fā)環(huán)境，如VC+和BC+，都提供了對話編輯器，但卻沒有將窗體設計器集成到開發(fā)流程中。Delphi的窗體設計器的與眾不同之處在于，Delphi是建立在一個真正面向對象的框架結構基礎之上的。這樣，你對基類所做的改變都將會傳遞給所有的派生類。這里涉及的一項關鍵技術就是VFI(visual form inheritance)，即可視化窗體繼承。VFI技術使你能夠動態(tài)地繼承當前

20、項目或對象庫中的任何其他窗體。一旦基窗體發(fā)生改變，派生的窗體會立即予以更新。（2）編譯器的速度和已編譯代碼的效率快速的編譯器可以使你逐步遞進地開發(fā)軟件，經(jīng)常地修改源代碼、重新編譯、測試、再修改、再編譯、再測試形成這樣一個良好的開發(fā)循環(huán)。如果編譯速度很慢，開發(fā)者就不得不分批地修改代碼，每次編譯前進行多處修改以適應一個低效率的循環(huán)過程。提高運行效率、節(jié)約運行時間、生成的二進制代碼更為短小，其優(yōu)越性是不言而喻的。Pascal編譯器最著名的特點就是速度快，而Delphi正是建立在這種編譯器的基礎之上的。事實上，它是針對Windows的最快的高級語言本地代碼編譯器。編譯速度一定能與運行效率成正比嗎？當然

21、不是。Delphi和C+Builder共享同一種編譯器后端，因此生成的代碼等效于由一個優(yōu)秀的C+編譯器生成的代碼。（3）編程語言的功能及其復雜性從根本上來說，匯編是一種最有力的語言。用它你幾乎無所不能。但是，即便是用匯編開發(fā)最簡單的應用程序，難度也非常大，還可能一無所獲。因此，我們對匯編的評價很低，它雖然功能很強大，但對幾乎所有的開發(fā)者來說都太復雜了。C+是另一種極為有力的語言。在它的潛在功能(如預處理器宏、模板、操作符加載等等)的幫助下，你幾乎可以使用C+設計你自己的語言。只要合理地使用其豐富的功能選項，就可以開發(fā)出簡潔直觀、易于維護的代碼。但這種語言自己不會朝著好的設計方向前進-這由開發(fā)者

22、決定。Object Pascal和Java給我們的感覺很相似，因為它們很好地把握住了復雜性和功能性的平衡。它們都采取了這樣一種途徑，即限制其可用功能以加強開發(fā)者的邏輯設計。例如，兩者都避免了完全面向對象但卻容易被濫用的多重繼承的觀念，而是實現(xiàn)了一個執(zhí)行多重接口功能的類。兩者都不支持美觀卻危險的操作符加載。兩者都有一些強大的功能，諸如異常處理、運行期類型信息(RTTI)和生存期內(nèi)存自管理字符串。同時，兩種語言都不是由專門的編委會寫出來的，而是來自于單個組織中對這種語言有著共同理解的個人或小組。（4） 數(shù)據(jù)庫結構的靈活性和可擴展性由于Borland缺少一種數(shù)據(jù)庫計劃，因此Delphi保留了我們認為

23、是所有工具中最靈活的數(shù)據(jù)庫結構。對大多數(shù)基于本地、客戶/服務器和ODBC數(shù)據(jù)庫平臺的應用程序來說，Delphi采用的獨特的數(shù)據(jù)庫引擎BDE（Borland database engine）對數(shù)據(jù)庫進行操作，通過BDE與各種數(shù)據(jù)庫的接口，可以訪問oracleSybasems accessdbaseparadox和interlace等數(shù)據(jù)庫4。BDE還可以與Borland的SQL Link鏈接，訪問各種網(wǎng)絡數(shù)據(jù)庫。它具有編程簡單，移植方便的特點。如果你對此不滿意，可以避開使用BDE以支持新的本地ADO組件。如果你沒有裝ADO，可以自己創(chuàng)建數(shù)據(jù)訪問類或者購買第三方數(shù)據(jù)訪問解決方案。此外，MIDAS使

24、對數(shù)據(jù)源的多層訪問更易于實現(xiàn)。Microsoft的工具(ODBC、OLEDB或者其他)從邏輯上來說趨向于支持Microsoft自己的數(shù)據(jù)庫和數(shù)據(jù)訪問解決方案。（5）框架對設計和使用模式的擴充這是一項經(jīng)常被其他軟件設計工具忽略了的重要功能。VCL是Delphi最重要的組成部分。在設計時操縱組件、創(chuàng)建組件、使用OO(面向對象)技術繼承其他組件的行為，這些能力都是決定Delphi效率的關鍵因素。在許多場合，編寫VCL組件都采用固定的OO設計方法。相比之下，其他基于組件的框架經(jīng)常過于死板或過于復雜。比如ActiveX控件具有和VCL控件相同的設計期性能，但卻不能被繼承以創(chuàng)建一個具有其他不同行為的新類。

25、傳統(tǒng)的類框架，如OWL和MFC，需要你有大量的內(nèi)部結構知識，而且如果沒有RAD工具的設計期支持，其功能將會受到抑制。將來能夠與VCL的功能相媲美的一個工具是Visual J+的WFC( Windows Foundation Classes)，即Windows基礎類。但是由于Sun Microsystems對Java問題的訴訟仍懸而未決，Visual J+的前景還不確定5。3. 汽車系統(tǒng)的故障分析3.1 汽車故障的產(chǎn)生汽車在復雜的環(huán)境中行駛或停放，由于物理變化和化學變化，引起汽車零件磨損、腐蝕和機械性損壞等，使汽車的技術性能(動力性、經(jīng)濟性、可靠性)逐步變壞，致使汽車不能正常運行，汽車便發(fā)生了故

26、障。引起汽車故障的因素有:使用不當、維護不當、材料選用不當、制造質量差、氣溫條件惡劣、道路條件差、低質燃油、低質潤滑油等。上述引起汽車故障的因素不一定立即影響到汽車的正常運行，但是能夠形成故障隱患，嚴重時會導致車輛徹底拋錨。使用不當，如猛然放松離合器踏板等操作不規(guī)范現(xiàn)象，這種違反操作規(guī)程的現(xiàn)象，就易使汽車發(fā)生故障。還有超載和不合理時速等運行現(xiàn)象，超載時，汽車通過一些不平路面時，易引起機件變形，加快零部件的損壞，不合理時速，汽車運行時，駕駛員若不能正確估計發(fā)動機動力和行駛阻力，盲目行駛，即發(fā)動機高轉速低檔位，或高檔位低速行駛，也容易使發(fā)動機和傳動機件損壞。隨著行駛里程的增加，汽車的技術狀況相應的

27、逐步變壞。對汽車實行定期維護或者視情維護十分重要。若維護不當，便會引起汽車故障。汽車維護一般以檢查、調整、潤滑、清潔、緊固等作業(yè)項目為主，其次是及時排除故障。根據(jù)汽車運行的特點，除了合理的設計和制造時采用新技術、新工藝外，合理選用材料也很重要。如果材料選用不當，就會引起汽車故障。汽車壽命的長短和制造質量有密切關系，若制造質量低劣，汽車就會經(jīng)常發(fā)生故障。制造質量包括焊接質量、機械加工質量、裝質量等。氣溫條件惡劣即氣溫過高或者過低，都不利汽車的使用，如果按照操作規(guī)程采取防范措施，則對汽車的壽命影響較小，否則，就容易使汽車發(fā)生故障。氣溫過低，會使?jié)櫥妥兂?，若預熱不良就會造成潤滑不良；對于氣壓制動汽

28、車，氣溫過低易造成氣壓制動失靈。柴油在低溫時易凝固，易造成油路堵塞發(fā)動機不容易發(fā)動或者啟動后熄火等故障。氣溫過高，易引起爆震，“氣阻”燃油供應中斷，功率下降，潤滑油粘度降低潤滑不良等故障現(xiàn)象。道路的好壞直接影響汽車的壽命，如果汽車在不良的道路上行駛。容易使汽車發(fā)生故障。例如:汽車在崎嶇不平的道路上行駛，由于行駛速度需要經(jīng)常變化，換檔次數(shù)頻繁，離合器分離和結合次數(shù)增加，加劇摩擦片的磨損和壓盤彈簧的疲勞;制動次數(shù)增多，加劇制動蹄片與制動鼓磨損;爬坡時間長，潤滑油溫度升高，粘度變小，潤滑不良，各部機件磨損，同時輪胎也會加快磨損;在凹凸不平的道路上行駛，會引起汽車振動，使懸架裝置和支承機件受到?jīng)_擊載荷

29、，導致車架等機件變形或者斷裂，造成汽車機械性能損壞。汽油質量的優(yōu)劣，是對汽油的蒸發(fā)性、抗爆性、膠質含量、酸、堿、硫含量、機械雜質和水分等指標的評價。汽油質量的好壞，直接影響發(fā)動機的正常運轉和壽命。汽車行駛的時候，各連接部件產(chǎn)生相對運動，必然引起磨損。為了減少磨損，延長機件使用壽命，要求兩配合機件表面間需要有良好的潤滑油作介質，將摩擦表面隔離，形成液體摩擦。如果潤滑油油質低劣，便不能形成好的潤滑油膜，會引起機件加速磨損。因此，對潤滑油有一定的質量要求。3.2 汽車故障的特性汽車故障具有如下特性:（1)層次性:是故障的“縱向性”，由系統(tǒng)的結構的層次性所決定。任何故障都是與系統(tǒng)的某一層次相聯(lián)系的，高

30、層次故障可以由低層次的故障所引起，而低層次故障必定引起高層次故障。(2)相關性:這是故障的“橫向性”，是由系統(tǒng)各元素之間的聯(lián)系所決定的。某個子系統(tǒng)的故障常常是與之相關的子系統(tǒng)或者下一級子系統(tǒng)故障傳播所至，從而表現(xiàn)出相關性。故障傳播途徑的不唯一，又引起了多故障并存。(3)時間性:系統(tǒng)故障的產(chǎn)生與表現(xiàn)于時間有關，從原發(fā)性故障到系統(tǒng)級故障的發(fā)生、發(fā)展及形成，是一個由量變到質變的過程。這一特性提示人們，故障可以早期預測、診斷，達到“防患于未然”的目的。(4)不確定性:使系統(tǒng)故障的一個重要特性，具有模糊性和隨機性兩種特征。引起故障不確定性的因素有很多方面，如系統(tǒng)的元素特性和聯(lián)系特性的不確定性、狀態(tài)描述方

31、法與工作環(huán)境的不確定性等等。復雜系統(tǒng)診斷問題的不確定性，是基于知識的診斷推理的一個重要研究內(nèi)容。3.3 本章小結本章主要分析了專家系統(tǒng)的研究對象:汽車的故障。詳細分析汽車故障，了解故障產(chǎn)生的原因、背景以及特點，有助于更好的建立汽車故障診斷的知識庫和相關的推理策略。4. 汽車故障診斷專家系統(tǒng)設計與開發(fā)4.1 汽車故障診斷專家系統(tǒng)的一般結構開發(fā)這樣一個系統(tǒng)，首先需要將汽車維修領域專家的大量實際維修經(jīng)驗進行匯總和提煉，編成知識庫，構成專家系統(tǒng)的核心部分；其次需要建立推理機，推理機可根據(jù)用戶提供的故障跡象或異?，F(xiàn)象，利用知識庫中的知識，按一定推理策略進行推理，進而得出診斷結果。專家系統(tǒng)結構一般包括6部

32、分：知識庫、推理機、綜合數(shù)據(jù)庫、人機接口、解釋程序和知識庫獲取程序，該專家系統(tǒng)的結構如圖所示6。人 機 接 口專 家用 戶推理機知識庫獲取程序解釋程序綜合數(shù)據(jù)庫知識庫圖1. 專家系統(tǒng)一般結構4.2 基于Delphi的汽車故障診斷專家系統(tǒng)的特點基于Delphi7.0開發(fā)的本故障診斷專家系統(tǒng)能滿足如下要求：（1）有良好的擴充性；（2）易于發(fā)布，容量不能過大，即知識庫中的素材不能占用過大存儲空間；（3）人機交互，便于操作使用；（4）高效的推理策略，完善的數(shù)據(jù)庫和圖像庫。（5）數(shù)據(jù)庫是在DBMS（數(shù)據(jù)庫管理系統(tǒng)）集中管理下，具有較高的數(shù)據(jù)獨立性，較少的冗余，并且相互間有聯(lián)系的文件集合7。它不僅能反映數(shù)

33、據(jù)的本身，而且能夠反映數(shù)據(jù)之間的聯(lián)系，在多個表的之間進行操作。數(shù)據(jù)庫還具有數(shù)據(jù)獨立性，數(shù)據(jù)安全性，數(shù)據(jù)完整性，集中管理，控制冗余等。利用數(shù)據(jù)庫構建專家系統(tǒng)的知識庫，具有存儲規(guī)則多，查詢方便、快捷，且便于維護。在系統(tǒng)的應用程序開發(fā)過程中，主要采用分模塊開發(fā)的調用程序結構，使其便于集體開發(fā)和軟件功能的擴展。其總體結構方框圖如圖2 所示。圖2. 總體結構方案圖主菜單規(guī)則故障診斷實例故障診斷知識庫輔助系統(tǒng)發(fā)動機系統(tǒng)底盤系統(tǒng)電器設備系統(tǒng)規(guī)則庫實例庫系統(tǒng)介紹使用說明發(fā)動機系統(tǒng)底盤系統(tǒng)電器設備系統(tǒng)4.3 故障診斷專家系統(tǒng)各模塊的建立4.3.1 故障診斷模塊故障診斷是專家系統(tǒng)的重要組成部分，直接影響到用戶對專

34、家系統(tǒng)使用和維護的方便以及其功能的發(fā)揮。因此，構建該專家系統(tǒng)的時候，將以用戶使用的簡便性、可操作性為目標，針對這一要求，選用了可視化編程語言Object Pascal來編制程序。該專家系統(tǒng)將充分體現(xiàn)人性化，是圖文并茂的完全診斷手冊，在診斷中，配以相應的實物原形圖來表示故障發(fā)生的具體部位以及維修使用的工具，并用相應的文字說明，讓使用維修人員能夠很快地識別，做出反應。其用戶界面友好、靈活，由彈出菜單和屏幕菜單回答系統(tǒng)來實現(xiàn)，數(shù)據(jù)輸入根據(jù)屏幕提出的問題由鍵盤響應來回答。該模塊以人機對話的方式搜索用戶所掌握的故障線索，模仿維修專家的診斷思路進行推理，進而一步步找出故障部件及原因，其診斷流程框圖如圖3所

35、示。根據(jù)汽車的具體情況將診斷模塊分為三個部分，即發(fā)動機系統(tǒng)、底盤系統(tǒng)、電器設備系統(tǒng)。故障現(xiàn)象選擇屏幕提示用戶回答是否找到故障原因推理分析診斷報告NY圖3. 診斷流程圖以發(fā)動機系統(tǒng)為例，在建立發(fā)動機不能發(fā)動診斷子模塊時，針對其故障特點，采用了較形象的樹狀圖示診斷方案。當進行診斷時，系統(tǒng)根據(jù)用戶對詢問的回答確定下一步顯示的樹枝，直到診斷進行到樹葉（找出故障原因）為止保存。此時，預覽診斷按鈕由失效變?yōu)榭捎茫ㄎ丛\斷完則為失效狀態(tài)），按下去后可彈出診斷報告屏幕，其人機界面見。(a) 故障診斷界面（b）診斷報告界面發(fā)動機不能發(fā)動有著車現(xiàn)象無著車現(xiàn)象確定起動困難此項目正常繼續(xù)診斷保存診斷結果預覽診斷報告診斷

36、報告界面(c)故障診斷流程圖圖4 故障診斷界面及流程圖逐步尋找故障零部件此故障現(xiàn)象的原因及排除方案按返回按鈕繼續(xù)診斷單選故障現(xiàn)象相應代碼如下：procedure TFDESForm.sure4_ButtonClick(Sender: TObject);/確定按鈕響應事件beginshow4_Edit.text:=發(fā)動機不能啟動，+ RadioGroup1.ItemsRadioGroup1.ItemIndex;Table1.Active:=True;/數(shù)據(jù)庫表1生效Table1.First;continue4_Button.Enabled:=True;/此項目正常繼續(xù)診斷按鈕可用save4_Bu

37、tton.Enabled:=True;i:=1;case RadioGroup1.ItemIndex of1: Table1.MoveBy(1);2: Table1.MoveBy(3);end;end;procedure TFDESForm.continue4_ButtonClick(Sender: TObject);/ 此項目正常繼續(xù)診斷按鈕響應事件beginsave4_Button.Enabled:=True;case RadioGroup1.ItemIndex of0: begin if i2 then Table1.Next else continue4_Button.Enabled:

38、=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:=(故障現(xiàn)象: + show4_Edit.Text +#13#10+ 故障

39、原因：+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;/預覽診斷報告按鈕生效a:=a+8;end;（1）診斷

40、軟件設計中的難點分析實現(xiàn)此故障樹診斷法，首先在表單上畫好所有的樹狀圖，然后根據(jù)每個按鈕、詢問文件之間的邏輯關系，編寫按下此按鈕時要執(zhí)行的動作（OnClick屬性）。（2）錯選反悔功能的設計有時，當用戶按確定按鈕后，在已顯示出了相應的診斷內(nèi)容后，發(fā)現(xiàn)選錯了，反悔并回過來按下其上一級或上幾級的某個按鈕。系統(tǒng)必須允許這種錯誤的發(fā)生，并實現(xiàn)他的要求，即在每個按鈕的OnClick屬性內(nèi)加入一些語句，使除了應該顯示的內(nèi)容Enabled:=true（可見）外，其余對象的屬性均變回Enabled:=false（不可見），這就需要逐條的控制每一對象。用戶在診斷過程中，允許實現(xiàn)瀏覽功能。診斷完畢后還允許對診斷報告

41、進行修改，以得到最佳的診斷效果。診斷過程中，以單擊保存診斷結果將所對應的內(nèi)容作為一個記錄保存在診斷報告中，診斷完畢后即完成一份完整的診斷報告。當對某一次診斷結果的保存有誤，允許執(zhí)行取消命令取消單次的保存結果，也可在診斷報告界面進行人工修改。取消按鈕的代碼：procedure TFDESForm.concel4_ButtonClick(Sender: TObject);beginfor n:=a downto a-8 doMemo1.Lines n:=;a:=a-8 ;end;4.3.2 故障診斷知識庫的建立該汽車故障診斷專家系統(tǒng)采用融合實例（case）與規(guī)則（rule）的推理方法，為更好地對知

42、識庫進行管理和維護，把知識庫分成2部分：實例庫和規(guī)則庫。其中實例庫是指以前曾成功解決過的問題或案例。結合汽車結構特點，將實例庫分為3個子庫：發(fā)動機庫、底盤庫以及汽車電器庫。每一個子庫又劃分為若干個小塊，每一小塊對應一張表。如可將汽車發(fā)動機部分劃分為：發(fā)動機不能發(fā)動、發(fā)動機怠速不良、發(fā)動機無力、發(fā)動機溫度油耗異常、發(fā)動機異響這5塊。所以，汽車發(fā)動機子庫包含5張表，每張表記錄了該塊的所有故障診斷實例。每個診斷實例看作是一條記錄，診斷實例所需要的參數(shù)為一個字段，具體的實例表示方法如表1所示。表1. 發(fā)動機不能發(fā)動的實例表enginestart車型故障現(xiàn)象故障原因排除方法圖片1桑塔納2000（時代超人

43、）起動機運轉正常，但不能著車汽油泵不運轉拆下汽油泵分解檢查，泵線圈燒毀，更換。規(guī)則是表達由一定的前提推出確定的結論的知識，故障診斷中的規(guī)則一般都是領域專家從長期的實踐經(jīng)驗中得出的規(guī)律性的結論。規(guī)則的一般形式是if x then y其中x表示前提，y表示結論，如同實例庫一樣，規(guī)則庫也分為發(fā)動機、底盤和電器3 部分，每一部分又劃分為若干塊，每一塊對應一個規(guī)則表，規(guī)則采用表2的形式記錄。表2. 發(fā)動機怠速不良的規(guī)則表idleengine故障現(xiàn)象故障原因排除方法規(guī)則率1怠速不穩(wěn)1、電控系統(tǒng)異常檢查怠速控制電機及電位計是否異常。正常則在游車狀態(tài)下，觀察節(jié)氣門是否能進行反饋調節(jié)，能說明怠速控制系統(tǒng)正常。用

44、傳感器模擬測試儀模擬空氣流量計，如怠速不穩(wěn)現(xiàn)象消失，則更換空氣流量計。0.822、進氣管漏氣進氣管處加裝壓力計和增壓器，給進氣管加氣增壓到25pa,保持一段時間后，觀察其是否有下降趨勢，有則說明漏氣。仔細檢查其漏氣位置，針對不同位置采取不同的補救方案。 知識庫的基本管理知識庫的管理是汽車故障診斷專家系統(tǒng)的重要組成部分，故障診斷專家系統(tǒng)運行過程中所需要的知識都是由知識庫來提供的，系統(tǒng)的推理、決策都是圍繞著運用知識庫中存儲的知識進行匹配、決策、歸納、演算等操作，從而得到最終結果8。因此，從某種意義上來說，知識庫建造的好壞直接影響到整個汽車故障診斷專家系統(tǒng)是否成功，而構造高效、完善的

45、知識庫將會對整個汽車故障診斷專家系統(tǒng)性能的提高起到非常重要的作用。其編輯故障實例界面見圖5：圖5 編輯故障實例界面（1）知識的檢驗管理正確性檢驗：主要是對故障診斷知識庫中的知識進行語法檢查，對語法檢查不合格的記錄，將其狀態(tài)設為不激活狀態(tài)。為實現(xiàn)對知識庫中不合法的知識進行檢驗，本系統(tǒng)采用SQL設計的關系數(shù)據(jù)庫中的觸發(fā)器在新知識增加時自動、及時地檢驗知識的合法性，保證了將這些錯誤消除在萌發(fā)階段。多義性檢驗：對規(guī)則庫中的規(guī)則來說，當已經(jīng)給出完備的規(guī)則前提時應得到唯一的結論。如果知識庫中存在前提相同而結論不同的規(guī)則就出現(xiàn)了多義性的錯誤。當發(fā)現(xiàn)此類錯誤后，知識庫管理系統(tǒng)將這些記錄提交給領域專家進行處理。

46、冗余檢驗：是檢查知識庫中是否存在完全相同或非常相似的記錄，特別是在規(guī)則庫中要檢查是否存在結論相同而規(guī)則前提中除有些條件互反外其余的條件都相同或等價的規(guī)則。如有，則將這些知識進行合并，消除知識冗余。（2）知識的存入知識的存儲是將經(jīng)過領域專家認可的知識輸入到知識庫中去，在輸入知識前，須明確將知識添加到知識庫中哪張表中去。通過選擇知識庫里設定的索引機制進入該表的操作界面，點擊輸入子菜單即可對知識進行輸入。本系統(tǒng)在編輯故障實例界面中添加按鈕即對知識的存入，在知識的存入之前要判斷此實例屬發(fā)動機系統(tǒng)、底盤系統(tǒng)、電器設備系統(tǒng)中那類故障，進入該界面后只有故障類型選擇是可用，其他按鈕處于無效狀態(tài)，選擇了故障類型

47、即選擇將實例添加到知識庫相應的表中。實現(xiàn)這一功能的代碼：procedure TFDESForm.ComboBox4Change(Sender: TObject);beginTable7.Active :=false;case ComboBox4.ItemIndex of0:Table7.TableName :=E:delphiDatabase Desktopenginecase.db;1:Table7.TableName :=E:delphiDatabase Desktopchassiscase.db;2:Table7.TableName :=E:delphiDatabase Desktopw

48、iringcase.db;end;Table7.Active :=true;modify_Button.Enabled :=true;delete_Button.Enabled :=true;add_Button.Enabled :=true;end;（3）知識的修改和刪除若發(fā)現(xiàn)一些知識誤差很大或錯誤很多，可選擇要刪除或修改的記錄，再點擊刪除或修改按鈕。本系統(tǒng)中利用DBNavigator控件對相應的實例表進行瀏覽，發(fā)現(xiàn)錯誤或需修改的記錄時，點擊刪除或修改按鈕，如有操作失誤可選擇取消按鈕；各按鈕相應代碼：procedure TFDESForm.add_ButtonClick(Sender: TO

49、bject);/添加按鈕響應事件beginTable7.Append ;modify_Button.Enabled :=false;delete_Button.Enabled :=false;ok_Button.Enabled :=true;cancel_Button.Enabled :=true;end;procedure TFDESForm.modify_ButtonClick(Sender: TObject); /修改按鈕響應事件beginTable7.Edit ;add_Button.Enabled :=false;delete_Button.Enabled :=false;ok_Bu

50、tton.Enabled :=true;cancel_Button.Enabled :=true;end;procedure TFDESForm.delete_ButtonClick(Sender: TObject); /刪除按鈕響應事件beginTable7.delete ;modify_Button.Enabled :=false;add_Button.Enabled :=false;ok_Button.Enabled :=true;cancel_Button.Enabled :=true;end;procedure TFDESForm.cancel_ButtonClick(Sender:

51、 TObject); /取消按鈕響應事件beginTable7.cancel;modify_Button.Enabled :=true;delete_Button.Enabled :=true;add_Button.Enabled :=true;end;procedure TFDESForm.ok_ButtonClick(Sender: TObject); /確定按鈕響應事件beginTable7.Edit;Table7.post;/知識表刷新modify_Button.Enabled :=true;delete_Button.Enabled :=true;add_Button.Enabled

52、 :=true;end;4.3.4 知識庫檢索模塊知識庫部分是整個系統(tǒng)的知識源，是系統(tǒng)最重要的組成部分之一。根據(jù)汽車知識極其龐大而復雜的特點。與知識庫模塊相應的工作界面也采用了交互式的關聯(lián)調用方式。各工作界面對應相應的知識庫，又相互可調用。由于采用了結構化編程，既增加了系統(tǒng)的靈活性，也使整個系統(tǒng)更為層次分明。整個工作界面網(wǎng)絡如所示，整個系統(tǒng)的工作環(huán)境是一個相互連接的網(wǎng)狀結構，在這個工作界面網(wǎng)絡中，用戶可以簡單的在各個部分數(shù)據(jù)中跳轉，而無須自己關心所在的數(shù)據(jù)庫層次，同時，各知識界面均與檢索界面、打印界面緊密連接，數(shù)據(jù)獲取更方便快捷。圖6 整體界面工作網(wǎng)絡圖整體界面軟件簡介故障診斷編輯故障實例編輯

53、診斷報告規(guī)則故障診斷故障實例診斷電氣設備故障底盤故障發(fā)動機系統(tǒng)發(fā)動機溫度油耗異常發(fā)動機怠速不良發(fā)動機不能起動發(fā)動機無力發(fā)動機異響電氣設備故障底盤故障發(fā)動機系統(tǒng)保存在相應的庫中知識檢索模塊是整個系統(tǒng)的一個中心環(huán)節(jié)。因為，衡量一個知識庫系統(tǒng)是否成功，很大程度上決定于其檢索功能的快速性、完善性。根據(jù)汽車數(shù)據(jù)記錄條目量大、數(shù)據(jù)字段數(shù)多、字段占用字節(jié)量大的特點，汽車數(shù)據(jù)庫系統(tǒng)采用了視圖檢索的新方式。通過工作界面獲取檢索條件，以參數(shù)形式傳遞給視圖，利用視圖進行檢索，再由視圖生成檢索結果的臨時數(shù)據(jù)表。將臨時數(shù)據(jù)表映射到檢索界面中，實現(xiàn)檢索結果的顯示。這種方式使用了結構化查詢SQL方式的視圖檢索，檢索條件的傳

54、輸與判別較為簡易，并且，在系統(tǒng)中還利用了視圖的臨時表可發(fā)送更新性質，增加了檢索結果編輯功能9。用戶可先利用檢索界面檢索到所需的數(shù)據(jù)記錄，并利用該功能對數(shù)據(jù)進行修改，發(fā)送到原數(shù)據(jù)表中，更好的實現(xiàn)數(shù)據(jù)管理。4.3.5 推理機制推理機制是應用知識的關鍵，一般推理機制要求達到：1根據(jù)環(huán)境選擇可用的知識；2正確應用知識；3當推理受阻時，能有效地解決問題；4能恰當?shù)亟K止推理過程。在上述技術的基礎上，設計了本系統(tǒng)的推理機制。問題提交有2種方式：通過人機交互，由維修人員選擇汽車故障信息，提交給系統(tǒng)處理；由數(shù)據(jù)驅動，即系統(tǒng)在不斷地檢測汽車維修電子檔案系統(tǒng)中的數(shù)據(jù)，與正常數(shù)據(jù)進行比較，一旦發(fā)現(xiàn)異常，則啟動推理機，根據(jù)當前數(shù)據(jù)進行診斷推理10。當實例匹配成功時，根據(jù)規(guī)則對生成初步維修方案進行修改以適應當前案例；當實例匹配不成功時，則啟動規(guī)則搜索算法，應用知識庫中的知識來生成初步故障處理方案，由維修技師審查確認后，生成維修方案。4.4 結論本應用程序結合了Delphi7.0 數(shù)據(jù)庫的