From 1a138e2f0bb9484d1522aec9777b60b4d8f6c86e Mon Sep 17 00:00:00 2001
From: Mo1s <1194302708@qq.com>
Date: Tue, 29 Sep 2026 11:53:45 +0800
Subject: [PATCH] docs: add edge SoC performance review

---
 ...异构SoC的混合实时控制基础系统研究综述.md}  |   0
 ...03-主流异构边侧设备与AI模型性能指标综述.md | 278 ++++++++++++++++++
 .../00-总览与定位/README.md                   |   6 +-
 .../01-工程应用场景与性能指标对标.md          | 135 +++++++++
 .../20-实验与验证/README.md                   |   4 +-
 .../README.md                                 |   4 +-
 6 files changed, 423 insertions(+), 4 deletions(-)
 rename 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/{02-国内外研究综述.md => 02-面向边侧异构SoC的混合实时控制基础系统研究综述.md} (100%)
 create mode 100644 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/03-主流异构边侧设备与AI模型性能指标综述.md
 create mode 100644 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/01-工程应用场景与性能指标对标.md

diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/02-国内外研究综述.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/02-面向边侧异构SoC的混合实时控制基础系统研究综述.md
similarity index 100%
rename from 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/02-国内外研究综述.md
rename to 02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/02-面向边侧异构SoC的混合实时控制基础系统研究综述.md
diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/03-主流异构边侧设备与AI模型性能指标综述.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/03-主流异构边侧设备与AI模型性能指标综述.md
new file mode 100644
index 0000000..81648b5
--- /dev/null
+++ b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/03-主流异构边侧设备与AI模型性能指标综述.md
@@ -0,0 +1,278 @@
+# 主流异构边侧设备与AI模型性能指标综述
+
+## 摘要
+
+边侧智能控制设备正从单一CPU或GPU计算平台，演进为同时集成应用核、实时核、GPU、NPU/DLA、DSP、ISP、FPGA可编程逻辑和多类I/O加速单元的异构系统。对这类平台进行选型时，仅比较TOPS会遮蔽模型精度、权重体积、算子落点、内存带宽、运行时回退、队列等待、功耗模式和尾时延等关键差异。本文结合前期《面向边侧异构SoC的混合实时控制基础系统研究综述》和《工程应用场景与性能指标对标》，对NVIDIA Jetson Orin、Rockchip RK3588、TI TDA4VM、NXP i.MX 8M Plus、Qualcomm QRB5165/RB5、Hailo-8和AMD Kria K26等代表性设备的计算组成、标称算力、存储资源、功耗与推理软件栈进行对比；同时以MobileNetV3、YOLOv8、Octo、OpenVLA及边缘VLA工作负载为例，分析参数量、权重精度、训练/任务精度、量化损失、推理时间和端到端控制频率之间的关系。本文进一步给出面向子课题B的统一报告模板和分层实验矩阵，使“峰值算力—模型质量—平均性能—尾时延—控制安全”能在同一证据链中进行审查。
+
+**关键词：** 异构SoC；边缘AI；模型权重；混合精度；量化；推理时延；尾延迟；具身智能；混合实时系统
+
+---
+
+## 1 研究对象及与前两篇综述的关系
+
+前期国内外研究综述主要回答“Linux、RTOS、Hypervisor和AI加速器如何共存”，并将研究重点放在资源隔离、共享资源干扰、跨域通信和安全降级上。工程应用场景文档主要回答“这些问题在人形/四足机器人、移动操作、巡检和EtherCAT控制中如何落地”。
+
+本文作为第三篇独立综述，聚焦于二者之间尚缺的“设备—模型—运行时—实时指标”对应关系：
+
+1. 设备端具有哪些异构计算单元，其标称算力和存储资源是多少；
+2. 模型的参数量、权重位宽、活化值和中间缓冲如何占用内存；
+3. “训练精度”、“数值精度”和“任务准确率”应如何区分；
+4. 推理时间究竟是纯硬件执行、运行时API返回，还是传感器到执行器的端到端时间；
+5. 平均FPS很高的平台，在AI、DMA、网络和存储并发时是否仍能维持控制周期的P99.9和观测最大值。
+
+因此，本文中的数据不用于简单给出设备排名，而用于建立实验选型和结果解释的基准。
+
+## 2 性能指标的统一语义
+
+### 2.1 峰值算力不等于模型性能
+
+TOPS通常表示每秒可执行的万亿次基本操作，但其数值受计数方式、数据精度和稀疏性假设影响。例如Jetson Orin官方表格中的整体AI性能明确标为稀疏INT8 TOPS，而同页又另列GPU Tensor Core的稠密INT8性能[1]。因此，不能直接把某厂商的稀疏INT8 TOPS与另一厂商的稠密INT8、FP16 TFLOPS或可配置DPU单元数进行比例换算。
+
+对任一实际模型，性能还取决于：
+
+- 算子是否全部被加速器支持，是否回退到CPU/GPU；
+- 张量排布转换、量化/反量化和外部算子的开销；
+- 权重、活化值和特征图是否受内存带宽限制；
+- 动态形状、batch大小、多流和多模型并发方式；
+- 功耗档位、频率锁定、温度以及热降频状态；
+- 运行时、编译器、驱动、固件和模型编译产物版本。
+
+### 2.2 模型权重与内存占用
+
+若模型参数量为\(N_p\)，每个权重位宽为\(b\)，则仅权重的理论容量为：
+
+\[
+S_{weight}=N_p\times b/8
+\]
+
+例如7B参数模型的理论权重容量约为：FP32 28 GB、FP16/BF16 14 GB、INT8 7 GB、INT4 3.5 GB。这些数字不包括视觉编码临时张量、KV cache、活化值、量化尺度/零点、运行时工作区、图优化副本及I/O缓冲。因此，“权重能放入内存”不等于“模型能稳定运行”。
+
+本课题建议分开报告五个内存量：原始模型文件、编译后引擎/私有格式、常驻权重、峰值活化与工作区、进程峰值常驻内存（RSS）或设备内存峰值。
+
+### 2.3 “精度”需要区分三种含义
+
+| 精度类型 | 常见取值 | 它回答的问题 | 必须同时记录的信息 |
+|---|---|---|---|
+| 训练数值精度 | FP32、FP16、BF16、混合精度 | 梯度、权重更新和前/反向计算用什么数值格式 | 优化器、loss scaling、训练硬件、时长、数据集版本 |
+| 部署/推理精度 | FP32、FP16/BF16、INT8、INT4、W4A16等 | 权重和活化值如何存储与计算 | PTQ或QAT、校准集、逐张量/逐通道、对称/非对称 |
+| 任务质量 | Top-1/Top-5、mAP、mIoU、WER、任务成功率 | 模型完成实际任务的质量 | 数据集、划分、输入尺寸、评估脚本、随机种子、置信区间 |
+
+用户所说的“训练精度”在工程文档中经常同时指数值精度和准确率。本文统一将二者分写为“训练/部署位宽”和“任务质量”，避免把“INT8”误读为“80%准确率”。
+
+### 2.4 推理时间的五层口径
+
+| 层级 | 延迟定义 | 包含内容 | 主要用途 |
+|---|---|---|---|
+| L0 | 算子/核函数时间 | 单个算子或融合核执行 | 算子库与瓶颈分析 |
+| L1 | 设备执行时间 | 加速器从接受到完成图执行 | 比较编译产物和计算核 |
+| L2 | 运行时推理时间 | API调用、提交、排队、同步和图执行 | 单模型部署基准 |
+| L3 | 应用流水线时间 | 预处理+推理+后处理+主机/设备搬运 | 视觉或多模态应用评价 |
+| L4 | 端到端控制时间 | 采集、队列、预处理、推理、IPC、校验、控制与执行提交 | 本课题的最终验收口径 |
+
+FPS或samples/s表示吞吐率，\(1/FPS\)只能在batch=1、没有流水重叠且测量口径一致时近似单请求时间。对实时控制，应同时报告P50、P95、P99、P99.9、观测最大值、截止期违约率和连续违约长度，不应只报平均值。
+
+## 3 代表性异构边侧设备指标
+
+### 3.1 设备横向对比
+
+表1使用2026年9月前公开的厂商一手资料。“未给出”表示引用的官方页面没有给出可直接比较的数值，而不表示设备没有功耗或存储限制。
+
+| 平台/芯片 | 异构计算组成 | 官方标称AI性能 | 内存/带宽 | 官方功耗口径 | 典型软件路径 | 对本课题的主要价值 |
+|---|---|---:|---|---|---|---|
+| Jetson Orin Nano 8GB | 6核Cortex-A78AE + 512核Ampere GPU/16 Tensor Cores | 最高67稀疏INT8 TOPS | 8 GB LPDDR5，约102 GB/s | 7–25 W | Linux/JetPack + CUDA/TensorRT/ONNX Runtime/Isaac ROS | 低成本具身智能与视觉基线；没有独立DLA[1] |
+| Jetson Orin NX 16GB | 8核Cortex-A78AE + 1024核Ampere GPU/32 Tensor Cores + 2个NVDLA | 最高157稀疏INT8 TOPS | 16 GB LPDDR5，102.4 GB/s | 10–40 W | Linux/JetPack + CUDA/TensorRT/NVDLA | 适合VLA、多视觉流和异构调度；也是当前机器人开发中常见的档位[1] |
+| Jetson AGX Orin 64GB | 12核Cortex-A78AE + 2048核Ampere GPU/64 Tensor Cores + 2个NVDLA + PVA | 最高275稀疏INT8 TOPS | 64 GB LPDDR5，204.8 GB/s | 15–60 W | Linux/JetPack + CUDA/TensorRT/NVDLA | 多模型、多传感器和大模型本地推理基线[1][2] |
+| Rockchip RK3588 | 4×Cortex-A76 + 4×Cortex-A55 + Mali-G610 MP4 + 三核NPU + 低功耗MCU | 6 INT8 TOPS；数据手册还列出INT4/INT16/FP16/BF16/TF32支持 | 64-bit LPDDR4/4X/5；额定容量与带宽取决于板级实现 | 未给出统一模块档位 | Linux/Android + RKNN Toolkit2/RKNN Runtime | 低成本NPU和多核CPU/GPU/NPU共存对照；官方模型库提供多模型FPS[3][4] |
+| TI TDA4VM | 2×Cortex-A72 + 6×Cortex-R5F + C7x DSP/MMA + 2×C66x DSP + GPU + ISP/VPAC/DMPAC | MMA最高8 INT8 TOPS | 随具体型号和板级设计确定 | 官方产品页未给出统一整机值 | Linux/QNX/FreeRTOS等 + TIDL | 应用核、多实时核、DSP与AI加速器高度集成，非常适合研究“Linux+RTOS+硬件隔离”[5] |
+| NXP i.MX 8M Plus | 2/4×Cortex-A53 + Cortex-M7 + NPU + HiFi 4 DSP + GPU + 双ISP | 最高2.3 TOPS | LPDDR4/DDR4，支持内联ECC；容量取决于型号和板级实现 | 未给出统一整机值 | Linux + FreeRTOS + eIQ/TFLite/ONNX生态 | 算力不高但实时核、TSN/CAN FD和工业接口完整，适合中小模型+实时控制[6][7] |
+| Qualcomm QRB5165/RB5 | 4高性能+4低功耗Kryo 585 + Adreno 650 + Hexagon 698/HTA/HVX + EVA/ISP | AI Engine最高15 TOPS | 开发套件配置与商用SoM不同，需按BOM冻结 | 官方页未给出统一整机值 | Linux/Ubuntu/ROS 2 + QAIRT/QNN/HTP | 强ISP、DSP、NPU和连接性，适合机器人、无人机和多相机异构流水线[8] |
+| Hailo-8（加速器） | 数据流AI处理器，需外部主机 | 26 TOPS | 芯片设计不需外部存储器；系统总内存仍由主机和流水线决定 | 官方典型值2.5 W | Host Linux + Hailo Dataflow Compiler + HailoRT/HEF | 适合研究外挂NPU、PCIe搬运、设备队列与主机控制任务之间的干扰[9] |
+| AMD Kria K26 | 4×Cortex-A53 + 2×Cortex-R5F + Mali-400 + 25.6万逻辑单元/1248 DSP的可编程逻辑 | 取决于DPU或自定义数据通路配置，不宜以固定TOPS与NPU比较 | 4 GB 64-bit DDR4，2400 Mb/s；26.6 Mb片上存储 | 取决于PL设计与载板 | Linux/FreeRTOS + Vitis AI/自定义PL加速 | 可把关键预处理、时间触发或自定义推理流水线硬件化，适合确定性对照[10][11] |
+
+上表表明，主流设备并不是同一类产品。Jetson强调GPU生态、统一内存与大模型兼容性；RK3588强调成本与多媒体NPU；TDA4VM、i.MX 8M Plus和Kria更容易形成应用域与实时域的硬件分工；QRB5165具有移动SoC的能效、感知和连接优势；Hailo-8则是主机外挂专用加速器。子课题B的“混合实时”研究应关注这些架构差异如何影响隔离和尾时延，而不是只寻找TOPS最大的设备。
+
+### 3.2 主要推理架构和编译链
+
+| 类型 | 典型数据路径 | 优势 | 与实时性相关的风险 |
+|---|---|---|---|
+| GPU/Tensor Core | PyTorch/ONNX → TensorRT engine → CUDA stream → GPU | 算子覆盖广，支持FP32/FP16/BF16/FP8/INT8/INT4/FP4等混合精度，易部署Transformer[12] | 核函数不可抢占区间、多流排队、显存/统一内存竞争和热降频 |
+| 固定功能NPU/DLA | ONNX/TFLite → 厂商编译器 → 私有图/二进制 → NPU Runtime | INT8能效高，适合固定视觉网络 | 算子不支持时可切图或回退CPU；固件队列和抢占能力不透明 |
+| DSP/HTP/MMA | 模型编译 → DSP/向量核+矩阵加速器 | 视觉、信号处理和AI可在相同子系统内融合 | 多核共享内存、任务图与数据搬运配置复杂 |
+| 数据流NPU | 模型 → 结构映射/编译 → HEF等产物 → 流式执行 | 视觉模型吞吐和能效高 | 主机预/后处理、PCIe或M.2传输和多流调度仍会影响端到端时间 |
+| FPGA/可编程逻辑 | 模型或自定义算子 → HLS/RTL/DPU → PL流水线 | 可定制I/O、并行度和固定数据路径，便于硬件时间触发 | 编译时间长，可用算子和量化方案受配置限制，更改模型需重新生成硬件产物 |
+
+这些运行时并不直接对应操作系统的实时优先级。即使提交线程在Linux中设置了高优先级，设备内部已排队任务、固件命令批次和内存控制器仍可能不可抢占。因此需要以时间戳区分“主机提交—设备开始—设备完成—结果可用”四个时刻。
+
+## 4 代表性模型的权重、质量与计算规模
+
+### 4.1 从轻量视觉到具身大模型
+
+表2中的权重容量按参数量与位宽计算，是方便选型的理论值，不代表文件大小或运行时峰值内存。
+
+| 模型 | 任务/架构 | 参数与计算 | 理论权重容量 | 公开任务质量/训练信息 | 对边侧部署的含义 |
+|---|---|---|---|---|---|
+| MobileNetV3-Large 1.0 | ImageNet分类，移动CNN | 5.4M参数，219M MAdds | FP32 21.6 MB；FP16 10.8 MB；INT8 5.4 MB | ImageNet Top-1 75.2%[13] | 适合作为算子覆盖和量化基线，但不能代表检测、分割或VLA |
+| YOLOv8n | COCO目标检测，单阶段CNN | 3.2M参数，约8.74 GOP（Hailo口径） | FP32 12.8 MB；FP16 6.4 MB；INT8 3.2 MB | Hailo模型库报告float mAP 37.0、设备mAP 36.4[14] | 适合低延迟感知和量化损失对照 |
+| YOLOv8s | COCO目标检测 | 11.2M参数，约28.6 GOP | FP32 44.8 MB；FP16 22.4 MB；INT8 11.2 MB | float mAP 44.6、Hailo设备mAP 43.9[14] | 与YOLOv8n组成同系列精度—延迟折中实验 |
+| Octo-Small/Base | 通用机器人策略，Transformer+动作头 | 27M/93M参数 | FP16约54/186 MB；INT8约27/93 MB | 使用约80万条机器人轨迹；官方仓库报告RTX 4090上约17/13 it/s[15] | 模型可放入边侧内存，但4090结果不能代替边侧实测；任务质量应以机器人成功率报告 |
+| OpenVLA-7B | 视觉—语言—动作，双视觉编码器+投影层+Llama 2 7B | 约7B参数 | FP16约14 GB；INT8约7 GB；INT4约3.5 GB | 97万条真实机器人演示；64块A100训练15天；论文报告其在29项任务上较RT-2-X绝对成功率高16.5个百分点[16][17] | 量化后权重可能放入8–16 GB设备，但活化值、视觉编码和上下文仍可造成显著内存及延迟压力 |
+| LiteVLA-Edge实验管线 | 边缘多模态控制，ROS 2 + llama.cpp | 论文采用FP32监督微调后4-bit GGUF量化 | 依具体基座模型而定 | Jetson Orin类平台上报告平均端到端时延150.5 ms，约6.6 Hz[18] | 说明“可运行”与“可高频闭环”差距巨大；需用异步动作块、过期拒绝和RTOS底层控制弥补 |
+
+上述数据还显示，“准确率”不能在不同任务之间直接比较。75.2% ImageNet Top-1、44.6 COCO mAP和机器人任务成功率属于不同评价对象。对具身智能，最终应报告分任务成功率、碰撞/越界次数、完成时间和对延迟扰动的敏感性，不能只使用离线感知指标。
+
+### 4.2 公开设备推理数据示例
+
+下表故意保留了各官方模型库的测试口径，不将它们包装成严格跨平台排名。倒数时间仅为\(1000/FPS\)的理想化换算，不是P99或端到端延迟。
+
+| 设备/来源 | 模型与输入 | 精度 | 公开吞吐 | 理想化倒数时间 | 测试条件与解读 |
+|---|---|---|---:|---:|---|
+| RK3588官方RKNN Model Zoo | MobileNetV2，1×3×224×224 | INT8 | 450.7 FPS | 2.22 ms | 官方表格标注RK3588 NPU单核，适合作图执行吞吐基线[4] |
+| RK3588官方RKNN Model Zoo | ResNet50-v2，1×3×224×224 | INT8 | 110.1 FPS | 9.08 ms | 同上[4] |
+| RK3588官方RKNN Model Zoo | YOLOv8n/s/m，1×3×640×640 | INT8 | 73.5/38.0/16.2 FPS | 13.61/26.32/61.73 ms | 同系列随模型规模增大出现清晰延迟梯度[4] |
+| Hailo-8官方Model Zoo | YOLOv8n/s/m/l，640×640 | 编译后硬件部署 | 1036/491/66.9/36.2 FPS | 0.97/2.04/14.95/27.62 ms | 官方表格的主机为i5-9400、PCIe Gen3×4、室温、batch=1；表内还分别报告float和硬件mAP[14] |
+| Hailo-8官方CLI示例 | ResNet-50 | 编译后HEF | 1328.83 FPS | 不按倒数解读 | 同一输出报告硬件延迟2.936 ms和流式平均功耗3.194 W，说明流水吞吐与单请求延迟并非简单互为倒数[19] |
+| Jetson Orin类设备/LiteVLA-Edge | 量化多模态控制管线 | 4-bit GGUF | 约6.6 Hz | 平均端到端150.5 ms | 包含ROS 2感知—推理—动作管线，与纯NPU图执行不是同一口径[18] |
+
+对真正的跨设备比较，应优先使用MLPerf Inference Edge这类固定模型、数据集、质量门槛、负载生成器和场景规则的基准。MLCommons将Closed组用于尽可能同模型横向比较，Open组则允许更换模型或重训练[20]。即使如此，MLPerf的Offline/Server/SingleStream等场景仍不能替代本课题的RTOS控制并发和故障注入实验。
+
+## 5 面向混合实时控制的指标体系
+
+### 5.1 不应缺失的设备信息
+
+每一组实验至少冻结：
+
+- SoC/模组/开发板型号、内存容量和载板版本；
+- OS、内核、RTOS、Hypervisor、BSP和固件版本；
+- AI编译器、运行时、驱动和模型编译产物的哈希；
+- 功耗模式、CPU/GPU/NPU/内存频率、锁频方式和散热条件；
+- CPU亲和性、中断亲和性、内存区域、IOMMU、设备所有权和加速器并发度；
+- 采集时长、样本数、预热时间、环境温度与稳态温度。
+
+### 5.2 不应缺失的模型信息
+
+- 模型名称、代码/权重提交号、输入尺寸、batch、序列长度和动态形状范围；
+- 参数量、MACs/FLOPs/OPS口径和支持算子比例；
+- 原始权重位宽、部署权重/活化位宽和混合精度列表；
+- PTQ/QAT方式、校准数据集与样本数，是否采用稀疏性或剪枝；
+- FP32/原始模型质量、编译后仿真质量和目标板实测质量；
+- 编译失败、CPU回退、子图切分、张量转换和外部算子情况。
+
+### 5.3 四类性能结果
+
+| 类别 | 核心指标 | 解释要点 |
+|---|---|---|
+| 模型质量 | 原始质量、量化后质量、绝对/相对下降、分类别/分场景成功率 | 达不到冻结质量门槛时，性能再高也不进入实时比较 |
+| 推理时序 | 冷启动、预热后P50/P95/P99/P99.9/最大值，吞吐、队列深度和超时率 | 分别记录L1–L4口径，避免用纯硬件FPS代替端到端时间 |
+| 资源与能效 | CPU/GPU/NPU利用率、DDR带宽、LLC未命中、DMA、峰值内存、平均/峰值功耗、J/inference | 功耗必须注明是芯片、模组、加速卡还是整机口径 |
+| 控制影响 | 控制周期偏差、截止期违约、AI结果年龄、过期丢弃率、降级与恢复时间 | 这是子课题B区别于通用AI硬件评测的最终指标 |
+
+## 6 对子课题B的设备和模型选型建议
+
+### 6.1 建议形成四类对照平台
+
+1. **高AI生态主平台：Jetson Orin NX 16GB或AGX Orin。** 用于具身视觉、VLA、多模型并发和GPU/DLA异构分配，也便于与已有机器人应用资料衔接。
+2. **集成实时域平台：TDA4VM或i.MX 8M Plus。** 用于对比应用核与R5F/M7实时核的硬件分工、共享内存通信和故障隔离。
+3. **低成本NPU平台：RK3588。** 用于评价私有NPU编译、算子回退、单/多NPU核调度与Linux实时化的性价比。
+4. **外挂或可编程加速平台：Hailo-8或Kria K26。** 用于研究PCIe/DMA搬运、主机队列、自定义数据通路和固定流水线的确定性。
+
+若当前资源只允许购置一套平台，建议优先Orin NX 16GB，并外接一块运行RTOS的MCU或实时控制器建立可测的Linux AI域—RTOS控制域链路。若研究重心更偏向单芯片内的真正AMP和安全隔离，TDA4VM的A72+R5F+C7x/MMA结构更具代表性。
+
+### 6.2 建议的模型负载梯度
+
+| 梯度 | 建议模型 | 目的 |
+|---|---|---|
+| M0 算子微基准 | Conv2D、Depthwise Conv、GEMM、Attention、Resize、NMS | 建立算子时间、能耗和CPU回退数据库 |
+| M1 轻量分类 | MobileNetV3-Large或MobileNetV2 | 验证编译链、INT8量化和最小延迟 |
+| M2 实时检测 | YOLOv8n/s/m | 建立模型规模—质量—延迟—能耗曲线 |
+| M3 语义/姿态任务 | DeepLabV3+、YOLOv8-Pose或项目自有模型 | 接近机器人对环境和人的感知负载 |
+| M4 紧凑机器人策略 | Octo-Small/Base或等规模动作模型 | 评估视觉、语言/状态和动作生成管线 |
+| M5 量化VLA | OpenVLA类7B或更小VLA的INT4版本 | 验证大权重、长时延、异步动作块和结果新鲜度策略 |
+
+## 7 建议直接纳入课题的实验设计
+
+### 7.1 E0：版本与配置冻结
+
+生成设备BOM、软件版本、功耗/频率、核与中断分配、模型哈希、校准集哈希和编译参数清单。未完成E0的数据不进入横向对比。
+
+### 7.2 E1：模型质量与内存账本
+
+对每个模型依次测量FP32/FP16原始质量、PTQ INT8/INT4质量、必要时的QAT质量；统计模型文件、设备编译产物、常驻权重、峰值工作区和稳态/峰值RSS。质量下降超过任务门槛的精度方案不参加性能验收。
+
+### 7.3 E2：单模型隔离推理
+
+固定batch=1和输入，分别测试冷启动、预热后和热稳态。对L1、L2、L3时间分段打点，报告分位数、吞吐、功耗和能耗。对具有多NPU核、GPU+DLA或CPU+DSP+NPU的设备，对比单加速器、多加速器和多模型并发。
+
+### 7.4 E3：控制域与AI域并发
+
+设置0.5/1/2/10 ms等不同控制周期的仿真或实机任务，对比：
+
+1. 仅控制任务；
+2. 控制+单模型推理；
+3. 控制+多视频流/多模型；
+4. 控制+大模型/VLA长时推理；
+5. 同负载下的普通Linux、PREEMPT_RT、AMP或静态分区方案。
+
+主指标为控制周期P99.9/最大偏差、截止期违约、AI结果年龄和过期拒绝率。
+
+### 7.5 E4：共享资源压力
+
+逐项和联合注入CPU、LLC、DDR、DMA、摄像头/ISP、网络、NVMe、GPU/NPU和热负载，建立：
+
+\[
+资源干扰强度\rightarrow推理队列和尾时延\rightarrow控制周期偏差\rightarrow截止期/任务质量
+\]
+
+的因果记录。此实验应长时运行到热稳态，否则无法观测DVFS和热降频对长尾的影响。
+
+### 7.6 E5：超时、故障和恢复
+
+注入AI进程崩溃、设备超时、驱动队列停滞、消息丢失/乱序/重复、过期结果、Linux重启和温度降频。测量故障检测时间、RTOS降级切换时间、安全状态保持率、通道清理和受控重新接入时间。
+
+## 8 综合讨论
+
+### 8.1 关于“边端训练”
+
+大多数异构边侧设备的主要任务是推理，并非从零训练大模型。OpenVLA的公开信息显示其预训练使用了64块A100、15天[17]，这与边侧SoC的功耗、内存和散热边界不在同一级别。边端更可行的路径是离线集中训练，边端进行小样本校准、LoRA/适配层微调、增量学习或模型选择。这些在线学习活动不应与高关键控制无界共享资源。
+
+### 8.2 关于具身智能的多频率系统
+
+具身智能中的VLA可能只能以6–20 Hz生成动作或动作块，而关节、平衡、力控和安全监测可能需要500 Hz–2 kHz甚至更高的周期。这不意味着VLA必须和伺服环同频，而意味着系统必须有明确的多频率协议：VLA只发布带时间戳、有效期、版本和置信度的有界目标/动作块；RTOS以高频率完成插值、限幅、状态估计、执行器控制和故障降级。
+
+### 8.3 最有价值的研究指标
+
+对本课题而言，最有价值的不是“将YOLO加速到多少FPS”，而是以下三类关系：
+
+1. 在相同模型质量门槛下，不同设备/精度/运行时的L3和L4尾时延如何；
+2. 在相同AI负载下，普通Linux、PREEMPT_RT、AMP和静态分区对控制周期P99.9和最大值的改善程度；
+3. 当AI超时、过载或崩溃时，RTOS能否在已知时间内拒绝旧结果、进入降级并维持安全状态。
+
+## 9 结论
+
+当前主流异构边侧设备已形成GPU主导、集成NPU/DSP、应用核+实时核、外挂数据流加速器和FPGA可编程逻辑等多条技术路线。其公开算力横跨约2.3 TOPS到275稀疏INT8 TOPS，但TOPS口径、数值精度、稀疏性、算子覆盖、内存系统和运行时都不同，因而不能根据峰值数字直接预测模型FPS或端到端控制时闶。
+
+在模型层面，MobileNet/YOLO类模型的权重仅为数MB至数十MB，而7B VLA即使INT4权重也约3.5 GB，其中间状态和端到端流水线还会显著增加内存与时间成本。量化的意义不只是减小文件，还要同时验证任务质量、算子映射、实际内存峰值和长尾时延。
+
+因此，子课题B应将设备峰值参数作为入口，将模型质量作为准入门槛，将L1–L4时间分解和资源计量作为过程证据，最终以控制周期、AI结果新鲜度、过期拒绝、故障降级和恢复时间作为系统级结论。这样才能把“模型跑得动”提升为“智能与实时控制可在已知边界内共存”。
+
+## 参考资料
+
+1. NVIDIA. *Jetson AGX Orin for Next-Gen Robotics: Technical Specifications*. [官方产品与规格页](https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-orin/)，访问日期：2026-09-29。
+2. NVIDIA. *Jetson AGX Orin Series Hardware Architecture*. [官方技术简报](https://www.nvidia.com/content/dam/en-zz/Solutions/gtcf21/jetson-orin/nvidia-jetson-agx-orin-technical-brief.pdf)。
+3. Rockchip. *RK3588 Brief Datasheet*. [官方数据手册](https://www.rock-chips.com/uploads/pdf/2022.8.26/191/RK3588%20Brief%20Datasheet.pdf)。
+4. Rockchip AI Team. *RKNN Model Zoo*. [官方代码仓库及性能表](https://github.com/airockchip/rknn_model_zoo/blob/main/README_CN.md)，访问日期：2026-09-29。
+5. Texas Instruments. *TDA4VM SoC with Dual Arm Cortex-A72, 8 TOPS of AI, C7x DSP, and GPU*. [官方产品页](https://www.ti.com/product/TDA4VM)。
+6. NXP. *i.MX 8M Plus: Cortex-A53/M7, Machine Learning, Vision, Multimedia and Industrial IoT*. [官方产品页](https://www.nxp.com/products/i.MX8MPLUS)。
+7. NXP. *i.MX 8M Plus Applications Processor Family*. [官方产品手册](https://www.nxp.com/docs/en/brochure/IMX8SERAPPBR.pdf)。
+8. Qualcomm. *Dragonwing QRB5165*. [官方产品页](https://www.qualcomm.com/internet-of-things/products/q5-series/qrb5165)。
+9. Hailo. *Hailo-8 AI Processor Product Brief*. [官方产品简报](https://hailo.ai/wp-content/uploads/2023/10/hailo-8-product-brief-rev3.26.pdf)。
+10. AMD. *Kria K26 SOM Data Sheet (DS987)*. [官方数据手册](https://docs.amd.com/r/en-US/ds987-k26-som)。
+11. AMD. *Kria K26 SOM: The Ideal Platform for Vision AI at the Edge*. [官方白皮书](https://docs.amd.com/v/u/en-US/wp529-som-benchmarks)。
+12. NVIDIA. *TensorRT Documentation*. [官方文档](https://docs.nvidia.com/deeplearning/tensorrt/latest/)。
+13. HOWARD A, SANDLER M, CHU G, et al. Searching for MobileNetV3[EB/OL]. arXiv:1905.02244, 2019. [论文](https://arxiv.org/abs/1905.02244)。
+14. Hailo AI. *Hailo Model Zoo: Hailo-8 Object Detection Models*. [官方模型指标与基准表](https://github.com/hailo-ai/hailo_model_zoo/blob/master/docs/public_models/HAILO8/HAILO8_object_detection.rst)。
+15. OCTO MODEL TEAM, GHOSH D, WALKE H, et al. Octo: An Open-Source Generalist Robot Policy[C]//Robotics: Science and Systems. 2024. [官方仓库与模型数据](https://github.com/octo-models/octo)。
+16. KIM M J, PERTSCH K, KARAMCHETI S, et al. OpenVLA: An Open-Source Vision-Language-Action Model[EB/OL]. arXiv:2406.09246, 2024. [论文](https://arxiv.org/abs/2406.09246)。
+17. OpenVLA Team. *OpenVLA Project Page*. [官方项目页](https://openvla.github.io/)。
+18. WILLIAMS J, GUPTA K D, GEORGE R, et al. LiteVLA-Edge: Quantized On-Device Multimodal Control for Embedded Robotics[EB/OL]. arXiv:2603.03380, 2026. [论文](https://arxiv.org/abs/2603.03380)。
+19. Hailo AI. *Hailo Model Zoo Benchmarks*. [官方基准复现说明](https://github.com/hailo-ai/hailo_model_zoo/blob/master/docs/BENCHMARKS.rst)。
+20. MLCommons. *MLPerf Inference: Edge*. [官方基准、场景与结果](https://mlcommons.org/benchmarks/inference-edge/)，访问日期：2026-09-29。
diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/README.md
index f7e00e7..3c1eb42 100644
--- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/README.md
+++ b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/00-总览与定位/README.md
@@ -6,7 +6,8 @@
 
 1. [00-子课题定义.md](./00-子课题定义.md)：研究对象、核心目标和方向边界；
 2. [01-研究问题与适用场景.md](./01-研究问题与适用场景.md)：关键问题、应用场景和系统约束；
-3. [02-国内外研究综述.md](./02-国内外研究综述.md)：系统形态、共享资源干扰、跨域通信、安全降级、研究空白与本课题研究框架。
+3. [02-面向边侧异构SoC的混合实时控制基础系统研究综述.md](./02-面向边侧异构SoC的混合实时控制基础系统研究综述.md)：系统形态、共享资源干扰、跨域通信、安全降级、研究空白与本课题研究框架；
+4. [03-主流异构边侧设备与AI模型性能指标综述.md](./03-主流异构边侧设备与AI模型性能指标综述.md)：主流异构设备、模型权重与精度、公开推理数据、运行时架构和统一实验指标。
 
 ## 阅读结果
 
@@ -15,6 +16,7 @@
 - 子课题B与子课题A在资源规模和部署形态上的区别；
 - Linux、RTOS、Hypervisor和Hybrid结构分别解决什么问题；
 - 哪些实时控制职责必须留在确定性执行域中；
-- 国内外相关研究已经解决了什么、尚缺少什么，以及本课题的可验证创新点。
+- 国内外相关研究已经解决了什么、尚缺少什么，以及本课题的可验证创新点；
+- 不同设备的TOPS、模型权重、精度、FPS和端到端延迟应如何正确比较。
 
 [返回总目录](../README.md)
diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/01-工程应用场景与性能指标对标.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/01-工程应用场景与性能指标对标.md
new file mode 100644
index 0000000..6b49736
--- /dev/null
+++ b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/01-工程应用场景与性能指标对标.md
@@ -0,0 +1,135 @@
+# 工程应用场景与异构系统性能指标对标
+
+## 1 调研目的与结论
+
+本文件把子课题B“Linux、RTOS、Hypervisor与异构加速器协同”的研究主线映射到可验证的工程场景，并整理截至2026年9月公开可查的延迟、抖动和控制周期数据。
+
+先说明数据边界：目前项目材料尚未冻结目标SoC、载板、Linux/RTOS版本、Hypervisor、AI加速器运行时和具体机器人型号。因此，下文数据是公开论文、厂商工程测试和产品资料中的**对标值**，不是本课题目标板的实测值，也不能直接互相比较。尤其宇树官网公开了部分算力、传感器和开发接口信息，但未公开其机器人内部控制链的端到端延迟分布、P99/P99.9抖动或截止期违约率。
+
+本次调研的工程判断是：
+
+1. 具身机器人适合作为课题牵引场景，宇树G1-D/G1-Comp、H1/H1-2以及四足巡检机器人具备“实时运动控制+视觉/语言模型+边侧算力”的真实需求；
+2. 公开VLA数据能说明高级策略推理可能需要百毫秒至秒级，不能把它放入毫秒级伺服闭环；
+3. 控制域的目标应单独定义周期、抖动和违约率，并由RTOS或专用控制器维持安全闭环；Linux/AI域通过有界通道提供更新较慢的感知和动作建议；
+4. 对课题最有价值的实验不是只报AI FPS，而是在CPU、DDR、DMA、NPU/GPU和温度压力下测量“传感输入至控制输出”的长尾时延、抖动和故障切换时间。
+
+## 2 已公开的量化性能参照
+
+### 2.1 边侧SoC实时内核与现场总线
+
+Seeed公布了在Orin Nano Super上对标准Linux和PREEMPT_RT进行的同机对照测试。设备运行JetPack 7.2，六核CPU；测试同时包含满CPU负载、内核临界区干扰、GPIO周期输出和1 kHz EtherCAT主站。该资料由硬件厂商发布，实验步骤和部分代码公开，属于可复核的工程数据，但不是独立同行评审论文。
+
+| 测量对象与条件 | 标准内核 | PREEMPT_RT | 解释 |
+|---|---:|---:|---|
+| 用户态满CPU负载下，周期线程唤醒延迟 P99 / 最大值 | 1,879 / 8,200 μs | 11 / 32 μs | 说明高优先级线程虽能压过普通用户任务，内核调度仍会产生毫秒级长尾 |
+| EtherCAT主站，1 kHz，内核自旋锁每3秒持有1秒，5,000周期中超1 ms周期数 | 约2,000 | 0 | 这是有意构造的严重内核临界区干扰，展示了非抢占内核区可能造成总线失联 |
+| 同一EtherCAT测试，主站唤醒延迟 P50 / P99 / 最大值 | 7 / 约994,000 / 约1,018,000 μs | 2 / 3 / 12 μs | PREEMPT_RT数据来自相同测试条件；不可视为所有Orin设备的通用保证 |
+| 2 kHz GPIO输出，300 μs锁竞争下 P99 / 最大值 | 306 / 325–547 μs | 251 / 257 μs，标准差0.56 μs | 周期输出比单纯cyclictest更接近电气边沿抖动测量 |
+
+同一资料还显示，标准内核与PREEMPT_RT在纯用户态负载下都能维持电机运行，但延迟分布差别仍明显；当内核不可抢占临界区加入后，标准内核会触发安全停机，PREEMPT_RT在该测试中没有丢周期。[Seeed Orin Nano Super PREEMPT_RT与EtherCAT对照测试](https://wiki.seeedstudio.com/deploy_preempt_rt_kernel_with_prebuilt_deb_package_on_recomputer_jetson/)
+
+NVIDIA的Jetson Thor实时内核测试也给出一个资源隔离参照：在性能模式、DDR/GPU高频、显示/USB/网络和编译负载并行的配置下，隔离核上的`rtla timerlat`线程最大延迟为26 μs；承担系统负载的核最大值最高96 μs。该测试针对Thor，不应外推为Orin或宇树开发计算单元的性能保证。[NVIDIA Jetson实时内核测量说明](https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/SD/Kernel/RealTimeKernel.html)
+
+### 2.2 ROS 2与机器人控制周期
+
+清华大学双臂机器人相关研究在PC控制平台上测试ROS 2、PREEMPT_RT和EtherCAT。其结果可用来设计指标口径，但硬件不是Jetson异构SoC：
+
+- 满CPU压力下，PREEMPT_RT周期线程测试持续25.7小时，最大唤醒延迟82 μs、平均2 μs；周期抖动在25–5,000 Hz测试范围内小于60 μs；
+- 1 kHz EtherCAT主站、16个从站的周期实测最小982.5 μs、平均999.8 μs、最大1,022.4 μs；
+- 1 KB ROS 2消息在不同发布频率下测得的最大传输延迟低于150 μs；消息大小、DDS/QoS和节点数变化会影响结果。
+
+该研究明确指出其测试优化的是系统实时性能，并未证明机器人运动控制品质；因此上述值适合作为“如何报告周期与延迟”的参照，不宜直接作为课题目标板的验收结论。[Ye等，ROS2 Real-time Performance Optimization and Evaluation](https://doi.org/10.1186/s10033-023-00976-5)
+
+### 2.3 Jetson上具身VLA推理与反应时间
+
+2026年的Jetson-PI研究在Jetson Orin上测试π0.5视觉语言动作模型。其表格给出以下分阶段优化结果：
+
+| Orin推理流程 | 端到端模型推理时间 | 动作反应时间 | 报告的控制频率 |
+|---|---:|---:|---:|
+| 朴素同步推理 | 1,420.8 ms | 1,420.8 ms | 0.70 Hz |
+| 加入VLM调用调度 | 1,420.8 ms | 674.9 ms | 1.48 Hz |
+| 加入CUDA Graph复用 | 476.1 ms | 227.0 ms | 4.41 Hz |
+| 加入中间缓冲与迭代展开 | 412.9 ms | 165.1 ms | 6.06 Hz |
+
+这里的“控制频率”是VLA高级策略生成/反应能力，不是关节伺服频率，也没有报告目标SoC混合负载下的P99抖动。研究另在PrimeBot X2-W平台上用三路224×224相机执行叠衣任务，报告机器人动作频率15 Hz；该实机结果使用XR-1模型，不应与上表π0.5的6.06 Hz混为一谈。该结果适合支持“VLA异步运行、低层控制独立闭环”的设计，而非证明VLA可以直接承担实时伺服。[Jetson-PI论文，arXiv版本于2026-09-05更新](https://arxiv.org/abs/2607.12659)
+
+### 2.4 Orin Nano移动机器人感知—规划链路
+
+2026年发表的一项ROS 2小型自动驾驶/移动机器人研究采用NVIDIA Jetson Orin Nano 8 GB作为高层计算单元、STM32 Nucleo-F401RE作为低层控制器，两者通过UART交换命令和反馈。其定位与感知规划链具有可对照的端到端时间分布：
+
+| 感知—规划任务 | 均值 | P95 | 实测最大值 |
+|---|---:|---:|---:|
+| 车道检测链 | 43.221 ms | 49.538 ms | 62.061 ms |
+| 目标检测链 | 49.998 ms | 61.986 ms | 72.616 ms |
+| 障碍检测链 | 11.554 ms | 19.524 ms | 25.909 ms |
+
+论文报告车道参考更新平均频率22.4 Hz。采集时计算、内存和I/O资源专门分配给该架构，没有叠加无关AI/DMA压力；论文将从测量数据汇总的最大值称为WCET，但从严格时序分析角度看，有限运行中的最大实测值不等同于已证明的理论WCET。[Bonci等，ROS 2-Based Architecture for Autonomous Driving Systems](https://doi.org/10.3390/s26020463)
+
+### 2.5 宇树平台的公开参数与指标缺口
+
+宇树官网资料显示，H1/H1-2标配计算单元包含平台功能计算机和用户开发计算机，选配可使用Intel Core i7或Orin NX；H1-2页面列出最多三块Orin NX。G1-D公开了8核高性能CPU、头部双目相机和腕部相机，并可选Orin NX 16 GB（100 TOPS）；G1-Comp页面列出Orin NX、ROS生态兼容、仿真和运动控制API。官方SDK2的G1低层控制示例把`control_dt`设为2 ms，即示例任务按500 Hz生成命令。
+
+这些信息证明具身机器人产品具有异构计算、感知和实时运动控制接口，但500 Hz只是SDK示例中的用户命令周期，不代表机器人内部伺服周期、实际网络收发周期或抖动上限。公开产品页和示例没有给出完整的传感器到执行器路径P99/P99.9、并发推理下的控制超期率或Hypervisor隔离数据。因此，宇树可作为应用平台和工作负载来源，具体性能必须在锁定机型、开发计算单元、SDK/固件和通信拓扑后实测。[宇树H1/H1-2规格](https://www.unitree.com/cn/h1/)；[宇树G1-D平台](https://www.unitree.com/G1-D/)；[宇树G1-Comp](https://www.unitree.com/cn/robocup/)；[Unitree SDK2 G1低层控制示例](https://github.com/unitreerobotics/unitree_sdk2_python/blob/master/example/g1/low_level/g1_low_level_example.py)
+
+## 3 适合子课题B的应用场景
+
+| 场景 | 可选平台与任务 | 异构计算分工 | 需要回答的实时问题 | 适合作为课题的原因 |
+|---|---|---|---|---|
+| 人形机器人移动操作 | 宇树G1-D/G1-Comp或H1-2；视觉找物、自然语言任务、抓取、递送、整理 | Linux/Orin运行视觉、VLA、任务规划；RTOS/安全控制域维护高频状态采集、关节/底盘控制接口、限位与看门狗；Hypervisor划分核、内存、设备和通信区 | 模型推理过慢或NPU排队时，控制域能否保持步态/姿态稳定；过期动作块是否被丢弃；抓取碰撞事件能否抢占慢速任务规划 | 直接体现“慢速智能决策+快速安全闭环”，与具身智能、异构SoC和AI故障兜底高度吻合；官方有Orin NX选配和多相机/开发接口 |
+| 四足机器人巡检与应急 | 宇树As2/Go2/B2等；电力巡检、园区巡逻、消防侦察、越障与回传 | Linux/SoC运行视觉、点云、SLAM、异常识别和任务规划；RTOS/运动控制域负责步态、IMU、关节状态和急停；网络/云端只传非安全关键任务 | 摄像头、雷达和NPU同时工作时，DDR/DMA竞争是否拉长姿态估计；无线链路断开、定位失效、AI异常时多快进入安全策略；热稳态后时延如何变化 | 宇树公开了[四足行业巡检方案及As2高算力扩展](https://www.unitree.com/As2/)；跌倒、振动、户外温度和断网可构造真实压力及故障注入 |
+| 视觉引导移动操作/仓储机器人 | Jetson Orin NX/Nano + ROS 2 + STM32/RTOS底盘或机械臂；目标搬运、避障、二维码/货架识别 | RTOS控制电机、编码器、安全输入和制动；Linux运行相机/激光雷达驱动、检测、定位和规划；IPC传递带时间戳的速度/轨迹目标 | 从相机曝光到电机命令的端到端P95/P99；队列积压和旧帧处理；Linux重启时RTOS能否维持受控停车 | 有Jetson Orin Nano + STM32的公开实机架构和端到端基线，原型成本较低，适合先打通测试工具链 |
+| EtherCAT协作臂/高精度运动控制 | Orin Nano/NX或其他边侧SoC + EtherCAT伺服；视觉定位、抓取、插装、轨迹跟踪 | RTOS或PREEMPT_RT域运行1 kHz现场总线周期任务；Linux/NPU做视觉和轨迹更新；低层以有界周期缓冲接收新目标 | CPU、DMA、相机和模型并发时1 ms周期最大偏差；主站唤醒延迟；超期和总线失联次数；故障恢复到安全位置的时间 | 有Orin Nano Super + 1 kHz EtherCAT公开对照测试，能直接形成标准内核、PREEMPT_RT和隔离方案基线 |
+
+## 4 推荐的课题验证路线
+
+### 4.1 先做可复现的实时底座
+
+建议先在一块可获得的Orin NX/Nano级开发板上固定操作系统、内核、频率和驱动版本，建立Linux基线、PREEMPT_RT基线和Linux+RTOS/Hypervisor共存方案。第一轮不急着跑完整VLA，可用固定模型推理或视频/DDR/DMA合成负载复现“AI负载压迫控制域”的时序问题。
+
+### 4.2 再挂接真实机器人工作负载
+
+低成本路径是Orin + RTOS微控制器的移动底盘/小型机械臂；展示路径可选宇树G1-D/G1-Comp或四足开发型号。接入前应确认指定版本是否开放所需SDK、低层命令、传感器时间戳、急停和控制权切换能力。机器人平台上是否能够部署本课题的Hypervisor/RTOS，需要根据厂商授权的开发单元和实际软件接口核实，不能从“支持Orin NX”推断内部控制器可被替换。
+
+### 4.3 建议统一报告的指标
+
+| 层次 | 指标 | 建议记录方法 |
+|---|---|---|
+| RTOS控制域 | 目标周期、唤醒延迟、执行时间、周期抖动P50/P95/P99/P99.9/最大值、截止期违约次数和连续违约长度 | 使用单调时钟或硬件时间戳；报告运行时间、样本数和负载条件 |
+| AI/加速器域 | 输入等待、预处理、NPU/GPU排队、推理、后处理各段时延；推理吞吐与有效结果率 | 分离排队时间与设备执行时间；同时报告冷启动和热稳态 |
+| 端到端链 | 传感器采集时间到RTOS接收结果、再到执行器命令提交的时延；AI结果年龄和过期率 | 以消息序列号和时间戳贯穿各域；不只测ROS topic往返 |
+| 资源争用 | CPU占用、DDR带宽、LLC未命中、DMA吞吐、加速器队列深度、核心迁移/中断分布 | 逐项压力与联合压力对照，报告控制时延增量及隔离效果 |
+| 故障与恢复 | 检测时间、降级切换时间、安全状态保持率、通道清理时间、重新接入时间 | 注入进程退出、NPU超时、旧/乱序数据、通信中断、热降频和Linux重启 |
+| 热与能耗 | SoC/加速器温度、频率、板级功耗、热稳态前后尾时延差 | 长时运行后再测P99.9和最大值，避免只报启动后短测数据 |
+
+### 4.4 初始验收值的设定原则
+
+在目标控制器和机械对象尚未冻结前，不宜把单篇论文的数字写成最终验收指标。可先把下列值作为第一轮工程门槛，再由控制周期、执行器接口和安全分析修订：
+
+- 若控制接口周期为2 ms，可将P99.9周期抖动≤50 μs、观测最大绝对偏差≤100 μs、规定负载下截止期违约为0作为试运行目标；
+- 若EtherCAT周期为1 ms，应单独记录周期误差和主站唤醒延迟，并按驱动器/机构允许的周期偏差给出通过线；
+- 感知或VLA消息需按任务设置有效期。超过有效期即丢弃，RTOS不得等待其完成；
+- 任何实测“最大值”必须附带测试时长、样本数、温度、频率、负载和版本信息。有限时间内零违约是实验结果，不是已证明的硬实时上界。
+
+## 5 与综述的衔接和课题落点
+
+综述中的静态分区、共享资源干扰、跨域消息契约和安全降级，在上述应用中分别落到可操作的研究问题：
+
+1. **体系结构贡献：** 明确AI域、控制域和Hypervisor的职责与设备所有权；
+2. **实时性贡献：** 在相同传感与控制链下比较普通Linux、PREEMPT_RT、AMP和静态分区方案；
+3. **资源治理贡献：** 使用真实NPU/GPU推理、图像流、DMA和存储负载测量控制尾时延；
+4. **协同机制贡献：** 将序列号、采集时间、模型版本、置信度和有效期纳入IPC协议；
+5. **安全证据贡献：** 通过过期结果拒绝、AI超时降级、Linux重启恢复和设备故障注入验证安全边界。
+
+因此，推荐把“**具身机器人上的视觉/语言任务与实时运动控制共存**”作为总体应用牵引，把“**Orin类SoC + RTOS安全控制域 + Linux AI域 + 有界IPC + 多资源压力**”作为系统研究对象；先以移动底盘或EtherCAT小型执行器快速建立可复现实验，再在宇树人形或四足平台上验证场景价值和系统适用范围。
+
+## 参考资料
+
+1. Seeed Studio. *Deploy a PREEMPT_RT Real-Time Kernel with a Prebuilt DEB Package on Seeed reComputer Jetson Devices*. [官方工程测试与复现实验](https://wiki.seeedstudio.com/deploy_preempt_rt_kernel_with_prebuilt_deb_package_on_recomputer_jetson/)，访问日期：2026-09-28。
+2. NVIDIA. *Installing Real-Time Kernel — Jetson Linux Developer Guide, R39.2*. [官方文档](https://docs.nvidia.com/jetson/archives/r39.2/DeveloperGuide/SD/Kernel/RealTimeKernel.html)，访问日期：2026-09-28。
+3. YE Y, NIE Z, LIU X, et al. ROS2 Real-time Performance Optimization and Evaluation[J]. Chinese Journal of Mechanical Engineering, 2023, 36:144. [DOI: 10.1186/s10033-023-00976-5](https://doi.org/10.1186/s10033-023-00976-5)。
+4. BONCI A, BRUNELLA F, COLLETTA M, et al. ROS 2-Based Architecture for Autonomous Driving Systems: Design and Implementation[J]. Sensors, 2026, 26(2):463. [DOI: 10.3390/s26020463](https://doi.org/10.3390/s26020463)。
+5. YANG Z, WANG Q, WANG Y, et al. Jetson-PI: Towards Onboard Real-Time Robot Control via Foresight-Aligned Asynchronous Inference[EB/OL]. arXiv:2607.12659, 2026. [https://arxiv.org/abs/2607.12659](https://arxiv.org/abs/2607.12659)。
+6. Unitree Robotics. H1/H1-2产品规格. [宇树官方页面](https://www.unitree.com/cn/h1/)，访问日期：2026-09-28。
+7. Unitree Robotics. G1-D End-to-End Platform for Humanoid Robot. [宇树官方页面](https://www.unitree.com/G1-D/)，访问日期：2026-09-28。
+8. Unitree Robotics. G1-Comp产品及RoboCup SDK. [宇树官方页面](https://www.unitree.com/cn/robocup/)，访问日期：2026-09-28。
+9. Unitree Robotics. Unitree SDK2 Python，G1低层控制示例. [官方代码仓库](https://github.com/unitreerobotics/unitree_sdk2_python/blob/master/example/g1/low_level/g1_low_level_example.py)，访问日期：2026-09-28。
diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/README.md
index 469b093..8a1e5ba 100644
--- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/README.md
+++ b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/20-实验与验证/README.md
@@ -4,7 +4,8 @@
 
 ## 文件
 
-1. [00-实验设计与验证方法.md](./00-实验设计与验证方法.md)：当前实验设计与指标骨架。
+1. [00-实验设计与验证方法.md](./00-实验设计与验证方法.md)：当前实验设计与指标骨架；
+2. [01-工程应用场景与性能指标对标.md](./01-工程应用场景与性能指标对标.md)：宇树具身机器人、Orin移动机器人和EtherCAT场景，以及公开时延、抖动和实验指标参照。
 
 ## 后续需要补充
 
@@ -13,5 +14,6 @@
 - 每次实验运行记录；
 - 资源争用和故障注入记录；
 - Linux、RTOS、Hypervisor及Hybrid方案的统一对照表。
+- 根据最终选定的SoC、机器人型号和控制接口，把本文件中的公开对标值替换为目标板实测值。
 
 [返回总目录](../README.md)
diff --git a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md
index 8fced88..9841975 100644
--- a/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md
+++ b/02-项目框架/02-项目框架2-面向AI的实时控制基础系统研究/30-子课题B-面向边侧SoC的混合实时控制基础系统/README.md
@@ -24,7 +24,8 @@
 
 - [子课题定义](./00-总览与定位/00-子课题定义.md)
 - [研究问题与适用场景](./00-总览与定位/01-研究问题与适用场景.md)
-- [国内外研究综述](./00-总览与定位/02-国内外研究综述.md)
+- [面向边侧异构SoC的混合实时控制基础系统研究综述](./00-总览与定位/02-面向边侧异构SoC的混合实时控制基础系统研究综述.md)
+- [主流异构边侧设备与AI模型性能指标综述](./00-总览与定位/03-主流异构边侧设备与AI模型性能指标综述.md)
 
 ### 10-技术框架
 
@@ -33,6 +34,7 @@
 ### 20-实验与验证
 
 - [实验设计与验证方法](./20-实验与验证/00-实验设计与验证方法.md)
+- [工程应用场景与性能指标对标](./20-实验与验证/01-工程应用场景与性能指标对标.md)
 
 ### 30-实施管理