現(xiàn)代汽車中軟件的復(fù)雜性迅速增加，這決定了電氣和/或電子（E/E）汽車架構(gòu)的新趨勢。因此，許多原始設(shè)備制造商（OEM）和供應(yīng)商一直主張將集中式E/E架構(gòu)作為未來的汽車架構(gòu)。在本文中，我們提出了在汽車工業(yè)中采用集中式E/E架構(gòu)的理由。我們通過仔細(xì)研究傳統(tǒng)分散式汽車E/E架構(gòu)的挑戰(zhàn)和缺點(diǎn)，并與集中式架構(gòu)帶來的相應(yīng)好處進(jìn)行對比，來討論集中化架構(gòu)方案的動機(jī)。然后，我們詳細(xì)討論了支持新的集中式結(jié)構(gòu)所需的技術(shù)。我們介紹了網(wǎng)絡(luò)技術(shù)、虛擬化、電子控制單元（ECU）硬件和AUTOSAR方面的技術(shù)現(xiàn)狀，并討論了這些技術(shù)在工業(yè)中的采用情況。自始至終，功能安全都是作為汽車行業(yè)的首要問題來考慮和解決的。

本節(jié)介紹了集中式汽車E/E架構(gòu)的動機(jī)。隨后介紹了架構(gòu)中的基本概念。最后，討論了集中式E/E解決方案在汽車工業(yè)中的應(yīng)用。

A. 必要性

車輛E/E架構(gòu)包括ECU、傳感器、制動器及其所有互連設(shè)備，以及電氣網(wǎng)絡(luò)(如高壓網(wǎng)絡(luò)、電力電子)和信息娛樂系統(tǒng)(如消費(fèi)電子元件)。傳統(tǒng)上，車輛E/E架構(gòu)是分散式的。

分散式車輛E/E架構(gòu)有一些優(yōu)點(diǎn)。例如，分散式結(jié)構(gòu)本質(zhì)上支持ECU之間分離：它們允許在單個ECU上部署一個或幾個非常緊密相關(guān)的功能。這使得驗(yàn)證ECU集成到網(wǎng)絡(luò)的條件相對簡單，主要是確保所需總線帶寬的可用性和檢查通信信息的簡單時序要求。此外，更換損壞的ECU很容易，因?yàn)镋CU很輕，很多功能沒法實(shí)現(xiàn)。對于每個ECU，可以使用具有平均處理能力的CPU，因?yàn)槊總€ECU封裝的功能有限。然而，分散式架構(gòu)存在一些限制。

首先，在現(xiàn)代汽車軟件實(shí)現(xiàn)的功能迅速和穩(wěn)步上升的時代，'每個ECU一個功能 '的方法已被證明是行不通的。為單個功能增加單獨(dú)的ECU會導(dǎo)致成本增加，因?yàn)樾枰~外的ECU及其線束存根。線束長度的增加進(jìn)一步引入了一個不必要的副作用，即限制了架構(gòu)物理布局的自由，因此在優(yōu)化最終架構(gòu)時會受到更嚴(yán)格的限制。此外，傳統(tǒng)的E/E架構(gòu)大多使用CAN（控制器區(qū)域網(wǎng)絡(luò)）組網(wǎng)，但也依賴FlexRay、LIN（本地互連網(wǎng)絡(luò)）和MOST（面向媒體的系統(tǒng)傳輸）。雖然這些網(wǎng)絡(luò)技術(shù)足以用于傳統(tǒng)的通信，但由于預(yù)期的數(shù)據(jù)量和不同ECU之間的互連數(shù)量，預(yù)計(jì)在不久的將來它們將不再適用。然而，盡管汽車以太網(wǎng)不被認(rèn)為是一種傳統(tǒng)的汽車通信技術(shù)，但在過去的十年中，它在汽車網(wǎng)絡(luò)中的應(yīng)用已經(jīng)穩(wěn)步上升。汽車以太網(wǎng)能夠支持大量的數(shù)據(jù)，以及具有功能安全要求的時間關(guān)鍵型通信。我們的觀點(diǎn)，也是許多其他作者（例如Matheus和K?nigseder）的觀點(diǎn)，即汽車以太網(wǎng)是未來汽車網(wǎng)絡(luò)的通信技術(shù)，盡管它不會是未來汽車所采用的唯一通信技術(shù)。汽車以太網(wǎng)的使用將是向集中式架構(gòu)發(fā)展的主要驅(qū)動力之一。

如今，為不同的細(xì)分市場構(gòu)建不同的車型意味著需要發(fā)布大量的軟件，并且可能需要構(gòu)建多個架構(gòu)來支持不同的車型特性。因此，目前市場要求的多樣性意味著需要一個多功能的、具有成本效益的E/E架構(gòu)解決方案。這個解決方案需要處理大量的車型，這些車型都是由客戶的期望引起的，例如，個性化的舒適功能，以及對自動駕駛輔助系統(tǒng)(ADAS)等自動支持的依賴。這增加了所需提供的車型的數(shù)量。此外，目前汽車生產(chǎn)線支持各種市場、技術(shù)和配置（例如，不同的動力系統(tǒng)架構(gòu)、不同的硬件平臺和來自不同供應(yīng)商的部件）。在減少支持大型汽車軟件產(chǎn)品線所需的軟件發(fā)布數(shù)量方面，E/E集中化具有很大的潛力，這一點(diǎn)將在下一節(jié)討論。

此外，當(dāng)前的 E/E 架構(gòu)解決方案不一定設(shè)計(jì)為對外部惡意攻擊具有魯棒性?？紤]到車輛與外界的連接不斷增加，未來的車輛架構(gòu)需要保證這些安全特性。

除了這些缺點(diǎn)，原始設(shè)備制造商和供應(yīng)商采取的策略也影響了E/E架構(gòu)的演變趨勢。例如，除了要求原始設(shè)備制造商和供應(yīng)商與汽車標(biāo)準(zhǔn)(如AUTOSAR, ISO 26262)兼容外，原始設(shè)備制造商還依賴越來越多的供應(yīng)商提供的軟件和硬件。在需求的驅(qū)使下，他們不得不整合改進(jìn)的技術(shù)，如先進(jìn)的高清顯示器、快速網(wǎng)絡(luò)和執(zhí)行高端功能的新ECU。但目前的架構(gòu)不夠靈活，無法讓OEM廠商輕松整合新的、多樣化的技術(shù)。

上述驅(qū)動因素促使汽車行業(yè)研究更加集中的汽車E/E架構(gòu)解決方案，如前面介紹的領(lǐng)域集中式、跨域集中式和車輛集中式（或面向區(qū)域）的架構(gòu)。本節(jié)中介紹的行業(yè)向集中式E/E架構(gòu)轉(zhuǎn)變的動機(jī)，可以通過下一節(jié)介紹的一些基本例子和結(jié)果來進(jìn)一步確定。

B. 動因分析

1) 不同處理要求: 對大型汽車生產(chǎn)線進(jìn)行成本效益的處理，是業(yè)界尋找新的E/E架構(gòu)解決方案的主要動力。例如，一個大型汽車OEM的引擎控制器軟件支持三種不同的引擎，在分散式E/E架構(gòu)中可以生成144個軟件/校準(zhǔn)版本。在一個集中的、面向領(lǐng)域的架構(gòu)中，一個強(qiáng)大的（領(lǐng)域）控制器承載了控制器的大部分功能，而一個非常簡單的智能執(zhí)行器只捕捉硬件變化（不同引擎之間的差異和底層硬件平臺之間的差異），領(lǐng)域控制器的發(fā)布數(shù)量將減少到72個，智能執(zhí)行器為3個，合計(jì)為75個。

