基于Vehicle Spy 的排放相關網絡故障碼測試方法實現

田 豐，林家強，周軍成，韋佳萍，周國林，許運灼

（1.上汽通用五菱汽車股份有限公司，廣西 柳州 545007；2.柳州孔輝汽車科技有限公司，廣西 柳州 545026；3.湖南湖大艾盛汽車技術開發有限公司，湖南 長沙 410221；4.柳州滬信汽車科技有限公司，廣西 柳州 545616）

1 引言

隨著汽車功能日益豐富，配置也多樣化，車載電控單元ECU的數量在不斷增多，各ECU之間通過總線的信息交互也越來越多。當某ECU需要的總線信號丟失或無效時，其功能就會受到影響，此時ECU會按照一定規則將該故障通過診斷故障代碼DTC的形式記錄并上報。對于DTC的產生及恢復邏輯測試，一直以來都是各大主機廠診斷測試的重要內容。裴偉軍、毛鴻霖等人提出的基于VT System和CANoe系列軟件的故障碼測試是一種通過搭建臺架測試系統，在實驗室單節點條件下，模擬相關總線信號故障的測試方法[1-2]，目前幾乎所有開展此項測試的主機廠也都是采用這種方法。

然而，對于發動機控制模塊ECM、變速器控制模塊TCM等排放相關的ECU而言，某些總線信號的丟失或無效，會導致車輛進入跛行等極限工況，從而影響排放。根據相關法規要求，排放相關的DTC需要2個或2個以上的駕駛循環才允許確認，而DTC的消除更是需要經過多個無故障暖機循環才能滿足要求。駕駛循環和暖機循環需要滿足發動機運轉、車速、水溫等條件，然而要想在實驗室環境下實現這些條件只能斥巨資搭建復雜的硬件在環（HIL）測試系統[3]，這對主機廠而言是個不小的挑戰。因此，目前大多主機廠對于這部分DTC的邏輯確認直接采用ECU供應商的測試結果或者在實車上粗略測試。顯然，這并不能達到準確驗證DTC邏輯的目的，也會給售后分析故障增加難度。為此，本文提出一種使用低成本標準設備在實車上精確測試排放相關故障碼的方法，利用簡單的測試環境補充了此項測試的空缺。

2 基于Vehicle Spy的半自動化測試

美國因特佩斯公司的Vehicle Spy是一款汽車總線仿真測試軟件，可以實現節點仿真、數據解碼、自動測試、數據采集等多種功能[4]，滿足實驗室和實車環境中對車輛ECU的基礎測試需求。本文所介紹的就是利用Vehicle Spy軟件在實車環境下進行的排放相關故障碼測試方案。

將Vehicle Spy硬件一端通過在線診斷（OBD）連接線接至整車OBD口，另一端通過USB接口接至裝有Vehicle Spy軟件的電腦上，測試環境即搭建完成，其整體連接示意如圖1所示。本測試方法以實車環境為基礎，免去了復雜的測試硬件方案設計，僅需通過標準工具中的相關軟件腳本編輯，配合人為的車輛操作，即可完成排放相關網絡DTC測試，大大降低測試成本的同時，也能精確地驗證DTC的設計邏輯。

圖1 排放相關網絡DTC測試環境整體連接示意圖

3 軟件方案設計

3.1 網絡數據庫（DBC）建立

由于測試內容涉及到網絡報文的丟失、無效、錯誤等故障現象，在進行測試之前需要編制好DBC數據庫。這需要識別被測DTC指向的是總線上的哪些ECU所發出的哪些報文。根據具體車型的通信矩陣，在Vehicle Spy軟件中的Message Editor界面進行發送信號編制，網絡數據庫編制如圖2所示。編制完成后即可在Tx Panel面板對所編輯的報文進行周期性模擬發送，如圖3所示。

圖2 網絡數據庫編制

圖3 網絡報文發送面板

3.2 診斷數據庫建立

