23 OTA·设备管理·Fleet 洞察
- 章节编号:23
- 所属层:D 部署与服务层(承接 22 打包、10 BSP、28 安全)
- 关联 ADR:ADR-079(OTA 架构:A/B + 签名 bundle)、ADR-080(Fleet 管理与设备画像)、ADR-081(灰度与回滚策略)、ADR-082(provisioning 与身份)
- 上游依赖:10(AB 分区/secure boot)、22(bundle)、24(云端)、28(签名/加密)
学习目标
- 前置知识:读过 22 章(bundle 打包/semver)、10 章(A/B 分区与 secure boot)、28 章(签名/加密链)的概览;知道「什么是 rootfs」「什么是差分升级(delta)」「什么是设备证书」;对「远程升级(OTA,Over-The-Air)一旦失败就可能变砖」有直观认识。无需车队运维或量产产线经验——本章从「更新原子性与车队风险控制」而非「具体云平台 API」切入。
- 学完产出:① 能说清一台机器人的 OTA 是分层的——VLA bundle(周级)、runtime/SDK(月级)、rootfs/BSP(季度)、NPU firmware(极少),并解释「模型 OTA 为什么必须独立于 OS OTA」;② 能把 A/B 双分区升级流程在时间轴上拆开算一遍,理解「为什么双份存储的代价换来的是升级永不砖机」;③ 能解释灰度发布(canary→staged→fleet) 如何把「一次坏更新炸掉整个车队」的风险收敛成「只炸 1%」,并说清触发自动回滚的判据;④ 能讲清签名 bundle 与供应链安全——为什么「设备只信任签名过的包」是 secure boot 到应用层的信任链闭环,以及签名缺失会带来怎样的攻击面;⑤ 能读懂本章 ADR 候选(ADR-079~082),把「怎么升级车队」翻译成「分区策略 + 签名链 + 灰度编排 + provisioning」的可执行输入。
- 阅读姿势:盯住一条主线——「OTA 工程的一切设计,都是在『把新版本推给成千上万台在野设备』这件天然高危的事上,层层加装安全网」。双分区是「升级失败能退回去」的网,灰度是「坏更新只影响一小撮」的网,签名是「设备只装可信包」的网。读表格时不要只看平台名,要问「它在哪一层加了哪张网、失败面被收敛到多大」。
1. 范围与目标
定义 海量机器人设备的远程更新、灰度、provisioning、设备画像。扩展阶段 聚焦 端侧 OTA 机制 + Fleet 最小闭环;大规模多租户 规模化阶段。
核心问题
- 更新 bundle / rootfs / firmware 哪几层?
- 对标 Jetson OTA、Qualcomm、Tesla Fleet、AWS IoT Greengrass?
- 灰度与 rollback 如何与 22 bundle semver 联动?
- secure boot(28) 如何衔接?
2. 需求洞察(具身驱动)
| 场景 | OTA 诉求 |
|---|---|
| VLA 模型热更新 | bundle delta;不影响 1kHz 岛 |
| JetPack 式 BSP 升级 | 全 rootfs A/B;少频次 |
| 工厂产线 provisioning | 设备证书 + 首包 |
| 1000+ 仓储机器人 | Fleet 分组灰度 |
硬性指标:bundle OTA ≤10min;失败 自动回滚;签名 100%。
为什么具身设备的 OTA 比手机/服务器更难:一台机器人是带电机、会移动、可能伤人的物理设备。手机升级失败大不了重刷,机器人升级到一半失联或行为异常,轻则产线停摆、重则安全事故。因此本章所有机制的隐含前提是:任何一次升级都必须满足「要么完全成功、要么完全回退到已知可用状态」的原子性,并且 1kHz 实时控制岛在整个升级过程中不能被打断——这是与通用 IoT OTA 最本质的区别。
3. 技术现状与趋势(点名 + 来源)
3.1 TOP 级 OTA/Fleet 深度对比(2025–2026)
| 平台 | 模型 OTA | OS/BSP OTA | Fleet/管理 | 灰度 | 机器人案例 | 优势 | 劣势 |
|---|---|---|---|---|---|---|---|
| NVIDIA Jetson | NGC/容器;partner 模型 | Jetson Linux OTA;Yocto | Orbit(BD 等);Redfish | 伙伴定 | Boston Dynamics | BSP 成熟 | 无统一 VLA OTA 标准 |
| Qualcomm QIRP | QNN context | Yocto meta-qcom OTA | 车规 Fleet | 车规级 | IQ10 CES 2026 | ASIL 流程 | 文档新 |
| Tesla | 整车 OTA | 一体 | 自有 百万车 Fleet | 全球灰度 | Optimus(规划) | 规模经验 | 闭源 |
| AWS IoT Greengrass | Component 版本 | 容器 | IoT Core | Job 部署 | 通用 IoT | 托管 | 非机器人实时 |
| Mender/RAUC | 应用层自定 | A/B rootfs | 需自建 | 支持 | 工业 IoT | 开源 reproducible | 无 AI 语义 |
| HuggingFace Hub | 模型权重 | ❌ | 下载统计 | ❌ | LeRobot | 生态 | 无设备管理 |
| ROS2 micro-ROS | ❌ | MCU | 有限 | ❌ | 传感器 MCU | 轻量 | 非 VLA |
| 我们(目标) | signed bundle delta | RAUC/Mender A/B | 最小 Fleet API | canary | manifest 驱动 | 模型/OS 解耦 | 从零 |
TOP 级对标结论:
- 规模标杆 = Tesla 百万车 Fleet:全球灰度 + 设备画像 + 整车 OTA 的运营经验是行业天花板,但一体化管道也意味着 AI 与 OS 强耦合、失败面大;FSD 的整车 OTA 是我们「车队灰度 + 设备画像」维度的借鉴对象(运营模式借鉴,非技术栈绑定)。
- 开源可复现路径 = Mender/RAUC:A/B rootfs 原子切换是 Yocto 官方同证路径(JetPack/QIRP 同源),但无 AI 语义——模型 bundle 的差分/签名要自建。
- 我们的差异化 = 模型/OS 解耦的双轨 OTA:VLA bundle 走周级 delta,rootfs 走季度 A/B,两条管道独立 rollback,1kHz 岛全程不受影响——这是既有平台都没有做完整的空白点。
3.1a 方案深度对比
双轨 OTA(我们推荐 vs Tesla 一体)
| 维度 | 我们双轨(bundle + rootfs) | Tesla 一体 OTA |
|---|---|---|
| 优势 | VLA 周级 迭代不影响 BSP;岛 1kHz 不受模型 OTA 影响 | 单管道简单 |
| 劣势 | 两套 rollback 逻辑 | AI 与 OS 耦合;失败面大 |
| 借鉴 | Tesla 全球灰度 + 设备画像(运营模式) | Tesla 单管道原子切换(工程简洁性) |
Mender/RAUC + 自研 bundle OTA
| 优势 | 劣势 |
|---|---|
| Yocto 官方路径(JetPack/QIRP 同证);A/B 原子切换 | 需自建 bundle 签名/差分 |
| 与 28 secure boot 衔接 | Fleet 层需自研或接 IoT 平台 |
AWS Greengrass(客户可选)
| 优势 | 劣势 |
|---|---|
| 托管 component、Job | 不适合 1kHz;vendor lock-in |
| 适用 边缘网关 多 robot 汇聚 | 非 MLIR/bundle 原生 |
3.1b Provisioning 与设备画像(加深,v4)
| 阶段 | 动作 | 对标 |
|---|---|---|
| 产线烧录 | 设备唯一 key + OEM cert | Qualcomm QTEE provisioning |
| 首次 开机 | Fleet register + manifest 首包 | Jetson Orbit |
| 运行期画像 | SKU tier / camera count / scenario_id | Tesla VIN+config |
设备画像字段(ADR-080 候选): device_id, sku_tier, bundle_version, thermal_profile, scenario_ids[], tenant_id(36 多租户)。
3.1c A/B 双分区升级机制(新增,深化 secure boot 衔接)
A/B 升级(也叫 无缝升级 / seamless update)是本章最核心的原子性保证机制。它的思路极其朴素:设备上永远保留两份可启动的系统槽(slot),升级时写「非活动」的那一份,验证通过后再原子地切换启动指针。下图是完整的状态机:
三个关键不变量:
- 升级写非活动槽,永不动正在跑的槽:活动 Slot A 在整个下载/写入/校验期间照常运行,1kHz 控制岛零中断——这是具身设备能「在线升级」的前提。
- 切换是原子的:bootloader 只翻转一个「启动哪个槽」的指针(通常一个 bootloader 环境变量),要么指 A 要么指 B,不存在「写了一半」的中间态。
- 回退由 bootloader 兜底:切到 B 后先进 trial(试运行)态,若启动后健康检查/watchdog 未在超时内喂狗,bootloader 下次开机自动退回 A。这就是「升级失败也不会砖机」的硬件级保险——RAUC/Mender/Jetson Linux OTA 的 A/B 实现都遵循这套语义。
3.1d 签名 bundle 与供应链信任链(新增)
「签名 100%」不是一句口号,而是从上电到跑模型的完整信任链(chain of trust)。每一层只加载并执行「上一层用私钥签名、本层用公钥验签通过」的产物,任何一环被篡改,验签立即失败、拒绝启动:
为什么模型 bundle 也必须签名:很多团队只对 OS/bootloader 做 secure boot,却把模型权重当「普通数据文件」直接下发。但在具身场景里,模型权重就是设备的行为定义——一个被投毒的 VLA 权重可以让机器人做出危险动作。因此 bundle 的 manifest 必须携带权重哈希 + 发布方签名,设备在加载前用固化公钥验签,验签失败即拒绝并回退。这样才把 secure boot 的信任链从「OS 层」一路延伸到「应用/模型层」,堵住供应链投毒(supply-chain poisoning)的攻击面。
3.2 分层 OTA
| 层 | 频率 | 机制 |
|---|---|---|
| VLA bundle | 周级 | delta weights/spec;22 ADR-075 |
| IREE runtime/SDK | 月级 | packagegroup 升级 |
| rootfs/BSP | 季度 | A/B reboot(10 ADR-060) |
| NPU firmware | rare | KMD 加载+签名(09) |
分层的核心动机是「更新频率与更新代价的匹配」:VLA 模型在 LeRobot/GR00T 生态里可能一周迭代好几次,但它只是「数据 + spec」,用 delta 差分几十兆就能热更、无需重启;而 rootfs/BSP 动辄上 GB、必须 A/B reboot,一个季度才升一次。若把这两者绑进一个整包(Tesla 式一体 OTA),就会被迫用「重启季度包」的节奏去发「周级模型」,白白牺牲迭代速度。分层 OTA 让每一层按自己的频率和代价独立演进,这是双轨设计的根本理由。
3.3 灰度策略
canary(1%) → staged(10%) → fleet(100%)
↓ fail ↓ fail
rollback hold + alert(29)
灰度(canary/staged rollout)本质是把「一次坏更新的爆炸半径」从 100% 收敛到 1%:新版本先只推给 1% 的金丝雀设备,盯住它们的健康指标(崩溃率、rollout 成功率、p99 延迟、thermal),只有全绿才放量到 10%、再到全量;任一阶段指标越线,canary 阶段直接自动回滚,staged 阶段则冻结推送(hold)并告警(29 章)。
设备画像:hardware rev、power_profile、manifest 版本、telemetry 版本。
3.4 趋势
- 模型 OTA 独立于 OS OTA——LeRobot/GR00T 迭代 远快于 JetPack。
- 签名 mandatory(28);delta weights 成标配(22)。
- Zenoh 作跨域 Fleet 发现(10 章);DDS 域内。
- Boston Dynamics + Orbit 证明 机器人 Fleet 是独立产品层,非 BSP 附属。
- Tesla FSD 整车 OTA 的全球灰度运营成为「大规模车队分批放量 + 设备画像驱动分组」的行业参照(运营模式借鉴,截至 2026 年中 Optimus 车队仍属规划,以官方为准)。
4. 候选方案
| 候选 | 小结 |
|---|---|
| A. 自研 bundle OTA + 开源 Mender/RAUC rootfs | 建议方案 |
| B. 全托管 AWS Greengrass | 客户可选;非核心 |
| C. 仅 USB 离线更新 | M1 only |
6. 结论与 ADR
- 双轨 OTA:bundle 高频 + rootfs A/B 低频。
- Fleet 最小集:注册、分组、灰度、回滚、画像。
- 全签名链(28)。
- ADR-079 OTA 架构:signed bundle;A/B slot;原子切换;与 22 semver 绑定。
- ADR-080 Fleet:设备注册、分组、manifest 版本查询;REST+Zenoh 可选。
- ADR-081 灰度回滚:canary→staged→fleet;失败 auto-rollback N-1 bundle。
- ADR-082 provisioning:工厂 设备证书;首包注入;28 secure boot 衔接。
深入思考
每题先给题干,再折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1:A/B 双分区为何能保证升级「无砖」
一次 rootfs OTA 下到一半突然断电,或新镜像启动后驱动崩溃——如果是单分区「原地覆盖」升级,设备就变砖了。结合 §3.1c 的 A/B 状态机,论证「双分区 + 原子指针切换 + bootloader 回退」这三件事如何组合成「升级失败也永不砖机」的保证,并算一遍双份存储要付出的代价——它到底值不值。
展开参考答案（含 A/B 失败路径 图 + 存储代价算一遍）
结论:单分区升级的致命点在于「覆盖正在用的系统」——一旦中途失败,旧的没了、新的不完整,设备无系统可启动就是砖。A/B 双分区把升级永远写在「非活动」的那一份上,活动份全程照跑;只有校验通过才原子翻转启动指针,且新份先进试运行态、健康检查不过 bootloader 自动退回旧份。三重保险叠加,任何一步失败设备都还停在一个「已知可用」的槽上,因此永不砖机。代价是多占一倍的系统分区存储,但相对整机成本和「变砖 = 上门返修」的代价,这份冗余极其划算。
用具体数字算一遍双份存储的代价(数量级估算,以实际镜像为准):
- 一份 rootfs/BSP 镜像典型 ~4GB(kernel + 驱动 + 用户态基础包)。A/B 双份即 ~8GB——比单份多占 4GB 存储。
- 一台机器人的存储(eMMC/NVMe)通常 64GB~256GB。多占的 4GB 约占 1.5%~6%,量产物料成本约增加 几美元(以当期 NAND 价格与容量分档为准)。
- 对比不做 A/B 的代价:单分区升级一旦失败变砖,现场设备无法远程恢复,需要上门/返厂重刷,单次运维成本(人力 + 停机 + 物流)动辄 数百美元,且规模化后按失败率乘以车队数量放大。
- 结论算式:多花几美元的 NAND 冗余,换来「升级失败率 × 车队规模 × 数百美元返修成本」的整块风险归零——在任何有一定出货量的场景下,A/B 的存储代价都远小于变砖的期望损失。这也是 JetPack/QIRP/Mender/RAUC 无一例外都用 A/B 的原因。
回链:详见 §3.1c A/B 双分区升级机制状态机、§3.2 分层 OTA(rootfs 走 A/B reboot)、§6 ADR-079「A/B slot;原子切换」与 ADR-081「auto-rollback N-1 bundle」。
思考题 2:灰度发布如何控制 fleet 风险
你手上有 1000 台仓储机器人,准备推一个新 VLA bundle。若一次性全量,万一新模型在某类货架布局下抓取失败率飙升,就是 1000 台同时出问题。结合 §3.3 灰度策略与 §3.1b 设备画像,分析 canary→staged→fleet 分批放量如何把爆炸半径收敛,以及应该用哪些指标作为「继续放量 vs 自动回滚」的判据。
展开参考答案（含灰度放量决策图 + 爆炸半径对比表）
结论:灰度的核心是「先小样本验证、再逐级放量」,把「一次坏更新炸掉整个车队」变成「最多炸掉当前批次那一小撮」。1% 金丝雀先扛雷,盯住崩溃率、rollout 成功率、p99 延迟、thermal 等健康指标,全绿才升到 10%、再全量;任一批次指标越线,canary 阶段直接自动回滚 N-1、staged 阶段冻结推送并告警。设备画像则决定「金丝雀选谁」——按 SKU tier/场景分层抽样,确保小样本能代表全车队的多样性。
用具体数字算一遍爆炸半径(1000 台车队):
| 放量策略 | 出问题时受影响设备 | 发现坏更新前的暴露量 | 回滚运维量 |
|---|---|---|---|
| 一次性全量 | 全部 1000 台 | 全车队同时异常,可能引发生产事故 | 需回滚 1000 台 |
| canary 1% | 仅 ~10 台 | 10 台异常即被指标捕获、触发回滚 | 只回滚 ~10 台 |
| staged 10% | 至多 ~100 台(canary 已过) | 100 台样本进一步验证边缘场景 | 冻结 + 回滚 ~100 台 |
判据指标怎么选(健康检查越线即回滚/冻结):
- 崩溃率 / 看门狗触发次数:进程崩溃、watchdog 未喂狗——最硬的红线,越线立即回滚。
- rollout 成功率:VLA 任务(抓取/放置)成功率相对基线的跌幅,是具身特有的「行为正确性」指标,比通用 IoT 的「进程存活」更关键。
- p99 延迟 / chunk 延迟:新模型是否拖慢推理、击穿实时预算(参见 21 章 chunk 延迟口径)。
- thermal / power_profile:新版本是否让 SoC 过热降频(§3.1b 画像字段)。
设备画像为什么关键:金丝雀不能随便挑 10 台,要按 sku_tier/scenario_ids[]/thermal_profile 分层抽样,让这 1% 覆盖车队的硬件档次与场景多样性——否则金丝雀全是同一型号同一货架,放量后遇到没覆盖的 SKU/场景照样翻车。这正是 §3.1b 设备画像字段服务于灰度的用途。
回链:详见 §3.3 灰度策略(canary→staged→fleet)、§3.1b 设备画像字段、§3.4 趋势 5(Tesla 全球灰度借鉴),以及 §6 ADR-081「canary→staged→fleet;失败 auto-rollback N-1 bundle」。
思考题 3:签名 bundle 与供应链安全
有人提议:「模型权重就是一堆浮点数,又不是可执行代码,下发时省掉签名验证能加快 OTA。」结合 §3.1d 信任链图与 §3.4 趋势 2(签名 mandatory),反驳这个提议——论证为什么在具身场景里模型 bundle 必须签名,以及签名缺失会打开怎样的供应链攻击面。
展开参考答案（含签名验证 vs 缺失攻击面对比图 + 对比表）
结论:在具身设备上,模型权重不是「无害的数据」,而是「设备的行为定义」——一个被投毒的 VLA 权重能让机器人做出危险或恶意动作,危害等同于恶意代码。省掉签名验证等于在 secure boot 辛苦建立的信任链末端开一个大洞:设备会照单全收任何来源的权重。因此 bundle 必须携带发布方签名 + 权重哈希,设备用固化公钥验签、不过即拒,把信任链从 OS 层一路闭合到模型层。
签名 vs 缺失的攻击面对比:
| 维度 | 签名验证(mandatory) | 缺失签名 |
|---|---|---|
| 中间人替换 | 篡改后哈希/签名不匹配 → 拒绝加载 | 设备无法分辨真伪,直接加载被替换的权重 |
| 仓库/分发链投毒 | 发布方私钥签名,攻击者无私钥无法伪造 | 攻破分发服务器即可推恶意权重给全车队 |
| 行为可追溯 | 每个 bundle 绑定发布方签名,可审计溯源 | 无从判断权重来源,事故无法归因 |
| 信任链完整性 | RoT→bootloader→OS→runtime→bundle 全闭 合 | secure boot 到 OS 就断了,应用层裸奔 |
为什么「不是可执行代码」的辩解站不住脚:传统安全直觉里「数据无害、代码危险」,但在具身 AI 里这条界线消失了——模型权重经由 runtime 直接决定电机输出,一个精心投毒的权重可以在特定触发条件下让机器人执行危险动作(定向投毒/后门)。其危害不亚于注入恶意代码,却因为「看起来只是浮点数」而容易被忽视。因此 §3.4 趋势 2 把「签名 mandatory」列为硬规则,§2 硬性指标要求「签名 100%」——信任链只要有一环不验签,整条链就等于没有。工程上,验签的开销(一次哈希 + 一次公钥验证,毫秒级)相对整个 OTA(下载 + 写盘,分钟级)可忽略,「省签名换速度」是拿系统性安全风险换取几乎为零的收益,得不偿失。
回链:详见 §3.1d 签名 bundle 与供应链信任链图、§2 硬性指标(签名 100%)、§3.4 趋势 2(签名 mandatory + delta weights),以及 §6 ADR-079「signed bundle」与 ADR-082「secure boot 衔接」。
附:信息来源
- NVIDIA Jetson OTA docs;Mender/RAUC;Qualcomm QIRP OTA layers。[公开]
- Tesla 整车 OTA / 全球灰度 / 百万车 Fleet:Tesla 官方博客与 FSD 发布记录;Optimus 车队为规划,以官方为准。[公开]
- A/B seamless update 语义:RAUC/Mender 文档、Android A/B system updates、Jetson Linux OTA。[公开]
- 10 ADR-060;22/28 章。[内部]