Virtual Digital Substation Test System and Interoperability Assessments

Abstract

Interoperability testing and analysis tools provide a means for achieving and assuring the integrity of multivendor intelligent electronic devices (IEDs) data exchanges. However, the testing and analysis are very time consuming and error prone, and these problems worsen when a substation becomes large and complex during the engineering process, commission, replacement, maintenance, and extension. To address this challenge, this paper presents a virtual digital substation test system (VDSTS) with interoperability analysis tools for assessing and identifying the engineering challenges for the multiple-vendors digital substation. This VDSTS consists of three parts: (i) A virtual digital substation modelling for generating real-time digital substation primary plant operation and fault conditions, (ii) a standard IEC 61850-based substation protection, automation, and control (PAC) system architecture with multivendor IEDs and bay solutions, and (iii) multivendor Substation Configuration description Language (SCL) tools and in-house built data visualisation tool. The study focuses on the interoperability testing of sampled values (SV), generic object-oriented substation events (GOOSE), and manufacturing message specification (MMS) communication services, as defined in IEC 61850. The main issues identified are compatibility issues of SCL tools, protocol implementation issues, different information models, and application limitations. The outcomes will help utilities to reduce the risks associated with the general rollout of digital substations.

1. Introduction

The IEC 61850 standards have been widely applied to substation protection, automation, and control (PAC) systems for real-time applications nowadays [1,2,3,4,5]. The application of digital station and process buses can bring benefits, such as reduced copper cables, fewer construction costs, less commissioning time, maintenance of PAC devices, i.e., intelligent electronic devices (IEDs) in a safer and quicker way, and with increased flexibility for substation extension [1,6]. Additionally, interoperability is a key driver for the adoption of the standards. Achieving full interoperability in multivendor substation PAC systems will allow utilities to confidently deploy new technologies and efficiently manage maintenance, upgrade, and replacement activities.

Due to the flexibility of IEC 61850, the implementation of the standards by various vendors may be different. Many studies [7,8,9,10,11,12,13] have been carried out to test digital solutions and the interoperability of the communication services defined in IEC 61850, i.e., sampled values (SV), generic object-oriented substation events (GOOSE), and manufacturing message specification (MMS). The test results have revealed some interoperability problems, such as compatibility issues of IEC 61850-6 System Configuration description Language (SCL) tools [9,10], difficulties in configuring third-party GOOSE subscriptions [11,12], unsuccessful data reading on human machine interfaces (HMIs) [10,13]. From the point view of performance, the studies in [6,14] tested SV/GOOSE delays under various background traffics, [15] assessed timestamping and processing delays of merging units (MUs) from different manufacturers, [16] studied the response of intelligent electronic devices (IEDs) to SV packet losses, and [17,18] investigated the impact of network redundancy protocols, SV delay, and synchronisation loss on protection functions.

Most interoperability studies from the literature have concentrated on investigating individual device performance. The tests were based on dedicated lab designs (e.g., ad hoc approach) with an interest in sensitivity analysis of IED performance. However, the communication architecture (or network topology) has usually been simplified to one or a few bays with limited types of functional tests [6,18], or to a station bus network or a process bus network only [11,14,17]. Consequently, more distributed applications, such as inter-bay trips, circuit breaker (CB) failure protection, CB synchronisation, interlocking, and station-wide MMS control, have not been fully studied to understand associated interoperability issues. Additionally, the system integration process should be further discussed considering a complex substation where the system integrator needs to handle SCL files from multiple suppliers.

To address these challenges, this paper presents a comprehensive PAC system test platform that consists of key elements for implementing IEC 61850, i.e., substation communication system architecture, SCL integration, data flow visualisation, and interoperability validation. The test system is based on a generic substation PAC system architecture developed from the previous research [19], which considers the requirements for installation, maintenance, replacement, and life-cycle cost of PAC equipment [20].

The test facility consists of a double-busbar substation simulated by a real-time digital simulator (RTDS), and a complete real PAC system that includes multiple bay solutions from different vendors. A data visualisation tool is developed to analyse the interoperability performance by graphically monitoring and plotting SV/GOOSE data links between IEDs. This paper demonstrates the benefits of the proposed architecture and test system through a number of typical test cases with SV, GOOSE, and MMS communications. The interoperability findings are highlighted. The findings can support utilities to develop technical specifications on IEC 61850 configuration, integration, and performance requirements, which will facilitate future deployment.

2. Substation Protection, Automation, and Control System Architecture Design

