DPsim—A dynamic phasor real-time simulator for power systems

DPsim is a real-time capable solver for power systems that operates in the dynamic phasor and electromagnetic transient (EMT) domain. This solver primarily targets co-simulation applications and large-scale scenarios since dynamic phasors do not require sampling rates as high as EMT simulations do. Due to the frequency shift introduced by the dynamic phasor approach, the sampling rate and rate of data exchange between simulators can be reduced. DPsim supports the Common Information Model (CIM) format for the description of electrical network topology, component parameters and power flow data and it is closely integrated with the VILLASframework to support a wide range of interfaces for co-simulation. Simulation examples demonstrate the accuracy of DPsim and its real-time performance for increasing system sizes. ©

and the highest frequency of simulated signals. Especially for power electronics and geographically distributed real-time simulation, this is an interesting feature. Currently, the focus of DPsim is more on the application in distributed real-time co-simulation than power electronics. The idea is that the larger the simulation step, the smaller the impact of the communication delay between simulators, which are geographically distributed.
Distributed real-time co-simulation is motivated by large system simulations requiring more simulation capacity than is locally available and by the possibility of Hardware-In-the-Loop (HIL) testing with hardware under test and simulators at different locations. Using dynamic phasors for this application is a fairly recent development although the dynamic phasor, or the envelope function concept, is well known and was introduced in power electronics analysis in [1] as a generalized state space averaging method.
The authors of [2] have developed a distributed real-time simulation laboratory by applying a communication platform as a simulator-to-simulator interface in order to enable remote and online monitoring of interconnected transmission and distribution systems. Each simulator carries out simulations in time domain, while the variables exchanged at the interconnected nodes, i.e. decoupling point, are in the form of time-varying Fourier coefficients. The electromagnetic transient (EMT) values cannot be exchanged at every simulation step due to the communication delay. This delay may be directly incorporated into the physical power system model using traveling wave transmission line models [3]. However, electromagnetic waves travel about 15 km in 50 µs, a time which equals the typical step time in real-time EMT power system simulation. This means that a communication delay in the range of milliseconds would have to be compensated with a line length of several hundred kilometers which may require large and unrealistic changes to the original system model. Therefore, this method is suited for applications on local simulation clusters where the delay is only few simulation steps, but not for internet-distributed simulation, where the expected delay is often tens of milliseconds. In the latter case, the insertion of a transmission line model with the required parameters into the model would have a severe impact on the behavior of the system. Without compensation, the communication delay might cause large errors and even instability of the simulation as shown in [4] for a delay of more than 30 ms.
Starting from the concept presented in [2], we propose interfaces and system-wide simulation state variables based on dynamic phasors. This approach has two benefits explained in [5], which presents a comparison of DP and EMT simulations conducted in DPsim. First, it takes advantage of the computational efficiency of dynamic phasors in scenarios that involve bandpass signals with large center frequencies, as in the case of switching power electronics. Secondly, it increases the simulation time step thus reducing the difference between the local simulation time step size and the round trip time between simulators.
The approach employed in [2] requires the extraction of phasor information from the EMT signals. Therefore, the transparency of the interface is not guaranteed since the interface algorithm may alter the exchanged signals. This extraction step is eliminated by using dynamic phasors as state variables. Because of these features, DPsim is now part of the distributed real-time cosimulation platform described in [6], which is also the base for the experiment described in [2]. A first example of distributed real-time co-simulation using DPsim is presented in [7]. This example shows the impact of the latency in geographical distributed simulation on the results and how the latency can be modeled a priori to running actual simulations.
Besides, there are other relevant open-source initiatives in the field of power system simulation to be mentioned. In particular the Modelica community is very active in adapting Modelica environments for large scale power system cases [8,9] and providing comprehensive libraries of models [10,11]. These initiatives aim to enable large scale, fast simulation of power systems using open-source components but the focus is slightly different compared to the work presented here. The primary objective of DPsim is to assure a deterministic time step in terms of simulated and computation time to provide real-time capability required for Hardware-in-the-Loop (HIL) experiments. This is why in DPsim higher order solver methods are avoided and the system is split into subsystems, which are solved separately. The aforementioned related work does not seem to rely on such compromises since a deterministic time step is not required. While Modelica allows a convenient definition of physical models, DPsim does not intend to provide a solution in this regard. The idea is rather to extend the set of available models in DPsim by generating C-code from Modelica models to represent components connected to the network. These can be linked to DPsim and solved by the ODE solver that was integrated into DPsim for this purpose.
Another related work which is not open-source but also DP based is described in [12]. Similarly to DPsim, the authors have developed a simulator based on the DP approach. However, the focus does not seem to be fast simulation or real-time simulation since the simulator was developed in Python and there are no measures described in order to speed up the simulation. Furthermore, the validation is focusing on the correctness of the simulation rather than simulation speed.

