前言

本系列文章將以RTA-OS為例詳細介紹AUTOSAR OS標準及概念，并分享實際使用的一些案例，本文為符合AUTOSAR標準的RTA-OS功能簡介。

正文

1.Introduction

RTA-OS是一種靜態(tài)可配置的搶占式實時操作系統(tǒng)(RTOS)，用于高性能、資源受限的應用程序。RTA-OS是開放標準AUTOSAR R3，AUTOSAR R4.0(包括多核)，AUTOSAR R4.1, AUTOSAR R4.2, AUTOSAR R4.3, AUTOSAR R4.4和AUTOSAR R4.5 (R19-11)操作系統(tǒng)規(guī)范的完整實現(xiàn)，也完全符合OSEK/VDX操作系統(tǒng)標準版本2.2.3。OSEK現(xiàn)已在ISO 17356中標準化。

RTA-OS內核被設計成:

high performance（高性能）: 內核非常小，速度非常快。內核的內存占用及其運行時性能是同類OS中領先的，使得RTA-OS特別適用于大量制造的系統(tǒng)，在這些系統(tǒng)中，必須滿足對硬件成本的非常嚴格的限制，并且任何最終產品都必須正確運行。

RTA-OS提供了許多獨特的優(yōu)化，有助于降低系統(tǒng)的單位成本。內核對所有類型的任務都使用了單堆棧體系結構。與傳統(tǒng)的每個任務的堆棧模型相比，這節(jié)省了大量的RAM。此外，仔細的應用程序設計可以利用單堆棧體系結構來提供顯著的堆棧RAM節(jié)省。

離線工具分析您的操作系統(tǒng)配置，并使用這些信息構建盡可能小且最快的內核。您不打算使用的代碼被排除在內核之外，以避免浪費執(zhí)行時間和內存空間。

real-time（實時）: 傳統(tǒng)的RTOS設計通常具有不可預測的開銷，通常取決于任務的數(shù)量和系統(tǒng)在每個時間點的狀態(tài)。這使得保證實時可預測性變得困難——無論內核有多“快”。在RTA-OS中，內核是快速的，而且所有的運行時開銷——比如切換任務、處理中斷和喚醒任務——都有較低的最壞情況邊界，執(zhí)行時間很少或沒有變化。在許多情況下，上下文切換發(fā)生在恒定的執(zhí)行時間內，這意味著RTA-OS可以用于開發(fā)硬實時系統(tǒng)，其中必須在特定的時間期限內做出響應。滿足嚴格的截止日期包括計算每個任務和中斷服務例程（ISR）的最壞情況響應時間，并確保每次都按時運行。RTA-OS是一個真正的RTOS，因為它滿足了固定優(yōu)先級可調度性分析的假設。

portable（可移植性）: RTA-OS可用于各種各樣的微控制器/編譯器組合（or port）。所有端口共享相同的公共RTA-OS代碼，這約占總內核功能的97%。該內核是用與MISRA-C 2012兼容的ANSI C編寫的。通過離線工具，可以生成RTA-OS的MISRA報告。

RTA-OS盡可能地不會對硬件施加控制。一般來說，不需要移交對硬件的控制，比如緩存、監(jiān)視器計時器和I/O端口。因此，您的代碼可以自由地使用硬件，從而允許將遺留軟件集成到系統(tǒng)中。

圖1.1：RTA-OS Product Architecture

RTA-OS產品體系結構如圖1.1所示，它包括：

lrtaoscfg是一個圖形配置工具，它用自動sarXML配置語言讀取和寫配置。

lrtaosgen是一個命令行工具，用于從輸入配置生成RTA-OS內核庫。

l端口插件，一個用于您使用RTA-OS的每個目標/編譯器組合。您可以同時安裝多個端口，并根據(jù)需要在它們之間進行切換。您還可以同時安裝同一端口的多個版本，從而允許您輕松地管理使用遺留編譯器和/或微控制器的項目。

VRTA是一個特殊的端口插件，在標準Windows PC上提供RTA-OS功能。這允許您在不需要實際目標硬件的情況下設計和測試應用程序行為。VRTA提供了一個開發(fā)工具包，允許您構建虛擬ecu，可以模擬中斷，I/O等。

VRTA可用于模擬多核AUTOSAR應用程序。

1.1 Features of the RTA-OS Kernel

