本系列学习笔记基于 AUTOSAR Adaptive Platform 官方文档 R20-11 版本 AUTOSAR_EXP_PlatformDesign.pdf
缩写
AP：AUTOSAR Adaptive Platform
AA：Adaptive Application
ARA：AUTOSAR Runtime for Adaptive Applications
FC：Functional Cluster
CM：Communication Management
RS：Requirement Specification
SWS：Software Specification
3.2 物理视图
本节内容仅为解释说明，不能替代正式需求规范，AP 内部仍由实现决定。更多关于 AP 内部架构细节，请参考 EXP_SWArchiteture。
3.2.1 系统、进程和线程
AP 操作系统必须提供 POSIX 多进程支持：
- 每个 AA 都是一个独立的进程，有独立的逻辑内存地址空间和命名空间
- 注意：一个 AA 可以有多个进程，可以部署在一个 AP 实例或分布在多个 AP 实例上
- 从模块组织的角度来看，每个进程都是 OS 从可执行文件实例化出来的
- 多个进程可以由一个可执行文件实例化
- AA 也可以由多个可执行文件组成
FC 一般实现为进程：
- 一个 FC 可以实现为单进程或多进程
- AP Service 或 非平台 Service（由 AA 提供的服务）都实现为进程
以上进程都可以是单线程/多线程。他们能用的 OS API 根据他们所在的逻辑层而不同：
- ARA 之上的 AA 只能用 PSE51
- 如果一个进程是 FC，能使用所有的 OS 接口
总结：在 OS 看来，AP 和 AA 都是一系列的进程，每个进程包括一个或多个线程，这些进程之间没有区别。尽管 AP 实现可以进行某种划分。进程之间通过 IPC 或其他系统功能（ara::com）交互。注意：AA 进程之间不能直接 IPC 进程间通信，只能通过 ARA 通信。
3.2.2 基于库或服务的 FC 实现
如图 3-1 AP 架构逻辑视图所示，一个 FC 可以是 Foundation 也可以是 Service。两者通常都是进程。他们如果想要和 AA（也是进程）通信，需要通过进程间通信。除此之外，还有两种方式：
- 基于库的设计：FC 提供接口库，链接到 AA，直接调用 IPC；
- 基于服务的设计：进程通过 CM 通信，AA 链接服务代理库。代理库调用 CM 的接口，处理 AA 和 Server 进程的通信。注意：AA 是否只和 CM 直接进程间通信还是混合代理库和 Server 通信是由实现决定的。
一般来说，如果 FC 只适用于本地 AP 实例，基于库的设计更合适，简单、高效。如果是分布式的场景，用于其他 AP 实例，建议使用基于服务的设计。因为 CM 可以封装差异，忽略 AA 和 Service 的位置，提供统一的通信方式。AP Foundation 的 FC 都是基于库的，AP Service 的 FC 都是基于服务的。正如他们的名字所指代的。
最后要注意，只要满足 FC 的 RS 和 SWS，FC 的实现可以只有库，没有进程，运行在 AA 的上下文。这种情况下，AA 和 FC 的交互就是普通的函数调用，而不是上面描述的 IPC。
3.2.3 FC 之间的交互
FC 之间可以按照实现特有的方式交互，因为他们不受限于 ARA 接口。比如 ARA 的 PSE51 接口限制，限制了 IPC。他们可以使用其他 FC 的 ARA public 接口。FC 之间典型的交互模型是使用 FC 的 protected 接口，提供一些特权，以实现特定的 FC 功能。
此外，从 AP R18-03 开始，引入了新的概念 IFC（Inter-Functional-Cluster）接口，描述了 FC 向其他 FC 提供的接口。注意，这不是 ARA 的一部分，也不是 AP 实现的正式规范。只是通过澄清 FC 之间的交互来帮助开发 AP 规范，并且向 AP 规范的用户提供了更好的架构视角。这些接口在各个 FC 的 SWS 附录中有介绍。
3.2.4 机器/硬件
AP 把运行它的硬件叫做机器（Machine），背后的原因是想有个统一的平台，不论底层使用了什么虚拟化技术。机器可以是真实的物理机器、完全虚拟化的机器、准虚拟化的系统、系统级虚拟化的容器或其他任意虚拟环境。
硬件（一般假定只有单一芯片）之上可以有一个或多个机器，一个机器上只能有一个 AP 实例。只要 AP 的实现支持，也可以多个芯片共同组成一个机器。