TR_AP方法论（22-11）

1 简介

1.1 目标和范围

AUTOSAR在主要的开发步骤中的一些通用的技术方法，称为AUTOSAR的方法论。

本文主要介绍自适应平台的方法论。

相关的需求定义在《Requirements on Methodology for Classic and Adaptive Platform AUTOSAR_RS_Methodology》

自适应AUTOSAR平台引入了新的概念，这里的扩展是有必要的。

与AUTOSAR经典平台相比，自适应AUTOSAR是在进程（进程是由操作系统管理的实体）的上下文中执行的。如果操作系统的配置允许，则可以在机器的生命周期中的任何时候启动、执行或停止进程。因此，配置的方式或软件包被部署的时间和方式（例如，通过OTA更新）显然不同于AUTOSAR经典平台的概念。

此外，AUTOSAR自适应平台引入了机器的概念。机器是准虚拟化的ECU-HW，软件可以部署到的实体。基于这个概念，一个真正的ECU-HW可以运行多个机器。最简单的情况是机器和ECU-HW之间1:1映射。

以上列举的例子也许并不全面，但是足以作为为AUTOSAR自适应平台提供单独方法论的充分的理由。

尽管有差异，但也有许多共性，如对系统特性的描述，如拓扑结构或硬件能力。为了避免重复，本文档将更多地关注AUTOSAR自适应平台的细节。这两个平台的共同方面的规范由单独的文档阐述。

[TR_AMETH_00100] AUTOSAR自适应平台的方法范围 【AUTOSAR自适应平台的方法论描述了构建AUTOSAR自适应系统所需的主要概念（用例、任务、工作产品、……）以及它们如何相互关联。该方法既没有提供完整的过程描述，也没有规定活动的精确顺序。活动可能是迭代的， 在这里不作过多描述】

1.2 文档大纲

本文档将遵循AUTOSAR经典平台的策略，即如何建模用例、如何构造文档以及指定的方法。因此，本文档的大纲大致遵循了AUTOSAR经典平台的对应内容：

• 第2节（自适应平台的用例）描述了开发实现AUTOSAR自适应平台的系统的主要用例。请注意，AUTOSAR方法论中不包括对软件包的生命周期的描述
• 第3节（自适应方法库）列出并描述了在第2节中的用例描述中使用的所有任务和工作产品。
• 本介绍部分的其余部分记录了所使用的策略和需求可追溯性图。

1.3 文档约定

本文档遵循一个文档约定列表，如下所示。

AUTOSAR的技术术语是用单间距字体排版的，例如Machine。作为一般规则，技术术语的复数形式是通过向单数形式中添加“s”来创建的，例如Machines。

本文档包含文本形式的规范项，区别在于它们有唯一的数字ID、标题和以[开始]字符结束的正文。需求可追溯性的约定遵循[TPS_STDT_00080]，请参见标准化模板（[3]）。

1.4 缩写和技术术语

术语和缩写的主要列表在[4]中定义了。下表包含了本文档范围中使用的尚未在[4]中定义的术语和缩写的列表，以及每个缩写的拼写含义。

术语	含义
自适应软件（Adaptive Software）	为运行在AUTOSAR自适应平台上而定制的应用程序级或平台级软件实体。这些软件实体可以由多个在多个操作系统进程中运行的可执行程序组成。
自底向上法(Bottom-up approach)	一种方法模式，其中工作/设计从具体/细粒度方法流向抽象/粗粒度方法，例如SWC→二进制→软件集群→系统
诊断管理器(Diagnostic Manager)	术语诊断管理是表示诊断通信和事件处理的完整功能的占位符。
功能组（Function Group）	功能组为一组可能具有运行时相互依赖关系的内聚实例（即进程）定义了一个状态机。流程指定它对功能组的参与。
实例说明符（Instance Specifier）	实例说明符是实例引用缩短的“字符串化”表示。 就 ARXML 而言，实例引用使用 《InstanceRef》 进行原型化，如果在目标上不需要它，也可以使用 《atpUriDef》 :在这种情况下，只有实例说明符在目标上的配置数据中可见。
自顶向下分析法（Top-down approach）	一种方法模式，其中工作/设计从抽象/粗粒度方法流到具体/细粒度方法

1.5 方法论概念

自适应平台的方法论概念与经典平台的方法论概念是相同的。因此，我们在这里只提到主要原则。详情请参见[1]中的第1.5节。

[TR_AMETH_00101]任务、工作产品和用例的定义。【该方法通过活动、实体来聚合任务及其相应的工作产品来描述典型的用例。任务被定义为可重用的元素：将处理输入信息（例如，存储在特定的工作产品中），以生成新的工作产品】

[TR_AMETH_00102]工作产品的类型和种类。【工作产品可以是手工，也可以是可交付物，可以是AUTOSAR XML、源代码、对象代码、可执行文件、文本或自定义的类型】

[TR_AMETH_00226]工作产品的文档编制。【为了在开发过程中记录设计决策或限制，每个工作产品可以汇总相应的文档。】

这些定义和图形主要遵循软件过程工程元模型规范[5，SPEM]，使用由SPEM支持的企业架构师建模工具提供的符号。

1.8 设计与部署

请注意单个产物（或可交付成果）的工作流

1. 可能只与设计步骤相关联
2. 可能与设计和部署步骤都相关联
3. 可能只与部署步骤关联
4. 可能会与基于来自设计级别的信息的部署步骤相关联
   1. 这可能包括复制到部署产物中的设计数据项
   2. 这可能只需要来自设计级别的结构信息
5. 可能与在设计级别上有直接对应物的部署步骤相关联

这说明在AUTOSAR自适应平台上的设计和部署之间的边界不像在AUTOSAR经典自适应平台上那样容易定义

2 自适应平台的用例

本章介绍了根据《5. 软件过程工程元模型规范》，在任务和工作产品方面构建基于AUTOSAR自适应平台系统的主要用例。

[TR_AMETH_00200] 用于AUTOSAR自适应平台方法的开发领域 【

自适应平台的方法应由以下开发领域来构建：

• 分析
• 架构设计
• 系统开发
• 软件开发
• 集成和部署

】

[TR_AMETH_00204]{DRAFT} 开发系统。【经典平台方法[1]的部分规范也应适用于自适应平台：

• 系统的开发和（开发）整体系统（[TR_METH_01048]），它可以通过定义 ECU 实例和网络的拓扑以及将软件组件部署到 ECU 实例来探讨 VFB 的改进， 具有车辆软件架构所需的扩展和指定机器的添加以及机器到 ECU-HW 的相应映射。
• 两阶段开发方法（[TR_METH_01047]）和组织之间的交互（[TR_METH_01049]），它们构建了不同组织之间的协作，比如oem与其供应商之间的协作。

】

[TR_AMETH_00251] {起草}变体处理 【CP中已知的变体机制仅适用于AP中与CP共享的配置项。任何与设计时间相关的AP配置项都隐式地具有代码生成或预编译时间的最新绑定时间。任何被定义为清单内容的AP配置项都会受到构建后和运行时差异的影响：可以仅通过替换清单文件来更改自适应软件的行为。

】

图 2.1 显示了自适应平台方法的主要领域，从高级架构通过几个设计和集成步骤到应用程序实施和 SW 打包。

2.1 系统-高级架构

一辆汽车上大概率会包含以下类型的ECU单元：

• 基于CP开发的ECU实例；
• 基于AP软件开发的机器
• 非AUTOSAR的硬件单元

因此，整个车辆的软件架构和系统设计必须涵盖所有这些ECU以及这些ECU之间的通信。

图2.2概述了高级体系结构范围内的任务和工作产品。

1. 开发功能架构将重点放在从未来实现中抽象出来的车辆功能上：E/E系统架构师评估并指定特定E/E车辆项目或项目系列所必需的车辆功能、特性和需求。由此产生的功能架构（见[TR_AMETH_00201]）很可能是一个非AUTOSAR 文档（或模型），描述了功能网络，表示执行特定车辆功能所需的功能网络。
2. 开发抽象平台规范将重点放在车辆功能及其交互的平台独立组件模型上。由此产生的抽象平台规范定义：（整车组件图，包括端口以及之间的连接）
   1. 抽象组件，忽略其未来实现的AUTOSAR AP / CP /非AUTOSAR软件实体或硬件实体
   2. 基于抽象的端口接口描述的通信端点
   3. 通信端点之间的连接，而不考虑其未来通过AUTOSAR AP服务发现或CP连接器或跨平台通信实现的实现。
3. 开发车辆软件架构将重点放在针对AUTOSAR AP或CP的软件组件上。所生成的车辆软件架构：（车辆软件架构
4. 为AP和CP平台分配功能
   • 并定义了所需的AP和CP内部和跨平台通信，以及与非AUTOSAR实体的“外部”通信的需求。

