由于大流行，大多數（如果不是全部）工人都經歷了在家工作（WFH），導致傳統開發和全球協作方法暫時停止。需要軟件和硬件團隊協作的替代方式。在保持社交距離的時代，遠程開發可能是一項挑戰，因為訪問遠程和稀缺的硬件以及開發和測試系統很困難。一種可行的解決方案可能是虛擬原型設計，它可以用硬件的軟件等效模型替換硬件；隨時隨地。

對于開發下一代無線、消費類和汽車設備的半導體和 OEM 公司而言，日益復雜的硬件和軟件的集成是一項重大挑戰。序列化硬件和軟件開發的傳統方法——在芯片設計完成后開發和驗證絕大多數軟件——通常無法滿足激進的產品開發計劃。虛擬原型是完整系統的快速、功能齊全的軟件模型，可以執行未經修改的生產代碼并提供無與倫比的調試效率。

汽車公司的解決方案應該能夠將設計和集成測試結合到一個虛擬原型平臺中。用戶可以確定設計和集成過程是否會成功，而不是通常會導致在集成測試中發現設計問題的開環設計過程。這里選擇的平臺是 VisualSim Architect （VSA），它可以通過對完整的端到端設計進行建模，通過閉環設計/集成流程來實現這一目標。端到端設計使用許多預構建、預測試的汽車庫，這些庫生成預定義的報告以加速開發和集成測試。用戶可以評估延遲、吞吐量、子系統利用率和關鍵子系統的功率。

其他汽車解決方案專注于算法測試、軟件開發和軟件測試。這些解決方案可用作指令集模擬器以在沒有板的情況下執行軟件代碼，SysML 可記錄軟件序列、C 代碼生成、數學正確性模型以及通過在原型板上加載軟件來測試解決方案。

上述解決方案在設計過程的后期使用。硬件和軟件故障的發生是由于規格不正確而不是制造不正確。這些替代解決方案正在針對不完善的規范驗證正確性。功能安全測試在設計周期的后期進行，制造變更會影響產品質量。當前的技術不允許跨真正的分布式系統出現多次故障。在集成或軟件開發階段對架構進行大規模更改是耗時、昂貴的，并且會延遲進度。

VisualSim 滿足以下標準：

優化規范以滿足時序、功耗和功能。

為 OEM 和供應商創建一個通用的可執行規范。

引入 ISO-26262 第 4、5 和 6 部分用于設計和驗證。

集成現有工具和模擬器，包括 MatLab 和 C 代碼，以進行時間驅動的分析。

支持的故障類型包括：

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

硬件故障：完全關閉電路板或核心故障

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

軟件故障：修改內存值、資源匱乏

RTOS 失敗：先前任務的溢出導致當前任務失敗

網絡故障：網絡內的消息損壞或擁塞

網絡安全：模擬攻擊并評估系統吞吐量的算法質量

分析硬件故障模型

根據 ISO 26262，不同的故障分為硬件、軟件、網絡、RTOS 和電源。我們將占用一個來分析它的結果。處理核心的丟失、存儲受限、內存設備減少或丟失或總線過載/錯誤信號、硬件資源、內存和總線接口的共享和獨占使用都可能在硬件故障下進行說明。

通過使用系統建模工具，我們可以在具有大型硬件和軟件建模組件庫的圖形離散事件仿真平臺中非常快速地組裝虛擬原型。該原型用于提供支持以根據標準測試架構、識別系統中不可恢復的故障并提供早期反饋、進行時間、吞吐量、功耗和服務質量權衡。該模型生成故障，測試系統的行為，并以符合標準要求的電子表格或圖形格式報告結果。

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

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

資源故障：如果其中一個資源發生故障，必須在剩余資源之間進行負載均衡。對該模型的分析是時間期限和緩沖區使用量的增加。

通過設置頂級模型參數，可以啟用所選的汽車平臺進行設計、集成測試或兩者兼而有之。這樣，開發和集成測試可以同時進行。設計小組可以改進其端到端模型版本的集成問題，而集成測試可以繼續測試設計的先前端到端模型。這減少了兩組的松弛時間。在最終版本中，所有的設計約束都將得到滿足，所有的集成測試都將在一個統一的平臺上得到滿足。管理層可以更有信心繼續制造原型或制造工廠。

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

虛擬原型通過在規范階段識別錯誤、電子設備的大小、配置網絡拓撲、構建分布式應用程序、測試時間期限、確定多次故障時的可靠性以及軟件輸出的正確性，消除了集成過程中的意外。生成的報告用于設計新診斷、驗證現有診斷并添加測試以符合 ISO26262。原型平臺集成了系統設計人員、硬件架構師和軟件開發人員，以實現單一定義，并成為 OEM、一級供應商和軟件供應商之間的標準通信媒介。

模型輸出是經過充分驗證的技術數據，可作為早期認證過程的證據。當硬件和軟件不可用時，該原型是在設計過程的早期構建的。該原型可以及早識別、確定優先級和最小化系統規范，以及系統行為中的故障和錯誤。該虛擬原型可幫助公司根據車輛、功能、清單和價格點的需求維護單一代碼庫和細分。

用戶從抽象架構模型開始，在可用時添加更多細節，可視化分布式系統行為，架構硬件需求，并評估時間期限。該方法從應用程序的虛擬模型開始。應用程序的任務被映射到 ECU 資源模型的網絡上。該模型用于識別系統瓶頸，創建應用程序的最佳映射，并獲得基本的硬件要求。可以將任務映射到不同的配置，并且可以針對不同的故障模式、最低性能要求和任務序列流的跟蹤對模型進行測試。

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

作者：Deepak Shankar，Mohini Yadav

審核編輯：郭婷