PowerWare Interface Manual

DIgSILENT PowerFactory
Version 13.1

DIgSILENT GmbH
Gomaringen, Germany

2005
Publisher:
DIgSILENT GmbH
Heinrich-Hertz-Str. 9
72810 Gomaringen / Germany
Tel : +49 (0) 7072-9168-0
Fax : +49 (0) 7072-9168-88

Visit our homepage at:

http://www.digsilent.de

Copyright DIgSILENT GmbH.

All rights reserved. No part of this
publication may be reproduced or
distributed in any form without
permission of the publisher
doc 2005 03 21 657 b295
Contents

1 PowerWare Interface 1
1.1 About PowerWare . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Component Architecture . . . . . . . . . . . . . . . . . . . . . 2
1.3 Fundamental Concepts . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Location . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Device . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.3 Device State . . . . . . . . . . . . . . . . . . . . . . 6
1.3.4 Lifecycle Phase . . . . . . . . . . . . . . . . . . . . . 7
1.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.1 PowerWare Server . . . . . . . . . . . . . . . . . . . 9
1.4.2 PowerFactory Client . . . . . . . . . . . . . . . . . . 9
1.5 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5.1 Prepare substation in PowerWare . . . . . . . . . . . 9
1.5.2 Prepare project in PowerFactory . . . . . . . . . . . 10
1.5.3 Link Relays and establish a Connection . . . . . . . . 12
1.5.4 Export and Import Settings . . . . . . . . . . . . . . . 16
1.6 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6.1 The Device Context Menu . . . . . . . . . . . . . . . 18
1.6.2 Connection . . . . . . . . . . . . . . . . . . . . . . . 19
1.6.3 The Browser Dialog . . . . . . . . . . . . . . . . . . . 21
1.6.4 The C OM P OWERWARE Object . . . . . . . . . . . . . 21
1.7 Technical Reference . . . . . . . . . . . . . . . . . . . . . . . . 25
1.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 26
1.7.2 Import Scripts . . . . . . . . . . . . . . . . . . . . . . 26
1.7.3 Export Scripts . . . . . . . . . . . . . . . . . . . . . . 28
1.7.4 How to create a new Device Type conversion . . . . . 31
DIgSILENT PowerFactory PowerWare Interface

Chapter 1

PowerWare Interface

This chapter describes the PowerWare interface. An introduction into PowerWare’s

general philosophy is given in section 1.1.
The following two sections describe the overall PowerWare architecture (section 1.2
on page 2) and the conceptual differences between PowerFactory and PowerWare
(section 1.3 on page 4).
Both PowerFactory and PowerWare have to be configured before they can be used
together (section 1.4 on page 8).
The Getting Started section (section 1.5 on page 9) provides a gentle introduction
into the most important features. The complete documentation can be found in the
Reference section (section 1.6 on page 18).
The final Technical Reference (section 1.7 on page 25) provides some deeper
knowledge how PowerFactory data is converted to PowerWare data and vice versa.
The terms PowerWare and PSMS are used as synonyms throughout the whole
chapter. PSMS stands for Protection Settings Management System, and stresses
the more internal and technical part of PowerWare.

1.1 About PowerWare

DIgSILENT PowerWare provides a reliable central protection settings database and

management system for the complete power system substation data, both to manage
the various control parameters and to centrally store substation related information
and data, based on latest .NET technology.
PowerWare stores and records all settings in a central database, allows modeling of
all relevant work flow sequences, provides quick access to relay manuals, interfaces
with manufacturer specific relay settings software, and integrates with PowerFactory
software, allowing for powerful and easy-to-use settings co-ordination studies.
Modern numerical relays have a large number of settings that are determined, stored
and communicated by proprietary software solutions (these may even be suitable for
only a particular manufacturer or even a series or type of relay). This results in a
fragmented and distributed settings ”database.” DIgSILENT PowerWare provides a

1
PowerWare Interface DIgSILENT PowerFactory

single system that incorporates all such different device protocols, thereby providing
one manageable software data storage system, based on modern IT techniques,
facilitating data interfacing and exchange in a transparent and hassle free manner.
PowerFactory’s data exchange facility allows it to access the settings stored in
PowerWare, such that these may be used as input for the powerful PowerFactory
system simulation and protection setting tools. Settings that are calculated by using
these tools may then be transferred back to PowerWare.

1.2 Component Architecture

