by Volker Leitloff, Rte, France, Joao Peres, Efacec, Portugal, Johann Maincent, SCLE, France, and Patrick Montaner, GE Vernova, France
The bay level IED of the first phase of the R#SPACE project include:
- Bay Control Units (BCU)
- Stand Alone Merging Units (SAMU) for interfacing with instrument transformers
- Switchgear Control Units (SCU) for interfacing of hard wired binary input and output signals from switchgear and from other substation equipment
- The corresponding IED Configuration Tools
These IED are purchased from different manufacturers, based on specifications defining the R#SPACE functional requirements and interoperability framework. This interoperability framework includes configuration, data models and cybersecurity requirements. Based on IEC 61850, it is completed by profiles and other features to achieve functional operational and non-operational interoperability.
This article outlines the specification and validation process. An experience feedback of the IED development and qualification is given:
- from the perspective of Rte which is in charge of specification of the PACS, component validation, system assembly and system level tests.
- from the perspective of the manufacturers in charge of development and qualification of the bay level and process interface IEDs, including their configuration tools.
R#SPACE System and Interoperability Framework
- The R#SPACE system consists of 3 main blocks:
- The substation level is implemented in a virtualized infrastructure hosting the substation level applications. These applications include the HMI for operating and maintaining the system, the configuration tools, the substation level automatons, the gateways and the cybersecurity functions
- The Local Area Network (LAN) with PRP redundancy and the time synchronization architecture
- The bay and process level, which consists of several types of IED (BCU, SAMU, SCU)
- The chosen architecture for R#SPACE’s LAN is shown in Figure2. It is composed of:
- 2 central switches for the general substation functions and the substation level bays (Busbar bay and General substation services bay).
- 2 switches per feeder bay which are connected to central switches in a star topology
The R#SPACE interoperability framework includes
1. Communication interoperability, covered by IEC 61850. The datasets published by a function and subscribed by other functions are defined and configured according to this standard
2. Profiles and Syntax: functions communicating which other functions need a common understanding about the meaning of the different Data Objects (DO). In some cases, the general definition offered by IEC 61850 is not sufficient and needs to be completed by profiles or data models.
Without these profiles, diverging interpretations about the meaning or use of specific Data Objects, Data Attributes or the associated quality attributes can occur, resulting in the risk of misoperations
3. Application level interoperability: finally, the functional specifications of the different elements also need to be coordinated. The associated documents can consist in functional standards or user specifications
The interoperability framework of R#SPACE defines a consistent set of interoperability requirements ranging over the three levels described in Figure 3. In addition to operational interoperability requirements, this framework also includes requirements related to configuration, setting, supervision and administration of the different components.
R#SPACE IED Specification and Validation Process
Each supplier was responsible for the compliance of his developments with the function and system requirements. Rte made the choice to perform the validation tests on the supplier’s premises, based on a test protocol defined in common agreement. In addition, critical functions, such as the distance protection, were also tested by Rte experts in Rte platforms. The stand-alone IED qualification tests aim to verify compliance with functional specifications and interoperability requirements. They also contribute to detect gaps or anomalies that cannot be identified in the case of a complete chain of IED (e.g. BCU interfaced to a SAMU and SCU).
When the individual and conformance tests were successfully passed, each component went through partial and / or system qualification tests in Rte facilities. As the test planning differs depending on the component, it is often not possible to wait for the complete system to begin system qualification testing. Partial system qualification tests were executed on an incremental way as components were delivered, until the whole R#SPACE system was available.
Previously, the stage of system qualification was performed by the suppliers of the turn-key PACS. For R#SPACE, the team dedicated to integration had to first define an overall strategy for system qualification and specify and develop specific tools for this step. The main aspects of the integration test strategy are:
- The integration test campaign is as much as possible automatically executable, to enable validation of multiple combinations of IEDs in a limited amount of time.
- The communication from IEDs that are not installed in the tested system is emulated by the test tool
- The test tool can inject in wired terminals of the system under test, corresponding to the PACS process interface, or perform IEC 61850 injections. The test cases where currents and voltages are injected into the SAMUs and logical binaries input or output are connected to the SCU correspond to a configuration which is also used for the Factory Acceptance Tests.
Experience Feedback
Rte
Rtecould use the experience feedback from the ”Postes Intelligents” demonstrator project (PAC World Magazine June 2018). This allowed the definition of the Rte data model, the definition of the requirements related to the management of input quality attributes and the definition of the PACS communication network. Most functional requirements for bay protection and automation functions of R#SPACE are similar or identical to those of the previous Rte PACS. Among other points, the following aspects were new to Rte:
- Use of IEC 61850 configuration files for the binding of input and output of functions
- Use of IEC 61850 configuration files for the configuration of physical inputs and outputs, both for SAMU and for SCU
- Interoperable IED administration and supervision management
- Interoperability requirements for IED Configuration tools, including API for administration, and configuration and parameter updates
- R#SPACE specific cyber security requirements
When the R#SPACE project was launched, it was not quite clear if all the requirements could be implemented by the IED manufacturers. For some aspects, several options were possible, but Rte needed to select one, to be used for all IED, to maintain the consistency of the system. In order to gain visibility on these points, Rte selected the “competitive dialog” tender method, allowed under European Union regulation. In this framework, workshops covering the different subjects with the different manufacturers having submitted offers in the tender phase have been organized. This resulted in adaptions and modifications in the IED specifications to best fit with the available offer.
In the development contracts, the IED Capability Description (ICD) and Substation Configuration Description (SCD) files were considered as deliverables, comparable to a product documentation, test report or specification. It became clear that this vision was not realistic, as several updates and exchanges of ICD and SCD versions are required in practice in the development phase. Also, contractual delays for providing updated documentation turned out to be not adapted to the development of SCD. Several aspects are concerned by this:
- The manufacturer needs to provide an IED Capability Description file based on the Rte data model, formalized as SCL file
- Based on the ICD, Rte creates a SCD. This SCD has to be accepted by the configuration tools of all components of R#SPACE, including the configuration tools of the IEDs
The constraints and specificities of the different components also had an impact on the development of the SCD and, again, resulted in several iterations. This was not anticipated in the project planning and took considerable time and resources, both for Rte and for the IED manufacturers. For this reason, a common SCD file could not be used for the unitary qualifications of the IEDs, as initially planned. As the capacity to import a common SCD file is instrumental for top-down engineering, improvements on this subject in the IEC 61850 standard would be welcome.
Another point related to the SCD was the clarification of the mapping between variables used in the functional specification and associated DO and DA to be published by the function, especially if the entries were of enumerated data type and not Boolean. This clarification was provided at the beginning of the development phase in updated functional specifications.
The interoperability studies from the R#SPACE PACS revealed many points which were not or not completely covered by the published IEC 61850 or product standards, in particular for SAMU and for protection functions. Rte has submitted many of those issues to the relevant IEC Technical Committees, where they are now considered for the new edition of the concerned standards. Rte is actively contributing to several IEC Technical Committees (TCs) relevant for fully digital PACS, including TC 57, in charge of IEC 61850, TC 38, in charge of standardization of instrument transformers and SAMU, and TC 95, in charge of standardization of protection functions and IEDs.
Efacec
Efacec is a manufacturer of technology, based in Portugal, with over 40 years of experience in supervision, control and automation of energy systems, providing reliable field-proven automation solutions with an extended range of products tailored to fit a wide variety of applications, from digital substation automation to power plant DCS.
The R#SPACE project provided an open and transparent relationship between Efacec and Rte, including at steering, project management and technical levels, and allowed for competent risk management and overall mitigation and anticipation of impacts. The competitive dialogue approach introduced by Rte in the early stages of the project allowed to break down the scope and limit gaps, allowing a deep understanding of Rte’s requirements and the proposed solutions.
Technical Feedback
The R#SPACE project was defined as a Fully Digital Substation environment with operational multivendor interoperability, full IEC 61850 Ed2.1 configuration with top-down engineering including data modelling and cybersecurity. Prior experience and strategic focus in digital substation solutions allowed Efacec to be very comfortable in the R#SPACE project. Efacec’s technical expertise and the digital substation product portfolio maturity allowed to deliver elegant solutions pushing the technical capabilities of the devices and comply to this vision. Examples include:
- Engineering with IEC 61850 model and configuration definition – Top-down engineering using a REST API for common interface and mediator concept to deal with specificities in the model and seamless engineering dealing with different ICT
- Standardization of operational settings with transformation file concept – manage the necessary conversion for specific operational settings in multi-vendor environment
- Cybersecurity solution by design– Authorization with RBAC, Secure communication with ICT, Hardening solutions (with ports, services and communication management and filtering), Authenticity and integrity validation of product firmware, Advanced supervision with Syslog aligned with IEC 62351-14
- Redundancy in the process level equipment – Dynamic automatic selection of main or backup SV or DO
- Active online reconfiguration of the internal and external subscription of DO – adding flexibility maintenance and enhanced testability with multiple dynamic selection of DO
- SAMU advanced performance according to IED 61869-13 – regarding accuracy requirements, dynamic ranges and Electromagnetic compatibility (EMC)
- Synchronism check validation in a PACS environment – Deployment of Synchronized Phasors over GOOSE with dynamic reconfiguration and later binding for voltage source subscription
Development Phase
The project scope matured along the implementation phase. One clear project challenge was to manage the modifications of specifications during the project execution. Several strategies were deployed successfully in this effort:
- Technical team proximity between utility and manufacturer to manage, align and clarify scope with constant interactions. The technical interactions always allowed to reach a common understanding of the requirements. This process was seamlessly managed in an R&D agile process as used by Efacec
- Open technical discussions regarding the best holistic added value solution to the application. This transparency was key to understand both the utility required functionality on one hand and best technological feasible approach on the other
- Scope breakdown with continuous delivery in intermediate versions. This strategy allowed to provide added value earlier, enabling the utility to validate the compliance with the requirements, reduced technical risk and enhanced feedback to align final solution
Although all these strategies considerably reduced the impact of the scope change, the added configuration exchanges lead to a longer period of stabilization of the configuration scope. Frequent unplanned SCL exchanges between technical teams during the parallel development phase were unavoidable. Furthermore, the disruptive nature of R#SPACE, the configuration versatility and dynamism with frequent SCL exchanges with the utility led to unplanned challenges in the quality assurance process. Some impact particularly in the development phase but also in the qualification phase were unavoidable.
Qualification Phase
The aforementioned scope evolution during the implementation phase had a direct impact in the qualification phase. The strategy adopted to manage the impact was a natural corollary to the continuous delivery process used in the development phase – to break the qualification in packages of closed application scope qualified sequentially. Overall strategy was successful in completing the qualification milestones, despite extending the qualification phase in time and effort compared to the original plan.
This strategy came with additional risk to the integration phase. This risk ended up manifesting in a higher-than-expected number of technical issues prior to successfully completing the integration phases of the first substation deployment.
SCLE
When we started the R#SPACE project, SCLE, based in France, had already been a regular partner of Rte for the supply of complete PACS for nearly 15 years. The architecture proposed by Rte within the framework of R#SPACE was a real challenge for us, forcing us to significantly rethink how we worked with them.
The first difficulty was clearly defining the interfaces and the associated functionalities. While the IEC 61850 standard clearly specifies the interfaces related to modelling, it leaves a wide interpretation to the IED manufacturer regarding the functionalities associated with this modelling. This was not compatible with Rte’s project, which, beyond simple modelling, also specified many elements related to functionality.
This involved, among other things, adding specific tags in the SCD files, sometimes planned by the standard, and sometimes not planned and therefore declared as “Private.” Indeed, the IEC 61850 standard did, at that time, not cover certain needs, such as the behavior of functions in case of degraded interfaces or the values to be considered for unbound interfaces.
As a result, we had to integrate into the ICT an automatic consideration of these tags, whereas these elements were previously hard-coded during the function design phase, thereby increasing the configurability of our products. On the integrator side, an essential element was the implementation of an Application Programming Interface (API), defined by Rte, that allowed the use of ICTs from different manufacturers in a transparent manner and thus facilitating multi-vendor integration.
Taking Rte’s needs into account has led to a high degree of product configurability. Indeed, each input and output of each Logical Device, whether external (GOOSE messaging or physical inputs/outputs) or internal (functional links between LDs), could be configured. This high configurability results in a very significant combinatorial complexity in the IED’s functionalities. We were therefore faced with the problem of validating these multiple functionalities. To do this, it was essential for us to implement an automated testing system that could account for all possible configurations and replay all tests with each evolution of the IED in just a few hours. We were then able to provide Rte with the entire test plan and, in consultation with them, determine a sampling of these tests for formal validation of the operation.
Finally, the last major constraint we had to consider was related to cybersecurity issues. Although this topic is increasingly being addressed by prescribers, implementing it in a multi-manufacturer solution that aims to be automated and integrated requires a cross-reflection between the prescriber and the integrator to arrive at a process that is both complete and sufficiently simple for operation.
The final feedback from this project is the importance of close collaboration between the manufacturer on one side and the prescriber and integrator, which was Rte, on the other. Indeed, no matter how good the preliminary reflection work is, it is inevitable that interpretation gaps may arise when implementing the specifications. Regular technical clarifications to avoid various deviations seem essential to limit the impact of these gaps during system testing.
GE Vernova
GE Vernova has more than 20 years of expertise and deep knowledge in digital substations, IEC 61850 and power system automation. We implement an agile development methodology, allowing us to efficiently absorb changes and adapt throughout the project lifecycle. Developing an IEC 61850-compliant Intelligent Electronic Device (IED) based on a customer’s digital substation specification presents a unique opportunity to push the boundaries of innovation while addressing the complexities of standardization and market adaptability. R#SPACE project fits into GE Vernova’s product strategy.
This project was key to collect lessons learned and voice of customers about IEC 61850 modelization and top-down engineering.
Our experience collaborating with Rte demonstrated both the strategic advantages of working closely with an experienced end user and the challenges of balancing tailored requirements with global market needs.
Leveraging End-User Expertise for Innovation: The specification for Rte’s R#SPACE project went beyond conventional requirements, encompassing all aspects of IED design:
- Hardware and Environmental Factors – Stringent performance criteria, including electromagnetic compatibility (EMC), wiring interfaces, acquisition accuracy, and boot times
- Communication Capabilities – High scalability in network interfaces, support for multiple Sampled Values (SV) streams, GOOSE messages, low-latency communication, and precise synchronization
- Application and Logical Modelling – Advanced Logical Node (LN) modelling for hardware abstraction, dynamic interface referencing (InRef) via MMS, later binding for intra-IED data linking, and operational modes dependent on the IED’s position within the substation
- Information Management and Cybersecurity – Comprehensive data handling policies, role-based security models, password management, and secured communications
- Configuration and Integration – API-based interaction with ICT systems, streamlined management of SCD, ICD, CID, and IID files, and enhanced automation of engineering processes.
By integrating these advanced concepts, the specification pushed the boundaries of IEC 61850 implementation, enhancing system flexibility, reducing configuration cycles, and paving the way for future virtualization of substation automation.
Challenges: While partnering with an experienced utility such as Rte provided clear advantages in terms of innovation and real-world applicability, it also introduced significant challenges, particularly in ensuring that the resulting IED remained viable beyond this specific customer. Rte’s detailed specification spanned hundreds of pages, demanding substantial development efforts across multiple domains.
As widely recognized in software and systems engineering, achieving a fully complete and accurate specification from the outset is nearly impossible. Despite the Rte’s extensive expertise and thorough documentation, multiple review cycles were required before reaching an acceptable level of detail to begin development. Our experience played a crucial role in closing the gaps and refining the specification details
Validation and Verification: During development, multiple levels of validation and verification were necessary before reaching the final qualification stage. This included:
- Unit Testing covering individual components and software modules
- Isolated Functional Testing, validating specific features and functionalities in controlled conditions.
Close collaboration with Rte throughout the development process was essential to keep the project aligned with expectations. Rte reviewed and approved our proposed test plan and procedures, which were later used as the basis for the final qualification and acceptance of the delivered project. This iterative approach ensured that all requirements were met while maintaining flexibility for adjustments as needed.
Evolution of Standards: One of the advantages of working with Rte was their commitment to adopting the latest IEC 61850 advancements. However, this also introduced significant challenges. Many of these recent standards—such as IEC 61850 Edition 2.1 and IEC 61869-9/-13—were still evolving, leading to inconsistencies and, in some cases, contradictions.
For instance, IEC 61869-13, which defines requirements for SAMU, significantly raises the bar on accuracy and performance criteria. While this represents a technical leap, it also led to a debate within the manufacturer about the practical necessity of some of these requirements from a power system analysis perspective.
Experience feedback: The collaboration with Rte on the R#SPACE project enabled us to implement cutting-edge features that improve flexibility, efficiency, and interoperability. The experience also encompassed the importance of balancing customization with scalability, serving a broader energy market.
This project reinforced the idea that partnerships with end users drive innovation, and success depends on a product strategy that maintains adaptability, ensuring long-term viability across different geographies and regulatory landscapes.
Conclusion
After a preparation phase, the external and internal developments of the R#SPACE components have been launched in 2020. Pre-integration and FAT have been performed stepwise starting form end of 2022, leading to the commissioning of the first substation in December 2023. The number of commissioned substations per year will be progressively increased for an industrial rollout. At the same time, Rte has launched and finalized the tender for the phase 2 of R#SPACE, comprising multi-voltage level substations.
- The experience feedback from the first phase highlights the following points:
- R#SPACE being a disruptive project compared to the previously deployed PACS, the tender form chosen by Rte for the bay level IEDs, the competitive dialogue, proved beneficial for all parties. It allowed Rte to adjust specifications and IED manufacturers to anticipate and understand the aims and requirements
- Close and frequent exchanges in the development phase were essential. This has led to identify needs for clarification and adjustment for some requirements
- Special attention has to be given to the generation of SCD files for development and testing. It has turned out that frequent exchanges are required to obtain an IEC 61850 compliant file which can be imported to all ICT. This should be correctly anticipated in follow-up projects
- Some of the features required for the R#SPACE project were under development in IEC 61850. All parties have strived to implement solutions in line with the orientations discussed in TC 57 WG 10 and have also submitted use cases and standardization requests to WG 10
The overall approach was validated by the commissioning of the first substation in 2023 (Figure 4), followed by others in 2024 and 2025.
Biographies:
Volker Leitloff studied Electrical Engineering at the university of Stuttgart (Germany) and received the Dr. INPG degree from the Institut National Polytechnique de Grenoble (INPG, France). At the R&D Division of Electricite de France, he worked successively on network protection and on transformers and network technology. Since 2003, he worked at Rte on protection of transmission networks and substation control. He is chair of CIGRE Study Committee B5 and of IEC Technical Committee 38 (Instrument Transformers), convenor of IEC TC95 WG2 Digital I/O of protection IED, and actual or past member of several IEC and CIGRE working groups.
Joao Peres is currently Head of R&D for the Automation Business Unit at Efacec, overseeing the PAC and Grid Management departments. He has over 15 years of experience in Power System Protection, Automation and Control, having led and contributed to numerous R&D projects focused on product innovation and solution deployment. He has also authored and contributed to several technical papers and publications related to these domains. Joao holds an MSc in Electrotechnical and Computer Engineering, specializing in Power Systems, from the Instituto Superior Técnico in Lisbon.
Johann Maincent is project manager for protection, automation and control system developments at SCLE SFE, a French manufacturer based in Toulouse. He holds a master’s degree in electrical engineering. For 15 years, he and his team have been contributing to the evolution of the systems developed by his company, as well as to the integration of the IEC 61850 standard into these systems, which are widely used by French TSOs and DSOs.
Patrick Montaner is system application architect at GE Vernova with IEC61850 expertise and driver for innovation. He has 26+ years of experience in PACS for TSO and DSO through different roles and 20 years’ experience in IEC 61850.