1背景介紹及現存挑戰

目前，由于功能和應用的不斷發展，汽車電子電氣系統(E/E systems)的復雜性不斷增加，對額外的電子控制單元(ECUs) 的需求也越來越大。安全相關的駕駛系統必然是確定的標準配置。對于用戶來說，駕駛系統必須是可理解的，因此它應該越簡單越好。與此相比，大量的增加新功能會導致出現較高系統失效率。因此，需要針對軟件的復雜性進行相應的安全分析。

如制動或轉向功能，傳統的車輛功能及其的未來應用將逐步被沒有機械后備(Fallback)的電子系統取代。自動駕駛和電子線控(X-by-Wire)便是這一趨勢的產物。在車輛電子系統中，有一些是安全相關的，特別是動力和底盤功能系統，如果這些系統發生故障，就會引發整車層面的失效，從而造成一系列危險情況，如車輛非預期的加速。有鑒于此，ISO 26262中規定應通過明確的安全分析來導出相應的安全要求，以便實現基于硬件和軟件的故障探測和控制機制。

在高度集成的多核系統中，交叉開關(Crossbar)過度爭用可能是導致內核故障的原因。發生故障的內核連續阻塞整個系統請求接口(SRI)的交叉開關(Crossbar)的部分調度，受阻塞的調度繼而影響其他內核的輸入/輸出(I/O)以及內存訪問，這將潛在地導致執行速度大幅下降。另外，由于各個內核之間存在功能上的依賴關系，一個內核的故障也可能影響系統行為。如果AUTOSAR標準中規定的基礎軟件(Basic Software)在故障的內核上運行，則其他內核將無法訪問外設。更有甚者，倘若與其他內核存在功能依賴關系的內核發生故障，這可能會造成系統部分或完全破壞。

本文的主要貢獻在于提出了用于失效操作(fail-operational)的汽車E/E系統的架構。為此，許多整車制造商(OME)、半導體供應商、工具供應商以及大學致力于從概念層面改進軟件實現和硬件架構。在這篇文章中，提出了重要的概念設計和想法。

2先前研究回顧

編碼處理(Coded processing)方案可以通過在軟件中增加冗余來減少硬件冗余。對于實現編碼處理的失效安全(fail-safe)系統和fail-operational系統，可以估算平均故障時間(MTTF)的改進。這種方法可顯著延長fail-safe系統的MTTF，但對fail-operational系統的MTTF影響不大，因此我們難以充分論證這種方法所需的算力損耗。

文章提出了一種新穎靈活的微控制器架構，可用于fail-safe與fail-operational系統。該微控制器架構符合IEC 61508和ISO 26262的相關規定，并通過預先認證的硬件故障監控器以降低成本。該方法要求半導體廠商優化硬件結構，使其符合功能安全要求。文章重點關注ECU的硬件架構，而我們的文章重點在軟件概念，同時綜合考慮了車輛的網絡以及通信架構。

文章提出了另一種方法，即系統層面簡單架構。通過硬件/軟件協同設計，該架構能對邏輯應用層故障，以及如實時操作系統(RTOS)和微處理器等相關層的故障提供fail-operational保證。

文章回顧了應用于工業領域的故障容錯(fault-tolerant)架構的相關研究，此外還提出了低成本的雙鎖步(lockstep)平臺，可應用在要求單點fail-operational的單元或雙點失效靜默(fail-silent)通道。

文章同時概述了電子駕駛輔助系統以及具備或不具備機械后備(Fallback)的電子線控系統，作者充分考慮到不同冗余方式的fault-tolerance原則，從而產生了fail-operational、fail-silent和fail-safe系統。

3嵌入式系統的安全機制

在安全相關的嵌入式系統中，特別是車輛實時系統，制動和轉向功能即使在系統發生局部故障失效時也必須得到保證。為避免系統失效或將系統失效降至最低，常規做法是風險最小化。一般來說，可以通過縮短操作時間或降低失效率來降低失效情況的發生概率。風險最小化的另一種方法是實現改進的控制策略，如安全關機，或者實現更高的容錯性。安全關機應用于fail-silent或fail-safe系統，而高容錯性系統主要應用于fail-operational系統。Fail-operational本身可以通過多樣性或冗余來實現。

圖1呈現了這些方法：

圖1.最小化風險實現

A Fail-Safe

在Fail-Safe場景中，當檢測到不可容忍故障時，E/E系統切換到系統安全狀態。該系統存在兩種不同的狀態，即不受影響繼續運行，或者是停止運行。此外，如果發生瞬態故障，系統停止運行后重啟。在考慮失效系統時，需要采取額外措施使其具有容錯性

在常見的多核處理器中，同時并行的運行同一組操作的鎖步核有助于實現冗余系統。典型的車輛故障安全系統包括防抱死制動系統(ABS)，牽引力控制系統(ASR)，電子穩定控制系統(ESC)及制動輔助系統(BA)。

