3.Adaptive AUTOSAR 架构详解

3.1 逻辑层架构

下面显示了AP的逻辑架构．AA（adaptive application)在ARA (AUTOSAR Runtime for Adaptive Applications) 上运行. ARA包含了所有功能集合的应用接口.这些功能属于 Adaptive Platform foundation 和 Adaptive Platform Service. 任何AA多可以为其他AA提供服务．

这些功能接口对应用程序来说没啥差别，不论这些功能属于Adaptive Platform Foundation还是Adaptive Platform Service. 这些接口仅提供C++接口或者将来AP将来支持的其他语言接口。这两个部分内部实现肯定是有差别的。并且，AA调用的ARA的库中，可以使用ARA之外的接口来实现AP规范。这取决于AP的实现

需要注意的是为了展现一个更好的整体架构，图3-1显示的AP架构逻辑层包含的功能集合不是当前发布的AP的一部分。在这里没有显示的新功能会加入到未来发布的AP中。

语言绑定， C++标准库和POSIX API

这些API使用的语言是C++，并且C++标准库是ARA的一部分。关于OS API, 仅PSE51接口是ARA的一部分。PSE51是POSIX标准的单进程配置文件。PSE51被选来实现POSIX应用程序的移植以实现应用程序之间的免打扰。

C++标准库包含很多基于POSIX的接口，多线程API也包含在内。不推荐C++标准库的线程接口和PSE51的线程接口混合使用。不行的，c++标准库并不能cover所有的PSE51的功能，比如设置一个线程的调度策略。在这种情况下混合起来是使用是很有必要的。

应用程序启动和关闭

应用程序的生命周期是由EM(execution management )来管理的。应用程序的加载和关闭是有EM提供的功能来管理的。启动一个应用程序需要再在系统集成和运行时间内进行正确的配置。实际上，除了EM自己，所有的功能对于EM来说都是一样的应用，加载方式都一样。图3-2展示了AP 内不同的应用程序类型。

事实上决定应用程序启动和关闭的并不是EM 。SM (state management )才是控制着者。SM 会基于整个系统的设计命令EM , 仲裁不同的状态从而控制整个系统的行为。这里的系统指的是整个机器AP 和其应用程序的内部行为，因此SM的实现是基于特定项目的。SM 也会和其他功能模块交互来协调整个机器的行为。SM 应当使用标准的ARA 接口来维护不同的AP stack 之间的可移植行。

应用程序交互

关于AA之间的交互，PSE51并不包括IPC (inter process communication ),  因为并没有直接的接口实现AA 之间的交互。CM (communication management )提供机器内和机器之间面向服务的通信。不管服务和客户端程序的部署拓补结构，CM 都可以处理服务 request/replies 的路由。其他的ARA 接口也可以内部触发AA之间的交互，但是这并不是一个显示的通信接口，仅仅是其他ARA接口提供的一个附带功能。

非标准接口

AA和功能组合也可以调用非标准接口，只要他们和标准AP 功能不冲突，并且他们也能符合项目对safety 和security 的要求。特别是那些纯的应用程序本地运行库，尽量保证使用范围最小，因为它会影响其它AP 实现的软件可移植性。

3.2 物理架构

这里讨论的物理层架构仅以解释为目的，不包含任何的AP 的正式的软件需求。任何AP 实现的正式需求都会明确说明。

OS, 进程和线程

AP 操作系统必须能够提供多进程的POSIX OS . 每一个AA的实现都是一个独立的进程，有自己独立的逻辑内存空间和命名空间。一个单独的AA有可能包含多个进程，他们有可能部署成一个单独的实例或者分布式部署成多个AP 实例。从模块组织的角度，每个进程会被OS 实例成一个可执行文件。多个进程可以从一个可执行文件实例出来。并且一个AA 有可能包含多个可执行文件。

功能簇也被实现为进程。一个功能簇可以被实现成一个进程或多个进程。Adaptive 平台的服务和非adaptive的服务也被实现为进程。

所有的这些进程可以是单线程的1也可以是多线程的。根据这些进程所属的逻辑层的不同使用不同的OS API. 如果这些进程是运行在ARA 之上的进程，他们应该使用PSE51.如果这些进程是其中一个功能簇，可以自由使用OS 的API.

