陳麗蓉，燕立明，羅 蕾

(電子科技大學計算機科學與工程學院 成都 610054)

隨著汽車電子控制系統(tǒng)功能、復雜性的不斷增加，當今一輛中檔轎車中裝備有大約80個電子控制單元(ECU)，它們通過多達5種不同的總線系統(tǒng)來通信與交互。出于成本、可靠性等多方面因素考慮，一種趨勢是將大量ECU替換成少量但功能更強大的微控制器，原來運行在若干專有ECU上的應用共享一個微控制器。當眾多功能集成在一個ECU中實現(xiàn)時，要系統(tǒng)性地考慮汽車電子應用在安全、可靠方面的需求。為了在運行時分離不同來源的軟部件，從軟件層面阻止一定級別的故障傳播，在汽車電子嵌入式軟件設計中要通過分區(qū)機制來防止各軟部件之間的干擾[1]。AUTOSAR組織闡述了存儲分區(qū)和處理器工作模式對實現(xiàn)防干擾的支持[2]；AUTOSAR OS規(guī)范[3]則提出了一系列與隔離保護相關的要求。

1 問題的提出

軟件分區(qū)分為操作系統(tǒng)分區(qū)和應用分區(qū)。操作系統(tǒng)內核、存儲軟件、通信診斷軟件、外設與I/O控制等基礎軟件模塊執(zhí)行在一個可信的、處于特權模式的操作系統(tǒng)分區(qū)中。應用層軟件部件在邏輯上被劃分到不同的應用中，一些應用屬于不可信的、非特權模式的應用分區(qū)，而另一些應用與操作系統(tǒng)一樣，也處于可信的、特權模式的操作系統(tǒng)分區(qū)。AUTOSAR規(guī)范要求實現(xiàn)不同應用軟件之間的隔離保護，以及應用軟件與基礎軟件之間的隔離保護。另外為了滿足一些安全限制，該規(guī)范還進一步基于程序的不同分段(數(shù)據(jù)、代碼、棧)提出了對操作系統(tǒng)、應用以及執(zhí)行體等3個級別的隔離保護要求。AUTOSAR架構中軟件分區(qū)的總體模型如圖1所示。

圖1 AUTOSAR架構基于軟件分區(qū)的隔離保護模型

1) 操作系統(tǒng)保護：禁止不可信應用對操作系統(tǒng)數(shù)據(jù)段和棧進行寫操作。

2) 應用的隔離：

①禁止不可信應用對其他應用的私有數(shù)據(jù)段進行寫或讀的操作。

②禁止不可信應用對其他應用中任務或ISR(中斷服務例程)的私有?；驍?shù)據(jù)段進行寫操作。

③允許某個應用禁止其他不可信應用執(zhí)行其代碼段。

3) 執(zhí)行體的隔離：禁止(非強制)某個不可信應用中的任務和ISR的數(shù)據(jù)段或棧被該應用中的其他任務或ISR進行寫操作。

上述隔離保護要求需要依賴特定硬件(比如MMU或MPU)的支持。而由于嵌入式處理器硬件資源(如TLB表項數(shù)量)的限制，使得規(guī)范中某些粒度的隔離保護需求難以實現(xiàn)，如將一個應用內部不同任務與ISR所使用的數(shù)據(jù)和棧區(qū)分開來，文獻[4]也提到了該問題。如果將所有這些數(shù)據(jù)及棧的分段各放到一個獨立的存儲頁中，顯然頁的數(shù)量很容易超過TLB表項的數(shù)量。而利用MMU的缺頁異常處理機制解決該問題又會對系統(tǒng)的實時響應特性帶來影響。因此基于單純的硬件機制所實現(xiàn)的隔離保護在一定程度上降低了操作系統(tǒng)的可用性。

文獻[5]提出了純粹基于軟件的存儲保護機制，但它主要是面向任務的，沒有達到應用級的隔離保護粒度，也沒有考慮對中斷服務例程的隔離保護；文獻[6]對比了基于硬件和軟件的存儲保護方案，但未描述具體實現(xiàn)細節(jié)且側重于編程語言(比如JAVA)所提供的安全特性；文獻[7]申明了操作系統(tǒng)提供存儲分區(qū)機制滿足故障隔離要求的重要性，但未提供具體實現(xiàn)；文獻[8]涉及的問題域與本文類似，但面向航空電子領域，應用環(huán)境有所差異；文獻[9]采用一種off-chip的方案檢測存儲訪問異常行為，但其不是操作系統(tǒng)內置機制與功能；文獻[10]提出了一種較為通用的存儲保護機制，但基于ITRON規(guī)范及SH3 RISC處理器進行的實現(xiàn)。

