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

(1)

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 TECHNOLOGY

SCHOOL OF ELECTRICAL ENGINEERING

(2)

(3)

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.

(4)

(5)

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.

(6)

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.

(7)

(8)

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:

(11)

-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 1}st_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

(12)

-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.

(13)

-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.

(14)

-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).

(15)

-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.

(16)

-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.

(17)

-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.

(18)

-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.

(19)

-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.

(20)

-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.

(21)

-12-An XML document is collection of XML elements following certain structure. -12-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.

(22)

-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.

(23)

-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.

(24)

-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

(25)

-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.

(26)

-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

(27)

-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__4 u=102.33 % Uang=-3.49194 ° NL-Busbar_3 u=101.70 % Uang=-1.71611 ° NL-Busbar_2 u=102.33 % Uang=-3.49194 ° NL-_Busbar_1 u=102.15 % Uang=-6.36182 ° NL-Busbar_5 u=101.80 % 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 1 B1 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 Boundary NL 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_AL11 u=102.79 % Uang=-6.59595 ° XZE_ST23 u=102.50 % Uang=-5.58573 ° BE-Busbar_6 u=105.00 % Uang=-9.39998 ° BE-Busbar_5 u=104.70 % Uang=-6.66500 ° BE-Busbar_4 u=103.05 % Uang=-7.06581 ° BE-Busbar_3 u=99.70 % Uang=-8.77964 ° XZE_ST24 u=102.26 % Uang=-5.64409 ° BE-Busbar_2 u=99.94 % Uang=-7.63282 ° XWI_GY11 u=102.72 % Uang=-6.58429 ° BE-Busbar_1 u=108.68 % Uang=-6.78901 ° XKA_MA11 u=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 Mvar BE-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 Mvar P=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_BUS1 u=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 BE_TR_BUS2 u=108.68 % Uang=-6.78901 ° P=-55.963 MW Q=217.572 Mvar BE_TR_BUS3 u=105.00 % Uang=-9.39998 ° BE_Breaker_3 P=55.154 MW Q=38.268 Mvar P=-55.154 MW Q=-38.268 Mvar BE_TR_BUS4 u=99.70 % Uang=-8.77964 ° BE_Breaker_4 P=55.223 MW Q=39.209 Mvar P=-55.223 MW Q=-39.209 Mvar BE_TR_BUS5 u=105.00 % Uang=-9.39998 ° BE_Breaker_5 P=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_10 u=104.70 % Uang=-6.66500 ° P=-117.496 MW Q=-92.682 MvarP=117.496 MW Q=92.682 Mvar BE_BUSBAR_12 u=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_BUS1 u=102.33 % Uang=-3.49194 ° NL_TR_BUS2 u=101.80 % Uang=0.00000 ° NL_BREAKER_1 P=-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 N1230822396 u=102.33 % Uang=-3.49194 ° NL_BREAKER_3 P=-288.964 MW Q=69.853 Mvar P=288.964 MW Q=-69.853 Mvar N1230822413 u=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 N1230991529 u=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 N1230991550 u=99.94 % Uang=-7.63282 ° P=25.804 MW Q=2.825 Mvar CIRCB-1230991718 P=-83.052 MW Q=138.476 Mvar N1230991724 u=108.68 % Uang=-6.78901 ° P=83.052 MW Q=-138.476 Mvar CIRCB-1230991736 N1230991739 u=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 N1230992195 u=102.15 % Uang=-6.36182 ° N1230992198 u=102.15 % Uang=-6.36182 ° N1230992201 u=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 N1230992228 u=102.33 % Uang=-3.49194 ° N1230992231 u=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 N1230992288 u=99.70 % Uang=-8.77964 ° N1230992291 u=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 N1230992411 u=99.94 % Uang=-7.63282 ° N1230992414 u=99.94 % Uang=-7.63282 ° P=-31.355 MW Q=-1.200 Mvar P=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

(28)

-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.

(29)

-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.

(30)

-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

(31)

-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

(32)

-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

(33)

(34)

-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.

(35)

-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.

(36)

-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

(37)

-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

(38)

-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.

(39)

-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.