docs: organize edge SoC research materials

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

.gitignore

@@ -0,0 +1,10 @@
+# Local assistant and workspace metadata
+.claude/
+.workbuddy-ai/
+
+# Local Git access notes may contain credentials
+git_skills.md
+
+# Microsoft Office temporary lock files
+~$*.docx
+**/~$*.docx

01-会议讨论/20260922_093448-会议主题拆分整理/00-会议主题索引.md

@@ -0,0 +1,35 @@
+# 20260922\_093448 会议主题拆分索引
+
+本次会议可以整理为 5 个相互关联、但可独立推进的主题板块。它们共同围绕人工智能、基础系统、行业落地与合作路径展开，但每个板块的研究对象、交付目标和后续动作并不相同，因此适合拆分为独立文件持续讨论。
+
+## 1. 主题划分
+
+1. [01-医疗AI导航与嵌入式收缩方向.md](01-医疗AI导航与嵌入式收缩方向.md)
+   - 聚焦手术显微镜 AI 辅助导航、外挂式推理到嵌入式收缩的产品路径。
+2. [02-大模型评测优化平台与本地模型社区.md](02-大模型评测优化平台与本地模型社区.md)
+   - 聚焦服务器侧模型评测、算子优化、量化比较、本地模型社区，以及平台建设、服务外溢和各方分工方式。
+3. [03-RTOS与AI实时控制基础系统课题讨论.md](03-RTOS与AI实时控制基础系统课题讨论.md)
+   - 聚焦翼辉方向、基础系统定位、MCU 与 SoC/Hybrid 路线区分，以及课题推进步骤、责任边界和合作方式。
+4. [04-垂直大模型训练框架与代训服务.md](04-垂直大模型训练框架与代训服务.md)
+   - 聚焦“垂直大模型不等于通用模型加行业语料”的方法论、七要素框架、代训服务步骤和分工合作方式。
+5. [05-法律政务数据治理智能体与XAPP平台.md](05-法律政务数据治理智能体与XAPP平台.md)
+   - 聚焦纪委办案、律师产品、数据治理智能体、XAPP 平台化思路，以及应用到平台的推进路径与合作分工。
+
+## 2. 结构判断
+
+这 5 个主题之间的关系如下：
+
+- `01` 是一个具体行业落地样例，体现 AI 从外挂推理向嵌入式系统收缩的路径；
+- `02` 是模型优化和测试平台能力，已经扩展为平台建设、服务输出与社区沉淀的完整工作线；
+- `03` 是基础系统方向的课题定义与合作主线，直接对应研究框架、翼辉合作和后续预研组织方式；
+- `04` 是大模型产业化的方法论与服务模式，偏研究方法、训练逻辑与代训服务设计；
+- `05` 是平台和应用层的产品化实践，展示多模态数据治理、专业应用与 XAPP 平台的落地形态。
+
+## 3. 使用建议
+
+后续讨论可以按两条线推进：
+
+1. **研究主线**：优先阅读 `03` 和 `04`；
+2. **落地主线**：优先阅读 `01`、`02` 和 `05`。
+
+这样可以把“研究框架”“平台能力”“具体应用”三类问题拆开处理，不会在同一份会议全文里相互缠绕。

01-会议讨论/20260922_093448-会议主题拆分整理/01-医疗AI导航与嵌入式收缩方向.md

@@ -0,0 +1,45 @@
+# 医疗AI导航与嵌入式收缩方向
+
+## 1. 主题定位
+
+这一部分讨论的是一个明确的医疗器械落地样例：围绕手术显微镜场景，为厂商提供 AI 辅助导航能力，并逐步从外挂式主机方案收缩到嵌入式系统方案。
+
+## 2. 当前项目形态
+
+- 合作对象是国内手术显微镜厂商；
+- 当前方案是在原有显微镜主显示链路之外增加一块副屏；
+- 图像从显微镜链路引出，进入外挂主机完成推理，再把辅助分析结果叠加回显示画面；
+- 这一阶段的目标是先完成功能验证和临床辅助价值展示，不直接改动原主屏系统。
+
+## 3. 核心价值
+
+这个方向的价值集中在三点：
+
+1. **医疗场景价值明确**：医生可以在术野中直接看到风险点、角度偏差和操作提示；
+2. **商业价值直接**：整套 AI 辅助能力对设备加价能力明显高于其硬件增量成本；
+3. **研究价值清晰**：这是一个从服务器式推理向设备内收缩的真实案例，能自然过渡到嵌入式与实时系统问题。
+
+## 4. 后续技术演进
+
+会议里已经明确，当前外挂式主机只是第一阶段。后续方向是：
+
+- 把外挂主机能力收缩进设备本体；
+- 把 AI 功能从“旁路叠加”逐步转向“设备内部集成”；
+- 由此引出嵌入式系统、资源预算、边缘推理和控制路径协同等问题。
+
+这意味着它不是一个单纯的图像识别项目，而是一个可持续向基础系统问题延展的行业样例。
+
+## 5. 与整体研究的关系
+
+这个主题与整体研究最强的连接点在于：
+
+- 它属于 `T4/T3` 一类的设备端与边缘端样例；
+- 它天然涉及“小型化、低功耗、设备内集成”的后续路线；
+- 它可以作为“AI 目标负载进入任务关键设备”的现实入口。
+
+## 6. 后续可单独推进的问题
+
+1. 设备内收缩后的算力与功耗预算如何设定；
+2. 显微镜主链路、副链路和 AI 推理链路如何协同；
+3. 哪些部分继续由外挂主机承担，哪些部分迁移到嵌入式系统；
+4. 该场景能否作为 RTOS / 基础系统研究的主样例之一。

01-会议讨论/20260922_093448-会议主题拆分整理/02-大模型评测优化平台与本地模型社区.md

@@ -0,0 +1,260 @@
+# 大模型评测优化平台与本地模型社区
+
+## 1. 主题定位
+
+这一部分讨论的不是训练一个新的通用大模型，而是建设一套面向服务器、机房、算力中心和本地部署场景的大模型评测与优化平台。它的核心价值不在“再做一个模型”，而在于把模型、量化、算子、运行框架、启动参数和硬件配置之间原本分散、难解释的差异，组织成一套可比较、可复用、可交付的证据体系。
+
+会议进一步给这条线增加了一个更有延展性的方向：在平台能力稳定之后，可以向“本地模型社区”延伸，形成面向区域算力中心、科研团队、行业客户和本地部署需求的模型比较、配置推荐和优化服务能力。
+
+## 2. 会议形成的核心判断
+
+这部分讨论形成了五个稳定判断。
+
+### 2.1 同一套硬件上，运行配置差异足以造成显著性能分化
+
+模型效果和运行表现并不只取决于显卡型号或算力规模。  
+量化方式、算子开关、容器配置、运行框架、显存组织和启动参数都会显著影响：
+
+- 启动时间；
+- 解码速度；
+- 稳定性；
+- 显存占用；
+- 长稳运行效果。
+
+这意味着客户看到的“模型快不快”，很多时候并不是硬件单因素决定的。
+
+### 2.2 平台真正解决的是“不可解释”问题
+
+很多客户当前并不清楚瓶颈到底来自：
+
+- 硬件资源本身；
+- 框架选型；
+- 算子实现；
+- 量化策略；
+- 参数配置与部署方式。
+
+平台的价值，是把原本靠经验和试错得出的结果，变成能够重复执行、系统记录和横向比较的证据。
+
+### 2.3 评测平台天然可以外溢为优化服务
+
+一旦平台具备：
+
+- 统一记录；
+- 统一对比；
+- 统一报告；
+- 统一复现实验；
+
+它就不再只是内部工具，而可以外溢成：
+
+- 算力中心选型服务；
+- 模型优化服务；
+- 部署建议服务；
+- 本地模型配置推荐服务。
+
+### 2.4 本地模型社区的重点不是“做大平台”，而是做“高价值局部能力”
+
+会议对“社区化”方向的判断也比较清楚：
+
+- 不必复制一个通用开源社区；
+- 不追求以模型数量堆出影响力；
+- 更适合聚焦本地部署模型、端侧模型、专业模型和工具化模型；
+- 重点放在选型、评测、优化、配置推荐和经验沉淀上。
+
+### 2.5 这条线与实时基础系统研究并不冲突
+
+虽然这部分内容更多发生在服务器和机房侧，但它和整体研究并不割裂，因为它提供了：
+
+- AI 目标负载的运行时证据基础；
+- 推理实时性不完全由操作系统决定的实证背景；
+- 对端侧、小型化和边缘部署的模型选型依据。
+
+## 3. 这条线真正要做的事情
+
+如果把会议中的想法进一步收束，这条线真正要建设的是一套“四位一体”的能力：
+
+1. **评测平台**  
+   负责统一记录硬件、模型、参数、运行结果和日志证据。
+2. **优化工作台**  
+   负责对比量化、算子、框架和启动配置，给出可复现的优化建议。
+3. **报告系统**  
+   负责把结果输出成客户能理解、团队能复用的标准报告。
+4. **本地模型社区**  
+   负责沉淀模型经验、配置经验、最佳实践和可复用模板。
+
+因此，这条线的本质不是“做个演示平台”，而是形成一套从实验到服务再到社区沉淀的连续能力。
+
+## 4. 建议的工作方式
+
+这条线更适合采用“平台底座 + 优化服务 + 社区沉淀”的工作方式。
+
+### 4.1 先把平台做成证据系统
+
+第一步不是追求界面完整，而是确保每一次实验都能形成可重复、可追溯的证据，包括：
+
+- 硬件环境；
+- 模型版本；
+- 量化与算子配置；
+- 启动参数；
+- 运行日志；
+- 性能指标；
+- 异常记录。
+
+### 4.2 再把平台变成优化工具
+
+在证据系统稳定之后，平台需要进一步承担：
+
+- 多配置对比；
+- 自动化基线测试；
+- 优化项回归验证；
+- 最优组合推荐。
+
+### 4.3 最后向社区和服务产品外溢
+
+只有在前两步稳定之后，才适合把成果外溢为：
+
+- 内部优化知识库；
+- 本地模型推荐清单；
+- 算力中心服务能力；
+- 对外社区或合作平台。
+
+## 5. 建议的推进步骤
+
+### 5.1 第一步：建立最小可用评测底座
+
+目标是先把评测和记录做扎实。  
+这一阶段应完成：
+
+- 硬件信息采集；
+- 模型加载与启动配置记录；
+- 解码速度、显存占用、温度和稳定性采集；
+- 日志归档与结果可回看。
+
+### 5.2 第二步：建立标准化对比实验
+
+目标是让平台开始具备“比较能力”。  
+这一阶段应完成：
+
+- 同模型不同量化方案对比；
+- 同模型不同框架对比；
+- 同模型不同算子开关对比；
+- 同一硬件下不同启动参数对比；
+- 同一配置长稳运行验证。
+
+### 5.3 第三步：形成优化报告模板
+
+目标是把结果变成可以交付的东西。  
+这一阶段应完成：
+
+- 统一评测报告模板；
+- 统一优化建议模板；
+- 面向内部研发和面向客户的双版本输出；
+- 典型案例归档。
+
+### 5.4 第四步：形成服务与社区接口
+
+目标是把平台从内部工具推进到合作能力。  
+这一阶段应完成：
+
+- 模型推荐清单；
+- 本地部署配置推荐；
+- 算力中心选型建议；
+- 模型社区入口与资料组织方式。
+
+## 6. 各方责任与分工方式
+
+这条线适合按四类角色组织。
+
+### 6.1 唐老师团队
+
+适合承担：
+
+- 对外合作牵头；
+- 客户问题定义与场景归类；
+- 服务模式设计；
+- 报告交付结构与对外表达组织。
+
+唐老师团队更适合站在“需求整合、问题转译、合作推进”的位置上。
+
+### 6.2 罗老师团队
+
+适合承担：
+
+- 评测方法学抽象；
+- 指标体系设计；
+- 对比逻辑与结论边界把关；
+- 从个案经验中提炼共性规则。
+
+罗老师团队更适合站在“方法论、评价体系、结果解释”的位置上。
+
+### 6.3 平台与工程团队
+
+适合承担：
+
+- 平台实现；
+- 模型部署与运行；
+- 评测脚本和自动化任务；
+- 数据采集、日志治理与结果可视化；
+- 优化项验证与回归测试。
+
+这一角色是平台真正落地的执行核心。
+
+### 6.4 合作方或客户方
+
+适合承担：
+
+- 提供真实模型与场景目标；
+- 提供约束条件与验收口径；
+- 确认数据权限与部署边界；
+- 对优化结果给出业务反馈。
+
+客户方不负责平台方法学设计，但必须负责场景目标与验收边界。
+
+## 7. 工作边界
+
+为了避免这条线失焦，需要明确它不做什么。
+
+### 7.1 不以训练新通用模型为主目标
+
+这条线的重点是评测、优化和配置比较，不是另起炉灶训练新的通用基座模型。
+
+### 7.2 不把平台做成纯展示系统
+
+如果平台没有可重复实验、可复用模板和可解释报告，它就只是演示界面，而不是方法平台。
+
+### 7.3 不把社区做成“模型仓库堆砌”
+
+本地模型社区的重点不在收集尽可能多的模型，而在于形成有用的模型说明、部署建议和优化经验。
+
+### 7.4 不直接替代端侧和基础系统研究
+
+这条线为整体研究提供模型运行证据，但它本身不替代 RTOS、基础系统和嵌入式部署课题。
+
+## 8. 合作推进方式
+
+这条线适合采用“三阶段合作法”。
+
+### 8.1 阶段一：评测平台共建
+
+重点是把实验环境、评测流程和数据记录打通。  
+交付物以内部工具、基线实验和标准报告模板为主。
+
+### 8.2 阶段二：优化服务协同
+
+重点是围绕真实客户、真实模型和真实部署需求输出优化结果。  
+交付物以优化报告、配置建议和案例沉淀为主。
+
+### 8.3 阶段三：社区与区域合作扩展
+
+重点是把积累下来的经验沉淀成更稳定的合作能力。  
+交付物以模型推荐清单、社区入口、合作机制和服务手册为主。
+
+## 9. 当前结论
+
+这条线的真正价值，不是再做一个“模型体验平台”，而是：
+
+> **把模型、量化、算子、框架和硬件之间原本难解释的运行差异，变成一套可比较、可复现、可交付、可沉淀的证据与服务体系。**
+
+如果继续向前推进，它会自然生长出两个方向：
+
+- 一个是面向内部和合作项目的优化工作台；
+- 一个是面向区域部署、本地模型与算力中心合作的本地模型社区。

01-会议讨论/20260922_093448-会议主题拆分整理/03-RTOS与AI实时控制基础系统课题讨论.md

@@ -0,0 +1,401 @@
+# RTOS与AI实时控制基础系统课题讨论
+
+## 1. 主题定位
+
+这部分讨论是整场会议中最接近课题主线、研究对象重定义和合作方向重构的核心内容。会议虽然从翼辉与 RTOS 相关问题切入，但最终形成的判断已经明显超出了“RTOS 是否更强”这一层，转向了一个更高层次的问题：
+
+> **当人工智能能力进入实时控制系统之后，真正需要研究和构建的对象，不再只是单一 RTOS，而是面向 AI 的实时控制基础系统。**
+
+这不是一句包装性口号，而是对研究主语、技术路线、合作方式和产业定位的重新组织。
+
+## 2. 会议形成的核心结论
+
+会议中稳定下来的，不是某一个局部技术答案，而是四项根本判断。
+
+### 2.1 大模型实时性不是单一 RTOS 问题
+
+人工智能目标负载进入系统之后，系统面对的问题来自多层要素共同作用，包括：
+
+- 模型结构与量化方式；
+- 推理框架与运行时队列；
+- RTOS 与 Linux 的角色分工；
+- Hypervisor 与资源隔离结构；
+- 芯片、总线、内存、DMA、NPU、GPU 等硬件资源形态；
+- 规则兜底、异常切换和安全边界机制。
+
+因此，会议给出的更准确判断是：
+
+> **人工智能进入实时控制系统之后，系统需要解决的是跨模型、跨运行时、跨基础软件和跨体系结构的整体实时性问题。**
+
+### 2.2 研究主语要从 RTOS 上移到基础系统
+
+会议没有否定 RTOS 的价值，但明确反对继续把全部实时性问题都压到 RTOS 身上。  
+RTOS 仍然是关键保障负载的确定性底座，但不再适合作为所有问题的唯一承担者。
+
+更合适的研究对象应当写成：
+
+- 实时基础系统；
+- 面向 AI 的实时控制基础系统；
+- 面向 AI 的实时控制系统体系结构。
+
+### 2.3 技术路线天然分成 MCU 路线与 SoC / 边侧路线
+
+会议没有把所有场景压成同一套逻辑，而是明确区分了两类问题结构：
+
+- `MCU` 路线：更强调静态资源组织、开发工具链、芯片协同和开发套件；
+- `SoC / 边侧` 路线：更强调 Linux、RTOS、Hypervisor 与异构资源共同构成的混合基础系统。
+
+因此，更接近原意的概括不是“MCU 让 RTOS 多做点事、边侧上 Hypervisor”，而是：
+
+> **MCU 路线主要解决静态编排与工具链协同问题，SoC / 边侧路线主要解决 Hybrid、Hypervisor 与系统协同问题，而两条路线共同服务于“面向 AI 的实时控制基础系统”这一更高层次主语。**
+
+### 2.4 翼辉方向需要从 RTOS 产品叙事转向基础系统叙事
+
+会议对翼辉这类公司的建议也比较明确：
+
+- 不再只讲 RTOS 厂商身份；
+- 不再把“适配了什么系统”作为核心叙事；
+- 转向“面向 AI 的实时控制基础系统供应方”；
+- 用 5 到 10 年技术路线替代短周期适配叙事。
+
+## 3. 基础系统视角下的问题结构
+
+为了避免后续再把所有问题混在一起，会议内容更适合被整理成三个层次。
+
+### 3.1 RTOS 直接控制域
+
+这一层对应 RTOS 可以直接施加机制约束的范围，主要包括：
+
+- 周期任务与关键任务调度；
+- 中断优先级、抢占关系和关键路径治理；
+- CPU 侧线程、同步机制与时钟管理；
+- 恢复、隔离和关键任务保护机制；
+- 对部分共享资源策略的直接控制接口。
+
+这一层回答的是：
+
+> **RTOS 如何为关键保障负载建立确定性底座。**
+
+### 3.2 推理运行域
+
+这一层主要由模型、量化、算子、框架和运行时共同决定，主要包括：
+
+- 模型大小与数值精度；
+- Prefill / Decode 的时延分布；
+- KV Cache、工作区和内存组织方式；
+- 推理框架队列、批处理与上下文管理；
+- GPU/NPU 内部执行与驱动接口行为。
+
+这一层回答的是：
+
+> **人工智能目标负载本身具有什么样的时间行为、资源行为和可优化空间。**
+
+### 3.3 系统协同域
+
+这一层是会议真正抬起来的新重点，主要包括：
+
+- Linux 与 RTOS 的角色分工；
+- Hypervisor 的隔离与资源划分；
+- 总线、DMA、统一内存、外存和协处理器竞争治理；
+- 规则兜底、异常切换与安全边界；
+- 关键保障负载与人工智能目标负载之间的优先级结构。
+
+这一层回答的是：
+
+> **在混合系统中，整体实时性如何被建立、维持和验证。**
+
+## 4. MCU 路线与 SoC / 边侧路线的真实含义
+
+### 4.1 MCU 路线
+
+会议对 `MCU` 方向的判断非常集中。  
+更准确的理解不是“MCU 端让 RTOS 多做一些事”，而是：在极小资源预算场景中，问题本身就不适合按高动态运行时思维组织。
+
+这一方向通常具有以下特点：
+
+- 动态空间极小；
+- 内存和算力预算刚性；
+- 控制任务和外设链路优先级极高；
+- 更适合小模型、小算子和静态工作流；
+- 更依赖离线配置、静态分配和代码生成。
+
+因此，会议原意更接近：
+
+> **MCU 路线中 RTOS 的意义更接近静态组织底座、可分析执行环境和开发工具链的一部分，而不是承接高动态推理运行时的主体。**
+
+### 4.2 SoC / 边侧路线
+
+`SoC / 边侧` 路线的判断也需要严格校准。  
+它并不是一句“边侧用 Hypervisor”就能概括的。会议真正强调的是：设备端 SoC 会天然同时存在 Linux 生态需求和实时控制需求，因此更现实的路径，是构造一个能够治理混合结构的基础系统。
+
+这类场景通常同时具有以下特征：
+
+- 需要 Linux 承接 AI 生态和推理框架；
+- 需要 RTOS 承接关键控制与实时保障；
+- 需要在同一 `SoC`、同一块板卡上处理统一内存和异构设备竞争；
+- 还要同时面对设备级功耗、散热、体积和驱动限制。
+
+会议对 `Hypervisor` 的态度是明确肯定的，但没有把它讲成单独答案。  
+更准确的理解是：
+
+- `Hypervisor` 首先是一种隔离和资源切分方法；
+- 它可以帮助划分 Linux 与 RTOS 的边界；
+- 但它本身不能自动消除统一内存、总线、DMA、缓存和协处理器带来的全部竞争问题。
+
+因此，这一路线真正保留并强化的是：
+
+> **面向 AI 实时控制系统的升级版 Hybrid，也就是能够处理分工、隔离、资源仲裁、规则兜底和异常切换的混合基础系统结构。**
+
+## 5. 建议的工作方式
+
+这一主题不适合按“先写论文、再找技术点”的方式推进，而更适合按“先完成问题重定义，再完成路线定义，再组织预研验证”的方式推进。
+
+### 5.1 先做课题重定义
+
+第一步不是急于给出实现方案，而是把以下问题写清楚：
+
+- 研究主语为什么要从 RTOS 上移到基础系统；
+- MCU 路线和 SoC / 边侧路线为什么不能混写；
+- RTOS 直接控制域、推理运行域、系统协同域如何分层；
+- Hybrid、Hypervisor、规则兜底在系统中的位置是什么。
+
+这一阶段的产物应当是：
+
+- 一份课题重定义稿；
+- 一份路线分层说明稿；
+- 一份面向合作方的概念阐释稿。
+
+### 5.2 再做技术路线分解
+
+在问题定义清楚之后，再把路线拆成两个主方向：
+
+1. `MCU` 路线  
+   重点看静态编排、工具链、开发套件、芯片协同。
+2. `SoC / 边侧` 路线  
+   重点看 Linux / RTOS / Hypervisor 分工、Hybrid 升级、统一内存与总线竞争治理。
+
+这一阶段的产物应当是：
+
+- 一份 MCU 路线稿；
+- 一份 SoC / Hybrid 路线稿；
+- 一份系统协同与规则兜底说明稿。
+
+### 5.3 再组织预研验证
+
+路线分解完成后，再进入原型和预研阶段。  
+这一阶段不是全面铺开，而应选典型切口验证关键判断，例如：
+
+- 小模型与控制任务的静态编排；
+- Linux 与 RTOS 分工下的控制链路保护；
+- Hypervisor 隔离下的统一内存竞争；
+- 模型输出与规则兜底共同构成的闭环。
+
+### 5.4 最后再回收进主课题框架
+
+只有在以上三步形成稳定判断之后，才适合把内容系统回收到主课题框架、论文规划和合作提案中。
+
+## 6. 建议的推进步骤
+
+### 6.1 第一步：形成概念共识
+
+目标是对内把“RTOS 课题”与“基础系统课题”的边界说清楚。  
+这一阶段应完成：
+
+- 会议判断整理；
+- 原话核对；
+- 关键词统一；
+- 课题候选命名收敛。
+
+### 6.2 第二步：形成路线稿
+
+目标是把两个方向彻底拆开。  
+这一阶段应完成：
+
+- MCU 路线稿；
+- SoC / 边侧路线稿；
+- Hybrid / Hypervisor 路线稿；
+- 系统协同域说明稿。
+
+### 6.3 第三步：形成合作版材料
+
+目标是让外部合作方能够看懂“为什么值得做、准备怎么做、各方做什么”。  
+这一阶段应完成：
+
+- 面向合作方的路线总述；
+- 阶段性合作方式说明；
+- 预研问题清单；
+- 交付物框架。
+
+### 6.4 第四步：组织预研与验证
+
+目标是围绕少数关键问题开展验证。  
+这一阶段应完成：
+
+- 板级或 SoC 原型验证；
+- 小模型与控制任务共存实验；
+- 混合系统资源竞争实验；
+- 规则兜底与异常切换实验。
+
+## 7. 各方责任与工作的边界
+
+这一主题如果要继续推进，必须把责任和边界说清楚，否则很容易重新落回“谁都在提想法，没人真正推进”的状态。
+
+### 7.1 唐老师团队
+
+适合承担：
+
+- 对外合作牵头；
+- 场景与需求整合；
+- 课题框架转译；
+- 合作节奏把控；
+- 外部沟通和阶段汇报组织。
+
+唐老师团队更适合处在“前端牵头、方案整合、合作推进”的位置。
+
+### 7.2 罗老师团队
+
+适合承担：
+
+- 研究主语与问题定义把关；
+- 方法论抽象；
+- 路线分层与概念边界校准；
+- 研究价值、学术表达和系统建模方向的判断。
+
+罗老师团队更适合处在“高层框架、方法论和方向判断”的位置。
+
+### 7.3 翼辉或对应产业团队
+
+适合承担：
+
+- RTOS、工具链、板级环境和基础软件条件说明；
+- MCU 路线和 SoC 路线的工程条件提供；
+- Hybrid / Hypervisor / 板级验证路径提供；
+- 原型实现与工程可行性反馈。
+
+产业团队不负责课题理论抽象，但负责把路线落到真实平台条件上。
+
+### 7.4 项目组或工程支撑团队
+
+适合承担：
+
+- 会议整理与材料撰写；
+- 路线稿、合作稿和阶段文档整理；
+- 预研验证组织；
+- 图表、报告和证据归档。
+
+这一角色更偏执行支撑与资料组织。
+
+## 8. 工作边界
+
+### 8.1 这项工作当前首先是“定义工作”，不是全面工程实现
+
+会议形成的第一价值，是重新定义问题和路线。因此现阶段不宜直接把重点放在“大规模开发”上。
+
+### 8.2 当前重点是“搭框架”，不是“宣称已经解决”
+
+无论是 MCU 路线还是 SoC / Hybrid 路线，当前更适合先形成稳定的问题定义、路线定义和验证问题，而不是过早给出“完整解决方案”叙事。
+
+### 8.3 学术问题与产业问题需要并行，但不能混写
+
+学术上要回答：
+
+- 问题定义是否成立；
+- 三层边界如何组织；
+- 经典实时理论如何扩展。
+
+产业上要回答：
+
+- 产品路线怎么讲；
+- 哪些工程条件已经具备；
+- 预研从哪里切入。
+
+这两类问题必须关联，但不能混成一篇只讲口号的材料。
+
+## 9. 合作推进方式
+
+这一主题适合采用“规划先行、预研跟进、原型验证收口”的推进方式。
+
+### 9.1 第一阶段：规划与定义
+
+重点是：
+
+- 统一研究主语；
+- 统一路线分层；
+- 统一合作表达；
+- 形成首轮课题和合作框架稿。
+
+这一阶段的交付物应以定义稿、路线稿和合作稿为主。
+
+### 9.2 第二阶段：预研与技术论证
+
+重点是：
+
+- 抽取少数关键问题做原型验证；
+- 形成系统协同和控制闭环的实证材料；
+- 把 MCU 路线与 SoC 路线分别落到真实平台。
+
+这一阶段的交付物应以预研报告、实验记录和系统草案为主。
+
+### 9.3 第三阶段：联合课题与对外输出
+
+重点是：
+
+- 回收进正式课题框架；
+- 形成面向项目、论文和合作申请的材料；
+- 根据需要向白皮书、论文和对外交流稿扩展。
+
+## 10. 对当前研究仓库的直接影响
+
+这场会议对当前仓库至少带来六项直接影响。
+
+### 10.1 研究主语需要继续上移
+
+当前仓库已经从“硬件主语”转到“RTOS 主语”，而会议进一步提示：下一步更值得推进的是从“RTOS 主语”继续上移到“基础系统主语”。
+
+### 10.2 `T5~T1` 验证矩阵仍然有效
+
+会议没有否定验证矩阵，而是强化了一个更清晰的判断：
+
+- `T5/T4/T3` 更适合作为系统研究主窗口；
+- `T2/T1` 作为 RTOS 优势主战场的意义较弱；
+- 但作为 AI 负载和系统协同的参照窗口仍然有价值。
+
+### 10.3 需要把“系统协同域”单独写出来
+
+当前仓库的五层技术栈已经是很好的起点，但后续需要明确写出：
+
+- RTOS 可控域；
+- 模型与运行时域；
+- Linux、Hypervisor、芯片与资源治理共同构成的系统协同域。
+
+### 10.4 “实时性”需要从纯 OS 叙事中适度抽离
+
+后续文档更适合写成：
+
+- 实时控制系统中的 AI 能力；
+- 引入 AI 后的整体实时性问题；
+- 基础系统如何维持控制路径与 AI 路径的统一时间边界。
+
+### 10.5 低功耗、小型化方向会自然进入主线
+
+一旦研究对象上移到基础系统，低功耗、小型化、片上资源预算这些问题就不再只是应用专题，而会自然进入主线。
+
+### 10.6 后续课题命名需要重新评估
+
+如果沿着这次会议的判断继续推进，候选命名更适合向以下方向收敛：
+
+- 面向 AI 的实时控制基础系统；
+- 人工智能目标负载进入实时控制系统后的基础系统保障机制；
+- 面向 AI 实时控制系统的嵌入式体系结构与基础系统研究。
+
+## 11. 当前结论
+
+这场会议最重要的价值，不是提供了一个立即可落地的单点技术答案，而是把观察视角整体抬高了一层。
+
+会议最终给出的判断可以概括为：
+
+> **人工智能进入实时控制系统之后，真正值得研究和构建的对象，不再只是单一 RTOS，而是一个围绕实时性、控制性、推理性和体系结构协同展开的基础系统。**
+
+如果进一步压缩成最贴近会议原意的一句话，可以写成：
+
+> **MCU 路线主要走静态编排、工具链与芯片协同，SoC / 边侧路线主要走 Linux + RTOS + Hypervisor + 升级版 Hybrid 的系统协同，而两条路线共同服务于“面向 AI 的实时控制基础系统”这一更高层次主语。**

01-会议讨论/20260922_093448-会议主题拆分整理/04-垂直大模型训练框架与代训服务.md