RTA-OS基于早期ETAS操作系統(tǒng)的成熟技術，迄今為止，該操作系統(tǒng)已在全球超過3.5億個ecu中使用。內核提供了AUTOSAR R3.x,AUTOSAR R4.0, AUTOSAR R4.1, AUTOSAR R4.2, AUTOSAR R4.3, AUTOSAR R4.4和AUTOSAR R4.5 (R19-11)開放標準的實現(xiàn)。這些標準從早期的OSEK OS標準中提取了功能。內核還提供了許多RTA-OS獨有的附加特性。下面幾節(jié)簡要介紹了這些標準及其特性。

1.1.1OSEK

OSEK是歐洲汽車行業(yè)標準，致力于為汽車電子產品生產開放系統(tǒng)接口。該項目的全名為OSEK/VDX。OSEK是由德語中的一個短語組成的首字母縮寫，翻譯為汽車電子產品的開放系統(tǒng)和相應的接口。VDX基于法國標準（車輛分布式執(zhí)行），現(xiàn)在已與OSEK合并。OSEK/VDX在本指南中被稱為OSEK。

OSEK的目標是支持跨多個項目的軟件組件的可移植性和可重用性。這使得供應商可以專注于汽車知識產權，因此供應商可以開發(fā)純軟件解決方案，并在任何符合osek的ECU中運行軟件。

然而，為了達到這個目標，需要對每個非應用程序特定組件的接口進行詳細的規(guī)范。因此，OSEK標準包括一個應用程序編程接口（API），它從底層硬件和車載網(wǎng)絡配置的具體細節(jié)中抽象出來。

OSEK OS

OSEK操作系統(tǒng)是OSEK標準中最成熟和應用最廣泛的一種。OSEK操作系統(tǒng)已被應用于所有類型的汽車ecu中，從動力系統(tǒng)、底盤和車身到多媒體設備。

OSEK操作系統(tǒng)的最新版本是2.2.3，這是2001年9月最初引入的2.2標準的第三個小版本。這個版本的OSEK OS也是ISO17356標準的一部分。

OSEK OS完全使用一種稱為OIL（OSEK實現(xiàn)語言）的離線配置語言進行靜態(tài)定義。由于所有對象在系統(tǒng)生成時都是已知的，因此實現(xiàn)可以非常小和高效。

OSEK操作系統(tǒng)提供了以下操作系統(tǒng)功能：

任務(Task)是OSEK操作系統(tǒng)系統(tǒng)的主要組成部分。與其他操作系統(tǒng)不同的是，OSEK中的任務不需要自我調度（也就是說，不需要將任務的主體放在一個無限循環(huán)3中）。在OSEK操作系統(tǒng)中有四種類型的任務：

l具有唯一優(yōu)先級和非排隊激活的基本任務（Basic taskswith unique priority and non-queued activation）。這些都是最簡單的任務形式，非常適合用于硬實時系統(tǒng)。一旦任務被激活，它必須運行并終止，然后才能再次被激活。這種類型的任務不能在執(zhí)行中途掛起自己以等待事件。在RTA-OS中，這些任務被稱為BCC1任務，因為它們對應于OSEK OS的BCC1一致性類（conformance class）（有關OSEK的一致性類的更多細節(jié)，請參閱第4.3節(jié)）。

l具有共享優(yōu)先級和排隊激活的基本任務（Basic taskswith shared priority and queued activation）。這些任務可以與系統(tǒng)中的其他任務共享優(yōu)先級，并且在再次被激活之前不需要終止。操作系統(tǒng)排隊等待任務激活的隊列，并在當前激活終止時運行下一次激活。與BCC1任務一樣，這種類型的任務不能在執(zhí)行過程中掛起自己以等待事件。在RTA-OS中，這些任務被稱為BCC2任務，因為它們對應于OSEK OS的BCC2一致性類。

l具有唯一優(yōu)先級的擴展任務（Extended taskswith unique priorit）。允許擴展任務在執(zhí)行過程中等待事件（即，該任務可以自掛起）。但是，激活不能被排隊，并且任務必須具有唯一的優(yōu)先級。在RTA-OS中，這些任務被稱為ECC1任務，因為它們對應于OSEK OS的ECC1一致性類。

l具有共享優(yōu)先級的擴展任務（Extended tasks with shared priority.）。這些任務類似于ECC1任務，但可以與系統(tǒng)中的其他任務共享優(yōu)先級。在這方面，它們類似于BCC2的任務。然而，與BCC2任務不同的是，擴展任務不能有排隊激活。在RTA-OS中，這些任務被稱為ECC2任務。

系統(tǒng)可以包含上述任務類型的任何組合。

調度（Scheduling）任務可以預先調度或非預先調度，并且可以很容易地構建協(xié)作調度器。

中斷（Interrupts）允許操作系統(tǒng)與異步外部觸發(fā)器的交互。

在OSEK OS中有兩種類型的中斷：

