劉 彤， 趙益宏， 蔡偉杰， 陳文強， 韋興民， 趙福全

（吉利汽車研究院， 浙江杭州 311228）

汽車故障診斷是利用ECU監(jiān)測控制系統(tǒng)各組成部分的工作情況， 發(fā)現(xiàn)故障后自動啟動故障記錄和處理邏輯。 汽車故障診斷模塊不僅能夠存儲記憶汽車故障， 還能夠?qū)崟r提供汽車各種運行參數(shù)［1］。 外部診斷設(shè)備通過一定的診斷通信規(guī)則與ECU建立診斷通信， 并讀取這些故障和參數(shù)， 同時解析出來供外部測試人員分析。 故障診斷記錄處理， 并將這些處理的信息通過診斷通信傳輸給外部診斷設(shè)備， 這一系列處理機制構(gòu)成了汽車立體化的診斷系統(tǒng)， 如圖1所示。

統(tǒng)一診斷服務(wù)UDS （Unified diagnostic services）是基于OSI （Open Systems Interconnection） 參考模型設(shè)計的， 是當(dāng)前汽車領(lǐng)域廣泛使用的一種車載診斷協(xié)議標(biāo)準。 當(dāng)前車載網(wǎng)絡(luò)快速發(fā)展， 網(wǎng)絡(luò)總線也不斷變化更新， 由初始的低速LIN總線， 到低速容錯CAN總線、 高速CAN總線， 再到FlexRay和Most總線等等， 越來越多的網(wǎng)絡(luò)總線和電子控制單元的出現(xiàn)迫切需要統(tǒng)一車載診斷協(xié)議。 ISO 14229基于UDS診斷規(guī)范， 可應(yīng)用于多種數(shù)據(jù)鏈路網(wǎng)絡(luò)， 是一種可廣泛應(yīng)用的滿足診斷需求的協(xié)議標(biāo)準， 如圖2所示［2］。

CAN網(wǎng)絡(luò)是一種非破壞性仲裁的通信網(wǎng)絡(luò)［3］，它因具有較高的通信速率 （最高可達1 Mb／s） 和靈活可靠的通信方式， 在車載網(wǎng)絡(luò)領(lǐng)域廣受青睞。 控制系統(tǒng)之間的信息交互即可通過CAN網(wǎng)絡(luò)通信的方式進行。 但如其他系統(tǒng)一樣， 通信實體之間也需要進行通信故障的診斷， 例如診斷通信異常、 通信丟失等故障。 CAN網(wǎng)絡(luò)通信不僅實現(xiàn)了車載電子單元之間的通信， 同時也為在線診斷提供了網(wǎng)絡(luò)載體。CAN總線電控單元及診斷接入端分布見圖3。

本文基于ISO 14229協(xié)議， 以CAN總線為通信介質(zhì)， 對車載控制單元之間記錄通信丟失故障原理及診斷儀如何讀取故障信息數(shù)據(jù)原理進行了分析， 并根據(jù)協(xié)議規(guī)范制定了一種通信丟失處理策略。

1 網(wǎng)絡(luò)通信丟失的故障診斷機制

變速器控制單元TCU和防抱死系統(tǒng)ABS是CAN車載網(wǎng)絡(luò)上的兩大電子控制單元， 這2個ECU要通過CAN網(wǎng)絡(luò)進行大量的信息交互。 但是由于電磁干擾、 串?dāng)_、 靜電等外界干擾或電控單元本身控制策略引起的通信停止等原因， 2個控制單元之間可能會出現(xiàn)通信丟失的現(xiàn)象。

控制系統(tǒng)需要將故障信息 （例如通信丟失故障信息） 診斷出來， 以處理通信被破壞時出現(xiàn)丟失幀的故障現(xiàn)象， 并記錄為DTC （diagnostic trouble code）。 一旦某一控制系統(tǒng)， 如TCU監(jiān)測到一段規(guī)定的時間內(nèi)并沒有接收到ABS發(fā)來的通信數(shù)據(jù)， 便將此DTC記錄下來。 外部診斷設(shè)備通過規(guī)則的診斷通信與控制系統(tǒng)建立診斷通信連接， 并選擇相應(yīng)的診斷方式， 例如： 讀取故障信息服務(wù)時， 就會將此故障信息讀出， 并在診斷儀中顯示出來。 TCU記錄網(wǎng)絡(luò)通信丟失流程如圖4所示。

