Autosar知识：方法论-绑定时间的定义

binding time不是（如名称所示）精确的时间点，而是处理步骤的分类。 例如，绑定时间CodeGenerationTime是指从ARXML格式的AUTOSAR模型到代码的转换步骤。

在本节中，我们定义方法中工件和任务的绑定时间。

 

 

任务绑定时间的定义

如果任务绑定了绑定时间X的变化点，则它具有绑定时间X。

这尤其意味着：

•在模型上执行的任何任务都可以绑定具有绑定时间SystemDesignTime的变化点。

•任何生成代码的任务都需要绑定具有绑定时间CodeGenerationTime的开放变体点。 到那时，所有绑定时间更早的变体点都必须已经绑定。

•同样，任何编译代码的任务都需要绑定具有绑定时间PreCompileTime的开放变体点。届时所有绑定时间较早的变体点都必须已绑定。

此时，还必须绑定变化点的PostBuildVariantConditions值。 这些值的最新绑定时间为PreCompileTime。

请注意，在使用RTE代码的情况下，绑定PreCompileTime变体的技术步骤部分由在实际编译之前运行的准备任务完成，请参见生成RTE预先构建数据集。 这尤其意味着必须在执行此准备任务之前定义相关的系统常数。 在这种情况下，实际编译任务“编译ECU源代码”的绑定时间表示为CompileTime。

变化点仍然是PostBuild：PostBuildVariantCondition固定在PreCompileTime，但是与关联的PostBuildVariantCriterion的比较发生在PostBuildVariantCriterion。 有关详细信息，请参见通用结构模板。

工件绑定时间的定义

在绑定时间为X的工件中，所有绑定时间X之前的变化点都应绑定。

我们在方法论库中没有为工件指定这样的绑定时间，因为它们的绑定时间通常取决于上下文。但是，作为特定用例的一部分，可以使用此定义为工件分配绑定时间。

特定任务上下文中工件的绑定时间的定义

如果将绑定时间X的工件用作特定任务的输入或输出，则与该任务相关且绑定时间最多为X的所有变化点都将被绑定。

这尤其意味着，如果将工件输入到任务中，则绑定时间变化点X将被绑定，并且任务依赖于此。

如果将工件输出到任务，则可以认为这样创建的工件具有绑定时间X bound的所有变化点。

在方法库中，这由附加到 Consumes / ConsumedBy 的标签Meth.bindingTime的值指示 resp.Produces / ProducedBy 关系。

请注意，标记Meth.bindingTime不适用于inout关系，因为根据上述定义的绑定时间值通常对于特定任务的输入和输出是不同的。如果表达这些绑定时间很重要，则必须将inout关系分为输入（即ConsumedBy）和输出（即产生）关系。

下图概述了AUTOSAR方法中使用的绑定时间。此图中的带框元素对应于绑定时间，并且它们之间的连接表征了工件。

不同绑定时间和其工件流向

 

关于结合时间的伪像分类

模型，需求，功能模型：这些是指不是AUTOSAR模型的模型。例如，模型可以是Matlab / Simulink模型或需求文档。

ARXML：ARXML工件是符合AUTOSAR XML模式的XML文档。

源代码：源代码工件是使用诸如C或C ++之类的编程语言的语法编写的文本。源代码可以手工生成，也可以是代码生成器的输出。

绑定源代码：绑定源代码工件包含没有任何未绑定预编译变化点的源代码。

目标代码：目标代码是编译器的输出。目标代码通常是机器代码，但也可以包括诸如XML格式的描述性信息。

可执行文件：可执行文件是可以在ECU上运行的工件。它通常类似于目标代码。两者之间的区别在于，前者不提供在ECU上执行的手段。

配置数据集：配置数据集是PostBuildVariantCriterion的一组分配。

绑定时间分类

下表概述了AUTOSAR变体处理中的绑定时间

元模型和方法学中的绑定时间

 

AUTOSAR元模型中的变体处理支持以下绑定时间：

• BlueprintDerivationTime

• SystemDesignTime

• CodeGenerationTime

• PreCompileTime

• LinkTime

• PostBuild
 

元模型中变化点的最新绑定时间的定义

所有这些绑定时间都可以在标记“ Vh.latestBindingTime”中使用，该标记用于定义元模型中变化点的最新绑定时间。

