1

Modeling and co-simulation of Wind generator control

systems using Simulink® interfaced to PSS/E

Kah Leong, Koo, Member, IEEE, Member, IEE

Shaw Power Technologies International Limited,
Knutsford, Cheshire WA16 8BW,
Manchester, England.
Email: kahleong.koo@shawgrp.com
Tel: +44 (0) 1565 650388
Fax: +44 (0) 1565 750376
Website: www.pti-us.com

Summary—A practical method of modeling wind generator control systems for network simulation using
® ®
Matlab-Simulink is presented. The interface developed between PSS/E and Matlab-Simulink allows the models
generated to be used directly in PSS/E dynamic simulation. Fundamentally, modeling involves understanding the
dynamics of equipments to be modeled and deriving the differential and algebraic equations which are coded using
a high level computing language. For network elements resilient to change, the latter remains the method.
However, wind generator controls change rapidly as new designs emerge in the market place and different
manufacturers compete against each other with better designs. Detailed dynamic models of these controllers are
required for performing transient stability studies on networks. It would benefit engineers if these models can be
created and incorporated quickly and effectively in networks for transient stability studies using a power system
tool like PSS/E. It is important that this interface can - (1) establish the correct steady-state network conditions for
the Simulink wind controller models, (2) establish the correct time-step solution between the Simulink wind
control models and the network and (3) deal with the different configurations and models used in a network with
embedded wind generation. The interface has to handle and recognize these different processes and provide a
coordinated interchange of data as required in an efficient manner to achieve acceptable performance. Illustration
of a dynamic simulation on a network is carried out using PSS/E with Simulink wind control models of a GE 1.5
MW wind generator with tabulated performance for comparison.

Index Terms— wind, induction generator, controller, pitch control, dynamic, modeling, simulink.
 2

I. NOMENCLATURE

ETERM Terminal voltage in P.U.

ITERM Induction generator terminal current in P.U.
PORD Desired active power of induction generator in P.U.
QORD Desired reactive power of induction generator in P.U.
PMECH Mechanical power of turbine in P.U.
VREF Voltage regulator set point voltage in P.U.
AVR Automatic voltage regulator.
GOV Governor.
ωrot Speed of induction generator (rad/s).
ωref Set point speed for wind controllers (rad/s).
Iinj Norton equivalent current in P.U.
API Application Programming Interface.

II. INTRODUCTION

WIND generation is an important renewable and sustainable energy resource and its contribution to energy needs
has a place not only in economic terms but has strong political support. Their increased capacity into the grid will impact
on power systems. Because of the different characteristics of wind generators, the ability to assess their influence in the
network is critical for their smooth operation within the grid. In particular, the work undertaken here to study the dynamic
aspects of the wind generation places importance on wind generation controls which affect damping of oscillations in
power systems. The many different kinds of induction generators with a large array of control configuration types mean
different behaviors can be expected from their connection to the network. Whereas, simplified models would have
sufficed in the past, this is no longer the case as their contribution to energy generation is rapidly increasing, where
detailed models are now required to perform stability assessment in the network. Constantly evolving wind controller
designs by manufacturers to meet different specifications and to better performance mean power engineers would need to
model them and tune the parameters to get the desired performance in order to carry out network studies. The
development of these models and integration of the coded models into any power system analysis tool is costly in terms
of man hours and presents obscurity in the coded form. A software method that allows rapid prototyping of these kinds of
controllers would be a solution.

In recognizing these difficulties, a block diagram approach to modeling these control systems with standard building
block functions and an ability to avoid a one off code development would be a practical and logical solution. The Matlab-
Simulink® environment was chosen because it has extremely powerful modeling features with extensive libraries being
provided through a graphically based interface to allow accurate models of control systems to be created. Matlab-
Simulink® is used across a broad range of industries from engineering to bio-medical for the modeling of highly complex
systems. By using Matlab-Simulink® will cater for all the modeling needs through not only a graphically based
environment but also the ability to create custom libraries. To further extend the modeling capabilities, the use of S-
functions allows a Matlab-Simulink block to be described using a computer language which can be in MATLAB®, C,
C++, Ada, or Fortran.

The PSS/E to Matlab-Simulink Interface (PMSI) provides a link from PSS/E to Matlab-Simulink® environment. This
allows models to be independently constructed using Matlab-Simulink®, saved as a Matlab-Simulink model and directly
used in PSS/E dynamics simulation. Using this approach allows both the Matlab-Simulink® modeling capabilities and
PSS/E real network modeling and simulation capabilities to be utilized in unison.