DIgSILENT PowerWare is a so-called Client-Server Application: the functionality is

distributed on at least two computers: client and server. Fig. 1.1 gives an overview on
the components.

Figure 1.1: Architecture Overview

Usually there are several clients. One main advantage of this architecture is the fact
that the data is stored in one central database on the server. One client connects to
the server and fetches the data from there, modifies them, and afterward stores them
back to the server. On other clients these changes are visible.
DIgSILENT PowerWare server provides two interfaces to access from client
machines:

1. The HTML interface can be used with an usual web browser (e.g. Microsoft
Internet Explorer or Mozilla Firefox) as shown in Fig. 1.2.

2
DIgSILENT PowerFactory PowerWare Interface

Figure 1.2: HTML interface

The browser displays HTML pages which are created by PowerWare’s HTML
frontend. The HTML pages are transfered using the HTTP protocol on top of the
TCP/IP internet protocol.
HTML allows to present all kind of data e.g. plain text, tables or images.
Additionally HTML provides concepts to achieve interactivity: by submitting HTML
forms or pressing on hyperlinks data is sent to the server. The server interprets
such requests and creates new HTML pages which are displayed by the browser
again.

2. The web service interface, similar to the HTML interface uses the HTTP proto-
col to communicate with the web service frontend, though no HTML pages are
transfered but lower-level data (SOAP/XML encoded). The web service client
application is responsible to present this data conveniently.
PowerFactory is able to play the role of a web service client. It integrates parts
of PowerWare’s data and concepts smoothly into its own world.

The functionality of the HTML interface is covered in the PowerWare manual. The
remainder of this chapter focuses on PowerFactory as client.

3
PowerWare Interface DIgSILENT PowerFactory

1.3 Fundamental Concepts

Though both in PowerWare and in PowerFactory the settings and data associated
with protective devices, such as relays, CTs, VTs and circuit breakers are stored, the
systems provide a different set of concepts how to deal with this data.
In PowerWare it’s possible to model a location hierarchy and associate the devices
to nodes in this hierarchy (e.g. substations). This has no equivalent on the
PowerFactory side where the devices are stored inside the parent grid (E LM N ET)
object.
On the other side PowerFactory allows to create a topological representation of
networks which is not supported in PowerWare.
This section describes the concept mismatch between PowerFactory and
PowerWare. In order to use the PowerWare interface it’s important to know about
the differences between both applications.

1.3.1 Location
In PowerWare each device belongs to exactly one location. There are different
location types e.g. Region, Area, Substation, or Bay. The locations are organized in a
hierarchy tree as shown in Fig. 1.3.

Figure 1.3: PowerWare Locations

4
DIgSILENT PowerFactory PowerWare Interface

In PowerFactory the data is organized in projects (I NT P RJ). A project may have one
or more grids (E LM N ET) which in turn contain net elements e.g. terminals, cubicles,
and relays (E LM R ELAY). See Fig. 1.4 for a typical PowerFactory project.

Figure 1.4: PowerFactory Project

PowerWare’s location concept and PowerFactory’s project/grid concept hardly fit

together. That’s the reason why the data mapping between PowerFactory and
PowerWare begins at the device level which is the subject of the next sections.

1.3.2 Device
PowerWare manages a set of devices e.g. relays, CTs, VTs, or Circuit breakers.
Each device is associated to a device type e.g. ABB DPU2000R or SEL421 003.
Additionally each device has an unique ID: the device ID.
In PowerFactory a relay is represented by an E LM R ELAY object which references
exactly one T YP R ELAY object. The E LM R ELAY object contains several sub-
components e.g. the I> component (a R ELTOC object), the Logic component
(R EL L OGIC), or the Ios component (R EL M EASURE). See Fig. 1.5 for an example.
The device ID is used to link one PowerWare device to one PowerFactory device.
The PowerFactory device e.g. a E LM R ELAY object stores the PowerWare device ID
as foreign key.

5
PowerWare Interface DIgSILENT PowerFactory

Figure 1.5: PowerFactory Relay

1.3.3 Device State

A device’s state is in PowerWare called setting. A setting is a list of attributes, and
describes the state of one device completely.
An attribute is a tuple of

• attribute name

• attribute type which can be an arbitrary integer or floating point number, option-
ally with a range restriction, or a string, or a enumeration type.

• a default value

• an optional unit

A complex relay may have thousands of attributes. In PowerWare the setting