作為集中式架構(gòu)支持汽車軟件產(chǎn)品線的成本效益開發(fā)的另一個例子，我們可以考慮一個汽車系統(tǒng)需求的案例，該需求因地理區(qū)域的不同而不同。在美國，汽車在被關(guān)閉時不能滑動，其法規(guī)要求 “... 啟動系統(tǒng)必須防止按鍵被移除... 除非變速器或齒輪選擇控制被鎖定在'停車’”。印尼等國家的規(guī)定可能會有不一樣要求，即 “車輛可以關(guān)閉鑰匙，然后進(jìn)入空擋，前提是司機(jī)被通知并明確接受關(guān)閉變速器的狀態(tài)?！?這一區(qū)域性要求允許車輛在自動停車庫或停車空間有限的地方關(guān)閉鑰匙后仍可滾動。

在分散式架構(gòu)的插電式混合動力汽車中，這個簡單的需求變化可能需要對大量ECU進(jìn)行軟件修改：

1)     車身控制模塊(BCM)，它監(jiān)控按鍵和電源開關(guān)用戶界面，并更新變速器位置顯示，包括接受用戶確認(rèn)的特殊齒輪選擇模式；

2)     變速器控制模塊（TCM），它與換擋器連接并控制變速器，同時可能與一個單獨(dú)的電子駐車ECU連接，該ECU控制駐車棘爪，將傳動系統(tǒng)鎖定在適當(dāng)?shù)奈恢茫?/span>

3)     混合動力監(jiān)督控制器（HSC），它協(xié)調(diào)混合動力電動驅(qū)動系統(tǒng)的整體控制；

4)     電池管理系統(tǒng)（BMS），即電池控制器，在美國版本中，可能只允許在停放棘爪嚙合時充電。

所有這些組件都可能需要在生產(chǎn)印尼車輛時更新軟件版本。例如，BCM的用戶界面必須進(jìn)行修改，以允許汽車在空檔狀態(tài)下關(guān)閉，向司機(jī)發(fā)出警報(bào)，并等待司機(jī)的明確確認(rèn)。為了允許在空擋狀態(tài)下關(guān)閉鑰匙，HSC和TCM必須進(jìn)行適當(dāng)?shù)男薷模赃m應(yīng)需求的變化。此外，印尼版的BMS可能會實(shí)現(xiàn)更多衍生的要求，即 '如果汽車在停車時正在充電，則在插入時需要停車制動'，因?yàn)槊绹娴腂MS出于安全原因不允許在非停車狀態(tài)下充電。

總的來說，受影響的ECU的數(shù)量相對比較多。在分散式架構(gòu)中，前面提到的模塊通常位于獨(dú)立的ECU上。隨著動力總成領(lǐng)域的集中化，例如，TCM、電機(jī)控制模塊（MCM）、BMS和HSC的可變功能將被整合到一個ECU上：在分散式架構(gòu)中對這些模塊的所有必要修改現(xiàn)在將集中在一個ECU上，導(dǎo)致一個單一的軟件版本捕獲這四個模塊的變化。隨著進(jìn)一步的集中化，例如將底盤和HMI（人機(jī)界面）合并到BCM中，將所有詳細(xì)的動力總成要求合并到HSC中，由TCM、BMS和MCM作為智能執(zhí)行器發(fā)揮作用，只需要更新用于用戶界面的BCM和用于其余功能的HSC。所有的智能執(zhí)行器代碼可以保持不變。因此，領(lǐng)域控制器架構(gòu)不需要分散式架構(gòu)的四、五個ECU軟件版本，而只需要兩個版本。

2) 一項(xiàng)研究: 另外一個例子是，Kanajan等人的早期的一項(xiàng)研究比較了四種不同的E/E架構(gòu)，涵蓋了包括控制和I/O的集中化程度。在他們的研究中，集中式控制與本文討論的概念相同，而集中式I/O是指一個特定的傳感器或執(zhí)行器是否直接連接到控制器（“集中式”），或作為一個智能執(zhí)行器連接到通信網(wǎng)絡(luò)（“分散式”）。到目前為止，在本文中，我們完全專注于智能執(zhí)行器，在他們的術(shù)語中是 '分散式'。

Kanajan等人考慮的四種架構(gòu)分別是CICC(集中式I/O，集中式控制)、CIDC(集中式I/O，分散式控制)、DIDC(分散式I/O，分散式控制)和MDICC(混合分散式I/O，集中式控制)。這其中，我們只對DIDC和MDICC感興趣。DIDC是由CAN總線上的許多具有獨(dú)立功能的ECU組成，同時只有智能傳感器/執(zhí)行器直接連接到同一CAN總線上。MDICC是由集中式和分散式ECU和傳感器/執(zhí)行器混合組成，同時與CAN互連。該作者在一些理想的架構(gòu)指標(biāo)方面對這四種架構(gòu)進(jìn)行了比較：端到端控制延遲；物理屬性（如電線長度和ECU數(shù)量）；網(wǎng)絡(luò)上的數(shù)據(jù)量；架構(gòu)靈活性（(魯棒性）變化，如重新定位、集中或分散車輛中的傳感器和執(zhí)行器，以及增加或刪除ECU（與車輛類型有關(guān)的架構(gòu)變化）。

該比較代表了在CAN總線上混合ECU、軟件控制和傳感器/執(zhí)行器的各種選擇，以形成E/E網(wǎng)絡(luò)。MDICC最能代表一個典型的傳統(tǒng)的、分散式E/E結(jié)構(gòu)。然而，我們所描述的集中式架構(gòu)與DIDC最相似，除了我們的控制都集中在一個有足夠能力的ECU上。我們可以肯定地說，在作者最初的DIDC架構(gòu)中，將控制權(quán)集中在一個強(qiáng)大的ECU上，對他們的四個標(biāo)準(zhǔn)有如下影響。

現(xiàn)在，我們根據(jù)對DIDC的這種修改來重新審視作者的結(jié)果。第一，對于直接連接到相應(yīng)控制器的傳感器和執(zhí)行器，無論是在原研究中，還是與修改后的DIDC相比，MDICC具有更好的延遲。然而，由于前面提到的原因，對于總線上的智能傳感器和執(zhí)行器來說，在集中控制的DIDC中，控制延遲有望減少。第二，作者最初版本的DIDC僅在ECU總數(shù)方面遜于MDICC，但在架構(gòu)的修改版本中，由于有一個單一的主ECU，情況就不再是這樣了。必須承認(rèn)，整體的ECU成本差異是一個需要單獨(dú)研究的問題。第三，正如預(yù)期的那樣，原始研究中DIDC的全分布式架構(gòu)將所有信號放在CAN總線上，因此比MDICC更廣泛地使用該總線。隨著控制權(quán)完全集中到單個ECU上，總線的利用率預(yù)計(jì)會下降，因?yàn)橐恍┬盘枌⒊蔀橹醒隕CU的內(nèi)部信號，但不能說明DIDC的修改版在這方面與MDICC相比如何。第四，在最初的研究中，DIDC在結(jié)構(gòu)靈活性方面優(yōu)于MDICC。由于所有的控制都集中在單個ECU上，這一點(diǎn)并沒有改變。

 可以看出，Kanajan等人的研究可以用來理解集中式E/E架構(gòu)與經(jīng)典的分散式架構(gòu)在一些重要方面的比較。事實(shí)上，假設(shè)將基礎(chǔ)的CAN技術(shù)改變?yōu)楦F(xiàn)代的CAN FD或汽車E網(wǎng)，后者的數(shù)據(jù)傳輸率提高了幾個數(shù)量級，并將對上述原因三中的DIDC產(chǎn)生積極的影響，作者的結(jié)果使集中化處于壓倒性的優(yōu)勢。

