引言：

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

1

軟件危機(jī)

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

成本日益增長

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

軟件質(zhì)量差

軟件維護(hù)困難

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

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

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

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

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

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

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

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

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

為什么......

2

軟件與 EE 的沖突

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

功能定義及分配

網(wǎng)絡(luò)拓?fù)浼?a target="_blank">信號分析

信號及接口定義

電源分配

線束設(shè)計(jì)

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

3

功能域相互扯皮

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

4

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

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

車型平臺

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

縮減開發(fā)成本

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

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

5

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

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

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

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

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

芯片平臺不同

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

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

共用同一分支，一次編譯，生成一個(gè)軟件包，能夠在所有車型上運(yùn)行（就像app能夠在所有Android手機(jī)上運(yùn)行）。

共用同一分支，多次編譯，生成多個(gè)軟件包，能夠在不用車型上運(yùn)行。

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

采用不同分支，多次編譯，生成多個(gè)軟件包，能夠在不用車型上運(yùn)行。

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

6

總結(jié)

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

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

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

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

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

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

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

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

責(zé)任編輯：haq