01.

前言

對于傳統汽車電子開發領域，早期使用的OS則是OSEK OS, OSEK OS是一個為滿足汽車電子可靠性、實時性、成本敏感性等需求而打造的實時單核操作系統（RTAOS）。

Classic platform AUTOSAR OS繼承OSEK OS，在OSEK OS的基礎上又特別明確了AUTOSAR OS至少需要提供的系統服務如下：

基于優先級的調度；

及時的中斷處理的能力；

中斷優先級必定高于Task；

通過StartOS()與StartOSHook()來創建啟動接口；

通過ShutdownOS()與ShutdownOSHook()來創建關機接口；

能夠在OSEK OS中跑的APP自然也能夠在AUTOSAR OS運行，但同時AUTOSAR os也同時限制了OSEK OS的一些基本使用。

02.

AUTOSAR OS 操作系統架構

2.1 OS 3層的處理級別

(1)、中斷級

(2)、邏輯級

(3)、Task級

在Task級別，根據其用戶分配優先權Task被調度（沒有，全或是混合搶先調度），運行時間方面，是在開始執行時間時被占用，以及在任務完成時被再次釋放。

以下是優先級規則定義：

(1)、中斷優先于Task；

(2)、中斷的處理級別由一個或多個中斷優先級組成；

(3)、中斷服務的流程有一個靜態分配中斷的優先級標準；

(4)、對于中斷服務例程優先級的分配取決于執行和硬件結構；

(5)、Task優先級是被用戶靜態分配的；

(6)、0是最低優先級，數值越大優先級越高。

2.2 Task的符合類

AUTOSAR OS根據不同的軟硬件需求，根據每個優先級可能具備的任務個數以及需要的是基本任務還是擴展任務等來定義了四種符合類分別為BCC1，BCC2，ECC1以及ECC2。

BCC1與ECC1不支持多次任務激活請求且每個優先級只能有一個任務；BCC2與ECC2既支持多次任務激活請求，同時也支持每個優先級可以有多個任務。各種符合類之間的兼容關系如下圖所示：

(1)、BCC1（只對基本的Tasks，所有的Task有不同的優先級，被限制只能有一個請求激活每個Task和每個優先級只能有一個Task）；

(2)、BCC2（象BCC1，但每個優先級可以有多個Task和允許多個請求激活Task）；

(3)、ECC1（象BCC1，增加擴展Tasks）；

(4)、ECC2（象ECC1，但每個優先級可以有多個Task和允許多個請求激活Basic Task）；

03.

Task管理

3.1 Task狀態模式

AUTOSAR OS中存在兩種任務：基本任務(Basic Task)和擴展任務（Extended Task）。基本任務則存在以下三種狀態：

(1)、運行狀態(Running)：處于運行狀態的任務可能被高優先級任務或者中斷搶占從而進入就緒狀態，且同一Core中任何時刻只會存在一個任務處于運行狀態，任務運行結束后則將自己掛起進入阻塞狀態；

(2)、就緒狀態(Ready):??處于就緒狀態的任務由調度器決定是否啟動進入運行狀態，且該狀態時任務切換至運行狀態的前提；

(3)、阻塞狀態(Suspend):?處于阻塞狀態的任務是被動的，可以由API函數或Alarm激活進入就緒狀態；

(4)、等待狀態(Waiting)：擴展任務與之相比，多了此狀態。當任務的運行需要等待某一或某些事件被置位時，任務進入就緒狀態。

基本任務與擴展任務的狀態機切換如下圖所示：

基本任務沒有等待狀態，所以只能在任務啟動與終結時進行同步，基本任務的優點就是占用較小的任務與執行時間。

擴展任務則包含多個同步點，沒有同步請求的麻煩，當進一步的條件無法滿足時，任務則會切換至等待狀態，其缺點也很明顯，會占用較多的內存和執行時間。

3.2 Task調度策略

3.2.1全搶占式調度

