参考书目

参考内容	文档
[1] General Requirements on Basic Software Modules	AUTOSAR SRS General.pdf
[2] Glossary	AUTOSAR Glossary.pdf
[3] Requirements on Basic Software Module Description Template	AUTOSAR RS BSWModule Description Temp.pdf
[4] Requirements on ECU Configuration	AUTOSAR RS ECU Configuration.pdf
[5] Software Component Template	AUTOSAR SoftwareComponentTemplate.pdf
[6] Specification of ECU Configuration Parameters	AUTOSAR SWS ECUConfigation Parameters.pdf
[7] Specification of System Template	AUTOSAR SystemTemplate.pdf
[8] Methodology	AUTOSAR Methodology.pdf
[9] Specification of Interoperability of Authoring Tools	AUTOSAR InteroperabilityAuthoringTools.pdf
[10] Template UML Profile and Modeling Guide	AUTOSAR TemplateModelingGuide.pdf
[11] Model Persistence Rules for XML	AUTOSAR ModelPersistenceRulesXML.pdf

1、简介

根据AUTOSAR Methodology，配置过程包含4个步骤

(1) 系统配置

(2) ECU 抽取

(3) ECU 配置

(4) 可执行代码生成

配置过程从对整个系统的描述开始： System Description （系统描述）。在下一步中，整个系统描述被拆分为几个 ECU 配置，而每个配置都包含有关一个单个 ECU 的所有信息。该 ECU 提取是 ECU 配置步骤的基础。

在 ECU 配置过程中， AUTOSAR 架构的每个模块可以针对该 ECU 的特殊需要进行配置。由于相当复杂的 AUTOSAR 架构、模块和模块之间的相互依赖关系，需要相应的工具支持： AUTOSAR ECU 配置编辑器。

工具需要有关 ECU 配置的知识参数及其约束，如配置类、值范围、多重性等。此描述是工具的输入，必须标准化。描述配置参数的定义称为 ECU 配置参数定义，在本规范（第3.3 章）中有详细描述。

为了确保所有工具在配置的 参数值中使用相同的输出格式　， ECU 配置描述也是本规范的一部分并在后面详细描述（第3.4章 ）。ECU 配置描述一方面可能是其他配置工具的输入格式（在几个配置编辑器的工具链中），另一方面它是生成器的基础。配置的参数生成到 ECU 可执行文件中。　

1 .１ 缩写

本节描述了特定于 ECU 配置规范的缩写 那些不属于官方 AUTOSAR 词汇表 [ 2 ] 的部分。

以下是本规范中特别使用的缩写：

•  ECUC ， ECU Configuration

•  ECUC Description ， ECU Configuration Description

•  ECUC ParamDef ， ECU Configuration Parameter Definition

•  ECUC Value E ， CU Configuration Value

•  StMD ， Standardized Module Definition

•  VSMD ， Vendor Specific Module Definition

2 ECU 配置方法

ECU 配置是整个 AUTOSAR 方法中的一个步骤，它是  记在 [  8  ] 中

2.1 使用的符号

图 1.1 和所有其他取自 AUTOSAR methodology [  8  ] 的图使用称为 SPEM （软件过程工程元模型）的形式符号，在 [ 8  ] 中有详细解释 。 本文档中使用的 SPEM 元素是：

•  Work products ( 蓝色文档外形颜色 )

•  Activities ( 块箭头 )

•  Guidances ( 三角尺 ) ，描述工具，通过虚线连接到它们支持的活动 .

工作流程用带箭头的实线表示工作流程的方向。依赖关系用带箭头的虚线表示，从依赖元素指向它所依赖的元素。组成关系由在聚集元素末端带有实心菱形的实线描绘。

2.2 ECU 配置的输入

 ECU 配置有两个输入源 。首先，所有必须在多个 ECU 之间达成一致的配置都在系统配置中定义，这将导致一个系统配置描述（ System Configuration Description ）（以及由此产生的对于单个 ECU 的 ECU Extract of the System Configuration  ）。其次， ECU BSW 是使用 BSW 模块构建的。这些模块实现的细节在 BSW Module Descriptions 中定义 。

2.2.1 ECU 系统描述提取

