去年 5 月，我们在苏南跑一个 20MW 的分布式项目，资产方要求实现秒级监控。当时施工方为了省事，还是按地面站那套逻辑，在现场塞了个工业 PC 装本地 SCADA。结果上线不到一周，运维群里的告警就炸了：网络稍微一抖动，本地数据库就断连，云端看数据全是断档。这种“重本地、轻云端”的土办法，在分布式光伏爆发的今天，简直是运维人员的噩梦。
工商业光伏的痛点很直接：电站散、环境杂、没专人看守。如果你还在用那种基于 Windows 的组态软件或者简易透传模块，基本就离“工单地狱”不远了。我们要聊的不是那种漂亮的演示 Demo，而是如何在 100 个甚至 500 个屋顶电站并存的复杂环境下，搭一套真正能跑、能报警、能算账的 SCADA 架构。
本文想说透一个事：在分布式场景下，SCADA 的重心必须从“本地采集”转向“云边协同”。
一、 为什么传统的本地 SCADA 在分布式场景必死无疑
在集中式地面站，我们有专门的中控室，有光纤环网，本地 SCADA 跑得稳如老狗。但在工商业屋顶，环境完全变了。我们总结过三个过不去的坎：
- 硬件可靠性与维护成本：工控机在高温、灰尘大的厂房环境下，风扇坏了或硬盘损毁是常有的事。一旦本地 SCADA 挂了，数据就面临丢失风险。你总不能为了修个软件，专门开 200 公里车去现场重启电脑吧？
- 协议转换的“黑盒”问题：厂家 A 的逆变器用 Modbus RTU，厂家 B 的电表走 DL/T 645。传统本地 SCADA 往往只能做简单的协议透传，一旦涉及到逻辑计算（比如计算综合能效），本地计算资源很快就会见底。
- 多电站并行的横向扩展性：当你管 1 个站时，本地 SCADA 挺好用；当你管 50 个站时，你需要在 50 个屏幕间切换。这种碎片化的数据，根本没法做集团化的资产管理。
下表是我们对比的两种架构模式：
| 维度 | 传统本地 SCADA | 现代云边协同架构 |
|---|---|---|
| 采集终端 | 工业 PC / 简易串口服务器 | 边缘计算网关 (Linux/ARM) |
| 数据存储 | 本地 SQL Server / 文件存储 | 云端时序数据库 (InfluxDB/TDengine) |
| 协议解析 | 强依赖本地配置，灵活性差 | 边缘端动态解析 + 云端归一化 |
| 断网补传 | 基本无或依赖手动拷贝 | 具备本地缓存，支持自动断点续传 |
| 运维成本 | 极高，需频繁下站 | 极低，支持远程配置与 OTA |
二、 边缘计算网关：不止是“搬运工”，更是“清洁工”
很多人觉得网关就是个 Modbus 转 MQTT 的盒子。这种理解在 5MW 以下的小电站可能勉强够用，但在大型工商业项目中，边缘网关必须承担起“数据清洗”的重任。
1. 协议归一化 (Normalization)
不同品牌的逆变器，同样是读“当前功率”，寄存器地址一个是 0x3000，一个是 0x7001；一个是 16 位整数，一个是 32 位浮点。如果在云端去适配这些差异，后端代码会写得极其恶心。我们的做法是在边缘端就把数据“洗白”成统一的 JSON 格式。
{"timestamp":1684567890000,"device_id":"INV-SH-001","data":{"active_power":50.5,"daily_energy":120.2,"dc_voltage":[650.2,652.1,648.5],"status":"NORMAL"}}2. 本地缓存与断点续传逻辑
工商业场景的 4G 网络极不稳定。我们要求网关必须具备至少 72 小时的本地存储能力。逻辑是这样的：网关内部维护一个消息队列，每发送成功一条数据，标记位移动；如果发送失败（收到非 200 响应或超时），数据就留在本地 SQLite 或 LevelDB 中。等网络恢复，立即以双倍速“追赶”进度。这一步做不好，你的发电量报表永远对不上账。
三、 云端架构：支撑百兆级实时并发的后端设计
当 500 个电站的网关同时往云端塞数据时，传统的 CRUD 架构肯定会崩。我们去年在处理一个华东区域 150MW 分布式资产包时，后端选型直接绕开了关系型数据库。
1. 接入层：MQTT Broker 才是王道
不要试图用 HTTP 接口去接海量设备。MQTT 的长连接机制和极低的报头开销，是光伏 SCADA 的基础。我们通常建议在接入层加一层 Kafka 缓冲。网关 -> MQTT -> Kafka -> 消费端。这样即使后端数据库在做索引优化或者临时宕机，数据也不会丢，全在 Kafka 队列里排队。
2. 存储层：为什么我们选择时序数据库
光伏数据是典型的时间序列数据，而且读写比极其悬殊（写多读少）。用 MySQL 存 1 分钟间隔的 50 台逆变器数据，跑三个月查询就卡死了。我们目前主流的方案是 TDengine 或者 InfluxDB。在 100MW 级规模下，时序数据库的压缩比能达到 10:1 甚至更高，这直接决定了你的服务器账单是每月 500 元还是 5000 元。
3. 多租户隔离机制
工商业光伏往往涉及 EPC、运维方、业主方三方看数。架构上必须从底层的tenant_id开始隔离。这不只是 UI 上的权限控制，更涉及到 API 限流。比如某个 EPC 写的脚本疯狂调用接口拉数据，不能让他的行为把整个云平台的资源占满，导致其他业主的告警发不出来。
四、 我们的取舍与踩坑复盘
在实际落地过程中，我们发现最难的不是技术选型，而是对“实时性”的克制。很多甲方老板一上来就要求“秒级刷新”，觉得屏幕上的功率曲线得像心电图一样跳动才叫 SCADA。
实操过 30+ 厂商 API 后，我们发现 1 秒采集一次不仅会给网关带来巨大压力，还会导致逆变器通讯口的 485 芯片频繁过热复位。最后我们采取了折中方案：
- 核心告警（如直流拉弧、停机）：边缘端主动推，延时控制在 3 秒内。
- 运行数据（如电压、电流）：15-30 秒频率采集，云端做 5 分钟聚合。
为了解决多品牌逆变器接入的繁琐，我们团队内部把这套“网关管理+协议映射+数据归一”的逻辑抽象出来，做成了一个中间件，内部叫 ZenovaConnect。它的作用就是让我们的架构师不用再去翻那些厚厚的 Modbus 手册，直接通过配置化的方式把华为、阳光、古瑞瓦特这些厂商的数据统一成一套标准的 API 推给上层监控平台。这层中间件替我们扛住了不同厂商接口变动和限流的坑，让我们能把精力放在更高价值的电站能效分析上。
五、 结尾的话
分布式光伏的 SCADA 系统，本质上是一场关于“数据可靠性”的持久战。从笨重的本地工控机转向轻量化的边缘计算，再到高并发的云端时序存储，这不仅是硬件的更替，更是架构思维的降维打击。
如果你还在为现场网关频繁掉线而苦恼，或者为多品牌数据的解析忙得焦头烂额，不妨反思一下：你的架构是在“堆人头”维护，还是在靠“协同”自动运行？
一个开放式的问题留给大家：在你的运维经验中，断网期间的发电量数据丢失，通常是怎么补救的？欢迎在评论区交流避雷心得。
了解 ZenovaConnect 完整方案。
