?[[433272]]?

當(dāng)前的國家形勢決定，我們的經(jīng)濟(jì)正處于“雙循環(huán)”中的內(nèi)循環(huán)主導(dǎo)外循環(huán)，主推自主創(chuàng)新，自身腰桿子要硬。因此，對(duì)于汽車行業(yè)，也不例外，我們也要加快自主創(chuàng)新，建立自己能力的步伐，建立具備自主權(quán)的OEM和技術(shù)先進(jìn)性的Tier1，但如何建立這種能力，就需要各位同仁共同努力。

01. xxx定義xxx

不管從事何種行業(yè)，都有自成體系的一套規(guī)則，在汽車行業(yè)也一樣，所有的技術(shù)落地都要遵循循序漸進(jìn)的原則，心急吃不了熱豆腐，因此首先我們來理清楚新架構(gòu)落地的層層關(guān)系：

??

圖2. xxx 定義 xxx

• 市場定義需求

首先，從整車電子電氣架構(gòu)流程來說，整車設(shè)計(jì)全生命周期的的起點(diǎn)必須是市場行為，OEM需要進(jìn)行大量的市場調(diào)研，結(jié)合自身情況，定位對(duì)應(yīng)的用戶群體，之后進(jìn)行大量的同類型車輛市場對(duì)標(biāo)、技術(shù)對(duì)標(biāo)，從而推導(dǎo)出產(chǎn)品的特性，分析自己產(chǎn)品的優(yōu)勢，在這其中，務(wù)必要分析出別人沒有我有的亮點(diǎn)，而這些亮點(diǎn)也必須是可以讓客戶覺得物有所值。

因此，在技術(shù)快速發(fā)展迭代的這個(gè)時(shí)代，大家更不能忽視市場分析，需求提煉，只有分析清楚市場，才能根據(jù)梳理出產(chǎn)品需求，同時(shí)還需要結(jié)合自己車型情況，找到適合自己公司的市場定位以及對(duì)應(yīng)的需求，再來決策是否需要引入一些新技術(shù)。

• 需求定義架構(gòu)

有了明確的需求，架構(gòu)團(tuán)隊(duì)就可以根據(jù)特定需求進(jìn)行架構(gòu)設(shè)計(jì)，有的放矢的分析每條需求，從中提取架構(gòu)特征，根據(jù)所要達(dá)到的架構(gòu)特征，找到最適合的架構(gòu)拓?fù)?，在?duì)應(yīng)的架構(gòu)拓?fù)渲屑?xì)化相關(guān)的技術(shù)方案，找到需求的最優(yōu)方案決策，從而輸出對(duì)應(yīng)的設(shè)計(jì)方案，規(guī)范，和設(shè)計(jì)指導(dǎo)給到軟硬件開發(fā)團(tuán)隊(duì)。

• 架構(gòu)定義功能

架構(gòu)在輸出對(duì)應(yīng)的設(shè)計(jì)指導(dǎo)時(shí)，必須基于識(shí)別的架構(gòu)特征和拓?fù)洌瑏砑s束和限制整車功能，并基于相關(guān)約束設(shè)計(jì)整車功能以及功能實(shí)現(xiàn)方案，輸出面向不同對(duì)象的功能描述文檔，有了這些文檔輸出，整車功能基本定型，接下來才有可能進(jìn)行開發(fā)實(shí)現(xiàn)。

• 功能定義軟件

架構(gòu)設(shè)計(jì)的功能，最終需要借助軟硬件來實(shí)現(xiàn)，尤其是軟件，不同的功能策略，必須對(duì)應(yīng)不同的軟件系統(tǒng)和架構(gòu)，從功能角度就需要對(duì)軟件進(jìn)行模塊化設(shè)計(jì)，以及定義模塊化之間的交互接口和行為。

有了功能邏輯之間的交互，軟硬件開發(fā)團(tuán)隊(duì)，就可以開始進(jìn)行對(duì)應(yīng)的功能開發(fā)和實(shí)現(xiàn)，因此如果功能邏輯設(shè)計(jì)不清晰，就會(huì)導(dǎo)致軟件代碼邏輯混亂。只有功能清晰，軟件才能基于功能定義的基礎(chǔ)上，設(shè)計(jì)好功能實(shí)現(xiàn)細(xì)節(jié)。

