?系列概述

OSEK是由歐洲自動化協會對汽車電氣制定的開放式系統，全程為OSEK/VDX。RTA-OS是基于OSEK OS的符合AUTOSAR規范的OS，是一種靜態可配置、搶占式實時操作系統(RTOS)，用于高性能、資源受限的應用程序。AUTOSAR OS主要包含Task, ISRs, Events, Resources, Application, Counter, Alarms, Schedule Table等OS對象。后續將對如上提到的八個對象進行分別介紹。本篇介紹的內容為Task，下面進入正題。

1.Task概述

任務調度分為靜態調度及動態調度，二者區別為，靜態調度是在調度前就已經配置好，而動態調度是根據負載率自動去調度的。在OSEK的OS系統中，Task是主要部分，RTOS里是靜態調度。對于多任務并發行為，與其為每個任務使用單獨的處理器，一個更經濟可行的方法是在單個處理器上一次只運行一個任務，不同任務之間進行切換。

2. 基本概念

2.1 調度RTAOS提供了一種根據提前固定好的不同優先級的任務間切換執行的調度方式。優先級排序的原則一般為：執行時間越短，執行頻率越快的優先級越高。

但無論選擇如何分配優先級，任務執行的順序都由調度策略決定。調度策略確定任務實際運行的時間。

AUTOSAR OS支持兩種調度策略：

2.1.1 搶占式調度

當一個Task正在運行，另一個更高優先級的任務準備運行，此時高優先級的任務會搶占執行，這也被稱為任務切換，高優先級任務執行完畢后，原來的task繼續執行。

對于所有任務都需要在運行時滿足其最后期限的系統，搶占式調度是最有效的調度策略，它將保證任務激活(準備運行)和終止之間的最短時間。此時間稱為任務的響應時間。搶占式的系統需要考慮對共享數據的搶占效應，并可能需要引入并發控制機制。

2.1.2 非搶占式調度

與搶占式調度不同的是，如果高優先級任務準備就緒，那么它將保持準備運行狀態，直到運行任務終止—它不會搶占。這意味著開始運行的非搶占式任務將始終運行到完成，然后終止。

2.1.3 協作式調度

實際上，AUTOSAR OS提供了對第三種稱為協作調度的調度的支持，因為它允許非搶占式任務告訴OS何時可以搶占。我們之所以說AUTOSAR OS支持兩種策略，是因為只有兩種配置—第三種配置必須自己構建。

操作系統運行準備運行的最高優先級任務。如果更高優先級的任務準備就緒，那么它將保持就緒，直到以下任一情況：1) 正在運行的任務終止(就像非搶占式調度一樣);2) 或者正在運行的任務發出Schedule()API調用，告訴操作系統它可以被搶占。當發出Schedule()調用時，優先級較高的任務會搶占正在運行的任務，任務切換被稱為已發生oc(就像搶占式調度一樣)。當高優先級任務完成后，搶占任務將恢復。通過精心設計，合作模式提供的系統雖然不如完全搶占式系統響應快，但不會出現非搶占式調度缺乏響應的情況。

2.2 基礎任務與擴展任務

當前項目中配置的除SecOC外的Task都是配置的BASIC

2.2.1 基礎任務

狀態：Running，Ready，Suspended。

基本任務開始、執行和終止(這通常稱為單次任務模型)。只有當基本任務終止或被更高優先級的任務搶占時，它才會釋放處理器。這種行為使它們非常適合嵌入式控制功能?；救蝿湛焖儆行?。

2.2.2 擴展任務

擴展任務啟動、執行、等待事件(Wait event)和(可選)終止。擴展任務在執行期間自動掛起自身任務的能力為任務提供了一種具有同步點的方法。此功能使擴展任務比基本任務更適合于需要中間執行同步(例如，等待用戶交互)的功能。

擴展任務時間響應較快，但會一直占用Ram資源，相當于以空間換時間。

2.2.3 Task State

Ready、Running 、(Waiting) 、Suspended

所有任務默認的狀態都是Suspended狀態，在被激活后才變成Ready狀態，當該任務為系統中的最高優先級任務時即轉為Running狀態，并開始執行任務，同時任務可能被更高優先級的任務搶占，重新變成Ready狀態。

任務通過終止返回到掛起(Suspended)狀態。一項任務可以在以后再次準備好，整個過程可以重復。