本文提出了一種軟件與硬件機制相結合的、分層實現(xiàn)隔離保護的框架和機制，有效利用硬件提供的保護功能，降低對硬件資源的需求，并基于軟件實現(xiàn)，滿足細粒度的隔離保護要求，增強應用系統(tǒng)的安全性，滿足汽車電子這一特殊應用領域規(guī)范的要求以及系統(tǒng)的實時性要求。

2 總體框架與基礎

2.1 總體框架

多級隔離保護機制框架如圖2所示。基于一定的硬件基礎，隔離保護機制主要涉及以下3個層次。

1) 第一級隔離保護：操作系統(tǒng)保護，主要基于處理器工作模式，對應用的訪存操作進行權限控制，從而實現(xiàn)操作系統(tǒng)分區(qū)與應用分區(qū)的隔離；

2) 第二級隔離保護：應用隔離，對應用的非操作系統(tǒng)訪問進行頁編號匹配檢查，從而實現(xiàn)不同應用分區(qū)之間的隔離；

3) 第三級隔離保護：執(zhí)行體隔離，通過分離應用中不同執(zhí)行體(任務、中斷服務程序即ISR)所使用的?？臻g，實現(xiàn)應用分區(qū)內部的隔離。

這3個保護級別的實現(xiàn)，貫穿在操作系統(tǒng)的系統(tǒng)初始化、異常處理及維護管理幾大功能模塊中。

2.2 硬件基礎及第一、二級隔離保護

第一、二級隔離保護基于MMU或MPU硬件所提供的分頁機制。MPC5634處理器的分頁地址轉換機制為：在指令的執(zhí)行過程中產生有效地址將與MMU的PID寄存器(用于維護系統(tǒng)當前應用分區(qū)號)、地址空間標識相結合，產生的虛擬地址與TLB中的頁表項進行比對，每一個頁表項則記錄了對應物理分頁的TID號、實際頁地址及訪問權限信息。在匹配的情況下進行正常的地址轉換，生成實際物理地址。而發(fā)生不匹配的情況有以下幾種：

圖2 多級隔離保護機制框架

1) 在TLB中未找到能夠匹配的有效頁地址：產生TLB未命中異常，需要在該異常處理程序中進行頁面置換(即TLB表項替換)；如頁面置換仍然未能找到匹配該有效頁地址的頁表項，則說明被訪問的頁不存在，進入保護錯誤處理；

2) 有效頁地址匹配而PID與TLB表項中的TID不匹配：產生TLB未命中異常(實質是權限違例)，此異常被用于實現(xiàn)不同應用分區(qū)之間的隔離，意味著出現(xiàn)了一個應用訪問其他應用私有頁面的情況；

3) TID為0時PID為任何值均不產生TLB未命中異常，此特性被用來實現(xiàn)操作系統(tǒng)分區(qū)，以便操作系統(tǒng)向應用提供各種共享服務。為防止處于用戶模式下的應用代碼對操作系統(tǒng)代碼及數(shù)據(jù)空間的非法訪問，需要利用TLB表項中的權限位結合處理器當前工作模式以及將要訪問空間的屬性(代碼或數(shù)據(jù))進行控制。6個權限信息位是：特權模式下可讀(SR)、可寫(SW)、可執(zhí)行(SX)；用戶模式下可讀(UR)、可寫(UW)、可執(zhí)行(UX)。若在地址轉換過程中發(fā)現(xiàn)權限不匹配，則產生TLB權限違例異常。

基于此，本文實現(xiàn)第一級和第二級的隔離保護，將每一個不可信應用分區(qū)均劃分為1個代碼段和1個數(shù)據(jù)段，可信的操作系統(tǒng)分區(qū)(包含可信應用)分為2個代碼段(核心代碼段和系統(tǒng)調用接口段)和1個數(shù)據(jù)段。每個段被放置到分離的內存頁面中(MPC5634允許不同大小的頁面共存)，以便利用MMU硬件的分頁機制實現(xiàn)隔離保護。表1為某系統(tǒng)頁表項配置實例，其中應用1和應用2是可信的，應用3和應用4是不可信的。系統(tǒng)調用接口是可以被用戶程序訪問的，因此被劃分為一個單獨頁面且訪問權限為用戶和系統(tǒng)均可執(zhí)行。每個不可信應用的TLB表項具有不同的TID，以控制它們之間的訪問。

