轉載於：http://blog.163.com/iable@126/blog/static/762494272015510101234906/
摘要：闡述一種診斷控制單元之間通信丟失故障的機制，通過基於UDS的診斷協議進行原理分析，並制定一種有效的診斷處理策略。
汽車故障診斷是利用ECU監測控制系統各組成部分的工作情況，發現故障后自動啟動故障記錄和處理邏輯。汽車故障診斷模塊不僅能夠存儲記憶汽車故障，還能夠實時提供汽車各種運行參數川。外部診斷設備通過一定的診斷通信規則與ECU建立診斷通信，並讀取這些故障和參數，同時解析出來供外部測試人員分析。故障診斷記錄處理，並將這些處理的信息通過診斷通信傳輸給外部診斷設備，這一系列處理機制構成了汽車立體化的診斷系統，如圖1所示。
統一診斷服務UDS (Unified diagnostic services)是基於OSI (Open Systems Interconnection）參考模型設計的，是當前汽車領域廣泛使用的一種車載診斷協議標准。當前車載網絡快速發展，網絡總線也不斷變化更新，由初始的低速LIN總線，到低速容錯CAN總線、高速CAN總線，再到F1exRay和Most總線等等，越來越多的網絡總線和電子控制單元的出現迫切需要統一車載診斷協議。ISO 14229基於UDS診斷規范，可應用於多種數據鏈路網絡，是一種可廣泛應用的滿足診斷需求的協議標准，如圖2所示。
CAN網絡是一種非破壞性仲裁的通信網絡它因具有較高的通信速率（最高可達1 Mb/s）和靈活可靠的通信方式，在車載網絡領域廣受青睞。控制系統之間的信息交互即可通過CAN網絡通信的方式進行。但如其他系統一樣，通信實體之間也需要進行通信故障的診斷，例如診斷通信異常、通信丟失等故障。CAN網絡通信不僅實現了車載電子單元之間的通信，同時也為在線診斷提供了網絡載體。CAN總線電控單元及診斷接人端分布見圖3。
本文基於ISO 14229協議，以CAN總線為通信介質，對車載控制單元之間記錄通信丟失故障原理及診斷儀如何讀取故障信息數據原理進行了分析，並根據協議規范制定了一種通信丟失處理策略。
1網絡通信丟失的故障診斷機制
變速器控制單元TCU和防抱死系統ABS是CAN車載網絡上的兩大電子控制單元，這2個ECU要通過CAN網絡進行大量的信息交互。但是由於電磁干擾、串擾、靜電等外界干擾或電控單元本身控制策略引起的通信停止等原因，2個控制單元之間可能會出現通信丟失的現象。
控制系統需要將故障信息（例如通信丟失故障信息）診斷出來，以處理通信被破壞時出現丟失幀的故障現象，並記錄為 DTC ( diagnostic troublecode)。一旦某一控制系統，如TCU監測到一段規定的時間內並沒有接收到ABS發來的通信數據，便將此DTC記錄下來。外部診斷設備通過規則的診斷通信與控制系統建立診斷通信連接，並選擇相應的診斷方式，例如：讀取故障信息服務時，就會將此故障信息讀出，並在診斷儀中顯示出來。TCU記錄網絡通信丟失流程如圖4所示。
根據UDS的診斷協議，汽車上的控制系統需要根據規則化的診斷協議進行故障記錄和處理，最終體現為診斷故障編碼DTC的方式。
根據ISO 14229協議規定，每個DTC均由DTC內容和DTC狀態表示。DTC內容代表了該故障的具體故障方式、故障標志等信息，例如車身系統中ABS傳感器故障。DTC狀態則表示當前的故障處於什么狀態，它由8位組成，每個位代表了不同的故障狀態信息，詳細意義如表1所示。
根據ISO 14229診斷協議，DTC的記錄原理和狀態信息控制如圖5所示。控制系統以一定的時間周期（如50 ms）進行一次相應的故障監測，檢測是否出現了故障。圖5中，橢圓框中豎線部分表示檢測到了故障。每一個控制單元中都會設定一個錯誤監測計數器，如黑色框中圖形顯示，計數器有計數上、下限，例如錯誤計數上限為127，下限為-128。一個駕駛循環開始的時候，錯誤檢測計數從0開始，監測信號沒有錯誤，則計數器減1，若一直累計到下限-128，則不再遞減。而一旦監測到一個錯誤信號，計數器將歸零或置於零上，若之后有連續的錯誤幀，則計數器持續累加，直到上限127,此時第一位（Bit 0 Test Failed）將置1。在一個駕駛循環內，如果某一時段監測停止，則計數保持不變。在一個駕駛循環結束，下一個駕駛循環開始時，計數器歸零，重新開始計數。其他位的記錄原理與此類似，見圖5圖注。TCU控制單元就是以這樣的診斷原理，將網絡通信丟失的故障記錄下來。
3診斷通信分析
診斷通信即為外部診斷設備與車載ECU之間進行的診斷信息交互。這個信息交互的過程要遵循一定的診斷通信協議要求，而診斷通信協議即為每個ECU生產商根據ECU的功能需求定義的診斷通信規范。外部診斷設備和ECU內部的診斷模塊都要根據這個規范進行定義和開發，這樣才可以保證外部診斷設備與ECU之間進行准確的診斷通信。
汽車故障診斷除了可以讓系統更加健壯，並實時處理出現的故障這個功能以外，還能將故障以DTC的形式記錄下來，並通過診斷通信的形式傳輸給外部診斷設備進行分析。DTC被記錄下來以后，外部診斷設備通過診斷通信的形式去讀取這些故障信息。診斷通信通過不同的診斷服務，執行不同的診斷目的，例如：讀取故障的診斷服務，是為了讀取控制系統中所記錄的DTC;讀取數據信息的診斷服務，就是為了讀取控制系統的一些參數。
為了更好地分析診斷儀讀取診斷信息的原理，不僅需要診斷儀對控制系統進行實時診斷，還需要CANoe將診斷儀和ECU之間交互的信息記錄下來。通過分析CANoe實際記錄的故障代碼數據，進行診斷通信分析。在整車診斷通信中，客戶端tester（診斷儀）和服務器端控制系統ECU是統一編址的，且每一個tester和ECU的地址都是惟一的。
ECU發生故障時，ECU通過自診斷模塊檢測到系統部件敵障，然后將故障的信息以數字代碼的形式存儲在模塊內部的EEPROM中。診斷儀通過診斷通信與ECU建立通信聯系，ECU從自身的存儲器中讀取這些數字代碼並傳輸給診斷設備。診斷設備根據代碼所對應的故障信息來識別故障。
診斷儀首先需要請求TCU開始建立診斷通信，然后告知TCU診斷的目的，例如：開始建立連接或讀取故障信息等。這種診斷目的性體現在ISO14229中即為診斷服務的方式，例如：請求診斷服務、讀取故障服務、讀取數據服務等。表2是一段實際的診斷數據。
如表2所示，診斷開始時刻，診斷儀向TCU發送建立診斷請求，TCU進行回復。其中7E1和7E9分別代表TCU診斷標識和TCU響應診斷標識。10表示建立診斷通信請求服務標識，50是響應服務標識。在ISO 14229中規定，ECU的診斷響應ID=ECU診斷請求ID+0x008，例如7E1的請求，響應則為7E9；響應服務的ID＝請求服務的ID+0x40，例如10的服務響應則是50。這種規則化的處理方式方便了數據的傳輸，更方便了數據的處理。診斷通信就是建立在這種規則化的通信方式之上的。
表3、表4所示的兩段數據表示診斷儀對TCU進行讀取故障碼診斷服務，TCU分別反饋故障DTC個數和故障DTC內容的情況。其中，19服務是讀取故障碼信息服務，59是19服務的肯定響應服務。
根據ISO 14229的診斷協議，19服務有01,02, 04, 06, OA等子服務。在01子服務中，第4個數據字節代表DTC狀態掩碼，即需要讀取哪種狀態的DTC。在表3所顯示數據的19服務請求中，第4個字節為FF，它代表的意義為讀取所有Bit置1位的DTC。在59響應服務中，第5, 6字節表示DTC的個數。如上述數據顯示，第5, 6字節均為00，即DTC的個數為0。
19服務的02子服務代表了根據故障信息掩碼讀取DTC內容。以表4為例，結果顯示有1個故障DTC。
數據中前3個字節所代表的含義可參照01子服務，之后的3個字節表示了這個DTC的內容，最后一個字節表示了這個DTC的狀態。
根據UDS診斷規范，DTC信息可由4部分組成，分別為DTC高位字節、DTC中位字節以及DTC低位字節和DTC狀態。而根據UDS協議，我們將DTC高位字節又分為3個部分，且每一部分賦予了一定的意義，如表5所示。
基於UDS的診斷協議，Bit7和Bit6組合為第1個編碼集合；Bit5和Bit4組合為第2個編碼集合；Bit3到BitO組合為第3個編碼集合。這樣做的好處是可以根據不同的編碼集合設計不同的故障類別和故障信息，而事實上，因為位數比較多，很多Bit位目前並沒有使用，但這樣也為未來可擴展性做了預留，是一種非常好的機制。
其中，DTC高位字節first編碼集合代表的是汽車上哪種系統出現了故障。目前，規范定義的系統有動力系統、底盤系統、車身系統和網絡系統。但隨着汽車研究的高速發展，當前定義的4個系統已經不能滿足要求，例如安全系統、娛樂系統等均沒有制定出來，此時即可以使用其他預留的位加以輔助來進行識別。first編碼集合的意義如表6所示。
根據表4分析數據可知：反饋的59信息為d80759 02 FF C l 21 20 DB，其中C12120DB所代表就是DTC的信息，C1, 21, 20分別是DTC高位字節、DTC中位字節和DTC低位字節。將C1分解為8位的二進制為1100 0001，它最高兩位（Bit7-6）為11，對應到表6中可知，是網絡出現了問題，即出現了通信故障。剩下的幾位00 0001和剩下的字節21, 20，根據整車廠策略不同，可以表示不同的內容，例如本文中最開始所提出的范例TCU記錄的DTC為與ABS通信丟失，就可通過設置編譯后，由剩下的位數表述出此故障信息。最后一個字節OxDB表示了該DTC的狀態，此信息含義對應到本文第2章所述，將DB分解為8位二進制，由置1位分析DTC內容，此過程分析見圖6。
圖6所示DTC狀態為：置1位分別為test failed,test failed this operation cycle，confirmed DTC，testnot completed since last clear，test not completedthis operation cycle和Warning Indicator requested，由此分析可知此DTC出現錯誤，且在當前駕駛循環下被確認。
4基於UDS的通信故障診斷處理策略制定
UDS診斷協議提供了故障檢測、記錄的方法和方向。但實際應用中還需要做兩個方面的設計：一是底層機制的支持，二是上層診斷處理策略的制定。
以車載網絡通信中通信丟失這一故障診斷為例：首先，協議棧的驅動層應該定期地（或采用中斷方式）接收網絡上傳輸過來的信息，並通過某種機制告知上層協議棧。上層協議棧（例如交互層）應該具備檢測通信丟失的功能機制，例如：周期性地進行檢測（continuous test run）。當檢測到缺失了應該接收到的信息或者接收超出了規定的時間閩值時，ECU應該記錄下此次診斷失敗（fault detectionat moment of test run）。
上層診斷處理策略主要指如何記錄DTC、記錄DTC的哪些屬性以及如何清除這些故障碼，這是診斷處理策略制定的關鍵！
以車載網絡通信丟失這一故障診斷為例，需要嚴格而可靠地診斷出這一故障，為此本文提出在UDS的基礎上進行優化，制定了以下機制，如圖7所示。
1)設定一個通信丟失錯誤計數器，一旦檢測到通信丟失，錯誤計數器開始計數。
2)在計數過程中一旦接收到信息，則計數器減1。
3)如果錯誤計數達到5次或者一個更可靠的閡值（這與具體的應用有關，在某些高安全高可靠領域可能更小）時，啟動通信丟失預警定時器，也稱之為恢復階段定時器，並開始定時。
4)一旦通信丟失，預警定時器達到6s還沒有接收到信息，我們認為通信丟失故障檢測完成，並置相應DTC的test failed位為1，如圖7中“1”處所標識。
圖8所示的時間流程圖能夠更清晰地說明這個基於UDS優化后的通信故障診斷處理策略。
在上電以后，各個系統開始正常的通信，發送和接收信號都沒有診斷出故障。在T0時刻，ECU檢測到應該接收的信號丟失，開始啟動錯誤計數器。當錯誤計數器達到一定I01值但還沒有接收到信息時，啟動恢復階段定時器。如果在恢復定時器時間段內，還檢測到通信丟失故障並且沒有恢復，則在定時器結束時記錄下該DTC，並在與外部設備進行故障診斷時，以診斷通信的方式傳輸給診斷設備。
5結束語
本文主要基於UDS統一診斷服務對車載網絡診斷過程的機制、策略進行了分析和研究。根據網絡通信的規范，設計出車載網絡通信丟失故障的診斷策略。通過故障數據記錄，結合ISO 14229診斷規范，分析到數據每一個字節、每一位所代表的含義，提出了新的優化機制，從而完善了網絡通信診斷記錄DTC策略，極大地提高了車載網絡通信的可靠性和魯棒性。