822_AUTOSAR_TPS_BSWModuleDescriptionTemplate18_一致性表达以及测试

       全部学习汇总： GitHub - GreyZhang/hack_autosar: learning autosar documents, aha, very hard!

       继续学习AUTOSR的文档，看一下《AUTOSAR_TPS_BSWModuleDescriptionTemplate》。

       12 实现一致性声明

       12.1 背景

       本章描述了必须使用 BSWMDT 的哪些元素来指定用于 AUTOSAR 一致性测试的 BSW 模块的交付。 有关一致性测试的背景，请参阅 [27]。

       本章假设的用例如下：

       • 测试是针对ICC3 模块完成的。

       • 要测试的代码作为完全配置的目标代码交付。请注意，这可能是多个文件，例如核心代码+单独编译的配置数据。

       • 测试仪无法更改配置。 这意味着，如果 AUTOSAR 为几组不同的配置值指定了测试，则必须交付相应的目标代码文件集。

       • 除了目标代码之外，还根据需要提供头文件和 ARXML 描述，以声明符合性和设置测试。

       特别是，BSWMD（以及附加的配置参数定义和配置值）应包含实现一致性声明（ICS）。  ICS 的目的是声明模块涵盖相关 AUTOSAR 规范的程度。 有关 ICS 的总体定义，另请参见 [5]。

       构成实现一致性声明的 ARXML 模型元素应在具有类别 ICS 的 ARPackage 下聚合。 不需要（但可能）此包下的子包也具有类别 ICS，但它们可能没有类别 BLUEPRINT。 有关包类别的正式约束，请参阅 [1]。

       需要注意，在当前的 AUTOSAR 版本中，ICC3 模块的标准化规范元素（即 SWS 的内容）由 AUTOASAR 发布，而不是以 ARXML 格式，而是以 pdf-Document 格式发布。 因此，如何在给定的 BSWMD 和相应的 SWS 之间进行跟踪的机制目前还没有标准化。

       接口级 ICS 的相关元素

       在 BSWMDT 的接口级别，以下元素与一致性测试相关：

       • BswModuleDescription.moduleId 这标识了 ICC3 模块及其规范。

       • BswModuleDescription.providedEntry BswModuleDescription.outgoingCallback 这些元素需要描述标准化提供的函数的名称和签名。 实际存在于测试代码中的传出回调（必需的和可选的）。 不应包括供应商特定的功能/回调。

       注意：如果回调的名称是可配置的，则还必须交付相应的配置值。

       • BswModuleDescription.bswModuleDependency.targetModuleId BswModuleDescription.bswModuleDependency.requiredEntry BswModuleDescription.bswModuleDependency.expectedCallback 这些元素是必需的，因为它们描述了对其他标准化ICC3 模块（由targetModuleId 标识）的标准化元素的依赖性。

       注意：标准化函数的一致性测试用例必须是可执行的，不依赖于非标准化函数/模块。 因此，测试设置必须只知道模块对其他标准化元素的依赖关系。

       • BswModuleEntry.shortName

        BswModuleEntry。- 这个元类的所有属性

        BswModuleEntry.argument.swDataDefProps        BswModuleEntry.returnType.swDataDefProps

       这里，BswModuleEntry 代表函数声明引用的函数签名的根元素。例如 providedEntry - 上面列出。ICS 不需要 SwDataDefProps 下面的主要数量的聚合或引用元素。只需要 SwDataDefProps 的那些部分，它们唯一地指定参数的 C 数据类型和 returnType。例如，如何用这种方式描述 C 数据类型，请参考 [6] 的“实现数据类型”一章。

       BSWMDT 接口级别上的其余元素与一致性测试无关。 为了完整起见，它们在此处列出：   • BswModuleDescription.providedModeGroup

       BswModuleDescription.requiredModeGroup

       BswModuleDescription.releasedTrigger

       BswModuleDescription.requiredTrigger

       这些元素用于支持模式切换或触发到 BSW 调度程序的委派。 这些机制目前没有被任何标准化的 ICC3 规范提及； 它们主要针对复杂的驱动程序或IO 硬件抽象。 因此，目前不需要在 ICS 中使用这些元素。

       12.3 内部行为层面

       在内部行为层面上没有与 ICS 相关的元素

       在 BSWMDT 的内部行为级别上，没有与一致性测试相关的元素。如以下概述所示：

       • BswInternalBehavior.entity

       BswInternalBehavior.event

       BswInternalBehavior.triggeringPoint BswInternalBehavior.bswTriggerDirectImplementation        BswInternalBehavior.modeSenderPolicy

       这些元素的主要用例是为配置基础软件调度程序（RTE 的一部分）提供输入。 此外，它们还提供用于计时或调用链分析的信息。 这些元素既与 ICS 无关，也与一致性测试无关，因为一致性测试不需要此信息来调用单个 C 函数。

       • BswInternalBehavior.constantMemory

        BswInternalBehavior.staticMemory

       这些元素用于声明模块本地的数据，主要用例是测量和校准以及设置NVRAM 管理器配置所需的数据。不需要为一致性测试声明它们。

       • BswInternalBehavior.serviceDependency

       此元素（以及由它聚合的其他元素）用于声明对其他标准化服务模块（如 NVRAM 管理器或 DEM）的配置的要求。 它不被认为与一致性测试相关，因为一致性测试环境不必如此详细地模拟这些服务模块的行为，即需要根据 ServiceNeeds 进行配置（参见第 6.12 章）。

       12.4 实施层面

       ICS 实施层面的相关要素

       在 BSWMDT 的实施级别，有几个元素与一致性测试相关。 虽然严格意义上不是 ICS 的一部分，但出于管理原因和设置测试环境需要它们。 以下要素与 BSWMDT 的实施级别相关：

       • BswImplementation.programmingLanguage

        BswImplementation.swVersion

        BswImplementation.arRelaseVersion

        BswImplementation.vendorId

        BswImplementation.vendorApiInfix

        BswImplementation.codeDescriptor

        BswImplementation.compiler

        BswImplementation.linker

       定义多个编程语言的名称标识符，扩展附加的API 代码版本信息，扩展API 的多个实例文件的名称信息到交付、编译器和链接器设置。 有关详细信息，请参阅第 7 章和第 8 章。

       • BswImplementation.hwElement

       如果有硬件相关性的正式描述，特别是对于 MCAL 模块，则可以添加该元素。 但是，这些信息的细节和数量并没有标准化。

       BSWMDT 实施级别的其余元素与一致性测试无关。 为了完整起见，它们在此处列出：

       • BswImplementation.usedCodeGenerator

        BswImplementation.requiredArtifact

        BswImplementation.requiredGeneratorTool

        BswImplementation.generatedArtifact

       由于只提供目标代码，因此不需要有关代码生成的信息。

       此外，就测试用例而言，除了对其他 ICC3 模块之外，不应有对其他工件的依赖关系，但后者已经通过接口级别的 bswModuleDependency 进行了定义。

       • BswImplementation.resourceConsumption

        BswImplementation.mcSupport

        BswImplementation.debugInfo

        有关资源消耗、测量、校准和调试数据的信息与一致性测试无关。

       • BswImplementation.swcBswMapping

     这与测试“裸”ICC3 模块的一致性无关。BSW 模块顶部的端口的附加规范不会更改其代码。它们与生成 RTE 相关，但与设置测试环境无关。

       12.5 配置和变体

       ICS 中的配置

       配置参数和配置值也构成 ICS 的一部分。 它们应按如下方式附加到 BSWMD：

       • BswImplementation.vendorSpecificModuleDef

       需要这样做有两个原因：

       1. 必须可以在不了解非标准化供应商特定配置参数的情况下运行 ICC3 测试用例。 但是，受支持的标准化参数定义的副本也是 vendorSpecificModuleDef 的一部分（像往常一样）并且在此处需要，因为 preconfiguredConfiguration 引用它们。

       2. 静态测试中必须包含从标准化参数“衍生”的供应商特定参数定义（即它们是否根据标准衍生）。 参数还应声明模块的给定版本支持的值范围 - 即使实际上只有一些值是预先配置和测试的（见下文）。

       但是，不需要包括全新的供应商特定参数定义（标准化配置参数中没有“起源”），因为在这种情况下，没有任何内容需要进行一致性测试。

       • BswImplementation.preconfiguredConfiguration

       由于每个交付的实现都是一个完全配置的目标代码，对于每个这样的实现，必须附加一组完整的预配置值（即上述 vendorSpecificModuleDef 中给出的所有参数的值）。 当然，如果要测试多个配置集，将有多个这样的预配置配置（以及类似的多个 BswImplementations 和目标文件），但只有一个 vendorSpecificModuleDef（属于该模块的版本）。

       ICS 中没有变体

       描述实际产品的 BSWMD 可以包含变化点（参见第 11 章）。 但是由于一致性测试人员获得了完全配置的目标代码，这也意味着 BSWMD 的 ICS 版本必须没有任何变化点，因为测试人员无法解决这些变化。

       如果要测试此类模块的多个变体的一致性，则对于每个变体，必须将 BSWMD（代表 ICS）和目标代码的单独摘录交付给测试人员。

       这部分主要是讲解了一致性表达的实施以及各种测试的手段，根据不同情况对于可测试性给出了一定的分析。这样的理念其实是很有推广价值的，针对完美产品的开发应该有这样的过程。当然，现在市场经济浪潮的冲撞下，或许很多团队必须得过且过因此这部分无法做到较为完美的程度。这样，不仅仅是这个章节，这一份文件一起看完了。信息琐碎而且繁杂，看起来的确是有一定的挑战度。