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

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

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

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

1

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

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

1.1 帶物理盒子的車載軟件

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

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

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

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

對(duì)于汽車軟件而言，這個(gè)特點(diǎn)就如同愛因斯坦的鼻子一樣突出。

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

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

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

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

進(jìn)一步地，車載軟件可以劃分為四類：

第一類：與整車高度耦合或安全等級(jí)較高的模塊，如發(fā)動(dòng)機(jī)控制、電機(jī)控制、剎車控制、電子助力轉(zhuǎn)向控制、車身穩(wěn)定控制系統(tǒng)ESP、混動(dòng)系統(tǒng)控制、安全氣囊控制、電池?zé)峁芾淼取?/p>

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

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

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

1.3 非車載軟件

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

包括云平臺(tái)（如數(shù)據(jù)埋點(diǎn)后臺(tái)、電池狀態(tài)遠(yuǎn)程監(jiān)控、OTA運(yùn)營(yíng)平臺(tái)）、工具鏈軟件（詳見《拆解一下汽車電子軟件開發(fā)工具鏈》）、生產(chǎn)用下線電檢軟件（EOL，End Of Line）以及手機(jī)車聯(lián)app和車機(jī)上的第三方app。

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

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

但是，V2X總是趨勢(shì)，值得我們不斷加強(qiáng)關(guān)注。

以上軟件種類的劃分會(huì)直接影響到后面6個(gè)特點(diǎn)的分布與側(cè)重，閱讀時(shí)可做關(guān)注。

2

從代碼到整車的5層集成

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

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

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

將軟件單元集成到一起

將軟件集成到硬件上

將硬件集成到機(jī)械殼體上

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

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

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

3

聯(lián)調(diào)與整車級(jí)評(píng)價(jià)

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

一直以來，大家習(xí)慣于在各自的電腦上、臺(tái)架上完成開發(fā)與驗(yàn)證，然后在集成點(diǎn)處進(jìn)行確認(rèn)。

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

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

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

整車碰撞試驗(yàn)會(huì)花費(fèi)高額的成本，一旦試驗(yàn)失效，時(shí)間和金錢都是巨大浪費(fèi)，前期的聯(lián)調(diào)非常必要。

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

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

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

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

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

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

總之，我們已經(jīng)看到了這樣的趨勢(shì)，聯(lián)調(diào)正伴隨著架構(gòu)的集成化逐漸演變?yōu)閷?duì)整車整體的評(píng)價(jià)。

4

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

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

車很貴，工程車尤其貴，退而求其次，大家用模擬信號(hào)與負(fù)載、用簡(jiǎn)易臺(tái)架加ECU、用白車身、用拼湊的實(shí)車......

而求其次自然會(huì)求來軟件版本不對(duì)齊、驗(yàn)證負(fù)載不充分、暴露問題不及時(shí)等等各類次的問題。

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

5

要考慮生產(chǎn)

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

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

原因有二：

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

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

6

ASPICE

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

。

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

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

有關(guān)ASPICE的解讀，詳見以下三篇文章：

《汽車軟件過程“閱卷準(zhǔn)則”之ASPICE 3.1品讀（上）》

《汽車軟件過程“作文提綱或模板“之ASPICE 3.1品讀（中）》

《汽車軟件過程“滿分作文“之ASPICE 3.1品讀（下）》

7

功能安全

功能安全正在像ASPICE一樣，面臨一個(gè)相對(duì)尷尬的境地。

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

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

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

8

全文小結(jié)

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

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

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

每個(gè)集成點(diǎn)都是一個(gè)接口，接口之間是需要聯(lián)調(diào)的，尤其對(duì)于跨模塊、多接口的復(fù)雜系統(tǒng)。而隨著架構(gòu)的集中化，這種趨向整車級(jí)的評(píng)價(jià)會(huì)是越來越突出的趨勢(shì)。

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

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

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

9

寫在最后

汽車軟件的特點(diǎn)與兩個(gè)老生常談的概念密切相關(guān)：軟件架構(gòu)的軟硬耦合和整車電子電氣架構(gòu)的分布式。

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

完

       原文標(biāo)題 : 汽車軟件開發(fā)模式的7個(gè)特點(diǎn)