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

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

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

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

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

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

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

· 動力總成

· 穩(wěn)定性控制

· 車身控制

· 剎車

· 操舵

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

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

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

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

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

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

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

使用虛擬 ECU 在幾分鐘內(nèi)獲得反饋

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

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

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

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

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

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

· 大覆蓋測試和驗證

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

· PC預(yù)校準(zhǔn)(與車內(nèi)校準(zhǔn)界面相同)

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

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

展望未來

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

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

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