Designing the Virtual Environment Around the SCADA System, Not Just the SCADA Software
At Nor-Cal Controls, one of the most common conversations we have with EPCs, owners, and IT teams during SCADA design is surprisingly simple:
“What is the sizing requirement for our servers to meet SCADA specification requirements?”
On the surface, this seems like an easy question. A typical SCADA system may consist of a few virtual machines running Windows Server, Ignition, a database, historian services, engineering tools, and various communications applications. It can be tempting to look at the published minimum requirements for each application, add them together, and select a server configuration that appears to have enough capacity.
In our experience, that approach can lead to problems
A utility-scale SCADA system is not simply an Ignition installation running on Windows. It is an ecosystem of applications, services, communications, databases, historians, redundant gateways, virtual machines, and infrastructure that must operate reliably around the clock. When we design a SCADA system, we therefore look at the entire virtual environment, not just the requirements of an individual application.
This becomes especially important as a project grows from a relatively simple SCADA installation into a large system with multiple Ignition Gateways, redundant servers, extensive tag counts, historians, databases, engineering workstations, and multiple back-end services.
The Difference Between Minimum Requirements and a Real SCADA Environment
Modern SCADA software generally has relatively modest minimum hardware requirements.For example, Ignition’s current published requirements list a dual-core processor, 4 GB of RAM, and 10 GB of available storage as baseline requirements, while also noting that requirements vary depending on usage. Those numbers are useful—but they should not be interpreted as a recommended specification for a large utility-scale deployment.
A small system with a few hundred field devices and a limited number of clients is fundamentally different from a multi-node SCADA environment collecting data from thousands of devices, maintaining historical data, supporting multiple Gateway services, and simultaneously running databases and other applications. Inductive Automation’s guidance for virtualized Ignition environments makes this distinction clear: a small system might require only a handful of vCPUs and several gigabytes of RAM, while a very large system can require dozens of vCPUs and 64 GB of RAM or more. This is why we don’t size SCADA virtual machines based solely on the software installer. We size them based on the top end expected workload, expected operator involvement, and historical data collection and retention requirements, which can significantly change those listed resource requirements.
What Actually Runs on a SCADA Server
One of the biggest mistakes we see is treating a SCADA server as if it is running one application.
A typical utility-scale SCADA environment can include: an Ignition Gateway, Ignition Perspective sessions, Tag providers, Historical data collection such as Canary or Timebase, Reporting and FTP services, Windows services, Antivirus & Cybersecurity Tools”such as SEL AcSELerator, Crimson, Machine Edition, or Studio5000.
Each application consumes resources, and the resources aren’t necessarily consumed in the same way. Some applications are CPU-intensive, while others require significant memory. As an example, Databases tend to benefit from fast storage and sufficient memory, and Ignition Gateways can require additional memory depending on the number of tags, devices, clients, modules, scripts, and historical data being processed. That means simply saying, “Ignition requires 4 GB of RAM,” doesn’t tell us what a production SCADA server needs, this is just the base minimum to run the application.
Why We Commonly Start With R470s for Smaller Systems
For many of the basic SCADA systems we design, a Dell PowerEdge R470 is an excellent starting point. The R470 provides a compact enterprise-class platform with substantial processing, memory, and virtualization capability. Dell specifically lists Windows Server with Hyper-V among its supported operating environments for the R470. For a relatively straightforward SCADA deployment, we commonly see an architecture built around: 1–2 physical Hyper-V nodes with multiple virtual machines distributed across those nodes.
A simplified environment might include:
VM 1 — SCADA Server
- Ignition Gateway
- Engineering/PPC Software
- Tag processing/historization software
- HMI/Perspective services
VM 2 — Historian/Database
- SQL Server or similar Historical database software
- Reporting applications
VM 3 — Domain Controller
Windows Domain Controller
The advantage of virtualization is that we don’t need to dedicate an entire physical server to every application. Instead, the Hyper-V cluster provides a pool of resources that can be allocated where they are needed. This resource pool is generally sourced from the Nodes and paired with a NAS to host the additional drive storage. For smaller systems, a 1- or 2-node R470-based environment can provide a very practical balance between cost, performance, and redundancy.
When R470s Stop Being Enough
As the SCADA system grows, the limiting factor is often not the SCADA software itself, but rather the number of applications and services that need to coexist within the virtual environment.
A larger renewable energy facility may have: Multiple Ignition Gateways, Redundant SCADA servers, Multiple historians, and hundreds of field devices. At that point, we’re no longer designing a simple SCADA server. This is where we generally start looking toward higher-capacity platforms such as the Dell PowerEdge R670.
The R670 is designed for substantially larger enterprise workloads and supports Windows Server with Hyper-V, along with other virtualization platforms.
For larger SCADA environments, we commonly recommend 2–3 or more physical nodes rather than trying to force everything onto a single or two-node architecture. The reason isn’t simply “more horsepower.” The Solution is focused on resource availability, redundancy, scalability, and operational flexibility.
The Importance of Multiple Hyper-V Nodes
Redundancy is one of the biggest reasons we move from a smaller two-node environment toward a three-node or larger architecture. Imagine a SCADA system running on two physical hosts. If one host fails, the remaining host needs enough capacity to absorb the workloads that were running on the failed machine. That means the cluster cannot simply the aggregate workload, be sized for normal operation. It needs to be sized for failure operation. This is one of the most important concepts in virtualized SCADA design. If the normal workload consumes 70–80% of available resources, a node failure can push the remaining server beyond its comfortable operating range.
At Nor-Cal, we prefer to leave sufficient capacity for the system to continue operating during abnormal conditions rather than designing a cluster that only works efficiently when every component is healthy.
Why Multiple Ignition Gateways Change the Equation
One of the biggest inflection points in SCADA server sizing occurs when a project begins using multiple back-end Ignition Gateways.
A single Ignition Gateway may be relatively easy to size. Several Gateways supporting different functions are a different story. For example, a larger SCADA architecture may contain: (1) Primary ‘Front End’ Ignition Gateway, and (2-5) ‘Back End’ Gateways.
The Front End Gateway prioritizes the HMI and operations performance, while the Back End Gateways focus on device connection and tag collections from hundreds of field devices. This setup creates additional network traffic, CPU utilization, memory requirements, storage activity, and database transactions. The virtual infrastructure therefore needs to be designed around the aggregate workload, not the individual Gateway requirements.
Ignition itself recommends that Gateway memory be sized according to actual system behavior and workload rather than simply allocating all available server memory to the application. The underlying host still needs sufficient resources, and those resources must be shared appropriately among all of the VMs.
Designing for the Worst Day, Not the Average Day
This is perhaps the most important philosophy we bring to SCADA infrastructure design. A power plant doesn’t care whether its SCADA system performs well during an average afternoon. It needs the system to work when something goes wrong.
Imagine a communications network failure that causes hundreds of devices to reconnect simultaneously. That event can create a temporary resource spike. Or imagine a major plant event that causes thousands of alarms to arrive within a short period. Or a historian catches up after a communications outage and suddenly must process a large backlog of buffered data. These situations can create workloads that are dramatically different from normal operation. This is why we don’t design virtual environments based exclusively on average CPU utilization. We design with operational headroom.
Scaling the Architecture as the Plant Grows
Another important consideration is future expansion. A SCADA system designed for today’s plant may eventually need to support additional PV blocks, Battery Energy Storage Systems, New market interfaces, Expanded historian requirements, Additional operator clients.
The virtual environment should have a path for growth. This is one of the advantages of using a Hyper-V architecture. Rather than replacing the entire SCADA platform when the workload increases, we can often add resources or additional nodes to the environment. Dell’s current PowerEdge platforms are explicitly designed for virtualization workloads, and the R470 and R670 both support Microsoft Windows Server with Hyper-V. That gives project teams flexibility to scale the underlying infrastructure as the SCADA system evolves.
A Practical Approach We Use at Nor-Cal
When we’re sizing a virtual SCADA environment, we typically work through several questions.
1. What applications are required?
We identify every service that will run in the environment—not just Ignition.
2. How many Ignition Gateways are required?
A single Gateway is very different from distributed architecture with multiple Back End Gateways.
3. How many devices and tags will be connected?
The number of devices, tags, scan rates, alarms, scripts, and historical data points all influence resource requirements.
4. What type of redundancy is required?
Does the plant require one-node fault tolerance? Can the system operate with one physical host offline?
These questions directly affect the number and size of Hyper-V nodes.
5. What is the expected growth?
We want to understand what the system looks like not only on Day One but five or ten years into the plant’s operating life.
The Bottom Line: Size the Infrastructure, Not the Software
There is nothing inherently wrong with starting with the minimum published requirements for an application. The problem occurs when those minimums become the final design specification. A utility-scale SCADA environment is much more than a software installation. It is an operational technology platform that has to integrate communications, databases, historians, HMIs, engineering tools, cybersecurity services, redundancy, and multiple applications—often across several virtual machines.
For basic systems, an R470-based Hyper-V environment with one or two nodes can provide an excellent foundation.
As the system grows, particularly when multiple Back End Ignition Gateways and additional SCADA applications are introduced, a more robust environment becomes necessary. At that point, R670-class infrastructure with two, three, or more nodes can provide the processing capacity, redundancy, and scalability needed to keep the system healthy.
The exact configuration will always depend on the project. There is no universal “SCADA server specification.” And that’s precisely why we believe server sizing should be treated as part of the SCADA engineering process.
At Nor-Cal, we look at the entire architecture: the applications, communications, device count, historian requirements, redundancy strategy, expected growth, and failure scenarios. The objective isn’t to build the biggest virtual environment possible. It’s to build an environment that has enough capacity to perform reliably today, enough headroom to handle abnormal conditions, and enough scalability to support the plant tomorrow.
Because when the SCADA system is responsible for monitoring and controlling a critical power facility, “it meets the minimum requirements” isn’t the standard we’re aiming for. We aim to deliver a reliable, resilient, and properly engineered SCADA System for our customers. Planning your next project? Reach out today to ensure your virtual infrastructure is built for long-term performance and reliability.