Introduction to DSL (DIgSILENT Simulation Language) and

Modelica

This guide is an introduction to dynamic modelling in PowerFactory. It covers the philosophy, creation, initiali-
sation and testing of dynamic models for use in time-domain power systems simulations.

Prerequisites

A basic knowledge of electrical engineering, linear systems and control theory and PowerFactory handling is
assumed. An understanding of numerical simulation (continuous-time and discrete-time), particularly the con-
cepts of state-space representations and solutions to differential-algebraic equations (DAE) is also desirable,
but not essential. The following references are useful for the interested reader:

• Modern Control Engineering by K. Ogata

• Power System Stability and Control by P. Kundur - Section 13 of this book has a good treatment on
the formulation of DAE equations for power systems applications and how to solve them with numerical
integration methods

1 Dynamic Modelling Concepts in PowerFactory

The implementation of user-defined dynamic models is realised using one of the following two specific objects:
• DSL: DSL Model (ElmDsl) and DSL Model Type (BlkDef )

• Modelica: Modelica Model (ElmMdl) and Modelica Model Type (TypMdl)

1.1 Terminology

In this section, several dynamic modelling terms that are specific to PowerFactory are defined. If this is your
first exposure to dynamic modelling in PowerFactory, then don’t worry about trying to understand all of these
terms right now (as they are quite abstract and can take some time to get used to!). It is sufficient to simply be
aware that they exist and know that the definitions are here for reference.

1.1.1 Terminology Common to DSL and Modelica

• Network Element: is a built-in model representing a standard piece of power system equipment, e.g.
generators, motors, transformers, converters, etc.
INTRODUCTION TO DSL

• Composite Model Frame: is a diagram establishing the connections between dynamic models and
network elements. Composite Model Frames are type objects that belong in the user defined models
library.
• Slot: is a block in the composite frame that represents an object location in the interconnection diagram,
e.g. network elements, measurement devices, DSL and Modelica models. The user should define what
type of object the slot represents.
• Composite Model: is an instance of a composite model frame. It represents a dynamic system (e.g.
generator with prime mover control and voltage regulator). The composite model establishes the links
between actual network elements, measurement devices, DSL and Modelica models.
• Measurement Device: is a PowerFactory built-in element used to obtain from a bus and/or branch
different values like bus voltages, frequency and angle, branch currents and power flows which can be
used in a Composite Model to be connected to a DSL or a Modelica Model.

1.1.2 Terminology DSL

• DSL Model Type: is the structure of a dynamic model containing its mathematical representation in the
form of a set of equations and/or a set of graphical macros. DSL Model Types are objects that belong in
the user defined models library.

• DSL Model: is an instance that links a DSL Model Type to an actual piece of dynamic equipment with
specific parameters. DSL models are grid elements and so must be located in the grid.
• Block Definition: is the name of the PowerFactory object (BlkDef ) used to build both composite model
frames and DSL model types. Block definitions can be built from both equations and graphical block
diagrams.
• Primitive Block Definition: is a DSL model type containing only a set of equations with no graphical
representation.
• Block Diagram: is a step-by-step diagram that represents the relation between different functions or
sub-processes of a dynamic system. A graphically defined DSL model type is a block diagram.

• Macro: is a block definition intended to be part of a composite block definition and contains the equation
for a specific function of a dynamic model. Macros can be used in different composite block definitions.
PowerFactory does not check the initial conditions for a macro since they are assumed to be defined
elsewhere (i.e. in a higher-level block definition). A macro can either be text only or can also be defined
graphically.

1.1.3 Terminology Modelica

Please refer to the Modelica Language specification for a complete description of the terms and definitions
used within Modelica. Within this section, only the most relevant and several PowerFactory -specific terms are
mentioned.

