引言：

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

1

軟件危機

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

成本日益增長

開發(fā)進度難以控制

軟件質(zhì)量差

軟件維護困難

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

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

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

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

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

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

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

為什么規(guī)劃了個新架構(gòu)，到最后只能做點小優(yōu)化？

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

為什么......

2

軟件與 EE 的沖突

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

功能定義及分配

網(wǎng)絡拓撲及信號分析

信號及接口定義

電源分配

線束設計

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

3

功能域相互扯皮

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

4

車型項目與數(shù)字架構(gòu)平臺化

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

車型平臺

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

縮減開發(fā)成本

縮減產(chǎn)品開發(fā)周期

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

5

傳統(tǒng)車廠的歷史包袱

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

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

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

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

芯片平臺不同

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

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

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

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

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

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

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

6

總結(jié)

寫了比較多的內(nèi)容，思路也比較發(fā)散，總結(jié)下來有以下幾點建議：

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

構(gòu)建的架構(gòu)團隊必須包含定義計算通信架構(gòu)的職責，靠 EE 和軟件架構(gòu)各自為戰(zhàn)，做出來的也是個漸進產(chǎn)品。

各功能域的職責在新的技術(shù)架構(gòu)下是會發(fā)生變化的，不要試圖在原有的組織架構(gòu)下搞出新的技術(shù)架構(gòu)。

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

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

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

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

責任編輯：haq