2. 数据采集与监控（SCADA）：遥测遥信原理、RTU/FTU通信协议（IEC 104/Modbus）、数据质量码处理
各位同学，咱们今天聊聊SCADA。说实话，这是EMS系统里最接地气、也最容易出幺蛾子的部分。你想想看，调度员在屏幕上看到的每一个数据，背后都经历了一段不简单的旅程。我做了十几年电力系统，见过太多因为数据采集出问题导致的误判——嗯，咱们今天就把这块彻底讲透。
2.1 遥测与遥信：SCADA的两大基石
遥测和遥信，说白了就是SCADA系统从现场设备那里“听”回来的两种信息。
- 遥测（Telemetry）：采集模拟量。比如电压、电流、有功功率、无功功率、频率、温度等。这些是连续变化的数值。
- 遥信（Teleindication）：采集状态量。比如断路器的分/合位、隔离开关的状态、保护动作信号、告警信号等。这些是离散的0或1。
我个人习惯把遥测比作“血压计”，遥信比作“心跳监测仪”。一个告诉你数值，一个告诉你状态。两者缺一不可。
核心要点：遥测数据是连续值，需要经过模数转换（ADC）和标度变换；遥信数据是离散值，需要防抖处理（去抖动时间通常设为20-50ms）。
2.2 RTU与FTU：现场的数据“哨兵”
RTU（远程终端单元）和FTU（馈线终端单元）是部署在变电站或线路上的智能设备。它们负责采集现场数据，并转发给主站。
| 设备类型 | 典型部署位置 | 主要功能 | 通信特点 |
|---|---|---|---|
| RTU | 变电站、发电厂 | 遥测、遥信、遥控、遥调 | 通道多、数据量大、可靠性要求高 |
| FTU | 配电线路、柱上开关 | 遥测、遥信、遥控（故障隔离） | 环境恶劣、供电受限、通信距离远 |
我记得有一次在西北某风电场调试，FTU装在户外柱上，冬天零下30度，设备频繁死机。后来发现是电源模块低温性能不达标——嗯，选型时一定要看工作温度范围，别只看参数表。
2.3 通信协议：IEC 104 vs Modbus
通信协议是SCADA系统的“语言”。目前国内电力系统最主流的就是IEC 60870-5-104（简称IEC 104）和Modbus。
2.3.1 IEC 104：电力系统的“普通话”
IEC 104是基于TCP/IP的网络协议，广泛应用于变电站和调度主站之间的通信。它的特点是：
- 面向连接：建立TCP连接后，通过启动帧（STARTDT）激活数据传输
- 数据分类清晰：遥测用M_ME_NA（归一化值）、M_ME_NB（标度化值）；遥信用M_SP_NA（单点遥信）、M_DP_NA（双点遥信）
- 具备传输确认机制：发送方需要等待接收方确认，否则会重发
你想想看，为什么电力系统偏爱IEC 104？因为它有完善的数据同步机制和时钟同步功能。我在项目中遇到过一个问题：主站和子站时钟偏差超过2秒，导致SOE（事件顺序记录）时间戳全部错乱。后来加了SNTP对时，问题才解决。
实战技巧：IEC 104的T0、T1、T2超时参数要合理设置。T0（连接超时）建议30秒，T1（发送/确认超时）建议15秒，T2（接收/确认超时）建议10秒。别设太短，网络抖动一下就会断链。
2.3.2 Modbus：工业界的“通用语”
Modbus协议简单、轻量，广泛应用于配电自动化、光伏逆变器、储能系统等场景。常见的有Modbus RTU（串口）和Modbus TCP（以太网）。
Modbus的核心是“寄存器”和“线圈”：
- 保持寄存器（Holding Register）：存放遥测数据，如电压、电流
- 线圈（Coil）：存放遥信状态，如开关分合
- 输入寄存器（Input Register）：只读的遥测数据
- 离散输入（Discrete Input）：只读的遥信状态
// Modbus RTU读取遥测数据示例（C语言伪代码）
uint16_t read_holding_register(uint8_t slave_id, uint16_t reg_addr) {
uint8_t request[8];
request[0] = slave_id; // 从站地址
request[1] = 0x03; // 功能码：读保持寄存器
request[2] = (reg_addr >> 8) & 0xFF; // 寄存器地址高字节
request[3] = reg_addr & 0xFF; // 寄存器地址低字节
request[4] = 0x00; // 读取数量高字节
request[5] = 0x01; // 读取数量低字节（读1个寄存器）
// CRC16校验（略）
// 发送request，接收response，解析数据
return (response[3] << 8) | response[4];
}Modbus有个坑：它没有数据质量码。你读到一个数值，不知道它是正常值还是无效值。所以我在项目中通常会在应用层加一个“心跳”寄存器，如果心跳停止更新超过3个周期，就判定数据无效。
注意：Modbus RTU的CRC校验不能省略！我曾经见过一个项目，因为CRC校验代码写错了，导致误码率高达5%。现场查了三天，最后发现是CRC查表法表格生成有误——嗯，这种低级错误，咱们别犯。
2.4 数据质量码：数据的“体检报告”
数据质量码（Quality Code）是SCADA系统给每个数据打的标签。它告诉你这个数据是“健康”还是“生病”。
我习惯把数据质量码分为三级：
- 好数据（Good）：数据正常采集，无异常。可以直接用于调度决策。
- 可疑数据（Questionable）：数据超出合理范围、通信有短暂中断、或设备处于检修状态。需要人工确认。
- 坏数据（Bad）：通信中断、设备故障、数据超时未更新。不能用于任何计算。
在IEC 104协议中，数据质量码通常包含以下标志位：
| 标志位 | 含义 | 典型场景 |
|---|---|---|
| IV（Invalid） | 数据无效 | 设备掉电、通信中断 |
| NT（Not Topical） | 数据非当前值 | 数据缓存未刷新、历史数据 |
| SB（Substituted） | 数据被人工置入 | 调度员手动输入替代值 |
| BL（Blocked） | 数据被封锁 | 设备检修、信号屏蔽 |
我曾经在某个省调项目里，发现AGC（自动发电控制）系统频繁误调。查了三天，最后发现是某个遥测点的质量码被置为“SB”（人工置入），但调度员忘记取消置入标志了。AGC系统以为这个数据是真实的，结果按错误数据调节了机组出力——嗯，从那以后，我要求所有数据在进入AGC前必须检查质量码，IV和SB的数据一律不参与计算。
数据质量码处理原则：
- 好数据：直接使用
- 可疑数据：标记告警，人工确认后决定是否使用
- 坏数据：丢弃，使用上一帧有效数据或插值替代
- 所有数据在存入历史库时，必须保留原始质量码
2.5 知识体系总览
下面这张图，是我自己总结的SCADA数据采集与监控的核心逻辑。你把它理解了，整个章节就通了。
这张图从下往上看，就是数据从现场设备到EMS应用的完整链路。每一步都有坑，每一步都需要认真对待。我个人觉得，数据质量码处理是最容易被忽视、但影响最大的环节——你想想看，一个坏数据进了AGC，后果有多严重？
我的建议：在开发SCADA数据采集模块时，先把数据质量码处理逻辑写好，再写业务逻辑。顺序别搞反了。数据质量是1，业务逻辑是后面的0——没有1，再多的0也没用。
公众号:蓝海资料掘金营，微信deep3321