@@ -0,0 +1,321 @@
+# 垂直大模型训练框架与代训服务
+
+## 1. 主题定位
+
+这一部分讨论的不是“再训练一个行业版通用模型”这么简单，而是一套更完整的方法论：如何理解垂直大模型训练，为什么“通用模型 + 行业语料”不足以形成真正的垂直能力，以及为什么围绕这一方法论形成的代训服务在产业上是成立的。
+
+这条线本质上站在 AI 上层任务语义、业务结构和训练目标设计这一侧，和基础系统、边缘部署、智能体应用构成上下游关系。它回答的是：
+
+> **行业模型为什么不是简单加语料，而是一整套角色、目标、制度、流程和边界的结构化重建。**
+
+## 2. 会议形成的核心判断
+
+这部分讨论形成了五个稳定判断。
+
+### 2.1 垂直大模型不等于“通用模型 + 行业语料”
+
+会议明确反对把垂直模型简化为：
+
+`垂直大模型 = 通用大模型 + 行业语料`
+
+原因在于，业务差异并不只是语言风格差异，而是更深层的结构差异，包括：
+
+- 角色不同；
+- 目标函数不同；
+- 制度约束不同；
+- 动作空间不同；
+- 工作流不同；
+- 升级与分流机制不同；
+- 业务边界与处理边界不同。
+
+### 2.2 真正决定垂直模型表现的是结构，而不是数据量本身
+
+如果训练目标没有定义清楚，即便不断增加行业语料，也往往只能得到“更像行业说话方式”的模型，而得不到真正能在行业流程里工作的模型。
+
+因此，关键不只是准备更多数据，而是把业务结构编码进训练与后训练过程。
+
+### 2.3 “七要素框架”是会议中最有价值的方法学沉淀
+
+会议中已经形成了一个比较稳定的“七要素”思路：
+
+1. 主体角色；
+2. 目标函数；
+3. 领域知识；
+4. 制度约束；
+5. 动作空间；
+6. 工作流；
+7. 业务边界与处理边界。
+
+这个框架的价值在于，它把“垂直化”从模糊概念变成了可拆解、可设计、可复核的方法问题。
+
+### 2.4 代训服务之所以成立，是因为客户往往缺的不是算力，而是结构化建模能力
+
+很多企业并不具备以下能力：
+
+- 定义训练目标；
+- 识别主体角色；
+- 拆分制度约束；
+- 组织工作流；
+- 设计动作空间；
+- 区分模型边界与人工边界。
+
+因此，代训服务的真实价值不只是“帮客户训练模型”，而是帮助客户完成一轮业务结构显化与训练目标重构。
+
+### 2.5 这条线本身可以沉淀为独立的方法与服务体系
+
+如果把这一套能力做扎实，它不只是某次项目中的附属服务，而可以形成：
+
+- 方法论材料；
+- 咨询服务；
+- 联合研发流程；
+- 训练与后训练工具链；
+- 行业模型开发手册。
+
+## 3. 这条线真正要做的事情
+
+从会议内容看，这条线真正要建设的，不是单一训练流程，而是一套“三层能力”。
+
+### 3.1 业务结构抽象能力
+
+先把客户的业务系统抽象成：
+
+- 谁在工作；
+- 为了什么工作；
+- 在什么制度约束下工作；
+- 有哪些动作空间；
+- 哪些流程是固定的；
+- 哪些决策需要模型参与；
+- 哪些边界必须保留给人。
+
+### 3.2 训练与后训练设计能力
+
+在业务结构清楚之后，再组织：
+
+- 数据准备；
+- 监督微调；
+- 偏好对齐；
+- 工作流约束注入；
+- 工具调用结构；
+- 边界与拒答策略。
+
+### 3.3 交付与服务能力
+
+最终落到客户侧，需要输出的不只是模型本身，还包括：
+
+- 业务结构说明；
+- 训练目标说明；
+- 数据与流程边界说明；
+- 部署建议；
+- 持续优化计划。
+
+## 4. 建议的工作方式
+
+这条线更适合采用“先结构化建模，再训练设计，再联合迭代”的工作方式。
+
+### 4.1 先做业务结构访谈，不急于进训练
+
+第一步不是立刻收数据、开始训，而是先做业务和任务建模。  
+需要先回答：
+
+- 这个行业里谁是主角色；
+- 模型服务的主任务是什么；
+- 业务里的目标函数是什么；
+- 制度和规则约束是什么；
+- 哪些地方允许模型生成，哪些地方必须人工把关。
+
+### 4.2 再做训练框架设计
+
+当业务结构明晰后，再确定：
+
+- 数据如何组织；
+- 训练样本如何标注；
+- 哪些能力靠训练获得；
+- 哪些能力靠后训练或工作流获得；
+- 哪些边界不应交给模型。
+
+### 4.3 最后用联合迭代替代“一次性交付”
+
+会议隐含的判断是，垂直模型不会一次训练就稳定成型，更适合：
+
+- 小步迭代；
+- 领域专家反馈；
+- 规则修正；
+- 数据回流；
+- 后训练与工作流联调。
+
+## 5. 建议的推进步骤
+
+### 5.1 第一步：完成业务结构建模
+
+这一阶段应完成：
+
+- 角色梳理；
+- 目标函数梳理；
+- 制度与规则梳理；
+- 工作流和动作空间梳理；
+- 业务边界和模型边界划分。
+
+这一阶段的产物应当是：
+
+- 结构化访谈纪要；
+- 业务框架图；
+- 七要素分析表。
+
+### 5.2 第二步：形成训练与后训练设计稿
+
+这一阶段应完成：
+
+- 数据来源清单；
+- 训练样本设计；
+- 后训练目标设计；
+- 工作流与工具调用关系设计；
+- 安全边界与人工介入点设计。
+
+这一阶段的产物应当是：
+
+- 训练设计稿；
+- 后训练流程稿；
+- 数据治理与边界说明。
+
+### 5.3 第三步：组织小规模联合试训
+
+这一阶段不追求一步到位，而应聚焦少量高价值任务。  
+应完成：
+
+- 小样本试训；
+- 关键任务验证；
+- 失败案例分析；
+- 人工反馈回流；
+- 规则与工作流调整。
+
+### 5.4 第四步：形成代训服务包
+
+当试训稳定之后，再将其沉淀为更稳定的服务形态，包括：
+
+- 咨询服务包；
+- 数据与训练准备包；
+- 联合试训包；
+- 交付和持续优化包。
+
+## 6. 各方责任与分工方式
+
+这条线最怕“只有技术团队在训，没人定义业务”，因此责任划分必须非常清楚。
+
+### 6.1 唐老师团队
+
+适合承担：
+
+- 对外需求沟通；
+- 业务问题转译；
+- 行业合作推进；
+- 服务包设计；
+- 对外汇报和合作节奏组织。
+
+唐老师团队更适合站在“业务和合作牵引”的位置。
+
+### 6.2 罗老师团队
+
+适合承担：
+
+- 七要素方法论抽象；
+- 垂直模型问题定义；
+- 训练目标与边界设计把关；
+- 从个案中提炼共性框架。
+
+罗老师团队更适合站在“方法论和结构建模”的位置。
+
+### 6.3 训练与工程团队
+
+适合承担：
+
+- 数据处理；
+- 训练与后训练实现；
+- 评测与失败样例分析；
+- 工具调用和工作流联调；
+- 交付部署支持。
+
+这一角色负责把方法落到真实模型流程上。
+
+### 6.4 行业客户或业务合作方
+
+适合承担：
+
+- 提供真实业务流程和语料；
+- 明确角色、规则和边界；
+- 参与效果验收；
+- 对失败样例和业务偏差给出反馈。
+
+客户方不负责训练方法设计，但必须负责业务真实性和边界清晰度。
+
+## 7. 工作边界
+
+### 7.1 这条线不等于“做行业语料堆叠”
+
+如果只是追加语料而不重构角色、目标和工作流，就不构成真正的垂直模型训练框架。
+
+### 7.2 这条线不等于“代替客户完成全部业务数字化”
+
+代训服务可以帮助客户显化结构，但不应承担全部业务改造工作。
+
+### 7.3 训练、后训练、智能体工作流必须区分
+
+后续材料中要明确区分：
+
+- 哪些能力靠训练获得；
+- 哪些能力靠后训练获得；
+- 哪些能力靠工作流、工具和规则系统获得。
+
+### 7.4 这条线不直接替代基础系统研究
+
+它补充的是 AI 任务语义、行业目标和训练结构层，但不替代 RTOS、基础系统和部署层研究。
+
+## 8. 合作推进方式
+
+这条线适合采用“咨询先行、试训跟进、服务沉淀”的推进方式。
+
+### 8.1 第一阶段：方法咨询与结构建模
+
+重点是：
+
+- 业务访谈；
+- 七要素建模；
+- 训练边界和工作流边界定义；
+- 确定适不适合做垂直模型。
+
+### 8.2 第二阶段：联合试训与验证
+
+重点是：
+
+- 选择少量高价值任务；
+- 做小规模试训；
+- 验证训练、后训练和工作流哪个更有效；
+- 形成失败案例和调整机制。
+
+### 8.3 第三阶段：形成代训服务与长期合作
+
+重点是：
+
+- 输出服务包；
+- 形成长期优化机制；
+- 必要时推进工具链和标准化材料。
+
+## 9. 与整体研究主线的关系
+
+这一主题虽然看上去更偏大模型产业化，但它和整体研究并不冲突，反而补足了上层语义与任务定义层。
+
+它的价值主要体现在：
+
+- 补充 AI 目标负载的任务语义与业务边界；
+- 说明系统表现并不只由 OS 决定，训练目标和模型结构同样重要；
+- 可以与行业样例、边缘部署、小型化系统和智能体应用形成上下游关系。
+
+## 10. 当前结论
+
+这条线真正值得保留的，不是“代训”这个商业词本身，而是它背后的方法学判断：
+
+> **垂直大模型的核心不是在通用模型上附加行业语料，而是把角色、目标、制度、动作空间、工作流和边界结构编码进训练与后训练过程。**
+
+如果继续向前推进，它最可能沉淀成两类成果：
+
+- 一类是垂直模型方法论和训练框架；
+- 一类是围绕这一方法论建立起来的咨询、试训和代训服务体系。

01-会议讨论/20260922_093448-会议主题拆分整理/05-法律政务数据治理智能体与XAPP平台.md

@@ -0,0 +1,330 @@
+# 法律政务数据治理智能体与XAPP平台
+
+## 1. 主题定位
+
+这一部分主要来自会议后半段的延伸讨论，内容已经明显脱离 RTOS 研究本身，转向法律、纪委办案、数据治理智能体和平台化产品形态。它是一条非常独立的产品与应用主题，但又和前面几个主题形成上下游关系：上接大模型方法与训练问题，下接具体行业系统和交付方式。
+
+这条线真正关心的，不是“做一个能聊天的法律助手”，而是：
+
+> **如何把复杂的数据治理、关系发现、证据组织和报告生成过程，封装成面向专业人员可直接使用的业务系统。**
+
+## 2. 会议形成的核心判断
+
+这部分讨论形成了五个稳定判断。
+
+### 2.1 政务与法律场景的核心问题不是对话，而是复杂数据治理
+
+会议中提到的多个场景，本质上都在解决同一类问题：
+
+- 多来源、多格式、多模态资料导入困难；
+- 原始数据需要清洗、映射、关联、解释和展示；
+- 用户不愿意直接操作复杂数据分析工具；
+- 用户真正需要的是问题理解、关系发现、证据组织和报告生成。
+
+因此，这一主题的主线不是“做一个聊天机器人”，而是“把复杂数据治理过程封装成可操作的业务系统”。
+
+### 2.2 专业应用不能被压扁成单一聊天窗口
+
+会议对纯对话式工作台给出了明确修正：
+
+- 重交互业务不能只靠聊天界面承载；
+- 上传物、工作流、结果区、图谱区和报告区都需要独立存在；
+- 专业应用必须保留自己的界面和流程结构。
+
+这意味着平台设计必须尊重业务 UI，而不是试图把一切都压成一个对话框。
+
+### 2.3 法律和政务场景更适合“专业应用 + 平台壳”的结构
+
+会议里出现的多个场景都说明：
+
+- 纪委办案系统需要强数据治理能力；
+- 律师产品需要强访谈、证据和报告能力；
+- 脱敏工具需要独立的安全工具形态；
+- 不同应用之间可以共享工作台和通用能力，但不应失去各自的业务结构。
+
+这就是 `XAPP` 思路出现的原因。
+
+### 2.4 平台价值和应用价值必须分开定义
+
+平台的价值在于：
+
+- 提供统一工作台；
+- 提供账号、路由、权限、文件管理、日志和通用模型能力；
+- 提供应用接入框架。
+
+应用的价值在于：
+
+- 行业模型；
+- 规则系统；
+- 数据治理逻辑；
+- 具体业务流程与交付物。
+
+如果平台和应用不分，结果往往是平台过空，应用过散。
+
+### 2.5 本地部署和数据安全是这条线的刚性约束
+
+无论是纪委办案还是法律业务，会议都明确指出：
+
+- 数据安全要求高；
+- 现场部署需求强；
+- 响应稳定性要求高；
+- 数据不能随意外流。
+
+因此，这条线天然更适合本地部署或专有环境部署。
+
+## 3. 会议中浮现出的几类产品
+
+### 3.1 纪委办案数据治理智能体
+
+这一方向主要面向：
+
+- 银行流水；
+- 通话记录；
+- 出行数据；
+- 房产信息；
+- 保险与其他多源资料。
+
+它的核心不是“自动办案”，而是：
+
+- 导入；
+- 清洗；
+- 模板映射；
+- 关系发现；
+- 分析辅助；
+- 报告与材料组织。
+
+### 3.2 律师场景产品
+
+会议中提到的律师方向主要包括：
+
+- 婚家咨询访谈整理；
+- 证据组织与关系发现；
+- 资金分析；
+- 脱敏工具。
+
+这一方向说明，法律行业更适合“专业工具 + 专业流程”，而不是通用助手叙事。
+
+### 3.3 XAPP 平台
+
+会议中提出的 `XAPP` 平台思路非常关键。  
+它的含义不是再造一个“总助手”，而是：
+
+- 共享统一工作台；
+- 每个应用保留独立 UI；
+- 应用之间共享登录、权限、文件、模型和路由；
+- 复杂业务仍然通过界面、表格、流程和产物区组织。
+
+这实际上是对“纯聊天平台”路线的一次重要修正。
+
+## 4. 这条线真正要做的事情
+
+如果把会议内容收束，这条线真正要建设的是“三层产品能力”。
+
+### 4.1 数据治理底层能力
+
+包括：
+
+- 多源数据导入；
+- 模板识别与字段映射；
+- 清洗与标准化；
+- 关系抽取与图谱组织；
+- 检索与追踪。
+
+### 4.2 行业应用能力
+
+包括：
+
+- 办案智能体；
+- 律师访谈和报告产品；
+- 脱敏工具；
+- 关系分析和证据整理工具。
+
+### 4.3 XAPP 平台能力
+
+包括：
+
+- 统一工作台；
+- 应用路由；
+- 权限与账号系统；
+- 文件与任务管理；
+- 共用模型和公共能力接入。
+
+## 5. 建议的工作方式
+
+这条线更适合采用“先单应用打透，再平台化抽象”的工作方式，而不是一开始就先做大平台。
+
+### 5.1 先用具体高价值场景验证价值
+
+应优先选择最痛、最清楚、最容易形成产物的场景，例如：
+
+- 纪委办案数据治理；
+- 婚家咨询整理与报告；
+- 脱敏处理工具。
+
+先让单点应用把价值打透。
+
+### 5.2 再抽象可复用的中间层
+
+当单点应用稳定之后，再把其中共性能力抽出来，例如：
+
+- 数据导入；
+- 模板映射；
+- 关系图谱；
+- 报告生成；
+- 权限与日志管理。
+
+### 5.3 最后再形成 XAPP 平台壳
+
+只有在多个应用共享同一组共性能力之后，再做平台化抽象，才不会做成空平台。
+
+## 6. 建议的推进步骤
+
+### 6.1 第一步：选择 1 到 2 个高价值场景做应用原型
+
+这一阶段应完成：
+
+- 选定业务场景；
+- 梳理数据来源；
+- 梳理用户任务；
+- 梳理需要生成的产物；
+- 明确本地部署和安全要求。
+
+### 6.2 第二步：打通数据治理链路
+
+这一阶段应完成：
+
+- 数据导入；
+- 模板映射；
+- 清洗与标准化；
+- 关系发现；
+- 初步报告生成。
+
+### 6.3 第三步：形成应用级交付
+
+这一阶段应完成：
+
+- 独立 UI；
+- 工作流组织；
+- 上传区、处理中间区、结果区和报告区；
+- 用户可操作的专业化界面。
+
+### 6.4 第四步：抽取平台共性能力
+
+当两个以上应用出现后，再抽取：
+
+- 登录权限；
+- 文件和任务管理；
+- 通用模型调用；
+- 公共组件；
+- 应用接入标准。
+
+## 7. 各方责任与分工方式
+
+这条线如果要落地，必须明确“谁负责场景、谁负责系统、谁负责方法、谁负责交付”。
+
+### 7.1 唐老师团队
+
+适合承担：
+
+- 行业需求获取与场景梳理；
+- 客户沟通；
+- 交付方案组织；
+- 产品方向和合作节奏把控；
+- 对外汇报与合作推进。
+
+### 7.2 罗老师团队
+
+适合承担：
+
+- 方法论抽象；
+- 数据治理逻辑与共性框架判断；
+- 平台层与应用层边界把关；
+- 从个案产品中提炼通用结构。
+
+### 7.3 产品与工程团队
+
+适合承担：
+
+- 数据治理链路实现；
+- 应用 UI 与工作流实现；
+- 报告和图谱模块；
+- 平台共性能力抽取；
+- 本地部署与安全实现。
+
+### 7.4 行业合作方或客户方
+
+适合承担：
+
+- 提供真实业务数据与使用流程；
+- 明确合规和安全要求；
+- 参与验收；
+- 对应用效果与流程合理性给出反馈。
+
+## 8. 工作边界
+
+### 8.1 这条线不等于“做个法律聊天机器人”
+
+如果把重点放在聊天入口，而不解决数据治理、图谱、报告和流程问题，这条线就会失焦。
+
+### 8.2 平台不应先于应用存在
+
+没有稳定的应用需求支撑，先做平台很容易变成空壳工程。
+
+### 8.3 专业应用必须保留独立 UI 和工作流
+
+不应把纪委、律师、脱敏工具都压成同一种对话式界面。
+
+### 8.4 这条线不直接纳入 RTOS 主课题
+
+它是独立的应用和产品方向材料，适合作为并行线保留，而不是强行并入基础系统主研究。
+
+## 9. 合作推进方式
+
+这条线适合采用“单应用切入、共性能力抽取、平台化收口”的推进方式。
+
+### 9.1 第一阶段：应用验证
+
+重点是：
+
+- 选具体场景；
+- 做原型；
+- 证明价值；
+- 形成第一批产物。
+
+### 9.2 第二阶段：应用扩展与复用
+
+重点是：
+
+- 增加第二类应用；
+- 比较共性与差异；
+- 抽取中间层能力；
+- 形成通用模块。
+
+### 9.3 第三阶段：平台化与持续合作
+
+重点是：
+
+- 建立 XAPP 平台结构；
+- 定义应用接入标准；
+- 形成长期合作和产品化路线。
+
+## 10. 与整体研究材料的关系
+
+这一主题虽然不直接属于 RTOS 主线，但对整体项目仍然有两类价值：
+
+- 它说明 AI 应用进入真实行业以后，对数据治理、平台结构、UI 组织和本地部署的要求会非常具体；
+- 它可以作为后续讨论“平台层”“XAPP 层”“工作流层”和“专业应用层”的现实参照。
+
+因此，它不应被强行塞进 RTOS 课题，但值得作为独立并行材料长期保留。
+
+## 11. 当前结论
+
+这条线真正值得保留的，不是若干零散行业点子，而是一条更稳定的产品判断：
+
+> **法律政务类智能体的核心，不是对话入口，而是把复杂数据治理、关系分析、业务流程和报告产出封装成专业应用，并在多个应用之上抽象出 XAPP 平台能力。**
+
+如果继续往前推进，这条线最自然的演化方式是：
+
+- 先做高价值行业应用；
+- 再抽取共性数据治理能力；
+- 最后收口到平台和应用协同的产品结构。

02-项目框架/01-项目框架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>

02-项目框架/01-项目框架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 是否同时保持了人工智能目标负载的时效性和功能有效性；
+- 吞吐损失是否在可接受范围；
+- 能耗和热稳定性是否同步改善或至少可解释；
+- 结论是否能跨部署形态成立；
+- 优势边界和失败边界是否都被讲清楚。
+
+## 最后一句话
+
+这个项目的本质是：
+
+> **用人工智能目标负载进入任务关键系统后的资源冲突与时序压力，去验证大型跨平台实时操作系统是否仍然能够维持系统应有的确定性、可预测性与实时保障边界。**

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

@@ -0,0 +1,283 @@
+# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的整体研究框架
+
+## 0. 核心问题
+
+本项目围绕大型跨平台实时操作系统支撑任务关键系统中的人工智能目标负载展开，核心判断是：
+
+> **当人工智能目标负载进入任务关键系统后，大型跨平台实时操作系统这一类平台在确定性、可预测性与实时保障上的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。`SylixOS` 是本项目的主实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本。**
+
+这里有三个基础判断：
+
+1. **研究对象是实时操作系统平台**；
+2. **人工智能推理在系统中承担目标负载角色**；
+3. **硬件条件以验证矩阵形式组织研究证据**。
+
+本研究评估的是：RTOS 在智能负载进入任务关键系统后，对系统秩序、时序边界与资源边界的维持能力。
+
+在这条主线之下，项目另设一个**面向小型化与低功耗方向的应用副课题**。这一副课题不改变“大型跨平台实时操作系统”作为研究对象的定位，主要用于在 `T5/T4` 两类部署形态中集中观察：当系统同时受到功耗、体积、散热与内存预算约束时，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、多节点集群 | 跨节点通信、分布式协同与规模扩展 |
+
+这五类部署形态首先依据**部署位置与系统角色**划分，其次才是容量和功耗。
+
+其中，`T1` 不表示通用训练机房或公网高吞吐推理集群，而是任务关键系统中的机架式协同计算平台。它承担的是全局状态管控、多源信息融合推理和跨节点决策协同等任务。
+
+### 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、网络互联、PTP   │
+└───────────────────────────────────────────────────────────────┘
+```
+
+**横向治理线**：安全、权限、配置版本、日志证据、时间同步、可观测性、OTA/回滚和审计能力贯穿五层，但不与任何单层并列。
+
+### 2.1 这套技术栈的意义
+
+这套表达用于把三个维度彻底拆开：
+
+- `T5~T1` 回答**在哪里验证**；
+- 五种算力基础回答**基于什么资源形态验证**；
+- 五层技术栈回答**系统内部怎么组织与保障**。
+
+这样就不会把“控制端 / 边缘节点 / 工作站 / 集群”误写成技术层，也不会把“MCU / SoC / GPU / 集群”误写成研究对象本身。
+
+### 2.2 人工智能目标负载到 RTOS 任务的映射
+
+```
+人工智能目标负载阶段          RTOS 侧任务/事件
+────────────────            ──────────────────
+输入处理 / Tokenization      → 低优先级辅助任务
+Embedding / Prefill         → 计算密集任务
+Attention / KV Cache         → 延迟敏感任务
+FFN / 设备计算              → 可流水化计算任务
+采样 / 输出决策              → 中优先级服务任务
+结果封装 / 输出通路          → 接口与通信任务
+```
+
+关键点在于：
+
+- 哪些阶段必须优先保障；
+- 哪些阶段可以延迟或限流；
+- 哪些资源需要隔离；
+- 哪些竞争会直接破坏关键保障负载。
+
+这里还要明确区分两类执行单元：
+
+- CPU 侧软件任务、系统调用、中断处理和资源治理逻辑，处于 RTOS 可调度与可分析范围；
+- GPU/NPU 等加速器内部算子流水线、显存调度和设备微架构执行行为，由驱动与硬件管理，不属于 RTOS 内核直接控制域。
+
+---
+
+## 3. 研究主线：实时保障机制
+
+项目后续所有子方向都服务于同一个主命题：
+
+> **大型跨平台实时操作系统如何在人工智能目标负载进入任务关键系统后，维持系统的确定性、可预测性与实时保障边界。**
+
+围绕这个主命题，系统机制可以分为六个方向：
+
+1. **推理图任务调度**
+2. **KV Cache 与内存管理**
+3. **加速器协同调度**
+4. **量化与精度感知调度**
+5. **中断与实时性保障**
+6. **能耗与热管理**
+
+这六个方向共同服务于一个判断：
+
+> **RTOS 能否在多类目标负载并存时，让系统继续有边界。**
+
+### 3.1 面向小型化与低功耗方向的应用副课题
+
+在六个机制方向之外，项目设置一条面向应用落点的专题线：
+
+> **面向小型化与低功耗方向的应用副课题。**
+
+这条副课题主要聚焦 `T5` 控制端与 `T4` 设备端 SoC 两类部署形态，重点关注下面四类约束同时成立时的系统表现：
+
+1. **功耗预算刚性**：整机输入功率、空闲功耗与单位任务能耗需要被明确约束；
+2. **体积与散热受限**：被动散热、轻量散热或设备本体内封装条件下的持续运行能力；
+3. **内存与带宽预算有限**：统一内存、片上 NPU/GPU 与 CPU 共享资源时的竞争边界；
+4. **关键保障任务不可退让**：控制回路、联锁与外部接口时序边界必须持续满足。
+
+这条副课题不与“推理图任务调度、KV Cache 与内存管理、加速器协同调度、量化与精度感知调度、中断与实时性保障、能耗与热管理”六个机制方向并列。它的作用是把这些机制组织成一个更聚焦的应用观察窗口，用于回答：
+
+- 小型化与低功耗系统是否仍能承载人工智能目标负载；
+- RTOS 在严格功耗与散热预算下如何维持关键保障负载边界；
+- 哪些机制组合最能体现 RTOS 相对普通 Linux 与 PREEMPT_RT Linux 的差异。
+
+因此，这一副课题承担的是“应用聚焦与证据收束”的角色，而不是新的并列机制方向。
+
+### 3.2 研究方法总述
+
+为了回答这个问题，研究方法采用一条统一证据链：
+
+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. **分析层**：面向人工智能目标负载与关键保障负载共存场景的可调度性建模、响应时间分析与边界推演方法；
+3. **机制层**：围绕调度、隔离、内存、中断、能耗的 SylixOS 实时保障机制；
+4. **方法层**：覆盖 `T5~T1` 五类部署形态的统一实验方法学；
+5. **数据层**：普通 Linux、PREEMPT_RT 与 SylixOS 的跨档位对照数据与边界证据；
+6. **应用层**：面向小型化与低功耗系统的专题化验证结论、边界解释与应用归纳；
+7. **论文层**：面向 RTSS、RTAS、EMSOFT、ISLPED 等方向的系统化论文与报告。
+
+---
+
+*最后更新: 2026-09-21*

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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**：运行时根据系统负载动态调整优先级？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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**: 多加速器间的动态负载均衡？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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**: 预测最佳精度, 避免频繁切换？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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**: 多中断并发时的优先级管理？

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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**: 多核场景下的热均衡调度？

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

@@ -0,0 +1,294 @@
+# 方向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` 个代表档位用于验证系统机制在不同资源条件下的成立范围与边界。
+
+这套验证矩阵统一的是建模、测量与对照方法，不预设同一套 RTOS 机制会在所有档位取得相同收益。研究重点是识别不同部署层级下机制有效的条件、收益来源与失效边界。
+
+对于 `T2/T1` 这类搭载独立 GPU 或复杂互联的层级，还需要单独区分两类证据：
+
+- CPU 侧实时调度、中断隔离、内存预算、关键保障负载保护等系统级证据；
+- 加速器执行、跨卡通信、驱动与运行时行为带来的平台级边界证据。
+
+前者属于 RTOS 直接可分析范围，后者作为系统约束和外部边界进入解释框架。
+
+## 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 分钟 |
+
+任何准入失败都要作为研究记录保留。
+
+对于 `T2/T1` 扩展层级，如果商业 GPU 驱动生态或平台条件限制了 RTOS 原生实测，需将该层级明确标注为建模分析、条件验证或基线对照证据，不把未完成的 RTOS 原生实测写成正式结果。
+
+## 6. 对照原则
+
+### 6.1 固定不变项
+
+为了保证 OS 对照公平，以下变量必须冻结：
+
+- 模型版本、量化格式、tokenizer、输入长度与输出长度；
+- CPU 核数量、优先级、内存预算、加速器数量；
+- 到达流、随机种子、预热时间、采样窗口；
+- PTP 或等效时钟同步方式、时间戳对齐策略与测量链路；
+- 环境温度、散热、驱动与框架版本。
+
+### 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` 为响应时间。
+
+人工智能目标负载根据其服务目标与预算，被建模为：
+
+- 可限流的服务任务；
+- 可准入的队列任务；
+- 可隔离的设备任务；
+- 必要时具有阶段性优先级的任务图。
+
+当场景包含跨节点协同或外部总线闭环时，还需把时间同步误差、通信抖动和设备完成事件纳入分析参数。对于具备形式化边界的关键保障任务，应进一步结合 WCET 假设、到达模型与调度策略，形成可调度性判定条件。
+
+### 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 分析仪 |
+| 时间同步 | PTP、硬件时间戳、同步误差校验脚本 |
+
+下面给出统一测量矩阵，用于把指标、采样工具与观测目的对齐：
+
+| 指标类别 | 代表指标 | 主要采样工具 | 观测目的 |
+|---|---|---|---|
+| 人工智能目标负载时效 | `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. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据；**
+4. **怎么用统一方法识别不同部署层级下 RTOS 机制的有效区间与失效边界。**
+
+这也是后续 `02-基础设备与算力基础.md`、`03-实验设计.md` 和 `04-论文写作规划.md` 必须共同服从的方法论中轴。

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

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

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

@@ -0,0 +1,178 @@
+# 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的研究逻辑说明
+
+## 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；
+- **硬件角色**：验证矩阵。
+
+在这条主线之下，项目同步设置一个**面向小型化与低功耗方向的应用副课题**。这一副课题主要锚定 `T5/T4`，用于集中组织小型化设备、设备端 SoC 与轻量智能终端中的证据，不单独改变研究对象，也不替代六个机制方向。
+
+## 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` 作为**部署形态与运行环境代码**，用于组织跨场景验证矩阵。
+
+其中，`T5/T4` 还承担面向小型化与低功耗方向应用副课题的主要验证窗口。这里的重点不是把低功耗设备本身当作研究对象，而是借助更严格的功耗、散热、体积与统一内存预算，观察 RTOS 机制边界在真实受限条件下的成立区间。
+
+## 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. 最后引入伴生竞争负载、突发场景、长稳运行与恢复测试。
+
+这条顺序用于区分平台就绪性问题与系统机制边界问题。
+
+对于面向小型化与低功耗方向的应用副课题，实验推进时优先选择 `T5-H`、`T4-L` 及后续 `T5-L/T5-M` 作为主验证窗口，再把结论回收到总课题的统一对照框架中。
+
+## 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章 |
+
+在这套结构下，硬件细度得到完整呈现，并服务于研究对象与实验结论组织。
+
+面向小型化与低功耗方向的应用副课题不单列为新的核心贡献项，而是作为 `C1` 与 `C2` 在 `T5/T4` 场景中的集中展开位置，用于加强项目在小型化设备与受限部署环境中的解释力。
+
+## 10. 最终闭环
+
+本研究形成的核心结论关系是：
+
+> **随着系统从 T5 控制端扩展到 T1 服务器 / 集群，大型跨平台实时操作系统这一类平台在多大范围内能够同时保证人工智能目标负载与关键保障负载，其优势来自哪些机制，又会在哪些档位开始收窄。SylixOS 是本项目的主实验样例。**
+
+在这条关系得到数据验证后，整个仓库会形成一条稳定主线：
+
+- 研究对象清楚；
+- 验证矩阵完整；
+- 对照关系公平；
+- 评价框架统一；
+- 论文叙事和产业叙事都能站住。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/20-实验与规划/02-基础设备与算力基础.md

@@ -0,0 +1,783 @@
+# 基础设备与算力基础配置（T5~T1 五类部署形态 / 11 个代表档位）
+
+> 版本: v2.1    起草日期: 2026-09-21
+> 设计目标: 为“**大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究**”建立完整的验证矩阵，并细化为 **T5~T1 五类部署形态 / 11 个代表实验档位**
+> 说明: 文中的 `T5~T1` 是**设备档位/运行形态代码**，用于组织实验与证据，承担验证矩阵角色
+
+---
+
+## 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 内存约束下的可行性验证

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

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

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

@@ -0,0 +1,453 @@
+# 论文写作规划 — 大型跨平台实时操作系统支撑任务关键系统中人工智能目标负载的实时保障机制研究
+
+> **版本**: 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 硬件层（含时间同步/PTP） → L2 RTOS 调度核 → L3 资源抽象 (加速器驱动/DMA/内存控制器) → L4 运行时 (任务图/流水线/内存池) → L5 模型层 (量化/KV Cache/投机解码) | 00-整体研究框架.md §2 |
+| 4.3 LLM 推理阶段 → RTOS 任务映射 | Tokenizer→LOW, Embedding→HIGH, Attention→MAX, FFN→HIGH, KV Cache Write→MEDIUM, Sample→LOW；阶段特征矩阵 (计算/IO/延迟敏感/确定性/优先级) | 01-推理图任务调度.md §2 |
+| 4.4 六大优化方向概览 | 方向1 推理图任务调度 (Hybrid FP+EDF) → 方向2 KV Cache 内存池 → 方向3 加速器协同 → 方向4 量化感知调度 → 方向5 中断与实时 → 方向6 能耗热管理 | 00-整体研究框架.md §3, 01~06 子文档 |
+| 4.5 面向小型化与低功耗方向的专题线 | 该专题线主要锚定 `T5/T4`，把调度、内存、量化、加速器协同、中断与能耗机制收束到受限功耗、体积、散热与内存预算场景中观察 | 00-整体研究框架.md §3.1 |
+| 4.6 SylixOS BSP 适配要点 | x86 BSP (V100/H100 CUDA 驱动, NVLink, RDMA)、ARM64 BSP (RK3588/RK3576/RK3568 NPU 驱动, T234 Jetson BSP)、内存分区限额 (一机两档)、跨核通信 (M0+RPMsg) | 02-基础设备与算力基础.md §7 (BSP Checklist) |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| 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.7A 管控边界说明 | 区分 CPU 侧 RTOS 可调度域与 GPU/NPU 设备执行域；T2/T1 的重点是 CPU 侧关键保障负载保护与系统协同边界，不把 GPU 内部调度写成 RTOS 直接收益 | 00-整体研究框架.md §2、03-实验设计.md §2、§3 |
+| 5.7B 证据层级说明 | 核心档位以实测为主；受驱动与 BSP 约束的扩展档位可使用基线对照、建模分析与条件验证，未完成的原生 RTOS 路径不写成正式结果 | 03-实验设计.md §1、§7 |
+| 5.8 研究问题到实验映射 | 明确 `RQ1~RQ4` 分别由哪些实验单元、场景编号与结果章节支撑，避免论文章节与实验表脱节 | 03-实验设计.md §1、§7 |
+| 5.9 场景编号到结果章节映射 | 明确 `L0~L7` 在论文中的归属位置：哪些是基线、哪些是核心双目标证据、哪些是扩展或压力场景 | 03-实验设计.md §6、§7 |
+
+**关键图表**:
+
+| 编号 | 图表 | 描述 |
+|------|------|------|
+| 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 优势；资源充裕且目标偏纯吞吐时，优势可能收窄；T1 仅限任务关键场景中的分布式协同计算平台，不覆盖通用 AI 训练集群 | 01-研究逻辑说明.md §10、03-实验设计.md §10 |
+| 9.2 威胁有效性 | (1) RKLLM 移植风险；(2) V100 驱动成熟度；(3) sysbench/stress-ng 等工具的可移植性；(4) 量化精度差异控制；(5) 室温/散热波动 | 03-实验设计.md §3、§11 |
+| 9.3 与已有工作的关系 | vs vLLM/TGI (服务器级, 无实时保证)、vs NPU SDK (封闭黑箱)、vs CUDA Stream (无实时分析)、vs 第三方文章 (仅 Linux, 仅 RK3588, 未测实时性) | 00-整体研究框架.md §6 |
+| 9.4 方法论局限 | 第三方来源数量有限；扩展档位依赖云租或后续采购；消融实验现阶段主要集中在现有核心平台；未完成档位不能写成正式结果 | 03-实验设计.md §10、07-方法论与评估工具链.md §10 |
+
+---
+
+### 第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 (相关工作), §7.2 (低功耗专题线), §8.3 (根因分析), §10.3 (开放问题) |
+| **01-推理图任务调度.md** | §4.3 (任务映射) | §7.4 (混合负载调度模型), §8.3 (根因) |
+| **02-KV-Cache与内存管理.md** | §4.4 (方向2 概览) | §7.4 (KV Cache 对实时任务的影响), §8.4 (能效) |
+| **03-加速器协同调度.md** | §4.4 (方向3 概览) | §7.7 (异构核分配), §8.3 (根因) |
+| **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 | 与第三方文章配置一致, 可比性最高 |
+
+---

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

