摘要

在過(guò)去的二十年中，汽車軟件的需求和應(yīng)用急劇增長(zhǎng)，隨之復(fù)雜性急劇上升，現(xiàn)有技術(shù)和框架不足以應(yīng)對(duì)這種復(fù)雜性。現(xiàn)在很明顯，汽車制造商（OEM）必須重新考慮他們生產(chǎn)車輛的方式以及車輛本身的生命周期。通過(guò)將重點(diǎn)放在軟件上，OEM可以在車輛整個(gè)生命周期中實(shí)現(xiàn)許多新的應(yīng)用用例，并打開一個(gè)充滿機(jī)遇的新世界。

一

軟件定義汽車以及虛擬化技術(shù)

1.1?軟件定義汽車的概念

移動(dòng)出行時(shí)代，汽車已逐漸從純粹由機(jī)械驅(qū)動(dòng)的硬件轉(zhuǎn)變?yōu)檐浖?qū)動(dòng)的電子產(chǎn)品。當(dāng)今不同車廠的產(chǎn)品硬件配置已逐漸趨同，在成本和功能改善空間有限的情況下，傳統(tǒng)汽車價(jià)值鏈的重構(gòu)勢(shì)在必行。車廠打造差異化的核心要素已轉(zhuǎn)向原先與硬件深度耦合的汽車軟件，隨著汽車軟件在新能源和智能化領(lǐng)域不斷取得成功，邁入“軟件定義汽車（Software Defined Vehicles，SDV）”時(shí)代已成為行業(yè)共識(shí)。

“軟件定義汽車”即軟件將深度參與到汽車的定義、開發(fā)、驗(yàn)證、銷售、服務(wù)等過(guò)程中，并不斷改變和優(yōu)化各個(gè)過(guò)程，是汽車從基于硬件的產(chǎn)品向軟件為中心的電子設(shè)備不斷轉(zhuǎn)變的結(jié)果。

“軟件定義汽車”?從表面上看是車內(nèi)軟件（包括電子硬件）的數(shù)量、價(jià)值超過(guò)機(jī)械硬件，背后更多的反應(yīng)了汽車從高度機(jī)電一體化的機(jī)械終端，逐步轉(zhuǎn)變?yōu)橐粋€(gè)智能化、可拓展、可持續(xù)迭代升級(jí)的移動(dòng)電子終端。為實(shí)現(xiàn)這一目標(biāo)，整車在標(biāo)準(zhǔn)操作程序前便預(yù)埋了性能超前的硬件，并通過(guò)OTA在生命周期中逐步解鎖和釋放功能和價(jià)值。在該背景下，主機(jī)廠的核心能力將從機(jī)械硬件轉(zhuǎn)向電子硬件和軟件；產(chǎn)業(yè)價(jià)值鏈也將從一錘子硬件銷售轉(zhuǎn)向持續(xù)的軟件及服務(wù)溢價(jià)。

1.2?汽車軟件發(fā)展的趨勢(shì)

汽車“新四化”離不開軟件和算法隨著新四化的深入發(fā)展，汽車正加速?gòu)膹臋C(jī)械設(shè)備向高度數(shù)字化、信息化的智能終端轉(zhuǎn)變。

首先，軟件及汽車電子占整車的研發(fā)成本逐步提高，車內(nèi)軟件和電子硬件價(jià)值有望超過(guò)硬件，成為整車價(jià)值的核心。據(jù)測(cè)算，預(yù)計(jì)到2030年軟件成本占整車BOM（物料清單，Bill Of Material）的比重將從目前不到10%增長(zhǎng)到50%。需指出的是，這里的軟件除應(yīng)用程序開發(fā)、還包括AI算法、操作系統(tǒng)，以及軟硬件一體化程度高的控制器、芯片等電子硬件。

其次，軟件及軟件更迭所帶來(lái)的性能和功能變化，將決定未來(lái)汽車的差異性。軟件的更新維護(hù)是未來(lái)主機(jī)廠提供差異化體驗(yàn)、提升客戶滿意度最經(jīng)濟(jì)、最便捷、最快速的一種方式。前提是由硬件提供冗余，再由軟件實(shí)現(xiàn)迭代。

最后，包括主機(jī)廠、零部件企業(yè)等產(chǎn)業(yè)鏈上企業(yè)將加強(qiáng)軟件能力建設(shè)，并圍繞“軟件定義汽車”開啟從產(chǎn)品開發(fā)模式、組織架構(gòu)、人員構(gòu)成、運(yùn)營(yíng)體系等的內(nèi)部變革。此外，新興的軟件公司將借助軟硬件協(xié)同能力，兼容產(chǎn)業(yè)鏈上下多方需求，一舉躍升為汽車產(chǎn)業(yè)鏈上新的Tier-1企業(yè)。

