AUTOSAR_EXP_PlatformDesign[R19.03] - 03.Architecture

AUTOSAR_EXP_PlatformDesign[R19.03] - 03.Architecture

【version:R19.03，translated by sky8336, 2019.06.04, Shanghai】

3 Architecture

3.1 Logical view

ARA

---------

Note1：

AA:  Adaptive Applications 

ARA: AUTOSAR Runtime for Adaptive applications

自适应平台基础：Adaptive Platform Foundation 

自适应平台服务：Adaptive Platform Services 

功能集群：Functional Clusters

非平台服务: Non-platform service（Non-PF Service）

----------

AA 运行在 ARA 的上层。

ARA 由功能集群提供的应用接口组成。这些功能集群接口属于自适应平台基础或自适应平台服务。

自适应平台基础提供AP的基本功能，自适应平台服务提供AP的平台标准服务。

任何AA也可以向其他AA提供服务，如图所示非平台服务。

从AA的角度来看，功能集群的接口，无论是属于自适应平台基础，还是自适应平台服务，都是无关紧要的，它们只是提供了特定的c++接口，或者AP将来可能支持的任何其他语言绑定。

语言绑定、c++标准库和POSIX API

这些API的语言绑定基于c++， c++标准库也是ARA的一部分。

对于 OS API，只有PSE51接口，POSIX标准的单进程概要文件 是可以作为ARA的一部分。

PSE51 已经被用于为现有的POSIX应用程序提供可移植性，并实现应用程序之间的干扰自由。

c++标准库包含许多基于POSIX的接口，包括多线程api。建议不要将c++标准库线程接口与本地PSE51线程接口混合使用，以避免出现复杂的情况。不幸的是，c++标准库没有涵盖PSE51的所有功能，比如设置线程调度策略。在这种情况下，可能需要同时使用这两种接口。

Application launch and shutdown 

-------

note:

Execution Management (EM): 执行管理

--------

应用程序的生命周期由执行管理(EM)管理。

应用程序的加载/启动是通过使用EM的功能来管理的，它需要在系统集成时或运行时进行适当的配置才能启动应用程序。

事实上，从EM的角度来看，所有的功能集群都是应用程序，它们也是以相同的方式启动的，除了EM本身。

图3-2应用程序演示了AP内部和AP上的不同类型的应用程序。

EM不会决定应用程序何时启动或何时终止。

一种称为状态管理(SM)的特殊FC是控制器，它根据系统的设计来指挥EM，仲裁不同的状态，从而控制整个系统

的行为。由于这里的系统是指整个机器AP及其应用程序，因此内部行为是特定于项目的实现。SM还与其他FCs

交互以协调整个机器行为。SM应该只使用标准的ARA接口来维护不同AP栈实现之间的可移植性。

Application interactions 

在AAs之间的交互方面，PSE51不包含IPC(进程间通信)，所以AAs之间没有直接的交互接口。

通信管理(CM)是唯一的显式接口。CM还提供了面向服务的机器内部和机器之间的通信，对应用程序是透明的。

不考虑服务和客户机应用程序的拓扑部署。注意，其他ARA接口可能会在内部触发AAs之间的交互，但是，这不是一个显式的通信接口，而是各个ARA接口提供的功能的副产品。

Non-standard interfaces 

AA和功能集群可以使用任何非标准接口，前提是它们不与标准AP功能冲突，并且它们符合项目的safety/security

需求。

3.2 Physical view 

这里讨论AP的物理体系结构[1]。请注意，本节中的大部分内容仅用于演示，并不构成AP的正式需求规范，因为

AP的内部是由实现定义的。对AP实现的任何正式需求都被显式地声明。

--------

note:

[1] 这里的“物理体系结构”主要指流程视图、物理视图以及其他一些开发视图，如[6]中所述

-------

OS, processes, and threads 

AP操作系统需要提供多进程POSIX OS功能。每个AA都实现为一个独立的进程，具有自己的逻辑内存空间和名

称空间。请注意，单个AA可能包含多个进程，并且可以将其部署到单个AP实例或分布在多个AP实例上。从模块

组织的角度来看，每个进程都由来自可执行文件的OS实例化。多个进程可以从一个可执行文件实例化。此外，

AA可以构成多个可执行程序。

功能集群通常也作为进程实现。一个功能集群也可以通过单个进程或多个(子)进程来实现。自适应平台服务和非

平台服务也作为进程实现。

所有这些进程都可以是单线程进程或多线程进程。但是，它们可以使用的OS API不同，这取决于进程属于哪个

逻辑层。如果他们是运行在ARA之上的AAs，那么他们应该只使用PSE51。如果进程是功能集群之一，则可以自

由使用任何可用的OS接口。

总之，从操作系统的角度来看，AP和AA只是形成了一组进程，每个进程都包含一个或多个线程——这些进程之

