Software-defined automation is becoming a serious direction in industrial control, but the term only matters when it can be tied to measurable performance.

To evaluate what this means in practice, OTee tested 16 Virtual PLC runtimes running simultaneously on an 11-year-old enterprise server. Each runtime executed a continuous benchmark workload designed to simulate a larger PLC-style program.

The result: low CPU utilization, controlled cycle-time jitter, and scan-time performance at approximately 25% of a high-performance hardware PLC reference platform for this specific benchmark.

In the updated test, after improvements to OTee’s vPLC runtime and performance tuning approach, the same 16-runtime setup maintained approximately 0.5 µs average cycle-time jitter and 7.5 µs maximum cycle-time jitter, even while additional disk and network load were introduced on the host.

This article explains what was tested, what changed in the updated benchmark, and why the result matters for software-defined automation.

Executive Summary: Virtual PLC Benchmark Results

The most important point is not only the scan-time result. It is the combination of low CPU usage, multiple simultaneous runtimes, and controlled jitter on older hardware.

Why This Benchmark Matters for Software-Defined Automation

Most discussions around software-defined automation focus on flexibility: less dependence on fixed controller hardware, easier deployment, faster updates, and more scalable system management.

Those benefits are relevant, but they do not answer the first question many engineers ask:

Can the control runtime execute predictably?

That is the question this benchmark addresses.

A Virtual PLC should not be described as “PLC software running on any computer.” That description is too loose for industrial automation. A credible Virtual PLC deployment depends on the full execution stack: runtime design, operating system behavior, process scheduling, compute hardware, I/O communication, network architecture, workload isolation, update strategy, monitoring, recovery behavior, and application-specific validation.

This benchmark does not evaluate every part of that stack. It focuses on one specific area: how OTee’s Virtual PLC runtime behaves under sustained computational load when multiple runtimes share the same host.

Benchmark Setup: Hardware, Runtime, and Workload

The benchmark was performed on an 11-year-old enterprise server equipped with a 12-core Intel Xeon E5-2690 v3 CPU.

OTee ran 16 Virtual PLC runtimes at the same time. Each runtime continuously executed a benchmark program consisting of 100,000 REAL multiplications.

The workload was selected to create sustained computational demand. It was not a small demonstration cycle, and it was not a single runtime running alone on an otherwise idle machine.

The server used a PREEMPT_RT real-time Linux kernel, RT process priority, and tuning of selected background services. Beyond that, the host was still not heavily tuned.

This matters because the result was not produced on new hardware or through extensive system optimization. It was a practical setup: older enterprise hardware, real-time Linux, runtime prioritization, and targeted performance tuning.

Virtual PLC Performance Results

CPU Utilization

CPU usage remained low throughout the test.

Each CPU core typically operated around 5–10% utilization and stayed below 20%, even with 16 Virtual PLC runtimes active.

That indicates meaningful compute headroom on the host. In a software-defined automation architecture, this matters because one practical question is whether multiple control runtimes can share infrastructure efficiently without consuming excessive resources.

Scan-Time Performance

In this benchmark, the OTee Virtual PLC runtimes completed the workload at approximately 25% of the scan time observed on a high-performance hardware PLC reference platform.

For this specific benchmark program, that corresponds to roughly 4x faster execution.

It does not mean every Virtual PLC workload will always execute four times faster than every hardware PLC. It means that in this defined benchmark, using this workload and this comparison point, OTee’s Virtual PLC runtime executed the program substantially faster.

Cycle-Time Jitter

The observed cycle-time jitter was:

• ~0.5 microseconds average

• ~7.5 microseconds maximum

For industrial automation, fast execution is not enough. A runtime also needs repeatability. If execution timing varies too much from cycle to cycle, raw speed becomes less useful.

In this benchmark, the Virtual PLC runtimes maintained controlled jitter while executing sustained workloads across 16 simultaneous instances.

That is a relevant result for software-defined automation because timing behavior is often one of the first concerns engineers raise when control logic moves from dedicated controller hardware to general-purpose compute infrastructure.

The server was not kept completely idle during the test.

The server was not kept completely idle during the test.

While the 16 Virtual PLC runtimes were running, software packages were also installed on the same machine. That introduced additional CPU, storage, file system, and network activity.

The maximum observed jitter remained at 7.5 microseconds

