系统学习AutoSAR ETAS RTA-OS嵌入式操作系统（一）

系统学习AutoSAR ETAS RTA-OS嵌入式操作系统（一）

1. RTA-OS简介

本用户指南告诉您如何使用RTA-OS构建基于AUTOSAR OS的应用程序，并按以下结构组织：

• 第2章介绍了RTA-OS，包括提供了哪些工具，内核支持哪些标准，并简要概述了内核功能。
• 第3章带您通过使用提供的工具配置和构建内核库以及将其与应用程序集成的开发阶段。
• 第4至12章详细解释了如何为每个主要类别的操作系统对象配置操作系统，并在运行时这些对象的内核API。
• 第13至17章解释了当出现问题时该怎么办。它们涵盖了在开发过程中如何检测对内核API错误使用、如何检查堆栈溢出和定时以及如何与外部调试和分析工成以获取有关操作系统运行时行为的额外见解。
• 第18至21章描述了如何构建分区系统其中多个应用程序与公共操作系统集成。它们描述了将操作系统对象映射到分区以及在运行时如何保护这些分区免受错误访问、定时和存储器故障影响等方面内容。第22章描述了如何构建多核AUTOSAR应用程序以及可能遇到的一些架构问题。
• 第23章讨论与整体性能相关的问题，以及您可以测量和调整操作系统以获得最佳结果的方法。
• 第24章描述了如何构建主参考配置和相关目标库，在传递给第三方开发人员之前进行完全测试. 开发人员将参考配置作为他应用程序 的一部分. 他可以对配置进行有限更改, 但无法更改其基本特征或修改参考库中的代码.

1.1 相关文件

在“入门指南”中可以找到有关如何安装RTA-OS的说明，并且在与本用户指南相同的目录中还可以找到完整的RTA-OS技术参考。针对您选择的编译器和目标硬件（我们称之为端口）实现RTA-OS的具体技术细节包含在“目标/编译器端口指南”中。每个已安装端口都有一个“目标/编译器端口指它可以在该端口的安装目录中找到。

1.2 关于你

你是一名经过训练的嵌入式系统开发人员，希望使用抢占式操作系统构建实时应用程序。你应该具备C编程语言的知识，包括使用所选择的工具链对嵌入式应用程序进行编译、汇编和链接。了解目标微控制器的基本知识也是必要的，例如起始地址、内存布局、外设位置等等。此外，你还应熟悉常见的Microsoft Windows操作系统的使用，包括安装软件、选择菜单项、点击按钮以及浏览文件和文件夹。

2. 简介

RTA-OS是一种静态可配置、抢占式的实时操作系统（RTOS），用于高性能、资源受限的应用。RTA-OS是开放标准AUTOSAR R3.x，AUTOSAR R4.0（包括多核）、AUTOSAR R4.1、AUTOSAR R4.2、AUTOSAR R4.3、AUTOSAR R4.4和 AUTOSAR R4.5(R19-11) OS规范的完整实现，并且完全符合OSEK/VDX OS标准版本2.2.3。OSEK现在已经被ISO 17356标准化。

RTA-OS内核的设计目标是：

high performance 高性能

内核非常小且非常快。内核的内存占用和运行时性能在同类产品中处于领先地位，使得RTA-OS特别适用于大规模生产的系统，在这些系统中需要满足硬件成本的严格限制，并确保任何最终产品都能正常运行。

RTA-OS提供了一系列独特的优化措施，有降低系统单位成本。内核使用单栈架构来处理所有类型的任务。与传统每个任务一个堆栈模型相比，可以显著节省RAM空间。此外，精心设计应用程序可以利用单栈架构来实现显著的堆栈RAM节省。

离线工具会分析您的操作系统配置，并利用这些信息构建尽可能小且最快速度的内核。不会使用到的代码将被排除在内核之外，以避免浪费执行时间和内存空间。

real-time 实时

传统的实时操作系统设计通有不可预测的开销，通常取决于每个时间点上任务数量和系统状态。这使得很难保证实时可预测性 - 无论内核有多“快”。在RTA-OS中，内核速度快，并且所有运行时开销 - 如切换到和从任务、处理中断和唤醒任务 - 具有较低的最坏情况界限，并且执行时间几乎没有变化。在许多情况下，上下文切换发生在恒定的执行时间内，这意味着RTA-OS可以用于开发需要在特定时间期限内做出响应的硬实时系统。满足硬期限涉及计算每个任务和中断服务例程（ISR）的最坏响应时间，并确保一切都按时运行。RTA-OS是一个真正的实时操作系统，因为它符合固定优先级调度分析的假设。

