# RTOS + Linux + Hypervisor 边缘并行架构说明

## 1. 架构目标

边缘侧采用并行分域思路：RTOS 负责控制和安全关键路径，Linux 负责 AI 推理与复杂软件生态，Hypervisor 或等价静态分区层负责空间隔离、时间干扰控制和设备分配。

该架构不把“让 RTOS 原生运行全部大模型软件栈”作为前提。优化目标按优先级排序为：

1. 控制闭环截止期不被推理负载破坏；
2. AI 结果在规定的新鲜度窗口内可用；
3. 推理域故障不扩散到控制域；
4. 在前三项满足后提高推理吞吐、能效和资源利用率。

## 2. 逻辑架构

```text
┌─────────────────────────────────────────────────────────────┐
│                    边缘计算硬件                              │
│  CPU 核 / LLC / DRAM / 内存带宽 / NPU或GPU / I/O / 时钟     │
├─────────────────────────────────────────────────────────────┤
│        Hypervisor、静态分区器或具备等价能力的隔离层          │
│  vCPU/物理核分配、内存区间、IOMMU、设备直通、中断路由、监控  │
├───────────────────────────┬─────────────────────────────────┤
│ RTOS 控制域               │ Linux 推理域                    │
│ - 周期控制与联锁          │ - 模型加载与推理运行时          │
│ - 现场总线与关键传感器    │ - GPU/NPU 驱动与厂商 SDK        │
│ - 时间戳、结果校验        │ - 数据预处理与后处理            │
│ - 超时、降级与安全状态    │ - 模型更新、日志与网络服务      │
├───────────────────────────┴─────────────────────────────────┤
│ 有界跨域通道：共享内存环形队列 + 通知 / RPMsg / 虚拟设备等   │
└─────────────────────────────────────────────────────────────┘
```

这里的“Hypervisor”表示架构角色，不预设具体产品。若 SoC 已具备安全岛、独立 MCU、AMP 或硬件静态分区能力，只要能够提供可验证的资源和故障隔离，也可以作为实现路径。

## 3. 两个域的职责边界

### 3.1 RTOS 控制域

RTOS 域应拥有：

- 周期控制、联锁、执行器输出和关键状态采集；
- 控制任务使用的定时器、关键中断和关键 I/O；
- AI 请求的采样时刻、任务编号、期望完成期限和优先级；
- AI 结果的完整性、新鲜度、置信度和序列一致性检查；
- 超时、失联、异常结果和推理域重启时的回退控制；
- 必要的看门狗与推理域生命周期控制接口。

RTOS 域不应依赖 Linux 域才能维持基本安全状态。AI 可增强系统能力，但关键控制闭环应明确 AI 缺席时的可接受行为。

### 3.2 Linux 推理域

Linux 域应拥有：

- 模型文件、模型运行时和推理服务；
- GPU/NPU/DLA 等加速器驱动及厂商 SDK；
- 复杂预处理、后处理、模型编排和批处理；
- 网络、存储、模型更新以及非关键日志服务；
- 推理资源的吞吐优化和域内调度。

Linux 域可以对 AI 服务做软实时优化，但不得把域内平均时延等同于控制系统的实时保证。

### 3.3 Hypervisor/分区层

隔离层需要明确而不是笼统声称以下能力：

- CPU 核是静态独占、时间分片还是混合分配；
- 内存区域是否静态划分，是否存在共享页和动态气球机制；
- LLC、内存带宽和互联是否可分配、限额或仅可观测；
- 加速器采用直通、复用还是由单一域独占；
- 设备 DMA 是否受 IOMMU 限制；
- 物理中断如何路由，是否会在控制核上产生额外虚拟化出口；
- 一个域崩溃、重启或过载时，另一域是否持续运行。

Hypervisor 本身也会引入 VM exit、虚拟中断和跨域通信开销，必须纳入实测，不能只把它视为零成本隔离层。

## 4. 跨域通信契约

推荐使用异步、有界、可丢弃的通信语义，避免 RTOS 控制任务同步等待 Linux 推理。

### 4.1 请求消息最小字段

| 字段 | 作用 |
|---|---|
| `request_id` | 区分请求和乱序结果 |
| `sample_time` | 标识传感数据的采样时刻 |
| `deadline` | AI 结果最晚可用时刻 |
| `priority/class` | 区分任务重要性和推理策略 |
| `payload_ref` | 指向受控共享缓冲区或内联小数据 |
| `schema/version` | 防止两域版本不一致 |

### 4.2 结果消息最小字段

| 字段 | 作用 |
|---|---|
| `request_id` | 与请求配对 |
| `model_version` | 支撑审计和回滚 |
| `finish_time` | 计算跨域端到端时延 |
| `confidence/status` | 判断结果是否可用 |
| `valid_until` | 规定结果新鲜度边界 |
| `payload/checksum` | 结果与完整性校验 |

### 4.3 控制域消费规则

RTOS 只在以下条件同时满足时采用 AI 结果：

```text
ID 匹配
AND 数据完整
AND finish_time <= deadline
AND now <= valid_until
AND confidence/status 满足策略
```

任一条件不满足时执行预定义回退，例如沿用上次可信结果、使用传统控制器、降低运行等级或进入安全状态。回退动作和完成时间本身也属于实时需求。

