1.引言

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

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

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

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

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

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

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

2.相關工作

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

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

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

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

3.集中式動力系統E/E架構

圖1. 集中域動力系統

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

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

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

4.后備控制策略

在本節中，我們將介紹我們所提出的安全架構，將其與傳統的安全架構進行比較，并討論該架構的一些重要方面。

A. 安全架構

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

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

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

圖3. 域內余量CPUC利用率示例

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

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

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

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

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

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

B. 與經典方案的比較

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

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

5.結論

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

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