Autosar Os overview

Autosar Os 在Autosar 框架中上至RTE 下至驅動，中間可以和BSW 基礎模塊進行交互。是整個autosar 框架下最重要的組成部分。

其中Syser Services 為一些系統服務，不屬于操作系統。下文僅對 Os 進行描述

OS 與 BSW 各模塊關系

雖然說OS 是整個框架的靈魂，但是也有極少數的BSW 模塊不與OS 直接交互。換句話說，其他BSW 模塊在改動的時候，是需要考慮一下OS 對其的影響，和它對OS 的影響。

這里可以看到除了cdd 都是無限制的與os交互。只有cdd 是有限制的和os 進行交互。

OS 的類別與其功能

AUTOSAR OS 和 OSEK OS 都是為汽車領域而開發的實時操作系統。雖然它們都致力于提供實時性能、可靠性和穩定性，但其設計理念和實現方式有所不同。AUTOSAR OS 旨在提供更高級的軟件體系結構和更多的配置選項，以支持更復雜的汽車軟件系統；而 OSEK OS 更加簡單和輕量級，適用于較小規模的汽車電子系統。兩者可以共存，也可以相互補充，以滿足不同汽車應用的需求。

TASK

OS 的task 分為兩種。

-- 基本任務

-- 擴展任務

其主要的區別就是有無waiting狀態。這里先表示一下基本狀態，下面對其使用棧詳細描述可以按需在實際架構中設計，使用。

TASK - 搶占機制

01非搶占

這里可以看出，當任務被設定為非搶占的時候，當任務沒有完成時，即使高優先級的任務到來，也無法將其搶占。

一般情況下我們可以把初始化的任務，以及一些模式切換時候，必須進行的一些操作，這類任務設計成非搶占的任務。

02搶占

為了更好的利用OS 來壓榨硬件資源，大部分的任務都會被設計成搶占式任務。一般的原則，重要的任務優先級高，需要運行時間較短的任務優先級高。

03合作

這里就很靈活，但是需要在代碼過程中設計好什么時候讓出CPU。但是處理得好的話，會拖慢CPU， 無法最大限度的壓榨硬件，高優先級的任務被耽誤。

#include 
TASK(Cooperative)
{Function1();
  Schedule();/* Allow preemption */
  Function2();
  Schedule();/* Allow preemption */
  Function3();
  Schedule();/* Allow preemption */
  Function4();
  TerminateTask();
}

任務在配置過程中最重要的下面幾個參數，需要注意。這里尤其要注意使用棧的大小。因為這個真的有可能會讓軟件運行奔潰。其他的參數最多是運行不正常。

TASK - 棧的使用

Autosar os的棧使用是單一棧策略。假設定義了32k的棧。那么所有的task都使用這一個大的棧空間。那就是說，當有任務搶占的時候，棧是疊加使用的。下面是

搶占時候使用的棧情況。

這里可以看出來，當有高優先級的任務運行的時候，棧的使用空間是一直增大的。這時候就需要注意上面定義的32k 夠不夠用了。因為他們所有的task公用一個棧。

下面是非搶占時候使用棧的情況。

這里就相對簡單多了，棧的使用就是和當前運行的task所需要的棧的情況是一樣的。

前面說到擴展任務的情況呢。

這里操作系統會根據靜態配置的任務使用的棧，進行預留。換句話說就是配置完擴展任務后，os 根據優先級比擴展任務優先級高的任務使用棧的最大總和，預留一下。把擴展任務的棧至于棧底 + 最大使用量。當擴展任務到running狀態后，直接就在規定的棧地方運行。所以這里很考驗前面的所有task的棧，如果是使用超了，這時候程序必然就崩了。

中斷

Interrupt

Category 1

?Os 無法給一類中斷提供服務

?一類中斷不與Os交互

?一類中斷優先級高于Os 以及所有的二類中斷

?可以通過Os 接口對一類中斷進行enable/disable

Category 2

?二類中斷受到Os管控

?硬件中斷向量指向Os內部

?有限制使用os 接口不允許 TerminateTask, WaitEvent, ClearEvent, Schedule, ChainTask

下圖可以看出來一類中斷時獨立于os的，高于os的。根據不同的芯片是不同的，有的芯片的中斷優先級是組類別，有的是獨立的。也就是說中斷是否可以嵌套。

下面是當二類中斷發生，這時候我們的os將會怎么處理呢。

當硬件終端觸發，并且ICU模塊處理完成之后，到達了OS 。這時候OS 根據靜態配置進行操作，對上下文進行切換與保存現場。

