官方文档下载方式及介绍情参见 Adaptive AUTOSAR 学习笔记 2 - 官方文档下载及阅读建议。

这是 Adaptive AUTOSAR 学习笔记的第 8 篇，学习笔记 3 - 7 翻译了 Adaptive AUTOSAR 官方文档 AUTOSAR_EXP_PlatformDesign.pdf 的前三个章节。继续学习之前先做个总结回顾（没有严格遵循原文内容，增加了些源自实际项目的理解）：

缩写

AP：AUTOSAR Adaptive Platform
AA：Adaptive Application
ARA：AUTOSAR Runtime for Adaptive Applications
FC：Functional Cluster
EM：Execution Management
SM：State Management
CM：Communication Management

2 技术范围和方法

传统 CP 无法满足新 ECU 的需求。AP 提供了：

高性能计算和通信机制
灵活的软件配置

2.2 技术驱动

以太网：高带宽，交换网络、传输效率高
处理器：众核、异构计算（GPGPU、FPGA、硬件加速）的发展、电源效率的提升

2.3 AP 特征

C++
SOA 面向服务的架构
并行计算
利用先用标准
功能安全和信息安全
计划动态：限制某些动态配置(?)
敏捷开发

2.4 CP、AP 以及非 AUTOSAR ECU 的集成

AP 不是取代 CP 以及非 AUTOSAR 的 ECU，而是互相协作。

3 架构

3.1 逻辑视角

3.1.1 ARA

AA 运行于 ARA 之上。ARA 由 FC 提供的接口组成。FC 接口有两种：

Foundation（之前很多资料称之为 API）：提供 AP 基础功能，AA 可直接调用 library 的 API
Service：提供 AP 平台标准服务，通过 SOA（ara::com）提供服务接口

AA 也可以向其他 AA 提供服务。

FC 的接口，不论是 Foundation 还是 Service，在 AA 看来都是一些 C++ 接口（虽然 ARA 接口之下确有不同）。注意：ARA 接口之下，包括 AA 链接的 ARA 库，可以使用 ARA 之外的接口。

ara::diag 在 R19-11 之前是 Service，从 R19-11 开始，改为 Foundation。

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

C++ 标准库包含很多基于 POSIX 的接口，包括多线程 API。但是 C++ 标准库没有覆盖所有 PSE51 API，比如设置线程调度策略。

3.1.3 应用启动关闭

应用的生命周期由 EM （Execution Management）控制。但 EM 本身不做决策，而是由 SM（State Management）决定什么时候启动/停止应用。

OS 启动 EM，EM 根据 Manifest 启动其他 FC 以及应用。在 EM 看来所有其他的 FC 都是应用。

3.1.4 应用接口

PSE51 不含 IPC，AA 之间不能直接通信，只能通过 CM（Communication Management）。CM 提供基于服务的通信，支持本机和跨机器通信（对应用来说是是透明的）。

3.1.5 非标接口

AA 和 FC 可以使用非标接口，只要不和标准 AP 功能冲突。除非是纯本地的运行库，尽量少用非标接口，以保证可移植性。

3.2 物理视角

3.2.1 操作系统，进程和线程

AA 都是一个或多个独立的进程
FC 一般实现为一个或多个进程（言外之意可以是库）
所有 Service 都是进程（包括 FC 提供的 Platform Service 和 AA 提供的 Non-PF Service）
所有进程可以是单线程，也可以是多线程
ARA 之上的 AA 只能使用 PSE51 系统 API；FC 可以使用任何系统 API
从系统看来，AP 和 AA 都是进程，AA 不能直接使用 IPC，只能通过 ARA 通信

3.2.2 基于库或基于服务的 FC 实现

FC 可以是 Foundation 模块，也可以是 Service。Foundation 和 Service 一般都是进程，如果要和 AA 进程通信，需要 IPC。有两种替代设计：

基于库：AA 链接 FC 的接口库，FC 接口库直接调用 IPC
基于服务：AA 链接服务 Proxy 库，Proxy 库调用 CM 的接口，间接实现进程间通信

