by Daniel Mulholland, Transpower New Zealand, Jarrad Raumati, Beca, New Zealand and Jakob Vogelsang, Alliander, Germany
Around the world, electricity grids have come to a time of change. Whether it is renewal of existing assets, industrial electrification, new generation sources or decarbonization there is substantial growth in the sector expected over the next 10-15 years. At the same time, there are significant labor and skill shortages in addressing these challenges. Transpower New Zealand is experiencing significant new generation studies and requests at the same time as there is a recognized infrastructure deficit. One solution for this is well standardized, rapidly deployed full digital substations (with IEC 61850 SV, GOOSE and MMS). In 2021 Transpower did a concept report into this concluding there were time and cost savings available. Over the last three years we have been developing a set of designs, a “toolbox” for building digital substations.
Early in the project, engineering tools were a significant problem for multivendor interoperability. However, by working collaboratively with the community in the process of developing a next generation SCT tool, we have achieved a solution that provides significant improvements for digital substation engineering.
Here we discuss features of a next generation tool and our experience of being involved in its development.
Vision
IEC 61850-6 describes the intended engineering process that users should follow to enable efficient configuration of IEC 61850 substations. It outlines the use of the Substation Configuration Language (SCL) to facilitate vendor-agnostic communication between IEDs. The vision of the standard strives to maximize interoperability between IEDs, while making the engineering process easy and efficient.
The reality for many users has been a story of trying to fulfill the intent of the standard, and then arriving at the disappointing conclusion of having a time-consuming and at times error-prone engineering process.
The two engineering processes for SCL are commonly described as the “top-down” and “bottom-up” process.
Top-down
The top-down process involves the use of an SCT to build most of the configuration of a substation. This uses ICD (template) files from IED manufacturers as shown in the IEC 61850 standard in IEC 61850-6 Information flow between tools (see Figure 1).
There is much variation in how the system specification from the substation section (SSD) is used. The vision of the IEC 61850 standard is for the substation section to hold “abstract information” about functional requirements from a specification or tender process to support automation.
This “top-down” process is rarely used despite the introduction of IEC 61850 over twenty years ago.
However, it has recently seen significantly more interest and adoption by users due to advancements in both SCT and ICT software and implementation and extended by the development of IEC 61850-7-6 and 61850-90-30.
Bottom-up
When an SCT is unavailable, or manufacturer’s ICTs do not completely conform to the standard it is necessary to use ICTs to complete the engineering process. This can involve several engineering artifacts (such as drawings, spreadsheets, databases, and so on) to describe the communications between IEDs and keep track of the substation configuration. The ICTs of each individual IED are then used to perform communication mapping in a two-step process:
1. Definition of the signal outputs (GOOSE, SMV, MMS)
2. Configuration of the signal inputs (e.g. ExtRefs)
The “bottom-up” process can be very time-consuming for even the smallest substations, and subject to error at many points throughout. It requires managing several SCL files for each IED, instead of a single SCD file describing the configured substation. Many users adopt this approach because it does not require the use of an SCT, which is often seen as adding further risk and complexity.
Current ICTs
Current ICTs from IED manufacturers sometimes only implement parts of the SCL engineering process. In many cases, the ICTs work well with their IEDs, but are suboptimal with other manufacturer’s IEDs. This has been the experience of many users for some time. Thankfully, substantial improvement over the last few years by manufacturers has occurred. Many are now implementing more of the standard in their products.
Stakeholder Feedback
At the start of the project, Transpower was conscious that doing a multivendor digital substation would be challenging. Despite several tools on the market, few are mature or in widespread use. As Cigre WG B5.50 concluded in their technical brochure:
…the report concludes that IEC 61850 is a complex standard to implement into all the needed products and tools. Thus, some challenges have been encountered in the first years of application of the standard. These challenges have raised several issues by the end users as improvement expectations to the implementation of the IEC 61850 standard. Even though a lot of work and efforts have already been done in improving products and tools, as well as in improving skills, methods and procedures, protection and control engineers still need some more time to further develop and mature the application of the standard, in order to be able to gain the majority and the most significant parts of the expected features and benefits for the end users, of which interoperability and ease-of-use are the most essential ones.
— Cigre TB819 (November 2020) IEC 61850 based substation automation systems – Users expectations and stakeholders’ interactions
The creators spent over 8 years developing this technical brochure, perhaps indicating the depth of issues it addresses. Particular areas mentioned in TB819 relevant to engineering tools were:
- Version handling, change tracking
- Visualizations
- Automatic verification, validity checks
- Reusability
- Import/export
These comments reflected our experience as we encountered issues in our selection of products and initial testing of the engineering process.
Explorations
Project approach: Transpower has traditionally used a multivendor approach for protection systems for both technical and commercial reasons (with six manufacturers used in our conventional systems). We assumed that configuring communications would be possible in a digital substation. We selected devices based on their compatibility with existing platforms and fulfillment of functional requirements. This resulted in a multivendor system with an additional two manufacturers as shown in Multivendor approach (Figure 2).
The interaction of ICTs on other manufacturer’s SCL files was an important aspect to understand. IEC 61850-6 Ed 2.1 was the baseline for comparing behavior while taking into account some of the selected IEDs were only recently Ed 2 certified.
Workflow Issues: Transpower found the workflow for configuring communications between the Protection 1 devices using ICT tools to be challenging to the point of unworkability.
First, in one ICT the user must configure the device with the appropriate subscriptions. Then, the user must transfer files to another ICT to do subscriptions for the other manufacturer. Each transfer had a significant risk of file damage or corruption. Each ICT had a different user interface and different level of capability for doing configuration. In the example given in Exclusive ICT workflow (Figure 3,) each of merging units (MU), bus zone (BZ) and protection (Prot) have communications in both directions. This meant that the user must apply three tools to configure the devices.
Exclusive ICT Workflow: This process is laborious and also requires that the user adapt their workflow to the tools. This results in a regimented approach to configuration as the tool usage must match the communications flow.
It also increases the risk of missing device configurations and holding wrong configurations at each point with the process. It can be difficult to implement this approach depending on the tool maturity to successfully create an SCD file reflecting the full substation configuration. Particular issues include:
- Users need another system (e.g. drawings/spreadsheet) to give an overall view of communications and assign addresses
- Lifecycle management and holding onto a consistent, known configuration is onerous
- It is impractical for large substations
- New ICT tool versions can break a functioning workflow
And this assumes that the ICT tools are compatible with each other. Over the course of the project, we discovered many issues with the interoperability of ICTs. For a time, these appeared insurmountable. They included:
- Inability to export a schema valid IID or SCD file
- Lack of support for SCT modification of supervision nodes (LGOS and LSVS)
- Proprietary Sampled Values subscription process and implementation of GOOSE message quality mapping
- Improper treatment of IEC 61850 schema defaults – some tools encoded defaults and some removed them but not all ICTs would function correctly afterwards
- Proprietary implementation of LGOS message quality supervision through use of ExtRef definition
- Removal of other manufacturer’s namespace declarations
- Wrong handling of Character data XML sections resulting in invalid data
Many of these were explored through laborious XML modification and comparison. Each manufacturer modified their software at least once and not all issues were fully resolved within the project time-frames.
We learned that it is important not to underestimate the time for remediation of issues. Sometimes solving an issue in one ICT can create a new issue for another ICT. We found that having the IEC 61850 standard available as a “single source of truth” helps focus discussion.
Ultimately, these issues pushed us towards using an SCT tool. Part of our concern was that reliance on ICT tools would make multivendor configuration excessively fragile.
Using an SCT Tool
Transpower’s early workflow experience pushed us in the direction of an SCT. With an SCT the workflow shown in SCT workflow Figure 4 is possible:
1. Users create template IEDs with an ICD file (with a template IED)
2. The user then configures all other information in the SCT (as much as possible)
3. ICTs are then only used to write configuration to devices, or perform IED-specific configuration
This approach is much simpler than the one outlined in Exclusive ICT workflow (Figure 3) and allows for a consistent workflow independent of the particular communications flow.
Engineering Process Development
Iterative method for evolving the engineering process (Figure 5)outlines the general approach that was undertaken when developing the engineering process. Often we made hand-modifications to an SCL file, followed by testing to see how the ICT behaved in the absence of a documented capability.
Key functions evaluated were:
- Perform basic SCL file manipulation (create, import, export)
- Create IEDs, rename and delete
- Configure instantiated IEDs (datasets, control blocks, communications)
- Perform subscription mapping (GOOSE, SV)
- Assign supervisions (LGOS, LSVS) to subscribed control blocks
After experiencing difficulties with ICT tools and learning about their capability we began an evaluation of available SCT tools. We slowly began to augment the engineering process with the selected SCT (discussed in the next section). Initially it was only used to instantiate ICD files within a single SCD file. Then we expanded its reach to do communications addressing. As we identified capability gaps and ourselves or the community developed solutions the SCT became more integral to our engineering process.
This allowed us prioritize key functionality and focus our effort for a minimum viable product. As the SCT developed, we documented the engineering process and tested against each manufacturer’s SCL files and ICTs to see if a viable multivendor approach was achievable.
Next Generation Tools: Transpower’s SCT assessment resulted in us working with the community which had formed around a new tool, OpenSCD.
OpenSCD is best described as an open source and community driven ecosystem that provides a variety of software modules to build SCTs, ICTs or a combination of both.
It is open source by choice. There are multiple advantages that come with open-source software, especially for a standard such as IEC 61850. It allows for sharing of the cost that comes with developing such a tool. A large enough community and the fact that everyone can freely contribute allows for faster integration of changes within IEC 61850. By agreeing at the software level, users can come to a common interpretation of the standard. The different interpretations of the standard with different tools is challenging, and can lead to interoperability issues.
OpenSCD is not solely an application (anymore) but has grown into an ecosystem over the course of its development. This is because the requirements of the different contributors to OpenSCD are very different. Although we all need the ability to add (e.g. control blocks to the SCL), the way this needs to happen varies from user to user. This does not come as a surprise given that engineering processes in utilities have grown mostly in isolation over the last few decades. As such, detailed engineering processes can vary substantially from one utility to another. At the same time, IEC 61850 promotes common processes as described earlier. Utilities then have the choice to either change their processes to fit into a commercially available tool, or to invest in an in-house solution.
You could also say OpenSCD is not a tool anymore but a toolbox that enables you to build your own tools that better fit your engineering process. This is potentially the biggest benefit of OpenSCD. Each user can create its own flavour of OpenSCD to fit its individual requirements, by simply assembling the software modules provided by the community into a “distribution.”
Technically this is achieved by having a modular plugin architecture. A plugin is a piece of functionality that can be loaded into a distribution on build or even at runtime. The OpenSCD core component loads plugins. It also includes an XML editing engine, an undo and redo capability and wizard handling.
At its simplest, a distribution is the core and a set of plugins (Figure 6).
Plugins can vary even when aiming to edit the same section of the SCL. There are already multiple plugins in the ecosystem that allow for manipulation of the substation section of an SCL file. They facilitate the user’s freedom of choice to solve similar problems in different ways.
To avoid opinionated views regarding the interpretation of IEC 61850, the OpenSCD ecosystem also has various software modules. One such software module is a common library of functions to manipulate an SCL called scl-lib.
Its objective is to offer:
- Functions to change existing SCL elements (e.g. subscribe and unsubscribe)
- Function to create new elements (e.g. new Reports)
- Functions to traverse SCL (e.g. looking up the GSE communications element for a GOOSE control block)
- High-level functions (e.g. importing an IED)
Plugin authors can use this library to manipulate the SCL (e.g remove a subscription) without the extensive knowledge of the standard to do so. Other use cases are already covered (see the documentation) and we would welcome ideas for further improvements.
Another such software module is a so-called “wizard.” A wizard is a standard dialog designed to edit or create specific SCL elements. One can for instance rename an IED or edit a new DataSet. Any plugin author can use wizards as they come with the core component. Plugin authors must only tell the core to edit and or create an SCL element. The wizard handles the edit complexity and as a result the plugin author does not need to implement this.
The OpenSCD ecosystem also provides a set of UI components that plugin authors can use. They are specifically designed to work with the SCL or XML, such as specially designed input fields, list and tree component. (Figure 7).
That said, a plugin author has significant freedom of choice on how to implement a plugin. It is technically a web based solution, which means it is provided through a JavaScript file. When choosing programming languages and user interfaces, developers have mostly written plugins with Typescript and a modern reactive framework (e.g. Google’s Lit or Svelte). Many frameworks, and even plain Javascript are compatible with the OpenSCD core. This gives freedom to developers to use the tools they are familiar and comfortable with, minimizing the barrier to entry.
As a next generation tool, OpenSCD allows:
- Multiple parallel distributions — an organization can assemble their distribution based on their own needs (see Creating your own OpenSCD Distribution Figure 8.)
- Existence of multiple plugins for a similar use case
- The existence of a plugin market
We expect this to enable:
- Faster plugin development
- Improved feedback to the IEC 61850 standard
- Faster integration of future standards developments
- Clearer interactions between developers and SCL specialists
Some OpenSCD distributions publicly available are listed below. Most plugins are open source and available online with a permissive license (Table 1).
We hope to see this next generation architecture be a solution for developing IEC 61850 engineering tools for a ranger of stakeholders. We would welcome hobbyists, open-source developers, commercial tool providers, IED manufacturers and others. Parties could offer OpenSCD and a selection of plugins as a service, as a supported software package or integrate selected plugins within other tools.
Engineering Workflow
Transpower’s current engineering workflow is in Transpower’s current engineering workflow Figure 9.
Over time, the engineering process shifted from an ICT only approach, to a mixed ICT and SCT approach. By mid-2024 we had realised our goal of using a single SCD file and using only OpenSCD for configuration, except for loading configurations onto IEDs.
This workflow uses one or more OpenSCD plugins to complete each step and allows us to produce a single, whole of substation SCD file. We expect that the engineering workflow will continue to evolve over time as new plugins are developed and the industry grows.
Discussion
Transpower’s use of OpenSCD as an SCT has pushed the boundaries of today’s digital substation engineering workflows. From initially using only ICTs, we have managed in less than 3 years to have a fully SCT based workflow. This allows the configuration of small digital substations in less than a day with appropriate templates. For Transpower, a key part of what made the use of an SCT possible was the open-source nature of the project together with an enthusiastic, supportive community. Being able to reuse the work of others and lean into their expertise allows rapid prototyping and reduces effort.
We see the following clear advantages in an SCT tool and workflow:
- A simpler, faster and more consistent workflow
- The ability to do communication addressing according to a set of rules
- Independence from ICTs (to avoid abrupt workflow changes as software changes)
- Enabling tools which visualize communication between IEDs and place them in a wider system context
- Ability to automate mappings between IEDs based on end-user requirements which reduces time to create subscriptions by 90-95%
The OpenSCD ecosystem is still maturing, and we are keen to understand and discuss what a next generation tool looks like for others.
Please join us in the discussion of next generation tool requirements on the Zulip chat platform at https://openscd.zulipchat.com
Biographies:
Daniel Mulholland has been a Protection & Automation Engineer in transmission and distribution for more than 15 years. He has recently moved into a Principal Engineer, Digital Substations role within the Protection & Automation team in Transpower. His key focus since 2022 has been leading the team developing a toolkit for creating greenfield digital substations covering all aspects, from device selection, engineering process and physical design. In previous roles he was worked in technical team management, project management and standards development.
Jarrad Raumati has a Bachelor of Engineering (Hons) in Electrical and Electronic Engineering from University of Canterbury (NZ). He has worked in both transmission substation and protection & automation. He is a Senior Associate – Protection Engineering at Beca Ltd working on projects in both New Zealand and Australia. Most recently, he has been a part of Transpower’s Digital Substation Project which is delivering a suite of template designs and processes which will allow for greenfield substations to be built using IEC 61850 station and process bus.
Jakob Vogelsang graduated from the university of Erlangen-Nuremberg (GER) with a Master of Science (Hons) in Electrical and Electronic Engineering. Since graduation he has worked as a PAC Engineer in various roles but mainly as consultant and trainer for IEC 61850 at OMICRON and business analyst for virtual substations for Alliander. Since 2018 he is working on the idea of an open source SCL editing tool. He is one of the founders of OpenSCD and was maintainer of the OpenSCD distribution until 2023. He is maintainer of the scl-lib project and develops plugins for the OpenSCD ecosystem.