A key enabler to drive value for secondary equipment, such as AMUs, DMUs, and IEDs, is a standard architecture, designed to deliver standard digital and physical interfaces, which enable the reuse of proven designs to reduce outage time and cost associated with commissioning, maintenance, testing and replacement of PAC solutions, and also enable vendor interoperability. To achieve this objective, the substation PAC system architecture should consider a number of design rules [19,21], such as the following:

• No single activity on the Main 1 protection system (MP1) shall affect the Main 2 protection system (MP2);
• No single failure shall result in the loss of control of more than one bay;
• Fault clearance time shall at least achieve the level of performance of conventional bays.

Figure 1 illustrates a high-level view of the proposed substation PAC system architecture based on the design principles mentioned above. The architecture consists of the following key components.

2.1. Parallel Process Buses

Each individual bay has two physically isolated process buses (PBs) for redundancy purposes. PB1 and PB2 are used to exchange local SV/GOOSE messages for MP1 and MP2 systems, respectively. Optional filter switches may be used if two or more adjacent bays need to share information at the process level, e.g., for mesh corner substations. The bays within a mesh corner (e.g., transformer bay, feeder bay, and mesh corner bay) need to exchange GOOSE messages in order to trip two CBs associated with that corner [6]. However, for double-busbar applications (as shown in Figure 1b), each bay has separated PBs as the protection scheme for each bay operates independently. No connections between bay PBs via filter switches need to be set up in this case.

2.2. Measurement Bus for High-Accuracy Metering and Synchronising

The measurement bus provides a high-bandwidth process bus across bays, i.e., inter-bay process bus. Each bay which requires high-accuracy metering (HAM, e.g., SV with 256 samples per cycle) should install a separate MU connected to the measurement bus. Additionally, normal SV streams (i.e., 80 samples per cycle) can be transmitted between bays via the measurement bus. This is important for CB synchronising function in substations without busbar voltage transformers (VTs). In the UK substations, the busbar running voltage is determined from the VTs of its connected bays. The devices with synchronising function, e.g., bay control units (BCUs), can use the measurement bus to access SV streams from their adjacent bays to determine the running voltage (see more details in Section 5.2).

2.3. Standard Bay Solutions

Different suppliers can provide bay solutions (e.g., MUs and IEDs) in a substation. Each supplier configures its own bay solution. This approach reduces the interoperability issues within a bay and facilitates the transition of substations from conventional through partially digital to fully digital.

2.4. Station Bus Network for Substation Automation and Control

The station bus is mainly an IEC 61850-8-1 MMS network for the local HMI and remote-control centre to control bay solutions. Additionally, the station bus can transmit inter-bay GOOSE signals (e.g., station-wide automation schemes and breaker failure trips) if needed. The station bus and measurement buses are required to be physically separated from process buses [22] for transmission substations considering higher performance and security requirements for process buses. The reliability of the station bus (or measurement bus) can be improved via using the High-availability Seamless Redundancy (HSR) protocol or Parallel Redundancy Protocol (PRP).

All the characteristics discussed above aim to ensure that substation operation can have the least possible overall interruption during maintenance and replacement.

3. RTDS-Based Virtual Digital Substation Test System

Having completed a number of successful piggyback trials of the standard PAC system architecture with individual suppliers, vendor interoperability, in particular at the station bus level, was the key driver behind the development of the virtual digital substation test system (VDSTS) as a real-time, hardware, closed-loop test platform. The test platform uses a real-time digital simulator (RTDS) to simulate the substation primary plant [21,23]. The objective is to provide a lab-based facility implementing the designed PAC architecture with multiple vendor bays solutions. Figure 2 illustrates the lab-based test system, which consists of the following three parts.

3.1. Real-Time Virtual Substation Modelling for Power Plant Using an RTDS

A typical UK 400 kV double-busbar transmission substation has been modelled in an RTDS simulator with PB5 processors. Figure 3 shows the primary plant model which currently only simulates four feeder bays due to the limitation of the RTDS installed in the lab.

The RTDS produces CT and VT signals for analogue merging units (AMUs) via amplifiers, and CB and disconnector (DIS) positions, for digital merging units (DMUs) via binary outputs. With a fault simulated by RTDS, the external IEDs will generate GOOSE trip signals to the DMUs, which will produce binary signals back to the RTDS.

3.2. PAC System with Multivendor Bay Solutions