1.3 汽車研發(fā)面臨的困局

首先，分布式電子電氣架構(gòu)無(wú)法滿足未來(lái)更高車載計(jì)算能力的需求。驅(qū)使EEA架構(gòu)升級(jí)的另一個(gè)推動(dòng)因素來(lái)自于更高的通訊效率和更大的帶寬容量需求。成本管控黑洞：隨著車內(nèi)ECU、傳感器數(shù)量增加，整車線束成本和布線難度也跟著大幅提升。

另外，汽車軟件的模塊化、平臺(tái)化程度低，導(dǎo)致軟件資源無(wú)法集中調(diào)度、協(xié)作性差。主機(jī)廠的ECU通常來(lái)自于不同的零部件供應(yīng)商，事實(shí)上控制器上許多底層軟件的重復(fù)性很高，這些代碼主要保障控制器的正常運(yùn)行，例如CAN總線信號(hào)的收發(fā)、任務(wù)進(jìn)程的調(diào)度、Flash數(shù)據(jù)的讀寫等等。但礙于每一家供應(yīng)商的軟件編程語(yǔ)言不同、接口標(biāo)準(zhǔn)不同，而且軟件又和硬件高度依賴，使得這些底層代碼無(wú)法被復(fù)制和移植，從而造成ECU軟件開發(fā)的大量重復(fù)和資源利用的低效。

其次，軟硬件高度嵌套、主機(jī)廠無(wú)法執(zhí)行大規(guī)模、深層次的更新和升級(jí)或定制化開發(fā)工作。分布式軟件架構(gòu)是一種面向信號(hào)的架構(gòu)，控制器之間通過(guò)信號(hào)來(lái)傳遞信息，但整個(gè)系統(tǒng)是封閉、靜態(tài)的，在編譯階段就被定義死，因此當(dāng)發(fā)生例如主機(jī)廠要修改或增加某個(gè)控制器的功能定義，同時(shí)該指令還必須調(diào)用另一個(gè)控制器上的功能時(shí)，就不得不把所有需要的控制器都升級(jí)，大大延長(zhǎng)開發(fā)周期、增加開發(fā)成本。

1.4 研發(fā)模式的轉(zhuǎn)變

基于以上技術(shù)架構(gòu)方面的變化，在軟件定義汽車的背景下，汽車研發(fā)將由傳統(tǒng)的瀑布式開發(fā)向敏捷開發(fā)的模式轉(zhuǎn)變。

敏捷軟件開發(fā)（Agile software development）：包括需求發(fā)現(xiàn)和解決方案改進(jìn)。該模式通過(guò)自組織和跨職能團(tuán)隊(duì)與用戶協(xié)作，制定適應(yīng)性計(jì)劃，進(jìn)行漸進(jìn)開發(fā)、早期交付、持續(xù)改進(jìn)，靈活應(yīng)對(duì)需求、能力的變化以及對(duì)需要解決問題的理解的變化。這是一種以用戶需求進(jìn)化為核心的迭代、循序漸進(jìn)的開發(fā)方法。工程師先將用戶最關(guān)注的軟件原型做出來(lái)進(jìn)行交付，根據(jù)用戶在實(shí)際場(chǎng)景中反饋的問題，快速修改彌補(bǔ)需求中的不足。上述過(guò)程不斷迭代，直至用戶滿意。

DevOps是一組過(guò)程、方法和系統(tǒng)的統(tǒng)稱，集文化理念、實(shí)踐、工具于一身，重視開發(fā)（Dev）和運(yùn)維（Ops）和質(zhì)量（QA）部門之間的溝通合作。

與傳統(tǒng)軟件開發(fā)模式系相比，DevOps打破了開發(fā)和運(yùn)維之間的壁壘，通過(guò)自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程，使得軟件的構(gòu)建、測(cè)試和發(fā)布能更加快捷、頻繁和可靠，從而幫助團(tuán)隊(duì)更快地發(fā)展和改進(jìn)產(chǎn)品、服務(wù)客戶、高效參與市場(chǎng)競(jìng)爭(zhēng)。

1.5 虛擬化的價(jià)值

汽車軟件開發(fā)將遵循IT行業(yè)的發(fā)展規(guī)律，引入中間件技術(shù)、虛擬化技術(shù)來(lái)實(shí)現(xiàn)軟件模塊化、硬件抽象化和標(biāo)準(zhǔn)化，從而進(jìn)一步解鎖軟硬件的耦合關(guān)系，滿足電子電氣架構(gòu)靈活、可拓展的需求。

