这两年如果你还在用 2018 年那套方式选 SCADA / 组态软件，大概率会越选越累。

以前大家最爱问的是：支持多少驱动？能接多少点？有没有历史库？这些当然还重要，但到了 2026 年，我自己看项目、看产品、看 POC，关注点已经明显变了。因为现在很多客户要的，不再只是“把设备数据采上来、画面跑起来”，而是：能不能 Web 化、能不能跨端、能不能适应国产化、能不能低成本复制到更多现场、能不能和 IoT / 业务系统顺畅接起来。

2026 年，SCADA 选型的主战场，已经从“单机组态能力”转向“平台化能力”。

我重点看哪 7 个能力？

1. 架构是不是原生面向 Web，而不是“桌面软件网页化”

这是我现在最先看的点。

很多产品也会说自己支持 Web、支持云组态、支持浏览器访问，但实际体验差别非常大。有些是底层就按 B/S、云边协同思路来做，编辑器、运行态、权限、发布、远程运维是一整套；有些则更像传统 C/S 产品外面包了一层 Web 壳。

这两类产品在 Demo 阶段看着都能跑，但一到项目落地就会暴露问题：

• 编辑端必须装客户端
• 浏览器端只能看，不能真正配置
• 跨端体验不一致
• 发布流程复杂
• 多人协作和版本管理比较弱

这次查资料时，能明显看到一些厂商已经在强化 Web 化表达。比如：

• 力控 FWebSCADA，公开信息里已经把“web 架构、云边端灵活部署、在线 HMI 组态”放到比较靠前的位置。
• 海为 Cloud SCADA，公开资料里也强调云组态、MQTT、数据库对接、远程运维等能力。
• 一些更偏新一代 Web 可视化路线的产品，则从一开始就是浏览器编辑、浏览器运行、组件化发布。

我个人的判断是：

未来留下来的，不一定是功能最多的，而是“最像平台”的那一批。

2. 数据接入能力，不能只看“支持协议数量”

这是个老话题，但现在依然很多人会被带偏。

厂商 PPT 上写“支持上百种协议”已经不稀奇了。真正要看的是：

• 主流 PLC / 仪表 / 网关协议是否稳定
• OPC UA、Modbus TCP、MQTT 这类现代工业接入方式是不是一等公民
• 能不能方便接 HTTP / WebSocket / SSE / SQL
• 现场边缘网关和云端平台之间怎么协同
• 出问题后是能排查，还是只能靠原厂工程师远程救火

尤其现在越来越多项目不是“纯自动化监控”，而是自动化 + IoT + 业务系统集成。这意味着组态平台要接的不只是 PLC，还包括：MES、ERP、中台、消息总线、第三方接口。

所以我现在更愿意看“开放连接能力”，而不是单纯看驱动数量。

从公开信息看：

• KingSCADA 仍然是偏大型、复杂工业监控场景的代表，强调高端通用 SCADA、分布式架构、百万 IO、冗余能力。
• 力控 的产品线比较全，既有传统监控组态路线，也在往国产化、云化方向铺。
• 中控 InPlant SCADA 公开信息里也在强调大规模分布式和免费点数授权，比较适合关注大系统架构的人去细看。
• 乐吾乐 这类更偏新一代 Web 可视化平台的路线，优势往往不是“老牌协议故事”，而是 Web 数据源接入、组件化、前后端融合和可扩展性更强，适合需要把工业画面和业务应用做在一起的团队。

如果你的项目未来一定要接业务系统，我建议把“API / 数据源扩展能力”单独列成一项打分，不要埋在“协议支持”那一栏里。

3. 可视化编辑能力，决定了交付效率的上限

说白了，很多项目最后并不是死在采集，而是死在画面和交互交付效率上。

尤其这两年客户要的已经不是单纯工艺监控画面，而是：

• 车间总览
• 多厂区总览
• 告警驾驶舱
• 设备画像
• 能耗分析
• 手机端看板
• 大屏 + PC + 平板联动

这就要求组态平台不能只会做传统“监控画面”，还得能做更现代的可视化表达。

我现在会重点看：