由于在測試過程中需要用到停止通信、讀故障碼、清故障碼等UDS診斷服務，因此診斷數據庫的編輯也至關重要。停止通信服務用于整車特定ECU報文的停發，結合之前編輯的DBC數據庫，即可實現在不對整車電子元器件及線束接插件做任何改動的情況下，精確控制被測DTC所對應報文的內容和周期，輕松制造期望的網絡故障，方便快捷。讀故障碼、清故障碼服務用于測試過程中判斷故障是否產生及手動清除。

3.3 測試腳本生成

Function Block是Vehicle Spy軟件中的一個腳本編輯工具，提供了一種列表式的命令執行步驟編輯方式，用于創建可直接執行的測試腳本序列。用戶無需了解具體編程語言，也可輕松操作完成測試用例編輯。結合前面兩步中所編輯的應用報文及診斷報文內容，在Function Block中給每一個步驟設置具體的指令，如發送應用報文、設置信號值、等待特定條件、發送診斷報文等，搭配工具提供的循環設置，即可實現自動執行制造故障、讀取故障碼、判斷測試結果等操作。Function Block測試腳本編輯界面如圖4所示。

圖4 Function Block測試腳本編輯界面

4 測試流程設計

4.1 測試流程實施

對于排放相關的ECU，在整車上電后即開始監控相關的網絡報文故障。第1個操作循環，從使用診斷服務停發相關ECU報文，到測試設備模擬發送被停掉的報文這段時間，ECU可能已經記錄了某些DTC。為了排除第1個操作循環中測試尚未開始階段的其他因素干擾，需要先對ECU進行清除DTC操作。在模擬發送相關報文一定時間后，根據DTC列表中描述的待測DTC產生條件，精確停發一定時間（如10個報文周期）相關報文后讀取DTC，判斷是否已經產生了待確認（Pending）DTC，若已產生則可以結束當前操作循環，若未產生則對停發報文的周期進行微調，直至產生待確認的DTC為止。整個操作循環過程中，需要配合車輛，至少啟動一次發動機（若為混動車型，則需要至少達到一次高壓狀態），以滿足駕駛循環的條件，否則ECU會一直處于第1個操作循環過程中，無法結束，從而影響測試結果。

第2個操作循環，執行與第1個操作循環同樣的操作，直至產生已確認（Confirm）DTC，測試完成。根據具體DTC策略，此方法還能應用于更多駕駛循環甚至暖機循環才能確認故障的情況測試，具體測試及判斷流程如圖5所示。

圖5 排放相關DTC測試流程

4.2 測試結果確認

由于測試用例中最終結果的判斷都是要以讀取到相應DTC為條件，如果一直讀取不到DTC或者尚未滿足條件就已經讀取到了DTC，均屬于測試不合格。測試用例中將各種不合格的情況均已考慮在內，以保證測試結果的準確性。具體包括以下幾種情況。

1）還未開始測試就已經出現了待測DTC。

2）第1個操作循環無法產生待確認DTC。

3）第1個操作循環還未達到故障產生條件就已經出現了待確認DTC。

4）第1個操作循環超過了故障產生條件才出現待確認DTC。

5）第1個操作循環就已經產生了已確認DTC。

6）第2個操作循環無法產生已確認DTC。

7）第2個操作循環還未達到故障產生條件就已經產生了已確認DTC。

8）第2個操作循環超過了故障產生條件才出現已確認DTC。

本文以ECM排放相關網絡DTC C15100為例，在實車上驗證了此方法的可行性和準確性。在第1個駕駛循環中按設計條件制造故障后，讀出了狀態位為0x27的Pending故障。配合發動機啟動、熄火、重新上電等操作，結束第1個駕駛循環，并進入第2個駕駛循環。繼續按DTC設計條件制造故障，讀出了狀態位為0x2F的Confirm故障。測試結果示例如圖6所示。

圖6 測試結果示例

5 結論

通過基于Vehicle Spy的半自動化測試方法，實現了對排放系統ECU的排放相關網絡故障碼邏輯測試，避免了復雜的硬件系統設計，同時節約了測試成本。利用Function Block功能，保證了測試過程的嚴謹性和測試結果的準確性，對DTC設計邏輯給出了評價，也為售后排查相關問題提供了試驗數據支持。