導入專用型多核心MCU　嵌入式車用系統安全有保障

與此同時，許多微控制器(MCU)廠商才剛開始著手生產多核心處理器，以市售產品的價格，提供嵌入式運算速度提升兩倍之多的處理器。本文將探討功能安全標準對嵌入式系統的影響，闡述如何建構多核心微控制器以支援封裝製程，同時說明舊式軟體如何與安全關鍵程式碼搭配，以快速推出安全系統，省去重頭開始設計的麻煩。

汽車系統複雜度遽增　軟硬體整合能力成關鍵

汽車產業正面臨將多種舊式應用程式整合到單一多核心裝置的挑戰。由於汽車產業承受巨大的成本壓力，加上汽車系統的功能及複雜性急遽增加，使得軟體成為主要的工程費用，因此必須對生產的大量裝置加以控制並合理化。傳統的軟體成本控制機制包括再利用和重新設計現有程式碼基底，加入所需要的額外功能，或甚至改變軟體集的設計目的，應用在完全不同的用途。

汽車軟體另一個關鍵的癥結點，就是採用AUTOSAR做為電子控制單元(ECU)的通用作業系統。AUTOSAR系統能夠透過常見的執行時間環境(RTE)下的驅動軟體集、通訊堆疊和抽象層，將應用層級的功能抽離特定微控制器的基礎硬體。RTE提供虛擬功能匯流排(VFB)，使用VFB單一描述符號撰寫的應用程式，能在車輛架構要針對不同的車輛等級進行更新或調整時，重新編譯並移轉到其他的ECU，如此彈性的設計時間讓基礎硬體超越商品，透過市場的力量來降低成本。

在實務上，AUTOSAR系統尚未開發完全，部分是因為第一層的ECU廠商編寫了自己一套特殊的AUTOSAR解譯，且其中的差異相當細微，另外則是來自完全硬體抽象的相關成本，因為許多節能和效能強化周邊裝置，以及常用的微控制器功能無法透過標準的AUTOSAR功能取得。AUTOSAR是一個結構完善的架構，早已為這個可能的結果做了規畫及準備，它能使用複雜裝置驅動程式(CDD)來延伸基本軟體(BSW)的集合。藉由CDD的使用，設計人員便能以極有效率的方式使用專屬的微控制器硬體，使軟體無法轉移到任何其他不支援相同CDD功能的裝置。

然而，AUTOSAR的設計本不支援多核心微控制器，也不支援功能安全，AUTOSAR的出現，主要是因汽車產業的車體部門為了解決複雜性不斷提高的管理問題，以及客製化ECU的大幅增加，因此為了完成此一不可能的任務，設計人員需要一些嶄新的解決方案。

ISO 26262標準認證嚴苛　墊高車用電子技術門檻

ISO 26262是一種用來將潛在危險質化及量化的風險評估方法，潛在危險可能對駕駛人或鄰近車輛的人們造成傷害。ISO 26262不是全新的概念，它涵蓋了IEC 61508功能安全標準大多數的內容，多年來已被廣泛用作不同領域其他汽車安全標準。不過，ISO 26262的發布對產業最主要的差別，就是現在有一個示範性方法能供所有人參考，做為最新的汽車功能安全工程標準。這項標準為安全相關電子系統工程解決了工程流程、工程原則的組織和技術解決方案等三個問題。

在過去，汽車開發大部分的焦點都放在成品上，因為成品須經過一連串的測試及分析驗證。ISO 26262則採取更廣泛的方法，並使用更穩健、需求導向的工程流程，先對可能的系統層級危險進行分析，接著細分為安全目標，再微調為安全需求，然後透過由硬體元件和軟體單元組成的架構來達成需求。ISO 26262將各種危險依照其嚴重性、控制性及接觸可能性進行分級，建立了汽車安全完整性等級ASIL，可決定工程製程的嚴格度、評估獨立性和技術解決方案能力。字母排序越高，適用的嚴格度越高。

此外，產業界也設立了ASIL QM等級，其代表危險可由標準的品質流程加以控制，不須特別遵循額外的ISO 26262方法。ASILD的等級越高，就須採取並回報越多個別的安全活動。但此類活動的成本極高，因此通常使用成本較低的ASIL分解規則，透過兩個獨立的ASILB實作控制ASILD的危險。正確的方程式為ASILD=ASILB(D)+ASILB(D)，其中括號內的字母顯示分解最終必須能重新編寫，並確實仍能將原本的危險控制在正確一開始的ASIL。此種分解方式套用在軟體上可省下大量時間及精神，而且多數舊式軟體依預設已能滿足ASIL QM的需求。

