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

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

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

符合 AutoSar 架構(gòu)的應(yīng)用軟件開發(fā)介紹

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

那對于應(yīng)用層軟件來說，如果要開發(fā)符合 AutoSar 架構(gòu)的軟件，需要考慮以下兩個重要問題：

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

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

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

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

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

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

MBD 全稱是 Model Based Design（基于模型設(shè)計），是一種以可視化模型開發(fā)為主的開發(fā)方式，區(qū)別于傳統(tǒng)的以文本編碼為媒介的代碼開發(fā)。采用模型化的方式來描述控制算法設(shè)計，無論是可讀性、可維護(hù)性、可移植性、測試驗證的便利性等方面，相比于從前手工 C 代碼都有長足的進(jìn)步。基于以上基于模型開發(fā)的特點基于 Simulink 的模型化 + 自動代碼生成的開發(fā)方式在汽車電子行業(yè)正在逐漸演變成開發(fā)的標(biāo)準(zhǔn)配置。接踵而來如何保證 MBD 開發(fā)方式下軟件質(zhì)量問題也成為現(xiàn)階段人們熱議的話題。

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

如何開展完備的模型測試？

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

如何優(yōu)化軟件結(jié)構(gòu)？

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

·生成代碼一個函數(shù)可能會上萬行代碼

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

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

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

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

復(fù)雜場景下的 ECU 性能壓力測試方案

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

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

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

?客戶收益

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

·保證軟件的任務(wù)、中斷預(yù)留堆棧空間和分配周期合理性

·保證芯片內(nèi)存占用率和 CPU 負(fù)載在閾值范圍內(nèi)

·開展符合功能安全和 ASPICE 流程要求的測試

?測試內(nèi)容

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

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

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

?方案特點

·借助 AbsInt 工具，針對工程二進(jìn)制可執(zhí)行文件進(jìn)行自動化分析，無需依賴源碼

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

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

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

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

·AbsInt 工具滿足 ASIL D 等級功能安全標(biāo)準(zhǔn)

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

?客戶收益

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

·可視化監(jiān)測任務(wù)調(diào)度和 CPU 負(fù)載，為系統(tǒng)升級提供優(yōu)化參考

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

·開展符合功能安全和 ASPICE 流程要求的測試

?測試內(nèi)容

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

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

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

?方案特點

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

·支持全量數(shù)據(jù)采集和長時間監(jiān)測運行，追蹤定位軟硬件交互情況

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

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

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

基于自動化測試框架的壓力測試

?客戶收益

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

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

·構(gòu)建標(biāo)準(zhǔn)化的壓力測試用例模板，有助于形成符合功能安全要求的測試流程

·測試用例搭載自動化測試框架進(jìn)行測試執(zhí)行、用例管理、問題追溯

?測試內(nèi)容

·針對 NVM、IO 驅(qū)動、CAN、LIN、ETH、COM 等模塊進(jìn)行壓力場景構(gòu)建

·分析系統(tǒng)不同組件間的時延特性，驗證模塊運行時間穩(wěn)定性

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

·驗證極限工況下的核心功能有效性及軟件后續(xù)響應(yīng)的合理性

?方案特點

·借助自動化測試框架執(zhí)行測試用例，測試周期短、測試效率高、測試復(fù)用性強

·支持軟硬件交互，可監(jiān)測底層函數(shù)、上層報文、外部信號等

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