0% found this document useful (0 votes)
26 views

PotM 03 2021 Functional Testing IEC 61850 ENU

Uploaded by

김똥기
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
26 views

PotM 03 2021 Functional Testing IEC 61850 ENU

Uploaded by

김똥기
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Functional testing of IEC 61850 based

Substation Automation Systems

1 Introduction functions such as command interlockings, many physical


inputs need to be forced at the same time, and the logic
Testing the protection element settings of IEDs and verified by executing the related control operation.
protection schemes are well established practices when For testing the SCADA signaling, an end-to-end check
testing a Protection, Automation and Control (PAC) system. is performed by stimulating the signals directly at the
Tools and methods are available to support standardized equipment level in the switchyard or by forcing them at
and automated protection testing routines. Test plans the IED’s input terminals. Additional documentation is
can be created for specific relay types and schemes to be typically required, like a spreadsheet with Remote Terminal
reused during distinct phases of a project, like Factory Unit (RTU) signal and mappings list.
Acceptance Tests (FAT), commissioning, Site Acceptance
Tests (SAT) and maintenance. This process, which is preferably performed during FAT
before delivery and installation at site, requires several
Contrary, testing the Substation Automation System weeks for a typical substation and involves several
(SAS), which involves many automation, control and experienced control and SCADA engineers. The following
SCADA functionalities, is usually performed manually. hardware, software and technical competencies shall be
When looking at the time spent during commissioning, available for system testing in the factory:
for example, testing the automation and communication
system is currently more time consuming than testing • Ideally the entire SAS with all bay IEDs, networking
the protection functions. Automation systems have equipment, gateways, HMIs, etc.,
become increasingly complex and the efforts for testing
communication, interlocking logic, and proper operation • A switchgear simulator hardwired to the IEDs (can be
of all signals transmitted to SCADA systems have grown simple switches and LED indicators up to sophisticated
dramatically. PLC based simulators),

In substations, all connection interfaces between IEDs • Control center simulator supporting the used SCADA
and primary equipment need to be checked as part of protocol (e.g. IEC 60870-5-104, DNP3)
the FAT and SAT. For hardwired interfaces, as an example,
this is usually performed one-by-one in a manual process • Network testing tools and the IED specific
of “green marking” all interfaces on printed functional maintenance tools
and wiring diagrams. For testing the implemented logic

© OMICRON electronics GmbH


• Deep knowledge about the implemented vendor Figure 1
products, the IEC 61850 standard and Ethernet
networks in general

• Well prepared test plans and documentation (Signal


spreadsheet, interlocking logics and other test
procedures)

Usually, not all components of the SAS are available at


the factory, e.g. in cases where IEDs are part of switchgear
deliveries and shipped directly to substation site without a
proper system test done before. In such cases, testing must
be exclusively performed on site, with consequences in
terms of efforts and costs.
SCL Concept
Practical experience shows that the better the system
is tested in the factory, the less problems occur during
installation and testing on site, and the more efficient and primary equipment and required logical nodes (LN) for
smooth the project finally is. implementing the substation automation functions.
The SSD file is generated by a System Specification Tool
During the testing procedure, bugs and errors in device (SST).
parameters but sometimes also in the device’ firmware are
detected and fixed. But every update of firmware version • ICD (IED Capability Description): describes the
and as well as any change of device settings requires at functional capabilities of an IED type. Each IED type
least retesting of the involved function, ideally a retest of has its related ICD file. It contains the IED logical
the entire system. This process is not efficient if manual nodes, data and supported services. It is generated by
testing is performed, therefore a new approach towards the vendor specific IED Configuration Tool (ICT).
more automated and efficient system testing is heavily
• SCD (System Configuration Description): contains all
needed. Such a solution is available today and based on
configured IEDs, the communication configuration
the SCL concept which is part of the IEC 61850 standard.
and all IEC 61850 aspects for a given system. It is
created by the System Configuration Tool (SCT).
2 IEC 61850 and the SCL Concept
• CID (Configured IED Description): contains a subset of
IEC 61850, the international standard for Communication the SCD file with all information related to one specific
networks and systems for power utility automation, defines IED. Private extensions are allowed.
not just communication protocols, but also data models
In principle, there are three types of engineering tools
for substation equipment. Moreover, the standard also
in this process: System Specification Tool (SST), System
specifies a common, vendor independent configuration
Configuration Tool (SCT) and IED Configuration Tool (ICT).
concept. Machine readable configuration information in an
Practically, an all-in-one tool and no SSD is often used in
XML based standardized format is used in this process – the
case in single-vendor systems. In multi-vendor installations
System Configuration Language (SCL).
with vendor specific ICTs, typically a dedicated SCT is
used. Today, more and more users understand the need
2.1 SCL Engineering Process for standardization and use an SST for the specification
process.
The SCL concept is defined in IEC 61850-6. Its main
purpose is to allow the exchange of configuration data, The SCT allows engineers to design and configure the
in a compatible way, between different configuration and system-wide IEC 61850 communication dataflow. ICD files
testing tools. from all IEDs and the SSD file can be imported into the
SCT. The tool should allow the configuration of IEC 61850
Figure 1 shows the general concept of the engineering related features of the IEDs, configuration of horizontal
process of a substation automation system with the usage communication links (GOOSE and Sampled Values) and
of SCL data exchange. configuration of vertical communication links (Client/
Server Reports). By using data from the SSD file or by direct
The following types of SCL files, with different extensions, entry, the engineer can associate IED functions (Logical
are specified for exchange of information: Nodes) to the single-line equipment and functions.
Ultimately, the SCD file, documenting the complete system,
• SSD (System Specification Description): describes the is generated by the SCT.
single line diagram of the substation, voltage levels,