portable 便携式

RTA-OS可用于各种微控制器/编译器组合（或端口）。所有端口共享相同的RTA-OS代码，该代码占总内核功能的约97%。内核采用符合MISRA-C 2012标准的ANSI C语言编写。可以通过离线工具生成RTA-OS的MISRA报告。

尽可能地，RTA-OS不会对硬件进行限制 - 通常情况下，无需交出对硬件的控制权，如缓存、看门狗定时器和I/O端口。因此，您的代码可以自由使用硬件资源，使得传统软件能够整合到系统中。

RTA-OS产品架构如图2.1所示，包括以下部分：

• rtaoscfg是一个图形化配置工具，用于读取和写入AUTOSAR XML配置语言的配置。
• rtaosgen是一个命令行工具，用于根据输入的配置生成RTA-OS内核库。
• Port plug-ins 端口插件，每个目标/编译器组合都有一个对应的插件与之配套使用。您可以同时安装多个端口，并根据需要进行切换。您还可以同时安装多个版本的同一端口，以便轻松管理使用传统编译器和/或微控制器的项目。

VRTA是一个特殊的端口插件，可以在标准Windows PC上提供RTA-OS的功能。这使您能够设计和测试应用程序行为，而无需真实目标硬件1。VRTA附带有一个开发工具包，允许您构建可以模拟中断、I/O等的虚拟ECU。VRTA可用于仿真多核AUTOSAR应用程序。

2.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.519-11）开放标准，这些标准继承了早期OSEK OS标准的功能。该内核还提供了一些RTA-OS独有的附加功能。以下部分简要介绍了这些标准及其特点。

2.1.1 OSEK

OSEK是欧洲汽车工业的标准化努力，旨在为车辆电子设备提供开放系统接口。该项目的全名是OSEK/VDX。 OSEK是德语短语的首字母缩写，意思是用于汽车电子设备的开放系统和相应接口。 VDX基于法国标准（Vehicle Distributed eXecutive），现已与OSEK合并。本指南中将称其为OSEK。

OSEK的目标是支持软件组件在多个项目之间的可移植性和可重用性。这使得供应商可以专注于汽车知识产权，即供应商可以开发纯粹的软件解决方案，并在任何符合OSEK标准的ECU上运行软件。

然而，要实现这一目标，需要对每个非特定应用组件的接口进行详细规范。因此，OSEK标准包括一个应用程序编程接口（API），它抽象了底层硬件和车内网络配置等具体细节。

更多信息请参见https://www.iso.org/standard/40079.html.

OSEK OS

OSEK OS是OSEK标准中最成熟和被广泛使用的。 OSEK OS已经在各种类型的汽车电子控制单元（ECU）中得到采用，包括动力总成、底盘和车身以及多媒体设备。 OSEK OS的最新版本是2.2.3，这是2001年9月首次引入的2.2标准的第三个小修 这个版本的OSEK OS也是ISO17356部分。

OSEK OS完全使用一种名为OIL（OSEK实现语言）的离线配置语言进行静态定义。由于在系统生成时已知所有对象，因此实现可以非常小巧高效。

OSEK OS提供以下操作系统功能：

Tasks

任务是OSEK OS系统的主要构建模块。与其他一些操作系统不同，OSEK中的任务不需要自我调度（即在无限循环内放置任务体并非必需）。OSEK OS中有四种类型的任务：

1. 具有唯一优先级和非排队激活的基本任务。这是最简单的任务形式，非常适用于硬实时系统。一旦任务被激活，它必须在再次被激活之前运行并终止。这种类型的任务不能在执行过程中暂停自己等待事件发生。在RTA-OS中，这些被称为BCC1任务，因为它们对应于OSEK OS的BCC1符合类（有关OSEK符合类的更多详细信息，请参见第4.3节）。
2. 具有共享优先级和排队激活的基本任务。这些任务可以与系统中的其他任务共享优先级，并且在被再次激活之前不需要终止。操作系统会将待处理的任务激活排入队列，并在当前任务终止后运行下一个激活。与BCC1类型的任务一样，这种类型的任务无法在执行过程中暂停自身发生。在RTA-OS中，它们被称为BCC2类型的任务，因为它们对应于OSEK OS的BCC2符合类别。
3. 具唯一优先级的扩展任务。扩展任务在执行过程中允许等待事件（即任务可以自我挂起）。然而，激活不能排队，且任务必须具有唯一的优先级。在RTA-OS中，这些被称为ECC1任务，因为它们对应于OSEK OS的ECC1符合类别。
4. 具有共享优先级的扩展任务。这些任务类似于ECC1任务，但可以与系统中的其他任务共享优先级。在这方面，它们类似于BCC2任务。然而，与BCC2任务不同的是，扩展任务不能有排队激活。在RTA-OS中，这些任务被称为ECC2任务。