• Modelica Model Type: is the structure of a model1 containing its mathematical representation in the
form of a set of sequential statements and/or a set of graphical blocks. Modelica Model Types are objects
that belong in the user defined models or dynamic models inside the project library.
• Modelica Model: is a network instance that links a model definition to an actual piece of dynamic
equipment with specific parameters. Modelica models are grid elements and so must be located in
the grid.

1 PowerFactory 2023 supports only discrete-time Modelica models

Rev.2 2
INTRODUCTION TO DSL

• Block: (Modelica-specific) representing a specialised Modelica class: same as the model class, with
the restriction that each connector component of a Block must have prefixes input and/or output for all
connector variables.
• Component: (Modelica-specific) A component is an instance of a Modelica class object.
• Type: A Type is a Modelica Model Type for which one or several Type Instances may exist. Use Types to
create a library of building blocks for block diagrams.

• Type Instance: The instance of a Type. Use Type Instances to add Types into Modelica block diagrams.
Type Instances are automatically created inside a model whenever users are adding library blocks into a
block diagram.
• Top-level diagram: (PowerFactory -specific) Models defined using hierarchically structured block dia-
grams may contain several diagrams, each linked with specific diagrams via child-parent relationships.
A top-level diagram represents in this context the highest level block diagram, which contains all sub-
ordinated diagrams of an hierarchical block diagram design.
• Top-level model: (PowerFactory -specific) The associated Modelica Model Type (TypMdl) whose dia-
gram is a top-level diagram is referred to as a Top-level Modelica Model Type or as a Top-level model.
Inputs and outputs of a Top-level model are meant to interconnect it with other PowerFactory elements
via High-level Control System Representations.

1.2 General Modelling Philosophy

The underlying philosophy for dynamic modelling in PowerFactory is as follows:

• Flexibility: allows any arbitrary dynamic model to be created.

• Inheritance and Reuse: object-oriented approach where multiple grid objects can use the same library
object (i.e. composite model frame or DSL model type or Modelica model type) with local parameter
settings.

• Built-in Error Detection: detection of structural and syntax errors at model implementation time.

1.2.1 Flexibility

The dynamic modelling approach in PowerFactory is specifically designed to be flexible so that any model,
from simple time delays to complex controller structures, can be constructed using the same set of tools. A
very powerful tool for building a dynamic model is the PowerFactory graphical interface. The basic building
blocks for the graphical interface are as follows for DSL and Modelica model types,
• For a DSL model type are macro definitions containing mathematical functions written in DIgSILENT
Simulation Language (DSL). Higher-level representations, such as graphical block diagrams and nested
block structures, are automatically converted to a set of DSL equations, which are first parsed and then
interpreted during the simulation2 .
• For a Modelica model type, the type definition contains sequential mathematical statements, i.e. algo-
rithms written in the Modelica language. The graphical type diagrams are automatically converted into a
set of Modelica statements which are first parsed and then compiled for simulation. The compiled model
is evaluated during the simulation.

2 Alternatively, the DSL model type can be manually or automatically compiled prior to simulation

Rev.2 3
INTRODUCTION TO DSL

1.2.2 Inheritance and Reuse

PowerFactory uses an object-oriented approach that encourages reuse by strictly enforcing the distinction
between library (type) and grid (element) objects. For example, when creating a transformer, the user must
create both a transformer type (e.g. 2MVA, 11/0.4kV, Z=6%) and the transformer element itself. Multiple
transformer elements can use the same type. Changing the type parameters will affect all transformers
referencing that type.

The same philosophy is reflected in PowerFactory ’s approach to dynamic modelling. There are type objects
in the library (i.e. composite model frames and DSL or Modelica model types) that are referenced by element
objects in the grid (i.e. composite models and DSL or Modelica models). These grid elements inherit the
properties of the type objects (e.g. a DSL or Modelica model inherits the block structure of its associated DSL
or Modelica model type).