图2.3概述了从功能体系结构推导出的车辆软件体系结构。

1. 开发车辆硬件架构将重点放在了从车辆软件架构中部署软件实体的ecu上。由此产生的车辆硬件架构指定了所需的 ECU 及其用于 AP（机器）、CP（ECU 实例）和通信基础设施的 HW 资源。图2.6概述了从车辆软件体系结构到从车辆硬件体系结构的硬件实体的关联。（车辆硬件架构）

[TR_AMETH_00001]{草案}识别抽象的端口接口。【此活动指定了抽象平台规范中通信端点所需的端口接口的功能。

在[9，抽象平台的规范]中定义的抽象端口接口指定：

• 1. 命令作为AP方法和CP客户机/服务器操作的一种抽象形式
  2. 指示是AP事件或字段和CP发送方/接收方数据原型的抽象形式
  3. 属性作为AP字段的抽象形式和收集的CP客户端/服务器操作，发送者/接收者数据原型
  4. 所有这些数据都使用了抽象的数据类型，概述了对未来具体的AP和CP数据类型的需求。

2.1.1 整体系统视图

[TR_AMETH_00201]开发功能架构.【工程师可以评估特定E/E车辆项目所必需的特性和需求，以便在开发功能体系结构的活动期间形成功能体系结构图。功能体系结构图由许多车辆功能及其接口和相应的连接组成。

在分析步骤中，车辆功能可以被详细分配到许多功能块中，然后得到派生的抽象平台规范中的抽象软件模块：

• 一个功能块封装了一个特定的功能。（注意：功能块可以在软件或硬件中实现，也可以作为两者的混合来实现）。
• 功能块的组合表示执行特定车辆功能所需的功能。

此活动是可选的。

】

[TR_AMETH_00202]{开发一个车辆软件体系结构。【工程师（软件架构师）可以将功能体系结构和/或抽象平台规范作为输入，以得出出相应的车辆软件体系结构。】

车辆软件架构提供了E/E车辆系统中所有AUTOSAR软件实体及其通信关系的专用视图：

• 自适应平台（AP SWCs）的AUTOSAR软件组件
• 经典平台（CP SWCs心）的AUTOSAR软件组件
• 具有AP和/或CP swc的任意组合的AUTOSAR软件组合
• 软件组件之间的通信：

车辆的软件架构中有：

• • AP SWC之间的自适应（即面向服务）通信
  • CP SWC之间的经典（即基于信号的）通信
  • AP和CP swc之间通过SOME/IP进行面向服务的通信
  • AP和CP swc之间通过信号/服务转换进行通信

请注意，分配给不同ecu的swc可以通过通信基础设施交换数据。swc的通信端点由特定的端口接口定义输入端口。在自适应平台中，接口被表示为为面向个别服务的通信用例量身定制的服务接口。

2.1.2 派生子系统

[TR_AMETH_00203]起草}派生子系统.【一个子系统是整个技术系统的一个简化部分。可行的用例是

• 推导出一个VFB视图的纯AUTOSAR经典子系统
• 推导出一个纯AUTOSAR自适应平台子系统
• 推导出一个混合自适应/经典平台子系统的视图。

分解成子系统的动机是

• 功能方面，例如，按车辆功能确定子系统的范围
• 技术方面，例如，通过AUTOSAR确定子系统的范围
• 任务分工，例如通过计划的分包来确定子系统的范围

任何子系统都可以与其他子系统交互：在这种情况下，分配给不同子系统的软件组件进行通信。为了支持这一点，子系统应包括至少为与其他子系统接口的AUTOSAR自适应和经典平台软件组件接口的端口接口定义。

】

整个车辆软件架构涵盖了包含所有的AUTOSAR实体的车辆整个系统。自上而下的方法的下一步与子系统的分解有关，中间步骤可能是任意的，直到达到特定于平台的子系统（参见[TR_AMETH_00203]）。

• AP和CP混合子系统将像有限范围的车辆软件架构一样处理（只覆盖车辆中AUTOSAR软件的部分）
• 从车辆软件体系结构中提取的CP子系统涵盖了车辆中任意CP ecu实例的CP软件。该CP系统将按照CP方法进行处理，逐步分解为多个ECU的系统提取、单个ECU的系统提取和ECU提取。
• 从车辆软件体系结构中提取的AP子系统涵盖了车辆中任意AP机器的AP软件。该AP系统将按照AP方法进行处理，并将其分解为机器（设计）提取，再分解为软件集群提取。
• 至少提取的子系统的通信端点和（概述但针对技术的）端口接口描述（作为来自[TR_AMETH_00001]的抽象端口接口的具体化）。

图2.4概述了从车辆软件体系结构中衍生出的子系统

请注意，车辆软件架构是只需要在一个自上而下的方法在定义高级架构。在自底而上的方法中，车辆软件体系结构显然是可选的，但可以从单独创建的CP和/或AP子系统中聚合。

车辆软件体系结构中确定的自适应和经典软件模块需要部署在车辆硬件体系结构中确定的ECU上：

图2.5概述了软件集群的分组。

• 这仅在AP中是强制性的：这里的swc集成到可部署到特定机器的可执行文件中（可升级的软件）。
• 对于CP软件集群，允许将一组swc一起部署到一个特定的ecu实例中（一个软件簇对应一个ECU实例）
• 最后，我们可以将软件集群映射到硬件实体。

图2.6概述了从车辆软件体系结构到车辆硬件体系结构中AP（机器）和CP（ECU-实例）的软件集群的分配。

整个车辆硬件架构（如图2.7所示）涵盖了所有ecu的拓扑结构以及车辆中互连的通信基础结构。这个硬件拓扑结构由以下部分组成：

• 表示物理或虚拟ECU-HW项的节点，它们承载特定CP ECU实例或特定AP机器或这些项的特定组合。
• 节点之间的连接器表示通信连接。如CP的CAN或以太网和AP的SOME/IP。
• 用于无线通信的连接器（例如用于车辆对车通信用例或软件更新OTA用例）。

2.2 系统设计

图2.8概述了系统设计范围内的任务和工作产品。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.2章）。

主要输入是车辆软件架构图和来自高级体系结构的车辆硬件架构图，另请参见第2.1.2章。系统设计代表了一个来自高级体系结构的、最好是特定于平台的子系统。

本系统的设计内容包括：

1. 系统拓扑描述作为定义系统拓扑任务的结果，旨在改进车辆软件架构，并定义具有所需功能及其通信需求的子系统。这包括：

• • 为分布式但一致的功能指定组。这些功能组将在软件集群设计过程中详细地作为软件集群设计描述。在AP中，功能组描述定义了一组可能具有运行时相互依赖性的内聚可执行实例（又名应用程序进程）
  • 指定所需通信技术的通信集群的网络连接性，如CP的CAN或以太网，以及AP的SOME/IP。
  • 对于以太网（当然还有 SOME/IP），网络端点描述定义了参与通信集群的 ECU（或者更准确地说是 CP-ECU 实例和 AP 机器） 的各个通信连接器的网络地址（作为 Internet 协议版本 4 或版本 6 地址和/或媒体访问控制 (MAC) 多播地址）。
  • 将服务网络指定为服务拓扑描述。这包括服务接口的规范（见第2.3章）、技术特定服务的定义、服务提供者的实例化、服务实例到CP-ECU实例和AP机器的分配实例，最后以及服务实例对网络端点的分配。可选地，还可以指定服务消费者的实例化，以及通过provided和provided服务实例进行的服务提供者和消费者之间的连接。

1. 作为识别软件集群的结果的一些初始的软件集群设计描述，旨在定义子系统软件体系结构中的主要构建块。软件集群设计描述的实际阐述见第2.9章软件集群设计。

我们将/可能将软件组件分组为软件集群，以便在ECU上部署软件集群。对于CP来说，这是一个可选的分组，以方便将swc映射到ecu实例。对于AP来说，这是参与部署在特定机器上的可执行文件构建的强制分组。

