forked from eaiadmin/rtos_llm_opt
docs: add alternative real-time research frameworks
This commit is contained in:
@@ -0,0 +1,241 @@
|
||||
# RTOS + Linux + Hypervisor 边缘并行架构说明
|
||||
|
||||
## 1. 架构目标
|
||||
|
||||
边缘侧采用并行分域思路:RTOS 负责控制和安全关键路径,Linux 负责 AI 推理与复杂软件生态,Hypervisor 或等价静态分区层负责空间隔离、时间干扰控制和设备分配。
|
||||
|
||||
该架构不把“让 RTOS 原生运行全部大模型软件栈”作为前提。优化目标按优先级排序为:
|
||||
|
||||
1. 控制闭环截止期不被推理负载破坏;
|
||||
2. AI 结果在规定的新鲜度窗口内可用;
|
||||
3. 推理域故障不扩散到控制域;
|
||||
4. 在前三项满足后提高推理吞吐、能效和资源利用率。
|
||||
|
||||
## 2. 逻辑架构
|
||||
|
||||
```text
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 边缘计算硬件 │
|
||||
│ CPU 核 / LLC / DRAM / 内存带宽 / NPU或GPU / I/O / 时钟 │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ Hypervisor、静态分区器或具备等价能力的隔离层 │
|
||||
│ vCPU/物理核分配、内存区间、IOMMU、设备直通、中断路由、监控 │
|
||||
├───────────────────────────┬─────────────────────────────────┤
|
||||
│ RTOS 控制域 │ Linux 推理域 │
|
||||
│ - 周期控制与联锁 │ - 模型加载与推理运行时 │
|
||||
│ - 现场总线与关键传感器 │ - GPU/NPU 驱动与厂商 SDK │
|
||||
│ - 时间戳、结果校验 │ - 数据预处理与后处理 │
|
||||
│ - 超时、降级与安全状态 │ - 模型更新、日志与网络服务 │
|
||||
├───────────────────────────┴─────────────────────────────────┤
|
||||
│ 有界跨域通道:共享内存环形队列 + 通知 / RPMsg / 虚拟设备等 │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
这里的“Hypervisor”表示架构角色,不预设具体产品。若 SoC 已具备安全岛、独立 MCU、AMP 或硬件静态分区能力,只要能够提供可验证的资源和故障隔离,也可以作为实现路径。
|
||||
|
||||
## 3. 两个域的职责边界
|
||||
|
||||
### 3.1 RTOS 控制域
|
||||
|
||||
RTOS 域应拥有:
|
||||
|
||||
- 周期控制、联锁、执行器输出和关键状态采集;
|
||||
- 控制任务使用的定时器、关键中断和关键 I/O;
|
||||
- AI 请求的采样时刻、任务编号、期望完成期限和优先级;
|
||||
- AI 结果的完整性、新鲜度、置信度和序列一致性检查;
|
||||
- 超时、失联、异常结果和推理域重启时的回退控制;
|
||||
- 必要的看门狗与推理域生命周期控制接口。
|
||||
|
||||
RTOS 域不应依赖 Linux 域才能维持基本安全状态。AI 可增强系统能力,但关键控制闭环应明确 AI 缺席时的可接受行为。
|
||||
|
||||
### 3.2 Linux 推理域
|
||||
|
||||
Linux 域应拥有:
|
||||
|
||||
- 模型文件、模型运行时和推理服务;
|
||||
- GPU/NPU/DLA 等加速器驱动及厂商 SDK;
|
||||
- 复杂预处理、后处理、模型编排和批处理;
|
||||
- 网络、存储、模型更新以及非关键日志服务;
|
||||
- 推理资源的吞吐优化和域内调度。
|
||||
|
||||
Linux 域可以对 AI 服务做软实时优化,但不得把域内平均时延等同于控制系统的实时保证。
|
||||
|
||||
### 3.3 Hypervisor/分区层
|
||||
|
||||
隔离层需要明确而不是笼统声称以下能力:
|
||||
|
||||
- CPU 核是静态独占、时间分片还是混合分配;
|
||||
- 内存区域是否静态划分,是否存在共享页和动态气球机制;
|
||||
- LLC、内存带宽和互联是否可分配、限额或仅可观测;
|
||||
- 加速器采用直通、复用还是由单一域独占;
|
||||
- 设备 DMA 是否受 IOMMU 限制;
|
||||
- 物理中断如何路由,是否会在控制核上产生额外虚拟化出口;
|
||||
- 一个域崩溃、重启或过载时,另一域是否持续运行。
|
||||
|
||||
Hypervisor 本身也会引入 VM exit、虚拟中断和跨域通信开销,必须纳入实测,不能只把它视为零成本隔离层。
|
||||
|
||||
## 4. 跨域通信契约
|
||||
|
||||
推荐使用异步、有界、可丢弃的通信语义,避免 RTOS 控制任务同步等待 Linux 推理。
|
||||
|
||||
### 4.1 请求消息最小字段
|
||||
|
||||
| 字段 | 作用 |
|
||||
|---|---|
|
||||
| `request_id` | 区分请求和乱序结果 |
|
||||
| `sample_time` | 标识传感数据的采样时刻 |
|
||||
| `deadline` | AI 结果最晚可用时刻 |
|
||||
| `priority/class` | 区分任务重要性和推理策略 |
|
||||
| `payload_ref` | 指向受控共享缓冲区或内联小数据 |
|
||||
| `schema/version` | 防止两域版本不一致 |
|
||||
|
||||
### 4.2 结果消息最小字段
|
||||
|
||||
| 字段 | 作用 |
|
||||
|---|---|
|
||||
| `request_id` | 与请求配对 |
|
||||
| `model_version` | 支撑审计和回滚 |
|
||||
| `finish_time` | 计算跨域端到端时延 |
|
||||
| `confidence/status` | 判断结果是否可用 |
|
||||
| `valid_until` | 规定结果新鲜度边界 |
|
||||
| `payload/checksum` | 结果与完整性校验 |
|
||||
|
||||
### 4.3 控制域消费规则
|
||||
|
||||
RTOS 只在以下条件同时满足时采用 AI 结果:
|
||||
|
||||
```text
|
||||
ID 匹配
|
||||
AND 数据完整
|
||||
AND finish_time <= deadline
|
||||
AND now <= valid_until
|
||||
AND confidence/status 满足策略
|
||||
```
|
||||
|
||||
任一条件不满足时执行预定义回退,例如沿用上次可信结果、使用传统控制器、降低运行等级或进入安全状态。回退动作和完成时间本身也属于实时需求。
|
||||
|
||||
## 5. 系统级时间模型
|
||||
|
||||
AI 辅助决策链可表示为:
|
||||
|
||||
```text
|
||||
R_ai = C_sample + C_tx_req + Q_linux + C_pre
|
||||
+ C_infer + C_post + C_tx_rsp + C_validate
|
||||
```
|
||||
|
||||
系统约束不是简单要求 `C_infer` 最小,而是:
|
||||
|
||||
```text
|
||||
R_control <= D_control
|
||||
|
||||
AI 结果被采用时:R_ai <= D_ai 且 age(result) <= A_max
|
||||
|
||||
AI 结果未按时到达时:R_fallback <= D_fallback
|
||||
```
|
||||
|
||||
其中,控制闭环约束为硬优先级;AI 时效约束通常为任务相关的软实时或固实时约束;回退路径必须有独立期限。
|
||||
|
||||
## 6. 资源并行与隔离策略
|
||||
|
||||
### 6.1 CPU 和中断
|
||||
|
||||
- 为 RTOS 域保留独立物理核,避免与 Linux vCPU 时间复用;
|
||||
- 将关键定时器和现场总线中断直达 RTOS 域;
|
||||
- 将网卡、存储和加速器完成中断尽量路由到 Linux 域;
|
||||
- 若共享 LLC,测量 Linux 推理对控制任务缓存行为的干扰;
|
||||
- 记录 SMT、动态迁核和电源管理对分区确定性的影响。
|
||||
|
||||
### 6.2 内存、带宽和 DMA
|
||||
|
||||
- 两域使用静态内存区间,共享区保持最小化;
|
||||
- 共享缓冲区预分配,禁止关键路径动态扩容;
|
||||
- 使用 IOMMU 或硬件访问控制限制 DMA 范围;
|
||||
- 对 DRAM 带宽、内存控制器和互联竞争进行压力实验;
|
||||
- 若硬件不支持带宽限额,必须把“核隔离”和“内存隔离”分开表述。
|
||||
|
||||
### 6.3 加速器
|
||||
|
||||
推荐由 Linux 推理域独占 GPU/NPU,以保留成熟驱动和运行时生态。RTOS 通过请求契约使用推理服务,而不是直接进入厂商运行时。
|
||||
|
||||
若控制域也需访问同一加速器,则必须额外解决队列仲裁、DMA 隔离、不可抢占执行段和故障复位归属。这种共享模式风险更高,应作为扩展方案而非默认主线。
|
||||
|
||||
### 6.4 功耗和热
|
||||
|
||||
分域不自动消除芯片级功耗和温度耦合。Linux 域的持续推理可能触发全芯片功耗限制或降频,进而改变 RTOS 域执行时间。因此需要:
|
||||
|
||||
- 固定或记录各域频率和功率模式;
|
||||
- 同步采集控制延迟、推理负载、温度和实际频率;
|
||||
- 对推理域设置负载准入或功耗上限;
|
||||
- 验证热稳态而非只测短时冷机性能。
|
||||
|
||||
## 7. 故障与降级状态机
|
||||
|
||||
```text
|
||||
正常增强控制
|
||||
│ AI 超时/低置信度
|
||||
▼
|
||||
传统控制或保持模式
|
||||
│ 连续超时/通信故障
|
||||
▼
|
||||
推理域隔离与重启
|
||||
│ 控制风险上升
|
||||
▼
|
||||
受限运行或安全状态
|
||||
```
|
||||
|
||||
需要验证的故障至少包括:
|
||||
|
||||
- Linux 推理进程崩溃;
|
||||
- Linux 域卡死或重启;
|
||||
- 加速器驱动错误或设备复位;
|
||||
- 跨域队列堆满、消息乱序或数据损坏;
|
||||
- 推理持续超时;
|
||||
- Linux 域 CPU、内存、网络或存储过载。
|
||||
|
||||
每种故障都要记录检测时间、隔离时间、回退完成时间、控制任务违约数和恢复后首个有效 AI 结果时间。
|
||||
|
||||
## 8. 可比较的架构组
|
||||
|
||||
| 组别 | 架构 | 用途 |
|
||||
|---|---|---|
|
||||
| A0 | 单 Linux,控制与推理同域 | 通用部署基线 |
|
||||
| A1 | PREEMPT_RT Linux,控制与推理同域 | 实时增强 Linux 基线 |
|
||||
| A2 | RTOS 同域承载控制与可运行的 AI | 适用于 MCU/小模型,不强求大模型生态 |
|
||||
| A3 | RTOS 控制域 + Linux 推理域 + 分区层 | 边缘并行主方案 |
|
||||
| A4 | A3 加入通信、带宽、故障和热治理机制 | 完整优化方案 |
|
||||
|
||||
比较时必须固定硬件、控制任务语义、AI 模型、输入到达序列和功率策略。A2 与 A3 若使用不同推理后端,应明确这是“系统方案比较”,不能仅归因为内核差异。
|
||||
|
||||
## 9. 核心评价指标
|
||||
|
||||
### 控制域
|
||||
|
||||
- 周期任务响应时间、抖动和 deadline miss ratio;
|
||||
- 外部输入到执行器输出的物理链路延迟;
|
||||
- AI 过载与故障期间的观测最大响应时间;
|
||||
- 回退路径完成时间。
|
||||
|
||||
### AI 链路
|
||||
|
||||
- 从 RTOS 发起请求到结果验证完成的端到端延迟;
|
||||
- 结果按期率、新鲜度合格率、超时率和丢弃率;
|
||||
- 吞吐、TTFT/TPOT 或任务特定推理时延;
|
||||
- 推理域重启后的恢复时间。
|
||||
|
||||
### 隔离与代价
|
||||
|
||||
- 空载和推理满载时控制延迟之差;
|
||||
- CPU、内存带宽、I/O、DMA 和热干扰敏感度;
|
||||
- 跨域 IPC 延迟、抖动、拷贝次数和 CPU 开销;
|
||||
- 静态资源预留造成的推理吞吐及能效损失。
|
||||
|
||||
## 10. 架构结论边界
|
||||
|
||||
本架构旨在证明“系统可以在 AI 负载不确定的情况下保护关键控制路径,并对 AI 结果实施有期限的安全消费”。它不自动证明:
|
||||
|
||||
- Linux 域中的大模型具备硬实时性;
|
||||
- Hypervisor 消除了所有共享硬件干扰;
|
||||
- 一个硬件平台的分区结果可直接迁移到另一 SoC;
|
||||
- 只要控制域未违约,AI 功能就一定满足任务需求。
|
||||
|
||||
最终结论必须同时报告控制保障效果、AI 结果可用性以及隔离带来的资源代价。
|
||||
@@ -0,0 +1,207 @@
|
||||
# 调整后研究问题与验证建议
|
||||
|
||||
## 1. 调整目的
|
||||
|
||||
本文将最新方向意见转化为可执行的研究问题和验证建议。它不替换现有实验设计,而用于指导下一轮方案收敛:主线从覆盖 `T1~T5` 的 RTOS 大模型统一评测,转向 MCU/资源受限 SoC 的 AI 实时干扰,以及边缘侧 RTOS/Linux 分域系统的整体实时保障。
|
||||
|
||||
## 2. 建议的研究范围
|
||||
|
||||
### 2.1 核心范围
|
||||
|
||||
- MCU 或资源受限 SoC 上,AI 与周期控制、采集和通信共存;
|
||||
- 边缘平台上,RTOS 控制域与 Linux 推理域并行运行;
|
||||
- CPU、内存、缓存、总线、中断、DMA、加速器、功耗和热形成的系统级干扰;
|
||||
- AI 结果的期限、新鲜度、超时、降级与故障恢复。
|
||||
|
||||
### 2.2 条件扩展
|
||||
|
||||
- 更大模型、更高并发和多加速器用于增加 Linux 推理域压力;
|
||||
- 不同 Hypervisor、静态分区或 AMP 实现之间的隔离开销比较;
|
||||
- 多边缘节点之间的协同推理。
|
||||
|
||||
### 2.3 暂不作为主线
|
||||
|
||||
- `T1` 多节点大模型集群的 RTOS 部署;
|
||||
- `T2` 多 GPU 工作站上的统一 RTOS 推理栈;
|
||||
- 以“容量从 MCU 连续扩展到集群”为核心贡献;
|
||||
- 将模型量化、KV Cache 或分布式推理优化直接归为 RTOS 成果。
|
||||
|
||||
## 3. 研究问题
|
||||
|
||||
| 编号 | 研究问题 | 核心输出 |
|
||||
|---|---|---|
|
||||
| RQ1 | AI 进入 MCU/SoC 后,通过哪些资源路径破坏控制实时性? | 干扰来源排序、响应时间与违约边界 |
|
||||
| RQ2 | RTOS 的优先级、预算、隔离、预分配和准入机制能扩大多少安全运行区间? | 无违约容量曲线与机制消融 |
|
||||
| RQ3 | RTOS 控制域 + Linux 推理域 + Hypervisor 是否优于单域共存? | 控制保护、AI 结果按期率与资源代价 |
|
||||
| RQ4 | 跨域通信与静态资源预留带来多大开销? | IPC 延迟/抖动、吞吐和能效损失 |
|
||||
| RQ5 | 推理超时、Linux 域崩溃或加速器故障时能否按时降级? | 故障检测、隔离、回退和恢复时间 |
|
||||
|
||||
## 4. 分阶段实验路线
|
||||
|
||||
### 阶段 P0:需求与时间契约冻结
|
||||
|
||||
先定义而不是从设备档位反推:
|
||||
|
||||
- 控制任务周期 `T_control` 和截止期 `D_control`;
|
||||
- AI 结果期限 `D_ai` 和最大新鲜度 `A_max`;
|
||||
- AI 缺席时的回退动作和期限 `D_fallback`;
|
||||
- 可接受的 AI 完成率、结果质量和能耗预算;
|
||||
- 需要保护的关键 I/O、中断、内存和设备。
|
||||
|
||||
完成标志是形成一张“任务—资源—期限—失败处理”表。
|
||||
|
||||
### 阶段 P1:MCU/SoC 干扰确认
|
||||
|
||||
在真实可运行 AI 的最小平台上建立下列负载:
|
||||
|
||||
| 负载 | 内容 | 目的 |
|
||||
|---|---|---|
|
||||
| M0 | 仅控制任务 | 控制实时性下界 |
|
||||
| M1 | 仅 AI | AI 执行、内存、功耗基线 |
|
||||
| M2 | 控制 + AI | 确认同域干扰 |
|
||||
| M3 | M2 + 内存/总线压力 | 定位共享资源瓶颈 |
|
||||
| M4 | M2 + I/O/中断压力 | 定位中断与 DMA 干扰 |
|
||||
| M5 | M2 + 热稳态运行 | 识别降频导致的时间漂移 |
|
||||
| M6 | AI 过载与突发 | 找到准入和降级阈值 |
|
||||
|
||||
AI 模型按硬件实际能力选择,不要求 MCU 运行大语言模型。小模型同样可以有效暴露系统级资源竞争。
|
||||
|
||||
### 阶段 P2:RTOS 机制验证
|
||||
|
||||
逐项加入并消融以下机制:
|
||||
|
||||
1. 控制任务固定优先级与核/执行上下文隔离;
|
||||
2. AI 任务预算或服务器机制;
|
||||
3. 内存预分配、缓冲区限额和禁止关键路径动态分配;
|
||||
4. 中断亲和性和关键设备优先级;
|
||||
5. AI 请求队列上限、限流和拒绝策略;
|
||||
6. 模型降级、跳帧或降低推理频率;
|
||||
7. 超时后回退到非 AI 控制路径。
|
||||
|
||||
每次只改变一个机制,输出控制任务违约率、AI 完成率和吞吐代价,避免只给出“优化前后”黑盒比较。
|
||||
|
||||
### 阶段 P3:边缘分域基线
|
||||
|
||||
至少比较:
|
||||
|
||||
| 组别 | 配置 |
|
||||
|---|---|
|
||||
| E0 | 普通 Linux:控制与推理同域 |
|
||||
| E1 | PREEMPT_RT Linux:控制与推理同域 |
|
||||
| E2 | RTOS 控制域 + Linux 推理域,最小静态分区 |
|
||||
| E3 | E2 + 中断、内存、通信和准入优化 |
|
||||
|
||||
如硬件不支持其中某组,应明确记录缺失原因,不用不同硬件数据替代同平台对照。
|
||||
|
||||
### 阶段 P4:共享资源压力扫描
|
||||
|
||||
在 Linux 推理域逐步增加:
|
||||
|
||||
- CPU 利用率和线程数量;
|
||||
- 模型请求到达率、batch 和上下文长度;
|
||||
- DRAM 带宽与 LLC 压力;
|
||||
- 网络、存储和摄像头 I/O;
|
||||
- GPU/NPU 占用和完成中断频率;
|
||||
- 持续功耗与温度。
|
||||
|
||||
横轴使用相同绝对负载或相同到达序列,纵轴联合展示控制 deadline miss ratio、AI 结果按期率和有效吞吐。目标是找到“控制仍安全、AI 仍有用”的二维可行区,而不是只比较单个平均值。
|
||||
|
||||
### 阶段 P5:跨域通信实验
|
||||
|
||||
比较可实现的通信方式,例如共享内存环形队列、通知机制、RPMsg 或虚拟设备。统一消息大小和到达序列,测量:
|
||||
|
||||
- 单向和往返时延;
|
||||
- P99/P99.9 与观测最大抖动;
|
||||
- 拷贝次数和 CPU 占用;
|
||||
- 队列满时的丢弃、覆盖或背压行为;
|
||||
- 域重启后的通道恢复时间;
|
||||
- 旧结果、乱序结果和损坏结果是否被 RTOS 拒绝。
|
||||
|
||||
### 阶段 P6:故障注入与恢复
|
||||
|
||||
建议故障集:
|
||||
|
||||
| 故障 | 必测结果 |
|
||||
|---|---|
|
||||
| 推理进程退出 | 检测时间、控制违约、服务恢复时间 |
|
||||
| Linux 域重启 | RTOS 是否持续运行、回退完成时间 |
|
||||
| 推理请求永久阻塞 | 超时是否生效、队列是否泄漏 |
|
||||
| 加速器错误/复位 | 故障是否跨域传播、恢复路径 |
|
||||
| 共享队列溢出 | 丢弃策略、内存安全、控制影响 |
|
||||
| 消息乱序/校验失败 | 错误结果是否被消费 |
|
||||
| Linux 域 CPU/内存/I/O 过载 | 控制尾延迟和隔离上限 |
|
||||
|
||||
仅在具备安全恢复路径时执行设备级故障注入;否则先用软件故障和仿真通道验证状态机。
|
||||
|
||||
## 5. 指标体系调整
|
||||
|
||||
### 5.1 第一优先级:控制实时性
|
||||
|
||||
- 释放到完成的响应时间;
|
||||
- deadline miss ratio;
|
||||
- P99/P99.9 和观测最大抖动;
|
||||
- GPIO、CAN、RS485 或工业以太网的端到端物理响应;
|
||||
- AI 满载、热稳态和故障期间的控制表现。
|
||||
|
||||
### 5.2 第二优先级:AI 结果可用性
|
||||
|
||||
- 请求发出到 RTOS 验证结果完成的端到端时延;
|
||||
- 结果按期率和新鲜度合格率;
|
||||
- 超时、拒绝、丢弃、乱序和错误率;
|
||||
- 任务质量或置信度;
|
||||
- 回退发生比例。
|
||||
|
||||
### 5.3 第三优先级:系统代价
|
||||
|
||||
- 分给 RTOS 的 CPU、内存和设备资源;
|
||||
- Hypervisor 与 IPC 开销;
|
||||
- 推理吞吐损失、能耗和热影响;
|
||||
- 静态预留导致的资源利用率变化;
|
||||
- 故障恢复和长稳运行开销。
|
||||
|
||||
TTFT、TPOT、tokens/s 和 `E/token` 可以继续使用,但它们属于 Linux 推理域或系统服务指标,不能替代控制实时性与结果新鲜度指标。
|
||||
|
||||
## 6. 推荐图表
|
||||
|
||||
1. 单域与分域架构职责图;
|
||||
2. AI 负载强度—控制违约率—AI 按期率三维或等高线图;
|
||||
3. CPU、内存、I/O、热干扰的控制尾延迟对比;
|
||||
4. 跨域请求—推理—返回—验证的时序分解图;
|
||||
5. RTOS 机制逐项消融图;
|
||||
6. 推理域故障期间控制响应时间序列;
|
||||
7. 静态资源预留与推理有效吞吐的 Pareto 曲线;
|
||||
8. AI 结果超时、回退、恢复状态机图。
|
||||
|
||||
## 7. 阶段验收标准
|
||||
|
||||
| 层次 | 验收条件 |
|
||||
|---|---|
|
||||
| 数据有效 | 时钟、负载、版本、拓扑和原始事件可追踪;失败样本未被静默删除 |
|
||||
| 控制保障 | 在冻结的运行区间内满足控制期限,并报告样本数和观测最大值 |
|
||||
| AI 可用 | 在冻结质量门槛下达到规定的按期率和新鲜度合格率 |
|
||||
| 隔离有效 | 推理负载或故障对控制域的影响显著小于单域基线 |
|
||||
| 代价可接受 | 同时报告资源预留、IPC、吞吐、能耗和热代价 |
|
||||
| 降级有效 | AI 不可用时在 `D_fallback` 内进入预定义状态,且不依赖推理域恢复 |
|
||||
|
||||
“未观测到违约”仍不能代替理论最坏界;Hypervisor 分域结果也只能在已验证的硬件、配置和压力范围内成立。
|
||||
|
||||
## 8. 对现有设备的使用建议
|
||||
|
||||
- 现有 RK3588 更适合作为边缘分域或资源受限 SoC 的核心验证平台,而不是同时承担多个容量档位以构造连续谱系;
|
||||
- 现有 V100 平台可作为 Linux 推理域的高压力源、吞吐参照或跨域服务端,但不需要证明其属于 RTOS 主线;
|
||||
- MCU 平台应根据真实 AI 运行能力和工业 I/O 条件选取,优先验证控制期限和资源干扰,而非模型参数规模;
|
||||
- 新增设备采购应由研究问题和分域实现需求驱动,不再为了补齐 `T1~T5` 档位而采购。
|
||||
|
||||
## 9. 建议的最小可发表闭环
|
||||
|
||||
在一个 MCU/SoC 同域平台和一个边缘分域平台上完成以下闭环即可形成聚焦的系统研究:
|
||||
|
||||
1. 证明 AI 负载会通过可识别的资源路径干扰控制实时性;
|
||||
2. 给出 RTOS 预算、隔离、准入和降级机制;
|
||||
3. 实现 RTOS 控制域与 Linux 推理域的有界异步通信;
|
||||
4. 与普通 Linux、PREEMPT_RT 或单域方案进行同平台比较;
|
||||
5. 在过载、热稳态和故障注入下验证控制保护;
|
||||
6. 同时报告 AI 结果按期率和资源代价;
|
||||
7. 明确结论只覆盖 MCU/SoC 与边缘任务关键系统,不外推到 T1/T2 集群。
|
||||
|
||||
这一闭环比覆盖全部硬件档位更容易建立清晰的因果关系,也更直接回应“AI 引入后,任务关键系统如何保持实时”的核心问题。
|
||||
@@ -0,0 +1,67 @@
|
||||
# 研究问题、定位与边界
|
||||
|
||||
## 1. 工业背景
|
||||
|
||||
机器人同时包含两类时间尺度显著不同的任务:
|
||||
|
||||
- 感知、语言理解、任务规划和大模型推理计算量大、运行时间动态,通常属于软实时或固实时;
|
||||
- 姿态稳定、关节控制、力控、现场总线和安全联锁按固定周期运行,通常属于硬实时或严格固实时。
|
||||
|
||||
把两类任务简单部署在同一 Linux 系统中,会产生调度、中断、内存带宽、DMA、功耗和故障传播问题;把完整 AI 软件栈迁入 RTOS,又会面临驱动、运行时、模型生态和不可控加速器执行路径问题。
|
||||
|
||||
## 2. 研究对象
|
||||
|
||||
本项目研究的是机器人大小脑异构系统,而不是单独研究 RTOS 或大模型:
|
||||
|
||||
| 子系统 | 工程角色 | 主要软件 |
|
||||
|---|---|---|
|
||||
| 大脑域 | 环境理解、模型推理、任务规划、技能选择 | Linux、ROS 2、LLM/VLM/VLA、GPU/NPU 运行时 |
|
||||
| 技能与安全接口 | 命令结构化、白名单技能、期限和约束检查 | 跨域协议、安全监控器、行为管理器 |
|
||||
| 小脑域 | 状态估计、轨迹跟踪、关节控制、联锁和降级 | RTOS、控制算法、关键设备驱动 |
|
||||
| 隔离层 | CPU、内存、设备、中断和故障域分区 | Hypervisor、AMP、IOMMU 或静态硬件分区 |
|
||||
|
||||
## 3. 核心研究问题
|
||||
|
||||
> 在机器人大小脑异构平台中,如何建立跨域时间契约和资源隔离机制,使动态、不可完全预测的大脑负载不会破坏小脑控制的实时边界,并使大脑输出能够被安全、按期地使用?
|
||||
|
||||
分解为五个问题:
|
||||
|
||||
1. 大脑负载通过哪些 CPU、缓存、内存、I/O、中断、DMA 和热路径干扰小脑控制?
|
||||
2. 静态分核与 Hypervisor 分域能够隔离哪些干扰,仍有哪些共享硬件干扰无法消除?
|
||||
3. 大小脑之间应采用什么时间契约、消息语义和队列策略?
|
||||
4. 大脑输出迟到、过期、错误或低置信度时,小脑如何在规定时间内回退?
|
||||
5. 大脑域、加速器或通信通道故障时,机器人能否持续受控并完成隔离和恢复?
|
||||
|
||||
## 4. 研究边界
|
||||
|
||||
### 纳入范围
|
||||
|
||||
- 机器人本体或近端边缘计算平台;
|
||||
- RTOS 小脑与 Linux 大脑并行运行;
|
||||
- 控制任务 deadline、AI 结果期限和新鲜度;
|
||||
- 跨域通信、共享资源干扰、故障隔离和安全降级;
|
||||
- 大模型、视觉或规划作为大脑压力负载。
|
||||
|
||||
### 不作为主线
|
||||
|
||||
- 大模型训练;
|
||||
- T1 多节点集群吞吐优化;
|
||||
- 证明大模型本身具备硬实时性;
|
||||
- 用平均推理时延替代机器人控制实时性;
|
||||
- 让自然语言输出直接控制电机力矩。
|
||||
|
||||
## 5. 基本原则
|
||||
|
||||
1. 小脑不依赖大脑即可维持基本稳定和安全状态。
|
||||
2. 大脑输出的是目标、技能或受约束轨迹,不直接绕过控制器驱动执行器。
|
||||
3. 小脑不得同步阻塞等待大脑推理完成。
|
||||
4. 所有大脑输出必须携带时间戳、序号、有效期、状态和必要的安全约束。
|
||||
5. Hypervisor 只是一种隔离手段,隔离效果必须通过压力和故障实验验证。
|
||||
|
||||
## 6. 预期贡献
|
||||
|
||||
- 一套面向大小脑系统的多时间尺度任务模型;
|
||||
- 一套有期限、有新鲜度、有回退语义的跨域通信契约;
|
||||
- 一套 RTOS/Linux/Hypervisor 资源和故障隔离机制;
|
||||
- 一套覆盖正常、过载、热稳态和故障状态的实验方法;
|
||||
- 大脑智能能力、控制实时性和资源代价之间的适用边界。
|
||||
@@ -0,0 +1,90 @@
|
||||
# 整体研究框架
|
||||
|
||||
## 1. 系统架构
|
||||
|
||||
```text
|
||||
操作员/任务系统
|
||||
│
|
||||
▼
|
||||
┌────────────────────────────────────────────┐
|
||||
│ Linux 大脑域 │
|
||||
│ 感知、LLM/VLM/VLA、任务规划、技能选择 │
|
||||
│ GPU/NPU、ROS 2、模型运行时 │
|
||||
└──────────────────┬─────────────────────────┘
|
||||
│ 有界异步命令
|
||||
│ 序号/时间戳/期限/有效期
|
||||
┌──────────────────▼─────────────────────────┐
|
||||
│ RTOS 小脑域 │
|
||||
│ 安全校验、状态估计、轨迹跟踪、关节控制 │
|
||||
│ 现场总线、联锁、超时回退、安全状态 │
|
||||
└──────────────────┬─────────────────────────┘
|
||||
│ 周期控制量
|
||||
▼
|
||||
执行器与机器人本体
|
||||
|
||||
Hypervisor / AMP / IOMMU / 静态资源分区
|
||||
```
|
||||
|
||||
传感数据按需求分别进入大小脑:高频本体反馈优先直达小脑,图像、语音和复杂环境信息主要进入大脑。关键安全传感器不得仅通过 Linux 域转发。
|
||||
|
||||
## 2. 三层时间模型
|
||||
|
||||
| 层次 | 典型任务 | 时间属性 | 主要指标 |
|
||||
|---|---|---|---|
|
||||
| L1 控制闭环 | 关节控制、姿态稳定、联锁 | 硬实时/严格固实时 | deadline、jitter、最大响应时间 |
|
||||
| L2 技能与决策窗口 | 轨迹片段、目标位姿、避障决策 | 固实时 | 按期率、新鲜度、回退率 |
|
||||
| L3 认知与交互 | 语言理解、长任务规划、解释 | 软实时 | TTFT、端到端延迟、任务成功率 |
|
||||
|
||||
基本约束为:
|
||||
|
||||
```text
|
||||
R_control <= D_control
|
||||
|
||||
采用大脑结果时:
|
||||
R_brain <= D_brain AND age(result) <= A_max
|
||||
|
||||
大脑不可用时:
|
||||
R_fallback <= D_fallback
|
||||
```
|
||||
|
||||
## 3. 三条研究主线
|
||||
|
||||
### 主线一:时间契约
|
||||
|
||||
- 规定大脑输出的期限、有效期和更新频率;
|
||||
- 把大脑输出转换为结构化技能或轨迹约束;
|
||||
- 对迟到、乱序、重复和低置信度结果定义统一处理;
|
||||
- 保证小脑在没有新命令时仍能连续控制。
|
||||
|
||||
### 主线二:资源与故障隔离
|
||||
|
||||
- 为小脑保留 CPU 核、内存、定时器和关键 I/O;
|
||||
- 路由关键中断到 RTOS 域;
|
||||
- 限制 Linux 和加速器 DMA 范围;
|
||||
- 测量 LLC、DRAM、互联、功耗和热等残余共享干扰;
|
||||
- 验证一个域崩溃或重启时另一域的持续运行能力。
|
||||
|
||||
### 主线三:联合评价
|
||||
|
||||
不能只报告控制延迟,也不能只报告大模型速度。结论必须联合回答:
|
||||
|
||||
- 小脑控制是否按时;
|
||||
- 大脑结果是否按期且有效;
|
||||
- 分域使用了多少静态资源;
|
||||
- 推理吞吐和能效付出了多少代价;
|
||||
- 故障与恢复期间机器人是否保持受控。
|
||||
|
||||
## 4. 研究假设
|
||||
|
||||
- H1:大脑负载会通过共享资源显著扩大控制尾延迟。
|
||||
- H2:RTOS/Linux 分域能够降低调度、中断和故障传播影响,但不能自动消除内存带宽与热耦合。
|
||||
- H3:有界异步时间契约能够避免小脑等待大脑,并降低过期决策进入执行路径的风险。
|
||||
- H4:准入、限流和故障降级可扩大“控制无违约且 AI 结果仍有用”的运行区域。
|
||||
|
||||
## 5. 研究成果形态
|
||||
|
||||
- 原型系统:RTOS 小脑域、Linux 大脑域与隔离层;
|
||||
- 跨域协议:请求、响应、心跳、超时和版本管理;
|
||||
- 实验工具:时间戳、压力发生、故障注入和物理链路测量;
|
||||
- 数据集:控制周期、大脑请求、功耗热状态和故障事件的对齐时间序列;
|
||||
- 论文结论:适用边界、收益来源和残余风险。
|
||||
@@ -0,0 +1,80 @@
|
||||
# 大小脑时间契约与跨域通信
|
||||
|
||||
## 1. 接口原则
|
||||
|
||||
大小脑之间采用异步、有界、可超时和可丢弃的消息通道。小脑控制线程不得执行无限等待、动态扩容或不可控的大块数据复制。
|
||||
|
||||
大脑输出应从开放文本收敛为受约束结构:
|
||||
|
||||
```text
|
||||
任务目标 → 白名单技能 → 参数与约束 → 小脑验证 → 执行
|
||||
```
|
||||
|
||||
## 2. 消息模型
|
||||
|
||||
### 请求
|
||||
|
||||
| 字段 | 含义 |
|
||||
|---|---|
|
||||
| `request_id` | 唯一序号 |
|
||||
| `sample_time` | 输入数据采样时刻 |
|
||||
| `deadline` | 最晚可用时刻 |
|
||||
| `task_class` | 感知、规划、诊断或交互类别 |
|
||||
| `priority` | 域内服务优先级提示 |
|
||||
| `payload_ref` | 受控共享缓冲区引用 |
|
||||
| `schema_version` | 接口版本 |
|
||||
|
||||
### 响应
|
||||
|
||||
| 字段 | 含义 |
|
||||
|---|---|
|
||||
| `request_id` | 请求匹配 |
|
||||
| `finish_time` | 推理完成时刻 |
|
||||
| `valid_until` | 结果失效时刻 |
|
||||
| `model_version` | 模型版本和审计信息 |
|
||||
| `confidence/status` | 结果质量与错误状态 |
|
||||
| `skill_id` | 白名单技能编号 |
|
||||
| `constraints` | 速度、力、空间和持续时间约束 |
|
||||
| `checksum` | 完整性校验 |
|
||||
|
||||
## 3. 小脑消费条件
|
||||
|
||||
```text
|
||||
accept(result) =
|
||||
id_match
|
||||
AND schema_valid
|
||||
AND checksum_valid
|
||||
AND finish_time <= deadline
|
||||
AND now <= valid_until
|
||||
AND confidence >= threshold
|
||||
AND skill_is_whitelisted
|
||||
AND constraints_passed
|
||||
```
|
||||
|
||||
拒绝结果后,小脑执行保持、传统控制、减速、停车或其他预定义回退,不等待大脑重新计算。
|
||||
|
||||
## 4. 通信实现候选
|
||||
|
||||
| 方式 | 优点 | 风险 | 适用场景 |
|
||||
|---|---|---|---|
|
||||
| 共享内存环形队列 + 通知 | 低复制、可控队列 | 缓存一致性和内存访问权限 | 同 SoC 分域主方案 |
|
||||
| RPMsg/邮箱 | SoC 生态常见、域间明确 | 消息大小和驱动能力受限 | MCU + 应用核 |
|
||||
| 虚拟设备 | 与 Hypervisor 集成 | VM exit 和虚拟中断开销 | 虚拟机分区 |
|
||||
| 以太网/TSN | 物理隔离、易扩展 | 网络栈与同步误差 | 双机大小脑 |
|
||||
|
||||
## 5. 队列策略
|
||||
|
||||
- 队列必须有固定容量;
|
||||
- 状态类消息可采用“只保留最新值”;
|
||||
- 事务类技能命令不得静默覆盖;
|
||||
- 大脑过载时优先拒绝低价值请求;
|
||||
- 小脑记录丢弃、超时、覆盖和回退原因;
|
||||
- 域重启后通过 epoch 或会话号拒绝旧消息。
|
||||
|
||||
## 6. 验证重点
|
||||
|
||||
- IPC 单向、往返、P99.9 和观测最大时延;
|
||||
- 消息大小、频率和队列深度的影响;
|
||||
- 队列满、乱序、重复、损坏和版本不一致;
|
||||
- 大脑域重启后的旧消息隔离;
|
||||
- 通信线程是否影响控制核和关键中断。
|
||||
@@ -0,0 +1,67 @@
|
||||
# Hypervisor 隔离、故障与降级
|
||||
|
||||
## 1. 隔离对象
|
||||
|
||||
| 资源 | 推荐归属 | 验证问题 |
|
||||
|---|---|---|
|
||||
| 控制 CPU 核 | RTOS 独占 | Linux 满载时是否发生调度干扰 |
|
||||
| 关键内存 | RTOS 静态分区 | Linux OOM、换页或内存压力是否影响控制 |
|
||||
| 电机/编码器/现场总线 | RTOS 直通 | 中断和 DMA 是否经过 Linux |
|
||||
| GPU/NPU/摄像头 | Linux 独占 | 设备复位是否影响 RTOS |
|
||||
| 共享内存 | 最小固定区域 | 越界、缓存一致性和拥塞 |
|
||||
| 网络/存储 | Linux 为主 | 高频 IRQ 是否污染控制核 |
|
||||
|
||||
## 2. 残余共享干扰
|
||||
|
||||
分核和虚拟化不能自动消除:
|
||||
|
||||
- LLC 和缓存互联竞争;
|
||||
- DRAM 带宽及内存控制器竞争;
|
||||
- SoC 总线与 DMA 拥塞;
|
||||
- 芯片级功耗限制;
|
||||
- 温度升高与全局降频;
|
||||
- 固件、系统管理中断和共享时钟源影响。
|
||||
|
||||
因此需要分别实施 CPU、缓存、内存、I/O 和热压力实验,不能用“已使用 Hypervisor”代替隔离证据。
|
||||
|
||||
## 3. 故障模型
|
||||
|
||||
- 大脑推理进程崩溃或永久阻塞;
|
||||
- Linux 域卡死、内核错误或重启;
|
||||
- GPU/NPU 驱动错误和设备复位;
|
||||
- 共享队列溢出、损坏或失联;
|
||||
- 大脑持续产生过期或不安全命令;
|
||||
- Linux 域 CPU、内存、网络和存储过载;
|
||||
- 热降频导致推理与控制执行时间漂移。
|
||||
|
||||
## 4. 降级状态机
|
||||
|
||||
```text
|
||||
智能增强运行
|
||||
│ 单次超时/低置信度
|
||||
▼
|
||||
保持当前安全技能或传统控制
|
||||
│ 连续超时/通信故障
|
||||
▼
|
||||
隔离并重启大脑域
|
||||
│ 本体风险上升
|
||||
▼
|
||||
减速、停车或安全状态
|
||||
```
|
||||
|
||||
每个状态必须规定进入条件、最大驻留时间、控制策略、可用传感器、允许执行器动作和恢复条件。
|
||||
|
||||
## 5. 安全监控职责
|
||||
|
||||
安全监控器位于 RTOS 小脑域或独立安全核,至少负责:
|
||||
|
||||
- 大脑心跳与期限监控;
|
||||
- 命令白名单和参数范围检查;
|
||||
- 速度、力矩、工作空间和碰撞约束;
|
||||
- 过期结果拒绝;
|
||||
- 大脑域隔离与重启请求;
|
||||
- 本地停车和安全状态执行。
|
||||
|
||||
## 6. 核心结论边界
|
||||
|
||||
实验可以证明指定平台和压力范围内的隔离效果,但不能自动证明形式化的最坏情况边界。若要宣称硬实时或功能安全,还需要可信 WCET、可调度性分析、硬件干扰上界和相应安全生命周期证据。
|
||||
@@ -0,0 +1,67 @@
|
||||
# 实验设计
|
||||
|
||||
## 1. 对照组
|
||||
|
||||
| 编号 | 系统配置 | 作用 |
|
||||
|---|---|---|
|
||||
| A0 | 普通 Linux:控制与大脑负载同域 | 通用基线 |
|
||||
| A1 | PREEMPT_RT Linux:控制与大脑负载同域 | 实时 Linux 基线 |
|
||||
| A2 | RTOS 小脑 + Linux 大脑,基础分区 | 分域基线 |
|
||||
| A3 | A2 + CPU/IRQ/内存/IPC 治理 | 完整方案 |
|
||||
| A4 | A3 + 超时、降级和故障恢复 | 安全协同方案 |
|
||||
|
||||
对照固定机器人控制任务、AI 模型、输入到达序列、硬件频率和功率策略。若推理后端不同,结果表述为系统方案比较,不单独归因于内核。
|
||||
|
||||
## 2. 负载场景
|
||||
|
||||
| 场景 | 内容 | 目的 |
|
||||
|---|---|---|
|
||||
| L0 | 仅小脑控制 | 实时性下界 |
|
||||
| L1 | 仅大脑推理 | 推理容量与功耗基线 |
|
||||
| L2 | 控制 + 感知/大模型 | 核心共存场景 |
|
||||
| L3 | L2 + CPU/内存压力 | 共享资源干扰 |
|
||||
| L4 | L2 + 摄像头/网络/存储 I/O | IRQ 与 DMA 干扰 |
|
||||
| L5 | L2 + 突发请求和过载 | 队列与准入边界 |
|
||||
| L6 | L2 长时间运行至热稳态 | 功耗和降频耦合 |
|
||||
| L7 | 进程、域、加速器和通信故障 | 隔离、降级与恢复 |
|
||||
|
||||
## 3. 控制任务
|
||||
|
||||
至少包含:
|
||||
|
||||
- 高频周期控制任务;
|
||||
- 状态估计或轨迹跟踪任务;
|
||||
- 关键 I/O 或 GPIO 回环;
|
||||
- 安全监控与回退任务。
|
||||
|
||||
无真实机器人时,先使用硬件在环、倒立摆、电机台架或确定性控制负载;不得仅用空循环替代全部控制语义。
|
||||
|
||||
## 4. 大脑任务
|
||||
|
||||
按平台能力选择视觉、VLM、VLA 或 LLM。大脑输出必须转换为结构化技能命令。分别扫描:
|
||||
|
||||
- 请求率和突发强度;
|
||||
- 模型规模、输入长度和输出长度;
|
||||
- batch、队列长度与并发;
|
||||
- GPU/NPU 利用率;
|
||||
- 感知数据大小和通信频率。
|
||||
|
||||
## 5. 故障注入
|
||||
|
||||
依次实施:推理进程退出、请求永久阻塞、消息乱序或损坏、队列溢出、Linux 域重启、加速器错误。设备级故障只在具备可恢复路径时开展。
|
||||
|
||||
记录故障发生、检测、回退、隔离、重启和首个恢复结果的完整时间线。
|
||||
|
||||
## 6. 实施顺序
|
||||
|
||||
1. 冻结控制 deadline、大脑结果期限和回退期限。
|
||||
2. 完成 A0/A1 的同域基线。
|
||||
3. 建立 A2 基础分域和最小 IPC。
|
||||
4. 扫描 CPU、内存、I/O 和热干扰。
|
||||
5. 加入 A3 治理机制并逐项消融。
|
||||
6. 加入 A4 故障状态机并开展故障注入。
|
||||
7. 进行长稳实验和独立确认批次。
|
||||
|
||||
## 7. 最小闭环
|
||||
|
||||
一台具备 RTOS/Linux 分域条件的边缘平台、一个可测量的控制任务和一个真实 AI 大脑负载,即可形成最小验证闭环,不要求扩展到工作站或集群。
|
||||
@@ -0,0 +1,60 @@
|
||||
# 指标与证据
|
||||
|
||||
## 1. 小脑控制实时性
|
||||
|
||||
- 周期任务释放、开始和完成时间;
|
||||
- 响应时间与完成抖动;
|
||||
- P50/P95/P99/P99.9 和观测最大值;
|
||||
- deadline miss ratio,报告分子与分母;
|
||||
- 外部输入到执行器输出的物理链路时延;
|
||||
- 过载、热稳态和故障期间的控制表现。
|
||||
|
||||
## 2. 大脑结果可用性
|
||||
|
||||
- 大小脑端到端决策时延;
|
||||
- deadline-hit ratio;
|
||||
- 结果新鲜度合格率;
|
||||
- 超时、过期、乱序、损坏和拒绝率;
|
||||
- 模型任务质量与置信度;
|
||||
- 大脑不可用时的回退发生率。
|
||||
|
||||
## 3. 跨域与隔离代价
|
||||
|
||||
- IPC 单向/往返延迟及尾部;
|
||||
- 拷贝次数、CPU 开销和队列占用;
|
||||
- 静态保留的 CPU、内存和设备资源;
|
||||
- 分域前后的推理有效吞吐和能效;
|
||||
- Linux 满载相对小脑空载的控制延迟增量;
|
||||
- LLC、DRAM、I/O 和热压力的敏感度。
|
||||
|
||||
## 4. 故障与恢复
|
||||
|
||||
- 故障检测时间;
|
||||
- 回退完成时间;
|
||||
- 域隔离和重启时间;
|
||||
- 故障窗口内控制违约数;
|
||||
- 恢复后首个有效大脑结果时间;
|
||||
- 是否出现不可恢复故障或错误动作。
|
||||
|
||||
## 5. 联合判定
|
||||
|
||||
系统配置只有同时满足下列条件才算有效:
|
||||
|
||||
```text
|
||||
控制任务满足期限
|
||||
AND 大脑结果达到规定的按期率与质量
|
||||
AND 超时结果不会进入执行路径
|
||||
AND 故障时在期限内完成回退
|
||||
AND 资源和能耗代价可接受
|
||||
```
|
||||
|
||||
平均推理时延降低但控制违约增加,不构成系统实时性改善;控制零违约但所有 AI 请求都被拒绝,也不构成有效协同。
|
||||
|
||||
## 6. 推荐核心图表
|
||||
|
||||
1. 大脑负载强度—控制违约率—结果按期率可行域;
|
||||
2. 单域与分域方案的控制尾延迟对比;
|
||||
3. CPU、内存、I/O 和热干扰消融图;
|
||||
4. 跨域时序分解图;
|
||||
5. 大脑故障期间控制时间序列;
|
||||
6. 静态资源预留与推理有效吞吐 Pareto 曲线。
|
||||
@@ -0,0 +1,45 @@
|
||||
# 项目框架2:面向机器人大小脑异构系统的实时保障研究
|
||||
|
||||
## 一句话定位
|
||||
|
||||
本项目研究机器人“大脑—小脑”异构系统的系统级实时保障:Linux 大脑域承担感知、推理与规划,RTOS 小脑域承担运动控制和安全保护,Hypervisor 或等价分区机制负责资源与故障隔离。
|
||||
|
||||
## 核心问题
|
||||
|
||||
> 当大模型、视觉和规划负载具有动态执行时间且可能过载或故障时,如何保证机器人控制闭环持续满足截止期,并使大脑输出只在满足时限、新鲜度和安全约束时进入执行路径?
|
||||
|
||||
## 与另外两套框架的区别
|
||||
|
||||
| 框架 | 研究主语 | 核心场景 | 本框架中的地位 |
|
||||
|---|---|---|---|
|
||||
| 框架1 | 大型跨平台 RTOS | T5~T1 五类部署形态 | 机制与设备资料来源,不作为本框架的统一谱系 |
|
||||
| 框架2 | 机器人大小脑异构系统 | RTOS 控制域 + Linux 推理域 | 当前目录的主线 |
|
||||
| 框架3 | MCU/资源受限 SoC | 轻量 AI 与实时控制同节点共存 | 小脑侧 AI 的专题补充 |
|
||||
|
||||
## 目录结构
|
||||
|
||||
- `00-项目总览/01-研究问题、定位与边界.md`
|
||||
- 研究对象、工业场景、核心假设和结论边界
|
||||
- `10-研究框架/00-整体研究框架.md`
|
||||
- 大小脑架构、三层时间模型与研究主线
|
||||
- `10-研究框架/01-大小脑时间契约与跨域通信.md`
|
||||
- 命令语义、结果新鲜度、有界 IPC 和时序约束
|
||||
- `10-研究框架/02-Hypervisor隔离、故障与降级.md`
|
||||
- CPU、内存、中断、DMA、热干扰和故障恢复
|
||||
- `20-实验与规划/01-实验设计.md`
|
||||
- 对照组、压力场景、故障注入和实施顺序
|
||||
- `20-实验与规划/02-指标与证据.md`
|
||||
- 控制实时性、大脑结果可用性和系统代价指标
|
||||
|
||||
## 推荐阅读顺序
|
||||
|
||||
1. `00-项目总览/01-研究问题、定位与边界.md`
|
||||
2. `10-研究框架/00-整体研究框架.md`
|
||||
3. `10-研究框架/01-大小脑时间契约与跨域通信.md`
|
||||
4. `10-研究框架/02-Hypervisor隔离、故障与降级.md`
|
||||
5. `20-实验与规划/01-实验设计.md`
|
||||
6. `20-实验与规划/02-指标与证据.md`
|
||||
|
||||
## 推荐课题名称
|
||||
|
||||
> **面向机器人大小脑异构系统的分域实时保障与安全协同机制研究**
|
||||
@@ -0,0 +1,44 @@
|
||||
# 研究问题、定位与边界
|
||||
|
||||
## 1. 问题背景
|
||||
|
||||
MCU 和资源受限 SoC 原本承担周期控制、采集、通信和保护任务。引入 AI 后,模型执行会持续占用 CPU/NPU、内存、缓存、总线、DMA 和功耗预算,导致控制抖动、关键中断延迟、内存不足或热降频。
|
||||
|
||||
该问题具有明确的工业实时属性:AI 可以降质、跳帧或暂停,但关键控制任务和安全保护不能因为 AI 负载而失去截止期。
|
||||
|
||||
## 2. 核心研究问题
|
||||
|
||||
1. 轻量 AI 通过哪些资源路径影响控制任务?
|
||||
2. 如何为 AI 分配可执行时间、内存、带宽和功耗预算?
|
||||
3. AI 负载超过容量时,如何限流、跳帧、切换模型或暂停执行?
|
||||
4. 模型精度、结果期限、控制实时性和能耗之间如何联合优化?
|
||||
5. 不同 MCU/SoC 上哪些机制可迁移,哪些依赖具体硬件?
|
||||
|
||||
## 3. 研究范围
|
||||
|
||||
### 纳入范围
|
||||
|
||||
- MCU、带 NPU 的工业 SoC 和控制器;
|
||||
- AI 与控制任务同 OS 或同芯片共存;
|
||||
- 固定优先级、预算服务器、准入和过载降级;
|
||||
- 静态内存、DMA、缓存、总线、功耗和热管理;
|
||||
- GPIO、CAN、RS485、工业以太网等物理响应。
|
||||
|
||||
### 不纳入主线
|
||||
|
||||
- 大模型训练和多节点集群;
|
||||
- 为补齐 T1~T5 而采购全谱系设备;
|
||||
- 只测 tokens/s 或平均推理速度;
|
||||
- 在设备无法真实运行时估算模型性能;
|
||||
- 把零违约实测表述为理论硬实时证明。
|
||||
|
||||
## 4. 基本假设
|
||||
|
||||
- H1:AI 对控制的主要影响不仅来自 CPU,还来自内存、DMA、中断和热耦合。
|
||||
- H2:预算、预分配和准入可以扩大控制无违约的 AI 运行范围。
|
||||
- H3:过载时主动降低 AI 服务质量,比继续排队更有利于维持系统可预测性。
|
||||
- H4:满足相同控制和 AI 约束时,可以找到能耗更低的模型、频率与执行策略。
|
||||
|
||||
## 5. 成果边界
|
||||
|
||||
本研究证明的是指定设备、任务和环境下的容量边界与机制收益。不同芯片的 NPU 固件、内存控制器和功耗策略不同,不能仅按内存容量把结果直接外推。
|
||||
@@ -0,0 +1,59 @@
|
||||
# 整体研究框架
|
||||
|
||||
## 1. 系统模型
|
||||
|
||||
```text
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ 安全与关键控制任务 │
|
||||
│ 周期控制、联锁、关键采集、现场总线 │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ AI 目标任务 │
|
||||
│ 检测、估计、识别、诊断、轻量智能决策 │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ 伴生任务 │
|
||||
│ 日志、通信、更新、存储和非关键后台服务 │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ RTOS/嵌入式系统治理 │
|
||||
│ 优先级、预算、准入、预分配、中断与降级 │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ MCU/SoC:CPU、NPU、RAM、缓存、总线、DMA、热 │
|
||||
└─────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 2. 优先级原则
|
||||
|
||||
1. 安全与关键控制任务优先满足 deadline;
|
||||
2. AI 任务在剩余时间和资源预算内执行;
|
||||
3. AI 结果超过有效期后不再进入控制路径;
|
||||
4. 伴生任务不得挤占控制和已准入 AI 的预算;
|
||||
5. 过载时优先降低 AI 频率、模型复杂度或输入质量。
|
||||
|
||||
## 3. 四维预算
|
||||
|
||||
| 预算 | 控制手段 | 典型风险 |
|
||||
|---|---|---|
|
||||
| 时间预算 | 固定优先级、时间服务器、分块执行 | 长算子和不可抢占段 |
|
||||
| 内存预算 | 静态分配、内存池、峰值准入 | OOM、碎片、共享缓冲区 |
|
||||
| 带宽预算 | DMA 编排、访问节流、采样降频 | 控制数据被 AI 挤占 |
|
||||
| 功耗预算 | DVFS、模型切换、占空比控制 | 热降频反向破坏实时性 |
|
||||
|
||||
## 4. 运行状态
|
||||
|
||||
```text
|
||||
S0 控制优先、AI 正常运行
|
||||
S1 AI 降频或跳帧
|
||||
S2 切换轻量模型或低精度模式
|
||||
S3 暂停 AI,保留传统控制
|
||||
S4 故障安全状态
|
||||
```
|
||||
|
||||
状态切换依据控制裕量、队列长度、内存水位、温度、功耗和 AI 结果质量。切换过程本身必须有界,并避免关键路径动态加载大型模型。
|
||||
|
||||
## 5. 研究主线
|
||||
|
||||
- AI WCET/执行时间分布与可抢占结构分析;
|
||||
- 控制任务响应时间和共享资源干扰分析;
|
||||
- AI 多维预算与准入控制;
|
||||
- 精度、执行频率和功耗联合降级;
|
||||
- 长时间热稳态和异常恢复;
|
||||
- 跨设备可迁移机制与芯片特定机制区分。
|
||||
@@ -0,0 +1,54 @@
|
||||
# AI 预算调度与控制保护
|
||||
|
||||
## 1. 任务模型
|
||||
|
||||
控制任务表示为:
|
||||
|
||||
```text
|
||||
τc = (Tc, Dc, Cc, Pc)
|
||||
```
|
||||
|
||||
其中 `T` 为周期、`D` 为截止期、`C` 为执行需求、`P` 为优先级。
|
||||
|
||||
AI 任务表示为:
|
||||
|
||||
```text
|
||||
τai = (arrival, deadline, budget_cpu, budget_mem,
|
||||
budget_power, quality_level, droppable)
|
||||
```
|
||||
|
||||
AI 任务必须声明是否可丢弃、是否允许跳帧以及可接受的最低质量等级。
|
||||
|
||||
## 2. 调度原则
|
||||
|
||||
- 控制任务使用固定优先级或已验证的实时调度策略;
|
||||
- AI 使用低优先级后台、预算服务器或可中止任务;
|
||||
- 将长推理拆分为可抢占或可中断阶段;
|
||||
- 不可抢占 NPU/GPU 执行段必须测量并纳入控制响应时间;
|
||||
- AI 请求只有在时间、内存和功耗预算同时满足时才准入。
|
||||
|
||||
## 3. 准入条件
|
||||
|
||||
```text
|
||||
schedulable(control | ai_load)
|
||||
AND peak_memory <= M_budget
|
||||
AND predicted_power <= P_budget
|
||||
AND result_deadline_feasible
|
||||
AND quality >= Q_min
|
||||
```
|
||||
|
||||
准入失败时,系统可以拒绝请求、推迟非关键输入、跳帧或选择更小模型,不能无限排队。
|
||||
|
||||
## 4. 控制保护机制
|
||||
|
||||
- 控制代码、数据和栈静态分配;
|
||||
- AI 与控制使用独立内存池;
|
||||
- 关键中断优先于 NPU、摄像头和通信完成中断;
|
||||
- 日志采用预分配缓冲并异步输出;
|
||||
- AI 执行前检查控制裕量;
|
||||
- AI 超时后结果直接失效;
|
||||
- 看门狗覆盖 AI 运行时和设备驱动卡死。
|
||||
|
||||
## 5. 消融验证
|
||||
|
||||
逐项移除预算服务器、内存池、中断隔离、准入和降级机制,比较控制尾延迟、AI 按期率和能耗,识别收益来源。
|
||||
@@ -0,0 +1,55 @@
|
||||
# 内存、功耗、热与降级
|
||||
|
||||
## 1. 内存治理
|
||||
|
||||
模型准入按完整峰值计算:
|
||||
|
||||
```text
|
||||
M_total = M_weight + M_activation + M_workspace
|
||||
+ M_io + M_runtime + M_control_reserved
|
||||
```
|
||||
|
||||
必须为控制任务、关键通信和故障日志保留不可侵占空间。权重大小不能代替峰值内存测量。
|
||||
|
||||
推荐机制:
|
||||
|
||||
- 模型和工作区静态加载;
|
||||
- 固定大小内存池;
|
||||
- 禁止关键窗口模型切换;
|
||||
- DMA 缓冲区白名单和容量上限;
|
||||
- OOM 前主动降低 AI 并发或切换模型。
|
||||
|
||||
## 2. 功耗与热耦合
|
||||
|
||||
AI 满载可能触发整芯片功耗限制或热降频,进而增加控制任务执行时间。实验必须同步记录:
|
||||
|
||||
- 整机功率;
|
||||
- 芯片温度;
|
||||
- CPU/NPU 实际频率;
|
||||
- AI 执行阶段;
|
||||
- 控制响应时间和违约;
|
||||
- 降频事件。
|
||||
|
||||
## 3. 降级策略
|
||||
|
||||
| 触发条件 | 优先动作 |
|
||||
|---|---|
|
||||
| 控制裕量下降 | 降低 AI 请求率或跳帧 |
|
||||
| AI 队列增长 | 拒绝低优先级请求 |
|
||||
| 内存水位过高 | 减少并发或切换小模型 |
|
||||
| 温度接近阈值 | 降低 AI 占空比或精度 |
|
||||
| 连续 AI 超时 | 暂停 AI,保留传统控制 |
|
||||
| 驱动或设备故障 | 复位 AI 子系统并进入安全模式 |
|
||||
|
||||
## 4. 能效口径
|
||||
|
||||
不能仅比较最低功率,应在相同控制实时约束和 AI 质量约束下比较:
|
||||
|
||||
- 单次有效推理能耗;
|
||||
- 有效结果/焦耳;
|
||||
- 控制无违约条件下的持续 AI 吞吐;
|
||||
- 热稳态而非冷机短时能效。
|
||||
|
||||
## 5. 结论边界
|
||||
|
||||
动态量化、模型切换和 DVFS 只有在切换开销已测量且不破坏控制 deadline 时,才能称为实时感知的低功耗策略。
|
||||
@@ -0,0 +1,64 @@
|
||||
# 实验设计
|
||||
|
||||
## 1. 平台选择
|
||||
|
||||
建议最少包含:
|
||||
|
||||
- 一个 MCU 或低资源控制器,用于 TinyML/轻量 AI 与周期控制共存;
|
||||
- 一个带 NPU 的资源受限 SoC,用于统一内存、DMA 和热干扰;
|
||||
- 必要的功率计、逻辑分析仪或示波器以及 CAN/RS485 对端。
|
||||
|
||||
设备按真实 AI 运行能力选择,不以补齐 T1~T5 为目标。
|
||||
|
||||
## 2. 对照组
|
||||
|
||||
| 编号 | 配置 |
|
||||
|---|---|
|
||||
| C0 | 仅控制任务 |
|
||||
| C1 | 控制 + AI 默认配置 |
|
||||
| C2 | C1 + 优先级和中断隔离 |
|
||||
| C3 | C2 + 时间/内存/功耗预算与准入 |
|
||||
| C4 | C3 + 模型降级和故障恢复 |
|
||||
|
||||
## 3. 压力场景
|
||||
|
||||
| 场景 | 内容 |
|
||||
|---|---|
|
||||
| M0 | 控制空载基线 |
|
||||
| M1 | AI 独立运行 |
|
||||
| M2 | 控制 + AI |
|
||||
| M3 | M2 + CPU/缓存压力 |
|
||||
| M4 | M2 + 内存/DMA 压力 |
|
||||
| M5 | M2 + I/O/中断压力 |
|
||||
| M6 | AI 突发和过载 |
|
||||
| M7 | 热稳态和降频 |
|
||||
| M8 | OOM、超时、运行时或设备故障 |
|
||||
|
||||
## 4. 变量扫描
|
||||
|
||||
- 控制周期、执行预算和关键 I/O 频率;
|
||||
- AI 模型、精度、输入尺寸和执行频率;
|
||||
- CPU/NPU 频率与功率模式;
|
||||
- 内存预算和 DMA 缓冲区大小;
|
||||
- AI 队列深度、跳帧率和超时期限;
|
||||
- 环境温度和持续运行时间。
|
||||
|
||||
## 5. 实施顺序
|
||||
|
||||
1. 验证控制任务和物理计时链路。
|
||||
2. 完成模型正确性、峰值内存和独立能耗准入。
|
||||
3. 运行 C0/C1,确认 AI 实际产生的干扰。
|
||||
4. 依次加入 C2~C4 并做逐项消融。
|
||||
5. 扫描负载直到出现控制违约或 AI 服务失效。
|
||||
6. 在选定边界附近进行热稳态与长时间实验。
|
||||
7. 使用冻结配置进行独立确认批次。
|
||||
|
||||
## 6. 停止条件
|
||||
|
||||
- 控制任务出现不可接受违约;
|
||||
- 温度、电压或电流超过设备安全范围;
|
||||
- 测量链路丢样或时钟失效;
|
||||
- 内存不足导致无法保持关键任务;
|
||||
- AI 后端不支持目标模型或精度。
|
||||
|
||||
停止不代表实验失败,应记录为容量或适配边界。
|
||||
@@ -0,0 +1,58 @@
|
||||
# 指标与证据
|
||||
|
||||
## 1. 控制实时性
|
||||
|
||||
- 任务响应时间、完成抖动和观测最大值;
|
||||
- deadline miss ratio;
|
||||
- 中断响应和关键 I/O 端到端时延;
|
||||
- AI 启停、模型切换和降频瞬间的时间序列;
|
||||
- 故障与恢复窗口内的控制表现。
|
||||
|
||||
## 2. AI 服务有效性
|
||||
|
||||
- 推理端到端时延和按期率;
|
||||
- 有效结果率、任务质量和超时率;
|
||||
- 跳帧、拒绝和降级比例;
|
||||
- 模型切换时间;
|
||||
- 控制无违约条件下的最大持续 AI 负载。
|
||||
|
||||
## 3. 资源与能耗
|
||||
|
||||
- 峰值和稳态内存;
|
||||
- CPU/NPU 利用率与执行占空比;
|
||||
- 内存带宽或可取得的代理指标;
|
||||
- 整机平均功率、峰值功率和能量;
|
||||
- 温度、实际频率和降频时间比例;
|
||||
- 单次有效结果能耗和有效结果/焦耳。
|
||||
|
||||
## 4. 核心结果表达
|
||||
|
||||
推荐把结果组织为“安全运行区”:
|
||||
|
||||
```text
|
||||
控制 deadline 满足
|
||||
AND AI 质量 >= Q_min
|
||||
AND AI 按期率 >= H_min
|
||||
AND 功耗 <= P_max
|
||||
AND 温度 <= Temp_max
|
||||
```
|
||||
|
||||
扫描 AI 频率、模型复杂度和功耗模式,绘制满足全部条件的可行区域及其边界。
|
||||
|
||||
## 5. 不应使用的证据替代
|
||||
|
||||
- 平均延迟不能替代 deadline miss ratio;
|
||||
- 短时冷机性能不能替代热稳态;
|
||||
- 模型权重大小不能替代峰值内存;
|
||||
- 芯片标称 TOPS 不能替代实测完成时间;
|
||||
- 零违约不能直接表述为理论硬实时保证;
|
||||
- 降低 AI 完成率获得的低功耗不能单独称为能效提升。
|
||||
|
||||
## 6. 推荐图表
|
||||
|
||||
1. AI 负载—控制尾延迟与违约率曲线;
|
||||
2. 时间、内存、功耗预算消融图;
|
||||
3. 模型质量—按期率—能耗 Pareto 图;
|
||||
4. 热稳态下温度、频率、控制延迟时间序列;
|
||||
5. 过载状态下跳帧、降级和恢复过程;
|
||||
6. 不同 MCU/SoC 的机制可迁移性对比表。
|
||||
@@ -0,0 +1,32 @@
|
||||
# 项目框架3:MCU 与资源受限 SoC 的 AI 实时性与低功耗研究
|
||||
|
||||
## 一句话定位
|
||||
|
||||
本项目研究 MCU 和资源受限 SoC 引入轻量 AI 后的实时干扰、资源预算、低功耗运行与安全降级问题,形成“控制期限优先、AI 预算执行、过载主动降级”的端侧智能方法。
|
||||
|
||||
## 核心问题
|
||||
|
||||
> 在 CPU、内存、带宽、功耗和散热均受限的控制节点中,允许多大的 AI 负载,才能在不破坏周期控制和关键 I/O 截止期的前提下获得有效智能功能?
|
||||
|
||||
## 研究对象说明
|
||||
|
||||
这里的 AI 不默认等于大语言模型。根据硬件能力,可以是:
|
||||
|
||||
- TinyML 和小型神经网络;
|
||||
- 异常检测与预测维护模型;
|
||||
- 轻量视觉、语音和状态识别;
|
||||
- 学习型状态估计或控制补偿;
|
||||
- 能在目标设备真实运行的小型语言模型。
|
||||
|
||||
## 目录结构
|
||||
|
||||
- `00-项目总览/01-研究问题、定位与边界.md`
|
||||
- `10-研究框架/00-整体研究框架.md`
|
||||
- `10-研究框架/01-AI预算调度与控制保护.md`
|
||||
- `10-研究框架/02-内存、功耗、热与降级.md`
|
||||
- `20-实验与规划/01-实验设计.md`
|
||||
- `20-实验与规划/02-指标与证据.md`
|
||||
|
||||
## 推荐课题名称
|
||||
|
||||
> **资源受限嵌入式控制系统中 AI 负载的实时预算与低功耗协同机制研究**
|
||||
Reference in New Issue
Block a user