attributes are organized in so-called setting groups. A setting group groups the
attributes together which belong somehow together. It’s often defined by the device
manufacturer. Each attribute belongs to exactly one setting group. Inside a group the
attribute name is unique.
The device type defines which attributes and groups characterize a device. Table 1.1
shows an example of a possible device type.
There are two setting groups G and H. Group G has the attributes a, b, and c, group
H has the attributes d and e.
According to this attribute definition a device can have settings as shown in table 1.2.

6
DIgSILENT PowerFactory PowerWare Interface

Group Name Type Default Unit

G a integer in [0,10] 0 A
b float -0.32 I/s
c float in [0.03,1.65] 1.0
H d string ’DEFAULT’
e enum ’yes’, ’no’, ’maybe’ ’yes’
Table 1.1: Settings definition

Group.Name Value Group.Name Value

G.a 7 G.a 8
G.b 23.43 G.b 0
G.c 1.1 G.c 1.1
H.d ’abc’ H.d ’abcdef’
H.e ’maybe’ H.e ’yes’
Table 1.2: Setting examples

On the PowerFactory side there are neither setting nor group nor attribute. There is
the E LM R ELAY object and its sub-objects. These objects can have parameters. See
table 1.3 for a definition and table 1.4 for an example. The T YP R ELAY type defines
components and parameters.

Component Parameter Type

i> o integer
Logic p string
q enum ’enabled, ’disabled’
Ios r float
s float
Table 1.3: Parameter definition

PowerWare attributes are somehow mapped to PowerFactory parameters and

vice versa. How this actually is accomplished, is described in section 1.7 on
page 25. The mapping is non-trivial since only a small subset of the attributes (the
calculation-relevant data) is modeled in PowerFactory and vice versa. Additionally
there is no one-to-one relationship between attributes, and parameters and a
parameter could get calculated out of several attributes.
Some relays support multiple setting groups (MSG) also called parameter sets. Such
relays have the same group many times (c.f. table 1.5).
The groups H1, H2, and H3 have the same set of attributes (c and d). Some relay
models in PowerFactory don’t support this concept fully. Instead of modeling all
MSGs, only one instance of the H groups is provided.
In this case a group index parameter defines which of the MSGs actually is transfered
from PowerWare to PowerFactory.

1.3.4 Lifecycle Phase

In PowerWare each setting has one lifecycle phase e.g. P LANNING or A PPLIED. At
each point in time a device can have a set of settings e.g. three P LANNING settings,
one A PPLIED setting and 12 H ISTORIC settings.

7
PowerWare Interface DIgSILENT PowerFactory

Component:Parameter Value
i>:o 8
Logic:p ’HIGH’
Logic:q ’enabled’
Ios:r 18.5
Ios:s 19.5
Table 1.4: Parameter example

Group Name Type Default Unit

G a integer in [0,10] 0 A
b float -0.32 I/s
H1 c string ’DEFAULT’
d float in [0.03,1.65] 1.0
H2 c string ’DEFAULT’
d float in [0.03,1.65] 1.0
H3 c string ’DEFAULT’
d float in [0.03,1.65] 1.0
Table 1.5: Multiple setting group definition

In PowerFactory a device has exactly one state (or setting). Therefore when data
is transfered between PowerFactory and PowerWare, always a concrete device
setting in PowerWare must be specified.
For PowerFactory purposes a special P OWER FACTORY planning phase is introduced.
The transfer directions are specified as follows:

• Imports from PowerWare into PowerFactory are restricted to Applied and

PowerFactory settings.
Applied denotes the current applied setting (A PPLIED) or a previous applied
(H ISTORIC) setting.

• Exports from PowerFactory to PowerWare are restricted to the PowerFactory

setting. (A PPLIED and H ISTORIC settings are read-only and can never be changed).

(Actually PowerFactory’s sophisticated variant management is similar to the phase

concept, but there is no obvious way how to bring them together.)

1.4 Configuration

In order to transfer data between PowerFactory and PowerWare both systems must
be configured.

8
DIgSILENT PowerFactory PowerWare Interface

1.4.1 PowerWare Server

An arbitrary PowerWare user account can be used for the PowerWare interface in
PowerFactory. The user must have enough access rights to perform operations e.g.
for the export from PowerFactory to PowerWare write-rights must be granted.
A non-default lifecycle phase named P OWER FACTORY of status P LANNING must be
created. This phase must have a cardinality constraint of 1 i.e. there may exist one or
no such setting for one device.

