本發(fā)明涉及汽車電子檢測術領域,尤其涉及一種汽車模擬通訊協(xié)議解析器及其解析方法。
背景技術:
汽車診斷是汽車行業(yè)必不可少的環(huán)節(jié),而xml資源與程序開發(fā)方式是目前基于pc或安卓等系統(tǒng)診斷儀器設置的主流開發(fā)方式,隨著汽車的保有量不斷提高,與汽車測試開發(fā)相關的車載診斷儀器也得到了快速地發(fā)展,“車載診斷系統(tǒng):on-boarddiagnostic,縮寫為:obd”。車載診斷儀器(obd)可以隨時監(jiān)控發(fā)動機的運行狀況,一旦發(fā)現(xiàn)有可能引起故障的情況,會馬上發(fā)出警示,因而成為輕型汽車的必備工具。一般地,在汽車上設有用于記錄汽車發(fā)動機運行狀況和及其各個處理系統(tǒng)各個時間段數(shù)據(jù)的obd接口,通過采用汽車故障診斷儀與汽車上的obd接口連接讀取數(shù)據(jù),然后再通過數(shù)據(jù)線與電腦連接,顯示所讀取的數(shù)據(jù)。另外,工程師在對汽車故障測試開發(fā)時往往需要將汽車故障診斷儀與汽車ecu模擬器、電腦和外接電源連接起來使用,如圖1所示,在汽車診斷軟件開發(fā)過程中最主要的工作量是填寫xml資源,xml資源是汽車診斷軟件的重要組成部分,少量的中斷及處理程序代碼加上不同類似的xml資源即可組成覆蓋成千上萬品牌車型的診斷軟件,然而,填寫xml資源又是一個費時且麻煩的工作,手動填寫效率太低,研發(fā)人員還容易疲勞,容易出錯,與此同時,各新廠商、新型號汽車的不斷生產(chǎn),診斷儀的所包含的汽車ecu模擬器故障信息將會越來越多,而且,各新廠商、新型號汽車會存在不兼容的情況,因此,故障診斷信息會占用存儲空間將會更大,浪費更多的診斷儀存儲空間,為此,開發(fā)了一款能夠自動生成xml資源和自動生成模擬汽車ecu軟件的資源的輔助開發(fā)工具—協(xié)議解析器,達到不斷擴大診斷開發(fā)對象的目的,以能夠大大的縮短了汽車診斷開發(fā)過程中填寫xml資源和汽車ecu模擬資源的時間,提高了效率和準確性。
技術實現(xiàn)要素:
本發(fā)明的目的在于提供一種汽車模擬通訊協(xié)議解析器及其解析方法,根據(jù)本發(fā)明的模擬通訊協(xié)議解析器能夠大大的縮短了汽車診斷開發(fā)過程中填寫xml資源和汽車ecu模擬資源的時間,提高了效率和準確性,為了實現(xiàn)上述目的,本發(fā)明采用以下技術效果:
根據(jù)本發(fā)明的一方面提供了一種汽車模擬通訊協(xié)議解析器,其特征在于:包括解析端、診斷端和診斷協(xié)議接口,所述診斷端用于將所述解析端發(fā)來的請求診斷協(xié)議的幀序列格式與所述診斷協(xié)議接口讀取的協(xié)議數(shù)據(jù)源的格式進行比較判斷,然后將比較判斷的結果進行測試并生成診斷測試數(shù)據(jù),該診斷端同時將診斷測試數(shù)據(jù)返回給所述解析端進行協(xié)議解析和可視化顯示,該解析端將協(xié)議解析后生成的數(shù)據(jù)進行打包,并作為協(xié)議幀序列數(shù)據(jù)發(fā)送給診斷端。
優(yōu)選的,所述解析端包括xml生成模塊、發(fā)送模塊、協(xié)議整理模塊、響應處理模塊、接收模塊、發(fā)送模塊、幀標志模塊和時鐘模塊,所述接收模塊用于接收診斷端發(fā)出請求診斷的診斷測試數(shù)據(jù)進行緩存和預處理并發(fā)送至響應處理模塊,所述響應處理模塊用于對接收到的響應幀按照幀的格式進行解析和判斷,并將解析結果進行可視化顯示以及發(fā)送給所述協(xié)議整理模塊進行協(xié)議校驗,該協(xié)議整理模塊對解析結果進行協(xié)議校驗所述響應幀是否正確并輸出協(xié)議校驗結果,所述xml生成模塊用于測試協(xié)議整理模塊輸出的協(xié)議校驗結果與幀標志模塊輸出的幀標志位,并判斷每幀數(shù)據(jù)是否正確,再根據(jù)每幀標志位判斷每幀數(shù)據(jù)的合法性,所述發(fā)送模塊將xml生成模塊測試的協(xié)議數(shù)據(jù)進行打包并按照時鐘模塊產(chǎn)生的時鐘源定時向診斷端發(fā)送協(xié)議幀序列。
優(yōu)選的,所述診斷協(xié)議接口為obd通訊接口協(xié)議。
優(yōu)選的,所述診斷端包括協(xié)議存儲模塊以及與協(xié)議存儲模塊相互通信連接的的汽車ecu模擬器,協(xié)議存儲模的物理層分別與解析端的收發(fā)端口、汽車ecu模擬器的協(xié)議接口實現(xiàn)驅動控制。
根據(jù)本發(fā)明的另一方面,提供了一種汽車模擬通訊協(xié)議解析器的解析方法,包括以下步驟:
步驟一:解析端向診斷端發(fā)出診斷協(xié)議,并判解析端是否需要進行協(xié)議解析請求,若有解析請求,將解析的協(xié)議數(shù)據(jù)結果通過可視化界面顯示,并通過可視化界面增加協(xié)議幀序列的協(xié)議識別符,然后根據(jù)協(xié)議識別符求解協(xié)議數(shù)據(jù);
步驟二:診斷端向解析端不同的功能模塊增加協(xié)議識別符,判斷所解析的每個功能模塊是否要增加特殊功能識別符并求解協(xié)議數(shù)據(jù)文件,若未添加特殊功能識別符則直接進行協(xié)議識別符求解協(xié)議數(shù)據(jù)文件,若已添加特殊功能識別符,則設置特殊識別符號的讀取方式,再根據(jù)特殊識別符求解協(xié)議數(shù)據(jù)文件;
步驟三:讀取不同功能模塊的特殊功能識別符,根據(jù)不同功能模塊的提示信息修改識別符,返回步驟二,否則根據(jù)解析的結構生成通用的標記語言并輸出解析文件;
優(yōu)選的,所述步驟二中求解協(xié)議數(shù)據(jù)文件包括:
b1、解析端接收的協(xié)議數(shù)據(jù)文件與診斷端中協(xié)議存儲模塊預設的協(xié)議特征進行判斷是否有匹配的協(xié)議,所述協(xié)議存儲模塊含多種協(xié)議數(shù)據(jù)規(guī)范文本;
b2、若有匹配協(xié)議,則按照所述預設的協(xié)議特征所對應的協(xié)議規(guī)范文本進行協(xié)議解析;否則,根據(jù)所述解析端所提供的協(xié)議規(guī)范文本運行腳本并自動生成xml資源,并將所述生成的xml資源保存到所述協(xié)議存儲模塊中。
優(yōu)選的,所述xml資源包含了數(shù)據(jù)流的名稱、協(xié)議轉換計算公式、數(shù)據(jù)顯示方式、顯示單位以及對應的命令數(shù)據(jù)。
本發(fā)明采用了上述技術方案,本發(fā)明具有以下技術效果:
(1)、本發(fā)明的汽車模擬通訊協(xié)議解析器能夠快速收集汽車的故障信息,并能自動模擬汽車ecu通信協(xié)議命令回復測試,自動生成模擬汽車ecu回復命令,大大縮短了汽車ecu模擬時間,提高汽車診斷的效率和準確率,具有很好的使用價值。能夠達到不斷擴大診斷對象的目的,以能夠大大的縮短了汽車診斷開發(fā)過程中填寫xml資源的時間,提高了效率和準確性,降低了開發(fā)成本和調試成本、縮短了開發(fā)周期。
(2)、本發(fā)明所述的汽車模擬通訊協(xié)議解析器與汽車ecu之間形成汽車通訊的模擬信號,避免了要通過大量的線束以及開發(fā)額外的診斷儀與汽車ecu之間連接才能完成通訊診斷的問題,減少了線束的使用,提高了解析與診斷測試效率。
附圖說明
圖1是現(xiàn)有的模擬汽車故障診斷原理結構圖;
圖2是本發(fā)明的一種汽車模擬通訊協(xié)議解析器的原理圖;
圖3是本發(fā)明的一種汽車模擬通訊協(xié)議解析器的解析方法流程圖;
具體實施方式
為使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白,以下參照附圖并舉出優(yōu)選實施例,對本發(fā)明進一步詳細說明。然而,需要說明的是,說明書中列出的許多細節(jié)僅僅是為了使讀者對本發(fā)明的一個或多個方面有一個透徹的理解,即便沒有這些特定的細節(jié)也可以實現(xiàn)本發(fā)明的這些方面。
如圖2所示,根據(jù)本發(fā)明的一方面,提供了一種汽車模擬通訊協(xié)議解析器,包括解析端、診斷端和診斷協(xié)議接口,所述診斷協(xié)議接口為obd通訊接口協(xié)議,所述診斷端用于將所述解析端發(fā)來的請求診斷協(xié)議的幀序列格式與所述診斷協(xié)議接口讀取的協(xié)議數(shù)據(jù)源的格式進行比較判斷,然后將比較判斷的結果進行測試并生成診斷測試數(shù)據(jù),該診斷端將比較判斷的結果生成數(shù)據(jù)報文后進行測試,再將測試結果生成診斷測試數(shù)據(jù),該診斷端同時將診斷測試數(shù)據(jù)返回給所述解析端進行協(xié)議解析和可視化顯示,該解析端將協(xié)議解析后生成的數(shù)據(jù)進行打包,并將打包的數(shù)據(jù)作為協(xié)議幀序列數(shù)據(jù)發(fā)送給診斷端。
在本發(fā)明中,如圖2所示,所述解析端包括xml生成模塊、發(fā)送模塊、協(xié)議整理模塊、響應處理模塊、接收模塊、發(fā)送模塊、幀標志模塊和時鐘模塊,所述接收模塊用于接收診斷端發(fā)出請求診斷的診斷測試數(shù)據(jù)進行緩存和預處理并發(fā)送至響應處理模塊,所述響應處理模塊用于對接收到的響應幀按照幀的格式進行解析和判斷,并將解析結果進行可視化顯示以及發(fā)送給所述協(xié)議整理模塊進行協(xié)議校驗,該協(xié)議整理模塊對解析結果進行協(xié)議校驗所述響應幀是否正確并輸出協(xié)議校驗結果,所述xml生成模塊用于測試協(xié)議整理模塊輸出的協(xié)議校驗結果與幀標志模塊輸出的幀標志位,并判斷每幀數(shù)據(jù)是否正確,再根據(jù)每幀標志位判斷每幀數(shù)據(jù)的合法性,所述發(fā)送模塊將xml生成模塊測試的協(xié)議數(shù)據(jù)進行打包并按照時鐘模塊產(chǎn)生的時鐘源定時向診斷端發(fā)送協(xié)議幀序列;協(xié)議整理模塊將每幀數(shù)據(jù)都會進行校驗測試正確與否,該協(xié)議整理模塊會根據(jù)實際情況在每幀序數(shù)據(jù)或幀序列數(shù)據(jù)的幀標志位前增加特殊識別符號判斷,并判斷每個特殊識別符是否為合法性,其中特殊識別符是指跟讀取故障碼、清除故障碼、讀取數(shù)據(jù)流,元件測試功能將執(zhí)行特殊識別符測試。
所述診斷端包括協(xié)議存儲模塊以及與協(xié)議存儲模塊相互通信連接的的汽車ecu模擬器,協(xié)議存儲模的物理層分別與解析端的收發(fā)端口、汽車ecu模擬器的協(xié)議接口實現(xiàn)驅動控制,物理層負責將協(xié)議數(shù)據(jù)組織成幀,并完成協(xié)議數(shù)據(jù)源的格式進行比較判斷,然后將比較判斷的結果進行測試并生成診斷測試數(shù)據(jù),網(wǎng)絡層對收到來自物理層的診斷測試數(shù)據(jù),并解析出相應的協(xié)議數(shù)據(jù)信息的傳輸路徑,數(shù)據(jù)傳輸層把每個協(xié)議數(shù)據(jù)信息綁帶一個幀標志位后傳送給應用層進行存儲。發(fā)送模塊將xml生成模塊測試的協(xié)議數(shù)據(jù)進行打包并按照時鐘模塊產(chǎn)生的時鐘源定時向診斷端發(fā)送協(xié)議幀序列,根據(jù)協(xié)議的請求并將協(xié)議數(shù)據(jù)組織打包好后,從協(xié)議存儲模塊的最高層向下逐層傳送,分別經(jīng)過應用層、數(shù)據(jù)傳輸層、網(wǎng)絡層、物理層進行逐層打包封裝,最后到達物理層實現(xiàn)協(xié)議請求傳輸。當應用層數(shù)據(jù)封裝好后,每層將協(xié)議數(shù)據(jù)按規(guī)定幀轉交給上一層,當?shù)竭_應用層時,把最終的協(xié)議數(shù)據(jù)信息取出,這樣就分別對物理層、網(wǎng)絡層、數(shù)據(jù)傳輸層和應用層進行了逐層分析和解析,也完成了整個解析過程。
如圖3所示,根據(jù)本發(fā)明的另一方面,提供了一種汽車模擬通訊協(xié)議解析器的解析方法,包括以下步驟:
步驟一:解析端向診斷端發(fā)出診斷協(xié)議,并判解析端是否需要進行協(xié)議解析請求,若有解析請求,將解析的協(xié)議數(shù)據(jù)結果通過可視化界面顯示,并通過可視化界面增加協(xié)議幀序列的協(xié)議識別符,然后根據(jù)協(xié)議識別符求解協(xié)議數(shù)據(jù);
步驟二:診斷端向解析端不同的功能模塊增加協(xié)議識別符,判斷所解析的每個功能模塊是否要增加特殊功能識別符并求解協(xié)議數(shù)據(jù)文件,若未添加特殊功能識別符則直接進行協(xié)議識別符求解協(xié)議數(shù)據(jù)文件,若已添加特殊功能識別符,則設置特殊識別符號的讀取方式,再根據(jù)特殊識別符求解協(xié)議數(shù)據(jù)文件;
步驟三:診斷端讀取不同功能模塊的特殊功能識別符,根據(jù)不同功能模塊的提示信息修改識別符,返回步驟二,否則根據(jù)解析的結構生成通用的標記語言并輸出解析文件;
在本發(fā)明中,所述步驟二中求解協(xié)議數(shù)據(jù)文件包括:
b1、解析端接收的協(xié)議數(shù)據(jù)文件與診斷端中協(xié)議存儲模塊預設的協(xié)議特征進行判斷是否有匹配的協(xié)議,所述協(xié)議存儲模塊含多種協(xié)議數(shù)據(jù)規(guī)范文本,其中包括標準can協(xié)議文本、擴展can協(xié)議文本、kwp2000協(xié)議文本等協(xié)議文本;
b2、若有匹配協(xié)議,則按照所述預設的協(xié)議特征所對應的協(xié)議規(guī)范文本進行協(xié)議解析;否則,根據(jù)所述解析端所提供的協(xié)議規(guī)范文本運行腳本并自動生成xml資源,并將所述生成的xml資源保存到所述協(xié)議存儲模塊中,所述xml資源包含了數(shù)據(jù)流的名稱、協(xié)議轉換計算公式、數(shù)據(jù)顯示方式、顯示單位以及對應的命令數(shù)據(jù)。
本發(fā)明的解析器會將數(shù)據(jù)流名稱按照xml格式進行轉換的生成對應的命令數(shù)據(jù),xml資源格式完成了轉換之后,解析器的測試模塊將按照文件格式執(zhí)行轉換結果存儲,存儲方式是xml資源格式進行存儲的,因為命令數(shù)據(jù)生成是按照格式生成的,以滿足obd通訊協(xié)議接口實現(xiàn)外界設備進行讀取,因此,只要提供了目標文件的格式,解析器就能夠根據(jù)所約定的通訊協(xié)議對目標文件格式進行生成xml資源格式,在協(xié)議解析的過程中,只需要將協(xié)議按一定的格式進行整理和后續(xù)的格式要求轉換的工作,生成的格式將會是統(tǒng)一的,協(xié)議解析代碼可靠性高,可以減少大批量重復性的工作,能夠很大的提升工作效率,協(xié)議整理過程是對數(shù)據(jù)流(每幀序數(shù)據(jù)或幀序列數(shù)據(jù))的命令添加特殊識別符,然后對數(shù)據(jù)流名字、當前值、關鍵字節(jié)、協(xié)議轉換計算公式、數(shù)據(jù)顯示方式、顯示單位以及對應的命令數(shù)據(jù)前添加特殊標志,至此,格式整理就結束了,解析器會將命令按照特定格式進行生成,接著解析數(shù)據(jù)流名稱,解析器會將特殊識別符和對應的名稱進行匹配,接著根據(jù)數(shù)據(jù)流對應的關鍵字節(jié)和對應命令,生成對應的命令和關鍵字節(jié)的地址,設置診斷端發(fā)出診斷協(xié)議數(shù)據(jù),并判解解析端是否需要進行協(xié)議解析,將解析的協(xié)議數(shù)據(jù)通過可視化界面顯示。
以上所述僅是本發(fā)明的優(yōu)選實施方式,應當指出,對于本技術領域的普通技術人員來說,在不脫離本發(fā)明原理的前提下,還可以作出若干改進和潤飾,這些改進和潤飾也應視為本發(fā)明的保護范圍。