丁燕敏 劉 煒

（上海大學(xué) 計(jì)算機(jī)工程與科學(xué)學(xué)院，中國 上海200072）

1 汽車故障診斷簡介

1.1 汽車故障診斷技術(shù)發(fā)展簡介

汽車診斷技術(shù)發(fā)展至今，大致經(jīng)歷了以下三個階段：

第一階段為20 世紀(jì)70 年代至20 世紀(jì)80 年代初。 此階段中，汽車的維修方式主要通過維修人員通過摸、看、聽等傳統(tǒng)方式及個人經(jīng)驗(yàn)，通過純手工工具進(jìn)行故障判斷與排除。 純手工的診斷方法不但要求維修工程師具有一定的經(jīng)驗(yàn)， 而且最終診斷的準(zhǔn)確性也得不到保障。

第二階段為20 世紀(jì)80 年代初至20 世紀(jì)80 年代末，此階段開始使用故障診斷儀器進(jìn)行檢測。 此階段中，通過使用故障診斷儀器對故障信息進(jìn)行采集，雖有效提高了診斷效率與準(zhǔn)確性，但依然不能對汽車故障給出最終判斷。最終的診斷結(jié)果依舊需經(jīng)驗(yàn)豐富的汽車維修工程師給出。

第三階段為20 世紀(jì)80 年代末至今，此階段開始大量使用專業(yè)的綜合性故障診斷儀器進(jìn)行汽車故障檢測。專業(yè)的綜合性故障診斷儀器有著自動化、智能化等特點(diǎn)，它可完成從故障信息采集、故障判斷與定位、讀取/清除故障碼等一系列功能，減少了故障診斷對個人經(jīng)驗(yàn)的依賴性，提高了診斷的正確性及維修工程師的工作效率。

1.2 汽車診斷軟件簡介

現(xiàn)行的汽車診斷軟件由診斷系統(tǒng)基本平臺與業(yè)務(wù)數(shù)據(jù)庫構(gòu)成兩者構(gòu)成。診斷系統(tǒng)平臺提供車型選擇，數(shù)據(jù)通信，結(jié)果顯示等與診斷業(yè)務(wù)無關(guān)的基本功能；而診斷儀相關(guān)的業(yè)務(wù)則有由數(shù)據(jù)來驅(qū)動。其中，汽車常規(guī)診斷業(yè)務(wù)數(shù)據(jù)因具有一定的通用性，故此類業(yè)務(wù)可統(tǒng)一成系列數(shù)據(jù)表格模板；針對診斷業(yè)務(wù)中的特殊功能則通過特別定制的腳本實(shí)現(xiàn)。

2 方案設(shè)計(jì)

內(nèi)嵌于診斷軟件的腳本因其主要實(shí)現(xiàn)診斷業(yè)務(wù)中的特殊功能，所以其業(yè)務(wù)邏輯相對復(fù)雜。 根據(jù)實(shí)際現(xiàn)行經(jīng)驗(yàn)，完整生成一個最終可執(zhí)行腳本大致有以下幾個步驟：

根據(jù)診斷業(yè)務(wù)邏輯，畫出與其相對應(yīng)的流程圖：

1）依據(jù)流程圖，手動編寫腳本；

2）手動提取診斷業(yè)務(wù)相關(guān)的邏輯數(shù)據(jù)，生成數(shù)據(jù)文件；

3）手動編輯腳本測試文件；

4）編譯及修改腳本，生成最終可執(zhí)行腳本文件；

5）測試并修改腳本，生成最終提交腳本文件。

從上述的腳本開發(fā)流程中可以得出腳本開發(fā)中存在的以下幾個問題：

1）腳本開發(fā)過程中，由于大部分工作都需手工完成，可能會存在一定的人為錯誤；

2）當(dāng)需開發(fā)腳本的數(shù)量很龐大時(shí)，開發(fā)人員的效率不能保證。

