AUTOSAR架構之內存分區(qū)與實現

1. 應用軟件

在AUTOSAR架構中，應用軟件位于RTE上方，由互連的AUTOSAR SWC組成，這些組件以原子方式封裝了應用軟件功能的各個組成部分。

圖1：應用程序軟件

AUTOSAR SWC獨立于硬件，因此可以集成到任何可用的ECU硬件上。為了便于ECU內部和內部的信息交換，AUTOSAR SWC僅通過RTE進行通信。

AUTOSAR SWC包含許多提供內部功能的函數和變量。AUTOSAR SWC的內部結構，即其變量和函數調用，通過頭文件隱藏在公眾視野之外。只有外部RTE調用才會在公共接口上生效。

圖2：SWC

AUTOSAR SWC還包含必須在運行時調用的函數。這些C函數在AUTOSAR中稱為Runnables。

Runnables不能由它們自己執(zhí)行;它們必須分配給 OS的可執(zhí)行實體?？梢酝ㄟ^將Runnables的函數調用插入OS任務主體來執(zhí)行此類分配。

然后，Runnables在調用方OS-Task的上下文中循環(huán)執(zhí)行和/或事件驅動。Runnables對任務的分配是根據圖3和圖4執(zhí)行的。

圖3：AUTOSAR分層軟件架構-Runnables的映射

2. OS-Applications

圖4顯示了對圖3中關系的解釋。根據此圖，AUTOSAR SWC中的Runnables被分配給 OS任務。

圖4：SWC到 OS-Applications的映射

AUTOSAR OS-Applications是 OS對象（如任務、ISR、調度表、計數器和警報）的集合，它們構成了一個內聚的功能單元。屬于同一 OS-Applications的所有對象都可以相互訪問。

OS-Applications中的 OS對象可能屬于不同的AUTOSAR SWC。RTE實現了一個內存區(qū)域， OS-Applications的所有成員都可以不受限制地訪問該區(qū)域，以方便SWC之間有效地進行通信。

OS-Applications有兩類：

受信任的 OS-Applications：“允許受信任的 OS-Applications在運行時禁用監(jiān)控或保護功能的情況下運行。他們可能不受限地訪問內存和 OS模塊的API。受信任的 OS-Applications不需要在運行時強制執(zhí)行其時序行為。當處理器支持時，它們被允許在特權模式下運行。

不受信的 OS-Applications：“不允許在運行時禁用監(jiān)控或保護功能的情況下運行不受信的 OS-Applications。它們限制了對內存的訪問，限制了對 OS模塊的API的訪問，并在運行時強制執(zhí)行其時序行為。當處理器支持時，不允許它們在特權模式下運行。

3. 通信和代碼共享

根據圖4和圖3，一個 OS-Applications可以包含多個AUTOSAR SWC和關聯的Runnables。僅允許Runnables直接訪問變量并在其各自的 SWC中執(zhí)行函數調用。

SWC的內部函數調用和變量不被其他 SWC公開獲取，因為它們的定義不由外部接口的頭文件提供，因此不能規(guī)劃通過變量直接通信并執(zhí)行其他 SWC的代碼。

在圖5中，代碼共享示例對此進行了說明，代碼共享只允許在 SWC內使用，而不允許在一個OS-Application的 SWC之間共享。與其他 SWC的通信應通過RTE執(zhí)行。Runnable4可能無法執(zhí)行屬于SWC2.2的功能。

圖5：OS-Applications中的代碼共享

4. 應用軟件中的內存分區(qū)

AUTOSAR ECU中的應用軟件可以由與安全相關的 SWC和非安全相關的 SWC組成。應根據ISO26262的要求，確保具有不同ASIL等級的 SWC之間的免干擾性。

AUTOSAR OS通過將 OS-Applications放入獨占的內存區(qū)域，從而不受與內存相關的故障的干擾。此機制稱為內存分區(qū)。OS-Applications之間彼此受到保護，因為在一個 OS-Applications的內存分區(qū)中執(zhí)行的代碼不能修改其他內存區(qū)域。AUTOSAR OS規(guī)范中的相應要求如表1所示。