@@ -0,0 +1,27 @@
+# 实验与规划索引
+
+本目录放置“怎么验证”和“怎么写成成果”的文档，负责把研究框架落到硬件、实验、论文规划和证据链上。
+
+## 阅读建议
+
+1. `01-研究逻辑说明.md`
+2. `02-基础设备与算力基础.md`
+3. `03-实验设计.md`
+4. `metric.md`
+5. `04-论文写作规划.md`
+6. `05-论文结构总览.png`
+
+## 文件说明
+
+- `01-研究逻辑说明.md`
+  - 项目研究逻辑总说明，串起验证矩阵、实验方案和论文贡献
+- `02-基础设备与算力基础.md`
+  - T5~T1 五类部署形态、五种算力基础下的十一档设备谱系与分级规则
+- `03-实验设计.md`
+  - 准入条件、对照原则、混合负载场景、指标与验收方法
+- `metric.md`
+  - 三层核心证据指标的统一定义、计算公式、采集要求与报告口径
+- `04-论文写作规划.md`
+  - 论文结构、章节分工、图表规划和证据映射
+- `05-论文结构总览.png`
+  - 文章结构与逻辑关系示意图

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

@@ -0,0 +1,397 @@
+# 核心证据指标说明
+
+## 1. 文档目的
+
+本文依据 [01-研究逻辑说明.md](./01-研究逻辑说明.md) 第 8 节，对后续实验必须覆盖的三层核心证据指标给出统一定义、计算方法、采集要求和报告口径。
+
+本指标体系用于回答一个核心问题：
+
+> **在人工智能目标负载与关键保障负载并存时，RTOS 能否在不牺牲任务质量和系统有效产出的前提下，提高系统的稳定性、可预测性与可保障性；这种提升在什么负载、功耗、温度和部署档位下成立。**
+
+指标分为三层：
+
+1. **人工智能目标负载层**：智能任务是否及时、正确、可用地完成；
+2. **关键保障负载层**：周期控制、联锁和外部闭环是否仍满足实时约束；
+3. **系统协同层**：双目标并存时，系统是否保持有效、节能、公平、稳定且可恢复。
+
+任何单一指标都不能独立支撑系统优越性结论。正式结论必须同时给出三层证据，并说明平台、OS、模型、负载、功耗、温度和运行时长等适用边界。
+
+## 2. 统一测量原则
+
+### 2.1 时间点与时钟
+
+人工智能请求至少记录以下时间点：
+
+| 符号 | 含义 |
+|---|---|
+| `a_i` | 请求计划到达时间 |
+| `s_i` | 请求实际发送时间 |
+| `u_i` | 服务端接收时间，可取得时记录 |
+| `g_i` | 首个有效输出到达时间 |
+| `c_i` | 完整输出到达或任务完成时间 |
+
+周期关键任务至少记录：
+
+| 符号 | 含义 |
+|---|---|
+| `r_i` | 计划释放时间 |
+| `q_i` | 进入就绪态时间，可等价取得时使用 |
+| `b_i` | 实际开始执行时间 |
+| `f_i` | 完成时间 |
+| `T` | 任务周期 |
+| `D` | 相对截止期 |
+
+同一指标必须在同一时钟域内计算，优先使用单调时钟。跨设备测量需在 `manifest` 中记录同步方法、同步误差和时间戳位置；同步误差不足以支持单向时延时，改报往返时延，不将往返时延简单除以二作为单向结果。
+
+### 2.2 统计与报告
+
+- 时延和抖动至少报告样本数、`P50/P95/P99/P99.9` 和观测最大值；样本不足以稳定估计 `P99.9` 时，明确标为探索性结果并改以 `P99` 为主。
+- 每个普通性能单元至少独立运行 5 次；跨运行报告中位数、区间和置信区间，不只报告最佳一次。
+- 最大值只能表述为“指定时长和工况下的观测最大值”，不能写成理论 `WCET`。
+- 零违约只能表述为“在 `N` 次计划释放中未观测到违约”，不能据此证明绝对硬实时安全。
+- 原始超时、拒绝、OOM、丢样和失败请求必须保留，不能从分母中静默删除。
+- OS 对照需冻结硬件、模型与量化版本、输入/输出长度、到达序列、随机种子、CPU/IRQ/频率配置、内存预算、加速器数量、散热条件和测量窗口。
+
+### 2.3 三层联合判定
+
+正式实验单元只有同时满足下列条件，才能记为“通过”：
+
+```text
+人工智能目标负载达标
+AND 关键保障负载达标
+AND 系统协同稳定
+```
+
+若通过拒绝大量请求、降低输出质量、缩短输出长度或减少关键任务计划释放次数来改善时延，该配置不能判定为优越。
+
+## 3. 人工智能目标负载层
+
+### 3.1 TTFT
+
+`TTFT`（Time To First Token）用于描述 LLM 请求从实际发出到首个有效 token 到达的时间：
+
+```text
+TTFT_i = g_i - s_i
+```
+
+该指标包含请求传输、排队、调度和 prefill 阶段。负载发生器还应记录发送滞后 `s_i-a_i`，防止发生器本身饱和导致排队时间被遗漏。
+
+报告要求：
+
+- 单位统一为 `ms`；
+- 按模型、输入长度、并发度和到达率分别汇总；
+- 至少报告 `P50/P95/P99/P99.9/Max`、样本数和超时数；
+- 流式接口以客户端收到首个**有效内容 token**为终点，不把连接确认、空片段或仅含元数据的事件作为首 token；
+- 非生成式人工智能任务不使用 `TTFT`，改用任务对应的首结果时间，并明确终点语义。
+
+### 3.2 TPOT
+
+`TPOT`（Time Per Output Token）描述首 token 之后的平均生成间隔。对输出 token 数 `n_i > 1` 的请求：
+
+```text
+TPOT_i = (c_i - g_i) / (n_i - 1)
+```
+
+报告要求：
+
+- 单位统一为 `ms/token`；
+- `n_i <= 1` 的请求记为不可计算，不以 0 填充；
+- 请求级 `TPOT` 与逐 token 间隔分布分开报告；
+- 同时报告实际输出 token 数，避免提前终止请求造成虚假的 TPOT 改善；
+- 按输入长度、输出长度、并发度和到达率分组。
+
+### 3.3 端到端响应时间
+
+端到端响应时间描述从请求实际发出到完整可用结果到达的时间：
+
+```text
+T_e2e,i = c_i - s_i
+```
+
+对于非 LLM 任务，应冻结起点和终点：例如视觉任务可定义为“帧进入应用边界至检测结果可被控制逻辑读取”，语音任务可定义为“音频块提交至最终文本可用”。设备执行事件只能用于阶段归因，不能代替包含排队、传输和后处理的完整链路。
+
+除分位数外，还需按业务完成期限 `D_ai` 报告按时完成率：
+
+```text
+on_time_completion_ratio
+= count(success_i AND T_e2e,i <= D_ai) / planned_requests
+```
+
+### 3.4 成功率、任务质量与输出可用性
+
+三个概念必须分开计算：
+
+| 指标 | 定义 | 典型失败 |
+|---|---|---|
+| 请求成功率 | 协议和运行时层面正常完成的请求数 / 计划请求数 | 超时、拒绝、崩溃、OOM、传输失败 |
+| 任务质量 | 输出与冻结的参考答案或数据集指标之间的符合程度 | 精度下降、错误分类、内容偏差 |
+| 输出可用率 | 同时满足成功、质量和业务格式/安全规则的输出数 / 计划请求数 | 空输出、截断、格式错误、不可解析或不满足质量门槛 |
+
+计算式：
+
+```text
+success_ratio = successful_requests / planned_requests
+usable_output_ratio = usable_outputs / planned_requests
+```
+
+任务质量应按负载类型选择并预先冻结：
+
+- LLM：固定题集得分、精确匹配、规则判分或人工盲评结果；
+- 视觉检测：`mAP`、召回率、误检率；
+- 分类：准确率、F1 等；
+- 语音识别：`WER/CER`；
+- 故障诊断：检出率、漏报率、误报率。
+
+量化或调度优化必须同时报告质量变化。仅提高速度但跌破质量门槛的输出不得计入有效结果。
+
+### 3.5 长时间运行稳定性
+
+人工智能负载稳定性用于检查持续运行时的性能和正确性是否退化。至少观测：
+
+- 每个时间块的 `TTFT/TPOT/T_e2e` 分位数；
+- 请求成功率、输出可用率和错误类型；
+- 吞吐、队列长度、内存和 KV Cache 占用；
+- 温度、实际频率、进程重启和驱动异常。
+
+建议将 24 h 运行划分为固定时间块，并比较早期稳定段与后期稳定段。可定义时延漂移率：
+
+```text
+latency_drift = (late_block_metric - early_block_metric)
+                / early_block_metric
+```
+
+报告时需给出完整时间序列，不能仅给 24 h 总平均值。持续内存增长、尾延迟恶化、成功率下降或周期性驱动错误均应作为稳定性退化证据。
+
+## 4. 关键保障负载层
+
+### 4.1 Deadline miss ratio
+
+对第 `i` 次计划释放，若 `f_i > r_i + D`，则发生截止期违约：
+
+```text
+miss_i = 1, if f_i > r_i + D; otherwise 0
+deadline_miss_ratio = sum(miss_i) / planned_releases
+```
+
+要求：
+
+- 分母必须是计划释放次数，而不是实际完成次数；
+- 未释放、跳过、丢失或未完成的实例必须单独标记，不能直接从分母删除；
+- 同时报告违约数、计划释放数、连续违约长度和违约发生时间；
+- 按场景、负载强度和 OS 配置分别统计。
+
+### 4.2 P99/P99.9 jitter
+
+本文默认以完成间隔抖动作为关键保障负载的主抖动口径：
+
+```text
+jitter_i = (f_i - f_(i-1)) - T
+```
+
+同时可报告绝对抖动 `abs(jitter_i)`。若使用释放抖动、唤醒抖动或响应时间波动，必须另行命名，不能与完成间隔抖动混用。
+
+报告要求：
+
+- 有符号抖动报告上下尾，绝对抖动报告 `P99/P99.9/Max`；
+- 附带时间序列，标出模型加载、突发流量、中断风暴、降频和故障注入事件；
+- 给出样本量及采样周期；
+- 不使用均值或标准差替代尾部分位数。
+
+### 4.3 观测最大响应时间
+
+关键任务响应时间定义为：
+
+```text
+R_i = f_i - r_i
+R_observed_max = max(R_i)
+```
+
+观测最大响应时间需要与截止期 `D` 并列展示，并给出裕量：
+
+```text
+deadline_margin = D - R_observed_max
+```
+
+`deadline_margin < 0` 表示至少出现一次违约。该指标必须附带运行时长、样本数、负载强度和发生最大值时的系统事件，不得将其描述为理论最坏响应时间。
+
+### 4.4 外部接口响应时间
+
+外部接口响应时间用于验证完整物理闭环，而不是仅验证内部线程调度。根据平台选择 GPIO、CAN、RS485 或网络回路：
+
+```text
+T_external = t_external_output - t_external_input
+```
+
+采集要求：
+
+- 优先使用示波器、逻辑分析仪、总线分析仪或对端硬件时间戳；
+- 固定波特率、帧长、总线负载、网络拓扑和时间戳位置；
+- 报告空回路基线、测量分辨率和仪器误差；
+- 报告 `P50/P99/P99.9/Max`、超时和丢帧；
+- 内核或应用日志仅作为归因证据，不能替代外部闭环测量。
+
+## 5. 系统协同层
+
+### 5.1 有效吞吐
+
+有效吞吐只统计同时满足时限、质量和可用性门槛的成功输出：
+
+```text
+effective_throughput
+= qualified_output_units / measurement_window
+```
+
+对 LLM，`qualified_output_units` 为合格请求产生的输出 token 数；对视觉任务可使用合格帧数，对请求型任务可使用合格请求数。
+
+合格请求至少满足：
+
+```text
+请求成功
+AND TTFT/端到端期限达标
+AND 任务质量达标
+AND 输出可用
+AND 同一窗口内关键保障负载达标
+```
+
+有效吞吐必须与总吞吐、请求完成率、拒绝率、超时率和错误率并列报告，避免通过拒绝或丢弃工作改善尾延迟。
+
+### 5.2 E/token
+
+在与负载统计完全一致的窗口 `[t0,t1]` 内：
+
+```text
+E_total = integral(P(t), t0, t1)
+E/token = E_total / N_output
+tokens/J = N_output / E_total
+```
+
+其中 `N_output` 为窗口内实际收到的输出 token 数。主结果使用整机输入端实测能耗，包含排队、空闲和失败请求消耗；板载或加速器遥测用于归因，不能替代整机测量。
+
+要求：
+
+- 单位为 `J/token`，同时报告平均功率、峰值采样功率和仪器采样率；
+- `N_output = 0` 时记为不可计算，不记为 0；
+- 同时报有效 `E/token = E_total / N_qualified_output`，以反映失败和不合格输出的成本；
+- 混合视觉与 LLM 负载时，不将全部能耗归因于 LLM，应使用独立对照或单列场景总能耗；
+- 只在人工智能与关键保障约束均满足的配置之间比较能效。
+
+### 5.3 温度、降频与热漂移
+
+全程同步记录：
+
+- 环境温度、芯片/板卡温度；
+- CPU、GPU、NPU 和内存相关实际频率；
+- 降频事件及其原因；
+- 功率、风扇/散热策略；
+- 同时间轴上的时延、吞吐和违约。
+
+降频时间比例定义为：
+
+```text
+throttling_ratio = throttled_time / valid_measurement_time
+```
+
+热漂移用于表示系统热稳定后相对冷态或早期稳定段的性能变化：
+
+```text
+thermal_drift(metric)
+= (hot_steady_metric - early_steady_metric) / early_steady_metric
+```
+
+时延和能耗类指标的正漂移通常表示恶化；吞吐类指标的负漂移表示恶化。报告必须说明温度传感器来源、采样频率和稳态判定方法，并把温度—频率—性能三者放在同一时间轴分析。
+
+### 5.4 多任务公平性
+
+多租户或多模型并发场景使用各任务相对独占性能 `x_i` 计算 Jain 公平指数：
+
+```text
+J = (sum(x_i))^2 / (k * sum(x_i^2))
+```
+
+其中 `k` 为任务数，`x_i` 可取“共享运行时的有效吞吐 / 独占运行时的有效吞吐”。`J` 越接近 1，吞吐分配越均衡。
+
+公平性不能只用一个指数概括，还应报告：
+
+- 每个任务或租户的有效吞吐、`TTFT`、端到端时延和成功率；
+- 关键任务是否满足各自服务等级；
+- 饥饿次数、最长无服务时间和优先级倒置事件；
+- 高优先级保障所造成的低优先级代价。
+
+对具有不同优先级和服务等级的任务，“公平”不是平均分配资源，而是在满足保障等级后不存在非预期饥饿。因此 Jain 指数只作为补充证据，不能替代逐任务 SLA 结果。
+
+### 5.5 恢复能力
+
+恢复测试应预先定义故障注入时刻 `t_fault` 和恢复判据。至少覆盖推理进程重启和队列过载；驱动重置、设备掉线或网络故障仅在存在安全、可恢复路径时执行。
+
+建议记录：
+
+| 指标 | 定义 |
+|---|---|
+| 故障检测时间 | 检测到故障的时刻减 `t_fault` |
+| 服务恢复时间 | 恢复到预定成功率和有效吞吐稳定区间的时刻减 `t_fault` |
+| 数据损失 | 故障窗口内丢失、重复或无法确认的请求数 |
+| 实时影响 | 故障窗口内关键任务违约数及最大响应时间 |
+| 重试成功率 | 成功重试请求数 / 发起重试请求数 |
+| 不可恢复故障数 | 需要人工干预、重启系统或丢失测量链路的次数 |
+
+恢复完成必须同时满足人工智能服务恢复和关键保障负载重新达标。仅进程重新启动但吞吐、队列或实时任务仍未恢复，不算恢复完成。
+
+### 5.6 24 h 长稳表现
+
+24 h 长稳采用人工智能目标负载、关键保障负载及必要伴生竞争负载的混合场景。至少连续记录：
+
+- 三层核心指标的固定时间块汇总；
+- 温度、频率、功率和降频事件；
+- 内存、KV Cache、句柄/线程和队列长度；
+- OOM、驱动错误、进程重启、接口超时和日志中断；
+- 注入故障前后恢复曲线。
+
+长稳通过条件至少包括：
+
+1. 完成连续 24 h 有效测量；
+2. 无不可恢复故障；
+3. 测量与日志链路无中断；
+4. 无持续、不可解释的内存增长；
+5. 人工智能输出与关键保障负载在冻结阈值内；
+6. 故障注入后在冻结时间内恢复。
+
+若发生故障，必须保留原始数据并分析，不得删除故障批次后宣称长稳通过。
+
+## 6. 指标—数据源—实验映射
+
+| 层级 | 指标 | 主要数据源 | 主要实验/场景 |
+|---|---|---|---|
+| 人工智能目标负载 | `TTFT/TPOT`、端到端响应时间 | `requests.csv`、负载发生器、推理日志 | E2/E3/E8，L1～L7 |
+| 人工智能目标负载 | 成功率、质量、输出可用率 | 请求日志、固定题集/数据集、判分程序 | E2/E3/E4/E8 |
+| 人工智能目标负载 | 长时间稳定性 | 分块请求汇总、内存和错误日志 | E8，24 h |
+| 关键保障负载 | 违约率、抖动、最大响应时间 | `rt.csv`、RTOS trace、GPIO 打点 | E1/E3/E7/E8，L0/L2～L7 |
+| 关键保障负载 | 外部接口响应时间 | 示波器、逻辑/总线分析仪、抓包 | E1/E3/E8 |
+| 系统协同 | 有效吞吐 | 请求、质量和 RT 数据联合计算 | E3/E5/E7/E8 |
+| 系统协同 | `E/token` | 外部功率计/PDU、`requests.csv` | E2/E6/E8 |
+| 系统协同 | 温度、降频、热漂移 | `thermal.csv`、频率与功率日志 | E6/E8 |
+| 系统协同 | 多任务公平性 | 各租户请求日志和独占基线 | E5，L6 |
+| 系统协同 | 恢复与 24 h 长稳 | `events.log`、三层时间序列 | E8，L7 |
+
+## 7. 最小数据产物
+
+每次运行至少保存：
+
+| 文件 | 必需内容 |
+|---|---|
+| `manifest.json` | 平台/档位、OS/BSP/驱动、模型校验值、量化、输入、到达序列、CPU/IRQ/频率/内存配置、环境和仪器信息 |
+| `requests.csv` | 请求 ID、计划到达、实际发送、首/末输出、输出数、成功、质量、可用性、超时/拒绝原因 |
+| `rt.csv` | 计划释放、就绪、开始、完成、CPU、违约、丢失/跳过状态 |
+| `power.csv` | 时间戳、功率、电压、电流、仪器来源 |
+| `thermal.csv` | 时间戳、环境/芯片温度、实际频率、降频状态 |
+| `events.log` | OOM、驱动错误、故障注入、重启、网络异常、测量故障 |
+| `summary.json` | 三层指标、样本量、分位数、最大值、区间、阈值和判定结果 |
+
+所有派生指标必须能够从原始记录重新计算。汇总程序不得覆盖原始文件，不得静默剔除异常值。
+
+## 8. 核心证据表述模板
+
+正式报告应采用带边界的联合表述：
+
+> 在 `[平台/档位]`、`[模型与输入输出配置]`、`[到达率与竞争负载]`、`[功耗和温度条件]` 下，`[OS/配置]` 在人工智能目标负载达到 `[TTFT/TPOT/质量/可用率]`、关键保障负载达到 `[违约率/P99.9/观测最大响应]` 的同时，实现 `[有效吞吐和 E/token]`，并在 `[故障与 24 h 长稳结果]` 下保持稳定。相对 `[对照组]` 的改善为 `[效应量及置信区间]`。
+
+不应只写“平均时延更低”“吞吐更高”或“24 小时无故障”。结论必须明确三层约束是否同时满足、比较基线是什么、改善代价是什么，以及结论适用于哪些部署档位和运行条件。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/README.md

@@ -0,0 +1,21 @@
+# 联合研究方索引
+
+本目录用于存放与项目潜在合作方、教授、团队背景有关的资料，服务于联合研究、外部沟通和人物画像整理。
+
+## 当前内容
+
+- `潜在合作研究路径-罗蕾教授与翼辉信息.md`
+  - 面向项目内部的合作设想文档
+  - 梳理罗蕾教授与翼辉信息在联合研究中的角色分工与协同结构
+- `罗蕾教授资料/`
+  - 电子科技大学知名专家学者罗蕾教授背景与研究工作介绍
+  - 包含人物概览、教学与人才培养、科研与产业化路径、代表成果与研究主题
+- `翼辉信息资料/`
+  - 具有较强行业代表性的 RTOS 与基础软件平台厂商翼辉信息与 SylixOS 平台介绍
+  - 包含公司与 RTOS 定位概览、SylixOS 技术能力与演进、行业落地与生态版图、与本项目的潜在协同点
+
+## 使用建议
+
+- 对外沟通时，可先阅读人物概览与科研路径两篇。
+- 讨论合作路径时，可先阅读 `潜在合作研究路径-罗蕾教授与翼辉信息.md`，但需注意其性质是内部筹划稿，不代表对方已确认加入。
+- 形成合作建议时，可结合本仓库 `00-项目总览/` 与 `20-实验与规划/` 一起使用。

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

@@ -0,0 +1,210 @@
+# 潜在合作研究路径：罗蕾教授与翼辉信息
+
+> 说明：本文用于项目内部的合作筹划与分工设计，服务于联合研究中的角色划分、协同结构设计与前期沟通准备。
+
+## 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 联合论文 / 白皮书 / 申报材料
+
+目标：
+
+- 学术上形成论文；
+- 产业上形成白皮书或联合研究说明；
+- 条件成熟后，再进一步走项目申报、平台共建或联合实验室路径。
+
+更适合的分工：
+
+- 罗蕾教授侧偏学术与规范表达；
+- 翼辉信息侧偏产业价值、案例与平台能力；
+- 项目组承担材料汇总、写作配合与整合支撑。
+
+### 5.5 面向小型化与低功耗方向的 RTOS 智能负载应用
+
+目标：
+
+- 聚焦小型化设备、边缘控制节点、轻量智能终端中的人工智能目标负载部署问题；
+- 研究在严格功耗、体积、散热与内存预算下，RTOS 如何同时维持推理服务能力与关键保障任务实时性；
+- 形成一套适用于低功耗、资源受限系统的任务准入、运行降级与能耗治理方法。
+
+更适合的分工：
+
+- 罗蕾教授侧可重点参与资源约束建模、可调度性分析、低功耗系统方法学抽象与学术问题凝练；
+- 翼辉信息侧可重点参与 SylixOS 在小型化硬件平台上的机制实现、BSP 支撑与工程验证；
+- 项目组负责具体场景选取、实验执行、数据整理与跨平台对照分析。
+
+这一主题与本项目现有 `T5/T4` 验证位置可以自然衔接，也更容易延伸到工业控制终端、车载边缘节点、轻量智能装备等应用语境。
+
+## 6. 更现实的推进顺序
+
+推进顺序以稳妥、小步、可验证为宜：
+
+1. **先分别沟通**：确认双方对课题定位、研究边界、合作兴趣是否一致；
+2. **先小后大**：先围绕一个具体问题试合作，例如基准设计、实验审阅或场景讨论；
+3. **先方法后平台**：先把研究问题和方法学框架对齐，再谈平台实现细节；
+4. **先形成最小闭环**：先做出一版可验证的实验与分析，再决定是否扩展成正式联合研究。
+
+## 7. 当前文档使用边界
+
+这份文档当前更适合作为：
+
+- 项目内部筹划材料；
+- 对外沟通前的思路整理；
+- 预判双方合作接口是否互补的参考稿。
+
+当前使用场景包括：
+
+- 项目内部筹划与分工设计；
+- 对外沟通前的内容准备；
+- 合作接口与协同结构的前期梳理。
+
+这份文档回答的是：
+
+> **与罗蕾教授、翼辉信息形成联合研究时，最合理的合作结构是什么。**

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/01-人物概览.md

@@ -0,0 +1,18 @@
+# 罗蕾教授人物概览
+
+罗蕾教授是电子科技大学教授、博士生导师，长期在电子科技大学从事嵌入式基础软件相关教学、科研与产业化工作。她曾任嵌入式软件工程中心主任，持续聚焦嵌入式操作系统、物联网网络安全与数据安全、工业软件、智能计算等方向，是电子科技大学在嵌入式系统与相关产业应用领域具有较高影响力、广受尊重的知名专家学者。
+
+罗蕾教授与电子科技大学保持了长期稳定的学术关联。她于 1987 年毕业于电子科技大学计算机系，1996 年晋升副教授，2003 年评为教授，2005 年晋升博士生导师。她既是学校本土培养起来的教师，也长期参与了学科建设、课程建设与团队建设。
+
+罗蕾教授的工作范围已经超出了传统高校教师的单一角色。她曾作为国家“核高基”专家参与智能手机、汽车电子、数字电视等多项嵌入式基础软件重大专项实施，同时担任国家智能网联汽车创新中心专家、车载信息服务产业应用联盟（TIAA）网络安全委员会秘书长、工信部区块链技术与数据安全重点实验室相关专家等职务。她的工作位置也因此横跨了高校、重大专项、行业联盟和产业协同几个层面。
+
+罗蕾教授的研究主线是一条逐步扩展的“底层软件到行业场景”的路线。较早阶段，她的工作更多与嵌入式实时操作系统、嵌入式基础软件和开发工具有关；随后逐步延伸到汽车电子、物联网安全、移动支付、区块链与数据安全，再到今天更强调工业软件、网络安全和智能计算。这种演进很有代表性，反映出她的研究沿着产业需求不断外扩。
+
+罗蕾教授是一位具有明显“工程化导向”和产业连接能力、在相关领域享有较高声誉的知名专家学者。她既有学校内部的学术与教学身份，也深度参与国家项目、行业标准和企业合作；既关注嵌入式系统的底层技术，又把研究延伸到汽车、支付、数据安全等具体行业。她的个人画像体现出“学术研究者 + 工程组织者 + 产业连接者”的复合型角色。
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
+2. 电子科技大学研招导师风采页：<https://yz.uestc.edu.cn/info/1025/2764.htm>
+3. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
+4. 科创中国个人主页：<https://www.kczg.org.cn/xuezhe/details?id=419875>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/02-教学与人才培养.md

@@ -0,0 +1,20 @@
+# 罗蕾教授的教学与人才培养工作
+
+罗蕾教授不仅是一位在嵌入式系统领域具有较高影响力的专家学者，也长期深度投入教学工作。她的教学工作有一个很明显的特点：围绕一门核心课程，把教材、实验、课程资源和人才培养体系连在一起。
+
+最能代表这一点的课程，是《嵌入式系统及应用》。这门课早在 2007 年就获得国家精品课程认定，之后又先后成为四川省精品资源共享课、四川省精品在线开放课程，并在 2023 年获得国家级一流本科课程认定。它是一门经过多年迭代、持续建设的核心课程。
+
+这门课是一门典型的工程化课程。课程内容覆盖嵌入式系统导论、ARM 体系结构与编程、嵌入式软件系统、任务管理与调度、同步互斥与通信、中断时间和内存管理等主题，并配有 ARM 实验和 uC/OS-II 操作系统实验。课程结构采用“原理 + 实验 + 开发能力”的组织方式，目标是让学生真正进入嵌入式系统开发。
+
+罗蕾教授在教学上的另一个特点，是把教材建设和课程建设配套推进。她主编过《嵌入式实时操作系统及应用开发》第一、二、三版，以及《嵌入式系统及应用》等著作。对一门工科课程来说，教材是否成体系，往往决定了课程能否长期稳定传承；她也由此搭建起一个可复制、可持续的知识框架。
+
+罗蕾教授的人才培养方向也比较清晰。她指导的软件工程、电子信息等学位点，研究方向主要包括嵌入式软件技术与应用、工业软件、网络安全、智能计算等。这些方向既有传统的嵌入式系统主线，也对接了当下工业软件和安全计算的需求。她的人才培养模式强调“从基础软件出发，向新应用场景延展”。
+
+罗蕾教授在教学上的重要性，体现在她于电子科技大学长期建设出了一套有工程背景、有实验支持、有教材配套、能持续培养学生的嵌入式教学体系。这也是这位知名专家学者在校内外形成广泛学术影响力的重要来源之一。
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
+2. 电子科技大学计算机学院教学成果页：<https://www.scse.uestc.edu.cn/info/1039/10809.htm>
+3. 中国大学 MOOC《嵌入式系统及应用》课程页：<https://www.icourse163.org/course/UESTC-1206862805?from=searchPage&outVendor=zw_mooc_pcssjg_>
+4. 电子科技大学教学资源平台课程页：<https://resource.uestc.edu.cn/learn/course/preview/spoc/17269f9718ed4af1b94108437e6b6e1a>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/03-科研与产业化路径.md

@@ -0,0 +1,21 @@
+# 罗蕾教授的科研与产业化路径
+
+罗蕾教授的科研工作持续把嵌入式基础软件能力往产业场景里推进。作为电子科技大学相关方向具有代表性的知名专家学者，她长期主持或参与国家重大专项、863 项目、自然科学基金、发改委软件产业化专项等任务，同时又深度参与企业合作、行业标准与联盟工作。这种“研究 - 标准 - 产品 - 场景”连起来的路径，是她区别于很多纯学院型学者的重要地方。
+
+她早期的重要发力点是嵌入式基础软件和实时操作系统。她曾主持“面向嵌入式软件的生产线”“智能手机嵌入式软件平台”“嵌入式实时操作系统及其开发工具”等项目，所在团队也长期围绕嵌入式操作系统、嵌入式网络安全、汽车电子基础软件展开工作。这类方向的共同点，是都处在系统底层，技术门槛高、复用价值大，而且很容易形成行业平台能力。
+
+之后，她的科研和产业化路径逐步向汽车电子和网络安全方向深化。团队列出的代表性项目里，既有“汽车电子网络安全标准化研究白皮书编制”“面向汽车电子的代码安全技术研究与实现”，也有“智能汽车安全加固与监控产品研发与产业化”“车辆身份唯一性认证模型的测试委托”等项目。罗蕾教授的工作集中在汽车电子基础软件、代码安全、身份认证、网络安全标准等更底层、更可落地的位置。
+
+同时，她的团队也明显向区块链与数据安全扩展。相关成果包括区块链基础平台“优云链”和面向数据共享的“优数”平台，应用场景覆盖无人机运输物流追踪、汽车大数据交易平台、学分银行、移动支付可信数据共享联盟链、国际贸易通关协同、财政资金监管等。她所推动的区块链工作与数据确权、共享交换、可信交易、安全监管等产业需求直接挂钩。
+
+除了项目本身，罗蕾教授在行业规则层面的参与也很值得关注。她牵头或参与了 20 余项国家、行业和团体标准，团队也参与了多项汽车网络安全相关国家标准与行业标准。她的影响力同时体现在技术落地和行业通用规则推进两个层面。对很多产业技术路线来说，这一步往往比单点成果更有长期影响。
+
+她的科研路径可以概括为三层：第一层是嵌入式操作系统、开发工具和基础软件；第二层是网络安全、汽车电子、物联网与数据安全；第三层是标准化、产业平台和企业合作落地。正因为这三层是打通的，罗蕾教授的工作才呈现出很强的“工程系统型”特征，并形成了连续展开的研究主题体系。
+
+## 参考资料
+
+1. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
+2. 电子科技大学研招导师风采页：<https://yz.uestc.edu.cn/info/1025/2764.htm>
+3. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
+4. 科创中国个人主页：<https://www.kczg.org.cn/xuezhe/details?id=419875>
+5. 世展网转载行业观点文章：<https://www.shifair.com/informationDetails/135407.html>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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. 电子科技大学研究生导师信息页：<https://yjsjy.uestc.edu.cn/gmis/jcsjgl/dsfc/dsgrjj/10322>
+2. 电子科技大学计算机学院科研团队页：<https://www.scse.uestc.edu.cn/info/1028/5993.htm>
+3. 电子科技大学学报相关论文页：<http://www.juestc.uestc.edu.cn/article/doi/10.3969/j.issn.1001-0548.2014.03.023?viewType=citedby-info>
+4. 学术摘要页《汽车电子嵌入式操作系统的隔离保护机制》：<https://www.xueshu.com/dzkjdxxb/201403/2984678.html>
+5. 维普摘要页《AUTOSAR可运行实体-任务自动映射方法研究》：<http://dianda.cqvip.com/Qikan/Article/Detail?id=7000589928>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/罗蕾教授资料/README.md

@@ -0,0 +1,15 @@
+# 罗蕾教授资料目录
+
+本目录用于介绍罗蕾教授的学术背景、教学工作、科研路径与代表性研究主题，并将内容拆分为几篇可以独立阅读的介绍文章。
+
+## 文件列表
+
+- `01-人物概览.md`：聚焦罗蕾教授的基本履历、学术身份与整体定位。
+- `02-教学与人才培养.md`：聚焦课程建设、教材编写与人才培养工作。
+- `03-科研与产业化路径.md`：聚焦科研方向、重大项目、行业标准与产业合作。
+- `04-代表成果与研究主题.md`：聚焦代表性研究主题、论文与技术成果。
+
+## 使用说明
+
+- 各文档彼此独立，可单独转发或继续扩写。
+- 各文档正文以人物介绍和研究工作为主，参考资料统一列于文末。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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. 翼辉信息官网首页：<https://www.acoinfo.com/>
+2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
+3. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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 官方文档《发展历程》：<https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html>
+2. 翼辉信息官网首页：<https://www.acoinfo.com/>
+3. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/翼辉信息资料/03-行业落地与生态版图.md

