摘要：闡述一種診斷控制單元之間通訊丟失故障的機制，通過基於UDS的診斷協議進行原理分析，並制定一種有效的診斷處理策略。

    汽車故障診斷是利用ECU監測控制系統各組成部分的工作情況，發現故障後自動啟動故障記錄和處理邏輯。汽車故障診斷模組不僅能夠儲存記憶汽車故障，還能夠實時提供汽車各種執行引數川。外部診斷裝置通過一定的診斷通訊規則與ECU建立診斷通訊，並讀取這些故障和引數，同時解析出來供外部測試人員分析。故障診斷記錄處理，並將這些處理的資訊通過診斷通訊傳輸給外部診斷裝置，這一系列處理機制構成了汽車立體化的診斷系統，如圖1所示。

    統一診斷服務UDS (Unified diagnostic services)是基於OSI (Open Systems Interconnection）參考模型設計的，是當前汽車領域廣泛使用的一種車載診斷協議標準。當前車載網路快速發展，網路匯流排也不斷變化更新，由初始的低速LIN匯流排，到低速容錯CAN匯流排、高速CAN匯流排，再到F1exRay和Most匯流排等等，越來越多的網路匯流排和電子控制單元的出現迫切需要統一車載診斷協議。ISO 14229基於

    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所示。

2基於UDS的診斷原理分析
    根據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策略，極大地提高了車載網路通訊的可靠性和魯棒性。