Paper - PAC World Conference 2024

Empowering IEC 61850 Engineering with LF Energy CoMPAS and OpenSCD: A Paradigm Shift Towards Flexibility and Collaboration

Davood Sooran¹*, Tamás Russ², Sander Jansen¹

¹*davood.sooran@alliander.com

¹Alliander N.V. (Netherlands), ²SprintEins GmbH (Germany)

The engineering landscape for IEC 61850 faces challenges stemming from a lack of standardization and vendor lock-in, limiting adaptability and efficiency. This paper introduces LF Energy CoMPAS and OpenSCD as a transformative solution, providing a vendor-agnostic, open-source ecosystem for System Configuration Language (SCL) editing. OpenSCD, with its web front-end, open-source codebase, plug-in architecture and user-friendly interface, serves as a pivotal tool in overcoming the limitations of traditional native desktop app oriented engineering processes. Notably, the LF Energy CoMPAS project collaborates actively with OpenSCD, leveraging its web front-end as part of the CoMPAS solution.

The current state of 61850 engineering tools reveals a disparity in approaches, resulting in non-standardized processes. CoMPAS/OpenSCD addresses this by offering an extensible and customizable platform that promotes flexibility and control, preventing vendor lock-in. The paper emphasizes the importance of moving away from manual XML editing, proposing a collaborative approach to system configuration and specification. For a clearer understanding of CoMPAS, refer to the image below illustrating the CoMPAS architecture overview.

Figure 1 : CoMPAS Architecture Overview

Efficiency gains and adaptability are at the core of the LF Energy CoMPAS and OpenSCD solution. CoMPAS/OpenSCD introduces a Central SCL data management system with a Plug-in architecture, enabling users and vendors to extend the ecosystem to suit their specific needs. This collaborative approach fosters a community-driven development model, accelerating the energy transition by streamlining the 61850 engineering process.

Crucially, this collaborative endeavor involves strategic partnerships with industry leaders such as SprintEins and Omicron. By working together in an open-source manner, the project taps into a diverse pool of expertise, enriching the tool's capabilities and ensuring a comprehensive and inclusive solution for the energy sector.

Alliander's utilization of CoMPAS/OpenSCD in ongoing projects reflects the immediate benefits and efficiency gains achieved through this collaborative effort. The successful implementation within Alliander serves as a tangible endorsement of the integration's ability to meet the diverse needs of practical engineering scenarios. The paper emphasizes the ongoing efforts to develop a Plug-in architecture that empowers users to create private extensions for 61850 configurations, ensuring a future-proof and adaptable solution.

In summary, this paper not only details the advancements achieved in the past year through the LF Energy CoMPAS and OpenSCD integration but also highlights the real-world impact within Alliander. The active involvement of external companies in creating plug-ins showcases the project's expanding influence and its potential to become a cornerstone in the evolution of IEC 61850 SCL configuration practices.

Introduction:

OpenSCD serves as a tool collaboratively developed and utilized by a diverse spectrum of professionals, including software architects, utility operators, equipment manufacturers, and dedicated enthusiasts on a global scale. Its primary objective is to facilitate accessibility to Substation Configuration Language (SCL), even for individuals lacking expertise in the domain. This objective is realized through the provision of a complimentary and user-friendly platform offering the most prevalent SCL functionalities.

Figure 2 :  An Overview of the Substation Plugin in CoMPAS/OpenSCD

An intriguing facet of OpenSCD is its adaptability, allowing users to extend its capabilities through the integration of personalized plug-ins. This feature empowers users to tailor the tool to align precisely with their distinct requirements, enhancing its utility significantly.

Moreover, ongoing efforts are directed towards the development of a comprehensive library housing essential SCL functions. This resource will serve as a repository for software developers, enabling them to construct bespoke tools, thereby simplifying SCL-related endeavors. For instance, the "unsubscribe" functionality streamlines connection management, adapting dynamically to the nuances of different SCL editions.

The OpenSCD Project

From the perspective of a project, OpenSCD is a free and open-source software (FOSS). Open source refers to software whose source code is freely available for anyone to inspect, modify, and enhance. It is developed collaboratively, with developers from around the world contributing to the project's development.

It is important to address some common misunderstandings about open-source software and the development process. Most open-source projects, including OpenSCD, are open for inspection and use. While anyone can review and copy the code, modification privileges are not universally granted. There are specific roles and strict rules in place to ensure the security and integrity of the final product.

Two key roles are particularly important in the software development context. Firstly, contributors are defined as individuals who contribute value to the project, whether through coding, documentation, or other forms of support. Secondly, maintainers are responsible for overseeing the project's direction, reviewing, and merging contributions, and ensuring the software remains in good health. It is important to note that maintainers are also contributors.

