当前位置：首页 > news >正文

AUTOSAR 运行时环境 (RTE)

news 来源：原创 2025/5/22 7:28:28

往期推荐

什么是运行时环境？

AUTOSAR 中的运行时环境 (RTE)

RTE 的应用

RTE 的生成

关于RTE API的一些信息

RTE生成后文件之间的关系

往期推荐

2025汽车行业新宠：欧企都在用的工具软件
ETAS工具链自动化实战指南＜一＞
ETAS工具链自动化实战指南＜二＞
ETAS工具链自动化实战指南＜三＞
AUTOSAR工程师必读：Artop的核心功能
Vector工具链自动化实战指南＜一＞
isolar高手秘籍| ECU Configuration三分钟速成！
掌握核心步骤：RTA-BSW以太网配置全解析
一文详解TC399 CAN MCAL 配置
LSL常见应用场景及示例＜一＞
LSL常见应用场景及示例＜二＞
LSL常见应用场景及示例＜三＞
为什么Autosar钟情arxml而非json？大揭秘！
深入浅出：SOME/IP-SD的工作原理与应用
【技术进阶】|一文掌握Autosar ComStack的精髓！
Autosar培训笔记整理＜一＞
【AutoSAR进阶】|实战详解ETAS工具链UDS 0x2f服务核心配置！
实战详解ETAS工具链CanTp模块自动化配置
一文掌握5种常见的AUTOSAR 错误类型
【AUTOSAR工程师必备知识】一文搞懂AUTOSAR架构9种通信方式
实战干货|详解ETAS工具链之 intra-ECU通信的数据转换

什么是运行时环境？

运行时环境 (RTE)也称为运行时系统，是一种执行环境，可帮助特定语言或软件运行并访问硬件。例如，JAVA 语言使用 JVM（JAVA 虚拟机）或Python使用 Python 解释器。RTE 通过抽象不同的低级分配（如函数、变量到内存映射等）来帮助程序在硬件上正确运行。RTE 还具有软件库、运行进程所使用的环境变量。RTE 主要用于高级语言。运行时环境的作用就是为程序提供一个适合执行的环境，确保它能够顺利运行，处理内存管理、任务调度、输入输出等各种操作。

在嵌入式系统开发中，通常使用 C 语言编写应用程序，这些程序直接与硬件交互，因此没有像高级语言（例如 Java、Python）那样的运行时环境（RTE）概念。嵌入式系统程序员编写的是针对特定硬件平台的低级代码，通常不依赖复杂的运行时环境或虚拟机。

但是，在 AUTOSAR 中，RTE 具有不同的含义和作用，确实和一般编程语言中的运行时环境不完全相同。在 AUTOSAR 中，RTE 是一种用于管理和连接软件组件（Software Components，SWC）之间的通信和交互的中间件层。

AUTOSAR 中的运行时环境 (RTE)

运行时环境是 AUTOSAR ECU 架构的核心。RTE 以及 AUTOSAR COM、OS 和其他 BSW 模块是ECU 的VFB 概念的实现。所有端口和接口均在 RTE 中实现，从而实现SWC之间的通信，并充当 SWC 访问BSW模块（如 OS 和通信服务）的一种方式。如上所述，RTE 具有接口， SWC 中的Runnable可通过这些接口与其他 SWC 或 BSW 模块通信。RTE 将 Runnable 映射到 RTE 配置期间配置的 OS 任务，并在同一任务或不同任务中执行 Runnable，RTE 还处理使用 SWC 配置中配置的 RTE 事件触发 Runnable（如果满足条件）的工作。RTE 与 BSW 调度程序紧密相关，因为相同的 OS 任务可用于 BSW 模块的 SWC 和可调度实体（也称为主处理功能）的调度。从逻辑上讲，RTE 分为两部分：

- SWC 之间的通信
- SWC 的调度

为每个 ECU 生成 RTE 和 BSW 调度程序，以确保在 ECU 级别实现最佳操作和定制。

AUTOSAR 的开发愿景是创建一个架构，使应用程序独立于硬件，可重定位和重用。如果没有 RTE，就无法实现这一目标，因为 RTE 充当粘合层，将应用层的 SWC 与 BSW 层连接起来，要实现这一点，需要为每个 ECU单独生成 RTE。

RTE 不可重用，因为它是根据应用程序要求生成的，如果应用程序发生变化，RTE 也需要更改。除了高度依赖于 ECU 硬件的传感器/执行器类型的 SWC 外，所有 SWC 都是可移植和可重用的。RTE 是在 SWC 集成之后生成的，因此 RTE 负责确保系统按预期运行，确保 SWC（它们之间以及与 BSW 模块之间的通信）顺畅，无论 SWC 部署在何处。

