Performance Evaluation of a Cloud-Native Open-Source Power System Digital Twin for Real-Time Simulation

Abstract

The increasing complexity of Cyber-Physical Energy Systems, driven by the high penetration of power electronics, advanced control, and digitalization, demands scalable, flexible real-time simulation platforms beyond traditional laboratory-based solutions. This paper investigates the feasibility of deploying open-source real-time power system simulation frameworks on cloud-based infrastructures while meeting real-time computational constraints. An open-source architecture based on DPsim and the VILLAS framework is implemented and evaluated across five computing environments using open-source tools: bare-metal, non-cloud virtual machines, private cloud Kubernetes clusters, public cloud virtual machines, and public cloud Kubernetes clusters. Each environment is carefully configured and tuned using real-time operating systems, CPU isolation, and affinity mechanisms to improve deterministic behavior. Performance and scalability are assessed through a benchmark based on replicated IEEE 9-bus systems, progressively increasing system size, and measuring simulation-timestep execution time. The results show that cloud and cloud-like infrastructures can support soft and, under controlled conditions, firm real-time simulation tasks, although achievable system scale decreases as additional abstraction layers are introduced. The study identifies practical performance limits for each infrastructure and discusses their suitability for different real-time simulation and co-simulation applications. These findings demonstrate that cloud-based real-time simulation can complement traditional digital real-time simulators, enabling scalable and cost-effective CPES experimentation.

1. Introduction

The electric sector is undergoing rapid, multifaceted changes driven by technological advances and regulatory policies. These shifts are steering the industry toward next-generation energy networks [1,2,3]. Ongoing innovations increasingly emphasize objectives such as decarbonization, decentralization, digital transformation, and the democratization of energy systems. These aims often require integrating advanced hardware and software solutions across multiple layers of the energy grid. A critical framework for such integration is the Smart Grid Architecture Model (SGAM), which supports interoperability across various domains [4]. In this context, the SGAM’s cyber-physical perspective—commonly referred to as Cyber-Physical Energy Systems (CPESs)—underscores the necessity for coordinated operation between physical components and information technologies.

The complexity inherent in these interconnected systems necessitates a shift in how validation and testing are conducted, ensuring a harmonized transition that holistically addresses this process rather than relying on the traditional component-level approach. A CPES has three main components: the physical system, the distributed computing applications, and the communication network between the devices and the computing infrastructure. This is particularly relevant for advanced control systems, which require comprehensive simulations that encompass both system dynamics and communication behaviors.

The concept of digital twins has been widely explored by the scientific community to represent different physical systems through virtual models that enable real-time monitoring, simulation, and optimization [5,6,7]. In power systems, digital twins have recently gained attention as a means of capturing the dynamic behavior of electrical networks and supporting advanced monitoring and operational analysis [8,9]. Several studies have also discussed the potential applications and challenges of digital twins in smart grids and energy systems [10,11,12]. Large-scale research initiatives such as TwinEU [13] further highlight the importance of integrating digital twin technologies for system-level analysis and the evaluation of emerging grid technologies. Real-time simulation is often considered a core component of these architectures, enabling synchronized evolution between the physical and virtual systems [14].

At the same time, the increasing deployment of power electronics and other advanced technologies introduces new dynamic phenomena in power systems [15], often requiring wide-area electromagnetic transient analysis to ensure system security [16,17]. The validation of such models increasingly relies on advanced experimental techniques such as hardware-in-the-loop (HIL) and power hardware-in-the-loop (PHIL) testing [18,19].

To support this ecosystem, holistic test methodologies have emerged, underpinned by the availability of advanced digital real-time simulators (DRTSs) [20,21,22,23]. These platforms are central to CPES research, particularly for experiments involving high levels of renewables, automation, and communication dependencies [24]. However, the commercial nature and high cost of most DRTSs present significant barriers, especially for research groups in resource-constrained environments.