请参见[6清单规范]中的“软件分发”和[10系统模板”中的“软件集群”。

1. 全局时间描述作为任务的结果，定义全局时间，旨在参与ecu的车辆范围内的时间同步。

在执行（分布式）车辆功能时，一个车辆E/E系统中的多个ECUs可能需要协同工作。为了实现这一点，在所有连接的CP-ecu-实例和ap-机器上的全局时间功能集群需要同步到相同的时间基。

请参见示意图2.9跨CP-ECU实例和AP机器同步功能集群，所涉及的全局时间功能集群（图中标记为X）如何通过通信基础设施交换同步消息。

AP的全局时间描述描述了范围内的机器如何参与车辆的全局时间同步。这是通过以太网发生的。对于CP，全局时间同步可能通过CAN或以太网发生。

请参见[6，清单规范]中的“时间同步部署”和[10系统模板]中的“全局时间同步”一章。

1. 网络管理描述作为任务的结果，定义网络管理，旨在参与网络（和ecu的网络连接器）的全车辆唤醒和睡眠行为。

请参见示意图2.9中的跨CP-ECU实例和ap机器的同步功能集群，所涉及的网络管理功能集群（图中标记为X）如何通过通信基础设施交换同步消息。

通常，OEM提供网络配置与车辆中所有连接的CP-ECU-实例和ap机器的网络管理功能集群相关的所有配置设置。

AP的网络管理描述描述了作用范围内的机器如何参与车辆中的整体网络管理。另请参见[6，清单规范]和[10，系统模板]中的网络管理章节中的TPS_MANI_03166和TPS_MANI_03226及相关说明。

1. 定义信号到服务的转换，目的是定义AP的SOME/IP序列化通信如何转换为基于信号的CP通信，反之亦然。

上述任务可以根据需求以任意的顺序执行。

2.2.1 系统设计使用场景（自顶向下）

图2.10显示了针对车辆范围的系统描述的自上而下的使用场景中系统设计的定制任务和工作产品定义。这可能是从头开始的，或从一些基线系统描述开始的。

元素包括：

• 定义（完整的）系统拓扑结构：

• • 将系统分解为子系统
  • 定义功能组
  • 定义网络端点
  • 定义服务拓扑
• 识别功能组的软件集群
• 为车辆软件体系结构中标识的软件实体和子系统定义子系统软件体系结构中的主要构建块（见第29页列表项目2中的概述），另请参见[TR_AMETH_00203]。
• 定义系统范围内的全局时间：定义ECU的车辆范围内的时间同步（请参见第30页列表项目3中的概述）。这使得跨所有连接的CP-ECU-实例和ap-机器的全局时间功能集群能够同步到相同的时间基础上。
• 定义全系统范围内的网络管理：定义网络的全车辆范围内的唤醒和睡眠行为（参见第30页列表项目4中的概述）。这使得在所有连接的CP-ecu-实例和ap-机器上的网络管理功能集群能够根据预期的唤醒和睡眠行为来控制网络连接器。

自上而下的方法导致以下为系统范围量身定制的工作产品：

• 系统拓扑描述

作为根据当前系统设计范围的系统拓扑，考虑子系统、功能组、网络端点和服务拓扑的定义（完整）系统拓扑的结果。

• 全局时间描述

作为定义全系统范围内的全局时间的结果

• 网络管理描述

作为定义全系统网络管理的结果

• 软件集群设计描述

作为对功能组的识别软件集群的结果，识别和描述根据当前系统设计范围实现功能组的软件集群。

2.2.2 系统设计使用场景（自底向上）

图2.11显示了在一个自下而上的使用场景中，系统设计的定制任务和工作产品定义，目标是针对特定ap机器的系统设计的贡献。

元素包括：

• 定义机器的系统拓扑贡献

其目的是为机器定义子系统，并为机器贡献网络端点

最终结合在本地定义机器设计（参见第2.7.1章机器设计使用场景）

• 概述特定机器范围内的子系统

来识别功能范围内的软件集群。

自底向上的方法得出机器范围对应的工作产品：

• 软件群集描述

作为在特定机器的范围内概述子系统的结果，根据当前机器的范围来识别实现功能组的软件集群。

• 系统拓扑贡献

作为为根据当前机器范围考虑功能组、网络端点和服务拓扑的机器定义系统拓扑贡献的结果。

2.2.3 信号到服务的转换

图2.12信号到服务转换概述了当（且仅当）CP端没有直接和完全满足SOME/IP消息格式时，在经典和自适应平台软件实体之间设计面向服务的通信的活动。

备注：

• 此活动的背景是请求通过SOME/IP在经典平台（CP）ECU实例的应用程序和自适应平台（AP）机器的应用程序之间实现面向服务的通信。
• 如果CP按照SOME/IP通信，则不需要服务转换。这是一种情况，如果

• • CP通过以太网直接通信，实现了SOME/IP消息格式。
  • 网关完成了信号到服务的转换（例如从CAN)转换为SOME/IP消息格式。
• 否则，根据[TR_AMETH_00207]、[TR_AMETH_00208]和[TR_AMETH_00210]提供的服务转换信号，须完成以下工作：
  • CP不支持服务接口。因此，相当于AP服务接口可以由不同类型的CP端口接口组成，如发送器/接收器、客户端/服务器或触发器接口。
  • 信号到服务的转换规范需要包括AP和CP接口元素的映射，以及数据实例的映射（例如，来自AP服务实例的SOME /IP消息和CP信号的映射）。

[TR_AMETH_00207]{DRAFT}经典平台（CP）ECU-实例与自适应平台（AP）机器之间的设计通信。【自适应软件以一种面向服务的方式进行通信。然而，一个典型的车辆将配备ECU-HW，它将承载CPECU-实例和AP机器的任何组合。

因此，ecu-实例和机器很可能需要进行通信：

• 如果ecu实例实现了SOME/IP，则可以与机器实现面向服务的通信。
  • 如果双方在总线级别上实现兼容的SOME/IP消息，这可以直接工作。
  • 如果出现不兼容的SOME/IP消息，则需要一个网关来实现总线级的兼容性
• 如果ECU实例以基于信号的方式进行通信（例如，在非SOME/IP用例中通过CAN或以太网进行通信），则需要一个从信号到服务的转换描述。
  • 双方都使用不同的端口接口类型，信号到服务的转换描述记录了这个通信场景。
  • 该上下文包括CP侧的PDU或以太网套接字和AP侧的服务实例。

】

[TR_AMETH_00208]{DRAFT}AUTOSAR 经典平台（CP）和自适应平台（AP）之间的设计信号服务转换。【

为了描述AP和CP之间的通信，即使在CP端不完全遵守SOME/IP的用例中，“定义信号到服务转换”活动描述了将一个或多个CP端口接口的元素映射到单个服务实例范围内的单个AP服务接口的元素：

• 映射AP方法(s)：

• • 将CP客户端/服务器操作映射到服务接口的方法。
  • 将CP触发器映射到服务接口的“即发即忘”方法。

• 映射AP事件(s)：
  • 将CP发送机/接收机数据原型映射到服务接口的一个事件。

• 映射AP字段(s)：

• • 将CP客户端/服务器操作映射到服务接口的现场接收器/设置器方法
  • 将CP发送器/接收器数据原型映射到服务接口的现场通知程序。

• 根据服务实例映射AP SOME/IP消息：

• • 将服务实例ID视为服务发现中的上下文
  • 将事件消息映射到元信号触发
  • 将方法消息映射到信号触发

由此产生的信号到服务的转换描述可用于生成转换代码。

】

[TR_AMETH_00210]{草案}将信号映射到服务。【对于信号到服务的转换描述，服务实例描述中的所有服务接口元素都被映射到基于信号的通信协议的相应项目，如CAN或FlexRay。

• 有关方法，请参见[6，清单规范]中的TPS_MANI_03125
• 有关事件，请参见[6，清单规范]中的TPS_MANI_03124
• 有关字段，请参见[6，清单规范]中的TPS_MANI_03126
• 有关具体的实例上下文，请参见[6，清单规范]中的TPS_MANI_03000

】

2.3 服务接口设计

图2.13给出了服务接口（设计）描述范围内的任务和工作产品的概述。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.8章）。

由此产生的工作产品是：

服务接口描述，作为定义服务接口的结果

• 最终通过服务接口映射增强为聚合服务接口的结果，以减少总线负载
• 为自适应平台定义的数据类型，作为为自适应平台定义数据类型的结果

[TR_AMETH_00008]{草案}开发自适应软件的服务接口。【

自适应软件中使用的所有服务接口都需要定义为具有事件、方法和现场细节的服务接口描述。

它们是生成头文件的基础。因此，也可以在服务接口中定义命名空间，这将对生成的代码产生直接影响。

】

[TR_AMETH_00009]{DRAFT}聚合服务接口，以减少总线负载。【可选地，可以通过分别定义服务接口映射或服务接口元素映射，将服务接口聚合到更粗粒度的服务接口。这导致服务接口描述的更新。 新定义的粗粒度服务接口随后用于基于网络的通信。】