变异点的实际绑定时间存储在VariationPoint的ConditionByFormula的属性bindingTime中，并且只能使用值SystemDesignTime，CodeGenerationTime，PreCompileTime，LinkTime。

AUTOSAR方法利用了另外两个绑定时间：InitialBindingTimes来表征没有绑定任何变化点的工件，而CompileTime则用来区分代码的预处理和编译。最后，FunctionDesignTime和Runtime不在AUTOSAR变量处理的范围内，但出于完整性目的在此处提及。

BlueprintDerivationTime

在BlueprintDerivationTime，模型是从Blueprints派生的。 例如，功能设计工具提供了从一组预定义的蓝图中派生对象的选项。 。 这与本章中定义的变体处理有所不同，但是使用了相同的元模型功能。

BlueprintDerivationTime不在本文档的讨论范围之内，但此处出于完整性考虑而提及。

输入工件：模型，需求

输出工件：ARXML

FunctionDesignTime

在FunctionDesignTime上，开发了用于（控制）系统的软件体系结构独立模型。 此阶段使用的典型工具是Matlab / Simulink或ASCETMD。

如果功能设计工具支持根据AUTOSAR进行变体处理，则除了在生成的AUTOSAR工件中使用CodeGenerationTime或更高版本作为绑定时间外，别无选择。

FunctionDesignTime不在本文档的范围之内（只要它不影响校准测量），但是此处出于完整性目的而提及。

输入工件：模型，需求

输出工件：功能模型

InitialBindingTime

在InitialBindingTime上，没有绑定任何变化点。 需要这种绑定时间来表示在人工输入工件中没有绑定SystemDesignTime点的状态：模型，需求，功能模型，ARXML格式蓝图中的AUTOSAR模型。

输出工件：ARXML。

BlueprintDerivationTime

SystemDesignTime的特征在于以下任务：

•设计VFB

•软件组件类型（接口）

•SWC原型以及SWC原型之间的连接

•设计拓扑

•ECU和互连网络

•设计通信矩阵和数据映射

输入工件：ARXML格式的蓝图中的功能模型，需求，AUTOSAR模型。

输出工件：ARXML。

CodeGenerationTime

在此步骤中，将生成代码。 这可以通过手工或使用工具或两者的混合来完成。

手写代码通常基于需求文档，而生成的代码通常是根据在FunctionDesignTime或SystemDesignTime设计的模型创建的。
需求和模型都可能包含变体，但是仅为已选择的变体或稍后需要解决的变体生成代码。

输入工件：ARXML。

输出工件：源代码。

PreCompileTime

在PreCompileTime时，预处理器（例如C预处理器）用于进一步自定义代码，并从编译过程中排除部分代码。

进行这种排除的原因有很多：选定的变体不需要代码，与选定的变体不兼容的代码，或者代码需要选定的变体中不存在的资源。在此阶段代码中排除的代码在以后的阶段将不可用。

PreCompileTime通常用于手写代码（对于SystemDesignTime和CodeGenerationTime显然不会生效），或者在代码生成后需要绑定系统常量时，使用PreCompileTime。

输入工件：源代码。

输出工件：绑定源代码。

CompileTime

在CompileTime上，已经由宏处理器（例如C预处理器）处理并去除了所有PreCompileTime变化点的源代码将转换为目标代码。编译器可能会通过删除未使用的代码路径来消除其他变体。

在AUTOSAR元模型中不使用CompileTime，而在AUTOSAR方法中使用CompileTime来区分预处理器和编译器。

输入工件：绑定源代码。

输出工件：目标代码。

LinkTime

在此阶段的配置将根据结果选择确定哪些模块包含在结果目标代码中（可执行），哪些模块被忽略。

输入工件：目标代码。

输出工件：可执行程序。

PostBuild

PostBuild是绑定时间，绑定时间最晚在ECU启动时绑定。 换句话说，这就是创建可执行程序和启动ECU之间的一切。

ECU的启动是PostBuild绑定，因为显然不能在模型中解决。

输入工件：可执行程序，配置数据集。

输出工件：–

Runtime

启动和初始化之后的所有内容都是RunTime。 运行时的变体处理不在本文档的讨论范围之内，但此处出于完整性目的而提及。