表1 頁表項配置實例

2.3 分離棧策略——第三級隔離保護

基于分頁機制及處理器模式，僅僅能夠實現(xiàn)操作系統(tǒng)與應用分區(qū)、不同應用分區(qū)之間的隔離。但是如果將分頁應用于應用內部各執(zhí)行體之間數(shù)據(jù)訪問的隔離，則需要為每一個執(zhí)行體的數(shù)據(jù)或棧提供獨立的內存頁，這樣會大大增加系統(tǒng)的負擔，影響系統(tǒng)性能(增加TLB未命中率，增加任務切換的負擔，降低單頁的利用效率)。因此，采用分離棧策略來滿足分區(qū)內部細粒度隔離保護的需要，即為操作系統(tǒng)、不同的任務、不同的用戶ISR提供獨立的棧，但這些棧不占據(jù)獨立的內存頁，而是在其所屬應用或內核的數(shù)據(jù)頁面進行分配，并通過操作系統(tǒng)來維護，以此實現(xiàn)第三級的隔離保護。

運行于特權模式的可信應用具有與操作系統(tǒng)內核一樣的特權級，其執(zhí)行體在進行系統(tǒng)調用或響應中斷時都可使用同一個棧。而對于運行于用戶模式的不可信應用，當其執(zhí)行體進行系統(tǒng)調用或保存中斷上下文時需要從其當前運行棧切換到另外一個獨立的系統(tǒng)棧以保證數(shù)據(jù)的安全和一致性。然而由于ISR的執(zhí)行具有嚴格的LIFO特性，中斷棧的使用可以優(yōu)化：可以使用一個共享的中斷棧對所有嵌套中斷的上下文進行保存，并且讓所有的可信ISR也運行在這個棧上，而不會導致棧中內容的破壞。因此系統(tǒng)中棧的安排策略如下：

圖3 中斷系統(tǒng)棧的共享機制

1) 為每個可信應用任務和不可信應用任務安排一個獨立的棧；

2) 對于每一個不可信應用中的任務，為其在可信區(qū)域中設置一個“任務系統(tǒng)棧”，以便該任務在進行系統(tǒng)調用或保存中斷上下文時使用；

3) 對于每一個不可信應用中的中斷服務程序，安排一個獨立的“中斷用戶?！?；

4) 所有可信的中斷服務程序共享一個“中斷系統(tǒng)棧”，該棧也用于保存系統(tǒng)中所有嵌套中斷的上下文，以及ISR調用系統(tǒng)服務時使用。

3 維護管理及保護錯誤處理

3.1 系統(tǒng)控制流及影響分析

系統(tǒng)控制流分析如圖4所示。在系統(tǒng)運行過程中，由于應用對操作系統(tǒng)的功能調用、發(fā)生中斷以及任務調度導致的任務切換等情況，系統(tǒng)的控制流會頻繁地在應用的不同執(zhí)行體與操作系統(tǒng)之間轉換。在各種可能的轉換情況中，操作系統(tǒng)要能夠保證處理器工作模式、應用分區(qū)以及棧轉換的正確性。為確保無遺漏，本文應用面向方面編程思想[11]進行程序分析與設計，以這3方面的內容為關注焦點，完成相應的系統(tǒng)調用處理、中斷派發(fā)處理以及任務切換。

3.2 中斷派發(fā)

中斷派發(fā)實現(xiàn)被中斷執(zhí)行體和目標ISR之間的轉換。當響應中斷時處理器已自動將系統(tǒng)置為特權模式，中斷派發(fā)程序需根據(jù)被中斷執(zhí)行體及目標ISR的屬性進行相應處理。被中斷執(zhí)行體包括可信或不可信的任務、可信或不可信的ISR和系統(tǒng)服務；目標ISR包括可信或不可信的ISR。中斷派發(fā)程序的流程：

1) 中斷上下文保存：確保中斷上下文保存在可信棧上：可信任務和ISR及系統(tǒng)服務被中斷時不進行棧切換，直接保存中斷上下文；不可信任務和ISR被中斷時，切換到任務系統(tǒng)?；蛑袛嘞到y(tǒng)棧進行保存。

2) 用戶ISR調用預處理：根據(jù)目標ISR的可信屬性、所屬應用分區(qū)，決定是否進行相應的模式切換、應用分區(qū)切換和棧切換。

