Guidelines and Use Cases for Power Systems Dynamic Modeling and Model Verification using Modelica and OpenIPSL

This paper offers systematic guidelines for modeling power systems components in the phasor time-domain us-ing the Modelica language and their verification. It aims to share the authors’ experience in power system modeling with Modelica and the approaches used to meet the high expectations of the power industry w.r.t. to the models’ simulation results. While the modeling guidelines are generic, the verification procedure includes the validation against a domain-specific commercial software tool called PSS®E that is the de facto tool used for power sys-tem transmission planning and analysis. To formalize the proposed approaches, a schematic description of the processes of model implementation and validation is elicited through flowcharts. Challenging use cases are presented to point out some of the major difficulties that can be faced in the modeling steps because of unclear or missing documentation of the models’ dynamics in the reference tool. Finally, unique features of the Modelica language that allow for power system modeling and verification unavailable in traditional tools are illustrated.


Introduction
This paper aims to formalize the process of power systems dynamic modeling and model verification using the Modelica language.The mail goal is to provide, for the first time, a formal description of the steps necessary for complete re-implementation of power systems components of closed-source commercial software like PSS®E in the Modelica language.A generic methodology for re-implementing existing models from different software tools and domains can be derived from the proposed steps.Key use cases that have been challenging to implement and verify are presented to highlight the value of the proposed approaches for model imple-mentation and validation.Moreover, it is shown how the self-documenting nature of object-oriented equationbased modeling offered by Modelica provides unique advantages for human and computer readable model implementation, as compared to existing modeling tools that do not always offer transparency regarding the dynamic behavior implemented in their tools.In this collection of examples, models for the OpenIPSL library1 have been considered and validated against PSS®E.Finally, we emphasize the value of the open-access standardized Modelica specification as a key enabler of open-access standardsbased interoperability (Gómez et al. 2020), showing how the newly implemented models can be re-utilized in multiple Modelica-standard-compliant tools without a need for re-implementation.The reminder of this paper is organized in four sections: Introduction describing some motivations and contributions, Guidelines formalizing in flowcharts the process of models implementation and validation, Use Cases illustrating the proposed approaches with examples of implemented models and Future Work and Conclusions with some final comments.

Motivations
Modeling of power systems has always been fundamental for the design, operation and planning of electric networks.To help all the players of the electric power systems sector to perform their studies and analyses, over the last decades several software tools have been developed.The de facto tools used by industry include proprietary software like PSS®E, PSCAD, EMTP-RV, Power-Factory, etc., that require the user to become an expert of their functionalities and poses intimate tool-and-domain specific knowledge to be productive.In addition, each tool has its own way of defining the data used to characterize their discretized model (i.e."data format") mak-146 ing it inflexible when attempting to share models and data between tools (Hongesombut et al. 2005).Another drawback is represented by the inconsistency of dynamic simulation results between different simulation platforms.This is due to the need to re-implement models in each simulation platform, which has tremendous costs.As reported by the Australian Energy Market Commission2 , the order of magnitude costs for model implementation in each individual tool can reach almost $500,000.00in the case of existing components with power electronic interfaces, such as wind and solar, thus making it challenging to study the effects of the integration of renewable energy resources.Therefore, the idea to remove ambiguity in power systems modeling was suggested in (Vanfretti et al. 2013) by using the object-oriented equation-based modeling language Modelica (Tiller 2001).Following this innovative idea a power systems library called OpenIPSL has been developed (Baudette et al. 2018).The library continues to be maintained and expanded based on the concepts of regression testing and Continuous Integration (CI) (Rabuzin, Baudette, and Vanfretti 2017), that allow the models to be verified against a traditional commercial software tool like PSS®E giving the user of the power systems community the confidence about its reliability for performing dynamic simulations and studies.