ECU 配置只能在合理的 system Configuration Description 生成后启动（见图 1.1 ）。 System Configuration Description 包含所有相关的系统范围的 配置，例如

•  系统中存在的 ECU

•  连接这些 ECU 及其配置的通信系统

•  这些通信系统的通信矩阵（发送和接收的帧）

•  软件组件、组件的端口、接口和连接的定义。

•  SWC 与 ECU 的映射

ECU Extract of the System Configuration 是与 System Configuration Description 格式相同的描述，只是前者只包含与一个 ECU 的相关的配置。

2.2.2 BSW 模块说明

所有映射到一个 ECU 的应用程序软件组件都在一个 ECU 的 ECU Extract of System Configuration 中定义。然而， ECU 软件的一个主要部分在描述中缺失：由于 BSW 模块是标准化的，并且它们的实现细节与 ECU 之间的通信无关，因此 ECU Extract of System Configuration 不包含有关这些模块的信息。相反，单独的 BSW module descriptions （ BSWMD ）由 BSW 模块实现者提供。 BSWMD 包含：

• 软件模块端口和接口的定义，用于软件组件和 RTE 。此信息是 RTE 生成的重要输入，因为它允许将软件组件端口与 BSW 连接。

• 供应商特定的模块定义（ Vendor Specific Module Definition ）。

对于每个 BSW 模块， AUTOSAR 定义了标准化的计算参数。 BSW 模块实现必须支持这些标准化参数的配置。这些定义可以按照第 4.1 章中定义的规则进行调整，以适应实现。此外，模块供应商可以定义其他配置参数，以便对硬件进行配置，并实现特定于实现的细节。 Vendor Specific Module Definition 包含标准化参数（由实现者调整）和特定于供应商的参数的定义。它引用了它所细化的 Standardized Module

Definition （标准模块定义）。

•  Vendor Specific Pre-configured Configuration Description

这部分 BSWMD 使用 ECU Configuration Description 的子集—— ModuleConfiguration （模块配置）（参见第 3.4.2 章）。它包含供应商特定模块定义中定义的那些配置参数和容器的值，这些参数和容器由模块的实现固定。固定模块配置参数值的原因有几个：

√   如果模块作为目标代码交付，则在编译模块之前，必须固定所有预编译时参数。因此，这些参数是固定的，并且所选值必须记录在 BSWMD 中，以便剩余参数和相邻模块的后续配置可以考虑这些固定值。

√   驱动程序模块的配置通常受到硬件在几个方面的限制。首先，硬件定义可以配置的实例数。例如，特定微控制器的 DIO 驱动程序有固定数量的可以配置的 DIO 端口和通道。每个端口和每个 channel 由一个 Container 表示（参见第 3.4.3 章）。因此，驱动程序的 BSWMD 应使用固定名称（例如 PORT-1-CHANNEL-1 ）固定这些容器，以便配置器和后续生成器都可以将这些容器与硬件进行匹配。其次，在每个硬件实例的配置中，某些在一般情况下可更改的参数由硬件针对某些实例进行固定。在 DIO 示例中，一般情况下，通道 Chanel 的方向可以通过配置（ IN 或 OUT ）来选择。但对于某些通道，此方向可能由硬件固定，因此必须在配置中固定。

第 2.3.2 章描述了如何使用 Vendor Specific Pre-configured Configuration Description 来构建基本的 ECU Configuration 。

• Vendor Specific Recommendationed Configuration Description

除了预配置的参数外， BSWMD 还可以包含（即参考）所有其他参数和容器的推荐值设置，这些设置可以通过工具来预配置模块，请参见第 2.3.2 章。

• 规范模块内部行为，例如与模块调度相关的信息。 BSW module description 的这一部分与方法论无关。也就对此不作描述。

2.3 ECU 配置

ECU 配置可以分解为三个活动：

• 生成基本的 ECU Configuration Description

• 编辑 ECU Configuration

• 生成 配置的 Module Code

如图 2.1 所示 ：

这三个活动将在后续章节中介绍。

它们都使用单个工作产品，即 ECU Configuration Description  （ ECUC Description ），其中包含（即引用） ECU 上所有软件模块的所有配置信息。关于为什么需要整个工作产品的背景信息将帮助理解后续章节。

2.3.1 ECU 配置说明

