forked from eaiadmin/rtos_llm_opt
docs: reorganize MCU static intelligence research materials
This commit is contained in:
@@ -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。
|
||||
@@ -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、驱动或时间戳的黑盒设备;
|
||||
- 仅通过降低任务完成率来获得更好实时性或能耗结果。
|
||||
@@ -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)
|
||||
@@ -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)。
|
||||
@@ -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>
|
||||
@@ -0,0 +1,22 @@
|
||||
# 10-技术框架
|
||||
|
||||
本层回答“静态智能控制基础系统如何设计和生成”。
|
||||
|
||||
## 文件
|
||||
|
||||
1. [00-总体技术路线.md](./00-总体技术路线.md):四层架构、核心机制、工具链和SylixOS映射;
|
||||
2. [01-离线联合编排研究框架.md](./01-离线联合编排研究框架.md):六步编排流程、准入门槛、配置产物和板端校准。
|
||||
|
||||
## 核心链路
|
||||
|
||||
```text
|
||||
控制任务 + 模型 + 平台
|
||||
↓
|
||||
内存规划 + 时间编排 + 准入检查
|
||||
↓
|
||||
SylixOS工程生成
|
||||
↓
|
||||
超时、规则兜底与恢复
|
||||
```
|
||||
|
||||
[返回总目录](../README.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、驱动或推理运行时不可用,停止对应路径,输出适配缺口,不把计划写成实测结果。
|
||||
@@ -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、内存和突发干扰;
|
||||
- [ ] 至少完成一次超时和任务异常注入;
|
||||
- [ ] 预测内存与实测内存完成比较;
|
||||
- [ ] 得出静态联合编排是否改善控制边界的结论。
|
||||
@@ -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频率和亲和性已确认;
|
||||
- [ ] 输入、随机种子和负载序列已冻结;
|
||||
- [ ] 测量设备和采样率已确认;
|
||||
- [ ] 数据目录空间充足;
|
||||
- [ ] 故障与无效批次记录方式已确认。
|
||||
@@ -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. 异常与后续动作
|
||||
|
||||
| 异常 | 初步原因 | 是否重跑 | 后续负责人 |
|
||||
|---|---|---|---|
|
||||
| | | | |
|
||||
@@ -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)
|
||||
+129
@@ -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扩展的共同基础。
|
||||
@@ -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小模型可执行;
|
||||
- 静态内存预算未超限;
|
||||
- 计时和日志链路可用。
|
||||
|
||||
任一核心条件不满足时,输出阻塞项和责任人,不通过降低测量标准强行进入正式实验。
|
||||
@@ -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)
|
||||
@@ -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. 论文、白皮书、工具和知识产权分工。
|
||||
@@ -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. 双方责任人和下一次检查节点。
|
||||
@@ -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极限结论。
|
||||
@@ -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)
|
||||
@@ -1,24 +1,83 @@
|
||||
# 子课题A:面向MCU的静态智能控制基础系统
|
||||
|
||||
本目录用于承接框架2中的第一个子课题,重点面向 `T5` 控制端与极小资源预算场景。
|
||||
本目录按“研究定义—技术框架—实验验证—实施管理—合作成果”分层管理,目标是把MCU研究方向落到现有RK3588、4×V100、SylixOS/RealEvo及后续控制端板卡上。
|
||||
|
||||
## 子课题定位
|
||||
## 一句话定位
|
||||
|
||||
本子课题重点研究:
|
||||
> 把轻量智能模型转换为具有固定资源上限、固定执行窗口和明确故障处理方式的实时任务,并在部署前判断其能否安全进入SylixOS控制系统。
|
||||
|
||||
> **在极小内存、极低功耗和强实时约束条件下,人工智能能力如何以静态、可分析、可部署的方式进入控制系统。**
|
||||
## 目录结构
|
||||
|
||||
## 建议阅读顺序
|
||||
```text
|
||||
子课题A
|
||||
├─ 00-总览与定位 研究对象、边界、问题和适用场景
|
||||
├─ 10-技术框架 总体技术路线与六步离线联合编排
|
||||
├─ 20-实验与验证 实验设计、冻结单和运行记录模板
|
||||
├─ 30-实施管理 设备路线图、工作包和两周计划
|
||||
├─ 40-合作与成果 翼辉合作、技术确认和成果组织
|
||||
└─ README.md 总导航
|
||||
```
|
||||
|
||||
1. [00-子课题定义.md](./00-子课题定义.md)
|
||||
2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md)
|
||||
3. [02-技术路线:静态编排、工具链与芯片协同.md](./02-技术路线:静态编排、工具链与芯片协同.md)
|
||||
4. [03-实验设计与验证方法.md](./03-实验设计与验证方法.md)
|
||||
5. [04-预期成果与论文方向.md](./04-预期成果与论文方向.md)
|
||||
6. [05-合作方式与产业落点.md](./05-合作方式与产业落点.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`。备份仅用于回溯,不参与当前阅读和实验流程。
|
||||
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
# 预期成果与论文方向
|
||||
# 预期成果与论文方向
|
||||
|
||||
## 1. 预期成果
|
||||
|
||||
@@ -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>
|
||||
@@ -0,0 +1,25 @@
|
||||
# 子课题A:面向MCU的静态智能控制基础系统
|
||||
|
||||
本目录用于承接框架2中的第一个子课题,重点面向 `T5` 控制端与极小资源预算场景。
|
||||
|
||||
## 子课题定位
|
||||
|
||||
本子课题重点研究:
|
||||
|
||||
> **在极小内存、极低功耗和强实时约束条件下,人工智能能力如何以静态、可分析、可部署的方式进入控制系统。**
|
||||
|
||||
## 建议阅读顺序
|
||||
|
||||
1. [00-子课题定义.md](./00-子课题定义.md)
|
||||
2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.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)
|
||||
|
||||
## 当前特点
|
||||
|
||||
本子课题的关键词是:
|
||||
|
||||
`静态编排`、`工具链`、`代码生成`、`芯片协同`、`低功耗`、`极小资源预算`
|
||||
Reference in New Issue
Block a user