deliverable (d) no: 11.2 data management concept for the ... · pdf filedata management...
Post on 07-Feb-2018
224 Views
Preview:
TRANSCRIPT
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 Page 5 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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 6 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 7 of 46
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-2. IEC 61968 PACKAGES ......................................................................................... 34
FIGURE A-3. IEC 62325 PACKAGES ......................................................................................... 35
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 8 of 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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 9 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 10 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 11 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 12 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 13 of 46
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/
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 14 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 15 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 16 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 17 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 18 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 19 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 20 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 21 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 22 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 23 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 24 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 25 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 26 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 27 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 28 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 29 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 30 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 31 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 32 of 46
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
Rafael Santodomingo / OFFIS Maike Rosinger / OFFIS Mathias Uslar / OFFIS
09.12.2015 1.0 First version for internal revision by WP11 members
Rafael Santodomingo / OFFIS Maike Rosinger / OFFIS Mathias Uslar / OFFIS
29.01.2016 2.0 Comments and proposed amendments from IBDR added
Maike Rosinger / OFFIS
18.02.2016 3.0 Final revision RWE/ Approval
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 33 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 34 of 46
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).
Figure A-2. IEC 61968 packages
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 35 of 46
on locational marginal prices (Uslar et al. 2012).
Figure A-3. IEC 62325 packages
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 36 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 37 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 38 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 39 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 40 of 46
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).
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 41 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 42 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 43 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 44 of 46
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
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 45 of 46
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.
D11.2 Data management concept for the comprehensive smart grid data repository
DISCERN_WP11_D11 2_160218_v3.doc Page 46 of 46
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)
top related