1.引言

現(xiàn)代道路車輛的復(fù)雜性與日俱增。為了保持競爭力，汽車必須滿足客戶對功能和性能的期望，而這些期望本身又與連接性、電氣化、泛在技術(shù)、通信、即時訪問等趨勢息息相關(guān)。這種趨勢增加了車輛的復(fù)雜性，并反過來推動汽車E/E（電動和/或電子）架構(gòu)的演變，從傳統(tǒng)的基于總線的分散式架構(gòu)，由幾十個ECU（電子控制單元）組成，發(fā)展到集中式架構(gòu)。集中式架構(gòu)由車輛領(lǐng)域（域控制架構(gòu)）或域組（跨域架構(gòu)）專用的計算集群組成，并由一個強(qiáng)大的ECU獨(dú)立控制。

集中式架構(gòu)還包括區(qū)域架構(gòu)，在區(qū)域架構(gòu)中，車輛級別的單個計算機(jī)集群可以實現(xiàn)車輛的主要功能。在本文中，我們主要考慮了域和跨域的架構(gòu)。域和跨域架構(gòu)利用強(qiáng)大的、價格相對較高的頂級ECU，分別稱為域控制器（DC）或跨域控制器（CDC），而控制域的其他ECU，本身相對便宜。在本文中，我們將使用DC來表示域控制器和跨域控制器。

在每個領(lǐng)域（或域的組合）中，DC是最要緊的單點失效。因此，當(dāng)一個車輛領(lǐng)域僅由一個強(qiáng)大的DC控制時，最大的擔(dān)憂之一是在該控制器完全丟失的情況下會發(fā)生什么。更確切地說，我們更關(guān)心的是DC的不可恢復(fù)的故障，如功率損失、液體進(jìn)入DC等。

在DC中，通常會實現(xiàn)許多功能安全的概念和功能，如E-Gas監(jiān)測概念、鎖步核等。但是這些機(jī)制并不能解決諸如DC內(nèi)所有微控制器或者ASIC的電源損失等問題。傳統(tǒng)的功能安全方案（例如，三模冗余）可以用來解決此類故障，但它們涉及到ECU層面的DC冗余，這會增加成本以及空間和電力需求。因此，我們尋求其他選擇來處理DC的災(zāi)難性故障，這些選擇可以與DC運(yùn)行時已實施的安全規(guī)定結(jié)合起來使用。

在本文中，我們提出了一種安全架構(gòu)，專門針對這種情況，我們認(rèn)為這種架構(gòu)可以最大限度地減少與功能安全專用硬件相關(guān)的成本，并充分利用集中式架構(gòu)的基本通用性。我們建議，在DC發(fā)生災(zāi)難性故障的場景中，應(yīng)該在受影響領(lǐng)域內(nèi)剩余的ECU中實施一個分布式控制方案，讓其接管故障DC的部分功能。雖然理論上這樣的方案可以實現(xiàn)DC的全部功能，但這并不是該方案的目的。在其基本功能形式中，這種后備體系結(jié)構(gòu)不需要任何其他硬件，只需要集中的領(lǐng)域中的硬件。

不可否認(rèn)的是，它增加了智能執(zhí)行器所需的計算資源，必須仔細(xì)規(guī)劃以適應(yīng)后備功能。雖然我們的架構(gòu)像經(jīng)典的安全架構(gòu)一樣利用了冗余，但它有望成為一個更經(jīng)濟(jì)的解決方案，因為它使用現(xiàn)有的硬件資源，而不是像更傳統(tǒng)的架構(gòu)那樣，依賴于冗余的ECU或微控制器的更昂貴的解決方案。據(jù)我們所知，我們提出的架構(gòu)在這方面是獨(dú)一無二的。必須指出的是，我們的提議只是涵蓋了集中式車輛領(lǐng)域完整安全架構(gòu)的一個方面。其余的，如域內(nèi)通信功能安全方面，則不在本文的討論范圍內(nèi)。

本文的其余部分結(jié)構(gòu)如下。在第Ⅱ節(jié)我們介紹了相關(guān)工作。第III節(jié)介紹了一個典型的集中式架構(gòu)。在第IV節(jié)中介紹了安全架構(gòu)。第IV節(jié)則總結(jié)了未來工作的路徑。

2.相關(guān)工作

DC的損失問題可以通過利用經(jīng)典的硬件冗余方案來解決。例如，MooN（M-out-of-N通道架構(gòu)）是一個基于多數(shù)投票系統(tǒng)的簡單靜態(tài)冗余方案。這種架構(gòu)的一個廣泛使用的實例是2-out-of-three（2oo3）通道架構(gòu)，也被稱為三模冗余（TMR），三個獨(dú)立模塊計算輸出，然后多數(shù)投票系統(tǒng)產(chǎn)生一個輸出。TMR架構(gòu)在各個行業(yè)都很適用，包括汽車行業(yè)（例如，Sari和Reuss的工作成果）。

