《AUTOSAR_TR_AdaptiveMethodology》翻译连载（二）

2 AP用例 Use Cases for the Adaptive Platform

本章节根据[5，软件过程工程元模型规范] 描述了基于AP平台搭建系统的主要用例，该用例与任务和工作产品相关。

This chapter describes the main use cases for building a system based on the AUTOSAR Adaptive Platform in terms of tasks and work products according to [5, Software Process Engineering Meta-Model Specification].

[TR_AMETH_00200] 使用AP平台方法论的开发领域【AP方法论应由以下开发领域构成:

[TR_AMETH_00200] Domains of development utilized for the methodology of the AUTOSAR Adaptive Platform 【The methodology of the Adaptive Platform shall be structured by the following domains of development:

• 需求分析 Analysis
• 架构设计 Architecture and Design
• 系统开发 System Development
• 软件开发 Software Development
• 集成和部署 Integration and Deployment 】(RS_METH_00018, RS_METH_00032)

[TR_AMETH_00204]{DRAFT}开发系统【CP平台方法论的规范[1]也应适用于AP平台(遵循其一般含义):

[TR_AMETH_00204]{DRAFT} Develop the System 【The subsequent specifications of the Classic Platform methodology [1] shall also be applicable for the Adaptive Platform (by following their general meanings):

• 系统的开发([TR_METH_01046])和(开发)整个系统([TR_METH_01048])，主要是关于VFB的细化，具体包括ecu实例的定义，网络拓扑的定义，ecu实例上软件组件的部署，车辆软件架构所需的扩展，指定机器的添加以及机器与硬件ECU的相应映射。
• Development of the System ([TR_METH_01046]) and (Develop) the overall system ([TR_METH_01048]), which talk about the refinement of the VFB by the definition of a topology of ECU-Instances and networks and the deployment of software components onto ECU-Instances, with the extensions necessary for the Vehicle Software Architecture and the additions to specify Machines and the corresponding mapping of Machines to ECU-HWs.
• 两阶段开发方法([TR_METH_01047])和组织之间的交互([TR_METH_01049])，它构建了不同方之间的协作，例如oem和供应商之间的协作。
• Two phase development approach ([TR_METH_01047]) and Interaction between organizations ([TR_METH_01049]), which structures the collaboration between different parties, like between OEMs and their suppliers.】

[TR_AMETH_00251]{DRAFT}变量处理【CP的变量处理机制仅适用于AP的配置。

[TR_AMETH_00251]{DRAFT} Variant handling dThe variant mechanisms as known from CP apply to AP only for configuration items shared with CP.

与AP配置相关的设计阶段都隐藏着代码生成阶段和预编译阶段。

Any design time related AP configuration item has implicitly a latest binding time of code-generation or pre-compile time.

AP的配置被定义成manifest内容，其能影响后期构建并改变软件运行时的行为：AP 软件行为的改变可以仅仅通过更改这些manifest文件。】(RS_METH_00062, RS_METH_00074, RS_METH_00075, RS_-METH_00076)

Any AP configuration item defined as manifest content is subject to post-build and runtime variance: the behavior of an Adaptive Software can be changed by replacing manifest files only.】(RS_METH_00062, RS_METH_00074, RS_METH_00075, RS_-METH_00076)

图2.1显示了Adaptive Platform方法论的主要领域，包括上层架构，设计，集成，应用层实施和软件部署。

Figure 2.1 shows the main areas of the Adaptive Platform methodology reaching from High level architecture via several design and integration steps to application implementation and SW packaging.

 2.1 系统- 上层架构

一辆典型的汽车一般会配备多个ECU

-软件符合CP标准的ECU

-软件符合AP标准的ECU

-非AUTOSAR 软件的ECU

A typical vehicle will be most likely equipped with ECUs hosting
– ECU-Instances with software developed for the AUTOSAR classic platform (CP)
– and Machines with software developed for the AUTOSAR adaptive platform (AP)
– and eventually also HW entities with non-AUTOSAR software.

因此，整个车辆的软件架构和系统设计必须涵盖所有这些ECU，同时考虑这些ECU之间的通信，包括以下几个方面：

• AUTOSAR AP和CP的硬件和软件实体之间的通信
• AUTOSAR和非AUTOSAR的硬件和软件实体之间的通信