Previous Works
The proposed process for testing newly implemented models in Modelica and their verification make use of a Single Machine Infinite Bus (SMIB) equivalent system model (Zhang et al. 2015).This model is typically used to test the implementation of new models and designs of control strategies, which has been emphasized in the literature (Chaudhary and Singh 2014;Kumar 2018;Jayapal and Mendiratta 2010;Wang et al. 2015).This small network is useful in describing the key behavior of a power plant within a power system for most practical purposes.It offers a good framework for studying basic power systems stability concepts and the application of different control techniques to understand their effects on the network.
Regarding the development of new open-source software for power systems studies several examples based on different languages have been reported in the literature.During the 1990's and 2000's, MATLAB saw an exponential adoption in academia, resulting in a number of power system simulation software, such as MAT-POWER (Zimmerman, Murillo-Sánchez, and Thomas 2010), focusing on steady state computations and the Power System Analysis Toolbox that offers an array of analysis types, both steady state or dynamic (F.Milano 2005).With the rise of Python, a new generation of Python-based tools for modeling, analysis and optimization of electric power systems have been developed.Among these, pandapower (Thurner et al. 2018) which aids with steady state computations.GridCal3 is another platform for power systems research and simulation based on Python, again, focusing on steady state computations.Meanwhile, another Python-based tool for power system simulation is ANDES (Cui, Li, and Tomsovic 2020).It is an open-source Python library for power system modeling, computation, analysis, and control and it uses a hybrid symbolic-numeric framework for numerical analysis.What these software have in common is that they define both their models in discretized form, interlinking a specific numerical solver (e.g.Newton solver for steady state analysis or trapezoidal integration for dynamic simulation) during implementation.
In recent years, the Julia language has been gaining popularity by the modeling and simulation community (Elmqvist, Henningsson, and Otter 2016).Naturally, Julia packages for power system modeling and simulation of power systems have also emerged, with PowerSimulationsDynamics.jl for power system dynamics and for power systems operations called PowerSimulations.jl (Henriquez-Auba et al. 2021).While these packages do require the user to specify their models in discretized form and target a specific solver, as in the case of the MATLAB and Python-based tools described above, they do require the user to specify models with pre-defined data structures and the resulting models can only be used with the solvers available within the Julia ecosystem (Henriquez-Auba et al. 2021), not to mention the models have not been validated against any other reference software tool.
Regardless, as each of the afromentioned tools define their own approach for model implementation, the means to define parameter data and support only specific solvers, the results obtained will be different.
In contrast, Modelica facilitates the re-use of models among different Modelica-compliant tools by defining interoperable libraries, with the models of each component implemented separately and without the need of a numerical solver.There are several power system analysis libraries based on Modelica, (Winkler 2017) gives an overview of all available open-source libraries for power system dynamic analysis and highlights the advantages and disadvantages of each library.Note that most libraries listed are for positive sequence phasor-based dynamic simulation.In addition, it is worth mentioning MSEMT: an advanced Modelica library for power system electromagnetic transient studies (Masoom et al. 2021).This paper enhances and expands the OpenIPSL library, which focuses on power system models in the phasordomain that have been validated against PSS®E.In that regard, some recent examples of models validation for renewable energy sources and battery energy storage systems are given in (Fachini et al. 2021).

Contributions
The use of the object-oriented equation-based modeling language, Modelica, allows for unambiguous power systems modeling.The flexibility of the language offers options to model a component, either by using typical block diagram representations or by defining mathematical equations that describe its dynamic behavior.The classical approach to validate a component's dynamics is by creating a small reference power network model, like an SMIB as used herein.As shown in Section 3, using the Modelica language it is also possible to validate each individual sub-system component within a model by using the reference tool's output signals and connecting them to the inputs of the newly implemented model.This simplifies the modeling process as it allows to isolate the specific individual part of the model that is being implemented in Modelica, instead of having to use it in a small reference power network as it is necessary for the traditional software tools to perform simulations.
Explicitly, the contributions of this paper are as follows:

Guidelines
In this section the approach of modeling power systems components in Modelica is described.

