4G设备远程固件升级怎么做
4G 控制器和 DTU 设备怎么做远程固件升级？区分模组自身 FOTA 和 MCU 固件升级，对比 MQTT 通知 + HTTP 下载、MQTT 分片下发和串口透传逐帧升级三种方式，讲清断点续传、流量、批量灰度和失败中止，附储能 BMS 远程升级的真实流程。
本文目录
设备装到客户现场以后，升级固件最怕的就是派人去。4G 设备本来就在线，远程升级是最自然的需求。但真做起来会发现，"4G 设备升级"其实分好几种情况，方案差别很大。
这篇讲 4G 控制器和 DTU 设备的远程固件升级。设备侧通用的分区、校验和回滚，请先看 固件OTA升级全流程。
先分清：升级的是模组还是 MCU
4G 设备里通常有两份固件：
- 4G 模组自己的固件：模组厂商提供，一般通过模组厂商的 FOTA 服务或者 AT 指令升级，你基本只需要按模组手册操作
- 你的 MCU 固件：你们自己写的业务逻辑，这才是大部分厂家真正要升级的
下面说的都是 MCU 固件的远程升级。BMS 云平台项目里，4G 模组固件和电池、仪表固件是三种独立的升级流程，地址和步骤各不相同，就是这个原因。
三种常见方式
| 方式 | 流程 | 适合 |
|---|---|---|
| MQTT 通知 + HTTP 下载 | 平台发升级通知（带下载地址、版本、CRC），模组用 HTTP 下载到本地，再交给 MCU | 模组有文件系统或设备有外部 Flash，固件较大 |
| MQTT 分片下发 | 平台把固件切片，通过 MQTT 一片片发，设备逐片确认 | 设备没有足够存储做整包缓存，或模组不方便用 HTTP |
| 串口透传逐帧升级 | 模组只做透明通道，平台按 MCU 原有的串口升级协议逐帧发送 | 设备已有串口 / Modbus 升级能力，不想改固件 |
方式一：MQTT 通知 + HTTP 下载
这是资源允许时最推荐的方式：
- 平台通过 MQTT 下发升级通知：
{ "version": "1.4.2", "url": "...", "size": 98304, "crc32": "..." } - 设备检查型号和版本，回执"接受"或"拒绝"
- 模组用 HTTP 下载固件，支持 Range 请求，断了可以从已下载的位置继续
- 下载完校验 CRC，通过后写入 MCU 的下载区
- MCU 切换、重启，上报新版本号
HTTP 下载比走 MQTT 效率高，也更适合大文件。下载地址最好带有效期和签名，避免被随意下载。
方式二：MQTT 分片下发
设备不方便用 HTTP 时，可以由平台通过 MQTT 分片发送。要点：
- 每片带序号或偏移，设备逐片确认，确认里带下一片期望的偏移
- 每片大小要考虑模组 AT 指令单次收发的上限和 MCU 的缓冲区
- 用 QoS 1 时可能收到重复片，设备按偏移去重
方式三：串口透传逐帧升级
很多已经量产的设备，原本就能用上位机通过串口升级，只是每次要派工程师到现场。这种情况可以不改设备固件，让模组做透明通道，平台模拟上位机按原协议逐帧发送。
我们的 储能 BMS 远程固件升级平台 就是这样做的：BMS 只认 Modbus 寄存器协议，联网靠 WiFi 模组透传。升级按"查询版本 → 写入升级请求 → 1KB 分片传输 → 写入完成"执行，每一步都等设备应答。单帧超时自动重试，累计失败超过上限就中止并记录停在哪一帧，升级完成后自动回读版本号。4G 模组透传也是同样的思路。
这种方式的代价是慢：每帧都要经过"平台 → Broker → 模组 → 串口 → MCU → 串口 → 模组 → Broker → 平台"一个完整往返。
断点续传和失败中止
4G 现场信号不稳是常态，升级流程必须能处理中断：
- 设备记录已接收的偏移，重新开始时告诉平台从哪里继续
- 单片超时重试，但要设累计失败上限，超过就中止，不要无限重试
- 中止后旧固件继续运行，平台记录失败原因和停止位置，等信号好了再重试
最怕的是升级卡在一半没人知道。平台要能看到每台设备的升级状态和日志。
流量和时间
升级一次的流量 ≈ 固件大小 × (1 + 协议和重传开销)。一个 100KB 的固件，用 HTTP 下载开销很小；逐帧透传因为每帧都有协议头和应答，开销会大一些。设备量大的项目，算一下批量升级的总流量，避免超出卡的套餐。
批量升级要分批
不要一次给所有设备推升级：
- 先选几台测试设备升级，确认正常
- 再按客户、项目或地区分批扩大
- 设置失败率阈值，超过就自动暂停
我们的储能 BMS 平台支持单台和批量升级，进度条和逐行升级日志实时刷新，客户、项目、设备和固件版本都有记录。平台侧的任务编排和灰度，可以看 设备OTA升级平台怎么做。
升级前的条件检查
控制器类设备尤其要注意：设备正在运行时能不能升级？锅炉在加热、电机在运转、储能在充放电，这时候重启设备可能有安全问题。升级协议里要让设备有权拒绝："当前运行状态不允许升级"，等停机后再执行。
常见问题
模组透传方式，固件完全不用改吗？
如果设备已有可用的串口升级协议，平台侧按原协议发送即可，设备固件基本不用改。需要确认模组能稳定透传、串口参数匹配，以及原协议对超时的容忍度。
升级失败设备会变砖吗？
取决于设备侧的设计。只要 Bootloader 独立、写入下载区或备份区、校验通过才切换，升级失败只会停在旧版本，不会变砖。
能做定时升级吗，比如半夜升级？
可以。平台按时间段下发升级任务，设备在空闲时段执行，减少对使用的影响。
你们能做 4G 远程升级的平台吗？
可以，参考 OTA 升级平台开发。设备侧的协议，也可以 联系我们 和你们的嵌入式工程师一起定。