Technical Paper

Empowering Substation Automation System

Verification: Challenges, Solutions, and Future
Directions

Authors

Daniel Katongo | DKatongo@zesco.co.zm

Arulraj Irudayasamy | arulraj.irudayasamy@omicronenergy.com

Notes
This technical document explores common challenges and resolutions associated with SCL engineering, as
well as conventional and standard SAS signal verification, along with interlock logic assessments. Additionally,
it delves into centralized approaches for collecting accurate asset information and disturbance records in IEC
61850 based substation projects.
Content

1 Abstract ..................................................................................................................................................3
2 Introduction ............................................................................................................................................3
3 Challenges..............................................................................................................................................3
3.1 SCL engineering .............................................................................................................................3
3.2 SAS signal and communication testing ..........................................................................................5
3.3 Accurate asset information .............................................................................................................7
3.4 Centralized fault/disturbance records collection .............................................................................7
3.5 Troubleshooting client-server (IEC 61850-8-1) ..............................................................................8
4 Solutions ................................................................................................................................................9
4.1 Creating a high quality SCD file ......................................................................................................9
4.2 Standardized SAS signals and communication testing ............................................................... 11
4.3 Accurate asset name plate information ....................................................................................... 14
4.4 Centralized fault/disturbance record collection ............................................................................ 15
5 Recommendations ............................................................................................................................. 17
5.1 Minimum requirements for the SCD file....................................................................................... 17
5.2 Standardized signal list ................................................................................................................ 17
5.3 Template CID/SCD files............................................................................................................... 17
5.4 Solutions for efficient SCL engineering ....................................................................................... 18
6 Future Directions ................................................................................................................................ 19
7 References .......................................................................................................................................... 19
7.1 Technical documents, papers and videos ................................................................................... 19
7.2 IEC/IEEE Standards .................................................................................................................... 19
8 Author Biography ............................................................................................................................... 20
8.1 Daniel Katongo ............................................................................................................................ 20
8.2 Arulraj Irudayasamy ..................................................................................................................... 21
1 Abstract
Substation Automation Systems (SAS) play a pivotal role in the efficient monitoring and control of various
components, including both primary and secondary equipment. These systems collect signals from different
sources, such as process elements, bays, station-level devices and even neighboring substations for tele
protection applications. Additionally, controlled stations (local substations) transmit critical signals to a
controlling station (central/national control center). To ensure efficient operation, maintenance, extension and
upgrade of SAS projects, rigorous assessments are required. These assessments include signal testing,
control command evaluations and interlock logic verification. The assessments are achieved through IEC
61850 client-server and Generic Object-Oriented System Event (GOOSE) communications based on IEC
61850-8-1.

Assessing automation, control, and communication elements in an energized substation project presents
several challenges. Key considerations include the need for a high-quality System Configuration Description
(SCD) file, standardized signal lists based on compatible logical node and data object classes as per IEC
61850-7-4, and engineering data flows between devices. This paper explores solutions for efficient
engineering of System Configuration Language (SCL). It employs an open-source SCL editor based on IEC
61850-6 to rectify missing information and create high-quality SCD file. It also describes a standardized SAS
test process for effective automation control and communication evaluation.

The paper summarizes valuable lessons learned and highlights improvements that must be made to future
substation automation projects.

2 Introduction
This case study involves a retrofit/upgradation project of an existing conventional 66/33/11KV substation
project with numerical protection control IEDs. The aim of this project is to enhance the efficiency by using the
latest model IEDs at the bay and station level and to utilize Client-Server communication services from different
make IEDs that are in our inventory.

3 Challenges

3.1 SCL engineering

The project involves various IEDs from NR, ABB, Schneider Electric and Hitachi Energy. The SCL
engineering used the proprietary ICTs (IED Configuration Tools) for different make IEDs, which is a common
practice in most projects. These tools are responsible for configuring and maintaining the IEDs throughout
their life cycle. However, this also means that there was no unified SCT (System Configuration Tool) used
for the system engineering part of this project, which resulted in some gaps and errors in the SCD file, such
as the substation section and communication services mapping between IEDs. Therefore, there was no
single SCD file for the whole system/substation, which poses a major challenge for the project maintenance.
We only had good amount of information access to the 11KV side of the substation, which had ABB medium
voltage protection and control IEDs configured from PCM600. These IEDs had the substation section
defined with Logical Node binding to the correct conducting equipment, but the other voltage levels still
needed to be configured and merged with the final SCD file. The importing of individual IED configuration
files looked like Figure 1 below.
Figure 1: Import
Imported NR,
NR, Schneider
Schneider Electric,
Electric, and
and ABB
ABB IED
IED SCL file configurations
configurations into SCL Editor
into SCL Editor

