作者：Deepak Shankar，Mohini Yadav

由于大流行，大多數(shù)（如果不是全部）員工都經(jīng)歷過在家工作 （WFH），導致傳統(tǒng)開發(fā)和全球協(xié)作方法暫時停止。需要軟件和硬件團隊協(xié)作的替代方式。在保持社交距離的時代，遠程開發(fā)可能是一個挑戰(zhàn)，因為訪問遠程和恐嚇硬件以及用于開發(fā)和測試的系統(tǒng)很困難。一個可行的解決方案可能是虛擬原型設(shè)計，可以用硬件的軟件等效模型替換硬件;隨時隨地。

日益復雜的硬件和軟件的集成是半導體和OEM公司開發(fā)下一代無線、消費和汽車設(shè)備的重大挑戰(zhàn)。傳統(tǒng)的序列化硬件和軟件開發(fā)方法（絕大多數(shù)軟件在芯片設(shè)計完成后進行開發(fā)和驗證）往往無法滿足緊迫的產(chǎn)品開發(fā)計劃。虛擬原型是完整系統(tǒng)的快速、功能齊全的軟件模型，可執(zhí)行未經(jīng)修改的生產(chǎn)代碼并提供無與倫比的調(diào)試效率。

汽車公司的解決方案應該能夠?qū)⒃O(shè)計和集成測試結(jié)合到一個虛擬原型平臺中。用戶可以確定設(shè)計和集成過程是否會成功，而不是在集成測試中經(jīng)常導致設(shè)計問題的開環(huán)設(shè)計過程。這里選擇的平臺是 VisualSim 架構(gòu)師 （VSA），它可以通過閉環(huán)設(shè)計/集成流程來實現(xiàn)這一點，因為它能夠?qū)ν暾亩说蕉嗽O(shè)計進行建模。端到端設(shè)計使用許多預構(gòu)建、預測試的汽車庫，這些庫生成預定義的報告以加快開發(fā)速度以及集成測試。用戶可以評估延遲、吞吐量、子系統(tǒng)利用率和關(guān)鍵子系統(tǒng)的功耗。

其他汽車解決方案專注于算法測試、軟件開發(fā)和軟件測試。這些解決方案可作為指令集模擬器提供，無需開發(fā)板即可執(zhí)行軟件代碼，SysML 可記錄軟件序列、C 代碼生成、數(shù)學正確性模型，并通過在原型板上加載軟件來測試解決方案。

上述解決方案在設(shè)計過程的后期使用。硬件和軟件故障是由于不正確的規(guī)格而不是不正確的制造而發(fā)生的。這些替代解決方案正在驗證針對不完美規(guī)范的正確性。功能安全測試在設(shè)計周期的后期進行，制造變更會影響產(chǎn)品質(zhì)量。當前的技術(shù)不允許在真正的分布式系統(tǒng)中發(fā)生多次故障。在集成或軟件開發(fā)階段對體系結(jié)構(gòu)進行大規(guī)模更改既耗時又昂貴，并且會延遲進度。

VisualSim滿足以下標準：

優(yōu)化規(guī)格以滿足時序、功耗和功能要求。

為 OEM 和供應商創(chuàng)建通用的可執(zhí)行規(guī)范。

引入了 ISO-26262 第 4、5 和 6 部分，用于設(shè)計和驗證。

集成現(xiàn)有工具和模擬器，包括 MatLab 和 C 代碼，以實現(xiàn)時間驅(qū)動的分析。

支持的故障類型包括：

電源故障：突然的電源尖峰，電池壽命縮短

硬件故障：電路板完全關(guān)閉或核心故障

冗余影響：在發(fā)生故障時處理增加的負載

軟件故障：內(nèi)存值修改、資源匱乏

RTOS 失敗：上一個任務的溢出導致當前任務失敗

網(wǎng)絡故障：消息損壞或網(wǎng)絡擁塞

網(wǎng)絡安全：模擬攻擊并評估系統(tǒng)吞吐量的算法質(zhì)量

分析硬件故障模型

根據(jù) ISO 26262，不同的故障分為硬件、軟件、網(wǎng)絡、RTOS 和電源。我們將采用一個來分析其結(jié)果。處理內(nèi)核丟失、存儲有限、存儲設(shè)備減少或丟失或總線過載/信號不正確、硬件資源、內(nèi)存和總線接口的共享和獨占使用都可能是硬件故障的原因。

