雖然AUTOSAR不是一個完整的安全解決方案，但它提供了一些安全機制用于支持安全關鍵系統的開發。本文用于介紹AUTOSAR支持的四種功能安全機制：

• 内存分區（Memory Partitioning）
• 時間監控（Timing Monitoring）
• 邏輯監督（Logical Supervision）
• 端到端保護（End-2-End Protection）

這些安全機制中，内存分區用于實現不同ASIL等級，安全相關組件和非安全相關組件的彼此獨立，時間監控和邏輯監控是軟件運行時序錯誤的常用檢測方法，端到端保護實現了安全相關應用在非受信網絡或存儲之間數據交互的安全。

内存分區

内存分區用于解決不同軟件組件之間的互相幹擾，造成對内存存儲的數據段或代碼段的篡改，需要限制對内存和内存映射的硬件外設的訪問。

在AUTOSAR架構下，分區是以OS-Application為對象劃分的，屬于一個OS-Application内的任務可以互相訪問，一個OS-Application包括多個任務Task，軟件組件SW-C的實現由一組可運行實體Runnable組成，Runnables在其調用者OS-Task的上下文中被循環執行和/或以事件作為觸發。下圖是OS-Application、Task、Runnable、SW-C之間的關系。

AUTOSAR 操作系統将OS-Application放入獨立的内存區域，由操作系統實現不同應用免受内存故障幹擾，這種機制稱為内存分區。由于在一個OS-Application的内存分區中執行的代碼不能修改其他内存區域，因此OS-Application之間相互保護。

具有不同 ASIL等級的軟件組件不應分配給同一個 OS-Application。操作系統隻是防止其他 OS-Application進行不适當的訪問。一個有問題的軟件組件不會被阻止修改同一 OS-Application中其他軟件組件的内存區域。同一軟件組件不能分配到不同的OS-Application中。

内存分區的實現方案是通過CPU的supervisor/ user mode進行分區，基礎應用任務運行于supervisor mode，普通應用任務運行于user mode。所有的基本軟件模塊都在一個trusted/supervisor 模式的内存分區中執行(紅色)。一些軟件組件在邏輯上被分組，放在單獨的non-trusted/user模式的内存分區中（綠色）。

選定的軟件組件屬于與基本軟件模塊相同的受信任/監督者模式内存分區（見圖8中第四個SW-C以紅色突出顯示）。可能有幾個非信任/用戶模式分區，每個分區包含一個或多個軟件組件。

内存分區功能需要專用硬件支持MPU（memory protection unit），MPU允許非受信的應用訪問微控制器地址空間的多個部分，訪問控制定義為Read/ Write/Execute訪問的組合。MPU的配置隻允許在supervisor模式下進行。硬件由操作系統進行适當的配置，以檢測和防止錯誤的内存訪問，然後監控在非受信/user模式内存分區中軟件組件的執行。

錯誤處理策略：

如在非受信/user模式分區中出現内存訪問違規或CPU指令違規，錯誤的訪問将被阻止，并由微控制器硬件提出一個異常。操作系統和RTE通過執行分區關閉或重新啟動該分區的所有SW-C來處理錯誤的軟件分區。

時間監控

為避免軟件組件之間出現的執行阻塞、死鎖、活鎖、執行時間的不正确分配、軟件元素之間的不同步，需要對軟件的運行時間進行監控，以确定軟件運行的正确時序。

受監督的軟件實體可以是軟件組件、基礎軟件模塊或CDD中的一個SW-C或Runnable。受監督實體中的重要位置被定義為checkpoint。受監督實體的代碼與看門狗管理器的函數調用交錯在一起。這些調用用于向看門狗管理器報告達到了一個checkpoint。

看門狗管理器實現兩種監督方式：Alive supervision和Deadline supervision。

Alive Supervision: 周期檢查被監督實體的checkpoint是否在給定的範圍内到達。這意味着看門狗管理器檢查被監督實體的運行頻率是否過高或過低。

Deadline Supervision：非周期性或偶發性的被監督實體對兩個checkpoint之間的時間有單獨的約束。通過Deadline Supervision，看門狗管理器檢查被監督實體的兩個checkpoint之間的轉換時間。這意味着看門狗管理器檢查被監督實體的某些步驟所需時間是否在配置的最小和最大範圍内。

錯誤處理策略：

當檢測到錯誤時，看門狗管理器将啟動以下錯誤處理策略的一種：

1. 被監督實體内的錯誤處理：如果被監督實體是SW-C或CDD，看門狗管理器可以通過RTE模式機制通知被監督實體監督失敗的情況，然後，被監督實體可以采取其行動從該故障中恢複。
3. 分區關閉：如果看門狗管理模塊檢測到位于非信任分區的被監督實體的監督失敗，看門狗管理模塊可以通過調用BswM請求分區關閉。
5. 由硬件看門狗複位：看門狗管理器向看門狗接口指示看門狗接口何時應不再觸發硬件看門狗。在硬件看門狗超時後，硬件看門狗對ECU或MCU進行複位。這将導緻ECU和/或MCU硬件的重新初始化和軟件的完全重新初始化
7. 立即MCU複位：如果有必要對監控故障做出立即的、全局的反應，看門狗管理器可以直接導緻MCU複位。這将導緻MCU硬件和整個軟件的重新初始化。通常情況下，MCU複位不會重新初始化ECU的其他硬件。

邏輯監督

