2.2 系统设计 System Design
图2.8概述了系统设计范围内的任务和工作产品。请参考AP方法论库（见第3.2章）中这些任务和工作产品的详细定义。
Figure 2.8 gives an overview of the tasks and work products in scope of System Design.
Please find the detailed definitions of these tasks and work products in Adaptive
Methodology Library (see chapter 3.2).
主要的输入来自于上层架构中的整车软件架构和整车硬件架构，详见第2.1.2章节。系统设计代表了如何从基于上层架构提取出子系统。
Main inputs are Vehicle Software Architecture and Vehicle Hardware Architecture from High Level Architecture, see also chapter 2.1.2. The System Design represents a – preferably platform specific – sub-system derived from High Level Architecture.
系统设计包括两部分
1、系统拓扑描述是“定义系统拓扑”的任务的结果，旨在精炼车辆软件架构并定义具备所需功能和通信需求的子系统。其中包括以下内容：
The System Design consists of
1. System Topology Description as outcome of task Define System Topology with the intention to refine the Vehicle Software Architecture and to define sub-systems with the required functionalities and their communication needs. This includes:
指定了独立但关联的功能组。在软件集群设计阶段，这些功能组描述了软件集群。
在AP中，功能组是一组具有运行时相互依赖性的连贯的可执行实例（也称为应用程序进程）。
指定了所需通信技术的通信集群的网络连接性，例如CAN或以太网用于CP和SOME/IP用于AP。
对于以太网（当然也包括SOME/IP），网络端点描述定义了参与通信集群的ECU的各个通信连接器的网络地址（作为Internet协议第4版或第6版地址和/或媒体访问控制（MAC）组播地址）。
指定了服务网络作为服务拓扑描述。
Specify groups for distributed but coherent functionality. These function groups will be detailed as SW Cluster Design Descriptions during Software Cluster Design.
In AP the Function Group Description defines a set of cohesive executable instances (aka application processes) likely having run-time interdependencies.
Specify the network connectivity for the communication clusters of the required communication technologies like CAN or Ethernet for CP and SOME/IP for AP.
For Ethernet (and of course also SOME/IP) the Network Endpoint Description defines the network addresses (as Internet Protocol version 4 or version 6 address and/or Media-Access-Control (MAC) multicast address) for the individual communication connectors of ECUs (or to be more precise of the CP-ECU-Instances and AP-Machines) taking part in a communication cluster.
Specify the network of services as Service Topology Description.
这包括服务接口的规范（参见第2.3章节），特定技术服务的定义，服务提供者的实例化，将服务实例分配给CP-ECU实例和AP机器，并最终将服务实例分配给网络端点。
在这之上，还可选择指定服务消费者的实例化以及通过提供的和所需的服务实例连接服务提供者和消费者之间的连接。
请注意，这是从服务提供者和消费者的实际功能中抽象出来的，但它约束了实现的技术。
This includes the specification of service interfaces (see chapter 2.3), the definition of technology specific services 5 6, the instantiation of service providers, the allocation of service instances to the CP-ECU-Instances and AP-Machines and finally also the allocation of service instances to network endpoints.
Optionally also the instantiation of service consumers and the connectivity between service providers and consumers via provided and required service instances may be specified.
Please be aware that this is abstracted from the actual functionality of service providers and consumers but constrains the technology binding of their implementation.
2、根据识别软件集群的任务，生成了一些初始的软件集群设计描述，旨在定义子系统软件架构中的主要构建模块。有关SW集群设计描述的详细信息，请参阅第2.9章节《软件集群设计》。
我们将可能将软件组件分组到软件集群中，以便将软件集群部署到ECU上。对于CP来说，这是一个可选的分组，旨在便于将SWC映射到ECU实例。对于AP来说，这是参与构建可部署到特定机器上的可执行文件的SWC的必需分组。
还请参阅[6,清单规范]中的软件分发章节和[10,系统模板]中的软件集群章节。
2. Some initial SW Cluster Design Description as outcome of task Identify Software Cluster with the intention to define the major building blocks in the sub-system software architecture. See chapter 2.9 Software Cluster Design for the actual elaboration of SW Cluster Design Description.
We shall/may group software components into software clusters with the intention to deploy the software clusters on an ECU. For CP this is an optional grouping to facilitate the mapping of SWCs to ECU-Instances. For AP this is a mandatory grouping of SWCs taking part in the build of executables to be deployed on a specific Machine.
See also chapter Software Distribution in [6, Manifest Specification] and chapter Software Cluster in [10, System Template] .
3、全局时间描述的任务是定义全局时间，旨在参与整车级别ECU的时间同步。在执行分布式车辆功能时，可能需要车辆E/E系统中的多个ECU协同操作。为了实现这一点，所有连接的CP-ECU实例和AP机器之间的全局时间功能集群需要同步到相同的时间基准上。
请参见图2.9的示意图，了解如何通过通信基础设施，使涉及的全局时间功能集群在图中标记为X）可以交换同步消息。
AP的全局时间描述了机器是如何参与车辆的全局时间同步的。这是通过以太网进行的。对于CP，全局时间同步可以通过CAN或以太网进行。
请参阅[6,清单规范]中的时间同步部署章节和[10,系统模板]中的全局时间同步章节。
3. Global Time Description as outcome of task Define Global Time with the intention to take part in the vehicle-wide time synchronization of ECUs.
It may be necessary that several ECUs in a vehicle E/E system need to act in concert while executing a (distributed) vehicle function. To achieve this the global time functional clusters across all connected CP-ECU-Instances and AP-Machines need to synchronize to the same time bases.
Please see in the schematic figure 2.9 Synchronize functional clusters across CP-ECU-Instances and AP-Machines how the involved global time functional clusters (labeled X in diagram) may exchange synchronization messages through the communication infrastructure.
Global Time Description for AP describes how the Machines in scope take part in the Global Time Synchronization of a vehicle. This happens via Ethernet. For CP the Global Time Synchronization may happen via CAN or Ethernet.
See also chapter Time Synchronization Deployment in [6, Manifest Specification] and chapter Global Time Synchronization in [10, System Template].
4、 网络管理描述定义了网络管理任务，旨在参与车辆级网络的唤醒和休眠行为（以及ECU的网络连接器）。
请参见图2.9的示意图，了解涉及的网络管理功能集（在图中标记为X）如何通过通信基础设施交换同步消息，以实现CP-ECU实例和AP机器之间的功能集的同步。
通常，OEM会提供包含所有与车辆中连接的CP-ECU实例和AP机器的网络管理功能集涉及的网络配置。
AP的网络管理描述了机器如何参与车辆的整体网络管理。
另请参阅[6,清单规范]中的TPS_MANI_03166和TPS_MANI_03226以及相关解释，以及[10,系统模板]中的网络管理章节。
4. Network Management Description as outcome of task Define Network Management with the intention to take part in the vehicle-wide wake-up and sleep behavior of Networks (and network-connectors of ECUs).
Please see in the schematic figure 2.9 Synchronize functional clusters across CP-ECU-Instances and AP-Machines how the involved network management functional clusters (labeled X in diagram) may exchange synchronization messages through the communication infrastructure.
Typically an OEM provides the network configuration with all configuration settings
that are relevant for the network management functional clusters across all connected
CP-ECU-Instances and AP-Machines in a vehicle.
Network Management Description for AP describes how the Machines in
scope take part in the overall network management in a vehicle. 8
See also TPS_MANI_03166 and TPS_MANI_03226 and related explanations in
[6, Manifest Specification] and chapter Network Management in [10, System Template].
5、"Signal to Service Translation Description"定义了信号到服务转换任务，旨在定义如何将AP的SOME/IP序列化通信转换为基于信号的CP通信，反之亦然。
详细信息请参阅第2.2.3章节中的《信号到服务转换》。
5. Signal to Service Translation Description as outcome of task Define Signal to Service Translation with the intention to define how SOME/IP serialized communication of AP can be translated into signal based communication of CP and vice versa.
See chapter 2.2.3 Signal to Service Translation for details.
根据需求，上述提到的任务可以以任意顺序执行。
The above mentioned tasks may be executed - as per demand - in arbitrary order.
2.2.1 系统设计用例场景（自顶向下） System Design Usage Scenario (top-down)
图2.10展示了系统设计中定制任务和工作产品定义的情况，它针对的是一个自顶向下的使用场景，目标是针对整车系统描述。这个过程可以从零开始，也可以从某个基线系统描述开始。
Figure 2.10 shows the tailored task and work product definitions of System Design in a top-down usage scenario targeting at a vehicle wide system description. This may start from scratch or from some base line system description.
其中包括以下几个要素：
1. 定义（完整）系统拓扑：
- 将系统分解为子系统。
- 定义功能组。
- 定义网络端点。
- 定义服务拓扑。
2. 为功能组识别软件聚类：
- 在子系统软件架构中定义主要构建模块，用于已识别的软件实体和子系统。
3. 定义系统范围的全局时间：
- 定义整车的ECU全局时间同步，确保所有连接的CP-ECU实例和AP机器都同步到相同的时间基准。
4. 定义系统范围的网络管理：
- 定义整车的网络唤醒和休眠行为，以控制网络连接器的预期唤醒和休眠行为，覆盖所有连接的CP-ECU实例和AP机器的网络管理功能聚类。详情请参见页码为28的第1个列表项中的概述，以及页码为29的第2个列表项和页码为30的第3和第4个列表项中的概述。
这样可以使得跨所有连接的CP-ECU实例和AP机器的网络管理功能集能够按照预期的唤醒和休眠行为来控制整个网络。
Elements are:
Define (complete) System Topology with
– Decompose System into Sub-Systems
– Define Function Groups
– Define Network Endpoints
– Define Service Topology
(see overview in list item 1 on page 28)
Identify Software Clusters for function groups:
Define the major building blocks in the sub-system software architecture (see overview in list item 2 on page 29) for software entities and sub-systems identified in Vehicle Software Architecture, see also [TR_AMETH_00203].
Define system-wide Global Time:
Define the vehicle-wide time synchronization of ECUs (see overview in list item 3 on page 30) .
This enables the synchronization of the global time functional clusters across all connected CP-ECU-Instances and AP-Machines to same time bases.
Define system-wide Network Management:
Define the vehicle-wide wake-up and sleep behavior of Networks (see overview in list item 4 on page 30).
This enables the network management functional clusters across all connected CP-ECU-Instances and AP-Machines to control the network-connectors as per expected wake-up and sleep behavior.
自顶向下的方法会产生以下针对系统范围的工作产品：
1. 系统拓扑描述：
- 完成对系统拓扑的定义，包括子系统、功能组、网络端点和服务拓扑，以满足当前系统设计范围的要求。
2. 全局时间描述：
- 完成对全局时间的定义。
3. 网络管理描述：
- 完成对系统范围的网络管理的定义。
4. 软件聚类设计描述：
- 完成对功能组的软件聚类识别和描述，作为当前系统设计范围下实现功能组的软件聚类的结果。
这些工作产品将有助于对系统范围进行具体描述和规划。
The top-down approach leads to the following work products tailored for Systemscope:
System Topology Description
as outcome of Define (complete) System Topology considering sub-systems,function groups, network endpoints and the service topology as per current system design scope.
Global Time Description
as outcome of Define system-wide Global Time
Network Management Description
as outcome of Define system-wide Network Management
SW Cluster Design Descriptions
as outcome of Identify Software Clusters for function groups identifying and describing the software clusters implementing the function groups as per current system design scope.
2.2.2 系统设计用例场景（自底向上）
图2.11展示了在一个自下而上的设计场景，该场景针对特定AP-Machine的系统设计定制任务和工作产品定义。
Figure 2.11 shows the tailored task and work product definitions of System Design in a bottom-up usage scenario targeting at a Contribution to System Design for a specific AP-Machine.
主要包括以下元素：
- 为机器定义系统拓扑结构，目的是为机器定义子系统及其节点，最终与本地定义机器设计相结合（请参见第2.7.1章节的机器设计使用场景）。
- 在特定机器的范围内概述子系统，以确定涉及的软件群集。
Elements are:
Define the System Topology Contribution for a Machine
with the intention to Define the Sub-System for a Machine and Contribute Network
Endpoints for a Machine
eventually in combination with Define the Machine Design Locally (see chapter
2.7.1 Machine Design Usage Scenario)
Outline the Sub-System in scope of a specific Machine
to identify the SoftwareClusters in scope.
自下而上的方法会生成以下工作产品：
-
软件群集描述：作为针对特定机器范围的子系统概述的结果，用于识别实现当前机器范围内功能组的软件群集。
-
系统拓扑贡献：作为为机器定义系统拓扑结构的结果，考虑到当前机器范围内的功能组、网络端点和服务拓扑。
The bottom-up approach leads to the following work products tailored for Machinescope:
Software Cluster Descriptions
as outcome of Outline the Sub-System in scope of a specific Machine identifying
the software clusters implementing the function groups as per current machine
scope.
System Topology Contribution
as outcome of Define the System Topology Contribution for a Machine considering
function groups, network endpoints and the service topology as per current
machine scope.
2.2.3 信号与服务转换 Signal to Service Translation
图2.12 "信号到服务"的转换概述了在CP平台和AP平台软件实体之间设计面向服务的通信的活动，但前提是（仅当）CP端不能直接完全满足SOME/IP消息格式。
Figure 2.12 Signal to Service Translation outlines the activity of designing the service
oriented communication between Classic and Adaptive Platform software entities, if
(and only if) the CP side does not directly and completely fulfill the SOME/IP message
format.
备注：
- 这个活动的背景是为了实现经典平台（CP）ECU实例和自适应平台（AP）机器之间通过SOME/IP启用面向服务的通信。
- 如果CP按照SOME/IP的方式进行通信，就不需要进行信号到服务的转换。
- 这种情况下：
- CP直接通过以太网进行通信，并符合SOME/IP消息格式。
- 网关将信号（例如CAN信号）转换成SOME/IP消息格式。
- 此外，必须根据[TR_AMETH_00207]、[TR_AMETH_00208]和[TR_AMETH_00210]执行信号到服务的转换：
- 不幸的是，CP不支持服务接口。因此，相当于AP服务接口的可能是由不同类型的CP端口接口（如发送器/接收器、客户端/服务器或触发器接口）组合而成的。
- 信号到服务的转换规范需要涉及AP和CP接口元素的映射，以及数据实例的映射（即来自AP服务实例和CP信号的SOME/IP消息）。
Remarks:
The background of this activity is the request to enable service oriented communication between applications of a Classic Platform (CP) ECU-Instance and those of an Adaptive Platform (AP) Machine via SOME/IP.
If CP communicates as per SOME/IP no signal to service translation is necessary.
This is the case if
– CP communicates directly via Ethernet and fulfills the SOME/IP message format.
– a Gateway does the necessary translation (e.g. from CAN) to the SOME/IP message format.
Otherwise a signal to service translation as per [TR_AMETH_00207], [TR_AMETH_00208] and [TR_AMETH_00210] has to do the job:
– Unfortunately CP does not support service interfaces. Thus, the equivalent to an AP service interface may be composed of different types of CP Port- Interfaces like Sender/Receiver, Client/Server or Trigger interfaces.
– A signal to service translation specification needs to cover the mapping of AP and CP interface elements as well as the mapping of data instances (i.e. SOME/IP messages from AP service instances and CP signals).
[TR_AMETH_00207]{DRAFT} 设计（CP）ECU实例和（AP）机器之间的通信。【AP软件以面向服务的方式进行通信。然而，一辆典型的车辆将搭载包含CP ECU实例和AP机器的ECU硬件，可以以任何组合方式配置。
[TR_AMETH_00207]{DRAFT} Design communication between Classic Platform (CP) ECU-Instances and Adaptive Platform (AP) Machines 【Adaptive Software communicates in a service oriented manner. However, a typical vehicle will be equipped with ECU-HW that hosts CP ECU-Instances and AP Machines in any combination.
因此，ECU实例和机器之间很可能需要进行通信：
- 如果ECU实例实现了SOME/IP，就可以实现与机器之间的面向服务的通信。
- 如果双方都在总线层面上实现了兼容的SOME/IP消息，那么可以直接进行通信。
- 如果存在不兼容的SOME/IP消息，则需要通过网关在总线层面上实现兼容性。
- 如果ECU实例以基于信号的方式进行通信（例如，通过CAN或以非SOME/IP用例的以太网），则需要进行信号到服务的转换描述。
- 双方使用不同的端口接口类型，信号到服务的转换描述这种通信场景。
- 上下文包括CP端的PDU或以太网套接字，以及AP端的服务实例。】
【RS_METH_00202】
Thus, it is very likely that ECU-Instances and Machines need to communicate:
If the ECU-Instance implements SOME/IP the service oriented communication with Machines can be achieved.
– This works directly if both sides implement compatible SOME/IP messages on bus level.
– In case of incompatible SOME/IP messages a Gateway is required to achieve compatibility on bus level
If the ECU-Instance communicates in a signal based way (e.g. via CAN or Ethernet in a non-SOME/IP use case) a Signal to Service Translation Description is needed.
– Both sides use different PortInterface types, the artifact Signal to Service Translation Description documents this communication scenario.
– The context includes a PDU or Ethernet-socket on CP side and a Service Instance on AP side.
】(RS_METH_00202)
[TR_AMETH_00208]{DRAFT} 设计AUTOSAR经典平台（CP）和自适应平台（AP）之间的信号到服务的转换。【为了描述AP和CP之间的通信，即使在CP端不完全符合SOME/IP的使用情况下，【定义信号到服务的转换】活动描述了将一个或多个CP端口接口的元素映射到一个单独的AP服务接口的元素：
- 映射AP方法（Method）：
- 将CP的客户端/服务端操作映射到服务接口的方法。
- 将CP的触发器映射到服务接口的“Fire and Forget”方法。
- 映射AP事件（Event）：
- 将CP的发送器/接收器数据原型映射到服务接口的事件。
- 映射AP字段（filed）：
- 将CP的客户端/服务器操作映射到服务接口的字段获取/设置方法（getter/setter）。
- 将CP的发送器/接收器数据原型映射到服务接口的字段通知器(filed-notifier)。
- 根据服务实例映射AP的SOME/IP消息：
- 在服务发现中考虑服务实例ID作为上下文。
- 将事件消息映射到ISignal触发。
- 将方法消息映射到ISignal触发。
得到的信号到服务的转换描述产物可用于生成转换代码。
【RS_METH_00200, RS_METH_00202】
[TR_AMETH_00208]{DRAFT} Design Signal to Service translation between AUTOSAR Classic Platform (CP) and Adaptive Platform (AP) 【In order to describe the communication between AP and CP even in use cases where the CP side does not fully comply to SOME/IP, the activity Define Signal to Service Translation describes the mapping of the elements of one or more CP Port- Interfaces to the elements of a single AP Service Interface in scope of an individual Service Instance:
map AP method(s):
– map a CP Client/Server Operation to a method of the Service Interface.
– map a CP Trigger to a "Fire and Forget" method of the Service Interface.
map AP event(s):
– map a CP Sender/Receiver Data Prototype to an event of the Service Interface.
map AP field(s):
– map CP Client/Server Operations to field-getter/setter methods of the Service Interface
– map a CP Sender/Receiver Data Prototype to a field-notifier of the Service Interface.
map AP SOME/IP message(s) as per service instance:
– consider the service instance ID as context in service discovery
– map event messages to ISignal triggerings
– map method messages to ISignal triggerings
The resulting artifact Signal to Service Translation Description may be used to generate translation code.】(RS_METH_00200, RS_METH_00202)
[TR_AMETH_00210]{DRAFT} 信号与服务之间的映射。【在信号与服务实例的映射中，服务实例描述的所有服务接口元素都需要映射到基于CAN或FlexRay通信协议的信号。
- 对于方法，请参考[6, 清单规范]中的TPS_MANI_03125。
- 对于事件，请参考[6, 清单规范]中的TPS_MANI_03124。
- 对于字段，请参考[6, 清单规范]中的TPS_MANI_03126。
- 对于具体实例上下文，请参考[6, 清单规范]中的TPS_MANI_03000。】
【RS_METH_00200, RS_METH_00202】
[TR_AMETH_00210]{DRAFT} Map signals to services 【For a Signal to Service Translation Description all Service Interface elements of a Service Instance Description are mapped to the corresponding items of a signal-based communication protocol like CAN or FlexRay.
for methods see TPS_MANI_03125 in [6, Manifest Specification]
for events see TPS_MANI_03124 in [6, Manifest Specification]
for fields see TPS_MANI_03126 in [6, Manifest Specification]
for the concrete instance context see TPS_MANI_03000 in [6, Manifest Specification]】(RS_METH_00200, RS_METH_00202)
2.3 服务接口设计 Service Interface Design
图2.13提供了与服务接口（设计）描述相关的任务和工作产品的概述。要找到这些任务和工作产品的详细定义，请参考AP方法论库中的第3.8章节。
Figure 2.13 gives an overview of the tasks and work products in scope of Service
Interface (Design) Description. Please find the detailed definitions of these tasks and
work products in Adaptive Methodology Library (see chapter 3.8).
产物如下：
- 服务接口描述，通过服务接口映射能降低总线负载
- AP数据类型定义
The resulting work products are
Service Interface Description as outcome of Define Service Interface eventually enhanced by Service Interface Mapping as outcome of Aggregate Service Interfaces for reducing the bus load
Datatypes for the Adaptive Platform as outcome of Define Datatypes for the Adaptive Platform
[TR_AMETH_00008]{DRAFT} AP服务接口
所有在AP软件中使用的服务接口都需要被定义为具有事件、方法和字段详细信息的服务接口描述。它们是生成头文件的基础。因此，还可以在服务接口中定义命名空间，这将直接影响生成的代码。【RS_METH_00201】
[TR_AMETH_00008]{DRAFT} Develop Service Interfaces for Adaptive Software 【All service interfaces used in Adaptive Software need to be defined as Service Interface Description with event, method and field details.
They are the basis for the header file generation. Therefore, it is also possible to define name spaces within a service interface, which has a direct influence on the generated code.】(RS_METH_00201)
[TR_AMETH_00008]{DRAFT} AP 软件开发服务接口
所有在AP软件中使用的服务接口都需要被定义为具有事件、方法和字段详细信息的服务接口描述。它们是生成头文件的基础。因此，还可以在服务接口中定义命名空间，这将直接影响生成的代码。【RS_METH_00201】
[TR_AMETH_00009]{DRAFT} Aggregating service interfaces for reducing the bus load 【Optionally, service interfaces can be aggregated to more coarse-grained service interfaces by defining a Service Interface Mapping or a service interface element mapping respectively. This results in an update of the Service Interface Description. The newly defined coarse-grained service interfaces are then used for the network-based communication.】(RS_METH_00201)
[TR_AMETH_00007]{DRAFT} AP平台数据类型的定义
【可以根据AUTOSAR的标准化数据类型来定义自适应平台的数据类型。与CP平台一样，数据类型在不同的抽象级别上进行定义：应用程序数据类型、实现数据类型和基本类型。大多数概念和数据类型可以从CP平台继承。然而，为了应对C++编程语言，自适应平台的数据类型同时也包括了C++实现数据类型（支持向量、字符串、映射等）。【RS_METH_00201】
[TR_AMETH_00007]{DRAFT} Definition of data types for the Adaptive Platform 【
Datatypes for the Adaptive Platform can be defined based on standardized data types from AUTOSAR. As on the Classic Platform, data types are defined on different levels of abstractions: application data types, implementation data types and base types. Most concepts and data types can be taken over from the Classic Platform.
However, in order to cope with the C++ programming language Datatypes for the Adaptive Platform include C++ implementation data types (supporting vectors, strings, maps etc.).】(RS_METH_00201)
要了解有关经典平台指定的数据类型以及自适应平台的扩展的更多信息，请参阅[6，清单规范]和[11，软件组件模板]。】
For more information on data types as specified for the Classic Platform and the extensions
for the Adaptive Platform, see [6, Manifest Specification] and [11, Software Component Template].
2.3.1 服务接口设计用例场景Service Interface Design Usage Scenario
图2.14展示了如何获取服务接口描述的使用场景：
- 在基于定制任务的创建/更改用例中：
- 定义（或重用）服务接口
- 定义（或重用）服务接口的数据类型
- 这可以在系统和/或应用程序设计活动的上下文中完成，采用自顶向下的方法。
- 在基于定制任务的重用用例中：
- 重用服务接口
- （定义或）重用服务接口的数据类型
- 这可以在系统和/或应用程序设计活动的上下文中完成，采用自底向上的方法。
结果是定制的工作产品：
- 服务接口描述
- 服务接口的数据类型描述
Figure 2.14 shows the usage scenario of how to obtain Service Interface Descriptions
either in create/change use cases based on the tailored tasks:
– Define (or re-use) Service Interface
– Define (or re-use) Datatypes for a Service Interface
– this may be done in the context of system and/or application design activities
in top-down approach
either in re-use use cases based on the tailored tasks:
– Re-use Service Interface
– (Define or) re-use Datatypes for a Service Interface
– this may be done in the context of system and/or application design activities in bottom-up approach
resulting in tailored work products
– Service Interface Description
– Data Type Descriptions for Service Interfaces
2.4 应用程序设计Application Design
Figure 2.15提供了应用程序设计范围内任务和工作产品的概述。请在AP方法库中查找这些任务和工作产品的详细定义（请参阅第3.3章）。
Figure 2.15 gives an overview of the tasks and work products in scope of Application Design. Please find the detailed definitions of these tasks and work products in Adaptive Methodology Library (see chapter 3.3).
应用程序设计描述包括：
- SW组件设计。通过实例化特定（应用程序级或平台级）的端口接口，将交互端点定义为SWC端口。
- 可执行描述，通过SW 组件 实现"可执行文件"的定义。其依赖：
- 所有提及的SW组件设计。
- 过程设计描述，通过"定义过程设计"实现，意图为实例化（例如启动）特定可执行文件的实际OS进程定义一个设计时代理。其依赖：
- 可执行描述。
- SW交互描述 ，通过应用程序级交互和功能群集级交互的任务结果来实现，对设计时已知（以及集成相关的）交互配置进行描述。包括：
- "定义与应用程序的交互"，生成应用程序级交互。
- "定义与功能群集的交互"，生成平台级交互。
对于诊断的交互描述，请参考相关的诊断交互设计（另请参见图2.20诊断设计）。
其依赖：
- 可用过程设计描述和相关的可执行描述与SW组合描述。
- SW组件设计包括要配置为交互端点的应用程序级和平台级端口。
详细的定义可在Adaptive Methodology Library（参见第3.3章）中找到。
The resulting Application Design Description consists of
SW Component Design as outcome of task Define SW Component Design.
The SW Component Design defines – among other aspects not to be detailed here – interaction endpoints in terms of SWC Ports instantiating specific (application-level or platform-level) PortInterfaces.
Executable Description including a SW Composition Description as outcome of task Define Executable with enclosed SW Composition.
Dependencies are:
– all addressed SW Component Designs are available.
Process Design Description as outcome of task Define Process Design with the intention to define a design time proxy for the actual OS process instantiating (i.e. starting) a specific executable.
Dependencies are:
– Executable Description is available.
SW Interaction Description with the at design-time known (and integration relevant) interaction configuration for the SWC Port instances existing in an executable instance. Containing
– application-level interactions as outcome of task Define Interaction with Applications.
– platform-level interactions as outcome of task Define Interaction with Functional Clusters.
For diagnostics this may include/anticipate the Diagnostic Design related SW to Diagnostics Interaction Description contributions (see also Figure 2.20 Diagnostic Design).
Dependencies are:
– Process Design Description and related Executable Description with SW Composition Description are available.
– SW Component Designs include the application-level and platform-level Ports to be configured as interaction endpoints.
以上提到的任务之间存在相互依赖关系，并可以根据需求以合适的顺序执行。
Figure 2.16提供了AP平台软件层的概述,以此可以区分应用程序软件和平台级软件。请注意，本章定义的活动用于描述应用程序设计时，也可能适用于平台级软件，特别是如果平台级软件支持端口/端口接口概念。
The above mentioned tasks have inter-dependencies and may be executed - as per demand - in a suitable order.
Figure 2.16 gives an overview of the AUTOSAR Adaptive Platform software layers. We
distinct between application-level and platform-level software. Please be aware that
the activities defined in this chapter to describe the Application Design may also apply
to platform-level software, especially if platform-level software supports the Port /
PortInterface concept.
[TR_AMETH_00010]{DRAFT} 应用程序级软件是一组可执行文件的自适应软件（Adaptive Software）。
任何应用程序级可执行文件都可以组成一个或多个软件组件。 (RS_METH_00202)
[TR_AMETH_00010]{DRAFT} Application-level Software 【An Adaptive Software of category application-level is a collection of Executables.
Any application-level Executables may compose one or more software components.】
(RS_METH_00202)
[TR_AMETH_00011]软件组件设计【基于服务接口设计，AP软件的设计始于软件组件的设计。软件组件可以具备层次结构。
任何软件组件的设计都通过实例化服务接口（用于应用程序级端口）和功能集群接口（用于平台级端口），来定义其交互端点的要求并提供端口。】(RS_METH_00202)
[TR_AMETH_00011] Design of the software components 【Based on the service interfaces, the development of adaptive application software starts with the design of the software components.
The software components may have an hierarchical structure.
Any software component design defines its interaction endpoints via required and/or provided Ports instantiating service interfaces (for application-level Ports) and functional cluster interfaces (for platform-level Ports).】(RS_METH_00202)
[TR_AMETH_00035]{DRAFT} 平台级软件 【平台级的AP软件是一个可执行文件的集合。
如果基于标准化的服务接口，平台级可执行文件可能由软件组件构成，但也可以直接实现而无需软件组件]。(RS_METH_00207, RS_METH_00041)
[TR_AMETH_00035]{DRAFT} Platform-level Software 【An Adaptive Software of category platform-level is a collection of Executables.
A platform-level Executable may consist of software components if these are based on standardized service interfaces, but may also be directly implemented without a software component model.】(RS_METH_00207, RS_METH_00041)
2.4.1 应用程序设计用例场景（自顶向下）Application Design Usage Scenario (top-down)
图2.17展示了如何详细说明应用程序设计的使用场景，以完成可执行文件及其基于定制任务的进程设计描述（自顶向下方法）的实例化过程：
Figure 2.17 shows the usage scenario of how to elaborate the Application Design, targeting at complete executables and their instantiation as Process Design Description (top-down approach) based on the tailored tasks:
- 定义具有封闭软件组合的可执行文件:
- 定义或重用软件组件。
- 这包括SWC之间用于交互的接口（包括应用程序级和平台级软件）。
- 输入为功能集群接口描述和服务接口描述，输出为软件组件描述。
- 定义可执行文件:
- 这包括在可执行文件的专用软件组合中实例化软件组件。
- 输入为软件组件描述，输出为可执行文件描述以及相关的软件组合描述。
- 定义可执行文件的运行时行为:
- 通过定义进程设计作为实际操作系统进程的设计时代理来实例化（即启动）特定的可执行文件。
- 输入为可执行文件描述，输出为进程设计。
- 定义可执行文件实例中存在的软件组件端口实例的软件交互:
- 定义与应用程序软件的交互。
- 定义与功能集群的交互。
- 输入来自应用程序设计，输出为扩展应用程序设计的软件交互描述。
Define Executable with enclosed SW Composition with
– Define or re-use SW Components
This includes the specification of SWC interaction endpoints in terms of Ports instantiating specific (application-level or platform-level) PortInterfaces.
Inputs are Functional Cluster Interface Descriptions and Service Interface Descriptions, deliverable is a SW Component Description.
– Define Executable
This includes the instantiation of SWCs in the dedicated SW composition of an executable.
Inputs are SW Component Descriptions, deliverable is the Executable Description along with the related SW Composition Description
Define Executable Run-time Behavior with
– Define Process Design as design time proxy for the actual OS process instantiating (i.e. starting) a specific executable.
Input is the Executable Description, deliverable is a Process Design.
Define SW Interaction for the SWC Port instances existing in an executable instance, with
– Define Interaction with Application SW
– Define Interaction with Functional Clusters
– Inputs come from Application Design, deliverable is a SW Interaction Description that extends the Application Design.
上述提到的活动具有前置依赖关系，并且需要按照项目符号的顺序执行。
The above mentioned activities have predecessor-dependencies and need to be executed
as per order of the bullet points.
2.4.2 应用程序设计场景（自底向上）Application Design Usage Scenario (bottom-up)
图2.18展示了如何根据定制任务进行应用程序设计:
- 定义可重用的软件组件:
- 使用功能集群接口描述和服务接口描述作为输入，输出为软件组件描述。
Figure 2.18 shows the usage scenario of how to elaborate a Contribution to Application Design based on the tailored task:
Define SW Components for re-use with Define re-usable SW Component Inputs are Functional Cluster Interface Descriptions and Service Interface Descriptions, deliverable is a SW Component Description.
2211
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