Five vendor solutions have been installed on the test platform to constitute a secondary system. Figure 4 shows the PAC system with four feeder bay solutions from four suppliers and two vendor HMIs. Figure 5a demonstrates the lab layout.

Each bay implements dedicated Ethernet switches for PB1, PB2, measurement bus, and station bus, respectively. Due to lab limitations, the Rapid Spanning-Tree Protocol (RSTP) has been used to link the station bus switches and measurement bus switches in all bays.

The proposed PAC system architecture also provides flexibility to address hardware limitations. For example, Figure 4 shows that the PB2 in bay 3 is directly connected to the measurement bus to allow inter-bay SV communications for CB synchronisation. An additional AMU can be installed and connected to the measurement bus to remove this link. Additionally, the protection IEDs in bay 4 currently only have one GOOSE port (being used by the station bus); therefore, the DMUs are linked to the station bus (with VLAN) to receive local trips.

3.3. Visualisation Tool

For a PAC system with IEC 61850 network communication replacing the traditional point-to-point hard wires, commissioning engineers may have difficulties in validating PAC signals. To enhance the readiness of site commissioning, a data visualisation tool has been developed for the test platform (see Figure 5b). The tool can monitor and plot the live SV/GOOSE messages between devices once connected to the station or process buses. The status is presented in three colours as follows:

• Green—SV/GOOSE being received;
• Yellow—SV/GOOSE was received but now becomes lost;
• Red—GOOSE data being updated, e.g., trip signal ON in a fault event (see Section 5).

With a substation configuration description (SCD) file, the tool can automatically record GOOSE data changes. By comparing the time stamps encoded (by IEDs) in GOOSE packets, the tool can calculate the transfer time delays for performance diagnosis. For example, Figure 6 illustrates that the tool can be used to measure the time delays T_a, T_b, T_c, and other parameters which are detailed in

Table 1. Time delay and function parameters.

Parameter	Descriptions
Ta	Protection response time = t1 − t0.
Tb	Process bus transfer time = t2 − t1.
Tc	DMU output delay = t3 − t2.
t0	The time when the RTDS generates a fault and is stamped by the RTDS.
t1	The time when MP1 publishes the GOOSE trip. Time stamped by MP1.
t2	The time when the DMU publishes the acknowledgement (via GOOSE) of receiving the trip signal. Time stamped by the DMU.
t3	The time when the RTDS receives a binary output from the DMU and is stamped by the RTDS.
Tn1, Tn2	Network transmission delays of PBs.
f1	Protection function enabled in MP1, e.g., distance protection.
f2	Function that converts incoming signals to Binary Output (BO) signals

.

The visualisation tool intends to support the validation of IEC 61850 signals for commissioning engineers who are less familiar with network communication protocols. The details of using this tool to perform interoperability tests are presented in Section 5.

4. System Integration with SCL

This section presents the integration process with four vendor bay solutions using IEC 61850-6 SCL. The configuration issues identified from the experience of handling multivendor SCL files are highlighted.

4.1. Bay-Solution Approach with Two Stages Bay SCLs

Figure 7 shows the proposed bay-solution approach with the system integration being decoupled into individual bays or so-called two stages SCLs, namely, (i) Stage 1: producing bay SCD file by a vendor at the bay level and (ii) Stage 2: producing system SCD file by the system integrator at the system level. The key steps are the following:

• The system integrator produces a system specification description (SSD) file according to a single-line diagram (SLD) and functional requirements from the utility;
• Each vendor preconfigures its bay by generating an SCD file, i.e., stage 1. A bay SCD file includes the project-specific instantiated IED description (IID) file of each device in the bay. An IID file contains the predefined data sets and control blocks for SV, GOOSE, and MMS messages, as well as SV/GOOSE mappings within the bay;
• The integrator imports all bay SCD files, i.e., stage 2, into a system integration tool to generate a site SCD file. The site SCD file should include inter-bay GOOSE mappings for distributed applications. The integrator will also configure the HMI with MMS reporting and control functions;
• With the site SCD file, each bay vendor reconfigures its bay to receive inter-bay GOOSE if needed.

The bay-solution approach provides an advantage in that the substation is not limited to a single vendor solution during a bay replacement, and the interoperability issues within a bay can be minimised. The system integrator just needs to set up MMS monitoring and HMI control functions and configure inter-bay SV/GOOSE subscriptions if necessary. The bay-solution method simplifies the integration process, compared to the case in which the integrator needs to set up the local process bus communications for third-party bays.

4.2. Integration Challenges