Consider Figures 1.1 and 1.2 to provide a more concrete example. The composite model frame represents
the connections of a generator to a controller. Both diagrams depict two generators, each connected to its
specific controller. The controllers in Figure 1.1 are DSL models and in Figure 1.2 are Modelica models. Each
DSL or Modelica model represents one instance of the same DSL or Modelica model type. Suppose that both
generators use the same type of vendor A controller. Instead of defining the block diagram for each controller
individually, the PowerFactory philosophy is to define the vendor A controller once as a type (DSL or Modelica
model type) and then create two different instances (DSL or Modelica models) for each of the generators (each
with their own local parameter settings). This configuration is reflected in both Figures 1.1 and 1.2.

DSL Model Controller

Network Data
Objects
Composite Model
GEN
Library
DSL Model Data Objects
Controller GEN CONTROLLER
GEN DSL Model
Type

Composite Model
GEN

Composite Model
Controller Frame

Figure 1.1: Single DSL model type referenced by two DSL models

Rev.2 4
INTRODUCTION TO DSL

Modelica Controller
Network Data
Model
Objects
Composite Model
GEN
Library
Modelica
Model Data Objects
Controller
Modelica
GEN GEN CONTROLLER
Model Type

Composite Model
GEN

Controller

Composite Model
Frame

Figure 1.2: Single Modelica model type referenced by two Modelica models

Now suppose that one of the vendor A controllers is replaced with a vendor B controller. We can create a new
DSL or Modelica model based on the vendor B block diagram (i.e., another DSL or Modelica model type) and
replace the vendor A controller in the composite model (while using the same composite model and composite
model frame).

1.3 Built-in Error Detection

In order to achieve great flexibility in modelling, there is no strictly defined workflow for creating dynamic
models. There are few restrictions on how a user can construct models, and with this freedom, models with
very complicated structures can be created. A user could then create model structures that are not sound, but
rather than impose restrictions, the philosophy of PowerFactory is to provide tools for error detection instead.

2 Examples

In this section, we present two examples. The first example shows a synchronous machine control system
implemented using DSL and the second one is an AC/DC three-level PWM converter where the converter
control is implemented using Modelica. The examples provide a high-level overview of the workflow for building
your own custom models. Detailed step-by-step instructions can be found in the next tutorial sections (see
Building a User Defined DSL Model and Building a User Defined Modelica Model))

2.1 DSL: Generator Control System

The built-in synchronous machine model (ElmSym) is provided by default without any controls. When the
synchronous machine is used “as-is” in a dynamic simulation (i.e. without controls), it will maintain a constant
turbine power “pt” and excitation voltage “ve” throughout the duration of the simulation. As a result, distur-
bances such as faults, load steps, etc may cause unstable or unrealistic system response, since the action of
control systems like speed governors and voltage regulators are omitted.

Rev.2 5
INTRODUCTION TO DSL

It is therefore necessary to specifically define the generator controls and their dynamic response to system
disturbances. The level of detail required in the controller models will of course depend on the type of studies
to be conducted, performance requirements, degree of influence the unit has on the network, etc.

In this example, we will illustrate the dynamic modelling concepts discussed so far by defining the structure of
a simplified generator control system, and how it can be implemented in PowerFactory.

Consider the hydroelectric generation system shown in Figure 2.1.

Figure 2.1: Hydroelectric dam, turbine and generator (Image courtesy of Wikipedia)

In this system, the amount of water flowing into the penstock is controlled by a control gate at the intake.
The water in the penstock flows through the turbine and rotates it, before being discharged through the draft
tube. The turbine is coupled to a synchronous generator, which is then connected to the network. The gate
position is controlled by a governor system, which tries to regulate the speed of the machine by acting on the
mechanical power intake of the generator. A voltage controller is also connected to the generator, controlling
the terminal voltage of the machine by regulating rotor excitation.

We can see from this stylised system that there are control signals (i.e. gate position, excitation voltage),
control objectives and feedback (i.e. speed, terminal voltage). This can be summarised by a block diagram as
shown Figure 2.2.