表1：AUTOSAR OS- OS-Applications的內存分區(qū)

應用程序軟件可以由具有不同ASIL等級的 SWC組成。但是，具有不同ASIL分級的 SWC不應分配給同一個 OS-Applications。內存分區(qū)不能提供分配給同一 OS-Applications的 SWC之間的免干擾性。OS僅阻止其他 OS-Applications執(zhí)行不正確的訪問。不會阻止有故障的 SWC修改同一 OS-Applications中其他SWC的內存區(qū)域。

注意：有關任務級分區(qū)的詳細信息，請參閱后續(xù)分區(qū)。

5. SWC中的內存分區(qū)

混合ASIL SWC可能由具有不同ASIL評級的Runnable組成，因此需要一個支持不受這些Runnable之間干擾的執(zhí)行環(huán)境。由于以下原因，無法在不同的內存分區(qū)中執(zhí)行一個 SWC的不同Runnables：

內存分區(qū)在 OS-Applications級別執(zhí)行。如圖所示圖3和圖4，一個 SWC只能分配給一個OS-Applications，因此只有一個內存分區(qū)。此外， SWC的Runnables只能由一個 OS-Applications的任務調用。

如圖6所示， SWC的Runnables不能分發(fā)到多個 OS-Applications的任務。

圖6：SWC與分區(qū)

內存分區(qū)不能用于分隔同一SWC中的Runnables。如果有必要讓 SWC包含具有不同ASIL的Runnable，并且這些Runnable需要免干擾的獨立執(zhí)行，那么在 OS-Applications級進行內存分區(qū)是不夠的，內存分區(qū)必須在任務級別執(zhí)行。方法如圖7所示。

圖7：任務級分區(qū)

與任務級別的內存分區(qū)相關的要求列在表2的AUTOSAR OS規(guī)范中。使用弱詞“may”表明任務級分區(qū)的實現對于AUTOSAR OS是可選的。因此，并非每個AUTOSAR OS實現都支持任務級內存分區(qū)。

表2：AUTOSAR OS要求–任務級的內存分區(qū)

6. 內存分區(qū)的實現

可以使用內存分區(qū)機制在系統和軟件級別上實現各種技術安全概念。

圖8顯示了一個可能的實現，而所有基礎軟件模塊都在一個受信任/監(jiān)控模式內存分區(qū)中執(zhí)行（圖8中以紅色突出顯示）。某些SWC在邏輯上分組并放在單獨的非受信任/用戶模式內存分區(qū)中（以綠色突出顯示）。選定的軟件模塊與基礎軟件模塊屬于同一可信/管理模式內存分區(qū)（參見圖8中紅色高亮的第四個SWC）。可能有多個不受信的/用戶模式分區(qū)，每個分區(qū)包含一個或多個SWC。

在非受信任/用戶模式內存分區(qū)中執(zhí)行SWCs會受到限制，不能修改其他內存區(qū)域，而受信任/監(jiān)控程序內存分區(qū)的SWCs的執(zhí)行不受限制。

用于安全相關應用的現代微控制器支持通過專用硬件（內存保護單元（MPU））進行內存分區(qū)。

注意：假設內存分片將在具有MPU或類似硬件功能的微控制器上實現。

使用典型的MPU實現，不受信的應用程序可以允許訪問微控制器地址空間的多個分區(qū)。訪問控制定義為讀取、寫入和執(zhí)行訪問的組合。MPU的配置僅在監(jiān)控模式下是允許的。

注意：在某些微控制器實現中，MPU集成在處理器內核中。因此，MPU僅控制關聯內核的訪問。其他總線主站（如DMA控制器和其他內核）不受此分段MPU實例的控制。

下表和用例說明了內存保護單元的配置派生自系統要求時的一組可能方案。注意：對于正在使用的特定硬件設備的功能，此表可能不完整。

表3：內存保護的配置方案

圖標說明：

X–需要保護

O–可選保護

注意：從性能角度來看，由于總線爭用、接口仲裁等原因，可能會產生副作用。

