3.Adaptive AUTOSAR 架构详解

TTomcat

已于 2022-10-11 16:02:17 修改

阅读量3.4k

点赞数 3

分类专栏： Adaptive Autosar 文章标签：架构 java 网络

于 2021-08-11 09:52:29 首次发布

Adaptive Autosar 专栏收录该内容

21 篇文章 82 订阅

订阅专栏

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中。