| 编辑推荐: |
本文从逻辑视图视图说起，物理视图，通过方法和举例以及清单，应用程序设计相关方面介绍。
本文来自于csdn，由火龙果软件Anna编辑、推荐。 |
|
1.逻辑视图
1.1 ARA
图1 显示了AP架构的逻辑视图。自适应应用程序（AA）运行在ARA（AUTOSAR自适应应用程序）之上。ARA由功能集群提供的应用接口组成，它们属于自适应平台基础或自适应平台服务。自适应平台基础提供AP的基本功能，自适应平台服务提供AP的平台标准服务。每一个
AA也可以向其他AA提供服务，图中所示为非平台服务。
从AA的角度上看，功能集群的接口与自适应平台基础或自适应平台服务提供的接口无关——因为它们只为C++提供接口，或为未来的某一种与AP相绑定的语言提供接口。其实这种差异还有很多。并且在ARA接口下（包括在AA中调用的ARA库），可以使用除ARA之外的其他接口来实现AP的规范，这取决于AP是怎样实现的。
图1 AP架构的逻辑视图
要注意到，图1包含的功能集群并不是当前版本AP的一部分，此图只是用来更好地了解总体结构的。图中没有显示的更多新功能集群很可能会在未来版本的AP中添加。
1.2 语言绑定、C++标准库和POSIX API
这些API的语言绑定是基于C++的，C++标准库也可以作为ARA的一部分。至于操作系统的API，只有PSE51接口（POSIX标准的单个进程概要文件）在ARA中是可用的。PSE51为现有POSIX应用程序提供可移植性，并实现应用程序之间的通信。
C++标准库包含基于POSIX的多个接口，包括多线程的API。建议不要将C++标准库线程接口与本地PIS51线程接口混在一起用，否则问题会变得复杂。但是，C++标准库不包括所有的PIS51函数，例如线程调度策略的设置。在这种情况下，可能需要同时使用两个接口。
1.3 应用程序的启动和关闭
应用程序的生命周期由执行管理（EM）负责。应用程序的加载和启动是通过使用EM来实现的，它需要在系统集成时或运行时进行适当的配置来启动应用程序。实际上，从EM的角度来看，除了EM本身，所有的功能集群都是应用程序，并且它们也以相同的方式启动。图2表示的是AP内和AP上不同类型的应用程序。
图2 应用程序
应用程序什么时候启动或终止不是由EM决定的。另一个功能集群（称为状态管理SM）是控制器，它根据系统的要求去控制EM并判断各种状态，从而控制整个系统的行为。SM还与其他的功能集群交互，来协调全部的机器行为。
1.4 应用程序的交互
对于AA之间的交互而言，PSE51是不包括IPC（进程间通信），所以AA之间没有直接的交互接口。通信管理（CM）是唯一的显式接口。CM也在机器内和机器间提供面向服务的通信，但应用程序不知道这一回事。无论服务器和客户端应用程序的拓扑部署如何，CM都会去处理服务的请求和响应。其他的ARA接口可能在内部触发ARA之间的交互，但是，这是一个不明确的通信接口，而是各自ARA接口的副产物。
1.5非标准接口
AA和功能集群可以使用任何非标准接口，前提是它们不能与标准AP的功能冲突，并且符合项目的安全要求。除非它们是本地运行库里面的应用程序。否则要尽量减少这种使用，因为这将影响软件对其他AP实现的可移植性。
2.物理视图
我们现在来讨论AP的物理架构。本节中的大部分内容仅用于说明目的，并不一定代表AP的正式标准，因为AP的内部是通过定义来实现的，实现AP的所有条件都有着明确的说明。
2.1 操作系统、进程和线程
AP操作系统需要满足多进程的POSIX。每个AA都作为一个独立的进程来实现，具有自己的逻辑内存空间和名称空间。一个AA可以包含多个进程，并且可以应用到一个AP实例上，或者分布在多个AP实例上。从模块组织的角度来看，每个进程都是由操作系统在可执行文件中去实现的。可以从单个可执行文件实现多个进程。AA可以构成多个可执行文件。
功能集群通常也被当作流程来实现。它也可以用单个进程或多个（子）进程实现。自适应平台服务和非平台服务也是被当作过程来实现的。
所有这些进程都可以是单线程或多线程的。但是，它们可以使用的操作系统的API因进程所属的逻辑层而异。如果它们是在ARA上运行的AA，那么它们应该只使用PSE51。如果一个进程是一个功能集群，它可以自由地使用任何可用的操作系统的接口。
总之，从操作系统的角度上看，AP和AA只形成一组进程，每个进程包含一个或多个线程——这些进程之间没有区别，尽管那些分区取决于AP是怎样实现的。这些进程确实通过IPC或任何其他可用的操作系统功能相互作用。但是，AA进程不能直接使用IPC，只能通过ARA进行通信。
2.2 基于库或基于服务的功能集群的实现
如图1所示，功能集群可以是自适应平台基础模块或自适应平台服务。上文提到过，这些通常是两个过程。为了与AA交互，它们需要使用IPC。要实现这一点，有两种可选设计。一种是“基于库”的设计，其中接口库由功能集群提供并链接到AA，直接调用IPC。另一种是“基于服务”的设计，流程使用通信管理功能，并有一个链接到AA的服务器代理库。代理库调用通信管理接口，该接口协调AA进程和服务器进程之间的IPC。实现定义决定了AA是只执行带有通信管理的IPC，还是通过代理库与服务器混合使用IPC。
设计功能集群的一般准则是，如果它只在AP实例的本地使用，那么基于库的设计更合适。因为它更简单，也更高效。如果以分布的方式在其他AP实例中使用，建议采用基于服务的设计。因为通信管理是非常清晰明了的，不需要知道客户端的AA和服务器在哪里。属于自适应平台基础的功能集群是“基于库的”，自适应平台服务是“以服务为基础的”。
只允许一个功能集群的实现没有进程，而是以库的形式去实现，并且它要在AA进程中运行，只要它满足功能集群定义的RS和SWS。在这种情况下，AA和功能集群之间的交互是常规过程调用，而不是前面描述的基于IPC的过程调用。
2.3 功能集群间的交互
一般来说，功能集群之间可以以AP特定实现的方式来进行交互，因为它们没有绑定ARA接口，例如限制IPC使用的PSE51。它确实可以使用其他功能集群的ARA接口，因为这些功能集群有公共接口。功能集群之间的一个典型交互模型是使用功能集群的受保护接口，来提供实现功能集群特殊功能所需的访问特权。
同时，从AP18-03开始，提出了一种新的功能间集群（IFC）接口的概念，它介绍了一个FC（功能集群）提供给其他FC的接口。要注意到，它不是ARA的一部分，也不是AP实现的正式标准。通过阐明FC之间的相互作用，这些功能可以促进AP标准的制定，还可以为AP标准的用户提供更好的架构视图。接口在各自的FC和SWS附件中有描述。
2.4 机器和硬件
AP将运行的硬件视为一台机器，实现一致的平台视图，而不考虑所使用的虚拟化技术。这台机器可能是一台真正的物理机器、一台完全虚拟化的机器、一个准虚拟化的操作系统、一个操作系统级的虚拟化容器或任何其他虚拟化环境。
在硬件上，可以有一台或多台机器，并且只有一个AP例程在机器上运行。这种“硬件”上一般会有一个芯片，并承载着一台或多台机器。然而，如果AP允许的话，多个芯片也可能形成一台机器。
3.方法和举例
对功能性应用程序进行分布、独立而又敏捷的开发需要一种标准化的开发方法论。AUTOSAR自适应方法涉及工作产品的标准化，用来描述服务、应用程序、机器及其配置等工件，并且定义了这些工件如何交互以实现开发所需的各种设计信息的交换。图3是如何实现自适应方法的概述。
图3 AP开发的流程
4.清单
清单表示为支持AUTOSAR AP产品配置而创建的一段AUTOSAR模型描述，它会上载到AUTOSAR
AP产品，会与适用于清单的可执行代码文件（如二进制文件）组合使用。
清单的使用仅限于AUTOSAR AP。但是，这并不意味着在一个以AUTOSAR AP为目标的开发项目中生成的所有ARXML都被视为清单。事实上，AUTOSAR
AP通常不是专门用于车辆项目的。
一部典型的车辆很可能也会配备在AUTOSAR CP上开发出的多个ECU。所以，整个车辆的系统设计必须涵盖这两个方面——构建在AUTOSAR
CP之上的ECU和创建在AUTOSAR AP之上的ECU。
原则上来说，术语清单可以定义为在概念上只有一个“Manifest”，每个部署都将在这里面处理。但这似乎是不合适的，因为很明显，在典型开发项目的不同阶段，存在与清单相关的模型元素。
这被认为是主要的驱动因素，即在设计应用程序时，有必要将术语清单的定义细分成三个不同的分区.
4.1 应用程序设计
这种描述指定了所有与设计相关的方面，这些方面可以为AUTOSAR AP创建应用程序软件。虽然不一定需要部署到自适应平台机器上，但是应用程序设计有助于在执行清单和服务实例清单中规定应用程序软件的部署。
4.2 执行清单
此类清单用于指定在AUTOSAR AP上运行的与应用程序部署相关的信息。执行清单与实际可执行代码捆绑在一起，以便将可执行代码集成到计算机上。
4.3 服务实例清单
这种清单用于指定如何根据底层传输协议的要求去配置面向服务的通信。服务实例清单与实现面向服务通信的各个实际可执行代码捆绑在一起。
4.4 机器清单
这种清单描述与部署相关的内容，这些内容只适用于运行AUTOSAR AP的底层计算机的配置（即机器上不运行任何应用程序）。机器清单与用于建立AUTOSAR
AP实例的软件捆绑在一起。
如果从时间上去分开不同类型清单的定义和用法，可以得出：在大多数情况下，将使用不同的物理文件来存储这三种清单的内容。
除了应用程序设计和不同种类的清单外，AUTOSAR方法支持系统设计去描述两个AUTOSAR平台的软件组件，这些组件将在单个模型的系统中使用。不同AUTOSAR平台的软件组件可以以面向服务的方式相互通信。也可以描述从信号到服务的映射，从而在面向服务的通信和基于信号的通信之间建立一个桥梁。
5.应用程序设计
应用程序设计描述了所有与设计相关的模型，这些模型用于为AUTOSAR AP创建应用程序软件。
应用程序设计的重点是以下几个方面：
用于软件设计和实现的分类信息的数据类型
作为面向服务通信的关键元素的服务接口
定义应用程序如何访问面向服务的通信
持续性接口作为访问持续数据和文件的关键元素
定义应用程序如何访问持续存储
定义应用程序如何访问文件
定义应用程序如何访问加密软件
定义应用程序如何访问平台健康管理
定义应用程序如何访问时基
序列化属性，用于定义数据在网络上如何序列化传输的特征
REST服务接口，通过REST模式作为关键元素与Web服务进行通信
客户端和服务器功能说明
对应用程序进行分组，以便于软件的部署
在应用程序设计中定义的工件，独立于应用程序软件的特定部署，从而简化了不同部署场景中应用程序的多次使用。
6.执行清单
执行清单用来提供将应用程序实际部署到AUTOSAR AP所需的信息。通常来说是将应用程序软件代码尽可能独立于部署场景，以增加在不同部署场景中多次使用应用程序软件的可能性。
使用执行清单可以控制应用程序的实例化，因此可以:
在同一台机器上多次实例化同一应用软件
或将应用软件部署到多台机器上，并为每台机器实例化应用软件
执行清单的重点是以下几个方面：
启动相关配置去定义应用程序实例的启动方式，启动包括启动选项和访问角色的定义，每次的启动可能取决于机器状态和/或功能组状态
资源管理，特别是资源组分配
7.服务实例清单
在网络上实现面向服务的通信，需要所使用通信技术（例如SOME或IP）的特定配置。由于通信基础设施在服务的提供和请求上应该相同，因此服务的实现必须在双方都兼容。
服务实例清单的重点是以下几个方面：
服务接口部署，定义如何在特定通信技术上把服务表示出来
服务实例部署，为特定的已提供的所需服务实例定义通信技术所需的凭据
E2E保护配置
安全保护配置
日志和跟踪配置
8.机器清单
机器清单上可以去配置在特定硬件（机器）上运行的实际自适应平台实例。
机器清单的重点是以下几个方面：
网络连接的配置和定义网络技术的基本凭证（例如，对于以太网这种涉及静态IP地址或定义DHCP的设置）。
服务发现技术的配置（例如，对于某些/IP而言，会涉及到要使用的IP端口和IP组播地址的定义）。
使用机器状态的定义
所用功能组的定义
自适应平台功能集群实现的配置（例如，操作系统提供具有特定权限的操作系统用户列表）
加密平台模块的配置
平台健康管理配置
时间同步配置
可用硬件资源的文档（例如，有多少RAM可用，有多少处理器内核可用）
|