Fail-safe架構概述如圖2所示：

圖2.Fail-Safe架構

B Fail-Operational

與fail-safe系統對比，如果在發生故障時關閉Fail-Operational系統，由于關鍵的安全目標無法得到滿足，會導致危險的系統行為。這種情況下，為了實現替代和安全執行，額外的fault-tolerance措施必不可少。

Fail-operational的行為可以通過設計多樣性或冗余來實現(圖1)。多樣性意味著兩種或更多不同的實現以完成同樣的任務，功能等價，但算法、架構或實現不同。在冗余系統中，計算是由兩個或多個等價的實例完成的。在下文中，我們將簡要介紹fail-operational系統的可能實現方法。

2oo3架構

冗余故障操作架構的典型代表是2oo3決策，這也被稱為具有表決功能的三模冗余(Triple Modular Redundancy, TMR)，是航空電子領域和多安全相關系統的代表性參考架構。在這種架構中，三個子系統獨立計算各自的結果，然后，對三個子系統輸出的結果進行比較，如果至少有兩個結果相同，則輸出為真(圖3)。建議每個單元和表決單元使用獨立的電源。如果考慮通信總線，這種方法是否適用于車輛系統嚴重依賴于通信速率。對于較慢的數據輸出速率，實現的復雜性是可接受的。相比之下，對于高速以太網來說，它要復雜得多。

2oo3架構如圖3所示：

圖3.2oo3架構

2oo2DFS架構

2oo2 DFS架構將主系統分成兩個子系統，它們可以是等價的，也可以是不同的。每個子系統被設計成fail-safe系統，并使用自己的監控概念檢測其自身的錯誤(Fail-Safe (FS))。此外，該系統可以監測另外一個子系統，以便在失效情況發生時采取適當的措施(Diagnosis (D))。如圖4所示，該架構意味著每個子系統具備獨立的電源，展現了一種車輛系統fail-operational的方法。該系統既可以設計為全冗余系統，也可以設計為所謂的由主控制系統和備用系統組成的跛行系統(Limp-Home system)。具體架構方案可由每個通道中的軟件設計，或由實現部分或完全冗余的輸入拓撲達成。此外，如果架構方案不需要在同一個ECU上實現，可以使用兩個獨立控制器或主/從方法。

2oo2DFS系統架構如圖4所示：

圖4.2oo2DFS系統架構

4常用多核架構的安全特性

當代汽車ECU的功能高度集成化可以通過高性能多核處理器實現。然而，將它們整合到新的架構中是一項更加困難和富有挑戰性的任務。

Fail-operational系統需要對應的ECU硬件設計，用于處理失效和系統的非預期行為。為實現這一點，半導體供應商提供了多種安全特性和全面的錯誤管理設計。鎖步核可以檢測CPU(中央處理器)的隨機硬件故障，而內存和總線的瞬態故障可以通過糾錯碼(ECC, Error Correcting Codes)進行保護。

多核處理器的另一個優點是提供了架構上的隔離，因此，由于采用了獨立的內核，它們具有額外的獨立性。該架構允許兩個軟件實例在不同的內核上同時運行。同時，性能提高也使集成額外的安全特性成為可能。

雖然現代微控制器應用了許多硬件安全特性，如鎖步核、糾錯碼等，但多核處理器也存在缺點。首先，與單核CPU相比，多核處理器更易出錯。CMOS內比特翻轉的概率會影響計算邏輯，并可能在長期運行中導致瞬時或永久故障。此外，時序行為的可預測性和混合關鍵性應用程序的隔離受到共享資源的共同使用的影響。大多數的MCU非常復雜，幾乎不可能預測關鍵軟件的時序。能夠運行并行算法的多核CPU也會面臨更高的同步工作量的影響，尤其是當運行在不同內核上的進程并發地訪問同一資源時，就可能出現競爭情況。運行在所有ECU上的整個軟件代碼庫的復雜性治理變得難以管理。這是除了(同構)冗余之外，多樣性是必要的另一個原因。當2oo2架構由不同的MCU(代碼和/或硬件基礎)組成時，由于軟件bug或同步問題導致兩個ECU同時失效的概率遠低于同構架構。此外，我們的目標是確保在一個內核持有另一個內核正在等待的資源時不會出現死鎖。但結果卻是兩個內核都被阻塞，無法繼續運行。

5未來硬件軟件架構的概念

在過去，就單個ECU而言，fail-safe行為足以應對安全問題。對于fail-operational系統，焦點轉移到系統層面。由于ECU的獨立性只能在系統層面得到保證，沒有明確系統邊界的情況下，無法實現冗余或n取m決策(m-out-of-n)。如果我們覺得無法證實新ECU的存在價值，可以預見，冗余將通過把不同的功能集成到多個域控制單元(DCU)來實現，這一方面凸顯了系統視角的重要性，另一方面將給汽車制造商帶來新的挑戰。

