docs: add alternative real-time research frameworks

# Conflicts:
#	10-研究框架/README.md
#	项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/03-实验设计.md
#	项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/metric.md

10-研究框架/08-RTOS-Linux-Hypervisor边缘并行架构说明.md

@@ -0,0 +1,241 @@
+# 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 结果可用性以及隔离带来的资源代价。

10-研究框架/README.md

@@ -1,36 +0,0 @@
-# 研究框架索引
-
-本目录放置项目的核心研究框架文档，说明研究对象、研究结构与具体优化切入方向。
-
-## 阅读建议
-
-1. `00-整体研究框架.md`
-2. `01-推理图任务调度.md`
-3. `02-KV-Cache与内存管理.md`
-4. `03-加速器协同调度.md`
-5. `04-量化精度感知调度.md`
-6. `05-中断与实时性保障.md`
-7. `06-能耗与热管理.md`
-8. `07-方法论与评估工具链.md`
-9. `参考文件/README.md`
-
-## 文件说明
-
-- `00-整体研究框架.md`
-  - 研究总框架、问题空间、技术分层、预期成果
-- `01-推理图任务调度.md`
-  - LLM 推理 DAG 拆解、任务映射与调度策略
-- `02-KV-Cache与内存管理.md`
-  - KV Cache 生命周期、内存池、带宽竞争与局部性
-- `03-加速器协同调度.md`
-  - CPU、NPU、GPU、DMA 等异构资源协同
-- `04-量化精度感知调度.md`
-  - 精度、资源占用和调度决策的联动关系
-- `05-中断与实时性保障.md`
-  - IRQ 路径、线程化、中断隔离与实时任务保护
-- `06-能耗与热管理.md`
-  - 能耗约束、温度耦合、频率策略与热稳定性
-- `07-方法论与评估工具链.md`
-  - 建模、仿真、原型验证和评估方法学
-- `参考文件/`
-  - 按七个研究方向整理的论文、标准、官方工程资料及其与本项目的证据映射

20-实验与规划/05-调整后研究问题与验证建议.md

@@ -0,0 +1,207 @@
+# 调整后研究问题与验证建议
+
+## 1. 调整目的
+
+本文将最新方向意见转化为可执行的研究问题和验证建议。它不替换现有实验设计，而用于指导下一轮方案收敛：主线从覆盖 `T1~T5` 的 RTOS 大模型统一评测，转向 MCU/资源受限 SoC 的 AI 实时干扰，以及边缘侧 RTOS/Linux 分域系统的整体实时保障。
+
+## 2. 建议的研究范围
+
+### 2.1 核心范围
+
+- MCU 或资源受限 SoC 上，AI 与周期控制、采集和通信共存；
+- 边缘平台上，RTOS 控制域与 Linux 推理域并行运行；
+- CPU、内存、缓存、总线、中断、DMA、加速器、功耗和热形成的系统级干扰；
+- AI 结果的期限、新鲜度、超时、降级与故障恢复。
+
+### 2.2 条件扩展
+
+- 更大模型、更高并发和多加速器用于增加 Linux 推理域压力；
+- 不同 Hypervisor、静态分区或 AMP 实现之间的隔离开销比较；
+- 多边缘节点之间的协同推理。
+
+### 2.3 暂不作为主线
+
+- `T1` 多节点大模型集群的 RTOS 部署；
+- `T2` 多 GPU 工作站上的统一 RTOS 推理栈；
+- 以“容量从 MCU 连续扩展到集群”为核心贡献；
+- 将模型量化、KV Cache 或分布式推理优化直接归为 RTOS 成果。
+
+## 3. 研究问题
+
+| 编号 | 研究问题 | 核心输出 |
+|---|---|---|
+| RQ1 | AI 进入 MCU/SoC 后，通过哪些资源路径破坏控制实时性？ | 干扰来源排序、响应时间与违约边界 |
+| RQ2 | RTOS 的优先级、预算、隔离、预分配和准入机制能扩大多少安全运行区间？ | 无违约容量曲线与机制消融 |
+| RQ3 | RTOS 控制域 + Linux 推理域 + Hypervisor 是否优于单域共存？ | 控制保护、AI 结果按期率与资源代价 |
+| RQ4 | 跨域通信与静态资源预留带来多大开销？ | IPC 延迟/抖动、吞吐和能效损失 |
+| RQ5 | 推理超时、Linux 域崩溃或加速器故障时能否按时降级？ | 故障检测、隔离、回退和恢复时间 |
+
+## 4. 分阶段实验路线
+
+### 阶段 P0：需求与时间契约冻结
+
+先定义而不是从设备档位反推：
+
+- 控制任务周期 `T_control` 和截止期 `D_control`；
+- AI 结果期限 `D_ai` 和最大新鲜度 `A_max`；
+- AI 缺席时的回退动作和期限 `D_fallback`；
+- 可接受的 AI 完成率、结果质量和能耗预算；
+- 需要保护的关键 I/O、中断、内存和设备。
+
+完成标志是形成一张“任务—资源—期限—失败处理”表。
+
+### 阶段 P1：MCU/SoC 干扰确认
+
+在真实可运行 AI 的最小平台上建立下列负载：
+
+| 负载 | 内容 | 目的 |
+|---|---|---|
+| M0 | 仅控制任务 | 控制实时性下界 |
+| M1 | 仅 AI | AI 执行、内存、功耗基线 |
+| M2 | 控制 + AI | 确认同域干扰 |
+| M3 | M2 + 内存/总线压力 | 定位共享资源瓶颈 |
+| M4 | M2 + I/O/中断压力 | 定位中断与 DMA 干扰 |
+| M5 | M2 + 热稳态运行 | 识别降频导致的时间漂移 |
+| M6 | AI 过载与突发 | 找到准入和降级阈值 |
+
+AI 模型按硬件实际能力选择，不要求 MCU 运行大语言模型。小模型同样可以有效暴露系统级资源竞争。
+
+### 阶段 P2：RTOS 机制验证
+
+逐项加入并消融以下机制：
+
+1. 控制任务固定优先级与核/执行上下文隔离；
+2. AI 任务预算或服务器机制；
+3. 内存预分配、缓冲区限额和禁止关键路径动态分配；
+4. 中断亲和性和关键设备优先级；
+5. AI 请求队列上限、限流和拒绝策略；
+6. 模型降级、跳帧或降低推理频率；
+7. 超时后回退到非 AI 控制路径。
+
+每次只改变一个机制，输出控制任务违约率、AI 完成率和吞吐代价，避免只给出“优化前后”黑盒比较。
+
+### 阶段 P3：边缘分域基线
+
+至少比较：
+
+| 组别 | 配置 |
+|---|---|
+| E0 | 普通 Linux：控制与推理同域 |
+| E1 | PREEMPT_RT Linux：控制与推理同域 |
+| E2 | RTOS 控制域 + Linux 推理域，最小静态分区 |
+| E3 | E2 + 中断、内存、通信和准入优化 |
+
+如硬件不支持其中某组，应明确记录缺失原因，不用不同硬件数据替代同平台对照。
+
+### 阶段 P4：共享资源压力扫描
+
+在 Linux 推理域逐步增加：
+
+- CPU 利用率和线程数量；
+- 模型请求到达率、batch 和上下文长度；
+- DRAM 带宽与 LLC 压力；
+- 网络、存储和摄像头 I/O；
+- GPU/NPU 占用和完成中断频率；
+- 持续功耗与温度。
+
+横轴使用相同绝对负载或相同到达序列，纵轴联合展示控制 deadline miss ratio、AI 结果按期率和有效吞吐。目标是找到“控制仍安全、AI 仍有用”的二维可行区，而不是只比较单个平均值。
+
+### 阶段 P5：跨域通信实验
+
+比较可实现的通信方式，例如共享内存环形队列、通知机制、RPMsg 或虚拟设备。统一消息大小和到达序列，测量：
+
+- 单向和往返时延；
+- P99/P99.9 与观测最大抖动；
+- 拷贝次数和 CPU 占用；
+- 队列满时的丢弃、覆盖或背压行为；
+- 域重启后的通道恢复时间；
+- 旧结果、乱序结果和损坏结果是否被 RTOS 拒绝。
+
+### 阶段 P6：故障注入与恢复
+
+建议故障集：
+
+| 故障 | 必测结果 |
+|---|---|
+| 推理进程退出 | 检测时间、控制违约、服务恢复时间 |
+| Linux 域重启 | RTOS 是否持续运行、回退完成时间 |
+| 推理请求永久阻塞 | 超时是否生效、队列是否泄漏 |
+| 加速器错误/复位 | 故障是否跨域传播、恢复路径 |
+| 共享队列溢出 | 丢弃策略、内存安全、控制影响 |
+| 消息乱序/校验失败 | 错误结果是否被消费 |
+| Linux 域 CPU/内存/I/O 过载 | 控制尾延迟和隔离上限 |
+
+仅在具备安全恢复路径时执行设备级故障注入；否则先用软件故障和仿真通道验证状态机。
+
+## 5. 指标体系调整
+
+### 5.1 第一优先级：控制实时性
+
+- 释放到完成的响应时间；
+- deadline miss ratio；
+- P99/P99.9 和观测最大抖动；
+- GPIO、CAN、RS485 或工业以太网的端到端物理响应；
+- AI 满载、热稳态和故障期间的控制表现。
+
+### 5.2 第二优先级：AI 结果可用性
+
+- 请求发出到 RTOS 验证结果完成的端到端时延；
+- 结果按期率和新鲜度合格率；
+- 超时、拒绝、丢弃、乱序和错误率；
+- 任务质量或置信度；
+- 回退发生比例。
+
+### 5.3 第三优先级：系统代价
+
+- 分给 RTOS 的 CPU、内存和设备资源；
+- Hypervisor 与 IPC 开销；
+- 推理吞吐损失、能耗和热影响；
+- 静态预留导致的资源利用率变化；
+- 故障恢复和长稳运行开销。
+
+TTFT、TPOT、tokens/s 和 `E/token` 可以继续使用，但它们属于 Linux 推理域或系统服务指标，不能替代控制实时性与结果新鲜度指标。
+
+## 6. 推荐图表
+
+1. 单域与分域架构职责图；
+2. AI 负载强度—控制违约率—AI 按期率三维或等高线图；
+3. CPU、内存、I/O、热干扰的控制尾延迟对比；
+4. 跨域请求—推理—返回—验证的时序分解图；
+5. RTOS 机制逐项消融图；
+6. 推理域故障期间控制响应时间序列；
+7. 静态资源预留与推理有效吞吐的 Pareto 曲线；
+8. AI 结果超时、回退、恢复状态机图。
+
+## 7. 阶段验收标准
+
+| 层次 | 验收条件 |
+|---|---|
+| 数据有效 | 时钟、负载、版本、拓扑和原始事件可追踪；失败样本未被静默删除 |
+| 控制保障 | 在冻结的运行区间内满足控制期限，并报告样本数和观测最大值 |
+| AI 可用 | 在冻结质量门槛下达到规定的按期率和新鲜度合格率 |
+| 隔离有效 | 推理负载或故障对控制域的影响显著小于单域基线 |
+| 代价可接受 | 同时报告资源预留、IPC、吞吐、能耗和热代价 |
+| 降级有效 | AI 不可用时在 `D_fallback` 内进入预定义状态，且不依赖推理域恢复 |
+
+“未观测到违约”仍不能代替理论最坏界；Hypervisor 分域结果也只能在已验证的硬件、配置和压力范围内成立。
+
+## 8. 对现有设备的使用建议
+
+- 现有 RK3588 更适合作为边缘分域或资源受限 SoC 的核心验证平台，而不是同时承担多个容量档位以构造连续谱系；
+- 现有 V100 平台可作为 Linux 推理域的高压力源、吞吐参照或跨域服务端，但不需要证明其属于 RTOS 主线；
+- MCU 平台应根据真实 AI 运行能力和工业 I/O 条件选取，优先验证控制期限和资源干扰，而非模型参数规模；
+- 新增设备采购应由研究问题和分域实现需求驱动，不再为了补齐 `T1~T5` 档位而采购。
+
+## 9. 建议的最小可发表闭环
+
+在一个 MCU/SoC 同域平台和一个边缘分域平台上完成以下闭环即可形成聚焦的系统研究：
+
+1. 证明 AI 负载会通过可识别的资源路径干扰控制实时性；
+2. 给出 RTOS 预算、隔离、准入和降级机制；
+3. 实现 RTOS 控制域与 Linux 推理域的有界异步通信；
+4. 与普通 Linux、PREEMPT_RT 或单域方案进行同平台比较；
+5. 在过载、热稳态和故障注入下验证控制保护；
+6. 同时报告 AI 结果按期率和资源代价；
+7. 明确结论只覆盖 MCU/SoC 与边缘任务关键系统，不外推到 T1/T2 集群。
+
+这一闭环比覆盖全部硬件档位更容易建立清晰的因果关系，也更直接回应“AI 引入后，任务关键系统如何保持实时”的核心问题。