一个系统可以包含以上任务类型的任意组合。

Scheduling

任务可以被分为抢占式调度和非抢占式调度，而且可以很容易地构建合作调度器。

Interrupts

允许操作系统与异步外部触发器进行交互。在 OSEK 操作系统中有两种类型的中断：

在OSEK OS中有两种类型的中断：

1. 类别1中断不操作系统处理；
2. 类别2中断由操作系统处理，并且可以与之交互。

Resources
资源是一种简单的二进制信号，它允许您在任务和中断之间共享关键部分，并提供互斥。操作系统使用优先级协议来管理资源，以确保运行时没有死锁，并最大程度地减少优先级倒置。（注: 优先级反转是指低优先级任务在高优先级任务之前运行的情况。使用优先级上限协议，每次激活较高优先级任务时（总是在执行开始时），这种情况最多只会发生一次，并称为较高优先级任务的阻塞时间。阻塞时间由任何单个任务与较高优先级对象共享数据的最长时间限制 - 由于较低优先级任务的交互而导致的累积阻塞不存在。）

Counters and alarms
计数器和报警器用于周期性地提供任务（以及非周期性的任务）。计数器用于记录特定领域事件发生的次数，并将该值作为“刻度”进行注册。报警在运行时根据配置的计数值到期，无论是绝对计数值还是相对于设置报警器时计数器的“刻度”值。

Debugging Support
调试支持是通过使用构建级别在操作系统中本地提供的。操作系统提供两个构建级别：

1. 标准版是“精简高效”的，只提供最基本的错误处理功能。
2. 扩展版是“调试”版本，提供了广泛的错误检测工具，以确保您正确使用操作系统。

调试也可以通过OSEK ORTI（OSEK运行时接口）标准来实现。这为操作系统的实现提供了一种常见的方式，以便将符号详细信息导出给第三方调试器，从而使调试器能够在运行时显示操作系统的内部状态（例如正在运行的任务、准备运行的任务等）。

2.1.2 AUTOSAR

AUTOSAR（汽车开放系统架构）是一种开放和标准化的汽车软件架构，由全球汽车制造商、供应商和工具开发者共同开发。AUTOSAR提供了基本软件模块（BSW）的规范，如操作系统、通信驱动程序、存储器驱动程序和其他微控制器抽象。AUTOSAR标准还定义了一个基于组件的体系结构模型。该模型定义了虚拟功能总线（VFB），用于定义应用软件组件（SW-Cs）之间的通信抽象。VFB允许SW-Cs独立于底层硬件，使它们可以在不同ECU之间进行移植，并在多个汽车项目中重复使用。VFB抽象由AUTOSAR运行时环境（RTE）封装。RTE提供了连接SW-Cs和BSW之间的"胶水"作用。

AUTOSAR OS是OSEK OS规范的扩展。AUTOSAR OS包括了所有OSEK OS的功能，并添加了一些新的功能，这些功能被分为四个可扩展性类别:

Scalability Class 1 可扩展性类别1包括 OSEK 操作系统加上：

1. Schedule Tables 调度表 - 调度表在编程重复活动时提供了一种更简便的选择，每个调度表可以作为一个单独的单元进行管理，并且您可以在运行时在不同的表之间切换，从而轻松构建模态系统。

2. Software Counter Interface 软件计数器接口 - 操作系统与计数器之间的交互已经标准化。在 OSEK 中是特定于供应商的。

3. Stack Monitoring 堆栈监控 - 添加了额外的调试支持，以帮助处理堆栈故障。

Scalability Class 2 可扩展性类别2包括可扩展性类别1以及更多内容：

1. Schedule Table Synchronization 计划表同步 - 计划表可以与全局时间源进行同步（尽管在可扩展性类别1中这是微不足道的）。

