# 系统协同域

## 1. 主题定位

系统协同域是框架2相对框架1最大的变化之一。它不再把问题停留在“RTOS 是否更强”，而是直接讨论：当 Linux、RTOS、Hypervisor、统一内存、总线、DMA、NPU、GPU 和规则兜底机制共同存在时，整体实时性如何被建立、维持和验证。

## 2. 为什么系统协同域是主问题

会议中最关键的判断之一是：人工智能进入实时控制系统后的真实问题，已经超出了单一操作系统边界。原因在于：

- 推理生态通常离不开 Linux；
- 关键保障负载需要 RTOS 或等价实时控制底座；
- 设备端 SoC 常常采用统一内存和异构协处理器；
- Hypervisor 与隔离机制直接影响资源边界；
- 规则兜底与安全约束必须与模型输出共同工作。

因此，系统协同域回答的是：

> **在混合结构中，整体秩序如何形成。**

## 3. 核心问题

### 3.1 Linux 与 RTOS 如何分工

Linux 更适合承担：

- 推理框架与模型生态；
- 容器、服务和工具链支持；
- 非关键路径的 AI 相关运行任务。

RTOS 更适合承担：

- 关键保障负载；
- 控制闭环中的刚性时间边界；
- 关键路径上的确定性治理。

系统协同域的核心，不是让两者彼此替代，而是让两者分工清楚、边界稳定。

### 3.2 Hypervisor 在这里起什么作用

Hypervisor 不是附属选项，而是重要研究对象之一。它至少影响：

- 核心隔离和资源切分；
- 中断路由和设备访问边界；
- 共享内存与通信路径；
- 异常传播与恢复策略。

在设备端 SoC 和边缘节点上，Hypervisor 往往是把“共存”升级为“可治理共存”的关键层。

### 3.3 异构资源竞争如何进入系统分析

在 SoC 和边缘节点上，整体边界往往由以下竞争共同决定：

- CPU 与 NPU/GPU 的统一内存争用；
- DMA 与 CPU 访存冲突；
- 总线与缓存竞争；
- 模型加载与控制 I/O 共享带宽；
- 后台服务与关键任务共享中断和核资源。

这些问题不能只在驱动层或 RTOS 层单独解释，必须进入系统协同域。

## 4. 关键机制

### 4.1 资源隔离

后续研究应重点观察：

- CPU 核和关键任务核是否可隔离；
- 设备中断是否可隔离；
- 共享内存和 DMA 缓冲是否可限定边界；
- 模型提交路径是否会挤占控制路径资源。

### 4.2 协同治理

协同治理关注的是：

- 推理与控制如何分层；
- 哪些事件由 Linux 负责，哪些由 RTOS 负责；
- 资源冲突发生时谁拥有优先权；
- 发生过载和异常时系统如何降级与恢复。

### 4.3 证据组织

系统协同域的证据不能只看某一个线程或某一个服务，而需要同时观察：

- 人工智能目标负载层；
- 关键保障负载层；
- 系统协同层。

只有三层指标同时成立，才能说明协同结构是有效的。

## 5. 对照方式

框架2的主对照建议采用：

- `O0` 普通 Linux
- `O1` PREEMPT_RT Linux
- `O2` RTOS 原生配置
- `O3` 混合基础系统配置

其中 `O3` 不再只是附属架构，而是系统协同域的主实验路径之一。

## 6. 当前结论

框架2真正抬升的，不只是标题口径，而是研究主线本身：

> **系统协同域使项目从“RTOS 机制研究”走向“人工智能进入实时控制系统后的基础系统研究”。**