AUTOSAR参数配置类及变体概述

作者：Stephen Du

免责声明： 本文为个人学习笔记及总结，仅代表个人观点，尽可能保证内容准确性。复制/转发请注明来源/作者。

欢迎添加微信交流学习。

---

修改历史	描述
V1.0	第一次发布
V1.1	11/26/2020，修正3章节，配置集中不当例子

1. 配置类/等级(Configuration Classes)

AUTOSAR软件分层架构里定义了以下三种配置等级/配置类（Configuration Classes）：

1.1 Pre-compile time/预编译时

所有的代码和数据在编译器运行前就已经决定了，编译完成（这里指链接完得到二进制文件）后代码和有效数据同时放到ECU的FLASH中（指代码和数据均已被包含在二进制文件里面）。比如：

• 预处理指令（比如常见的宏定义#define，但不仅仅包含这个）。

配置为该类型的模块的所有源文件都必须作为目标代码交付（包含：xx.c/xx_structs.h/xx_cfg.h/xx_cfg.c）。

该类型的优缺点请见后面“变体”章节里面的示例1的解释。

1.2 Link time/链接时

编译某代码的时候不添加数据，数据是在链接阶段由链接器从其他模块添加进来的。链接完成后，代码和有效数据已被同时放到ECU的FLASH中（指代码和数据均已被包含在二进制文件里面）。主要指模块外的常量。

比如某模块A依赖于其他模块里面定义的常量数据，这些常量数据可以在模块A编译后仍可进行更改配置，且不用重新编译模块A。

注意上面是说的不用重新编译模块A，通常修改的数据对应的模块是需要重新编译的，整个工程也是需要重新链接生成目标文件的。

配置为该类型的模块，只要求xx.c文件作为目标代码交付（也就是用户不可更改该文件）。这意味着上面Pre-compile time里面的预编译指令在代码实现时需要转变为变量/常量。

该类型的优缺点请见后面“变体”章节里面的示例2的解释。

1.3 Post-build time/构建后

代码里面使用到的数据，在编译和链接完成后仍没有添加到里面，而是代码里面通过指针的方式指向某个FLASH地址，并且这个地址所对应的数据是空的（或者你理解所对应的数据是无效的，这就是为何我前面特别强调有效数据）。这些数据不是在编码阶段提供的，而通常是在制造过程中或以后阶段提供（工厂产线，4S店等）。主要指可重新加载的、模块外的常量，这和第二种非常相似，区别就在于数据可以在指定内存区域重新加载，如ECU产线从新刷写，标定数据等等。

什么意思呢，再说详细点，第二种里面那些常量没有特别指定内存区域，就保持默认的链接文件配置，那么他们的地址信息是变化的，可能你修改一行代码后就完全不一样了，这样的话你是没办法去直接修改他的值的，只能在源代码里面修改，然后重新编译。

但是第三种就解决了上述问题，有些特殊的数据，我们在链接文件里面单独划分一个独立的内存区域出来专门存放，划分出来的内存区域地址是固定的。这样即使编译完后我们想修改其中某个数据，我们可以直接去修改二进制文件即可/直接在线更新，不用重新编译。与之相关的常见应用有：CCP/XCP标定协议或bootloader升级程序/UDS等。

事实上这里（Post-build time）又可以细分为两种，分别为：构建后可加载（post build loadable）,构建后可选择（post build selectable）。

可加载指：在运行时使用的数据是固定的。

可选择指：在运行时使用的数据是可选择的。

注意： “可加载” 和 “可选择” 这两个类是互斥的，在特定模块的特定变体种，不能同时包含两者的混合体。

这就是为什么有些资料说分为4种配置等级/类，就是把Post-build time里面细分的”可加载“和”可选择“两种拿出来说了。

在许多情况下，一个模块的配置参数包含多种不同的配置类。比如：一个模块里面的配置参数可能既有属于Post-build time类型的，同时也有属于Pre-compile time类型的。针对某个具体的参数，其也可以属于多种类型，这在每个文档里面的参数配置章节都有定义。但针对一个变体（Variant）每个配置参数只能分配一个配置类。

2. 变体（Variant）

上面提到的变体（Variant），其定义是：指每个模块的配置参数指定/分配到某个配置类即为一个变体。