在配置過程中很簡單，但是對于實際的操作我們需要注意優先級，一般情況我們都會使用二類中斷。這樣會減少os的影響。減少系統的不可控性。

如何有效率的使用中斷。

#include 
ISR(InefficientHandler) {
/* Long handler code. */
}


#include 
ISR(EfficientHandler) {
ActivateTask(Task1);
}
TASK(Task1) {
/* Long handler code. */
TerminateTask();
}


#include 
ISR(Interrupt1) {
/* Dismiss the interrupt where required */
/* Rest of the handler */
}

異步處理，不將中斷的回調一直處理完。而是激活一個task，進行處理，當然這也是要根據實際場景進行設計。

resource

Resource 基礎介紹

?Standard resource 標準的二進制狀態

?Linked resource 可以嵌套的二進制狀態

?Internal resource 以任務為基礎的二進制狀態

Standard resource 標準的二進制狀態 具體使用

#include 
TASK(Task1) {
...
GetResource(Resource1);
/* Critical section. */
ReleaseResource(Resource1);
...
TerminateTask();
}

代碼片段：可切換語言，無法單獨設置文字格式

可以看出這類是最簡單的，一個get 一個 release. 中間的 就是會被鎖住的資源。其他地方無法進行訪問。需要這個release之后才可以。

Linked resource 可以嵌套的二進制狀態

#include 
GetResource(Resource1);
   GetResource(Resource2);
     GetResource(Resource3);
     ReleaseResource(Resource3);
   ReleaseResource(Resource2);
ReleaseResource(Resource1);
}

代碼片段：可切換語言，無法單獨設置文字格式

和上面很相似，不過必須是一個對應一個。一個解開一個。

舉個例子錯誤使用

#include 
TASK(Write){
 /* Highest priority .*/
 WriteBuffer();
 GetResource(Guard);
 BufferNotEmpty = True;
 ReleaseResource(Guard);
 ChainTask(Read);
}
TASK(Read){
/* Lowest priority. */
 ReadBuffer();
 GetResource(Guard);
 if( BufferNotEmpty ) {
 ReleaseResource(Guard);
 ChainTask(Read);
 } else {
 ReleaseResource(Guard);
 TerminateTask();
 }
}

tips: 任務結束前，沒有release.

Schedule table

區別于rtos, 這里有調度表，屬于靜態配置的調度器。可以說是一系列的event的組合。

下面也給了schedule table 和 event的對比。用起來相當的方便。

這里簡單介紹兩個schedule table 的api

?Start absolute point

?Start relative point

一般情況下我們系統里只需要一條schedule table即可。所以這些api 在外部用的也很少。這里只需要直到，如果當架構設計需要多條schedule table的時候，我們可以通過一系列條件，手動的調度起來。讓這上面的point 內部的task 以此運行。

配置

配置也相對比較簡單。也基本不需要配置，因為在左外SWC 設計，完成RTE 的配置之后。這個table的屬性就已經被定義好了。只是通過OS 將其生成代碼。

stack monitor 棧監控

最上面提到task的一個配置參數，棧的使用。

這里面就是可以激活OS 對棧使用的監控。os將會自動monitor

下面截取一段代碼，解釋了一下os如何獲取棧的使用情況。在使用過程中，我們用戶可以利用這個api進行一些自己的monitor.

當然實現方式千千萬，我們還是要了解一下實際的原理。

下圖可以看出來。不同地方調用 GetStackUsage結果可能是不同的。

所以一般來說，我們可以選擇高優先級的任務進行執行該api. 進而獲取

time protection 時間保護

對于時間保護我們一般采類似于下面的時間約束。

這是什么意思呢。

1ms的任務 如果在5ms內 沒有被執行完，則認為有問題。

3ms的任務 如果在10ms內沒有被執行完，則認為有問題。

5ms的任務 如果在15ms內沒有被執行完，則認為有問題。

下面有個例子。

看似是C 沒有執行完。確實os 報錯 應該報的是C 任務沒有規定時間內完成。

但是原因缺失上面的A 和 B。所以實際情況，還是需要根據調度關系進行分析。問題不一定處在報錯的任務。

關于配置方面也很簡單。

memory protection 內存保護

內存保護的機制通過os-application 的 trust 和 non-trust 進行隔離開。

對讀寫的限制，對運行的隔離。

當其中一個os-application 發生故障，可以獨立的關閉其中一個os-application ,其他的os-application 不受影響。

對外設的訪問，對內存特殊區域的訪問的約束。可以通過trust non-trust 來約束。

這樣可以一定程度上減少 讓os崩潰的可能發生

審核編輯：湯梓紅