Software description
The main theoretical building blocks of DPsim are the dynamic phasor concept and the modified nodal analysis (MNA). Dynamic phasors [13] have various names in scientific literature. Depending on the field and application, they are known as generalized averaging method [1], shifted frequency analysis [14], equivalent envelope [15,16] or baseband signal [17]. Here, the term dynamic phasors is selected because it is widely known in the power system community. The basic idea of dynamic phasors is to approximate a time domain signal x with a Fourier series representation as shown in (1) The kth coefficient is determined by where ω s is the fundamental system frequency and kω s are its harmonics. MNA is used for the representation of the network as a linear equation system, whereas complex components, such as electrical machines, connected to the network are treated by a separate ODE solver. Depending on the simulation scenario, the admittance matrices of the required network topologies can be preprocessed, i.e. factorized, before simulation start to guarantee a deterministic simulation time step.
The simulation kernel of DPsim is extended with interfaces to support different use cases such as circuit or system simulation, batch simulation, co-simulation and HIL testing. DPsim supports the Common Information Model (CIM) [18] as native input for the description of electrical network topologies, component parameters and load flow data, which is used for initialization. Users can interact with the simulation kernel via Python bindings, which can be used to script the execution, schedule events, change parameters and retrieve results. Python scripts have been proven an easy and flexible way to codify the complete workflow of a simulation from modeling to analysis and plotting, for example in Jupyter notebooks using Numpy and Matplotlib. Furthermore, DPsim supports co-simulation and interfaces to a variety of communication protocols of commercial hardware via the integration of DPsim with the VILLASframework [19], that enables large-scale co-simulations and HIL experiments.

Module structure
The DPsim simulation kernel and its component models are implemented in the C++ programming language. The availability of good compilers and highly optimized software libraries, such as Eigen [20], Sundials [21] and VILLASnode, which is part of the VILLASframework, for C++ were key factors for this decision.
The core of DPsim consists of models and solvers as depicted in Fig. 1. Interfaces to other software, hardware or data are supported through external libraries. Grid data in CIM standard format is imported using the CIM++ library [22]. Communication with other software, e.g. real-time simulators, control and monitoring software, as well as hardware is provided by the VILLASframework. For linear algebra operations, DPsim uses the Eigen library. The MNA solver of DPsim uses the Eigen LU factorization and Eigen::Dense/Sparse::Matrix are the standard data types for all matrix variables. The Sundials solver package is included in DPsim to provide more complex ODE solvers for components connected to the network.
Compilation from source code requires a Git, a C++11 compiler and CMake 3.6. Tested compilers are Clang, GCC, MSVC and Intel's ICC. As a base operating system Ubuntu 18.04 LTS or Fedora 29 are recommended. For real-time execution a Linux 4.9 kernel with the PREEMPT_RT patch-set is recommended.