2 基于UDS的診斷原理分析

根據(jù)UDS的診斷協(xié)議， 汽車上的控制系統(tǒng)需要根據(jù)規(guī)則化的診斷協(xié)議進行故障記錄和處理， 最終體現(xiàn)為診斷故障編碼DTC的方式。

根據(jù)ISO 14229協(xié)議規(guī)定， 每個DTC均由DTC內(nèi)容和DTC狀態(tài)表示。 DTC內(nèi)容代表了該故障的具體故障方式、 故障標(biāo)志等信息， 例如車身系統(tǒng)中ABS傳感器故障。 DTC狀態(tài)則表示當(dāng)前的故障處于什么狀態(tài)， 它由8位組成， 每個位代表了不同的故障狀態(tài)信息， 詳細意義如表1所示［2］。

根據(jù)ISO 14229診斷協(xié)議， DTC的記錄原理和狀態(tài)信息控制如圖5所示［2］。 控制系統(tǒng)以一定的時間周期 （如50 ms） 進行一次相應(yīng)的故障監(jiān)測， 檢測是否出現(xiàn)了故障。 圖5中， 橢圓框中豎線部分表示檢測到了故障。 每一個控制單元中都會設(shè)定一個錯誤監(jiān)測計數(shù)器， 如黑色框中圖形顯示， 計數(shù)器有計數(shù)上、 下限， 例如錯誤計數(shù)上限為127， 下限為-128。 一個駕駛循環(huán)開始的時候， 錯誤檢測計數(shù)從0開始， 監(jiān)測信號沒有錯誤， 則計數(shù)器減1， 若一直累計到下限-128， 則不再遞減。 而一旦監(jiān)測到一個錯誤信號， 計數(shù)器將歸零或置于零上， 若之后有連續(xù)的錯誤幀， 則計數(shù)器持續(xù)累加， 直到上限127，此時第一位 （Bit 0 Test Failed） 將置1。 在一個駕駛循環(huán)內(nèi)， 如果某一時段監(jiān)測停止， 則計數(shù)保持不變。 在一個駕駛循環(huán)結(jié)束， 下一個駕駛循環(huán)開始時， 計數(shù)器歸零， 重新開始計數(shù)。 其他位的記錄原理與此類似， 見圖5圖注。 TCU控制單元就是以這樣的診斷原理， 將網(wǎng)絡(luò)通信丟失的故障記錄下來。

表1 DTC狀態(tài)位描述

3 診斷通信分析

診斷通信即為外部診斷設(shè)備與車載ECU之間進行的診斷信息交互。 這個信息交互的過程要遵循一定的診斷通信協(xié)議要求， 而診斷通信協(xié)議即為每個ECU生產(chǎn)商根據(jù)ECU的功能需求定義的診斷通信規(guī)范。 外部診斷設(shè)備和ECU內(nèi)部的診斷模塊都要根據(jù)這個規(guī)范進行定義和開發(fā)， 這樣才可以保證外部診斷設(shè)備與ECU之間進行準確的診斷通信。

汽車故障診斷除了可以讓系統(tǒng)更加健壯， 并實時處理出現(xiàn)的故障這個功能以外， 還能將故障以DTC的形式記錄下來， 并通過診斷通信的形式傳輸給外部診斷設(shè)備進行分析。 DTC被記錄下來以后，外部診斷設(shè)備通過診斷通信的形式去讀取這些故障信息。 診斷通信通過不同的診斷服務(wù)， 執(zhí)行不同的診斷目的， 例如： 讀取故障的診斷服務(wù)， 是為了讀取控制系統(tǒng)中所記錄的DTC； 讀取數(shù)據(jù)信息的診斷服務(wù)， 就是為了讀取控制系統(tǒng)的一些參數(shù)。

