IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010
Implementation of EDP Type Project to the
Automation of Substations according to IEC
61850
Martins, D.F.R., Student IST
Abstract - The EDP long tradition of substations automation and
protection gave birth to a prototype project, whose configurations
can be reuse in future projects with all the financial benefits that
this solution insures. However, the recent communication norm
for energy environment (IEC 61850), recommend rules
specifications of organization oriented for objects, applying a
specific language SCL (Substations Configuration Language).
Substations adjust to the new norm aims to carry the
PC/Windows: Ethernet net, TCP/IP environments, and “plug and
play” services to substations informatics systems. Towards it is
very important and interesting the development of reusable
specifications of Automation and protection systems for EDP
substations, using the organization for objects and SCL language
set in IEC 61850.
The main goal of this work was to write in SCL language the EDP
current specifications for systems described in substations
prototype project, making their structure according the norm
principles and using high level tools called “System configuration
tools”. These tools have graphical environments that aid SCL use,
like Visual SCL and Helinks STS, which were used in this work.
Many configuration methods were tested for these tools. In
addition communication interfaces were exploited between
system configuration tools and IED’s configuration tools, in order
to find if it is possible reach interoperability through data
exchange among tools.
It was also developed an new method for all configuration
services related to IEC 61850, hat consist in a program based on
C language, with the ability of reading and editing SCL files.
Index Terms-- IEC 61850, IED’s Configuration Tools, System
Configuration Tools, SCL Language
I. INTRODUCTION
IEC 61850 was presented in the market like an universal
solution with the aim of go around the vast protocol amount
existence in substation communication field, which in general
were associated with technical and financial complications, for
users and manufacturers. The communication standardization
provided by the norm, will allow a decrease of engineering and
maintenance costs contributing to the raise of investments
security. The norm appliance vantages are at the level of
system expansion process will therefore upgrade costs far
below those that are practiced today. Therefore the IEC 61850
application in electricity substations will lead to operational
and financial benefits. Hence last decade was a period of huge
development at the level of digital relays protection systems
digital technology. A great part of systems evolution occurs in
Manuscript received xx, 2010.
Digital object xxx.
1
Pinto de Sá, J.L., Senior Member IEEE
a way that it is possible cope the norm to increase the size of
the features planned for those, whereby the amount of
configurable parameters assumed a characteristic of
exponential growth, making the parameterization task by the
protection engineer, an exhaustive process with high rates of
error probability associated.
In a worldwide context it is possible to find IEC 61850 mainly
in transport energy substation. For the involved voltage levels,
the substations are sized and designed almost individually,
whereby a new substation project involves in most cases the
same number of workers of the former substation, and it’s not
possible to settle a prototype project. Nevertheless at
distribution voltage levels it is possible to see that electricity
substations are very similar among them and for that reason
the new substation projection it is basically other project
replication being a labor force and a time waste besides the
large probability of making mistakes during settings.
The solution presented in this article focus its approach in the
development of a proposed substation type, which can be
reused whenever you want to design a substation with similar
characteristics of a existing one. This substation type notion
makes sense when considered in parallel with all the flexibility
principles that characterize the IEC 61850, raising the
following question:
"Is it possible to create an engineering tool based on IEC
61850, which can receive an SCL file with the substation
generic configuration, creating a new file with the
configuration of a real substation, totally configured with
equipment from different manufacturers?"
These two concepts adaptation would enhance all substations
setting process to a new level, generating a new paradigm in
protections market.
This new paradigm would provide essentially a method of
reducing the configuration costs since the application of a new
method based on universal processes need less skilled labor
force in the different projects. Likewise the constant evolution
that a certain substation model can be subjected, gives more
efficiency and strength, eluding all the problematic situations
that were found on previous projects. In spite of concepts
adaptation it only makes sense if protection manufacturers
adopt a common philosophy in tools standardization around
common protocols that share the same language.
The incompatibility problems arise in this tool interaction
phase because all the manufacturers end up to insert in their
software’s and SCL files peculiar characteristics that can be
problematic in a project with different IED’s (Intelligent
Electronic Devices) from diverse manufacturers.
 IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010
