Top-down Engineering Process with IEC 81850 at the UCAIUG IEC 61850 Interoperability Testing
by Keith Gray, Cris Dyer and Sina Karimi, POWER Engineers, Inc. USA
The focus here is on application profiles, where the profile specifies what is required to implement a specific application
The International Electrotechnical Commission (IEC) developed IEC 61850 standards to
advance electric power substation automation and controls into a new era of interoperability. Some of the standards were based on the work done by the Utility Communications Architecture (UCA) in the late 1990s and early 2000s. The UCA International Users’ Group (UCAIug) is an unaffiliated, non-profit organization of utility end users, vendors, manufacturers, and consultants whose mission is to help promote the development, adoption, and integration of IEC 61850 and other international standards.
The UCAIug has conducted interoperability (IOP) tests biennially since 2011.In 2021, due to the COVID-19 pandemic, the format of the IOP was changed, and a “virtual” test of the System Configuration Language (SCL) file interchange process was conducted. Once COVID-19 restrictions were loosened, a typical face-to-face (F2F) event was held in the summer of 2022.
POWER Engineers, an engineering consulting firm active throughout the US, was invited to participate in the IOP in both 2021 and 2022. POWER served multiple roles, including developing the configuration files that would be utilized by all participants, developing test plans and additional test configuration files, and serving as witnesses as the various IOP tests were conducted.
This article will discuss the 2021 virtual IOP and the subsequent 2022 F2F IOP from POWER’s perspective. A brief history of the IOP will be presented.
Then, a description of the virtual IOP that occurred in 2021 will be discussed. Finally, the 2022 F2F IOP will be presented from the viewpoint of the representatives of POWER Engineers, including the work done prior to convening at the test site as well as during the week of the IOP.
Interoperability History
The UCAIug serves as a resource for standards working groups undertaking improvements and clarifications to standards, as well as for manufacturers and vendors of hardware and software in the IEC 61850 space. They are also responsible for creating and maintaining the IEC 61850 conformance tests.
Since 2011, the UCAIug has organized a gathering to bring together vendors of hardware and software to conduct testing of the interoperability defined in IEC 61850 and related standards. These IOP testing sessions are meant to be collaborative meetings where vendors can learn how their tools and solutions behave in environments outside their own testing. The published results do not identify individual organizations or equipment, giving vendors an opportunity to assist with the overall goal of improving interoperability in the industry. The objective of the testing is “to fail.” The intent is not to show successful interoperability, but to help identify problems in implementation. These problems might include differing interpretations of a vague standard, conflicting sections of standards, failures of implementation, or disagreements between vendors in interpretation of the standards.
Biennially since 2011, the gathering has brought vendors, consultants, and end-users from around the globe to assist in the development of the test plan, to conduct and to witness the tests, and to create problem reports that result in either action items for the vendors or feedback to the appropriate standards working groups.
POWER has been independently exploring, and working with end user clients, the IEC 61850 protocols and design standards for nearly two decades. In addition, POWER representatives are active in IEC TC57 WG10, which is responsible for IEC 61850, as well as various IEEE and Cigre working groups. Our experience with IEC 61850, and the fact we are an independent systems integrator not tied to any one vendor or manufacturer, made POWER a desirable choice to participate in the development of the system’s configuration and provide a neutral position for witnessing the tests.
2021 Virtual SCL Interoperability Test
SCD File Creation: In the run-up to the 2021 IOP session, the COVID-19 pandemic introduced concerns about how the event could be conducted. With continued surges of COVID-19 around the world in early spring 2021, it was determined that a F2F event would be unlikely. While disappointing, it did give the users’ group an opportunity to test current technology around the SCL virtually. The users’ group first selected a single line topology that built on previous IOPs to begin the test development cycle. The protection, automation, and control scheme functionality of the test configuration was also derived from previous years. The vendors then determined which devices or software they wanted to include in the testing. Examples of devices included merging units, relays, test sets, simulators, and other IEDs.
In parallel to these activities, POWER, serving as the IOP independent integrator, discussed with the users’ group the construction of the Substation Configuration Description (SCD) for the IOP. In previous years, the construction of the SCD was a joint effort of the Substation Configuration Tool (SCT) vendors and others in the users’ group. This would be the first IOP where an independent integrator would develop the SCD. The involvement of a non-vendor integrator in this process was designed to give the SCT vendors the opportunity to obtain feedback from users of the software, and it would also help with validation of the interoperability of the engineering process. There were two SCTs considered for the 2021 virtual IOP, and it was decided that two configurations would be developed in parallel.
Development of the SCTs was straightforward and was based directly on the single line topology for the test substation and the functional descriptions of the connections and schemes. IEC 61850-4 and IEC 61850-6 define the SCT development engineering process. The two chosen SCTs take different approaches to this engineering process. One of the SCTs was developed with more of a top-down engineering approach. For this SCT, the top-down design process consisted of creating virtual IEDs and defining data flows between those virtual IEDs. Once the vendors provided IED Capability Description (ICD) files, the files were imported over the virtual IEDs. The other SCT used more of a bottom-up approach, starting from the ICD files and performing the signal mapping from there.
Basic schemes were considered for the IOP testing. Data collected by the Process Interface Units (PIUs) included system voltages (TVTR), currents (TCTR), and breaker/switch positions (XCBR/XSWI). Signals exchanged between the PIUs, the Bay Protection Unit (BPU), and the Bay Control Unit (BCU) were similarly defined. Signals for protection elements (PTRC, PDIS, PTOC, etc.), breaker fail (RBRF), reclosing (RREC), synchronism check (RSYN), switch controllers (CSWI), and interlocking (CILO) were used in this application. The team leaned heavily on IEC 61850-7-500 in the creation of the final schemes used.
Once the functions, and the signals connecting them, were selected, development of the SCD began. In one SCT, IED datasets were created for three different types of messages: Sampled Values (SV), Generic Object-Oriented Substation Event (GOOSE), and Manufacturing Message Specification (MMS). After these datasets were created, control blocks were created and associated with the appropriate dataset. Finally, in the subscribing device, the published data objects were bound to the appropriate external references (ExtRefs) available to the IED for internal logic. The process was repeated for all the IEDs until the appropriate signals were mapped across the substation. In the other SCT, applications were created to define the signal mapping at a higher level. The SCT itself then automatically created the datasets, control blocks, and mappings.
The SCD file was provided to the vendors at various checkpoints throughout the creation process. Each vendor imported the SCD file into its own IED Configuration Tool (ICT), and the vendors then provided feedback if any errors were identified by the tools. One area of interest was the import process, which can create an iterative loop between the SCT and ICT tools. This may occur for any vendor and any device. Focusing on this feedback loop, with a concerted effort by the vendors to identify errors and then re-verify the import process once the errors had been resolved, was invaluable to the project.
As issues were encountered in the run up to the IOP and during the IOP, minor corrections and modifications to configurations were required to keep the testing moving. For example, if a change was made to an IED configuration, one option was to incorporate an Instantiated IED Description (IID) file. This IID file would incorporate specific configurations for that specific IED that may have been added/modified by the vendor using their ICT. Theoretically, this would reduce the number of changes required, as the IID will generate a new SCD that can be imported to the ICT.
Manipulated SCD Files: An additional aspect of the virtual IOP was testing the tools using separate SCD files, with modifications introduced to validate the tools’ responses. A software application, released under an open-source license and hosted on gitlab.com (https://gitlab.com/keith-gray-powereng/ucaiug-iop) was created by POWER Engineers and Herb Falk, who is the Vice President of Testing at the UCAIug. This application loads the SCD file created using the SCTs and then makes changes to create additional SCD files. These files were then used during the virtual IOP by loading them into the ICTs and validating their responses against the test plan.
2021 Results/Lessons Learned: Implementation of the test didn’t turn out exactly as hoped for. In the run up to the virtual test, there was a corruption in the database in one of the SCTs that would have required significant rework to move forward or even back-track. Given that the team had been developing the SCD in two SCTs in parallel, this wasn’t catastrophic to the IOP testing. It was decided that the secondary SCT would be the primary tool used during the IOP, though some changes were still required as testing started. A couple of long nights/early mornings were required to make these modifications and keep the SCD file ahead of the testing. However, by mid-week, the SCD changes slowed drastically, and testing was able to progress smoothly.
Secondary to the management of the SCD, one key aspect of the testing was to have witnesses for the tests. Not having any allegiance to vendors or specific devices, POWER was able to serve as a witness, which is a neutral role providing an unbiased ruling for tests. The tests were laid out in the weeks and months prior to the virtual IOP event. A test plan was created to validate interoperability between the various tools using the SCL files. ICD, CID, IID, and SCD files were used in the testing. SED files were also partially tested, and this testing produced some valuable problem reports.
In the end, performing the virtual IOP proved valuable to the users group. It also provided a solid framework for the 2022 F2F (hopefully) IOP. In the end, 12 vendors participated, and more than 150 problem reports were published. These problem reports will lead to improvements in vendor implementations of their hardware/software platforms, improvements to the standards, and improvements to the test plans themselves. For more information about the testing and results, refer to the report released by the UCAIug.
2022 Interoperability Test
Preparations for the 2022 F2F IOP began almost immediately after the 2021 virtual IOP. The substation topology would largely remain the same, and the testing would expand with a physical network, a varied architecture, and multiple vendors participating. The tests would expand to include functional tests and increased visualization tools. The F2F event was scheduled for July 18 through July 22, 2022. The host was CESI, the parent company of KEMA Labs in Milan, Italy.
The system topology didn’t change significantly until the call to vendors went out to begin selecting devices and positions. Vendors were free to change, add, or remove devices they had tested in the 2021 virtual IOP. However, the equipment would have to be physically transported to Italy, which led to fewer devices than in the virtual IOP. Some devices also had to be swapped for different models due to availability.
POWER Engineer’s Role: POWER Engineer’s continued our participation in the IOP leading up to and attending in Milan. POWER’s role was set up to be like the virtual, we would use the SCTs to develop the SCD file for the test. This time, there were three vendor tools available to work with. A primary tool, one of the SCTs used in the 2021 virtual IOP, was selected by vote in the users’ group. The other tool from the virtual IOP as well as a new tool were selected as back-ups. POWER chose to continue configuration with the third tool (the primary tool from the virtual IOP) for the educational aspects as well as to have another SCD available after learning what could go wrong from the 2021 virtual IOP.
The lead-up to the IOP found the team in a rush to complete the SCD file and publish it to the vendors. Simultaneous to the integration team working to make progress on the SCTs, the vendors were also working to get ICD files to the integration team in a timely manner. The configuration phase spilled over into the setup the week prior to the scheduled testing in Milan. The integration team traveled early to join the setup, which provided an opportunity for the team to obtain feedback from vendors on questions pertaining to specific devices and the tools themselves.
The Saturday before the testing was scheduled to begin, there were changes identified to the SCD configuration that would continue to affect all three SCTs. While the integration team deeply appreciated the opportunity to learn the disparate tools and would have liked to complete the configurations in each tool, it became clear that the parallel effort of using three SCTs was not going to be practical. The integration team decided that efforts should be focused on the primary tool, and configurations could be imported in other tools if necessary. This path continued through the completion of the IOP.
Like the virtual IOP, the POWER team acted in secondary roles of support and witnessing tests. Since POWER’s UCAIug team members were not tied to any vendor, and the team had a broad range of experiences, they were also able to help troubleshoot and aid vendors as setup and pre-testing commenced.
Challenges: The integration aspects of the 2022 IOP testing were challenging, though they led to a much better understanding of the standards as well as the process of creating the SCD among the IOP participants. In addition, the collaborative nature between end user and vendors was highlighted. The IOP could definitively be considered a non-traditional design given a typical end-user design wouldn’t likely incorporate the number of disparate equipment and vendors. As described earlier, the goal of the IOP is truly to find the weaknesses in the standards, implementations, and the tests themselves.
The first challenge facing the team was the last-minute changes that needed to be made to the configurations that each of the three integrators were developing. Many aspects of the designs were postponed until just before the test setup. It became increasingly clear that maintaining the SCD files in three tools wasn’t practical. A decision was made by the integration team to focus on the primary tool and assist the driver of the tool in coordination, debugging, and configuration. The third SCT provided robust validation rules which proved to be very helpful. By importing an SCD derived in the primary tool, unforeseen issues were quickly discovered and brought to resolution, with changes identified for incorporation in the final tool.
Overall, the integration team worked hand in hand with the SCT and other equipment vendors to make the test successfully fail (pun intended). The tools all received high marks, and many will continue to be used in future IOPs.
Problem reports for the 2022 F2F IOP are still under discussion, and action items have not yet been finalized. Once the reports and action items are completed, the final report summarizing the IOP will be produced and will be made available to the public.
Conclusions: The POWER SCT team must thank all the vendor participants who supported both the 2021 and 2022 IOP testing in so many ways, including providing significant technical guidance and mentorship. The SCT vendors were also very supportive and made themselves readily available to answer questions and provide feedback and solutions to issues as they arose. The entire team was engaged in the spirit of collaborative testing.
The vendors were, of course, most concerned with the specific products they were looking to put through the paces, but when issues came up across the system, it was clear that the 2021 and 2022 IOP participants brought an engineering spirit and were there to help move things forward.
The POWER SCT team took away several key lessons from the testing. First, the chance to review the engineering design process using three different tools increased knowledge of not only the design process itself, but also the format and intent of the configuration files used in the design process. The structure of the ICD, SCD, IID, and CID files were all closely reviewed when errors or warnings were encountered. This provided an opportunity to better understand the standards and ask questions about the intent of the standards and where implementations may be corrected, or the standards shored up.
Second, the chance to dive into engineering design for all the communication protocols described in the standards provided learning opportunities rarely seen in routine projects in North America. Working through the requirements to send GOOSE, MMS, and SV signals, understanding how devices were set up differently for each type of signal, and determining how to navigate the network and successfully configure a signal path were all rewarding and will reap benefits in future projects in the US.
Finally, the 2021 and 2022 IOPs provided the opportunity to dive into a design that may have taken several real-life projects to experience for most participants. The network configuration, with various redundancy methods and approaches, the many IED vendors with often differing implementations, and the test equipment vendors with varying approaches towards simulation, signal injection, and visualization were worth hours upon hours of engineering time all crammed into a couple of mad weeks. We are grateful for the opportunity to participate in the IOP testing and look forward to continuing the work.
Biographies:
Keith Gray eceived his B. Sc. And M. Sc. Degrees in Electrical Engineering from Southern Illinois University Edwards-ville in 2003 and 2005, respectively. Since graduation, he has been working at POWER Engineers, performing SCADA, protection, and automation design and commissioning projects. His areas of interest include digital substations
and IEC 61850. He is currently participating in a Cigre B5 working group
as well as contributing to IEC TC57 WG10 standards. He is a licensed Professional Engineer in Idaho.
Chris Dyer received his Bachelor of Science in Electrical Engineering from the University of Idaho in 1997. Prior to joining POWER Engineers in 2006 Chris worked as a SCADA & Automation Engineer for different manufacturers leading and executing numerous projects from planning to final commissioning. Since joining POWER he has led
various SCADA, Automation, Protection & Control, and commissioning projects along with leading teams as Department and Regional Manager of POWER’s SCADA & Analytical Services Business Unit. Chris is a licensed Professional Engineer in several states and a member of IEEE for over twenty years.
Sina Karimi P.Eng. has 10+ years of experience in the utility industry focusing on the design and commissioning of substation automation, SCADA, and network projects. He received his BSc in Electrical & Computer Engineering from the University of Alberta in Canada and is a licensed Professional Engineer in the province of Alberta. Sina began his career in the utility industry working for a Transmission and Distribution facility owner. He later joined POWER Engineers where he further focused on the design of substation P&C systems based on the IEC 61850 standards. He is currently contributing to IEC TC57 WG10 standards and has been a part of POWER’s involvement with UCAIug’s Interoperability testing.
