SCADA has always been about one thing: visibility over distributed infrastructure. Whether that’s a water treatment network, a gas pipeline, an energy substation, or a manufacturing line, the core requirement is the same – reliable data collection, meaningful visualisation, and fast alerting when something goes wrong.

The problem with traditional SCADA platforms is the cost and rigidity. Proprietary HMI software. Vendor-locked hardware. Licensing models that charge per tag. Integration that requires specialist contractors and weeks of configuration work. For operators running modern IoT-enabled equipment over cellular or Ethernet WAN, that model feels increasingly mismatched.

ThingsBoard has become one of the most widely adopted open-source IoT platforms in industrial and utility deployments precisely because it addresses these friction points head-on. It speaks the protocols SCADA engineers already use, runs wherever you need it to run, and scales from a 10-device pilot to a multi-site enterprise deployment on the same codebase.

What ThingsBoard brings to SCADA deployments

ThingsBoard is not a traditional SCADA platform – and that distinction matters. It does not try to replace a full DCS or PLC programming environment. What it does is provide the data layer, visualisation layer, and alerting layer that sit above your field devices and controllers, connecting them into a coherent operational picture.

Protocol support – the practical reality

The most common integration question in any SCADA context is protocol support. Field devices – PLCs, RTUs, meters, sensors – rarely speak MQTT natively. Most still communicate over Modbus or OPC-UA, sometimes over serial RS-485 backplanes.

ThingsBoard handles this through its IoT Gateway component, which runs as a lightweight service on any Linux-capable device (including industrial routers and edge computers) and translates legacy protocols into ThingsBoard’s telemetry API.

How a typical SCADA deployment looks on ThingsBoard

The architecture for a cellular-connected SCADA deployment using ThingsBoard generally follows this pattern:

The industrial router does two jobs here. First, it provides the WAN link – typically 4G LTE or 5G cellular with failover to a secondary SIM or fixed-line backup. Second, it can run the ThingsBoard IoT Gateway as a Docker container or lightweight application, handling local protocol translation before data is sent upstream. This means Modbus polling happens locally and only processed telemetry is transmitted over the cellular link – reducing data usage and latency.

For fixed IP connectivity – which is important for SCADA deployments where the server needs to reach out to field devices as well as receive telemetry – a fixed IP SIM at the remote site removes the need for complex VPN configuration in many topologies. Combined with ThingsBoard’s built-in RPC commands, operators can push configuration changes and commands back to field devices through the same path.

ThingsBoard Edge – the case for local processing

One of the most practically important features for SCADA engineers is ThingsBoard Edge. This is a version of the ThingsBoard platform that runs locally at the remote site – on an industrial PC, edge server, or capable router – and operates independently of cloud connectivity.

The value is straightforward. In SCADA applications, a WAN outage should not mean loss of control visibility. ThingsBoard Edge continues to collect data, evaluate alarms, and present dashboards locally during any connectivity interruption. When the link recovers, it synchronises telemetry history back to the cloud instance. No data gaps, no blind spots during outages.

This architecture is particularly relevant for sites in marginal cellular coverage areas, offshore or remote locations, or any deployment where regulatory requirements mandate local data retention – energy, water, critical national infrastructure.

SCADA verticals where ThingsBoard is actively deployed

Community Edition vs Professional Edition – what matters for SCADA

ThingsBoard Community Edition is open source and free to self-host. For many SCADA deployments, particularly pilots and smaller networks, it covers the core requirements: Modbus/OPC-UA via IoT Gateway, dashboard builder, alarm engine, rule chain processing, and basic user management.

Professional Edition adds features that become relevant at scale or in multi-tenant and enterprise contexts: advanced RBAC with domain isolation, white labelling, scheduler, report generation, and enhanced rule chain capabilities. The key decision point is usually whether you need multiple customer environments on a single instance, or whether you need the scheduler for automated reports and periodic commands.

For cloud-hosted deployments without the overhead of self-managing the infrastructure, ThingsBoard Public Cloud offers both a free tier and paid plans starting at the Pilot level – useful for proof-of-concept work before committing to an on-premise rollout.

Getting started – a realistic path

The most practical route into a ThingsBoard SCADA deployment is to run a cloud trial on a representative subset of your field devices first. ThingsBoard’s Public Cloud free tier imposes no hard device limit on the Community Edition and is accessible without a credit card. Connect two or three devices via the IoT Gateway, build a basic dashboard, and test your alarm logic before touching production infrastructure.

From there, the same configuration – device profiles, rule chains, dashboard layouts – migrates directly to a self-hosted Professional Edition or Private Cloud instance. ThingsBoard calls this pilot-to-production portability a core design principle, and in practice it does hold up: there is no architectural rework required when moving from cloud trial to on-premise deployment.

For teams already using industrial cellular routers at remote sites, the IoT Gateway can be deployed as a Docker container on routers that support containerisation, or on a co-located edge device. Either way, the Modbus or OPC-UA polling configuration is done through a simple JSON file – no programming required.

Frequently asked questions