Contributors, as members of LF Energy, must accept and sign the Developer Certificate of Origin with each change they propose. This document serves to confirm that the contributor is permitted to contribute the change and that the project is authorised to distribute it. Another signature we require is the commit signature. This is necessary to verify the author of the code. We enforce these requirements with automated processes by disallowing new alterations without the signatures. The two signatures serve to verify the identity of the contributor and to grant us permission to utilise their contribution. This increases traceability in the project and makes it more difficult for malicious alterations to be created.

Each contribution undergoes a review process involving multiple parallel components. As previously stated, maintainers assess the proposed changes before accepting them, ensuring that they benefit the project. In this phase, they propose modifications and provide guidance to contributors on how to adjust their contributions.

Concurrently with the review, a continuous integration pipeline automatically assesses the quality and correctness of the code. We ensure the program functions as intended by running a comprehensive test suite for each contribution. Furthermore, static code analysis tools are utilized to ensure uniform code style and identify potential errors within the codebase.

These audits are now standard practice in all projects, but they are particularly important in open-source ones. By improving quality and security, we can enhance the trustworthiness of our software.

Another common criticism of open-source is the lack of support. In our case, this is addressed through two channels. The first and least onerous solution is the community support. Should a problem arise, or a query be raised regarding OpenSCD, the community can be reached via Slack (https://lfenergy.slack.com) or by creating an issue on GitHub at the OpenSCD organisation (https://github.com/openscd). Typically, Slack is more suitable for providing clarifications, while GitHub is more appropriate for submitting concrete suggestions and addressing problems. This enables the community to monitor usage and identify the specific requirements of the broader community.

A second potential avenue for obtaining commercial support is through the services of providers such as SprintEins (https://sprinteins.com) or Omicron (https://www.omicronenergy.com). The principal advantages of service providers that are directly involved in the project are their familiarity with the code base, their engagement with the community and their contribution to the community.

OpenSCD’s Architecture

Operationally, OpenSCD is accessible as a web-based application through the following link: https://openscd.github.io/. It is also classified as a progressive web app (PWA), which means it offers offline capabilities. This feature is particularly advantageous for engineers who may find themselves without internet access but still need to browse or edit their SCL files, such as when working on-site at a substation or while traveling. Additionally, all previously installed plug-ins remain available when using the offline app. While the update process is seamless, it's important to note that an internet connection is required for updates.

Web browsers are highly effective tools for handling XML, making them an ideal foundation for an SCL editing program. They offer a wide range of built-in APIs for interacting with XML files and provide a secure sandbox environment. Leveraging the processing capabilities of modern browsers allows files to stay safely on the user's computer, ensuring compliance with strict data privacy protocols and maintaining confidentiality and integrity of user data.

In terms of architectural principles, OpenSCD employs web standards in order to guarantee the longevity that the energy sector demands of its tools. Furthermore, OpenSCD will not only be usable in the future, but it will also be maintainable. A significant aspect of these web standards is the incorporation of web components or custom elements. These elements permit developers to create reusable and shareable components, thereby reinforcing the strength of the community. Moreover, by relying solely on these components, teams can develop their own plugins, utilising not only currently popular technologies but also future ones.

Currently, everybody can create their own distribution of OpenSCD, meaning everybody can have their own copy deployed in any infrastructure. This is already a good option for enterprises and utilities that require more protection and want to have a say over when their version will be updated. However, we would like to go further and offer a streamlined process for further customization so we introduce different building blocks that can be used in different manners. This architecture design (See Figure 3) facilitates the completion of common customisations with greater ease, while still allowing for more extensive adjustments to the software.

Figure 3: The different building blocks of OpenSCD

A distribution can be created from an app variant by configuring which plugins should be installed by default and/or making adjustments to the theme. This is the most straightforward method for establishing one's own instance of OpenSCD, and we provide a limited number of customisations. A distribution is the app with which the users directly interact through their browsers.

The function of an app variant is to provide a platform for plugins and to allow configurations such as theming. They may utilise the provided functionality, such as the "Editing" feature, or alternatively, they may implement their own version of this functionality, provided that it adheres to the interface standards, to keep compatibility. This ensures that plugins remain compatible with any app variant. At this level, developers can replace parts of OpenSCD in order to adhere to their specific requirements. One illustrative example is the implementation of an authentication or authorization feature.

An addon extends OpenSCD as a platform and provides technical capabilities that the plugins can use. One such an example is the logging addon, whose responsibility is to log any activity in the app to the browser’s console. One could decide to replace it with an alternative implementation that sends every activity to a server for better traceability.

Plug-ins provide SCL-related business features (see Figure 4). The majority of the requirements can be addressed through the use and development of a plug-in, which represents the most effective solution. They can be installed per user or globally for a distribution. They can be made available for everybody or behind secure infrastructure or only locally on one’s computer. This modularity  offers several benefits. First, it enhances user acceptance because users can tailor the program to meet their specific needs. Second, it provides flexibility, allowing users to mix and match plug-ins to create a setup that works best for them. Moreover, the availability of new plug-ins means that users can continuously expand and improve the functionality of OpenSCD. Once a new plug-in is added, users can immediately start using it, without any delay. This seamless integration of new features ensures that users can stay productive and make the most out of the software. Currently, there is a distinction between official plug-ins developed by the core project team and community plug-ins by developers from the wider community. This distinction is intended to ensure the safety of users.

The Core package primarily serves to define the specifications that ensure compatibility between the building blocks and between different implementations and provides basic functionalities for developers. It enables the community to customize OpenSCD to their specific requirements.

Figure 4 : Plugins Menu of the CoMPAS/OpenSCD

Important functions of OpenSCD:

CoMPAS/OpenSCD tool has seen the development of numerous functions and plugins aimed at simplifying and enhancing SCL configuration. These plugins are instrumental in streamlining the process for users, making it both easier and more efficient. Within the CoMPAS/OpenSCD tool, two main types of plugins have been created: Editor plugins and Menu plugins. In Table 1 below, you'll find a comprehensive list of the key implemented plugins, each contributing to the tool's functionality and usability.

Table 1 : CoMPAS/OpenSCD Functions and Plugins

An essential plug-in that aids users in grasping the intricacies of the IEC 61850 data-model is the IED plugin. This plugin empowers users to filter and focus on a specific IED. With the IED plugin, users gain the capability to explore the IEC 61850 structure of a selected IED. It provides insights into various components such as the Access Point (AP), Server, Logical Device, and Logical Node, allowing users to navigate down to the ENUM level for comprehensive understanding. Figure 5 displays the user interface for the IED plugin.

It's worth noting that for editing and checking AP configurations, users can utilize the Communication plugin. This additional plugin grants users access to all Access Points defined within the SCL file, providing comprehensive control and management over communication configurations within the system.

Figure 5 : IED Plugin of the CoMPAS/OpenSCD

The substation section comprises two main types of elements: process-type elements, also known as process structure, and function-type elements, or functional structure. The process structure is responsible for creating the visible physical layout within the substation and includes components like the Substation itself, Voltage Level, Bay, and Conducting Equipment. On the other hand, the functional structure consists of elements such as Function, Subfunction, EqFunction, and EqSubFunction.

To manage and visualize information related to the substation and its associated functions and equipment, the Substation editor is utilized. This editor facilitates the establishment of links between IEDs, functions, and conducting equipment, enabling the viewing and adjustment of reports, GOOSE, and Sampled Measured Values (SMV) communication. Figure 6 showcases the user interface of the Substation editor, with unlinked IEDs displayed at the top, followed by the substation and its voltage level, along with bays, a linked IED, functions, and conducting equipment.

Figure 6 : SCL file opened in OpenSCD

Another remarkable feature of CoMPAS and OpenSCD is the IEC 104 plugin, depicted in Figure 7, which has been meticulously crafted in alignment with the IEC 61850-80-1 standard document. This plugin serves a critical role by facilitating the translation of device-oriented data models outlined in IEC 61850 onto the predefined ASDUs and services of IEC 60870-5-104 or IEC 60870-5-101 standards.

This translation process allows users to seamlessly map attributes of CDCs onto the defined ASDUs of IEC 60870-5-104. By leveraging this plugin, users can effectively bridge the gap between different communication protocols, ensuring interoperability and compatibility between systems.

Once the necessary 104 points are incorporated using this plugin, users can utilize the Pro-mode feature to gain real-time visibility into the integration process. This means that as points are added, users can monitor their inclusion into the SCL file, as illustrated in Figure 8. This level of transparency empowers users to closely track the integration progress and ensure that the desired functionality is accurately represented in the final configuration.

Figure 7 : Show the 104 values in the SCL file

Figure 8 : Show the SCL content of added IEC 104 points

The Template editor in OpenSCD, as illustrated in Figure 9, provides users with a platform to define their data model from scratch, known as a greenfield approach. For many users, this involves transitioning an existing signal list to align with the structure of the IEC 61850 data model.

The key distinction between a traditional signal list and the IEC 61850 data model lies in its hierarchical structure, which consists of Logical Nodes, Data Objects, Data Attributes, and Enumerations. This hierarchical arrangement is established within the DataTypeTemplates section of an SCL file, where four essential elements are defined and referenced: LNodeType, DOType, DAType, and EnumType. Each element builds upon the other, creating a nested structure of data definitions.

The complexity of understanding and navigating this hierarchical structure can be challenging, especially for beginners. To assist users, particularly those unfamiliar with the nuances of the standard (such as 7-4, 7-3, 8-1), OpenSCD offers templates. These templates serve as predefined data models, encompassing a variety of logical node classes with predefined references to DOType, DAType, and EnumType. By leveraging these templates, users can streamline the process of defining their data models and ensure adherence to the IEC 61850 standard without grappling with the intricacies of manual configuration.

Figure 9 : Show the SCL template section

Furthermore, alongside the engineering of the data model and the substation section, the communication between IEDs can be parameterized. This includes support for common telegram types such as GOOSE, Sampled Values (SV), and Reports. Figure 10 showcases the GOOSE communication editor, providing a visual representation of the user interface for configuring GOOSE communication within CoMPAS and OpenSCD.

Figure 10 : GOOSE Communication Plugin

One of the notable recent additions to the platform is the network explorer (See Figure 11). This feature serves as a valuable tool for users to delve into the intricacies of the physical network represented within the SCD file. Through the plugin's interface, users can visualize IEDs that are connected with clear and unambiguous links, with the option to group them into bays if they are part of a larger unit.

The interactive nature of the diagram enhances user experience, allowing them to select individual or multiple IEDs for detailed inspection of their network information. Furthermore, users can explore connected IEDs directly from the diagram, facilitating a comprehensive understanding of the network topology.

It's important to note that while the current layout of the diagram is automatically generated, users have the flexibility to adjust the positioning of elements as needed. However, these adjustments are temporary and are not saved in the SCD file at present.

Additionally, the network explorer offers users the capability to remove elements from the diagram. However, the functionality to add new elements is not yet supported in the current version of the plugin.

Figure 11: Network Explorer, Device Inspection plugin

In addition to examining IEDs, it's crucial to inspect the cables that connect them (See Figure 12). This gives insight into which IEDs they're linked to and which specific ports they're connected with.

If there are available ports on the IEDs, you can establish connections by simply dragging one of the black dots to another. The system intelligently selects the first available port for the connection, but users retain the flexibility to change this selection as needed. This interactive feature streamlines the process of configuring connections between devices, enhancing user control and efficiency within the system.

Figure 12: Network Explorer, Cable Inspection Plugin

OpenSCD vs CoMPAS:

Not every function is suitable for in-browser development, especially those requiring interaction or integration with other applications via API calls. For example, integration with a SCADA system or importing and reporting on substation functions using CIM may not be feasible directly in the browser. To address this need, LF Energy's CoMPAS extends OpenSCD with backend services. This expansion makes it suitable for enterprise-level requirements such as single sign-on, role-based access, and audit trails, while still facilitating interaction and integration with external systems.

Database back-end:

One important function recently added is a database backend for storing and loading SCL files (See Figure 13). As SCL files are becoming more vital for utilities, being used in various applications and containing critical settings, it's crucial to have a robust method for managing them. This includes proper storage, maintaining an audit trail, implementing role-based access, enabling single sign-on, and managing versioning. The backend services in CoMPAS offer a solution for loading and storing SCL files, ensuring efficient management and utilization of this important data.

Figure 13 : File types currently supported by CoMPAS

The database backend incorporates a default method for versioning SCL files, with the decision made to adopt semantic versioning (major/minor/patch) (See Figure 14). When a file undergoes an update, the user is prompted to specify the desired revision of the SCL file. This approach ensures that versioning is enforced to the end-user, providing clarity and control over the evolution of the files.

Figure 14 : Store a File in CoMPAS database

In the background, the system keeps track of the user who is logged in and records them in the change log. This helps trace back changes to specific users if necessary. The Version tab displays all the existing versions stored in the database, allowing for easy comparison between different versions. (See Figure 15)

Figure 15 : The versions editor in CoMPAS

CIM Import:

To speed up substation development, CoMPAS makes it easy to use a grid-planning CIM-based substation as a starting point for engineering work. With CoMPAS, you can convert a CGMES-EQ based substation to SCL using backend services. This conversion sets up bays, equipment, and other parts so they're ready to connect to IEDs and LNs, making the whole process quicker and smoother. (See Figure 16)

Figure 16 : A converted CIM-based substation to SCL

Concluding Remarks on CoMPAS and OpenSCD

The CoMPAS and OpenSCD projects have been a success so far, and there's still a lot of room for growth. We want to invite everyone to join in, whether you're a user, tester, developer, or vendor. You can get involved by reaching out to the community, like through our GitHub and Slack channel.

We're especially excited to have vendors on board to create export plug-ins or validators. This helps make things easier for everyone involved by cutting down on manual work. So, if you're a vendor, this is your chance to make a real difference and improve the project for everyone.