為了更好地分析診斷儀讀取診斷信息的原理，不僅需要診斷儀對控制系統(tǒng)進行實時診斷， 還需要CANoe將診斷儀和ECU之間交互的信息記錄下來。通過分析CANoe實際記錄的故障代碼數(shù)據(jù)， 進行診斷通信分析。 在整車診斷通信中， 客戶端tester （診斷儀） 和服務(wù)器端控制系統(tǒng)ECU是統(tǒng)一編址的， 且每一個tester和ECU的地址都是惟一的。

以泛在教學(xué)與混合式教學(xué)為核心思想，與企業(yè)共同打造集課程資源、企業(yè)實訓(xùn)項目庫、教學(xué)互動、教學(xué)應(yīng)用、教學(xué)管理評估、項目式驅(qū)動學(xué)習(xí)、學(xué)習(xí)質(zhì)量評估、學(xué)習(xí)行為管理分析于一體的網(wǎng)絡(luò)教學(xué)綜合服務(wù)平臺。通過平臺，學(xué)生可以隨時隨地進行自主探究式學(xué)習(xí)，并通過自身的學(xué)習(xí)行為數(shù)據(jù)更加透徹地了解自己，實現(xiàn)個性化的高效學(xué)習(xí)方式；教師可以把學(xué)習(xí)計劃、課程資源等整合到學(xué)習(xí)平臺中，可以查看學(xué)生的學(xué)習(xí)狀況、開展課堂互動與課后討論等，可以通過質(zhì)量評估數(shù)據(jù)了解學(xué)生，調(diào)整教學(xué)計劃，實現(xiàn)教學(xué)相長，提高教學(xué)質(zhì)量。

ECU發(fā)生故障時， ECU通過自診斷模塊檢測到系統(tǒng)部件故障， 然后將故障的信息以數(shù)字代碼的形式存儲在模塊內(nèi)部的EEPROM中。 診斷儀通過診斷通信與ECU建立通信聯(lián)系， ECU從自身的存儲器中讀取這些數(shù)字代碼并傳輸給診斷設(shè)備。 診斷設(shè)備根據(jù)代碼所對應(yīng)的故障信息來識別故障［4］。

診斷儀首先需要請求TCU開始建立診斷通信，然后告知TCU診斷的目的， 例如： 開始建立連接或讀取故障信息等。 這種診斷目的性體現(xiàn)在ISO 14229中即為診斷服務(wù)的方式， 例如： 請求診斷服務(wù)、 讀取故障服務(wù)、 讀取數(shù)據(jù)服務(wù)等。 表2是一段實際的診斷數(shù)據(jù)。

如表2所示， 診斷開始時刻， 診斷儀向TCU發(fā)送建立診斷請求， TCU進行回復(fù)。 其中7E1和7E9分別代表TCU診斷標(biāo)識和TCU響應(yīng)診斷標(biāo)識。 10表示建立診斷通信請求服務(wù)標(biāo)識， 50是響應(yīng)服務(wù)標(biāo)識。在ISO 14229中規(guī)定， ECU的診斷響應(yīng)ID=ECU診斷請求ID+0x008， 例如7E1的請求， 響應(yīng)則為7E9； 響應(yīng)服務(wù)的ID=請求服務(wù)的ID+0x40， 例如10的服務(wù)響應(yīng)則是50。 這種規(guī)則化的處理方式方便了數(shù)據(jù)的傳輸， 更方便了數(shù)據(jù)的處理。 診斷通信就是建立在這種規(guī)則化的通信方式之上的。

表2 TCU診斷請求／響應(yīng)數(shù)據(jù)

表3、 表4所示的兩段數(shù)據(jù)表示診斷儀對TCU進行讀取故障碼診斷服務(wù)， TCU分別反饋故障DTC個數(shù)和故障DTC內(nèi)容的情況。 其中， 19服務(wù)是讀取故障碼信息服務(wù)， 59是19服務(wù)的肯定響應(yīng)服務(wù)。

表3 TCU診斷讀取故障碼（DTC）個數(shù)

表4 TCU診斷讀取故障碼（DTC）內(nèi)容