There are many difficulties to overcome in order that a successful interface can be implemented between PSS/E and
Matlab-Simulink® to obtain acceptable accuracy and speed performance. This paper describes the main areas tackled in
implementing this interface, PMSI (PSS/E to Matlab-Simulink Interface). This interface in effect de-couples PSS/E from
Matlab-Simulink® and actively controls the different processes between PSS/E and Matlab-Simulink® during actual
 3

simulation carried out by PSS/E. It also describes the procedures when using PSS/E to run PMSI and gives an overview
of the simplistic and transparent nature when using PSS/E to run the PMSI in controlling the co-simulation of Simulink
models in the Matlab-Simulink® environment.

Simulated results are presented for both PSS/E user defined models developed via user-written code and Matlab-
Simulink models on an example PSS/E network to compare the accuracies and execution times. This approach of directly
using Simulink models of wind generator controllers through the interface has demonstrated its feasibility and the benefits
that can be gained from it. This paper also explains and demonstrates how this modeling is performed with the models
then simulated as part of PSS/E in a network simulation.

III. IMPLEMENTATION OF PMSI

There are four main areas tackled to derive the right technical design for implementation. Firstly, to adopt a block
configuration that is flexible and general enough to accommodate the modeling requirements. Secondly, to derive the
right initial conditions for the Simulink models in relation to PSS/E network conditions. Thirdly, to obtain dynamic
responses from the Simulink models in relation to PSS/E network conditions. Fourthly, to handle, the data interchange,
synchronization and the different PSS/E calculation modes with Matlab-Simulink® during a network simulation. The
PSS/E modes of calculation are used to decide which type of calculation is required for Matlab-Simulink® at the different
stages of the dynamic simulation.

IV. CONFIGURATION OF WIND CONTROLLER MODULES

Figure 1 shows a typical configuration of a wind generator controller system which includes also the electrical
controller block to allow doubly fed induction generators to be included.

The main modules in Figure 1 labeled M 1 and M 2 separates the wind generator controllers into the mechanical and
electrical component analogous to an AVR and a GOV of an AC generator. M 1 comprises sub-modules SM 1 to SM 4
and main module M 2 is equivalent to SM 5 which can easily accommodate additional sub-modules if required. The main
modules and the different sub-modules reflect actual physical arrangement in wind generator controller systems. It is
logical that this modular approach is adopted when considering the design and implementation of this method by the
PMSI in modeling the controllers. These main modules (M 1 and M 2) and sub-modules (SM1 to SM5) can be
individually modeled and gives the modeling flexibility by allowing different module combinations to be used. The
significance of this approach can be appreciated where in the case of the main module M 1 being modeled means a direct
coupling of this model to the induction generator. Hence, this approach gives total freedom to configure this controller
model to match different induction generator types from the doubly-fed induction generator types to conventional squirrel
cage induction generator types (model accuracy for this type will depend on operating speed).
 4

M1

WIND GEAR
COMPONENT AERODYNAMICS BOX
PMECH
SM 1 SM 2 SM 3

PITCH
CONTROLLER
SET 1 I/P
SM 4

M2

GENERATOR ELECTRICAL
CONTROLLER
PORD,
(FOR DOUBLY FED IG)
QORD
SET 2 I/P
SM 5

Figure 1 - Layout of the various wind generator controller modules.

V. INITIALIZATION OF WIND CONTROLLER MODULES

The initialization is an extremely important process given the different modules and sub-modules that can be
individually modeled. Depending on which of the modules are modeled, the individual signals which form the inputs and
outputs will have to be carefully selected to avoid incorrect initialization. This involves determining which signals should
be constrained and which should be unconstrained. The overall initialization problem can be described by equations (1)
and (2) which are applied to these modules when finding the equilibrium point:

Fn = f (* Xi / p1, i / p 2, i / p 3, etc., X 1, X 2, X 3, X 4, X 5,...) .………….. (1)

Fn = C n ……………………………………………………………….. (2)

Cn represents the fixed constraint normally specified or determined from the steady state load flow calculations.
Equation (1) which is a function of the set of inputs *Xi/p, X1, X2, X3, X4, X5,,… must be solved to satisfy equation (2).
Where there are external inputs that are provided, these cannot be varied. *Xi/p with the asterisk denotes input or inputs
which are unbounded to match the requirement of the fixed external constraint Fn [8].

