SCADA是什么？数据采集与监控系统的组成与作用

SCADA是Supervisory Control and Data Acquisition的缩写，通常译为数据采集与监控系统。它通过现场控制器和通信链路汇集设备、工艺过程的数据，让操作人员查看运行状态、处理报警、回看历史，并在权限与现场条件允许时发出监督控制请求，例如启停设备或调整设定值。

理解SCADA，要同时看到两条路径：现场数据怎样传到监控端，操作请求怎样到达现场并得到确认。它具备控制作用，但现场快速调节和动作逻辑通常由PLC、RTU等控制器承担，无须让每次计算都经过监控画面。它在工业应用中的位置，可结合研发设计、生产控制与经营管理三类工业软件的分工理解；下面用一个供水泵站说明具体工作过程。

SCADA系统由哪些部分组成？

SCADA不是只有一块大屏。以远程泵站为例，液位、压力和泵的运行状态需要在现场取得，再经过通信和采集处理，才能成为可查看、可记录的数据；反方向的操作请求，还要由现场控制逻辑决定怎样执行。

功能组成	在系统中承担的工作
现场仪表、执行器及反馈装置	仪表测量液位、压力或流量；泵、阀等执行机构改变过程；运行接点、位置反馈等提供设备实际状态。下发的命令与返回的状态应分清。
PLC、RTU及现场I/O	可编程逻辑控制器（PLC）、远程终端单元（RTU）等接收现场信号，执行配置的控制逻辑，并向上提供数据、接收允许的操作请求。实际能力随设备与程序而异。
通信链路与采集服务	经工业网络、专线或无线等连接现场，使用相应驱动或协议读取、订阅和写入数据，并处理连接状态、质量及时间信息。
监控服务器与操作界面	组织变量、设备对象和画面，呈现状态与趋势，管理用户权限和操作入口。服务器与客户端可以分开，也可能在同一计算环境中运行。
报警、历史及相关记录功能	按配置识别并记录报警，保存选定过程数据和操作事件，支持检索、趋势分析及报表。保存哪些内容、保存多久，需要单独定义。

这些是功能角色，不要求每一行各对应一台独立服务器。NIST SP 800-82 Rev.3第2.3.2节用现场采集、通信、中心监控及操作等环节描述SCADA，并说明现场RTU、PLC可承担本地控制。系统的边界应沿实际数据和控制路径判断，不能只看监控室里安装了什么软件。

从供水泵站看SCADA怎样采集数据、发出控制请求

假设一个泵站向蓄水池补水：现场PLC接入池内液位、泵运行反馈和流量，并配置本地自动补水逻辑；SCADA用于远程监视，在现场模式和许可条件满足时也可以提出启动请求。以下是学习用的功能示例，不代表某套实际装置的接线、阈值或操作规程。

现场信号先成为有明确含义的数据点

液位测量经输入接口进入PLC，按工程配置处理后，通过通信提供给SCADA。采集端需要知道读取哪个地址或节点、数据类型是什么、单位与缩放怎样解释，才能把它显示成“某池液位”。泵运行反馈、远程模式和故障状态也要分别映射，不能把名字相近的点当成同一个信号。

SCADA中的变量常被称为Tag。它可以关联数据来源、画面、报警和历史功能。Ignition的Tags文档展示了这种数据点组织方式。读取方式可以是轮询，也可以是订阅；连接成功仅说明某条通信路径可用，还需要确认点位与工程含义正确。

在本例中，本地自动补水逻辑由PLC依据液位和现场条件执行。SCADA把当前状态、设定和异常呈现给人员，帮助他们管理整个泵站；不能把画面刷新速度当作PLC控制逻辑的执行周期。

操作请求通过通信后，仍要由现场条件决定是否执行

假设操作人员准备远程启动泵，完整过程可以按下列环节理解：

1. 发起请求：操作界面核对用户权限，向指定控制点发送启动请求，并记录相关操作信息。
2. 现场检查：PLC判断当前模式是否接受远程启动，检查本例配置的水源条件、设备故障和其他许可条件；不满足时拒绝请求或返回相应状态。
3. 执行动作：条件满足后，PLC通过输出和驱动设备作用于泵。通信写入本身不会替代这一段实际执行。
4. 读取反馈：监控端再查看泵运行反馈，以及与任务有关的流量、压力或液位变化，判断是否得到预期结果。

