继续梳理《AUTOSAR_TR_Methodology》。
概览
变体处理中的变体点
AUTOSAR 的变体处理在通用结构模板模板中定义。 首先，这个概念定义了将 AUTOSAR 元模型中的某些位置指定为变体点的方法。 一个点粗略地由一个条件（在什么条件下这个变体是活跃的？）和一个绑定时间（这个变体应该在什么时候被解决？）组成。
第二，有预定义的变体。
变体处理中的预定义变体
典型的 AUTOSAR 模型可能包含大量变体点。 然而，通常只有相对少量的变体（即“活动”变体点的组合）被积极使用。每个预定义的变体都描述了这样一个变体。
绑定时间
绑定时间类型
AUTOSAR 变体处理为 AUTOSAR 定义了两种绑定时间：最新绑定时间和实际绑定时间。 它们具有相同类型的值3，但用于不同的上下文。
接下来的接种绑定时间前面熟悉过了，但是多出来了3个，分别是蓝图派生阶段、系统设计阶段、代码生成阶段。而这部分，其实在接下来的这段中有相关的描述。
通用结构模板提到了另外两个绑定时间。 首先是 FunctionDesignTime，它出现在 SystemDesignTime 之前，但独立于 BluePrintDerivationTime。 其次是运行时，它出现在 PostBuild 之后。 这些绑定时间不包含在 AUTOSAR 中，此处提及只是为了完整性。
绑定时间的定义
还应该注意的是，绑定“时间”并不是真正的时间点，而是表示 AUTOSAR 系统开发的一个阶段。
最新的绑定时间
在 AUTOSAR 元模型中，每个变体点都有一个最新的绑定时间，由标签 Vh.LatestBindingTime 实现。 顾名思义，特定变体的最新绑定时间对该点可以绑定的时间设置了上限。 一个变体可能比这个时间更早绑定，但不能更晚。
例如，作为组合一部分的软件组件的最新绑定时间是 PostBuild。 换句话说，ECU 可以配置为在启动时决定软件组件是否处于活动状态。
但是，并非总是可以在最晚的时间绑定变体。 继续上面的例子，使所有软件组件 PostBuild 意味着一个可执行文件总是包含所有软件组件的代码和其他资源，无论它是否被激活。 因此，可执行文件可能会变得太大而无法放入其指定的 ECU。 如果是这种情况，则需要更早地绑定软件组件，通常是在 PreCompileTime 甚至 SystemDesignTime。
这不是导致此决定的唯一情况。 例如，一个软件组件可能包含两个或多个子组件，每个子组件都特定于某个供应商。 在这种情况下，在将软件组件交付给特定供应商之前，通常会删除针对其他供应商的子组件。 这显然可以在最晚的 PrecompileTime 完成。
在某些情况下，变体点的绑定时间存在隐式（即未说明元模型）下限的情况。 例如，如果软件组件 A 中的变体使用软件组件 B 中的变体，则需要协调绑定时间。 如果组件 B 是 PostBuild，则组件 A 不能是 SystemDesignTime，但使用软件组件 A。
关于是否要把变体存留在最终软件中，的确是有一点新的收获。
实际的绑定时间
这将我们带到了变体点的实际绑定时间，它存储在变体点的属性4中。 同样，在此阶段不一定要严格绑定变体点； 而是声明在以后的阶段不能绑定变体点。该绑定时间可能早于最新的绑定时间。
如上一节所述，可以在 PostBuild 绑定软件组件的组合，但这样做并不总是可取的，甚至不可行。 在这种情况下。 bindingTime 应该说明更早的绑定时间。
此外，与作为元模型元素并在 M2 级别上声明的最新绑定时间不同，此绑定时间是与变体点相关联的模型元素并在 M1 级别上声明。
也就是说，变体点的绑定时间限制了特定变体点必须被绑定的点，但是这个绑定时间再次受到最新绑定时间的限制。
变体定义
一个变体几乎总是不止一个变体点或一个系统常数。 通常，变体是系统常量或构建后变体条件的值分配列表。 在 AUTOSAR 模型中，这样的列表由元类 PredefinedVariant 的实例表示，请参阅工件预定义变体的定义。
评估变体集
类似地，元类 EvaluatedVariantSet 的实例是一组 PredefinedVariants，这些变量已知对元模型的某个元素（例如特定的软件组件）起作用（或不起作用）。 评估的变体可用于在不同供应商之间交换关于已知变体的信息，例如记录软件组件的哪些变体已经过测试并且已知可以工作。
在 Methodology SPEM 模型中，变体选择器由 Evaluate Variant Set 工件表示，该工件由 Evaluate Variant 任务创建。
此信息是必要的，因为可能的变体数量非常多，但其中只有很小的一个子集是可行的。
预定义变体的使用
包含在 PredefinedVariant 实例中的一组系统常量通常会影响许多变体点，这些变体点位于模型中的不同位置，具有不同的绑定时间。
因此，预定义的变体不能直接与元模型中的特定位置或某个绑定时间相关联。 相反，一个 PredefinedVariant 用于多个元模型元素并在不同的绑定时间。
选择变体
一个系统中是否包含一个变体点是由一个或多个变量决定的。 如果变体点的绑定时间在 SystemDesignTime 到 LinkTime 之间的任何位置，则变体点包含基于系统常量的表达式（请参阅工件系统常量值集）。 如果此表达式的计算结果为真，则系统中包含该变体点。 PostBuild 使用简化的方案，只允许与 PostBuildVariantCriterion（技术上，ARElement）进行一次比较。
选择变体
因此，一旦确定了相应系统常数或构建后变体条件的值，就会选择变体。 这通常通过选择包含相应值的 PredefinedVariant 来完成。 这种选择显然必须在绑定变体点之前发生。 但是，它不需要在绑定变体点之前立即发生。
例如，确定 PreCompileTime 变体点的系统常量可能已经在 SystemDesignTime 中选择，但实际绑定必须延迟到 PreCompileTime，因为依赖于具有绑定时间 PreCompileTime 的另一个软件组件，如第 2.15 节所述 .2.2.
此外，由于 PredefinedVariant 跨越多个变体点，这些变体点可能具有不同的绑定时间，因此有些可能在选择 PredefinedVariant 后立即具有绑定时间（最新的甚至实际的），而其他的可能具有更晚的绑定时间。
最后，选择特定变体的决定通常与遵循其自身时间表的供应商特定流程相关。
因此，选择特定变体的时间通常与绑定相关变体点的时间不同。 总之，必须在绑定之前的某个时间选择一个变体，但是发生这种情况的实际时间不是由 AUTOSAR 确定的，并且也非常特定于供应商。
本次梳理暂且到此为止吧，看起来，这个章节的内容还是很多。我觉得，看到这里，多少还是有一些改变我自己先前观念的。在此之前，其实我一直更加倾向于大而全的设计，一切全都要配置到最终的控制器中。现在看来，这个理念的确是不合适，尤其是涉及到资源使用优化的时候，一定不适合做一个大而全的方式了。