對于完全搶占式任務調度策略而言，當前運行的任務可在任何時刻被高優先級任務打斷而被迫釋放處理器控制權，具備最高優先級的任務從就緒狀態轉入運行狀態，而當前任務被搶占從而進入就緒狀態，同時保留現場環境，待下次運行時恢復。

如下圖所示為完全搶占式任務調度策略，TaskA為擴展任務，TaskB與TaskC為基本任務，優先級TaskA > TaskB > TaskC。

場景1：

當前TaskC處于運行狀態，當激活TaskB進入到就緒狀態時，由于TaskB優先級高于TaskC，所以TaskC被迫釋放處理器控制權，調度器開始調度TaskB從就緒狀態變為運行狀態，直到TaskB運行完成之后，在調度TaskC繼續運行。

場景2：

當前TaskC處于運行狀態，激活TaskA與TaskB分別進入就緒狀態，由于TaskA優先級高于TaskB，所以TaskA搶占內核運行, 但是由于Resource1仍被TaskC占用，而TaskA無法訪問到共享資源Resource1，則被迫進入到等待狀態，TaskB開始運行。TaskB運行結束后掛起之后則重新運行TaskC，TaskC運行結束后釋放Resource1，進入TaskA得以由等待狀態轉入運行狀態。

此時你會發現高優先級的任務TaskA由于共享資源被占用的原因導致不能先于TaskB運行的現象，該現象也被稱為優先級反轉現象。

為了解決該問題，在此需要提到AUTOSAR OS的優先級天花板模式：即將訪問共享資源的任務優先級在占用資源的過程中提升至共享資源任務的最高優先級之上，從而避免優先級反轉現象的發生。

即若TaskC運行過程中占用共享資源Resource1，此時即使存在需占用共享資源的高優先級任務TaskA被激活，也必須保證TaskC運行結束之后才能執行TaskA，也就意味著在重要代碼執行之前，應采用資源保護機制，以免被高優先級的任務打斷。

3.2.2非搶占式調度

用非搶占式調度策略，那么當前運行狀態的任務在任何時刻都不會其他高優先級任務所搶占，任務的切換只會發生在任務完成時。

非搶占式調度策略的問題在于任務執行時間不確定，系統調度實時性較差。如下圖所示為非搶占式調度策略，可見即使高優先級任務 TaskB被激活切換至就緒狀態，也必須等到TaskC執行結束之后才能夠被調度。

04.

Task 調度

4.1 AUTOSAR Task調度時序圖

在軟件架構設計時，為了保證CPU的負載率以及任務的前置條件，需要將每個SWC的Runnable進行定義，根據SWC的屬性進行設計，如下圖所示。

在原則上，需要定義一些主要規則：

(1)、SWC對時間要求不高的，盡量將Runnable的時間放長點。

(2)、相同Task的Runnable，可以設計多個Task，通過Offset的設置，避開同一周期的Task同時運行。

Task調度時序圖

4.2 AUTOSAR Task調度構成圖

在軟件架構設計時，為了讓軟件架構更加清晰，可以分成三類：

(1)、ECU在怠速和空轉時的任務處理；

(2)、ECU在上電或喚醒，下電或睡眠時的任務處理，以及總線收發通訊任務和消息處理任務；

(3)、ECU在Normal模式下運行時的任務處理（這里主要處理和執行功能所需的任務）；

Task調度構成圖

05.

AUTOSAR OS系統啟動

5.1 OS在OSEK規范中的啟動過程介紹

在處理器復位后，實施初始化過程，但是OS提供支持一個初始化的標準方法。OS和應用程序必須要清晰定義硬件初始化函數。

在OS初始化后，OS沒有強制定義一個需要啟動的特殊Task，但是允許用戶在系統創建時指定自動啟動的Tasks和Alarms。在CPU復位后，硬件標準應用函數被執行（沒有操作系統介入）。???

例如，在OS被初始化后（調度程序沒有運行），StartOS調用鉤子函數StartupHook()，用戶可以在那里為他的OS增加一些初始化代碼。