The GE 1.5 MW wind generator model which has been developed in PSS/E will be used in illustrating how some of
these modules can be modeled using the Matlab-Simulink® approach.
 5

When initializing the pitch controller (sub-module SM 4), the ‘SET 1 I/P’ of Figure 1 corresponds to the set of inputs
shown in Figure 2. Referring to equation (1), *Xi/p1 will be the reference input ωref and X1, X2, X3,,…will be rotor speed
ωrot, desired real power Pord respectively and Fn corresponds to the blade pitch angle θ. Using the known set of variables,
the initial conditions for the Simulink wind pitch model can be calculated by Matlab-Simulink including the reference
input. Figure 3 shows the flow paths for the signals exchanged between PSS/E and Matlab-Simulink® automatically
handled by PMSI. The intermediate modules for the pitch model are modules that are not modeled in Matlab-Simulink®
but which form part of the initialization loop. The vector output Iinj is the Norton equivalent current injected to the PSS/E
network by the induction generator.

Pord ωrot PMSI PROGRAM:

- CONTROLS
θ INITIALIZATION
ωrot SIMULINK WIND
Intermediate
PITCH
modules *ωref
Pord MODEL: θ
*ωref Pord ωrot θ
*ωref e.g. TGPTCH.MDL
Iinj SIMULINK PITCH
MODEL SM 4
SM 4 PSS/E APP.
* denotes signal initialization to be determined
in Matlab-Simulink®

Figure 3 – Initialization flow paths for Simulink model

Figure 2 - SM 4 Module of Figure 1 showing actual of sub-module SM 4.
SET 1 I/P input signals.

When initializing the electrical controller (sub-module SM 5), the ‘SET 2 I/P’ of Figure 1 corresponds to the set of
inputs shown in Figure 4. Referring to equation (1), *Xi/p1, *Xi/p2 will be the reference inputs for ωref and Vref and X1,
X2, X3,,…will be terminal voltage Eterm, terminal current Iterm, and rotor speed ωrot, respectively and Fn corresponds to the
desired real power Pord and desired reactive power Qord. The initial conditions for the Simulink electrical controller
model are solved using a similar approach with that of SM 4. Figure 5 shows the flow paths for the signals exchanged
between PSS/E and Matlab-Simulink® for SM 5. It is important to note here that the set of module interface signals
(signal inputs and signal outputs) are not confined to the ones shown in the figures which are shown only for the GE 1.5
MW wind generator model.

Eterm
Eterm Iterm PMSI PROGRAM:
SIMULINK ωrot - CONTROLS
Iter INITIALIZATION
GENERATOR Intermediate Pord
ELECTRICAL Pord modules
Qord
ωrot CONTROLLER MODEL Eterm Iterm ωrot Qord
(FOR DOUBLY-FED IG):
*Vref Pord
Qord *ωref *Vref
*Vref e.g. CGECN1.MDL *ωref
Iinj
SIMULINK
*ωref GENERATOR
PSS/E APP.
ELECTRICAL
SM 5
CONTROLLER MODEL
* denotes signal initialization to be determined SM 5
in Matlab-Simulink®

Figure 4 - SM 5 Module of Figure 1 showing actual Figure 5 – Initialization flow paths for Simulink model
SET 2 I/P input signals. of sub-module SM 5.
 6

As shown in Figure 1, this layout was adopted to allow flexibility in modeling wind controllers. As previously
described, the sub-modules can be individually modeled using Matlab-Simulink®. Similarly, the main module M 1
(comprising SM 1, SM 2, SM 3 and SM 4) can also be individually modeled. This means M 1 can be constructed to
encompass the wind component, aerodynamics, pitch controller and drive train in totality if required, for example if
model changes has a wide impact on all sub-modules and their interconnections, this might be a more logical approach.
When initializing M 1 (we will term mechanical controller analogous to a GOV of an AC generator), the ‘SET 1 I/P’ of
Figure 1 corresponds to the set of inputs shown in Figure 6. Referring to equation (1), *Xi/p1 will be the reference input
for ωref and X1, X2, X3,,…will be rotor speed ωrot, desired real power Pord respectively and Fn corresponds to the turbine
mechanical power
power Pmech. The input denoted by etc. in Figure 6 signifies other available input signal types for use in
constructing the model. The initial conditions for the Simulink mechanical controller model are solved in a similar
approach to what has been described earlier. Figure 7 shows the flow paths for the signals exchanged between PSS/E and
Matlab-Simulink® for M 1.