但是，擴展任務也可以進入Waiting狀態。當擴展任務通過等待事件自動掛起時，它將從Running狀態移動到Waiting狀態。

當擴展任務進入Waiting狀態時，操作系統將分派準備運行的最高優先級任務。設置事件后，任務將從Waiting狀態移動到Ready狀態。請注意，擴展任務返回到Ready狀態，而不是Running狀態。這是因為，在擴展任務處于Waiting狀態期間，其他一些更高優先級的任務可能已被激活，然后被調度。

Event只是用于為系統事件提供指示器的操作系統對象。事件示例包括數據準備好使用或正在讀取傳感器值。

激活Task的方式有：調用ActivateTask() API，或Alarm到期或調度表。

2.2.4 任務優先級

AUTOSAR-OS運行任務可以享有同一優先級，同一優先級的任務以先進先出FIFO(First In First Out)的原則從Ready狀態Release。

使用時需避免使用Share Priorities，實時性差，無法進行調度可行性分析。

2.2.5 隊列任務激活

在大多數情況下，僅需任務處于掛起狀態時激活它。事實上，AUTOSAR OS將處于就緒、運行或等待狀態的任務激活視為錯誤情況。

但是，在某些情況下，可能需要實現一個系統，該系統必須多次激活同一任務，但連續激活之間最短的時間可能小于運行該任務所需的時間。例如，用戶可能正在任務中解包CAN總線幀，并且需要處理網絡上幀的瞬時突發。這意味著用戶需要在運行時對任務激活進行排隊。

AUTOSAR OS允許對基本任務的激活進行排隊，以幫助構建此類應用程序。與AUTOSAR OS中的其他功能一樣，任務隊列的大小是靜態配置的。必須指定任務可以掛起的最大激活次數。如果超過激活的最大次數，激活將被忽略。

2.2.6 異步任務激活

AUTOSAR OS允許別的核激活當前核的Task，而不是從任務實際運行的核激活任務。雖然這可能很有用，但可能會影響性能.因為要完全符合AUTOSAR，所有任務激活(包括SetEvent)必須阻止調用方，直到任務狀態更新。在內部，操作系統必須使用內部自旋鎖來協調與所屬核的狀態更改。這會對所有核的性能產生重大影響。

2.3 一致性類

AUTOSAR OS對什么樣的功能可以一起使用有一些限制。這些被稱為一致性類，用于對任務特性進行分組，以便于理解，支持標準的部分實現，并為不同的應用程序類提供可伸縮性。

AUTOSAR-OS分成如下四種類型，其對應特性如下：

每個一致性類都需要更多的資源——BCC1系統比ECC2系統更快、更小。用戶無需擔心要使用哪個一致性類-RTA-OS支持所有一致性類，并將根據用戶的操作系統配置計算一致性類。

2.4 最大性能與最小內存

RTA-OS在最小化目標應用程序上的代碼和數據使用方面設計得非常積極。它將分析應用程序的特性，并生成一個僅包含所需特性的系統。

用戶對任務特征的選擇對最終應用的規模和速度有重大影響?！皼]有免費的午餐”，因此，當用戶向應用程序中添加使用更高級任務類型的任務時，系統將不可避免地變得稍大、稍慢。

為系統運行更有效率，同時在使用過程中應盡量使用BCC1，盡量少使用BCC2及擴展任務。

因為：同優先級的，隊列等待任務;擴展任務需要等待都會影響運行效率。

3. Task 配置

包括：name、Priority、Scheduling、Activation及Autostart

優先級：0是最低優先級，

調度：任務可以完全搶占或非搶占地運行。一般來說，為了獲得最佳的應用程序性能，應該選擇完全搶占式調度而不是非搶占式調度。

激活：在Ready狀態下可以排隊的最大任務激活數。對于BCC1、ECC1和ECC2任務，激活次數始終為一次。這意味著這些類型的任務只有在處于掛起狀態時才能激活。在未掛起的情況下，嘗試激活此類任務將導致錯誤。大于1的值表示操作系統將對激活進行排隊，任務結束時再次激活。

3.1 調度原則

低優先級的任務會被高優先級任務搶占;

對于協作式調度，低優先級的任務可為低優先級聲明一段時間，在該時間段內不能被高優先級任務搶占，但仍可能被中斷打斷。

通常，使用非搶占性任務的系統的響應性比搶占性運行的系統差。