A 新軟件層

失效操作(Fail-Operational)系統利用冗余計算資源實現其功能。整個系統必須知道不同子系統的狀態才能采取相應的行動，這就需要一個安全的通信層，它不僅能夠交換數據，還能夠控制消息流。例如，如果一個子系統生成了錯誤的數據，為保持系統穩定性，就必須停止傳播這一錯誤數據。最后，必須實現分布式邏輯來處理不同類型的故障。

通過使用更多域控制器來減少單個ECU數量的方法需要新的fail-operational概念，以便在一個控制器中實現冗余系統。下面的小節將我們將對硬件和軟件架構設計的一些相關概念進行概述。

B 多核架構相關概念

未來的fail-operational系統需要改進的軟件設計，下面的討論中介紹了一些不同的方法。

用于自動駕駛汽車EPS的 2oo2 DFS架構

在這種方法中，所謂的自動駕駛ECU將兩個獨立的鎖步MCU作為2oo2DFS架構的基礎。兩個輸出信號代表EPS ECU的冗余輸入信號，同時EPS ECU也被設計為2oo2DFS系統。每個ECU也可設計為僅支持跛行系統(Limp-Home)，例如一個僅提供基本功能的8位小CPU被用作備份系統。但是，MCU使用同一電路板上的兩個物理隔離的CPU(圖 5)。通常情況下，衡量系統可靠性的指標稱為平均故障間隔時間(Mean Time Between Failures，MTBF)，它表示平均故障前時間(Mean Time To Failure，MTTF)和平均故障修復時間(Mean Time To Repair，MTTR)的總和。對于Fail-safe系統，針對瞬時故障采取系統重啟等修復措施。2oo2DFS方法通過縮短MTBF提高了整個系統的可靠性。第二個子系統可以直接替換失效子系統的功能，從而縮短整個系統的MTTR。由于采用了fail-operational方案，延長了MTTF。同時，與fail-safe系統相比，該系統的容錯能力更高。

自動駕駛汽車中的2oo2DFS架構如圖5所示：

圖5.自動駕駛汽車中的2oo2DFS架構

高度集成的多核ECU中的2oo2DFS架構

此架構類似于1)中提出的 2oo2DFS。相比之下，ECU利用單個多核芯片設計成冗余系統。該架構需要為多核CPU提供多個電源，例如，每個內核一個電源。此外，硬件架構必須能夠支持每個內核的復位機制，以便在出現失效時重啟(圖6)。從軟件層面看，應該盡可能只復位最小受影響部分，即故障數據或控制流處理器指令序列(control flow processor instruction sequence)，盡可能保持較高的整體可用性。如果ECU的其中一個內核發生故障，則必須由另一個內核檢測到這一故障，剩余的內核才可以發揮備用系統的作用。因此，兩個內核必須持續地相互監控。兩個內核都通過芯內互連連接到總線接口。冗余總線連接能夠確保傳輸數據到其他的ECU，為防止失效傳播，失效的內核必須與系統隔離并斷開連接，這就意味著要將失效的內核與芯片內部的互連斷開，并關閉失效內核的電源。總而言之，這種方法大有可為，因為它不僅降低了現代車輛的成本和重量，同時提高了可靠性和可用性。圖7呈現了一種更面向軟件的方法。具有不同安全要求的應用程序封裝在虛擬機(Virtual Machine, VM)中。(圖7)顯示了一個具有三個內核的示例，每個內核執行一個客戶操作系統。客戶操作系統使用不同的傳感器信號，這些信號直接路由到對應的VM。為實現與外設及虛擬機間的通信，每個內核都配備虛擬機監視器(hypervisor)。兩級2oo3表決器被用于VM輸出(L1)的安全機制以及作為安全機制的監控(L2)。后者控制執行器。其優點之一便是，瞬時故障發生時，可以復位VM。此外，VM可以托管不同的、獨立的且彼此完全隔離的操作系統。因此，當主系統在另一VM中執行時，Limp-Home功能能夠在VM中運行。

高度集成電子控制裝置中的2oo2DFS如圖6所示：

圖6.高度集成電子控制裝置中的2oo2DFS

高度集成電子控制裝置中的流程虛擬化如圖7所示：

圖7.高度集成電子控制裝置中的流程虛擬化

6結語

對汽車工程師來說，從fail-safe到fail-operational的轉變是一個長期存在且無法避免的巨大挑戰。汽車多核處理器的通用硬件架構提供了大量的安全特性，這些特性是fail-operational實現的先決條件。在我們的合作工作中，我們開發了新概念來實現此類系統新功能，如自動駕駛和電子線控等。本文展示了一些有關如何設計未來的fail-operational架構的概念及想法。特別是，我們認為2oo2DFS架構應用靈活，具有廣闊前景。

審核編輯：湯梓紅