因此，假如舊式軟體原先便是用來控制以ASILD安全為目標的安全相關系統，便能設計額外的監控或合理性軟體，使其達到ISO 26262 ASILD開發程序的完整嚴格度，並以獨立於舊式程式碼的運算通道運行。舊式軟體也許有數千行的原始碼，並能執行多項功能，但很可能並非所有功能都跟ASILD安全目標背道而馳。

由於新編寫的合理性軟體容量較小，也較簡單，所以比舊式程式碼更能滿足安全需求，全新合理性軟體的用意不是控制系統，而是偵測ASILD安全目標發生違反事件的時間，並將系統帶入穩定安全狀態。舊式軟體可以當成是ASIL QM，而新的合理性軟體則當成ASILD，如此系統的組成便會是ASILD=ASILQM(D)+ASILD(D)。於是責任落到系統整合商身上，他們須證明這兩個不同的軟體處理通道「無干擾」，且不常發生共因失效。如此看來，設計人員需要專屬的故障偵測和製程封裝機制，並由特定微控制器上的硬體提供支援。

控制記憶體存取與權限　封裝技術至關重要

對於多重應用程式和工作共存於通用處理平台，也可強制執行不同層級的封裝邊界。從核心層級來看，記憶體保護系統可偵測CPU嘗試存取其未獲得權限的資料或程式碼位址。使用記憶體管理單元(MMU)，可將位址虛擬化，並將實體位址轉譯為邏輯位址，以控制記憶體存取及權限。

MMU除了執行位址轉譯，還須軟體支援，才能在配置工作時執行設定和環境切換。用來控制MMU的軟體將成為單點故障，此軟體元件內的干擾或錯誤將影響所有執行中的工作，包括能夠用來偵測MMU系統故障的工作。用來執行MMU功能的硬體並非零故障，因此也必須在執行時間內診斷位址對映邏輯和轉譯後備緩衝區(TLB)的故障問題。另外，執行MMU所需要的電力，將會由記憶體保護單元(MPU)負責提供。

MPU能夠監控用於資料和程式碼存取的位址，且能在運行中隨時切換設定，跟MMU一樣，但不正確的MPU操作並不會直接引致新的故障模式，因為MPU不具備轉譯位址的功能(即使發生故障時)。在多核心架構中，還須要為全域共用資源(包含記憶體)提供保護。有許多架構性解決方案可供使用，包括有可完全信任及合作的架構，其中每個核心都有MMU或MPU實作，且各自執行作業系統實例，能夠維持系統所指派的最高ASIL。這適合某些大多數處理位在類似層級的應用，但對混合關鍵系統來說則顯得浪費。

此外，有一些微控制器系統內部分核心為鎖步(因此內部有備援的運算硬體)，其他核心則不是鎖步。在這樣的設定中執行合作架構，由MMU和MPU做為記憶體封裝的閘道管理器，將局限可實現的ASIL(一般實現ASILB)，而鎖步的核心則可能實現ASILD。第二個替代方式則是提供本身擁有MPU的中央橋或閘道，這個以中央匯流排為基礎的MPU能在運行中切換，提供核心及共用資源之間可用的記憶體區域對映，此一MPU須由支援適當ASIL功能的核心來控制。

改善一致性問題　多核心MCU效能再升級

由於ECU所用軟體是專為在單核心處理器上執行所撰寫及設計的，因此通常會有主要排程循環在運作，執行具時間決定性的所有工作，而且有一定數量的中斷，主要由事件導向。排程器下運作的單一工作執行緒，通常不須注意資料的一致性和一貫性，但會保護資料免於中斷可能導致的任何毀損或更新。如果程序在作業一開始使用其中一種狀態(例如測量到的汽車電池電壓)，那麼類比轉換器中斷便可能在演算法完成之前跳入並更新回報的電池電壓，使用部分更新的資訊，可能導致不想要或非預期的結果。要避免此問題的一般做法是將全域狀態的更新與排程器內的特定時槽同步。本機程序也可以使用「getter」和「setter」功能及API，在特定時間為全域狀態建立快照並更新結果。