Pord ωrot PMSI PROGRAM:

ωrot - CONTROLS
SIMULINK MECHANICAL Pmech INITIALIZATION
CONTROLLER MODEL:
e.g. TMECH.MDL Intermediate
Pord modules *ωref
Pmech *ωref Pord ωrot Pmech
*ωref SM 1 SM 2 SM 3
Iinj SIMULINK MECHANICAL
CONTROLLER MODEL:
etc. PSS/E APP. e.g. TMECH.MDL
SM 4 Main module
M1
M1

Figure 6 – M1 Module of Figure 1 showing sub- Figure 7 – Initialization flow paths for Simulink model
modules modeled as a single Simulink model. of main module M 1.

Note: This section has been describing the use of these modules individually for the purpose of clarity in explaining
the interactions involved. It is essential to point out that these modules modeled as Simulink models can be
combined to form the complete wind controller configuration and used together in parallel in a dynamic
simulation. And in the case of coupling to a non doubly-fed induction generator type, the module combination
would be without M2 or SM 5.

VI. DYNAMIC STAGE OF WIND CONTROLLER MODULES

The dynamic stage of the wind controller modules is entered when the time-step solution starts. This is the useful stage
where the transient stability behavior of the network can be studied by simulating the appropriate disturbances. The
objective of the transient stability study is to look at power and control stability behavior. Hence, the level of detailing
required for our models are sufficiently described by electromechanical models in simulating the transient behavior in the
power cycle timeframe (typically a few milliseconds to 100 seconds).

Upon successful completion of the initialization stage described in (B), the time-step solution for dynamics can begin.
This is also the same requirement for any PSS/E models. The initial conditions which have been solved for the Simulink
models are restored to the models during the time-step calculations as the integration method is not self starting. During
the time-step solution of the PSS/E network, the time-step solution for any Simulink models being simulated during any
PSS/E time-step is calculated in Matlab-Simulink®. The calculated results are then passed back to PSS/E within that
PSS/E time-step from Matlab-Simulink®.

Each of the Simulink models being simulated is a function of their inputs, states and time. The PMSI ensures that the
states of the Simulink models are automatically stored at the end of every time-step and automatically restored at the start
 7

of every time-step. Note that these are Matlab states that are calculated by Matlab-Simulink® for the Simulink models.
The inputs which represent the external inputs from the network are updated at the start of every new time-step. Figure 8
illustrates the external signal flow paths between PSS/E and the Simulink model for the pitch controller model during the
dynamic stage. The essential difference in the flow paths to that of the initialization stage is that now the SM 4 pitch
controller output, θ is extracted from the Simulink model to drive the other modules. Figure 9 shows the sub-module SM
4 Simulink model of the pitch controller. The Simulink model input and output ports provide the channel for the external
signals described for the flow paths.

Pord ωrot PMSI PROGRAM:

- CONTROLS TIME-
*ωref STEP SOLUTION
Intermediate
modules θ
*ωref Pord ωrot θ
Iinj
SIMULINK PITCH
PSS/E APP. MODEL SM 4

Figure 9 – Simulink model of pitch controller being

Figure 8 – Flow paths for Simulink model of pitch simulated.
controller during time-step solution.

The external signal flow paths for the other modules will be similarly altered for the time-step solution. For example,
Figure 10 shows the Simulink model of sub-module SM 5 of the generator electrical controller. The controller outputs
Pord and Qord are now extracted from the Simulink model to drive the other modules during the dynamic stage.

VII. DATA COMMUNICATION, SYNCHRONIZATION AND

CALCULATION MODES.

The PMSI main roles are highlighted in Figure 11.

These are: (i) The calculation modes, (ii) The data
communication, (iii) The synchronization between
PSS/E and Matlab-Simulink®, (iv) The mapping of
PSS/E network elements to Simulink models.

The different stages of a PSS/E dynamic simulation

are reflected in the nature of the calculation types being
imposed on any Simulink models used in the
simulation. These PSS/E modes are interpreted by the
PMSI and are used to control the nature of the Simulink
model calculations in Matlab-Simulink®.

