rtos_llm_opt/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/05-研究逻辑说明.md

面向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 / 混合结构建立统一对照。

在此基础上，后续可以继续向更细的实验子文档、联合研究方材料和正式交付物展开。