## 5. 系统级时间模型

AI 辅助决策链可表示为：

```text
R_ai = C_sample + C_tx_req + Q_linux + C_pre
     + C_infer + C_post + C_tx_rsp + C_validate
```

系统约束不是简单要求 `C_infer` 最小，而是：

```text
R_control <= D_control

AI 结果被采用时：R_ai <= D_ai 且 age(result) <= A_max

AI 结果未按时到达时：R_fallback <= D_fallback
```

其中，控制闭环约束为硬优先级；AI 时效约束通常为任务相关的软实时或固实时约束；回退路径必须有独立期限。

## 6. 资源并行与隔离策略

### 6.1 CPU 和中断

- 为 RTOS 域保留独立物理核，避免与 Linux vCPU 时间复用；
- 将关键定时器和现场总线中断直达 RTOS 域；
- 将网卡、存储和加速器完成中断尽量路由到 Linux 域；
- 若共享 LLC，测量 Linux 推理对控制任务缓存行为的干扰；
- 记录 SMT、动态迁核和电源管理对分区确定性的影响。

### 6.2 内存、带宽和 DMA

- 两域使用静态内存区间，共享区保持最小化；
- 共享缓冲区预分配，禁止关键路径动态扩容；
- 使用 IOMMU 或硬件访问控制限制 DMA 范围；
- 对 DRAM 带宽、内存控制器和互联竞争进行压力实验；
- 若硬件不支持带宽限额，必须把“核隔离”和“内存隔离”分开表述。

### 6.3 加速器

推荐由 Linux 推理域独占 GPU/NPU，以保留成熟驱动和运行时生态。RTOS 通过请求契约使用推理服务，而不是直接进入厂商运行时。

若控制域也需访问同一加速器，则必须额外解决队列仲裁、DMA 隔离、不可抢占执行段和故障复位归属。这种共享模式风险更高，应作为扩展方案而非默认主线。

### 6.4 功耗和热

分域不自动消除芯片级功耗和温度耦合。Linux 域的持续推理可能触发全芯片功耗限制或降频，进而改变 RTOS 域执行时间。因此需要：

- 固定或记录各域频率和功率模式；
- 同步采集控制延迟、推理负载、温度和实际频率；
- 对推理域设置负载准入或功耗上限；
- 验证热稳态而非只测短时冷机性能。

## 7. 故障与降级状态机

```text
正常增强控制
    │ AI 超时/低置信度
    ▼
传统控制或保持模式
    │ 连续超时/通信故障
    ▼
推理域隔离与重启
    │ 控制风险上升
    ▼
受限运行或安全状态
```

需要验证的故障至少包括：

- Linux 推理进程崩溃；
- Linux 域卡死或重启；
- 加速器驱动错误或设备复位；
- 跨域队列堆满、消息乱序或数据损坏；
- 推理持续超时；
- Linux 域 CPU、内存、网络或存储过载。

每种故障都要记录检测时间、隔离时间、回退完成时间、控制任务违约数和恢复后首个有效 AI 结果时间。

## 8. 可比较的架构组

| 组别 | 架构 | 用途 |
|---|---|---|
| A0 | 单 Linux，控制与推理同域 | 通用部署基线 |
| A1 | PREEMPT_RT Linux，控制与推理同域 | 实时增强 Linux 基线 |
| A2 | RTOS 同域承载控制与可运行的 AI | 适用于 MCU/小模型，不强求大模型生态 |
| A3 | RTOS 控制域 + Linux 推理域 + 分区层 | 边缘并行主方案 |
| A4 | A3 加入通信、带宽、故障和热治理机制 | 完整优化方案 |

比较时必须固定硬件、控制任务语义、AI 模型、输入到达序列和功率策略。A2 与 A3 若使用不同推理后端，应明确这是“系统方案比较”，不能仅归因为内核差异。

## 9. 核心评价指标

### 控制域

- 周期任务响应时间、抖动和 deadline miss ratio；
- 外部输入到执行器输出的物理链路延迟；
- AI 过载与故障期间的观测最大响应时间；
- 回退路径完成时间。

### AI 链路

- 从 RTOS 发起请求到结果验证完成的端到端延迟；
- 结果按期率、新鲜度合格率、超时率和丢弃率；
- 吞吐、TTFT/TPOT 或任务特定推理时延；
- 推理域重启后的恢复时间。

### 隔离与代价

- 空载和推理满载时控制延迟之差；
- CPU、内存带宽、I/O、DMA 和热干扰敏感度；
- 跨域 IPC 延迟、抖动、拷贝次数和 CPU 开销；
- 静态资源预留造成的推理吞吐及能效损失。

## 10. 架构结论边界

本架构旨在证明“系统可以在 AI 负载不确定的情况下保护关键控制路径，并对 AI 结果实施有期限的安全消费”。它不自动证明：

- Linux 域中的大模型具备硬实时性；
- Hypervisor 消除了所有共享硬件干扰；
- 一个硬件平台的分区结果可直接迁移到另一 SoC；
- 只要控制域未违约，AI 功能就一定满足任务需求。

最终结论必须同时报告控制保障效果、AI 结果可用性以及隔离带来的资源代价。