1.2 四代 SCADA：从中控室的一面墙到一朵云
1.2 四代 SCADA：从中控室的一面墙到一朵云
本节摘要：SCADA 的架构史可以概括为四代：单机集中式、分布式、网络化、云化与物联网化。每一代都由一组具体矛盾驱动——布线成本、点数膨胀、跨厂区互联、多基地协同——而每一代的解决方案又留下新的债。本节按时间线梳理四代特征与代表性技术，并解释为什么今天的改造项目里四代架构常常同时存在。
先看一段真实的机房
水厂老调度室的档案里有一张照片：一面三米宽的模拟屏，数百只指示灯和指针仪表按工艺流程排布，屏后是成捆的芯线，每只灯泡对应现场一只继电器触点。那是这家水厂最早的「SCADA」——严格说是硬接线监控系统。后来拆掉这面墙换上计算机的工程师，和今天把老系统迁到云平台的工程师，面对的其实是同一类问题：让远处的人更可信地看见现场。理解四代演化，就是理解每个架构决策背后的那条矛盾线索。
一、第一代：单机集中式，主机时代的确信与束缚
上个世纪中后期，监控系统的核心是一台专用主机（后来是小型机），现场信号通过远程终端单元（RTU）用专线接入，主机的屏幕和键盘就是操作员的一切。这一代的特点是架构极简、行为确定：轮询节奏、报文格式、画面逻辑全部静态固定，出问题时工程师拿万用表和逻辑分析仪就能查。
代价是僵化。加一个测点，往往要动通信电缆、改主机组态、重新调试轮询表；主机是单点，它一停全厂失明；不同厂商的主机和 RTU 协议私有，互换为零。水厂项目老档案里那份「测点变更申请单」要三个科室会签，正是这一代架构的日常。
二、第二代：分布式，把智能铺到现场
微处理器价格跳水后，RTU 和 PLC 拿到了自己的计算能力，监控架构随之分叉：主站之间、主站与现场单元之间通过局域网互联，单点故障不再导致全局失明。这一代的标志性变化是功能下放——联锁保护、本地闭环留在现场控制器，主站专注监盘；通信标准化起步，不同厂家的设备第一次可以商量着说同一种「话」。
分布式带来的新问题是配置漂移：每个现场单元都有自己的组态，版本一多就对不上账。今天你在任何一家工厂能见到的「点表与实际接线不符」问题，多半是这一代留下的遗产治理欠账。工程上的应对——把点表纳入变更管理、定期与现场核对——到第三代才逐渐成型。
三、第三代：网络化，走出厂墙
以太网与 TCP/IP 普及后，SCADA 的地理范围从「一个厂」扩展到「一张网」：管网沿线的加压站、几公里外的取水头部、跨县的污水提升井，都能接入同一个平台。协议层面，IEC 60870-5-104、DNP3 这类面向广域的规约成为电力与水务的主流，通道诊断、断线续传、事件缓存成为主站的必备能力。
网络化把 SCADA 从孤立系统变成了网络节点，也随之带来了此前不存在的风险面：原本物理隔离的系统开始与企业网互联，协议自身薄弱的安全机制暴露出来。第三代架构的功能设计已经相当成熟，它的历史使命之一，是逼着行业正视「互联互通」与「安全边界」必须同时设计——这正是本书第 6 章的全部内容。
四、第四代：云化与物联网化，数据成为主角
云计算、容器化、消息队列与物联网协议（MQTT 及其 Sparkplug 规范）把 SCADA 推进第四代：采集服务可以弹性扩容，历史数据进数据湖，AI 模型直接消费测点数据做预测性维护，移动端与浏览器成为新的画面载体。第四代的关键不是「上云」这个动作，而是数据语义的标准化——Sparkplug 用统一的主题结构与状态管理，让「泵的运行状态」在不同系统之间不再需要一对一翻译。
第四代的债是实时性与确定性的再谈判：控制指令还能不能走云？丢网时现场自治到什么程度？第 8 章会专门展开。这里只需记住一个工程直觉：云适合做记忆与思考，边缘适合做反应。
图 1-2 SCADA 四代演化时间线与驱动力
五、为什么改造项目里四代并存
走进今天任何一个在运水厂，你几乎能同时看到四代架构的活化石：老泵房还留着第二代 PLC 的硬接线联锁；加压站上一代网络化 RTU 用 104 规约向上送数；新建的深度处理车间第一次用了支持物联网规范的网关；集团的数据中台在云上汇总六座水厂的趋势。这不是落后，而是分层理性——每一层都选了该层约束下最经济的架构。
给设计者的启示有三条。其一，不要为了「新」而统一：把联锁保护搬上云没有任何收益，风险倒是无穷大。其二，换代规划要沿着数据流做：先统一语义（点表规范），再换传输（网络与协议），最后换平台，倒过来做的项目返工最多。其三，每代遗留的债要显式登记：组态漂移、协议私有、安全缺位，这些债不会因为上了云就自动消失，第 7 章验收清单里我们会把它们变成可勾选的检查项。
六、代际判读：拿到一个老系统先问五个问题
改造项目的第一步永远是「判读存量」。对着一套运行多年的系统，按五个问题走一遍，它的代际坐标与债务清单就基本清楚了：
- 事件时标在哪打的？ 答案是主站，说明它还带着一代或二代的血液，事件顺序分析要打折扣用；
- 断链后数据丢不丢？ 丢，说明没有站端缓存机制，通信契约里必须先补这一课；
- 加一个测点要动几处？ 要动线缆、主站表、画面、报表四处以上，说明语义层没有统一，点表债深重；
- 两个厂商的设备怎么对接的？ 靠私有驱动或定制网关，说明开放性债；换厂商时这些都会变成报价单上的数字；
- 谁的账号能进控制网？ 答案含糊，说明安全债从上一代一路欠到现在。
这五个问题的答案直接进入改造需求清单——它们比「用不用新技术」重要一个量级。水厂项目改造立项时，我们把这五问答成一页纸附在需求书第一页，评审会上省掉了大量「现状到底是什么」的来回。
七、演化视角的三个反直觉结论
把四代史读细了，有三个结论与直觉相悖，值得单独记录。结论一：架构的先进性不等于系统的先进性。 保养得当的三代系统，运行质量可能远胜疏于治理的四代系统——决定运行质量的是点表纪律、报警治理这些「卫生习惯」，不是代际。结论二：每一代的经典难题都会在下一代以新马甲回归。 二代的组态漂移，在四代变成「云边配置漂移」；三代的通道安全，在四代变成「多云身份与密钥管理」。识别出「老问题的新马甲」，可以复用上一代的治理手段。结论三：换代的窗口期是债务清算期。 平时动不了的点表统一、协议替换，趁换代一次做掉最省钱——换代规划里不排债务清算项的项目，投运第一年就会以故障形式把债讨回来。
本节要点回顾
- 四代脉络：单机集中 → 分布式 → 网络化 → 云化物联，每一代由具体矛盾驱动，而非技术时尚。
- 代际叠加：在运系统通常四代并存，分层理性优于形式统一。
- 换代顺序：先统一数据语义，再改传输，最后动平台。
- 债要登记：旧架构的组态漂移与安全缺位不会自动消失，必须进入变更与验收管理。
下一节回答一个评审会上最常吵起来的问题：这套系统到底该叫 SCADA 还是 DCS？边界划在哪里？