“功能架構(gòu)”在中國(guó)汽車開發(fā)圈子里，是一個(gè)很新潮、很前衛(wèi)、很有前途的崗位！這個(gè)開發(fā)理念來源于國(guó)外的大車企，并被國(guó)內(nèi)很多車企吸收模仿，是我們趕超國(guó)際先進(jìn)水平、實(shí)現(xiàn)汽車行業(yè)彎道超車的方式之一。但是，現(xiàn)實(shí)卻不是那么樂觀……

01、為什么要搞架構(gòu)？

汽車電子電氣系統(tǒng)越來越復(fù)雜，已經(jīng)不能用之前的那種零部件級(jí)別的思維來做設(shè)計(jì)了，必須得有一個(gè)角色，站在比零部件高一級(jí)的層次上，通盤統(tǒng)籌各種功能去實(shí)現(xiàn)。只有這樣才能防止零部件各自為政、只顧自己，從而確保整車的設(shè)計(jì)更加優(yōu)秀，質(zhì)量更有保障。

總而言之，“架構(gòu)”就是為“整車”服務(wù)的，是車企為了強(qiáng)化整車方面的工作職能而設(shè)立了崗位。

02、“架構(gòu)”一般都做什么？

這個(gè)聽起來牛逼哄哄的崗位，一般都做什么呢？

答案也很簡(jiǎn)單，架構(gòu)的工作對(duì)象就是功能，車上有哪些功能大類，這些功能大類又劃分為哪些功能小類，各個(gè)功能點(diǎn)跟哪些零部件相關(guān)，各個(gè)功能如何實(shí)現(xiàn)，各個(gè)零部件如何交互、如何協(xié)同，是需要架構(gòu)工程師來做的，目的還是更好地實(shí)現(xiàn)整車的各種功能。

其實(shí)，在“架構(gòu)工程師”這個(gè)崗位誕生之前，這些工作內(nèi)容也是有的，“功能方案”由各個(gè)ECU去“認(rèn)領(lǐng)”并主導(dǎo)實(shí)現(xiàn)。

現(xiàn)在有了“架構(gòu)工程師”去協(xié)調(diào)這個(gè)事情，但是“功能方案”基本上仍然是由各個(gè)零部件去“認(rèn)領(lǐng)”并承擔(dān)實(shí)現(xiàn)，因?yàn)?ldquo;架構(gòu)工程師”在國(guó)內(nèi)多數(shù)車企里，還不能作為推動(dòng)力量，去推動(dòng)方案的設(shè)計(jì)。

03、“架構(gòu)”工作為什么那么虛無縹緲？

因?yàn)槠髽I(yè)雖然配置了“架構(gòu)工程師”的崗位，但是開發(fā)流程上并沒有遵循“架構(gòu)”那一套，也就是說，文檔上的技術(shù)方案，和軟硬件開發(fā)測(cè)試，脫節(jié)了，走的不是同一條路。

這種情況下，架構(gòu)工程師輸出的東西，根本無法閉環(huán)，對(duì)車輛開發(fā)也無法真正起到作用，后續(xù)開發(fā)環(huán)節(jié)出現(xiàn)的問題，其他人一般也沒有動(dòng)力去追溯至“架構(gòu)”環(huán)節(jié)去尋找原因。

架構(gòu)輸出的一些文件材料，在當(dāng)下中國(guó)的汽車開發(fā)流程里，更多的是以“指導(dǎo)文件”的形式存在，而不是“約束文件”，這個(gè)很明顯就讓人覺得可有可無……

04、該怎么辦？

架構(gòu)工作一定要依附于公司級(jí)的規(guī)范開發(fā)流程，沒有流程，搞架構(gòu)就是做樣子的。

架構(gòu)工作要重點(diǎn)關(guān)注功能設(shè)計(jì)實(shí)現(xiàn)，功能要?jiǎng)澐智宄?，要多組織相關(guān)的評(píng)審討論，關(guān)起門來搞架構(gòu)工作，是不可能成功的。

架構(gòu)工作要和總線（還包括低壓線束，但是總線和架構(gòu)關(guān)系更密切）搞好關(guān)系，甚至毫不客氣地說，國(guó)內(nèi)很多企業(yè)，就是由做總線設(shè)計(jì)的人在做功能架構(gòu)工作，CAN信號(hào)的交互，天然具有架構(gòu)設(shè)計(jì)的屬性，適合從整車層面去統(tǒng)籌功能的設(shè)計(jì)及實(shí)現(xiàn)。

CAN交互的設(shè)計(jì)，要想做好，也是一個(gè)挺麻煩的事情，國(guó)內(nèi)的多數(shù)車企，都做得不太好，并且一般而言，主要會(huì)有兩種形態(tài)：如果總線工程師比較強(qiáng)勢(shì)的話，信號(hào)就由總線工程師發(fā)布，各個(gè)ECU挨個(gè)來到總線工程師的座位上，由總線工程師對(duì)其進(jìn)行一對(duì)一討論指導(dǎo)，讓ECU工程師看excel（excel文件肯定是不能發(fā)的，機(jī)密，哈哈），說自己要接收哪些信號(hào)、想發(fā)哪些信號(hào)、有什么意見，之類的，后續(xù)總線工程師發(fā)布一份打印掃描pdf協(xié)議，就算完事了。如果ECU工程師比較強(qiáng)勢(shì)的話，那么協(xié)議一般都在ECU工程師手里，總線工程師不管信號(hào)交互，由各個(gè)ECU自己去對(duì)接討論，之后總線工程師搜集上來各個(gè)ECU手里的協(xié)議之后，以整車的名義發(fā)布，再做做測(cè)試，就算完成工作了。

很顯然，上面兩種方式都不好，對(duì)于前一種，會(huì)極大限制ECU工程師的的創(chuàng)造力，并且總線工程師累得要死；對(duì)于后一種，那基本上就是放任自流、不管不問了。

我們的“總線架構(gòu)協(xié)同平臺(tái)”，就能完美地解決這個(gè)問題。它可以使信號(hào)的交互及討論，下放到各個(gè)ECU之間，由ECU工程師在工具內(nèi)部自主協(xié)商設(shè)計(jì)，并同時(shí)更加強(qiáng)化總線工程師在其中的核心作用，還可以方便地為每個(gè)ECU生成不同的協(xié)議矩陣以及dbc。