The procedures shown in Figure 7 may become difficult at steps 3 and 4 due to the exchange of SCL files between vendors. The two main challenges are as follows.

4.2.1. Information Modelling

There may be difficulties for the system integrator to understand the functions of each logical node (LN) from the SCD files provided by bay suppliers, especially for generic LNs such as generic automatic process control (GAPC) and generic process I/O (GGIO). A temporary solution is to use a lookup table or to clarify the function in the “desc” parameters of data objects (DOs) or data attribute (DAs). For a long-term benefit, utilities should publish specifications to standardise the data modelling [24].

4.2.2. Tool Compatibility Issues

Ideally, each bay supplier should be able to use a site SCD file generated from a common system integration tool to re-configure its IEDs for inter-bay GOOSE subscriptions. However, this is currently not achievable. From the experience of using various SCL integration tools during the lab setup, most SCL tools can read third-party SCL files and create site SCD files with inter-bay GOOSE mappings. However, an IED configurator cannot recognise the mappings created by a third-party SCL integration tool.

To address the mapping issues, the system has to be integrated by skipping the site SCD file. For instance, if vendor A needs to read vendor B GOOSE (see Figure 7), the vendor A SCL tool will import the vendor B bay SCD to create a GOOSE mapping in its own SCD file and then upload SCD to its vendor A IED configurator. A list of tool compatibility issues identified is highlighted in Section 6.

5. Interoperability Test Cases

Based on the integrated system, a number of functional test cases have been carried out to validate interoperability at process bus, measurement bus, and station bus. The developed visualisation tool has been used to monitor data traffic and to evaluate functional compliance and performance.

5.1. Process Bus Interoperability

In the test system shown in Figure 4, bay 2 has AMU2 and DMU2 from vendor A communicating with MP1 (with distance protection) from vendor B. The process bus interoperability performance was investigated by injecting faults at different locations of the simulated transmission lines and recording the trip reception time. The trip time is calculated by RTDS by measuring the elapsed time from a fault occurrence to the receipt of a binary output from a DMU.

To test the distance protection, three phase ground faults were applied to 25%, 50%, and 100% of the feeder, respectively. The zone boundary for MP1 was configured as 80% for zone 1 (with no delay) and 150% for zone 2 (with 200 ms delay). The fault was repeated 50 times for each location.

Table 2. Fault injection tests for MP1 in bay 2.

Fault Type	Zone	Trip Reception Time (ms)
		Average	Standard Deviation	Maximum
ABC-to-ground (25% of feeder)	Zone 1	23.8	1.340	27.4
ABC-to-ground (50% of feeder)	Zone 1	26.4	1.504	29.4
ABC-to-ground (100% of feeder)	Zone 2	223.7	1.185	226.3

summarises the statistical results. The average time of a Zone 1 trip was 25 ms, which reflected a similar level of protection performance, compared to the other bays using single-vendor solutions, e.g., a maximum of 30 ms trip time, as specified by National Grid, UK.

To validate the relevant messages exchanged between devices, the developed visualisation tool was connected to PBs during the tests. Figure 8 shows a screenshot of the tool detecting that GOOSE messages were changed (in red colour) in bay 2.

Table 3. Example of GOOSE events recorded by the visualisation tool.

NO	IED	GOOSE Signal	Time Stamp	Pre-Value	Post-Value
1	RTDS	CTRL/OUT_GGIO6/Ind.stVal (Fault Injected—Bay 2)	12:12:03.499299943 UTC	0	1
2	BAY2_MP1	CtlCB1/CB1PTRC1/Tr.general (Protection Trip)	12:12:03.513999998 UTC	0	1
3	BAY2_DMU2	RPIT/ProtInGGIO1/Ind2.stVal (Trip Received)	12:12:03.516993343 UTC	0	1
4	RTDS	CTRL/OUT_GGIO7/Ind.stVal (RTDS Trip Received—BAY 2)	12:12:03.521949946 UTC	0	1
5	BAY2_DMU2	RPIT/XCBR1/Pos.stVal (CB Position)	12:12:03.576992571 UTC	80 (On)	40 (Off)

summarises the GOOSE updates recorded by the visualisation tool.

As discussed in Section 3, the “time stamp” in Table 3 was retrieved from GOOSE messages indicating the time stamp for an event. With all devices in the lab synchronised to a central master clock, the transfer delays can be measured by comparing the time stamps between each packet (see Figure 6). From the result, the average transfer time (T_b) for the GOOSE trip from MP1 (vendor B) to DMU2 (vendor A) is around 4 ms, including the network delay and GOOSE processing time of DMU2.