Class hierarchy
Simulation is the main interface class for users to control the simulation state. The attributes of a Simulation instance hold all the information that specifies one simulation scenario in DPsim. The Simulation holds references to the solvers, interfaces and the power system model information. This hierarchy is presented in Fig. 2. The complete class hierarchy diagram can be found in the developer's documentation of DPsim [23]. All solvers inherit from Solver, e.g. MNASolver and ODESolver, and all interfaces from Interface, e.g. for VILLASnode. All component models, power system, signal etc., derive from the class IdentifiedObject. The main attribute of this class is a unique identifier, which is equivalent to the mRID in CIM.

Parallelization
In order to utilize the multiple processor cores of modern computer systems and speed up the simulation, the computation of one time step is split up into multiple tasks. These tasks are defined by the various parts of the simulation (like instances of Solver and Interface). An internal scheduler creates a task graph by analyzing which variables are modified and used by the tasks. This task graph is a directed acyclic graph with nodes representing tasks and edges representing data dependencies. The scheduler uses this graph to distribute the tasks onto multiple threads such that these dependencies are upheld. DPsim implements different scheduling algorithms for this purpose, the simplest of which being level scheduling as used in [24]. This algorithm divides the tasks into ordered levels such that each task only depends on tasks in a previous level. To simulate a time step, these levels are then executed in order by distributing all tasks of one level evenly among the available threads.
To further optimize the simulation performance for large networks when using multiple processors, a decoupling transmission line model can be introduced. In this model a transmission line is represented using equivalent current sources and resistances at the line ends that are not topologically connected as described in [25, ch. 6.2]. Instead, the ends are indirectly connected by updating the values of the sources based on the values on the other end only after a delay τ , which depends on the line's parameters. As subsystems that are connected using this line model are not connected in a strict topological sense, they can be solved independently and in parallel. This significantly reduces the computational effort to simulate large systems.

Software functionalities
DPsim supports both dynamic phasor and EMT simulation. Furthermore, DPsim is optimized for real-time simulation but it is also possible to run the same simulation scenario offline meaning that the simulation is executed as fast as possible. These different simulation modes are compatible with the user and simulation interface which are covered in the following.

User interface
Network models can be directly defined in the C++ code. This technique is complemented by a CIM importer, which allows the user to directly load network models from CIM-XML files. This proves to be an adequate form to describe network topology and component parameters, which are required by the solver. This CIM importer relieves the user from defining the model in plain C++ code. However, CIM-XML is not suitable for the definition of more complex simulation scenarios with time varying parameters or topology changes caused by contingencies in the system (e.g. breaker events or faults). Therefore, DPsim features Python bindings to most parts of the C++ programming interface. A scripting language like Python is used to define scenarios by leveraging the flexibility of a general purpose imperative language. This allows the user to write a single Python script to: • Describe the network topology and parameters • Load a network from CIM data and optionally extend it • Define a simulation scenario with events or parameter changes • Execute the simulation and analyze or plot the simulation results

