我們都看過很多汽車廣告，展示了一輛汽車猛烈撞擊障礙物，以及它的安全特性如何挽救車內碰撞測試假人的生命。這些演示僅展示了汽車進行的測試的一部分，尤其是在其開發(fā)結束時。早在一輛全新的汽車撞上障礙物之前，就必須對機器的每一個部件進行全面測試。隨著汽車技術的進步和車輛架構變得越來越復雜，這只會變得更具挑戰(zhàn)性。

汽車開發(fā)商在過去 100 年中取得了顯著進步。從機械改進到電子進步，再到最近的軟件創(chuàng)新，一切都推動了從系統(tǒng)到芯片的顛覆。這也增加了能夠驗證、測試和模擬真實駕駛艙行為的軟件平臺的重要性。隨著我們越來越接近自動駕駛汽車，軟件定義車輛的成功正以驚人的速度增長，其功能和特性從根本上由軟件實現(xiàn)。

這導致汽車原始設備制造商及其供應商在試圖跟上已經(jīng)競爭激烈的市場環(huán)境中的進步時變得越來越復雜。對于芯片設計人員和驗證團隊來說，現(xiàn)代汽車幾乎每一個部件的組件都需要經(jīng)過嚴格的測試和驗證，以確保安全性、可靠性和質量，并確保軟件在每個組件上都能按預期正常運行——復合挑戰(zhàn)。結果是工程師的測試時間延長，開發(fā)人員在整個開發(fā)周期中的反饋時間更長。

電子控制單元：具有局限性的核心組件

電子控制單元 (ECU) 是半導體芯片上的嵌入式系統(tǒng)，運行軟件以實現(xiàn)各種功能。它們提供多種功能，從發(fā)動機控制和剎車燈等必需品，到用于展開安全氣囊和鎖門的安全和安保功能，再到讓您自定義汽車座椅角度和溫度的舒適功能。

傳統(tǒng)上，直到今天，汽車軟件開發(fā)都遇到了幾個瓶頸。除了處理正在進行的軟件改進之外，使用基于硬件的開發(fā)方法意味著在您擁有可用于測試的更新的 .hex 文件、傳輸以十六進制格式保存且通常由微控制器單元使用的數(shù)據(jù)之前，幾個團隊之間的軟件循環(huán)和如果您在循環(huán)中有其他供應商，則需要更多天或數(shù)周。一旦更新的文件上傳到電子控制單元，就需要進一步的工具來運行、測量和校準軟件。

可能有 100 多個這樣的單元控制您駕駛的汽車，最常見于以下系統(tǒng)：

· 動力總成

· 穩(wěn)定性控制

· 車身控制

· 剎車

· 操舵

· 高級駕駛輔助系統(tǒng)(ADAS)

隨著汽車制造商不斷創(chuàng)新車輛設計和功能，必須開發(fā)新的 ECU。隨著每一次新的開發(fā)，測試這些 ECU 及其功能變得越來越困難。昂貴設備的資源成本和緊迫的工程師工作量是制造商的主要障礙(更不用說測試過程中發(fā)現(xiàn)的錯誤導致硬件損壞的后果)。工程師受限于他們可以通過原型運行測試來實現(xiàn)什么，并且硬件在環(huán)仿真 (HiL) 的結果是不確定的，從而導致多個測試產(chǎn)生不同的結果。缺乏確認的測試結果會導致更多的測試、時間損失和更多的成本?？紤]到車輛擁有的數(shù)百個 ECU 以及傳統(tǒng)的開發(fā)方法，是不可行的。

通過虛擬化使代碼栩栩如生

解決方案?構建稱為虛擬 ECU 的基于軟件的測試環(huán)境，允許工程師將他們的開發(fā)任務從道路和測試臺轉移到 PC 環(huán)境。

將此開發(fā)虛擬化可顯著減少測試時間和成本。在不冒硬件暴露風險的情況下，開發(fā)人員可以在幾分鐘內進行測試并收到反饋。這遵循左移方法，這是一種通過更快地優(yōu)先考慮軟件開發(fā)并排除功能硬件模型開發(fā)和驗證軟件所需的等待時間來加速開發(fā)的實踐。這種策略促使開發(fā)人員在設計完成之前更早地發(fā)現(xiàn)問題——允許更快地修復錯誤(在將它們安裝到硬件中之前)以加快交付速度。

