For water treatment installations across multiple smaller sites, traditional SCADA platforms are over-engineered and overpriced. We built a custom HMI using Moxa industrial devices, Elixir/OTP, and standard Modbus protocols — delivering the same monitoring and control at a fraction of the per-site cost, with no vendor lock-in and fully replaceable hardware.
When Vontech — an Australian manufacturer of ultrafiltration systems for water treatment — needed a monitoring and control interface for their equipment, the obvious answer was SCADA.
SCADA is the industry standard. It’s what every integrator recommends. It’s what the big water utilities use. And for a large plant running thousands of sensors across a complex process, SCADA makes sense.
But Vontech doesn’t install one massive plant. They install filtration systems across multiple smaller sites. And when you’re deploying monitoring to dozens of locations — each with a handful of sensors and a few membranes — the economics of SCADA fall apart quickly.
Read the full Project Aqua case study for the technical overview.
The SCADA Problem for Small-to-Medium Installations
SCADA platforms are designed for large-scale industrial operations. They’re powerful, mature, and comprehensive. They’re also:
Expensive to license. Most SCADA platforms charge per-tag (per data point), per-client, or per-server. For a single large plant, that licensing cost gets absorbed across thousands of monitored points. For a small installation with 8-10 sensors, you’re paying enterprise licensing fees for a fraction of the capability.
Expensive to deploy at multiple sites. Each site needs its own SCADA server or a connection back to a central server. Licensing multiplies. Infrastructure multiplies. Maintenance multiplies. When you’re deploying across 10, 20, 50 sites, the per-site cost becomes the dominant expense: not the hardware or the sensors.
Locked to the vendor. Once you commit to a SCADA platform, switching is painful. Your tags, your screens, your logic, your historian configuration: all proprietary. The platform vendor knows this, and prices accordingly. Every customisation deepens the lock-in.
Over-engineered for simple requirements. A water treatment filtration system with 8 sensors and 3 membranes doesn’t need enterprise process control. It needs real-time visibility, automated maintenance cycles, and alerting. SCADA gives you all of that, plus a thousand features you’ll never use and a configuration complexity that requires specialist integrators.
For Vontech’s deployment model (many sites, each relatively simple), we needed something different.
The Architecture We Built Instead
The design principle was straightforward: decouple the hardware from the software, use standard protocols, keep the per-site cost low, and make every component replaceable.
Moxa Devices as the Hardware Layer
At each site, Moxa industrial devices connect directly to the sensors. They read sensor data (pressure, flow rates, turbidity, temperature) and expose it via Modbus, the standard industrial communication protocol.
The Moxa devices are the hardware layer. They’re industrial-grade (designed for harsh environments, temperature extremes, vibration), widely available, and talk a protocol that every industrial device in the world understands.
This is the critical design decision: the Moxa devices are commodity hardware connected via a standard API. They’re not proprietary. If a device fails on site, the operator orders a replacement, connects it to the same sensors, points it at the same Modbus addresses, and the system picks it up. No specialist technician. No vendor callout. No proprietary configuration tool.
Compare that to a SCADA setup where a failed HMI panel might require the integrator to come on-site with their proprietary software to reconfigure the replacement.
Two Visualisation Options
The system supports two deployment modes depending on what the site needs:
Touchpanels for direct control. At sites where operators need hands-on control (triggering backwash cycles, acknowledging alarms, monitoring in real time), we deploy touchscreen panels running our custom HMI. The interface is purpose-built for industrial use: large touch targets for gloved hands, a dark theme that reduces glare under plant lighting, and a layout designed for the specific equipment being monitored.
Cloud services for remote monitoring and storage. For sites that don’t need on-site operators, or for centralised oversight of multiple locations, the same sensor data streams to cloud services. Historical data, trend analysis, alerting, and remote monitoring are all accessible from a browser, anywhere.
Both modes read from the same Modbus API on the same Moxa devices. The hardware layer doesn’t care how the data is consumed.
Why Elixir for Industrial Control
We built the software layer in Elixir running on the BEAM virtual machine (Erlang/OTP). This is an unconventional choice for industrial software, but it’s the right one for this application. Here’s why:
Fault tolerance is built into the language. Erlang/OTP was designed by Ericsson for telephone switches: systems that need to run 24/7 with no downtime. The “let it crash” philosophy means individual processes can fail and restart without bringing down the system. A sensor connection drops? That process restarts and reconnects. The rest of the system keeps running. This matters when your software is controlling water treatment equipment in an unmanned facility.
Real-time communication at low cost. Phoenix WebSockets give us real-time sensor data streaming to every connected display with minimal overhead. When a pressure reading changes, every touchpanel and every cloud dashboard sees it within milliseconds. Elixir handles hundreds of concurrent WebSocket connections on hardware that would struggle to run a traditional SCADA server.
Low CPU requirements. The BEAM VM is remarkably efficient for concurrent, I/O-heavy workloads. That is exactly what industrial monitoring is. Reading from dozens of Modbus registers, processing the data, broadcasting to connected clients, and logging to storage. Elixir does this on a fraction of the CPU that a comparable Java or .NET SCADA application would need. That means the on-site hardware can be smaller, cheaper, and lower-power.
Latency is acceptable for the use case. Elixir isn’t a hard real-time system. For applications that need microsecond response times (robotic control, high-speed manufacturing), you need something closer to the metal. But water treatment operates on a different timescale. Membrane backwash cycles run for minutes. Pressure changes happen over seconds. The slight latency overhead of running on the BEAM is invisible in this context, and the trade-off buys you fault tolerance that would cost ten times as much to build in C or C++.
The Economics
We’re not going to name specific SCADA platforms or quote their pricing. But the cost structure comparison is straightforward:
Cost Comparison: SCADA vs Custom HMI (Per Site)
| Cost Factor | Traditional SCADA | Custom HMI |
|---|---|---|
| Software licensing | Per-tag/server fees, annual renewal | None. No per-tag fees, no renewals |
| Integration | Specialist SCADA integrator required | Standard Modbus configuration, no specialist needed |
| Hardware | Industrial PC or dedicated SCADA server | Off-the-shelf Moxa devices + commodity touchpanel |
| Maintenance | Annual vendor support contract | Commodity hardware, swappable. Remote software updates |
| Scaling | Multiply all costs for each new site | Marginal cost per site is hardware only |
| Customisation | Every change through the integrator | Direct software modification, no intermediary |
| Vendor lock-in | Proprietary. Switching means starting over | Modbus is open standard. Hardware is commodity. Software is yours |
For a single large installation, the cost difference might not justify the development investment. But for a manufacturer like Vontech who deploys across many sites, the per-site savings compound quickly. By the fourth or fifth installation, the custom system has paid for itself. Every site after that is pure saving.
What the Operators Actually Got
Beyond the economics, the operators at each site got an interface designed specifically for their equipment and their workflow:
- Real-time monitoring of 8 sensors across a 3-membrane filtration system on a single screen
- One-touch backwash replacing complex manual procedures that previously required referencing a paper manual
- Scheduled maintenance automation: configure it once and the system runs maintenance cycles on its own
- Intelligent alerting that warns before problems become failures, not after
- Glove-friendly interface with large touch targets designed for industrial environments
A SCADA system could do all of this. But it would require a SCADA integrator to build the screens, configure the logic, and maintain the system. The custom HMI does it out of the box, designed for exactly this equipment and exactly this workflow. This is one example of how we approach systems integration and automation.
When SCADA Still Makes Sense
We’re not anti-SCADA. For a large water treatment plant with thousands of sensors, complex process control, regulatory reporting requirements, and an existing operations team that knows SCADA, it’s the right choice. The ecosystem is mature, the tools are proven, and the scale justifies the cost.
Where SCADA doesn’t make sense:
- Small-to-medium installations where licensing costs dwarf the monitoring requirements
- Multi-site deployments where per-site costs multiply
- Equipment manufacturers who need an interface that ships with their product
- Any scenario where vendor lock-in is a concern and future flexibility matters
For those situations, a custom HMI built on standard protocols, commodity hardware, and fault-tolerant software delivers the same monitoring and control at a fraction of the long-term cost.
Frequently Asked Questions
When should you use a custom HMI instead of SCADA? A custom HMI makes sense for small-to-medium installations with under 50 sensors, multi-site deployments where per-site licensing costs multiply, and equipment manufacturers who need an interface that ships with their product. SCADA remains the right choice for large plants with thousands of sensors and complex process control requirements.
What is Modbus and why does it matter for industrial monitoring? Modbus is the standard industrial communication protocol used by virtually every sensor and PLC in the world. Building on Modbus means the monitoring system works with any standard industrial hardware, with no proprietary lock-in to a specific vendor.
Why use Elixir for industrial control software? Elixir runs on the BEAM virtual machine (Erlang/OTP), originally built by Ericsson for telephone switches requiring 99.999% uptime. It provides built-in fault tolerance where individual processes can crash and restart without affecting the rest of the system, handles hundreds of concurrent connections on low-power hardware, and uses a fraction of the CPU of traditional SCADA server software.
What happens if a Moxa device fails on site? The operator orders an off-the-shelf replacement, connects it to the same sensors and Modbus addresses, and the system picks it up automatically. No specialist technician, no vendor callout, no proprietary reconfiguration tool required.
Building industrial equipment that needs a monitoring interface? We’d like to hear about it. Our senior engineers have built control systems for environments where uptime isn’t optional.
Book a free 30-minute call → — no pitch, just a conversation with the engineers who built this.