ECU Extract of System Configuration  仅定义了必须在 ECUs 之间商定的配置，为了生成在 ECU 上运行的工作可执行程序，必须提供更多的配置信息。

在 PRE-AUTOSAR 系统中，此配置信息是收集在多个不同的配置格式中。其中一些格式是标准化的，例如 OSEK OIL 和 FIBEX ，但许多是针对特定模块实现的专有格式。这种方法的优点是不同的格式可以针对手头的问题进行定制，并且可以很容易地扩展。在 AUTOSAR 上下文中，该方法也有严重的缺点：由于不同的软件模块具有许多相互依赖性，因此需要了解相邻模块的配置以及多个模块之间通用的参数设置。最好通过一些示例来说明这一点：

•  操作系统和 RTE 生成器都需要定义支持 SW-C 可运行对象的任务：操作系统需要在其任务计划中定义任务 ;RTE 将生成任务正文。

•  时钟的层级跟所有具有时钟输入的模块有关。

•  需要协调硬件资源对模块的分配。例如，硬件定时器需要 GPT 、 OS ，也可能是 PWM 和 ICU; 定时器的配置需要在不同的消费模块之间对齐。

如果 AUTOSAR 要继续使用上面提出的方法，则特定模块的配置工具和生成器需要读取多个不同的格式。在 RTE 的示例中，一个工具将需要读取 OSEKOIL 文件、 RTE 特定格式、其他相邻模块的格式。不同的配置格式可能包含冗余信息。这将很难在整体配置内获得一致性。

因此， AUTOSAR 采取了不同的方法并定义了单一格式，即 ECU Configuration Description 。

这一个描述将软件模块的完整配置收集在一个 ECU 中。然后，每个模块生成器可以从该单一格式中提取自己所需的配置数据的子集。

2.3.2  生成基本 ECU 配置说明

ECU Configuration Description 包含了存在于 ECU 之上的所有软件模块的配置 . 不同模块的配置位于不同的章节。在基本 ECU Configuration Description 中，使用 Vendor Specific ECU Configuration Parameter Definition( 通过该模块的 BSWMD) 和 ECU Extract of the System Configuration ，特定模块的章节可以被生成。参见图 2.2 。 这个生成过程是半自动化的：

对于 ECU 中的每个 BSW 模块，模块实现必须被选择。这通过引用和 BDW 模块一起交付的 BSWMD 来实现。 BSWMD 定义了容器中所有配置参数和对应的结构，这些对应于特定的模块实现。这通过 Vendor Specific Module Definition 来实现，参见 章节 2.2.2 。一旦元模型被引入，构建基础 ECU Configuration Description 的时候　必须被遵循的规则就可以被定义。

2.3.3  编辑 ECU 配置

一旦在基本 ECU Configuration  描述中生成了特定模块的部分，就可以使用 AUTOSAR ECU Configuration  编辑器进行编辑。这些编辑器可以与用户交互一起运行，半自动或自动，具体取决于模块和实现。

ECU 配置的工具策略和工具细节超出了本规范的范围，因此以下  2.3.3.1 至 2.3.3.3 节 提供了丰富的信息。存在这样的假设 ， 配置编辑器对其支持的配置部分执行一致性和完整性检查。

ECUC 参数定义和 ECUC 描述是被设计为 支持不同工具方法。在以下，介绍了在制定规范过程中考虑的不同方法。 ECUC 参数定义和 ECUC 描述支持这些工具方法。其他方法可能与此规范一致，但尚未明确考虑。

工具供应商在工具可能采用 ECU 配置的方法方面具有高度的自由度。 ECU 配置工具可能由一个能够操作 ECU 配置各个方面的整体式编辑器组成，它可以是一个核心工具框架，它采用插件组件来操作 ECU 配置的特定方面，它可能是一组专用工具，每个工具都能够配置一个 特定的类型或软件模块子集，或者，更有可能的是，软件供应商可以提供单独的自定义工具来仅配置它们所支持的代码块   （类似于微处理器供应商为他们自己的微型提供专门的调试器）。

不同工具方法的共同点是，每个配置编辑器都必须能够读取（可能不完整的） ECU Configuration Description ，并以相同的格式写回其修改后的配置结果。修改可能包括 ECU 配置值的更改值，并添加了包含所有 ECU 配置值的容器实例（仅适用于具有可变多重性的容器 / 参数）。