@@ -0,0 +1,18 @@
+# 行业落地与生态版图
+
+翼辉信息持续进入关键行业落地场景，其服务对象集中在火箭、卫星、高铁、大飞机、工业自动化、能源电力、智能汽车、低空经济等任务关键型装备领域。这些行业共同要求硬实时或强实时、长期稳定、功能安全和工程可维护性。
+
+翼辉信息正在构建一套更完整的生态版图。除了 SylixOS 之外，公开展示的还包括 RealEvo 轻量开发环境、VSOA 分布式软总线、工业自动化数字基座、可编程控制器、虚拟 PLC、边缘计算机、飞控系统、飞行仿真平台等。其商业策略已延伸到“关键装备基础软件平台方”这一层级。对联合研究而言，这种生态化布局可以覆盖内核测评、整机验证、边缘控制、系统集成和行业样机落地等更宽的接口。
+
+行业案例与用户故事也体现出清晰的行业线索。首页展示了中国铁道科学研究院和星际荣耀的用户评价，前者强调轨交信号控制系统对功能安全、稳定性、实时性的苛刻要求，后者强调在火箭飞控场景中通过 RTOS 对复杂软件进行分层抽象的重要性。航天行业页面还提到，翼辉信息与相关航天单位开展深度合作，基于 SylixOS 的星载操作系统用于星务和载荷设备开发，并参与火箭控制器、卫星载荷等系统建设。翼辉的主要市场集中在高可靠装备场景。
+
+翼辉信息在南京的软件产业生态中也被作为“工业底层操作系统”代表企业来呈现。2026 年南京雨花台区公开报道提到，南京翼辉信息 2016 年落地软件谷，围绕 SylixOS 研发逐步形成产业能力，并将经验复制到水务、地铁运营、地下空间运维等场景。报道还提到其正推动人工智能、边缘计算与操作系统深度融合。翼辉的产业化路径已经覆盖军工之外的城市基础设施和工业场景。
+
+翼辉信息已经把 RTOS 能力嵌入了多个高要求行业场景，并在工具链、行业方案和系统架构层面继续外扩。对本项目而言，它既是实验平台的重要来源，也是后续验证场景和行业接口的重要支撑。
+
+## 参考资料
+
+1. 翼辉信息官网首页：<https://www.acoinfo.com/>
+2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
+3. 翼辉信息航天行业页：<http://www.acoinfo.cn/industry-center/spaceflight>
+4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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. 翼辉信息官网首页：<https://www.acoinfo.com/>
+2. 翼辉信息官网 About 页面：<https://www.acoinfo.com/about>
+3. SylixOS 官方文档《发展历程》：<https://docs.acoinfo.com/sylixos/start/get_to_know_sylixos/development_history.html>
+4. 南京雨花台区公开报道《聚焦软件大会|扎根软件名城 长成参天大树》：<http://www.njyh.gov.cn/ywdt/gnzx/202606/t20260626_5866615.html>

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/30-联合研究方/翼辉信息资料/README.md

@@ -0,0 +1,15 @@
+# 翼辉信息资料目录
+
+本目录用于介绍翼辉信息及其 SylixOS 技术体系，服务于联合研究判断、产业协同沟通和 RTOS 技术路线分析。
+
+## 文件列表
+
+- `01-公司与RTOS定位概览.md`：聚焦翼辉信息的公司定位、核心产品和公开产业身份。
+- `02-SylixOS技术能力与演进.md`：聚焦 SylixOS 的技术特征、发展里程碑和能力边界。
+- `03-行业落地与生态版图.md`：聚焦翼辉信息在关键行业的应用方向、案例和生态布局。
+- `04-与本项目的潜在协同点.md`：聚焦翼辉信息与本项目“RTOS 管理 LLM 推理资源竞争”主题的结合点。
+
+## 使用说明
+
+- 各文档彼此独立，可单独阅读或继续扩写。
+- 正文以公司定位、平台能力和行业应用介绍为主，参考资料统一列于文末。

02-项目框架/01-项目框架1-基于RTOS的五类场景AI实时性研究/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-归档/` 存放外部导入副本、压缩包与阶段性暂存内容。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/00-总课题总览/01-当前研究问题：背景、问题与挑战.md

@@ -0,0 +1,59 @@
+# 当前研究问题：背景、问题与挑战
+
+## 1. 背景
+
+人工智能能力正在从服务器、云端和通用应用软件，持续进入设备控制、边缘协同、车载平台、工业终端和任务关键系统。系统中的人工智能不再只是离线分析能力，而正在承担识别、规划、诊断、导航、辅助决策和自然交互等面向实时场景的功能。
+
+当人工智能能力进入这些系统后，系统的时间结构发生了明显变化：
+
+- 感知链路、推理链路与控制链路开始耦合；
+- CPU、NPU、GPU、DMA、总线和内存带宽竞争明显增强；
+- 功耗、散热、体积、统一内存和设备驱动限制直接影响系统行为；
+- 关键保障负载与人工智能目标负载开始争夺同一组底层资源。
+
+因此，系统面对的已经不是单纯的“把模型跑起来”问题，而是“如何让人工智能能力进入系统之后，整体时序边界仍然成立”的问题。
+
+## 2. 问题
+
+本框架聚焦的问题是：
+
+> **当人工智能能力进入实时控制系统后，模型、运行时、RTOS、Linux、Hypervisor、芯片、总线、内存和协处理器如何共同决定系统的整体实时边界。**
+
+这里的核心观察有三点：
+
+1. **大模型与智能算法的实时问题不能完全归于 RTOS 单独解决。**
+2. **纯粹把问题写成“RTOS 优于 Linux”已经不足以覆盖真实系统问题。**
+3. **真正需要研究的是面向 AI 的实时控制基础系统，而不是单一软件层。**
+
+## 3. 挑战
+
+### 3.1 跨层因果交织
+
+人工智能目标负载的时间行为同时受到模型结构、量化方式、算子实现、运行时队列、驱动、芯片资源和操作系统机制影响。单一层面的解释无法完整说明系统实时性。
+
+### 3.2 感知与控制形成闭环
+
+一旦感知、规划、语音理解或推理链路进入控制闭环，推理延迟、链路抖动和异常输出都会直接影响执行效果，系统面对的是认知与控制的一体化问题。
+
+### 3.3 MCU 与 SoC 路线差异显著
+
+MCU 场景更偏向静态资源分配、工具链和芯片协同；SoC 场景更偏向 Linux / RTOS / Hypervisor 协同、统一内存竞争治理和异构设备协作。这两类问题不能被同一套表达简单覆盖。
+
+### 3.4 体系结构成为主要变量
+
+随着 NPU、GPU、DMA、统一内存、总线和缓存结构进入主舞台，问题已经从调度器、中断和线程同步扩展到嵌入式计算机体系结构层。
+
+### 3.5 产业叙事需要升级
+
+如果企业仍然只把自己定义为 RTOS 供应方，就很难完整解释人工智能进入实时控制系统后出现的新问题。更有延展性的定位应当围绕“基础系统”展开。
+
+## 4. 本框架的价值
+
+本框架的目标不是否定 RTOS，而是把 RTOS 放回更准确的位置：
+
+- RTOS 是关键保障负载的确定性底座；
+- Linux 与推理运行时承载 AI 生态与计算任务；
+- Hypervisor、芯片与资源治理结构承担隔离、边界与整体秩序；
+- 规则层与兜底机制承担异常控制与安全边界。
+
+因此，本框架对应的研究价值在于：为“人工智能进入实时控制系统之后的基础系统问题”建立更准确的问题定义、技术路线和实验组织方式。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/00-总课题总览/02-研究定位与项目边界.md

@@ -0,0 +1,80 @@
+# 研究定位与项目边界
+
+## 1. 研究定位
+
+本框架的研究定位是：
+
+> **面向人工智能能力进入实时控制系统后的整体系统问题，研究基础系统如何维持确定性、可预测性与实时边界。**
+
+这里的“基础系统”不是单一软件层，而是由以下部分共同构成：
+
+- 模型与任务语义；
+- 推理运行时与负载编排；
+- RTOS 与 Linux 的角色分工；
+- Hypervisor 与资源隔离；
+- 芯片、总线、内存、NPU、GPU、DMA 等硬件资源结构；
+- 规则兜底、安全约束与异常切换机制。
+
+## 2. 研究对象
+
+本框架的研究对象是：
+
+> **面向 AI 的实时控制基础系统。**
+
+其中：
+
+- `SylixOS` 仍然可以作为关键实验样例与基础软件样本；
+- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可继续作为参照平台；
+- `Linux` 与 `PREEMPT_RT Linux` 继续作为重要对照对象；
+- `T5~T1` 继续作为验证矩阵，而不是研究主语。
+
+## 3. 本框架不把什么当作研究主语
+
+### 3.1 不把硬件谱系当作研究主语
+
+`T5~T1` 五类部署形态和各类算力基础承担的是验证矩阵角色，用于组织证据、比较边界和解释场景差异。
+
+### 3.2 不把单一 RTOS 当作全部因果承担者
+
+RTOS 在本框架中承担关键作用，但不再被写成全部实时问题的唯一解决者。模型、运行时、芯片与资源结构同样影响系统边界。
+
+### 3.3 不把纯吞吐优化当作核心目标
+
+本框架关注的是人工智能目标负载、关键保障负载与系统协同三层指标同时成立的条件，而不是单一的吞吐最大化。
+
+## 4. 研究边界
+
+### 4.1 重点覆盖的系统类型
+
+- 控制端 MCU / 控制盒；
+- 设备端 SoC；
+- 边缘节点；
+- 面向任务关键场景的单机高密和集群协同平台。
+
+### 4.2 重点覆盖的问题
+
+- 关键保障负载与人工智能目标负载共存时的整体实时性；
+- Linux / RTOS / Hypervisor 的混合协同结构；
+- 统一内存、总线和异构协处理器竞争治理；
+- 小型化、低功耗和受限部署条件下的系统边界；
+- 模型推理与规则兜底共同构成的执行闭环。
+
+### 4.3 暂不作为主线的问题
+
+- 通用大模型训练集群的纯吞吐优化；
+- 面向互联网高并发服务的开放式推理平台；
+- 单纯以算法精度提升为主的模型研究；
+- 不涉及实时控制闭环的普通桌面 AI 应用。
+
+## 5. 与项目框架1的关系
+
+项目框架1把“大型跨平台 RTOS”作为研究主语，重点讨论 RTOS 在五类部署形态中的机制优势。
+
+项目框架2则把研究主语上移到“面向 AI 的实时控制基础系统”，重点讨论：
+
+- RTOS 在整个系统中的位置；
+- Linux、RTOS 与 Hypervisor 如何协同；
+- 模型推理、资源竞争与控制任务如何共同构成实时边界；
+- 企业与平台如何从 RTOS 供应方转向基础系统供应方。
+
+这两套框架可以并行维护，分别服务于不同层次的课题收敛。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/00-总课题总览/03-总课题与两个子课题的关系.md

@@ -0,0 +1,86 @@
+# 总课题与两个子课题的关系
+
+## 1. 决策记录
+
+在对 2026-09-22 会议内容、框架2当前结构和外部相关研究进行综合判断后，当前对框架2的组织方式做出如下决策：
+
+> **框架2继续保留为“面向 AI 的实时控制基础系统研究”这一总课题，不单独再分出框架3；但在框架2内部，明确提升为“一总课题 + 两个子课题 + 一个共享方法层”的结构。**
+
+这一决策的核心依据是：
+
+1. `MCU` 路线与 `边侧 SoC` 路线已经不是同一种技术问题；
+2. 但两条路线仍然服务于同一个更高层研究主语，即“面向 AI 的实时控制基础系统”；
+3. 三层边界、验证矩阵、评价框架和对照逻辑仍然具有共享性；
+4. 目录层级上如果不把两个子课题抬成一级目录，就会削弱其独立研究价值。
+
+## 2. 总课题是什么
+
+总课题回答的是：
+
+> **人工智能能力进入实时控制系统之后，基础系统如何维持系统的确定性、可预测性与整体实时边界。**
+
+这一层负责统一以下内容：
+
+- 研究主语；
+- 问题定义；
+- 三层边界；
+- 验证矩阵；
+- 对照方法；
+- 总体评价框架；
+- 总体论文和课题表达。
+
+## 3. 为什么需要两个子课题
+
+### 3.1 子课题 A：面向 MCU 的静态智能控制基础系统
+
+这一子课题主要回答：
+
+- 极小资源预算下，人工智能能力如何被静态、可分析地纳入控制系统；
+- 小模型、小算子、工具链、代码生成与芯片协同如何共同形成系统能力；
+- 低功耗、小型化与极小内存预算如何构成主边界。
+
+### 3.2 子课题 B：面向边侧 SoC 的混合实时控制基础系统
+
+这一子课题主要回答：
+
+- Linux、RTOS、Hypervisor 与 Hybrid 结构如何在同一 SoC 上协同；
+- 统一内存、总线、DMA、NPU/GPU 竞争如何被治理；
+- 控制链路、推理链路与规则兜底如何共同形成整体边界。
+
+## 4. 为什么不现在直接分出框架3
+
+当前不单独再分出框架3，主要基于三点考虑：
+
+1. **研究主语没有分裂**  
+   两个子课题仍然隶属于同一个总课题主语。
+2. **方法层高度共享**  
+   三层边界、验证矩阵和评价框架不需要重复建设。
+3. **当前阶段更适合内部分流，而不是外部分家**  
+   目前仍处于课题框架优选和收敛阶段，过早拆出框架3会增加主线分散的风险。
+
+## 5. 当前目录组织原则
+
+因此，框架2当前采用以下结构：
+
+- `00-总课题总览`
+- `10-共享理论与方法层`
+- `20-子课题A-面向MCU的静态智能控制基础系统`
+- `30-子课题B-面向边侧SoC的混合实时控制基础系统`
+- `40-综合比较与收敛`
+
+这种结构同时满足：
+
+- 总课题不散；
+- 子课题不被湮灭；
+- 后续可以继续长成独立课题；
+- 当前仍可维持统一的研究主线。
+
+## 6. 后续演化条件
+
+只有在以下条件进一步成立时，才考虑把子课题继续外扩为独立框架或独立申报方向：
+
+1. 两个子课题分别对应不同合作方、不同交付物和不同对外课题口径；
+2. 两个子课题形成了不再共享的方法层和评价体系；
+3. 论文、实验和合作推进已经自然分化为两套完整闭环。
+
+在此之前，框架2保持“一总两子”的结构是当前最稳的组织方式。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/00-整体研究框架.md

@@ -0,0 +1,238 @@
+# 面向AI的实时控制基础系统整体研究框架
+
+## 0. 核心问题
+
+本框架围绕“人工智能能力进入实时控制系统之后，基础系统如何维持整体实时边界”展开。核心判断是：
+
+> **当人工智能目标负载进入实时控制系统后，系统需要解决的已经不是单一操作系统问题，而是模型、运行时、RTOS、Linux、Hypervisor、芯片、总线、内存、NPU、GPU、DMA 和规则兜底机制共同构成的整体实时性问题。`SylixOS` 可作为关键实验样例，`QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为参照平台。**
+
+这里有四个基础判断：
+
+1. **研究对象是面向 AI 的实时控制基础系统**；
+2. **人工智能推理在系统中承担目标负载角色**；
+3. **RTOS 是关键底座，但不是全部因果的唯一承担者**；
+4. **硬件条件以验证矩阵形式组织研究证据。**
+
+本框架评估的是：当人工智能目标负载与关键保障负载共同进入系统时，基础系统如何维持控制路径、推理路径和资源路径的整体边界。
+
+---
+
+## 1. 问题空间：五类部署形态、三类系统负载与跨层实时性
+
+### 1.1 五类部署形态
+
+`T5~T1` 五类部署形态继续作为验证矩阵。
+
+| 部署形态 | 系统角色 | 主要研究关注点 |
+|---|---|---|
+| T5 控制端 | 极紧资源预算下的控制节点 | 静态分配、低功耗、极小内存预算 |
+| T4 设备端 SoC | 设备本体内的异构平台 | Linux/RTOS 协同、统一内存与带宽隔离 |
+| T3 边缘节点 | 近源推理与控制协同节点 | 多任务并发、热稳定性、边缘协同 |
+| T2 单机工作站 | 单机高密本地推理平台 | 多卡公平性、控制侧保护与资源协同 |
+| T1 服务器 / 集群 | 任务关键场景中的分布式协同平台 | 跨节点协同、系统边界与规模扩展 |
+
+这些部署形态回答的是“在哪里验证”，而不是“什么是研究主语”。
+
+### 1.2 三类系统负载
+
+| 负载类型 | 定义 | 典型例子 |
+|---|---|---|
+| 人工智能目标负载 | 系统要完成的智能功能本身 | LLM 推理、视觉识别、导航规划、故障诊断 |
+| 关键保障负载 | 维持安全与执行闭环的关键任务 | 周期控制、联锁、状态采集、执行输出 |
+| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、模型加载、通信、I/O |
+
+### 1.3 跨层实时性问题
+
+本框架中的“实时性”不再只指调度器和中断路径，而是至少同时涉及：
+
+- 模型与推理阶段时间行为；
+- 运行时与队列组织；
+- RTOS 的关键任务保障能力；
+- Linux 的生态与推理承载能力；
+- Hypervisor 的隔离与资源切分；
+- 总线、内存、DMA、NPU、GPU 等资源竞争结构；
+- 规则兜底与异常切换机制。
+
+---
+
+## 2. 分层边界：三层系统问题
+
+### 2.1 RTOS 直接控制域
+
+这一层是 RTOS 可以直接施加机制约束的部分，包括：
+
+- 关键任务调度；
+- 中断优先级与抢占关系；
+- CPU 侧线程、同步与时钟机制；
+- 恢复、隔离和关键路径治理。
+
+这一层回答的是：
+
+> **RTOS 如何为关键保障负载建立确定性底座。**
+
+### 2.2 推理运行域
+
+这一层主要由模型、量化、算子、运行时和驱动共同决定，包括：
+
+- Prefill / Decode 时延结构；
+- 模型大小与量化精度；
+- KV Cache、内存组织与队列行为；
+- GPU/NPU 内部执行与框架调度。
+
+这一层回答的是：
+
+> **人工智能目标负载本身具有什么样的时间行为和资源行为。**
+
+### 2.3 系统协同域
+
+这一层是本框架的重点，包括：
+
+- Linux 与 RTOS 的角色分工；
+- Hypervisor 的隔离与资源划分；
+- 总线、DMA、外存、统一内存与协处理器竞争治理；
+- 规则兜底、安全约束与异常切换；
+- 关键保障负载与人工智能目标负载之间的优先级关系。
+
+这一层回答的是：
+
+> **在混合系统中，整体实时性如何被建立、维持和验证。**
+
+---
+
+## 3. 两条主要技术路线
+
+### 3.1 MCU 路线：静态分配、工具链与芯片协同
+
+MCU 路线重点关注：
+
+- 小模型、小算子与控制任务的静态编排；
+- 工具链、代码生成与开发套件；
+- 与芯片厂商的协同设计；
+- 极小资源预算下的 AI 目标负载纳入方式。
+
+这条路线的关键词是：
+
+`静态分配`、`工具链`、`开发套件`、`芯片协同`
+
+### 3.2 SoC 路线：Hybrid、Hypervisor 与整体确定性
+
+SoC 路线重点关注：
+
+- Linux 侧推理与 RTOS 侧控制的分工；
+- Hybrid 结构从“并置”升级为“协同治理”；
+- Hypervisor 的隔离、分簇和资源切分；
+- 统一内存、总线、DMA、NPU/GPU 竞争治理；
+- 控制与 AI 在同一系统中的整体确定性。
+
+这条路线的关键词是：
+
+`Hybrid`、`Hypervisor`、`隔离`、`资源治理`、`系统确定性`
+
+---
+
+## 4. 统一技术体系：五层技术栈与横向治理线
+
+本框架继续保留五层技术栈表达，但其含义从“RTOS 机制展开”进一步上升为“基础系统展开”。
+
+```
+┌───────────────────────────────────────────────────────────────┐
+│ L5 模型与任务语义层                                            │
+│ 任务语义、模型结构、量化、输出约束、业务边界                    │
+├───────────────────────────────────────────────────────────────┤
+│ L4 运行时与负载编排层                                           │
+│ 队列、准入控制、内存池、流水线、推理框架、规则兜底接口          │
+├───────────────────────────────────────────────────────────────┤
+│ L3 资源抽象与系统协同层                                         │
+│ CPU/NPU/GPU/DMA/总线/统一内存抽象、Hypervisor、资源治理        │
+├───────────────────────────────────────────────────────────────┤
+│ L2 基础软件控制层                                               │
+│ RTOS、Linux、中断、调度、同步、恢复、隔离、关键路径保护         │
+├───────────────────────────────────────────────────────────────┤
+│ L1 硬件与互联层                                                 │
+│ MCU、SoC、加速器、缓存、总线、外存、网络互联、时钟源            │
+└───────────────────────────────────────────────────────────────┘
+```
+
+横向治理线包括：安全、审计、配置版本、日志证据、时间同步、可观测性、规则兜底、异常切换和 OTA / 回滚能力。
+
+---
+
+## 5. 研究主线：整体实时边界的建立与验证
+
+本框架后续所有子方向都服务于同一个主命题：
+
+> **面向 AI 的实时控制基础系统如何在人工智能目标负载进入控制闭环后，维持系统的确定性、可预测性与整体实时边界。**
+
+围绕这个主命题，研究主线可以组织为六个方向：
+
+1. **RTOS 直接控制域的保障机制**
+2. **人工智能目标负载的时间行为建模**
+3. **系统协同域的资源隔离与治理**
+4. **MCU 路线的静态编排与工具链能力**
+5. **SoC 路线的 Hybrid / Hypervisor 协同结构**
+6. **规则兜底、异常切换与闭环安全边界**
+
+这些方向共同服务于一个判断：
+
+> **人工智能能力进入实时控制系统后，系统是否仍然有边界，以及这个边界由哪些机制共同构成。**
+
+---
+
+## 6. 评价框架：三层指标同时成立
+
+### 6.1 人工智能目标负载指标
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性
+- 长时间稳定性
+
+### 6.2 关键保障负载指标
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 6.3 系统协同指标
+
+- 有效吞吐
+- `E/token` / `tokens/J`
+- 温度、热漂移与降频行为
+- 资源隔离效果
+- 恢复能力与异常切换表现
+
+因此，本框架的成功标准是：
+
+> **人工智能目标负载、关键保障负载与系统协同三层指标同时成立。**
+
+---
+
+## 7. 对照关系：Linux、PREEMPT_RT、RTOS 与混合结构
+
+后续实验与叙事可采用四类对照：
+
+| 对照组 | 含义 | 作用 |
+|---|---|---|
+| `O0` 普通 Linux | 通用系统基线 | 观察非实时平台的自然行为 |
+| `O1` PREEMPT_RT Linux | 实时增强型 Linux | 观察增强型通用 OS 的边界 |
+| `O2` RTOS 原生配置 | RTOS 基础路径 | 观察 RTOS 底座能力 |
+| `O3` 混合基础系统配置 | Linux + RTOS + Hypervisor 或协同结构 | 观察整体协同路径的收益与代价 |
+
+这条对照线的重点，不再只是比较“谁更快”，而是比较：
+
+- 谁更能维持关键保障负载边界；
+- 谁更能承受 AI 目标负载进入后的资源竞争；
+- 谁更能形成可解释、可复现、可治理的整体系统秩序。
+
+---
+
+## 8. 预期成果
+
+1. **问题定义层**：人工智能能力进入实时控制系统后的基础系统问题定义；
+2. **分析层**：RTOS 直接控制域、推理运行域与系统协同域的边界划分方法；
+3. **机制层**：面向 Hybrid / Hypervisor / 资源治理 / 规则兜底的基础系统机制；
+4. **方法层**：覆盖 `T5~T1` 的统一验证矩阵与对照方法；
+5. **产业层**：从 RTOS 平台叙事上升到基础系统叙事的合作与产品路线；
+6. **论文层**：面向实时系统、嵌入式系统和低功耗系统方向的系统化论文与报告。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/01-RTOS直接控制域.md

@@ -0,0 +1,90 @@
+# RTOS直接控制域
+
+## 1. 主题定位
+
+在框架2中，RTOS 不再被写成全部系统问题的唯一承担者，但它仍然是关键保障负载确定性底座的核心组成部分。本文件用于明确：哪些问题属于 RTOS 可以直接控制和分析的范围，哪些问题不应继续归因到 RTOS 身上。
+
+## 2. 直接控制域的边界
+
+RTOS 直接控制域主要包括：
+
+- 周期任务、关键任务与后台任务的调度关系；
+- 中断优先级、抢占路径和线程化中断机制；
+- CPU 侧线程、同步互斥、时钟与定时器；
+- 内存锁定、关键缓冲区预分配与恢复机制；
+- 关键任务隔离、核心绑定和关键路径保护；
+- 对共享资源治理接口的直接约束能力。
+
+这一层回答的是：
+
+> **RTOS 如何在人工智能目标负载进入系统后，持续保护关键保障负载的时间边界。**
+
+## 3. 核心研究问题
+
+### 3.1 关键任务如何不被人工智能目标负载拖垮
+
+当人工智能目标负载与关键保障负载并存时，RTOS 的首要任务不是提高模型吞吐，而是确保：
+
+- 周期控制任务不失去截止期；
+- 中断链路不被模型加载、日志、I/O 和推理提交路径污染；
+- 恢复路径在异常条件下仍然可触发；
+- 控制输出始终保留优先权。
+
+### 3.2 哪些资源竞争能够由 RTOS 直接治理
+
+RTOS 可以直接治理的通常是：
+
+- CPU 时间分配；
+- 抢占关系；
+- 中断响应顺序；
+- 同步冲突；
+- 关键路径上的内核对象与内存使用方式。
+
+RTOS 不能单独决定的，则包括 GPU/NPU 内部算子执行、显存流水线、驱动内部队列与片上总线物理冲突。这些内容必须和系统协同域一起讨论。
+
+## 4. 关键机制
+
+### 4.1 调度与抢占
+
+关键保障负载应继续保持硬优先级或等价的刚性优先级结构。人工智能目标负载相关线程、提交路径和后台服务线程必须被限制在不会破坏关键任务的优先级层次中。
+
+### 4.2 中断与关键路径治理
+
+模型加载、设备中断、网络和存储路径都可能拉长关键路径。后续研究应重点观察：
+
+- 哪些中断必须线程化；
+- 哪些中断应固定到非关键核；
+- 哪些设备中断会污染关键任务核；
+- 推理提交和结果回收链路是否会引发优先级倒置。
+
+### 4.3 恢复与隔离
+
+当推理链路失稳、超时或内存耗尽时，RTOS 直接控制域需要承担：
+
+- 关键任务不受波及的隔离；
+- 降级模式触发；
+- 任务重启与恢复；
+- 对控制回路的兜底保持。
+
+## 5. 评价重点
+
+这一层的核心指标包括：
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+- 恢复时间与异常切换开销
+
+这些指标构成 RTOS 直接控制域的主证据，不应和 GPU/NPU 内部执行指标混为一体。
+
+## 6. 与其他层的关系
+
+- 与 `推理运行域` 的关系：RTOS 负责保护关键路径，推理运行域负责描述 AI 目标负载本身的时间行为；
+- 与 `系统协同域` 的关系：RTOS 负责可直接治理的部分，系统协同域负责 Linux、Hypervisor 和异构资源共同造成的整体边界问题。
+
+## 7. 当前结论
+
+框架2并没有削弱 RTOS 的价值，而是把 RTOS 的价值说得更准确：
+
+> **RTOS 是关键保障负载的确定性底座，是人工智能进入实时控制系统后仍能维持秩序的直接控制层。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/02-推理运行域.md

@@ -0,0 +1,85 @@
+# 推理运行域
+
+## 1. 主题定位
+
+推理运行域用于解释人工智能目标负载本身的时间行为、资源行为和优化空间。框架2强调，大模型与智能算法的实时问题不能完全归因到 RTOS 身上，原因就在于推理运行域本身已经带有很强的结构性时间特征。
+
+## 2. 推理运行域包含什么
+
+这一层主要包括：
+
+- 模型结构与参数规模；
+- 量化方式与数值精度；
+- Prefill / Decode 两阶段时间特征；
+- KV Cache 生命周期与内存组织；
+- 推理框架队列、批处理与上下文管理；
+- 算子实现、驱动路径和设备执行接口。
+
+这一层回答的是：
+
+> **人工智能目标负载本身具有什么样的时间行为、内存行为和资源竞争特征。**
+
+## 3. 为什么这一层不能被省略
+
+如果把所有实时性问题都写成 RTOS 问题，就会忽略以下事实：
+
+- 不同模型大小对内存和时延的影响完全不同；
+- 量化方式会显著改变推理峰值、稳定性和能效；
+- 同一硬件上，不同框架和不同算子组合会带来巨大差异；
+- Decode 阶段与 Prefill 阶段的时间结构并不相同；
+- 推理框架内部队列策略会直接影响首响应时间与尾延迟。
+
+因此，推理运行域必须被单独分析。
+
+## 4. 核心研究问题
+
+### 4.1 模型时间行为如何进入系统分析
+
+后续研究需要回答：
+
+- 不同模型在 Prefill 与 Decode 阶段分别造成什么样的时间分布；
+- 哪些阶段是延迟敏感的；
+- 哪些阶段可以延后、限流或降级；
+- 哪些阶段会对关键保障负载形成直接冲击。
+
+### 4.2 内存与缓存如何形成主瓶颈
+
+对于设备端 SoC 和边缘节点，KV Cache、统一内存与 DMA 搬运常常比算力本身更早成为主瓶颈。  
+因此，这一层需要重点分析：
+
+- 权重、KV Cache、工作区和运行时缓冲的占用边界；
+- 模型切换、上下文增长和并发请求如何改变内存行为；
+- 哪些内存组织方式更适合和关键保障负载并存。
+
+### 4.3 量化与算子如何影响实时边界
+
+量化和算子优化不仅影响吞吐，还影响：
+
+- 首响应时延；
+- 长稳阶段的功耗与热状态；
+- 设备端资源占用；
+- 能否在受限部署条件下持续运行。
+
+## 5. 评价重点
+
+这一层的核心指标包括：
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性与任务完成率
+- 峰值内存、工作区与长稳退化
+- 单位任务能耗与热漂移
+
+这些指标构成 AI 目标负载本身的主证据。
+
+## 6. 与其他层的关系
+
+- 与 `RTOS 直接控制域` 的关系：推理运行域描述 AI 目标负载自身行为，RTOS 控制域负责保护关键任务不被这些行为拖垮；
+- 与 `系统协同域` 的关系：推理运行域给出负载输入，系统协同域回答这些负载如何与 Linux、Hypervisor 和异构资源共同形成整体边界。
+
+## 7. 当前结论
+
+框架2保留 RTOS 的重要性，但明确要求把推理运行域单独提出，是因为：
+
+> **只有先把人工智能目标负载本身的时间结构说清楚，后续系统边界分析才不会落回单因果叙事。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/03-系统协同域.md

@@ -0,0 +1,107 @@
+# 系统协同域
+
+## 1. 主题定位
+
+系统协同域是框架2相对框架1最大的变化之一。它不再把问题停留在“RTOS 是否更强”，而是直接讨论：当 Linux、RTOS、Hypervisor、统一内存、总线、DMA、NPU、GPU 和规则兜底机制共同存在时，整体实时性如何被建立、维持和验证。
+
+## 2. 为什么系统协同域是主问题
+
+会议中最关键的判断之一是：人工智能进入实时控制系统后的真实问题，已经超出了单一操作系统边界。原因在于：
+
+- 推理生态通常离不开 Linux；
+- 关键保障负载需要 RTOS 或等价实时控制底座；
+- 设备端 SoC 常常采用统一内存和异构协处理器；
+- Hypervisor 与隔离机制直接影响资源边界；
+- 规则兜底与安全约束必须与模型输出共同工作。
+
+因此，系统协同域回答的是：
+
+> **在混合结构中，整体秩序如何形成。**
+
+## 3. 核心问题
+
+### 3.1 Linux 与 RTOS 如何分工
+
+Linux 更适合承担：
+
+- 推理框架与模型生态；
+- 容器、服务和工具链支持；
+- 非关键路径的 AI 相关运行任务。
+
+RTOS 更适合承担：
+
+- 关键保障负载；
+- 控制闭环中的刚性时间边界；
+- 关键路径上的确定性治理。
+
+系统协同域的核心，不是让两者彼此替代，而是让两者分工清楚、边界稳定。
+
+### 3.2 Hypervisor 在这里起什么作用
+
+Hypervisor 不是附属选项，而是重要研究对象之一。它至少影响：
+
+- 核心隔离和资源切分；
+- 中断路由和设备访问边界；
+- 共享内存与通信路径；
+- 异常传播与恢复策略。
+
+在设备端 SoC 和边缘节点上，Hypervisor 往往是把“共存”升级为“可治理共存”的关键层。
+
+### 3.3 异构资源竞争如何进入系统分析
+
+在 SoC 和边缘节点上，整体边界往往由以下竞争共同决定：
+
+- CPU 与 NPU/GPU 的统一内存争用；
+- DMA 与 CPU 访存冲突；
+- 总线与缓存竞争；
+- 模型加载与控制 I/O 共享带宽；
+- 后台服务与关键任务共享中断和核资源。
+
+这些问题不能只在驱动层或 RTOS 层单独解释，必须进入系统协同域。
+
+## 4. 关键机制
+
+### 4.1 资源隔离
+
+后续研究应重点观察：
+
+- CPU 核和关键任务核是否可隔离；
+- 设备中断是否可隔离；
+- 共享内存和 DMA 缓冲是否可限定边界；
+- 模型提交路径是否会挤占控制路径资源。
+
+### 4.2 协同治理
+
+协同治理关注的是：
+
+- 推理与控制如何分层；
+- 哪些事件由 Linux 负责，哪些由 RTOS 负责；
+- 资源冲突发生时谁拥有优先权；
+- 发生过载和异常时系统如何降级与恢复。
+
+### 4.3 证据组织
+
+系统协同域的证据不能只看某一个线程或某一个服务，而需要同时观察：
+
+- 人工智能目标负载层；
+- 关键保障负载层；
+- 系统协同层。
+
+只有三层指标同时成立，才能说明协同结构是有效的。
+
+## 5. 对照方式
+
+框架2的主对照建议采用：
+
+- `O0` 普通 Linux
+- `O1` PREEMPT_RT Linux
+- `O2` RTOS 原生配置
+- `O3` 混合基础系统配置
+
+其中 `O3` 不再只是附属架构，而是系统协同域的主实验路径之一。
+
+## 6. 当前结论
+
+框架2真正抬升的，不只是标题口径，而是研究主线本身：
+
+> **系统协同域使项目从“RTOS 机制研究”走向“人工智能进入实时控制系统后的基础系统研究”。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/04-规则兜底与控制闭环.md

