全部学习汇总: https://github.com/GreyZhang/hack_autosar

       继续学习AUTOSAR的文档,看一下《AUTOSAR_TPS_BSWModuleDescriptionTemplate》。

814_AUTOSAR_TPS_BSWModuleDescriptionTemplate10_执行时间2_it技术

       9.5.4.3 对逻辑上下文的依赖

       这个逻辑上下文包括:

       1. 调用 runnable 的输入参数

       2. 也是 runnable 所属组件的逻辑“状态”(或者更准确地说:所有内存的内容 由 runnable 使用)

       虽然输入参数的描述相对直接指定,但可能很难描述软件所依赖的整个逻辑状态。

       此外,在某些情况下,人们希望为非常特定的逻辑上下文提供特定的(例如测量的或模拟的)执行时间; 而在其他情况下,人们想要描述在所有有效逻辑上下文或逻辑上下文子集上的最坏情况执行时间。

814_AUTOSAR_TPS_BSWModuleDescriptionTemplate10_执行时间2_缓存_02

       9.5.4.4 对外部代码的依赖

       当描述了执行时间的代码段调用(“跳入”)外部库时,事情就会变得非常复杂。 为了解决这个问题,我们可以采取以下方法之一:

       1. 完全不支持这种情况:只有不依赖外部库的代码才能被赋予执行时间

       2. 支持对库的非常特定版本(再次在目标代码级别)的执行时间的描述。 使用的外部库的确切版本将与执行时间一起描述。 此外,runnable 和库在内存中的相对位置、相对于库的硬件状态(例如,此代码是否在缓存中)以及库的逻辑状态可能会产生影响。

       3. 从概念上讲,有可能支持对软件的描述,该描述明确描述了对库执行时间的依赖性。 该描述将包括:

       (a) 软件本身提供的代码的执行时间

       (b) 进行哪些外部库调用的规范(使用什么参数、多久一次、以什么顺序……)

       选项 3 被认为不切实际和不切实际,不支持。 然而,选项 2 很重要,因为许多软件可能依赖于非常简单但非常常见的外部库(例如在软件中提供浮点功能的数学库)。 因此,对于外部库没有影响其执行时间的附加逻辑上下文的情况,将支持选项 2。

814_AUTOSAR_TPS_BSWModuleDescriptionTemplate10_执行时间2_执行时间_03

       9.5.5 执行时间的描述模型

       9.5.5.1 执行时间描述的详细结构

       图​​ 9.5 显示了执行时间如何成为实现整体描述的一部分以及它如何与各种其他模型元素相关联。

       执行时间

       对于(特定实现的)每个 ExecutableEntity 可以关联任意数量的 ExecutionTime 描述。 因此,该 ExecutionTime 描述也可能取决于实现的代码或数据变体。

814_AUTOSAR_TPS_BSWModuleDescriptionTemplate10_执行时间2_it技术_04

       预计许多 ExecutableEntity 将没有关联的 ExecutionTime 描述。对于具有 ExecutionTime 描述的 ExecutableEntity-s,软件实现者可以提供多个不同范围的此类描述:例如,每个特定的 ECU 都有一个,实现可以在其上运行并在其上测量或估计时间。 此外,即使在给定的 ECU 上下文中,也可以指定几种不同类型的执行时间,如下所述。

       如果一个 ExecutableEntity 被定义为完全运行在一个 ExclusiveArea 中,那么相关的 ExecutionTime 可以被认为是在 RTE 中配置数据一致性机制的约束。

如果 ExecutableEntity 定义为能够进入 ExclusiveArea,则可以为每个区域指定 ExecutionTime。 提供的时间是调用进入 ExclusiveArea 之后和调用离开 ExclusiveArea 之前消耗的时间。

       图 9.6 显示了 ExecutionTime 的各种子类。 以下段落更详细地描述了该模型的各个方面。 对于类 TimeValue 的定义,请参阅时序规范([12])。

814_AUTOSAR_TPS_BSWModuleDescriptionTemplate10_执行时间2_缓存_05

       图 9.6:ExecutionTime 的子类及其对 TimeValue 的使用

       上面以表格形式显示了 ExecutionTime 的属性。

       几个的基类意味着如何描述软件的执行时间。通过此类提供所需的上下文信息。

814_AUTOSAR_TPS_BSWModuleDescriptionTemplate10_执行时间2_缓存_06

       9.5.5.2 ExecutionTime 引用“ECU”

       ExecutionTime 通过属性 hwElement 引用一个 ECU(概念 ECU 由 ECU-ResourceTemplate [25] 定义)。 此参考唯一地描述了为其提供 ExecutionTime 的硬件。

       它包括:处理器类型、MMU 类型、缓存类型、可用内存类型……

       需要注意,对 HwElement 的引用与实现中的属性处理器具有不同的语义。 处理器定义了所提供的实现可以在其上运行的处理器系列(这是对可以部署组件的硬件的要求)。 另一方面,ECU(处理器只是其中的一部分)是关于 ExecutionTime 上下文的声明。 当然,ECU 的处理器应该等于Implementation 中指定的处理器。注意,ECU 可能包含对 ExecutionTime 没有影响的特定硬件。 尽管如此,最好指定对所使用的整个硬件平台的引用,而不是引入另一个硬件子系统,该子系统包括影响软件执行时间的所有硬件元素。

814_AUTOSAR_TPS_BSWModuleDescriptionTemplate10_执行时间2_执行时间_07

       执行时间之硬件配置

       通过 hwElement 属性描述的 ECU 仍然可以在多种 HW 模式下运行。 例如,许多 ECU 可以在几种“速度”模式下运行(例如正常快速模式和低功率慢速模式)。  HardwareConfiguration 的目标是描述这一点。 属性processorSpeed 和processorMode 应该描述ECU 的特定模式。

       由于对许多其他硬件配置设置(例如缓存策略、MMU 设置等)的潜在依赖性,提供了一个通用属性附加信息。 由于信息的确切结构似乎在很大程度上取决于具体情况,因此所有属性都是非结构化文本。

       描述在需要此资源消耗时硬件在哪种模式下运行。

814_AUTOSAR_TPS_BSWModuleDescriptionTemplate10_执行时间2_autosar_08

       9.5.5.4 执行时间包含一个 MemorySectionLocation

       执行时间之存储选择位置

       对于实现的每个 memorySection,ExecutionTime 必须指定该部分在 ECU 的物理内存中的位置。 软件的memorySections在实现的resourceConsumption中描述。

       硬件上的可用内存区域在 ECU 的描述中进行了描述。 ExecutionTime 包含对内存部分 MemorySectionLocation 位置的描述,这些部分将软件内存部分链接到 ECU 上的硬件内存部分。

       这一部分看了一些执行时间相关的限制信息,以及一些测量的限定分析方式。