3. AUTOSAR Classic与Adaptive在Stellar上的协同
Stellar 系列 MCU 的一个关键特征，是在同一颗芯片上同时提供实时锁步核（如 Cortex-R52）与高性能应用核（如 Cortex-A 系列），并配有硬件隔离单元、共享内存与跨核通信外设。这种异构多核结构天然适合承载混合 AUTOSAR 栈：Classic AUTOSAR 运行在实时核上，负责毫秒级甚至微秒级的确定性控制；Adaptive AUTOSAR 运行在应用核上，负责高算力、面向服务的计算任务。理解两者的匹配关系与划分原则，是域控制器软件架构设计的起点。
一、为什么需要混合 AUTOSAR 栈
传统分布式 ECU 中，Classic AUTOSAR 已经能覆盖动力、底盘、车身等大多数控制需求。但域控制器把多个 ECU 的功能集中到一颗芯片后，出现了两类 Classic 不擅长的工作：一是需要 POSIX 环境、动态调度、大内存和丰富中间件的应用，例如感知融合、OTA 管理、诊断服务聚合；二是需要面向服务通信（SOA）的整车级功能编排。Adaptive AUTOSAR 正是为这类需求设计的，它提供 POSIX PSE51 接口、ara::com 服务通信、执行管理（EM）、状态管理（SM）和更新配置管理（UCM）。
但 Adaptive 并不适合替代 Classic 做硬实时控制。它的调度基于操作系统，抖动和延迟难以保证到微秒级，功能安全等级通常到 ASIL-B，而 Classic 配合锁步核可支撑 ASIL-D。因此 Stellar 上的合理做法不是二选一，而是让两者各司其职、通过明确的边界协同。
二、Stellar 多核与两类 AUTOSAR 的匹配关系
从硬件资源看，Stellar 的实时核集群通常运行 Classic AUTOSAR：OS 采用 OSEK/AUTOSAR OS，调度表驱动，任务周期可设为 1 ms、5 ms、10 ms；通信走 CAN/CAN FD、LIN、FlexRay 或以太网的 Classic 栈（Com、PduR、CanIf、EthIf）；诊断走 Dcm/Dem；存储走 NvM/Fee。应用核集群运行 Adaptive AUTOSAR：Linux 或 QNX 作为宿主 OS，之上是 ara::exec 启动的 Adaptive 应用（AA），通过 ara::com 做服务通信，通过 ara::diag 做诊断，通过 ara::ucm 做 OTA。
两者之间不是孤立的。Stellar 提供核间通信硬件通道，例如共享内存加消息控制器、IPC 中断、以及部分型号上的以太网交换或 PCIe。混合栈的协同就建立在这些通道之上。下图给出一个典型的匹配关系：左侧实时核承载 Classic 栈，右侧应用核承载 Adaptive 栈，中间通过共享内存与 IPC 连接，并由 Hypervisor 或硬件隔离单元划分资源。
三、混合栈的划分原则
划分不是按“哪个核空闲”来分，而是按功能属性、实时性、安全等级和通信模式四个维度判断。以下原则可直接用于域控制器的软件架构评审。
原则一：硬实时闭环留在 Classic。凡是控制周期小于 10 ms、抖动要求小于 100 μs、且直接驱动执行器的闭环，例如电机电流环、制动压力控制、安全气囊点火，必须放在实时核的 Classic 栈中。Adaptive 的 POSIX 调度无法保证这种确定性。
原则二：ASIL-D 安全逻辑留在 Classic。功能安全等级达到 ASIL-C/D 的监控、冗余比较、安全状态切换，应运行在锁步核上，由 Classic 的 OS 和应用共同实现。Adaptive 侧通常只承担 ASIL-B 及以下的非安全关键任务，或作为 QM 级辅助计算。
原则三：面向服务的通信放在 Adaptive。需要动态发现、按需订阅、跨域编排的服务，例如“车辆进入迎宾模式”这类涉及多个域控制器的场景，适合用 ara::com 的 SOME/IP 服务实现。Classic 侧则继续使用信号导向的 Com 通信，保持与现有 ECU 的兼容。
原则四：大数据吞吐与算法迭代放在 Adaptive。摄像头、激光雷达的点云处理，OTA 包解压与校验，日志聚合与远程上传，这些任务数据量大、算法更新频繁，放在 Adaptive 侧可以利用 POSIX 生态和容器化部署，避免每次改动都重新生成 Classic 代码。
原则五：跨核交互必须定义清晰接口。Classic 与 Adaptive 之间的每一次数据交换，都应通过共享内存的固定布局或 IPC 消息格式约定，并明确方向、周期、超时和失效处理。典型做法是在共享内存中划分信号区，Classic 侧以 10 ms 周期写入车辆状态，Adaptive 侧读取后用于服务决策；反向则由 Adaptive 写入规划结果，Classic 侧读取后作为控制目标。
四、一个可参考的划分示例
假设某 Stellar 域控制器同时管理动力与车身，可按下表划分。表中参数为教学示例，实际项目需根据芯片型号和整车需求调整。
| 功能 | 所属栈 | 运行核 | 周期/触发 | 安全等级 | 通信方式 |
|---|---|---|---|---|---|
| 电机扭矩控制 | Classic | R52 核0 | 1 ms | ASIL-D | CAN FD 信号 |
| 制动压力闭环 | Classic | R52 核1 | 1 ms | ASIL-D | CAN FD 信号 |
| 车身灯光控制 | Classic | R52 核0 | 10 ms | ASIL-B | LIN / CAN |
| 诊断服务聚合 | Adaptive | A 核0 | 事件触发 | QM | ara::diag / DoIP |
| OTA 包管理 | Adaptive | A 核0 | 事件触发 | QM | ara::ucm / HTTPS |
| 驾驶模式服务 | Adaptive | A 核1 | 100 ms | ASIL-B | ara::com / SOME/IP |
| 车辆状态共享 | 跨核 | 共享内存 | 10 ms 写入 | — | 共享内存 + IPC 中断 |
五、协同中的关键约束
混合栈落地时，有三个约束最容易出问题。第一是启动顺序：Classic 侧通常先启动，完成基础通信和安全监控后，再释放 Adaptive 侧的启动信号，避免应用核在车辆状态未知时做出错误决策。第二是时间同步：Classic 的调度表时间与 Adaptive 的 POSIX 时间需要通过 Stellar 的全局时间模块对齐，否则跨核数据的时间戳会漂移。第三是失效降级：当 Adaptive 侧崩溃或重启时，Classic 侧必须能独立维持安全相关控制，不能因为应用核异常而丢失制动或转向能力。