引言：

又是一個思緒亂飛的夜晚，花了7個小時碼出了下面這些內容，今天不講技術，主要談談之前的一些經驗教訓供大家參考。 大家經常會聽到車廠要招幾千上萬人的軟件團隊，先不看具體的內容，聽起來好像軟件就是一個勞動密集型的產業，只要堆人就行了。殊不知，這只是在從一個坑跳進另外一個更深的坑，新勢力們已經構建起了部分的軟件能力，傳統的車廠正在努力追趕，這個行業一片欣欣向榮的景象，但先行者的很多的經驗教訓是值得大家好好反思的。前段時間，大家都在談傳統車廠的軟件危機，這些都是不具備能力所產生的危機，等到大家都有軟件團隊了，更多的危機還在醞釀當中，汽車技術的復雜性，進一步讓這些危機更加明顯。

1

軟件危機

軟件危機是軟件工程領域的一個說法，說的就是軟件工程中所表現出的各種問題，主要體現為以下幾點。

成本日益增長

開發進度難以控制

軟件質量差

軟件維護困難

看起來比較抽象，我舉幾個具體的例子，大家自檢一下：

為什么別人家的軟件一個月可以更新好幾次，而自家半年過去了，非常努力的敏捷開發而一個版本也發不出來？

為什么每個功能域都覺得自己沒問題了，集成到一起就問題層出不窮？

為什么修好了一個 bug，又冒出來幾個其他 bug？

為什么開發告訴我這個功能技術方案太復雜，這期來不及，以后再做，然而以后還是來不及？

為什么一些功能邏輯只有到了實車上，才發現原先的設計邏輯有問題？

為什么第一款車已經做過一遍了，這款新車就適配一下，還需要這么長時間？

為什么規劃了個新架構，到最后只能做點小優化？

為什么開發告訴我，自己要維護十幾套代碼基線，功能不都差不多嗎？

為什么......

2

軟件與 EE 的沖突

無法掌控電子架構，軟件架構就是空中樓閣，軟件部門經常會和 EE 打交道，特別是在新的軟件化浪潮下，雙方經常會起沖突。其實靜下心來分析，這種沖突是雙方認知不同造成的必然結果。 傳統的EE一般來自于電氣、電氣自動化、汽車等相關專業，主要有以下幾個重要職責：

功能定義及分配

網絡拓撲及信號分析

信號及接口定義

電源分配

線束設計

在傳統的離散架構下，其工作以信號為基礎，圍繞網絡與零部件展開，車上的很多功能往往需要多個 ECU 相互配合，定義功能邏輯、信號交互、管理 ECU 零部件開發是日常的工作重心。 在傳統的架構下，其工作模式其實是至下而上的，所有的功能性 ECU 都是產業鏈上有的，組合起來形成各種產品功能。 而在新架構下，工作模式需要至上而下，底層 ECU 提供的都是原子功能，功能邏輯都是在中央計算單元中實現。所以原本的功能定義和劃分職責，現在變成了功能拆解、原子服務定義。

3

功能域相互扯皮

在傳統的架構下，如果組建開發團隊，很自然的就會按照零部件或者功能域去劃分，比如智駕、座艙、網關、BCM、VCU 等，一旦這種組織架構形成，想要推行新的技術架構，就會產生非常大的阻力。 組織架構往往是由分工邊界決定的，一旦組織架構確定，就會形成一個利益團體，有句話叫撼動利益，比撼動靈魂還難。 舉個例子，在中央計算架構下，中央網關退化為多個區域網關，之前中央網關開發的人去干嘛？把 BCM 和 VCU 的業務功能放到中央計算單元的車控單元之后，這些業務由誰來開發？新的架構要取消這兩個 ECU，原來的開發部門會同意？ 從這個維度來看，你就知道為什么在傳統車廠內部搞這種底層的數字化架構基本沒戲，這不是一個單純的技術問題。另外，如果出去單獨成立新軟件公司，如果不能決定 EE 架構的，基本也沒戲！

4

車型項目與數字架構平臺化