由于不同的使用场景需要不同的配置类型。比如网关里面的可配置路由表，通常我们需要Post-build time类型。而针对静态路由表则需要Pre-compile time 类型。按照上面的定义，也就是说这个例子就对应两个变体了。标准提供了3种类型的变体，分别为：

1. VARIANT-PRE-COMPILE
2. VARIANT-LINK-TIME
3. VARIANT-POST-BUILD

从名字上看和配置类是不是一一对应的？但其实他们的关系并不是一一对应的，而是遵循如下关系：

VARIANT-PRE-COMPILE:

• 这个变体只允许包含那些配置类为Pre-compile time的参数。

VARIANT-LINK-TIME:

• 这个变体只允许包含那些配置类为Pre-compile time以及Link time的参数。

VARIANT-POST-BUILD:

• 这个变体允许包含所有类型的配置类参数（Pre-compile time, Link time, Post-build time）。

为了更便于理解，这里用表格从两个方向来描述一下他们的关系。

变体	配置类
VARIANT-PRE-COMPILE	Pre-compile time
VARIANT-LINK-TIME	Pre-compile time, Link time
VARIANT-POST-BUILD	All Classes: Pre-compile time, Link time, Post-build time

配置类	变体
Pre-compile time	ALL VARIANT：VARIANT-PRE-COMPILE, VARIANT-LINK-TIME, VARIANT-POST-BUILD
Link time	VARIANT-LINK-TIME, VARIANT-POST-BUILD
Post-build time	VARIANT-POST-BUILD

上面第一个表中可以看到，虽然一个变体可以包含多个配置类，但如前文提到，在一个变体中，针对某个参数只能分配一个配置类。在一个变体中，不同的配置参数可以是不同的配置类。

如果可能的话，我们尽量将所有变体的配置参数都指定到相同的配置类。

之所以允许变体定义配置类的组合，是为了实现灵活性。下面通过一些示例说明变体的概念（注意，这些只是示例，你可以根据不同变体的含义做不同决定）。

示例1： 为实现最高效率，可能所有参数实现都是预编译(pre-compile time)类型

在该变体中，所有参数都是在预编译时间确定的。 一旦进行了编译（除了通过重新编译），就不可能更改任何参数。 因此，该变体具有最有效的能力，但也具有最小的灵活性。 预编译参数的一个很好的例子是DevelopmentErrorChecking。 这通常是通过预处理器实现的，以启用或禁用模块源特定区域的代码生成。 但是，如果您改变主意，则需要重新编译.

示例2： 通过添加链接时（Link time）类型参数提高灵活性

在该变体中，通过选择一些将在链接时确定的参数来增加灵活性。 因此，通常在此变体中将存在预编译和链接时参数的混合。 与示例1一样，预编译参数是在编译之前设置的，只能通过重新编译来更改。 同样，这里的DevelopmentErrorChecking参数是一个很好的例子。 因此，该模块通常将作为源代码交付。 其他参数可以在链接时设置，而无需重新编译模块。 例如，CAN控制器中的波特率可以在编译后通过将其设为链接时参数来确定。

在一个特定的变体中，参数只能在一个配置类中，一个参数对应多个配置类是不可能的。 但是，参数可以在两个变体之间从一个类更改为另一个类。

3. 配置集（Configuration sets）

在新版协议里面，配置集这个概念本身与配置等级/类无关，它的具体定义在原始文档中我也没有找到。一个变体我们可以称为一个配置集。我们可通过变体点（Variation points）提供单个或多个配置集。如果提供了多个配置集，则实际使用哪个可以在运行时通过绑定不同变体点来实现。这里其实所的就是前面我们提到的“构建后可选择（post build selectable）”。

什么意思呢？ 假如某个模块我们配置为Post-Build配置类并创建了多个变体，每个变体里面的参数可能是针对不同车型（高配，低配）来配置的（这些参数可能需要下线后统一标定）。我们可以根据实际情况来切换这些参数/数据集。通常代码都是以指针方式来实现的。
配置集这个概念在新版本里面开始淡化了，大家了解即可。更多的会提到变体这个概念。

注意： 4.1.x版本以前，多个配置集被建模为Post-build time的子类。