总而言之，从OS的角度，AP 和AA 只是一个进程的集合。每个进程包含一个或多个线程。尽管它们取决于AP的实现来提供任何类型的分区，但这些进程之间没啥差别。这些进程之间的交互通过IPC 或其它OS 可用的功能。说明一下，AA 进程也可能不用IPC 而仅通过ARA 通信

基于库或基于服务的功能簇的实现

根据图3-1的AP 逻辑架构，一个功能簇可以是一个Adaptive 平台的功能模块或是Adaptive 平台的服务。根据之前的描述，这些都是进程，需要通过IPC 和AA 进行交互。这里有两种方式可以实现。一个是基于库的设计。功能簇提供接口库，链接到AA, 直接调用IPC. 另外一种是基于service的设计。进程会使用CM的功能-有一个server代理库链接到AA。代理库调用CM接口，协调AA和Server进程之间的IPC。实现功能的时候可以定义是选择AA仅使用CM直接实现IPC或者使用server通过代理库实现IPC。

对于如何为功能簇选择设计，一个通用的指导意见是如果是本地单一AP实力，基于库的设计可能更合适因为它更简单且效率更高。如果是分别是的AP实例，建议使用基于service的色剂，因为CM提供透明的通信无论是否是本地的AA还是service.  属于Adaptive 平台的功能簇都是基于库的，Adaptive平台都是基于service就像名字所显示的那样。

最后，对于FC的实现是允许不以库的形式实现而不是以进程的方式实现，只要能满足FC定义的RS和SWS的需求。在这种情况下，AA和FC之间的交互就是一般的进程调用，而不是像之前描述的那样是基于IPC的。

功能簇之间的交互

通常来讲，FC之间可以交互以AP特定的实现方式，因为它们不给ＡＲＡ接口束缚。比如PSE51 禁止使用PIC。它可以使用其他FC的ARA public的接口。其他FC之间的接口，为了实现FC一些特殊的功能，可以使用protected 的接口提供优先访问权限.

并且，从AP 18-03开始，一个新的概念引入，是Inter-Functional-Cluster(IFC)。它描述了FC提供给其FC的接口。注意它既不是ARA的一部分, 也不包括AP 实现正式的规范需求。通过澄清FC 之间的接口，它的出现只是为了促进AP 规范的开发。对于AP规范的使用者来说，它提供了一个更好的AP 架构视图。这些接口的描述在对应的FC SWS 的附录中。

机器/硬件

AP 允许的硬件被称为一个machine。背后的原理是不论使用何种虚拟技术，都可以达成一个一致的平台。这个机器可以是一个真实的物理机器，也可以是一个虚拟机，或者是一个半虚拟化的OS, 或者是一个OS级别虚拟的container, 亦或者是其他虚拟环境。

硬件上面可以有一个或多个machine.一个machine 上运行一个CP 实例。一般假设就是一个硬件也就是一个芯片，上面运行一个或多个machine .如果AP 实现允许的话，也可以是多个芯片组成一个machine.

3.3 methodology

为了能够功能应用分布式，独立和敏捷开发，需要标准的开发方式。AUTOSAR adaptive方法论为像服务，应用，机器和配置这些东西提供标准和对应的task。这些对应的task定义了在adaptive平台上开发产品，不同的活动如何交互可以达到交换设计信息的目的。图3－3是一个草稿图，说明了adaptive的方法论是如何实现的。详细的细节在参考文档3中。

3.4 manifest

清单Manifest是AUTOSAR 模型的描述。它用来支持AUTOSAR AP产品的配置。Manifest可以上传到AP 产品，和它对应的文件比如二进制文件结合在一起。

Manifest的使用被限制在AP平台。但是这并不意味着在AP 项目开发过程中产生的ARXML会自动被认为是manifest. 事实上，在汽车项目组中，AUTOSAR AP 不是被唯一使用的。

一个典型的汽z车也包含许多部署CP 的ECU。因此，一个整车的系统设计是包含两者的，即部署CP的ECU 和部署AP的ECU.