在每种情况下， ECU Configuration Description 都有望成为参考点，即该过程的支柱。

以下各节将介绍一些可能的工具形式，并确定它们的一些优点和缺点。

2.3.3.1 自定义编辑器

在自定义编辑器方法中，如图  2.3 所示， 每个 BSW 模块都捆绑了一个自定义配置编辑器和一个生成器 （例如 在图  2.3 中的  AUTOSAR RTE Configuration Editor  和  AUTOSAR RTE Generator  ）。这些工具可以针对配置一个 BSW 模块的特定任务进行优化，并且可能相当强大。 BSW 模块配置和 ECU 配置描述中的其他配置项之间的复杂依赖关系可以在该工具中表达和支持。   每个 BSW 模块的供应商都需要提供一个工具。   系统和 ECU 工程师需要大量的工具来处理各种 BSW 模块。   每个工具可能都有单独的外观和感觉，这可以增加成为精通所需的培训和经验。  

2.3.3.2 通用工具

如图 2.4 所示的 AUTOSAR 通用配置编辑器能够配置配置参数定义中定义的任何参数。 它将读取这些定义，并提供一个通用接口来编辑 ECU 配置描述中所有参数的值。 它只能解析在配置参数定义中显式定义的相对简单的依赖项。 只需要有限数量的编辑器，也许只需要一个，而且在通用工具之间，外观和感觉不太可能有太大的差异。 因此，培训和工具成本可能会更低。 这样的工具已经存在或即将存在的例子有 tresos 、 GENy 、 DAvE 和 MICROSAR ，不过应该注意的是，在撰写本文时还没有 ECU 配置编辑器。 在生成方面，可以使用通用生成器，也可以为各个模块使用自定义生成器。

2.3.3.3 工具框架 ( 增长见识 )

图 2.5 所示的工具框架是自定义工具和通用工具之间的交叉，其中专用配置步骤 (OS 、 COM 、 MCAL 等 ) 作为插件集成到通用 ECU 配置框架中。 该工具的核心将是一个框架，它提供某些核心服务，例如从标准文件格式导入和导出数据，维护标准的内部数据结构，并为用户提供一个 HMI 。 保证 ECU 的 “ 配置描述 ” 按照定义的方式读取、解释和写入。 该框架还可以监视和控制用户 / 项目工作流程。 它提供了较低的初始工具和培训投资。 该方法的强大之处在于能够添加扩展核心功能的插件模块。 这将允许非常复杂的功能，可能专用于一个 BSW 模块，由个别供应商添加。 此外，还可以在所有 BSW 模块中添加通用插件，以解决配置的特定方面。 这种方法依赖于一个标准框架 : 多个框架标准可能导致较高的工具成本。 这类工具的一个例子是美国国家仪器公司的 LabVIEW 测试和测量工具以及 Eclipse 框架。

2.3.3.4 ECU 配置内的迭代

很明显的一点是，在软件模块内部和模块之间的参数之间，可能既要进行优化，也要进行权衡。 例如，配置处理详细的调度信息或所需的 BSW 模块的配置数据。 因此，这是一个重要的设计步骤，需要复杂的设计算法和 / 或工程知识。 ECU 配置因此可能是一个迭代的过程。 这个迭代最初将在编辑器之间进行，然后，当实现了一个可信的 ECU 配置时，代码生成可能会突出显示需要进一步迭代的额外更改。 希望大多数生成器 - 编辑器迭代将受到限制，这可以如下方式实现：

图 2.6 显示了一组定制工具如何在一个迭代链中使用，以实现一个成功的 ECU 配置。 在工具链中依次调用工具，以创建 AUTOSAR ECU 配置。 迭代周期必须通过反复激活 BSW 特定方面的不同配置工具来实现。 工具之间的依赖关系，以及配置工作流程，可能需要显式地表示出来。 配置工具只需要支持单一的标准化接口，即 ECU 配置描述模板，但是对于特定 ECU 的配置状态并没有全面的描述，因为每个工具只专门用于配置的一个特定子集。

在 2.3.3.1,2.3.3.2 和 2.3.3.3 节中给出的不同工具链模型将明显地影响迭代的数量，迭代在 ECU 配置中发生的位置，以及如何控制和跟踪它。