• 軟件定義汽車

“軟件定義汽車”的含義我懂，但如果像之前行業(yè)內(nèi)特意把這個(gè)概念單獨(dú)拎出來，著重強(qiáng)調(diào)，我就一直有個(gè)疑問，軟件是如何來定義汽車的，尤其是在這個(gè)詞沒出現(xiàn)之前，難道軟件在汽車?yán)锞筒淮嬖凇?/p>

當(dāng)然有的人會(huì)說，好的軟件可以優(yōu)化汽車的方方面面，首先這句話是完全正確的，沒有任何問題，但是靠什么設(shè)計(jì)好軟件呢，SOA？評(píng)判標(biāo)準(zhǔn)是什么？這方面我也一直在探索，沒想明白。

但有一點(diǎn)，在我看來是非常清晰的，軟件定義汽車作為設(shè)計(jì)的最后一環(huán)，絕對(duì)是將大家共同的努力呈現(xiàn)出來的一環(huán)。舉個(gè)例子，在服務(wù)定義時(shí)，首先要定義Service，之后定義Service Interface，再就是定義SOME/IP Service Interface Deployment，最后才是Service Instance，但我們?cè)诳捶?wù)通信行為的時(shí)候，只看到了實(shí)例化后的服務(wù)交互，但沒有前面的那些類型定義，服務(wù)實(shí)例化如何存在？如果不去梳理功能，設(shè)計(jì)好服務(wù)邏輯，整合服務(wù)接口，會(huì)有好的服務(wù)實(shí)例？那軟件定義汽車的概念其實(shí)也一樣，如果不從源頭梳理清楚需求，做不到每個(gè)設(shè)計(jì)都有其對(duì)應(yīng)的需求，那軟件定義汽車就無法落地，軟件工程師實(shí)現(xiàn)的時(shí)候肯定也是一臉懵。

其實(shí)這里就是想強(qiáng)調(diào)一點(diǎn)，整車開發(fā)的流程應(yīng)該是環(huán)環(huán)相扣，軟件脫離其他，是無法單獨(dú)存在的。

02 . 架構(gòu)如何設(shè)計(jì)

在上述層層關(guān)系中，某種程度來說，架構(gòu)是成就了軟件定義汽車，如下圖所示。

??

圖3. EEA成就軟件定義汽車

那在弄清楚軟件如何定義汽車之前，我覺得最重要的是考慮清楚架構(gòu)如何設(shè)計(jì)，而我的專業(yè)是架構(gòu)，所以我從自身經(jīng)驗(yàn)出發(fā)，分析下架構(gòu)如何設(shè)計(jì)：

作為OEM，首先要對(duì)架構(gòu)如何設(shè)計(jì)了然于心，并有一套可以適用于所有車型的架構(gòu)設(shè)計(jì)方法論，這套方法論必須做到不管技術(shù)如何更新迭代，架構(gòu)如何演變，方法論可以一直被沿用，內(nèi)容可以不斷更新，但框架始終不變。如下圖所示，就是我理解中的架構(gòu)設(shè)計(jì)方法論。

我將架構(gòu)設(shè)計(jì)劃分為四大方向：架構(gòu)特征、架構(gòu)拓?fù)?，架?gòu)決策，設(shè)計(jì)指導(dǎo)。

??

圖4. 架構(gòu)設(shè)計(jì)方法論

• 架構(gòu)特征

首先，架構(gòu)特征是定義整車架構(gòu)最主要的一個(gè)維度，架構(gòu)特征定義了系統(tǒng)的成功標(biāo)準(zhǔn)，它通常與系統(tǒng)的功能強(qiáng)相關(guān)，通過功能需求和OEM需求來推導(dǎo)和定義架構(gòu)特征。比如，如果OEM需要通過沿用架構(gòu)來降低成本，那架構(gòu)特征就必須包括可復(fù)用性，同時(shí)如果技術(shù)不斷變革，架構(gòu)勢必也要具備不斷更新迭代，但如何做到即可復(fù)用又滿足后續(xù)技術(shù)發(fā)展，這樣的架構(gòu)就必須要做到可擴(kuò)展性，隨著智能駕駛等級(jí)的不斷升級(jí)，整車系統(tǒng)的安全穩(wěn)定同樣也是一個(gè)重要的特征，因此比起可復(fù)用性和擴(kuò)展性來說，架構(gòu)的可靠性也變得尤為重要。

