CIM/CGMES Interoperability Test Report 2023

CIM/CGMES IOP Report IOP Report 2 EXECUTIVE SUMMARY This report provides a comprehensive overview of the results and key findings of the Interoperability test (IOP) on Common Grid Models Exchange Standard (CGMES) version 3.0 organised by the Interoperability Network for the Energy Transition (int:net project) and hosted by ENTSO-E in Brussels. The objective of this test was to foster the harmonisation and interoperability of energy services throughout Europe by focusing on the adoption and implementation of CGMES v3.0, an IEC standard (IEC 61970-600-1&2:2021). The report will be used by the project to further discuss interoperability aspects. It can also be used by organisations implementing CIM, such as ENTSO-E, in addition to Transmission System Operators (TSOs), Distribution System Operators (DSOs) or any project or organisation in general that would like to improve on interoperability. The test brought together approximately 50 participants representing 35 companies from 20 countries, both physically and remotely, to discuss and analyse important topics related to interoperability. The participants included vendors, TSOs, DSOs and other stakeholders. The discussions and collaborations during the test resulted in significant insights and conclusions regarding CGMES v3.0 and its implementation. The test served its purpose by providing a forum for knowledge sharing around CGMES v3.0 and other ongoing standardisation areas. CGMES v3.0, which has been a standard since June 2021, has a wide scope and provides necessary clarifications, forming a stable baseline for future versions. However, it was evident from the test that many vendors, TSOs and DSOs are not fully aware of the benefits offered by this version. Consequently, one of the main conclusions of the test was the need for proactive discussions and knowledge sharing among stakeholders to facilitate a smooth transition to the latest versions of the standards. The development of an interoperability framework and the scheduling of periodic IOPs are crucial components for ensuring successful interoperability in the CIM-based data exchanges. IOP Report 3 This IOP confirmed that to achieve interoperability, the necessary resources, guidance and assistance to ensure the successful execution of IOPs should be planned. By defining clear organisational roles and responsibilities, establishing workflows and processes, and fostering effective communication, the framework enhances the efficiency and effectiveness of the implementation efforts. Periodic interoperability tests play a vital role in evaluating the compatibility and effectiveness of the adopted standards and tools. By scheduling regular tests, stakeholders can assess the performance of their systems, identify any gaps or issues, and work towards resolving them prior to the formal conformity process. These tests also provide an opportunity for knowledge sharing, discussing best practices and vetting draft international standards. By organising periodic tests, the interoperability community can ensure that the implemented standards and tools remain up-to-date and aligned with evolving requirements. Conformity assessment emerged as a crucial aspect in ensuring the quality of data exchange and minimising overall effort. The test highlighted the importance of TSOs and DSOs actively requesting that vendors apply for conformity assessment. It should be considered that conformity and interoperability testing have different stages and different purposes when conducted in the development process of standards and during the implementation of projects dealing with data exchanges. Furthermore, participants emphasised the necessity of transitioning to a more automated conformity assessment process to optimise resources on both the vendor and assessment sides. Clear communication, both internally and externally, and strict planning by stakeholders implementing business processes were identified as crucial factors for success. There should be communication from standards development organisations related to the planning of the next releases of the standards. Planning coming from project implementing data exchanges is crucial to close the feedback and support the planning of the standardisation. Access to comprehensive documentation was highlighted as pivotal in facilitating seamless operations and promoting knowledge sharing. To enhance accessibility, it was recommended that a centralised repository, such as GitHub, be created for documentation pertaining to standards, amendments and bug fixes. In addition, promoting subscriptions to new standards would ensure stakeholders stay updated on the latest developments. A clear commitment by utilities to implement the standards/specifications designed to meet requirements was emphasised as a key driver for progress. Projects implementing new versions of business processes should be aware of the time required to implement a new version of a data exchange standard and the need to plan for it. Moreover, the presence of a well-designed transition process was considered important to meet business process needs and ensure continuity. The transition process should address changes in content that may impact data exchange quality, bug fixes and minor enhancements for improved efficiency and correctness, in addition to major functional upgrades to meet new business requirements. Business processes need to see the transition processes as part of the normal operation of the business as changes are happening constantly and require organisation and governance. Not having such commitment and transition processes would trigger additional alignment activities or the parallel development of specifications that endanger interoperability over time. Establishing a robust framework for aligning standardisation processes with implementation needs emerged as a critical requirement. This entails prioritising the alignment of business units and embracing innovative information technologies while upholding business continuity. Effective communication and collaboration among stakeholders were identified as pivotal in this regard. Facilitating access to validation tools and ensuring uniform usage across vendors were considered crucial aspects for business processes. Streamlined processes that provide vendors IOP Report 4 with readily accessible validation tools were recommended to enhance operational efficiency. Encouraging uniform usage of the same validation artifacts among vendors would contribute to seamless collaboration. CGMES v3.0 relies on W3C SHACL based validation which should be fully utilised. The maintenance of existing test data, the release of declassified models from TSOs and ensuring data quality were recognised as vital factors in enabling the interoperability community to conduct robust testing. Participants recommended establishing a systematic procedure to enhance test data and utilise declassified models, which would provide valuable resources for testing purposes. The availability of quality data, rather than just sample data, would enable the comprehensive testing of complex aspects of the standard and enhance the capabilities of vendor tools. However, IOP participants recognise the confidentiality aspects and recommend that elements of real data be reproduced in sample data to enable the objectives be met. This requires collaborative efforts that require organisation. In conclusion, by incorporating the recommendations discussed during the IOP, stakeholders can effectively promote interoperability, digitalisation and energy transition objectives in Europe. Clear communication, proactive planning, commitment to implementation, robust frameworks, and access to validation tools and quality data are all key elements that will contribute to the successful adoption and implementation of CGMES v3.0 and future versions of data exchange standards. Continuous collaboration and engagement among vendors, standardisation bodies, TSOs and DSOs are essential for driving progress and achieving the seamless integration of technological standards into practical operational solutions. IOP Report 5 CONTENTS Executive Summary ................................................................................................................................. 2 Contents .................................................................................................................................................. 5 1 Introduction ................................................................................................................................. 6 2 Use Cases and Topics ................................................................................................................ 9 3 Summary of Topics Discussions and Tests.............................................................................. 15 4 Conclusions and Recommendations ........................................................................................ 45 5 Annex A: Information on Applications/Tools used in the IOP (alphabetical order)................... 47 6 Annex B: Summary of Issues ................................................................................................... 65 7 Annex C: Test Procedures........................................................................................................ 68 Bibliography ........................................................................................................................................... 71 IOP Report 6 1 Introduction The int:net project aims to foster the harmonisation of interoperability activities on energy services throughout Europe by forming an interdisciplinary network of stakeholders who will engage in a constant exchange on the topic during the project period and beyond. Specifically, int:net will impact the interoperability landscape for energy services by pursuing specific objectives during the project. This IOP workshop explores the application of CGMES 3.0 by engaging TSOs, DSOs, research institutions, conformity labs, standardisation bodies and vendors. From an int:net project perspective, CGMES 3.0 is just one of the important standards that demonstrate the necessary efforts regarding the interoperability landscape. CGMES is a standard for the exchange of data (not for hardware or security or regulatory interoperability). It is an enterprise standard (not a field protocol) regarding a very specific type of data (grid model data) used by a specific part of the electric utility industry (transmission). CGMES is widely used, and it is IEC international standard. The standard is essential to the industry's ability to meet its climate change responsibilities and implement Network Codes in Europe. The fact that CGMES v3.0 was released in June 2021 and the transition from previous versions will require organisation makes it an interesting case study. The int:net project organised a series of weekly meetings to explore use cases and test respective solutions. The goals of the workshop series are as follows: • Vetting of data exchange specifications; • Demonstrating TSO–DSO data exchange based on existing standards; • Discussing the testing of interoperability on all levels; and • Preparing for cross-sectoral interoperability. A final two-day event on 16–17 May 2023 concluded the series with an IOP event in Brussels at ENTSOE premises. The IOP was organised in two parts: the preparation phase, where IOP participants discussed different topics relevant for the IOP, and the physical meeting held in May 2023 in Brussels. Topics discussed during the IOP included: • TSO–DSO exchange of the power system model, including diagrams and geographical location; • Different variants of boundary set exchange, extensive usage of reference data; • Power system project exchange; • Possibilities for exchange using JSON-LD instead of CIM XML; • Test procedures and test configurations; • CGMES v3 implementation and current IOP, and setup of future IOPs; • Managing the transition, setup of a data exchange process which relies on multi version data exchange specifications; • Conformity – how to improve the Factory Acceptance Test (FAT) and define a workable Site Acceptance Test (SAT). Barriers for utilities, vendors, etc. The IOP is considered a significant milestone in the effort to re-launch these activities, marking it the first of its kind since 2016. Throughout the int:net IOP weekly calls, a diverse and collaborative community comprising vendors, research institutions, DSOs and TSOs collaborated to delve deeper IOP Report 7 into discussions on various use cases. This report serves as a comprehensive summary of those discussions. Chapter 2 provides an introduction to the use cases and topics that were explored. Chapter 3 presents a summary of the discussions held and outlines the tests conducted during the IOP. It provides valuable insights into the progress made and highlights any notable findings or outcomes. Chapter 4 encompasses the general conclusions drawn from the IOP, in addition to the recommendations made by the participants. To enhance the report's comprehensiveness, three annexes have been included. Annex A showcases the applications utilised in both the preparation and execution of the IOP, offering a comprehensive overview of the tools involved. Annex B provides a summary of the issues that arose throughout the process, serving as a reference for future releases and improvements to the CGMES. Finally, Annex C details the test procedures employed during the IOP, ensuring transparency and facilitating replication in future IOPs. Overall, this report not only sheds light on the IOP itself but also emphasises the collective efforts made by the community in fostering interoperability. It serves as a valuable resource for stakeholders in the field, providing a comprehensive understanding of the discussions, tests, conclusions and recommendations generated from this groundbreaking event. 1.1 Acknowledgments The int:net project would like to thank the many people who worked hard to make the IOP a success. Not all contributors can be named here. However, int:net would like to give special recognition to the following utilities and vendors: • Bajame Allmeta and Eduardo Relaño Algaba (ENTSO-E) for the IOP organisation; • Chavdar Ivanov (ENTSO-E, gridDigIt) for directing the IOP, for the preparation of the IOP report, and developing some of the test data. • Eric Lambert (EDF R&D, representing TDX-ASSIST, OMEGA-X and BRIDGE Standards User Group as part of BRIDGE Data Management Working Group) for the preparation of the DSO test model demonstrating CGMES v3 support by EDF tools (Riseclipse, DisNetSimpl); • Pat Brown (Cimpledata) for contributions to the IOP report; • Gordon Jahn (Open Grid Systems) for demonstrating CGMES v3 support by Cimphony; • Sindre Hunn (Siemens) for demonstrating CGMES v3 support by PSS®ODMS; • Frano Tomašević & Alen Muller (Adnet) for demonstrating CGMES v3 support by NetVision EMS; • Attila Barta and Zoltan Solga (IPS Intelligent Process Solutions GmbH) for demonstrating CGMES v3 support by IPS-NMM; • Enric Micolau (Neplan) for demonstrating CGMES v3 support by Neplan; • Lino Prka and Harish Krishnappa (DNV) for validating the data with CIMbion; • Tobias Berger and Amalishiya Robert (Associmates GmbH) for validating the data with ValiMate; and • Viktor Rimarev (AST) for demonstrating CGMES v3 support by MUSTANG. IOP Report 8 1.2 Test Participants The following companies, organisations and research institutions participated in the test: IOP Report 9 2 Use Cases and Topics 2.1 TSO–DSO Exchanges The TSO–DSO exchange plays a crucial role in various use cases, some of which can be addressed using existing exchange mechanisms, whereas others require further discussion, requirement gathering and development. To initiate a discussion on the requirements and potential gaps in a broad sense, the following questions and topics have been outlined: • Modelling of Renewables: o What is the minimum requirement for modelling renewables to serve the purposes of the TSO? • Modelling of Equivalents, including network: o How should the modelling of equivalents, including the network, be approached? • Boundary Exchange: o What are the considerations and requirements for exchanging data at the boundary between TSO and DSO areas? • Area Modelling: o How should the areas be modelled, and what factors require consideration? • Scope of the Grid: o To what extent should the grid information be shared? o Where and what specific data should be included? o What should the frequency and periodicity of data exchange be? • DSO Representation for the TSO (and vice versa): o What are the expectations regarding the representation of DSOs for the TSO and vice versa? o If a detailed model is used, how should network losses be considered by the receiving end when aggregated? o If aggregation is employed, how should network losses be accounted for by the sending end? For example, should there be sensitivity towards the point of coupling? • Data Exchange: o Should data be shared per time stamp or in the form of time series? o What file format would ensure ease of use for individual analysis, while also facilitating time-based analysis with fewer files? o What should be the expected frequency of data exchange, and what time resolution is necessary for each exchange? o Is there a requirement for data exchange from the TSO to the DSO, or is this a potential use case for the future? o If such exchange is necessary, would the same requirements apply as mentioned above? o Is there a file format that can support bi-directional data exchange? • Unbalanced Modelling: o Unbalanced modelling aims to study how to model an electric power system in a situation where the electrical magnitudes in the three phases are not symmetrical (i.e. IOP Report 16 Community about upcoming developments was emphasised. There is a lack of proactiveness in the industry, although different projects have varying requirements, hence utilities need guidance. Some TSOs focused on the operational planning processes suggest maintaining CGMES 2.4.15 for the next two years as several TSOs are still catching up with that version. However, there is a belief that planning for the transition to CGMES v3.0 should not be discouraged. At the same time, questions have been raised about the future beyond 2025, which leads to a need for early planning. TSOs suggest comparing the quality between CGMES v2.4.15 and v3.0. However, the importance of having tools to facilitate this comparison was emphasised, which would require vendors to support the new standards. It is also important to realise that such a comparison needs to be done on the exact same content of the model. There are a considerable number of issues faced by the Community as new business processes require the exchange of data that was never exchanged in this form outside the utilities. Therefore, that part of the data needs to undergo the same quality scrutiny that the data related to the backbone of the grid naturally experienced for decades. The question of how to speed up this process is a business challenge which requires considerable resources, tooling and an organisation structure facilitating the creation of a single source of truth related to data in the utilities. Vendors should be providing tools to compare data, and vendors should be aware of the new standards so that they also recommend new versions of standards to TSOs. Understanding TSOs and DSOs needs is also an important task as these are well beyond the use case needed for a particular business process. Conducting a survey to assess whether those needs are being met is considered appropriate. Some vendors reported that customers have already heavily invested CGMES v2.4.15 and see no reason to switch unless clear advantages in modelling are demonstrated in CGMES v3.0. They mention the challenges in converting to the previous version and suggest that use cases demonstrating the benefits of the new standard could be useful. They also highlight the need for use case-driven implementation and caution against rushing forward without considering associated risks. The need for business drive and internal organisational efforts to convince stakeholders has been emphasised. The advantages of CGMES v3.0 become apparent only during implementation. It is suggested that interoperability issues could be identified through interoperability tests, and it was advocated that a roadmap to anticipate challenges and benefits is essential. Vendors also indicated the challenges of selling CGMES v3.0 to management and highlight the dependencies on earlier versions and additional documents such as ENTSO-E QoCDC rules that they are currently focused on addressing. The importance of collaboration between vendors and users in digitalisation efforts, where users are guided by use cases and vendors gain investment protection through assured product demand. There are benefits of testing in the effort to promote and increase the level of understanding and adoption by both vendors and utilities. Experts who are familiar with the annex of the CGMES v3.0 standard believe it is well-written and clearly outlines the changes. In addition, there are also now automatic ways to highlight the changes between versions. In general, the purpose of the standard is to establish a semantic set of rules that everyone can understand. The Community sees big progress in the effort to prepare a CGM. Back in 2008, it took two years to do this, but nowadays it takes a few hours, including an effort to improve the data. It is important to highlight the significant advantage of faster integration. We need to acknowledge that during IOP Report 17 the development of CGMES v2.4.15 in the period 2010–2014, there was very limited information on the use cases and required data to be exchanged for the purpose of implementation of the Network Codes as they were either drafts or unknown. The Community is really lacking in strict version control and a transitioning process. Many failures in the overall process are assigned to the wrong item, being either a CGM creation or CGMES as a standard or its validation. This is a natural consequence of not being well informed on the detail, which appears to be a critical item for improvement. IOP participants emphasise the importance of the Community understanding the significance of testing and conforming to new versions instead of remaining stuck with outdated ones. In addition, following the widely used CIM standard is insufficient and users need better tools for quick bug fixes and test. Therefore, this puts higher requirements on the tooling. The need to explain what changes are applied in a machine-readable version in addition to the clarification on what use cases are defined by different authorities can be implemented through identifying which standards are important to know and which standards need to be changed accordingly. Views were expressed that implementations based on the standards and the development of the standard should go hand in hand. There is a belief that currently, there is a significant gap between the two. It is strongly recommended that vendors should encourage their customers to adopt the new standard instead of adding additional features to old versions, e.g. CGMES v2.4.15. Another aspect that requires consideration is that in the case of processes related to operational planning, the criticality of errors is higher as they can lead to widespread blackouts, tarnishing the industry's reputation. This should be one of the key elements when preparing the transition plans and should not stop the changes but ensure the quality. In summary, the following points should be considered: • Projects that are responsible for implementing business requirements need to drive the transition between versions. They need to do this in a very transparent manner towards the whole Community, including vendors and standardisation bodies. • Different projects have different needs and will have different implementation schedules. It is necessary to keep limited numbers for versions used in production environments. • A semantic understanding of versioning and machine-readable representation on what is changed between versions is necessary. • The Community needs to be mobilised and have channels to receive direct feedback on issues. These issues need to be solved in the next version of standards and implemented as soon as possible to achieve the business objectives. • Modelling practices will need to be aligned. A use-case approach on standard development is necessary to support the process of development of test data and also highlight the reasons for transitioning to the next version. 3.2 Outcome of the 2022 TYNDP IOP The Ten-Year Network Development Plan (TYNDP) project conducted an IOP in November 2022. Some vendors were present to discuss issues, but they did not have access to the data. The IOP’s objective IOP Report 18 was to identify issues and suggest resolutions to be applied for the TYNDP project and next standards as well as to gather feedback on CGMES v3.0 implementation. The points discussed in the November 2022 IOP revolve around the high level of criticality, convergence issues with a specific tool in the IOP, the focus on threats to TYNDP development, the desire for vendors to conform to CGMES 3.0, and the need to identify and resolve issues in the CGMES v2.4 to prevent their recurrence in CGMES 3.x. The TYNDP models are not flawless but have been tested with the merged model of continental Europe, allowing simulations to be run. Vendors are interested in understanding model changes between versions, particularly in classes, injections and generating units. Use cases for HVDCs have been created, with a request for an exchangeable HVDC model that accurately represents flow. While the data provided in the 2022 TYNDP IOP are largely the same as the current IOP, some modifications were made to reactive power based on synchronous machine output and the equivalent representation of certain network parts due to confidentiality restrictions. Topology and substations are generally unchanged. The round table organised on this topic involved experts that were part of the IOP in November 2022. This round table was the first major interaction-follow up of the results and aimed to clarify the current status of the issues, answering the problems that were detected. The summary below follows the open points on CGMES v3.0 addressed by the November 2022 IOP. There are some items that are organisational or ENTSO-E specific, and these will be managed within ENTSO-E. The following summarises the discussion on the topics and needs addressed by the TYNDP IOP: • Vendors not understanding the DNV validation tool for the conformity process o In the frame of the announcing conformity process, DNV presented the process that was agreed with ENTSO-E. During this IOP, information was provided on the tooling and the process. Int:Net IOP also organised training, which is available on YouTube 1 and covers this topic. More focused communication will need to be implemented with the support of the TYNDP project. DNV reported that one vendor applied for conformity and there are discussions with a few other vendors. • Vendors concerned about the conformity fees o The conformity process is an important process which saves resources, but also requires some resources from vendors and customers. As the Assessment Body (the conformity lab) is not funded by other sources, fees need to be introduced to cover the development of tooling, its maintenance and the assessment of conformity, which currently is not fully automated. Earlier conformity assessments done in 2014–2016 did not have conformity fees only because all costs that occurred for the Assessment Body were covered by ENTSO-E, and these costs are comparable with the current fees asked by the Assessment Body. There is a topic to be further discussed on possibilities to lower costs and/or access to funding. • Lack of support from TSOs (their clients) 1 (387) ENTSO-E CGMES 3.0 Training - YouTube IOP Report 19 o Discussions in the IOP covered this topic on CGMES v3.0 implementation as well as the need to have a more structure process to ensure transition between versions. • Test cases are not frozen and that causes uncertainty over what to test o This seems to be due to miscommunication. The Conformity Assessment Scheme (CAS v3.0) was announced last year and is published on the ENTSO-E web site. There have been no changes since that time and all test cases and test configurations are stable. • There is no full conversion from CGMES 2.4.15 to CGMES 3.0 o This is a topic to be further discussed as part of the efforts to ensure transition. Vendors reported that users do not really request support tooling that would enable them to convert from CGMES v2.4.15 to CGMES v3.0. The question is whether a common tool is necessary or if this can be done by the different tools used in the model exchange. • There is no SharePoint folder for CGMES 3.0 documentation o All necessary information is in the ENTSO-E web site 2 and IEC web store 3 as the CGMES v3.0 is IEC standard and the main documentation can only be provided by IEC. Otherwise, it could be seen as a copyright breach. o ENTSO-E would like to initiate a process to request free access to the relevant IEC standards for ENTSO-E members with a web-based interface (instead of pdfs). This addresses TSOs’ access but not necessarily vendors’ access. The recommendation for vendors is to follow the same strategy in terms of membership and go for web-based interface. • Multiple changes in the profile without final documentation & lack of maturity of CGMES 3.0 o There appears to be some miscommunication here. The CGMES v3.0 has been a standard since June 2021 and there are no changes after this date. It needs to be clarified what level of maturity is requested. CGMES v3.0 is a service pack of CGMES v2.4.15, which means fixes issues and minor updates are applied. New major functionalities will need to be requested and developed in the standard. It is important that projects implementing data exchange standards provide structured feedback on any needs and also commit to implementing the updated standard once the functionality is standardised. The communication between standardisation streams and implementation streams should be bidirectional. o Some vendors fear there will be an upcoming upgrade to CGMES 3.0, and this is causing hesitation in pursuing the upgrade. The CGMES Roadmap outlines the planned development of CGMES, with new versions typically released every two years to accommodate the standardisation process. These new versions aim to address issues found in the previous version and incorporate user feedback. It is important for development efforts to strike a balance to ensure a smooth transition. In addition, there 2 CGMES Library: Common Grid Model Exchange Standard (CGMES) Library (entsoe.eu) and Conformity site: CIM Conformity and Interoperability (entsoe.eu) 3 IEC 61970-600-1:2021: IEC 61970-600-1:2021 | IEC Webstore, IEC 61970-600-2:2021: IEC 61970600-2:2021 | IEC Webstore IOP Report 20 will be a minor version to fix issues found in the implementation as part of the normal maintenance of any standard. As a recommendation, all vendors should establish a development program that aligns with this release cycle. • How to implement the boundary on the EQ profile o Most of the topic was covered in the training and is explained in the standard. In brief, it is important to understand that in CGMES v3.0, the boundary EQ profile was deprecated only because it was aligned with the EQ profile. This makes the boundary EQ profile useless. This does not mean that there is no exchange of boundary equipment instance data. On the contrary, the boundary EQ instance data is still exchanged in the same manner as in CGMES v2.4, but this instance data can conform to the main EQ profile as well as to the deprecated boundary EQ profile. In the next versions of CGMES, the boundary EQ profile will be removed, but this will not change the fact that the boundary EQ instance data is still exchanged. • Topological nodes not being an input in the models but result of the topological processing o This is one of the main improvements in CGMES v3.0 to enable an exchange of hybrid models (combination of node breaker and bus branch modelling styles). This does not mean that an application that cannot support topology processing will not be able to use Topology profile. The key point is that the connectivity in the models is available in the equipment profile for all modelling styles which makes the modelling more universal. • Removing TP on the input can cause issues on tools that do not support the node-breaker modelling o The support or not for node breaker modelling style has nothing to do with the Topology profile being an output and not an input. There are several important points to clarify: ▪ The change, topology being an output of a topology processing, does not require that models that are exchanged have node breaker modelling style. The topology profile instance file can be an output of a model that is pure bus branch modelling style. ▪ A node breaker model is not necessarily a model that contains all breakers and disconnectors present in the grid that is modelled. There could be different modelling details depending on the need of the studies where the model will be used. ▪ The requirements in CGMES v3.0 is that all tools understand ConnectivityNode and build the model connectivity using ConnectivityNode objects and not TopologicalNode objects. In a very simplified approach, a model will have the same ConnectivityNode objects as TopologicalNode objects. • The voltage level being defined from connectivity nodes without the topological nodes means it is not possible to know which busbar sections are associated with connectivity nodes or switches o There are a few issues here that need clarification. Take the usage of the BusbarSection object to express that a ConnectivityNode is a busbar section; this is the usage of the object, but as this is left for the vendors and users to define which node is a busbar section, not all applications are doing this consistently. It is also very difficult IOP Report 21 to validate this as the validation needs to know the original intention of whether a node is supposed to be a busbar section. In the next version of CGMES, this will be clarified. o The containment of ConnectivityNode objects in CGMES v2.4 created conflicts as there are situations in which this cannot be set. This is why, in CGMES v3.0, the containment on ConnectivityNode objects is not defined in a strict manner. In addition, the ConnectivityNode does not have an association with BaseVoltage in the way that TopologicalNode has. Some applications may have issues in cases where ConnectivityNode is not contained in a VoltageLevel that has an association with a BaseVoltage. In these cases, the application should be able to derive a base voltage for the node. More guidance on this can be provided in the next version of the standard. • The CIMdesk 2.8.2 converter does not render usable models, just a class re-assignment with multiple errors that make the AC load flow solution impossible o This is an implementation issue that will be followed in ENTSO-E to assess it. It was not part of the IOP discussions. • The following needs are identified: o CGMES 3.0 IOP between tools ▪ The int:net IOP is one of the efforts that answers this need. More testing can be setup in the frame of implementation projects. o To use the planning models converted from CGMES 2.4.15 to 3.0 and use them as a test ▪ This is welcome. The only problem is that the confidentiality should be clarified. For the int:net, the TYNDP model that is provided under NDA was converted, but more work is needed to improve the dataset and compare it with the original data. o To have a dedicated ENTSO-E SharePoint for vendors to exchange and contribute ▪ This is something ENTSO-E can organise as part of the effort to increase collaboration. o To make EA data publicly available ▪ The EnterpriseArchitect project file is already available on the ENTSO-E web site 4 . o Clarification on the boundary connections ▪ After CGMES v3.0 was published, some issues were found in the modelling of the boundary point in a substation. This led to a discussion which resulted in the creation of an ENTSO-E document on boundary and reference data. This document was approved on 10 May 2023 and will be part of the next version of CGMES. The IOP discussions clarified questions raised by vendors. o Clarification on topological nodes ▪ This was provided in the training and in the int:net IOP. The TopologyNode objects for boundary nodes are exchanges in the model of the sending party 4 https://www.entsoe.eu/Documents/CIM_documents/Grid_Model_CIM/CIM100_CGMES31v01_50120v02_NC22v95_MM10v01.zip IOP Report 22 as there is no topology instance file for the boundary set. When the different models are merged there is a common topology instance file which contains the TopologyNode objects of the merged model. This is also explained in CGMES v3.0. o Can/should ‘Class bay’ be used to tackle the topic of removing the TP? ▪ This relates to the issue of the usage of BusbarSection, which was clarified. o Clarification on the use of connectivity nodes instead of topological nodes ▪ This was also clarified in the IOP. There are sufficient explanations in the CGMES v3.0. More training efforts can be organised and knowledge sharing improved. o More IOPs in 2023 ▪ This IOP was part of the effort. More can be organised by the implementation projects. This will need to be planned. o Clearer maintenance of the boundary ▪ The maintenance of the boundary is an effort of TSOs and ENTSO-E. The defined process needs to be followed to ensure the required quality. o Clearer access to CGMES 3.0 information in the CIM WG website (within ENTSO-E website) ▪ ENTSO-E is working on an improved version of the website. o To have an official converter to CGMES 3.0 (they proposed to use the software tools from vendors) ▪ Multiple options are available here. It will be good to have flexibility so that implementation projects are able to select the best option. o A converter would allow planning models that have been verified for quality and AC load flow solution to be easily retested in CGMES 3.0 ▪ This will only be possible in a transition period if the content of the model is the same. Some things might not be comparable as if the sending party sends a more detailed model to meet the business need, the comparison effort might not be relevant or at least will need to be analysed in detail. ▪ In the CGMES roadmap, it will be stated that a machine-readable description of the transition from the current version to the next and from the next to the current (upgrade and downgrade) will be provided. o The test cases need to be final and the standard version for CGMES 3.0 mature ▪ This was clarified. The standard has been final since June 2021. The conformity scheme was published in 2022. There will be improvements and issues resolutions. The intent is to maintain artefacts in GitHub which will allow open access to the material and easy handling of the issues. o ENTSO-E WG DM (Data modelling) III to contact CIM WG to organise ENTSO-E IOPs 2023 for all vendors and CGMES standardisation participants ▪ This is an ENTSO-E item which will be handled internally. It was not part of the IOP discussions. o ENTSO-E WG DM III to deliver the vendors comments and proposals to CIM WG IOP Report 23 ▪ This is an ENTSO-E item which will be handled internally. It was not part of the IOP discussions. o Improve coordination between ENTSO-E and vendors and set up regular exchanges where the vendor can participate ▪ This is understood and there should be some more efforts to increase collaboration, but there will be a need for support from all implementation projects regarding both financial and human resources. o ENTSO-E WG DM III to propose the procedure to validate models converted from CGMES 2.4.15 to CGMES 3.0 ▪ This is an ENTSO-E item which will be handled internally. It was not part of the IOP discussions. o The test models should include some of the planning models based on the ENTSO-E dataset ▪ There is no problem including planning models in the conformity scheme as long as confidentiality questions are clarified and the quality of the models is improved. This will not replace the need to have smaller models to facilitate the debug efforts. There should be activities established to work on these tasks. 3.3 Boundary and Reference Data Exchange The discussion on the boundary and reference data exchange primarily revolved around the specifications published by ENTSO-E. Throughout the conversation, it became evident that the IOP participants not only comprehended but also supported the new approach proposed by ENTSO-E, which aimed to maximise the utilisation of W3C vocabularies whenever possible. Through this acknowledgement, the IOP participants highlighted their willingness to adapt and embrace this new specification. However, it was acknowledged that thorough testing would be required to validate the implementation of these modifications. Vendors conducted initial tests, and the results indicated that some of the proposed modifications could be readily supported ‘out of the box’. Nevertheless, the compatibility of these modifications would be contingent upon the specific platforms utilised by the vendors. Despite this, it was generally anticipated that the overall impact of these modifications would be minimal. Moving forward, the modifications defined within the ENTSO-E specification will need to undergo a formal presentation to the IEC and subsequently be published as part of the standard. This crucial step ensures that the advancements and improvements discussed during the boundary and reference data exchange discussions are integrated into the broader industry framework, providing a comprehensive and standardised approach to data exchange within the energy sector. In conclusion, the next steps in this topic are to organise more testing, update the CAS and proceed with the integration of the proposed specification into IEC standards. IOP Report 24 3.4 Power System Project Exchange In May 2023, ENTSO-E approved the Power System Project specification. During the discussions on the technical details of the specification, several key points were raised that shed light on the future direction of power system project modelling. One crucial aspect was the adoption of JSON-LD as a counterpart for CIMXML. JSON-LD, if implemented, would allow power system projects to be modelled directly in JSON-LD format, serving as the primary serialisation. This shift to JSON-LD was deemed more advantageous due to its potential benefits. It could streamline the modelling process and facilitate seamless integration with existing systems and technologies. Another important concern addressed during the discussions pertained to dependencies on other projects. It was acknowledged that dependencies on separate systems or data could pose challenges. To tackle this issue, two potential approaches were proposed. The first approach suggested that each project should explicitly list all its dependencies, ensuring transparency and clarity. Alternatively, a separate register could be established to store and manage dependencies on individual projects. With the approval of the Power System Project specification and the constructive discussions regarding its technical details, the next step in the process involves the development of test data and the organisation of testing. This phase is crucial to ensure that the specification is implemented accurately and effectively. By conducting thorough testing, any potential issues or shortcomings can be identified and addressed promptly, thereby enhancing the overall reliability and functionality of the power system projects. In conclusion, test data will need to be prepared, testing organised and in parallel the specification will need to be presented to IEC for standardisation with the proposal that JSON-LD should be used as a primary serialisation. 3.5 Document Header and Manifest The recently approved specification by ENTSO-E introduces modification to the document header used in the CIMXML instance data. It also defined the rules for packaging files that are sent for specific exchange in a cimx 5 file, which is a zipped package. This approach follows the OpenXML technique but does not apply the same structure as OpenXML. There was discussion on whether OpenXML can be used directly as this would allow the utilisation of open libraries. IOP participants acknowledged that one of the main difficulties lies in incorporating JSON-LD within the framework, along with the need for various serialisations. Consequently, the advantages offered by using OpenXML in this context become minimal. The specification recognises the need for flexibility in serialisation formats to cater to various use cases and system requirements. It was pointed out that the header and manifest specifications will evolve in the direction of full integration with DCAT 3 concepts. It is also expected the md:FullModel will be deprecated. This step was not taken just to ensure the transition period. In the IOP and other technical discussions, it was highlighted that: 5 Proposal for file extension of cim instance data files that are archived. IOP Report 25 • dcterms:publisher can be used instead of dcterms:creator; • dcterms:references can be used instead of prov:wasInfluencedBy which can still be relevant for when topology and state variables instance data are referred as part of provenance; • dcat:version should use the semantic versioning, e.g. 1.0.0. – last item is changed when the change does not affect the result by using it, e.g. change of a description. Minor is updated when items does not prevent the given result, e.g. some extra information has been added. Major is when the result might not be compliant, e.g. items have been removed. This is only relevant when dcterms:replaces is used; and • There is a proposal to directly use dcat:Dataset instead of md:FullModel, but the transition period will need to be planned. IOP participants discussed the following issues in the GitHub that relate to the manifest and cimx way of packaging: • Manifest Specification · Issue #283 · digin-energi/Grunnprofil (github.com) • Manifest payload naming standard · Issue #39 · Haigutus/Energy-Reference-Data (github.com) • Manifest instance file specification · Issue #40 · Haigutus/Energy-Reference-Data (github.com) • Contain and compress dataset using cimx · Issue #280 · digin-energi/Grunnprofil (github.com) In summary, it is expected that there will be a change request and further alignment with IEC standards. The conformity for new profiles that are developed will need to also test the header and manifest as well. The transition of CGMES standards should also be planned. 3.6 JSON-LD Serialisation One of the objectives of the IOP is to discuss different aspects regarding the potential of JSON-LD, which helps to address certain limitations of CIMXML. The topic on the introduction and transition to a new serialisation format was also discussed. The introduction and transition to a new serialisation format require careful consideration and planning. This involves contemplating various aspects, including the compatibility with existing systems, data migration strategies, adoption challenges, and the overall impact on interoperability. The IOP serves as a platform for open dialogue, allowing experts to share insights, experiences and best practices regarding the process of introducing and transitioning to a new serialisation format effectively. As the topic is significant, follow-up discussions in future IOPs are also necessary. JSON-LD has gained significant attention as a promising solution for representing structured data in a more flexible and interoperable manner. Therefore, some of the IOP participants recommended planning the transition and some of the new exchanges for an exchange using JSON-LD serialisation. There is a standardisation challenge that needs to be addressed. CGMES v3.0 and other standards refer to the IEC 61970-552 serialisation method. To utilise JSON-LD and transition data exchange, it is necessary to develop a standard that describes how this serialisation is applied to CIM-based exchanges. IOP Report 32 • Concerning funding for implementation, it is generally preferable (even required) for the project itself to bear the financial responsibility. By sourcing funding from the project, it ensures that the resources allocated for the implementation align with the project's objectives and priorities. • To conduct effective testing, it is important to clearly define the scope of what is being tested. This involves distinguishing between standards and tools. Standards refer to the established guidelines and criteria that define the expected performance and IOP requirements. Tools, however, are the specific software or technological solutions used to implement those standards. Testing the implementation (in the scope of IOP testing or conformity testing for a particular business process) primarily focuses on evaluating the performance and effectiveness of the tools in achieving the desired outcomes for the business processes. • The terms specified in the Key Organisational Requirements, Roles and Responsibilities (KORRR) relating to Data Exchange in accordance with Article 40(6) 8 need to be considered when defining the scope of the IOP and the potential funding from projects, the European Union (EU) or other sources. Securing funding will provide the necessary financial backing to ensure the successful execution of the IOP framework. • Lastly, it is crucial to ensure that the entire implementation process is organised and wellstructured at an organisational level. This involves establishing clear roles and responsibilities, defining workflows and processes, fostering effective communication, and ensuring coordination among the various stakeholders involved. An organised approach enhances the efficiency and effectiveness of the implementation efforts, increasing the likelihood of achieving the desired outcomes. 3.7.3 Conformity Assessment The discussion on conformity assessment covered different aspects on overall organisation and technical details. The sessions in the IOP also covered information on how the EC DIGIT (European Commission's Directorate-General for Informatics) supports IOP efforts. Regarding the organisation, in the past, ENTSO-E funded the conformity assessment, making it less expensive for vendors. However, with the transition to CGMES 3.0, an external party, DNV, was appointed to perform the conformity tasks related to the Assessment Body. The assessment body had to introduce fees as this is the only source of finding the effort. It is important to note that any other organisation with the correct certification could also fulfil this role. There have been discussions within ENTSO-E about obtaining full accreditation to issue certification, but this is not currently in place. Conducting the conformity assessment requires resources from all parties involved, including the Assessment Body, Opinion Body and Vendors. The challenge is to maintain the process as a continuous effort. Funding sources could come from users through direct funding, maintenance contracts or other funding options. It can be seen as an investment rather than a free service. 8 Commission Regulation (EU) 2017/1485 of 2 August 2017 establishing a Guideline on Electricity Transmission System Operation. IOP Report 33 Most vendors are aware of how to apply for conformity either through their contact with the DNV team or by extracting information from the ENTSO-E website. These vendors have provided feedback on improving readability, which will be considered during the ongoing website refurbishing process. The IOP participants discussed how users can be incentivised or how to require vendors to register and achieve conformity. Some utility representatives suggested that there is a clear business case related to system development that requires addressing. While the construction of TYNDP models involves various constraints, the real-time or near-real-time operational aspect is not one of them. Therefore, efforts to address all business processes should be organised and implementing projects need to understand the importance of the conformity and follow the processes strictly. In the meantime, vendors are encouraged to consider addressing TYNDP modelling needs as part of developing their CGMES 3.0 solutions. This would increase the maturity of their tools, justify the investment and prepare them for the eventual implementation of CGMES 3.0 on the operational side when that decision is made. The differences between the FAT and SAT types of conformity in the ENTSO-E Conformity Assessment Scheme were also discussed, and the IOP gives a clear indication of the need to separate. One question is how to organise SAT conformity testing and this is where further discussions will be needed. The SAT is linked with the implementation of a specific business process, and it is expected that projects implementing business processes will actively participate in the discussion of organising the SAT conformity assessment. It is important to perform these tests in an efficient manner but simultaneously ensure impartiality and ensure the third-party assessment process is done properly. ENTSO-E here is just one example where there are multiple business cases, some of which are governed by ENTSO-E, some not, and there is dependency between business processes. There are multiple organisations involved. It is believed that the need for conformity assessments to certify compliance to a business process is not a unique requirement for Europe and will require further discussion. The following figure illustrates the main elements of that need to be considered in respect to IOP tests and conformity. The figure does not go into detail on how the certification is done in the business process. Standards Proposed Data Exchange standard IOP Test Plan/ Procedure Interoperability Test (run by ITCA) Test Report Issues ITCA Interoperability Testing and Certification Authority (ITCA) Conformity/ Certification Test (run by Assessment Body, i.e., Test Lab) Vendor Product Vendor Product Vendor Product Vendor Product Vendor Product A Final Data Exchange standard Conformity Test use cases (Test Plan/ Procedure) Test Data Test Data Certificate of Conformity for Vendor Product A Assessment Body (Test Lab) certifies e.g. currently DNV for CGMES Implementation Implementation Implementation Implementation –process to prepare for Conformity (so called Conformity Assessment SAT) Implementation Project Testing Vendor Product C Implementation Project Test Plan/ Procedure Project Data Vendor Product B Vendor Product A Project Participant Project Participant Project Participant Implementation Design Project Owner Implementation Project Requirements/ Use Cases Interoperability Test Project Issues Standards Issues Project Data Exchange Design e.g. TYNDP: ENTSO-E LTDS: Ofgem Nodal Market: ERCOT CGM: CGM business process Industry Requirements/ Use Cases Standards Design Standards Development Organization IOP Report 34 The IOP participants had the opportunity to discuss with a representative from EC DIGIT, who provided an overview of the work in the field of data validation and conformance testing. The following figures illustrate the main functionalities. The EU DIGIT has developed a validation platform aimed at enabling reporting, monitoring and traceability. The platform allows individuals representing organisations to connect and participate in research projects. Transparency is achieved through a Docker solution that allows the installation of all IOP Report 35 components. The platform includes a conformance test bed with various capabilities. It can validate different data formats such as RDFXML, protocols such as HTTP, and processes involving token generation and digests. Custom capabilities can be added on the fly, and APIs are available to add new features to the test bed. Test cases, defined as XML files, specify the actors, actions and messages to be exchanged during testing. Examples of projects supported by the test bed include EINVOICING 9 and EDELIVERY 10 . The Java-based API can be enhanced; future improvements and scalability options are being considered including containerisation with tools such as Kubernetes. The platform has over 2 million hits and supports approximately 30 projects, with a few thousand users, and it is highly customisable. The installation processes for the platform are fully documented, ensuring easy setup and deployment. A demonstration of the platform was performed to showcase its features. Users can register their communities and set up tokens provided by the administrator. The landing page can be customised with project information and documentation. Running tests leads to graphical representations of the process steps, accompanied by reports containing metadata for each step. The conformance status history and additional test information can be reviewed. Funding for the platform is fully provided by the EC, with eligibility checks for professional use. Specification granting and certification are handled by community administrators. The platform is involved in the development of common data spaces, particularly regarding data consumption processes in Flanders. Technical discussions on conformity highlighted the following points: • Version of the SHACL shapes should be followed: In technical discussions regarding conformity, it is important to adhere to the specified version of shapes or standards. This means that when developing or implementing a system or software, it should comply with the defined version of shapes or formats. Following the correct version ensures compatibility and consistency across different systems and avoids any potential issues that may arise from using outdated or incompatible versions. • Backwards compatibility: Backwards compatibility refers to the ability of a system or software to function properly and accept data or inputs from older versions or formats. In the context of conformity, it means that any changes or updates made to the shapes or standards should not break compatibility with existing systems or data. It is important to consider the impact of any modifications on backward compatibility and ensure that older versions can still be used or supported to maintain continuity and interoperability. • Usage of open Application Programming Interface (API) for automated conformity checking: Using an open API can be a recommended approach for automating the process of checking conformity. An API allows different software systems to communicate and exchange data in a standardised manner. By utilising an open API, developers can integrate automated conformity 9 European eInvoicing standard. Validation of invoiving scenarios submitted manually or via eDelivery. 10 eDelivery AS4profile for secure and reliable message exchanges. Published list of conformant solutions. IOP Report 36 checks into their software, enabling efficient and consistent validation against the specified shapes or standards. EC DIGIT also employs this approach for conformity checking. • Redesigning the CAS for automation: To facilitate automated conformity checking, the CAS needs to be redesigned. This means making changes to the scheme's architecture, workflows and processes to enable automated validation of conformity. The redesign should ensure that the CAS can seamlessly integrate with automated tools and processes, allowing for efficient and reliable conformity assessments without the need for manual intervention. ENTSO-E as the owner of the CAS should work on this, but other projects such as int:net or activities related to the setting up of ITCA should collaborate in finding the right solution. • Validating the validator with different implementations: Validating the validator involves verifying the accuracy and reliability of the tool or software used for conformity checking. To ensure confidence in the validator's performance, it is preferable to have multiple implementations or alternative tools that can be used for comparison. By comparing results obtained from different validators, potential errors or discrepancies can be identified, and the overall reliability of the conformity checking process can be improved. • Creating test cases with fewer steps and increased automation: To enhance automation and efficiency, it is advisable to create test cases that require fewer manual steps. This means designing tests in a manner that minimises human intervention and relies more on automated processes and tools. By reducing the manual effort involved in executing test cases, the conformity checking process can be streamlined and accelerated. However, achieving this level of automation may require developing or implementing additional automated tools or scripts to support the testing process effectively. In summary, the IOP participants highlighted that: • Conformity assessment should be developed towards certification. The goal is to bring it to a level where it can meet the required certification criteria. • Automation of conformity assessment processes holds substantial potential in expediting operations and streamlining workflows. Embracing automation within the conformity assessment processes is advised to reduce manual efforts, increase efficiency and minimise errors. Deploying advanced technologies, such as artificial intelligence and machine learning, can significantly enhance the validation procedures. The objective here is to enhance the process of conformity testing by incorporating more automation in a stepwise approach. • TSOs should require CGMES v3.0 conformity in tenders. Currently, vendors report that they see more requests on CGMES v2.4.15 conformity. The IOP report outlines a number of reasons why this effect is observed, e.g. lack of communication, clear understanding by business units on the importance of changes aiming at satisfying business requirements, etc. • The platform from the EC has promising features. However, it is evident that to effectively utilise this platform, some organisation is necessary. An assessment body needs to be appointed and some fees still need to be applied to support the development of the conformity assessment and the assessment itself. This indicates that financial resources are required to facilitate the implementation and operation of the assessment procedures and to ensure the sustainability of the conformity assessment activities. ENTSO-E, EU DSO and int:net should further examine the potential utilisation of the platform. IOP Report 37 3.8 Data Exchange Standards’ Implementation. Transition Between Versions. The industry is currently facing challenges in effectively applying new data exchange standards to meet the operational needs and regulatory requirements. The discussion aims to supply a comprehensive overview of the key issues identified and propose recommendations for improvement. It is expected that recommendations will be considered in different organisations and groups. A level of divergence between standardisation and implementation is observed. Despite early standardisation to meet important requirements, the implementation of standards is not following a stable path. This underscores the critical importance of fostering closer coordination between standardisation efforts and operational counterparts. To successfully adhere to existing and forthcoming regulations, such as the EU Network Codes, it is paramount to achieve alignment between operational planning processes and exploit the potential of new information technologies, without compromising the operational stability of the power system or the effectiveness of the business processes. IOP participants discussed the transition between versions of standards and business requirements. The different viewpoints are summarised as follows: • In general, it is emphasised that best practices in software development do not address all the issues faced by the industry, particularly due to the presence of equipment over 100 years old. To address this, it is suggested to use more machine-readable tools and avoid the creation of isolated islands within the industry by adopting tools used in other sectors. This cross-industry approach can bring in fresh perspectives and innovative solutions. Vendors are more confident in the quality of their tools, thanks to conformity measures. Conformity assessments and certifications provide assurance to vendors and users alike, ensuring that tools meet the required standards and specifications. The discussion confirmed the outcome of other round tables which have highlighted the necessity of conformity. • The current conformity scheme and tooling developed for testing is considered as a Minimum Viable Product (MVP) because it is focused on specific use cases where users need to verify certain aspects defined by the CAS published by ENTSO-E. This approach allows for targeted testing and validation, aligning with specific user requirements. However, further development is necessary. • An important question was raised regarding whether vendors would be willing to contribute to the development of open-source tools if something like an open-source validation tool were to exist. This question highlights the potential for collaboration and resource-sharing between vendors and the open-source community. Vendors highlighted the challenge of recruiting skilled individuals and then allocating funds to retain them. The availability of qualified personnel is essential for the successful development and maintenance of tools and systems. The option of hiring people specifically to work on updating open-source tools exists. This approach can ensure the continuous improvement and evolution of these tools, keeping them up to date with industry needs. The concern regarding a potentially monopolistic position by some vendors is acknowledged, but these vendors also express a willingness to contribute to the industry’s effort. Collaboration and cooperation between vendors, utilities and other stakeholders are crucial to foster a healthy and balanced ecosystem. IOP Report 38 • The inquiry on the relevant time period required to transition to new standards highlights the need for a realistic understanding of the timeframes involved in implementing changes effectively. Here, IOP participants see a need for clarity and commitment from utilities. Utilities play a significant role in driving the adoption and implementation of new standards. • It is a question of how to effectively communicate and express the industry's needs. This inquiry has emphasised the importance of clear and concise communication channels to ensure that stakeholders' requirements and expectations are adequately understood and addressed. Good communication regarding new standards is often lacking, and finding the relevant documents can be challenging. This highlights the need for improved communication channels and accessible resources to disseminate information effectively. On this point, ENTSO-E is working on a new version of its website which will help improve access to various documentation. It is also recommended that utilities and vendors inquire about accessing the standards through their respective countries' channels, i.e. IEC National Committees. BRIDGE Data Management working group has set-up a BRDIGE Standards User Group which can help European projects funded by the EU to better inform on standards, and which can also make available Code Components or so called Application profiles (to increase reusability), and provide feedback on standards implementation and related issues. • As part of the improving and further developing processes related to CGM to be used by operational planning processes, ENTSO-E is working on a procedure to structure the transition between different versions. In addition, some work to declassify models on the TSO side has also been initiated. This initiative aims to enable the release of previously confidential data by anonymising it, thereby unlocking its potential for wider use while ensuring privacy protection. It should also be clear that the availability of real data does not guarantee that software is functioning correctly. The importance of thorough testing is highlighted as test cases frequently fail to capture the full complexity of real-world situations. Efforts should be focused on improving test data and the community should be guided to implement standards by relying on the specifications and not only on sample data. The following sections provide some important details on the support of multiple versions, backwards compatibility and documents hierarchy which are necessary elements for the transition process. 3.8.1 Support of Multiple Versions The support of multiple versions of standards within an implementation of a business process is a necessity to maintain business continuity and simultaneously meet new requirements and transition all entities that participate in the process. It is acknowledged that processes such as operational planning and TYNDP include a large number of entities and it is very challenging to apply any change with a hard deadline. The following figure illustrates a proposal which includes the support of multiple versions. IOP participants consider it necessary to ensure support for the following types of versions: • Previous version; • Current version – which covers all from the previous version; and • Next version – which is under development and on which testing is performed. IOP Report 39 Figure 3: Transition relying on a support of multiple versions 3.8.2 Backwards Compatibility Principles The necessity to have a stable approach to backwards compatibility is evident. It provides a level of security and stability to different parties which is of the utmost importance for system operators and suppliers to plan their activities for upcoming years and for business processes to rely on stable continuity. It is necessary to define the main principles related to backwards compatibility, and a method shall be found to test backwards compatibility at both ends: specification development and the tools that implemented the specification. The following principles are proposed: • A version of a standard is considered as fully backward compatible with its predecessor if every profile and instance data exchanged with this profile is valid under both the new and the previous version and it retains its meaning under the new version. For example, an instance of equipment profile compliant with a new version of CGMES can be consumed by a tool compliant to a previous fully backwards compatible version without tool or data modifications. Naturally, new elements in the new version are ignored as they are not present in the previous version. • A version of a standard is considered as functional backwards compatible with its predecessor if the data exchanged can be transformed to fully satisfy the functional requirements for both new and previous version. For example, a change of a name of class or attribute, or deletion and substitution of elements. • A revision version of a standard shall be fully backwards compatible. • A minor version of a standard shall be functional backwards compatible. • A major version of a standard shall be in principle functional backwards compatible. However, more ‘breaking’ changes can be expected. Version X in production Version Y in production Requirement defined Issue found Implementation package updated: Version X of document A replaced by Version Y Document A is fixed. Version Y agreed Agreement on when implementation package version (with doc Version Y) will be enforced in production Version Z in production Agreement on when implementation package version (with doc Version Z) will be enforced in production … Only 2 concurred versions supported 2 concurrent versions 2 concurrent versions Fast trackFollows planning We need to agree on: -How issues/requirements are collected -Who updates relevant documents -Who approves the document(s) -Who packages –the impl package -Who agrees of the date This all assumes that we have a setup where 2 concurrent versions are supported and we have rolling process. IOP Report 40 • The Std IOP shall include test cases for testing the level of backwards compatibility. The test data and test cases shall cover all modifications done between the new version and the previous version. • The organisation responsible for the data exchange shall ensure full backwards compatibility between any local version (in case this is necessary while waiting for IEC publication) and its IEC equivalent standard\specification. • The organisation responsible for the data exchange shall ensure functional backwards compatibility between any local versions and shall strive to achieve the same level of backwards compatibility between IEC versions of the standards\specifications. The following version related definitions are proposed: • A minor version is a compatible change to a profile. The minor version must be incremented if new, backwards compatible functionality is introduced to the standard. It must be incremented if any functionality is marked as deprecated. It may be incremented if substantial new functionality or improvements are introduced to the standard by adding additional profiles and/or an extension. It may include revision level changes. The revision version shall be reset to 0 when the minor version is incremented. • The number of a major must be incremented if any backwards incompatible changes are introduced to the standard, e.g. something is deleted. It may include minor and revision level changes if the number of changes is significant. The major version will also be incremented if one or more profiles are no longer backwards compatible. Minor and revision version numbers shall be reset to 0 when the major version is incremented. • Updates as part of a minor version update should not break the interoperability for a major profile exchange. This means that a tool which supports a profile version, e.g. 2.4 (2 major version, and 4 minor version) shall be able to import a file which is generated based on profile version 2.5 where all the additional classes, attributes and associations are ignored. • The revision version shall be incremented if only backwards compatible error fixes are introduced. A fix is defined as an internal change that fixes incorrect behaviour. Updating documentation or a class, an attribute or a profile to reflect the intended behaviour are considered error fixes. • A pre-release version may be denoted by appending a hyphen and a series of dot separated identifiers immediately following the revision version. Identifiers shall comprise only ASCII alphanumeric and hyphen [0-9a-Za-z-]. Identifiers shall not be empty. Numeric identifiers shall not include leading zeroes. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Example: 2.5.0-alpha. 3.8.3 Documents Hierarchy There are different documents that either standardise the data exchange or bring additional guidance essential to a utility or a vendor to conform with a business process or a standard. • Standard o IEC documents – includes profiles and constraints that are part of the standard. IOP Report 41 o Open-source machine-readable artifacts – UML, RDFS, SHACL, etc. • Implementation guide document – makes the link between the business requirements and standard. Explains how to use the standard to manage the data exchange needed for a given business process. This guides users and does not define requirements for applications. • Business process data exchange constraints document – defines business-driven constraints and refers to a relevant set of constraints defined in the standard. • Conformity assessment scheme for FAT and SAT. 3.8.4 Recommendations in Transitions Between Versions of Data Exchange Standards In summary, there are several essential elements that shall be considered in planning the transition between versions: • Clear communication (internal and external towards vendors and standardisation bodies) and strict planning by efforts implementing business processes. Efficient access to comprehensive documentation plays a pivotal role in facilitating seamless operations and promoting knowledge sharing. Creating a centralised repository, such as GitHub, for documentation pertaining to standards, amendments and bug fixes would greatly enhance accessibility and enable vendors to access information conveniently. Moreover, promoting subscriptions to new standards would ensure that stakeholders stay updated on the latest developments. • A clear commitment for implementation by utilities. • The presence of a transition process is important. This process requires a careful design to meet business process needs, ensure business continuity and rely on fast implementation by using more machine-readable artifacts describing changes between versions. The transition process should take care of different aspects: 1) changes in content that may not require a change of the data exchange standard but can still impact the quality of the data exchange; 2) changes in data exchange due to bug fixes and minor enhancements that aim to improve efficiency and the correctness of the exchange or modelling; 3) changes necessary to integrate major functional upgrades required to meet new business requirements. • It is imperative to establish a robust framework for aligning standardisation processes with implementation needs to ensure the seamless integration of technological standards into practical operational solutions. Prioritising the alignment of business counterparts and embracing innovative information technologies, while upholding business continuity, is pivotal to ensuring compliance with current and forthcoming regulations. This requires a holistic approach that encompasses effective communication and collaboration among stakeholders. • Facilitating access to validation tools and ensuring uniform usage across vendors are crucial aspects in the pursuit of business process excellence. It is recommended to establish streamlined processes that provide vendors with readily accessible validation tools. Furthermore, encouraging the uniform usage of the same validation version among vendors will contribute to enhanced operational efficiency and seamless collaboration. • The release of declassified models from TSOs (e.g. referring to the procedure that ENTSO-E is organising) and ensuring data quality are vital factors in enabling the interoperability community to conduct robust testing. Establishing a systematic procedure to enhance test data and the eventual usage of declassified models would provide valuable resources for testing purposes. IOP Report 48 o Helps with the preparation for CIM Conformance Testing • For utilities and network operators o Validates the interoperability of new systems during SAT and business process testing 5.1.3 Contacts Harish Krishnappa, CIMbion Service Lead: Harish.Krishnap[email protected] Lino Prka, CIMbion Product Owner: L[email protected]m For more information and to start your free trial, visit the link: https://store.veracity.com/cimbion 5.2 CimPal 5.2.1 Vendor presentation gridDigIt was established in the beginning of 2020 with the objective of providing state-of-the-art digital, innovative and interoperable tools and solutions. It provides consultancy services mainly in the following areas: • Power system analysis and modelling; • Networks models and data management, • IEC CIM, CGMES, conformity of IEC CIM related standards, • Interoperability aspects of grid models exchange, • Research, development and innovation activities; and • Training activities on various topics. 5.2.2 Tool description Introducing CimPal: Empowering CIM Implementation and Simplifying Workflows! CimPal, the innovative family of open-source Java applications, is here to revolutionise your CIM experience. Developed by gridDigIt and licensed under the EUPL-1.2-or-later, CimPal is your ultimate companion for effortless CIM implementation. Powered by industry-leading technologies such as Apache Jena (Apache License v2.0), TopBraid SHACL API (Apache License v2.0), and JAVAFX (GPLv2+CE license), CimPal offers a comprehensive suite of tools designed to streamline your workflow and enhance productivity. IOP Report 49 CimPal app features include: • Seamless Conversion: Effortlessly convert from RDFS to SHACL, unlocking new possibilities for your CIM implementation. • Simplified Constraints: Export SHACL constraints from an excel template, making it easier than ever to stay compliant and error-free. • Intelligent Comparison: Perform RDFS comparisons with ease, swiftly identifying changes between different versions of CIM profiles. • Documentation: Export RDFS descriptions and cardinalities in Excel, helping you to prepare clear and comprehensive documentation. • Generate datatypes mapping effortlessly, eliminating the complexity associated with CIM data management. • Generate inheritance structures from RDFS, gaining valuable insights into the organisation of your CIM profiles. • Seamless RDF Conversion: Experience hassle-free conversion between different RDF serialisations such as RDFXML, TURTLE, and JSON-LD (Note: advanced JSON-LD support is under development). CimPal CGMES Converter, simplify your workflows and unlock new opportunities with these powerful features: • Conversion: Seamlessly convert CGMES v2.4 to CGMES v3.0, effortlessly adapting to the latest standards. • Profile Support: Equipment (EQ), Steady State Hypothesis (SSH), Topology (TP), and State Variables (SV). • Conversion of boundary set IOP Report 50 Continuous Improvement: gridDigIt is actively working on expanding the converter's functionalities, so stay tuned for future updates. While the first version of CimPal CGMES Converter focuses on core features, we are committed to constant improvement and addressing user needs. Links: • gridDigIt: https://griddigit.eu/ • CimPal GitHub repository: https://github.com/griddigit/CimPal • CimPal CGMES Converter GitHub repository: https://github.com/griddigit/CimPal-CGMESConverter 5.3 Cimphony Orchestra 5.3.1 Vendor presentation For over 10 years, Open Grid Systems (https://www.opengrid.com/) has delivered industry-leading, model-driven software solutions to utilities worldwide. Open Grid Systems’ Cimphony Open Data Engine and Grid Applications software allow utilities to manage their Digital Twin using Open Standards including IEC 61968/61970/62325 (CIM), and full access using Open Interfaces defined by the ISO/OASIS OData v4.0 standard. Open Grid Systems software is used to support Network Model Management, Open Data Access, Customer Support, next-generation DERMS and advanced Data Analytics. Open Grid Systems’ software is deployed worldwide, on premises, in the cloud in AWS and Azure, and embedded within mission-critical control systems at some of the world’s largest energy companies. 5.3.2 Tool description Cimphony Orchestra is a model-driven desktop power system data management application supporting multiple power system data formats, using a modular, multi-platform framework for data management and power system analysis. IOP Report 51 The core Cimphony modules provide model-independent services for: • Data Management; • Data Validation; • Model-Driven Data Transformation; • Data Object and Schematic Visualisation and Editing; • Geographical Network Visualisation and Editing; and • Electrical Network Powerflow Analysis, including Powerflow and Topological Processing. The model-driven architecture allows support for new formats and data models to be added to Cimphony without requiring the core frameworks to be altered. 5.3.3 Expected CIM functionalities Cimphony uses a Model Driven Architecture that supports a number of data models including established open standards such as IEC CIM 10-17/100, ENTSO-E CGMES 2.4.15 & 3.0, CYMDIST, Grid Lab-D, IEEE Common Data Format, PSLF EPC, and PSS®E RAW (v30-33) along with extended standard models such as that used at ERCOT. Cimphony includes a number of tools to validate CIM XML data: • Checking the data is valid XML; • Checking the data conforms to the serialisation format rules (e.g. IEC 61970-552 CIM RDF XML) including validating XML namespaces; • Checking the data against the meta-model class structure and that classes, attributes and references are valid (e.g. ensuring any classes or attributes exist in the declared version of CIM or any customer defined extensions); and • Executing detailed validation rules defined in the Object Constraint Language (OCL) including standard rule sets based on IEC and ENTSO-E standards. Cimphony includes an OCL editor to allow users to define custom rules that can then be run against loaded data sets. The topological processor is also available to check for unexpected islanding in the network. Cimphony uses a model-driven approach to data management, validation and transformation. Data transformations are defined between models, allowing complex data translations to be modularised and defined independently of the source and target serialisation formats (such as the IEC 61970-552 CIM RDF XML standard). Cimphony includes support for a number of transformations between CIM, PSS®E RAW and CYMDIST including inter-version transformations for CIM. 5.4 EDF tools These tools have already been used in ENTSO-E 2016 IOP tests, and improved subsequently. LV Data Sets and DisNetSimpl EDF Tool contacts: [email protected] , elio.el[email protected] IOP Report 52 RiseClipse tool contacts: aurelie.dehouck[email protected] , [email protected] 5.4.1 RiseClipse This tool has been developed in collaboration with CentraleSupelec, in the context of RiseGrid 11 . https://github.com/riseclipse/riseclipse-ocl-constraints-cgmes-3 RiseClipse (open source based on Eclipse) is an umbrella name for tools based on Model Driven Engineering (MDE) technologies and dedicated to IEC standards. Open source RiseClipse components are available under the Eclipse Public License version 2.0. More information on RiseClipse is available on https://wdi.centralesupelec.fr/software/RiseClipse/ See also: https://riseclipse.github.io/ and https://riseclipse.github.io/downloads for downloads (standalone versions) Web version is available at: https://rise-clipse.pam-retd.fr/front_v2/ RiseClipse allows CIM and 61850 profiles to be tested and has been used in recent 61850 IOP tests. For now, RiseClipse is using OCL validation rules. 5.4.2 DisNetSimpl DisNetSimpl is EDF R&D network study platform, based on Matlab. DisNetSimpl has import/export interfaces compliant with CIM profiles (IEC 61968-13/CDPSM, CGMES 2.4.15, CGMES 3.0.0), but CAS need to be passed. The following figure illustrates its main features: 11 https://www.centralesupelec.fr/en/risegrid-institute-research-institute-smarter-electric-grids IOP Report 53 5.4.3 CDPSM to CIM CGMES converter This tool is used by EDF R&D to convert some Distribution CDPSM data sets (IEC 61968-13) to CGMES files (IEC 61970-600-1 and IEC 61970-600-2). 5.5 IPS 5.5.1 Vendor presentation IPS Intelligent Process Solutions GmbH is a German based company, established in 2004, and a leading provider of EAM, NMM, OMS, APM, AIP, AFRM, relay protection management and mobile workforce management software solutions for the global energy supply industry. IPS provides advanced, specialised, and valuable integrated solutions and support to client organisations worldwide to transform data into real intelligence for critical business and technical decisions. IPS offers comprehensive off-the-shelf solutions, with a focus on the utilities. IPS®SYSTEMS are characterised by their modular structure. Customers can add individual module groups according to functional requirements and implement the system step-by-step – starting with the basics and gradually implementing the full functionality. IOP Report 54 5.5.2 Tool description IPS has consistently proven itself as a leading provider of innovative solutions for the power systems industry. With IPS®NMM Network Model Management, they continue to push the boundaries of network model management, empowering organisations to optimise their power system operations and drive sustainable success in the dynamic energy landscape. IPS®NMM gives users unparalleled control over the creation, modification, administration, verification and storage of CIM-based network models. Acting as a centralised hub, this cutting-edge software empowers organisations with a comprehensive repository and management system dedicated to the development and upkeep of power system network models. Designed in accordance with the rigorous standards set forth by the CIM User Group, the IPS®NMM tool effortlessly fulfils all specified requirements. These requirements include key objectives, essential product features, proposed evaluation methods, typical NMM use cases, and a detailed list of specific requirements. At the heart of IPS®NMM lies a state-of-the-art CIM-based data repository carefully built on a database-agnostic system. In addition to its CIM–CGMES compliance, IPS goes above and beyond by offering seamless integration capabilities with various other critical systems. IPS®NMM stands out as a versatile solution that can interface with multiple systems, including ERP, SCADA, OMS and more, using IPS Identity Provider and IPS WebAPI supported CIM-based and/or non-CIM-based integration methods. IPS®NMM serves as a unifying force, bridging the gap between network models and critical systems, and enabling organisations to harness the full potential of their power system data. With IPS®NMM, organisations can effortlessly connect their power system network models to these diverse systems, IOP Report 55 enabling synchronised operations across multiple platforms. This interoperability facilitates efficient data exchange, streamlines workflows and enhances the overall effectiveness of power system management. 5.5.3 Expected CIM functionalities The overall experience, vendor interaction, contract negotiation, contract flexibility, understanding of organisational needs, responsiveness to product questions and issues, responsive service and technical support, user group, and peer community are IPS’s commitment to maintain into the future. • IPS®NMM is fully built on CIM models (IEC 61970 and IEC61968) and supports customerspecific extensions. It supports all CGMES profiles for CGMES 2.4.14. In a testing phase, it supports all the CGMES 3.0 profiles. The IPS system is compliant with the North American (NERC) standards. In addition, the IPS®NMM also supports customer-specific profiles. • The CIM model could be visualised through hierarchical trees, GEO map, list views, diagrams, property grids and reports. • IPS®NMM is updated continuously to comply with the ENTSO-E Quality of CQMES Datasets and Calculations (QoCDC) guide. IOP Report 56 • Intuitive and powerful CIM node-breaker and bus-branch modelling are available via IPS Diagram Editor. It supports the creation of single line diagrams and topological diagrams. Based on diagram editing, the CIM model is automatically updated. IPS®NMM supports customisable single line auto-layout diagrams. An easy diagram update based on the CIM model is a very useful feature. • The capability to easily merge large multi area (MAS) systems (tested with 26 TSO models simultaneously) together with the automatic generation of CGM models makes the IPS®NMM an attractive option for ENTSO-E member TSOs. IOP Report 57 • The system fully supports the conversion of PSS®E (version 33 and 35) RAW, SEQ and DYR models from<->to CIM. The conversion from/to PSS®E v35 supports both node-breaker and bus-branch model conversion. The customers with PSS®E installation could seamlessly integrate IPS®NMM with PSS®E via python interface. • IPS®NMM has a script engine for massive manipulation with CIM models. C# and Python programming languages are supported. IOP Report 64 5.10 ValiMate FEATURES • ValiMate can be used for the validation of individual datasets, IGM or CGM. • ValiMate generates validation reports in CSV and XLS formats, with the ability to customise the report format based on requirements. • ValiMate can be easily executed on Windows, Linux and Mac platforms. • ValiMate offers a REST API based on Swagger/OpenAPI in the full version. • ValiMate also offers a Docker version. • Comprehensive product documentation and 24/7 support are available to ensure a seamless experience with ValiMate. For further details, contact us at valimate.associmates.eu [email protected] A product by Associmates GmbH, Poppelsdorfer Allee 106, 53115 Bonn, Germany ABOUT VALIMATE ValiMate sets the industry standard for CGMES 3.0, CGMES 2.4.15, and other CIM standards validation engines. It is built on the power of SHACL – the Shapes Constraint Language – and can be used for any RDF based dataset validation. Out of the box, ValiMate deals with specificities of CIM for network model exchange (IEC 61970 standards) including CGMES – IEC 61970-600-1 and IEC 61970-600-2). ValiMate can be used and integrated via its command line interface or REST API. In addition, we offer a free GUI version with limited features. ValiMate The industry leading SHACL-based validation engine for CGMES 2.4.15, CGMES 3.0 and related CIM Standards IOP Report 65 6 Annex B: Summary of Issues This annex summarises issues that have been discussed in the IOP. These issues should be presented to IEC, UCAIug and ENTSO-E to apply the proposed resolutions in the next release if related specifications or standards. 6.1 TopologicalNode.ConnectivityNodes Multiplicity in Topology Profile The multiplicity of the association end TopologicalNode.ConnectivityNodes is 0..* in the Topology profile (IEC 61970-456 and IEC 61970-600-2), see the figure below. Having in mind that TopologicalNode objects are a collection of ConnectivityNode objects, the IOP proposes that the multiplicity is changed to 1..*. 6.2 PowerTransformer.PowerTransformerEnd Multiplicity in Equipment Profile The multiplicity of the association end PowerTransformer.PowerTransformerEnd is 0..* in the Equipment profile (IEC 61970-452 and IEC 61970-600-2), see the figure below. The IOP considers that there is no use cases to model a power transformer with its windings and recommends that the multiplicity is changed to 1..*. IOP Report 66 6.3 TieFlow Usage When modelling a control area, there is a question on how TieFlow is used and why a terminal can have two TieFlow objects. IOP discussions concluded that the topic is well explained in clause 4.5.17 ‘Control area modelling’, i.e. no further clarification is necessary. 6.4 Usage of Association OperationalLimitSet.Equipment When modelling operational limits, there is a question of why the association with Equipment is optional and when it is used. IOP discussions concluded that the topic is explained in CGMES v3 and there is also a constraint that checks the implementation, i.e. no further clarification is needed. In general, the reason is that the AuxiliaryEquipment does not have terminals and uses the terminal of the main conducting equipment. This is why the limits still need to be attached to the terminal, because of the equipment. The association to equipment provides information if the limit relates to the main equipment of the auxiliary equipment. The following constraint is defined: C:452:EQ:OperationalLimitSet:limits OperationalLimitSet has associations with ACDCTerminal and Equipment. In the event the OperationalLimitSet is the operational limit of the AuxiliaryEquipment, then the association end OperationalLimitSet.Equipment is also required. In the event where OperationalLimitSet.Equipment is associated with an instance of ConductingEquipment, OperationalLimitSet.Terminal shall be one of the ConductingEquipment’s Terminal-s. IOP Report 67 6.5 Clarification on the BusbarSection This issue was also raised in the CIM community and there is an issue opened here: CIM Issues #6328: Required usage of BusbarSection - WG13 Issues - UCAIug Issue Tracking System The usage of the BusbarSection was clarified among vendors, but it is still expected to have resolution of the issues and modification of the relevant standards. 6.6 Clarification on HVDC Issues Two issues were recorded in the CIM community. These are: • CIM Issues #5098: CsConverter targtAlpha and targetGamma - WG13 Issues - UCAIug Issue Tracking System • CIM Issues #6329: VsConverter required and optional attributes in SSH and SV Profiles - WG13 Issues - UCAIug Issue Tracking System Part of the issue is that there are more attributes required than necessary. In addition, there is a need to clarify the modelling styles and when the details converter model is exchanged as well as the possibilities to model transformation and handling by a receiving system. The resolution of these issues will have an impact on CIM17, i.e. CGMES v3.0-based implementations. Therefore, the process to update the standards will require further discussion. 6.7 CAS v3.0 Constraints During the preparation of the TYNDP 2022 test dataset, i.e. in the process of conversion of the data from CGMES v2.4 to CGMES v3.0 and subsequent validations with ValiMate, it was found that some of the SHACL constraints are not optimal and would require significant time and computation resource if there are extensive number of errors in the dataset, e.g. more than 500,000. The following constraints were fixed, and they need to be corrected and a new version of CAS Application profiles released: • eqbdn301:BoundaryPoint.isExcludedFromAreaInterchange-requiredTieFlow in file EQBD_NotSolvedMAS_301UML.ttl • tpn456:Switch-sameTopologicalNode in file TP_NotSolvedMAS_456.ttl • sm600:All-DanglingReferences in file SolvedMAS_600-1.ttl • sshn456:RotatingMachine-pAndQcapabilityCurveP and sshn456:RotatingMachinepAndQcapabilityCurveQ in file SSH_NotSolvedMAS_456.ttl IOP Report 68 7 Annex C: Test Procedures 7.1 On-site Rules The on-site test starts on 16 May 2023 and finishes on 17 May 2023. Test participants should be present in the ENTSO-E premises between 8:00h and 18:00h. The following ground rules to be followed during the IOP: • Vendors must submit the product release (version ID) for the software under test. If the software is not production grade, indicate when the production release will contain this software functionality. • Test witnesses need to familiarise themselves with the test models and be able to witness the correct implementation of the tested profiles. The test witnesses move between test participants to cover all vendors and ensure that each test witness witnesses each vendor. The test participants (vendors) execute all tests and complete the internal validation as well as execute the validation tools for the external file validation. The test witness ensures that all steps are executed, and all issues are noted. • The test participant (vendor) downloads the model files to be imported from the file storage location and the model files produced by the test participant are then uploaded to the agreed file server for use by other participants. The test participants (vendors) are responsible for the instance file validation and for ensuring that the files produced during the test are loaded onto the file server. However, the test witness should assist the test participant with these tasks as much as possible. At a minimum, the test witness should ensure the files are included on the file server. • Unstructured tests may be performed if there is time, and the test participant wishes to complete these tests. Any unstructured test must be documented on the test record form by the test witness for inclusion into the IOP report. Each step of the procedure followed must be fully documented. • The test participants may select what test cases and test procedure they wish to execute depending on the functionalities of their tools. The IOP report presents the results for all files used and all procedures executed. 7.1.1 Test Scoring Rules The main objective is to confirm the correctness of the specifications and discuss issues. Therefore, the following scores are used: completed, not completed. IOP Report 69 7.1.2 IOP Agenda Day 1 - 08:30h: Participants arrival - 08:45–09:15h: Welcome and introduction - 09:15–10:45h: Round table 1: • 2022 TYNDP IOP Report (issues, discussions, feedback) • CGMES 3.0 implementation • IOP framework and conformity • 2022 TYNDP IOP Report (issues, discussions, feedback) - 10:45–11:00h: Coffee break - 11:00–11:30h: Round table 1 – continuation and conclusions - 11:30–12:30h: Test session: Import/Export model using CGMES 3.0 (part 1) - 12:30–13:30h: Lunch - 13:30–14:30h: Test session: Import/Export model using CGMES 3.0 (part 2) - 14:30–15:30h: Round table 2: • Data exchange standards’ implementation. Transition between versions - 15:30–15:50h: Coffee break - 15:50–17:15h: Test session: Import/Export model using CGMES 3.0 (part 3) - 17:15–17:30h: Conclusions Day 1 - 17:30–18:30h: Networking Day 2 - 08:30: Participants arrival - 08:35–09:00: DIGIT (EU COM) Validation Platform - 09:00–09:30 HVDC, SSH and SV issues - 09:30–10:45: Test session / Discussion: Exchange of boundary and reference data - 10:45–11:00 Coffee break - 11:00–11:45 Test session / Discussion: Exchange of boundary and reference data - 11:45–12:30: Round table 3: • Conformity – how to improve FAT and define workable SAT. • Barriers for utilities, vendors, etc. - 12:30–13:30: Lunch - 13:30–14:30: Round table 4: • Exchange of power system project information - 14:30–15:30: Round table 5: • Import/Export manifest instance file - 15:30–15:45 Coffee break - 15:30–16:45: Round table 6: • The importance of data exchange serialisation (JSON-LD vs CIMXML) IOP Report 70 • Alternatives to be supported • Difference file exchange. - 16:45–17:30: Conclusions Day 2 and next steps 7.1.3 Validation Tools The following validation tools are used in the IOP, see Annex A: Information on Applications/Tools used in the IOP (alphabetical order): • Cimbion • ValiMate 7.1.4 File Naming Due to the usage of file headers, vendors should not count on file names to identify information about file types. For files exchanged during the IOP, the file name should contain the name of the tool that exported the file. All files should be grouped in folders per test performed. 7.1.5 Files Transfer IOP participants will use the following location to share information… 7.1.6 Test Logistics The test is held in Brussels, ENTSO-E premises (Rue de Spa 8, 1000 Brussels, Belgium) A webinar is organised to facilitate remote testing. The webinar will be open during all IOP days from 8:30h–18:00h CET. 7.1.7 Test Record Forms No specific test record forms were used in this IOP. 7.2 Test Procedures Description 7.2.1 CGMES v3.0 Tests Tests performed with instance data that conform to CGMES v3.0 profiles should follow test use cases (TUC) defined in CAS v3 published here: https://www.entsoe.eu/data/cim/cim-conformity-andinteroperability/ Test configurations: • Any of the test configurations included in CAS v3; • Test data developed for the purpose of the IOP. 7.2.2 New Specifications Tests Due to the short notice, vendors could not fully develop prototype application to test new functionalities. However, some of the modifications have been tested with existing applications. Unstructured testing was performed to test these cases. IOP Report 71 BIBLIOGRAPHY There are no sources in the current document.