傳統(tǒng)汽車開發(fā)過程的連續(xù)性意味著需要先開發(fā) ECU，然后再開發(fā)軟件，這對嚴格的上市時間安排造成壓力。使用Triple Shift Left方法，團隊可以實施仿真和共享模型，以便及早在虛擬平臺上開發(fā)軟件，從而促進整個汽車供應鏈的協(xié)作。根據(jù)最終用例和源代碼的可用性，可以將 ECU 軟件的不同部分移植到 PC 上，并在多個工作臺上同時進行測試(并行)。

當今的先進車輛通常包含超過 1 億行代碼，需要 100 多個 ECU 來實現(xiàn)功能。通過利用 Triple Shift Left 方法，團隊可以在硬件可用之前通過虛擬化 ECU 顯著加快開發(fā)和設計周期，所有這些都不會影響功能安全性、可靠性和質量。

使用虛擬 ECU 在幾分鐘內獲得反饋

借助 Synopsys Silver虛擬 ECU 平臺，開發(fā)人員可以通過啟動虛擬化環(huán)境來構建 ECU，以測試 ECU 軟件堆棧的各個方面。只需在 PC 上，您就可以使用物理 ECU 的應用程序代碼來構建虛擬 ECU，從而縮短開發(fā)過程的多個方面。Silver 還作為一個強大的平臺，通過仿真測試和驗證聯(lián)網(wǎng) ECU、變速器、汽車部件和發(fā)動機的交互。

在構建虛擬 ECU 時，開發(fā)人員有多種選擇。大多數(shù)情況下，它們從 C 代碼庫生成虛擬 ECU，但它們可以從其他來源派生，包括模擬模型。負責一項任務(例如芯片模擬項目)的開發(fā)人員通常無法完全訪問應用程序代碼，但仍可以使用 Silver 從編譯的二進制代碼創(chuàng)建虛擬 ECU 并將其閃存到目標上。構建過程甚至可以自動化。

讓我們看一個 C 代碼項目虛擬 ECU 的示例。上圖左側是用戶編寫的示例配置文件，指定編譯器(即 Visual Studio)和目錄、任務和輸入/輸出。用戶將其插入 Silver 中的 SBS 工具以及任何附加文件，例如 A2L 和 DBC 的規(guī)范，具體取決于 ECU。Silver 平臺然后從配置文件創(chuàng)建一個虛擬 ECU，并從物理 ECU 克隆應用層，提供操作系統(tǒng)仿真、虛擬內存、A2L 轉換、XCP 連接和閃存。

一旦構建完成，虛擬 ECU 就會在整個開發(fā)過程中為工程師提供各種功能，例如：

· 通過手動測試和調試在系統(tǒng)環(huán)境中即時反饋

· 從模塊級到虛擬系統(tǒng)級的自動化測試

· 大覆蓋測試和驗證

· 優(yōu)化設計參數(shù)

· PC預校準(與車內校準界面相同)

· 應用程序的實時運行：快速控制原型、混合虛擬和真實組件等。

為了克服軟件密集型車輛系統(tǒng)的復雜性，我們認為通過將軟件開發(fā)步驟從原型車、測試臺和 HiL(硬件在環(huán))轉移到功能開發(fā)人員的 PC 來實現(xiàn)開發(fā)過程的虛擬化至關重要. 持續(xù)集成也是虛擬 ECU 的一個關鍵方面。與多個持續(xù)集成工具(即 Jenkins)集成后，開發(fā)人員可以持續(xù)測試代碼更改，并立即反饋更新是否有效。對于等待軟件更新完成后再安裝到車輛上的工程團隊來說，這可以節(jié)省大量時間——防止硬件風險并加快測試過程。

展望未來

在軟件定義汽車時代，汽車行業(yè)有望在 ADAS 技術方面取得更多進步，幾乎無限可能。每年，看到全自動駕駛汽車在我們身邊行駛的承諾似乎都可以實現(xiàn)。

為了讓社會信任自動駕駛汽車，它們必須盡可能接近完美。防止錯誤和系統(tǒng)故障的很大一部分責任落在了設計支持這些技術的底層軟件的開發(fā)人員身上。虛擬 ECU 幫助他們做到這一點——更快、更便宜。通過虛擬化測試環(huán)境，工程師可以通過持續(xù)集成和最大部署效率來減少他們的開發(fā)時間(和成本)。

作為汽車向自動駕駛汽車發(fā)展的未來，虛擬 ECU 將成為團隊在無需額外硬件的情況下進行驗證和測試并加速汽車軟件開發(fā)的關鍵推動力。