3. 储能站设备通信需求分析

储能站的通信集成不是“把设备接上网”这么简单。站内至少存在四类通信主体：电池管理系统（BMS）、储能变流器（PCS）、能量管理系统（EMS），以及消防、空调、动环等辅助系统。它们的数据密度、实时性要求、接口形态和协议能力差异很大。通信需求分析的目标，是在动手配置之前，先把“谁和谁通、通什么、怎么通、通多快、断了怎么办”这五个问题落到可核对的清单上。

一、先分清四类设备的数据角色

BMS 是站内数据量最大、层级最深的设备。它通常按“电池簇—电池模组—单体”三级组织数据，需要上传的信息包括：簇电压、簇电流、SOC、SOH、最高/最低单体电压及其位置、最高/最低温度及其位置、绝缘电阻、接触器状态、告警与保护状态等。一个 1MW/2MWh 的储能单元，若由 8 个电池簇组成，每簇 20 个模组、每模组 16 个单体，则单体级测点约 2560 个。实际工程中不会把所有单体电压都直接送 EMS，而是由 BMS 内部聚合后，只上传簇级汇总值和极值，单体级数据留给本地监控或按需召唤。

PCS 的数据量小但实时性要求最高。核心测点包括：直流侧电压/电流/功率、交流侧三相电压/电流/频率/功率因数、有功/无功指令与反馈、运行状态（待机、充电、放电、故障）、故障码、温度等。PCS 的有功调节响应通常在百毫秒级，因此 EMS 对 PCS 的遥调指令和遥测回读周期一般要求 ≤1s，部分一次调频场景要求 ≤100ms。

EMS 是通信的汇聚点。它向下采集 BMS、PCS 和辅助系统，向上对接调度或云平台。EMS 本身不产生一次数据，但决定数据如何组织、存储和转发。需求分析时要明确 EMS 的采集周期、转发协议（如 IEC 104、MQTT）、转发点表和本地历史存储深度。

消防与空调等辅助系统常被低估。消防主机通常提供干接点或 RS485，数据点包括火警、故障、联动状态、气体泄漏报警；空调系统提供运行状态、回风温度、设定温度、故障码。这些点数量少，但参与站级联锁，必须确认接口类型和故障时的默认状态。

二、通信接口确认：从物理层到应用层

接口确认要逐层落实。物理层先看接口形态：BMS 常见 RS485 或 CAN，PCS 常见 RS485 或以太网，消防主机多为 RS485 或干接点，空调可能提供 RS485 或 SNMP。RS485 要确认波特率（如 9600/19200/115200）、数据位、停止位、校验方式，以及是否与其他设备共用总线。以太网要确认 IP 地址、子网掩码、网关、端口号，以及是否支持 Modbus TCP 多客户端连接。

应用层要确认协议版本和寄存器映射。以 Modbus 为例，必须拿到设备厂商的通信点表，逐点核对：寄存器地址（0x/1x/3x/4x 区）、数据类型（UINT16、INT16、UINT32、FLOAT32）、字节序（大端/小端/字交换）、缩放因子（如 0.1、0.01）、读写权限。很多现场通信失败不是接线问题，而是点表地址偏移了一位，或 FLOAT32 的高低字顺序与 EMS 默认设置相反。

下面是一份可直接用于现场核对的通信接口确认表示例，覆盖四类设备的关键字段：

三、数据点表梳理的实操方法

点表梳理不是把厂商点表原样复制，而是按 EMS 的数据模型重新组织。建议按“设备—功能组—测点”三级归类。以 PCS 为例，功能组可分为：交流侧遥测、直流侧遥测、状态遥信、指令遥调、故障告警。每个测点记录：点名、点号、寄存器地址、数据类型、缩放因子、单位、读写属性、采集周期、是否转发、转发点号。

实操中有一个容易忽略的环节：确认“无效值”和“默认值”。例如 BMS 在通信中断时，SOC 应保持最后一次有效值还是置为无效？PCS 在收到无效指令时是保持当前功率还是降为零？消防系统在通信正常但无火警时，干接点应处于常闭还是常开？这些必须在点表中明确标注，否则 EMS 的告警逻辑和联锁逻辑无法正确设计。

四、需求分析的输出物

完成上述分析后，应形成三份可交付文件：第一份是《设备通信接口确认表》，记录每台设备的物理接口、协议、参数和连接方式；第二份是《站级数据点表》，按统一格式列出所有采集和转发测点；第三份是《通信异常处理约定》，明确超时时间、重试次数、断线告警阈值和故障默认值。这三份文件是后续 Modbus 配置、EMS 组态和联调测试的直接输入，也是验收时判断通信集成是否完整的依据。

需要强调的是，需求分析阶段多花一天核对点表，联调阶段可能少花三天排查问题。尤其是字节序、缩放因子和无效值这三类细节，一旦在点表中写错，现场表现往往是“数据能读到但数值不对”或“告警不触发”，排查成本远高于前期确认。