ECU電控軟件開(kāi)發(fā)及測試介紹

       伴隨著(zhù)電動(dòng)化、智能化、網(wǎng)聯(lián)化等技術(shù)發(fā)展的時(shí)代背景，各行各業(yè)電子電氣架構都在發(fā)生深度變革。新型架構逐漸取代傳統架構，比如汽車(chē)、工程機械、儲能、船舶等領(lǐng)域，電子電氣架構從傳統分布式向域集中式，甚至向著(zhù)中央集中式發(fā)展，控制器功能呈現集中化、復雜化的特點(diǎn)。為了提升開(kāi)發(fā)效率、提高軟件的穩定性以及便于平臺移植，基于 AutoSar 架構開(kāi)發(fā)復雜軟件已成為行業(yè)共識。

       另外，行業(yè)內競爭愈發(fā)激烈，開(kāi)發(fā)周期大大壓縮，加之軟件復雜度的提升，在快速迭代的情況下確保軟件質(zhì)量是一個(gè)重要課題。加之 ASPICE、ISO26262 等過(guò)程體系和法規標準的要求，如何開(kāi)發(fā)符合 AutoSar 架構的應用軟件、評估軟件質(zhì)量和性能、優(yōu)化軟件結構、驗證壓力場(chǎng)景下的 ECU 穩定性成為各廠(chǎng)商面臨的新挑戰。

       本文重點(diǎn)介紹符合 AutoSar 架構的應用軟件開(kāi)發(fā)、MBD 開(kāi)發(fā)模式下的軟件質(zhì)量評估與優(yōu)化方案、復雜場(chǎng)景下的 ECU 性能壓力測試方案。

符合 AutoSar 架構的應用軟件開(kāi)發(fā)介紹

       對于 AutoSar 軟件架構，分為經(jīng)典平臺 AutoSar CP 和自適應平臺 AutoSar AP，二者應用場(chǎng)景存在一定差別：AutoSar CP 具有高安全、高實(shí)時(shí)性，其通常部署在微控制器 MCU 類(lèi)型芯片或多核異構芯片 M 核；AutoSar AP 具有動(dòng)態(tài)性和可擴展性，適用于大數據并行處理和高性能計算等應用場(chǎng)景，通常部署在 MPU 或多核異構芯片 A 核。目前從行業(yè)內來(lái)看，無(wú)論是域控制器還是中央 + 區域控制器，通常都是多核的，甚至是多核異構的，不同核根據實(shí)際使用需求部署 AutoSar CP 或 AP，基礎軟件通常采用標準的 BSW 協(xié)議棧。下圖所示是 AutoSar 軟件架構示例：

AutoSar 軟件架構

       那對于應用層軟件來(lái)說(shuō)，如果要開(kāi)發(fā)符合 AutoSar 架構的軟件，需要考慮以下兩個(gè)重要問(wèn)題：

       · 采用何種開(kāi)發(fā)工具鏈

       · 采用何種開(kāi)發(fā)模式

       對于應用軟件開(kāi)發(fā)工具鏈，通常涉及 SWC 軟件架構設計工具和軟件編程實(shí)現工具。SWC 軟件架構設計工具主要對應用層軟件架構進(jìn)行實(shí)現，定義 SWC、配置 SWC 的交互接口、配置 Runnable、導出 ARXML 文件等，一般不同品牌的協(xié)議棧都有對應的 SWC 軟件架構設計工具，經(jīng)緯恒潤自研 AutoSar 協(xié)議棧提供工具鏈方案為 EAS-SWCDesigner。