Template Models for Modeling and Validation
A basic example of electric power system network is the SMIB.Its block diagram in Modelica is given in Figure 1.This system is used to model a power plant with its controls connected to the rest of the grid through transmission lines and substations represented by buses.This small network also defines the model to standardize the testing of different device models implemented in Modelica and having PSS®E models as reference.
In Figure 1, in the red block, a complete power plant is modeled with a generator, connected to bus GEN1, and its controls.The grid is represented by the generator connected to bus GEN2.Between GEN1 and GEN2 other power systems components are considered like lines, a load and a ground fault.The bus SHUNT also allows to connect other components to this small network.Depending on the type of power systems component to model, the configuration of the generating unit (red block) connected to bus GEN1 varies whereas the configuration of the rest of the network (green block) remains the same.
In the sequel, components in the red block of Figure 1 will be implemented and validated.Note that for all the tests, the remainder of the power system in the green block of Figure 1 remains unchanged.

Model Implementation Guide
The modeling implementation process is defined in Figures 2 and 3.While the approach is generic, the process depicted considers PSS®E the reference software tool.In Figure 2 the process of implementation starts with the assignment of a model to implement (a).The identification of available technical information (b) about the model is necessary to the model implementation in Modelica.If the PSS®E manuals do not present sufficient information about the model's dynamics then it is necessary to find additional literature (c) that can help understanding how the models were implemented within the reference tool.Once the documents describing the model have been identified, collected and analyzed by finding the block diagrams and/or the equations of the model (d), it is possible to determine if the building blocks of the model are already present in the OpenIPSL library (e).It might be required to implement missing blocks or functions (f) before building the entire component model with the appropriate initialization of its sub-blocks (g).To assess the validity of the model to implement, a small test network (SMIB) is used in both Modelica and the reference software, and generating the reference results from PSS®E (h).That means the SMIB network with the target model needs to be assembled both in PSS®E (i) and Modelica (l).After that the software-to-software validation can be performed  (m) following the model validation guide (n) (see Figure 3).

Model Validation Guide
The process of model validation is defined through the flowchart in Figure 3 and it comes after the process of Figure 2.After assembling the SMIB in PSS®E it is necessary to obtain the steady state computation results of a "power flow" (1), export them (2) and provide them as initial guess values to solve the initialization problem of the corresponding SMIB in the Modelica compliant software tool (3).The OpenIPSL library used in this validation process describes the dynamic behavior of power system components therefore it relies on external tools for the power flow calculations necessary for initializing the models.The import of the power flow results can be made manually or automatically (Dorado-Rojas et al. 2021), the latter increasing numerical accuracy and reducing human errors.Next, the scenario for the dynamic simulation in both tools can be defined (4) and a dynamic simulation of the SMIB in both softwares can be run (5).Once the results are generated the quantities to compare can be chosen (6) and exported in the appropriate format (7) to be used in another tool, for example CSV Compare4 (8).Tools like CSV Compare allow to quantify the discrepancies between the simulation software tools after defining an acceptable tolerance level (see Figure 4).If the errors between the quantities to compare are within the tolerance band (9) then the validation is complete (10).If the er- rors are bigger than the defined tolerance then more debugging (11) of the model is required.A better insight of the model dynamics can be obtained by comparing subcomponent inputs, outputs and states of the implemented model (an example is given in Section 3) with the analogous signals from the SMIB in PSS®E ( 12).The iterative process continues until the difference between signals is lower than the tolerance (13), meaning that the validation is completed.This process can be part of a continuous integration and regression methodology, such as the one described in (Baudette et al. 2018).

Use Cases
In this section some key use cases of the implementation of power system components are described following the steps in Section 2. The verification illustrated through the plots of some quantities includes a software-to-software validation between PSS®E and different Modelica compliant platforms.

