工业边缘 AI 设备这两年落地速度越来越快，但真正干过现场交付的人都知道，“装系统”和“配环境”这两件事能逼疯半个项目组。尤其是煤矿、港口、化工厂这类场景，网络条件差、机柜环境乱、现场工程师又不一定懂 Linux，一台设备开箱之后光是装驱动、配推理引擎、改配置文件就能折腾大半天。我们做的边缘 AI 盒子（就是那种内置 GPU/NPU、跑目标检测或行为识别算法的工业小主机），最开始交付时也是派人一台台到现场部署，后来量一上来，这套路完全走不通。这篇文章就围绕冷部署和 OTA 远程升级这套组合拳，聊聊怎么让工业边缘 AI 设备真正做到插电即用、远程可维护。
先解释一下这两个词。冷部署，指的是设备在出厂或者首次上电时，不需要人工介入安装操作系统、部署运行环境，而是通过预置镜像、自动初始化等手段，让设备拿到手就能直接跑业务。OTA 远程升级，就是从云端或者本地管理平台，把新的固件、算法模型、配置文件远程下发到设备上，自动完成升级和回滚。这俩事儿凑在一起，解决的正是工业边缘场景里两个最头疼的问题：开箱调试时间太长，以及设备分散在各地之后没法派人频繁出差。下面我把整个方案的来龙去脉、关键设计、踩过的坑一起拆开说。
1. 内容整体设计与思路拆解
1.1 为什么工业场景必须“开箱即用”
我们最早做边缘 AI 盒子的时候，交付流程是：设备到现场 -> 接显示器键盘 -> 装 Ubuntu -> 装显卡驱动/CANN/TensorRT -> 配 IP -> 同步算法模型 -> 测试拉流识别。这套流程在实验室里很顺，到现场就全是意外。矿上的工程师不会 vi，化工厂的交换机端口没开 DHCP，港口项目连外网都没有，驱动包 2 个 GB 拷不过去。一个站点 10 台设备，运气好一天弄完，运气不好两天都打不住。而且这种部署方式高度依赖人的经验，A 工程师装的和 B 工程师装的系统，分区大小不一样、环境变量不一样、启动项不一样，后期运维全是坑。
所以“开箱即用”不是锦上添花，是规模化交付的硬门槛。我们的思路很直接：设备在产线上就把操作系统、AI 运行环境、算法服务全部烧录好，到现场只需要做两件事——插网线、扫码绑定。剩下的全部自动化。
这套思路拆开来看有三个关键点：第一是镜像的标准化，保证每台设备出厂状态完全一致；第二是首次开机的自初始化，设备能自己完成网络配置、证书申请、业务注册；第三是配套的远程管理通道，让运维人员不需要到现场也能看到设备状态、下发任务。冷部署解决前两点，OTA 解决第三点和后续迭代问题。
1.2 冷部署与 OTA 的组合价值
冷部署和 OTA 并不是两个孤立的功能，它们本质上是同一套设备生命周期管理体系的上下两端。冷部署解决的是“出生问题”，OTA 解决的是“成长问题”。
设备出厂时通过镜像烧录，把包含操作系统、AI Runtime、推理服务、管理 Agent 的完整系统写入存储介质。这意味着设备第一次上电时，系统就已经处于“待命”状态，中间层软件全部就位。而 OTA 升级体系是为了后续的版本迭代：算法模型的精度要提升、推理框架要修 bug、甚至 Linux 内核要打安全补丁，这些都不能靠人到现场操作，必须远程完成。
这套方案的另一个隐性价值是故障恢复。我们做 OTA 的时候，会保留上一版本作为回滚兜底。所以一旦远程升级出问题，设备能自动退回旧版本，不会变成砖。这一点在远程维护场景里太重要了——现场没有技术员，设备恢复不了就只能发快递返厂，成本极高。
1.3 技术选型的核心权衡
先说操作系统层。工业边缘 AI 设备的主流方案是 Ubuntu 或 Debian 系，因为 AI 框架（比如 PyTorch、TensorRT、昇腾的 CANN）对 Ubuntu 的支持最完整，驱动厂商的官方文档也都是基于 x86/ARM + Ubuntu 来写的。我们试过 Alpine 这种精简发行版，跑轻量服务没问题，但到推理框架这层就各种“缺 lib”，兼容成本太高。所以冻结在一套经过验证的 Ubuntu LTS 版本上，是最省心的选择。
再说是整机镜像还是容器化。有一部分团队会选择在设备上预装 Docker，然后通过拉取容器镜像来完成算法服务的部署。但工业现场网络不稳定，几百 MB 甚至上 GB 的容器镜像经常拉一半断掉；而且 GPU/NPU 的设备映射、内核模块挂载在容器里容易出幺蛾子。我们的选择是“整机镜像 + 容器化内部结构”：系统层面用整机镜像保证一致性，业务服务在系统内部用 Docker Compose 管理。这样既有镜像部署的确定性，又有容器管理单个服务的灵活性。
最后说 OTA 的通道设计。设备在用户现场，业务流量走的是用户内网；OTA 管理流量如果也要穿透到我们的管理平台，就要考虑安全边界。工业场景里很多客户不接受设备主动连外网，所以我们做的是双模式：支持通过我们自建的 OTA 服务端走公网升级，也支持客户在内网部署一套离线 OTA 服务端。设备上的 Agent 只需要配置 OTA 服务地址，两种模式共用同一个升级流程。
2. 核心细节解析与实操要点
2.1 镜像标准化：从“手工装机”到“产线烧录”
实现冷部署的第一步，是有一份标准的“母本镜像”。听起来简单，实际上有很多门道。手工装机时每个人的分区、软件包版本、系统配置都可能不一样，所以必须找一个“标准机”，在它上面把系统、驱动、AI Runtime、业务服务全部装好、调好，然后在关机状态下把整块系统盘做成镜像文件。
打镜像的工具我们用过 Clonezilla、dd 加压缩、还有专门的量产工具。简单的场景，dd if=/dev/sda | gzip > image.gz就能用，但这样出来的镜像文件体积太大——一块 256GB 的 SSD，哪怕只用了 20GB，dd 全盘克隆也得搬 256GB 的数据。所以推荐用 Clonezilla 这类按已用块备份的工具，或者先对系统分区做fstrim，让文件系统把空闲块标记清楚，再用精简备份。最终我们的系统镜像一般控制在 12GB 左右，烧录到同型号的 SSD/emmc 上只需要几分钟。
镜像里面有些内容需要“出厂后再生成”，比如 SSH host key、设备唯一 ID、证书等。这些如果每个设备都一样，会有严重的安全隐患。所以要做好“首启初始化”机制：镜像里的系统服务第一次启动时，检测到标记文件不存在，就自动生成随机 host key、写入设备序列号、申请设备证书，然后把标记文件创建好。这相当于给每个设备一个“法律身份”，后面 OTA 和远程管理都靠它来识别设备。
2.2 分区方案：升级不回滚的隐患要提前堵住
做 OTA 如果不在分区层面做规划，后面一定会出大问题。最常见的坑是：整块盘只有一个根分区/，升级的时候把新版本写到根分区里，一旦写到一半断电，系统直接起不来。我们一开始就是这样，吃过亏后重新设计了分区。
当前用的分区方案大概是这样的：
| 分区 | 挂载点 | 大小 | 作用 |
|---|---|---|---|
| /dev/mmcblk0p1 | /boot | 1GB | 内核、initrd、bootloader 配置 |
| /dev/mmcblk0p2 | / | 30GB | 系统主分区（active） |
| /dev/mmcblk0p3 | /_alt | 30GB | 系统备用分区（inactive） |
| /dev/mmcblk0p4 | /data | 剩余 | 用户数据、算法模型、日志、配置 |
| /dev/mmcblk0p5 | /data_alt | 剩余 | 数据备用分区 |
核心思路是双 A/B 分区。升级的时候，新系统写入 p3，新数据写入 p5；写入完成后通过 bootloader 环境变量切换启动顺序；重启设备，bootloader 引导到新分区启动。如果新系统起不来，bootloader 里的 watchdog 超时之后自动切回 p2，设备就能恢复。这样升级过程只是写数据 + 改一个标志位，风险点被隔离在“重启瞬间”，而重启瞬间又由 watchdog 兜底。
数据分区和数据备用分区也这么搞，是因为算法模型往往和系统服务有版本对应关系。升级系统版本的时候，通常要同时升级模型；如果模型单独放在 /data 分区，升级系统时不动它，新版本服务可能因为模型不兼容直接白屏。所以我们需要“系统 + 数据”一起原子切换。
应用层的数据（比如运行日志、临时文件、用户配置）要考虑重新定向。我们的做法是：业务服务的可执行程序和依赖都装在根分区，但运行时的动态数据一律写 /data 下的独立目录。这样切分区时不会丢用户配置。
2.3 OTA 升级包设计：增量与全量怎么选
OTA 升级包分为全量包和增量包两种。全量包就是一个完整的系统镜像（通常打成了 tar.xz 或者 squashfs），不管设备当前是什么版本，直接覆盖到备用分区即可。优点是校验简单、出错率低，缺点是文件大、浪费流量。
增量包则是两个版本之间的 diff。工业现场经常是 4G 网络，流量费不便宜，增量包能省不少钱。我们用过diffoscope和zsync一类的工具，但在实际使用中增量包生成的流程复杂、必须严格基于“已知上一版本”，一旦设备中间跳过了某个版本，增量升级就失败了。所以我们的策略是：同一个大版本内的补丁升级用增量包，跨大版本升级用全量包。默认以全量包为主，毕竟包体也就 1-2GB，在千兆内网环境下不算什么。
升级包的元信息非常重要，推荐用 JSON 文件描述：
{ "version": "2.1.0", "build_time": "2025-01-08T14:30:00Z", "platform": "atlas500_arm64", "base_version": "2.0.0", "type": "full", "packages": ["system", "runtime", "detect-model"], "checksum": "sha256:cde...", "min_battery": -1, "release_note": "fix memory leak in rtsp module" }设备拿到升级包之后，先校验checksum和platform，防止传错型号的包把设备刷挂。base_version用来判断能不能用增量升级。
升级包分发的网络协议，我们直接用 HTTPS + 断点续传。工业现场网络不稳，一个 1GB 的包下载到一半断线是常事。Agent 会记录当前下载的 offset，重新连接后从断点继续，而不是从头再来。
2.4 升级 Agent 设计：系统里最不能挂的进程
OTA 升级离不开一个常驻的 Agent 进程。这个 Agent 的职责包括：注册设备、心跳上报、接收升级指令、下载升级包、校验包完整性、执行切换操作、回滚。
Agent 本身要设计得极简、极稳。它不依赖业务服务，也不依赖 AI Runtime，只依赖系统的基础库。它作为一个独立的 systemd 服务存在，设置Restart=always，而且不要让它在 rootfs 升级时把自己弄丢。
升级过程中 Agent 的处理流程是：
- 收到 OTA 服务端的升级指令，下载升级包到 /data/ota 目录（这个目录不受切换影响，两个系统都能访问）。
- 校验包的哈希值、签名、平台信息。
- 把根分区和备用分区的角色互换标记写入 bootloader 环境变量，同时写入“升级待确认”标记。
- 调用
reboot。 - 重启后，设备从新分区启动。业务服务如果正常启动，会向 OTA 服务端上报“升级成功”；Agent 收到成功确认后，清除“待确认”标记。
- 如果新系统启动失败，bootloader 里的 watchdog 检测到 3 分钟内没有正常系统上报，就自动切回旧分区启动，并上报“升级失败回滚”。
这里要特别注意一个点：千万不要在升级过程中直接修改当前正在运行的分区。很多新手做升级，想着“反正我在系统里，直接把文件替换掉不就行了”，这在 LTS 系统上偶尔能成，但一旦进程正在使用某个 .so 文件、或者磁盘写满，系统就废了。双分区方案从机制上杜绝了这种问题。
3. 实操过程与核心环节实现
3.1 制作母本镜像的步骤拆解
这里以我们常用的 Intel x86 平台 + NVIDIA 显卡的盒子为例，说一下母本镜像是怎么打出来的。
先在标准机上安装 Ubuntu 20.04 LTS（内核版本锁定在 5.15 左右），安装完基础系统后用ubuntu-drivers autoinstall安装显卡驱动；接着安装 Docker、NVIDIA Container Toolkit、我们自研的推理服务（负责拉流、推理、结果上抛）。然后做完所有配置。
做完这些之后，把系统的 hostname、IP 等个性化配置全部清掉，恢复到“出厂待初始化”的状态。用 systemd 写一个firstboot-init.service：
[Unit] Description=First boot initialization ConditionPathExists=/etc/firstboot-init.lock DefaultDependencies=no After=local-fs.target [Service] Type=oneshot ExecStart=/usr/local/bin/firstboot-init.sh TimeoutStartSec=300 [Install] WantedBy=sysinit.target这个脚本负责生成 SSH host key、写入设备序列号、生成设备证书、配置默认密码（强制用户首次登录修改）、向管理平台完成注册。
最后用 Clonezilla 把整块系统盘备份成镜像，镜像文件放到产线烧录工具能访问的目录。产线烧录时，只需要把镜像恢复到目标 SSD 上，然后开机验证，就能保证每台设备“长”得一模一样。
3.2 首次上电自动初始化的完整链路
设备到现场之后，用户接上电源和网线，按下开关。这时候设备内部其实完成了一连串操作：
- bootloader 引导系统到主分区。
- systemd 启动 firstboot-init.service，检查到第一次上电、初始化锁不存在，执行初始化脚本。
- 生成随机 host key、设备 UUID，向 OTA/管理平台发起注册请求，把设备序列号、版本号、硬件型号上报。
- 系统尝试 DHCP 获取 IP。如果在 DHCP 失败的情况下，设备会启动一个热点配网模式——用户用手机连上设备的 WiFi 热点，在网页里输入现场网络的静态 IP 或 WiFi 密码，设备拿到网络配置后自动重连。
- 业务服务启动，推理进程加载默认模型，开始处理视频流。
- 设备上报“在线可服务”状态。
这一套下来，从开机到“业务可用”，理想情况下 2-3 分钟，比人工安装部署节省的时间是以小时计的。注意，这里没有复杂的“首次配置向导”，目标就是让非专业人士也能完成，减少现场支持电话。
3.3 OTA 平台的搭建与升级实拍
OTA 管理平台本身也是一个 Web 服务，负责设备管理、升级包管理、批量任务下发、升级进度监控。早期我们用了一个相对简单的方案：设备 Agent 定时轮询 OTA 服务端的/api/ota/check接口，服务端返回“有/无升级包”以及升级包下载地址。考虑到工业场景可能没有外网，这个服务可以部署在客户内网，或者每台设备配置一个内网 OTA 地址。
升级任务从创建到完成的实际操作流程大概是：
- 在 OTA 管理端上传升级包，填写版本号、适用平台、发布说明。
- 选择目标设备组（可按项目、按站点、按型号筛选），创建升级任务，设置灰度策略（比如先选 5% 的设备，确认稳定后再全量）。
- 设备 Agent 在下一轮心跳时收到升级指令，开始下载升级包。
- 管理端能看到每台设备的下载进度、升级状态（下载中、校验中、待重启、升级成功、回滚）。
- 升级完成后，Agent 上报当前版本，管理端记录归档。
灰度发布这个点很重要。我们在真实项目里出过一次事故：某个新版本镜像里一个动态库的链接方式变了，导致一部分型号较老的设备启动异常。如果当时一次性全量下发，后果就是几百台设备集体失联。后来所有版本都强制先灰度 10 台以内，观察 24 小时再扩大范围，这个流程省下的麻烦远比它带来的延迟多。
3.4 升级流程中的关键参数与容错设计
升级包的下载超时时间、重试次数、断点续传的 chunk 大小，这些参数需要根据现场网络条件来调。
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 下载 chunk 大小 | 4MB | 太小导致请求频繁，太大大文件中断后浪费流量 |
| 下载超时 | 120s | 超过 120s 无数据则认为当前连接异常 |
| 最大重试次数 | 5 次 | 超过后上报“升级失败”，等下一个触发周期 |
| 升级确认等待时间 | 5min | 新系统启动后 5 分钟内必须上报成功，否则自动回滚 |
| 回滚等待时间 | 3min | bootloader 检测到 3 分钟无成功确认，切换回旧分区 |
最后的“升级确认”是一个容易忽略的小设计。设备在升级后启动，业务正常了，Agent 要主动上报“新系统运行正常”，服务端记录成功后，Agent 才会把 bootloader 里的“待确认”标记清除。如果没设计这个“确认”步骤，可能新系统已经在跑，但 bootloader 一直认为升级未确认，一旦设备重启，会错误地回滚到旧分区，造成版本反复横跳。
4. 常见问题与排查技巧实录
4.1 升级包写到一半设备断电怎么办
这是冷部署和 OTA 设计里最核心的容错问题。解决办法就是双分区方案。升级时新系统写的是备用分区，当前系统的启动配置没被动过。所以哪怕写入过程断电，备用分区损坏，设备重启后仍然从原系统启动，不会变砖。这一点在设备端设计时就要想清楚，不要指望把升级写成“原子操作”，因为硬件断电是任何软件都无法拦截的事件。
4.2 升级完成后业务起不来怎么办
升级后业务起不来，大多发生在包本身有问题，比如依赖库版本冲突、模型文件不兼容。这时候 bootloader 的 watchdog 会在 3 分钟内强制切回旧分区。所以在升级后的新系统里，业务服务要在 systemd 中配好Restart=on-failure，并且尽快完成启动成功通知。如果业务服务因为模型加载失败而无限重启，导致系统看起来“起来了”但实际上没上报，也会触发回滚。这种情况回滚是符合预期的，不用慌，真正要做的是在测试环境里把升级包的质量卡住。
4.3 设备长时间断网的升级策略
有些设备部署在井下或者偏远站点，一连几周没有网络。OTA 服务端下发任务后，设备一直不在线。等到设备下次上线，心跳发现有待执行的升级任务，会立即进入升级流程。但这里有个风险——如果设备上次在线时已经下载了部分升级包，下次上线需要先校验本地已有文件的完整性，再继续下载剩余部分。如果本地文件损坏，就全量重下，不能直接覆盖后继续，否则大概率升级失败。
4.4 内存和磁盘空间不足的处理
边缘 AI 盒子的存储通常不大，128GB 已经算大的了。升级包 1.5GB、备用分区要占系统空间的 1 倍，这些都会挤占存储。我们遇到过数据分区里日志文件写满，导致升级包下载了一半就报磁盘不足的情况。
建议做法：
- 日志必须做 logrotate，按大小轮转，限制最多保留 3 天。
- 系统监控要覆盖磁盘占用率，超过阈值就告警并自动清理旧的模型备份和日志。
- 升级执行前，Agent 要检查
/data分区剩余空间，不足至少 2 倍升级包大小时直接拒绝升级并上报原因。
4.5 升级包与硬件型号不匹配
这个坑在产线上很容易被忽略。不同型号的盒子，虽然 CPU 架构一样，但 GPU/NPU 型号不同、传感器接口卡不同，内核驱动自然也不能通用。但实际操作中，很容易在生成升级任务时选错设备组。解决办法有两个：升级包的元信息里明确写入platform字段，设备 Agent 在下载完成后校验该字段是否与自身匹配；另外管理端要支持按硬件型号过滤设备，不允许跨型号任务下发。
排查升级失败时，建议按这张表快速定位问题：
| 现象 | 排查点 | 解决方案 |
|---|---|---|
| 下载进度停在 0% | 防火墙拦截、OTA 地址不通 | 检查设备到服务端网络连通性，telnet 测试端口 |
| 下载到一半断开重试多次失败 | 4G 信号弱、网络抖动 | 升级包切到增量包，或者换内网 OTA 服务地址 |
| 校验失败 | 下载文件损坏 | 清理本地缓存重新下载，确认服务端文件哈希正确 |
| 重启后仍是旧版本 | bootloader 环境变量未更新成功 | 检查 U-Boot/GRUB 环境变量写入权限，确认升级确认流程是否触发回滚 |
| 新系统启动 3 分钟后回滚 | 业务服务未上报成功 | 查看新分区的 systemd 服务日志，修复启动脚本 |
| 升级成功但业务异常 | 模型文件与推理框架版本不兼容 | 回滚到旧版本，先在测试机验证新模型 |
5. 实操心得与经验复盘
我在这个项目里踩过不少坑，有些是设计层面就能避免的，有些是现场环境太过刁钻导致的。分享几条具体的经验。
第一，镜像体系的验证一定要自动化。实验室里手工验证通过不代表产线烧出来没问题。我们在 CI 里保留了“烧录 -> 启动 -> 跑一遍标准测试集 -> 上报结果”的整链路自动化用例，每出一版系统镜像都跑一遍。升级 OTA 包也一样，如果测试环境不完整，千万不要直接推向现场。
第二，网络环境没有那么好，一定要预留足够重试和断点续传的能力。煤矿井下、港口岸边、高速路侧，这些现场的网络条件远比办公室差。4G 网络经常掉线、带宽不稳定，升级包下载失败是常态。第一次做 20 台设备的批量升级之前，一定先在弱网环境（比如把带宽限制到 1Mbps）压测一遍完整流程。
第三，灰度发布不是可选项。不管你对自己打包有多自信，都先拿 1-2 台设备真实验证。尤其是算法模型的升级——模型精度在测试集上提升不代表在用户现场数据上也能跑得更好，用户现场的摄像头位置、光照条件、目标尺度很可能跟公开数据集差异很大。AI 设备的 OTA 不只是系统升级，更要关注模型升级后的业务表现。
第四，设备端的状态上报要足够细。心跳包里除了版本号，还要带上磁盘剩余空间、温度、CPU/GPU 使用率、网络信号强度。这些信息在排查远程故障时太有用了。有一次设备离线，我们通过心跳记录里的温度数据发现是设备放在室外机柜里，夏天暴晒导致热保护关机，而不是软件问题。
第五，关于安全：OTA 服务端的证书、升级包签名、设备证书等一定要做完整，防止有人篡改升级包或者伪造设备接入管理平台。我们见过用户内网里有人乱发 ARP 包导致设备离线，也见过有人尝试在升级包上做手脚。安全这块不必过分复杂，但基础该做的必须做到。
这个项目走到现在，设备批量交付到几十个站点，现场实施人员基本只需要“开箱、插电、扫码、确认在线”，剩下的升级、回收、配置变更都通过 OTA 平台远程完成。从我个人的实际体会来说，冷部署和 OTA 是一套需要从项目第一天就规划进去的体系，而不是等设备部署到几百台之后再来补课。如果你正在做工业边缘设备的产品或交付，建议先从镜像标准化和双分区方案入手，把“设备出厂后还能远程安全升级”这个能力当作基础功能，而不是锦上添花的事来设计。