經常會發現，不必使用不可搶占的任務，因為用戶可以使用其他更合適的方法來實現更靈敏的系統?？墒褂玫氖侄伟ǎ?/p>

?使用標準資源序列化對數據或設備的訪問。

?使用內部資源精確指定哪些其他任務不會導致搶占。

3.2 隊列激活(僅針對BCC2)

在大多數情況下，用戶將僅在任務處于掛起狀態時激活它。但是，用戶可能需要實現一個系統，在該系統中，同一任務必須被多次激活，并且連續激活之間的最短時間小于運行該任務所需的時間。

如果發生這種情況，用戶將在任務處于就緒狀態或正在運行狀態時激活該任務。這意味著激活將丟失。要防止激活丟失，必須指定任務所需的最大多次激活次數。

根據AUTOSAR OS標準，此功能僅適用于基本任務。不能指定 擴展任務的多個激活。

當指定多個激活時，RTA-OS會自動識別任務為BCC2。構建應用程序時，RTA-OS將計算每個BCC2任務所需的多激活隊列的最大大小。

當BCC2任務共享優先級時，RTA-OS使用FIFO隊列來保存掛起的激活。如果BCC2任務在AUTOSAR OS應用程序中具有唯一的優先級，則RTA-OS會自動優化排隊策略，使其達到最佳優先級激活。計數激活比FIFO激活更有效，應盡可能使用。

3.3 自動開始的任務

自動啟動主要用于啟動Waiting Event的擴展任務，因為它不需要編寫代碼來激活任務。

4. 堆棧管理

RTA-OS使用單棧模型，即所有的Task、ISRS在同一個堆棧區域上運行。

當任務運行時，其堆棧使用量會像正常情況一樣增減。當任務被搶占時，高優先級任務的堆棧使用將在同一堆棧上繼續(就像標準函數調用一樣)。當任務終止時，它使用的堆?？臻g將被回收，然后重新用于下一個優先級最高的任務運行(同樣，與標準函數調用一樣)。下圖顯示了單堆棧在聲明、搶占和終止任務時的行為。

在單堆棧模型中，堆棧大小與系統中優先級的數量成比例，而不是與任務/ISR的數量成比例。這意味著，直接或通過共享內部資源，或通過被配置為非先發制人，共享優先級的任務永遠不會同時出現在堆棧上。在硬件上共享優先級的ISR也是如此。這意味著用戶可以通過簡單的配置更改來交換系統響應性，即任務或ISR完成所需的時間，以換取堆棧空間。

上圖顯示了同一任務集的執行情況，具有與上上圖相同的到達模式，但這次任務是非搶占式調度的?？梢钥吹剑邇炏燃壢蝿盏捻憫獣r間比搶占式調度時長得多，但總體堆棧消耗要低得多。

單堆棧模型還顯著簡化了鏈接時的堆棧空間分配，因為用戶只需為整個系統堆棧分配單個內存部分，就像根本不使用操作系統一樣。

4.1 擴展任務的堆棧管理

RTA-OS獨特地擴展了單堆棧模型，在不影響基本任務性能的情況下為擴展任務提供支持。

在RTA-OS中，擴展任務的生命周期如下：

Suspended→Ready：任務被添加到Ready 序列

Ready→Running：任務已調度，但與內容位于堆棧頂部的基本任務不同，內容位于堆?？臻g中，所有低優先級任務的預先計算的最壞情況搶占深度處。

Running→Ready：擴展任務被搶占。如果搶占任務是一個基本任務，那么它會像往常一樣在堆棧頂部調度;如果搶占任務是一個擴展任務，那么它將按照預先計算的所有低優先級任務的最壞情況搶占深度進行調度。

Running→Waiting：任務的等待事件堆棧內容(包括操作系統上下文、本地數據、函數調用的堆棧幀等)保存到內部操作系統緩沖區中

Waiting→Ready：任務添加到Ready 隊列

Running→Suspended：任務的“等待事件堆?！眱热輰膬炔坎僮飨到y緩沖區復制回堆棧中所有低優先級任務預先計算的最壞情況搶占深度。

擴展任務管理要求RTA-OS知道任務和ISR使用了多少堆棧。以下各節描述了各種配置參數。

4.2 強制堆棧信息

計算出的最壞情況分派點定義了需要啟動擴展任務的字節數，該字節數與調用StartOS()時堆棧指針的地址有關。這些偏移量作為ROM數據存儲在擴展任務控制塊中，并在運行時添加到堆棧的基址。