用例1：SWC位于同一分區(qū)中。

同一分區(qū)中的 SWC可以訪問彼此的RAM區(qū)域，因此可能會損壞彼此的內存內容。

根據定義， SWC無法訪問外圍設備，因為它們不應了解底層微控制器架構。當 SWC被允許直接訪問外圍設備時，可能會創(chuàng)建不安全的系統。
用例2：不同分區(qū)中的 SWC。

不同分區(qū)中的 SWC無法訪問彼此的RAM區(qū)域，因此無法損壞彼此的內存內容。

根據定義， SWC無法訪問外圍設備，因為它們不應了解底層微控制器架構。當 SWC被授予對外圍設備的直接訪問權限時，可能會創(chuàng)建可能不安全的系統。
用例3：MCAL驅動程序

MCAL驅動程序是函數的集合，例如讀/寫/初始化。它們必須由另一個實體執(zhí)行，例如BSW或CDD。有關詳細信息，請參見圖8。

MCAL驅動程序需要對相應外設硬件模塊的外設空間進行讀/寫訪問。根據硬件架構，可能還需要處理器的監(jiān)控模式。

7 檢測和響應

功能安全機制內存分區(qū)通過限制對內存和內存映射硬件的訪問來提供保護。在一個分區(qū)中執(zhí)行的代碼不能修改另一個分區(qū)的內存。內存分區(qū)可以保護只讀內存段，以及保護內存映射硬件。此外，在用戶模式下執(zhí)行的SWC對CPU指令的訪問受到限制，例如重新配置。

內存分區(qū)機制可以在微控制器硬件（如內存保護單元或內存管理單元）的支持下實現。微控制器硬件必須由 OS進行適當配置，以便于檢測和防止不正確的內存訪問。然后監(jiān)控在不受信的/用戶模式內存分區(qū)中SWC的執(zhí)行。

如果內存訪問違規(guī)或非受信任/用戶模式分區(qū)中的CPU指令沖突，則錯誤訪問將被阻止，微控制器硬件會引發(fā)異常。OS和RTE通過執(zhí)行分區(qū)關閉或重新啟動此分區(qū)的所有軟件分區(qū)來消除錯誤的軟件分區(qū)。

注意：OS的實際響應可以通過保護掛鉤實現進行配置。有關更多詳細信息，請參閱 OS SWS[i]文檔。

注：AUTOSAR文檔“應用程序級錯誤處理說明”[ii]提供了有關錯誤處理的其他信息。在文檔中，解釋了如何執(zhí)行錯誤處理以及可以從何處獲取所需數據（例如替代值）。此外，本文檔還提供了有關如何在AUTOSAR中執(zhí)行 OS-Applications/分區(qū)終止和重新啟動的詳細說明（用戶手冊）。

8 限制

1. 具有相同ASIL分級的SWC的內存分區(qū)。

ISO26262標準要求不同ASIL等級[iii]的 SWC之間的免干擾性。但是，標準不要求在具有相同ASIL等級的 SWC之間的免干擾性。

允許使用由大量 SWC組成的 OS-Applications。如果單個 SWC導致沖突，從而導致關閉或重新啟動整個內存分區(qū)，則此內存分區(qū)的所有其他正常工作的SWC也會受到影響。

2. 內存分區(qū)不適用于受信任的 OS-Applications。

受信任/監(jiān)控模式內存分區(qū)的執(zhí)行不受 OS和某些MMU/MPU硬件實現的控制。

3. 任務級別不支持內存分區(qū)。

任務級分區(qū)的實現對于AUTOSAR OS實現不是必需的。因此，可能不支持 OS-Applications中的免干擾性。

4. 由于內存分區(qū)導致的性能損失。

根據應用軟件的架構以及微控制器硬件和 OS的實現，使用內存分區(qū)會降低性能。此損失隨著每個時間單位執(zhí)行的上下文切換數的增加而增加。

5. 無基礎軟件分區(qū)。

基礎軟件的當前規(guī)范未指定來自不同供應商的不同ASIL等級的基礎 SWC的內存分區(qū)。

編輯：黃飛

?