The software architecture and System design for the entire vehicle has therefore to cover all these ECUs as well as the communication between these ECUs, considering – communication between AUTOSAR AP and CP hardware and software entities – communication between AUTOSAR and non-AUTOSAR hardware and software entities).

图2.2概述了高级架构范围内的任务和工作产品。请在AP方法论库中查找这些任务和工作产品的详细定义（请参阅第3.1章）。

Figure 2.2 gives an overview of the tasks and work products in scope of High Level Architecture. Please find the detailed definitions of these tasks and work products in Adaptive Methodology Library (see chapter 3.1).

在自顶向下的方法中，与定义高级架构相关的活动始于开发功能架构和/或开发抽象平台规范，最终将导致功能架构和抽象平台规范对高级架构的贡献:

 In a top-down approach the activities related to Define High Level Architecture start with Develop Function Architecture and/or Develop Abstract Platform Specification resulting in the Function Architecture and Abstract Platform Specification contributions to High Level Architecture:

1.开发功能架构将重点放在车辆功能上，抽象出其未来的具体实现细节：一位电气/电子系统架构师评估并规定特定电气/电子车辆项目或项目系列所需的车辆功能、特性和需求。结果得到的功能架构（见[TR_AMETH_00201]）描述了表示执行特定车辆功能所需的功能网络，但可能是非AUTOSAR文档（或模型）。

1.Develop Function Architecture puts the focus on vehicle functions abstracting from their future implementation: An E/E system architect evaluates and specifies vehicle functions, features and requirements necessary for a specific E/E vehicle project or project family. The resulting Function Architecture (see [TR_AMETH_00201]) is likely a non-AUTOSAR document (or model) describing function networks representing functionalities that are needed to execute particular vehicle functions.

2.开发抽象平台规范聚焦于车辆功能及其交互的平台无关组件模型。由此得出的抽象平台规范确定了以下内容：

• 忽略其未来实现，将抽象组件标识为AUTOSAR AP / CP / 非AUTOSAR软件实体或硬件实体。
• 基于抽象的PortInterface描述确定通信终点（见[TR_AMETH_00001]）。
• 忽略其未来实现，通过AUTOSAR AP服务发现、CP连接器或跨平台通信建立通信终点之间的连接。

2. Develop Abstract Platform Specification puts the focus on a platform independent component model for vehicle functions and their interaction.
The resulting Abstract Platform Specification identifies 

abstract components disregarding their future implementation as AUTOSAR AP / CP / non-AUTOSAR software entities or as hardware entities.
communication endpoints based on abstract PortInterface descriptions (see [TR_AMETH_00001]).
connections between communication endpoints disregarding their future implementation via AUTOSAR AP service discovery or CP connectors or cross platform communication.

3. 开发车辆软件架构将重点放在面向任意组合的AUTOSAR AP或CP的软件组件上。由此得出的车辆软件架构（见[TR_AMETH_00202]）：
- 将功能分配给AP和CP平台。
- 定义所需的AP和CP平台内部以及跨平台的通信，以及与非AUTOSAR实体进行“外部”通信的需求。

3. Develop Vehicle Software Architecture puts the focus on software components targeting at AUTOSAR AP or CP in any combination.  The resulting Vehicle Software Architecture (see [TR_AMETH_00202])
allocates functionalities to AP and CP platforms
and defines the required AP and CP intra and cross platform communication as well as the demand for "external" communication with non-AUTOSAR entities.

图2.3概述了从功能架构到车辆软件架构的推导过程。

请参阅AP和CP软件架构的解释性文件[7，《AP平台软件架构解释》]和[8，《分层软件架构》]。

Figure 2.3 outlines the derivation of Vehicle Software Architecture from Function Architecture.
Please see also explanatory documents for AP and CP software architecture [7,Explanation of Adaptive Platform Software Architecture] and [8, Layered Software Architecture].

开发车辆硬件架构聚焦于承载车辆软件架构中软件实体的电子控制单元（ECU）。由此得出的车辆硬件架构指定了AP（机器）、CP（ECU实例）和通信基础设施所需的ECU及其硬件资源。

图2.6概述了车辆软件架构中的软件实体与车辆硬件架构中的硬件实体之间的关联。