II. IEC 61850 AND DIFFERENT MANUFACTURES
Most protections manufacturers had settled its equipment to
needs imposed by the standard. This adaptation process
involves engineering tools creation which in parallel to IED's
configuration are able to create and handle different SCL
formats file.
This procedure makes possible to deal with their IED's in the
environment of IEC 61850 at IED's configuration tool and at
system configuration tool level. Coming the substation
configuration phase, it is required that these two tools levels
establish communication channels between them.
IEC 61850 does not prescribe how logical nodes are conducted
internally or what they do. Therefore, and consequently, the
IED's don’t need to be changed according to the standard,
except the formatting has to be normalized according to the it.
This normalization does not require the IED's modification,
since the intermediate configuration tools become to be the
real IED's interfaces toward the norm.
The system configuration tools must be able to import and
export configuration files in the SCL language based on rules
defined in part 6 of IEC 61850 [1]. These tools must be
provided with the ability to import as many IED's
configuration files, as those who wish to install in a given
substation project. These IED's descriptive files must be
generated by respective IED's configuration tools.
Subsequently, the configuration system must generate a file
containing the substation configuration, which must be
approved by the IED's configuration tools, in order to all
settings be properly perceived by all IED's substation
elements.
In Figure 1, is described the method which SCL file formats
directly involved in the communication of data between
different engineering tools, specifically, ICD and SCD will be
administered.
ICD
IED Configuration System
Tool Configuration Tool
SCD
Figure 1 - Functional diagram of the communication SCL files between two
engineering tools
During the development of this work were used tools from two
protections manufacturers, Efacec and Siemens. However, not
only it was use the tools created by the manufacturers, but also
tools from others without a direct connection with the
manufacture of protection units such as ASE (Applied Systems
Engineering, Inc) and Helinks LLC . The use of these tools
developed outside the context of protections manufacturers, is
a decisive factor for the configuration of a reusable substation,
since the process of construction of this software must have
followed a principle of universality of use and should not
depend on the manufacturers to use the in the project. This is
2
important for this work, where the main goal is to obtain a
substation configuration guided by the impartiality toward the
considered manufacturers. Last consideration, it can never be
possible to completely avoid the use of manufacturer’s tools,
but it will be make an effort to reduce great part of this need.
 Visual SCL (manufacturer: ASE)
 Helinks STS (manufacturer: Helinks LLC)
 DIGSI (manufacturer: Siemens)
The system configuration tools used during the test phases
were the following:
 WinSettings (fabricante: Efacec)
 DIGSI (fabricante: Siemens)
The procedures that took place during the test phases are based
in configurations philosophy allowed from the system
configuration software, Helinks STS. This tool was chosen
instead of Visual SCL, since after extensive use of both
programs utilization, Visual SCL revealed some background
problems. In this chapter it will be analyzed the differences
between SCL files from two protection manufacturers which
protection units are in the laboratory, Efacec and Siemens.
The development of tests procedures in this phase allow to
prove that although the existence of common points among
IED’s structures there are divergences. The most evident
differences are structure related with the way the two
manufacturers organized the logical nodes inside the LD
(Logical Device) instance and also LLNO (Logical Node
Zero) notion. For that, four ICD files were downloaded for the
substation description. As can be seen in the following figure it
is possible to analyze that the tool was succeeded in the four
unit’s presence interpretation specifically the IED_0010,
IED__0013 and IED_0018 devices from Siemens and
IED1_lab device from Efacec.
Figure 2 - Association of IED's in a substation with Visual SCL
As expected the program updates the substation description
with IED’s data of the two manufacturers, namely the sections
corresponding to instances of "Data Type Templates", which
can be seen in Figure 3. In that figure can also be observed that
this instance is composed from several fields, namely: "Lnode
Types", "Data Types", "Attribute Types" and "Enum Types."
 IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010 3