所有的公司剛開始做的時候，毫無疑問最關注還是產品功能，不管怎樣先把產品弄出來再說，所有的資源都是圍繞著車型的項目在推動。 等到一個車型項目做完，下一個車型項目又開始了，一旦這個過程啟動，任何有點技術風險嘗試都會被扼殺在搖籃當中，所以永遠只能做漸進式的改變，這就導致，會衍生出很多個軟件版本。以后每增加一款車型，就要多維護一條產品線。 在靠硬件差異化拼天下的時代，傳統的巨頭都是車型平臺化設計的高手。一個車型平臺，需要投入上百億的資金進行研發，一家大型的車企，可能同時擁有幾十款車型，如果每款車的架構都是不一樣的，全部都重新開發，這個成本誰也無法承受。

車型平臺

我想在他們內部也不會有人質疑，為什么要花這么大的成本去開發這樣一個車型平臺，因為經過了時間的檢驗，采用平臺化設計為他們帶來了很多好處：

縮減開發成本

縮減產品開發周期

為不同車型的硬件差異化提供了基礎

5

傳統車廠的歷史包袱

在傳統的汽車上，一個零部件隨著整車出廠之后，軟件一般不會再進行升級，但在OTA的大背景下，車的生命周期被延長，軟件在一定的周期內會進行不斷的迭代，如果沒有平臺化的軟件作為支持，產品功能的迭代會產生巨大的工作量，而且迭代速度會非常緩慢。 按照傳統車廠的節奏，會頻繁的推出新的車型，如果沒有平臺化的軟件作為支撐，光是車型適配的工作就會產生大量的開發成本，更不要談后續的OTA升級，以后每增加一款車型，就要多維護一條產品線，到了最后，可能不得不去放棄一些銷量較低的車型的軟件迭代工作，這對于購買那些車的用戶來講公平嗎。 在傳統的印象中，軟件為什么毛利潤那么高？很重要的一個原因是軟件的可復制性，在復制部署的過程中，其邊際成本趨近于零。而軟件可復制部署的前提是軟硬件的平臺化。要在一輛未經良好設計的汽車上去迭代軟件，后期本身就會演變成一個災難。 國內車聯網的先行者第一款車發布的時候整個人員規模也就300人左右，后續隨著體系內的車型不斷變多，導致的適配工作呈現倍數放大，人員規模很快膨脹到近千人，主要的資源力量都被吸引到了車型適配當中去，無形之中也影響到了主線產品的開發節奏，即使是把這部分工作交給外包去做，依然也要付出巨大的人工成本。 為什么會產生如此大的適配工作量呢？可以先給大家介紹一下，軟件適配車型具體的工作范圍。 車載軟件系統，開發出來之后，只要芯片平臺不變，操作系統不變，按道理來講是不需要什么適配工作的。但是但由于傳統車廠的一些歷史遺留問題，以及產品設計理念的問題，會產生以下三類問題。

車型平臺、車型信號不同，導致信號的適配
新的車型，如果是基于同一個車型平臺開發出來，其一般只是信號的值，或者信號的個數發生了變化，但是如果兩款車基于完全不同的車型開發出來，基本上信號共用的部分就很少，同樣是控制某個功能，信號的名稱可能完全不一樣，并且一個車型上發一個信號能完成的功能，到了另外一個車型上，可能需要多個信號組合才能完成。這會導致，像網關、TBOX、域控MCU、域控MPU的車輛信號處理的中間件、HMI控制邏輯等模塊需要進行軟件變更。此類功能，是車載軟件開發中聯調工作最大的部分，并且還必須是在早期就具備的功能，比如PPV階段，就要求此類功能ready，而其他大部分功能都可以放到SOP階段，和其他零部件交互的功能，都是聯調中最麻煩的，特別是在早期階段，工程師需要跑各種現場分析解決問題。

屏幕適配
咱們國內的整車的產品人員對智能化的理解是不是太膚淺了，喜歡定義各種規格的屏幕尺寸，多搞幾塊屏幕，沒事兒還橫屏改豎屏，豎屏改橫屏，似乎誰的屏幕多、屏幕大就更智能似的。殊不知，多一塊屏幕或者是改變了屏幕的橫豎關系，就要重新定義交互方式，而改變屏幕分辨率，也會導致UI布局上的調整， 這些改變會導致軟件上巨大的工作量。

