deliverable (d) no: 11.2 data management concept for the ... · pdf filedata management...

Distributed Intelligence for Cost-Effective and Reliable Distribution Network Operation

Deliverable (D) No: 11.2

Data management concept for the comprehensive smart grid data repository

Author: OFFIS Date: 18.02.2016 Version: 3.0

www.discern.eu

The research leading to these results has received funding from the European Union Seventh Framework Programme (FP7/2007-2013) under grant agreement

No. 308913.

Confidential (Y / N): N

D11.2 Data management concept for the comprehensive Smart Grid data repository

DISCERN_WP11_D11 2_160218_v3.doc

Title of the Deliverable

Data management concept for the comprehensive smart grid data repository

WP number WP title WP leader

11 Methodologies for reusing and comparing information about smart grid projects

OFFIS

Task title T11.2 Data management concept for the comprehensive smart grid data repository

Main Authors Rafael Santodomingo/ OFFIS Maike Rosinger / OFFIS Mathias Uslar / OFFIS

Project partners involved

Raúl Bachiller / IBDR Lars Nordström/ KTH Carmen Calpe/ RWE Sarah Rigby/ SSEPD Miguel García Lobo / UFD Dag Wästlund / VRD

Type (Distribution level)

PU, Public PP, Restricted to other program participants (including the Commission Services) RE, Restricted to other a group specified by the consortium (including the Commission Services) CO, Confidential, only for members of the consortium (including the Commission Services)

Status In Process In Revision Approved

Further information www.discern.eu

D11.2 Data management concept for the comprehensive smart grid data repository

DISCERN_WP11_D11 2_160218_v3.doc of 46

Executive Summary

Deliverable D11.2 “Data management concept for the comprehensive smart grid data repository”

presents the methodologies that will have to be implemented in the future smart grid dashboard

system with the aim of addressing data management issues when importing, storing, and exporting

smart grid data.

The functional use cases included in D11.1 “Functional description of the comprehensive smart grid

data repository” detailed the services that will be provided by the smart grid dashboard system. These

services can be summarised in three main objectives: reusing smart grid data, integrating smart grid

simulations, and comparing smart grid solutions. All these use cases are associated with data

management challenges. Particularly relevant are those issues directly related with the existence of

numerous and heterogeneous data formats typically used in the electricity sector for representing

smart grid data.

This deliverable D11.2 is dedicated to describing the data models that will have to be dealt with by the

dashboard system in order to perform each of the use cases and to identify the incompatibilities or

mismatches that hamper bi-directional transformations of instance data based on the previously

described data models.

For that purpose, the first part of the document gives an overview of data model transformation

technologies included in the state of the art, starting with a categorisation of possible mismatches that

can suppose a barrier for interoperability when managing heterogeneous data models and following

with commonly used methods for coping with these mismatches. The second part of the document

adopts the categorisation presented previously in the context of the smart grid dashboard system

functional use cases.

The main learnings of this study can be summarised in the following two points:

The state-of-the-art categorisation of data model mismatches as well as its adoption for detecting

and describing data formatting issues in relation to commonly utilised data models in the electricity

sector not only sets up the basis for one of the main tasks of the future comprehensive data

repository for European smart grid projects – the smart grid dashboard system – but it is also of

benefit for other studies beyond DISCERN aimed at improving interoperability within the scope of

smart grids, since the identification and classification of the problems that need to resolved is the

first necessary step toward the solution of these problems.

This document highlights the existence of a variety of data formats for representing smart grid

data and details the complexity of the problems caused by the different terminologies, structures,

and even modelling languages widely adopted in this domain data. This document shows

therefore the benefits of adopting international standard data models and advocates that utilities

carefully study the available options for describing smart grid data when designing their systems

so as to avoid adding complex interoperability mismatches. Moreover, standardisation bodies

should also make an effort to avoid the existence of incompatible standard data models, as it

happens for example with the two main standard data models for representing network models:

the IEC 61968/61970 CIM and the IEC 61850 SCL. Advance data modelling technologies, such as

those proposed by (Guizzardi 2006) are promising research directions toward more efficient

development and maintenance of compatible standard data models for the electricity sector.



Table of Contents

Executive Summary .................................................................................................................................................................... 5 Table of Contents ........................................................................................................................................................................ 6 List of Figures ............................................................................................................................................................................. 7 List of Tables............................................................................................................................................................................... 8 Abbreviations and Acronyms ....................................................................................................................................................... 9 1. Introduction ..................................................................................................................................................................... 11

1.1. Scope of the document .......................................................................................................................................... 11 1.2. Structure of the document ...................................................................................................................................... 11

2. An Overview of Data Model Transformation Technologies ............................................................................................... 12 2.1. Metadata ............................................................................................................................................................... 12 2.2. Languages for defining metadata models............................................................................................................... 14 2.3. Metadata interoperability ........................................................................................................................................ 15 2.4. Types of mismatches hindering semi-automatic data model transformations ......................................................... 16

2.4.1. Mismatches at M2 and M1 ................................................................................................................................. 18 2.4.2. Mismatches at M0 ............................................................................................................................................. 20

2.5. Data model transformation techniques ................................................................................................................... 20 2.5.1. Model agreement .............................................................................................................................................. 20 2.5.2. Meta-model agreement ..................................................................................................................................... 21 2.5.3. Model reconciliation ........................................................................................................................................... 21

3. Data management requirements of the smart grid dashboard system ............................................................................. 22 3.1.1. Reuse grid data ................................................................................................................................................. 22 3.1.2. Reuse ICT data ................................................................................................................................................. 25 3.1.3. Access data about communication protocols and standard data models ............................................................ 26 3.1.4. Access technical reports on smart grid cyber security ........................................................................................ 26 3.1.5. Reuse technical functions .................................................................................................................................. 27 3.1.6. Reuse Key Performance Indicators (KPIs) ......................................................................................................... 27

3.2. Integrate smart grid simulations ............................................................................................................................. 27 3.3. Compare smart grid solutions ................................................................................................................................ 28

3.3.1. Reference smart grid data ................................................................................................................................. 28 3.3.2. Calculate Key Performance Indicators (KPIs) .................................................................................................... 28

4. Conclusions ..................................................................................................................................................................... 29 5. References ...................................................................................................................................................................... 30

5.1. Project documents ................................................................................................................................................. 30 5.2. External documents ............................................................................................................................................... 30

6. Revisions ......................................................................................................................................................................... 32 6.1. Track changes ....................................................................................................................................................... 32

Annex A. Data models used by the smart grid dashboard system ............................................................................................. 33



List of Figures

FIGURE 2-1. METADATA ELEMENTS AND CONTENT VALUES......................................................... 12

FIGURE 2-2. MOF ABSTRACTION LEVELS AND METADATA BUILDING BLOCKS (FROM (HASLHOFER,

KLAS 2010)) ................................................................................................................... 13

FIGURE 2-3. INTEROPERABILITY LEVELS (MODIFIED FROM (SGCG 2011)) .................................. 15

FIGURE 2-4. TYPES OF MISMATCHES IMPEDING METADATA INTEROPERABILITY ............................ 16

FIGURE 2-5. METADATA MODEL A FOR REPRESENTING CONDUCTING EQUIPMENT IN ELECTRIC

FACILITIES ...................................................................................................................... 17

FIGURE 2-6. METADATA MODEL B FOR REPRESENTING CONDUCTING EQUIPMENT IN ELECTRIC

FACILITIES ...................................................................................................................... 18

FIGURE 3-1. NAMING MISMATCH BETWEEN UML AND XSD ........................................................ 22

FIGURE 3-2. FLEXIBILITY MISMATCH BETWEEN CIM AND SCL (MODIFIED FROM (PREISS, KOSTIC

2006)) ........................................................................................................................... 24

FIGURE A-1. IEC 61970 PACKAGES ......................................................................................... 33



FIGURE A-4. EXTRACT OF CIM/XML FILE ................................................................................. 36

FIGURE A-5. FRAGMENT OF A CIM/XSD FILE ........................................................................... 37

FIGURE A-6. RELATIONSHIP OF CIM/SVG AND CIM/XML (FROM IEC 61970-453) ..................... 38

FIGURE A-7. BASIC CONCEPTS OF THE LN MODEL (FROM (SUCIC, MARTINIC & FRANCESCONI

2011)) ........................................................................................................................... 40

FIGURE A-8. FRAGMENT OF THE UML REPRESENTATION OF THE LN MODEL ............................... 42

FIGURE A-9. OVERVIEW OF SCL MODEL ................................................................................... 43

FIGURE A-10. FRAGMENT OF AN SCL FILE ............................................................................... 44

FIGURE A-11. EXTRACT OF SGAM UML META-MODEL (ALIGNED WITH IEC 62559-3 META-MODEL)46



List of Tables

TABLE 1 ACRONYMS .................................................................................................................. 9

TABLE 2-1. WIDELY-USED LANGUAGES FOR DESCRIBING METADATA MODELS ............................. 14

TABLE A-1. CSWI CLASS (DEFINED IN IEC 61850-7-4) ............................................................. 41

TABLE A-2. FRAGMENT OF THE DEFINITION OF DPC CLASS (FROM IEC 61850-7-3) .................... 41



Abbreviations and Acronyms

Table 1 Acronyms

ACS Access data about communication protocols and standard data models

ATS Access technical reports on smart grid cyber security

CBR Circuit Breaker

CDF Common Data Format

CEN European Committee for Standardisation