Develop Vehicle Hardware Architecture puts the focus on ECUs hosting the software entities from Vehicle Software Architecture. The resulting Vehicle Hardware Architecture specifies the required ECUs with their HW resources for AP (Machines), CP (ECU-Instances) and communication infrastructure.
Figure 2.6 outlines the association of software entities from Vehicle Software Architecture to hardware entities from Vehicle Hardware Architecture.

[TR_AMETH_00001]{草稿} 标识抽象的端口接口【这个活动指定了在抽象平台规范中通信终点所需的PortInterface的能力。

[TR_AMETH_00001]{DRAFT} Identify Abstract Port Interfaces 【This activity  specifies  capabilities of PortInterfaces required for communication endpoints in Abstract Platform Specification.

在[9，《抽象平台规范说明》]中定义的抽象PortInterfaces指定了以下内容：

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

The abstract PortInterfaces as defined in [9, Specification of Abstract Platform] specify
commands as an abstracted form of AP methods and CP client/server operations
indications as an abstracted form of AP events or fields and CP sender/receiver data prototypes
attributes as an abstracted form of AP fields and collected CP client/server operations,  sender/receiver data prototypes
all using abstracted data types outlining the demand for future concrete AP and CP data types.

请注意，这与以下事项无关：
- 分配给特定网络绑定的任何任务
- 分配给特定平台软件组件类型的任何任务，这可以视为开发AP或CP软件实体的准备步骤，与上述事项是相互独立的。

Please be aware that this is independent of
– any assignment to a specific network binding,
– any assignment to platform specific software components types and may be seen as a preparation step towards the development of AP or CP Software entities.

这个活动是可选的，并不会在自底向上的方法中显示出来。( RS_METH_00201，RS_METH_00032)

This activity is optional and will not show up in a bottom-up approach.c(RS_-METH_00201, RS_METH_00032)

2.1.1 整体系统图 Overall System View

[TR_AMETH_00201]{DRAFT} 开发一个功能架构【工程师，例如E/E系统架构师，可以在“开发功能架构”活动中评估特定E/E车辆项目所需的功能和要求，以形成适当的功能架构。
[TR_AMETH_00201]{DRAFT} Develop a Function Architecture 【An engineer, e.g.
an E/E system architect, may evaluate features and requirements necessary for a specific
E/E vehicle project in order to form an appropriate Function Architecture during the activity Develop Function Architecture.

功能架构由一系列车辆功能及其接口和相应的连接组成。
The Function Architecture consists of a number of vehicle functions with their interfaces and the corresponding connections.

在分析步骤中，车辆功能可以被详细分解为多个功能块，这些功能块最终会在派生的抽象平台规范中形成抽象的软件构件（SWCs）：
- 功能块封装了特定的功能。请注意，功能块可以是软件、硬件或两者混合实现。

- 功能块的组合表示执行特定车辆功能所需的功能集合。

In an analysis step, a vehicle function may be detailed into a number of function blocks which later lead to the abstract SWCs in the derived Abstract Platform Specification:
A function block encapsulates a specific functionality.
Note, that function blocks may be realized in software or hardware or as a mix of both.

A composition of function blocks represents the functionality that is needed to execute a particular vehicle function.

这个活动是可选的，并不会在自底向上的方法中显示出来。( RS_METH_00201，RS_METH_00032)

This activity is optional and will not show up in a bottom-up approach.c(RS_-METH_00201, RS_METH_00032)

[TR_AMETH_00202]{DRAFT} 开发车辆软件架构【工程师，例如软件架构师，可以在执行“开发车辆软件架构”活动时将功能架构和/或抽象平台规范作为输入，推导出相应的车辆软件架构。

 [TR_AMETH_00202]{DRAFT} Develop a Vehicle Software Architecture dAn engineer, e.g. a software architect, could take the Function Architecture and/or a Abstract Platform Specification as input to derive a corresponding Vehicle Software Architecture while executing the activity  Develop Vehicle Software Architecture.

车辆软件架构提供了在E/E车辆系统内的所有AUTOSAR软件实体及其通信关系的专用视图，包括：
- AP平台（AP SWCs）的AUTOSAR软件组件，
- CP平台（CP SWCs）的AUTOSAR软件组件，
- 使用AP和/或CP SWCs任意组合的AUTOSAR软件组合，
- 软件组件之间的通信
- 在车辆软件架构内部的通信，包括
    - AP SWCs之间的AP（基于服务）通信，
    - CP SWCs之间的CP（基于信号）通信，
    - AP和CP SWCs之间通过SOME/IP进行基于服务的通信，
    - AP和CP SWCs之间通过信号/服务转换进行通信，
  - 与外部软件实体（例如不在车辆软件架构范围内的非AUTOSAR SWCs）的通信。