Rev.2 6
INTRODUCTION TO DSL

Figure 2.2: Connection diagram for hydroelectric generation system

This block diagram showing how the synchronous generator, governor, turbine and voltage controller are
connected through the input / output signals between them, must be implemented as the composite model
frame for the dynamic system. The blocks that represent the generator, governor, etc are called slots and are
placeholders for the models that describe their dynamic behaviour.

At this stage, we have just seen an overview for how the hydro generation control system is structured (i.e. a
frame). We still have to define the individual dynamic models for the governor, turbine and voltage controller.
Note that as mentioned earlier, there is already a built-in model for the synchronous generator element and
therefore does not require an additional definition.

Let’s first define a voltage controller as shown in Figure 2.3.

Rev.2 7
INTRODUCTION TO DSL

Figure 2.3: Block diagram for a simple voltage controller

This block diagram must be implemented as the DSL model type for the voltage controller. We can perform
a similar exercise and create DSL model types for the governor and turbine (not shown here). Once we have
finished creating these model types, we will have then defined the dynamic model for the hydro generation
control system, i.e. the individual dynamic model for the governor, turbine and voltage controller, the built-in
model for the generator and how they are all connected together is defined in the composite model frame.

However at this stage, we only have general structures (which are located in the library types). We still need to
create actual instances of the equipment inside the grid. Built-in grid elements such as synchronous generators
can be created by the drawing tools in the PowerFactory Graphical User Interface (GUI). Composite models
and DSL models need to be created from within the Data Manager (inside a grid folder) using the New Object
( ) icon.

We can first create a composite model and link it to the composite model frame we defined earlier (see
Figure 2.2). The slots for the generator, governor, turbine and voltage controller now need to be filled. For the
generator slot, we can select the relevant generator element in the grid. For the other slots, we will have to
create DSL models and link them to the relevant model definition. At the end, the complete composite model
is shown in Figure 2.4. The same composite model as seen from inside the data manager is shown in Figure
2.5.

Rev.2 8
INTRODUCTION TO DSL

Figure 2.4: Complete composite model for hydro generator system

Rev.2 9
INTRODUCTION TO DSL

Figure 2.5: Composite model of hydro generator system in the data manager

2.2 Modelica: AC/DC Three-Level PWM Converter

PowerFactory supports various commonly used power electronics (PE) based devices within several built-
in simulation models. This section shows an AC-DC three-level PWM Converter, where the controllers are
implemented using Modelica. The converter is voltage-sourced based with IGBT valves, which are controlled
by a PWM modulator. The network diagram is shown in Figure 2.6. The PE equipment is developed within
a built-in PWM converter element (ElmVsc), then it is connected to the external power system via predefined
connection ports belonging to a Submodel. The corresponding topology of the submodel is shown in Figure
2.7. The AC and DC connection ports are used to link the internal components with the elements to which the
built-in element terminals are connected in the power system.

Figure 2.6: Single line diagram

Rev.2 10
INTRODUCTION TO DSL

Figure 2.7: Submodel

The control system is designed such that each individual IGBT is controlled via its gate signal. Since the
respective gate signal of one IGBT element is a scalar, the total number of gate signals is 12. The gate
signals are generated using a pulse generator block. The pulse generator receives reference input signals
from the controller. The controller requires filtered inputs from local measurement voltages and currents and
the frequency from the PLL. Figure 2.8 shows how the gate signals of converter IGBT valves, pulse generator,
filters, controllers, and measurement elements are connected through the input/output signals between them.
This must be implemented as the composite model frame for the dynamic system. The placeholders for the
controller, filters, etc., are called slots.

Rev.2 11
INTRODUCTION TO DSL

Figure 2.8: Composite model frame of the Three-Level converter controller

Individual dynamic models for the controller, pulse generator and filters are defined using Modelica in the
project library. The implementation of the controller as a structured graphical Modelica model type is shown in
Figure 2.9. The top-level model of the controller is the upper left model in Figure 2.9.

