汽車診斷中腳本自動生成工具的研究

丁燕敏 劉 煒

（上海大學 計算機工程與科學學院，中國 上海200072）

1 汽車故障診斷簡介

1.1 汽車故障診斷技術發展簡介

汽車診斷技術發展至今，大致經歷了以下三個階段：

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

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

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

1.2 汽車診斷軟件簡介

現行的汽車診斷軟件由診斷系統基本平臺與業務數據庫構成兩者構成。診斷系統平臺提供車型選擇，數據通信，結果顯示等與診斷業務無關的基本功能；而診斷儀相關的業務則有由數據來驅動。其中，汽車常規診斷業務數據因具有一定的通用性，故此類業務可統一成系列數據表格模板；針對診斷業務中的特殊功能則通過特別定制的腳本實現。

2 方案設計

內嵌于診斷軟件的腳本因其主要實現診斷業務中的特殊功能，所以其業務邏輯相對復雜。 根據實際現行經驗，完整生成一個最終可執行腳本大致有以下幾個步驟：

根據診斷業務邏輯，畫出與其相對應的流程圖：

1）依據流程圖，手動編寫腳本；

2）手動提取診斷業務相關的邏輯數據，生成數據文件；

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

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

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

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

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

2）當需開發腳本的數量很龐大時，開發人員的效率不能保證。

綜上，若通過第三方工具替代原開發流程中部分的步驟，不但可大大減少腳本的開發時間，而且能有效提高最終的業務數據質量。

2.1 方案概述

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

圖1

2.2 詳細論述

2.2.1 流程圖轉換

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

運算處理節點（Deal）：

運算處理項中所涵蓋的內容包括單一的賦值運算及復雜的邏輯運算等情況；其次，各表達式中使用的變量類型及其作用域又是各不相同的。 綜上所述，結合腳本使用情況，規定了下列規范：

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

流程圖中單個節點中，可有多行表達式。 且每一行表達式中可嵌套多個運算表達式。

數據收發節點（數據的一次收發可看成為一個會話，故簡稱Session）：

數據收發部分由發送與接收兩個部分組成， 分別通過關鍵字“Cmd”與“Rcv”區分表示。

鑒于接收與發送的數據長度為可變的，故在關鍵字后需追加“[]”。

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

接收數據的表達式中需填寫有用的數據包最大長度，例：Rcv[16]。

2.2.2 系統解析

系統解析器首先會對轉換后的XML 文件與腳本規范XML 文件中定義類目進行匹配，檢測。檢測無誤后，方可進入內容解析。XML 內容解析由標簽管理，變量管理，表達式解析及命令拼接這四部分構成。解析的過程有兩步：

第一步：初析。本階段只完成各節點內容到腳本語言的語義翻譯，保留XML 文件中各節點相關原始信息，如變量名，節點間跳轉ID，數據信息等。

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

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

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

（1）只作用于執行單次的流程且不隸屬于循環分支的節點中定義變量視為局部變量；其余節點中定義的變量則視為全局變量。

（2）儲存回包狀態的變量與循環計數器在未特別指明時為全局變量，并為其指定默認存儲空間。

XML 文件中的所有變量都通過一個變量表管理，其中該表的key ID 為變量名。 在XML 文件的初析階段，根據規則1，首先篩選出全局變量與局部變量；其次，為全局變量分配存儲空間并更新變量表中的對應信息。 精析階段，根據當前剩余存儲空間并結合規則2，為局部變量動態分配存儲空間。考慮到每個腳本都皆為單進程、順序執行，故對局部變量的存儲空間進行復用，即每個存儲空間可與多個局部變量對應。 當某局部變量的生命周期到達后，需對之前動態分配的存儲空間進行釋放，同時更新動態變量分配狀態表。

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

中綴表達式翻譯成后綴表達式的方法：

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

Stp2： 若ch 是操作數，直接輸出

Stp3： 若ch 是運算符（含左右括號），則：

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

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

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

1：若ch 優先級比top 高，則將ch 壓入棧

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

其次，根據翻譯后的后綴表達式求解最終結果，其求解流程如下：后綴表達式計算方法：

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

Stp2：若ch 是表達式，就壓入棧；

Stp3： 若ch 是運算符，就從棧中彈出此運算符需要用到的表達式的個數（二元運算符需要2 個），創建一個新二元表達式，然后把二元表達式壓入棧。

Stp4：若數組處理完畢，棧中最后剩余的表達式就是最終結果。

2.3 測試文件構建

通過機器實現測試文件的自動構建， 可以減少開發人員的工作量，提高工作效率。 當然，若是通過機器生成的測試文件不夠準確、全面，則開發人員仍需手動檢查、修改測試文件，從而使工作效率更低。

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

前后動作邏輯無關指令收發數據包內容是固定的。 對應到XML文件的數據收發節點中，即為只有“Cmd[]=0xXX，0xYY……”這一行命令賦值表達式。由于此類指令的收發包內容與格式都可在協議中找到明確的定義，因而，根據數據收發節點中的命令這一個條件即可構建此類指令的測試內容。

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

3 結論

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

［1］何云東，黃昶.復雜表達式解析和計算的研究實現[J].中國科技信息，2009(8)：35-36.

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

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

［4］徐愛春，章堅民.基于XML/XSLT 代碼自動生成技術研究[J].杭州電子工業學院學報，2004，24(4)：64-68.

［5］王茹，宋瀚濤.XML 文檔結構定義規范：XML Schema[J].計算機應用研究，2002，19(1)：127-129.