此活动是可选的，并且在自下而上的方法中不会显示。】(RS_-METH_00032)

The Vehicle Software Architecture provides a dedicated view of all AUTOSAR software entities and their communication relations within the E/E vehicle system, with
AUTOSAR software components of the Adaptive Platform (AP SWCs),
AUTOSAR software components of the Classic Platform (CP SWCs),

AUTOSAR software compositions with arbitrary combinations of AP and/or CP
SWCs,
the communication between software components
        – local to Vehicle Software Architecture with
         adaptive (i.e. service oriented) communication between AP SWCs
         classic (i.e. signal based) communication between CP SWCs
         service oriented communication between AP and CP SWCs via SOME/IP
         communication between AP and CP SWCs via signal/service translation
        – with external software entities (e.g. non-AUTOSAR SWCs not covered by Vehicle Software Architecture).
This activity is optional and will not show up in a bottom-up approach.】(RS_-METH_00032)

请注意，分配给不同ECU的SWCs可以通过通信基础设施交换数据。
SWCs的通信端点是由特定的PortInterface定义的端口类型。在AP平台的情况下，接口被表达为针对个别服务导向通信用例定制的Service Interfaces。

Please be aware that SWCs allocated to different ECUs may exchange data through the  communication  infrastructure.
The communication end points of SWCs are Ports typed by a particular PortInterface definition. In case of the Adaptive Platform, interfaces are expressed as Service Interfaces tailored for the individual service oriented communication use cases.

2.1.2 提取子系统 Derive Sub-Systems

[TR_AMETH_00203]{DRAFT} 导出子系统【子系统是整体技术系统的一个简化部分，重点关注其中相关的方面。可行的用例包括：

• 将纯AUTOSAR CP平台子系统导出为VFB视图。
• 导出纯AUTOSAR AP平台子系统。
• 导出混合AP/CP平台子系统的视图。

[TR_AMETH_00203]{DRAFT} Derive Sub-Systems dA sub-system is a reduced part
of the overall technical system and emphasizes on relevant aspects of it. Feasible use
cases are
derive a pure AUTOSAR Classic Platform sub-system as VFB view
derive a pure AUTOSAR Adaptive Platform sub-system
derive a view on a mixed Adaptive/Classic Platform sub-system.

分解为子系统的动机包括：

- 功能方面，例如根据车辆功能范围来界定子系统。
- 技术方面，例如根据AUTOSAR平台来界定子系统。
- 数据流方面，例如根据预期的子系统交互来界定子系统。

Motivations for the decomposition into sub-systems are
functional aspects, e.g. scoping of sub-system by vehicle functions
technology aspects, e.g. scoping of sub-system by AUTOSAR platform
logistics, e.g. scoping of sub-system by intended sub-contracting

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

该行为可选。】（This activity is optional.c(RS_METH_00078, RS_METH_00079)）

Any sub-system may interact with other sub-systems: in such cases software components  allocated to different sub-systems communicate. To support this the subsystem shall include PortInterface definitions at least for the AUTOSAR Adaptive and Classic Platform software component ports interfacing to other sub-systems.

This activity is optional.(RS_METH_00078, RS_METH_00079)

整车软件架构涵盖了所有AUTOSAR软件实体。自顶向下方法中的下一步与分解为子系统有关，最终达到特定平台的子系统（参见[TR_AMETH_00203]）为止，可以包含任意的中间层。

 The overall Vehicle Software Architecture covers a whole System considering all AUTOSAR software entities of a vehicle. The next steps in a top-down approach are related to the decomposition into sub-systems - eventually with arbitrary intermediate levels - until platform specific sub-systems (see [TR_AMETH_00203]) are reached.

