The Journal of Engineering

The 14th International Conference on Developments in Power System

Protection (DPSP 2018)

Virtual site acceptance test platform for IEC eISSN 2051-3305

Received on 3rd May 2018

61850 based substations with multi-vendor

Accepted on 23rd May 2018
E-First on 23rd August 2018
doi: 10.1049/joe.2018.0167
bay solutions www.ietdl.org

Linwei Chen1, Thomas Charton1, Haiyu Li2 , Ray Zhang1

1National Grid, Warwick, UK
2School of Electrical and Electronic Engineering, University of Manchester, Oxford Road, Manchester M13 9PL, UK
E-mail: haiyu.li@manchester.ac.uk

Abstract: IEC 61850 conformance alone does not necessarily guarantee interoperability of devices from different
manufacturers. Achieving full interoperability in a substation protection and control system involving different vendors will
increase the confidence of power utilities to deploy digital bays or substations on site. This study presents the development of a
virtual site test platform to assess the engineering process and interoperability performance for a fully digital substation with
multi-vendor bay solutions. A data monitoring tool has been developed to visualise data flows in IEC 61850 networks, which can
help commissioning engineers to intuitively validate signals like they do for conventional schemes. Case studies are presented
to investigate the interoperability of sampled values, generic object oriented substation events and manufacturing message
specification communication services. The learning from the system integration and testing will help utilities identify potential
issues in engineering phases and hence reduce the risks associated with future site tests.

1 Introduction communication architecture, engineering process, data monitoring