• 架構(gòu)拓?fù)?/strong>

架構(gòu)通過拓?fù)鋪沓尸F(xiàn)，而拓?fù)鋭澐譃槲锢硗負(fù)?，網(wǎng)絡(luò)拓?fù)?，功能拓?fù)洹２煌耐負(fù)鋵?duì)應(yīng)不同的架構(gòu)團(tuán)隊(duì)，各個(gè)架構(gòu)團(tuán)隊(duì)負(fù)責(zé)各自的專業(yè)內(nèi)容設(shè)計(jì)，并要做到整個(gè)架構(gòu)系統(tǒng)協(xié)調(diào)統(tǒng)一。

• 架構(gòu)決策

定義架構(gòu)的下一個(gè)因素是架構(gòu)決策，架構(gòu)決策定義了應(yīng)該如何構(gòu)建系統(tǒng)的規(guī)則。例如，架構(gòu)決策是否采用SOA，這將決定了OEM整個(gè)技術(shù)方向，如果不采用SOA，就需要考慮后續(xù)是否會(huì)脫離主流技術(shù)路線，如果采用SOA，是否就代表押對(duì)寶了呢？因此架構(gòu)決策逐漸形成了整車系統(tǒng)的約束，并指導(dǎo)設(shè)計(jì)開發(fā)團(tuán)隊(duì)確定什么是允許的，什么是不允許的。

• 架構(gòu)原則

架構(gòu)定義中的最后一個(gè)因素是設(shè)計(jì)原則。設(shè)計(jì)原則與架構(gòu)決策的不同之處在于，設(shè)計(jì)原則是指導(dǎo)方針，而不是硬性規(guī)則，每個(gè)決策的定版都要有一套對(duì)應(yīng)的設(shè)計(jì)原則。

面對(duì)新型架構(gòu)，OEM往往面臨著定義架構(gòu)師的角色與定義架構(gòu)一樣困難。OEM往往不具備判斷一個(gè)架構(gòu)師好與壞的能力，但我認(rèn)為好的架構(gòu)師勢必是從基層中來的，必須要具備實(shí)戰(zhàn)經(jīng)驗(yàn)，口說無憑，說的天花亂墜，如果無法合理推導(dǎo)以上四大方向策略，也就只是請(qǐng)了個(gè)會(huì)念經(jīng)的和尚，但3個(gè)和尚沒水喝。另一個(gè)角度，光有實(shí)戰(zhàn)經(jīng)驗(yàn)也無法成為一個(gè)好的架構(gòu)師，好的架構(gòu)師必須要能夠從基層實(shí)戰(zhàn)中升華，找出規(guī)律，提煉方法論，對(duì)整個(gè)新型電子電氣架構(gòu)架構(gòu)落地了然于胸，能夠?yàn)楣径x戰(zhàn)略技術(shù)方向，并同時(shí)能夠?qū)ψ约旱臎Q策有足夠的的信心。因此我建議OEM與其將時(shí)間浪費(fèi)在定義角色上，還不如將重點(diǎn)放在對(duì)架構(gòu)師的期望上。

因?yàn)樾滦碗娮与姎饧軜?gòu)是建立在以太網(wǎng)，SOA，智能座艙，智能駕駛等新技術(shù)的基礎(chǔ)上，因此絕非資歷越深越能滿足OEM對(duì)該領(lǐng)域架構(gòu)師的期望，真正的期望應(yīng)該與對(duì)方的角色，頭銜，工作年限等都無關(guān)，如下為新型電子電氣架構(gòu)架構(gòu)師的七個(gè)核心期望:

• 具備做出架構(gòu)決策的能力

架構(gòu)師需要定義用于指導(dǎo)團(tuán)隊(duì)、部門或整個(gè)企業(yè)的技術(shù)決策或者架構(gòu)決策，以及設(shè)計(jì)原則。

