基于CDMA和CAN總線的車輛遠程故障診斷系統

　　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

　　發動機噴油嘴故障嚴重，需馬上修理。

　　推理機設計時本系統采用了兩級es推理控制策略。結合領域知識，將總體故障分析求解任務分解為不同的子任務，如發動機故障分析子任務、輪胎故障診斷子任務等。每個子任務有各自的目標求解變量，服從不同的求解方法，彼此之間既相互獨立又存在著相互聯系。通過正向推理求解其目標變量，并將所求結果顯示給車主。

　　而汽車故障診斷的各子任務間是有一定的依賴關系的，各子任務的求解是有一定的前提條件的，例如，氣缸噴油嘴子任務的求解必須在油嘴線路電壓已知的前提下才能進行，因而，各求解器中都設置了激活條件，只有滿足了這些條件，求解器才能被激活從而進行目標變量的求解。元級推理機利用此關聯對象集信息按一定的順序激活相關的求解器進行重新推理。

　　解釋機制通過與推理機輸出的數據， 回答用戶提出的how、why、what、whether等問題。

3.2 車載故障診斷單元軟件設計

　　車載故障診斷單元主要負責車載故障數據的讀取，并通過無線網絡（）將故障碼實時送到遠程車輛信息技術服務中心，簡單的故障信息，如：一般故障（不用馬上處理），故障（需馬上修理），嚴重故障（需請求交通拯救）需要及時反饋給車主（包括以文字的方式反饋到車主車載屏上，更緊急的時候通過語音或者視頻對話來溝通）。更詳細的故障情況車主可以通過移動電腦或者移動電話訪問相關遠程車輛信息技術服務中心的網站來獲取。

　　車載故障診斷單元的主程序在執行完初始化功能，再根據當前故障狀態位的值設置定時中斷的時間后，然后就進入低功耗模式。單元讀取故障碼和其他運行數據，以及這些數據的傳輸都放置在中斷程序，中斷結束立即進入低功耗模式。車輛故障狀態位正常時，可取60min定時中斷一次，調用crc-16校驗計算執行庫后，通過無線方式發送給遠程車輛信息技術服務中心。在故障狀態位出現多位數值為“1”時，縮短定時中斷時間，增加數據采樣及發送頻率。定時中斷程序流程如圖3所示：

　　數據接收程序在主程序完成初始化功能后，模塊進入等待SPI數據工作狀態。在接收到一個數據幀，crc校驗（采用查表法實現，減小微控制器cpu占用時間）和車輛信息技術服務中心id判斷無誤后，送液晶顯示并點亮相應的指示燈以表示各模塊工作正常。當某個模塊出現故障時，啟動led閃爍警告或蜂鳴器報警。程序流程圖如圖4所示。