There were also many unnecessary default datasets and control blocks used in this project that did not match
the project scheme diagram shown in Figure 2 below.

Figure 2: Default Dataset which are unused and irrelevant for the project.
 The SCD obtained from the multivendor IED configuration tool was ambiguous when imported into the SAS
testing tool. The substation overview was confusing, and the IEDs were not assigned to the correct voltage
and bay levels, as shown in Figure 3 below.

Figure 3: Lacks clarity regarding the substation overview in the SAS testing tool.

3.2 SAS signal and communication testing

To test the conventional SAS signal, we need to verify different input signals from both hardware and
software sources. These include the status of some process level equipment as hardwired inputs to the
BCUs (Bay Control Units), and some software functions from the IED side such as protection. We also need
to check the control signal with interlock and synchronize the whole system to a common SNTP (Simple
Network Time Protocol) clock server time source in a hybrid substation (where only the station and bay level
uses IEC 61850-8-1 part of this project). This is a manual and time-consuming process that involves many
voltage levels, bay levels and IEDs. The test reports are usually created by humans and there is a high risk
of error due to copying and pasting test reports from one bay or project to another without proper verification.
An example of a traditional SAS test report in a word file is shown below in Figure 4.
Figure 4: Traditional SAS test signal test report
3.3 Accurate asset information
One of our main tasks as end users is to manage our substation assets effectively. We need to know what
kinds of assets we have, such as IEDs,make,types and their versions. This helps us comply with
cybersecurity frameworks like NIST (National Institute of Standards and Technology), one of the key
functions of NIST cybersecurity framework 2.0 to identify our assets and their vulnerabilities. By doing so, we
can assess the risk and update the security patches to protect our critical infrastructure, such as substations.

Another reason is to monitor the life cycle of our assets and find the best recommendations and alternatives
when an asset reaches its end of life.

However, collecting accurate asset information is not easy and poses a challenge for the whole system.

3.4 Centralized fault/disturbance records collection

The main function of protection devices in the substation is to monitor the system, detect faults, and isolate
the affected assets and applications as fast as possible. They also generate disturbance records that contain
information about the system before and after the fault.

The disturbance records are stored in the IEDs in the standard COMTRADE format. The COMTRADE1999
format consists of a header file HDR, a configuration file CFG, and a data file DAT. The COMTRADE2013
format uses a single file format CFF. The COMTRADE analyzing tool can help to analyze the data in the
disturbance records.

However, it can be difficult to access and extract the fault data from different vendor IEDs in a substation.

Figure 5: Use the ABB IED Configuration tool to read the disturbance records.

Figure 5 shows an example of how to use PCM600 to access ABB IEDs and read the disturbance records.
3.5 Troubleshooting client-server (IEC 61850-8-1)
Sometimes, the MMS Client (SCADA HMI/RTU) at the station level fails to send control commands to the
bay level IEDs. In such cases, it is important to sniff the client-server communication and analyze the
problem to find a solution.
Some logical nodes are in test mode, but the SCADA is unaware of this. This can be easily verified by going
online and checking the status as shown in Figure 6 below.

Figure 6: The ABB IEDs have a test-related mode in some logical nodes.

There were some orphans (unknown GOOSE messages) in the networks which was identified in quick time
by importing the system model (SCD file) and selecting the unknown IEDs in the Network Sniffer tool shown
in the figure 7 below,
 Figure 7: A GOOSE message was detected in the network using the Network Sniffer.

4 Solutions

4.1 Creating a high quality SCD file

OpenSCD is a tool that we used in this project to complete the SCD file with the necessary information.
OpenSCD is an open-source editor for SCL files, which are based on the IEC 61850-6 standard. It supports
all the versions of the SCL schema for IEC 61850 Ed1, Ed2 and Ed2.1. It allows us to edit the SCL files
easily.
We imported the SCD file which were exported from different IED configuration tools and use OpenSCD to
add the substation, voltage levels, bays and conducting equipment to the SCD file. We also assigned the
standard logical nodes to the appropriate conducting equipment by moving the IEDs to the right bay level.
We use the clone option to quickly add the typical bays and voltage levels to the substation section of the SCD
file. The final SCD file with the complete substation section is shown in Figure 8
Figure 8: The SCL Editor has been used to create the final SCD file, which now includes the previously missing information for the
substation section.