為應(yīng)對(duì)流程轉(zhuǎn)變上的挑戰(zhàn)，開發(fā)團(tuán)隊(duì)可考慮將軟硬件解耦后，硬件和軟件部分各自按照獨(dú)立時(shí)間線來(lái)開發(fā)，并在進(jìn)行軟件更改后無(wú)需對(duì)整個(gè)車輛進(jìn)行重新驗(yàn)證，純軟件的開發(fā)和驗(yàn)證過(guò)程從原型車或者硬件在環(huán)測(cè)試過(guò)渡到軟件在環(huán)（SiL）的測(cè)試和驗(yàn)證。這種軟硬解耦的方式同時(shí)也迎合了當(dāng)下將ECU功能整合到中央計(jì)算單元或域控制器的趨勢(shì)，在多合一控制器融合的過(guò)程中發(fā)揮作用，軟硬件模塊可以在不同的硬件平臺(tái)運(yùn)行，并在車輛整個(gè)生命周期內(nèi)更新。

那么軟件在環(huán)SiL有什么應(yīng)用場(chǎng)景呢？其應(yīng)用場(chǎng)景通常是在快速變更的功能需求下敏捷開發(fā)及快速迭代。要求盡早進(jìn)行軟件驗(yàn)證并發(fā)現(xiàn)和糾正代碼中的重要錯(cuò)誤，特別是涉及安全相關(guān)錯(cuò)誤。在高頻率OTA云端升級(jí)軟件的情況下自動(dòng)化持續(xù)驗(yàn)證。在以上場(chǎng)景下軟件在環(huán)SIL測(cè)試能夠脫離硬件而快速驗(yàn)證控制器的功能代碼。

軟件在環(huán)SiL的最關(guān)鍵的一個(gè)核心就是虛擬化：即通過(guò)將真實(shí)控制器轉(zhuǎn)化為虛擬控制器，部署到PC上集成環(huán)境和聯(lián)合仿真平臺(tái)，接入CI/CT/CD自動(dòng)化流水線，并上云端進(jìn)行大規(guī)模測(cè)試，從而搭建完整的DevOps的SiL平臺(tái)。

虛擬化技術(shù)使得在Windows PC上對(duì)汽車ECU（Electronic Control Unit，電子控制器單元）進(jìn)行閉環(huán)仿真成為可能，能有效改善ECU開發(fā)過(guò)程。一些開發(fā)任務(wù)得以從道路、測(cè)試平臺(tái)和HIL（Hardware in the Loop，硬件在環(huán)）轉(zhuǎn)移到PC上，縮短開發(fā)時(shí)間和成本。

從OEM的視角來(lái)看虛擬化，可以將軟件測(cè)試前移到早期開發(fā)階段閉環(huán)，既減少了項(xiàng)目初期昂貴的BOM成本，又降低了軟件開發(fā)成本和時(shí)間，在實(shí)現(xiàn)軟件CICT閉環(huán)自動(dòng)化的同時(shí)，可以建立供應(yīng)商之間的發(fā)展生態(tài)系統(tǒng)，進(jìn)行多團(tuán)隊(duì)多租戶并行工作。

從工程師的視角來(lái)看虛擬化，傳統(tǒng)汽車軟件開發(fā)的流程一般為：功能開發(fā)團(tuán)隊(duì)使用基于模型的工具鏈開發(fā)ECU模型，生成C代碼，然后針對(duì)目標(biāo)處理器進(jìn)行代碼編譯，并使用測(cè)試平臺(tái)，HiL系統(tǒng)和道路測(cè)試來(lái)測(cè)試和驗(yàn)證生成的ECU，進(jìn)而將結(jié)果反饋至開發(fā)人員，結(jié)束開發(fā)周期。該過(guò)程存在的主要缺點(diǎn)有：迭代時(shí)間長(zhǎng)，受原型車和測(cè)試設(shè)備的限制—硬件資源昂貴且稀缺。

為開發(fā)團(tuán)隊(duì)提供虛擬ECU可解決上述問題：開發(fā)人員可在PC機(jī)上對(duì)軟件進(jìn)行模擬、校準(zhǔn)和測(cè)量，縮短開發(fā)周期，減少對(duì)稀缺資源和實(shí)際硬件的嚴(yán)重依賴；同時(shí)，通過(guò)虛擬ECU，開發(fā)人員可隨時(shí)觀察和修改內(nèi)存變量甚至硬件狀態(tài)，極大提升工作效率。

二

vECU虛擬控制器集成

2.1 虛擬控制器的介紹

虛擬控制器簡(jiǎn)稱vECU (即Virtual ECU)，表示脫離真實(shí)硬件依賴后基于PC獨(dú)立編譯和運(yùn)行的軟件，vECU所包含的內(nèi)容通常可由ASW,vBSW,vCDD以及RTE這幾個(gè)部分構(gòu)成，在集成編譯后封裝成基于PC的可執(zhí)行文件。