A. Logical Device Organization

It is at LD organization level, where the general differences
between the structures of the two manufacturers in question,
lies on. There are several philosophies which can be followed
to structure the logical nodes within a LD instance. Within
Figure 3 - Hierarchical structure of Data Type Templates with Visual SCL Figure 5, it can consider that the "LDevice" of IED_0018
(Siemens) consists of five instances where the nodes are
For example, in the "Lnode Types" (Figure 4) it can be organized in logical agreement with its functional area. More
observed all logical nodes which can be implemented by four specifically, the five instances are:
devices, where the logical nodes of IED_0010, IED_0013  PROT - Protection
IED_0018 and are appointed based on the device address and  MEAS - Measurement
subsection in which they operate. On the other hand, the  DR - Disturb Rec
logical nodes from other IED are named based on the prefix  CTRL - Control
"EFA_" followed by the acronym representing the protective  EXT – Extended
function. Although different from the method followed by
Siemens, the definition of logical nodes by Efacec is not going
against IEC 61850, since it’s provided the prefixes and
suffixes combination to the description of the logical nodes.
While Efacec chooses to use prefixes, Siemens often chooses
the use of suffixes, as can be seen for IED_0010/PROT/PDIS
logical node, which can be terminated with the number "1" or
with the number "2" as can be observed in the fifth and sixth
line of Figure 4.

Figure 5 - Comparison between files in Visual SCL (left side: Efacec, right
side: Siemens)

In IED_0018 structure the logical nodes are not immediately

disposed within each of the instances listed above, as there are
still two more branches, more specifically, "LLN0" and
"LN’s". Its inside the instance "LN’s" that are discriminated all
logical nodes. Relatively to IED1_lab also represented in
Figure 5, may consider that the "LDevice" while detailing the
logical nodes within the instance "LN’s", don’t organized
them into logical devices, opting only to list them all on the
same branch. The other instance in the logical device
("LLN0") will be analyzed in the following chapter.

B. Logical Node Zero Organization (LLN0)

The Figure 5 analysis also proved to be very useful with regard
to LLN0. The importance of this logical node is vital, since it
is through it that are all communications aspects are
parameterized, like horizontal (GOOSE) and vertical (RCB,
etc). On this point clear differences emerge between the
Figure 4 - Association of Lnode Types in Visual SCL
structure followed by Siemens and Efacec. As the IED from
Efacec are characterized by only a list of logical nodes, only
have one instance of the logical node LLN0 against the five
instances of Siemens (one instance for each of the lists of
logical nodes of the five functional areas).
 IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010 4

original DIGSI although this is not in agreement with Visual

SCL schema. Nevertheless when the file is save it is adapted it
to its default schema which is not recognized by DIGSI.
Therefore, we find that this is not a problem of standard
misinterpretation, but a problem of interoperability between
tools. On the other hand, the interaction between the Helinks
STS and DIGSI does not present the same problems that Visual
SCL. This result was leading to the choice of an engineering
tool used to perform the procedures that follow. Henceforth
the Helinks STS was the tool of choice for the substations
configurations.

III. EDP PROJECT TYPE