© OMICRON electronics GmbH


2.2 SCL Content Figure 3

The SCL language in its full scope allows to describe a


model of the substation comprising of three basic parts:

• Substation: describes the single line diagram of the


substation, primary equipment and functions; The
substation equipment such as a Circuit Breaker is
“connected” to the virtual logical nodes contained in
the IED;

• IED: describes all the hardware devices (IEDs) used in


the substation automation system. The data model
implemented in the IED including its logical devices
and logical nodes are described in this part. IEDs are
connected to the communication system via its access-
Example substation topology
points;

• Communication: describes logically possible 2.4 Content and Usage of SCD Files
connections between IEDs in sub-networks by means
As explained above, the SCD file is the ultimate file
of access-points (communication ports).
resulting from a completed IEC 61850 system design.
The SCD file is not only used by engineering tools and
Figure 2 for documentation purposes, but also by testing tools.
Testing tools can support a more efficient testing,
taking advantage of the SCD file information about the
substation under test.

However, while the standard defines a clear concept


for the engineering process, it does not define a
minimum content requirement for the SCD file. Topology
information in the substation section, for example, is
optional. Information in the IED section depends on
the capabilities of the specific IED products used in the
SCL Content project. So, it is strongly recommended for asset owners
to include minimum requirements on the SCD file into
SAS specifications used for project tenders and service
The content of a complete SCD file is comprised of these
contracts, such as:
three parts plus a section with data type templates
describing which data and attributes are used by the IEDs.
• Substation section must contain all voltage levels, bays
and CBs/disconnectors with their LN references (XCBR/
XSWI, CSWI and CILO)
2.3 Substation Structure and Functional Naming
• Data Objects include „desc“ description attributes with
The substation structure represents the primary system
signal text as defined by the owner,
architecture and describes which primary equipment
functions are used, and how the equipment is connected.
• GOOSE subscriptions use <IEDName> elements in
The objects in this section are hierarchically structured
the <GSEControl> element, and use <Inputs><ExtRef
and designated according to IEC 81346. Figure 3 shows
type=“GOOSE“> elements
an example of a substation single line diagram following
the naming conventions of IEC 81346 for the substation • RTUs/Gateways or HMIs must be defined, have the
structure and equipment such as disconnect switches and Report Control Blocks in the IED reserved and declared
breakers. using <ClientLN> in the <ReportControl> element.

The main purpose of this section is to derive a clear • All data sets used in report reports are of static type (as
functional designation for the abstract logical nodes, dynamic data sets are not documented in the SCD)
which are implemented in the IEDs to the primary
equipment in the substation. Otherwise it might be The better the quality and content of the substation’s
difficult for the system tester to find out which specific SCD file, the higher the efficiency of system testing will
LN-instance in the IED is “connected” to which primary be. A compliant SCD file is also highly supporting later
element in the switchgear. extensions of the station as described later.

© OMICRON electronics GmbH


3 New SAS Testing Approach Based on SCD Files testing for the SAS and significantly reduces the required
testing effort. It comes with a robust and powerful
3.1 Test Approach hardware that allows users to simulate multiple IEDs with
a secure isolation to the SAS networks. This user-friendly
As mentioned, testing of the automation and control software helps to visualize SCL files or tracing signals
functionality are usually performed in a manual way. Since within the substation without any configuration effort.
many years, tools are available offering testing capabilities
on a per IED basis, allowing manual test and simulation of Some practical use cases of StationScout related to
individual IEDs. troubleshooting and testing of SAS are discussed in the
following sections.
The method presented here extends the test from
single IED testing and simulation to testing of the entire
Figure 5
Substation Automation System. The test is entirely based
on the SCD configuration file. By importing the SCD file,
the entire system can be visualized and all information
available in the SCD is used. The information in the
substation section is used to place IEDs and switchgear
equipment within their voltage levels and bays. As can
be seen in Figure 5, the tester gets to view the system in
a very similar way as the single-line diagram or the local
substation HMI, which he is already familiar with.

