摘要(yào)：

       在過去(qù)的(de)二十年(nián)中，汽車(chē)軟件(jiàn)的(de)需求和(h•✘βé)應用(yòng)急劇(jù)增長(cháng)，随之複雜(zá)性急劇(jù)上(shàng)σ∞&升，現(xiàn)有(yǒu)技(jì)術(shù)和(hé÷→≤)框架不(bù)足以應對(duì)這(zhè)種複雜(zá)性。現(xiàn)在很(hěn•™≠)明(míng)顯，汽車(chē)制(zhì)造商（OEM）必須重新考慮他(tā)們生(shēng)産車(chē)輛(liàng)的(de₹±§✔)方式以及車(chē)輛(liàng)本身(shēn)的(de)生(shēng)¶→÷命周期。通(tōng)過将重點放(fàng)在軟♣≠÷件(jiàn)上(shàng)，OEM可(kě)以在車(chē)輛(liàng)整個(gè±←δ‌)生(shēng)命周期中實現(xiàn)許多(duō)新的(de)應用(yò↕♠↑ng)用(yòng)例，并打開(kāi)一(yī)個(gè)充滿機(jī¥ φ)遇的(de)新世界。

01.軟件(jiàn)定義汽車(chē)以及虛拟化(huà)技(jì)術(sφ÷hù)

1.1 軟件(jiàn)定義汽車(β§$>chē)的(de)概念

       移動出π"行(xíng)時(shí)代，汽車(chē)已逐漸從(c↓'§óng)純粹由機(jī)械驅動的(de)硬件γ γφ(jiàn)轉變為(wèi)軟件(jiàn)驅動的(de)電(diàn)子™♠(zǐ)産品。當今不(bù)同車(chē)廠(chǎng)的(de)産品硬件(ji ♣àn)配置已逐漸趨同，在成本和(hé)功能(δ∏néng)改善空(kōng)間(jiān)有(yǒu)限的(>§¥£de)情況下(xià)，傳統汽車(chē)價值鏈÷ε¥的(de)重構勢在必行(xíng)。車(ch γ®₽ē)廠(chǎng)打造差異化(huà)的(de)核心要(yào)素已‍₽轉向原先與硬件(jiàn)深度耦合的(de)汽車(ch≈<ē)軟件(jiàn)，随著(zhe)汽車(chē)軟件(ji₩™àn)在新能(néng)源和(hé)智能(néng)φ≤♠‌化(huà)領域不(bù)斷取得(de)成功，邁入“軟件(jiàn)定義汽車(chē)（Software Defined Vehicles，SDV）”時(shí)代已成為(wèi)行(xíng)業(yè)共識。“軟件(jiàn)定義汽車(chē)”即軟件(jiàn)将深度參與到(dào)汽車(chē)的(de)定義、開®≥∑(kāi)發、驗證、銷售、服務等過程中，并不(•®≈bù)斷改變和(hé)優化(huà)各個(gè)過程，是(shì)汽車(♥"chē)從(cóng)基于硬件(jiàn)的(de)産品向軟件(jiàn)為(wèi >≤)中心的(de)電(diàn)子(zǐ)設備不(bù)斷轉變的(de)結★₽&≠果。

     “軟件(jiàn)定義汽車(chē)” 從(cóng)表面上(shàng)看(kàn)是(shì)車(chē)內(nèi)軟件(ji↓♥®àn)（包括電(diàn)子(zǐ)硬件(jiàn)）的(de)數(shù)量、價值超&↔§α過機(jī)械硬件(jiàn)，背後更多(•σ∑πduō)的(de)反應了(le)汽車(chē)從(cóng)高(g$αāo)度機(jī)電(diàn)一(yī)體(€≈≈↑tǐ)化(huà)的(de)機(jī)械"≤終端，逐步轉變為(wèi)一(yī)個(gè)智能(néng)化(huà)、可 '✘¶(kě)拓展、可(kě)持續叠代升級的(de)移動電(diàn)子(zǐ)終端。為(wèi)ε±實現(xiàn)這(zhè)一(yī)目标，整車(chē)在标準操作(zuπ≈♦βò)程序前便預埋了(le)性能(néng)超前的(de)硬件(jiàn)，↔←₽并通(tōng)過OTA在生(shēng)命周期中逐步解鎖和(hé)釋放(fàng)功能(néng)和(hé$÷←)價值。在該背景下(xià)，主機(jī)廠(c★→↑$hǎng)的(de)核心能(néng)力将從(cóng)機(jī)械硬件(jiàn)轉向♠γ↕↓電(diàn)子(zǐ)硬件(jiàn)和(hé)軟件(jiàn)；産業(≥​yè)價值鏈也(yě)将從(cóng)一(yī)錘子(zǐ)硬件(jià≥♦≤☆n)銷售轉向持續的(de)軟件(jiàn)及服務溢價。