@@ -0,0 +1,80 @@
+# 规则兜底与控制闭环
+
+## 1. 主题定位
+
+人工智能能力进入实时控制系统后，系统不可能只靠模型输出维持闭环。框架2因此把“规则兜底与控制闭环”单独列为一条研究线，用来说明模型推理、控制逻辑、安全约束和异常切换如何共同维持系统边界。
+
+## 2. 为什么必须单独提出这一层
+
+如果只讨论模型推理和操作系统，容易忽略一个关键事实：
+
+- 模型输出可能延迟；
+- 模型输出可能不稳定；
+- 模型输出可能不满足控制安全边界；
+- 系统必须在异常条件下退回到规则与安全约束支撑的路径。
+
+因此，真实系统需要的是“模型驱动 + 规则兜底”的混合闭环。
+
+## 3. 核心研究问题
+
+### 3.1 模型与规则如何分工
+
+模型更适合承担：
+
+- 感知理解；
+- 语义识别；
+- 规划建议；
+- 异常模式发现。
+
+规则层更适合承担：
+
+- 安全边界检查；
+- 优先级裁决；
+- 异常降级；
+- 默认动作触发；
+- 恢复条件判定。
+
+### 3.2 闭环如何建立
+
+框架2中的闭环至少包括：
+
+1. 感知输入；
+2. 推理与规划；
+3. 规则检查；
+4. 执行输出；
+5. 状态回读；
+6. 异常切换与恢复。
+
+只有这条链路完整，系统才是真正的实时控制系统，而不是带 AI 的普通服务系统。
+
+### 3.3 异常切换如何进入系统实验
+
+后续实验不仅要测正常场景，还要测：
+
+- 模型超时；
+- 队列过载；
+- 设备异常；
+- 推理链路中断；
+- 控制路径回退。
+
+这些内容构成规则兜底层的核心证据。
+
+## 4. 评价重点
+
+这一层重点观察：
+
+- 异常切换时间；
+- 规则触发正确性；
+- 降级后的关键任务保持情况；
+- 恢复后的系统稳定性；
+- 模型与规则共同工作时的整体边界。
+
+## 5. 与其他层的关系
+
+- 与 `RTOS 直接控制域` 的关系：RTOS 负责底层调度与恢复执行；
+- 与 `推理运行域` 的关系：模型提供感知和规划能力；
+- 与 `系统协同域` 的关系：规则兜底把混合系统真正闭合成可执行的控制系统。
+
+## 6. 当前结论
+
+> **没有规则兜底与异常切换，人工智能进入实时控制系统就只是“把模型接进来了”；只有闭环建立起来，基础系统课题才真正成立。**

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

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

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/10-共享理论与方法层/06-基础设备与算力基础.md

@@ -0,0 +1,100 @@
+# 面向AI的实时控制基础系统基础设备与算力基础
+
+## 1. 文档目的
+
+本文用于说明框架2中的验证矩阵如何组织。这里继续保留 `T5~T1` 五类部署形态，但其作用是“验证矩阵”，不是研究主语。本文件同时把 `MCU 路线` 与 `SoC 路线` 显式放进设备与算力组织逻辑中。
+
+## 2. 验证矩阵的组织原则
+
+### 2.1 三条组织原则
+
+1. **部署形态优先于硬件型号**  
+   先回答系统在什么位置运行，再回答用什么设备验证。
+2. **技术路线优先于单点性能**  
+   先区分 MCU 路线与 SoC 路线，再讨论容量、功耗和算力差异。
+3. **基础系统问题优先于纯吞吐问题**  
+   优先选择能暴露控制路径、推理路径与资源竞争关系的设备与场景。
+
+### 2.2 五类部署形态
+
+| 部署形态 | 系统角色 | 主要关注点 |
+|---|---|---|
+| `T5` 控制端 | 极紧资源预算下的控制节点 | 静态编排、低功耗、极小内存 |
+| `T4` 设备端 SoC | 设备本体内的异构平台 | Linux/RTOS/Hypervisor 协同、统一内存竞争 |
+| `T3` 边缘节点 | 设备附近的近源协同节点 | 多任务并发、热稳定性、边缘协同 |
+| `T2` 单机工作站 | 单机高密本地推理平台 | 多卡公平性、关键任务保护与系统协同 |
+| `T1` 服务器 / 集群 | 任务关键场景中的分布式协同平台 | 跨节点边界、编排与规模扩展 |
+
+## 3. 两条技术路线在矩阵中的位置
+
+### 3.1 MCU 路线
+
+MCU 路线主要对应 `T5`，重点设备类型包括：
+
+- MCU 控制器；
+- 轻量控制盒；
+- 极小资源预算下的端侧控制节点。
+
+它承担的问题是：
+
+- 小模型与控制任务如何静态编排；
+- 芯片工具链和开发套件如何支撑部署；
+- 极小内存、功耗与外设约束下能否维持闭环。
+
+### 3.2 SoC 路线
+
+SoC 路线主要对应 `T4`，并向 `T3` 延伸。重点设备类型包括：
+
+- 工业 SoC；
+- 车规 SoC；
+- 设备端 AI 模组；
+- 边缘异构平台。
+
+它承担的问题是：
+
+- Linux 与 RTOS 的协同关系；
+- Hypervisor 的隔离与资源切分；
+- 统一内存、DMA、总线与 NPU/GPU 竞争；
+- 设备级功耗、散热与体积约束下的整体确定性。
+
+## 4. 当前设备锚点
+
+### 4.1 已有核心平台
+
+| 平台 | 对应位置 | 当前价值 |
+|---|---|---|
+| RK3588 16 GB | `T4-L` / 受限配置可模拟 `T5-H` | 设备端 SoC 主样例；同时可承接小型化与低功耗观察 |
+| 4×V100 服务器 | `T2-L` | 单机高密推理与关键保障负载保护的对照窗口 |
+
+### 4.2 条件扩展平台
+
+| 平台方向 | 对应位置 | 主要价值 |
+|---|---|---|
+| RK3568 / 同类控制盒 | `T5-L` | MCU / 轻量控制路线主验证窗口 |
+| RK3576 / 同类设备 | `T5-M` 或 `T4-L` 衔接档 | 中间资源档位与工具链观察窗口 |
+| Jetson / IGX / 工控边缘节点 | `T3` / `T4-M` | SoC 向边缘协同扩展的窗口 |
+| 更高端单机多卡或多节点平台 | `T2-H` / `T1` | 观察规模扩展和协同边界收窄区间 |
+
+## 5. 为什么框架2仍然保留 `T2/T1`
+
+框架2并不把 `T2/T1` 当作 RTOS 优势的天然主战场，但仍保留其验证价值：
+
+- 它们可以暴露 AI 目标负载的运行时复杂性；
+- 它们可以观察关键保障负载在高密度 AI 负载下是否仍可被保护；
+- 它们可以为系统协同域提供资源竞争、队列行为和规模边界证据。
+
+因此，`T2/T1` 在框架2中的角色更接近“上界参照窗口”，而不是研究主语。
+
+## 6. 当前建议
+
+对框架2而言，最值得优先强化的设备与算力主线是：
+
+1. **`T5` MCU / 控制端路线**
+2. **`T4` 设备端 SoC 路线**
+3. **`T3` 边缘协同路线**
+
+这三类场景最能体现“基础系统主语”与“系统协同边界”。
+
+## 7. 当前结论
+
+> **框架2中的设备与算力组织方式，不是为了堆出更大的硬件谱系，而是为了在不同资源条件下，把 MCU 路线与 SoC 路线的基础系统问题显式暴露出来。**

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

@@ -0,0 +1,31 @@
+# 共享理论与方法层
+
+本目录用于承载框架2中由总课题统一维护、并由两个子课题共同共享的理论和方法内容。
+
+## 本层内容
+
+1. [00-整体研究框架.md](./00-整体研究框架.md)
+2. [01-RTOS直接控制域.md](./01-RTOS直接控制域.md)
+3. [02-推理运行域.md](./02-推理运行域.md)
+4. [03-系统协同域.md](./03-系统协同域.md)
+5. [04-规则兜底与控制闭环.md](./04-规则兜底与控制闭环.md)
+6. [05-研究逻辑说明.md](./05-研究逻辑说明.md)
+7. [06-基础设备与算力基础.md](./06-基础设备与算力基础.md)
+
+## 本层作用
+
+这一层统一负责：
+
+- 研究主语与问题定义；
+- 三层边界；
+- 统一验证矩阵；
+- 统一评价框架；
+- 统一对照逻辑；
+- 总体方法论表达。
+
+## 与两个子课题的关系
+
+- 子课题 A 重点继承其中与 `MCU`、静态编排、低功耗和工具链相关的部分；
+- 子课题 B 重点继承其中与 `Linux/RTOS/Hypervisor`、资源隔离和系统协同相关的部分。
+
+这意味着两个子课题虽然分别展开，但不需要各自重复建设方法层。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/00-子课题定义.md

@@ -0,0 +1,84 @@
+# 子课题定义
+
+## 1. 建议名称
+
+正式名称：
+
+> **面向 MCU 的静态智能控制基础系统研究**
+
+当前工程阶段名称：
+
+> **基于 SylixOS 与控制端 SoC 的静态智能任务编排、准入与闭环保障研究**
+
+两个名称分别解决不同问题：正式名称保持长期研究方向，工程阶段名称准确反映当前拥有 RK3588、4×V100，而尚缺真正 MCU 实验板的设备现实。
+
+## 2. 核心研究问题
+
+本子课题研究：
+
+> 在控制任务的时间、内存、功耗和安全边界必须优先满足的条件下，如何把轻量智能模型转换为具有固定资源上限、固定执行窗口、明确异常处理方式的 SylixOS 实时任务，并通过工具链在部署前完成可行性判定。
+
+研究对象不是某一个模型，也不是单纯的模型压缩，而是由以下部分构成的静态智能控制基础系统：
+
+1. 控制任务与安全规则；
+2. 小模型与有限算子集合；
+3. 离线资源分析与联合编排器；
+4. 静态内存、固定优先级和固定推理窗口；
+5. SylixOS BSP、内核机制和 RealEvo 工程链路；
+6. 超时、拒绝、降级、恢复和部署准入机制。
+
+## 3. 项目现实基础
+
+| 现有条件 | 在本子课题中的作用 |
+|---|---|
+| RK3588 16 GB 工业盒 | 首个 SylixOS/控制端 SoC 方法原型平台 |
+| RK3588 8 GB 受限配置 | 验证预算收缩和部署准入，不冒充真实 MCU |
+| 4×V100 服务器 | 模型训练、量化校准、转换和参考精度平台 |
+| SylixOS / RealEvo | 实时任务、BSP、内存布局、编译部署与调试基础 |
+| RK3568 / RK3576 候选板 | 控制端资源收缩与跨 BSP 验证 |
+| 真正 MCU 平台 | 后续补充，用于形成严格 MCU 级结论 |
+
+## 4. 三阶段研究路线
+
+### 阶段A：方法原型
+
+在现有 RK3588 上打通控制任务描述、模型转换、静态 Tensor Arena、SylixOS 任务生成、固定优先级、超时与规则兜底以及部署准入报告。
+
+### 阶段B：控制端收缩
+
+在 RK3568、RK3576 或等价控制端平台上收紧内存、CPU时间、功耗、散热和启动预算，验证跨 BSP 可移植性。
+
+### 阶段C：真正 MCU 实证
+
+在确认 SylixOS lite/tiny、目标 BSP 和算子运行时可用后，验证 KB/MB 级 SRAM、片上 Flash、固定控制周期、快速启动和 `E/inference`。
+
+## 5. 研究边界
+
+本子课题重点覆盖：
+
+- 小模型、小算子与关键控制任务共存；
+- 离线编排、静态内存和部署前准入；
+- SylixOS上的调度、中断、内存、DMA和恢复；
+- 低功耗、快速启动和规则兜底；
+- 工具链、代码生成和芯片协同。
+
+本子课题不把以下内容作为主线：
+
+- 通用大语言模型在 MCU 上运行；
+- Linux 容器、复杂虚拟化和大规模服务编排；
+- 只追求平均吞吐的推理优化；
+- 用 RK3588 限额实验替代真正 MCU 结论；
+- 在驱动或 BSP 未准入时预设 NPU 已经可用。
+
+## 6. 与总课题的关系
+
+本子课题对应总课题的 `T5` 控制端路线，重点研究 RTOS 直接控制域与推理运行域如何在极端约束下闭合。其任务描述、资源准入、规则兜底和数据格式也可供子课题B复用。
+
+## 7. 成功判据
+
+1. 部署前能够预测内存、时间和功耗预算；
+2. 工具能够生成 SylixOS 工程所需代码和配置；
+3. AI加入后关键控制任务仍满足截止期；
+4. 超时、过载或模型异常时规则路径能够接管；
+5. 预测值与实测值存在可解释误差；
+6. 方法能够从 RK3588 迁移到更小控制端和真正 MCU。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/01-研究问题与适用场景.md

@@ -0,0 +1,77 @@
+# 研究问题与适用场景
+
+## 1. 总体问题
+
+本子课题不研究“MCU能运行多大的模型”，而研究：
+
+> 在控制任务优先、资源预算刚性和AI结果不完全可信的条件下，基础系统如何给智能任务建立可分析的资源边界、时间边界和安全边界。
+
+## 2. 核心研究问题
+
+| 编号 | 研究问题 | 主要证据 |
+|---|---|---|
+| RQ1 | 控制任务与模型如何离线联合编排 | 可调度性、控制截止期、固定推理窗口 |
+| RQ2 | 静态内存规划能否降低峰值和碎片风险 | 峰值内存、长期稳定性、部署成功率 |
+| RQ3 | 部署前预测能否接近目标板实测 | 时间、内存、功耗预测误差 |
+| RQ4 | 规则兜底能否限制AI故障传播 | 降级时间、控制保持率、恢复时间 |
+| RQ5 | 同一工具描述能否跨设备迁移 | RK3588、RK3568/3576、真正MCU之间的迁移代价 |
+
+## 3. 推荐主场景
+
+### 3.1 电机或泵类设备状态识别
+
+- 关键控制：1 ms级采样、控制计算和执行输出；
+- AI功能：振动、电流或温度窗口的异常分类；
+- AI周期：50～100 ms或事件触发；
+- 模型：INT8 1D CNN、小型MLP或决策树；
+- 兜底：AI超时或结果越界时继续规则控制并上报告警。
+
+这个场景适合首个实验，因为控制链路、AI链路和故障处理边界都清晰，且不要求AI直接进入硬实时内环。
+
+### 3.2 工业节点状态分类
+
+持续运行传感器采集与现场总线通信，AI负责工况分类、故障预警或参数建议，规则层负责范围校验和安全动作。该场景可以验证 CAN、RS485、GPIO、DMA 与推理之间的干扰。
+
+### 3.3 关键词或声学事件识别
+
+模型和输入窗口固定，适合验证算子分段、静态Arena和低占空比推理，但不建议把语音输出直接接入关键执行链路。
+
+### 3.4 轻量视觉检测或分类
+
+适合 RK3588/RK3568 方法原型，可研究摄像头DMA、内存带宽和NPU中断对控制任务的影响，但不宜作为真正 MCU 阶段的唯一场景。
+
+## 4. 不同设备上的场景分工
+
+| 平台 | 优先场景 | 研究重点 |
+|---|---|---|
+| 4×V100 | 模型训练、量化校准、参考精度 | 不进行MCU实时性结论 |
+| RK3588 16 GB | 电机状态、轻量视觉、控制与推理共存 | SylixOS集成、工具链闭环、干扰注入 |
+| RK3588 8 GB限额 | 同一工作负载的预算收缩 | 准入机制能否正确降级或拒绝 |
+| RK3568/RK3576 | 电机状态、关键词、工业节点 | 更小资源、低功耗、跨BSP迁移 |
+| 真正MCU | 1D CNN、MLP、关键词、状态分类 | SRAM/Flash极限、快速启动、E/inference |
+
+## 5. 负载结构
+
+所有场景统一拆成三类任务：
+
+1. **关键保障负载**：周期控制、采样、执行输出、联锁；
+2. **人工智能目标负载**：分类、检测、异常识别或参数建议；
+3. **伴生竞争负载**：日志、通信、存储、模型加载和后台诊断。
+
+AI任务必须满足：不阻塞控制内环、使用有界队列、输入过期可丢弃、结果经过规则检查、超时结果不再生效、故障时控制系统能够独立运行。
+
+## 6. 研究假设
+
+- H1：静态联合编排比普通后台部署更能维持控制任务的尾延迟和截止期；
+- H2：静态Arena与生命周期复用比动态堆具有更低、更稳定的峰值内存；
+- H3：基于目标板算子数据库的预测能够给出具有工程安全系数的执行上界；
+- H4：有界队列、超时和规则兜底能够把AI过载转化为可解释的拒绝或降级；
+- H5：统一描述格式能够降低从RK3588迁移到更小控制端的适配成本。
+
+## 7. 首期排除项
+
+- AI直接闭合1 ms硬实时控制环；
+- 动态Agent、多轮生成和开放式工具调用；
+- 无法固定输入、模型版本或任务质量标准的应用；
+- 无法获得BSP、驱动或时间戳的黑盒设备；
+- 仅通过降低任务完成率来获得更好实时性或能耗结果。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/00-总览与定位/README.md

@@ -0,0 +1,19 @@
+# 00-总览与定位
+
+本层回答“研究什么、为什么研究、用现有设备能证明什么”。
+
+## 文件
+
+1. [00-子课题定义.md](./00-子课题定义.md)：名称、研究对象、三阶段路线、边界和成功判据；
+2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md)：研究问题、假设、首个工业场景和设备分工。
+
+## 阅读结果
+
+读完本层应能够明确：
+
+- RK3588、RK3568/RK3576与真正MCU的区别；
+- 4×V100在项目中的辅助角色；
+- 为什么AI不直接进入1 ms硬实时内环；
+- 项目最终需要证明哪些研究假设。
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/00-总体技术路线.md

@@ -0,0 +1,171 @@
+# 技术路线：静态编排、工具链与芯片协同
+
+## 1. 总体架构
+
+本子课题采用“离线联合编排 + SylixOS有界运行时 + 规则兜底”的结构。
+
+```text
+模型与数据集               控制任务与安全规则
+     │                            │
+     ├──模型解析/量化             ├──周期/截止期/WCET
+     ├──算子图/张量生命周期       ├──中断/DMA/通信开销
+     └──质量阈值                  └──降级与恢复条件
+                 │          │
+                 └────┬─────┘
+                      ▼
+              离线联合编排器
+        内存规划/时间编排/准入判定
+                      │
+          ┌───────────┴───────────┐
+          ▼                       ▼
+     拒绝或降级建议        SylixOS工程产物
+                                  │
+                                  ▼
+              固定任务、静态内存、有界队列
+                                  │
+                                  ▼
+                   超时检测、规则兜底、恢复
+```
+
+## 2. 四层技术结构
+
+### 2.1 模型与算子层
+
+- 固定模型版本、输入尺寸和任务质量标准；
+- INT8等目标量化；
+- 有限算子集合；
+- 统计权重、Tensor Arena和工作区；
+- 建立目标板算子执行时间和能耗数据库。
+
+### 2.2 离线编排层
+
+- 分析控制任务周期、截止期、执行时间与干扰；
+- 规划静态内存和张量复用；
+- 选择完整推理窗口或算子分段窗口；
+- 计算响应时间和安全余量；
+- 输出 `PASS / PASS WITH LIMITS / REJECT`。
+
+### 2.3 SylixOS执行层
+
+- 固定优先级与周期释放；
+- 控制任务、AI任务和安全任务分级；
+- 任务核绑定与中断治理；
+- 静态区、固定Arena和DMA缓冲；
+- 高精度时间戳、看门狗和异常恢复。
+
+### 2.4 规则与闭环层
+
+- AI输出范围、状态机和置信度检查；
+- 超时或过载时丢弃过期结果；
+- 默认动作或规则控制接管；
+- 恢复前连续自检；
+- 保证控制内环不等待AI。
+
+## 3. 核心机制
+
+### 3.1 静态内存
+
+部署前计算：
+
+\[
+M_{AI}=M_{weights}+M_{arena}+M_{workspace}+M_{IO}+M_{stack}
+\]
+
+并保证：
+
+\[
+M_{AI}\leq M_{total}-M_{OS}-M_{control}-M_{comm}-M_{safety}
+\]
+
+运行阶段避免模型路径使用无界动态分配；权重、张量、DMA和控制缓冲分区管理。
+
+### 3.2 静态时间
+
+控制任务始终高于AI任务。AI采用以下两种方式之一：
+
+- 固定周期内完成一次完整推理；
+- 把算子图切分成若干有界片段，分布在多个控制周期的空闲窗口执行。
+
+必须分析AI不可抢占片段、中断和DMA对关键任务造成的最大阻塞。
+
+### 3.3 有界通信
+
+- 固定长度队列或环形缓冲；
+- 最新值优先，过期输入可丢弃；
+- 控制任务不得因等待AI队列而阻塞；
+- 结果携带时间戳和有效期；
+- 超时结果不得晚到生效。
+
+### 3.4 部署准入
+
+在编译和烧录前检查：
+
+- Flash/RAM是否超限；
+- 算子是否受支持；
+- 模型质量是否达标；
+- 推理窗口是否满足；
+- 控制任务是否仍可调度；
+- 是否存在规则兜底和故障恢复路径。
+
+## 4. 工具链路线
+
+```text
+ONNX/TFLite/其他固定模型
+  → 解析与校验
+  → 量化和算子合法化
+  → 目标芯片算子映射
+  → 张量生命周期与静态内存规划
+  → 控制任务联合调度分析
+  → SylixOS C/C++、链接段和任务配置生成
+  → RealEvo编译、部署、调试
+  → 板端数据回灌
+```
+
+建议研究团队开发独立的编排器，不重复实现IDE。编排器负责模型、资源和任务分析；RealEvo继续负责BSP/App工程、交叉编译、部署和调试。
+
+## 5. 结合现有设备的实现
+
+### 5.1 4×V100服务器
+
+负责训练、剪枝、量化校准、参考精度、模型转换和编排工具运行。服务器结果只提供模型侧基线，不作为控制端实时性证据。
+
+### 5.2 RK3588工业盒
+
+首期以CPU路径打通端到端流程，再把NPU作为条件扩展：
+
+1. SylixOS BSP和控制任务准入；
+2. CPU小模型运行；
+3. 静态Arena和任务生成；
+4. 固定核、共享核与干扰对照；
+5. 超时、过载和规则兜底；
+6. NPU运行时可用后增加DMA、统一内存和中断实验。
+
+### 5.3 RK3568/RK3576
+
+用于验证生成代码和资源描述能否跨BSP迁移，并逐步缩小内存、算力和功耗预算。两者仍归类为控制端SoC。
+
+### 5.4 真正MCU
+
+必须在BSP、最小系统、模型运行时和测量链路确认后选型。真正MCU阶段应把模型收敛到1D CNN、DS-CNN、MLP、决策树等有限任务，不延续大模型口径。
+
+## 6. SylixOS技术映射
+
+| 研究机制 | SylixOS/RealEvo落点 | 待确认项 |
+|---|---|---|
+| 周期任务与优先级 | 线程、定时器、RMS/固定优先级 | API和实际调度配置 |
+| 核绑定 | SMP与大小核调度 | RK3588具体亲和性接口 |
+| 静态内存 | BSP内存映射、链接脚本、静态区 | 内存域和限额能力 |
+| DMA/Cache | BSP与驱动接口 | NPU、摄像头等设备一致性路径 |
+| 异常恢复 | 看门狗、任务/进程恢复 | 推荐的局部重启方式 |
+| 代码部署 | RealEvo BSP/App构建、上传和调试 | 外部生成工程接口 |
+| MCU落地 | lite/tiny与目标BSP | 芯片清单和最小资源占用 |
+
+## 7. 技术边界
+
+- 不把GPU/NPU内部执行时间直接归因于RTOS；
+- 不把不同推理后端的整栈差异写成操作系统差异；
+- 不用观测最大值替代理论WCET；
+- 不在驱动未准入时承诺NPU路径；
+- 不用SoC受限配置替代真正MCU功耗和存储结论。
+
+六步编排、配置产物和准入门槛详见 [01-离线联合编排研究框架.md](./01-离线联合编排研究框架.md)。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/01-离线联合编排研究框架.md

