AUTOSAR AP是一个标准化的汽车中间件平台。它不仅包含通信中间件，还包含执行管理、持久化、诊断等完整的服务集群。它不是唯一的中间件，但在追求功能安全、跨域标准化的量产项目中，它是目前最主流的方案。
目录
一、核心定位：AP不是CP的升级版，而是互补品
在讲解架构前，必须先建立这个认知：
| 维度 | AUTOSAR CP（经典平台） | AUTOSAR AP（自适应平台） |
|---|---|---|
| 目标芯片 | MCU（微控制器） | SoC（系统级芯片）/ 多核高性能处理器 |
| 操作系统 | AUTOSAR OS（OSEK/VDK） | POSIX OS（Linux、QNX） |
| 编程语言 | C | C++11/14 |
| 架构范式 | 静态配置、编译期确定 | 动态部署、运行时发现 |
| 通信 | CAN/LIN/ETH（SOME/IP静态） | SOME/IP、DDS（动态服务发现） |
| 更新机制 | 全量刷写（通常需停产） | 增量OTA、SOTA |
| 适用场景 | 硬实时控制、功能安全（ASIL D） | 智能驾驶、高算力计算、V2X、OTA |
结论：CP管躯干，AP管大脑。座舱SoC上的QNX/Android运行AP框架，负责高算力、动态服务、与云端/智驾域的交互。
二、AUTOSAR AP 整体架构分层图
text
+---------------------------------------------------------------------+
| 应用层 (ARA::Application) |
| [自适应应用 1] [自适应应用 2] [自适应应用 3] [机器/深度学习应用] |
+--------------------------|------------------------------------------+
| ARA API（应用运行时环境接口）
+--------------------------v------------------------------------------+
| AUTOSAR AP 基础平台层 |
| +---------------------------------------------------------------+ |
| | 功能集群 (Function Clusters) | |
| | +-------------------+ +-------------------+ | |
| | | 执行管理 | | 通信管理 | ...更多集群 | |
| | | (Execution Mgmt) | | (Communication) | | |
| | +-------------------+ +-------------------+ | |
| | +-------------------+ +-------------------+ | |
| | | 身份认证 | | 持久化 | | |
| | | (Identity/M&C) | | (Persistence) | | |
| | +-------------------+ +-------------------+ | |
| +---------------------------------------------------------------+ |
| | 平台基础服务 (Platform Foundation) | |
| | [操作系统抽象层: POSIX PSE51] [C++运行时] [日志] | |
| +---------------------------------------------------------------+ |
+---------------------------------------|---------------------------+
|
+---------------------------------------v---------------------------+
| POSIX 操作系统 (QNX/Linux) |
| 硬件层 (ARM Cortex-A, RISC-V) |
+-------------------------------------------------------------------+层级解释：
- 硬件层：ARM A系列核（Cortex-A55/A76）、RISC-V、英伟达Orin、高通SA系列
- OS层：必须支持POSIX PSE51子集，典型代表QNX（功能安全）、Linux（非安全，用于智驾预处理）
- 平台基础服务：OS抽象、C++标准库、Log、DLT
- 功能集群：AP核心模块，以独立进程/组件形式提供标准化服务
- ARA（AUTOSAR运行时）：应用调用功能集群的唯一入口，本质是C++头文件+动态链接库
- 应用层：基于AP框架开发的自适应应用（AA），可实现动态加载/卸载
三、核心功能集群详解（AP的“器官”）
AP不叫“模块”，叫功能集群（Function Cluster）。每个集群通常以独立守护进程形式运行。
1. 执行管理（Execution Management）—— 最核心、AP的“大脑”
角色：应用的生命周期管理者。替代CP的RTE+OS，但更动态。
核心职责：
- 应用启动：不是从main()开始。EM解析manifest，确定启动顺序、依赖关系、资源限制
- 状态管理：定义系统级状态（Startup、Shutdown、Restart、Update）
- 资源监控：CPU、内存超限时主动kill应用（类似systemd但更严格）
- 平台健康管理：与看门狗协同，检测应用卡死
关键机制：
- Manifest文件：每个AP应用附带，XML/JSON格式，声明（需要多少内存、依赖哪些服务、允许访问哪些路径）
- 函数钩子：
Initialize()、Run()、Terminate()，EM按状态机调用
类比：QNX的procnto + systemd + k8s的Pod控制器。
2. 通信管理（Communication Management）—— AP的“神经”
角色：跨进程、跨节点（域间、车云）通信中间件。
核心职责：
- 服务发现：动态的！应用启动后广播“我在这里，提供XX服务”，消费者动态查找
- 协议转换：SOME/IP、DDS、HTTP（部分厂商扩展）
- 序列化：SOME/IP的Payload编解码
突破CP的限制：
- CP的通信矩阵是Excel表格，编译时生成代码，不可变
- AP的服务接口是ARXML定义 + 动态绑定，OTA后可新增服务
典型场景：
- 智驾域启动“感知融合服务”
- 座舱域（AP框架）通过通信管理动态发现
- 订阅车道线、障碍物数据，渲染在仪表/AR-HUD
3. 持久化（Persistence）—— AP的“记忆”
角色：提供键值存储（K/V Store）和文件存储接口。
关键点：应用不感知存储位置。可以是内存、闪存、外部云端，由平台策略决定。
CP vs AP：
- CP：NVRAM，固定地址，编译分配
- AP：持久化集群，应用请求
"user.setting.seat_position"，平台返回存储句柄
4. 身份与访问管理（Identity and Access Management）
角色：AP的安全闸门。
核心机制：
- 应用签名：只运行经私钥签名的ELF文件
- 权限控制：基于POSIX Capabilities或更细粒度的权限Token
- 加密服务：不是自己调用OpenSSL，而是通过IAM向硬件安全模块（HSM）申请加解密
设计哲学：AP假设系统可能被攻破，但攻击者无法窃取密钥（密钥不出HSM）。
5. 诊断（Diagnostics）—— CP的UDS继承者
角色：UDS over IP（DoIP）。
不同点：
- CP诊断：静态DTC定义，Flash驻留
- AP诊断：支持动态加载诊断插件，云诊断会话
典型用例：OTA失败后，AP诊断集群主动上传日志片段，云端分析后下发修复策略。
6. 状态管理（State Management）—— 非独立集群，但与EM深度耦合
角色：定义整车级抽象状态。
CP时代：KL15硬线直接拉低MCU中断。
AP时代：状态是服务。
典型状态机（OEM自定义）：
text
OFF → ACC → RUNNING → SLEEP → SHUTDOWN
↓ ↓
[中控亮] [智驾启动]状态管理接收来自MCU（通过通信集群）的硬线信号，转换为服务状态，通知所有订阅的应用进入对应状态。
7. 更新与配置管理（UCM）—— OTA落地者
角色：刷写软件包、回滚、增量更新。
技术栈：
- 接收云端OTA包（通常是压缩的
*.pkg） - 校验签名、解包
- 调用执行管理：停止目标应用、备份旧版本、写入新二进制、重启应用
- 失败则执行回滚
为什么这是集群？
因为必须标准化。OEM不能每家自己写刷写逻辑，否则Tier1没法适配。
四、ARA：自适应应用接口
ARA不是一层厚API，而是一组C++头文件 + 动态链接库。
cpp
#include <ara/exec/execution_client.h>
#include <ara/com/service_client.h>
int main() {
// 1. 向执行管理报告状态
ara::exec::ExecutionClient exec_client;
exec_client.ReportExecutionState(ara::exec::ExecutionState::kRunning);
// 2. 发现远程服务
auto proxy = ara::com::ServiceProxy::Create("SomeIP", "VehicleSpeedService");
// 3. 订阅事件
proxy->SubscribeEvent(/* callback */);
}关键特征：
- 标准化：所有AP兼容平台都提供这组头文件
- 非侵入式：应用代码里不包含
#include <qnx/qnx_specific.h>，只包含ara/* - 动态链接：不同OEM的底层实现不同（Vector/EB/自研），但对应用透明
五、CP vs AP：真正的并存关系
不是替代，是分工。
并存架构图（真实车辆）
text
+--------------------+ +---------------------+
| 智驾域 (AP) | | 座舱域 (AP + 原生) |
| - 传感器融合 | <-以太网-> | - 服务发现 |
| - 规划控制 | SOME/IP | - 状态同步 |
| - 高精地图 | | - 与Android通信 |
+---------|----------+ +----------|----------+
| |
SOME/IP | 车云通信 SOME/IP | CAN网关
| |
+---------v----------+ +----------v----------+
| 底盘/动力域 (CP) | | 车身域 (CP) |
| - ESP | | - 门窗 |
| - EPS | CAN | - 空调 |
| - BMS | | - 座椅 |
+--------------------+ +---------------------+典型拓扑：
- CP域：硬实时控制，周期1-10ms
- AP域：高性能计算，部署于智驾/座舱SoC，通信周期100ms级
- 网关：CP与AP通过SOME/IP网关翻译（通常由座舱MCU或独立网关执行）
六、AP在座舱SoC上的实际落地形态
注意： 座舱SoC（SA8155/8295）上运行的QNX/Linux + Android，AP是嵌在其中的一层中间件，不是替代QNX/Android。
方案1：QNX + AP（仪表/安全域）
- QNX Neutrino（POSIX兼容）
- 运行Vector/EB的AP平台实现
- 应用：ADAS告警渲染、车速融合、HMI状态机
- 通信：与MCU走SOME/IP，与Android走Socket
方案2：Linux + AP（非安全域）
- Linux Yocto（PREEMPT_RT）
- 运行AP核心集群（通信、持久化、诊断）
- 应用：数据采集、云端交互、日志上传
方案3：Android + AP库（娱乐域）
- Android不直接运行AP框架（太重、权限冲突）
- 方案：在Native层封装AP通信库
- 通过JNI给Java层调用，实现“Android App发现智驾域服务”
七、总结：如何理解AUTOSAR AP
| 问题 | 答案 |
|---|---|
| AP是操作系统吗？ | 不是。它跑在QNX/Linux上，是中间件 |
| AP是CP的V2.0吗？ | 不是。CP管MCU，AP管SoC，互补 |
| AP的核心贡献？ | 将SOA引入车控域，让服务可发现、可动态部署 |
| 我需要在Android层写AP代码吗？ | 通常不直接写。但需要通过AP通信库调用智驾域服务 |
| 座舱工程师要懂AP到什么程度？ | 理解服务发现机制，能看懂ARXML接口定义，会跨域联调SOME/IP |
一句话定义：
AUTOSAR AP是运行在POSIX操作系统上、面向高性能计算和动态服务架构的汽车标准化中间件平台，它让“软件定义汽车”在架构层面成为可能。
0 条评论