3) 航空航天工業(yè)的經(jīng)驗(yàn)教訓(xùn)：航空航天業(yè)已經(jīng)成功地從分散式（航空術(shù)語中的 '聯(lián)合式'）E/E架構(gòu)過渡到集中式（'集成式'）架構(gòu)?，F(xiàn)代飛機(jī)采用了集成模塊化航空電子設(shè)備(IMA)概念，這是一種用于航空電子設(shè)備的集成(集中)架構(gòu)。IMA被廣泛認(rèn)為是一種具有成本效益的解決方案，可用于提高航空電子學(xué)的復(fù)雜性，具有以下優(yōu)點(diǎn)：減少CPU、通信通道、I/O模塊的數(shù)量，并相應(yīng)地減少電子設(shè)備的尺寸、重量和功耗；改善模塊化和軟硬件的復(fù)用率；提高資源效率等。波音787采用了IMA概念，使波音減少了100多個LRU(線路可更換單元)，減少了約900公斤的飛機(jī)重量。同樣，空客A380也采用了IMA概念，將處理器單元的數(shù)量減少了一半。在對35個項(xiàng)目（包括商用飛機(jī)和戰(zhàn)斗機(jī)）的研究中，已經(jīng)報(bào)告了功率消耗、空間和重量的減少。此外，Mairaj的研究展示了機(jī)載電子系統(tǒng)總數(shù)的減少，以及可靠性（平均故障間隔時間）和資源利用率的改善。在汽車行業(yè)，只報(bào)告了少數(shù)類似的結(jié)果。例如，德爾福報(bào)告說，奧迪A3上ADAS功能的集中化降低了30%的線束重量，節(jié)省了30%的成本，而博世報(bào)告說，從一個集中化的架構(gòu)（面向領(lǐng)域）到一個更集中的架構(gòu)（面向區(qū)域的架構(gòu)）時，線束重量減少了15-20%。但通過觀察，我們可以發(fā)現(xiàn)，汽車E/E架構(gòu)在本質(zhì)上類似于航空器的架構(gòu)，只是沒有那么復(fù)雜?？紤]到如前所述，一輛高端汽車有100多個ECU，而上述數(shù)字與波音公司采用IMA后減少的電子系統(tǒng)數(shù)量相同--這種比較提供了一種規(guī)模感。因此，在向集中化過渡的汽車領(lǐng)域中，我們有理由期待類似IMA的好處。

圖1. 車輛E/E架構(gòu)的預(yù)期演變

C. 基本概念

為了提高E/E體系結(jié)構(gòu)的可擴(kuò)展性，一些基于集中化總體思路的現(xiàn)代架構(gòu)已經(jīng)逐漸取代了分散化的架構(gòu)。圖1由Bosch設(shè)計(jì)，展示了電子/電子建筑的歷史和未來。汽車OEM目前正在嘗試上述三種類型的集中式架構(gòu)，即面向領(lǐng)域的、面向跨域的和面向區(qū)域的架構(gòu)，它們都是基于將多個相關(guān)功能集成到一個功能強(qiáng)大的單一ECU上的想法。在本節(jié)中，我們將介紹這些架構(gòu)背后的基本概念。

圖2. 典型的面向領(lǐng)域的E/E架構(gòu)

在面向領(lǐng)域的架構(gòu)中，軟件組件(SWC)根據(jù)車輛功能域進(jìn)行聚類，如圖2所示。盡管各組織之間的車輛領(lǐng)域略有不同，但汽車行業(yè)普遍認(rèn)同的主要領(lǐng)域有四個：車身和駕駛室（舒適度和照明）、信息娛樂（顯示器、娛樂和信息系統(tǒng)）、車輛運(yùn)動和安全（底盤、主動/被動安全和駕駛輔助功能）以及動力系統(tǒng)（推進(jìn)和廢氣處理）。在面向領(lǐng)域的架構(gòu)中，每個領(lǐng)域都有一個相應(yīng)的領(lǐng)域集群，該集群由一個領(lǐng)域控制單元（DCU）和零個或多個子領(lǐng)域ECU組成。DCU控制僅與其鏈接的子域ECU。一個典型的DCU有一個強(qiáng)大的多核CPU，承載著領(lǐng)域的主要功能，同時提供一個額外的抽象層，簡化了DCU所處領(lǐng)域和其他領(lǐng)域之間的接口。子域ECU封裝了輔助域的功能，所需的CPU功率較小。通常情況下，它們與相關(guān)的車輛硬件一起，構(gòu)成了智能執(zhí)行器。不同的DCU的連接是通過高速連接實(shí)現(xiàn)的，以太網(wǎng)數(shù)據(jù)主干。子域ECU通過典型的現(xiàn)場總線（如CAN、LIN、FlexRay）與它們的DCU相連，但如果需要的話，也可以通過汽車以太網(wǎng)實(shí)現(xiàn)。

雖然面向領(lǐng)域的架構(gòu)解決了分散式架構(gòu)的許多問題，但它們?nèi)悦媾R兩個主要挑戰(zhàn)。首先，某些高端功能如ADAS需要DCU之間的大量互動，使得DCU之間的邊界不明確。其次，由于DCU之間的互動越來越多，更多高端功能的出現(xiàn)，人們可能懷疑目前的通信帶寬將不足以滿足未來E/E架構(gòu)的需要?？缬蚣惺郊軜?gòu)的出現(xiàn)解決了這些問題。

在跨域集中式架構(gòu)中，多個域的功能被整合到單個ECU上，稱為跨域ECU（CDCU），如圖1所示。因此，一個可能實(shí)現(xiàn)的跨域集中式架構(gòu)看起來與圖2中的架構(gòu)類似，此處用CDCU取代了DCU。例如，底盤和動力系統(tǒng)領(lǐng)域的功能可以合并到一個車輛運(yùn)動控制CDCU中。

對于領(lǐng)域集中式架構(gòu)和跨域集中式架構(gòu)，分別在DCU和CDCU中進(jìn)行復(fù)雜函數(shù)的處理。因此，隨著功能的復(fù)雜性增加，在這些ECU中進(jìn)行的本地處理也在增加，需要更大的帶寬來在ECU之間傳輸經(jīng)過處理的、越來越復(fù)雜的信息。此外，由于單個車輛的功能變得越來越復(fù)雜，越來越依賴于其他功能，所以需要更多的線路。這些問題可以在一個車輛集中式或面向區(qū)域的架構(gòu)中得到解決。

圖3. 典型的面向區(qū)域的E/E架構(gòu)

在面向區(qū)域的架構(gòu)中，汽車被分為多個區(qū)域，每個區(qū)域都有一個區(qū)域ECU（ZCU），例如，'前右 '區(qū)域和 '前左 '區(qū)域。與面向領(lǐng)域的架構(gòu)中的子域ECU類似，ZCU與傳感器和執(zhí)行器相連。但是ZCU與子域ECU不同之處在于，它們不進(jìn)行任何處理以實(shí)現(xiàn)車輛功能。相反，它們收集并將與各自區(qū)域有關(guān)的信息轉(zhuǎn)發(fā)給一個功能更強(qiáng)大的中央服務(wù)器，該服務(wù)器對復(fù)雜功能進(jìn)行必要的處理。在這種架構(gòu)中，復(fù)雜的處理也可以負(fù)載到云端。圖3展示了一個面向區(qū)域的架構(gòu)的實(shí)現(xiàn)。這種架構(gòu)可以緩解上面提到的線束長度問題。如前所述，博世報(bào)告稱，當(dāng)使用面向區(qū)域的架構(gòu)而不是面向領(lǐng)域的架構(gòu)時，線束重量減少了15-20%。據(jù)我們所知，還沒有供應(yīng)商或OEM采用過以云計(jì)算為基礎(chǔ)的分區(qū)架構(gòu)；這種方法只在理論上討論過。面向區(qū)域的體系結(jié)構(gòu)的另一個主要優(yōu)勢是，高帶寬傳感器(如視覺或深度傳感器)可以直接連接到中央服務(wù)器進(jìn)行數(shù)據(jù)處理，從而消除了在遵守ISO 26262標(biāo)準(zhǔn)1時對功能安全造成的潛在代價。功能安全性和ISO 26262將下一節(jié)進(jìn)行討論。

