5-ETAP - User Defined Dynamic Models

Chapter 25
User-Defined Dynamic Models (UDM)

The ETAP User-Defined Dynamic Models (UDM) program is a graphic logic editor (GLE)
interpreter tool for the creation of user-defined governor, exciter, and power system stabilizer
models for synchronous machines, generic load and wind turbine generator models. This module
allows the models to be linked to ETAP’s transient stability program. The models can be built in
the ETAP UDM Graphic Logic Editor or can be imported from Matlab Simulink files. ETAP
uses these dynamic models at run time when conducting Transient Stability Studies. This tool is
fully integrated into ETAP to allow the creation of dynamic models.
The main application of the UDM module is to create and tune (validate) dynamic control
elements which are not part of the standard ETAP dynamic model library (built-in models). The
following types of controllers / dynamic models can be created with UDM:
1) Synchronous Motors Exciter / AVR models

2) Synchronous Generator Exciter / AVR models
3) Synchronous Generator Turbine, Engine / Speed Control models
4) Synchronous Generator PSS (Power System Stabilizer) models
5) Wind Turbine Generator Models
6) Generic Load Models (Lumped Load Element Dynamic Models)
7) Generic Controller Models (plant-level controls)
8) Energy-Storage Devices
The UDM interface also has the capability to assist in the selection of parameters or settings for
each of the controllers or dynamic models listed above. This capability is called, “Dynamic
Parameter Estimation and Tuning,” or DPET for short. DPET can be used to estimate the values
of the parameters which make the controllers respond as similar as possible to a field-measured
response (i.e. measurements from a staged test or field-recorded disturbance). The tuning of the
UDM model response is accomplished by using an iterative approach, which automatically adjusts
the tunable settings/parameters in the model to make the controller response match that of field-
recorded data. This process may also be known as, “automatic model validation parameter tuning.”
Combined with the UDM variable parameter capability, DPET adds a lot of time-saving
capabilities which can literally save hundreds of engineering man-hours previously spent on the
tedious process of model validation parameter tuning. Furthermore, a section on how to best use
DPET is included in this chapter.
This chapter also covers the basics of how to model, simplify, debug and configure initialization
routines required to make the models work properly for Transient Stability Studies.
ETAP 25-1 ETAP 18.0 User Guide

User-Defined Dynamic Models UDM Graphic Logic Editor
UDM Graphic Logic Editor

This section describes how to open the UDM interface and how to use all of its related general
toolbars and functionalities.
25.1.1 Accessing the UDM Interface

There are two ways to access the UDM Editor. The first method is from the system toolbar. The
second method to access the UDM Editor is from the synchronous generator editor individual
pages (Governor, Exciter & PSS pages), synchronous motor exciter page, dynamic page of the
lumped load editor and the Info page of the wind turbine generator editor. Please note that the
model type is inherited from the editor from which the UDM interface was accessed.
If you open the UDM Editor from the Individual Editors:

If the UDM Editor is opened from the synchronous generator, synchronous motor, lumped load
or wind turbine editor, any content that is not related to the individual element is filtered out.
This means that only the models created specifically for the given machine will be listed in the
model selection drop list. If there is no model created, then the UDM model selection drop list is
blank. Clicking on the UDM Editor Button opens the UDM Interface. At this time, a new model
can be created. When the model is saved, it will be associated with the element from which the
editor was accessed. The model can be associated with other elements or added to the model
library later on if required.
Once the UDM editor is opened from the generator element, the default directory for the file
“save” and “open” is the current project directory.
The following image illustrates the process of opening a UDM model for the first time from the
generator editor:
Once the model is saved, the model will be linked to the element for which it was created using
the following naming convention:
<Element ID>_<Type>_<Model Name>.

User-Defined Dynamic Models UDM Graphic Logic Editor
More on the naming convention is included under the file saving section of this chapter.
If you open the UDM Editor from the System Toolbar:

Opening the UDM Editor from the system toolbar allows you to modify all model files including
the ones in the current project directory or the ones from the library. The program file open and
file save directory are defaulted to the UDM library directory (\\ETAP Installation
Directory\UDM). However, it is possible to save and link to an element as long as the model is
saved in the project directory with the proper naming convention. If this is done, the model
would be linked exclusively to an element and can be accessed from the element itself.
The following image show how to access the UDM GLE Interface from the system toolbar by
clicking on the UDM Interface Icon:

User-Defined Dynamic Models UDM Model Files
Saving UDM Model Files

The UDM Interface saves the models using a *.udm extension. The files will be stored in two
locations. The first will be the project directory. The other will be the UDM library directory (i.e.
template directory).
If the models are saved to the library, then they will be saved in the following directories inside
of the ETAP installation director:
Governor Models \UDM\Gov

Exciter Models \UDM\Exc
PSS Models \UDM\PSS
Generic Load \UDM\Generic
Wind Turbine \UDM\WTG
Please note that the UDM directory is located inside of the ETAP installation directory such as
C:\ETAP7.5.1\UDM
Note: When naming the device and the UDM file, do not include period, forward slash or colon
in the name: “.”, “/”, or “:”.
Please note that you can also place Simulink files to be imported or converted to a *.udm
format by placing them in the same locations as described above.
Note: A*.mdl file can only be imported into the UDM editor. These files will only be visible to
the UDM Interface if the user selects the import or export function. The UDM import function
has been disabled for ETAP 16.0.0. It will be enabled in future versions of the UDM tool.

File Naming convention for UDM Models (files with extensions *.udm, *.bin & *.doc):
The files which are purposely saved as specific models for certain generators need to have the
following naming convention.
<Element ID>_<Type>_<Model Name>.UDM
Element ID-> Where the Element ID is the Element ID from ETAP Element. This could be the
synchronous generator or synchronous motor ID.
Model Name-> IEEE1, IEEEAC7B, GELM2500, etc, etc. This is the actual model name as
shown in the element editor UDM model selection drop list.
The types available are:
Type->EXC
Type->GOV
Type->PSS
Type->Generic
Type->WTG
For example: if an exciter from the library (i.e. IEEE1.UDM) is to be associated with Generator
1, then the file should be named:
“Gen1_EXC_IEEE1.UDM”
Other Examples would be:
“GeneratorXYZ_GOV_DT.UDM”
“EmergencyDiesel_EXC_IEEEAC7B.UDM”
“Gen1_PSS_STAB2A.UDM”
“SynchMotor_EXC_IEEE1.UDM”
“Lump1_GENERIC_CONV1.UDM”
“Lump2_GENERIC_SEQ1.UDM”,
Etc, etc.
This naming convention achieves the following:
If the Type is EXC, then this file is only visible from the Exciter pages of the Synchronous
Generator and Motor. If the Type is GOV, then the model is only visible from the Governor page
of the synch generator and finally, if the type is PSS, then it would only be visible from the PSS
page. If the Type is GENERIC, then this file is only visible from the Dynamic Page of the
Lumped Load. If the type is “WTG” then the models are only visible from the WTG editors.

The following file types are also generated by the UDM GLE Interface after the model is
compiled:
*.DOC, *.BIN, *.LK, *.SC
The *.bin files generated by the compiler have the following naming convention:
<Element ID>_<Type>_<Model Name>.bin
The *.doc files generated by the compiler have the following naming convention:
<Element ID>_<Type>_<Model Name>_data.doc
The *.LK files generated by the compiler have the following naming convention:
<Element ID>_<Type>_<Model Name>.lk
This file is created when the models include lookup table elements with significant amount of
imported data.
The *.SC files are generated by the compiler have the following naming convention:
<Element ID>_<Type>_<Model Name>.sc
The *.sc files are created when the models include any DPET study cases.
This naming convention has the same purpose and it is to associate the models with their
respective elements.

25.2.1 UDM Editor Presentation

This section describes the toolbars, menu items and all the capabilities of the UDM graphic logic
editor interface. The image below shows the UDM Graphic Logic Editor Interface with a
governor model open. The interface also shows the Simulation (test mode) and the DPET mode
toolbar.
File Menu Items:

The file menu items allow the user to open, save and import information into the UDM Editor.
The following are the options available through this drop down menu:

New
This menu item allows the user to create a new UDM model.
Open
The “open” option allows the user to open a UDM model. The open function opens a dialog
which has a default directory. The default is the project directory. The file open dialog opens
only the files with extension *.udm.
Open from Library

This option is used to open the UDM models stored in the UDM model library directories for
Exc, Gov, Pss, Generic and WTG models. The location or path for this is always the ETAP
project in the UDM directory (i.e. C:\ETAP 800\UDM\). Once in the library directory, the user
can browse inside each directory and choose which file to open.
Close
Close the currently selected model.
Save
This option saves the UDM file into the current project directory unless the user specifies a
different location. Depending from where the file was opened, the save button will also link a
model to an element and type.
If the UDM model was opened from the generator editor, then upon saving, the program would
name the model as:
<Element ID>_<Type>_<Model Name>.UDM
If the UDM model was opened from the system toolbar, then the UDM modeled will be saved
based on the user given name. The program would not rename the model.
Save as
Saves the *.udm file as specified and where specified by the user. The remaining options to save
as EMF, GIF, PNG, BMP, JPEG, TIFF, SVG file are allowed and save the UDM model as a
graphical image.
Save to library
This function allows the user to save the current model as part of the library items. When saved
in the library, the user is free to specify the name and the interface does not follow the naming
convention since the model is meant to be a generic library model.
Import (from *.mdl Simulink files)

This function allows the user to import models into the UDM editor which were created in
Simulink . The following mapping table is used in order to map the inputs and outputs from
Simulink into the ETAP UDM Graphic Logic Editor format.
This feature has been temporarily disabled for ETAP 16.0.0 and will be enabled in future
releases.

If the type of the model is a GOV, PSS, Generic or WTG then the mapping table adjusts to show
the input and output ports for those elements only. Please note that any unmapped input and
output ports are removed, since they would not be supported by the ETAP compiler.
The blocks supported from Simulink which are recognized by the UDM compiler are shown
below:

Please note that any block which is imported into the UDM editor which is not supported is
automatically deleted in the imported UDM model. The import program supports imported
Simulink models up to version 7.11.0.584 (R2010b).
The models which can be imported into ETAP should follow the model design rules of previous
versions of the UDM compiler. If those model design rules are not followed, the model may not
compile properly in the new UDM compiler. Those rules are summarized below:
The maximum order of a transfer function (Transfer Fcn) block is a third order function.
The function types that can be used in an Fcn block consist of: sin, cos, tan, atan, abs, exp, sqrt, and
log.
The input/output variable names in Simulink can be specified arbitrarily and then mapped to ETAP
input/output variable names using the System Variable Selection Editor. This was true up to version
7.5.3. However, In ETAP11 we recommend using the following key words for the input/output
variable names. The appropriate key words reserved for ETAP UDM Turbine/Governor,
Exciter/AVR, and PSS models, are provided in the following tables:
Turbine/Governor Model
Key Word Description
Pe Generator Real Electrical Power
Input
W Generator Speed
Output Pm Turbine Output Mechanical Power
Exciter/AVR Models
Vt Machine Terminal Voltage
CVt Machine Terminal Voltage in complex form
It Machine Terminal Current
CIt Machine Terminal Current in complex form
Pe Machine Real Power
Input
Qe Machine Reactive Power
Vs PSS Signal
Ifd Machine Field Current
Fre Machine Terminal Voltage Frequency
PF Machine Power Factor
Output Efd Exciter Output Voltage

PSS Model
Vt Generator Terminal Voltage
W Shaft Speed
f Generator Terminal Voltage Frequency
Input
Pe Generator Real Power
Pm Generator Mechanical Power
Ang Generator Rotor Angle
Output Vs PSS Output Signal
Using these input/output variable names will simplify the import process significantly since in
ETAP11, those inputs and output names are fixed block types.
The check box “Save the imported UDM model into library” allows the user to automatically
same the imported model into the corresponding library of UDM models. This is done according
to the model type.
Export
This function allows the user to export the *.udm file into a *.mdl file. The export function
supports up to version 7.11.0.584 (R2010b) of Simulink.
The export function has been disabled in ETAP 16.0.0. It will be enabled in future releases.
Note: Default settings are used for the parameters not included in the *.udm model file.
Page Setup
Regular page setup function (landscape, portrait, page size, etc).
Print Preview
Regular print preview tool.
Print
Regular printing utility
Exit
Exit the project. Prompts if the file has not been saved or has been modified since the last save.

Edit Menu Items:

This menu list contains following functions:
Undo
Undo a certain action such as hiding or moving an element. You may also undo adding or
deleting a connection. The Undo feature can revert back up to 20 actions.
Redo
This option allows you to ‘Redo” up to 20 actions. The following image shows an example of the
“Undo” and “Redo” functions.
Delete Study Case

This menu item allows the deletion of dynamic parameter estimation and tuning (DPET) study
cases. The image below shows the delete window.

Cut
The Cut command on the Edit menu will delete selected elements from the workspace and place
them in memory. You can also cut selected elements by right-clicking and selecting the cut
command from the pop-up menu. To select a group of elements, click and hold the left mouse
button down while dragging the pointer across the elements you want to select.
Copy
The Copy command from the Edit Menu copies selected elements from the workspace. You can
also copy multiple elements selecting them (press and hold the left mouse button down while
dragging the pointer across the elements you want to select) and then right-clicking and pressing
the Copy command from the pop-up menu.
Paste
To paste an element or a group of elements from the memory, select the Paste command from the
Edit menu or you can right-click and select the Paste command from the pop-up menu.
Format
This option includes Fill and Shadow to set the inside color and shadow of the selected objects.
Basically, you can change color and format of the selected blocks in this section.

Fill
Under Edit menu go to Format then click on Fill. The “FillStyle Dialog” allows you to change
the background and fore color of the selected blocks. Also, different brush styles can be selected.
Shadow
Under Edit menu go to Format then click on Shadow. The “ShadowStyle Dialog” allows you to
configure the shadow for a particular element block. The shadow style is shown in the “Preview”
section.

View Menu Items:

The “View” menu contains the following functions:
Rulers
The horizontal and vertical rulers in the UDM Graphical Grapical Logic editor are often used to
align text, graphics, tables, and other elements in the workspace.

Symbol Palette
This option activates the Control Element Symbol Palette (shown on the left-hand side of the
workspace by default)
Properties
This command shows the properties window (shown on the right-hand side of the workspace by
default)

When copying and pasting elements from one model to another, the diagram size should be set to
a size appropriate to hold all the pasted elements. If this is not the case, the copy/paste action will
not take effect until the size is modified accordingly. The image below shows the location of the
diagram size dialog.

Pan Zoom Window

This window can be used to preview a panoramic view of the elements in the workspace. The
panoramic view can be modified by dragging the panoramic box around the workspace preview
window. This tool is useful to zoom in and out and to navigate through very complex and large
models.
There is a pin icon on top of the toolbox shown as . By clicking this pin you can Hide/Show
the toolbox in UDM.

Before:
After:

Document Explorer
This window provides good information about the elements in the selected model. It lists all the
elements by type. This tool can be used to navigate through the model elements and make
changes to the individual properties without having to find the block graphically in the
workspace.
Layers (will be available in future)

To add a block to a layer you need to make the layer active
while you are dragging the block to your workspace. If two
layers are active at the same time, the created block will
belong to both layers, and if you hide one of the layers, all
the blocks which belong to the layer will be invisible.
Element changes are applicable to all active layers. If an

element or connection is to appear only in one layer, then all
the remaining layers must be de-activated. Only the desired
layer should be active when the element block is added or the
connection is made.
The image below illustrates the end result of associating

some elements and connections to different layers. Elements
not active during simulation will not be considered active in
the mathematical calculations. This tool will not be active in
the first release of the UDM Graphic Logic Editor.

Model 1 Model 2
Layer 1 is Visible
Layer 2 is Visible
Layer 1 is Visible
Layer 2 is Invisible
Layer 1 is Invisible
Layer 2 is Visible

Header
With thisFooter
option you can add your desired header and footer to your model. The header and
footer contents can be customized by applying different font styles and colors.

Page Borders
You can select different borders, weight, and style. Also by changing the color and transparency,
you have the option to choose your desired color for borders.

Model Parameters
The model parameter section lists all the parameters used in the UDM model.
Please refer to section 25.4.2 for more details.
Actions Menu Items

After you select some functions block from Actions toolbar, the “Align” option can perform the
actions as described below:
Action Result
Align Left moves all blocks to the most left side of the reference block
Align Center moves center of all blocks to the center of the reference block
Align Right moves all blocks to the most right side of the reference block
Align Top moves all blocks to the top side of the reference block
Align Middle moves all blocks to the middle line of the reference block
Align Bottom moves all blocks to the bottom line of the reference block
Please note that the first block created is the reference block

Before After
Align Left Align Center Align Right
Before
Align Top
After Align Middle
Align Bottom

Flip
The flip option causes a reflection of the selected block. The blocks can be flipped horizontally
or vertically. The following image illustrates the result of flipping some blocks horizontally:

Rotate
This function helps to rotate selected object 90 degree clockwise or counter-clockwise. You can
activate the rotation by clicking the right mouse button and selecting the different rotate
commands from the menu.
Figure 17- Rotate Toolbar
Mouse right click
Figure 18- Using Rotate option from Mouse Right Click popup menu
Figure 19- Rotate Toolbar

Window Menu Item
Tabbed MDI
This is a control that allows you to use tabbed document interface and change the project
windows view as shown below:

Hot Keys/ Shortcut keys

These hotkeys work at the “model” level, not at the UDM editor window level. That is, you
must be inside the model tab to activate these keys.
• Ctrl+G = compiles model

• Ctrl+T = runs model test
• Ctrl+W = closes all plots
• Ctrl+U = open UDM library
• Ctrl+O = open project directory
• Ctrl+N = open new diagram
• Ctrl+S = save UDM file
• Ctrl+A = select all the blocks
• Ctrl+D = delete DPET study case
• Ctrl+Z = undo
• Ctrl+X = cut
• Ctrl+Y = redo
• Ctrl+C = copy
• Ctrl+V = paste
• Alt+F = open file option
• Alt+E = open Edit option
• Alt+V = open view option
• Alt+A = open actions option
• Alt+W = open window option
• Alt+H = open help option

Mode Toolbar
The mode toolbar selects which simulation mode is to be used for the controller or dynamic
model. The first option is “Simulation” or “Test” mode. The purpose of this mode is to allow the
running of simple test simulation routines on the models to check their performance. The second
mode is the DPET mode. The dynamic parameter estimation and tuning mode can be used to run
the model validation or tuning simulations. The mode toolbar is displayed below (both docked
and undocked).

25.2.2 Simulation (Test) Mode

This mode includes several simulation test routines, which can be used to check the performance
of the model after it has been created. The mode contains a specific compiler toolbar and test
routines which can be accessed through the parameters editor.
Translator (Compiler) Toolbar:

The translator / compiler toolbar is used to save, link and compile the UDM models in
preparation for their use in ETAP’s transient stability calculations. The following image shows
the toolbar and its location:
Compile UDM Model Icon

The “Compile UDM Model” icon is used to compile (translate) the model once it has been
created. While the compiling takes place, a progress bar (located on the lower right-hand side of
the interface) and a message is displayed when the compiling is complete.

Compile all Models

The “Compile all Models” icon on this toolbar can translate all models, or all uncompiled or
untranslated models in the user-specified directory. When this icon is clicked, the following
dialog opens:
The option “All Models” compiles all UDM models within the specified directory. The option
“Uncompiled Models Only” compiles only the models which do not have an up-to-date
translation file (file with extension *.bin). An out-of-date or uncompiled UDM model is one
which does not have a corresponding *.bin file last saved within a minute of the save time of the
*.udm file (within a one-minute period).
The following message informs about the results of the compilation process:

The information shows how many models compiled successfully and how many models failed
compilation. For information on failed compilation issues, please refer to the advanced topics
section of this chapter.
Open Plots Icon

The “Open Plot” icon opens previous test output plots for all the scopes within the model.
Close Plots Icon

The “Close Plots” icon closes the active plots for the UDM model.
Warning or compiler error messages may be displayed during the compiler process. These
message windows will indicate certain conditions such as missing required parameters or illegal
block combinations or connections. An example of a warning message is shown below:
Run Test Simulation

When clicking on the “run test simulation” icon, the program launches a test simulation which is
geared to test the exciter, governor, power system stabilizer models, etc, etc. by simulating
certain disturbances like faults, load acceptance and load rejection (shed). The test settings and
initialization settings must be configured prior to running any test routines.
The progress bar is also displayed during the time the simulation test is running. When the test is
complete, a plot of the test results will appear.

Note: as soon as the test simulation is launched, the model must be initialized by the compiler.
The initialization may take a considerable amount of time depending on the initialization method
selected or the time constant values used in the model. If the model is not configured properly for
initialization, a message or warning will appear and the test will not start. It may take several
minutes in extreme cases for a model to initialize. The progress bar will only start to advance
until once the model has been initialized.
Prior to running the test simulation, the Initialization, test settings and system reference setting
must be configured. The image below shows the location of the model parameters property sheet
where these settings are stored:
The image below shows an enhanced view of the system parameters property sheet:

View Test Simulation Results

When clicking on the “view test simulation” results icon, the program displays a plot showing
the results of the simulation. If the test simulation was a fault, then the test results might look like
the ones shown below:

Plot of Test Results for a Load Shed Simulation
Plot of Test Results for a Load Acceptance Simulation

Plot of Test Results for a Fault Simulation
Plot of Test Results for a None Simulation (steady-state condition)

25.2.3 Dynamic Parameter Estimation and Tuning (DPET) Mode

This mode has the DPET toolbar, which has the study cases, output plots and DPET result
analyzer. This model of analysis can be used to launch the iterative parameter estimation and
tuning process, based on comparisons against field-measured results.
DPET Toolbar
The DPET toolbar contains the following controls:
1. Duplicate DPET study case

2. DPET study case dropdown list
3. DPET study case editor
4. DPET output report dropdown list
5. Open DPET reports
6. DPET Analyzer
1 2 3 4 5 6
Duplicate DPET Study Case

This option allows the creation of DPET study case duplicates, which can be modified for
different analysis scenarios. To delete the study cases, go to the “Edit” menu and select “Delete
Study Case.”
DPET Study Case Dropdown List

This tool lists all existing DPET study cases. The DPET study cases are only applicable for a
single model. This list only contains DPET study cases for the active model.
DPET Output Report Dropdown List

This list contains the names of all the output reports from the DPET simulations. Please note that
the DPET simulations are filtered from other DPET output reports (i.e. from a different model
within the same ETAP project) by the use of a special naming convention in the project
directory. A directory with the same name as the model is created to store all the outputs related
to the active model. For example, if the names of the models are, “GENLOADST” and
“GENLOADSTFinal” then the DPET program would create two output report directories with
the same model names inside of a general output report directory. Both of these directories are
placed inside of the active ETAP project directory. In this case, the active ETAP project
directory is “TCS-UDM-046” (see below):

Please note that the output reports are stored in *.xlsx format.
Open DPET Output Reports

This button simply opens the active DPET output report from the DPET report dropdown list.
DPET Analyzer
Pressing this icon will launch the DPET report analyzer. The analyzer is discussed later in this
section.
DPET Study Case Editor

The DPET study case is the main interface editor for configuring the DPET simulations. The
input field-measured parameters like voltage, current, electrical power, frequency, etc. need to be
specified from this editor. The parameters, which will be considered in the simulation, are also
specified along with the iterative method solution precision and iteration time. The image below
shows the DPET study case:

Data Loading Page
Study Case ID
This field holds the alphanumeric identifier or study case name. The study case name can have as
many characters as needed (125 characters or more) to have unique study case names.
Field Recorded Data

This section holds the input field-measured results. The field-measured results can come from
staged tests such as exciter reference voltage bump tests, load bank step tests, Q-axis response
tests, etc. The measured results can also be from actual recorded disturbances like faults, system
disconnections, etc. The recorded data needs to be entered in Microsoft Excel format (*.xls or
*.xlsx). Future versions will allow direct import of recorded events from comtrade or PMU
formats.

Name
This field shows the names of the inputs and outputs in the model for which field-measured
results will be assigned. For SISO (single input single output) models, only a pair of inputs will
be listed. In the case of an exciter with SISO, only the Vt (terminal voltage in pu) and Efd
(exciter field voltage in pu) will be listed. All the names are pre-determined based on the type of
inputs and outputs present in the model.
Location
This shows the directory where the Excel file containing the field measurements are stored.
Browse
Allows the specification of the directory where the field measurements are stored.
Plot
This icon opens plot(s) of the selected field-measured data. The plot shows the data tabulated
against time (x-axis). It is recommended to check the data by means of this plot button before
running DPET study.
Start T. (s)
This field can be used to specify the starting point of the input data to be used for the DPET
simulation. In the majority of cases, the starting time should be the same for all the input field-
measured results. For synchronization, the smallest common time span selected will be used for
the DPET simulation.
End T. (s)
This field can be used to specify the ending point of the input data to be used for the DPET
simulation. In the majority of cases, the ending time should be the same for all the input field-
measured results. For synchronization, the smallest common time span selected will be used for
the DPET simulation.

The following data shows the exciter field current with a starting time at 120 seconds. The end
time is 125.5 seconds. The total data collected covers a span of 420 seconds. The net simulation
time span is only 5.5 seconds, but this time is sufficient to capture the transient period. The
transient period is what is used to perform the exciter parameter estimation in this case.
S. Rate (s)
This is the sampling rate that the program will use when reading the field measurements. The
sampling rate is the same as the time step of the first few steps in the input data. There is no
requirement for the sampling rate to be fixed (constant); however, it is preferred. The sampling
rate can be increased or decreased depending on the situation and the amount of data points
collected in the measured data.
The following images show input signals with a sampling rate of 1.0 millisecond. The image also
shows two different input signals. The first image (on the left) is a scalar input signal and the

first column is the time with a time step of 1.0 millisecond. The second image is a complex (on
the right) signal. Again, the first column is always the time and the remaining columns are the
magnitude and angle (p.u. magnitude and radians):
In some cases, it may be necessary to increase the sampling time to reduce the amount of
measured data points that are used in the DPET simulation.
Case 1: The time step of the measured field disturbance is 0.000333 or around 0.33 milliseconds.
However, the simulation time is 1.0 milliseconds. In this case using a sampling rate of 0.33
millisecond will only slow down the simulation and not provide any more resolution or catch any
transient behavior that can be captured by the DPET or eventual transient stability simulation. In
this case, the sampling rate can be decreased.
Case 2: The sampling rate can be decreased as well, if the smallest value of the time constant
parameters is known. Time constants will not capture or pass any values with a sampling rate
smaller than the time constant value. For example, assume again that the time step of the field
measurement is 0.33 milliseconds and that the minimum value of any time constant in the control
system is 0.010 seconds. Then, in this case, it is recommended to decrease the sampling rate to
0.005 seconds. This will collect less data in the simulation and speed up the DPET simulation.
Note: Decreasing the sampling rate can be a good way to speed up the DPET simulation;
however, the sampling rate should not be decreased to the point where it would cause the loss of
the actual transients required in the parameter estimation. An example of this is shown below.
The first plot was generated based on a sampling rate of 33 milliseconds (left). The second plot
was generated with a sampling rate of 0.5 sec.

As can be seen above, there is a loss of the lower voltage dip of the input voltage measurement.
This portion of the signal would be needed to be able to match the calculated results against the
field measurements.
Format for the Input Field-Measured Data

The field measurements must be provided in MS Excel format. The interface accepts files with
extension *.xls (Excel 97-2003) and *.xlsx (Excel 2007 and later versions). The following
considerations should be taken when preparing the input data for the simulations:
1) Each excel file for a scalar input/output has two columns- first column is for time in
second and second column is for value in per unit (pu).
2) Each excel file for a complex input-output has three columns- first column is for time in
second, second column is for magnitude in pu and third column is for angle in radian.
3) The data must be sequential (i.e. t=0+ to t=end time).
4) The excel data must not contain any text or time data in hour:min:sec format. No strings
are accepted. Only number formats are accepted.
5) It is preferred if all the input field measurements have a common time span or recording
duration. For example, one signal could have been measured for 100 seconds and another
one for only 80 seconds. It would be preferred if both measurements are trimmed to the
common time span of 80 seconds. If this is not done, then at least the starting time should
be common to both measurements so that there is correlation between the different
measurements.

6) Do not include the column or plot data headers in the excel files. The inputs should only
be numbers. The program will automatically label the data plots depending on the type of
input or output ports to which the data is assigned.
Parameter Estimation List

The parameter estimation list is probably the most important portion of the study case. The
information available in this section will be used to define the range of estimation and the
number of parameters available for the tuning. The process of parameter estimation and tuning
can be quite complex, extensive and time-consuming. The selection of parameters and their
ranges should be carefully considered, based on the physical limits and practical implementation
of the actual range of the hardware controls.
Fixed
This check box is a simple indicator to the DPET program that the parameter should not be
considered for tuning. As simple as this seems, the selection of which parameters should be fixed
(checked box) and which ones should be variable (unchecked) can make all the difference for a
realistic result in terms of parameter estimation. The following rules of thumb should be applied
when selecting the application of the fixed parameter checkbox:
1) Physical limits of the controller (i.e. Pmax, Efdmax, Pmin, Vrmax, Vrmin) are generally kept
fixed in the parameter estimation. These limits should be included only in situations
where extreme transients are used which may result in clipping or saturation limits to be
engaged. The difference between the estimated and field measurement should provide
some insight as to how the range of the parameter should be set once a limit is included in
the simulation by unchecking its fixed condition.
2) Time constants for actuators, valves, fuel system, combustion system, regulators (for
most electromechanical or mechanical control mechanisms) typically should not be
included in the estimation process. Most of the time, these time constants represent the
time delay of the actual control system mechanism to take action based on the input error
or control signal. However, if the actual values are unknown, then they can be included
but their range of estimation should be limited to a range reasonable for the type of
element being modeled. Examples of these are transducers. Their time constants can

range between 0.002 seconds to 0.010 seconds for most applications. If the actual value is
not known then the transducer time constant can be included (fixed box unchecked) and
its range can be set from 0.002 to 0.010 with an initial value of 0.005 sec.
3) Time constants and gains in PID controllers, AVRs and/or Speed controllers or any other
type of control portion (typically elements right after the error signal difference summing
point) can be included in the estimation and tuning process (fixed box unchecked). These
parameters are tunable be means of electronic controls or adjustable electromechanical
potentiometer or other types of control systems. For example, in a PID control you may
encounter KI, KP, KD, KF, TF etc. The range for KP can be set to 0.2 to 10 with an initial
value of 5. Tf can be set as 0.005 to 0.1 with an initial value of 0.06 seconds. Please note
that the manufacturer documentation should be consulted when selecting the range and
initial value, and that each application may require different ranges.
4) Typically relative operators or boolean logic operators or signal-switching control

parameters should not be included in the estimation. Examples of these are threshold
values inside of signal-routing switch elements. Other examples are relative values to set
boolean logic implementation.
5) Reference signals are typically not tunable although they can be varied to adjust the
estimation process. More details on this will be provided in a later section, which
explains how to setup dynamic reference control signals in the parameter estimation tool.
In general, the fixed check box can be summarized as an indicator of whether a parameter is
included or not in the estimation process.
Note: When a parameter is fixed, its initial value is used by the DPET program as a known
constant parameter.
Block
This field shows corresponding block name, which contains the parameter. The list of parameters
can be sorted by block name. This field is read-only. Of course, the block name can be changed
from the individual block property editor.
Name
This field displays the parameter name. The parameters can be sorted by their name. This field is
display only. The parameter name can be changed by accessing it from the variable where the
parameter is contained.
Base
This shows base values of all parameters. The base value can be defined as the “current”
parameter value in the model. In most cases, the base values can be described as the
manufacturer or vendor provided parameters for the model. The base values are the parameters
which will be used in any kind of transient stability simulation in the UDM model. It is important
to note that the estimated parameters can replace the base values in the model. This should be
done only after the model validation and estimation is complete. It is recommended to create a

new model that uses the estimated parameters from the DPET simulation. With this technique, it
is possible to compare the performance of the model before and after the parameter estimation
process.
The parameters can be sorted by the base value. This field is read-only. However, their values
can be edited from the Model Parameters section/window. In most cases, the base value is used
as the initial value in the DPET simulation.
Initial
The initial value as described under the “Fixed” section above is used to set the first iteration
value of the parameter in the DPET simulation. The initial value should be set to the value,
which is considered to be the best expectation of the actual parameter value. In most cases, the
initial value is the base value unless a better “guess” or estimate can be provided to the program.
The DPET simulation will reach a solution faster if the initial value is close (good guess
guestimate?) and the range of the parameter variation is smaller.
A parameter takes its initial value and keeps it constant during DPET optimization process if the
parameter is fixed. If a parameter is not fixed, DPET optimization starts with random values
from an initial value to lower or upper values (limits).
The relation between the initial, lower and upper limit is:
Lower Initial Upper.
If this relation is not followed, then an error message will appear. See image below. The
relational condition must be satisfied before the error message disappears.
Lower
It is lower limit of a parameter value.
Upper
It is upper limit of a parameter value.

Update Initial with Base

Updates all initial values with the current model base values for all parameters.
Study Remarks
You can enter up to 120 alphanumeric characters in the Remarks box. The purpose of this
information text area is to provide information specific to the conditions for each study case.
DPET Simulation Parameter Page
Simulation Data
Iterations
The number of iterations for DPET should be set according to the expected duration of the
estimation process. The optimization process stops after the specified number of iterations. If the
expected deviation is too small for the specified number of iterations, increasing the number of
iterations and running it again may be needed until the desired average deviation is reached.
Default value is 10 and max is 9,999.
Agents
Enter the number of agents. Agents interact with each other and share their information at each
iteration. The recommended and default value is 10; however, max is 999. Higher numbers of

agents will make the optimization process slow. Note: For five iterations and ten agents, total
number of optimization calculations will be (5X10=) 50.
Time Step(s)
This is the time step for running the DPET optimization simulations. The range of the time step
is from 0.0001 sec to 10 sec. The time step is also used to initialize the model after each iteration.
However, the DPET time step should be smaller than the time step or sampling rate of the input
measured data. The following considerations should be applied when selecting the time step for
the DPET optimization process:
1) The time step should be smaller than the smallest sampling rate of all the signals.
2) The time step should be smaller than the smallest possible minimum time constant of all
blocks. However, setting the simulation time step as a very small value will make the
simulation slow down significantly.
Ex. Time(s)
This time determines the execution time in seconds. The optimization process will stop after that
execution time has been reached. The execution time should be selected based on the model
complexity, number of parameters being considered, and their range. Longer execution times
may be needed in order for the optimization process to converge (reach the desired average
deviation). If the desired deviation is not small enough for the specified execution time limit,
increasing the execution time can help the simulation to converge. The default execution time
value is 500 seconds.
Deviation Avg.
Enter desired average deviation of measured and calculated outputs in p.u. The default value is
0.01 pu.
Max. Ind. Point

Enter maximum deviation of measured and calculated outputs in p.u. at any point of time that
should be achieved. The default value is 0.01 pu.
Simulation Time Step Multiplier

Enter time step multiplier. The multiplier is an integer value which can be used to speed up the
optimization process; however, using multiplier values higher than 1 may increase the overall
deviation. The recommended and default value is 1. However, a value as high as 10 or more can
be used, in some cases.
Running DPET
Executing the DPET simulation is simple. The following steps are required to launch the
simulation:

1) Setup the DPET study case by entering the input measured results and setting up all the
parameters to be considered.
2) Compile the model.
3) Launch the DPET simulation by clicking on the “start simulation” icon on the toolbar.
4) During simulation the plots will open and display the current optimization iteration and
the current results in graphs.
5) The DPET can be stopped at any time to get the current estimated parameters. Please note
that the simulation will stop after the “stop simulation” icon is clicked and the current
iteration is completed (i.e. the DPET optimization engine will stop only after completing
the simulation for the current iteration and thus may not stop right away).
6) The DPET results can be viewed by means of the reports or the DPET report analyzer.
Compile
The compile button is the same as the UDM compile button described in section 25.2.2. The
model needs to be re-compiled after any changes have been made to the model. Failure to
compile will cause the latest changes (since last successful compilation) to be neglected in the
current UDM test or DPET simulation. Changes in the DPET study cases do not require re-
compiling the model. However, the DPET start simulation icon is only activated the first time
after the model has been compiled.
Run
This icon allows the DPET process to start (if the model has been properly compiled). The study
case must be configured as mentioned before running DPET. During the DPET process, a group

of plots are opened and refreshed after each iteration. These plots provide a visual indicator of
where the current convergence state and deviation between the measured and calculated results.
The following images show the estimation results at iteration 12/100 (12th iteration out of total
100) and at iteration 96/100.
Stop
During the DPET optimization process, users can stop running DPET any time. The DPET
process can be stopped if the current iteration shows satisfactory results, even if the desired
overall deviation has not been reached. If DPET is stopped, the results reported for the
parameters correspond to those of the current iteration (please note that these results may not
necessarily be those that provided the least deviation). The best set of estimated parameters is
only reported if the simulation stops automatically after reaching the desired average deviation.
Plot
This button brings up all the available plots (graphs). It has zooming capability to see specific
parts of the graphs clearly.