CENELEC European Committee for Electrotechnical Standardisation

CKP Calculate Key Performance Indicators

CIM Common Information Model

D Deliverable

DMS Data Management System

DSO Distribution System Operator

EEGI European Electricity Grid Initiative

EMS Energy Management System

ETSI European Telecommunications Standards Institute

IEC International Electrotechnical Commission

IED Intelligent Electronical Device

IOP Tool Interoperability Tool

ISS Integrate smart grid simulations

JRC Joint Research Centre

KPI Key Performance Indicator

MOF Meta Object Facility

MS Microsoft

NIST National Institute of Standards and Technology

ODM Open Data Model

OWL Web Ontology Language

OWL-DL Web Ontology Language Description Logic

RCS Reuse data about communication protocols and standard data models

RDFS Resource Description Framework Schema

RGD Reuse Grid Data

RID Reuse ICT data

RKP Reuse Key Performance Indicators

RSG Reference smart grid data

RTF Reuse technical functions

RTS Reuse technical reports on smart grid cyber security

RTU Remote Terminal Unit

SCADA Supervisory Control and Data Acquisition

SGAM Smart Grid Architecture Model

SGCG Smart Grid Coordination Group

T Task



TC Technical Committee

UCMR Use Case Management Repository

UCTE Union for the Co-ordination of Transmission of Electricity

UML Unified Modelling Language

WG Working Group

WP Work Package

XML eXtensible Markup Language

XSD XML Schema Definition



1. Introduction

1.1. Scope of the document

Deliverable D11.2 is the output of task T11.2 “Data management concept for the comprehensive smart

grid data repository” within the DISCERN work package WP11 “Methodologies for reusing and

comparing information about smart grid projects”. WP11 will set the basis for the development of a

repository – the smart grid dashboard system. This dashboard allows storing data that is gathered in

Research and Development (R&D) smart grid projects on the European level in a uniform way and

appropriate granularity. It will serve as the foundations for a comprehensive smart grid data repository

for and from European R&D projects in a large scale.

The study carried out in D11.2 addresses the data management issues that will have to be dealt with

by the smart grid dashboard system in order to realise the functional use cases described in [D11.1].

Therefore, D11.2 is aimed at providing key inputs with regard to one of the main tasks of the

dashboard system, namely to manage and make bi-directional transformations between the most

widely-used data formats for representing valuable smart grid data.

1.2. Structure of the document

The document comprises the following main sections:

Section 1 introduces the document.

Section 2 classifies and gives an overview of the data model transformation issues that may occur in

information systems, and presents state-of-the-art technologies typically utilised so as to overcome

such issues in an automated manner.

Section 3 details the actual data model management requirements of the smart grid dashboard

system based on the use cases defined in [D11.1], focusing on data transformation mismatches

according to the classification given in the previous section.

Finally, section 4 concludes this report.

Annex A provides detailed descriptions of the most relevant data models that will have to be managed

by the smart grid dashboard system.



2. An Overview of Data Model Transformation Technologies

This section introduces the fundamentals about metadata interoperability and data model

transformation technologies.

Firstly, sub-section 2.1 defines the term of metadata and describes its needed building blocks

following a model perspective. Among such building blocks, metadata models play a major role in

metadata interoperability, because they define the semantics of metadata. For this reason, sub-

section 2.2 describes and compares widely-used languages for defining metadata models. These

languages are XSD, UML, RDFS and OWL. Sub-section 2.3 defines the concept of metadata

interoperability. Finally, sub-section 2.4 categorises the types of mismatches hindering interoperability

between two systems based on different metadata models, and sub-section 2.5 summarises the main

techniques commonly used to overcome metadata interoperability mismatches.

2.1. Metadata

There are numerous definitions of the term metadata in the state of the art. The definition utilised in

DISCERN is the one provided by Haslhofer and Klas in (Haslhofer, Klas 2010): “Metadata is machine

processable data that describes resources, digital or non-digital”. In this context, resources, also

referred to as information objects, stand for anything that can be addressed or manipulated by

humans or systems as discrete entities (Gill et al. 2008). Metadata is therefore used for describing any

entity in machine-tractable form. This facilitates the exchange of information between applications in

order to manage information systems.

Metadata has elements which refer to the different types of entities represented in the metadata, and

content values, which specify the concrete values of the elements in a particular case. For instance,

the XML document and the table shown in Figure 2-1 are fragments of metadata describing two

switches of an electric facility. In the case of the XML document, the metadata elements are

represented with tags (e.g. <switch>) and in the case of the table they are represented as the titles

(fields) of the columns. Regarding the content values, the XML document includes them between the

tags, whereas in the table they are shown in the subsequent rows of the fields.

Figure 2-1. Metadata elements and content values



In the following the components (or building blocks) of metadata are identified by following a model

perspective (Haslhofer, Klas 2010). Figure 2-2 shows the abstraction levels according to the Meta

Object Facility (MOF) defined by the Object Management Group (OMG)1, and associates each level

with its corresponding metadata building block.

Figure 2-2. MOF abstraction levels and metadata building blocks (from (Haslhofer, Klas 2010))

Level M1 refers to metadata models, also known as metadata schemes. Metadata models define the

meaning of metadata elements. Different types of metadata models exist depending on their semantic

capabilities, i.e. depending on their ability to formally define and relate metadata elements. The main

types of metadata models according to the categorisations provided in the state of the art

((McGuinness 2003), (Gómez-Pérez, Fernandez-Lopez & Corcho 2004) and (Arranz 2006)) are briefly

described below:

Controlled vocabularies are finite sets of terms and words to describe a domain.

Glossaries are controlled vocabularies including the term definitions using a natural language. The

same as controlled vocabularies, glossaries do not define a structure that relates the terms.

Taxonomies organise the terms in hierarchical structures by establishing derivation relationships

between them. This means that taxonomies represent the fact that a more specific term (e.g.

switch) derives from a more general term (e.g. conducting equipment).

Conceptual models define terms as concepts (classes) with properties, and even with rules

establishing constraints to their properties. In the hierarchical or derivation relationships (also

known as subsumption relationships) between two classes, the most general class is the parent

class and the most specific class is the son class. The properties and constraints of the parent

class are inherited by the son class. Moreover, the conceptual models can include relationships

different to subsumption relationships.

Ontologies. The most accepted definition of ontology in Computer Science is the one provided by

1 http://www.omg.org/spec/MOF/



Gruber in (Gruber 1993): “An ontology is an explicit specification of a conceptualisation”. Applying

this definition, ontologies can be seen as equivalent metadata models to conceptual models.

However, ontologies have special characteristics that differentiate them from common conceptual

models. Originally, ontologies were created in Artificial Intelligence (AI) for generating reusable

knowledge base components for the intelligent systems (Gómez-Pérez, Fernandez-Lopez &

Corcho 2004). Therefore, unlike the conceptual models, ontologies are thought to be reused.

Furthermore, they represent domain knowledge in a machine-tractable form. Hence, they define

logic theories that provide a mathematical model allowing the reasoning over the knowledge

defined in the ontology.

Metadata instances are included at level M0. They express content values for a specific context by

using metadata elements defined in metadata models (M1).

Level M2 belongs to the metadata meta-models, which determine the modelling languages (also

known as schema definition languages) utilised for describing the models.

Lastly, level M3 is identified with the most abstract metadata building block, the meta-meta-models.

Meta-meta-models define the constructors (or primitives) utilised in the modelling languages. When

the language used in the meta-meta-model to define the constructors is the modelling language itself,

then, such language is said to be reflexive.

2.2. Languages for defining metadata models

Most of the languages for defining metadata models (or modelling languages) utilised in DISCERN

follow the object-oriented philosophy. For that reason, before describing the modelling languages,

some concepts are briefly introduced in order to facilitate the understanding of such philosophy.

In object-oriented models, classes are sets of objects with some common characteristics. These

characteristics are defined with properties, which can be object properties (or relationships), or data

properties (or attributes). Object properties relate two classes, whereas data properties connect

classes to data types, which define types of content values. The domain of a property is the source

class of the property, and the range is the class or data type determining the type of the target

instances or content values of the property. Finally, individuals (or instances) are the objects belonging

to a class.

Table 2-1. Widely-used languages for describing metadata models

Expressiveness Machine-tractability Human-friendly

XSD

Tree structures: controlled vocabularies and taxonomies

XML parsers available on the Web (only validation)

XML tools, such as Altova XML Spy, provide non-standard graphical representations for visualizing and editing XSD schemas

UML Object-oriented conceptual models

XMI serialisation allows UML diagrams to be expressed in machine-tractable languages

UML defines a standard graphical representation that enables humans to interpret and edit the models

RDFS Taxonomies and conceptual models

RDFS defines inference services that can be performed by available RDFS reasoners

There is a node-arc diagram representation defined in RDFS. However, RDFS is more focused on machine-tractability



Expressiveness Machine-tractability Human-friendly

OWL

Ontologies including logic correspondences, such as equivalences and intersections

OWL defines inference services that can be performed by available OWL reasoners. Furthermore, OWL-DL and OWL-Lite follow the Description Logics formalism, which guarantees the completeness and soundness of the inferences

Ontology editors, such as Protégé provide non-standard graphical representations for visualizing and editing OWL ontologies

The modelling languages utilised in DISCERN are: XSD, UML, RDFS and OWL. Table 2-1 provides a