4.3 指定任務分配Task

在僅包含基本任務的系統中，除非用戶正在進行堆棧監控，否則無需告知RTA-OS任何堆棧分配。只需在鏈接器/定位器中為應用程序分配足夠大的堆棧部分。這是單堆棧體系結構的優點之一。

對于使用擴展任務的應用程序，用戶可以像以前一樣分配Linker部分，但用戶還必須為RTA-OS中每個優先級低于最高優先級擴展任務的任務分配堆棧，即使它們是基本任務。RTA-OS使用堆棧分配信息為每個離線擴展任務計算最壞情況下的搶占點。

雖然RTA-OS使用單堆棧模型，但在某些端口上，這并不一定意味著只使用一個物理堆棧?？赡苁蔷幾g器或硬件自動將數據強制到不同的堆棧上。例如，TriCore設備使用CSA內存快速保存調用context。

即使有多個物理堆棧，RTA-OS仍然提供了單堆棧體系結構的好處——當任務和/或ISR共享優先級時，每個物理堆棧上所需的堆?？臻g可以重疊。但是，要使堆棧分配正常工作，需要指定每個堆棧上所需的空間。如果用戶配置，RTA-OS將要求用戶提供多個堆棧值

4.4 處理堆棧溢出

如果用戶提供給RTA-OS的堆棧分配太小(運行時錯誤的潛在來源)，有三種錯誤情況可能發生：

1.當RTA-OS嘗試調度擴展任務時，堆棧指針的當前值高于計算的最壞情況調度點，因此擴展任務無法啟動。這意味著堆棧上的一個(或多個)低優先級任務占用了太多空間。

2.擴展任務無法從等待狀態恢復，因為堆棧指針高于它應該的值。當為擴展任務正在等待的事件調用SetEvent()并且擴展任務現在是系統中優先級最高的任務時，可能會發生這種情況。

3.擴展任務無法進入等待狀態，因為任務正在使用的堆棧的當前數量大于配置的“WaitEvent()堆?！钡拇笮?。

當RTA-OS檢測到擴展任務堆棧管理出現問題時，它將調用ShutdownOS()，錯誤代碼為E_OS_STACKFAULT。如果要調試該問題，則可以啟用堆棧故障Hook。