@@ -0,0 +1,662 @@
+# 面向 MCU 静态智能控制基础系统的离线联合编排研究框架
+
+> 版本：v0.1
+>
+> 用途：解释“模型—控制任务离线联合编排”具体研究什么、如何在现有硬件与 SylixOS 条件下实施，以及最终形成哪些可验证成果。
+> 适用范围：子课题 A“面向 MCU 的静态智能控制基础系统”。
+
+## 1. 研究目的
+
+本研究不是把模型训练、控制软件开发和操作系统移植分别完成后，再把三者简单放到同一设备上运行，而是在部署前联合回答以下问题：
+
+1. 控制任务必须保留多少 CPU 时间、内存、中断和通信资源；
+2. 智能模型需要多少权重空间、运行内存、执行时间和能量；
+3. 模型能否在不破坏控制截止期的条件下进入系统；
+4. 模型、算子、任务和缓冲区应如何静态放置；
+5. 推理超时、输入堆积、结果异常或设备故障时，系统如何降级；
+6. 部署工具能否在烧录前给出“允许部署、需要降级或拒绝部署”的结论。
+
+本研究的核心目标可以概括为：
+
+> 将轻量智能任务转换为一个具有固定资源上限、固定执行边界和明确失效处理方式的实时系统任务，使其能够被纳入 SylixOS 控制系统的可调度性与资源预算分析。
+
+## 2. 先明确设备边界
+
+### 2.1 MCU 与控制端 SoC 不能混为一谈
+
+仓库现有设备和候选设备中，RK3568、RK3576、RK3588 都属于多核应用处理器或异构 SoC，不是真正意义上的微控制器 MCU。它们拥有 MMU、GB 级内存并可运行 Linux 或大型 RTOS，适合验证：
+
+- SylixOS 上的静态任务与内存编排流程；
+- 大小核绑定、任务优先级、中断与 DMA 干扰；
+- 模型转换、代码生成、部署和运行时保护；
+- 从控制端 SoC 向真正 MCU 收缩时的方法可迁移性。
+
+但如果最终论文题目明确使用“MCU”，仍需要增加一块真正的 MCU 实验平台，对 KB/MB 级 SRAM、片上 Flash、无 MMU、固定外设和极低功耗条件进行实测。
+
+### 2.2 当前硬件在本研究中的分工
+
+| 平台 | 当前状态 | 在本子课题中的角色 | 不能直接证明什么 |
+|---|---|---|---|
+| RK3588 16 GB 工业盒 | 已有 | P0 方法原型；验证 SylixOS 集成、静态编排工具、资源限额和控制/推理共存 | 不能直接代表真正 MCU 的内存与功耗边界 |
+| RK3588 8 GB 受限配置 | 由现有设备限额形成 | 模拟控制端高档资源约束，验证预算收缩和部署拒绝机制 | 内存限额不等于真实小芯片的缓存、总线和功耗特征 |
+| 4×V100 服务器 | 已有 | 模型训练、量化校准、转换、参考精度和离线工具运行 | 不作为 MCU 实时控制结论的证据 |
+| RK3568 / RK3576 | 条件扩展 | 控制端 SoC 收缩验证；观察更小内存、低功耗和较弱算力条件 | 仍不是严格意义上的 MCU |
+| 真正 MCU 开发板 | 当前需补充 | P2 核心实证；验证 KB/MB 级内存、固定窗口、快速启动和 `E/inference` | 需先确认 SylixOS BSP、工具链和模型运行时支持 |
+
+### 2.3 SylixOS 已确认能力与待确认能力
+
+基于当前仓库材料和翼辉官方资料，可以把 SylixOS 能力分成两类。
+
+已确认、可用于研究设计的能力：
+
+- 支持多线程、实时调度、中断、定时器、同步和内存管理；
+- 支持 SMP、多种处理器架构和 BSP 开发；
+- RealEvo 可创建、构建、部署和调试 BSP 与应用工程；
+- BSP 工程可配置启动、内存映射、链接脚本、中断、时钟、Cache 和 DMA；
+- 官方存在 RK3588 和 RK3568 的板级资料，可作为适配依据；
+- 可通过链接脚本、静态区、固定任务和固定优先级实现离线资源布局。
+
+必须由翼辉或具体 BSP 进一步确认的能力：
+
+- 现有 RK3588 工业盒是否与官方支持板完全兼容；
+- RK3588 NPU、RKNN/RKLLM 或其他推理后端在 SylixOS 下的可用性；
+- RK3576 的完整 BSP、驱动和性能计数支持；
+- 面向真正 MCU 的 SylixOS lite/tiny 配置、最小内存占用和目标芯片 BSP；
+- 模型运行时、算子库、DSP/NPU驱动和功耗测量接口；
+- 核绑定、内存域、DMA缓冲、缓存维护和中断亲和性的具体 API。
+
+因此，本研究不能预设“模型和NPU在SylixOS上已经可用”，而应把运行时与驱动准入作为第一道实验门槛。
+
+## 3. 离线联合编排的输入与输出
+
+### 3.1 输入
+
+离线编排器至少接收四类描述。
+
+#### 控制任务描述
+
+- 周期 `T_i`；
+- 相对截止期 `D_i`；
+- 优先级；
+- WCET、测量上界或执行时间分布；
+- 栈空间；
+- 中断、DMA、总线和外设依赖；
+- 任务之间的先后关系；
+- 故障时必须继续运行的最小任务集合。
+
+#### 模型描述
+
+- 模型格式与版本；
+- 输入输出张量；
+- 算子图；
+- 量化格式；
+- 权重大小；
+- 中间张量生命周期；
+- 算子工作区；
+- 各算子在目标芯片上的执行时间与能耗估计；
+- 任务质量阈值。
+
+#### 平台描述
+
+- CPU、DSP、NPU及其频率；
+- Flash、SRAM、DDR和内存 Bank；
+- Cache、DMA、总线和外设结构；
+- SylixOS BSP、驱动、编译器和运行时版本；
+- 可用算子库与硬件加速能力；
+- 功耗模式、启动方式和测量接口。
+
+#### 安全与运行策略描述
+
+- AI任务周期与最大等待时间；
+- 可接受的输入丢弃策略；
+- 超时后的默认动作；
+- 模型结果合法性检查；
+- 连续异常次数阈值；
+- 进入降级模式与退出降级模式的条件。
+
+### 3.2 输出
+
+离线编排器最终不只生成可执行程序，还应生成一组可审查产物：
+
+1. 静态内存布局；
+2. 任务优先级与核绑定表；
+3. 推理窗口与抢占关系表；
+4. 模型和算子映射结果；
+5. 超时、丢弃、降级和恢复策略；
+6. SylixOS 应用代码与配置；
+7. 部署准入报告；
+8. 实测校准清单；
+9. 配置清单与版本指纹。
+
+## 4. 六步离线联合编排流程
+
+### 4.1 步骤一：分析控制任务
+
+#### 研究问题
+
+第一步不是分析模型，而是先确定系统中哪些控制功能绝对不能被AI破坏。
+
+对每个控制任务建立任务参数：
+
+\[
+\tau_i=(T_i,D_i,C_i,P_i,M_i,I_i)
+\]
+
+其中：
+
+- `T_i`：周期；
+- `D_i`：截止期；
+- `C_i`：执行时间上界或测量上界；
+- `P_i`：优先级；
+- `M_i`：栈、静态数据和缓冲区；
+- `I_i`：中断、DMA和外设干扰。
+
+#### 具体工作
+
+1. 列出周期控制、状态采集、执行输出、通信、诊断和日志任务；
+2. 区分硬关键、软关键和非关键任务；
+3. 测量空载和典型干扰下的执行时间；
+4. 记录中断屏蔽、临界区、锁竞争和DMA影响；
+5. 确定控制任务必须保留的CPU、栈、缓冲区和安全余量；
+6. 建立无AI时的实时性基线。
+
+#### SylixOS 落点
+
+- 使用固定优先级、RMS或项目冻结的调度策略；
+- 控制任务使用静态或预分配栈；
+- 将关键中断与AI相关中断分层；
+- 在多核 SoC 上优先为关键任务设置固定核或亲和性；
+- 通过GPIO翻转、系统时间戳或外部逻辑分析仪测量端到端响应。
+
+#### 输出
+
+- `control_tasks.yaml`；
+- 控制任务时序图；
+- CPU利用率和响应时间分析表；
+- 关键任务内存预留表；
+- 无AI基线数据。
+
+#### 准入门槛 G1
+
+只有在控制任务单独运行时能够稳定满足截止期、测量链路可信且日志不会明显干扰实时任务，才进入下一步。
+
+### 4.2 步骤二：分析模型与算子
+
+#### 研究问题
+
+模型是否适合控制端，不由参数量单独决定，而由模型图、算子支持、工作区、执行时间和任务质量共同决定。
+
+#### 具体工作
+
+1. 固定模型修订、输入尺寸、前处理和输出语义；
+2. 将模型转换为稳定的中间表示；
+3. 完成 INT8 或其他目标量化，并保存校准数据；
+4. 展开算子图，统计每个算子的输入、输出和工作区；
+5. 检查动态 Shape、动态控制流和不支持算子；
+6. 在目标芯片或参考内核上测量算子执行时间；
+7. 计算模型峰值内存，而不是只计算权重大小；
+8. 比较量化前后任务质量。
+
+#### 优先模型类型
+
+真正 MCU 阶段优先选择：
+
+- 1D CNN 异常检测；
+- DS-CNN 关键词识别；
+- 小型 MLP 状态分类；
+- 轻量视觉分类；
+- 决策树或小型集成模型。
+
+RK3588/RK3568 方法原型阶段可以使用更大的模型验证工具链，但不能据此替代 MCU 结论。
+
+#### 输出
+
+- `model_manifest.yaml`；
+- 算子支持矩阵；
+- 权重、Tensor Arena与工作区统计；
+- 算子执行时间数据库；
+- 精度与量化报告。
+
+#### 准入门槛 G2
+
+出现以下任一情况时拒绝进入正式编排：
+
+- 存在无法替换的不支持算子；
+- 峰值内存已经超过AI预算；
+- 任务质量低于冻结阈值；
+- 单次推理时间明显超过允许窗口且无法分段；
+- 推理后端或驱动在SylixOS目标板上不可用。
+
+### 4.3 步骤三：制定静态内存布局
+
+#### 研究问题
+
+系统必须在部署前知道每一类内存由谁使用、峰值是多少、是否会与DMA或控制任务冲突。
+
+AI 内存预算至少包括：
+
+\[
+M_{AI}=M_{weights}+M_{arena}+M_{workspace}+M_{IO}+M_{stack}
+\]
+
+系统可给AI使用的上限为：
+
+\[
+M_{AI,max}=M_{total}-M_{OS}-M_{control}-M_{comm}-M_{safety}
+\]
+
+必须满足：
+
+\[
+M_{AI}\leq M_{AI,max}
+\]
+
+#### 具体工作
+
+1. 冻结SylixOS内核、应用、控制任务和通信缓冲的预留；
+2. 确定权重放在Flash、eMMC映射区、DDR还是SRAM；
+3. 根据张量生命周期复用Tensor Arena；
+4. 单独划分DMA缓冲，明确Cache一致性处理；
+5. 避免控制任务与推理任务共享无界堆；
+6. 在多Bank SRAM或NUMA式结构中确定放置位置；
+7. 为日志、异常和升级预留安全余量；
+8. 生成链接段、内存映射和静态数组。
+
+#### SylixOS 落点
+
+- 在BSP和链接脚本中固定关键内存段；
+- 控制任务与AI任务使用独立静态区或受限内存区域；
+- 正式运行窗口内禁止模型路径调用无界 `malloc/free`；
+- 使用SylixOS的Cache、DMA和内存管理接口完成一致性治理；
+- 在RK3588原型阶段分别测试16 GB全量和8 GB限额，但将结果标为SoC约束实验。
+
+#### 输出
+
+- `memory_layout.yaml`；
+- SylixOS链接脚本片段；
+- Tensor Arena偏移表；
+- DMA与控制缓冲区映射；
+- 峰值内存与安全余量报告。
+
+#### 准入门槛 G3
+
+若内存峰值超过预算、DMA缓冲与关键区域存在未解决冲突，或部署依赖运行时无界分配，则拒绝部署。
+
+### 4.4 步骤四：制定静态时间布局
+
+#### 研究问题
+
+AI任务必须使用控制任务执行后明确剩余的时间，而不能依赖平均CPU占用较低。
+
+#### 两类编排方式
+
+##### 方式A：完整推理窗口
+
+每隔固定周期释放一次AI任务，并要求其在固定窗口内完成。例如：
+
+- 控制任务周期：1 ms；
+- AI任务周期：50 ms；
+- AI最大完成时间：20 ms；
+- 控制任务可随时抢占AI任务；
+- AI超时则丢弃本次结果。
+
+适合一次推理可在较短时间内完成的模型。
+
+##### 方式B：算子级分段窗口
+
+将推理图按算子或子图切分，每次只执行一个有界片段：
+
+```text
+控制周期1：Conv1
+控制周期2：DepthwiseConv
+控制周期3：Pooling
+控制周期4：FC + 输出检查
+```
+
+适合单次完整推理时间较长，但每个算子能够独立建立执行边界的模型。
+
+#### 具体工作
+
+1. 冻结AI任务的周期、相位和相对截止期；
+2. 确定AI任务优先级低于关键控制任务；
+3. 确定是否允许算子间抢占；
+4. 建立AI任务对控制任务的阻塞时间上界；
+5. 建立中断与DMA干扰项；
+6. 进行响应时间分析或调度仿真；
+7. 生成时间表、优先级和核绑定配置；
+8. 在目标板上校准预测值。
+
+#### SylixOS 落点
+
+- 使用SylixOS线程优先级和定时器建立周期释放；
+- 控制任务固定为高优先级，AI工作线程低于控制与安全线程；
+- 在RK3588上可将关键控制线程与AI线程固定到不同核，比较固定核与共享核；
+- NPU提交线程、中断回收线程和模型加载线程必须进入统一优先级分析；
+- 记录调度延迟、抢占次数和每个推理片段的开始/结束时间。
+
+#### 输出
+
+- `schedule.yaml`；
+- 任务—核心映射表；
+- 推理窗口或算子分段表；
+- 响应时间和可调度性分析；
+- 预测与实测偏差表。
+
+#### 准入门槛 G4
+
+只有在加入AI任务后，关键控制任务仍满足冻结的截止期条件，并保留约定安全余量，才允许进入混合负载实验。
+
+### 4.5 步骤五：加入运行时保护机制
+
+#### 研究问题
+
+静态编排只能说明正常条件下可运行，保护机制负责处理模型超时、输入过载、输出异常和推理域故障。
+
+#### 保护机制
+
+| 机制 | 目的 | 推荐策略 |
+|---|---|---|
+| 超时检测 | 防止推理无限占用窗口 | 到期取消结果、停止后续片段或重置任务状态 |
+| 有界队列 | 防止输入无限堆积 | 固定长度1～N，禁止无界增长 |
+| 输入丢弃 | 保持结果时效性 | 优先保留最新状态，丢弃过期样本 |
+| 输出校验 | 阻止非法模型结果进入控制路径 | 范围检查、状态机检查、置信度与一致性检查 |
+| 规则兜底 | AI不可用时维持基本控制 | 执行冻结的安全规则或默认动作 |
+| 看门狗 | 处理推理任务卡死 | 局部任务重启，必要时进入系统降级 |
+| 恢复门槛 | 防止故障后立即反复切换 | 连续通过若干次自检后恢复AI路径 |
+
+#### 运行原则
+
+1. AI结果不能直接覆盖硬安全约束；
+2. 控制内环不等待AI任务；
+3. 超时结果不得晚到后继续生效；
+4. 队列满时优先拒绝或覆盖旧输入，而不是阻塞控制任务；
+5. 降级路径必须在没有AI的情况下独立运行；
+6. 恢复过程不能引入新的控制抖动。
+
+#### SylixOS 落点
+
+- 使用高精度定时器或任务级截止期监视；
+- 使用固定长度消息队列、事件或环形缓冲；
+- 利用看门狗和任务重启机制处理异常；
+- 将规则兜底任务设置为高于AI任务、低于最关键控制任务的明确层级；
+- 使用RealEvo调试与性能工具记录异常切换过程；
+- 在RK3568/RK3588上可进一步测试NPU/驱动异常是否传播到控制路径。
+
+#### 输出
+
+- `safety_policy.yaml`；
+- 超时和丢弃状态机；
+- 规则兜底代码；
+- 故障注入脚本或测试程序；
+- 异常切换与恢复测试报告。
+
+#### 准入门槛 G5
+
+模型超时、队列过载和推理任务异常时，控制任务必须继续运行；若故障能够无界传播到控制路径，则系统不得进入正式实验。
+
+### 4.6 步骤六：生成部署产物与准入报告
+
+#### 研究问题
+
+部署报告不是普通性能总结，而是对一个“模型—硬件—SylixOS—控制任务”组合能否上线的工程判定。
+
+#### 报告内容
+
+##### 基本信息
+
+- 板卡与硬件版本；
+- SylixOS、BSP、编译器和驱动版本；
+- 模型、量化文件和校验值；
+- 控制应用版本；
+- 工具链版本。
+
+##### 资源预算
+
+| 项目 | 上限 | 预测值 | 实测值 | 结论 |
+|---|---:|---:|---:|---|
+| Flash/eMMC占用 | 待冻结 |  |  |  |
+| 静态RAM | 待冻结 |  |  |  |
+| Tensor Arena | 待冻结 |  |  |  |
+| 任务栈 | 待冻结 |  |  |  |
+| DMA缓冲 | 待冻结 |  |  |  |
+| 单次推理时间 | 待冻结 |  |  |  |
+| 控制任务最大响应时间 | 待冻结 |  |  |  |
+| `E/inference` | 待冻结 |  |  |  |
+| 启动到安全控制 | 待冻结 |  |  |  |
+| 启动到AI就绪 | 待冻结 |  |  |  |
+
+##### 准入结论
+
+部署结论只允许使用以下三种状态：
+
+- **PASS**：资源、时间、质量和保护机制全部通过；
+- **PASS WITH LIMITS**：降低AI周期、模型规模或功能范围后通过；
+- **REJECT**：会破坏控制截止期、超出资源预算或缺少可验证保护机制。
+
+#### 自动生成的工程产物
+
+- 模型权重或模型镜像；
+- 静态Tensor Arena；
+- 算子调用代码；
+- SylixOS任务包装代码；
+- 超时与规则兜底代码；
+- 链接脚本和内存布局；
+- 编译配置；
+- 部署清单；
+- 测试用例与验收脚本。
+
+## 5. 工具链总体结构
+
+```text
+训练模型/固定数据集
+        │
+        ▼
+模型解析、量化与任务质量检查
+        │
+        ▼
+算子合法化、融合与目标芯片映射
+        │
+        ├──────────────┐
+        ▼              ▼
+算子时间/能耗数据库   控制任务与平台描述
+        │              │
+        └──────┬───────┘
+               ▼
+       内存规划与时间编排
+               │
+               ▼
+       可调度性与准入检查
+               │
+      ┌────────┴────────┐
+      ▼                 ▼
+   拒绝/降级建议     生成SylixOS工程
+                         │
+                         ▼
+              RealEvo编译、部署与调试
+                         │
+                         ▼
+                 板端实测与模型校准
+```
+
+### 5.1 与 RealEvo 的结合方式
+
+建议不要重新实现完整IDE，而是在模型编排工具与RealEvo之间定义稳定接口：
+
+1. 模型侧工具生成C/C++代码、权重、静态内存描述和任务配置；
+2. RealEvo负责SylixOS BSP/App工程管理、交叉编译、部署和调试；
+3. 编排工具生成或修改应用层配置和链接片段；
+4. 板端采样程序输出执行时间、内存、功耗和异常事件；
+5. 实测数据回灌算子数据库，修正下一轮预测。
+
+这样可以把研究贡献集中在“模型与控制任务的联合编排”，避免重复建设已有的操作系统IDE能力。
+
+## 6. 基于现有硬件的分阶段实施路线
+
+### P0：在现有 RK3588 上建立完整链路
+
+目标：不等待新硬件，先打通方法和工具。
+
+工作内容：
+
+1. 确认现有工业盒的SylixOS BSP兼容性；
+2. 建立普通Linux/PREEMPT_RT与SylixOS控制任务基线；
+3. 先使用CPU可执行的小模型，避免一开始被NPU驱动阻塞；
+4. 完成模型解析、量化、静态Arena和代码生成；
+5. 完成控制任务与AI任务的固定优先级编排；
+6. 完成超时、队列限长和规则兜底；
+7. 在16 GB和受限内存配置下验证部署报告是否能够正确给出结论。
+
+P0的成果是“方法原型”，不是MCU最终结论。
+
+### P1：向 RK3568/RK3576 控制端收缩
+
+目标：验证方法在较弱CPU、更小内存和更低功耗平台上的迁移能力。
+
+工作内容：
+
+- 减小模型和Tensor Arena；
+- 收紧CPU时间和功耗预算；
+- 验证启动时间和看门狗恢复；
+- 验证不同BSP下代码生成的可移植性；
+- 比较工具预测值与板端实测偏差。
+
+P1仍属于“控制端SoC验证”，正式材料中不应写成纯MCU实证。
+
+### P2：增加真正 MCU 平台
+
+目标：形成严格的MCU级研究证据。
+
+选板前必须确认：
+
+- SylixOS或其lite/tiny配置能否运行；
+- BSP、编译器、调试器和功耗测量链路是否可用；
+- SRAM、Flash、DSP/NPU和DMA结构是否适合研究；
+- 是否可以获得芯片厂商算子库和周期数据；
+- 控制外设、GPIO、CAN、ADC/PWM是否满足闭环实验。
+
+如果SylixOS不适合最终选定的极小MCU，可将研究拆成两层：
+
+1. SylixOS控制端SoC负责系统编排与工程平台验证；
+2. 真正MCU负责静态模型、控制闭环和极限资源边界验证；
+3. 两层共享任务描述、模型清单、内存规划和准入报告格式。
+
+这比为了维持单一操作系统叙事而选择不合适的平台更符合研究真实性。
+
+## 7. 推荐的首个实验样例
+
+### 7.1 场景：电机状态识别与 1 ms 控制共存
+
+控制链路：
+
+```text
+ADC/编码器采样 → 1 ms控制算法 → PWM/CAN输出
+```
+
+智能链路：
+
+```text
+振动/电流窗口 → 1D CNN → 状态分类 → 规则检查 → 参数建议或告警
+```
+
+关键原则：
+
+- 1 ms控制内环不等待AI；
+- AI每50～100 ms运行一次；
+- AI只提供状态分类、参数建议或告警；
+- AI超时或结果非法时，继续使用规则控制；
+- AI结果只有通过范围和状态机检查后才能生效。
+
+### 7.2 实验变量
+
+- 无AI、AI静态编排、AI无保护三组；
+- CPU共享核与固定核；
+- 动态堆与静态Arena；
+- 完整推理与算子分段；
+- 无干扰、CPU干扰、内存/DMA干扰；
+- 不同量化模型；
+- 正常、超时、队列过载和任务异常。
+
+### 7.3 主要指标
+
+| 层次 | 指标 |
+|---|---|
+| 控制任务 | deadline miss ratio、P99/P99.9 jitter、最大响应时间、GPIO端到端响应 |
+| AI任务 | 单次推理时延、完成率、任务质量、峰值内存 |
+| 系统协同 | CPU占用、内存余量、队列状态、干扰下的可用区间 |
+| 能耗与启动 | `E/inference`、平均功耗、启动到安全控制、启动到AI就绪 |
+| 安全与恢复 | 超时切换时间、规则触发正确率、恢复时间、故障传播范围 |
+
+## 8. 研究问题与论文贡献
+
+### RQ1：离线联合编排能否保护控制截止期
+
+比较模型单独部署、普通后台任务部署和静态联合编排，观察关键控制任务的尾延迟与截止期违约。
+
+### RQ2：静态内存规划能否降低峰值与碎片风险
+
+比较动态堆、固定Arena和生命周期复用三种方案，观察峰值内存、长期稳定性和部署成功率。
+
+### RQ3：部署前预测能否接近板端实测
+
+比较工具预测的内存、执行时间和功耗与板端实测值，建立误差范围与安全系数。
+
+### RQ4：保护机制能否限制AI故障传播
+
+注入超时、错误输出、队列过载和任务崩溃，测量控制任务是否继续达标以及系统恢复时间。
+
+### 预期贡献
+
+1. 面向智能控制任务的统一描述方法；
+2. 模型—算子—控制任务联合静态编排算法；
+3. 面向SylixOS的代码生成与部署接口；
+4. 部署前资源和可调度性准入方法；
+5. 规则兜底与故障隔离运行时；
+6. 从RK3588方法原型到真正MCU实证的分级验证体系。
+
+## 9. 与翼辉联合研究需要确认的接口
+
+建议将以下问题整理为与翼辉的技术确认清单：
+
+1. 现有RK3588工业盒可复用哪个官方BSP，板级差异有哪些；
+2. RK3588/RK3568上可用的任务核绑定、中断亲和性和内存限额接口；
+3. RKNN/RKLLM或其他NPU运行时能否移植到SylixOS；
+4. DMA连续内存、Cache维护和设备中断的推荐实现；
+5. RealEvo能否接收外部工具生成的工程、链接配置和代码；
+6. 是否存在适合真正MCU的SylixOS lite/tiny产品形态和参考BSP；
+7. 能否提供任务切换、中断延迟、内存和功耗相关追踪接口；
+8. 看门狗、任务重启、进程隔离和异常恢复的推荐工程路径；
+9. 是否可联合建设算子执行时间与资源占用数据库；
+10. 是否可共同定义“模型进入任务关键控制系统”的部署准入报告。
+
+## 10. 最终判断标准
+
+本研究成功的标志不是模型能够在板卡上输出结果，而是同时满足：
+
+1. 部署前能够计算模型和控制任务的资源需求；
+2. 工具能够自动生成静态内存和时间布局；
+3. SylixOS上的控制任务在AI和干扰负载下仍满足截止期；
+4. AI任务的资源使用不超过冻结预算；
+5. 模型超时或异常时规则路径可以接管；
+6. 预测值和实测值之间存在可解释误差范围；
+7. 同一描述和工具链能够从RK3588原型逐步迁移到更小控制端和真正MCU。
+
+最终需要形成的不是一个“能够运行的小模型演示”，而是一套：
+
+> **能够在部署前判断可行性、在运行时维持控制边界、在异常时完成安全降级的静态智能控制基础系统。**
+
+## 11. 参考资料
+
+### 仓库内材料
+
+- `10-共享理论与方法层/06-基础设备与算力基础.md`
+- `20-子课题A-面向MCU的静态智能控制基础系统/02-技术路线：静态编排、工具链与芯片协同.md`
+- `20-子课题A-面向MCU的静态智能控制基础系统/03-实验设计与验证方法.md`
+- 项目框架1中的设备、实验设计和SylixOS联合研究方资料
+
+### 翼辉官方资料
+
+- SylixOS / RealEvo 开发环境：<https://docs.acoinfo.com/sylixos/ide/install_the_ide/overview.html>
+- RealEvo BSP开发：<https://docs.acoinfo.com/realevo-stream/practice/visual-workflow/bsp_c.html>
+- SylixOS系统与驱动开发：<https://docs.acoinfo.com/sylixos/dsp/advanced_development/system_development.html>
+- RK3588官方板级资料：<https://docs.acoinfo.com/bsp-sdk/RK3588/TL3588-EVM/product_introduction/board_introduction.html>
+- RK3568看门狗与设备资料示例：<https://docs.acoinfo.com/bsp-sdk/RK3568/TL3568-EVM/development_guidelines/watchdog_usage.html>

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/10-技术框架/README.md

@@ -0,0 +1,22 @@
+# 10-技术框架
+
+本层回答“静态智能控制基础系统如何设计和生成”。
+
+## 文件
+
+1. [00-总体技术路线.md](./00-总体技术路线.md)：四层架构、核心机制、工具链和SylixOS映射；
+2. [01-离线联合编排研究框架.md](./01-离线联合编排研究框架.md)：六步编排流程、准入门槛、配置产物和板端校准。
+
+## 核心链路
+
+```text
+控制任务 + 模型 + 平台
+          ↓
+内存规划 + 时间编排 + 准入检查
+          ↓
+SylixOS工程生成
+          ↓
+超时、规则兜底与恢复
+```
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/00-实验设计与验证方法.md

@@ -0,0 +1,144 @@
+# 实验设计与验证方法
+
+## 1. 实验目标
+
+验证静态联合编排是否能够在AI进入控制系统后，同时保证：
+
+1. 控制任务时间边界；
+2. AI任务质量与时效性；
+3. 内存、功耗和启动预算；
+4. 超时、过载和异常时的安全降级。
+
+## 2. 平台分层
+
+| 层级 | 平台 | 作用 |
+|---|---|---|
+| H0 | 4×V100服务器 | 训练、量化、转换和参考精度 |
+| H1 | RK3588 16 GB | SylixOS方法原型和完整链路 |
+| H2 | RK3588 8 GB限额 | 预算收缩与准入判定验证 |
+| H3 | RK3568/RK3576 | 控制端迁移、低功耗和跨BSP验证 |
+| H4 | 真正MCU | SRAM/Flash、快速启动和极限资源实证 |
+
+## 3. 对照组
+
+| 编号 | 配置 | 目的 |
+|---|---|---|
+| O0 | 无AI，仅控制任务 | 控制性能下界 |
+| O1 | AI作为普通后台任务 | 观察未经治理的干扰 |
+| O2 | 静态Arena + 固定优先级 | 验证基础静态机制 |
+| O3 | O2 + 固定窗口/算子分段 | 验证时间编排 |
+| O4 | O3 + 准入、超时和规则兜底 | 完整方案 |
+
+在同硬件、同模型、同输入和同编译选项下进行机制消融。Linux/PREEMPT_RT与SylixOS比较属于系统方案对照，若推理后端不同，必须单独解释。
+
+## 4. 负载场景
+
+| 编号 | 场景 | 目的 |
+|---|---|---|
+| L0 | 仅周期控制 | 建立基线 |
+| L1 | 仅AI任务 | 建立模型时间与能耗基线 |
+| L2 | 控制 + AI | 核心共存场景 |
+| L3 | L2 + CPU竞争 | 验证调度和抢占 |
+| L4 | L2 + 内存/DMA竞争 | 验证内存与总线干扰 |
+| L5 | L2 + CAN/网络/存储 | 验证中断和I/O污染 |
+| L6 | L2 + 突发输入 | 验证队列、丢弃与准入 |
+| L7 | L2 + 超时/崩溃/错误输出 | 验证规则兜底和恢复 |
+
+## 5. 实验单元
+
+### E0：设备和软件准入
+
+- BSP启动、时钟、SMP、外设和看门狗；
+- SylixOS/RealEvo版本冻结；
+- 模型在CPU路径完成正确性验证；
+- NPU路径单独设置准入门槛；
+- 测量工具和时间戳校验。
+
+### E1：控制任务基线
+
+测量1 ms主任务及5/10 ms扩展任务的唤醒延迟、响应时间、抖动和GPIO端到端响应。
+
+### E2：模型和算子基线
+
+记录每个算子与完整模型的执行时间、峰值内存、工作区、任务质量和 `E/inference`。
+
+### E3：内存方案对照
+
+比较动态堆、固定Arena、生命周期复用和不同内存限额，观察峰值、碎片、失败点和长稳行为。
+
+### E4：时间编排对照
+
+比较普通后台运行、固定窗口和算子分段，观察控制任务尾延迟、AI完成率和切分开销。
+
+### E5：混合干扰
+
+依次增加CPU、内存、DMA、通信和存储干扰，不同时改变多个变量。
+
+### E6：准入和过载
+
+逐级增加AI到达率，记录队列峰值、拒绝率、过期输入、有效完成率和控制任务边界。
+
+### E7：故障与规则兜底
+
+注入模型超时、错误输出、任务崩溃和驱动不可用，测量切换时间、控制保持率和恢复时间。
+
+### E8：启动、功耗和长稳
+
+分别测量启动到安全控制、启动到AI就绪、平均功耗、单次推理能耗和24小时运行状态。
+
+## 6. 指标
+
+### 6.1 控制层
+
+- deadline miss ratio；
+- P50/P95/P99/P99.9 jitter；
+- 观测最大响应时间；
+- GPIO/CAN端到端响应；
+- 降级期间控制任务保持率。
+
+### 6.2 AI层
+
+- 单次推理时延及分布；
+- 完成率、拒绝率和过期率；
+- 任务准确率、F1或业务指标；
+- 权重、Arena、工作区和峰值内存。
+
+### 6.3 系统层
+
+- CPU占用和抢占次数；
+- 队列长度；
+- 内存安全余量；
+- `E/inference`；
+- 温度、频率和降频；
+- 启动与恢复时间。
+
+## 7. 统计与报告原则
+
+1. 普通单元至少独立运行5次；
+2. 控制任务报告样本数、分位数、最大值和违约分子/分母；
+3. 零违约只表述为“在指定工况和样本数下未观测到违约”；
+4. 不用P99.9或观测最大值冒充理论WCET；
+5. 保存超时、拒绝、OOM和任务崩溃，不静默删除失败数据；
+6. 预测与实测必须使用相同配置和版本；
+7. 功耗报告说明测量边界、采样率和空载功率。
+
+## 8. 数据产物
+
+每次运行至少保存：
+
+- `manifest.json`：硬件、SylixOS/BSP、模型、任务和编译配置；
+- `control.csv`：释放、开始、完成、CPU、截止期状态；
+- `inference.csv`：输入、开始、结束、结果、超时与拒绝原因；
+- `memory.csv`：静态区、Arena、栈和峰值；
+- `power.csv`：功率、温度和频率；
+- `events.log`：看门狗、降级、重启和恢复；
+- `summary.json`：指标、样本量和准入结论。
+
+## 9. 阶段完成条件
+
+- P0：RK3588 CPU路径完成E0～E7；
+- P1：NPU或加速路径在准入后完成E2、E5、E7；
+- P2：RK3568/RK3576复现实验并量化迁移成本；
+- P3：真正MCU完成E0～E8，形成严格MCU论文证据。
+
+若BSP、驱动或推理运行时不可用，停止对应路径，输出适配缺口，不把计划写成实测结果。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/01-首个实验冻结说明.md

@@ -0,0 +1,147 @@
+# 首个实验冻结说明
+
+> 实验名称：RK3588 + SylixOS上1 ms控制任务与INT8 1D CNN共存实验
+>
+> 状态：草案，待BSP与场景数据确认后冻结
+> 原则：冻结后，正式实验期间不得静默改变模型、输入、任务、频率和测量口径。
+
+## 1. 实验目标
+
+回答以下问题：
+
+1. AI作为普通后台任务运行时，会对1 ms控制任务造成多大干扰；
+2. 静态Arena、固定优先级和固定推理窗口能否降低干扰；
+3. 有界队列、超时和规则兜底能否限制AI过载与故障传播；
+4. 离线预测的内存和执行时间与板端实测相差多少。
+
+## 2. 平台冻结
+
+| 项目 | 冻结值 | 状态 |
+|---|---|---|
+| 设备型号/编号 | RK3588工业盒，待填写 | 待确认 |
+| CPU | 4×A76 + 4×A55 | 已知 |
+| 内存 | 16 GB；增加8 GB限额组 | 计划 |
+| 存储 | eMMC/NVMe，待填写 | 待确认 |
+| SylixOS版本 |  | 待翼辉确认 |
+| BSP版本 |  | 待翼辉确认 |
+| RealEvo版本 |  | 待翼辉确认 |
+| 编译器与优化级别 |  | 待确认 |
+| CPU频率策略 | 固定频率优先 | 待确认 |
+| 散热与环境温度 |  | 待填写 |
+
+## 3. 控制任务冻结
+
+| 参数 | 初始建议 | 最终冻结值 |
+|---|---:|---:|
+| 周期 `T` | 1 ms |  |
+| 截止期 `D` | 1 ms |  |
+| 任务体 | 确定性计算 + GPIO/CAN回环 |  |
+| 参考执行时间 | 约100～200 μs |  |
+| 释放方式 | 绝对周期释放 |  |
+| 优先级 | 最高业务优先级 |  |
+| CPU绑定 | 独占核与共享核各一组 |  |
+| 日志 | 预分配内存缓冲 |  |
+
+控制任务必须在无AI条件下先通过基线准入。
+
+## 4. AI任务冻结
+
+| 参数 | 初始建议 | 最终冻结值 |
+|---|---|---|
+| 任务 | 振动/电流窗口状态分类 |  |
+| 模型 | 小型INT8 1D CNN |  |
+| 输入长度 | 固定，待数据集确认 |  |
+| 输出类别 | 正常/轻微异常/严重异常 |  |
+| 推理周期 | 50或100 ms |  |
+| 推理后端 | 第一阶段CPU |  |
+| Tensor Arena | 静态生成 |  |
+| 最大允许执行时间 | 由基线试运行后冻结 |  |
+| 质量阈值 | Accuracy/F1，待冻结 |  |
+| 超时行为 | 丢弃结果并触发规则路径 |  |
+
+## 5. 对照组
+
+| 编号 | 配置 |
+|---|---|
+| O0 | 仅控制任务 |
+| O1 | 控制 + AI普通后台任务、动态内存 |
+| O2 | 控制 + AI静态Arena、固定优先级 |
+| O3 | O2 + 固定推理窗口或算子分段 |
+| O4 | O3 + 有界队列、超时、规则兜底和恢复 |
+
+## 6. 负载组
+
+- L0：无干扰；
+- L1：CPU竞争25/50/75%；
+- L2：内存流式读写；
+- L3：GPIO/CAN/网络I/O；
+- L4：AI输入突发；
+- L5：模型超时；
+- L6：AI任务异常退出；
+- L7：连续运行与热状态。
+
+## 7. 规则兜底
+
+AI结果仅用于状态分类、告警或参数建议，不直接覆盖硬安全约束。
+
+触发兜底的条件：
+
+- 推理超过冻结截止期；
+- 输出类别或数值越界；
+- 输入时间戳过期；
+- 队列溢出；
+- AI任务或运行时异常；
+- 连续若干次结果不可信。
+
+兜底动作：
+
+1. 丢弃当前AI结果；
+2. 保持或恢复规则控制；
+3. 记录事件；
+4. 必要时重启AI任务；
+5. 连续自检通过后恢复AI路径。
+
+## 8. 指标
+
+### 控制任务
+
+- deadline miss ratio；
+- P50/P95/P99/P99.9响应时间与抖动；
+- 观测最大值；
+- GPIO/CAN端到端响应。
+
+### AI任务
+
+- 单次推理时延；
+- 完成、拒绝、超时和过期率；
+- 任务质量；
+- 权重、Arena、工作区和峰值内存。
+
+### 系统
+
+- CPU占用、抢占和上下文切换；
+- 内存余量；
+- 功率、温度和频率；
+- 降级切换和恢复时间。
+
+## 9. 运行方法
+
+1. 保存硬件和软件配置快照；
+2. 重启进入指定配置；
+3. 先运行O0基线；
+4. 模型预热与冷启动分开测量；
+5. 各组随机或平衡顺序运行；
+6. 普通单元至少独立运行5次；
+7. 保存所有失败、拒绝和超时；
+8. 正式结果使用冻结后的新运行批次。
+
+## 10. 首轮完成判据
+
+- [ ] BSP、时钟和测量链路通过；
+- [ ] O0控制基线无未解释异常；
+- [ ] CPU模型正确运行；
+- [ ] O0～O4全部有数据；
+- [ ] 至少完成CPU、内存和突发干扰；
+- [ ] 至少完成一次超时和任务异常注入；
+- [ ] 预测内存与实测内存完成比较；
+- [ ] 得出静态联合编排是否改善控制边界的结论。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/02-硬件软件版本清单模板.md

@@ -0,0 +1,109 @@
+# 硬件与软件版本清单模板
+
+> 每次正式实验必须复制一份本模板并填写完整。无法获取的字段填写 `N/A` 或 `UNKNOWN`，不得留空或按经验猜测。
+
+## 1. 实验标识
+
+| 字段 | 内容 |
+|---|---|
+| 项目 | 面向MCU的静态智能控制基础系统 |
+| 实验编号 |  |
+| 运行编号 |  |
+| 日期与时区 |  |
+| 操作人 |  |
+| 数据目录 |  |
+| Git提交 |  |
+
+## 2. 硬件
+
+| 字段 | 内容 |
+|---|---|
+| 设备名称 |  |
+| 实物编号 |  |
+| 主板/核心板型号 |  |
+| PCB/硬件版本 |  |
+| SoC/MCU |  |
+| CPU核心与频率 |  |
+| DSP/NPU/GPU |  |
+| RAM容量与类型 |  |
+| Flash/eMMC/NVMe |  |
+| 网络接口 |  |
+| CAN/RS485/GPIO |  |
+| 电源 |  |
+| 散热方式 |  |
+| 环境温度 |  |
+
+## 3. SylixOS与BSP
+
+| 字段 | 内容 |
+|---|---|
+| SylixOS版本 |  |
+| Base版本 |  |
+| BSP名称与版本 |  |
+| 设备树校验值 |  |
+| RealEvo版本 |  |
+| 编译器版本 |  |
+| 编译优化级别 |  |
+| C/C++运行库 |  |
+| 启动参数 |  |
+| CPU亲和性 |  |
+| 中断亲和性 |  |
+| 频率策略 |  |
+| 看门狗配置 |  |
+
+## 4. AI模型与运行时
+
+| 字段 | 内容 |
+|---|---|
+| 模型名称 |  |
+| 模型版本/校验值 |  |
+| 模型格式 |  |
+| 量化格式 |  |
+| 输入形状 |  |
+| 输出定义 |  |
+| 权重大小 |  |
+| Tensor Arena |  |
+| 最大工作区 |  |
+| 推理运行时 |  |
+| 算子库版本 |  |
+| NPU/驱动版本 |  |
+| 校准数据版本 |  |
+| 任务质量阈值 |  |
+
+## 5. 控制任务
+
+| 字段 | 内容 |
+|---|---|
+| 周期 |  |
+| 截止期 |  |
+| 优先级 |  |
+| CPU绑定 |  |
+| 栈大小 |  |
+| 任务体版本 |  |
+| GPIO/CAN回环 |  |
+| 安全规则版本 |  |
+| 超时动作 |  |
+
+## 6. 测量设备
+
+| 字段 | 内容 |
+|---|---|
+| 逻辑分析仪/示波器 |  |
+| 探头与采样率 |  |
+| 功率计 |  |
+| 功率采样率 |  |
+| CAN/RS485分析仪 |  |
+| 时间同步方式 |  |
+| 空载环回延迟 |  |
+
+## 7. 配置校验
+
+- [ ] 设备编号与实物一致；
+- [ ] Git提交已记录；
+- [ ] 模型校验值已记录；
+- [ ] BSP、编译器和运行时版本已记录；
+- [ ] CPU频率和亲和性已确认；
+- [ ] 输入、随机种子和负载序列已冻结；
+- [ ] 测量设备和采样率已确认；
+- [ ] 数据目录空间充足；
+- [ ] 故障与无效批次记录方式已确认。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/03-实验运行记录模板.md