1.4.2 PowerFactory Client

The client operating system must allow connections to the server (network and
firewall settings etc.).
Nothing has to be done in the PowerFactory configuration itself. The T YP R ELAYs in
the Library must of course support PowerWare/PowerFactory mapping.

1.5 Getting Started

This section is a simple walkthrough and covers the most essential PowerWare
interface functionality. By using a simple PowerFactory project and simple
PowerWare substation, it describes

1. how relays in PowerWare and PowerFactory are created

2. how these relays are linked

3. how settings can be exported from PowerFactory to PowerWare

4. how settings can be imported again into PowerFactory

All (especially the more advanced) options and features are described in the reference
section (see section 1.6 on page 18).

1.5.1 Prepare substation in PowerWare

We begin with the PowerWare side. We create a substation and two relays within:

start the web browser

log on to the PowerWare system

create a new substation titled Getting Started

9
PowerWare Interface DIgSILENT PowerFactory

Figure 1.6: Substation

create two relays named Getting Started Relay 1 and Getting Started Relay 2 in
the Getting Started substation

In the HTML interface the station detail page should look as shown in Fig. 1.6.

Go to the detail page of the Getting Started Relay 1 (c.f. Fig. 1.7).

Figure 1.7: Device

Since we’ve just created the device it has no settings, yet. Later it will contain a
PowerFactory setting which reflects the relay state on the PowerFactory side.

1.5.2 Prepare project in PowerFactory

Create a new PowerFactory project and create a simple grid within

10
DIgSILENT PowerFactory PowerWare Interface

start PowerFactory

create a new project titled G ETTING S TARTED

draw a simple grid with two terminals (E LM T ERM) connected by a line (E LM L NE)
as shown in Fig. 1.8.

Figure 1.8: Grid

Now add a relay to the upper terminal

right-click the cubicle quadrangle with the mouse. A context menu pops up.

select New Devices.../Relay Modell... as shown in Fig. 1.9.

A dialog pops up that allows you to specify the settings of the new relay (E LM R ELAY).

insert Getting Started Relay 1 as Name

select an appropriate Relay Type which supports PowerWare import/export

(c.f. Fig. 1.10).

press OK

in the same way add a relay G ETTING S TARTED R ELAY 2 to the second terminal.

PowerFactory’s object filter mechanism gives an overview over all devices inside the
current project.

11
PowerWare Interface DIgSILENT PowerFactory

Figure 1.9: Cubicle context menu

Press the icon (Edit Relevant Objects for calculation) in the toolbar and
select the icon (E LM R ELAY) to filter out all non-relay objects as shown in
Fig. 1.11.

All calculation relevant relays (actually there only the two we created above) are
displayed in a table (c.f. Fig. 1.12).

1.5.3 Link Relays and establish a Connection

Now the PowerFactory relays must get linked to the PowerWare relays.

mark both relay icons with the mouse

press the right mouse button

A context menu pops up as shown in Fig. 1.13

select the PowerWare menu item

select the Select Device ID item

A Log on to PowerWare server dialog pops up. Since this is the first time
PowerFactory connects to the PowerWare server some connection settings must be
entered.

12
DIgSILENT PowerFactory PowerWare Interface

Figure 1.10: Relay dialog

Figure 1.11: Relay object filter

enter the Server Endpoint URL of the PowerWare server. The URL should have
a format similar to

http://the.server.name/powerwarews/powerwarews.asmx

enter Username and Password of a valid PowerWare user account

13
PowerWare Interface DIgSILENT PowerFactory

Figure 1.12: Relay display

Figure 1.13: Device Context Menu

Fig. 1.14 shows the dialog settings.

Figure 1.14: Log on Dialog

press OK

14
DIgSILENT PowerFactory PowerWare Interface

The connection procedure may take some seconds. If the server could be accessed
and the user could be authenticated a success message is printed into the output
window

DIgSI/info - Established connection

to PowerWare server ’http://192.168.1.53/psmsws/psmsws.asmx’
as user ’pf00002’

Otherwise an error dialog pops up. Correct the connection settings until the
connection is successfully created.
The reference section (section 1.6.2) explains the connection options in detail.
Having established a connection to the server, a browser dialog pops up which
displays the location hierarchy as known from the PowerWare HTML interface. The
dialog is shown in Fig. 1.15.

