How the Engineering Design Process Can Simplify the

Testing of Automation and Control Systems

Eugenio Carvalheira, Andreas Klien
OMICRON electronics
[email protected]

Abstract—During the life cycle of a Substation Automation In a substation with IEC 61850 communication-based in-
System (SAS), testing the communication, interlocking logic terfaces, the process of testing the automation and control
and proper operation of all signals transmitted to Supervisory can be improved by using software to replace some of the
Control and Data Acquisition (SCADA) systems take consider- manual steps previously described. This process can be even
able effort and time. In a substation which makes use of
IEC 61850 communication, all the engineering and configura-
more efficient if some optional features defined by the
tion data can be saved in standard-format files, the so-called IEC 61850 standard are used while exploiting the capabili-
System Configuration Language (SCL) files. This paper pre- ties of the SCL.
sents a new test approach that increases efficiency in testing the
automation and control functionality of a SAS. This paper dis-
cusses the Intelligent Electronic Device (IED) data model and II. IEC 61850 AND THE SCL CONCEPT
SCL file requirements that should be considered when specify- IEC 61850, the international standard for power utility
ing and designing a system. The paper also discusses network communications, defines not only communication protocols,
design considerations to support testing. but data models for substation equipment [3] and abstract
communication services. The three classes of communica-
Keywords—IEC 61850, SCL, Testing, Simulation, Substa- tion services defined by the standard to be used for substation
tion Automation, Control protection, automation, and control are Client/Server,
GOOSE, and Sampled Values (SV). Moreover, the standard
I. INTRODUCTION also specifies a common, vendor independent, configuration
Testing the protection element settings of IEDs and pro- concept. Machine readable configuration information in a
tection schemes are well established practices when testing a XML based standardized format is used in this process – the
Protection, Automation and Control (PAC) system [6]. Tools SCL [2].
and methods are available to support standardized and auto-
mated testing routines. Test plans can be created for specific A. SCL Engineering Process
relay types and schemes to be reused during distinct phases The SCL concept is defined in IEC 61850-6. Its main pur-
of a project, like Factory Acceptance Tests (FAT), Commis- pose is to allow the exchange of communication system con-
sioning, Site Acceptance Tests (SAT) and Maintenance. figuration data, in a compatible way, between different con-
On the other hand, testing the SAS, which involves auto- figuration and testing tools.
mation, control and SCADA functionalities, is usually per- Fig. 1 shows the general concept of the engineering pro-
formed manually. When looking at the time spent during cess of a substation automation system with the usage of SCL
commissioning, for example, testing the automation and data exchange.
communication system is currently more time consuming
than testing the protection functions. Automation systems
have become increasingly complex and the efforts for testing
communication, interlocking logic, and proper operation of
all signals transmitted to SCADA systems have grown dra-
matically.
In substations with conventional hardwired interfaces, all
wiring and cabling connections between IEDs need to be
checked as part of the FAT and SAT. This is performed one-
by-one in a manual process of “green marking” all interfaces
on printed functional and wiring diagrams. For testing the
relay logic, the physical inputs need to be forced, and logic
verified either by monitoring LEDs, outputs or with assis-
tance of the IED software. For testing the SCADA signaling, Fig. 1 SCL Concept
an end-to-end (also referred to as point-to-point) check is The following types of SCL files, with different exten-
performed by stimulating the signals directly at the equip- sions, are specified for exchange of information:
ment level in the switchyard or by forcing them at the IEDs.
Additional documentation is typically required, like a • SSD (System Specification Description): describes
spreadsheet with Remote Terminal Unit (RTU) signal and the single line diagram of the substation, existing
mappings list. voltage levels, primary equipment and required log-

1
 ical nodes for implementing the substation func- The content of a complete SCD file is comprised of these
