Virtual Digital Substation Test System and Interoperability Assessments

: 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 Conﬁguration 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 speciﬁcation (MMS) communication services, as deﬁned in IEC 61850. The main issues identiﬁed 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. RTDS, (2) PAC system architecture with multivendor secondary equipment and bay solutions, and (3) interoperability analysis and visualisation tools.


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

•
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.

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.

Measurement Bus for High-Accuracy Metering and Synchronising
The measurement bus provides a high-bandwidth process bus across bays, i.e., interbay 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).

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.

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.

Measurement Bus for High-Accuracy Metering and Synchronising
The measurement bus provides a high-bandwidth process bus across bays, i.e., interbay 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).

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.

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.

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.

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.

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.

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

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.

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 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.

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.   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.

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; 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.

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: 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.

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 Ta, Tb, Tc, and other parameters which are detailed in Table 1.   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.

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. 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: 1.

Bay-Solution Approach with Two Stages Bay SCLs
The system integrator produces a system specification description (SSD) file according to a single-line diagram (SLD) and functional requirements from the utility; 2.
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; 3.
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; 4.
With the site SCD file, each bay vendor reconfigures its bay to receive inter-bay GOOSE if needed.

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.

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].

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.

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. 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.

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.

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].

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.

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.

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 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 summarises the GOOSE updates recorded by the visualisation tool. 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 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 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 (Tb) 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.    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.

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.

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 (Vsync2) from its local bay AMU. The BCU needs to derive the relevant busbar voltage (Vsync1) 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 Vsync1. 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.   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.     Table 4. 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.

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: 1.
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; 2.
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.

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

SCL Configuration-At Tool Level
There are still issues with the compatibility between IED configuration tools and third-party system integration tools. Table 5 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.

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.

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

SCL Configuration-At Tool Level
There are still issues with the compatibility between IED configuration tools and thirdparty system integration tools. Table 5 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.

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. 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.

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.

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.

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.