對(duì)于功能測(cè)試驗(yàn)證工程師，通常他會(huì)拿到一個(gè)帶有軟件的完整ECU控制器，并以硬件在環(huán)或?qū)嵻嚟h(huán)境作為測(cè)試環(huán)境進(jìn)行測(cè)試，整個(gè)測(cè)試過(guò)程可能受硬件和線束的限制，每當(dāng)遇到軟件的失效時(shí)首先需要考慮線束或者硬件通信上的問題，長(zhǎng)此以往測(cè)試效率通常受硬件資源和硬件狀態(tài)的限制，難以在受限的條件下高效的完成測(cè)試。但是如果僅ECU內(nèi)與硬件無(wú)關(guān)的功能，只需解耦ECU產(chǎn)品代碼并封裝成vECU運(yùn)行在PC上進(jìn)行測(cè)試即可。數(shù)據(jù)采集和驗(yàn)證過(guò)程同真實(shí)環(huán)境軟件測(cè)試工具一致，如INCA、Debugger調(diào)試器等等。

而對(duì)于功能開發(fā)工程師來(lái)說(shuō)，驗(yàn)證功能時(shí)需要在完整ECU軟件上進(jìn)行集成并驗(yàn)證功能，該集成過(guò)程通常由軟件集成工程師負(fù)責(zé)，軟件集成該功能同時(shí)還需要考慮ECU 平臺(tái)化升級(jí)、底層芯片配置等諸多因素導(dǎo)致迭代效率低下的問題。其實(shí)對(duì)于其生成的ECU功能代碼，依然可以將這一部分代碼封裝成一個(gè)部分功能的vECU并進(jìn)行仿真測(cè)試。并且你可以在任意時(shí)間終止仿真并進(jìn)行Debug，還可以在功能驗(yàn)證過(guò)程中根據(jù)需要對(duì)vECU做預(yù)標(biāo)定從而提前驗(yàn)證預(yù)設(shè)標(biāo)定數(shù)據(jù)。

簡(jiǎn)而言之，就是將控制器C代碼基于PC環(huán)境編譯后生成FMU格式的可執(zhí)行文件運(yùn)行在常規(guī)PC仿真環(huán)境上，以更早和更快的方式進(jìn)行測(cè)試及調(diào)試。

2.2 虛擬控制器的分類

生成虛擬控制器的方式有兩種，一種是通過(guò)C源碼經(jīng)過(guò)PC的x86編譯器后生成可以運(yùn)行在PC上vECU目標(biāo)文件，并于PC上進(jìn)行系統(tǒng)測(cè)試和驗(yàn)證后反饋給研發(fā)工程師。另一種是將C源碼編譯成目標(biāo)芯片的程序（hex文件）后，運(yùn)行在目標(biāo)芯片的指令模擬器上來(lái)進(jìn)行系統(tǒng)測(cè)試后再將結(jié)果反饋給研發(fā)工程師。

如上圖所示，Type-1 vECU, ?Type-2 vECU, Type-3 vECU為第一類通過(guò)C源碼的構(gòu)建方式生成的vECU，Type-4為第二類通過(guò)目標(biāo)程序運(yùn)行在目標(biāo)芯片指令模擬器的方式實(shí)現(xiàn)vECU。

Type-4 vECU雖然可執(zhí)行的是同一個(gè)目標(biāo)hex文件，但緩慢的運(yùn)行效率及芯片迭代所帶來(lái)大量工程服務(wù)來(lái)屏蔽當(dāng)前ECU項(xiàng)目的部分二進(jìn)制控制指令，當(dāng)前大部分用戶仍會(huì)采用基于PC編譯器Type1 Type2 和Type3的方式。基于PC編譯器編譯控制器C代碼的諸多優(yōu)勢(shì)，比如：vECU 的更快的運(yùn)行效率、仿真時(shí)的在線Debug、解耦真實(shí)硬件以及對(duì)實(shí)驗(yàn)結(jié)果更快的反饋時(shí)間。?

雖然采用vECU來(lái)驗(yàn)證有諸多優(yōu)勢(shì)，但用其進(jìn)行測(cè)試和仿真時(shí)仍有一定限制，比如無(wú)法評(píng)估和分析諸如軟件上的時(shí)間表現(xiàn)、CPU負(fù)載、內(nèi)存資源的消耗以及模擬硬件中斷等特性。

2.3 FMU介紹

FMU是對(duì)動(dòng)態(tài)鏈接庫(kù)DLL進(jìn)行的二次封裝，它是基于FMI協(xié)議進(jìn)行封裝的模型文件。FMI協(xié)議是獨(dú)立于建模軟件的標(biāo)準(zhǔn)接口協(xié)議，可以用于集成不同的軟件建立的不同詳細(xì)程度的模型，進(jìn)行MiL/SiL仿真。

