汽車軟件開發(fā)是很復雜的系統(tǒng)工程。

這種復雜經(jīng)常讓來自不同知識背景的我們，在觀點交鋒時出現(xiàn)雞同鴨講的滑稽。

解決復雜性和對齊討論基準的一個方式是粗暴地具象化，比如，卡通畫人像，寥寥幾筆勾勒最關鍵的特征，很不全面，但足夠典型。

本文期望，通過7個典型特點的抽取，來勾勒出汽車軟件開發(fā)模式的特殊性和變遷性。

1

車載與非車載軟件的分類及差異

既然汽車軟件是非常復雜的，種類繁多自是預料之內(nèi)，我們先來解決這個最基本的問題。

1.1?帶物理盒子的車載軟件

最正宗的汽車軟件當屬ECU里的軟件，也就是車載軟件。直觀來看，就是固定在車上，并通過線束與電氣系統(tǒng)或其他ECU連接起來的物理盒子。

ECU已經(jīng)在汽車行業(yè)存在了近60年，但直到現(xiàn)在，ECU仍然是談論汽車軟件時的主要對象。

只不過，隨著汽車電子電氣架構的演變，ECU的功能越來越集中化，也即現(xiàn)在炒得熱火朝天的域控或中央計算。

無論如何，形式上來看，ECU或DCU都是嵌入在物理盒子里的車載軟件產(chǎn)品。

對于汽車軟件而言，這個特點就如同愛因斯坦的鼻子一樣突出。

1.2 車載軟件的內(nèi)涵

除了形式，再看功能內(nèi)涵。

首先，基于這兩年廣泛流傳的博世五域劃分，可以將車上的電子軟件功能進行分區(qū)，即動力域（車輛運動）、底盤域（安全）、車身域（車身電子）、座艙域（娛樂信息）和自動駕駛域（駕駛輔助）。

這五域劃分可以給我們一個大框架的參考，但對于我們區(qū)分開發(fā)模式來說，并不夠友好。

進一步地，車載軟件可以劃分為四類：

第一類：與整車高度耦合或安全等級較高的模塊，如發(fā)動機控制、電機控制、剎車控制、電子助力轉向控制、車身穩(wěn)定控制系統(tǒng)ESP、混動系統(tǒng)控制、安全氣囊控制、電池熱管理等。

第二類：功能獨立且安全等級較低的車身控制模塊，如網(wǎng)關、照明控制、雨刮控制、車門車窗控制、無鑰匙啟動、天窗控制、座椅記憶控制、后視鏡控制、功放控制等。

第三類：智能駕駛，ADAS、AD及附屬的雷達或攝像頭傳感器等。

第四類：智能座艙或說車機，主要是以各類大屏為承載的軟件。

1.3 非車載軟件

除了車載軟件，還有一部分是非車載類軟件，他們也廣泛地存在于汽車行業(yè)的各個領域。

包括云平臺（如數(shù)據(jù)埋點后臺、電池狀態(tài)遠程監(jiān)控、OTA運營平臺）、工具鏈軟件、生產(chǎn)用下線電檢軟件（EOL，End Of Line）以及手機車聯(lián)app和車機上的第三方app。

其中，云平臺與app和互聯(lián)網(wǎng)軟件比較接近，車載軟件和互聯(lián)網(wǎng)軟件則是完全不同類別的東西，談論主體的不一致經(jīng)常是兩個行業(yè)背景的人進行雞同鴨講的原因之一。

當然呢，現(xiàn)在這些非車載軟件還沒有形成穩(wěn)定及具規(guī)模的生態(tài)，所以本文后面部分仍然主要基于車載軟件展開。

但是，V2X總是趨勢，值得我們不斷加強關注。

以上軟件種類的劃分會直接影響到后面6個特點的分布與側重，閱讀時可做關注。

2

從代碼到整車的5層集成

汽車軟件種類繁多、模塊眾多，而且需要裝在整車上跨模塊、跨域體現(xiàn)功能。

所以，只要電子電氣架構的集中化沒有走到中央計算和云計算，只要供應鏈各方的軟硬件自主權沒有被收歸一統(tǒng)，多層集成就不可避免。

按照當下的架構發(fā)展階段，我們可以把汽車軟件的集成分為5個層次：

將軟件單元集成到一起

將軟件集成到硬件上

將硬件集成到機械殼體上

將ECU 集成到子系統(tǒng)中

將子系統(tǒng)集成到整車上

有關這部分內(nèi)容，詳見《汽車軟件集成的5個層次》。

3

聯(lián)調與整車級評價

汽車軟件開發(fā)是個各模塊或功能域協(xié)作的過程。

一直以來，大家習慣于在各自的電腦上、臺架上完成開發(fā)與驗證，然后在集成點處進行確認。

“各人自掃門前雪”的協(xié)作慣例能讓分工清晰，也會讓幾乎不可避免的問題延后暴露。

因此，部分與整車環(huán)境依賴關系比較緊密的模塊（第一類）會提前進行聯(lián)調。

很典型的是安全氣囊控制器。

整車碰撞試驗會花費高額的成本，一旦試驗失效，時間和金錢都是巨大浪費，前期的聯(lián)調非常必要。

比如，安裝方向、傳感器位置、線束連接、電阻范圍、DTC狀態(tài)、軟件版本及對手件響應等的聯(lián)調確認。