2.3.4 生成配置模块代码

AUTOSAR ECU 配置方法的第三步，也就是最后一步，已经在前面的章节中被引用，因此不奇怪 : 为不同的 SW 模块生成配置模块代码。 生成是将量身定制的 ECU 配置描述应用于软件模块的过程。 这可以不同的方式执行，并取决于为不同模块选择的配置类 ( 参见 2.3.4.1 章 ) 和实施者的选择。 对于每个 BSW 模块，一个生成器从 ECU 配置描述中读取相关参数，并创建实现指定配置的代码，如图 2.3 和 2.4 右侧所示。 在生成步骤中，翻译 ECU 配置描述的抽象参数 对硬件和实现特定的数据结构，适合相应的软件模块的实现。 本规范没有详细说明生成器工具。 但是，我们假设生成器在生成所需的配置部分执行错误、一致性和完整性检查。

2.3.4.1 配置类简介

基础软件模块的开发包括编译、链接、下载到 ECU 内存的开发周期。 参数配置可以在以下任何一个过程步骤中完成 : 预编译时、链接时甚至构建后。 根据配置参数的流程步骤，配置类被分类如下 ：

•  编译前

•  链接时

•  构建后

不同流程步骤中的配置对 ECU configuration 参数的处理有一些影响 : 例如，如果一个配置参数被定义为编译前，编译后该配置参数不能再更改。 或者，如果在构建后定义了配置参数，则必须将配置参数存储在一个已知的内存位置。

在标准化参数定义中，参数的配置类通常不是固定的，因为可能有几种变体。 然而，一旦实现了模块，实现中每个参数的配置类通常都是固定的。 从可用的变体中选择正确的配置类取决于应用程序的类型和模块实现者的设计决策。 不同的配置类可以组合在一个模块中。 例如，对于构建后可配置的 BSW 实现，只有参数的一个子集可能是构建后可配置的。 有些参数可能被配置为预编译时间或链接时间。 配置类将在本章接下来的章节中详细解释。 输出文件格式为 .exe 和 .hex ，在本节的图中用作示例文件格式。 除了 .hex/.exe 之外，还可能使用其他输出文件格式。

2.3.4.2 配置类 编译前时间

这种类型的配置是在编译源代码之前完成的独立配置。 这意味着这些可配置元素的参数值是在编译之前选择的，并将在编译时间之后生效。 可配置参数的值是在软件开发过程的早期阶段决定的，参数值的任何更改都需要重新编译。 预编译参数的内容不能在后续的开发步骤 ( 如链接时或构建后 ) 中更改 。

图 2.7 中的示例 BSW1 显示了一种实现预编译时参数的可能方法。 可配置参数值将保存在一个配置头文件中，并与模块源文件一起编译，它不受 BSW1 配置生成器的影响。 图 2.7 中的示例 BSW2 显示了另一种方法，其中 BSW2 配置生成器生成完整的、特定于配置的代码。 这两种方法都同样有效。

当必须在选择其他可靠参数之前决定参数值时，预编译时配置是正确的选择。 例如， CRC 初始校验和参数的算法选择是基于 CRC 类型 (CRC16 或 CRC32) 的选择。 当选择 CRC16 时，处理时间会增加，但内存使用会减少。 而当选择 CRC32 时，处理时间会减少，但内存占用会增加。 在编译源代码之前，实现者应该根据需求和资源可用性做出正确的选择 。

下面列出了可以采用预编译时配置的示例 :

•  配置 NVRAM 管理器的内存表个数和块描述表个数

•  切换 RTE 生成器的两种可用的生成模式 (VENDOR MODE 和 COMPATIBILITY MODE)

•  启用宏，用于软件模块的开发错误跟踪

2.3.4.3 链接时间的配置类 (Configuration Class Link Time)

这种类型的配置是在连接时对软件模块进行的。 这意味着软件模块的目标代码从另一个目标代码文件接收其配置的部分，或者它由链接器选项定义。 链接时间参数通常在向集成程序交付目标代码时使用。

这个配置类为配置过程提供了模块化的方法。 一个单独的模块将处理配置细节，这些参数值将在链接过程中提供给其他模块。