FMI的全稱叫Functional Mockup Interface 。FMI是為了仿真領(lǐng)域定義的。FMI 定義了二進(jìn)制的標(biāo)準(zhǔn)格式仿真模型交換。FMU 數(shù)學(xué)模型的代碼實(shí)現(xiàn)就是將提供的 C 頭文件里面定義的函數(shù)都實(shí)現(xiàn)，如果需要做到源碼保密，則將其封裝成動(dòng)態(tài)鏈接庫(kù) .dll 就行。

一般商業(yè)化的仿真工具比如 CarSim、CarMaker 、AVL Cruise、Amesim和Simulink 、ASCET等都由官方提供 FMU。在 FMI 官網(wǎng)上列出了目前提供了 FMU 的軟件可以在以下路徑找到https://fmi-standard.org/

2.4?vECU自動(dòng)化生成流程

以ETAS的VECU-BUILDER為例，這是一個(gè)基于Python和CMake的Windows工具。

為了創(chuàng)建一套生成PC Target的虛擬控制器FMU 文件，我們需要有一套軟件集成和編譯工具鏈：自動(dòng)化vECU編譯工具鏈。這個(gè)工具鏈需要一旦配置完成后，可實(shí)現(xiàn)一鍵生成虛擬控制器。

初次生成vECU工作流程：

Rebuild生成vECU工作流程：

三

集成環(huán)境及聯(lián)合仿真

下面介紹一下關(guān)于FMU的集成環(huán)境和聯(lián)合仿真平臺(tái)。

3.1 COSYM介紹

COSYM（系統(tǒng)協(xié)同仿真）產(chǎn)品是一個(gè)仿真和集成平臺(tái)，作為系統(tǒng)級(jí)軟件在環(huán)的主干，能夠方便支持ECU間通信，并使能OEM廠商成為虛擬車輛集成商。一旦OEM廠商開發(fā)了自有的構(gòu)建模塊庫(kù)，將能夠方便采用COSYM進(jìn)行模塊集成與連接，使能控制器之間精確地通信。COSYM具有?“時(shí)序主控”?，能夠協(xié)調(diào)所集成模塊時(shí)間同步。?

COSYM提供了圖形配置界面（GUI）和實(shí)時(shí)操作環(huán)境（CEE），以實(shí)現(xiàn)有效的用戶交互。旨在為用戶提供：

?模塊導(dǎo)入，集成和部署；

?多平臺(tái)仿真：

基于Windows的自適應(yīng)時(shí)間（ATS），軟實(shí)時(shí)(MiL/SiL)；

基于云端的并行加速運(yùn)算(MiL/SiL)；

基于Linux的實(shí)時(shí)仿真(HiL)；

?離散和連續(xù)仿真系統(tǒng)的交互操控及結(jié)果可視化(CEE)；

?高級(jí)程序員/用戶可以使用ASAM XiL和RestAPI（Python接口等）接 口 與COSYM進(jìn)行交互。

通用模型集成器主要優(yōu)勢(shì)：

?通用FMI2.0集成接口，可快速?gòu)?fù)用被控對(duì)象模型，虛擬控制器模型和幀級(jí)虛擬總線模型

?COSYM提供Rest API，可啟動(dòng)后臺(tái)運(yùn)行模式，支持自動(dòng)化流水線工具接入

?可實(shí)現(xiàn)基于Windows和Linux*增量編譯，提升集成效率

聯(lián)合仿真器主要優(yōu)勢(shì)：

?支持ASAM-XiL標(biāo)準(zhǔn)接口，調(diào)用API即可運(yùn)行仿真環(huán)境

?支持基于Windows和Linux*系統(tǒng)下的自動(dòng)化集成測(cè)試

?支持基于云原生和容器鏡像技術(shù)的仿真計(jì)算

?支持第三方工具交互式測(cè)試，例如：測(cè)試管理與標(biāo)定工具和總線仿真與信息安全工具功能

3.2 COSYM功能

功能模塊集成：

?COSYM支持用于聯(lián)合仿真的功能模型接口標(biāo)準(zhǔn)（FMI）V2.0；

?提供了用于虛擬ECU（vECU）集成和仿真的環(huán)境；

?建模工具ASCET和ASCMO模型；

?Labcar系列半物理模型，基于Simulink的?模型編譯導(dǎo)入；

?支持模板化的C模塊；

模塊間通信連接：

COSYM 提供了基于CAN/CANFD, 車載以太網(wǎng)，F(xiàn)lexRay, LIN的的汽車總線虛擬仿真技術(shù)。