1.第一類中斷（Category 1 interrupts）不由操作系統(tǒng)處理；

2.第二類中斷（Category 2 interrupts）是由操作系統(tǒng)處理，并可以與之交互。

資源（Resources）是簡單的二進制信號量，允許在任務和中斷之間共享的臨界區(qū)上提供互斥。資源由操作系統(tǒng)使用優(yōu)先級天花板協(xié)議進行管理，該協(xié)議保證不出現(xiàn)死鎖，并最大限度地減少運行時的優(yōu)先級反轉。

Note: 優(yōu)先級反轉是指低優(yōu)先級任務優(yōu)先于高優(yōu)先級任務運行的情況。使用優(yōu)先級上限協(xié)議，這種情況最多在高優(yōu)先級任務被激活時發(fā)生一次(并且總是在執(zhí)行開始)，并被稱為高優(yōu)先級任務的阻塞時間。阻塞時間受限于任何單個任務與高優(yōu)先級對象共享數(shù)據(jù)的最長時間——由于低優(yōu)先級任務的交互而不存在累積阻塞。

計數(shù)器和告警（Counters and alarms）用于提供周期性(和非周期性)的任務調度。計數(shù)器，顧名思義，計數(shù)(domain specific)事件的發(fā)生，并將值寄存器為“ticks”?？梢詫⒏婢O置為運行時可配置的計數(shù)值，可以是絕對計數(shù)值，也可以是設置告警時相對于計數(shù)器的“tick”值。

調試支持（Debugging Support）通過使用構建級別在操作系統(tǒng)中提供。操作系統(tǒng)提供了兩種構建級別:

1.標準（Standard）是“精簡和平均”，并提供最小的錯誤處理。

2.擴展（Extended）是“調試”版本，它提供了廣泛的錯誤檢測功能，以檢查是否正確使用操作系統(tǒng)。

調試也通過OSEK ORTI (OSEK運行時接口)標準提供。這為操作系統(tǒng)實現(xiàn)提供了一種通用的方法，可以將符號詳細信息導出到第三方調試器，以便調試器可以在運行時顯示關于操作系統(tǒng)內部狀態(tài)的信息(例如，哪個任務正在運行，哪些任務準備運行等)。

1.1.2AUTOSAR

AUTOSAR(汽車開放系統(tǒng)架構)是一個開放和標準化的汽車軟件架構，由全球汽車制造商、供應商和工具開發(fā)人員共同開發(fā)。

AUTOSAR為基本軟件模塊(BSW)提供規(guī)范，如操作系統(tǒng)、通信驅動程序、內存驅動程序和其他微控制器抽象套件。AUTOSAR標準還定義了一個基于組件的體系結構模型。該模型定義了虛擬功能總線(VFB)，它定義了應用軟件組件+(SW-Cs)之間通信的抽象。VFB允許sw - c獨立于底層硬件，使其在不同的ecu之間可移植，并在多個汽車項目中可重用。VFB抽象由AUTOSAR運行時環(huán)境(RTE)進行封裝。RTE提供sw - c和BSW之間的“膠水（glue）”。

AUTOSAR操作系統(tǒng)是OSEK操作系統(tǒng)規(guī)范的擴展。AUTOSAR操作系統(tǒng)包括OSEK操作系統(tǒng)的所有特性，并添加了一些新功能，這些功能分為以下四個可伸縮性類:

可伸縮性類1（Scalability Class 1）包括OSEK OS加:

調度表（Schedule Tables）--在編程重復活動時，調度表為OSEK警報提供了一個更簡單的替代方案。每個調度表都可以作為單個單元進行管理，您可以在運行時在表之間進行切換，從而方便地構建模態(tài)系統(tǒng)。

軟件計數(shù)接口（Software Counter Interface）-- 操作系統(tǒng)和計數(shù)器之間的交互已經標準化。它在OSEK中是特定于供應商的。

棧監(jiān)控（Stack Monitoring）-- 添加了額外的調試支持，以幫助處理堆棧錯誤。

可伸縮類2（Scalability Class 2）包括可伸縮類1加：

調度表同步（Schedule Table Synchronization）-- 調度表可以與全局時間源同步(盡管這在可伸縮性類1中是很可能的)。

定時保護（Timing Protection）-- 添加保護是為了防止任務和中斷執(zhí)行時間過長或過頻繁。保護方案允許您在運行時約束系統(tǒng)定時的那些方面，這些方面控制您的系統(tǒng)是否滿足其最后期限。

可伸縮類3（Scalability Class 3）包括可伸縮類1加：