原则上，manifest这个词可以定义为在概念上只有一个。所有的部署都可以在这个上下文中处理。这看起来显然是不合理的。因为模型相关的元素存在于典型项目开发的不同阶段。

这部分是应用设计的主要动机。把manifest 细分成三种不同的类型是很有必要的。

应用设计. 这种描述详细描述了适用AP 应用软件创建所有设计相关的部分。它不是必须部署在adaptive 平台机器上。但是应用设计在执行清单上和服务实例清单上能够帮助应用软件部署的定义。

执行清单。这种清单地方是用来详细说明AP应用程序运行时部署相关的信息。执行清单是和实际执行的code绑定在一起用来支持可执行程序在机器上的集成。

服务实例清单。这种清单是用来说明如何根据传输协议的要求面向服务的通信是如何配置的。服务实例清单是和实际的可执行code绑定在一起的来实现面向服务的的使用。

机器清单。这种清单应该用来说明运行AP应用程序的机器的部署相关的配置的。机器清单和创建AP实例的软件绑定在一起。

这种临时定义的不用清单的用处会导致困惑。大多数情况下不同的文件用来存储三中清单。

除了用用程序设计和三种不同的清单，AUTOSAR方法论还支持系统设计。用来描述AUTOSAR平台的软件模块。这些软件模块用来在一个系统中一个模型中。不同AUTOSAR平台的软件模块会以面向服务的形式互相通信。但是描述一个信号到服务的映射可以在面向服务的通信和信号通信之间搭建一座桥梁。

3.5 应用程序设计清单

应用程序的设计描述了所有AP应用软件创建的设计相关的模型。

应用设计关注一下几个方面。

* 数据类型用来说明软件设计和实现的信息

*服务接口作为面向服务的通信的关键元素。

*定义应用如何访问面向服务的通信。

*持久接口是访问持久数据和文件的关键元素

*定义用用程序如何访问持久存储。

*定义应用程序如何访问文件。

*定义应用程序如何访问加密软件

*定义应用程序如何访问PHM模块

*定义应用程序如何访问时间基数

*序列化属性用来定义如何序列化网络传输上的数据

*REST服务接口是通过REST模式与web服务通信的关键元素

*客户端和服务器功能的描述

*分组应用程序以简化软件的部署

*应用程序设计中定义的构件独立于应用程序软件的特定部署，从而简化了对不同部署场景的应用程序实现的重用。

3.6 执行清单

执行清单的目的是为了提供AP应用程序实际部署需要的信息。这种想法是为了尽可能的保持代码和特定的部署场景独立，以增加在不同的部署场景中重用应用程序软件的可能性。

使用可执行清单可以控制应用程序的实例化， 因此，

*在同一台计算机上多次实例化相同的应用程序软件

*将应用程序软件部署到多台计算机上，并为每台计算机实例化应用程序软件。

执行清单关注一下几个方面

* 启动配置，以定义如何启动应用程序实例。启动包括启动选项和访问角色的定义。每个启动可能依赖于机器状态和/或功能组状态。

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

3.7 服务实例清单

在网络上实现面向服务的通信需要特定于所使用的通信技术(例如SOME/IP)的配置。由于通信基础设施在服务的提供者和请求者上的行为应该相同，所以服务的实现必须保证双方都兼容。

服务实例清单关注以下几个方面。

*服务接口部署，以定义如何在特定的通信技术上表示服务。

*服务实例部署，为特定的服务实例定义所使用的通信技术要求的证书

*E2E保护的配置

*信息安全保护的配置

*Log和trace的配置

3.8 机器清单

机器清单允许配置在特定硬件(机器)上运行的实际AP实例。

机器清单关注以下几个方面

*配置网络连接和定义网络技术的基本证书(例如，对于以太网，这涉及到设置静态IP地址或定义DHCP)。

*服务发现技术的配置（比如，对于SOME/IP，这涉及所使用的IP端口和IP组播地址的定义）

*定义使用的机器状态

*定义使用的功能组

*自适应平台功能集群实现的配置(例如，操作系统提供具有特定权限的OS用户列表)

*配置密码平台模块

*配置PHM

*配置时间同步

*可用硬件资源的文档(例如可用内存大小;有多少个处理器核可用)