RTE 既支持带有源代码的 SWC，也支持仅带有目标代码的 SWC。RTE 不支持任何运行时重新配置，即在生成 RTE 之前必须配置 SWC 和 BSW 模块之间的每个通信。

RTE 的应用

RTE 是 AUTOSAR 最重要的元素之一，因为它执行对应用程序有用的关键操作。

RTE 的应用：

RTE 实现虚拟功能总线，有助于连接 ECU 内的 SWC 和 ECU 外的 SWC（通过 ECU 之间的物理网络连接）
RTE 使用端口和接口实现通信路径，用于根据配置连接 SWC 和下层的 BSW 模块。
根据配置基于不同的 RTE 事件调用并支持 SWC 的多个Runnable 。
在配置期间包含任何项目中的任何 SWC，并按预期执行操作，以实现 AUTOSAR 的 SWC 重用能力和可移植性特性。
启用 SWC 实例化并支持 SWC 的单个和多个实例
由于 RTE 处理 OS 任务中可运行对象的执行，因此它实现了激活偏移，用于在时间触发的可运行对象映射到同一 OS 任务的情况下优化 CPU 负载、内存等。由于时间触发变量需要在配置的时间执行，并避免可运行对象因重叠而发生冲突，因此 RTE 使用激活偏移。RTE 通过计算任务的最大周期（即所有可运行对象的最大公约数 (GCD)）来处理此问题，并且它假设任何可运行对象的最大执行周期都低于 GCD。
RTE 还会将任何中断（如果已配置）通知给可运行体，但这并不意味着可运行体将在 ISR 中执行！可运行体是 SWC 的子集，SWC 完全独立于下层。
RTE 在同一 SWC 的 Runnable 之间、分区间 SWC 之间、分区内 SWC 之间，甚至不同 ECU 的 SWC 之间通信时，必须确保数据一致性。
SWC 之间的通信（在发送方-接收方通信中）不仅限于对等通信，还以1:N（一个 SWC 与多个 SWC 通信）或N:1（多个 SWC 与一个 SWC 通信）组合进行。如果发送方同时向一个接收方传输数据或反之亦然，RTE 会注意防止发生任何冲突。
如果发送方请求TransmissionAcknowledgementRequest ，RTE 会通知发送方信号传输成功。此通知并不保证接收方已成功收到信号。

RTE 的生成

在任何基于 AUTOSAR 的项目中，生成 RTE 是最重要的一步。生成 RTE 的结果是有各种文件，但我们只考虑两个重要的文件：1. Rte.c文件，2. Rte.h文件。这是最常见的 RTE 生成结果，但一些集成商也倾向于为每个 SWC 生成单独的 RTE 文件（.c 和 .h），这些文件进一步包含在主 RTE 文件中，以便于管理项目的 RTE 文件，此类生成选项可能因 AUTOSAR GUI 工具而异。RTE 生成器可以是单独的工具，也可以是集成工具，这完全取决于您使用的工具供应商。例如，在 Vector DaVinci 的情况下，DaVinci 开发人员用于 SWC、Runnables、IDT创建等，而DaVinci 配置器用于配置BSW和生成 RTE。在任何基于 AUTOSAR 的系统中，RTE 都是为每个 ECU 单独生成的，因为每个 ECU 的 SWC 可能有自己独特的要求，因此 RTE 是定制的以满足这些要求。

上图给出了与 SWC 和 RTE 生成器软件相关的 RTE 生成步骤。下面详细了解每个步骤：

收集可用的 SWC 实现：此步骤包括收集 SWC 描述文件（如果打算重用旧 SWC）及其各自的组合 SWC并进一步使用它们。或者我们也可以创建新的 SWC 实现并将其用于后续步骤。
配置系统：此步骤结合了旧步骤中的 SWC，并配置了系统（整车 ECU 网络），该系统具有不同 ECU 的不同组合 SWC 和其他系统约束。在此步骤中，所有 SWC 都映射到各自的 ECU。
系统配置描述：这是 arxml 文件，其中包含系统配置后生成的整个系统（车辆）的 ECU 详细信息。、
提取 ECU 特定信息：此步骤提取单个 ECU 的 SWC 描述和其他详细信息，不同于包含车辆中所有 ECU 信息的系统配置描述文件。此步骤的输出称为 ECU Extract arxml，这是下一步。
生成 ECU 配置：此步骤涉及BSW模块（如Com Services等）的 AUTOSAR 下层（RTE 之下）的配置。此步骤的输出再次是一个 arxml 文件，其中包含 ECU 的全部信息，如 BSW 配置、SWC 配置等，这恰好是 RTE 生成过程的下一步。
生成 RTE：这是 RTE 生成中的重要步骤。在此步骤中，所有可运行对象都映射到 OS 任务，所有委托连接器都映射到实际信号等。此步骤的输出是 Rte.c和Rte.h文件，它们可以粗略地称为 AUTOSAR 的 RTE 层。我之所以粗略地称呼它们，是因为还有一些其他文件与 RTE 层相关联。此步骤还生成 BSWMD（基本软件模块描述）文件，其中包含 RTE 不同功能的信息。
编译 RTE：顾名思义，在此步骤中将编译 RTE 文件（考虑到已编写可运行代码）并生成目标文件，然后将其与其他已编译的 BSW 和 SWC 文件链接以生成可刷入 MCU 的可执行文件。

