Walk into a SCADA control room at most Queensland mine sites and you’ll find the same thing: a rack of ageing Dell servers running Windows Server 2008, a Citect or FactoryTalk installation that hasn’t had a major version update in a decade, and a growing awareness that replacing any of it is going to be a significant undertaking.
SCADA virtualisation, running your SCADA servers as virtual machines on modern host hardware, is how most large sites are addressing this without the full-scale rip-and-replace. This article explains what it actually involves, where it works well, and where the complexity lies.
What virtualisation means in an OT context
In an IT context, virtualisation is routine. In OT, it introduces complications that don’t exist in the server room.
An OT SCADA system is not just a software application. It has real-time communication obligations to PLCs, timing requirements on scan cycles, and in many cases, physical I/O connections via serial or hardwired interfaces. Running it as a virtual machine means those real-time obligations have to be met by a hypervisor layer that introduces its own overhead.
For most modern SCADA platforms (FactoryTalk View SE, CitectSCADA, PlantSCADA, Ignition), virtualisation is fully supported and works reliably on VMware vSphere or Hyper-V, provided the host hardware is appropriately specified. The SCADA vendors each publish virtualisation guides with minimum specifications, supported hypervisors, and configuration recommendations. Following these is not optional.
The most common mistake in OT virtualisation projects is under-specifying the host hardware. A SCADA server that ran adequately on dedicated hardware may perform poorly as a VM on a host that is also running five other VMs, particularly if the host’s CPU and memory are undersized. Size for headroom, not just current load.
The typical migration path
Most sites arrive at virtualisation via one of two routes:
- A planned SCADA version upgrade that requires newer hardware, where the opportunity to virtualise is taken at the same time
- Ageing physical servers approaching end of life, where the hardware replacement triggers the virtualisation decision
In either case, the migration generally follows this sequence:
- Procure and configure the host hardware: typically a rackmount server with sufficient CPU, RAM, and storage for the number of VMs planned, plus headroom for growth
- Install the hypervisor (VMware ESXi is most common in OT; Hyper-V is used where the site’s IT team manages the infrastructure)
- Create the virtual machines, each with the appropriate CPU cores, RAM allocation, and disk configuration for the SCADA role
- Install the SCADA software into each VM, migrate the project files, configure communications, and license the software
- Test extensively in the VM before cutting over from physical hardware: validate scan times, I/O communications, alarm and trending behaviour
- Cut over during a planned maintenance window
Primary and backup server architecture
Most industrial SCADA systems support a Primary/Standby server architecture: two SCADA servers running simultaneously, with the standby taking over automatically if the primary fails. In a virtualised environment, these two VMs should run on different physical host servers. Running both on the same host defeats the purpose of the redundancy.
Where a site has a VMware vSphere cluster, VM High Availability (HA) and Fault Tolerance features can be configured to automatically restart failed VMs on surviving hosts. For SCADA servers, HA restart is generally acceptable; Fault Tolerance (which maintains a live shadow VM) has overhead that may not be justified for most SCADA applications.
Rockwell licensing and virtual NICs
Rockwell ActivIDs are tied to the network interface card (NIC) of the machine they are activated on. In a VM, the NIC is virtual, and by default the MAC address changes each time the VM is moved or recreated, which invalidates the licence.
The solution is to set the VM’s virtual NIC MAC address to a fixed value, and to install Rockwell’s VirtNet Network Adapter inside the VM. This creates a stable virtual network interface that Rockwell’s licence manager binds to. This step is frequently overlooked and causes licence failures post-migration.
Document your ActivID activations before migrating. If you need to deactivate and reactivate licences as part of the migration, allow time for Rockwell’s deactivation process: it is not instant.
ThinManager and thin client deployments
Where a site is also deploying ThinManager for operator thin-client terminals, the ThinManager server typically runs as a VM alongside the SCADA servers. Thin clients boot from the network, authenticate with ThinManager, and display a FactoryTalk View SE client session served from the SCADA VM.
This architecture significantly reduces the hardware footprint in control rooms: instead of a full PC at each operator station, a small thin client terminal with no local operating system or software. Replacement of a failed terminal takes minutes. Software updates are applied once, to the SCADA VM, and immediately reflected on all terminals.
Where we have applied this
Virtualisation of SCADA infrastructure has featured in several projects in Dennis Murphy’s career, including SCADA virtualisation scoping and assessment work for Mackay Sugar, virtualised SCADA environments at QCoal Cook CHPP and QGC water treatment plants, and Glencore’s OT domain virtualisation programme at Hail Creek and Rolleston, which involved migrating servers from the old IT-managed domain into a dedicated OT vSphere cluster under the OT.NET domain.
In each case, the driver was the same: physical hardware approaching end of life, SCADA software on unsupported Windows versions, and no straightforward path to in-place upgrade. Virtualisation provided a clean migration path with a predictable hardware lifecycle going forward.
About the author
Dennis Murphy RPEQ is the principal engineer at Beetle Engineering & Automation, based in Mackay, Queensland. He specialises in PLC and SCADA engineering, OT network architecture, and OT cybersecurity across Queensland’s mining and industrial sectors. Contact: dennis.murphy@beetle.engineering