这几个阶段回答不同问题。“已发送”说明请求离开了某个环节；“写入成功”说明某层接受了数据；“泵已运行”则需要设备反馈。即使命令寄存器读回为启动状态，也不能仅凭该命令位证明电机已经转动。运行反馈能说明其配置所代表的设备状态，而补水效果还应结合相应过程量判断。

OPC UA的Write服务规范给出一个明确例子：Good_CompletesAsynchronously可以表示已写入中间系统，但服务器尚不知道数据源是否更新成功。不同协议和产品的确认机制有所不同，这个例子说明，必须识别“成功”发生在哪一层。

界面变化也未必是最终确认。例如，Ignition Tag Groups文档中的Optimistic Writes允许先更新界面标签值，再等待后续核实。因此，画面上的按钮或数值变化不能独自代表设备动作完成。若请求发出后通信中断，结果应标为待确认，先核查现场状态，而不是把重复点击当作可靠的恢复办法。

一个SCADA数值为什么还要看时间和质量？

画面显示“液位2.4米”，至少还要知道它属于哪个池、单位是否正确、数据什么时候取得，以及当前是否仍可用。数值、来源、时间与质量一起，才构成能够解释的运行信息。通信失联后最后一次读取仍可能是2.4米，但它已经不能直接代表此刻的现场液位。

源时间、采集时间和接收时间，不一定相同

有的设备或数据源能够给出时间戳，有的只能由采集端在读取时标记时间，平台接收到数据又是另一个时刻。分析“泵先停止，还是流量先下降”时，需要知道使用的时间来自哪里，并考虑相关设备时钟是否一致；不能用消息到达的先后顺序，直接代替现场发生顺序。

OPC UA的DataValue定义区分sourceTimestamp和serverTimestamp：前者由数据源赋予，可反映值或状态上次变化；后者可反映服务器接收或确认该值准确的时刻。它们不能自动等同于监控平台的入库时间。一个值长时间没有变化，源时间也可能不变，因此“时间戳较早”不应单独成为失联结论，还要结合质量、最近成功读取或心跳等信息。

质量状态说明数据可用性，不替代测量与映射核对

采集系统可以给数据附加正常、不确定、过期或未连接等质量状态。Ignition质量码文档区分最后已知值、过期值和未连接状态，并说明怎样在画面中提示异常质量。各产品的代码和传播规则不同，不能把某一家代码表当作所有SCADA的统一规则。

质量正常也不意味着量程、单位、点位映射和仪表校准必然正确。例如把毫米误解释成米，通信仍可能完全正常。反过来，通信断开时可以保留最后已知值，但应清楚标出未更新或失联状态；把失联值直接显示成零，容易让人员误认为池内已空。

采集、画面刷新与历史记录为什么可能不同步？

现场控制器更新数据、SCADA获取数据、画面刷新和历史库写入，是不同环节。历史记录还可能采用变化触发、周期记录或死区过滤，查询时也可能按时间区间聚合或插值。Ignition Tag Historian文档说明了相关采样、记录和查询机制。因此，一条看起来连续的曲线，不必然意味着每个时刻都保存了原始测量值。

作一个明确的假设：SCADA采用普通轮询，每1秒读取一次故障位，现场既不保持该位，也不保存事件。如果故障位仅维持200毫秒，并恰好出现在两次读取之间，SCADA就可能一次也没读到。把画面刷新得更快，无法补回没有采到的事件。需要记录这种短事件时，应在适合的现场环节捕获、保持或生成带时间的事件记录，再向上提供。

保存历史时也要围绕实际问题安排：判断泵运行时段，需要可靠的状态变化；分析流量变化，需要合适的过程采样；追查远程操作，还需要操作记录。只保存液位曲线，事后未必能还原是谁发出启动请求、现场是否拒绝以及泵何时真正运行。

报警确认与报警恢复有什么区别？历史记录怎样帮助分析？

报警是依据配置条件产生的运行事件。例如泵站液位超过设定高限后，系统可以形成高液位报警。操作人员进行“确认”，表示对这条报警作出了确认记录；“恢复”则表示报警条件已经不再成立。两者描述不同事实，确认本身不会证明现场液位已经恢复。