间没有区别，尽管AP的实现可以提供任何类型的分区。这些进程通过IPC或任何其他可用的操作系统功能相互交

互。注意，AA进程不能直接使用IPC，只能通过ARA进行通信。

Library-based or Service based Functional Cluster implementation 

如图3-1 AP体系结构逻辑视图所示，一个功能集群可以是自适应平台基础模块或自适应平台服务。如前所述，他

们一般都是进程。为了让它们与AAs(也是进程)交互，它们需要使用IPC。有两种可选的设计来实现这一点。一种

是“基于库”的设计，这种设计中，由功能集群提供并链接到AA的接口库直接调用IPC。另一种是“基于服务”的设

计，进程使用通信管理功能，并有一个连接到AA的服务器代理库。

代理库调用通信管理接口，用于协调AA进程和服务器进程之间的IPC。注意，它是实现定义的，AA是否只通过

通信管理直接执行IPC，还是通过代理库与服务器混合使用直接IPC。

为Functional Cluster选择设计的一般原则是，如果只在本地的AP实例中使用它，那么基于库的设计更合适，因

为它更简单，也更高效。如果以分布式方式从其他AP实例使用它，建议使用基于服务的设计作为通信，无论客

户端AA和服务位于何处，管理都提供透明的通信。正如名称所正确指出的那样，属于自适应平台基础的功能集

群是“基于库的”，属于自适应平台服务的集群是“基于服务的”。

最后，请注意，FC的实现允许没有进程，而是以库的形式实现，在AA进程上下文中运行，只要它满足FC定义的

RS和SWS。在这种情况下，一个 AA和FC的交互将是常规的程序调用，而不是前面描述的基于IPC的调用。

The interaction between Functional Clusters 

通常，功能集群可以以AP特定于实现的方式相互交互，因为它们不绑定到ARA接口，例如PSE51，这限制了IPC

的使用。它确实可以使用其他功能集群的ARA接口，即公共接口。功能集群之间的一个典型交互模型是使用功能

集群的受保护接口，提供所需的特权访问，以实现功能集群的特殊功能。

同时，从AP18-03开始，引入了一个新的功能间集群(IFC)接口的概念。它描述了FC提供给其他FC的接口。注

意，它不是ARA的一部分，也不构成AP实现的正式规范需求。提供这些功能是为了通过澄清FCs之间的交互来

促进AP规范的开发，它们还可能为AP规范的用户提供更好的AP体系结构视图。这些接口在各自的FC SWS的附

件中进行了描述。

Machine/hardware 

AP将其运行的硬件视为一台机器。其背后的原理是实现一致的平台视图，而不管可能使用的虚拟化技术。这台

机器可能是一台真正的物理机器、一台完全虚拟化的机器、一个准虚拟化的OS、一个OS级虚拟化的容器或任何

其他虚拟化的环境。

在硬件上，可以有一台或多台机器，并且一台机器上只能运行一个AP实例。一般认为，这种“硬件”包括一个芯

片，承载一台或多台机器。但是，如果AP实现允许，也有可能由多个芯片组成一台机器。

3.3 Methodology and Manifest 

对功能应用程序的分布式、独立和敏捷开发的支持需要一种标准化的开发方法。AUTOSAR自适应方法涉及工作

产品的标准化，用于描述服务、应用程序、机器及其配置等构件;对功能应用程序的分布式、独立和敏捷开发的

支持需要一种标准化的开发方法。AUTOSAR自适应方法涉及工作产品的标准化，用于描述服务、应用程序、机

器及其配置等构件;以及定义这些工作产品应如何交互以实现为自适应平台开发产品所需的各种活动交换设计信

息的各自任务。

图3-3说明了如何实现自适应方法的概述草案。有关这些步骤的详细信息，请参见[3]。

3.4 Manifest 

清单表示为支持AUTOSAR AP产品的配置而创建的AUTOSAR模型描述的一部分，并将其上载到AUTOSAR AP

产品，可能与清单应用于的包含可执行代码的其他构件(如二进制文件)结合使用。

清单的使用仅限于AUTOSAR AP。但是，这并不意味着所有针对AUTOSAR AP 的开发项目产生的ARXML 被自

动认为是一个清单。

事实上，AUTOSAR AP通常并不只用于车辆项目中。

一个典型的车辆很可能还配备了一些基于AUTOSAR CP开发的的ecu，因此整个车辆的系统设计必须涵盖两者

——在AUTOSAR CP上够条件的ECU和 在AUTOSAR 上创建的ECU。

原则上，术语“清单”可以定义为在概念上只有一个“清单”，并且每个部署方面都将在此上下文中处理。这似乎并不

合适，因为很明显，与清单相关的模型元素存在于一个典型开发项目的完全不同的阶段中。

这方面是主要的动机，在应用程序设计之后，有必要将术语Manifest的定义细分为三个不同的分区:

