reorganize repository into meeting and project framework structure
Align the repository with the new collaboration workflow by separating meeting records from project framework materials, so discussion outputs and formal research assets can evolve independently.
This commit is contained in:
@@ -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 真实工程复杂度的方向。
|
||||
@@ -0,0 +1,29 @@
|
||||
# 研究问题与适用场景
|
||||
|
||||
## 1. 研究问题
|
||||
|
||||
本子课题重点回答四个问题:
|
||||
|
||||
1. Linux 与 RTOS 如何在同一 SoC 上分工;
|
||||
2. Hypervisor 与 Hybrid 结构如何提升整体可治理性;
|
||||
3. 统一内存、总线、DMA 与 NPU/GPU 竞争如何进入系统分析;
|
||||
4. 规则兜底与异常切换如何把混合系统闭合成可验证的控制系统。
|
||||
|
||||
## 2. 适用场景
|
||||
|
||||
典型场景包括:
|
||||
|
||||
- 设备端 SoC;
|
||||
- 工业边缘节点;
|
||||
- 车载或机器人边侧平台;
|
||||
- 同时承载控制与 AI 推理的异构系统。
|
||||
|
||||
## 3. 与总课题共享层的衔接
|
||||
|
||||
本子课题主要继承共享层中的:
|
||||
|
||||
- `系统协同域`
|
||||
- `规则兜底与控制闭环`
|
||||
- `基础设备与算力基础` 中的 `T4/T3` 部分
|
||||
|
||||
同时结合 `RTOS 直接控制域` 和 `推理运行域` 形成整体边界分析。
|
||||
+77
@@ -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 的实时控制基础系统”最能成立、也最值得展开的核心研究窗口。**
|
||||
@@ -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`
|
||||
- 资源隔离效果
|
||||
- 温度、热漂移与恢复时间
|
||||
@@ -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 协同结构与实时边界
|
||||
@@ -0,0 +1,29 @@
|
||||
# 合作方式与产业落点
|
||||
|
||||
## 1. 合作重点
|
||||
|
||||
本子课题更适合围绕以下合作对象展开:
|
||||
|
||||
- SoC / 板级平台厂商;
|
||||
- Hypervisor / mixed-criticality 基础软件团队;
|
||||
- 工业边缘和机器人设备团队;
|
||||
- 同时承载 AI 与控制任务的行业客户。
|
||||
|
||||
## 2. 合作方式
|
||||
|
||||
建议采用:
|
||||
|
||||
1. 平台条件与资源结构梳理;
|
||||
2. Linux / RTOS / Hypervisor 分工设计;
|
||||
3. 板级实验与隔离验证;
|
||||
4. 规则兜底和闭环安全验证;
|
||||
5. 系统协同证据沉淀。
|
||||
|
||||
## 3. 产业落点
|
||||
|
||||
这一子课题更容易落到:
|
||||
|
||||
- 边侧 SoC 参考架构;
|
||||
- 混合基础系统方案;
|
||||
- Hypervisor 协同部署方法;
|
||||
- 设备端 AI + 控制一体化平台路线。
|
||||
@@ -0,0 +1,24 @@
|
||||
# 子课题B:面向边侧SoC的混合实时控制基础系统
|
||||
|
||||
本目录用于承接框架2中的第二个子课题,重点面向 `T4/T3` 设备端 SoC 与边侧混合系统场景。
|
||||
|
||||
## 子课题定位
|
||||
|
||||
本子课题重点研究:
|
||||
|
||||
> **在边侧 SoC 与设备端异构平台上,Linux、RTOS、Hypervisor、Hybrid 结构与异构资源治理如何共同维持系统的实时边界。**
|
||||
|
||||
## 建议阅读顺序
|
||||
|
||||
1. [00-子课题定义.md](./00-子课题定义.md)
|
||||
2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md)
|
||||
3. [02-技术路线:Linux-RTOS-Hypervisor-Hybrid.md](./02-技术路线:Linux-RTOS-Hypervisor-Hybrid.md)
|
||||
4. [03-实验设计与验证方法.md](./03-实验设计与验证方法.md)
|
||||
5. [04-预期成果与论文方向.md](./04-预期成果与论文方向.md)
|
||||
6. [05-合作方式与产业落点.md](./05-合作方式与产业落点.md)
|
||||
|
||||
## 当前特点
|
||||
|
||||
本子课题的关键词是:
|
||||
|
||||
`Hybrid`、`Hypervisor`、`Linux+RTOS`、`统一内存`、`资源隔离`、`系统协同`
|
||||
Reference in New Issue
Block a user