根據(jù)ISO 14229 的診斷協(xié)議， 19 服務(wù)有01，02， 04， 06， 0A等子服務(wù)。 在01子服務(wù)中， 第4個數(shù)據(jù)字節(jié)代表DTC狀態(tài)掩碼， 即需要讀取哪種狀態(tài)的DTC。 在表3所顯示數(shù)據(jù)的19服務(wù)請求中， 第4個字節(jié)為FF， 它代表的意義為讀取所有Bit置1位的DTC。 在59響應(yīng)服務(wù)中， 第5、 6字節(jié)表示DTC的個數(shù)。 如上述數(shù)據(jù)顯示， 第5、 6字節(jié)均為00， 即DTC的個數(shù)為0。

19服務(wù)的02子服務(wù)代表了根據(jù)故障信息掩碼讀取DTC內(nèi)容。 以表4為例， 結(jié)果顯示有1個故障DTC。

數(shù)據(jù)中前3個字節(jié)所代表的含義可參照01子服務(wù)， 之后的3個字節(jié)表示了這個DTC的內(nèi)容， 最后一個字節(jié)表示了這個DTC的狀態(tài)。

表5 DTC高位字節(jié)信息

基于UDS的診斷協(xié)議， Bit7和Bit6組合為第1個編碼集合； Bit5和Bit4組合為第2個編碼集合； Bit3到Bit0組合為第3個編碼集合。 這樣做的好處是可以根據(jù)不同的編碼集合設(shè)計不同的故障類別和故障信息， 而事實上， 因為位數(shù)比較多， 很多Bit位目前并沒有使用， 但這樣也為未來可擴展性做了預(yù)留， 是一種非常好的機制。

其中， DTC高位字節(jié)first編碼集合代表的是汽車上哪種系統(tǒng)出現(xiàn)了故障。 目前， 規(guī)范定義的系統(tǒng)有動力系統(tǒng)、 底盤系統(tǒng)、 車身系統(tǒng)和網(wǎng)絡(luò)系統(tǒng)。 但隨著汽車研究的高速發(fā)展， 當(dāng)前定義的4個系統(tǒng)已經(jīng)不能滿足要求， 例如安全系統(tǒng)、 娛樂系統(tǒng)等均沒有制定出來， 此時即可以使用其他預(yù)留的位加以輔助來進行識別。 first編碼集合的意義如表6所示。

表6 first編碼集合意義

根據(jù)表4分析數(shù)據(jù)可知： 反饋的59信息為d 8 07 59 02 FF C1 21 20 DB， 其中C1 21 20 DB所代表就是DTC的信息， C1、 21、 20分別是DTC高位字節(jié)、 DTC中位字節(jié)和DTC低位字節(jié)。 將C1分解為8位的二進制為1100 0001， 它最高兩位 （Bit7-6） 為11， 對應(yīng)到表6中可知， 是網(wǎng)絡(luò)出現(xiàn)了問題， 即出現(xiàn)了通信故障。 剩下的幾位00 0001和剩下的字節(jié)21、 20， 根據(jù)整車廠策略不同， 可以表示不同的內(nèi)容， 例如本文中最開始所提出的范例TCU記錄的DTC為與ABS通信丟失， 就可通過設(shè)置編譯后， 由剩下的位數(shù)表述出此故障信息。 最后一個字節(jié)0xDB表示了該DTC的狀態(tài)， 此信息含義對應(yīng)到本文第2章所述， 將DB分解為8位二進制， 由置1位分析DTC內(nèi)容， 此過程分析見圖6。

圖6所示DTC狀態(tài)為： 置1位分別為test failed，test failed this operation cycle， confirmed DTC， test not completed since last clear， test not completed this operation cycle 和Warning Indicator requested，由此分析可知此DTC出現(xiàn)錯誤， 且在當(dāng)前駕駛循環(huán)下被確認。

4 基于UDS的通信故障診斷處理策略制定

UDS診斷協(xié)議提供了故障檢測、 記錄的方法和方向。 但實際應(yīng)用中還需要做兩個方面的設(shè)計： 一是底層機制的支持， 二是上層診斷處理策略的制定。