Figure 2.9: Controller block diagram using Modelica

Instances of each piece of equipment (controller, pulse generator, filters) are created inside the grid. The
drawing tools in the PowerFactory Graphical User Interface (GUI) are used to create built-in grid elements
such as AC voltage sources. Composite models and Modelica models need to be created from within the Data
Manager (inside a grid folder) using the New Object ( ) icon.

Rev.2 12
INTRODUCTION TO DSL

We can first create a composite model and link it to the composite model frame we defined earlier (see Figure
2.8). All the slots now need to be filled. For the IGBT valves, first, create an object Vector of Objects (IntVecobj)
inside the composite models using the New Object ( ) icon. Then append 12 rows and connect the built-in
valve (ElmValves) elements. For voltage, current and frequency measurements, first create network elements
(StaImea, StaVmea, StaPll) and then a vector of objects. For the respective slot to put the controller, pulse
generator, and filter, we will have to create Modelica models and link them to the relevant model definition.
The complete composite model is shown in Figure 2.10.

Figure 2.10: Composite model of AC/DC Three-Level PWM Converter

3 Creating Dynamic Models

3.1 General Procedure

The general procedure for creating a dynamic model in PowerFactory is as follows and will be practised in the
next sections of this Tutorial (see Building a User Defined DSL Model and Building a User Defined Modelica
Model):

1. Consider the structure of the system to be modelled and how it can be broken down into individual blocks
that can be modelled separately.
2. Based on the modeling requirement, decide whether we implement a DSL or Modelica model. Create
each of the DSL or Modelica model types and set appropriate initial conditions.
3. Construct a composite model frame showing how the slots are interconnected.
4. Create a composite model and fill the slots with the relevant grid elements, e.g., DSL or Modelica models,
built-in models, measurement devices, etc.

5. Test the complete model.

Rev.2 13
INTRODUCTION TO DSL

3.2 Library Objects

Both composite model frames and DSL model types are created in PowerFactory using the block definition
object (BlkDef). The difference is that composite model frames can only contain slots and connectors and do
not perform calculations, whereas DSL model types can contain mathematical functions in the form of equa-
tions, graphical macros, summation points, multipliers, etc. Modelica model types can be purely algorithmic or
graphical through connecting components.

3.2.1 Composite Model Frame

Composite model frames are diagrams containing slots and connectors, showing how network elements, DSL
and Modelica models are to be connected together. Composite model frames are purely graphical and contain
no equations. See for example Figures 2.2 and 2.8.

3.2.2 DSL Model Type

A DSL model type constitutes the mathematical representation of a dynamic model in the form of equations
and / or graphical macros. A DSL model type containing only equations is called a primitive block definition,
while a DSL model type with a graphical block diagram is referred to as a composite block definition. Both
primitive and composite block definitions can be reused inside other higher-level model definitions (PowerFac-
tory supports an arbitrary number of layers).

Figure 3.1: An example of a DSL model type for a hydraulic turbine

Rev.2 14
INTRODUCTION TO DSL

Some DSL syntax guidelines to keep in mind when creating model definitions:

• A variable cannot belong to more than one type (input, output, parameter, state variable).
• DSL syntax is based on assignments of variables to mathematical expressions.
• A state variable cannot be of more than one type (output, parameter, input or state variable) at the same
time.

• Derivatives may only appear on the left-hand side of equations.

• Algebraic loops and recursion (e.g. for and while loops) are not supported in DSL.
• Conditional statements (of the if-then-else type) are to be implemented using the “select” function.
• Intrinsic, logic and conditional fucntions/operators are available.

• Maximal line length is 80 characters. Longer lines can be broken by “&” sign in the first column.
• All keywords, names, functions, variables, models, macros, etc. are case sensitive.
• Complex numbers and matrix operations are not supported.