We did not use any GOOSE messages in this project, but we find two GOOSE control blocks in two IEDs from
different manufacturers. We also removed about 140 default datasets that are not used in the project. These
are some of the unwanted configurations that we clean up in the SCL editor, as shown in Figure 9.

Figure 9: The cleanup tool removes unused data sets and control blocks from the SCL editor.

The SCD file with the substation section gives us a clear view of the system design and helps us with
various use cases such as automation, control, communication monitoring, signal testing and assessment.

We imported the final SCD file into a SAS testing tool and performed an offline engineering check under the
system diagram. We check the communication overview for the client-server report control block reference
and verified that it is associated with the correct client. This is shown in Figure 10.
 Figure 10: Overview of client-server offline communication in SAS testing tool.

4.2 Standardized SAS signals and communication testing

The project uses IEC 61850 -8-1 MMS Client-Server for communication between bay level and station level.
We verified the system configuration description (SCD) with the project scheme and the SCADA HMI design
with the live status overview in SAS test tool shown in Figure 11 below.
Figure 11: Live status overview in SAS testing tool.

We synchronized the SAS Test tool with the GPS over SNTP Server, which is the system under test. We
checked the accuracy performance class level of the MMS applications between bay level and station level,
according to IEC 61850-5. The figure 12 below show the results.

Figure 12: The SAS Test tool checks the accuracy class of the NTP time server at the substation.
Figure 13: Testing of performance requirements and data transfer times for various applications according to IEC 61850-5.

We used the SAS testing tool to perform semi-automated and fully automated tests for the signal and control
functions. We got a permission to perform testing activities in one of the spare feeder/bays to verify the
interlock logics with the control function and ran the test cases with automation shown in Figure 14. We
replicated the test case for other bays to save time shown in figure 15. We generated test reports from the
testing tool to standardize the SAS signal testing in figure 16.

Figure 14: Automation testing for control signals with interlock validation.
 Figure 15: Duplicating the test case for typical bays.

Figure 16: Standardized SAS testing report.

4.3 Accurate asset name plate information

The IEC 61850 standard organizes the data in a hierarchical way to model the functions that the IED
supports. For example, one of the functions is to gather the asset information, which is useful for getting the
IED Nameplate data over MMS (IEC 61850-8-1). This information is usually stored in the LPHD (Logical
Node), PhyNam (Physical Device Name Plate-Data Object).
We used the MMS read request service to get the asset information of the whole system in less than 2 minutes
shown in Figure 17. This would normally take hours or even days depending on the substation size with a
traditional method.
 Figure 17: Accurate asset information collected from SAS testing tool.

4.4 Centralized fault/disturbance record collection

The file transfer over MMS service is available in IEC 61850 supported IEDs. This service allows the IEC
61850 MMS Client to request COMTRADE files from the MMS Server (Protection IEDs) on demand.
The use case is to retrieve the disturbance records from a single tool, The final SCD file used in the IEC
61850 test tool allows the user to select a specific IED and go online by choosing the files section, IEC
61850 client initiates a file transfer over MMS to get the disturbance records from protection IED which is
very useful when working with many IED configuration tools shown in Figure 18 and 19.
Figure 18: MMS file transfer request from IED testing tool.

Figure 19: MMS file transfer request traces from Sniffer testing tool.
5 Recommendations

5.1 Minimum requirements for the SCD file

A good SCD file is important for the whole project and system life cycle. It should have these minimum
requirements for our IEC 61850 projects:
- System topology: include substation structure (voltage levels, bays, ...) and LN references
- Project specific data sets: use static data sets for Reports, not dynamic ones that are not in the SCD file
- Meaningful description: use the “desc” Data Attributes for Data Objects as the owner defined
- Correct subscription: specify GOOSE and SV subscribers with <IEDName> elements
- Association of clients: declare Report clients in the reserved Report Control Block with <ClientLN>elements

5.2 Standardized signal list

One of the important tasks to improve the usage of native logical nodes from the IEC 61850-7-4 is to
standardize the signal list for our projects. We realized this a bit late, but creating a signal list is a one-time
job and we will reap the benefits in all our IEC 61850 projects later, whether they are green field, brown field
(extension bays) or upgradation projects.
We aim to create a signal list for each function, such as Bay Control, Feeder, Motor, Generator, Line
Distance, Line/ Transformer /Busbar Differential, Frequency, Auto recloser, etc.
The goal is to utilize the full potential of latest edition of IEC 61850 benefits related to supervision logical
nodes like LTMS, LTRK, LGOS, LSVS, etc.
We also plan to conduct the signal list audit within the SAS testing tool to ensure that the system integrators
follow the standard signal list mandated by ZESCO by importing the master signal list against the specific
project as shown in the Figure 20 below.