项目框架1-基于RTOS的五类场景AI实时性研究/00-项目总览/02-研究定位与项目边界.md

@@ -56,6 +56,8 @@
 - `T2` 桌面 / 工作站单机
 - `T1` 服务器 / 集群
 
+其中，`T1` 在本项目中定义为**面向任务关键场景的分布式协同计算平台**，承载全局状态管控、多源信息融合推理和跨节点协同决策等任务；通用高吞吐训练集群或面向公网请求的通用推理机房不属于本项目场景范围。
+
 这套验证矩阵支撑以下四类判断：
 
 - RTOS 优势在哪些部署形态下最明显；
@@ -63,6 +65,8 @@
 - 为维持实时保障需要付出多少吞吐和能耗代价；
 - 从什么资源规模开始，RTOS 相对非实时平台的优势开始收窄。
 
+这套验证矩阵提供的是统一的建模、评估与证据组织方法，不要求同一套机制在 `T5~T1` 全部取得同等收益；项目重点是识别不同资源约束、拓扑结构和负载强度下，RTOS 优势边界与失效边界的成立区间。
+
 ### 4. 建立“AI 目标负载 + 关键保障负载”双目标证据链
 
 项目以可复现、可解释的证据链为核心输出，目标是形成能被论文、产品和产业沟通共同接受的系统性结论。
@@ -86,6 +90,8 @@
 - 任务关键系统；
 - 人工智能目标负载。
 
+其中，`T5/T4/T3` 属于典型嵌入式装备节点；`T2/T1` 属于通用处理器硬件平台上运行的任务关键业务环境。项目讨论的是实时操作系统在这些平台上的系统作用，硬件本身不被定义为嵌入式系统。
+
 ### 2. 评价重点
 
 项目评价围绕“双目标达标 + 系统协同稳定”展开，重点包括：
@@ -105,6 +111,10 @@
 
 因此，项目重点落在系统机制、调度策略和资源治理能力上。
 
+对于搭载独立 GPU 或专用加速器的平台，RTOS 的主要管控范围是 CPU 侧任务调度、中断隔离、内存预算、关键保障负载时间保护和系统级恢复机制；GPU 内部算子调度、显存流水线与设备微架构行为由加速器硬件与驱动管理，不属于 RTOS 内核直接管控域。
+
+因此，`T2/T1` 层级的研究重点不是单纯优化 GPU 吞吐，而是评估在人工智能目标负载并发存在时，CPU 侧关键保障负载与系统协同机制是否仍能维持实时边界。
+
 ### 4. 成果形态
 
 项目成果需要形成完整的方法与证据体系，包括：
@@ -115,12 +125,14 @@
 - 跨部署形态可比较的规律；
 - 能被学术界和产业界共同理解的结论。
 
+在证据形态上，项目区分**核心实测证据**与**扩展层级证据**：核心档位以实机对照与长稳数据为主，扩展档位可结合建模分析、仿真、条件验证和外部参照结果，形成边界推演与跨层级比较。
+
 ## 这个项目最后要交付什么
 
 项目最终交付物至少应包括：
 
 1. 一套面向任务关键系统的 SylixOS 实时保障机制；
-2. 一组覆盖 `T5~T1` 五类部署形态的实测数据和对照结果；
+2. 一组覆盖 `T5~T1` 五类部署形态的验证证据与对照结果，其中核心档位以实测为主，扩展档位以建模、仿真和条件验证为补充；
 3. 一套同时覆盖 AI 目标负载与关键保障负载的实验方法学；
 4. 一篇能够清楚表达机制、证据、边界和规律的系统化论文或正式报告；
 5. 一套可用于产业沟通和产品表达的技术叙事。

项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/00-整体研究框架.md

@@ -14,6 +14,8 @@
 
 本研究评估的是：RTOS 在智能负载进入任务关键系统后，对系统秩序、时序边界与资源边界的维持能力。
 
+在这条主线之下，项目另设一个**面向小型化与低功耗方向的应用副课题**。这一副课题不改变“大型跨平台实时操作系统”作为研究对象的定位，主要用于在 `T5/T4` 两类部署形态中集中观察：当系统同时受到功耗、体积、散热与内存预算约束时，RTOS 对人工智能目标负载与关键保障负载双目标达标能力的支撑边界。
+
 ---
 
 ## 1. 问题空间：五类部署形态、五种算力基础与三类系统负载
@@ -28,10 +30,12 @@
 | T4 设备端 SoC | 设备本体内的统一内存异构平台 | 工业 SoC、车规 SoC、端侧 AI 模组 | CPU/NPU/GPU 共享资源与带宽隔离 |
 | T3 边缘节点 | 设备附近的就地计算节点 | 边缘盒子、边缘工控机、Jetson/IGX 节点 | 近源推理、多任务并发、热与供电约束 |
 | T2 桌面 / 工作站单机 | 单机高密度本地推理与研发验证平台 | RTX 工作站、多 GPU 单机、实验室服务器 | 单机多卡调度、互联拓扑与公平性 |
-| T1 服务器 / 集群 | 多节点大模型服务与分布式协同平台 | x86/ARM 服务器、多 GPU、多节点集群 | 跨节点通信、分布式调度与规模扩展 |
+| T1 服务器 / 集群 | 面向任务关键场景的分布式协同计算平台 | x86/ARM 服务器、多 GPU、多节点集群 | 跨节点通信、分布式协同与规模扩展 |
 
 这五类部署形态首先依据**部署位置与系统角色**划分，其次才是容量和功耗。
 
+其中，`T1` 不表示通用训练机房或公网高吞吐推理集群，而是任务关键系统中的机架式协同计算平台。它承担的是全局状态管控、多源信息融合推理和跨节点决策协同等任务。
+
 ### 1.2 五种算力基础
 
 | 算力基础 | 资源形态 | 代表平台 | 对 RTOS 的主要挑战 |
@@ -77,7 +81,7 @@
 │ 调度器、中断管理、同步机制、时钟、内存、隔离与恢复机制           │
 ├───────────────────────────────────────────────────────────────┤
 │ L1 硬件与互联层                                                 │