綜上，若通過第三方工具替代原開發(fā)流程中部分的步驟，不但可大大減少腳本的開發(fā)時(shí)間，而且能有效提高最終的業(yè)務(wù)數(shù)據(jù)質(zhì)量。

2.1 方案概述

考慮到整個腳本開發(fā)中，除去最終實(shí)測外，只有診斷業(yè)務(wù)理解也即流程圖的繪制是一定需要人工參與的，而其余部分皆可由自動化工具替代。因此將流程圖作為切入點(diǎn)，軟件通過對流程圖的解析，自動生成腳本文件開發(fā)所需文件，軟件系統(tǒng)框圖如圖1 所示。首先，本工具會將腳本開發(fā)人員需按事先定義好的的流程圖規(guī)范繪制流程圖通過轉(zhuǎn)化器，生成相應(yīng)的腳本XML 文件，源流程圖中的每個圖形被對應(yīng)轉(zhuǎn)換成XML 中的node，每個node 都有其唯一對應(yīng)的ID。 隨后，轉(zhuǎn)化生成后的腳本XML 文件與事先定義的腳本語言規(guī)范配置XML 文件一同被系統(tǒng)解析器解析，生成可執(zhí)行的腳本文件、腳本驗(yàn)證時(shí)的測試文件及診斷業(yè)務(wù)數(shù)據(jù)文件。本軟件按功能模塊可以分成流程圖轉(zhuǎn)換與系統(tǒng)解析兩大部分，下面將會進(jìn)行詳細(xì)闡述。

圖1

2.2 詳細(xì)論述

2.2.1 流程圖轉(zhuǎn)換

由流程圖轉(zhuǎn)換后的XML 文件（covtd.xml），將作為系統(tǒng)解析器的輸入文件。 covtd.xml 處理了原始流程圖中的分頁跳轉(zhuǎn)、頁內(nèi)跳轉(zhuǎn)和子流程。covtd.xml 文件有以下三大節(jié)點(diǎn)類型：Process（過程處理）， Screen（終端顯示）， Session （數(shù)據(jù)收發(fā)）。 Process 節(jié)點(diǎn)對應(yīng)流程圖中Terminator（起/止符）、Condition（條件判斷）以及Deal（運(yùn)算處理）圖形；Screen 節(jié)點(diǎn)對應(yīng)流程圖中的Screen 圖形； Session 節(jié)點(diǎn)則對應(yīng)流程圖中的Send Command 圖形。由于covtd.xml 文件涵蓋了生成最終文件所需所有信息，所以指定了流程圖規(guī)范來描述信息，同時(shí)便于解析工具解析。

運(yùn)算處理節(jié)點(diǎn)（Deal）：

運(yùn)算處理項(xiàng)中所涵蓋的內(nèi)容包括單一的賦值運(yùn)算及復(fù)雜的邏輯運(yùn)算等情況；其次，各表達(dá)式中使用的變量類型及其作用域又是各不相同的。 綜上所述，結(jié)合腳本使用情況，規(guī)定了下列規(guī)范：

變量命名中需表明變量類型，基本格式為：數(shù)據(jù)類型_ 描述。數(shù)據(jù)類型可參照C 語言，若數(shù)據(jù)類型為數(shù)組形式時(shí)，需在數(shù)據(jù)類型字段中加上 “Array” 及在描述字段后加上 “[]” 符號。 例：int_Speed=90，byte_Angle=0x30，byteArray_Version[]=0x20，0x21，0x30

流程圖中單個節(jié)點(diǎn)中，可有多行表達(dá)式。 且每一行表達(dá)式中可嵌套多個運(yùn)算表達(dá)式。

數(shù)據(jù)收發(fā)節(jié)點(diǎn)（數(shù)據(jù)的一次收發(fā)可看成為一個會話，故簡稱Session）：

數(shù)據(jù)收發(fā)部分由發(fā)送與接收兩個部分組成， 分別通過關(guān)鍵字“Cmd”與“Rcv”區(qū)分表示。