Model Initialization
The initialization process is the same as that described in the test simulation section. However,
the main difference is that the initial input and output values used for the initialization come from
the first set of data points from the field-measured parameters. In the test routine, the initial
conditions are specified from the model properties section.
The initialization process may be slow and sometimes even impossible to reach. If that is the
case, it will take a long time for each DPET iteration to complete. In general, using the direct
initialization process is not preferred. The iterative process should work in all cases, except those
where a solution is not possible, because the states are outside the possible solution range. It is
recommended to use the iterative method of initialization for all possible situations.
Please see the Advanced Topics section for more tips on how to configure the model
initialization for UDM and DPET.
Note: The simulation time from the Simulation Parameter page is used as the initialization time
for all models in DPET. This means that the test routines take the initialization time from the
model properties section, and the DPET simulation takes the initialization simulation time from
the DPET study case’s Simulation Parameters page.

25.2.4 DPET Analyzer

The DPET analyzer is a power tool, which can be used to view and compare the results of
multiple DPET simulation results. The DPET analyzer will only show simulation results for
DPET simulations which were executed in the current model.
Study Reports
Report
The report section shows all available reports for the active model. Users can select report(s) to
show initial and estimated parameter values for selected report(s). It has sorting capability by
report name. This field is display only.
Max Dev
This shows achieved maximum deviation of the corresponding report. The User can compare
different reports and pick the best one. It has sorting capability by maximum deviation. This field
is ‘display only.’ Note: Achieved maximum deviation and average deviation are written in the
report.
Parameter Results
Block
This shows block names. If the block name is empty for a parameter, the parameter was deleted
from the project. It has sorting capability by block name. This field is display only.
Name
This shows parameter names. If a parameter has no block name, in that case, the parameter was
deleted. It has sorting capability by parameter name. This field is display only.

Base
This shows base values of all the parameters. It has sorting capability by base value. This field is
display only.
Initial
This shows initial values of all the parameters for the optimization process when the report was
generated. It has sorting capability by initial value. This field is display only.
Estimated
This shows estimated values of all the parameters using DPET optimization. It has sorting
capability by estimated value. This field is display only.
Active Model
This shows the active model name. This field is display only.
Update Base
This updates base values of all parameters by estimated values of corresponding parameters of a
selected report. This button is active once any report is selected from "Parameter Results."
section.
Create New Model

This button is active once any report is selected from "Parameter Results" section. It creates a
new model with estimated parameter values of the selected report as base values.
Plot
This button is active once any report is selected from "Parameter Results" section. It plots all
calculated, measured and deviation graphs for the estimated parameter values including input
graphs. It has zooming capability to see specific parts of the graphs clearly.

25.2.5 DPET Excel Report

Info
This tab shows UDM model name, file name, DPET study data and study case name. It also
includes average and maximum deviations of measured and calculated data.
Model Parameter Results

This tab reports UDM block names, parameter names and base values. It also includes initial
guesswork of all the parameters used in DPET optimization process and their final estimated
values.
Plot Data
This reports all measured data for inputs and outputs, calculated data for outputs, and deviation
of measured and calculated data for outputs. Users can make plots from those data.


25.2.6 Model Global Properties

The model property sheet is used to configure the global model parameters, which are used for
compiling the model so that it can be used in a transient stability calculation. The property sheet
includes sections for setting the model type, initialization and testing.
Parameters
Name
This field is used to enter the model name.
Appearance
Background Color
Change the background color.
Diagram Size
Modify the document size and orientation such as landscape or portrait.
System Model Parameters

The following table describes the System Model Parameters in detail for an exciter model.


Logic for the System Reference (i.e. Qref, Pref, Vref, etc)
These fields are used to tell the program which blocks are used for specific signal references
required by each type of model.
For example, for an exciter you may need to select a constant block, which will serve the
purpose of being the exciter reference voltage (Vref). You may also need Qref and Pref,
depending on the type of model or controller being implemented.
The same applies to governor models. Please note that the following rules and best practices
apply to the selection of the reference constant blocks:
The following logic applies to these fields:
1) The best practice is to name the constant block in the model the same as the expected name
in the compiler. If you named the voltage reference block “AVRReFVoltage,” it may be
easier instead, to name the constant block “Vref.”

2) The selection is unique. The same block may not be used as reference more than once. For
example, if you select C1 constant block for Vref, then you will not be able to select C1 as
constant block for Pref.
3) The System Reference Signals have sorting which gives preference to any constant blocks
named similarly to the expected reference signal name. For example, if we are trying to
select the constant blocks for Vref, then any block named “Vr”, “V1”, Vreference” and
“Vr1” is placed at the top of the list. Any constant block starting with “V” or “Vr” is placed
at the top of the list. All the other constants fall below with regular sorting in descending
order.
4) The system reference selection is checked at the time the model is compiled. If a selection
is not made, then there are warning messages are displayed (i.e. for exciter models Vref
needs to be selected and for Governor Wref needs to be selected as well).
The following image shows three models with their respective constant block system reference
selections:

Note that ETAP 16.0.0 can automatically select the reference blocks for the system reference
section as long as they are properly configured and named using the reserved words described in
this section. Using names other than the reserved names will require user input and selection for
the mapping of the blocks to their corresponding reference values.

User-Defined Dynamic Models Input and Output Blocks
Input and Output Blocks

The input/output blocks or elements are the variables that are used by the compiler to transfer
data back and forth between transient stability calculation and the UDM model. Each model type
has a specific list of inputs and outputs, which are handled by the compiler and have specific
meanings.
25.3.1 List of Inputs/Outputs based on Model Type

These inputs and outputs come from the synchronous machines, lumped loads and wind turbine
generator elements. The following tables list the inputs and outputs available for direct interface
to the transient stability calculation:
Note: Any additional input (besides those listed in the tables below) may be defined by the user
by using mathematical equations and constant blocks. Any output can be defined by using
special plotter element blocks (described later in this chapter). The list of inputs and outputs
below have been pre-defined as the most important parameters between TS and UDM Models.
List of UDM Inputs/Outputs for an Exciter Model

UDM Tool Tip Description
Input
GoToBlock input where the user can specify a variable
name from where this input reads data. Use in
In Generic Input
combination with output ports. The units are inherited
from the variable that is being read.
Synch machine control bus voltage - magnitude in pu
Vt Terminal Voltage
(bus base kV)
Synch machine control bus voltage - complex (real,
imag) in pu (bus base kV) Note: The voltage passed to
UDM from transient stability is the bus voltage without
Terminal Voltage, phase angle adjustment. The magnitude will be the same
Vt,c
Complex but the phase angle is not referenced to the system
reference angle. This does not affect the model behavior
since all the other complex values passed to UDM are not
referenced to the system angle.
Vs PSS Voltage Signal PSS voltage signal to exciter in pu (machine base)
Synch machine terminal current magnitude in pu (100
It Terminal Current
MVA Base)
Terminal Current, Synch machine terminal current- complex (real, imag) in
It,c
Complex pu (100 MVA Base)
Ifd Exciter Field Current Exciter field current in pu (machine base)*
P Real Power Output Synch machine real power output in pu (100 MVA Base)
Synch machine reactive power output in pu (100 MVA
Q Reactive Power Output
Base)
PF Power Factor Synch machine output power factor in pu
Freq Frequency Synch machine control bus frequency in pu


Output
Efd Exc Field Voltage Exciter field voltage in pu (machine base)
GoToBlock output where the user can specify a variable
name to which this output port writes data. Use in
Out Generic Output
combination with input ports. The units or per-unit value
is inherited from the input
List of UDM Inputs/Outputs for a Governor Model

Input
In Generic Input
Vt Generator Speed Generator speed in pu (machine rated RPM)
Generator real power output in pu (machine rated MW
P Real Power output
base)
Load sharing power signal in pu (machine rated MW
Psh Load Sharing Signal base)
Output
Turbine/Engine mechanical power output in pu
Pm Mechanical Power
(machine rated MW base)
Out Generic Output
List of UDM Inputs/Outputs for a PSS Model

Input
In Generic Input
Generator control bus voltage - magnitude in pu (control
Vt Terminal Voltage
bus base kV)
P Real Power output Generator real power output in pu (100 MVA base)
Turbine/ Engine mechanical power output in pu (100
Pm Mechanical Power MVA base)
W Generator Speed Generator speed in pu (machine rated RPM)
Ang Rotor Angle Generator rotor angle in radians
Freq Terminal Frequency Synch machine control bus frequency in pu
Output

Vs PSS Voltage Signal PSS voltage signal to exciter in pu (machine base)

Out Generic Output
is inherited from the input.
List of UDM Inputs/Outputs for a Generic Load Model

Input
In Generic Input
Terminal bus voltage - magnitude in pu (bus nominal kV
Vt Bus Voltage base)
Terminal bus voltage - complex (real, imag) in pu (bus
Vt,c Bus Voltage, Complex nominal kV base)
Freq Bus Frequency Terminal bus frequency in pu
Output
P Load Real Power Load real power in pu (1 MW base)
Q Load Reactive power Load reactive power in pu (1 MVAR base)
WTG complex (real, imag) current output in pu (1MVA
It,c Complex Current Output base)
Out Generic Output
is inherited from the input.
List of UDM Inputs/Outputs for a WTG Model

Input
In Generic Input
Terminal bus voltage - complex (real, imag) in pu (bus
Vt,c Bus Voltage, Complex
nominal kV base)
Ws Wind Speed Wind speed in meter per second (m/s)
WTG terminal bus voltage - magnitude in pu (bus
Vt Terminal Bus Voltage nominal kV base)
WTG control bus voltage - magnitude in pu (bus nominal
Vc Control Bus Voltage kV base)
P WTG Real Power Output WTG real power output in pu (machine MVA base)

WTG Reactive Power

Q Output WTG reactive power output in pu (machine MVA base)
WTG terminal bus frequency in pu (system frequency
Freq Frequency base)
Output
P WTG Output Real Power WTG output real power in pu (1 MW base)
WTG Output Reactive
Q power WTG output reactive power in pu (1 MVAR base)
WTG complex (real, imag) current output in pu (1MVA
It,c Complex Current Output base)
Out Generic Output
*ETAP uses two different bases to UDM exciter field current.
Base Determination Method 1

When running “Non-Frequency Dependent (NFD) TS Simulations”, the Ifd base for UDM is
determined based on the field current required to produce 100% terminal voltage. The generator
open circuit saturation curve is used to determine the per-unit value for Ifd and Efd.
Base Determination Method 2

For “Frequency-Dependent (FD) Simulations”, (such as generator startup), the base value used
for UDM Ifd is 100MVA. This base value is more suitable for simulations involving the starting
of large generators where actual values of field current may be needed.

Converting between Different Base Values

If it is required to use the same exciter in FD & NFD simulations, add a base conversion factor to
the UDM Ifd input as shown below:
GenMVA 1
Ifd NFD Ifd FD
100 MVA Lad
Where:
IfdNFD Exciter field current expressed using non-frequency dependent base

IfdFD Exciter field current expressed using 100 MVA base
Lad Xd-Xl in machine per-unit base
The image below shows how the conversion factor can be implemented into a UDM exciter
model.
Switching between Different Base for FD UDM Ifd

An ETAPS.ini entry can be added below the [ETAP PowerStation] header to change the base
used for Ifd in frequency dependent UDM exciters.
The entry is:
UDMFDIfdBase= 0 or 1
The default value (i.e. no INI entry) or with the INI entry in place with a value = 0, causes the
program to use Method 1 for Ifd base in UDM when using frequency-dependent simulations.
Setting the value of this entry to 1 causes the program to use method 2 (100 MVA base) to
determine the base for UDM Ifd in frequency-dependent simulations.
Non-frequency dependent UDM exciters always use method 1 to determine the base for Ifd.
Built-in exciters always use Method 1 to determine the Ifd base (even if FD or NFD simulations
are performed).

25.3.2 Input/Output Blocks Data Sheet Properties

This section describes the parameters of the inputs/outputs blocks in the UDM Graphic Logic
Editor Interface.
Equations for the Input/output blocks

The equation of this block is: y = u
If the block is an input, then “u” is the input variable from ETAP Transient Stability (TS)
(whatever it may be according to tables in section 25.3.1) passed to the UDM model. If the block
is an output, then “u” is the output variable from the UDM model passed back to the ETAP TS.
Name
Input / Output name or Id. This can be a more descriptive name than the abbreviations used to
define each input by the compiler.
Input Port Number

Inherited parameter used by previous versions of ETAP, which used Matlab’s Simulink interface
input and output ports numbering system. This field is still used for import and export to
Simulink purposes.
Line Style
This section provides general symbol graphical properties customization options.
Font
This section provides parameters to configure the fonts to be used for labels of the block.

25.3.3 List of Input/Output Blocks

The following image shows all the input/output blocks including the system defined (reserved
inputs and outputs) and those which are user-definable inputs and outputs or otherwise known as
“GoToBlocks”.
The image below shows the inputs and outputs for an exciter:
Please refer to section 25.3.1 for a complete description of each of the reserved inputs and
outputs (e.g. those which cannot be modified).
In/Out Blocks
This section focuses on the “In” and “Out” input and output blocks. The “In” input block allows
the reading of a variable value, which can originate within the same model or from another UDM
model (when the simulation is executed from transient stability).
The input block has the following parameters:
Port ID: The graphical name of the port for graphical identification
Variable ID: This field identifies the local or remote variable name. If the Input type is
set to “TS”, then this name should match the ID of the element data source (i.e. the name
of the element from the one-line diagram in ETAP).
Communication Link ID: This is a unique identifier used to create unique communication
channels between the input and output ports. If the input type is “Internal”, this link is

read-only and the display shows an alphanumeric “GUID” identifier. For external input
port types, the link is editable and can receive the link or GUID from another model.
Initial Value: This field contains the initial value of a remote variable (e.g. variable which
does not exist within the model). This value is used for initialization purposes only when
running transient stability or as a constant value when running the test routine. This value
is not used when the variable is defined locally (e.g. the variable is defined within the
model itself).
Input Type: The input type determines the class of input data received by the input port.
The types are:
1. The internal variable means that this input variable resides within the model
where the input block resides.
2. The external Input Type means that the data source for this input block can come
from an external UDM model.
3. The “TS” Input Type allows the import of bus and branch element transient
stability calculation results.
4. The real-time (measured online data tags) is not supported in this release.
Element Type: The element type is enabled if the input type is “TS”. The element type
can be either a bus or branch.
Bus Signal Type: The signal type field is active if the input type is “TS”. The signal type
determines what calculated value is passed to the input port from the signal types
available in TS for the selected bus element. The signal types are:
1. Voltage (kV)
2. Voltage Angle (Degree)
3. Frequency (Hz)
Branch Signal Type: The branch element signal type is enabled if the input type is “TS”
and the Element Type is “Branch”. The signal type for branches determines which
calculated parameter from TS is passed to the input port. The branch signal types are:
1. MW_From (MW)
2. MW_To (MW)
3. Mvar_From (Mvar)
4. Mvar_To (Mvar)
5. Current_From (kA)
6. Current_To (kA)
7. MVA_From (MVA)
8. MVA_To (MVA)

The Output block has the following parameters:
Port ID: The graphical name of the port for graphical identification.
Variable ID: This field identifies the variable name in which the output port data will be
stored for other input blocks to use.
Communication Link ID: This is a unique identifier used to create unique communication
channels between the input and output ports. If the input type is “Internal,” this link is
read-only and the display shows an alphanumeric “GUID” identifier. For external input
port types, the link is editable and it can receive the link or GUID from another model.
Output Type: The output type determines the class of data channel used to pass the data
signal connected to the output port. The types are:
1. Internal: The output port passes its signal only to input ports with the same GUID
identifier
2. External: The output port passes its signal to internal or external input ports,
which have the same GUID identifier. The communication link ID is editable and
the GUID of an external model can be entered to establish communication across
models
3. TS: This option will be enabled for a future release
4. Real-Time: This option will be enabled for a future release
Element Type: This option will be enabled in a future release
Signal Type: This option will be enabled in a future release
Application of the “In” and “Out” Blocks – Remote Connector (GoToBlocks)

The “In” and “Out” blocks can be used as remote connectors (similar to the ETAP one-line
diagram remote connectors). If the input and output blocks both have the same variable name
and both reside within the same UDM model (internal input type and output type with same
GUID), then they behave as remote connectors for UDM.
The image below shows an example of remote connector application for UDM diagrams:

Note that in the example above, the blocks called “Out” and “In” (pair) both have the same
variable name called “abc”. The blocks called “In1” and “Out1” both have the same variable
name called “abc1”.
The blocks could also be used to send the same signal to multiple points. For example, we can
take one signal and add the same variable name to three or four different input ports. The image
below shows the contant value of 3 being passed to three input blocks and being plotted three
times with a three-input scope.
Application of the “In” and “Out” Blocks – Communication Across Models

Another application of the input and output blocks is to send signals across models when the
simulation is running in transient stability. During the simulation it may be required to send or
receive information about other components. The information transferred could be used as

control signals to simulate generic control systems. Some examples of power systems which
benefit from this bi-directional communication channels across models are:
Microgrid Systems
Renewable Energy Systems
Systems with Automatic Generation Control
Systems with Load Sharing and Load Shedding schemes
Systems with remote control points
…
To communicate across models all it takes is to setup matching pairs of input and output ports
with a common remote variable name and with input and output ports configured as external
with matching GUID identifiers. A very quick example is described below where a generation
setpoint is passed from a controller to a wind turbine element (e.g. communication between a
controller inside a lumped load and a WTG model).
The microgrid system below has synchronous generators (diesel generators), wind turbines,
photovoltaic systems and energy storage devices. It is also capable of shedding the loads
connected because of under frequency or low generation conditions.
Input and output ports have been configured to obtain information about the generation from the
renewables and load in the system, and control channels to regulate the generation setpoints of
the generator sources. The arrows below specify some of the communication channels which
come from the control center and go to different elements.

The example above is just one of hundreds of potential applications of bi-directional

communication in power systems.

Application of the “In” Blocks – Signals from Network Elements in TS

Another application of the generic input blocks is to create a communication channel between
transient stability results for network elements and the UDM models. When an input port is of
type “TS”, and its variable ID, Element Type, Bus/Branch Signal Type and Signal Type are
selected, then the input block can receive plot values from transient stability. The following
example shows that input port signals from TS are passed to the UDM model when the input
ports are configured to receive signals from a bus and cable within the power system network.
First we can observe the network and the location of the network elements “Main Bus” and
“Cable2”:
These elements are plotted as part of the transient stability solution:

The TS plot simulation results for a 200 ms 3-phase fault somewhere within the network for
these element are:
For Main Bus:
For Cable 2:

Next, an example of the input port (which can reside within any UDM model type such as
exciter, governor, etc., etc.) configured to receive bus voltage signals:
Next, an example of the same to receive “Cable2” MW flow “From” bus towards to “To” bus:
The image below illustrates how multiple inputs can be configured to receive all the plot signal
types for both the bus and cable. The signals are sent to scopes.