The Project type main idea, is to find a unique configuration
solution for the substations, using whenever it’s possible the
tools to perform the expected functionalities. The EDP Project-
Type is composed by an extensive set of technical documents
with a very broad spectrum of areas, which sets the technical
characteristics the substation HV / MV should include in its
installation. From all the functional areas this paper mainly
focuses its analysis only on issues related to SPCC (Protection
System, Command and numeric Control). As the name says
Figure 6 - Comparison between files in Visual SCL (left side: Efacec, right SPCC is responsible for the protection, command and control
side: Siemens)
of all substation organs, their internal architecture consists of
several information process modules which interconnection
allows the performance of all necessary functions for the
As described earlier, is on LLN0 that communications are proper substation work. The functional architecture of the
parameterized, with the main phase interest the RCB stage SPCC is divided into three interlinked hierarchical levels, as
settings. To parameterize completely an RCB a configuration seen in Figure 7:
of the two instances is needed which can be seen in Figure 6
 Level 0 – Process (constituted by HV / MV
for any of the IED’s. The attributes that will be provided are
substation equipment in which SPCC interacts
specified in the instance "Data Sets", and this section is later
 Level 1 – Panel Unit / IED;
referenced inside the instance "Report Controls" where must
be defined other features relating to RCB's.  Level 2 – UC (Central Unit):
The logical node LLNO internal structure is the same for any
o PCL (Local Command Station);
of the manufacturers, and the only thing that varies are the
names that are assigned to instances that constitute it. For o CC (Conduction Center);
example for the "Data Sets", Efacec chooses to do an
o CER (Remote Engineering Center);
association between a specific "Data Set" and the RCB by the
composition of the name. Namely "DSforbRCBA" means "
Data Set for Buffered Report Control Block A". Furthermore
Siemens chooses only call "DataSet1," and only makes the
association of "Data Set" with its RCB at a later
parameterizations stage.
Despite the existence of commonalities between the IED's
structures, there are also divergent points that may prove to be
problematic when the need to export files arises.

C. Interaction between engineering Tools

We tested the SCD file transfer resulting from the previous
chapter, between the two configuration tools, from systems
analyzed. It was found that in Visual SCL and DIGSI cases
there are different interpretations of some points of the SCL
language, otherwise the adaptation of Visual SCL schema to
the original DIGSI file would not cause changes that inhibit
their subsequent transfer. Visual SCL schema, consists
essentially of a standard structure that the Visual SCL uses to
organize its files. Must be underlined that the Visual SCL Figure 7 - Architecture and Functional Organization of the SPCC [2]
recognizes and correctly interprets the file structure of the
 IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010
The communication data between different SPCC levels is
carried out through both LAN (Local Area Network),
specifically the "Process Bus" and “Substation Bus," which
wiring diagram is shown in the previous figure. The "Process
Bus" establishes a data connection between the physical
equipment of HV / MV and the IED's, just as the “Substation
Bus" establishes communication between IED's and UC. It is
important to refer that although there is a conceptual notion of
"level 0" it is not yet in operation on distribution network
substations.
A. Different communication levels
In IEC 61850 it’s possible to distinguish two communication
distinct levels, vertical and horizontal communication.
Horizontal communication also known as GOOSE,
establishing communication channels between different IED's
present at the substation, while the vertical communication
(RCB) provides links to data exchange between IED's and UC.
Although both communication types are very important, this
paper focuses exclusively its approach to the vertical
communication level of IED's.
IV. PROJECT TYPE REUSABLE CONFIGURATION
EDP project type has in his genesis the construction of a
substation type where all processes and parameterizations can
be based on a possible procedure to replicate most of the
substations. However, protections manufacturers have created
their own software to deal with language SCL, adding also that
the interpretation of IEC 61850 is slightly different among
different manufacturers. The solution enabled by IEC 61850
for this problem boils down to the use of universal engineering
tools capable of dealing with the different structures of the
SCL files submitted by manufacturers
However, and as reported previously, available tools and the
different patterns of data presentation followed by the
manufacturers do not allow full interoperability of these tools.
Moreover, for a given voltage level the substations assume in
most cases an identical topology, so that all settings in the
protection units will have to be repeated whenever wants to
build a new substation. This setting method besides being
extremely exhausting for the operator responsible for
parameterization introduces a high probability of human error
during extensive process.
It was demonstrated in this paper a method to solve the
interoperability problems found, allowing a fully reusable
substation configuration, using to this end, an algorithm
programmed in order to operate the IEC 61850 settings based
in a single procedure.
A. Conversion tool of SCL files among manufacturers
The solution adopted to automate all services settings, related
to IEC 61850 consisted in the development of a program in C
programming language, which allows reading and editing the
SCD files, exploiting the XML format that is the basis of SCL
language. The program called Conversor SCL, explored the
extensive list of existing libraries that enable interaction with
XML files, as well as the simplicity of creating an executable
5
file which can be executed on a computer with Windows
operating system. Conversor SCL does not eliminate the need
for a universal configuration tool nor the tools from
manufacturers. The program's function is to reduce the amount
of time and complexity of transactions between the system
operator and the various engineering tools, solving the
interoperability problems encountered when trying to use data
groups. In a simplified way the program allows the reception
of SCD files where can be inserted generic IED’s or IED's
whose internal structure is not set according to the
interpretation of a particular protections manufacturer. The
generic IED structure depends only on the generic
configuration tool system used, in this case the Helinks STS.
The SCD file creation on Helinks STS based on these generic
IED's give rise to a file whose services and data, represent no
real protection unit from any manufacturer protections in
particular. The Conversor SCL performs the recognition of
generic IED’s, and converts to a particular manufacturer
structure. So, it is possible to parameterize an entire substation
based on generic entities and then converting to the structure
of a particular manufacturer, each of these entities.
The referred algorithm is illustrated graphically in Figure 8. In
this figure it can be seen that both input and output of
Conversor SCL are SCD format files. For the case in figure
mentioned above, the difference lies in the fact that the inputs
file describing the substation is an IED from Siemens and a
generic, while the output file becomes an IED from Siemens
and one from Efacec. That is, the program recognizes the
existence of a generic entity and asks the user if he wanted to
award this entity to a particular manufacturer, in which case it
was assumed that the user intended to use an Efacec entity.
Moreover, all input file entities that are not recognized as
generic remains unaltered in the output file.
.SCD Conversor SCL .SCD
Substation: Substation:
Siemens IED Siemens IED
Generic IED Efacec IED
Figure 8 - Functional diagram of the Conversor SCL
In the previous paragraph was mentioned an IED generic
adaptation to a manufacturer's, Efacec, because this was the
only manufacturer existing into the database which the
Conversor SCL uses. However, the method can be
extrapolated to any market producer which implement in their
protection units the features contained in IEC 61850.
1) Functional flowchart
The functional flowchart of Conversor SCL is represented in
Figure 10. In this picture it can be seen two oval shapes
outlined in red representing the program input and output.
Likewise, the rectangular blocks represent subsystems where it
acts directly on the file and lozenges subsystems where the
need for a decision arises.
One of the key points for correct perception of the built
program goes to new entity concept clarification, which is
 IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010 6

