AUTOSAR OS操作系統(tǒng)架構(gòu)與啟動流程介紹

01.

前言

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

Classic platform AUTOSAR OS繼承OSEK OS，在OSEK OS的基礎(chǔ)上又特別明確了AUTOSAR OS至少需要提供的系統(tǒng)服務(wù)如下：

基于優(yōu)先級的調(diào)度；

及時的中斷處理的能力；

中斷優(yōu)先級必定高于Task；

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

通過ShutdownOS()與ShutdownOSHook()來創(chuàng)建關(guān)機(jī)接口；

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

02.

AUTOSAR OS 操作系統(tǒng)架構(gòu)

2.1 OS 3層的處理級別

(1)、中斷級

(2)、邏輯級

(3)、Task級

在Task級別，根據(jù)其用戶分配優(yōu)先權(quán)Task被調(diào)度（沒有，全或是混合搶先調(diào)度），運(yùn)行時間方面，是在開始執(zhí)行時間時被占用，以及在任務(wù)完成時被再次釋放。

以下是優(yōu)先級規(guī)則定義：

(1)、中斷優(yōu)先于Task；

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

(3)、中斷服務(wù)的流程有一個靜態(tài)分配中斷的優(yōu)先級標(biāo)準(zhǔn)；

(4)、對于中斷服務(wù)例程優(yōu)先級的分配取決于執(zhí)行和硬件結(jié)構(gòu)；

(5)、Task優(yōu)先級是被用戶靜態(tài)分配的；

(6)、0是最低優(yōu)先級，數(shù)值越大優(yōu)先級越高。

2.2 Task的符合類

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

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

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

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

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

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

03.

Task管理

3.1 Task狀態(tài)模式

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

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

(2)、就緒狀態(tài)(Ready):??處于就緒狀態(tài)的任務(wù)由調(diào)度器決定是否啟動進(jìn)入運(yùn)行狀態(tài)，且該狀態(tài)時任務(wù)切換至運(yùn)行狀態(tài)的前提；

(3)、阻塞狀態(tài)(Suspend):?處于阻塞狀態(tài)的任務(wù)是被動的，可以由API函數(shù)或Alarm激活進(jìn)入就緒狀態(tài)；

(4)、等待狀態(tài)(Waiting)：擴(kuò)展任務(wù)與之相比，多了此狀態(tài)。當(dāng)任務(wù)的運(yùn)行需要等待某一或某些事件被置位時，任務(wù)進(jìn)入就緒狀態(tài)。

基本任務(wù)與擴(kuò)展任務(wù)的狀態(tài)機(jī)切換如下圖所示：

基本任務(wù)沒有等待狀態(tài)，所以只能在任務(wù)啟動與終結(jié)時進(jìn)行同步，基本任務(wù)的優(yōu)點(diǎn)就是占用較小的任務(wù)與執(zhí)行時間。

擴(kuò)展任務(wù)則包含多個同步點(diǎn)，沒有同步請求的麻煩，當(dāng)進(jìn)一步的條件無法滿足時，任務(wù)則會切換至等待狀態(tài)，其缺點(diǎn)也很明顯，會占用較多的內(nèi)存和執(zhí)行時間。

3.2 Task調(diào)度策略

3.2.1全搶占式調(diào)度

對于完全搶占式任務(wù)調(diào)度策略而言，當(dāng)前運(yùn)行的任務(wù)可在任何時刻被高優(yōu)先級任務(wù)打斷而被迫釋放處理器控制權(quán)，具備最高優(yōu)先級的任務(wù)從就緒狀態(tài)轉(zhuǎn)入運(yùn)行狀態(tài)，而當(dāng)前任務(wù)被搶占從而進(jìn)入就緒狀態(tài)，同時保留現(xiàn)場環(huán)境，待下次運(yùn)行時恢復(fù)。

如下圖所示為完全搶占式任務(wù)調(diào)度策略，TaskA為擴(kuò)展任務(wù)，TaskB與TaskC為基本任務(wù)，優(yōu)先級TaskA > TaskB > TaskC。

場景1：

當(dāng)前TaskC處于運(yùn)行狀態(tài)，當(dāng)激活TaskB進(jìn)入到就緒狀態(tài)時，由于TaskB優(yōu)先級高于TaskC，所以TaskC被迫釋放處理器控制權(quán)，調(diào)度器開始調(diào)度TaskB從就緒狀態(tài)變?yōu)檫\(yùn)行狀態(tài)，直到TaskB運(yùn)行完成之后，在調(diào)度TaskC繼續(xù)運(yùn)行。

場景2：

當(dāng)前TaskC處于運(yùn)行狀態(tài)，激活TaskA與TaskB分別進(jìn)入就緒狀態(tài)，由于TaskA優(yōu)先級高于TaskB，所以TaskA搶占內(nèi)核運(yùn)行, 但是由于Resource1仍被TaskC占用，而TaskA無法訪問到共享資源Resource1，則被迫進(jìn)入到等待狀態(tài)，TaskB開始運(yùn)行。TaskB運(yùn)行結(jié)束后掛起之后則重新運(yùn)行TaskC，TaskC運(yùn)行結(jié)束后釋放Resource1，進(jìn)入TaskA得以由等待狀態(tài)轉(zhuǎn)入運(yùn)行狀態(tài)。

此時你會發(fā)現(xiàn)高優(yōu)先級的任務(wù)TaskA由于共享資源被占用的原因?qū)е虏荒芟扔赥askB運(yùn)行的現(xiàn)象，該現(xiàn)象也被稱為優(yōu)先級反轉(zhuǎn)現(xiàn)象。

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

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