After compiling the UDM model which contains the input ports and scopes and running transient
stability, the program generates a CSV file with all the signals. Plotting the signals shows that
they are identical to the ir counterparts in TS.
For Main Bus:
For Cable 2:
The network signals passed to UDM models can be used to implement plant-level controls.

Application of the “In” and “Out” Blocks – Setting up External Communication

Another application of the generic input and output blocks is to create a communication channel
between multiple UDM models. This section shows an example on how to configure external
communication.
The example consists of sending information between two generators. The mechanical power of
Gen1 is sent to Gen2.
Gen1 has s (a?) UDM governor with a generic output port configured for external
communication. The box highlighted shows the location of the output port, which is connected to
Pm.
The output port configuration is provided below:

Note that the output port contains a GUID or communication link ID. This field must be used to
link the signal output to the input port in Gen2. Now we can go to Gen2 and observe that its
UDM governor has an input port, which receives the signal from this output port.
The process for the configuration of the input port for Gen2 is:

Copy the Communication Link ID from Gen1’s Output Port:
First highlight
Then copy the link
Now, proceed to go to Gen2 governor model where the input port resides. Paste the
communication link into the communication link ID field of the input port
First, highlight the communication link ID field contents
Next, paste the communication link ID from Gen1’s output port

Now, compile both models and the communication link is established. The plots below show the
Pm plot from Gen1 generated from a scope block connected to the input port of Gen2 after a
transient stability simulation.

User-Defined Dynamic Models Control Blocks
Control Blocks
The control elements are the “fundamental” elements, which can be used to build more complex
transfer function or logical expressions. They are the building blocks of all the models, which
can be created in the UDM Graphic Logic Editor Interface.
25.4.1 List of Control Blocks (fundamental elements)

The following image shows all the block symbols:
The following table lists all of the control elements available for simulation
Block Name Block Name (cont.)

Transfer function Complex to Mag-Angle
Integrator Absolute Value
Derivative Switch
SISO Function Manual Switch
MISO Function Gain
LV/HV Gate Constant
Delay Logical Operator
Saturation Relational Operator
Look-up Table Relay
Dead Zone Rate Limiter
Multiplication/Div Sample Hold
Sum Script Block
Real-Imag to Complex Data Plotter
Complex to Real-Imag Simulation Time

25.4.2 Data Types and Variable Format

The majority of blocks only support scalar numerical format data type with the exception of the
blocks, which can convert polar or rectangular data to scalar components.
Data Accept
Block Name
Types Variables?
Transfer function Scalar Yes
Integrator Scalar Yes
Derivative Scalar N/A
SISO Function Scalar No
MISO Function Scalar No
LV/HV Gate Scalar No
Delay Scalar Yes
Saturation Scalar Yes
Look-up Table Scalar No
Dead Zone Scalar Yes
Multiplication Scalar N/A
Division Scalar N/A
Sum Scalar N/A
Real-Imag to Complex Complex No
Complex to Real-Imag Complex No
Switch Scalar Yes
Manual Switch Scalar N/A
Gain Scalar Yes
Constant Scalar Yes
Logical Operator Scalar N/A
Relational Operator Scalar N/A
Relay Scalar Yes
Simulation Time Scalar N/A
Rate Limiter Scalar Yes
Sample Hold Scalar Yes
Data Plotter Scalar N/A
Complex to Mag- Complex No
Angle
Absolute Value Scalar N/A
Script Scalar N/A
In ETAP 12.5.0 both constants and variables for tuning are supported as parameters of a transfer
function. Each parameter variable must be assigned a base value prior to compiling a UDM
model. The fundamental blocks, which accept variables are listed in the previous table.

The variables which can be defined are of scalar type. The format of the variable name follows
the following rules:
1) The variable names cannot include any mathematical operator symbols.

2) The format should be alphanumeric.
3) The underscore character is accepted, but it cannot be the first character of the variable
name.
4) The variable names are not case sensitive.
5) The variable names cannot contain C# programming language keywords as the first
character (i.e. cannot start with a number or use; if, char, do, etc unless they are prefixed
with an @ symbol).
6) The variable names cannot be the same as UDM translator or compiler reserved words
(i.e. Vref, Wref, Pref, Tref, etc).
7) Variable names do not support spaces in between.
Examples of valid variable names:

Vmax_1
EFD_Out
S
Tr
Average_v
Ki, KD
Examples of invalid variable names:

_Be
1GHTPm
s
&%Vbe
Vt, Efd, Pe
if
do
Wref (UDM reserved)
Vref (UDM reserved)
Vt (UDM reserved)
Pe (UDM reserved)
Qe (UDM reserved)
KD and Kd (repeated in the same model because variables are not case sensitive)
The following is a list of all the UDM reserved words:
Vt Psh
Vt,c Pm
Vs W
It Ang

It,c Ws
Ifd Vc
P iniCnst
Q DRP
PF u
Freq s (S)
EFD Qref
Vref PFref
Wref Tref
Pref
The transfer function block requires special consideration. There is no separating operator
between the variable name and the “s” operator, so the variable name could appear as
misleading. In the image below, notice that the variable name is, “Ta”. However, in the block it
appears as, “Tas”. The actual meaning of this is Ta.s or Ta times s.
Example:

Model Parameters and Creating of Modifying Variables

The model parameter section lists the available parameters with assigned variables.
If you attempt to delete a variable which is being used in one of the blocks, then the following
error message appears:
To delete a parameter, it must first be removed from the block where it is being used. After it is
removed from the block, then it can be removed from the list or it can be re-assigned to another
block. As can be seen below, there is no assigned block for VarRef1(highlighted) and thus it can
be deleted from the model parameter list at any time.

The value of the variable can be changed from the model parameter list at any time.
When creating a new variable, if typed directly into an element field which already has a value,
then the value present is automatically assigned to the variable. If the value does not exist then a
default value of zero is assigned.

25.4.3 Transfer Function Block:

The benefit of this element is the implementation of a classical textbook transfer function block
with a maximum of third order. The block is shown below:
Block Equations
The behavior of this block should be the same as that of the existing “Zero Order Hold” Block in
Simulink.
Block Properties
The image below shows the property sheet for the transfer function block.
The following table describes each of field under the parameter section of the property sheet:

Parameters
Name Transfer Function
Numerator 1,0.06,1 Enter the coefficient and the order of the
numerator of the transfer function. The
order of the numerator must be less than
or equal to that of the denominator
Denominator 1,1,1 Enter the coefficient and the order of the
denominator of the transfer function. The
order of the denominator must be greater
than or equal to that of the numerator
Parameter Range
Numerator Coefficients can have a range of:
± 999999999.999999
The transfer function numerator or denominator can only handle up to third order coefficients. If
higher orders are required then simplification techniques must be used (i.e. place two lower order
transfer function in series, so that the end result is higher order transfer function).
This would translate into the following coefficients for the numerator and denominator:
Numerator = 1,-1,0.06,1
Denominator = 1,1,-1,1
Parameter Defaults
Numerator = 1
Denominator = 0.01,1
General Logic Information

The order of the numerator must be lower or equal to the order of the denominator. If this is not
the case, then the following message is posted:

The values of the coefficient of denominator and numerator can be separated by commas space
or space commas.
The editor property sheet numerator and denominator reject the changes and force the user to
enter the correct order for the coefficients. An example of invalid parameters is given below:
Numerator = 1,1,1
Denominator = 0.01,1
The transfer function block requires special consideration. There is no separating operator
between the variable name and the “s” operator so the variable name could appear as misleading.
In the image below, you notice that the variable name is “Ta,” however in the block, it appears as
“Tas”. The actual meaning of this is Ta.s or Ta times s.
Example:

25.4.4 Integrator Block

This block performs a numerical integration.
Block Equations
The equation of this block is shown below:
Block Properties
The following table shows the properties of the integrator block.
Parameters
Name Integrator
Activate Saturation Limits True Setting this parameter activates the
limits for the integrator block.
Upper Saturation Limit 999999999.999999 upper saturation limit
Lower Saturation Limit -999999999.99999 lower saturation limit
Parameter Range
Upper Limit = ± 999999999.999999
Lower Limit = ± 999999999.999999
Activate Saturation Limits = True or False
Parameter Defaults
Upper Saturation Limit = 9999999999.99999
Lower Saturation Limit = -9999999999.99999
Activate Saturation Limits = True (read only and cannot be changed for this release).

The upper saturation limit must be greater than the lower saturation limit. The editor enforces
this condition as the data is being entered. The following message is displayed if this condition is
present:

Variable parameters are supported for this block. The same rules as described above apply when
working with variables in the saturation limits.
25.4.5 Derivative Block

This block performs a numerical derivative
Block Equations
The equation of this block is a numerical derivative of the input. The linearization time constant
is:
The derivative block can be modeled with a transfer function as shown below to improve the
accuracy and linearization depending on the time step selected.
Variable parameters are not applicable for this block.

25.4.6 SISO Function Block:

The benefit of this block is the implementation of a mathematical function block.
Block Equations
The equations (expressions) supported for this block are listed below:
sin, cos, tan, atan, acos, asin, abs, exp, sqrt, log (base 10), ln (natural log)
The supported operators are ( ) ^ + - * /
Block Properties
This block has an expression input field. An example of the expression is displayed in the table
below:
Parameters
Any of the following math
functions can be used: sin,
Expression f(u) = 0.363*exp(0.229*u)
cos, tan, atan, acos, asin, abs,
exp, sqrt, log, ln
Parameter Range
Coefficient range = ± 999999999.999999
Parameter Defaults
f(u)

If the text strings typed into the expression field do not match one of those listed in the table
above, a warning message is displayed as shown below:

Variable parameters are not supported for this block. In addition, the mathematical expressions
supported by this block require that the inputs be limited to the valid range. In other words, the
value -1 is an invalid input to the sqrt(u) function since the output types for the blocks are only
scalar (no complex variables are supported). Other examples of invalid inputs and math function
range are provided below:
Function Expressions
exp maximum exponent = 35 or exp(36)
asin -1<= u <=1
acos -1<= u <=1
atan u = + 999999999.99999
abs u = + 999999999.999999
sin u = + 999999999.99999
cos u = + 999999999.99999
u = ((2n+1)* is not a valid input; where n = +
tan integer. Any other values are allowed
sqrt 0 <= u < 999999999.99999
log 0 < u < 999999999.99999
ln 0 < u < 999999999.99999
Some examples of the valid exponential operator use (applies to both SISO and MISO
functions):

25.4.7 MISO Function Block

The benefit of this block is the implementation of a mathematical function block with multiple
inputs:
Block Equations
The equations (expressions) supported for this block are listed below:
if multiple inputs y f ( u ,u1 ,u2 ,un 1......,u9 )

Where u to u9 are up to ten (10) different input pins supported. The math functions supported are
listed below:
Sin, cos, tan, atan, acos, asin, abs, exp, sqrt, log (base 10), ln (natural log)
The supported operators are ( ) ^ + - * /
Block Properties
This block has an expression input field. An example of the expression is displayed in the table
below, which shows the format for a MISO function with three different inputs starting from the
top input pin.
Parameters
Any of the following math
functions can be used: sin,
Expression f(u, u1, u2,..u9) = u + u1 + u2
cos, tan, atan, acos, asin, abs,
exp, sqrt, log, ln
Parameter Range
Coefficient range = ± 999999999.999999
The block supports up to ten (10) input pins.
Parameter Defaults
f(u, u1, u2) = u1 + u1 + u3

If the text strings typed into the expression field do not match one of those listed in the table
above, a warning message is displayed as shown below:

Variable parameters are not supported for this block. In addition, the mathematical expressions
supported by this block require that the inputs be limited to the valid range. In other words, the
value -1 is an invalid input to the sqrt(u) function since the output types for the blocks are only
scalar (no complex variables are supported). Other examples of invalid inputs and math function
range are provided below:
Function Expressions
exp maximum exponent = 35 or exp(36)
asin -1<= u <=1
acos -1<= u <=1
atan u = + 999999999.99999
abs u = + 999999999.999999
sin u = + 999999999.99999
cos u = + 999999999.99999
u= +
tan integer. Any other values are allowed
sqrt 0 <= u < 999999999.99999
log 0 < u < 999999999.99999
ln 0 < u < 999999999.99999
Additional Notes:
The syntax of the MISO math function block does not support expressions such as:
5(u), (u)(u), 8sin(u). ((u), (((cos(u)) etc. etc.
An error message which states that the model could not be compiled will be generated during
translation and simulation time.
Unconnected MISO blocks with functions such as ln(u) or log(u) are evaluated as ln(0) and
log(0). This will cause them to produce invalid input error messages.

25.4.8 LVHV Gate Block:

This block is used to pass to the output, the low value or the high value of all the inputs.
Block Equations
The following equations apply to this block and can be generalized for more than two inputs:
Block Properties
The following table lists the LVHV Gate block properties:
Parameters
Name LVHV Gate
Inputs 2 Number of inputs to be
compared (minimum is
two)
Function Type Drop List Options: Set the LVHV Gate to
function as a LV Gate or
HV Gate
Parameter Range:
Inputs = Up to 10 inputs.
Function Type =
Parameter Defaults
Inputs = 2
Function Type = LV Gate
Variable parameters are not applicable to this block.

25.4.9 Delay Block

This block allows the implementation of a time delay.
Block Equations
This block specifies a time delay as described in the block symbol.
Block Properties
This block has the following properties:
Parameters
Name Delay
Time Delay (Td) (sec) 0.02 Show the value in Td (inside block)
In ETAP 12.5 (and higher versions), both constants and variables for tuning are supported as
parameters of delay blocks. Each parameter variable of delay blocks must be assigned a base
value prior to compiling a UDM model.
Example:
Parameter Range
Time Delay (Td) = 0 to 999999999.999999 (maximum value handled in the calculation is 1.0
sec.)
It is recommended that the time delay be used for delays less than 1 second. If the delay is
greater than one second, it is recommended that a different block combination be used to model
the delay.
Variable parameters are supported for this block:
Parameter Defaults
Td = 0.02

25.4.10 Saturation Block

This block allows the implementation of a saturation function:
Block Equations
The equations of this block are described below:
if u L X , then y LX
if u LN , then y LN
if L X u LN , then y u
Block Properties
Parameters
Name Saturation
Upper Saturation Value 1.5
(LX)
Lower Saturation Value 0
(LN)
Label Upper Limit LX Editor would show LX = 1.5
Label Lower Limit LN Editor would show LN = 0
Parameter Range
LX = ± 999999999.999999
LN = ± 999999999.999999
Parameter Defaults
LX 1.5
LN 0
Variable parameters are supported for this block. When assigning variable names, the rules of the
block equations must also be followed. If the rules are not followed then an error message may
be displayed.


25.4.11 Look-Up Table Block

This block allows the implementation of a look-up table function.
Block Equations
This block performs linear interpolation for input values between the given ranges and performs
extrapolation based on the last two end points for values outside the range. The plot below
shows the interpolation section with solid lines and the extrapolation sections with dashed lines:
Block Properties
The Look-Up Table block element has the following properties:
Parameters
Name Look-Up Table
Table Data 0,1,2,3,4,…..Xn (n = m) points must have matching
dimension
0,1,3,4,5,…..Ym (m = n)

Import / Export
The import and export functions allow you to import points from spreadsheets in MS Excel
format. Please note that only the first two columns in excel are imported automatically. This
means that the excel data would have to be in the format as shown below in order to duplicate
the data, as shown in the previous Table Data dialog.
Parameter Range
Inputs = ± 999999999.999999

Outputs = ± 999999999.999999

The dimension of the inputs and outputs must match. If, for some reason the parameters
dimensions do not match, a warning message shown below may be displayed:
“Invalid Parameters for Look-up table. Dimension of Input and output must match”
However, the spreadsheet design in the Table Data dialog automatically rejects data points which
do not match dimensions to prevent this condition.
The “Input” values must be in sequential order (i.e. in increasing fashion like, -1,0.2,3.3,4,…). If
they are not, then the lookup table may not yield consistent results. The following warning
message may be displayed if this is not the case:
“Invalid Parameters for Look-up table. Input values must be entered in sequence.”

25.4.12 Dead Zone Block

This block is used to define dead zone function
Block Equations
The equations of this block are shown below:
if L N u L X , then y 0
where L X is the upper dead zone limit
where L N is the lower dead zone limit
else y u
Block Properties
Parameters
Name Dead Zone
Dead Zone Upper limit 0.010 End of Dead Zone (upper limit)
Dead Zone Lower Limit -0.010 Start of Dead zone (lower limit)
Parameter Range
Dead Zone Upper Limit: ±999999999.999999
Dead Zone Lower Limit: ±999999999.999999
Variable parameters are supported for this block.
Parameter Defaults
Dead Zone Upper Limit: 0.010
Dead Zone Lower Limit: -0.010

It is preferred that the value of the dead zone lower limit must be lower or equal to the value of
the dead zone upper limit. If the dead zone lower limit is higher than the upper limit, then the
following message is displayed:

The values are rejected and the parameters should be re-entered.
25.4.13 Multiplication/Division Block

This block represents a multiplication and division function.
Block Equations
This is a scalar value only multiplication of all the inputs.
if mult only, then y u1 u 2 u 3 u n 1 ........ u10
u1 u 2
for mult and division (example of four inputs), then y
u3 u 4
Block Properties
Parameters
Name Mult-Div Multiplication or Division
Input Type */** (see logic section)
Parameter Range
Input Type = */*********………………….//**** (up to 10 different */ signs)
Parameter Defaults
Input Type = ** (multiplication for two inputs)


The Input Types field accepts multiplication and division (asterisk “*” and forward slash “/”)
symbols inputs to indicate the desired operation. This block outputs the results of the specified
mult-div combination. For example:
If the following sequence: **/*/* is entered, then the program should create a block with 6 inputs
and one output. The value of the 6 inputs and the result (output) of the block are shown below:
If only one input is entered, then the following message is displayed:


25.4.14 Sum Block

This block implements a scalar mathematical summation.
Block Equations
This block can be used to add and subtract the inputs according to input signs specified.
y u1 u 2 u3 ........u10
where n is the number of inputs
Block Properties
Parameters
Name Sum
Input Signs +,+,+,-,-,…. (or +,-,+,-,+,+,+, etc) default = +,+
Show Label True or False
block
Parameter Defaults
Input Signs = +,+
Variable parameters are not applicable to this block. The maximum number of inputs for the
summer block is ten (10).

The “Input Signs” input field determines the arithmetic operations performed by the sum block.
The operations are of type subtraction or addition. The following message is displayed if any
invalid characters are inputted into the block:

25.4.15 Real-Complex Block (Real-Imag to Complex)

This block converts real and imaginary components into a complex format.
Block Equations
This block converts two scalar inputs representing the real and imaginary components into a
complex number of the form:
y Re i(Im)
where Re is real
and Im is imaginary
Block Properties
Parameters
Name Real-Complex (short for Real-Imag to Complex)
Real Part 0 If the “Imaginary” option is selected,
this input can be used to specify the real
part of the complex number output.
Imaginary Part 0 If the “Real” option is selected, this
input can be used to specify the
imaginary part of the complex number
output.
Input Type The “Real-Imaginary” option allows the
input of both the real and imaginary
parts. The input selection of “Real” or
“Imaginary” allows as input only the
selected part.
Parameter Range
Real Part = ± 999999999.999999
Imaginary Part = ± 999999999.999999
Parameter Defaults
Real Part = 0
Imaginary Part = 0

If the option “Real-Imaginary” is selected, then the block shows two inputs. The top input is the
Real part of the complex number. The bottom input is the imaginary part of the complex number.

If the option “Real” is selected, then only the real part input is displayed. If the option
“Imaginary” is selected, then the block has only the imaginary input. The complex number can
be completed with real and/or imaginary parts which can be specified as input in the editor. The
images below show how the inputs are reconfigured based on the input type selection.
Note that the real-complex and imaginary-to-complex options are supported graphically but not
supported by the UDM translation engine. These options will be available in a future release of
the program. For now, please use the real, imaginary-to-complex block and feed only real or
imaginary inputs into it.

25.4.16 Complex-Real Block (Complex to Real-Imag)

This block can be used to separate the real and imaginary components of a complex number.
Block Equations
The block equations are shown below:
y1 Re(u ) Re
y 2 Im(u ) Im
u is a complex number
Re real part of u
Im imaginary part of u
Block Properties
This block contains the following properties:
Parameters
Name Complex-Real Short for Complex to Real-Imag
Output Type The “Real-Imaginary” option allows
the output of both the real and
imaginary parts. The selection of
“Real” or “Imaginary” allows the
output of only the selected part.
Parameter Defaults
Output Type = “Real-Imaginary”

If the option “Real-Imaginary” is selected, then the block shows two outputs. The top output is
the Real part of the complex number. The bottom output is the imaginary part of the complex
number.
If the option “Real” is selected, then only the real part output is displayed. If the option
“Imaginary” is selected, then the block has only the imaginary output. The images below show
how the inputs are reconfigured based on the input type selection:

Note that the complex to real and complex to imaginary options are supported graphically but
not supported by the UDM translation engine. These options will be available in a future release
of the program. For now use the complex to real, imaginary block and take only the real or
imaginary outputs.
25.4.17 Absolute Value Block

This block implements an absolute value function.
Block Equations
The equation for this block is shown below. The output is the scalar magnitude of the input. The
input can be complex or scalar.

25.4.18 Switch Block

The benefit of this block is the implementation of a switch block.
Block Equations
The equations for this block are shown below:
if the condition is " True"

y Input1
if the condition is " False"
y Input 3
Conditions :
Input 2 Threshold
Input 2 Threshold
Input 2 0
Block Properties
Parameters
Name Switch
Threshold 0.5 Any number between the range.
Condition Input 2 >= Threshold The c Input2 >= Threshold
Input 2 > Threshold
Input 2 ~= 0
In ETAP 12.5 and onward, both constants and variables are supported as parameters of switch
blocks for threshold. Each parameter variable must be assigned a base value prior to compile a
UDM model.
Example:
Parameter Range
Threshold Range = ±999999999.999999
Variable parameters are applicable to this block (threshold can be a variable parameter).

Parameter Defaults
Threshold = 0.5

The top input is Input 1, the middle Input is Input 2 and the bottom input is Input 3. The middle
Input 2 is used to make the decision of which input to pass as the output (i.e. Input 1 or Input 3).
The switch block only accepts and outputs scalar values.
Input 1
Output can be Input 1 or Input
Input 2
Input 3

25.4.19 Manual Switch Block

This block implements a manual switch.
Block Equations
The behavior of this block should be the same as that of the existing “Switch” Block in Simulink.
if switch is in position "0, " then

y input 0
if switch is in position "1 , " then
y input1
Block Properties
Parameters
Name Manual Switch
Switch Position 0 or 1 Allow selection of Input 1
(Top) Input 0 (bottom)
Parameter Range
Switch Position = 0 or 1
Parameter Defaults
Switch Position = 1 (top input as shown in image below)
General Logic Information:

The top input is Input 1, the bottom is Input 0. When selecting Input1, the position of the switch
is graphically switched towards the input selected.
Input 1
Output = Input 1
Input 0

25.4.20 Gain Block

This block implements a gain block.
Block Equations
The equation for this block is shown below.
y K (u )
where K is the gain multiplier
Block Properties
Parameters
Name Gain (default)
Gain (K) 1 Gain value
Parameter Range
Gain (K) range is ±999999999.999999
This block supports variable parameters.
Parameter Defaults
Gain (K) = 1

25.4.21 Constant Block

This block can be used to enter a constant value.
Block Equations
The equation of this block is shown below:
Block Properties
Parameters
Name Constant
Constant (C) 1 Constant value
Parameter Range
Constant value range = ± 999999999.999999
Variable parameters are supported by this block
Parameter Defaults
Constant value default = 1

The value of the constant is displayed inside the symbol. This device has only one output and it
outputs scalar constant values only.

25.4.22 Logical Operator Block

This block can be used to implement different logic operations.
Block Equations
The supported logical operations are: AND, OR, NAND, NOR, XOR, NOT. The output is the
boolean logic value (1 or 0).
Block Properties
Parameters
Name Logical Operator
Logical Operator AND Selection of the logical operation.
NAND The number of inputs will be
OR restricted based on the type of
NOR logical operation selected.
XOR
NOT
Number of Inputs Number of inputs for multiple input
10
operations.
Parameter Range
Number of Inputs = 1 to 10 (for selected functions AND, OR, NAND, NOR, XOR) and only 1
for the NOT function.
Parameter Defaults
Logical Operator Selection = AND
Number of Inputs = 2

The logical operation is displayed inside of the block. If the NOT function is selected, then
there is only one input which gets inverted as shown below. The “number of inputs” field
becomes display only.

25.4.23 Relational Operator Block

This block allows the implementation of relational operators in the UDM models.
Block Equations
The supported relational operations are >=, <=, <, >, ~= and ==. The output of the block is 1
or 0, (“true = 1” or “false= 0”), depending on the selected relational operation.
Block Properties
Parameters
Name Relational Operator
Relation Type Drop list selections: Relation type selection.
Parameter Defaults
Relation Operator = “>=” (greater or equal)

The relational operation is displayed inside of the block.

25.4.24 Relay Block

This block allows the simulation relays as part of UDM models.
Block Equations
The relay block has a switch on value and switch off value. If the input u is:
if u switch on value, then

y Value _ when _ on
if u switch off value, then
y Value _ when _ off
Block Properties
Parameters
Name Relay
Switch On at 1 Enter any value between the range. This value must
be >= than the “Switch Off at” value.
Switch Off at 0 Enter any value between the range.
Value when on 1 Enter any value between the range
Value when off 0 Enter any value between the range
Parameter Range
Switch on at Value = ± 999999999.999999
Switch off at Value = ± 999999999.999999
Value when On = ± 999999999.999999
Value when Off = ± 999999999.999999
Variable parameters are supported by this block.
Parameter Defaults
Switch On at Value = 1
Switch Off at Value = 0
Value when On = 1

Value when Off = 0

The “Switch On At” value must be greater or equal than the “Switch Off At” value. The editor
enforces this logic. The message below would be displayed if the incorrect parameters are
entered.
The condition “Switch On at” value = “Switch Off at” is valid. The relay still outputs the “Value
when On” only when the input equals the single value.

25.4.25 Rate Limiter Block

This block can be used to limit the rate of change of the input signal.
Block Equations
The first derivative of the input signal is limited to the rising and falling rates specified. The
equations below show how the output is determined:
du
if (Rising Rate of change Limit), then
dt
yi t (Rising Rate of change Limit) yi 1
du
if (Falling Rate of change Limit), then
dt
yi t (Falling Rate of change Limit) yi 1
du
if (Falling Rate of change Limit) (Rising Rate of change Limit), then
dt
yi ui
Block Properties
Parameters
Name Rate Limiter
Rising Rate of Change 1 Rising rate of change limit
Falling Rate of Change -1 Falling rate of change limit
Parameter Range
Rising Rate of Change = 0 to +999999999.999999
Falling Rate of Change = 0 to -999999999.999999
Parameter Defaults
Rising Rate of Change = 1
Falling Rate of Change = -1


The value of the rising rate must be greater or equal to zero. The value of the rising rate must be
greater than that of the falling rate. The rising and falling rate can be equal only if both values
are zero. The following message is displayed if any parameter inconsistency is detected:
If both the Rising and Falling Rates are zero, then the output of this block is always zero.

25.4.26 Sample Hold Block
Block Equations
The sample hold block holds the input for the specified sample time. This block is typically used
to account for discretization of the input signal. The following plot shows the input and output
signals for a sample hold block with a hold time of 0.1 seconds.
Block Properties
Parameters
Name Sample Hold
Sample Hold Time 0.025 Sample hold time
Parameter Range
Sample Time = 999999999.999999 to 0
This block supports variable parameters

Parameter Defaults
Sample Time = 0.025 sec.

The value of the sample hold time can be any value equal to zero or higher. The value of the
Sample Time field must be positive and greater than zero. The following message is displayed if
this condition is not true:

25.4.27 Complex-Polar Block (Complex to Magnitude-Angle)

This block outputs the magnitude and angle of a complex value input.
Block Equations
This block outputs the magnitude (pu of the input to the block) and angle (radians) of a complex
input value.
Block Properties
Parameters
Name Complex-Polar Short for Complex to Magnitude-
Angle
Output Type “Magnitude- Selection of the output type for this
Angle” block
“Magnitude”
“Angle”
This block does not support variable parameters
Defaults:
Output Type = “Magnitude-Angle”

The output ports of the block are displayed based on the “Output Type” selection. The selection
controls which parameter output port. The images below show this:
Note that the complex to magnitude and complex to angle options are supported graphically but
not supported by the UDM translation engine. These options will be available in a future release
of the program. For now, use the complex to magnitude, angle block and take either the
magnitude or angle outputs.

25.4.28 Data Plotter Block

The benefit of this block is the implementation of a data plotter block which allows the value of
any intermediate parameters (variables) inside the model to be plotted by exporting the results to
a comma separated file (*.csv file) or graphically by observing the test routine simulation results.
Block Equations
This block outputs internal variables in the model from the time the transient stability simulation
starts to run. In the case of generic lumped loads and WTG models, the data plotter starts to plot
internal variables during the initialization procedure.
The output Yplot is the plotted value at every plot time step defined by the TS calculation engine
or by the test routine time step and plot step.
Block Properties
Parameters
Name Data Plotter
Number of Plots 1~10 Number of inputs for generating
plots
Parameter Range
Maximum Number of Input Plots = 10 (i.e. ten (10) input pins)
Parameter Defaults
Number of Plots = 1

The “Number of Plots” input field allows you define the number of inputs and plots to be
generated by the program in *.csv format. In the image below, the number of plots was selected
as 2.
Please note that the first value to be outputted into the *.csv output file is the first or top input.
The indication of the input number is added to the column name. For example, if a two input data
plotter block is plotted, then its name is used to generate the column name and the input number
is appended as shown below:

Data Plotter ID_<Input Number>

Data Plotter_1
Data Plotter_2
In ETAP 16.0.0 the scope has been enhanced to receive input values from the test routine
simulation. Whenever you run the test routine, all the active and connected scopes will open and
show the results of the simulation.
Note that the header of the scope output plot shows the name of the input connector “AVR
Output” as an example. In ETAP 16.0.0 you can add text names to the connectors so that you can
easily identify the plot. The image below shows how to name the connector.

Another new feature of the scope block in ETAP 16.0.0 is that its output data values (obtained
from the test routine) can be quickly exported to MS Excel. To do this all you have to do is right
click inside the plot and select the option “Save”.
The UDM scope interface generates an output *.csv file with the name of the output variable or
connector name which also includes the data of the simulation execution (see image below).

The output of the scope is limited to a certain maximum value of data points. The UDM scope
detects the maximum number of data points to be generated when the test routine simulation is
launched using the following formula:
Data Points = ((Total Simulation Time / Time Step) / Plot Step) * Number of Plots
If the maximum data points of all the combined scope output plots exceeds the maximum
number the program will prompt a warning message:
The maximum number of data points is approximately 0.6 x106 to 0.7 x106. This number
represents the combined data point capacity of all the scope plots open. As suggested in the
warning message, it is advised to reduce the number of scopes, reduce the total simulation time,
increase the simulation time step or increase the plot step.

25.4.29 Simulation Time Block

The benefit of this block is the implementation of a clock, which brings the simulation time into
the model. The simulation time comes from the transient stability calculation.
Block Equations
The behavior of this block is the same as that of the existing integrator block in Simulink.
Yout t
The output Yout is the simulation time, which is accumulated based on the time step from the TS
calculation. It is recommended that the time step from TS be smaller or equal to the time step
used internally to initialize the governor, exciter and power system stabilizer models. For generic
lumped load and WTG models, the time step from TS is used directly to initialize the models.
Block Properties
This block only allows the user to define its ID or block name.

This element is very simple in its application yet serves a very powerful role in dynamic
simulations. In combination with lookup table blocks, it allows the definition of any time-based
action which occurs internally in the model. This allows the definition of internal actions, which
are synchronized with the transient stability simulation time.

25.4.30 Script Block (MIMO User-Definable Block)

This block is a user-definable multi-input multi-output block. The block mathematical or logical
function can be implemented in generic C# language code. This capability is an enhancement in
ETAP 16.0.0 and adds tremendous flexibility for the implementation of complex UDM models.
Block Equations
This block outputs whatever calculation of equation has been defined by the user. By default, the
script block has been configured as a “pass-through” block (i.e. the first output is equal to the
first input). If the second output is enabled, the value has been set to twenty (20). The default
equations shown below can be changed according to whatever C# statements are added in the
block.
Y1 u
Y2 20
In general, the block equations for the script block output pins can be described as:
Y1 f ( u ,u1 ,...u9 )
Y2 f ( u ,u1 ,...u9 )
Block Properties
Parameters
Name Script Block It is recommended to use only valid C#
characters for the script block name.
Number of Inputs 1~10 Number of inputs for the script can as
high as ten.

Number of Outputs 1~2 Number of outputs can be maximum of

two
Assemblies User-definable This capability will be added to a future
release of ETAP UDM
Source Code User Definable This field is for display only and stores
code storage the script block code.
Parameter Range
Maximum Number of Input Plots = 10 (i.e. ten (10) input pins). Maximum number of outputs is
two (2).
Parameter Defaults
Inputs = 1
Outputs = 1

The script block sample logic code is shown below:
**************************************************************************
namespace UdmEngineLib
{
// UDM Script Block Code
// It is recommended to test the script block code using the provided test routine.
// C# syntax is checked with the test routine. User is responsible to properly test.
// The script block logic (program) prior to deployment in UDM simulations.
// For more information please refer to ETAP help file/User-Guide.
// Beginning of "using" statement definitions

// WARNING: "using" statements must remain inside "namespace"
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using UdmScriptEditor;
using System.Numerics;
//End of "using" statement definition section
// WARNING: Class name must match block name

public class Script13 : IUserCode
{
private Complex a;
private double x = 0;
/// Test Routine Information

/// The following routine is called when testing user code. Modify as needed.

/// Beginning of test routine definition

public void TestRoutine()
{
var y = 2 + 3;
OnInitialize(0.00111, 10);
double y1 = 0;
double y2 = 0;
OnSolve(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, out y1, out y2);
MessageBox.Show(String.Format("y1 = {0}\ny2 = {1}", y1, y2));
}
/// End of test routine definition
/// Initialization Routine Information

/// This method is called once during initialization and
/// before the simulation starts
/// <param name="dtSecs">Simulation time step in seconds</param>
/// <param name="TstopSecs">Simulation stop time in seconds</param>
/// Beginning if initialization definition
public void OnInitialize(double dtSecs, double TstopSecs)
{
x = 10;
a = new Complex(2, 3);
}
/// End of initialization definition
/// Simulation Routine Information

/// This method is called once at each time step of the simulation
/// <param name="y1">Output 1</param>
/// <param name="y2">Output 2</param>
/// <param name="u">Input 1</param>
/// <param name="u1">Input 2</param>
/// <param name="u2">Input 3</param>
/// <param name="u3">Input 4...</param>
/// ...
/// <param name="u9">Input 10...</param>
/// <returns>A scalar outputs.</returns>
/// Beginning of simulation routine definition
public void OnSolve(double u, double u1, double u2,
double u3, double u4, double u5,
double u6, double u7, double u8, double u9,
out double y1, out double y2)
{
//sample code for y1 is a pass-thru block (output 1 = input 1)
//sample code for y2 is a pass-thru block (output 2 = input 2 for two output script block)
y1 = u;
y2 = 20;

}
}
}
****************************************************************************
The equation definitions are contained within the “OnSolve” routine defined above. As can be
seen the sample equations are defined as “y1 = u;” and “y2 = 20;”
The sample code above contains system definitions and function and variable definitions. Most
of the variable definitions in some of the sections are there for illustration purposes only.
The following requirements and code change restrictions apply to script blocks:
1. The name of the script block must match the name public class name. The UDM editor
has logic to automatically enforce this condition. There is no need to change this part of
the code unless for some reason the script block is renamed.
2. The system statement definitions must remain within the namespace UdmEngineLib
definition brackets. It is recommended to not change these definitions but if new
definitions are added, they should be placed in the same section as shown in the sample
code above.
3. The syntax of the C# instructions is checked; however the logic and code should be
debugged and tested. The built-in test routine can be modified with different input and
output values to test the code. However, complex code logic should be tested
systematically before applying it to the script block.
4. The initialization values apply for the very first output value during initialization. By
default, the initial value of the script block outputs for initialization is zero.
The script block supports some of the following C# statement types:
1) Logical
2) Conditional
3) Relational
4) General numeric calculations
The system definitions indicate the supported C# statements and features.
Code Sections
1. The code should begin within the “namespace” provided by ETAP. This section is
highlighted in the following image with a blue box. (Note: all the brackets in the script
block should be in pairs).

2. Script block code is divided into two major functions:

a. Code for Test Code button (test routine)
This section of code is executed when the Test Code button is clicked.
The displayed code calls the OnSolve function during the test routine. This can
be edited to refelect the user needs.
The variables y1 and y2 are declared in this code to display the message box.
The code “MessageBox.Show…..” should not be removed from the test routine
function.
b. Code for simulation time (function OnSolve)

The code in this function is executed during simulation time.

This function can be called in test routine.

User-Defined Dynamic Models Creating UDM Models
Creating UDM Models

This section is meant to provide the step-by-step process of creating different types of UDM
models. This section also covers some of the concepts required to create models using the
fundamental blocks.
25.5.1 Creating AVR / EXC UDM Models

The automatic voltage regulators (AVR) and exciter (EXC) models can be created for the
synchronous machines (motor/generator). The AVR and EXC are both part of the same dynamic
models. The job of the exciter is to generate a control signal, which determines the amount of
excitation applied by the exciter on the generator field windings.
Typically the AVR has a summing type input where the reference signal (Vref) and the terminal
bus voltage (in p.u. bus base kV) generate a difference signal which is then amplified and
processed by an amplifier. The amplifier output is used by the exciter to determine the
proportional excitation voltage applied on the field winding. The output of the exciter model is
the exciter field voltage (Efd in p.u based on the exciter rated output voltage). The base of the efd
output voltage can be thought of the value of excitation required to provide 1.0 p.u. rated current,
based on the generator rated current.
The following steps summarize the process of creating an EXC/AVR model:
1) Create a new model by opening the UDM editor from the synchronous generator/motor
exciter page or from the system toolbar (it is recommended to create the model from the
element so that the naming convention is automatically applied and the model is
automatically linked to the element).
2) Name the model and define the model type from the System Model Parameter section. In
this case, the model type is “Exciter.”
3) Select an Initialization method. The default method to initialize the exciter model is the
Iterative method. The direct method or the iterative method can be selected (please refer
to the initialization techniques section for more information on these methods). For the
purpose of this example, the direct method can be selected but not recommended as
default.
4) Define the inputs and outputs and reference blocks. For this example, “Vt”, “Vref” and
“Efd” should be defined.
5) The AVR transfer function can be entered. The AVR function can be tested with a simple
exciter to verify its performance.
6) The Exciter transfer function can be entered.
7) The model can be tested using the test routine or with a simple system in transient
stability.
8) Once the model has been developed, it can be saved and linked to other generators or it
can be added to the exciter model library.
Step 1
Please refer to section 25.1.1. Create a new UDM project as shown below:

Step 2
Name the model and define the system parameters model type. Name the model EXC1. Define
the model as an “Exciter”.
Step 3
Select the initialization method as “Direct” (Iterative method is recommended as default)
Step 4
The inputs and outputs can be defined. Select click on the Inputs section of the element toolbar
as shown below and enter the first input “Vt”. Then click on the output section and select the
output to be “Efd”. From the control blocks section, select a constant block and name it “Vref”

Before proceeding to Step 5, select the Vref block to be the reference voltage signal for this
exciter model. Do this from the system parameter section under the “System Reference” section.

Step 5
Now construct the AVR transfer function by adding the summing point (sum block), a transducer
(to simulate the measuring circuit time constant) and the regulator blocks.

Once the AVR is built, it is a good idea to run a quick test to determine if it works well. If the
AVR portion of the model does not work, then it may be difficult to determine what is wrong
with the model, once many more blocks are added. The best practice would be to do some quick
tests on this portion of the model first. In order to do this a simple time constant block can be
used to represent the exciter. By connecting the exciter block and the output, we get a simple
exciter model that may be used to test the AVR portion.
We can compile the model and run a few test routines to check the behavior of the exciter. A six
second total simulation time is used for all three tests.
Load Shed Test Results
Load Acceptance Test
Fault Test Results

The UDM models for the synchronous motor are exactly the same as those for the synchronous
generator. The only difference is that the exciter for synchronous motors is selected from the
exciter page of the motor element.

25.5.2 Creating GOV/Turbine UDM Models

This section describes the process of creating and testing a GOV/Turbine Model using the UDM
editor.
The governors or speed controllers (GOV) and turbine/engine models can be created for the
synchronous generators. Typically, a speed/output power controls a turbine or engine model.
Both of these components are contained within the type of model defined and called “Governor”.
The job of the speed and power controllers is to regulate the shaft speed and mechanical power
output of the turbine/engine. The turbine/engine model represents the dynamics of the
mechanical system, which provides the power to the generator.
Typically, the speed/power controller has a summing type input where the reference speed
(Wref) and the shaft speed (in p.u. generator rated RPM) generate a difference signal which is
then amplified and processed. This signal can be sent to a variety of devices including valves,
actuators, servomotors, gates etc. These devices exert control on the fuel, steam and even water
flow in order to adjust the speed and power delivered by the mechanical system to the generator.
The output of the governor model is the mechanical power (Pm in p.u. based on the machine
rated MW base). 1.0 p.u. for a 10 MW generator equates to 10 MW of mechanical power
delivered by the shaft to the generator unit.
The following steps summarize the process of creating a governor model:
1) Create a new model by opening the UDM editor from the synchronous generator
governor page or from the system toolbar (it is recommended to create the model from
the element, so that the naming convention is automatically applied and the model is
automatically linked to the element).
2) Name the model “GMdl1” and define the model type from the System Model Parameter
section. In this case the model type is “Governor”.
purpose of this example, the iterative method can be selected. This is preferred.
4) Define the inputs and outputs and reference blocks. For this example, “W”, “Wref” and
“Pm” should be defined.
5) The speed controller transfer function can be entered. The speed controller function can
be tested with a simple governor to verify its performance.
6) The turbine/engine transfer function can be entered.
stability.
can be added to the governor model library.
Step 1
Please refer to section 25.1.1. Create a new UDM project.

Step 2
Name the model and define the system parameters model type. Name the model 1. Define the
model as a “Governor”.
Step 3
Select the initialization method as “Iterative.” (iterative method is recommended for all cases).
Step 4
as shown below and enter the first input “W”. Enter the second input “P”. Then click on the
output section and select the output to be “Pm”. From the control blocks section, select a
constant block and name it “Wref.”


Before proceeding to Step 5 select the Wref block to be the reference voltage signal for this
exciter model. Do this from the system parameter section under the “System Reference” section.
Step5
Now we can create the speed controller. To do that we can add and connect the blocks as shown
below. Please note that this is a proportional integral type controller.

Step6
We can test the speed controller by using a simple engine model (transfer function) and
connecting it to the mechanical power output “pm”. The image below shows the process and
quick load shed test result.

Step7
Now we can create a simple actuator and model the fuel delay of the engine (in most cases the
fuel system time delay is the only portion model for the engine). The images below show the
actuator and fuel system models.
The image above shows the conversion of the PID output to the actuator degree base. There is an
actuator time delay and a limiter, which shows that the actuator can only go from -60 to +60
degrees. The integrator and the feedback complete the dynamic representation of the actuator. At
the end of the image we convert back from actuator units (degrees to per unit). The per-unit
output can then be coupled to the engine model shown in the image below:

In the previous image, the Act to Torque conversion serves as a gain, and couples the actuator to
the engine power limit block (limiter) and to the fuel system dynamics. The output is the
mechanical power.
It is important to understand that the Pm output should be in per-unit. Where 1.0 p.u. represents
the machine rated MW base (Generator-rated MW and not the engine-rated MW).
Step 8
Now we can connect the speed controller to the actuator and engine models. The image below
shows the completed model (the temporary transfer function representing the engine has been
removed).
Please note that the generator real power output input block has been left unconnected until now.
This input can be used to add base loading control to the speed controller. The model we have
created will operate only in isochronous mode.

The model can be tested using the iterative method and default settings. The images below show
the results for a fault, load shed and load acceptance tests. As can be expected during a fault, the
mechanical power output (not the speed) starts to reduce. The mechanical power output goes up
or down for the load change tests.
Fault Test Results
Load Acceptance Test
Load Shed Test

25.5.3 Creating UDM Models for Power System Stabilizers

This section describes the process of creating and testing a PSS Model using the UDM editor.
The power system stabilizer can be created for synchronous generators only. Typically, PSS
units are added to a power system to enhance the damping to extend power transfer limits. A PSS
works in conjunction with the excitation system of the synchronous machine to modify the
torque angle of the shaft to increase damping.
The PSS has different types of inputs. They include speed, frequency, power, accelerating power
and integral of accelerating power. ETAP UDM uses the terminal voltage, electrical power,
mechanical power, speed, rotor angle, and frequency as possible inputs. The output typically is
signal-fed directly into the summing point of the automatic voltage regulator.
The following steps summarize the process of creating a PSS model:
1) Create a new model by opening the UDM editor from the synchronous generator PSS
page or from the system toolbar (it is recommended to create the model from the element
so that the naming convention is automatically applied and the model is automatically
linked to the element).
2) Name the model “PSSMdl1” and define the model type from the System Model
Parameter section. In this case the model type is “PSS”.
purpose of this example, the direct method can be selected; however, the iterative method
is preferred.
4) Define the inputs and outputs and reference blocks. For this example, “Pe” and “Vs”
should be defined.
5) The PSS controller transfer function can be entered. PSS units are electronic devices
which in most cases, are tied directly to the exciter controls.
stability.
can be added to the governor model library.
Step 1
Step 2
Name the model and define the system parameters model type. Name the model 1. Define the
model as a “PSS.”
Step 3
Select the initialization method as “Direct.” (for this example only. Use of the iterative method is
recommended for the majority of cases).

Step 4
The inputs and outputs can be defined. Click on the Inputs section of the element toolbar as
shown below and enter the first input “P” or “Pe”. Now click on the output section and select the
output to be “Vs”. From the control blocks section, select a constant block and name it “Wref.”
There are no reference constant blocks that need to be defined for a power system stabilizer in
ETAP UDM.
Step5
Now we can create the PSS transfer function. To do that we can add and connect the blocks as
shown below.

Step6
Now we can test the power system stabilizer model. Please add the test settings as shown below
in the test setting section of the model parameters prior to running the test.
The power system stabilizer has only one type of test. The test results are shown below.
Typically, the PSS has limited output to the AVR. In this case, the test disturbance shows that the
signal has been limited to ± 0.05 per unit.


25.5.4 Creating General Load / Source UDM Models

This section describes the process of creating and testing the generic load / source UDM models.
Note: The lumped load type must be set to conventional, in the nameplate tab, to utilize a user-
defined dynamic model through a lumped load and run a transient stability study.
The generic models can be created by using the lumped load editor. Different types of models
can be created and they include:
1) Static Load Models

• Exponential
• Polynomial
• Comprehensive
2) Dynamic Load Models
• Discharge Lighting Loads
• Thermal and overcurrent relays and motor starters
• Thermostatically controlled loads (space heaters)
3) MOV and Motor Models (for acceleration studies)
• Static motor models
• Dynamic motor models
• DC motor acceleration models
4) Time-Domain Model (recorded signals or loads used as part of the model)
• Load Profiles
• Signals recorded over a time period
5) AC to DC Source Models for dynamic studies
• Inverters
• Converters
6) PV array and inverter models – Solar Models
7) Wind Turbine Models
• Simple induction generator models
• Full and half converter models
8) SVC / STATCOM Models
9) More…
This example shows the creation of static and dynamic load models.
The following steps summarize the process of creating a simple generic load (static) model:
1) Create a new model by opening the UDM editor from the lumped load dynamic model
page or from the system toolbar (it is recommended to create the model from the element
so that the naming convention is automatically applied and the model is automatically
linked to the element).
2) Name the model “ExponentialMdl” and define the model type from the System Model
Parameter section. In this case, the model type is “Generic”.
3) The initialization method for generic loads is different than for exciters, governors and
pss. The initialization is done forward. The output P & Q of the lumped load depends on

the input parameters. In the case of the synchronous generator models, the output values
are calculated prior to initialization and the internal reference values are modified until a
solution is reached. The only initialization parameter which is required for the generic
load models is located under the ETAP Preferences\Options editor (TS section). The
following image shows the entry and the suggested value for this example. The value of 1
second is good starting point for most load models.
4) Define the inputs and outputs. For this example, “Vt”, “Freq”, “P” and “Q” should be
defined. The input “Vt” and “Freq” inputs are in per-unit. Transient stability uses 1.0
MW as base for the real power and 1.0 MVAR as base for the reactive power.
5) The mathematical relationship for the load should be entered.
6) The output should be converted to the desired base.
7) Once the model has been developed, it can be saved and linked to other lumped loads or
added to the generic model library.
Step 1
Step 2
Name the model and define the system parameters model type. Name the model “exponential”.
Define the model as a “Generic Load” model.
Step 3
as shown below and enter the inputs “Vt” and “Freq.” Now click on the output section and
select the outputs to be “P” and “Q.”

Step4
Now we can create the generic load mathematical representation. To do that we can add and
connect the blocks as shown below. Please note that the equations used to represent the load are
shown below:

For this example, the value of the a & b exponents is 2 for both. This means that the load will
behave as a constant impedance load. The system frequency changes play a factor along with the
gains “Kpf” and “Kqf”. A function block can be used instead of the multiplier blocks (to obtain
the square of the voltage).
Step5
Compile and link the system to a lumped load. This can be done in the end system for which the
model was created or it can be done in a test system like the one described in step 6.
Step6
Before using the load model in the actual system, it can be tested using a simplified test system.
The test system should have very little voltage drop so that the internal voltage input value is
close to 1.0 p.u. This helps with the initial debugging of the UDM model equations.

As expected the real and reactive power of the lumped load is very close to 2 MW and 1 MVAR
since the voltage and frequency are very close to 1.0 p.u.
Step 7
To convert the generic lumped load into a source of power, all we have to do is to add a negative
multiplier to the “P” and “Q” outputs.

The image below shows the TS load flow results after compiling and running the simulation. As
can be seen, the power is now flowing into the system and the generic load is behaving as a
voltage dependent “P” & “Q” source.

25.5.5 UDM Model Parameter Report

After compilation a UDM model, a report file with Microsoft Word format (.doc) for UDM
model parameters is generated in the same folder as project files. The name of the report file is
combined with generator ID and UDM name, as shown as follows:

User-Defined Dynamic Models Sharing Modes
EXC/ GOV MW/Var Sharing Modes

The exciter and governor models can be configured to share real and reactive power between
several generator units.
25.6.1 Load Sharing
Load Share (Psh)

Use this pull-down list to map the variable name of load sharing to the ETAP key word (Psh).
This is the governor load sharing power reference in per-unit of generator MW.
Group Number
The group number allows you to take several generators and group them together for load
sharing. In the image above, you would select Gen1,2,3 as Group Number 1 and Gen 4,5,6 as
Group Number 2, otherwise this pull-down list will be grayed out. The default group number
“0” means no load sharing available.

User-Defined Dynamic Models Sharing Modes
25.6.2 Exciter Var Sharing Mode

For the exciter cross current compensation model, the number (ID) of the group in which the
generator participates in var sharing needs to be specified in UDM Exciter Editor, as shown in
the example below. The default group number “0” means no var sharing available and the
selection box is grayed out.
var Share Group Number

The group number allows you to take several generators and group them together for var sharing.
In the image above, you would select Gen1,2,3 as var Share Group Number 1 and Gen 4,5,6 as
var Share Group Number 2; otherwise this pull-down list will be grayed out. The default group
number “0” means no var sharing available.

User-Defined Dynamic Models Test Model
Testing UDM Models

The UDM Program also allows you to perform a stand-alone test for your UDM equation files.
Depending on the model type that you have selected, click the Run Test Simulation button to
launch the test simulation for the UDM models. The test settings are located under the system
parameters section of the UDM editor and are provided to allow you to specify the appropriate
system input variable values and the test types like Load Shedding, Load Acceptance, and Fault
Bus for a simple power system. The test power system consists of a single generator connected
to a single load via a transmission line as shown below. The parameters of the power system are
built into the program.
Governor
Vt
Generator
Exciter
ZL
25.7.1 Governor Model Test

The Governor Model test parameters are located in the model parameters section. The system
test input/output values, simulation time, system output and test types are described below.
Test Type Events
Load Shed
Select this option to simulate a power system load shed of 50%.
Load Acceptance
Select this option to simulate a power system load addition of 50%.
Fault Bus
Select this option to simulate short-circuit fault on the generator terminal bus.
None
Select this option to simulate the transfer function or model running under steady-state
conditions after it has initialized. Note that some small transients may be visible at the beginning
of the simulation. This small transient is a result of the internal initialization precision. The
important result of this test is that the system stays under steady-state conditions after this small
initial transient has decayed to its final running value.

Simulation Time Step

Enter the simulation time step in seconds for the governor test routine. It is recommended to
enter a value smaller than the smallest time constant in the governor system.
Total Simulation Time

Enter the total simulation time in seconds for the governor test routine. It is recommended to
enter a simulation time which is greater than the event time and which allows you to observe the
necessary transient behavior. Using large simulation times may lead to potential data point issues
with the scope outputs. Please see the scope section of this chapter for more details. The default
is 40 seconds.
Simulation Event Time

Enter the time at which the test routine simulation event will take place. The default is 2.0
seconds.
Plot Step
Enter the plot step for the simulation in multiples of the time step. Default is 20.
Test Inputs
The test routine has been enhanced in ETAP 16.0.0 to accept user-specified values for the inputs
which are supposed to come from the generator. In the case of the governor system the user can
type in the desired values for the speed and the electrical power output.
Speed (W) – User definable value which can be used for test routine simulation
Elec Power (Pe) – User definable value which can be used for the test routine simulation
Test
When the test input values and simulation times are specified and a test type is selected in the
Governor Model Test Editor, you can implement the governor model testing by clicking the
“Run Simulation Test” button.

25.7.2 Exciter Model Test

The Exciter Model test parameters are located in the model parameters section. The system test
input/output values, simulation time, system output and test types are described below.
Test Type
Load Shed
Select this option to simulate a power system load shed of 50%.
Load Acceptance
Select this option to simulate a power system load adding of 50%.
Fault Bus
Select this option to simulate a short-circuit fault on the generator terminal bus.
None
Select this option to simulate the transfer function or model running under steady-state
conditions after it has initialized. Note that some small transients may be visible at the beginning
of the simulation. This small transient is a result of the internal initialization precision. The
important result of this test is that the system stays under steady-state conditions after this small
initial transient has decayed to its final running value.

Enter the simulation time step in seconds for the exciter test routine. It is recommended to enter a
value smaller than the smallest time constant in the exciter system.

Enter the total simulation time in seconds for the exciter test routine. It is recommended to enter
a simulation time which is greater than the event time and which allows you to observe the
with the scope outputs. Please see the Scope Section of this chapter for more details. The default
is 40 seconds.

seconds.
Plot Step

Test Inputs
which are supposed to come from the generator. In the case of the exciter system the user can
type in the desired values for the following:
Terminal Voltage (Vt)

PSS Signal (Vs)
Terminal Frequency (Fre)
Field Current (Ifd) (ignored since the test routine can calculate this value but user can still
type in a value)
Test
Once the test input values and simulation times are specified and a test type is selected in the
Exciter Model Test Editor, you can implement the exciter model testing by clicking the “Run
Test Simulation button”.

25.7.3 PSS Model Test

The PSS Model test parameters are located under the model parameters section of the UDM
editor. The test input/output values, simulation time, and test types are described below:

Enter the simulation time step in seconds for the PSS test routine. It is recommended to enter a
value smaller than the smallest time constant in the PSS system.

Enter the total simulation time in seconds for the PSS test routine. It is recommended to enter a
simulation time which is greater than the event time and which allows you to observe the
with the scope outputs. Please see the Scope Section of this chapter for more details. The default
is 40 seconds.

seconds.
Plot Step
Test Inputs
which are supposed to come from the generator. In the case of the PSS the user can type in the
desired values for the following:
Shaft Speed (W)

Terminal Voltage (Vt)
Real Power Output of the generator (Pe)
Rotor Angle (Ang)
Mechanical Power (Pm)
Voltage Frequency (Fre)
Test
Once the test input values and simulation times are specified in the PSS Model Test Editor, you
can implement the PSS model testing by clicking the Run Test Simulation button. The PSS
model test is conducted by placing a pulse disturbance only on input signals.

25.7.4 Gen Load and WTG Model Test

The Gen Load (lumped load models) and WTG UDM models did not have a test routine in
versions prior to ETAP 16.0.0. The test routine for these models allows you to run and test the
UDM model prior to its implementation in the transient stability simulations.
Test Type
None
The test simulates a time advance from t = 0 to the end of the total simulation time. Unlike the
PSS, Exc and Gov, the test routine for the Gen Load and WTGs does not have an event time.
Events can be introduced by the use of the clock input block if necessary.

Enter the simulation time step in seconds for the PSS test routine. It is recommended to enter a
value smaller than the smallest time constant in the PSS system.

Enter the total simulation time in seconds for the PSS test routine. It is recommended to enter a
simulation time which is greater than the event time and which allows you to observe the
with the scope outputs. Please see the scope section of this chapter for more details.
Plot Step
Test Inputs
which are supposed to come from the element or the network (system). In the case of the Gen
Load/WTG the user can type in the desired values for the following:
Complex Terminal Voltage (CVt) Magnitude (for both Gen Load and WTG)
Complex Terminal Voltage (CVt) Angle (for both Gen Load and WTG)
Terminal Voltage Frequency (for both Gen Load and WTG)
Terminal Bus Voltage (Vt) Magnitude (WTG Only)
Control Bus Voltage (Vc) Magnitude (WTG Only)
Wind Speed (WS) (WTG only)

User-Defined Dynamic Models Advanced Topics
Advanced Topics
25.8.1 Report of middle state variables of UDM model
If you want to see the outputs of some middle state variables of UDM model, you can use the
“Data Plotter” block to connect to the point you are interested in the UDM model as shown
below, in an example of UDM block diagram.
After the simulation is completed, a report file with Microsoft Excel format (.csv) for the
specified middle state variable outputs will be generated in the same folder as the project file.
The name of report file is a combination of the generator ID and UDM name, as shown as
follows:


25.8.2 Switching governor between Droop and Isochronous Modes

If a governor has Droop and Isochronous Operation Mode options, the UDM can allow you to
simulate the switch behavior between Droop and Isochronous Modes. In order to do that, first,
you need to use an ETAP reserved key word “Drp” block to flag the initial operation mode in
the UDM model. The following diagram shown below is an example to set up the switch options
between the Droop and Isochronous Modes. The Drp constant block is handled only for
EXC/GOV/PSS models.
Then, you need to create in the ETAP Transient Stability Study Case Editor an action event to
switch the Operation Mode for the generator. The event setting is shown as follows:


25.8.3 By-pass some blocks during initialization process

If you use Iterative method for UDM initialization, for some models a special setting for some
control blocks such as MinMax or Saturation blocks may cause the UDM initialization to fail.
These blocks may need to be by-passed during the initialization process in order to successfully
initialize the EXC/GOV/PSS models. An ETAP UDM reserved key word “iniCnst” constant
block can be used to control the path for initialization loop or simulation loop. The following
diagram is an example to show how to set up the control structure. The initial value of “iniCnst”
block is set to 1; the initialization loop is on during initialization process. Once the initialization
is successfully completed, the value of “iniCnst” block will be automatically changed to 0 and
the normal simulation loop will be switched to on.
Please note that the “iniCnst” constant block is used only for the EXC/GOV/PSS models. The
simulation time block can be used to by-pass blocks for the Generic Load and WTG udm
models.
Note that it is recommended to use the iterative method for translating UDM models. The
iterative method should work for exciters and governors. The use of the direct initialization
method will be discontinued in future releases of ETAP, and also may not work well for 90% or
higher of all UDM models.
Starting with ETAP 16.0.0, the speed of the initialization process has been significantly
improved and thus the use of the direct method is encouraged even less.

25.8.4 General Load and WTG Modeling in Transient Stability

The general load and WTG UDM models have two types of outputs to interface with transient
stability. One set of outputs are Pe and Qe. The other output type is Itc (complex terminal
current). This section describes some of the analysis and modeling considerations for both types
of outputs.
Pe, Qe Output Considerations in Transient Stability

The General Load and WTG udm models are handled as constant power loads in the transient
stability calculation when their outputs are Pe, Qe or both. This assumption requires certain
modeling techniques for simulations where the terminal bus voltage connected to these loads
goes to values near zero. The modeling techniques are listed below:
1) Under low bus voltage conditions and constant power modeling, the resulting load
current becomes very high and will eventually cause the solution to diverge.
2) The VLC limit setting in the dynamic page of the transient stability study will cause the
constant power load or source models to automatically switch to constant impedance
ones.
3) The transient stability program automatically sets the current equal to zero if the terminal
voltage becomes very low (i.e. approximately less than 0.1% or less of bus nominal kV).
Because of the previous modeling issues, the following design considerations and effects on the
results are obtained:
1) The VLC limit must be set to a small value in order to prevent the general
load/source/wtg model from being switched to a constant impedance model.
2) The real and reactive power outputs must be multiplied by the voltage or the square of the
voltage in order to reduce to zero under the condition where the input terminal bus
voltage goes to zero.
3) The behavior of the model under fault current conditions will not be accurate since there
is no internal machine model or internal voltage present in order to contribute current into
the system. This presents no problem for most load models like converters (rectifiers) or
dynamic loads, but is a problem if the UDM model intends to represent a load which can
contribute current to a fault on its input terminal (such as is the case with induction motor
models being represented with UDM).
4) Wind turbine models with terminal bus faults will also contribute to the fault, but this
behavior may not be accurately modeled using the UDM technique. The existing WTG
built-in models can be used for fault analysis.
The following image shows a test system used to illustrate the condition described above:

The bus terminal voltage plots for Bus1 and Bus5 are shown below:
The real and reactive power output plots show that there is a dependency on the input voltage:

The real power output shows that as the voltage goes down, so does the real power output. This
behavior is accomplished by multiplying the real power output in the UDM model by the voltage
as shown below:

If the input voltage is set completely to zero during simulation and the model does not handle
this condition internally, then the load/source current may be set to zero at this point and the
model may not be part of the system.
The addition of different modeling techniques in the future will help in the modeling of this
condition. In the meantime, special attention should be paid to the simulation conditions
described in this section.
Itc Output Considerations in Transient Stability

The use of Itc was added to ETAP UDM in version 16.0.0. This enhancement allows some of the
restrictions described in the previous section. The use of Itc makes the UDM model interact with
transient stability using a current injection method.
1. When Itc is used, the VLC limit no longer applies.
2. When Itc is used, low voltage transient simulations (including those which faults at the
terminal connection bus of the gen load or wtg) no longer require the reduction of the
current to zero. The injection of current towards the fault will take place based on the
model design.
Switching Actions with Gen Load and WTG UDM Models

There other additional considerations related to the use of Itc for Gen Loads and WTG UDM
models. These considerations are related to what happens when these UDM model types become
de-energized or are de-energized and become energized during the transient stability simulations.
The considerations are listed below:
Gen Loads with UDM can be energized and de-energized with switching actions of PDs
directly connected to the terminal connector.
Gen Loads with UDM can be energized and de-energized with switching actions of PDs
not directly connected to the terminal connector.
WTGs with UDM can be? de-energized with switching actions of PDs directly connected
to the terminal connector. However, WTGs cannot be re-energized once their terminal
connector PD has been opened. The TS simulation would report this as an invalid action.

WTGs with UDM can be energized and de-energized with switching actions of PDs
which are not directly connected to the terminal connector.
When modeling switching actions involving WTGs with UDMs, it is recommended to

user the Itc (complex current output) instead of Pe and Qe outputs. Using Pe and Qe may
result in non-stable numerical issues in the transient stability simulations.
When de-energizing or re-energizing Gen Load and WTG models the UDM model will
be turned off during the period of time which it remains de-energized. This means that if
the program determines that the Gen Load or WTG UDM model element is not
connected to an energizing source (such as utility or generator, etc.) the program will
automatically turn off any current or power injection for both types of models.
To model situations where the WTG or Gen Load UDM model elements are still
participating with network elements in the absence of any other energizing source, a
special INI entry needs to be added to ETAP. The INI entry is provided below:
UDMGenLoadItcCurrentInjectionWhenDeenergized=0
When the value of the entry is set to 0, the Gen Load and WTG UDM element will be
completely disconnected from any part of the network still connected to it under
situations where there is an absence of any other energizing source.
When the value of the entry is set to 1, the Gen Load and WTG UDM element will be
kept in the simulation and will be allowed to participate in the islanded network under
situations where there is an absence of any other energizing source. This is the default
value of this option.
Note that when using this entry with a value equal to 1, there must be a shunt-connected
path for the current injection flow from the Gen Load or WTG UDM model element. If
this path is not present, there may be voltage rise transient conditions.
An example of a terminal connector-switching device or PD (protective device) is given below:

Examples of de-energized islanded networks with/without a shunt path for current injection flow
is given below:
First: De-energized islanded network without a shunt connection.
Second: De-energized islanded network with a shunt connection.

25.8.5 Input/Output Block Application Notes

The generic input and output blocks which are part of every model require some special
considerations for their application as communication channels across models. This section
provides some insights into some of these considerations.
1. Output signals can be internal or external: Output ports make their output variable
parameters available for input blocks within and outside the UDM model. This means
that matching input and output ports can transfer data within the model when the
simulations are executed (Simulation Mode DPET Mode) and can transfer data across
models when transient stability is running. The input and output ports must have the same
variable ID and the same communication link ID or GUID.
2. Requirement for Output Port Variable ID Uniqueness (UDM Standalone): variable

names should be unique for each input/output port pair. If the same variable ID is used in
two different output ports with the same communication link ID or GUID, then an
overwrite of the value will occur. The last evaluated port value will be send to the
variable and any previous values. In the image below both “Out” and “Out1” output ports
have the same GUID and write to the same variable called “abc1”.

3. Requirement for Output Port Variable ID Uniqueness (Transient Stability): when

running UDM with TS make sure that only one output port writes to the same variable
name. If more than one output port with the same GUID writes to the same variable, then
an overwrite will occur and the value passed to the variable will be that of the last
evaluated output port. In the image below, an exciter UDM model with an output port
called “Out” and a governor UDM model with an output port called “Out” are both
writing to the same output port variable called “abc1”. Both ports have the same GUID.
This results in overwrite of the variable value. Note that in different models, the output
ports can have the same name and thus the GUID helps to make these output signals be
unique and prevent overwrite of data signals with the same variable ID.

4. Input ports Signal can be Internal or External: Using the same variable name in
multiple input ports will effectively transfer the variable value to all of the input ports.
This is an easy way to implement a distribution point to multiple connections or
locations. An example is to write a set point value to a variable through an output port
and then read that variable in 10 different machines (e.g. 10 wind turbines). In the image
below the value of the output variable “abc1” is being broadcast to “In”, “In1” and “In2”
since all three input ports use the same variable name “abc1”. Note that the output and
inputs should be external and they should all have the same GUID.
5. Input ports without matching output port variable: If an input port uses a variable
which has not been used in any output port, then the output value of the input port is set
to zero (0).

6. Unconnected output ports: If an output port is left unconnected then its variable value is
set to zero (0).
7. Value of the input port variables during initialization for TS when the output port
variable does not reside within the model: When the matching output port and variable
do not exist within the same model, the input port uses its initial value (as defined in the
“Initial Value” field) for initialization. Once all the UDM models have initialized and the
TS simulation begins, then value passed to the input port is the value of the output port
variable at t = 0+. In the image below, the input port named “VarShareSignal” does not
have the output port with variable name “VarGen1” within the same model. The initial
value highlighted in the diagram is used in different ways as described in 7, 8 and 9.
8. Value of the input port variables during initialization for UDM Standalone when
the output port variable does not reside within the model: When the matching output
port and variable do not exist within the same model, the input port uses its initial value
(as defined in the “Initial Value” field) for initialization. The same value is used during
the test simulation running time (T=0+) since the UDM model with the source output
port variable is not involved (not active). In other words, the value of the input port fed
from an external output port is always equal to the initial value when running the model
in the UDM standalone simulation routine.
9. Value of input port variables during initialization and simulation for TS and UDM
Standalone when both input and output port variables reside within the model: The
initial value of the input port variable is used for the very first step of the initialization
process. During the rest of the initialization process and during the actual execution of a
TS or UDM simulation the value is calculated based on the output port input value passed

to the variable. In other words, the value of the input port is always determined from its
matching output port variable value except for a single initial point during the
initialization.
It is recommended to create models, which can initialize without rigorous need of the input port
variable values. If the model requires this input port variable value, then it is recommended to
enter values as close as possible to the actual values, which will be passed from the output port
during transient stability simulations. The values of these ports can be ignored during
initialization by means of the iniCnst tool as previously described in the advanced topics section
of this chapter.

25.8.6 Handling of Invalid Mathematical Function Input Values

The UDM program mathematical evaluations have been enhanced in ETAP 16.0.0 to detect
conditions where mathematical functions produce undefined output values (such as NAN, etc.).
This is of particular importance when using the SISO, MISO and Script Block blocks which have
the capability to handle different numerical functions.
This section provides information on how to debug and correct any invalid input error messages
which can be generated during simulation time in both transient stability and UDM standalone
interface.
An example of an invalid input to a mathematical function is given below. The image shows that
an invalid input is given to a square root function. ETAP UDM only handles scalar inputs and if
the input to the square root function is negative, then the output would be undefined.

The math function input can be negative during the simulation. When an undefined output value
is returned by any of the blocks, ETAP UDM will bring up the following warning message:
The message gives you three options:
Ignore this instance

Ignore all instances
Stop simulation
Ignore this instance

If you select this option, then for the given time step, the UDM program will ignore the invalid
output and proceed to the next time step. Note that if the condition persists in the next time step,
the same message will appear again until the invalid input is no longer detected. If the condition
could persist for hundreds or thousands of time steps, then this message would remain in effect
indefinitely.
Ignore all instances

This option tells the UDM simulation to ignore all instances of the invalid inputs to the math
functions. This is how ETAP 14.1.0 and previous versions used to handle the invalid input
condition. Now this could lead to invalid results or numerical instability and failed simulations.
The simulation will proceed unless there are other offending math functions with invalid inputs.
Note that if we choose to ignore all instances in the example above, the output of the math
function will be undetermined for the duration of the invalid input to the math block.

Stop simulation
This is the recommended option. Stopping the simulation and correcting the invalid input to the
math function is the preferred approach. To correct the invalid input condition we must limit the
invalid inputs to the function. When using the stop simulation option a second warning message
appears:
At this point, if you press the OK button, the entire simulation will begin the termination process.
If you are terminating a standalone UDM simulation this will be the ending point. If you are
terminating a transient stability simulation then there will be two additional error messages.
Example of those error messages are given next:

There are a couple of options to correct the invalid input depending on the physical meaning of
the mathematical function. The first method is to limit the input to the square root function to 0+
values. The other option is to take the absolute value of the input before executing the square
root function. Both solutions are shown below along with their expected effect on how the
mathematical function is solved. It is up to the user to determine the preferred method to prevent
the invalid mathematical function input.
Method 1: Saturation to limit value to 0+.
Method 1: Sqrt function output.
Method 2: Abs(u) priot to Sqrt(u).

Method 2: Sqrtr function output.
Detection of the Invalid Input Blocks (Identifying Offending Blocks)

In the previous example, the offender block is easily detectable since there are only a couple of
mathematical functions being used. In far more complex systems, the process of detecting the
offending blocks may be more difficult. To help the user detect the invalid input blocks, ETAP
UDM also provides the internal evaluation name or ID of the offending block. Notice that in the
message below, ETAP UDM provides the internal name of the offending block along with a clue
as to how to trace the block back the graphical block name representation.

Inside the *.doc files (a block input information file generated for all compiled UDM models)
there is a mapping table which can be used to map the internal block name, (in this case “block
5”), with its external graphical name or ID.
The image below shows the sample of the information:
In this file we can find the mapping information for block 5:
The internal block name is mapped to its graphical name “Function”.

Additional Considerations for Offending Block Identification

The invalid input condition may cause the invalid NAN output to propagate to other blocks. In
this situation it may difficult to identify the source of the problem. It is recommended to start by
reviewing and enforcing valid inputs for all mathematical functions in the transfer function.
Other recommendations/observations apply:
Offending block conditions may occur during initialization. During initialization there are
extremely large value swings which may not occur during simulation time (i.e. t = 0+).
Under this condition, it may be valid to use the “ignore all instance” option since the
transfer function will ignore the temporary invalid states which may occur during
initialization, but which are not expected to occur during the simulation.
Several blocks (not only mathematical blocks) may end up having invalid input
conditions. It is recommended to check all math-related blocks (including script blocks)
to verify their input range.
All 5 types of UDM models may experience the invalid mathematical input condition.
Invalid input error messages depend on the type of simulation and transient condition
being executed. Not all transient simulations may cause the input of the functions to be
invalid.
The SISO and MISO math function block section provides more examples of invalid
input conditions. Please see that section for other examples. To other cases like 1/u where
u = 0, you must apply similar restrictions to the range of u before it gets applied to the
relation 1/u (i.e. range of u should be u 0.
When comparing invalid input conditions against other programs like Matlab Simulink,
please consider that the data type of ETAP UDM blocks is scalar for the majority of the
blocks. Other programs may consider data types (e.g. complex, etc.). In the future, the
range and data types of the ETAP UDM blocks will be expanded to handle other data
types to limit the number of invalid input data conditions.

User-Defined Dynamic Models DPET
25.8.7 Running DPET on Exciter/AVR models

This section presents general considerations and presents an example of how to perform DPET
on an exciter/AVR control element. In this case, the example used is a form of an IEEE exciter
ST4B AVR/EXC model. The UDM model is displayed below:
The UDM model above is a representation of the IEEE ST4B exciter model from the ETAP help
file as displayed below. The parameters KG, KIM have been set as zero in this case.

IEEE ST4B from ETAP help file
The following variables have been identified as potential parameters which can be varied for this
model.


Based on the guidelines presented in section 25.2.3 (using the “Fixed” option in the parameters
section of the DPET study case), the following parameters were selected as candidates for the
DPET simulation (i.e. were not fixed):
Parameter Initial Min Max

Kc 0.08 0.02 10
Kp 5.18 0.3 30
Xl -0.001 -1 -0.001
Kir 20 0.1 40
KPM 1 0.01 10
Kpr 20 0.386 38.6
Ta 0.01 0.004 0.1
The disturbance being simulated is the addition of a 4 MW load to the generator. The recorded
field measurements are displayed below. The first plot shows the recorded terminal voltage of
the generator during a 420 second span.
Portion used in the DPET

Simulation
The next plot shows the recorded exciter field voltage for the same time span (420 seconds):

Portion used in the DPET

Simulation
The entire 420 seconds were not used for the DPET simulation. Only the time period between
120 and 125.5 seconds was used for the DPET simulation as indicated by the dotted area in the
images above. The plots below show only the portion of the data used for each of the required
IEEE ST4B inputs:
Terminal Voltage (Vt) in p.u.:

Next is the Exciter Field Voltage (Efd) showing one of the first calculated EFDs (red) along with
the input (blue) in p.u:
Below is the Complex Terminal Voltage (CVt) in p.u. (showing only the magnitude):

The IEEE ST4B model also needs the Complex Terminal Current (CIt) in p.u. (showing only the
magnitude component):
The Exciter Field Current (Ifd) in p.u. is also required:

Dynamic Variable Reference

This model also used a dynamically calculated voltage reference signal. This additional
parameter is used to adjust the driving error point between the terminal voltage and the internal
exciter reference voltage. This adjustment is initially zero and can be added when the driving
signal difference causes the calculated exciter voltage to deviate upwards or downwards. The
image below shows one possible implementation of the variable reference parameter.
The variable reference parameter is only added after the simulation has started. The study case
will include the “VarRef1” parameter with a range which can be typically specified as ± 0.05 or
less. This value should not be set to a large value or have a large range since it would only work
against the simulation and may cause the final solution to take a much longer time to be reached.

Switch6 above is being used as the signal routing element to allow the “VarRef1” parameter to
affect the simulation. Setting the threshold value to zero or a small value like 0.001 will add the
variable reference parameter from the beginning of the simulation.
Note: In this example, the value of the “VarRef1” was set to ± 0.005 with an initial value of
0.000.
Moving Average Noise Filter

A moving average filter can be added to remove some of the field measurement noise. The noise
can come from higher order harmonics, from rectifier field action, from measurement device
analog to digital conversion, etc. The noise does not need to be part of the estimation process. In
order to filter out some of the noise, a moving average filter can be added to “smooth” out some
of the noise from the field measurements.
The filter can be added by placing a constant block (does not need to be connected to anything)
with the following parameter name inside; “NoOfSmoothingPoints”. Please note that the image
below does not show the final “s” in the parameter name. The constant block does not have any
naming requirements, but in this example has been called “MovingAverageFilter” to be easily
identifiable in the DPET study case.
This parameter should be fixed inside the DPET study case. The following images show the
terminal voltage magnitude and Efd plots in per-unit with the NoOfSmoothingPoints parameter
set to 1(left figure) and set to 5 (right figure).

As can be seen (especially in the Efd plot), the smoothing filter has removed some noise but it
still retains the major effect of the transient peaks.
In some cases, the smoothing number can be set much higher than 5. It can be set as high as 100
or 120. This should only be done for signals where the time step is very small (i.e. fraction of a
millisecond) and also where the smoothing of the signal does not cause the removal of any
needed transients.
In this version of ETAP, only a moving average filter has been added. However, other types of
noise filtering techniques are available and can be used to further prepare the measured signals
prior to adding them to the DPET study case. If the data is filtered by external tools, then the
NoOfSmoothingPoints filter should be removed or always set to 1, so that no further average
smoothing is performed.
Note: In this example, the value of the “NoOfSmoothingPoints” smoothing average filter was set
to 5.
Running the DPET Simulation with the following settings in the Simulation Parameters page:

The time step was set to 0.004 to speed up the simulation since the value of the smallest time
constant was expected to be 0.008 seconds. The total number of equivalent estimation steps was
set to 300. The average deviation and simulation time step were set to small and high enough,
respectively, to allow the simulation to converge and stop only after all iterations are completed.
The following image shows calculated vs. measured exciter field voltage for the first iteration of
the DPET process.
The following image shows calculated vs. measured exciter field voltage for the 200th iteration
of the DPET process.

Please note that the estimation results can be considered acceptable since the calculated
transients (red color) appear to be more severe than the measured results. If the estimated results
are considered to be acceptable at any time, then the simulation can be stopped to obtain the
current estimated parameters. In fact, the results of the 200th iteration are presented as well in the
summary section of this example.
The following image shows calculated vs. measured exciter field voltage for the 300th iteration
of the DPET process.

Please note that the estimation process in this case can take as long as 30 to 40 minutes if not
more, depending on the computer speed and memory available.
Summary
As previously discussed, the IEEE ST4B model has many more parameters which were fixed
because of different reasons. The DPET process described in this example utilized a disturbance
which covered only less than 5% of the range or the exciter field voltage range. Several
additional tools or components needed to be added to the transfer function of the IEEE ST4B
model in order for the DPET estimation to be successful. The considerations included, the time
span needed for the tuning, the variable reference and noise removing filtering.
The DPET process can take several iterations. The overall process described in this example was
created over a three-hour period. Tuning an exciter model to this level of accuracy can take as
much as 30 to 40 hours (if not more for an expert user) since the transient stability simulation
would have to be used and the results to be exported and manually compared at each iteration.
The following table shows the initial and the final DPET estimated parameters. All the estimated
parameters are not too far away from actual settings which can be set for this controller.
Parameter Initial Min Max After After

200th 300th
Iteration Iteration
Kc 0.08 0.02 10 1.345 1.159
Kp 5.18 0.3 30 5.899 4.837
Xl -0.001 -1 -0.001 -0.7427 -0.198
Kir 20 0.1 40 17.54 18.622
KPM 1 0.01 10 0.4393 0.5094
Kpr 20 0.386 38.6 17.617 20.174
Ta 0.01 0.004 0.1 0.0178 0.008
To refine the estimation it may be necessary to go beyond 400 iterations or more. However,
because the DPET optimization process is stochastic, no two estimation processes may yield
exactly the same solution. As can be seen in the images of the 200th and 300th iteration,
sometimes the results will yield.

25.8.8 Running DPET for Governor or General Load Model

This section presents an example for running DPET for an engine/governor model. The situation
presented in this section is for a stand-alone generator running in isochronous mode with a
starting motor load. The estimation is accomplished by means of two different approaches as
follows:
1) The rotational speed (w or freq) and the mechanical power or torque (Pm or Tm) are
measured.
2) The rotational speed (w or freq) and the electrical load (Pe) are measured.
This example will illustrate how to take advantage of the general load model DPET capability to
estimate the mechanical model speed response rather than the mechanical power.
This example uses the following model as a variation of a Woodward 2301 speed controller and
a simplified diesel engine model. The model transfer function is displayed below. The contents
of the shaded blocks are not included in this example, but can be considered to be similar to
standard models in it.
The transfer function of the UDM model above can be considered to be similar to the ETAP help
file transfer function displayed below:

The transfer function in the UDM model is displayed below. Please note that some blocks of this
transfer function have been omitted since the contents of the transfer function cannot be
published. Please note that in the image below, the inputs are the electrical power (Pe) and the
speed (W) and the output is the mechanical power (Pm).
Case 1: DPET using the Speed and Mechanical Power as Measured Inputs
In this case, the inputs to the DPET simulation are the measured speed and the mechanical power
output from the engine. The input plots used are displayed below:
Engine Mechanical Power Output in p.u (blue = measured, red = calculated for 1st iteration):

Generator Speed (p.u):
Generator Electrical Power Output (p.u):
The first step is to determine which parameters are need to be considered in the simulation. The
list below displays the parameters, which were considered to be included in the DPET study
case.


AlphaC 2.5 0.95 20
Rho 0.1 0.008 0.2
Tpilot 0.09 0.005 0.1
Tpstage 0.06 0.005 0.1
Beta1 1 0.001 2
The DPET simulation was performed using the governor model. There were no additional
control elements or additional control elements added to the model. The following image shows
the response after 34 iterations. The image on the left below is the initial iteration. The image on
the right is the estimation process after 34 iterations. As can be seen, the process has almost
matched the response.
Result Summary
The table below shows the summary of the estimation process results. The results are presented
after the 34th iteration and after a longer simulation of almost 200 iterations.
After After
Parameter Initial Min Max 34th 190th
Iteration Iteration
AlphaC 2.5 0.95 20 1.937 2.796
Rho 0.1 0.008 0.2 0.0921 0.062
Tpilot 0.09 0.005 0.1 0.085 0.0707
Tpstage 0.06 0.005 0.1 0.0672 0.0877
Beta1 1 0.001 2 1.111 1.452

Case 2: DPET using the Speed and Electrical Power Output of the Generator as Inputs
In this case, the inputs to the DPET simulation are the measured speed and the electrical power
output from the generator. The input plots used are displayed below:
Generator Electrical Power Output in p.u:
Generator Speed Measurement in p.u (blue color plot):
Please note that in the plots above, the initial measured speed is not in perfect steady-state
condition and thus, there will be a difference which cannot be reduced. The calculated results

from DPET will be in steady-state conditions prior to the disturbance being introduced at 2.2
seconds.
To achieve the parameter estimation of case 2, the following items need to be implemented:
1) The Gen Load Model in UDM must be used for the DPET simulation. This means that
the Governor model must be inserted into a Gen Load model.
2) The mechanical model must be included in the model. This way the speed will be
calculated rather than the mechanical power.
3) In the Gen Load Model, the input Vt must be used for Pe and the output Pe can be used
for the calculated speed.
The previous three workaround requirements will be removed from the DPET program in future
versions. However, for now these conditions must be met to estimate the speed response of a
governor/engine model in response to a load change. The image below shows a Gen Load Model
which meets all of the conditions described above (including the mechanical mass model).
Furthermore, the model contains a moving average filter and an initialization time block. These
tools are described in detail in the following sections:

Mechanical Mass Model

The following mechanical mass model can be used to close the feedback loop in the Gen Load
Model. The image below shows a basic implementation of the mechanical mass model with the
intent of calculating the speed of the generator/turbine or generator/engine. The inertia value
used here must represent the sum of the inertia values of all components (generator rotor, engine
shaft and coupling).
P Mechanical
(p.u)
P Electrical (p.u)
To speed Difference Summing point

(W)
The input P mechanical from the governor/engine or governor/turbine model must be placed into
a summing point (see “Sum7” above). The output of the integral of the difference divided by an
inertia constant (called “H” here for simplification purposes) represents the speed of the
mechanical system. The image below shows the overall connection. As can be seen, the output of
the mechanical mass model (speed) is connected to speed controller negative feedback input
(W).
Note: This mechanical system representation ignores any damping effect from the generator.
This model should be used mostly for stand-alone generator systems with constant frequency
controller mode (isochronous).
Mechanical Mass Model Correlation with ETAP Transient Stability

The value of the H constant used in the simplified mechanical model described in the previous
section can be correlated to the Inertia value used in the ETAP model. To go from ETAP
transient stability to the UDM simplified model, take the inertia value from the generator in
ETAP (combined total), then multiply by [2 * (Gen MVA rating / Gen MW rating)].
Using the inertia value from the image above (1.705), we can calculate the equivalent value for
the UDM model to be 4.81. The opposite conversion can be used to go from UDM to TS.

Forward Initialization Time for Gen Load and WTG UDM models in DPET
When using Gen Load and/or WTG UDM models in DPET, a constant block should be added to
indicate how many seconds to use for the forward initialization time for the model. The
parameter name is, “IniTimeForGenLoadWTG” (the name of the parameter is not case
sensitive). The value should be initially set to at least 50 to 100 secs.
Note: In this example, the value was set to 1000 seconds. The initialization time step is the same
as that used in the simulation (from Simulation Parameter) page.
Smoothing Filter (Moving Average Filter)

A smoothing filter was used in this example. The value was set to 80 in the DPET study case.
Please refer to 25.8.5 for more details on the moving average filter use. The final estimated
parameters were obtained using this value. As can be observed in the final results, the speed plot
has been reduced in thickness and a smoother (less noisy) curve is used in the comparison.
The input speed measurement would look as displayed below with a moving average filter value
of 1:
The next requirements which must be met are to use the Pe output port for the calculated speed
and the Vt input port for the electrical power. This requirement was met and can be observed in

the transfer function image above. Pe is assigned to the speed output and Vt as the input
electrical power.
DPET Study Case Setup

The study case Data Loading Page is displayed below to show how the field measurements were
loaded into the DPET study case based on this requirement.

AlphaC 2 0.95 20
Rho 0.1 0.001 2
Tpilot 0.05 0.005 0.1
Tpstage 0.09 0.005 0.1
Beta1 1.33 0.001 2
InertiaC 4.54 0.001 10
All other parameters or variables were held constant (fixed), since they were not considerable as
tunable parameters. Details or description of the actual purpose of each parameter are omitted
and are considered to be different from model to model depending on the type of controller.
Overall, the list above contains some time constants and some gains. The inertia constant H was
also included as part of the estimation. However, in most cases the value of H can be omitted
since it should be a known parameter.
The Simulation Parameter page contained the following settings:

Result Summary
The plot below shows the final DPET result for the change in speed. The overall difference in the
results is less than 0.1% as displayed in the deviation plot.
The following table shows the results of the DPET process after 100 iterations.
After
Parameter Initial Min Max 100th
Iteration
AlphaC 2 0.95 20 2.807
Rho 0.1 0.001 2 0.036
Tpilot 0.05 0.005 0.1 0.0511
Tpstage 0.09 0.005 0.1 0.0854
Beta1 1.33 0.001 2 1.57
InertiaC 4.54 0.001 10 5.994
As can be observed, the estimation yields are close to the initial values in most cases. The table
below shows the results of the estimation using the governor model and using the Gen Load
Approach. It can be concluded that the Gen Load Approach is probably the most practical due to
the higher availability of test data for the speed and electrical power (i.e. measuring the
mechanical power is less common).
Parameter Case 1 Case 2

AlphaC 2.796 2.807
Rho 0.062 0.036
Tpilot 0.0707 0.0511
Tpstage 0.0877 0.0854
Beta1 1.452 1.57

Memory Usage Considerations for DPET

The DPET program may use a considerable amount of memory because of the plot comparison
process for many iterations. To reduce the memory usage it is important to reduce the amount of
measured data to be considered in the simulation to only what is absolutely needed to tune the
parameters. In section 25.8.5, an example of field-measured data usage was presented. The
exciter field-measured data covered a time span of 420 seconds. However, in reality only 5
seconds were needed to estimate the parameters.
The following general guidelines should be considered when selecting the time span and the
sampling rate for the measured input signals:
1) A 20 to 30 second time span for field-measured data should be adequate to cover most
electromechanical transient phenomena in the DPET simulation.
2) Extended periods of time of steady-state “noisy” measured data should be avoided. Most
of the time, their consideration does not work towards a better-estimated result.
3) The sampling rate can be reduced to collect less points from the field measurement. This
can reduce the memory consumption. However, the sampling rate should not be reduced
below the point where essential transients are lost and not considered in the simulation.
In general, it is recommended to use a computer with at least 12 GB of available RAM for

projects where the field-measured results will exceed 200 seconds and the model has multiple
input and output ports.

5-ETAP - User Defined Dynamic Models

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

5-ETAP - User Defined Dynamic Models

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 25

User-Defined Dynamic Models (UDM)

1) Synchronous Motors Exciter / AVR models

ETAP 25-1 ETAP 18.0 User Guide

UDM Graphic Logic Editor

25.1.1 Accessing the UDM Interface

If you open the UDM Editor from the Individual Editors:

<Element ID>_<Type>_<Model Name>.

ETAP 25-2 ETAP 18.0 User Guide

If you open the UDM Editor from the System Toolbar:

ETAP 25-3 ETAP 18.0 User Guide

Saving UDM Model Files

Governor Models \UDM\Gov

ETAP 25-4 ETAP 18.0 User Guide

<Element ID>_<Type>_<Model Name>.UDM

The types available are:

Other Examples would be:

This naming convention achieves the following:

ETAP 25-5 ETAP 18.0 User Guide

*.DOC, *.BIN, *.LK, *.SC

<Element ID>_<Type>_<Model Name>.bin

<Element ID>_<Type>_<Model Name>_data.doc

<Element ID>_<Type>_<Model Name>.lk

<Element ID>_<Type>_<Model Name>.sc

ETAP 25-6 ETAP 18.0 User Guide

25.2.1 UDM Editor Presentation

File Menu Items:

ETAP 25-7 ETAP 18.0 User Guide

Open from Library

<Element ID>_<Type>_<Model Name>.UDM

Import (from *.mdl Simulink files)

ETAP 25-8 ETAP 18.0 User Guide

ETAP 25-9 ETAP 18.0 User Guide

Output Pm Turbine Output Mechanical Power

Output Efd Exciter Output Voltage

ETAP 25-10 ETAP 18.0 User Guide

Output Vs PSS Output Signal

ETAP 25-11 ETAP 18.0 User Guide

Edit Menu Items:

Delete Study Case

ETAP 25-12 ETAP 18.0 User Guide

ETAP 25-13 ETAP 18.0 User Guide

ETAP 25-14 ETAP 18.0 User Guide

View Menu Items:

ETAP 25-15 ETAP 18.0 User Guide

ETAP 25-16 ETAP 18.0 User Guide

ETAP 25-17 ETAP 18.0 User Guide

Pan Zoom Window

ETAP 25-18 ETAP 18.0 User Guide

ETAP 25-19 ETAP 18.0 User Guide

Layers (will be available in future)

Element changes are applicable to all active layers. If an

The image below illustrates the end result of associating

ETAP 25-20 ETAP 18.0 User Guide

ETAP 25-21 ETAP 18.0 User Guide

ETAP 25-22 ETAP 18.0 User Guide

ETAP 25-23 ETAP 18.0 User Guide

Please refer to section 25.4.2 for more details.

Actions Menu Items

ETAP 25-24 ETAP 18.0 User Guide

After Align Middle

ETAP 25-25 ETAP 18.0 User Guide

ETAP 25-26 ETAP 18.0 User Guide

.DOC, .BIN, .LK, .SC