reorganize repository into framework-based structure

项目框架1-基于RTOS的五类场景AI实时性研究/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  
+   <https://realtime-linux.dev-lfprojects5.linuxfoundation.org/>
+2. QNX, Software Foundation for Physical AI
+   <https://qnx.software/en/software/technologies/physical-ai>
+3. Wind River 官网与 Edge AI / mission-critical 相关公开表述  
+   <https://www.windriver.com/>
+4. Ullrich et al., *AI Safety Assurance for Automated Vehicles: A Survey on Research, Standardization, Regulation*  
+   <https://arxiv.org/abs/2504.18328v1>

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

@@ -0,0 +1,155 @@
+# 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` 服务器 / 集群
+
+其中，`T1` 在本项目中定义为**面向任务关键场景的分布式协同计算平台**，承载全局状态管控、多源信息融合推理和跨节点协同决策等任务；通用高吞吐训练集群或面向公网请求的通用推理机房不属于本项目场景范围。
+
+这套验证矩阵支撑以下四类判断：
+
+- RTOS 优势在哪些部署形态下最明显；
+- 这些优势来自哪些系统机制；
+- 为维持实时保障需要付出多少吞吐和能耗代价；
+- 从什么资源规模开始，RTOS 相对非实时平台的优势开始收窄。
+
+这套验证矩阵提供的是统一的建模、评估与证据组织方法，不要求同一套机制在 `T5~T1` 全部取得同等收益；项目重点是识别不同资源约束、拓扑结构和负载强度下，RTOS 优势边界与失效边界的成立区间。
+
+### 4. 建立“AI 目标负载 + 关键保障负载”双目标证据链
+
+项目以可复现、可解释的证据链为核心输出，目标是形成能被论文、产品和产业沟通共同接受的系统性结论。
+
+证据至少包括三层：
+
+- **人工智能目标负载层**：
+  `TTFT`、`TPOT`、端到端响应时间、成功率、任务质量、长时间稳定性；
+- **关键保障负载层**：
+  `deadline miss ratio`、`P99/P99.9 jitter`、观测最大响应时间、外部接口响应；
+- **系统协同层**：
+  有效吞吐、`E/token`、温度漂移、资源争抢边界、恢复能力与长期稳定性。
+
+## 项目边界
+
+### 1. 应用背景与研究对象
+
+项目的应用背景覆盖控制端、设备端、边缘节点、工作站和集群等多种部署形态，但研究对象始终保持一致：
+
+- 大型跨平台实时操作系统；
+- 任务关键系统；
+- 人工智能目标负载。
+
+其中，`T5/T4/T3` 属于典型嵌入式装备节点；`T2/T1` 属于通用处理器硬件平台上运行的任务关键业务环境。项目讨论的是实时操作系统在这些平台上的系统作用，硬件本身不被定义为嵌入式系统。
+
+### 2. 评价重点
+
+项目评价围绕“双目标达标 + 系统协同稳定”展开，重点包括：
+
+- AI 目标负载是否按时完成；
+- 关键保障负载是否满足截止期；
+- 系统是否在长时间运行中保持稳定；
+- 满足这些约束后，吞吐与能耗代价是否可接受。
+
+### 3. 算法与系统的关系
+
+量化、KV Cache、流水线、投机解码这些内容在本项目里主要服务于系统层研究：
+
+- 它们如何改变时延分布；
+- 如何影响内存占用和带宽争抢；
+- 如何改变调度器和资源管理策略。
+
+因此，项目重点落在系统机制、调度策略和资源治理能力上。
+
+对于搭载独立 GPU 或专用加速器的平台，RTOS 的主要管控范围是 CPU 侧任务调度、中断隔离、内存预算、关键保障负载时间保护和系统级恢复机制；GPU 内部算子调度、显存流水线与设备微架构行为由加速器硬件与驱动管理，不属于 RTOS 内核直接管控域。
+
+因此，`T2/T1` 层级的研究重点不是单纯优化 GPU 吞吐，而是评估在人工智能目标负载并发存在时，CPU 侧关键保障负载与系统协同机制是否仍能维持实时边界。
+
+### 4. 成果形态
+
+项目成果需要形成完整的方法与证据体系，包括：
+
+- 可解释的方法；
+- 可复现的证据；
+- 明确的适用边界；
+- 跨部署形态可比较的规律；
+- 能被学术界和产业界共同理解的结论。
+
+在证据形态上，项目区分**核心实测证据**与**扩展层级证据**：核心档位以实机对照与长稳数据为主，扩展档位可结合建模分析、仿真、条件验证和外部参照结果，形成边界推演与跨层级比较。
+
+## 这个项目最后要交付什么
+
+项目最终交付物至少应包括：
+
+1. 一套面向任务关键系统的 SylixOS 实时保障机制；
+2. 一组覆盖 `T5~T1` 五类部署形态的验证证据与对照结果，其中核心档位以实测为主，扩展档位以建模、仿真和条件验证为补充；
+3. 一套同时覆盖 AI 目标负载与关键保障负载的实验方法学；
+4. 一篇能够清楚表达机制、证据、边界和规律的系统化论文或正式报告；
+5. 一套可用于产业沟通和产品表达的技术叙事。
+
+## 判断项目是否成功，要看什么
+
+要看：
+
+- SylixOS 是否在公平对照下改善了关键保障负载的尾延迟与违约率；
+- SylixOS 是否同时保持了人工智能目标负载的时效性和功能有效性；
+- 吞吐损失是否在可接受范围；
+- 能耗和热稳定性是否同步改善或至少可解释；
+- 结论是否能跨部署形态成立；
+- 优势边界和失败边界是否都被讲清楚。
+
+## 最后一句话
+
+这个项目的本质是：
+
+> **用人工智能目标负载进入任务关键系统后的资源冲突与时序压力，去验证大型跨平台实时操作系统是否仍然能够维持系统应有的确定性、可预测性与实时保障边界。**