?[[433272]]?

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

01. xxx定義xxx

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

??

圖2. xxx 定義 xxx

• 市場定義需求

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

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

• 需求定義架構

有了明確的需求，架構團隊就可以根據特定需求進行架構設計，有的放矢的分析每條需求，從中提取架構特征，根據所要達到的架構特征，找到最適合的架構拓撲，在對應的架構拓撲中細化相關的技術方案，找到需求的最優(yōu)方案決策，從而輸出對應的設計方案，規(guī)范，和設計指導給到軟硬件開發(fā)團隊。

• 架構定義功能

架構在輸出對應的設計指導時，必須基于識別的架構特征和拓撲，來約束和限制整車功能，并基于相關約束設計整車功能以及功能實現方案，輸出面向不同對象的功能描述文檔，有了這些文檔輸出，整車功能基本定型，接下來才有可能進行開發(fā)實現。

• 功能定義軟件

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

有了功能邏輯之間的交互，軟硬件開發(fā)團隊，就可以開始進行對應的功能開發(fā)和實現，因此如果功能邏輯設計不清晰，就會導致軟件代碼邏輯混亂。只有功能清晰，軟件才能基于功能定義的基礎上，設計好功能實現細節(jié)。

• 軟件定義汽車

“軟件定義汽車”的含義我懂，但如果像之前行業(yè)內特意把這個概念單獨拎出來，著重強調，我就一直有個疑問，軟件是如何來定義汽車的，尤其是在這個詞沒出現之前，難道軟件在汽車里就不存在。

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

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

其實這里就是想強調一點，整車開發(fā)的流程應該是環(huán)環(huán)相扣，軟件脫離其他，是無法單獨存在的。

02 . 架構如何設計

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

??

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

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

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

我將架構設計劃分為四大方向：架構特征、架構拓撲，架構決策，設計指導。

??

圖4. 架構設計方法論

• 架構特征

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

• 架構拓撲

架構通過拓撲來呈現，而拓撲劃分為物理拓撲，網絡拓撲，功能拓撲。不同的拓撲對應不同的架構團隊，各個架構團隊負責各自的專業(yè)內容設計，并要做到整個架構系統(tǒng)協(xié)調統(tǒng)一。

• 架構決策

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

• 架構原則

架構定義中的最后一個因素是設計原則。設計原則與架構決策的不同之處在于，設計原則是指導方針，而不是硬性規(guī)則，每個決策的定版都要有一套對應的設計原則。

面對新型架構，OEM往往面臨著定義架構師的角色與定義架構一樣困難。OEM往往不具備判斷一個架構師好與壞的能力，但我認為好的架構師勢必是從基層中來的，必須要具備實戰(zhàn)經驗，口說無憑，說的天花亂墜，如果無法合理推導以上四大方向策略，也就只是請了個會念經的和尚，但3個和尚沒水喝。另一個角度，光有實戰(zhàn)經驗也無法成為一個好的架構師，好的架構師必須要能夠從基層實戰(zhàn)中升華，找出規(guī)律，提煉方法論，對整個新型電子電氣架構架構落地了然于胸，能夠為公司定義戰(zhàn)略技術方向，并同時能夠對自己的決策有足夠的的信心。因此我建議OEM與其將時間浪費在定義角色上，還不如將重點放在對架構師的期望上。

因為新型電子電氣架構是建立在以太網，SOA，智能座艙，智能駕駛等新技術的基礎上，因此絕非資歷越深越能滿足OEM對該領域架構師的期望，真正的期望應該與對方的角色，頭銜，工作年限等都無關，如下為新型電子電氣架構架構師的七個核心期望:

• 具備做出架構決策的能力

架構師需要定義用于指導團隊、部門或整個企業(yè)的技術決策或者架構決策，以及設計原則。

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

架構師應該持續(xù)分析架構和當前的技術環(huán)境，然后提供可行的改進方案

• 緊跟最新趨勢，具備不斷學習的能力

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

• 堅持對決策負責

架構師應該確保遵從架構決策和設計原則，并有對其決策負責的決心和自信

• 具備知識面的廣度，接觸不同領域和建立不同領域的經驗

架構師應該接觸多種不同的技術、框架、平臺和環(huán)境，從實戰(zhàn)中來。

• 具備非常深的業(yè)務領域知識

架構師應該對本專業(yè)領域的理論，經驗要達到很高的深度和廣度。

• 人際交往能力

架構師應該具備卓越的人際交往能力，包括團隊合作、促進和領導能力。

架構師角色能否成功的第一個關鍵因素取決于理解和實踐以上每一個期望。

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

03. 架構拓撲分析

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

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

• 控制器

—— 基于域控D-based

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

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

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

• 中央

—— 基于中央計算單元VC

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

—— 基于控制器單元CC

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

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

相對于域控架構，區(qū)域架構和它之間的區(qū)別將是本章節(jié)的重點：

• 硬件資源成本
• 關鍵應用程序的故障概率
• 通信電纜長度
• 通信負載
• 功能負載

1. 硬件資源成本

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

表1：功能安全等級對應的資源成本矩陣

??

對于四種不同的架構類型，最終所對應的成本是不一樣的：

1）無冗余設計

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

2）有冗余設計

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

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

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

2. 關鍵應用程序的故障概率

對于主干網上關鍵應用程序的故障概率，和不同的架構類型內部網絡配置是強相關的：

1）無冗余設計

• D-CC：因為架構相對簡單，依然四種架構類型中故障率最低的。
• Z-CC：鑒于D-CC和D-VC之間，相對于D-CC保持了12.9%的增量
• D-VC：在Z-CC的基礎上，增加了11.4%左右
• Z-VC：在D-VC的基礎上，增加了2.5%

2）有冗余設計

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

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

3. 通信電纜長度和通信負載

上面也說了故障率是跟這些架構內部網絡通信相關的，那對于這四種架構來說，需要的通信總線纜長度和總通信負載情況又是如何呢？

1）無冗余設計

基于控制器CC和中央計算單元VC在通信線纜層面，并沒有太大區(qū)別，主要的區(qū)分點在于域控控制器和區(qū)域控制器之間，因為域控制器是按照區(qū)域分布，相對于域控制器架構的線纜，區(qū)域控制器線纜總長度下降30%左右。

但線纜長度和成本下降，并不會降低通信負載數量，對于通信負載，因為跟數據流向強相關，在功能相同的情況下，D-CC擁有最低負載，而D-VC，Z-CC，Z-VC的通信總量大概是D-CC的2.53倍。

2）冗余設計

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

綜上，在兩個不同的應用程序節(jié)點上應用冗余對系統(tǒng)屬性的影響，D-CC拓撲比其他拓撲具有更好的負載和成本結果，同時在故障概率和總通信電纜長度方面被一些基于區(qū)域的拓撲超越。以上的數據只能分析出不同的架構特性，我們并不傾向于任何一種架構，至于OEM具體采用那種，是一定要結合自己的需要來做相關規(guī)劃，域控架構和區(qū)域架構各自的優(yōu)勢也都很明顯。

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