基于共享內(nèi)存，該虛擬總線仿真為被動(dòng)和分散式，分布式系統(tǒng)因此可以由任意數(shù)量的模塊構(gòu)建。不需要真實(shí)的網(wǎng)絡(luò)接口，可在虛擬vNet接口上捕獲網(wǎng)絡(luò)流量并將其轉(zhuǎn)發(fā)到真實(shí)的網(wǎng)絡(luò)接口。虛擬CAN和車載以太網(wǎng)支持在ISO / OSI第二層級(jí)及以上的邏輯總線行為模擬，模擬可到幀的傳輸而非電壓電平。

COSYM ?可提供vPIN 級(jí)別的vECU信號(hào)互連插件-虛擬電器層（vEL），以實(shí)現(xiàn)例如故障存儲(chǔ)器，EEPROM，通訊堆棧和輸入/輸出的測(cè)試驗(yàn)證；相比真實(shí)硬件，該插件簡(jiǎn)化或刪除了部分特定硬件和復(fù)雜驅(qū)動(dòng)程序相關(guān)的仿真。

3.3 COSYM應(yīng)用場(chǎng)景

?虛擬控制器自動(dòng)尋優(yōu)標(biāo)定（節(jié)能減排）

?大規(guī)模云端并行計(jì)算及多租戶協(xié)同工作（降本增效）

?虛擬整車及產(chǎn)品級(jí)代碼白盒持續(xù)集成與測(cè)試（加速迭代）

?被控對(duì)象模型自動(dòng)參數(shù)化（精度提升）

四

云上大規(guī)模測(cè)試

ETAS?的Cloud?Service整體概覽

從ECU到VECU實(shí)現(xiàn)了控制器硬件的虛擬化；從物理控制器測(cè)試聯(lián)調(diào)到聯(lián)合仿真平臺(tái)實(shí)現(xiàn)了測(cè)試環(huán)境的虛擬化；前序兩階段的虛擬化為云上大規(guī)模測(cè)試仿真提供了可能。

4.1 快速的基礎(chǔ)設(shè)施擴(kuò)展

依托于云供應(yīng)商（AWS、Ali Cloud）的彈性伸縮服務(wù)，秒級(jí)創(chuàng)建用于大規(guī)模測(cè)試仿真所需的計(jì)算資源。應(yīng)對(duì)復(fù)雜被控對(duì)象模型和海量信號(hào)數(shù)據(jù)輸入也能夠?qū)崿F(xiàn)即時(shí)處理；仿真任務(wù)完成后資源即刻銷毀。相較于傳統(tǒng)本地仿真運(yùn)行，能夠有效避免由于硬件計(jì)算資源不足導(dǎo)致的運(yùn)行崩潰，仿真等待時(shí)間長(zhǎng)，從成本上看按量付費(fèi)模式可減少基礎(chǔ)設(shè)施建設(shè)投入，減少計(jì)算資源閑置。

4.2 并行測(cè)試仿真

基于容器云的編排能力和云供應(yīng)商容器服務(wù)?（AWS: EKS、Lambda, Ali Cloud: ACK、FC）能夠完成大規(guī)模并行仿真任務(wù)，并行測(cè)試執(zhí)行。能夠?qū)囕v網(wǎng)絡(luò)等復(fù)雜系統(tǒng)進(jìn)行仿真，包括虛擬車輛控制單元、車輛總線和仿真模型。每次仿真運(yùn)行可測(cè)量1000個(gè)信號(hào)，輸出報(bào)告支持用戶自定義格式。相較于本地運(yùn)行仿真時(shí)的垂直擴(kuò)展方式，Cloud Service能夠以分布式架構(gòu)水平擴(kuò)展計(jì)算節(jié)點(diǎn)，完成各節(jié)點(diǎn)間仿真任務(wù)的數(shù)據(jù)同步，最大可支持1000個(gè)仿真任務(wù)并行執(zhí)行。

云上仿真測(cè)試用例釋義

4.3 高度安全的云環(huán)境

Cloud Service 上的仿真應(yīng)用Model-Simulator已通過(guò)ISO/IEC 27000?和 27001認(rèn)證。達(dá)到博世安全等級(jí)3(嚴(yán)格保密)。

4.4 兼容的適配性

Cloud Service 兼容COSYM、VECU Builder、ETAB之外，還兼容其它第三方產(chǎn)品，如ECUTest、AVL、Synopsis、Vector等。

4.5 多租戶團(tuán)隊(duì)協(xié)同

多個(gè)仿真測(cè)試團(tuán)隊(duì)可同時(shí)登錄進(jìn)行仿真測(cè)試。各租戶之間模型和信號(hào)等數(shù)據(jù)隔離；租戶之間仿真任務(wù)并行運(yùn)行互不影響；各云上租戶資源可無(wú)限擴(kuò)展。

五

CICT自動(dòng)化流水線

