Web SCADA: What It Is and How It Differs from Traditional SCADA

A web SCADA is an industrial supervision system whose interface is served from a server and used from the browser, with no client installed on each workstation. Compared with the traditional thick-client SCADA, what changes is the deployment model (one central installation instead of one per PC), the access model (any device with a browser and the right permissions) and the user model (many people with role-based views instead of a single operator seat). In this guide we look at what each approach offers, when each one makes sense and how Captia.ai approaches it.

What a web SCADA is

SCADA stands for supervisory control and data acquisition: the tool the operator uses to see the state of the process, receive alarms and act. What sets a web SCADA apart is not what it does but how it is delivered: mimic screens, trends, alarms and commands are served as a web application and consumed from any modern browser, on a control-room PC, on the shift leader's tablet or on the on-call technician's phone.

The practical consequence is that the SCADA stops being a physical seat and becomes a service. The server holds the logic, the screens and the permissions; the clients only render. There are no client versions to update machine by machine, no per-seat licences to ration between shifts, and no difference between watching the plant from the control room or from a customer visit, beyond the permissions each role has been granted.

Traditional SCADA: thick client and single seat

The classic SCADA was born in a different era and for a different problem: a fixed operator seat, on the same network as the PLCs, with a runtime installed on a dedicated industrial PC. That model remains perfectly valid for what it was designed to do, and it deserves a description without caricature:

• Per-seat installation. Every PC that needs to see the process runs its own runtime, with its licence, its version and its maintenance. Adding a seat is a small project: hardware, licence, installation and testing.
• Coupling to the operating system. The runtime typically depends on specific Windows versions and on communication drivers installed on the same machine. Operating system migrations become SCADA migrations.
• Designed for the OT network. The client lives on the same network as the process. Taking a view outside that network (to management, to maintenance at home, to a supplier) requires add-ons, from remote desktops to screen replicas.
• One operator per seat. The user model is that of the control desk: whoever sits in front of it is in command. Roles, concurrent sessions and per-profile views are later additions, not the original design.

HTML5 and the browser: what really changes

The first generation of "SCADA with web access" published the thick client's screens through technologies that browsers have since retired, such as Java applets or Flash, or simply shared the control seat's desktop. It worked, but it inherited every limitation of the original model and added its own.

A modern web SCADA is built directly on HTML5: the screens are native web applications, not a relay of a client installed somewhere else. That changes three things fundamentally:

• Zero installation and zero per-seat maintenance. The browser is already on every device. Updating the SCADA means updating the server once; the next page refresh serves the new version to everyone.
• Device independence. The same screen responds on a control-room monitor, a tablet at the machine or a phone. Responsive design is not an extra: it is the difference between checking an alarm from where you are and walking to the seat.
• Natural integration with the rest of the software. A web application coexists with APIs, corporate authentication and deep links. Linking from a notification to the exact screen of the affected asset is trivial on the web and contrived in a thick client.

Multi-user and roles: from one seat to the whole plant

The most underestimated change is not technical but organisational. When seeing the plant stops costing a licence and an installation, the circle of people who see it widens: production, maintenance, quality, energy and management can work on the same data with different views.

For that openness not to degenerate into risk, the web SCADA needs a first-class user and role model: who sees what, who acknowledges alarms, who can write setpoints and who only reads. The line operator's view is not the energy manager's nor the general manager's, and all three come from the same server without duplicating engineering. Command control (only the right people write, from the right places) moves from being a physical restriction, the key to the seat, to being an explicit, auditable policy.

Secure remote access

Remote access is the most cited reason for moving to web SCADA and also the one that deserves the most respect. Publishing process screens on the open Internet is a serious mistake; the correct approach has three ingredients:

• The process is not exposed: the application is. The PLCs and the OT network stay behind; the remote user talks to the web server, with authentication and encryption, never to the control equipment directly.
• Encrypted, authenticated channels. TLS for all traffic and access through private networks or modern VPNs, so the public surface is minimal or nil.
• Permissions that separate seeing from acting. Remote consultation of dashboards and alarms is low risk; remote writing of setpoints demands restricted roles and traceability of every action. A good web SCADA lets you draw that line precisely.

This is the same approach we develop for the architecture as a whole in the guide to zero trust in industrial OT: connectivity adds value only when security is part of the design, not of the patch.

Cloud, hybrid or on-premise: where the web SCADA lives

A web interface does not dictate where the server runs. There are three patterns, and the choice depends on the criticality of the control and on the plant's connectivity:

• On-premise. The server lives in the plant, on the same infrastructure that hosts the classic SCADA today. You gain the web interface and the multi-user model without depending on the WAN to operate.
• Cloud. The server lives outside the plant and receives data through a local acquisition layer. Maximum convenience of access and maintenance, with one golden rule: supervision may live in the cloud; real-time control and machine safety stay in the plant, in PLCs and safety systems that depend on no WAN.
• Hybrid. The most common pattern in practice: local acquisition and buffering so that a network outage neither loses data nor stops the operation, with the supervision, analytics and history layer accessible from anywhere.

In all three, the web SCADA works better the better the data layer feeding it: multi-protocol acquisition, normalisation at the source and buffering against outages. That layer is exactly the role of an industrial data platform, and its entry piece, the edge gateway, is covered in the guide to industrial edge with buffering and QoS.

Comparison table: web SCADA versus traditional SCADA

When traditional SCADA is still the answer

An honest comparison admits that the answer is not always the web. The operator seat of a critical process, with real-time command, large-format screens and guaranteed availability even if everything else fails, is still well served by the classic model, and many plants will keep it for years. Nor does it make sense to migrate for migration's sake a fully amortised system that does its job and needs no more users.

The pattern we see working is not replacement but complement: process control stays where it is, and the web layer adds what the classic model does not give, multi-user supervision, secure remote access, a queryable history and connection with the rest of the business. Over time, each plant decides whether the web layer eventually absorbs seat supervision too or whether both coexist stably.

How Captia.ai approaches it

Captia.ai is the operations and intelligence layer of our platform, and its web SCADA is exactly the model described in this guide: supervision from the browser, with dashboards per asset, line, role or plant, history, rules, alerts, events and workflows, user and role management, reporting and APIs to connect with ERP or MES. On that foundation run its artificial intelligence modules, from anomaly detection to forecasting.

The data feeding it arrives through Captia Connect, the edge acquisition layer: multi-protocol reading of PLCs, sensors, meters and existing SCADAs, normalisation at the source and local buffering so a network outage does not open gaps in the history. Deployment can be on-premise, hybrid or cloud, and the existing SCADA is not replaced: it is integrated as one more source. The whole is the architecture we describe in industrial data platform.

Frequently asked questions about web SCADA

If you are considering bringing your plant's supervision to the browser without replacing what already works, at Captia.ai we build that layer on the data captured by Captia Connect. The starting point is the full architecture we describe in industrial data platform.