1.2 汽車(chē)軟件(jiàn)發展的(de)趨勢

      汽車(chē)“新四化(huà)”離(lí)不(bù)開(kāi)軟件(jiàn)和(hé)算±∑↕(suàn)法随著(zhe)新四化(huà)的(de)深π≥入發展，汽車(chē)正加速從(cóng)從(cóng)機(jī)械設備向高(gāo)度數(shù≈↔)字化(huà)、信息化(huà)的(de)智能Ωδ&&(néng)終端轉變。

      首先，軟件(jiàn γ)及汽車(chē)電(diàn)子(zǐ)占整車(chē)的(de)研發成本逐步提高(' ∞gāo)，車(chē)內(nèi)軟件(jiàn)和(β€hé)電(diàn)子(zǐ)硬件(jiàn)價值有(yǒu)望超過硬÷$®件(jiàn)，成為(wèi)整車(chē)價值的(de)核心。據測算(suàn)，預計(jì)✘β到(dào)2030年(nián)軟件(jiàn)成本占整車(chē)BOM（物(wù)料清單，Bill Of Material）的(de)比重将從(cóng)目前不(bù)到★₹★(dào)10%增長(cháng)到(dào)50%。需指出的(de)是(shì)，這(zhè)裡(lǐ)的(de)軟件(jiàn)  ☆​除應用(yòng)程序開(kāi)發、還(hái)包括AI算(suàn)法、操作(zuò)系統，以及軟硬件(jiàn)一(yī)§↑體(tǐ)化(huà)程度高(gāo)的(de)控制(zh↓>↕ì)器(qì)、芯片等電(diàn)子(zǐ)硬件(jiàn)。

      其次，軟件(jiàn)及軟件(jiàn↓®ε)更叠所帶來(lái)的(de)性能(néng)'♥¥φ和(hé)功能(néng)變化(huà)，将決定未來(lái)汽車(chē)的(de)差→± →異性。軟件(jiàn)的(de)更新維護是(shì)未來(™♣××lái)主機(jī)廠(chǎng)提供差異化(huà)體(tǐ)驗、提升客戶滿意度最經Ω•濟、最便捷、最快(kuài)速的(de)一(yī)種方式。前提是(shì)由硬件(j<​€ iàn)提供冗餘，再由軟件(jiàn)實現(x≠←iàn)叠代。

     ≈Ω 最後，包括主機(jī)廠(chǎng)、零部件(jià★α×≥n)企業(yè)等産業(yè)鏈上(shàng)企☆€業(yè)将加強軟件(jiàn)能(néng)力建設，并≥ ™圍繞“軟件(jiàn)定義汽車(chē)”開(kāi)啓從(cóng)産品開(kāi)發模式、組織架構、人(rén)員(yuán)構成、運♣©營體(tǐ)系等的(de)內(nèi)部變革。此外(wài)，新興的(→₹♠de)軟件(jiàn)公司将借助軟硬件(jiàn)協同能(néng)力，兼$↔容産業(yè)鏈上(shàng)下(xià)多(duō)方需求，一(yī)舉¶≈躍升為(wèi)汽車(chē)産業(yè)鏈上(shàng)新的(de)Tier-1企業(yè)。

1.3 汽車(chē)研發面臨的(de)困局

      首先，分(fēn)布式電(di©☆>↑àn)子(zǐ)電(diàn)氣架構無法滿足未來(lái)更高(gāo)車£ε(chē)載計(jì)算(suàn)能(néng)力的(de)需求。驅使EEA架構升級的(de)另一(yī)個(gè)推動因←€Ω素來(lái)自(zì)于更高(gāo)的(de)通(tōng)φ¶訊效率和(hé)更大(dà)的(de)帶寬容量需求。成✘&→本管控黑(hēi)洞：随著(zhe)車(chē)內(nèi)ECU、傳感器(qì)數(shù)量增加，整車(☆←≤chē)線束成本和(hé)布線難度也(yě)跟著(zhe)≥Ω¶大(dà)幅提升。

      另外(wài)，汽車(chē)軟件(jiàn)的(de)¥∏模塊化(huà)、平台化(huà)程度低(dī)，導緻軟件(jiàn)資源無法集中調度、 ∞©協作(zuò)性差。主機(jī)廠(chǎng)的(de)ECU通(tōng)常來(lái)自(zì)于不(bù)同的(de)零部件(jiàn$∞≈)供應商，事(shì)實上(shàng)控制(zhì)器 ☆(qì)上(shàng)許多(duō)底層軟件(jiàn)的(d¶♥δΩe)重複性很(hěn)高(gāo)，這(zhè)些(xiē)代碼主要(yào)保障控制(zhì)π™'器(qì)的(de)正常運行(xíng)，例如(rú)CAN總線信号的(de)收發、任務進程的(de)調度、Flash數(shù)據的(de)讀(dú)寫等等。但(dàn)礙于每一(yī)家(jiā)供應商↔α₽π的(de)軟件(jiàn)編程語言不(bù)★ ♥±同、接口标準不(bù)同，而且軟件(jiàn)又(yòu)σ®€↓和(hé)硬件(jiàn)高(gāo)度依賴，使得(d​✔e)這(zhè)些(xiē)底層代碼無法被複制(zhì)和(h♣≈↑δé)移植，從(cóng)而造成ECU軟件(jiàn)開(kāi)發的(de)大(dà)量重複和(h∞ γ↕é)資源利用(yòng)的(de)低(dī)效。其次，軟硬件(jiàn)高(gāo)度嵌套、主機(jī)廠(chǎn®¥Ω​g)無法執行(xíng)大(dà)規模、深層次的(de)更新和(hé)升級或定制(z₽↔←♦hì)化(huà)開(kāi)發工(gōπ÷★φng)作(zuò)。分(fēn)布式軟件(jiàn)架構是(shì)一(yī)種面向信号的(deφγ★)架構，控制(zhì)器(qì)之間(jiān)通✘÷(tōng)過信号來(lái)傳遞信息，但(dàn)整個(gè)系統是(shì)封閉、靜✔®(jìng)态的(de)，在編譯階段就(jiù)被定≠φ義死，因此當發生(shēng)例如(rú)主機(jī)廠(chǎng)要(yào)修改或增α₽加某個(gè)控制(zhì)器(qì)的(de)功能(néng)定義，同時(>≥φshí)該指令還(hái)必須調用(yò♠α∑≠ng)另一(yī)個(gè)控制(zhì)器(qì)上(shàng)的(de)π‍λ功能(néng)時(shí)，就(jiù)不(bù)得(de)不(bù)把所有(yǒ♠<♥λu)需要(yào)的(de)控制(zhì)器(qì)都(dōu)升級，大(dà)大(dà)延長≥∞£Ω(cháng)開(kāi)發周期、增加開(kāi)發成本。

1.4 研發模式的(de)轉變

      基于以上(shàng)技(jì)術(shù)架構方面的 ±$(de)變化(huà)，在軟件(jiàn)定義汽車(chē)的(de)背景下(xià) '§∑，汽車(chē)研發将由傳統的(de)瀑布式開(kāi)發向敏捷開(kāi)發的(de)模式轉變​≥ ε。

      敏捷軟件(jiàn)開(kāi)發（Agile software development）：包括需求發現(xiàn)和(hé)解決方•↔×σ案改進。該模式通(tōng)過自(zì)組織和(hé)跨職能(néng)團隊與用♦‍(yòng)戶協作(zuò)，制(zhì)定适應性計(jì)劃，進行(xíng₽λ←§)漸進開(kāi)發、早期交付、持續改進，靈活應對(duì)需求、≠≠♥∞能(néng)力的(de)變化(huà)以及對(duì)需要(yào)解決問(wèn)題÷<<↔的(de)理(lǐ)解的(de)變化(huà)。這(λ♠zhè)是(shì)一(yī)種以用(yσ&¶≤òng)戶需求進化(huà)為(wèi)核心的(de)叠代、循序漸進的(de)開(kāi)發方法。©≤ 工(gōng)程師(shī)先将用(yòng)戶最關注的(de)軟件(jiàn)原型做↔≤♥(zuò)出來(lái)進行(xíng)交付，根據用(yòng)戶在實際場(cεΩ♠hǎng)景中反饋的(de)問(wèn)題，快(kuài)速修∞™£ 改彌補需求中的(de)不(bù)足。上(shàng)述過程不(b<>↕≈ù)斷叠代，直至用(yòng)戶滿意。DevOps是(shì)一(yī)組過程、方法和(hé)系統的(de)統稱，集文(wén←♦☆☆)化(huà)理(lǐ)念、實踐、工(gōng)具于一(yī)身(shēn)，重視(shì)開(k÷¥>āi)發（Dev）和(hé)運維（Ops）和(hé)質量（QA）部門(mén)之間(jiān)的(de)溝通(tōng)合作(zuò)♦↑©‍。與傳統軟件(jiàn)開(kāi)發模式系相(xiàng)比，DevOps打破了(le)開(kāi)發和(hé)運維之間(jiān)的(de)壁壘"÷≤‍，通(tōng)過自(zì)動化(huà)“軟件(jiàn)交付”和(hé)“架構變更”的(de)流程，使得(de)軟件(jiàn)的(de)構建、測試和(hé)發布能(néng)更加​ ©<快(kuài)捷、頻(pín)繁和(hé)可(kě)靠，從(cóγ& ¶ng)而幫助團隊更快(kuài)地(dì)發展和(hé)改進産品、服務客戶 ≤αβ、高(gāo)效參與市(shì)場(chǎng)競£‍€争。

1.5 虛拟化(huà)的(de)價值

       汽車(chē)軟件(jiàn)<∏"開(kāi)發将遵循IT行(xíng)業(yè)的(de)發展規律，引入中間(jiān)件(jiàn)技<↓(jì)術(shù)、虛拟化(huà)技(jì)術(shù)來(lái)實現(xiàn)λε軟件(jiàn)模塊化(huà)、硬件(jiàn)抽象化(huà)和(hé)标準化(huà)，♥>​從(cóng)而進一(yī)步解鎖軟硬件(jiàn)的(de<≥₩‌)耦合關系，滿足電(diàn)子(zǐ)電(diàn)氣架構 ∑靈活、可(kě)拓展的(de)需求。為(wèi)應對(duì)流程轉變上(shàng)的(de)挑戰，開(kāi)₹¥發團隊可(kě)考慮将軟硬件(jiàn)解耦後，硬件(jiàn)和€↔"(hé)軟件(jiàn)部分(fēn)各自(zì)按照(zhào)獨立時(shí)間∑α←(jiān)線來(lái)開(kāi)發，并在進行(xíng)軟件(jiàn)更♠₽α改後無需對(duì)整個(gè)車(chē)輛(liàng)進行(xíng)重新驗‍γ證，純軟件(jiàn)的(de)開(kāi)發和(hé)驗證過程從∑≈(cóng)原型車(chē)或者硬件(jiàn)在← ÷±環測試過渡到(dào)軟件(jiàn)在環（SiL）的(de)測試和(hé)驗證。這(zhè)種軟硬解耦的(de)方式同時(×€≥$shí)也(yě)迎合了(le)當下(xià)将ECU功能(néng)整合到(dào)中央計(jì)算(suàn)單元或域控§$☆β制(zhì)器(qì)的(de)趨勢，在多(duō)合一(yī)控制(zhì)器λ≥φ(qì)融合的(de)過程中發揮作(zuò)用(yòng)，軟≤★‌硬件(jiàn)模塊可(kě)以在不(bù)同的(de)硬件(jiàn)平台運行(xíng)§✘×≤，并在車(chē)輛(liàng)整個(gè)生(shēng)命周期內(nèi)更新。

      那(←™☆nà)麽軟件(jiàn)在環SiL有(yǒu)什(shén)麽應用(yòng)場(c♥‍ hǎng)景呢(ne)？其應用(yòng)場(chǎng)景通(tōng ∑÷®)常是(shì)在快(kuài)速變更的(de)功♠←♠能(néng)需求下(xià)敏捷開(kāi)發及快(kuài)速叠代。要(λ§yào)求盡早進行(xíng)軟件(jiàn)驗證并發現(xiàn¶±≥)和(hé)糾正代碼中的(de)重要(yào)錯(cuò)誤，特别是(shì)涉及安全相(xiàn<♣$∏g)關錯(cuò)誤。在高(gāo)頻(pín)率OTA雲端升級軟件(jiàn)的(de)情況下(xià)自(zì)動化(huà)持續驗證±₽©。在以上(shàng)場(chǎng)景下(xià)軟件₽→$(jiàn)在環SIL測試能(néng)夠脫離(lí)硬件(jiàn)而快("≥kuài)速驗證控制(zhì)器(qì)的(de)功能(néng'™)代碼。

      軟件(jiàn)在環SiL的(de)最關鍵的(de)一(yī)個(gè)核心就(δ ↔jiù)是(shì)虛拟化(huà)：即通(tōng)過将真實控制(zhì)器(qì)轉化( ✔huà)為(wèi)虛拟控制(zhì)器(qì)，部署到(dβ∏ào)PC上(shàng)集成環境和(hé)聯合仿真平台，接入CI/CT/CD自(zì)動化(huà)流水(shuǐ)線，并上(shàng)雲端φ¥≈↓進行(xíng)大(dà)規模測試，從(cóng)而搭建φ≠∞$完整的(de)DevOps的(de)SiL平台。

     虛拟化(h¥"↔∞uà)技(jì)術(shù)使得(de)在Windows PC上(shàng)對(duì)汽車(chē)ECU（Electronic Control Unit，電(diàn)子(zǐ)控制(zhì)器(qì)單元）進行(≈€↕↑xíng)閉環仿真成為(wèi)可(kě)能(néng)，能(néng)有(yǒu)效δ★改善ECU開(kāi)發過程。一(yī)些(xiē)開(kāi)發任務得(de)以從(cóng)道γ♠£(dào)路(lù)、測試平台和(hé)HIL（Hardware in the Loop，硬件(jiàn)在環）轉移到(dào)PC上(shàng)，縮短(duǎn)開(kāi)發ε•≈‍時(shí)間(jiān)和(hé)成本。從(cóng)OEM的(de)視(shì)角來(lái)看(kàn)虛拟化(huà)，可(k©↓σě)以将軟件(jiàn)測試前移到(dào)早期開♠‌↔×(kāi)發階段閉環，既減少(shǎo)了(le)項目初期昂貴的(de)BOM成本，又(yòu)降低(dī)了(le)軟件(jiàn)開(kāi)發成本和(hé)¶←®±時(shí)間(jiān)，在實現(xiàn)軟件(jiàn)CICT閉環自(zì)動化(huà)的(de)同時(shí)，可(kě)以建立供應商之間(± ¥↓jiān)的(de)發展生(shēng)态系統，進行(xíng)多(duō)團隊多(duō)租‍✘"戶并行(xíng)工(gōng)作(zuò)。從(cóng)工(gōng)程師(shī)的(de≠‍©™)視(shì)角來(lái)看(kàn)虛拟化(hδ€'≈uà)，傳統汽車(chē)軟件(jiàn)開(kāi)發的(de)流程一(yī)♣☆般為(wèi)：功能(néng)開(kā¶​∞♦i)發團隊使用(yòng)基于模型的(de)工(gōng)具鏈開(kāi)發ECU模型，生(shēng)成C代碼，然後針對(duì)目标處理(lǐ)器(qì)進行(xíng)代<≠<碼編譯，并使用(yòng)測試平台，HiL系統和(hé)道(dào)路(lù)測試來(lái)測試♣£✔≈和(hé)驗證生(shēng)成的(de)ECU，進而将結果反饋至開(kāi)發人(rén)員(yuán)，結束開(kāi)發周期。該過程₹↕☆存在的(de)主要(yào)缺點有(yǒu)：叠代時(shí)間(jiānα♥)長(cháng)，受原型車(chē)和(hé)測試設備的(de)γλ™限制(zhì)—硬件(jiàn)資源昂貴且稀缺。為(wèi)開(kāi)發團隊提供虛拟ECU可(kě)解決上(shàng)述問(wèn)題：開(kāi)發人(rén)員(π‍$yuán)可(kě)在PC機(jī)上(shàng)對(duì)軟件(jiàn)進行(x♦∑§íng)模拟、校(xiào)準和(hé)測量，縮短(duǎn)&α開(kāi)發周期，減少(shǎo)對(duì)稀缺資源和(hé)★δφ實際硬件(jiàn)的(de)嚴重依賴；同時(shí)，通(tō>"↑>ng)過虛拟ECU，開(kāi)發人(rén)員(yuán)可(kě)随時(shí)觀÷​察和(hé)修改內(nèi)存變量甚至硬件(jiàn)狀态，極大(dà)提升工(gōng∏>​)作(zuò)效率。

02.vECU虛拟控制(zhì)器(qì)集成
2.1 虛拟控制(zhì)器(qì)的(de)介紹β₽‍

      虛拟控制(zhì)器(qì)簡稱vECU (即Virtual ECU)，表示脫離(lí)真實硬件(jiàn)依賴後基于PC獨立編譯和(hé)運行(xíng)的(de)軟件(jiàn)，vECU所包含的(de)內(nèi)容通(tōng)常可(kě)由ASW,vBSW,vCDD以及RTE這(zhè)幾個(gè)部分(fēn)構成，在集成編​≠ ©譯後封裝成基于PC的(de)可(kě)執行(xíng)文(wén)件(jiàn)。

       對(duì)于功能(±↓ ₽néng)測試驗證工(gōng)程師(shī)，通(tōng)常他(t↑☆®↑ā)會(huì)拿(ná)到(dào)一(yī)個(gè)帶有(yǒu)軟件(jiàn÷φγ)的(de)完整ECU控制(zhì)器(qì)，并以硬件(jiàn)在環或實車(chē)環♦©δ境作(zuò)為(wèi)測試環境進行(xíng)測試，£™整個(gè)測試過程可(kě)能(néng)受硬件(jiàn₹ε$₩)和(hé)線束的(de)限制(zhì)，每當遇到(dào)軟件¥λ≥<(jiàn)的(de)失效時(shí)首先需要(yào)考慮線束或 €β™者硬件(jiàn)通(tōng)信上(shàng)的(de)問(wλ↓èn)題，長(cháng)此以往測試效率通(tōng)常受硬件(ji£←≠àn)資源和(hé)硬件(jiàn)狀态的(de)限制(zhì)，難以在受↔£•"限的(de)條件(jiàn)下(xià)高(gāo)效的(de)↓≥¥完成測試。但(dàn)是(shì)如(rú)果僅ECU內(nèi)與硬件(jiàn)無關的(de)功能(né≈♣ ∞ng)，隻需解耦ECU産品代碼并封裝成vECU運行(xíng)在PC上(shàng)進行(xíng)測試即可(kě)。數(shù)據采集和(h€↕≤é)驗證過程同真實環境軟件(jiàn)測試β★σ工(gōng)具一(yī)緻，如(rú)INCA、window調試器(qì)等等。

      ∞π 而對(duì)于功能(néng)開(kāi)發工('ε>¶gōng)程師(shī)來(lái)說(shuō)，驗證功能(néngπ∑)時(shí)需要(yào)在完整ECU軟件(jiàn)上(shàng)進行(xíng)集成并驗證功能(néng)，該集成過程通(tōng ←α)常由軟件(jiàn)集成工(gōng)程師™≠♠←(shī)負責，軟件(jiàn)集成該功能(néng)同時(shí)δπ≥還(hái)需要(yào)考慮ECU 平台化(huà)升級、底層芯片配置等諸多(duō)因素導緻叠代效率低(dī)下(xià)的(de) ♣問(wèn)題。其實對(duì)于其生(shēng)成的(de)ECU功能(néng)代碼，依然可(kě)以将這(zhè)一(yī)部分(‍≥♦fēn)代碼封裝成一(yī)個(gè)部分(fēn)功能(néng)的(de)vECU并進行(xíng)仿真測試。并且你(nǐ)可(k<&" ě)以在任意時(shí)間(jiān)終止仿真并進行(xíng)Debug，還(hái)可(kě)以在功能(néng)驗證過程中根據需要(yào)對(duì)vECU做(zuò)預标定從(cóng)而提前驗證預設标定數(shù)據× 。

       簡而言¥♥之，就(jiù)是(shì)将控制(zhì)器(qì)∏ΩC代碼基于PC環境編譯後生(shēng)成FMU格式的(de)可(kě)執行(xíng)文(w₹§∞¥én)件(jiàn)運行(xíng)在常規PC仿真環境上(shàng)，以更早和(hé)更快(kuài)的(dδ¥™‌e)方式進行(xíng)測試及調試。

2.2 虛拟控制(zhì)器(qì)的(de)分(fēn)類

       生(shēng)成虛拟控制(zhì ©✔)器(qì)的(de)方式有(yǒu)兩種，一(yī &α£)種是(shì)通(tōng)過C源碼經過PC的(de)x86編譯器(qì)後生(shēng)成可(kě)以運行(xíng)在PC上(shàng)vECU目标文(wén)件(jiàn)，并于PC上(shàng)進行(xíng)系統測試和(h>♠∞∏é)驗證後反饋給研發工(gōng)程師(shī)。另一(yī)種是(shì)♠∏将C源碼編譯成目标芯片的(de)程序（hex文(wén)件(jiàn)）後，運行(xíng)在目标芯片的(de)指令模拟器(qì)★π上(shàng)來(lái)進行(xíng)系統測Ω♥試後再将結果反饋給研發工(gōng)程師(shī)。

       如(rú)上(sε↔>÷hàng)圖所示，Type-1 vECU,  Type-2 vECU, Type-3 ≤✘®€;vECU為(wèi)第一(yī)類通(tōng)過C源碼的(de)構建方式生(shēng)成的(de)vECU，Type-4為(wèi)第二類通(tōng)過目标程序運行(xíng)在目标芯片指令模拟器(qì)的(de)方↓←€≈式實現(xiàn)vECU。Type-4 vECU雖然可(kě)執行(xíng)的(de)是(sh™★≤♣ì)同一(yī)個(gè)目标hex文(wén)件(jiàn)，但(dàn)緩慢(màn)的(de)運行(xíλλ₩ng)效率及芯片叠代所帶來(lái)大(dà)量工(g↑÷₹ōng)程服務來(lái)屏蔽當前ECU項目的(de)部分(fēn)二進制(zhì)控制(zhì)指令，當前大(d‍∑✘∏à)部分(fēn)用(yòng)戶仍會(huì)采用(yò€≥ng)基于PC編譯器(qì)Type1 Type2 和(hé)Type3的(de)方式。基于PC編譯器(qì)編譯控制(zhì)器(qì)C代碼的(de)諸多(duō)優勢，比如(rú)：vECU 的(de)更快(kuài)的(de)運行(xíng)效率、仿真時(shí)的(de)在↑ ∞₩線Debug、解耦真實硬件(jiàn)以及對(duì)↑<實驗結果更快(kuài)的(de)反饋時(shí)間(j↑∞&iān)。 雖然采用(yòng)vECU來(lái)驗證有(yǒu)諸多(duō)✔₩∞優勢，但(dàn)用(yòng)其進行(xíng)測試和(hé)仿真時(shí)仍有(yǒu↑"')一(yī)定限制(zhì)，比如(rú)無法評估和(h✘♠¥☆é)分(fēn)析諸如(rú)軟件(jiàn)上(shàng)的(de)時(sh☆'í)間(jiān)表現(xiàn)、CPU負載、內(nèi)存資源的(de)消耗以£∏及模拟硬件(jiàn)中斷等特性。

2.3 FMU介紹

      FMU是(shì)對(duì)動态鏈接庫DLL進行(xíng)的(de)二次封裝，它是(shì)基于FMI協議(yì)進行(xíng)封裝的(de)模€δλ&型文(wén)件(jiàn)。FMI協議(yì)是(shì)獨立于建模軟件(jiàn)的(de)标準接口協議(yì)，可(kě)以用(yòng)于集成不(bù)同的($₹÷de)軟件(jiàn)建立的(de)不(bù)同詳細程度$★β的(de)模型，進行(xíng)MiL/SiL仿真。

      FMI的(de)全稱叫Functional Mockup In♠¶ ↓terface 。FMI是(shì)為(wèi)了(le)仿真領域定義的(de)。FMI 定義了(le)二進制(zhì)的(de)★<标準格式仿真模型交換。FMU 數(shù)學模型的(de)代碼實現(xiàn)就(jiù)是(shì)"★"将提供的(de) C 頭文(wén)件(jiàn)裡(lǐ)面定©÷♥∞義的(de)函數(shù)都(dōu)實現(xδ¶iàn)，如(rú)果需要(yào)做(zuò)到(dào)源碼保密，則将其封裝成動态∏×鏈接庫 .dll 就(jiù)行(xíng)。

      一(yī)般商業(yè)化(huà)的(de∑‍‌÷)仿真工(gōng)具比如(rú) CarSim、CarMaker 、AVL Cruise、Amesim和(hé)Simulink 、ASCET等都(dōu)由官方提供 FMU。在 FMI 官網上(shàng)列出了(le)目前提供了♥ &™(le) FMU 的(de)軟件(jiàn)可(kě)以在•λ®₹以下(xià)路(lù)徑找到(dào)https://fmi-standard.org/¥↕∏↑

2.4 vECU自(zì)動化(huà)生(shēng)成流• ×π程

      以E≠λ>TAS的(de)VECU-BUILDER為(wèi✘$>)例，這(zhè)是(shì)一(yī)個(gè)基于Python✘≤和(hé)CMake的(de)WindoΩδ←∏ws工(gōng)具。

      為(wèi)>✔了(le)創建一(yī)套生(shēng)成PC Target的(de)虛拟控制(zhì)器(qì)FMU 文(wén)件(jiàn)，我們需要(yào)有(yǒu)一(yī)套軟件(jiàn)∑€集成和(hé)編譯工(gōng)具鏈：自(zì)動化(huà)vECU編譯工(gōng)具鏈。這(zhè)個(gè)工(gōng)具鏈需要(yào)一₩γ(yī)旦配置完成後，可(kě)實現(xiàn)一(yī)鍵生(shēng)成虛拟控制(zhìγ✔β✘)器(qì)。

      初次生(shēng)成vECU工(gōng)作(zuò)流程：

      Rebuild生(shēng)成vECU工(gōng)作(zuò)流程：

03.集成環境及聯合仿真
      下(xià)面介紹一(yī)下(xià)關于FMU的(de)集成環境和(hé)聯合仿真平台。

3.1 COSYM介紹

      COSYM（系統協同仿真）産品是(shì)一(yī)個(gè)仿♠≥<✘真和(hé)集成平台，作(zuò)為(wèi)系統級軟件(jiàn)在環的(de)主幹，能(néσ¥ng)夠方便支持ECU間(jiān)通(tōng)信，并使能(ε£₹←néng)OEM廠(chǎng)商成為(wèi)虛拟車(chē)輛(liàng)集成商。一(yī)旦OEM廠(chǎng)商開(kāi)發了(le)自(×≥β©zì)有(yǒu)的(de)構建模塊庫，将能(néng)夠方便采用(y↑δ≠$òng)COSYM進行(xíng)模塊集成與連接，使能(néng)控制(zhì)器(qì)之間(jiānα&×)精确地(dì)通(tōng)信。COSYM具有(yǒu) “時(shí)序主控” ，能(néng)夠協調所集成模塊時(shí)間(π≠±jiān)同步。 COSYM提供了(le)圖形配置界面（GUI）和(hé)實時(shí)操作(zuò)環境（CEE），以實現(xiàn)有(yǒu)效的(de)用(yòng)戶交互。Ω↔旨在為(wèi)用(yòng)戶提供：

       ►模塊導入，集成和(hé)部署；

       ►多(duō)平台仿真：

     ∑>★¶     基于Windows的(de)自(zì)适應時(shí)間(jiān)（ATS），軟實時(shí)(MiL/SiL)；

          基于β¥ 雲端的(de)并行(xíng)加速運算(suàn)(MiL/SiL)；

       σ‍ φ   基于Linux的(de)實時(shí)仿真(HiL)；

       ►離(lí)散和(hé)連續仿真系統的(de)交互操控及結果可(kě)視(shì)化(h≤ uà)(CEE)；

       ►高(gāo)級程序員(yuán)/用(y✔÷≈±òng)戶可(kě)以使用(yòng)ASAM XiL和(hé)RestA♣↓PI（Python接口等）接 口 與COSYM進行(xíng)交互。★φ

      通(tōng)用(yòng)模型集成器(qìδεα€)主要(yào)優勢：

      ►通(tōng)用(yòng)FMI2.0集成接口，可(kě)快(kuài)速複用(yòng)被控對(duì)象模型，虛拟控制(zh‌÷®≈ì)器(qì)模型和(hé)幀級虛拟總線模型

      ►COSYM提供Rest API，可(kě)啓動後台運行(xíng)模式，支持自(zì)動化£ε(huà)流水(shuǐ)線工(gōng)具接入

      ►可(kě)實現(xiàn)基于Windows和(hé)Linux*增量編譯，提升集成效率

      聯合仿真器(qì)主要(yào)優勢：

      ►支持ASAM-XiL标準接口，調用(yòng)API即可(kě)運行(xíng)仿真環境

      ►支持基于Windows和(hé)Linux*系統下(xià)的(de)自(zì)動化(huà)集成測試

      ►支持基于雲原生(shēng)和(hé)容器(q©÷ì)鏡像技(jì)術(shù)的(de)仿真計(jì)算(suàn)

      ►支持第三方工(gōng)具交互式測試，例如(rú)：測試管理(lǐ)與标定工(gōng)具和(h♥₽é)總線仿真與信息安全工(gōng)具功能(néng)

3.2 COSYM功能(néng)

      功ε≥能(néng)模塊集成：

      ►COSYM支持用(yòng)于聯合仿真的(de)功能(néng)模型接∞<口标準（FMI）V2.0；

      ►提供了(le)用(yòng)于虛拟ECU（vECU）集成和(hé)仿真的(de)環境；

      ►建模工(gōng)具ASCET和(hé)ASCMO模型；

      ►Labcar系列半物(wù)理(lǐ)模型，基于Simulink的(de) 模型編譯導入；

      ►支持模闆化(huà)的(de)C模塊；

      模ε&塊間(jiān)通(tōng)信連接：

      COSYM 提供了(le)基于CAN/CANFD, 車(chē)載以太網，FlexRay, LIN的(de)的(de)汽車(chē)總線虛拟仿真技(jì)術(shù)"↑>‍。基于共享內(nèi)存，該虛拟總線仿真為(wèi)被動和(hé)分(fēn)散式，分(→≥®fēn)布式系統因此可(kě)以由任意數(shù)量的(de)模塊構建。不(bù)需要(yào)•Ω♠真實的(de)網絡接口，可(kě)在虛拟vNet接口上(shàng)捕獲網絡流量并将其轉發到(dào)真實的(de)網絡接口。虛拟CAN和(hé)車(chē)載以太網支持在ISO / OSI第二層級及以上(shàng)的(de)邏輯總線行(σ✔™γxíng)為(wèi)模拟，模拟可(kě)到(dào)幀的(de)傳輸而非電(diàn)壓電(d >§iàn)平。COSYM  可(kě)提供vPIN 級别的(de)vECU信号互連插件(jiàn)-虛拟電(diàn)器(qì)層（vEL），以實現(xiàn)例如(rú)故障存儲器(qì)，EEPROM，通(tōng)訊堆棧和(hé)輸入/輸出的(de)測試驗證；相(xiàng)比真實硬件(jiàn)，該插件(jiàn&☆≠)簡化(huà)或删除了(le)部分(fēn)特定硬件(jiàn)和(hé)複雜(zá)‌✔♣驅動程序相(xiàng)關的(de)仿真。

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

       ►虛拟控制(zhì)器(qì)自(zì)動​¥"尋優标定（節能(néng)減排）

      ►大(dà)規模雲端并行(xíng)計(jì)算(suàn)及多(duō)租戶協同工(gōng)作(≈✔zuò)（降本增效）

      ►α★©虛拟整車(chē)及産品級代碼白(bái)盒持續集成與測試（加速叠代）

       ►被控對(duì)象模型自(zì)動參數(shù)化(huà)（精度提"÷升）