docs: organize edge SoC research materials

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

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-项目框架/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. 产业落点
+
+这一子课题更容易落到：
+
+- 开发套件；
+- 芯片协同方案；
+- 小型控制设备智能化升级；
+- 低功耗端侧部署方法。

02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/90-备份-子课题A-重组前-20260924/06-离线联合编排研究框架.md

@@ -0,0 +1,661 @@
+# 面向 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>