在虛擬控制器生成和虛擬整車平臺(tái)SIL環(huán)境搭建的基礎(chǔ)上，通過(guò)一系列工具鏈實(shí)現(xiàn)持續(xù)集成與持續(xù)測(cè)試的CICT自動(dòng)化流水線。

CICT方案為客戶帶來(lái)的顯著收益：

?開發(fā)與測(cè)試環(huán)節(jié)的全面加速

?盡早發(fā)現(xiàn)錯(cuò)誤并有效反饋

?可重復(fù)使用現(xiàn)有工具

?數(shù)據(jù)安全保障

?使員工可以專注于價(jià)值創(chuàng)造，而非工具與工具鏈

?多方工程協(xié)作的支持

支持構(gòu)建用戶自定義的持續(xù)集成及持續(xù)測(cè)試自動(dòng)化流水線

流水線步驟舉例：

?代碼變更，保存并推送代碼倉(cāng)庫(kù)，Jenkins觸發(fā)CICT Pipeline流水線。

?拉取代碼變更到本地 PC，生成虛擬控制器FMU并進(jìn)行校驗(yàn)。

?COSYM集成并進(jìn)行冒煙測(cè)試。

?持續(xù)測(cè)試通過(guò)，報(bào)告生成和查看分析，上傳測(cè)試通過(guò)虛擬ECU文件至JFrog制品倉(cāng)庫(kù)。

六

應(yīng)用案例

以下是基于ETAS虛擬化開發(fā)工具鏈，列舉一些應(yīng)用案例。

6.1 虛擬標(biāo)定和虛擬總線應(yīng)用，虛擬整車POC

客戶面臨的挑戰(zhàn)和困難：

?仿真平臺(tái)能夠支持接入第三方的模型（如：ML/SL、GT、AMESim、CarMaker等）。

?能夠減少車輛標(biāo)定工作時(shí)間，特別是重復(fù)性標(biāo)定（如：工況脈譜圖的掃點(diǎn)標(biāo)定）。

使用虛擬化方案實(shí)現(xiàn)的成果：

?成功通過(guò)COSYM仿真平臺(tái)完成軟件在環(huán)的閉環(huán)工作。

?標(biāo)定軟件INCA通過(guò)XCP協(xié)議與虛擬控制器建立通訊。

?自動(dòng)化標(biāo)定軟件INCA-FLOW通過(guò)ASAM-XIL接口與ETAS COSYM進(jìn)行連接，實(shí)現(xiàn)對(duì)被控對(duì)象（如：運(yùn)行工況點(diǎn)）的控制，并通過(guò)設(shè)計(jì)好的標(biāo)定流程自動(dòng)實(shí)施標(biāo)定工作。

6.2 基于模型在環(huán)和軟件在環(huán)的功能測(cè)試

客戶面臨的挑戰(zhàn)和困難：

?虛擬化實(shí)踐需要基于目前使用的軟件開發(fā)工具。

?虛擬控制器能夠使用優(yōu)化后的標(biāo)定參數(shù)，并通過(guò)DCM文件進(jìn)行。

?虛擬化實(shí)踐除了在單機(jī)上進(jìn)行，也支持在云端運(yùn)行。

使用虛擬化方案實(shí)現(xiàn)的成果：

?通過(guò)VECU-Builder工具實(shí)現(xiàn)了Type-1虛擬控制器的生成，并使用了DCM文件中優(yōu)化后的標(biāo)定參數(shù)。

?成功通過(guò)COSYM仿真平臺(tái)完成軟件在環(huán)的閉環(huán)工作。

?單機(jī)性能：比實(shí)時(shí)仿真快2+倍。

?通過(guò)Cloud Service實(shí)現(xiàn)了云端運(yùn)行的預(yù)研評(píng)估工作。

6.3 持續(xù)集成和持續(xù)測(cè)試 CI/CT

客戶面臨的挑戰(zhàn)和困難：
?有計(jì)劃、分步驟地進(jìn)行虛擬化實(shí)踐。

?適用于AUTOSAR架構(gòu)的和非AUTOSAR架構(gòu)的軟件。

?不能因?yàn)橐胩摂M化實(shí)踐，大幅增加開發(fā)工程師的工作負(fù)荷。

?虛擬化實(shí)踐要滿足未來(lái)軟件定義汽車的大趨勢(shì)。

使用虛擬化方案實(shí)現(xiàn)的成果：

?根據(jù)客戶的實(shí)際情況成功建立起點(diǎn)是源代碼，終點(diǎn)為測(cè)試報(bào)告的自動(dòng)化Pipeline。

?Pipeline中可以自動(dòng)地生成虛擬控制器，關(guān)聯(lián)被控對(duì)象模型，接入仿真平臺(tái)。并進(jìn)行虛擬控制器的冒煙測(cè)試后，按照設(shè)定的測(cè)試用例進(jìn)行軟件在環(huán)測(cè)試，最后生成報(bào)告。?Pipeline可以在本地服務(wù)器中部署，也可以移植到云端運(yùn)行。