brief comparison between these languages attending to three parameters: expressiveness (or

semantic capabilities), machine-tractability, and human-friendly. The first parameter (expressiveness)

refers to the ability of the constructors of the modelling language to represent domain knowledge. The

second parameter (machine-tractability) indicates to what extent the language can be processed by

general tools in order to carry out reasoning (or inference) services over the knowledge defined in the

metadata model. The third parameter (human-friendly) establishes if the language represents

metadata models in a way that can be easily understood, designed and edited by humans.

2.3. Metadata interoperability

The Institute of Electrical and Electronics Engineers (IEEE) defines the term interoperability as “the

ability of two or more systems or components to exchange information and to use the information that

has been exchanged” (IEEE Std 610 1991). The International Electrotechnical Commission (IEC) re-

defines this basic definition indicating that the systems (or devices) that interoperate can be from

different developers, and that the objective for exchanging information is co-operating on some task.

Hence, the standard IEC 61850 defines interoperability as “the ability of two or more devices from the

same vendor, or different vendors, to exchange information and use that information for correct co-

operation” (IEC 61850-1).

The definitions provided above refer to the general concept of interoperability. However, the

interoperability comprises several levels. Consequently, the European joint working group on

standards for the smart grid classifies such levels as five interoperability classes (SGCG 2011) (Figure

2-3).

Figure 2-3. Interoperability Levels (modified from (SGCG 2011))

The two lowest interoperability classes (physical interface and communication protocols) refer to

technical aspects of the interoperability, such as the physical connectors or the communication

protocols used to exchange data. Meanwhile, the two highest interoperability classes (function and



business) are focused on functional and strategic aspects of the business procedures that need to be

performed in co-operation.

According to the definition provided in (Haslhofer, Klas 2010), metadata interoperability is the

“qualitative property of metadata information objects that enables systems and applications to work

with or use these objects across system boundaries”. With this definition, Haslhofer and Klas mean

that metadata interoperability is focused on the common understanding of the syntax and semantics of

metadata. As discussed, syntax and semantics of metadata are defined in metadata models,

sometimes denominated in the literature as information models. Therefore, metadata interoperability

corresponds to the intermediate interoperability level of Figure 2-3.

2.4. Types of mismatches hindering semi-automatic data model

transformations

Typically, in information systems, agents based on heterogeneous metadata models and meta-models

have to interact with each other. This leads to mismatches (also known as incompatibilities, or

heterogeneities) impeding metadata interoperability. Several types of mismatches have been identified

by contributions in the Ontology Matching field (Euzenat, Shvaiko 2007), (Benerecetti, Bouquet &

Ghidini 2001), (Visser et al. 1999) and the Metadata Interoperability field (Haslhofer, Klas 2010).

Figure 2-4 considers such contributions to propose a categorisation of the mismatches that can

appear between two agents or systems.

Figure 2-4. Types of mismatches impeding metadata interoperability

The proposed categorisation in this report differentiates the types of mismatches by attending to the

abstraction level in which they occur (M0, M1 or M2). Moreover, it determines whether the type of

mismatch is structural, i.e. it is caused by structural problems in the model or meta-model, or

semantic, i.e. it stands for conflicts in the meaning of the metadata elements and content values.

In order to facilitate the description of the types of mismatches included in the categorisation, the

following represents two metadata models – hereinafter referred to as model A and model B (Figure

2-3) .

Metadata model A is shown in Figure 2-5. It is worth noting that the figure does not use any

standardised notation for representing metadata models. It simply defines a node-arc diagram for

facilitating the comprehension of the metadata model defined in the example.



Figure 2-5. Metadata model A for representing conducting equipment in electric facilities

This example model is based on the standard metadata models commonly used in smart grids. In

particular, the metadata model in the example focuses on the representation of conducting equipment

in electric facilities. The class ConductingEquipment represents any piece of conducting equipment

and has three attributes: id, which identifies the instances of the class, name, which represents the

name of the conducting equipment, and voltage_KV, which determines the nominal voltage of the

conducting equipment (in kilovolts). ConductingEquipment is associated to the Terminal class with

the object property hasTerminals, which represents the terminals of a piece of conducting

equipment. The terminals are used to physically connect the pieces of conducting equipment in the

electric facility. Thus, the class Terminal is associated to ConnectivityNode with the object property

connecedTo, which establishes that terminals have to be connected at least to one connectivity node

within the electric facility. The class ConnectivityNode has three attributes: id, name and ground.

The last one establishes whether or not the connectivity node is grounded. Two classes derive from

ConnectivityNode: PhysicalNode and TopologicalNode. The first represents physical

connectivity nodes that actually exist in the electric facility. The second represents virtual nodes that

are useful for power flow analysis. A virtual node comprises a set of physical nodes that are connected

by closed switches.

Switches are represented in the model with the class Switch, which derives from

ConductingEquipment and includes the data property normalOpen. Such data property indicates

if the switch is normally open (true) or not (false). Three types of switches are defined in the metadata

model with the classes LoadBreakSwitch, Breaker and Disconnector. In addition, an instance

of LoadBreakSwitch is included in Figure 2-5. This instance represents a load-break switch that is

normally open, that is identified with the string http://www.discern.eu/example#elementQA1, and that

is named E1Q1QA1. Finally, the metadata model includes three additional classes: SwitchNO,

NormalOpenEquipment, and ProtectedSwitch. The class SwitchNO is defined as the



intersection of the class Switch and the class NormalOpenEquipment, which represents all the

instances taking the value true in normalOpen. Meanwhile, the class ProtectedSwitch is the

union of the classes LoadBreakSwitch and Breaker. This means that all the instances of

ProtectedSwitch belong to one of these two classes (LoadBreadSwitch or Breaker), and all

the instances of such classes belong to ProtectedSwitch.

Metadata model B organises the information about electric facilities in a different way from the

organisation utilised in the metadata model A. Figure 2-6 shows the representation of model B using

the same node-arc form that the one used in Figure 2-5.

Figure 2-6. Metadata model B for representing conducting equipment in electric facilities

Let us suppose that a system based on model A has to interoperate with a system based on model B.

In addition, let us suppose that model A is described in OWL-DL and that model B is described in

XSD. By using this example, sub-sections 2.4.1 and 2.2.2 describe the types of mismatches included

in the categorisation proposed in Figure 2-4.

2.4.1. Mismatches at M2 and M1

At levels M2 and M1 there can be both structural and semantic mismatches. The first ones are

described in sub-section 2.4.1.1, whereas the second ones are described in sub-section 2.4.1.2. In

such descriptions, the term model will be utilised for both the metadata models at M1, and the

metadata meta-models at M2.

2.4.1.1 Structural mismatches

As stated previously, structural mismatches stand for the structural properties of the models. The

types of structural mismatches are described below:

Naming mismatches occur when the same real entity is represented in two models with two

elements that have different names. In model A, pieces of conducting equipment are represented

with the class ConductingEquipment, whereas in model B they are represented with the class



CEquipment. At M2, OWL-DL (utilised in model A) and XSD (utilised in model B) use different

constructors for expressing the same concepts. For instance, classes are represented in OWL-DL

with owl:Class and in XSD with xs:complexType.

Multilateral correspondences appear when an element of a model is represented in the other

model with multiple elements. In model A, the names of pieces of conducting equipment are

expressed with one element (attribute name). On the contrary, in model B, these are represented

with the concatenation of two elements (attributes prefix and local-name).

Meta-level discrepancies occur when the same real entity is represented differently in two

models, i.e. using different types of metadata elements. For instance, in model A, the relationships

between pieces of conducting equipment and terminals are represented with an object property

(hasTerminals). However, in model B, such relationships are represented with an association

by reference involving the attribute terminal of the class CEquipment and the attribute id of the

class Terminal.

Identification mismatches are due to the different identification mechanisms utilised in two

models. The pieces of conducting equipment in model B are identified by their properties (local-

name, prefix, hasVoltage). On the contrary, in model A there is an attribute called id that

identifies each piece of conducting equipment with a single string.

2.4.1.2 Semantic mismatches

Semantic mismatches exist due to the conflicts between the models regarding the meaning of the

model elements and the meaning of the content values. The different types of semantic mismatches

appearing at M1 and M2 are described in the following:

Granularity mismatches occur when two models describe the same entity from the same

perspective, but at different levels of detail. For instance, model A, unlike model B, defines classes

for representing different types of switches: LoadBreakSwitch, Breaker and Disconnector.

Therefore, in this case the information about the specific type of switch will be lost in the

interactions from A to B. This type of mismatch can also appear at M2. Thus, although it does not

apply in the example, in XSD, classes can be represented not only with xs:complexType, but also

with xs:group and xs:attributeGroup. However, in OWL such concepts are all represented with the

owl:Class constructor.

Perspective mismatches occur when two models describe the same entity at the same level of

detail, but from different perspectives. In model A, two types of connectivity nodes are defined:

physical nodes and topological nodes. On the contrary, model B classifies the connectivity nodes

following a different perspective. Hence, it focuses on the type of electric elements utilised to

connect the pieces of conducting equipment: bus bar sections, or junctions. Therefore, in this

case, there will be conflict situations in the translations in both directions. Thereby, from A to B, it

will be necessary to decide if the connectivity node is a bus bar section or a junction, and from B

to A, it will be necessary to decide if the connectivity node is a physical node or a topological

node.

Coverage mismatches occur when two models describe different, possibly overlapping, regions

of a domain. This means that these mismatches stand for the fact that one model cannot

