【ZiDongHua 之駕駛自動化收錄關(guān)鍵詞：MathWorks   電動汽車    汽車行業(yè)    ECU 】
　　
　　開發(fā)和交付新一代軟件定義汽車
　　
　　作者 Jim Tung, MathWorks
　　
　　算法無需由實時調(diào)度器調(diào)用，即可部署在面向服務的架構(gòu)中，并通過 API 調(diào)用進行調(diào)用。鑒于這種轉(zhuǎn)變，基于模型的設(shè)計工具已更新，不但支持基于信號的接口，而且還支持面向服務的架構(gòu)。
　　
　　◆  ◆  ◆  ◆
　　
　　下一代汽車將是率先通過軟件傳遞品牌特色和客戶價值的汽車。連接、自主性和電氣化方面的新技術(shù)，是這些軟件定義汽車 (SDV) 的核心。這些技術(shù)將不斷涌現(xiàn)，以應對客戶對移動性不斷變化的期望。這些創(chuàng)新背后的軟件，無論是面向客戶的還是在后臺運行的軟件，都需要大量的投資。它還代表著新的機遇，因為各公司不斷發(fā)展自身能力，以提供附加 App 和服務，更不用說安全和其他關(guān)鍵更新了。
　　
　　多年以來，在提高車輛性能和安全性方面，軟件無疑一直發(fā)揮著重要作用。這種嵌入式軟件與物理系統(tǒng)緊密綁定并部署在 ECU 上，因此需要很高的可靠性。通常，它還必須符合過程模型（包括 Automotive SPICE®）以及功能安全標準（如 ISO® 26262）。許多汽車 OEM 和供應商都擅長使用基于模型的設(shè)計，以通過仿真以及隨后的代碼生成和驗證對設(shè)計進行早期驗證，從而加速此軟件的交付（圖 1）。
　　
　　
　　
　　圖 1. 基于模型的設(shè)計有助于更早地發(fā)現(xiàn)并修復系統(tǒng)和軟件缺陷。
　　
　　對于 SDV，軟件發(fā)揮著更加重要的作用。為此，組織需要做好規(guī)劃，以在車輛投產(chǎn)后持續(xù)改進和更新軟件。他們需要整合從聯(lián)網(wǎng)車輛收集的運營數(shù)據(jù)，以便推動這種持續(xù)改進。此外，他們還需要擴展用于衡量成功的關(guān)鍵性能指標 (KPI) 集，也就是用開發(fā)運營一體化方面的更多度量（包括改動失敗率和從事故中恢復的平均時間）作為傳統(tǒng)度量（如開發(fā)速度）的有力補充。
　　
　　完成上述任務需要轉(zhuǎn)變心態(tài)。眾多汽車公司面臨的問題是：我們的軟件開發(fā)和系統(tǒng)開發(fā)團隊和過程需要做何改變，以及基于模型的設(shè)計如何發(fā)展才能應對這些變化？
　　
　　基于模型的設(shè)計如何發(fā)展以適應 SDV 開發(fā)
　　
　　迄今為止，工程團隊最常使用基于模型的設(shè)計來針對嵌入式系統(tǒng)進行開發(fā)。在許多情況下，這意味著在資源受限的 ECU 或微控制器上難以實時實現(xiàn)算法（用信號流表示）。現(xiàn)在，除了 ECU，目標還包括 SDV 的中央或區(qū)域計算機以及云。此外，算法無需由實時調(diào)度器調(diào)用，即可部署在面向服務的架構(gòu)中，并通過 API 調(diào)用進行調(diào)用。鑒于這種轉(zhuǎn)變，基于模型的設(shè)計工具已更新，不但支持基于信號的接口，而且還支持面向服務的架構(gòu)。
　　
　　這些工程團隊習慣于使用基于模型的設(shè)計，專注于設(shè)計、實現(xiàn)和驗證，并在人工驅(qū)動的交互式開發(fā)工作流中使用為桌面端打包的工具。展望未來，自動化將成為重中之重，并通過持續(xù)集成 (CI) 管道、Kubernetes 編排流程和類似機制發(fā)揮更大的作用。許多組織已將基于模型的設(shè)計和 CI 與自動化管道相集成，這些管道用于在提交模型更改時執(zhí)行模型驗證、代碼生成、靜態(tài)代碼分析和其他任務。
　　
　　同樣，盡管組織對使用產(chǎn)品生命周期管理 (PLM) 系統(tǒng)進行工具和資產(chǎn)管理的關(guān)注相對較少，但這種關(guān)注也在逐漸增加。如今，團隊更傾向于使用 Git™ 和 Artifactory 倉庫的主干分支方法，以敏捷方式存儲、迭代和快速改進軟件工件。軟件開發(fā)團隊使用的是更敏捷、更精細的方法。此外，這些團隊不再只是將其軟件系統(tǒng)交付到用于生產(chǎn)啟動 (SOP) 的物料清單中，還要在 SOP 后將其無線傳輸?shù)?SDV。基于模型的設(shè)計將不斷發(fā)展，以適應這些新興的開發(fā)模式。
　　
　　彌合 SDV 文化差距
　　
　　當然，任何創(chuàng)新案例，包括 SDV 案例，都不僅僅關(guān)乎一套不斷發(fā)展的工具和流程。它還涉及工具和流程的使用者，并且往往與使用者所處的組織的文化有關(guān)。在許多方面，對于使用基于模型的設(shè)計進行嵌入式軟件的系統(tǒng)工程和交付的團隊，其工作方式明顯不同于更以代碼為中心的團隊，后者更傾向于采用開發(fā)運營一體化做法。
　　
　　有些組織已著手彌合這些各行其事的常見團隊之間的分歧（圖 2）。在這些組織中，系統(tǒng)工程團隊已開始采用開發(fā)運營一體化做法。例如，在創(chuàng)建系統(tǒng)模型或場景模型時，他們通過適當?shù)牧鞒虒⒃撃Ｐ娃D(zhuǎn)交給其他人，再由這些人將其納入下游自動化過程中。另一方面，這些組織中以代碼為中心的團隊，已開始將系統(tǒng)和模型視為其工作的重要組成部分。他們認識到了仿真在將 SDV 所需的軟件和系統(tǒng)作為一個有機整體交付時的價值，并且正在學習如何將它納入自己的流程中。此外，這些組織正在采取各種措施，通過持續(xù)集成/持續(xù)交付 (CI/CD) 等公共平臺將各團隊匯聚于此。這種共享技術(shù)堆棧更易于擴展和維護，它有助于簡化對流量、速度、軟件穩(wěn)健性和系統(tǒng)嚴格性等共享 KPI 的跟蹤。
　　
　
　　
　　圖 2. 通過基于模型的設(shè)計和自動化工作流彌合以代碼為中心的團隊與系統(tǒng)工程團隊之間的鴻溝。
　　
　　真實用例
　　
　　為了更好地了解團隊如今可以采取哪些措施來加速 SDV 軟件的交付，請參考以下用例。工程團隊的任務一直是為已投入生產(chǎn)的電動汽車提供更新。此更新將實現(xiàn)一項新功能，即 Sport + 模式。該功能有助于將車輛從 0 加速到 60 英里/小時（100公里/小時）的時間減少 10%。
　　
　　此示例側(cè)重于團隊為實現(xiàn)此目標而使用的下面三個關(guān)鍵工作流：
　　
　　在云端執(zhí)行系統(tǒng)分析和仿真
　　
　　使用 CI 實現(xiàn)測試和代碼生成自動化
　　
　　執(zhí)行虛擬 ECU 部署和測試
　　
　　一、系統(tǒng)級研究。
　　
　　作為第一步，該團隊需要確定可通過更改實現(xiàn)所需加速度的關(guān)鍵軟件參數(shù)，然后在組件級別和系統(tǒng)級別量化更改這些參數(shù)所帶來的影響。他們使用虛擬車輛組建工具在 Simulink® 中以交互方式配置和構(gòu)建虛擬車輛（圖 3）。然后，他們運行一系列參數(shù)掃描，更改最大電池電流和制動再生限制等模型參數(shù)，同時監(jiān)控加速度、MPGe 和其他系統(tǒng)級和組件級度量。為了加快仿真速度，該團隊使用 AWS® 上的 MATLAB Parallel Server™，對 EC2 實例運行參數(shù)掃描，這將執(zhí)行數(shù)百次仿真所需的時間從數(shù)小時縮短到幾分鐘。若要增大所需的加速度，除了優(yōu)化參數(shù)之外，可能還需要更改算法。這些更改可以在模型中快速實現(xiàn)，并通過模型在環(huán) (MIL) 和軟件在環(huán) (SIL) 測試進行驗證。
　　
　　
　　
　　圖 3. 系統(tǒng)級研究中使用的虛擬車輛和關(guān)鍵變量圖。
　　
　　二、使用 CI 實現(xiàn)測試和代碼生成自動化。
　　
　　完成系統(tǒng)級研究后，該團隊開始修改組件模型，更新參數(shù)值，并根據(jù)需要進行其他更改，以提高車輛的加速度。在許多情況下，多名工程師可能并行處理不同功能和組件，因此，該團隊會將模型組件化并置于源代碼管理之下。這樣，工程師便可與其隊友共享資產(chǎn)并同步工作。同樣重要的是，該團隊由此能夠使用可擴展的 Jenkins® 或 GitLab® CI 管道，在更改提交時實現(xiàn)測試和代碼生成自動化（圖 4）。這些測試可以在模型級別和應用軟件級別運行（包括 MISRA C™ 檢查和其他靜態(tài)分析），并且可以配置為在各種環(huán)境和容器中運行。
　　
　　
　　
　　圖 4. CI 管道可用于在開發(fā)運營一體化工作流中實現(xiàn)測試和代碼生成自動化。（徽標由 Jenkins 提供。）
　　
　　三、虛擬 ECU 部署和測試。
　　
　　在代碼生成并經(jīng)過測試后，該團隊的下一步是在虛擬 ECU 上驗證應用軟件。在本例中，生成的代碼將作為應用軟件組件部署在 AUTOSAR Classic 和 Adaptive 平臺上。為了驗證組件是否可在接受目標硬件測試之前與中間件集成，并可能作為無線更新發(fā)送到車輛，該團隊使用了運行在 AWS EC2 實例上的虛擬 ECU（圖 5）。對于這種特殊的應用，他們針對 Adaptive AUTOSAR 將組件與 Elektrobit (EB) corbos 中間件相集成，而針對 AUTOSAR Classic 將組件與 EB tresos 基礎(chǔ)軟件相集成。在虛擬 ECU 上運行測試后，該團隊將測試結(jié)果與之前通過 Simulink 執(zhí)行的 MIL 和 SIL 測試的結(jié)果進行了比較。確認了集成生產(chǎn)軟件可供進行測試后，該團隊就可以部署此軟件了。
　　
　　
　　
　　圖 5. 在 AWS EC2 上的容器化環(huán)境中運行的虛擬 ECU 上進行測試。
　　
　　未來發(fā)展之路
　　
　　MathWorks 的工程師與汽車行業(yè)和世界各地的數(shù)千客戶建立了合作關(guān)系，可以幫助他們的團隊在組織內(nèi)以新的方式使用基于模型的設(shè)計。隨著越來越多的公司及早開啟了他們的 SDV 之旅，我們將繼續(xù)致力于這項工作，增加旨在進一步推動自動化和關(guān)閉反饋回路的新功能，將更多來自生產(chǎn)車輛的運營數(shù)據(jù)納入系統(tǒng)工程、設(shè)計和開發(fā)活動（圖 6）。
　　
　　
　　
　　圖 6. 饋送運營數(shù)據(jù)。
　　
　　我們還將繼續(xù)幫助客戶調(diào)整組織內(nèi)的軟件開發(fā)和系統(tǒng)工程做法，以幫助他們經(jīng)濟高效地提供下一代汽車所需的更高性能、可靠性和安全性。對成熟的汽車公司來說，這往往意味著要利用系統(tǒng)工程團隊的專業(yè)知識來增強或提升軟件開發(fā)團隊的能力。而對科技初創(chuàng)企業(yè)和更年輕的公司來說，這是贏得競爭優(yōu)勢的大好時機，因為他們可以將成熟的基于模型的設(shè)計做法（包括建模、仿真和代碼生成）納入面向開發(fā)運營一體化的工作流中。