2. Timing Protection 定时保护 - 添加了保护措施，以防止任务和中断执行时间过长或过频繁。该保护方案允许您在运行时限制系统定时的各个方面，以控制系统是否能够满足其截止日期。

Scalability Class 3 可扩展性类别3包括可扩展性类别1以及：

1. Memory Protection 内存保护 - 内存保护允许系统分为操作系统应用程序。操作系统应用程序可以配置为可信任的，即它们在通常被称为“监管模式”的模式下运行，或者是不受信任的，即它们在通常被称为“用户模式”的模式下运行。可以对不受信任的操作系统应用程序编程内存访问限制，并且操作系统会在运行时管理目标微控制器的内存管理功能以提供保护。还有一种带有保护模式的可信代码，在这种情况下，代码是可信赖的，但也可能具有内存访问限制。

2. Service Protection 服务保护 - 可以允许或拒绝对操作系统API进行配置任务/中断服务例程（ISR）的访问。例如，您可以禁止一个OS-Application中的任务激活另一个OS-Application中的任务。API调用保护还提供了通过添加可信函数并根据需要授予或拒绝对这些函数进行访问来扩展API功能的机制，就像对待操作系统API一样。

Scalability Class 4 可扩展性类别4是可扩展性类别2和3的超集。

RTA-OS .1.0支持Scalability Classes 1-4中的所有AUTOSAR OS R3.x/4.x功能。它还支持AUTOSAR多核操作系统规范中描述的多核应用程序，包括IOC（Inter OsApplication Communication）机制。IOC为AUTOSAR RTE提供服务，在此不再详细讨论。多核应用程序在第22章中有详细描述。由于AUTOSAR OS基于OSEK OS，因此与现有基于OSEK OS的应用程序向后兼容 - 即针对OSEK OS编写的应用程序在大部分情况下可以在AUTOSAR OS上运行而无需修改。

然而，AUTOSAR OS标准还澄清了一些关于OSEK OS规范中未定义或特定厂商行为引起的歧义问题，因为这些问题会影响可移植性。从使用某个特定实现的OSEK OS迁移到AUTOSAR OS并依该实现某个特定功能的用户应注意以下情况：

参考指南提供了OSEK OS和AUTOSAR OS之间的API调用兼容性列表。AUTOSAR OS使用基于XML的配置语言替代了OSEK的OIL配置格式。AUTOSAR XML采用与OIL相同的配置对象和概念，但使用不同的语法。

2.1.3 Unique RTA-OS Features

RTA-OS不仅仅是一个系统。该内核旨在支持软件工程师构建和集成实时系统。

**可移植性注释2.1：**RTA-OS特定功能不能保证在其他OSEK OS或AUTOSAR OS的实现中具有可移植性。附加功能包括：

1. Time Monitoring 时间监控用于在运行时测量任务和第二类中断服务程序的执行时间，并可选择性地将时间与预配置的预算进行比较。

2. Enhanced Stack Monitoring 增强型堆栈监控提供了额外的可能性，帮助您调试堆栈问题。

3. RTA-TRACE Integration RTA-TRACE集成可以自动对操作系统内核进行仪器化，以支持ETAS RTA-TRACE实时操作系统分析和可视化工具，这样您就可以实时查看操作系统正在做什。

4. User control of hardware 用户对硬件的控制，使得不需要将硬件的控制权交给操作系统，例如外围定时器、缓存和I/O端口等。所有与硬件的交互都通过RTA-OS的明确定义的硬件接口进行。

5. Predictable run-time overheads 可预测的运行时开销，如任务切换、中断处理和唤醒任务，在最坏情况下具有较低的上限，并且在执行时间内变化很小。

6. Graphical offline configuration editor 支持AUTOSAR XML配置操作系统的图形离线配置编辑器。

7. Easy integration into your build process 易于集成到构建过程中，因为RTA-OS代码生成只需要一个命令行工具，可以从任何构建环境驱动。

8. Highly scalable kernel architecture 使用离线工具实现高度可扩展的内核架构，自动优化适用于您应用程序的内核。

2.2 总结

• RTA-OS是一种用于嵌入式系统的抢占式实时操作系统。
• 内核提供了AUTOSAR OS R3.x/4.x标准中指定的所有可扩展性类别的功能，包括对传统 OSEK OS 的支持。
• RTA-OS还提供了其他功能，使得将 AUTOSAR OS 集成到您的构建过程中更加容易。