第2章 Adaptive AUTOSAR的架构与组成
2.1 AP架构总览
2.1.1 逻辑架构
在1.3.2节中，读者初步了解了AP的架构，本节将详细讲解AP的架构。AP的逻辑架构如图2-1所示。
图2-1 AP的逻辑架构
自适应应用程序（Adaptive Applications，AA）运行在ARA（AUTOSAR Runtime for Adaptive Applications）之上。ARA由功能集群提供的应用接口组成，它们属于自适应平台基础或自适应平台服务。自适应平台基础提供AP的基本功能，自适应平台服务提供AP的平台标准服务。任何AA也可以向其他AA提供服务，图2-1中所示为非平台服务。
功能集群（Functional Clusters，FC）的接口是自适应平台基础或自适应平台服务的接口，FC接口与AA无关，它们只提供指定的C++接口或任何其他将来可能支持的与AP绑定的语言，这在底层确实存在着分歧。另外，在ARA接口下面，包括在AA上下文中调用的ARA库，可以使用ARA以外的其他接口来实现AP的规范，这取决于AP实现的设计。需要注意的是，为了能够更好地了解整体结构，图2-1的AP架构逻辑视图包含不属于当前AP版本的功能集群。在AP的未来版本中，可能会添加更多新的功能集群。
这些API的语言是基于C++的，C++标准库也可以作为ARA的一部分。关于操作系统API，POSIX标准的单个进程概要文件，即PSE51接口作为ARA的一部分是可用的。选择PSE51是为了为现有POSIX应用程序提供可移植的可能性，并实现应用程序之间的自由交互。
注意：C++标准库包含基于POSIX的许多接口，其中也包括多线程API。建议不要将C++标准库线程接口与本地PSE51线程接口混合，以避免出现复杂的情况。需要特别注意的是，C++标准库不包括所有的PSE51函数，例如设置线程调度策略的函数。在这种情况下，可能需要同时使用两个接口。
应用程序的生命周期由执行管理（Execution Management，EM）来管理。应用程序的加载/启动是通过使用EM的功能来管理的，它需要在系统集成时或运行时进行适当的配置来启动应用程序。事实上，所有的功能集群都是通过EM管理的。除了EM本身之外，它们也是以同样的方式启动、运行和停止的。图2-2说明了不同类型且在AP内部或在AP之上的应用程序之间的关系。
图2-2 应用程序关系
需要明确的一点是，应用程序启动或终止的决定不是由EM做出的。决定应用程序的启停是一种特殊的FC，称为状态管理（State Management，SM）。SM是根据系统的设计指挥EM的控制器，SM会仲裁不同的状态，从而控制整个系统的行为。由于这里的系统指的是整个AP的机器（Machine，后续章节会介绍到）及搭载在机器上正在运行的应用程序，因此实现的内部行为是由每个项目的需求所决定的。同时SM还与其他FC交互，以协调整体机器行为。SM应该只使用标准的ARA接口来维护不同AP栈之间的可移植性。
关于AA间的交互，由于PSE51不包括进程间通信（IPC），因此AA间没有直接的交互接口。通信管理（Communication Management，CM）是唯一的显式接口。CM还为机器内和机器间提供面向服务（SOA）的通信，这对应用程序是透明的。CM处理服务请求/回复的路由选择，而不考虑服务和客户端应用程序的拓扑部署。其他ARA接口可能会在内部触发AA之间的交互，但是，这不是显式的通信接口，而只是各个ARA接口提供的功能的副产品。
最后，AA和功能集群可以使用任何非标准接口，只要它们不与AP标准功能冲突，并且符合项目的功能/信息安全要求。除非它们是纯粹地使用程序本地库，否则应该注意将这种使用保持在最低限度，因为这将影响软件在其他应用程序实现上的可移植性。