本文所討論的架構(gòu)，即集中式架構(gòu)，包括本節(jié)中定義的面向領(lǐng)域、面向跨域和面向區(qū)域的架構(gòu)。

D. 在汽車行業(yè)的應(yīng)用

雖然一些現(xiàn)有的技術(shù)可以直接用于集中式架構(gòu)，但也有一些技術(shù)需要調(diào)整，以促進(jìn)集中式車輛E/E架構(gòu)的開發(fā)、運(yùn)行和維護(hù)。本節(jié)將介紹支持集中式E/E架構(gòu)的技術(shù)。首先，在第四節(jié)A部分中，我們討論了開發(fā)功能強(qiáng)大的集中式控制器所需的ECU硬件的進(jìn)展。然后第四節(jié)B部分討論了虛擬化，虛擬化這是一種基本的硬件支持的軟件技術(shù)，允許軟件重用，并能在集中式E/E架構(gòu)解決方案中有效和安全地集成。第四節(jié)C部分討論了滿足集中式E/E架構(gòu)需要的網(wǎng)絡(luò)技術(shù)，第四節(jié)D部分討論了AUTOSAR對現(xiàn)代E/E架構(gòu)的支持。

A. ECU硬件

圍繞（跨）域或區(qū)域控制器集中車輛的E/E架構(gòu)，會使車輛中的ECU的數(shù)量減少，但也增加了一些ECU的處理器負(fù)載，因?yàn)橛懈嗟墓δ懿渴鸬竭@些因此，汽車行業(yè)正在向帶有多核CPU的ECU過渡（目前，典型配置是兩到六核），以增加處理能力，并允許在不同的核上并行運(yùn)行幾個SWC。

許多硬件廠商已經(jīng)發(fā)布了多核處理器，用于高性能實(shí)時安全關(guān)鍵的汽車應(yīng)用。恩智浦推出了幾款微處理器，可以在現(xiàn)代E/E架構(gòu)的域控制器中加以利用。例如，他們的S32S24是一個基于ARM R52的四核微控制器，時鐘頻率為800 MHz，應(yīng)用范圍包括汽車車輛動力學(xué)、領(lǐng)域控制和安全協(xié)處理器應(yīng)用。英飛凌的AURIX微控制器系列基于英飛凌專有的TriCore架構(gòu)，可提供多達(dá)六個時鐘頻率為300MHz的內(nèi)核。無論何時，電路的設(shè)計(jì)都是為了滿足ASIL D的應(yīng)用。正如預(yù)期的那樣，已經(jīng)投入生產(chǎn)的域控制器利用了現(xiàn)有的微控制器技術(shù)。例如，第二節(jié)D部分中提到的Visteon的SmartCore是基于高通公司的8155芯片，這是一個基于ARM定制的64位八核微處理器。

對功能安全來說，多核CPU提供的執(zhí)行環(huán)境能增加免受干擾的自由度，因?yàn)槲锢砩喜煌膬?nèi)核隔離了具有不同臨界水平的SWC的同時執(zhí)行，這是很重要的。雖然這種分離并不像傳統(tǒng)架構(gòu)那樣徹底，不能每個ECU重新接收一個SWC，但與使用功能強(qiáng)大的單核CPU和部署相同數(shù)量的SWC的ECU相比，它能更有效地減輕軟件和硬件故障的影響。然而，在符合ISO 26262標(biāo)準(zhǔn)的情況下，在同一多核CPU上運(yùn)行混合關(guān)鍵性軟件需要分區(qū)機(jī)制，以防止核心之間在共享資源方面的處理干擾，包括主存儲器、通信基礎(chǔ)設(shè)施（在汽車領(lǐng)域，最常見的是CAN和LIN總線）以及數(shù)字和模擬I/O?，F(xiàn)代多核產(chǎn)品包含專用硬件，有助于實(shí)現(xiàn)這種分離，這是ISO 26262的直接支持。在核心冗余、故障報(bào)告、內(nèi)存分區(qū)、錯誤檢測和糾錯等專用硬件功能的輔助下，最終的汽車軟件可以更安全、更高效、更安全地運(yùn)行。

采用多核ECU需要考慮方方面面，最重要的是遷移和調(diào)度策略。絕大多數(shù)情況下，將看到為單核ECU構(gòu)建的單體、經(jīng)過驗(yàn)證的傳統(tǒng)應(yīng)用程序的遷移，有些是將軟件原封不動地遷移到其中一個核心上，或者將軟件重新設(shè)計(jì)成（也許是并行的）任務(wù)，按照時間表在單個核心或幾個核心上同時運(yùn)行。分區(qū)調(diào)度可以應(yīng)用于第一種情況，即任務(wù)被靜態(tài)地分配到一個核心，而不能在另一個內(nèi)核上執(zhí)行。在第二種情況下，可以使用帶有任務(wù)重定位的全局調(diào)度，在這種情況下，可以通過將任務(wù)轉(zhuǎn)移到內(nèi)核上而動態(tài)地加載未被充分利用的內(nèi)核。第一個遷移策略一般是可行的，因?yàn)槟壳岸嗪水a(chǎn)品的單個內(nèi)核比早期的單核ECU功能更強(qiáng)大。在第二種情況下，現(xiàn)代汽車CPU內(nèi)核相對較高的性能能力足以抵消內(nèi)核間通信、任務(wù)同步和任務(wù)調(diào)度的額外計(jì)算負(fù)荷。如同在其他依賴計(jì)算的領(lǐng)域一樣，在汽車領(lǐng)域，通過適當(dāng)?shù)牟⑿熊浖こ袒蛘邔纹浖匦略O(shè)計(jì)為并行任務(wù)，可以最好地發(fā)揮并行計(jì)算的作用。在這種情況下，必須盡量減少任務(wù)間的通信，從而使跨核通信保持在最低限度，并且調(diào)度必須使內(nèi)核得到最大限度的利用，同時確保任務(wù)優(yōu)先、相互排斥以及各任務(wù)的時間限制。汽車行業(yè)正在應(yīng)對這些挑戰(zhàn)，以便從ECU的并行計(jì)算中獲得最大利益。

另一個有希望開發(fā)強(qiáng)大的領(lǐng)域、跨域和區(qū)域控制器的平臺是眾核CPU。眾合CPU的內(nèi)核數(shù)量較多，從幾十到幾千，而且對CPU進(jìn)行了并行處理的優(yōu)化。這些內(nèi)核通常通過片上網(wǎng)絡(luò)（NoC）連接，與傳統(tǒng)的基于總線或基于環(huán)的多核系統(tǒng)配置相比，它提供了更多可擴(kuò)展的解決方案。與多核CPU相比，眾核CPU具有一些優(yōu)勢；特別是，它們尤其1適合于計(jì)算密集型的應(yīng)用。