5.2. Measurement Bus Interoperability

The CB synchronising function has been configured for the BCUs in all bays. In Figure 9, each BCU obtains the incoming voltage (V_sync2) from its local bay AMU. The BCU needs to derive the relevant busbar voltage (V_sync1) from the AMUs in other bays which it receives via the measurement bus.

A voltage selection function should be configured for a BCU to decide the busbar voltage as the BCU receives more than one SV stream via the measurement bus. Due to function limits, only vendor B and C BCUs have the capability to configure a voltage selection scheme. The scheme was developed by creating priority lists via programmable logic mappings. The BCUs first receive the switchgear status (via GOOSE generated by the RTDS) from the station bus. Depending on the switchgear status, the BCUs select the SV stream from the highest priority bay (if connected) as V_sync1. This priority-based VT selection scheme is limited by the maximum number of SV streams that one IED can read.

As the measurement bus has multivendor SV streams, CB synchronisation tests will help demonstrate the inter-bay SV interoperability. The test results in Figure 10 indicate that synchronising with the developed VT selection scheme is carried out successfully. Note that tests have also proved that the BCUs from vendors A and D can read third-party SV streams for synchronising with fixed VT sources.

5.3. Station Bus Interoperability

5.3.1. Inter-Bay GOOSE Interoperability via CB Failure Testing

CB failure protection tests have been carried out to assess the inter-bay GOOSE communication. By disconnecting the trip circuit to the RTDS, a CB failure event was created in bay 1. After a pre-set 200 ms delay, vendor A BCU in bay 1 published the CB failure GOOSE trip over the station bus. The IEDs in other vendor bays received the GOOSE message and issued trip signals. The resulting GOOSE changes were saved by the visualisation tool and listed in

Table 4. Exchanged GOOSE data during a CB failure event in Bay 1.

NO	IED	GOOSE Signal	Time Stamp	Pre-Value	Post-Value
1	RTDS	CTRL/OUT_GGIO2/Ind.stVal (Fault Injected—Bay 1)	12:21:37.386099934 UTC	0	1
2	BAY1_MP1	PROT/PTRC1/Tr.general (Protection Trip)	12:21:37.404000043 UTC	0	1
3	BAY1_BCU	PROT/RBRF1/OpEx.general (CB Failure Trip)	12:21:37.611999988 UTC	0	1
4	BAY3_BCU	Ln1_ExternalTrip1/EXT_PSCH1/Op.general(Back Trip—BAY 3)	12:21:37.613273024 UTC	0	1
5	BAY2_BCU	System/GosGGIO2/Ind1.stVal (Back Trip—BAY 2)	12:21:37.613999962 UTC	0	1
6	BAY4_DMU1	MON/SP16GAPC1/Ind15.stVal (Back Trip—BAY 4)	12:21:37.615294635 UTC	0	1

.

The rest three bays have also been tested on the CB failure protection function. The tests were repeated 10 times for each bay. The GOOSE updates were captured by the data visualisation tool to calculate the transfer time of inter-bay GOOSE messages. Figure 11 shows the average transfer delay between multivendor IEDs on the station bus. Note that the delay consists of:

• IED communication processing time to decode and encode GOOSE;
• IED internal logic processing time to map the incoming GOOSE to a back trip;
• Station bus network delay.

The results show the variability of GOOSE transfer time between vendor solutions even though interoperability is achieved. The test system, therefore, provides a platform that can validate functional compliance as per utility requirements.

5.3.2. MMS Interoperability via HMI Monitoring and Control

As shown in Figure 4, the vendor A and E HMIs have been installed on the station bus to provide control and monitoring functionality for all bays. The two HMIs can use MMS reporting services to read measurements, binary indications (or alarms), and CB status from the IEDs of all vendors. Additionally, the HMIs can instruct BCUs (via MMS commands) to control switchgear. The following two issues were identified when configuring the HMI databases:

• Vendor A HMI has interoperability issues when importing SCD files from third parties. To successfully build an IEC 61850 database, the system integrator needs to manually modify some parts of the SCD files as per the proprietary HMI configurator requirements;
• Vendor E HMI has challenges to configure the HMI database to initialise MMS reporting services on IEDs. The HMI will not issue a “Start Reporting” command to an IED which defines all report control blocks (RCBs) under a common “root logical device (LD)” rather than the source LD containing signals to be reported. This problem was addressed at the HMI database side by creating a dummy IEC 61,850 signal/variable coming from the root LD.