在考量資料快取及多核心架構時，首當其衝的便是一貫性及一致性的問題。如果工作建立某些全域狀態的快取副本，那麼硬體將自動使用本機快取副本以進一步進行本機運算，直到快取失效。使用本機快取副本，很明顯可改善效能，也更為省電，但是軟體程式設計人員現在須協調快取資料副本，使其在必要的時間失效。支援資料快取的微控制器，一直以來都支援特定的快取失效技術，以維持資料的一貫性。此外，也有一些具備自動快取同調硬體邏輯的架構。此種機制雖然方便，但假如同調邏輯發生錯誤，可能對系統造成不必要的副作用。它也需要大量邏輯，並會消耗大量電力，因此對一般汽車系統所使用的微控制器類別來說較不符合經濟性。

資料一致性的問題，在執行非同步排程並共用某些全域狀態的多核心處理器上更為明顯。一般會使用合作式排程器，使用時間分隔多重存取(TDMA)的方式。對安全相關系統來說，此種配置也會帶來困擾，因為多重核心可取得共用資源的存取權限，在預先定義的特定時槽進行存取。假如某一核心發生故障，那它可能也會在錯誤的時間覆寫某些狀態，因而破壞資料。較為常見的方法是，使用某一核心(支援高ASIL)來統整其他核心所有的活動，如此部分核心便無法自行授予存取權限，而資料也會按排程時間在本機記憶體上進行讀寫。

多核心微控制器另一個較不明顯的問題是重設個別核心時，必須協調運作中的核心，以及內部匯流排或交叉開關的互連結構。如果核心變成故障，導致無法復原的錯誤，則通常只有對核心執行本機重設，才能讓核心恢復上線狀態。如果核心剛好在匯流排交易的半途發生故障，則必須從架構層級深入考量，提供機制來偵測任何核心的鎖定及逾時，並取消任何尚未完成的交易，讓匯流排上其餘的核心能持續運作，而故障的核心則能執行重設。

整合舊式軟體　新一代多核心MCU大顯身手

如先前所述，要能將一或多個舊式軟體區塊整合到多核心微控制器，有一些重大難題必須先克服。有許多問題須要詳加考慮，像是如何架構多重作業系統，還有各種驅動程式、通訊協定堆疊及其他應用程式的實例。AURIX微控制器系列的AUTOSAR多核心版本支援一種新方法，就是將舊式軟體裝載到第四級擴充性版本的作業系統，以提供記憶體及時間保護功能。

舊式軟體可以執行為「不信任」的軟體，也就是說，可自動鎖住對周邊裝置或其他共用資源的所有存取。這些存取將產生陷阱，而陷阱可以加以分析，以偵測存取嘗試的內容、對象及時間。除錯介面擁有功能強大的追蹤機制，也能對產生所要求之存取的程式流量執行完整檢驗；支援的靜態程式碼分析工具(如Polyspace)和排程及計時分析工具(如Rapita)，可用來分析舊式軟體，並了解多重關鍵系統之間可能的互動。AURIX硬體封裝機制可確保舊式程式碼和裝載的其他軟體及程序之間不會發生干擾，但還須要完成其他工作，才能讓舊式軟體如期運作。系統也可以協助AUTOSAR，因為它可修改「不信任」的軟體，重新導向嘗試對「信任」的作業系統存取。這確實有效，但有不小的缺點，因為舊式軟體必須經過再造、修改和重新發布，會延宕產品上市時程，但所幸AURIX微控制器具備更進階的功能，可省下這個額外的步驟。

作業系統虛擬化　處理器負擔大幅減輕

作業系統虛擬化在電腦產業行之多年，在這個產業內有穩固的基礎，是一廣受支持的概念。其主要使用兩種技術；第一種是硬體虛擬化，基礎硬體可向裝載的作業系統顯示比實體資源更多的「虛擬」資源。例如，四核心處理器可以進行分割，向裝載的作業系統顯示十二個「虛擬」CPU，讓最多十二個作業系統實例能夠同時運作。

在VMware ESX和Microsoft Virtual Server也可見到這類硬體虛擬化的範例。第二種常用的方法，則是在軟體層級執行虛擬化(在基礎硬體之上)，作業系統將應用程式顯示為專屬實例，如此一來，裝載的應用程式便會假設其能使用所有可用的資源。但實際上，裝載的應用程式正在共用可用的實體資源，並由較低層級的作業系統進行統整。這個技術亦稱為多重實例(Multi-instantiation)，其用意是在單一硬體上提供多個平行的工作階段，另外則能確保資源的分配和效能分布。

圖1　使用Hypervisor的訪客作業系統虛擬化概念