Figure 10 – Simulink model of generator electrical During the different stages of the simulation, network
controller being simulated. information and results of the Simulink model
calculations are interchanged between PSS/E and the
Simulink models. This process where the different data
 8

are exchanged is critical to the performance of the dynamic simulation. The PMSI dynamically allocates space for the
required data and makes available to Matlab-Simulink® workspace only the appropriate data for the simulated model at
any instant. This data then becomes immediately available to the Simulink model being simulated at this instant in time.

The PMSI has to provide the correct pathway between the PSS/E network equipment that is connected to the equipment
modeled as a Simulink model. A map which traces these links is only generated each time the PSS/E application program
is invoked. This is the case to allow any PSS/E network changes to be reflected in the map constructed by PMSI. In any
simulation, this map is used to uniquely identify the exact location to which the data between PSS/E and the Simulink
model are interchanged.

It is important to point out that during the dynamic simulation, two different application programs are being executed in
parallel. PSS/E through the PMSI invokes Matlab-Simulink® and controls this later part of the simulation through Matlab
engine functions which are made available through its API. During the real time simulation carried out by PSS/E, the
PMSI synchronizes the separate processes between the PSS/E application program and Matlab-Simulink® application
program. The synchronization is crucial as these different processes, although independent must be interrupted during the
different stages and also during the time-step calculations for the dynamic stage. For example, for any particular time-step
calculation of a Simulink model, that PSS/E time-step simulation has to be in a wait state until the result of the time-step
calculation is available from the Simulink model.

PMSI INTERFACE PROGRAM:

• Controls the different modes of dynamic simulation.
• Handles the data communication.
• Controls synchronization.
• Controls mapping between PSS/E elements and Simulink models.
• Etc…..

®
MATLAB-SIMULINK APPLICATION
PROGRAM:
PSS/E APPLICATION PROGRAM:
• Provide the main network simulation. • Provide modeling environment for Simulink
Wind Controller models.
• Provide simulation environment for Simulink
Wind Controller models.

START.SAV
NETWORK FILES START.MDL SIMULINK
(E.G. WIND.SAV) MODEL FILES (E.G.
CGECN1.MDL, TGPTCH.MDL)

Figure 11 – Block diagram illustrating top layer hierarchy of the programs and files interaction.
 9

VIII. SIMULATION RESULTS ACCURACY AND SOFTWARE PERFORMANCE

PSS/E remains the main driving program with the PMSI participating in the background. The PMSI becomes active
when Simulink models are being simulated but nevertheless remains transparent to the user. The normal procedures in
performing the dynamic network analysis in PSS/E remain unchanged. The PSS/E base case network shown in Figure 12
used for testing the PSS/E user written model of the GE 1.5 MW wind model is also used here for running the Simulink
wind controller models.

There are three main stages involved in using Simulink models in a PSS/E dynamic simulation. Firstly, create the
Simulink models of the required wind controller modules using Matlab-Simulink®. Secondly, informing PSS/E of the
Simulink models to be used through its dynamics data input file which generates the necessary calls to the PMSI
functions. Finally, PSS/E compiles and links these objects into its DLLs for its executable.

PSS/E can now use the desired Simulink models as part of its network dynamic simulation by making the calls to these
models as required during the simulation. For this simulation, the Simulink models of modules SM 4 (Figure 9) and SM
5 (Figure 10) of the pitch and electrical controller respectively are going to be used.

The dynamic study emulates low frequency power oscillations to demonstrate the damping characteristics of the wind
controllers by applying a bus fault at BUS 101 shown in the network diagram of Figure 12 at 0.2 second lasting for 0.2
second. The duration of the study lasts for 15 seconds.

Figure 12 – The PSS/E network view in PSS/E application showing network used in the dynamic simulation.
 10

Figure 13 – Multi channel PSS/E dynamic plots for 3 wind controller parameters (6 plots in total) superimposed for
comparison. Note – Plots 4, 5 and 6 are dynamic plots from running Simulink models and Plots 1, 2 and 3 are dynamic
plots from running PSS/E user code written models.

TABLE I