• 图形编辑器是否顺手
• 组件库是否丰富
• 图表能力是不是够用
• 事件交互是否灵活
• 动画是否自然
• 模板复用是否方便
• 多页面工程能力是否成熟
• 有没有 2D / 3D / GIS 联动的可能

这一点上，我自己越来越偏向看“编辑器产品感”。

因为一个编辑器好不好，不是 demo 漂不漂亮，而是工程师愿不愿意连续用 3 个月。如果一个平台每加一个联动、每加一个弹窗、每加一个告警样式都很费劲，那项目后期基本会被拖死。

最近我翻资料时，比较有感的是，部分新一代产品已经不再满足于传统组态画布，而是往更完整的可视化平台走。比如乐吾乐的大屏 / 2D / 3D 几条产品线就是这种思路：2D 组态、可视化大屏、3D 场景、GIS 能力逐步打通，比较适合做“监控 + 展示 + 运营”一体化场景。它不是那种老牌 SCADA 的典型形态，但如果项目本身就是 Web 化、平台化方向，这种路线反而更顺。

4. 国产化与部署弹性，已经从“加分项”变成“必答题”

这个就不用多解释了，大家都懂。

但我想说的是，很多人理解的国产化还停留在“能不能部署到国产系统上”。实际上，今天项目里真正会问的是：

• 支不支持国产操作系统
• 支不支持国产数据库
• 有没有信创适配经验
• 部署方式是否灵活
• 边缘端、中心端、私有云怎么组合
• 出现网络抖动时，边端能不能自治

这次看公开资料时，这块表达比较明确的有：

• KingSCADA / 力控 / 中控 这类传统国产 SCADA 厂商，都在强调国产化生态与大型场景能力。
• 一些新一代 Web 平台，则更强调 Linux、容器化、云边协同、私有化部署等现代架构适配能力。

这里我有个比较明确的建议：

不要只问“支不支持国产化”，要问“国产化之后，实施复杂度会上升多少”。

因为真正花钱的，不是“能装上”，而是“能长期稳定跑”。

5. 复制能力比首个项目能力更重要

这点特别适合中小制造企业、多园区集团、设备厂商、集成商看。

一个平台如果只能做“一个项目”，那它更像工具；如果能把模板、组件、数据模型、权限模型、页面结构复制到第二个、第三个项目，它才更像产品。

我会看这些问题：

• 是否支持模板化复用
• 页面 / 组件 / 数据源能不能批量复制
• 多项目管理是否清晰
• 权限体系是否可继承
• 设备模型是否可复用
• 能不能快速从单站扩成多站

很多项目第一次上线时都挺满意，但复制到第二个现场就开始崩：命名规则乱了、变量结构乱了、页面规范没了、权限越做越脏。

所以现在我对“工程模式”“模板库”“项目复制能力”会比以前看得更重。

乐吾乐这一类偏平台型产品，在工程模式、多页面方案、组件模板化这块是有天然优势的；传统 SCADA 产品则在成熟行业积累、工程实施体系上更稳。怎么选，其实取决于你更需要“快速创新”，还是“沿成熟路径稳着上”。

6. 二次开发边界，要么足够开放，要么足够克制

我见过最痛苦的项目之一，就是产品什么都“支持二开”，但每次真改起来都很别扭。

一个好的平台在二开上通常会走两个方向之一：

• 要么足够开放：API 清晰、扩展点明确、前后端都好接、能嵌业务系统
• 要么足够克制：内置能力足够多，让你根本不用怎么二开

最怕的是卡在中间：基础功能不够、扩展能力也不顺。

对于今天很多数字化项目来说，SCADA 已经不是孤岛，它常常只是整体数字底座中的一个前台应用。因此，平台是不是支持：

• 自定义组件
• 自定义脚本
• 自定义数据源
• 第三方系统嵌入
• 导出成独立页面 / 组件
• 与业务中台做统一认证

这些问题，实际重要性越来越高。

乐吾乐在公开资料里提到支持导出 HTML / Vue / React、支持单点登录、支持多种 Web 数据源，这类能力对“工业可视化融入业务系统”很有吸引力。反过来，如果你的项目更强调稳定的传统监控闭环，老牌 SCADA 路线可能会让团队更有安全感。