Implementation
An example of the difficulties faced when implementing a standard power system model like those of power system stabilizers (PSSs) PSS2A and PSS2B is given in this section.The reference software tool PSS®E comes with several manuals to help understanding the implementation and behavior of the different components present in its libraries.In some cases, like for the aforementioned PSSs models, the documentation is insufficient and not helpful to understand the behavior of one of the blocks of the models.In particular, this block is the ramp tracking filter highlighted in Figures 5 and 6.
An initial implementation of the ramp tracking filter in Modelica revealed to be not accurate compared to PSS®E implementation.This result led to additional investigations about the ramp tracking filter block.Because the PSS®E documentation does not offer more details, then the idea of analysing the continuous time trajectories of the states of this block was used.This idea was derived  considering the available information, that needs to be appropriately selected, included in the simulation results of a SMIB test system in PSS®E with one of the PSSs.So from PSS®E it is possible to analyze the dynamics of the ramp tracking filter block through its input, output and states.A visual illustration of the implemented corrections when the filter model was debugged is given in Figure 7.The Modelica code for the ramp tracking filter model is given in Listing 1.With this kind of implementation several features of the Modelica language have been used.The language is object-oriented and, in this case, it allows for the creation of arrays of transfer functions to build the model.This implementation is transparent and selfdocumented without leaving any uncertainty about the dynamics of the component as opposed to the de facto standard proprietary tools of the power systems domain that are not always well documented, or as in this case, the documentation of the software was erroneous.In addition to that, the level of abstraction and portability with the Modelica language is superior.The implementation of the ramp tracking filter has been tested first with the component alone as in the system of Figure 8.A ramp signal has been applied as input and the following parameters: T 1 = 0.5, T 2 = 0.1, M = 5, N = 1 for the filter have been used.The choice of the parameters of the ramp tracking filter has been derived from the reference example of Figure 11.By varying those parameters it is possible to obtain the desired ramp tracking behavior (Bérubé and Hajagos 2007;Berube, Hajagos, and Beaulieu 1999).
The results of the test in Figure 8 are given in Figure 9.

Validation
The new implementation of the ramp tracking filter has been introduced in the PSS2A component model.The Modelica model of PSS2A corresponding to the one in Figure 5 is given in Figure 10.The component PSS2A has then been tested in a small network like a SMIB.The PSS®E benchmark system is illustrated in Figure 11.
The corresponding SMIB implementation in Modelica is given in Figure 12.
The tested scenario for the SMIB consists of a 3 phase fault to ground applied at bus FAULT at t = 2s for 0.15s.The results are plotted in Figure 13.
A multi-platform software-to-software validation of PSS2A using the same SMIB system in Figure 12 with the same scenario is given in Figures 14, 15, 16 and 17.The simulations in the different tools have been performed with the same tolerance (1e-06) and the same output interval length (0.001s).
Another feature of the Modelica language is the possibility to implement models in the traditional way using block diagrams, like PSS2A, or with coding, like the ramp tracking filter.The graphic layer and the text layer of a model are linked to each other without the need to work on both separately like in the standard software tools, which is illustrated next.The PID with non-windup limits included in the model in Figure 18 is represented in Figure 19.
The challenge of the implementation of this component was represented by the integrator block inside the PID block.From (Murad and Federico Milano 2019) it is clear that for the same component, like a PI, there can be different implementations.In our case, to find the right representation of the dynamics of the PID block it has been necessary to check the state of the integrator.The interpretation has been facilitated by output of the PID block together with the state of the integrator of the PID during a dynamic simulation in PSS®E of the SMIB including the DC4B model.The considered scenario is a 3-phase fault applied at bus FAULT at t = 2s for 0.15s.The corresponding SMIB in Modelica is given in Figure 20.The time trajectories of the PID output and its integrator state from PSS®E for the bus fault scenario are illustrated in Figure 21.
From Figure 21 it is possible to see that when the output of the PID reaches its limits the state of the integrator freezes to avoid windup effects (the so called conditional integrator).This observation led to the Modelica imple-  mentation of the PID with non-windup limits as in Figure 22.
The Modelica text layer of the model in Figure 22 explains the behavior of the integrator of the PID (see Listing 2).To make the code more easily readable, in Listing 2 all the annotations, the lines indicating the blocks and additional parameters for the initialization of the model have been removed.
Modelica .U n i t s .SI ; 3 p a r a m e t e r SI .P e r U n i t K_P " V o l t a g e r e g u l a t o r p r o p o r t i o n a l g a i n ( pu ) " ; 4 p a r a m e t e r SI .TimeAging K_I " V o l t a g e r e g u l a t o r i n t e g r a l g a i n ( pu ) " ; 5 p a r a m e t e r SI .P e r U n i t K_D " V o l t a g e r e g u l a t o r d e r i v a t i v e g a i n ( pu ) " ; 6 p a r a m e t e r SI .Time T_D " V o l t a g e r e g u l a t o r d e r i v a t i v e c h a n n e l t i m e c o n s t a n t ( s e c ) " ; 7 p a r a m e t e r SI .P e r U n i t V_RMAX " Maximum r e g u l a t o r o u t p u t ( pu ) " ; 8 p a r a m e t e r SI .P e r U n i t V_RMIN " Minimum r e g u l a t o r o u t p u t ( pu ) " ; 9 equation