@@ -0,0 +1,107 @@
+# 实验运行记录模板
+
+## 1. 运行信息
+
+| 字段 | 内容 |
+|---|---|
+| 实验编号 |  |
+| 运行编号 |  |
+| 日期/开始时间/结束时间 |  |
+| 操作人 |  |
+| 对照组 | O0/O1/O2/O3/O4 |
+| 负载组 | L0～L7 |
+| 数据目录 |  |
+| 配置清单 |  |
+
+## 2. 运行前检查
+
+- [ ] 硬件编号正确；
+- [ ] SylixOS/BSP/应用版本正确；
+- [ ] 模型校验值正确；
+- [ ] CPU频率与亲和性正确；
+- [ ] 中断配置正确；
+- [ ] 测量设备已连接；
+- [ ] 空载环回值正常；
+- [ ] 时间同步正常；
+- [ ] 数据目录空间充足；
+- [ ] 环境温度已记录。
+
+## 3. 运行参数
+
+| 参数 | 值 |
+|---|---|
+| 控制周期/截止期 |  |
+| 控制任务优先级/CPU |  |
+| AI周期/截止期 |  |
+| AI任务优先级/CPU |  |
+| 模型/量化/输入 |  |
+| Arena/工作区 |  |
+| 队列长度 |  |
+| 超时策略 |  |
+| 干扰负载 |  |
+| 运行时长 |  |
+| 随机种子 |  |
+
+## 4. 运行过程
+
+| 时间 | 事件 | 影响 | 处理 |
+|---|---|---|---|
+|  | 启动 |  |  |
+|  | 进入稳态 |  |  |
+|  | 干扰开始 |  |  |
+|  | 故障注入 |  |  |
+|  | 降级/恢复 |  |  |
+|  | 结束 |  |  |
+
+## 5. 结果摘要
+
+### 控制任务
+
+| 指标 | 结果 |
+|---|---:|
+| 计划释放数 |  |
+| 完成数 |  |
+| 截止期违约数/比率 |  |
+| P99/P99.9响应时间 |  |
+| 观测最大响应时间 |  |
+| GPIO/CAN端到端延迟 |  |
+
+### AI任务
+
+| 指标 | 结果 |
+|---|---:|
+| 输入数 |  |
+| 完成/拒绝/超时/过期 |  |
+| P50/P99推理时延 |  |
+| 任务质量 |  |
+| 峰值内存 |  |
+
+### 系统
+
+| 指标 | 结果 |
+|---|---:|
+| CPU占用 |  |
+| 平均/峰值功率 |  |
+| `E/inference` |  |
+| 温度/降频比例 |  |
+| 降级切换时间 |  |
+| 恢复时间 |  |
+
+## 6. 有效性判定
+
+- [ ] 配置与冻结说明一致；
+- [ ] 原始数据完整；
+- [ ] 无丢失且未解释的时间戳；
+- [ ] 测量设备正常；
+- [ ] 失败、超时和拒绝均已保存；
+- [ ] 无人为中断或未记录操作。
+
+运行判定：`VALID / INVALID / EXPLORATORY`
+
+原因：
+
+## 7. 异常与后续动作
+
+| 异常 | 初步原因 | 是否重跑 | 后续负责人 |
+|---|---|---|---|
+|  |  |  |  |

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/20-实验与验证/README.md

@@ -0,0 +1,22 @@
+# 20-实验与验证
+
+本层管理研究证据、冻结配置和逐次实验记录。
+
+## 方法文档
+
+1. [00-实验设计与验证方法.md](./00-实验设计与验证方法.md)：O0～O4对照、L0～L7负载、E0～E8实验和指标；
+2. [01-首个实验冻结说明.md](./01-首个实验冻结说明.md)：RK3588首个正式实验的冻结模板。
+
+## 实验模板
+
+3. [02-硬件软件版本清单模板.md](./02-硬件软件版本清单模板.md)：每个正式配置填写一次；
+4. [03-实验运行记录模板.md](./03-实验运行记录模板.md)：每次运行填写一次。
+
+## 使用原则
+
+- 先冻结配置，再运行正式实验；
+- 保存失败、拒绝、超时和异常；
+- 不用观测最大值替代理论WCET；
+- 不把不同推理后端的差异直接归因于操作系统。
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/00-基于现有设备的项目实施路线图.md

@@ -0,0 +1,129 @@
+# 基于现有设备的项目实施路线图
+
+## 1. 当前起点
+
+项目目前具备：
+
+- RK3588 16 GB工业盒，可作为SylixOS控制端SoC主样例；
+- 4×V100服务器，可承担训练、量化、转换和离线工具；
+- SylixOS/RealEvo研究基础；
+- RK3568/RK3576候选扩展路线；
+- 已形成六步离线联合编排与准入框架。
+
+当前关键缺口：
+
+- 现有工业盒BSP兼容性确认；
+- SylixOS下可用的小模型CPU运行时；
+- RK3588 NPU运行时和驱动准入；
+- 功耗与GPIO端到端测量设备；
+- 真正MCU开发板及对应SylixOS形态。
+
+## 2. 工作包
+
+### WP0：平台与版本冻结
+
+输出：硬件清单、设备编号、SylixOS/BSP/RealEvo版本、编译器、时间戳和测量链路。
+
+停止条件：BSP不能稳定启动、关键外设不可用或计时误差无法接受。
+
+### WP1：控制任务与基线
+
+在RK3588上实现1 ms控制任务、GPIO/CAN回环、看门狗和日志缓冲，形成无AI基线。
+
+输出：`control_tasks.yaml`、控制延迟数据、外部响应数据。
+
+### WP2：模型与离线工具
+
+在V100服务器完成模型训练/选择、INT8量化、算子图分析、Tensor Arena规划和代码生成。
+
+首个模型建议：振动或电流窗口上的1D CNN。
+
+输出：模型清单、算子数据库、静态内存布局和参考精度。
+
+### WP3：RK3588 CPU路径闭环
+
+先不依赖NPU，完成AI任务、固定优先级、静态Arena、有界队列、超时和规则兜底。
+
+输出：首个完整SylixOS参考工程和O0～O4对照数据。
+
+### WP4：干扰、故障与长稳
+
+增加CPU、内存、DMA、通信、突发输入、模型超时和任务崩溃；执行长稳和恢复实验。
+
+输出：可行负载区间、故障传播边界和恢复时间。
+
+### WP5：NPU条件扩展
+
+只有在RK3588 NPU驱动、运行时、模型转换和时间戳均通过准入后开展。
+
+输出：CPU与NPU路径的整栈对照，并区分RTOS收益和加速器收益。
+
+### WP6：控制端收缩
+
+把相同描述和生成工具迁移到RK3568/RK3576，收紧内存、功耗和启动预算。
+
+输出：跨BSP迁移工作量、预测误差和资源边界变化。
+
+### WP7：真正MCU实证
+
+完成选板、BSP、轻量运行时、功耗采样和控制外设准入，再复用任务描述和准入报告。
+
+输出：严格MCU级实证、第三篇论文候选和开发套件原型。
+
+## 3. 依赖关系
+
+```text
+WP0 → WP1 ─────────────┐
+  └→ WP2 → WP3 → WP4 ─┼→ WP6 → WP7
+                 └─────┘
+             WP5为条件扩展
+```
+
+不应让NPU适配阻塞CPU路径，也不应等待真正MCU采购后才开始工具链研究。
+
+## 4. 阶段验收
+
+| 阶段 | 验收标志 |
+|---|---|
+| M0 | 备份、目录重组和技术确认清单完成 |
+| M1 | RK3588 SylixOS控制任务基线可复现 |
+| M2 | 服务器端模型转换和静态内存报告完成 |
+| M3 | RK3588 CPU路径AI+控制闭环完成 |
+| M4 | O0～O4与L0～L7核心数据完成 |
+| M5 | RK3568/RK3576至少一档迁移成功 |
+| M6 | 真正MCU完成核心实验并形成论文数据 |
+
+## 5. 首批采购与确认优先级
+
+### 优先确认，不立即采购
+
+- 现有RK3588工业盒BSP；
+- SylixOS CPU小模型运行时；
+- RealEvo自动化接口；
+- 逻辑分析仪/示波器、功率计是否已有。
+
+### 首批可能需要补充
+
+- RK3568或RK3576官方/兼容开发板；
+- GPIO、CAN或电机回环负载；
+- 可同步采样的直流功率计；
+- 真正MCU候选板，但须在BSP确认后采购。
+
+## 6. 风险与替代路线
+
+| 风险 | 替代路线 |
+|---|---|
+| RK3588 NPU在SylixOS不可用 | CPU路径先完成方法验证，NPU列适配缺口 |
+| 现有工业盒与官方BSP不兼容 | 使用官方RK3588评估板或先在仿真/兼容板验证 |
+| RK3576 BSP不可用 | 跳过中间档，优先RK3568或RK3588限额 |
+| 真正MCU无法运行SylixOS | MCU使用轻量RTOS验证方法，SylixOS保留控制端SoC工程平台角色 |
+| 功耗仪器不足 | 先完成时间和内存实验，能耗标为未测而非估算 |
+| 模型不能满足窗口 | 缩小模型、降低周期或采用算子分段，并由准入报告记录限制 |
+
+## 7. 当前最小可行成果
+
+无需等待所有设备，当前即可完成的最小成果是：
+
+> 在RK3588与SylixOS上，以1 ms控制任务和INT8 1D CNN为样例，完成静态Arena、固定优先级、有界队列、超时与规则兜底，并证明离线联合编排相比普通后台部署能够更稳定地维持控制任务边界。
+
+这一成果能够同时验证问题定义、工具链、SylixOS集成和实验方法，是后续向RK3568和真正MCU扩展的共同基础。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/01-两周执行计划与验收清单.md

@@ -0,0 +1,134 @@
+# 两周执行计划与验收清单
+
+> 目标：用两周时间完成“平台能否开展实验”的判断，并形成RK3588控制基线与小模型准备结果。两周结束时不要求完成整篇论文，但必须减少关键不确定性。
+
+## 第1周：平台准入与任务冻结
+
+### D1：设备清点
+
+- [ ] 记录RK3588工业盒型号、接口、内存和存储；
+- [ ] 导出Ubuntu启动日志和设备树信息；
+- [ ] 确认GPIO、CAN、RS485和网络可用性；
+- [ ] 清点逻辑分析仪、示波器和功率计；
+- [ ] 填写硬件软件版本清单初稿。
+
+验收物：硬件清单、设备照片、接口表。
+
+### D2：翼辉技术确认材料
+
+- [ ] 完成会议提纲；
+- [ ] 整理工业盒资料；
+- [ ] 整理首个实验和模型算子清单；
+- [ ] 向翼辉发送问题；
+- [ ] 确定会议时间和双方接口人。
+
+验收物：已发送的会议材料。
+
+### D3：控制任务设计
+
+- [ ] 冻结1 ms周期和1 ms截止期；
+- [ ] 设计确定性任务体；
+- [ ] 设计GPIO或CAN回环；
+- [ ] 设计预分配日志缓冲；
+- [ ] 定义释放、开始、完成时间戳。
+
+验收物：控制任务说明和数据字段。
+
+### D4：模型与数据选择
+
+- [ ] 选择振动、电流或公开轴承数据；
+- [ ] 定义输入窗口与类别；
+- [ ] 建立小型1D CNN；
+- [ ] 固定训练/验证划分；
+- [ ] 确定Accuracy/F1阈值。
+
+验收物：数据说明、模型结构和质量基线。
+
+### D5：SylixOS路径结论
+
+- [ ] 召开翼辉会议；
+- [ ] 冻结推荐SylixOS/BSP/RealEvo版本；
+- [ ] 判断现有工业盒兼容性；
+- [ ] 明确CPU推理路径；
+- [ ] 将NPU标记为可用、需适配或暂缓。
+
+验收物：会议纪要和责任表。
+
+## 第2周：基线和离线工具准备
+
+### D6：开发环境
+
+- [ ] 安装RealEvo与工具链；
+- [ ] 获取或创建BSP/App工程；
+- [ ] 完成Hello World、定时器和GPIO测试；
+- [ ] 记录构建与部署步骤；
+- [ ] 冻结Git提交和版本。
+
+验收物：可重复构建的最小工程。
+
+### D7：控制基线程序
+
+- [ ] 实现周期任务；
+- [ ] 实现时间戳记录；
+- [ ] 实现内存缓冲日志；
+- [ ] 实现截止期判定；
+- [ ] 实现GPIO/CAN回环。
+
+验收物：控制程序和原始数据样例。
+
+### D8：模型量化与转换
+
+- [ ] 训练或取得模型；
+- [ ] 完成INT8量化；
+- [ ] 导出固定格式；
+- [ ] 统计算子、权重和中间张量；
+- [ ] 比较FP32与INT8质量。
+
+验收物：模型文件、校验值和量化报告。
+
+### D9：静态资源报告
+
+- [ ] 生成模型算子清单；
+- [ ] 计算权重、Arena和工作区；
+- [ ] 给出CPU推理时间初测；
+- [ ] 形成首版任务与模型描述；
+- [ ] 给出是否可进入板端的初步判定。
+
+验收物：资源预算与准入报告v0.1。
+
+### D10：复核与下一阶段冻结
+
+- [ ] 控制基线至少独立运行5次；
+- [ ] 保存样本数、分位数、最大值和违约数；
+- [ ] 检查所有版本和配置记录；
+- [ ] 更新首个实验冻结说明；
+- [ ] 决定是否进入AI板端接入阶段。
+
+验收物：两周总结和下一阶段Go/No-Go结论。
+
+## 两周结束验收表
+
+| 项目 | 必须完成 | 状态 |
+|---|---|---|
+| RK3588硬件与接口清单 | 是 |  |
+| 翼辉技术确认会议 | 是 |  |
+| SylixOS/BSP/RealEvo版本结论 | 是 |  |
+| 1 ms控制任务设计 | 是 |  |
+| 控制基线程序或明确阻塞项 | 是 |  |
+| INT8 1D CNN模型 | 是 |  |
+| 模型质量与资源报告 | 是 |  |
+| CPU推理路径结论 | 是 |  |
+| NPU路径结论 | 可标记暂缓 |  |
+| 下一阶段Go/No-Go | 是 |  |
+
+## Go/No-Go规则
+
+满足以下条件进入板端AI接入：
+
+- BSP稳定；
+- 控制任务基线可信；
+- CPU小模型可执行；
+- 静态内存预算未超限；
+- 计时和日志链路可用。
+
+任一核心条件不满足时，输出阻塞项和责任人，不通过降低测量标准强行进入正式实验。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/30-实施管理/README.md

@@ -0,0 +1,17 @@
+# 30-实施管理
+
+本层回答“使用现有设备如何开工、依赖是什么、什么时候Go/No-Go”。
+
+## 文件
+
+1. [00-基于现有设备的项目实施路线图.md](./00-基于现有设备的项目实施路线图.md)：WP0～WP7、设备依赖、里程碑和风险替代路线；
+2. [01-两周执行计划与验收清单.md](./01-两周执行计划与验收清单.md)：D1～D10执行清单与阶段验收。
+
+## 当前第一优先级
+
+1. 确认RK3588工业盒的SylixOS BSP；
+2. 跑通1 ms控制任务基线；
+3. 在V100侧完成INT8 1D CNN和资源报告；
+4. 不等待NPU，先完成CPU推理路径。
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/00-合作方式与产业落点.md

@@ -0,0 +1,96 @@
+# 合作方式与产业落点
+
+## 1. 合作结构
+
+本子课题适合采用“研究团队 + 翼辉信息 + 芯片/板卡厂商 + 场景方”的四方结构。
+
+| 参与方 | 主要职责 |
+|---|---|
+| 研究团队 | 问题定义、编排算法、实验设计、数据分析和论文 |
+| 翼辉信息 | SylixOS/RealEvo、BSP、调度与内存接口、工程验证 |
+| 芯片/板卡厂商 | 算子库、SDK、驱动、周期/功耗数据和硬件样机 |
+| 场景方 | 控制任务、传感器数据、安全规则和验收约束 |
+
+## 2. 与翼辉信息的合作重点
+
+### 2.1 平台准入
+
+- 确认现有RK3588工业盒与官方BSP的兼容性；
+- 确认RK3568、RK3576和真正MCU候选平台；
+- 冻结SylixOS、BSP、编译器和RealEvo版本；
+- 明确CPU、NPU、DMA、CAN、GPIO和看门狗支持边界。
+
+### 2.2 实时机制
+
+- 固定优先级、RMS和周期任务配置；
+- 核绑定、中断亲和性和大小核调度；
+- 静态内存、链接段和DMA连续内存；
+- Cache一致性、任务/进程恢复和看门狗；
+- 高精度时间戳与性能追踪。
+
+### 2.3 工具链接口
+
+- 外部编排器生成SylixOS App工程的方式；
+- 链接脚本、任务配置和静态数组注入；
+- RealEvo自动构建、上传、调试和数据回收；
+- 生成代码与BSP版本兼容检查；
+- 部署准入报告的联合格式。
+
+## 3. 与芯片厂商的合作重点
+
+- 算子支持矩阵和优化内核；
+- 每个算子的工作区、周期和能耗数据；
+- SRAM Bank、Cache、DMA和中断结构；
+- 模型转换、代码生成和SDK接口；
+- 低功耗状态、唤醒时间和功耗测量；
+- 芯片规格与AI任务需求的反向协同。
+
+## 4. 建议合作步骤
+
+1. 完成现有设备、BSP和工具链盘点；
+2. 选择一个电机状态识别或工业节点场景；
+3. 在RK3588上完成CPU路径最小原型；
+4. 接入SylixOS静态任务、超时和规则兜底；
+5. 在NPU运行时准入后增加异构路径；
+6. 向RK3568/RK3576收缩；
+7. 共同选择真正MCU平台；
+8. 形成参考工程、工具、样机和论文。
+
+## 5. 产业落点
+
+### 5.1 SylixOS静态智能任务开发套件
+
+面向工业控制设备开发者，提供模型转换、资源预算、代码生成、部署检查和板端验证。
+
+### 5.2 智能控制器升级方案
+
+在不破坏原有控制和安全规则的前提下，为电机、泵、阀、PLC外围节点和设备控制盒增加异常识别与状态分类。
+
+### 5.3 芯片适配与选型服务
+
+用模型、控制任务和资源预算反向评估芯片、内存和加速器是否适合目标设备。
+
+### 5.4 AI进入任务关键系统的准入规范
+
+形成可复用的资源、时间、质量、故障和恢复检查表，而不只交付单个模型Demo。
+
+## 6. 合作边界
+
+- BSP或驱动未确认前，不承诺具体加速器性能；
+- 不把SylixOS认证范围自动扩展到AI模型和完整应用；
+- 不把模型平均速度当作实时安全证据；
+- 不把场景方未确认的规则写成安全策略；
+- 联合研究数据需冻结版本、设备编号和测量边界。
+
+## 7. 首次技术会议建议清单
+
+1. RK3588现有工业盒可复用的BSP；
+2. RK3588/RK3568的核绑定和中断接口；
+3. NPU运行时与驱动的可用状态；
+4. 静态链接布局和内存域能力；
+5. 看门狗、任务重启和局部恢复路径；
+6. RealEvo外部生成工程接口；
+7. lite/tiny目标和真正MCU支持清单；
+8. 可开放的追踪、功耗和算子数据；
+9. 联合参考板与首个工业场景；
+10. 论文、白皮书、工具和知识产权分工。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/01-翼辉技术确认会议提纲.md

@@ -0,0 +1,125 @@
+# 翼辉技术确认会议提纲
+
+> 会议目标：确认现有 RK3588 工业盒能否进入 SylixOS 实验，冻结首期 BSP、开发工具、运行时和测量接口，明确需要翼辉支持的工作。
+
+## 1. 会前材料
+
+- [ ] RK3588 工业盒型号、主板照片和硬件规格；
+- [ ] CPU、内存、eMMC、网络、CAN、RS485、GPIO清单；
+- [ ] 当前 Ubuntu 版本、设备树和启动日志；
+- [ ] 拟运行的1 ms控制任务说明；
+- [ ] INT8 1D CNN模型与算子清单；
+- [ ] 预期对照实验和指标；
+- [ ] 本会议问题清单提前发送给翼辉。
+
+## 2. 项目说明
+
+本项目拟研究：
+
+> 在 SylixOS 控制系统中，通过静态内存、固定优先级、固定推理窗口、部署准入和规则兜底，使轻量AI任务进入系统后不破坏关键控制任务的时间边界。
+
+首期实验不依赖大模型，也不把NPU作为启动前提。计划先完成：
+
+- RK3588 + SylixOS；
+- 1 ms周期控制任务；
+- CPU执行的INT8 1D CNN；
+- 控制与AI共存；
+- 超时、过载、故障和规则兜底。
+
+## 3. 必须确认的问题
+
+### 3.1 板卡与BSP
+
+1. 现有工业盒是否兼容翼辉官方RK3588 BSP？
+2. 如果不完全兼容，需要提供哪些原理图、设备树和启动信息？
+3. 推荐使用哪个SylixOS版本、BSP版本和RealEvo版本？
+4. 当前BSP支持哪些CPU核、定时器、GPIO、CAN、RS485、网口、eMMC和NVMe？
+5. 是否支持SMP和大小核调度？
+6. BSP移植工作由哪一方负责，预计交付物是什么？
+
+### 3.2 调度与计时
+
+1. 周期任务推荐使用哪类定时器和任务接口？
+2. 是否支持固定优先级、RMS和CPU亲和性？
+3. 是否支持将控制任务固定到指定CPU核？
+4. 是否支持中断亲和性或中断线程化？
+5. 高精度单调时钟的分辨率和读取开销是多少？
+6. 推荐如何记录任务释放、开始、完成和截止期违约？
+
+### 3.3 内存、Cache与DMA
+
+1. 如何在BSP或链接脚本中划分控制区、AI区和DMA区？
+2. 是否可为应用设置固定内存上限或独立内存区域？
+3. DMA连续内存如何申请和释放？
+4. Cache刷新、失效和一致性维护使用什么接口？
+5. 是否可以避免正式运行阶段的动态内存分配？
+6. 是否有内存峰值、碎片和泄漏监测工具？
+
+### 3.4 推理运行时
+
+1. SylixOS下是否已有可用的小模型CPU推理运行时？
+2. 是否支持TFLite Micro、ONNX Runtime裁剪版或翼辉自有方案？
+3. RK3588 NPU驱动是否可用？
+4. RKNN/RKLLM模型转换和运行时能否在SylixOS下工作？
+5. NPU提交、完成中断、DMA和统一内存路径是否可观测？
+6. 若NPU不可用，翼辉是否认可先完成CPU路径研究？
+
+### 3.5 故障处理
+
+1. RK3588看门狗在SylixOS中的推荐使用方式是什么？
+2. AI线程卡死后能否只重启线程或进程？
+3. 驱动异常是否可能影响关键控制任务？
+4. 如何记录任务异常、看门狗、重启和恢复事件？
+5. 是否有推荐的安全降级或双任务监控模式？
+
+### 3.6 RealEvo与自动化
+
+1. 外部工具能否生成或修改SylixOS App工程？
+2. 是否有命令行编译、部署和调试接口？
+3. 链接脚本、静态数组和任务配置如何自动注入？
+4. 是否支持批量运行测试和回收日志？
+5. 性能分析、代码覆盖率和远程调试工具如何使用？
+
+### 3.7 真正MCU路线
+
+1. 是否存在SylixOS lite/tiny产品形态？
+2. 支持哪些真正MCU或无MMU目标？
+3. 最小Flash、RAM和启动时间是多少？
+4. 推荐哪块参考板开展MCU实证？
+5. 是否有TinyML或轻量推理参考工程？
+
+## 4. 希望翼辉提供的材料
+
+- [ ] 推荐BSP与版本；
+- [ ] 板卡兼容性判断；
+- [ ] RealEvo安装包和开发文档；
+- [ ] 周期任务、核绑定和高精度计时样例；
+- [ ] DMA、Cache和静态链接布局样例；
+- [ ] 看门狗和任务恢复样例；
+- [ ] CPU推理运行时或移植建议；
+- [ ] NPU支持状态说明；
+- [ ] 真正MCU候选平台清单；
+- [ ] 技术接口人与问题跟踪方式。
+
+## 5. 会议输出
+
+| 决策项 | 结论 | 责任方 | 完成时间 | 证据/链接 |
+|---|---|---|---|---|
+| RK3588 BSP | 待确认 |  |  |  |
+| SylixOS/RealEvo版本 | 待确认 |  |  |  |
+| CPU推理路径 | 待确认 |  |  |  |
+| NPU路径 | 待确认 |  |  |  |
+| 调度和计时接口 | 待确认 |  |  |  |
+| 内存和DMA接口 | 待确认 |  |  |  |
+| 故障恢复接口 | 待确认 |  |  |  |
+| 真正MCU候选 | 待确认 |  |  |  |
+
+## 6. 会议结束判据
+
+会议结束时至少应得到：
+
+1. RK3588能否进入SylixOS实验的明确结论；
+2. 一个冻结的软件版本组合；
+3. 一个CPU推理可行路径；
+4. NPU路径是“可用、需适配或暂缓”的结论；
+5. 双方责任人和下一次检查节点。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/02-预期成果与论文方向.md

@@ -0,0 +1,95 @@
+# 预期成果与论文方向
+
+## 1. 方法成果
+
+1. 面向 MCU / 控制端的静态智能控制问题定义；
+2. 控制任务、模型和平台的统一描述方法；
+3. 小模型与控制任务离线联合编排方法；
+4. 静态内存、固定推理窗口和有界通信设计；
+5. 部署前资源、可调度性和安全准入方法；
+6. 规则兜底、异常切换与恢复方法。
+
+## 2. 工具与软件成果
+
+- 模型解析、量化和算子合法化工具；
+- 目标板算子执行时间与资源数据库；
+- Tensor Arena与链接布局生成器；
+- 控制任务与AI任务联合调度分析器；
+- SylixOS C/C++任务包装与配置生成器；
+- `PASS / PASS WITH LIMITS / REJECT`部署报告生成器；
+- 板端采样、故障注入和数据汇总工具。
+
+## 3. 原型与数据成果
+
+### 原型A：RK3588 + SylixOS方法原型
+
+完成控制任务、CPU小模型、静态Arena、固定窗口、超时和规则兜底的完整闭环。
+
+### 原型B：控制端收缩原型
+
+在RK3568/RK3576或等价平台上复现，并量化内存、功耗和BSP迁移成本。
+
+### 原型C：真正MCU验证样机
+
+完成KB/MB级内存、快速启动、`E/inference`和控制截止期验证。
+
+### 数据集
+
+- 控制任务时间序列；
+- 算子和完整模型执行时间；
+- 内存峰值与碎片；
+- 功耗、温度和启动数据；
+- 超时、过载、降级和恢复事件；
+- 预测值与实测值误差。
+
+## 4. 论文组织建议
+
+不建议把所有设备和工具链塞入一篇论文。建议拆成三类成果。
+
+### 论文1：静态联合编排方法
+
+核心问题：模型和控制任务如何在部署前共同完成内存、时间和准入分析。
+
+主要贡献：统一描述、静态内存规划、时间编排和预测—实测校准。
+
+### 论文2：SylixOS控制端共存与故障隔离
+
+核心问题：AI进入控制端后，SylixOS如何维持关键任务边界并限制故障传播。
+
+主要贡献：固定优先级、核绑定、中断/DMA干扰、规则兜底和恢复实证。
+
+### 论文3：真正MCU上的低功耗静态智能控制
+
+核心问题：在极小SRAM、Flash和功耗预算下，静态智能任务的成立边界是什么。
+
+主要贡献：内存极限、快速启动、`E/inference`和跨设备迁移。
+
+## 5. 可使用的学术方向表述
+
+- TinyML / Edge AI on MCU；
+- 低功耗嵌入式智能系统；
+- 静态部署与工具链协同；
+- 实时控制中的小模型纳入；
+- AI workload admission for real-time systems；
+- predictable embedded inference；
+- safety fallback for intelligent control。
+
+## 6. 产业交付物
+
+- 面向芯片与板卡的AI任务准入规范；
+- SylixOS静态智能任务开发模板；
+- 面向设备厂商的部署检查工具；
+- 电机/泵/工业节点参考样机；
+- 联合白皮书和基准测试报告；
+- 芯片选型与模型适配矩阵。
+
+## 7. 成果成熟度阶梯
+
+| 阶段 | 可对外表述 |
+|---|---|
+| 仅RK3588方法原型 | 控制端SoC上的静态编排方法验证 |
+| 增加RK3568/RK3576 | 跨控制端平台的迁移与收缩验证 |
+| 增加真正MCU | 面向MCU的静态智能控制实证 |
+| 形成工具和样机 | 可部署的开发套件与产业方案 |
+
+在真正MCU实验完成前，不将SoC结果表述为MCU极限结论。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/40-合作与成果/README.md

@@ -0,0 +1,17 @@
+# 40-合作与成果
+
+本层管理联合研究分工、翼辉技术确认和成果组织。
+
+## 文件
+
+1. [00-合作方式与产业落点.md](./00-合作方式与产业落点.md)：研究团队、翼辉、芯片厂商和场景方分工；
+2. [01-翼辉技术确认会议提纲.md](./01-翼辉技术确认会议提纲.md)：第一次技术会议的问题、材料和输出模板；
+3. [02-预期成果与论文方向.md](./02-预期成果与论文方向.md)：方法、工具、原型、数据、论文和产业交付物。
+
+## 合作原则
+
+- BSP或驱动未确认前，不承诺具体加速器性能；
+- 不把SylixOS认证范围自动扩展到AI模型和完整应用；
+- 联合数据必须冻结版本、设备编号和测量边界。
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/20-子课题A-面向MCU的静态智能控制基础系统/README.md

@@ -0,0 +1,83 @@
+# 子课题A：面向MCU的静态智能控制基础系统
+
+本目录按“研究定义—技术框架—实验验证—实施管理—合作成果”分层管理，目标是把MCU研究方向落到现有RK3588、4×V100、SylixOS/RealEvo及后续控制端板卡上。
+
+## 一句话定位
+
+> 把轻量智能模型转换为具有固定资源上限、固定执行窗口和明确故障处理方式的实时任务，并在部署前判断其能否安全进入SylixOS控制系统。
+
+## 目录结构
+
+```text
+子课题A
+├─ 00-总览与定位       研究对象、边界、问题和适用场景
+├─ 10-技术框架         总体技术路线与六步离线联合编排
+├─ 20-实验与验证       实验设计、冻结单和运行记录模板
+├─ 30-实施管理         设备路线图、工作包和两周计划
+├─ 40-合作与成果       翼辉合作、技术确认和成果组织
+└─ README.md           总导航
+```
+
+## 分层入口
+
+### 00-总览与定位
+
+- [子课题定义](./00-总览与定位/00-子课题定义.md)
+- [研究问题与适用场景](./00-总览与定位/01-研究问题与适用场景.md)
+
+### 10-技术框架
+
+- [总体技术路线](./10-技术框架/00-总体技术路线.md)
+- [离线联合编排研究框架](./10-技术框架/01-离线联合编排研究框架.md)
+
+### 20-实验与验证
+
+- [实验设计与验证方法](./20-实验与验证/00-实验设计与验证方法.md)
+- [首个实验冻结说明](./20-实验与验证/01-首个实验冻结说明.md)
+- [硬件软件版本清单模板](./20-实验与验证/02-硬件软件版本清单模板.md)
+- [实验运行记录模板](./20-实验与验证/03-实验运行记录模板.md)
+
+### 30-实施管理
+
+- [基于现有设备的项目实施路线图](./30-实施管理/00-基于现有设备的项目实施路线图.md)
+- [两周执行计划与验收清单](./30-实施管理/01-两周执行计划与验收清单.md)
+
+### 40-合作与成果
+
+- [合作方式与产业落点](./40-合作与成果/00-合作方式与产业落点.md)
+- [翼辉技术确认会议提纲](./40-合作与成果/01-翼辉技术确认会议提纲.md)
+- [预期成果与论文方向](./40-合作与成果/02-预期成果与论文方向.md)
+
+## 推荐阅读路线
+
+### 理解研究框架
+
+`00-总览与定位` → `10-技术框架` → `20-实验与验证/00-实验设计与验证方法.md`
+
+### 立即启动项目
+
+`30-实施管理/01-两周执行计划与验收清单.md` → `40-合作与成果/01-翼辉技术确认会议提纲.md` → `20-实验与验证/01-首个实验冻结说明.md`
+
+### 执行正式实验
+
+`20-实验与验证/02-硬件软件版本清单模板.md` → `20-实验与验证/03-实验运行记录模板.md`
+
+## 当前设备边界
+
+- RK3588是控制端SoC方法原型，不是真正MCU；
+- 4×V100用于模型训练、量化和离线工具；
+- RK3568/RK3576用于控制端收缩和跨BSP验证；
+- 严格MCU结论需要真正MCU实验板及对应BSP/运行时。
+
+## 当前最小可行实验
+
+- 平台：RK3588工业盒；
+- 系统：SylixOS；
+- 控制任务：1 ms周期任务与GPIO/CAN回环；
+- AI任务：INT8 1D CNN状态识别；
+- 机制：静态Arena、固定优先级、有界队列、超时和规则兜底；
+- 目标：验证静态联合编排能否在AI负载下维持控制边界。
+
+## 备份说明
+
+本目录重组前的快照位于同级目录：`90-备份-子课题A-重组前-20260924`。备份仅用于回溯，不参与当前阅读和实验流程。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/00-子课题定义.md