域控制器需要進(jìn)行大量處理，因此往往需要硬件加速器，如人工智能應(yīng)用的加速器、密碼學(xué)加速器和線性代數(shù)加速器。例如，恩智浦的S32S24平臺有三個硬件加速器，其中包括一個硬件安全引擎（HSE），能提供加密算法、散列和隨機(jī)數(shù)生成等安全支持。AURIX TC3xx還利用了密碼學(xué)加速器。一般來說，硬件供應(yīng)商會通過專用的快速硬件實(shí)現(xiàn)加密操作、安全密鑰存儲、安全通信網(wǎng)關(guān)、網(wǎng)絡(luò)總線信息驗(yàn)證和入侵檢測來提供安全功能。以上這些功能都可以在軟件中執(zhí)行，但硬件加速可以實(shí)現(xiàn)量級提速。硬件加速器通常利用圖形處理單元（GPU）、數(shù)字信號處理器（DSP）和現(xiàn)場可編程門陣列（FPGA）。前面提到的駕駛艙域控制器Visteon SmartCore，在單個片上系統(tǒng)（SoC）上實(shí)現(xiàn)，它載有高通Adreno GPU和高通Hexagon DSP，可用于計(jì)算機(jī)繪圖。GPU也被用于現(xiàn)有ADAS解決方案的各種應(yīng)用中，包括行人檢測、線路跟蹤和路徑規(guī)劃。FPGA在現(xiàn)代ECU中有很多應(yīng)用，包括包括在發(fā)動機(jī)控制單元中的應(yīng)用，用于并行采集發(fā)動機(jī)數(shù)據(jù)和與其他子系統(tǒng)的接口；激光雷達(dá)信號處理和數(shù)據(jù)融合、安全網(wǎng)關(guān)、連接和用于娛樂制圖；ADAS數(shù)據(jù)聚合、傳感器融合和對象分類。

B. 虛擬化

虛擬化是支撐E/E集中化趨勢的一項(xiàng)重要技術(shù)。幾十年，虛擬化軟件和多核計(jì)算平臺相輔相成。在嵌入式汽車領(lǐng)域中，避免干擾和簡單軟件集成的需求等因素也推動了這種共生關(guān)系。在本節(jié)中，我們將描述驅(qū)動在多核汽車ecu上采用虛擬化的因素，并試圖演示為什么虛擬化的便利使其成為集中化的必然選擇。

如圖5所示，一個虛擬化系統(tǒng)由一層虛擬機(jī)（VM，軟件）和一個虛擬機(jī)監(jiān)視器（VMM，也是軟件）組成，在物理機(jī)主機(jī)（硬件）上運(yùn)行。虛擬機(jī)是一種通過模擬物理機(jī)來封裝和執(zhí)行其他軟件的軟件。被執(zhí)行的軟件可以是一個單一的程序，也可以是一個完整的操作系統(tǒng)(OS)，按照通常的方式執(zhí)行任務(wù)。VMM是一個中間軟件層，用于在虛擬機(jī)之間劃分處理、內(nèi)存和通信資源，并將同時運(yùn)行的虛擬機(jī)調(diào)度和遷移到不同的資源上。與嵌入式汽車應(yīng)用程序相關(guān)的VMM被稱為hypervisor。它們直接在ECU處理器上運(yùn)行，可以看作是虛擬機(jī)的操作系統(tǒng)，其中它的“任務(wù)”就是虛擬機(jī)本身。

虛擬化的一個主要用途是整合需要不同操作系統(tǒng)，以及相同操作系統(tǒng)的不同版本的ECU功能，如圖6所示。例如，可能有必要將一個ECU的遺產(chǎn)軟件（應(yīng)用程序和操作系統(tǒng)）與另一個ECU（例如符合AUTOSAR標(biāo)準(zhǔn)的ECU）的軟件并排使用。這種整合有幾個好處。復(fù)用遺產(chǎn)ECU軟件可以降低成本和上市時間，因?yàn)檫z產(chǎn)軟件是已經(jīng)經(jīng)過驗(yàn)證的。

但是，由于功能干擾，如果不使用專門的隔離機(jī)制，不同的操作系統(tǒng)以及同一操作系統(tǒng)的不同版本的共存，是一個非常難以管理的問題。將需要不同操作系統(tǒng)或操作系統(tǒng)版本的應(yīng)用程序隔離在虛擬機(jī)內(nèi)，可以完全消除這個問題。每個應(yīng)用程序都會收到它所需要的操作系統(tǒng)，并且由于在虛擬機(jī)內(nèi)的隔離，它們不“知道”其他操作系統(tǒng)的存在。

汽車行業(yè)的另一個常見場景是混合關(guān)鍵性ECU的整合，如圖6所示。ISO 26262要求，保證整合后的功能不受干擾，如一個SWC的故障（例如，設(shè)計(jì)或?qū)崿F(xiàn)缺陷，或由于硬件失效導(dǎo)致的故障）不會傳播到部署在同一ECU的其他更高ASILs的SWC。在傳統(tǒng)的設(shè)置中，當(dāng)這種故障表現(xiàn)在一個ECU上時，它對其他SWC的影響會因?yàn)镋CU的物理分離而降到最低。例如，故障的SWC不能覆蓋不同ECU上的SWC的內(nèi)存。確保SWC之間免受這些影響的唯一途徑是ECU之間的通信鏈路。實(shí)現(xiàn)這一目標(biāo)的成熟方法已經(jīng)存在，例如在通信鏈路上檢測畸形數(shù)據(jù)的傳輸。但在集中式設(shè)置中，這種物理分離消失了，不同ECU的功能被整合到一個ECU上。根據(jù)ISO 26262，要合并兩個具有不同ASIL要求的功能的ECU，例如ASIL D和ASIL A，這兩個功能必須按照ASIL D的要求開發(fā)，或者必須使用按照ASIL D要求開發(fā)的機(jī)制，以保證兩個功能之間不會有干擾。

虛擬化是解決這些困難的一個完美方案。不同的遺產(chǎn)SWC可以并排部署在單個ECU的虛擬機(jī)內(nèi)。由于虛擬化促進(jìn)了遺產(chǎn)軟件的遷移，異構(gòu)軟件可以被整合，而VM內(nèi)部的隔離消除了不同版本的軟件和操作系統(tǒng)共存的擔(dān)憂。每個虛擬機(jī)都可以使用最合適的操作系統(tǒng)，而VMM提供了所需的免受虛擬機(jī)之間干擾的自由。例如，偉世通的SmartCore DCU實(shí)現(xiàn)了一個集成式數(shù)字駕駛艙（在第二節(jié)D部分中介紹過），它使用一個hypervisor來集成在Linux上運(yùn)行的非ASIL信息娛樂領(lǐng)域和ASIL B儀器集群領(lǐng)域。用于嵌入式應(yīng)用的Hypervisor通常是按照ASIL D要求開發(fā)的，所以它們是符合ISO 26262標(biāo)準(zhǔn)的軟件功能集成的COTS解決方案。最后，虛擬化足夠靈活，可以促進(jìn)構(gòu)建靈活的、可擴(kuò)展的體系架構(gòu)，在ECU之間遷移SWC才是可行的。

虛擬化第一次被證明是整合企業(yè)IT基礎(chǔ)設(shè)施上的異構(gòu)軟件的可行解決方案。然后，該技術(shù)在21世紀(jì)初被作為航空系統(tǒng)的集中化使能技術(shù)。

現(xiàn)在，市場上的hypervisor，其中許多已經(jīng)在航空航天、國防和醫(yī)療領(lǐng)域的安全關(guān)鍵應(yīng)用中取得了巨大的成功，正在推動采用虛擬化成為汽車E/E架構(gòu)中的首選集成方案。通用動力公司（General Dynamics)和風(fēng)河系統(tǒng)公司(Wind River Systems)等航空航天和國防領(lǐng)域的老牌供應(yīng)商，都在提供非常適合汽車應(yīng)用的關(guān)鍵任務(wù)管理程序（hypervisor）。

