作者：Stephen Du
免责声明： 本文为个人学习笔记及总结，仅代表个人观点，尽可能保证内容准确性。复制/转发请注明来源/作者。
欢迎添加微信交流学习。
文章目录
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种类型的变体，分别为：
- VARIANT-PRE-COMPILE
- VARIANT-LINK-TIME
- 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）
在新版协议里面，配置集这个概念本身与配置等级/类无关，但其使用与配置类里面的Post-build time有关。我们可通过变体点（Variation points）提供单个或多个配置集。如果提供了多个配置集，则实际使用哪个可以在运行时通过绑定不同变体点来实现。这里其实所的就是前面我们提到的 “构建后可选择(post build selectable)”。
什么意思呢？ 我们都知道，配置工具里面很多配置界面下都可以新建多个实体，也就是我们通过建立多个实体，每个实体里面的参数可能是针对车的不同运行工况（夏天，冬天）来配置的（这些参数可能需要下线后统一标定）。程序会根据当前工况自动切换这些参数/数据集。比如最常见的，在MCU模块中，我们针对正常运行时和进入随眠后的时钟配置肯定是不一样的，通常我们会创建两个实体，然后会生成相应的结构体配置数据，在使用的时候根据系统状态调用不用的实体来实现不同的功能。通常都是以指针方式来实现的。
注意： 4.1.x版本以前，多个配置集被建模为Post-build time的子类。