The method proposed is suitable for testing the SAS


during its entire project lifecycle, which project phases are
described at IEC 61850 4 and illustrated in Figure 4. The
tool using this method should support both monitoring
as well as simulation of the system. When testing, the test
set should have access to the GOOSE network traffic and a
Example SCL loaded into StationScout
MMS connection to the IEDs.

3.3 Verification of Communication Links


Figure 4

By loading the SCD file and having access to the network


traffic and MMS connection to the IEDs, StationScout
can automatically validate all GOOSE, Sampled Values
and Report communication links. The test set can poll for
SAS Lifecycle attributes in the IEDs and validate against the model. The
user can check, for example, if the Report Control Blocks
are currently enabled and if the Owners of the Reports are
During specification phase, the SCD file, the signals and
the Clients declared in the SCD file.
communication services can be validated without need of
any physical device. Later, testing of SCADA gateways and
GOOSE communication links will be automatically verified
HMIs can be performed by simulating the communication
for:
behavior and signals of all IEDs – again without any real
IED. During the FAT, IEDs that are not yet present can be • GOOSE mismatch on the sender side: by verifying
simulated to test those ones which are already available. Control Block settings;
As the project moves into the commissioning stage, more
monitoring and testing of the real IEDs is done instead of • GOOSE publishing errors: by sniffing on the network
simulation. and comparing against SCD;

One of the key factors for an efficient approach is the • GOOSE subscription errors: by verifying the LGOS
option to create test plans. A test procedure can be statuses at each subscribing IED. Mismatches are also
documented and reused throughout the SAS lifecycle. Test checked.
sequences can be performed and assessed automatically.
Figure 6 illustrates an example where the GOOSE
published by an IED is verified in the network, but
3.2 SAS Functional Testing with StationScout StationScout identifies a problem at one of the subscribers
due to a mismatch in the configuration revision. The
StationScout is the innovative testing solution for IEC connection link is highlighted in yellow and warning signs
61850 substations which provides the required testing are displayed to indicate the issue.
features as described before. StationScout simplifies

© OMICRON electronics GmbH


Figure 6 3.4 Troubleshooting by Tracing Signals

There are multiple transfers of messages and signals


within a SAS system. A signal passes multiple steps until
it arrives at the control center. If there is an error in this
communication, the commissioning engineer needs to
follow the signal on its way through the SAS. Finding
such signal errors can be very time consuming. Using
StationScout it is possible to follow how the signals
propagate through the SAS.

Figure 9

Check of GOOSE publisher-subscriber links

3.3 Testing Interlocking Logics

PLC Logic is implemented in most IEDs to cover control and


automation functions. They can be automatically tested
by simulation of the inputs of the logic (either via IED
simulation or real switchgear status) and assessment of
the results of the logic calculations with StationScout. One
application example is the use of logics for interlocking
schemes to ensure proper operation of disconnect and
grounding switches. To represent the result of interlocking
logic conditions, IEC 61850 defines the status of the
release in the logical node CILO. For testing, a subset or
ideally all possible combinations of inputs can be tested,
and the logic output assessed by automatically reading the
CILO status values.
Breaker position transmitted over the SAS
Figure 7
3.5 Testing RTU/Gateway and Local HMI Configuration

Gateways, RTUs and local HMIs usually communicate


with almost all IEDs in the system, mainly via Reports, but
also GOOSE. Typically, several thousand of signals need
Testing of interlocking schemes: Interlocking logics and definition of to be tested per substation. During commissioning, at
test steps in spreadsheert least the most critical signals are tested point-to-point by
stimulating the signal in the switchyard. All other signals
can be simulated by StationScout. A test plan can be built
Figure 8 with StationScout simulating all IEDs and signals of the
substation for a quick verification if the RTU and gateways
are correctly configured.

Gateways/RTUs, HMIs and other IEDs in general are often


exposed to firmware updates and security patches during
their lifetime. Those devices can be easily re-tested after
the update (sanity check) by executing the test plan
which was already prepared for that device before it is put
back into operation. Those tests can be performed in the
substation with all other IEDs simulated by StationScout
without affecting the devices in operation.