虛擬化技術(shù)有幾個局限性。首先，實(shí)時性能通常是不可預(yù)測的，因?yàn)樘摂M化可以導(dǎo)致在兩個級別上進(jìn)行調(diào)度，即管理（hypervisor）級別和虛擬機(jī)級別。解決這一限制的一種方法是將 VM 靜態(tài)分配到內(nèi)核。其次，虛擬機(jī)利用了相當(dāng)可觀的內(nèi)存資源。第三， ECU 外設(shè)（例如 CAN 總線）的虛擬化是一個需要進(jìn)一步研究的復(fù)雜問題。第四，hypervisor必須保持較小規(guī)模，以確保安全、可靠和無 bug ，以便在用作 SEooC 時能夠開發(fā)到最高的ASIL級別。最后，在過去，ECU 中對虛擬化的硬件支持有限。不過，隨著汽車 CPU 中硬件虛擬化支持的引入，這種情況目前正在得到改善。這些擴(kuò)展基于 ARM 內(nèi)核的 CPU，加速了虛擬化環(huán)境的執(zhí)行。比如來自NXP，英飛凌和德州儀器都包括硬件虛擬化支持。

虛擬化對工業(yè)界和學(xué)術(shù)界都是一個重大機(jī)遇。對于工業(yè)界來說，它為所有汽車制造商面臨的難題提供了現(xiàn)成的解決方案；對于學(xué)術(shù)界來說，它提供了新的方法，將日益復(fù)雜的汽車系統(tǒng)的開發(fā)方法與 ISO 26262 等標(biāo)準(zhǔn)的要求相結(jié)合。在這兩種情況下，虛擬化都是不可或缺的支持技術(shù)。因此，我們預(yù)計(jì)航空行業(yè)的故事將會重演，虛擬化將是未來汽車行業(yè)標(biāo)準(zhǔn)遵從的首選技術(shù)。

C. 聯(lián)網(wǎng)

傳統(tǒng)上， CAN 總線一直被用作車載連接的實(shí)際標(biāo)準(zhǔn)。CAN 總線是用于互連車輛內(nèi)部 ECU 的串行總線。隨著車輛功能及其產(chǎn)生的數(shù)據(jù)流量的日益復(fù)雜，CAN 網(wǎng)絡(luò)越來越不適合未來的 E/E 架構(gòu)，因?yàn)樗鼈兊臄?shù)據(jù)速率限制為每秒1mb。CAN FD (flexible data rate靈活數(shù)據(jù)速率)和汽車以太網(wǎng)可用于替代在不同領(lǐng)域的CAN 總線。

CAN FD的特點(diǎn)為動力總成領(lǐng)域（如混合動力和全電動驅(qū)動）、車身領(lǐng)域（如與舒適性相關(guān)的先進(jìn)車身部件）和底盤領(lǐng)域（不包括駕駛輔助子領(lǐng)域）的先進(jìn)功能提供了必要的性能升級。這些特點(diǎn)包括幾乎為6 Mbit/s的實(shí)際最大數(shù)據(jù)速率，具有64個字節(jié)的數(shù)據(jù)字段的數(shù)據(jù)包（相對于CAN的8個字節(jié)的數(shù)據(jù)字段），與傳統(tǒng)的CAN系統(tǒng)向后兼容，并且功耗低。將現(xiàn)有的網(wǎng)絡(luò)從CAN轉(zhuǎn)換到CAN FD可以大大減少總線負(fù)載，允許在可接受的延遲情況下傳輸更多的數(shù)據(jù)。但是，由于在信號級別與 CAN 相同，我們可以預(yù)測在最大節(jié)點(diǎn)數(shù)和最大電纜長度方面有類似的限制。事實(shí)上，盡管作者無法找到任何具有支持性的實(shí)驗(yàn)證據(jù)，但可以推斷出，對于較高的CAN FD數(shù)據(jù)速率來說，最大的電纜長度要和CAN相比明顯減少，這一因素對于某些制造商和某些應(yīng)用來說可能是不可接受的。更重要的是，CAN FD作為現(xiàn)代和未來軟件定義的汽車所需要的網(wǎng)絡(luò)技術(shù)，本質(zhì)上是不能夠通用的。在這些應(yīng)用中，服務(wù)導(dǎo)向成為主導(dǎo)的軟件范例。預(yù)定義服務(wù)的集成，以及在車輛制造時未知的服務(wù)——電話、音樂播放器、健身追蹤器等個人小工具，以及與交通基礎(chǔ)設(shè)施的整合--需要數(shù)據(jù)速率和功能分離、帶寬預(yù)留、安全等方面的多功能，而CAN FD無法提供。在一定的復(fù)雜程度之上，仍然需要更快、更可靠和更通用的通信技術(shù)，例如汽車以太網(wǎng)，以便為不同的汽車應(yīng)用提供更高的帶寬，包括ADAS領(lǐng)域和信息娛樂領(lǐng)域。

汽車以太網(wǎng)是指在車輛中使用的基于以太網(wǎng)的通信方案，在信號級別上與原始以太網(wǎng)完全不同。汽車以太網(wǎng)提供了一個輕量級和具有成本效益的通信媒介，它使用單一非屏蔽雙絞線。100 Mbit/s和1000 Mbit/s的通信數(shù)據(jù)率很常見，IEEE 802.3ch-2020規(guī)定的最大數(shù)據(jù)率為2.5、5和10 Gbit/s。IEEE P802.3cy工作組正在制定25、50和100 Gbit/s的規(guī)格。與傳統(tǒng)的汽車現(xiàn)場總線相比，高數(shù)據(jù)率是汽車以太網(wǎng)的一個顯著優(yōu)勢。事實(shí)上，由于未來的自動駕駛汽車估計(jì)會產(chǎn)生4TB/h的數(shù)據(jù)量，市場專家相信，全面采用汽車以太網(wǎng)是不可避免的。然而，由于它是一種相對較新的技術(shù)，文獻(xiàn)似乎還沒有反映出一套既定的基于汽車以太網(wǎng)的車載網(wǎng)絡(luò)物理層的設(shè)計(jì)原則。目前的研究正在揭示這種網(wǎng)絡(luò)技術(shù)的電磁兼容性和信號質(zhì)量特性，這是物理層設(shè)計(jì)的基礎(chǔ)。此外，開放聯(lián)盟提供了幾個測試規(guī)范，可用于汽車以太網(wǎng)應(yīng)用的物理層面。為了支持高帶寬和低延遲的實(shí)時車載通信，聯(lián)盟已經(jīng)制定了一套標(biāo)準(zhǔn)，即TSN（Time-Sensitive Networking時間敏感網(wǎng)絡(luò)）標(biāo)準(zhǔn)。TSN標(biāo)準(zhǔn)擴(kuò)展了AVB（音頻視頻橋接）標(biāo)準(zhǔn)，通過以太網(wǎng)提供時間敏感的通信。時鐘同步是滿足系統(tǒng)級實(shí)時性要求的關(guān)鍵。在日益復(fù)雜的車輛中，嚴(yán)格的實(shí)時要求，即如果在E/E系統(tǒng)運(yùn)行時，違反這些要求將對功能安全造成嚴(yán)重后果，這些要求將必然依賴于網(wǎng)絡(luò)性能的時間保證。實(shí)例包括ADAS和 'by-wire'系統(tǒng)。TSN的IEEE 802.1AS-2020標(biāo)準(zhǔn)規(guī)定了跨以太網(wǎng)的時間同步機(jī)制。它定義了一個在網(wǎng)絡(luò)中分配時基的主控器，以保證所有組件遵循相同的全局時鐘，但也允許在同一個網(wǎng)絡(luò)中運(yùn)行多個不同的時域。此外，該標(biāo)準(zhǔn)還定義了同步時間的傳輸。該標(biāo)準(zhǔn)的時鐘同步協(xié)議是IEEE 1588-2008定義的精確時間協(xié)議的變體。