tions. The SSD file is generated by a System Spec- three parts plus a section with data type templates describing
ification Tool (SST). which data and attributes are used by the IEDs.
• ICD (IED Capability Description): describes the
functional capabilities of an IED type. Each IED
type has its related ICD file. It contains the IED log-
ical nodes, data and supported services. It is gener-
ated by the IED Configuration Tool (ICT).
• SCD (Substation Configuration Description): con-
tains all configured IEDs, the communication con-
figuration and all IEC 61850 aspects for a given sys-
tem. It is created by the System Configuration Tool
(SCT).
• CID (Configured IED Description): contains a sub-
set of the SCD file with all information related to Fig. 2 Simplified SCL Content
one specific IED. Private extensions are allowed.
Edition 2 of the standard defines two other file types. The C. Substation Structure and Functional Naming
IID (Instantiated IED Description) file describes a single IED The substation structure represents the primary system
pre-configured for a specific project and the SED (System architecture and describes which primary equipment func-
Exchange Description) file to be used for exchange of data tions are used, and how the equipment is connected. The ob-
between two different projects. jects in this session are hierarchically structured and desig-
There are three types of engineering tools in this process: nated according to IEC 81346. Fig. 3 shows an example of a
System Specification Tool (SST), System Configuration substation single line diagram following the naming conven-
Tool (SCT) and IED Configuration Tool (ICT). tions of IEC 81346 for the substation structure and equip-
ment such as disconnect switches and breakers.
The SCT allows engineers to design and configure the
system-wide IEC 61850 communication dataflow. ICD files
from all IEDs and the SSD file are imported in the SCT. The
tool should allow the configuration of IEC 61850 related fea-
tures of the IEDs, configuration of horizontal communication
links (GOOSE and Sampled Values) and configuration of
vertical communication links (Client/Server Reports). By us-
ing data from the SSD file, the engineer can also associate
IED functions (Logical Nodes) to the single-line equipment
and functions. Ultimately, the SCD file, documenting the
complete system, is generated by the SCT.
The ICT is a manufacturer-specific tool used to generate
the ICD files and to load the CID configured files into the
IED.

B. SCL Scope Fig. 3 Example Substation Topology

The SCL language in its full scope allows to describe a The main purpose of this section is to derive a functional
model comprising of three basic parts: designation for the IED logical nodes from the substation
structure. When naming signals, applications can make use
• Substation: describes the single line diagram of a of the IED-related naming or the functional-related naming.
switchyard and which primary equipment and func-
tions are used; The substation equipment and func- The functional naming is a signal identification based on
tions are related to logical nodes contained in the the substation structure names down to the LN class, and then
IED; followed by the semantically completely standardized data
• IED: describes all the hardware devices (IEDs) used object and attribute names. The switch position of QB1 in
in the substation automation system. The data bay Q01 of Fig. 3 could then be identified by the path name
model implemented in the IED including its logical AA1D1Q01QB1/CSWI.pos.stVal and be associated with a
devices and logical nodes are described in this part. CSWI logical node of an IED located at bay AA1D1Q01,
IEDs are connected to the communication system where:
via its access-points;
• AA1 – Substation name
• Communication: describes logically possible con-
• D1 – Voltage level name
nections between IEDs in sub-networks by means
• Q01 – Bay name
of access-points (communication ports).
• QB1 – Equipment (disconnect switch) name

