Autosar - 【2 RTE模块】

2.1 RTE概述

AUTOSAR RTE(Run Time Environment)实现了AUTOSAR系统中的虚拟功能总线（VFB），提供了SWC(Software Component)之间的访问接口和SWC对于BSW资源的访问接口。RTE为SWC中的Runnable提供与其他SWC或者BSW模块通信的接口，RTE将Runnable映射到OS Task中，并且管理Runnable的触发机制，因此RTE功能主要可以分为两个部分：

1. SWC间的通信
2. SWC的调度

简化的AUTOSAR架构图如下：

如上图，AUTOSAR架构是分层设计的，并且其理念是将软件与硬件解耦，使得软件可以重分配和复用，这些都要依赖RTE来实现。但是RTE是不可复用的，因为RTE是匹配应用需求的，所以如果应用修改了RTE也就需要修改。除了高度依赖ECU硬件的传感器/执行器类型SWC，其他所有SWC都是方便移植和复用的。RTE是在SWC集成之后生成的，因此RTE服务确保SWC之间，SWC与BSW之间的通信，从而确保系统按照预期工作，而不管SWC部署在哪里。RTE既支持源码类型SWC也支持目标代码SWC。RTE不支持运行时的重新配置，所有通信在配置生成后都是静态的。

为了充分描述RTE的概念，还必须考虑基础软件调度程序。基础软件调度程序调度基础软件模块的可调度实体。在一些文档中，可调度实体也被称作主要处理函数。

由于同一OS任务可能用于调度软件组件和基础软件模块，因此RTE的调度部分与基础软件调度程序有着紧密的联系，不能清晰的分开。

为每个ECU生成RTE和基础软件调度程序，以确保RTE和基础软件调度程序对于ECU是最佳的。

实时运行环境（RTE）的作用有点像一个快递中转站或者说是电话接线员（就是上个世纪那种要先打电话到接线员那里，然后通过接线员转接电话线到目的地），其作用就是将一个SWC的信息通过RTE连接到其他SWC或者BSW上，且RTE具有管理这些信息的功能。比如接收的SWC正忙（您所拨打的用户正忙），那么RTE负责让发送信息的SWC等待，或者做其他处理；RTE还能触发SWC，就像是这时接收的SWC在睡觉，这时发送的SWC发信息来了，那么RTE就要把接收的SWC叫醒起床。一句话概括就是RTE提供了SWC的运行环境。

RTE的作用：

1. 提供跨ECU/ECU内部的通信管理；
2. 提供对runnable的管理功能（触发、唤醒等，简单说就是runnable需要映射到Task上运行，而这个映射就是通过RTE具体实现的）；
3. VFB（虚拟功能总线），RTE就是VFB的具体实现。

2.2 RTE相关的重要AUTOSAR概念

2.2.1 AUTOSAR软件组件

在AUTOSAR中，应用软件架构上位于RTE的上方，由应用组件组成，应用组件中有一种特殊的应用组件就是传感器/执行器组件，这些组件依赖于ECU硬件，因此由于性能/效率原因不容易重新定位。在系统配置期间，AUTOSAR软件组件可以被部署到任何可用的ECU上。RTE负责确保组件可以通信，并且确保无论组件部署在哪，系统都能按预期工作。考虑到传感器/执行器软件组件，他们能够直接寻址本地ECU抽象层，因为需要通过一个中间传感器/执行器软件组件将信息广播给远端ECU来实现对远端ECU抽象层的访问，因为在不同的ECU上移动传感器/执行器软件组件，可能意味着也会将连接的设备（传感器/执行器）移动到相同的ECU（前提是能够有效访问）。

软件组件按类型定义。在组件被部署到一个ECU上时，组件类型会被实例化。组件类型可以在同一个ECU上实例化多次，在这种情况下，组件类型被称作“多重实例化”。RTE支持每实例一个内存段，来确保每个组件实例具有私有状态。

RTE既支持源代码可用的软件组件（源代码软件组件），又支持仅目标代码可用的软件组件（目标代码软件组件）。

2.2.2 基础软件模块

基础软件模块可以直接访问ECU 抽象层和其他基础软件模块，因此既不独立于ECU，也不独立于位置。

软件组件不能直接访问基础软件模块，所有的通信都通过AUTOSAR接口，因此受RTE控制。不直接访问的要求适用于所有基础软件模块，包括操作系统和通信服务。

2.2.3 通信

