3. SCADA系统架构设计

SCADA能源管理平台的架构选型，本质上是在“可用性、实时性、成本、可维护性”四个约束之间做权衡。架构一旦定错，后期再补冗余或拆分分布式，代价往往远高于初期多花的两周设计时间。本节先给出四类典型架构的适用边界，再逐层拆解采集层、监控层、数据层、应用层的职责与接口，最后给出一份可直接用于方案评审的架构选型决策表。

一、四类架构的适用边界

单机架构：采集、监控、数据库、Web应用全部部署在一台工控机或服务器上。适用于测点规模小于5000点、站点数量不超过3个、允许停机窗口在4小时以内的场景，例如小型园区配电监控或单栋楼宇能耗采集。优点是部署快、成本低；缺点是单点故障即全站失能，且历史库与实时采集争抢同一台机器的CPU和磁盘IO。

冗余架构：通常指双机热备或双网冗余。双机热备采用主备两台服务器共享磁盘阵列或实时数据库同步，主节点故障时备节点在秒级接管。适用于测点5000～50000点、对连续运行要求高的场景，如化工厂能源站或数据中心配电。关键判断依据是：停机1小时造成的生产损失是否超过冗余硬件投入。冗余架构必须验证“切换后历史数据不丢、报警不重复推送”两个指标。

分布式架构：按地理区域或业务单元拆分多个采集站，每个站独立完成本地采集与监控，中心侧只做汇总展示与跨站分析。适用于多厂区、多楼层、跨地域的集团级能源管理，测点可达十万级以上。分布式架构的核心设计点是“本地自治”：即使中心网络中断，各站仍能独立运行并缓存数据，恢复后补传。

云边协同架构：边缘侧部署轻量采集网关或边缘服务器，完成协议解析、数据清洗、断网缓存和本地联动控制；云端部署数据层与应用层，完成海量存储、AI分析和多租户展示。适用于站点分散、无固定机房、需要远程运维的场景，如分布式光伏电站群或连锁商业体。云边协同必须明确“哪些逻辑留在边缘、哪些上云”，否则会出现控制延迟或云端依赖过重的问题。

二、四层职责的边界与接口

采集层的职责只有三件事：把现场设备的物理信号或协议报文读上来、做必要的量纲换算与质量码标注、按统一格式向上转发。采集层不应承担业务计算，例如“计算某车间单位产品能耗”不属于采集层。采集层的典型参数包括：轮询周期（电表通常1～5秒，温湿度可放宽到30秒）、超时重试次数（建议2次）、断线缓存时长（边缘侧至少缓存4小时）。接口上，采集层向监控层提供的是“带时标和质量码的测点值”，质量码至少区分“正常、可疑、无效、超时”四种。

监控层负责实时画面的刷新、报警的生成与确认、以及本地控制指令的下发。监控层与采集层的边界在于：监控层不直接读设备寄存器，只消费采集层提供的测点值。监控层的关键设计点是报警抑制与分级：例如同一台变压器的高温报警，在5分钟内只推送一次，且按“预警、报警、跳闸”三级分别对应不同的通知渠道。监控层向数据层写入的是“变化数据”而非全量数据，以降低存储压力。

数据层是架构中最容易被低估的一层。它需要同时支撑三类负载：实时库支撑画面秒级刷新，历史库支撑趋势查询和报表统计，关系库支撑设备台账、用户权限和配置信息。三者的存储引擎不同，不能混用。数据层向应用层暴露的接口应当是API或数据集，而不是让应用层直接连数据库表。一个常见的错误是应用层直接查询历史库的原始测点表，导致复杂报表拖垮整个平台。

应用层只做业务价值输出：能耗看板、成本分摊、需量预警、碳排核算、报表导出。应用层不应包含任何设备协议解析逻辑，也不应直接操作采集层。应用层与数据层的接口应约定好数据粒度和时间范围，例如“按15分钟粒度查询某表计某天的有功电量”。

三、架构选型决策表

下表用于方案评审时快速定位架构类型。表中“测点规模”指平台接入的实时测点总数，“站点数”指需要独立采集的物理位置数量，“可用性要求”指年允许停机时长。

四、一个分布式架构的落地示例

假设某集团有3个厂区，每个厂区约2万测点，中心需要汇总各厂区能耗并做对比分析。推荐采用分布式架构：每个厂区部署一台采集服务器和一台监控服务器，本地历史库保留12个月数据；中心部署数据汇总服务和Web应用，只存储各厂区上传的15分钟粒度汇总数据和报警事件。厂区与中心之间通过专线或VPN连接，采用MQTT协议上传，QoS设为1（至少一次）。断网时，厂区本地缓存数据，恢复后按时间戳补传，中心侧做去重处理。这样设计的验证点是：断开中心网络30分钟后恢复，中心侧数据无缺失、无重复，且各厂区本地监控不受影响。

架构设计完成后，建议输出一份《架构决策记录》，至少包含：选型结论、约束条件、被否决的方案及原因、以及后续升级的触发条件。这份记录在项目交付和运维交接时，比任何图纸都更有说服力。