2
D. Content and Usage of SCD Files 2. LGOS and LSVS
As explained above, the SCD file is the ultimate file re- Verifying a GOOSE or Sampled Values message that is
sulting from a completed IEC 61850 system design. The being published is not a complicated task. As these messages
SCD file is not only used by engineering tools and for docu- use a multicast mechanism, they can be easily sniffed in the
mentation purposes, but also by testing tools. Testing tools network. However, verifying the subscription of these mes-
can support a more efficient testing, taking advantage of the sages by other IEDs would not be an easy task without the
SCD file information about the substation under test. introduction of supervision logical nodes to the data model
of IEDs.
However, while the standard defines a clear concept for
the engineering process, it does not define a minimum con- IEC 61850-7-4 ed.2 [3] defines the LGOS (Logical Node
tent requirement for the SCD file. Topology information in for GOOSE Subscription) to be used for monitoring the sta-
the substation section, for example, is optional. Information tus of GOOSE subscriptions. Similarly, the LSVS (Logical
in the IED section depends on the capabilities of the specific Node for Sampled Values Subscription) is used to monitor
IED products used in the project. It is clear then that the de- the status of SV subscriptions.
gree of efficiency that testing tools can provide depends on Instances of LGOS and LSVS LNs should be available
the capabilities of selected IEDs and on the overall infor- for each configured subscription to allow testing tools to au-
mation made available in the SCD file. tomatically verify, via a Client/Server connection, the recep-
tion of messages. The testing tool can identify a problem ei-
III. CONSIDERATIONS WHEN ENGINEERING IEC 61850 ther when the GOOSE/SV is not received or when there is a
SYSTEMS configuration mismatch between publisher and subscriber.
Testing requirements should be an integral part of the en- 3. Report Owners and Static Datasets
gineering process. To increase test efficiency, how the SAS Report is a Client/Server service defined by the standard
system will be tested throughout its lifecycle should be and used in SCADA systems to transmit an event list from a
clearly defined during the specification and early design server (IED) to a client (RTU, Gateway or Human Machine
phases. Interface - HMI). It uses the MMS protocol and establishes a
one-to-one connection between clients and servers.
The previous section alluded to the fact that the infor-
mation contained in the SCD file is of extreme importance to Report Control Blocks in the IED data model contain
what the testing tools can deliver. Therefore, it is important configuration parameters about the reports. The standard de-
to understand some of the IED and SCD key requirements fines an optional attribute “owner” which can be used to
for an optimal testing. This section will discuss some of these identify which client is using the report. By polling the Re-
requirements, what to consider and show how to engineer the port Control Block’s owner attribute value, a testing tool can
system. check if pre-configured Client/Server connections are active.
Datasets are used by reports to determine which attributes
A. IED requirements
(signals) of the data model will be included in the report. Da-
1. Test Mode and Simulation Flag tasets can be created statically or dynamically. A dynamic
For testing of already energized substations or during dataset is created by the client after establishing connection
maintenance activities, precaution should be taken to isolate to the server, i.e. the client defines the content of the report.
IEDs under test. This will avoid any accidental breaker trip The content of the dynamic data sets is not described in the
or undesired exchange of signaling between IEDs due to the SCD file and typically documented in a separate and often
test. Edition 2 of IEC 61850 provides two enhanced features inconsistent “SCADA signal table”. On the other hand, a
that should be available to accomplish the test isolation [5]. static dataset is defined in the System Configuration Tool
One of the features is the possibility to put a function or while configuring the IED and cannot be changed by a client.
IED in Test Mode using the data object Mode (Mod). Based The use of static datasets has the advantage that the data in
on the Mod value of individual logical nodes within a logical the report is described in the SCD file and available for doc-
device, the resultant test mode status is determined by the umentation and testing purposes. In any case, the dataset
attribute Behavior (Beh). IED manufacturers usually opt for should include only those data objects (signals) which are in
a simple implementation with one Mod data object used to fact processed by the respective client. Overloading the data
set the entire IED in test mode. The possible values for the set with all the signals available in the IED’s data model will
Mod data objects are: on; blocked; test; test/blocked and off. just create unnecessary network loads, make the signal tests
more difficult and produces very large SCD files.
The other feature is the Simulation Flag in GOOSE and
Sampled Values. Subscribers should support handling of the B. SCD file requirements
simulation flag. The data object LPHD.Sim serves as a In this section, some requirements for the content of SCD
switch between the messages coming from the real IEDs in files are discussed. For illustration purposes, an example of
the system and simulated messages coming from test sets or extracts from SCD files will be shown to demonstrate how
testing tools. the information should be included and the subsequent ben-
efit for testing tools. It is important to mention that users con-
figuring the system should not be manually editing these

3
SCD files. The System Configuration Tool should offer an Switchgear equipment (e.g. breakers and disconnect
easy graphical interface for the creation and configuration of switches) should be associated to IED logical nodes. The en-
the SCD file. gineering tool should allow a graphical configuration of this
association and define them in the SCL Substation section
1. Substation Topology and Association between
using the <LNode> references. Fig. 4 shows the SCL exam-
Switchgear and LNs ple of the breaker QA1 at bay Q01 which is associated with
As mentioned in the previous section, the substation por- the logical nodes "XCBR", "XSWI" and "CSWI" of the IED
tion of the SCD file is optional. If the engineering tools sup- named AA1D1Q01Q1. Fig. 6 shows these signals associated
port the configuration and this section is structured properly, with the QA1 breaker when selecting it from the diagram of
testing tools can display the IEDs and equipment in the right the testing tool. As they are associated with logical nodes
location in a structured way. from IED Q1, the tool can indicate whether these signals are
Fig. 4 shows part of the SCL substation section for our being transmitted by the IED via GOOSE or Reports. In
example substation of Fig. 3. The hierarchical structure Fig. 6 GOOSE signals are represented by the purple lines,
<Substation>, <VoltageLevel>, <Bay> and <Equipment> is and Reports are represented by the Teal lines.
present and configured.