基于啟動的應用模式，為了能在StartupHook()里結構化初始化代碼，為此提供了一個GetActiveApplicationMode的服務。

在從鉤子函數返回后，OS啟動中斷，并且開始調度程序。在這以后系統運行并且執行用戶的Tasks 。

(1)、在復位后，用戶釋放執行的（不可移植）特殊硬件代碼。到Phase5之前，Category 2的中斷不能運行；

(2)、調用StartOS；

(3)、OS執行內部啟動函數；

(4)、調用鉤子函數StartupHook()，用戶可能會將初始化程序放在這里。在運行鉤子函數期間，所有的中斷需要被禁用；

(5)、OS激活用戶中斷和激活調度程序。對當前應用模式OS啟動自啟動的Tasks和聲明的Alarm。

自啟動的Tasks優先級是未定義的，但是具有高優先級。自啟動Tasks在自啟動Alarm前被執行。

(6)、運行用戶Tasks ；

5.2 OS在Vector模塊中的啟動過程介紹

(1)、執行Os_InitMemory() 初始化OS參數（OS使用到的變量等）;

(2)、執行Os_Init() 初始化OS參數（變量，OS中斷控制器，MPU等）；

(3)、執行EcuM_Init() 初始化部分硬件模塊（Port,Dio,Adc…）；

(4)、執行EcuM_StartOS() 啟動OS；

(5)、再OS開始執行后Task_Init() 會首先被調用. ? 執行EcuM_StartupTwo() ，此函數會調用BswM_Init() 來初始化其他硬件模塊(CAN/LIN/NVM…)；

(6)、再BswM_Init() 函數最后執行Rte_Start() 用于啟動所有任務。

06.

AUTOSAR OS系統關閉

6.1 OS在OSEK規范中的關閉過程介紹

規范中定義了一個服務以便關閉操作系統，ShutdownOS。這個服務被應用或是操作系統嚴重錯誤時調用。

當ShutdownOS被調用時，操作系統將調用鉤子函數ShutdownHook（用戶通常在ShutdownHook自由的定義系統行為），然后再關閉系統。

6.2 OS在Vector模塊中的關閉過程介紹

(1)、停止CAN/LIN/ETH通信；

(2)、保存NVM數據；

(3)、EcuM執行休眠程序；

(4)、設置喚醒源；

(5)、EcuM執行OS停止程序；

(6)、MCU進入休眠模式。

07.

AUTOSAR OS調試

兩個鉤子函數（PretaskHook和PostTaskHook）在Task上下切換時被調用，這兩個鉤子函數也許可以用來調試或時間的測試（包括上下切換時的時間）。

因此PostTaskHook在每次Task離開Running狀態時直接被調用，PreTaskHook是每次Task進入Running狀態時被直接調用。因為Task仍然/已經在Running狀態下，所以GetTaskId不會返回INVALID_TASK。

如果PostTaskHook調用沒被定義在ShutdownHook之前或之后，當調用ShutdownOS同時Task正在運行ShutdownOS時，PostTaskHook可能會調用或不被調用。

08.

中斷處理

處理中斷（Interrupt Service Routine：ISR）的功能被分類為兩種ISR（中斷服務程序在OS中具有高于Task的優級先級）：

Category1

ISR 不需要OS接管，不受OS中斷優先級等管理，在ISR完成后，處理程序繼續運行被中斷停止的指令，如中斷不會影響Task的管理。這種類型的ISRs開銷最少。

Category2

ISR需要OS接管，并受OS管理。OS提供一個ISR-Frame為專用用戶程序準備一個運行時環境，在系統創建時用戶程序被分配給中斷。

在中斷服務程序使用OS服務只限于下圖所示。

在ISR內重調度不會發生。如果一個搶占式Task被中斷并且沒有其他的中斷被激活，重調度會在Category2終止后發生。

這個行為確認Task只有通過OS調度點才被執行，為實現這一目標，可實施對所有類型的ISR限制中斷優先級。

審核編輯：劉清