represent an entity that can be represented in the other model. For instance, model A, unlike

model B, represents the name of the connectivity nodes with the attribute name. At level M2, there

are also concepts that can be represented in OWL but not in XSD, such as the value restrictions

expressed with the constructor owl:someValuesFrom.



Flexibility mismatches only appear at M1 and occur when the models contain optional elements.

The conflict situations in this type of mismatch appear when an optional element is not included in

the instance file of the source model and such element is mandatory in the target model. For

example, in model B, the attribute normalOpen is mandatory for all the instances of the class

Switch. However, such attribute is optional in model A. Therefore, in a translation from A to B,

the information about the attribute normalOpen may not be included in the source instance file.

2.4.2. Mismatches at M0

In addition to the mismatches at levels M1 and M2, there may be mismatches at instance level, i.e. at

M0. Such mismatches have nothing to do with structural problems in the models, but with the meaning

of the content values. There are two types of mismatches at M0:

Scalability/Units mismatches occur when different scaling systems are used in two models to

measure the same content values. For instance, in model A, the nominal voltage associated to a

piece of conducting equipment is always represented in kilovolts with the attribute voltage_KV.

Conversely, in model B, nominal voltages can be represented with different units determined with

the attribute unit. In that way, if the unit utilised in model B is different from kilovolts, there will be

a conflict situation during the transformations at instance level.

Datatype mismatches occur when different data types are used in two models for representing

the same content values. The value of the nominal voltages in model A is represented with an

integer, whereas in model B they are represented with a float. Therefore, the information about the

decimals of the nominal voltages will be lost in the transformations from B to A.

2.5. Data model transformation techniques

Three basic techniques are identified in the literature for resolving the mismatches described in

section 2.4 in order to achieve metadata interoperability (Haslhofer, Klas 2010). These techniques are:

model agreement, meta-model agreement and model reconciliation.

2.5.1. Model agreement

The model agreement proposes the standardisation to overcome the mismatches among systems that

have to interoperate. The standardisation is carried out by accredited institutions, also known as

standardisation bodies like the IEC. Hence, following the model agreement approach, these

institutions define: standard modelling languages to avoid mismatches at M2, standard metadata

models to avoid mismatches at M1, and even standard profiles to avoid mismatches at M0.

However, in practise, this kind of standardisation is not always sufficient in itself. Particularly difficult is

the definition of standard metadata models that are valid for all the agents having to interoperate in a