[TR_AMETH_00007]为自适应平台的数据类型的定义。【自适应平台的数据类型可以根据AUTOSAR中的标准化数据类型来定义。与在经典平台上一样，数据类型是在不同的抽象级别上定义的：应用程序数据类型、实现数据类型和基础类型。大多数概念和数据类型都可以从经典平台中复用。然而，为了应对C++编程语言，自适应平台的数据类型包括C++实现数据类型(支持vector、字符串、map等。

有关为经典平台指定的数据类型和为自适应平台扩展的数据类型的更多信息，请参见[6，清单规范]和[11，软件组件模板 】

2.3.1 服务接口设计使用场景

图2.14显示了如何获取服务接口描述的使用场景。

• 根据定制的任务创建/更改用例：

• • 定义（或重用）服务接口
  • 为服务接口定义（或重用）数据类型
  • 这可以在自上而下的系统和/或应用程序设计活动的上下文中完成

• 在基于定制任务的重用用例中：

• • 重用服务接口
  • （定义或）重用服务接口的数据类型
  • 这可以在自下而上的方法中的系统和/或应用程序设计活动的上下文中完成

• 从而产生量身定制的工作产品

• • 服务接口说明
  • 服务接口的数据类型说明

2.4 应用设计

图2.15给出了应用程序设计范围内的任务和工作产品的概述。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.3章）。

所生成的应用程序设计描述包括：

• 软件组件设计作为定义软件组件设计任务的结果。

软件组件设计定义了实例化的特定（应用程序级或平台级）的SWC端口接口方面的交互端点

• 可执行描述包括软件组件的描述，该描述是任务使用封闭的软件组合定义可执行体的结果。依赖：

所有的引用的软件组件设计是可用的。

• 进程设计描述是定义进程设计描述任务的结果。其目的是为实例化（即启动）一个特定的可执行文件的实际操作系统进程定义一个设计时间代理。

依赖可执行描述文件可用

• SW交互描述是在设计时已知的可执行实例中SWC端口的交互配置。包含：
  • 作为任务定义与应用程序的交互结果的应用程序级交互
  • 平台级的交互作为任务定义与功能集群的交互的结果
  • 对于诊断，这可能包括/预测与诊断设计相关的软件到诊断交互描述的贡献（另请参见图2.20诊断设计）。

依赖

• 进程设计描述文件，可执行设计描述文件，和软件组件设计描述文件可用
• 软件组件设计包含应用级别和平台级别的端口配置为交互端口

上述任务具有相互依赖的关系，可以根据需求按适当的顺序执行。

图2.16给出了AUTOSAR自适应平台软件层的概述。我们区分了应用程序级和平台级的软件。请注意，本章中定义的描述应用程序设计的活动也可能适用于平台级软件，特别是如果平台级软件支持端口/端口接口的概念。

[TR_AMETH_00010]{草案}应用程序级软件.【一个类别为应用程序级别的自适应软件是一个可执行文件的集合。任何应用程序级的可执行文件都可以组成一个或多个软件组件。】

[TR_AMETH_00011]软件组件的设计【基于服务接口，自适应应用软件的开发从软件组件的设计开始。这些软件组件可以具有分层结构。任何软件组件设计都通过需端(required)和/或供端（provided）实例化服务接口（应用程序级接口）和功能集群接口（平台级端口）来定义其交互端点。】

[TR_AMETH_00035]{草稿}平台级软件。【一个类别为平台级的自适应软件是一个可执行文件的集合。平台级可执行文件可以包含基于软件组件的标准化服务接口，但也可以在没有软件组件模型的情况下直接实现。】

2.4.1 应用程序设计使用场景（自顶向下）

图2.17展示了如何详细设计应用程序设计的使用场景，针对完整的可执行文件和它们的实例化，作为基于定制任务的过程设计描述（自上而下的方法）：

• 用封闭的软件组合定义可执行文件：
  • 定义或重用软件组件

这包括根据端口实例化特定的（应用程序级或平台级）端口接口而提供的SWC交互端点的规范。输入是功能集群接口描述和服务接口描述，可交付的是一个软件组件描述。

• • 定义可执行体

这包括可执行体的专用软件组合中的实例化。

输入是软件组件描述，可交付的是可执行的描述以及相关的软件组合描述

• 定义可执行的运行时行为
  • 定义进程设计作为实例化（如启动）一个特定可执行文件的实际操作系统进程的设计时间代理
• 为可执行实例中存在的SWC端口实例定义SW交互
  • 定义与应用程序软件的交互
  • 定义与功能集群的交互
  • 输入来自应用程序设计，可交付的是一个扩展应用程序设计的软件交互描述。

上述活动具有前任依赖性，需要按照要点的顺序来执行。

2.4.2 应用程序设计使用场景（自底向上）

图2.18显示了如何根据定制的任务详细设计对应用程序设计的贡献的使用场景：

定义可重用的软件组件，定义可重用的软件组件输入是功能集群接口描述和服务接口描述，可交付的是软件组件描述。

2.5 自适应软件的实现

图2.19给出了在应用程序级和平台级的自适应软件实现范围内的任务和工作产品的概述。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.4章）。

[TR_AMETH_00002]{草案}开发自适应软件 【当定义了自适应（服务）接口时，应用程序级和/或平台级的自适应软件的开发就可以开始了。这个软件开发可能包括一些子活动，如分析、设计、实现或测试。

这个活动的最重要的结果是源代码或对象代码工件，这取决于开发人员事先是否知道自适应软件构建配置。

最后，自适应软件开发人员将所得到的自适应软件实现转发给集成人员。

】

开发自适应软件和自适应软件的实现细节：

• 对实际软件开发的输入是自适应软件生成的项（参见[TR_AMETH_00012]）。这对于实现（但不限于）COM端口和相关端口接口的服务代理和骨架是必要的。
• 实际的软件开发（参见[TR_AMETH_00013])取决于自适应软件构建配置的可用性：

• • 当然，首先需要开发自适应软件源代码。
  • 如果集成商提供了自适应软件构建配置（参见[TR_AMETH_00014])，则可以交付自适应软件对象代码（无需公开自适应软件源代码本身）。
  • 否则，需要自适应软件源代码（参见[TR_AMETH_00015]）。
• 请注意，应用程序级和平台级的自适应软件需要一个主要的功能和一个执行清单（另请参见[TR_AMETH_00020]）。

[TR_AMETH_00012]生成服务接口的头文件。【这一步独立于软件组件及其具体端口的设计：头文件为范围内任意数量的服务接口生成，用于软件组件的开发。

所生成的自适应软件生成项包括服务代理（用于需要COM端口）和服务骨架（用于提供COM端口）。这包括平台独立的头文件和特定于平台的实现。

】

[TR_AMETH_00013]{草案}软件组件的实现和编译。【生成的头文件是实现软件组件核心功能的基础】

开发存在两个典型的用例，这取决于自适应软件构建配置是已知或不知道的，因此源代码或对象代码是由应用程序开发人员交付的。