AUTOSAR软件组件的通信接口由多个端口组成。AUTOSAR软件组件可以通过它的接口与其他AUTOSAR软件组件（无论该组件位于同一个ECU或不同的ECU上）或同一ECU上的基础软件模块进行通信。此通信只能通过组件端口进行。端口可以归为两类：发送方-接收方，客户端-服务端。发送方-接收方提供消息传递功能，客户端-服务端提供函数调用。

1. 通信样式

RTE为SWC实例间的通信提供了不同的样式：

1. 发送方-接收方（sender-receiver）（信号传递），流程图如下：

1. 客户端-服务端（client-server）（功能调用）
2. 模式切换（mode switch）
3. 非易失性数据（NvBlockSwComponentType）交互

每个通信样式都可以应用于分区内的软件组件分发（包括同一分区内的任务内和任务间分发），分区间的软件组件分发和ECU间的软件组件分发。任务内通信发生在映射到同一OS任务的可运行实体之间，而任务间通信发生在影射到同一分区的不同任务的可运行实体之间，因此涉及关联转换。分区间通信发生在影射到同一个ECU的不同分区的组件中的可运行实体之间，因此涉及关联转换和跨越保护边界（内存保护，定时保护，核心隔离）。ECU间通信发生在影射到不同ECU的组件中的可运行实体之间，本质上是冰法，并且可能涉及不可靠通信。

1. 通信模式

对于发送方-接收方（sender-receiver）通信，RTE提供两种模式：

1. 显式（Explicit）：组件使用显式API调用发送和接收数据单元；
2. 隐式（Implicit）：RTE在调用可运行实体之前自动读取指定的一组数据集单元，并且在可运行实体终止后自动写入（不同的）一组数据集单元。这里使用术语“隐式”是指可运行实体不会主动发起数据的接收和传输。

1. 静态通信

RTE应仅支持静态通信。静态通信仅包括那些在生成RTE时所有通信的源和目的就已知的通信连接。由于运行时间和代码开销会限制适用RTE的设备规模，因此不支持通信的动态重新配置。

1. 通信多样性

除了点对点通信，RTE还支持含有多个提供者或多个需求者的通信连接。

当使用发送方-接收方通信时，RTE支持1:n（即一个发送方，多个接收方），n:1（即多个发送方，一个接收方）的通信，并且限制不允许多个发送方进行模式切换通知。

RTE不协调多个发送方或多个接收方的执行过程，这意味着不同软件组件的行为是独立的，RTE不确保不同发送方同时传输数据，也不确保所有接收方同时接收数据或接收事件。

当使用客户端-服务端通信时，RTE支持n:1（即多个客户端，一个服务端）通信，不支持1:n（即一个客户端，多个服务端）通信。

无论使用1:1，n:1，1:n通信，RTE负责实现通信连接，因此，AUTOSAR软件组件不知道具体配置，这样就允许一个AUTOSAR软件组件在不修改的情况下重新部署到不同的配置中。

1. 通信并发性

AUTOSAR软件组件不能直接访问操作系统，因此AUTOSAR应用层中没有任务。相反，AUTOSAR中的并发操作是基于RTE引用的组件中的可运行实体的。

AUTOSAR VFB规范将可运行实体定义为“可由RTE启动的指令序列”。一个组件提供一个或多个可运行实体，每个可运行实体只有一个入口点。入口点在提供可运行实体执行的软件组件代码中定义标记。

RTE负责调用可运行的实体-AUTOSAR软件组件无法（动态）创建私有控制线程。因此，AUTOSAR应用层中的所有活动都是由RTE触发可运行实体来发起的，作为RTE事件的结果。

RTE事件包含所有可能的情况，这些情况可以触发RTE执行可运行实体。

RTE支持任何具有AUTOSAR接口的软件组件的可运行实体，包括AUTOSAR软件组件和基础软件模块。

可运行实体分为多个类别，每个类别支持不同的设备。

2.3 RTE的生成

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

上图给出了关于SWC和RTE生成器软件的RTE生成步骤。让我们详细了解每个步骤：