鑒于接收與發(fā)送的數(shù)據(jù)長度為可變的，故在關(guān)鍵字后需追加“[]”。

發(fā)送的數(shù)據(jù)包可以是直接字符型的，例：Cmd[]=0x14，0xFF，0xFF；也可是由變量與直接字符混合組成的， 例：Cmd [0]=0x14， Cmd [1-2]=int_Ecode。符號“[]”不填寫內(nèi)容時(shí)，表示需發(fā)送數(shù)據(jù)即為賦值的內(nèi)容；符號“[]”填寫數(shù)字時(shí)，表示需發(fā)送的數(shù)據(jù)列中的內(nèi)容將被等號右邊的內(nèi)容替換，符號“[]”所填內(nèi)容為被替換的數(shù)據(jù)起止地址。

接收數(shù)據(jù)的表達(dá)式中需填寫有用的數(shù)據(jù)包最大長度，例：Rcv[16]。

2.2.2 系統(tǒng)解析

系統(tǒng)解析器首先會對轉(zhuǎn)換后的XML 文件與腳本規(guī)范XML 文件中定義類目進(jìn)行匹配，檢測。檢測無誤后，方可進(jìn)入內(nèi)容解析。XML 內(nèi)容解析由標(biāo)簽管理，變量管理，表達(dá)式解析及命令拼接這四部分構(gòu)成。解析的過程有兩步：

第一步：初析。本階段只完成各節(jié)點(diǎn)內(nèi)容到腳本語言的語義翻譯，保留XML 文件中各節(jié)點(diǎn)相關(guān)原始信息，如變量名，節(jié)點(diǎn)間跳轉(zhuǎn)ID，數(shù)據(jù)信息等。

第二步：精析。 此階段通過查詢各數(shù)據(jù)表，取得最終輸出值并替換原XML 相關(guān)信息，刪除初析階段構(gòu)建的冗余信息，生成最終腳本文件。

標(biāo)簽管理：標(biāo)簽管理分為臨時(shí)標(biāo)簽與最終標(biāo)簽。 臨時(shí)標(biāo)簽是解析XML 文件時(shí)創(chuàng)建的，每一個Node 都會有其對應(yīng)的標(biāo)簽；最終標(biāo)簽是指輸出至最終腳本文件。解析器對XML 的解析是以Node 為單位進(jìn)行的，在對Node 解析過程中無法判別此Node 節(jié)點(diǎn)是否被其它Node 節(jié)點(diǎn)所調(diào)用，所以需要通過創(chuàng)建臨時(shí)標(biāo)簽作為標(biāo)注。由于XML 文件中所有輸入解析器的Node 節(jié)點(diǎn)都會創(chuàng)建臨時(shí)標(biāo)簽，其中必有無用標(biāo)簽。因此，需對標(biāo)簽表進(jìn)行遍歷，刪除冗余標(biāo)簽。

變量管理：XML 文件中定義的變量對應(yīng)到最終可執(zhí)行腳本中時(shí)，變量名由某個存儲空間表述。 考慮到實(shí)際可使用的存儲空間有限，因此需對各變量進(jìn)行管理。 根據(jù)變量的使用，指定以下規(guī)則：

（1）只作用于執(zhí)行單次的流程且不隸屬于循環(huán)分支的節(jié)點(diǎn)中定義變量視為局部變量；其余節(jié)點(diǎn)中定義的變量則視為全局變量。

（2）儲存回包狀態(tài)的變量與循環(huán)計(jì)數(shù)器在未特別指明時(shí)為全局變量，并為其指定默認(rèn)存儲空間。