當(dāng)然還存在其他通用的硬件冗余方案，其中一個模塊提供輸出，一個故障檢測單元檢測模塊是否出現(xiàn)故障。在檢測到故障模塊后，系統(tǒng)會進(jìn)行重新配置，以切換到健康單元。例如，由兩個雙工（1oo2或2oo2）系統(tǒng)組成的duo-duplex架構(gòu)，被用于汽車的線控驅(qū)動系統(tǒng)，以及諸如空中客車公司等的航空電子設(shè)備。兩個版本的duo-duplex架構(gòu)，對稱2oo2DFS和非對稱2oo2DFS，已經(jīng)被用于汽車底盤領(lǐng)域。

這些方案的基礎(chǔ)都是經(jīng)典硬件冗余。同樣的方法也可以用于保障汽車應(yīng)用中DC的容錯和功能安全。換句話說，先前簡單討論過的冗余方案同樣可以應(yīng)用于集中式E/E架構(gòu)的DC，以實現(xiàn)集中式汽車領(lǐng)域的功能安全，如動力系統(tǒng)或運(yùn)動和安全。然而，雖然對于汽車、航空電子、航天等安全關(guān)鍵應(yīng)用的DC來說，硬件冗余看起來是一個可行的解決方案，但這種類型的方法不是安全關(guān)鍵應(yīng)用的普遍解決方案—主要是因為需要額外成本、額外的空間和額外功耗。對于大批量、成本敏感型的汽車應(yīng)用來說，這種類型的方法在許多情況下是非常昂貴的。此外，ISO 26262沒有明確要求上述的硬件冗余方案用于安全關(guān)鍵應(yīng)用。

一般來說，專門針對集中式E/E架構(gòu)的功能安全的工作不多，尤其是我們在本文中討論的情況。然而，還是可以找到一些參考建議的。Sommer等人提出了一個帶有以太網(wǎng)骨干網(wǎng)絡(luò)的車輛區(qū)域結(jié)構(gòu)。中央計算機(jī)集群由若干臺“車輛控制計算機(jī)”組成，這些計算機(jī)可以是雙工控制計算機(jī)(dcc)，也可以是單工控制計算機(jī)。一個DCC有兩條執(zhí)行路徑，兩條路徑上的相關(guān)輸出都被監(jiān)控和比較：如果觀察到錯誤，結(jié)果就會被丟棄，第二個冗余的DCC就會接手。此處可以有多個冗余DCC。在正好有兩個DCC的情況下，這種結(jié)構(gòu)實際上成為duo-duplex架構(gòu)。汽車以太網(wǎng)網(wǎng)絡(luò)是環(huán)形的，有兩條獨(dú)立的路徑。在這種情況下，該方法也是基于硬件冗余的。然而，汽車應(yīng)用所需要的是能夠以遠(yuǎn)低于硬件冗余的成本提供故障操作功能。

3.集中式動力系統(tǒng)E/E架構(gòu)

圖1. 集中域動力系統(tǒng)

圖1所示的集中式動力系統(tǒng)架構(gòu)是在之前提出的。這張圖展示了電動汽車動力系統(tǒng)E/E架構(gòu)的原型，但這個概念很容易擴(kuò)展到混合動力電動汽車，甚至傳統(tǒng)汽車。它是一個領(lǐng)域控制架構(gòu)，有一個強(qiáng)大的中央控制器和外圍控制器（智能執(zhí)行器）。DC實現(xiàn)了該領(lǐng)域的大部分功能，同時包含了不同車輛變體的差異性（例如，提供的功能、動力系統(tǒng)配置等方面的差異）。

另一方面，智能執(zhí)行器是一個低成本的控制器，能實現(xiàn)基本的執(zhí)行器功能。此外，該領(lǐng)域還包括一個網(wǎng)關(guān)，在DC和車輛的其他部分之間路由所有硬件信號，包括數(shù)字信號和模擬I/O信號，以及現(xiàn)場總線信號。圖1中的圖表使用以太網(wǎng)進(jìn)行域內(nèi)通信，作為一種新興的高速汽車網(wǎng)絡(luò)技術(shù)，但域內(nèi)的控制器也可以根據(jù)需要使用典型的現(xiàn)場總線(CAN、CAN FD、LIN、FlexRay)連接到DC上。域間連接（未顯示）通常是處于高速的，如汽車以太網(wǎng)。