In response, several initiatives have emerged to use non-commercial software for real-time simulation, but they provide limited support for large numbers of nodes [25,26]. Recently, an open-source framework architecture for real-time simulation and co-simulation is being developed [27], enabling the inclusion of affordable digital twins in CPES experimentation.

In small-scale experiments, off-the-shelf multicore computers with properly tuned real-time guest OS kernels may provide sufficient computing capacity for the described architecture [28]. However, scaling to large-scale systems in real-time simulation is infeasible without sufficient computational and network resources. High-Performance Computing infrastructure might also be expensive to buy and maintain. Still, public cloud providers nowadays allow renting and scaling up computational resources practically and affordably to set up almost any required infrastructure for a particular experiment. Additionally, several cloud computing simulations have been developed for large-scale systems [29,30]; however, they do not focus on real-time simulations or on hardware interaction.

Real-time simulation is a key enabler of power system digital twins, as it allows the virtual model to evolve synchronously with the physical system using measurement data. This capability enables functions such as real-time monitoring, predictive analysis, and the evaluation of control or optimization strategies within a digital representation of the grid.

Although real-time and cloud computing may sound like an oxymoron due to virtualization’s `random’ latencies, recent contributions focused on obtaining deterministic behavior in hypervisors [31] and containers [32] have allowed envisioning the implementation of real-time simulation in the cloud, which is the main objective of the proposed work.

The contributions of this paper are threefold. First, it proposes and implements a cloud-native, open-source real-time simulation architecture for power systems, based on DPsim and the VILLAS framework, and demonstrates its deployment across heterogeneous computing environments, including bare-metal servers, virtual machines, private cloud Kubernetes clusters, and public cloud infrastructures. Second, it provides a systematic performance evaluation of these environments under real-time constraints, quantifying the impact of virtualization and containerization layers on worst-case latency and achievable simulation scale through reproducible benchmarking using a scalable IEEE 9-bus test system scaled up to an 810-bus system. Third, the paper identifies practical limits and suitable application domains for cloud-based real-time power system simulation, clarifying which classes of real-time and co-simulation applications can be supported under different infrastructure configurations. Together, these contributions provide concrete guidance for researchers seeking cost-effective, scalable alternatives to commercial digital real-time simulators for experimentation with Cyber-Physical Energy Systems.

The remainder of this paper is organized as follows. Section 2 reviews the main considerations for real-time power system simulation. Section 3 presents the proposed open-source framework architecture. Section 4 describes the benchmark test case and the experimental setup used to evaluate computational performance across different infrastructures. Section 5 discusses the simulation results and outlines potential applications of cloud-based real-time simulation. Finally, Section 6 summarizes the main conclusions and identifies directions for future work.

2. Real-Time Power System Simulation

A digital twin is a virtual representation of a physical system that enables analysis and supports operational decision-making [12,33]. A key requirement is the ability to exchange data bidirectionally with the physical system, enabling continuous updating of the digital model using real-world measurements [11]. In the context of power system real-time simulation, a digital twin can be conceptualized as a three-layer architecture: the physical power system, a communication layer responsible for exchanging measurements and control signals, and a digital simulation layer that reproduces system dynamics and supports monitoring and analysis. In this paper, we primarily focus on the real-time simulation requirement, which enables data exchange with the real world.

For a simulation to be considered real-time, it must replicate the fastest dynamics of the phenomena of interest. In this sense, a real-time application must process or solve system equations without affecting the dynamics of interest in the analysis. A real-time application is a task that must be completed before a deadline [31]. This means that time constraints govern their execution and interaction within the system. If there are multiple execution steps, they must meet their deadlines, and the system’s application performance depends on this.

2.1. Power System Real-Time Simulation Applications

Real-time simulation applications in power systems are implemented in different configurations with varying scopes, where in some cases it is possible to interact with physical equipment and in others only with software. The most well-known are Software in the Loop (SIL) or model in the Loop (MIL), Rapid Control Prototyping (RCP), Hardware in the Loop (HIL), and Power Hardware in the Loop (PHIL) [23].

Some possible dynamics tested in the different configurations are Real-Time Power System Dispatch, Automatic Generation Control, Primary Control, Wide Area Monitoring and Protection algorithms, Equipment Protection, and Power Electronics Controls, among others [20,23,34].

Figure 1 presents the possible dynamics and the frequency of interest that generate the time-step constraints to achieve the desired dynamics for the application.

2.2. Power System Open-Source Software

There are several open-source software packages for power system simulation, designed for different purposes, such as power-flow [35], phasor-domain [36], and EMT simulation [37]. Nonetheless, most of them do not focus on meeting real-time requirements.

Currently, open-source real-time simulations developed by [27,38,39,40] are available, enabling real-time deployment on general-purpose computers using real-time operating systems. Its framework is composed of two software tools: (1) DPsim, a real-time capable solver for power systems that operates in the dynamic phasor and electromagnetic transient (EMT) domain, and (2) VILLASnode, a gateway for simulation data and measurements with a variety of interfaces to existing real-time simulation targets as well as adapters to commonly used protocols. Both software are suitable for virtualization, containerization, and deployment in cloud-like and cloud environments.

DPsim is an open-source, real-time power system simulator that supports various dynamics, including EMT, dynamic phasor, and continuous power flow. It solves the linear network equation using the Modified Nodal Analysis with a non-iterative technique [40]. This software is optimized to meet real-time constraints across different power system models and to integrate the CIM [41] format as native input, enabling interaction with multiple software packages that support this standard and the exchange of data parameters with the real world.

The VILLAS Framework was developed to couple testbed and real-time simulators in geographically distributed laboratories [39,42,43]. This framework has several components, but two of the most relevant are VILLASnode and VILLAScontroller. The former is a modular gateway for exchanging simulation data across multiple industrial and common communication protocols, enabling interaction among real-time simulation equipment, databases, and microservices, thereby supporting the bidirectional communication required in a digital twin. The latter component orchestrates interactions with multiple simulators, enabling scalability across simulators and power system devices from multiple vendors. The architecture of the VILLAS framework and its interaction with real infrastructure is shown in Figure 2.

The laboratories for our proposal could be physical nodes, virtual ones, or a combination of both.

3. Cloud Based Real-Time Simulation Strategy

The cloud-based strategy for real-time simulation centers on configuring and managing cloud resources to meet real-time constraints while balancing performance, scalability, cost, and reproducibility. We set up a cloud architecture to meet real-time requirements.

The proposed cloud infrastructure has one physical node available, which can be classified as a Hyperconverged Infrastructure (HCI) [44]. The physical node was divided into six virtual nodes using KVM as the hypervisor on the Linux host. Figure 3 shows a logical diagram of the proposed cloud infrastructure, and 

Table 1. Virtual nodes and network configuration of the Kubernetes cluster.

Virtual Node	vCPUs	Memory	Description
Infrastructure node	2 vCPUs	8 GiB	Provisioner and controller
Cloud control plane	2 vCPUs	4 GiB	Control plane node
Cloud node 0	8 vCPUs	16 GiB	Real-time simulator node
Cloud node 1	8 vCPUs	16 GiB	Real-time simulator node
Cloud node 2	4 vCPUs	8 GiB	Data streaming node
Storage node 0	2 vCPUs	4 GiB	RADOS storage node
Storage node 1	2 vCPUs	4 GiB	RADOS storage node
Storage node 2	2 vCPUs	4 GiB	RADOS storage node
VLAN name	CIDR	MTU	Usage description
oam-space	192.168.10.0/24	1500	Operation and management
storage-access	192.168.12.0/24	9000	Ceph storage access
storage-replication	192.168.14.0/24	9000	Ceph storage replication
internal-space	192.168.11.0/24	1500	Nodes, APIs and services
network-provider	168.176.124.0/23	1500	Network with Internet access

presents each virtual node’s specification and usage.

The cloud uses Kubernetes to automate the deployment, scaling, and management of containerized applications in the private cloud [45]. The Kubernetes system is deployed in clusters, consisting of a set of physical or virtual worker machines called nodes. Every cluster has at least one worker node—the worker node(s) host the Pods, the components that run the containerized workloads. The Control Plane nodes manage the worker nodes in several aspects.

The Container Network Interface (CNI) is deployed using open-source software called Calico [46], and the load balancer is based on MetalLB [47].

The additional software components that abstract physical resources to enable cloud technologies, such as hypervisors and container runtimes, may introduce random latencies for workloads compared to running directly on bare-metal machines. From a kernel perspective, latency is the time from an interrupt request to a task entry. For real-time workloads, the worst-case latency defines whether the system is suitable for hosting a real-time application.

We deploy specific tuning to achieve real-time performance despite the latencies introduced by virtualization. The main hardware and software settings are presented in the following subsections.

3.1. Bare-Metal Server

The server used is an HPE(R) ProLiant(R) DL380 Gen10, with the hardware specifications shown in

Table 2. Hardware references and specifications.

QTY	Hardware	Reference
2	CPU	Intel(R) Xeon(R) Gold 6242R CPU @ 3.10 GHz
40	CORES	80 total threads HT, and VT-x and VT-d
4	MEMORY	32 GiB DDR4 RAM
2	NIC	Broadcom(R) BCM57416 NetXtreme-E Dual-Media 10Gbps
1	IPMI	iLO HPE

.

In the BIOS, power management and hyper-threading are disabled, as they can introduce random latencies.

3.2. Real-Time Operating System

Since open-source operating systems can be installed on a general-purpose computer, some configuration is required to achieve real-time response from the DPSIM application. In real-time (rt) applications, latency must be accountable and predictable, exhibiting a deterministic behavior. From a computing perspective, nearly all latency sources in a system stem from the kernel and scheduler decisions. Thus, tuning an rt-capable kernel to minimize or eliminate latency when responding to various events is the first task for the system administrator when deploying an rt application on any compute infrastructure. Although rt tuning is an iterative process, we refer to some of the most critical variables and configurations.

3.2.1. Real-Time Operating System Setting

In a non-rt kernel (or non-preemptable kernel), latencies may come from various sources and are not deterministic. For example, a driver could disable interrupts, preventing high-priority programs from being scheduled. Similarly, if the kernel uses a busy-waiting locking mechanism (such as a spinlock) to protect critical sections, it blocks the scheduler from allocating other high-priority processes. However, running a kernel built with the rt kernel patchset (or a fully preemptable kernel) modifies the kernel to reduce the size of non-preemptable sections, introducing fine-grained locking and using sleeping locking mechanisms (such as mutexes) instead of busy-waiting. For most of the infrastructure presented in Section 3, we used precompiled installations of a fully-preemptable Linux kernel when possible. The Linux operating system is patched with PREEMPT_RT Linux kernel [48] to reduce the impact of interrupt handlers and make locks preemptible.

3.2.2. Isolating Interrupts and Setting Process Affinity

System functions and interrupt (IRQs) handling are other sources of latency. They can conflict with other high-priority programs running on the same CPU, causing delays. Isolating IRQs on dedicated CPUs from high-priority processes can be particularly important when the speeds involved are near or at the limits of memory and available peripheral bus bandwidth. Any wait for memory fetched into processor caches will impact overall processing time and determinism. We isolated 2 out of 12 CPUs for operating system functions and interrupt handling for most of the infrastructure. The remaining 10 CPUs were dedicated purely to real-time simulation.

3.3. Host Operating System

The kernel profile was set to realtime-virtual-host. This profile uses the performance CPU frequency scaling governor to maximize core frequency. Also, cores 4–24 are set to isolated mode, reducing the number of scheduling clock interrupts (no_hz) on those cores.

As mentioned earlier, isolating IRQ-dedicated CPUs minimizes latency experienced by real-time workloads in the user processes. The realtime-virtual-host profile configures the IRQ-balancing service and excludes isolated cores from consideration.

3.4. Hypervisor

It uses a low-latency kernel on both host and guest, as proposed by ref. [31], suggesting that this configuration may be suitable for KVM when serving real-time applications.

3.4.1. VMs Configurations

Using the command libvirt, three real-time KVM VMs were deployed. Their cores matched those isolated in the host OS. The first has eight vCPUs from core 5 to core 12, the second has eight vCPUs from core 13 to core 20, and the third has four vCPUs from core 21 to core 24. vCPUs were pinned to a list of physical CPU numbers using the vcpu.cpuset parameter.

The backing memory was allocated with huge pages using memoryBacking.hugepages command and locked to prevent swapping with the memoryBacking.locked parameter.

3.4.2. Guest OS Real-Time Kernel

As in the host OS, we used the same Linux kernel version 5.4, patched for real-time with the Fully Preemptible Kernel (Real-Time) as the preemption model in the guest OS.

3.5. Containers and Images

The feasibility of using container-based technologies to support real-time capable systems has been previously investigated in the literature. In [32], the authors analyze the potential of both application- and system-level containers for real-time execution, highlighting their advantages in terms of portability and deployment flexibility.

Containers run by sharing the host operating system’s kernel. When deployed in a virtualized environment, containerized applications share the kernel of the underlying virtual machine. As a result, the container’s real-time behavior is directly influenced by the kernel configuration and tuning described in the previous subsection. In this work, CPU affinity and scheduling priority parameters were explicitly configured at the container level to ensure that the application under test executed on isolated processor cores with the highest possible priority, thereby minimizing interference from other system processes.

3.6. Cloud Performance Results

We test five cases to evaluate the real-time performance of the different possible configurations of the layers, as shown in

Table 3. Cloud configuration test cases.

Case	OS Host	KVM	lxc	Container
1	non-rt	-	-	-
2	rt	-	-	-
3	rt	rt	-	-
4	rt	rt	rt	-
5	rt	rt	-	rt

.

We use cyclictest to measure worst-case latency for each abstraction in a non-stress scenario (the routine running with no additional load) and a stress scenario (a heavy CPU load, as proposed by [49]).

The command to generate the CPU load for the stress tests was:

$ while true; do /bin/dd if=/dev/zero of=bigfile \| \\
>    bs=1024000 count=1024; done & \|\\
>    cd ltp-20210524; while true; do ./runalltests.sh -x 40; done|

And the following command to measure the latencies:

$ cyclictest --mlockall --priority=99 --interval=100 \|\\
>    --histogram=100  --duration=2h -q > output|

Figure 4 presents the cumulative histogram of the cyclictest results. As expected, the average latencies obtained are low; however, the worst-case latencies reported in

Table 4. Worst-case latency results.

Layers	Kernel	Worst-Case		$\overline{\mathit{x}}$	${\mathit{\sigma }}_{\mathit{s}}$
		No Stress	Stress
bare-metal	non-rt	789 $\mathsf{\mu }$s	2303 $\mathsf{\mu }$s	1 $\mathsf{\mu }$s	13 ns
bare-metal	rt	64 $\mathsf{\mu }$s	344 $\mathsf{\mu }$s	1 $\mathsf{\mu }$s	10 $\mathsf{\mu }$s
bare-metal/kvm vm	rt/rt	87 $\mathsf{\mu }$s	465 $\mathsf{\mu }$s	6 $\mathsf{\mu }$s	498 ns
bare-metal/kvm vm/lxc	rt/rt/rt	129 $\mathsf{\mu }$s	2980 $\mathsf{\mu }$s	7 $\mathsf{\mu }$s	187 ns
bare-metal/kvm vm/containerd	rt/rt/rt	142 $\mathsf{\mu }$s	3049 $\mathsf{\mu }$s	7 $\mathsf{\mu }$s	372 ns

are the most relevant metric for real-time applications.

The results show that the cloud is suitable for running workloads with hard or firm real-time constraints under no-stress conditions. However, higher latencies may occur under stress and overrun soft real-time-constrained workloads, so users should run only soft real-time-constrained workloads under stress.

4. Test Case—Cloud Computing

In power system simulations, setting the time step to match the dynamics and analysis of interest is important. For control and stability analysis, a suitable timestep should be below 100 $\mathsf{\mu }$s.

We use, as in [50], the benchmark scenario based on the WSCC 9-bus system, where interconnected copies of the system are scaled in a ring topology, as depicted in Figure 5. The proposed methodology evaluates the real-time capabilities of DPsim by executing a 5002-time-step simulation 1000 times and measuring the mean time-step computation time. Scalability is evaluated by progressively increasing the number of system copies and interconnecting them through transmission lines, as illustrated in Figure 5. With this strategy, the complexity of the benchmark system increases proportionally, enabling evaluation of system sizes ranging from 9 buses to 810 buses, with corresponding increases in generators, transformers, transmission lines, and loads. The characteristics of the scaled systems used in this study are summarized in

Table 5. Characteristics of the scaled WSCC 9-bus benchmark systems used in the scalability analysis.

Copies	Buses	Generators	Transformers	Transmission Lines	Loads
1	9	3	3	6	3
25	225	75	75	225	75
50	450	150	150	480	150
75	675	225	225	675	225
90	810	270	270	810	270

.

To evaluate performance on the cloud infrastructure, DPsim was configured to exploit parallelization, where the best performance for the server used in this study was obtained with eight threads, as shown in Figure 6. As a baseline, the computation time to simulate a time step of a single copy of the IEEE 9-bus system under the bare-metal real-time configuration is approximately 8.37 $\mathsf{\mu }$s. This baseline helps interpret the scaling behavior when additional system copies are interconnected to increase the network size.

Finally, we tested the benchmark case to evaluate the time required to compute each time step for the five cloud configurations described in Section 3. Moreover, a new case was evaluated using a public cloud instance in Amazon Web Services (AWS) [51]. The instance type was the m5n.4xlarge due to the similarities to the on-premise hardware specifications. The m5n family features second-generation Intel Xeon Scalable Processors with the Cascade Lake microarchitecture, a sustained all-core Turbo CPU frequency of 3.1 GHz, and AVX-512 support. The Amazon Machine Image (AMI) used the same OS, real-time patch, and realtime-virtual-guest tuned profile as the on-premise VMs. However, the host OS could not be changed.

5. Results and Discussion of Possible Applications

Figure 7 presents the mean duration of the 5002 simulation steps of the WSCC 9-bus system with n copies after running the simulation 1000 times. The results clearly show that a non-real-time OS does not enable the 100 $\mathsf{\mu }$s timestep goal. On the other hand, using real-time configuration across different cases enables us to achieve this goal; however, the maximum number of nodes decreases as the number of abstraction layers increases.

Table 6. Results of scaling the WSCC 9-bus system.

Layers	Kernel	System Copies	System Buses
bare-metal	non-rt	0	0
bare-metal	rt	57	513
bare-metal/kvm vm	rt/rt	41	369
bare-metal/kvm vm/lxc	rt/rt/rt	40	360
bare-metal/kvm vm/containerd	rt/rt/rt	37	333
aws nitro system/aws instance	non-rt/rt	5	45

summarizes the maximum number of WSCC 9-bus system copies that each test environment can simulate while maintaining a mean timestep duration below 100 $\mathsf{\mu }$s. As expected, the introduction of virtualization layers reduces the system’s scalability by approximately 28–35%. Nevertheless, the achieved system sizes remain significant, and future work may further increase the effective simulation scale through horizontal scalability strategies using multiple containers or pods.

The results above show that different cloud configurations enable the deployment of real-time simulations in power systems at different scales. The main application of real-time simulation will depend on the scope required.

The reduced performance observed in the AWS instance can be attributed to the limited control over the host environment in public cloud infrastructures. Unlike the on-premise setup, the host operating system and hypervisor cannot be configured for real-time optimizations, which may introduce additional latency and execution variability due to shared-resource scheduling.

For Software-in-the-Loop simulation, where algorithms are tested in the same cloud-based environment, it can be used for applications on power plant controllers as well as protections.

Synchronization is a key challenge in distributed cloud-based real-time simulations. In these environments, the orchestration layer coordinates the execution of different simulation components to maintain temporal consistency during co-simulation. Because communication latency between geographically distributed cloud resources can vary and is not always deterministic, a practical approach is to rely on local synchronization using a common global time reference [43]. Within each node or containerized environment, high-precision synchronization protocols such as the Precision Time Protocol (PTP), standardized as IEEE 1588 [52], can be used to achieve sub-microsecond clock alignment between devices.

Several co-simulation examples have demonstrated the feasibility of developing geographically distributed simulations [38,43,53]. Nonetheless, evaluating synchronization performance and latency propagation across distributed cloud infrastructures remains an important topic for future work.

The use of a real-time cloud lab may be suitable for co-simulation, interacting with local real-time labs equipped with HIL capabilities, which may handle interactions with physical equipment and the cloud simulation of a wide-area simulation, as shown in Figure 8.

If communication with external laboratories or cloud environments is required, communication latency must be considered. According to [54], network latency can vary significantly across cloud providers and edge computing platforms. Nevertheless, several configurations can achieve latencies ranging from a few milliseconds to several tens of milliseconds, which may still support applications such as Wide Area Monitoring, Protection, and Control (WAMPAC), Power System Stabilizers (PSS), or Automatic Generation Control (AGC), depending on the dynamic requirements shown in Figure 1. As illustrated in Figure 8, the cloud-based simulation can represent large-scale network dynamics, while local laboratories conduct hardware-in-the-loop experiments that interact with physical devices. The data exchanged between the cloud simulation and the local laboratories may include phasor measurements of voltage and current, as well as derived quantities such as frequency, rate of change of frequency (RoCoF), and switching states.

Despite its lower performance, the AWS configuration simulated up to 45 nodes under real-time constraints, which may still be useful for small-scale scenarios or customized cloud deployments designed for real-time simulations, as explored in this work. While this capacity remains below that achieved in the on-premise environments, it nevertheless demonstrates the feasibility of cloud-based real-time simulation. This configuration, therefore, provides a proof of concept for deploying real-time simulation in public clouds and could be extended in future work through cluster orchestration strategies, such as horizontal scaling using multiple pods or containers.

6. Conclusions

This paper evaluated the feasibility of running open-source real-time power system simulations on cloud-based infrastructures, with particular emphasis on computational determinism, scalability, and practical deployment constraints. By systematically comparing bare-metal, virtualized, containerized, private-cloud, and public-cloud environments, the study quantified the impact of increasing abstraction layers on worst-case latency and achievable real-time simulation scale. The results demonstrate that, when combined with appropriate real-time kernel configurations, CPU isolation, and affinity tuning, cloud and cloud-like infrastructures can support real-time simulation workloads under soft and, in some cases, firm real-time constraints.

The benchmark results indicate that while bare-metal and private-cloud environments enable larger-scale real-time simulations, public-cloud instances remain suitable for smaller systems and less time-critical applications. These findings suggest that cloud-based real-time simulation is not a replacement for commercial digital real-time simulators, but rather a complementary approach that can extend experimental capabilities, particularly for wide-area studies, co-simulation, and geographically distributed testing.

These results show that containerization reduces the scalability achievable within a single simulation instance. Nevertheless, this approach remains promising in a cloud-native context, where horizontal scalability can be exploited by deploying multiple containers or pods. Such a strategy could enable larger network representations by distributing the simulation workload across multiple instances. Future work will focus on evaluating network-induced latencies in multi-site deployments, integrating hardware-in-the-loop experiments, and exploring emerging cloud and edge computing platforms specifically optimized for real-time workloads.

In this context, the evaluated cloud-native real-time simulation infrastructure can serve as a computational backbone for power system digital twins, enabling continuous synchronization between physical measurements and digital models.