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

       继续学习AUTOSAR，这次开始一个新的文档，多达900页，可能需要啃很久。

       1 简介

       1.1 概述

       本文档包含AUTOSAR 软件组件模板的规范。 实际上，它是通过 AUTOSAR 元模型作为对软件组件模板正式定义的补充而创建的。 换句话说，除了正式规范之外，本文档还为与软件组件定义相关的 AUTOSAR 元模型部分提供了介绍性描述和基本原理。

       在这种情况下，术语软件组件是指需要 AUTOSAR RTE [2] 才能执行的正式描述的现有软件。

       请注意，应用软件组件语义背后的一般思想已在虚拟功能总线 [3] 的规范中进行了描述。 然而，后者代表了强烈影响但不完全控制软件组件的正式定义的概念性工作。

       进一步注意，本文档不提供任何软件组件建模的“最佳实践”建议，也不要求或强制执行某种方法。 但是请注意，方法方面包含在 AUTOSAR 方法 [4] 的规范中。

       尽管使用合适的 AUTOSAR 创作工具来处理 AUTOSAR 软件组件毫无疑问是合理的，但本规范不做任何假设，也不提供有关工具的建议。 有关 AUTOSAR 创作工具应该工作和交互的更多详细信息，请参阅 [5]。

       1.2 范围

       正如在第 1.1 章中已经提到的，本文档的范围是对 AUTOSAR 软件组件的描述。 这项工作包括以下三个方面：

       • 使用 PortPrototypes 和 PortInterfaces 对 SwComponentTypes 的一般描述，即本文档将 SwComponentType 定义为一个实体，可以通过提供或需要 PortInterfaces 的 PortPrototypes 进行描述。

       • CompositionSwComponentTypes 的描述，它是由软件组件的连接实例组成的子系统，即软件组件可以以分层子系统的形式定义，而分层子系统又由软件组件组成。 此类分层结构的描述在本文档的范围内。

       • AtomicSwComponentType 的描述，它作为可以映射到AUTOSAR ECU 的软件实现。

因此，AtomicSwComponentType 出现在图 1.1 所示的 ECU 软件架构中。 在此图中，绿色（垂直条纹）和蓝色（对角条纹）边框显示了软件组件模板所描述的方面。

       与 RTE 无关的 AUTOSAR 基础软件方面超出了范围； 这些都包含在基本软件模块描述模板 [7] 中。

       此外，该文档不涵盖与 AUTOSAR 软件组件执行相关的时序分析方面。 这个问题在时序扩展规范 [8] 以及相应的需求规范 [9] 中进行了解释。

       1.3 元模型的组织

       图 1.2 描绘了元模型的整体结构，它正式定义了描述 AUTOSAR 软件组件所需的词汇表。 如图所示，其他模板规范（例如 ECU 资源模板 [10] 和系统模板 [11]）也使用相同的建模方法来定义 AUTOSAR 软件描述的整体一致模型。

       图中的虚线箭头根据元模型内的包之间的导入关系描述了依赖关系。 例如，包 SWComponentTemplate 导入在包 GenericStructure [12] 和 ECUResourceTemplate [10] 中定义的元类。

       请注意，本规范文档将（有一些明确定义的例外）主要讨论在包 SWComponentTemplate 中定义的元模型元素。

       为了澄清起见，请注意包 GenericStructure 包含一些基本的基础设施元类和 [12] 中描述的常见模式。 由于所有其他模板规范都使用这些，因此为了清楚起见，图中没有描述依赖关系。

       1.4 模板结构

       AUTOSAR 软件组件在三个不同的层次上进行描述，如图 1.3 所示。

       1.4.1 VFB 级别的软件组件描述

       最高（最抽象）的描述级别是虚拟功能总线 [3]。在本文档中，SwComponentType 是通过数据类型、端口接口、端口原型以及它们之间的连接来描述的。 在这个层次上，表达了组件的基本通信属性以及它们之间的通信关系。

       在图 1.3 所描绘的图表中，这个方面是通过 AtomicSwComponentType1 的描述来表达的。

       1.4.2 RTE 层的软件组件描述

       中间层允许对给定的 AtomicSwComponentType 进行行为描述。 这种所谓的 SwcInternalBehavior 是根据 AUTOSAR RTE 概念表达的，例如 RTEEvents 和在可调度单元方面，所谓的 RunnableEntitys。

       例如，对于在 VFB 上特定 ClientServerInterface 的范围内定义的 ClientServerOperation，行为指定哪个 RunnableEntity 作为调用特定 ClientServerOperation 的结果而被激活。

       如图 1.3 所示，可能有零个或一个 SwcInternalBehaviors 由给定的 AtomicSwComponentType 聚合。 为了响应聚合中存在构造型 atpSplitable，可以将聚合分布在多个物理文件上。

       1.4.3 实现级别的软件组件描述

       最低级别的描述指定给定SwcInternalBehavior描述的实现（即根据 AUTOSAR 元模型：SwcImplementation）。 更准确地说，这种行为的 RunnableEntity 被映射到代码（源代码或目标代码）。

       可能有不同的 SwcImplementations 引用特定的 SwcInternalBehavior 描述，例如使用不同的编程语言，或使用不同的优化代码。

       请注意，实现已在本文档的先前版本中进行了描述。 为了响应 AUTOSAR 概念的演变，实现方面的描述已移至“CommonStructure”（见图 1.2），因为它也用于创建基本软件模块描述模板 [7]。

       然而，SwcImplementation 仍然在本文档的范围内，因为它只涵盖软件组件的各个方面，而不是基本的软件模块。

       术语表部分直接跳过了，大概都是看过的。文档格式约定以及需求跟踪矩阵也不看了，这样第一个章节简介部分就看完了。虽然，比较有技术指点性的信息不多，但是看起来整个文档的组织还是很宏大的。