Fig. 6 Signals associated with the breaker QA1

Fig. 4 Example of SCL Substation Section
Similar to the breaker, CTs and VTs can also have
Fig. 5 shows an example of a testing tool after importing
<LNode> references to "TCTR" and "TVTR" LNs of IEDs.
the SCD file of the example substation of Fig. 3. The 5 bays
(only 3 represented in the figure) of the 380 kV switchgear 2. SCL Description Attributes
are grouped accordingly with the respective breakers and dis- If Data Objects are equipped with SCL "desc" description
connect switches allocated to each bay. The IEDs are also attributes, then the testing tool can display this text as the
allocated in the respective bays. Even though the single-line signal name. Engineering tools often allow the user to enter
diagram information is not fully present in this case, the in- custom names for Data Objects. Instead of visualizing
formation is enough for the testing tool to display the equip- IEC 61850 logical node, data object and attribute names, the
ment and IEDs in a meaningful and understandable way. user can view signals according to his naming conventions.
IEC 61850 complexity can be hidden and be displayed only
by request. Fig. 7 shows a clear description of the breaker
position in the main window, while the XCBR logical node
naming is only shown in the detail view.

Fig. 7 Display of Signal Description

3. GOOSE Configuration
The LGOS logical node described within the IED re-
quirements section defines which GOOSEs are being sub-
scribed and allow monitoring the subscription status. The
SCL language offer also other ways of describing subscrip-
Fig. 5 Example Substation displayed in Testing Tool tions. They can be described within the IED section of the
SCL file by either using the <IEDName> element under the

4
GOOSE Control Block (<GSEControl>) or using <In-
puts><ExtRef type="GOOSE"> elements. Fig. 8 shows the
GOOSE configuration of the IED AA1D1Q01Q1 in the SCD
file of our example substation and describes that five other
IEDs are subscribing to it.

Fig. 8 GOOSE subscriptions defined in the SCD

Fig. 11 Testing Tool displaying Report connections
Testing tools are then able to represent the GOOSE links
and relation between publisher and subscribers, as repre- C. Network Design
sented in Fig. 9.
When designing the communication network [4], engi-
neers should take testing aspects into account. While testing
during a FAT may offer flexibility in terms of plugging and
unplugging devices from the network, there should be strong
limitations as soon as the substation is energized. A clear test
procedure and test cases for different scenarios should be
specified during the SAS specification phase. The network
should enable testing without exposing the system to any
possible malfunction or cybersecurity issues.
1. Network Topology
When designing the topology of the network, physical
access points should be clearly defined for testing purposes
and represented in the SAS documentation. The physical lo-
cation of the access points need also to be considered. Test
personnel should be well informed about where to connect
Fig. 9 Representation of GOOSE connections test sets and test laptops for a specific testing event. For mon-
Another valuable information about the GOOSE config- itoring of the communication system, access to all network
uration, which should be included in the SCD file, are the segments, process bus and station bus should be available
“minTime” and “maxTime” attributes. These attributes are giving visibility of the entire system. In case of HSR (High-
optional and describe the minimum and maximum retrans- availability Seamless Redundancy) and PRP (Parallel Re-
mission times used by the IED publishing the GOOSE. dundancy Protocol) redundant networks, the use of RedBox
(Redundant Box) should be considered for connection of test
4. Report Configuration sets.
Like the GOOSE described above, Report connections
for the SCADA system can also be described in the SCD file. 2. Traffic Control
HMIs, RTUs or Gateways can have Report Control Blocks To prevent or minimize overloads, unnecessary traffic
reserved for them. This should be declared using <Cli- can be limited in the network. Multicast or VLAN filtering
entLN> in the <ReportControl> element as illustrated in are two mechanisms that can be used to control traffic in a
Fig. 10 and Fig. 11. network. VLAN, for instance, allows a logical separation of
a network. During the engineering design, each GOOSE and
Sampled Values can be assigned to VLAN domains while
each port in the switches is configured to which VLAN it
belongs to. The ability to test the SAS system should be con-
sidered when designing traffic controls to avoid the need of
any posterior configuration change only for testing purposes.
Fig. 10 Report Control Block with Clients reserved One example, in case of VLAN filtering, is to pre-define
which ports will be used for connecting test sets and config-
ure the VLAN domains of these ports accordingly.