Simulation interface
Interfacing the simulation kernel is desirable for multiple reasons: • Real-time exchange of simulation signals for co-simulation or HIL testing • User interface for online monitoring and control of the simulation • Logging of simulation results for offline analysis • Import of time series data, for example load and production profiles For commercial simulation tools these interfaces are a major selling point as new protocols and standards and DAQ cards are introduced continuously. Their implementation and maintenance is time consuming and seemingly never ending. By design, DPsim tries to avoid this pitfall by leaving the implementation of interfaces, data formats and protocols to a separate project. VIL-LASnode, a component of the VILLASframework project, handles input/output as well as translation between different protocols. DPsim focuses on solving the system model and provides only a single type of interface, shared memory, to the VILLASnode gateway. Interfaces to external systems, databases, files or the web interface are then handled by the wide range of supported interfaces of the VILLASnode gateway, which in this case acts as a proxy between the shared-memory interface to DPsim and the outside world. Responsibilities are clearly separated. This allows the development of new interfaces without having to modify the simulation kernel itself.
In addition, DPsim can use the VILLASnode interfaces for cosimulation with other simulators or remote DPsim instances. In such a scenario, DPsim is usually coupled using an Ideal Transformer Model (ITM). Fig. 3 shows a decoupled model, which exchanges voltages in one and current signals in the opposite direction to control respective sources. For a phasor simulation, the exchanged signals are complex-valued attributes which are passed via the shared-memory interface to VILLASnode which further sends them to a remote simulator using one of VILLAS' supported protocols (e.g. MQTT, UDP, ZeroMQ, . . . ). For geographically distributed simulations, VILLASnode can implement interface algorithms to compensate for the inherent communication latencies when executed in real-time over a high latency connection such as the internet. Alternatively, the implementation of a Discrete Fourier Transform (DFT) in VILLASnode allows for a coupling of the phasor-based DPsim with other EMT-based simulation tools like OPAL-RT or RTDS.
DPsim exchanges simulation data with the VILLASnode gateway via a shared-memory region. The execution of DPsim and VILLASnode as independent processes is crucial in real-time simulation scenarios as the main simulation kernel must not be interrupted by background activities such as data logging to a possibly blocking database.
Furthermore, DPsim has its own simple logging module to write results to CSV files for archival and post processing. This method is easy to setup and convenient for small simulations where post processing and analysis of simulation results is done in MATLAB or Python. In the long term, the internal CSV logging functionality is planned to be incorporated into VILLASnode and enhanced by the support of additional data formats like HDF5 as used by MATLAB.

Implementation and empirical results
To complement the previous overview of DPsim's architecture, the next subsection explains implementation specifics affecting the real-time performance of DPsim. The real-time performance of DPsim is demonstrated in the following subsection. The remaining two subsections demonstrate the correctness of the solution computed by DPsim against Matlab Simulink. The first simulation validates only the network solution, which is computed by the MNA solver. The second simulation features a combination of the MNA solver for the network solution and an ODE solver for the numerical integration of the synchronous generator equations.

Implementation details
Only a compiled language like C++ with minimal runtime overhead is suitable for the implementation since DPsim is targeting simulation time steps in the range of milliseconds to microseconds on off the shelf computing hardware. Great care was taken to avoid memory allocation during the actual simulation. Whenever possible, DPsim utilizes low order integration methods and avoids iterative solver strategies to minimize computation time. That is why the network part is handled by the MNA solver specifically developed for DPsim.
DPsim is compatible with Windows, macOS and Linux operating systems. Eventually, the operating system configuration can have a large impact on the real-time performance. To guarantee real-time execution, DPsim leverages several Linux real-time features such as the real-time capable SCHED_FIFO scheduler, realtime signals, the timerfd interface, or control groups (cgroups). Many of these features are nowadays incorporated in the standard Linux kernel but have their origin in the PREEMPT_RT patchset. The patch-set is slowly integrated into the mainline kernel but still exists and can be applied to further improve the real-time performance by enabling preemption of critical sections such as interrupt handlers. The capability to preempt critical sections in the operating system kernel reduces the overall system latency and therefore helps to ensure strict deadlines at each time-step interval.
Real-time execution on Windows or macOS is not supported. Best real-time performance was achieved on a recent Intel x86_64 multi-core machine with optimized BIOS settings to avoid interruptions of the system by the System Management Mode (SMM). To do so, DPsim execution threads are isolated from remaining system processes using Linux's cgroup feature. This reduces the impact of background jobs in the system on the real-time performance.
As a good start for real-time optimizations, we recommend Redhat's Real-time Guide [26] with its tuned tool and the realtime profile. An updated list of optimization options can be found in the DPsim documentation [23].
To control the time step, DPsim is using timerfd interface in Linux environments. The timerfd interface allows for the configuration repetitive interval and one-off timers. It uses blocking file descriptors to suspend the execution of the simulation loop until the beginning of the next interval. This approach is more Fig. 3. VILLASnode as a gateway for distributed co-simulation with DPsim. efficient than the use of the more common timer interface, which relies on signals. At the same time, timerfd is more accurate as calls to sleep or nanosleep as they suffer of a lingering drift to non-equidistant execution intervals. The timerfd is also used to schedule the synchronized start of distributed simulations as described in the introduction.
Shared-memory is a common method for inter-process communication (IPC) used on symmetric multi-processing (SMP) machines. It enables user processes to exchange data without the involvement of the OS kernel. Shared-memory IPC allows both processes, the solver and the gateway, to be executed in parallel while streaming their data with minimal latency over a queue in the shared memory region. The queue is implemented as a lock free multiple producer/multiple consumer (MPMC) queue and relies on atomic operations of the processor to facilitate synchronization of the DPsim and VILLASnode processes. The lockfree queue is a thread safe data structure. It is used to pass samples of simulation data between the involved processes. As such message passing is used as the main paradigm to avoid data races. During the initialization phase, semaphores are used to avoid race conditions in the setup of the shared-memory regions. The absence of the operating system in the communication is crucial to avoid costly context switches, which have to be avoided in a real-time context. Using the shared-memory interface, the DPsim simulation loop can run uninterrupted in a high priority process. At the same time, VILLASnode gets assigned a lower priority for handling of possibly blocking disk or database accesses. In a hardware-in-the-loop simulation it might be necessary to have hard real-time capable interfaces to the real world. For this purpose, DPsim supports an arbitrary number of sharedmemory interfaces at the same time. This allows the user to configure one VILLASnode process with a high priority for the control of PCIe FPGA or DAQ cards, and at the same time another VILLASnode process for low priority logging of simulation data in the background.