This should not be interpreted as a recommendation to mix unrelated workloads freely in a production control environment. Production systems need clear rules for workload isolation, update handling, access control, monitoring, and recovery.

The point is narrower: the runtimes did not become unstable simply because the host had additional work to do.

For software-defined automation, this is an important observation. Runtime performance should not only be evaluated under ideal conditions. It should also be tested in ways that reveal how scheduling, prioritization, and resource handling behave when the host is active.

What the Benchmark Shows About OTee’s Virtual PLC

This benchmark is not just a performance exercise. It is evidence for a larger shift already taking place in industrial automation: control logic is gradually becoming less tied to fixed controller hardware and more dependent on software-defined execution environments.

Industry analysts describe Virtual PLC technology as part of the move toward industrial software-defined automation, where software-based controllers can run on standard compute infrastructure such as industrial PCs or servers. ARC Advisory Group places Virtual PLCs directly under this software-defined automation category, while IoT Analytics describes vPLCs as a shift away from control logic being tightly coupled to vendor-specific hardware

For OTee, the benchmark adds measured evidence to that shift. Sixteen OTee Virtual PLC runtimes ran simultaneously on older enterprise hardware with low CPU utilization, strong scan-time performance, controlled cycle-time jitter, and stable behavior while the host handled additional activity.

This is where OTee’s Virtual PLC should be understood beyond the benchmark. OTee is already applying its technology in mission-critical industrial operations, including industrial use cases where control systems are expected to run continuously, behave predictably, and support operational continuity. In these environments, a Virtual PLC cannot be evaluated only as software. It has to be evaluated as part of a complete automation architecture: runtime, compute infrastructure, I/O communication, monitoring, cybersecurity, update handling, and recovery strategy. 

Why This Result Matters for Virtual PLC Deployment

First, it shows that a Virtual PLC can scale beyond a single runtime. A lot of discussions around vPLCs stay theoretical or focus on one isolated instance. Running 16 runtimes simultaneously gives a much more useful view of consolidation potential and resource efficiency.

Second, it shows that older hardware is already capable. This was not a modern, top-tier system. It was an 11-year-old server. That makes the result more practical, because it suggests that strong Virtual PLC performance does not necessarily depend on the newest hardware available.

Third, it strengthens the case for edge-based Virtual PLC deployment. A common misconception is that virtualized control automatically means cloud control. In practice, serious industrial control discussions increasingly emphasize the importance of deterministic local execution and the underlying technology stack needed to support it.

Taken together, the benchmark shifts the discussion from whether control logic can run in software to a more useful question: how the runtime behaves when scaled, how much compute headroom remains, and whether the architecture can support predictable execution close to the equipment.

Reliability Considerations for Software-Defined Control

Performance is one part of the evaluation. Reliability is another.

A Virtual PLC deployment depends on the complete execution environment: compute hardware, operating system, runtime behavior, I/O communication, redundancy strategy, cybersecurity model, update process, and recovery behavior.

The benchmark ran on enterprise-grade server hardware. Systems in this class commonly support features such as server-class CPUs, ECC memory, storage redundancy, and redundant power supplies.

Those features are relevant, but they are not a substitute for engineering validation.

The conclusion is not that a server is better than a PLC. The conclusion is that reliability must be assessed at the architecture level.

This is also how OTee approaches Virtual PLC technology: as part of a complete automation architecture, not as a shortcut around the engineering work required for industrial control.

What This Means for the Future of Virtual PLC Technology

This benchmark points to a larger shift in industrial control: software-defined automation is becoming practical when the runtime, hardware, operating environment, and deployment model are engineered together.

Running 16 OTee Virtual PLC runtimes on an 11-year-old server with limited tuning shows that modern vPLC architecture has meaningful performance headroom. On newer hardware and with more optimized configurations, that headroom is likely to increase.

The result should still be read responsibly. It does not replace application-specific validation, and it does not mean every control workload should move to a Virtual PLC. Timing requirements, I/O architecture, redundancy, cybersecurity, and recovery behavior all still need to be evaluated.

But it does shift the conversation. Virtual PLC technology should not be judged by assumptions about software-based control. It should be judged by measured runtime behavior.

For OTee, that is the practical direction of software-defined automation: flexible control logic, suitable local execution, and engineering validation where performance and reliability matter.