navigate to the Getting Started substation

select the Getting Started Relay 1 device

press OK

Figure 1.15: Browser Dialog

Now the PowerFactory relay is ”connected” to the PowerWare device.

in the same way select Getting Started Relay 2 for the second PowerFactory
relay.

15
PowerWare Interface DIgSILENT PowerFactory

1.5.4 Export and Import Settings

Having linked PowerFactory to PowerWare devices, the transfer between both
systems can be done.

mark the relays with the mouse and right-click to get the relay context menu as
shown in figure 1.13 on page 14.

select the Export... item in the PowerWare menu entry.

A C OM P OWERWARE dialog is shown which allows to specify the export options

(c.f. Fig. 1.16). See section 1.6.4.2 on page 25 in the Reference section for all export
options.

Figure 1.16: ComPowerware Dialog

leave PowerFactory as Lifecycle Phase

press E XECUTE

After a few seconds the relay settings are transfered to the server, and the output
window contains the message

DIgSI/info - Exported 2 of 2 device settings successfully

The result can now be observed in the PowerWare HTML interface.

16
DIgSILENT PowerFactory PowerWare Interface

Figure 1.17: Device detail page

navigate to the relay detail view of the Getting Started Relay 1 relay (c.f. Fig.
1.17)

Observe the new created PF setting. The phase of this setting is P OWER FACTORY.

switch to the settings detail page of the new PF setting (c.f.Fig. 1.18).

Figure 1.18: Setting detail page

The setting values should correspond to the relay state in PowerFactory. In the
same way the Getting Started Relay 2 relay has a new PF setting.
Now try the opposite direction and import a setting from PowerWare into
PowerFactory.

17
PowerWare Interface DIgSILENT PowerFactory

modify the PF settings in PowerWare by entering some other values

in PowerFactory mark the relays with the mouse and right-click to get the relay
context menu as shown in figure 1.13 on page 14.

select the Import... item in the PowerWare menu entry.

Again the C OM P OWERWARE dialog (c.f. figure 1.16 on page 16) pops up as known
from the export.

leave the default settings

press E XECUTE

Again the result of the settings transfer is reflected in the output window:

DIgSI/info - Imported 2 of 2 device settings successfully

find E LM R ELAY object parameters changed according to the changes on the

PowerWare side

All import options are described in detail in the reference section (section 1.6.4.1 on
page 22).

1.6 Reference

This section describes all options and features concerning the PowerWare interface.

1.6.1 The Device Context Menu

Almost all functionality can be accessed by the device context menu. Mark one ore
more objects which supports the PowerWare transfer e.g. E LM R ELAY

• in the object filter (c.f. in figure 1.13 on page 14)

• in the data manager as shown in Fig. 1.19

The PowerWare submenu contains the entries as follows:

Import... opens the C OM P OWERWARE dialog and sets the device selection according
to the above selected device objects.
The C OM P OWERWARE dialog settings are explained in detail in section 1.6.4 on
page 21.

18
DIgSILENT PowerFactory PowerWare Interface

Figure 1.19: Device Context Menu

Export... does the same for the export direction.

Select Device ID... starts the Browser Dialog (c.f. figure 1.23 on page 22) to link
this device to a PowerWare device. The dialog is subject of section 1.6.3 on
page 21.

Reset Device ID resets the device ID.

Connect... terminates the current PowerWare session if it’s already existing. Shows
a Log On dialog. The connection settings are covered by section 1.6.2.
This may be useful when you’re using several PowerWare accounts and want
to switch between them.

Disconnect terminates the PowerWare session

1.6.2 Connection
Similar to the HTML interface the PowerWare interface in PowerFactory is
session-oriented: when a user logs on to the system by specifying a valid PowerWare
account (username and password) a new session is created. Only inside such a
session PowerWare can be used. The account privileges restrict the application
functionality e.g. an administrator account is more powerful than a usual user account.

19
PowerWare Interface DIgSILENT PowerFactory

Figure 1.20: Log on Dialog

Working with PowerFactory the first time the PowerWare server is required the Log
on dialog is shown as shown in figure 1.20 on page 20.
The PowerWare connection options are stored in the user settings (c.f. Fig. 1.21).
After each successful logon the the user settings are updated.

Figure 1.21: User Settings

As mentioned in the Architecture section (section 1.2) PowerWare is a client-server

