(ver: 19-11)AUTOSAR_TPS_ManifestSpecification(第2章：Big Picture of Manifest Definition)

前言

进来在学习Adaptive AUTOSAR，由于 本人英语水平很一般，所以在阅读AUTOSAR官方文档的时候尤为吃力，而且我发现一个问题，这个官方文档可能需要经常翻阅的， 但是因为英语水平有限的缘故，可能每次都得重新使用翻译工具翻译一下，显得有些麻烦， 于是，本人就想着，看一点就翻译一点，下载再要来翻阅的时候，就可以直接阅读中文版，方便不少，顺便也在博客里面做一个记录，一作备忘。

AUTOSAR_TPS_ManifestSpecification的pdf文档有800多页，没法短时间弄完，所以可能也不会按顺序记录。

笔者看的AUTOSAR Adaptive Platform版本是： 19-11

2. Big Picture of Manifest Definition

2.1 Design vs. Deployment

2.1.1 Overview

尽管有这个名称，这个文档仍然包含了模型元素的描述，这些元素清楚地绑定到一个设计工作流，并且模型元素与部署方面有很强的关系。

本文档中讨论的模型元素与设计或部署有关，两组之间没有重叠。

与部署相关的模型元素将用于上传到目标平台的模型中，请参见[TPS_MANI_01000]。这些模型元素主要在本文档的章节中描述，其中术语“Manifest”是章节标题的一部分。

在没有更精确的定义的情况下，可以通过与部署无关来标识与设计相关的模型元素。

2.1.2 Relation between Design and Deployment Models

请注意，在许多情况下，与部署相关的元模型部分会在设计领域反映出类似的建模，例如：E2E配置文件参数的定义。

对于设计和部署之间的关系如何影响具体的开发项目，目前还没有明确定义的属性，E2E属性示例在以下场景中可能发生：

• OEM提供AdaptivePlatformServiceInstances的描述，包括E2E属性的定义。可以肯定的是，模型的后续处理应将E2E属性视为已授予，并针对给定属性开发软件
• 存在通过ComSpecs定义E2E属性的软件。由于各种原因，可能会发生软件无法更新的情况，因此在E2E属性定义方面处于“领先”地位。然后，AdaptivePlatformServiceInstances的定义可能必须遵守软件方面的现有建模。
• 也可能发生现有定义被工程师部分修改的情况，前提是，工程师真正知道那些定义是干什么用的。

2.1.3 Structure of the document

本文档的结构根据设计和部署的映射来划分，例如，章节：3, 4.1, 5, 12.1 and 6.2 主要讲述设计方面的内容，章节：7, 8, 9, 10, 12.2, 13.2 and 13.3 主要是讲述部署方面的内容。

2.2 About Manifest

本章将阐明术语“Manifest ”在AUTOSAR自适应平台中的定义。

[TPS_MANI_01000]{DRAFT} 术语“Manifest ”的定义: Manifest表示AUTOSAR模型描述的一部分，它被创建出来用于支持AUTOSAR自适应平台产品的配置功能，并上载到AUTOSAR自适应平台的产品中，可能与包含Manifest应用的可执行代码的其他工件（如二进制文件）结合使用(RS_-MANI_00015)

必须强调的是，Manifest 的使用确实严格限制在AUTOSAR自适应平台上，并且没有将该概念移植到AUTOSAR经典平台的用例。

2.3 Serialization Format

Manifest 定义与其他AUTOSAR模型内容的一个共同点是标准化序列化格式。

[TPS_MANI_01020] {DRAFT } AUTOSAR中Manifest的序列化格式：AUTOSAR中Manifest内容的标准化序列化格式是ARXML。因此，可以根据AUTOSAR XML模式验证Manifest模型内容。(RS_MANI_00015)

[TPS_MANI_01020]的一个重要结论是：这里没有只允许存在一个”Manifest文件“(即唯一Manifest)的限制。根据AUTOSAR通用结构模板规范[6]中给出的规则，Manifest内容可以分布在多个物理文件中。

[TPS_MANI_01021]{DRAFT}具体硬件机器上Manifest内容的序列化格式：平台供应商可以自由选择用于在计算机上实际上载Manifest的序列化格式，但是，原始ARXML清单的内容和语义需要完全保留(RS_MANI_00015)

可以预料，在许多情况下，Manifest序列化格式的最佳选择仍然是ARXML，因为自定义格式显然必须支持清单元模型的全部复杂性。

请注意，元模型预见到存在从清单相关的元类到设计相关的元类的引用。创建这些引用是为了清晰起见，但并不强制要求引用的内容实际上需要可解析。

就AUTOSAR建模方法而言，这转化为使用原型<<atpUriDef>>装饰这些引用。更多信息见[6]。

如果引用的元类包含与Manifest级别相关的信息，则此信息将在Manifest级别上复制（这样，Manifest级别的模型就不必依赖于设计级别信息的可用性）。

2.4 Scope

如前所述，Manifest的使用仅限于AUTOSAR自适应平台。但是，这并不意味着在一个以AUTOSAR自适应平台为目标的开发项目中生成的所有ARXML都会自动地被视为Manifest。

事实上，AUTOSAR自适应平台通常并不专用于车载项目。

一辆典型的汽车很可能还配备了许多在AUTOSAR classic平台上开发的电子控制单元(ECU)，因此，整个汽车的系统设计必须包括在AUTOSAR classic平台上构建的电子控制单元(ECU)和在AUTOSAR adaptive平台上创建的电子控制单元(ECU)。

[TPS_MANI_01019]{DRAFTg}Manifest内容可能适用于AUTOSAR自适应平台的不同方面：Manifest内容可以应用于模型的不同方面。目前，Manifest内容大致可以分为三个重点领域：

• 与应用程序相关的Manifest内容描述了应用程序部署的所有方面，包括但不限于应用程序级别上的启动配置和面向服务的通信端点的配置。
• 与机器相关的清单内容仅描述了机器的部署，即，机器上没有运行任何应用程序（包括平台模块）。
• 与服务实例相关的清单描述了在传输层级别上面向服务的通信如何绑定到应用程序和（在某些情况下）平台软件中的端点。

(RS_MANI_00015)

2.5 Manifests described in this Document

原则上，术语Manifest可以定义为概念上只有一个“Manifest”，并且每个部署方面都将在此上下文中处理。这似乎不合适，因为很明显，与Manifest相关的模型元素存在于典型开发项目的完全不同阶段中。这方面被认为是将术语Manifest的定义细分为三个不同分区的主要动机：

**Execution Manifest **：这种Manifest用于指定在AUTOSAR自适应平台上运行的应用程序的部署相关信息，执行清单(Execution Manifest)与实际的可执行代码捆绑在一起，以便支持将可执行代码集成到计算机上。请在第8节中找到有关此主题的更多信息。

**Service Instance Manifest **：此类Manifest用于指定如何根据底层传输协议的要求配置面向服务的通信，服务实例清单(**Service Instance Manifest **)与实现面向服务通信的相应用法的实际可执行代码捆绑在一起。请在第10节中找到有关此主题的更多信息。

Machine Manifest：这种Manifest应该描述与部署相关的内容，这些内容仅适用于运行AUTOSAR自适应平台的底层计算机（即没有在计算机上运行任何应用程序）的配置，机器清单(Machine Manifest)与用于建立AUTOSAR自适应平台实例的软件捆绑在一起。请在第7节中找到有关此主题的更多信息。

不同种类清单的定义（和用法）之间的时间划分导致了这样的结果：在大多数情况下，不同的物理文件将用于存储这三种Manifest的内容。但是，与所有类型的ARXML内容一样，这不是一个绑定规则。