配置后，RTA-OS將在堆棧故障發生時調用用戶提供的回調OS_Cbk_StackOverflowHook()，而不是ShutdownOS()?；卣{傳遞了兩個參數：溢出的字節數、溢出的原因。

5. 任務的控制

5.1任務執行

任務類似于C函數，在RTA-OS調用它們時實現某種形式的系統功能。

當任務開始運行時，從任務輸入函數開始執行。任務輸入函數是使用示例4.2中的C語法編寫的。

注意，基本任務是一次性完成的。這意味著他們從固定的任務入口點開始執行，并在完成時終止。

5.2 任務激活

任務激活后變為Ready狀態，當該任務的優先級為所有Ready狀態的任務及當前處于Running的任務中最高時，開始(或搶占)變成Running狀態。

任務每次被激活后會運行一次，當激活的次數超過配置次數時會報E_OS_LIMIT錯誤。

任務可以通過Tasks或二類中斷激活。

5.2.1 直接激活

可以通過多種不同的方式激活任務。任務激活的基本機制是ActivateTask()API調用，它直接激活任務。ActivateTask(TaskID)調用將命名任務置于就緒狀態。ChainTask(TaskID)終止當前正在運行的任務(參見第4.11節)，并將激活指定任務置于就緒狀態。

#include  TASK(Task1)  {  /*  Task1  functionality.  */  ActivateTask(Task2);  TerminateTask();}TASK(Task2)  {  /*  Task2  functionality.  */  ActivateTask(Task3);  TerminateTask();}TASK(Task3)  {  /*  Task3  functionality.  */  TerminateTask();}

5.2.2 間接激活

通過Alarm激活或通過調度表激活。

通過Alarm激活：對于系統中的每個Alarm，可以指定一個任務，該任務在每次Alarm過期時激活。

調度表激活：對于系統中的每個調度表，可以指定在表上的一個或多個到期點激活的任務。

5.3 任務執行順序控制

許多情況下，需要控制任務執行的順序，即某個任務的執行需要基于前一個任務執行的結果。時序的控制可以通過如下三種方式：

?直接激活鏈;

?優先級;

?不可搶占的任務。

5.3.1 直接激活鏈

當使用直接激活鏈控制執行順序時，任務對必須在發出調用的任務之后執行的任務進行ActivateTask()調用。

5.3.2 通過任務優先級

將需要優先執行的任務設置更高的優先級，在執行時即可按搶占式完成。

5.4 RTA-OS中的合作式調度

當任務以非搶占方式運行時，它會阻止任何任務(包括優先級較高的任務)執行。然而，有時對于非搶占式任務來說，提供可以進行重新調度的明確位置是很有用的。這比簡單地非搶占式運行更有效，因為高優先級任務對系統刺激的響應時間更短。任務以非搶占方式運行并為重新調度提供點數的系統稱為合作調度系統。

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

注：該應用形式，在搶占式調度中Schedule();沒有意義。

5.5.任務終止

在AUTOSAR操作系統中終止的任務必須進行API調用，以告知操作系統正在發生這種情況。AUTOSAR OS標準定義了兩個用于任務終止的API調用。其中之一必須用于終止任何任務。這些API調用是：

? TerminateTask()

? ChainTask(TaskID)

當任務完成時，它必須進行其中一個API調用。這確保RTA-OS可以正確地安排準備運行的下一個任務。

TerminateTask()強制調用任務進入掛起狀態。RTA-OS將在Ready狀態下運行下一個優先級最高的任務。

ChainTask(TaskID)終止調用任務并激活任務TaskID。因此，該API類似于執行TerminateTask()，然后立即執行ActivateTask(TaskID)。鏈接任務會將命名任務置于就緒狀態。

5.5.1 RTA-OS中的終端優化

AUTOSAR OS標準允許任務在任何時候調用任務終止API調用，包括在一組深度嵌套的函數調用中。這是一種糟糕的編程實踐，相當于使用goto。在運行時，RTA-OS必須存儲信息，以便在任務終止于entry函數以外的其他位置時清除堆棧。這通常是使用setjmp/longjmp對完成的。

然而，單堆棧體系結構的一個關鍵好處是，在其entry函數中終止的任務可以簡單地返回TerminateTask()而無需執行任何操作。

RTA-OS允許用戶使用快速終止優化(Optimizations?fast Terminate)利用良好的應用程序設計。當所有執行TerminateTask()或ChainTask()API的任務僅在其entry函數中執行時，可以啟用此優化。優化告訴RTA-OS不要生成代碼來保存不必要的上下文，從而節省堆?？臻g。

5.6 任務的Idle機制

在任何搶占式OS中，當沒有Task或中斷運行時也必須有些事情要做。在AUTOSAR OS中是通過Idle 機制實現。在RTA-OS中當沒有Task或中斷執行時，系統將處于繁忙的等待循環中。

用戶可以通過聲明一個名為Os_Cbk_idle的回調來提供自己的空閑機制實現，從而覆蓋默認行為。

Os_Cbk_idle的行為較普通Task外有如下不同：

不能被激活

不能被終止

不能被鏈(嵌套)調用

不能使用內部資源

Os_Cbk_Idle的優先級最低，即當沒有任何任何及中斷運行時才會Ready to Run。

Os_Cbk_Idle在退出時返回一個布爾值，告訴RTA-Os是否再次調用Os_Cbk_Idle。當返回TRUE時，RTA-OS將立即再次調用Os_Cbk_Idle。當返回FALSE時，RTA-OS停止調用Os_Cbk_Idle并進入繁忙等待循環的默認行為。

6. 任務前與任務后Hooks

假設用戶需要在每個任務開始之前和/或在每個任務結束之后執行一些代碼，例如，以提供執行跟蹤。用戶可以使用AUTOSAR OS提供的PreTask和PostTask Hook來實現這一點。

每當任務進入運行狀態時，RTA-OS就會調用預任務Hook。這意味著在搶占后，每當任務恢復時，也會調用預任務Hook。

每當任務移出運行狀態時，RTA-OS就會調用PostTaskHook。任務終止時，每次任務被搶占時，都會調用PostTaskHook。

需要配置后才能使用該功能，用于在運行時對應用程序進行配置。

原文標題：RTA-OS系列介紹-Task

文章出處：【微信公眾號：汽車ECU開發】歡迎添加關注!文章轉載請注明出處。
審核編輯：湯梓紅