vs 生成com组件 其他电脑_AutoSar中RTE的生成准备

稍微整理下RTE的生成准备阶段，即协议阶段。

用于软件组件的RTE生成器

             图1  System Build Methodology

根据之前RTE的overview介绍可以知道，车辆功能的描述基于软件组件组合、软件组件原型和原子组件展开，软件组件的接口定义也在组件组合之中，VFB包含SW-C之间的联系，和实际ECU没有对应关系。

VFB描述了原子组件之间的通信关系，固定了每个SW-C原型和原子组件对于特定ECU的映射，可以生成对应的通信矩阵。在SW-C类型描述中，通过端口交换的数据以抽象的方式定义。现在，系统配置生成器需要定义系统信号(包括实际的信号长度和它们传输的帧)来通过网络传输应用程序数据。RTE生成器通过COM信号相关的系统信号来传输应用程序数据。

RTE生成过程中，系统配置描述被划分到每个ECU的描述。在ECU提取生成过程中，VFB视图的组件组合的层次结构也被平面化，ECU提取的组件原型则代表真实的实例。ECU提取只包含单独配置一个ECU所需的信息,并将其用于各自的ECU配置。每个ECU实例单独配置和生成对应的RTE信息。

ECU配置编辑器会对ECU配置值进行迭代，直到所有配置问题都得到解决。由于每个配置编辑器专门负责ECU配置的特定部分，所以几个配置编辑器有必要特殊化配置。这种情况下，一个编辑器可能配置COM堆栈(不是通信矩阵，而是各个模块的交互)，而另一个编辑器用于配置RTE。

由于特定BSW模块的配置并不完全独立于其他模块，因此需要将编辑器多次应用于ECU配置值，以确保所有配置参数的一致性。只有当配置问题得到解决时，RTE生成器才会用于生成实际的RTE代码，然后这些代码将与其他BSW模块、SW-C代码一起参与编译和链接。

RTE生成器需要处理许多信息源，因为RTE生成器的必要信息是以ECU配置值为基础，而ECU配置值可能分布在多个文件中，其本身也引用多个其他AUTOSAR描述。RTE生成器支持读取单个文件和将文件集存储在文件系统中。这个过程中的配置工具，提供一种在文件系统选择特定文件和文件集的机制。

AUTOSAR的XML描述可以包含在几个文件中，有些文件用于确定数据类型，有些文件用于定义接口等。RTE生成器工具支持合并AUTOSAR模型，这些模型在读取一组文件时被分割并存储在多个部分模型中。同时，模型的合并也包括引用的解析，RTE生成器应该能够按任何顺序读取子模型。

RTE生成器支持对AUTOSAR XML描述的解释和创建。无论是使用或没有文档对应的AUTOSAR XML架构，这些描述是由XML推荐、W3C XML 1.1 规范定义有效的。换句话说，即使该工具不使用标准的XML机制来验证XML描述，它将确保XML描述可以成功地通过AUTOSAR XML架构进行验证。

如果RTE生成器希望对AUTOSAR架构验证AUTOSARXML描述，它应该在自己的资源中提供必要的模式文件。RTE生成器会为XML提供序列化，不会更改传递给生成器的模型内容。

用于BSW调度器的RTE生成器

     图2   Basic Software Scheduler Methodology

ECU配置阶段是BSW调度器配置的开始，在此阶段收集不同BSW模块的所有需求，输入信息在各个BSW模块的描述文档中提供。然后，将BSW调度器配置生成BSW调度器代码，该代码将编译并构建到ECU的可执行文件中。

RTE协议阶段：

                 图3   RTE Contract Phase

为了能够使用RTE特定的API支持AUTOSAR软件组件开发，在所谓的RTE协议阶段，RTE生成器从软件组件内部行为描述生成组件API(应用程序的头文件)。在使用AUTOSAR软件组件模板的SW-C接口描述中，特定SW-C的AUTOSAR接口是需要描述的。这意味着带有端口及其接口的软件组件类型。另外，在软件组件内部行为描述中，还定义了可运行实体和RTE事件。RTE生成器可以根据这些信息生成特定的API来访问端口，以及发送和接收数据。

使用生成的组件API(应用程序头文件)，SW-C开发人员可以提供软件组件的源码，而无需考虑后续的通信是本地的还是使用某些网络。

必须考虑到AUTOSAR软件组件开发过程是迭代的，在AUTOSAR软件组件开发过程中，AUTOSAR软件组件描述可能会发生变化。这要求重新生成应用程序头文件，以反映软件组件描述中所做的更改。

当软件组件成功编译后，“组件实现描述生成”工具将分析生成的目标文件，并使用来自特定实现的信息增强软件组件描述。这包括关于ROM和RAM的实际内存需求的信息，并进入AUTOSAR软件组件模板的“组件实现描述”部分。

需要注意的是，在实现预编译时间可变性的情况下，还需要预编译数据集协议阶段才能编译软件组件。因此，当一个软件组件交付时，它将包括以下部分：

• 组件的类型描述

• 组件内部行为描述

• 组件实现和编译过的组件

• 组件实现描述

当整个系统组装完成时，需要上述信息为系统生成步骤提供足够的信息。 

BSW调度器协议阶段：

能够支持BSW模块开发的BSW调度器特定API模块连接头和连接类型的头文件(包含基本软件调度程序API定义和声明的文件，关联到单个基本软件模块实例，通过RTE生成器在所谓的基本软件调度器协议阶段生成。

需求输入包括：

• BSW模块描述

• BSW模块内部行为；

• BSW模块实现

预编译数据集协议阶段：

在RTE中，预编译数据集协议阶段主要为产生条件值的宏，它用来解决部分SW-C或BSW的预编译可变性的实现。通过预定义的变体来定义特殊值的定义。这些预定义的变体因素包含ECU配置相关的系统常数值的定义。

这个阶段的输出是RTE配置的头文件。使用预编译时间可变性编译软件组件的特定变体时需要这些文件。条件值的宏通过使用预处理器语句来实现预编译可变体，因此需要通过运行C预处理器来解决实现的可变性。

RTE的ECU配置编辑

在配置ECU时，还需要配置RTE。这分为几个必须迭代执行的步骤：RTE的配置和其他模块的配置。所以，首先RTE配置编辑器需要收集建立可操作RTE所需的所有信息。该收集过程包括关于软件组件实例及其通信关系、可运行实体和涉及的RTE事件等的信息。所有这些信息的主要来源是ECU配置值，它可能提供对进一步描述的参考，如软件组件描述或系统配置描述。

另外一个输入源是定时扩展规范。此模板可用于指定可运行实体的执行顺序。RTE配置编辑器可以使用这些信息来创建和检查RTE事件到OS任务映射的配置。

ECU配置编辑器的使用，覆盖ECU配置值的不同部分。如果没有循环依赖项就不会收敛，收敛到一个稳定的配置，然后完成ECU配置过程。 

---

作者简介：

Demu，传统汽车电控向智能驾驶转变的汽车人。从事发动机控制器系统工程师和软件工程师多年，有丰富的ECU系统和软件设计经验。欢迎大家一起留言交流，共同进步。