電子發燒友App
摘要
在過去的二十年中，汽車軟件的需求和應用急劇增長，隨之復雜性急劇上升，現有技術和框架不足以應對這種復雜性。現在很明顯，汽車制造商（OEM）必須重新考慮他們生產車輛的方式以及車輛本身的生命周期。通過將重點放在軟件上，OEM可以在車輛整個生命周期中實現許多新的應用用例，并打開一個充滿機遇的新世界。
一
軟件定義汽車以及虛擬化技術
1.1?軟件定義汽車的概念
移動出行時代，汽車已逐漸從純粹由機械驅動的硬件轉變為軟件驅動的電子產品。當今不同車廠的產品硬件配置已逐漸趨同，在成本和功能改善空間有限的情況下，傳統汽車價值鏈的重構勢在必行。車廠打造差異化的核心要素已轉向原先與硬件深度耦合的汽車軟件，隨著汽車軟件在新能源和智能化領域不斷取得成功，邁入“軟件定義汽車（Software Defined Vehicles，SDV）”時代已成為行業共識。
“軟件定義汽車”即軟件將深度參與到汽車的定義、開發、驗證、銷售、服務等過程中，并不斷改變和優化各個過程，是汽車從基于硬件的產品向軟件為中心的電子設備不斷轉變的結果。
“軟件定義汽車”?從表面上看是車內軟件（包括電子硬件）的數量、價值超過機械硬件，背后更多的反應了汽車從高度機電一體化的機械終端，逐步轉變為一個智能化、可拓展、可持續迭代升級的移動電子終端。為實現這一目標，整車在標準操作程序前便預埋了性能超前的硬件，并通過OTA在生命周期中逐步解鎖和釋放功能和價值。在該背景下，主機廠的核心能力將從機械硬件轉向電子硬件和軟件；產業價值鏈也將從一錘子硬件銷售轉向持續的軟件及服務溢價。
1.2?汽車軟件發展的趨勢
汽車“新四化”離不開軟件和算法隨著新四化的深入發展，汽車正加速從從機械設備向高度數字化、信息化的智能終端轉變。
首先，軟件及汽車電子占整車的研發成本逐步提高，車內軟件和電子硬件價值有望超過硬件，成為整車價值的核心。據測算，預計到2030年軟件成本占整車BOM（物料清單，Bill Of Material）的比重將從目前不到10%增長到50%。需指出的是，這里的軟件除應用程序開發、還包括AI算法、操作系統，以及軟硬件一體化程度高的控制器、芯片等電子硬件。
其次，軟件及軟件更迭所帶來的性能和功能變化，將決定未來汽車的差異性。軟件的更新維護是未來主機廠提供差異化體驗、提升客戶滿意度最經濟、最便捷、最快速的一種方式。前提是由硬件提供冗余，再由軟件實現迭代。
最后，包括主機廠、零部件企業等產業鏈上企業將加強軟件能力建設，并圍繞“軟件定義汽車”開啟從產品開發模式、組織架構、人員構成、運營體系等的內部變革。此外，新興的軟件公司將借助軟硬件協同能力，兼容產業鏈上下多方需求，一舉躍升為汽車產業鏈上新的Tier-1企業。
1.3 汽車研發面臨的困局
首先，分布式電子電氣架構無法滿足未來更高車載計算能力的需求。驅使EEA架構升級的另一個推動因素來自于更高的通訊效率和更大的帶寬容量需求。成本管控黑洞：隨著車內ECU、傳感器數量增加，整車線束成本和布線難度也跟著大幅提升。
另外，汽車軟件的模塊化、平臺化程度低，導致軟件資源無法集中調度、協作性差。主機廠的ECU通常來自于不同的零部件供應商，事實上控制器上許多底層軟件的重復性很高，這些代碼主要保障控制器的正常運行，例如CAN總線信號的收發、任務進程的調度、Flash數據的讀寫等等。但礙于每一家供應商的軟件編程語言不同、接口標準不同，而且軟件又和硬件高度依賴，使得這些底層代碼無法被復制和移植，從而造成ECU軟件開發的大量重復和資源利用的低效。
其次，軟硬件高度嵌套、主機廠無法執行大規模、深層次的更新和升級或定制化開發工作。分布式軟件架構是一種面向信號的架構，控制器之間通過信號來傳遞信息，但整個系統是封閉、靜態的，在編譯階段就被定義死，因此當發生例如主機廠要修改或增加某個控制器的功能定義，同時該指令還必須調用另一個控制器上的功能時，就不得不把所有需要的控制器都升級，大大延長開發周期、增加開發成本。
1.4 研發模式的轉變
基于以上技術架構方面的變化，在軟件定義汽車的背景下，汽車研發將由傳統的瀑布式開發向敏捷開發的模式轉變。
敏捷軟件開發（Agile software development）：包括需求發現和解決方案改進。該模式通過自組織和跨職能團隊與用戶協作，制定適應性計劃，進行漸進開發、早期交付、持續改進，靈活應對需求、能力的變化以及對需要解決問題的理解的變化。這是一種以用戶需求進化為核心的迭代、循序漸進的開發方法。工程師先將用戶最關注的軟件原型做出來進行交付，根據用戶在實際場景中反饋的問題，快速修改彌補需求中的不足。上述過程不斷迭代，直至用戶滿意。
DevOps是一組過程、方法和系統的統稱，集文化理念、實踐、工具于一身，重視開發（Dev）和運維（Ops）和質量（QA）部門之間的溝通合作。
與傳統軟件開發模式系相比，DevOps打破了開發和運維之間的壁壘，通過自動化“軟件交付”和“架構變更”的流程，使得軟件的構建、測試和發布能更加快捷、頻繁和可靠，從而幫助團隊更快地發展和改進產品、服務客戶、高效參與市場競爭。
1.5 虛擬化的價值
汽車軟件開發將遵循IT行業的發展規律，引入中間件技術、虛擬化技術來實現軟件模塊化、硬件抽象化和標準化，從而進一步解鎖軟硬件的耦合關系，滿足電子電氣架構靈活、可拓展的需求。
為應對流程轉變上的挑戰，開發團隊可考慮將軟硬件解耦后，硬件和軟件部分各自按照獨立時間線來開發，并在進行軟件更改后無需對整個車輛進行重新驗證，純軟件的開發和驗證過程從原型車或者硬件在環測試過渡到軟件在環（SiL）的測試和驗證。這種軟硬解耦的方式同時也迎合了當下將ECU功能整合到中央計算單元或域控制器的趨勢，在多合一控制器融合的過程中發揮作用，軟硬件模塊可以在不同的硬件平臺運行，并在車輛整個生命周期內更新。
那么軟件在環SiL有什么應用場景呢？其應用場景通常是在快速變更的功能需求下敏捷開發及快速迭代。要求盡早進行軟件驗證并發現和糾正代碼中的重要錯誤，特別是涉及安全相關錯誤。在高頻率OTA云端升級軟件的情況下自動化持續驗證。在以上場景下軟件在環SIL測試能夠脫離硬件而快速驗證控制器的功能代碼。
軟件在環SiL的最關鍵的一個核心就是虛擬化：即通過將真實控制器轉化為虛擬控制器，部署到PC上集成環境和聯合仿真平臺，接入CI/CT/CD自動化流水線，并上云端進行大規模測試，從而搭建完整的DevOps的SiL平臺。
虛擬化技術使得在Windows PC上對汽車ECU（Electronic Control Unit，電子控制器單元）進行閉環仿真成為可能，能有效改善ECU開發過程。一些開發任務得以從道路、測試平臺和HIL（Hardware in the Loop，硬件在環）轉移到PC上，縮短開發時間和成本。
從OEM的視角來看虛擬化，可以將軟件測試前移到早期開發階段閉環，既減少了項目初期昂貴的BOM成本，又降低了軟件開發成本和時間，在實現軟件CICT閉環自動化的同時，可以建立供應商之間的發展生態系統，進行多團隊多租戶并行工作。
從工程師的視角來看虛擬化，傳統汽車軟件開發的流程一般為：功能開發團隊使用基于模型的工具鏈開發ECU模型，生成C代碼，然后針對目標處理器進行代碼編譯，并使用測試平臺，HiL系統和道路測試來測試和驗證生成的ECU，進而將結果反饋至開發人員，結束開發周期。該過程存在的主要缺點有：迭代時間長，受原型車和測試設備的限制—硬件資源昂貴且稀缺。
為開發團隊提供虛擬ECU可解決上述問題：開發人員可在PC機上對軟件進行模擬、校準和測量，縮短開發周期，減少對稀缺資源和實際硬件的嚴重依賴；同時，通過虛擬ECU，開發人員可隨時觀察和修改內存變量甚至硬件狀態，極大提升工作效率。
二
vECU虛擬控制器集成
2.1 虛擬控制器的介紹
虛擬控制器簡稱vECU (即Virtual ECU)，表示脫離真實硬件依賴后基于PC獨立編譯和運行的軟件，vECU所包含的內容通常可由ASW,vBSW,vCDD以及RTE這幾個部分構成，在集成編譯后封裝成基于PC的可執行文件。
對于功能測試驗證工程師，通常他會拿到一個帶有軟件的完整ECU控制器，并以硬件在環或實車環境作為測試環境進行測試，整個測試過程可能受硬件和線束的限制，每當遇到軟件的失效時首先需要考慮線束或者硬件通信上的問題，長此以往測試效率通常受硬件資源和硬件狀態的限制，難以在受限的條件下高效的完成測試。但是如果僅ECU內與硬件無關的功能，只需解耦ECU產品代碼并封裝成vECU運行在PC上進行測試即可。數據采集和驗證過程同真實環境軟件測試工具一致，如INCA、Debugger調試器等等。
而對于功能開發工程師來說，驗證功能時需要在完整ECU軟件上進行集成并驗證功能，該集成過程通常由軟件集成工程師負責，軟件集成該功能同時還需要考慮ECU 平臺化升級、底層芯片配置等諸多因素導致迭代效率低下的問題。其實對于其生成的ECU功能代碼，依然可以將這一部分代碼封裝成一個部分功能的vECU并進行仿真測試。并且你可以在任意時間終止仿真并進行Debug，還可以在功能驗證過程中根據需要對vECU做預標定從而提前驗證預設標定數據。
簡而言之，就是將控制器C代碼基于PC環境編譯后生成FMU格式的可執行文件運行在常規PC仿真環境上，以更早和更快的方式進行測試及調試。
2.2 虛擬控制器的分類
生成虛擬控制器的方式有兩種，一種是通過C源碼經過PC的x86編譯器后生成可以運行在PC上vECU目標文件，并于PC上進行系統測試和驗證后反饋給研發工程師。另一種是將C源碼編譯成目標芯片的程序（hex文件）后，運行在目標芯片的指令模擬器上來進行系統測試后再將結果反饋給研發工程師。
如上圖所示，Type-1 vECU, ?Type-2 vECU, Type-3 vECU為第一類通過C源碼的構建方式生成的vECU，Type-4為第二類通過目標程序運行在目標芯片指令模擬器的方式實現vECU。
Type-4 vECU雖然可執行的是同一個目標hex文件，但緩慢的運行效率及芯片迭代所帶來大量工程服務來屏蔽當前ECU項目的部分二進制控制指令，當前大部分用戶仍會采用基于PC編譯器Type1 Type2 和Type3的方式。基于PC編譯器編譯控制器C代碼的諸多優勢，比如：vECU 的更快的運行效率、仿真時的在線Debug、解耦真實硬件以及對實驗結果更快的反饋時間。?
雖然采用vECU來驗證有諸多優勢，但用其進行測試和仿真時仍有一定限制，比如無法評估和分析諸如軟件上的時間表現、CPU負載、內存資源的消耗以及模擬硬件中斷等特性。
2.3 FMU介紹
FMU是對動態鏈接庫DLL進行的二次封裝，它是基于FMI協議進行封裝的模型文件。FMI協議是獨立于建模軟件的標準接口協議，可以用于集成不同的軟件建立的不同詳細程度的模型，進行MiL/SiL仿真。
FMI的全稱叫Functional Mockup Interface 。FMI是為了仿真領域定義的。FMI 定義了二進制的標準格式仿真模型交換。FMU 數學模型的代碼實現就是將提供的 C 頭文件里面定義的函數都實現，如果需要做到源碼保密，則將其封裝成動態鏈接庫 .dll 就行。
一般商業化的仿真工具比如 CarSim、CarMaker 、AVL Cruise、Amesim和Simulink 、ASCET等都由官方提供 FMU。在 FMI 官網上列出了目前提供了 FMU 的軟件可以在以下路徑找到https://fmi-standard.org/
2.4?vECU自動化生成流程
以ETAS的VECU-BUILDER為例，這是一個基于Python和CMake的Windows工具。
為了創建一套生成PC Target的虛擬控制器FMU 文件，我們需要有一套軟件集成和編譯工具鏈：自動化vECU編譯工具鏈。這個工具鏈需要一旦配置完成后，可實現一鍵生成虛擬控制器。
初次生成vECU工作流程：
Rebuild生成vECU工作流程：
三
集成環境及聯合仿真
下面介紹一下關于FMU的集成環境和聯合仿真平臺。
3.1 COSYM介紹
COSYM（系統協同仿真）產品是一個仿真和集成平臺，作為系統級軟件在環的主干，能夠方便支持ECU間通信，并使能OEM廠商成為虛擬車輛集成商。一旦OEM廠商開發了自有的構建模塊庫，將能夠方便采用COSYM進行模塊集成與連接，使能控制器之間精確地通信。COSYM具有?“時序主控”?，能夠協調所集成模塊時間同步。?
COSYM提供了圖形配置界面（GUI）和實時操作環境（CEE），以實現有效的用戶交互。旨在為用戶提供：
?模塊導入，集成和部署；
?多平臺仿真：
基于Windows的自適應時間（ATS），軟實時(MiL/SiL)；
基于云端的并行加速運算(MiL/SiL)；
基于Linux的實時仿真(HiL)；
?離散和連續仿真系統的交互操控及結果可視化(CEE)；
?高級程序員/用戶可以使用ASAM XiL和RestAPI（Python接口等）接 口 與COSYM進行交互。
通用模型集成器主要優勢：
?通用FMI2.0集成接口，可快速復用被控對象模型，虛擬控制器模型和幀級虛擬總線模型
?COSYM提供Rest API，可啟動后臺運行模式，支持自動化流水線工具接入
?可實現基于Windows和Linux*增量編譯，提升集成效率
聯合仿真器主要優勢：
?支持ASAM-XiL標準接口，調用API即可運行仿真環境
?支持基于Windows和Linux*系統下的自動化集成測試
?支持基于云原生和容器鏡像技術的仿真計算
?支持第三方工具交互式測試，例如：測試管理與標定工具和總線仿真與信息安全工具功能
3.2 COSYM功能
功能模塊集成：
?COSYM支持用于聯合仿真的功能模型接口標準（FMI）V2.0；
?提供了用于虛擬ECU（vECU）集成和仿真的環境；
?建模工具ASCET和ASCMO模型；
?Labcar系列半物理模型，基于Simulink的?模型編譯導入；
?支持模板化的C模塊；
模塊間通信連接：
COSYM 提供了基于CAN/CANFD, 車載以太網，FlexRay, LIN的的汽車總線虛擬仿真技術。
基于共享內存，該虛擬總線仿真為被動和分散式，分布式系統因此可以由任意數量的模塊構建。不需要真實的網絡接口，可在虛擬vNet接口上捕獲網絡流量并將其轉發到真實的網絡接口。虛擬CAN和車載以太網支持在ISO / OSI第二層級及以上的邏輯總線行為模擬，模擬可到幀的傳輸而非電壓電平。
COSYM ?可提供vPIN 級別的vECU信號互連插件-虛擬電器層（vEL），以實現例如故障存儲器，EEPROM，通訊堆棧和輸入/輸出的測試驗證；相比真實硬件，該插件簡化或刪除了部分特定硬件和復雜驅動程序相關的仿真。
3.3 COSYM應用場景
?虛擬控制器自動尋優標定（節能減排）
?大規模云端并行計算及多租戶協同工作（降本增效）
?虛擬整車及產品級代碼白盒持續集成與測試（加速迭代）
?被控對象模型自動參數化（精度提升）
四
云上大規模測試
ETAS?的Cloud?Service整體概覽
從ECU到VECU實現了控制器硬件的虛擬化；從物理控制器測試聯調到聯合仿真平臺實現了測試環境的虛擬化；前序兩階段的虛擬化為云上大規模測試仿真提供了可能。
4.1 快速的基礎設施擴展
依托于云供應商（AWS、Ali Cloud）的彈性伸縮服務，秒級創建用于大規模測試仿真所需的計算資源。應對復雜被控對象模型和海量信號數據輸入也能夠實現即時處理；仿真任務完成后資源即刻銷毀。相較于傳統本地仿真運行，能夠有效避免由于硬件計算資源不足導致的運行崩潰，仿真等待時間長，從成本上看按量付費模式可減少基礎設施建設投入，減少計算資源閑置。
4.2 并行測試仿真
基于容器云的編排能力和云供應商容器服務?（AWS: EKS、Lambda, Ali Cloud: ACK、FC）能夠完成大規模并行仿真任務，并行測試執行。能夠對車輛網絡等復雜系統進行仿真，包括虛擬車輛控制單元、車輛總線和仿真模型。每次仿真運行可測量1000個信號，輸出報告支持用戶自定義格式。相較于本地運行仿真時的垂直擴展方式，Cloud Service能夠以分布式架構水平擴展計算節點，完成各節點間仿真任務的數據同步，最大可支持1000個仿真任務并行執行。
云上仿真測試用例釋義
4.3 高度安全的云環境
Cloud Service 上的仿真應用Model-Simulator已通過ISO/IEC 27000?和 27001認證。達到博世安全等級3(嚴格保密)。
4.4 兼容的適配性
Cloud Service 兼容COSYM、VECU Builder、ETAB之外，還兼容其它第三方產品，如ECUTest、AVL、Synopsis、Vector等。
4.5 多租戶團隊協同
多個仿真測試團隊可同時登錄進行仿真測試。各租戶之間模型和信號等數據隔離；租戶之間仿真任務并行運行互不影響；各云上租戶資源可無限擴展。
五
CICT自動化流水線
在虛擬控制器生成和虛擬整車平臺SIL環境搭建的基礎上，通過一系列工具鏈實現持續集成與持續測試的CICT自動化流水線。
CICT方案為客戶帶來的顯著收益：
?開發與測試環節的全面加速
?盡早發現錯誤并有效反饋
?可重復使用現有工具
?數據安全保障
?使員工可以專注于價值創造，而非工具與工具鏈
?多方工程協作的支持
支持構建用戶自定義的持續集成及持續測試自動化流水線
流水線步驟舉例：
?代碼變更，保存并推送代碼倉庫，Jenkins觸發CICT Pipeline流水線。
?拉取代碼變更到本地 PC，生成虛擬控制器FMU并進行校驗。
?COSYM集成并進行冒煙測試。
?持續測試通過，報告生成和查看分析，上傳測試通過虛擬ECU文件至JFrog制品倉庫。
六
應用案例
以下是基于ETAS虛擬化開發工具鏈，列舉一些應用案例。
6.1 虛擬標定和虛擬總線應用，虛擬整車POC
客戶面臨的挑戰和困難：
?仿真平臺能夠支持接入第三方的模型（如：ML/SL、GT、AMESim、CarMaker等）。
?能夠減少車輛標定工作時間，特別是重復性標定（如：工況脈譜圖的掃點標定）。
使用虛擬化方案實現的成果：
?成功通過COSYM仿真平臺完成軟件在環的閉環工作。
?標定軟件INCA通過XCP協議與虛擬控制器建立通訊。
?自動化標定軟件INCA-FLOW通過ASAM-XIL接口與ETAS COSYM進行連接，實現對被控對象（如：運行工況點）的控制，并通過設計好的標定流程自動實施標定工作。
6.2 基于模型在環和軟件在環的功能測試
客戶面臨的挑戰和困難：
?虛擬化實踐需要基于目前使用的軟件開發工具。
?虛擬控制器能夠使用優化后的標定參數，并通過DCM文件進行。
?虛擬化實踐除了在單機上進行，也支持在云端運行。
使用虛擬化方案實現的成果：
?通過VECU-Builder工具實現了Type-1虛擬控制器的生成，并使用了DCM文件中優化后的標定參數。
?成功通過COSYM仿真平臺完成軟件在環的閉環工作。
?單機性能：比實時仿真快2+倍。
?通過Cloud Service實現了云端運行的預研評估工作。
6.3 持續集成和持續測試 CI/CT
客戶面臨的挑戰和困難：
?有計劃、分步驟地進行虛擬化實踐。
?適用于AUTOSAR架構的和非AUTOSAR架構的軟件。
?不能因為引入虛擬化實踐，大幅增加開發工程師的工作負荷。
?虛擬化實踐要滿足未來軟件定義汽車的大趨勢。
使用虛擬化方案實現的成果：
?根據客戶的實際情況成功建立起點是源代碼，終點為測試報告的自動化Pipeline。
?Pipeline中可以自動地生成虛擬控制器，關聯被控對象模型，接入仿真平臺。并進行虛擬控制器的冒煙測試后，按照設定的測試用例進行軟件在環測試，最后生成報告。?Pipeline可以在本地服務器中部署，也可以移植到云端運行。
6.4 虛擬標定和云端隊列
客戶面臨的挑戰和困難：
?需要減少車輛道路測試和標定的人力投入和費用。
?最大限度兼容目前使用的工具（INCA、ASCMO和MOCA等）。
?提高測試和標定工作的效率。
使用虛擬化方案實現的成果：
?成功通過VECU-Builder工具實現了Type-1虛擬控制器的生成。
?成功通過COSYM仿真平臺完成軟件在環的閉環工作。?INCA、ASCMO和MOCA等工具能夠在虛擬環境中無縫銜接。
?標定效率：比實車測試快5+倍。
?測試效率：2小時仿真=25,000公里路測。
6.5 虛擬標定自動化
客戶面臨的挑戰和困難：
?仿真平臺能夠支持接入第三方的模型（如：ML/SL、GT、AMESim、CarMaker等）。
?能夠減少車輛標定工作時間，特別是重復性標定（如：工況脈譜圖的掃點標定）。
使用虛擬化方案實現的成果：
?成功通過COSYM仿真平臺完成軟件在環的閉環工作。
?標定軟件INCA通過XCP協議與虛擬控制器建立通訊。
?自動化標定軟件INCA-FLOW通過ASAM-XIL接口與ETAS COSYM進行連接，實現對被控對象（如：運行工況點）的控制，并通過設計好的標定流程自動實施標定工作。
七
總結
7.1 應用領域
?針對功能開發、集成測試工程師可以在應用層代碼開發階段完成SIL仿真測試
?針對標定測試工程師可以在SIL仿真環境中進行多控制器聯合虛擬標定
?實車數據與虛擬整車相互促進
?打造敏捷軟件開發的研發生態
?助力車企打造軟件定義汽車和整車數字孿生應用案例
?整車物理模型的搭建、集成與精度提升
?工具兼容性可支持低成本及跨車型通用
7.2 功能特色
?支持跨軟件架構和操作平臺，生成不同類型的虛擬控制器vECU，操作流程簡易成熟
?聯合仿真平臺支持標準FMU集成，跨平臺聯合仿真，靈活度和兼容性高
?支持三方工具多控制器聯合虛擬標定
?支持構建用戶自定義的持續集成及持續測試自動化流水線
?各類幀級虛擬總線標準插件。包括CAN、CANFD、LIN、以太網等虛擬總線
?可基于國內云端部署
7.3 收益優勢
?虛擬控制器可靈活應用在軟件開發前期、中期和后期，提升開發效率
?標準化仿真平臺，兼容各類虛擬控制器和被控對象模型，實現軟件在環測試，仿真速率高
?通過建立持續集成、持續測試Pipeline，減少開發人員的重復工作，加速迭代過程
?支持幀級虛擬總線、國內云端部署，更好地協助開發部門進行數字化轉型
?減少硬件測試臺架的投資，加快整車開發測試和上市周期
?建立多團隊間的協同開發軟件的生態?
?
編輯：黃飛
工商網監
評論