EAS-SWCDesigner 界面

       而軟件編程實(shí)現可基于圖形化編程自動(dòng)生成代碼或手寫(xiě)代碼的方式，AutoSar CP 和 AP 架構應用層軟件開(kāi)發(fā)實(shí)現方法略有差別，CP 架構應用層更多采用基于模型設計方法開(kāi)發(fā)，工具鏈通常采用 Matlab/Simulink，其對 CP 架構應用層開(kāi)發(fā)的支持比較完善且成熟，但是由于其對 AP 架構應用軟件開(kāi)發(fā)支持還存在不完善的點(diǎn)，故 AP 架構應用層軟件開(kāi)發(fā)目前更多還是基于手寫(xiě) C++ 代碼的方式，工具鏈基于一些代碼編輯工具比如 Vscode。

       對于應用軟件開(kāi)發(fā)模式，分為自上而下開(kāi)發(fā)、自下而上開(kāi)發(fā)和雙向開(kāi)發(fā)模式。自上而下開(kāi)發(fā)比較適用于正向開(kāi)發(fā)流程，在有 EE 架構輸入的情況下采用該模式，這種模式的好處是可以繼承 EE 架構的工作產(chǎn)品，但是缺點(diǎn)是工作鏈路會(huì )比較長(cháng)，應用層和底層軟件開(kāi)發(fā)都需要依耐 SWC 架構設計導出的 ARXML 文件作為輸入，影響開(kāi)發(fā)迭代效率；自下而上開(kāi)發(fā)是直接在軟件編程工具實(shí)現軟件，然后配置 AutoSar 接口，再導出 ARXML，然后對 ARXML 文件進(jìn)行合并，這種方式比較適用于沒(méi)有 EE 架構輸入的情況，應用軟件開(kāi)發(fā)工程師獨立配置 AutoSar 接口，這種模式的好處是不依耐 AutoSar 工具鏈，比較靈活，但是缺點(diǎn)是對每個(gè)應用軟件開(kāi)發(fā)人員 AutoSar 知識要求高些；雙向開(kāi)發(fā)模式就是結合自上而下和自下而上開(kāi)發(fā)模式的優(yōu)點(diǎn)，針對第一版軟件采用自上而下開(kāi)發(fā)模式，后續版本軟件更新迭代采用自下而上開(kāi)發(fā)模式。

應用軟件開(kāi)發(fā)模式

MBD 開(kāi)發(fā)模式下的軟件質(zhì)量評估與優(yōu)化方案

       MBD 全稱(chēng)是 Model Based Design（基于模型設計），是一種以可視化模型開(kāi)發(fā)為主的開(kāi)發(fā)方式，區別于傳統的以文本編碼為媒介的代碼開(kāi)發(fā)。采用模型化的方式來(lái)描述控制算法設計，無(wú)論是可讀性、可維護性、可移植性、測試驗證的便利性等方面，相比于從前手工 C 代碼都有長(cháng)足的進(jìn)步?；谝陨匣谀Ｐ烷_(kāi)發(fā)的特點(diǎn)基于 Simulink 的模型化 + 自動(dòng)代碼生成的開(kāi)發(fā)方式在汽車(chē)電子行業(yè)正在逐漸演變成開(kāi)發(fā)的標準配置。接踵而來(lái)如何保證 MBD 開(kāi)發(fā)方式下軟件質(zhì)量問(wèn)題也成為現階段人們熱議的話(huà)題。

       針對軟件質(zhì)量直接有效的手段便是開(kāi)展完備的測試或在軟件開(kāi)發(fā)過(guò)程中優(yōu)化軟件結構減少問(wèn)題的引入。

 如何開(kāi)展完備的模型測試？

       模型驗證方法可以分為靜態(tài)驗證和動(dòng)態(tài)驗證，模型靜態(tài)驗證，是一種通過(guò) MAAB 和 dSPACE 等建模公司提供的建模規則指南來(lái)驗證模型設計是否符合規則的測試方法。此外，還有一種模型度量元指標檢查方法，可以分析模型的復雜程度，以此評判模型在可維護性、可移植性、可重用性等不同維度的質(zhì)量特性。綜上所述，在模型靜態(tài)驗證部分，可以看出有兩種方法：建模規范規則檢查和模型度量元指標檢查。與模型靜態(tài)驗證不同，模型動(dòng)態(tài)驗證可以通過(guò)比較在執行實(shí)際模型時(shí)的輸出值來(lái)進(jìn)行驗證。通過(guò)根據用戶(hù)輸入預期結果值對比實(shí)際模型結果值來(lái)動(dòng)態(tài)驗證模型。通過(guò)檢查模型的覆蓋率，可以提高測試用例針對需求的覆蓋率以及測試用例的充分性。此外借助 ASPICE 過(guò)程管理的思維，在整個(gè)測試過(guò)程中加入過(guò)程管理思維，確保測試過(guò)程、測試環(huán)境、測試策略的可靠性以及測試用例的充分性、一致性、追溯性，以此確保模型質(zhì)量。

