9680329b3b
revert docs: 完善三套实时性研究框架与验证方案 (#3) ## 改动内容 - 完善并提交“项目框架1：基于 RTOS 的五类场景 AI 实时性研究”。 - 新增“项目框架2：面向机器人大小脑异构系统的实时保障研究”。 - 新增“项目框架3：MCU 与资源受限 SoC 的 AI 实时性与低功耗研究”。 - 新增 RTOS–Linux–Hypervisor 边缘并行架构说明。 - 新增调整后的研究问题与验证建议，明确 RTOS、系统实时性与大模型低时延的边界。 ## 验证 - 已同步上游 `main`，源分支基于最新上游历史继续提交。 - `git diff --cached --check` 通过。 - 已检查提交范围，未加入凭据、令牌或临时文件。 - 远端分支提交已核对为 `b7863721fe906c0fa6a5e841599dd276a579d679`。 ## 建议重点审查 - 三套框架是否应作为相互独立、可并列选择的研究路线。 - 是否充分区分工业实时性、AI 推理低时延与端到端系统实时性。 - 机器人大小脑分域、Hypervisor 隔离及 MCU 资源预算的实验指标是否可落地。 --------- Co-authored-by: Mo1s <1194302708@qq.com> Reviewed-on: #3 Co-authored-by: moyixin <15971501952@163.com>
2.7 KiB
2.7 KiB
SoC路线：Hybrid与Hypervisor协同
1. 主题定位
SoC 路线是框架2的核心主战场。这里最直接体现会议中的判断：人工智能进入实时控制系统后，最现实的结构不是让 RTOS 独自承接一切，而是让 Linux、RTOS、Hypervisor 与异构协处理器形成可治理的混合基础系统。
2. 为什么 SoC 路线最关键
设备端 SoC 同时具有以下特征：
- 需要 Linux 承接 AI 生态和推理框架；
- 需要 RTOS 承接关键控制与执行闭环；
- 统一内存和异构协处理器使资源竞争非常明显；
- 设备级散热、功耗和体积限制比服务器更刚性；
- 更接近真实产业落地场景。
因此，SoC 路线最能体现“基础系统主语”。
3. Hybrid 结构为什么仍然重要
会议并没有否定 Hybrid，反而强调它是当前最现实的路径之一。
Hybrid 的现实价值在于：
- 保留 Linux 的推理生态；
- 保留 RTOS 的控制与保障能力；
- 让 AI 目标负载与关键保障负载可以在不同控制层上运行；
- 为后续 Hypervisor 和资源治理留出结构空间。
但框架2不再接受“传统 Hybrid 只求共存”的写法，而要求把它升级为协同治理结构。
4. Hypervisor 在 SoC 路线中的角色
Hypervisor 使 SoC 路线从“双系统并置”走向“可治理混合系统”。它重点承担：
- 核心与资源切分；
- 中断与设备访问边界控制；
- 共享内存与通信路径组织；
- 异常隔离与恢复。
如果没有 Hypervisor 或等价机制，很多 SoC 路线的协同边界很难稳定复现。
5. 核心研究问题
5.1 推理与控制如何分层
后续研究需要回答：
- 哪些 AI 任务保留在 Linux 侧；
- 哪些控制任务保留在 RTOS 侧；
- 控制与推理之间通过什么接口通信；
- 在延迟、异常和过载条件下如何切换策略。
5.2 统一内存与总线竞争如何治理
SoC 路线中最容易被低估的问题包括：
- CPU 与 NPU/GPU 的统一内存争抢；
- DMA 传输对控制路径的污染；
- 模型加载与设备 I/O 共享带宽；
- 缓存与总线冲突对尾延迟的影响。
这部分是 SoC 路线区别于纯 RTOS 叙事的关键证据。
5.3 设备级受限条件如何影响系统边界
SoC 路线必须同时面对：
- 功耗预算；
- 散热与封装条件；
- 设备体积与部署空间；
- 软件栈和驱动闭源限制。
因此，它天然也是框架2中“小型化与低功耗”方向最强的承载层。
6. 当前结论
SoC 路线不是 RTOS 课题的附属场景，而是“面向 AI 的实时控制基础系统”最能成立、也最值得展开的核心研究窗口。