Real-time performance evaluation
DPsim is specifically designed for real-time simulation. To assess the effect of system size on the real-time performance of DPsim, a simple test network was copied multiple times and connected with additional transmission lines. Fig. 4a shows the WSCC 9-bus system, which was used for this purpose. The copies were connected in a ring-like topology using additional transmission lines at the nodes 5, 6, and 8. The average wall clock time needed to simulate one time step was measured for a simulation time period of 0.1 s with a time step of 100 µs. Each measurement was further averaged over ten simulations of the same system. The measurements were performed on a system running Ubuntu 16.04 on an Intel Xeon Silver 4114 processor featuring ten cores clocked at 2.2 GHz. The results are shown in Fig. 4b for two different configurations: For the normal simulation, the additional transmission lines were modeled using the Pi model and only one thread was used. For the parallel simulation, the decoupling transmission line model was used for the additional lines and ten threads were employed. As it can be seen, the use of multiple threads and the special transmission line model greatly reduces the wall clock time necessary for simulating a single time step. Even for 40 copies of the original system (resulting in a system size of 360 nodes), the wall clock time per step stays under the simulation time step of 100 µs, thus allowing for real-time simulation. For a small number of system copies, DPsim supports simulation time steps of about 10 µs, which is a typical time step for commercial EMT simulators. However, it should be noted that such small time steps are not the aim of DPsim since the simulation is conducted in DP and not EMT.

Validation of the MNA network solver
The next simulation case demonstrates the accuracy of the MNA network solver compared to Simulink results. Both simulators DPsim and Simulink are run with a simulation time step of 100 µs. It can be seen that for such small time steps DP simulations yield the same results as EMT. The larger the time step, the more will the results degrade. It is shown in [5] that the degradation of the results with larger time steps is smaller when using the DP approach compared to EMT. Fig. 5a shows the simulated circuit, which is composed of one current source of 10 A, two resistors of 1 , an inductor of 1 mH and a capacitor of 1 mF. The voltage source is set to its nonzero peak value at the beginning because it is following a cosine with zero phase shift. Therefore, the system is not starting from steady-state and a transient can be observed. The DPsim dynamic phasor results are transformed to time domain values and compared against Simulink EMT results. As can be seen from Fig. 5b, the results match.