如何優(yōu)化軟件結構？

       現階段我們模型生成的代碼是否會(huì )存在以下問(wèn)題：

       · 生成代碼一個(gè)函數可能會(huì )上萬(wàn)行代碼

       · 看不懂 matlab 生成代碼后的變量的定義及過(guò)程轉化

       · 要不要針對模型生成的代碼做修改

       優(yōu)化軟件的前提是已經(jīng)開(kāi)展靜態(tài)測試優(yōu)化完畢模型結構。確保模型結構的規范性。針對每一個(gè)軟件設計單元生成獨立函數、每一個(gè)軟件組件生成與之相對應的 C 文件可以確保模型生成代碼的結構清晰。同時(shí)不對模型生成的代碼做任何的修改是 MBD 開(kāi)發(fā)過(guò)程中的軟件維護準則。

       綜上讓我們一起來(lái)期待恒潤針對 MBD 開(kāi)發(fā)模式下的軟件質(zhì)量評估與優(yōu)化的解決方案。

復雜場(chǎng)景下的 ECU 性能壓力測試方案

       隨著(zhù)控制器數量的激增和模塊交互復雜度的提升，只針對軟件基礎功能驗證的效果存在一定的缺陷，越來(lái)越多的項目實(shí)踐表明，軟件的偶發(fā)性故障需要從軟件性能指標、壓力場(chǎng)景來(lái)進(jìn)行補充驗證，以確保軟件產(chǎn)品的質(zhì)量。

       性能測試針對 ECU 電控軟件的內存（堆棧、RAM/ROM/FLASH）、CPU 負載進(jìn)行最差工況的分析，保證資源占用的合理性；壓力測試構建通信、IO 驅動(dòng)、診斷、網(wǎng)絡(luò )管理等模塊的異常注入、總線(xiàn)故障、高頻觸發(fā)等場(chǎng)景，保證軟件功能在壓力場(chǎng)景下不存在致命風(fēng)險。

基于 AbsInt 的靜態(tài)性能分析

? 客戶(hù)收益

       · 評估資源使用率，指導芯片選型和工程優(yōu)化

       · 保證軟件的任務(wù)、中斷預留堆?？臻g和分配周期合理性

       · 保證芯片內存占用率和 CPU 負載在閾值范圍內

       · 開(kāi)展符合功能安全和 ASPICE 流程要求的測試

? 測試內容

       · 內存：自動(dòng)化分析最差工況的堆棧用量、RAM/ROM/Flash 占用率

       · WCET：分析最差工況下的執行時(shí)間，測試周期穩定性和任務(wù)實(shí)時(shí)性

       · 調度仿真：模擬任務(wù)調度，建模仿真 CPU 負載率和任務(wù)占比

? 方案特點(diǎn)

       · 借助 AbsInt 工具，針對工程二進(jìn)制可執行文件進(jìn)行自動(dòng)化分析，無(wú)需依賴(lài)源碼

       · 支持 PPC、V850、Tricore、ARM 等多種架構芯片的堆棧、時(shí)間分析

       · 分析遍歷工況，結果涵蓋程序的各個(gè)入口

       · 圖形化展示最差工況下的執行路徑和占比用量，指導性能優(yōu)化

       · 不依賴(lài)測試用例，執行效率高，項目周期短

       · AbsInt 工具滿(mǎn)足 ASIL D 等級功能安全標準