[TR_AMETH_00014]{具有自适应软件构建配置知识的开发【在这种方法中，集成商事先将自适应软件构建配置移交给软件开发人员。

软件开发人员可以根据这个构建链构建他的软件组件，并可以将对象代码交付给集成商。】

[TR_AMETH_00015]{草案}在不了解自适应软件构建配置的情况下进行开发。【对于这个用例，应用程序开发人员不知道自适应软件构建配置，因此需要向集成商交付源代码。然后，集成商负责编译软件组件的源代码】

[TR_AMETH_00020]{草案}平台级自适应软件对象代码的开发。【需要开发由一个可执行文件组成的平台模块。与应用程序级软件类似，它们稍后将根据执行清单进行实例化，然后部署到机器上。对于每个可执行文件，还需要开发相应的主要功能。】

2.6 诊断设计

图2.20概述了诊断设计范围内的任务和工作产品。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.5章）。

此活动将给定的诊断信息（诊断数据、诊断启用条件、诊断事件、诊断操作周期）与针对特定机器的特定诊断管理器的软件结构（（组件、端口等的应用程序设计信息））相关联。

在AUTOSAR自适应平台上的诊断配置通常将通过创建一个诊断提取（DEXT）（参考[12，诊断提取模板]）来完成，该模板也在AUTOSAR经典平台上使用。因此，诊断提取中的概念同样适用于两个平台上的模型：一个给定的DEXT可以分为应用于CP ecu 实例和应用于AP机器的部分，它们都属于同一辆车。

为了举例说明该方法，图2.21所示的图描述了一个非常简单的情况。自适应SWC暴露的两个不同的诊断端口被诊断管理器访问，这两个端口有不同的端口接口类型，目的是访问相关的目的（即 ）诊断数据标识符（又称DID）。

图2.21诊断目的数据交换示例数据显示了诊断数据到端口映射（从自适应SW的诊断映射），该数据正式在通信的两端之间形式化了“连接”。

获取诊断设计的活动：

• 定义诊断接口描述的结果是诊断接口描述，在定义软件组件设计中使用，以指定自适应软件通信中心的诊断端口。
• 为应用程序设置提供DEXT，包括所有用于指定诊断资源（如诊断数据标识符）并将其添加到DEXT中的活动。
• 自适应SWC可以在可执行文件中进行多重实例化，而自适应可执行文件可以在进程中进行多重实例化。

因此，每个诊断端口实例在可执行描述的上下文中都有一个明确的实例指定符，并且需要在软件中专门映射到诊断交互描述：

• 此映射需要根据过进程设计描述与操作系统进程相关联，这可以在设计时完成，但应在集成诊断期间的集成时最终确定（参见图2.21诊断目的的数据交换示例）。
• DEXT包括在定义与功能集群交互的应用程序设计中指定的软件诊断交互描述，但应在软件集群集成期间完成软件诊断交互描述以获得自适应软件的诊断映射（参见图2.33软件集群集成（第2部分））。
• 在适用的DEXT中提供针对应用程序设置结果的DEXT，以及在应用程序设计和/或诊断设计和/或软件集群设计中收集的内容。

请注意，一个DEXT可能持有多个可执行文件、诊断管理器和软件集群的诊断配置。为应用程序设置提供DEXT，以确保完全涵盖了特定应用程序设计描述的诊断需求。

• 定义诊断贡献说明结果在诊断贡献说明中指定在特定软件集群中为可执行文件定制的诊断管理器中使用DEXT的内容。

图2.22诊断设计概述了根据[TR_AMETH_00212]进行的诊断设计活动，并预计在软件集群集成期间将根据[TR_AMETH_00213]最终完成诊断映射。

诊断映射是自适应诊断管理器（模块）和应用软件中特定诊断相关端点之间关系的正式模型（另请参见图 2.21 用于诊断目的的数据交换示例），并且可以详细说明。

1. 在应用程序设计中

在活动中，定义与诊断的交互（作为定义与功能集群的交互的一部分），这导致了SW到诊断交互描述的诊断映射的早期形式。

来自[TR_AMETH_00212]和[TR_AMETH_00213]的规定可能在此时间点得到实现（取决于DEXT中相关诊断资源的可用性）。

1. 诊断设计期间

在活动中，定义诊断映射（作为为应用程序设置提供DEXT的一部分），会导致统一的诊断映射

来自[TR_AMETH_00212]的期望应该得到满足，来自[TR_AMETH_00213]的期望可以在那时得到实现。

1. 在软件集群集成期间

在活动中，最终确定诊断映射（作为集成诊断的一部分），从而导致基于软件到诊断交互描述的最终诊断映射

来自[TR_AMETH_00212]和[TR_AMETH_00213]的期望应在此时点得到实现。

[TR_AMETH_00212] 设计诊断映射 【此活动涵盖了执行诊断映射所需的最必要任务（只有相应进程设计的关联可能由集成商完成）。

详细任务如下：

• 将诊断清除条件映射到端口
• 将诊断数据映射到端口
• 映射诊断启用条件到端口
• 将诊断事件映射到端口
• 映射诊断通用服务到端口
• 映射诊断指示器到端口
• 将诊断内存目标描述映射到端口
• 将诊断操作周期映射到端口
• 将诊断安全级别映射到端口
• 将诊断软件服务映射到端口

为了执行各个任务，需要进行以下输入：

• 包含所需诊断资源的DEXT作为诊断（机器）提取物
• 可执行描述，软件组合描述指定包含的软件组件及其端口

这一步导致部分填充了自适应软件的清单诊断映射，它在设计时由软件到诊断交互描述来表示。】（RS_METH_00207，RS_METH_00201，RS_METH_00016）

2.7 机器设计

图2.23概述了机器设计范围内的任务和工作产品。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.6章）。

作为定义机器设计结果的机器设计使用系统设计的网络端点定义。

[TR_AMETH_00003]{草稿}机器的配置。【机器具有根据具体ECU-HW的ECU资源描述进行定制的配置。因此，定义机器设计和定义机器清单的活动是Tier1公司集成的职责。

提供网络端点描述，这属于OEM的通信设计的范围，这是先决条件。这发生在早期的设计阶段，由此产生的机器设计代表了对未来机器的网络通信的需求。

因此，机器的配置被细分为两个步骤：

• 第一步是配置预期机器的通信结构，并且将由OEM的通信设计者作为（系统）设计阶段的一部分执行，或者由Tier1基于OEM共享的网络端点描述执行。结果是一个机器设计。
• 第二步包括将在真正的ECU-HW上部署的机器配置的活动和任务，并将由Tier1的集成执行。然后，生成的配置是机器清单的一部分。

】

[TR_AMETH_00021]{DRAFT}定义和配置网络通信机 【

本活动将涵盖未来机器的网络通信的定义和配置，其中包括：

• 配置网络连接的网络端点IP（版本4或版本6）地址
• 配置与多播IP地址和UDP端口之间的服务发现消息交换

】

2.7.1 机器设计使用情况

图2.24显示了如何在设计必要时获得与通信相关的机器配置（即机器设计）的使用场景

• 在现有的系统设计（自顶向下的方法）中，根据系统拓扑描述中根据定制任务：

- 根据系统拓扑定义机器设计

• 或在局部（自下而上的方法），最终伴随着基于定制任务的系统拓扑贡献：

- 在局部定义机器设计

• 导致定制工作产品网络连接器描述和服务发现描述作为机器设计选择也在系统设计的系统拓扑贡献

2.8 机器清单

图2.25概述了机器清单范围内的任务和工作产品。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.7章）。

定义机器清单的一个主要输入是机器设计中可用的通信结构的配置，这是在机器设计过程中准备的（见第2.7章），其中[TR_AMETH_00003]定义了这个工作边界。

所生成的机器清单包括：

• 描述可用的ECU-HW资源的机器描述，请参见[TR_AMETH_00019]和[TR_AMETH_00217]。
• 机器设计作为定义机器设计的结果，见第2.7章机器设计。
• 平台模块配置作为定义平台模块配置的结果，请参见[TR_AMETH_00023]、[TR_AMETH_00214]、[TR_AMETH_00215]和第2.10.3章创建平台模块配置。
• 在特定机器上运行的进程的配置是执行清单的一部分，请参见第2.10.2章创建执行清单。

图2.26概述了在设置机器清单时进行的活动。

[TR_AMETH_00019]{草案}自适应平台的ECU-HW资源描述。【作为第一个准备步骤，需要指定一个特定的自适应平台实例的可用硬件元素。为此的主要配置实体是ECU资源描述，描述了可用的硬件单元，如处理单元、存储器、传感器、执行器或引脚。ECU资源描述应来自ECU-HW提供商.】（RS_METH_00207，RS_METH_00041）

[TR_AMETH_00034]{DRAFT}选择自适应平台的操作系统 。【需要为一个特定的自适应平台选择并提供一个操作系统（OS）。可能有必要为特定的ECU-HW和机器定制操作系统。自适应平台的操作系统是一个没有执行清单的平台模块。请注意，它的开发工作流程将不同于平台级软件（RS_METH_00207，RS_METH_00041）的工作流程】

[TR_AMETH_00217]{草案}资源的定义 【机器的配置可以包括资源的规范作为机器描述。基于目标ECU-HW的ECU资源描述，可以描述特定机器的可用硬件资源，并添加到机器清单中（RS_METH_00204，RS_METH_00203）】

[TR_AMETH_00023]{DRAFT}操作系统的配置 【操作系统平台模块配置指定了操作系统的特定实例化，具有资源组、支持的计时器粒度等】

[TR_AMETH_00214] 平台服务配置 【机器的配置包括机器特定的平台模块自适应平台服务配置（如网络管理、DoIP）】（RS_METH_-00204，RS_METH_00203）

[TR_AMETH_00215]平台基础模块的配置 【除了操作系统的配置外，机器的配置还包括自适应平台基础模块的机器特定的平台模块配置（如日志和跟踪）。】（RS_METH_00204，RS_METH_-00203）

2.9 软件集群设计

软件集群表示可上传的软件包（可以理解为安卓里的app应用）

图2.27和图2.29概述了软件集群设计描述范围内的任务和工作产品。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.9章）。

AUTOSAR 自适应平台作为现场部署软件单元的平台，其本质需要此类软件的前期设计支持。

例如，这样的软件单元可以是一个独立的驾驶功能。

这需要支持应用程序级软件在内部或在驾驶功能之间与其他应用程序级软件进行通信的设计过程。

我们使用软件集群设计描述来设计可能代表这种驾驶功能的软件。注意，软件集群设计描述支持任意粒度的软件，因此也可能涵盖多种驾驶功能。

还请注意，将软件集群设计描述转换为软件集群描述并没有通过AUTOSAR格式化。这一步可以通过一个集成人员自行决定的工具来完成。在某些情况下，这种转换可能在开发项目中较早完成，而其他项目可能使软件集群设计描述保持较长的时间。

软件集群设计描述涵盖了可部署软件实体的各个设计方面，这些方面可以在自上而下或自下而上的工作流中指定：

• 在自上而下的方法，软件集群设计描述考虑车辆软件架构的一部分，组成的子系统软件架构在系统设计的活动定义系统拓扑和识别软件集群，如图2.4所示从车辆软件架构提取子系统：

• • 定义系统拓扑考虑分解为子系统以及服务拓扑的定义
  • 识别软件集群考虑了在系统设计时可用的软件集群设计描述内容

基于这些信息，软件集群设计描述的详细说明开始并确定了应用程序设计中详细包含的应用程序和平台级软件实体

• 在自底向上的方法中，一些独立开发的应用程序设计描述（参见第2.4章应用程序设计中的图2.15应用程序设计）可以被输入，用于软件集群设计描述的设置
• 在这两种情况下，为范围内的功能定义provided和required服务实例（以及相关的服务接口描述）都是开发的一个很好的起点

2.9.1 SW集群设计纲要

软件集群设计描述代表了对需求的响应，这些需求已由OEM制定，并可能随着软件开发的进行而得到丰富

• 任何软件集群设计描述的目的都是指在目标机器上进行安装变更的设计：应添加、更新或删除一个可安装的实体（定义什么是软件簇（可安装的实体））。这包括（但不限于）：
  • 预先加载软件集群的定义
  • 支持一致性
  • 为未来的部署定义构建块
• 可安装实体的粒度和分区：
  • 在简单的情况下，软件集群设计描述只涵盖了一个（一致的）可安装实体
  • 在更复杂的情况下，软件集群设计描述具有一个嵌套结构，反映了一组要一致安装的可安装实体。使用案例包括：
    • 一个分布式开发场景（根据相关方进行嵌套）
    • 分段更新（嵌套定义构建块）
• 与高级体系结构的关系可能是正交的：
  • 例如，一个驾驶功能可能有多个软件集群设计
  • 软件集群设计描述的概念适用于平台级和应用程序级软件的任何组合。

注意，软件集群设计描述不会被上传到目标平台。它只是被上传的最终软件集群描述的早期形式。

软件集群设计大纲涵盖了软件集群设计的基本设置说明：

• 指定软件集群设计描述容器本身
• 指定所包含的软件的黑盒，在软件集群设计描述中识别通信端点（参见图2.28服务实例映射），可能是在任何应用程序设计活动开始之前。软件集群设计描述之间的
• 依赖性允许在早期设计阶段描述需要一起安装的内容。由于软件集群设计描述不包括版本标签，这些依赖关系一般只考虑软件集群
• 可选择关联诊断地址和贡献，也可选择关联当前已知的内容元素。这可能包括针对预期目标机器的机器设计，作为在开发项目的早期阶段的未来可上传软件包的上下文

详细内容将在稍后的时间点以任何顺序添加。

2.9.2 定义（和映射）provided和required服务实例

通常，定义provided和required服务实例是开发软件集群的起点。

基于服务接口描述的必要输入，这将得到基于服务部署描述（请参见[TR_AMETH_00027]）的服务实例描述（请参见[TR_AMETH_00005]）。

在早期的设计阶段，包含软件的黑盒子概述了通信端点作为委托端口（表示软件集群设计描述的封闭软件的公开端口）——通常在实际的应用程序设计描述可用之前。为了将服务实例描述与软件集群设计描述关联起来，我们需要使其在封闭软件的特定通信端点上有效。

为了实现这一点，包含的软件的黑盒为在软件集群设计描述中处理的每个服务实例描述指定了一个单独的委托端口。

• 只有当应用程序设计描述和进程设计描述可用时，将provided和required服务实例映射到包含的可执行文件时，才允许最终确定服务实例映射。
• 图2.28服务实例映射提供了一个概述。
• 服务实例描述和服务实例映射将用于在软件集群集成期间创建服务实例清单。

[TR_AMETH_00027]{草案}服务接口部署的配置【负责的软件集群在服务部署说明中指定了如何部署服务接口。这包括描述服务接口的单个传输层绑定的（车辆范围内的合并）属性。例如，对于SOME/IP部署，我们为每个服务接口定义了一个ID。此ID需要在系统上下文中是明确的。此外，方法id、事件id和事件组都在个别的SOME/IP服务接口部署的范围内明确地定义过。（RS_METH_00206，RS_METH_00203）】

[TR_AMETH_00005]{DRAFT}服务实例的配置【负责的软件集群在服务实例说明中指定了如何按照提供或需要的服务实例化服务接口。这扩展了从服务部署描述中描述服务接口的单个传输层绑定的（车辆范围内的整合）属性。例如，对于SOME/IP部署，我们为每个服务实例定义了一个ID。此服务实例ID需要在SOME/IP服务接口ID上下文中明确（这在整个车辆上下文中是明确的）。】（RS_METH_00206，RS_-METH_00203）

2.9.3 关联内容元素

软件集群设计描述中最突出的内容之一是通过进程设计描述对可执行软件的参考。

• 进程设计描述是一个进程的设计级表示，即在目标机器上相应的可执行文件（软件图像）的一个实例。
• 请注意，应用程序设计描述、可执行的描述和进程设计描述是应用程序设计的可交付成果。

软件集群设计描述的一个重要方面是，应该应用什么诊断提取物。

• 在开发过程的早期阶段，有意地可以引用多个诊断设计，以支持诊断堆栈的分散配置（例如，部分由OEM完成，部分由供应商完成）配置。
• SW集群设计说明包含一个物理诊断地址和任意数量的功能诊断地址。这些信息通常来自OEM，作为合同的一部分
• 关联诊断地址和贡献（根据诊断设计的诊断贡献描述考虑适用的 DEXT 内容，另请参见第 2.6 章诊断设计）可以在大纲软件集群设计期间或之后完成。

此外，关联内容元素还需要注意软件集群设计描述范围内的所有所需的可上传元素（如机器设计、过程设计描述等）。已在相关的可上传元素中注册。

2.9.4 软件集群设计使用场景（自上而下）

图2.30显示了在一个自上而下的使用场景中，软件集群设计的定制任务和工作产品定义，从系统设计中可用的信息开始。元素包括：

• 定义服务实例，考虑系统拓扑描述中系统设计时已知的所需服务的服务拓扑。

这是一个主要的设计决策：

• 在系统设计时由OEM识别的哪些服务实例应该在当前设计的软件集群中实现。
• 软件集群实现需要哪些附加的支持服务实例。
• 定义具有通信端点的软件集群（除了系统拓扑描述中系统设计时已知的子系统拓扑）在系统设计时确定的软件集群描述。

这将软件集群设计与实际软件设计解耦：

• 软件集群黑框中列出的委派端口（请参见图2.28服务实例映射）标识通信端点。
• 一个或多个应用程序（参与当前设计的软件集群）应实现这些通信端点（以及仅实现这些通信端点）
• 地图服务实例可将软件集群设计链接到相关的应用程序设计（另请参见图2.28)。
• 关联内容以及关联诊断地址和贡献完成了软件集群设计