邏輯監督用于檢查軟件是否按照正确的邏輯順序執行。如果一條或多條程序指令以不正确的順序被處理，或者甚至根本沒有被處理，就會發生不正确的控制流。例如，控制流錯誤會導緻數據不一緻、數據損壞或其他軟件故障。程序序列的邏輯監測是ISO26262、IEC61508、MISRA所要求或建議提出。

與時間監控一樣，受監督的軟件實體可以是軟件組件、基礎軟件模塊或CDD中的一個SW-C或Runnable。邏輯監督同樣基于checkpoint進行檢查，每個被監督實體都有一個或多個checkpoint。一個被監督實體的checkpoint之間的轉換形成一個圖。

一個圖可以有一個或多個初始checkpoint和一個或多個最終checkpoint。假設checkpoint屬于同一個圖，那麼從任何初始checkpoint開始到任何最終checkpoint結束的任何順序都是正确的。

錯誤處理策略：邏輯監督的故障處理策略與時間監控的處理策略一緻。

端到端保護

在一個分布式系統中，發送方和接收方之間的數據交互可能會影響功能安全，如果其安全行為的安全性取決于這些數據的完整性。因此，此類數據的傳輸應使用保護機制，以防止通信鍊路内的故障影響。

數據傳輸存在以下故障類型：

• 信息的重複：一種通信故障，即信息被接收一次以上
• 信息的丢失：一種通信故障，即信息或部分信息從傳輸的信息流中被删除
• 信息的延遲：一種通信故障，即信息的接收比預期的晚
• 信息的插入：一種通信故障，即在傳輸的信息流中插入額外的信息
• 信息的僞裝：一種通信故障，即非真實的信息被傳輸者當作真實的信息接受。
• 信息的不正确的尋址：一種通信故障，即信息被不正确的發送者或不正确的接收者所接受。
• 信息的不正确順序：一種通信故障，它修改了傳輸信息流中的信息順序
• 信息的破壞：一種通信故障，它改變了信息。
• 從一個發送方發送至多個接收方的不對稱信息：一種通信故障，即接收者确實從同一個發送者那裡收到不同的信息
• 從一個發送方發出的信息隻被一個子集的接收方收到：一種通信故障，一些接收者沒有收到信息
• 阻斷對一個通信通道的訪問：一種通信故障，即對通信通道的訪問被阻斷。

這些故障類型存在于一個ECU内部的不同軟件組件、OS-Application，也存在于不同ECU硬件之間。

實現端到端保護的方法是在通信協議中，數據發送方增加端到端控制信息，控制信息通常包含一個校驗和、一個計數器和其他選項。擴展後的數據元素被提供給RTE進行傳輸。

數據元素在接收方通過處理端到端控制信息的内容與應用數據進行驗證。在收到的數據元素被處理并接受為正确後，控制信息被删除，應用數據被提供給目标軟件組件，錯誤處理是在接收方進行的。

端到端的數據保護機制包括：

• CRC校驗和，用于檢驗數據是否被破壞；
• 順序計數器，在每次傳輸請求時遞增，該值在接收方檢查是否正确遞增，用于檢查數據是否丢失、插入、順序混亂；
• 在每個傳輸請求中增加的alive counter，如果它有任何變化，在接收方檢查其值，但不檢查正确的增量；
• ID:通過端口發送的每一個端口數據元素都有一個特定的ID（對系統來說是全局的，因為系統可能包含幾個ECU）；
• 超時檢測，接收器通信超時和發送器确認超時。

AUTOSAR 4.2.1 版還引入了一個狀态機，幫助确定所收到的應用數據是否可以接受，并且更加詳細。通信狀态機用于接收方接收到正确數據、錯誤數據以及可恢複、不可恢複的狀态轉換。

端到端保護以軟件庫的方式提供，可以有不同的解決方案。它們可能取決于RTE、COM或其他基本軟件模塊的完整性，以及其他SW/HW機制的使用（例如，内存分區）。

錯誤處理策略：端到端通信保護功能在 AUTOSAR 4.0 中作為标準庫實現。這個庫提供了End-2-End通信保護機制，使發送方能夠在傳輸前保護數據，接收方能夠在運行時檢測和處理通信鍊路中的錯誤。當接收方檢測到通信錯誤後，将向應用提供錯誤類型，數據處理方式（丢棄/使用上周期/重啟）。

從軟件應用層來看，端到端通信保護是一個點對點的連接，但為了達到多點通信的靈活适用性和互通性，300多頁的端到端設計規範可以看出，在通信協議的設計上需要考慮很多

總結

以上是AUTOSAR架構提供的四種功能安全機制，用于在内存保護、軟件執行的時間和邏輯順序、數據交互需要考慮的安全機制，這些内容更多是規範性方面的要求，不涉及具體的實現方法，例如時間和順序監控中，看門狗的checkpoint應該設置多少個，監督檢測到錯誤應該采用何種處理，由各廠商在遵循AUTOSAR框架下去具體實現，為保證互通性，AUTOSAR僅提供統一的外部調用接口；

這些安全措施作為ISO26262中的通用性安全要求，應予以遵循，但AUTOSAR沒有從系統層進行結構化的安全分析，這些安全要求并不完備，也沒有ASIL等級，還應結合具體的相關項定義進行補充和規定。

從應用方角度來看，安全功能的設計實現不是應用方所關注的，已在AUTOSAR架構中予以實現，應用隻要實現對這些功能進行參數配置，按照給定手冊中的要求進行調用即可，簡化了安全功能的實現過程，另一方面來說，由于對接口做了封裝，也了解不到具體的實現細節。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!