基于 AbsInt 的測試流程

函數調用關(guān)系及用量顯示

數據化表格用量展示

 基于 RVS 的動(dòng)態(tài)性能測試

? 客戶(hù)收益

       · 在 PIL、HIL、車(chē)載環(huán)境下進(jìn)行時(shí)序分析，確保軟件行為安全

       · 可視化監測任務(wù)調度和 CPU 負載，為系統升級提供優(yōu)化參考

       · 保證多任務(wù)和多核運行的合理性，規避優(yōu)先級反轉、死鎖等時(shí)序問(wèn)題

       · 開(kāi)展符合功能安全和 ASPICE 流程要求的測試

? 測試內容

       · WCET：分析任務(wù) / 中斷的最差工況執行時(shí)間，測試周期穩定性和響應實(shí)時(shí)性

       · 任務(wù)調度：評估 WCRT，監測任務(wù)時(shí)序特征，圖形化顯示多核、多任務(wù)調度關(guān)系

       · 負載率：基于實(shí)際工況對 CPU 負載率進(jìn)行實(shí)時(shí)統計和分析，評估極限負載下的 CPU 負載率占用情況

? 方案特點(diǎn)

       · 借助 RVS 分析套件進(jìn)行實(shí)時(shí)數據采集和分析，還原實(shí)際環(huán)境下的執行工況

       · 支持全量數據采集和長(cháng)時(shí)間監測運行，追蹤定位軟硬件交互情況

       · 自定義程度高，項目復用性強，可針對任意函數、模塊或代碼段進(jìn)行時(shí)序分析

       · 支持集成多種處理器 + 編譯器環(huán)境，實(shí)現 PIL/HIL/ 車(chē)載環(huán)境下分析

       · RVS 工具可以支持產(chǎn)品功能安全認證等級 ASIL D

基于 RVS 的測試流程

時(shí)序調度分析

 基于自動(dòng)化測試框架的壓力測試

? 客戶(hù)收益

       · 保證通信、診斷、操作系統、IO 驅動(dòng)、網(wǎng)絡(luò )管理等模塊在壓力場(chǎng)景下不存在致命風(fēng)險

       · 作為功能驗證的補充，發(fā)現軟件質(zhì)量潛在問(wèn)題，確保軟件魯棒性、穩定性

       · 構建標準化的壓力測試用例模板，有助于形成符合功能安全要求的測試流程

       · 測試用例搭載自動(dòng)化測試框架進(jìn)行測試執行、用例管理、問(wèn)題追溯

? 測試內容

       · 針對 NVM、IO 驅動(dòng)、CAN、LIN、ETH、COM 等模塊進(jìn)行壓力場(chǎng)景構建

       · 分析系統不同組件間的時(shí)延特性，驗證模塊運行時(shí)間穩定性

       · 驗證在異常注入、高頻觸發(fā)、總線(xiàn)故障等因素影響下的功能穩定性

       · 驗證極限工況下的核心功能有效性及軟件后續響應的合理性

? 方案特點(diǎn)

       · 借助自動(dòng)化測試框架執行測試用例，測試周期短、測試效率高、測試復用性強

       · 支持軟硬件交互，可監測底層函數、上層報文、外部信號等

       · 支持在 PIL/HIL 環(huán)境下開(kāi)展測試，可同步注入多種激勵進(jìn)行測試驗證

測試流程示意

測試框架示意

了解更多

       請致電 010-64840808轉6116 或發(fā)郵件至market_dept@hirain.com（聯(lián)系時(shí)請說(shuō)明來(lái)自EEPW）