• Blanks are removed when DSL code is processed. Exception: blanks in strings are kept.
• The sequence of lines is not relevant. Instruction execution order is sorted automatically.
• Comments can be done preceded with “!”.

3.2.3 Modelica Model Type

A Modelica model type constitutes the mathematical representation of a dynamic model in the form of a
sequence of statements or graphical. The type implemented using a sequence of statements is a textual model.
And the graphical model is implemented by connecting inputs, outputs, and instances of textual models. As an
example in Figure 2.9 all four types shown are graphical models, and the integrator, gain, sum, and limiter to
construct the PI controller (see lower left in Figure 2.9) are textual model. Some Modelica syntax guidelines to
keep in mind when creating model definitions:
• Code syntax of the type is based on the Modelica language specification.
• The name of the type and components must comply with the Modelica language specification require-
ments for naming, e.g., no white spaces.

• Duplicate component name is not allowed.

• Both textual and graphical implementations in the same Modelica model type are not allowed.
• Code sequence in the Initialisation and Simulation of a textual implementation is relevant.
• A top-level diagram of a hierarchically structured type may have several components connected. The
execution order of the connected components is sorted automatically.
• For array-type inputs and outputs, only one dimension i.e., vector, is supported.

Note: Modelica language specification supports both equations and algrothims for modeling. In PowerFactory
it is possible to implement only algorithmic models in the form of textual or graphical. With reference to
the specification, the functionality supported in PowerFactory is described in the user manual.

Rev.2 15
INTRODUCTION TO DSL

3.3 Grid Objects

3.3.1 Composite Model

A composite model is a grid object representing a dynamic system (e.g., a generator with prime mover and
voltage control). A composite model references a composite model frame and inherits its structure (i.e., the
interconnections between system components). The relevant system components, e.g., network elements,
DSL and Modelica models, measurement devices, etc., are assigned to the relevant slots in the composite
model.

Composite models are created from within the data manager, inside the active grid folder. Once a frame is
selected, the relevant system components (for example, see Figures 2.4 and 2.10) can be assigned to the
slots. It is best practice to store elements such as DSL and Modelica models and measurement devices inside
the composite model object (for example, see Figure 2.5).

Note: It is allowed to assign DSL and Modelica models in respective slots in the same composite model.

3.3.2 DSL Model

A DSL model is a grid object that represents an instance of a DSL model type. A DSL model inherits the
structure of the linked DSL model type and has its own local parameter settings.

DSL models are created from the data manager. Once a DSL model type has been selected, the parameters
of the DSL model can be entered (as an example, see Figure 3.2).

Figure 3.2: An example of a DSL model and its parameters

Rev.2 16
INTRODUCTION TO DSL

3.3.3 Modelica Model

A Modelica model is a grid object representing an instance of a model type. A Modelica model inherits the
linked model type’s structure and has its own local parameter settings.

The data manager is used to create Modelica models. Once a Modelica model type has been selected, the
scalar and array parameters of the Modelica model can be entered (as an example, see Figure 3.3). The array
parameters must be defined using references of IntMat objects. During simulation, the model is evaluated with
fixed sampling options and is set in the page Clocked Model.

Figure 3.3: An example of a Modelica model and its parameters page

4 Model Initialisation

In PowerFactory, all dynamic models are initialised according to a load flow calculation. In other words, prior
to the start of a time-domain simulation, the system is operating in a steady state condition and network
voltages, active and reactive power flows, loadings, etc. are defined by the load flow solution. This also means
that the operational configuration defined for the load flow calculation (e.g. generator active / reactive power
dispatch, settings for station controllers, etc.) is used as the steady-state starting point for the time-domain
simulation. It is recommended that the steady-state load flow is configured correctly before running a time-
domain simulation.

4.1 How DSL Models are Initialised in PowerFactory