Validation of the ODE solver for components
The following example compares the results of Simulink and DPsim for a three phase synchronous generator fault. Here, the simulation time step is 50 µs for DPsim and Simulink. As in the previous simulation case, the DP approach would allow for larger time steps than EMT. A comprehensive study investigating this property and featuring synchronous generator models is presented in [27]. Initially, the load is 300 MW and the fault is applied at 0.1 s. The generator parameters are taken from example 3.1 in [28]. As in the previous example, the dynamic phasor results are transformed to time domain values before the comparison. Again, it is visible that the DPsim results match the Simulink results except when the fault is cleared (see Fig. 6). In contrast to DPsim, the fault in Simulink is not immediately cleared but at the next zero-crossing.

Illustrative examples
As mentioned in Section 2.2, there are two ways to define a circuit topology for DPsim: coding the topology using Python or C++ or importing it from CIM. The two options are presented by means of two examples: a circuit and a small power system. The first example presented in this section demonstrates the definition utilizing Python while the second example takes advantage of the CIM import function.

Defining a circuit simulation in python
The circuit of the previous section, Fig. 5, is taken as an example to demonstrate how circuits can be defined using DPsim's Python interface. The topology can be created in Python as depicted by Listing 1.
Listing 1: Python code to define a circuit.

Simulating a power system defined in CIM
The next example presents the CIM loading functionality, which is used to read the data of the WSCC 9-bus system as displayed in Fig. 4a. The objects defined in the CIM file, e.g. Terminal, TopologicalNode, SynchronousMachine, are mapped to DPsim objects according to the CIM::Reader class of DPsim. The system frequency, 60 Hz, is not defined in the CIM file. Therefore, it needs to be specified before loading the CIM file. Furthermore, a fault is applied to node 9 of the imported system. To implement the fault, the system is extended by a switch connected to node 9, which connects the node to ground with a small resistance after 0.2 s. The switching action is created as an object of type Event and added to the Simulation instance.  Fig. 7, it can be seen how the rotational speed of the generators starts to oscillate after the fault. The oscillation frequency depends on the mechanical inertia and as expected the generator with the largest inertia has the lowest oscillation frequency.

Impact
Since DPsim is open source, it can serve as a reference implementation for real-time power system simulators and a common basis for users working with different real-time simulation solutions. Having a common basis facilitates discussions on differences in simulation results of different tools. Besides, DPsim allows for real-time simulation on standard computing hardware, making real-time applications available to a wider range of researchers.
Thanks to its design, DPsim facilitates distributed real-time co-simulation, which promotes collaboration and allows the use of the simulation capacity of geographically distributed laboratories to support large scale scenarios [5]. Distributed real-time co-simulation allows also for better data privacy, enabling cooperation because, in a co-simulation, each entity can keep its data confidential and only exchange boundary variables. This could be interesting for confidential grid data but also black box device models where manufacturers cannot share implementation details.
The dynamic phasor approach is used here in a system level simulation in contrast to component level power electronics applications as in [1]. With an increasing share of power electronics in power systems, this approach supports the investigation of future grids.
DPsim is already used in the EU H2020 research project RE-SERVE [29] and it was developed as a solution to decrease the difference between communication delay and simulation time step in previous co-simulation projects, e.g. RT-Superlab [2]. DPsim is promoted by the FEIN association that also hosts its code and documentation [23].

Conclusions
The presented software project, DPsim, exploits the dynamic phasor approach to overcome the requirement for EMT simulation that the simulation time step needs to be proportional to the highest signal frequency. In doing so, DPsim facilitates distributed real-time simulation and lets users exploit simulation resources in different geographical locations. For this purpose, DPsim is programmed in the C++ language and has its own MNA based network solver. Despite having a C++ core, the DPsim allows for scripting simulations via the python interface and reading grid topologies in the standard CIM format via the CIM++ library. These features are demonstrated in two simulation examples, a circuit and a grid simulation. Likewise, the computational correctness of DPsim and its real-time performance are demonstrated by means of simulation examples. Furthermore, DPsim is tightly integrated with the VILLASframework that offers many interfaces to commercial real-time simulators and hardware.

Declaration of competing interest
We confirm that there are no known conflicts of interest associated with this publication.