呂 峰,歐增開
(東風柳州汽車有限公司技術中心,廣西 柳州 545005)
近年來,國內自主品牌企業在整車電控系統研發設計方面投入了很多資金和人員力量,并且配備自主開發的控制器的車型也陸續上市。但從研發設計到實車測試驗證階段,整體來說還不具備較完善的測試環境和測試流程,尤其是控制器控制策略及故障診斷策略的測試驗證方面,還處于簡單的車身臺架及手動測試階段。這種模式只能對常規的邏輯類功能進行驗證,不能覆蓋到包括復雜交互式性能、故障 (電器、功能)注入、極限工況以及對時間參數有嚴格要求的邏輯功能測試,況且這些工況在實車測試環節中也未必能遇到。由于測試環節的不夠完善,導致上市的車輛會存在沒有及時發現的潛在問題[1],因此自主企業針對電控單元的研發、測試及驗證過程,建立先進的測試環境條件以及完善的測試流程至關重要,本文針對某車型整車電控系統進行硬件在環測試的方案原理及測試流程進行闡述。
某車型的整車系統網絡拓撲架構如圖1所示。整個測試過程需要搭建系統硬件在環 (HIL)仿真測試環境,基于該平臺環境,實現對整車系統電器系統的功能策略進行驗證測試,實現網絡系統的復雜測試,對被控對象進行工況模擬,實現電控系統的故障模式注入 (電器故障和功能故障)及診斷測試。
系統硬件設計需求分析是搭建HIL測試環境的前提。需要根據以下設計輸入 (客戶及供應商提供)對HIL系統進行電器接口配置設計:①整車電氣原理圖;②電控單元引腳定義;③電控單元輸入輸出接口電路;④電控單元傳感器特性參數;⑤電控單元執行機構特性參數;⑥電控單元插接件及連接線束;⑦執行機構插接件及連接線束;⑧整車網絡拓撲定義;⑨整車網絡通信數據庫 (dbc文件和ldf文件);⑩診斷協議及診斷數據庫 (cdd文件);11故障碼列表及故障注入方式。
系統軟件設計需求主要是基于用戶需求、被測對象功能測試需求分析基礎之上,確定測試管理Layout、數據采集及數據分析環境、系統測試控制軟件界面以及自動化測試環境等。
HIL系統功能測試除了搭建系統硬件環境,即滿足電控單元所需的整車電氣環境、測試軟件管理環境之外,還需要搭建整車系統運行環境,需要構建發動機系統、動力傳動系統、車輛動力學系統、道路環境及駕駛員模型等車輛運行環境模型。
HIL測試系統主要包括硬件仿真平臺 (dSPA-CE Simulator和測試臺架)、實時仿真ASM模型以及測試管理軟件 (控制臺操作界面)等幾部分。
2.1.1 硬件仿真平臺Simulator
硬件仿真平臺采用的是德國dSPACE Simulat-or,該平臺主要用于和真實電控單元進行電氣連接及通信,提供控制器所需的各種傳感器輸入信號,并接受控制器發出的各種控制信號,反饋給車輛模型進行計算仿真,同時可以產生 (模擬)各種故障用于故障工況仿真。
2.1.2 實時仿真模型
實時仿真模型包括IO模型和車輛模型,IO模型主要負責把傳感器等的物理信號通過轉換關系得到電氣信號值,同時把采集到的電氣信號值通過轉換關系得到物理值;車輛模型包括發動機、傳動系(包括變速器和差速器等)、車輛動力學以及道路環境模型。圖2為實時仿真模型外層基本框架。
通過ModelDesk利用提供的發動機、變速器等車輛參數對車輛模型進行參數化,使實時仿真模型能夠正確模擬車輛運動,被控對象能夠及時準確響應控制器的控制動作并把運動狀態反饋給控制器。
2.1.3 系統測試控制管理
利用ControlDesk測試管理軟件創建圖形化界面(圖3),對整個測試過程進行控制和管理,能夠進行硬件管理、虛擬儀表顯示、數據監控、變量及參數設置,并進行模型的下載[2]。
基于AutomationDesk自動化測試管理平臺,按照測試規范,編制相應的測試序列,實現測試用例的實現及自動化測試腳本開發,并形成測試報告。
2.2.1 系統硬件接口配置
根據控制器的引腳功能定義、傳感器與驅動器的電氣特性,對HIL測試系統進行I/O通道的建立與配置管理,并且根據客戶的需求完善系統配置。在此基礎之上,設計測試系統的信號列表Signal List,該信號列表全面地反映了HIL測試系統的功能配置,并根據需求與定義,完善此列表。主要工作如下:①控制器相關板卡配置;②控制器與仿真柜的硬線連接;③dSPACE相關實時系統軟件配置;④I/O模型配置與映射;⑤傳感器及執行機構參數匹配;⑥集成CANLIN通信模型。
2.2.2 試驗管理Layout設計
試驗管理Layout設計主要是實現一個比較友好的人機界面,方便用戶進行測試、分析、統計、查看等一系列測試管理工作。基于ControlDesk試驗管理軟件,設計測試界面Layout,主要包括以下幾個部 分[3]:①系 統 基 本 控制窗口;②傳感器輸入信號模擬窗口;③執行器輸出信號采集窗口;④數據分析窗口;⑤總線數據顯示窗口;⑥圖標界面顯示窗口。
2.2.3 傳感器信號標定測試
通過界面控制,對測試機柜的傳感器仿真信號進行模擬,結合標定工具CANape或INCA對傳感器信號進行采集測試,并進行標定和確認。
2.2.4 執行器信號標定測試
需要對執行器的驅動負載進行模擬或采用實際負載,結合標定工具CANape或INCA對執行器的驅動信號進行測試,并進行標定和確認。
2.2.5 測試臺架安裝與調試
對預先設計好的方案進行臺架樣件安裝以及線束連接,然后對臺架進行調試以及信號激勵測試,確保各個信號準確有效性,最后進行系統臺架系統聯調。
測試矩陣規范是進行測試用例設計的依據,包含整個測試內容的系統功能劃分、測試項和測試用例條目的概述、需求映射關系、測試執行情況的跟蹤等;測試矩陣中根據測試方案及控制器功能特征、危險等級、用戶體驗、供應商能力、法規與標準等制定各個功能項的安全等級及測試深度。
測試用例設計是測試實施的依據,根據測試方案和測試矩陣開發具體的測試指導文件,每條測試用例包括用例ID、用例名稱、初始條件、測試步驟、期望結果和測試結果。每一用例名稱代表一個測試點并且擁有惟一ID。通過使用測試ID,有利于測試活動的可追溯性,便于測試管理。
根據測試需求和控制器功能規范,基于自動化測試軟件環境,按照測試要求組織測試序列,開發測試腳本,主要針對一些流程性或實時性測試方面的測試用例。自動化測試開發采用離線測試和在線測試相結合的方法,提高測試工作效率。
2.6.1 CAN網絡系統測試
CAN網絡通信測試主要是根據特定的整車網絡拓撲圖 (或dbc文件),為待測電控單元建立網絡測試環境,進行殘余總線仿真,通過專用CAN配置工具RTICANMM來實現。基于HIL實時測試平臺,可以進行以下測試:①報文ID;②報文長度;③報文傳輸率;④支持ECU本身節點BUS OFF;⑤CHK確認 (報文中包含CHK信息);⑥計數器確認 (報文中包含計數器信息);⑦總線負載率確認 (Bus navigator中可觀測總線負載率)。
為了對整車網絡系統進行完整的測試和仿真,需要將網絡測試設備與硬件在環測試設備一起協同工作,如Vector公司的CANStress或CANoe等。
2.6.2 LIN網絡節點仿真測試
LIN網絡通信測試主要根據LIN網絡通信數據庫(ldf文件),為待測電控單元建立網絡測試環境,進行LIN總線節點的仿真測試,通過專用的LIN配置工具RTILINMM來實現。
要能夠完整地驗證系統的功能策略,需要利用硬件在環系統使控制器在一個可控的虛擬環境下進行各種功能性及分布式功能測試,以確定目前的控制策略功能可以完全滿足用戶的需求。
具體的功能測試需要供應商提供相關的功能規范及控制策略。依據功能控制策略,編寫測試用例,在Controldesk或AutomationDesk環境下實現控制器的系統功能測試。
系統的診斷功能測試,主要分為以下2個層次。
1)電器硬件故障診斷測試。硬件故障又分為傳感器故障診斷和執行器故障診斷。通過故障注入模塊可產生如下的電氣錯誤類型:開路、對電源短路 (KL30)、對點火起動電源短路 (KL15)、 搭鐵短路 (KL31)、信號線短路、信號不良、信號線互相短路。
2)系統功能故障診斷測試。系統的功能性故障診斷測試,需要獲取控制器的診斷策略,通常這些是供應商或主機廠的技術核心,需要雙方協商一起來實現這部分的診斷測試。
系統自動化測試是在HIL系統基礎測試的基礎上,基于AutomationDesk環境,開發測試序列,并結合相關診斷工具、標定工具,對系統功能、診斷策略、網絡通信進行自動化測試,測試完成形成測試報告。
硬件在環測試具有傳統實車測試中不可比擬的優點[4],從安全性、可行性和合理的成本上考慮,硬件在環仿真測試已經成為汽車廠開發流程中非常重要的一環,不僅減少了實車路試的次數,縮短開發時間和降低成本,同時還提高電控ECU的軟件品質, 降低汽車廠的風險[5]。
[1]雷葉紅,張記華,張春明.基于dSPACE_MATLAB_Simulink平臺的實時仿真技術研究[J].系統仿真技術,2005 (3):13-17.
[2]Susanne Kohl, Dirk Jegminat.How to Do Hardware-in-the-Loop Simulation Right[J].SAE Paper.2005 (1):1657.
[3]李幼德,劉巍,李靜,等.汽車穩定性控制系統硬件在環仿真[J].吉林大學學報, 2007 (4):3-6.
[4]胡朝峰.汽車電子電器硬件在環仿真實驗系統的研究[J].汽車電器,2010(6):50-52.
[5]范瑩.基于dSPACE的列控車載控制器測試方法的研究(碩士學位論文)[D].北京:北京交通大學,2012.