引言
2017 年 AUTOSAR 发布 Adaptive 平台,动机很直接:Classic 为 MCU 设计,静态配置、无动态内存、单进程模型,无法承载自动驾驶的高算力需求(几十 TOPS 的 SoC)、无法支持 OTA 动态更新应用、无法用现代 C++ 与多进程架构。Adaptive 的目标是「面向服务的、可动态部署的、跑在 POSIX 系统上的 C++ 平台」。
Adaptive 与 Classic 不是替代关系,而是分工:Classic 继续跑在 MCU 上做安全关键控制,Adaptive 跑在高性能 SoC 上做感知、融合、座舱与云端通信,两者通过 SOME/IP 网关连接。一个中央计算平台里,可能同时有 Classic ECU、Adaptive 机器、以及 QNX/Linux 上的非 AUTOSAR 应用。
工程难点在于「动态性」带来的复杂性:服务可以动态发现、应用可以动态加载、进程可能崩溃需要监督。这与 Classic 的静态确定性截然相反,需要一套全新的运行时管理机制(EM、SM、PHM)。本文逐层拆解。
目录
- 从 Classic 到 Adaptive 的演进动机
- Adaptive 架构与 ARA 功能集群
- 执行管理 EM 与状态管理 SM
- 通信管理 CM 与 SOME/IP 服务
- 持久化与更新配置管理
- C++14/17 与 POSIX PSE51 编程模型
- 与 Classic 的共存与网关
- 信息安全与平台健康管理
- 典型部署与性能调优
1. 从 Classic 到 Adaptive 的演进动机
两代平台的差异是根本性的:
| 维度 | Classic | Adaptive |
|---|---|---|
| 目标硬件 | MCU(AURIX、S32K) | 高性能 SoC(Orin、8295) |
| 操作系统 | AUTOSAR OS(OSEK) | POSIX PSE51(Linux/QNX) |
| 语言 | C(MISRA) | C++14/17 |
| 内存 | 静态分配 | 动态分配(受控) |
| 执行模型 | 单进程、静态任务 | 多进程、动态调度 |
| 通信 | 信号(S/R) | 服务(SOA、SOME/IP) |
| 部署 | 静态编译 | 动态加载/更新 |
| 更新 | 整 ECU 刷写 | 应用级 OTA |
| 认证 | ASIL D | 到 ASIL B(多为 QM) |
Adaptive 引入的关键能力:动态部署(应用可作为独立包安装/卸载)、服务发现(运行时找到服务提供者)、进程隔离(一个应用崩溃不影响其他)、OTA 友好(应用级更新)。
2. Adaptive 架构与 ARA 功能集群
Adaptive 用 ARA(AUTOSAR Runtime for Adaptive Applications)定义运行时接口,按功能集群(Functional Cluster)组织:
Adaptive 应用(AA)
↓ 使用 ARA 接口
┌──────────────────────────────────────┐
│ ARA 功能集群 │
│ Execution Management (EM) 执行管理 │
│ State Management (SM) 状态管理 │
│ Communication Management (CM) 通信 │
│ Persistency (PER) 持久化 │
│ Update & Configuration Mgmt (UCM) 更新│
│ Platform Health Mgmt (PHM) 健康管理 │
│ Cryptography (CRYPTO) 加密 │
│ Identity & Access Mgmt (IAM) 访问控制 │
│ Diagnostics (DM) 诊断 │
│ Time Synchronization (TS) 时间同步 │
│ Network Management (NM) 网络管理 │
├──────────────────────────────────────┤
│ 操作系统:POSIX PSE51(Linux/QNX) │
├──────────────────────────────────────┤
│ 硬件:多核 SoC + Hypervisor │
└──────────────────────────────────────┘
功能集群是可选的:一个最小 Adaptive 系统只需 EM + CM + 一个应用;完整系统会启用十几个集群。选型时按需裁剪,减少认证负担。
3. 执行管理 EM 与状态管理 SM
EM 负责进程的启动、监控、终止,是 Adaptive 的「init」:
EM 职责:
1. 解析执行清单(Execution Manifest)
- 每个进程的可执行路径、参数、依赖
2. 按依赖顺序启动进程
3. 监控进程健康(配合 PHM)
4. 处理进程终止与重启
5. 管理 Machine State(Startup / Running / Shutdown)
执行清单示例(ARXML 概念):
Process: PerceptionApp
Executable: /opt/apps/perception/bin/perception
Args: --config /etc/perception.json
DependsOn: SensorDriver, CameraService
StartupOption: AfterDependencies
NumberOfRestarts: 3
SM(状态管理):
定义整机状态机(如 Startup → Driving → Parking → Shutdown)
状态切换时通知各应用(通过 Function Group State)
应用可注册状态回调,在进入/离开某状态时执行动作
示例状态机:
MachineState: Startup
→ Running
→ FunctionGroup: Driving / Parking / Charging
EM 与 SM 配合,实现「整车状态驱动的应用生命周期管理」——进入驾驶状态才启动感知应用,进入充电状态才启动充电应用。
4. 通信管理 CM 与 SOME/IP 服务
CM 是 Adaptive 的服务通信层,底层用 SOME/IP(或 DDS):
CM 概念:
Service:一组方法(Method)、事件(Event)、字段(Field)
Provided Service Instance:服务提供者
Required Service Instance:服务消费者
Service Discovery:运行时发现服务
CM API 示例(C++):
// 提供方
auto service = ara::com::Service::CreateInstance(...);
service->OfferService();
// 消费方
auto proxy = ara::com::FindService<MyServiceProxy>(...);
proxy->MyMethod(arg).GetResult(); // 同步调用
auto future = proxy->MyMethodAsync(arg); // 异步
// 订阅事件
proxy->MyEvent.Subscribe(10); // 队列深度 10
proxy->MyEvent.SetReceiveHandler([&](){
proxy->MyEvent.GetNewSamples([](auto sample){
// 处理
});
});
CM 的配置在服务清单(Service Manifest)里,包括事件组、队列深度、E2E 保护、序列化方式。服务发现用 SOME/IP-SD(组播),配错会导致服务找不到。
5. 持久化与更新配置管理
Adaptive 的两个特有集群:
Persistency(PER):
提供键值存储与文件存储
- Key-Value Storage:小数据(配置、状态)
- File Storage:大文件(地图、模型)
底层映射到文件系统(ext4 / QNX fs)
支持冗余与一致性(掉电不损坏)
API:
auto storage = ara::per::OpenKeyValueStorage("config");
storage->SetValue("last_mode", 3);
auto v = storage->GetValue<int>("last_mode");
Update & Configuration Management(UCM):
管理软件包的安装、更新、回滚
- 接收软件包(UCM Master 下发)
- 校验签名与完整性
- 安装到指定分区
- 激活(activate)与回滚
流程:
TransferStart → TransferData → TransferExit
→ ProcessSwPackage(校验、解包)
→ Activate(切换分区)→ 重启应用
UCM 让 Adaptive 支持应用级 OTA:只更新某个应用包,不必刷整机。
6. C++14/17 与 POSIX PSE51 编程模型
Adaptive 用现代 C++,但受 POSIX PSE51 子集约束:
允许的 C++ 特性:
C++14/17 标准库(部分)
智能指针、RAII、lambda、模板
异常(受控使用,部分平台禁用)
std::thread、std::mutex、std::chrono
POSIX PSE51 约束(实时安全子集):
允许:pthread、mutex、condvar、clock、sched
禁止:fork、exec、文件系统任意访问
禁止:动态加载任意库(受 IAM 管控)
限制:内存分配(受控的堆)
进程模型:
每个 Adaptive 应用是一个进程
进程间用 SOME/IP(跨机)或共享内存(同机)
进程隔离:一个崩溃不影响其他(由 EM/PHM 监督)
示例(一个 Adaptive 应用的骨架):
#include <ara/exec/execution_client.hpp>
#include <ara/com/service_proxy.hpp>
int main() {
// 向 EM 报告启动完成
ara::exec::ExecutionClient ec;
ec.ReportExecutionState(
ara::exec::ExecutionState::kRunning);
// 创建服务代理
auto proxy = ara::com::FindService<...>();
// ... 业务逻辑
return 0;
}
异常策略是常见分歧点:安全关键应用倾向禁用异常(用错误码),普通应用可用异常。
7. 与 Classic 的共存与网关
一个整车同时有 Classic 与 Adaptive 节点,靠网关桥接:
共存架构:
MCU(Classic)←→ 网关 ←→ SoC(Adaptive)
CAN/以太网
网关职责:
1. 信号 ↔ 服务转换
CAN 信号(刹车状态)→ SOME/IP 事件
SOME/IP 方法调用 → CAN 报文
2. 时间同步:把 CAN 时间戳映射到 gPTP 时基
3. E2E 保护:跨域时保持端到端保护
数据流示例:
轮速传感器(Classic ECU,CAN 报文)
→ 网关解析 CAN 信号
→ 打包为 SOME/IP 事件(VehicleSpeed)
→ Adaptive 感知应用订阅
→ 融合结果回传
→ 网关拆成 CAN 报文 → 执行器 ECU
网关的延迟要计入端到端预算(通常 5~20 ms),且要做限流防止跨域风暴。
8. 信息安全与平台健康管理
Adaptive 的安全机制与 Classic 不同:
IAM(Identity and Access Management):
基于应用身份的访问控制
应用有唯一身份(证书/密钥)
访问资源(服务、文件)需授权
类似 Linux 的 SELinux,但面向车载
Crypto(CRYPTO):
提供加解密、签名、哈希 API
底层用 HSM(硬件安全模块)或 TEE
密钥存储在安全区,不可导出
SecOC:报文认证(主要在 Classic 侧)
PHM(Platform Health Management):
监督应用与进程健康
- Alive Supervision:进程按周期上报心跳
- Deadline Supervision:检查执行是否超时
- Logical Supervision:检查执行顺序
- Health Channel:应用主动上报健康状态
失败动作:重启进程、切换功能组状态、进入降级模式
PHM 是 Adaptive 的「看门狗」,是功能安全(ASIL B)的关键机制。
9. 典型部署与性能调优
Adaptive 部署在高性能 SoC 上,性能调优有独特之处:
典型部署(Orin 上):
QNX Hypervisor
├─ VM1: QNX + Adaptive(安全域,ASIL B)
└─ VM2: Linux + Adaptive(智驾域,QM)
性能调优点:
1. 进程绑核(CPU affinity),避免跨核迁移抖动
2. 内存:预分配 + 内存池,避免运行时分片
3. 通信:同机用共享内存(零拷贝),跨机用 SOME/IP
4. 序列化:SOME/IP 用固定布局,避免运行时反射
5. 线程优先级:通信线程 > 计算线程 > 日志线程
6. 实时调度:SCHED_FIFO 用于关键线程
启动时间优化:
延迟启动非关键应用(EM 的依赖管理)
并行启动无依赖应用
应用预热(预加载库)
Adaptive 应用的启动时间通常 100 ms~1 s,比 Classic 的毫秒级慢,因为涉及进程创建与库加载。
权衡取舍
| 决策点 | 选项 A | 选项 B | 建议 |
|---|---|---|---|
| 平台 | Classic | Adaptive | 硬实时用 Classic,SOA/高性能用 Adaptive |
| 通信 | SOME/IP | DDS | AUTOSAR 生态用 SOME/IP,大数据用 DDS |
| 异常 | 启用 | 禁用 | 安全关键禁用,普通应用可启用 |
| 同机通信 | 共享内存 | SOME/IP | 同机大流量用共享内存,跨机用 SOME/IP |
| 部署 | 单体 | 多进程 | 多进程隔离好,但启动慢、通信开销大 |
| 安全 | IAM + Crypto | 仅 Crypto | 多应用共存必须 IAM 做访问控制 |
常见坑清单
- 用 Classic 思维写 Adaptive:静态分配、单进程,浪费了平台能力,也不满足动态部署需求。
- 服务发现配错:组播地址或端口不一致,服务找不到,需全车统一 SD 配置。
- 进程不绑核:跨核迁移导致抖动,关键进程必须设 CPU affinity。
- PHM 未配置:进程崩溃无监督,安全域不可用,ASIL B 必须配 Alive/Deadline 监督。
- 异常在实时路径抛出:栈展开耗时不可控,关键路径用错误码。
- UCM 不做回滚:更新失败导致应用不可用,必须支持 activate/rollback。
- 共享内存无同步:多进程读写竞争,需用信号量或原子操作保护。
- 序列化用反射:性能差且不可预测,用固定布局的静态序列化。
- IAM 授权过宽:应用能访问不该访问的资源,按最小权限原则配置。
- 时间同步未接入:Adaptive 与 Classic 时基不一致,跨域数据时间戳错位。
小结
AUTOSAR Adaptive 是「面向服务的、动态部署的 C++ 平台」,与 Classic 形成互补:Classic 守住硬实时与 ASIL D 的 MCU 阵地,Adaptive 承接高性能 SoC 上的 SOA 应用。它的核心是 ARA 功能集群——EM 管进程、SM 管状态、CM 管通信、PHM 管健康、UCM 管更新。
入门路径:先理解 ARA 与功能集群的划分,再学 EM/SM 的应用生命周期,然后深入 CM 与 SOME/IP 服务,最后接触 UCM 与 PHM。Classic 的对照阅读见 AUTOSAR Classic 平台与 RTE ;服务通信细节见 SOME/IP 与车载中间件 ;OTA 落地见 车载 OTA 升级与安全 。
Adaptive 的进程与线程模型建立在 POSIX 之上,Linux 容器隔离机制 有助于理解进程隔离的边界;C++ 的 ABI 与二进制兼容问题则需另行查阅。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。