CGMES Network Code (NC) extension

Description

The purpose of the Common Grid Model Exchange Standard (CGMES) Network Code (NC) extension project is to manage the application profiles related to ENTSO-E CIM WG project for extending CGMES to support data exchange defined in the Network Code (e.g. SOGL) to support the Regional Coordination Processes (RPC).

The goal is that the same application profiles can be used to support the TSO-TSO-DSO-DSO-SGU application processes for supporting the RCC-TSO data exchange. The application also have some support for Clean Energy Network Code.

The project include the definition of application profile according to RDFS2020, an augmented RDF serialization, that is an evolution of IEC 61970-501:2006 that describe the conversion from UML representation to RDFS.

The application profile is defined in three RDF-syntax:

• RDF/XML for backwards compatibility and support of IEC 61970-501

• Turle for better human readability

• JSON-LD for forward machine understandable processing

The project also define all relevant constraints on the vocabulary using SHACL.

The project include multiple release of the profile so that we are able to describe the difference between the version of the same application profile between releases. This to support better transition between the use of the different versions.

Installation Instructions

There a now need to install anything as there are no executable code part of the project. Any RDF-syntax editor can be used.

The artifacts can be generated using CIMTool or CIMSyntaxGen.

The tools are using the zipped Sparx Enterprise Architect (EAP) ENTSO-E CIM 17.1.0.

The application profile has been produced using CIMConteXtor and following the CGMES Profiling User Guide.

Usage

The primary usage for the project is to help software vendor to develop software tools that can support the required data exchange using these application profile.

They can also be used as input to create the base graph in an knowledge graph.

The RDFS and SHACL can also be used to support data driven validation. This can be done through a SHACL validator in your favorite development language or API, e.g. TopBrad SHACL API, Python library pySHACL, or creating validation code generated from RDFS and SHACL.

Configuration

Not applicable.

Contributing Guidelines

All branches requires pull request. There should be an issue for all pull requests.

License Information

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Acknowledgements

To be added.

Contact Information

To be added.

Badges

To be added.

Table of Contents

The project has the following content structure:

• r(release number) - top folder to identify the NC release, e.g r2.2.

  • ap - Application profile - top instance according to DX-PROF. This is not used for RDFS2020, but will be included as part of 501Ed2.

  • ap-voc - Application profile Vocabulary - In 501Ed2 this will be shared between multiple profile.

  • ap-con - Application profile Constrains described using SHACL

For each of these folder that are one folder for each of the RDF-syntax:

• rdf - for files that conforms to RDF/XML

• ttl - for files that conforms to Turle

• jsonld - for files that conforms to JSON-LD

Between each project release there will be a difference folder structure that description changes from one release to the next. This description will work on both direction (forward (added), reversal(removed) and forward and reversal (updated))

• diff_(previous release number)_(next release number) - top folder to identify the NC release, e.g diff_r2.2_r2.3. The same folder applies as for the releases. However, we have also include:

• xlsx - for files that conforms to Excle using OpenCML to make it more user friendly.

Screenshots or Demo

To be added.

Changelog

To be added.