自顶而下的方法导致为软件集群范围量身定制的工作产品：

• 服务实例描述（以及范围中的服务部署描述）将作为当前设计的软件集群的一部分部署。
• 软件黑盒的软件集群描述
• 服务实例映射结合了服务实例描述和软件集群描述与SW黑盒与来自应用程序设计的具体端口实例。
• 相关项目考虑到相关的可上传元素

请注意应用程序设计和软件集群设计的工作流之间的依赖关系：

• 只有当“软件集群描述”指定了定义包含软件软件组合的可执行文件的通信端点时，应用程序才能开始设计。
• 在应用程序设计中定义软件交互，最好使用服务实例描述。
• 地图服务实例需要应用程序设计的详细的可执行描述和流程设计。

2.9.5 软件集群设计使用场景（自底向上）

图2.31显示了在一个自下而上的使用场景中，软件集群设计设计的定制任务和工作产品定义，从应用程序设计中可用的信息开始。

元素是：

• 定义服务实例，考虑在应用程序设计过程中确定的服务实例和在定义软件交互中使用的provided和required服务实例。
• 定义带有通信端点的软件集群，在定义可封闭的可执行文件，定义可执行运行时行为，并在定义软件交互中使用。映射服务实例的信息在此时点可用。
• 根据应用程序设计期间的可用性，为关联内容元素和关联诊断地址和贡献的关联内容。

自底向上的方法产生了为软件集群范围量身定制的工作产品：

• 服务实例说明和服务部署说明
• 软件黑盒的软件集群描述
• 服务实例映射
• 关联的可上传元素的关联项

2.10 软件集群集成

图2.32和2.33给出了软件集群集成范围内的任务和工作产品的概述。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.10章）。

AUTOSAR自适应平台的一个关键特性是能够在给定的机器上扩展软件，而不必重新刷写整个ECU-HW。相反，软件包会被上传到机器上，并通过UCM进行安装。