• 能夠持續(xù)分析架構(gòu)

架構(gòu)師應(yīng)該持續(xù)分析架構(gòu)和當(dāng)前的技術(shù)環(huán)境，然后提供可行的改進(jìn)方案

• 緊跟最新趨勢，具備不斷學(xué)習(xí)的能力

架構(gòu)師應(yīng)該緊跟最新的技術(shù)和行業(yè)趨勢，需要有清晰的技術(shù)路徑，不允許出現(xiàn)模棱兩可的地方

• 堅(jiān)持對(duì)決策負(fù)責(zé)

架構(gòu)師應(yīng)該確保遵從架構(gòu)決策和設(shè)計(jì)原則，并有對(duì)其決策負(fù)責(zé)的決心和自信

• 具備知識(shí)面的廣度，接觸不同領(lǐng)域和建立不同領(lǐng)域的經(jīng)驗(yàn)

架構(gòu)師應(yīng)該接觸多種不同的技術(shù)、框架、平臺(tái)和環(huán)境，從實(shí)戰(zhàn)中來。

• 具備非常深的業(yè)務(wù)領(lǐng)域知識(shí)

架構(gòu)師應(yīng)該對(duì)本專業(yè)領(lǐng)域的理論，經(jīng)驗(yàn)要達(dá)到很高的深度和廣度。

• 人際交往能力

架構(gòu)師應(yīng)該具備卓越的人際交往能力，包括團(tuán)隊(duì)合作、促進(jìn)和領(lǐng)導(dǎo)能力。

架構(gòu)師角色能否成功的第一個(gè)關(guān)鍵因素取決于理解和實(shí)踐以上每一個(gè)期望。

對(duì)于上面所說的架構(gòu)四大因素，對(duì)架構(gòu)設(shè)計(jì)人員的要求是必須要對(duì)整車系統(tǒng)架構(gòu)有個(gè)非常非常深入的理解，紙上談兵肯定是不行的。

03. 架構(gòu)拓?fù)浞治?/strong>

從今年開始，區(qū)域架構(gòu)變成了后起之秀，成為了新一代網(wǎng)紅。如果哪家主機(jī)廠還沒有開始準(zhǔn)備量產(chǎn)區(qū)域架構(gòu)，簡直是馬上要被淘汰的節(jié)奏，行業(yè)內(nèi)充滿了恐慌。

下面由我來提供一些市場調(diào)研和分析，架構(gòu)特性分析，給大家?guī)硪恍├潇o思考或者一些參考。首先，在分析不同架構(gòu)之前，我們必須清楚我們要分析的是那種類型的架構(gòu)拓?fù)?，不同的架?gòu)拓?fù)渲械墓?jié)點(diǎn)類型是不同的：

• 控制器

—— 基于域控D-based

域控制器是一組系統(tǒng)，是按照功能域進(jìn)行劃分，每個(gè)功能域擁有一個(gè)域控制器，特定域下的傳感器和執(zhí)行器直接或者間接的連接到對(duì)應(yīng)的域控制器上。

—— 基于區(qū)域Z-based

區(qū)域控制器同樣也是一組系統(tǒng)，但是是根據(jù)在汽車物理位置來定義的，每個(gè)區(qū)域擁有一個(gè)區(qū)域控制器，傳感器和執(zhí)行器直接連接到最近的區(qū)域控制器。

• 中央

—— 基于中央計(jì)算單元VC

所有的復(fù)雜功能邏輯都映射到中央單元，傳感器將數(shù)據(jù)直接傳送到中央單元，中央單元再直接傳送給執(zhí)行器。這時(shí)，域或區(qū)域控制器僅執(zhí)行該域或區(qū)域網(wǎng)絡(luò)與中央單元之間的組網(wǎng)功能，執(zhí)行一些簡單功能邏輯。

—— 基于控制器單元CC

將復(fù)雜功能邏輯映射到域或區(qū)域中的控制器，這樣域控制或者區(qū)域控制器就要具備很強(qiáng)的計(jì)算能力，因此中央單元只執(zhí)行需要來自多個(gè)域或區(qū)域的數(shù)據(jù)或向多個(gè)域或區(qū)域提供數(shù)據(jù)的任務(wù)，而無需處理復(fù)雜功能，嚴(yán)格來說是弱化了中央計(jì)算單元。