and interoperability. The communication networks have been
For substation secondary systems (i.e. protection and control established based on the National Grid Architecture for Substation
systems), the replacement of hardwired interfaces with
Secondary Systems (AS3) [12], which considers the
communication networks using IEC 61850 can bring benefits, such
commissioning and maintenance requirements as well as the
as significantly reduced outage time for commissioning and
reliability and life-cycle cost of protection and control (P&C)
maintenance, lower cost for wiring, and improved substation
equipment [13].
safety. However, there are still some obstacles to the roll out of
The testing platform is set up by utilising a Real-Time Digital
digital substations due to a number of factors, such as
Simulator (RTDS) with four configurable bay solutions (e.g. MUs,
interoperability issues and a lack of established testing strategies.
protective relays and bay controllers) delivered from various
The IEC 61850 standards have been introduced to facilitate
vendors. Regarding system integration, the interoperability issues
interoperability between Intelligent Electronic Devices (IEDs)
associated with SCL configuration are discussed in this paper.
from different manufacturers by defining common communication
Also, a data visualisation tool is developed for the platform to
protocols, i.e. the IEC 61850-9-2 Sampled Values (SV), IEC
constantly monitor the digitised analogue and tripping signals (i.e.
61850-8-1 Generic Object Oriented Substation Events (GOOSE)
SV and GOOSE packets) in networks and to graphically plot the
and Manufacturing Message Specification (MMS). Many studies
data links between IEDs. With the tool, functional tests are
have been carried out to test the interoperability of SV between
performed to assess the interoperability performance on the process
Merging Units (MUs) and IEDs [1–3], GOOSE between IEDs [4,
bus (local SV and GOOSE) and the station bus (inter-bay GOOSE
5], and MMS between substation Human Machine Interfaces
and station-wide MMS). The outcomes will help utilities to
(HMIs) and IEDs [6, 7]. In the studies, several interoperability
develop their guidelines for system integration and IEC 61850
issues have been reported [7–9]. The main reason for these issues
testing strategy, and hence accelerate the future roll out of digital
is due to various interpretations or implementations of the IEC
substations.
61850-6 System Configuration description Language (SCL). For
instance, certain SCL tools cannot properly interpret the SCL files
from third party tools, resulting in unsuccessful GOOSE 2 Virtual site acceptance test platform
subscriptions. Further studies have been carried out to evaluate Fig. 1 illustrates the test facility with key components. It consists of
interoperability performance under various conditions, such as SV/ three parts: (i) a virtual substation modelling and simulation
GOOSE delays under different background traffics [1, 5], impacts platform, (ii) a substation secondary system with bay solutions and
of SV packet loss on IEDs [10], SV delay with network HMIs provided by multiple vendors, and (iii) a data flow
redundancy protocols and impacts of time synchronisation loss on visualisation tool. The details for each part are described below.
MUs and IEDs [3, 11].
From the literature, most tests have focused on assessing the
2.1 Primary plant modelling
interoperability performance between individual IEDs through
dedicated device-to-device lab designs. The system configuration The virtual substation modelling and simulation platform has been
is relatively simple compared to the integration of a real substation implemented using an RTDS. Fig. 2 illustrates the simulated
with multi-vendor bay solutions. Also, as the communication substation model, which consists of four feeder bays. The
architecture has usually been simplified to one bay or to one substation topology and parameters are based on a National Grid
network (e.g. station bus or process bus only), the interoperability 400 kV double-busbar substation.
issues faced with in real applications, e.g. inter-bay trips, The RTDS generates real-time analogue CT/VT signals for
interlocking, circuit breaker (CB) synchronisation and station-wide Analogue MUs (AMUs) and binary signals, e.g. CB and
MMS control, have not been thoroughly investigated. Disconnector (DIS) positions, for Digital MUs (DMUs). The
This paper presents a multi-vendor secondary system test RTDS can insert phase–phase or phase–ground faults at any
platform that investigates the key aspects of IEC 61850, including
J. Eng., 2018, Vol. 2018 Iss. 15, pp. 791-795 791
This is an open access article published by the IET under the Creative Commons Attribution-NonCommercial-NoDerivs License
(http://creativecommons.org/licenses/by-nc-nd/3.0/)

Fig. 1 Overview of the test platform with key components
Fig. 2 Single-line diagram of the RTDS simulated substation
location along the simulated transmission lines. Trip signals (in
GOOSE) from protective IEDs will be received by DMUs, which
generate binary outputs to control the RTDS.
2.2 AS3-based secondary system
In the test platform shown in Fig. 1, the communication networks
of the secondary system are based on the National Grid AS3
architecture, which consists of the following components [14]:
(a) Independent process buses PB1 and PB2: Considering
reliability, each bay has two independent PBs for Main Protection 1
(MP1) and 2 (MP2) systems. PB1 and PB2 are physically isolated
and used for local bay SV/GOOSE exchanges. For double-busbar
applications as shown in Fig. 1, the process buses are separated
between bays, and hence no filtering functions need to be set up
between bays, resulting in less commissioning and maintenance
time. Mesh corner substations should use appropriate filters for
interconnections between bays.
(b) Measurement bus/inter-bay process bus: The measurement bus
(or inter-bay process bus) provides high accuracy metering (HAM)
across bays. Each bay which requires HAM should provide an
additional AMU connected to the measurement bus. The
measurement bus can be used to check synchronisation for CB
(re-)closing. In National Grid substations, the running voltage of a
busbar is determined by the VTs of its connected bays. Therefore,
the IEDs (e.g. BCU – bay control units) with synchronising
function need to be linked to the measurement bus to access SV
streams across bays.
(c) Standard bay solutions: Bay solutions can be provided by
different vendors. Each vendor configures IEC 61850 devices for
its own bay. This bay-solution based approach reduces the
possibility of having interoperability issues within a bay and also
792
This is an open access article published by the IET under the Creative Commons Attribution-NonCommercial-NoDerivs License
20513305, 2018, 15, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/joe.2018.0167 by CochraneArgentina, Wiley Online Library on [17/10/2023]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
Fig. 3 Secondary system based on the AS3 architecture
Fig. 4 Hardware platform developed in the lab
simplifies the engineering process of system integration. The
details are described in Section 3.
(d) Station bus: The station bus network provides a digital I/O
interface for the local HMI as well as the remote control centre to
monitor and control any bay IEDs via IEC 61850-8-1 MMS. In
addition, inter-bay trip signals (e.g. CB failure trip) could be
transmitted via GOOSE over the station bus.
It is necessary to segregate the station/measurement buses and
process buses, due to higher requirements for process bus
performance as well as security implementation issues. The station
bus (or measurement bus) network can be implemented with
Parallel Redundancy Protocol (PRP) or High-availability Seamless
Redundancy (HSR) Protocol.
Based on the AS3 architecture, Fig. 3 illustrates the secondary
system implemented on the test platform. It consists of four feeder
bay solutions provided by four vendors and two HMIs from two
vendors. Fig. 4 shows a photo of the hardware platform established
in the lab.
In general, each bay uses four Ethernet switches to implement
the network interfaces: PB1, PB2, measurement bus and station
bus, respectively. PB1 and PB2 together provide redundancy for
local P&C functions at the process level of a bay. The station buses
(or measurement buses) in all bays are connected together as a ring
network. Due to the limited functions of the installed switches, the
station bus (or measurement bus) redundancy has been
implemented using the Rapid Spanning-Tree Protocol (RSTP).
However, the PRP or HSR protocol, which can provide zero
recovery time, should be considered for real applications.
Fig. 3 also shows some implementation differences between
vendor solutions. However, the AS3 architecture is flexible enough
to cope with the differences. For instance, in bay 3 (or bay 4), the
PB2 is linked to the measurement bus so that the BCUs in third
party bays can read the SV stream from bay 3 (or bay 4) for CB
synchronisation. This link and the associated data filtering can be
removed by installing a separate merging unit for the measurement
bus. Also, the DMUs in bay 4 are connected to the station bus due
J. Eng., 2018, Vol. 2018 Iss. 15, pp. 791-795
(http://creativecommons.org/licenses/by-nc-nd/3.0/)

Fig. 5 Main user interface of the developed visualisation tool
Table 1 SCL parameters affecting GOOSE mappings
SCL Notes
parameter
ࠑExtRefࠒ This indicates the IED inputs, e.g. GOOSE.
Different SCL tools may defineࠑExtRefࠒat different
locations in SCL files.
intAddr This is used to define the data attribute to which an
external input is linked. However, the naming format
is not specifically defined in the standards.
srcLDInst and These indicate the LD instance containing the
srcCBName source control block and the name of the source
control block, respectively. However, certain vendor
tools have not implemented the parameters.
to the lack of available GOOSE I/O ports on the relays. VLAN
(Virtual Local Area Network) has been set up for the station bus to
segregate the data flows from other bays.
2.3 Visualisation tool
As the IEC 61850 standards replace the traditional point-to-point
hard wires with fibre-optic cables and Ethernet switches,
commissioning engineers cannot easily check the signals from
IEDs and hence may have difficulties in troubleshooting
communication problems. To reduce maintenance difficulties and
validate interoperability, a visualisation tool has been developed (in
C++) for the test platform. The tool can be connected to the station
bus as well as process buses to monitor and plot SV/GOOSE data
links between devices.
Fig. 5 illustrates the interface of the visualisation tool, which
displays the secondary system. By connecting to process buses and
the station bus, the tool can first scan the network to find out
available IEDs and then start to constantly capture SV/GOOSE
packets. As shown in Fig. 5, the tool displays the data flow using
three colours:
• Green for data received,
• Yellow for connection lost, and
• Red for GOOSE updated, e.g. protection trip during a fault
event.
The tool is also able to record the data changes for substation
events. The details are presented in the interoperability tests in
Section 4.
3 System integration
The secondary system with four vendor bay solutions has been
integrated by configuring the IEC 61850-6 SCL files of IEDs. It is
important to investigate the engineering process of integrating a
digital system with multi-vendor bay solutions. The experience will
help utilities identify the potential interoperability issues at the
initial bay configuration stage and hence facilitate the following
system integration. The following sections first describe the
integration process and then discuss the challenges experienced
during the process.
J. Eng., 2018, Vol. 2018 Iss. 15, pp. 791-795
This is an open access article published by the IET under the Creative Commons Attribution-NonCommercial-NoDerivs License
(http://creativecommons.org/licenses/by-nc-nd/3.0/)
20513305, 2018, 15, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/joe.2018.0167 by CochraneArgentina, Wiley Online Library on [17/10/2023]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
3.1 Engineering process with the bay-solution approach
Since the test platform divides the substation into independent
vendor-solution based bays, the system integration can also be
decoupled into individual bays. The bay-solution based system
integration includes three steps:
Step 1: Each vendor provides a pre-configured Substation
Configuration Description (SCD) file for its own bay. A bay SCD
file contains not only the predefined datasets and control blocks of
SV, GOOSE and MMS messages for each device but also SV/
GOOSE mappings within the local bay.
Step 2: The system integrator imports all bay SCD files to generate
an SCD file for the complete substation. The site SCD file may
contain inter-bay GOOSE mappings. The integrator will also set up
signal monitoring and control in the HMI using the bay SCD files.
Step 3: Each vendor then reconfigures its bay to receive inter-bay
GOOSE based on the site SCD file.
The benefit of the proposed bay-solution approach is that each
supplier can quickly configure all IEDs in its own bay and update
them easily if only the information within its bay needs to be
changed. This approach reduces the possibility of having
interoperability issues within a bay. The system integrator will only
configure inter-bay GOOSE/SV or global MMS, which reduces the
complexity of the integration process and maintenance time.
3.2 Challenges and interoperability issues
For the integration steps mentioned above, steps 2 and 3 may have
difficulties due to the interactions between different vendors. The
two main challenges are:
3.2.1 Data modelling: The system integrator may find difficulties
in understanding the physical meaning or functions of the Logical
Nodes (LNs) described in each bay SCD file, especially for the
Generic Automatic Process Control (GAPC) and Generic Process
I/O (GGIO) LNs.
A short-term solution is to use a lookup table (like a gateway
configuration) or to check the ‘desc’ parameter of each Data Object
(DO). Utilities should consider publishing specifications to
standardise the data modelling of IEDs by defining prefixes,
instance numbers and LN classes for functions.
3.2.2 Compatibility issues of SCL tools: The site SCD file may
have inter-bay GOOSE mappings created by a third party system
integration tool. Due to software compatibility issues (e.g. naming
convention), a bay vendor IED configurator may not interpret the
mappings correctly when importing the site SCD file.
Consequently, the bay supplier could not configure IEDs to receive
inter-bay GOOSE messages.
System integration tools from different vendors have been
installed and studied. Although they can create site SCD files with
inter-bay GOOSE mappings, a third party IED configurator cannot
recognise the mappings due to the varying SCL implementations
listed in Table 1.
To avoid the mapping problems, the test system has been
integrated by skipping the site SCD file. For example, if vendor B
needs to subscribe to the GOOSE from vendor A, the vendor B
SCL tool will first import the bay SCD file from vendor A and
define the GOOSE mapping and then send the new SCD file to its
IED configurator.
Even with this distributed integration approach, interoperability
issues have still occurred when transferring SCL files between
different vendor tools. Some parts of the SCL descriptions were
manually changed into the same format, in order to successfully
configure the communications between the four bays. The issues
have been logged and sent back to vendors to improve tool
compatibility in future.
793

Fig. 6 GOOSE updated with a fault event in bay 2
Table 2 GOOSE events in bay 2 logged by the visualisation tool
IED GOOSE signal
1 RTDSa CTRL/OUT_GGIO 6/Ind.stVal (Fault Injected – Bay 2)
2 BAY2_MP1 CtlCB1/CB1PTRC 1/Tr.general (Protection Trip)
3 BAY2_DMU2 RPIT/ProtInGGIO1 /Ind2.stVal (Trip Received)
4 RTDSa CTRL/OUT_GGIO 7/Ind.stVal (RTDS Trip Received – BAY 2)
5 BAY2_DMU2 RPIT/XCBR1/Pos.s tVal (CB Position)
aThe RTDS was configured to publish GOOSE for signal diagnosis.
Fig. 7 Example of RTDS monitored CT currents of bay 3 during a
reclosing transient state
4 Interoperability case studies
Having a successfully integrated system, interoperability tests were
carried out, and data traffic was monitored using the visualisation
tool to evaluate functional compliance and performance. This
section presents a number of functional test cases for the validation
of interoperability at the process bus, measurement bus and station
bus.
4.1 Process bus interoperability – local SV/GOOSE
As shown in Fig. 3, bay 2 has AMU2 and DMU2 from vendor A
communicating with MP1 (with distance protection) from vendor
B. All devices have been successfully configured to achieve both
SV and GOOSE interoperability at the process level. The
performance of the process bus interoperability has been assessed
by generating faults at different locations along the transmission
line and measuring the binary trip reception time. The RTDS
calculates the trip time by measuring the elapsed time from a fault
occurrence to the receipt of a binary output from an external DMU.
794
This is an open access article published by the IET under the Creative Commons Attribution-NonCommercial-NoDerivs License
20513305, 2018, 15, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/joe.2018.0167 by CochraneArgentina, Wiley Online Library on [17/10/2023]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
Time stamp Pre-value Post-value
Sep 7, 201711:23:10.877199888 UTC 0 1
Sep 7, 201711:23:10.892999947 UTC 0 1
Sep 7, 201711:23:10.896988451 UTC 0 1
Sep 7, 201711:23:10.901999890 UTC 0 1
Sep 7, 201711:23:10.956987679 UTC 80 (close) 40 (open)
From the test results, the average time taken to receive Zone 1 trip
was 24 ms but in all instances below 30 ms.
The developed visualisation tool was connected to PB2 of bay 2
during the tests. The corresponding process bus traffic was checked
and traced to validate that the relevant messages were exchanged
correctly. For instance, Fig. 6 illustrates the updated GOOSE links
(in red colour) due to a fault event in bay 2. Table 2 shows the
GOOSE event log saved by the visualisation tool during the fault.
The ‘Time Stamp’ in Table 2 has been decoded directly from
GOOSE messages, which indicates the IED internal timestamp for
an event. As all devices are synchronised to a master clock in the
lab, the transfer delays of signals on the network can be measured
by comparing the timestamps between GOOSE packets. From the
result, the transfer time for the GOOSE trip (vendor B) to DMU2
(vendor A) is around 4 ms, which includes both the network delay
and the GOOSE processing time of DMU2.
4.2 Measurement bus interoperability – inter-bay SV
As the BCUs in all bays have enabled the CB synchronisation
function, the BCUs will perform synchronisation checks before
they issue reclosing signals to DMUs. For each feeder bay, the
incoming voltage is measured by its local AMU, while the
substation running voltage is determined through a number of
inter-bay SV streams over the measurement bus as shown in Fig. 3.
Each BCU should use a proper voltage selection function to
decide the running voltage if there is more than one SV stream on
the measurement bus. The vendor B and vendor C bay solutions
have implemented a simple voltage selection scheme based on
priority lists. The BCUs of both vendors were configured to receive
the plant status (in GOOSE published from the RTDS) via the
station bus. A priority-based selection scheme was then
implemented through IED internal logic mappings. Depending on
the plant status, the BCUs can select an SV stream from the other
three bays as the running voltage. As an example, the current
waveforms are shown in Fig. 7 indicate that the synchronising is
carried out successfully without introducing large overshoot
currents.
J. Eng., 2018, Vol. 2018 Iss. 15, pp. 791-795
(http://creativecommons.org/licenses/by-nc-nd/3.0/)

4.3 Station bus interoperability – GOOSE/MMS
4.3.1 Inter-bay GOOSE interoperability: The inter-bay GOOSE
communication via the station bus has been tested by carrying out
CB failure protection tests. For instance, a CB failure event in bay
1 was created by deliberately disconnecting the trip circuits to the
RTDS and then generating a feeder fault. After a pre-defined time
delay of 300 ms, the BCU (vendor A) published the CB failure trip
to the station bus via GOOSE. The BCUs in bays 2 and 3 and the
DMU1 in bay 4 processed the GOOSE message and issued back
trip signals.
Same CB failure protection tests have also been carried out in
other bays. The corresponding GOOSE data was captured by the
visualisation tool to validate the sequence of events. From the
results, the average time delay for inter-bay GOOSE
communication (incl. coding and decoding time) via the station bus
was 3.1 ms.
4.3.2 MMS interoperability: As shown in Fig. 3, the HMIs from
vendors A and E have been installed at the platform to provide
monitoring and control functionality over the station bus (via
MMS) for all bays. Both HMIs can communicate with the IEDs of
all vendors, provided the following two issues are solved:
(i) For the HMI from vendor A, interoperability issues were found
when importing third party SCD files. Manual modifications of the
SCD files are necessary in order to create an HMI database for IEC
61850 signals.
(ii) For the HMI from vendor E, the challenge is to configure the
HMI to initialise 8-1 MMS reporting services on IEDs. The HMI
may not send a ‘start reporting’ command to an IED if the IED
defines all Report Control Blocks (RCBs) under a common (and
separate) LD (Logical Device) rather than the source LD
containing signals to be reported. To solve this problem, the HMI
database should include at least one IEC 61850 signal/variable
coming from the common LD with RCBs.
5 Conclusions
This paper presents a multi-vendor test platform to investigate the
key aspects of IEC 61850, including architecture, engineering
process, data monitoring and interoperability. A visualisation tool
has been developed to monitor data traffic and validate information
exchanged between devices. Although the interoperability of SV,
GOOSE and MMS has been successfully demonstrated in this
work, several issues still need to be addressed in order to facilitate
the deployment of digital substations:
• The compatibility between IED configurators and third party
SCL integration tools is still an issue. The system integrators
may have to install and use the SCL tools from all bay suppliers
in order to configure GOOSE mappings across bays.
• There is variability between manufacturers regarding IEC 61850
communication ports, i.e. the number of ports, types of data (e.g.
J. Eng., 2018, Vol. 2018 Iss. 15, pp. 791-795
This is an open access article published by the IET under the Creative Commons Attribution-NonCommercial-NoDerivs License
(http://creativecommons.org/licenses/by-nc-nd/3.0/)
20513305, 2018, 15, Downloaded from https://ietresearch.onlinelibrary.wiley.com/doi/10.1049/joe.2018.0167 by CochraneArgentina, Wiley Online Library on [17/10/2023]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
SV or GOOSE/MMS) accepted by each port and redundancy
protocols. The number of SV streams that can be read by an IED
is limited due to the high processing speed requirement. This
may cause limitations for applications requiring multiple SV
streams, e.g. CB synchronisation and busbar protection.
• Collaboration between utilities and suppliers is important for the
standardisation of data modelling and the engineering process.
Standard LN models with predefined naming conventions will
improve the understanding of SCL files from different suppliers.
6 Acknowledgments
The authors thank all participating suppliers for providing
equipment and digital solutions for the test platform.
7 References
[1] Yang, L., Crossley, P.A., An, W., et al.: ‘Design and performance testing of a
multivendor IEC61850-9-2 process bus based protection scheme’, IEEE
Trans. Smart Grid, 2014, 5, (3), pp. 1159–1164
[2] Miswan, N.S., Ridwan, M.I., Hayatudin, A., et al.: ‘Interoperability testing for
digital substation in smart grid domain: a power utility perspective’. 2015 Int.
Symp. on Technology Management and Emerging Technologies (ISTMET),
Malaysia, August 2015
[3] Chen, X., Guo, H., Crossley, P.: ‘Interoperability performance assessment of
multivendor IEC61850 process bus’, IEEE Trans. Power Deliv., 2016, 31, (4),
pp. 1934–1944
[4] Hadbah, A., Ustun, T.S., Kalam, A.: ‘Using IEDScout software for managing
multivendor IEC61850 IEDs in substation automation systems’. 2014 IEEE
Int. Conf. on Smart Grid Communications (SmartGridComm), Venice,
November 2014
[5] Manassero, G., Pellini, E.L., Senger, E.C., et al.: ‘IEC61850-based systems –
functional testing and interoperability issues’, IEEE Trans. Ind. Inf., 2013, 9,
(3), pp. 1436–1444
[6] Yang, M.-T., Gu, J.-C., Lin, P.-C., et al.: ‘Interoperability and performance
analysis of IEC61850 based substation protection system’, Int. J. Electr.
Robot. Electron. Commun. Eng., 2013, 7, (8), pp. 497–504
[7] Koshiishi, K., Kaneda, K., Watabe, Y.: ‘Interoperability experience with IEC
61850-based substation automation systems’. 2012 IEEE PES Transmission
and Distribution Conf. and Exposition (T&D), Orlando, May 2012
[8] Ridwan, M.I., Miswan, N.S., Shokri, M.S.M., et al.: ‘Interoperability in smart
grid using IEC 61850 standard: a power utility prospect’. 2014 IEEE
Innovative Smart Grid Technologies – Asia (ISGT ASIA), Kuala Lumpur,
May 2014
[9] Holbach, J., Rodriguez, J., Wester, C., et al.: ‘Status on the first IEC61850
based protection and control, multi-vendor project in the United States’. 60th
Annual Conf. for Protective Relay Engineers, College Station, March 2007
[10] Chen, X., Guo, H., Crossley, P.: ‘Performance testing of IEC 61850 based
architecture for UK National Grid standardised substation automation
solutions’. 2015 IEEE Power & Energy Society General Meeting, Denver,
July 2015
[11] Ingram, D.M.E., Schaub, P., Taylor, R.R., et al.: ‘System-level tests of
transformer differential protection using an IEC 61850 process bus’, IEEE
Trans. Power Deliv., 2014, 29, (3), pp. 1382–1389
[12] Anombem, U.B.: ‘Evaluation of IEC 61850 process bus architecture and
reliability’. PhD Thesis, School of Electrical and Electronic Engineering, the
University of Manchester, 2012
[13] Anombem, U.B., Li, H.Y., Crossley, P., et al.: ‘Process bus architectures for
substation automation with life cycle cost consideration’. IET Int. Conf. on
Developments in Power System Protection (DPSP), Manchester, March 2010
[14] Charton, T., Chen, L., Li, H., et al.: ‘Virtual site acceptance testing and
training facility (VSATT) for digital substation solutions’. CIGRE Study
Committee B5 Colloquium, Auckland, September 2017
795