在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不能由它們自己執行;它們必須指派給 OS的可執行實體。可以透過將Runnables的函數呼叫插入OS任務主體來執行此類分配。
然後，Runnables在呼叫方OS-Task的上下文中循環執行和/或事件驅動。 Runnables對任務的分配是根據圖3和圖4執行的。
#圖3：AUTOSAR分層軟體架構-Runnables的對應
圖4顯示了圖3中關係的解釋。根據此圖，AUTOSAR SWC中的Runnables被指派給 OS任務。
圖4：SWC到OS-Applications的對應
##AUTOSAR OS-Applications是OS物件（如任務、ISR、排程表、計數器和警報）的集合，它們構成了一個內聚的功能單元。屬於同一 OS-Applications的所有物件都可以互相存取。
OS-Applications中的 OS物件可能屬於不同的AUTOSAR SWC。 RTE實作了一個記憶體區域， OS-Applications的所有成員都可以不受限制地存取該區域，以方便SWC之間有效地進行通訊。
OS-Applications有兩類：
根據圖4和圖3，一個 OS-Applications可以包含多個AUTOSAR SWC和關聯的Runnables。僅允許Runnables直接存取變數並在其各自的 SWC中執行函數呼叫。
SWC的內部函數呼叫和變數不被其他SWC公開獲取，因為它們的定義不由外部介面的頭檔提供，因此不能規劃透過變數直接通訊並執行其他SWC的代碼。
在圖5中，程式碼共享範例對此進行了說明，程式碼共享只允許在 SWC內使用，而不允許在一個OS-Application的 SWC之間共享。與其他 SWC的通訊應透過RTE執行。 Runnable4可能無法執行屬於SWC2.2的功能。
##圖5：OS-Applications中的程式碼共享
AUTOSAR ECU中的應用軟體可以由與安全相關的SWC和非安全相關的SWC組成。應根據ISO26262的要求，確保具有不同ASIL等級的 SWC之間的免干擾性。
AUTOSAR OS透過將 OS-Applications放入獨佔的記憶體區域，而不受與記憶體相關的故障的干擾。此機制稱為記憶體分區。 OS-Applications之間彼此受到保護，因為在一個 OS-Applications的記憶體分區中執行的程式碼不能修改其他記憶體區域。 AUTOSAR OS規範中的相應要求如表1所示。
表1：AUTOSAR OS- OS-Applications的記憶體分區
# #應用程式軟體可以由具有不同ASIL等級的SWC組成。但是，具有不同ASIL分級的 SWC不應指派給同一個 OS-Applications。記憶體分區不能提供分配給相同 OS-Applications的 SWC之間的免幹擾性。 OS僅阻止其他 OS-Applications執行不正確的存取。不會阻止有故障的 SWC修改同一 OS-Applications中其他SWC的記憶體區域。
注意：有關任務層級分割區的詳細信息，請參閱後續分割區。
5. SWC中的記憶體分區混合ASIL SWC可能由具有不同ASIL評級的Runnable組成，因此需要一個支援不受這些Runnable之間幹擾的執行環境。由於以下原因，無法在不同的記憶體分割區中執行一個 SWC的不同Runnables：
#記憶體分區在 OS-Applications層級執行。如圖所示圖3和圖4，一個 SWC只能分配給一個OS-Applications，因此只有一個記憶體分區。此外， SWC的Runnables只能由一個 OS-Applications的任務呼叫。
如圖6所示， SWC的Runnables不能分發到多個 OS-Applications的任務。
圖6：SWC與分割區
##記憶體分割不能用於分隔同一SWC中的Runnables。如果有必要讓 SWC包含具有不同ASIL的Runnable，而這些Runnable需要免幹擾的獨立執行，那麼在 OS-Applications層級進行記憶體分區是不夠的，記憶體分區必須在任務層級執行。方法如圖7所示。
#圖7：任務級分割區
與任務層級的內存分區相關的要求列在表2的AUTOSAR OS規格中。使用弱詞「may」表示任務級分區的實作對於AUTOSAR OS是可選的。因此，並非每個AUTOSAR OS實作都支援任務級記憶體分區。
表2：AUTOSAR OS需求–任務層級的記憶體分割區##6.記憶體分區的實作
圖8顯示了一個可能的實現，而所有基礎軟體模組都在一個受信任/監控模式記憶體分區中執行（圖8中以紅色突出顯示）。某些SWC在邏輯上分組並放在單獨的非受信任/使用者模式記憶體分區中（以綠色突出顯示）。選定的軟體模組與基礎軟體模組屬於相同可信任/管理模式記憶體分區（參見圖8中紅色高亮的第四個SWC）。可能有多個不受信件的/使用者模式分區，每個分區包含一個或多個SWC。
#
在非受信任/使用者模式記憶體分區中執行SWCs會受到限制，不能修改其他記憶體區域，而受信任/監控程式記憶體分區的SWCs的執行不受限制。
用於安全相關應用的現代微控制器支援透過專用硬體（記憶體保護單元（MPU））進行記憶體分區。
注意：假設記憶體分片將在具有MPU或類似硬體功能的微控制器上實現。
使用典型的MPU實現，不受信的應用程式可以允許存取微控制器位址空間的多個分區。存取控制定義為讀取、寫入和執行存取的組合。 MPU的配置僅在監控模式下是允許的。
注意：在某些微控制器實作中，MPU整合在處理器核心中。因此，MPU僅控制關聯核心的存取。其他匯流排主站（如DMA控制器和其他核心）不受此分段MPU執行個體的控制。
下表和用例說明了記憶體保護單元的配置派生自系統要求時的一組可能方案。注意：對於正在使用的特定硬體設備的功能，此表可能不完整。
表3：記憶體保護的設定方案
#圖示說明：
X–需要保護
#O–可選保護
注意：從效能角度來看，由於匯流排爭用、介面仲裁等原因，可能會產生副作用。
用例1：SWC位於同一分割區。
功能安全機制記憶體分區透過限制對記憶體和記憶體映射硬體的存取來提供保護。在一個分區中執行的程式碼不能修改另一個分區的記憶體。記憶體分區可以保護唯讀記憶體段，以及保護記憶體映射硬體。此外，在使用者模式下執行的SWC對CPU指令的存取受到限制，例如重新配置。
記憶體分區機制可以在微控制器硬體（如記憶體保護單元或記憶體管理單元）的支援下實現。微控制器硬體必須由 OS進行適當配置，以便於偵測並防止不正確的記憶體存取。然後監控在不受信的/用戶模式記憶體分區中SWC的執行。
如果記憶體存取違規或非受信任/使用者模式分區中的CPU指令衝突，則錯誤存取將被阻止，微控制器硬體會引發異常。 OS和RTE透過執行分區關閉或重新啟動此分區的所有軟體分區來消除錯誤的軟體分區。
注意：OS的實際響應可以透過保護掛鉤實現進行配置。有關更多詳細信息，請參閱 OS SWS[i]文件。
附註：AUTOSAR文件「應用程式層級錯誤處理說明」[ii]提供了錯誤處理的其他資訊。在文件中，解釋如何執行錯誤處理以及可以從何處取得所需資料（例如替代值）。此外，本文檔還提供了有關如何在AUTOSAR中執行 OS-Applications/分區終止和重新啟動的詳細說明（使用者手冊）。
1. 具有相同ASIL分級的SWC的記憶體分區。
ISO26262標準要求不同ASIL等級[iii]的 SWC之間的免干擾性。但是，標準不要求在具有相同ASIL等級的 SWC之間的免干擾性。
允許使用由大量 SWC組成的 OS-Applications。如果單一 SWC導致衝突，從而導致關閉或重新啟動整個記憶體分區，則此記憶體分區的所有其他正常工作的SWC也會受到影響。
2. 記憶體分割區不適用於受信任的 OS-Applications。
受信任/監控模式記憶體分區的執行不受 OS和某些MMU/MPU硬體實現的控制。
3. 任務層級不支援記憶體分割區。
任務層級分割區的實作對於AUTOSAR OS實作並不是必要的。因此，可能不支援 OS-Applications中的免幹擾性。
4. 由於記憶體分區導致的效能損失。
根據應用軟體的架構以及微控制器硬體和 OS的實現，使用記憶體分區會降低效能。此損失隨著每個時間單位執行的上下文切換數的增加而增加。
5. 無基礎軟體分割區。
基礎軟體的目前規格未指定來自不同供應商的不同ASIL等級的基礎 SWC的記憶體分區。
以上是記憶體分區和實作的功能安全機制的詳細內容。更多資訊請關注PHP中文網其他相關文章！