3.2.2非搶占式調(diào)度

用非搶占式調(diào)度策略，那么當(dāng)前運(yùn)行狀態(tài)的任務(wù)在任何時刻都不會其他高優(yōu)先級任務(wù)所搶占，任務(wù)的切換只會發(fā)生在任務(wù)完成時。

非搶占式調(diào)度策略的問題在于任務(wù)執(zhí)行時間不確定，系統(tǒng)調(diào)度實時性較差。如下圖所示為非搶占式調(diào)度策略，可見即使高優(yōu)先級任務(wù) TaskB被激活切換至就緒狀態(tài)，也必須等到TaskC執(zhí)行結(jié)束之后才能夠被調(diào)度。

04.

Task 調(diào)度

4.1 AUTOSAR Task調(diào)度時序圖

在軟件架構(gòu)設(shè)計時，為了保證CPU的負(fù)載率以及任務(wù)的前置條件，需要將每個SWC的Runnable進(jìn)行定義，根據(jù)SWC的屬性進(jìn)行設(shè)計，如下圖所示。

在原則上，需要定義一些主要規(guī)則：

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

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

Task調(diào)度時序圖

4.2 AUTOSAR Task調(diào)度構(gòu)成圖

在軟件架構(gòu)設(shè)計時，為了讓軟件架構(gòu)更加清晰，可以分成三類：

(1)、ECU在怠速和空轉(zhuǎn)時的任務(wù)處理；

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

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

Task調(diào)度構(gòu)成圖

05.

AUTOSAR OS系統(tǒng)啟動

5.1 OS在OSEK規(guī)范中的啟動過程介紹

在處理器復(fù)位后，實施初始化過程，但是OS提供支持一個初始化的標(biāo)準(zhǔn)方法。OS和應(yīng)用程序必須要清晰定義硬件初始化函數(shù)。

在OS初始化后，OS沒有強(qiáng)制定義一個需要啟動的特殊Task，但是允許用戶在系統(tǒng)創(chuàng)建時指定自動啟動的Tasks和Alarms。在CPU復(fù)位后，硬件標(biāo)準(zhǔn)應(yīng)用函數(shù)被執(zhí)行（沒有操作系統(tǒng)介入）。???

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

基于啟動的應(yīng)用模式，為了能在StartupHook()里結(jié)構(gòu)化初始化代碼，為此提供了一個GetActiveApplicationMode的服務(wù)。

在從鉤子函數(shù)返回后，OS啟動中斷，并且開始調(diào)度程序。在這以后系統(tǒng)運(yùn)行并且執(zhí)行用戶的Tasks 。

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

(2)、調(diào)用StartOS；

(3)、OS執(zhí)行內(nèi)部啟動函數(shù)；

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

(5)、OS激活用戶中斷和激活調(diào)度程序。對當(dāng)前應(yīng)用模式OS啟動自啟動的Tasks和聲明的Alarm。

自啟動的Tasks優(yōu)先級是未定義的，但是具有高優(yōu)先級。自啟動Tasks在自啟動Alarm前被執(zhí)行。

(6)、運(yùn)行用戶Tasks ；

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

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

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

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

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

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

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

06.

AUTOSAR OS系統(tǒng)關(guān)閉

6.1 OS在OSEK規(guī)范中的關(guān)閉過程介紹

規(guī)范中定義了一個服務(wù)以便關(guān)閉操作系統(tǒng)，ShutdownOS。這個服務(wù)被應(yīng)用或是操作系統(tǒng)嚴(yán)重錯誤時調(diào)用。

當(dāng)ShutdownOS被調(diào)用時，操作系統(tǒng)將調(diào)用鉤子函數(shù)ShutdownHook（用戶通常在ShutdownHook自由的定義系統(tǒng)行為），然后再關(guān)閉系統(tǒng)。

6.2 OS在Vector模塊中的關(guān)閉過程介紹

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

(2)、保存NVM數(shù)據(jù)；

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

(4)、設(shè)置喚醒源；

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

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

07.

AUTOSAR OS調(diào)試

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

因此PostTaskHook在每次Task離開Running狀態(tài)時直接被調(diào)用，PreTaskHook是每次Task進(jìn)入Running狀態(tài)時被直接調(diào)用。因為Task仍然/已經(jīng)在Running狀態(tài)下，所以GetTaskId不會返回INVALID_TASK。

如果PostTaskHook調(diào)用沒被定義在ShutdownHook之前或之后，當(dāng)調(diào)用ShutdownOS同時Task正在運(yùn)行ShutdownOS時，PostTaskHook可能會調(diào)用或不被調(diào)用。

08.

中斷處理

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

Category1

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

Category2

ISR需要OS接管，并受OS管理。OS提供一個ISR-Frame為專用用戶程序準(zhǔn)備一個運(yùn)行時環(huán)境，在系統(tǒng)創(chuàng)建時用戶程序被分配給中斷。

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

在ISR內(nèi)重調(diào)度不會發(fā)生。如果一個搶占式Task被中斷并且沒有其他的中斷被激活，重調(diào)度會在Category2終止后發(fā)生。

這個行為確認(rèn)Task只有通過OS調(diào)度點(diǎn)才被執(zhí)行，為實現(xiàn)這一目標(biāo)，可實施對所有類型的ISR限制中斷優(yōu)先級。

審核編輯：劉清