車輛電控模塊通信類故障快速診斷方法研究

楊洪福,吳君,張斌

(泛亞汽車技術中心有限公司，上海 201201)

0 引言

伴隨著車輛電氣化、數字化及智能化[1]程度的提高，車輛模塊間的交互需求越來越強烈，車輛的電控模塊間的通信消息的數量越來越多。伴隨著通信數量的增加，模塊間通信類故障發生的概率也會增大。針對模塊間通信類故障的具體原因調查，需由專業人員或者受過培訓的人員進行手動數據分析，進而確定哪條信號引起了該故障。人工分析總線故障排查效率較低，且有一定的門檻，受人員技術水平的限制。

實際造車過程中，為不影響正常造車節拍，針對造車中出現的問題，需要快速定位問題原因。傳統的人工分析方式效率較低，為了減小對造車節拍的影響，對提高總線故障分析效率、簡化總線故障分析過程以及降低總線故障分析門檻提出了迫切需求。

本文作者主要針對車輛電控模塊通信類問題的快速分析理論及實際應用，利用該理論開發相應分析軟件，用于代替人工；通過自動化分析，快速鎖定通信類問題的根本原因，并生成問題分析報告，極大提高分析效率，實現原因排查操作簡單化，入手容易，且可大范圍推廣。

1 通信類問題基本類型

模塊間的通信消息一般包含以下基本內容： 信號值，信號有效性，rolling count(滾動計數)value和protect(checksum)value。若車輛實施了網絡安全[3]，可能還會包含MAC(Message Authentication Codes)。 圖1給出了一些實例。

圖1 通信消息內容舉例

通信類故障一般包含兩部分：信號未接收到(timeout)，接受到的信號異常[2]。針對信號異常故障，依據消息中包含的信號內容，主要包含以下幾類故障：

(1)Invalid

信號有效性故障。理論上，當信號無效時，發送方會將validity置為invalid。接收方檢測到validity的狀態為invalid時，當滿足報碼條件時，觸發故障碼。

(2)DLC(Data length code)error

信號的長度不正確。當信號實際發送的數據長度和定義的數據長度不一致，當滿足報碼條件時，觸發故障。

(3)Value error

信號發送的值不正確。發送方發送的信號值若不是規定的數值，或者接收方核對值不正確，當滿足報碼條件時，觸發故障。

(4)Rolling count error

Rolling count主要目的是為了保證信號的連續性，防止信號中斷的產生。理論上rolling count變化規律為：0，1，2，3，0，1，2，3……，當rolling count的變化未按照規律進行時，表明存在信號丟失，當在規定的時間內滿足一定的故障次數、滿足報碼條件時，觸發故障。

(5)Protect value error

Protect value主要是為了保證此信號的正確性。Protect value是此信號中內容經過一定的算法獲得的結果值，并存儲在protect value中，連同該消息一同發出，若接受方依據相同的算法得到的數值與發送方發送的protect value值不一致，當滿足報碼條件后，觸發故障。

(6)MAC(Message Authentication Codes)error

MAC是車輛增加網絡安全后新增的一個通信內容。MAC主要通過密鑰將信號加密，接收方成功解密后，信號才可用。當接收方依據算法無法解析MAC時，一定程度上說明發送方發送的MAC存在錯誤，當滿足報碼條件后，觸發故障。

2 故障快速診斷介紹

基于故障自診斷原理[4]，車輛模塊針對接受到的信號都有一套自身的診斷規范(Diagnostic Specification)，依據診斷規范，對信號進行判斷，若信號異常，達到報碼條件，則觸發相應故障碼。

利用診斷規范，結合整車數據庫(Database)和故障數據，理論上可自動對故障數據進行分析，找出故障碼信息及導致該故障具體原因：

利用數據庫解析故障數據，讀取故障數據中記錄的故障碼信息；調用診斷規范，確認引發故障碼的可能原因；依據可能原因，檢查故障數據，鎖定引發故障的真實原因；最終將分析結果以圖標的形式進行展現。具體流程可參考圖2。

圖2 通信故障診斷流程

2.1 故障快速診斷基本框架介紹

快速診斷系統基本框架主要由以下幾部分組成：

(1)整車數據庫(Database)。整車數據庫是車輛通信數據解析的集合。它記錄了通信消息的發送方，接收方，CAN ID，發送頻率，消息名稱，消息中包含的信號名稱、位數、信號默認值等信息(內容舉例見圖3)，利用數據庫可進行整車總線數據的解析。

圖3 數據庫內容舉例

(2)故障診斷規范又叫故障字典，該字典中記錄了針對故障的具體解析，包含故障碼信息、引發故障的原因描述等(具體示例見圖4)，依據該字典可以查到何種信號導致該故障。

車輛模塊間的通信類故障碼多以U開頭，故障碼包含兩部分：主碼和子碼。綜合考慮存儲量和故障原因的數量，同一故障碼下面可能存在多個原因，需要依次檢查相關的信號是否存在異常。若人為依次檢查每個信號的話，操作偏向機械化，時間長、效率低。

(3)故障數據記錄了問題發生時刻的總線數據，包含了故障碼由無到有的過程。利用錄取的故障數據，依據快速診斷原理，確認引發故障的根本原因。整個分析過程可通過上位機軟件自動完成。

(4)分析結論。分析結論中包含了故障碼信息、報碼時間、引發該故障碼的信號狀態，信號異常的時間。分析結論需要體現并證明，故障碼由于某信號異常導致。分析結論由上位機分析軟件自動生成。

圖4 診斷規范內容舉例

2.2 快速診斷方法具體軟件實現

依據基礎邏輯框架，搭建快速診斷軟件，具體操作及界面如圖5所示。

圖5 快速診斷軟件界面

針對整車具有多個模塊的特點，軟件包含了眾多車輛模塊，例如EPS、ECM、TCM、EBCM等。依據需求選擇對應的模塊，然后導入或選擇對應的故障字典(診斷規范)和數據庫。數據庫和故障字典第一次導入之后，后續可直接使用，無需再次導入。針對故障數據，通過讀取故障數據中的故障碼信息獲取需要分析的故障碼，依據故障字典查找故障數據中對應的信號在故障發生時刻是否異常，當檢查到信號異常與報碼時刻一致，自動生成數據分析報告。

2.3 快速診斷方法實車應用

利用開發好的快速診斷軟件，進行實車通信類故障分析，整個分析大約在1 s內完成，從圖6中可以看到:針對U015100的故障碼，工具展示了故障觸發時刻與相關問題信號的關系，鎖定了引發問題的根本原因。

通過自動分析故障數據，能夠快速找出問題原因，程序配置好之后，只需要導入故障數據，工具自動依據快速診斷理論進行分析，指出總線何種問題導致了故障的產生，并生成分析報告，人工參與分析程度降低，有效提高了問題分析效率。

圖6 軟件實際應用結果

3 結束語

針對目前通信類故障人工分析的痛點，將已較為成熟的故障自診斷原理應用到實際的具體通信類問題分析中，形成快速診斷方法。將該方法以分析軟件的形式進行展現，在實際的實車測試中，該方法得到有效驗證，節省了通信類問題分析時間，降低了分析門檻。