①如果目標ISR所屬應用分區(qū)號與當前PID寄存器中的應用分區(qū)號不同，則保存PID到中斷上下文中，并設置PID為新的應用分區(qū)號；

②如果目標ISR為可信的，則不進行模式切換和棧切換(直接在當前中斷系統(tǒng)棧的位置開始執(zhí)行用戶ISR)；

③如果目標ISR不可信，則從特權模式切換為用戶模式由由中斷系統(tǒng)棧切換至目標ISR的用戶棧；

3) 調用用戶ISR，并在其返回后做如下處理：

①如果是從可信ISR返回，則不進行模式切換和棧切換，直接回到中斷派發(fā)程序中；

②如果是從不可信ISR返回，則需從用戶模式切換回特權模式，并從ISR的用戶棧切換回中斷系統(tǒng)棧；

圖4 系統(tǒng)控制流分析

4) 中斷派發(fā)程序的后處理：存在3種可能性：

①回到上級 ISR：如果還存在中斷嵌套，則恢復中斷上下文，返回上一級用戶ISR程序中；

②回到被中斷任務：如果沒有中斷嵌套，則切換回到任務系統(tǒng)棧，在不需要重新調度任務或需要重新調度但調度結果仍然是原被中斷任務的情況下，則從任務系統(tǒng)棧中恢復最外層的中斷上下文，回到原任務被中斷的位置繼續(xù)執(zhí)行；

③切換到新的任務：如果調度的結果是需要切換到其他任務執(zhí)行，則由任務切換函數(shù)完成相應的模式轉換、應用分區(qū)切換及棧切換。

3.3 系統(tǒng)調用接口

系統(tǒng)調用接口實現(xiàn)調用者(任務或者ISR)與操作系統(tǒng)服務之間的轉換，調用者也分為可信和不可信兩類。在進行系統(tǒng)調用以及系統(tǒng)服務執(zhí)行期間，均不需要切換應用分區(qū)，系統(tǒng)調用處理只關注處理器模式和?？臻g的變化。

1) 對于可信的任務或ISR在進行系統(tǒng)調用的時候，處理器已經處于特權模式，不需要進行模式切換和棧切換，系統(tǒng)服務可以C函數(shù)調用的方式，直接在調用者的棧上運行；

2) 對于不可信的任務或 ISR在進行系統(tǒng)調用時，需要由用戶模式切換至特權模式，并從任務或ISR的用戶棧切換至其系統(tǒng)棧。模式切換需要利用處理器的系統(tǒng)調用指令或自陷指令完成，執(zhí)行該指令時，處理器將自動切換為特權模式，并進入到相應的異常處理程序。因此，本文可進一步在此異常處理程序中完成棧的切換。當系統(tǒng)服務函數(shù)完成后返回到該異常處理程序中時，再將棧切換回原用戶棧，并利用異常返回指令自動完成模式的切換。

3.4 任務調度與切換

任務調度的結果可能發(fā)生任務切換，也可能不發(fā)生切換。在發(fā)生任務切換的情況下，基本原則是要保存好即將離開的任務的上下文，并建立好新任務的運行環(huán)境。在這兩個環(huán)節(jié)中均要考慮處理器模式、應用分區(qū)以及任務棧指針的正確維護。

1) 首先對離去任務的上下文進行保存，包括當前指令執(zhí)行位置、棧指針、處理器模式以及其他需要保存的通用寄存器的內容。

2) 然后根據(jù)新任務所屬應用來對PID寄存器進行更新，這樣在隨后任務的運行過程中PID才能與對應應用頁面的TID號相匹配。

3) 根據(jù)新任務是否第一次運行進行處理；如果任務以前運行過但因某種原因被搶占，則在該任務上一次被切換離開處理器時，其棧指針、處理器模式已經作為其上下文內容的一部分被保存了下來，則此次它恢復執(zhí)行的時候，只需要恢復其上下文，即可實現(xiàn)其棧指針、處理器模式的恢復。如果任務是第一次運行，則將棧寄存器設置為該任務的棧起始地址，并根據(jù)任務所屬應用的可信屬性對處理器當前的工作模式進行設置：由于當前程序還運行在特權模式的操作系統(tǒng)內核中，如果是可信應用，則直接調用任務函數(shù)啟動任務的運行；如果是不可信應用，則需要通過內嵌匯編程序將處理器工作模式設置為用戶模式后再調用任務函數(shù)。

3.5 保護錯誤處理

保護錯誤來自兩方面：在TLB未命中異常處理中發(fā)現(xiàn)應用進行非法訪問，或是應用非法訪問操作系統(tǒng)產生的權限違例異常。當OS檢測到上述錯誤后：

