許靈斐 黎揚 王兆喜
四輪獨立驅動電動汽車控制系統對通信確定性有更高的要求。基于汽車總線開發V模式流程,從四輪獨立驅動控制系統通信需求出發,設計其FlexRay通信網絡。采用Network Designer生成網絡數據庫,導入到CANoe.FlexRay軟件對網絡進行了全仿真、半實物仿真,驗證了所設計的FlexRay通信網絡的協議參數的正確性,最后將該網絡用于樣車中。實驗結果表明,所設計的FlexRay通信網絡完全可用于四輪獨立驅動電動車控制系統,具有較高的可靠性、確定性及實時性,能夠滿足控制系統的通信需求。
隨著車輛中ECU(Electronic Control Unit)數量增加,CAN(Controller Area Network)網絡已經在車輛控制器通信中越來越普遍[1]。
汽車故障診斷技術的發展,使得車輛故障維修已經從人識別故障轉變為控制器通過傳感器診斷故障。
目前,故障診斷中,診斷通信協議存在
兩種,在轎車上一般采用ISO15745以及ISO14229協議,而在商用車上,一般采用SAE J1939協議。
2 商用車故障診斷通信系統概述
診斷通信系統包含以下幾個部分:
車內CAN通信網絡、車內ECU,CAN適配器,以及診斷上位機軟件。
某型商用混合動力汽車CAN網絡拓撲分為CAN1低壓網絡和CAN2高壓網絡。CAN3網絡用于診斷數據和HCU標定數據的發送。HCU(Hybrid Control Uint)是混合動力汽車的控制中樞,其在高壓和低壓網絡上.在混合動力控制的過程中,HCU必須要實時獲取其他各個模塊的故障狀態,所以其他各個ECU通過CAN報將各自模塊的故障上傳給HCU,HCU將故障信息匯總,通過SAE J1939標準診斷通信協議將故障傳給外部診斷設備。另外HCU通過與自身連接的外部傳感器,診斷由其直接控制的部件的故障狀態。
應用層和診斷層支持的J1939-73標準協議,主要完成具體的診斷任務。定義了診斷消息DM1(Diagnistci Message)-DM21用于傳輸發動機參數數據、凍結幀數據以及標定、Bootloader數據等。
3 SAE J1939診斷通信網絡層設計
CAN報文的一幀只能傳輸8個字節的數據,當需要傳輸的數據多于8個字節時,就需要采用多包傳輸機制來完成數據的傳輸。在J1939協議中,網絡層由J1939-21定義。
從該CAN報文的數據中,從ID場讀出SA,PGN以及Priority,數據長度和具體的數據,后交給其他軟件模塊處理。
當有數據需要發送時,首先需要根據數據的字節數計算一共需要發送的幀數。如果該數據為廣播數據,則不需要考慮[2]其他節點的響應,只需要在傳輸時間參數范圍內將數據發送出去。如果不是廣播的數據,則需要按照多包傳輸協議。它是點對點的數據傳輸,首先發送CM_RTS請求報文,并啟動定時器,開始等待接收節點發送CM_CTS報文。如果CM_CTS報文超時,則發送放棄連接報文Abort報文,放棄連接原因為時間超時。
4 故障診斷系統測試
在Microsoft Visual C++基于MFC開發了商用車的故障診斷軟件,該軟件通過硬件USB-CAN卡連接到車輛的診斷CAN網絡上
5.1 診斷儀進行故障診斷
啟動故障診斷軟件,讀取HCU內部的故障碼。
5.2 凍結參數讀取
車輛在故障時候的狀態參數有助于幫助維修,所以本系統會將車輛在故障時的參數保存,當外部有請求的時候,使用DM9(凍結幀)將該數據發送出來。
讀到的凍結幀參數如圖12所示。
(作者單位:重慶郵電大學)