通過以上的分類，當(dāng)前可實(shí)施的架構(gòu)就可組合成4種，分別是D-VC，D-CC，Z-VC，Z-CC，如果有些OEM想直接從Z-VC開始入手，跳過中間D-CC，D-VC，Z-CC環(huán)節(jié)，也是可以的，只要落實(shí)了具體架構(gòu)落地的技術(shù)路徑，這些都不是難點(diǎn)，就怕有些沒有十足的把握，甚至沒有任何理論支撐直接就一刀切的做Z-VC，這樣就容易成為前浪，花了人力物力，最終出來一個(gè)四不像，光為他人做嫁衣。如果以落地為目標(biāo)，前期就必須做好需求分析，技術(shù)分析，規(guī)劃出合理的技術(shù)路徑，再行動(dòng)。

相對(duì)于域控架構(gòu)，區(qū)域架構(gòu)和它之間的區(qū)別將是本章節(jié)的重點(diǎn)：

• 硬件資源成本
• 關(guān)鍵應(yīng)用程序的故障概率
• 通信電纜長度
• 通信負(fù)載
• 功能負(fù)載

1. 硬件資源成本

首先要對(duì)需求進(jìn)行分析，區(qū)域架構(gòu)和域控架構(gòu)核心問題是以太網(wǎng)是否作為主干網(wǎng)，這種區(qū)別就主要體現(xiàn)在不同等級(jí)的功能安全，是否進(jìn)行冗余設(shè)計(jì)，以及冗余的程度是什么。國外研究表明，不同的功能安全等級(jí)，所對(duì)應(yīng)的硬件資源成本是不同的，因此我們基于不同功能安全所對(duì)應(yīng)的資源成本矩陣，來分析不同架構(gòu)所需要的成本。

表1：功能安全等級(jí)對(duì)應(yīng)的資源成本矩陣

??

對(duì)于四種不同的架構(gòu)類型，最終所對(duì)應(yīng)的成本是不一樣的：

1）無冗余設(shè)計(jì)

• D-CC：成本最低
• D-VC：成本相對(duì)于D-CC高，但差距不是很大，增加了大約2.9%
• Z-VC和Z-CC：成本相對(duì)于域控架構(gòu)，增加了28%左右

2）有冗余設(shè)計(jì)

• D-CC：依然是成本最低
• D-VC：成本第二，但和D-CC差距就拉大了，增加了大約29%
• Z-CC：成本相對(duì)于D-VC增加的不是很明顯，增加了6%
• Z-VC：成本比前三者大了許多， 相對(duì)于Z-CC，增加了21%左右

首先有個(gè)前提就是，區(qū)域架構(gòu)是必須要引進(jìn)冗余設(shè)計(jì)，而域控架構(gòu)一般無需引進(jìn)過多的冗余設(shè)計(jì)。因此對(duì)于成本這塊，應(yīng)該拿有冗余設(shè)計(jì)的區(qū)域架構(gòu)和無冗余設(shè)計(jì)的域控架構(gòu)進(jìn)行比較，這樣就可以得出最終我們想要的成本數(shù)據(jù)：區(qū)域架構(gòu)Z-VC在域控架構(gòu)D-CC的基礎(chǔ)上，成本增加了63%之多。

另外，以上是我們的硬件成本，但其實(shí)從軟件成本上，我們依然可以進(jìn)一步得到一些結(jié)論，本身域控架構(gòu)是在分布式架構(gòu)的基礎(chǔ)上，增加了很多資源，比如域控制器增加了多顆MPU芯片，全都運(yùn)載了以太網(wǎng)協(xié)議棧，部分域控制器還采用Adaptive AUTOSAR協(xié)議棧，因此域控制器的成本相對(duì)于分布式架構(gòu)已經(jīng)是質(zhì)的飛越了。那區(qū)域架構(gòu)還在域控制器的基礎(chǔ)上，不斷增加冗余。因此總結(jié)來說，區(qū)域架構(gòu)的落地充滿了錢的味道，所以需要做一些權(quán)衡，既保證需求，又能降低成本。