COMPARISON OF ELAPSED TIME IN SECONDS BETWEEN DYNAMIC RUNS USING PSS/E USER CODE WRITTEN MODELS AND
USING SIMULINK MODELS
USING PSS/E USER WRITTEN MODELS USING SIMULINK MODELS FOR PITCH CONTROLLER
(SM 4) AND ELECTRICAL CONTROLLER (SM 5)
COMPARISON FOR A DYNAMIC RUN OF 3 SECS.
5.18 seconds 46.7 seconds
COMPARISON FOR A DYNAMIC RUN OF 6 SECS.
10.6 seconds 93 seconds
COMPARISON FOR A DYNAMIC RUN OF 10 SECS.
19 seconds 154.8 seconds
COMPARISON FOR A DYNAMIC RUN OF 15 SECS.
32 seconds 235.3 seconds

Figure 13 show the plots for the pitch controller output (θ) and the turbine mechanical power (Pmech) at the bus where
the wind generation is connected. It also shows the desired power (Pord) from the electrical controller. The pitch angle
plot shows the output of the pitch controller reacting to the wind turbulence emulated by the fault disturbance. The Pmech
plot shows the damped mechanical power output of the wind turbine due to the pitch controller action. Dynamic runs
were obtained for the test network using PSS/E user code written models and using Simulink models. From the
 11

superimposed plots shown in Figure 13, it can be seen that the responses from the wind controllers for both the PSS/E
user code written models and Simulink models produce identical results. The accuracy achieved here is well above 99 per
cent.

The software performance data compiled is only for this network but other factors like the ratio of machine numbers
to the size of the network, the nature and severity of the disturbance, complexity and number of models used will
influence the performance. Table I shows the execution times for the dynamic runs using the network shown in Figure 12.
The comparison was carried out for Simulink models against the PSS/E user code written models for different duration of
dynamic runs. The elapsed time given in Table I gives the actual time elapsed between the start and end of the dynamic
study on a 647MHz Pentium III-PC running Windows-XP. The comparison indicates acceptable performance can be
obtained by this method.

IX. CONCLUSION

This paper has introduced and implemented a practical and efficient method of modeling wind controllers for co-
simulation using Simulink by interfacing it to PSS/E. This is an expansion on previous work which has been implemented
in PSS/E 30 [2], [3]. It has demonstrated:

1. A graphical approach to modeling using Matlab-Simulink® where models created can be directly used for co-
simulation processes.
2. The modular approach for practicality and the different processes required for this method can be successfully
integrated with PSS/E.
3. The desired accuracy is achieved with acceptable software performance.
4. The PMSI which bridges PSS/E and Matlab-Simulink® sits in the background with PSS/E driving the dynamic
simulation.
5. The Simulink models can be successfully initialized to the network conditions.
6. The Simulink models can successfully participate in the dynamic process at every time step between PSS/E and
Matlab-Simulink® environment.

The simulation that has been carried out and the comparisons made show the feasibility of this method and the benefits
that can be gained from it. This method allows for fast prototyping compared to a user code written model. If speed
performance is a critical issue, the validated prototype can be subsequently coded. This approach can be adapted for the
changing requirements of wind models and be developed for modeling of other devices such as FACTs devices and so on.

X. REFERENCES
Books:
[1] The Mathworks Inc. Copyright 1984-2004. Online Product Documentation For Release 14. [Online].

Technical Reports:
[2] Koo, K.L. “Modeling and co-simulation of AC generator excitation and governor systems using Simulink interfaced
to PSS/E”, IEEE Proceedings, paper presented at the Power Systems Conference and Exposition 2004, 10-13th
October 2004, New York City, New York.
[3] Koo, K.L. “Modeling of Plant Controllers using the PSS/E to Matlab-Simulink Interface (PMSI) in PSS/E 30”,
Newsletter Issue 96, October 2004, Shaw Power Technologies Inc.
[4] K.L.Koo, “PMSI User Manual For Prototype Program Revision 1.2 (Internal),” Shaw Power Technologies
International, Knutsford, Manchester, England, Oct. 2003.
[5] K.L.Koo, “PSS/E To Matlab Prototype Comparative Test Results Revision 1.0 (Internal),” Shaw Power
Technologies International, Knutsford, Manchester, England, Aug. 2003.
[6] Shaw Power Technologies, Inc. (2004, Oct.). Online Documentation PSS/E-30, Schenectady, NY. [Online].
[7] Power Technologies, Inc. (1992, Nov.) PSS/E Programmer’s Aid, Schenectady, NY.

Dissertations:
[8] K.L.Koo, “User Defined Models For Static Power Converters and Rotary Converter Set,” Ph.D. dissertation, Dept.
of Electrical Eng. And Electronics, Univ. Manchester Institute of Science and Technology, Manchester, 1996.
12