called the generic IED. The system configuration tools allow

the association of IED's, by importing the ICD files associated
SCD file
with them. However, these tools allow another method of
entities association, where the operator can easily create a new
IED through an icon "New IED." Immediately after the entity
Analyzes the SCD
association, the characterizing object is only constituted by the file looking for a
generic IED
hierarchical structure root that defines a model of IED based
on IEC 61850. This generic structure, which can be If find If not find

continuously branched depending on the settings made on

IED. Figure 9 shows all the necessary branches to configure
Operator wants to convert the
the vertical communication structures, also having the entire generic IED to the proper No
Makes no change to
the file
structure of a manufacturer?
terminal nodes (in red) needed to correct the definition of a
generic IED.
Yes

IED_generico IED Collects data from

the generic IED

Acess
AP1 Point Asks the operator the
name and serial
number of the new
IED

Server
Replaces the generic
IED structure by the
manufacturer structure
and inserts the data SCD file
Logical the user requests
LD_generico Device

LN0 Lnodes Checks if the generic IED Updates the initial

Dont have
has RCB's and DataSet SCD file

Report
DataSet1 Data Set
Control Have

From the template of IED

manufacter collects all No
FCDA available Lnodes and
their internal attributes

Figure 9 - Diagram of the branches to implement the generic model of an IED

All branches that have been outlined previously can be Manufacturer IED has Lnodes
and attributes described in the
Warns the
operator that there
Operator wishes to
No continue the conversion
transcribed for the Helinks STS, obtaining a similar result to generic dataset of the generic
IED?
are no available
data on IEDl
of the remaining?