软件的集成和部署（在自适应平台上）是指使指定软件在特定机器上运行所必需的所有活动，由其硬件、连接网络、操作系统和（某些）平台级自适应软件决定，以满足所有要求。

请注意，一个可上传的软件包不仅包括（可执行的）软件本身，而且还包括在之前安装的AUTOSAR环境中，在目标机器上安装和运行该软件所需的清单内容。软件集群集成的主要活动有：

• 构建可执行软件以获得相关的自适应软件二进制制（见下文为测试环境构建软件一章）
• 配置软件集群以获得所包含的应用程序级和平台级自适应软件实体的软件集群描述。包含：

• • 定义执行清单得到执行清单（见下面章节创建执行清单）
  • 如果平台集群包含平台级自适应软件，则定义平台模块配置(参见下面章节创建平台模块配置）
  • 如果软件集群包含应用程序级自适应软件，则创建或完成服务实例清单（参见下面章节创建或完成服务实例清单）
  • 集成诊断导致自适应SW的诊断映射(见下文，章节集成诊断)主要输入来自软件集群设计描述（参见第2.9章软件集群设计）

2.10.1 为测试环境构建软件

集成时间活动为测试环境构建软件（另请参见[TR_AMETH_00205])适用于应用程序级和平台级的自适应软件。

为测试环境构建软件预期并启用部署时间活动为目标运行时环境构建软件（参见2.11软件打包）：

• 主要输入来自应用程序设计描述（参见2.4应用程序设计）和自适应软件实现（参见2.5的自适应软件实现），使用自适应软件源代码和/或自适应软件对象代码，最终提供一些自适应软件生成项和自适应软件构建配置。
• 集成商根据应用程序设计描述中的可执行文件描述，添加构建（自适应的）可执行文件所需的必要信息（参见[TR_AMETH_00018]）

这包括开发或最终确定COM的序列化属性（请参见[TR_AMETH_00016]），以及生成粘合代码，例如生成服务代理和骨架（请参见[TR_AMETH_00017]）。

• 产生的工作产品是：每个可执行文件在软件集群描述和/或库中指定的自适应软件二进制和相关的诊断管理器二进制。

[TR_AMETH_00205]{草案}集成软件【集成商将将源码和/或对象代码文件作为自适应软件实现，并将它们绑定在一起，以构建针对特定机器的（自适应）可执行文件。此活动不包括实例化，即将可执行文件绑定到进程的上下文。】（RS_METH_00202，RS_METH_00032）

[TR_AMETH_00016]{draft}序列化属性的开发‘【需要描述服务接口中的数据如何序列化以实现网络上的传输。特别是，这对于经典平台和自适应平台之间通过SOME/IP进行的通信非常重要。

对于服务接口，将定义序列化的属性。对于SOME/IP，这包括对齐、可在数组或结构前面添加的长度字段的配置等。基于这种序列化配置，序列化代码可以在软件开发过程中生成为自适应软件生成项，也可以在集成过程中生成为自适应软件胶水代码】

[TR_AMETH_00017]{草案}服务代理和框架的实现。【服务代理和骨架签名将在实际软件开发开始之前作为服务接口的头文件生成，并且（很可能）可以作为自适应软件生成的项目生成，并在自适应软件对象代码中使用。

服务代理和骨架的实现应（最好）在集成期间作为自适应软件胶水代码生成，并考虑到适用的序列化属性。

】

[TR_AMETH_00018]{DRAFT}构建（自适应的）可执行文件。【

（自适应的）可执行文件可以基于应用程序级或平台级的自适应软件对象代码来构建，并且各自的主要功能是自适应软件源代码的一部分。 此外，自适应软件胶水代码-例如，具有序列化源代码、服务代理和骨架实现等。–和所有必要的库都被生成、编译并链接到一个可执行文件中。】（RS_METH_00202，RS_METH_-00066，RS_METH_00042）

2.10.2 创建执行清单

集成时间活动定义执行清单适用于应用程序级和平台级的自适应软件。

• 主要输入来自软件集群设计说明（参见第2.9章软件集群设计）
• 集成商收集并指定所需信息，以便执行管理器始终启动和停止软件集群中标识的功能组的可执行文件，请参见[TR_AMETH_00004]、[TR_AMETH_00022]、[TR_AMETH_00024]、[TR_AMETH_00025]和[TR_AMETH_00026]。
• 由此产生的工作产品是：执行清单与功能组配置和流程配置

[TR_AMETH_00004]}执行清单的创建 【集成活动定义执行清单在执行清单中指定了如何通过操作系统进程实例化自适应软件的可执行文件

• 实例化意味着将（自适应的）可执行文件绑定到操作系统的特定进程的上下文。
• 执行清单的一个主要部分是流程配置，它定义了适用的启动配置、与功能组的关联和进一步的依赖关系。
• 根据适用的功能组状态，不同的进程可以使用不同的启动配置启动相同的可执行文件。
• 进一步介绍了一下，执行清单还可以定义进程及其状态之间的依赖关系

】

[TR_AMETH_00022]{草案}功能组状态的定义。【功能组配置将功能组定义为一组可能具有运行时相互依赖关系的内聚可执行实例（即进程）的状态机。功能组本身并不依赖于进程，相反，每个进程只指定它与一个功能组的关联（即，进程与函数组的绑定是排他的）。平台级自适应软件的进程可以使用一个名为“MachineFG”的标准化功能组来依赖于当前的机器状态，详情请参见[6]中的[TPS_MANI_01330]。】

[TR_AMETH_00024]{draft}（自适应）可执行文件的实例化【根据进程配置定义在特定机器上针对特定目的的（自适应）可执行文件的实例化。一个可执行文件可以以任意顺序以不同的启动行为实例化多次。如果同一可执行文件的多个实例应并发运行，则需要多个进程。】

[TR_AMETH_00025]{draft}进程启动行为的定义【对于每个进程，启动行为可以依赖于同一功能组的一个或多个状态。因此，与第二个功能组状态相比，进程在一个功能组状态下可能具有不同的启动行为。例如，这个行为可以根据调度优先级或对其他进程的执行依赖关系而有所不同。如果一个（自适应）可执行文件在多个进程中运行，多个功能组可能有效（RS_METH_00203）