6. Discussions

This section summarises the lessons learned from the aforementioned architecture design, system integration, and interoperability tests.

6.1. SCL Configuration—At Tool Level

There are still issues with the compatibility between IED configuration tools and third-party system integration tools.

Table 5. SCL parameters with varying implementations.

Item in SCL	Descriptions
<ExtRef>	This element shows the IED inputs (e.g., GOOSE) from external devices. Different SCL tools may have variations in defining <ExtRef> at different locations in SCL files.
intAddr	This element defines the data attribute where an external input is linked. However, the naming format is not specifically defined in the IEC61850-6 standard.
srcLDInst & srcCBName	These elements define the LD instance containing the source control block and the name of the source control block, respectively. However, some SCL tools have not implemented these parameters.
appID	This is an application identifier for a GOOSE control block. Some SCL tools will change the appID into their default format when importing 3rd party files.
<ServerAt>	This can be used to reference an existing server containing GOOSE and report control blocks. It may not be recognised by some SCL tools, resulting in failed subscriptions.
smvID & APPID	These two parameters are used to identify an SV stream. Some vendor tools have a specific format or value range.

lists the parameters with varying implementations of SCL found during the study. These variations have caused compatibility issues for IED (or SCL) tools when using third-party SCL files. These issues have been reported back to the participated vendors.

6.2. Protocol Implementation—At Device Level

The interoperability tests have also found several issues regarding protocol implementation, such as the following:

▪

The use of “SmpSynch” to represent local or global synchronisation for 9-2 SV messages;

▪

Failed subscriptions to the fixed-length encoded GOOSE as defined in IEC 61850-8-1;

▪

IEDs from some vendors cannot publish GOOSE with data qualities, resulting in issues for test mode.

These implementation issues can only be solved by updating the firmware embedded on IEDs. Therefore, the protocol problems are not similar to SCL issues, which could be quickly solved by manual modifications of SCL files. It is important to check the Protocol Implementation Conformance Statement (PICS) documents of IEDs to understand interoperability limitations at the start and hence avoid issues that may cause project delays.

6.3. Information Modelling

The SCL files provided by all suppliers show a variety of data models (logical nodes) and frequent use of GGIOs or GAPCs without standard semantics. To reduce the integration difficulty, utilities should develop a specification to standardise the LN functions used between vendors. The specification would define which LN (including LN class, prefix, and instance number) should be adopted to represent a specific PAC signal, indication, or alarm in a bay. This approach can improve interoperability by helping suppliers quickly understand third-party SCL files without acquiring additional documents.

6.4. Performance and Application Limitations

From CB synchronisation tests, it has been found that the sampling time delays (e.g., A/D conversion time) of AMUs are different between manufacturers. The IEC 61869-9 AMU standard only specifies that the maximum delay for protective accuracy class outputs shall be less than 2.0 ms, which could still result in up to 36° phase shift for 50 Hz systems. The BCU in bay 3 has been observed with a voltage angle deviation of 12° under a CB closed condition. Therefore, for functions involving multivendor AMUs, IEDs should be able to compensate for the sampling delays when calculating phase angle differences.

Additionally, different IED products have different limits on the number of SV streams that can be read. This could cause challenges for applications requiring multiple SV streams, e.g., CB synchronisation, and busbar protection.

7. Conclusions

This paper presents a standard PAC system architecture design for digital substations and a real-time virtual substation primary plant modelling using RTDS and develops a multivendor test platform to assess the challenges for integration, data visualisation, and interoperability. The test system was integrated using a PAC bay-solution method, reducing the integration complexity while still achieving vendor interoperability. A visualisation tool was also developed to monitor data traffics and facilitate the analyse of interoperability performance.

The studies have shown that the interoperability between IEDs from different vendors is still not yet seamless. Achieving interoperability through a bay-by-bay approach can reduce individual bay configuration time and the integration difficulty of processing multivendor SCL files. The interoperability issues identified have been summarised in this paper. The outcomes of this work show the benefits of the proposed PAC system architecture, PAC bay solutions, and engineering process as well as the potential risks when integrating equipment from multiple suppliers, one of the key issues being SCL file compatibility between bay suppliers and system integrators. The identified key issues can help utilities to develop their configuration guidelines to ensure interoperability and to facilitate the future rollout of digital substations.