全部学习汇总: https://github.com/GreyZhang/hack_autosar
继续梳理《AUTOSAR_TR_Methodology》。
绑定时间定义
概要
绑定时间不能取字面意思,不是一个精确的时间点,而是处理步骤的分类。 例如,绑定时间 CodeGenerationTime 指的是从 ARXML 格式的 AUTOSAR 模型到代码的转换步骤。
在本节中,我们在方法论中定义工件和任务的绑定时间。
任务绑定时间的定义
如果任务绑定了绑定时间 X 的变化点,则任务具有绑定时间 X。
这尤其意味着:
• 在模型上工作的任何任务都可以绑定具有绑定时间 SystemDesignTime 的变体点。
• 任何生成代码的任务都需要绑定具有绑定时间 CodeGenerationTime 的开放变体点。 那时绑定时间较早的所有变体点都必须已绑定。
• 类似地,任何编译代码的任务都需要绑定具有绑定时间 PreCompileTime的开放变体点。所有具有较早绑定时间的变体点都必须在那时绑定。
此时,还必须绑定变点的 PostBuildVariantConditions 值。 这些值的最新绑定时间为 PreCompileTime6。
在所有这些情况下,显然必须在绑定变化点之前定义变化点条件所需的系统常数。
在 Methodology 库中,任务的绑定时间由标记 Meth.bindingTime 的值指示,这些任务始终可以与此绑定时间相关联。 对于仅可选绑定变体的任务,不指示它。 这通常适用于仅适用于 ARXML 模型的所有任务,例如,像 Extract ECU Topology 这样的任务是否应绑定任何变体取决于具体过程。
后面的章节就是方法论库,这里做了引用说明,我比较好奇这部分应该如何使用。
工件绑定时间的定义
在绑定时间为 X 的工件中,绑定时间为 X 之前的所有变化点都应绑定。
我们没有为 Methodology 库中的工件表示这样的绑定时间,因为它们的绑定时间通常取决于上下文。 但是,此定义可用于将绑定时间分配给工件,作为特定用例的一部分。
在特定任务的上下文中定义工件的绑定时间
如果绑定时间为 X 的工件被用作特定任务的输入或输出,则绑定时间为 X 的与该任务相关的所有变化点都将被绑定。
这特别意味着如果工件被输入到任务中,那么绑定时间变化点 X 将被绑定并且任务依赖于此。
如果工件被输出到任务,则允许这样创建的工件具有绑定时间X绑定的所有变化点。
在 Methodology 库中,这由附加到 Consumes/ConsumedBy 的标记 Meth.bindingTime 的值指示。 Produces/ProducedBy 关系。
请注意,标记 Meth.bindingTime 不适用于 inout 关系,因为根据上述定义的绑定时间值对于特定任务的输入和输出通常是不同的。 如果表达这些绑定时间很重要,则必须将 inout 关系拆分为输入(即 ConsumedBy)和输出(即 Produces)关系。
图 2.64 概述了 AUTOSAR 方法中使用的绑定时间。 此图中的封装元素对应于绑定时间,它们之间的联系表征了工件。
关于绑定时间的工件分类
模型、需求、功能模型这些是指非 AUTOSAR 模型的模型。 例如,模型可以是 Matlab/Simulink 模型或需求文档。
ARXML ARXML 工件是符合 AUTOSAR XML 模式的 XML 文档。
源代码 源代码工件是使用编程语言(例如 C 或 C++)的语法编写的文本。
源代码可能是手工生成的,也可能是代码生成器的输出。
绑定源代码 绑定源代码工件包含没有任何未绑定预编译变体点的源代码。
目标代码 目标代码是编译器的输出。 目标代码通常是机器代码,但也可能包含 XML 等格式的描述性信息。
可执行文件 可执行文件是可以在 ECU 上运行的工件。 它通常类似于目标代码; 两者之间的区别在于前者不提供在 ECU 上执行的手段。
配置数据集 配置数据集是一组对 PostBuildVariantCriterion 的分配。
这一次的小结到此结束了,其实这部分相比第一部分没有太多的可以直接解答我当前疑惑的信息收获。