全部学习汇总： https:///GreyZhang/hack_autosar
继续学习AUTOSAR，看一下官方的文档。
3 Autosar 顶层结构
AUTOSAR 对所有 AUTOSAR 模板使用通用的顶层结构。 这种方法为设计 AUTOSAR 方法中的工件留下了最大的灵活性。
图 3.1 说明了 AUTOSAR 顶层结构。
AUTOSAR 模型的顶层结构
元类 AUTOSAR 是所有模板的根。 AUTOSAR 包含多个 ARPackage 作为 arPackage。
ARPackage 可以任意嵌套。 这些包包含代表 AUTOSAR 模板的特定自管理实体的 PackageableElements。 这方面最突出的特化是 ARElement（参见第 4.2 章）。
请注意，所有 AUTOSAR 元类都继承自 ARObject（参见第 4.1 章）。
AUTOSAR 顶级 AdminData
顶级结构还包含 AdminData，它指定了 AUTOSAR 工件的两个主要方面：
• 指定为 DocRevision 的更改管理信息
• 文档的语言状态
工件的语言状态
工件的语言状态指定：
1. 在顶级 AdminData 中的属性语言中指定的文档的“主”语言。
2. 文件中的其他语言。 这被指定为 usedLanguages，它是一个 MultiLanguagePlainText，用作文档中使用的语言列表。
有关多语言方法的更多详细信息，请参阅第 8.6 章。 以下示例说明了 ARXML 文件的顶级结构。 该文件以英语和德语维护。 英语是母语。
这是前面提到的示例。
AUTOSAR 描述的根元素，也是相应 XML 文档中的根元素。
标签： xml.globalElement=true
AUTOSAR 工件组织在 ARPackages 中，其中包含所谓的 PackageableElements 元素。 这些是根据其自身的性质定义的，它们彼此独立存在并由关联使用。 例如，计算方法是自行定义的。 它由数据定义通过引用使用。
有关 ARPackage 的更多详细信息，请参阅第 4.2 章。
3.1 识别包中的 M1 元素
包用于组织 AUTOSAR M1 模型。 AUTOSAR Gbr 本身发布 M1 模型作为已发布标准的一部分。 为了清楚地识别此类模型元素，适用以下规则：
AUTOSAR 交付模型的包结构
由 AUTOSAR 标准化并作为 ARXML 交付的模型元素存在于一个顶级包中，其 shortName 是 AUTOSAR。
这意味着由 OEM 或供应商定义的数据元素不应位于名为 AUTOSAR 的顶级包中。
AUTOSAR 交付模型的模式
AUTOSAR 交付模型的包结构遵循上面截图中的模式。
请注意，AUTOSAR 通常会提供蓝图。 有关更多详细信息，请参阅 [TPS_STDT_00067]。
上面给出了一个结构的示例。
在这个例子中，有一个包含实现数据类型和最终作为标准实现的实现数据类型的蓝图的包。
截图给出了另一个示例。
此示例显示了一个提供 STANDARD、BLUEPRINT 和示例的用例。
EUC 参数定义的包结构
请注意，出于兼容性原因，ECUC 包结构在 AUTOSAR 4.0 中保留为上面截图中的格式。
AUTOSAR 定义的模型元素的模式
AUTOSAR 规范已经为其定义了标准化名称（例如平台类型）的模型元素应根据以下模式存在于包路径中。
在这些给定的模式中，以下占位符适用：
{module} 表示模块指示符
模块指示符是以下之一 - 模块、库等（根据 [7] 作为 API 服务前缀（例如 CanIf、Ifx、Compiler） - 由 [6] 中指定的“VirtualModules”集中的分类 ModuleDesignator 的关键字定义的 abbrName ]（例如AISpecification）。
{postfix} 表示特定的实现
当且仅当 BSW 模块的多个实现出现在同一系统中时，才会将后缀添加到包结构中。
{kind} 表示元素的种类
该值是 ARElement 子类的名称，并附加复数-'s'。 使用 UML 标记 atp.recommendedPackage（参见 [TPS_GST_00049]）为每个 ARElement 指定特定的包名称，并在类表中显示（例如，从 BswModuleDescription 派生的 BswModuleDescriptions。
ARPackage的类别
包有一个类别，表明该包中的元素是用于参考目的还是用于处理。 标准化值为 STANDARD、BLUEPRINT、Example。
此类包中的元素充当真实对象的一种“蓝图”。
这尤其适用于诸如 PortInterface 之类的对象，这些对象并未专门建模为“蓝图”，但仍然是 AtpBlueprint 和 AtpBlueprintable 的特化。
例如，创作工具提供这种预定义的 PortInterface 作为一种工具箱，可以从中将定义复制到实际项目中。
此类包中的模型元素可能仅被部分定义。 因此可以应用特定的语义约束。 有关更多详细信息，请参阅 [2] 中的 [TPS_STDT_00002]。
蓝图不支持的蓝图
请注意，特别建模为“蓝图”（例如 PortPrototypeBlueprint）的对象也存在于类别为 BLUEPRINT 的包中。 严格来说，这意味着它们可以是“蓝图”的“蓝图”。 这种间接性不是有意的，也不支持。
由相关顶级包的提交者标准化的元素，可以按原样用于处理（例如 ECU 参数定义）。 请注意，这也允许代表利益相关者特定的标准元素，因为 STANDARD 不限于 AUTOSAR 内部应用程序。
构成实施一致性声明的元素。
ICS 可能不包含蓝图
由于实施一致性声明总是描述一组一个或多个完全配置的软件模块，一个类别为 ICS 的包不允许在任何级别包含类别为 BLUEPRINT 的子包。
ICS不得参考实例
ICS 就像一个生产模型，因此不应参考示例。 由于在 ICS 中需要忽略目标，因此这样的引用将是无用的。
有关实施一致性声明内容的更多详细信息，请参阅 [8]。
例子
Example 包中的元素说明了如何应用 STANDARD 或 BLUEPRINT 包中定义的示例元素。 示例包中的元素应被生成器等忽略。
这部分主要是看了AUTOSAR的顶层架构，讲述了架构以及工具之间的一些映射关系。