5
 IV. TESTING THE SUBSTATION AUTOMATION SYSTEM Some test cases related to the SAS system are discussed
in the following sections of the paper.
A. Test Approach
As mentioned previously in this paper, testing of the au- B. Verification of Communication Links
tomation and control functionality are usually performed in By loading the SCD file and having access to the network
a manual way. Tools are available offering testing capabili- traffic and MMS connection to the IEDs, the testing tool can
ties on a per IED basis, allowing test and simulation of IEDs automatically validate all GOOSE, Sampled Values and Re-
individually. port communication links.
The method presented here extends the test from single The test set can poll for attributes in the IEDs and vali-
IED testing and simulation to testing of the entire Substation date against the model. It can check, for example, if the Re-
Automation System. The test is entirely based on the SCD port Control Blocks are Enabled and if the Owners of the
configuration file of the system. By importing the SCD file, Reports are the Clients declared in the SCD file.
the entire system can be visualized and all information avail-
able in the SCD is used. The information in the substation GOOSE communication links can be verified for:
section is used to place IEDs and switchgear equipment • GOOSE mismatch on the sender side: by verifying
within their voltage levels and bays. As can be seen in Fig. 5, Control Block settings;
the tester gets to view the system in a very similar way as the • GOOSE publishing errors: by sniffing on the net-
single-line diagram or the local substation HMI, which he is work and comparing against SCD;
already familiar with. • GOOSE subscription errors: by verifying the LGOS
The method proposed is suitable for testing the SAS dur- statuses at each subscribing IED. Mismatches are
ing its entire project lifecycle, which project phases are de- also checked.
scribed at IEC 61850-4 and illustrated in Fig. 12. The tool Fig. 14 illustrates an example where the GOOSE pub-
using this method should support both monitoring as well as lished by an IED is verified in the network but a problem is
simulation of the system. When testing the system, the test identified at one of the subscribers due to a mismatch in the
set should have access to the network traffic and a MMS con- configuration revision. The connection link is highlighted in
nection to the IEDs. yellow and warning signs are displayed to indicate the issue.

Fig. 12 SAS Project Lifecycle

During specification, the SCD file can be validated and

used to support the configuration of devices. Development
and testing of SCADA RTUs and HMIs can start by simulat-
ing the communication behavior of all IEDs in the system.
During the FAT, IEDs that are not yet present can be simu-
lated to test the ones already installed and available. As the
project moves into the commissioning stage, more monitor-
ing and testing of the real IEDs is done instead of simulation.
One of the key factors for an efficient approach is the op-
tion to create test plans. A test procedure can be documented Fig. 14 Check of GOOSE Publisher-Subscriber Links
and reused throughout the SAS lifecycle. Test sequences can
be performed and assessed automatically. C. Testing Interlocking Logics
Logic is implemented in IEDs to cover many automation
functions. They can automatically be tested using this ap-
proach by simulating the inputs of the logic (either via IED
simulation or real switchgear status) and the result of the
logic can be assessed. One application example is the use of
logic for interlocking schemes to ensure proper operation se-
quence of disconnect and grounding switches. To represent
the result of interlocking logic conditions, IEC 61850 repre-
sents the status of the release in the logical node CILO. For
testing, all combinations of inputs can be tested and the logic
output assessed by reading the CILO status values automati-
cally.
Fig. 13 Test Plan Example

6
 check) after the update by executing the test plan already pre-
pared for that device before it is put back into operation.
Those tests can be performed in the substation with all other
IEDs simulated by a modern test tool without affecting the
devices in operation.