Figure 20: Perform a SAS signal audit to ensure consistency among the native logical nodes and data attributes.

5.3 Template CID/SCD files

Creating a template file for different make and types of IEDs may be a tedious work at the very beginning but
it serves in mandating the native logical nodes which are implemented by vendors in several projects.
 The use case is as an end user we plan to provide an example Configured IED Description which contains
on how to handle the Logical Devices, Logical Nodes, DO and creation of dataset, mapping it to different
control blocks like RCB, GCB and MCSVCB with expected naming.
Similarly reference SCD file shows an example on how to handle the Substation section and the different
voltage, bay level, conducting equipment in a standardized way as per our project requirements.

5.4 Solutions for efficient SCL engineering

Project tender specifications should emphasize the Top-Down SCL engineering approach as a long-term
vision, exceeding the minimum requirements for SCD files. This method empowers utilities (DSO-Distribution
System Operators/TSO-Transmission System Operators) to define project needs comprehensively. Using the
SST-System Specification Tool, they specify requirements on a single-line diagram, including substation
sections, switchgear components, and necessary protection, control, and automation elements. Pre-built
templates for logical nodes and data types streamline the process for typical projects.

The generated SSD file feeds into the SCT-System Configuration Tool, an independent system-level tool.
Here, various. ICD-IED Capability Description files from specific equipment types are imported and configured
with unique network parameters like IED names, IP addresses, and access point mappings. This leads to SCL
data flow engineering between IEDs. Project-specific datasets for Client-Server, GOOSE, and Sampled Value
communication are created and mapped to corresponding blocks and clients/subscribers, culminating in the
.SCD-System Configuration Description file.

The ICT-IED Configuration Tool imports the .SCD file into individual projects and binds incoming data to input
signals. Redundancy and time server methods are identified before writing information to real IEDs as CID-
Configured IED Descriptions. This information is exported as a new SCD file and imported back into the SCT
(System Configuration Tool) for consistency across tools.

For IEC 61850 Edition 2 onwards, SCL engineering benefits from pre-configured manufacturer templates for
the IID-Instantiated IED Description. Additionally, IIDs can be exported from the SCT/ICT for typical bay SCL,
accelerating engineering and facilitating efficient data flow across projects.

Introduced in Edition 2, the SED-System Exchange Description enhances collaboration by allowing control
over data flow engineering rights between projects, ensuring consistency during information exchange. Figure
21 further illustrates the Top-Down SCL engineering approach.

Figure 21: SCL engineering concept based on IEC 61850-6 Ed 2.1.

Using the engineering tools ICT (IED Configuration Tool) and SCT (System Configuration Tool) at the
engineering workstation, team members can collaborate on a single project for both protection and IEC 61850
SCL engineering. This will help them achieve a consistent and final project outcome. They can also use a free
and open-source SCL editor that complies with IEC 61850-6, such as OpenSCD, to fill in some of the missing
information in the .SCD file. Additionally, they can refer to the IEC 61850 implementation documents for the
IEDs and tools mentioned below.
 PICS- Protocol Implementation Conformance Statement
It describes the IEC 61850 communication services implementation for a specific type of IED and version.
PICS enables us to choose the right product for our project requirements.
PIXIT-Protocol Implementation eXtra information for Testing
It describes the communication capabilities implemented in a specific IED model and version.
PIXIT allows us to determine the maximum capabilities and behaviour of an IED in terms of different scenarios
of communication services.
MICS - Model Implementation Conformance Statement
It describes the implemented functions and its description of a specific model IED type and version.
Describe the IED functions so that we can understand the function, as well as its logical node and its data
attributes, this is kind of signal list for the specific IED model and versions.
TICS-Technical Issue Implementation Conformance Statement
Clarifications are made regarding the fixes for the technical issues.
It allows us to know the availability of fixes for the identified technical issues in the IEC 61850 standard for a
specific make IED type and version.
SICS-SCL Implementation Conformance Statement.
The document describes the IED, and the System level engineering tools that comply with IEC 61850-6 and
IEC 61850-10.
It is beneficial to know the capabilities of engineering tools.

