3. 能源监控数据采集与通信协议
SCADA能源监控系统的数据采集层，本质上是把现场设备的状态量、模拟量、电能量和事件记录，通过不同协议搬运到前置采集服务器，再交给实时库与历史库。协议选型一旦确定，运维人员面对的就是四类典型协议族：Modbus、IEC 60870-5-101/104、DNP3和IEC 61850。它们不是简单的“能通就行”，而是各自有明确的链路模型、地址空间、时间戳机制和异常语义。理解这些差异，才能在现场判断“是设备没发、通道丢了、还是主站解析错了”。
四类协议的链路与数据模型差异
Modbus是最轻量的请求/响应协议，常见于电表、温控器、逆变器和PLC。它没有标准的信息模型，只有线圈、离散输入、输入寄存器、保持寄存器四类地址空间，寄存器含义完全由设备厂商的点表定义。运维时最常遇到的是“地址偏移”问题：设备手册写40001，实际报文里功能码03的起始地址是0，主站点表若填40001就会整体错位。因此Modbus排障第一步永远是核对功能码、起始地址、寄存器数量和字节序。
IEC 60870-5-101是串行链路，104是其TCP/IP映射版本，广泛用于变电站与调度主站之间。101/104有明确的应用服务数据单元类型标识，如单点遥信、双点遥信、归一化测量值、标度化测量值、短浮点测量值，以及总召唤、时钟同步、遥控等。104默认端口2404，采用APCI+ASDU结构。运维要点在于：总召唤是否成功、公共地址与信息对象地址是否匹配、传送原因是否正确、时标是CP24Time2a还是CP56Time2a。
DNP3在北美和水利、油气行业常见，采用主从轮询加事件缓冲机制。它支持类0静态数据、类1/2/3事件数据，以及完整性轮询、事件轮询、时钟同步、冷/热重启。DNP3的运维重点是事件缓冲区是否溢出、类1/2/3事件是否被正确确认、链路层确认与CRC校验是否正常。若主站只做完整性轮询而不做事件轮询，现场变化将无法及时上送。
IEC 61850面向变电站自动化，采用MMS、GOOSE、SV报文，强调面向对象的信息模型，如逻辑设备、逻辑节点、数据对象、数据属性。运维中常接触的是ICD/SCD文件、GOOSE订阅关系、SV采样值通道、报告控制块和数据集。与前三者不同，61850的“点”不是寄存器地址，而是带语义的路径，如IED1/LLN0$GO$gcb01。配置错误往往表现为GOOSE断链、SV失步或报告控制块未使能。
运维要点：从“通不通”到“准不准”
协议运维不能停留在“Ping得通、端口开着”。以IEC 104为例，链路建立后主站会发总召唤，若子站返回的ASDU中公共地址与主站点表不一致，主站会丢弃全部数据，表现为“链路正常但无数据”。此时应抓包查看STARTDT、总召唤激活、总召唤确认、总召唤结束的完整交互，确认传送原因是否为激活、信息对象地址是否落在点表范围内。若总召唤成功但个别遥测不刷新，则要检查该点的类型标识是否与主站定义一致，例如子站送归一化值而主站按短浮点解析，数值会明显异常。
Modbus的典型故障是“部分点错位”。假设某电表点表定义40001为A相电压、40002为B相电压，主站却从40002开始读，则A相电压会显示为B相电压，B相显示为C相，最后一相显示为无效值。排查时用Modbus Poll或抓包工具读取功能码03、起始地址0、数量3，对比原始寄存器值与主站显示值，即可定位偏移。字节序问题则表现为数值放大或缩小256倍，例如浮点数高低字颠倒。
DNP3的运维要特别关注事件缓冲。若主站只配置完整性轮询，子站事件缓冲区会逐渐填满，最终溢出并丢失早期事件。正确做法是同时配置类1/2/3事件轮询，并在主站确认后清除事件。若发现事件时标跳变或重复上送，应检查主从时钟同步和事件确认机制。链路层CRC错误较多时，优先检查串口参数、屏蔽接地和波特率，而不是反复重启主站。
IEC 61850的运维更偏向配置一致性。SCD文件是全站配置的唯一依据，若IED实际ICD与SCD不一致，会出现GOOSE订阅失败、报告控制块无法使能。GOOSE断链通常表现为订阅端收不到心跳，应检查APPID、目的MAC、VLAN优先级和GOOSE控制块路径。SV采样值异常则要检查采样率、通道映射和同步对时。与101/104不同，61850的“点”是带语义的路径，修改点表必须同步更新SCD并重新下装，不能只改主站数据库。
协议选择与现场配合
四类协议并非互斥。一个能源监控系统可能同时存在：电表走Modbus RTU接入串口服务器，变电站保护测控走IEC 61850 MMS，调度通道走IEC 104，水厂泵站走DNP3。运维人员应建立“协议—通道—点表—设备”四维台账，记录每个通道的协议类型、端口、公共地址/从站号、点表版本和最近一次总召唤时间。当数据异常时，先判断是单点、单设备还是整条通道，再按物理层、协议层、点表层、应用层逐级排查。
可直接使用的通道巡检记录示例
| 通道名称 | 协议 | 关键参数 | 巡检项 | 正常判据 |
|---|---|---|---|---|
| 1#电表 | Modbus RTU | 从站号1，9600-8-N-1 | 功能码03读取电压电流 | 寄存器值与实测一致，无超时 |
| 升压站104 | IEC 104 | IP 10.10.1.5，端口2404，公共地址1 | 总召唤、时钟同步、遥测刷新 | 总召唤结束，遥测5秒内刷新 |
| 泵站DNP3 | DNP3 TCP | 主站10.10.2.10，从站10，端口20000 | 类0/1/2/3轮询，事件确认 | 事件缓冲区无溢出，时标正确 |
| 保护测控61850 | MMS/GOOSE | IED名PCS-01，GOOSE APPID 0x3001 | 报告控制块使能，GOOSE订阅 | GOOSE心跳正常，报告无断链 |
把上述巡检项固化为日常任务，配合抓包和点表比对，就能在数据异常时快速区分“设备侧未发”“通道侧丢失”“主站侧解析错误”三类问题。协议本身不复杂，复杂的是现场参数、点表版本和配置一致性。运维的核心不是记住所有报文格式，而是建立可核对的参数台账和可复现的排查路径。