汽車軟件定義危機(jī)是如何釀成的？

引言：

又是一個(gè)思緒亂飛的夜晚，花了7個(gè)小時(shí)碼出了下面這些內(nèi)容，今天不講技術(shù)，主要談?wù)勚暗囊恍┙?jīng)驗(yàn)教訓(xùn)供大家參考。 大家經(jīng)常會(huì)聽到車廠要招幾千上萬(wàn)人的軟件團(tuán)隊(duì)，先不看具體的內(nèi)容，聽起來(lái)好像軟件就是一個(gè)勞動(dòng)密集型的產(chǎn)業(yè)，只要堆人就行了。殊不知，這只是在從一個(gè)坑跳進(jìn)另外一個(gè)更深的坑，新勢(shì)力們已經(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è)說(shuō)法，說(shuō)的就是軟件工程中所表現(xiàn)出的各種問(wèn)題，主要體現(xiàn)為以下幾點(diǎn)。

成本日益增長(zhǎng)

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

軟件質(zhì)量差

軟件維護(hù)困難

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

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

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

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

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

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

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

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

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

為什么......

2

軟件與 EE 的沖突

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

功能定義及分配

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

信號(hào)及接口定義

電源分配

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

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

3

功能域相互扯皮

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

4

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

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

車型平臺(tái)

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

縮減開發(fā)成本

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

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

5

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

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

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

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

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

芯片平臺(tái)不同

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

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

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

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

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

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

有人也許會(huì)問(wèn)，為啥要搞這么復(fù)雜，每個(gè)車型都采用不同代碼，不是更好管理嗎？傳統(tǒng)車廠包給Tier1做的時(shí)候，也的確是這樣，因?yàn)槟莻€(gè)時(shí)代，軟件和硬件一樣，都是一錘子的買賣，不需要后續(xù)還進(jìn)行什么升級(jí)。今天我們談?wù)撥浖x汽車的前提就是，要通過(guò)OTA不斷的為車升級(jí)新的功能。如果都采用不同的代碼版本，意味著軟件開發(fā)團(tuán)隊(duì)的規(guī)模是和車型的數(shù)量成正比的，越往后面迭代，已有的車型都會(huì)變成歷史的包袱。 很多時(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ǔ)的軟硬件平臺(tái)，通過(guò)良好的架構(gòu)設(shè)計(jì)，在標(biāo)準(zhǔn)的軟硬件基礎(chǔ)設(shè)施上，開發(fā)出完備的工具鏈，以支持車型功能的快速開發(fā)與快速迭代，是軟件定義汽車的基礎(chǔ)。

6

總結(jié)

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

在構(gòu)建新的數(shù)字化架構(gòu)的過(guò)程中，如果牽頭人不是像馬斯克這種有技術(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)，做出來(lái)的也是個(gè)漸進(jìn)產(chǎn)品。

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

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

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

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

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

責(zé)任編輯：haq