由于E/E架構(gòu)的集中化仍處于相對早期的階段，我們有理由假設(shè)在汽車環(huán)境中，只有部分E/E架構(gòu)是集中的，比如一個或兩個域。我們的方案的設(shè)計是這樣的，它可以促進(jìn)傳統(tǒng)的分散式E/E架構(gòu)向集中式架構(gòu)，一次一個領(lǐng)域的漸進(jìn)式轉(zhuǎn)變。這可能是實驗或概念驗證工作的情況。我們用一個集中化的領(lǐng)域，即動力系統(tǒng)領(lǐng)域，來解釋集中化的想法并展示我們的方法。但我們提出的方法既可以用于完全集中的E/E架構(gòu)，也可以用于部分集中的E/E架構(gòu)。前面提到的領(lǐng)域網(wǎng)關(guān)有助于在這種混合的E/E架構(gòu)中使用我們的方法。

4.后備控制策略

在本節(jié)中，我們將介紹我們所提出的安全架構(gòu)，將其與傳統(tǒng)的安全架構(gòu)進(jìn)行比較，并討論該架構(gòu)的一些重要方面。

A. 安全架構(gòu)

我們假設(shè)一個DC的災(zāi)難性損失的情況。對于這種情況，我們提出了一個后備方案，在該方案中，關(guān)鍵的DC功能是以分布式的方式，在域內(nèi)每個可用的子域ECU或整個車輛的余量資源中實現(xiàn)的。這里的余量是指已知可供使用的ECU的資源，如未使用的RAM、閃存和空閑的CPU時間。在DC完全丟失的情況下，分散的后備實現(xiàn)將控制受影響的域，將該方案置于“故障-可操作”類別中。該方案如圖2所示。如前所述，我們專注于動力總成領(lǐng)域，但我們的建議實際上是通用的，可以用于任何安全關(guān)鍵的車輛領(lǐng)域，或跨領(lǐng)域集中的情況下的域組合。

圖2. 將后備組件分配到域ECU

圖2所示的動力系統(tǒng)域由一個DC、三個智能執(zhí)行器和該動力系統(tǒng)域與車輛其他部分之間的域網(wǎng)關(guān)組成。當(dāng)DC無響應(yīng)時，這些分布式組件可以共同協(xié)調(diào)并接管對域的控制。硬件信號通過網(wǎng)關(guān)以相同的方式進(jìn)出于實現(xiàn)的各個參與者。唯一的區(qū)別是，在這種情況下，信息不是流經(jīng)一個（DC），而是流經(jīng)多個節(jié)點（實施后備策略的智能執(zhí)行器）。網(wǎng)關(guān)必須管理這種信息的路由，由基于以太網(wǎng)的域骨干網(wǎng)絡(luò)的IP層提供所有必要的識別信息。

圖3. 域內(nèi)余量CPUC利用率示例

通常情況下，每個子域的ECU都會有一定的執(zhí)行余量（如圖3）。這種余量也存在于ECU的閃存和內(nèi)存上。這種情況通常是由于特定ECU軟件的硬件要求與市場上具有不同功能的ECU之間的不完全匹配造成的。讓我們假設(shè)部署在ECU-EM上的軟件正好需要1.5MB的閃存，最大內(nèi)存1MB的RAM和最高速度為2.5MHz的CPU。但市場上最接近的產(chǎn)品有2MB的閃存，1.5MB的RAM和最高可達(dá)2.5MHz的CPU。

對于ECU-EM的應(yīng)用，將選擇這個產(chǎn)品，可以提供上面提到的0.5MB的額外閃存，0.5MB的額外RAM和一個比要求快1.6倍的CPU。這個例子是為了強(qiáng)調(diào)這種余量的潛力，但在實踐中，即使市場上有完美適配的產(chǎn)品，通常也會選擇具有余量的ECU硬件，因為必須考慮到ECU軟件未來可能會有變化。此外，在DC失效的情況下，最大的CPU利用率可能會小于額定值，因為當(dāng)DC消失時，子域ECU不需要再履行某些功能，或者不需要達(dá)到與之相等的水平。這可以進(jìn)一步增加可用的執(zhí)行余量。

與DC相比，這些ECU相對便宜，因此，另一種情況是，設(shè)定額外的余量以適應(yīng)后備策略，這樣應(yīng)該只需要很小的邊際成本。根據(jù)子域ECU上可用的總余量，DC的全部能力可以在備用方案得到體現(xiàn)，但最有可能的是部分功能無法實現(xiàn)，即實現(xiàn)"跛行模式"功能。

