2. 储能系统架构：BMS、EMS、PCS与云平台的通信需求
聊到储能监控，很多人一上来就盯着MQTT协议本身看。但我个人的习惯是——先搞清楚你要跟谁说话，再说怎么说话。
储能系统里，核心的四个角色分别是：BMS（电池管理系统）、EMS（能量管理系统）、PCS（储能变流器），以及上层的云平台。它们之间的通信需求，说白了就是“谁该知道什么，什么时候知道，知道了要干嘛”。
我在项目里见过不少踩坑的案例，就是因为没理清这几个角色的通信边界，结果数据满天飞，该快的慢，该准的乱。嗯，咱们今天就把这个架构捋清楚。
2.1 四个核心角色的定位
先简单过一遍每个角色的职责，这样后面聊通信需求时你才能理解为什么有的数据要高频上报，有的却可以慢慢来。
| 角色 | 核心职责 | 典型数据量级 |
|---|---|---|
| BMS | 监控电池单体电压、温度、SOC、SOH，保护电池安全 | 高（每节电芯都要上报） |
| PCS | 控制充放电功率，实现AC/DC变换 | 中（功率、电流、电压、状态） |
| EMS | 制定充放电策略，协调BMS与PCS，做能量调度 | 中（策略指令、汇总数据） |
| 云平台 | 远程监控、数据分析、告警、OTA升级 | 低（聚合后的关键数据） |
你想想看，BMS是离电池最近的，它每秒都在跟电芯打交道。PCS是执行者，它听EMS的指令干活。EMS是大脑，它要同时看BMS的脸色和PCS的反馈。云平台呢？它不需要知道每一节电芯的实时电压，它只需要知道“这个电池簇健康吗？SOC多少？”就够了。
2.2 通信需求拆解：谁跟谁说话？
我习惯把通信链路分成三层：设备内总线、本地局域网、广域网。每一层的通信需求完全不同。
2.2.1 BMS ↔ PCS：硬实时，毫秒级
这是最关键的链路。BMS发现电池过温了，必须立刻告诉PCS“降功率”或者“停机”。
- 通信方式：CAN总线或RS485，Modbus RTU协议
- 实时性要求：< 100ms
- 数据内容：SOC、SOH、单体最高/最低电压、温度、故障码
- 典型问题：我曾经遇到过一个项目，BMS和PCS之间用了TCP/IP走交换机，结果网络抖动导致保护动作延迟了200ms，电池直接触发了过温告警。后来全部改回硬线CAN，问题解决。
2.2.2 BMS ↔ EMS：准实时，秒级
EMS需要知道电池的总体状态来做调度决策。它不需要每节电芯的毫秒级数据，但需要每1-5秒的聚合数据。
- 通信方式：以太网，Modbus TCP 或 MQTT
- 实时性要求：1-5秒
- 数据内容：总电压、总电流、SOC、SOH、充放电限值、告警状态
- 我的建议：如果EMS是本地部署的工控机，用Modbus TCP更稳定。如果EMS是边缘网关，MQTT更灵活，方便后续上云。
2.2.3 PCS ↔ EMS：控制闭环，百毫秒级
EMS给PCS下发功率指令，PCS执行后反馈实际功率。这是一个闭环控制链路。
- 通信方式：以太网，Modbus TCP 或 IEC 61850
- 实时性要求：100-500ms
- 数据内容：有功/无功功率指令、运行模式、并网/离网状态
- 避坑指南：我曾经见过一个项目，EMS和PCS之间用了Wi-Fi，结果信号干扰导致指令丢包，PCS一直按旧功率运行，差点造成电池过充。后来全部换成有线以太网，再也没出过问题。
2.2.4 本地设备 ↔ 云平台：非实时，分钟级
这是MQTT的主战场。云平台不需要知道每一秒的功率变化，它只需要知道“这个储能站在正常运行吗？今天发了多少电？”
- 通信方式：4G/5G/以太网，MQTT协议
- 实时性要求：1-5分钟（告警可提升到秒级）
- 数据内容：聚合后的运行数据、日发电量、告警事件、设备状态
- 为什么用MQTT？ 说白了，云平台要管理成百上千个储能站，MQTT的发布/订阅模型天然适合这种一对多的场景。而且MQTT的遗嘱消息（Last Will）能帮你及时发现设备离线——这个功能在储能监控里太重要了。
2.3 一张图看懂通信架构
下面这张图是我自己画的一个典型储能系统通信架构。你可以看到，不同层级用了不同的协议，各有各的用途。
2.4 MQTT在架构中的位置
看到这张图，你应该明白了——MQTT不是万能的。它最适合的场景是本地设备与云平台之间的通信，以及多个储能站与集中管理平台之间的数据汇聚。
我个人习惯把MQTT部署在EMS边缘网关这一层。网关向上连接云平台，向下通过Modbus或CAN跟BMS、PCS打交道。这样设计的好处是：
- 解耦：云平台不关心底层设备是什么协议，它只跟MQTT Broker打交道。
- 带宽友好：网关可以做数据聚合和压缩，只把关键数据推上云。我在一个项目中，原本每秒上报1000条电芯数据，云平台服务器直接扛不住。后来在网关里做了聚合，每分钟只上报30条聚合数据，服务器压力瞬间降下来。
- 离线缓存：网络断了怎么办？MQTT的离线消息机制可以帮你缓存数据，等网络恢复后再补发。这个功能在偏远地区的储能站特别实用。
2.5 通信需求总结
最后，我用一张表把四个角色的通信需求总结一下。你以后做架构设计时，直接对照这张表来选协议和参数就行。
| 通信链路 | 推荐协议 | 实时性 | 数据粒度 | MQTT是否适用 |
|---|---|---|---|---|
| BMS ↔ PCS | CAN / RS485 | < 100ms | 单体电芯 | ❌ 不适用 |
| BMS ↔ EMS | Modbus TCP / MQTT | 1-5s | 电池簇聚合 | ✅ 可选 |
| PCS ↔ EMS | Modbus TCP / IEC 61850 | 100-500ms | 功率指令 | ⚠️ 不推荐 |
| EMS ↔ 云平台 | MQTT | 1-5min | 聚合运行数据 | ✅ 强烈推荐 |
嗯，架构层面的通信需求就聊到这儿。你想想看，搞清楚了谁跟谁说话、用什么节奏说话，后面再聊MQTT的具体主题设计和QoS配置，就顺理成章了。
公众号:蓝海资料掘金营，微信deep3321