1) OS調用保護HOOK函數(shù)并傳遞出錯的類型；

2) 保護 HOOK函數(shù)根據(jù)系統(tǒng)的配置反饋處理要求給OS，該處理要求與錯誤的嚴重程度相匹配；

3) OS根據(jù)反饋選擇執(zhí)行具體的處理：①PRO_IGNORE：什么也不做；②PRO_TERM INATETASKISR：強行終止出錯的任務或ISR；③PRO_TERM INATEAPPL：強行終止出錯應用；④PRO_TERM INATEAPPL_RESTART：強行終止出錯應用，并重新初始化該應用；⑤PRO_SHUTDOWN：關閉OS自身。

圖5 應用實例運行流程

4 實例與分析

4.1 實例驗證

本文所述機制在基于MPC5634的ECU硬件平臺XPC563MADPT144S上實現(xiàn)，并與作者團隊所開發(fā)的AUTOSAR OS進行了集成。為驗證已實現(xiàn)的隔離保護機制能有效工作，設計一個具有4個應用的系統(tǒng)，包含可信應用APP1和APP2及不可信應用APP3和APP4，包含任務APP1_T1, APP2_T1, APP3_T1,APP3_T2, APP4_T1和APP4_T2，任務優(yōu)先級依次遞增，APP1能訪問所有任務。在不可信應用執(zhí)行體中刻意增加非法訪存操作，以驗證該機制是否能對訪存故障進行隔離保護。為驗證TLB缺頁置換功能，在系統(tǒng)初始化時未預置所有TLB項。保護錯誤處理的配置為：APP3中任務非法訪存時強制終止故障任務；APP4中任務非法訪存時強制終止故障應用。

經測試表明，系統(tǒng)在運行過程中伴隨著任務的切換可以正確地完成應用分區(qū)的轉換、模式切換以及棧的切換。當發(fā)生TLB未命中異常時，能夠正確完成頁的置換，使相應任務能繼續(xù)執(zhí)行。而當發(fā)生權限違例時，能根據(jù)系統(tǒng)配置對發(fā)生錯誤的任務或應用進行終止，因而能夠將錯誤或故障局限于一定的區(qū)域內，降低系統(tǒng)整體發(fā)生故障或失效的可能性。

4.2 優(yōu)劣勢分析

假定某系統(tǒng)有n個應用，其中不可信應用n1個。每個應用包含數(shù)量不等的任務和ISR，方便起見，假設平均每個應用的任務及ISR總數(shù)為k個(k≥1)。如果為每個應用分配1個代碼頁、1個被該應用所有任務及ISR共享的數(shù)據(jù)頁、每個任務及ISR分配1個私有數(shù)據(jù)頁和1個棧頁，加上操作系統(tǒng)的核心代碼頁、數(shù)據(jù)頁和接口函數(shù)頁，總共需要劃分出內存頁共計個，假設此為方案1。采用本文的方案2，只需為每個不可信應用劃分1個代碼頁和1個數(shù)據(jù)頁，可信應用代碼頁與數(shù)據(jù)頁分別與操作系統(tǒng)核心代碼頁及數(shù)據(jù)頁劃分到一起，所有的?？臻g在相應的數(shù)據(jù)頁內進行分配，則總共需要劃分個內存頁。表2的數(shù)據(jù)對比說明了后者的優(yōu)勢。

顯然方案1對于應用的數(shù)量以及應用中任務及ISR的數(shù)量變化都比方案2更敏感，它會顯著增加頁的數(shù)量，帶來TLB命中率下降以及隨之的異常處理、TLB表項替換的系統(tǒng)時間開銷。而另一方面，嵌入式應用中通常一個任務或ISR的規(guī)模都不是很大(可小到只需1 KB以內的空間)，如果為每個任務及ISR的數(shù)據(jù)和棧分配一個頁面，則對于頁內空間的利用率是很低的，這有可能造成整個存儲空間不夠滿足應用系統(tǒng)的需求。

表2 兩種方案的存儲頁數(shù)量對比