V. CONCLUSION
The SCL described in IEC 61850-6 represents one of the
biggest advantages of the standard. It makes possible the in-
teroperability between engineering tools. All aspects of the
communication system can be saved in a SCD file that rep-
Fig. 15 Testing of Interlocking Schemes resents the ultimate documentation of the system. This is par-
ticularly important as more and more of the hardwiring of
D. Troubleshooting by Tracing Signals signals between bays is replaced by the extensive use of
There are multiple transfers of messages and signals GOOSE services and in that way, the SCD file becomes as
within a SAS system. A signal passes multiple steps until it relevant as the as-built drawings and wiring diagrams had
arrives at the control center. If there is an error in this com- been before. However, the lack of tools that exploits the full
munication, the commissioning engineer needs to follow the capabilities of the SCL language was one of the challenges
signal on its way through the SAS. Finding such signal errors faced by early adopters. This situation is changing with the
in the case of conventional hardwired substations is very tools being improved. Some key features defined in the Edi-
time consuming. Using the test method indicated in this pa- tion 2 of the standard are also finally being implemented in
per, within an IEC 61850 substation, it is possible to follow the IEDs.
how the signals propagate through the SAS. Commissioning and maintenance engineers using mod-
ern testing tools can also benefit from all the information
available in the SCD files. To maximize the capabilities of
the tools, key IED and SCL requirements should be met and
consequentially requested in technical specifications for ten-
ders and purchasing contracts. These requirements are dis-
cussed in this paper to support engineers on how the SAS
system should be specified and designed.
An innovative test approach was presented for testing the
Communication, Automation, Control and SCADA part of
the SAS system, which is based on the SCD file information.
Test plans can now be created to document and automate test
procedures that have been very time consuming until now.
Automated test plans also enable a quick re-test after security
patches and firmware updates, which are performed quite of-
ten nowadays. Testing is becoming an integral part of the
system and quickly evolving into a supervision and monitor-
ing role.

Fig. 16 Breaker position transmitted over the SAS VI. REFERENCES

[1] IEC 61850-4 Ed.2: 2011 Communication networks and systems for
E. Testing RTU/Gateway and local HMI Configuration power utility automation - Part 4: System and project management.
Gateways, RTUs and local HMI usually communicate [2] IEC 61850-6 Ed. 2: 2009: Communication networks and systems for
with almost all IEDs in the system, mainly via Reports, but power utility automation - Part 6: Configuration description language
also GOOSE. Typically, several thousand of signals need to for communication in electrical substations related to IEDs.
be tested. During commissioning, at least the most critical [3] IEC 61850-7-4 Ed. 2: 2010: Communication networks and systems for
signals are tested point-to-point by stimulating the signal in power utility automation - Part 7-4: Basic communication structure -
the switchyard. All other signals can be simulated by a test- Compatible logical node classes and data object classes.
ing tool. A test plan can be built with the testing tool simu- [4] IEC TR 61850-90-4: 2013: Communication networks and systems for
lating all IEDs and signals of the substation for a quicker ver- power utility automation - Part 90-4: Network Engineering Guidelines.
ification. [5] C. Brunner, F. Steinhauser, “Testing and IEC 61850 Edition 2 – what
Gateways/RTUs, HMIs and other IEDs in general are of- does it mean for the Protection Engineer”, International Protection
ten exposed to firmware updates and security patches during Testing Symposium, 2010.
their life time. The devices can be easily re-tested (sanity

7
[6] E. Carvalheira, J. Coronel, “A Testing Approach for Commissioning
the entire Protection System in Sampled Values Based Substations”,
SIPSEP – Simposio sobre Protecciones de Sistemas Electricos, Mex-
ico, 2013.
[7] A. Klien, T. Schossig, “New Methods for Testing Automation and
Control”, PACWorld Americas Conference, Raleigh, NC, 2018.

VII. BIOGRAPHIES
Eugenio Carvalheira received his B.Sc. in Electrical Engineering in
Brazil and his M.Sc. in Computational Engineering in Germany. He has over
17 years of experience in the design and commissioning of power systems
protection, automation and control systems. He joined OMICRON in 2008
as an Application Engineer and is currently Engineering Manager for North
America based in Houston, TX. He is also an active member of IEEE-PES-
PSRC.
Andreas Klien received the M.Sc. degree in Computer Engineering at
the Vienna University of Technology. He joined OMICRON in 2005, work-
ing with IEC 61850 since then. Since 2018, Andreas has been responsible
for the Power Utility Communication business of OMICRON. His fields of
experience are substation communication, SCADA, and power systems
cyber security. As a member of the WG10 in TC57 of the IEC he is partici-
pating in the development of the IEC 61850 standard series.