內存保護（Memory Protection）-- 內存保護允許將系統(tǒng)劃分為OS-Applications。OS-Applications可以配置為可信的，即它們運行在通常稱為“管理模式”的模式下，或不可信的，即它們運行在通常稱為“用戶模式”的模式下。內存訪問限制可以為不可信的OS-Applications編程，操作系統(tǒng)在運行時管理目標MCU的內存管理功能以提供保護。還有一種受信任的保護模式，其中代碼是受信任的，但也可以有內存訪問限制。

服務保護（Service Protection）-- 可以允許或拒絕對OS API的訪問，以配置防護任務/ isr。

例如，你可以禁止一個操作系統(tǒng)應用程序中的任務激活另一個操作系統(tǒng)應用程序中的任務。API調用保護還提供了一種機制，通過添加可信函數(shù)和授予或拒絕對這些函數(shù)的訪問來擴展API，就像對操作系統(tǒng)API一樣。

可伸縮類4（Scalability Class 4）是可伸縮類2和可伸縮類3的超集。

RTA-OS 6.1.3支持所有AUTOSAR OS R3.x/4.x來自可伸縮性類1-4的特性。它還支持AUTOSAR多核操作系統(tǒng)規(guī)范中描述的多核應用程序，包括IOC (OsApplication Inter Communication)機制。IOC為AUTOSAR RTE提供服務，這里不再進一步討論。后續(xù)章節(jié)將深入介紹多核應用程序。

由于AUTOSAR OS是基于OSEK OS的，它向后兼容現(xiàn)有的基于OSEK OS的應用程序——即為OSEK OS編寫的應用程序將主要在AUTOSAR OS上運行而無需修改。

然而，AUTOSAR OS標準還澄清了OSEK OS規(guī)范中出現(xiàn)的一些不明確之處，這些不明確之處是在OSEK OS的行為未定義或特定于供應商時出現(xiàn)的，因為它們代表了可移植性的障礙。

從OSEK操作系統(tǒng)遷移并依賴于OSEK操作系統(tǒng)特性的特定實現(xiàn)的用戶應該意識到AUTOSAR OS在以下情況下定義了必需的OSEK操作系統(tǒng)行為:

參考指南提供了OSEK OS和AUTOSAR OS之間的API調用兼容性列表。

AUTOSAR OS將OSEK的OIL配置格式替換為基于xml的配置語言。AUTOSAR XML采用了與OIL中相同的配置對象和概念，但是使用了不同的語法。

1.1.3Unique RTA-OS Features

RTA-OS不僅僅是一個AUTOSAR OS。內核設計用于支持軟件工程師構建和集成實時系統(tǒng)。

可移植性說明：RTA-OS特定的特性不能保證可移植到OSEK OS或AUTOSAR OS的其他實現(xiàn)中。

添加的功能特點包括：

時間監(jiān)控（Timing monitor），以在運行時測量任務和第2類isr的執(zhí)行時間，并根據(jù)預先配置的預算可選擇地檢查時間。

增強的堆棧監(jiān)視（Enhanced Stack Monitoring）提供了額外的可能性來幫助您調試堆棧問題。

RTA-TRACE集成（RTA-TRACE Integration）提供操作系統(tǒng)內核的自動檢測，以支持ETAS RTA TRACE實時操作系統(tǒng)分析和可視化工具，以便您可以實時準確地查看操作系統(tǒng)正在做什么。

用戶控制硬件（User control of hardware），這樣就不需要把硬件的控制，如外圍定時器、緩存和I/O端口等移交給操作系統(tǒng)。所有硬件交互都通過RTA-OS定義良好的硬件接口進行。

可預測的運行時開銷（Predictable run-time overheads），如切換任務、處理中斷和喚醒任務，具有較低的最差情況邊界，并且在執(zhí)行時間內幾乎沒有可變性。

圖形脫機配置編輯器（Graphical offline configuration editor），支持操作系統(tǒng)的自動存儲XML配置。

作為RTA-OS代碼生成，您可以輕松地集成到構建過程中（Easy integration into your build process），這只需要一個可以從任何構建環(huán)境中驅動的命令行工具。

使用離線工具的高度可擴展的內核架構（Highly scalable kernel architecture），可以自動優(yōu)化應用程序的內核。

1.1.4Summary

-- RTA-OS是一種針對嵌入式系統(tǒng)的搶占式RTOS

-- 內核提供AUTOSAR OS R3.x/4中指定的特性標準用于所有可伸縮性類，包括對遺留OSEK操作系統(tǒng)的支持。

-- RTA-OS提供了額外的功能，可以更容易地將AUTOSAR OS集成到構建過程中。

審核編輯：劉清