Validation
The software-to-software validation of the DC4B model against PSS®E has been performed to check the validity of the adopted modeling approach.For the verification the SMIB in Figure 20 has been considered with a bus fault applied at bus FAULT at t = 2s for 0.15s.Some results of the validation are given in Figures 24,25 and 26.An alternative approach for the validation of the DC4B excitation system, that Modelica flexibility allows for, consists of simulating only the block representing the DC4B component driven by external input signals collected from the reference SMIB network in PSS®E.This means that the Modelica model of DC4B can also be run  To prove this new approach the PID model in Figure 22 has been modified replacing the integrator blocks with an input so to use the integrator state trajectory as input to the model (see Figure 27).
Then a new test system in Modelica has been created as in Figure 28  Listing 3. Modelica code for the DC4B test system in Figure 28 Then the validation of the model has been performed comparing the DC4B exciter output (EFD) in a scenario of SMIB system, as in Figure 20, with a bus fault applied at bus FAULT at t = 2s and duration t = 0.15s.The results are given in Figure 29.In Figure 29 the output of DC4B for the SMIB in Figure 20, the corresponding SMIB in PSS®E and the new test system in Figure 28

Examples of interoperability: portable system modeling with unambiguous and homogeneous results
Finally, to demonstrate an additional value of implementing and validating models with the Modelica language, we highlight the portability of system models using validated components.This can be shown by running the simulation of an example of the OpenIPSL library in different software environments.The example of a SMIB with the exciter EXST1 has been chosen (see Figure 30).Some results of the simulation of the network in Figure 30 are reported in Figures 31 and 32.The plots show that the model gives the same results regarless of the tool being used, which means that tool-specific re-implementation can be avoided.
Another example is illustrated with the network model IEEE14 in Figure 33.simulation are given in Figure 34, where it is possible to see that once the models are validated they can give the same results as the reference tool with the same simulation settings even for larger networks.

Conclusions and Future Work
This paper formalizes and illustrates a procedure to implement power system models in Modelica with a softwareto-software validation methodology that is an important step for developing and maintaining a Modelica library using the concepts of regression testing and continuous integration.The guidelines illustrated in this paper are indispensable for the initial debugging of new models addressing all possible challenges of the time consuming reimplementation process in a systematic way.The guidelines were illustrated through key use cases that proved to be challenging to implement, this gives an idea of the difficulties faced when developing power system models from a reference software tool.Once the results of an initial validation are satisfactory then the software-to-software validation process can be automated using scripts to test different scenarios in the different simulation platforms.This work will be presented in a future publication.

Figure 2 .
Figure 2. Flowchart of the process of implementation of power systems models.

Figure 3 .
Figure 3. Flowchart of the process of software-to-software validation of power systems models.

Figure 4 .
Figure 4. Example of the use of the CSV Compare tool.

Figure 7 .
Figure 7. Original and new block diagram representation of the ramp tracking filter for the Modelica implementation.