1. 收集可用SWC实现 此步骤包括收集SWC描述文件（如果打算重用旧SWC）及其各自的Composition SWCs并进一步使用它们。或者我们也可以创建新的SWC实现并将其用于进一步的步骤。
2. 配置系统 本步骤结合了旧步骤中的SWC，并配置了系统（整车ECU网络），该系统具有不同ECU和其他系统约束的不同组成SWC。在此步骤中，所有SWC都映射到各自的ECU。
3. 系统配置说明 arxml文件，其中包含整个系统（车辆）的ECU的详细信息，该文件在系统配置后生成。
4. 提取ECU特定信息 提取单个ECU的SWC描述和其他详细信息，不同于包含车辆中所有ECU信息的系统配置描述文件。
5. 生成ECU配置 此步骤涉及配置RTE下层BSW中模块比如COM Service等模块的配置，这一步生成的也是一个arxml文件其包含所有ECU的信息，比如BSW的配置，SWC的配置等。
6. 生成RTE 此步骤中，所有Runnables映射到操作系统任务，所有connetions连接到实际的信号。此步骤的输出为Rte.c和Rte.h文件，大致可以称为AUTOSAR的RTE层。此步骤还生成BSWMD（基本软件模块描述）文件，其中包含RTE不同功能的信息。
7. 编译RTE 顾名思义，在这一步中，将编译RTE文件，并生成目标文件，然后将这些文件与其他已编译的BSW和SWC文件链接，以生成可刷写到MCU的可执行文件。

对于系统的每个ECU，都会重复以上步骤。除了RTE文件外，还会为每个SWC生成SWC文件（.h和.c），一些软件还会在SWC.c文件中生成可运行的框架，在SWC.h文件中生成函数原型。所有RTE文件均按照[MISRA]生成(https://en.wikipedia.org/wiki/MISRA_C)-C标准，虽然允许一些MISRA*违规行为，但此类情况记录在评论中。RTE源文件具有应用程序和其他层所需的RTE调用，RTE头文件具有这些调用的原型。

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

2.4 RTE API

RTE提供多种API以便SWC使用从其他SWC或者低层访问数据。RTE APIs可以简单的根据任何函数的Rte_prefix识别，通常分为2种类型：

1. Direct API：在需要高效（零运行时开销）调用时使用。这些API是为每个端口生成的，应用程序可以通过在Runnable中调用API名称直接使用它。在映射API时，可以针对SWC优化此类API。通常，Direct API实现为宏。因此，不可能获得RTE API的地址来与C中的函数指针一起使用。
2. Indirect API：使用端口句柄间接调用API。这种形式效率较低（间接寻址无法优化），但支持一种可能更方便的不同编程风格。

直接和间接API调用都将生成相同的结果，只是调用方式不同。在SWC中，我们可以使用间接或直接API实现。

 2.5 RTE生成的文件关系

在RTE生成之后，RTE生成器工具会生成许多文件，其中的头文件与其他文件有关系，即这些文件被#included到不同的文件中。这些文件以及它们与其他文件的关系如下：

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

Rte_XX_Type.h：这也称为应用程序类型头文件，它包含与应用程序相关的常量，如SWC中使用的范围值或枚举值。该文件包括Rte_Type.h文件。

2.6 Interface

在配置RTE的时候经常会出现这个词，在使用工具配置的时候，如果不太清楚Interface和Port等等的概念的话，即便机械的按照流程配置下来，也依旧不理解，甚至会导致换了一个配置工具后，因为不明白原理结果寸步难行。

Interface是一个抽象的概念，是一个无法直接在代码中对应的概念。可参考：AUTOSAR Port原理概念详解

1. SWC可以比较准确的对应为.C文件，Interface在配置工具的语境下包含了输入输出Port，以及两个Port之间的连接关系的一个集合。
2. 在工具中，会为一个Interface命名，再将输入输出Port连接到这个Interface上，这样RTE层内部如何实现两个Port之间的代码维度的连接，就是工具在生成的了，这个时候内部生成的不管是全局变量抑或是宏定义等等，都会基于这个Interface的元名称进行扩展。正因此，才会需要在工具层面上具象化Interface，并给他一个命名。

总而言之，SR-Port（Sender-Reciever）主要是进行数据的传输，而另一方面CS-Port（Client-Server）则是调用另一个SWC中的服务，或者理解成调用另一个函数。

1. 具体在代码中就会变成，SR是对一个全局变量的操作，当然如果只涉及SWC内部的传输的话，就变成Static变量了。
2. CS的则是在函数中调用另一个函数，特别是另一个SWC的函数才会需要经过RTE来调用，这个另一个SWC可以是本ECU内部的，也可以是跨ECU的。不过对于调用方的SWC，跨不跨ECU并没有什么区别。