實(shí)例包括ADAS和 'by-wire '系統(tǒng)。TSN的IEEE 802.1AS-2020標(biāo)準(zhǔn)規(guī)定了跨以太網(wǎng)的時間同步機(jī)制。它定義了一個在網(wǎng)絡(luò)中分配時基的主控器，以保證所有組件遵循相同的全局時鐘，但也允許在同一個網(wǎng)絡(luò)中運(yùn)行多個不同的時域。此外，該標(biāo)準(zhǔn)還定義了同步時間的傳輸。該標(biāo)準(zhǔn)的時鐘同步協(xié)議是IEEE 1588-2008定義的精確時間協(xié)議的變體。

TSN標(biāo)準(zhǔn)IEEE 802.1Q-2018提供了有界限的低延遲。幾個不同的流量類別被定義為基于優(yōu)先級的。然后，該標(biāo)準(zhǔn)為以太網(wǎng)幀的傳輸定義了兩種調(diào)度機(jī)制：嚴(yán)格的優(yōu)先權(quán)和基于信用的整形器。第三種調(diào)度算法也被定義為TAS（Time Aware Shaper時間感知整形器），它使用時分多址（TDMA）方案確定性地調(diào)度幀，使時間關(guān)鍵的幀在每個時間段的時間窗口內(nèi)享有獨(dú)家傳輸權(quán)。為了使最高關(guān)鍵性的幀獲得更低的延遲，建議采用幀搶占的方式，即較低優(yōu)先級的幀被中斷和分割，從而使高關(guān)鍵性的幀能夠盡早被發(fā)送。

IEEE 802.1Q-2018還定義了執(zhí)行網(wǎng)絡(luò)工作流控制和監(jiān)控的措施。例如，該標(biāo)準(zhǔn)規(guī)定了如何通過限制某些端口的允許入口帶寬來避免通信網(wǎng)絡(luò)的過載。對于容錯，IEEE 802.1CB-2017 TSN標(biāo)準(zhǔn)規(guī)定了冗余措施以保證車輛網(wǎng)絡(luò)內(nèi)的容錯。該標(biāo)準(zhǔn)定義了識別和復(fù)制數(shù)據(jù)包的方法，以及識別其他重復(fù)的數(shù)據(jù)包并消除它們的方法。然而，該標(biāo)準(zhǔn)并沒有定義數(shù)據(jù)包的冗余路徑。相反，IEEE 802.1Q-2018定義了在網(wǎng)絡(luò)上配置多條路徑以提供冗余性的方法。IEEE 802.1Q-2018和IEEE 802.1CB-2017 TSN標(biāo)準(zhǔn)結(jié)合在一起，可以被用來進(jìn)行動態(tài)網(wǎng)絡(luò)配置。動態(tài)網(wǎng)絡(luò)配置的能力對于支持未來的車輛網(wǎng)絡(luò)，通過FOTA（空中下載固件）和SOTA（空中下載軟件）實(shí)現(xiàn)軟件更新至關(guān)重要。例如，添加一個需要增加以太網(wǎng)鏈路帶寬的新功能時，將需要用到此功能。此外，將采用動態(tài)網(wǎng)絡(luò)配置替代靜態(tài)的手工網(wǎng)絡(luò)配置，以有效地處理車輛產(chǎn)品線中越來越多不同變體的網(wǎng)絡(luò)配置。

總的來說，TSN標(biāo)準(zhǔn)旨在提供網(wǎng)絡(luò)性能的基本保證（延遲的界限、帶寬預(yù)留、流量分離等），這是實(shí)現(xiàn)任務(wù)和安全關(guān)鍵要求的先決條件。另一個協(xié)議，時間觸發(fā)以太網(wǎng)（TTEthernet），是SAE AS6802標(biāo)準(zhǔn)，定義了支持確定性、實(shí)時通信和功能安全相關(guān)應(yīng)用的機(jī)制。例如，該標(biāo)準(zhǔn)通過將一個物理通信通道劃分為獨(dú)立的子通道來支持功能安全，這些子通道不受邏輯和時間干擾，從而避免了故障傳播。

與 TSN 一樣，TTEthernet 需要為三種流量（包括時間關(guān)鍵流量）中的每一種流量分配一個靜態(tài)定義的時隙時間表，以保證傳輸時間。在這兩種情況下，必須離線解決時間表，例如通過SMT技術(shù)解決。但與TSN不同的是，必須解決所有涉及的交通類別和路線的時間表。相比之下，在 TSN 的情況下，必須只為時間關(guān)鍵流解決時間表，而其他流量則通過各種機(jī)制盡力而為。但是，也可能通過在解決時間關(guān)鍵性的流量計(jì)劃的同時考慮到非關(guān)鍵流量，來優(yōu)化所有流量。由于并非車輛應(yīng)用程序中的所有流程都是時間關(guān)鍵的，因此完全基于TTEthernet的車輛模型的變體可能需要解決比完全基于TSN的車輛模型的不同的網(wǎng)絡(luò)配置更多的調(diào)度。在車輛型號頻繁變化，并且伴隨著車輛變型的情況下，TSN也許比TTEthernet提供了更高的靈活性。

雖然下一代架構(gòu)將巧妙地混合使用 CAN、CAN FD、LIN、FlexRay 和以太網(wǎng)技術(shù)，但許多汽車制造商已經(jīng)在量產(chǎn)車輛中使用以太網(wǎng)，和/或計(jì)劃使用以太網(wǎng)主干。事實(shí)上，通過實(shí)時和安全擴(kuò)展（如AVB、TSN和TTEthernet）適當(dāng)擴(kuò)展的汽車以太網(wǎng)，正在成為域間通信的最優(yōu)解決方案。通過實(shí)時擴(kuò)展，汽車以太網(wǎng)也完美地適用于與智能執(zhí)行器的域內(nèi)通信，如電動馬達(dá)控制和SONAR/雷達(dá)/激光雷達(dá)傳感系統(tǒng)，在這種情況下，必須滿足時序保證。此外，我們預(yù)計(jì)，車輛將越來越多地被要求與智能交通系統(tǒng)集成，實(shí)時通信的要求將越來越嚴(yán)格，因?yàn)殛P(guān)于車輛如何與環(huán)境通信的規(guī)定變得更加苛刻。這將對車載網(wǎng)絡(luò)技術(shù)提出了額外的要求，以便在未來擴(kuò)大規(guī)模，滿足這一需求。

D. AUTOSAR

集中化E/E架構(gòu)需要在軟件架構(gòu)層面的適當(dāng)支持。汽車行業(yè)一直在逐步遵守包括AUTOSAR在內(nèi)的幾個標(biāo)準(zhǔn)。AUTOSAR標(biāo)準(zhǔn)化的趨勢有幾個優(yōu)勢，所有這些優(yōu)勢都與E/E集中化的目標(biāo)相一致，如促進(jìn)來自不同供應(yīng)商的部件集成，不同的車輛項(xiàng)目和平臺的組件重用，以及以系統(tǒng)的方式控制故障。在這一節(jié)中，我們重點(diǎn)討論AUTOSAR為集中式架構(gòu)提供的支持。

