真实交付项目OTA 升级储能设备
储能 BMS 远程固件升级平台
为储能 BMS 厂商建设云端固件升级管理平台：WiFi 模组透传 Modbus 升级协议，云端通过 MQTT 对现场 BMS 做单台或批量远程升级，并按客户、项目管理设备和固件版本。
- 项目时间
- 2024-09 至 2024-11
- 项目周期
- 约 2 个月，含现场联调
- 交付团队
- 项目组
真实交付项目。客户名称已隐去；为保护客户数据，界面图按项目实际功能重绘，数值均为演示数据，设备编号、坐标和服务器信息不公开。
储能 BMS 远程固件升级平台 · 界面示意图
01 / 05
系统架构PC 后台
WiFi 模组透传 Modbus 升级帧，云端通过 Ctrl / reply 两个 MQTT 主题与每台设备一问一答。
- 升级链路
- WiFi + MQTT
- 设备协议
- Modbus RTU
- 升级方式
- 单台 / 批量
- 分片大小
- 1 KB
项目背景
项目背景与挑战
设备已经能用上位机通过串口升级，但每次都要工程师到现场。BMS 本身只认 Modbus 寄存器协议，联网靠 WiFi 模组，模组只负责收发；升级包要拆成 1KB 分片逐帧写入，现场信号不稳时单帧超时很常见，失败了还要能说清楚停在哪一帧。
适合已有串口升级流程、想把现场升级搬到云端的 BMS、PCS、储能柜和其他带 MCU 的设备厂商参考。
怎么做的
解决方案
- 01沿用设备现有的 Modbus 升级寄存器定义，WiFi 模组只做透明通道：云端下发走 Ctrl 主题，设备应答走 reply 主题，每台模组按序列号独立一组主题
- 02FastAPI 升级服务按「查询版本 → 写入升级请求 → 1KB 分片传输 → 写入完成」执行，每一步都等设备应答再继续
- 03单帧超时自动重试，累计失败分片超过上限即中止并记录原因，避免设备停在半升级状态还不被发现
- 04Vue 3 管理后台支持单台和批量升级，进度条和逐行升级日志实时刷新，升级完成后自动回读版本号
- 05客户、项目、设备、固件版本都记录创建用户，不同账号之间数据隔离；另提供远程重置设备参数和审计日志
技术栈
- Python
- FastAPI
- Vue 3
- Naive UI
- MQTT
- Modbus RTU
- Docker
项目亮点
- WiFi 模组透传 Modbus 升级协议
- 单台 / 批量远程升级
- 分片重试与失败中止，日志可追溯
- 客户 / 项目 / 固件版本分权管理
适合参考的项目
- 设备已有串口升级能力，希望改成远程升级的储能、电源和工业设备厂商
- 设备通过 WiFi / 4G 模组透传串口协议上云的项目
- 需要按客户、项目管理固件版本和升级记录的团队
交付时要重点关注
- 升级协议先在本地串口跑通，再接 MQTT，两边用同一份帧格式定义。
- 超时、重试和中止条件要在联调时用弱信号环境反复验证。
- 升级完成后必须回读版本号，确认设备真的跑在新固件上。
做类似项目，建议先准备这些资料
- 设备现有的升级协议（寄存器地址、帧格式、应答格式）和一台可联调样机
- 联网方式：WiFi、4G 还是以太网，模组能否做串口透传
- 固件包大小、分片大小和设备侧对超时的容忍度
- 是否需要批量升级、按客户 / 项目分权，是否要保留升级日志
FAQ
关于这个项目的常见问题
设备只支持串口升级，能改成远程升级吗？+
这个项目就是这种情况。只要联网模组能做串口透传，云端可以把原有的升级帧装进 MQTT 下发，设备侧固件基本不用改。需要先拿到现有升级协议和样机做本地联调。
远程升级到一半断网了怎么办？+
每个分片都要等设备应答，超时会自动重试；累计失败超过上限就中止并记录停在第几帧。设备侧需要有 Bootloader 保底，下次可以重新发起升级。
能不能一次给一批设备升级？+
可以。后台勾选多台设备即可批量升级，每台设备独立执行、独立记录日志，某一台失败不影响其他设备。
项目咨询
想做类似「储能 BMS 远程固件升级平台」的项目？
把设备类型、协议资料、样机状态和计划上线时间发过来，我们会对照这个项目的做法，给你首期范围、报价区间和推进顺序建议。
如果你暂时不方便填写完整信息，也可以直接前往 联系页面 获取电话、邮箱与微信方式。
提交项目需求
适用于 储能 BMS 远程固件升级平台 场景，提交后默认进入业务咨询通道。