7. 厂商与生态，不只是“有没有案例”，而是“遇到坑时谁能接住”

这点很现实。

很多人做选型时爱收集 logo 墙、成功案例、合作客户，但我觉得真正该问的是：

• 文档够不够全
• 社区活不活跃
• 培训资源多不多
• 出问题能不能快速定位
• 有没有合作伙伴生态
• 是否存在开源或开放社区能力

比如这次我顺手查到 meta2d.js 在 Gitee / GitHub 都有公开仓库，定位就是实时数据响应和交互的 Web 2D 引擎，可用于 Web SCADA、物联网、数字孪生。这类开源底座的价值，不只是“免费”，而是它给了团队更强的透明度和可扩展空间。

当然，开源不等于项目就一定轻松，企业级落地看的是“开源能力 + 商业产品能力 + 服务能力”能不能接上。

所以最后我会把生态拆成两部分看：

• 工程生态：实施商、培训、案例、服务
• 技术生态：文档、社区、开源、API、可扩展性

如果让我粗分，我会怎么理解这几类产品？

这不是严格排名，更像是我个人现在的一个认知地图：

第一类：传统强势 SCADA 路线

代表方向：KingSCADA、力控、中控等

特点：

• 在大型工业监控、复杂项目、传统行业积累深
• 对分布式、冗余、大点数、行业交付更有话语权
• 更适合对稳定性、成熟案例、行业经验要求高的客户

可能的代价：

• Web 化体验未必都同样优秀
• 产品思维有时偏工程导向
• 新业务场景的扩展性要具体看产品代际

第二类：云化 / Web 化增强路线

代表方向：海为 Cloud SCADA、力控 FWebSCADA、部分 HTML5 / 云组态产品

特点：

• 更强调浏览器访问、远程运维、跨端能力
• 更适合轻量部署、远程站点、IoT 场景
• 对中小项目、多站点项目更友好

可能的代价：

• 大型复杂工业场景的深度能力要谨慎验证
• 宣传里的“云化”不一定等于平台化

第三类：新一代 Web 可视化平台路线

代表方向：更偏 Web 原生、低代码、可视化引擎驱动的平台

特点：

• 编辑器体验往往更现代
• 容易和业务系统、IoT 平台、大屏、数字孪生一起做
• 对多端呈现、组件化开发、平台化复制比较友好

可能的代价：

• 传统 SCADA 深水区能力要做针对性验证
• 项目成败更依赖团队产品化和实施方法

乐吾乐我会放在第三类里看，而且在这一类里它的完整度是比较高的：有 2D、3D、大屏、GIS、IoT 平台，底层还有 Meta2d.js 开源生态。如果项目目标是“做一个现代化 Web 工业可视化平台”，它确实值得试；但如果你是典型的传统大工业控制监控项目，也别跳过老牌厂商，该做 POC 还是要做。

我建议怎么做 POC？

如果你们今年真的要定平台，我建议别只听销售讲，直接做一个 2~3 周的小型 POC，重点验证这 6 件事：

1. 接 2 种真实现场设备 / 协议
2. 做 1 套工艺监控画面 + 1 套管理驾驶舱
3. 跑 1 组历史趋势 + 报警
4. 做 1 次权限分级
5. 做 1 次移动端 / 大屏适配
6. 做 1 次与第三方系统的接口联调

最后别只让工程师打分，最好让三类人一起评：

• 自动化工程师
• IT / 平台架构人员
• 业务使用者

因为现在很多 SCADA 项目，买单的人、实施的人、最终用的人，早就不是同一拨人了。

最后一句

2026 年再看国产 SCADA / Web 组态，我觉得已经不能只问“能不能做”，而要问：

它能不能帮你把一个项目做成产品，把一个现场复制成一套体系。

如果你的场景是传统大型工业监控，老牌国产 SCADA 依然很有价值；如果你的目标是 Web 化、平台化、数字孪生化，那就别只盯传统名单了，去看看那些真正按新一代架构做出来的产品。

选型这件事，最终拼的不是参数表，而是谁更适合你接下来 3 年的路线。