1
model R a m p T r a c k i n g F i l t e r "Ramp− t r a c k i n g f i l t e r " 2 e x t e n d s Modelica .Blocks .I n t e r f a c e s .SISO ; 3 import Modelica .Blocks .C o n t i n u o u s ; 4 p a r a m e t e r Real T_1 ; 5 p a r a m e t e r Real T_2 ; 6 p a r a m e t e r I n t e g e r M = 5 " >=0 , M * N<=8 " ; 7 p a r a m e t e r I n t e g e r N = 1 " >=0 , M * N<=8 " ; 8 p a r a m e t e r Real y _ s t a r t = 0 " Output s t a r t v a l u e " ; 9 f i n a l p a r a m e t e r Boolean b y p a s s = i f M == 0 o r N == 0 then t r u e e l s e f a l s e " Boolean p a r a m e t e r " a n n o t a t i o n ( E v a l u a t e = t r u e ) ; 10 Continuous .T r a n s f e r F u n c t i o n TF1 [M] ( b= f i l l ( { 1 } ,M) , a= f i l l ( { T_2 , 1 } ,M) , each y _ s t a r t = y _ s t a r t ) i f b y p a s s == f a l s e " C o n d i t i o n a l component " ; 11 Continuous .T r a n s f e r F u n c t i o n TF2 [N] ( b= f i l l ( { T_1 , 1 } ,N) , a= f i l l ( { T_2 , 1 } ,N) , each y _ s t a r t = y _ s t a r t ) i f b y p a s s == f a l s e " C o n d i t i o n a l component " e i f M == 1 and N ==1 then 31 c o n n e c t ( u , TF2 [ 1 ] .u ) ; 32 c o n n e c t ( TF2 [ 1 ] .y , TF1 [ 1 ] .u ) ; 33 c o n n e c t ( TF1 [ 1 ] .y , y ) ; 34 e l s e 35 c o n n e c t ( u , TF2 [ 1 ] .u ) ; 36 f o r i i n 1 : N−1 loop 37 c o n n e c t ( TF2 [ i ] .y , TF2 [ i + 1 ] .u ) ; 38 end f o r ; 39 c o n n e c t ( TF2 [N ] .y , TF1 [ 1 ] .u ) ; 40 f o r i i n 1 :M−2 loop 41 c o n n e c t ( TF1 [ i ] .y , TF1 [ i + 1 ] .u ) ; 42 end f o r ; 43 c o n n e c t ( TF1 [M− 1 ] .y , TF1 [M] .u ) ; 44 c o n n e c t ( TF1 [M] .y , y ) ; 45 end i f ; 46 end R a m p T r a c k i n g F i l t e r ; Listing 1. Modelica code for Ramp Tracking Filter model

Figure 8 .
Figure8.Ramp tracking filter test with the original and final version (see Figure7).

Figure 9 .
Figure 9. Results of the ramp tracking filter test: reference ramp signal (red), original Modelica implementation of ramp tracking filter (blue) and final new implementation of ramp tracking filter (black) (see Figure 7).

Figure 14 .
Figure 14.Generator terminal voltage at bus GEN1 of the system in Figure 12.

Figure 15 .
Figure 15.PSS2A output of the system in Figure 12.

Figure 16 .
Figure 16.Active Power of the generator at bus GEN1 of the system in Figure 12.
Another example of model implementation is the exciter model DC4B.In Figure18the block diagram of the component from a PSS®E manual is given.

146Figure 17 .
Figure 17.Speed Deviation of the generator at bus GEN1 of the system in Figure 12.
Figure 19.Block diagram of PID with non-windup limits from PSS®E manual (Siemens Industry 2013).

Figure 21 .Figure 22 .Figure 23 .
Figure 21.Plot of the output of the PID and the state of its integrator from a bus fault simulation in PSS®E.

Figure 25 .
Figure 25.Time trajectory of the state of the integrator of the PID with non-windup limits included in the DC4B model.

Figure 26 .
Figure 26.Time trajectory of the state of the derivative part of the PID with non-windup limits included in the DC4B model.
has been plotted.The system in Figure 28 takes the required input signals exported from the SMIB in PSS®E simulated with a bus fault as described before.

Figure 32 .
Figure 32.EXST1 output of the system in Figure 30.

Figure 34 .
Figure 34.Voltage at bus 1 of the IEEE14 model with a fault to ground at bus 4.