車型特殊硬件，增加新的軟件模塊
傳統車廠的車型產品中，喜歡弄一些差異化的硬件，而這些功能往往需要增加新的軟件模塊才能運行，此類功能倒是比較好處理，因為新增的模塊總比改已有的模塊要方便，新增只影響一個車型，而改已有的模塊會影響其他所有車型。

芯片平臺不同

以上的這些因素都會導致軟件的變更，而軟件的變更也分為幾個層次，軟件工程中一般會使用git等工具來管理代碼，在軟件開發過程中，幾十上百個軟件工程師會共同完成同一個項目，這里面很重要的概念就是“主線”與“分支”，如果多個車型項目的代碼能夠復用同一“主線”，意味者他們的代碼是同一套，工作量會小很多，但是如果某個車型的軟件變更，導致他們無法再用同一套，在軟件上就會產生一個新的分支，就像大家平時多個人要共同編輯某個文檔，一旦大家的修改產生了分叉，就必須同時維護多個版本。

從軟件工程的角度來講，軟件開發的一般分為，需求分析、領域建模、架構/概要/詳細設計、開發/單元測試、綜合測試、編譯集成、發布等幾個階段。每增加一個分支，就會導致從開發開始所有流程工作量的增加。 從軟件的角度來看，采用一些技術上的設計，可以復用已有的模塊分為以下幾個層次：

共用同一分支，一次編譯，生成一個軟件包，能夠在所有車型上運行（就像app能夠在所有Android手機上運行）。

共用同一分支，多次編譯，生成多個軟件包，能夠在不用車型上運行。

部分模塊共用同一分支，多次編譯，生成多個軟件包，能夠在不用車型上運行。

采用不同分支，多次編譯，生成多個軟件包，能夠在不用車型上運行。

有人也許會問，為啥要搞這么復雜，每個車型都采用不同代碼，不是更好管理嗎？傳統車廠包給Tier1做的時候，也的確是這樣，因為那個時代，軟件和硬件一樣，都是一錘子的買賣，不需要后續還進行什么升級。今天我們談論軟件定義汽車的前提就是，要通過OTA不斷的為車升級新的功能。如果都采用不同的代碼版本，意味著軟件開發團隊的規模是和車型的數量成正比的，越往后面迭代，已有的車型都會變成歷史的包袱。 很多時候，大家在開始做項目的時候，最關注的還是產品功能的實現度，很少關心軟件的架構設計和拓展性，積累到一定的階段，又不敢輕易的進行重構，而后產生惡性循環，導致開發資源的大量浪費，功能大家都能做，但工程能力的高低往往體現在這些看不見的地方。 構建一套基礎的軟硬件平臺，通過良好的架構設計，在標準的軟硬件基礎設施上，開發出完備的工具鏈，以支持車型功能的快速開發與快速迭代，是軟件定義汽車的基礎。

6

總結

寫了比較多的內容，思路也比較發散，總結下來有以下幾點建議：

在構建新的數字化架構的過程中，如果牽頭人不是像馬斯克這種有技術決斷力的領導，最好就構建一個強有力的架構團隊，從技術層面總領全局，否則靠功能域自己相互協調，只能做點優化，改變不了基礎架構。

構建的架構團隊必須包含定義計算通信架構的職責，靠 EE 和軟件架構各自為戰，做出來的也是個漸進產品。

各功能域的職責在新的技術架構下是會發生變化的，不要試圖在原有的組織架構下搞出新的技術架構。

產品線開發和平臺開發要分開，否則就會面臨邊開飛機邊換引擎的慘痛局面，開發資源永遠被現有項目所圍困。

新平臺的開發是一個 EE+硬件+軟件的綜合體，如果總想拿正式車型項目去推動，會讓項目面臨很多不可控風險。新平臺的正向研發過程中面臨很多技術決斷，建議成立一只獨立團隊開展前期研究工作。在一定階段導入正式量產項目。本質是把 R&D 中的 Research 與 Development 分開，并且將 R 前置。

原文標題：軟件定義汽車 (第九集) : 危機是如何釀成的

文章出處：【微信公眾號：佐思汽車研究】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq