validation and conformity test of cgmes models …1046364/fulltext01.pdf · validation and...

IN DEGREE PROJECT ELECTRICAL ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2016

VALIDATION AND CONFORMITY TEST OF CGMES MODELS OF ENTSO-E TEST NETWORKS

YIQI ZHAO

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING

Acknowledgement

I would like to express my sincere thanks to my supervisors Georgii Valdenamaiier at KTH and Lars-Ola Österlund at ABB Enterprise Software for their guidance and support during the whole thesis work. Thanks for sharing the knowledge and experience patiently and inspiring me with your professional work attitude.

I also want to say thanks to Professor Lars Nordström for offering me this thesis position and all the precious opportunities before. It is also because of the knowledge and skills gained through various courses taught by him that eventually help me to complete this project and my study at KTH.

Finally, I would thank all the staff at the department, all the classmates I have met and worked with, all my friends and families for their help and support all the way along. I could never thank you all enough.

Abstrakt: För att uppnå optimal resursdelning och öka hållbar energiförsörjning, stiger behovet av gränsöverskridande kraftöverföring ständigt. Därför frekventa utbyta information med detaljerade galler uppgifter krävs. För att standardisera sådant utbyte och därigenom främja gemensam kraftsystemstudier i Europa, Common Grid Model Exchange Standard (CGMES) grundar sig på IEC CIM (Common Information Models) utfärdats av ENTSO-E (European Network of Transmission Operators for Electricity) i 2013. En CGMES bedömning av överensstämmelse processen också inrättats att uppmuntra och undersöka antagandet av CGMES med relevanta kraftsystemtillämpningar. Huvudsyftet med denna avhandling är att validera att Network Manager produkten av ABB har genomfört CGMES ordentligt. Effektflödesberäkningar utförs baserat på ENTSO-Es provnäten och erhållna lösningarna jämförs med standard resultat samt resultaten från Power Factory (ett kraftsystem analysverktyg från DIgSILENT som redan har passerat bedömningen av överensstämmelse med framgång). Jämförelse resultaten analyseras alltså för att identifiera orsakerna till eventuella avvikelser från standardeffektflödeslösningar och ge förslag på framtida utveckling av Network Manager.

Abstract. To achieve optimal resource sharing and enhance the sustainability of energy supply, the need for cross-border power transmission is continuously growing. Therefore, frequent information exchange with detailed grid data is required. To standardize such exchange and thus to facilitate common power system studies in Europe, the Common Grid Model Exchange Standard (CGMES) based on IEC CIM (Common Information Models) was issued by ENTSO-E (European Network of Transmission Operators for Electricity) in 2013. A CGMES conformity assessment process was also set up to encourage and examine the adoption of CGMES with relevant power system applications. The main purpose of this thesis is to validate that the Network Manager product of ABB has implemented CGMES properly. Power flow calculations are performed based on ENTSO-E’s test networks and the solutions obtained are compared with the standard results as well as the results from Power Factory (a power system analysis tool from DIgSILENT that has already passed the conformity assessment successfully). The comparison results are analyzed thus to identify causes of any variation from the standard power flow solutions and to give suggestions for future development of Network Manager.

Keywords. IEC CIM, CGMES and conformity assessment, Network Manager, Power Factory, power flow calculation.

Table of Contents

1 INTRODUCTION 1

1.1 METHODOLOGY 1 1.2 PROJECT TIMELINE 2

2 CIM OVERVIEW 3

2.1 IEC CIM ARCHITECTURE 4 2.2 LAYER 1 – UML AS MODELING BASIS 4

2.2.1 Class diagram 4 2.2.1.1 Class definition 5 2.2.1.2 Relations between classes 5

2.2.2 Package diagram 7 2.2.2.1 Package definition 7 2.2.2.2 Relations between packages 8

2.2.3 Example conversion from circuit to CIM objects 8 2.3 LAYER 2 – CIM PROFILES FOR SPECIALIZATION 10 2.4 LAYER 3 – XML AND RDF FOR IMPLEMENTATION 11

2.4.1 XML basics 11 2.4.2 RDF basics 13

2.4.2.1 RDF syntax 13 2.4.2.2 RDF schema 13

3 CGMES AND CONFORMITY ASSESSMENT 15

3.1 INFORMATION EXCHANGE WITH CGMES 16 3.1.1 Central concept : Model Authority Set (MAS) 16 3.1.2 CGMES profiles and instance file types 17 3.1.3 Example of CGMES data based on ENTSO-E Test Configuration 18

3.2 CGMES CONFORMITY ASSESSMENT 19 3.2.1 First party assessment 19

3.2.1.1 Support level – CGMES conformity categories 19 3.2.1.2 Tests to perform – Test Use Case 20 3.2.1.3 Example 22

3.2.2 Second party assessment 23

4 GENERAL TEST SETUP AND TOOL DESCRIPTIONS 25

4.1 GENERAL TEST SETUP 25 4.1.1 Power flow and network models 25 4.1.2 Power flow solution comparison method and output format 27

4.2 NETWORK MANAGER (NM) 29 4.2.1 Import input files 30 4.2.2 Topology processing and power flow simulation 30 4.2.3 Export power flow result and input files 30

4.3 POWER FACTORY (PF) 31

5 TESTS AND RESULTS 33

5.1 TEST WITH IMPORT CGMES DATA INTO PF 33 5.1.1 Result from PowerFactory 2016 first release 33 5.1.2 Result from PowerFactory SP2 33

5.2 TESTS WITH TOPOLOGY PROCESSING WITH CGMES DATA IN PF 34 5.2.1 Result from PowerFactory 2016 first release 34 5.2.2 Result from PowerFactory SP2 36

5.3 POWER FLOW RESULT COMPARISON BETWEEN PF AND ENTSO-E 38 5.3.1 Result from PowerFactory 2016 first release 38 5.3.2 Result from PowerFactory SP2 38

6 CONCLUSIONS 39

REFERENCE 40

- 1 -

1 Introduction

The electrical power system is now one of the most important infrastructures that the modern society depends on. Over the past 130 years, with the development of the industry and technology, the power grid has changed from the initially centralized local system into a highly interconnected large system. In parallel with the scale expansion, growing concerns on environmental issues also led to the high penetration of distributed renewable energy today, which makes the effective control and secure operation of such system more and more difficult. To meet both the increasing electricity demand and the climate change objectives as aforementioned, the “Smart Grid” concept was put forward. The design of the smart grid all starts with using rich and intelligent information in a model-based process as addressed by [1], meanwhile, the operation of smart grid also produces much more data than before. Therefore the proper management of those network data and efficient communication between different parties over such information becomes a key issue in the development of the smart grid.

To facilitate such information exchange, a common language defining the data being exchanged is desired. The standard used for this purpose is CIM (Common Information Model) belongs to IEC (International Electrotechnical Commission), which was originally designed by Electric Power Research Institute (EPRI) to solve the problem of vendor lock-in created by EMS (Energy Management System) vendors [2], but its overall scope and usage have been extended over time. In Europe, where the market is already quite open and increasingly interconnected, the energy policy goals have been set by the European Union as: to achieve sustainability and security of energy supply and to increase the competitiveness of the market [3]. These goals create a growing need for power transmission even between different countries over long distances, which especially requires the support of large amount of high-quality system data and more detailed data exchanges. TSOs (Transmission System Operator) realized such need and thus ENTSO-E, an association of the European TSOs for electricity, started to work on creating its own standards to meet the requirement of TSOs. In 2013, ENTSO-E adopted a new standard called the Common Grid Model Exchange Standard (CGMES), which is a superset of IEC CIM and is used for data exchange in areas of system operation, network planning and integrated electricity markets [4].

The implementation of CGMES is pushed forward by requiring vendors of relevant power system applications to develop their products to be in line with the standard. Therefore, a conformity assessment process was set up by ENTSO-E to ensure the conformity of such applications with CGMES. Documents such as CGMES Test Configurations, Test Use Cases etc. are also released by ENTSO-E to be used as input files or guides to help with the adoption of CGMES. On the other hand, vendors themselves must also see the market opportunities brought by the implementation of CGMES, especially in the coming “smart grid era”. Several suppliers have actually already got the Attestation of Conformity, such as Neplan, PSS SINCAL and PowerFactory [5] etc.

ABB, as a leader in power and automation technology, also has started to develop its own product Network Manager (NM) with the functionality of exchanging CGMES data. To verify that NM has implemented CGMES properly, ABB needs to apply for and pass the conformity assessment tests conducted by ENTSO-E, which is also the main task of this thesis work. Specifically, power flow calculations are performed based on ENTSO-E’s test networks and the results are validated by comparing with ENTSO-E results as well as the results from other tools (in this project PowerFactory is selected).

1.1 Methodology

The methodology used for completing this thesis work mainly consists of three parts: background study, tool study, simulation and results comparison and analysis. The detailed explanation of each part can be listed as below:

-2-

1) Background study

To study background information about IEC CIM, CGMES standards, and the documents related to conformity assessment. To obtain a clear understanding of CIM data, CGMES profiles which to be used as input files, and the steps to be followed to evaluation the conformance

2) Tool study

To study PF and NM, especially to be familiar with the functions related to CGMES implementation and power flow calculation.

3) Simulation, result comparison and analysis

Run power flow in PF for all ENTSO-E’s test models and properly comparing the results from NM, PF and ENTSO-E. Validate the results from different tools and identify possible causes when variation or problems occurred and give feasible suggestions.

1.2 Project Timeline

The project is conducted from 18th January to 1st June.

27/01/2016: PowerFactory 2016 is released with announced CGMES functionality

01/02/2016 – 29/04/2016: Pre-study and testing procedure with PowerFactory 2016

27/04/2016: PowerFactory SP2 released

02/05/2016 – 01/06/2016: Writing report and repeat all tests with PowerFactory SP2

-3-

2 CIM Overview

With the wide use of modern digital computers in various areas of power systems, the need for properly storing and exchanging data has arisen.

For large-scale applications such as EMS, asset-management systems or work management systems, database schemas are used to define the structure of data storage, which are mostly written in the way to reflect the operator’s specific requirements; for smaller offline applications, data is then mostly organized and stored only to meet the specialty of each application [6]. Moreover, the file formats used are usually proprietary.

Under the aforementioned circumstance, the exchange of data, both externally between applications from different vendors and internally between applications of the same company, can become quite problematic and requires the users either to purchase extra applications or to develop various translators. However, these solutions are no longer feasible or efficient when the exchange becomes more and more frequent with more and more players involved, which is and will be exactly the situation in today’s deregulated and the future power system. Therefore, a single open standard allowing the use of a single, detailed and compatible file format by all vendors is desired. Specifically, this standard should fulfill the following requirements as pointed out by [6]:

1) To provide model describing the power system data in detail

2) To provide a method describing and encapsulating the data with the strong expansibility

3) Has the potential to be accepted and adopted by software vendors and the utilities

The last requirement is considered more as a commercial or regulatory challenge rather than a technical one, which could be met by letting the vendors see the economic benefits of adopting the standard and/or by releasing auxiliary standards to pushing the implementation. In terms of the first two requirements, The Common Information Model (CIM) is considered as the most promising standard created and currently used for these purposes. The role of CIM in achieving interoperability can be explained based on the GridWise Interoperability Framework as below [7], which is in line with the criteria set above.

Figure 1 Role of CIM in achieving interoperability

-4-

2.1 IEC CIM architecture

In 1996, the CIM was turned over to IEC Technical Committee 57 (TC 57): POWER SYSTEMS management and associated information exchange to be advancing through the standardize process. The TC 57 also created a layered architecture for CIM as shown below.

Figure 2 CIM architecture

The first layer is used to define general, application independent information and semantic models of the power grid, including all the needed objects and the relationships between them. The Unified Modeling Language (UML) is used as the basis to realize the modeling goal.

The second layer is named as the context layer, which restricts the information model of this first layer by introducing various profiles.

The last layer focuses on the message syntax describing the file format for the instance data. Implementable technologies, such as the most commonly used XML and RDF, belong to this layer.

Each layer will be further discussed in the following sections, emphasizing on basic knowledge of UML, CIM profiles, XML and RDF respectively.

2.2 Layer 1 – UML as modeling basis

In the field of software engineering, modeling is always considered as the essential part of a software development project. A model is an abstraction of the real world which usually describes the most relevant aspects of the project while hiding the unnecessary details. A good model helps to identify problems, to exam the implementation of functionalities and makes it easier for future expansion.

The most widespread notation used for modeling in the context of software-intensive systems is the Object Management Group (OMG) Unified Modeling Language (OMG UML) [2], which is also the basis used to create the CIM data model as mentioned above. There are thirteen types of diagrams defined in UML with mainly three different purposes: to represent static application structure, to represent behavior, and to represent interactions [9]. To understand CIM, which particular considers various elements in the power system, two diagrams are necessary to know, namely class diagram and package diagram which all belongs to the structure diagram category.

2.2.1 Class diagram

Class diagram is the most common diagram type among all the thirteen types defined in UML. It provides means of visually representing the hierarchies of objects by describing classes and the relations between them. The concept of class and the relations defined in class diagram are explained as follows.

-5-

2.2.1.1 Class definition

A class, according to [10], describes “a set of objects that share the same specifications of features, constraints, and semantics.” It is often shown by a rectangle with three compartments, holding the information about class name, attributes, and operations respectively. The compartments can be hidden such as in the case when the attributes or operations are not relevant to the aspect studied, then only the name of the class is shown.

Figure 3 Example of Window class

Figure 3 above shows an example of the Window class. The state of the class is described by the two attributes: Size and Visibility, while the behaviors the class can invoke are described by the two operations: display and hide.

2.2.1.2 Relations between classes

In order to better describing the system, different relations are defined in UML to logically connect various classes together. Some of the most commonly used relations such as Association, Aggregation,

Composition, Dependency, and Generalization will be explained in this section.

1) Association

Association is used between at least two classes to describe usually longer lasting relationships. It can be graphically represented by a solid line between the related classes or usually with an arrow added at one end to illustrate the direction. At both ends of the association link, multiplicity can be found, indicating the number of instances can be involved in this relation with a lower and an upper bound value specified. An association can also have its own name, which is mainly for the better understanding of the user. The direction of the association between certain classes is not fixed. However, the multiplicities and the name should be precise and correspond with the direction used without causing any confusion.

An example of this relationship is shown as below:

Figure 4 Association example

In this example, the association relationship between the Undergraduate class and the Subject class can be represented in two ways with different names and directions. However, in both case, the relation should be interpreted as: an undergraduate can study zero to infinite number of subjects while a subject is studied by one to infinite students (assuming that the subject no longer exists if no one studies).

2) Aggregation and composition

-6-

Aggregation and composition are two special kinds of association, indicating that one class is a container of another [6]. The difference between these two relations is that: for aggregation, the involved classes are not totally inter-dependent while with a composition relation the “contained” object is strongly dependent on the “container” object. Figure 5 shows examples of both relationships, where aggregation is represented by a solid line with a clean diamond and composition is represented using the solid line with a black diamond instead.

Figure 5 Aggregation and composition example

In this example a garden can contain none or many trees and if the garden is destroyed the tree can still be alive. However, with the Tree-Leaf composition relation, leaves can no

longer exist without the existence of the tree.

3) Dependency

Dependency represents a weaker relationship than association which signifies “that a single or a set of model elements requires other model elements for their specification or implementation” [10]. Unlike association, it usually represents the relationship that doesn’t persist long. The graphical representation of dependency is a dashed line with an arrow at the end. Moreover, in UML a mechanism called stereotypes is also used to describe additional features and specify different kinds of dependencies. Some predefined stereotypes such as <<use>>, <<realize>> etc. are also brought.

An example of the dependency relationship is given as below. In this example, the Car class is dependent on the Wheel class and the specific dependency type is <<use>>.

Figure 6 Dependency example

4) Generalization (Inheritance)

Unlike the previous relationships, generalization is used to describe the relation between one general class and its specialized versions. In the context of object-oriented programming languages, it stands for the concept of inheritance and can be explained as the relation between a superclass and the sub-classes derived from it. Therefore, with generalization, a specialized class would inherit all the features from the general class but also holds its own attributes, operations and relations with other classes.

-7-

A line with a triangle is used to graphically represent generalization and a simple example can be seen as in Figure 7. Both Student and Staff class are specialized versions of the class Person, having the same attributes of Name and Gender. Meanwhile, they all have their own special attributes that the Person class doesn’t contain.

Figure 7 Generalization example

2.2.2 Package diagram

When modeling a middle or large scale system, the number of basic elements such as classes or use cases created would become very large. Therefore, to better organize the overall model, the system should be represented at an even higher abstraction level and the package diagram is thus introduced.

2.2.2.1 Package definition

A package groups the related basic elements and provides a way of defining namespaces for all the grouped members. It is a namespace for its members and may also contain other packages thus to create the hierarchy. Another functionality of package is that it can import individual elements or all elements from other packages.

The visual representation of a package looks like a file folder icon and the inclusion of the package can be shown using two different ways as illustrated in the figure below. In this example, the two classes named HydroTurbine and PhotovoltaicModule are all contained in the package named Generation.

Figure 8 Two ways to illustrate package inclusion

-8-

2.2.2.2 Relations between packages

Similar to the class diagram, various relationships are also used in the package diagram to describe the logical relations between packages. The mostly involved relation is dependency, which has the same definition and visual representation as given in the previous section. Stereotypes are also used to depict the precise meaning of a relation and an example is given as below.

Figure 9 Example relationships between packages

2.2.3 Example conversion from circuit to CIM objects

The information provided in sections 2.2.1 and 2.2.2 is enough for understanding the syntactic elements used in CIM. In this section, an example is also given, which illustrates how a circuit can be converted into the corresponding CIM objects.

The example circuit is given by Figure 10, which consists of a load, a line, a busbar, a power source, three breakers and two transformers.

Figure 10 Example circuit

Except for the power transformers, all other above-mentioned elements can be mapped to their corresponding classes in CIM and the mapping results with all the classes specified in rectangles are shown as below.

-9-

Figure 11 Mapping circuit elements with CIM elements

The transformer in CIM is not mapped to a single class but modeled as a container class with various components associated with it. Figure 12 shows the class diagram of transformer. Using the knowledge provide in section 2.2.1, it can be seen that PowerTranformer is a “container” object that contains one to several TransformerWindings and itself is derived from the Equipment class. When a TapChanger is present, it would be associated with a specific TransformerWinding. Therefore, the two transformers in the example circuit will be finally represented by four TransformerWindings (two for each) and one TapChanger for transformer 17-132.

Figure 12 Class diagram of transformer in CIM

Additionally, an EquipmentContainer class is also defined in CIM to represent both the electrical and non-electrical containment of a group of Equipment. Example EquipmentContainer classes are VoltageLevel, Substation, and Line. More details can be found in [6] and will not be discussed here.

Figure 13 is the final CIM representation of the example circuit. The ConnectivityNode and Terminal are also CIM classes, which is used to represent the connection between grid components. Any ConductingEquipment is associated with one or several terminals and terminals of different CoductingEquipments are connected through a ConnectivityNode if the modeled real objects are connected, such as the connection between Load A and Breaker 33 kV. The mentioned CIM classes in this example will also be involved in later sections and will not be explained again. However, more details about the class definitions can be found in [6] and in corresponding standards.

-10-

Figure 13 Final CIM representation of the example circuit

2.3 Layer 2 – CIM profiles for specialization

A CIM profile is a subset of the CIM UML model, containing only the needed CIM objects for a particular usage. It limits the scope of CIM by introducing additional restrictions such as the restriction on the cardinality of associations and it also distinguishes mandatory and optional attributes, making CIM easier to be applied in various projects. In other words, CIM profiles provide a contextual model instead of the information model from the first layer. The figure below shows an example of changing from information to contextual model, where the overly complex information (both classes and attributes) is muchly reduced.

Figure 14 Information model and contextual model

-11-

Even profiles are designed to cover the specific information for certain exchange, they could be relevant to multiple use cases. For instance, the required classes for exchanging topology information are identical between different use cases. Therefore an approach of combining several profiles into a single Profile Group for data exchange is used, making profiles more focused and reusable [11].

Accordingly, those profiles should also be used as the base for any interoperability or conformity tests. An example of this is to perform the conformity assessment of power flow applications against CGMES, a superset of ENTSO-E CIM Profile 1, which will be discussed in later sections.

The CIM profile can be intra-corporate and user defined, but there are also some large standardized profiles that are widely spread. Examples of the commonly used CIM profiles are [2]:

Name District Usage

The Common Power System Model (CPSM)

USA Exchange of transmission system models

The Common Distribution Power System Model

(CDPSM)

Europe Exchange of distribution power system

models

ENTSO-E profile Europe Exchange of transmission system models

Table 1 Commonly used CIM profile

2.4 Layer 3 – XML and RDF for implementation

The first two layers have already provided means for creating a general information model and also for restricting the model to certain purpose. However, in order to describe the abstract CIM model or to exchange it, certain message format should be decided. The implementation language to be used is never bounded, however, the fulfillment of following requirements is always preferred.

1) Well-structured and extensible

2) Machine-readable and human-legible

3) Easy to implement and independent from platform and products

4) Broad usage

The eXtensible Markup Language (XML) is exactly a self-describing language of such type, which is first designed by a working group supported by the World Wide Web Consortium (W3C) in 1996 with the basic original design goal of providing a format usable over the internet that supports various applications [12].

The idea of using XML to create the model exchange format for CIM data was first proposed in the USA and adopted by the Data Exchanging Working Group of NERC (North American Electric Reliability Corporation) [13] and is now widely accepted and used by EMS vendors as well as in other industries.

In this section, the basic knowledge of XML will be presented and the limitation of only using XML for CIM data is also analyzed thus led to the introduction of Resource Description Framework (RDF).

2.4.1 XML basics

XML syntax uses tags with the common format as:

<tag 1>...contained content...</tag 1>

The tags along with the content in between are defined as an element in XML and the tag name is actually the name of the elements which is mandatory. The content can contain other elements as well and those contained elements are then treated as “children” of the current element. In the case when the content is empty, the “<tag/>” format can be used.

Elements can also have attributes, which are written right after the element name within the start-tag.

-12-

An XML document is collection of XML elements following certain structure. An example is given as below.

Figure 15 Example simple XML file

The first two lines are a prolog and a declaration of document type respectively followed by the root element i.e. “meeting” in this case. This meeting element has a single attribute “ID” with the value of “SUM’2000”, it also contains two child elements “where” and “when” which include other children of their own.

Another thing can be noticed from this example is that unlike other languages such as HTML, XML allows the flexible definition of the vocabularies used for tags, for instance, “meeting”. This equips XML with the high flexibility to be used by any application. However, two things should be pay attention to:

1) Naming conflicts should be avoided when using vocabularies

2) A common understanding of the vocabularies is necessary for the users

The first problem is solved by using namespace in XML, which “qualify a name using an Internationalized Resource Identifier (IRI)” [2]. It is usually declared using an attribute named “xmlns” of the root element. The name of namespace can then be used as prefix of elements or attributes in the XML documents to define the specific scope of it.

As for the second issue, a document called XML schema is created. With an XML schema, information such as element types, number and type of attributes associated with each type of elements, data types of attributes and so on can be specified, putting constraints on the structure and content of a particular XML document.

An example XML schema with namespace used is taken from [6] and presented as below.

Figure 16 Example XML schema

-13-

However, a disadvantage of XML is that it only supports the representation of parent-child relation by using sub-elements inside a node. There is no way of expressing the relationship between two nodes at the same level (i.e. two entries of the XML documents). To achieve this, the Resource Description Framework is used, which is explained in next section.

2.4.2 RDF basics

“The Resource Description Framework is an XML schema used to provide a framework for data in an XML format by allowing relationships to be defined between XML nodes.” [11].As the name implies, RDF basically describes resources. 2.4.2.1 RDF syntax In RDF syntax, a resource is identified by a URI (Unique Resource Identifier). Resources also have properties, which are characteristics of the resource and can be described with a value [13]. The triple of these three elements, i.e. (resource, property, value) is defined as a statement in RDF and can be graphically represented as below. The value in the statement can also be another resource.

Figure 17 RDF syntax using triple

In the context of CIM XML, a unique ID is assigned to each element as attribute under the RDF namespace. The reference between elements can be made by adding a resource attribute to an element and having its value pointing at another element’s ID. An example can be seen as below, where the relationship between the Terminals and the ACLineSegment are established using this mechanism.

Figure 18 Example of using RDF in CIM XML file

2.4.2.2 RDF schema

Similar to the XML schema mentioned before, RDF schema also provides means of describing specific vocabularies according to its user’s particular need. The schema provides a type system that allowing the user to define resources as instances of classes and to organize them in a hierarchy. The schema could also be extended to creating sub-classes. In the following example, the element subClassOf has a resource attribute with its value referring to the book class.

Figure 19 Example RDF schema

-14-

Until this point, the CIM UML model which is an object-oriented design can be easily mapped to RDF and RDF schema. Specifically, objects in UML can be mapped to resources in RDF, attributes of objects and associations correspond to properties in RDF. Various classes defined in CIM UML model can also be defined as classes in RDF schema and the inheritance relationship between classes can be represented using the “subClassOf” RDF schema property mentioned above.

-15-

3 CGMES and conformity assessment

The exchange of electricity between countries became possible from 1921, when power was transmitted from Nancy, France, through Switzerland to Milan in Italy. This exchange created several challenges but also first time pointed out the importance of coordination. During the World War II, the electricity supply industry was under heavy burden and it was realized that the existing capacities needed to be expanded and the energy supply should be reconstructed to achieve higher efficiency. At that time, coal and lignite were still the main power resources, therefore more interconnections between countries were established after the war with the original purpose of making effective use of the limited resource. In 1957, the liberalization of occasional exchange of electricity between countries for emergency supply was achieved and can be done by putting through a telephone call. Meanwhile, the liberalization of energy supplies also took place thus to ensure that the supplies were not restricted by foreign exchange allocations of the countries. [14]

Since then, great progress has been made in areas such as manufacturing, power transmission and electricity market construction, making the European power network highly interconnected today and regional energy trading was realized. Additionally, the growing concerns for environmental issues lead to the active encouragement of using renewable energy, which also needs the support of a strong interconnected power grid and frequent power exchanges. Apparently, such cross-border exchanges can no longer be done simply in a phone call as in the 1960s but need standardized management and rational arrangement based on precise knowledge of the grids.

The organization responsible for these issues in Europe is European Network of Transmission System Operators for Electricity, which was founded by European TSOs and established in 2009. Its organizational structure is illustrated by the chart below, consisting four committees with different focuses.

Figure 20 ENTSO-E organizational structure

System Development and System Operations processes within ENTSO-E require accurate analysis of the interconnected networks, which heavily depend on the accuracy of the grid model and operational data. Therefore, in 2009 ENTSO-E developed its first CIM Model Exchange profile (first edition) based on the IEC CIM standards, which was intended mainly to meet the requirements for power flow and short circuit analysis of the ENTSO-E networks. Three ENTSO-E file types were included

-16-

in this profile, namely the State Variables (SV) file, the TSO Topology (TP) file and the TSO Equipment (EQ) file [15].

Later on, it is realized that the grid model exchange can benefit from the sharing of information related to the system dynamics, the diagram layout of the system and the geographical location of various grid components. Therefore, efforts were made to update the original profile with more features included and finally result in the initial issue of Common Grid Model Exchange Standard in 2013. On 7th August 2014, CGMES version 2.4.15 was approved and it is the currently used baseline exchange standard for information exchange between systems and applications.

Moreover, ENTSO-E has the objective of ensuring the interoperability of the power system applications used by TSOs, thus the CGMES Conformity Assessment Framework was approved by ENTSO-E to exam the compliance of these applications with CGMES. A CGMES Conformity Assessment Scheme (current version 1.1.3) is also available that specifies all the needed documents for suppliers of applications to evaluate its conformance with CGMES.

This chapter consists of two parts. The first part provides basic knowledge needed to understand information exchange with CGMES, emphasizing on how the CGMES data is organized. The second part focuses on the information related to the CGMES conformance evaluation process and criteria for passing the conformity test.

3.1 Information Exchange with CGMES

The CGMES is based on the following IEC CIM standards applicable for the CIM UML 16v25 [19]:

IEC 61970-552: CIM XML Model Exchange Format

IEC 61970-301: Common Information Model (CIM) Base

IEC 61970-302: Common Information Model (CIM) for Dynamics Specification

IEC 61970-452: CIM Static Transmission Network Model Profiles

IEC 61970-453: Diagram Layout Profile

IEC 61970-456: Solved Power System State Profiles

IEC 61970-457: Common Information Model (CIM) for Dynamics Profile

IEC 61968-4: Application integration at electric utilities – System interfaces for distribution management - Part 4: Interfaces for records and asset management

CGMES takes and uses the CIM concepts and rules from the above standards and defines new sets of rules or requirements according to TSOs’ business processes and ensures interoperability.

3.1.1 Central concept : Model Authority Set (MAS)

For neighboring parties in an interconnected network, each party should be able to obtain the network model of its neighbors’ territory and must also be able to assemble the models into a complete analytical model so that the common studies could be conducted by both sides. To achieve this, each party should export its internal model to its neighbor and import the neighbor’s internal model to create its external model. Meanwhile, any update with the internal models should be transferred and applied to the neighbor’s external model with little manual attention [16]. Thus a CIM concept called Model Authority Set (MAS) is introduced to facilitate this kind of internal model exchange, allowing the interconnection model to be divided into disjointed sets of objects so that different parties can only take responsibility for the corresponding parts of the model [19].

There are two types of MASs namely Reginal Set (RS), representing a single authority, and Boundary Set (BS) which is a bipartisan authority between two RSs. Their definitions can be visually represented as the example below.

-17-

Figure 21 Graphical representation of MAS

In the context of CGMES, each TSO in ENTSO-E is considered as a Model Authority and manages the corresponding MAS. Therefore, the RS mentioned above is referred as TSO set in CGMES.

Each node in Figure 21 represents corresponding single CIM object and the branches between nodes stand for the relationships. As can be seen from the figure, each object instance is assigned to one and only one MAS and there is no direct relation between objects from two different TSO sets. Instead, the relation is established by having the associations between each of the TSO set with the BS. Each MAS contains a set of different instance files describing the internal objects and relationships, which will be further described in next section.

3.1.2 CGMES profiles and instance file types

As mentioned in section 2.3, profiles are usually designed to be small, reusable and only focused on the exchange of certain type of information. In CGMES, there are nine different profiles defined, referring to the different subsets of classes, relationships, and attributes required to accomplish the corresponding particular type of interface [19]. In term of actual exchange, then only instances of the concrete classes defined in the profiles are used, which are referred as instance files in CGMES and are described as below.

1) Equipment (EQ) instance file describes the equipment in the power system model covered

by a MAS

2) Topology (TP) instance file describes the topology objects in a MAS and it is a result of topology processing in the case when the exchange is based on a node-breaker model (details about network model can be found in 4.1.1)

3) Steady state hypothesis (SSH) instance file provides all objects required to exchange input parameters to be able to perform load flow simulations

4) State variables (SV) instance file contains all objects required to complete the specification of a steady-state solution

5) Dynamics (DY) instance file contains data necessary to model the system dynamic behavior, such as the transient/sub-transient parameters of various equipment

6) Diagram layout (DL) instance file contains data needed for the model diagram

7) Geographical location (GL) instance file contains Geographic Information System (GIS) data

-18-

8) Boundary equipment (BD_EQ) instance file contains all objects defined in the boundary equipment profile and includes data for boundary information relating to a given exchange.

9) Boundary topology (BD_TP) instance file contains all objects defined in the boundary topology profile and includes data for boundary information relating to a given exchange.

A given logical exchange contains multiple files and it is defined by CGMES that all these files should be zipped together. The ZIP files are used for import or export by any applications.

3.1.3 Example of CGMES data based on ENTSO-E Test Configuration

To better understand the usage of instance files and how these data is organized, an example based on the type 1 MicroGrid test network from ENTSO-E Test Configuration is given in this section and the corresponding diagram is illustrated by Figure 22.

This model shows the interconnected network consists of the Belgian (BE) grid and the power grid of Netherland (NL). It can be seen that the MAS concept from section 3.1.1 is used here thus the model is divided into three parts, i.e. two TSO sets for BE and NL respectively and one BS in between, which are marked as BE MAS, NL MAS and Boundary in the figure.

P=557.219 MW

Q=249.237 Mvar

P=-555.848 MW

Q=-202.587 Mvar

NL_TR2_3

Tap=5

NL_Busbar__4u=102.33 %

Uang=-3.49194 °

NL-Busbar_3u=101.70 %

Uang=-1.71611 °


Uang=-3.49194 °

NL-_Busbar_1u=102.15 %

Uang=-6.36182 °


Uang=0.00000 °

NL-Line_4

P=28.659 MW

Q=-3.960 Mvar

NL-Line_2

P=50.684 MW

Q=-87.968 Mvar

NL-Line_1

P=52.033 MW

Q=-102.196 Mvar

NL-Line_5

P=96.206 MW

Q=-158.309 Mvar

NL-Line_3

P=28.075 MW

Q=-1.487 Mvar

NL-TR2_1

Tap=-2

NL_TR2_2

Tap=17

busbarcoupler 1B1

NL-G2

P=-140.000 MW

Q=26.673 Mvar

NL-G3

P=-150.000 MW

Q=26.673 Mvar

NL-G1

P=-557.219 MW

Q=-249.237 Mvar

NL-Load_3

P=488.265 MW

Q=231.608 Mvar

NL-Load_2

P=10.000 MW

Q=10.000 Mvar

NL-Load_1

P=90.000 MW

Q=280.000 Mvar

NL-S1

P=0.000 MW

Q=-52.178 Mvar

P=-298.922 MW

Q=110.651 Mvar

P=290.000 MW

Q=-53.346 Mvar

P=-288.964 MW

Q=69.853 Mvar

P=299.812 MW

Q=-93.426 Mvar

P=-232.229 MW

Q=64.406 Mvar

P=232.229 MW

Q=-64.406 Mvar

BoundaryNL MAS

NL-G1-ExcAC1A

NL-G1-PSSB

NL-G1-IEEEEG3

NL-G3-GovHydro1

NL-G3-PSSB

NL-G3-Exc-ST1A

NL-G2-Turb-GovHydro1

NL-G2-PSSB

NL-G2-Exc-ST1A

NL-G1-Vcomp

NL-G2-Vcomp

NL-G3-Vcomp

XCA_AL11u=102.79 %

Uang=-6.59595 °

XZE_ST23u=102.50 %

Uang=-5.58573 °

BE-Busbar_6u=105.00 %

Uang=-9.39998 °


Uang=-6.66500 °


Uang=-7.06581 °


Uang=-8.77964 ° XZE_ST24u=102.26 %

Uang=-5.64409 °BE-Busbar_2u=99.94 %

Uang=-7.63282 °

XWI_GY11u=102.72 %

Uang=-6.58429 °


Uang=-6.78901 °

XKA_MA11u=103.15 %

Uang=-6.75517 °

BE-Line_5

P=83.052 MW

Q=-138.476 Mvar

BE-Line_4

P=36.978 MW

Q=-80.702 Mvar

BE-Line_3

P=36.701 MW

Q=-54.201 Mvar

BE-Line_7

P=26.835 MW

Q=-1.493 Mvar

BE-Line_1

P=27.396 MW

Q=-0.427 MvarBE-Line_2

P=27.916 MW

Q=2.741 Mvar

BE-Line_6

P=11.242 MW

Q=1.072 Mvar

BE-TR2_2

Tap=10

BE-TR2_3

Tap=18

BE-TR2_1

Tap=16

BE-TR3_1

Tap=17

BE-G1

P=-90.000 MW

Q=51.127 Mvar

BE-Load_2

P=200.000 MW

Q=50.000 Mvar

BE-Load_1

P=200.000 MW

Q=90.000 Mvar

BE_S2

P=1.181 MW

Q=-59.058 Mvar

BE_S1

P=0.000 MW

Q=-330.750 Mvar

P=55.223 MW

Q=39.209 Mvar

P=90.000 MW

Q=-51.127 Mvar

P=-89.686 MW

Q=57.144 Mvar

P=-55.161 MW

Q=221.874 MvarP=55.963 MW

Q=-217.572 Mvar

P=-55.154 MW

Q=-38.268 Mvar

P=-216.065 MW

Q=-85.396 Mvar

P=99.586 MW

Q=3.250 Mvar

BE-G1-VcompBE-G1-ExcAC4A

BE-G1-PSSB

BE-G1-TurbIEEEEG1

BE MAS

Micro Grid T1

L-1230804819

P=1.000 MW

Q=0.000 Mvar

BE_TR_BUS1u=105.00 %

Uang=-9.39998 °

BE_Breaker_1

P=-55.161 MW

Q=221.874 Mvar

P=55.161 MW

Q=-221.874 Mvar

BE_Breaker_2

P=55.963 MW

Q=-217.572 Mvar


Uang=-6.78901 °

P=-55.963 MW

Q=217.572 Mvar


Uang=-9.39998 °

BE_Breaker_3

P=55.154 MW

Q=38.268 Mvar

P=-55.154 MW

Q=-38.268 Mvar

BE_TR_BUS4u=99.70 %

Uang=-8.77964 °

BE_Breaker_4

P=55.223 MW

Q=39.209 Mvar

P=-55.223 MW

Q=-39.209 Mvar


Uang=-9.39998 °

BE_Breaker_5P=89.686 MW

Q=-57.144 Mvar

P=-89.686 MW

Q=57.144 Mvar

BE_Breaker_10

P=117.496 MW

Q=92.682 Mvar

BE_BUSBAR_10u=104.70 %

Uang=-6.66500 °

P=-117.496 MW

Q=-92.682 MvarP=117.496 MW

Q=92.682 Mvar

BE_BUSBAR_12u=108.68 %

Uang=-6.78901 °

BE_Breaker_12

P=99.586 MW

Q=3.250 Mvar

P=-99.586 MW

Q=-3.250 Mvar

NL_TR_BUS1u=102.33 %

Uang=-3.49194 °

NL_TR_BUS2u=101.80 %

Uang=0.00000 °

NL_BREAKER_1P=-555.848 MW

Q=-202.587 Mvar

P=555.848 MW

Q=202.587 Mvar

NL_BREAKER_1

P=-557.219 MW

Q=-249.237 Mvar

P=557.219 MW

Q=249.237 Mvar

N1230822396u=102.33 %

Uang=-3.49194 °

NL_BREAKER_3

P=-288.964 MW

Q=69.853 Mvar

P=288.964 MW

Q=-69.853 Mvar

N1230822413u=101.70 %

Uang=-1.71611 °

NL_BREAKER_4

P=-290.000 MW

Q=53.346 Mvar

P=290.000 MW

Q=-53.346 Mvar

CIRCB-1230991526

N1230991529u=99.94 %

Uang=-7.63282 °

P=23.868 MW

Q=-1.275 Mvar

P=-23.868 MW

Q=1.275 Mvar

CIRCB-1230991544

P=-25.804 MW

Q=-2.825 Mvar

N1230991550u=99.94 %

Uang=-7.63282 °

P=25.804 MW

Q=2.825 Mvar

CIRCB-1230991718

P=-83.052 MW

Q=138.476 Mvar

N1230991724u=108.68 %

Uang=-6.78901 °

P=83.052 MW

Q=-138.476 Mvar

CIRCB-1230991736

N1230991739u=108.68 %

Uang=-6.78901 °

P=-36.701 MW

Q=54.201 Mvar

P=36.701 MW

Q=-54.201 Mvar

CIRCB-1230992174

CIRCB-1230992183

CIRCB-1230992192

N1230992195u=102.15 %

Uang=-6.36182 °

N1230992198u=102.15 %

Uang=-6.36182 °

N1230992201u=102.15 %

Uang=-6.36182 °

P=-96.206 MW

Q=158.309 Mvar

P=96.206 MW

Q=-158.309 Mvar

P=-52.033 MW

Q=102.196 Mvar

P=52.033 MW

Q=-102.196 Mvar

P=-50.684 MW

Q=87.968 Mvar

P=50.684 MW

Q=-87.968 Mvar

N1230992228u=102.33 %

Uang=-3.49194 °

N1230992231u=102.33 %

Uang=-3.49194 °

CIRCB-1230992240

CIRCB-1230992249

P=-28.659 MW

Q=3.960 Mvar

P=28.659 MW

Q=-3.960 Mvar

P=-28.075 MW

Q=1.487 Mvar

P=28.075 MW

Q=-1.487 Mvar

CIRCB-1230992276

CIRCB-1230992285

N1230992288u=99.70 %

Uang=-8.77964 °

N1230992291u=99.70 %

Uang=-8.77964 °

P=27.916 MW

Q=2.741 Mvar

P=11.242 MW

Q=1.072 Mvar

P=-27.916 MW

Q=-2.741 Mvar

P=-11.242 MW

Q=-1.072 Mvar

CIRCB-1230992399

CIRCB-1230992408

N1230992411u=99.94 %

Uang=-7.63282 °

N1230992414u=99.94 %

Uang=-7.63282 °

P=-31.355 MW

Q=-1.200 MvarP=31.355 MW

Q=1.200 Mvar

P=-17.316 MW

Q=-0.350 MvarP=17.316 MW

Q=0.350 Mvar

AC

ACGENC-1230999187

P=-117.496 MW

Q=-92.682 Mvar

Figure 22 Diagram of Micro-grid type 1

Figure 23 gives an overall idea about how the ENTSO-E Test Configurations i.e. the grid data of the test networks, is organized.

Figure 23 File structure of ENTSO-E Test Configurations

The ENTSO-E Test Configurations is given as a ZIP file (gray regtangle in Figure 23 )which contains totally four test networks namely MicroGrid, MiniGrid, SmallGrid and RealGrid. Each grid is stored in the corresponding file folder (see the black regtangle in Figure 23). There could be several different

-19-

types of grid model for each grid. For instance, the “Type1_T1” folder in the “MicroGrid” folder (see the red regtangle in Figure 23) actually stores the data for the particular model of the MicroGrid named as type 1 model. The content of the “Type1_T1” folder is shown by the orange box in the figure. Usually, the model data is organized as a set of ZIP files correspond to the MASs in the grid model. For example, the grid model given in Figure 22, can be obtained using the data in the three ZIP files for BD, BE, and NL. The blue and green boxes illustrate the content of the BS ZIP file and the two TSO set ZIP files respectively, from where we can see that all the instance file types mentioned in section 3.1.2 are stored accordingly inside them as XML files.

The test configurations are used as input data in the conformity assessment test described in later sections.

3.2 CGMES conformity assessment

To achieve the efficient data exchange between systems, relevant power system applications are required to be in line with CGMES. Consequently, a conformity assessment process was established by ENTSO-E. The process consists of two stages: first party assessment and second party assessment and the final result is that the supplier of the application receives opinions, positive or negative, about the Attestation of Conformity.

3.2.1 First party assessment

The main process of the first party assessment stage can be illustrated by Figure 24. It is triggered by a supplier that would obtain an Attestation of Conformity for its application. The supplier first requests the test models to be used from the Assessment Body and then perform tests based on these models. A Declaration of Conformity can be issued by the supplier if the test results are positive, and the

declaration will be handed in to and registered by the Assessment Body, which is the end of this stage.

Figure 24 Basic process of the first party assessment

The test models mentioned above is the CGMES Test Configuration which has already been discussed in section 3.1.3.

In addition to understanding of the basic process of this stage, suppliers involved should also have a clear goal on what level of conformity their applications are going to achieve and what tests should be performed then. Therefore, it is important to introduce the CGMES conformity categories and the Test Use Case (TUC).

3.2.1.1 Support level – CGMES conformity categories

A measure of the CGMES Conformity achieved by an application is the CGMES conformity categories defined by ENTSO-E and is illustrated by the chart below.

-20-

Figure 25 CGMES conformity categories

As implied by their names, the three different conformity categories are defined to measure the CGMES conformity of an application from different aspects:

1) Standard category is the category at the highest level which measures the overall support that an application can offer.

2) Profile category indicates which CGMES profiles can be supported by the application.

3) Function category represents the supports the application provides in terms of various functionalities.

Under each category, there are also three different grades used: “Gold”, “Silver” and “Bronze”, indicating three different support levels in a descending order. Each grade of the corresponding conformity category is defined by specifying the TUC to be passed by an application.

3.2.1.2 Tests to perform – Test Use Case

The TUC are used in the process to issue a Declaration of Conformity or in the processes to assess an application for issuing an Attestation of Conformity. There are 46 TUC defined by ENTSO-E, which are grouped into three main categories: import category (TUC 1- TUC 12), export category (TUC 13 –TUC 24) and functional category (TUC 25 – TUC 46). More detail information of all the applicable TUC can be found in [21].

Passing all the TUC defined for the conformity assessment is not always necessary and instead, as mentioned before, it depends on the support grade of each conformity category that an application wants to obtain. Figure 26 illustrates the CGMES Function Category matrix, where all the TUC are

listed and marked with different grades according to various function categories.

-21-

Figure 26 CGMES Function Category matrix

Given the matrix, the rules for what TUC must be used to achieve specific support grade of each conformity category are then defined as below [22].

1) Standard category

Gold: the application needs to pass all the TUC defined for the CGMES conformity assessment

Silver: the application needs to pass all the TUC marked as “Silver” and “Bronze” defined for the CGMES conformity assessment

Bronze: the application needs to pass all the TUC marked as “Bronze” defined for at least one profile or function

2) Profile category

Gold: the application needs to pass all TUC defined for the “Import” and “Export” CGMES function categories. The application supports this profile in combination with other CGMES profiles supported by it

Silver: the application needs to pass all TUC marked as “Silver” and “Bronze” that are defined for the “Import” and “Export” CGMES function categories

Bronze: the application needs to pass all TUC marked as “Bronze” that are defined for the “Import” and “Export” CGMES function categories

3) Function category

Gold: the application needs to pass all TUC defined for a CGMES function for the profiles supported by it

Silver: the application needs to pass all TUC marked as “Silver” and “Bronze” that are defined for a CGMES function for the profiles supported by it

Bronze: the application needs to pass all TUC marked as “Bronze” that are defined for a CGMES function for the profiles supported by it

-22-

Using the rules explained above together with the matrix, the supplier can know the TUC to be used during the assessment process thus can perform the tests accordingly to evaluate the conformity of their product.

Until this point, the supplier already has enough information to issue the Declaration of Conformity if the test results are positive. The main content of the declaration is also given by Figure 27, where the gray fields (only when relevant to the application) are to be filled in by the supplier with “Gold”, “Silver” or “Bronze” accordingly.

Figure 27 Main content to be filled in Declaration of Conformity

3.2.1.3 Example

To further explain what the targeted conformity grade is necessary for an application to be used for specific data exchanges and what TUC is required accordingly, an example is given in this section.

Assume that an application is designed as;

To perform the load flow calculation only on a bus-branch model (see 4.1.1)

To support difference exchange

To support model assembling

Not able to perform short circuit analysis or any functions related to DL, GL DY profiles

Then, according to the CGMES Function Category Matrix, the TUC to be passed are:

Import: TUC 1, 2, 3, 4, 5, 9, 10, 11

Export: TUC 13, 14, 15, 16, 17, 21, 22, 23

Update and Repository: TUC 10, 11, 12, 22, 23, 24

Diagram layout: Not related, since this application is not designed to support DL profile

Geographical location: Not related, since this application is not designed to support GL profile

Load flow (Node-breaker input representation): Not related, since this application is not designed to support the node-breaker model

Load flow (Bus-branch input representation): TUC 1, 9, 10, 11, 12, 13, 21, 22, 23, 24, 25,27 29, 33 and from 37 to 46 (assume the application can pass all TUC defined for gold)

Dynamic: Not related, since this application is not designed to support DY profile

Short circuit: Not related, since this application is not designed to support short circuit calculation

-23-

The supplier can then issue a Declaration of Conformity for the application if all the TUC are passed with positive results and the declaration would look as below:

Figure 28 Example Declaration of Conformity

3.2.2 Second party assessment

This stage is triggered by the valid registration of the supplier when the Declaration of Conformity is received. It is composed of three parts, the evaluation, the opinion formation and the publication and archiving. The following three charts show basic work flow of each part. However due to the scope

of this report, details of this stage will not be discussed here but can be found in [23].

Figure 29 Evaluation process in second part assessment

Figure 30 Opinion formation process in second part assessment

-24-

Figure 31 Publication and archiving process in second part assessment

-25-

4 General test setup and tool descriptions

The focus of this thesis project is to use Network Manager (NM) and Power Factory (PF) for solving power flow on a network model and exchange the network model with CGMES standard. Specifically, power flow calculation is performed in both applications and the results would be compared with PF used as a bench-mark. Therefore, some general information about how power flow calculation would be conducted on ENTSO-E test networks and the method for comparing results from different tools will be first given before looking into the actual work flow of a specific tool. However, due to the proprietary information, details about PF will not be presented in this report and only a basic

description about the used functions can be provided.

4.1 General test setup

4.1.1 Power flow and network models

In order to run a power flow, it is necessary to know the topology of the network and the initial conditions of the calculation. The later information can be obtained from SSH instance files (see 3.1.2) while the former depends on the input representation used for the calculation. As can be noticed from the previous section, there are two different network models i.e. bus-branch and node-breaker:

1) Node-breaker (NB) model

The network is modeled as various power system equipment with their terminals connected through connectivity nodes. It is a detailed representation of the network with all the switches included and their status given in the SSH file.

2) Bus-branch (BB) model

The network is modeled as power flow buses (i.e. TopologicalNodes) connected through branches (i.e. power transformers, lines). A BB model generally does not have switches. However retained switches are possible, the power flow calculation then computes the power flow through these switches

The power flow calculation is always performed on a BB network model, therefore if the BB model is used as input representation the network topology can be directly obtained from TP instance files. However, if NB model is used, the topology information can only be generated from topology processing (i.e. NB-to-BB conversion). Figure 32 illustrates the general process for performing power flow calculation based on ENTSO-E test networks for both input representations.

Figure 32 Power flow calculation using BB and NB representation

-26-

To better explain how the topology processing is done, a brief example is given. Figure 33 illustrates a detailed NB representation of a substation named Winlock from ABB 40-bus test network.

Figure 33 NB representation of Winlock substation

Take G1 as a starting point which is connected with a closed breaker, leading us to further find the connected BusbarSection and transformer T1. The first TopologicalNode is thus created. Figure 34 shows the final bus-branch model of the substation with three TopologicalNodes created in total. It can also be seen from the figure that due to the open positions of breakers 6B and 6D, the corresponding outgoing line is removed. The same rule applies with breaker 3B which leads to remove of BusbarSection B.

Figure 34 Bus-branch representation of Winlock substation

-27-

The outputs of the calculation from a NB model are, as can be seen from Figure 32, SV and TP files. Both files describe the BB model of the solved network, providing the power flow results and the final topology information of the network.

4.1.2 Power flow solution comparison method and output format

To compare the power flow results obtained from different tools, not only the voltage values of same TopologicalNodes should be checked, but also the power system elements associated with the TopologicalNodes are of interest.

However, the manual comparison is quite difficult and cumbersome due to the complicated associations between CIM objects and the split of them over different files. For example, with a known TopologicalNode, in order to find out the network elements associated with it, one should use “cim:Terminal.TopologicalNode” to find out the corresponding terminals first and then using “cim:Terminal.ConductingEquipment” to find the corresponding equipment. Additionally, several different types of instance files are usually needed to facilitate this kind of information looking up. Therefore, an automatic comparison is desired and the procedures are described as follows:

1) Step 1: Create bus-branch lists

A bus-branch list contains all the TopologicalNodes in the grid and the network elements associated with each of these nodes. The interested power flow results and some other attributes are listed together with the corresponding elements, such as “v” and “angle” for each node. An example bus-branch list can be seen as below, which represents the type 1 Microgrid described in 3.1.3. The attributes listed are not all used for this thesis, but they all helps to evaluate the power flow results obtained and worth to be explained here.

v and angle represent the solved bus voltage magnitude and voltage angle respectively

pinj and qinj represent the power residuals in the final iteration of power flow calculation, i.e. the differences between the final computed active/reactive power value with the scheduled active/reactive power value. These parameters can help to recognize the accuracy of the calculation. More information about general power flow calculation can be found in literature such as [27]

pssh and qssh are the initial active and reactive power provided in the SSH file which is an input file for power flow calculation. Similarly, psv and qsv are the P, Q values from the power flow solution i.e. in the output SV file

ploss and qloss are applicable when the corresponding element has non-zero impedance, representing the active and reactive power losses of this element

Figure 35 Screenshot of example bus-branch list

To have a better understanding of the bus-branch list, a diagram of NL grid which corresponds to the NL part of the list above is given by Figure 36. All the TopologicalNodes in the network are marked by rectangles in different colors. Taking the TopologicalNode “NL-Busbar_2” (light blue) as an

-28-

example, the power system equipment associated with it are: a load NL_Load_3, two transformers NL-TR2_1 and NL_TR2_3, two breakers NL_BREAKER_1 and B1. Comparing these devices from the diagram with the elements in the bus-branch list, it can be seen that all the associated devices are listed. Additionally in this case, due to the “Switch.retained” field of B1 is set to be true, B1 is also kept in the list.

Figure 36 Topology of NL grid with TopologicalNodes marked

To create such lists, an XSLT script is used which takes the following files as the input.

<EQ> ENTSO-E EQ instance files with Bus Name Marker </EQ>

<SSH> ENTSO-E SSH instance files modified by ABB </SSH>

<TP>exported TP instance file from NM/PF/ ENTSO-E </TP>

<SV> exported SV instance file from NM/PF/ ENTSO-E </SV>

The same EQ (from ENTSO-E) and SSH file (from NM, is a modified file of the original ENTSO-E file with some errors fixed) are always used to create any bus-branch list. Therefore, a TP and a SV file of the solved network are expected to be exported from different software thus to be used to create the bus-branch list.

2) Step 2: Compare bus-branch lists from step 1

After the bus-branch lists are created, another XSLT script is executed taking the two lists (bb1 and bb2) as the input and then generates the comparison results with similar structure and content as the figure below.

Figure 37 Screenshot of example bus-branch lists comparison result

Elements within “<ERROR_in_bb1 (2) _but_not_in_bb2 (1)>” stand for those elements that are only in bus-branch list bb1 (2) but not found in the other bus-branch list bb2 (1). Other elements

-29-

listing below are the common part of two bus-branch lists where the power flow results from different parties and the differences between them can be easily checked.

Following the above two steps, the comparison for power flow solutions from different tools can be easily conducted with the results illustrated in an easily readable manner.

4.2 Network Manager (NM)

NM is a SCADA/EMS developed by ABB. It is built on an open platform and can be turned for supervising and controlling a power system. In this project, only the functions related to CGMES data processing and power flow calculation are of interest. The basic work flow of NM is quite similar as given in Figure 32 but more complicated and is illustrated as below.

Figure 38 Basic work-flow in NM

The procedures can be briefly explained as [24]:

1) CIMXML File manager receives ZIP archives from an external location and store in the repository. The archive is unzipped and the CIMXML files are transferred to DE 400 or the online for import (indicated by star 1).

2) The EQ files made available to DE 400 are imported (indicated by star 2).

3) The EQ files imported in DE 400 are populated to the online (indicated by star 3).

4) The SSH files made available to online are imported (indicated by star 4).

5) Run power flow (indicated by star 5).

6) The power flow result is exported from online (indicated by star 6).

7) It possible to re-export the previously imported files (indicated by star 7).

8) CIMXML files created in NM can be transferred to the file repository, zipped and then exported to any external party (indicated by star 8).

In the context of this document, the most interested steps can be concluded into three main parts:

1) Import input files (i.e. steps correspond to star 1 to 4)

2) Topology processing and power flow simulation (i.e. step corresponds to star 5)

3) Export power flow result and input files (i.e. steps correspond to star 6 and 7)

Each part will be further explained in detail in the following subsections.

-30-

4.2.1 Import input files

The files imported into NM are EQ and SSH CIM XML files which are based on the NB model of ENTSO-E’s test network, providing information for equipment connectivity and initial conditions for power flow (step 1to 4 in Figure 38).

4.2.2 Topology processing and power flow simulation

After the above-mentioned files are successfully imported (i.e. steps 1-4 in Figure 38 have been done), all the data needed for power flow simulation is ready. However, since the imported files give a NB representation of the network, topology processing is performed as discussed in section 4.1.1. The figure below is a screenshot from one of NM’s interfaces, which shows the sub-steps performed in this part.

Figure 39 Screenshot of NM network monitor interface

In the context of this document, only the second and fourth blocks (from left to right) are of interest. The NMB block stands for the network model builder that builds up the BB model of the simulated network and the DPF block is where power flow is performed (step 5 in Figure 38) based on the BB network model got from NMB.

4.2.3 Export power flow result and input files

After the previous step has succeeded, a SV and a TP file of the solved network can be generated (step 6 in Figure 38) and exported as the result of power flow simulation and ready for later use in the power flow solution comparison as what is described in section 4.1.2.

Additionally, NM also provides the possibility of exporting the input files for power flow (i.e. SSH and EQ instance files) in order to make sure they were not changed by the software (step 6 and 7 in Figure 38).

The following screenshots show the file export interfaces in NM.

Figure 40 Export SV report in NM

-31-

Figure 41 Export TP report in NM

Figure 42 Export SSH report in NM

4.3 Power Factory (PF)

PF is a power system analysis tool developed by DIgSILENT GmBH. The CGMES tool of this application is used during this thesis work and the basic work flow can be illustrated as:

Figure 43 Basic work-flow in PF CGMES tool

The CIM files, either as single XML file or zipped together, can be imported into PF by first using the CIM data import function to import the data into CIM objects (step 1 in Figure 43). Then using CIM to Grid conversion function, the CIM objects are converted into internal grid model in PF (step 2 in Figure 43). With these grid models, power flow calculations can then be performed.

-32-

To export data from PF, the solved grid model should be first converted into CIM objects (step 3 in Figure 43) and then be exported as a ZIP file or XML file in conformity with CIM data structure (step 4 in Figure 43).

-33-

5 Tests and results

During the thesis, various tests were performed in PowerFactory 2016 (first release) in order to get the power flow solutions for ENTSO-E test networks and to compare them with standard results. Unfortunately, the test results obtained indicate that this version of PF cannot be used as the bench-mark for validating the power flow solutions from NM. A newer version of PF, i.e. Power Factory SP2, was received from the supplier after the main work has been completed (according to the time limit mentioned in 1.2). To ensure that the content of the thesis is up-to-date with available software release on the date of publication, all tests are conducted again with the latest version in May 2016

All the test cases performed with the results received from both versions of PF will be covered in this chapter.

5.1 Test with import CGMES data into PF

As the general process given by Figure 32 or the work flows shown in Figure 38, it is expected according to [R.3.1] in CGMES_v2.4.15[19] that the power flow calculation can be performed with only EQ and SSH files imported if the NB input representation is supported by an application. Therefore, a similar test TS1 is conducted in PF following the steps below:

5.1.1 Result from PowerFactory 2016 first release

The figure below is a screenshot of the output window from PF for this test case:

Figure 44 Screenshot of the output window from PF 2016 for TS 1

It can be noticed that in this case, PF cannot run the power flow calculation if only EQ and SSH files are imported. But it is later tested that the calculation can be performed if one includes the TP files with the data import.

5.1.2 Result from PowerFactory SP2

Similar test results are valid for this version as well. According to DIgSLIENT feedback, it is discovered that only the TP file for the boundary set is required for the power flow calculation to be correctly performed, instead of including all the TP files. The reason provided by DIgSILENT for adding the boundary TP file is that ConnectivityNodes of the boundary only have a link to their corresponding TopologyNodes, which makes the boundary EQ file not independent. Moreover, since

TS 1

1) Create a project

2) Import a ZIP file (step 1 in Figure 43), containing 3 EQ files for 2 TSO sets and the

Boundary set, 2 SSH files for the 2 TSO sets.

3) Do CIM to Grid conversion (step 2 in Figure 43)

4) Run power flow

-34-

there is no SSH file for the boundary set, previously mentions [R.3.1] in CGMES_v2.4.15 is not applicable for the boundary as well.

5.2 Tests with topology processing with CGMES data in PF

According to the user manual of PF [25], the Grid to CIM conversion (step 3 in Figure 43) is always generating a full NB representation. Therefore, to facilitate the comparison of power flow solutions, the NB-to-BB conversion needs to be done to get the power flow solution i.e. the SV and TP files in a BB representation.

More specifically, a DPL (DIgSILENT Programming Language, a built-in language in PF offering users way to manipulate internal objects) script needs to be run with the CIM archive that needs to be converted as the input, and the expected output is a BB model with breakers removed accordingly. The used function in the DPL script is [26]:

CimArchive.ConvertToBusBranch()

The detailed procedures of this test case TS2 are:


All the above procedures are successfully conducted by PF and Figure 45 illustrates a part of the generated bus-branch list of the results from PowerFactory 2016.

Figure 45 Screenshot of a part of generated bus-branch list using data from TS 2

TS 2

1) Create a project

2) Import a ZIP file (step 1 in Figure 43), containing EQ, SSH and TP files

3) Do CIM to Grid conversion (step 2 in Figure 43)

4) Run power flow with converted grid model

5) Do Grid to CIM conversion (step 3 in Figure 43) and get a result archive containing a NB model of the solved network

6) Run NB-to-BB DPL script with the archive in 5)

7) Export a ZIP file containing all the profiles from the archive in 6) (step 3 in Figure 43)

-35-

It can be seen that many breakers have remained in this bus-branch list. However, according to the original EQ files from ENTSO-E, only one breaker with name “B1” from NL has “Switch.retained=true” that should be retained.

To find out the reason for the appearance of these extra breakers, the exported EQ files from PF are checked. Figure 46 gives the screenshot for the comparison between the EQ file for NL exported from PF and that from ENTSO-E, where it can be noticed that the EQ file has been modified by PF (actually the modification is done by the “Grid to CIM conversion” step). Specifically, the “Switch.retained” field for all breakers has been changed and two breakers with “false” value have been removed from the EQ file.

Figure 46 Comparison between exported EQ file and that from ENTSO-E

If using such bus-branch list (Figure 45) and the bus-branch list for ENTSO-E’s results to generate the comparison list, the result file will be as is shown below:

-36-

Figure 47 Comparison result

It can be seen that there are 39 TopologicalNodes in PF’s results (bb2) which is much more than the 17 TopologicalNode from ENTSO-E (bb1). Actually, the amount of the total TopologicalNodes generated by PF almost equals to the number of ConnectivityNode in the network.

One possible reason for getting much more TopologicalNode could be that too many breakers are set to be remained before the NB-to-BB conversion. Therefore, another test case TS3 has been created in PowerFactory 2016.

The result of TS 3 is investigated again. However, even the breakers are removed correctly the TopologicalNodes generated by PF remain exactly the same as we got in the previous case (see Figure 47).


TS2 is performed in PowerFacotory SP2 again and it is validated that the breaker reduction problem found before is fixed in the new PF version. After running the NB-to-BB DPL script (step 6 in TS2), it is checked in PF that only two breakers remain this time. Those two breakers are: breaker B1 in NL which is set to be remained in the original XML file, and breaker BE_Breaker_3 which is selected as retained by PF. According to DIgSILENT, the reason for remaining BE_Breaker_3 is that the

TS 3

1) – 5) Same as in TS2

6) Manually modify “Switch.retained” field for all breakers as the original values given by

ENTSO-E

7) Run NB-to-BB DPL script with the archive in 6)

8) Export a ZIP file containing all the profiles from the archive in 7) (step 3 in Figure 43)

-37-

ConnectivityNode BE_TR_BUS3 which has a different phase technology (ABC-N instead of ABC) must be retained in order to keep the grounding information of the transformer.

As mentioned in 4.1.2, it is required to export the SV file and TP files for the solved network in order to continue with the load flow result comparison. However, an error occurred when exporting the boundary TP (BD_TP) file, indicating that the file cannot be exported since there are some attributes missing for the TopologicalNode in the BD_TP file. For each boundary TopologicalNode, the following attributes marked with red blocks in Figure 48 are absent.

Figure 48 Missing attributes for boundary TopologicalNode

The boundary TP file is successfully exported after manually added and filled in values for those attributes. The comparison of TopologicalNode between PowerFacoty SP2 (bb2) and ENTSO-E (bb1) is illustrated as in Figure 49.

Figure 49 Comparing TopologicalNode between ENTSO-E and PF SP2

As can be noticed from the figure, there are 18 and 17 TopologicalNodes in PF and ENTSO-E’s results respectively and 14 of them have the same value for IdentifiedObeject.name attribute and are presented as the common part in the comparison list. But it should be noted that a TopologicalNode usually contains several ConnectivityNodes thus could take the name of any ConnectivityNode it contains as the name for itself when generated after topology processing. As a result of this, it is checked that the three TopologicalNodes listed in the first sections and the last three TopologicalNodes listed in the second section of the comparison report actually corresponds to the same TopologicalNode. Specifically, BE_TR_BUS2 is the same node as BE-Busbar_1, BE-Busbar_2 is the same node as N1230991550, NL_Busbar__4 is the same node as N1230992228.

-38-

There is only one more TopologicalNode generated by PF which in named as BE_TR_BUS3. The reason for having this additional node is because that one more breaker i.e. BE_Breaker_3 is set to be retained by PF as explained above.

5.3 Power flow result comparison between PF and ENTSO-E


As discussed in 5.2.1, the power flow solution exported from this version of PF is not properly comparable with ENTSO-E’s result using the comparison method in 4.1.2.

In such case, the power flow solution might only be compared manually by first merging the extra TopologicalNodes and check if the TopologicalNodes are compliant with ENTSO-E and then manually compare the power flow solutions for each node, without taking into account the possibility of how such manual merging could influence the power flow result.


With this version of PF, topology processing is correctly performed thus the power flow result can be used to do the comparison, as long as the boundary TP file along with the two TP files for BE and NL as well as the assembled SV file are exported.

Table 2 shows the difference between the power flow solutions got from PowerFactory SP2 and the ENTSO-E results. The voltage differences for all the TopologicalNodes except for BE-Busbar_5 are less than 1% of base voltage, while for BE-Busbar_5 the voltage difference is 1.1% of the base voltage value. The angle differences for all the TopologicalNode are less than 1 degree. Therefore, it is now validated that the power flow result got using PowerFactory SP2 is sufficiently close to be

compared with ENTSO-E’s result.

Topological

Node

diff_V (kV)

diff_angle (degree)

Topological

Node

diff_V (kV)

diff_angle (degree)

BE_TR_BUS2 0.814258 0.55355 NL_TR_BUS2 0 0

BE_TR_BUS4 0.680838 0.64715 NL-Busbar_2 0.124196 0.204

BE-Busbar_2 0.568552 0.53228 NL_Busbar__4 0.106196 0.204

BE-Busbar_4 0.074049 0.65759 Border_AL11 0.769687 0.52256

BE-Busbar_5 0.2431 0.86219 Border_GY11 0.769757 0.52255

BE-Busbar_6 0 0.60082 Border_MA11 0.805575 0.54799

N1230822413 0.00005 0.20309 Border_ST23 0.368236 0.36312

N1230992195 0.722263 0.49127 Border_ST24 0.372529 0.36569

Table 2 Difference of power flow solutions from TS2 between PF SP2 and ENTSO-E

-39-

6 Conclusions

The main task of this thesis is to compare and validate the power flow results from NM using PF as a bench mark. The input used for tests is ENTSO-E test networks and the expected output is that the NM could obtain similar power flow results as the values provided by ENTSO-E, so that ABB can claim the proper implementation of CGMES with NM product.

Efforts were made to:

1) Understand IEC CIM standards (Chapter 2)

The three-layer architecture of CIM is given and each layer is described in detail from the top to the bottom. Specifically, basic knowledge about UML is provided first accompanied with detailed examples in order to explain how a power grid can be converted into CIM objects. CIM profiles are introduced providing a way of limiting the scope of CIM UML model on the first layer according to specific usages. Underlying technologies such as XML and RDF are given at the end to illustrate the real implementation of CIM model.

2) Understand CGMES and conformity assessment process and criteria (Chapter 3)

With general information about CIM provided, CGMES standard is introduced in this chapter. Some basic knowledge for understanding information exchange with CGMES such as the concept of MAS is explained first followed by the descriptions about CGMES instance file types. An example is given based on one of the ENTSO-E test networks to show how the CGMES data is organized as well as to introduce the Test Configurations. In the second part of this chapter, information related to the CGMES conformance evaluation process and criteria for passing the conformity test is provided accompanied with an example.

3) Understand general preparation for testing and tools to be used (Chapter 4)

Regardless of what application to be used, it is important to understand what data is needed to conduct a power flow calculation and how the calculation results from different tools can be compared efficiently. Such information is provided as general test setup first in this chapter. The work flows in specific tools i.e. NM and PF are then described.

4) Perform tests and analyze results (Chapter 5)

Power flow calculations are performed with ENTSO-E test configurations in two versions of PF and the results are compared with the standard values. The results from PowerFactory 2016 (first release) indicates that PF cannot generate the good results in proper bus-branch representation, thus are not able to be used as the bench mark as expected. However, with PowerFactory SP2 most of the problems are already fixed and it is validated that the power flow solution is sufficiently close to ENTSO-E’s result. Problems discovered during testing are explained in detail in the chapter.

Due to the problems with PowerFactory 2016 first release presented in the report, not all of the original goals of the thesis were met by the final outcome. Fortunately, those problems were solved in new release which is also validated by our later testing. However, we could not utilize those functionalities within the project because of time limitation. On the other hand, in-depth studies have been done to obtain both theoretical and practical knowledge necessary for completing this thesis.

-40-

Reference

[1] Sierra Energy Group, Smart grid starts with smart design, April 2010

[2] Uslar, M., Specht, M., Rohjans, S., Trefke, J., Vasquez González, J.M. The Common Information

Model CIM: IEC 61968/61970 and 62325 – A Practical Introduction to the CIM. Springer-Verlag

Berlin Heidelberg 2012

[3] Chavdar Ivanov, Role of CIM for Power System Model Exchange: Europe - ENTSO-E Experience with

CIM, Melbourne Australia, February 26, 2013

[4] ENTSO-E, CGMES Conformity Assessment Framework Version 1, 11 April, 2014

[5] https://www.entsoe.eu/major-projects/common-information-model-cim/cim-for-grid-models-

exchange/conformity-registry-archive/Pages/default.aspx

[6] Alan W. McMorran. An Introduction to IEC 61970-301 and 61968-11: The Common Information

Model. Glasgow. 2007

[7] http://cimug.ucaiug.org/Meetings/SF2010/Presentations/CIM%20University/01%20Introduction%20to

%20CIM%20October%202010.pp

[8] Nada Reinprecht, Javier Torres, Marilza Maia, IEC CIM architecture for Smart Grid to achieve

interoperability, March 2011

[9] OMG Unified Modeling Language (OMG UML) Superstructure Version 2.3

http://www.omg.org/gettingstarted/what_is_uml.htm

[10] http://www.omg.org/spec/UML/2.3/Superstructure

[11] Open Grid Systems Ltd. Common Information Model Primer Third Edition. 2015.

[12] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau, John Cowan,

Extensible Markup Language (XML) 1.1 (Second Edition), W3C Recommendation 16 August, 2006

[13] A. deVos, S.E. Widergren, J. Zhu, XML FOR CIM MODEL EXCHANGE, 2001

[14] UCTE, UCPTE-UCPTE The 50 Year Success Story- Evolution of a European Interconnected Grid, 22

April, 2011

[15] ENTSO-E, COMMON INFORMATION MODEL (CIM) – MODEL EXCHANGE PROFILE 1, 10 June,

2014

[16] Britton J P. Designing model exchange processes with CIM and 'RMA sets'[C]//Power Systems

Conference and Exposition, 2006. PSCE'06. 2006 IEEE PES. IEEE, 2006: 487-489.

[17] http://cimug.ucaiug.org/Groups/Model%20Exchange/Model%20Exchange.ppt

[18] Rafael Lopez, Jay Britton, UCTE model exchange based on IEC CIM standards, DEMSEE 2009-

International Conference on Deregulated Electricity Market Issues in South-Eastern Europe, Belgrade,

17-18 September 2009

[19] ENTSO-E, Common Grid Model Exchange Standard (CGMES) Version 2.4, 7 August, 2014

[20] ENTSO-E, MicroGridTestConfiguration Version 2 CGMES 2.4.15, 31 May, 2015

[21] ENTSO-E, Test Use Cases Version 1.0.1, 23 June, 2014

[22] ENTSO-E, Test Procedures and Conformity Categories Version 1.0.1, 23 June, 2014

[23] ENTSO-E, CGMES Conformity Assessment Framework Version 1, 11 April, 2014

[24] ABB, NM CIM Import Workflow Function Description, December, 2015

[25] DIgSILENT, PowerFactory 2016 User Manual, January, 2016

[26] DIgSILENT, PowerFactory Technical Reference Document DPL Function Reference, 20 January,

2016

[27] Hadi Saadat, Power System Analysis, third edition, 2010.

https://www.entsoe.eu/major-projects/common-information-model-cim/cim-for-grid-models-exchange/conformity-registry-archive/Pages/default.aspx

https://www.entsoe.eu/major-projects/common-information-model-cim/cim-for-grid-models-exchange/conformity-registry-archive/Pages/default.aspx

http://cimug.ucaiug.org/Meetings/SF2010/Presentations/CIM%20University/01%20Introduction%20to%20CIM%20October%202010.ppt

http://cimug.ucaiug.org/Meetings/SF2010/Presentations/CIM%20University/01%20Introduction%20to%20CIM%20October%202010.ppt

http://www.omg.org/gettingstarted/what_is_uml.htm

http://cimug.ucaiug.org/Groups/Model%20Exchange/Model%20Exchange.ppt

TRITA EE 2016:144

ISSN 1653-5146

www.kth.se