2.1 分层架构：现场层、通信层与监控中心

2.1 分层架构：现场层、通信层与监控中心

本节摘要：分层是 SCADA 架构的第一设计动作：现场层负责与物理世界打交道，通信层负责把数据可信地搬来搬去，监控中心负责把数据变成人的判断依据。本节讲三层的职责边界、层间接口与故障传播规律，并区分物理架构与逻辑架构两个常常被混用的视角。

从一张被画错的图说起

新人画的系统图常犯一个错：把「数据库服务器」画在现场层，理由是「数据是从那儿来的」。图本身不算错——物理连线确实通到机柜——但职责画错了，照着它做故障预案就会闹笑话：数据库宕机时，该切的是监控中心的服务，而不是去泵站重启什么。分层图画的不是连线，是职责与故障边界。本节要让你看图时能读出三层信息：设备在哪、职责归谁、故障影响多大。

一、现场层：系统的手与脚

现场层包括一次仪表（压力变送器、液位计、流量计）、执行器（电动阀、变频器、接触器）和控制器（RTU、PLC）。它的职责清单很短：把物理量变成数字，把数字指令变成物理动作，以及在通信中断时独立维持本地联锁与顺控。

现场层设计的三个要点。第一，自治能力：通信断了，泵站还必须安全运行——联锁保护、本地顺控、直流后备电源都属于现场层自治的一部分。第二，接口标准化：仪表信号制式（模拟量、数字量、总线）在层内统一，避免每只仪表一种接法。第三，环境适配：防护等级、温度范围、供电制式按现场实际选，控制柜里的低温致使液晶屏失效这类问题，图纸上永远看不出来。

故障传播规律：现场层故障的影响范围默认是本站。设计的目标就是把故障摁在站内——这也是为什么联锁逻辑应留在现场控制器而不是主站。

二、通信层：系统的神经

通信层包括站端网关、工业交换机、光纤环网、无线通道和广域链路，以及跑在上面的协议栈。它的职责是把现场层数据按契约送到监控中心：完整（不丢）、及时（时延可预期）、有序（事件时标可靠）、可诊断（断了能报警、能定位）。

这层最容易被低估的是契约二字。「能 ping 通」不等于通信可靠。工程契约至少包括：轮询或上报周期、通道切换时间、断链缓存时长、时钟同步精度、报文优先级。第 4 章会逐条展开这些契约怎么定、怎么验。

故障传播规律：通信层故障的影响范围是链路两端的所有会话，但设计得当的话，数据不丢（站端缓存）、控制不乱（指令重发与去重机制）、现场不失守（自治运行）。

三、监控中心层：系统的大脑皮层

监控中心包括采集服务器（前置）、实时数据库、历史数据库、报警服务、画面服务、报表服务以及操作员站。职责是把海量测点组织成人可消化的态势：实时画面、分级报警、趋势曲线、报表与回放。

这层的架构要点是服务拆分与状态分离：采集、报警、画面、历史各自独立进程甚至独立服务器，任何一项重启不影响其余；实时态放内存，历史态落盘，分析态进数据平台。拆分粒度过了头也有代价——服务间调用链变长，排障复杂度上升。中小项目用一体化平台加双机冗余，往往比硬拆七个微服务更稳。

故障传播规律：监控中心故障的影响是人失去态势感知，但现场继续安全运行。这是分层的终极保险：中控全黑，泵站照常供水——代价是没有了远程调度。

图 2-1 三层架构与故障影响范围

四、物理视角与逻辑视角：一张图两个读法

物理架构回答「东西在哪」：几台服务器、几块板卡、几芯光纤、哪个机房哪面柜。逻辑架构回答「职责归谁」：哪个进程做规约解析、哪张画面属于哪个工艺系统、哪个账号有遥控权限。同一套物理设备可以承载多种逻辑划分，混用两个视角是架构评审里最常见的信息噪音。

实操建议：物理图与逻辑图分开画，各自版本化；评审时先对逻辑图追问职责与故障预案，再对物理图追问供电、接地与施工路由。水厂项目里我们把逻辑架构图贴在调度室墙上——操作员不需要知道服务器机柜位置，但必须知道「画面上的加药系统归二区网关管，它断了会看到什么」。

五、分层的常见变形与适用条件

教科书式的三层在现场会因规模与历史而变形，认识常见变形能避免「照图施工式」的误判。变形一：两层压缩。 小型厂站常把通信层压薄——站端控制器直接带广域规约接口，网关不单独成盒。这是合理简化，但压缩后要把网关的四项职责（3.2 节）明确挂回控制器：断链缓存、对时、变化检测不能凭空消失。变形二：监控中心前移。 跨区域项目会在片区设「区域监控站」，中心只做汇总——相当于把监控中心层复制了两级。两级中心必须先回答「数据谁权威」：区域站故障时，中心能否直连站端接管？答案写进设计，否则故障时会出现两个「事实源」。变形三：单层全景。 特小型系统（一个泵房、几十个点）用一台一体化控制器完成全部三层职能。它依然是三层逻辑，只是物理上合体——逻辑分层不因物理合并而失效，排障时依然按「先现场、再通道、后中心」的次序走。

变形识别的价值在接手别人的系统时最明显：看到非典型拓扑，先把它「还原」成标准三层标注职责，再判断每个环节是否尽责——这套还原动作能让你在半天内建立起对陌生系统的掌控感。

六、接口契约：层与层之间的交接清单

分层设计最容易漏的不是层内功能，是层间交接物。三份交接清单建议在设计文件里显式成表：

• 现场层交给通信层：测点清单（与点表同源）、变化上送约定、断链缓存参数、站端自治策略声明；
• 通信层交给监控中心：通道画像（时延、可靠性）、规约与版本、对时方式、各通道看护参数（4.2 节）；
• 监控中心交给使用者：画面与报警规范（5.2 节）、权限模型、数据外供接口与语义（2.3 节）。

交接清单的用处是让相邻层的负责人互相签字。集成项目里大量摩擦源于「我以为你知道」——清单加签字，把默契变成契约。水厂项目联调前的最后一轮设计会，议程就是逐条过这三份清单，所有「默认」当场消灭。

七、案例：三层划分怎么救了一次半夜故障

某夜，水厂中控三台操作员站画面同时冻结。值班员按预案做了三件事：确认泵站数据仍在按周期入库（采集服务活着，是画面服务挂了）、切换到备用画面服务器、电话通知各站保持就地值守。二十分钟恢复，全程无一次非计划停机。复盘会上，这份预案的每一行都对应着架构图上的一条分层决策：采集与画面分离，所以画面崩溃不等于数据断流；历史库独立，所以故障期间数据可回补；站端自治，所以通信保障优先级可以降低。解读这则案例的关键不是「预案写得好」，而是三层职责划分在故障时刻自动给出了排查顺序：先判断数据链通不通（通信层），再判断服务死没死（中心层），最后才怀疑现场（现场层）。变式思考：如果采集服务与画面服务部署在同一台服务器，这份预案要改几处？每处会多损失什么？

本节要点回顾

• 三层各管一段：现场层管物理，通信层管搬运，监控中心管态势；分层的目的是把故障和变化限制在局部。
• 故障边界即职责边界：现场故障摁在站内，通信中断数据不丢，中心宕机现场自治。
• 通信契约先行：周期、切换、缓存、对时、优先级写进设计，不能靠「能通」蒙混。
• 物理与逻辑分开画：两张图各自版本化，评审各答各的问题。

下一节聚焦故障本身：冗余设计的常用手法、各自代价，以及切换怎么才算成功。