application. The PowerWare server component is located on a server machine in the
internet. The client component is the PowerFactory application which is running on
a client machine.
The technology PowerFactory and PowerWare use to communicate is called web
services and is standardized like many other internet technologies (HTML, HTTP).
The server computer (or more exactly the PowerWare service application on the the
server computer) has a ’name’ by which it can be accessed. This ’name’ is called
service endpoint and resembles a web page URL:

http://the.server.name/psmsws/psmsws.asmx

or

http://192.168.1.53/psmsws/psmsws.asmx

http denotes the protocol, the.server.name is the computer name (or DNS) of
the server computer and psmsws/psmsws.asmx is the name of the PowerWare
application.
The connection options are as follows:

Service Endpoint The Service Endpoint denotes the PowerWare server ’name’ as
described above

20
DIgSILENT PowerFactory PowerWare Interface

Username/Password Username and Password have to be valid user account in

PowerWare. A PowerWare user account has nothing to do with the Power-
Factory user account.

The very same PowerWare account can be used by two different PowerFactory
users.
The privileges of the PowerWare account actually restrict the functionality. For device
import the user requires read-access rights. For exporting additionally write-access
rights are required.

1.6.3 The Browser Dialog

As mentioned in the Concept section (section 1.3.2 on page 5) the PowerWare
device ID is stored as Foreign Key in the E LM R ELAY object dialog (Description page)
as shown in Fig. 1.22.

Figure 1.22: ElmRelay Dialog

A more convenient way is to use the Browser Dialog shown in Fig. 1.23. The dialog
allows to browse through the PowerWare location hierarchy and select a device.
The hierarchy data is cached to minimize network accesses. Due this caching
it’s possible that there may exist newly created locations or devices which are not
displayed in the browser dialog. The R EFRESH button empties the cache and
enforces PowerFactory to re-fetch the correct data from the server.

1.6.4 The C OM P OWERWARE Object

In PowerFactory almost everything is an object: relays are E LM R ELAY objects, users
are I NT U SER objects, and grids are E LM N ET objects.
What may be on the first sight confusing is the fact that actions are objects as well:
for a short-circuit calculation a C OM S HC object is created. The calculation can be
performed with several options e.g. 3-Phase, single phase, or 3 Phase to Neutral.
You can even specify the fault location. All these calculation options are stored in the

21
PowerWare Interface DIgSILENT PowerFactory

Figure 1.23: Browser Dialog

C OM S HC object. Every action object has an E XECUTE button which starts the
action.
In fact there is a whole bunch of parametrized actions like loadflow calculation
(C OM L DF), simulation (C OM S IM), there’s even a C OM E XIT object that shuts down
PowerFactory. All objects which can ’do’ something have the C OM prefix.
Since the PowerWare interface is actually ’doing’ something (it does import data, it
does export data) it is implemented as a C OM P OWERWARE object.
The C OM P OWERWARE object is used both for the im import (section 1.6.4.1) and
the export (section 1.6.4.2). It is located in the project’s study case according to
PowerFactory conventions. The actual Getting Started project (section 1.5) is shown
in Fig. 1.24.
By default the study case of a new project contains no C OM P OWERWARE object. It
is automatically created when it is first needed, as well as the C OM S HC object is
instantiated at the time when the first short-circuit calculation is performed.

1.6.4.1 Import Options

The C OM P OWERWARE dialog provides import options as follows (Fig. 1.25):

Transfer Mode select Import from PowerWare as Transfer Mode

Check only Plausibility if the Check only Plausibility flag is enabled the import is
only simulated but not really executed.

Lifecycle Phase/Time stamp The Lifecycle phase may either be PowerFactory or

Applied.

22
DIgSILENT PowerFactory PowerWare Interface

Figure 1.24: Project Study Case

Figure 1.25: ComPowerware Import Options

• PowerFactory selects the current setting with P OWER FACTORY phase as

source setting
• if Applied is selected the current A PPLIED setting is transfered. If addition-

23
PowerWare Interface DIgSILENT PowerFactory

ally a Timestamp value is entered the setting that was applied at this time
is transfered which may either be A PPLIED or H ISTORIC.

The Timestamp format is in ISO format

2005-02-28 22:27:16

The time part may be omitted. Then 00:00:00 AM is assumed.

All Devices If All Devices is enabled, all calculation-relevant devices are imported.
Devices not supported by PowerWare are ignored.