• 混合的AP和CP子系统将按照有限范围的车辆软件架构进行处理（仅涵盖车辆中的部分AUTOSAR软件）。
• 从车辆软件架构中提取的CP子系统涵盖了车辆中任意CP ECU实例的CP软件。这个CP系统将按照CP方法论进行处理，逐步分解为多个ECU的系统提取、单个ECU的系统提取和ECU提取的步骤。
• 从车辆软件架构中提取的AP子系统涵盖了车辆中任意AP Machines的AP软件。这个AP系统将按照AP方法论进行处理，从Machine（设计）提取逐步分解到软件集群提取的过程。
• 至少提取的子系统的通信端点需要（以技术为基础的）PortInterface描述（作为[TR_AMETH_00001]中抽象PortInterfaces的具体化）。
• A mixed AP and CP sub-system will be handled like Vehicle Software Architecture with limited scope (covering only parts of the AUTOSAR software in a vehicle).
• A CP sub-system extracted from Vehicle Software Architecture covers CP software of arbitrary CP ECU-Instances in a vehicle. This CP system will be handled as per CP Methodology with the step by step decomposition into System Extract for multiple ECUs, System Extract for a single ECU and ECU Extract.
• A AP sub-system extracted from Vehicle Software Architecture covers AP software of arbitrary AP Machines in a vehicle. This AP System will be handled as per AP Methodology with the decomposition into Machine (Design) Extract down to Software Cluster Extract.
• At least the communication endpoints of extracted sub-systems need (outlined but technology specific) PortInterface descriptions (as concretion of the abstract PortInterfaces from [TR_AMETH_00001]).

图2.4概述了从车辆软件架构派生出子系统的过程。请注意，车辆软件架构仅在自顶向下方法的定义高级架构阶段需要。
在自底向上的方法中，车辆软件架构明显是可选的，但可以从单独创建的CP和/或AP子系统进行聚合。

Figure 2.4 outlines the derivation of sub-systems from Vehicle Software Architecture.
Please be aware that Vehicle Software Architecture is required only in a top-down approach at Define High Level Architecture.
In a bottom-up approach the Vehicle Software Architecture is clearly optional but may be aggregated from the individually created CP and/or AP sub-systems.

 在整车软件架构中识别出的AP和CP的软件组件（SWC）需要部署在整车硬件架构中识别出的电子控制单元（ECU）上。

The adaptive and classic SWCs identified in Vehicle Software Architecture need to be deployed on ECUs identified in Vehicle Hardware Architecture:

图2.5概述了将SWC分组为软件集群的过程。
        - 这仅在AP中是强制性的：在这里，SWC被集成到一个可执行文件中，可以部署到特定的Machine上。
        - 对于CP软件，软件集群允许将一组SWC一起部署到特定的ECU实例上。

Figure 2.5 outlines the grouping of SWCs into software clusters.
        – This is mandatory in AP only: here SWCs are integrated to an executable that can be deployed to a specific Machine.
        – For CP software clusters allow a grouping of SWCs to be deployed together to a specific ECU-Instance.

最后，我们可以将软件集群映射到硬件实体。
图2.6概述了从车辆软件架构到车辆硬件架构的AP（Machines）和CP（ECU实例）软件集群的分配过程。

Finally we can map the software clusters to HW entities.
Figure 2.6 outlines the allocation of software clusters from Vehicle Software Architecture to HW entities for AP (Machines) and CP (ECU-Instances) from Vehicle Hardware Architecture.

 整车硬件架构（如图2.7所示）涵盖了车辆中所有ECU的拓扑结构以及互连通信基础设施。这个硬件拓扑结构包括：
- 节点，其表示承载特定CP ECU实例、特定AP Machine或特定组合的物理或虚拟ECU硬件项。
- 节点之间的连接，其表示可能的通信。这使得ECU中的组件能参与所需的通信技术（如CAN或以太网对于CP，SOME/IP对于AP）。
- 用于无线通信的连接（例如，用于车辆对车辆无线通信用例或OTA用例）。

The overall Vehicle Hardware Architecture (as outlined in figure 2.7) covers the topology of all ECUs along with the interconnecting communication infrastructure in a vehicle. This hardware topology consists of
Nodes representing physical or virtual ECU-HW items that host either a specific CP ECU-Instance or a specific AP Machine or a specific combination of these.
Connectors between nodes representing the communication possibilities.
This allows to take part in the communication clusters of the required communication  technologies like CAN or Ethernet for CP and SOME/IP for AP.
Connectors for over-the-air communication (e.g. for vehicle-to-vehicle communication use cases or software update over-the-air use cases).