上述兩種方法都有相同的基本假設，也就是裝載的應用程式無法直接存取基本的系統資源和服務，存取將遭中介的作業系統層(通常整合使用Hypervisor)攔截並改由其發出。如圖1所示，Hpervisor層負責來自上層各種資源要求的仲裁及分配，並能根據預先定義的規則集或演算法來控制存取。

虛擬化有許多極為吸引人的好處，但它一樣有其缺陷。就電腦產業來說，使用Hypervisor一般不會大幅影響可預見的系統效能，因為實際上只有少數的存取需要攔截，其他大多數都是直接的記憶體存取，已由MMU虛擬化。然而，這個情況則不適用於傳統的嵌入式汽車系統，因為其可用的CPU處理效能經常是呈量級減少，而預期的即時效能卻比電腦實際效能高出好幾個量級。這不包含可用的全Hypervisor系統，且還會形成嚴重的效能瓶頸，因為所有的即時存取都須經過同一層。支援同時存取的平行系統較為適用，它可允許多核心微控制器內的個別核心同時進行讀取和寫入，而不會增加延遲或佇列，AUTOSAR作業系統特別是如此。

AUTOSAR虛擬化的概念是直到最近才得以實現，受到多核心效能、可用核心數量，和支援舊式單核心AUTOSAR應用程式的需求帶動，讓企業須投入研究可行的解決方案。其中一項計畫名為RECOMP，這是由歐洲共同發起的專案，集結來自汽車業、工業及航太工業許多知名公司，加上來自學術界的支援，更受到歐盟ARTEMIS聯合企業的大力資助。RECOMP計畫探討了安全相關硬體和軟體的認證能否在適用產業內重複使用的問題。RECOMP產生的結果之一，就是建立新微控制器架構的定義，以半虛擬化的形式，透過輕量的 Hypervisor實作，支援最頂尖的機制。半虛擬化的實作就是在CPU核心及所有的共用資源上實作一系列的分散式硬體存取權限、CPU權限層級和存取陷阱機制。

圖2　在AURIX微控制器上虛擬化AUTOSAR作業系統多重實例的半虛擬化配置概念

AUTOSAR基本軟體的最底層經過調整，能夠將許多專用的驅動程式及服務集合實例化，如此便能將多個AUTOSAR實例裝載在單一微控制器上。這些深度嵌入的汽車微控制器的半虛擬化，與一般電腦的實作方式稍微不同，但在電力、成本及運算資源的限制下，卻能符合汽車使用情況的經濟性，達成相同的目的。AURIX微控制器所使用的半虛擬化允許使用Hypervisor(圖2)，而Hypervisor也有硬體型的繞道通道，也能從特定核心或在這些核心上運作的工作直接存取，能夠直接對映而不被攔截。如此便能建構出混合式系統，透過直接對映來維持即時效能，而AUTOSAR實作下的共用資源則由Hypervisor功能統合。此一方法可讓AUTOSAR應用程式保持不變，即便是這些應用程式的純正性和安全功能與其他(高完整性)的軟體元件不符。半虛擬化造成了封裝的阻礙，因此必須確保共存的BSW、通訊堆疊、複雜裝置驅動程式和AUTOSAR作業系統實例之間「無干擾」。

微控制器從單核心轉向多核心，能夠在效能、軟體抽象，甚至應用程式整合能力等各方面帶來許多好處，而且全都可為系統省下大筆成本。但要重新架構軟體，使其能夠在這些新機器上運作是一件困難的工作，因為各種功能的整合將使複雜性大大提高。還有像是資料一致性及一貫性、程式及資料快取的使用、共用的L2記憶體和周邊裝置等，全都反映問題的多個面向，即使能推出合作式共用配置，也很難判斷提出的解決方案是否最好或夠耐用。

為能夠解決此一問題，使用半虛擬化硬體並調整低階軟體，將硬體上的軟體虛擬化能確保軟體堆疊內各種抽象層的「無干擾」。其提供的封裝機制能夠將舊式軟體虛擬化並整合，當作是在單核心控制器上執行，即使基礎硬體為多核心。當共用資源存取造成衝突或發生暫時性問題時，便能呼叫Hypervisor，以免發生系統層級的違反狀況。Hypervisor可穩定監督，也會斟酌其他的功能需求，以支援ISO 26262功能安全的考量，同時還能隔離故障的軟體，維持可用性。

(本文作者為英飛凌首席工程師)