2024年7月11-13日，2024中國汽車論壇在上海嘉定舉辦。本屆論壇以“引領(lǐng)新變革，共贏新未來”為主題，由“閉門峰會、大會論壇、10多場主題論壇、9場重磅發(fā)布、主題參觀活動”等多場會議和若干配套活動構(gòu)成，各場會議圍繞汽車行業(yè)熱點重點話題，探索方向，引領(lǐng)未來。其中，在7月12日下午舉辦的“主題論壇四：數(shù)據(jù)鏈動汽車，智能駛向未來”上，易特馳汽車技術(shù)有限公司軟件開發(fā)解決方案總監(jiān)吳正發(fā)表精彩演講。以下內(nèi)容為現(xiàn)場演講實錄：

  各位領(lǐng)導(dǎo)、各位同仁下午好，我是來自于易特馳的吳正，今天下午我會把汽車行業(yè)軟件開發(fā)面臨的挑戰(zhàn)和博世集團(tuán)以及易特馳公司針對這個挑戰(zhàn)的一些想法和大家分享。

  主要由于自動駕駛和智能座艙這兩個域的軟件開發(fā)驅(qū)動，給新的軟件開發(fā)工程師帶來了新的挑戰(zhàn)，主要集中在三部分：

  1.部署頻率。

  2.新功能的開發(fā)速度。

  3.當(dāng)我們SOP以后，如果我們的軟件有BUG，是不是能在以小時為計的時間之內(nèi)發(fā)現(xiàn)這個BUG，同時把BUG迭代掉。

  這三個指標(biāo)針對于之前傳統(tǒng)的V-cycle的開發(fā)模式無論如何達(dá)不到的，這是我們現(xiàn)在必須面對的挑戰(zhàn)，必須找到相應(yīng)的解決方案。

  站在主機(jī)廠的角度，現(xiàn)在軟件的集成度越來越高，電子電氣架構(gòu)從傳統(tǒng)的分布式一直往SOA的架構(gòu)上迭代，就意味著有越來越多的功能從傳統(tǒng)控制器拆出來、解耦出來，往你的主機(jī)電腦上不停地集中、不停地迭代，就意味著單個車載電腦軟件的復(fù)雜程度越來越大，就意味著集成過程中參與方越來越多，從操作系統(tǒng)、基礎(chǔ)軟件、中間件、算法、應(yīng)用層，越來越多的玩家集中在一個控制器的開發(fā)中。

  作為主機(jī)廠，我負(fù)責(zé)最后的集中交付，我面臨的問題是當(dāng)我拿到這些軟件集中的時候，已經(jīng)在整個開發(fā)流程的中后期，如果這個階段發(fā)現(xiàn)問題的話，時間壓力、成本壓力、溝通壓力非常大?，F(xiàn)在大家都比拼時間和速度，如果沒有很好的辦法把問題提前發(fā)現(xiàn)，一定要把問題集中在最后的集成階段才能發(fā)現(xiàn)的話，面臨的挑戰(zhàn)就非常大，團(tuán)隊和交付期面臨不可控的因素也會越來越多。

  所有主機(jī)廠都在想，我們挑戰(zhàn)已經(jīng)在面前了，用什么樣的方法解決這個問題?絕大多數(shù)主機(jī)廠的軟件工程師都建立了很大的團(tuán)隊，500人、1000人團(tuán)隊，他們做的事情就是從傳統(tǒng)的V-cycle向DevOps開發(fā)流程持續(xù)集成、持續(xù)交付的方式實現(xiàn)。通過ETAS跟歐洲和美國的主機(jī)廠，和國內(nèi)主機(jī)廠的伙伴，發(fā)現(xiàn)大家做DevOps的時候通常會有三個級別：第一是實現(xiàn)了單個軟件模塊的自動化流水線，軟件模塊本身已經(jīng)可以自動化實現(xiàn)開發(fā)和測試，依然無法避免最后階段的集成，這個就是集成的地域模式無法避免。做得好一點，我們可以把功能相近的軟件模塊或者地理上相近的，或者組織結(jié)構(gòu)相近的一些模塊或者功能可以進(jìn)行預(yù)編譯、預(yù)集成，極大減少了最后階段的集成，可以實現(xiàn)部分的改善。

  如果要想徹底解決這個問題，我們現(xiàn)在提出了“軟件工廠”的概念，所有軟件的參與方是基于合作的平臺，當(dāng)然是有權(quán)限的限制來共同開發(fā)，他的想法是只要有一版軟件的提交，這版軟件就會自動在平臺上把所有該做的軟件事情通過流水線的方式自動化實現(xiàn)，包括現(xiàn)在說的模塊測試、集成測試甚至以后的回歸測試，所有這些東西都可以在軟件觸發(fā)之后自動觸發(fā)，作為軟件的開發(fā)工程師可以第一時間拿到測試報告，可以在很快的閉環(huán)之內(nèi)不停地迭代軟件，不用等到最后的集成。

  這是針對最下面這一層實現(xiàn)一個軟件模塊或者軟件端功能自動化流水線的實例，這是去年底我們跟亞馬遜合作，在亞馬遜Re Invent的技術(shù)日上聯(lián)合展出。我們的目的，現(xiàn)在很多主機(jī)廠做軟件的時候還有一個問題，大家每個軟件開發(fā)者用自己的電腦裝了一個軟件開發(fā)環(huán)境進(jìn)行代碼開發(fā)、代碼提交，現(xiàn)在很大的問題就是開發(fā)環(huán)節(jié)和驗證環(huán)節(jié)、部署環(huán)節(jié)如果不一致的話，用的公域版本不一致、庫的版本不一致，工程師本身在電腦上開發(fā)沒有問題，但一旦真正部署到實際環(huán)境上，這些問題無法提前發(fā)現(xiàn)，這就是為什么我們有一個Washing Workbench的概念，我們把所有的開發(fā)環(huán)境以鏡像的方式提前在云上部署好。作為任何一個軟件工程師，只要根據(jù)我編的項目平臺進(jìn)行登錄，還會自動在云端建立起來我要使用的軟件開發(fā)環(huán)境，就可以針對這個環(huán)境開發(fā)軟件，進(jìn)行軟件提交，當(dāng)我推出以后，所有這些資源會自動被釋放。這是一個軟件開發(fā)虛擬集成環(huán)境的概念。

  一旦軟件被提交到了代碼倉庫里，所有剛才我說的集成測試，甚至當(dāng)你的軟件編譯過程中，相應(yīng)的需求文檔也會自動被觸發(fā)生成，之前ASPACE要求的追溯性可以通過這個平臺進(jìn)行保證。接下來虛擬控制器的生成，虛擬控制器和多樣模型的閉環(huán)搭建，和我們測試用例的自動拉取，基于測試用例在云端自動測試的執(zhí)行，所有這些東西都是在云端自動實現(xiàn)的，作為軟件開發(fā)工程師可以拿到自動的軟件開發(fā)報告，來驗證我剛才提交的那版軟件是不是有問題，如果有問題的話可以立刻迭代掉。

  這是當(dāng)時我們跟亞馬遜聯(lián)合發(fā)布的一個例子，這個例子是跟我有關(guān)，技術(shù)控搞得比較復(fù)雜一點。這個例子本身就把剛才PPT上說的幾個步驟全部實現(xiàn)，怎么通過虛擬的軟件開發(fā)環(huán)境，我在云端進(jìn)行代碼的編寫或者建模，模型建完以后怎么提交到代碼倉庫，提交代碼倉庫以后就會自動觸發(fā)所有軟件接下來編譯和測試的工作。

  這邊是三個層次當(dāng)中的第三個層次，現(xiàn)在博世內(nèi)部也有一個軟件工廠的開發(fā)平臺，這個平臺舉兩個例子。基于平臺，我們首先開發(fā)了一個ADAS中間件，另外是AUTOSAR AP。基于這兩個平臺，我們跟合作伙伴聯(lián)合開發(fā)，這個平臺本身是跨公司、跨國家的一個合作平臺，這個平臺大家可以看到每天有將近600個工程師在上面進(jìn)行開發(fā)和迭代，最多的時候需要同時在云上起180個虛擬機(jī)支持所有流水線的執(zhí)行，每天會有超過100GB data的同步，無論你是下載還是代碼的推送、驗證都會基于這個平臺進(jìn)行，這是我們博世內(nèi)部基于軟件工廠概念的實踐。

  這是平臺簡要的介紹，我們有很多成熟的組件已經(jīng)在里面了，可以根據(jù)客戶需求定制化開發(fā)，還有資源的監(jiān)控，所有資源都可以搭建和動態(tài)釋放，完全取決于你現(xiàn)在有多少人在做工作，做了哪些工作，所有這些都可以動態(tài)監(jiān)控。這里可以看到實時在跑的流水線是哪些，這些流水線是做什么的，下面你要點進(jìn)去，每個流水線的細(xì)節(jié)都可以看到，整個平臺會支撐跨公司、跨域的合作。這是我們面對軟件新挑戰(zhàn)的解決方案。

  這個方案最核心的解決方案就是虛擬化測試(軟件在環(huán)測試)，傳統(tǒng)控制器的開發(fā)強烈依賴于軟件開發(fā)完以后，做完軟件必要測試以后一定要上HiL上Bench或者上整車才能交付release?，F(xiàn)在電子電氣架構(gòu)逐漸集中，逐漸和強實時real time的操作系統(tǒng)進(jìn)行解耦，你會把很多功能放在非安全域的控制上執(zhí)行。這些功能本身就和實時系統(tǒng)解耦了，如果解耦這些功能完全可以用虛擬化的方式測試掉，這是我們的方案。要做這個事情本身大概分為幾步，首先針對于基于控制器的代碼，必須要有辦法生成虛擬控制器，把以前跑在控制器ECU上的程序可以讓它跑在PC端、云端。

  另外我們要把市面上比較主流的多樣模型集中在一起，因為所有按功能劃分的部門，無底盤、PT、自動駕駛、座艙他們都有用得非常習(xí)慣的第三方主流的模型，發(fā)動機(jī)模型、變速箱模型或者車輛動力學(xué)模型、道路模型，所有這些模型我們必須找到一個平臺，把它和虛擬控制器可以通過虛擬總線的方式聯(lián)系在一起，我們這個平臺叫call simulation，我們可以把市面上所有主流的對象模型和生成的虛擬控制器進(jìn)行閉環(huán)搭建。基于這個，搭建起來一個閉環(huán)的環(huán)境以后，基于這個環(huán)境可以做測試甚至做虛擬標(biāo)定，因為我在很多主機(jī)廠，他們最大的問題是現(xiàn)在的車，單車型銷售越來越少，但變種越來越多，這種情況下以前這么投入造很多樣車跑實驗、做耐久是無法負(fù)擔(dān)的，這個地方需要有虛擬環(huán)境，把絕大多數(shù)的測試甚至成熟度不高的預(yù)標(biāo)定做完，現(xiàn)在我們有一些客戶是基于這個平臺做預(yù)標(biāo)定的事情。最后我們可以把整個環(huán)境進(jìn)行到云端部署，跨部門合作就不成問題了。

  接下來有一個視頻，我們基于簡單純電的平臺建立了純電的虛擬環(huán)境，如果大家對測量標(biāo)定比較熟悉的話這是主流的測量標(biāo)定工具INCA，也是我們公司的?；谶@個虛擬平臺，標(biāo)定工程師和測試工程師跟他上實車，跟他上HiL、跟他上Bench用的工具一樣，依然通過這個工具進(jìn)行通訊，采集控制器里面的數(shù)據(jù)，甚至在這個例子里我們進(jìn)行了預(yù)標(biāo)定自動標(biāo)定的過程，之前的穩(wěn)態(tài)扭矩輸出和實現(xiàn)目標(biāo)的扭矩輸出有一個明顯的GAP，他用一個定點補償?shù)姆绞竭M(jìn)行優(yōu)化，優(yōu)化完以后自動把標(biāo)定再刷回去，之前和之后兩個情況進(jìn)行對比。標(biāo)定工程師基于虛擬平臺做的事情，和你在HiL上整車市場是一樣的，甚至測試用例、測試工具都不需要改變。

  這是另外一個例子，這個上面有6個虛擬控制器，這是針對于VCU百公里加速的標(biāo)定，首先模擬一個上電的過程，掛到D檔，把油門踏板上到50%的開度。之前的標(biāo)定百公里加速需要15秒，我們需要改，把標(biāo)定數(shù)據(jù)優(yōu)化以后可以縮短百公里加速的時間?；谶@個技術(shù)，我們有些主機(jī)廠基于這個技術(shù)可以實現(xiàn)預(yù)標(biāo)定的原因，完全可以把車上用的標(biāo)定流程或者環(huán)境直接移植到現(xiàn)在的虛擬平臺上，是無縫對接的。

  最后一個問題，這個虛擬測試或者虛擬標(biāo)定的概念非常好，但它有瓶頸，瓶頸在什么地方?如果我們想定性測一些功能沒有問題，但如果我想在一個虛擬環(huán)境下想定量做一些事情，他絕大多數(shù)很強烈地依賴于被控對象模型的精度。假如發(fā)動機(jī)模型精度本身并不是那么高的話，上面能做的事情其實有限，比如我可以實現(xiàn)50%的標(biāo)定成熟度，再往后要上實車要真正上Bench去做。

  這里有一個對比，博世的氣囊部門用了虛擬化進(jìn)行了測試，他有一些數(shù)據(jù)對比。首先是氣囊部門完整測試有7萬條測試用例，正常發(fā)布周期要三個月，是以季度來算的，為什么?基于HiL要測完7萬條用例需要4個多月，最大的瓶頸在這邊。當(dāng)我們把Full test用虛擬化的方式實現(xiàn)，大家可以看到95%測試用例可以用虛擬化實現(xiàn)，有5%是無法用虛擬化替代。但是基于這樣的比例，極大提高了整個測試的覆蓋度，以前要四個半月，現(xiàn)在七天就能測完。哪5%是無法用虛擬化替代的?就是這邊，主要是跟電磁干擾、雷雨環(huán)境、振動這些有關(guān)系，這個很難用純軟件的方式解決掉，但也可以，但代價和產(chǎn)出不成正比。

  所以說軟件在環(huán)測試不是為了替代硬件測試，一定是把更多的以前強依賴于硬件測試往前移，盡量縮短整個開發(fā)周期，這是我們的目的。而且針對于這個解決方案，以虛擬化測試為中心，向前向后延伸我們做了很多實踐，流水線可以大大縮短整個開發(fā)周期。

  這是我今天的分享，謝謝!