@@ -0,0 +1,27 @@
+# 子课题定义
+
+## 1. 子课题名称
+
+面向边侧 SoC 的混合实时控制基础系统
+
+## 2. 子课题主问题
+
+本子课题围绕以下问题展开：
+
+> **在边侧 SoC 与设备端异构平台上，Linux、RTOS、Hypervisor、Hybrid 结构、统一内存和异构协处理器如何共同维持控制路径与推理路径的整体实时边界。**
+
+## 3. 子课题边界
+
+本子课题重点聚焦：
+
+- Linux 与 RTOS 的分工；
+- Hypervisor 与隔离机制；
+- Hybrid 升级为协同治理结构；
+- 统一内存、总线、DMA、NPU/GPU 竞争；
+- 规则兜底与闭环安全边界。
+
+本子课题不以极小资源 MCU 的静态部署问题为主战场。
+
+## 4. 在总课题中的位置
+
+这是框架2中的第二个子课题，重点对应 `T4/T3`，也是总课题中最能体现混合结构、系统协同和边侧 SoC 真实工程复杂度的方向。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/01-研究问题与适用场景.md

@@ -0,0 +1,29 @@
+# 研究问题与适用场景
+
+## 1. 研究问题
+
+本子课题重点回答四个问题：
+
+1. Linux 与 RTOS 如何在同一 SoC 上分工；
+2. Hypervisor 与 Hybrid 结构如何提升整体可治理性；
+3. 统一内存、总线、DMA 与 NPU/GPU 竞争如何进入系统分析；
+4. 规则兜底与异常切换如何把混合系统闭合成可验证的控制系统。
+
+## 2. 适用场景
+
+典型场景包括：
+
+- 设备端 SoC；
+- 工业边缘节点；
+- 车载或机器人边侧平台；
+- 同时承载控制与 AI 推理的异构系统。
+
+## 3. 与总课题共享层的衔接
+
+本子课题主要继承共享层中的：
+
+- `系统协同域`
+- `规则兜底与控制闭环`
+- `基础设备与算力基础` 中的 `T4/T3` 部分
+
+同时结合 `RTOS 直接控制域` 和 `推理运行域` 形成整体边界分析。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/README.md

@@ -0,0 +1,18 @@
+# 00-总览与定位
+
+本层回答“子课题B研究什么、为什么研究、适用于哪些边侧SoC场景”。
+
+## 文件
+
+1. [00-子课题定义.md](./00-子课题定义.md)：研究对象、核心目标和方向边界；
+2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md)：关键问题、应用场景和系统约束。
+
+## 阅读结果
+
+读完本层应能够明确：
+
+- 子课题B与子课题A在资源规模和部署形态上的区别；
+- Linux、RTOS、Hypervisor和Hybrid结构分别解决什么问题；
+- 哪些实时控制职责必须留在确定性执行域中。
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/10-技术框架/00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md

@@ -0,0 +1,77 @@
+# SoC路线：Hybrid与Hypervisor协同
+
+## 1. 主题定位
+
+SoC 路线是框架2的核心主战场。这里最直接体现会议中的判断：人工智能进入实时控制系统后，最现实的结构不是让 RTOS 独自承接一切，而是让 Linux、RTOS、Hypervisor 与异构协处理器形成可治理的混合基础系统。
+
+## 2. 为什么 SoC 路线最关键
+
+设备端 SoC 同时具有以下特征：
+
+- 需要 Linux 承接 AI 生态和推理框架；
+- 需要 RTOS 承接关键控制与执行闭环；
+- 统一内存和异构协处理器使资源竞争非常明显；
+- 设备级散热、功耗和体积限制比服务器更刚性；
+- 更接近真实产业落地场景。
+
+因此，SoC 路线最能体现“基础系统主语”。
+
+## 3. Hybrid 结构为什么仍然重要
+
+会议并没有否定 Hybrid，反而强调它是当前最现实的路径之一。  
+Hybrid 的现实价值在于：
+
+- 保留 Linux 的推理生态；
+- 保留 RTOS 的控制与保障能力；
+- 让 AI 目标负载与关键保障负载可以在不同控制层上运行；
+- 为后续 Hypervisor 和资源治理留出结构空间。
+
+但框架2不再接受“传统 Hybrid 只求共存”的写法，而要求把它升级为协同治理结构。
+
+## 4. Hypervisor 在 SoC 路线中的角色
+
+Hypervisor 使 SoC 路线从“双系统并置”走向“可治理混合系统”。它重点承担：
+
+- 核心与资源切分；
+- 中断与设备访问边界控制；
+- 共享内存与通信路径组织；
+- 异常隔离与恢复。
+
+如果没有 Hypervisor 或等价机制，很多 SoC 路线的协同边界很难稳定复现。
+
+## 5. 核心研究问题
+
+### 5.1 推理与控制如何分层
+
+后续研究需要回答：
+
+- 哪些 AI 任务保留在 Linux 侧；
+- 哪些控制任务保留在 RTOS 侧；
+- 控制与推理之间通过什么接口通信；
+- 在延迟、异常和过载条件下如何切换策略。
+
+### 5.2 统一内存与总线竞争如何治理
+
+SoC 路线中最容易被低估的问题包括：
+
+- CPU 与 NPU/GPU 的统一内存争抢；
+- DMA 传输对控制路径的污染；
+- 模型加载与设备 I/O 共享带宽；
+- 缓存与总线冲突对尾延迟的影响。
+
+这部分是 SoC 路线区别于纯 RTOS 叙事的关键证据。
+
+### 5.3 设备级受限条件如何影响系统边界
+
+SoC 路线必须同时面对：
+
+- 功耗预算；
+- 散热与封装条件；
+- 设备体积与部署空间；
+- 软件栈和驱动闭源限制。
+
+因此，它天然也是框架2中“小型化与低功耗”方向最强的承载层。
+
+## 6. 当前结论
+
+> **SoC 路线不是 RTOS 课题的附属场景，而是“面向 AI 的实时控制基础系统”最能成立、也最值得展开的核心研究窗口。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/10-技术框架/README.md

@@ -0,0 +1,16 @@
+# 10-技术框架
+
+本层回答“边侧SoC上的混合实时控制基础系统如何划分运行域、隔离资源并完成跨域协同”。
+
+## 文件
+
+1. [00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md](./00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md)：四类系统形态、异构资源治理和技术路线。
+
+## 后续重点
+
+- 控制域与推理域的CPU核、内存和中断隔离；
+- 跨域通信的时延上界和故障传播边界；
+- NPU/GPU/DMA共享资源对控制任务尾时延的影响；
+- 推理超时、服务失效和系统异常时的规则接管。
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/00-实验设计与验证方法.md

@@ -0,0 +1,29 @@
+# 实验设计与验证方法
+
+## 1. 验证重点
+
+本子课题的验证重点包括：
+
+- Linux / RTOS 分工是否稳定；
+- Hypervisor 隔离是否有效；
+- 统一内存、总线与 DMA 竞争是否可观测、可治理；
+- 规则兜底与异常切换是否能保护关键保障负载边界。
+
+## 2. 典型实验单元
+
+适合优先组织：
+
+1. Linux 与 RTOS 双域并存实验；
+2. Hypervisor 隔离与无隔离结构对比；
+3. 统一内存、DMA 与总线竞争实验；
+4. 模型输出、规则兜底与异常切换实验；
+5. 长稳、热状态与恢复实验。
+
+## 3. 指标重点
+
+- `TTFT`
+- `TPOT`
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 资源隔离效果
+- 温度、热漂移与恢复时间

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/README.md

@@ -0,0 +1,17 @@
+# 20-实验与验证
+
+本层管理子课题B的实验设计、对照系统、混合负载和验证证据。
+
+## 文件
+
+1. [00-实验设计与验证方法.md](./00-实验设计与验证方法.md)：当前实验设计与指标骨架。
+
+## 后续需要补充
+
+- 设备与软件版本清单；
+- 首个共存实验冻结说明；
+- 每次实验运行记录；
+- 资源争用和故障注入记录；
+- Linux、RTOS、Hypervisor及Hybrid方案的统一对照表。
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/30-实施管理/README.md

@@ -0,0 +1,13 @@
+# 30-实施管理
+
+本层用于管理设备路线、工作包、依赖条件、阶段计划和Go/No-Go判据。
+
+当前尚未形成独立实施文档。正式开工前应补齐：
+
+1. T4/T3具体设备、芯片和外设清单；
+2. Linux、RTOS、Hypervisor及驱动可用能力；
+3. 推理后端与异构加速器支持情况；
+4. 首个共存实验的固定硬件与软件组合；
+5. 两周或月度执行计划与验收清单。
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/00-合作方式与产业落点.md

@@ -0,0 +1,29 @@
+# 合作方式与产业落点
+
+## 1. 合作重点
+
+本子课题更适合围绕以下合作对象展开：
+
+- SoC / 板级平台厂商；
+- Hypervisor / mixed-criticality 基础软件团队；
+- 工业边缘和机器人设备团队；
+- 同时承载 AI 与控制任务的行业客户。
+
+## 2. 合作方式
+
+建议采用：
+
+1. 平台条件与资源结构梳理；
+2. Linux / RTOS / Hypervisor 分工设计；
+3. 板级实验与隔离验证；
+4. 规则兜底和闭环安全验证；
+5. 系统协同证据沉淀。
+
+## 3. 产业落点
+
+这一子课题更容易落到：
+
+- 边侧 SoC 参考架构；
+- 混合基础系统方案；
+- Hypervisor 协同部署方法；
+- 设备端 AI + 控制一体化平台路线。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/01-预期成果与论文方向.md

@@ -0,0 +1,19 @@
+# 预期成果与论文方向
+
+## 1. 预期成果
+
+本子课题预期形成：
+
+1. 面向边侧 SoC 的混合基础系统问题定义；
+2. Linux / RTOS / Hypervisor / Hybrid 协同结构说明；
+3. 统一内存与资源竞争治理证据；
+4. 规则兜底、异常切换与控制闭环验证材料。
+
+## 2. 论文方向
+
+可对应的论文方向包括：
+
+- Mixed-criticality embedded systems
+- Hypervisor / partitioned real-time systems
+- Edge AI system co-design
+- Linux + RTOS 协同结构与实时边界

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/40-合作与成果/README.md

@@ -0,0 +1,16 @@
+# 40-合作与成果
+
+本层管理联合研究分工、产业落点、工程交付物和论文成果。
+
+## 文件
+
+1. [00-合作方式与产业落点.md](./00-合作方式与产业落点.md)：合作对象、分工方式和产业结合点；
+2. [01-预期成果与论文方向.md](./01-预期成果与论文方向.md)：方法、系统、实验和论文成果。
+
+## 使用原则
+
+- 合作承诺以具体BSP、虚拟化能力和加速器支持情况为依据；
+- 论文结论必须对应冻结的平台、负载和系统形态；
+- 工程成果与学术贡献分别描述，但共享同一套实验数据和版本记录。
+
+[返回总目录](../README.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md

@@ -0,0 +1,65 @@
+# 子课题B：面向边侧SoC的混合实时控制基础系统
+
+本目录按“研究定义—技术框架—实验验证—实施管理—合作成果”分层管理，与子课题A保持一致的文档骨架。
+
+## 一句话定位
+
+> 在边侧异构SoC上，研究Linux、RTOS、Hypervisor和Hybrid系统如何通过资源隔离、跨域协同及故障兜底维持实时控制边界。
+
+## 目录结构
+
+```text
+子课题B
+├─ 00-总览与定位       研究对象、边界、问题和适用场景
+├─ 10-技术框架         系统形态、资源治理和协同机制
+├─ 20-实验与验证       对照系统、混合负载和评价指标
+├─ 30-实施管理         设备路线、工作计划和验收材料
+├─ 40-合作与成果       联合研究、产业落点和论文成果
+└─ README.md           总导航
+```
+
+## 分层入口
+
+### 00-总览与定位
+
+- [子课题定义](./00-总览与定位/00-子课题定义.md)
+- [研究问题与适用场景](./00-总览与定位/01-研究问题与适用场景.md)
+
+### 10-技术框架
+
+- [Linux-RTOS-Hypervisor-Hybrid技术路线](./10-技术框架/00-技术路线：Linux-RTOS-Hypervisor-Hybrid.md)
+
+### 20-实验与验证
+
+- [实验设计与验证方法](./20-实验与验证/00-实验设计与验证方法.md)
+
+### 30-实施管理
+
+- [实施管理说明](./30-实施管理/README.md)
+
+### 40-合作与成果
+
+- [合作方式与产业落点](./40-合作与成果/00-合作方式与产业落点.md)
+- [预期成果与论文方向](./40-合作与成果/01-预期成果与论文方向.md)
+
+## 推荐阅读路线
+
+### 理解研究框架
+
+`00-总览与定位` → `10-技术框架` → `20-实验与验证`
+
+### 准备实施
+
+`30-实施管理` → 确认T4/T3设备与系统组合 → 冻结首个共存实验
+
+### 组织合作与成果
+
+`40-合作与成果/00-合作方式与产业落点.md` → `40-合作与成果/01-预期成果与论文方向.md`
+
+## 当前成熟度
+
+研究定义、技术路线、实验方法和成果骨架已经形成。设备实施路线、版本清单、实验冻结单及运行记录模板，需要在具体SoC、RTOS、Linux和Hypervisor组合确认后继续补充。
+
+## 备份说明
+
+本目录重组前的快照位于同级目录：`90-备份-子课题B-重组前-20260924`。备份仅用于回溯，不参与当前阅读和实验流程。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/01-统一实验设计与验证骨架.md

@@ -0,0 +1,119 @@
+# 面向AI的实时控制基础系统实验设计
+
+## 1. 实验目标
+
+框架2的实验目标不是单纯比较“RTOS 比 Linux 快多少”，而是比较在人工智能目标负载进入实时控制系统后，不同基础系统结构能否同时维持：
+
+1. **人工智能目标负载的时效性与功能有效性**
+2. **关键保障负载的时间边界**
+3. **系统协同层的资源秩序、恢复能力与解释性**
+
+## 2. 研究问题
+
+| 编号 | 研究问题 | 核心观察量 |
+|---|---|---|
+| `RQ1` | RTOS 直接控制域在 AI 目标负载进入后还能维持多强的关键保障边界 | `deadline miss ratio`、`P99/P99.9 jitter`、外部接口响应 |
+| `RQ2` | 推理运行域的模型、量化、框架和内存组织如何改变整体系统边界 | `TTFT/TPOT`、峰值内存、长稳退化 |
+| `RQ3` | Linux / RTOS / Hypervisor 混合结构能否比单一系统结构提供更稳定的整体边界 | 三层指标同时达标情况、恢复与隔离效果 |
+| `RQ4` | MCU 路线与 SoC 路线的边界分别是什么 | 静态编排能力、统一内存竞争、功耗与体积约束下的成立区间 |
+
+## 3. 对照结构
+
+框架2的主对照组如下：
+
+| 编号 | 配置 | 作用 |
+|---|---|---|
+| `O0` | 普通 Linux | 通用系统基线 |
+| `O1` | PREEMPT_RT Linux | 实时增强 Linux 的边界 |
+| `O2` | RTOS 原生配置 | RTOS 直接控制域能力 |
+| `O3` | 混合基础系统配置 | Linux + RTOS + Hypervisor 或等价协同结构 |
+
+必要时可继续细分：
+
+- `O3a` 无 Hypervisor 的双系统结构
+- `O3b` 带 Hypervisor 的隔离结构
+- `O3c` 加入规则兜底与异常切换的完整结构
+
+## 4. 场景编号
+
+| 编号 | 场景 | 目的 |
+|---|---|---|
+| `L0` | 仅关键保障负载 | 观察关键保障负载下界 |
+| `L1` | 仅人工智能目标负载 | 观察 AI 目标负载独立行为 |
+| `L2` | 关键保障负载 + AI 目标负载 | 核心双目标场景 |
+| `L3` | `L2` + CPU / 中断竞争 | 观察 RTOS 直接控制域边界 |
+| `L4` | `L2` + 内存 / DMA / 总线竞争 | 观察系统协同域边界 |
+| `L5` | `L2` + 网络 / 存储 / 模型加载 | 观察运行时与后台服务影响 |
+| `L6` | `L2` + 规则兜底 / 降级切换 | 观察闭环安全边界 |
+| `L7` | `L2` + 突发 / 过载 / 恢复 | 观察长稳、异常与恢复能力 |
+
+## 5. 实验单元
+
+| 编号 | 实验单元 | 主要覆盖问题 |
+|---|---|---|
+| `E0` | 设备、驱动与基础软件准入 | 全部 |
+| `E1` | RTOS 直接控制域微基准 | `RQ1` |
+| `E2` | 推理运行域基线 | `RQ2` |
+| `E3` | 双目标共存对照 | `RQ1/RQ2` |
+| `E4` | 混合结构协同对照 | `RQ3` |
+| `E5` | MCU 路线静态编排实验 | `RQ4` |
+| `E6` | SoC 路线统一内存与总线竞争实验 | `RQ3/RQ4` |
+| `E7` | 规则兜底与异常切换实验 | `RQ3` |
+| `E8` | 长稳、热状态与恢复实验 | `RQ2/RQ3/RQ4` |
+
+## 6. 分路线实验重点
+
+### 6.1 MCU 路线
+
+MCU 路线优先组织：
+
+- 小模型 / 小算子与控制任务静态编排；
+- 固定内存池与固定执行窗口；
+- 开发套件、代码生成与部署检查能力；
+- 极低功耗与极小内存条件下的成立区间。
+
+### 6.2 SoC 路线
+
+SoC 路线优先组织：
+
+- Linux / RTOS 的分工；
+- Hypervisor 资源切分；
+- 统一内存、DMA、总线和 NPU/GPU 竞争；
+- 设备级受限散热、受限功耗与长稳边界。
+
+## 7. 指标结构
+
+### 7.1 人工智能目标负载层
+
+- `TTFT`
+- `TPOT`
+- 端到端响应时间
+- 功能有效性
+- 长时间稳定性
+
+### 7.2 关键保障负载层
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 观测最大响应时间
+- 外部接口响应时间
+
+### 7.3 系统协同层
+
+- 有效吞吐
+- 资源隔离效果
+- `E/token`
+- 温度与热漂移
+- 异常切换与恢复时间
+
+## 8. 解释边界
+
+框架2特别强调三条解释边界：
+
+1. **GPU/NPU 内部执行行为不直接等价于 RTOS 收益**
+2. **混合结构的收益必须拆分为 RTOS 收益、协同结构收益和运行时收益**
+3. **MCU 路线与 SoC 路线的结论不得直接互相替代**
+
+## 9. 当前结论
+
+> **框架2的实验设计，不再围绕“单系统性能竞赛”组织，而是围绕“人工智能进入实时控制系统后的整体边界是否成立”来组织。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/02-总课题论文写作规划.md

@@ -0,0 +1,143 @@
+# 论文写作规划 — 面向AI的实时控制基础系统研究
+
+> **版本**: v0.1
+> **定位**: 框架2对应的候选论文规划稿
+> **目标**: 把“人工智能进入实时控制系统后，基础系统如何维持整体实时边界”组织成可写作、可实验、可比较的论文结构
+
+## 0. 文章定位与核心贡献
+
+### 0.1 一句话定位
+
+> **围绕人工智能目标负载进入实时控制系统后的整体边界问题，系统研究模型、运行时、RTOS、Linux、Hypervisor 与异构资源结构如何共同决定系统的确定性、可预测性与实时性表现。**
+
+### 0.2 核心贡献
+
+| 编号 | 贡献 |
+|---|---|
+| `C1` | 提出“面向 AI 的实时控制基础系统”这一问题定义与三层边界框架 |
+| `C2` | 给出 MCU 路线与 SoC 路线并行的统一验证矩阵 |
+| `C3` | 给出 Linux / RTOS / Hypervisor / 混合结构的系统级对照方法 |
+| `C4` | 给出规则兜底、异常切换与闭环安全边界的实验组织方式 |
+
+## 1. 文章整体结构
+
+```
+第1章  引言
+第2章  问题背景与相关工作
+第3章  面向AI的实时控制基础系统问题定义
+第4章  三层边界：RTOS控制域、推理运行域、系统协同域
+第5章  MCU路线与SoC路线
+第6章  实验方法学与对照结构
+第7章  实验结果
+第8章  深入分析与边界讨论
+第9章  产业定位与系统意义
+第10章 结论与展望
+```
+
+## 2. 各章重点
+
+### 第1章 引言
+
+重点说明：
+
+- 人工智能进入实时控制系统后，问题已经跨层展开；
+- 单纯用“RTOS 优于 Linux”不足以覆盖真实系统问题；
+- 需要一个“基础系统主语”的新框架。
+
+### 第2章 问题背景与相关工作
+
+重点说明：
+
+- AI 目标负载的时间行为与资源行为；
+- RTOS 的直接价值；
+- Linux 与 PREEMPT_RT 的边界；
+- 现有研究为什么很少真正覆盖混合系统。
+
+### 第3章 问题定义
+
+重点说明：
+
+- 什么是“面向 AI 的实时控制基础系统”；
+- 为什么研究对象要从 RTOS 平台上移；
+- `T5~T1` 继续作为验证矩阵，而不是研究主语。
+
+### 第4章 三层边界
+
+重点说明：
+
+- RTOS 直接控制域；
+- 推理运行域；
+- 系统协同域。
+
+这一章是框架2的核心理论骨架。
+
+### 第5章 MCU 路线与 SoC 路线
+
+重点说明：
+
+- MCU 路线为什么强调静态编排和工具链；
+- SoC 路线为什么强调 Hybrid、Hypervisor 和统一内存竞争；
+- 两条路线如何分别组织实验。
+
+### 第6章 实验方法学与对照结构
+
+重点说明：
+
+- `O0/O1/O2/O3` 对照组；
+- `L0~L7` 场景编号；
+- `E0~E8` 实验单元；
+- 三层指标与解释边界。
+
+### 第7章 实验结果
+
+重点按三条主线展开：
+
+1. RTOS 直接控制域结果
+2. 推理运行域结果
+3. 系统协同域结果
+
+并比较：
+
+- MCU 路线与 SoC 路线；
+- 原生系统结构与混合结构；
+- 有无规则兜底时的闭环差异。
+
+### 第8章 深入分析与边界讨论
+
+重点分析：
+
+- 哪些边界由 RTOS 直接贡献；
+- 哪些边界由协同结构贡献；
+- 哪些结论只在 MCU 或 SoC 路线成立；
+- 哪些情况下混合结构收益明显，哪些情况下收益收窄。
+
+### 第9章 产业定位与系统意义
+
+这一章是框架2相对框架1新增的重要内容。重点讨论：
+
+- 企业如何从 RTOS 供应方转向基础系统供应方；
+- 基础系统叙事如何替代单点适配叙事；
+- 这一转向对联合研究与产业化路径的意义。
+
+### 第10章 结论与展望
+
+重点总结：
+
+- 人工智能进入实时控制系统后的主问题是什么；
+- 基础系统主语为什么比 RTOS 单主语更准确；
+- 后续在工具链、体系结构与协同治理上还有哪些扩展方向。
+
+## 3. 研究问题到实验映射
+
+| 研究问题 | 主要实验单元 | 主要章节 |
+|---|---|---|
+| `RQ1` RTOS 直接控制域边界 | `E1`、`E3`、`E8` | 第4、7、8章 |
+| `RQ2` 推理运行域时间行为 | `E2`、`E3`、`E8` | 第4、6、7章 |
+| `RQ3` 系统协同域结构收益 | `E4`、`E6`、`E7`、`E8` | 第4、6、7、8章 |
+| `RQ4` MCU / SoC 双路线边界 | `E5`、`E6`、`E8` | 第5、7、8章 |
+
+## 4. 当前结论
+
+框架2的论文规划和框架1最大的不同，不是换了一个标题，而是换了整篇文章的主语：
+
+> **论文不再只回答“RTOS 在 AI 任务下是否更优”，而是回答“人工智能进入实时控制系统后，基础系统如何共同维持边界”。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/03-两个子课题的共同问题.md

@@ -0,0 +1,26 @@
+# 两个子课题的共同问题
+
+## 1. 共同主语
+
+两个子课题共同服务于同一个总课题主语：
+
+> **面向 AI 的实时控制基础系统。**
+
+## 2. 共同方法层
+
+两个子课题共同依赖：
+
+- 三层边界；
+- 三类系统负载；
+- `T5~T1` 验证矩阵；
+- 统一评价框架；
+- 对照逻辑与规则兜底思想。
+
+## 3. 共同科学问题
+
+二者都需要回答：
+
+- AI 目标负载如何进入控制系统；
+- 关键保障负载如何继续保持边界；
+- 系统边界由哪些机制共同构成；
+- 实时性问题如何避免单因果叙事。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/04-两个子课题的差异边界.md

@@ -0,0 +1,32 @@
+# 两个子课题的差异边界
+
+## 1. 子课题A的主边界
+
+子课题A的主边界在于：
+
+- 极小资源预算；
+- 静态部署；
+- 低功耗与小型化；
+- 工具链和芯片协同；
+- 小模型与控制任务的静态共存。
+
+## 2. 子课题B的主边界
+
+子课题B的主边界在于：
+
+- Linux / RTOS 分工；
+- Hypervisor 与 Hybrid；
+- 统一内存、总线、DMA、NPU/GPU 竞争；
+- 规则兜底与异常切换；
+- 混合系统中的整体确定性。
+
+## 3. 为什么不能混写
+
+两个子课题对应的是两类不同的问题结构，因此：
+
+- 评价重点不同；
+- 工程条件不同；
+- 合作对象不同；
+- 论文表达重点不同。
+
+这就是框架2内部需要采用“一总两子”结构的原因。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/05-总课题申报与论文组织建议.md

@@ -0,0 +1,24 @@
+# 总课题申报与论文组织建议
+
+## 1. 申报组织建议
+
+当前更适合按以下方式组织：
+
+- 以总课题名义对外表述；
+- 在内部和申报材料中并列写出两个子课题；
+- 共享方法层放在总论部分；
+- 两个子课题分别作为技术主线展开。
+
+## 2. 论文组织建议
+
+论文层面建议采用：
+
+1. 总问题定义；
+2. 共享理论与方法层；
+3. 子课题A；
+4. 子课题B；
+5. 共同问题、差异边界与总体结论。
+
+## 3. 当前结论
+
+在当前阶段，最稳的组织方式不是把两个子课题拆成两个独立框架，而是在框架2内部保持“一总两子”的结构，并用共享方法层与综合收敛层保证主线统一。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/40-综合比较与收敛/README.md

@@ -0,0 +1,11 @@
+# 综合比较与收敛
+
+本目录用于承接总课题层面对两个子课题的统一实验骨架、论文组织和后续收敛工作。
+
+## 当前文档
+
+1. [01-统一实验设计与验证骨架.md](./01-统一实验设计与验证骨架.md)
+2. [02-总课题论文写作规划.md](./02-总课题论文写作规划.md)
+3. [03-两个子课题的共同问题.md](./03-两个子课题的共同问题.md)
+4. [04-两个子课题的差异边界.md](./04-两个子课题的差异边界.md)
+5. [05-总课题申报与论文组织建议.md](./05-总课题申报与论文组织建议.md)

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/00-子课题定义.md

@@ -0,0 +1,26 @@
+# 子课题定义
+
+## 1. 子课题名称
+
+面向 MCU 的静态智能控制基础系统
+
+## 2. 子课题主问题
+
+本子课题围绕以下问题展开：
+
+> **在 MCU 级资源预算下，人工智能能力如何通过静态编排、工具链、代码生成和芯片协同，被纳入可分析、可验证、可部署的实时控制系统。**
+
+## 3. 子课题边界
+
+本子课题重点聚焦：
+
+- 小模型、小算子与控制任务的静态共存；
+- 工具链、部署链路和代码生成能力；
+- 极小内存、极低功耗和快速启动场景；
+- 与芯片厂商和开发套件的协同。
+
+本子课题不把高动态 Linux 生态、复杂虚拟化结构和大规模混合系统作为主战场。
+
+## 4. 在总课题中的位置
+
+这是框架2中的第一个子课题，重点对应 `T5` 控制端，也是总课题中最能体现“小型化、低功耗、静态部署”特征的方向。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/01-研究问题与适用场景.md

@@ -0,0 +1,30 @@
+# 研究问题与适用场景
+
+## 1. 研究问题
+
+本子课题重点回答四个问题：
+
+1. 小模型与关键控制任务如何静态编排；
+2. 工具链如何把模型部署、资源预算和代码生成联成闭环；
+3. 芯片规格、运行时约束和控制边界如何共同决定系统能力；
+4. 低功耗、小型化和极小内存预算下，系统成立边界在哪里。
+
+## 2. 适用场景
+
+典型场景包括：
+
+- 控制器；
+- 轻量控制盒；
+- 小型工业控制节点；
+- 电池供电或功耗严苛设备；
+- 需要毫秒级或更紧周期控制的端侧场景。
+
+## 3. 与总课题共享层的衔接
+
+本子课题主要继承共享层中的：
+
+- `RTOS 直接控制域`
+- `推理运行域`
+- `基础设备与算力基础` 中的 `T5` 部分
+
+但会弱化 `系统协同域` 中面向大 SoC 混合结构的部分。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/02-技术路线：静态编排、工具链与芯片协同.md

@@ -0,0 +1,63 @@
+# MCU路线：静态分配与工具链协同
+
+## 1. 主题定位
+
+MCU 路线并不是“把大模型缩小以后放进 MCU”这么简单。在框架2中，MCU 路线代表的是另一类完全不同的问题结构：资源极端受限、动态空间极小、工具链和静态编排比在线调度策略更重要。
+
+## 2. MCU 路线的系统特征
+
+这一路线通常具有以下特点：
+
+- 可用内存极小；
+- 时钟和算力预算刚性；
+- 外设和控制链路优先级极高；
+- 更适合小模型、小算子和静态工作流；
+- 更依赖芯片 SDK、代码生成工具和开发套件。
+
+因此，MCU 路线更接近“静态可分析系统中的 AI 能力纳入问题”。
+
+## 3. 核心研究问题
+
+### 3.1 小模型如何进入静态编排体系
+
+MCU 路线重点不是追求通用大模型能力，而是研究：
+
+- 哪些轻量模型可以被稳定纳入控制系统；
+- 小模型、小算子与控制任务如何离线编排；
+- 预分配、静态内存池和固定执行窗口如何设计。
+
+### 3.2 工具链为什么比单点机制更重要
+
+在 MCU 路线上，真正决定工程落地效率的常常不是调度策略，而是：
+
+- 模型裁剪与转换工具；
+- 自动代码生成能力；
+- 内存预算与部署检查工具；
+- 芯片级软件开发套件。
+
+因此，MCU 路线天然更强调“工具链能力”。
+
+### 3.3 芯片协同如何进入研究主线
+
+对于 MCU 场景，芯片规格本身就会限制可用模型、缓冲区与时延上界。后续研究需要回答：
+
+- 哪些 AI 需求会反向定义 MCU 和端侧芯片规格；
+- 哪些片上资源是决定性瓶颈；
+- 开发套件如何把这些约束显式化。
+
+## 4. 评价重点
+
+MCU 路线重点观察：
+
+- 关键保障负载能否稳定维持；
+- 小模型能否在固定资源预算中运行；
+- 工具链是否能给出可分析、可复现的部署边界；
+- 功耗、体积和散热预算是否同时满足。
+
+## 5. 与框架2的关系
+
+MCU 路线主要对应 `T5` 控制端，也是框架2中最能体现“小型化、低功耗、工具链协同”特征的部分。它为整个基础系统课题提供了一个约束极强、边界清晰的验证窗口。
+
+## 6. 当前结论
+
+> **MCU 路线的主问题不是“大模型如何跑进去”，而是人工智能能力如何在极端受限条件下，被静态、可分析地纳入实时控制系统。**

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/03-实验设计与验证方法.md

@@ -0,0 +1,28 @@
+# 实验设计与验证方法
+
+## 1. 验证重点
+
+本子课题的验证重点包括：
+
+- 静态内存预算是否成立；
+- 控制任务截止期是否维持；
+- 小模型推理是否能在固定窗口内完成；
+- 功耗、热状态和启动时间是否满足约束。
+
+## 2. 典型实验单元
+
+适合优先组织：
+
+1. 小模型与控制任务共存实验；
+2. 静态内存池和固定执行窗口实验；
+3. 工具链生成结果与手工部署结果对比；
+4. 低功耗与长稳运行实验。
+
+## 3. 指标重点
+
+- `deadline miss ratio`
+- `P99/P99.9 jitter`
+- 单次推理时延
+- 峰值内存占用
+- 启动时间
+- `E/inference`

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/04-预期成果与论文方向.md

@@ -0,0 +1,19 @@
+    # 预期成果与论文方向
+
+## 1. 预期成果
+
+本子课题预期形成：
+
+1. 面向 MCU 的静态智能控制问题定义；
+2. 小模型与控制任务静态编排方法；
+3. 工具链、代码生成与部署检查框架；
+4. 低功耗、小型化场景下的系统边界证据。
+
+## 2. 论文方向
+
+可对应的论文方向包括：
+
+- TinyML / Edge AI on MCU
+- 低功耗嵌入式智能系统
+- 静态部署与工具链协同
+- 实时控制中的小模型纳入问题

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/05-合作方式与产业落点.md

@@ -0,0 +1,28 @@
+# 合作方式与产业落点
+
+## 1. 合作重点
+
+本子课题更适合围绕以下合作对象展开：
+
+- MCU / 控制芯片厂商；
+- 开发套件和工具链团队；
+- 小型化控制设备厂商；
+- 对功耗和体积高度敏感的行业客户。
+
+## 2. 合作方式
+
+建议采用：
+
+1. 芯片与工具链条件梳理；
+2. 静态部署链路共建；
+3. 小规模样机验证；
+4. 工具链与方法沉淀。
+
+## 3. 产业落点
+
+这一子课题更容易落到：
+
+- 开发套件；
+- 芯片协同方案；
+- 小型控制设备智能化升级；
+- 低功耗端侧部署方法。