what is shown in Figure 14.

Yes

Add the template

dataset of IED and
the RCB according to Yes
the manufacturer
model

Figure 10 – Functional flowchart of Conversor SCL

2) Procedures
The main goal of carrying out the following procedures is to
prove that it is possible to develop reusable configurations for
a substation, which can be properly converted to a particular
project through interaction with a new engineering tool.
In the sequence of following tests, were associated with the
substation description, two IED's, one belonging to a particular
manufacturer and the other following the concept generic IED,
explained in the previous chapter. The IED association from a
particular manufacturer does not add value to the tests,
allowing only illustrate that this entity does not get in conflict
with the generic entity. It is precisely this generic entity in
 IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010 7

which the experience are focused in, since it is based on  PTOC.Op

similar entities which hypothesis of substations settings reuse  XCBR.Mod
are going to be tested. The substation description is based on
these two IED's interaction with developed software in order to
demonstrate that this allows converting the reusable
specifications in a configuration that represents a particular
case. The procedures were organized taking in consideration
four key steps listed below:
 1st Stage - Import and parameterization of a Siemens
IED in Helinks STS
 2nd Stage - Membership and parameterization of a
generic IED Helinks STS
 3th Stage - Interaction between the resulting SCD file
and Conversor SCL
 4th Stage a) - Importation of SCD File generated on
the Conversor SCL to Helinks STS
 4th Stage b) – Importation of SCD File generated on
the Conversor SCL to DIGSI

The SCD files which constitute the entrance to the Conversor

SCL (3th Stage) has associated in its internal structure, two
IED's,one from Siemens (parameterized in 1st Stage) and a
generic (parameterized in 2nd Stage). As already mentioned, all
IED's from the input file which is not recognized as generics
will remain unchanged in the output file, i.e., Siemens IED
that was associated with the file, should not suffer any
alterations. For the generic IED that is present in the file, the
Conversor SCL will adapt the structure in order to satisfy
particular manufacturer specifications, in this case Efacec. The
files compatibility which is the program output will be
checked for the Helinks STS [4th Stage a)], as for the DIGSI
[4th Stage b)].

a) 1st Stage - Import and parameterization of a Siemens

IED in Helinks STS
The proceeding begins with the IED association at the
substation describing file, through the SCL file importation
with ICD format. In Figure 11, can already be seen the IED
association to the substation, specifically IED_0010 Siemens.
Figure 12 - Internal structure of the IED_0010 in Helinks STS
b) 2nd Stage - Membership and parameterization of a
generic IED Helinks STS
At this procedures stages will be associated with a generic IED
instance in the same substation descriptive file where has been
configured IED_0010. The result of this procedure can be seen
in Figure 13, where it is evident the two IED's presence.

Figure 11 – IED’s considered within the description of a substation in Helinks

STS

The ICD file that gave rise to the represented IED instance was
generated by DIGSI. The responsible structures for vertical
communication of this IED (DataSets and RCB) can be created
in DIGSI before exporting the ICD file, or they can be created
directly in Helinks STS after importing the file. It was decided Figure 13 – IED’s considered within the description of a substation in Helinks
to make the settings through Helinks STS, with the obtained STS
result shown in Figure 12. In this figure, it is analyzed the
instance creation of "Data Set", which was associated with The SCD file resultant from all settings that took place will be
three attributes, namely: interpreted by the Conversor SCL. The level names created
 PDIS.Str during the branch of generic IED structure need to be carefully
 IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010
assigned, since it is through them that the Conversor SCL can
perceive the existence of a generic IED structures and their
constituents. This way, the names from all relevant objects to a
proper program work were pre-defined and represented in the
lateral left section of Figure 9. All branches outlined in this
figure were transcribed for the Helinks STS, as shown in
Figure 14. In a meticulous analysis from this figure, it is verify
the direct correspondence between the names assigned to
objects, and predefined names that were displayed in Figure 9.
Figure 14 - Internal structure of the IED_generico in Helinks STS
In the previous figure can be analyzed that a DataSet instance
was created named "DataSet1" which were set three attributes
listed below.
 XCBR.Pos
 XCBR.BlkOpn
 RREC.BlkRec