Ignition报警文档将激活或恢复、确认或未确认作为两个独立维度。因此，报警可以仍在激活但已经确认，也可以已经恢复但尚未确认。确认和恢复的先后可以不同；消音只是声音处理，也不能当成异常已经消除。

在泵站案例中，若液位报警先发生、随后操作人员确认，而液位继续升高，报警条件仍然存在。若液位已降回允许范围、人员稍后才查看，则可以先恢复后确认。运行记录需要保留这些差别，不能把“已确认”统一画成“设备正常”。

报警列表用于了解当前需要关注的事件；报警历史用于回看发生、确认和恢复等记录。两者不能互相替代。Ignition Alarm Journal文档说明，报警日志需要相应的存储配置。画面上出现过报警，并不自动意味着所有事件都已长期保存。

分析某次高液位事件时，可以把液位、泵运行状态、流量、操作请求和报警放在同一时间轴上比较：先核时间来源，再看异常前后的变化。它们能帮助提出并核实原因，但“两个变化接近同时发生”仍不是充分的因果证明；设备检查或现场记录可能仍然必要。

SCADA断网后会怎样，恢复连接就能补齐历史吗？

“断网”需要先说清断在哪一段。操作画面连不上、现场通信中断和数据库不可用，对控制与记录的影响并不相同。

中断位置	需要分别判断的影响
操作客户端与服务器之间	人员可能无法查看或操作；如果服务器、采集服务和其他链路仍正常，采集与历史记录可能继续。不能仅因一台客户端离线就认定现场停机。
SCADA采集端与现场PLC、RTU之间	远程新数据和操作可能不可用。本地自动控制能否继续，取决于现场程序、通信失效策略及对外部数据的依赖，不能保证一律继续或一律停止。
采集或历史服务与数据库之间	现场数据可能仍在被采集，但能否暂存、保留多少和何时补写，取决于实际缓存配置、容量与服务状态。

对于本例，只有在自动补水逻辑及所需输入都能本地完成、且故障策略允许的条件下，PLC才可能在远程通信中断后继续自动运行。此时远程画面仍应显示数据失联或未更新，而不是把“本地可能在运行”当作已确认的远程状态。

Ignition的Store and Forward文档展示了数据库写入失败时的缓存和后续补写机制。这类机制保存的是已经到达相应环节的数据，不能自动补回从未被现场或采集端记录的内容。若现场另有历史缓冲，还需要系统支持读取并处理这些记录；恢复连接本身不等于完整历史已经恢复。

补传记录应保留可识别的原始时间和来源，并避免重复计入；尚未恢复的区间应留有可见标记。尤其在事后查看曲线时，要分清迟到的数据、插值结果和真实缺口，不能用一条平滑连线掩盖未知状态。

SCADA适合哪些场景，与PLC、HMI、DCS怎样区分？

SCADA常用于需要汇集多个现场运行信息、进行远程监督操作并保留事件历史的场景，例如分散泵站、供水设施、电力站点和管线监控。它也可以用于同一工厂内的多个设备或工艺区域，不要求现场必须跨城市分布。

PLC或RTU承担现场信号处理和控制，是SCADA可能连接的对象；人机界面（HMI）是人员查看和操作系统的入口，可以是机旁屏，也可以是SCADA客户端，单独一块HMI不等于完整SCADA。DCS则强调多个控制单元在统一工程与操作环境中的协调，实际工程里几类系统可以存在功能交叉。需要进一步理解这种控制架构，可阅读DCS的结构与工作原理。

判断一个SCADA系统实际做到了什么，最终要沿着具体对象核实：点位是否对应真实设备，时间与质量是否可解释，请求能否追踪到现场反馈，报警和历史是否按需要保存，以及各处通信中断时是否留下明确状态。这些关系决定了监控画面能支持哪些操作和分析。

参考资料

• NIST：SP 800-82 Rev.3，Guide to Operational Technology (OT) Security，2023年，第2.3.2—2.3.4节。
• Inductive Automation：Ignition 8.3文档，Tags、Tag Groups、Quality Codes and Overlays。访问日期：2026年10月25日。
• OPC Foundation：OPC UA Part 4，第5.11.4节Write、第7.11节DataValue。访问日期：2026年10月25日。
• Inductive Automation：Ignition 8.3文档，Alarming、Alarm Journal、Tag Historian、Store and Forward。访问日期：2026年10月25日。