XML 文件中的所有變量都通過一個變量表管理，其中該表的key ID 為變量名。 在XML 文件的初析階段，根據(jù)規(guī)則1，首先篩選出全局變量與局部變量；其次，為全局變量分配存儲空間并更新變量表中的對應(yīng)信息。 精析階段，根據(jù)當(dāng)前剩余存儲空間并結(jié)合規(guī)則2，為局部變量動態(tài)分配存儲空間?？紤]到每個腳本都皆為單進(jìn)程、順序執(zhí)行，故對局部變量的存儲空間進(jìn)行復(fù)用，即每個存儲空間可與多個局部變量對應(yīng)。 當(dāng)某局部變量的生命周期到達(dá)后，需對之前動態(tài)分配的存儲空間進(jìn)行釋放，同時(shí)更新動態(tài)變量分配狀態(tài)表。

表達(dá)式解析：表達(dá)的解析通過堆棧解析。 解析時(shí)首先將取得的表達(dá)式（中綴表達(dá)式）翻譯成后綴表達(dá)式，翻譯流程如下：

中綴表達(dá)式翻譯成后綴表達(dá)式的方法：

Stp1： 從左向右依次從輸入字串中取得字符ch

Stp2： 若ch 是操作數(shù)，直接輸出

Stp3： 若ch 是運(yùn)算符（含左右括號），則：

a：若ch = '('，將ch 放入棧

b：若ch = ')'，依次輸出棧中的運(yùn)算符，直到遇到'(' 為止

c：若ch 既不為')' 也不為'('，那么就和堆棧中頂點(diǎn)位置的運(yùn)算符top 做優(yōu)先級比較

1：若ch 優(yōu)先級比top 高，則將ch 壓入棧

2：若ch 優(yōu)先級低于或者等于top，則輸出top，然后將ch 壓入棧Stp4： 若表達(dá)式已讀取完，而棧中仍有運(yùn)算符時(shí)，則將棧中運(yùn)算符依次由頂端輸出

其次，根據(jù)翻譯后的后綴表達(dá)式求解最終結(jié)果，其求解流程如下：后綴表達(dá)式計(jì)算方法：

Stp1：從左向右掃描后綴表達(dá)式數(shù)組，依次取出一個數(shù)組元素ch；

Stp2：若ch 是表達(dá)式，就壓入棧；

Stp3： 若ch 是運(yùn)算符，就從棧中彈出此運(yùn)算符需要用到的表達(dá)式的個數(shù)（二元運(yùn)算符需要2 個），創(chuàng)建一個新二元表達(dá)式，然后把二元表達(dá)式壓入棧。

Stp4：若數(shù)組處理完畢，棧中最后剩余的表達(dá)式就是最終結(jié)果。

2.3 測試文件構(gòu)建

通過機(jī)器實(shí)現(xiàn)測試文件的自動構(gòu)建， 可以減少開發(fā)人員的工作量，提高工作效率。 當(dāng)然，若是通過機(jī)器生成的測試文件不夠準(zhǔn)確、全面，則開發(fā)人員仍需手動檢查、修改測試文件，從而使工作效率更低。

此處的腳本測試，是指通過軟件模擬實(shí)車與汽車診斷儀的通信數(shù)據(jù)包，驗(yàn)證腳本邏輯流程的正確性。測試過程中，用戶需先指定需加載的測試文件；測試文件加載完成后，模擬軟件根據(jù)測試文件中所羅列的指令數(shù)據(jù)項(xiàng)，模擬實(shí)車與診斷儀通信時(shí)的指令數(shù)據(jù)。 測試文件中需涵蓋的指令集中，既會有Reset 這種前后動作邏輯無關(guān)指令，又會有讀取特定故障碼后再清除讀出的故障碼此類前后動作邏輯相關(guān)指令；同時(shí)通過直接解析XML 文件，可完整提取各出各指令間的邏輯關(guān)系。因此，在解析XML 文件的同時(shí)，需收集數(shù)據(jù)收發(fā)指令的信息。鑒于，每一組數(shù)據(jù)指令都由一條請求指令與一條響應(yīng)指令構(gòu)成，故將命令收發(fā)節(jié)點(diǎn)作為兩個指令組的分割標(biāo)志。