[TR_AMETH_00026][{draft}执行清单的定义【执行清单指定流程配置：

• 关联的关联可执行文件的启动配置
• 与一个函数组的关联依赖于其功能组状态
• 与其他进程的依赖关系
• 超时和资源需求
• 调度策略和确定性的客户端选项

[TR_AMETH_00216]{草案}将进程映射到一个特定的机器。【进程配置是特定于机器的，因此执行清单应包括一个进程到机器的映射。】

2.10.3 创建平台模块配置

集成时间活动定义平台模块配置适用于平台级自适应软件，并将平台模块配置添加到目标机器清单中。因此，定义平台模块配置与定义机器清单密切相关（请参见2.8机器清单）。各种平台级软件集群自适应软件需要一个机器特定的平台模块配置：

COM=通信管理加密

DoIP =诊断通过互联网协议

GTS=（全球）时间同步

DLT =日志和跟踪

IAM =身份访问管理器

IDS =入侵检测系统

NM =网络管理

OS =操作系统

PER =持久性

PHM =平台运行状况管理

UCM =更新和配置管理，然后与软件集群描述相关联。平台模块配置的内容是平台模块特有的，表示平台模块的运行时配置。

2.10.4 创建或完成服务实例清单

集成时间活动“创建或最终确定服务实例清单”可配置应用程序级（最终还有平台级）自适应软件的通信端点。

• 主要输入来自SW集群设计描述（参见第2.9章软件集群设计），并根据设计时可用的信息配置了服务实例描述和服务实例映射。
• 集成商指定服务实例清单

• • 根据系统拓扑描述中适用的服务拓扑描述中的服务实例ID（参见第2.2章系统设计）来确定服务实例ID。
  • 根据之前匹配映射的进程设计描述的进程配置（参见第2.10.2章创建执行清单）增强了服务实例映射

[TR_AMETH_00028]{DRAFT}服务实例的配置【基于系统拓扑描述（最好是在系统设计时由OEM共享），集成商定义了已部署的服务接口的实例，并决定是否提供或使用了服务实例。为了设置面向服务的通信服务实例清单，其中包括用于搜索或提供条件的服务发现属性。例如，对于SOME/IP，为每个提供的服务实例定义了一个ID。此ID在车辆中应是唯一的（或如果甚至在车辆之外也涉及空中通信）。对于所需的服务实例，SOME/IP允许指定所需的服务实例ID（当然应该在某个地方提供）.】（RS_METH_00206，RS_METH_00203）

[TR_AMETH_00029]从服务实例到机器的映射。【provided和必需的服务实例被分配给将托管可执行它们的可执行文件的计算机。

本机器映射服务实例实际上考虑了机器适用的通信连接器，其中包括通信端点的技术特定属性。例如，对于SOME/IP，本文描述了客户端和服务器的TCP和IP配置。

】

[TR_AMETH_00033]{draft}服务实例到自适应软件端口的映射 【

服务实例需要通过服务实例到端口原型映射映射到应用程序级（最终也是平台级）自适应软件中的表示，该映射还指定了公开端口的可执行文件的操作系统进程。

这种映射将服务实现与其配置解耦，并允许将部署的自适应软件自适应到具体的服务拓扑。

】

2.10.5 集成诊断

将诊断映射与进程设计关联起来：特定应用程序软件的不同实例可能需要不同的诊断映射。因此，需要建立一个特定的诊断映射和一个特定的进程（设计）之间的关系。

这些映射可能是在与诊断设计相关的活动中准备好的(见第2章。6诊断设计)，并在集成诊断中完成，

• 将诊断清除条件映射到端口
• 将诊断启用条件映射到端口
• 将诊断事件映射到端口
• 将诊断通用服务映射到端口
• 将诊断指示器映射到端口
• 将诊断存储器目标映射到端口
• 将诊断操作周期映射到端口
• 将诊断安全级别映射到端口
• 将诊断服务数据标识符映射到端口
• 将诊断软件服务映射到端口

结果现在完全填充了自适应软件的诊断映射。

[TR_AMETH_00213]{DRAFT}将诊断映射与可执行文件的实例联系起来。【特定应用软件的不同实例（即基于同一可执行文件的不同进程）可能需要不同的诊断映射。因此，需要建立一个特定的诊断映射和一个特定的进程之间的关系。由于设计中的进程还不存在，所以（元）模型元素进程设计可以作为一个代理。

此分配可能独立于设计诊断映射的步骤，并且可以在集成诊断中的最后一个额外步骤（将诊断映射与过程设计关联）中完成。

此步骤将部分填充的自适应软件的工件诊断映射和工件过程设计描述作为输入，并生成自适应软件的诊断映射。

】

2.11 软件打包

图2.34给出了在软件包装范围内的任务和工作产品的概述。请在自适应方法库中找到这些任务和工作产品的详细定义（见第3.11章）。

软件集群（作为软件集群集成的结果）本身并不足以安装。实际上，软件集群被包装到一个自适应软件包中，该软件包至少有部分标准化的清单格式（软件软件包描述）。软件集群的语义和自适应软件包的语义之间的区别在于，软件集群关注的是软件本身的结构，而创建自适应软件包是为了处理软件安装的部署方面。

主要活动是：

• 定义软件包得到自适应软件包，包含软件包的描述，自适应软件二进制文件，诊断管理二进制文件。参见[TR_AMETH_00006]，[TR_AMETH_00206]，[TR_AMETH_00218]，[TR_AMETH_00219]，[TR_AMETH_00222]
• 指定更新活动得到更新活动描述。参见[TR_AMETH_00220]，[TR_AMETH_00221]
• 执行实际软件更新。参见[TR_AMETH_00031]，[TR_AMETH_00223]，[TR_AMETH_00224]，[TR_AMETH_00225]

[TR_AMETH_00224]}自适应软件包的管理【一旦创建了软件包描述和软件包有效负载，如自适应软件二进制和诊断管理器二进制，它们通常可以通过自适应软件包部署到该领域的专用自适应机器上

为了做到这一点，自适应软件包可以例如被存储到位于后端服务器上的软件包的存储库中。

数据库可以支持自适应软件包存储库的管理。

由于自适应软件包的管理是OEM的一项固有任务，并且在公司之间会有所不同，因此该活动将不会进一步详细说明

】

[TR_AMETH_00031]{DRAFT}设置一个初始机器。【此活动的目的是获得一台初始建立的机器。“最初设置”意味着在这里，机器可以通过自适应软件包上传和安装额外的软件。为此目的，至少平台模块UCM和相关模块（如诊断通信模块）需要在最初设置的机器上运行。因此，该活动将（至少）将包括以下任务：

• 在选定的目标（机器）上安装选定的操作系统。
• 在已安装的操作系统上安装所有必要的平台模块，以便能够通过自适应软件包来执行上传和安装额外的应用软件。

为了能够执行此活动，需要进行以下输入：

• 自适应平台操作系统
• 通过“机器清单”进行的配置设置
• 设计文件，比如机器设计
• 应安装的平台和应用程序模块的可执行文件
• 应安装的平台和应用模块的执行清单和服务实例清单
• 自上传和安装过程以来，通过诊断（机器）提取物获得的诊断信息可能会使用诊断环境

】

2.11.1 定义软件包

[TR_AMETH_00006]{应用软件的部署 【软件通过自适应软件包部署到机器（即部署到特定的自适应AUTOSAR平台实例）。

这意味着：

1. 相关的软件工件需要编译、构建和添加为软件软件包有效负载，如自适应软件二进制和诊断管理器二进制
2. 自适应软件包由特定于oem的后端服务器提供，以便现场的机器可以访问

】

[TR_AMETH_00206]{草案}创建一个自适应的软件包 【为了获得一个自适应软件包，需要获得以下活动/任务：

• 创建一个软件软件包描述
• 收集属于一个软件集群的所有软件产物描述、构建它们
• 在任何类别的软件集群描述之间的模型依赖关系
• 开发安装指令
• 创建自适应软件包
• 管理自适应软件包（任何类别）的数据库

】

[TR_AMETH_00218]{DRAFT} 创建初始软件包描述 【

此步骤的主要输入是通过软件集群设计描述给出的 OEM 要求。 因此，此任务将创建一个新的软件包描述，并将给定软件集群设计描述的结构和条目传输到新创建的软件包描述中】

[TR_AMETH_00219] {DRAFT} 收集属于软件集群的所有软件产物，结构和建模它们【根据新创建的软件包描述的软件集群设计描述，此步骤包括以下子任务：

• 识别必要的（软件）交付物
  • 识别必要的（软件）产物为了构建自适应软件包，也包含他们的版本

• • 检查，是否有必要的和实际的子软件集群之间的偏差（通过聚合工件和版本），如有必要，解决它们，并相应地重新建模软件软件包描述
  • 检查，要求的（根）软件集群描述（通过其聚合的子软件集群和版本）之间是否存在差异。
• 收集子软件集群的归属（软件）交付物
  • 将子软件集群的归属（软件）产物收集到单独的篮子（子软件集群），以准备创建软件包描述的最后一步
  • 执行接收检查（可选）
  • 将输入的产物存储到存储库中

[TR_AMETH_00222]创建自适应软件包【自适应软件包的格式以及更新策略，即您是进行完整的更新还是增量更新，都是特定于实现的。这两个问题都不会由AUTOSAR指定。

因此，该活动处理将软件集群描述和软件软件包描述编译成自适应软件包。

由于AUTOSAR没有指定自适应软件包的外观，因此将此活动分解为任务也会特定于特定的oem及其供应商】

2.11.2 指定更新活动

[TR_AMETH_00220]}任何类别的软件集群之间的模型依赖关系 【软件集群设计描述可能已经由OEM的要求给出了相同或不同类别的软件集群之间的依赖关系。对软件集群的依赖关系是通过它们的标识（名称）和版本来指定的。

因此，相应的软件集群设计描述将是该活动的一个输入

然而，依赖关系可能会在开发过程中发生变化，而活动需要考虑它。

因此，此任务描述至少通过以下子任务处理依赖关系：

• 检查由各自的软件集群设计描述给出的相同或不同类别的软件集群描述之间的依赖关系是否仍然有效
• 确定任何类别的软件集群描述之间的实际依赖关系和所需依赖关系之间的更改
• 如有必要，根据上述两个任务的结果重新建模软件软件包描述

】

[TR_AMETH_00221]开发安装说明【安装指令控制在自适应软件包更新期间UCM的行为。安装说明可以是“添加/更新”，意思是安装一个包，也可以是“删除”，表示应该从机器上卸载和删除一个包。安装说明根据软件集群说明定义，独立于其类别。具体信息请参见[13，更新和配置管理规范]

因此，此任务可能包括以下子任务：

• 根据软件集群说明（属于任何类别）指定安装说明
• 制定更新活动（可选的）

具体的安装说明是软件软件包说明的一部分】

[TR_AMETH_00225]为现场机器提供自适应软件包【后端服务器还可以提供某种（复杂的）业务逻辑。例如，它可以使测试人员不仅能够访问特定自适应软件包的特定版本，而且还可以提供不同版本的自适应软件包的更改集。

一个具体的上传程序的处理在某种程度上是由诊断标准规定的。但是，如前所述，并没有指定自适应软件包的格式以及更新策略。oem之间在处理和程序上存在差异，因此，这一活动不会进一步细分。

】