The initialisation process is generally performed in the opposite direction from normal operation, i.e. from right-
to-left or output-to-input (although this is not always the case). This is because the outputs of the model are
usually known (e.g. from the steady-state load flow calculation) and the inputs are unknown and need to be
initialised. Model initialisation typically starts at the grid elements and then works backward through the other
blocks, initialising each block completely one at a time.

In most models, a number of variables (or signals) will need to be manually initialised. This is generally true
for variables or signals that cannot be determined directly from the load flow solution. Note that not all of the
variables and signals in a model need to be manually initialised. When a variable or signal is not known or

Rev.2 17
INTRODUCTION TO DSL

manually initialised, PowerFactory will try to use the model equations to compute its initial value. An error
will be thrown if the model equations have undefined variables or signals (e.g. an unknown input). Undefined
variables or signals need to be manually initialised, for example:

• All state variables

• All unknown input (and output) signals

Elaborating on the concept of known and unknown signals, known signals are those that are connected to
built-in models (e.g. grid elements such as synchronous machines, transformers, etc) or other DSL models
that have already been initialised.

For example, consider Figure 4.1 showing a frame of a governor and turbine connected to a synchronous
generator.

Figure 4.1: Frame showing a governor and turbine connected to a synchronous generator

The initialisation process starts at the synchronous generator element, a grid element with a built-in model.
The signals (pt and speed) are calculated automatically based on the steady-state load flow solution and are
known.

The turbine block is the next block initialised. The output signal pt is known from the generator element, but
the input signal g is unknown, and must be manually initialised. The input signal g should be initialised such
that the model equations yield pt at the output.

Lastly, the governor block is initialised. Since the output signal g has already been initialised in the turbine block
and the speed input is known from the generator element, no manual initialisation of the input / output signals
for this block are required. However, any internal state variables in the block need to be manually initialised.

Note that it may also be possible for the output signal g to be calculated using the model equations from the
speed input. If this is possible, then the calculated g should be the same as the g initialised in the turbine block.
If it’s not, then an error message will be shown (“Block not correctly initialised”).

4.2 How Modelica Models are Initialised in PowerFactory

4.2.1 General Procedure for Composite Model Initialisation

Using the example in the preceding section as a reference, we can articulate a general procedure for calculating
the initial conditions for a composite block:

1. Consider the composite model frame in which the composite block is located and how it will be connected
to other slots.
2. Determine which signals (and variables) are known and unknown.

Rev.2 18
INTRODUCTION TO DSL

This follows on from step one - once the signal relationships of the slot is known in the context of the
frame, then we can identify a) the signals that will be known from a load flow initialisation, and b) the
signals that we need to initialise manually.
3. Construct a steady-state representation of the block diagram.
Set all derivatives to zero and redraw the block to show its steady-state configuration.
4. Determine expressions for the unknown signals (and variables) from the known quantities.

This can be applied during the practical exercise of this tutorial Building an User Defined Model.

5 Additional Documentation

The information provided in this document is just a high-level introduction to DSL. Additional information is
available, the following documents can be accessed either directly from PowerFactory or from the DIgSILENT
download area ([Link]

• Advanced Tutorial: step by step description to define an user defined model. Help → Tutorial. . .
• User Manual: a dedicated chapter presents all information regarding models for dynamic simulations,
a complete list with all DSL functions including examples is also available in the User Manual. Help →
User Manual
• Technical References: description of the models implemented in PowerFactory for the different power
systems components. Help → Technical References
• Knowledge base: a database of information, based on an FAQ format, available for any users (whether
registered or not) in [Link]

Apart from the mentioned documentation, DIgSILENT provides Direct Technical Support, where PowerFac-
tory experts offer direct assistance to registered users with valid guarantee/maintenance. The Support Cen-
tre is located on the website [Link] Additionally DIgSILENT
GmbH offers a standard 2-day training course on dynamic modelling and DSL. In-house courses are normally
run twice per year; however, special courses can be provided upon request. Please contact DIgSILENT or
consult the website ([Link]) for details on course dates and schedules.