应用程序设计(Application Design)： 这类描述指定设计相关的所有方面,它们适用于AUTOSAR AP 应用软件的

创建。它

并不一定需要部署到自适应平台机器,但是应用程序设计帮助在执行清单和服务实例清单中进行应用软件的部署

定义。

执行清单(Execution manifest): 这种清单用于指定运行在AUTOSAR AP上的应用程序的部署相关信息。

执行清单与实际的可执行代码捆绑在一起，以支持将可执行代码集成到机器上。

服务实例清单(Service Instance Manifest):  这种清单用于指定如何根据底层传输协议的需求配置面向服务的通

信。

服务实例清单与实际的可执行代码绑定在一起，这些代码实现了各自的面向服务通信用法。

机器清单(Machine Manifest): 这种清单应该描述与部署相关的内容，这些内容只应用于运行AUTOSAR AP的底

层机器的配置(即没有任何应用程序在机器上运行)。机器清单与用于建立AUTOSAR AP实例的软件捆绑在一起

不同类型清单的定义(和使用)之间的暂时划分导致这样的结论，在大多数情况下，将使用不同的物理文件存储这

三种清单的内容。

除了应用程序的设计和不同种类的清单，AUTOSAR方法支持一种系统设计(System Design)，他能描述两个

AUTOSAR平台的软件组件，它们将在一个单一模型的单个系统中使用。不同AUTOSAR平台的软件组件可以以

面向服务的方式彼此通信。但是也可以描述信号到服务的映射，从而在面向服务的通信和基于信号的通信之间建

立桥梁。

3.5 Application Design 

应用程序设计描述了所有与设计相关的建模，这些建模应用于AUTOSAR AP应用程序软件的创建。

应用程序设计主要关注以下几个方面:

• 用于对软件设计和实现的信息进行分类的数据类型(data types)
• 作为面向服务通信的关键元素的服务接口(Service interfaces)
• 应用程序如何访问面向服务通信的定义(definition)
• 作为访问persistent 数据 和文件的关键元素的persistency 接口(persistency interfaces)
• 应用程序如何访问persistent 存储的定义(definition)
• 应用程序如何访问文件的定义(definition)
• 应用程序如何访问加密软件的定义(definition)
• 应用程序如何访问平台健康管理的定义(definiton)
• 应用程序如何访问时间基准的定义(definition)
• 序列化属性(serialization properties)，用于定义如何序列化网络上传输的数据的特征
• 作为通过REST模式与web服务通信的关键元素的REST 服务接口(REST service interfaces)
• 客户端和服务器功能的描述（description）
• 对应用程序进行分组，以简化软件的部署。

应用程序设计中定义的构件独立于应用程序软件的特定部署，因此可以简化在不同的部署场景中重用应用程序的

实现。

3.6 Execution manifest

执行清单的目的是提供将应用程序实际部署到AUTOSAR AP所需的信息。

通常的想法是，使应用程序软件代码尽可能独立于部署场景，以增加应用程序软件在不同部署场景中重用的可能

性。

通过执行清单，可以控制应用程序的实例化，因此有可能这样做

• 在同一台计算机上多次实例化相同的应用程序软件
• 将应用程序软件部署到多台机器上，并为每台机器实例化应用程序软件。

执行清单主要关注以下几个方面:

• 启动配置，以定义如何启动应用程序实例。启动包括启动选项和访问角色的定义。

       每个启动可能依赖于机器状态和/或函数组状态。

• 资源管理，特别是资源组分配。

3.7 Service Instance Manifest 

在网络上实现面向服务的通信需要特定于所使用的通信技术的配置(例如，SOME/ IP)。由于通信基础设施在服务

的提供者和请求者上的行为应该相同，因此服务的实现必须在双方都兼容。

服务实例清单主要关注以下方面:

• 服务接口部署(service interface deployment)，定义如何在特定的通信技术上表示服务。
• 服务实例部署，为特定的已提供和所需的服务实例定义通信技术所需的凭据。
• 配置E2E保护
• 配置安全保护
• 日志和跟踪的配置

3.8 Machine Manifest 

• 机器清单允许配置运行在特定硬件(机器)上的实际自适应平台实例。
• 机器清单主要关注以下几个方面:
• 配置网络连接并为网络技术定义基本凭证(例如，对于以太网，这涉及设置静态IP地址或定义DHCP)。
• 服务发现技术(service discovery technology)的配置(例如，对于SOME/IP，这涉及到要使用的IP端口和IP组播地址的定义)。
• 使用的机器状态的定义
• 使用的功能组的定义
• 自适应平台功能集群实现的配置(例如，操作系统提供具有特定权限的OS用户列表)。
• 密码平台模块的配置
• 平台健康管理配置
• 时间同步的配置
• 可用硬件资源的文档(例如可用内存大小;有多少处理器内核可用)

--------------------------

【end-2019.06.07】