01.
前言
對于傳統(tǒng)汽車電子開發(fā)領域,早期使用的OS則是OSEK OS, OSEK OS是一個為滿足汽車電子可靠性、實時性、成本敏感性等需求而打造的實時單核操作系統(tǒng)(RTAOS)。
Classic platform AUTOSAR OS繼承OSEK OS,在OSEK OS的基礎上又特別明確了AUTOSAR OS至少需要提供的系統(tǒng)服務如下:
基于優(yōu)先級的調(diào)度;
及時的中斷處理的能力;
中斷優(yōu)先級必定高于Task;
通過StartOS()與StartOSHook()來創(chuàng)建啟動接口;
通過ShutdownOS()與ShutdownOSHook()來創(chuàng)建關機接口;
能夠在OSEK OS中跑的APP自然也能夠在AUTOSAR OS運行,但同時AUTOSAR os也同時限制了OSEK OS的一些基本使用。
02.
AUTOSAR OS 操作系統(tǒng)架構
2.1 OS 3層的處理級別
(1)、中斷級
(2)、邏輯級
(3)、Task級
在Task級別,根據(jù)其用戶分配優(yōu)先權Task被調(diào)度(沒有,全或是混合搶先調(diào)度),運行時間方面,是在開始執(zhí)行時間時被占用,以及在任務完成時被再次釋放。
以下是優(yōu)先級規(guī)則定義:
(1)、中斷優(yōu)先于Task;
(2)、中斷的處理級別由一個或多個中斷優(yōu)先級組成;
(3)、中斷服務的流程有一個靜態(tài)分配中斷的優(yōu)先級標準;
(4)、對于中斷服務例程優(yōu)先級的分配取決于執(zhí)行和硬件結構;
(5)、Task優(yōu)先級是被用戶靜態(tài)分配的;
(6)、0是最低優(yōu)先級,數(shù)值越大優(yōu)先級越高。
2.2 Task的符合類
AUTOSAR OS根據(jù)不同的軟硬件需求,根據(jù)每個優(yōu)先級可能具備的任務個數(shù)以及需要的是基本任務還是擴展任務等來定義了四種符合類分別為BCC1,BCC2,ECC1以及ECC2。
BCC1與ECC1不支持多次任務激活請求且每個優(yōu)先級只能有一個任務;BCC2與ECC2既支持多次任務激活請求,同時也支持每個優(yōu)先級可以有多個任務。各種符合類之間的兼容關系如下圖所示:
(1)、BCC1(只對基本的Tasks,所有的Task有不同的優(yōu)先級,被限制只能有一個請求激活每個Task和每個優(yōu)先級只能有一個Task);
(2)、BCC2(象BCC1,但每個優(yōu)先級可以有多個Task和允許多個請求激活Task);
(3)、ECC1(象BCC1,增加擴展Tasks);
(4)、ECC2(象ECC1,但每個優(yōu)先級可以有多個Task和允許多個請求激活Basic Task);
03.
Task管理
3.1 Task狀態(tài)模式
AUTOSAR OS中存在兩種任務:基本任務(Basic Task)和擴展任務(Extended Task)?;救蝿談t存在以下三種狀態(tài):
(1)、運行狀態(tài)(Running):處于運行狀態(tài)的任務可能被高優(yōu)先級任務或者中斷搶占從而進入就緒狀態(tài),且同一Core中任何時刻只會存在一個任務處于運行狀態(tài),任務運行結束后則將自己掛起進入阻塞狀態(tài);
(2)、就緒狀態(tài)(Ready):??處于就緒狀態(tài)的任務由調(diào)度器決定是否啟動進入運行狀態(tài),且該狀態(tài)時任務切換至運行狀態(tài)的前提;
(3)、阻塞狀態(tài)(Suspend):?處于阻塞狀態(tài)的任務是被動的,可以由API函數(shù)或Alarm激活進入就緒狀態(tài);
(4)、等待狀態(tài)(Waiting):擴展任務與之相比,多了此狀態(tài)。當任務的運行需要等待某一或某些事件被置位時,任務進入就緒狀態(tài)。
基本任務與擴展任務的狀態(tài)機切換如下圖所示:
基本任務沒有等待狀態(tài),所以只能在任務啟動與終結時進行同步,基本任務的優(yōu)點就是占用較小的任務與執(zhí)行時間。
擴展任務則包含多個同步點,沒有同步請求的麻煩,當進一步的條件無法滿足時,任務則會切換至等待狀態(tài),其缺點也很明顯,會占用較多的內(nèi)存和執(zhí)行時間。
3.2 Task調(diào)度策略
3.2.1全搶占式調(diào)度
對于完全搶占式任務調(diào)度策略而言,當前運行的任務可在任何時刻被高優(yōu)先級任務打斷而被迫釋放處理器控制權,具備最高優(yōu)先級的任務從就緒狀態(tài)轉入運行狀態(tài),而當前任務被搶占從而進入就緒狀態(tài),同時保留現(xiàn)場環(huán)境,待下次運行時恢復。
如下圖所示為完全搶占式任務調(diào)度策略,TaskA為擴展任務,TaskB與TaskC為基本任務,優(yōu)先級TaskA > TaskB > TaskC。
場景1:
當前TaskC處于運行狀態(tài),當激活TaskB進入到就緒狀態(tài)時,由于TaskB優(yōu)先級高于TaskC,所以TaskC被迫釋放處理器控制權,調(diào)度器開始調(diào)度TaskB從就緒狀態(tài)變?yōu)檫\行狀態(tài),直到TaskB運行完成之后,在調(diào)度TaskC繼續(xù)運行。
場景2:
當前TaskC處于運行狀態(tài),激活TaskA與TaskB分別進入就緒狀態(tài),由于TaskA優(yōu)先級高于TaskB,所以TaskA搶占內(nèi)核運行, 但是由于Resource1仍被TaskC占用,而TaskA無法訪問到共享資源Resource1,則被迫進入到等待狀態(tài),TaskB開始運行。TaskB運行結束后掛起之后則重新運行TaskC,TaskC運行結束后釋放Resource1,進入TaskA得以由等待狀態(tài)轉入運行狀態(tài)。
此時你會發(fā)現(xiàn)高優(yōu)先級的任務TaskA由于共享資源被占用的原因導致不能先于TaskB運行的現(xiàn)象,該現(xiàn)象也被稱為優(yōu)先級反轉現(xiàn)象。
為了解決該問題,在此需要提到AUTOSAR OS的優(yōu)先級天花板模式:即將訪問共享資源的任務優(yōu)先級在占用資源的過程中提升至共享資源任務的最高優(yōu)先級之上,從而避免優(yōu)先級反轉現(xiàn)象的發(fā)生。
即若TaskC運行過程中占用共享資源Resource1,此時即使存在需占用共享資源的高優(yōu)先級任務TaskA被激活,也必須保證TaskC運行結束之后才能執(zhí)行TaskA,也就意味著在重要代碼執(zhí)行之前,應采用資源保護機制,以免被高優(yōu)先級的任務打斷。
3.2.2非搶占式調(diào)度
用非搶占式調(diào)度策略,那么當前運行狀態(tài)的任務在任何時刻都不會其他高優(yōu)先級任務所搶占,任務的切換只會發(fā)生在任務完成時。
非搶占式調(diào)度策略的問題在于任務執(zhí)行時間不確定,系統(tǒng)調(diào)度實時性較差。如下圖所示為非搶占式調(diào)度策略,可見即使高優(yōu)先級任務 TaskB被激活切換至就緒狀態(tài),也必須等到TaskC執(zhí)行結束之后才能夠被調(diào)度。
04.
Task 調(diào)度
4.1 AUTOSAR Task調(diào)度時序圖
在軟件架構設計時,為了保證CPU的負載率以及任務的前置條件,需要將每個SWC的Runnable進行定義,根據(jù)SWC的屬性進行設計,如下圖所示。
在原則上,需要定義一些主要規(guī)則:
(1)、SWC對時間要求不高的,盡量將Runnable的時間放長點。
(2)、相同Task的Runnable,可以設計多個Task,通過Offset的設置,避開同一周期的Task同時運行。
Task調(diào)度時序圖
4.2 AUTOSAR Task調(diào)度構成圖
在軟件架構設計時,為了讓軟件架構更加清晰,可以分成三類:
(1)、ECU在怠速和空轉時的任務處理;
(2)、ECU在上電或喚醒,下電或睡眠時的任務處理,以及總線收發(fā)通訊任務和消息處理任務;
(3)、ECU在Normal模式下運行時的任務處理(這里主要處理和執(zhí)行功能所需的任務);
Task調(diào)度構成圖
05.
AUTOSAR OS系統(tǒng)啟動
5.1 OS在OSEK規(guī)范中的啟動過程介紹
在處理器復位后,實施初始化過程,但是OS提供支持一個初始化的標準方法。OS和應用程序必須要清晰定義硬件初始化函數(shù)。
在OS初始化后,OS沒有強制定義一個需要啟動的特殊Task,但是允許用戶在系統(tǒng)創(chuàng)建時指定自動啟動的Tasks和Alarms。在CPU復位后,硬件標準應用函數(shù)被執(zhí)行(沒有操作系統(tǒng)介入)。???
例如,在OS被初始化后(調(diào)度程序沒有運行),StartOS調(diào)用鉤子函數(shù)StartupHook(),用戶可以在那里為他的OS增加一些初始化代碼。
基于啟動的應用模式,為了能在StartupHook()里結構化初始化代碼,為此提供了一個GetActiveApplicationMode的服務。
在從鉤子函數(shù)返回后,OS啟動中斷,并且開始調(diào)度程序。在這以后系統(tǒng)運行并且執(zhí)行用戶的Tasks 。
(1)、在復位后,用戶釋放執(zhí)行的(不可移植)特殊硬件代碼。到Phase5之前,Category 2的中斷不能運行;
(2)、調(diào)用StartOS;
(3)、OS執(zhí)行內(nèi)部啟動函數(shù);
(4)、調(diào)用鉤子函數(shù)StartupHook(),用戶可能會將初始化程序放在這里。在運行鉤子函數(shù)期間,所有的中斷需要被禁用;
(5)、OS激活用戶中斷和激活調(diào)度程序。對當前應用模式OS啟動自啟動的Tasks和聲明的Alarm。
自啟動的Tasks優(yōu)先級是未定義的,但是具有高優(yōu)先級。自啟動Tasks在自啟動Alarm前被執(zhí)行。
(6)、運行用戶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() 用于啟動所有任務。
06.
AUTOSAR OS系統(tǒng)關閉
6.1 OS在OSEK規(guī)范中的關閉過程介紹
規(guī)范中定義了一個服務以便關閉操作系統(tǒng),ShutdownOS。這個服務被應用或是操作系統(tǒng)嚴重錯誤時調(diào)用。
當ShutdownOS被調(diào)用時,操作系統(tǒng)將調(diào)用鉤子函數(shù)ShutdownHook(用戶通常在ShutdownHook自由的定義系統(tǒng)行為),然后再關閉系統(tǒng)。
6.2 OS在Vector模塊中的關閉過程介紹
(1)、停止CAN/LIN/ETH通信;
(2)、保存NVM數(shù)據(jù);
(3)、EcuM執(zhí)行休眠程序;
(4)、設置喚醒源;
(5)、EcuM執(zhí)行OS停止程序;
(6)、MCU進入休眠模式。
07.
AUTOSAR OS調(diào)試
兩個鉤子函數(shù)(PretaskHook和PostTaskHook)在Task上下切換時被調(diào)用,這兩個鉤子函數(shù)也許可以用來調(diào)試或時間的測試(包括上下切換時的時間)。
因此PostTaskHook在每次Task離開Running狀態(tài)時直接被調(diào)用,PreTaskHook是每次Task進入Running狀態(tài)時被直接調(diào)用。因為Task仍然/已經(jīng)在Running狀態(tài)下,所以GetTaskId不會返回INVALID_TASK。
如果PostTaskHook調(diào)用沒被定義在ShutdownHook之前或之后,當調(diào)用ShutdownOS同時Task正在運行ShutdownOS時,PostTaskHook可能會調(diào)用或不被調(diào)用。
08.
中斷處理
處理中斷(Interrupt Service Routine:ISR)的功能被分類為兩種ISR(中斷服務程序在OS中具有高于Task的優(yōu)級先級):
Category1
ISR 不需要OS接管,不受OS中斷優(yōu)先級等管理,在ISR完成后,處理程序繼續(xù)運行被中斷停止的指令,如中斷不會影響Task的管理。這種類型的ISRs開銷最少。
Category2
ISR需要OS接管,并受OS管理。OS提供一個ISR-Frame為專用用戶程序準備一個運行時環(huán)境,在系統(tǒng)創(chuàng)建時用戶程序被分配給中斷。
在中斷服務程序使用OS服務只限于下圖所示。
在ISR內(nèi)重調(diào)度不會發(fā)生。如果一個搶占式Task被中斷并且沒有其他的中斷被激活,重調(diào)度會在Category2終止后發(fā)生。
這個行為確認Task只有通過OS調(diào)度點才被執(zhí)行,為實現(xiàn)這一目標,可實施對所有類型的ISR限制中斷優(yōu)先級。
審核編輯:劉清
評論