StationWare User Manual
StationWare User Manual
StationWare User Manual
StationWare 2016
User Manual
User Manual
Online Edition
DIgSILENT GmbH
Gomaringen, Germany
April 2016
Publisher:
DIgSILENT GmbH
Heinrich-Hertz-Strae 9
72810 Gomaringen / Germany
Tel.: +49 (0) 7072-9168-0
Fax: +49 (0) 7072-9168-88
April 2016
2993
Contents
I General Information 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Contact us 5
4 StationWare overview 9
5.2 My StationWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6 Locations 25
7 Devices 37
8 Settings 47
10 History mode 69
11 Library 73
12 Reports 79
III Administration 81
13 Device administration 83
13.2 Manufacturers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.3.6 Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
13.3.10 Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
13.3.13 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
13.4 Usages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
13.5.3 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
16 Scripts 121
17.1.8 Create users or user groups directly as a member of an existing user group . . . 133
17.1.10 Remove users and user groups from a user group . . . . . . . . . . . . . . . . . 134
General Information
Chapter 1
1.1 Introduction
This user manual is a reference for users of the DIgSILENT StationWare software. It covers the general
idea and philosophy of StationWare, the mechanics of using the web interface, how to use reports to
obtain formatted information from the system, configuration options for the database administrator, and
additional information ways to interface with StationWare from other tools such as PowerFactory.
This chapter covers general information about the contents and the used conventions of this documen-
tation.
This part (Part I) of the user manual provides general information, an overview of StationWare software
and how to contact DIgSILENT for additional support.
Part II provides the main guide to the StationWare interface and information about each of the tasks
that users would be required to perform.
For information about how to configure the software, if you are an administrator of the system, refer to
Part III.
Part IV covers some examples for interfacing external tools with StationWare. This includes how to
configure settings converters, and how to interface with PowerFactory.
Menus, actions and links Menus and actions are referenced using Italics. For example, refer to the
main menu Hierarchy region North and select the action Edit.
Objects and data Speech marks are used to indicate objects in StationWare or data to be entered
by the user. For example, Change the name of the region North to East.
Buttons Buttons to click are indicated in Bold underlined font. For example, click Create to generate
the new settings.
StationWare is web based software. This means that the majority of actions and objects within the
software are presented as clickable hyperlinks within a standard web browser interface. Clicking on a
hyperlink within StationWare causes one of the following actions:
Some property of the page or object is changed. For instance when changing a lifecycle phase of
a relay settings object.
Navigating to another page. For example, when clicking on a device within a substation location.
Editing the properties of the current page. Usually this is achieved by clicking the Edit action after
which the page will refresh and the editable fields of the object will become apparent.
A new sub-window appears. For example when adding additional documents, or using the Navi-
gator.
In contrast to a traditional windows application, information that is entered into fields in the StationWare
interface is not automatically saved by software. To save the information you need to submit it to the
software for processing by clicking Submit or some other button depending on the context.
Contact us
For further information about the company DIgSILENT , our products and services please visit our web
site, or contact us at:
DIgSILENT GmbH
Heinrich-Hertz-Strae 9
www.digsilent.de
For general information about DIgSILENT or your StationWare license, contact us via:
Phone: +49-(0)7072-9168-0
Fax: +49-(0)7072-9168-88
E-mail: mail@digsilent.de
DIgSILENT has many local representatives around the world and users are encouraged to contact
their local regional representative in the first instance should they have any queries. Please refer to
http://www.digsilent.de/index.php/company-international.html for the latest contact information for the
local representatives.
DIgSILENT experts offer direct assistance to StationWare users with valid maintenance agreements
via:
E-Mail: stationware@digsilent.de
For users that are outside of Europe, it may be more convenient to contact your local DIgSILENT
representative in the first instance. Should they not be able to answer your query they can forward your
question directly to technical assistance in Europe.
DIgSILENT StationWare is provided with a complete help package to support users at all levels of
expertise from beginner to system administrator.
Installation manual: StationWare installation guide, describes the procedures followed to install and
setup the program in a standalone PDF. It is available for download from the DIgSILENT Station-
Ware download area.
User manual: This document. Access via Help link in StationWare. The current manual (PDF files)
can also be found on the DIgSILENT StationWare download area. Note beginning and less ex-
perienced users are encouraged to first refer to Part II for the basics of using the program and its
functionalities, while more experienced users who are after more detailed information on config-
uring the software are encouraged to refer to Parts III and IV.
Settings converter manual: Each settings converter (for importing/exporting relay manufacturer set-
tings files) is issued with a corresponding manual. These are available in the DIgSILENT Station-
Ware download area.
Release notes: For all new versions and updates of the program Release Notes are provided. These
document the changes in the software from previous versions. They are available in the DIgSI-
LENT StationWare download area.
Website: www.digsilent.de
StationWare overview
This chapter introduces StationWare and provides a primer for the general aspects of the software
including the software concept, the software data structure, and the user interface.
The idea of StationWare is to provide a tool that meets the following needs:
A data repository for relay settings files supporting historical, current, and proposed new versions
of settings.
Organisation of additional documentation associated with devices and settings, including relay
manuals, application guides, instrumentation diagrams, and settings calculations.
Easy access to information. Furthermore, it must be straightforward for users to modify information
in the database.
Workflow processes and settings processes unique to an organisation should be supported and
the software should make this a fundamental feature that is deeply integrated into the settings
management process.
It should be manufacturer agnostic such that it supports in principle all devices regardless of man-
ufacturer, and hence provides a unifying interface for the management of settings from multiple
different vendors.
It should allow for import and export of settings information from third party vendors and also
integration with specialised analysis software that is used as an aid to settings development.
The preceding aspects are discussed in more detail in the following paragraphs.
The first requirement is that a settings management system should be a data repository. This stems
mostly from the complexity of modern relays which has increased dramatically since the first numerical
relays were introduced.
Modern multifunction numerical devices often have several settings groups each of which contain many
hundreds or even thousands of individual settings. Typically such settings are stored within a proprietary
electronic format specific to the relay manufacturer. This is known as a settings file and depending on
the manufacturer can be stored in many different electronic formats, including ASCII, XML, and binary.
Although, in principle such settings could be printed in entirety, and stored in a non-electronic system,
because of the number of settings, it is generally not practical nor desirable to maintain a paper based
system. A further complicating factor that adds to the management burden, is the common practice
of having many versions of settings for a particular device. Such versions might include temporary
settings for emergencies, historical versions from previous network configurations, design settings, and
the currently applied settings.
Secondly, in addition to the relay settings files, it is a common need to store other related documentation
that is useful for those concerned with the management of the protection relay. Such documentation
might include design documents, test reports, substation single line diagrams, relay manuals, and ap-
plication notes. It is convenient to have such documents organised along with the relay settings such
that they are easy to find and access.
A third requirement for settings management is that the information should be easily accessible. Fur-
thermore, the way the data is accessed must support collaboration between personnel, and support
multiple people using the software simultaneously. Such information should also be easily updated to
reflect the most up to date and accurate information about the real system. Since the advent of the
internet, the most logical way to meet this need is with a web based system.
The fourth requirement of the settings management system is the implementation and support of the
organisations settings process workflow. This is known as the device lifecycle in StationWare. A device
lifecycle defines the current state of every setting within a device allowing a user at a glance to determine
what settings are current, in development, historical, or used for other purposes such as emergencies.
By defining and managing transitions between different states, the settings workflow can be established
and enforced. In its most basic form, a settings lifecycle might consist of only three states: a plan-
ning/design state where proposed settings are developed, a review state where settings are checked
for consistency and approved, and an applied state which represents the current settings on the device.
Each of the basic states can be refined and divided into sub stages depending on the complexity of
the desired workflow. This concept of a lifecycle is deeply integrated into StationWare and settings
management.
The fifth requirement of the settings management system is that it should be manufacturer agnostic.
One of the challenges of settings management is to provide a repository that adequately manages the
settings from multiple different relay vendors. If this is achieved, the settings management system can
provide a common interface irrespective of the device type.
The final requirement of the settings management system is that it should support the import and export
of settings information from multiple vendor platforms. This is necessary for numerical relays because
the volume of settings means that it is not a realistic option for more than a handful of such settings to
be transcribed manually.
Another related aspect of the final requirement is the ability to interface with an analysis tool that sup-
ports detailed power system analytical functions. This enables the processes around settings design
and verification to be easily integrated with the settings database which in turn offers productivity gains
in the settings development and analysis process.
StationWare was developed specifically to address these six requirements and all the features within
the software can be related back to one of these.
There are three primary types of objects in StationWare, locations, devices, and settings. These objects
are organised in a hierarchical database that generally mimics the physical structure where the assets
are located in the real world.
In StationWare, the power system is represented in a hierarchy of location types which are in turn based
on several location categories. For example, there might be a location categories Geographic Area,
Scheme, and Bay. Location types derived from the Geographic Area could be Area and Region.
Likewise, there might be location types Transformer Bay, Feeder Bay, and Generator Bay, which
would be of location category Bay.
Using the approach of defining different location categories and types allows for a flexible hierarchical
software model of the power system to be developed that is specific to each organisation.
Location types such as a Region or Area are arranged in a hierarchy. Rules are defined by the
system administrator that determine what dependencies exist and therefore what locations can exist
underneath other locations. However, as the depth of the hierarchy increases, it is typical that the
location would narrow into a more specific area, protection scheme or bay.
In StationWare, the location hierarchy is customisable to represent the most logical structure for each
particular organisation. As a user of the software, such rules are setup by the system administrator
and it is common for each organisation to produce internal documentation that describes the specific
structure. Regardless, the rules are setup within StationWare such that you cannot create a location in
a place where it should not belong.
For more information on working with locations in StationWare refer to Chapter 6. Administrators looking
for further information about customising the location categories, types, and hierarchy in StationWare
refer to Chapter 18.
Typical devices that are modelled within StationWare include relays, current transformers, voltage trans-
formers, and circuit breakers. In StationWare these are known as device categories. The intention is
that the software exists as a repository for those devices that require settings. However, it is often useful
to have other electrical information about associated devices in the system and therefore StationWare
allows the definition of other types of devices such as transformers.
All devices must reside within a location in the StationWare hierarchy. The locations that can hold
devices are setup by the system administrator and typically these would be location types such as
substations, feeder bays, and transformer bays.
It is usually the case in a deployed StationWare system that there would be many different relays from
multiple manufacturers, and these relays are modelled as separate device types. For example, it might
be the case that you wish to store settings for a SEL-351 relay and an Schneider P543 relay in the
StationWare database. The manufacturer specific variants would be known as device types but they
would both have the device category of relay.
For more information on working with devices in StationWare refer to Chapter 7. For information regard-
ing the administration of device categories and device types, refer to Chapter 13.
In StationWare settings are always stored underneath a device, and consequently the format of the
settings is defined by the device type. The settings format determines such things as the number of
settings groups, what chapters exist within each group, and the parameters that exist within each chap-
ter. Each settings parameter in StationWare allows for the flexible definition of its name, description,
unit, range, and possible value.
Whether the device uses a static or dynamic device model, determines if individual settings param-
eters are defined within each group, with a pre-defined default value, or whether settings parameters
along with appropriate descriptions and ranges would be created on the fly by the device settings
converter. It is the recommended approach for complex numerical relays with many thousands of set-
tings, that a dynamic device model is used and settings are always imported into StationWare using the
associated converter.
For more information on working with settings in StationWare refer to Chapter 8. Administrators who
would like more information on settings converters should refer to Chapter 24.
StationWare is a web based software. This means that the interface to the software is through a web
browser such as Internet Explorer, Mozilla Firefox, or Google Chrome. The web browser is responsible
for rendering the page graphics and due to slight implementation differences within each browser, the
display of StationWare of things such as colours, fonts, width of text boxes, and input fields can appear
slightly different. However, in all cases the general structure and functionality will be the same.
It also means that many of the controls in the software are implemented as links rather than buttons
which are typical in a classical windows application. There are however still places in the software where
the more traditional buttons are used. For example, when selecting documents to add in the additional
documents tab of a location, device, or setting.
Section tabs These allow the user to select an appropriate area of the software for further navigation.
Start is the My StationWare page. The Hierarchy area allows the user to navigate the location
hierarchy.
Navigation/current location This row displays your current location in the database. It is helpful to
keep this in mind, because the available actions and location specific tabs down the bottom of the
screen change depending on the specific properties of the location.
General functions These are general functions such as Change password that can be accessed at all
times.
Object attributes This area shows the attributes of the object (location/device/setting) that you are
currently viewing. These will change depending on the object type that is being viewed. The object
attributes are structured in built-in attributes and additional attributes. Settings have imported
attributes as well.
Note: The basic objects (location/device/setting/process/task) have a system generated unique
ID number. This ID is displayed as first object attribute in the object header. The object ID
can be used for the general search function in the page header and for the interface between
StationWare and PowerFactory.
Actions box This box shows the available actions that can be applied to the currently viewed object.
Like the object attributes, the available actions change depending on the object type that is cur-
rently being viewed.
Location/device specific tabs These tabs show sub-locations contained directly within the currently
viewed object. For instance, documents such as a substation single line diagram or a photograph
of the substation can be stored within the additional documents tab.
The common part of StationWare is the main section as shown above. For general navigation within
the software, it is recommended to use the navigation links (the tree and navigation row) rather than the
browser back and forward buttons. The browser buttons will work, however, due to caching of the pages
they do not always show the latest changes, especially if another user has modified information on one
of these pages, which is quite possible when the system is accessed by many users simultaneously.
Should you use the browser back or forward buttons, pressing F5 on your keyboard at any time will
refresh the window and ensure that the latest information is shown.
The user is encouraged to refer to Part II for more detailed information about the user interface.
This chapter outlines the basic methods of navigating and searching the StationWare database using
the web interface. The following basic functionality is explained:
Before you can begin productive work in StationWare you must login to the system.
To login:
1. Open up your browser of choice. StationWare supports all W3C standards compliant browsers.
2. Enter the url for your StationWare installation. If you dont know this, contact your system admin-
istrator. The StationWare login page should appear as illustrated in Figure 5.1.1.
3. Enter your username.
4. Enter your password.
5. Click Login.
Note: The preceding instructions only apply to cases where StationWare is not setup to use Active di-
rectory. When using Active Directory login would be automatic based on your domain credentials.
Furthermore, many organisations also place StationWare within an additional security layer such
as Citrix that requires further authentication protocols. If unsure, please contact your system
administrator for further information.
5.2 My StationWare
The My StationWare page is a user specific page. It opens automatically after the user login. My
StationWare includes the user specific information sorted in the following tabs:
Recent Places This tab is the default tab of the My StationWare page. It displays the last 30 visited
objects including locations, devices, and processes.
My Settings List of all settings that are assigned to the user as owner. Note, that expired settings are
highlighted in this list.
My Tasks List of all tasks that are assigned to the user as owner. Note, that expired tasks are high-
lighted in this list.
Note: Owner is an attribute of the settings/tasks and is listed in the settings/tasks header. There are
relevant and other users selectable as owner. Relevant users have Write access on the lifecycle
phase, the settings/tasks, and location.
The most common way of moving through the StationWare database is to use the tree structure. This
behaves similar to a standard file explorer that is found on most computer operating systems. The tree
structure can be accessed by clicking the Hierarchy tab. An example tree is shown in Figure 5.3.1
Clicking the Hierarchy tab always returns StationWare to the default (root) view of the entire tree. To
show locations at a level below the root level, you can click the icon to expand the tree structure
below one of the root locations. Alternatively, clicking the location name will take you to a detailed page
of the location, and sub-locations will be shown in the Sub locations tab towards the bottom of the
screen.
Sometimes it is useful to have a view of the tree structure in a hierarchical form at all times when viewing
details of devices and locations deeper within the StationWare tree. This is possible using the dedicated
Navigator window.
The Navigator can be started by clicking the Navigator link from the top right of the StationWare inter-
face. A new web browser window will appear.
The Navigator can be closed by closing the web browser window containing it.
Clicking the icon will expand the Navigator tree to show the sub-locations within the clicked location
icon.
Clicking the location name will take the main StationWare window to the detailed page for that location.
Maintaining the Navigator window and the main StationWare window side-by-side is a practical way of
using the StationWare system.
Searching is one of the most common operations, particularly in large protection settings databases
where there are typically hundreds, perhaps thousands of individual locations and devices. In many
cases searching for a location or device is faster than direct navigation, particularly if you know a device
or location name but are not quite sure where it is located in the hierarchical tree.
StationWare has four different types of searches and these are explained in this section:
The ID search is used for searching for locations, devices, settings, processes, or tasks by ID. This
search function supports searching for the system generated unique ID number of an object as well as
the foreign key of an object. If an object number exists as a system generated unique ID number and
for another object as a foreign key, the result depends on the configuration within the web.config file.
Refer to the StationWare installation manual for further information on the web.config file options. To
search explicity for the system generated ID it is possible to enter ID: before entering the number. The
prefix FK: can be used to search explicity for the foreign key of an object. Wildcards such as * and
? can not be used to search for number patterns. The complete number must be entered.
Searching for the system generated unique ID number or the foreign key of an object
To search for the system generated unique ID number or the foreign key (exact match) of a location,
device, settings, process, or task object:
1. Enter the complete system generated unique ID number or foreign key of the object in the search
field placed in the page header.
2. Click to start the search. If an object with the entered number exists, this objects detail page
will be opened. If not, the message not found is displayed.
The basic search is used for searching for locations, devices, settings, processes, or tasks by name.
No complex logic is supported by this search but it has the benefit of being fast. Wildcards such as *
and ? can also be used to look for name patterns.
To do a basic search (exact match) for a location, device, settings, process, tasks object:
1. From a location in the database click the Search tab. The Search for page will appear.
2. Enter the name of the object that you wish to search for. Note that the search is not case sensitive.
3. Click Search to start the search. Note, that depending on the level in the database where the
search began, it may take some time. After the search is finished a list of the locations, devices,
settings, processes, and tasks will appear below the search box.
Note: The basic search described above requires an exact (although case insensitive) match to the
entered search string. If you want to search for only part of a name refer to the instructions for the
pattern search below.
Pattern search
Often it is useful to return a set of results that match a certain pattern. For example, you might want to
list all the locations and devices that contain green as part of their name. This is known as searching
by pattern. In StationWare, the pattern delimiter is the asterisk * which means match zero or more
characters.
1. From a location in the database click the Search tab. The Search for page will appear.
2. Enter the pattern names of the object that you wish to search for. For example, to search for all
locations and devices with green somewhere in the name, enter *green* in the search field.
3. Click Search. Note, that depending on the level in the database where the search began, it may
take some time. When the search is finished, a list of the locations, devices, settings, processes,
and tasks that match the search pattern will appear below the search box.
Examples:
*green This will locate all objects with green at the end of the name. For example Walgreen. It would
not match those objects with additional characters following the green, such as greenfield
green* This will locate all objects with green at the beginning of the name. It would therefore match
greenfield but not Walgreen.
*green* This will locate all objects with the letters green anywhere in the name. It would therefore
match both Walgreen and greenfield.
Wildcard search
Sometimes it is useful to complete a search with only a single wildcard character. For example, you
might want to search for everything in the database with the name green but with one appended
character, such as green1, green2, greena etc. The symbol for a single unknown character in the
search is the question mark ?.
1. From a location in the database click the Search tab. The Search for page will appear.
2. Enter the pattern names of the object that you wish to search for. For example, to search for all
locations and devices with green in the name, and a single character afterwards, enter green? in
the search field.
3. Click Search. Note, that depending on the level in the database where the search began, it may
take some time. After the search is complete, a list of the locations, devices, settings, processes,
and tasks will appear below the search box.
Note: There is a setting in the web.config file for StationWare that allows StationWare to automatically
add wildcards for the basic search. For more information on setting the auto-wildcard parameter
in the web.config file refer to the StationWare installation manual.
A search can be started from any location in the database tree by clicking the search tab. Note that the
location where the search starts from is determined by the location where the search tab was clicked.
This means that if is desired to start a search only in a particular branch of the tree, you should first
navigate to that location. Likewise, if it is desired to search the entire database, you should click the
search tab after first clicking Hierarchy.
The standard search is used for more detailed searching of the StationWare database. In particular,
when it is desired to search for objects based on their attributes, rather than just their name as is the
case for the basic search.
The standard search consists of a list of search fields which change depending on whether the target
for the search is a Location, Device, or Setting.
Location types Select the type of location to search for. Note the available types, depend on the types
defined by the system administrator. For example, Region or Substation are typical location
types. It is compulsory to select a location type.
Location Name This field is always visible. If left blank, then the search will return all locations of the
type selected. Otherwise, depending on what is entered into the field, and the dropbox selection,
the search will selectively filter objects.
Other fields The location search will display other fields depending on what additional attributes were
assigned to the location types. The meaning of the = (exact match), or Pattern (* and ?
wildcards) is explained in section 5.5.5.
Device categories Select the device category to search for. For example, this could be CT or a
specific relay model like a SEL-321. If All Devices is specified then the results will not be filtered
based on device category.
Device name This field is always visible. If left blank, then the search will return all devices of the type
selected. Otherwise, depending on what is entered into the field, and the dropbox selection, the
search will selectively filter objects.
Other fields The device search will display other fields depending on what additional attributes were
assigned to the device types. The meaning of the = (exact match), or Pattern (* and ?
wildcards) is explained in section 5.5.5.
When completing a standard search, if any of the non compulsory fields is a string, it will by default have
a dropdown box next to the additional attribute that will look like Figure 5.5.1 or Figure 5.5.2.
Figure 5.5.1: Standard search options when searching for an exact match of a string
Figure 5.5.2: Standard search options when searching for a string pattern
If you leave the field next to this blank, then this field is not considered by the standard search. However,
if you enter any text string into the field next to the dropdown box, then the search will filter all values so
that only those with an exact match will be returned from the search. This search is not case sensitive.
For example, say there are the following regions defined in the database:
Australia
Chile
China
France
Greece
India
New Zealand
South Africa
United Kingdom
then an exact match search for regions with G entered into the field will return nothing. On the other
hand, if instead a Pattern (* and ? wildcards) search was completed then United Kingdom and
Greece would be returned. Wildcards * and ? can also be used to further refine the search. It is
noted that the standard search is not case sensitive.
The advanced search is used for complex searches that cannot be achieved using the simple or stan-
dard search. For example, it might be necessary to search individual settings objects for particular
parameter values.
The advanced search uses a dynamic configuration that depends on the object type that is being
searched for. To begin the search you must choose either:
After selecting one of the above fields, the search page will change to show a list of parameters relevant
to the particular class of object that has been selected. These are the attributes that appear on the
device/location/setting details page when navigating to that particular object. The drop down menus
and search fields behave in much the same way as described in the standard search parameters (sec-
tion 5.5.4), either an exact match can be searched for or wildcards can be entered to allow for a broader
pattern based search.
If a settings advanced search is selected the field Imported Attributes will be available. Imported
attributes are settings attributes that are imported with the import of a manufacturer specific settings
file, e.g. MLFB, DeviceLanguage, FirmwareNumber. It depends on the manufacturer specific settings
file and the converter, if imported attributes are displayed or not. Figure 5.5.3 shows an example of the
imported attributes MLFB, DeviceLanguage and FirmwareVersion.
Figure 5.5.3: Example showing the MLFB, DeviceLanguage and FirmwareVersion fields in a Siemens
device
To search for such settings attributes is possible by using the Imported Attributes field in the advanced
settings search.
Note: The usage of wildcards is neither allowed for the imported attribute name nor the value of the
attribute. The name and value has to match exactly otherwise no results will be found.
Locations
In StationWare there are three basic kinds of objects within the tree structure:
This chapter discusses locations and actions that can be completed on a location.
A location in StationWare is a software representation of a physical location. They are used primarily
to organise the StationWare tree in a hierarchical structure that becomes meaningful to users who are
familiar with the system being represented. Locations are also used to enforce location rights and help
control who has access and what actions are allowed in each area of the tree.
Typical examples of locations include Areas, Regions, Substations, and Bays. Although the types of
locations available in StationWare depends on the way the system is configured by the administrators.
From an administrative perspective it is useful to understand that locations are defined through the use
of location categories and location types. The latter is all that is presented to the user during regular
access of the database. More information about configuring location categories and types can be found
in chapter 18.
When you enter the details page of a location, the screen that is presented looks typically as shown in
Figure 6.1.1. The highlighted areas include:
Location additional documents are a place to store any additional electronic documentation that is rele-
vant to the particular location. For example, it might be useful at a substation location to have a single
line diagram schematic of the substation, and possibly some photographs. The Additional documents
tab is the ideal place for this.
7. Optional: Enter a foreign key. For example, this might be a link to an internal document manage-
ment system that has the latest version of the file.
8. Click Browse and select the desired file. It is also possible to select multiple files at once.
9. Click Submit.
1. Click the Additional documents tab. A list of available additional documents for this location will be
displayed in a tabular format.
2. Either:
(a) Click the document name. The document will immediately download.
(b) Click the View. . . link in the Actions column. The document will immediately download.
1. Click the Edit. . . link. A new window will appear showing the details of the additional document.
2. Edit the fields as desired.
3. Click Submit.
Note: Editing the additional document does not change the document itself, only the properties of the
document recorded within StationWare. To change the actual document use the Update. . . link.
1. Click the Delete. . . link. A confirmation dialog will appear. Note this will delete all versions of the
file.
2. Click OK.
1. Click the Versions. . . link. A new window will appear showing all the available versions in a tabular
format. Note that this link is only visible if the document has more than one version.
2. Click the View. . . link. The document will immediately download.
Location notes are a place to create and store text notes. The notes are visible directly in the browser
window on the Notes tab of the location and hence are slightly easier to access and see than additional
documents which must be downloaded first.
Notes can be used to draw attention to any special features of a location that other users should be
aware of.
After clicking the Notes tab, all notes for that location are shown in table form. Only the first 256
characters of the note are displayed in the note description column.
3. Click the Delete. . . link in the Actions column. A confirmation window will appear.
4. Click OK.
3. Click the View. . . link in the Actions column. The full text of the note will appear.
4. Click Submit.
Location links are used to provide a place where useful web links can be entered. These might include
links to:
Note: An internet address link in StationWare could also be a local intranet address, StationWare does
not distinguish between them.
5. Click Submit.
4. Click OK.
The audit trail shows the history of the location, device or settings object. It is therefore an useful way
of checking the historical development of attributes at a location, and if errors have occurred, it can be
used to determine exactly when the error happened.
The functionality of the audit trail with regard to settings is explained in section 8.6. There is an important
difference in the audit trail functionality when applying it from the location level, compared to applying
it at the settings level. The audit trail does not drill down into lower levels of the database hierarchy,
consequently when selecting the audit trail at the location level, you will only see historical changes to
the location attributes, not to devices or settings within that location.
3. Optional. Uncheck the tick boxes for types of objects/parameters that you dont want to show in
the audit trail. For example, if you only want to show changes to the location Attributes then you
should only tick the box next to this option.
4. Either:
(a) Enter a date range to reduce the size of the audit trail to only show modifications within the
selected date range. Or:
(b) Select number of days, and choose an options from the selection control to show the audit
trail for a specified period prior to the current date and time.
Note: The last audit trail filter configuration is stored in the session and applies to all audit trail filters
during a session. Restarting the browser ends in the default audit trail filter configuration. This
default configuration includes all types of objects/parameters and the Number of days is set to
30Days.
Various actions, depending on the rights granted by the system administrator are possible at the location
level. If you do not have permissions for a certain action it will be greyed out. The following sections
discuss the possible location actions.
The Create location (or sub-location) action allows you to create a new location immediately underneath
the location where you clicked the action. To create a location or sub-location:
3. Select the Type. Note the available types depend on those configured by the StationWare admin-
istrator.
4. Enter a name.
The Edit location action allows you to alter the attributes of the location. This includes:
1. Click the Copy. . . Actions link. A new window will appear showing you the StationWare tree.
2. Enter the new location name.
3. Optional: Select the target location that will become the copys parent.
4. Optional: Tick Copy sub locations to also copy the sub locations of the copied location.
5. Optional: Choose which settings should be copied.
6. Optional: Select a user as owner for the settings.
7. Select the settings expiry date. Note that the expiry date is only available (and then mandatory),
if the New settings status includes this enabled option in the lifecycle phase definition for the
StationWare device lifecycle.
8. Optional: Select the settings status for the new settings.
9. Optional: Enter a status change date.
1. Click the Move. . . Actions link. A new window will appear showing the StationWare tree.
2. Select the new parent for the location.
3. Click Move.
Note: Locations can only be moved if they do not contain sub-locations. Administrators can move loca-
tions including sub-locations using the Administrative data move function from the Administration
control panel. See section 19.2 for more information.
Detach is used to temporarily make a location and its sub-locations invisible in the StationWare tree.
This could be used for decommissioning a substation for example. The behaviour of detach is subtly
different to delete, which is a permanent action and cannot be undone. By contrast, detached locations
can be reattached by the administrator at a later time.
To Detach a location:
Note: It is only possible to delete a location if it does not have sub-locations. An administrator can
delete locations including sub-locations using the delete function in the Administration control
panel. See section 19.1 for more information.
In many cases, protection design is completed from so-called standards and templates. These enable
the rapid prototyping of new protection schemes based on already established principles and avoids the
long process of creating all settings from scratch. StationWare supports a similar concept for locations.
For instance a standard substation design including two feeders might look as shown in Figure 6.6.1.
In the StationWare database this actually consists of 7 objects, the substation, the two feeder bays, the
two relays, and two default settings for each relay.
StationWare administrators can create such templates, see section 18.2 for more information.
1. Click the Create location from template. . . link. A new page will appear.
8. Select the tasks expiry date. Note that the expiry date is only available (and then mandatory), if
the template includes tasks with a tasks status of a lifecycle phase definition including the enabled
option Expiry Date.
9. Click Create.
To create a process:
3. Enter a name for the process. For example, Recurring protection device testing.
4. Optional: Enter a description.
5. Optional: Enter a foreign key for interfacing with another software.
6. Optional: Modify the Valid from date/time. The Valid from date defaults to the time you pressed
the Create process. . . link. The Valid from date/time can be earlier than the current time and
affects the time that the process would be visible to when in History mode.
7. Click Create.
1. Click the Create process from template. . . link in the Actions menu.
8. Select the tasks expiry date. Note that the expiry date is only available (and then mandatory), if
the template includes tasks with a tasks status of a lifecycle phase definition including the enabled
option Expiry Date.
9. Click Create.
In locations where devices are permitted, for example substations, the Create device action is visible.
To create a device:
1. Click the Create device. . . action. The device creation page will appear.
It is commonly the case that certain standard protection settings for various schemes exist within an
organisation. These include typical settings for each device that are used as a starting point for devel-
oping new settings. In StationWare, this is supported through the use of location, device, and settings
templates.
A device template can be setup with default settings and attributes of the proposed functionality of the
device which in turn simplifies the settings development process and reduces the amount of manual
data entry.
The StationWare administrator can define device templates. See section 13.3.7 for more information.
1. Click the Create device from template. . . action. The device creation page will appear.
2. Select the device category.
3. Select the manufacturer.
Reports related to locations can also be accessed directly from the locations Actions menu. See
chapter 12 for more information on creating these reports.
Devices
In StationWare a device is one of the three principle object types within the database, the other two
are locations and settings. The database administrator is able to configure many different categories
of device so that all the real devices in your system can be represented by an equivalent within the
StationWare environment. For example, the following device categories can be available within the
database:
Relays
Voltage transformers
Current transformers
Circuit breakers
Lines
Transformers
Your StationWare administrator may also choose to create other device categories that have physical
counterparts in the primary or secondary system.
Of these devices, typically only relays would have settings associated with them and this is the typical
use of the protection settings management system - keeping a database of all relays and their asso-
ciated settings. However, by also using the other device categories in StationWare it is also possible
to keep data and records for the other devices typically associated with the protection system. That
way, StationWare can become the complete repository for all power system protection information in
the utility.
This chapter first provides some additional background of the features of a device within StationWare
and then explains the actions that are possible at the device level.
Note for information regarding the management and configuration of the available devices within the
StationWare database, refer to chapter 13.
A discussion of devices in StationWare must first distinguish between device categories and device
types. The former is a high level container that tells StationWare what kind of devices exist. For
example, relays, current transformers, and voltage transformers. By contrast, the device type tells
StationWare what types of each device are possible in the database. Consider the default category of
Relay. The StationWare database would typically contain many tens, if not hundreds of types of relays.
SEL-421, Siemens 7SA632, GE URL90, and ABB REL521 are all examples of device types.
A device in StationWare is a software representation of a physical device which is based on the device
properties specified in the device type. The majority of devices in the protection settings management
system are relays. However, as mentioned earlier, it is also possible to store information about other
primary and secondary equipment. It can be beneficial to do so for those devices that are typically
associated with the complete protection system.
The configuration of the available device categories, and types is completed by the StationWare admin-
istrator. More information about this can be found in chapter 13.
When you enter the details page of a device, the screen that is presented looks typically as shown in
Figure 7.1.1. The highlighted areas include:
Figure 7.1.1: Device details page (note the attributes shown in your system may differ from that shown
here depending on how your system administrator has configured the software)
Often it is useful to compare different settings objects within the same device. The device Compare tab
is used for this purpose.
1. Click the Compare tab. A list of all settings within the device will appear. Note historic settings,
and snapshot settings that are otherwise not visible will also appear on this tab. This allows for
comparison of the applied settings with previous applied settings.
2. Check the box next to two settings that you wish to compare. Note you cannot compare more than
two settings in the same action.
3. Click the Compare settings. . . button. The window will change to show the comparison table.
Only the settings parameter differences will be listed in the table.
Device additional documents are a place to store any additional electronic documentation that is relevant
to the particular device. Note this is different from the device library that is designed to store documents
for the particular device type. Relay manuals and application guides should as a rule be stored in the
device library. More information on the device library is available in chapter 14.
Some examples of the types of documents that could be stored in the device additional documents
include:
Photographs.
Commissioning notes.
The process for adding device additional documents is identical to the process for adding location
additional documents, please refer to section 6.2.1.
The steps to view device additional documents are identical to viewing location additional documents,
please refer to section 6.2.2.
The steps to edit device additional documents are identical to editing location additional documents,
please refer to section 6.2.3.
The steps to update device additional documents are identical to updating location additional docu-
ments, please refer to section 6.2.4.
The steps to delete device additional documents are identical to deleting location additional documents,
please refer to section 6.2.5.
The steps to view old versions of device additional documents are identical to viewing old versions of
location additional documents, please refer to section 6.2.6.
Device notes are a place to create and store text notes. The notes are visible directly in the browser
window on the Notes tab of the device and hence are slightly easier to access and see than additional
documents which must be downloaded first.
Notes can be used to draw attention to any special features of a device that other users should be aware
of.
After clicking the Notes tab, all notes for that device are shown in table form. Only the first 256 characters
of the note are displayed in the note description column.
The steps to create a device note are the same as the steps for creating a location note, please refer to
section 6.3.1.
The steps to delete a device note are the same as the steps for deleting a location note, please refer to
section 6.3.2.
The steps to view a device note are the same as the steps for viewing a location note, please refer to
section 6.3.3.
The steps to edit a device note are the same as the steps for editing a location note, please refer to
section 6.3.4.
Device links are used to provide a place where useful web links can be entered. These might include
links to:
The Connections tab shows the defined topological connections of a device. The purpose of connec-
tions in StationWare is to allow for more convenient navigation between related objects. For example,
a distance protection scheme would typically involve two or more relays at each end of a line. In the
typical hierarchical view of StationWare, to see the relay object at each of the scheme you would have
to navigate to the containing location for each relay (probably a substation or bay). Connections allow
the creation of a direct link between the two devices, represented perhaps by a signalling connection
between them.
An example of a primary connection is the connection between a disconnector and a circuit breaker.
If the connection cannot be modelled with a simple one-to-one relationship, for example a transformer
that connects to multiple lines, then a connectivity node object can be created to manage the multiple
connections.
An example of a signal interconnection is the connection between the voltage transformer and a relay.
Another example would be the connection/s between the relay and the circuit breaker/s that it trips. An
example signal connection diagram is shown in Figure 7.6.1.
Note: The types of connections possible for a device depend on how that device model has been con-
figured by the system administrator. See section 13.6.2.4 for more information.
Figure 7.6.1: Example diagram illustrating the connections between a CT, VT, CB, and relay.
4. Navigate to the target device and click it. Depending on whether you are connecting a signal or
primary connection you will then be presented with one of two options:
If the connection is a signal, then choose the target signal within the target device from the
drop down list.
If the connection is a primary connection, choose the terminal within the primary device from
the drop down list.
5. Click Create.
1. Click . You are prompted to confirm whether you really want to delete the signal.
2. Click OK.
1. Click to show the Connectivity Node which lists the primary connections.
2. Click . You will be prompted to confirm if you would like to delete the connection.
3. Click OK.
The device audit trail behaves similar to the location audit trail such that it only shows historical changes
to the device itself, not to the settings contained within the device. For more information about the
settings audit trail refer to chapter 8.6.
Various actions, depending on the rights granted to you by the system administrator are possible at the
device level. If you do not have the appropriate permissions for a certain action it will be greyed out.
The following sections discuss the possible device actions.
The Edit. . . device action allows you to alter the properties of the device. This includes:
Note: When you edit a device, you lock the device details page until you release the lock by clicking
the Exit edit mode. . . action. When a device is locked, no-one else can modify the device details.
This prevents conflicts if two or more users try to modify the same device at the same time.
1. Click the Copy. . . Actions link. A new window will appear showing you the StationWare tree.
2. Enter the new device name.
3. Select the target location that will become the device copys parent.
4. Optional: Select a user as owner for the settings.
5. Select the settings expiry date. Note that the expiry date is only available (and then mandatory),
if the device includes settings with a settings status of a lifecycle phase definition including the
enabled option Expiry Date.
6. Optional: Select the lifecycle phases of the settings that will be copied with the device. Note, if
you do not check any of the boxes here, no settings will be copied with the device.
7. Choose the status for the copied settings. A planning lifecycle phase must be selected.
8. Optional: Enter the status change date for the copied settings. The default is the system time that
you clicked in the copy device action.
9. Click Copy.
Detach is used to temporarily make a device and its settings invisible in the StationWare tree. This
could be used for decommissioning a relay for example. The behaviour of detach is subtly different to
delete, which is a permanent action and cannot be undone. By contrast, detached locations can be
reattached by the administrator at a later time.
To detach a device:
Note: It is only possible to delete a device if the user is authorized to also delete the contained settings.
Applied, historic, and snapshot settings cannot be deleted. However, an administrator can delete
devices including such settings using the delete function in the Administration control panel. See
section 19.1 for more information.
The Compare to another device. . . action compares the attributes of one device to another. It does not
compare settings. To compare settings use the compare settings actions - see section 8.5.6 for more
information.
1. Click the Compare to another device. . . action. The page will change to show the StationWare
tree.
2. Navigate to the device that you want to compare.
3. Click the device. A table will appear showing a comparison of the device details. The table is
categorised into attributes that are different and attributes that are the same, to allow you to easily
identify any obvious differences.
Note: Device attribute comparison is also allowed between different device types.
1. Click the Create settings. . . action. The settings creation page will appear.
2. Enter a name for the settings.
9. Optional: Modify the status change date if you would like the settings status change to be different
from the time you clicked the Create settings action.
10. Click Create.
Note: For complex numerical relays, it is recommended that settings be created using the device spe-
cific settings converter via the settings import action. Refer to section 7.10.8.
A settings template defines default settings for a device that may differ from the defaults that are
specified in the device type itself. This allows the StationWare administrator to define several different
settings profiles for different possible applications of the device. For more information on creating
settings templates refer to section 13.3.8.
1. Click the Create settings from template. . . action. The settings creation page will appear.
2. Choose the template.
3. Enter a name for the new settings.
Settings can be imported from external files in several supported formats. This is the recommended
way of importing settings data for complex multi-function devices with potentially thousands of individual
settings. The available import formats are:
To import settings:
1. Click the Import new settings action. The settings import page will appear.
2. Optional: Edit the name for the new settings.
3. Optional: Select the device firmware.
4. Optional: Select a user as owner for the settings.
5. Select the settings expiry date. Note that the expiry date is only available (and then mandatory),
if the settings status is of the lifecycle phase definition including the enabled option Expiry Date.
6. Select the lifecycle phase for the new settings.
7. Optional: Modify the status change date if you wish the settings initial lifecycle status date to be a
different time to when you initiated this action.
8. Click Browse. A file browser dialog will appear.
9. Select the settings file from a location on your PC or network drive. If the particular settings
converter requires more than one settings file, hold CTRL and select the additional files.
10. Select the type of settings converter. Note if you dont have specific converters installed for a
particular relay type, then the only available converter will be the StationWare Excel File Format.
11. Click Import. A parameter list will appear in the window indicating the status of all imported
settings. It is recommended to check this for any errors that might have occurred during the
import process.
Note: Settings converters are not available for all device variants and are developed on request as
the need arises from customers. However, some converters are included for free within the base
StationWare installation. To obtain a license for additional converters, or to check if a specific
converter is currently available, contact DIgSILENT support.
Reports related to devices can also be accessed directly from the devices Actions menu. See chap-
ter 12 for more information on creating these reports.
Settings
Settings, or more formally settings objects, are one of the three primary object types within the Station-
Ware database. The other two are locations and devices.
This first part of this chapter provides some background of the features of settings within StationWare
and how they are represented internally within the software. The second part of the chapter explains
how to work with settings and the possible actions that are available.
In StationWare a setting must belong to a device, typically a relay. Although other categories of device
can also contain settings, it is normally the relays that contain the most complicated settings and also
the majority of settings information in the protection settings management system (PSMS).
Because settings are always located within a device, the device defines the format and also the structure
of the settings. The following paragraphs explain the structure of the internal representation of settings
within StationWare.
The highest level of the setting structure within StationWare is the settings object. Settings objects
can be seen as a list of links within the device underneath the Settings tab as shown in Figure 8.1.1.
A settings object always has a status which is defined by the settings lifecycle phase. The settings
lifecycle is discussed in further detail in section 8.1.3.
Figure 8.1.1: Settings tab within the device showing the list of settings objects and their current lifecycle
status
The settings object defines one or more groups that are displayed as a list of tabs across the screen
when the settings object link is clicked. Each group is further divided into settings chapters. Chapters
are not mandatory, although they are usually included to improve readability of the settings. Finally, the
settings parameters, what are typically referred to by the engineer as the settings, are shown within
each chapter. A settings parameter has several properties:
Name;
Description;
Value (the actual setting);
The overall hierarchy of the settings object is illustrated within Figure 8.1.2.
As an example, consider the MiCOM Alstom P543 distance relay. The relay has a settings parameter
Line Impedance within a group named Group 1. The settings parameter is part of a chapter named
GROUP 1 LINE PARAMETERS. For the purpose of this illustration, lets say that it also has a value of
17.23 Ohms.
Group - Group 1
Chapter - GROUP 1 LINE PARAMETERS
Parameter Name - 30.03 (this is the internal settings property designation)
Parameter Description - Line Impedance
A screenshot showing the view of a StationWare settings object with a group, chapter and a parameter
highlighted is shown in Figure 8.1.3.
Throughout the rest of this chapter the word settings means the StationWare settings object, whereas
parameter refers to one of the actual device settings parameters, for example Line Impedance.
For electromechanical relays and other primary equipment where the number of individual settings is
limited to perhaps less than 50, it is practical to define the settings structure directly in StationWare
through the device model. In StationWare this is known as a static device model. Internally within the
software model of the relay in StationWare this means that the structure of the defined settings param-
eters is immutable - it cannot be altered by a settings converter during the import process. Settings
parameters values can be altered, but not what values exist.
An example of a device that would be appropriate to model with a static device model description is
the CDG family of electromechanical relays. The settings are a property of the device, rather than the
device electronics or firmware.
In contrast to electromechanical relays, modern numerical relays typically contain many thousands of
settings. Furthermore, the settings, and permitted ranges of the settings often vary for different firmware
variants of the same model. Consequently, it is not practical to define a static device model for such
relays. Of course, it can be done, but developing such a device model would introduce a high overhead
in creating the model and maintaining variants for different firmware revisions.
To simplify the process of modelling numerical relays, StationWare supports the representation of set-
tings using a dynamic device model. Such a model does not have any permanent chapters, or settings
parameters, rather just a set of Groups. The settings chapters and parameters are added on the fly
by a settings converter specific to the relay model or relay model family..
The settings converter takes a relay Original Equipment Manufacturer (OEM) file, reads it, creates the
StationWare settings definition including all chapters, and settings parameters and then populates the
internal StationWare settings object with the parameter values.
Settings converters are licensed separately to the main StationWare application and are provided as
add ons to the software. Due to the vast number of relay types currently available, converters are
not available for all devices and are developed by DIgSILENT as requested. Contact DIgSILENT (See
chapter 2) to obtain the latest list of available converters, to obtain a license for a particular converter,
or to enquire about the development of a new converter.
More information about device settings converters is also available within chapter 24.
A fundamental aspect of settings management is the need to keep track of multiple settings for each
device. This is because during the normal lifecycle of the device, it will have many different settings
depending on how the system changes, but more importantly to cope with emergency situations.
Beyond this need, there is a need to keep track of the historical evolution, or work-flow of how a particular
settings came to be applied to a relay. Consequently, many utilities keep historical records of design
and review settings. This is particularly important because it is seldom the case that the same individual
would be responsible for developing, approving, and applying the settings in the field. Consequently if
a settings error occurs, the multiple settings records can be compared to see where the error was
introduced and steps can be taken to ensure that the risk of such errors is reduced in the future.
In StationWare, the concept of the settings workflow and settings status is enforced with the device
lifecycle. The lifecycle is implemented at the settings level where every settings object has a so-called
lifecycle phase. An example lifecycle is shown in Figure 8.1.4.
The lifecycle consists of a number of phases (states) that settings may have. These phases are divided
into four primary classes:
Planning
Review
Applied
Historic
The following sections provide some additional information about each of these phase classes.
The planning phases, coloured blue, are designed to represent the early stages of the settings devel-
opment process. These could be early design settings, settings that are used for analysis purposes in
other software packages (PowerFactory for example), or just settings that the designer wishes to have a
place-holder for. Typically these settings undergo frequent large changes and would not be considered
reliable for applying directly to a device in the field.
There is no built-in restriction on the number of planning phases that a device can have, with the
exception of the PowerFactory phase for which there can be a maximum of one. However, it is possi-
ble to limit the number of particular planning phases by creating additional lifecycle constraints. See
section 13.5.4 for more information about managing and creating lifecycle constraints.
The review lifecycle phases, coloured yellow, typically come after the planning stages in the settings
lifecycle process. These are used to indicate settings that have typically passed the initial design phase
and must now undergo further quality checks. The change from a settings phase of planning to review,
often also marks the time that the settings designer hands responsibility of the settings over to a settings
reviewer. Review phase settings are seen therefore as candidate settings to be applied to the device
in the field and typically they would not undergo large modifications compared with planning settings.
All changes made to review phase settings in StationWare are logged and can be viewed through the
settings audit trail. Refer to section 8.6 for more information on the audit trail.
The applied phases represent settings that are active on the physical device and therefore represent
the current state of the device settings in the power system. Consequently, applied settings cannot be
modified or deleted, they can only be replaced by new applied settings. Furthermore, a device may
only have one applied settings. It is very important to keep accurate records of the applied settings,
and to maintain these records for historical purposes, hence applied settings have a special status
within StationWare.
Applied settings are always retained within the StationWare system. When a device gets new applied
settings, the old applied settings become historic. Please note that each applied settings phase
should be followed by a historic phase. Historic settings can be viewed through settings comparison,
or in the history mode. See chapter 10 for more information on the history mode.
There are also some secondary lifecycle states that StationWare uses to add additional functionality to
the device lifecycle. These include the following phases:
Initial
Delete
Historic
PowerFactory
The Initial phase is a placeholder to indicate to StationWare what the permitted initial states of a setting
are when first created. The transitions from initial to other (usually planning type phases) indicate the
permitted initial state of settings. For example, in Figure 8.1.4, when a settings is first created, it can
only have either the Planning (in this example planning is a specific phase as well as an overall class)
phase, or the PowerFactory phase, both of which are planning type phases. A settings can never
have the phase Initial.
Because it is necessary to tell StationWare when settings are permitted to be deleted, a special Delete
lifecycle phase is available. Transitions from another phase to Delete indicate that it is permitted to
delete a setting when it is in this phase. Like the Initial phase, settings cannot be assigned to the
Delete phase. To enable the user to delete a setting, it must have a lifecycle transition from a planning
or review phase to the Delete phase.
Due to the special status of the applied settings, another special lifecycle phase exists called Historic.
A transition from a lifecycle phase to Historic, indicates that a copy of the settings will be retained
indefinitely. Essentially this indicates a snapshot of the settings will be retained when they are replaced.
The PowerFactory lifecycle phase is actually a planning type lifecycle phase. However, it is a manda-
tory lifecycle phase required to enable the import and export of settings to PowerFactory. For the link
between the two software products to work correctly, there can be a maximum of one PowerFactory
lifecycle phase per device. For more information about the PowerFactory- StationWare interface refer
to chapter 22.
Access to settings and what actions users are permitted on the settings are controlled by managing
rights that users have to each lifecycle phase, and to each lifecycle transition. For more information
about configuring lifecycle phases, and lifecycle transitions, refer to section 13.5.
Transitions between lifecycle phases also take on special properties in StationWare. It is possible
to configure which users are permitted to make each transition. For example, consider the settings
designer. In Figure 8.1.4 she is responsible for making the transition of the settings from Planning to
Outstanding, after which the setting becomes the responsibility of the settings reviewer. It therefore
makes sense for the settings designer to be able to make the Planning to Outstanding transition, but
she should be restricted from making the transition to Outstanding and Authorized because the review
phase is not her area of responsibility. Through the management of user rights to lifecycle phase and
lifecycle transitions, the StationWare administrator can enforce the particular settings workflow process
of the organisation.
An administrator can also force the mandatory sending of email messages when a transition occurs,
which allows the next user in the process to be notified that they are now in control of the settings. For
more information about configuring lifecycle transitions, refer to section 13.5.3.
It can also be useful to restrict the number of settings of a particular phase that are permitted to exist
for any given device at one time. One mandatory example of this is for applied settings. It is apparent
that a device in the field can only have one set of applied settings, and therefore StationWare has a
mandatory restriction limiting all device to maximum of 1 applied setting per device.
The administrator, in the interests of keeping the settings management system well organised and tidy,
may decide to also place restrictions on other phases such as Pending. To do this StationWare allows
for the definition of so-called lifecycle constraints which define the maximum number of settings for a
specified phase.
The StationWare lifecycle is completely flexible and the idea is that it should be able to effectively match
the desired settings workflow of any organisation. For more information on the configuration of the
settings lifecycle, refer to section 13.5.
Settings additional documents are a place to store any additional electronic documentation that is rele-
vant to the particular settings. In general this should be used to store only documents that relate to the
particular settings. This could include:
The process for adding settings additional documents is identical to the process for adding location
additional documents, please refer to section 6.2.1.
The steps to view settings additional documents are identical to viewing location additional documents,
please refer to section 6.2.2.
The steps to edit settings additional documents are identical to editing location additional documents,
please refer to section 6.2.3.
The steps to update settings additional documents are identical to updating location additional docu-
ments, please refer to section 6.2.4.
The steps to delete settings additional documents are identical to updating location additional docu-
ments, please refer to section 6.2.5.
The steps to view old versions of settings additional documents are identical to viewing old versions of
location additional documents, please refer to section 6.2.6.
Settings notes are a place to create and store text notes within the particular settings object. The notes
are visible directly in the browser window on the Notes tab of the device and hence are slightly easier
to access and see than additional documents which must be downloaded first.
Notes can be used to draw attention to any special features of a particular setting that other users
should be aware of.
After clicking the Notes tab, all notes for that setting are shown in table form. Only the first 256 characters
of the note are displayed in the note description column.
The steps to create a settings note are the same as the steps for creating a location note, please refer
to section 6.3.1.
The steps to delete a settings note are the same as the steps for deleting a location note, please refer
to section 6.3.2.
The steps to view a settings note are the same as the steps for viewing a location note, please refer to
section 6.3.3.
The steps to edit a settings note are the same as the steps for editing a location note, please refer to
section 6.3.4.
Settings links are used to provide a place where useful web links can be entered. These might include
links to:
Various actions, depending on the rights granted to you by the system administrator are possible at the
settings level. If you do not have the appropriate permissions for a certain action it will be greyed out.
The following sections discuss the possible settings actions.
The Edit. . . settings action allows you to alter the attributes of the settings object. This includes:
Note: When you edit settings, you lock the settings details page until you release the lock by clicking
the Exit edit mode. . . action. When a device is locked, no-one else can modify the settings object
details or the settings parameters. This prevents conflicts if two or more users try to modify the
same setting at the same time.
Change status is used to change the lifecycle phase of the settings. Depending on your rights, this is
how you can advance or retard the status of the settings within the lifecycle.
1. Click the settings object link. The settings detail screen will appear.
2. Click the Change status. . . action. A new status change window will appear.
3. Select the new status. Note, only those lifecycle statuses that you are permitted to change will be
visible.
4. Optional: Enter a status change date. This defaults to the time you initiated the status change
action. This can be useful for example if you wish to enter the actual time the settings were applied
to the device in the field. In many cases you wont be able to update the status in StationWare
until you return to the office, or a place where you can access the system. The status change time
allows you to enter a restrospective time to reflect the actual time the device was updated.
5. Optional: Select a user as owner for the settings.
6. Select the settings expiry date. Note that the expiry date is only available (and then mandatory),
if the new settings status is of the lifecycle phase definition including the enabled option Expiry
Date.
7. Check the checklist items. Checklist items are defined by the StationWare administrator. Contact
him if you are unsure what these mean. To configure checklist items refer to section 13.5.3.7.
8. Optional: Enter a note to indicate why the status is changing.
9. Click Change.
The Copy settings action is used to create a copy of any existing device settings.
1. Click the settings object link. The settings detail screen will appear.
2. Click Copy. . . from the Actions menu.
3. Enter a name for the new settings. It must be unique at the settings level. StationWare will suggest
a name Copy of <copied settings name>.
4. Select the device where you wish to copy the settings to. Note that you are only permitted to copy
settings to devices using the identical device type.
5. Optional: Select a user as owner for the settings.
6. Select the settings expiry date. Note that the expiry date is only available (and then mandatory),
if the new settings status is of the lifecycle phase definition including the enabled option Expiry
Date.
7. Enter the lifecycle status for the settings copy.
8. Optional: Enter a status change date.
9. Click Copy. StationWare will automatically show the detail screen of the settings copy.
The Copy settings group values. . . is used to copy a settings group rather than the complete settings
object. The settings group can be copied to another identical group within the same device, or to another
settings object within a different device of the same type.
1. Click the settings object link. The settings detail screen will appear.
2. Select the tab of the group that you wish to copy.
3. Click Copy settings group values. . . from the Actions menu. A new window will appear.
4. Option 1, to copy to an identical settings group in a different device:
(a) Click the Another device. . . link. The StationWare tree will appear in the window.
(b) Locate the target settings object within the target device that you wish to copy the settings
group to. Hint use the to expand the locations to show the locations underneath.
(c) Click the to show the settings groups of the settings object.
(d) Select the target settings group. It must be the same type as the group you are copying from.
The window will change to show a confirmation question.
(e) Click Copy.
To delete settings:
1. Click the settings object link. The settings detail screen will appear.
2. Click the Delete. . . action. A settings delete window will appear.
3. Click Delete.
Note: Only settings that are not Applied or Historic can be deleted. Furthermore the settings must
be in a lifecycle phase whose following phase is Delete.
Compare to another device is used to compare the currently selected settings with another device of
the same type.
To compare settings:
1. Click the Compare to another device. . . action. A new window will appear showing the Station-
Ware tree.
Click the Compare settings group. . . action is used to compare the settings from the selected group to
another group of the same type within the same settings object, or to another group within a settings
object from a different device.
1. Click the Compare settings group. . . action. A new window will appear.
2. Option 1. If comparing to another settings group within the same settings object:
(a) Select the settings group from the drop down menu.
(b) Click Compare . . . . A comparison window will show a tabular view of the settings group
differences.
3. Option 2. If comparing to another device:
(a) Click the Another device. . . link. A window showing the StationWare location tree will appear.
(b) Navigate to the relay to compare. Note this could be the same device if you want to compare
to a different settings object within the same relay.
(c) Locate the target settings.
(d) Click the target group. A settings comparison window will appear.
Settings can be exported to external files in several supported formats. This is the recommended way
of exporting settings data for complex multi-function devices with potentially thousands of individual
settings. The available export formats are:
To export settings:
The difference in choosing this option, rather than the import at the device level, is that the settings
will be imported and overwrite the existing settings rather than creating a settings object. Hence the
lifecycle phase is not selectable.
Reports related to settings can also be accessed directly from the settings Actions menu. See chap-
ter 12 for more information on creating these reports.
The audit trail is used to inspect the history of changes made to the settings. The following actions are
recorded by the audit trail:
Settings parameters
Of the above changes, only the changes to the lifecycle phase are recorded when the settings are in a
planning type phase. However, once a setting reaches a review phase, then all changes in the above
list are recorded.
To view the audit trail click the Audit trail tab when in the main settings view.
It is also possible to filter the displayed Audit trail list to only include certain categories from the above
list by unchecking the box next to the category name, and then clicking the Filter button.
The audit trail can also be restricted to a date interval by entering a from and to date in the appropriate
fields. Alternatively, the audit trail can be restricted to a period of days preceding the current date. To
do so, select the appropriate option from the Number of days list.
Note: The last audit trail filter configuration is stored in the session and applies to all audit trail filters
during a session. Restarting the browser ends in the default audit trail filter configuration. This
default configuration includes all types of objects/parameters and the Number of days is set to
30Days.
This chapter discusses the application of processes and tasks within StationWare.
The first section will explain some of the background about processes and tasks and what the two
concepts mean within StationWare. An effort will be made to relate the internal representation of these
two objects within StationWare back to a real world process.
When it comes to managing the protection system, besides the settings development and management
there are usually several other types of processes that need to be managed. These include:
Attention to these items is important to guarantee the reliability of the protection system, and hence
many organisations develop detailed processes and tasks associated with each process to assist with
managing and coordinating human resources, test equipment and so forth.
StationWare already includes a detailed device lifecycle that enables the management of the device
settings work-flow process. It hence seems natural to extend this concept to also support other types
of routine processes and tasks such as those mentioned previously, where management of them would
improve overall work-flow, transparency and efficiency. Thus the concept of processes and tasks was
included within StationWare.
StationWare supports multiple separate process lifecycles. These are independent from the device
lifecycle and allow for definition of complex tasks and dependencies according to internal organisation
procedures.
Processes and tasks in StationWare are setup by the system administrator. For administrators seeking
more information about how they are configured, refer to chapter 15.
For explaining how processes and tasks are implemented in StationWare, and how to work with them,
an example process called Routine relay testing is illustrated.
To illustrate with a simple example, a CDG11 earth fault relay will be used. This is an electromechanical
relay with an inverse time trip curve characteristic. The relay comes in multiple variants, and the example
will use a relay with a 20-80 % current setting and a 1.3 s time setting, although this is not important for
the example.
As part of the annual maintenance procedure for such a relay, there is an annual inspection and trip test
that must be completed by a qualified technician. The test procedure is as follows:
On site risk assessment The technician must indicate whether a risk assessment has been com-
pleted.
Personnel competency All personnel must be competent to complete the test tasks.
Confirmation of relay details The firmware version, relay model, and asset ID match the drawings
and test documentation.
Visual inspection The relay visual inspection is complete and the relay is clean and shows no obvious
signs of physical deterioration.
CT ratio check The CT ratio is checked to make sure that it matches the protection settings report.
Trip test The relay is injected with a prescribed amount of secondary current, and the trip time is
reported. This test is repeated three times to get three points on the IDMT curve, to compare with
the theoretical curve.
Curve attached A plot of the test results compared with the predicted results are attached as an addi-
tional document.
An overall process container This usually contains several overview attributes such as whether the
test passed or failed.
Tasks Tasks are contained within a process and are analogous to settings for relays.
Task attributes These are the specific procedures that must be followed as part of a task. Examples
of these are in the preceding list.
Related to the above three components is the assignment of devices and settings to processes and
tasks. It is normally the case that a process would be associated with a device and often a particular
settings of that device, hence in StationWare, part of the procedure for configuring a process and task
involves the assignment of devices and settings to the task.
It is the responsibility of the StationWare administrator to create a process which contains the task which
in turn contains the preceding procedures. The definition of such processes and tasks allows for simple
management and collection of records each time a test is completed. Each year a StationWare task is
created which represents the test procedures to be completed that year. More information on setting up
processes and tasks from an administrative perspective is presented in chapter 15.
Every task in StationWare also has assigned a lifecycle status. The lifecycle associated with a task is
different from the lifecycle associated with settings, and in most cases would probably be simpler. The
idea is that the task lifecycle should enable users of the system to easily establish what is the current
status of the test or process task. For example, in the task example above, it would be useful to know
if the test is complete, whether it is pending, or whether it is scheduled. Such status values can be
represented in a simple process lifecycle like that indicated in Figure 9.1.1.
The process lifecycle is also configured by the StationWare administrator, and the configuration of it is
the same as for the device lifecycle. It contains phases of type planning, review and applied. Refer
to chapter 13.5 for more information on the device lifecycle configuration.
This section describes the available actions when working with processes in StationWare.
1. Navigate to the location where you would like to create the process. Note this is usually the
location containing the device that will later be associated with the process.
2. Click the Processes tab. A table of all existing processes at this location will appear.
3. Click Create Process. . . from the Actions panel. The process creation screen will appear.
4. Enter the process type. Note the administrator is responsible for configuring the available process
types. For more information refer to section 15.3.
5. Enter a name for the process. For example Relay annual trip test.
9. Click Create.
2. Click the Attributes tab. A list of the process attributes should be visible. Note that the process
attributes are defined by the StationWare administrator. For more information on process config-
uration refer to section 15.4.
A device can be assigned to a process. This is independent from the assignment of devices to tasks.
The procedure is however, very similar to the process for assigning devices to tasks. Refer to sec-
tion 9.3.4.
To copy a process:
2. Click Copy. . . from the Actions menu. The copy process window will appear showing the Station-
Ware location tree.
3. Select a target location.
4. Enter a name for the new process
5. Select the type of tasks to copy by checking the lifecycle phase types.
6. Optional: Select a user as owner for the tasks.
7. Select the tasks expiry date. Note that the expiry date is only available (and then mandatory), if
the process includes tasks with a tasks status of a lifecycle phase definition including the enabled
option Expiry Date.
8. Enter the status for any copied tasks.
9. Optional: Enter the status change date. This defaults to the date and time that the Copy action
was clicked.
Administrators can define process templates that are populated with alternative default attributes from
the base process. For more information on the definition of process templates refer to section 15.5.
1. Navigate to the target location where you would like to add a new process.
2. Click Create process from template. . . from the Actions menu. The window for creating the
process from a template will appear.
3. Select the process type.
4. Select the template from the list of available templates.
To delete a process:
To detach a process:
4. Click Detach. The process will be detached and the StationWare focus will return to the parent
location.
This section describes the available actions when working with tasks in StationWare.
It is convenient although not mandatory to assign devices to tasks. This is useful for example if you
consider a relay testing task. It would be beneficial to have easy access to the relay within StationWare
and also to easily see the tasks associated with a particular relay within a tab from the relay view. All of
this occurs automatically after a device has been assigned to a task.
As for devices, settings objects can also be assigned to tasks. The currently assigned settings are
displayed in the Assigned settings tab when viewing the task.
To copy a task:
To delete tasks:
1. Click the tasks object link. The tasks detail screen will appear.
2. Click the Delete. . . action. A tasks delete window will appear.
3. Click Delete.
Note: Only tasks that are not in a phase of the type Applied or Historic can be deleted. Furthermore
the tasks must be in a phase whose following phase is Delete.
A task template is a task definition that contains a set of default attribute values that are different from
the standard default values of the task. Administrators can create task templates. For more information,
refer to section 15.6.
2. Click Create task from template. . . from the Actions menu. The task creation from a template
window will appear.
3. Enter a name for the task.
4. Optional: Enter a task description.
History mode
Often when considering the performance of the protection system it is useful to be able to understand
the historical development of the settings. For instance, the engineer might wish to know what settings
were applied to a device six months ago and compare these with the current settings. In this way
a more comprehensive management and auditing system can be developed alongside the settings
management system.
Historically, setting records for electromechanical relays were stored as hard copies and filed. This
meant the engineer could always retrieve old settings simply by retrieving the appropriate file. Of course,
with the advent of computer based numerical relays, it was no longer practical to keep hard copies of
settings and such filing systems by necessity had to become computer based. Many such computer
based systems have evolved over time and hence tend to have several problems:
StationWare has many features that address these concerns and that are discussed elsewhere in this
manual. For addressing the need of maintaining historical versions of settings, StationWare has a
feature called history mode, that is discussed in this chapter.
The StationWare history mode functions somewhat like a time machine that allows the engineer to travel
back into the past and view the applied settings of the protection system at that time. This is one of
reasons that an applied setting can never be deleted - it is necessary to keep a permanent copy of the
settings for access by the history mode.
When in the history mode, the most obvious difference is that the StationWare colour scheme is
greyscale. This is easiest way to tell at any time if you are looking at a historical or current view of
the system. The second key difference is that all locations, devices and settings objects are read-only,
and there are no possible actions. The difference between the normal (current) view of StationWare
and the history mode is illustrated in Figure 10.1.1.
Figure 10.1.1: Contrast in the StationWare interface when in normal mode and history mode
The StationWare root location tree generally shows the location tree at its present state. In addition it
shows locations that are detached. The location tree has the following restrictions that apply to all kind
of objects:
If an object was moved it will always be shown at the place where it is at present.
Object properties like Name are always shown as they are at present. E.g. if an object was
renamed it will always be shown with its present name.
If an object was deleted it will not be shown at all.
When accessing a location details page, such as a substation, only devices existing at the time you
logged in are shown (regarding the above restrictions).
When accessing a device details page, the following settings are shown:
Applied settings. Any applied settings at the history mode time are shown as applied. Note
any settings that were applied after the history mode time are not shown.
Historic settings. This includes old settings that have been replaced by new applied settings,
and also any settings where snapshots were made as part of the lifecycle process.
When viewing the settings detail page, you are able to see the settings as they were at the history mode
login time.
(b) Click the button. A new window will appear with a calendar view.
i. Click the date that you wish to use.
ii. Optional: Enter the specific time that you wish to login in the text box.
iii. Click Submit to save the date and time.
4. Click Login. The screen colours will immediately change to greyscale indicating that you have
entered history mode.
To exit the history mode and return to the normal (current) StationWare view, click the Hierarchy tab.
The StationWare colour scheme will return to normal.
Library
This chapter explains the features of the StationWare library. The chapter begins by explaining the
functionality of the library and its purpose and then discusses the instructions for completing common
tasks within it.
The StationWare library provides a storage location for useful additional information and documents.
Normally such documentation is related to devices with manuals and application guides being common
examples of items that might be stored within the library. However, the library is also a general purpose
electronic filing cabinet and folders can be created within it to store any kind of electronic information.
The library contains a built-in folder named device types. Clicking this folder shows a list of all the
available device models in your StationWare system grouped by manufacturer. Internal to each device
model is a sub-folder for each firmware version of the device, and this in turn also has a sub-folder for
each sub-version of the firmware.
Note the built in folder * is a special folder for non relay devices such as CTs and VTs.
Method 1 By clicking the Library tab near the top of the StationWare window. The main library will
show. Note if this link is not visible, then you do not have rights to access the library. Contact your
StationWare administrator to enable this feature. Or,
Method 2 By clicking the icon directly from the device details page.
Method 3 By clicking the icon from the device model page in the Administration area.
Method 4 Clicking the link from the Type, or Manufacturer column in the location details page. In
the former case, the link redirects to the library device page, and in the latter case, redirects to the
manufacturer page.
Note: You cannot edit the Library or Device types library folders. These are built-in folders.
Note: Deleting a library folder will also delete any sub-folders of that folder, and also any contained
documents.
The library search is used to search documents in the library. It also searches within the documents
themselves, so it is possible to search for particular documents containing a specific word or phrase.
3. Enter the search term in the text box. See section 11.3.6 for a description of the search terms.
4. Click Search to start the search. A list of all documents containing the search term will appear in
the window.
Note: The library search must be configured by the administrator by enabling the full text search, see
section 14.2
The syntax used for the library search is based on the Query Parser Syntax of Apache Lucene. For
a full description of the search syntax see http://lucene.apache.org/core/3 0 3/queryparsersyntax.html.
Note that at present the field:query syntax is not supported.
To search for documents containing a single word Type the word as the search term
To search for documents containing all words that start with a particular pattern Enter the pattern,
followed by the asterisk *. For example to search for all words starting with SEL type SEL*.
To search for documents containing two words Use the AND keyword between the two words. For
example to search for all documents containing SEL and AREVA, type SEL AND AREVA.
To search for documents that contain one word or another word Use the OR operator between
the two words. For example to search for documents that contain the word SEL or the word
AREVA type SEL OR AREVA.
The process for adding a document to a library folder is the same as adding an additional document at
another location within the StationWare tree. Refer to section 6.2.1 for further instructions.
The process for viewing a document in a library folder is the same as viewing a document at another
location within the StationWare tree. Refer to section 6.2.2 for further instructions.
The process for updating a document in a library folder is the same as updating a document at another
location within the StationWare tree. Refer to section 6.2.4 for further instructions.
The process for deleting a document in a library folder is the same as deleting a document at another
location within the StationWare tree. Refer to section 6.2.5 for further instructions.
The process for editing a library document in a library folder is the same as editing a document at
another location within the StationWare tree. Refer to section 6.2.3 for further instructions.
The process for viewing old versions of a library document is the same as for additional documents
elsewhere in the StationWare tree. Refer to section 6.2.6 for further instructions.
Unlike additional documents that cannot be moved, a library document can be moved to another folder
within the library. To move a library document:
4. Click Move. The window will close and StationWare will show the new parent folder view.
Links can be created within every folder in the library. Two types of links can be created:
1. Navigate to the library location where you want to create the link.
2. Select the Links tab.
The procedure for adding an internet link to the library is the same as described in section 6.4.1.
Reports
In StationWare reports are used to provide information about aspects of the protection settings database
in a several standard formats including XML, HTML, and PDF. Reports are generated from the Reports
page accessed from the StationWare home page. Database administrators might also choose to define
custom reports according to the specific requirements of the organisation - these reports are developed
in Python and more information about how to develop such reports is described in chapter 16.
This chapter provides a general overview of how to run reports in StationWare. The built-in reports in
StationWare are classified into several different types.
Locations reports
Devices reports
Settings reports
The first case presents a list of all available reports, while the second case shows only reports that can
be run at that particular place in the system.
There are three possible output formats for the StationWare reports:
PDF This is the default option, and presents the report in a formatted PDF document suitable for print-
ing, or for electronic filing.
HTML This format is useful if the report only needs to be viewed electronically. It can be viewed
by any standard web browser. Other word processing software also supports reading HTML
documents, and they can also be edited in such software. HTML reports also contain hyperlinks
to StationWare, so you can easily use these links to navigate to objects within the StationWare
interface.
Native XML This format is the StationWare native format and is useful if you need to retrieve the in-
formation in a structured format for later processing in another application. XML can also be
presented in an acceptable visual manner by some applications, however, the emphasis is on
maintaining the structure, rather than presentation for this report.
To run a report browse to its report page in StationWare, specify the report parameters and the desired
output format, and click the Execute button.
The individual reports and their parameters are described on their respective web page in StationWare.
Administration
Chapter 13
Device administration
This chapter provides information on how to configure and administer the behaviour of any device within
StationWare. There are several related aspects that must be understood before an administrator can
manage devices and these are described in the following sections:
The sections of this chapter are presented in a process order. In other words, before you can upload
a device model, you must first create the device category, followed by the manufacturer. After this is
complete, you could define additional Usages. The device lifecycle can be developed at any time.
However, this section is presented last.
A device category defines the kind of device that can be created and managed within StationWare.
StationWare comes with some built-in categories like Relay, CT, VT, Line and Circuit Breaker. But
StationWare is not limited to these categories only. Administrators can define their own categories
depending upon the user requirements.
Before uploading a new device model, ensure that the category of the device being imported is defined
here.
Note: The StationWare software name may contain only upper and lower case letters, numbers and
underscores, and it must not start with a number.
Note: If a device category is currently being referenced in any device model, then the user will not be
able to delete the device category.
13.2 Manufacturers
A manufacturer, is a StationWare category used to organise device models by their original equipment
manufacturer (OEM). The definition of manufacturers is mandatory before the uploading of device mod-
els. This is because the device model specifies a manufacturer reference.
Every manufacturer has a dedicated folder in the StationWare library (under Library / Device types).
A user with appropriate permissions can add manufacturer specific documents and/or links in these
folders.
This location can also be accessed directly via the Manufacturers page by clicking on the folder icon
next to the relevant manufacturer.
4. Click Submit.
4. Click Submit.
Note: Editing manufacturers will automatically update all the related references across StationWare.
4. Check the box next to all the manufacturers that you would like to merge.
5. Click Submit. A confirmation dialog will appear.
6. Click OK.
Note: Merging manufacturers will automatically update all the related references across StationWare.
4. Click OK.
Note: A manufacturer cannot be deleted if there are device models that reference it. To delete such a
manufacturer all the device models referencing it must be deleted.
A device type is an object which contains the actual model definition of a device (known as a device
model definition).
A device model definition is an xml file which defines a specific type of device, for example a Relay. The
definition also contains the devices properties (like manufacturer, device category, etc.), its main setting
groups and if it is a static model, settings as well.
Existing device types can be found under the Device types page (grouped by device manufacturers)
accessible via the Administration tab. For each device type, its device category, version, an optional
description and link to the library folder are shown.
Every device type has a dedicated folder in the StationWare library (under Library > Device types >
Device manufacturer ). A user with appropriate permissions can add device type specific documents
and/or links within that folder.
This location can also be accessed directly via the Device types page by clicking on the folder icon in
the Library column of the relevant device type.
Note: Not all properties are editable. Currently, StationWare only allows an administrator to change the
Obsolete flag of a device type.
Warning: Deleting a device type will delete all the devices currently referenced by it.
3. Click the Export device type as xml file. . . link under the Actions pane.
4. Click Upload.
Note: Please refer to section 13.6 for more information on how to create device model definition XML
files.
13.3.6 Firmware
Firmware, as the name suggests, defines a firmware of a device. Each firmware can further have
different subversions (in incremental order starting from 1).
3. Click the Create firmware. . . link under the Actions pane. A new window will appear.
4. Enter a name.
4. Click the Delete. . . link under the Actions pane. A confirmation dialog will appear.
5. Click Delete.
Note: If a firmware is currently being referenced in any device settings, then the user will not be able to
delete it.
Device templates can be used to create new devices quickly based on a specific configuration.
An administrator can define a Usage of the device and also assign values to any additional attributes
within the template.
In addition to that, StationWare automatically creates a set of default settings (defined in the model
definition) within the template. Administrators have the ability to update the settings (either manually or
via any built-in converters) including any custom and additional attributes, additional documents, notes,
links and even assign a certain lifecycle phase to the setting.
4. Enter a name.
5. Optional: Enter a description.
6. Optional: Enter a foreign key, a unique ID.
7. Optional: Select a usage. See section 13.4 for more information about Usages.
8. Click Create.
4. Click the Delete. . . link under the Actions pane. A confirmation dialog will appear.
5. Click Delete.
Settings templates are used to define settings based on device usage and firmware. The purpose is to
create a default settings based on a particular device usage. After a settings template is defined, users
can utilise it when creating a new device based on a specific usage.
Administrators can modify the settings defined within a template (either manually or via any built-in
converters) including custom and additional attributes. A default lifecycle phase cannot be specified as
part of a settings template, this is selected by the user according to the normal procedure explained in
section 8.5.2.
4. Click the Delete template settings. . . link under the Actions pane. A confirmation dialog will
appear.
5. Click the Delete button to delete the template.
4. Refer to section 8.5.6 for more information on comparing settings with another device.
To copy a settings group values to another settings group of the same kind (within a settings template):
Settings views can be used to group important settings in a tab on the main settings page, based on
device usage and firmware. The settings can either be manually defined or imported using a special
import function. The view will be visible on all settings pages including device template settings.
This function is useful if for example you want commonly viewed settings to be easily visible to users
without them having to scroll or search through a large number of other settings within a group.
4. Enter a name.
5. Optional: Enter a description.
6. Optional: Select a usage.
7. Optional: Select a firmware.
8. Click Create.
9. Refer to section 13.3.9.2 to add settings to the view.
(a) Click the Import. . . link under the Actions pane. A new window will appear.
(b) Click the Browse button and select the desired file. Refer to section 13.7 for a description of
the file format.
(c) Click Import.
7. To delete settings from the view:
Note: The above described function to import the settings view parameters in an existing settings view
overwrites parameters that already exist in the settings view. Only newly imported parameters are
included in the settings view after this import.
4. Click the Delete. . . link in the Actions pane. A confirmation dialog will appear.
5. Click Delete.
6. Click Copy.
13.3.10 Annotations
Annotations can be used to provide additional information for individual settings parameters. This ad-
ditional information is different from the settings description and will be displayed in a separate column.
Annotations can be customised based on a specific usage and/or a firmware version. The annotations
can be manually defined or imported using a special import function.
4. Click the Delete. . . link in the Actions pane. A confirmation dialog will appear.
5. Click Delete.
3. Click the Import settings views and annotations. . . link in the Actions pane. A new window will
appear.
4. Click Browse and select the desired file.
5. Click Import.
Note: Please refer to section 13.7 for more information on how to create the import file.
Note: Not selecting usage or firmware will only export settings views and annotations with no usage or
firmware defined.
13.3.13 Connections
With connections, it is possible to specify a list of primary and input-output signal connections for every
device. This list is defined within a device model definition and can be viewed in the Connections tab
after the model has been imported. Refer to section 13.6.2.4 for more information on how to define the
connections in the device model definition file.
Help texts can be added to individual setting parameters to provide the user with additional information
about particular settings parameters. This feature provides similar functionality to annotations. However,
it can only be used with static device model definitions, whereas annotations can be used for all device
model types.
The help text icon is displayed next to the settings parameter when the setting is in edit mode. A
user can click the icon to view the helpful information.
3. Click the Edit help texts for device type... link in the Actions pane.
4. If the setting has more than one group, click the target group.
5. Add text as desired.
6. Click Submit.
13.4 Usages
Usage is a special property which indicates the purpose of a specific device. For example, a relay can
be installed in the field for different protective purposes such as protection of a line, a bus coupler, a
transformer or a busbar. The protective purpose of the relay is defined as a Usage in StationWare.
To create a usage:
2. Click the Create Usage. . . link under the Actions pane. A new window will appear
3. Enter a name in the provided text box.
4. Click Submit.
4. Click Submit.
4. Click OK.
The device lifecycle is a fundamental component of the StationWare system used for managing the
device settings and the business processes involved with settings management. A background and
more detailed explanation of the device lifecycle is presented in section 8.1.3. This section explains
how to configure the device lifecycle, and lifecycle transitions.
2. Click the Create lifecycle phase. . . link under the Actions pane. A new window will appear.
3. Enter a name.
4. Optional: Enter a description.
Note: The option Expiry Date is editable in the Edit mode of the lifecycle phase. It is an attribute of
settings or tasks and can be used to inform the user until when he should have finished his work
on the settings/tasks assigned to him (settings/tasks attribute Owner). Expired settings/tasks are
highlighted in the My Settings/My Tasks list on the My StationWare page (see also chapter 5.2).
13.5.3 Transitions
Note: The option Automatic creation of a snapshot can only be configured in phase transitions of the
device lifecycle. This option is not available in the phase transition configuration menu of process
lifecycles.
To configure automated email notifications to a selected group of users on successful phase transition:
Note: The email server, and additional options must be configured within the web.config file. Refer to
the StationWare installation manual for further information on the web.config file options.
Transitions can trigger Python scripts before and after applying a lifecycle phase change. To select a
transition script:
Note: The transition script has to be created in the Python script configuration menu. To display the
corresponding scripts in the Pre-transition or Post-transition drop-down menu, for these scripts
the Transition Script Type must be set to Settings Transition or All Transitions in the Python
script configuration menu.
To display helpful information next to the phase name on the change status window (window displayed
when Change status link is clicked on a settings page):
Note: The order that the checklist items appear can be altered by clicking to move the item one
position up the list, or to move the item one position down the list.
Lifecycle constraints are a set of rules which restrict the total number of settings within various lifecycle
phases.
2. Click the Create lifecycle constraint. . . link under the Actions pane. A new window will appear.
3. Enter a name.
6. Under Lifecycle phases tab, select all the desired lifecycle phases from the Other phases section
and click Include.
2. Click the desired lifecycle constraint from the Lifecycle constraints section located at the bottom
of the page.
3. Click the Edit. . . link under the Actions pane.
4. Edit the fields as desired.
5. Click Submit.
2. Click the desired lifecycle constraint from the Lifecycle constraints section located at the bottom
of the page.
3. Click the Delete. . . link under the Actions pane. A confirmation dialog will appear.
4. Click Delete.
Group authorisation rights can be configured to allow or deny access to perform a phase transition. To
configure:
Group authorisation rights can be configured to allow read, write or no access for individual groups for
settings in a lifecycle phase. To configure:
Note: Lifecycle rights work in conjunction with the parent location rights (by using AND operation).
Read-only access:
With read-only access, for a specific lifecycle, StationWare users will not be able to:
Read-write access:
With read-write access, for a specific lifecycle, StationWare users will be able to:
Change status of settings (transition rights, section 13.5.5.1, will determine whether a specific
transition is allowed or not).
No Access:
If access is denied to a specific lifecycle phase, StationWare users will not be able to access the settings
page at all.
To supply StationWare with models of existing devices, an appropriate model containing all necessary
information about a devices parameters must be created. Each parameter is structured with the follow-
ing components:
Name
Value
Valid range
Unit
Description
String
Floating point (double)
Integer
There are two types of device models, the static and the generic ones.
A static device model includes all parameters, default values, units and other relevant information of the
devices. A generic device model contains no parameter definitions and the settings record in Station-
Ware will be filled by the import of the manufacturers settings file on-the-fly. The principal structure of
the generic and static device model is however the same and will be explained in the following sections.
Device model definitions are defined using Microsoft Excel XML Spreadsheets. The XML Spreadsheets
(workbooks) have several sheets (worksheets) that will appear in Excel through tab pages. While the
majority of sheets will have names corresponding to particular group types within the settings file, there
are two mandatory sheets in every model definition: the Groups and the Info sheet.
The Groups sheet contains a list of all settings groups defined in the model. Unique group types
are specified in the GroupID column. The actual groups are specified in the Group Names column.
Table 13.6.1 shows a typical Groups sheet.
The column GroupID lists all settings group types. For each settings group type, a worksheet con-
taining the settings parameters must exist in this workbook. Note that the worksheet name must be
identical to the name in the column GroupID. The group type name listed in the GroupID column
must not contain any special characters, except an underscore ( ), or a white space. The first character
of the name must be a letter. Further, as Groups and Info have a special meaning, the group type
names must not have one of these reserved names.
The settings groups of one type are listed in the column Group Names. As shown in Table 13.6.1, in
this example there are 6 logical settings groups L1, L2, L3, L4, L5, L6 (separated by a semicolon) of
type L. A StationWare device based on this model will have the settings groups L1 to L6 with all the
settings that are defined in the group type L.
This sheet is a list of device property names and values. An example is shown in Table 13.6.2.
Manufacturer SEL
ModelNo 035171H45542XX
DeviceCategory Relay
Version 1.0.0.1
SoftwareIds AcSELerator
Ansi Device Function No. 50 / 51 / 67 / 79
DeviceCategory In StationWare the devices are organised into device categories (refer to section 13.1),
like circuit breaker, voltage transformer, current transformer and relay.
Version Version number of the device.
SoftwareIds For some devices StationWare offers an exchange interface to import or export the OEM
settings file which is created by the OEM software. Special settings converters are developed for
this purpose. These are linked to particular models by including the name of the converter/s in a
semi-colon separated list.
ANSI Device Function No. Here the device functions according to the ANSI definitions can be en-
tered. This will be displayed in the device details page for all devices that use this model definition.
This is not mandatory but is useful information for users when browsing devices in StationWare.
The table below shows the columns header required on all settings group sheets. The meaning of each
column is explained in the following section.
Function/Chapter This is a method to organise settings parameters into chapters. These parameters
will then appear together when viewing the settings in StationWare.
SWName This is the name for the parameter variable. The name must be software compatible, this
means no white spaces and no special characters except underscores ( ) are permitted and the
first character must be a letter. Every settings parameter name must be unique within a settings
group sheet.
DisplayName This is an identifier, address or short name that is displayed to the user when viewing the
settings within StationWare. Special characters and whitespace are permitted within this name.
Range All integer and floating point settings parameters have a permissible range. Some examples
are presented in the following text.
Unit This is a text string. There is no special style required for the unit. In some cases also additional
information about the value are entered here. Some examples of units are: C, kA sec
Description In this column the long settings name or its description may be entered. It recommended
to populate this column, although it is not mandatory.
Type The settings value can be an integer value (i), a floating point value (d), a set of some expressions
(ENUM) defined in the column Range or a string of a certain length (1a - 256a, the number before
the a defines the maximum length of the settings string).
Default The default or initial value has to be of the defined type and within the defined range. During
the validation of the parameters it will be checked if the default values are set according to their
range definitions.
Note: If the device model is a generic one, these columns should be left empty and will be filled on-the-
fly during the import of the OEM settings file.
In StationWare, it is possible to represent topology information. To build up the topology, devices need
the information about their primary and signal connections. This information is defined in the sheet
Connections of the device type. If no topology is required, there is no need to define the Connections
sheet. The Connections sheet includes the following columns:
Function/Chapter The purpose of this column is the same as the corresponding column in the settings
sheets.
SWName Software compatible name of the connection.
DisplayName Display name of the connection.
Description (optional) Connection Description
Settings views and annotations can be defined using Microsoft Excel XML Spreadsheets to perform a
bulk import. There are two ways to import settings views:
Import settings view parameters in an existing settings view described in chapter 13.3.9.2. In this
case the Microsoft Excel XML Spreadsheet includes only a settings views sheet that contains a
list of all settings parameter names and the group name they belong to (see section 13.7.1.3).
Bulk import of settings views and annotations described in chapter 13.3.11. The required structure
of the Microsoft Excel XML Spreadsheet is described below.
The XML Spreadsheets (workbooks) have several sheets (worksheets) that will appear in Excel through
tab pages. There are three mandatory sheets that must be found in each model: the Info, the Set-
tingsViews and the Annotations sheet.
This sheet is a list of property names and values. An example is shown in Table 13.7.1.
Manufacturer Siemens
DeviceCategory Relay
DeviceType 7UT63 generic
Usage Transformer Protection
Firmware V4.6
FirmwareSubversion 1
Note: Usage, Firmware and FirmwareSubversion are optional. But if left blank, settings views and an-
notations will only be visible for device settings with no usage or firmware defined.
The column SettingsViewID lists all settings view group types. For each settings view group type,
a sheet containing the settings view parameters has to exist in this workbook. It must be ensured
that the name of the worksheet is exactly the same as the corresponding expression in the column
SettingsViewID.
The group type name listed in the SettingsViewID column must not contain any special characters,
except an underscore ( ), or a white space and the first character of the variable must be a letter.
Further, as SettingsViews, Annotations and Info have a special meaning, the group type names
must not have one of these reserved names.
The table below shows the columns header of every settings views sheet.
Group name Name of the parameter group the setting belongs to. The parameter groups are defined
in the device type model and the setting has to be defined in this group.
The column AnnotationID lists all annotation column types. For each annotation column type, a sheet
containing the annotation parameters has to exist in this workbook. It must be ensured that the name of
the worksheet is exactly the same as the corresponding expression in the column type AnnotationID.
The column type name listed in the AnnotationID column must not contain any special characters,
except an underscore ( ), or a white space and the first character of the variable must be a letter.
Further, as SettingsViews, Annotations and Info have a special meaning, the column type names
must not have one of these reserved names.
The table below shows the columns header of every annotation sheet.
Library administration
The library administration section is used to configure the StationWare library. There are three areas
which are described in this section:
Documents that include additional documents and library documents can be organised into various
user-defined categories. For example, an organisation may want document categories such as:
The document categories administration section allows the StationWare administrator to define such
categories according to the organisations preferences.
1. Click the StationWare Administration tab - note you must have rights to the Administration control
panel for this tab to be visible.
2. Click the Document categories link under the Library section of the Administration page.
3. Click the Create document category. . . link. A new window will appear.
4. Enter the StationWare software name. Note this name must not include spaces or special char-
acters. Camel case is recommended for long names (CamelCase (Wikipedia)).
5. Enter the name (display name). This name may include spaces.
6. Optional: Enter a description that describes the document category. This is useful for explaining
to users what documents should use this category.
7. Click Create to save the category.
1. Click the StationWare Administration tab - note you must have rights to the Administration control
panel for this tab to be visible.
2. Click Document categories under the Library section of the Administration page.
3. Click the link for the document category (either the name, the software name or the description).
4. Edit the fields as desired.
5. Click Submit to save the changes.
Warning: Deleting a document category will also delete all documents of that category. If you choose
to delete the category, you will be unable to recover documents that were using it.
1. Click the StationWare Administration tab - note you must have rights to the Administration control
panel for this tab to be visible.
2. Click Document categories under the Library section of the Administration page.
3. Click the link for the document category (either the name or the software name).
4. Click the Delete. . . link in the actions area. A new window will appear.
5. Click Delete to delete the document category.
To set up the full-text search within the library, perform the following steps.
The configuration file for the full-text search can be found at <StationWarePath> \ fulltext \ icefix.
The default file name is icefix32.exe.config and should be changed to icefix.exe.config if a 64-bit
database client is being used.
In the configuration file the following attributes have to be added and/or amended to match the local
settings:
1. The database connection string (please refer to section 5.3 of the installation manual).
2. The path to pdftotext.exe to allow the search for PDF files:
<configuration>
<ice.net>
<components>
<fulltext.service>
<additionalFilters>
<additionalFilter application='..\..\__fulltext\pdftotext.exe'
argumentsPattern='{0} {1} -enc UTF-8' extension='.pdf'/>
Note: pdftotext.exe (an executable file) is included in the open source software Xpdf. For Win-
dows users it is recommended to download the binaries package xpdfbin-win-. . . . After
unzipping this archive, copy the pdftotext.exe executable to the <StationWarePath> \
fulltext directory.
In the general web.config file, located under <StationWarePath> \ WebImpl.HtmlUI \ psms, the
indexing of documents is disabled by default. If disabled, the full text search will not work. To enable it,
the relevant section of the web.config file must be:
<configuration>
<ice.net>
<components>
<fulltext enabled='true'>
To keep the full-text search up-to-date, a task has to be created with Microsofts Task Scheduler that
automatically starts the indexing process of new documents. It is recommended that this task is run
every ten minutes so that the document index is updated relatively frequently. To configure:
The setup of the full-text search is now complete and the search index will look for new documents to
index every 10 minutes. If you instantly want to test the full-text search, just run the task manually by
navigating to Task Scheduler Library in the navigation tree of the Task Scheduler, right-clicking the
task and selecting Run from the context menu.
14.2.3 Troubleshooting
If the full-text search does not find a document, then probably the indexing of the document might have
failed, for example, because of an incorrect path to pdftotext.exe. This can be verified by examining
the error folder located at <StationWarePath> \ fulltext \ error. For each failed document, two files
can be found in this folder:
*.error file
Contains the error message.
*.icefttask file
The index task of a document. This file has to be moved back to the queue folder located at
<StationWarePath> \ fulltext \ queue to try indexing the document properly.
Group authorisation rights can be configured to allow read, write or no access for individual groups for
individual library folders. To configure:
Note: To apply same rights to the sub-folders for all groups, click the Apply below the header Apply
rights to sub folders for all groups.
Read-only access:
With Read-only access to a folder, StationWare users will not be able to:
Read-write access:
With Read-write access, StationWare users will have full access to that specific library folder.
No Access:
If access is denied, StationWare users will not be able to access that specific library folder at all.
Process administration
This chapter describes the configuration of processes within StationWare. For more information about
what a process is and what they can be used for, refer to chapter 9. The following topics are covered:
Note: The procedure for editing a process lifecycle is the same as the procedure for editing a device
lifecycle.
4. Click the Delete button in the pop-up windows. This is only possible if the lifecycle is currently not
in use.
6. Click Create.
4. Click Submit.
Note: Please refer to section 15.4 for more information on how to create process types.
Warning: Deleting a process type will permanently delete all its processes and tasks.
Process types are defined using Microsoft Excel XML Spreadsheets. The XML Spreadsheets (work-
books) have several sheets (worksheets) that will appear in Excel through tab pages. There are three
mandatory sheets that must be found in each model: the Info, the Groups, and the Process sheet.
Contact your DIgSILENT representative to obtain an example process type XML file.
This sheet is a list of property names and values. An example is shown in Table 15.4.1.
Version 1.0.0.1
ProcessCategory Routine testing
The format of the Groups sheet is identical to the format of the Groups sheet of a device model. For
more information, please refer to the instructions from section 13.6.2.1.
The Process sheet contains a list of process attributes. These attributes are displayed on the Attributes
tab of the process.
The format of the process sheet is identical to the format of the settings sheet. For more information,
please refer to the instructions from section 13.6.2.3.
Similar to the settings sheet in a device model a tasks sheet has to exist in the process model for every
task group defined in the Groups list. The format of the tasks sheet is identical to the format of the
settings sheet. For more information, please refer to the instructions in section 13.6.2.3.
4. Enter a name.
5. Optional: Enter a description.
Scripts
StationWare has the ability to run Python scripts. These can be used for creating additional reports,
or for other administrative actions. StationWare uses the IronPython implementation 2.7.0.40, which is
based on Python 2.
The process for writing Python scripts is described in the following sections:
8. Under the section Display in. . . , select the desired StationWare object types, where the report
should be visible (besides the Reports tab). Enabling these options places a hyperlink within the
actions panel of the associated object.
9. Click Submit.
Note: Ideally, the Python script should first be tested by authorised administrators. The Visible tick
box must not be ticked before the script has been approved for use by other StationWare users.
Note: Ideally, the Python script must first be tested by the authorised administrators. And once the
script has been approved for other StationWare administrators to use, only then the Visible tick
box must be ticked.
Running of Python scripts defined in the section 16.2 is explained in this section. To run a script:
Note this section is not intended as a tutorial on the Python programming language. Rather, it is as-
sumed that the reader has at least basic knowledge of Python. For those users who wish to get up to
speed on Python development, there are many general purpose Python tutorials online. A good starting
point is to visit The Python tutorial.
16.4.1 Modules
All StationWare Python scripts, must have the following import declarations:
from System import *
from ServiceInterface.DataTransfer import *
16.4.2 Functions
All StationWare Python scripts, must have the following functions defined:
get parameters()
Function to define all the user input parameters. Required for all StationWare Python scripts.
def get_parameters():
return
validate parameters()
Function to validate any or all of the user input parameters. Required for all StationWare Python
scripts.
def validate_parameters():
return True
execute()
Function to define the Python script logic (section 16.2) or Python report logic (section 16.1).
def execute():
return
All the user input parameters required by the script must be defined in this function. These parameters
will then be available for the StationWare users on the script execution page.
DateTime
Int32, Boolean
String, MultilineText
LifecyclePhase, DeviceLifecyclePhase
MultiOverallStatusPhase
AdvancedSearch
For example:
pr.Description = "The objects within the location are reported"
pr.Type = ParameterType.Location
pr.Optional = True
User input parameters defined in the get parameters() function, can be validated in this function.
1. Retrieve the input parameter object using function Parameters.Get(string: object name) and re-
trieve its value using the Value attribute.
For example:
depth = Parameters.Get("Depth (1-5)").Value
Note: By default, if no validation is required, the function should simply return True. If a False value
is returned, the script will not execute any further.
16.4.2.3 execute()
This function defines the business logic of a Python report (section 16.1). To define:
1. Retrieve each input parameter object using function Parameters.Get(string: object name) and
retrieve their value using the Value attribute.
2. Use Python-StationWare methods to perform operations on StationWare objects, as desired.
Available methods are listed in the StationWare Service Methods manual. For examples on
how to use these methods, see the existing python reports that are delivered with StationWare
and the python module utils module.py.
3. To produce a report, information can be provided in the XML format and then desired XSLT (for
HTML reports) and XSL-FO (for PDF reports) layout scripts can be written. The XML output can
be produced using the following functions:
Output.WriteStartElement(string: elementName)
Writes the opening tag of a new XML element. Ideal for complex type elements (elements
with child elements).
Output.WriteElementString(string: elementName, string: value)
Writes a new XML element (with both opening and closing tags) and assigns it the passed
value.
Output.WriteEndElement()
Writes the closing tag of the latest currently opened XML element.
16.4.2.4 execute()
This function defines the business logic of an administrative Python script (section 16.2). To define:
1. Retrieve each input parameter object using function Parameters.Get(string: object name) and
retrieve their value using the Value attribute.
2. Use Python-StationWare methods to perform operations on StationWare objects, as desired.
3. Results or any debugging information can be printed on the users screen using the following
functions:
Output.Append(string: result)
Appends the string (passed as an argument) on the Python script execution page. The
argument is mandatory.
Output.AppendLine(string: result)
Appends the string (passed as an argument) followed by a line feed on the Python script
execution page. The argument is optional. The function will append a line feed to the output
screen irrespective of the argument being supplied.
All of StationWares Python methods can be referred from the PDF file or Compiled HTML Help file
StationWare Service Methods located in the root folder of the StationWare installation directory.
To call a method in StationWares Python script, Service.Method Name (input parameters) should be
used. For example, a function described as:
List<ILocationInfo> ServiceInterface.IPublishedReadOnlyMethods.TopLocationGetList
where
Boolean = System.Boolean
DateTime = System.DateTime
List = System.Collections.Generic.List
ILocationInfo = ServiceInterface.DataTransfer.ILocationInfo
can be called as
topLocations = Service.TopLocationGetList(False, DateTime.Now);
The following Python script returns a count of the number of settings in each lifecycle phase. It takes a
starting point (Root location) as an optional input parameter. If not specified, search for the settings is
performed on the entire StationWare system.
from System import *
from ServiceInterface.DataTransfer import *
PLANNING = "Planning"
REVIEW = "Review"
APPLIED = "Applied"
HISTORIC = "Historic"
SNAPSHOT = "Snapshot"
planningCount = 0
reviewCount = 0
appliedCount = 0
historicCount = 0
snapshotCount = 0
def get_parameters():
pr = Parameters.Create("Root location")
pr.Description = "The objects within the location are reported"
pr.Type = ParameterType.Location
pr.Optional = True
Parameters.Add(pr)
def validate_parameters():
return True
def execute():
rootLoc = Parameters.Get("Root location").Value
if str(rootLoc) == "None":
topLocations = Service.TopLocationGetList(False, DateTime.Now)
for location in topLocations:
checkRootLocation(location.Id)
getSublocations(location.Id)
else:
checkRootLocation(rootLoc)
getSublocations(rootLoc)
printInformation()
def checkRootLocation(locationId):
locationInfo = Service.LocationGetDetails(locationId)
if locationInfo.Info.IsDeviceContainer:
checkDeviceContainer(locationInfo.Info.Id)
def getSublocations(locationId):
sublocations = Service.LocationGetSublocations(
locationId, False, DateTime.Now)
for location in sublocations:
if location.IsDeviceContainer:
checkDeviceContainer(location.Id)
getSublocations(location.Id)
def checkDeviceContainer(locationId):
deviceList = Service.DeviceContainerGetDeviceList(
locationId, False, DateTime.Now)
for device in deviceList:
settingsList = Service.DeviceGetSettingsList(
device.Id, DateTime.MinValue)
for setting in settingsList:
checkSettingsStatus(setting.StatusName)
def checkSettingsStatus(statusName):
global planningCount
global reviewCount
global appliedCount
global historicCount
global snapshotCount
if statusName == PLANNING:
planningCount = planningCount + 1
elif statusName == REVIEW:
reviewCount = reviewCount + 1
elif statusName == APPLIED:
appliedCount = appliedCount + 1
elif statusName == HISTORIC:
historicCount = historicCount + 1
elif statusName == SNAPSHOT:
snapshotCount = snapshotCount + 1
def printInformation():
Output.AppendLine(PLANNING + ": " + str(planningCount))
Output.AppendLine(REVIEW + ": " + str(reviewCount))
Output.AppendLine(APPLIED + ": " + str(appliedCount))
Output.AppendLine(HISTORIC + ": " + str(historicCount))
Output.AppendLine(SNAPSHOT + ": " + str(backupCount))
User administration
The user administration section is used to configure the StationWare users and user groups. They are
explained in the following sections:
In StationWare, all the rights are applied to user groups and not the users themselves. Users get
assigned those rights depending upon which user group they belong to.
A StationWare user can belong to as many user groups as required, and they inherit the rights of all
groups that they belong to.
It is possible for a user group to contain other user groups as well. This, however, does not apply to the
Everyone group which is a special group and can only contain users and no user groups. But, it can
be a part of other user groups.
Administrators This user group has built-in administrative super-user rights (which means that they
have no restrictions) hence users who are members of this group have super-user rights within
StationWare.
By default, the built-in Administrator user is a member of this group and cannot be removed from
it.
Rights assigned to the Administrators user group cannot be modified.
Everyone Every user in StationWare is a member of this group. On initial setup, this group has no
rights. It is recommended to create new groups, assign them the desired rights and then assign
users to those newly created groups rather than modifying rights for Everyone user group.
StationWare has a special user called Administrator. By default, it has a blank password and belongs
to the special Administrators user group which has all the super-user rights.
It is not possible to delete or remove the Administrator user from the Administrators user group.
Account expires A flag to restrict the account activity of the user to a certain time period
Enabled from Date and time from which the user account is active (only effective if the Account ex-
pires flag is enabled)
Enabled to Date and time until which the user account is active (only effective if the Account expires
flag is enabled)
Password expires A flag to force the user to change password after a set number of days
Expires after . . . days Number of days after which the user password expires (only effective if the
Password expires flag is enabled)
To delete a user:
Note: If a user has been deleted, all its existing activity is still preserved in the StationWare database.
Note: If a user group has been deleted, all its existing members will be automatically removed from its
membership and therefore all the group specific rights will be revoked.
4. Click Submit.
A user can get locked out of the system in case of too many incorrect login attempts using the wrong
password.
The number of failed login attempts and the time period for which a user will be locked are configurable
via the web.config file. Please refer to the installation manual for more details.
Group data access rights can be configured to control access for individual groups for various Station-
Ware objects. To configure:
5. Click Submit.
Group data access rights can be configured to control access for individual groups for Administration
sections. To configure:
All users with their group relation. . . is an exclusive report available to administrators to list all the
users, their properties and their respective groups.
Comment The comment is an optional extra text description that is printed at the start of the report.
In order to perform a particular task, a user must have all the necessary rights. For instance, the
minimum rights a user must have to create and edit a settings record of lifecycle phase Planning, of a
device D at the location L are:
Technical information provides information about internal StationWare objects along with the version
number of the system and licensed converters. Information about the size of the StationWare database
can also be accessed from this page.
Location Administration
This chapter provides information on how to configure and administer the behaviour of any location
within StationWare.
A location category defines a kind of location that can be created and managed within StationWare. For
example, a location category called Bay might be created. Location types (discussed in section 18.2)
of Feeder Bay, Transformer Bay, and Line Bay could be defined that reference this category. In a
way, this is similar to the categorisation of animals, for example, there is a category of animals called
cats of which lions, tigers, and leopards are types.
StationWare comes with some built-in categories like Bay, Location, Scheme and Substation. Admin-
istrators can define additional categories or modify the existing ones depending upon the user require-
ments.
7. Click Create.
Note:
1. The StationWare software name can contain only upper and lower case letters, numbers and
underscores, and it cannot start with a number.
2. The value of device container attribute can only be assigned during creation and can never be
modified.
4. Click Submit.
Note: The value of device container attribute can only be assigned during creation and can never be
modified.
3. Click the Delete. . . link under the Actions pane. A confirmation dialog will appear.
4. Click Delete.
Note: If a location category is currently being used by any location type, then the user will not be able
to delete it.
Location types are used to build the location hierarchy that exists within an organisation. The location
types are based on the location categories defined in section 18.1.
StationWare comes with some built-in location types like Region and Area (of category Location),
Substation (of category Substation), Feeder Bay and Transformer Bay (of category Bay) and Feeder
Scheme and Transformer Scheme (of category Scheme). Administrators can define their own location
types or modify the existing ones depending upon their requirements.
7. Tick the Can be used as top level location option if a location of this specific type can be defined
at the root or top level of StationWare hierarchy.
8. Optional: Click Choose File to upload a 16 x 16 GIF image.
9. Click Create.
Note: The StationWare software name can contain only upper and lower case letters, numbers and
underscores, and it cannot start with a number.
4. Click Submit.
Refer to section 18.2.5 for more information on how to manage the location hierarchy.
2. Click the desired location type from either Hierarchy or All location types section.
3. Click the Delete. . . link under the Actions pane. A confirmation dialog will appear.
4. Click Delete.
Note: If a location type has sub locations defined or is currently being used by any location defined
within StationWare, then the user will not be able to delete it.
To allow StationWare users to be able to create and manage specific devices at specific location types:
2. Click the desired location type from either Hierarchy or All location types section.
3. Click the device compatibility tab. A list of compatible device types (the devices that are allowed
to exist at this location) can be found under the Can contain section and incompatible ones (the
devices that are not allowed at this location) can be found under the Cannot contain section.
(a) Select the device type(s) under the Cannot contain section.
(b) Click Add.
Note: Cannot contain list always overrides the Can contain list. It is therefore possible to configure
all device types, except some, by selecting All device types option from the Can contain list
and those not allowed from the Cannot contain list.
If a device type is not part of either list, it is automatically disallowed.
1. Please refer to section 18.2.8.1 for more information on how to access sub locations.
2. To edit basic information, edit the fields as desired and click the Submit button.
3. To manage devices, please refer to section 18.2.9.
4. To manage processes, please refer to section 18.2.10.
6. Click Copy.
2. Click the Move template. . . link under the Actions pane. A new window showing all the location
templates will appear.
3. Locate the target location.
4. Enter a new template name. This will be used as the name of the sub location.
5. Click Move.
Note: A sub location cannot be deleted if there are any sub locations or devices within it.
1. Follow the steps in section 18.2.9.1 to access the devices in the template.
2. Edit fields as desired.
3. Click Submit.
1. Follow the steps in section 18.2.9.1 to access the devices in the template.
2. Click the Delete. . . link under the Actions pane. A confirmation dialog will appear.
3. Click Delete.
1. Follow the steps in section 18.2.9.1 to access the devices in the template.
2. Click the Copy. . . link under the Actions pane. A new window showing all the location templates
will appear.
3. Click the target location.
1. Follow the steps in section 18.2.9.1 to access the devices in the template.
2. Click the Move. . . link under the Actions pane. A new window showing all the location templates
will appear.
3. Click the target location.
4. Enter a new device name.
5. Click Move.
1. Follow the steps in section 18.2.9.1 to access the devices in the template.
2. Click the default settings name under the Settings tab.
3. Refer to section 8.5.1 for more information on managing settings in a device.
Location rights can be configured to control access for individual groups for every location. To configure:
Note: To apply the rights to the sub locations for all groups, click Apply below the header Apply rights
to sub locations for all groups.
Read-only access:
With Read-only access for a location, StationWare users will not be able to:
Copy, move, detach, delete, create sub locations or edit details of a location.
Add, update, delete, move or edit details of additional documents.
Create, edit or delete notes and links.
Read-write access: With Read-write access for a location, StationWare users will be able to:
Copy, move, detach, delete, create sub locations or edit details of a location.
Rights for additional documents, notes and links will depend upon the respective rights in Data
access rights (section 17.1.18) for individual groups.
No Access:
If access is denied, StationWare users will not be able to access that specific location at all. In other
words, they will not even see that it exists in the hierarchy.
The administrative data maintenance section is used to delete, detach or move StationWare objects
from one location to another. There are two parts to it:
It is possible to permanently delete or temporarily detach StationWare objects like locations, devices,
settings, processes and tasks from the Administration interface.
Once an object is deleted, it can never be recovered again. However, detaching an object does not
delete the object itself. Rather, StationWare makes the object invisible (or out of service).
Once detached, historical records (if any) of a detached object can still be viewed via the History tab.
A detached object can also be reattached at a later stage. However, the same does not hold true for a
permanently deleted object.
Note: Settings objects can only be deleted. They cannot be detached or reattached.
Warning: Deleted objects are not recoverable and therefore cannot be restored.
Warning: Moving an object leads to an inaccurate representation in historic view. Objects may be
placed in their current location as opposed to their historic location.
The Table views administration section is used to define and configure additional information that can
be viewed in a tabular format for various StationWare objects. This has been described in the following
sections:
Table views are a way of presenting information from the StationWare database that might not otherwise
be visible in a convenient tabular form. They can be defined for locations, devices and settings. This
information can either be viewed as tabs at a location level (based on location types) or can be used to
replace the default search results for all locations, devices and settings.
Changed on Date and time the device, location or settings was last changed or updated.
Changed by StationWare user who last changed or updated the device, location or settings.
Lifecycle Phase Lifecycle phase of the setting.
Lifecycle Phase type Lifecycle phase type of the setting.
Parent name Name of the parent object (location name for a location or a device and device name for
a settings record).
Path (*) Relative path from the current location.
7. Click Create.
8. Please refer to section 20.1.4 for more information on adding columns to the table view.
Table views can be assigned to location, device and settings search results. When assigned, the
StationWare default view of the search results gets replaced by the selected table view definition.
4. Click Delete.
Additional Attributes
This chapter provides information on how to configure and assign additional attributes to various objects
within StationWare. Please refer to the following sections for detailed information:
Additional attributes represent additional information that the users may find useful for a location, device
or settings within a device. These are not directly part of a settings record but user-defined. For
example, a common additional attribute that is useful for a feeder or substation location, is the nominal
voltage level in kV.
Any change made to these attributes also gets logged in the audit trail. Moreover, running a device
comparison (see section 7.10.5) also returns the comparison between the additional attributes of the
devices, independent of their device types.
Attribute A user settable value that does not have any inner logic rules.
Propagate A user settable value that automatically propagates to lower levels of the StationWare tree.
For example, using the voltage example previously mentioned. If this is defined at the substation
level, but as a propagate type attribute, then all sub-locations, devices, and settings contained
within this substation will also have this attribute. Note, that at lower levels, the attribute is read-
only, and therefore it can only be changed at the level where it is assigned. Please note that
changes on a propagate attribute affects the Last change attribute of objects on the lower levels.
Overall status A lifecycle phase value evaluated from a set of rules (please see section 21.3.3).
Revision number An automatic incremental value triggered by the rules monitoring Overall status
attributes (please see section 21.3.4).
The data that is stored within an additional attribute, can be one of the following six types:
To create additional attributes, it is necessary to create Additional attribute containers first and then
define as many additional attributes as required within that container. This also has the benefit of
grouping together attributes to simplify the assignment process. The idea is that you can assign a
single attribute container to an object (which contains several attributes) rather than having to manually
assign the individual attributes one by one.
Note:
1. The StationWare software name can contain only upper and lower case letters, numbers and
underscores, and it cannot start with a number.
2. If set to Read only, the attributes will not be editable (irrespective of their initial value, which
is blank). This could be used as a temporary measure to prevent changes to particular additional
attributes.
Note: The StationWare software name can contain only upper and lower case letters, numbers and
underscores, and it cannot start with a number.
2. Select the destination container by clicking on the name or the StationWare software name.
3. Click the Contains attributes of tab.
4. Select the source container from the Contain attributes of selection box.
5. Click Add.
4. Click Submit.
4. Select the desired attribute definition by clicking on the name or the StationWare software name.
5. Edit the fields as desired.
6. Click Submit.
Warning: If a container contains any additional attributes, then it cannot be deleted. To delete it, you
first must delete all the internal additional attributes.
To change the display order of additional attributes within an additional attribute container:
5. Under the Enumerations tab, enter the desired text name of the enumeration in the Create enu-
meration value text box and click Add. A new record will appear inside the same tab.
6. Repeat the previous step to add additional selectable values.
When an existing additional attribute of kind Propagate is assigned to a new StationWare object, it
does not appear directly in the object it is being assigned to. To reflect the changes:
1. Go to Administration tab and either click the Additional attribute definitions link or the Additional
attribute assignments link.
2. Click the Recalculate propagate attributes. . . link. A new window will appear.
3. Click Recalculate.
An additional attribute of kind Overall status, is a lifecycle phase value evaluated from a set of rules.
It is used to provide a quick summary or visual status of the devices underneath a particular location.
For example, say you have navigated to a substation and you would like to know if any devices at that
substation currently have settings under development. Checking the overall status of the substation,
tells you such information at a glance. Please note, that a change on a settings status can affect the
overall status of a device or substation and this again affects the Last change attribute of the device
or substation. The overall status is also useful for reporting. For instance, there is a specific report that
provides information about the system based on the overall status phase.
An overall status attribute follows a user defined logic which can be defined by:
The rules are checked in the order they are listed. As soon as one rule evaluates to true, the resulting
overall status value is set (based on the Results in property of the rule).
For a rule to evaluate to true, all the entries within that rule have to evaluate to true. If no entry is defined
within a rule, it will always be evaluated to true. This, therefore, is a good approach to use if no other
rule evaluates to true and this type of rule can be placed at the bottom of the rules list.
After the overall status rules are created or modified, the system needs to re-evaluate the rules for each
location in the system and this does not occur automatically. Hence the overall status attributes must
be manually recalculated. To do this, please refer to section 21.3.3.4.
2. Select the desired container by clicking on the name or the StationWare software name.
3. Select the Attribute definitions tab.
4. Select the desired attribute definition by clicking on the name or the StationWare software name.
5. Click the Create rule. . . link. A new window will appear.
6. Enter a name.
7. Optional: Enter a description.
8. Select a value for the Results in combobox (one of the lifecycle phases).
6. Under the Entries tab, click Add entry. A new record will appear inside the Entries tab.
7. Under the Phase column, select the lifecycle phase to be checked.
8. Choose one of the following radio buttons:
All
All the inner objects, like the settings records, must have this lifecycle phase.
Not all
Not all inner objects need to have the selected lifecycle phase.
Right arrow
The logical criteria in the following two columns defines this entry. The inner objects must
have a count of objects with the lifecycle phase selected that equals, is greater, is less, is
greater or equal or is less or equal to the number inserted in the Count column.
Note: Before a new entry can be added, please click Submit to save the existing changes.
1. Go to Administration tab and either click the Additional attribute definitions link or the Additional
attribute assignments link.
2. Click the Recalculate overall status. . . link. A new window will appear.
A revision number is an automatic incremental attribute, which gets triggered by an overall status
change. It must be of Integer type. To configure:
Additional attribute containers defined in earlier sections must be assigned to StationWare objects, so
that the attributes will appear within those objects in the tree.
The additional attribute visualization sequence defines the order that the selected additional attributes
are displayed within the StationWare object.
The visualisation sequence can be modified by clicking to move a record one position up the list, or
to move a record one position down the list.
Maximo Contains an additional attribute Maximo ID of kind Attribute and type String.
Overall Contains an additional attribute Overall Status of kind Overall status and type String.
Revision Contains an additional attribute Revision Number of kind Revision number and type Inte-
ger.
Voltage Contains two additional attributes of kind Propagate:
1. Voltage Level of type Real.
2. GlobalNote of type String.
21.5.1 Assignments
By default:
1. Maximo, Overall and Revision are assigned to Device Container location base type.
2. Voltage is assigned to Bay and Scheme location categories and Settings.
3. Voltage and Overall are assigned to Device device base type.
The following visualization sequence only applies to the default StationWare hierarchy. Any changes to
the default hierarchy, locations or additional attributes may result in a different visualization sequence.
1. Feeder Bay, Feeder Scheme, Transformer Bay, Transformer Scheme and Substation being
device containers, will have access to the additional attributes of Maximo, Overall and Revision
containers.
2. Feeder Bay, Feeder Scheme, Transformer Bay and Transformer Scheme being part of lo-
cation categories Bay and Scheme respectively, will have access to the additional attributes of
Voltage container.
3. Circuit Breaker, CT, Relay and VT being part of device base type Device, will have access
to the additional attributes of Voltage and Overall along with two additional built-in properties
AnsiDeviceFunctionNumber and Usage.
StationWare interfaces
Chapter 22
PowerFactory interface
This chapter discusses the StationWare interface to PowerFactory software. The following topics will
be addressed:
Interface background
Interface requirements
StationWare has the ability to exchange relay settings information with PowerFactory software which
significantly speeds up the process of inputting settings parameters into PowerFactory especially for
numerical relays with hundreds or thousands of settings parameters. PowerFactory can then be used
to adjust the relay settings using the analysis tools present within the software. Following settings ad-
justment, they can be exported to StationWare, where they become managed again using the lifecycle
within StationWare.
The process for exchanging settings parameters with PowerFactory uses the underlying web services
framework, which must first be enabled within the StationWare environment. Note that the web ser-
vices framework that is used for the PowerFactory interface is different from the standard web services
interface. Instructions for settings this up are provided within the StationWare installation manual.
An overview of the components of the PowerFactory interface is shown in Figure 22.1.1. There are four
components to the link:
PowerFactory relay model This describes the mathematical functionality of the relay, but only con-
tains the necessary subset of the relay settings required to determine the primary power system
performance of the relay. More information on relay modelling in PowerFactory can be found
within the PowerFactory user manual.
StationWare relay model The StationWare relay model is the XML representation of all the relay set-
tings.
DPL import script This DPL script is stored within the relay model in PowerFactory and must have
the name PsmsImport. It describes the mapping of the StationWare settings parameters to the
PowerFactory settings parameters, and also any custom logic that might be required to translate
the settings from one format into the other.
DPL export script Like the DPL import script, this script is stored within the relay model and must have
the name PsmsExport. It describes the mapping of the PowerFactory relay model parameters
into the corresponding StationWare model parameters and any custom logic that might be required
to translate the settings from one format into the other. Note that, because the PowerFactory
settings are a subset of the entire relay settings, it is necessary that this script also has some logic
to reconstruct the missing settings parameters.
Note: Writing the PowerFactory interface scripts requires expert knowledge of the DIgSILENT Pro-
gramming Language (DPL), and is beyond the scope of this StationWare user manual. Further
information about DPL can be found within the PowerFactory user manual. To obtain an example
relay model, with example interface DPL scripts, contact your DIgSILENT representative.
This chapter discusses the web services methods that can be used to access components of the Sta-
tionWare system and complete complex automation task using external software and scripting lan-
guages. The following topics will be addressed:
Web services are a common method of enabling third party tools and interfaces to access existing web
based database and software systems. Essentially, it is a framework that defines a list of functions, their
inputs, calling methodology, and the values that they return.
Due to the widespread popularity of web services, many programming languages such as Python have
built-in libraries and methods that make it easy to call the available functions.
StationWare supports the Web Services Description Language (WSDL) which is an XML based lan-
guage for describing the available functions provided by the web service. Before accessing the web
services, they must be enabled by the system administrator. The procedure for doing this is described
in the StationWare installation manual.
http://<ServernameOrIpaddress>/<ServiceAlias>/PSMSService.asmx
This link will show a list of all the available web services methods. Clicking on the hyper-linked name of
one of the methods will provide additional information about it. For example, the method LocationGet-
Sublocations can be used to retrieve the sub-locations of any object within the StationWare tree. The
XML request definition of the method (SOAP 1.2) is as follows:
POST /swws_dpmelb42b_service/PSMSService.asmx HTTP/1.1
Host: 10.0.30.62
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<LocationGetSublocations xmlns="http://www.digsilent.de/psms/webservice/">
<AuthTicket>string</AuthTicket>
<LocationId>string</LocationId>
<FilterByDate>boolean</FilterByDate>
<EffectivityDate>dateTime</EffectivityDate>
</LocationGetSublocations>
</soap12:Body>
</soap12:Envelope>
The LocationGetSublocations XML tag lists the required input parameters that must be passed to the
function. In this case, the following parameters are required:
AuthTicket The StationWare AuthTicket string that is generated after a successful login.
LocationId A string of the location ID where the sub-locations will be retrieved from.
FilterByDate A True or False value indicating whether the results should be limited to only those
objects that were in the system prior to the EffectivityDate
EffectivityDate A datetime value that will be used to filter the sub-locations if FilterByDate is True.
The response to the query will yield an XML file that contains any error messages, and also a list of
sub-locations. The response XML form shows the format of this response.
All other web services methods use a similar approach, and their functionality can be determined by
accessing the web services information page for each specific function.
The following source code is an example of a Python script that can be used to call the StationWare
web services. Assuming that web services is enabled on your StationWare system, and that you have
Python 3 installed on your system, you should be able to run this script as an example.
If you would like to obtain a copy of this script, contact your DIgSILENT representative.
Prior to running the script, you need to update the following variables:
reqUsername Set this to the user that you want the script to login to StationWare as. Note that if the
script does not have appropriate read-only access to all parts of the StationWare tree, it may not
work correctly.
reqPassword Set this to the password of the above user.
reqSWurl Set this to the url of the StationWare web service that you want to connect to.
The script will connect to StationWare and retrieve the entire tree including all devices and print the
results to the terminal window.
'''Demonstrates the usage of web services for the StationWare manual.
The script will retrieve the StationWare tree, and print it the standard output.
Each level of the tree will be indented by two spaces.
Requirements
The suds-py3 package must be installed to your Python installation.
'''
import suds
#The variables below must be altered to match the appropriate settings for your
#local instance of StationWare.
def main():
'''
Logs in to SW web service, retrieves all the top locations, passes them to
the GetLocationTree function which recursively navigates through the tree.
'''
if __name__ == '__main__':
main()
Settings converters
This chapter discusses the settings converters that are available within StationWare and that can be
used to import settings data from manufacturer specific settings files (OEM files) into the standard
StationWare format. The following topics are covered:
Converters background
Available converters
Configuring StationWare to use the settings converters
Although proprietary settings files in the manufacturer file format (OEM format) can be stored directly
in StationWare by attaching them as settings documents, much of the advanced functionality of the
system is restricted unless you store the settings within the StationWare XML format. Storing settings
within the StationWare XML format has several benefits including:
A commmon interface is presented for every settings file, regardless of relay vendor, or relay
model.
Settings views allow for custom displays that show only the most important or critical settings from
the entire list of settings parameters.
The StationWare audit trail captures changes to the individual settings parameters when the
settings object is in a review or applied phase. This allows for visualisation of the development of
settings over time, and by extension makes the finding of problems straightforward.
Searches can be completed on individual settings parameters.
Settings can be compared directly in StationWare, without the need to use the vendor settings
software.
Settings can be exchanged with PowerFactory software to allow rapid checks of protection settings
and testing of relay performance.
To store settings in the StationWare XML format requires that they are converted from the proprietary
OEM format. StationWare implements settings converters that automatically complete this process. A
settings converter is an integrated software tool that understands the vendor format and can extract all
settings parameters, units, descriptions, and valid ranges from it. In some cases the converter is also
required to extract encrypted or obfuscated information from the file when the OEM format is not an
open standard.
Historically, due to the large number of vendor formats, such converters have been developed on an
as requested basis and released to our clients for an additional fee. StationWare now comes as
standard with two converters included, and additional converters can be purchased from DIgSILENT
and licensed along with your StationWare software license. Contact your DIgSILENT representative to
obtain a quotation and/or order additional converters.
A list of converters that are currently loaded by your StationWare installation can be accessed via the
StationWare user interface: Administration tab > Technical information > Converters tab.
The process of configuring each settings converter is slightly different, and each one must be separately
installed. Consequently, the installation procedure is not described within this user manual, but rather
with the technical documentation and installation manual provided with each licensed converter. Contact
your DIgSILENT representative in case of difficulties with converter installation.