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