domain (Wache 2003), (Halevy et al. 2005). Thereby, O’Leary applies in (O'Leary 1997) the

impossibility theorem of Arrow (Arrow 1963) to the ontologies and asserts that “no ontology can be

maximum for all individuals and the group, i.e. some individuals or the group will lose when an

ontology is adopted over some other ontology”. Therefore, it is mandatory to find alternative solutions

to the definition of a single standard ontology (or metadata model) for the domain. Such solutions must

be able to achieve metadata interoperability among agents based on heterogeneous metadata

models.



2.5.2. Meta-model agreement

Given the existing difficulties to achieve model agreement, quite often, the standardisation bodies do

not agree on a model, but in a meta-model. At M2, the meta-model agreement means that the

standardisation body, not being able to standardise a modelling language for its domain, tries to find

an agreement in a common meta-meta-model for all the modelling languages utilised in such domain.

MOF defines the level M3 to create elements that define the primitives of the modelling languages. If

all the modelling languages utilised in a domain are instances of the same meta-meta-model, the

number of mismatches between such languages is significantly reduced.

At M1 the meta-model agreement implies that the standardisation body does not define a standard

metadata model for all the agents. On the contrary, it standardises a global conceptual model, which is

a similar knowledge representation to the upper ontologies used in Ontological Engineering (Gómez-

Pérez, Fernandez-Lopez & Corcho 2004). Such global conceptual model defines the basic concepts

common to all the agents of the domain. From the global conceptual model, new models (profiles)

have to be defined including additional constraints for a specific context or application within the

domain. In that way, although the systems which have to interact are not based on the same standard

metadata model, the mismatches between their metadata models are reduced, because such models

derive from the same global conceptual model.

The meta-model agreement is a technique commonly used by the standardisation bodies of the smart

grids. Thus, the CIM is defined as a global conceptual model for the management of electric systems.

From the CIM, different standard profiles are defined for specific applications such as network

operation, metering, or asset management.

2.5.3. Model reconciliation

When it is not possible to achieve a model agreement or a meta-model agreement for all the systems

having to interact in the domain, it is mandatory to employ model reconciliation techniques to achieve

metadata interoperability. Model reconciliation techniques are aimed at finding and processing the

correspondences between heterogeneous metadata. Given that there are heterogeneities at M2, M1

and M0, there must be model reconciliation techniques for each one of these abstraction levels.

At M2, model reconciliation techniques are called language mapping techniques and are focused on

the transformations between different modelling languages. Section 5.5 describes the language

mapping techniques utilised in this work. At M1, model reconciliation techniques are aimed at finding

and expressing the semantic correspondences (also called alignments) between heterogeneous

metadata models. Such techniques are commonly known as model mapping, or ontology matching

(Euzenat, Shvaiko 2007). At M0, model reconciliation techniques (known as instance transformation

techniques) are used to process the correspondences generated at M1 in order to translate instance

level metadata between two heterogeneous metadata models.

Finally, it is worth noting that model reconciliation techniques can also be required in case of model

agreement or meta-model agreement. Hence, even when a standard metadata model is defined (i.e.,

model agreement at M1), this model may not be stationary (O'Leary 1997). Therefore, there may be

mismatches between different versions of the standard metadata model. In such cases, model

reconciliation techniques can facilitate the interactions between systems based of different versions of

the model. Meanwhile, when a global conceptual model is defined (i.e. meta-model agreement at M1),

it may occur that the different models (profiles) derived from it includes extensions that result in

mismatches between the systems. Again, model reconciliation techniques can be then utilised to

resolve such mismatches.



3. Data management requirements of the smart grid

dashboard system

This section summarises the data management issues of each of the use cases developed in [D11.1]

by identifying the most widely-adopted data models for realising the functions of the smart grid

dashboard system and classifying the types of mismatches hindering interoperability within the scope

of the use case.

3.1.1. Reuse grid data

RGD_1: Reuse network models

The smart grid dashboard system shall be able to import and export electricity network models in

formats typically used in the electricity sector [D11.1]. The main data models for network model

exchange as identified in the use case are:

IEC 61968/61970 Common Information Model (CIM) – typically in RDF serialisation

IEC 61850 Substation Configuration Language (SCL) – typically in XML serialisation

Mismatches at M2

Whereas the CIM model is described in UML, the SCL model (although it includes some UML

fragments) is standardised in XSD. The following describes the types of mismatches between UML

and XSD modelling languages that were detected in this work.

Naming mismatches. There are several constructors in UML and XSD that represent the same

modelling concept, but have different name. For instance, UML classes are represented in XSD

with the xs:complexType constructor. Another example of naming mismatch between UML and

XSD is shown in Figure 3-1. As can be seen, the hierarchical relationships (or derivations) in UML

are represented in XSD with the xs:extension constructor.

Figure 3-1. Naming mismatch between UML and XSD

Granularity mismatches. Two granularity mismatches were found at M2 level between UML and

XSD. Firstly, in UML, object properties can be represented as associations, aggregations or

compositions, whereas in XSD they are all represented with the xs:element constructor.

Secondly, in XSD sets of instances can be represented with xs:complexType, xs:group and

xs:attributeGroup, whereas in UML they are all represented as classes.



Coverage mismatches. There are modelling concepts that can be represented in one modelling

language, but not in the other. For instance, XSD constructors xs:sequence and xs:choice

cannot be represented with UML constructors.

Mismatches at M1

The classification of incompatibilities between CIM and SCL detailed in (Preiss, Kostic 2006) was only

focused on the metadata model level, i.e. on M1. The following details the types of mismatches that

were identified at M1 in this work between CIM and SCL by following the classification defined in

section 2.2.

Naming mismatches. In general, all the equivalent concepts defined in both metadata models are

represented with different names in CIM and SCL. For example, substations are represented in

SCL as instances of the class scl:tSubstation and in CIM as instances of cim:Substation. A

less evident case of naming mismatch between CIM and SCL is detailed as follows. In SCL,

communication networks of automation systems are represented with instances of the class

scl:tSubnetwork, whereas in CIM these are represented with instances of the equivalent

cim:CommunicationLink class.

Multilateral correspondences. In CIM, pieces of conducting equipment are represented as

instances of classes derived from the cim:ConductingEquipment class. However, in SCL,

these are represented as instances of the scl:tConductingEquipment class and the type of

conducting equipment is determined with the enumerated value of the attribute scl:type. For

example, in CIM, a circuit breaker is represented with a single entity (an instance of the

cim:Breaker class) and in SCL, it is represented with the combination of two entities: an

instance of the scl:tConductingEquipment class and the enumerated value CBR in the

attribute scl:type.

Meta-level discrepancies. The property cim:Terminal.ConnectivityNode associates a

terminal to a connectivity node in CIM. This relationship cannot be directly expressed in SCL.

Nevertheless, the instances of scl:tTerminal and scl:tConnectivityNode can be

associated by reference. Thus, if the value of the attribute scl:connectivityNode in a terminal

is the same as the value of the attribute scl:pathName in a connectivity node, then the terminal

is connected to the connectivity node.

Identification mismatches. SCL instances are identified by their attributes, whereas CIM instances

are identified using an URI identifier. In CIM/XML serialisations such identifiers are assigned to the

value of the attributes rdf:ID, and in CIM/XSD serialisations they are assigned to the value of

the attributes cim:mRID. These identification mismatches difficult the recovering of lost

information in bi-directional translations between CIM and SCL models.

Granularity mismatches. In SCL, disconnectors are represented as instances of the

scl:tConductingEquipment class with value DIS in the attribute scl:type. Nonetheless, in

CIM, disconnectors be represented with three different classes cim:Disconnector,

cim:GroundDisconnector and cim:LoadBreakSwitch. In that way, there will be conflict

situations during the translations from SCL to CIM, because the same instance in SCL can be

represented with three different classes in CIM.

Perspective mismatches. In CIM, lines are distinguished attending to the type of current,

cim:ACLineSegment and cim:DCLineSegment, whereas SCL differentiates two types of lines

depending on its isolation, LIN (without isolation) and GIL (with gas isolation). Therefore, in this

case there will be conflict situations in the translations between SCL and CIM in both directions.



Coverage mismatches. There are concepts represented in CIM that are not included in SCL, and

vice versa. For example, instances of the CIM class cim:BusbarSection cannot be

represented in SCL. Thus, this information will be lost in the translations from CIM to SCL.

Flexibility mismatches. In CIM, pieces of conducting equipment can belong directly to a voltage

level or to a substation. This means that instances of the class cim:ConductingEquipment can

be directly associated to an instance of cim:VoltageLevel or cim:Substation without including

a bay (instance of cim:Bay) in such equipment containers. However, as shown in Figure 3-2,

these associations cannot be represented in SCL, because instances of

scl:tConductingEquipment must be contained in an instance of scl:tBay within a voltage

level (instance of scl:tVotlage), which, in turn, must belong to an instance of

scl:tSubstation. In (Preiss, Kostic 2006) this mismatch was classified as an incompatibility at

relationship level, because it appears between relationships of equivalent concepts. Following the

classification defined in section 2.4, this mismatch belong to the flexibility mismatches group,

because it stands for the existence of entities defined in CIM as optional elements (in this case the

bays) that are mandatory in SCL. Therefore, if a CIM file does not include bays for grouping the

pieces of conducting equipment, such pieces of conducting equipment cannot be represented in

the equivalent SCL file.

Figure 3-2. Flexibility mismatch between CIM and SCL (modified from (Preiss, Kostic 2006))

Mismatches at M0

Regarding the mismatches at instance level (M0) between CIM and SCL, scaling/units mismatches

were identified in this work:

Scaling/units mismatches. In the interactions at instance level, the scale and unit used for

expressing voltages must be the same in both the CIM/XML file and the SCL file. Thus, the values

of the attributes scl:unit and scl:multiplier of an scl:tVoltage instance must be the



same as the values of the attributes cim:unit and cim:multiplier of the equivalent

cim:Voltage instance. At this point, it is worth noting that in CIM, the standard profiles express

voltages in kilovolts. Thereby, conflict situations will appear in the interactions between an SCL

tool and a CIM application based on the standard profiles, if an SCL file uses different values to

“V” and “k” in the attributes mentioned above.

RGD_2: Reuse process component models

Process component models typically base on international standards for different viewpoints as IED

and RTUs are systems which fulfil different purposes in different domains and therefore, are built to be

re-used and engineered by vendors and OEMs. The principle of re-using hat been around since the

Texas Instruments TTL technology, therefore, we suggest to use IEC 61499 or 61131 based models

within the scope of re-using individual component models for federated logic devices. At instance

level, engineering data for configuration like IEC 61850 SCL files must be dealt with and provided to

properly re-use configurations to properly evaluate smart grids solutions presented by the dashboard.

3.1.2. Reuse ICT data

RID_1: Reuse ICT architectures

The scope of this function is to reuse information about combined smart grid components, their

functions and dependencies, typically centred on interfaces and interface standards. To provide a

typical overview and basic information about this type of architecture, the DISCERN project uses the

SGAM models and a particular granularity for the matching model elements defined, e.g. for the

DISCERN SGAM Visio template [D2-3.2]. Therefore, we suggest to re-use the SGAM as a semantic

reference designation framework in the repository and to add the project specific vocabulary for

naming elements to the SGAM framework and meta-model.

For SGAM, the SGAM toolbox as well as the 3D Visualization for SGAM provides a XML schema

which can be seen as the basic meta model for SGAM. However, it only focuses on the actual SGAM

framework and lacks semantics agreed upon for the models itself. In DISCERN, we have defined a

first model which can also be used as “core” elements in the dashboard system. Therefore, certain

mismatches shall be addressed when setting up the formats for the RID_1:

Mismatches at M1

As both Use Cases and SGAM are based on a harmonized IEC 42010 meta model there should be no

mismatches at M1 when elements are put onto the individual SGAM domains, zones and layers.

However, it should be made sure when architecture models are imported into the repository that they

share the same basic SGAM reference designation framework and do not use semantics from e.g.

SCIAM or RAMI 4.0.

Mismatches at M0

At instance level, new items ca cover zones which are not included or have the same label and

semantics annotated to the same domain/zone/layer combination because they can implement

different roles as e.g. a system and their scope in broader than needed. In this case, the actor itself

must be harmonised and the functions consolidated just like it is done in the UCMR for DISCERN.

This functionality can be either taken from the UCMR or be deployed into the dashboard when there

could be an actor list component which could be used by several sub-functions like UCMR, SGAM and

KPI.



3.1.3. Access data about communication protocols and standard data models

ACS_1: Find recommended smart grid standards for communication

The smart grid dashboard system shall be able to recommend users the communication standards

and standard data models that can be utilised so as to achieve interoperability within a smart grid

system under design. As explained in [D11.1], this function requires the following data models:

SGAM extension to the IEC 62559-3

SGCG IOP Tool model

IEC Smart Grid Standards Map

Since all these data models share a common framework, the Smart Grid Architecture Model (SGAM)

the number of mismatches at model and instance level – that is, M1 and M0 – are not expected to be

very problematic in the context of this use case. Moreover, the mismatches regarding the modelling

language (i.e. M2) are not relevant in this case, because the system will not perform file

transformations between the formats, but rather make queries on the different data sources based on

the users’ selection.

Nonetheless, it is worth noting that within smart grid projects, individual parts of standards series are

typically confused with the overall technology. For instance, when proposing the IEC 61850-7-4 as the

standard to achieve interoperability within an automation system, users would be agreeing only on the

data model or semantics of the messages, not on the complete technology stack, which is further

detailed in additional parts of the IEC 61850 standard series. Therefore, in order to resolve the

potential granularity mismatches at M1 when designing SGAM models, we suggest additional

keywords for classification when the parts from either the SGCG IOP Tool or the IEC Smart Grid

Standards Map are introduced to the knowledge base of the dashboard.

ACS_2: Carry out standards assessment

For the standards assessments the smart grid dashboard system will leverage the same data models

as described in ACS_1.

3.1.4. Access technical reports on smart grid cyber security

ATS_1: Find recommended IT-security requirements

The smart grid dashboard system shall enable users to find the IT-security requirements as

recommended by international experts on Smart Grid Cyber Security based on the high-level

architectures of the smart grid solution under design. The data models that have to be managed by

the dashboard system in order to realise this function are:

SGAM extension to the IEC 62559-3

NISTIR 7628 role model

As detailed in [D3.5], there might be naming mismatches at M1 when mapping the SGAM components

to the NISTIR 7628 actors; that is, the names given to the devices and applications within the SGAM

component layer, can be different to the equivalent actor as defined in the NISTIR 7628.



3.1.5. Reuse technical functions

RTF_1: Update functional categories

The technical functions stored in the smart grid dashboard system will be grouped in functional

categories, which can be modified by users with necessary access rights. This process, as detailed in

[D11.1] will be carried out directly via a graphic user interfaces. Therefore, the only data model

relevant for this use case is the internal one utilised by the dashboard system, which implies that there

will not be mismatches due to the existence of heterogeneous data models in this case.

RTF_2: Reuse algorithms or automation logics

The representation of the functions (algorithms or automatic logics) as stored in the dashboard system

shall be given in widely-used formats, such as those highlighted in [D11.1]: Matlab, IEC 61131 or

61499. Nonetheless, since the algorithms are hardly interoperable without implementation and there is

not a need within the scope of this use case to actually transform the algorithms between different

formats, no mismatches hindering data management of algorithms are to be expected.

3.1.6. Reuse Key Performance Indicators (KPIs)

RKP_1: Update KPI categories

The smart grid dashboard system shall be able to store KPIs in KPI categories, which will rely on the

European Electricity Grids Initiative (EEGI) KPI framework. Furthermore, it shall enable users to

update the categories that classify the KPI formulas as stored in the repository. The main exchanged

information as defined in [D11.1] are:

KPI category: Proposal of a new KPI category to be included into the smart grid dashboard

system. It shall indicate where the new KPI category would be added into the current library of KPI

categories and explain the motive for the extension.

Rejection: Message explaining the reasons for rejecting the proposed KPI category

The categories must be disjoint to avoid mismatches regarding the name, perspective and granularity.

RKP_2: Reuse performance KPIs

The smart grid dashboard system shall be to reuse performance KPIs for assessing technical smart

grid solutions. Users are able to upload and reuse KPI formulas to assess smart grid solutions [D11.1]

When describing KPIs two mismatches might occur at instance level (level M0):

Scalability/Units mismatches. There are conflicts when different units of KPIs are used in two

models to measure the same content value. Thus, the values of the unit must be the same.

Datatype mismatches. To ensure the comparability, the datatype of the KPIs should be the same

to ensure the comparability (e.g. Integer vs. Float, Integer16 vs. Integer32).

3.2. Integrate smart grid simulations

ISS_1: Create reference simulation scenarios

The smart grid dashboard system shall enable users to create and edit complex co-simulation

scenarios combining models – e.g. network models, functions, ICT architectures, etc. – as stored in

the dashboard system. Therefore, this use case will deal with the mismatches of the corresponding

models as defined in the rest of use cases presented in this deliverable. As for the selection of

language to be used to model the complex co-simulation scenarios (e.g. Mosaik, SysML, CIM), it will



depend on the co-simulation platform that will be utilised in combination with the dashboard system.

3.3. Compare smart grid solutions

3.3.1. Reference smart grid data

RSG_1: Get reference network model from DSO Observatory

The data formatting issues with regard to reference network models are the same as those affecting

the network models, which were already described in RDG_1.

3.3.2. Calculate Key Performance Indicators (KPIs)

CKP_1: Calculate performance KPI

The calculation of KPIs will be performed via a KPI_Calculator interacting with the co-simulation

platform; that is, this use case will be realised through complex co-simulation scenarios.

Consequently, the data management issues affecting this use case are those previously presented in

ISS_1.



4. Conclusions

Deliverable D11.2 is the output of Task 11.2 “Data management concept for the comprehensive smart

grid data repository”. It provides an overview of the required concepts and techniques to be utilised by

the smart grid dashboard system in order to deal with data management issues.

One of the main tasks of the smart grid dashboard system that will be developed in future work out of

the DISCERN scope on the basis of the studies carried out in WP11 is to overcome data management

challenges, particularly those directly related with the existence of numerous data formats for

representing smart grid solutions.

With the aim of developing methods and tools that perform bi-directional transformations between

systems based on heterogeneous data models it is a good practice to first identify and categorise the

mismatches or incompatibilities that suppose a barrier for carrying out such transformations. For that

reason, the first part of this deliverable is dedicated to classifying the types of mismatches hindering

interoperability as described in the state of the art. In addition to this, the main techniques to address

these mismatches are also summarised in this first part of the document.

Following the overview of data model transformation technologies mentioned above, the second part

of the deliverable enumerates the data formats that will be employed by the smart grid dashboard

system for each of the functional use cases that were presented in [D11.1], and categorises and

describes the mismatches that will have to be resolved by the dashboard system so as to realise the

use cases.

The categorisation of mismatches based on state-of-the-art contributions and the adoption of such a

classification to identify and describe data formatting issues with regard to widely-adopted data

models in the electricity sector is a valuable result in itself both for the future development of the smart

grid dashboard system and also for further studies beyond this project, which are aimed at improving

interoperability in smart grids.

The variety of data formats and complexity of the potential problems caused by the different

terminologies, structures, and even modelling languages typically used when representing smart grid

data show the benefits of agreeing on the adoption of existing international standard data models. In

that way, DSOs are encouraged to carefully study the available options in relation to smart grid data

formatting when designing their systems so as to avoid reinventing the wheel and, in that way, adding

complex interoperability mismatches in the future. The overview provided in this document within the

scope of the future smart grid dashboard system shows also that the standardisation bodies

themselves should make an effort to avoid the existence of incompatible standard data models, as it

happens for instance with the IEC 61968/61970 CIM and the IEC 61850 SCL with regard to network

model representation. In that sense, advance data modelling technologies, such as those proposed by

(Guizzardi 2006) are promising research directions toward more efficient development and

maintenance of compatible standard data models for the electricity sector.



5. References

5.1. Project documents

[D2-3.2] – DISCERN Deliverable 2-3.2: “Tool support for managing Use Cases and SGAM models”

[D3.5] – DISCERN Deliverable 3.5: “IT security concept”

[D11.1] – DISCERN Deliverable 11.1: “Functional description of the comprehensive smart grid data

repository”

[D5.1] – DISCERN Deliverable 5.1: “DISCERN semantic model to transfer developed solutions to

DSOs and to facilitate their integration”

[D5.2] – DISCERN Deliverable 5.2: “DISCERN guide for facilitating the replication and scalability of

the solutions”

5.2. External documents

Arranz, A.L. 2006, Advanced multi-agent architectures, M.Sc. Thesis, Comillas Pontifical University,

Spain

Arrow, K. 1963, Social Choice and Individual Values, Cowles Foundation Monograph 12, Wiley, New

York

Benerecetti, M., Bouquet, P. & Ghidini, C. 2001, On the Dimensions of Context Dependence:

Partiality, Approximation, and Perspective, Springer Berlin / Heidelberg

Candido, G., Colombo, A.W., Barata, J. & Jammes, F. 2011, "Service-Oriented Infrastructure to

Support the Deployment of Evolvable Production Systems", Industrial Informatics, IEEE Transactions

on, vol. 7, no. 4, pp. 759-767

Euzenat, J. & Shvaiko, P. 2007, Ontology Matching, Springer-Verlag

Gill, T., Gilliland, A.J., Whalen, A. & Woodley, M.S. 2008, Introduction to Metadata, Getty Publications

Gómez-Pérez, A., Fernandez-Lopez, M. & Corcho, O. 2004, Ontological Engineering with examples

from the areas of Knowledge Management, e-Commerce and the Semantic Web, Springer

Guizzardi G. 2006, Ontological Foundations for Structural Conceptual Models, PhD Thesis, University

of Twente, The Netherlands.

Halevy, Y., Ives, G., Suciu, D. & Tatarinov, I. 2005, "Schema mediation for large-scale semantic data

sharing", The VLDB Journal, vol. 14, no. 1, pp. 68-83

Haslhofer, B. & Klas, W. 2010, "A survey of techniques for achieving metadata interoperability", ACM

Comput.Surv., vol. 42, no. 2, pp. 7:1-7:37

IEC 61850-1, Communication networks and systems for power utility automation - Part 1: Introduction

and overview, IEC TC57 WG 10



IEEE Std 610 1991, IEEE Standard Computer Dictionary. A Compilation of IEEE Standard Computer

Glossaries, 1991

Kalogeras, A.P., Gialelis, J.V., Alexakos, C.E., Georgoudakis, M.J. & Koubias, S.A. 2006, "Vertical

integration of enterprise industrial systems utilizing web services", IEEE Transactions on Industrial

Informatics, vol. 2, no. 2, pp. 120-128

Lastra, J.L.M. & Delamer, M. 2006, "Semantic web services in factory automation: fundamental

insights and research roadmap", IEEE Transactions on Industrial Informatics, vol. 2, no. 1, pp. 1-11

McGuinness, D.L. 2003, "Ontologies Come of Age" in Spinning the Semantic Web: Bringing the World

Wide Web to Its Full Potential., eds. D. Fensel, J. Hendler, H. Lieberman & W. Wahlster, MIT Press.

O'Leary, D.E. 1997, "Impediments in the use of explicit ontologies for KBS development", Int.J.Hum.-

Comput.Stud., vol. 46, no. 2-3, pp. 327-337

Preiss, O. & Kostic, T. 2006, "Unified Information Models in Support of Location Transparency for

Future Utility Applications", in Proceedings of the 39th Annual Hawaii International Conference on

System Science (HICSS '06), pp. 242a

SGCG 2011, Report on Reference Architecture for the Smart Grid; v1.0, CEN/CENELEC/ETSI-Smart

Grid Coordination Group (SGCG)

Sucic, S., Martinic, A. & Francesconi, D. 2011, "Utilizing SOA-ready devices for virtual power plant

control in semantic-enabled Smart Grid Analyzing IEC 61850 and OPC UA integration methodology",

IEEE International Conference on Smart Grid Communications (SmartGridComm), pp. 43

Uslar, M., Specht, M., Rohjans, S., Trefke, J. & Gonzalez, J.M. 2012, The Common Information Model

CIM: IEC 61968/61970 and 62325 - A practical introduction to the CIM (Power Systems), Springer

Visser, P.R.S., Beer, M.D., Bench-Capon, T.J.M., Diaz, B.M. & Shave, M.J.R. 1999, "Resolving

Ontological Heterogeneity in the KRAFT Project", in Proceedings of the 10th International Conference

on Database and Expert Systems Applications, Springer-Verlag, London, UK, UK, pp. 668

Wache, H. 2003, Semantische mediation für heterogene informationsquellen, M.Sc. Thesis, University

of Bremen



6. Revisions

6.1. Track changes

Name Date

(dd.mm.jjjj) Version Changes

Subject of change page

Rafael Santodomingo / OFFIS Maike Rosinger / OFFIS Mathias Uslar / OFFIS

13.11.2015 0.1 Table of contents

Maike Rosinger / OFFIS Mathias Uslar / OFFIS

04.12.2015 0.2 Additional Aspects to Section 3


09.12.2015 1.0 First version for internal revision by WP11 members


29.01.2016 2.0 Comments and proposed amendments from IBDR added

Maike Rosinger / OFFIS

18.02.2016 3.0 Final revision RWE/ Approval



Annex A. Data models used by the smart grid dashboard

system

This annex describes the data models that will be dealt with by the smart grid dashboard system.

Common Information Model (CIM)

The Common Information Model (CIM), which is also used in WP5 for [D5.1] and [D5.2], is the main

metadata model that promotes the interoperability in the management of electric power systems. It is

defined in three standards: the IEC 61970, which is focused on EMS; the IEC 61968, which is focused

on DMS; and the IEC 62325, which describes the CIM-based messages for exchanging information

about electricity markets. Each standard defines a part (or subset of packages) of the model (Uslar et

al. 2012).

The IEC 61970-301 defines the CIM Base model, which represents the required concepts for

exchanging information about the management of transmission networks. Figure A-1 shows the

packages included in this standard.

Figure A-1. IEC 61970 packages

These packages are mainly used to represent: electric power systems (Wires, Topology), the

associated SCADA and protection systems, including the corresponding measurements and control



data (SCADA, Protection, Meas, ControlArea), the generation plants (Generation), and the information

about outage and loads (Outage, LoadModel).

Among the classes defined in the CIM Base Model, cim:Discrete and cim:Analog (which are

included in Meas package) are used to represent, respectively, discrete and analog measurements.

The type of the measurements is determined by the attribute

cim:Measurement.measurementType included in these classes. For example, the position of a

circuit breaker is expressed with an instance of the class cim:Discrete taking the value “Switch

Position” in the above mentioned attribute. The value of a measurement is represented with the

attribute value of the classes cim:DiscreteValue and cim:AnalogValue, whereas the quality of

a measurement is represented with instances of the class cim:MeasurementValueQuality.

The IEC 61968-11 defines additional packages for representing the required concepts for the

management of distribution networks (Figure A-2), such as: asset management (Assets, AssetModel),

information about work management and network extensions (Work), information about customer

billing (Customer), and metering and load control (Metering, LoadControl, PaymentMetering). It also

includes an extension of the Wires package for representing typical distribution network equipment

(WiresExt).


Finally, the IEC 62325-301 adds three new packages for expressing data about electricity markets

(Figure A-3). The MarketCommon package defines concepts that are required in all type of markets,

and the other two packages include specific concepts for different types of electricity markets. The

MarketManagement package is used when the electricity market is mainly based on regulated third

party access, i.e. when transmission system operators have to allow any electricity supplier non-

discriminatory access to the transmission network. Meanwhile, the MarketOperations package is

focused on US-Style electricity market, which is mainly characterised by day-ahead unit commitment

by a market operator, intraday and real-time balancing through central dispatch, and settlement based



on locational marginal prices (Uslar et al. 2012).


Each of the above presented standards, and therefore each part of the CIM model, is developed and

maintained by different working groups of experts within the IEC TC 57: WG13 is responsible for IEC

61970, WG 14 is responsible for IEC 61968, and WG16 is responsible for IEC 62325. Each working

group discusses the possible modelling extensions and modifications of its corresponding part of the

model on a regular basis, usually weekly (Uslar et al. 2012). Nevertheless, due to the existing

dependencies between the different parts, the three working groups have to synchronize their versions

in order to generate an annual combined version, which is maintained as an UML model in the Sparx

Enterprise Architect (EA).

In practice, the CIM works as a global conceptual model. Consequently, it is aimed at achieving a

meta-model agreement for remote management systems of electric networks. Therefore, in order to

achieve metadata interoperability in a particular context within this domain, it is mandatory to define

CIM profiles. The IEC TC 57 WG13 and WG 14 have developed standard profiles. Hence, the IEC

61970-452 and IEC 61968-13 standards define profiles (CPSM and CDPSM) that select the CIM

entities that are required for representing transmission and distribution networks, respectively. Such

standard profiles are described in RDFS. Furthermore, parts 3 to 9 of the IEC 61968 include CIM

profiles in XSD for different business processes in DMS.

In addition to the global conceptual model and the standard profiles, CIM standards define

standardised serialisations for exchanging instance level metadata using CIM entities. Several types

of serialisations are defined in the IEC 61968/61970 standards. The following paragraphs briefly

describe three of them: CIM/XML, CIM/XSD and CIM/SVG.

The CIM/XML, defined in the IEC 61970-552 standard, is an RDF/XML format for exchanging power

system models. CIM/XML files represent instances of the entities defined in the CIM RDF Schemas

standardised in the abovementioned IEC 61970-452 and IEC 61968-13 standards. Figure A-4 shows

how to represent a simple fragment of an electric facility using the CIM/XML format.



Figure A-4. Extract of CIM/XML file

The example describes a circuit breaker that is connected to a connectivity node through one of its

terminals. The circuit breaker is represented in CIM as an instance of cim:Breaker class included in

Wires package. This class derives from cim:ProtectedSwitch, which represents switches

associated to protection equipment. In turn, cim:ProtectedSwitch derives from the class that

represents all types of switches, cim:Switch. Lastly, cim:Switch is a subclass of

cim:ConductingEquipment, which belongs to Core package and represents a generic piece of

conducting equipment. The connection between different pieces of conducting equipment are

represented in CIM with instances of cim:Terminal and cim:ConnectivityNode classes, which

belong to Core package.

The CIM/XML file shown in Figure A-4 represents the definitions of all the instances mentioned above,

including their data properties (such as, cim:Switch.normalOpen, which indicates if the switch is

normally open or not), and their object properties, which represent the associations between the

instances; for example, the instances representing the terminal and the connectivity node in the

example are associated in the CIM/XML file with the object property

cim:Terminal.ConnectivityNode. It is worth mentioning that in Figure A-4, the prefix cim:

refers to the URI that identifies the CIM model. This example uses the version 14 of the CIM

(hereinafter referred to as CIM_v14), so the URI is: http://iec.ch/TC57/2009/CIM-schema-cim14.

CIM/XML serialisation has many advantages. As it is based on the well-known RDF language, it

facilitates the processing of the files in open-source frameworks (such as Jena) and the automatic

inferences using available reasoners on the Web. Nevertheless, in case of large models, CIM/XML

format can have a poor performance in terms of memory. For instance, a CIM/XML file containing the



topology of a real distribution network of a Spanish utility consisting of 1500 nodes takes up 200

Mbytes. In order to partially solve this problem, De Vos defined in (deVos 2003) the Difference Model

Exchange which allows exchanging only the fragments of the models that have been modified from

the previously stored model. However, the first exchange of the complete model can still be

problematic. For that reason, a new CIM standard of the IEC 61970-55x series is being prepared for

defining the CIM Based Efficient Model Exchange Format, also known as CIM/E. In the tests

described in the draft version of the standard, the format CIM/E proved to reduce an average 4.52

times the size of the files in comparison with the CIM/XML format. Nonetheless, the CIM/E format

does not have the advantages of the RDF based languages mentioned above. An alternative solution

that will be analysed in future works, is to employ RDF simplified formats, such as N3 (Berners-Lee,

Connolly 2011), which can significantly reduce the size of very large files and can be processed by

open-source programming frameworks and reasoners.

CIM/XSD files are instances of the XSD profiles described in parts 3 to 9 of the IEC 61968. Figure A-5

shows a fragment of a CIM/XSD file including information about a circuit breaker. The file follows the

Switches.xsd schema defined in the IEC 61968-3 standard and establishes how to exchange

information about switches for network operation purposes. In this case the URI of the CIM model is

represented with the prefix m, and the definition of the breaker includes three attributes: the identifier,

the name, and an attribute indicating if the switch is normally open or not.

Figure A-5. Fragment of a CIM/XSD File

Finally, the CIM/SVG (CIM Based Graphic Exchange Format) is defined in the IEC 61970-453

standard. It is based on the Scalable Vector Graphics (SVG) format, and it is aimed at serializing CIM-

based graphics in order to automatically generate displays of power systems represented in CIM-

based formats. Figure A-6 included in the IEC 61970-453 standard shows the relationship of CIM/SVG

and CIM/XML.



Figure A-6. Relationship of CIM/SVG and CIM/XML (from IEC 61970-453)

As can be seen, the source system sends to the target system the CIM/XML file containing the

information about the power system and the CIM/SVG file containing the information about the

graphical representation of such system.



IEC 61850 models (LN and SCL)

The standard IEC 61850 is developed and maintained by WG 10, WG 17 and WG 18 of the IEC

TC57, and it is aimed to the interoperability in the station automation systems of electric networks.

Originally, it was focused on substation automation systems, but it has evolved in order to be

employed in other electric facilities (IEC 61850-7-420 is an extension for DER plants, IEC 61850-7-

410 for hydroelectric power plants, and IEC 61400-25 for wind power plants), and also for the

communications between substations (IEC 61850-90-1) and between substations and control centres

(IEC 61850-90-2).

Therefore, analogously to the CIM in remote energy management systems, the metadata models of

the IEC 61850 standard define the common semantics to be employed in the local automation of

power systems. As explained in (Hughes 2006), the IEC 61850 defines two standard metadata

models: the LN model and the SCL model.

LN model

The Logical Node (LN) model is standardised in the IEC 61850-7 series and defines the semantics of

the run-time signals that need to be exchanged between IEC 61850 IEDs. It is based on the following

concepts (Sucic, Martinic & Francesconi 2011):

Servers represent physical IEDs in station automation systems.

Logical Devices (LDs) are virtual representations of devices that perform supervision, protection or

control functions within a server.

Logical Nodes (LNs) are the main concepts in the LN model and represent specific functionalities

in the logical devices. The IEC 61850-7-4 series (including IEC 61850-7-4xx extensions) define

around 200 classes of logical nodes. First letter of these classes designates a functionality group

(e.g., X – switching devices, C – control functions, M – measurement), while the rest of LN

notation reflects function names (e.g., XCBR – circuit breaker, CSWI – control switch, MMXU –

measurement unit).

Data Objects (DOs) are groups of attributes included in logical nodes. For instance, the data

object Pos included in CSWI contains all the information about the position of a switch. Data

objects can additionally contain sub data objects (SDOs). Thus, the data object A of MMXU refers

to the measurement of current and contains the sub data object phsA, which represents the

current in the phase A.

Data Attributes (DAs) are the endpoints of the LN model. For instance, the attribute stVal of Pos

represents the value of the position of an element. Data attributes can contain basic data

attributes (BDAs). For example, the above mentioned phsA attribute is a complex measured value

that includes different BDAs, such as instCVal, which represents the instance value of analogue

measurements.

Functional Constraints (FC) categorize data attributes attending to their specific functional use,

e.g. control, measurement, or configuration.

Data Sets (DS) refer to sets of data objects that are used by IEC 61850 clients in order to optimize

communication bandwidth usage.

Figure A-7 shows a UML class diagram representing the relationships between these basic concepts.

As can be seen, Servers can contain LDs, which in turn consist of LNs. Meanwhile, LNs include DOs,

which are composed of SDOs and DAs. Finally, DAs are associated to a FC and DOs can belong to a



DS.

Figure A-7. Basic concepts of the LN model (from (Sucic, Martinic & Francesconi 2011))

LN run-time signals are identified by the concatenation of the corresponding instances of the basic

concepts defined before. Thereby, the path of a LN run-time signal follows this structure:

ServerLD/LN.DO.DA. In case of existing SDOs or BDAs, such elements should be included in the

corresponding position according to the hierarchy showed in Figure A-7, i.e.

ServerLD/LN.DO.SDO.DA.BDA. For instance, the LN run-time signal indicating the position of a circuit

breaker QA1 located in the bay Q1 and controlled by the logical device LD1, which in turn, is allocated

in the physical device IED1 is: IED1LD1/Q1QA1CSWI1.Pos.stVal. For its part, the LN run-time signal

that represents the instant value of the current in the phase A of bay Q1 and it is allocated in the same

logical device is: IED1LD1/Q1MMXU1.A.phsA.instCVal. It is worth mentioning that logical nodes are

represented in the LN run-time signals as the concatenation of a prefix, the class of logical node and a

suffix. The prefix typically refers to the power system resource associated to the logical node, whereas

the suffix indicates the number of logical node instance. In the first example, the prefix Q1QA1 refers

to the circuit breaker QA1 located in the bay Q1. Meanwhile, in the second example, the prefix Q1

refers to the bay Q1.

The LN model is represented in simple text tables following the specific format defined in the IEC

61850-7 series. Thus, for instance, the CSWI logical node class is represented in Table A-1, which is

included in the IEC 61850-7-4 standard. The data objects (DO) of the logical nodes are categorised in

the tables attending to their functional constraint: generic data, controls, measured values and status

information. For each DO, the table includes its Common Data Class (CDC), provides a brief

description of the data object, and indicates whether the DO is mandatory (M), optional (O), or

conditional (C).



Table A-1. CSWI class (defined in IEC 61850-7-4)

In the LN model, Common Data Classes (CDCs) are classes of data objects. They are defined in the

standard IEC 61850-7-3. For instance, according to Table A-1, the data object Pos belongs to the

DPC class, which is defined in the standard IEC 61850-7-3 (Table A-2).

Table A-2. Fragment of the definition of DPC class (from IEC 61850-7-3)

DPC class contains, among others, the data attributes stVal, t and q, which represent, respectively,

the value of measurement, its time stamp and the quality associated to the measurement. Each data

attribute is associated to a data type, which can be: a primitive (such as BOOLEAN), another CDC, or

a simple data type (such as TimeStamp). Simple data types are defined in the IEC 61850-7-2

standard.

At present, based on previous contributions (Preiss, Kostic 2006), IEC TC 57 WG10 is working on the

representation of the LN model in UML. This work facilitates the detection of mistakes, redundancies

and contradictions in the existing LN model, and will make it easier for the applications to process the

model. The objective is to automatically generate the IEC 61850-7 standard documents from the UML



version of the model. In the future, the automatic conversions from UML to OWL will enable the

inferences in available reasoners on the Web from the knowledge described in the LN model. This will

make it possible the explicit and reusable representations of control functions. Moreover, following the

same principles as the evolvable production systems described in (Lastra, Delamer 2006), (Kalogeras

et al. 2006), and (Candido et al. 2011), it will facilitate the metadata interoperability in run time with

systems based on different metadata models.

Figure A-8 shows a fragment of the UML representation of the LN model. In particular, the fragment

shows the UML representation of the logical node CSWI and of the common data class DPC. The first

definition is included in the package IEC 61850-7-4 and the second one in the package IEC 61850-7-

3.

Figure A-8. Fragment of the UML representation of the LN model

LN messages are serialised at application level in MMS and GSE. MMS stands for Manufacturing

Message Specification and is a standardised messaging system (ISO 9806) between devices of

control systems. For its part, GSE stands for Generic Substation Event and refers to the

communication service defined in the IEC 61850-7-2 standard that enables the simultaneous, fast and

reliable communication of generic substation events to several IEDs within the automation system.

SCL model

The Substation Configuration Language (SCL) model is described in the IEC 61850-6 standard and

defines the semantics to exchange information about the configuration of IEC 61850-based systems.

Figure A-9 gives an overview of the SCL basic structure. The element (SCL) is derived from the

scl:tBaseElement class, which can include private information and descriptive textual data. SCL

elements must contain an scl:Header element of type scl:tHeader with information about the

version and author of the SCL document. In addition, they may contain:

scl:Substation elements of type scl:tSubstation with information about the topology of

the electric facility,

a scl:Communication element of type scl:tCommunication with information about the



communications in the automation system,

scl:IED elements of type scl:tIED with information about the intelligent electronic devices of

the system,

and a scl:DatatypeTemplates element of type scl:tDatatypeTemplates with information

about the LN signals allocated in the IEDs.

Figure A-9. Overview of SCL model

SCL is standardised as a XML Schema defined in XSD. However, the IEC 61850-6 standard includes

fragments of the model in UML. At instance level, SCL files are XML files that follow the XML Schema

defined in the standard. Figure A-10 shows how to represent a simple fragment of an electric facility in

SCL. As can be seen, the representation of the terminals and connectivity nodes in SCL is similar to

the representation of such elements in CIM. The difference is that in CIM the terminals and

connectivity nodes are associated with an object property (cim:Terminal.ConnnectivityNode),

whereas in SCL they are related with an association by reference. Thus in SCL, a terminal t is

associated to a connectivity node c if the value of the attribute scl:connectivityNode of t is the

same as the value of the attribute scl:pathName of c. Regarding the representation of the circuit

breaker, in SCL all the pieces of conducting equipment are instances of the class

scl:tConductingEquipment. The type of conducting equipment represented by the instance is

determined with the attribute scl:type, whose range is an enumeration including all the types of

conducting equipment that are defined in the SCL model. In the case of circuit breakers, the attribute

scl:type takes the value CBR.



Figure A-10. Fragment of an SCL File

Lastly, it is worth explaining that the IEC 61850-6 standard defines six types of SCL files depending on

the type of information that they exchange:

IED Capability Description (ICD) files contain data exchanged from the IED configurator to the

system configurator about the functional and engineering capabilities of an IED type. They must

include one scl:IED element with name TEMPLATE, a scl:DatatypeTemplates section and,

optionally, a scl:Substation with name TEMPLATE.

Instantiated IED Description (IID) files contain data exchanged from the IED configurator to the

system configurator about a single IED preconfigured specifically for a project. They include the

same elements as ICD files, but the scl:IED and scl:Substation elements have their own

specific names. Furthermore, IID files may contain an scl:Communication element with the

address and other settings of the IED.

System Specification Description (SSD) files contain data exchanged from a system specification

tool (e.g., substation or protection engineers in the EMS) to the IEC 61850 system configurator

about the single line diagram of the electric facility and the associated logical nodes. They include

an scl:Substation element, and optionally, they can include a scl:Communication element

and scl:IED elements if they are already configured.

Configured IED Description (CID) files contain data exchanged from the IED configurator to the

IED about the communication-related part of an instantiated IED within a project. They have to

include all the elements inFigure A-9, except the scl:Substation element, which is optional.

System Configuration Description (SCD) files contain data exchanged from the system

configurator to IED configurators about all configured IEDs in the automation system. They include

all the elements in Figure A-9 that are required to define a configured IEC 61850 automation



system.

System Exchange Description (SED) files contain data exchanged between system configurators

of different projects. They are subsets of SCD files including only the interfacing parts of the IEDs

to which connections between the projects shall be engineered.



SGAM data model IEC 62559-3

The standard IEC 62559-3 includes a UML data model defining the concepts required for expressing

use cases. In DISCERN, this UML data model has been enhanced with the aim of formally

representing SGAM concepts and relating them with use case elements.

Figure A-11 shows an extract of the SGAM extension to the IEC 62559-3 data model.

Figure A-11. Extract of SGAM UML meta-model (aligned with IEC 62559-3 meta-model)

deliverable (d) no: 11.2 data management concept for the ... · pdf filedata management...

Documents