Results of interlocking test after execution with StationScout

© OMICRON electronics GmbH


4 Practical Use Case: Extension of an Existing Substation the owner decided to perform the test of the new IEDs
with a spare Interlocking IED and the rest of the substation
For an important 20kV Indoor Substation with around 55 to be simulated by StationScout (Figure 11).
IEDs, 3 busbars and two bus sections in a large industrial
complex, the owner decided to extend the existing At first, the engineer imported the existing SCD file into
substation with several additional bays. The substation a new project data base, added the new IEDs, updated
was commissioned around 10 years ago with a modern the central interlocking IED, the HMI and the gateways in
PAC system based on IEC 61850. Due to the operational order to incorporate the new bays and finally created a
constraints, the extension must be performed without de- new SCD file of the entire substation (existing + extension).
energizing and during operation of the substation. The existing bay control and protection IEDs remained
unaffected and will not be loaded with new parameter
The command interlockings have been implemented by files.
PLC functions in the IEDs and GOOSE is used for exchange
of the relevant signals between the IEDs.
Figure 11

The bay-related interlocks are implemented in the StationScout Interlocking


IED (spare)
respective bay device. In addition, a dedicated station
interlocking IED calculates the station-wide interlockings
(Figure 10). To realize this, the bay devices send their
switch positions and other information via GOOSE to the
Station LAN IEC 61850
interlocking IED, which calculates topological information
such as „busbar 1 grounded“ and sends this information
..... .....
again via GOOSE back to the bay devices, where the final
command releases are calculated. Benefit: If the central existing IEDs simulated new IEDs
by StationScout
device fails, the bay-related interlocks remain available.
And most important: Existing bay IEDs are not affected in
Test setup of the new IEDs in the factory
case of extensions of the substation!

For each disconnector’s open/close operation in the new


Figure 10
bays, test cases with >50 test steps have been defined
Control Center Reports
as a permutation table in a spread sheet (Figure 7) and
Local HMI Interlocking
GOOSE implemented in StationScout. The test cases have been
Gateways
A and B IED created just once for a typical bay and easily copied for the
others.

Finally, those test steps have been executed by simulation


Station LAN IEC 61850 of the existing IEDs and assessment of the relevant CILO
data objects in the new IEDs (Figure 11). This way, the
correct implementation of the interlocking scheme in the
..... .....
central interlocking IED as well as in the new bay IEDs has
IEDs IEDs been verified.
MV Swichtgear - Existing MV Switchgear - Extension

Principle system diagram of the SAS


4.2 Testing of the Updated Gateways

This way of implementation allows subsequent extension A second part of the extension project involves the update
without retesting the existing bays and – when using of the existing gateways with latest CPU hardware and
modern testing tools like StationScout - also during firmware for cybersecurity reasons. Considering the
operation. extensive evolution of hardware and firmware during the
This way of implementation allows subsequent extension past 10 years, a complete retest of around 2.000 signals
without retesting the existing bays and – when using from the IEDs to the Control Center after the update was
modern testing tools like StationScout - also during highly recommended.
operation.
As the station is equipped with redundant gateways, one
of the two gateways can be disconnected from the Station
4.1 Factory Testing of the New IEDs LAN without disturbing remote control from the control
center. Each gateway will be upgraded, and a complete
As the majority of the IEDs are already in operation, the
signal test will be performed by simulating all reports and
IEDs for the new bays could not be factory tested together
SCADA signals with StationScout, verifying the correct
with the existing IEDs and station level devices. Therefore,
function of the gateway up to the control center.

© OMICRON electronics GmbH


4 Conclusion

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 automate the test and
document 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 often nowadays. Testing is becoming
an integral part of the system and quickly evolving into a
supervision and monitoring role.

The authors

Christian Brauner, OMICRON electronics GmbH, Austria


[email protected]

Eugenio Carvalheira, OMICRON electronics Corp., USA


[email protected]

© OMICRON electronics GmbH


OMICRON is an international company serving the electrical power industry with
innovative testing and diagnostic solutions. The application of OMICRON products
allows users to assess the condition of the primary and secondary equipment on
their systems with complete confidence. Services offered in the area of consulting,
commissioning, testing, diagnosis and training make the product range complete.

Customers in more than 160 countries rely on the company’s ability to supply leading-
edge technology of excellent quality. Service centers on all continents provide a broad
base of knowledge and extraordinary customer support. All of this together with our
strong network of sales partners is what has made our company a market leader in the
electrical power industry.

For more information, additional literature,


and detailed contact information of our
worldwide offices please visit our website.

www.omicronenergy.com

You might also like