當然呢，安全氣囊太成熟、太傳統(tǒng)、軟硬耦合程度太深了。

與其他模塊或整車耦合程度沒那么高的模塊（第二類），聯(lián)調必要性就會減弱。比如，簡單的天窗控制模塊和方向盤加熱模塊，可能臺架上連接一個電機和加熱墊就綽綽有余。

智駕和座艙逐漸脫離了傳統(tǒng)汽車軟件開發(fā)模式，而二者之間也有些不同。

智駕的開發(fā)驗證可以依賴一部分仿真模擬，但終歸需要整車的調試標定，尤其需要運動控制部分的功能完善。

智艙集成了大量的人機交互內(nèi)容，無論是控制指令的發(fā)出，還是反饋信息的投屏，大屏正在變成人與車的I/O口，這讓座艙的開發(fā)頗為困難，所謂聯(lián)調或者協(xié)同驗證的意義和必要性也十分顯著。

總之，我們已經(jīng)看到了這樣的趨勢，聯(lián)調正伴隨著架構的集成化逐漸演變?yōu)閷φ囌w的評價。

4

開發(fā)驗證受制于實車環(huán)境

仿真也是個非常古老的東西，但它的發(fā)展看起來始終有些緩慢，汽車開發(fā)的各層級開發(fā)驗證，都難以離開真實的物理環(huán)境，也就是車。

車很貴，工程車尤其貴，退而求其次，大家用模擬信號與負載、用簡易臺架加ECU、用白車身、用拼湊的實車......

而求其次自然會求來軟件版本不對齊、驗證負載不充分、暴露問題不及時等等各類次的問題。

受制于樣件和實車的環(huán)境是汽車開發(fā)的特點，特別地，在架構融合的過渡階段，更耦合的功能、更多的交互，會讓現(xiàn)在這種單一仿真環(huán)境凸顯出更大的問題。

5

要考慮生產(chǎn)

一切的軟件都需要進入整車，從整車層面解決客戶需求，而進入的第一步和主要步驟還是通過生產(chǎn)裝配，特別是對于第一類軟件。

所以呢，我們做汽車軟件要關注制造、關注生產(chǎn)。

原因有二：

OTA技術、流程和監(jiān)管還不足夠成熟，我們還不能自由OTA。

現(xiàn)有的標準化生產(chǎn)方式仍然足夠安全可靠。

6

ASPICE

ASPICE也曾被人捧上神壇，最近一兩年，大約是因為全行業(yè)灰頭土臉，精致昂貴的ASPICE逐漸被人報以微笑。

反復思考、反復調研，我認為ASPICE還會一定程度地回歸，會隨著行業(yè)生態(tài)的恢復和產(chǎn)品方案的成熟逐漸體現(xiàn)出其必要的規(guī)范性意義。

但是還有一點要說明，ASPICE的分層意義可能會隨著架構集中的進一步發(fā)展而減弱，比如，軟硬解耦后，軟件開發(fā)中一直關注的系統(tǒng)（軟+硬+...）就沒太大存在必要了。

7

功能安全

功能安全正在像ASPICE一樣，面臨一個相對尷尬的境地。

原本呢，這部分算是傳統(tǒng)汽車暨三大件被繞過后還剩余的技術門檻，但是，新勢力進來后，先是一波高薪，兩三年就培養(yǎng)出一大批功能安全工程師，人才多少是有點飽和了。

年初，特斯拉又掀起一波價格戰(zhàn)，多米諾骨牌，各大車企還陸續(xù)開啟裁員。一陣寒意后，功能安全？飯都吃不飽了，自己都不安全了，還管功能安全不安全。

很顯然，特別是對于第一類（與整車高度耦合或安全等級較高的模塊）和第三類（智能駕駛）軟件，功能安全非常重要，只是這個魔幻的階段暫時讓它無所適從。

8

全文小結

汽車軟件是有些行業(yè)與產(chǎn)品特殊性的，本文總結了7個相互有關聯(lián)的特點：

討論總是需要在同一概念基礎上的，所以首先區(qū)分了汽車軟件的分類，最典型的當屬車載軟件，我們按照開發(fā)模式的差異性分成了4類，而行業(yè)的方向正在向非車載軟件延展。

對于分布式架構和協(xié)同供應鏈下的車載軟件，多層集成是其非常直接的特點，大體來看，從代碼到整車可分為5層。

每個集成點都是一個接口，接口之間是需要聯(lián)調的，尤其對于跨模塊、多接口的復雜系統(tǒng)。而隨著架構的集中化，這種趨向整車級的評價會是越來越突出的趨勢。

在仿真足夠真實之前，出于成本的考慮，開發(fā)始終會受制于實車環(huán)境。

同樣地，在OTA足夠可靠之前，汽車軟件不得不考慮其對生產(chǎn)的影響和生產(chǎn)對其的影響。

ASPICE和功能安全是不同性質的要求，但都是期望將行業(yè)的躁動按住一點，將開發(fā)的混亂規(guī)范一點，將安全的地位拔高一點，但是現(xiàn)在的環(huán)境暫時讓二者難以生存。

9

寫在最后

汽車軟件的特點與兩個老生常談的概念密切相關：軟件架構的軟硬耦合和整車電子電氣架構的分布式。

而伴隨著軟硬解耦和架構集中化，汽車軟件的特異性會逐漸地演變，乃至消亡。

編輯：黃飛

?