如何选择取决于 FC 实现：基于库简单、高效；基于服务支持跨 AP 实例服务调用。

注意：FC 可以只有库，没有进程！此时 FC 库运行于 AA 的进程上下文中，对 AA 来说，就是普通的函数调用，不涉及 IPC。

3.2.3 FC 之间的交互

FC 之间的交互不受限于 ARA 接口（如 PSE51）
FC 可以使用其他 FC 的 public ARA 接口
更常见的是 FC 使用其他 FC 的 protected 接口，相比 public 的 ARA 接口，多一些特权

3.2.4 机器/硬件

运行 AP 的硬件在 AP 中统称为 Machine
可能是一个真实的物理机器，也可能是完全虚拟机、准虚拟系统或容器
一个 Machine 上只运行一个 AP 实例
一个 chip 上运行一个或多个 Machine（也可能多个 chip 组成一个 Machine）

3.3 方法论和 Manifest

AP 方法论包含两部分：

ARXML（用于描述、配置的 Application Design、Execution Manifest、Service Instance Manifest 以及 Machine Manifest）的标准化
定义上述 ARXML 之间如何交互以交换设计信息

方法论影响着开发流程：

大致步骤如下：

在 AP 工具链/平台配置工具中配置平台、目标硬件信息，如处理器型号、核心数、机器 IP 地址、SOME/IP 端口等信息，生成 Machine Manifest
在 AP 工具链/应用设计工具中定义服务，如数据类型、服务接口、组件等

a) AP 工具链自动生成 Application Design 的 ARXML 文件

b) AP 工具链/代码生成器基于 Application Design 的 ARXML 生成 Proxy 和 Skeleton 的 .h 和 .cpp 文件
软件开发

a) Service 应用实现 Skeleton 的接口

b) Client 应用通过 Proxy 类（经由 CM）间接调用 Service

c) 编译生成可执行文件
软件集成：在 AP 工具链/可执行文件配置工具中配置可执行文件路径、实例（进程）数、启动参数、环境变量、调度策略、UID/GID 等信息，生成 Execution Manifest
AP 工具链提取 Application Design 中的服务接口信息，在服务实例配置工具中添加额外的 SOME/IP 配置，如 Service ID，Method ID，Event ID 等，生成 Service Instance Manifest
上述可执行文件、Execution Manifest、Service Instance Manifest 作为一个 SW Package 上传到目标硬件

a) 目标硬件中 SW Configuration Management 根据 Manifest 信息部署、验证、安装应用

b) 根据 AP 平台的实现，可以（不强制）预处理 Manifest 文件，如导入数据库，以提高执行效率

c) EM 根据 Execution Manifest 的信息调用 OS API 启动、配置、关闭应用（FC 以及 AA）

3.4 Manifest

Manifest 代表了 AUTOSAR 模型描述，上传到 AP，用于配置 AP。AP 中的 ARXML 不都是 Manifest，比如 Application Design。

3.5 Application Design

应用设计建模，定义数据类型、接口、组件等信息，不需要部署到 AP 机器上，但组件、接口信息会被 Execution Manifest 和 Service Instance Manifest 引用。

3.6 Execution Manifest

定义每个可执行文件实例化几个进程，每个进程的的启动参数、环境变量、UID/GID、资源组、调度策略、何时启动、停止等都可以独立配置。

3.7 Service Instance Manifest

针对特定的传输协议（如 SOME/IP），进行面向服务通信的配置。如 Service ID，Method ID，Event ID，端口等。

3.8 Machine Manifest

描述运行 AUTOSAR AP 的机器。如硬件资源描述（RAM、处理器、核心数）、以太网 IP 地址（静态分配或者 DHCP 动态分配），SOME/IP 端口、机器状态定义（On/Off/Start/Restart/Shutdown...）等。

Adaptive AUTOSAR 学习笔记 8 - 干货小结：背景、技术、特征、架构、方法论和 Manifest

缩写