在这种方法中 ( 如图 2.8 所示的示例 ) 声明了对在一个公共头文件 (BSW3 header) 中包含配置参数数据的常量的外部引用，这些常量包含在模块源文件 (BSW3 Code) 和模块配置源文件 (BSW3 configuration data) 中。 模块源文件需要这个头文件来解析引用，模块配置源文件需要根据定义交叉检查数据类型声明。 模块源文件和模块配置源文件分别编译，分别生成模块目标文件和模块配置目标文件。 在连接过程中，通过解析外部引用将配置数据提供给模块对象文件。 当需要修改配置参数值时，需要将模块的配置对象文件替换为包含新参数的配置对象文件。

下面列出了可以采用 Link Time 配置的示例 :

•  信号的初值和无效值

•  为各 NM 实例配置的唯一通道标识符

•  CAN 网络逻辑句柄

•  CAN 接口的硬件接收句柄和硬件传输句柄的标识符和类型

•  ComFilterAlgorithm

•  COM 回调函数指示接收到无效信号的 RTE

2.3.4.4 构建后时间的配置类 (Configuration Class Post-Build Time)

在构建了 SW 模块或 ECU 软件之后，可以进行这种类型的配置。 在代码链接的完整 ECU 软件下载过程中，软件可以接收到其配置参数，也可以接收到可单独下载到 ECU 的配置文件，从而避免 ECU SW 模块的重新编译和重建。

为了使构建后重新配置成为可能，重新配置的参数应存储在 ECU 存储区域的已知内存位置。图 2.9 显示了一个示例。 这里展示了两种不同的方法。 BSW4 和 BSW5 都有独立于构建后配置数据进行编译和链接的代码。 对于 BSW4 ，头文件 BSW4 header 包含配置数据结构的结构和位置信息。 BSW4 配置是使用普通的 C 源代码和编译器和链接器生成的。 对于 BSW5 ，一个专门的 BSW5 配置生成器直接以可加载到 ECU 内存的格式生成必要的数据结构。 BSW5 代码需要遵循专有工具定义的结构来访问这些数据结构。 在这两种情况下，生成的十六进制文件将被定位到一个已知的内存位置，以便 ECU 可执行文件可以在下载后访问最新的配置数据。

此配置类允许在软件模块构建后更改配置参数值。

下面列出了可以采用构建后配置的示例案例。

•  CAN 帧的标识符

•  CAN 驱动器波特率和传播延迟

•  COM 传输方式，传输方式时间偏移和时间段

2.3.4.5 替代生成方法 ( Alternative Generation Approaches )

如前所述， ECU 配置描述是存储基于 AUTOSAR 的 ECU 的所有模块配置参数的唯一配置源。 然而，对于 OS 等几个模块，已经建立了现有的配置语言。 这些语言将来可能仍将用于非 autosar 系统。 因此，用于 AUTOSAR 和非 AUTOSAR 系统的模块必须同时支持不同的配置语言。 这可以通过不同的方式实现，如图 2.10 所示。

在完全基于 AUTOSAR 的方法中，生成器读取 ECU 配置描述，并在一个步骤中直接输出相关源代码，该步骤由示例中的 AUTOSAR OS 生成器支持。 为了支持现有生成器工具的重用，这个步骤可以分为两个步骤。

然后，第一个活动是使用 AUTOSAR OS 从 ECU 配置描述中提取所有操作系统配置信息到 OIL Rewriter ，并将其以遗留工具使用的格式存储 ( 所选示例中的 OIL 文件 ) 。 现有的 OSEK 操作系统生成器可以读取中间格式来生成代码。 然而，任何遗留配置工具都不能更改中间格式，因为这些更改可能会使整个配置不一致，而且这些更改会随着中间格式的下一次生成而丢失。

因此，图 2.10 中所示的活动 ( 提取、生成 ) 都不包含任何由工程师做出决定的工程步骤。 它们是全自动的，因为所有的输入驱动这些步骤都包含在 ECU 配置描述中。

2.4 ECU 配置步骤

配置好的代码可用之后，必须对其进行编译、链接和定位，以生成可以加载到 ECU 内存中的二进制文件。 这些活动超出了 ECU 配置的范围，因此这里没有详细解释 。