前后動作邏輯無關(guān)指令收發(fā)數(shù)據(jù)包內(nèi)容是固定的。 對應(yīng)到XML文件的數(shù)據(jù)收發(fā)節(jié)點(diǎn)中，即為只有“Cmd[]=0xXX，0xYY……”這一行命令賦值表達(dá)式。由于此類指令的收發(fā)包內(nèi)容與格式都可在協(xié)議中找到明確的定義，因而，根據(jù)數(shù)據(jù)收發(fā)節(jié)點(diǎn)中的命令這一個條件即可構(gòu)建此類指令的測試內(nèi)容。

前后動作邏輯相關(guān)指令中的部分內(nèi)容由用戶定義的，即指令是部分可變的。對應(yīng)到XML 文件的數(shù)據(jù)收發(fā)節(jié)點(diǎn)中，即存在多行“Cmd[]=”此種命令賦值表達(dá)式。 對于此類指令中的不變部分的獲取方法，可借鑒前后動作邏輯無關(guān)指令。 指令中的可變部分，可能是由前驅(qū)節(jié)點(diǎn)計(jì)算獲取，也可能需與后繼節(jié)點(diǎn)中的判斷條件匹配。所以對此類指令，需解析完從本命令節(jié)點(diǎn)至下一命令節(jié)點(diǎn)間的所有節(jié)點(diǎn)后，才可構(gòu)建測試文件?？紤]到指令中的可變部分與前驅(qū)節(jié)點(diǎn)的關(guān)聯(lián)可由一組混有變量名的數(shù)學(xué)運(yùn)算式表述；且本程序在對XML 解析的過程中，會對所有變量創(chuàng)建對應(yīng)的信息表，包括該變量的類型，缺省值，字節(jié)序，取值范圍，被賦值情況等。因此，結(jié)合變量信息表對數(shù)學(xué)運(yùn)算式進(jìn)行語法分析，即可提取出有效數(shù)據(jù)，并構(gòu)建請求指令。同樣的，對于響應(yīng)指令包內(nèi)容需與后繼節(jié)點(diǎn)判斷條件匹配的情況，結(jié)合后繼判斷節(jié)點(diǎn)中的判斷條件及變量信息表，即可構(gòu)建響應(yīng)指令包。

3 結(jié)論

本工具現(xiàn)已投入到腳本開發(fā)的工作中，根據(jù)開發(fā)人員的實(shí)際使用后的反饋情況，在開發(fā)腳本的過程中，通過使用本工具后，現(xiàn)腳本開發(fā)所需時(shí)間大約為原來腳本開發(fā)時(shí)間的70%。 同時(shí)，由于目前所開發(fā)的工具支持的腳本語言有限，給使用帶來一定的局限性。 日后的工作將側(cè)重兼容更多的腳本語言，擴(kuò)展本工具適用范圍，提高工具的實(shí)用性。

［1］何云東，黃昶.復(fù)雜表達(dá)式解析和計(jì)算的研究實(shí)現(xiàn)[J].中國科技信息，2009(8)：35-36.

［2］彭四偉，朱群雄.基干源代碼分析的逆向建模[J].計(jì)算機(jī)應(yīng)用研究，2006.

［3］馮進(jìn)，丁博，史殿習(xí)，等.XML 解析技術(shù)研究[J].計(jì)算機(jī)工程與科學(xué)，2009，31(2)：120-124.

［4］徐愛春，章堅(jiān)民.基于XML/XSLT 代碼自動生成技術(shù)研究[J].杭州電子工業(yè)學(xué)院學(xué)報(bào)，2004，24(4)：64-68.

［5］王茹，宋瀚濤.XML 文檔結(jié)構(gòu)定義規(guī)范：XML Schema[J].計(jì)算機(jī)應(yīng)用研究，2002，19(1)：127-129.