域網(wǎng)關(guān)(ECU-GW)是我們的方案很重要的一部分。它將所有的硬件信號，包括I/O線，LIN，CAN等，從車輛的各個部分輸出和輸入，由于前面提到的原因，這些部分不能轉(zhuǎn)化為智能執(zhí)行器。這意味著沒有硬件I/O（模擬或數(shù)字）或LIN，或者任何其他低電平信號直接在DC和車輛硬件之間傳輸。這個網(wǎng)關(guān)是一個智能執(zhí)行器，與該領(lǐng)域中其他的智能執(zhí)行器一樣，其唯一的功能是連接不屬于智能執(zhí)行器的硬件。我們正在進(jìn)行的工作中有一個重要的例子，就是加速踏板。

在正常操作下，領(lǐng)域網(wǎng)關(guān)必須促進(jìn)DC和硬件之間的某些交互，而這些硬件是沒有被抽象為智能執(zhí)行器的。這些交互包括CAN和LIN通信計劃的執(zhí)行，模擬信號、數(shù)字信號和PWM信號的讀取和發(fā)射等。因此，域網(wǎng)關(guān)本質(zhì)上必須充當(dāng)DC和與之相連的硬件之間的信息路由器，同時總體上盡量減少引入的延遲，以確保在任何關(guān)鍵情況下都能滿足時序要求。在備用操作下，當(dāng)DC丟失時，網(wǎng)關(guān)必須促成同樣的互動，但現(xiàn)在，就網(wǎng)關(guān)而言，任何智能執(zhí)行器都可以充當(dāng)DC，因為所有這些參與者現(xiàn)在必須與DC一樣訪問硬件。當(dāng)然，這可能取決于后備軟件的分區(qū)方式，但一般來說，上述操作是符合事實的。因此，很明顯，需要一個非常嚴(yán)謹(jǐn)?shù)穆酚蓞f(xié)議來操作后備策略。初步調(diào)查顯示，這樣的協(xié)議可以在基于以太網(wǎng)的域骨干網(wǎng)的情況下實施。

我們之所以不允許除骨干以太網(wǎng)連接之外的任何連接到DC，是因為如果DC發(fā)生故障，上面提到的其他I/O連接仍然可以用于域。如果這些信號在DC故障時仍然可用，那么就有可能實施我們所提出的分散式后備策略，并且不需要任何特定的信號線的重復(fù)。盡管在這樣的體系結(jié)構(gòu)中，網(wǎng)關(guān)就像DC一樣是單點故障，但需要注意的是，網(wǎng)關(guān)機(jī)制可以在比DC本身更簡單、更便宜的ECU上實現(xiàn)。重復(fù)網(wǎng)關(guān)ECU成為解決這一缺點的經(jīng)濟(jì)而有效的安全措施。 

B. 與經(jīng)典方案的比較

本文所提出的回退策略提供了一個故障操作容錯解決方案，不需要重復(fù)DC。因此，它比基于硬件冗余的解決方案更嚴(yán)謹(jǐn)、更節(jié)能、更便宜。由于它本質(zhì)上是一個分布式架構(gòu)，它的開發(fā)可以在各方面都受益于分散式E/E架構(gòu)開發(fā)的技術(shù)水平。

另一方面，雖然硬件冗余在概念上和實踐上都很簡單，但我們提出的方法，其設(shè)計和實施基本上需要兩個平行但協(xié)同的開發(fā)工作，一個是集中式E/E架構(gòu)，另一個是疊加在其上的分散式后備方案。由于我們所提議的備用方案是分散式的，因此必須謹(jǐn)慎設(shè)計，使其保持簡單，并且在不同車型之間不輕易發(fā)生變化，以避免集中化所面對的首要問題。由功能安全分析可知，由于在后備方案中不太可能需要DC的全部功能，因此必須實現(xiàn)最小的功能集。

5.結(jié)論

在本文中，我們提出了一個關(guān)于集中式E/E架構(gòu)的安全模式的早期建議。為了了解該方法的適用性，還需要進(jìn)一步分析和評估，作者正在就幾個方面進(jìn)行研究。例如，必須根據(jù)ISO 26262標(biāo)準(zhǔn)對智能執(zhí)行器控制器和控制軟件同時執(zhí)行的備用元素進(jìn)行分區(qū)。

盡管存在諸如虛擬化等商業(yè)解決方案，但可能一個更簡單的定制分區(qū)方案就足夠了。同樣與標(biāo)準(zhǔn)有關(guān)的是，該方案引入了使用ASIL分解，以減少中心化領(lǐng)域的開發(fā)工作和成本。必須開發(fā)切換到后備控制方案的決斷、同步和重新配置邏輯。在我們的示例中，域網(wǎng)關(guān)是一個必要的設(shè)計元素，但考慮到它在后備策略設(shè)計中的關(guān)鍵作用，我們將進(jìn)一步研究如何使用這種網(wǎng)關(guān)作為集中式E/E架構(gòu)設(shè)計的原則。