Device Selection Unless All Devices is enabled, the Device Selection provides a
more subtle way to specify which devices are to be transfered. The Device
Selection parameter can be

• an E LM R ELAY object: this and only this relay is imported

• a S ET S ELECT object: a S ET S ELECT is a container that may hold several
objects. All of them are transfered, except the ones not supported by Pow-
erWare
• a S ET F ILT object: the S ET F ILT is the most flexible way to specify the device
selection e.g. you can select all devices in the project of type E LM R ELAY
and whose name begin with PW....

Devices outside the activated project are ignored.

The Device Selection is automatically set if the Device Context Menu mecha-
nism (section 1.6.1 on page 18) was used.

All Settings Groups/Group Index This parameter specifies how multiple settings groups
(MSG) are handled (c.f. section 1.3).

• If the relay in PowerWare has MSGs and the PowerFactory relay model
supports MSGs and
– All Settings Groups is enabled: then all groups are transfered.
– All Settings Groups is disabled: then only the Group Index-th group is
transferred.
• If the relay in PowerWare has MSGs and the PowerFactory relay model
doesn’t support MSGs: then the Group Index-th group is imported.

These parameters are ignored completely if the relay has no MSGs.

The import transfer is started by pressing E XECUTE .

24
DIgSILENT PowerFactory PowerWare Interface

Figure 1.26: ComPowerware Export Options

1.6.4.2 Export Options

The export options are almost identical to the import options (c.f. Fig. 1.26):

Transfer Mode Select Export as Transfer Mode

Lifecycle Phase Only the P OWER FACTORY setting in PowerWare can be the target
setting. A PPLIED settings can never be changed.

Click E XECUTE to start the data transfer. If there exists already a P OWER FACTORY
setting in PowerWare it is removed completely.
Then a new P OWER FACTORY is created as copy of the current A PPLIED setting.
If no A PPLIED setting is available the default settings are copied. Then the
PowerFactory-relevant part of the settings are copied upon the P OWER FACTORY
setting.

1.7 Technical Reference

The purpose of this section is to describe what happens internally inside

PowerFactory when device settings are exported or imported.

25
PowerWare Interface DIgSILENT PowerFactory

This section also explains how new device types are integrated. PowerFactory is
delivered with a library of relay models. This library can’t contain all relays of all
manufacturers. A way how to enhance the library for new device types is shown in
this section as well.
The PowerWare interface is heavily based on DPL (Digsilent Programming
Language) which is documented in a separate DPL Manual.

1.7.1 Overview
For each device type (T YP R ELAY) and each transfer direction a separate DPL script
is required.
The import DPL script takes the PowerWare attributes and a E LM R ELAY object as
input and fills somehow the E LM R ELAY object’s and its subobjects’ parameters.
The export DPL script takes a E LM R ELAY object as input parameter and calculates
some output parameters which are the PowerWare attributes.

Note
DPL’s most important benefit is: you can do everything.
That’s exactly DPL’s most important disadvantage as well. Be sure that your
DPL scripts do what they should do and not more.
An import script should only set the parameters in the E LM R ELAY object and
its subcomponents.
An export script shouldn’t change anything at all (at least within
PowerFactory).

The scripts have to be named P SMS I MPORT.C OM D PL and P SMS E XPORT.C OM D PL

and must be located in the same folder as the T YP R ELAY object.
Type data like T YP R ELAY objects should be located in a library folder e.g. in the
project library. If it is referenced from several projects, it belongs into a global library.
See Fig. 1.27 for an example database structure.

1.7.2 Import Scripts

The algorithm used for the import from PowerWare to PowerFactory is as follows.
Let d be the device whose setting is to be imported:

1. let t be d’s device type

2. let dpl be the P SMS I MPORT.C OM D PL object near t

3. initialize dpl’s input parameter with the device attributes from PowerWare

4. initialize dpl’s external object parameter Relay with d

5. execute dpl

26
DIgSILENT PowerFactory PowerWare Interface

Library
+- Relays
+- ManufacturerA
| +- Relay family A
| | +- RA1.ElmRelay
| | +- RA2.ElmRelay
| | +- RA3.ElmRelay
| | +- PsmsImport.ComDpl
| | +- PsmsExport.ComDpl
| |
| +- Relay family B
| +- RB1.ElmRelay
| +- RB2.ElmRelay
| +- PsmsImport.ComDpl
| +- PsmsExport.ComDpl
|
+- ManufacturerB
+- ....

