前言
本系列文章將以RTA-OS為例詳細介紹AUTOSAR OS標準及概念,并分享實際使用的一些案例,本文為符合AUTOSAR標準的RTA-OS功能簡介。
正文
1.Introduction
RTA-OS是一種靜態可配置的搶占式實時操作系統(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)操作系統規范的完整實現,也完全符合OSEK/VDX操作系統標準版本2.2.3。OSEK現已在ISO 17356中標準化。
RTA-OS內核被設計成:
high performance(高性能): 內核非常小,速度非常快。內核的內存占用及其運行時性能是同類OS中領先的,使得RTA-OS特別適用于大量制造的系統,在這些系統中,必須滿足對硬件成本的非常嚴格的限制,并且任何最終產品都必須正確運行。
RTA-OS提供了許多獨特的優化,有助于降低系統的單位成本。內核對所有類型的任務都使用了單堆棧體系結構。與傳統的每個任務的堆棧模型相比,這節省了大量的RAM。此外,仔細的應用程序設計可以利用單堆棧體系結構來提供顯著的堆棧RAM節省。
離線工具分析您的操作系統配置,并使用這些信息構建盡可能小且最快的內核。您不打算使用的代碼被排除在內核之外,以避免浪費執行時間和內存空間。
real-time(實時): 傳統的RTOS設計通常具有不可預測的開銷,通常取決于任務的數量和系統在每個時間點的狀態。這使得保證實時可預測性變得困難——無論內核有多“快”。在RTA-OS中,內核是快速的,而且所有的運行時開銷——比如切換任務、處理中斷和喚醒任務——都有較低的最壞情況邊界,執行時間很少或沒有變化。在許多情況下,上下文切換發生在恒定的執行時間內,這意味著RTA-OS可以用于開發硬實時系統,其中必須在特定的時間期限內做出響應。滿足嚴格的截止日期包括計算每個任務和中斷服務例程(ISR)的最壞情況響應時間,并確保每次都按時運行。RTA-OS是一個真正的RTOS,因為它滿足了固定優先級可調度性分析的假設。
portable(可移植性): RTA-OS可用于各種各樣的微控制器/編譯器組合(or port)。所有端口共享相同的公共RTA-OS代碼,這約占總內核功能的97%。該內核是用與MISRA-C 2012兼容的ANSI C編寫的。通過離線工具,可以生成RTA-OS的MISRA報告。
RTA-OS盡可能地不會對硬件施加控制。一般來說,不需要移交對硬件的控制,比如緩存、監視器計時器和I/O端口。因此,您的代碼可以自由地使用硬件,從而允許將遺留軟件集成到系統中。
圖1.1:RTA-OS Product Architecture
RTA-OS產品體系結構如圖1.1所示,它包括:
lrtaoscfg是一個圖形配置工具,它用自動sarXML配置語言讀取和寫配置。
lrtaosgen是一個命令行工具,用于從輸入配置生成RTA-OS內核庫。
l端口插件,一個用于您使用RTA-OS的每個目標/編譯器組合。您可以同時安裝多個端口,并根據需要在它們之間進行切換。您還可以同時安裝同一端口的多個版本,從而允許您輕松地管理使用遺留編譯器和/或微控制器的項目。
VRTA是一個特殊的端口插件,在標準Windows PC上提供RTA-OS功能。這允許您在不需要實際目標硬件的情況下設計和測試應用程序行為。VRTA提供了一個開發工具包,允許您構建虛擬ecu,可以模擬中斷,I/O等。
VRTA可用于模擬多核AUTOSAR應用程序。
1.1 Features of the RTA-OS Kernel
RTA-OS基于早期ETAS操作系統的成熟技術,迄今為止,該操作系統已在全球超過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)開放標準的實現。這些標準從早期的OSEK OS標準中提取了功能。內核還提供了許多RTA-OS獨有的附加特性。下面幾節簡要介紹了這些標準及其特性。
1.1.1OSEK
OSEK是歐洲汽車行業標準,致力于為汽車電子產品生產開放系統接口。該項目的全名為OSEK/VDX。OSEK是由德語中的一個短語組成的首字母縮寫,翻譯為汽車電子產品的開放系統和相應的接口。VDX基于法國標準(車輛分布式執行),現在已與OSEK合并。OSEK/VDX在本指南中被稱為OSEK。
OSEK的目標是支持跨多個項目的軟件組件的可移植性和可重用性。這使得供應商可以專注于汽車知識產權,因此供應商可以開發純軟件解決方案,并在任何符合osek的ECU中運行軟件。
然而,為了達到這個目標,需要對每個非應用程序特定組件的接口進行詳細的規范。因此,OSEK標準包括一個應用程序編程接口(API),它從底層硬件和車載網絡配置的具體細節中抽象出來。
OSEK OS
OSEK操作系統是OSEK標準中最成熟和應用最廣泛的一種。OSEK操作系統已被應用于所有類型的汽車ecu中,從動力系統、底盤和車身到多媒體設備。
OSEK操作系統的最新版本是2.2.3,這是2001年9月最初引入的2.2標準的第三個小版本。這個版本的OSEK OS也是ISO17356標準的一部分。
OSEK OS完全使用一種稱為OIL(OSEK實現語言)的離線配置語言進行靜態定義。由于所有對象在系統生成時都是已知的,因此實現可以非常小和高效。
OSEK操作系統提供了以下操作系統功能:
任務(Task)是OSEK操作系統系統的主要組成部分。與其他操作系統不同的是,OSEK中的任務不需要自我調度(也就是說,不需要將任務的主體放在一個無限循環3中)。在OSEK操作系統中有四種類型的任務:
l具有唯一優先級和非排隊激活的基本任務(Basic taskswith unique priority and non-queued activation)。這些都是最簡單的任務形式,非常適合用于硬實時系統。一旦任務被激活,它必須運行并終止,然后才能再次被激活。這種類型的任務不能在執行中途掛起自己以等待事件。在RTA-OS中,這些任務被稱為BCC1任務,因為它們對應于OSEK OS的BCC1一致性類(conformance class)(有關OSEK的一致性類的更多細節,請參閱第4.3節)。
l具有共享優先級和排隊激活的基本任務(Basic taskswith shared priority and queued activation)。這些任務可以與系統中的其他任務共享優先級,并且在再次被激活之前不需要終止。操作系統排隊等待任務激活的隊列,并在當前激活終止時運行下一次激活。與BCC1任務一樣,這種類型的任務不能在執行過程中掛起自己以等待事件。在RTA-OS中,這些任務被稱為BCC2任務,因為它們對應于OSEK OS的BCC2一致性類。
l具有唯一優先級的擴展任務(Extended taskswith unique priorit)。允許擴展任務在執行過程中等待事件(即,該任務可以自掛起)。但是,激活不能被排隊,并且任務必須具有唯一的優先級。在RTA-OS中,這些任務被稱為ECC1任務,因為它們對應于OSEK OS的ECC1一致性類。
l具有共享優先級的擴展任務(Extended tasks with shared priority.)。這些任務類似于ECC1任務,但可以與系統中的其他任務共享優先級。在這方面,它們類似于BCC2的任務。然而,與BCC2任務不同的是,擴展任務不能有排隊激活。在RTA-OS中,這些任務被稱為ECC2任務。
系統可以包含上述任務類型的任何組合。
調度(Scheduling)任務可以預先調度或非預先調度,并且可以很容易地構建協作調度器。
中斷(Interrupts)允許操作系統與異步外部觸發器的交互。
在OSEK OS中有兩種類型的中斷:
1.第一類中斷(Category 1 interrupts)不由操作系統處理;
2.第二類中斷(Category 2 interrupts)是由操作系統處理,并可以與之交互。
資源(Resources)是簡單的二進制信號量,允許在任務和中斷之間共享的臨界區上提供互斥。資源由操作系統使用優先級天花板協議進行管理,該協議保證不出現死鎖,并最大限度地減少運行時的優先級反轉。
Note: 優先級反轉是指低優先級任務優先于高優先級任務運行的情況。使用優先級上限協議,這種情況最多在高優先級任務被激活時發生一次(并且總是在執行開始),并被稱為高優先級任務的阻塞時間。阻塞時間受限于任何單個任務與高優先級對象共享數據的最長時間——由于低優先級任務的交互而不存在累積阻塞。
計數器和告警(Counters and alarms)用于提供周期性(和非周期性)的任務調度。計數器,顧名思義,計數(domain specific)事件的發生,并將值寄存器為“ticks”。可以將告警設置為運行時可配置的計數值,可以是絕對計數值,也可以是設置告警時相對于計數器的“tick”值。
調試支持(Debugging Support)通過使用構建級別在操作系統中提供。操作系統提供了兩種構建級別:
1.標準(Standard)是“精簡和平均”,并提供最小的錯誤處理。
2.擴展(Extended)是“調試”版本,它提供了廣泛的錯誤檢測功能,以檢查是否正確使用操作系統。
調試也通過OSEK ORTI (OSEK運行時接口)標準提供。這為操作系統實現提供了一種通用的方法,可以將符號詳細信息導出到第三方調試器,以便調試器可以在運行時顯示關于操作系統內部狀態的信息(例如,哪個任務正在運行,哪些任務準備運行等)。
1.1.2AUTOSAR
AUTOSAR(汽車開放系統架構)是一個開放和標準化的汽車軟件架構,由全球汽車制造商、供應商和工具開發人員共同開發。
AUTOSAR為基本軟件模塊(BSW)提供規范,如操作系統、通信驅動程序、內存驅動程序和其他微控制器抽象套件。AUTOSAR標準還定義了一個基于組件的體系結構模型。該模型定義了虛擬功能總線(VFB),它定義了應用軟件組件+(SW-Cs)之間通信的抽象。VFB允許sw - c獨立于底層硬件,使其在不同的ecu之間可移植,并在多個汽車項目中可重用。VFB抽象由AUTOSAR運行時環境(RTE)進行封裝。RTE提供sw - c和BSW之間的“膠水(glue)”。
AUTOSAR操作系統是OSEK操作系統規范的擴展。AUTOSAR操作系統包括OSEK操作系統的所有特性,并添加了一些新功能,這些功能分為以下四個可伸縮性類:
可伸縮性類1(Scalability Class 1)包括OSEK OS加:
調度表(Schedule Tables)--在編程重復活動時,調度表為OSEK警報提供了一個更簡單的替代方案。每個調度表都可以作為單個單元進行管理,您可以在運行時在表之間進行切換,從而方便地構建模態系統。
軟件計數接口(Software Counter Interface)-- 操作系統和計數器之間的交互已經標準化。它在OSEK中是特定于供應商的。
棧監控(Stack Monitoring)-- 添加了額外的調試支持,以幫助處理堆棧錯誤。
可伸縮類2(Scalability Class 2)包括可伸縮類1加:
調度表同步(Schedule Table Synchronization)-- 調度表可以與全局時間源同步(盡管這在可伸縮性類1中是很可能的)。
定時保護(Timing Protection)-- 添加保護是為了防止任務和中斷執行時間過長或過頻繁。保護方案允許您在運行時約束系統定時的那些方面,這些方面控制您的系統是否滿足其最后期限。
可伸縮類3(Scalability Class 3)包括可伸縮類1加:
內存保護(Memory Protection)-- 內存保護允許將系統劃分為OS-Applications。OS-Applications可以配置為可信的,即它們運行在通常稱為“管理模式”的模式下,或不可信的,即它們運行在通常稱為“用戶模式”的模式下。內存訪問限制可以為不可信的OS-Applications編程,操作系統在運行時管理目標MCU的內存管理功能以提供保護。還有一種受信任的保護模式,其中代碼是受信任的,但也可以有內存訪問限制。
服務保護(Service Protection)-- 可以允許或拒絕對OS API的訪問,以配置防護任務/ isr。
例如,你可以禁止一個操作系統應用程序中的任務激活另一個操作系統應用程序中的任務。API調用保護還提供了一種機制,通過添加可信函數和授予或拒絕對這些函數的訪問來擴展API,就像對操作系統API一樣。
可伸縮類4(Scalability Class 4)是可伸縮類2和可伸縮類3的超集。
RTA-OS 6.1.3支持所有AUTOSAR OS R3.x/4.x來自可伸縮性類1-4的特性。它還支持AUTOSAR多核操作系統規范中描述的多核應用程序,包括IOC (OsApplication Inter Communication)機制。IOC為AUTOSAR RTE提供服務,這里不再進一步討論。后續章節將深入介紹多核應用程序。
由于AUTOSAR OS是基于OSEK OS的,它向后兼容現有的基于OSEK OS的應用程序——即為OSEK OS編寫的應用程序將主要在AUTOSAR OS上運行而無需修改。
然而,AUTOSAR OS標準還澄清了OSEK OS規范中出現的一些不明確之處,這些不明確之處是在OSEK OS的行為未定義或特定于供應商時出現的,因為它們代表了可移植性的障礙。
從OSEK操作系統遷移并依賴于OSEK操作系統特性的特定實現的用戶應該意識到AUTOSAR OS在以下情況下定義了必需的OSEK操作系統行為:
參考指南提供了OSEK OS和AUTOSAR OS之間的API調用兼容性列表。
AUTOSAR OS將OSEK的OIL配置格式替換為基于xml的配置語言。AUTOSAR XML采用了與OIL中相同的配置對象和概念,但是使用了不同的語法。
1.1.3Unique RTA-OS Features
RTA-OS不僅僅是一個AUTOSAR OS。內核設計用于支持軟件工程師構建和集成實時系統。
可移植性說明:RTA-OS特定的特性不能保證可移植到OSEK OS或AUTOSAR OS的其他實現中。
添加的功能特點包括:
時間監控(Timing monitor),以在運行時測量任務和第2類isr的執行時間,并根據預先配置的預算可選擇地檢查時間。
增強的堆棧監視(Enhanced Stack Monitoring)提供了額外的可能性來幫助您調試堆棧問題。
RTA-TRACE集成(RTA-TRACE Integration)提供操作系統內核的自動檢測,以支持ETAS RTA TRACE實時操作系統分析和可視化工具,以便您可以實時準確地查看操作系統正在做什么。
用戶控制硬件(User control of hardware),這樣就不需要把硬件的控制,如外圍定時器、緩存和I/O端口等移交給操作系統。所有硬件交互都通過RTA-OS定義良好的硬件接口進行。
可預測的運行時開銷(Predictable run-time overheads),如切換任務、處理中斷和喚醒任務,具有較低的最差情況邊界,并且在執行時間內幾乎沒有可變性。
圖形脫機配置編輯器(Graphical offline configuration editor),支持操作系統的自動存儲XML配置。
作為RTA-OS代碼生成,您可以輕松地集成到構建過程中(Easy integration into your build process),這只需要一個可以從任何構建環境中驅動的命令行工具。
使用離線工具的高度可擴展的內核架構(Highly scalable kernel architecture),可以自動優化應用程序的內核。
1.1.4Summary
-- RTA-OS是一種針對嵌入式系統的搶占式RTOS
-- 內核提供AUTOSAR OS R3.x/4中指定的特性標準用于所有可伸縮性類,包括對遺留OSEK操作系統的支持。
-- RTA-OS提供了額外的功能,可以更容易地將AUTOSAR OS集成到構建過程中。
審核編輯:劉清
-
RAM
+關注
關注
8文章
1367瀏覽量
114533 -
AUTOSAR
+關注
關注
10文章
350瀏覽量
21479 -
RTOS
+關注
關注
22文章
809瀏覽量
119440 -
VDX
+關注
關注
0文章
9瀏覽量
9749
原文標題:符合AUTOSAR標準的RTA-OS --功能簡介
文章出處:【微信號:汽車電子嵌入式,微信公眾號:汽車電子嵌入式】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論