AUTOSAR（汽車開放系統(tǒng)架構(gòu)）提供了一個用于開發(fā)汽車嵌入式系統(tǒng)的框架。該標(biāo)準(zhǔn)由一個由OEM制造商、供應(yīng)商和廠商組成的聯(lián)盟開發(fā)，目的是促進(jìn)車輛軟件的可移植性和可組合性。AUTOSAR的軟件架構(gòu)定義了在ECU上執(zhí)行的三個軟件層，如圖7所示。這些層分別是應(yīng)用層、運(yùn)行時環(huán)境（RTE）和基本軟件（BSW）。應(yīng)用層以獨(dú)立于硬件的SWC的形式實(shí)現(xiàn)ECU的功能，這些SWC可以執(zhí)行車輛功能或傳感器/執(zhí)行器功能。RTE是架構(gòu)的通信媒介，即SWC通過RTE與其他SWC（在同一或不同的ECU上）以及BSW模塊進(jìn)行通信。RTE是網(wǎng)關(guān)，車輛應(yīng)用軟件通過它訪問ECU的功能以實(shí)現(xiàn)其目標(biāo)。這些功能在BSW中通過幾個抽象層實(shí)現(xiàn)（圖7），成為應(yīng)用軟件可以使用的服務(wù)。BSW的最上層、最抽象的一層是服務(wù)層，它為應(yīng)用程序、RTE和BSW模塊提供服務(wù)。這些服務(wù)包括系統(tǒng)服務(wù)，如操作系統(tǒng)，一個是可以被所有模塊使用的功能。在抽象譜的另一端是微控制器抽象層（MCAL），這是BSW的最低層。它由直接訪問微控制器和外設(shè)的驅(qū)動程序組成。這一層是針對硬件的。

圖 7. AUTOSAR 的分層軟件架構(gòu)

AUTOSAR的分層結(jié)構(gòu)通過將車輛SWC與硬件平臺分離來支持集中化，有效地提高了軟件的模塊化和復(fù)用性，軟件的模塊化和復(fù)用性又反過來促進(jìn)了集中化在E/E架構(gòu)中部署和重新定位到不同的ECU。因此，我們認(rèn)為AUTOSAR是集中化的重要軟件架構(gòu)支柱，也是可以解決一直困擾汽車行業(yè)的可擴(kuò)展性問題的E/E架構(gòu)方案。

關(guān)于功能安全，AUTOSAR定義了便于檢測和處理故障的機(jī)制，以確保在符合AUTOSAR的ECU中為SWC提供無干擾的執(zhí)行環(huán)境，這是符合ISO 26262的必要條件。對于軟件來說，內(nèi)存分區(qū)就是這樣一個功能，不同的操作系統(tǒng)應(yīng)用程序被限制訪問隔離的內(nèi)存分區(qū)，以幫助執(zhí)行應(yīng)用程序之間的功能分離。然后，應(yīng)用程序的內(nèi)存訪問由內(nèi)存分區(qū)機(jī)制監(jiān)控，該機(jī)制最好放在操作系統(tǒng)中。操作系統(tǒng)可以完全在特權(quán)模式下運(yùn)行，也可以被拆分，這樣只有與安全相關(guān)的函數(shù)才能在特權(quán)模式下運(yùn)行。除了內(nèi)存分區(qū)，AUTOSAR中的定時保護(hù)允許操作系統(tǒng)對定時故障作出反應(yīng)，并采取預(yù)定義的行動，以實(shí)現(xiàn)應(yīng)用程序之間的時間分離（即避免定時故障的傳播）。邏輯監(jiān)督機(jī)制也可用于監(jiān)控軟件的控制流，確保其正確執(zhí)行。最后，端到端的通信保護(hù)機(jī)制可以用來處理操作系統(tǒng)應(yīng)用程序或ECU之間的錯誤信號傳輸。

AUTOSAR通過診斷機(jī)制（如核心和RAM測試）支持硬件的功能安全。內(nèi)核測試檢測ECU的處理單元中可能會引發(fā)不正確輸出的故障，例如算術(shù)邏輯單元中的故障。RAM測試可以檢測出可能破壞ECU易失性存儲器的故障。這些測試在現(xiàn)代汽車級CPU中具有完備的硬件支持。

為了支持安保性，AUTOSAR定義了安全車載通信（SecOC）模塊，這是一個BSW模塊，為汽車網(wǎng)絡(luò)內(nèi)的敏感數(shù)據(jù)傳輸提供認(rèn)證機(jī)制。此外，AUTOSAR定義了加密抽象庫（CAL）和加密服務(wù)管理器（CSM），以支持加密服務(wù)。

雖然AUTOSAR最初是為單核ECU開發(fā)的，但后來通過解決BSW在不同內(nèi)核上的分配（即BSW的并行化），該標(biāo)準(zhǔn)被擴(kuò)展到支持多核ECU。然而，標(biāo)準(zhǔn)中沒有涉及應(yīng)用層中SWC的并行化問題。關(guān)于SWCs并行化的研究有限，有的在高層討論并行化過程(例如Macher等人的工作)，有的在沒有將其應(yīng)用于現(xiàn)實(shí)世界的AUTOSAR系統(tǒng)的情況下進(jìn)行了具體的研究。

行業(yè)向集中式E/E架構(gòu)的轉(zhuǎn)變，往往需要將已經(jīng)驗(yàn)證的AUTOSAR順序應(yīng)用遷移到現(xiàn)代多核平臺上。這種遷移面臨幾個挑戰(zhàn)。首先，AUTOSAR中的每個SWC都由可運(yùn)行項(xiàng)組成，可運(yùn)行項(xiàng)必須映射到任務(wù)，而這些任務(wù)又將被分配到內(nèi)核中?？蛇\(yùn)行任務(wù)到任務(wù)的映射和任務(wù)分配到內(nèi)核的工作需要同時進(jìn)行，以避免過多的跨核通信，同時保持系統(tǒng)的約束（如優(yōu)先權(quán)約束）。其次，AUTOSAR的BSW的服務(wù)層中的系統(tǒng)服務(wù)（圖7）是為單核ECU設(shè)計(jì)的。如前所述，系統(tǒng)服務(wù)是所有AUTOSAR層內(nèi)的所有模塊都可以使用的輔助功能（例如，操作系統(tǒng)）。因此，遷移到多核ECU可能需要調(diào)整這些系統(tǒng)服務(wù)，以支持在不同分區(qū)上運(yùn)行的相同BSW模塊的不同場景。另外，在應(yīng)用層面的并行化也是一項(xiàng)相當(dāng)具有挑戰(zhàn)性的任務(wù)。為了應(yīng)對這些挑戰(zhàn)，未來應(yīng)該需要定義并行設(shè)計(jì)模式，并為映射、調(diào)度、同步和通信提供指導(dǎo)。

許多汽車OEM已經(jīng)明確表態(tài)會將其軟件遷移到AUTOSAR，這是一個巨大的工程。但是，當(dāng)OEM正在向本文所述的AUTOSAR版本（稱為AUTOSAR '經(jīng)典'版）過渡時，AUTOSAR聯(lián)盟正在致力開發(fā)另一個AUTOSAR平臺，以精確滿足汽車功能不斷增加的復(fù)雜性和多樣性對汽車E/E架構(gòu)的要求，特別是高帶寬應(yīng)用，如ADAS和高度自動駕駛、信息娛樂以及V2X連接。其成果是2017年發(fā)布的AUTOSAR '自適應(yīng) '標(biāo)準(zhǔn)。AUTOSAR自適應(yīng)標(biāo)準(zhǔn)轉(zhuǎn)向了面向服務(wù)的架構(gòu)，其中服務(wù)和客戶端在ECU運(yùn)行時動態(tài)鏈接。