通過使用系統(tǒng)建模工具，我們可以在具有大型硬件和軟件建模組件庫的圖形離散事件仿真平臺中非?？焖俚亟M裝虛擬原型。該原型用于提供支持，以根據(jù)標準測試架構(gòu)，識別系統(tǒng)中不可恢復的故障并提供早期反饋，進行時序、吞吐量、功耗和服務質(zhì)量權(quán)衡。該模型生成故障，測試系統(tǒng)的行為，并以符合標準要求的電子表格或圖形格式報告結(jié)果。

從三個流量塊生成的數(shù)據(jù)包（任務）映射到資源 （CPU） 1、2 和 3 進行處理。與此模型集成的兩種故障場景：

資源不可用：如果將進程分配給沒有任何內(nèi)存來處理任務的資源，則會生成錯誤。例如，如果資源 1 的緩沖區(qū)長度為 30，并且緩沖區(qū)已滿，則在處理未完成的數(shù)據(jù)包之前，它無法接受新數(shù)據(jù)包。

資源失?。喝绻渲幸粋€資源發(fā)生故障，則必須在剩余資源之間平衡負載。對該模型的分析是時序截止時間和緩沖區(qū)使用量的增加。

通過設(shè)置頂級模型參數(shù)，可以啟用所選的汽車平臺進行設(shè)計、集成測試或兩者兼而有之。這樣，開發(fā)和集成測試可以同時執(zhí)行。設(shè)計組可以改進其端到端模型版本的集成問題，而集成測試可以繼續(xù)測試設(shè)計的先前端到端模型。這減少了兩組的閑暇時間。在最終版本中，將滿足所有設(shè)計約束，并在統(tǒng)一平臺中滿足所有集成測試。管理層可以對繼續(xù)制造原型或制造工廠更有信心。

所使用的平臺包含模擬電子設(shè)備、軟件任務、流量和傳感器、C 代碼包裝器、自定義模型生成器和電源的庫組件。生成的報告包括延遲、緩沖區(qū)占用、吞吐量、功耗、電池使用情況和生命周期以及執(zhí)行跟蹤。該平臺應使設(shè)計人員能夠從軟件的抽象模型開始，將應用程序映射到目標分布式硬件平臺，模擬測試以達到規(guī)范，在軟件可用后評估軟件結(jié)果的正確性，并在部署后從現(xiàn)場回放跟蹤。

虛擬原型通過識別規(guī)范階段的錯誤、電子設(shè)備的尺寸、配置網(wǎng)絡拓撲、構(gòu)建分布式應用程序、測試時序截止時間、確定發(fā)生多次故障時的可靠性以及軟件輸出的正確性，消除了集成過程中的意外情況。生成的報告用于設(shè)計新的診斷，驗證現(xiàn)有診斷，并添加符合ISO26262的測試。原型平臺集成了系統(tǒng)設(shè)計人員、硬件架構(gòu)師和軟件開發(fā)人員，以處理單個定義，并成為 OEM、一級供應商和軟件供應商之間的標準通信媒介。

模型輸出是經(jīng)過充分驗證的技術(shù)數(shù)據(jù)，可以作為早期認證過程的證據(jù)。該原型是在硬件和軟件不可用的設(shè)計過程的早期構(gòu)建的。該原型能夠及早識別、確定優(yōu)先級和最小化系統(tǒng)規(guī)格，以及系統(tǒng)行為中的故障和錯誤。該虛擬原型可幫助公司根據(jù)車輛、功能、列表和價格點的需求維護單個代碼庫和細分。

用戶從抽象的體系結(jié)構(gòu)模型開始，在可用時添加更多詳細信息，可視化分布式系統(tǒng)行為，構(gòu)建硬件要求并評估計時截止時間。該方法從應用程序的虛擬模型開始。應用程序的任務映射到ECU資源模型網(wǎng)絡上。此模型用于識別系統(tǒng)瓶頸，創(chuàng)建應用程序的最佳映射，并獲取基本硬件要求?？梢詫⑷蝿沼成涞讲煌呐渲?，并且可以針對不同的故障模式、最低性能要求和任務序列流的跟蹤來測試模型。

在這種VisualSim方法中，軟件是使用傳統(tǒng)方法開發(fā)的。MatLab/Simulink 模型或軟件可以在可用時替換抽象模型。當數(shù)據(jù)由于網(wǎng)絡擁塞而延遲到達時，可以測試這些模型的結(jié)果的正確性，更高優(yōu)先級的任務搶占流，并研究分布式系統(tǒng)中存在多個故障時的行為。硬件模型還可以捕獲詳細的ECU設(shè)計，并評估資源效率和功耗。部署后，同一模型可用于在現(xiàn)場回放操作并確定故障原因。

審核編輯：郭婷