The SCADA conversation has changed
Five years ago, SCADA picks were Siemens WinCC vs Wonderware vs Ignition vs "the thing my system integrator already knows". The technical lines between options were genuinely meaningful. In 2026, the gap has narrowed for most use cases — the picks are now driven more by IT/OT integration story, licensing model, and openness, than by features.Here's how we'd think about it for a new factory.
Ignition (Inductive Automation)
Strengths: unlimited tags / clients / connections per server licence — a pricing model that actually scales without surprise audits. Web-deployed clients out of the box. Python-based scripting (Jython 2.7 historically; native Python in newer versions). Excellent OPC UA + MQTT story.Where we ship it: anything new. Greenfield projects, multi-site replication, anywhere the customer's IT team will be involved in operations. The licensing story alone has moved many of our customers off legacy stacks.
Trade-offs: not as deeply integrated with Siemens hardware as WinCC. If the entire installed base is Siemens and the maintenance team is Siemens-trained, the cost-of-switch isn't always worth the gain.
WinCC (Siemens — Classic / Unified / Open Architecture)
The "WinCC" name covers three quite different products. Quick disambiguation:- WinCC Classic — legacy, Windows-only, deeply embedded in Siemens factories. New deployments mostly avoid it.
- WinCC Unified — current generation, web-native, replaces Classic and TIA Portal HMI. Where Siemens is steering everyone.
- WinCC OA (Open Architecture) — large-scale, multi-server, used in CERN-class deployments. Different beast.
We ship WinCC Unified when the customer is committed to Siemens hardware end-to-end. The integration with TIA Portal projects is genuinely tight, the comms reliability is excellent, and the alarm/historian features are mature.
A custom stack — when it's the right call
React + Node + InfluxDB + Grafana + an OPC UA / MQTT gateway sounds like a developer self-indulgence and often is. But there are three cases where we've shipped it:- Customer's IT team is the maintenance team (rare, but real for newer manufacturers)
- The "HMI" is actually a customer-facing portal with an OT data feed
- Multi-tenant SaaS where the deployment crosses many small sites and per-site SCADA licensing dominates cost
Don't go custom for "it's not that hard". The historian alone — high-rate compression, retention policies, downsampling, queries at scale — is a nontrivial engineering product. We use TimescaleDB for this most often, with deliberate intent.
Comms layer choices that compound
- OPC UA — the modern default. Browse-able, secure (when configured correctly), supported by every serious PLC.
- MQTT (Sparkplug B) — for unreliable networks, distributed sites, IIoT-scale fan-out. Pairs well with Ignition.
- Direct PLC drivers (S7, EtherNet/IP) — fall back when OPC UA isn't on the controller. Still common on older hardware.
- REST / WebSocket — to PC-side applications, web HMIs, third-party dashboards. Always behind an OPC UA gateway, never directly to the PLC.
The historian is half the SCADA
SCADA without a working historian is a glorified HMI. Things to plan up front:- Tag rates — total tag-update / second across the system. Sized wrong and the historian is the bottleneck.
- Retention — how many years of full-rate data, how many years of downsampled data, what's the cold-storage path
- Query patterns — what reports does the business want, what cycle-time analysis does engineering want
- Backup story — historian data loss is irreplaceable. Backups, replication, and tested restores from day one.
One thing we no longer do
A SCADA on the same machine as the PLC programming workstation. The temptation to "just put it on the engineering laptop for now" turns into "the system has been running off Klaus's laptop for two years and Klaus left the company last week". Always a dedicated machine, virtualised or otherwise.What's your historian? TimescaleDB, InfluxDB, the historian baked into your SCADA, or something else?