以車載網(wǎng)絡(luò)通信中通信丟失這一故障診斷為例： 首先， 協(xié)議棧的驅(qū)動層應(yīng)該定期地 （或采用中斷方式） 接收網(wǎng)絡(luò)上傳輸過來的信息， 并通過某種機制告知上層協(xié)議棧。 上層協(xié)議棧 （例如交互層）應(yīng)該具備檢測通信丟失的功能機制， 例如： 周期性地進行檢測 （continuous test run）。 當(dāng)檢測到缺失了應(yīng)該接收到的信息或者接收超出了規(guī)定的時間閾值時， ECU應(yīng)該記錄下此次診斷失?。╢ault detection at moment of test run）。

上層診斷處理策略主要指如何記錄DTC、 記錄DTC的哪些屬性以及如何清除這些故障碼， 這是診斷處理策略制定的關(guān)鍵！

以車載網(wǎng)絡(luò)通信丟失這一故障診斷為例， 需要嚴格而可靠地診斷出這一故障， 為此本文提出在UDS的基礎(chǔ)上進行優(yōu)化， 制定了以下機制， 如圖7所示。

1） 設(shè)定一個通信丟失錯誤計數(shù)器， 一旦檢測到通信丟失， 錯誤計數(shù)器開始計數(shù)。

2） 在計數(shù)過程中一旦接收到信息， 則計數(shù)器減1。

3） 如果錯誤計數(shù)達到5次或者一個更可靠的閾值（這與具體的應(yīng)用有關(guān)， 在某些高安全高可靠領(lǐng)域可能更?。?時， 啟動通信丟失預(yù)警定時器， 也稱之為恢復(fù)階段定時器， 并開始定時。

4） 一旦通信丟失， 預(yù)警定時器達到6 s還沒有接收到信息， 我們認為通信丟失故障檢測完成， 并置相應(yīng)DTC的test failed位為1， 如圖7中 “1” 處所標(biāo)識。

圖8所示的時間流程圖能夠更清晰地說明這個基于UDS優(yōu)化后的通信故障診斷處理策略。

在上電以后， 各個系統(tǒng)開始正常的通信， 發(fā)送和接收信號都沒有診斷出故障。 在T0時刻， ECU檢測到應(yīng)該接收的信號丟失， 開始啟動錯誤計數(shù)器。當(dāng)錯誤計數(shù)器達到一定閾值但還沒有接收到信息時， 啟動恢復(fù)階段定時器。 如果在恢復(fù)定時器時間段內(nèi)， 還檢測到通信丟失故障并且沒有恢復(fù)， 則在定時器結(jié)束時記錄下該DTC， 并在與外部設(shè)備進行故障診斷時， 以診斷通信的方式傳輸給診斷設(shè)備。

5 結(jié)束語

本文主要基于UDS統(tǒng)一診斷服務(wù)對車載網(wǎng)絡(luò)診斷過程的機制、 策略進行了分析和研究。 根據(jù)網(wǎng)絡(luò)通信的規(guī)范， 設(shè)計出車載網(wǎng)絡(luò)通信丟失故障的診斷策略。 通過故障數(shù)據(jù)記錄， 結(jié)合ISO 14229診斷規(guī)范， 分析到數(shù)據(jù)每一個字節(jié)、 每一位所代表的含義， 提出了新的優(yōu)化機制， 從而完善了網(wǎng)絡(luò)通信診斷記錄DTC策略， 極大地提高了車載網(wǎng)絡(luò)通信的可靠性和魯棒性。

［1］ 陳新. 基于GPRS的汽車故障診斷儀的遠程診斷設(shè)計［J］.工業(yè)控制計算機， 2006 （6）： 70-73.

［2］ ISO 14229. Road vehicles-Unified diagnostic services（UDS）-Specification and requirements［S］. 2006.

［3］ ISO 11898-1. Road vehicles-Controller area network（CAN）-Part 1： Data Link Layer and physical signaling［S］. 2003.

［4］ 蔡浩. 汽車故障診斷系統(tǒng)的設(shè)計和開發(fā)［D］. 上海： 上海交通大學(xué)， 2009.