Figure 1.27: Database Structure

The execution step actually sets the relay parameters.

We use the PowerWare device type example shown in table 1.1 on page 7 from
the Concept section (section 1.3) and the PowerFactory device type as shown in
table 1.3 on page 7.
The PowerWare attributes are G.a, G.b, G.c, H.d, and H.e, the PowerFactory
parameters are I>:o, Logic:p, Logic:q, Ios:r, and Ios:s.
Only the attributes G.a, G.c, and H.d and the parameters I>:o, Logic:p, and Ios:r
are mapped. The others are ignored since there is no equivalent concept on the other
system.
Fig. 1.28 shows the Basic options. The P SMS I MPORT.C OM D PL must meet the
requirements as follows:

Name must be PsmsImport

General Selection must be empty

Input Parameters this table holds the PowerWare attributes. The Name has the
format

[group name] [attribute name]

The Type may either be int (for integer numbers), double (for floating point
numbers), or string (for string and enum values).
The Value field must be empty. The attribute unit has to inserted in the Unit field
if appropriate. A Description may be inserted, too.

External Object this table contains exactly one entry: an object with the Name Relay.
The object column must be empty.

27
PowerWare Interface DIgSILENT PowerFactory

Figure 1.28: DPL import script: Basic options

The Input parameters get initialized with the PowerWare attribute values and the
External Object with the current relay.
The second page of the C OM D PL script holds the output parameters. They have the
meaning as follows (Fig. 1.29 shows the Advanced options).

Remote Script this parameter must be unset

Result Parameters the table must have one entry with Name Result of Type String.
The DPL script should set this parameter to OK if the import procedure was
successful. Otherwise it may hold an error message which is displayed in the
output window.

Fig. 1.30 shows the Script page which contains the DPL code. The code must
be a valid DPL program. It should set the relay parameters according to the input
parameters.

1.7.3 Export Scripts

The export direction is almost symmetric to the import process. Be d the device
whose setting is to exported:

1. let t be d’s device type

2. let dpl be the P SMS E XPORT.C OM D PL object near t

28
DIgSILENT PowerFactory PowerWare Interface

Figure 1.29: DPL import script: Advanced options

Figure 1.30: DPL import script: Script

3. initialize dpl’s external object parameter Relay with d

4. execute dpl

29
PowerWare Interface DIgSILENT PowerFactory

5. transfer dpl’s output parameter to the setting in PowerWare

The export DPL script must also meet some requirements: Fig. 1.31 shows the Basic
options. The C OM D PL.

Figure 1.31: DPL export script: Basic options

Name must be PsmsExport

General Selection must be empty

Input Parameters this table must be empty

External Object this table contains exactly one entry: an object with the Name Relay.
The object column must be empty.

The second page of the C OM D PL script holds the output parameters. They have the
meaning as follows (c.f. Fig. 1.32 shows the Advanced options).

Remote Script this parameter must be unset

Result Parameters the table must have the first entry with Name Result of Type
String.
The DPL script should set this parameter to OK if the import procedure was
successful. Otherwise it may hold an error message which is displayed in the
output window.
Below the Result parameter are the PowerWare attributes.

Fig. 1.33 shows the Script page which contains the DPL code. The code must be a
valid DPL program. It shouldn’t change the database.

30
DIgSILENT PowerFactory PowerWare Interface

Figure 1.32: DPL export script: Advanced options

Figure 1.33: DPL export script: Script

1.7.4 How to create a new Device Type conversion

This section gives some practical guidelines how to create the conversion scripts for
new types.

31
PowerWare Interface DIgSILENT PowerFactory

First create a test environment:

create in PowerWare a new substation with one device of the desired device
type. Create a default P OWER FACTORY setting for this device.

create a simple PowerFactory project which contains a device of the desired

type

link the PowerFactory device to the the PowerWare device by setting the for-
eign key to the device ID.

Then write the import script:

create an empty P SMS I MPORT.C OM D PL near the T YP R ELAY object.

define the input and output parameters of the C OM D PL object

write the DPL code

test the script by importing the P OWER FACTORY setting

Iterate these steps until there are no error messages. Change the setting in
PowerWare and re-try the import.
In quite the same way create and verify a P SMS E XPORT.C OM D PL script.

32