# 面向AI的实时控制基础系统研究逻辑说明 ## 1. 文档目的 本文用于解释框架2的研究逻辑,重点回答三个问题: 1. 研究对象从 RTOS 平台上升到基础系统之后,实验如何组织; 2. `T5~T1` 验证矩阵如何继续保留,同时不替代研究主语; 3. Linux、RTOS、Hypervisor 与混合结构如何进入统一对照框架。 ## 2. 研究对象 本框架的研究对象是: > **面向 AI 的实时控制基础系统。** 其核心不是某一个单一软件层,而是下面三层共同构成的系统: - **RTOS 直接控制域**:关键任务调度、中断、同步、恢复和控制路径保护; - **推理运行域**:模型、量化、算子、推理框架、驱动与运行时队列; - **系统协同域**:Linux、RTOS、Hypervisor、统一内存、总线、DMA、NPU/GPU 和资源治理结构。 ## 3. T5~T1 验证矩阵的角色 `T5~T1` 五类部署形态继续承担三项作用: 1. **验证矩阵**:在不同资源与系统角色下检验同一问题是否成立; 2. **证据组织框架**:把结论放回统一谱系中观察边界和收窄区间; 3. **产业解释接口**:让不同部署位置都能找到现实对应场景。 在框架2中,`T5~T1` 回答的是“在哪里验证”,而不是“研究对象是什么”。 ## 4. 两条技术路线如何进入实验 ### 4.1 MCU 路线 MCU 路线更适合围绕以下内容组织实验: - 小模型与控制任务的静态编排; - 工具链和开发套件的能力; - 极小资源预算下的任务边界; - 与芯片规格、片上资源和开发流程的协同关系。 ### 4.2 SoC 路线 SoC 路线更适合围绕以下内容组织实验: - Linux / RTOS 的角色分工; - Hybrid 结构与 Hypervisor 的隔离方式; - 统一内存、总线和异构协处理器竞争; - 推理链路与控制链路并存时的整体实时性。 ## 5. 对照逻辑 框架2的主对照不再只限于“普通 Linux / PREEMPT_RT / RTOS”,而是扩展为: | 编号 | 配置 | 作用 | |---|---|---| | `O0` | 普通 Linux | 通用系统基线 | | `O1` | PREEMPT_RT Linux | 实时增强 Linux 的边界 | | `O2` | RTOS 原生配置 | RTOS 底座能力 | | `O3` | 混合基础系统配置 | Linux + RTOS + Hypervisor 或等价协同结构 | 必要时还可以继续细分 `O3` 的不同协同版本,用于比较不同 Hybrid 结构的收益与代价。 ## 6. 核心实验顺序 框架2的实验顺序建议如下: 1. **系统就绪性确认**:设备、驱动、模型、测量链路和基础软件栈可用; 2. **单域基线测试**:分别测试推理运行域与关键保障负载的基础行为; 3. **双域并存测试**:测试人工智能目标负载与关键保障负载共存时的边界; 4. **协同结构测试**:引入 Linux / RTOS / Hypervisor 混合结构,比较不同协同方式; 5. **极限与恢复测试**:引入突发负载、长稳运行、异常切换和规则兜底场景; 6. **跨档位回收分析**:把结论放回 `T5~T1` 观察适用区间与失效边界。 ## 7. 核心指标 框架2仍然采用三层指标结构: ### 7.1 人工智能目标负载层 - `TTFT` - `TPOT` - 端到端响应时间 - 功能有效性 ### 7.2 关键保障负载层 - `deadline miss ratio` - `P99/P99.9 jitter` - 观测最大响应时间 - 外部接口响应时间 ### 7.3 系统协同层 - 有效吞吐 - 资源隔离效果 - `E/token` - 温度与热漂移 - 异常切换与恢复能力 ## 8. 与框架1的关键差别 框架1的重点是: - RTOS 作为研究主语; - 六个 RTOS 机制方向; - 观察 RTOS 在五类部署形态中的系统优势。 框架2的重点是: - 基础系统作为研究主语; - 三层边界与两条技术路线; - 观察人工智能进入实时控制系统后,整体边界如何成立。 因此,框架2更适合承接 2026-09-22 会议中的重定义判断。 ## 9. 当前状态 框架2当前已经形成一条完整的逻辑链: 1. 研究对象上移到“面向 AI 的实时控制基础系统”; 2. 用三层边界划分研究问题; 3. 用 MCU 路线与 SoC 路线组织不同系统结构; 4. 用 `T5~T1` 验证矩阵组织证据; 5. 用 Linux / RTOS / Hypervisor / 混合结构建立统一对照。 在此基础上,后续可以继续向更细的实验子文档、联合研究方材料和正式交付物展开。