采用本文方法能夠大大降低分頁的數(shù)量，提升操作系統(tǒng)性能及存儲空間利用率，但對于同一個應用區(qū)域內的棧溢出不能夠很及時地進行檢測。棧溢出有刻意或非刻意兩種情形。非刻意溢出緣于在系統(tǒng)設計中未能分配足夠的棧空間，尤其是突發(fā)情況(通常為出現(xiàn)了多個嵌套的中斷)下棧空間的超正常使用。不過由于系統(tǒng)只允許響應比當前中斷優(yōu)先級更高的中斷，中斷嵌套的最大層數(shù)是有限的。在本文所述方案中，用于嵌套中斷處理的棧已經與系統(tǒng)中其他的棧分離，可單獨為這個棧劃分足夠大的空間。這樣既有效避免了非刻意性棧溢出的發(fā)生，又在最大程度上減少了?？臻g的分配?？桃獾臈Ｒ绯霾僮骺赡軄碜杂诤诳蛙浖?，其意在破壞系統(tǒng)的正常工作。由于本文至少在可信與不可信區(qū)域之間設置了基于物理頁的隔離機制，對于可能非法進行棧操作的應用是作為不可信的部分集成到系統(tǒng)中的，因此此類棧溢出可以被及時檢測出來。綜上，本文所用機制已較好地規(guī)避了該問題。

5 結 論

應用具有隔離保護機制的嵌入式操作系統(tǒng)，能夠在一個ECU系統(tǒng)中容納來自不同渠道、具有不同安全完整性級別的軟件部件，能夠降低整個軟件系統(tǒng)滿足高安全等級的難度，滿足日益增長的汽車電子控制系統(tǒng)的安全需求。對于硬件資源受限且有實時性需求的汽車電子嵌入式系統(tǒng)，該機制的實現(xiàn)具有一定的挑戰(zhàn)性。本文工作通過有效結合硬件資源與軟件策略，降低了對硬件資源的需求，并提升了性能，以滿足在高安全完整性級別的汽車控制系統(tǒng)中應用此操作系統(tǒng)的要求。

[1] ISO. ISO/IS 26262-6 road vehicles-functional safety-part 6:product development: software level[S/OL]. [2013-06-12].http://www.iso.org/iso/home/store/catalogue_tc/catalogue_tc_browse.htm?commid=46752.

[2] AUTOSAR GbR. Technical Safety Concept Status Report V1.1.0 R4.0 Rev 2[S/OL]. [2013-06-12]. http://www.autosav.org.

[3] AUTOSAR GbR. Specification of Operating System V4.1.0 R4.0 Rev 2[S/OL].[2013-06-12]. http://www.autosav.org.

[4] 張呂紅. 參照AUTOSAR標準的SmartOSEK OS4.0的設計與實現(xiàn)[D]. 杭州: 浙江大學, 2010.

ZHANG Lü-hong. Design and implementation of smartOSEK OS 4.0 consulting AUTOSAR[D]. Hangzhou:Zhejiang University, 2010.

[5] 鄧俊, 李紅, 方正, 等. AUTOSAR OS存儲保護方案的改進與實現(xiàn)[J]. 儀器儀表學報, 2011, 32(9): 2146-2152.

DENG Jun, LI Hong, FANG Zheng, et al. Improvement and implementation of AUTOSAR OS memory protection mechanism[J]. Chinese Journal of Scientific Instrument,2011, 32(9): 2146-2152.

[6] STILKERICH M, LOHMANN D, SCHR?DERPREIKSCHAT W. Memory protection at option[C]//Proceedings of the 1st Workshop on Critical Automotive applications: Robustness & Safety. New York, USA: ACM,2010: 17-20.

[7] XI Chen. Requirements and concepts for future automotive electronic architectures from the view of integrated safety[D]. Germany: University Karlsruhe(TH), 2008.

[8] GUI S L, LUO L, TANG S S, et al. Optimal static partition configuration in ARINC653 system[J]. Journal of Electronic Science and Technology, 2011, 9(4): 373-378.

[9] Dinh-Duc A V, HO N. A run-time detector for violated memory access in embedded systems[C]//Mechatronics and Embedded Systems and Applications (MESA), 2010 IEEE/ASME International Conference on. [S.l.]: IEEE, 2010:217-223.

[10] YAMADA S, NAKAMOTO Y, AZUM I T, et al. Generic memory protection mechanism for embedded system and its application to embedded component systems[C]//Proceedings of the 8th International Conference on Computer and Information Technology Workshops. Los A lam itos, CA, USA: IEEE, 2008: 557-562.

[11] LOHMANN D, HOFER W, SCHR?DER-PREIKSCHAT W, et al. Aspect-aware operating system development[C]//Proceedings of the tenth international conference on Aspect-oriented software development. [S.l.]: ACM, 2011:69-80.

編 輯 稅 紅