对系统的每个 ECU重复上述步骤。除了 RTE 文件外，还会为每个 SWC 生成SWC 文件 (<swc_name>.h 和<swc_name>.c )，一些软件还会在 SWC .c文件中生成可运行程序的骨架，在 SWC .h文件中生成函数原型。SWC 文件将包含必要的头文件#include d（但这取决于您使用的配置器软件）。所有 RTE 文件均遵循MISRA -C标准生成，尽管允许某些 MISRA 违规行为， 但此类情况已在注释中记录。RTE 源文件具有应用程序和其他层所需的 RTE 调用，RTE 头文件具有这些调用的原型。

由于 AUTOSAR 的主要目标是 SWC 的可重用性 ，因此 RTE 支持不同 AUTOSAR 版本的 SWC 兼容性，前提是 SWC 在其源文件中可用，而不是在目标代码中可用。SWC 的兼容性和可重用性不仅限于 AUTOSAR 版本，还与工具供应商无关，即只要提供源代码，就可以使用来自不同工具供应商的 SWC。

关于RTE API的一些信息

RTE 提供各种 API，SWC 可以使用这些 API 访问来自其他 SWC 或较低层的数据。通过查看任何函数调用的Rte_前缀，可以轻松区分源代码中的 RTE API。RTE API 分为两种类型：

直接 API：它是一种 RTE API，用于需要高效（零运行时开销）调用的情况。这些 API 是为每个端口生成的，应用程序可以通过在 Runnable 中调用 API 名称直接使用它。在映射 API 时，可以针对 SWC 优化此类 API。通常，直接 API 以宏的形式实现，因此无法获取 RTE API 的地址以与 C 中的函数指针一起使用，但是，如果我们愿意，可以通过一些困难的方法在应用程序中使用函数指针。
间接 API：这是一种 RTE API，其中 API 是使用端口句柄间接调用的。当单个端口接口有多个端口时，这种类型的 API 很有用，因此我们可以拥有该接口的端口句柄数组，并且只需在调用时传递相应的端口句柄，即可使用相同的 RTE API 访问多个端口。

直接和间接 API 调用都会产生相同的结果，只是调用方式不同。在 SWC 中，可以同时实现间接或直接 API。

RTE生成后文件之间的关系

RTE 生成后，RTE 生成器工具会生成许多文件，其中头文件与其他文件有关系，即这些文件被 #include到不同的文件中。让我们看看这些文件及其与其他文件的关系。生成的文件：

Rte.h：此文件定义了不需要为每个 ECU 生成的固定元素，因为此 RTE 生成器软件不会一次又一次地生成此文件。但是，如果需要，我们可以定制此文件以满足我们的应用程序。此文件包括 Std_Types.h文件。
Std_Types.h：此文件是标准 AUTOSAR 文件，它定义基本数据类型（如无符号和有符号整数的平台特定实现），并提供访问编译器抽象的方法。
Rte_Main.h：这是生命周期头文件，其中包含RTE 生命周期 API 的函数原型，如 Rte_Start和Rte_Stop。一些软件还添加了更多生命周期 API，用于初始化 RTE 内存等。此文件包含Rte.h文件。
Rte_<swc_name> .h：这是特定于应用程序的 RTE 头文件，顾名思义，文件名的前缀始终是Rte_，后缀是此 RTE 应用程序文件所关联的 SWC 名称。此文件包含与 SWC 关联的 SWC 中使用的 RTE API 的函数原型、数据结构和 Runnable 的函数原型。此文件包括Rte_Type.h 和 Rte_DataHandle.h 文件。
Rte_Type.h：此文件包含从在 SWC 配置期间配置的实现数据类型派生的 RTE 特定类型声明。此文件还包含对 RTE API 有用的 AUTOSAR 数据类型。此文件包括 Rte.h文件。
Rte_DataHandle.h：此文件包含 SWC 数据结构所需的数据句柄类型声明。此文件不包含任何将使用内存的符号。
Rte_<swc_name>_Type.h：这也称为应用程序类型头文件，它包含与应用程序相关的常量，如 SWC 中使用的范围值或枚举值。文件名也将在空格中包含 SWC 名称。此文件包含 Rte_Type.h文件。