This dataset has been associated to a RCB instance called
"Report URCB Control", whose properties are shown in
Figure 15.
Figure 15 - Internal structure of the RCB instance of the IED2_lab in Helinks
STS
th
c) 3 Stage - Interaction between the SCD file and the
resulting Conversor SCL
This testing phase begins with file import from the previous
phase to Conversor SCL. This file has two IED's defined in its
8
internal structure, one belonging to Siemens manufacturer and
the other generic.
Conversor SCL when receiving the file if detects the presence
of a generic IED automatically generates a communication
interface with the user, represented in Figure 16.
Figure 16 - Communication interface with the user of Conversor SCL
The program requires user interaction, to answer the four
questions listed below:
•Find IED generic. Replace? [Y / n];
•Insert IED name that will replace the generic;
•Insert IED manufacturer that will replace the generic;
•Insert serial number;
In Figure 16 are outlined in red the answers that were provided
for this case. As can be seen in the figure, the user has chosen
to proceed with the generic IED substitution for one from
Efacec, with the name IED2_lab and serial number, 903016.
The entire program provided information will be integrated
into the internal structure of the resulting SCD file.
Conversor SCL is performed based on an EXE format file, and
the resulting file called "output.scd" is generated in the same
directory where the executable file is located.
d) 4th Stage a) - Importation of SCD File generated on
the Conversor SCL to Helinks STS
In this test phase, the file which is the output of the Conversor
SCL can now be analyzed with the aim of verifying that the
changes made by the program are consistent with the defined
SCL models. For the "output.scd” file analysis, was used in
first instance Helinks STS. As can be seen in Figure 17 the file
is considering a Siemens IED and an Efacec IED, instead of
one from Siemens and a generic (Figure 14).
Figure 17 – IED’s considered within the description of a substation in Helinks
STS
Still in this phase, it is interest to verify that "Data Set" settings
and RCB were also correctly described in the “output.scd” file.
These fields can be examined at the IED2_lab internal
structure, represented in Figure 18. In this picture it is possible
 IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010 9

to see that "Data Set" field was parameterized with all the
attributes previously defined in Figure 14:
 XCBR.Pos
 XCBR.BlkOpn
 RREC.BlkRec

Figure 19 - Relatório da importação de um ficheiro SCD para o DIGSI

The warnings returned by the import report are not

problematic, just warn the user that the IED's instances to be
imported were not yet defined within the descriptive icon of
the substation. If the user wishes to continue with the import, a
substation description is updated depending on the SCD file,
and returns a new report. This new report no longer shows any
problems (Figure 20).

Figure 20 - Report of importing a SCD file to the DIGSI

After the file has been successfully imported, it is important to

ascertain whether DIGSI recognizes the two IED's presence,
and if for each of them is correctly interpreting the settings
made. Figure 21 shows the analysis that DIGSI recognized the
two IED's association on the substation file description.
Figure 18 – IED’s considered within the description of a substation in Helinks
STS

The results of this test phase, shows that Conversor SCL is

performing the objectives for which it was built, since it
confirms the possibility to a system configuration tool import
the resulting file of the program, correctly interpreting their
internal structure and their settings. Nevertheless, the file
"output.scd" has to be successfully imported by the IED's Figure 21 – IED’s considered within the description of a substation in DIGSI
configuration tool in use (DIGSI), a situation that will be tested
in the next phase. For IED_0010 was configured a RCB with the following
attributes:
e) 4 Stage b) – Importation of SCD File generated on
th
 PDIS.Str
the Conversor SCL to DIGSI  PTOC.Op
To make the import in DIGSI, was created a new substation
 XCBR.Mod