6.4 虛擬標(biāo)定和云端隊(duì)列

客戶面臨的挑戰(zhàn)和困難：

?需要減少車輛道路測(cè)試和標(biāo)定的人力投入和費(fèi)用。

?最大限度兼容目前使用的工具（INCA、ASCMO和MOCA等）。

?提高測(cè)試和標(biāo)定工作的效率。

使用虛擬化方案實(shí)現(xiàn)的成果：

?成功通過(guò)VECU-Builder工具實(shí)現(xiàn)了Type-1虛擬控制器的生成。

?成功通過(guò)COSYM仿真平臺(tái)完成軟件在環(huán)的閉環(huán)工作。?INCA、ASCMO和MOCA等工具能夠在虛擬環(huán)境中無(wú)縫銜接。

?標(biāo)定效率：比實(shí)車測(cè)試快5+倍。

?測(cè)試效率：2小時(shí)仿真=25,000公里路測(cè)。

6.5 虛擬標(biāo)定自動(dòng)化

客戶面臨的挑戰(zhàn)和困難：

?仿真平臺(tái)能夠支持接入第三方的模型（如：ML/SL、GT、AMESim、CarMaker等）。

?能夠減少車輛標(biāo)定工作時(shí)間，特別是重復(fù)性標(biāo)定（如：工況脈譜圖的掃點(diǎn)標(biāo)定）。

使用虛擬化方案實(shí)現(xiàn)的成果：

?成功通過(guò)COSYM仿真平臺(tái)完成軟件在環(huán)的閉環(huán)工作。

?標(biāo)定軟件INCA通過(guò)XCP協(xié)議與虛擬控制器建立通訊。

?自動(dòng)化標(biāo)定軟件INCA-FLOW通過(guò)ASAM-XIL接口與ETAS COSYM進(jìn)行連接，實(shí)現(xiàn)對(duì)被控對(duì)象（如：運(yùn)行工況點(diǎn)）的控制，并通過(guò)設(shè)計(jì)好的標(biāo)定流程自動(dòng)實(shí)施標(biāo)定工作。

七

總結(jié)

7.1 應(yīng)用領(lǐng)域

?針對(duì)功能開發(fā)、集成測(cè)試工程師可以在應(yīng)用層代碼開發(fā)階段完成SIL仿真測(cè)試

?針對(duì)標(biāo)定測(cè)試工程師可以在SIL仿真環(huán)境中進(jìn)行多控制器聯(lián)合虛擬標(biāo)定

?實(shí)車數(shù)據(jù)與虛擬整車相互促進(jìn)

?打造敏捷軟件開發(fā)的研發(fā)生態(tài)

?助力車企打造軟件定義汽車和整車數(shù)字孿生應(yīng)用案例

?整車物理模型的搭建、集成與精度提升

?工具兼容性可支持低成本及跨車型通用

7.2 功能特色

?支持跨軟件架構(gòu)和操作平臺(tái)，生成不同類型的虛擬控制器vECU，操作流程簡(jiǎn)易成熟

?聯(lián)合仿真平臺(tái)支持標(biāo)準(zhǔn)FMU集成，跨平臺(tái)聯(lián)合仿真，靈活度和兼容性高

?支持三方工具多控制器聯(lián)合虛擬標(biāo)定

?支持構(gòu)建用戶自定義的持續(xù)集成及持續(xù)測(cè)試自動(dòng)化流水線

?各類幀級(jí)虛擬總線標(biāo)準(zhǔn)插件。包括CAN、CANFD、LIN、以太網(wǎng)等虛擬總線

?可基于國(guó)內(nèi)云端部署

7.3 收益優(yōu)勢(shì)

?虛擬控制器可靈活應(yīng)用在軟件開發(fā)前期、中期和后期，提升開發(fā)效率

?標(biāo)準(zhǔn)化仿真平臺(tái)，兼容各類虛擬控制器和被控對(duì)象模型，實(shí)現(xiàn)軟件在環(huán)測(cè)試，仿真速率高

?通過(guò)建立持續(xù)集成、持續(xù)測(cè)試Pipeline，減少開發(fā)人員的重復(fù)工作，加速迭代過(guò)程

?支持幀級(jí)虛擬總線、國(guó)內(nèi)云端部署，更好地協(xié)助開發(fā)部門進(jìn)行數(shù)字化轉(zhuǎn)型

?減少硬件測(cè)試臺(tái)架的投資，加快整車開發(fā)測(cè)試和上市周期

?建立多團(tuán)隊(duì)間的協(xié)同開發(fā)軟件的生態(tài)?

?

編輯：黃飛