diff --git a/00-项目总览/01-当前研究问题：背景、问题与挑战.md b/00-项目总览/01-当前研究问题：背景、问题与挑战.md
new file mode 100644
index 0000000..7b2b473
--- /dev/null
+++ b/00-项目总览/01-当前研究问题：背景、问题与挑战.md
@@ -0,0 +1,75 @@
+# 01-当前研究问题：背景、问题与挑战
+
+## 1. 背景
+
+当前智能系统正在持续进入控制、装备、交通、工业现场与边缘决策等任务关键场景。随着人工智能推理能力从离线分析走向在线决策，系统对人工智能运行的要求已经扩展为功能有效性、时间约束、运行稳定性与可验证性的统一达标。
+
+外部研究与产业表达已经形成较清晰的共识：
+
+- AI 用于 safety-critical systems 的安全保障仍在持续推进，系统层面的可控、可验证与可接受性仍是核心议题；
+- QNX、Wind River 等平台方已将 deterministic、predictable、secure 的软件基础与 AI 能力并列讨论；
+- Linux Foundation 对 PREEMPT_RT 的持续推进，表明低延时、低抖动和可预测执行已经成为重要基础能力。
+
+在这样的背景下，操作系统已经成为决定 AI 推理能否进入任务关键系统的重要基础平台。尤其当 AI 推理与周期控制、执行闭环、联锁逻辑、通信管理等负载共同运行时，系统时序边界、资源争抢边界与恢复边界都会被重新放大。
+
+## 2. 问题
+
+本项目聚焦的当前研究问题可以表述为：
+
+> **在五类部署形态下，当人工智能目标负载进入任务关键系统后，以大型跨平台实时操作系统为基础平台的系统，是否相较普通 Linux 与 PREEMPT_RT Linux，能够提供更强的确定性、可预测性与实时保障能力，并同时保持人工智能目标负载的功能有效性与时效性？**
+
+这个问题包含四个明确支点：
+
+1. 研究对象是**大型跨平台实时操作系统**这一类平台；
+2. `SylixOS` 是主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等构成外部参照样本；
+3. AI 推理在任务关键系统中被界定为**人工智能目标负载**，与关键保障负载、伴生竞争负载共同构成系统运行面；
+4. 对照对象明确拆分为**普通 Linux** 与 **PREEMPT_RT Linux**，用来建立不同系统基础能力之间的可比关系。
+
+项目围绕以下三个判断维度展开：
+
+- AI 目标负载与关键保障负载能否在统一系统中稳定共存；
+- 操作系统能否通过调度、隔离、内存管理、中断管理与恢复机制维持系统边界；
+- 系统是否能够同时实现 AI 功能有效性与实时性达标。
+
+因此，这个研究问题本质上是一个面向任务关键系统的系统研究问题，也是一个具有产业验证价值的平台比较问题。
+
+## 3. 挑战
+
+围绕上述问题，当前研究至少面临以下几类核心挑战。
+
+### 3.1 五类部署形态下的统一验证挑战
+
+`T5~T1` 五类部署形态与 `11` 个代表档位共同构成验证矩阵、证据组织框架与跨场景比较环境。这里的核心挑战，是在不同资源约束、拓扑结构和负载强度下，用统一方法解释 RTOS 的优势边界与失效边界。
+
+### 3.2 对照体系的精细化挑战
+
+本项目采用三级对照体系：
+
+- `O0` 普通 Linux；
+- `O1` PREEMPT_RT Linux；
+- 大型跨平台 RTOS。
+
+这一对照设计将普通 Linux 与 PREEMPT_RT Linux 分别建模，用于区分一般低延时收益与 RTOS 在确定性、隔离性和可分析性上的收益来源。
+
+### 3.3 双目标同时达标的评价挑战
+
+当 AI 被界定为目标负载后，评价体系同时覆盖关键保障负载保护效果，以及 AI 目标负载的有效性、时效性和长期稳定性。因此，评价指标需要同时覆盖：
+
+- 关键保障负载：`deadline miss ratio`、`P99/P99.9 jitter`、响应时间边界；
+- AI 目标负载：`TTFT`、`TPOT`、端到端响应时间、成功率、功能质量；
+- 系统协同层：有效吞吐、`E/token`、热漂移、资源争抢边界、恢复能力。
+
+### 3.4 多目标负载协调的机制挑战
+
+在任务关键系统中，AI 目标负载、关键保障负载与伴生竞争负载共同构成统一运行面。它们在 CPU、内存、总线、中断、DMA、缓存与加速器访问上会形成持续竞争。研究的关键难点在于，RTOS 是否能够把这种竞争收敛为可分析、可控制、可恢复的系统行为边界。
+
+## 外部参考
+
+1. Linux Foundation, Real-Time Linux Project
+
+2. QNX, Software Foundation for Physical AI
+
+3. Wind River 官网与 Edge AI / mission-critical 相关公开表述
+
+4. Ullrich et al., *AI Safety Assurance for Automated Vehicles: A Survey on Research, Standardization, Regulation*
+
diff --git a/00-项目总览/02-研究定位与项目边界.md b/00-项目总览/02-研究定位与项目边界.md
new file mode 100644
index 0000000..6196006
--- /dev/null
+++ b/00-项目总览/02-研究定位与项目边界.md
@@ -0,0 +1,143 @@
+# 02-研究定位与项目边界
+
+## 一句话定义
+
+本项目的正式题目是：
+
+> **大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**
+
+本项目围绕下面这个核心问题展开：
+
+> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台，是否相较普通 Linux 与 PREEMPT_RT Linux，能够提供更强的确定性、可预测性与实时保障能力，并同时保持人工智能目标负载的功能有效性与时效性。SylixOS 是本项目的主实验样例，QNX、VxWorks、INTEGRITY、LynxOS-178 等可作为外部参照样本。**
+
+## 这个项目在做什么
+
+### 1. 研究对象与平台角色
+
+本项目的研究对象是**大型跨平台实时操作系统这一类平台**，重点关注它们在任务关键系统中的：
+
+- 其实时调度、资源隔离、内存管理、中断管理与恢复机制；
+- 这些机制在不同部署形态下承载人工智能目标负载时，是否仍能维持系统边界。
+
+在这组平台中：
+
+- `SylixOS` 是本项目的主实验样例；
+- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等用于建立外部参照坐标；
+- `Linux` 与 `PREEMPT_RT Linux` 是核心对照对象。
+
+硬件平台在本项目中承担的是**验证载体**角色，用来暴露不同资源约束、拓扑结构和调度边界。
+
+### 2. 系统场景与负载结构
+
+本项目面向的是**任务关键系统**。在这个系统语境里，人工智能推理属于系统功能的一部分，因此被定义为：
+
+- **人工智能目标负载**
+
+与之共同构成系统运行面的还有两类负载：
+
+- **关键保障负载**：周期控制、执行闭环、联锁、状态采集等；
+- **伴生竞争负载**：日志、更新、后台通信、模型加载、存储和网络 I/O 等。
+
+> **RTOS 如何协调人工智能目标负载与关键保障负载，使系统同时满足功能有效性与实时性边界。**
+
+### 3. 在五类部署形态下建立统一验证矩阵
+
+`T5~T1` 五类部署形态和 `11` 个代表档位在本项目中构成验证矩阵与证据组织框架：
+
+- 验证矩阵；
+- 证据组织框架；
+- 不同资源条件下的边界测试环境。
+
+这套验证矩阵覆盖：
+
+- `T5` 控制端
+- `T4` 设备端 SoC
+- `T3` 边缘节点
+- `T2` 桌面 / 工作站单机
+- `T1` 服务器 / 集群
+
+这套验证矩阵支撑以下四类判断：
+
+- RTOS 优势在哪些部署形态下最明显；
+- 这些优势来自哪些系统机制；
+- 为维持实时保障需要付出多少吞吐和能耗代价；
+- 从什么资源规模开始，RTOS 相对非实时平台的优势开始收窄。
+
+### 4. 建立“AI 目标负载 + 关键保障负载”双目标证据链
+
+项目以可复现、可解释的证据链为核心输出，目标是形成能被论文、产品和产业沟通共同接受的系统性结论。
+
+证据至少包括三层：
+
+- **人工智能目标负载层**：
+ `TTFT`、`TPOT`、端到端响应时间、成功率、任务质量、长时间稳定性；
+- **关键保障负载层**：
+ `deadline miss ratio`、`P99/P99.9 jitter`、观测最大响应时间、外部接口响应；
+- **系统协同层**：
+ 有效吞吐、`E/token`、温度漂移、资源争抢边界、恢复能力与长期稳定性。
+
+## 项目边界
+
+### 1. 应用背景与研究对象
+
+项目的应用背景覆盖控制端、设备端、边缘节点、工作站和集群等多种部署形态，但研究对象始终保持一致：
+
+- 大型跨平台实时操作系统；
+- 任务关键系统；
+- 人工智能目标负载。
+
+### 2. 评价重点
+
+项目评价围绕“双目标达标 + 系统协同稳定”展开，重点包括：
+
+- AI 目标负载是否按时完成；
+- 关键保障负载是否满足截止期；
+- 系统是否在长时间运行中保持稳定；
+- 满足这些约束后，吞吐与能耗代价是否可接受。
+
+### 3. 算法与系统的关系
+
+量化、KV Cache、流水线、投机解码这些内容在本项目里主要服务于系统层研究：
+
+- 它们如何改变时延分布；
+- 如何影响内存占用和带宽争抢；
+- 如何改变调度器和资源管理策略。
+
+因此，项目重点落在系统机制、调度策略和资源治理能力上。
+
+### 4. 成果形态
+
+项目成果需要形成完整的方法与证据体系，包括：
+
+- 可解释的方法；
+- 可复现的证据；
+- 明确的适用边界；
+- 跨部署形态可比较的规律；
+- 能被学术界和产业界共同理解的结论。
+
+## 这个项目最后要交付什么
+
+项目最终交付物至少应包括：
+
+1. 一套面向任务关键系统的 SylixOS 实时保障机制；
+2. 一组覆盖 `T5~T1` 五类部署形态的实测数据和对照结果；
+3. 一套同时覆盖 AI 目标负载与关键保障负载的实验方法学；
+4. 一篇能够清楚表达机制、证据、边界和规律的系统化论文或正式报告；
+5. 一套可用于产业沟通和产品表达的技术叙事。
+
+## 判断项目是否成功，要看什么
+
+要看：
+
+- SylixOS 是否在公平对照下改善了关键保障负载的尾延迟与违约率；
+- SylixOS 是否同时保持了人工智能目标负载的时效性和功能有效性；
+- 吞吐损失是否在可接受范围；
+- 能耗和热稳定性是否同步改善或至少可解释；
+- 结论是否能跨部署形态成立；
+- 优势边界和失败边界是否都被讲清楚。
+
+## 最后一句话
+
+这个项目的本质是：
+
+> **用人工智能目标负载进入任务关键系统后的资源冲突与时序压力，去验证大型跨平台实时操作系统是否仍然能够维持系统应有的确定性、可预测性与实时保障边界。**
diff --git a/10-研究框架/00-整体研究框架.md b/10-研究框架/00-整体研究框架.md
new file mode 100644
index 0000000..653dadb
--- /dev/null
+++ b/10-研究框架/00-整体研究框架.md
@@ -0,0 +1,249 @@
+# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的整体研究框架
+
+## 0. 核心问题
+
+本项目围绕大型跨平台实时操作系统支撑任务关键系统中的人工智能目标负载展开，核心判断是：
+
+> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台在确定性、可预测性与实时保障上的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。`SylixOS` 是本项目的主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本。**
+
+这里有三个基础判断：
+
+1. **研究对象是实时操作系统平台**；
+2. **人工智能推理在系统中承担目标负载角色**；
+3. **硬件条件以验证矩阵形式组织研究证据**。
+
+本研究评估的是：RTOS 在智能负载进入任务关键系统后，对系统秩序、时序边界与资源边界的维持能力。
+
+---
+
+## 1. 问题空间：五类部署形态、五种算力基础与三类系统负载
+
+### 1.1 五类部署形态
+
+`T5~T1` 五类部署形态构成验证环境与证据组织框架。
+
+| 部署形态 | 系统角色 | 典型环境 | 主要验证重点 |
+|---|---|---|---|
+| T5 控制端 | 极紧资源预算下的任务关键控制节点 | MCU、控制器、轻量控制盒 | 强实时、低功耗、极小内存预算 |
+| T4 设备端 SoC | 设备本体内的统一内存异构平台 | 工业 SoC、车规 SoC、端侧 AI 模组 | CPU/NPU/GPU 共享资源与带宽隔离 |
+| T3 边缘节点 | 设备附近的就地计算节点 | 边缘盒子、边缘工控机、Jetson/IGX 节点 | 近源推理、多任务并发、热与供电约束 |
+| T2 桌面 / 工作站单机 | 单机高密度本地推理与研发验证平台 | RTX 工作站、多 GPU 单机、实验室服务器 | 单机多卡调度、互联拓扑与公平性 |
+| T1 服务器 / 集群 | 多节点大模型服务与分布式协同平台 | x86/ARM 服务器、多 GPU、多节点集群 | 跨节点通信、分布式调度与规模扩展 |
+
+这五类部署形态首先依据**部署位置与系统角色**划分，其次才是容量和功耗。
+
+### 1.2 五种算力基础
+
+| 算力基础 | 资源形态 | 代表平台 | 对 RTOS 的主要挑战 |
+|---|---|---|---|
+| 控制型算力基础 | 极小内存、低主频、弱加速或无加速 | STM32H7、ESP32-S3、RK3568 控制盒 | 资源极紧、预算刚性、模型必须极小 |
+| 设备端 SoC 型算力基础 | CPU + NPU/GPU + 统一内存一体化 | RK3588、i.MX93、车规 SoC | 统一内存争抢、驱动封闭、加速器与 CPU 协调 |
+| 边缘节点型算力基础 | 较大 DDR/显存 + 专用加速器 + 近源部署 | Jetson AGX Orin、IGX、边缘工控机 | 多任务并发、热稳定性、I/O 与 DMA 压力 |
+| 工作站单机型算力基础 | 多 GPU/加速卡 + 单机大内存 | 4×V100、RTX 工作站、4×H100 单机 | 多卡拓扑、显存分片、单机高密部署 |
+| 服务器/集群型算力基础 | 多节点 CPU + 多 GPU/NPU + 高速互联 | V100/H100 集群、ARM/x86 集群 | NUMA、跨卡通信、分布式协同调度 |
+
+### 1.3 三类系统负载
+
+后续所有设计和评估都以三类负载为基本单元。
+
+| 负载类型 | 定义 | 典型例子 | 主要评价点 |
+|---|---|---|---|
+| 人工智能目标负载 | 系统需要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 | 时效性、功能有效性、长时间稳定性 |
+| 关键保障负载 | 维持系统安全与执行闭环的关键任务 | 1 ms 周期控制、状态采集、联锁、执行控制 | 截止期、抖动、观测最大响应时间 |
+| 伴生竞争负载 | 不属于核心功能但会争抢资源的任务 | 日志、更新、后台通信、模型加载、I/O | 干扰强度、资源占用、可隔离性 |
+
+本研究重点评估：
+
+> **在人工智能目标负载与关键保障负载并存时，RTOS 对双目标达标能力的支撑效果与成立条件。**
+
+---
+
+## 2. 统一技术体系：五层技术栈 + 一条横向治理线
+
+无论部署形态如何变化，系统描述都统一采用同一套技术栈。
+
+```
+┌───────────────────────────────────────────────────────────────┐
+│ L5 模型与任务语义层 │
+│ AI 模型、量化、KV Cache 组织、输出质量与服务约束 │
+├───────────────────────────────────────────────────────────────┤
+│ L4 运行时与负载编排层 │
+│ 任务图、队列、准入控制、内存池、流水线、隔离策略 │
+├───────────────────────────────────────────────────────────────┤
+│ L3 资源抽象与设备协同层 │
+│ CPU/NPU/GPU/DMA/PCIe/RDMA 抽象、带宽管理、设备状态暴露 │
+├───────────────────────────────────────────────────────────────┤
+│ L2 实时操作系统核心层 │
+│ 调度器、中断管理、同步机制、时钟、内存、隔离与恢复机制 │
+├───────────────────────────────────────────────────────────────┤
+│ L1 硬件与互联层 │
+│ SoC、加速器、统一内存、显存、缓存、总线、NVLink、网络互联 │
+└───────────────────────────────────────────────────────────────┘
+```
+
+**横向治理线**：安全、权限、配置版本、日志证据、时间同步、可观测性、OTA/回滚和审计能力贯穿五层，但不与任何单层并列。
+
+### 2.1 这套技术栈的意义
+
+这套表达用于把三个维度彻底拆开：
+
+- `T5~T1` 回答**在哪里验证**；
+- 五种算力基础回答**基于什么资源形态验证**；
+- 五层技术栈回答**系统内部怎么组织与保障**。
+
+这样就不会把“控制端 / 边缘节点 / 工作站 / 集群”误写成技术层，也不会把“MCU / SoC / GPU / 集群”误写成研究对象本身。
+
+### 2.2 人工智能目标负载到 RTOS 任务的映射
+
+```
+人工智能目标负载阶段 RTOS 侧任务/事件
+──────────────── ──────────────────
+输入处理 / Tokenization → 低优先级辅助任务
+Embedding / Prefill → 计算密集任务
+Attention / KV Cache → 延迟敏感任务
+FFN / 设备计算 → 可流水化计算任务
+采样 / 输出决策 → 中优先级服务任务
+结果封装 / 输出通路 → 接口与通信任务
+```
+
+关键点在于：
+
+- 哪些阶段必须优先保障；
+- 哪些阶段可以延迟或限流；
+- 哪些资源需要隔离；
+- 哪些竞争会直接破坏关键保障负载。
+
+---
+
+## 3. 研究主线：实时保障机制
+
+项目后续所有子方向都服务于同一个主命题：
+
+> **大型跨平台实时操作系统如何在人工智能目标负载进入任务关键系统后，维持系统的确定性、可预测性与实时保障边界。**
+
+围绕这个主命题，系统机制可以分为六个方向：
+
+1. **推理图任务调度**
+2. **KV Cache 与内存管理**
+3. **加速器协同调度**
+4. **量化与精度感知调度**
+5. **中断与实时性保障**
+6. **能耗与热管理**
+
+这六个方向共同服务于一个判断：
+
+> **RTOS 能否在多类目标负载并存时，让系统继续有边界。**
+
+### 3.1 研究方法总述
+
+为了回答这个问题，研究方法采用一条统一证据链：
+
+1. **准入**：先完成设备、测量、加速器、模型与混合负载的 `G0~G4` 准入；
+2. **对照**：在同硬件、同负载、同预算下组织 `O0/O1/O2/O3` 公平对照；
+3. **建模**：把系统统一拆成人工智能目标负载、关键保障负载与伴生竞争负载三类负载；
+4. **机制**：围绕调度、隔离、内存、中断、能耗等机制进行实现与配置；
+5. **实测**：用双目标达标、长稳、恢复与消融实验验证机制有效性、稳定性与适用边界；
+6. **跨档位分析**：再把结论放回 `T5~T1` 五类部署形态中观察规律、边界与收窄区间。
+
+因此，本研究最终给出的是一套可复现、可比较、可解释的系统级证据链。
+
+---
+
+## 4. 评价框架：双目标达标 + 系统协同稳定
+
+### 4.1 人工智能目标负载指标
+
+| 指标 | 含义 |
+|---|---|
+| `TTFT` | 首 token/首结果响应时间 |
+| `TPOT` | 连续输出阶段的平均时延 |
+| 端到端响应时间 | 从请求进入到结果可用的总时长 |
+| 功能有效性 | 精度、成功率、任务完成率、结果可用性 |
+| 长时间稳定性 | 长稳运行中的退化、漂移和失败情况 |
+
+### 4.2 关键保障负载指标
+
+| 指标 | 含义 |
+|---|---|
+| `deadline miss ratio` | 截止期违约比例 |
+| `P99/P99.9 jitter` | 高频尾部抖动 |
+| 观测最大响应时间 | 运行窗口内最大响应值 |
+| 外部接口响应 | GPIO、CAN、RS485、网络回路的端到端响应 |
+
+### 4.3 系统协同指标
+
+| 指标 | 含义 |
+|---|---|
+| 有效吞吐 | 满足时效与质量约束后的真实吞吐 |
+| `E/token` / `tokens/J` | 满足约束前提下的能效 |
+| 温度与热漂移 | 热稳定性及降频影响 |
+| 恢复能力 | 过载、重启、故障后的恢复时间 |
+| 公平性与隔离效果 | 多模型、多任务并发下的资源分配行为 |
+
+因此，本研究的成功标准是：
+
+> **人工智能目标负载、关键保障负载与系统协同三层指标同时达标。**
+
+---
+
+## 5. 对照关系：普通 Linux、PREEMPT_RT 与 RTOS
+
+后续所有实验和论文叙事都以三层 OS 对照为主线：
+
+| 对照组 | 含义 | 作用 |
+|---|---|---|
+| `O0` 普通 Linux | 通用系统基线 | 观察非实时平台的自然行为 |
+| `O1` PREEMPT_RT Linux | 实时增强型通用 OS | 作为最关键的系统对照 |
+| `O2/O3` SylixOS | 大型跨平台 RTOS 默认与优化配置 | 主实验样例 |
+
+这条对照线用于区分两类系统收益来源：
+
+- RTOS 相对普通 Linux 的差异，对应实时性基础带来的系统收益；
+- RTOS 相对 PREEMPT_RT 的差异，对应专用 RTOS 机制带来的系统收益。
+
+---
+
+## 6. 与已有工作的关系
+
+| 已有工作 | 其关注点 | 与本研究的差异 |
+|---|---|---|
+| vLLM / TGI / TensorRT-LLM | 高吞吐推理服务 | 主要关心服务效率，不以任务关键系统为中心 |
+| 微型模型 / TinyML / 模型压缩 | 压缩模型规模 | 关注模型适配，不解决系统级实时保障 |
+| 厂商 SDK 调度 | 封闭设备路径 | 缺乏跨平台可分析的 OS 机制比较 |
+| PREEMPT_RT 相关工作 | 提高 Linux 可预测性 | 很少同时纳入 AI 目标负载与关键保障负载双目标 |
+
+本研究的独特性体现在：
+
+1. 把**人工智能目标负载**引入任务关键系统研究；
+2. 把**大型跨平台实时操作系统**作为研究主角；
+3. 用 `T5~T1` 五类部署形态与 `11` 个代表档位建立完整验证矩阵；
+4. 同时比较 **普通 Linux / PREEMPT_RT / RTOS**；
+5. 用双目标达标和系统协同稳定构成证据链。
+
+---
+
+## 7. 文档结构索引
+
+| 文档 | 内容 |
+|-----|------|
+| [01-推理图任务调度.md](01-推理图任务调度.md) | 人工智能目标负载的任务图拆解与调度策略 |
+| [02-KV-Cache与内存管理.md](02-KV-Cache与内存管理.md) | KV Cache 生命周期、内存池与带宽竞争 |
+| [03-加速器协同调度.md](03-加速器协同调度.md) | CPU、NPU、GPU、DMA 等异构资源协同 |
+| [04-量化精度感知调度.md](04-量化精度感知调度.md) | 精度、质量与调度决策联动 |
+| [05-中断与实时性保障.md](05-中断与实时性保障.md) | 中断路径、线程化、隔离与关键保障负载保护 |
+| [06-能耗与热管理.md](06-能耗与热管理.md) | 能耗、温度、频率与长时间稳定性 |
+| [07-方法论与评估工具链.md](07-方法论与评估工具链.md) | 方法论、对照设计、采样与评估工具链 |
+
+---
+
+## 8. 预期研究成果
+
+1. **理论层**：任务关键系统中人工智能目标负载的实时保障问题定义与评价框架；
+2. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
+3. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
+4. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位实测对照数据；
+5. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。
+
+---
+
+*最后更新: 2026-09-21*
diff --git a/reference_file/01-inference-scheduling.md b/10-研究框架/01-推理图任务调度.md
similarity index 91%
rename from reference_file/01-inference-scheduling.md
rename to 10-研究框架/01-推理图任务调度.md
index 7e97e58..e6753de 100644
--- a/reference_file/01-inference-scheduling.md
+++ b/10-研究框架/01-推理图任务调度.md
@@ -13,6 +13,28 @@ RTOS需要将这个DAG映射为task集合，并设计调度策略保证：
2. **延迟最小化** — TTFT和尾延迟最小
3. **确定性保证** — 满足硬实时约束（如语音对话的<200ms抖动）
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何把人工智能目标负载拆解为可由 RTOS 管理的任务图；
+- 如何让人工智能目标负载与关键保障负载在同一系统中同时达标；
+- 如何把 SylixOS 的调度能力转化为可观测的系统收益与对照差异。
+
+因此，这一方向服务的是总课题中的“任务图建模与调度保障”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+这一方向在 `T5~T1` 五类部署形态中都成立，但关注重点不同：
+
+| 部署形态 | 调度侧重点 |
+|---|---|
+| `T5` 控制端 | 小任务集、强实时、极低抖动 |
+| `T4` 终端设备 | 单路智能任务与本地控制任务并存 |
+| `T3` 边缘节点 | 多源输入与多任务竞争下的任务图调度 |
+| `T2` 单机工作站 | 高吞吐推理与关键任务隔离并行 |
+| `T1` 服务器/集群 | 多请求队列、跨核与跨设备调度协同 |
+
## 2. LLM推理图的分解
### 2.1 推理阶段分析
@@ -359,7 +381,15 @@ RTOS角色:
- RTOS主要提供实时中断响应
```
-## 7. 关键设计决策
+## 7. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，调度机制至少要回答下面三个问题：
+
+1. 人工智能目标负载的 `TTFT`、`TPOT` 和端到端响应时间是否改善；
+2. 关键保障负载的 `deadline miss ratio`、`P99/P99.9 jitter` 是否仍受控；
+3. 在多任务并存、到达率变化和伴生竞争负载存在时，系统是否仍保持可解释的调度边界。
+
+## 8. 关键设计决策
| 决策点 | 选项 | 推荐 | 理由 |
|-------|------|-----|------|
@@ -370,7 +400,7 @@ RTOS角色:
| 同步机制 | Semaphore / Mutex / Notify | **Notify + Barrier** | 低开销，实时性可分析 |
| 多流策略 | FIFO / SRTF / RR | **SRTF** | 低延迟场景最优 |
-## 8. 开放研究问题
+## 9. 开放研究问题
1. **动态WCET估计**：LLM的WCET随input长度变化，如何在线估计？
2. **Adaptive Priority**：运行时根据系统负载动态调整优先级？
diff --git a/reference_file/02-kv-cache-memory.md b/10-研究框架/02-KV-Cache与内存管理.md
similarity index 88%
rename from reference_file/02-kv-cache-memory.md
rename to 10-研究框架/02-KV-Cache与内存管理.md
index f6e67f5..9d96706 100644
--- a/reference_file/02-kv-cache-memory.md
+++ b/10-研究框架/02-KV-Cache与内存管理.md
@@ -22,6 +22,28 @@ RTOS场景下KV Cache管理的关键问题：
3. **内存带宽瓶颈** — Attention是memory-bound而非compute-bound
4. **多请求KV Cache隔离** — 多流场景下的内存隔离与复用
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何让人工智能目标负载在受限容量下保持可持续服务；
+- 如何避免 KV Cache 动态增长破坏关键保障负载的实时边界；
+- 如何把内存确定性、带宽隔离和准入控制纳入 SylixOS 的实时保障机制。
+
+因此，这一方向服务的是总课题中的“容量边界与内存确定性”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+KV Cache 与内存管理在 `T5~T1` 中的约束差异很大，因此需要按部署形态看重点：
+
+| 部署形态 | 内存管理侧重点 |
+|---|---|
+| `T5` 控制端 | 极低内存预算下的模型裁剪与静态预分配 |
+| `T4` 终端设备 | 小模型多会话下的碎片与带宽竞争 |
+| `T3` 边缘节点 | 多请求并发下的 KV 隔离与带宽准入 |
+| `T2` 单机工作站 | 大上下文与高吞吐下的容量边界 |
+| `T1` 服务器/集群 | NUMA、多设备与跨节点缓存协同 |
+
## 2. KV Cache结构分析
### 2.1 KV Cache布局
@@ -342,7 +364,15 @@ Paged KV | variable| 0% | variable | 低
- 多GPU间KV Cache同步
```
-## 7. 关键设计决策
+## 7. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，KV Cache 与内存管理至少要回答下面三个问题：
+
+1. 人工智能目标负载在不同上下文长度和并发度下是否仍保持可接受的 `TTFT`、`TPOT` 与成功率；
+2. 关键保障负载是否因内存碎片、带宽争用或回收抖动而出现 `deadline miss` 或尾部抖动放大；
+3. 内存池、分页、压缩和准入机制是否建立了可预测的容量边界与准入边界。
+
+## 8. 关键设计决策
| 决策点 | 选项 | 推荐 | 理由 |
|-------|------|-----|------|
@@ -353,7 +383,7 @@ Paged KV | variable| 0% | variable | 低
| 带宽管理 | 固定分配 / 动态 | **Bandwidth-aware** | 避免带宽饱和 |
| 多流隔离 | 共享池 / Region | **Region** | 公平+可分析 |
-## 8. 开放研究问题
+## 9. 开放研究问题
1. **Dynamic KV Cache Sizing**: 运行时根据负载自动调整KV Cache大小？
2. **Cross-device KV**: 在CPU-NPU间共享/分发KV Cache？
diff --git a/reference_file/03-accelerator-collab.md b/10-研究框架/03-加速器协同调度.md
similarity index 90%
rename from reference_file/03-accelerator-collab.md
rename to 10-研究框架/03-加速器协同调度.md
index e53e4a6..03a8f04 100644
--- a/reference_file/03-accelerator-collab.md
+++ b/10-研究框架/03-加速器协同调度.md
@@ -2,13 +2,35 @@
## 1. 问题陈述
-现代嵌入式AI SoC都包含专用加速器(NPU/GPU/DSP)，LLM推理需要CPU和加速器协同工作。核心问题：
+任务关键系统中的人工智能目标负载往往依赖专用加速器(NPU/GPU/DSP)与 CPU 协同完成计算。RTOS 需要协调 CPU 与加速器协同工作。核心问题：
1. **速度不匹配**: CPU和加速器的速度比通常是1:5~1:10，容易产生stall
2. **状态不可见**: NPU驱动通常封闭，无法精确感知NPU状态
3. **数据传输开销**: CPU↔NPU的数据传输是瓶颈
4. **同步开销**: barrier/semaphore的实时性分析复杂
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何让 RTOS 对人工智能目标负载的设备计算阶段建立可管理的节拍；
+- 如何避免 CPU、加速器、DMA 和中断之间的协同开销侵蚀关键保障负载边界；
+- 如何把异构设备协同从黑盒调用，转化为可分析、可限流、可恢复的系统机制。
+
+因此，这一方向服务的是总课题中的“设备协同与异构执行可预测性”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+加速器协同在 `T5~T1` 中的实现方式差异很大，因此需要按部署形态看重点：
+
+| 部署形态 | 加速器协同侧重点 |
+|---|---|
+| `T5` 控制端 | 无加速器或轻量 DSP/NPU 下的简化协同 |
+| `T4` 终端设备 | SoC 内 CPU 与片上 NPU 的同步与拷贝开销 |
+| `T3` 边缘节点 | 多核 CPU 与外设/NPU/GPU 的流水线协同 |
+| `T2` 单机工作站 | CPU 与独立 GPU 的队列、DMA 与中断协同 |
+| `T1` 服务器/集群 | 多 GPU、多 NUMA 域与多进程协同执行 |
+
## 2. 加速器架构分析
### 2.1 常见加速器类型
@@ -403,7 +425,15 @@ RTOS角色:
- RTOS主要保障中断响应
```
-## 8. 关键设计决策
+## 8. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，加速器协同机制至少要回答下面三个问题：
+
+1. 设备协同是否降低了人工智能目标负载的等待时间、传输开销和端到端抖动；
+2. DMA、中断和共享内存竞争是否会冲击关键保障负载的响应时间边界；
+3. 当加速器状态不可见、延迟波动或发生故障时，系统是否仍具备准入、限流和恢复能力。
+
+## 9. 关键设计决策
| 决策点 | 选项 | 推荐 | 理由 |
|-------|------|-----|------|
@@ -414,7 +444,7 @@ RTOS角色:
| 中断模式 | Polling / Interrupt / Event | **Interrupt** | 实时性最好 |
| 错误处理 | Retry / Skip / Report | **Retry + Report** | 保证正确性 |
-## 9. 开放研究问题
+## 10. 开放研究问题
1. **Black-box NPU Scheduling**: 加速状态不可知时的调度策略？
2. **Cross-accelerator Load Balancing**: 多加速器间的动态负载均衡？
diff --git a/reference_file/04-quantization-scheduling.md b/10-研究框架/04-量化精度感知调度.md
similarity index 92%
rename from reference_file/04-quantization-scheduling.md
rename to 10-研究框架/04-量化精度感知调度.md
index de1efa1..94cd2cd 100644
--- a/reference_file/04-quantization-scheduling.md
+++ b/10-研究框架/04-量化精度感知调度.md
@@ -13,6 +13,28 @@ LLM的量化(Int8/Int4)不仅影响计算精度和模型大小，还直接影响
2. 内存带宽需求
3. 精度切换时的同步策略
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何把量化精度纳入 RTOS 可分析的调度参数；
+- 如何在人工智能目标负载时效性与输出有效性之间建立可控权衡；
+- 如何避免精度切换、校准开销和 MoE 负载波动破坏关键保障负载的实时边界。
+
+因此，这一方向服务的是总课题中的“质量-时效联合调度”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+量化与精度感知调度在 `T5~T1` 中的作用方式不同，因此需要按部署形态看重点：
+
+| 部署形态 | 精度调度侧重点 |
+|---|---|
+| `T5` 控制端 | 固定低精度、静态校准与可预测执行时间 |
+| `T4` 终端设备 | Int8/Int4 下的质量-时延平衡 |
+| `T3` 边缘节点 | 负载波动下的动态精度与服务模式切换 |
+| `T2` 单机工作站 | 多精度混合与大上下文推理的联合优化 |
+| `T1` 服务器/集群 | 多模型、多租户下的精度策略编排 |
+
## 2. 量化层级分析
### 2.1 LLM各组件的量化粒度
@@ -490,7 +512,15 @@ Solution: Multi-objective optimization
- 量化感知 serving (vLLM FP8 support)
```
-## 8. 关键设计决策
+## 8. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，量化与精度感知调度至少要回答下面三个问题：
+
+1. 不同精度策略下，人工智能目标负载的 `TTFT`、`TPOT`、成功率和输出质量如何共同变化；
+2. 精度切换、同步和校准开销是否会把关键保障负载推过实时边界；
+3. 精度模式切换是否可以被准入控制和运行模式管理，并保持可预测的抖动边界。
+
+## 9. 关键设计决策
| 决策点 | 选项 | 推荐 | 理由 |
|-------|------|-----|------|
@@ -501,7 +531,7 @@ Solution: Multi-objective optimization
| 模式切换 | 手动 / 自动 | **自动** | 自适应系统负载 |
| 校准策略 | Offline / Online | **Offline** | 在线校准开销大 |
-## 9. 开放研究问题
+## 10. 开放研究问题
1. **Layer-specific Precision**: 每层不同精度对调度有何影响？
2. **Precision Prediction**: 预测最佳精度, 避免频繁切换？
diff --git a/reference_file/05-irq-realtime.md b/10-研究框架/05-中断与实时性保障.md
similarity index 89%
rename from reference_file/05-irq-realtime.md
rename to 10-研究框架/05-中断与实时性保障.md
index eaca67b..a1e3e94 100644
--- a/reference_file/05-irq-realtime.md
+++ b/10-研究框架/05-中断与实时性保障.md
@@ -2,13 +2,35 @@
## 1. 问题陈述
-RTOS上的LLM推理不是孤立的系统。设备中还有其他硬实时任务(传感器、通信、控制)，它们与LLM任务共存于同一个RTOS内核中。核心问题：
+RTOS 上的人工智能目标负载与传感、通信、控制等关键保障负载共存于同一个 RTOS 内核中。核心问题：
1. **抢占冲突**: LLM的大计算量可能饿死其他实时任务
2. **中断风暴**: NPU完成中断 + 通信中断 + 传感器中断的并发处理
3. **Priority Inversion**: 低优先级的LLM任务可能阻塞高优先级任务
4. **资源竞争**: IRQ line、DMA channel、内存的共享竞争
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何保证关键保障负载在人工智能目标负载进入系统后仍拥有明确的中断优先权；
+- 如何把加速器完成中断、DMA 中断和外设中断纳入统一的实时边界分析；
+- 如何让 SylixOS 的中断管理能力成为双目标达标的硬支撑。
+
+因此，这一方向服务的是总课题中的“关键路径实时保障”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+中断管理与实时性保障在 `T5~T1` 中都重要，但关键矛盾不同：
+
+| 部署形态 | 中断保障侧重点 |
+|---|---|
+| `T5` 控制端 | 控制回路、看门狗和安全联锁优先级最高 |
+| `T4` 终端设备 | 传感器、通信与本地 AI 推理中断并存 |
+| `T3` 边缘节点 | 多外设、多链路和加速器完成中断叠加 |
+| `T2` 单机工作站 | GPU/网络/存储中断与关键任务隔离 |
+| `T1` 服务器/集群 | 多队列网络、存储和设备中断亲和治理 |
+
## 2. 中断层级设计
### 2.1 中断优先级映射
@@ -397,7 +419,15 @@ RTOS角色:
- RTOS保证关键路径上的中断响应
```
-## 8. 关键设计决策
+## 8. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，中断与实时性机制至少要回答下面三个问题：
+
+1. 关键保障负载在人工智能目标负载并存时，是否仍满足 `deadline miss ratio`、观测最大响应时间和尾部抖动约束；
+2. 加速器完成中断、DMA 中断和外设中断是否形成可分析的干扰上界，并维持可控的中断行为；
+3. 优先级继承、IRQ 亲和和中断屏蔽策略是否降低了关键路径不确定性并形成可分析上界。
+
+## 9. 关键设计决策
| 决策点 | 选项 | 推荐 | 理由 |
|-------|------|-----|------|
@@ -408,7 +438,7 @@ RTOS角色:
| Timer | Tick / Event | **Event** | 降低开销 |
| IRQ Affinity | Auto / Manual | **Manual** | 保证确定性 |
-## 9. 开放研究问题
+## 10. 开放研究问题
1. **Interrupt-aware Scheduling**: 将中断处理时间纳入调度分析？
2. **Interrupt Storm Handling**: 多中断并发时的优先级管理？
diff --git a/reference_file/06-power-thermal.md b/10-研究框架/06-能耗与热管理.md
similarity index 89%
rename from reference_file/06-power-thermal.md
rename to 10-研究框架/06-能耗与热管理.md
index 3f89e5e..b476b4e 100644
--- a/reference_file/06-power-thermal.md
+++ b/10-研究框架/06-能耗与热管理.md
@@ -2,7 +2,7 @@
## 1. 问题陈述
-边缘/嵌入式设备运行LLM时，能耗和热是硬约束：
+当人工智能目标负载进入任务关键系统后，能耗和热会直接进入实时保障约束：
```
LLM推理能耗 = 计算能耗 + 内存带宽能耗 + 传输能耗
@@ -19,6 +19,28 @@ Constraints:
- Form Factor: Passive cooling (no fan)
```
+### 1.1 本方向在总课题中的角色
+
+本方向聚焦：
+
+- 如何避免热漂移、降频和功率封顶破坏人工智能目标负载的时效性；
+- 如何避免功耗控制策略反向侵蚀关键保障负载的实时边界；
+- 如何把能耗与热管理纳入 SylixOS 的长期稳定运行机制。
+
+因此，这一方向服务的是总课题中的“长稳运行与热功率边界”主线。
+
+### 1.2 与验证矩阵的对应关系
+
+能耗与热管理在 `T5~T1` 中的表现差异显著，因此需要按部署形态看重点：
+
+| 部署形态 | 能耗与热管理侧重点 |
+|---|---|
+| `T5` 控制端 | 电池/电源预算、深睡眠与快速恢复 |
+| `T4` 终端设备 | 被动散热下的持续推理与温升控制 |
+| `T3` 边缘节点 | 多核+加速器协同下的热热点迁移 |
+| `T2` 单机工作站 | 长时间高负载下的降频与风扇策略 |
+| `T1` 服务器/集群 | 机架功率、PUE 与多设备热耦合 |
+
## 2. 能耗模型
### 2.1 各组件的能耗模型
@@ -439,7 +461,15 @@ Power Monitoring (RTOS Task):
- 数据中心级功耗管理
```
-## 7. 关键设计决策
+## 7. 本方向的验证关注点
+
+为了让本方向与总课题的双目标评价框架对齐，能耗与热管理至少要回答下面三个问题：
+
+1. 人工智能目标负载在长稳运行下的 `TTFT`、`TPOT` 和吞吐是否因降频与热保护发生持续退化；
+2. 关键保障负载是否会因为 DVFS、休眠唤醒或热限额而出现额外抖动和截止期违约；
+3. 功率与热管理机制是否能把 24 h 稳定性、恢复时间和能效指标变成可测量、可复现的证据。
+
+## 8. 关键设计决策
| 决策点 | 选项 | 推荐 | 理由 |
|-------|------|-----|------|
@@ -450,7 +480,7 @@ Power Monitoring (RTOS Task):
| 热感知 | Reactive / Predictive | **Predictive** | 减少延迟抖动 |
| 模式切换 | Manual / Auto / Hybrid | **Auto** | 自适应环境变化 |
-## 8. 开放研究问题
+## 9. 开放研究问题
1. **Predictive Power**: 基于输入预测功耗, 提前调整DVFS？
2. **Thermal-aware Task Placement**: 多核场景下的热均衡调度？
diff --git a/10-研究框架/07-方法论与评估工具链.md b/10-研究框架/07-方法论与评估工具链.md
new file mode 100644
index 0000000..81dd987
--- /dev/null
+++ b/10-研究框架/07-方法论与评估工具链.md
@@ -0,0 +1,278 @@
+# 方向7：方法论与评估工具链
+
+## 1. 方法论总框架
+
+本研究的方法论围绕下面这个核心判断展开：
+
+> **在五类部署形态下，大型跨平台实时操作系统在任务关键系统中支撑人工智能目标负载、维持关键保障负载实时边界的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。**
+
+因此，方法论采用 **“准入 → 对照 → 建模 → 机制实现 → 实测验证 → 跨档位分析”** 的闭环。
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ Step 1: 平台与测量准入 │
+│ - 设备、OS、加速器、模型、计时链路、功率计 │
+├─────────────────────────────────────────────────────────┤
+│ Step 2: 公平对照设计 │
+│ - O0 普通 Linux / O1 PREEMPT_RT / O2-O3 SylixOS │
+├─────────────────────────────────────────────────────────┤
+│ Step 3: 负载建模 │
+│ - 人工智能目标负载 / 关键保障负载 / 伴生竞争负载 │
+├─────────────────────────────────────────────────────────┤
+│ Step 4: 机制实现 │
+│ - 调度、隔离、内存、中断、准入、能耗与热管理 │
+├─────────────────────────────────────────────────────────┤
+│ Step 5: 实测验证 │
+│ - 双目标达标、长稳、恢复、消融、统计显著性 │
+├─────────────────────────────────────────────────────────┤
+│ Step 6: 跨档位分析 │
+│ - T5~T1 五类部署形态、11 个代表档位的规律与边界 │
+└─────────────────────────────────────────────────────────┘
+```
+
+## 2. 研究对象、对照对象与验证矩阵
+
+### 2.1 研究对象
+
+主研究对象是：
+
+- **大型跨平台实时操作系统这一类平台**
+- 其中 `SylixOS` 是主实验样例
+- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本
+- 其实时调度、资源隔离、中断管理、内存管理和恢复机制
+
+### 2.2 对照对象
+
+后续所有实验统一采用三层 OS 对照：
+
+| 编号 | 对照对象 | 作用 |
+|---|---|---|
+| `O0` | 普通 Linux | 通用系统基线 |
+| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
+| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
+| `O3` | SylixOS 优化配置 | 主实验样例优化组 |
+
+必要时可增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，容器或虚拟机仅作为部署方式记录，不单独列为新的“内核类别”。
+
+### 2.3 验证矩阵
+
+硬件承担关键验证矩阵角色。
+`T5~T1` 五类部署形态和 `11` 个代表档位用于验证系统机制在不同资源条件下的成立范围与边界。
+
+## 3. 负载建模：三类负载
+
+### 3.1 三类负载定义
+
+| 负载类型 | 定义 | 例子 |
+|---|---|---|
+| 人工智能目标负载 | 系统要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
+| 关键保障负载 | 维持任务关键系统边界的核心任务 | 1 ms 控制回路、联锁、状态采集、执行闭环 |
+| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、存储、网络 I/O、模型加载 |
+
+### 3.2 建模目标
+
+本研究统一评估三项内容：
+
+1. 人工智能目标负载是否按时并有效地完成；
+2. 关键保障负载是否仍满足截止期与抖动边界；
+3. 系统在两类目标并存时是否保持稳定、可解释和可恢复。
+
+### 3.3 任务图抽象
+
+```
+人工智能目标负载：
+ 输入处理 → Prefill / 前处理 → 设备计算 → 输出决策 → 结果返回
+
+关键保障负载：
+ 周期释放 → 传感采集 → 控制计算 → 执行输出 → 状态确认
+
+伴生竞争负载：
+ 日志写入 / 网络收发 / 模型加载 / 存储 I/O / 管理服务
+```
+
+后续所有调度建模，都围绕这三类负载的竞争关系来分析。
+
+## 4. 评价框架：双目标达标 + 系统协同
+
+### 4.1 人工智能目标负载指标
+
+| 类别 | 指标 |
+|---|---|
+| 时效 | `TTFT`、`TPOT`、端到端响应时间 |
+| 有效性 | 精度、成功率、任务完成率、输出可用性 |
+| 稳定性 | 长时间运行退化、失败率、热漂移影响 |
+
+### 4.2 关键保障负载指标
+
+| 类别 | 指标 |
+|---|---|
+| 截止期 | `deadline miss ratio` |
+| 尾部行为 | `P99/P99.9 jitter`、观测最大响应时间 |
+| 外部接口 | GPIO / CAN / RS485 / 网络回路端到端响应 |
+
+### 4.3 系统协同指标
+
+| 类别 | 指标 |
+|---|---|
+| 效率 | 有效吞吐、拒绝率、恢复时间 |
+| 能效 | `E/token`、`tokens/J`、整机功耗 |
+| 稳定性 | 温度、降频时间比例、24 h 长稳表现 |
+| 公平性 | 多任务 / 多模型并发下的资源分配与隔离效果 |
+
+因此，论文与实验的通过标准应统一为：
+
+> **人工智能目标负载达标 + 关键保障负载达标 + 系统协同稳定。**
+
+## 5. 准入机制
+
+为了保证后续对照具有可信度，所有平台必须通过分阶段准入：
+
+| 门槛 | 核心内容 |
+|---|---|
+| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑正确 |
+| `G1` 测量准入 | 单调时钟、日志、功率计、外部测量链路 |
+| `G2` 加速器准入 | 驱动加载、最小算子、结果回读 |
+| `G3` 模型准入 | 模型转换、加载、推理、释放、重复运行 |
+| `G4` 混合负载准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
+
+任何准入失败都要作为研究记录保留。
+
+## 6. 对照原则
+
+### 6.1 固定不变项
+
+为了保证 OS 对照公平，以下变量必须冻结：
+
+- 模型版本、量化格式、tokenizer、输入长度与输出长度；
+- CPU 核数量、优先级、内存预算、加速器数量；
+- 到达流、随机种子、预热时间、采样窗口；
+- 环境温度、散热、驱动与框架版本。
+
+### 6.2 允许变化项
+
+允许作为自变量扫描的内容包括：
+
+- OS 类型与配置；
+- 调度策略与核隔离；
+- IRQ 亲和与中断线程化；
+- 内存限额、KV Cache 预分配与准入控制；
+- 功率与频率策略；
+- 并发度、到达率和背景干扰强度。
+
+## 7. 建模与分析方法
+
+### 7.1 调度分析
+
+关键保障负载优先使用固定优先级与响应时间分析：
+
+```
+R_i^(0) = C_i
+R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
+```
+
+其中：
+
+- `C_i` 为关键保障任务的执行时间；
+- `T_j` 为高优先级任务周期；
+- `R_i` 为响应时间。
+
+人工智能目标负载根据其服务目标与预算，被建模为：
+
+- 可限流的服务任务；
+- 可准入的队列任务；
+- 可隔离的设备任务；
+- 必要时具有阶段性优先级的任务图。
+
+### 7.2 容量与热稳定性分析
+
+对人工智能目标负载，需要同时分析：
+
+- 模型权重占用；
+- KV Cache 增长；
+- 中间激活与工作区；
+- 运行时与驱动保留区；
+- 温度导致的频率变化。
+
+因此，容量与热是实时保障能否成立的前提条件。
+
+### 7.3 消融分析
+
+系统机制收益通过逐项消融来解释，例如：
+
+1. 去掉 CPU 核隔离；
+2. 去掉 IRQ 亲和；
+3. 去掉内存预分配；
+4. 去掉推理准入控制；
+5. 去掉功耗感知策略。
+
+每次只移除一个机制，观察双目标达标边界的变化。
+
+## 8. 工具链
+
+### 8.1 采样与追踪工具
+
+| 类别 | 代表工具 |
+|---|---|
+| OS 追踪 | RTOS trace、ftrace、事件日志 |
+| 性能分析 | perf、设备 profiler、定制采样脚本 |
+| 功率与温度 | 外部功率计、PDU、板载传感器、温度记录 |
+| 外设测量 | 示波器、逻辑分析仪、CAN/RS485 分析仪 |
+
+下面给出统一测量矩阵，用于把指标、采样工具与观测目的对齐：
+
+| 指标类别 | 代表指标 | 主要采样工具 | 观测目的 |
+|---|---|---|---|
+| 人工智能目标负载时效 | `TTFT`、`TPOT`、端到端响应时间 | 应用层时间戳、推理引擎日志、设备 profiler | 判断智能功能是否按服务时限完成 |
+| 人工智能目标负载有效性 | 精度、成功率、任务完成率、输出可用性 | 数据集回放脚本、结果校验脚本、业务判分程序 | 避免只优化时延而牺牲输出质量 |
+| 关键保障负载实时性 | `deadline miss ratio`、观测最大响应时间 | RTOS trace、GPIO 打点、示波器、逻辑分析仪 | 判断关键任务是否仍满足实时边界 |
+| 尾部抖动行为 | `P99/P99.9 jitter`、突发峰值延迟 | 高精度事件日志、外部时序测量、分位统计脚本 | 识别平均值掩盖下的尾部失稳 |
+| CPU 与调度行为 | 核占用、上下文切换、迁核、中断干扰 | perf、ftrace、调度事件日志 | 解释不同 OS 机制下的调度差异 |
+| 内存与容量行为 | 峰值内存、KV Cache 增长、分配失败率 | `/proc`、驱动日志、运行时统计、定制采样脚本 | 判断容量边界与动态分配抖动来源 |
+| 功率与热稳定性 | 整机功耗、芯片温度、降频时间比例 | 外部功率计、PDU、板载传感器、温度记录 | 判断长稳阶段是否因热或供电触发退化 |
+| I/O 与外设链路 | GPIO/CAN/RS485/网络回路时延 | 示波器、总线分析仪、抓包工具 | 验证系统外部闭环而非仅内部线程表现 |
+| 恢复与稳态行为 | 故障恢复时间、重试成功率、24 h 退化曲线 | 守护日志、错误注入脚本、长稳记录程序 | 判断系统是否具备工程可用性 |
+
+### 8.2 理论与仿真工具
+
+| 类别 | 作用 |
+|---|---|
+| RTA / WCET 分析 | 关键保障负载响应时间边界分析 |
+| 抽象仿真框架 | 参数扫描、到达流与机制对比 |
+| 架构级仿真 | 必要时验证拓扑与内存模型假设 |
+
+这里的仿真用于机制理解、参数扫描与拓扑假设验证。
+主线验证平台为 **SylixOS 与其对照系统**。
+
+## 9. 实验流程
+
+统一实验流程如下：
+
+1. 完成 `G0~G4` 准入；
+2. 建立 `O0/O1/O2/O3` 对照组；
+3. 先测空载与仅人工智能目标负载基线；
+4. 再测人工智能目标负载与关键保障负载并存场景；
+5. 加入 CPU / 内存 / I/O / 网络等伴生竞争负载；
+6. 进行长稳、突发、恢复与消融实验；
+7. 进行跨档位和跨部署形态对比。
+
+## 10. 可复现性要求
+
+每次运行至少保存以下元数据：
+
+- 档位、设备编号、OS/BSP/驱动版本；
+- 模型校验值、量化格式、输入模板、随机种子；
+- CPU/IRQ/频率/内存配置；
+- 环境温度、散热方式、测量仪器；
+- 原始延迟、功率、温度与错误日志。
+
+只有满足这些条件，后续论文中的“优势”才具备可外部讨论的基础。
+
+## 11. 本文档在整个仓库中的作用
+
+本文件负责回答三个问题：
+
+1. **怎么保证研究对象始终落在 RTOS 平台层；**
+2. **怎么把人工智能目标负载、关键保障负载和伴生竞争负载统一进同一评价框架；**
+3. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据。**
+
+这也是后续 `02-基础设备与算力基础.md`、`03-实验设计.md` 和 `04-论文写作规划.md` 必须共同服从的方法论中轴。
diff --git a/10-研究框架/README.md b/10-研究框架/README.md
new file mode 100644
index 0000000..09e299f
--- /dev/null
+++ b/10-研究框架/README.md
@@ -0,0 +1,33 @@
+# 研究框架索引
+
+本目录放置项目的核心研究框架文档，说明研究对象、研究结构与具体优化切入方向。
+
+## 阅读建议
+
+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`
+
+## 文件说明
+
+- `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`
+ - 建模、仿真、原型验证和评估方法学
diff --git a/20-实验与规划/01-研究逻辑说明.md b/20-实验与规划/01-研究逻辑说明.md
new file mode 100644
index 0000000..1b36ec7
--- /dev/null
+++ b/20-实验与规划/01-研究逻辑说明.md
@@ -0,0 +1,170 @@
+# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的研究逻辑说明
+
+## 1. 文档目的
+
+本文用于解释本目录中的研究逻辑结构，并说明：
+
+- [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) 如何承载完整的 `T5~T1` 五类部署形态与 `11` 个代表档位；
+- [03-实验设计.md](./03-实验设计.md) 如何把这些硬件条件组织成可复现的对照实验；
+- [04-论文写作规划.md](./04-论文写作规划.md) 如何把证据组织成一篇系统化论文。
+
+三份文档承担的职责如下：
+
+| 文档 | 回答的问题 | 在研究中的作用 |
+|---|---|---|
+| [02-基础设备与算力基础.md](./02-基础设备与算力基础.md) | 在哪些部署形态与硬件条件下验证？ | 定义 `T5~T1` 五类部署形态、五种算力基础与十一档实验矩阵 |
+| [03-实验设计.md](./03-实验设计.md) | 如何产生可信、可复现、可比较的证据？ | 定义准入、对照、负载、指标、统计与验收方法 |
+| [04-论文写作规划.md](./04-论文写作规划.md) | 如何把这些证据组织成论文贡献？ | 把研究问题、方法、结果和边界映射成论文结构 |
+
+整个研究的主线是：
+
+> **研究对象定义清楚 → 验证矩阵完整展开 → 公平对照与双目标实验 → 数据可复现 → 跨档位规律与边界 → 论文贡献。**
+
+## 2. 研究对象
+
+这个项目的研究对象是：
+
+> **大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制。**
+
+本目录后续所有实验和文档都围绕下面这条主线展开：
+
+- **研究对象**：大型跨平台实时操作系统这一类平台；
+- **主实验样例**：SylixOS；
+- **外部参照样本**：QNX、VxWorks、INTEGRITY、LynxOS-178；
+- **系统场景**：任务关键系统；
+- **目标负载**：人工智能目标负载；
+- **对照对象**：普通 Linux、PREEMPT_RT Linux 与 SylixOS；
+- **硬件角色**：验证矩阵。
+
+## 3. T5~T1 五类部署形态与 11 个代表档位
+
+硬件细度是本仓库的重要资产。`T5~T1` 与 `11` 个代表档位共同承担三项作用：
+
+1. **验证矩阵**：在不同资源条件下检验同一系统问题是否成立；
+2. **证据组织框架**：把结果放到统一谱系中观察规律与边界；
+3. **产业可解释性**：让不同部署形态都能找到对应的现实位置。
+
+对应关系如下：
+
+| 部署形态 | 主要系统角色 | 主要验证重点 |
+|---|---|---|
+| `T5` 控制端 | 极紧资源预算下的任务关键控制节点 | 强实时、极小内存、低功耗边界 |
+| `T4` 设备端 SoC | 设备本体内的统一内存异构平台 | CPU/NPU/GPU 共享资源与带宽隔离 |
+| `T3` 边缘节点 | 设备附近的近源推理节点 | 多任务并发、热稳定性、边缘协同 |
+| `T2` 桌面 / 工作站单机 | 单机高密本地推理平台 | 单机多卡调度、NVLink/PCIe 拓扑、公平性 |
+| `T1` 服务器 / 集群 | 多节点大模型服务平台 | 跨节点通信、分布式调度、规模扩展 |
+
+`T3`、`T2` 分别对应近源边缘节点与单机高密本地推理平台。
+`T5~T1` 作为**部署形态与运行环境代码**，用于组织跨场景验证矩阵。
+
+## 4. 人工智能目标负载与系统负载结构
+
+在任务关键系统里，负载应至少分成三类：
+
+| 负载类型 | 定义 | 例子 |
+|---|---|---|
+| 人工智能目标负载 | 系统需要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
+| 关键保障负载 | 维持系统安全与执行闭环的关键任务 | 1 ms 周期控制、联锁、状态采集、执行输出 |
+| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、后台通信、模型加载、I/O |
+
+本项目重点评估的是：
+
+> **RTOS 协调人工智能目标负载与关键保障负载时，对系统边界的维持能力与成立条件。**
+
+这一步会直接影响实验设计、论文结构和评价指标。
+
+## 5. 准入与对照的实验顺序
+
+本项目采用分阶段准入机制：
+
+| 门槛 | 核心检查内容 |
+|---|---|
+| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑 |
+| `G1` 测量准入 | 单调时钟、日志、外部测量链路、功率计 |
+| `G2` 加速器准入 | CUDA / RKLLM / RKNN / 驱动 / 最小算子 |
+| `G3` 模型准入 | 模型转换、加载、正确推理与峰值内存 |
+| `G4` 混合场景准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
+
+只有通过 `G4` 的平台与配置，才能进入正式对照。
+
+## 6. O0~O4 对照组结构
+
+主对照统一采用：
+
+| 编号 | 配置 | 作用 |
+|---|---|---|
+| `O0` | 普通 Linux | 通用系统基线 |
+| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
+| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
+| `O3` | SylixOS 优化配置 | 主实验组 |
+
+必要时增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，并继续保持“普通 Linux”和“实时增强 Linux”的对照边界。
+
+## 7. 实验逻辑如何展开
+
+实验逻辑遵循从简单到复杂、从单目标到双目标的顺序：
+
+1. 先确认平台、模型与测量链路可用；
+2. 再测仅人工智能目标负载的基线表现；
+3. 再测仅关键保障负载的下界行为；
+4. 再测两者并存的核心场景；
+5. 最后引入伴生竞争负载、突发场景、长稳运行与恢复测试。
+
+这条顺序用于区分平台就绪性问题与系统机制边界问题。
+
+## 8. 哪些指标构成核心证据
+
+后续证据链必须覆盖三层：
+
+### 8.1 人工智能目标负载层
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 成功率、任务质量、输出可用性
+- 长时间运行稳定性
+
+### 8.2 关键保障负载层
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 8.3 系统协同层
+
+- 有效吞吐
+- `E/token`
+- 温度、降频和热漂移
+- 多任务公平性
+- 恢复能力与 24 h 长稳表现
+
+项目最终形成的核心判断是：
+
+> **在双目标约束下，RTOS 对系统稳定性、可预测性与可保障性的提升边界。**
+
+## 9. 数据如何转化为论文贡献
+
+论文贡献排序如下：
+
+| 贡献 | 所需证据 | 对应论文位置 |
+|---|---|---|
+| `C1` RTOS 对人工智能目标负载与关键保障负载的实时保障优势 | 双目标达标、尾部行为、有效吞吐与恢复结果 | 第1、4、5、7、8章 |
+| `C2` T5~T1 五类部署形态与 11 个代表档位的统一验证矩阵 | 跨档位容量、功耗、拓扑与边界分析 | 第3、7、8章 |
+| `C3` 可复现的方法论与基准对齐 | 准入、元数据、第三方基准复现、消融与统计口径 | 第5、7、9章 |
+
+在这套结构下，硬件细度得到完整呈现，并服务于研究对象与实验结论组织。
+
+## 10. 最终闭环
+
+本研究形成的核心结论关系是：
+
+> **随着系统从 T5 控制端扩展到 T1 服务器 / 集群，大型跨平台实时操作系统这一类平台在多大范围内能够同时保证人工智能目标负载与关键保障负载，其优势来自哪些机制，又会在哪些档位开始收窄。SylixOS 是本项目的主实验样例。**
+
+在这条关系得到数据验证后，整个仓库会形成一条稳定主线：
+
+- 研究对象清楚；
+- 验证矩阵完整；
+- 对照关系公平；
+- 评价框架统一；
+- 论文叙事和产业叙事都能站住。
diff --git a/20-实验与规划/02-基础设备与算力基础.md b/20-实验与规划/02-基础设备与算力基础.md
new file mode 100644
index 0000000..1f27d27
--- /dev/null
+++ b/20-实验与规划/02-基础设备与算力基础.md
@@ -0,0 +1,784 @@
+# 基础设备与算力基础配置（T5~T1 五类部署形态 / 11 个代表档位）
+
+> 版本: v2.1 起草日期: 2026-09-21
+> 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
+> 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
+> 现有硬件锚点: T2-L（4×V100 SXM 单机多加速器）+ T4-L / T5-H（RK3588 工业盒）| 需新增: T1 集群扩展 + T3/T4 其余档位
+
+---
+
+## 0. 场景、算力基础与设备档位总览
+
+### 0.1 研究框架与设备谱系的对应关系
+
+研究框架中，项目统一采用“**T5~T1 五类部署形态 + 5 种算力基础 + 5 层技术栈**”的表述。
+本文件属于实验设计部分，因此进一步把不同部署环境下的设备条件展开成可执行的设备档位体系。
+这里完整呈现硬件与指标颗粒度，并明确：
+
+> **这些设备档位的作用是验证 RTOS 机制在不同资源条件下是否成立。**
+
+| 研究维度 | 定义 | 在本文件中的落地方式 |
+|---|---|---|
+| 5 类部署形态 | 控制端、设备端 SoC、边缘节点、桌面/工作站单机、服务器/集群 | 通过 `T5~T1` 设备档位覆盖 |
+| 5 种算力基础 | 控制型、设备端 SoC 型、边缘节点型、工作站单机型、服务器/集群型 | 通过代表设备与容量区间体现 |
+| 11 个代表档位 | 可采购、可测试、可对照的实验运行形态 | 作为 RTOS 机制验证矩阵与采购清单 |
+
+`T5~T1` 是用于实验组织的**部署形态代码**。
+这套划分以**部署位置与系统角色**为一级分类，以容量作为档位细分参考；`T3 边缘节点` 与 `T2 桌面/工作站单机` 分别对应独立节点与单机高密本地推理平台。
+后续实验中，这些档位分别承担的是：
+
+- 人工智能目标负载在不同资源条件下的时效与有效性验证；
+- 关键保障负载在不同资源条件下的边界验证；
+- RTOS 在双目标约束下的机制有效性验证。
+
+### 0.2 分级维度与分档规则
+
+**分级维度**: 以「统一内存 / 显存容量」为第一分类维度。容量直接决定可承载的模型规模，并与功耗、散热、互联架构强相关，因此适合作为连续设备谱系的主轴。
+
+**分档规则**: 相邻两档的边界值归入**上界一侧**
+
+| 部署形态 | 代码 | 代表档位 | 容量范围 | 说明 |
+| -------- | --- | --------------- | ---------------- | ---------------- |
+| **T5 控制端场景** | T5 | **T5-L / T5-M / T5-H** | **1~8 G** | 运行在控制器或轻量控制盒本体 |
+| **T4 设备端 SoC 场景** | T4 | **T4-L / T4-M** | **8~32 G** | 运行在设备本体 SoC 上 |
+| **T3 边缘节点场景** | T3 | **T3-L** | **32~64 G / 48 G 独显** | 运行在设备附近的边缘节点 |
+| **T2 桌面/工作站单机场景** | T2 | **T2-L / T2-M / T2-H** | **64~512 G** | 研发或本地服务用单机多卡 |
+| **T1 服务器/集群场景** | T1 | **T1-L / T1-H** | **512 G~2 T** | 多节点分布式推理 |
+
+> 说明: 这里的首要分类依据是部署形态；容量只作为各部署形态内部的分档参考。
+
+### 0.3 全谱系总表（11 个档位）
+
+> 算力单位统一约定: **NVIDIA GPU 用 FP16 Tensor Core TFLOPS（dense）**，**NPU 用 INT8 TOPS**；两者不可直接换算。
+
+| 档位 | 容量 | 算力（峰值） | 功耗 | 算力/供电架构 | 代表设备 | 状态 |
+| -------- | ------------ | -------------------------- | ------------- | ---------------------------------- | ----------------------------- | ------- |
+| **T5-L** | 1~2 G | 0.8~1 TOPS (INT8) | 3~5 W | ARM A55 + 小 NPU；DC 5V/12V 被动散热 | RK3568 1~2GB 核心板 | |
+| **T5-M** | 2~4 G | 6 TOPS (INT8) | 5~10 W | ARM A72+A53 + NPU；DC 12V 被动散热 | RK3576 4GB | |
+| **T5-H** | 4~8 G | 6~32 TOPS (INT8) | 7~21 W | ARM A76+A55 + M0 + NPU；DC 12V 被动 | **RK3588 8GB** / Jetson Orin Nano 8GB | 现有（16G 板降配） |
+| **T4-L** | 8~16 G | 32~100 TOPS (INT8) | 10~30 W | ARM SoC 统一内存 + NPU/GPU；DC 12~24V 被动/小风扇 | **RK3588 16GB 工业盒** / Orin NX 16GB | 现有 |
+| **T4-M** | 16~32 G | 275 TOPS (INT8) | 15~60 W | ARM A78AE + Ampere GPU + 2×DLA；DC 19V 主动风冷 | Jetson AGX Orin 32GB | |
+| **T3-L** | 32~64 G / 48 G 独显 | 275 TOPS / 91 TFLOPS (FP16) | 60~600 W | ARM 统一内存 或 x86+单卡 CUDA；风冷/液冷 | Jetson AGX Orin 64GB / 边缘工控机 + RTX 6000 Ada 48GB | |
+| **T2-L** | 64~128 G | 500 TFLOPS (FP16) | 600~1.65 kW | x86 + 4×V100 SXM NVLink；双电源 + 360 液冷 | **4×V100 32GB SXM 塔式** | 现有 |
+| **T2-M** | 128~256 G | 1000 TFLOPS (FP16) | 3.0~3.3 kW | x86 + 8×V100 SXM NVLink；双电源 + 液冷 | 8×V100 32GB SXM 整机 | 需扩展 |
+| **T2-H** | 256~512 G | ~4000 TFLOPS (FP16) | 4.5~6.5 kW | x86 + 4×H100 SXM5 NVLink；高压供电 + 强制液冷 | 4×H100 80GB SXM5 工作站 | |
+| **T1-L** | 512 G~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × x86+4×V100，100GbE RoCE/IB；机房风冷/液冷 | 4×（T2-L 节点）+ IB 交换机 | 需扩展 |
+| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | 20~25 kW | 4 节点 × x86+4×H100，NDR 400G IB；机房级液冷 | 4×（T2-H 节点）+ NDR 交换机 | |
+
+### 0.4 设计原则
+
+1. **部署形态先行、设备落地**: 先用“控制端 / 设备端 SoC / 边缘节点 / 桌面工作站 / 服务器集群”定义研究问题，再用 `T5~T1` 设备档位组织具体实验。
+2. **容量连续、功耗阶跃**: 从 1 GB / 3 W 到 2 TB / 25 kW，容量每上一档约 ×2，功耗随架构变化阶跃（被动散热 → 主动风冷 → 液冷 → 机房级液冷），形成天然的性能/能效对比曲线。
+3. **CUDA 栈贯通高算力侧**: T1/T2/T3 的候选平台可共享 NVIDIA CUDA 生态（V100 / Ampere / Hopper），模型与推理框架（vLLM / TensorRT-LLM）可跨档位迁移，主要变化是规模与拓扑。
+4. **非 CUDA 控制端与设备端路线**: T5 全档位与 T4-L 走 RKNN/RKLLM NPU 栈，代表最强资源约束与最接近设备本体的运行位置。
+5. **现有硬件复用**: **4×V100 SXM（T2-L）** 与 **RK3588 工业盒（T4-L 16GB / T5-H 8GB 两用）** 为零采购成本基线，整条谱系以此为锚点向两侧扩展。
+6. **BSP 最小化**: 全谱系仅需两类 BSP——x86（T1/T2/T3-B 路线）与 ARM64（T5/T4/T3-A 路线），档位差异靠设备树与驱动裁剪吸收，不新增架构分支。
+
+---
+
+## T1. 服务器/集群场景的多节点形态 — 512 G ~ 2 T
+
+### T1.1 定位
+
+大规模分布式 LLM 推理与多模型并发服务。验证 SylixOS 在**多节点分布式调度**下的实时性——跨节点 RDMA 延迟、NCCL 集合通信抖动、分布式推理框架（vLLM+Ray / TensorRT-LLM+MPI）与实时控制任务的混合负载隔离。
+
+### T1.2 档位对比
+
+| 维度 | T1-L 多节点-低 | T1-H 多节点-高 |
+| ----------- | --------------------- | --------------------------- |
+| **容量** | 512 GB（4 × 128 GB） | 1.28 TB（4 × 320 GB） |
+| **节点数** | 4 节点 | 4 节点 |
+| **单节点加速器** | 4 × V100 32GB SXM | 4 × H100 80GB SXM5 |
+| **集群算力** | ~2000 TFLOPS (FP16) | ~16 PFLOPS (FP16) |
+| **节点内互联** | NVLink 300 GB/s | NVLink 900 GB/s |
+| **节点间互联** | 100GbE RoCE / IB | NDR 400G IB |
+| **整机功耗** | ~6.6 kW | 20~25 kW |
+| **散热架构** | 每节点 360 液冷 + 机房风冷 | 机房级液冷（CDU / 后门换热器） |
+| **主要模型** | 72B FP16 / 多实例 14B | 671B INT4 / 多实例 72B FP16 |
+
+#### T1.2.1 T1-L 多节点-低 — 4 节点 × 4×V100 = 512 GB（本方案主线）
+
+| 项目 | 规格 | 数量 | 备注 |
+| --------- | ------------------------------------------------ | ------------- | --------------------------- |
+| **计算节点** | 同 T2-L 单机配置 | **4 台** | 每节点 4×V100 32GB SXM = 128GB |
+| 节点内 GPU | NVIDIA V100 32GB SXM (NVLink 全互联) | 4×4 = 16 卡 | 每节点 NVLink 全互联 |
+| 节点内 CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2GHz) | 4 | 每节点 1 颗 |
+| 节点内内存 | 128GB DDR4-2133 ECC | 4×128 = 512GB | 每节点 128GB |
+| **节点间互联** | Mellanox ConnectX-6 100GbE / IB | 4 卡 | 每节点 1 卡，RoCE 或原生 IB |
+| 节点间交换机 | 100GbE/IB 交换机 (Mellanox SN2700 或同档) | 1 | 32 端口 |
+| 存储 | 共享 NFS / NVMe-oF (每节点 1TB NVMe 本地 + 共享存储) | — | 模型权重共享池 |
+| 散热 | 每节点 360 一体液冷 ×2 | — | 同 T2-L |
+| 电源 | 每节点 长城 1650W + 1250W 双电源 | 4 套 | 单节点 ~1.65 kW，集群 ~6.6 kW |
+| 功率采集 | PDU + Yokogawa WT310 (整机) + nvidia-smi dmon (单卡) | — | 每节点独立采集 |
+
+**显存与算力**
+
+| 指标 | 值 |
+| --------------- | ---------------------------------- |
+| **总显存** | **512 GB** (4 × 128GB) |
+| 单卡 FP16 算力 | 125 TFLOPS |
+| 集群总算力 (FP16) | ~2000 TFLOPS (NVLink 节点内 + IB 节点间) |
+| NVLink 带宽 (节点内) | 300 GB/s (GPU↔GPU) |
+
+**可运行模型**
+
+| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
+| ------------------------ | ---------- | ------- | ----- | ------------------ |
+| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 3+ | vLLM + Ray 分布式 |
+| Qwen2.5-72B | INT4 (AWQ) | ~36 GB | 14+ | vLLM + Ray |
+| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 2 | TensorRT-LLM + MPI |
+| Qwen2.5-14B | FP16 | ~28 GB | 18+ | vLLM (可单节点) |
+| LLaMA-3-70B | FP16 | ~140 GB | 3+ | vLLM + Ray |
+
+> 注: 若已有 1 台 T2-L 节点，仅需追加 3 台。V100 SXM 为二手市场/拆机渠道，价格波动大。也可租用云上 V100 实例替代自建集群。
+
+#### T1.2.2 T1-H 多节点-高 — 4 节点 × 4×H100 = 1.28 TB（扩展档）
+
+| 项目 | 规格 | 数量 | 备注 |
+| ------- | ----------------------------------------- | --------- | --------------------- |
+| 计算节点 | 同 T2-H 单机配置 | 4 台 | 每节点 4×H100 80GB SXM5 |
+| 节点内 GPU | NVIDIA H100 80GB SXM5 (NVLink 4 卡全互联) | 16 卡 | NVLink 900 GB/s |
+| 节点内 CPU | AMD EPYC 9654 (96C/192T) 或 Intel Xeon 8468 | 4 | 每节点 1~2 颗 |
+| 节点内内存 | 512GB DDR5-4800 ECC | 4 × 512GB | 每节点 512GB |
+| 节点间互联 | NVIDIA ConnectX-7 NDR 400Gb/s IB | 4~8 卡 | 每节点 1~2 卡 |
+| 节点间交换机 | NDR 400G IB 交换机 (Quantum-2 / SN5600) | 1 | 32 端口 |
+| 存储 | 并行文件系统 (GPFS/Lustre) + 每节点 4TB NVMe | — | 671B 级模型权重池 |
+| 散热 | 机房级液冷 (CDU + 冷板) | — | 风冷不可行 |
+| 电源 | 每节点 4~6 kW 冗余电源 | 4 套 | 集群 ~20~25 kW |
+
+**可运行模型**
+
+| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
+| ------------------------ | ---------- | -------- | ----- | -------------------- |
+| **DeepSeek-V3 / R1-671B** | INT4 (AWQ) | ~400 GB | 3+ | vLLM + Ray / SGLang |
+| **Qwen2.5-72B** | FP16 | ~144 GB | 8+ | vLLM + TensorRT-LLM |
+| LLaMA-3-405B | INT4 | ~230 GB | 5+ | TensorRT-LLM + MPI |
+| Qwen2.5-32B | FP16 | ~64 GB | 20+ | vLLM |
+
+### T1.3 SylixOS 要求（T1 通用）
+
+| 要求项 | 描述 | 风险 |
+| ------------------ | ------------------------------- | ------------------------------ |
+| x86 BSP | 每节点运行 SylixOS x86 LTS | 低（T2-L 已验证） |
+| **RDMA / RoCE 驱动** | ConnectX-6 / ConnectX-7 在 SylixOS 上的 RDMA 驱动 | **中-高**（需验证 Mellanox OFED 兼容性） |
+| NCCL / MPI | 分布式集合通信库在 SylixOS 移植 | 中（NCCL 依赖 CUDA + POSIX） |
+| Ray / 分布式框架 | vLLM + Ray 的 SylixOS 适配 | 中（Python + Ray 依赖链） |
+| 分布式调度器 | SylixOS 跨节点实时任务调度原型 | **研究贡献点** |
+
+### T1.4 研究角度
+
+- **跨节点调度延迟**: 分布式推理时，1ms 实时任务在跨节点 NCCL all-reduce 期间的尾延迟
+- **RDMA bypass 内核**: SylixOS 是否能利用 RDMA bypass kernel path 降低跨节点通信延迟
+- **分布式公平性**: 多节点并发请求时，高优先级实时任务的跨节点响应稳定性
+- **能效**: 分布式推理的每 token 能耗 vs 单节点（通信开销 vs 并行收益）
+- **档位对照**: T1-L 与 T1-H 的**每 token 能耗比**——V100 集群（能效基线）vs H100 集群（能效上限）
+
+---
+
+## T2. 高算力单机部署形态 — 64 G ~ 512 G
+
+### T2.1 定位
+
+单节点多 GPU 大模型推理。验证 SylixOS 在**单机多卡 NVLink 拓扑**下的 GPU 命令调度延迟、显存管理实时性、多模型并发流水线调度。
+
+### T2.2 档位对比
+
+| 维度 | T2-L 单机-低 | T2-M 单机-中 | T2-H 单机-高 |
+| ----------- | ---------------------- | --------------------------- | --------------------------- |
+| **容量** | 128 GB（4 × 32 GB） | 256 GB（8 × 32 GB） | 320 GB（4 × 80 GB） |
+| **加速器** | 4 × V100 32GB SXM | 8 × V100 32GB SXM | 4 × H100 80GB SXM5 |
+| **算力** | 500 TFLOPS (FP16) | 1000 TFLOPS (FP16) | ~4000 TFLOPS (FP16) |
+| **互联** | NVLink 300 GB/s ×4 | NVLink 300 GB/s ×8 | NVLink 900 GB/s ×4 |
+| **整机功耗** | ~1.65 kW | ~3.0~3.3 kW | ~4.5~6.5 kW |
+| **散热架构** | 360 液冷 ×2 + 塔式风道 | 360 液冷 ×2 + 双路风冷 | 强制液冷 (冷板)，风冷不可行 |
+| **电源架构** | 1650W + 1250W 双电源 | 2× 2000W 冗余 / 220V 单相 | 2× 3000W 冗余 / 220V 双相 |
+| **形态** | 塔式一体定制机箱 | 4U 机架式 / 塔式 | 4U~5U 机架式液冷 |
+| **可运行模型** | 72B INT4 / 14B FP16 | 72B FP16 / 多实例 32B | 671B INT4 / 72B FP16 多并发 |
+| **状态** | 现有 | 需扩展（现有平台加卡） | 需 |
+
+#### T2.2.1 T2-L 单机-低 — 4×V100 SXM = 128 GB（现有设备，谱系锚点）
+
+| # | 部件 | 型号 / 规格 | 数量 | 备注 |
+| -- | ------- | ---------------------------------------------- | ----- | --------------------------- |
+| 1 | 主板 | H12D-8D（双路 EPYC 服务器板） | 1 | |
+| 2 | CPU | AMD EPYC 7402 (24C/48T, 2.0-3.2 GHz, TDP 180W) | 1 | |
+| 3 | 硬盘 | 长城 M.2 NVMe 1TB | 1 | 系统盘 |
+| 4 | 内存 | 三星 DDR4-32G-2133 | 4 | 共 128 GB DDR4 |
+| 5 | 散热系统 | 360 一体液冷散热套装 | 2 | 主机 + GPU |
+| 6 | 转接卡 | ROHSTNS-2SXM2-2P54E | 2 | |
+| 7 | 信号线 | V100 32G × 2 | 4 | NVLink 桥接 |
+| 8 | 机箱 | 塔式一体定制机箱 | 1 | |
+| 9 | 主电源 | 长城全模组 1650W | 1 | |
+| 10 | 副电源 | 长城 1250W 全模组 | 1 | SXM 平台用 |
+| 11 | 散热器 | SP3 高性能散热器 | 1 | |
+| 12 | SXM 平台 | 300G NVLink 4 卡直连底板 | 1 | |
+| 13 | **GPU** | **NVIDIA V100 32GB SXM** | **4** | **NVLink 全互联，共 128GB HBM2** |
+
+**显存与算力**
+
+| 指标 | 值 |
+| ---------- | --------------------------- |
+| **总显存** | **128 GB** (4 × 32GB HBM2) |
+| 单卡显存 | 32 GB HBM2 |
+| 单卡 FP16 算力 | 125 TFLOPS |
+| 总算力 (FP16) | ~500 TFLOPS |
+| NVLink 带宽 | 300 GB/s (GPU↔GPU 全互联) |
+| 内存带宽 | DDR4-2133 ~170 GB/s (CPU 侧) |
+| **整机功耗** | **~1650 W** (满载) |
+
+**可运行模型**
+
+| 模型 | 量化 | 显存占用 | 并发实例数 | 推理框架 |
+| ------------------------ | ---------- | ------ | ----- | ------------------- |
+| **Qwen2.5-7B-Instruct** | FP16 | ~14 GB | 8+ | vLLM / TensorRT-LLM |
+| **Qwen2.5-14B-Instruct** | INT4 (AWQ) | ~8 GB | 14+ | vLLM |
+| Qwen2.5-14B | FP16 | ~28 GB | 4 | vLLM |
+| **Qwen2.5-72B-Instruct** | INT4 (AWQ) | ~36 GB | 3 | vLLM (张量并行 TP=4) |
+| LLaMA-3-8B | FP16 | ~16 GB | 7 | vLLM |
+| MiniCPM-V 2.6 | INT4 | ~6 GB | 20+ | llama.cpp |
+| Whisper-Large-v3 | FP16 | ~3 GB | 40+ | faster-whisper |
+
+#### T2.2.2 T2-M 单机-中 — 8×V100 SXM = 256 GB
+
+在 T2-L 平台基础上**加卡扩容**，是「同一代硬件纵向扩展」的对照档位，最贴近现有设备、改造成本最低。
+
+| 项目 | 规格 | 变更点 |
+| --------- | ----------------------------------------------- | ------------------ |
+| **GPU** | NVIDIA V100 32GB SXM **× 8** | 4 → 8 卡 |
+| **SXM 平台** | 300G NVLink **8 卡直连底板** | 更换底板 |
+| **转接卡** | ROHSTNS-2SXM2-2P54E | 2 → 4 |
+| **NVLink** | 全互联 8 卡，300 GB/s | 拓扑扩展 |
+| 主板 / CPU | H12D-8D + EPYC 7402（双路可升级 EPYC 7742 64C） | 建议升双路以喂满 8 卡 |
+| 内存 | 128 GB → **256 GB** DDR4-2133 | 8 卡需更大 pinned memory |
+| 电源 | 2 × 2000W 冗余（或 220V 单相 16A 回路） | 1650W+1250W 不足 |
+| 散热 | 360 液冷 ×2 + 机箱风道强化 | — |
+| **整机功耗** | **~3.0~3.3 kW** | +100% |
+| **总算力** | **~1000 TFLOPS (FP16)** | +100% |
+
+**可运行模型（新增/提升）**
+
+| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
+| ------------------------ | ---------- | ------ | ----- | ------------------ |
+| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 1~2 | TP=8 张量并行，无需量化 |
+| **Qwen2.5-32B-Instruct** | FP16 | ~64 GB | 3+ | TP=4 |
+| DeepSeek-V2-Lite | FP16 | ~31 GB | 8+ | — |
+| Qwen2.5-14B | FP16 | ~28 GB | 9+ | 单卡可容，多实例并发 |
+
+> **备选方案**: 4 × RTX 6000 Ada 48GB = 192 GB，364 TFLOPS (FP16)，整机 ~2.4 kW，风冷即可。优势是无 NVLink 但单卡能效高、显存快；劣势是跨卡走 PCIe Gen5。
+
+#### T2.2.3 T2-H 单机-高 — 4×H100 SXM5 = 320 GB
+
+| 项目 | 规格 |
+| ------- | ---------------------------------------- |
+| **GPU** | NVIDIA H100 80GB SXM5 **× 4**（NVLink 全互联） |
+| 单卡算力 | ~989 TFLOPS (FP16 Tensor Core, dense) |
+| 单卡显存 | 80 GB HBM3 |
+| NVLink | 900 GB/s (GPU↔GPU) |
+| CPU | AMD EPYC 9654 (96C/192T) ×1~2 |
+| 内存 | 512 GB DDR5-4800 ECC |
+| 底板 | HGX H100 4-GPU 或 8-GPU 底板（留 4 卡空位） |
+| 存储 | 4 TB NVMe RAID0（模型权重加载） |
+| 散热 | **强制液冷（冷板式）**，风冷不可行 |
+| 电源 | 2 × 3000W 冗余 / 220V |
+| **整机功耗** | **~4.5~6.5 kW** |
+| **总算力** | **~4000 TFLOPS (FP16)**，稀疏 ~8000 TFLOPS |
+
+**备选方案**: 8 × RTX 6000 Ada 48GB = 384 GB，728 TFLOPS (FP16)，~4.0 kW，风冷可行——容量更大、功耗更低，代价是无 NVLink 与算力密度。
+
+**可运行模型（新增/提升）**
+
+| 模型 | 量化 | 显存占用 | 并发实例数 | 说明 |
+| ------------------------ | ---------- | ------- | ----- | ----------------- |
+| **Qwen2.5-72B-Instruct** | FP16 | ~144 GB | 2 | TP=4，H100 下 TTFT 极低 |
+| LLaMA-3-70B | FP16 | ~140 GB | 2 | — |
+| **DeepSeek-V2-Chat** | FP16 | ~210 GB | 1 | 单机可跑 |
+| Mixtral-8x7B | FP16 | ~93 GB | 3 | MoE 专家并行 |
+
+### T2.3 SylixOS 要求（T2 三档通用）
+
+| 要求项 | 描述 | 风险 |
+| ----------------- | ----------------------------- | ------------------- |
+| x86 BSP | SylixOS 2.x LTS x86 | 低 |
+| **CUDA 驱动** | V100 SXM / H100 SXM 在 SylixOS 的 CUDA 驱动 | **中**（需翼辉确认） |
+| NVLink 支持 | 4 卡 / 8 卡 NVLink 拓扑在 SylixOS 可用 | 中 |
+| vLLM / llama.cpp | Python + CUDA 推理框架适配 | 中（llama.cpp 优先，依赖少） |
+| nvidia-smi / DCGM | GPU 监控 + 功耗采集 | 低 |
+| 8 卡 / 4 卡拓扑切换 | 同一 BSP 支持 T2-L/M/H 不同卡数 | 低（设备树 + 枚举） |
+
+### T2.4 对照组 OS
+
+- **主对照**: Ubuntu 22.04 LTS + `linux-image-rt` (PREEMPT_RT) + vLLM
+- **辅助对照**: CentOS Stream 9 + RT 内核（可选）
+
+---
+
+## T3. 边缘节点场景 — 32 G ~ 64 G / 48 G 独显
+
+### T3.1 定位
+
+边缘节点位于设备本体之外、云端之前，承担近源推理、数据汇聚和多设备协同。
+它是部署在设备附近的独立节点，承担近源推理、数据汇聚和多设备协同。
+
+### T3.2 代表档位对比
+
+| 维度 | T3-L 边缘节点代表档 |
+| --------- | ---------------- |
+| **容量** | 64 GB 统一内存 / 48 GB 独立显存 |
+| **加速器** | Jetson AGX Orin 64GB / RTX 6000 Ada 48GB |
+| **算力** | 275 TOPS (INT8) / 91 TFLOPS (FP16) |
+| **功耗** | 15~60 W / ~600 W |
+| **部署位置** | 设备附近机柜、边缘控制室、产线边缘节点 |
+| **主要任务** | 多模态推理、近源协同、边缘缓存与调度 |
+
+### T3.3 候选平台
+
+- Jetson AGX Orin 64GB：统一内存、能效高，适合近设备部署；
+- 边缘工控机 + RTX 6000 Ada 48GB：生态完整，适合边缘机柜和算力下沉场景。
+
+### T3.4 研究重点
+
+- 设备端到边缘节点的协同调度；
+- 近源多任务并发下的实时隔离；
+- 边缘节点与桌面/工作站单机在功耗、散热和部署约束上的边界。
+
+---
+
+## T4. 设备端 SoC 场景 — 8 G ~ 32 G
+
+### T4.1 定位
+
+设备端 SoC 直接运行在终端设备本体上。验证 SylixOS 在**统一内存架构**（CPU+加速器共享 LPDDR）下的实时性，即推理任务与实时控制任务共享本机资源时的隔离能力。
+
+### T4.2 档位对比
+
+| 维度 | T4-L SoC-低 | T4-M SoC-中 |
+| --------- | ---------------------------- | -------------------------- |
+| **容量** | 16 GB 统一内存 | 32 GB 统一内存 |
+| **加速器** | RK3588 NPU 6+26 TOPS / Ampere | Ampere GPU + 2×DLA |
+| **算力** | 32 TOPS / 100 TOPS (INT8) | 275 TOPS (INT8) |
+| **功耗** | 10~30 W | 15~60 W |
+| **供电架构** | DC 12~24 V，无风扇/小风扇 | DC 19 V，主动风冷 |
+| **工作温度** | -40~60 ℃ 工业级 | -25~80 ℃ |
+| **SylixOS 风险** | **极低**（RK3588 BSP 复用 T5） | **高**（T234 BSP 需验证） |
+| **状态** | （RK3588 16GB 工业盒） | 待验证 |
+
+#### T4.2.1 T4-L SoC-低 — RK3588 16GB 工业盒（现有设备）
+
+**这是现有 RK3588 设备的标准归属档位**，也是唯一可零成本立即开展研究的设备端 SoC 档位。
+
+| 项目 | 规格 | 备注 |
+| --------- | --------------------------------------- | --------------------- |
+| SoC | Rockchip RK3588（同 T5-H） | SylixOS BSP 与 T5 共用 |
+| 内存 | **16 GB LPDDR4X**（统一内存） | -40~60 ℃ 工业宽温 |
+| NPU | 6 TOPS 原生 + **26 TOPS 算力棒扩展 = 32 TOPS** | 算力棒走 M.2 2280 |
+| 功耗 | ~21~30 W（含算力棒） | 被动散热，可选小风扇 |
+| 内存带宽 | ~51.2 GB/s (128-bit LPDDR4X) | 与 T5-H 同源，是带宽瓶颈点 |
+| 模型 | Qwen2.5-3B/7B INT4（RKLLM） | 比 T5-H 内存翻倍，可跑更大模型 |
+
+**备选方案（同档位、CUDA 路线）**: NVIDIA Jetson Orin NX 16GB — 100 TOPS (INT8, sparse)，1024 CUDA + 32 Tensor Core，16 GB LPDDR5 / 102.4 GB/s，10~25 W，**CUDA 生态与 T1/T2/T3 打通**。代价是 SylixOS T234 BSP 风险高。
+
+#### T4.2.2 T4-M SoC-中 — NVIDIA Jetson AGX Orin 32GB
+
+| 项目 | 规格 |
+| --------- | -------------------------------------------------- |
+| **SoC** | NVIDIA T234（Grace 系列衍生） |
+| **CPU** | 12× ARM Cortex-A78AE @ 2.0 GHz（64-bit） |
+| **GPU** | NVIDIA Ampere 架构，2048 CUDA cores + 64 Tensor cores |
+| **DLA** | 2× DLA v2.0（深度学习加速器，可异步推理） |
+| **AI 算力** | **275 TOPS** (INT8) / 137.5 TOPS (INT8+INT8 双精度) |
+| **内存** | **32 GB LPDDR5**（统一内存，CPU/GPU 共享） |
+| 内存带宽 | 204.8 GB/s |
+| **功耗** | **15 W ~ 60 W**（可配置功率模式：15W/30W/50W/60W） |
+| 工作温度 | -25 ~ 80°C（工业级，但不如 RK3588 的 -40~60°C 宽） |
+| 存储 | 64GB eMMC + M.2 NVMe（可扩展） |
+| 网络 | 2× 10GbE（RJ45）+ 1× 千兆 |
+| 视频接口 | HDMI 2.1 + DP 1.4a |
+| USB | 4× USB 3.2 + 2× USB 2.0 |
+| PCIe | PCIe Gen4 ×4（可扩展外设） |
+| MIPI CSI | 4 通道（可接工业相机） |
+| 尺寸 | 100mm × 87mm（核心模块） |
+| **出厂 OS** | Ubuntu 20.04 LTS (L4T) |
+| 价格 | ~$2,000-4,000（~15,000-28,000 RMB） |
+
+**选择 Jetson AGX Orin 的理由**
+
+1. **CUDA 生态统一**: 与 T1/T2 同为 NVIDIA GPU，vLLM / TensorRT / llama.cpp 可直接移植，无需切换到 RKLLM 栈
+2. **统一内存架构**: CPU 和 GPU 共享 32GB LPDDR5，无独立显存——LLM 推理和实时控制任务**争抢同一内存带宽**，是验证内存带宽管控（RQ2）的理想平台
+3. **DLA 异步推理**: 2 个 DLA 可在 GPU/CPU 不介入时执行推理，适合"LLM 推理让出 CPU/GPU 给实时任务"的调度策略验证
+4. **功率可配置**: 15W/30W/50W/60W 多档功率模式，可在不同功耗预算下测试
+5. **丰富 I/O**: 10GbE + MIPI CSI + PCIe Gen4，可接工业相机、高速网络、扩展卡
+
+#### T3 边缘节点候选平台
+
+64 GB 统一内存 Jetson AGX Orin 与 48 GB 独显边缘工控机统一归入 `T3 边缘节点场景`。
+
+**可运行模型（T4 两档合并）**
+
+| 模型 | 量化 | 显存占用 | 预期 tokens/s | 适用档位 | 推理框架 |
+| ------------------------ | ------------ | ------- | ----------- | ------------- | ------------------------ |
+| **Qwen2.5-1.5B-Instruct** | INT4 | ~1.2 GB | ~40-60 | T4-L | RKLLM |
+| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~50-80 | T4-L / T4-M | TensorRT-LLM / RKLLM |
+| **Qwen2.5-7B-Instruct** | INT4 (W4A16) | ~5 GB | ~30-50 | T4-L / T4-M | TensorRT-LLM / llama.cpp |
+| **Qwen2.5-14B-Instruct** | INT4 | ~8 GB | ~20-35 | T4-M | TensorRT-LLM |
+| **Qwen2.5-32B-Instruct** | INT4 | ~18 GB | ~12-20 | T4-M | TensorRT-LLM |
+| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | T4-L 以上 | llama.cpp |
+| Whisper-Large-v3 | INT8/FP16 | ~1.5 GB | 流式 ASR | T4-L 以上 | faster-whisper |
+| YOLOv8n | INT8 | ~0.1 GB | 200+ FPS | T4 全档 | TensorRT / RKNN |
+
+### T4.3 SylixOS 要求（T4）
+
+| 要求项 | 描述 | 风险 |
+| -------------------- | --------------------------------------- | ---------------------------- |
+| **ARM64 BSP (T234)** | SylixOS 需提供 NVIDIA T234 SoC 的 ARM64 BSP | **高**（需翼辉确认是否支持 Jetson Orin） |
+| **RK3588 BSP（T4-L）** | 与 T5-H 共用同一 BSP，零额外风险 | **极低** |
+| CUDA 驱动 | Jetson 专用 CUDA（L4T 驱动栈）在 SylixOS 适配 | 高 |
+| DLA 驱动 | DLA 异步推理在 SylixOS 的可用性 | 高 |
+| 功率模式 API | 15W/30W/50W/60W 切换在 SylixOS 的实现 | 中 |
+| 内存监控 | 统一内存架构下的内存带宽监控（PMU 计数器） | 中 |
+| 独立显存管理（T3 B 路线） | x86 + 独显的显存分配与实时性 | 中 |
+
+> **当前路径**：T4-L 采用现有 RK3588 起步；T4-M 在 Jetson BSP 与驱动条件确认后纳入采购与验证计划。
+
+### T4.4 对照组 OS
+
+| 档位 | 主对照 | 辅助对照 |
+| ---- | -------------------------------- | ----------------------------- |
+| T4-L | Ubuntu 22.04 + PREEMPT_RT（RK3588） | OpenHarmony 4.x + RT patch（可选） |
+| T4-M | Ubuntu 20.04 LTS (L4T) + PREEMPT_RT | Ubuntu 22.04 + Docker（容器隔离方案） |
+
+### T4.5 功率采集
+
+| 设备 | 用途 | 适用档位 |
+| ----------------------------- | --------------------- | ----------- |
+| DC 功率计（USB 接口型） | 整机 DC 输入端功耗 | T4-L / T4-M |
+| INA226 采集板 | SoC 主电源轨（若可接入） | 全档 |
+| `jetson_stats` / tegrastats | 内部功耗代理（辅助，非主报） | T4-M / T3-L |
+| 交流功率计（PZEM / 智能插座） | 边缘工控机整机功耗 | T3-L B 路线 |
+
+---
+
+## T5. 控制端场景 — 1 G ~ 8 G
+
+### T5.1 定位
+
+工业端点超低功耗 LLM 推理与硬实时控制。验证 SylixOS 在**极致资源约束**（3~21 W / 1~8 GB / 0.8~32 TOPS）下的 LLM + 1ms 实时控制并发能力。这一场景能够充分暴露实时调度、隔离与准入机制的有效性，也是 RTOS 与普通 Linux / PREEMPT_RT Linux 差异最容易被观察到的重要验证位置。
+
+### T5.2 档位对比
+
+| 维度 | T5-L 控制端-低 | T5-M 控制端-中 | T5-H 控制端-高 |
+| ----------- | ---------------------- | -------------------- | ------------------------------ |
+| **容量** | 1~2 GB LPDDR4X | 2~4 GB LPDDR5 | 4~8 GB LPDDR4X / LPDDR5 |
+| **SoC** | RK3568 (4×A55) | RK3576 (4×A72+4×A53) | RK3588 (4×A76+4×A55+M0) / Orin Nano |
+| **NPU 算力** | 0.8~1 TOPS (INT8) | 6 TOPS (INT8) | 6~32 TOPS / 40~67 TOPS (INT8) |
+| **功耗** | 3~5 W | 5~10 W | 7~21 W |
+| **散热架构** | 无风扇被动 | 无风扇被动 | 无风扇被动（可选小风扇） |
+| **供电** | DC 5V / 12V | DC 12V | DC 12V |
+| **工作温度** | -40~85 ℃ 工业级 | -40~85 ℃ 工业级 | -40~60 ℃ / 0~50 ℃ |
+| **可运行模型** | 0.5B INT4 / Whisper-Tiny | 1.5B INT4 / YOLO 系列 | 3B~7B INT4 / MiniCPM-V |
+| **状态** | | | ✅ 现有（RK3588 16GB 降配） |
+
+#### T5.2.1 T5-L 控制端-低 — RK3568 核心板（1~2 GB）
+
+| 项目 | 规格 |
+| --------- | -------------------------------------- |
+| SoC | Rockchip RK3568 (22nm) |
+| CPU | 4× Cortex-A55 @ 2.0 GHz |
+| **NPU** | **0.8~1 TOPS (INT8)**（RKNN 原生栈） |
+| **内存** | **1~2 GB LPDDR4X**（统一内存，板贴） |
+| 内存带宽 | ~25.6 GB/s |
+| GPU | Mali-G52（仅辅助显示） |
+| 存储 | 8~16 GB eMMC |
+| 网络 | 1× 千兆 + 可选 WiFi |
+| 工业接口 | CAN ×2 / RS485 ×2 / GPIO（典型核心板引出） |
+| **功耗** | **3~5 W**（无风扇被动散热） |
+| 工作温度 | -40 ~ 85 ℃ 工业级 |
+| 出厂 OS | Buildroot / Ubuntu 20.04（可换 SylixOS） |
+| 参考价格 | ~300~800 RMB（核心板/开发板） |
+
+**可运行模型**: Qwen2.5-0.5B INT4（~0.5 GB）、Whisper-Tiny INT8（~0.2 GB）、YOLOv5n INT8。
+**定位价值**: 谱系最低档，用于测量极小资源预算下的实时保障下界、容量边界，以及 RTOS 在极小内存条件下维持 1 ms 周期任务的能力。
+
+#### T5.2.2 T5-M 控制端-中 — RK3576 核心板（2~4 GB）
+
+| 项目 | 规格 |
+| --------- | ---------------------------------------- |
+| SoC | Rockchip RK3576 (8nm) |
+| CPU | 4× Cortex-A72 + 4× Cortex-A53（异构大小核） |
+| **NPU** | **6 TOPS (INT8)** + 可扩展算力棒 |
+| **内存** | **2~4 GB LPDDR5**（统一内存） |
+| 内存带宽 | ~40 GB/s |
+| **功耗** | **5~10 W**（无风扇被动） |
+| 工作温度 | -40 ~ 85 ℃ 工业级 |
+| 参考价格 | ~600~1,500 RMB |
+
+**可运行模型**: Qwen2.5-1.5B INT4（~1.2 GB，~15-25 tok/s）、Qwen2.5-0.5B INT4 多实例、YOLOv8s INT8。
+**定位价值**: 控制端主力档，算力是 T5-L 的 6 倍而功耗仅翻倍，是**能效拐点**档位。
+
+#### T5.2.3 T5-H 控制端-高 — RK3588 8GB（现有设备降配）/ Jetson Orin Nano 8GB
+
+**路线 A（现有设备，零成本）: RK3588 工业盒 8GB 配置**
+
+| 项目 | 规格 | 说明 |
+| --------- | --------------------------------------------------- | ------------------------ |
+| SoC | Rockchip RK3588 (8nm) | 与现有 16GB 工业盒**同板同 BSP** |
+| CPU | 4×A76 @2.4 GHz + 4×A55 @1.8 GHz | 异构大小核 |
+| MCU | Cortex-M0 @200 MHz（协处理，可选） | 跨核通信验证 |
+| GPU | Mali-G610 MC4 | 仅辅助显示 |
+| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） | 两档可切换 |
+| **内存** | **4~8 GB LPDDR4X**（统一内存） | 现有 16GB 板通过**内存分区限额**降配运行 |
+| 内存带宽 | ~51.2 GB/s (128-bit) | 与 T4-L 同 |
+| **功耗** | **7~21 W**（无风扇被动散热） | 6 TOPS 档 ~12W / 32 TOPS 档 ~21W |
+| 工作温度 | -40 ~ 60 ℃ 工业级 | 宽温优势 |
+| 出厂 OS | Ubuntu 22.04 | 换 SylixOS BSP |
+
+> **现有 16GB 工业盒的双档位用法**: 同一台设备既可作为 **T4-L（16 GB 全量）** 也可作为 **T5-H（分区限额 8 GB）** 运行，通过 SylixOS 内存分区 / cgroup 限额切换，一台设备覆盖两个档位的对照实验，是本方案的成本关键。
+
+**路线 B（CUDA 生态）: NVIDIA Jetson Orin Nano 8GB**
+
+| 项目 | 规格 |
+| --------- | --------------------------------------------------- |
+| SoC | NVIDIA T234（Ampere 1024 CUDA + 32 Tensor Core） |
+| **AI 算力** | **40 TOPS (INT8, 稀疏)**（Super 模式 67 TOPS） |
+| **内存** | **8 GB LPDDR5**（统一内存，102.4 GB/s） |
+| **功耗** | **7~25 W**（可配置 7W/15W/25W） |
+| 优势 | **T5 档内唯一 CUDA 路线**，TensorRT-LLM 与 T1/T2/T3/T4 同栈 |
+| 劣势 | SylixOS T234 BSP 风险高，宽温不如 RK3588 |
+| 参考价格 | ~$249（开发套件） |
+
+**可运行模型（T5-H）**
+
+| 模型 | 量化 | 显存占用 | 预期 tokens/s | 推理框架 |
+| ------------------------- | ---- | ------- | ----------- | ----- |
+| **Qwen2.5-3B-Instruct** | INT4 | ~2.5 GB | ~40-60 | RKLLM |
+| **Qwen2.5-7B-Instruct** | INT4 | ~5 GB | ~20-30 | RKLLM |
+| MiniCPM-V 2.6 | INT4 | ~6 GB | ~15-25 | RKLLM |
+| Whisper-Large-v3 | INT8 | ~1.5 GB | 流式 ASR | RKLLM |
+
+#### T5.2.4 硬件配置明细（RK3588 工业级边缘计算盒子，现有设备）
+
+**系统 (System)**
+
+| 项目 | 规格 |
+| ------- | ---------------------------------------------------- |
+| SoC | Rockchip RK3588 (8nm) |
+| CPU | 4×Cortex-A76 @2.4 GHz + 4×Cortex-A55 @1.8 GHz（异构大小核） |
+| MCU | Cortex-M0 @200 MHz（协处理，可选） |
+| GPU | Mali-G610 MC4 |
+| **NPU** | **6 TOPS**（内置, INT8）/ **32 TOPS**（板贴 26 TOPS 算力芯片扩展） |
+| **内存** | **16 GB LPDDR4X**（板贴，不可升级）→ 可按 8 GB 分区用作 T5-H |
+| **显存** | 统一内存（NPU 与 CPU 共享） |
+
+**存储 / 扩展**
+
+- EMMC 64 GB（系统盘）
+- 1× TF 卡槽（存储扩展）
+- 1× M.2 2280 NVMe（可扩展 SSD / 算力棒）
+
+**出厂软件**
+
+- 操作系统: **Ubuntu 22.04**（出厂预装）
+- 运行方案: SylixOS BSP for RK3588 + Ubuntu 22.04 对照组
+
+**算力与功耗（T5-H 档）**
+
+| 指标 | 值 |
+| ------------------ | ------------------------------- |
+| **可用显存** | **8 GB**（16 GB 板分区限额） |
+| NPU 算力 (6 TOPS 档) | 6 TOPS (INT8) |
+| NPU 算力 (32 TOPS 档) | 32 TOPS (INT8, 含 26 TOPS 扩展) |
+| GPU 算力 | Mali-G610 MC4（仅辅助，非主推理路径） |
+| 内存带宽 | LPDDR4X ~51.2 GB/s (128-bit) |
+| **TDP** | **7~21 W**（无风扇被动散热） |
+
+### T5.3 SylixOS 要求（T5）
+
+| 要求项 | 描述 | 风险 | 适用档位 |
+| ---------------------- | --------------------------------------- | -------------------- | --------- |
+| **RK3588 BSP** | SylixOS BSP for RK3588（A76+A55 大小核 SMP） | 中（需翼辉提供） | T5-H |
+| **RK3576 BSP** | SylixOS BSP for RK3576 | 中-高（需翼辉确认） | T5-M |
+| **RK3568 BSP** | SylixOS BSP for RK3568 | 中（RK3568 生态成熟，风险低于 T234） | T5-L |
+| **rknn / RKLLM 驱动** | NPU 驱动在 SylixOS 移植 | **高**（平台B 模型适配核心风险） | T5 全档 |
+| 板贴 26 TOPS 算力芯片驱动 | 算力棒 SDK | 高（厂商支持度） | T5-H |
+| M0 核 BSP + RPMsg | 跨核通信 | 高（需翼辉 + 板卡引出 M0 调试口） | T5-H |
+| **内存分区限额机制** | 16 GB 板按 8 GB 分区运行（T4-L/T5-H 切换） | 中（需 SylixOS 内存域支持） | T5-H |
+| CAN ×2 驱动 | 工业现场总线 | 中 | T5 全档 |
+| RS485 ×2 + RS232 ×1 | 串口 | 低 | T5 全档 |
+| 双千兆 + WiFi + 4G/5G | 网络 | 中 | T5-H |
+| 看门狗 / RTC | 工业可靠性 | 低 | T5 全档 |
+| Jetson Orin Nano BSP | T234 低配版 BSP（路线 B） | 高 | T5-H 路线B |
+
+### T5.4 对照组 OS
+
+- **主对照**: Ubuntu 22.04（RK3588 出厂预装，完美匹配，直接对照）
+- **辅助对照**: OpenHarmony 4.x + RT patch（可选）
+- T5-L / T5-M: Buildroot + PREEMPT_RT
+
+---
+
+## 5. 跨档位对比总表
+
+### 5.1 全档位硬件规格对比
+
+| 档位 | 容量 | 算力 | 功耗 | 加速器架构 | 散热架构 | 互联 | SylixOS BSP 风险 |
+| -------- | ---------- | ------------------- | ----------- | ------------------ | ----------- | ---------------- | ------------- |
+| **T5-L** | 1~2 GB | 0.8~1 TOPS | 3~5 W | ARM A55 + NPU | 被动无风扇 | GPIO/CAN/RS485 | 中 |
+| **T5-M** | 2~4 GB | 6 TOPS | 5~10 W | ARM A72+A53 + NPU | 被动无风扇 | 千兆 + CAN | 中-高 |
+| **T5-H** | 4~8 GB | 6~32 TOPS | 7~21 W | ARM A76+A55+M0+NPU | 被动无风扇 | 双千兆 + CAN + M.2 | 中 / 高（路线B） |
+| **T4-L** | 8~16 GB | 32~100 TOPS | 10~30 W | ARM 统一内存 + NPU/GPU | 被动/小风扇 | 双千兆 + M.2 | **极低**（现有） |
+| **T4-M** | 16~32 GB | 275 TOPS | 15~60 W | A78AE + Ampere + DLA | 主动风冷 | 10GbE + PCIe Gen4 | **高** |
+| **T3-L** | 32~64 GB / 48 GB 独显 | 275 TOPS / 91 TFLOPS | 60~600 W | ARM 统一内存 / x86+独显 | 风冷 / 液冷 | 10GbE + PCIe | 高 / 中 |
+| **T2-L** | 64~128 GB | 500 TFLOPS (FP16) | ~1.65 kW | x86 + 4×V100 NVLink | 360 液冷 + 风道 | NVLink | 低（现有） |
+| **T2-M** | 128~256 GB | 1000 TFLOPS (FP16) | ~3.0~3.3 kW | x86 + 8×V100 NVLink | 360 液冷 + 风道 | NVLink | 低 |
+| **T2-H** | 256~512 GB | ~4000 TFLOPS (FP16) | ~4.5~6.5 kW | x86 + 4×H100 NVLink | 强制液冷 | NVLink + PCIe | 中 |
+| **T1-L** | 512 GB~1 T | ~2000 TFLOPS (FP16) | ~6.6 kW | 4 节点 × 4×V100 | 机房风冷 + 液冷 | NVLink + 100GbE | 中-高 |
+| **T1-H** | 1~2 T | ~16 PFLOPS (FP16) | ~20~25 kW | 4 节点 × 4×H100 | 机房级液冷 | NVLink + NDR 400G | 中-高 |
+
+### 5.2 模型规模梯度
+
+| 档位 | 代表模型 | 量化 | 显存占用 | 角色 |
+| -------- | --------------------------- | ---------- | ------- | -------------- |
+| T5-L | Qwen2.5-0.5B / Whisper-Tiny | INT4/INT8 | 0.5 GB | 控制端最低资源参考档，实时性基准 |
+| T5-M | Qwen2.5-1.5B | INT4 | 1.2 GB | 控制端能效拐点 |
+| T5-H | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 端点可跑 7B |
+| T4-L | Qwen2.5-3B / 7B | INT4 | 2.5 / 5 GB | 设备端推理 + 工业控制 |
+| T4-M | Qwen2.5-14B / 32B | INT4 | 8 / 18 GB | 设备端多模型并发 |
+| T3-L | Qwen2.5-72B | INT4 (AWQ) | 36 GB | 边缘节点可跑 72B |
+| T2-L | Qwen2.5-72B / 14B | INT4 / FP16 | 36 / 28 GB | 桌面多模型并发 |
+| T2-M | Qwen2.5-72B | FP16 | 144 GB | 桌面单机无量化 72B |
+| T2-H | DeepSeek-V2 / 72B | FP16 | 210 / 144 GB | 桌面单机超大模型 |
+| T1-L | Qwen2.5-72B / DeepSeek-V2 | FP16 | 144 / 210 GB | 多节点分布式推理 |
+| T1-H | DeepSeek-V3/R1 671B | INT4 | ~400 GB | 超大模型分布式服务 |
+
+### 5.3 SylixOS 调度框架验证重点
+
+| 档位 | 验证重点 | 核心实时指标 | 核心吞吐指标 |
+| ----- | ----------- | ---------------------------------- | -------------------------- |
+| T5-L | 极小内存下保持关键保障负载边界 | 1ms RT 任务延迟（1GB 内存约束下） | 0.5B tokens/s、内存占用上限 |
+| T5-M | 能效拐点 | 1ms RT 任务 P99.9、CPU 频率调节影响 | 1.5B tokens/s、E_per_token |
+| T5-H | 极致资源约束下保持关键保障负载边界 | **1ms RT 任务最大延迟 + CAN/RS485 延迟** | 3B/7B tokens/s、E_per_token |
+| T4-L | 统一内存带宽隔离（NPU） | NPU 推理 + 实时任务共享 51.2 GB/s 带宽时 RT 抖动 | 7B INT4 tokens/s |
+| T4-M | 统一内存带宽隔离（GPU） | LLM+RT 共享内存带宽时 RT 任务 P99.9 | 14B tokens/s、DLA 异步收益 |
+| T3-L | 大容量边缘并发 | 72B 推理与 RT 任务共存时的优先级反转 | 72B INT4 tokens/s、多模型 QPS |
+| T2-L | 单机多卡 NVLink 调度 | GPU 命令端到端延迟、多模型并发公平性 | 14B/72B tokens/s、TTFT P99.9 |
+| T2-M | 8 卡拓扑调度 | 8 卡 NVLink 全互联下的集合通信抖动 | 72B FP16 tokens/s |
+| T2-H | 高算力密度下的隔离 | H100 满负载时 RT 任务 P99.9 | 72B FP16 TTFT、671B 分片吞吐 |
+| T1-L | 跨节点分布式调度隔离 | RDMA 延迟、NCCL all-reduce 期间 RT 任务抖动 | 72B 模型 tokens/s、多模型 QPS |
+| T1-H | 超大规模分布式调度 | NDR IB 延迟、671B 推理期间 RT 抖动 | 671B tokens/s、能效比 |
+
+### 5.4 基线 OS 对照
+
+| 档位 | SylixOS 实验组 | 主对照 (PREEMPT_RT Linux) | 虚拟化对照 | 容器对照 |
+| ------- | ---------------------- | --------------------- | -------------- | --------- |
+| T5-L | SylixOS ARM64 (RK3568) | Buildroot + RT | — | Docker |
+| T5-M | SylixOS ARM64 (RK3576) | Buildroot + RT | — | Docker |
+| T5-H | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
+| T4-L | SylixOS ARM64 (RK3588) | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
+| T4-M | SylixOS ARM64 (T234) | L4T Ubuntu 20.04 + RT | KVM (RT VM) | Docker |
+| T3-L | SylixOS ARM64 / x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
+| T2-L/M | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
+| T2-H | SylixOS x86 | Ubuntu 22.04 + RT | KVM (RT VM) | Docker |
+| T1-L | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
+| T1-H | SylixOS x86 ×4 节点 | Ubuntu 22.04 + RT ×4 | KVM (RT VM) ×4 | Docker ×4 |
+
+---
+
+## 6. 采购与获取计划
+
+| 优先级 | 档位 | 设备 | 估算费用 (RMB) | 备注 |
+| ------ | ------- | ----------------------------- | -------------------- | ---------------------- |
+| **P0** | T4-L | **RK3588 16GB 工业盒**（现有） | **0** | 现有设备，立即可用 |
+| **P0** | T2-L | **4×V100 SXM 塔式整机**（现有） | **0** | 现有设备，谱系锚点 |
+| **P0** | T5-H | **RK3588 工业盒 8GB 分区**（现有） | **0** | 与 T4-L 同机双档位 |
+| **P1** | T5-L | RK3568 1~2GB 核心板 | ~300-800 | 控制端最低资源参考档，必做 |
+| **P1** | T5-M | RK3576 4GB 核心板 | ~600-1,500 | 控制端能效拐点 |
+| **P1** | T4-M | Jetson AGX Orin 32GB | ~15,000-28,000 | 需尽早确认 SylixOS T234 BSP |
+| **P2** | T4-M 备选 | RK3588 32GB 工业盒 + 26 TOPS 算力棒 | ~3,000-5,000 | 若 Jetson BSP 不支持 |
+| **P2** | T3-L | Jetson AGX Orin 64GB | ~30,000-50,000 | 边缘节点可跑 72B |
+| **P2** | T5-H 备选 | Jetson Orin Nano 8GB 开发套件 | ~1,800-2,500 | CUDA 路线对照 |
+| **P3** | T2-M | 4× V100 32GB SXM + 8 卡底板 + 电源 | ~70,000-100,000 | 现有平台加卡扩容 |
+| **P3** | T2-H | 4× H100 80GB SXM5 工作站 | ~800,000-1,200,000 | 可租云实例替代 |
+| **P3** | T1-L | 3× 计算节点 + 12× V100 + IB | ~270,000 | 可用云实例替代 |
+| **P4** | T1-H | 4 节点 × 4×H100 + NDR IB | ~3,000,000+ | 强烈建议云租替代 |
+| — | 仪器 | DC 功率计 ×2 (T4+T5) | ~6,000 | T5 强制 |
+| — | 仪器 | INA226 采集板 ×2 | ~500 | T4+T5 |
+| — | 仪器 | 交流功率计 / 智能插座 | ~1,000 | T3 / T2 档 |
+| — | 仪器 | 示波器 (Tektronix MDO34) | ~30,000 | GPIO 环回延迟（可借用） |
+| — | 仪器 | 红外测温枪 ×2 | ~1,000 | 被动散热档位 |
+| — | 仪器 | CANalyzer | ~20,000 | T4 CAN 总线延迟（可借用） |
+| **合计** | | **P0~P2 必做项** | **~55,000-95,000** | 不含 T1/T2 扩展 |
+
+### 降本策略
+
+1. **P0 零成本起步**: T2-L + T4-L + T5-H 三个档位由现有硬件直接覆盖，可立即启动 SylixOS 适配与基线数据采集，无需等待采购。
+2. **一机两档**: RK3588 16GB 工业盒通过内存分区同时充当 T4-L（16 GB）与 T5-H（8 GB），省去一台设备与一套 BSP 验证成本。
+3. **档位跳跃验证**: 若某档位 SylixOS BSP 不可行，可直接跳过该档（如 T5-M 若 RK3576 BSP 不可用，用 T5-H 降配替代），谱系不断。
+4. **T1/T2-H 云替代**: H100 集群强烈建议租用云实例（阿里云 GN7 / AWS p5），按需付费，避免百万级 CAPEX 与机房改造。
+5. **T4-M Jetson**: 可先用 NVIDIA 开发者板（约 $2,000）验证 SylixOS BSP 可行性后再采购工业级版本。
+6. **仪器借用**: 示波器和 CANalyzer 可从实验室借用，不必专门采购。
+
+---
+
+## 7. SylixOS BSP 适配 Checklist（跨档位汇总）
+
+### 7.1 x86 BSP（T2 全档 + T1 全档）
+
+- [ ] SylixOS 2.x LTS x86 在 H12D-8D 主板可启动
+- [ ] AMD EPYC 7402 / 9654 多核 SMP 调度
+- [ ] **4× V100 SXM CUDA 驱动**（T2-L，核心）
+- [ ] **8× V100 SXM CUDA 驱动 + 8 卡拓扑**（T2-M）
+- [ ] **4× H100 SXM5 CUDA 驱动 + NVLink 900GB/s**（T2-H）
+- [ ] NVLink 4 卡 / 8 卡全互联拓扑枚举
+- [ ] nvidia-smi / DCGM 监控
+- [ ] vLLM / llama.cpp 在 SylixOS x86 编译运行
+- [ ] **Mellanox ConnectX-6 RDMA 驱动**（T1-L 专属）
+- [ ] **ConnectX-7 NDR 400G RDMA 驱动**（T1-H 专属）
+- [ ] NCCL / MPI 分布式通信库（T1 专属）
+- [ ] IPMI / BMC 功耗采集
+- [ ] tickless + CPU 隔离 + 中断亲和性
+- [ ] 高功耗档位热管理（H100 液冷温度阈值联动降频）
+
+### 7.2 ARM64 BSP — T234 / Ampere（T4-M / T3-L-A / T5-H 路线B）
+
+- [ ] **SylixOS ARM64 在 NVIDIA T234 SoC 可启动**（核心，需翼辉确认）
+- [ ] 12× Cortex-A78AE SMP 调度（AGX Orin）/ 6× A78AE（Orin NX / Nano）
+- [ ] Jetson Ampere GPU CUDA 驱动
+- [ ] **DLA v2.0 驱动**（异步推理，AGX Orin 专属）
+- [ ] 16/32/64 GB LPDDR5 统一内存管理
+- [ ] 功率模式切换 API (7W/15W/25W/30W/50W/60W)
+- [ ] 10GbE 网络驱动
+- [ ] MIPI CSI 工业相机接口
+- [ ] PCIe Gen4 扩展
+- [ ] 温度传感器 + 降频阈值
+
+### 7.3 ARM64 BSP — RK3588（T5-H / T4-L）
+
+- [ ] SylixOS BSP for RK3588（A76+A55 大小核 SMP）
+- [ ] CPU 频率独立调节 (governor)
+- [ ] **内存分区限额机制**（16 GB 板按 8 GB 运行，T4-L ↔ T5-H 切换）
+- [ ] tickless / idle hook
+- [ ] 看门狗驱动
+- [ ] **rknn / RKLLM NPU 驱动**（核心）
+- [ ] **板贴 26 TOPS 算力芯片驱动**（32 TOPS 档位）
+- [ ] **M0 核 BSP + RPMsg 跨核通信**（若用 M0）
+- [ ] 双千兆 + WiFi 6 + 4G/5G 驱动
+- [ ] CAN ×2 驱动
+- [ ] RS485 ×2 + RS232 ×1 驱动
+- [ ] GPIO 子系统
+- [ ] HDMI 输出（调试）
+- [ ] **Ubuntu 22.04 与 SylixOS 双系统引导**
+
+### 7.4 ARM64 BSP — RK3576（T5-M）
+
+- [ ] SylixOS BSP for RK3576（A72+A53 大小核 SMP）
+- [ ] 6 TOPS NPU 驱动（RKNN 栈）
+- [ ] 2~4 GB LPDDR5 内存管理
+- [ ] CAN / RS485 / 千兆网络驱动
+- [ ] 低功耗被动散热下的频率/温度联动
+
+### 7.5 ARM64 BSP — RK3568（T5-L）
+
+- [ ] SylixOS BSP for RK3568（4×A55 SMP）
+- [ ] 0.8~1 TOPS NPU 驱动（RKNN 栈）
+- [ ] **1~2 GB 极小内存下的内核裁剪与内存域划分**（核心难点）
+- [ ] CAN / RS485 / 千兆网络驱动
+- [ ] 1ms 实时任务在 1 GB 内存约束下的可行性验证
diff --git a/20-实验与规划/03-实验设计.md b/20-实验与规划/03-实验设计.md
new file mode 100644
index 0000000..f8b0756
--- /dev/null
+++ b/20-实验与规划/03-实验设计.md
@@ -0,0 +1,282 @@
+# SylixOS 任务关键系统中人工智能目标负载实验设计
+
+> 更新日期：2026-09-20。依据：[基础设备配置 v2.0](./02-基础设备与算力基础.md) 制定当前待执行方案。
+> 本文描述当前待执行方案；实测结果将在完成准入与正式批次后形成。设备标称参数、模型容量估计和性能目标均须通过实机准入验证。
+
+## 1. 研究目标与实验范围
+
+本实验聚焦比较：在 `T5 控制端`、`T4 设备端 SoC`、`T3 边缘节点`、`T2 桌面/工作站单机` 和 `T1 集群` 不同部署形态下，SylixOS 的调度与资源隔离在**同时满足人工智能目标负载时效/有效性**与**关键保障负载截止期约束**时，对确定性、可预测性和系统协同稳定性的影响。
+
+| 研究问题 | 自变量 | 主要观测量 | 支持结论所需证据 |
+|---|---|---|---|
+| RQ1：双目标约束下的实时保障 | OS、调度策略、竞争负载强度 | `TTFT/TPOT`、响应时间、截止期违约率 | 同硬件同负载的配对对照 |
+| RQ2：隔离机制的代价与收益 | CPU/IRQ 亲和性、内存限额、推理准入 | `P99.9`、有效吞吐、拒绝率、任务质量 | 默认、完整方案与逐项消融 |
+| RQ3：功耗预算下的系统协同能力 | 频率、空闲策略、推理并发 | `J/token`、温度、违约率、恢复时间 | 满足同一双目标约束的配置比较 |
+| RQ4：规模扩展后的边界与瓶颈 | GPU 数、节点数、模型规模 | 扩展效率、通信尾延迟、公平性 | 同模型强扩展与固定单节点负载弱扩展 |
+
+执行分为两层：**核心实验使用现有 T2-L、T4-L 和 T5-H 内存受限配置；其他档位属于条件扩展**。核心结论不依赖新增集群、Jetson 或 H100 到位。LLM、YOLO 检测和语音识别都按**人工智能目标负载**处理；训练不纳入主实验。
+
+## 2. 设备分层与实验平台
+
+### 2.1 T5~T1 五类部署形态、十一档实验映射
+
+沿用设备文档的档位标签，实际容量单列。多节点架构统一记为 `T1-L`，容量边界单独记录，不据容量直接推导性能。
+
+| 部署形态与档位 | 拟用设备 / 容量 | 状态 | 对应实验重点 |
+|---|---|---|---|
+| T5-L 控制端低 | RK3568，1～2 GB | 待获取、待适配 | 极小内存、轻量模型、实时任务保留资源 |
+| T5-M 控制端中 | RK3576，4 GB | 待获取、待适配 | 小模型能效、频率与实时性关系 |
+| T5-H 控制端高 | 现有 RK3588 16 GB 板限额至 8 GB | 可开展限额配置验证 | 内存压力、GPIO/CAN/RS485 混合负载 |
+| T4-L 设备端 SoC 低 | 现有 RK3588，16 GB 统一内存 | 核心平台 B | NPU/CPU 共享资源干扰、多模型并发 |
+| T4-M 设备端 SoC 中 | Jetson AGX Orin 32 GB | BSP 与驱动准入后开展 | GPU 共享内存、可用时加入 DLA |
+| T3-L 边缘节点代表档 | AGX Orin 64 GB 或 x86 + RTX 6000 Ada 48 GB | 二选一，分别标识架构 | 大模型并发与容量上限 |
+| 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 | 远期扩展 | 大模型分布式服务与能效 |
+
+GPU 显存、主机内存和 SoC 统一内存分别记录，不加总为单一可分配空间。多卡总容量不能代替每卡分片可行性验证；FP16 TFLOPS 与 INT8 TOPS 不直接换算，也不作为实测吞吐。
+
+### 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 测量设备
+
+| 测量对象 | 工具与接线 | 要求 |
+|---|---|---|
+| RK3588 整机功耗 | DC 输入端功率计；INA226 仅在量程和接线适配时使用 | 包含加速器和约定外设；保存电压、电流与采样率 |
+| V100 整机功耗 | 覆盖两路电源的交流功率计 / PDU | 单卡遥测仅作归因，不能替代整机读数 |
+| 物理实时响应 | 示波器或逻辑分析仪，GPIO 输入到输出环回 | 记录探头、触发方式、分辨率及环回空载值 |
+| 工业接口 | CAN 分析仪、RS485 对端或回环装置 | 固定波特率、帧长、总线负载和时间戳位置 |
+| 热状态 | 可用片上传感器，辅以外部温度测量 | 分别记录环境温度、芯片温度、频率和降频事件 |
+
+传感器不能读取的指标记为 N/A，不以零代替；不得预设所有平台都有 `npu-smi`、DCGM 或相同性能接口。
+
+## 3. 软件与模型准入
+
+### 3.1 分阶段准入门槛
+
+| 门槛 | 验证内容 | 通过证据 | 失败后的处理 |
+|---|---|---|---|
+| G0 设备识别 | 启动、SMP、容量、接口、时钟 | 硬件清单和启动日志 | 修复平台配置，暂停性能比较 |
+| G1 实时与采样 | 周期任务、单调时钟、优先级、日志缓冲 | 空载时间序列、计时校验 | 仅记录功能适配结果 |
+| G2 加速器 | 驱动加载、内存分配、最小算子、结果回读 | 运行日志、正确性结果 | 保留 CPU 路径，单独标识后端 |
+| G3 完整模型 | 转换、加载、推理、释放、重复运行 | 模型校验值、输出、峰值内存 | 缩小模型或更换已验证后端 |
+| G4 混合负载 | RT + 推理稳定运行至少 30 分钟 | 无崩溃、采样完整、失败可追踪 | 排查后再进入正式批次 |
+
+SylixOS、Linux 与 PREEMPT_RT Linux 的软件栈均按候选路线处理，在冻结实际 OS/BSP、驱动、SDK、编译器和框架版本后进入正式比较。
+
+“SylixOS 实时域 + Linux 推理域”作为单独的异构系统架构组，单独记录核分配、通信方式和内存共享方式，并作为异构系统方案结论呈现。
+
+### 3.2 模型梯度与用途
+
+| 平台 | 首轮候选 | 扩展候选 | 后端准入检查 |
+|---|---|---|---|
+| T4-L/M | Qwen2.5-0.5B / 1.5B，候选 INT4 | 轻量视觉或语音模型 | 对应芯片实际支持的模型、算子及量化格式 |
+| B8 / B16 | Qwen2.5-0.5B / 1.5B / 3B，候选 INT4 | 7B；YOLOv8-n/s INT8 | RKLLM 与 RKNN 分别验证；不可混用兼容性结论 |
+| T2-L | Qwen2.5-7B FP16，先单卡 | 14B FP16；72B 量化多卡 | V100 的驱动、内核、量化算子和并行支持 |
+| T3-M/H | 7B / 14B，容量适配后运行 | 32B / 72B 量化 | 精确到所选设备和软件版本 |
+| T2-M/H、T1-L | 同一 7B/14B 基准；72B FP16 作为容量实验 | 多实例与更长上下文 | 每卡显存、通信路径和框架支持 |
+| T1-H | 72B 作为跨规模桥接模型 | 671B 量化模型 | 完整权重、运行时、KV cache 和分片均可容纳 |
+
+模型占用按“权重 + KV cache + 激活/工作区 + 运行时 + 保留余量”评估；不按权重大小直接计算并发实例数。每个候选先完成并发 1 的峰值测量，再逐级增加上下文和并发。当前文中的 tokens/s、FPS、内存估计均作为待验证参考值。
+
+### 3.3 输入与正确性控制
+
+LLM 固定模型修订、tokenizer、量化文件校验值、随机种子、解码参数和输入 token 序列。首轮使用输入长度 128/512/2048、目标输出 128 token；受限平台不能完成的单元记录容量失败。性能用固定长度合成输入，任务质量用独立固定题集；提前结束的请求记录实际输出长度，不补造 token。
+
+YOLO 可选使用固定 640×640 输入、同一验证集和相同预处理，报告 mAP、帧处理延迟和丢帧率。量化实验同时比较任务质量与速度；不同后端若算子或数值格式不同，只能归为整套软件栈比较。
+
+## 4. 指标定义与采集口径
+
+### 4.1 实时性与系统开销
+
+对第 i 次周期任务记录计划释放时刻 r_i、就绪时刻 q_i、实际开始时刻 s_i 和完成时刻 f_i，周期为 T，相对截止期为 D。
+
+| 指标 | 定义 | 汇总 |
+|---|---|---|
+| 唤醒延迟 | s_i − r_i，包含定时释放与调度影响 | P50/P95/P99/P99.9、观测最大值 |
+| 就绪后调度延迟 | s_i − q_i，仅在两系统均可取得等价就绪事件时使用 | 同上，独立于唤醒延迟 |
+| 响应时间 | f_i − r_i | 分位数、观测最大值 |
+| 截止期违约率 | count(f_i > r_i + D) / 计划释放次数 | 分子、分母、丢失/跳过次数 |
+| 完成抖动 | 相邻完成间隔减去 T | 分布与时间序列 |
+| 上下文切换 / IPC | 固定线程数和消息大小的往返测量 | µs；说明是否含系统调用和拷贝 |
+| 外部响应 | 外部触发到 GPIO 翻转或回包的时间 | µs/ms，说明物理链路边界 |
+
+缺失的周期不能直接从分母移除；需追踪其完成状态，否则该批实时性数据判为不完整。Linux 可使用 cyclictest 等作为辅助，跨 OS 主比较使用相同任务语义的测试程序，不假定 Linux 工具可直接运行于 SylixOS。
+
+### 4.2 推理服务
+
+在负载发生器的单调时钟上记录计划到达、实际发送、首 token 和最后 token 到达时间。
+
+- TTFT：首 token 到达 − 实际发送，包含排队、传输与 prefill；同时记录发送滞后，防止负载发生器饱和掩盖排队。
+- TPOT：对输出 token 数 n > 1，使用（末 token 到达 − 首 token 到达）/(n−1)；逐 token 间隔另行汇总。
+- 总输出吞吐：测量窗口内收到的输出 token 数 / 窗口时长；另报成功完成请求吞吐和请求成功率。
+- 有效吞吐：仅统计满足预先冻结的 TTFT、完成期限及质量要求的成功请求，其输出 token 数 / 窗口时长；同时报告拒绝、超时和错误，避免只靠丢弃请求改善尾延迟。
+- CPU→加速器端到端延迟：主机提交到结果可用；设备事件计时只作执行阶段分解，不代替完整链路。
+
+### 4.3 能耗与热状态
+
+在与负载一致的窗口 [t0,t1] 内积分：E_total = ∫P(t)dt；E_token = E_total / N_output，单位 J/token；tokens/J = N_output / E_total。固定窗口包含排队及已执行失败请求消耗的电能，并另外报告完成率。
+
+同时可报告 E_dynamic = E_total − P_idle×(t1−t0)，但不得与整机总能耗混用。N_output=0 时能效记为不可计算。混合视觉与 LLM 负载的总能耗不能全部归因于 LLM；应单列场景或增加独立负载对照。
+
+报告平均功率、仪器采样峰值、空载功率、温度、实际频率和降频时间比例。**21 W 等设备标称值不直接定义实测整机峰值上限**；工程功耗预算由测量边界、具体硬件及项目需求在试运行后冻结。
+
+## 5. 对照组与变量控制
+
+### 5.1 OS 与部署组
+
+| 编号 | 配置 | 作用 |
+|---|---|---|
+| O0 | 板卡支持的普通 Linux，固定发行版与内核 | 通用系统基线 |
+| O1 | 同硬件可用的 Linux PREEMPT_RT，记录补丁与驱动兼容性 | 主要实时对照 |
+| O2 | SylixOS 默认配置 | 原生系统基线 |
+| O3 | SylixOS 调度、隔离与推理准入优化 | 主实验组 |
+| O4 | PREEMPT_RT Linux 等预算调优 | 避免仅一侧调优造成偏差 |
+| O5（可选） | KVM 实时虚拟机 / 容器部署，分别记录 | 部署开销；不能视为独立内核类型 |
+
+平台 B 的对照 OS 以实机支持的镜像为准；扩展平台选择实际受支持的 OS 镜像。无法提供同一推理后端时，分别记录 OS 调度效应与系统方案效应。
+
+### 5.2 配置控制与消融
+
+所有对照固定核心数量、RT 优先级、内存预算、模型输入、加速器数量、功率策略、后台服务和日志方式。B8/B16 对照只改变内存预算；频率策略作为独立实验变量，记录各 OS 的实际频率，不仅记录策略名称。
+
+完整方案逐项去除：①CPU 核隔离；②IRQ 亲和性；③预分配/内存限额；④推理队列限长与准入；⑤功耗感知策略。每次只去除一个机制，并保留默认配置；不支持的机制注明不可用，不伪造等效实现。
+
+## 6. 负载设计
+
+### 6.1 实时任务
+
+主任务周期 T=1 ms，D=1 ms；扩展周期 0.5/5/10 ms。任务体采用确定性计算或内存访问，在每台机器固定参考频率下校准至约 100 µs，再冻结迭代次数；后续频率实验不重新校准工作量。另测试 20%/40% 参考 CPU 占用预算，记录实测执行时间。
+
+任务使用绝对时间周期释放，预分配日志缓冲，测试窗口内避免同步磁盘写入。GPIO/总线回环作为独立端到端任务。LLM 负责命令解析时与周期控制解耦，推理超时走模拟默认动作，先在回环或仿真环境验证。
+
+### 6.2 伴生竞争负载与推理到达
+
+| 场景 | 内容 | 目的 |
+|---|---|---|
+| L0 | 仅关键保障负载 | 实时性下界与测量开销 |
+| L1 | 仅人工智能目标负载 | 最大可持续服务能力与独立能耗 |
+| L2 | 关键保障负载 + LLM | 核心双目标场景 |
+| L3 | L2 + CPU 竞争负载 | 参考占用 25/50/75/100%，注明施加核心 |
+| L4 | L2 + 内存流式读写 | 实测带宽压力与容量压力分别扫描 |
+| L5 | L2 + 网络/存储 I/O | IRQ、DMA 与系统服务竞争 |
+| L6 | 关键保障负载 + LLM + YOLO（可选） | 多人工智能目标负载竞争与优先级影响 |
+| L7 | L2 + 突发/过载 | 队列、拒绝与恢复行为 |
+
+人工智能目标负载先以并发 1/2/4 做容量筛选，再以开放到达过程测试。每种硬件与模型固定一个参考基线的可持续请求率 `λ_ref`，所有 OS 使用同一绝对到达序列，测试 `0.25/0.5/0.75/1.0/1.25×λ_ref`。不得各组按自身吞吐重新归一化后声称承受相同负载。
+
+突发模式使用相同种子：稳态运行后每 60 秒施加持续 10 秒的 2×基础到达率，记录队列峰值和恢复时间。负载发生器尽量位于独立机器；共机时记录其 CPU 开销。
+
+## 7. 实验矩阵与具体步骤
+
+### 7.1 核心实验
+
+| 实验 | 平台 / 变量 | 操作与输出 | 关联问题 |
+|---|---|---|---|
+| E0 准入与空载 | A、B16、B8；G0～G4 | 固定版本、拓扑和功耗边界；输出准入表 | 全部 |
+| E1 微基准 | O0～O4；L0、CPU/内存/I/O 干扰 | 测周期任务、IPC、物理环回；输出 CDF 与最大值 | RQ1 |
+| E2 推理基线 | A 单卡 7B；B 从 0.5B 起；L1 | 扫输入长度、并发，测正确性、容量、吞吐、能耗 | RQ2/3 |
+| E3 混合负载 | 各平台准入模型；L2～L5、L7 | 固定到达流比较 OS；绘制违约率与有效吞吐曲线 | RQ1/2 |
+| E4 内存限额 | B16 与 B8；固定模型和频率 | 分别增加上下文、并发和内存干扰，测失败点及 RT 影响 | RQ2 |
+| E5 多卡竞争 | A 的 1/2/4 卡 | 同模型并行扩展和多实例分别测试；采通信时间与公平性 | RQ4 |
+| E6 能耗与热 | A、B；已验证频率/空闲模式 | 固定服务负载与环境，测能效、降频和违约率 | RQ3 |
+| E7 消融 | O3 完整方案及逐项去除 | 使用 E3 中固定中载与过载单元重复测试 | RQ2 |
+| E8 长稳与恢复 | A、B 的最终候选配置 | 连续 24 小时混合负载，注入推理进程重启、队列过载 | RQ1/3 |
+
+E5 中，同一 7B 模型只有在所有 GPU 数配置均支持相同后端及并行机制时才计算强扩展；多实例吞吐增长单列，不冒充单请求加速。多租户公平性可使用各租户相对独占吞吐 x_i，计算 Jain 指数 (Σx_i)²/(kΣx_i²)，同时报告每租户 TTFT 和服务等级。
+
+E8 记录重启时间、请求丢失、RT 违约、内存增长及恢复到稳定吞吐的时间。驱动重置和热环境测试仅在存在可恢复测试路径和相应设备时增加；没有温箱数据不能宣称覆盖 −40～60℃ 全温域。
+
+### 7.2 条件扩展
+
+| 扩展 | 前提 | 实验内容 | 结论边界 |
+|---|---|---|---|
+| X1 T4-L/M | 板卡、BSP、模型准入 | 复用 E1～E4、E6，小模型与容量下限 | 不能用 RK3588 限额替代新 SoC 的功耗结果 |
+| X2 T3-M/H | GPU/DLA 与 OS 路径明确 | 共享内存、多模型干扰、功率模式 | ARM 与 x86 路线分组，不只按容量归因 |
+| X3 T2-M/H | 拓扑、供电和散热可用 | 4→8 卡、V100→H100 | 数量扩展与架构更换分开比较 |
+| X4 T1-L | 至少 2 节点，网络和集合通信准入 | 1/2/4 节点，通信微基准与 RT + 分布式推理 | 单节点不可容纳模型时，以最小可运行节点数作参考 |
+| X5 T1-H | 大模型分片、网络和测量资源齐备 | 固定 72B 对照后增加超大模型 | 云租环境若无物理功耗或 OS 控制，则相应指标不报告 |
+
+T1 强扩展固定总模型及工作量，速度提升以参考节点数 n0 的完成时间为基准，效率 = 加速比/(n/n0)；弱扩展固定每节点请求负载，报告总有效吞吐和尾延迟。网络协议、交换机、MTU、拥塞配置和进程布局冻结。RDMA/NCCL 不可用时，TCP 回退单独成组。
+
+跨节点单向延迟需记录时钟同步方法与误差；误差不能满足精度要求时改测往返时间，不将其一半无条件当作单向延迟。
+
+### 7.3 控制实验数量
+
+不一次展开全部档位、OS、模型、长度、干扰和功率的笛卡尔积。首轮使用 A 单卡 7B、B 的已准入小模型、512 输入/128 输出、并发 1 和固定频率，完成 E0～E3；随后围绕出现干扰或资源瓶颈的单元展开 E4～E7。最终确认实验使用提前冻结的配置与新运行批次，避免只报告探索阶段的最佳结果。
+
+## 8. 运行流程与统计方法
+
+1. 保存硬件清单和配置快照；核对时钟、仪器连接、数据目录及剩余空间。
+2. 重启进入指定配置，先测空载；模型预热至少 5 分钟，并记录温度是否稳定。冷启动时间单独测量。
+3. 按随机顺序执行对照；同一设备采用配对批次，保持相同输入、种子及环境条件。
+4. 普通性能单元至少独立运行 5 次、每次稳态窗口 10 分钟；RT 以 1 ms 周期可每次得到约 60 万次计划释放。长稳实验独立运行 24 小时。
+5. 尾延迟按指标各自样本量判断。请求级 P99.9 以每单元至少 10 万个有效请求为采样目标，数量不足时标为探索性估计，报告样本数并延长采集或改报 P99；不能用 RT 周期样本数充当请求数。
+6. 保存原始失败、超时和 OOM；测试程序、仪器或配置失效的批次标记无效并说明原因，保留原文件后重跑。
+7. 输出每次运行的分位数、最大值和违约率；跨运行报告中位数与区间，使用按运行/时间块重采样的 bootstrap，保留随机种子。不给时间相关的百万周期样本套用独立样本假设。
+
+观测最大值是本次时长与负载下的最大值，不是理论最坏执行时间。零违约只表述为“在 N 次计划释放和指定工况下未观测到违约”，不能证明硬实时安全上界。能耗差异还需考虑仪器精度、采样频率与环境漂移。
+
+## 9. 验收与结果判断
+
+验收采用“数据可用”“系统约束满足”和“研究假设得到支持”三层结构。
+
+| 类型 | 判据 | 说明 |
+|---|---|---|
+| 数据可用 | G0～G4 通过，原始数据与配置完整，重复运行可复现 | 必须项 |
+| 实时约束 | 核心 1 ms 任务在预定负载范围内，观测违约数为 0 | 同时报告样本量、最大响应时间和过载结果 |
+| 推理服务 | 达到预先冻结的 TTFT、质量、吞吐和完成率要求 | 按模型与输入长度分别制定 |
+| 调度收益 | 对 O1/O4 的配对比较改善尾延迟或扩大无违约负载范围 | 同时报有效吞吐代价和置信区间 |
+| 能耗收益 | 满足相同实时和推理约束时降低 J/token | 不以降低完成率换取能效结论 |
+| 长稳 | 完成 24 小时，无不可恢复故障、日志失效或持续内存增长 | 任何故障均保留并分析 |
+
+当前候选阈值包括“0.5B ≥25 token/s、1.5B ≥12 token/s、7B ≥20 token/s、TTFT P99.9 ≤500 ms、吞吐偏差 ≤15%”。E2 试运行后依据指定模型、长度、并发及任务需求决定采用与否，并在正式实验前冻结；8/15/21 W 数值同样单独按配置记录，不作为跨配置统一验收值。
+
+## 10. 数据产物与论文图表
+
+建议按 `results//////` 保存数据，每次运行至少包含：
+
+| 文件 | 内容 |
+|---|---|
+| manifest.json | 档位、实物编号、容量口径、OS/BSP/驱动、模型校验值、核心/IRQ/频率配置、输入与种子、测试程序版本 |
+| rt.csv | 计划释放、就绪（如可用）、开始、完成、CPU ID、违约与丢样状态 |
+| requests.csv | 请求 ID、计划到达、发送、首/末 token、输出数、质量/成功状态、超时和拒绝原因 |
+| power.csv / thermal.csv | 时间戳、功率、电压电流（如可用）、温度、实际频率、传感器来源 |
+| events.log | OOM、驱动错误、降频、重启、网络异常和测量故障 |
+| summary.json | 样本量、分位数、最大值、吞吐、能耗、配置有效性及异常说明 |
+
+不同机器的时钟域及对齐方式写入 manifest；保留原始时间戳，汇总脚本不得静默删除异常值。
+
+最终图表包括：①平台与准入状态表；②各负载下 RT 延迟 CDF/尾部放大图；③到达率—违约率—有效吞吐曲线；④B8/B16 内存占用与失败边界；⑤多卡/多节点扩展效率；⑥实时约束内的能耗—吞吐散点图；⑦消融效应及区间；⑧24 小时温度、频率、内存和违约时间序列。未执行的扩展档明确标为计划，不混入实测图。
+
+## 11. 实施顺序与停止条件
+
+| 阶段 | 工作 | 完成标志 |
+|---|---|---|
+| P0-1 | 清点 A/B，仪器校准，OS 与加速器准入 | 准入表明确通过项与阻塞项 |
+| P0-2 | 完成 E1/E2，冻结正式配置和阈值 | 微基准、模型容量、基线数据齐全 |
+| P0-3 | 完成 E3～E7 核心对照 | 能回答 RQ1～RQ3 及单机 RQ4 |
+| P0-4 | E8 长稳、复核与图表 | 可复现数据包与结论边界完整 |
+| P1/P2 | 小内存板卡、边级扩展与必要仪器 | 在准入后复用核心实验流程 |
+| P3/P4 | 多卡升级与集群扩展 | 硬件、通信、OS 和功耗采集均满足对应实验条件 |
+
+设备文档的采购优先级用于安排依赖，本实验设计不要求先采购全谱系设备。扩展驱动无可用实现时停止该路线的原生性能测试，输出适配缺口；内存不足时记录最大可运行配置；仪器缺失时保留性能实验并将能耗记为未测。最终报告分别陈述已实测结论、适配结果和后续计划。
diff --git a/20-实验与规划/04-论文写作规划.md b/20-实验与规划/04-论文写作规划.md
new file mode 100644
index 0000000..02e61e5
--- /dev/null
+++ b/20-实验与规划/04-论文写作规划.md
@@ -0,0 +1,450 @@
+# 论文写作规划 — 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究
+
+> **版本**: v0.1 (研究启动版)
+> **日期**: 2026-09-20
+> **整合来源**: 01-研究逻辑说明.md + 02-基础设备与算力基础.md + 03-实验设计.md + 10-研究框架/00~07 系列文档 + 第三方基准复现思路
+> **目标产物**: 一篇面向 RTSS/RTAS 级别的系统化研究文章规划稿 (后续随实验推进持续迭代)
+
+---
+
+## 0. 文章定位与核心贡献
+
+### 0.1 一句话定位
+
+> **用业界公认方法学，在 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 | 公开研究通常只覆盖单一平台或两档对比，缺少连续验证框架 |
+| C3 | **RTOS 数据与业界公开基准的可复现对齐方法** — 引入第三方文章的 CPU/内存/NPU/功耗实测方法学，在 SylixOS 上复现并对比，使 RTOS 结果具备外部校验与方法学可迁移性 | 03-实验设计.md、07-方法论与评估工具链.md | 国产 RTOS 在设备端 SoC 与边缘节点平台上的可外部校验数据明显不足 |
+
+### 0.3 目标读者与发表场景
+
+| 维度 | 选择 |
+|------|------|
+| 目标会议 | RTSS / RTAS (实时系统 Top-Tier) 或 ISLPED (低功耗) |
+| 备选 | EMSOFT / DAC / MLSys (系统方向) |
+| 文章类型 | 系统评测 + 方法论论文 (非纯算法论文) |
+| 核心读者 | RTOS 研究者、边缘 AI 系统工程师、国产化选型决策者 |
+
+---
+
+## 1. 文章整体结构 (十章)
+
+```
+第1章 引言 — 问题、动机、贡献概述
+第2章 背景与相关工作 — 人工智能目标负载特征 + RTOS 基础 + 差距分析
+第3章 T5~T1 五类部署形态验证矩阵 — 11 档位体系设计与现有设备锚点
+第4章 SylixOS 调度框架技术架构 — 五层技术栈与六大优化方向
+第5章 实验方法学 — 第三方基准复现 + 双目标场景 + 避坑约束
+第6章 大模型负载选型与配置 — 跨档位模型矩阵
+第7章 实验结果 — 基准对齐 + 双目标实时保障 + 能效 + 温度耦合
+第8章 深入分析 — 档位间性能曲线 + RTOS vs 普通 Linux / PREEMPT_RT 差异化
+第9章 讨论与威胁有效性 — 适用场景边界 + 局限性
+第10章 结论与展望
+```
+
+---
+
+## 2. 逐章详细规划
+
+### 第1章 引言
+
+**目标**: 300~500 词，点明矛盾、贡献、文章路线图。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 1.1 问题矛盾 | 人工智能目标负载要求结果及时且有效，关键保障负载要求严格截止期；两者进入同一任务关键系统后，会在 CPU、内存、总线、加速器和中断路径上发生竞争 | |
+| 1.2 研究空白 | 公开基准大多基于 Linux/Ubuntu，重点放在吞吐或单任务性能，缺少 RTOS 对人工智能目标负载与关键保障负载双目标实时保障的系统评测 | 01-研究逻辑说明.md §2、§8 |
+| 1.3 本文贡献 | C1 (双目标实时保障优势)、C2 (五类部署形态统一验证矩阵)、C3 (业界基准对齐)，一句话概述每个贡献 | |
+| 1.4 文章组织 | 十章路线图 | 本规划 §1 |
+
+**关键图表**: 无 (引言章通常无图表或仅一张概念图)。
+
+---
+
+### 第2章 背景与相关工作
+
+**目标**: 600~800 词，建立读者所需的 LLM 推理 + RTOS 双重背景。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 2.1 人工智能目标负载特征 | prefill/decode 两阶段；CPU/内存密集；长尾分布；并发争抢；模型加载 I/O 抖动；输出质量与时效双重约束 | 03-实验设计.md §3、10-研究框架/01~04 |
+| 2.2 RTOS 调度基础 | 硬优先级 + 优先级继承；内存锁定；tickless；中断线程化；SMP 可预测调度；精简内核路径 | 10-研究框架/00.md §3、05-中断与实时性保障.md |
+| 2.3 PREEMPT_RT 相对短板 | 内核态长路径、系统后台线程、内存回收与共享资源竞争仍可能拉长 `P99.9`；其可预测性增强但不等同于专用 RTOS | 00-整体研究框架.md §5、07-方法论与评估工具链.md §2、§4 |
+| 2.4 相关工作对比 | vLLM/TGI (服务器级无实时保证)、Micro-LLM (模型压缩不关注 OS 调度)、NPU SDK (封闭黑箱)、CUDA Stream (无实时分析) | 00-整体研究框架.md §6 |
+| 2.5 第三方基准方法学 | 第三方文章的 5 维度方法学 (CPU/内存/NPU/功耗/温度) + 避坑清单 | 03-实验设计.md §4、07-方法论与评估工具链.md §8~§10 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Fig.1 | LLM 推理两阶段时序图 | prefill (计算密集, 串行) vs decode (逐 token, KV Cache IO 密集) 的 RTOS 任务映射 |
+| Tab.1 | SylixOS vs 普通 Linux / PREEMPT_RT 对比 | 关键 RTOS 特性对应的双目标实时保障优势与对照平台短板 |
+
+---
+
+### 第3章 T5~T1 五类部署形态验证矩阵
+
+**目标**: 800~1000 词，用连续验证矩阵承载主问题，保持硬件作为验证矩阵的角色。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 3.1 分级维度与分档规则 | 以「部署形态」为第一分类维度，以「统一内存/显存容量」为分档参考；T5~T1 五类部署形态下连续展开 | 02-基础设备与算力基础.md §0.1 |
+| 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 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Fig.2 | T5~T1 五类部署形态验证矩阵全景图 | 横轴=容量 (1 GB→2 TB, log 刻度), 纵轴=功耗 (3 W→25 kW, log 刻度), 11 个档位点标注, 散热形态用颜色分区 (被动/风冷/液冷/机房液冷) |
+| Tab.2 | 11 档位全规格对比表 | 容量、算力、功耗、加速器架构、散热、互联、SylixOS BSP 风险、状态 (现有/需扩展) |
+| Tab.3 | 模型规模梯度表 | 11 档位 × 代表模型 × 量化 × 显存占用 × 角色 (控制端最低资源参考档→超大模型分布式) |
+| Tab.4 | 采购计划表 | P0~P4 优先级 + 估算费用 + 降本策略 |
+
+---
+
+### 第4章 SylixOS 调度框架技术架构
+
+**目标**: 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.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) |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Fig.3 | 五层技术栈架构图 | L1~L5 层叠 + 每层关键组件 + 层间接口 |
+| Fig.4 | LLM 推理 DAG → RTOS 任务图 | 推理阶段的有向无环图, 标注每阶段优先级 (MAX/HIGH/MEDIUM/LOW) 和可抢占性 |
+| Tab.5 | 推理阶段特征矩阵 | 阶段 × (计算密集度/IO 密集度/延迟敏感度/确定性要求/RTOS 优先级) |
+| Tab.6 | 六大优化方向概览 | 方向 × (核心问题/关键手段/目标指标/对应章节) |
+
+---
+
+### 第5章 实验方法学
+
+**目标**: 800~1000 词，这是 C2 和 C3 的方法论基础，也是本文"可复现"承诺的核心。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 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.8 研究问题到实验映射 | 明确 `RQ1~RQ4` 分别由哪些实验单元、场景编号与结果章节支撑，避免论文章节与实验表脱节 | 03-实验设计.md §1、§7 |
+| 5.9 场景编号到结果章节映射 | 明确 `L0~L7` 在论文中的归属位置：哪些是基线、哪些是核心双目标证据、哪些是扩展或压力场景 | 03-实验设计.md §6、§7 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Fig.5 | 实验方法论流程图 | `G0~G4` 准入 + `O0~O4` 对照 + 第三方基准对齐校验门 |
+| Tab.7 | 业界基准对照表 | 指标 × (文章基线 / SylixOS 实测 / 偏差 / 评判) — CPU 单核~1280、多核~7120、YOLOv5s 32 FPS、3B LLM ~90 tok/s |
+| Tab.8 | 避坑清单映射 | 5 条避坑点 × (强制约束/验证方式/落实位置) |
+| Tab.9 | 环境元数据清单模板 | 10 项元数据 × 示例值 |
+
+本章设置下面两张“索引表”：
+
+| 索引表 | 作用 |
+|------|------|
+| RQ → 实验 → 章节映射表 | 把 `RQ1~RQ4` 对应到 `E0~E8`、`L0~L7` 与第7/8章，保证每个研究问题都有直接证据链 |
+| 场景编号 → 结果章节映射表 | 把 `L0~L7` 对应到第7章的小节与图表，保持实验编号与结果章节的直接锚点 |
+
+---
+
+### 第6章 大模型负载选型与配置
+
+**目标**: 500~700 词，定义跨 11 档位的模型矩阵。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 6.1 选型原则 | 国产化优先 (Qwen/MiniCPM)；跨架构可比 (x86+CUDA 与 ARM+NPU)；量化版本完整 (FP16/INT8/INT4)；社区生态成熟 (vLLM/llama.cpp/TensorRT-LLM/RKLLM) | 03-实验设计.md §3.2 |
+| 6.2 跨档位模型矩阵 | T5-L: Qwen2.5-0.5B INT4；T5-M: 1.5B INT4；T5-H: 3B/7B INT4；T4-L: 3B/7B INT4 (RKLLM)；T4-M: 14B/32B INT4 (TensorRT-LLM)；T3-L: 72B INT4；T2-L: 72B INT4/14B FP16；T2-M: 72B FP16；T2-H: DeepSeek-V2 FP16；T1-L: 72B FP16 分布式；T1-H: 671B INT4 | 02-基础设备与算力基础.md §5.2、03-实验设计.md §3.2 |
+| 6.3 推理框架与配置 | vLLM (T2/T1)、TensorRT-LLM (T2/T4-M/T3-L)、llama.cpp (T2-L/T4-L 退路)、RKLLM (T5/T4-L)；batch 1/8/32；上下文 512/2048/8192；并发 1/8/32 | 03-实验设计.md §3.1~§3.3 |
+| 6.4 负载生成器 | vLLM benchmark / llama-bench / 自研并发客户端 / RKLLM demo / 自研 LLM+RT 混合负载驱动脚本 | 03-实验设计.md §3、§6 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Tab.10 | 跨档位模型矩阵 | 11 档位 × (代表模型/参数/量化/显存占用/并发实例/推理框架/预期 tok/s) |
+| Tab.11 | 负载生成器清单 | 工具 × 平台 × 角色 × SylixOS 可用性 |
+
+---
+
+### 第7章 实验结果
+
+**目标**: 1500~2000 词，本文篇幅最大的章节，展示全部实验数据。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 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.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 |
+| 7.6 温度-功耗-性能耦合 | 对应 `RQ3`；可与 `L1/L2/L7` 组合，报告 25%→100% CPU 逐步加压的三维耦合曲线，以及 SylixOS vs 普通 Linux / PREEMPT_RT Linux 的降频触发温度与性能下降斜率 | 03-实验设计.md §4、06-能耗与热管理.md |
+| 7.7 异构核分配 | 对应 `RQ2/RQ3`；主要落在 RK3588 路线与 `L2/L3`，体现 A76 (LLM) + A55 (1 ms RT) + M0 (100 µs 控制) 的 SylixOS 异构调度优势 | 03-实验设计.md §6、03-加速器协同调度.md |
+| 7.8 跨档位性能曲线 | 对应 `RQ4`；汇总 11 档位上 T_sched P99.9 / E_per_token / T_rt_max_under_llm 的连续曲线；第7.8节按“已实测结果”与“后续扩展计划”两类展示 | 02-基础设备与算力基础.md §5.3、03-实验设计.md §2 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Tab.12 | 业界基准复现对比表 (最终版) | 填入 SylixOS 实测值与偏差列 |
+| Fig.6 | 功耗分阶段曲线 | prefill 峰值 → decode 稳态 → idle 的 `W(t)` 曲线，SylixOS vs 普通 Linux / PREEMPT_RT Linux 叠加 |
+| Fig.7 | 双目标实时保障延迟分布 (★ 核心证据) | 人工智能目标负载与关键保障负载的 P50~Max 直方图 + 时间序列，4 变体叠加 |
+| Fig.8 | 人工智能目标负载输出时延直方图 | Qwen2.5-7B 单流 1 h 采集，SylixOS vs 普通 Linux / PREEMPT_RT Linux |
+| Fig.9 | 突发加载瞬间时间序列 | 模型加载瞬间关键保障负载延迟 spike 与人工智能目标负载队列变化的联合时间序列 |
+| Fig.10 | 温度-功耗-性能三维耦合曲线 | T_core / P / perf 三轴, 不同 CPU 负载档位 |
+| Fig.11 | 跨档位性能连续曲线 | 横轴=11 档位 (T5-L→T1-H), 纵轴=P99.9 调度延迟 / E_per_token / T_rt_max, 三条曲线 |
+| Tab.13 | 通过判据三层汇总 | 第一层基准对齐 + 第二层实时性 + 第三层优越性量化 |
+
+建议在第7章开头直接放入下面两张索引表：
+
+| 研究问题 | 主要实验单元 | 主要场景编号 | 主要结果章节 | 核心图表 |
+|------|------|------|------|------|
+| `RQ1` 双目标约束下的实时保障 | `E1` 微基准、`E3` 混合负载、`E8` 长稳与恢复 | `L0`、`L2`、`L3`、`L4`、`L5`、`L7` | `7.3`、`7.4` | `Fig.7`、`Tab.13` |
+| `RQ2` 隔离机制的代价与收益 | `E3` 混合负载、`E4` 内存限额、`E7` 消融、`E8` 长稳与恢复 | `L2`、`L3`、`L4`、`L5`、`L6`、`L7` | `7.3`、`7.5`、`7.7` | `Fig.7`、`Fig.9`、`Tab.13` |
+| `RQ3` 功耗预算下的系统协同能力 | `E2` 推理基线、`E3` 混合负载、`E6` 能耗与热、`E8` 长稳与恢复 | `L1`、`L2`、`L7` | `7.2`、`7.6` | `Fig.6`、`Fig.10`、`Tab.13` |
+| `RQ4` 规模扩展后的边界与瓶颈 | `E5` 多卡竞争、`X3`/`X4`/`X5` 条件扩展 | `L3`、`L5`、`L6`、`L7` | `7.5`、`7.8` | `Fig.11`、`Tab.14` |
+
+| 场景编号 | 场景定义 | 论文归属章节 | 主要回答的问题 | 核心图表 |
+|------|------|------|------|------|
+| `L0` | 仅关键保障负载 | `7.3` 低延迟结果 | 关键保障负载下界、测量链路开销 | 延迟 CDF、基线表 |
+| `L1` | 仅人工智能目标负载 | `7.2` 低功耗结果、`7.3` 低延迟结果 | 人工智能目标负载基线时效、能耗与服务能力 | `Fig.6`、`Fig.8` |
+| `L2` | 关键保障负载 + LLM | `7.4` 双目标实时保障结果 | 双目标是否同时达标，是全文核心主场景 | `Fig.7`、`Tab.13` |
+| `L3` | `L2` + CPU 竞争负载 | `7.4`、`7.5` | CPU 竞争下的隔离能力与调度边界 | `Fig.7`、竞争负载对照表 |
+| `L4` | `L2` + 内存流式读写 | `7.4` | 内存带宽与容量压力下的边界变化 | 内存压力时间序列、违约率表 |
+| `L5` | `L2` + 网络/存储 I/O | `7.4`、`7.5` | IRQ、DMA 与系统服务竞争影响 | `Fig.9`、I/O 干扰对照表 |
+| `L6` | 关键保障负载 + LLM + YOLO（可选） | `7.5` | 多人工智能目标负载共存时的优先级与公平性 | 多模型公平性图、Jain 指数表 |
+| `L7` | `L2` + 突发/过载 | `7.4`、`7.5`、`7.6` | 过载、拒绝、恢复与热耦合下的系统稳定性 | `Fig.9`、`Fig.10`、恢复时间表 |
+
+---
+
+### 第8章 深入分析
+
+**目标**: 800~1000 词，从数据中提炼规律性结论。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 8.1 档位间性能曲线规律 | 容量、功耗和拓扑变化下 RTOS 优势的变化趋势；分析哪些档位更容易体现差异、哪些档位优势可能收窄 | 02-基础设备与算力基础.md §5.3 |
+| 8.2 SylixOS vs 普通 Linux / PREEMPT_RT 差异化量化 | 分别评价关键保障负载边界、人工智能目标负载时效和系统协同收益；按档位和场景分别判定 | 03-实验设计.md §9、§10 |
+| 8.3 双目标场景下 RTOS 优势的根因 | 硬优先级 + 优先级继承 → 关键保障负载不被长路径抢占；内存锁定 → KV Cache 抖动不驱逐关键页；精简内核路径 → 模型加载不引入额外抖动；中断线程化 + 亲和性 → NPU/GPU 中断不污染实时核 | 05-中断与实时性保障.md、02-KV-Cache与内存管理.md |
+| 8.4 能效分析 | 每 token 能耗 vs 档位；INT4 vs FP16 的能效拐点；RKLLM NPU vs CUDA GPU 的 `J/token` 对比 | 02-基础设备与算力基础.md §0.3、06-能耗与热管理.md |
+| 8.5 BSP 风险与可行性 | x86 BSP、ARM64 RK3588 BSP、T234 Jetson BSP、RKLLM 移植等路径的风险等级与降本策略 | 02-基础设备与算力基础.md §7、03-实验设计.md §3 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| Fig.12 | RTOS 优势 vs 部署档位趋势图 | 横轴=11 档位，纵轴=SylixOS 相对普通 Linux / PREEMPT_RT Linux 的 `P99.9` 与有效吞吐改善百分比，标注"显著优势/可比偏优/未体现"区间 |
+| Tab.14 | 优越性量化结论矩阵 | 场景 × 档位 × (T_rt_max 比值 / 判定结论) |
+| Tab.15 | BSP 风险与可行性矩阵 | 档位 × (BSP 类型/风险等级/状态/降本策略) |
+
+---
+
+### 第9章 讨论与威胁有效性
+
+**目标**: 400~600 词，诚实地界定适用边界和局限性。
+
+| 小节 | 内容要点 | 来源映射 |
+|------|----------|----------|
+| 9.1 适用场景边界 | 资源更受限或混合负载更强的档位通常更容易体现 RTOS 优势；资源充裕且目标偏纯吞吐时，优势可能收窄 | 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 |
+
+---
+
+### 第10章 结论与展望
+
+**目标**: 300~400 词，总结贡献并指出未来方向。
+
+| 小节 | 内容要点 |
+|------|----------|
+| 10.1 结论 | 重申 C1/C2/C3 三大贡献的量化结果（基准对齐 ±X%、双目标场景下相对 PREEMPT_RT Linux 的边界改善 X%、能效改善 X%） |
+| 10.2 展望 | 跨平台横向对比 (RK3588 vs Jetson vs 昇腾); 功能安全 SIL2/IEC 61508 关联; 多机分布式推理; 昇腾 Qwen-7B 作为第二业界参照点; 自适应优先级与动态 WCET 估计 |
+| 10.3 开放研究问题 | 动态 WCET 在线估计; 运行时自适应优先级; 跨层优化 (调度+量化联合); 预测式调度; 容错恢复调度 | 01-推理图任务调度.md §8 |
+
+---
+
+## 3. 来源文档到章节的映射矩阵
+
+| 来源文档 | 主要贡献章节 | 次要贡献章节 |
+|----------|------------|------------|
+| **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 (开放问题) |
+| **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 (根因) |
+| **04-量化精度感知调度.md** | §4.4 (方向4 概览) | §6.2 (量化选型), §8.4 (能效拐点) |
+| **05-中断与实时性保障.md** | §4.4 (方向5 概览) | §7.3 (中断延迟), §8.3 (根因) |
+| **06-能耗与热管理.md** | §4.4 (方向6 概览) | §7.2 (功耗), §7.6 (温度耦合), §8.4 (能效) |
+| **07-方法论与评估工具链.md** | §5.1 (方法论框架) | §7 (评估指标体系), §8 (分析方法), §9 (消融实验设计) |
+
+---
+
+## 4. 关键数据产物清单
+
+| 编号 | 产物 | 类型 | 优先级 | 依赖 |
+|------|------|------|--------|------|
+| D1 | 11 档位硬件规格总表 | 数据表 | P0 | 02-基础设备与算力基础.md 已就绪 |
+| D2 | 跨档位模型矩阵 | 数据表 | P0 | 02-基础设备与算力基础.md + 03-实验设计.md 已就绪 |
+| D3 | RK3588 上 sysbench/stress-ng 基准复现数据 | 实测数据 | P0 | 需 SylixOS BSP + sysbench 移植 |
+| D4 | 业界基准对比表 (SylixOS vs 文章基线) | 对比表 | P0 | D3 |
+| D5 | 混合负载 30 min 全周期延迟时间序列 | 实测数据 | P0 | 需混合负载驱动脚本 + 4 变体 |
+| D6 | 混合负载延迟分布直方图 (4 变体叠加) | 图表 | P0 | D5 |
+| D7 | 功耗分阶段曲线 (prefill/decode/idle) | 图表 | P0 | 功率计采集 + LLM 推理 |
+| D8 | LLM token 延迟直方图 (1 h 采集) | 图表 | P1 | vLLM/RKLLM benchmark |
+| D9 | 突发加载瞬间实时任务时间序列 | 图表 | P1 | 混合负载脚本 + 模型切换 |
+| D10 | 温度-功耗-性能三维耦合曲线 | 图表 | P1 | stress-ng 逐步加压 + 温度日志 |
+| D11 | 跨档位性能连续曲线 | 图表 | P1 | 已完成档位实测 + 后续档位条件补充；未完成档位不写成正式结果 |
+| D12 | 优越性量化结论矩阵 | 分析表 | P1 | D4+D6+D7 |
+| D13 | 环境元数据清单 (每份数据附) | 元数据 | P0 | 03-实验设计.md §11 模板 |
+
+---
+
+## 5. 写作优先级与依赖关系
+
+```
+Phase 0: BSP 适配 + 工具移植 (3 周)
+ ├─ SylixOS RK3588 BSP 部署
+ ├─ sysbench / stress-ng / RKLLM 移植验证
+ └─ vLLM / llama.cpp 在 SylixOS 编译运行
+
+Phase 1: 基准复现 + 文章骨架 (1.5 周)
+ ├─ D3: RK3588 基准复现 → D4: 业界对比表
+ ├─ 撰写: §1 引言 + §2 背景 + §3 验证矩阵 + §4 技术架构 + §5 方法学 + §6 模型选型
+ └─ 依赖: D3 通过 ±15% 对齐门 → 准入 Phase 2
+
+Phase 2: 低功耗测试 + 温度耦合 (2 周)
+ ├─ D7: 功耗曲线 + D10: 温度耦合曲线
+ └─ 撰写: §7.2 + §7.6
+
+Phase 3: 低延迟 + 混合负载测试 (3 周)
+ ├─ D5+D6: 混合负载核心证据 + D8: token 延迟直方图 + D9: 突发场景
+ └─ 撰写: §7.3 + §7.4 + §7.5
+
+Phase 4: 异构调度测试 (1 周)
+ ├─ 场景6: A76+A55+M0 异构分配
+ └─ 撰写: §7.7
+
+Phase 5: 数据汇总 + 深入分析 + 全文定稿 (2.5 周)
+ ├─ D11: 跨档位曲线 + D12: 优越性矩阵
+ ├─ 撰写: §7.8 + §8 深入分析 + §9 讨论 + §10 结论
+ └─ 全文校对 + 图表终版
+```
+
+**总周期: ~13 周** (Phase 0~5 累计)
+
+---
+
+## 6. 章节字数预算
+
+| 章节 | 预算字数 | 占比 |
+|------|---------|------|
+| §1 引言 | 400 | 4% |
+| §2 背景与相关工作 | 700 | 7% |
+| §3 T5~T1 五类部署形态验证矩阵 | 900 | 9% |
+| §4 技术架构 | 700 | 7% |
+| §5 实验方法学 | 900 | 9% |
+| §6 模型选型 | 600 | 6% |
+| §7 实验结果 | 1800 | 18% |
+| §8 深入分析 | 900 | 9% |
+| §9 讨论 | 500 | 5% |
+| §10 结论 | 350 | 3% |
+| 参考文献 + 附录 | ~2000 | 23% |
+| **总计** | **~9750** | 100% |
+
+> 注: 按 RTSS/RTAS 会议论文 10~12 页双栏计算, 正文约 8000~10000 词, 参考文献+附录另计。
+
+---
+
+## 7. 核心叙事线 (Storyline)
+
+```
+问题矛盾 (§1)
+ → 人工智能目标负载时效/有效性 vs 关键保障负载严格截止期, 在任务关键系统中必须共存
+ → 空白: 国产 RTOS 在任务关键系统中承载人工智能目标负载的系统化数据仍然稀缺
+
+背景铺垫 (§2)
+ → 人工智能目标负载的 CPU/内存/长尾特征
+ → RTOS 的 6 项调度优势 + 普通 Linux / PREEMPT_RT 的边界
+ → 第三方方法学引入 (5 维度 + 5 避坑)
+
+验证矩阵 (§3) ← C2 验证框架
+ → 11 档位连续展开: 1 GB/3 W → 2 TB/25 kW
+ → 现有 P0 零成本起步 (V100 + RK3588)
+ → 一机两档降本
+
+技术架构 (§4)
+ → 五层技术栈 + 六大优化方向
+ → LLM 推理 DAG → RTOS 任务映射
+ → BSP 适配要点与风险
+
+方法学 (§5) ← C1/C3 基础
+ → 第三方基准复现 (先对齐 ±15% 才准入)
+ → 双目标负载四原则 (核心设计)
+ → 功耗真测 + 温度监控 + 元数据强制
+
+模型选型 (§6)
+ → 跨 11 档位的 Qwen/LLaMA/MiniCPM/Whisper 矩阵
+ → INT4/INT8/FP16 量化梯度
+
+实验结果 (§7) ← 本文核心
+ → 7.1 基准对齐 (第一层门)
+ → 7.2~7.3 功耗/延迟 (基础指标)
+ → 7.4 双目标实时保障 (★ 核心证据)
+ → 7.5~7.7 并发/突发/异构
+ → 7.8 跨档位连续曲线
+
+深入分析 (§8)
+ → 档位间趋势: 哪些资源条件与拓扑更容易体现 RTOS 优势
+ → 优越性量化: 关键保障负载边界、人工智能目标负载时效与有效吞吐的联合改进
+ → 根因: 硬优先级 + 内存锁定 + 精简内核 + 中断亲和
+ → 能效: V100 基线 vs H100 上限, INT4 拐点
+
+讨论 (§9)
+ → 适用边界: T5/T4 更容易体现优势, T1-H 可能收窄
+ → 威胁有效性: RKLLM 移植/V100 驱动/sysbench 移植
+ → 与已有工作: vs vLLM/NPU SDK/CUDA Stream/第三方文章
+
+结论 (§10)
+ → 三大贡献量化回顾
+ → 跨平台/功能安全/分布式/自适应展望
+```
+
+---
+
+## 8. 待确认事项
+
+| 编号 | 待确认项 | 影响章节 | 当前假设 |
+|------|---------|---------|---------|
+| Q1 | SylixOS 在 x86+4×V100 NVLink 的 CUDA 驱动支持度 | §4.5, §7.3, §8.5 | 需翼辉确认; 单卡先行, 4 卡作 stretch |
+| Q2 | RK3588 BSP 是否集成 rknn/RKLLM | §5.2, §7.1, §9.2 | 需翼辉确认; 退路 llama.cpp CPU |
+| Q3 | sysbench/stress-ng 在 SylixOS 可移植性 | §5.2, §7.1 | POSIX 兼容, 假设可行 |
+| Q4 | T234 (Jetson Orin) BSP 是否支持 | §3.2 (T4-M / T3-L) | 风险高; T4-L 用 RK3588 起步 |
+| Q5 | RK3588 板卡是否引出 M0 调试接口 | §7.7 (场景6) | 若未引出, 场景6 需调整 |
+| Q6 | 是否纳入功能安全 SIL2/IEC 61508 章节 | §10.2 展望 | 暂列为展望, 不入正文 |
+| Q7 | 是否纳入昇腾 Qwen-7B 作为第二业界参照 | §7.1, §9.4 | 暂列为后续, 非本方案硬件 |
+| Q8 | 主对照组确认: Ubuntu 22.04+PREEMPT_RT | §5.7 | 与第三方文章配置一致, 可比性最高 |
+
+---
diff --git a/20-实验与规划/README.md b/20-实验与规划/README.md
new file mode 100644
index 0000000..b0b3871
--- /dev/null
+++ b/20-实验与规划/README.md
@@ -0,0 +1,24 @@
+# 实验与规划索引
+
+本目录放置“怎么验证”和“怎么写成成果”的文档，负责把研究框架落到硬件、实验、论文规划和证据链上。
+
+## 阅读建议
+
+1. `01-研究逻辑说明.md`
+2. `02-基础设备与算力基础.md`
+3. `03-实验设计.md`
+4. `04-论文写作规划.md`
+5. `05-论文结构总览.png`
+
+## 文件说明
+
+- `01-研究逻辑说明.md`
+ - 项目研究逻辑总说明，串起验证矩阵、实验方案和论文贡献
+- `02-基础设备与算力基础.md`
+ - T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则
+- `03-实验设计.md`
+ - 准入条件、对照原则、混合负载场景、指标与验收方法
+- `04-论文写作规划.md`
+ - 论文结构、章节分工、图表规划和证据映射
+- `05-论文结构总览.png`
+ - 文章结构与逻辑关系示意图
diff --git a/30-联合研究方/README.md b/30-联合研究方/README.md
new file mode 100644
index 0000000..1f070de
--- /dev/null
+++ b/30-联合研究方/README.md
@@ -0,0 +1,21 @@
+# 联合研究方索引
+
+本目录用于存放与项目潜在合作方、教授、团队背景有关的资料，服务于联合研究、外部沟通和人物画像整理。
+
+## 当前内容
+
+- `潜在合作研究路径-罗蕾教授与翼辉信息.md`
+ - 面向项目内部的合作设想文档
+ - 梳理罗蕾教授与翼辉信息在联合研究中的角色分工与协同结构
+- `罗蕾教授资料/`
+ - 电子科技大学知名专家学者罗蕾教授背景与研究工作介绍
+ - 包含人物概览、教学与人才培养、科研与产业化路径、代表成果与研究主题
+- `翼辉信息资料/`
+ - 具有较强行业代表性的 RTOS 与基础软件平台厂商翼辉信息与 SylixOS 平台介绍
+ - 包含公司与 RTOS 定位概览、SylixOS 技术能力与演进、行业落地与生态版图、与本项目的潜在协同点
+
+## 使用建议
+
+- 对外沟通时，可先阅读人物概览与科研路径两篇。
+- 讨论合作路径时，可先阅读 `潜在合作研究路径-罗蕾教授与翼辉信息.md`，但需注意其性质是内部筹划稿，不代表对方已确认加入。
+- 形成合作建议时，可结合本仓库 `00-项目总览/` 与 `20-实验与规划/` 一起使用。
diff --git a/30-联合研究方/潜在合作研究路径-罗蕾教授与翼辉信息.md b/30-联合研究方/潜在合作研究路径-罗蕾教授与翼辉信息.md
new file mode 100644
index 0000000..c45c6fe
--- /dev/null
+++ b/30-联合研究方/潜在合作研究路径-罗蕾教授与翼辉信息.md
@@ -0,0 +1,194 @@
+# 潜在合作研究路径：罗蕾教授与翼辉信息
+
+> 说明：本文用于项目内部的合作筹划与分工设计，服务于联合研究中的角色划分、协同结构设计与前期沟通准备。
+
+## 1. 两个合作方的协同结构
+
+本项目对应的是一个典型的“**学术问题定义 + 系统机制设计 + 产业平台验证**”三段式问题：
+
+1. 需要有人把研究问题定义清楚，并把方法学、可调度性分析、评价体系和论文表达做扎实；
+2. 需要有人把 RTOS 机制、工具链、BSP、系统实现和真实行业场景接起来；
+3. 需要把两者合成一个既能发表、又能落地、还能与产业沟通的闭环。
+
+在这个结构里，罗蕾教授与翼辉信息的优势方向并不相同，但恰好可以形成互补：
+
+- **罗蕾教授**作为电子科技大学相关领域广受尊重的知名专家学者，更适合承担研究方法、系统建模、学术组织与标准化表达这一侧；
+- **翼辉信息**作为大型实时操作系统与基础软件平台领域极具代表性的产业样本，更适合承担 SylixOS 平台、工程实现、场景验证与产业落地这一侧。
+
+合作路径可以让两个合作方分别占据研究闭环中的不同位置。
+
+## 2. 罗蕾教授更适合承担的合作角色
+
+基于其长期研究积累与代表成果，罗蕾教授更适合在下面几个方向发挥作用：
+
+### 2.1 研究问题与方法学共建
+
+罗蕾教授长期积累的重点在嵌入式实时操作系统、可调度性分析、汽车电子基础软件、安全隔离与系统工程化。这位在相关领域享有较高声誉的专家学者，尤其适合参与：
+
+- 研究问题的学术化表述；
+- `RQ1~RQ4` 的研究问题拆解；
+- `O0/O1/O2/O3` 对照逻辑的合理性论证；
+- `TTFT/TPOT + deadline miss + jitter + 系统协同` 这套双目标指标体系的学术组织；
+- 长稳、突发、恢复、消融等实验类型的论文化组织。
+
+罗蕾教授更适合帮助项目把工程现象组织成可发表的系统研究问题。
+
+### 2.2 系统建模与分析工具链
+
+罗蕾教授在实时系统建模、AADL 可调度性分析、AUTOSAR 任务映射、隔离保护等方向已有持续积累，因此她适合参与：
+
+- 关键保障负载的任务模型抽象；
+- 人工智能目标负载进入系统后的实时约束建模；
+- 基于 `RTA/WCET` 的边界分析；
+- 任务映射、优先级分配、资源预算与配额约束的分析框架；
+- 从实验结果回推系统机制成立条件的理论解释。
+
+这一部分做扎实后，项目可以形成“机制 - 结果 - 边界”三位一体的研究结构。
+
+### 2.3 学术产出与标准化表达
+
+罗蕾教授长期处在“研究 - 标准 - 产业化”打通的路径上，因此她也适合参与：
+
+- 论文结构与贡献凝练；
+- 学术报告和项目申报材料；
+- 将系统机制抽象为可推广的方法学；
+- 后续延伸到行业测试规范或联合白皮书时，可协助形成更规范的表达。
+
+## 3. 翼辉信息更适合承担的合作角色
+
+翼辉信息的价值首先体现在其所代表的 **SylixOS 大型跨平台实时操作系统平台** 与行业落地经验。作为国内 RTOS 与关键基础软件方向颇具代表性的企业样本，翼辉信息在合作设想中具备很高的参考价值。
+
+### 3.1 主实验样例与平台能力提供方
+
+翼辉信息最适合承担的第一角色，是 `SylixOS` 主实验样例的提供与支撑，包括：
+
+- SylixOS 版本、配置、调度参数与机制能力说明；
+- BSP、驱动、工具链、trace/观测接口支持；
+- SMP、多核绑定、中断治理、内存锁定、隔离机制等平台能力验证；
+- 针对任务关键系统场景的默认配置与优化配置对照。
+
+这一部分决定了项目能否把“研究对象”落实到一套可验证的 RTOS 平台上。
+
+### 3.2 工程实现与系统机制落地
+
+翼辉信息也适合参与系统机制层的实现与验证，例如：
+
+- 人工智能目标负载与关键保障负载的优先级/配额治理；
+- 核隔离、IRQ 亲和、设备中断分流；
+- KV Cache、内存池、DMA/I/O 路径的系统治理；
+- 长稳运行、恢复策略、故障隔离和资源回收机制；
+- 不同部署形态下的实际可部署方案。
+
+这部分决定了项目能否从“方法论文档”走到“工程上真的成立”。
+
+### 3.3 行业场景与产业验证语境
+
+翼辉信息长期服务于航天、轨道交通、电力、工业自动化、智能汽车等任务关键行业，因此它更适合提供：
+
+- 任务关键系统的真实负载语境；
+- 典型关键保障任务模板；
+- 更贴近行业的干扰链路和恢复要求；
+- 对“结果是否具有产业解释力”的判断。
+
+这一部分非常重要，因为它会决定研究结果是不是只在实验室里成立。
+
+## 4. 三方合作的分工结构
+
+本项目可按“三方闭环”来组织：
+
+- **罗蕾教授侧**：负责研究问题定义、系统建模、方法学审阅、论文组织与学术表达增强；
+- **翼辉信息侧**：负责 SylixOS 平台支撑、机制实现接口、工程验证条件与产业场景输入；
+- **我们项目组**：负责前期调研、实验执行、资料整理、跨平台对照实现与协同支撑。
+
+可以把它理解成下面这条链路：
+
+`研究问题定义 -> 方法学与分析框架 -> RTOS 机制实现 -> 实验验证 -> 论文与白皮书表达`
+
+其中：
+
+- 罗蕾教授更靠前半段和总结抽象；
+- 翼辉信息更靠中间实现与后端产业验证；
+- 项目组负责根据合作方的方向与建议，把实验推进、资料整合和执行工作衔接起来。
+
+## 5. 可优先推进的合作研究主题
+
+合作讨论可以优先围绕下面几类题目推进：
+
+### 5.1 双目标实时保障基准共建
+
+目标：
+
+- 联合定义一套面向任务关键系统的 AI 目标负载 + 关键保障负载基准；
+- 统一 `TTFT/TPOT`、`deadline miss`、`P99/P99.9 jitter`、`E/token` 等指标；
+- 明确 `G0~G4` 准入和 `O0~O4` 对照逻辑。
+
+更适合的分工：
+
+- 罗蕾教授侧负责方法学与指标体系合理性；
+- 翼辉信息侧负责 SylixOS 落地和观测手段；
+- 项目组负责实验编排、数据整理和协同落实。
+
+### 5.2 任务关键系统中的 AI 负载准入与隔离机制
+
+目标：
+
+- 研究人工智能目标负载进入系统后，如何通过配额、优先级、核绑定、时间预算、内存预算等机制维持关键保障任务边界；
+- 给出“哪些条件下准入、哪些条件下拒绝、哪些条件下需要降级运行”的规则。
+
+更适合的分工：
+
+- 罗蕾教授侧偏规则建模和边界分析；
+- 翼辉信息侧偏机制实现和可部署性验证。
+
+### 5.3 面向实际行业场景的 SylixOS 机制验证
+
+目标：
+
+- 选择 1~2 个更贴近行业的关键场景，如工业控制、车载控制、边缘智能节点；
+- 把实验从抽象负载推进到“有行业解释力”的场景负载。
+
+更适合的分工：
+
+- 翼辉信息侧提供场景输入和系统约束；
+- 罗蕾教授侧帮助把场景抽象成学术上可论证的问题。
+
+### 5.4 联合论文 / 白皮书 / 申报材料
+
+目标：
+
+- 学术上形成论文；
+- 产业上形成白皮书或联合研究说明；
+- 条件成熟后，再进一步走项目申报、平台共建或联合实验室路径。
+
+更适合的分工：
+
+- 罗蕾教授侧偏学术与规范表达；
+- 翼辉信息侧偏产业价值、案例与平台能力；
+- 项目组承担材料汇总、写作配合与整合支撑。
+
+## 6. 更现实的推进顺序
+
+推进顺序以稳妥、小步、可验证为宜：
+
+1. **先分别沟通**：确认双方对课题定位、研究边界、合作兴趣是否一致；
+2. **先小后大**：先围绕一个具体问题试合作，例如基准设计、实验审阅或场景讨论；
+3. **先方法后平台**：先把研究问题和方法学框架对齐，再谈平台实现细节；
+4. **先形成最小闭环**：先做出一版可验证的实验与分析，再决定是否扩展成正式联合研究。
+
+## 7. 当前文档使用边界
+
+这份文档当前更适合作为：
+
+- 项目内部筹划材料；
+- 对外沟通前的思路整理；
+- 预判双方合作接口是否互补的参考稿。
+
+当前使用场景包括：
+
+- 项目内部筹划与分工设计；
+- 对外沟通前的内容准备；
+- 合作接口与协同结构的前期梳理。
+
+这份文档回答的是：
+
+> **与罗蕾教授、翼辉信息形成联合研究时，最合理的合作结构是什么。**
diff --git a/30-联合研究方/罗蕾教授资料/01-人物概览.md b/30-联合研究方/罗蕾教授资料/01-人物概览.md
new file mode 100644
index 0000000..6afdc14
--- /dev/null
+++ b/30-联合研究方/罗蕾教授资料/01-人物概览.md
@@ -0,0 +1,18 @@
+# 罗蕾教授人物概览
+
+罗蕾教授是电子科技大学教授、博士生导师，长期在电子科技大学从事嵌入式基础软件相关教学、科研与产业化工作。她曾任嵌入式软件工程中心主任，持续聚焦嵌入式操作系统、物联网网络安全与数据安全、工业软件、智能计算等方向，是电子科技大学在嵌入式系统与相关产业应用领域具有较高影响力、广受尊重的知名专家学者。
+
+罗蕾教授与电子科技大学保持了长期稳定的学术关联。她于 1987 年毕业于电子科技大学计算机系，1996 年晋升副教授，2003 年评为教授，2005 年晋升博士生导师。她既是学校本土培养起来的教师，也长期参与了学科建设、课程建设与团队建设。
+
+罗蕾教授的工作范围已经超出了传统高校教师的单一角色。她曾作为国家“核高基”专家参与智能手机、汽车电子、数字电视等多项嵌入式基础软件重大专项实施，同时担任国家智能网联汽车创新中心专家、车载信息服务产业应用联盟（TIAA）网络安全委员会秘书长、工信部区块链技术与数据安全重点实验室相关专家等职务。她的工作位置也因此横跨了高校、重大专项、行业联盟和产业协同几个层面。
+
+罗蕾教授的研究主线是一条逐步扩展的“底层软件到行业场景”的路线。较早阶段，她的工作更多与嵌入式实时操作系统、嵌入式基础软件和开发工具有关；随后逐步延伸到汽车电子、物联网安全、移动支付、区块链与数据安全，再到今天更强调工业软件、网络安全和智能计算。这种演进很有代表性，反映出她的研究沿着产业需求不断外扩。
+
+罗蕾教授是一位具有明显“工程化导向”和产业连接能力、在相关领域享有较高声誉的知名专家学者。她既有学校内部的学术与教学身份，也深度参与国家项目、行业标准和企业合作；既关注嵌入式系统的底层技术，又把研究延伸到汽车、支付、数据安全等具体行业。她的个人画像体现出“学术研究者 + 工程组织者 + 产业连接者”的复合型角色。
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：
+2. 电子科技大学研招导师风采页：
+3. 电子科技大学计算机学院科研团队页：
+4. 科创中国个人主页：
diff --git a/30-联合研究方/罗蕾教授资料/02-教学与人才培养.md b/30-联合研究方/罗蕾教授资料/02-教学与人才培养.md
new file mode 100644
index 0000000..7aae785
--- /dev/null
+++ b/30-联合研究方/罗蕾教授资料/02-教学与人才培养.md
@@ -0,0 +1,20 @@
+# 罗蕾教授的教学与人才培养工作
+
+罗蕾教授不仅是一位在嵌入式系统领域具有较高影响力的专家学者，也长期深度投入教学工作。她的教学工作有一个很明显的特点：围绕一门核心课程，把教材、实验、课程资源和人才培养体系连在一起。
+
+最能代表这一点的课程，是《嵌入式系统及应用》。这门课早在 2007 年就获得国家精品课程认定，之后又先后成为四川省精品资源共享课、四川省精品在线开放课程，并在 2023 年获得国家级一流本科课程认定。它是一门经过多年迭代、持续建设的核心课程。
+
+这门课是一门典型的工程化课程。课程内容覆盖嵌入式系统导论、ARM 体系结构与编程、嵌入式软件系统、任务管理与调度、同步互斥与通信、中断时间和内存管理等主题，并配有 ARM 实验和 uC/OS-II 操作系统实验。课程结构采用“原理 + 实验 + 开发能力”的组织方式，目标是让学生真正进入嵌入式系统开发。
+
+罗蕾教授在教学上的另一个特点，是把教材建设和课程建设配套推进。她主编过《嵌入式实时操作系统及应用开发》第一、二、三版，以及《嵌入式系统及应用》等著作。对一门工科课程来说，教材是否成体系，往往决定了课程能否长期稳定传承；她也由此搭建起一个可复制、可持续的知识框架。
+
+罗蕾教授的人才培养方向也比较清晰。她指导的软件工程、电子信息等学位点，研究方向主要包括嵌入式软件技术与应用、工业软件、网络安全、智能计算等。这些方向既有传统的嵌入式系统主线，也对接了当下工业软件和安全计算的需求。她的人才培养模式强调“从基础软件出发，向新应用场景延展”。
+
+罗蕾教授在教学上的重要性，体现在她于电子科技大学长期建设出了一套有工程背景、有实验支持、有教材配套、能持续培养学生的嵌入式教学体系。这也是这位知名专家学者在校内外形成广泛学术影响力的重要来源之一。
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：
+2. 电子科技大学计算机学院教学成果页：
+3. 中国大学 MOOC《嵌入式系统及应用》课程页：
+4. 电子科技大学教学资源平台课程页：
diff --git a/30-联合研究方/罗蕾教授资料/03-科研与产业化路径.md b/30-联合研究方/罗蕾教授资料/03-科研与产业化路径.md
new file mode 100644
index 0000000..a5142dd
--- /dev/null
+++ b/30-联合研究方/罗蕾教授资料/03-科研与产业化路径.md
@@ -0,0 +1,21 @@
+# 罗蕾教授的科研与产业化路径
+
+罗蕾教授的科研工作持续把嵌入式基础软件能力往产业场景里推进。作为电子科技大学相关方向具有代表性的知名专家学者，她长期主持或参与国家重大专项、863 项目、自然科学基金、发改委软件产业化专项等任务，同时又深度参与企业合作、行业标准与联盟工作。这种“研究 - 标准 - 产品 - 场景”连起来的路径，是她区别于很多纯学院型学者的重要地方。
+
+她早期的重要发力点是嵌入式基础软件和实时操作系统。她曾主持“面向嵌入式软件的生产线”“智能手机嵌入式软件平台”“嵌入式实时操作系统及其开发工具”等项目，所在团队也长期围绕嵌入式操作系统、嵌入式网络安全、汽车电子基础软件展开工作。这类方向的共同点，是都处在系统底层，技术门槛高、复用价值大，而且很容易形成行业平台能力。
+
+之后，她的科研和产业化路径逐步向汽车电子和网络安全方向深化。团队列出的代表性项目里，既有“汽车电子网络安全标准化研究白皮书编制”“面向汽车电子的代码安全技术研究与实现”，也有“智能汽车安全加固与监控产品研发与产业化”“车辆身份唯一性认证模型的测试委托”等项目。罗蕾教授的工作集中在汽车电子基础软件、代码安全、身份认证、网络安全标准等更底层、更可落地的位置。
+
+同时，她的团队也明显向区块链与数据安全扩展。相关成果包括区块链基础平台“优云链”和面向数据共享的“优数”平台，应用场景覆盖无人机运输物流追踪、汽车大数据交易平台、学分银行、移动支付可信数据共享联盟链、国际贸易通关协同、财政资金监管等。她所推动的区块链工作与数据确权、共享交换、可信交易、安全监管等产业需求直接挂钩。
+
+除了项目本身，罗蕾教授在行业规则层面的参与也很值得关注。她牵头或参与了 20 余项国家、行业和团体标准，团队也参与了多项汽车网络安全相关国家标准与行业标准。她的影响力同时体现在技术落地和行业通用规则推进两个层面。对很多产业技术路线来说，这一步往往比单点成果更有长期影响。
+
+她的科研路径可以概括为三层：第一层是嵌入式操作系统、开发工具和基础软件；第二层是网络安全、汽车电子、物联网与数据安全；第三层是标准化、产业平台和企业合作落地。正因为这三层是打通的，罗蕾教授的工作才呈现出很强的“工程系统型”特征，并形成了连续展开的研究主题体系。
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：
+2. 电子科技大学研招导师风采页：
+3. 电子科技大学计算机学院科研团队页：
+4. 科创中国个人主页：
+5. 世展网转载行业观点文章：
diff --git a/30-联合研究方/罗蕾教授资料/04-代表成果与研究主题.md b/30-联合研究方/罗蕾教授资料/04-代表成果与研究主题.md
new file mode 100644
index 0000000..848d763
--- /dev/null
+++ b/30-联合研究方/罗蕾教授资料/04-代表成果与研究主题.md
@@ -0,0 +1,29 @@
+# 罗蕾教授的代表成果与研究主题
+
+罗蕾教授作为电子科技大学相关方向具有较高影响力的知名专家学者，其研究主题围绕“嵌入式系统底层能力如何支持复杂场景”逐步展开。她较有代表性的成果，大致可以分成四个方向：嵌入式实时操作系统、汽车电子基础软件与安全、网络与数据安全、以及面向新场景的智能计算延展。
+
+第一类成果是嵌入式实时操作系统与基础软件。罗蕾教授主编过《嵌入式实时操作系统及应用开发》和《嵌入式系统及应用》等教材，导师页面列出的代表论文也长期围绕任务调度、GUI、多任务系统、AADL 可调度性分析等主题展开。比如 `UCaS: a schedulability analysis tool for AADL models` 这类工作，体现的是她早期在嵌入式软件建模与调度分析方面的积累。这个方向的核心关键词，是实时性、可调度性和基础软件工程化。
+
+第二类成果是汽车电子嵌入式操作系统与 AUTOSAR 相关研究。比较典型的论文包括《汽车电子嵌入式操作系统的隔离保护机制》和《AUTOSAR 可运行实体-任务自动映射方法研究》。前者关注的是在有限硬件资源下实现多层级隔离保护，以降低系统整体失效概率；后者则围绕 ECU 配置和实时系统任务映射，提高汽车软件开发效率。她在汽车电子方向持续关注操作系统机制、安全隔离和软件架构配置这类关键底层问题。
+
+第三类成果是网络安全与数据安全。她及其团队长期从事物联网安全、区块链与数据安全工作，形成了“优云链”“优数”等成果，并将其用于物流追踪、汽车数据交易、移动支付可信共享等场景。论文成果也体现出她团队在入侵检测、代码混淆安全模型、异常检测等方面的持续投入。这部分工作的意义，在于把原本偏底层的软件能力继续向数据可信、安全共享和行业安全运营延伸。
+
+第四类成果是跨向智能计算与新型应用场景的延展。较新的培养方向已经覆盖工业软件、网络安全、智能计算，团队介绍中也把深度学习、自然语言处理、移动 AR、嵌入式 AI 列为主要研究方向之一。罗蕾教授的研究由此延伸到智能化应用场景。
+
+罗蕾教授的代表性工作始终围绕两个问题展开：一是如何把系统底层做稳，特别是实时性、可靠性、安全性和可配置性；二是如何让这些底层能力进入实际产业系统，服务汽车电子、物联网、支付和数据共享等复杂场景。这也是她作为知名专家学者，能够同时出现在学术导师页面、课程建设页面、科研团队页面和行业合作资料里的重要原因。
+
+## 可关注的公开代表成果
+
+- `汽车电子嵌入式操作系统的隔离保护机制`
+- `AUTOSAR可运行实体-任务自动映射方法研究`
+- `A Cross-platform Mobile Payment Solution Based on Web Technology`
+- `UCaS: a schedulability analysis tool for AADL models`
+- `An intrusion detection system integrating network-level intrusion detection and host-level intrusion detection`
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：
+2. 电子科技大学计算机学院科研团队页：
+3. 电子科技大学学报相关论文页：
+4. 学术摘要页《汽车电子嵌入式操作系统的隔离保护机制》：
+5. 维普摘要页《AUTOSAR可运行实体-任务自动映射方法研究》：
diff --git a/30-联合研究方/罗蕾教授资料/README.md b/30-联合研究方/罗蕾教授资料/README.md
new file mode 100644
index 0000000..51aa5e9
--- /dev/null
+++ b/30-联合研究方/罗蕾教授资料/README.md
@@ -0,0 +1,15 @@
+# 罗蕾教授资料目录
+
+本目录用于介绍罗蕾教授的学术背景、教学工作、科研路径与代表性研究主题，并将内容拆分为几篇可以独立阅读的介绍文章。
+
+## 文件列表
+
+- `01-人物概览.md`：聚焦罗蕾教授的基本履历、学术身份与整体定位。
+- `02-教学与人才培养.md`：聚焦课程建设、教材编写与人才培养工作。
+- `03-科研与产业化路径.md`：聚焦科研方向、重大项目、行业标准与产业合作。
+- `04-代表成果与研究主题.md`：聚焦代表性研究主题、论文与技术成果。
+
+## 使用说明
+
+- 各文档彼此独立，可单独转发或继续扩写。
+- 各文档正文以人物介绍和研究工作为主，参考资料统一列于文末。
diff --git a/30-联合研究方/翼辉信息资料/01-公司与RTOS定位概览.md b/30-联合研究方/翼辉信息资料/01-公司与RTOS定位概览.md
new file mode 100644
index 0000000..6a0d765
--- /dev/null
+++ b/30-联合研究方/翼辉信息资料/01-公司与RTOS定位概览.md
@@ -0,0 +1,28 @@
+# 翼辉信息与大型实时操作系统定位概览
+
+翼辉信息在本项目中对应的是**面向任务关键系统的大型跨平台实时操作系统平台**。SylixOS 的核心价值集中在复杂系统中的实时软件底座能力，即维持确定性、可预测性和系统边界。
+
+翼辉信息长期围绕 SylixOS 展开自身定位，定位为“软件定义智能装备业内领先的基础软件架构供应商”，强调基于原创工业操作系统和整体软件架构技术，为火箭、卫星、高铁、大飞机、无人设备、电网电站、工业自动化、智能汽车等任务关键型智能设备提供稳定、可靠、安全的软件系统方案。其平台能力覆盖**关键行业、复杂系统、长期交付和基础平台能力**，在相关领域具备较强代表性和较高行业辨识度。
+
+翼辉信息最核心的产品身份是“**大型实时操作系统**”。SylixOS 的核心能力包括：SMP 多核实时调度、多处理器架构支持、动态装载、POSIX 兼容、高安全高可靠、复杂系统集成，以及长期版本维护。SylixOS 承担的是更高层次的软件平台职责：在不同硬件架构、不同规模平台和不同关键行业约束下，为复杂任务提供统一、稳定且可演进的实时操作系统基础。
+
+本项目围绕的大型跨平台实时操作系统平台，正与翼辉信息所代表的平台能力直接对应。翼辉信息提供的是一种可以跨平台承载、跨行业验证、并且天然面向任务关键场景的 RTOS 平台样本。
+
+翼辉团队的技术起点可追溯到 2006 年，随后在 2015 年公司化运营。SylixOS 内核经过工信部赛普测评中心源代码测评，自主化率达到 100%，并获得德国 TÜV SUD 集团颁发的 IEC 61508（SIL3）、EN 50128（SIL4）和 ISO 26262（ASIL D）认证。翼辉信息已经进入高安全、高可靠、高约束行业的软件平台提供方序列，是非常值得重视、也颇具分量的**产业级实时操作系统案例**。
+
+除了 SylixOS 内核本身，翼辉信息还呈现出一条从 RTOS 向完整基础软件栈外扩的路径。其产品和能力包括 RealEvo 开发环境、VSOA 分布式软总线、任务关键型云原生体系、工业自动化数字基座、飞控与仿真产品等。翼辉正在把实时操作系统扩展为面向关键装备的软件平台。这种平台化能力与本项目的验证方向高度一致。
+
+翼辉信息在本项目中的身份可以表述为：**面向关键行业的大型跨平台实时操作系统与基础软件平台提供方**。作为产业落地样本，它能够直接支撑与实时调度、关键系统约束、复杂工程交付相关的课题论证。
+
+## 对本项目最有价值的定位结论
+
+1. 翼辉信息代表的是**大型跨平台实时操作系统平台**。
+2. SylixOS 的核心价值体现在**复杂系统中的实时性、确定性与平台能力**。
+3. 翼辉信息更适合作为**产业级 RTOS 案例**。
+4. 它能够帮助本项目围绕“实时操作系统如何治理智能负载进入任务关键系统后的边界问题”展开产业样本验证。
+
+## 参考资料
+
+1. 翼辉信息官网首页：
+2. 翼辉信息官网 About 页面：
+3. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：
diff --git a/30-联合研究方/翼辉信息资料/02-SylixOS技术能力与演进.md b/30-联合研究方/翼辉信息资料/02-SylixOS技术能力与演进.md
new file mode 100644
index 0000000..642a05a
--- /dev/null
+++ b/30-联合研究方/翼辉信息资料/02-SylixOS技术能力与演进.md
@@ -0,0 +1,17 @@
+# SylixOS 技术能力与演进
+
+SylixOS 是翼辉信息的核心技术载体，是一款支持 SMP 多核实时调度、可运行于多种 CPU 架构目标平台的“大型实时操作系统”。其工程积累集中体现在调度、隔离、兼容性和长期演进能力上。
+
+SylixOS 的内核在 2006 年完成，最初具备线程调度、中断管理、定时器、RMS、信号量等核心机制；随后逐步加入 I/O、网络、文件系统、内存管理、POSIX 支持、C++ 支持、GDB 调试、Qt 支持和更广泛的平台适配。2011 年开始支持多核和动态装载；2012 年开始支持进程；2018 年全面支持 C-SKY 和 RISC-V；2020 年推出 LTS 版本；2021 年通过 IEC 61508（SIL3）和 EN 50128（SIL4）国际安全认证；2022 年进一步通过 ISO 26262（ASIL D）认证并支持 LoongArch。SylixOS 持续朝着可落地的大型实时系统平台演进。
+
+SylixOS 对多核与异构调度的强调，也与本项目高度相关。其 2023 年 V3.0.0 阶段已经开始支持异构算力大小核处理器，并提供灵活高效的调度器与调度策略，在算力和功耗之间取得平衡。这一能力与 LLM 推理线程、实时控制任务在共享 CPU、缓存和内存资源时的冲突控制直接相关。SylixOS 在大小核调度、SMP 调度策略、长期版本维护和实时性保障上的成熟能力，也使其非常适合作为实验平台或联合验证对象。
+
+SylixOS 周边能力也比较完整。其支持多种 CPU 架构，强调强实时、高安全、高可靠；同时配套 RealEvo 开发环境、仿真与远程开发能力，甚至扩展到容器、分布式软总线和任务关键型云原生体系。它已经形成较完整的软件工程与集成配套。对研究项目而言，这种配套能力很关键，因为很多真实工业验证会卡在工具链、仿真环境、应用移植和系统验证流程上。
+
+SylixOS 主要承担 RTOS 与基础软件底座角色。在本项目语境下，研究重点是 SylixOS 这类 RTOS 如何对 AI 推理任务进行资源隔离、优先级控制、实时保障和系统级治理。
+
+## 参考资料
+
+1. SylixOS 官方文档《发展历程》：
+2. 翼辉信息官网首页：
+3. 翼辉信息官网 About 页面：
diff --git a/30-联合研究方/翼辉信息资料/03-行业落地与生态版图.md b/30-联合研究方/翼辉信息资料/03-行业落地与生态版图.md
new file mode 100644
index 0000000..286c951
--- /dev/null
+++ b/30-联合研究方/翼辉信息资料/03-行业落地与生态版图.md
@@ -0,0 +1,18 @@
+# 行业落地与生态版图
+
+翼辉信息持续进入关键行业落地场景，其服务对象集中在火箭、卫星、高铁、大飞机、工业自动化、能源电力、智能汽车、低空经济等任务关键型装备领域。这些行业共同要求硬实时或强实时、长期稳定、功能安全和工程可维护性。
+
+翼辉信息正在构建一套更完整的生态版图。除了 SylixOS 之外，公开展示的还包括 RealEvo 轻量开发环境、VSOA 分布式软总线、工业自动化数字基座、可编程控制器、虚拟 PLC、边缘计算机、飞控系统、飞行仿真平台等。其商业策略已延伸到“关键装备基础软件平台方”这一层级。对联合研究而言，这种生态化布局可以覆盖内核测评、整机验证、边缘控制、系统集成和行业样机落地等更宽的接口。
+
+行业案例与用户故事也体现出清晰的行业线索。首页展示了中国铁道科学研究院和星际荣耀的用户评价，前者强调轨交信号控制系统对功能安全、稳定性、实时性的苛刻要求，后者强调在火箭飞控场景中通过 RTOS 对复杂软件进行分层抽象的重要性。航天行业页面还提到，翼辉信息与相关航天单位开展深度合作，基于 SylixOS 的星载操作系统用于星务和载荷设备开发，并参与火箭控制器、卫星载荷等系统建设。翼辉的主要市场集中在高可靠装备场景。
+
+翼辉信息在南京的软件产业生态中也被作为“工业底层操作系统”代表企业来呈现。2026 年南京雨花台区公开报道提到，南京翼辉信息 2016 年落地软件谷，围绕 SylixOS 研发逐步形成产业能力，并将经验复制到水务、地铁运营、地下空间运维等场景。报道还提到其正推动人工智能、边缘计算与操作系统深度融合。翼辉的产业化路径已经覆盖军工之外的城市基础设施和工业场景。
+
+翼辉信息已经把 RTOS 能力嵌入了多个高要求行业场景，并在工具链、行业方案和系统架构层面继续外扩。对本项目而言，它既是实验平台的重要来源，也是后续验证场景和行业接口的重要支撑。
+
+## 参考资料
+
+1. 翼辉信息官网首页：
+2. 翼辉信息官网 About 页面：
+3. 翼辉信息航天行业页：
+4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：
diff --git a/30-联合研究方/翼辉信息资料/04-与本项目的潜在协同点.md b/30-联合研究方/翼辉信息资料/04-与本项目的潜在协同点.md
new file mode 100644
index 0000000..9c36f07
--- /dev/null
+++ b/30-联合研究方/翼辉信息资料/04-与本项目的潜在协同点.md
@@ -0,0 +1,38 @@
+# 与本项目的潜在协同点
+
+把翼辉信息放进本项目的联合研究方名单，能够为项目提供一个较有代表性的**产业落地案例**，帮助我们把课题从抽象的“实时操作系统理论”推进到“任务关键系统中的工程验证”。
+
+本项目围绕的大型跨平台实时操作系统平台比较，聚焦于五类硬件条件下智能负载进入任务关键系统后的确定性、可预测性与实时保障表现。翼辉信息对应的是一个面向关键行业长期演进的 RTOS 平台提供方，因此在这个课题中具有清晰的产业样本价值。
+
+第一，翼辉信息适合作为**基础平台型产业案例**。SylixOS 被持续定义为“大型实时操作系统”，其核心能力集中在 SMP 多核实时调度、跨处理器架构支持、动态装载、长期维护、高安全高可靠，以及面向复杂系统集成的工程能力。翼辉信息在这一结构中承担的是“系统级平台厂商”角色，与本项目的平台研究对象高度一致。
+
+第二，翼辉信息适合作为**任务关键系统落地语境下的验证样本**。其行业服务重点集中在轨道交通、航天、航空、电力、工业自动化、智能汽车等领域，这些场景共同要求系统长期稳定运行，并对时序、可靠性、安全性和工程交付有明确要求。翼辉这样的案例能够把研究问题放到具有明确时序边界和系统保障要求的工业语境中。
+
+第三，翼辉信息适合作为**RTOS 在任务关键场景中的边界控制能力**这一命题的产业对照载体。未来设计对照实验时，重点就在于同一类任务关键负载下，SylixOS 这类大型跨平台 RTOS 与标准 Linux、PREEMPT_RT Linux 这类通用或实时增强型系统相比，在 deadline miss、尾延迟、任务抖动、资源隔离和故障恢复上形成怎样的边界控制能力。翼辉的产业案例价值就在这里：它让这一研究命题可以被放到真实行业约束中讨论。
+
+第四，翼辉信息还适合作为**工程闭环能力的观察对象**。翼辉围绕 SylixOS 不仅提供内核，还扩展了开发环境、仿真、软总线、数字基座、任务关键型云原生与系统化交付能力。它已经形成一整套从内核到工具链再到行业集成的方法论。工程闭环能力也直接决定学术结论能否落到产业场景里。
+
+第五，翼辉信息在本项目中的价值集中在**实时操作系统平台、关键行业基础软件和系统治理能力**。围绕 SylixOS 这类大型跨平台 RTOS，可以进一步展开 AI 推理系统进入任务关键系统后的实时约束建模、优先级与配额控制、内存带宽与缓存竞争治理、大小核与能耗协同、容器化封装，以及控制任务不失稳条件下的系统级实验设计。
+
+翼辉信息为“大型跨平台实时操作系统在任务关键系统中的边界控制能力”这一研究命题，提供了一个能够落到关键行业、复杂系统和长期交付语境中的产业样本。
+
+## 作为产业落地案例时可重点强调的价值
+
+1. **平台定位**：翼辉代表的是大型跨平台实时操作系统平台。
+2. **场景准确**：其公开落地行业天然属于任务关键系统，比消费电子场景更能支撑课题成立。
+3. **对照准确**：便于把 SylixOS 与 Linux / PREEMPT_RT 等系统放到统一的工业约束下比较。
+4. **验证准确**：可从调度、隔离、故障恢复、能耗治理、系统集成多个层面观察 RTOS 的真实优势。
+
+## 可继续深挖的合作问题
+
+1. SylixOS 当前公开可支持到什么程度的 AI 推理运行时、边缘推理框架或异构算力调度能力。
+2. 在 SylixOS 平台上，实时控制任务与推理任务共存时可用的隔离手段包括哪些，例如核绑定、容器、时间分片、内存配额、设备访问权限控制等。
+3. 以翼辉作为产业落地案例时，对照组采用 Linux、PREEMPT_RT Linux，还是两者同时纳入。
+4. 能否联合定义一个面向任务关键系统的 AI 干扰基准测试，用于量化 deadline miss、尾延迟、抖动和能耗影响。
+
+## 参考资料
+
+1. 翼辉信息官网首页：
+2. 翼辉信息官网 About 页面：
+3. SylixOS 官方文档《发展历程》：
+4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：
diff --git a/30-联合研究方/翼辉信息资料/README.md b/30-联合研究方/翼辉信息资料/README.md
new file mode 100644
index 0000000..c049574
--- /dev/null
+++ b/30-联合研究方/翼辉信息资料/README.md
@@ -0,0 +1,15 @@
+# 翼辉信息资料目录
+
+本目录用于介绍翼辉信息及其 SylixOS 技术体系，服务于联合研究判断、产业协同沟通和 RTOS 技术路线分析。
+
+## 文件列表
+
+- `01-公司与RTOS定位概览.md`：聚焦翼辉信息的公司定位、核心产品和公开产业身份。
+- `02-SylixOS技术能力与演进.md`：聚焦 SylixOS 的技术特征、发展里程碑和能力边界。
+- `03-行业落地与生态版图.md`：聚焦翼辉信息在关键行业的应用方向、案例和生态布局。
+- `04-与本项目的潜在协同点.md`：聚焦翼辉信息与本项目“RTOS 管理 LLM 推理资源竞争”主题的结合点。
+
+## 使用说明
+
+- 各文档彼此独立，可单独阅读或继续扩写。
+- 正文以公司定位、平台能力和行业应用介绍为主，参考资料统一列于文末。
diff --git a/30-联合研究方/翼辉信息资料/翼辉SylixOS智能控制技术栈架构白皮书-v1.0.docx b/30-联合研究方/翼辉信息资料/翼辉SylixOS智能控制技术栈架构白皮书-v1.0.docx
new file mode 100644
index 0000000..033bc5b
Binary files /dev/null and b/30-联合研究方/翼辉信息资料/翼辉SylixOS智能控制技术栈架构白皮书-v1.0.docx differ
diff --git a/40-交付物/Word规范稿/基础设备.docx b/40-交付物/Word规范稿/基础设备.docx
new file mode 100644
index 0000000..c0c3554
Binary files /dev/null and b/40-交付物/Word规范稿/基础设备.docx differ
diff --git a/40-交付物/Word规范稿/基础说明.docx b/40-交付物/Word规范稿/基础说明.docx
new file mode 100644
index 0000000..481c04a
Binary files /dev/null and b/40-交付物/Word规范稿/基础说明.docx differ
diff --git a/40-交付物/Word规范稿/实验设计.docx b/40-交付物/Word规范稿/实验设计.docx
new file mode 100644
index 0000000..d407760
Binary files /dev/null and b/40-交付物/Word规范稿/实验设计.docx differ
diff --git a/40-交付物/Word规范稿/最终文章规划.docx b/40-交付物/Word规范稿/最终文章规划.docx
new file mode 100644
index 0000000..9ab4f76
Binary files /dev/null and b/40-交付物/Word规范稿/最终文章规划.docx differ
diff --git a/40-交付物/白皮书与汇报/最终文章规划.docx b/40-交付物/白皮书与汇报/最终文章规划.docx
new file mode 100644
index 0000000..9ab4f76
Binary files /dev/null and b/40-交付物/白皮书与汇报/最终文章规划.docx differ
diff --git a/90-归档/压缩包与杂项/rtos_llm_opt.zip b/90-归档/压缩包与杂项/rtos_llm_opt.zip
new file mode 100644
index 0000000..f351d5c
Binary files /dev/null and b/90-归档/压缩包与杂项/rtos_llm_opt.zip differ
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..d530ee6
--- /dev/null
+++ b/README.md
@@ -0,0 +1,42 @@
+# SylixOS LLM RTOS Research Repo
+
+本仓库现按“总览、研究框架、实验规划、外部资料、交付物、归档”六个层次组织，便于把研究主线、写作材料和外部导入内容分开维护。
+
+## 目录结构
+
+- `00-项目总览/`
+ - 当前研究问题与项目定位边界说明
+- `10-研究框架/`
+ - 核心研究框架
+ - 六个优化方向与方法学子文档
+- `20-实验与规划/`
+ - 硬件谱系
+ - 实验设计
+ - 研究逻辑说明
+ - 论文规划与配图
+- `30-联合研究方/`
+ - 联合研究方资料、人物背景与协作参考
+- `40-交付物/`
+ - Word 规范稿
+ - 白皮书与汇报输出
+- `90-归档/`
+ - 外部导入副本
+ - 压缩包与暂存杂项
+
+## 建议阅读顺序
+
+1. `00-项目总览/01-当前研究问题：背景、问题与挑战.md`
+2. `00-项目总览/02-研究定位与项目边界.md`
+3. `20-实验与规划/README.md`
+4. `20-实验与规划/01-研究逻辑说明.md`
+5. `20-实验与规划/02-基础设备与算力基础.md`
+6. `20-实验与规划/03-实验设计.md`
+7. `10-研究框架/README.md`
+8. `10-研究框架/00-整体研究框架.md`
+9. `20-实验与规划/04-论文写作规划.md`
+
+## 说明
+
+- `10-研究框架/00-整体研究框架.md` 与 `01~07` 子文档保持同目录，避免内部引用失效。
+- `20-实验与规划/` 中的核心规划文档保持同目录，便于交叉引用。
+- `90-归档/` 存放外部导入副本、压缩包与阶段性暂存内容。
diff --git a/reference_file/07-analysis-methods.md b/reference_file/07-analysis-methods.md
deleted file mode 100644
index 0013e42..0000000
--- a/reference_file/07-analysis-methods.md
+++ /dev/null
@@ -1,536 +0,0 @@
-# 方向7: 分析方法与评估工具链
-
-## 1. 方法论框架
-
-本研究的方法论遵循 **"建模 → 分析 → 实现 → 验证"** 的四步循环:
-
-```
-┌─────────────────────────────────────────────────────────┐
-│ Step 1: 基准测量 (Profiling) │
-│ - 不同平台上的LLM推理profile │
-│ - 延迟、带宽、能耗、中断频率 │
-├─────────────────────────────────────────────────────────┤
-│ Step 2: 建模 (Modeling) │
-│ - 推理图建模 (DAG) │
-│ - 调度模型 (Fixed Priority / EDF) │
-│ - 内存模型 (KV Cache pool) │
-│ - 能耗模型 (DVFS) │
-├─────────────────────────────────────────────────────────┤
-│ Step 3: 算法设计 (Algorithm Design) │
-│ - 基于模型分析设计调度/内存/协同策略 │
-│ - 理论分析 (WCET, WCL, Schedulability) │
-├─────────────────────────────────────────────────────────┤
-│ Step 4: 仿真验证 (Simulation) │
-│ - 在模拟环境中验证理论分析 │
-│ - 参数扫描 (不同模型/平台/负载) │
-├─────────────────────────────────────────────────────────┤
-│ Step 5: 原型实现 (Prototype) │
-│ - 在真实RTOS上实现关键模块 │
-│ - FreeRTOS / Zephyr + custom patches │
-├─────────────────────────────────────────────────────────┤
-│ Step 6: 实测对比 (Evaluation) │
-│ - 优化前后指标对比 │
-│ - 消融实验 (每个方向的独立贡献) │
-└─────────────────────────────────────────────────────────┘
-```
-
-## 2. 性能基准测量
-
-### 2.1 测量指标
-
-```
-┌───────────────────────────────────────────────────────────────┐
-│ Category | Metric | Tool │
-├─────────────────┼───────────────────────────┼────────────────┤
-│ Latency | TTFT, TPOT, WCL | RTOS Trace │
-│ Latency | Jitter (P50/P90/P99) | ftrace │
-│ Latency | Preemption overhead | perf │
-├─────────────────┼───────────────────────────┼────────────────┤
-│ Computation | FLOPs, MACs, Utilization | NPU/GPU Profiler│
-│ Computation | WCET per layer | RTOS Trace │
-│ Computation | Cache miss rate | ARM CCM/Perf │
-├─────────────────┼───────────────────────────┼────────────────┤
-│ Memory | Bandwidth utilization | DDR Profiler │
-│ Memory | KV Cache size/fragmentation| Custom tool │
-│ Memory | DMA throughput | DMA Profiler │
-├─────────────────┼───────────────────────────┼────────────────┤
-│ Power | Dynamic power per stage | Power Monitor │
-│ Power | Thermal profile | Thermal Sensor │
-│ Power | Energy per inference | Power Monitor │
-├─────────────────┼───────────────────────────┼────────────────┤
-│ Interrupt | IRQ rate per stage | GIC Profiler │
-│ Interrupt | ISR latency | RTOS Trace │
-│ Interrupt | Priority inversion count | Custom tool │
-└───────────────────────────────────────────────────────────────┘
-```
-
-### 2.2 Profile数据流
-
-```
-LLM Inference (Qwen2.5-1.5B on RK3588)
-│
-├── Layer Profile (per-layer computation time)
-│ Layer 1 Attn: 1.2ms, Layer 1 FFN: 0.8ms, ...
-│
-├── Memory Profile (bandwidth, cache, KV Cache)
-│ Read: 4.2GB/s, Write: 2.1GB/s, Cache hit: 85%
-│
-├── Power Profile (dynamic power, temperature)
-│ CPU: 120mW, NPU: 350mW, DDR: 80mW
-│ Temp: 62°C
-│
-├── Interrupt Profile (IRQ rate, latency)
-│ NPU IRQ: 320Hz, Avg latency: 2.3μs
-│
-└── Scheduling Profile (context switch, preemption)
- Context switches: 1280/inference, Avg overhead: 3.5μs
-```
-
-## 3. 调度可调度性分析
-
-### 3.1 Fixed Priority Scheduling (FPS)
-
-```
-Rate Monotonic Analysis (RMA):
-
- Utilization bound for n tasks:
- U_n = n × (2^(1/n) - 1)
-
- n=1: 69.3%
- n=2: 58.6%
- n=3: 53.2%
- n→∞: 69.3%
-
- For LLM with 6 task types (Attention, FFN, KV, etc.):
- U_6 = 6 × (2^(1/6) - 1) = 49.2%
-
- If total utilization ≤ 49.2%, system is schedulable
- (sufficient condition, not necessary)
-
-Response Time Analysis (RTA):
-
- R_i^(0) = C_i
- R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
-
- Iterate until R_i^(k+1) = R_i^(k) or R_i > D_i
-```
-
-### 3.2 Earliest Deadline First (EDF)
-
-```
-EDF Utilization Bound:
-
- n tasks → 100% utilization bound
- (necessary and sufficient)
-
- For LLM:
- Total utilization = Σ(C_i / T_i)
-
- C_i: WCET of each stage
- T_i: Period (inter-arrival time)
-
- If total util ≤ 100%, all deadlines met (under EDF)
-```
-
-### 3.3 Hybrid Scheduling Analysis
-
-```
-Hybrid = Fixed Priority (hard) + EDF (soft)
-
-Analysis:
- 1. Hard tasks: Analyze with RMA
- - Attention, FFN → Fixed priority
- - Check: R_attention ≤ D_attention
-
- 2. Soft tasks: Analyze with EDF within priority band
- - KV Cache, Tokenizer → EDF within their priority band
- - Check: Utilization soft ≤ 100% within band
-
- 3. Cross-band interference:
- - Hard tasks can preempt soft tasks
- - Soft task utilization needs hard task overhead
- - U_soft_adj = U_soft + U_hard (worst case)
-```
-
-## 4. WCET (Worst-Case Execution Time) 分析
-
-### 4.1 LLM各阶段的WCET估算
-
-```
-WCET Estimation Method:
-
- WCET_attention = Max(input_len) × FLOPs / Compute_speed
-
- For Qwen2.5-1.5B, max_seq=4096:
- FLOPs_attn = 2 × N_layers × d × seq × seq / heads
- = 2 × 32 × 2048 × 4096 × 4096 / 32
- ≈ 5.5 × 10^12 FLOPs
-
- At 1.0 TOPS (Int8):
- WCET_attn = 5.5 × 10^12 / 10^12 = 5.5s
- (theoretical max, not practical)
-
- Realistic: ~1.5 TOPS effective → 3.7s
-
- WCET_ffn = N_layers × d × seq × FLOPs_per_FF
- = 32 × 2048 × 1 × 4 × 2048 × 8
- ≈ 2.2 × 10^12 FLOPs
-
- WCET_ffn ≈ 1.5s (at 1.5 TOPS)
-
- WCET_total_prefill = WCET_attn + WCET_ffn ≈ 5.2s
- (for single token, batch=1)
-
- For batch=32, seq=4096:
- WCET_total_prefill ≈ 5.2s / 32 ≈ 160ms
-```
-
-### 4.2 影响WCET的因素
-
-```
-Factor | Impact on WCET | Variability
---------------------|-------------------|------------------
-Cache hit rate | ±20% | Highly variable
-Memory bandwidth | ±30% | Depends on system load
-NPU utilization | ±15% | Other tasks competing
-Thermal throttling | ±10% | Temperature dependent
-Preemption overhead | ±5μs per switch | Task graph dependent
-
-Worst Case WCET = Nominal WCET × (1 + max_violability)
- = 160ms × 1.65 ≈ 264ms
-```
-
-## 5. 仿真工具
-
-### 5.1 仿真层次
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│ Level 1: Cycle-Accurate Simulation │
-│ - gem5 / NN-SIM / GALSim │
-│ - 精确到时钟周期的模拟 │
-│ - 精度: 高, 速度: 慢 (hours for one inference) │
-│ - 用途: 验证WCET分析, 验证内存模型 │
-├─────────────────────────────────────────────────────────────┤
-│ Level 2: Architectural Simulation │
-│ - ARM fast model / QEMU │
-│ - 架构级模拟, 不考虑微架构细节 │
-│ - 精度: 中, 速度: 中 (minutes for one inference) │
-│ - 用途: 调度算法仿真, 参数扫描 │
-├─────────────────────────────────────────────────────────────┤
-│ Level 3: Abstract Simulation │
-│ - Custom simulation framework │
-│ - 抽象调度逻辑, 忽略微架构 │
-│ - 精度: 低, 速度: 快 (seconds for 100 inferences) │
-│ - 用途: 大规模参数扫描, 算法比较 │
-├─────────────────────────────────────────────────────────────┤
-│ Level 4: Analytical Modeling │
-│ - Mathematical models (RTA, Markov, Queueing) │
-│ - 纯数学分析, 无需仿真 │
-│ - 精度: 取决于假设, 速度: 即时 │
-│ - 用途: 论文理论分析, 快速验证 │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### 5.2 自定义仿真框架
-
-```
-// LLM RTOS仿真框架 (伪代码)
-class LLMSimulator {
- // LLM模型
- ModelConfig model; // Qwen2.5-1.5B config
- InferenceEngine engine; // Simulated inference engine
-
- // RTOS模型
- OSConfig os; // RTOS configuration
- Scheduler scheduler; // Simulated scheduler
- TaskGraph task_graph; // Simulated task graph
-
- // Hardware model
- HardwareModel hw; // Simulated hardware
- PowerModel power; // Simulated power
-
- // Run simulation
- SimResult run(Config config) {
- SimResult result;
-
- for (int i = 0; i < config.num_inferences; i++) {
- // 1. Generate input
- Input input = generate_input(config.workload);
-
- // 2. Simulate inference
- InferenceTrace trace = simulate_inference(input);
-
- // 3. Simulate scheduling
- ScheduleResult sched = simulate_scheduling(trace, config);
-
- // 4. Simulate power
- PowerResult pwr = simulate_power(trace, config);
-
- // 5. Accumulate results
- result.latency += trace.e2e_latency;
- result.energy += pwr.energy;
- result.jitter += trace.jitter;
- }
-
- return result;
- }
-};
-```
-
-## 6. 原型实现
-
-### 6.1 RTOS选择
-
-```
-Options:
-
- 1. FreeRTOS
- - 最成熟, 文档最多, 社区最大
- - 优点: 成熟、广泛支持、易于理解
- - 缺点: 功能有限, 无NUMA支持, 多核支持简单
- - 适用: MCU级、SoC级
-
- 2. Zephyr
- - 现代RTOS, 多架构支持
- - 优点: 现代设计、设备树支持、多架构
- - 缺点: 学习曲线, 文档不如FreeRTOS
- - 适用: 多平台, 特别是SoC级
-
- 3. RTX5 (Keil)
- - ARM官方RTOS
- - 优点: ARM优化, MDK集成
- - 缺点: 商业许可, 锁定ARM
- - 适用: ARM平台
-
- 4. RT-Thread
- - 中国RTOS, 功能丰富
- - 优点: 功能丰富, 中国社区
- - 缺点: 国际支持有限
- - 适用: 中国市场
-
-Recommendation: Start with FreeRTOS for MCU/SoC,
- then evaluate Zephyr for multi-platform.
-```
-
-### 6.2 原型架构
-
-```
-┌──────────────────────────────────────────────────────┐
-│ LLM Application Layer │
-│ - Inference API (user-facing) │
-│ - Batch manager │
-│ - Model loader │
-├──────────────────────────────────────────────────────┤
-│ Scheduling Engine (Custom RTOS patch) │
-│ - Hybrid scheduler (Fixed Priority + EDF) │
-│ - KV Cache manager │
-│ - Power controller │
-│ - IRQ handler extensions │
-├──────────────────────────────────────────────────────┤
-│ RTOS Core │
-│ - FreeRTOS / Zephyr │
-│ - Task management │
-│ - Synchronization (semaphore, mutex, event) │
-│ - Memory management │
-├──────────────────────────────────────────────────────┤
-│ Hardware Abstraction Layer │
-│ - NPU driver (custom or vendor) │
-│ - DMA controller │
-│ - Memory controller │
-│ - Power management (DVFS) │
-└──────────────────────────────────────────────────────┘
-```
-
-## 7. 评估指标
-
-### 7.1 核心指标
-
-```
-Primary Metrics:
- 1. Latency
- - TTFT (Time to First Token): 目标 < 200ms
- - TPOT (Time per Output Token): 目标 < 50ms
- - WCL (Worst-Case Latency): 目标 < 500ms
- - P99 Latency: 目标 < WCL
-
- 2. Throughput
- - Tokens per second: 目标 > 100 tok/s (edge)
- - Requests per second: 目标 > 10 rps
-
- 3. Energy
- - mJ per token: 目标 < 10 mJ/token (edge)
- - mW per tok/s: 目标 < 0.1 mW/(tok/s)
-
- 4. Determinism
- - Jitter (P99-P50): 目标 < 50ms
- - Deadline miss ratio: 目标 < 1%
-
- 5. Resource Utilization
- - CPU utilization: 目标 < 80%
- - Memory utilization: 目标 < 70%
- - NPU utilization: 目标 > 60% (efficient)
-```
-
-### 7.2 对比实验设计
-
-```
-Baseline vs. Proposed:
-
- Baseline:
- - Standard FreeRTOS scheduling (Fixed Priority)
- - No KV Cache optimization
- - No power-aware scheduling
- - No NPU协同优化
-
- Proposed:
- - Hybrid Priority + EDF
- - KV Cache pool + bandwidth-aware
- - DVFS + thermal-aware
- - NPU pipeline scheduling
-
- Results:
- Metric | Baseline | Proposed | Improvement
- ----------------|----------|----------|-----------
- TTFT | 450ms | 280ms | -38%
- TPOT | 80ms | 45ms | -44%
- P99 Latency | 620ms | 400ms | -35%
- Energy/token | 25mJ | 15mJ | -40%
- Jitter | 180ms | 60ms | -67%
- Deadline miss | 15% | 0.5% | -97%
- CPU util | 92% | 75% | -18%
-```
-
-## 8. 消融实验
-
-```
-Ablation Study: 验证每个方向的独立贡献
-
-Full System (all optimizations):
- TTFT = 280ms, Energy = 15mJ
-
- - No scheduling optimization:
- TTFT = 450ms (+61%)
-
- - No KV Cache optimization:
- TTFT = 380ms (+36%), Energy = 20mJ (+33%)
-
- - No power-aware:
- TTFT = 310ms (+11%), Energy = 22mJ (+47%)
-
- - No NPU协同:
- TTFT = 520ms (+86%), Energy = 35mJ (+133%)
-
- - No IRQ optimization:
- TTFT = 350ms (+25%), Jitter = 120ms (+100%)
-```
-
-## 9. 论文目标与结构
-
-### 9.1 目标会议/期刊
-
-```
-Top-Tier RTOS/Embedded Conferences:
- - RTSS (Real-Time Systems Symposium) - Top-tier
- - RTAS (Real-Time and Embedded Computing) - Top-tier
- - ISLPED (International Symposium on Low Power Electronics)
- - DAC (Design Automation Conference)
- - ASPLOS (Architecture-Supported Programming Languages)
-
-Top-Tier AI/ML Systems:
- - MLSys (Machine Learning Systems)
- - EuroSys
- - OSDI
-
-Secondary Conferences:
- - ERTCS (Embedded Real-Time Contest Systems)
- - ICEC (International Conference on Embedded Computing)
-```
-
-### 9.2 论文结构模板
-
-```
-Title: RT-LM: Real-Time Scheduling for Large Language Models
- on Edge Devices
-
-Abstract:
- LLM inference is becoming prevalent on edge devices, but
- existing scheduling systems lack real-time guarantees.
- We present RT-LM, a novel RTOS-based scheduling framework
- for LLM inference that provides deterministic latency
- while maximizing throughput and energy efficiency.
-
-1. Introduction
- - LLM on edge trend
- - Real-time challenges
- - Contribution overview
-
-2. Background & Motivation
- - LLM inference overview
- - RTOS fundamentals
- - Gap analysis
-
-3. System Overview
- - Architecture
- - Key components
-
-4. Inference Graph Scheduling
- - Task decomposition
- - Hybrid scheduling algorithm
- - RT analysis
-
-5. KV Cache Management
- - Memory pool design
- - Bandwidth-aware scheduling
-
-6. NPU-CPU Collaboration
- - Pipeline scheduling
- - Synchronization
-
-7. Power-Aware Scheduling
- - DVFS integration
- - Thermal management
-
-8. Evaluation
- - Experimental setup
- - Latency analysis
- - Throughput analysis
- - Energy analysis
- - Ablation study
-
-9. Related Work
-10. Conclusion
-```
-
-## 10. 关键里程碑
-
-```
-Phase 1 (Months 1-2): Literature review + profiling
- - Survey existing work
- - Profile LLM on target platform
- - Establish baseline metrics
-
-Phase 2 (Months 3-4): Model design + analysis
- - Task graph modeling
- - WCET analysis
- - Scheduling algorithm design
-
-Phase 3 (Months 5-6): Implementation
- - FreeRTOS patch
- - KV Cache manager
- - Power controller
-
-Phase 4 (Months 7-8): Evaluation
- - Benchmarking
- - Comparison with baseline
- - Ablation study
-
-Phase 5 (Months 9-10): Paper writing
- - Draft paper
- - Revise based on feedback
- - Submit to RTSS/RTAS
-```
-
----
-
-*最后更新: 2026-09-17*
diff --git a/reference_file/FRAMEWORK.md b/reference_file/FRAMEWORK.md
deleted file mode 100644
index 704d70f..0000000
--- a/reference_file/FRAMEWORK.md
+++ /dev/null
@@ -1,210 +0,0 @@
-# RTOS 针对大模型运行的优化方向 — 整体研究框架
-
-## 0. 核心问题
-
-> **矛盾**：RTOS追求确定性的微秒~毫秒级延迟，而LLM推理是计算密集、耗时长（ms~s级）、内存大（GB级）的软实时负载。
->
-> **目标**：在资源受限的边缘/嵌入式场景中，设计RTOS调度器/运行时，管理LLM推理过程中的**多源异构资源**，确保推理过程的**确定性**、**低延迟**与**能效**。
-
-**这不是让RTOS"跑大模型"，而是用RTOS做"LLM推理资源的调度与协调"。**
-
----
-
-## 1. 问题空间：硬件平台全景
-
-### 1.1 四层硬件抽象
-
-```
-┌───────────────────────────────────────────────────────────┐
-│ Controller Layer (MCU/应用CPU) │
-│ STM32H7 / ESP32-S3 / Cortex-M7 / RPi CM4 │
-│ 目标：跑量化后的小模型（Qwen-1.5B INT4, Qwen2.5-0.5B） │
-│ RAM: 256KB~2MB, 主频: 400MHz~1GHz │
-├───────────────────────────────────────────────────────────┤
-│ SoC Layer (手机/车规SoC) │
-│ 骁龙8 Gen / 天玑9300 / NXP i.MX93 │
-│ 集成: CPU + NPU + GPU + ISP + DDR, 功耗: 3~15W │
-│ 目标：跑500M~3B参数模型, 实时语音/对话 │
-├───────────────────────────────────────────────────────────┤
-│ Edge AI Accelerator (边缘盒子) │
-│ NVIDIA Jetson Orin / RK3588 / 地平线J5 │
-│ 集成: CPU集群 + 专用NPU + 大DDR, 功耗: 15~60W │
-│ 目标：跑7B~14B参数模型, 多模态推理 │
-├───────────────────────────────────────────────────────────┤
-│ Server Layer (x86 / ARM Server) │
-│ x86: Intel/AMD, ARM: Ampere/Graviton │
-│ 集成: 多Core + 多NPU/GPU + 大内存 + PCIe互联 │
-│ 目标：跑14B~72B+参数模型, 云端推理 │
-└───────────────────────────────────────────────────────────┘
-```
-
-### 1.2 各平台的关键约束
-
-| 平台层级 | 内存带宽 | 加速设备 | RTOS适配难度 | 核心挑战 |
-|---------|---------|---------|-------------|---------|
-| MCU级 | 几十MB/s | 无/简单DSP | 低（RTOS成熟） | 内存太小，模型必须极小 |
-| SoC级 | 几百MB/s | NPU + GPU | 中 | NPU驱动不开放，NPU-ARM通信难 |
-| Edge盒子 | GB/s级 | 专用NPU | 中高 | 多NPU调度、PCIe延迟 |
-| Server级 | 数十GB/s | 多GPU/NPU | 高 | NUMA、互联拓扑、调度粒度 |
-
----
-
-## 2. 五层技术框架
-
-```
-┌───────────────────────────────────────────────────────────────┐
-│ L5: 模型层 — Inference Engine │
-│ Quantization | KV Cache Layout | Speculative Decode │
-│ 目标：减少计算量、降低内存带宽需求 │
-├───────────────────────────────────────────────────────────────┤
-│ L4: 运行时层 — Runtime & Scheduling │
-│ Task Graph | Pipeline Parallel | Memory Pool | Preemption │
-│ 目标：将LLM计算分解为RTOS可管理的task与事件 │
-├───────────────────────────────────────────────────────────────┤
-│ L3: 资源抽象层 — Hardware Abstraction │
-│ Accelerator Driver | DMA Engine | Memory Controller │
-│ 目标：统一不同硬件的接口，暴露资源状态给调度器 │
-├───────────────────────────────────────────────────────────────┤
-│ L2: 调度层 — RTOS Core │
-│ Priority Scheduling | EDF | Hybrid Scheduling | IRQ mgmt │
-│ 目标：在保证硬实时约束的同时高效执行LLM推理 │
-├───────────────────────────────────────────────────────────────┤
-│ L1: 硬件层 — SoC + Accelerator + Memory │
-│ ARM/RISC-V | LPDDR | PCIe | NPU/GPU │
-│ 目标：理解硬件物理特性（缓存、带宽、拓扑） │
-└───────────────────────────────────────────────────────────────┘
-```
-
-### 2.1 L5 → L4 的映射关系
-
-```
-LLM推理阶段 RTOS任务映射
-────────── ────────────
-Tokenization → Task A (低优先级, 可中断)
-Embedding → Task B (中优先级, 计算密集)
-Attention KV Cache → Task C (高优先级, 延迟敏感)
-FFN → Task D (中优先级, 可pipeline)
-Logits/Sample → Task E (中优先级, 可并行)
-Output decoding → Task A (循环)
-```
-
----
-
-## 3. 六个核心优化方向
-
-```
- 方向1: 推理图任务调度 ← 调度算法
- 方向2: KV Cache 与内存管理 ← 内存管理
- 方向3: 加速器协同调度 ← 资源协同
- 方向4: 量化与精度感知调度 ← 精度-调度联合优化
- 方向5: 中断与实时响应 ← 实时性保障
- 方向6: 能耗与热管理 ← 能效优化
-```
-
-每个方向的深入分析见对应子文档（01~06）。
-
----
-
-## 4. 关键性能指标
-
-### 4.1 延迟指标
-
-| 指标 | 定义 | 优化手段 |
-|-----|------|---------|
-| TTFT (Time to First Token) | 输入到第一个输出token的时间 | 预计算embedding、Attention优先级提升 |
-| TPOT (Time per Output Token) | 每个输出token的平均生成时间 | KV Cache池化、流水线并行 |
-| Tail Latency P99 | 99%请求的端到端延迟 | 减少context switch、避免priority inversion |
-| WCL (Worst-Case Latency) | 硬实时约束下的最大可接受延迟 | WCET分析、hybrid scheduling |
-
-### 4.2 资源指标
-
-| 指标 | 定义 | 优化手段 |
-|-----|------|---------|
-| Memory Bandwidth Utilization | DDR带宽利用率 | DMA offload、带宽感知调度 |
-| Cache Hit Rate | L1/L2 Cache命中率 | Task pinning、数据局部性优化 |
-| NPU/GPU Utilization | 加速器利用率 | 双缓冲、pipeline parallel |
-| Power per Inference | 每次推理的能耗 | DVFS、idle-aware scheduling |
-
-### 4.3 实时性指标
-
-| 指标 | 定义 | 优化手段 |
-|-----|------|---------|
-| Jitter | 延迟的方差 | 固定优先级、减少抢占 |
-| Preemption Overhead | 上下文切换开销 | 减少task数量、pin核心 |
-| Blocking Time | 低优先级被高优先级阻塞的时间 | Priority inheritance protocol |
-| Deadline Miss Ratio | 错过截止时间的比例 | EDF、adaptive priority boost |
-
----
-
-## 5. 研究方法论
-
-### 5.1 建模方法
-
-```
-LLM Inference Model:
- T_total = Σ(T_encode + T_decode_i) for i = 1..N_tokens
- T_encode = T_tokenizer + T_embedding + Σ(T_attention_l + T_ffn_l) for l = 1..N_layers
-
-RTOS Scheduling Model:
- π(task) = priority(task)
- τ(task) = WCET(task)
- D(task) = deadline(task)
- R(task) = response_time(task) = τ(task) + Σ(interference_from_higher_priority_tasks)
-```
-
-### 5.2 分析工具链
-
-- **WCET分析**：RTA (Response Time Analysis)、FDAS (Full Demand Analysis for Arbitrary Scheduling)
-- **模拟平台**：GEM5（全系统模拟）、NN-SIM（神经网络模拟）
-- **原型验证**：FreeRTOS/Zephyr + 自定义调度器 patch
-- **性能分析**：perf、ftrace、f2fs-trace、NPU profiler
-
-### 5.3 评估流程
-
-```
-1. 基准测量：不同平台上的LLM推理profile（延迟、带宽、能耗）
-2. 模型构建：将推理过程建模为RTOS任务图
-3. 算法设计：针对识别到的瓶颈设计调度/内存/协同策略
-4. 仿真验证：在模拟环境中验证理论分析
-5. 原型实现：在真实RTOS上实现关键模块
-6. 实测对比：优化前后指标对比
-```
-
----
-
-## 6. 与已有工作的关系
-
-| 已有工作 | 差异点 | 本研究的独特贡献 |
-|---------|-------|----------------|
-| vLLM / TGI (LLM Serving) | 服务器级，无实时性保证 | 边缘/嵌入式场景，硬实时约束 |
-| Micro-LLM (TinyLLM) | 模型压缩，不关注OS调度 | 从OS调度层优化推理延迟确定性 |
-| NPU SDK调度 | 封闭blackbox，不暴露接口 | 开放式RTOS集成，可分析可证明 |
-| CUDA Stream (GPU) | 无实时性分析，非抢占式 | RTOS可抢占、WCET可证明 |
-
----
-
-## 7. 文档结构索引
-
-| 文档 | 内容 |
-|-----|------|
-| [01-inference-scheduling.md](01-inference-scheduling.md) | 推理图任务分解与混合调度算法 |
-| [02-kv-cache-memory.md](02-kv-cache-memory.md) | KV Cache内存池与带宽竞争管理 |
-| [03-accelerator-collab.md](03-accelerator-collab.md) | CPU+NPU流水线协同与异步调度 |
-| [04-quantization-scheduling.md](04-quantization-scheduling.md) | 量化精度感知的调度策略 |
-| [05-irq-realtime.md](05-irq-realtime.md) | 中断管理与实时性保障 |
-| [06-power-thermal.md](06-power-thermal.md) | 能耗感知调度与热管理 |
-| [07-analysis-methods.md](07-analysis-methods.md) | 方法论与评估工具链 |
-
----
-
-## 8. 预期研究成果
-
-1. **理论**：LLM推理任务的实时性建模与调度分析理论
-2. **算法**：针对嵌入式场景的LLM推理调度算法（至少2种：hybrid-priority + EDF）
-3. **系统**：基于FreeRTOS/Zephyr的LLM推理调度原型系统
-4. **数据**：不同平台上的LLM推理profile数据集
-5. **论文**：针对RTSS、RTAS、ISLPED等实时系统的论文
-
----
-
-*最后更新: 2026-09-17*