-│ SoC、加速器、统一内存、显存、缓存、总线、NVLink、网络互联        │
+│ SoC、加速器、统一内存、显存、缓存、总线、NVLink、网络互联、PTP   │
 └───────────────────────────────────────────────────────────────┘
 ```
 
@@ -113,6 +117,11 @@ FFN / 设备计算              → 可流水化计算任务
 - 哪些资源需要隔离；
 - 哪些竞争会直接破坏关键保障负载。
 
+这里还要明确区分两类执行单元：
+
+- CPU 侧软件任务、系统调用、中断处理和资源治理逻辑，处于 RTOS 可调度与可分析范围；
+- GPU/NPU 等加速器内部算子流水线、显存调度和设备微架构执行行为，由驱动与硬件管理，不属于 RTOS 内核直接控制域。
+
 ---
 
 ## 3. 研究主线：实时保障机制
@@ -134,7 +143,28 @@ FFN / 设备计算              → 可流水化计算任务
 
 > **RTOS 能否在多类目标负载并存时，让系统继续有边界。**
 
-### 3.1 研究方法总述
+### 3.1 面向小型化与低功耗方向的应用副课题
+
+在六个机制方向之外，项目设置一条面向应用落点的专题线：
+
+> **面向小型化与低功耗方向的应用副课题。**
+
+这条副课题主要聚焦 `T5` 控制端与 `T4` 设备端 SoC 两类部署形态，重点关注下面四类约束同时成立时的系统表现：
+
+1. **功耗预算刚性**：整机输入功率、空闲功耗与单位任务能耗需要被明确约束；
+2. **体积与散热受限**：被动散热、轻量散热或设备本体内封装条件下的持续运行能力；
+3. **内存与带宽预算有限**：统一内存、片上 NPU/GPU 与 CPU 共享资源时的竞争边界；
+4. **关键保障任务不可退让**：控制回路、联锁与外部接口时序边界必须持续满足。
+
+这条副课题不与“推理图任务调度、KV Cache 与内存管理、加速器协同调度、量化与精度感知调度、中断与实时性保障、能耗与热管理”六个机制方向并列。它的作用是把这些机制组织成一个更聚焦的应用观察窗口，用于回答：
+
+- 小型化与低功耗系统是否仍能承载人工智能目标负载；
+- RTOS 在严格功耗与散热预算下如何维持关键保障负载边界；
+- 哪些机制组合最能体现 RTOS 相对普通 Linux 与 PREEMPT_RT Linux 的差异。
+
+因此，这一副课题承担的是“应用聚焦与证据收束”的角色，而不是新的并列机制方向。
+
+### 3.2 研究方法总述
 
 为了回答这个问题，研究方法采用一条统一证据链：
 
@@ -147,6 +177,8 @@ FFN / 设备计算              → 可流水化计算任务
 
 因此，本研究最终给出的是一套可复现、可比较、可解释的系统级证据链。
 
+这套统一框架统一的是研究对象定义、负载建模、评估指标与对照方法，不预设同一套机制会在所有档位取得同等收益。研究结论将以有效区间、失效边界和贡献来源的形式展开。
+
 ---
 
 ## 4. 评价框架：双目标达标 + 系统协同稳定
@@ -239,10 +271,12 @@ FFN / 设备计算              → 可流水化计算任务
 ## 8. 预期研究成果
 
 1. **理论层**：任务关键系统中人工智能目标负载的实时保障问题定义与评价框架；
-2. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
-3. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
-4. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位实测对照数据；
-5. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。
+2. **分析层**：面向人工智能目标负载与关键保障负载共存场景的可调度性建模、响应时间分析与边界推演方法；
+3. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
+4. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
+5. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位对照数据与边界证据；
+6. **应用层**：面向小型化与低功耗系统的专题化验证结论、边界解释与应用归纳；
+7. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。
 
 ---
 

项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/07-方法论与评估工具链.md

@@ -59,6 +59,15 @@
 硬件承担关键验证矩阵角色。
 `T5~T1` 五类部署形态和 `11` 个代表档位用于验证系统机制在不同资源条件下的成立范围与边界。
 
+这套验证矩阵统一的是建模、测量与对照方法，不预设同一套 RTOS 机制会在所有档位取得相同收益。研究重点是识别不同部署层级下机制有效的条件、收益来源与失效边界。
+
+对于 `T2/T1` 这类搭载独立 GPU 或复杂互联的层级，还需要单独区分两类证据：
+
+- CPU 侧实时调度、中断隔离、内存预算、关键保障负载保护等系统级证据；
+- 加速器执行、跨卡通信、驱动与运行时行为带来的平台级边界证据。
+
+前者属于 RTOS 直接可分析范围，后者作为系统约束和外部边界进入解释框架。
+
 ## 3. 负载建模：三类负载
 
 ### 3.1 三类负载定义
@@ -137,6 +146,8 @@
 
 任何准入失败都要作为研究记录保留。
 
+对于 `T2/T1` 扩展层级，如果商业 GPU 驱动生态或平台条件限制了 RTOS 原生实测，需将该层级明确标注为建模分析、条件验证或基线对照证据，不把未完成的 RTOS 原生实测写成正式结果。
+
 ## 6. 对照原则
 
 ### 6.1 固定不变项
@@ -146,6 +157,7 @@
 - 模型版本、量化格式、tokenizer、输入长度与输出长度；
 - CPU 核数量、优先级、内存预算、加速器数量；
 - 到达流、随机种子、预热时间、采样窗口；
+- PTP 或等效时钟同步方式、时间戳对齐策略与测量链路；
 - 环境温度、散热、驱动与框架版本。
 
 ### 6.2 允许变化项
@@ -161,7 +173,7 @@
 
 ## 7. 建模与分析方法
 
-### 7.1 调度分析
+### 7.1 可调度性与响应时间分析
 
 关键保障负载优先使用固定优先级与响应时间分析：
 
@@ -183,6 +195,8 @@ R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
 - 可隔离的设备任务；
 - 必要时具有阶段性优先级的任务图。
 
+当场景包含跨节点协同或外部总线闭环时，还需把时间同步误差、通信抖动和设备完成事件纳入分析参数。对于具备形式化边界的关键保障任务，应进一步结合 WCET 假设、到达模型与调度策略，形成可调度性判定条件。
+
 ### 7.2 容量与热稳定性分析
 
 对人工智能目标负载，需要同时分析：
@@ -217,6 +231,7 @@ R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
 | 性能分析 | perf、设备 profiler、定制采样脚本 |
 | 功率与温度 | 外部功率计、PDU、板载传感器、温度记录 |
 | 外设测量 | 示波器、逻辑分析仪、CAN/RS485 分析仪 |
+| 时间同步 | PTP、硬件时间戳、同步误差校验脚本 |
 
 下面给出统一测量矩阵，用于把指标、采样工具与观测目的对齐：
 
@@ -273,6 +288,7 @@ R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
 
 1. **怎么保证研究对象始终落在 RTOS 平台层；**
 2. **怎么把人工智能目标负载、关键保障负载和伴生竞争负载统一进同一评价框架；**
-3. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据。**
+3. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据；**
+4. **怎么用统一方法识别不同部署层级下 RTOS 机制的有效区间与失效边界。**
 
 这也是后续 `02-基础设备与算力基础.md`、`03-实验设计.md` 和 `04-论文写作规划.md` 必须共同服从的方法论中轴。

项目框架1-基于RTOS的五类场景AI实时性研究/10-研究框架/README.md

@@ -0,0 +1,60 @@
+# 研究框架索引
+
+本目录放置项目的核心研究框架文档，分为两部分：
+
+1. **主干机制文档**：作为公共研究材料，沉淀已经形成的主线表达、机制拆解与方法论；
+2. **候选课题框架目录**：并行维护 3 套可讨论、可修改、可优选的课题框架方案。
+
+## 阅读建议
+
+### 1. 主干机制文档
+
+1. `00-整体研究框架.md`
+2. `01-推理图任务调度.md`
+3. `02-KV-Cache与内存管理.md`
+4. `03-加速器协同调度.md`
+5. `04-量化精度感知调度.md`
+6. `05-中断与实时性保障.md`
+7. `06-能耗与热管理.md`
+8. `07-方法论与评估工具链.md`
+9. `参考文件/README.md`
+
+### 2. 候选课题框架目录
+
+1. `方案A-RTOS平台主导框架/00-课题框架.md`
+2. `方案B-系统协同保障框架/00-课题框架.md`
+3. `方案C-小型化与低功耗应用框架/00-课题框架.md`
+
+## 文件说明
+
+- `00-整体研究框架.md`
+  - 研究总框架、问题空间、技术分层、预期成果
+- `01-推理图任务调度.md`
+  - LLM 推理 DAG 拆解、任务映射与调度策略
+- `02-KV-Cache与内存管理.md`
+  - KV Cache 生命周期、内存池、带宽竞争与局部性
+- `03-加速器协同调度.md`
+  - CPU、NPU、GPU、DMA 等异构资源协同
+- `04-量化精度感知调度.md`
+  - 精度、资源占用和调度决策的联动关系
+- `05-中断与实时性保障.md`
+  - IRQ 路径、线程化、中断隔离与实时任务保护
+- `06-能耗与热管理.md`
+  - 能耗约束、温度耦合、频率策略与热稳定性
+- `07-方法论与评估工具链.md`
+  - 建模、仿真、原型验证和评估方法学
+- `参考文件/`
+  - 按研究方向整理的论文、标准、官方工程资料及其与本项目的证据映射
+
+## 候选框架说明
+
+- `方案A-RTOS平台主导框架`
+  - 保持“大型跨平台 RTOS”作为研究主语，适合继续沿现有主线推进
+- `方案B-系统协同保障框架`
+  - 强调 RTOS、运行时、模型与加速器协同治理，适合承接系统级方法学讨论
+- `方案C-小型化与低功耗应用框架`
+  - 强调 `T5/T4` 受限系统与低功耗应用场景，适合形成更聚焦的专题路线
+
+## 使用方式
+
+后续讨论、修改和优选时，可以优先在这 3 个候选目录中推进，不必立即改动主干机制文档。待最终课题框架确定后，再把优选结果回收进 `00-整体研究框架.md` 及相关主干文件。

项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/01-研究逻辑说明.md

@@ -36,6 +36,8 @@
 - **对照对象**：普通 Linux、PREEMPT_RT Linux 与 SylixOS；
 - **硬件角色**：验证矩阵。
 
+在这条主线之下，项目同步设置一个**面向小型化与低功耗方向的应用副课题**。这一副课题主要锚定 `T5/T4`，用于集中组织小型化设备、设备端 SoC 与轻量智能终端中的证据，不单独改变研究对象，也不替代六个机制方向。
+
 ## 3. T5~T1 五类部署形态与 11 个代表档位
 
 硬件细度是本仓库的重要资产。`T5~T1` 与 `11` 个代表档位共同承担三项作用：
@@ -57,6 +59,8 @@
 `T3`、`T2` 分别对应近源边缘节点与单机高密本地推理平台。
 `T5~T1` 作为**部署形态与运行环境代码**，用于组织跨场景验证矩阵。
 
+其中，`T5/T4` 还承担面向小型化与低功耗方向应用副课题的主要验证窗口。这里的重点不是把低功耗设备本身当作研究对象，而是借助更严格的功耗、散热、体积与统一内存预算，观察 RTOS 机制边界在真实受限条件下的成立区间。
+
 ## 4. 人工智能目标负载与系统负载结构
 
 在任务关键系统里，负载应至少分成三类：
@@ -112,6 +116,8 @@
 
 这条顺序用于区分平台就绪性问题与系统机制边界问题。
 
+对于面向小型化与低功耗方向的应用副课题，实验推进时优先选择 `T5-H`、`T4-L` 及后续 `T5-L/T5-M` 作为主验证窗口，再把结论回收到总课题的统一对照框架中。
+
 ## 8. 哪些指标构成核心证据
 
 后续证据链必须覆盖三层：
@@ -155,6 +161,8 @@
 
 在这套结构下，硬件细度得到完整呈现，并服务于研究对象与实验结论组织。
 
+面向小型化与低功耗方向的应用副课题不单列为新的核心贡献项，而是作为 `C1` 与 `C2` 在 `T5/T4` 场景中的集中展开位置，用于加强项目在小型化设备与受限部署环境中的解释力。
+
 ## 10. 最终闭环
 
 本研究形成的核心结论关系是：

项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/03-实验设计.md

@@ -16,6 +16,10 @@
 
 执行分为两层：**核心实验使用现有 T2-L、T4-L 和 T5-H 内存受限配置；其他档位属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM、YOLO 检测和语音识别都按**人工智能目标负载**处理；训练不纳入主实验。
 
+这套实验设计统一的是研究问题、对照原则、采样口径与评价方法，不要求所有档位都完成同等深度的实机验证。核心档位承担主证据，扩展档位用于补足边界、拓扑和规模变化下的成立条件与失效边界。
+
+在统一实验主线之下，本文同步组织一个**面向小型化与低功耗方向的应用副课题实验包**。这一实验包主要落在 `T5-H`、`T4-L` 以及后续 `T5-L/T5-M` 条件扩展档位，集中观察被动散热、整机功耗预算、统一内存约束与关键保障负载并存时，RTOS 对双目标达标能力的支撑边界。
+
 ## 2. 设备分层与实验平台
 
 ### 2.1 T5~T1 五类部署形态、十一档实验映射
@@ -33,12 +37,35 @@
 | T2-L 桌面低 | 现有 4×V100 SXM 32 GB，总显存 128 GB | 核心平台 A | 多卡推理、NVLink 通信与实时隔离 |
 | T2-M 桌面中 | 8×V100 32 GB，总显存 256 GB | 待扩容 | 同代 GPU 数量扩展 |
 | T2-H 桌面高 | 4×H100 80 GB，总显存 320 GB | 待获取或租用 | 高算力密度、跨代对照 |
-| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信与分布式推理 |
-| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式服务与能效 |
+| T1-L 集群低 | 4 节点×4×V100，总显存 512 GB | 待扩展 | 跨节点通信、分布式协同与关键业务编排 |
+| T1-H 集群高 | 4 节点×4×H100，总显存 1.28 TB | 远期扩展 | 大模型分布式协同服务与系统级能效 |
 
 GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。
 
-### 2.2 测量设备
+`T1` 在本项目中表示面向任务关键场景的分布式协同计算平台，不表示通用 AI 训练集群或公网高吞吐推理机房。该层级的实验重点是人工智能目标负载并发存在时，CPU 侧关键保障负载、系统编排与跨节点协同机制能否维持时间边界。
+
+其中，`T5-H`、`T4-L` 及后续 `T5-L/T5-M` 同时承担面向小型化与低功耗方向应用副课题的主窗口。相关结论单独按“小型化、低功耗、受限散热与内存预算”口径组织，但仍纳入总课题的统一对照体系，不作为独立于主课题之外的新实验主线。
+
+### 2.2 平台 A：现有 V100 服务器
+
+依设备清单配置 H12D-8D 主板、单颗 EPYC 7402（24 核/48 线程）、128 GB DDR4、1 TB NVMe、4×V100 SXM 32 GB、NVLink 底板、双电源及液冷。完整 BOM 见设备文档 T2.2.1。
+
+实验前采集 CPU/NUMA 拓扑、实际内存通道、PCIe 链路、逐对 GPU 互联与带宽、各卡温度和功率上限。4 卡互联形态以枚举和通信测试为准。双电源输入均纳入整机能耗，不把额定电源瓦数当作运行功耗。
+
+分别测试 1、2、4 卡；单卡先完成模型与采样链路验证，再加入多卡并行。CPU 实时任务使用固定物理核，记录其 SMT 同胞核的使用方式，避免不同组的物理资源分配不一致。
+
+### 2.3 平台 B：现有 RK3588 工业盒
+
+依设备清单采用 4×A76 + 4×A55、16 GB 统一内存、64 GB eMMC，以及实际引出的 GPIO、CAN、RS485 和网络接口。原生 NPU 与外接加速器分开登记。
+
+- B16：全量 16 GB，记为 T4-L。
+- B8：同板施加 8 GB 限额，记为 T5-H 受限配置；两种配置顺序运行。
+- 原生 NPU 是首轮路径；扩展加速器作为独立配置单独验证，待芯片型号、连接方式、模型格式和任务拆分能力完成准入后纳入对照。
+- 可选 M0、CAN 和 RS485 必须先核对实物与 BSP；缺失的接口实验登记为未开展。
+
+**内存限额口径**：优先采用能覆盖 OS 可见内存及加速器保留区的启动配置，并记录实际可用容量。若只能限制应用进程，则标为“8 GB 应用预算”，不能称为整机 8 GB。核对驱动缓冲区、DMA/CMA、页缓存、共享内存与交换空间是否受限；禁止将限额实验解释为真实 8 GB 板卡的功耗或带宽结论。
+
+### 2.4 测量设备
 
 | 测量对象 | 工具与接线 | 要求 |
 |---|---|---|
@@ -66,6 +93,8 @@ SylixOS、Linux 与 PREEMPT_RT Linux 的软件栈均按候选路线处理，在
 
 “SylixOS 实时域 + Linux 推理域”作为单独的异构系统架构组，单独记录核分配、通信方式和内存共享方式，并作为异构系统方案结论呈现。
 
+对于搭载独立 GPU 的平台，RTOS 主要负责 CPU 侧任务调度、中断线程、内存预算、关键保障负载保护与恢复策略；GPU 内部算子调度、显存流水线和设备执行细节由驱动与硬件管理。因此，这类平台的实验解释必须区分 RTOS 直接收益与加速器平台边界。
+
 ### 3.2 模型梯度与用途
 
 | 平台 | 首轮候选 | 扩展候选 | 后端准入检查 |
@@ -183,6 +212,14 @@ YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，
 | E7 消融 | O3 完整方案及逐项去除 | 使用 E3 中固定中载与过载单元重复测试 | RQ2 |
 | E8 长稳与恢复 | A、B 的最终候选配置 | 连续 24 小时混合负载，注入推理进程重启、队列过载 | RQ1/3 |
 
+面向小型化与低功耗方向的应用副课题，主要由 `E2`、`E3`、`E4`、`E6` 与 `E8` 共同支撑：
+
+- `E2` 负责建立受限设备上的独立推理能效与服务能力基线；
+- `E3` 负责比较双目标并存时的达标边界；
+- `E4` 负责观察内存限额与容量失败边界；
+- `E6` 负责组织功耗、温度与降频证据；
+- `E8` 负责验证长时间运行、恢复与热稳定性。
+
 E5 中，同一 7B 模型只有在所有 GPU 数配置均支持相同后端及并行机制时才计算强扩展；多实例吞吐增长单列，不冒充单请求加速。多租户公平性可使用各租户相对独占吞吐 x_i，计算 Jain 指数 (Σx_i)²/(kΣx_i²)，同时报告每租户 TTFT 和服务等级。
 
 E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳定吞吐的时间。驱动重置和热环境测试仅在存在可恢复测试路径和相应设备时增加；没有温箱数据不能宣称覆盖 −40～60℃ 全温域。
@@ -199,6 +236,8 @@ E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳
 
 T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的完成时间为基准，效率 = 加速比/(n/n0)；弱扩展固定每节点请求负载，报告总有效吞吐和尾延迟。网络协议、交换机、MTU、拥塞配置和进程布局冻结。RDMA/NCCL 不可用时，TCP 回退单独成组。
 
+若 `T2/T1` 层级受商业 GPU 驱动、BSP 或运行时条件限制，无法完成 SylixOS 原生路径实测，则该层级结果降级为基线对照、建模分析或异构架构验证，不将缺失的原生 RTOS 数据写成正式对照结论。
+
 跨节点单向延迟需记录时钟同步方法与误差；误差不能满足精度要求时改测往返时间，不将其一半无条件当作单向延迟。
 
 ### 7.3 控制实验数量

项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/04-论文写作规划.md

@@ -11,14 +11,14 @@
 
 ### 0.1 一句话定位
 
-> **用业界公认方法学，在 T5~T1 五类部署形态与 11 个代表档位上，系统评测大型跨平台实时操作系统这一类平台在任务关键系统中承载人工智能目标负载时的确定性、可预测性与实时保障表现，并同步评估人工智能目标负载的功能有效性与时效性。`SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等作为外部参照样本。**
+> **用业界公认方法学，在 T5~T1 五类部署形态与 11 个代表档位上，系统评测大型跨平台实时操作系统这一类平台在任务关键系统中承载人工智能目标负载时的确定性、可预测性与实时保障表现，并同步评估人工智能目标负载的功能有效性与时效性。`SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等作为外部参照样本。该框架统一的是建模、评估与对照方法，结论以各部署层级的有效区间与失效边界展开。**
 
 ### 0.2 三大核心贡献
 
 | 编号 | 贡献 | 来源整合 | 对标空白 |
 |------|------|----------|----------|
 | C1 | **大型跨平台 RTOS 对人工智能目标负载与关键保障负载的双目标实时保障优势** — 在同硬件、同负载下，以 `SylixOS` 为主实验样例，比对其与普通 Linux、PREEMPT_RT Linux 在 `TTFT/TPOT`、`deadline miss ratio`、`P99.9` 抖动与有效吞吐上的差异，并与 QNX、VxWorks、INTEGRITY、LynxOS-178 等外部样本形成理论参照 | 03-实验设计.md、07-方法论与评估工具链.md | 公开研究通常只测吞吐，缺少任务关键系统中的双目标评测 |
-| C2 | **T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵** — 从 T5 控制端 RK3568 (1 GB/3 W) 到 T1 集群级 4×H100 (1.28 TB/25 kW)，以完整硬件颗粒度系统刻画 RTOS 机制优势随资源条件、拓扑和部署形态变化的规律与边界 | 02-基础设备与算力基础.md §0~§5 | 公开研究通常只覆盖单一平台或两档对比，缺少连续验证框架 |
+| C2 | **T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵** — 从 T5 控制端 RK3568 (1 GB/3 W) 到 T1 集群级 4×H100 (1.28 TB/25 kW)，以完整硬件颗粒度系统刻画 RTOS 机制优势随资源条件、拓扑和部署形态变化的规律与边界；统一的是方法学与证据组织方式，不预设各档位收益幅度相同 | 02-基础设备与算力基础.md §0~§5 | 公开研究通常只覆盖单一平台或两档对比，缺少连续验证框架 |
 | C3 | **RTOS 数据与业界公开基准的可复现对齐方法** — 引入第三方文章的 CPU/内存/NPU/功耗实测方法学，在 SylixOS 上复现并对比，使 RTOS 结果具备外部校验与方法学可迁移性 | 03-实验设计.md、07-方法论与评估工具链.md | 国产 RTOS 在设备端 SoC 与边缘节点平台上的可外部校验数据明显不足 |
 
 ### 0.3 目标读者与发表场景
@@ -38,7 +38,7 @@
 第1章  引言 — 问题、动机、贡献概述
 第2章  背景与相关工作 — 人工智能目标负载特征 + RTOS 基础 + 差距分析
 第3章  T5~T1 五类部署形态验证矩阵 — 11 档位体系设计与现有设备锚点
-第4章  SylixOS 调度框架技术架构 — 五层技术栈与六大优化方向
+第4章  SylixOS 调度框架技术架构 — 五层技术栈、六大优化方向与低功耗专题线
 第5章  实验方法学 — 第三方基准复现 + 双目标场景 + 避坑约束
 第6章  大模型负载选型与配置 — 跨档位模型矩阵
 第7章  实验结果 — 基准对齐 + 双目标实时保障 + 能效 + 温度耦合
@@ -97,7 +97,7 @@
 | 3.2 全谱系总表 (11 档位) | T5-L→T5-M→T5-H→T4-L→T4-M→T3-L→T2-L→T2-M→T2-H→T1-L→T1-H 的容量/算力/功耗/散热/代表设备/状态 | 02-基础设备与算力基础.md §0.2 |
 | 3.3 设计原则 | 容量连续功耗阶跃；CUDA 栈贯通 T1/T2/T3；非 CUDA 控制端与设备端路线 (T5 全档 + T4-L)；现有硬件复用 (V100+RK3588 锚点)；BSP 最小化 (x86+ARM64 两类) | 02-基础设备与算力基础.md §0.3 |
 | 3.4 现有设备与采购计划 | P0 零成本起步 (T2-L+T4-L+T5-H)；一机两档 (RK3588 16 GB 同时充当 T4-L 与 T5-H)；T1/T2-H 云替代 | 02-基础设备与算力基础.md §6 |
-| 3.5 各部署形态定位与验证重点 | T1 跨节点分布式调度；T2 桌面/工作站单机多卡 NVLink；T3 边缘节点近源协同；T4 设备端 SoC 统一内存带宽隔离；T5 极致资源约束下的关键保障负载边界保持 | 02-基础设备与算力基础.md T1~T5 各 §.1 |
+| 3.5 各部署形态定位与验证重点 | T1 面向任务关键场景的跨节点分布式协同计算；T2 桌面/工作站单机多卡 NVLink；T3 边缘节点近源协同；T4 设备端 SoC 统一内存带宽隔离；T5 极致资源约束下的关键保障负载边界保持 | 02-基础设备与算力基础.md T1~T5 各 §.1 |
 
 **关键图表**:
 
@@ -112,15 +112,16 @@
 
 ### 第4章 SylixOS 调度框架技术架构
 
-**目标**: 600~800 词，将 `00-整体研究框架.md` 的五层技术栈和六大优化方向浓缩为文章的技术背景章。
+**目标**: 600~800 词，将 `00-整体研究框架.md` 的五层技术栈、六大优化方向与低功耗专题线浓缩为文章的技术背景章。
 
 | 小节 | 内容要点 | 来源映射 |
 |------|----------|----------|
 | 4.1 核心问题定义 | 用 RTOS 做 "LLM 推理资源的调度与协调"，并建立任务关键系统中的实时保障机制 | 00-整体研究框架.md §0 |
-| 4.2 五层技术栈 | L1 硬件层 → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | 00-整体研究框架.md §2 |
+| 4.2 五层技术栈 | L1 硬件层（含时间同步/PTP） → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | 00-整体研究框架.md §2 |
 | 4.3 LLM 推理阶段 → RTOS 任务映射 | Tokenizer→LOW, Embedding→HIGH, Attention→MAX, FFN→HIGH, KV Cache Write→MEDIUM, Sample→LOW；阶段特征矩阵 (计算/IO/延迟敏感/确定性/优先级) | 01-推理图任务调度.md §2 |
 | 4.4 六大优化方向概览 | 方向1 推理图任务调度 (Hybrid FP+EDF) → 方向2 KV Cache 内存池 → 方向3 加速器协同 → 方向4 量化感知调度 → 方向5 中断与实时 → 方向6 能耗热管理 | 00-整体研究框架.md §3, 01~06 子文档 |
-| 4.5 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 02-基础设备与算力基础.md §7 (BSP Checklist) |
+| 4.5 面向小型化与低功耗方向的专题线 | 该专题线主要锚定 `T5/T4`，把调度、内存、量化、加速器协同、中断与能耗机制收束到受限功耗、体积、散热与内存预算场景中观察 | 00-整体研究框架.md §3.1 |
+| 4.6 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 02-基础设备与算力基础.md §7 (BSP Checklist) |
 
 **关键图表**:
 
@@ -129,7 +130,7 @@
 | Fig.3 | 五层技术栈架构图 | L1~L5 层叠 + 每层关键组件 + 层间接口 |
 | Fig.4 | LLM 推理 DAG → RTOS 任务图 | 推理阶段的有向无环图, 标注每阶段优先级 (MAX/HIGH/MEDIUM/LOW) 和可抢占性 |
 | Tab.5 | 推理阶段特征矩阵 | 阶段 × (计算密集度/IO 密集度/延迟敏感度/确定性要求/RTOS 优先级) |
-| Tab.6 | 六大优化方向概览 | 方向 × (核心问题/关键手段/目标指标/对应章节) |
+| Tab.6 | 六大优化方向与低功耗专题线概览 | 方向/专题 × (核心问题/关键手段/目标指标/对应章节) |
 
 ---
 
@@ -139,13 +140,15 @@
 
 | 小节 | 内容要点 | 来源映射 |
 |------|----------|----------|
-| 5.1 方法论框架 | `G0~G4` 准入 → `O0~O4` 对照 → 负载建模 → 机制实现 → 实测验证 → 跨档位分析 | 07-方法论与评估工具链.md §1、§5、§6、§9 |
+| 5.1 方法论框架 | `G0~G4` 准入 → `O0~O4` 对照 → 负载建模 → 机制实现 → 实测验证 → 跨档位分析；统一的是建模与评估方法，结论按有效区间与失效边界展开 | 07-方法论与评估工具链.md §1、§5、§6、§9 |
 | 5.2 第三方基准复现方法学 | 引入第三方文章的 5 维度方法 (CPU/内存/NPU/功耗/温度)；在 SylixOS 上重跑等价工具链，与文章数据对比 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
 | 5.3 混合负载实验设计四原则 | 原则1: 混合负载；原则2: 尾部时延指标；原则3: 突发场景；原则4: 调度精细度 | 03-实验设计.md §5、§6 |
 | 5.4 功耗真测强制约束 | 禁止仅靠软件读数；DC 功率计 + INA226 采集板强制；采样 ≥1 Hz | 03-实验设计.md §2.4、§4 |
 | 5.5 温度监控强制约束 | 烤机 1 h 稳态 <75 ℃ 才采样；≥85 ℃ 数据作废；全程温度日志 | 03-实验设计.md §2.4、§4 |
 | 5.6 环境元数据强制清单 | OS/内核/BSP/固件/驱动/室温/散热/工具/量化/时间戳等元数据强制记录 | 03-实验设计.md §11、07-方法论与评估工具链.md §10 |
 | 5.7 对照组设计 | OS 层: `O0` 普通 Linux / `O1` PREEMPT_RT Linux / `O2` SylixOS 默认 / `O3` SylixOS 优化 / `O4` PREEMPT_RT 等预算调优；KVM/Docker 仅作为扩展对照 | 03-实验设计.md §5 |
+| 5.7A 管控边界说明 | 区分 CPU 侧 RTOS 可调度域与 GPU/NPU 设备执行域；T2/T1 的重点是 CPU 侧关键保障负载保护与系统协同边界，不把 GPU 内部调度写成 RTOS 直接收益 | 00-整体研究框架.md §2、03-实验设计.md §2、§3 |
+| 5.7B 证据层级说明 | 核心档位以实测为主；受驱动与 BSP 约束的扩展档位可使用基线对照、建模分析与条件验证，未完成的原生 RTOS 路径不写成正式结果 | 03-实验设计.md §1、§7 |
 | 5.8 研究问题到实验映射 | 明确 `RQ1~RQ4` 分别由哪些实验单元、场景编号与结果章节支撑，避免论文章节与实验表脱节 | 03-实验设计.md §1、§7 |
 | 5.9 场景编号到结果章节映射 | 明确 `L0~L7` 在论文中的归属位置：哪些是基线、哪些是核心双目标证据、哪些是扩展或压力场景 | 03-实验设计.md §6、§7 |
 
@@ -194,7 +197,7 @@
 | 小节 | 内容要点 | 来源映射 |
 |------|----------|----------|
 | 7.1 基准对齐结果 (第一层判据) | SylixOS 在 RK3588 上的 CPU 单核/多核、内存带宽、NPU FPS、3B LLM tok/s 与第三方文章基线的偏差 | 03-实验设计.md §4、07-方法论与评估工具链.md §8 |
-| 7.2 低功耗结果 | 对应 `RQ3`；以 `L1/L2` 为主，报告 `P_idle / P_prefill / P_decode / E_per_token` 分阶段功耗曲线；T2-L (V100) 与 T4-L/T5-H (RK3588) 两平台对照；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的能效差异 | 03-实验设计.md §4、§6、06-能耗与热管理.md |
+| 7.2 低功耗结果 | 对应 `RQ3`；以 `L1/L2` 为主，报告 `P_idle / P_prefill / P_decode / E_per_token` 分阶段功耗曲线；T2-L (V100) 与 T4-L/T5-H (RK3588) 两平台对照；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的能效差异；这一节同时承担面向小型化与低功耗方向应用副课题的核心结果窗口 | 03-实验设计.md §4、§6、06-能耗与热管理.md |
 | 7.3 低延迟结果 | 对应 `RQ1/RQ2`；以 `L0/L1` 为基线，报告 `T_irq / T_sched / T_ctx` `P50~Max` 与 `TTFT / TPOT` 尾延迟分布；SylixOS vs 普通 Linux / PREEMPT_RT Linux 的 `P99.9/Max/σ` 对比 | 03-实验设计.md §4~§6、05-中断与实时性保障.md |
 | 7.4 双目标实时保障结果 (★ 核心) | 对应 `RQ1`；以 `L2` 为主场景，并向 `L3/L4/L5/L7` 扩展；同时报告 `TTFT/TPOT`、`T_rt_max`、`jitter` 与有效吞吐；4 变体 (`O0/O1/O2/O3` 或含 `O4`)；30 min 全周期时间序列图 | 03-实验设计.md §5~§7 |
 | 7.5 多模型并发与突发场景 | 对应 `RQ2/RQ4`；覆盖 `L3/L5/L6/L7`，讨论多模型流水线优先级公平性、突发加载/切换瞬间实时性保持，以及 GPU/NPU 多请求调度公平性 | 03-实验设计.md §6、10-研究框架/01~03 |
@@ -265,7 +268,7 @@
 
 | 小节 | 内容要点 | 来源映射 |
 |------|----------|----------|
-| 9.1 适用场景边界 | 资源更受限或混合负载更强的档位通常更容易体现 RTOS 优势；资源充裕且目标偏纯吞吐时，优势可能收窄 | 01-研究逻辑说明.md §10、03-实验设计.md §10 |
+| 9.1 适用场景边界 | 资源更受限或混合负载更强的档位通常更容易体现 RTOS 优势；资源充裕且目标偏纯吞吐时，优势可能收窄；T1 仅限任务关键场景中的分布式协同计算平台，不覆盖通用 AI 训练集群 | 01-研究逻辑说明.md §10、03-实验设计.md §10 |
 | 9.2 威胁有效性 | (1) RKLLM 移植风险；(2) V100 驱动成熟度；(3) sysbench/stress-ng 等工具的可移植性；(4) 量化精度差异控制；(5) 室温/散热波动 | 03-实验设计.md §3、§11 |
 | 9.3 与已有工作的关系 | vs vLLM/TGI (服务器级, 无实时保证)、vs NPU SDK (封闭黑箱)、vs CUDA Stream (无实时分析)、vs 第三方文章 (仅 Linux, 仅 RK3588, 未测实时性) | 00-整体研究框架.md §6 |
 | 9.4 方法论局限 | 第三方来源数量有限；扩展档位依赖云租或后续采购；消融实验现阶段主要集中在现有核心平台；未完成档位不能写成正式结果 | 03-实验设计.md §10、07-方法论与评估工具链.md §10 |
@@ -291,7 +294,7 @@
 | **02-基础设备与算力基础.md** | §3 (验证矩阵) | §4.5 (BSP 适配), §6.2 (模型矩阵), §7.8 (跨档位曲线), §8.1 (档位趋势), §8.5 (BSP 风险) |
 | **03-实验设计.md** | §5 (实验方法学), §7.4 (混合负载) | §2.1~§2.3 (负载与平台), §5.7 (对照组), §6 (模型选型), §7.2~§7.7 (功耗/延迟/并发/突发/异构), §8.2 (优越性量化), §9.2 (威胁有效性) |
 | **01-研究逻辑说明.md** | §1 (核心问题), §9 (贡献排序) | §2 (研究对象), §9.1 (适用边界), §10 (最终闭环) |
-| **00-整体研究框架.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §8.3 (根因分析), §10.3 (开放问题) |
+| **00-整体研究框架.md** | §4 (技术架构) | §1 (核心问题), §2.4 (相关工作), §7.2 (低功耗专题线), §8.3 (根因分析), §10.3 (开放问题) |
 | **01-推理图任务调度.md** | §4.3 (任务映射) | §7.4 (混合负载调度模型), §8.3 (根因) |
 | **02-KV-Cache与内存管理.md** | §4.4 (方向2 概览) | §7.4 (KV Cache 对实时任务的影响), §8.4 (能效) |
 | **03-加速器协同调度.md** | §4.4 (方向3 概览) | §7.7 (异构核分配), §8.3 (根因) |

项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/潜在合作研究路径-罗蕾教授与翼辉信息.md

@@ -166,6 +166,22 @@
 - 翼辉信息侧偏产业价值、案例与平台能力；
 - 项目组承担材料汇总、写作配合与整合支撑。
 
+### 5.5 面向小型化与低功耗方向的 RTOS 智能负载应用
+
+目标：
+
+- 聚焦小型化设备、边缘控制节点、轻量智能终端中的人工智能目标负载部署问题；
+- 研究在严格功耗、体积、散热与内存预算下，RTOS 如何同时维持推理服务能力与关键保障任务实时性；
+- 形成一套适用于低功耗、资源受限系统的任务准入、运行降级与能耗治理方法。
+
+更适合的分工：
+
+- 罗蕾教授侧可重点参与资源约束建模、可调度性分析、低功耗系统方法学抽象与学术问题凝练；
+- 翼辉信息侧可重点参与 SylixOS 在小型化硬件平台上的机制实现、BSP 支撑与工程验证；
+- 项目组负责具体场景选取、实验执行、数据整理与跨平台对照分析。
+
+这一主题与本项目现有 `T5/T4` 验证位置可以自然衔接，也更容易延伸到工业控制终端、车载边缘节点、轻量智能装备等应用语境。
+
 ## 6. 更现实的推进顺序
 
 推进顺序以稳妥、小步、可验证为宜：

项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/04-代表成果与研究主题.md

@@ -8,7 +8,7 @@
 
 第三类成果是网络安全与数据安全。她及其团队长期从事物联网安全、区块链与数据安全工作，形成了“优云链”“优数”等成果，并将其用于物流追踪、汽车数据交易、移动支付可信共享等场景。论文成果也体现出她团队在入侵检测、代码混淆安全模型、异常检测等方面的持续投入。这部分工作的意义，在于把原本偏底层的软件能力继续向数据可信、安全共享和行业安全运营延伸。
 
-第四类成果是跨向智能计算与新型应用场景的延展。较新的培养方向已经覆盖工业软件、网络安全、智能计算，团队介绍中也把深度学习、自然语言处理、移动 AR、嵌入式 AI 列为主要研究方向之一。罗蕾教授的研究由此延伸到智能化应用场景。
+第四类成果是跨向智能计算与新型应用场景的延展。较新的培养方向已经覆盖工业软件、网络安全、智能计算，团队介绍中也把深度学习、自然语言处理、移动 AR、嵌入式 AI 列为主要研究方向之一。罗蕾教授的研究由此延伸到智能化应用场景。这一方向也可以继续向小型化、低功耗、资源受限系统中的智能应用展开，把嵌入式基础软件、可调度性分析与低功耗部署问题连接起来。
 
 罗蕾教授的代表性工作始终围绕两个问题展开：一是如何把系统底层做稳，特别是实时性、可靠性、安全性和可配置性；二是如何让这些底层能力进入实际产业系统，服务汽车电子、物联网、支付和数据共享等复杂场景。这也是她作为知名专家学者，能够同时出现在学术导师页面、课程建设页面、科研团队页面和行业合作资料里的重要原因。
 

项目框架2-面向机器人大小脑异构系统的实时保障研究/00-项目总览/01-研究问题、定位与边界.md

@@ -0,0 +1,67 @@
+# 研究问题、定位与边界
+
+## 1. 工业背景
+
+机器人同时包含两类时间尺度显著不同的任务：
+
+- 感知、语言理解、任务规划和大模型推理计算量大、运行时间动态，通常属于软实时或固实时；
+- 姿态稳定、关节控制、力控、现场总线和安全联锁按固定周期运行，通常属于硬实时或严格固实时。
+
+把两类任务简单部署在同一 Linux 系统中，会产生调度、中断、内存带宽、DMA、功耗和故障传播问题；把完整 AI 软件栈迁入 RTOS，又会面临驱动、运行时、模型生态和不可控加速器执行路径问题。
+
+## 2. 研究对象
+
+本项目研究的是机器人大小脑异构系统，而不是单独研究 RTOS 或大模型：
+
+| 子系统 | 工程角色 | 主要软件 |
+|---|---|---|
+| 大脑域 | 环境理解、模型推理、任务规划、技能选择 | Linux、ROS 2、LLM/VLM/VLA、GPU/NPU 运行时 |
+| 技能与安全接口 | 命令结构化、白名单技能、期限和约束检查 | 跨域协议、安全监控器、行为管理器 |
+| 小脑域 | 状态估计、轨迹跟踪、关节控制、联锁和降级 | RTOS、控制算法、关键设备驱动 |
+| 隔离层 | CPU、内存、设备、中断和故障域分区 | Hypervisor、AMP、IOMMU 或静态硬件分区 |
+
+## 3. 核心研究问题
+
+> 在机器人大小脑异构平台中，如何建立跨域时间契约和资源隔离机制，使动态、不可完全预测的大脑负载不会破坏小脑控制的实时边界，并使大脑输出能够被安全、按期地使用？
+
+分解为五个问题：
+
+1. 大脑负载通过哪些 CPU、缓存、内存、I/O、中断、DMA 和热路径干扰小脑控制？
+2. 静态分核与 Hypervisor 分域能够隔离哪些干扰，仍有哪些共享硬件干扰无法消除？
+3. 大小脑之间应采用什么时间契约、消息语义和队列策略？
+4. 大脑输出迟到、过期、错误或低置信度时，小脑如何在规定时间内回退？
+5. 大脑域、加速器或通信通道故障时，机器人能否持续受控并完成隔离和恢复？
+
+## 4. 研究边界
+
+### 纳入范围
+
+- 机器人本体或近端边缘计算平台；
+- RTOS 小脑与 Linux 大脑并行运行；
+- 控制任务 deadline、AI 结果期限和新鲜度；
+- 跨域通信、共享资源干扰、故障隔离和安全降级；
+- 大模型、视觉或规划作为大脑压力负载。
+
+### 不作为主线
+
+- 大模型训练；
+- T1 多节点集群吞吐优化；
+- 证明大模型本身具备硬实时性；
+- 用平均推理时延替代机器人控制实时性；
+- 让自然语言输出直接控制电机力矩。
+
+## 5. 基本原则
+
+1. 小脑不依赖大脑即可维持基本稳定和安全状态。
+2. 大脑输出的是目标、技能或受约束轨迹，不直接绕过控制器驱动执行器。
+3. 小脑不得同步阻塞等待大脑推理完成。
+4. 所有大脑输出必须携带时间戳、序号、有效期、状态和必要的安全约束。
+5. Hypervisor 只是一种隔离手段，隔离效果必须通过压力和故障实验验证。
+
+## 6. 预期贡献
+
+- 一套面向大小脑系统的多时间尺度任务模型；
+- 一套有期限、有新鲜度、有回退语义的跨域通信契约；
+- 一套 RTOS/Linux/Hypervisor 资源和故障隔离机制；
+- 一套覆盖正常、过载、热稳态和故障状态的实验方法；
+- 大脑智能能力、控制实时性和资源代价之间的适用边界。

项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/00-整体研究框架.md

@@ -0,0 +1,90 @@
+# 整体研究框架
+
+## 1. 系统架构
+
+```text
+操作员/任务系统
+       │
+       ▼
+┌────────────────────────────────────────────┐
+│ Linux 大脑域                               │
+│ 感知、LLM/VLM/VLA、任务规划、技能选择      │
+│ GPU/NPU、ROS 2、模型运行时                 │
+└──────────────────┬─────────────────────────┘
+                   │ 有界异步命令
+                   │ 序号/时间戳/期限/有效期
+┌──────────────────▼─────────────────────────┐
+│ RTOS 小脑域                                │
+│ 安全校验、状态估计、轨迹跟踪、关节控制     │
+│ 现场总线、联锁、超时回退、安全状态         │
+└──────────────────┬─────────────────────────┘
+                   │ 周期控制量
+                   ▼
+              执行器与机器人本体
+
+     Hypervisor / AMP / IOMMU / 静态资源分区
+```
+
+传感数据按需求分别进入大小脑：高频本体反馈优先直达小脑，图像、语音和复杂环境信息主要进入大脑。关键安全传感器不得仅通过 Linux 域转发。
+
+## 2. 三层时间模型
+
+| 层次 | 典型任务 | 时间属性 | 主要指标 |
+|---|---|---|---|
+| L1 控制闭环 | 关节控制、姿态稳定、联锁 | 硬实时/严格固实时 | deadline、jitter、最大响应时间 |
+| L2 技能与决策窗口 | 轨迹片段、目标位姿、避障决策 | 固实时 | 按期率、新鲜度、回退率 |
+| L3 认知与交互 | 语言理解、长任务规划、解释 | 软实时 | TTFT、端到端延迟、任务成功率 |
+
+基本约束为：
+
+```text
+R_control <= D_control
+
+采用大脑结果时：
+R_brain <= D_brain AND age(result) <= A_max
+
+大脑不可用时：
+R_fallback <= D_fallback
+```
+
+## 3. 三条研究主线
+
+### 主线一：时间契约
+
+- 规定大脑输出的期限、有效期和更新频率；
+- 把大脑输出转换为结构化技能或轨迹约束；
+- 对迟到、乱序、重复和低置信度结果定义统一处理；
+- 保证小脑在没有新命令时仍能连续控制。
+
+### 主线二：资源与故障隔离
+
+- 为小脑保留 CPU 核、内存、定时器和关键 I/O；
+- 路由关键中断到 RTOS 域；
+- 限制 Linux 和加速器 DMA 范围；
+- 测量 LLC、DRAM、互联、功耗和热等残余共享干扰；
+- 验证一个域崩溃或重启时另一域的持续运行能力。
+
+### 主线三：联合评价
+
+不能只报告控制延迟，也不能只报告大模型速度。结论必须联合回答：
+
+- 小脑控制是否按时；
+- 大脑结果是否按期且有效；
+- 分域使用了多少静态资源；
+- 推理吞吐和能效付出了多少代价；
+- 故障与恢复期间机器人是否保持受控。
+
+## 4. 研究假设
+
+- H1：大脑负载会通过共享资源显著扩大控制尾延迟。
+- H2：RTOS/Linux 分域能够降低调度、中断和故障传播影响，但不能自动消除内存带宽与热耦合。
+- H3：有界异步时间契约能够避免小脑等待大脑，并降低过期决策进入执行路径的风险。
+- H4：准入、限流和故障降级可扩大“控制无违约且 AI 结果仍有用”的运行区域。
+
+## 5. 研究成果形态
+
+- 原型系统：RTOS 小脑域、Linux 大脑域与隔离层；
+- 跨域协议：请求、响应、心跳、超时和版本管理；
+- 实验工具：时间戳、压力发生、故障注入和物理链路测量；
+- 数据集：控制周期、大脑请求、功耗热状态和故障事件的对齐时间序列；
+- 论文结论：适用边界、收益来源和残余风险。

项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/01-大小脑时间契约与跨域通信.md

@@ -0,0 +1,80 @@
+# 大小脑时间契约与跨域通信
+
+## 1. 接口原则
+
+大小脑之间采用异步、有界、可超时和可丢弃的消息通道。小脑控制线程不得执行无限等待、动态扩容或不可控的大块数据复制。
+
+大脑输出应从开放文本收敛为受约束结构：
+
+```text
+任务目标 → 白名单技能 → 参数与约束 → 小脑验证 → 执行
+```
+
+## 2. 消息模型
+
+### 请求
+
+| 字段 | 含义 |
+|---|---|
+| `request_id` | 唯一序号 |
+| `sample_time` | 输入数据采样时刻 |
+| `deadline` | 最晚可用时刻 |
+| `task_class` | 感知、规划、诊断或交互类别 |
+| `priority` | 域内服务优先级提示 |
+| `payload_ref` | 受控共享缓冲区引用 |
+| `schema_version` | 接口版本 |
+
+### 响应
+
+| 字段 | 含义 |
+|---|---|
+| `request_id` | 请求匹配 |
+| `finish_time` | 推理完成时刻 |
+| `valid_until` | 结果失效时刻 |
+| `model_version` | 模型版本和审计信息 |
+| `confidence/status` | 结果质量与错误状态 |
+| `skill_id` | 白名单技能编号 |
+| `constraints` | 速度、力、空间和持续时间约束 |
+| `checksum` | 完整性校验 |
+
+## 3. 小脑消费条件
+
+```text
+accept(result) =
+    id_match
+    AND schema_valid
+    AND checksum_valid
+    AND finish_time <= deadline
+    AND now <= valid_until
+    AND confidence >= threshold
+    AND skill_is_whitelisted
+    AND constraints_passed
+```
+
+拒绝结果后，小脑执行保持、传统控制、减速、停车或其他预定义回退，不等待大脑重新计算。
+
+## 4. 通信实现候选
+
+| 方式 | 优点 | 风险 | 适用场景 |
+|---|---|---|---|
+| 共享内存环形队列 + 通知 | 低复制、可控队列 | 缓存一致性和内存访问权限 | 同 SoC 分域主方案 |
+| RPMsg/邮箱 | SoC 生态常见、域间明确 | 消息大小和驱动能力受限 | MCU + 应用核 |
+| 虚拟设备 | 与 Hypervisor 集成 | VM exit 和虚拟中断开销 | 虚拟机分区 |
+| 以太网/TSN | 物理隔离、易扩展 | 网络栈与同步误差 | 双机大小脑 |
+
+## 5. 队列策略
+
+- 队列必须有固定容量；
+- 状态类消息可采用“只保留最新值”；
+- 事务类技能命令不得静默覆盖；
+- 大脑过载时优先拒绝低价值请求；
+- 小脑记录丢弃、超时、覆盖和回退原因；
+- 域重启后通过 epoch 或会话号拒绝旧消息。
+
+## 6. 验证重点
+
+- IPC 单向、往返、P99.9 和观测最大时延；
+- 消息大小、频率和队列深度的影响；
+- 队列满、乱序、重复、损坏和版本不一致；
+- 大脑域重启后的旧消息隔离；
+- 通信线程是否影响控制核和关键中断。

项目框架2-面向机器人大小脑异构系统的实时保障研究/10-研究框架/02-Hypervisor隔离、故障与降级.md

@@ -0,0 +1,67 @@
+# Hypervisor 隔离、故障与降级
+
+## 1. 隔离对象
+
+| 资源 | 推荐归属 | 验证问题 |
+|---|---|---|
+| 控制 CPU 核 | RTOS 独占 | Linux 满载时是否发生调度干扰 |
+| 关键内存 | RTOS 静态分区 | Linux OOM、换页或内存压力是否影响控制 |
+| 电机/编码器/现场总线 | RTOS 直通 | 中断和 DMA 是否经过 Linux |
+| GPU/NPU/摄像头 | Linux 独占 | 设备复位是否影响 RTOS |
+| 共享内存 | 最小固定区域 | 越界、缓存一致性和拥塞 |
+| 网络/存储 | Linux 为主 | 高频 IRQ 是否污染控制核 |
+
+## 2. 残余共享干扰
+
+分核和虚拟化不能自动消除：
+
+- LLC 和缓存互联竞争；
+- DRAM 带宽及内存控制器竞争；
+- SoC 总线与 DMA 拥塞；
+- 芯片级功耗限制；
+- 温度升高与全局降频；
+- 固件、系统管理中断和共享时钟源影响。
+
+因此需要分别实施 CPU、缓存、内存、I/O 和热压力实验，不能用“已使用 Hypervisor”代替隔离证据。
+
+## 3. 故障模型
+
+- 大脑推理进程崩溃或永久阻塞；
+- Linux 域卡死、内核错误或重启；
+- GPU/NPU 驱动错误和设备复位；
+- 共享队列溢出、损坏或失联；
+- 大脑持续产生过期或不安全命令；
+- Linux 域 CPU、内存、网络和存储过载；
+- 热降频导致推理与控制执行时间漂移。
+
+## 4. 降级状态机
+
+```text
+智能增强运行
+    │ 单次超时/低置信度
+    ▼
+保持当前安全技能或传统控制
+    │ 连续超时/通信故障
+    ▼
+隔离并重启大脑域
+    │ 本体风险上升
+    ▼
+减速、停车或安全状态
+```
+
+每个状态必须规定进入条件、最大驻留时间、控制策略、可用传感器、允许执行器动作和恢复条件。
+
+## 5. 安全监控职责
+
+安全监控器位于 RTOS 小脑域或独立安全核，至少负责：
+
+- 大脑心跳与期限监控；
+- 命令白名单和参数范围检查；
+- 速度、力矩、工作空间和碰撞约束；
+- 过期结果拒绝；
+- 大脑域隔离与重启请求；
+- 本地停车和安全状态执行。
+
+## 6. 核心结论边界
+
+实验可以证明指定平台和压力范围内的隔离效果，但不能自动证明形式化的最坏情况边界。若要宣称硬实时或功能安全，还需要可信 WCET、可调度性分析、硬件干扰上界和相应安全生命周期证据。

项目框架2-面向机器人大小脑异构系统的实时保障研究/20-实验与规划/01-实验设计.md

@@ -0,0 +1,67 @@
+# 实验设计
+
+## 1. 对照组
+
+| 编号 | 系统配置 | 作用 |
+|---|---|---|
+| A0 | 普通 Linux：控制与大脑负载同域 | 通用基线 |
+| A1 | PREEMPT_RT Linux：控制与大脑负载同域 | 实时 Linux 基线 |
+| A2 | RTOS 小脑 + Linux 大脑，基础分区 | 分域基线 |
+| A3 | A2 + CPU/IRQ/内存/IPC 治理 | 完整方案 |
+| A4 | A3 + 超时、降级和故障恢复 | 安全协同方案 |
+
+对照固定机器人控制任务、AI 模型、输入到达序列、硬件频率和功率策略。若推理后端不同，结果表述为系统方案比较，不单独归因于内核。
+
+## 2. 负载场景
+
+| 场景 | 内容 | 目的 |
+|---|---|---|
+| L0 | 仅小脑控制 | 实时性下界 |
+| L1 | 仅大脑推理 | 推理容量与功耗基线 |
+| L2 | 控制 + 感知/大模型 | 核心共存场景 |
+| L3 | L2 + CPU/内存压力 | 共享资源干扰 |
+| L4 | L2 + 摄像头/网络/存储 I/O | IRQ 与 DMA 干扰 |
+| L5 | L2 + 突发请求和过载 | 队列与准入边界 |
+| L6 | L2 长时间运行至热稳态 | 功耗和降频耦合 |
+| L7 | 进程、域、加速器和通信故障 | 隔离、降级与恢复 |
+
+## 3. 控制任务
+
+至少包含：
+
+- 高频周期控制任务；
+- 状态估计或轨迹跟踪任务；
+- 关键 I/O 或 GPIO 回环；
+- 安全监控与回退任务。
+
+无真实机器人时，先使用硬件在环、倒立摆、电机台架或确定性控制负载；不得仅用空循环替代全部控制语义。
+
+## 4. 大脑任务
+
+按平台能力选择视觉、VLM、VLA 或 LLM。大脑输出必须转换为结构化技能命令。分别扫描：
+
+- 请求率和突发强度；
+- 模型规模、输入长度和输出长度；
+- batch、队列长度与并发；
+- GPU/NPU 利用率；
+- 感知数据大小和通信频率。
+
+## 5. 故障注入
+
+依次实施：推理进程退出、请求永久阻塞、消息乱序或损坏、队列溢出、Linux 域重启、加速器错误。设备级故障只在具备可恢复路径时开展。
+
+记录故障发生、检测、回退、隔离、重启和首个恢复结果的完整时间线。
+
+## 6. 实施顺序
+
+1. 冻结控制 deadline、大脑结果期限和回退期限。
+2. 完成 A0/A1 的同域基线。
+3. 建立 A2 基础分域和最小 IPC。
+4. 扫描 CPU、内存、I/O 和热干扰。
+5. 加入 A3 治理机制并逐项消融。
+6. 加入 A4 故障状态机并开展故障注入。
+7. 进行长稳实验和独立确认批次。
+
+## 7. 最小闭环
+
+一台具备 RTOS/Linux 分域条件的边缘平台、一个可测量的控制任务和一个真实 AI 大脑负载，即可形成最小验证闭环，不要求扩展到工作站或集群。

项目框架2-面向机器人大小脑异构系统的实时保障研究/20-实验与规划/02-指标与证据.md

@@ -0,0 +1,60 @@
+# 指标与证据
+
+## 1. 小脑控制实时性
+
+- 周期任务释放、开始和完成时间；
+- 响应时间与完成抖动；
+- P50/P95/P99/P99.9 和观测最大值；
+- deadline miss ratio，报告分子与分母；
+- 外部输入到执行器输出的物理链路时延；
+- 过载、热稳态和故障期间的控制表现。
+
+## 2. 大脑结果可用性
+
+- 大小脑端到端决策时延；
+- deadline-hit ratio；
+- 结果新鲜度合格率；
+- 超时、过期、乱序、损坏和拒绝率；
+- 模型任务质量与置信度；
+- 大脑不可用时的回退发生率。
+
+## 3. 跨域与隔离代价
+
+- IPC 单向/往返延迟及尾部；
+- 拷贝次数、CPU 开销和队列占用；
+- 静态保留的 CPU、内存和设备资源；
+- 分域前后的推理有效吞吐和能效；
+- Linux 满载相对小脑空载的控制延迟增量；
+- LLC、DRAM、I/O 和热压力的敏感度。
+
+## 4. 故障与恢复
+
+- 故障检测时间；
+- 回退完成时间；
+- 域隔离和重启时间；
+- 故障窗口内控制违约数；
+- 恢复后首个有效大脑结果时间；
+- 是否出现不可恢复故障或错误动作。
+
+## 5. 联合判定
+
+系统配置只有同时满足下列条件才算有效：
+
+```text
+控制任务满足期限
+AND 大脑结果达到规定的按期率与质量
+AND 超时结果不会进入执行路径
+AND 故障时在期限内完成回退
+AND 资源和能耗代价可接受
+```
+
+平均推理时延降低但控制违约增加，不构成系统实时性改善；控制零违约但所有 AI 请求都被拒绝，也不构成有效协同。
+
+## 6. 推荐核心图表
+
+1. 大脑负载强度—控制违约率—结果按期率可行域；
+2. 单域与分域方案的控制尾延迟对比；
+3. CPU、内存、I/O 和热干扰消融图；
+4. 跨域时序分解图；
+5. 大脑故障期间控制时间序列；
+6. 静态资源预留与推理有效吞吐 Pareto 曲线。

项目框架2-面向机器人大小脑异构系统的实时保障研究/README.md

@@ -0,0 +1,45 @@
+# 项目框架2：面向机器人大小脑异构系统的实时保障研究
+
+## 一句话定位
+
+本项目研究机器人“大脑—小脑”异构系统的系统级实时保障：Linux 大脑域承担感知、推理与规划，RTOS 小脑域承担运动控制和安全保护，Hypervisor 或等价分区机制负责资源与故障隔离。
+
+## 核心问题
+
+> 当大模型、视觉和规划负载具有动态执行时间且可能过载或故障时，如何保证机器人控制闭环持续满足截止期，并使大脑输出只在满足时限、新鲜度和安全约束时进入执行路径？
+
+## 与另外两套框架的区别
+
+| 框架 | 研究主语 | 核心场景 | 本框架中的地位 |
+|---|---|---|---|
+| 框架1 | 大型跨平台 RTOS | T5～T1 五类部署形态 | 机制与设备资料来源，不作为本框架的统一谱系 |
+| 框架2 | 机器人大小脑异构系统 | RTOS 控制域 + Linux 推理域 | 当前目录的主线 |
+| 框架3 | MCU/资源受限 SoC | 轻量 AI 与实时控制同节点共存 | 小脑侧 AI 的专题补充 |
+
+## 目录结构
+
+- `00-项目总览/01-研究问题、定位与边界.md`
+  - 研究对象、工业场景、核心假设和结论边界
+- `10-研究框架/00-整体研究框架.md`
+  - 大小脑架构、三层时间模型与研究主线
+- `10-研究框架/01-大小脑时间契约与跨域通信.md`
+  - 命令语义、结果新鲜度、有界 IPC 和时序约束
+- `10-研究框架/02-Hypervisor隔离、故障与降级.md`
+  - CPU、内存、中断、DMA、热干扰和故障恢复
+- `20-实验与规划/01-实验设计.md`
+  - 对照组、压力场景、故障注入和实施顺序
+- `20-实验与规划/02-指标与证据.md`
+  - 控制实时性、大脑结果可用性和系统代价指标
+
+## 推荐阅读顺序
+
+1. `00-项目总览/01-研究问题、定位与边界.md`
+2. `10-研究框架/00-整体研究框架.md`
+3. `10-研究框架/01-大小脑时间契约与跨域通信.md`
+4. `10-研究框架/02-Hypervisor隔离、故障与降级.md`
+5. `20-实验与规划/01-实验设计.md`
+6. `20-实验与规划/02-指标与证据.md`
+
+## 推荐课题名称
+
+> **面向机器人大小脑异构系统的分域实时保障与安全协同机制研究**

项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/00-项目总览/01-研究问题、定位与边界.md

@@ -0,0 +1,44 @@
+# 研究问题、定位与边界
+
+## 1. 问题背景
+
+MCU 和资源受限 SoC 原本承担周期控制、采集、通信和保护任务。引入 AI 后，模型执行会持续占用 CPU/NPU、内存、缓存、总线、DMA 和功耗预算，导致控制抖动、关键中断延迟、内存不足或热降频。
+
+该问题具有明确的工业实时属性：AI 可以降质、跳帧或暂停，但关键控制任务和安全保护不能因为 AI 负载而失去截止期。
+
+## 2. 核心研究问题
+
+1. 轻量 AI 通过哪些资源路径影响控制任务？
+2. 如何为 AI 分配可执行时间、内存、带宽和功耗预算？
+3. AI 负载超过容量时，如何限流、跳帧、切换模型或暂停执行？
+4. 模型精度、结果期限、控制实时性和能耗之间如何联合优化？
+5. 不同 MCU/SoC 上哪些机制可迁移，哪些依赖具体硬件？
+
+## 3. 研究范围
+
+### 纳入范围
+
+- MCU、带 NPU 的工业 SoC 和控制器；
+- AI 与控制任务同 OS 或同芯片共存；
+- 固定优先级、预算服务器、准入和过载降级；
+- 静态内存、DMA、缓存、总线、功耗和热管理；
+- GPIO、CAN、RS485、工业以太网等物理响应。
+
+### 不纳入主线
+
+- 大模型训练和多节点集群；
+- 为补齐 T1～T5 而采购全谱系设备；
+- 只测 tokens/s 或平均推理速度；
+- 在设备无法真实运行时估算模型性能；
+- 把零违约实测表述为理论硬实时证明。
+
+## 4. 基本假设
+
+- H1：AI 对控制的主要影响不仅来自 CPU，还来自内存、DMA、中断和热耦合。
+- H2：预算、预分配和准入可以扩大控制无违约的 AI 运行范围。
+- H3：过载时主动降低 AI 服务质量，比继续排队更有利于维持系统可预测性。
+- H4：满足相同控制和 AI 约束时，可以找到能耗更低的模型、频率与执行策略。
+
+## 5. 成果边界
+
+本研究证明的是指定设备、任务和环境下的容量边界与机制收益。不同芯片的 NPU 固件、内存控制器和功耗策略不同，不能仅按内存容量把结果直接外推。

项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/00-整体研究框架.md

@@ -0,0 +1,59 @@
+# 整体研究框架
+
+## 1. 系统模型
+
+```text
+┌─────────────────────────────────────────────┐
+│ 安全与关键控制任务                          │
+│ 周期控制、联锁、关键采集、现场总线          │
+├─────────────────────────────────────────────┤
+│ AI 目标任务                                  │
+│ 检测、估计、识别、诊断、轻量智能决策        │
+├─────────────────────────────────────────────┤
+│ 伴生任务                                     │
+│ 日志、通信、更新、存储和非关键后台服务       │
+├─────────────────────────────────────────────┤
+│ RTOS/嵌入式系统治理                          │
+│ 优先级、预算、准入、预分配、中断与降级       │
+├─────────────────────────────────────────────┤
+│ MCU/SoC：CPU、NPU、RAM、缓存、总线、DMA、热  │
+└─────────────────────────────────────────────┘
+```
+
+## 2. 优先级原则
+
+1. 安全与关键控制任务优先满足 deadline；
+2. AI 任务在剩余时间和资源预算内执行；
+3. AI 结果超过有效期后不再进入控制路径；
+4. 伴生任务不得挤占控制和已准入 AI 的预算；
+5. 过载时优先降低 AI 频率、模型复杂度或输入质量。
+
+## 3. 四维预算
+
+| 预算 | 控制手段 | 典型风险 |
+|---|---|---|
+| 时间预算 | 固定优先级、时间服务器、分块执行 | 长算子和不可抢占段 |
+| 内存预算 | 静态分配、内存池、峰值准入 | OOM、碎片、共享缓冲区 |
+| 带宽预算 | DMA 编排、访问节流、采样降频 | 控制数据被 AI 挤占 |
+| 功耗预算 | DVFS、模型切换、占空比控制 | 热降频反向破坏实时性 |
+
+## 4. 运行状态
+
+```text
+S0 控制优先、AI 正常运行
+S1 AI 降频或跳帧
+S2 切换轻量模型或低精度模式
+S3 暂停 AI，保留传统控制
+S4 故障安全状态
+```
+
+状态切换依据控制裕量、队列长度、内存水位、温度、功耗和 AI 结果质量。切换过程本身必须有界，并避免关键路径动态加载大型模型。
+
+## 5. 研究主线
+
+- AI WCET/执行时间分布与可抢占结构分析；
+- 控制任务响应时间和共享资源干扰分析；
+- AI 多维预算与准入控制；
+- 精度、执行频率和功耗联合降级；
+- 长时间热稳态和异常恢复；
+- 跨设备可迁移机制与芯片特定机制区分。

项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/01-AI预算调度与控制保护.md

@@ -0,0 +1,54 @@
+# AI 预算调度与控制保护
+
+## 1. 任务模型
+
+控制任务表示为：
+
+```text
+τc = (Tc, Dc, Cc, Pc)
+```
+
+其中 `T` 为周期、`D` 为截止期、`C` 为执行需求、`P` 为优先级。
+
+AI 任务表示为：
+
+```text
+τai = (arrival, deadline, budget_cpu, budget_mem,
+       budget_power, quality_level, droppable)
+```
+
+AI 任务必须声明是否可丢弃、是否允许跳帧以及可接受的最低质量等级。
+
+## 2. 调度原则
+
+- 控制任务使用固定优先级或已验证的实时调度策略；
+- AI 使用低优先级后台、预算服务器或可中止任务；
+- 将长推理拆分为可抢占或可中断阶段；
+- 不可抢占 NPU/GPU 执行段必须测量并纳入控制响应时间；
+- AI 请求只有在时间、内存和功耗预算同时满足时才准入。
+
+## 3. 准入条件
+
+```text
+schedulable(control | ai_load)
+AND peak_memory <= M_budget
+AND predicted_power <= P_budget
+AND result_deadline_feasible
+AND quality >= Q_min
+```
+
+准入失败时，系统可以拒绝请求、推迟非关键输入、跳帧或选择更小模型，不能无限排队。
+
+## 4. 控制保护机制
+
+- 控制代码、数据和栈静态分配；
+- AI 与控制使用独立内存池；
+- 关键中断优先于 NPU、摄像头和通信完成中断；
+- 日志采用预分配缓冲并异步输出；
+- AI 执行前检查控制裕量；
+- AI 超时后结果直接失效；
+- 看门狗覆盖 AI 运行时和设备驱动卡死。
+
+## 5. 消融验证
+
+逐项移除预算服务器、内存池、中断隔离、准入和降级机制，比较控制尾延迟、AI 按期率和能耗，识别收益来源。

项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/10-研究框架/02-内存、功耗、热与降级.md

@@ -0,0 +1,55 @@
+# 内存、功耗、热与降级
+
+## 1. 内存治理
+
+模型准入按完整峰值计算：
+
+```text
+M_total = M_weight + M_activation + M_workspace
+        + M_io + M_runtime + M_control_reserved
+```
+
+必须为控制任务、关键通信和故障日志保留不可侵占空间。权重大小不能代替峰值内存测量。
+
+推荐机制：
+
+- 模型和工作区静态加载；
+- 固定大小内存池；
+- 禁止关键窗口模型切换；
+- DMA 缓冲区白名单和容量上限；
+- OOM 前主动降低 AI 并发或切换模型。
+
+## 2. 功耗与热耦合
+
+AI 满载可能触发整芯片功耗限制或热降频，进而增加控制任务执行时间。实验必须同步记录：
+
+- 整机功率；
+- 芯片温度；
+- CPU/NPU 实际频率；
+- AI 执行阶段；
+- 控制响应时间和违约；
+- 降频事件。
+
+## 3. 降级策略
+
+| 触发条件 | 优先动作 |
+|---|---|
+| 控制裕量下降 | 降低 AI 请求率或跳帧 |
+| AI 队列增长 | 拒绝低优先级请求 |
+| 内存水位过高 | 减少并发或切换小模型 |
+| 温度接近阈值 | 降低 AI 占空比或精度 |
+| 连续 AI 超时 | 暂停 AI，保留传统控制 |
+| 驱动或设备故障 | 复位 AI 子系统并进入安全模式 |
+
+## 4. 能效口径
+
+不能仅比较最低功率，应在相同控制实时约束和 AI 质量约束下比较：
+
+- 单次有效推理能耗；
+- 有效结果/焦耳；
+- 控制无违约条件下的持续 AI 吞吐；
+- 热稳态而非冷机短时能效。
+
+## 5. 结论边界
+
+动态量化、模型切换和 DVFS 只有在切换开销已测量且不破坏控制 deadline 时，才能称为实时感知的低功耗策略。

项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/20-实验与规划/01-实验设计.md

@@ -0,0 +1,64 @@
+# 实验设计
+
+## 1. 平台选择
+
+建议最少包含：
+
+- 一个 MCU 或低资源控制器，用于 TinyML/轻量 AI 与周期控制共存；
+- 一个带 NPU 的资源受限 SoC，用于统一内存、DMA 和热干扰；
+- 必要的功率计、逻辑分析仪或示波器以及 CAN/RS485 对端。
+
+设备按真实 AI 运行能力选择，不以补齐 T1～T5 为目标。
+
+## 2. 对照组
+
+| 编号 | 配置 |
+|---|---|
+| C0 | 仅控制任务 |
+| C1 | 控制 + AI 默认配置 |
+| C2 | C1 + 优先级和中断隔离 |
+| C3 | C2 + 时间/内存/功耗预算与准入 |
+| C4 | C3 + 模型降级和故障恢复 |
+
+## 3. 压力场景
+
+| 场景 | 内容 |
+|---|---|
+| M0 | 控制空载基线 |
+| M1 | AI 独立运行 |
+| M2 | 控制 + AI |
+| M3 | M2 + CPU/缓存压力 |
+| M4 | M2 + 内存/DMA 压力 |
+| M5 | M2 + I/O/中断压力 |
+| M6 | AI 突发和过载 |
+| M7 | 热稳态和降频 |
+| M8 | OOM、超时、运行时或设备故障 |
+
+## 4. 变量扫描
+
+- 控制周期、执行预算和关键 I/O 频率；
+- AI 模型、精度、输入尺寸和执行频率；
+- CPU/NPU 频率与功率模式；
+- 内存预算和 DMA 缓冲区大小；
+- AI 队列深度、跳帧率和超时期限；
+- 环境温度和持续运行时间。
+
+## 5. 实施顺序
+
+1. 验证控制任务和物理计时链路。
+2. 完成模型正确性、峰值内存和独立能耗准入。
+3. 运行 C0/C1，确认 AI 实际产生的干扰。
+4. 依次加入 C2～C4 并做逐项消融。
+5. 扫描负载直到出现控制违约或 AI 服务失效。
+6. 在选定边界附近进行热稳态与长时间实验。
+7. 使用冻结配置进行独立确认批次。
+
+## 6. 停止条件
+
+- 控制任务出现不可接受违约；
+- 温度、电压或电流超过设备安全范围；
+- 测量链路丢样或时钟失效；
+- 内存不足导致无法保持关键任务；
+- AI 后端不支持目标模型或精度。
+
+停止不代表实验失败，应记录为容量或适配边界。

项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/20-实验与规划/02-指标与证据.md

@@ -0,0 +1,58 @@
+# 指标与证据
+
+## 1. 控制实时性
+
+- 任务响应时间、完成抖动和观测最大值；
+- deadline miss ratio；
+- 中断响应和关键 I/O 端到端时延；
+- AI 启停、模型切换和降频瞬间的时间序列；
+- 故障与恢复窗口内的控制表现。
+
+## 2. AI 服务有效性
+
+- 推理端到端时延和按期率；
+- 有效结果率、任务质量和超时率；
+- 跳帧、拒绝和降级比例；
+- 模型切换时间；
+- 控制无违约条件下的最大持续 AI 负载。
+
+## 3. 资源与能耗
+
+- 峰值和稳态内存；
+- CPU/NPU 利用率与执行占空比；
+- 内存带宽或可取得的代理指标；
+- 整机平均功率、峰值功率和能量；
+- 温度、实际频率和降频时间比例；
+- 单次有效结果能耗和有效结果/焦耳。
+
+## 4. 核心结果表达
+
+推荐把结果组织为“安全运行区”：
+
+```text
+控制 deadline 满足
+AND AI 质量 >= Q_min
+AND AI 按期率 >= H_min
+AND 功耗 <= P_max
+AND 温度 <= Temp_max
+```
+
+扫描 AI 频率、模型复杂度和功耗模式，绘制满足全部条件的可行区域及其边界。
+
+## 5. 不应使用的证据替代
+
+- 平均延迟不能替代 deadline miss ratio；
+- 短时冷机性能不能替代热稳态；
+- 模型权重大小不能替代峰值内存；
+- 芯片标称 TOPS 不能替代实测完成时间；
+- 零违约不能直接表述为理论硬实时保证；
+- 降低 AI 完成率获得的低功耗不能单独称为能效提升。
+
+## 6. 推荐图表
+
+1. AI 负载—控制尾延迟与违约率曲线；
+2. 时间、内存、功耗预算消融图；
+3. 模型质量—按期率—能耗 Pareto 图；
+4. 热稳态下温度、频率、控制延迟时间序列；
+5. 过载状态下跳帧、降级和恢复过程；
+6. 不同 MCU/SoC 的机制可迁移性对比表。

项目框架3-MCU与资源受限SoC的AI实时性与低功耗研究/README.md

@@ -0,0 +1,32 @@
+# 项目框架3：MCU 与资源受限 SoC 的 AI 实时性与低功耗研究
+
+## 一句话定位
+
+本项目研究 MCU 和资源受限 SoC 引入轻量 AI 后的实时干扰、资源预算、低功耗运行与安全降级问题，形成“控制期限优先、AI 预算执行、过载主动降级”的端侧智能方法。
+
+## 核心问题
+
+> 在 CPU、内存、带宽、功耗和散热均受限的控制节点中，允许多大的 AI 负载，才能在不破坏周期控制和关键 I/O 截止期的前提下获得有效智能功能？
+
+## 研究对象说明
+
+这里的 AI 不默认等于大语言模型。根据硬件能力，可以是：
+
+- TinyML 和小型神经网络；
+- 异常检测与预测维护模型；
+- 轻量视觉、语音和状态识别；
+- 学习型状态估计或控制补偿；
+- 能在目标设备真实运行的小型语言模型。
+
+## 目录结构
+
+- `00-项目总览/01-研究问题、定位与边界.md`
+- `10-研究框架/00-整体研究框架.md`
+- `10-研究框架/01-AI预算调度与控制保护.md`
+- `10-研究框架/02-内存、功耗、热与降级.md`
+- `20-实验与规划/01-实验设计.md`
+- `20-实验与规划/02-指标与证据.md`
+
+## 推荐课题名称
+
+> **资源受限嵌入式控制系统中 AI 负载的实时预算与低功耗协同机制研究**