2. 關(guān)鍵應(yīng)用程序的故障概率

對(duì)于主干網(wǎng)上關(guān)鍵應(yīng)用程序的故障概率，和不同的架構(gòu)類型內(nèi)部網(wǎng)絡(luò)配置是強(qiáng)相關(guān)的：

1）無冗余設(shè)計(jì)

• D-CC：因?yàn)榧軜?gòu)相對(duì)簡單，依然四種架構(gòu)類型中故障率最低的。
• Z-CC：鑒于D-CC和D-VC之間，相對(duì)于D-CC保持了12.9%的增量
• D-VC：在Z-CC的基礎(chǔ)上，增加了11.4%左右
• Z-VC：在D-VC的基礎(chǔ)上，增加了2.5%

2）有冗余設(shè)計(jì)

• D-CC：相對(duì)于無冗余的D-CC架構(gòu)，增加了6%
• Z-CC：鑒于D-CC和D-VC之間，相對(duì)于D-CC提升了21.2%的增量
• D-VC：在D-CC的基礎(chǔ)上，增加了17.5%左右
• Z-VC：在D-VC的基礎(chǔ)上，增加了4.1%

基于以上的數(shù)據(jù)，我們可以得出，有冗余設(shè)計(jì)的Z-VC相對(duì)于無冗余設(shè)計(jì)的D-CC，故障率大約增加了61.2%，故障率的增加，失效概率也會(huì)大幅度增加。

3. 通信電纜長度和通信負(fù)載

上面也說了故障率是跟這些架構(gòu)內(nèi)部網(wǎng)絡(luò)通信相關(guān)的，那對(duì)于這四種架構(gòu)來說，需要的通信總線纜長度和總通信負(fù)載情況又是如何呢？

1）無冗余設(shè)計(jì)

基于控制器CC和中央計(jì)算單元VC在通信線纜層面，并沒有太大區(qū)別，主要的區(qū)分點(diǎn)在于域控控制器和區(qū)域控制器之間，因?yàn)橛蚩刂破魇前凑諈^(qū)域分布，相對(duì)于域控制器架構(gòu)的線纜，區(qū)域控制器線纜總長度下降30%左右。

但線纜長度和成本下降，并不會(huì)降低通信負(fù)載數(shù)量，對(duì)于通信負(fù)載，因?yàn)楦鷶?shù)據(jù)流向強(qiáng)相關(guān)，在功能相同的情況下，D-CC擁有最低負(fù)載，而D-VC，Z-CC，Z-VC的通信總量大概是D-CC的2.53倍。

2）冗余設(shè)計(jì)

增加了鏈路冗余，則需要的線纜長度增加了78-80%左右，同時(shí)鏈路冗余，功能冗余和通信冗余等原因，也導(dǎo)致這四種架構(gòu)的通信負(fù)載呈倍數(shù)增加，功能邏輯也增加50%左右。

綜上，在兩個(gè)不同的應(yīng)用程序節(jié)點(diǎn)上應(yīng)用冗余對(duì)系統(tǒng)屬性的影響，D-CC拓?fù)浔绕渌負(fù)渚哂懈玫呢?fù)載和成本結(jié)果，同時(shí)在故障概率和總通信電纜長度方面被一些基于區(qū)域的拓?fù)涑?。以上的?shù)據(jù)只能分析出不同的架構(gòu)特性，我們并不傾向于任何一種架構(gòu)，至于OEM具體采用那種，是一定要結(jié)合自己的需要來做相關(guān)規(guī)劃，域控架構(gòu)和區(qū)域架構(gòu)各自的優(yōu)勢也都很明顯。

考慮到當(dāng)前OEM一方面希望通過傳感器、執(zhí)行器和其他組件融合在一起實(shí)現(xiàn)相同的功能，以便作為一種節(jié)省成本的策略進(jìn)行考慮。另一方面，OEM又希望維護(hù)獨(dú)立的組件以實(shí)現(xiàn)系統(tǒng)冗余，確保功能安全。所以架構(gòu)設(shè)計(jì)還是要以需求為導(dǎo)向，架構(gòu)目標(biāo)清晰之后，架構(gòu)設(shè)計(jì)方向才能清晰。