新能源汽車整車控制系統的診斷開發

導語：新能源汽車整車控制系統的診斷開發一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

1引言

近年來，新能源汽車在國內得到了飛速的發展。而相較于傳統汽車，新能源汽車具有更高的電氣化水平，其電子電氣架構也更復雜，可能發生故障的問題點也越來越多，故障出現后其診斷也變得愈加困難。依靠傳統的人工經驗檢測與診斷方法，無法快速、準確的判斷新能源汽車電子控制系統的故障，難以適應現代汽車的快速發展。在汽車故障診斷技術方面，國內起步較晚，雖然相較于國外Vector、博世等有所差距，但也有成熟產品，不過多應用于傳統車型。因此，研發具有自主知識產權的汽車故障診斷檢測系統是必然趨勢，具有重要的商業與應用價值。針對汽車診斷，各大汽車廠家都制定了各自的標準，導致汽車診斷規范通用性很差。歐洲汽車商推出一種基于CAN總線的診斷系統通信標準ISO15765，可滿足E-OBD的系統要求。ISO15765以ISO14229定義的服務為基礎,規范了基于CAN總線的診斷服務(UDSonCAN)，包括網絡管理、網絡定時、應用層定時等詳細內容,使得該協議的適用性和可操作性更強。ISO15765符合現代汽車網絡總線系統的發展趨勢，被眾多汽車廠商采納,或將成為未來汽車行業的通用診斷標準。

2UDS診斷系統設計

2.1總體方案設計

結合某新能源診斷系統的現狀，將UDSonCAN診斷系統的開發分為兩大塊：上位機與控制器ECU，參見圖1。上位機部分可以結合現有的EOL平臺進行拓展性開發，在時間進度與客戶的認可度上有一定的保障。控制器部分主要針對現有新能源車輛配置的主要零部件，進行底層與應用層的UDS診斷適應性開發，本文主要闡述此部分診斷開發主要分四個步驟：制定協議規范（需求）、軟件（代碼）實現、診斷測試和實車驗證。

2.2UDS需求規范制定

診斷協議是后續工作開展的基礎，其基于OSI七層架構體系，依據ISO標準制定，詳細定義診斷的物理層、數據鏈路層、網絡層、會話層以及應用層需求。DiagnosticonCAN的OSI結構見表1。實際開發過程中，應結合控制器通訊協議、刷寫要求等各種規范，完成診斷相關的服務在應用與下載兩種情境下的模式與尋址方式等功能定義、通用DTC碼定義、發生故障時凍結幀（整車或部件DTC環境信息）的定義、通用和靜態數據DID信息定義、數據刷寫流程定義等內容。診斷協議也是主機廠把控各零部件狀態的關鍵。

2.3軟件的實現

2.3.1軟件功能概述基于UDS的故障診斷系統，一個完整的控制器需要實現以下功能：①對負載工作狀態和總線網絡通信狀態等進行周期性檢測，并在故障發生時，啟動故障記錄（故障本身及快照信息）和故障處理功能，必要時需及時切斷輸出，確保部件及整車的安全性；②根據整車點火周期定義，在整車當前點火周期結束時存儲歷史故障，在下一個點火周期開始時讀取之前的故障記錄；③當故障消除時，控制器軟件能夠自主啟動故障碼清除邏輯；④診斷儀在線時，按照診斷儀的服務請求，能夠讀取、清除DTC及相關快照與擴展信息，能夠讀寫DID，能夠完成一些IO或例程控制等；⑤診斷儀可以根據數據庫對ECU上傳的數據進行解析并顯示故障類型和故障狀態，并能以表格的形式導出相關數據；⑥診斷儀可以就當前控制器快捷更新程序。2.3.2軟件功能劃分控制器軟件系統主要由底層驅動部分、協議棧和應用層策略部分3部分組成。底層驅動模塊主要實現診斷數據收發（CAN）和故障碼讀寫（存儲模塊）等功能。協議棧設計根據通信矩陣、診斷規范等輸入文檔，實現通信層、數據鏈路層、網絡層、會話層、診斷層的代碼編寫，根據底層協議棧提供的診斷接口，完成診斷函數的填充，最終實現診斷功能。應用層軟件采用基于模型的設計方法（Simulink），主要實現故障檢測、處理和清除等功能。一般來說，具備直接網絡管理功能的控制器將網絡的休眠和喚醒作為一個駕駛循環；而在間接網絡管理的控制器上，將控制器上電和下電作為一個駕駛循環。本方案的駕駛循環根據控制器的上下電（點火信號keyon）來定義。故障檢測、記錄及自恢復機制如下：①每個故障都定義故障檢測計數器、故障老化計數器，下電時計數器值需要寫入存儲模塊，上電后讀取。②每個故障定義好各自的檢測頻率，并設置一個Counter（上限+127，下限-128）值，Counter初始值為0。③每一個檢測周期，分別對各個故障進行一次判斷，若當前檢測周期測出信號超限，Counter+1，直至Counter值為+127，則確定為1次故障；若當前檢測周期信號正常，咱Counter-1，直至Counter值為-128，則表示沒有故障；當Counter值達到+127且故障一直持續，則Counter值維持+127不變；當Counter值達到-128且信號一直正常，則Counter值維持-128不變；若Counter為正數，信號正常，則Counter-1，信號出現故障，則Counter+1；若Counter為負數，信號正常，則Counter-1，信號出現故障，則Counter從0開始+1。④若Counter值為+127，則判定故障產生，將故障信息及故障產生時刻的快照信息存儲在內存中。同時下一個駕駛循環周期開始，老化計數器+1。⑤若后續駕駛循環信號一直正常，則老化計數器一直累加，直至到達第40個駕駛循環周期，然后故障自動清零，同時清除故障相關的快照信息及故障計數器等信息。所有故障相關的信息存儲到一個或幾個臨時變量數組，下電時，再把這些信息存儲到存儲模塊的相應地址中。

2.4診斷測試

診斷功能的測試可以結合CANdelaStudio、DiVa、CANoe工具鏈聯合完成。三套工具配合使用，可極大的簡化各零部件控制器的非車載測試工作，通過最后生成的HTML格式的報告，也可以快速分析底層代碼的問題所在。另外一部分測試可以在實驗室通過臨時搭建控制器環境，完成各零部件的診斷測試。

2.5實車驗證

實車驗證屬于最后的綜合測試，聯合上位機在實車環境中一起對各控制器進行診斷測試，重點驗證診斷過程中相應CAN網絡的負載率情況。實車初步測試完成后，需要就整車狀態進行一定的可靠性驗證。

3總結

診斷系統是整車控制系統開發中至關重要的一環，關乎整車安全。而基于UDS的統一診斷系統是大勢所趨，對主機廠來說，可以充分把控整車各零部件狀態，確保車輛的安全性與可靠性，提升產品的市場認可度；對零部件廠來說，將一部分權限開放給主機廠，可以減少人力、物力等方面的投入，降低部分售后維修費用。總之，這對于雙方來說，是一個雙贏的方案。

作者：薛云鴻 張甜甜 田光爍 李照遠 王方抒 單位：中國重汽集團新能源汽車研究總院