一
傳統V型開發流程向DevOps開發流程轉換
伴隨著汽車行業向新四化的推動,車輛的功能越來越豐富,車內控制器的軟件迭代速度更是不斷提升,從智能座艙、信息娛樂到先進駕駛輔助系統,消費者希望這些功能像手機應用一樣時刻保持最新,導致汽車軟件開發由V型開發流程轉向DevOps敏捷開發,以幫助軟件團隊縮短開發周期,加速軟件迭代。 ? ?DevOps全稱Developemt and Operations,提倡Continueous Integration(持續集成),CT(持續測試),CD(持續交付),通過工具平臺使得構建、測試、發布軟件能夠更加的快捷、頻繁和可靠。”
? 為應對流程轉變上的挑戰,開發團隊可將軟硬件解耦后,硬件和軟件的部分各自按照獨立時間線來開發,并在進行軟件更改后無需對整個車輛進行重新驗證,純軟件的開發和驗證過程從原型車或者硬件在環測試過渡到軟件在環(SIL)的測試驗證。這種軟硬解耦的方式同時也迎合了當下將ECU功能整合到中央計算單元或域控制器的趨勢,在多合一控制器融合的過程中發揮作用,軟件模塊可以在不同的硬件平臺運行, 并在車輛整個生命周期內更新。
二
軟件在環的應用場景
快速變更的功能需求下敏捷開發及快速迭代。
盡早進行軟件驗證并發現和糾正代碼中的重要錯誤,特別是涉及安全相關的錯誤。
在高頻率OTA云端升級軟件的情況下自動化持續驗證。
在以上場景下軟件在環SIL測試能夠脫離硬件而快速驗證控制器的功能代碼。
軟件在環(SIL)包括三個部分:虛擬控制器(vECU)、被控對象模型或環境模型(Plant Model)及聯合仿真平臺(Simulation Middleware Platform)。
三
什么是虛擬ECU
虛擬ECU簡稱vECU,表示脫離真實硬件依賴后基于PC獨立編譯和運行的軟件,vECU所包含的內容通常可由ASW,vBSW,vCDD以及RTE這幾個部分構成,在集成編譯后封裝成基于PC的可執行文件。
對于功能測試驗證工程師,通常他會拿到一個帶有軟件的完整ECU,在硬件在環或實車環境下進行測試,整個測試過程可能受硬件和線束的限制,每當遇到軟件的失效首先考慮線束或者硬件通信上的問題,測試效率受硬件條件限制,難以高效的完成測試任務。但對于ECU內與硬件無關功能,解耦ECU代碼后生成vECU即可運行在PC上直接測試目標代碼,數據采集和驗證過程同真實環境軟件測試工具一致,如INCA、Debugger調試器等。
對功能開發工程師來說,驗證功能時需要在完整ECU軟件上進行集成并驗證功能,該集成過程通常由軟件集成工程師負責,軟件集成工程師在集成該功能同時還需考慮ECU平臺化bugfix,底層芯片配置等方方面面因素,導致反饋過程冗長,迭代效率低效的問題。其實對于生成的ECU功能代碼,依然將這一部分代碼封裝成一個vECU并進行仿真測試,可以在任意時間終止仿真并進行Debug,還可以在功能驗證過程中根據需要對vECU做預標定從而提前驗證預設數據。
隨著vECU復雜程度的逐步提升,vECU使用場景也會越來越多。如下圖中隨著虛擬化和自動化程度提升,vECU使用場景能逐步過渡到第二和第三個階段。
簡而言之,就是將控制器C代碼基于PC環境編譯后生成FMU格式的可執行文件運行在常規PC仿真環境上,以更早和更快的方式進行測試及調試。
四
虛擬控制器vECU的分類
生成虛擬控制器的方式有兩種,一種是通過C源碼經過PC的x86編譯器(MinGW或者Visual Studio)后生成vECU目標文件,并于PC上進行系統測試和驗證后反饋給研發工程師。另一種是將C源碼編譯成目標芯片的程序(hex文件)后,運行在目標芯片的指令模擬器上來進行系統測試后再將結果反饋給研發工程師。
如下圖所示,Type-1 vECU、Type-2 vECU和Type-3 vECU為第一類通過C源碼的構建方式生成的vECU,Type-4為第二類通過目標程序運行在目標芯片指令模擬器的方式實現vECU。 ?
Type-4 vECU雖然可執行的是同一個目標hex文件,但考慮到Type-4 vECU本身緩慢的運行效率及芯片迭代所帶來大量工程,當前多數用戶會采用基于源碼的Type-1、Type-2 和Type-3的vECU生成方式,它可以獲得的更快的運行效率、仿真時的在線Debug、解耦硬件(芯片)以及對實驗結果更快的反饋時間。
雖然采用vECU來驗證有諸多優勢,但用其進行測試和仿真時仍有一定限制,比如無法評估和分析諸如軟件上的時間表現、CPU負載、內存資源的消耗以及模擬硬件中斷等特性。
五
構建虛擬ECU
VECU-BUILDER 是一款生成虛擬ECU的工具,它將C代碼源文件或者預編譯后的二進制庫文件構建成虛擬 ECU。
虛擬ECU可在虛擬仿真環境中對ECU軟件進行仿真、調試和標定。
作為集成vECU的環境,它的輸入可以是C代碼、靜態庫文件(lib)或動態鏈接庫(dll),與通過ARXML配置 Classic Autosar 代碼不同,進行vECU集成和配置時只需維護唯一個YAML文件,YAML文件是一個文本形式的配置文件。VECU-BUILDER通過YAML文件的配置信息將代碼封裝成FMU格式的目標文件。
YAML文件包含編譯配置信息、所需集成的C代碼或者庫文件、vECU的輸入輸出端口以及任務調度的入口函數,該配置文件可在vECU增量編譯的過程中重復使用。
構建虛擬ECU工具演示
vECU生成演示
vECU測試及Debug
六
軟硬件解耦后的vECU應用案例
軟硬件解耦后vECU的集成和測試可以覆蓋從模塊測試到系統集成測試。
以下列舉5個典型的應用案例
案例1(?短周期內在SIL環境下ASW的持續性開發)
案例描述:
1.集成ECU應用層軟件產品代碼成vECU,生成可執行SIL文件。
2.在試驗環境上運行SIL,該測試環境等價于目標環境(相同仿真、測試和標定工具)。
3.預集成虛擬化通訊協議棧的vECU可以是該SIL環境的一部分。
案例2 (仿真時間或實時時間下的SIL集成測試)
案例描述:
1.集成測試帶有一個或多個vECU,滿足相關的功能需求。
2.基于不同的應用案例,可在時間基準上調節仿真時間。
3.使用ECUTest或TPT或Robot Framework框架進行vECU的集成測試。
案例3(?vECU虛擬標定)
案例描述:SIL環境用于執行vECU以及經標定過的被控對象模型,針對軟件在環中特定客戶項目或者車輛調整vECU的標定參數,從而實現預標定。
案例4(多方協作在云端集成SIL測試環境)
案例描述:
為虛擬控制器測試人員提供結合云端的軟件測試SIL測試環境以測試vECU功能。
案例5(?Software Sharing)
案例描述:
對第三方代碼(以靜態或動態庫文件的方式)在軟件在環的環境下進行集成和測試。
相關案例:
七
結語:
ETAS 可提供:
1.虛擬控制器vECU工具鏈
2.聯合仿真平臺(Simulation Middleware Platform)支持標準FMU集成及跨平臺聯合仿真,各類虛擬總線
3.持續集成持續測試的自動化流程 (Automation Pipeline)
4.專業的工程服務
用戶收益:
1.支持生成不同類型的虛擬控制器,可靈活應用在軟件開發前期、中期、后期,提升開發效率。
2.標準化仿真平臺,易于接入各種虛擬控制器和被控對象模型等,實現軟件在環測試,盡早發現關鍵錯誤。
3.通過建立持續集成、持續測試的pipeline,減少開發人員的重復工作,加速集成和測試過程。
4.支持幀級的虛擬總線、國內云端部署,更好地協助開發部門進行數字化轉型。
審核編輯 :李倩
評論