6 Future Directions
To ensure the IEC 61850 based substation has a future proof design and system verification options, we
recognize the importance of having a high quality SCD file, a standardized signal list, template files and
standard SAS engineering and testing tools that are aligned from the start of the project. We will propose the
necessary steps with the business case that we developed for this project to ZESCO Management, in order
to make this process a mandatory part of the project tender.

7 References

7.1 Technical documents, papers and videos

[1] OMICRON electronics,2023, IEDScout 5.20 and StationScout 2.30 software help sections

[2] OMICRON Academy, 2023-02-21, v 1.10, IEC 61850 Level 1 and 2 Training Courses.

[3] OpenSCD v.0.33.0,2024-02, https://openscd.github.io

[4] Hitachi Energy, June 2023, Revision: S, Line differential protection RED670 Version 2.2 IEC
Technical manual-1MRK505377-UEN

[5] Arulraj Irudayasamy YouTube -IEC 61850 implementation related documentation for IEDs and Tools

[6] National Institute of Standards and Technology (2024) The NIST Cybersecurity Framework (CSF)
2.0. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity White Paper
(CSWP) NIST CSWP 29. https://doi.org/10.6028/NIST.CSWP.29

7.2 IEC/IEEE Standards

[7] IEC 61850-1 Ed.2: 2013-03 Communication networks and systems for power utility automation - Part
1: Introduction and overview.

[8] IEC 61850-2 Ed.2: 2019-04 Communication networks and systems for power utility automation -
Part 2: Glossary.
 [9] IEC 61850-4 Ed.2.1: 2020-11 Communication networks and systems for power utility automation –
Part 4: System and project management.

[10] IEC 61850-5 Ed.2: 2013-01 Communication networks and systems for power utility automation -
Part 5: Communication requirements for functions and device models.

[11] IEC 61850-6 Ed.2.1: 2018-06 Communication networks and systems for power utility automation -
Part 4: Configuration description language for communication in power utility automation systems related to
IEDs.

[12] IEC 61850-7-4 Ed.2.1: 2020-02 Communication networks and systems for power utility automation -
Part 7-4: Basic communication structure – Compatible logical node classes and data object classes.

[13] IEC 61850-8-1 Ed.2.1: 2020-02 Communication networks and systems for power utility automation -
Part 8-1: Specific communication service mapping (SCSM) – Mappings to MMS (ISO 9506-1 and ISO 9506-
2) and to ISO/IEC 8802-3.

[14] IEC 61850-10 Ed.2.1: 2012-12 Communication networks and systems for power utility automation -
Part 10: Conformance testing

8 Author Biography

8.1 Daniel Katongo

Daniel Katongo is currently working as a Principal Engineer – Networks Automation for ZESCO Limited
with over ten years of experience spanning Substation Automation, Protection and Control Systems
integration and Project Management. He holds a Bachelor of Engineering (B.Eng.) in Electrical & Electronics
Engineering from Copperbelt University and a Master of Business Administration (MBA). He is a Professional
Member of the Engineering Institution of Zambia (EIZ) and a Professional Member of the Institute of Electrical
& Electrical Engineers (IEEE). He also holds several certifications in Schneider Electric, ABB & NR Electric
Automation, Protection and Control Systems. He is currently responsible for running operations and
maintenance of Substation Automation Systems (SAS) for the ZESCO Transmission North region
comprising six (06) provinces of Zambia in Southern Africa.

LinkedIn Profile: Daniel Katongo [B.Eng., MBA, MEIZ, REng., MIEEE] | LinkedIn
8.2 Arulraj Irudayasamy

Arul joined as a Regional Application Specialist for Power Utility Communication at OMICRON in 2020,
overseeing IEC 61850 application testing and implementing cybersecurity solutions in the Middle East, Africa,
and Turkey regions.
Over 9 years of experience in the Substation Automation field, Arul began his career as a Relay Service
Engineer at GK Power, specializing in MiCOM Numerical Protection and Control IEDs. He also contributed as
a Substation Automation System (SAS) Engineer on significant projects for AREVA/ALSTOM/GE and
Schneider Electric in India. Following this, he worked as a Verification and Validation Engineer for Bay Level
Products at ABB/Hitachi Energy Global R&D from 2018 to 2020.
He graduated from Saveetha Engineering College, Chennai, India, in 2014 with a degree in Electrical and
Electronics Engineering.

LinkedIn Profile: Arulraj Irudayasamy | LinkedIn