汽車軟件開發是很復雜的系統工程。

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

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

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

1

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

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

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

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

ECU已經在汽車行業存在了近60年，但直到現在，ECU仍然是談論汽車軟件時的主要對象。

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

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

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

1.2 車載軟件的內涵

除了形式，再看功能內涵。

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

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

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

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

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

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

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

1.3 非車載軟件

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

包括云平臺（如數據埋點后臺、電池狀態遠程監控、OTA運營平臺）、工具鏈軟件、生產用下線電檢軟件（EOL，End Of Line）以及手機車聯app和車機上的第三方app。

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

當然呢，現在這些非車載軟件還沒有形成穩定及具規模的生態，所以本文后面部分仍然主要基于車載軟件展開。

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

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

2

從代碼到整車的5層集成

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

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

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

將軟件單元集成到一起

將軟件集成到硬件上

將硬件集成到機械殼體上

將ECU 集成到子系統中

將子系統集成到整車上

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

3

聯調與整車級評價

汽車軟件開發是個各模塊或功能域協作的過程。

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

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

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

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

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

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

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

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

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

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

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

總之，我們已經看到了這樣的趨勢，聯調正伴隨著架構的集成化逐漸演變為對整車整體的評價。

4

開發驗證受制于實車環境

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

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

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

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

5

要考慮生產

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

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

原因有二：

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

現有的標準化生產方式仍然足夠安全可靠。

6

ASPICE

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

反復思考、反復調研，我認為ASPICE還會一定程度地回歸，會隨著行業生態的恢復和產品方案的成熟逐漸體現出其必要的規范性意義。

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

7

功能安全

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

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

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

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

8

全文小結

汽車軟件是有些行業與產品特殊性的，本文總結了7個相互有關聯的特點：

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

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

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

在仿真足夠真實之前，出于成本的考慮，開發始終會受制于實車環境。

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

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

9

寫在最后

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

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

編輯：黃飛

?