2.3.3.1 RTE特征

正如2.2.2节所述，在AUTOSAR架构中，基本上有两个独立部分——一个在RTE上面，另一个在RTE下面（图2.5）。在RTE的下面部分中，BSW模块可以随意调用或使用任何其他模块或API功能，例如，某些操作系统直接服务。在RTE的上面部分，ASW组件通过端口相互通信。不允许有其他的通信方式（如通过允许共享全局变量）。一个ASW组件也不允许直接使用任何BSW模块。此外，ASW组件的动态行为的描述和实施，是通过“可运行的实体”来完成的。一个可运行的实体是一个ASW组件的一个可调度单元。基本上，它是一个序列的指令，可以由RTE开始——作为RTE触发事件的结果。例如当新的数据到达一个接口时、当一个计时器到期时或者当一个服务器调用返回时，这样一个RTE事件会触发。可运行的概念实体及其激活在参考文献[14，17]中描述。

图2.5 RTE特征

RTE的任务是将这两个部分粘合在一起。“胶水”这个词在这里的上下文中是非常重要的。应该明确的是RTE不仅仅是ASW与BSW之间的一个抽象层。在非AUTOSAR应用程序中，ASW通常直接采用操作系统服务（如激活一个任务），或直接发送或接收CAN信息。在AUTOSAR中，这是不可能的。ASW组件根本不知道操作系统任务的概念或CAN信息。同样，没有这些概念和AUTOSAR之间的一对一映射。因此，它将不足以创建一个将现有的专有应用程序的包装，以使其与AUTOSAR一致。相反，整个内部行为必须适应AUTOSAR范式。

因此，RTE采用BSW是为了通过指定的接口和运行的实体来实现ASW组件的特性。这包括两项主要任务：实现通信和实现运行实体的激活。

对于通信任务而言，RTE提供了一组API，它们用于发送或接收数据元素，及在客户端/服务器通信情况中的远程服务器调用。可运行实体映射到操作系统任务上（2.4.5节）。因此，为了激活运行实体（比如，可运行实体需要的数据已经到达），RTE通常激活相应的可运行的实体映射到的操作系统的任务。但在客户端/服务器操作中，也有可能以直接功能调用的形式，调用一个可运行的实体。

RTE进而负责通信期间数据的一致性，也就是在接收和发送信号时，数据不会改变。(www.daowen.com)

2.3.3.2 生成RTE

生成RTE为了确保它适合一个给定的ECU和系统配置。这意味着一个RTE的实现，总是只提供给定配置所需的功能而已。生成过程分为两个阶段（2.4.5节）：

•合约阶段：这一阶段是ECU独立的。它提供了给定的ASW组件和RTE之间的合约，也就是说，ASW可以用于对付API组件。这个阶段的输入就是使用所有接口和运行的实体来描述ASW组件。结果就是具体的ASW组件头文件，它可以包含在对应的源代码文件中。在这个头文件中，所有可以被ASW组件使用的RTE API函数要进行声明。它还要声明必要的数据类型和ASW组件所需的结构。允许的API函数组取决于给定的ASW组件的端口。例如，如果一个ASW组件具有一个数据元素d的发送端口p，那么在合约阶段将生成API函数Rte_Send_p_d。ASW组件使用该函数通过端口p，发送数据元素d。

•生成阶段：在这个阶段，具体代码生成在一个给定的ECU上执行。这个阶段的输入是ECU配置描述，其中特别包括运行实体到操作系统任务或到通信矩阵的映射。它们和ASW组件头文件一起，在合约阶段创建，且所有必要的BSW代码、生成的代码之后可以编译成给定ECU可执行的文件。

请注意，还可以提供一个只以对象代码形式表示的ASW组件，例如这是为了保护知识产权。所有必要的信息是ECU独立的，且在合约阶段早已可用。使用ASW的特定组件的头文件，可以编译给定ASW组件的源代码。接着，生成的目标代码和头文件一起打包交付给客户。

然而，目标代码对于优化没有什么潜力，例如某些函数不能按照C宏语言来实施。而如果ASW组件的源代码可行的话，那么这将是有可能的。