4. 智能终端与边缘计算：RTU/DTU/边缘网关在需求响应中的应用
各位同行，今天我们来聊聊需求响应中最接地气的一环——智能终端。说白了，就是那些挂在现场、装在柜子里、贴在设备上的小盒子。我做了十几年电力系统，见过太多“上层规划完美，底层执行拉胯”的项目。问题出在哪？往往就出在这些不起眼的终端上。
需求响应这件事，核心就三个字：采、传、控。采集数据，传输指令，控制设备。而RTU、DTU、边缘网关，就是干这三件事的主力军。很多人分不清它们，我刚开始也犯过糊涂。今天咱们一次讲透。
4.1 RTU：老将出马，一个顶俩
RTU，远程终端单元。这玩意儿在电力系统里摸爬滚打了几十年。我2015年在西北做一个光伏电站的AGC/AVC改造，现场用的就是老款RTU。那东西皮实，零下20度照样干活，就是配置起来麻烦点。
RTU的核心能力：
- 遥测（YC）：采集电压、电流、功率、频率等模拟量。精度一般0.5级，够用。
- 遥信（YX）：采集开关状态、保护动作等数字量。说白了就是“开”或“关”。
- 遥控（YK）：下发指令，控制断路器、负荷开关投切。
- 遥调（YT）：调节变压器分接头、无功补偿装置等。
需求响应中的典型应用：
RTU直接挂在用户进线柜上，实时采集总负荷。当调度下发“压降5%负荷”的指令时，RTU根据预设策略，自动切除可中断负荷回路。整个过程秒级响应，不需要人干预。
我的经验：RTU的通信协议是个坑。很多老旧RTU只支持IEC 101/104，新平台只认Modbus TCP。我建议在选型时，优先选支持多协议、可远程升级的型号。否则后期改协议，现场跑断腿。
4.2 DTU：通信小能手，专治各种“连不上”
DTU，数据传输单元。它和RTU最大的区别是什么？RTU是“采集+控制”一体，DTU主要干一件事——传数据。它就是个通信猫，把串口数据（RS232/485）转成IP数据，通过4G/5G或者以太网发出去。
我记得2018年做一个工业园区需求响应项目，现场有几十个电表，全是RS485接口。主站平台在云端，距离现场几十公里。怎么办？每个电表配一个DTU，插上4G卡，数据直接上云。简单粗暴，但有效。
DTU的选型要点：
| 参数 | 说明 | 我的建议 |
|---|---|---|
| 通信方式 | 4G/5G/NB-IoT/以太网 | 优先选4G+以太网双模，有备无患 |
| 协议支持 | Modbus RTU/TCP, DLT645, IEC104 | 至少支持Modbus和DLT645，这是电表标配 |
| 数据缓存 | 断网时本地存储，恢复后补传 | 必须有！我吃过断网丢数据的亏 |
| 电源 | DC 12-48V宽压输入 | 现场电源环境复杂，宽压是刚需 |
避坑指南：我曾经在一个项目里用了某品牌的廉价DTU，结果一到夏天高温就死机。后来拆开一看，散热片都没贴牢。记住：工业级温度范围（-40℃~85℃）是底线，不是加分项。
4.3 边缘网关：把“脑子”放到现场去
边缘网关是这几年最火的概念。它和RTU/DTU最大的区别是什么？边缘网关能“算”。它不只是采数据、传数据，它能在本地做决策、跑算法、执行策略。
你想想看，传统模式是：现场采集→传到云端→云端计算→下发指令。这一圈下来，延迟至少几百毫秒到几秒。对于需求响应来说，有时候要的是毫秒级响应。比如储能逆变器的功率调节，延迟超过100ms，效果就大打折扣。
边缘网关在需求响应中的三大角色：
- 数据预处理：把原始电表数据做滤波、去重、聚合，只上传有效信息。我见过一个项目，每天上传几GB的原始数据，平台根本处理不过来。加了边缘网关后，数据量降到原来的1/10。
- 本地策略执行：网关里预置需求响应策略。比如“当总负荷超过变压器容量80%时，自动切除第3、5、7路非重要负荷”。即使和主站通信中断，本地策略照样执行。
- 协议转换与设备管理：一个网关可以对接多种设备——电表、逆变器、空调控制器、充电桩。统一转换成标准格式上报。我习惯用MQTT+JSON，轻量又好解析。
核心逻辑图：边缘网关在需求响应中的位置
图：边缘网关在需求响应中的三层架构
4.4 实战对比：什么时候该用谁？
很多朋友问我：“我到底该用RTU、DTU还是边缘网关？”我的回答是：看场景，别跟风。
| 场景 | 推荐设备 | 理由 |
|---|---|---|
| 变电站/配电房，需要采集多路模拟量+控制开关 | RTU | 成熟稳定，IO点数多，支持多种规约 |
| 分散的电表/传感器，只需要把数据传回平台 | DTU | 成本低，部署快，即插即用 |
| 储能站/微电网，需要本地快速响应和策略执行 | 边缘网关 | 算力强，延迟低，支持自定义逻辑 |
| 既有RTU/DTU，又想增加本地决策能力 | 边缘网关+原有设备 | 不改动现有设备，网关做上层协调 |
我的习惯：在需求响应项目中，我倾向于边缘网关+DTU的组合。网关负责策略和协议转换，DTU负责和底层设备通信。这样分工明确，出了问题也好排查。记住：不要把鸡蛋放在一个篮子里。
4.5 代码示例：边缘网关上的一个简单需求响应策略
下面是一个用Python写的边缘网关策略示例。逻辑很简单：当总负荷超过阈值时，按优先级切除负荷。
# 边缘网关需求响应策略示例
# 运行环境：OpenWrt / Linux 边缘网关
import time
import json
import paho.mqtt.client as mqtt
# 配置参数
LOAD_THRESHOLD = 800 # 负荷阈值，单位kW
PRIORITY_ORDER = [5, 3, 1, 2, 4] # 负荷回路编号，按切除优先级排序
# 当前负荷状态
current_load = 0
load_status = {1: True, 2: True, 3: True, 4: True, 5: True} # True=运行
def on_message(client, userdata, msg):
"""处理来自主站或本地采集的数据"""
global current_load
data = json.loads(msg.payload)
if 'total_load' in data:
current_load = data['total_load']
check_and_control()
def check_and_control():
"""检查负荷并执行控制"""
if current_load > LOAD_THRESHOLD:
# 需要切除负荷
for circuit in PRIORITY_ORDER:
if load_status[circuit]:
print(f"切除负荷回路 {circuit}，当前负荷 {current_load}kW")
# 实际执行：通过Modbus写线圈
# modbus_client.write_single_coil(circuit, False)
load_status[circuit] = False
current_load -= 50 # 假设每路50kW
if current_load <= LOAD_THRESHOLD:
break
elif current_load < LOAD_THRESHOLD * 0.7:
# 负荷低于阈值70%，尝试恢复
for circuit in reversed(PRIORITY_ORDER):
if not load_status[circuit]:
print(f"恢复负荷回路 {circuit}")
# modbus_client.write_single_coil(circuit, True)
load_status[circuit] = True
break
# MQTT连接
client = mqtt.Client()
client.on_message = on_message
client.connect("192.168.1.100", 1883, 60)
client.subscribe("site/load/data")
print("边缘网关需求响应策略已启动...")
client.loop_forever()注意：实际部署时，一定要加防抖逻辑和手动/自动切换。我曾经见过一个策略，因为负荷波动频繁，导致断路器一小时内动作了20多次。嗯，那哥们后来被运维骂惨了。
4.6 总结：选型三原则
说了这么多，最后给大家三个原则，记牢了：
- 可靠性优先：现场环境恶劣，温度、湿度、电磁干扰都是杀手。选工业级产品，别省那几百块钱。
- 通信要冗余：主通信断了，备用通信要顶上。我习惯用4G主+以太网备，或者反之。
- 本地要有“脑子”：哪怕主站瘫痪，边缘设备也能独立运行。这是需求响应系统的基本素养。
好了，关于智能终端和边缘计算，今天就聊到这儿。这些东西看着不起眼，但往往是项目成败的关键。下次你们在现场调试，遇到终端通信不上、策略不执行的时候，想想今天讲的这些，或许能少走些弯路。
公众号:蓝海资料掘金营，微信deep3321