简析符合AUTOSAR标准的RTA-OS功能

前言

本系列文章将以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集成到构建过程中。

审核编辑：刘清