descriptive icon and downloaded the "output.scd” file. When
the created didn’t have any IED associated, the import report Figure 22 reflects the DIGSI interpretation from IED_0010
indicates that both IED_0010 and IED2_lab, were not present settings made in Helinks STS. Comparing the attributes defined
at the substation, and for that reason two warnings appear in the figure, with the attributes that were listed, it is confirmed
which that can be seen in Figure 19. that DIGSI are actually interpret successfully settings.
 IST, MASTERS DISSERTATION IN ELECTRICAL AND COMPUTER ENGINEERING, SEPTEMBER 2010 10

IED's, exporting later a SCL file with a substation description

based on real IEDs. This was achieved successfully and has
been proven that the tool in question meets all the results that
were proposed.

Figure 22 - Internal structure of the RCB instance of the IED_0010 in DIGSI REFERENCES

[1] IEC TC 57, “IEC 61850-6: Communication Networks and Systems in

Conversor SCL only makes effect on generic IED's, i.e., from
the two IED’s presents in SCD files, which compose the
program input only IED2_lab suffer a few changes, so the
positive result for IED_0010 was quite expected. Furthermore,
the configuration of IED2_lab has greater relevance.
For IED2_lab was configured a RCB with the following
attributes:
 XCBR.Pos
 XCBR.BlkOpn
 RREC.BlkRec
The settings that were made in Helinks STS for IED2_lab were
properly interpreted by DIGSI, as shown in Figure 23. The
analogy between the attributes defined in the figure, and the
attributes that were listed, shows that DIGSI are actually
interpreting profitably the settings.
Substations, Part 6: Part 6: Configuration description language for
communication in electrical substations related to IEDs”
[2] Pedro Filipe Moreira Dias, “Projecto estruturado de Sistemas de
Automação em Subestações segundo a norma 61850”, Tese de mestrado,
IST, 2009
[3] Carl Öhlén, “Um IED com conceito modular e prova de futuro”, Rio de
Janeiro, April 23-25, 2006
BIOGRAPHIES
Martins, D.F.R. (1987) is student of Electrical Engi-
neering at the Instituto Superior Técnico in Lisbon,
Portugal. He has worked in research related with the
IEC 61850, with digital IED technology of two
manufactures, Efacec and Siemens.

Pinto de Sá, J.L. (1951, SM 90) is a Professor of Elec-

trical Engineering at the Instituto Superior Técnico in
Lisbon, Portugal. He has worked in Substations ad-
Figure 23 - Internal structure of the RCB instance of the IED2_lab in DIGSI vanced automation since 1981. In the nineties he led the
development of multi-function protective relays for
EFACEC, and from 2001 to 2006 he was with LABE-
This result confirms the overall success of Conversor SCL as
LEC as a coacher and a consultant. His main research
an engineering tool, demonstrating their compatibility with the interests are in Power Systems Protection, protective re-
SCL models specificities defined in IEC 61850. Based on the laying and Substations Automation.
testing procedures carried out, it is confirmed that the created
program is able to convert an IED generic model to the
structure of a particular manufacturer, not compromising the
ability of this file to be imported into the IED configuration
tool in a configurations after stage.

V. CONCLUSION
The IEC 61850 advent and its interoperability and free
allocation principles has brought new perspectives regarding
the design and configuration of systems automation. In this
context, this paper elaborates some proposals to develop new
solutions in terms of engineering tools that were capable to
deal with SCL. The system configuration tool tested, Helinks
STS didn’t show any kind of abnormal situation, when he
underwent DIGSI tools interaction tests. It is possible to
conclude that the compatibility level between some of the
engineering tools, is perfectly feasible to transfer SCL files
with the IED’s settings and substations between software from
different manufacturers.
Finally, the paper focused its approach on building software
with specific features that allow a specific interaction with
SCL files. The engineering tool algorithm built, works in the
sense of cooperation with the engineering tools already
exploited at work, in order to download SCL files with generic