662 lines
24 KiB
Markdown
662 lines
24 KiB
Markdown
# 面向 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>
|