Professional Documents
Culture Documents
This project has received funding from the European Unions Horizon 2020 research and innovation programme under
grant agreement No 646531
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
2 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
DOCUMENT HISTORY
3 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
EXECUTIVE SUMMARY
The work developed in T1.3 Applicable standards and potential synergies, and presented in D1.3
Report on standards and potential synergies, is focused on describing and analysing the implementation
of standardised solutions and potential improvements achievable by promoting the use of standard
communication protocols and interoperable and standardised equipment in the four UPGRID
demonstrators (Spain, Portugal, Sweden and Poland) [1].
It is considered that the Smart Grid standardization framework is mature enough. This is corroborated
by the review of references provided in section 1.1 - Practical references to standardisation (e.g. Smart
Grid Standards Mapping Tool, SGCG Interoperability IOP tool and SGAM). However on what smart grid
actors should be placed particular emphasis now is in exploring detail aspects derived from the
applicability of already defined standards. This will result in the identification of strengths and
weaknesses from a practical perspective. In fact, requirements derived from field experience and
implementation tests are the key aspects that make feasible this approach. This is the focus given to the
present document.
The present deliverable collects information to show the approach to standards in the four UPGRID
demonstrators first, to perform then a Gap Analysis. It is complemented by the technical framework of
the four UPGRID demonstrators included in D1.1 Report on technical specifications [1].
The precise scope of D1.3 deals with both communication protocols (i.e. application layer) and
equipment (i.e. mechanical characteristics that influence on the interchangeability of devices between
countries). The first two chapters are aimed at classifying, describing and collecting evidences about the
impact of the identified protocols and pieces of equipment; while the third chapter is focused on
analysing this information and the complete definition of the particular protocols and profiles. This has
resulted in a series of conclusions and recommendations.
The classification of protocols and equipment have been defined to show which ones are involved in the
Demo Base (implementations over which the UPGRID demos will build on) and those that will be
deployed during UPGRID. Additionally they are identified in standard or non-standard solutions. This is
complemented with some qualitative information. The impact assessment is based on four factors:
interoperability, interchangeability, scalability and replicability.
From the initial demonstrations approach to standard and equipment and the impact assessment it is
possible to conclude that the four UPGRID demonstrators are progressing on the identification and
definition of the protocols and equipment. The four demonstrators mostly, at the present stage of the
project (M6) are considering protocols in which they have previous experience. The expected use of
non-standard approaches will be in most of the cases extensions on standards solutions. That means, in
coming years they could be promoted to be included in the standards. It is worth mentioning that the
4 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
four demonstrators will consider CIM in the UPGRID implementations. This is aligned with the selection
in D1.1 of the sub-functionality Use CIM for LV network modelling and data exchange between e.g.
AMI, GIS, MV SCADA, and LV Network Management System (D9.2). Regarding the impact assessment of
equipment, the full interoperability (being interoperable-communications and interchangeable-
mechanic) has not been identified as a predominant feature across the demonstrations. This is most
probable at national level than between countries. The main reasons (barriers) are requirements for
physical dimensions; while from a communication point of view more synergies are identified. One way
pointed out by the demos to prove interoperability is the fulfilment of compliance tests.
The most important chapter of this deliverable is the Gap Analysis. As mentioned, the purpose is to
compare the approach of protocols and standards done and expected by each of the demonstrators to
provide suggestions and recommendations. The main conclusion for the Gap Analysis is that regarding
low-level protocol layers, the interoperability is assured by the use of mature protocols as PRIME, ETSI
TS 103 908, GPRS (or superior technology) or general IP networks. The main gap arises in the data model
to be used in the high-level protocol layers: or is a non-standard protocol or the experience about using
the protocol is not enough. This is the case of CIM and justify the development of the sub-functionality
Use CIM for LV network modelling and data exchange between e.g. AMI, GIS, MV SCADA, LV Network
Management System (D9.2). This sub-functionality also increases the synergy level between
demonstrators. In order to achieve the interchangeability of equipment involved in the project, the Gap
Analysis has detected the importance of national regulations that hinder, e.g. that a Smart Meter (SM)
from one demo could be installed in other demo, despite that the functionality and protocol
communication are interoperable.
This document has been elaborated considering the present stage of definition and concretion of the
conditions, approaches and characteristics of each Demonstrator, combining inputs received from the
demo leaders with the support of the rest of the collaborators and the transversal partners.
5 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE OF CONTENTS
6 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
7 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
LIST OF FIGURES
FIGURE 1: WINDOW SHOOT OF THE SMART GRID STANDARDS MAP (TAKEN FROM
HTTP://SMARTGRIDSTANDARDSMAP.COM/) ______________________________________________18
FIGURE 2: WINDOW SHOOT OF THE SGCG INTEROPERABILITY IOP TOOL (TAKEN FROM
HTTP://WWW.CENCENELEC.EU/STANDARDS/SECTORS/SUSTAINABLEENERGY/SMARTGRIDS/PAGES/DEF
AULT.ASPX) _________________________________________________________________________19
FIGURE 3: LAYERS, DOMAINS AND ZONES DEFINED BY SGAM (TAKEN FROM [17]) _________________21
FIGURE 4: DIFFERENT DIMENSIONS OF STANDARDS _________________________________________23
FIGURE 5: CONCEPTS AND FACTORS USED TO FRAME THE STANDARDISATION IMPACT IN UPGRID ___27
FIGURE 6: COMPLETE METHODOLOGY APPLIED IN D1.3 ______________________________________32
FIGURE 7: ARCHITECTURE FOR SUB-FUNCTIONALITIES IN THE SPANISH DEMONSTRATION DEALING WITH
THE DATA METERING ACQUISITION FROM FIELD (SOURCE: ZIV) _______________________________42
FIGURE 8: LIST OF EQUIPMENT USED IN THE SPANISH DEMONSTRATION INDICATING LOCATIONS AND
PROTOCOLS FOR SUB-FUNCTIONALITIES DEALING WITH METERING DATA ACQUISITION FROM FIELD
(SOURCE: ZIV) _______________________________________________________________________43
FIGURE 9: DISTRIBUTED NETWORK ______________________________________________________45
FIGURE 10: DISTRIBUTED NETWORK, ELEMENTS (DATA CONCENTRATOR IN RED WHILE SMS IN GREEN)
(SOURCE: ZIV. THE IMAGE SHOWS THE DATA CONCENTRATOR MODEL 4CCT AND SMS MODEL 5CTM) 46
FIGURE 11: ARCHITECTURE OF PORTUGUESE DEMONSTRATOR ________________________________57
FIGURE 12: MAIN CHARACTERISTICS OF THE EDP BOX _______________________________________58
FIGURE 13: PROTOCOLS FOR EDP BOX PLC PRIME __________________________________________59
FIGURE 14: PROTOCOLS FOR EDP BOX GPRS _______________________________________________59
FIGURE 15: MAIN CHARACTERISTICS OF THE DTC ___________________________________________60
FIGURE 16: SIMPLIFIED DESCRIPTION OF STANDARDS USED FOR SM CONNECTION TO OVERLYING
SYSTEM HIERARCHY __________________________________________________________________68
FIGURE 17: SIMPLIFIED DESCRIPTION OF STANDARD USED FOR MV NETWORK FPI AND LV NETWORK
SECONDARY SUBSTATION CONNECTION TO OVERLYING SYSTEM HIERARCHY _____________________69
FIGURE 18: SGAM COMPONENT LAYER FOR THE SWEDISH DEMONSTRATOR ARCHITECTURE ________73
FIGURE 19: SGAM COMMUNICATION LAYER FOR THE SWEDISH DEMONSTRATOR ARCHITECTURE ____75
FIGURE 20: SGAM INFORMATION LAYER FOR THE SWEDISH DEMONSTRATOR ARCHITECTURE _______78
FIGURE 21: SGAM FUNCTION LAYER FOR THE SWEDISH DEMONSTRATOR ARCHITECTURE __________79
8 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
9 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
LIST OF TABLES
TABLE 23: IMPACTS FOR THE UPGRID PORTUGUESE DEMONSTRATOR PROTOCOL LIST ____________103
TABLE 24: IMPACTS FOR THE UPGRID PORTUGUESE DEMONSTRATOR EQUIPMENT LIST __________104
TABLE 25: IMPACTS FOR THE UPGRID SWEDISH DEMONSTRATOR PROTOCOL LIST ________________107
TABLE 26: IMPACTS FOR THE UPGRID SWEDISH DEMONSTRATOR EQUIPMENT LIST ______________110
TABLE 27: IMPACTS FOR THE UPGRID POLISH DEMONSTRATOR PROTOCOL LIST _________________118
TABLE 28: IMPACTS FOR THE UPGRID POLISH DEMONSTRATOR EQUIPMENT LIST ________________120
TABLE 29: SENSORS AND IEDS _________________________________________________________124
TABLE 30: IEDS AND DATA CONCENTRATORS _____________________________________________124
TABLE 31: DATA CONCENTRATOR, OR IEDS, AND SCADA ____________________________________124
TABLE 32: BETWEEN SCADAS __________________________________________________________125
TABLE 33: SCADA AND MANAGEMENT LEVEL _____________________________________________125
TABLE 34: INSIDE MANAGEMENT LEVEL _________________________________________________125
TABLE 35: SMS AND SM CONCENTRATORS _______________________________________________125
TABLE 36: SM CONCENTRATORS AND AMI HEAD-END ______________________________________126
TABLE 37: AMI HEAD-END AND MANAGEMENT LEVEL ______________________________________126
TABLE 38: PRIME NETWORK MANAGEMENT ______________________________________________126
TABLE 39: DATA CONCENTRATOR (E.G. RTUS) NETWORK MANAGEMENT _______________________126
TABLE 40: MOBILE DEVICES AND MANAGEMENT LEVEL _____________________________________126
TABLE 41: HOME DEVICES ____________________________________________________________127
TABLE 42: INSTALLED EQUIPMENT IN THE DEMO BASE _____________________________________130
TABLE 43: NEW EQUIPMENT TO BE INSTALLED UNDER UPGRID _______________________________131
11 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
13 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
14 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
1. INTRODUCTION
The introductory chapter is aimed at providing a general overview about Smart Grid standardisation to
complement the information provided by the analysis of standards and equipment that will be used in
the UPGRID demos. This should facilitate the understanding of what currently exists around this topic
(high level approach) giving practical references to the reader.
The main objectives of task T1.3 Applicable standards and potential synergies is to see how the four
UPGRID demos are considering the implementation of standardised solutions and thus how to improve
some of the proposed deployments by promoting the use of interoperable and standardised equipment
(scalability and replicability). A Gap Analysis on standards will be also done by studying the problems
and lacks to utilize some of them in different projects. Moreover, this work is complemented taking into
account equipment utilisation. That is, description of the implementation of standardised solutions and
improvements in some of the proposed demo projects by fostering the use of interoperable and
standardised equipment. Then, D1.3 is based on the applicability of standards already developed to
identify possible issues.
Task T1.3 is interrelated with other WPs and Tasks of UPGRID project. Firstly, with the list of
subfunctionalities elaborated in task T1.1 since it is the framework that allows narrowing the scope of
protocols and equipment to analyse. Secondly, with each of the demo WPs (WP3-6), since task T1.3 is
aimed at providing them with guidelines and recommendations regarding the use of standards to
measure the impact in the four aspects identified in this document: interoperability, interchangeability,
scalability and replicability. Then, demonstrators will have the opportunity to compare their initial
approach to standards to what is advised in task T1.3. The proposed recommendations can be applied in
their implementations. WP2 - Innovative Distribution Grid Use Cases and Functions will take as reference
the standardisation approach of the demos to design the communication part of the WP2 transversal
components accordingly to facilitate their implementation.
In March 2011 the EU Smart Grid mandate M/490 [2] was published. Through this mandate, the EC
requested CEN (Comit Europen de Normalisation) [3], CENELEC (Comit Europen de Normalisation
lectrotechnique) [4] and ETSI (European Telecommunications Standards Institute) [5] to develop or
update a set of consistent standards within a common European framework of communication and
electrical architectures and associated processes. CEN, CENELEC and ETSI created the SGCG (Smart Grid
Co-ordination Group) that has been working during four years to enable or facilitate the implementation
in Europe of the different high level Smart Grid services and functionalities. In other regions of the world
other initiatives have been developed also, like USA with NIST (National Institute of Standards and
15 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Technology) [6]. Another relevant mandate is M/441 in the field of measuring instruments for the
development of an open architecture for utility meters involving communication protocols enabling
interoperability [7][9].
The work in SGCG was distributed in four working groups: Architecture, Set of Standards, Security and
Interoperability. In the Architecture group, the Smart Grid Architecture Model (SGAM) was created to
set a visual description and the basis of the model of the Smart Grids in Europe. In the Set of Standards
group a selection of existing and upcoming standards were compiled from CEN, CENELEC, ETSI but also
from IEC, ISO or ITU (other international standardization associations) when needed, and also the gaps
in the standards were detected. In the Security group, the basis of the security model and the gaps
related to security were detected in the standards. In the Interoperability group the problems due to
lack of interoperability in the products developed according to a standard were studied to give a final
recommendation about the points to have in mind when developing standards to avoid these problems.
The works in SGCG ended in 2014 but the European Commission is studying now how to maintain the
work along the time.
The use of standards intents to facilitate the development and interoperability of new solutions.
However, the context around this process is a determining factor. For example, it might be different the
approach to integrate legacy systems that use proprietary protocols with new ones than build an
architecture from scratch. Efforts and resources are the main variables that will condition the choice to
follow in each of the cases.
In general terms, the use of standards have a series of advantages. They are summarised next for one
particular example: standards for representing Smart Grid solutions (e.g. SGAM and Use Cases). The
benefit of applying communication standards (protocols) are covered in Chapter 3. They aim at
promoting interoperability within solutions. That is, facilitate information exchanges across different
components (devices and applications) within Smart Grid solutions.
16 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
There are a series of tools to facilitate the visualisation and access to the different standards that
currently exist around Smart Grid which are promoted by different standardisation bodies. They are very
useful for experts on the topic but also for others that the standardisation is not their area of expertise.
17 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
FIGURE 1: WINDOW SHOOT OF THE SMART GRID STANDARDS MAP (TAKEN FROM HTTP://SMARTGRIDSTANDARDSMAP.COM/)
18 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
FIGURE 2: WINDOW SHOOT OF THE SGCG INTEROPERABILITY IOP TOOL (TAKEN FROM
HTTP://WWW.CENCENELEC.EU/STANDARDS/SECTORS/SUSTAINABLEENERGY/SMARTGRIDS/PAGES/DEFAULT.ASPX)
19 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
There are a series of standards that include lists of Smart Grid actors that intend to normalise and
uniformed their names: IEC 61970, IEC 61850, ENTSO-E Role Model and CEN-CENELEC-ETSI Smart Grid
Coordination Group First Set of Standards.
The DISCERN project has created a consolidate list taken into account the previous material:
(http://www.discern.eu/project_output/tools.html)
It exists other material related to cyber security aspects of Smart Grids that might be also useful as
reference. For example, NISTIR 7628 guidelines [22]. It is a document based on Smart Grid Cyber
Security developed by the National Institute of Standards and Technology (NIST) of the U.S. Department
of Commerce. It defines components and systems that interact in Smart Grid solutions as well as groups
of logical interfaces between them. For each logical interface category, NISTIR 7628 gives a set of high-
level IT security requirements that shall be met by the solutions implementing logical interfaces within
that category. It is aligned the European CEN-CENELEC-ETSI SGCG Smart Grid Information Security
report. (http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf)
Regarding tools to represent and document Smart Grid solutions, there are two tools that stand out.
They are: SGAM (Standard Graphical Architecture Model) and Use Case template. SGAM was developed
by CEN-CENELEC-ETSI Smart Grid Coordination Group. The SGAM framework aims at offering a support
for the design of smart grids use cases with an architectural approach allowing for a representation of
interoperability viewpoints in a technology neutral manner, both for current implementation of the
electrical grid and future implementations of the smart grid. It is a three dimensional model that is
merging the dimension of five interoperability layers (Business, Function, Information, Communication
and Component) with the two dimensions of the Smart Grid Plane, i.e. zones (representing the
hierarchical levels of power system management: Process, Field, Station, Operation, Enterprise and
Market) and domains (covering the complete electrical energy conversion chain: Bulk Generation,
Transmission, Distribution, DER and Customers Premises), see Figure 3. This SGAM Framework can be
used by the SGAM Methodology for assessing smart grid use cases and how they are supported by
standards, thus allowing standards Gap Analysis. They represent a limited set of ways to represent
abstractions of different stakeholders views of a Smart Grid system. Four viewpoints have been
selected by the SG-CG/RA: Business, Functional, Information and Communication, with associated
architectures [15][17].
Use Cases are the descriptions of smart grid applications that define the important actors, systems and
technologies and their requirements that are part of the smart grid applications. That is class
specification of a sequence of actions, including variants, that a system (or other entity) can perform,
interacting with actors of the system [SOURCE: IEC 62559, ed.1 2008-01 - IEC 62390, ed. 1.0:2005-01]
use case template a form which allows the structured description of a use case in predefined fields
[15][17].
20 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
FIGURE 3: LAYERS, DOMAINS AND ZONES DEFINED BY SGAM (TAKEN FROM [17])
It is worth mentioning that the European FP7 project DISCERN (Distributed Intelligence for Cost-Effective
and Reliable Distribution Network Operation) (http://www.discern.eu/index.html) has developed a
series of tools for managing Use Cases and SGAM models that is comprised of:
21 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
DISCERN Libraries
Excel files containing libraries of actors, technical functions, and requirement categories that must be
used in the Use Cases and SGAM models. The libraries are based on international standards and
technical reports, such as: IEC 61970, IEC 61850, ENTSO-E Role Model and CEN-CENELEC-ETSI Smart Grid
Coordination Group First Set of Standards.
The material and description used in this frame are available free of charge from the project webpage
(http://www.discern.eu/project_output/tools.html)
In WP2 - Innovative Distribution Grid Use Cases and Functions of the UPGRID project it is intended to
use the SGAM model to represent and deliver the conceptual definition of transversal components to
the demo partners involved. It is being evaluated the possibility to make use of the synergy that would
provide the use of the latter SGAM introduced Visio template. In such a way, all the components will be
documented using the same file format and graphical representations. Therefore, this will facilitate the
understanding of any component by any partner.
From a high level perspective, D1.3 deals with protocols and equipment. However it is evident that
these two concepts are very wide and it is necessary to establish a concise framework for the present
document.
In both cases, protocols and equipment, there are standards and proprietary solutions. Regarding
standards it can be identified different types such as measurement standards, communication protocol
standards, data model standards, standard graphical representation, physical dimension standards,
environmental conditions standards and power supply standards (see Figure 4).
22 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
OSI levels
Measurement standards Physical
Communication protocol standards Link
Data model standards Communication
Graphical representation Application
Standards Solutions
Physical dimension standards
Environmental conditions standards
Power supply standards
Proprietary Solutions
This document is organised in four main chapters that form the core of the deliverable which is
complemented with an Executive Summary and Introduction chapters.
Chapter 2 explains the methodology used to elaborate each of the analysis performed in this
document.
Chapter 3 presents the approach to standard by each of the four demos in the UPGRID project
(protocols and equipment). This information is presented in tables and complemented with
qualitative information.
Chapter 4 presents evidences of the impact that the demo approach will have on interoperability,
interchangeability, scalability and replicability based on the election of protocols and equipment.
Chapter 5 reports the Gap Analysis performed based on the collected information and
guidelines/recommendations regarding the synergies of using standards in the demo projects.
Annex I contains more details about some of the protocols mentioned in this deliverable.
It is worth mentioning that the reader might find that some sections of the document are not equality
balanced in terms of amount of information and details between the demonstrators. The main reason is
that the deliverable has been elaborated from the information available by the demonstrators during
the first months of the UPGRID project and some aspects were still under evaluation without being able
to be described in detail. Then the information contained in the following chapters will be consolidate
and complete by the work that is going to be done by each demonstrator in their respective WPs.
23 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
2. METHODOLOGY
The methodology applied in D1.3 aims to facilitate the achievement of task T1.3 objectives. It consists
on collecting information from each of the four UPGRID demonstrators, classified it (Table 1, Table 4 and
Table 5) and processed to obtain conclusions, recommendations and guidelines to promote the use of
standards. This is developed in three core chapters which have their own purposes.
The first chapter, initial demonstrations approach to standards and equipment provides a view of how
demonstrators are approaching the use of standards for protocols and equipment in the
subfunctionalities identified in D1.1 - Report on Technical Specifications [1]. That is, what is used and
what is proposed to be used. The methodology for this part of the document is based on creating two
tables: one for protocols and other for pieces of equipment. As shown in Table 1 they are divided in
different sections in order to structure the information and facilitate the visualisation. These tables are
divided in two halves that contain two categories each. The left hand side of the tables is focused on the
existing part over which the UPGRID demos will be built (what is already used) and the right hand side
area makes reference to the demo developed under UPGRID (what is proposed to be used). The two
subcategories in each of the halves have the purpose of identifying the character of the protocol and
equipment. That is, if they are standard or proprietary.
Therefore Table 2 is used for protocols while Table 3 for equipment. Then, there are two tables per
demonstrator. These tables have been filled in by the demos taken into account the list of
subfunctionalities [1]. This has been done in an iterative process. The complete name of protocols has
been requested to identify them univocally.
24 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
The information included in the previous tables is completed with qualitative information for each of the
identified protocols and pieces of equipment. These details are intended to be collected through a series
of questions to guide and facilitate the exploration to the demonstrators. They are structured in three
25 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
categories: one for the developed part of the demo (standard and proprietary parts) and two for the
part of the demo to be developed under UPGRID (one for standard proposed while other for those cases
in which changes are proposed) questions are listed as follows:
Guideline for qualitative aspects for protocol and equipment to explore by the demonstrators
(based on Table 2 and Table 3)
Table 2 and Table 3 together with the qualitative descriptive information form the starting point
regarding demos approach to standards. This is used afterwards to perform the Gap Analysis.
The second chapter presents the impact of standardisation in the UPGRID project from a protocol and
equipment perspective. It deepens on the scalability and replicability. As mentioned the main objectives
of the recommendations and guidelines proposed in this document facilitate the utilisation of some
standards in different demonstrators and make possible to measure the improvements derived. A
series of key concepts have been identified in this section: Interoperability, Interchangeability,
Scalability and Replicability. The methodology for this part of the document is based on creating two
new tables. As happens before, one is concentrated on protocols and the other on equipment. It is
observed that the first column in Table 4 and Table 5 follows the same structure of Table 2 and Table 3.
Moreover, there is one header for each of the four identified factors. The purpose is to collect and
26 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
identify practical arguments related to the impact on the mentioned factors as results of the use of
selected protocols and equipment in the UPGRID demonstrators (Chapter 3). It is not intended to be a
theoretical exercise but a practical one (justifications through real demo facts).
Figure 5 presents the concepts and factors that are used in chapter 4 to frame the impact of
standardisation which definitions are presented bellow (most of them come from original sources -
standard and norms - which are duly indicated)
Factors
Concepts Interoperability (compatibility)
Standard (interface standard) Interchangeability
Communication protocol / protocol Scalability
Replicability
FIGURE 5: CONCEPTS AND FACTORS USED TO FRAME THE STANDARDISATION IMPACT IN UPGRID
Standard: Document, established by consensus and approved by a recognized body, that provides,
for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed
at the achievement of the optimum degree of order in a given context. Standards should be based on
the consolidated results of science, technology and experience, and aimed at the promotion of
optimum community benefits. For example: IEC 60870-5-101: Serial protocol between Control Centre
and RTU, EN 60529: Degrees of protection provided by enclosures and EN 50470-3: Accuracy
requirements of an active energy meter. [Source: ISO/IEC GUIDE 2:2004]
Safety and reliability Adherence to standards helps ensure safety, reliability and environmental
care. As a result, users perceive standardised products and services as more dependable this in
turn raises user confidence, increasing sales and the take-up of new technologies.
Support of government policies and legislation Standards are frequently referenced by
regulators and legislators for protecting user and business interests, and to support government
policies. Standards play a central role in the European Union's policy for a Single Market.
Interoperability the ability of devices to work together relies on products and services complying
with standards.
Business benefits standardization provides a solid foundation upon which to develop new
technologies and to enhance existing practices. Specifically standards:
Open up market access
Provide economies of scale
Encourage innovation
Increase awareness of technical developments and initiatives
27 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Consumer choice - standards provide the foundation for new features and options, thus
contributing to the enhancement of our daily lives. Mass production based on standards provides
a greater variety of accessible products to consumers.
[Source: ETSI]
A particular case of standard is interface standard. This specifies requirements concerned with the
compatibility of products or systems at their points of interconnection [Source: ISO/IEC GUIDE
2:2004] Therefore, two systems with the same standard interface (standard protocol) could be not
compatible. To be so, the two systems must adopt the same options: same profile (companion
standard) Example: IEC 60870-5-101 permits 8bits or 7 bits for data transmissions: Company XXXX
(where XXXX means any company name) profile specifies 8 bits Profile Company XX: 8 bits
Communication protocol/protocol: Set of rules for data transmission in a system interlinking several
participants. A protocol may define the conditions for establishing a connection to a transmission
medium, the rules governing access to the medium, the procedures for error protection, the
functional and procedural means of data exchange, the transport mechanisms, the communication
control, and the representation of data and the exchange of application data. Protocols define, for
example:
Data units transferred between participants
The meaning of data units (semantics)
The format of data units (syntax)
The logic time sequence of data exchange
The protocols used in a system may be organized in accordance with the OSI/ISO seven-layer
reference model, for example. Examples: IEC 60870-5-101 is a standard that defines a serial protocol
between Control Centre and RTU. [Source: IEC 60050-351:2006]
The most relevant factors over which the use of standards will have impacts (Table 4 and Table 5) are
described as follows:
Interoperability: The capability to communicate, execute programs, or transfer data among various
functional units in a manner that requires the user to have little or no knowledge of the unique
characteristics of those units [Source: ISO/IEC 2382-01, Information Technology]
The ability of two or more systems or components to exchange information and to use the
information that has been exchanged. [Source: IEEE Standard Computer Dictionary: A Compilation of
IEEE Standard Computer Glossaries (New York, NY: 1990)]. The communication must be standardised
Compatibility: Suitability of products, processes or services for use together under specific conditions
to fulfil relevant requirements without causing unacceptable interactions [Source: ISO/IEC GUIDE
2:2004] It is possible to distinguish compatibility among different aspects, for example:
Compatibility between devices or functions
28 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Interchangeability: Ability of one product, process or service to be used in place of another to fulfil
the same requirements. NOTE: The functional aspect of interchangeability is called functional
interchangeability, and the dimensional aspect dimensional interchangeability. [Source: ISO/IEC
GUIDE 2:2004] For example:
Meter provided by different manufacturers
Same function
Mechanically compatible
Fault detection function provided by different developers
Same function
Same operating system
Similar use of computing resources
Scalability: It can be defined as the ability of a solution to change its scale in order to meet growing
volumes of demand (e.g. increasing the number of elements interacting in the system). A system is
understood as a set of interacting elements with similar boundary conditions [38][39].
Replicability: It denotes the characteristic of a solution to be duplicated at another location, time and
under different operating conditions (e.g. duplicating a system somewhere else) [38][39].
29 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
30 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Finally, a Gap Analysis is performed in chapter 5 based on both the collected information described
previously and a complete set of documents that define in detail most of the identified protocols. This is
a key step to fulfil the task objectives. The methodology applied here has relied on :
Requesting documentation that details each protocol identified to the demonstrators.
Asking questions to partners. This even can motivate future bilateral meetings between protocol
experts within the project consortium.
The objective of the Gap Analysis is to identify important aspects regarding the use of protocols and
equipment. It is aimed at answering questions such as: Do the demonstrators expect using different
protocols/equipment for the same purpose? Are they standards or proprietary solutions?, Are the
proposed or evaluated extensions already covered by some standards? and are there alternatives to be
proposed to increase the use of standard in the demos?. Then, the main purpose is to make demos
evaluate these alternatives and suggestions in case they can support demos in the decision taken
process.
Figure 6 summarises the complete methodology in D1.3. It is possible to identify which part is covered
by each chapter of the document. It is worth mentioning that the conclusion obtained from this
document it is intended to be used as reference by each demonstrator. However there are not
constraints from them to use or change neither protocols nor equipment accordingly. Once the demos
are finished the D1.3 proposed composition will be compared with the information derived from the
final implementation. This will be done in other WPs, for example WP8 - Monitoring & Impact
Assessment of Project Demonstrations.
31 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Chapter 5 & 6
FIGURE 6: COMPLETE METHODOLOGY APPLIED IN D1.3
32 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
This chapter provides an overview of how demonstrators are approaching the use of standards for
protocols and equipment in the subfunctionalities identified in D1.1 - Report on Technical Specifications
[1]. The following subsections contain the information received from the four demonstrators promoters
based on the Table 2, Table 3 and questions presented in Chapter 2.
Table 6 presents the classification of the most relevant protocols identified by the Spanish demonstrator
based on the implementations identified in D1.1 [1]; while Table 7 aims to the same purpose but
focused on equipment.
33 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
34 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
35 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
3.1.1 PROTOCOLS
Table 8 presents the main protocols used in each of the subfunctionalities identified in D1.1 [1] for the
Spanish demonstrator.
DLMS/COSEM DLMS/COSEM is an open international standard for exchanging energy data between
energy meters and other systems. It has been developed at the end of the 1990s by leading utilities
and meter manufacturers with the objective to provide data exchange in a standard, interoperable,
and manufacturer independent way, over a range of communication media.
An object model, to view the functionality of the meter, as it is seen at its interface(s)
An identification system for all metering data
A messaging method to communicate with the model and to turn the data to a series of bytes
A transporting method to carry the information between the metering equipment and the data
collection system
PRIME (PoweRline Intelligent Metering Evolution) is the definition of the lower layers of a system to
provide an open, royalty and patent free solution, for physical and media access control layers,
together with certain convergence layers definition, for a narrowband PLC solution in CENELEC A
band in the low voltage part of the network. PRIME seeks interoperability for different vendors
equipment and systems. PRIME system ends at the transformer substation: from there to the control
centres, other communication technologies should be used as backbone connections.
STG-DC (STG-DC stands for Sistema de Telegestin Data Concentrator) is a protocol to define the
information exchange between the AMI Head End and Meter Data Aggregator (installed in the
secondary substations). It is a web services protocol based on SOAP and it defines methods and data
format to be transmitted in both directions. The AMI Head End must be able to manage, configure
and extract all the information from Meter Data Aggregator. It controls all the requirements of Meter
Data Aggregator including those LV Supervisors (traditional and advanced) connected to them.
It has been developed by Iberdrola within the framework of the national rollout of SMs determined
by law. Based on the corresponding Royal Decree, the party in charge of the metering has to
implement all the AMI systems to manage the SMs. These developments have to be authorised by
the competent administrations associated to the Government and Regulator. A version of this
36 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
protocol is at disposal of the PRIME Alliance members. Iberdrola is working on implementing new
functionalities (e.g. LV advanced supervision).
PRIME Alliance defines a multi-serve PLC communications protocol where AMI is covered within
smart metering profile. This profile supports all layers involved in the metering data management
(SMs scattered over the LV grid and meters inside the SS). Therefore communication between the
AMI head end (STG) and the data Concentrators (at the SS) is also maintained, in PRIME WAN Task
Force.
ICCP / TASE2: Integration of the demo LV management pilot system to the existing operational and
central control system. Specific SCADA values that are relevant to the LV Management system can be
transferred from the operational system to the pilot system, without disturbance and change to the
operational system. D3 - Integration of the MV power transformer status from the MV systems to the
new LV system.
IEC 104: Communication of the available field devices with the pilot LV management system. This
protocol leverages IP based communication along available physical communication lines available
for sub-functionalities Improvement the LV Network Management System visualisation by
integrating data measurements from inside SS (e.g. transformer meter, advanced LV supervision)
(D7.3) and Improvement the LV Network Management System visualisation by integrating data
measurements from LV network devices (e.g. customers SM, EV charging points, DER) (D7.4)
The IEC 60870-5-104 describes a commonly accepted and widely used SCADA protocol interface.
Most devices and SCADA systems are able to communicate via the defined protocol, therefore the
use this protocol was defined and chosen as the first option. If several SCADA protocols have to be
configured and to be maintained in the demo, the efforts are increased to set up the systems.
CIM: The network model managed and maintained for planning and network design purposes in the
GIS, is transferred and migrated to the operational LV management system. Updates to the normal
state of the network model (connectivity, geography & attribution) should be mastered by the GIS
system and incorporated into the operational system, where the current state of the network is
managed. SCADA point configuration is currently excluded from this integration. D4 - Define a sound
LV network model (schematic diagrams and parameters of components). D4 - CIM used for LV
network modelling and connection with the GIS model.
In case of CIM (IEC 61968, IEC 61970, IEC 62325), the data exchange between GIS and the DMS
requires a high level of data consistency between the two network models. As well a frequent and
fluent update process needs to be envisaged to enable a seamless end-to-end planning and
commissioning processes between the two domains. The description of the network model and the
corresponding components to be exchanged between GIS and the operational system, are modelled
in a CIM profile. This profile is used to control according software interfaces to extract relevant
network components out of the GIS and to provide those as XML based data files, aligned with the
37 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
defined CIM profile, to the LV management system. An according interface is available as a standard
product and will be used as a baseline for implementation of the demo. The description of the
network model and the corresponding components to be exchanged, can be modelled in a CIM
aligned XML format and an according interface is available as a standard product and should
therefore be used to streamline implementation of the demo.
PRIME: Deployment of a multiservice and manageable PRIME subnetwork is one of the objectives of
this demo. This implies using PRIME technology to create a telecommunications network over the LV
electricity grid. This would allow the integration of LV grid remote control operation over Smart
Metering PRIME infrastructure and it involves all the activities required to deploy LV remote control
applications over the existing LV Smart Metering PRIME technology.
Evaluation of PRIME subnetworks capacity:
This analysis requires the definition of a management protocol of PRIME devices (PRIME MIB
definition over SNMP standard protocol). Development of PRIME subnetworks analysis tools
that make use of the data provided by Base Nodes.
PRIME standard evolution proposal:
Once the capacity is evaluated a base node solution that supports multiple applications would
be developed. The Development, Test and Standardization process of PRIME LV control and
operation profile is needed.
The proposal of a new profile for remote control over PRIME would be done to the PRIME Alliance.
This will allow PRIME standard evolution.
Web services SOAP (Simple Object Access protocol), is a protocol specification for exchanging
structured information in the implementation of web services in computer networks. It uses XML for
its message format, and relies on Hypertext Transfer Protocol (HTTP) for message negotiation and
transmission.
SNMP Simple Network Management Protocol (SNMP) is a set of protocols for network management
and monitoring. These protocols are supported by many typical network components and devices.
Supported devices are all network-attached items that must be monitored to detect conditions.
These conditions must be addressed for proper, appropriate and ongoing network administration.
38 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
SNMP standards include an application layer protocol, a set of data objects and a methodology for
storing, manipulating and using data objects in a database schema.
In the scope of UPGRID project there is the specification of the implementation to be done regarding
SNMP. In terms of security, in WP3 there will be a first milestone with SNMPv2 and for the SNMPv3
evolution, there will be a definition of the privacy and authenticity protocols and mechanisms to be
used.
This demo aims to obtain and manage real time basis detailed, enriched and accurate representation
of the LV network (covering components, topology, status, operation, connectivity, performance,
loads and generation connected, etc.). This relies on the availability of SMs events in the systems.
These standards/interfaces will be analysed and could need to be evolved to ensure the optimization
of events availability.
DLMS Profile: Specific companion standard DLMS/COSEM profile for the demo is PRIME COSEM
Profile for Communication Interfaces. Version implemented for the demo is the latest available
(PRIME COSEM Profile for Communication Interfaces 1.06). This document provides a companion
standard for an Automatic Meter Reading (AMR) system for electricity meters. The scope of this
standard is on: Spanish Residential AMM T5 electricity meters.
Current implementation of event management regarding this COSEM Profile will be analysed. If the
demo shows the need, it is possible that some evolution of this companion is proposed.
The information exchange format between the remote management system and the data
concentrators to be used in the demo is defined in STG-DC specification. This interface is designed so
the system is able to manage, configure and request the information available in data concentrators
and SMs. Version implemented for the demo is the latest available STG-DC 3.2.
Current implementation and performance of event management regarding this web services based
interface will be analysed. If the demo shows the need, it is possible that some evolution of this
specification is proposed.
CIM: A GIS and DMS with proper CIM support needs to be applied. The CIM model needs to be
defined and validated against the existing network model and corresponding components quality
checks against the GIS data have to be set up and data correction/improvements have to be carried
out. A particular CIM profile was created to support LV components of the distribution domain. GE
has defined its own profile for Distribution CIM, based on the standard CDPSM (Common Distribution
Power System Model) profile.
39 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 8: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE SPANISH DEMONSTRATOR
Cluster, Function Objectives & Subfunctionalities Main protocols
D7.1 Operation (control and multiservice) of LV grid devices using PLC-PRIME for different IEC 60870-5-104 over PLC-PRIME from LV SCADA to field devices
telecontrol applications (Concept test)
D7.2 Queries to request advanced meter data to support operation PRIME, IEC 60870-5-104 from MDM/head end to LV DMS or STG-
DC (SOAP/XML) with proprietary content
D7.3 Improvement the LV Network Management System visualisation by integrating data PRIME, PRIME, DLMS COSEM, STG-DC, IEC 60870-5-104 from RTU
measurements from inside SS (e.g. transformer meter, advanced LV supervision) to SCADA
Improvement the LV Network Management System visualisation by integrating data PRIME, PRIME, DLMS COSEM, STG-DC, IEC 60870-5-104 when
D7.4 measurements from LV network devices (e.g. customers SM, EV charging points, DER) possible SOAP/XML with proprietary content or CIM otherwise
Integration of the MV power transformer status from the MV systems to the LV Network ICCP / TASE.2 from MV SCADA to LV SCADA or
D7.5 Management System proprietary database interface
Integration of measurement data to support power flow analyses in LV Network LV DMS internal, no protocol involved assumed that
D7.7 Management System measurements are available in LV SCADA.
D9.1 Define a sound LV network (schematic diagrams and parameters of components) Not applicable to protocols. This is a process to be carried out in
the LV DMS.
D9.2 Use CIM for LV network modelling and data exchange between e.g. AMI, GIS, MV SCADA, LV CIM is supported in Network information / Asset Management
Network Management System System (NIS/AMIS) has well as in LV SCADA/ADMS
D9.3 Interface to manage PRIME subnetwork with Simple Network Management Protocol (SNMP) PRIME, SNMP
D9.5 Visualisation of data from LV Management Network System in a geographical context Not applicable to protocols. This is a process to be carried out in
the LV DMS.
40 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
D9.6 Internal DSO business processes review in relation with Outage Management Not applicable to protocols. This is a process to be carried out in
the LV DMS.
D10.1 Integration and processing of meter events or/and other sources (e.g. telecom data) in the PRIME, DLMS COSEM, IEC 60870-5-104 from MDM/head end to
Outage Management System (OMS) LV DMS or STG-DC (SOAP/XML) with proprietary content
D10.3 Algorithm to determine connectivity of SM to the grid (identification of phase and line to PRIME
which each SM is connected to)
D11.1 Data analytics based on historical network state data to assist network planning Not applicable to protocols. This is a process to be carried out in
the LV DMS.
D12.1 Data analytics based on historical network state data to assist maintenance Not applicable to protocols. This is a process to be carried out in
the LV DMS.
D12.4 Deploy some mobile devices (e.g. tablet, smart phone) for accessing and visualise remotely SOAP/XML over HTTPS via GPRS/UMTS with proprietary content
information from LV system (e.g. geographical context, assets and outage location) to it needs to be developed/defined in the project.
support
grid crews
D13.1 Web portal for increasing the consumer awareness in order to leverage their participation N/A
in electricity markets
41 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
3.1.2 EQUIPMENT
FIGURE 7: ARCHITECTURE FOR SUB-FUNCTIONALITIES IN THE SPANISH DEMONSTRATION DEALING WITH THE DATA
METERING ACQUISITION FROM FIELD (SOURCE: ZIV)
42 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
FIGURE 8: LIST OF EQUIPMENT USED IN THE SPANISH DEMONSTRATION INDICATING LOCATIONS AND PROTOCOLS FOR
SUB-FUNCTIONALITIES DEALING WITH METERING DATA ACQUISITION FROM FIELD (SOURCE: ZIV)
PRIME SM:
Single phase meters cover the metrological needs of the residential market, providing automated
meter reading (AMR) solutions to the distribution companies, based on a modular platform. This
modular concept allows the use of SMs in clients that only require energy metering functions as well
as in those requiring time of use (TOU) and/or load profile functionality in the de-regulated electric
market. The SMs incorporates a bidirectional PLC modem PRIME compatible (power line carrier)
through the low voltage network for remote reading application.
Smart meters provides the following measurements (e.g. the 5CTM model provided by ZIV that is
one the SMs used in the demonstration area)
Current with a reference value 5 A and maximum value up to 80A.
Voltage with an extended range between 127 and 230 Vac (20%).
Active power (bidirectional) and reactive in 4 quadrants.
Active energy (bidirectional) and reactive in 4 quadrants.
Instantaneous power factor.
43 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
The SMs are configured following the DLMS communication protocol and following the objects
described in the document Companion standards for communication interfaces (PRIME COSEM
Profile for communication interfaces version 1.06). This companion describes the set of events to be
stored and reported from the SMs. There are six groups of events. Some of them have subgroups.
Each group or subgroup has its own event log, i.e., seven event logs. This is shown Table 9. Every
event has a unique code to identify the action which has triggered it. Every event is assigned to one
event log and it is only stored there. This assignment is fixed and cant be changed dynamically.
TABLE 9: GROUPS AND SUB-GROUP OF EVENTS DESCRIBED BY THE COMPANION STANDARDS FOR SMS
Detailed event analysis will be done with ZIV SMs although other meters are installed in the field.
Data Concentrators:
This device is a communications concentrator which forms part of a remote management system
with automatic meter reading (AMR) through the actual low voltage network (Power Line
Communication or PLC). This system is comprised of:
44 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
A metering subsystem consisting of a set of single-phase meters (residential use) and three-phase
meters (industrial and commercial use) with low voltage network communication through the A
band (CENELEC) reserved for the exclusive use of the utilities and using PRIME technology (PRIME
Alliance Technical Working Group, PRIME Specification version 1.3.6 (Nov 2011.
http://www.prime-alliance.org, accessed on July 2012).
The concentrator devices located in the transformation stations (the equipment being described in
this point).
LV supervision system. This is a three-phase meter which can be connected to the concentrator via
RS485 port (external), or as an added function within the concentrator (internal). The internal Low
Voltage supervisor is also described in this manual.
Remote management system: Meter reading and management system from the distributor's
management system.
The architecture is based in a distributed network where multiple secondary substations will be
managed (red boxes in the Figure 9) from the system and the information needs to be obtained
remotely.
Secondary
Substations
Meter rooms
Going into the detail of the elements. In the secondary substation (red box in Figure 10) there is one
Data Concentrator that automatically reads the meters under it. These meters are installed in meter
rooms (green box in Figure 10) within the Low Voltage network and communicate with the Data
Concentrator using this LV network as a communication channel, with PRIME PLC protocol.
45 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
FIGURE 10: DISTRIBUTED NETWORK, ELEMENTS (DATA CONCENTRATOR IN RED WHILE SMS IN GREEN) (SOURCE: ZIV. THE
IMAGE SHOWS THE DATA CONCENTRATOR MODEL 4CCT AND SMS MODEL 5CTM)
These devices store and manage specific events for LV grid management:
Blown fuse indication per phase
Over-current (programmable threshold)
General events (power failure, voltage sags, synchronisation, current unbalance, over-current..)
Equipment for other manufacture (Meritronic) is installed in the Spanish demonstration area.
46 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Neither SMs nor Advanced LV supervisor will be installed within UPGRID project.
47 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Table 10 presents the classification of the most relevant protocols identified by the Portuguese
demonstrator based on the implementations identified in D1.1 [1]; while Table 11 aims to the same
purpose but focused on equipment.
48 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 10: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE PORTUGUESE DEMONSTRATOR
49 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
DLMS/COSEM DLMS/COSEM
DLMS UA 1000-1: Blue book, COSEM Identification System and DLMS UA 1000-1: Blue book, COSEM Identification System and
Interface Classes, 12th Edition Interface Classes, 12th Edition
DLMS UA 1000-2: Green book, DLMS/COSEM Architecture and DLMS UA 1000-2: Green book, DLMS/COSEM Architecture and
Protocols, 8th Edition Protocols, 8th Edition
IEC 62056-42: Electricity metering Data exchange for meter IEC 62056-42: Electricity metering Data exchange for meter
reading, tariff and load control - Part 42: Physical reading, tariff and load control - Part 42: Physical
IEC 62056-46: Electricity metering Data exchange for meter IEC 62056-46: Electricity metering Data exchange for meter
reading, tariff and load control Part 46: HDLC reading, tariff and load control Part 46: HDLC
IEC 62056-47: Electricity metering Data exchange for meter IEC 62056-47: Electricity metering Data exchange for meter
reading, tariff and load control Part 47: COSEM transport layer reading, tariff and load control Part 47: COSEM transport layer
for IP networks (Wrapper for GPRS SMs) for IP networks (Wrapper for GPRS SMs)
IEC 62056-53: Electricity metering Data exchange for meter IEC 62056-53: Electricity metering Data exchange for meter
reading, tariff and load control Part 53: COSEM application reading, tariff and load control Part 53: COSEM application
layer layer
IEC 62056-62: Electricity metering Data exchange for meter IEC 62056-62: Electricity metering Data exchange for meter
reading, tariff and load control Part 61: Object identification reading, tariff and load control Part 61: Object identification
system (OBIS) system (OBIS)
EDP Box data model EDP companion for DLMS/COSEM EDP Box data model EDP companion for DLMS/COSEM
Web services SOAP (STG-DC 3.1.c) Web services SOAP (STG-DC 3.1.c)
Central System DTC interface based on DC INTERFACE Central System DTC interface based on DC INTERFACE
SPECIFICATION , v3.1.c, authored by Iberdrola but currently SPECIFICATION , v3.1.c, authored by Iberdrola but currently
under the responsibility of the Prime Alliance under the responsibility of the Prime Alliance
EDP profile with specific Orders (Bnn) and Reports (Snn) - EDP profile with specific Orders (Bnn) and Reports (Snn) -
WS_STG.DTC_perfil.EDP_v5.13 WS_STG.DTC_perfil.EDP_v5.13
FTP (RFC959) FTP (RFC959)
50 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 11: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE PORTUGUESE DEMONSTRATOR
51 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
3.2.1 PROTOCOLS
Table 12 presents the main protocols used in each of the subfunctionalities identified in D1.1 [1] for the
Portuguese demonstrator.
IEC 60870-5-104
IEC 60870 part 5 is one of the IEC 60870 set of standards which define systems used for telecontrol
(supervisory control and data acquisition) in electrical engineering and power system automation
applications. The IEC Technical Committee 57 (Working Group 03) developed a protocol standard for
telecontrol, teleprotection, and associated telecommunications for electric power systems. The IEC
Technical Committee 57 has also generated companion standards, one of them is IEC 60870-5-104
Transmission Protocols, Network access for IEC 60870-5-101 using standard transport profiles.
EDP-Energias de Portugal PID 104 represents the current minimum requirements for an IEC 60870-5-
104 system. The PID presents sets of parameters and alternatives from which subsets must be
selected to implement particular telecontrol systems.
PRIME (PoweRline Intelligent Metering Evolution) is the definition of the lower layers of a system to
provide an open, royalty and patent free solution, for physical and media access control layers,
together with certain convergence layers definition, for a narrowband PLC solution in CENELEC A
band in the low voltage part of the network. PRIME seeks interoperability for different vendors
equipment and systems. PRIME system ends at the transformer substation: from there to the control
centres, other communication technologies should be used as backbone connections.
DLMS/COSEM is an open international standard for data exchange with utility meters measuring any
kind of energy, more generally, with intelligent devices. It has been developed at the end of the
1990s by leading utilities and meter manufacturers with the objective to provide a means for meter
data exchange in a standard, interoperable, energy type and manufacturer independent way, over a
range of communication media.
Web services SOAP (Simple Object Access protocol), is a protocol specification for exchanging
structured information in the implementation of web services in computer networks. It uses XML for
its message format, and relies on Hypertext Transfer Protocol (HTTP) for message negotiation and
transmission.
52 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
STG-DC 3.1.c (STG-DC stands for Sistema de Telegestin Data Concentrator) is a protocol to define
the interchange of information between the AMI Head End and Meter Data Aggregator (installed in
the secondary substations). It defines functionalities in both directions. The AMI Head End must be
able to manage, configure and extract all the information from Meter Data Aggregator. That is,
controlling all the requirements of Meter Data Aggregator including those LV Supervisors (traditional
and advanced) connected to them.
EDP is using a profile with specific Orders (Bnn) and Reports (Snn) named
WS_STG.DTC_perfil.EDP_v5.13.
FTP (File Transfer Protocol): RFC959 is a standard network protocol used to transfer computer files
from one host to another host over a TCP-based network, such as the Internet. FTP is built on a
client-server architecture and uses separate control and data connections between the client and the
server. FTP users may authenticate themselves using a clear-text sign-in protocol, normally in the
form of a username and password, but can connect anonymously if the server is configured to allow
it. For secure transmission that protects the username and password, and encrypts the content, FTP
is often secured with SSL/TLS (FTPS) [25].
All the protocols description can be found in the previous section. The protocols were selected based on
EDP Distribuio practical experience in InovGrid project.
53 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 12: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE PORTUGUESE DEMONSTRATOR
Cluster, Function Objectives & Subfunctionalities Main protocols
D1.2 Home Energy management system to provide data to dynamic pricing simulator MODBUS
D1.3 End user engagement to improve distribution network operation Web services SOAP (STG-DC 3.1.c)
D6.1 Consumption characterisation of Electrical Vehicle (EV) charging points (street stations) PRIME, DLMS/COSEM, Web services SOAP (STG-
DC 3.1.c)
D7.3 Improvement the LV Network Management System visualisation by integrating data measurements from inside SS Web services SOAP (STG-DC 3.1.c)
(e.g. transformer meter, advanced LV supervision)
D7.4 Improvement the LV Network Management System visualisation by integrating data measurements from LV PRIME, DLMS/COSEM, Web services SOAP (STG-
network DC 3.1.c)
devices (e.g. customers SM, EV charging points, DER)
D7.5 Integration of measurement data to support state estimation in LV Network Management System N/A
D7.6 Integration of measurement data to support power flow analyses in LV Network Management System N/A
54 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
D7.10 LV meshed network operation - Remote reconfiguration (no fully automatic) of the LV network (grid protection) Web services SOAP (STG-DC 3.1.c)
D7.11 LV meshed network operation - identifying the optimum topological configuration N/A
D9.2 Use CIM for LV network modelling and data exchange between e.g. AMI, GIS, MV SCADA, LV Network Management CIM is supported in Network information / Asset
System Management System (NIS/AMIS) has well as in
LV SCADA/ADMS
D9.4 Implementation of Network Management System (NMS) based on Simple Network Management Protocol (SNMP) SNMP
at SS level
D9.5 Visualisation of data from LV Management Network System in a geographical context N/A
D10.1 Integration and processing of meter events or/and other sources (e.g. telecom data) in the Outage Management PRIME, DLMS/COSEM, Web services SOAP (STG-
System (OMS) DC 3.1.c)
D10.2 Calculation of indicators for SM infrastructure e.g. the availability-KPI indicators to be used in a geographical N/A
context the to assist the Network Operation Centre (NOC)
D10.3 Algorithm to determine connectivity of SM to the grid (identification of phase and line to which each SM is PRIME, DLMS/COSEM, Web services SOAP (STG-
connected to) DC 3.1.c)
D10.4 Calculation of non-technical losses using data from metering devices both in SS and LV network PRIME, DLMS/COSEM, Web services SOAP (STG-
DC 3.1.c)
D12.4 Deploy some mobile devices (e.g. tablet, smart phone) for accessing and visualise remotely information from LV N/A
system (e.g. geographical context, assets and outage location) to support grid crews
55 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
D13.1 Web portal for increasing the consumer awareness in order to leverage their participation in electricity markets N/A
D13.2 Create market hub for relationship between DSO and Suppliers N/A
D13.3 Dynamic / Real time pricing based on DSO services and infrastructure (DSM) (simulator) N/A
56 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
3.2.2 EQUIPMENT
The main equipment used in the Portuguese demonstrator and classified in Table 11 is depicted in
Figure 11.
This architecture allows to integrate, in a global solution, different type of devices from different
manufacturers:
Secondary substation:
Legacy meter: meter with RS232 interface and previous data model based on DLMS/COSEM
(transformer measurements).
EDP Box (public lighting): new generation of SM for control of public lighting purposes
(astronomical watch integrated and controllable outputs) and also remote data collection
(billing, profiling ).
DTC: Distribution Transformer Controller acts like a data concentrator but also allow monitoring
and managing the LV network.
2G/3G router: communication interface
SMs based on 2 technologies (PLC PRIME and GPRS) from different vendors
Central Systems to manage, commercially (AMR, AMI and Client portal) and technically (NMS,
SCADA), all infrastructure.
57 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
58 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
59 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
60 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
No equipment added under this category for D1.3 purposed. However, for the HEMS solution the
Portuguese demo still need to evaluate and decide some implementation details (depending on
different interaction with other internal systems and other eventual limitations). The quantity of devices
that will be installed also depends on the DER available and the final user engagement. For this reason
the Portuguese demo has not included this device in this category for evaluation.
61 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Table 13 presents the classification of the most relevant protocols identified by the Swedish
demonstrator based on the implementations identified in D1.1 [1]; while Table 14 aims to the same
purpose but focused on equipment.
62 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 13: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE SWEDISH DEMONSTRATOR
63 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
GPRS/3G - Communication between the field installed IED, e.g. DC, GPRS/3G/CDMA
and telecommunication service provider hardware environment
IEC-60870-5-104 - Communication between FPI and SCADA-DMS
and/or fault analysis tool in MV substation
IEC-60870-5-104 - Communication between secondary substation
(10-20/0.4 kV) and SCADA-DMS
DNP3 (IEEE Std. 1815) - Distributed Network Protocol might be
used by one RTU manufacturer, while -104 implementation is
finalized
ZigBee (IEEE 802.15.4) - Communication between wireless current
sensor and RTU
CIM - Common Information Model for data exchange between
Network Information System and LV SCADA
FTP (RFC959) over GPRS
Development of new protocols / Development of extensions to a
Used proprietary protocols standard protocol / protocol profiles to be developed (and
Possible standardization process)
N/A N/A
64 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 14: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE SWEDISH DEMONSTRATOR
1
A re-closer/breaker is under discussions within the project to be included or not. This decision is partly dependent on IT security issues and the system set-up for the project
65 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
66 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
As described in D1.1 [1], the Swedish demonstration is focusing on a technical solution which will test
and evaluate interoperability between equipment in field and overlying system platforms. The
demonstrator will use a new LV SCADA-DMS as well as work towards existing MV SCADA-DMS, Asset
Management / Network Information System (NIS) and AMI Head End system. The ambition is also to
install LV network measuring equipment and RTU from several manufacturers and integrate information
from them into LV Monitoring and SCADA-DMS. For the MV network, the WP5 - Demonstration 3 in real
User Environment: VTF - Sweden initial ambition is to demonstrate MV network sensors for fault
identification and localisation, as well as to test a Smart Transformer, for LV network voltage control.
Existing SMs will also provide to other systems readings and events from the LV customers connected to
the MV/LV substations within the scope of the demonstrator.
The demonstration will include several manufacturers. The work to define the exact devices to be
included in the demonstration is planned to continue during most of 2015, with the ambition to have
final draft of equipment list ready for decision by October-November 2015. During this first year of the
project, Vattenfall and partners will discuss how to equip the demonstration with appropriate devices to
support the planned technical solution.
Figure 16 and Figure 17 illustrate the interfaces between the field equipment and overlying system
architecture and are complementary to the SGAM (Smart Grid Architectural Model) diagrams presented
in later figures.
Table 15 presents the main protocols used in each of the subfunctionalities identified in D1.1 [1].
Please note that for sub-functionality Life Cycle Cost (LCC) calculations of best technical, financial
solution with new equipment (e.g. IEDs) no direct or indirect match against any protocol can be made,
since this sub-function is a development in the Asset Management system application.
67 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
FIGURE 16: SIMPLIFIED DESCRIPTION OF STANDARDS USED FOR SM CONNECTION TO OVERLYING SYSTEM HIERARCHY
68 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
FIGURE 17: SIMPLIFIED DESCRIPTION OF STANDARD USED FOR MV NETWORK FPI AND LV NETWORK SECONDARY
SUBSTATION CONNECTION TO OVERLYING SYSTEM HIERARCHY
69 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 15: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE SWEDISH DEMONSTRATOR
Cluster, Function Objectives & Subfunctionalities Main protocols
D7.3 Improvement the LV Network Management System visualisation by integrating data measurements .104 over GPRS for SCADA/DMS, FTP over GPRS for LV
from inside SS (e.g. transformer meter, advanced LV supervision) monitoring Application.
ZigBee communication is between sensors and the RTU
at the substation, and the RTU would be the one using
IEC-104 to communicate the information towards the
SCADA and the LV Monitoring Application.
D7.4 Improvement the LV Network Management System visualisation by integrating data measurements GS2 and/or CIM from metering AMM/MDM head end
from LV network devices (e.g. customers SM, EV charging points, DER) .104 from RTU with sensors
D7.7 Integration of measurement data to support power flow analyses in LV Network Management System GS2 and/or CIM from metering AMM/MDM head end
.104 from RTU with sensors
D7.9 LV regulation at SS level using a new smart transformer .104 with the SCADA
D7.12 Interoperability test of the integration of LV Network Management System with equipment from .104 (DNP3 may be used for one RTU, instead of
different manufactures upcoming 104 implementation)
D9.1 Define a sound LV network (schematic diagrams and parameters of components) Not applicable to protocols. This is a process to be
carried out in the LV DMS.
D9.2 Use CIM for LV network modelling and data exchange between e.g. AMI, GIS, MV SCADA, LV Network CIM is supported in Network information / Asset
Management System Management System (NIS/AMIS) has well as in LV
SCADA/ADMS
70 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
D10.1 Integration and processing of meter events or/and other sources (e.g. telecom data) in the Outage OSGP and GS2
Management System (OMS)
D10.3 Algorithm to determine connectivity of SM to the grid (identification of phase and line to which each Not applicable to protocols. This is a process to be
SM is connected to) carried out in the LV Monitoring Application.
D10.4 Calculation of non-technical losses using data from metering devices both in SS and LV network MDM head end and LV Monitoring Application internal
functions (no communication with other applications)
D12.3 Life Cycle Cost (LCC) calculations of best technical / financial solution with new equipment (e.g. IED) N/A internal NIS application
71 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
It is worth mentioning that the Swedish demonstrator has used SGAM and standardised names of
components to present the information in this chapter. This can be used and evaluated, as reference for
the other demos, to get in contact with this tool (introduced in section 1.1 of the present document).
This is an important synergy to facilitate the knowledge sharing among partners.
The SGAM (Smart Grid Architecture Model) aims to describe the infrastructure of the project, describing
the demonstrator contents in a common shape, and thus localize the standards which are used by the
demonstrator.
For a structured system description, the system will be mapped to the IEC/CENELEC Smart Grid
Architecture Model (SGAM). The system mapping is following the same path:
List of standards to be considered for interfacing within this system at component layer,
communication layer and information layer.
Reference to UPGRID Function objectives and sub-functionalities used at function level.
This layer localises power system equipment, monitoring and control devices, communication network
components and information system computers which together constitute the field implementation of
the project to describe the physical infrastructure of the Swedish demonstrator architecture. The system
component architecture for Smart Transformer, wireless current sensor, fault passage indicator and SM
are given in Figure 18.
72 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Market
Enterprise
NIS MDM
Operation
AMI
MV LV LV Head End
SCADA-DMS SCADA DMS
LV
Monitoring
Field
Fault Passage Wireless Smart
Indicator (FPI) Current Meter
Sensor
Re-closer Smart
/breaker Transformer
Process
MV LV
Network Information System (NIS): Application which maintains all information about the network
(assets).
Meter Data Management (MDMS): Application which maintains all information to be able to
calculate the energy bill for a customer based on the meter data retrieved from AMI head end(s).
AMI Head End: Application which acts as back-end for the metering communication and controls and
monitors the communication to the meter devices.
Meter Data Concentrator: Device in substation which establishes the communication to SMs to
collect the metered information and send it in concentrated form to an AMI head end.
SM: End devices on process and field level. Meters at customer premises.
73 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
LV Monitoring: Application based on the electrical measurements done at the secondary substation
on all low voltage feeders, and on LV customer premises in order to perform analysis functions
related to network planning and optimization such non-technical losses, LV topology identification,
load transformer analysis, harmonics, feeder/ phase unbalances, etc. There are no real-time
information requirements.
LV SCADA-DMS: Application based on the electrical measurements done at the substation on all low
voltage feeders, providing information to improve the asset management and the quality of supply
and an optimized visualization. SCADA/DMS systems are used for control and operation purposes,
and they have real-time information requirements.
RTU /IED: Device for Switchgear control and monitor, power measurement and quality and fault
detection in MV/LV Substation.
Wireless Current Sensor: Device designed to measure currents and voltages downstream
distributions tables equipping the MV / LV substations. For measuring currents, it is a wireless
product, without contact, without battery.
Fault Passage Indicator: Device that measures the current at their actual location using CTs and can
determine the direction to the fault. Most FPI measure both current and voltage to detect an earth
fault, but trials is ongoing at Vattenfall with FPIs requiring only current measurement. It requires a
modem for wireless communication.
Smart Transformer: Electric energy converter that changes voltages and currents and solves the
problem of voltage fluctuation using a serial transformer working together with the conventional
active part, a set of low-current LV contactors and a PLC to control operations.
The communication layer describes protocols and mechanism used by the demonstrator infrastructure
to exchange data. This layer represents the how (how the data is transported between systems). This
layer aims at identify communication protocols used to carry information and to perform use cases
described before.
74 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Market
Enterprise
NIS MDM
CIM
CIM
Integration Bus W3C Web Services ?
over networks IP based
Operation
AMI
MV LV LV Head End
SCADA-DMS SCADA DMS
4
-5-10
LV
Over
PR
IEC 6
Monitoring
rG
IEC 60870-5-104
ove
over GPRS
Meter Data
FTP
Station
RTU / FPI Concentrator
O
ove SGP
over 5.4
802.1
r P ETS
LC I G
ETS S O
Zigbe
I TS S G
10 001
39
e
08 Field
Fault Passage Wireless Smart
Indicator (FPI) Current Meter
Sensor
Re-closer Smart
/breaker Transformer
Process
MV LV
For drawing the communication layer of the system we have differentiated two parts:
Communication technologies and medias corresponding more to OSI layers 1 to 4
Associated standard communication protocols mostly focuses on application layers (layer 5 to 7 of
the OSI model)
The standard technologies and media used for communication links are:
Ethernet (IEEE 802.3): The IEEE 802.3 standard fall within the first two layers of the ISO/OSI model.
The newest form of Ethernet is the 100 Gb/s category. This technology is functionally similar to the
10 and 100 Mb/s technologies, but has a main difference: the transmission medium for 100 Gb/s
Ethernet is the optical fiber cable. This standard is based on the Carrier Sense Multiple Access with
75 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Collision Detection (CSMA/CD) in which all the devices connected to the network have access to the
transmission medium and can send and receive data whenever the network is idle.
Power Line Communications (PLC): PLC is a technology which consists of building the access network
over the infrastructure of the LV and MV network. ETSI TS 103 908 is high-performance narrow band
power line (PL). CENELEC A-band-compliant power line communication with built-in coupling circuit
complies with ETSI TS 103 908 Power Line Telecommunications (PLT) BPSK Narrow Band Power Line
Channel for Smart Metering Applications. For the Swedish demonstrator, PLC will be used only in the
LV network.
ZigBee (IEEE 802.15.4): ZigBee is a radio technology for low-cost wireless links with reduced energy
consumption. It is therefore particularly adapted to in-house electronic appliances. This technology
allows short-range transfer (2,5 MHz, 16 channels) at relatively low rates (250 kbit/s at a maximum
distance 100 m). The ZigBee technology is maintained by the ZigBee Alliance.
General Packet Radio Service (GPRS): GPRS is an ETSI Standard that adds packet-switched
functionality to GSM, which is essentially circuit switched. It offers faster data rates than GSM
reaching a theoretical data rate of 171 kbit/s that in practice is about 30/40 kbit/s. However the
transmission speed is calculated according to the coding scheme and the capacity of each time slot
(kbit/ts). The introduction of 2.5 mobile generation, called Enhanced Data rates for Global Evolution,
has increased the data rate up to 384 kbit/s.
IEC-60870-5-104: IEC 60870 part 5 is one of the IEC 60870 set of standards which define systems used
for telecontrol (supervisory control and data acquisition) in electrical engineering and power system
automation applications. The IEC Technical Committee 57 (Working Group 03) have developed a
protocol standard for telecontrol, teleprotection, and associated telecommunications for electric
power systems. The IEC Technical Committee 57 has also generated companion standards, one of
them is IEC 60870-5-104 Transmission Protocols, Network access for IEC 60870-5-101 using standard
transport profiles.
W3C Web Services: Web Services are realized as software applications communicating with each
other by using XML interfaces. The Web Services Architecture has three key roles:
Service broker
Service provider
Service consumer
Service brokers are the managing part of the system. They are realized as servers. Service providers
deliver information to the service brokers in order to make them consumable. Service consumers
query the service broker database in order to find appropriate services that fulfil requesters
requirements and quality of service.
76 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
File Transfer Protocol (FTP): RFC959 is a standard network protocol used to transfer computer files
from one host to another host over a TCP-based network, such as the Internet. FTP is built on a
client-server architecture and uses separate control and data connections between the client and the
server. FTP users may authenticate themselves using a clear-text sign-in protocol, normally in the
form of a username and password, but can connect anonymously if the server is configured to allow
it. For secure transmission that protects the username and password, and encrypts the content, FTP
is often secured with SSL/TLS (FTPS) [25].
Open Smart Grid Protocol (OSGP): The OSGP application specification, ETSI GS OSG 001, is available
from European Telecommunications Standards Institute (ETSI). OSGP enables the development of
interoperable SMs and other smart grid devices by multiple vendors. At the Physical Layer, OSGP
currently uses ETSI TS 103 908 as its power line communication standard; however the OSGP
application layer (ETSI GS OSG 001) is independent of the physical layer, so it is not tied to a specific
communications medium. For the Networking Layer, OSGP uses ISO/IEC14908-1. For the data model,
OSGP adapts the IEEE 1377 and the ANSI C 12 table structure for a networking protocol, and adds
extensions for security, authentication, and encryption.
The information layer describes the information objects and the data models required by use cases sub-
functionalities and services. This layer represents the what (what are the information exchanged
between systems).
77 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Market
Enterprise
NIS MDM
SINTEF GS2
Data Model
Operation
AMI
MV LV LV Head End
SCADA-DMS SCADA DMS
OSGP based on
IEEE 1377 and
ANSI C12
LV
Monitoring
IEE OSG
E1 P b
37
7 a ased
nd o
AN n
SI C Field
Fault Passage Wireless 12 Smart
Indicator (FPI) Current Meter
Sensor
Re-closer Smart
/breaker Transformer
Process
MV LV
Open Smart Grid Protocol (OSGP): The OSGP application specification, ETSI GS OSG 001, is available
from European Telecommunications Standards Institute (ETSI). For the data model, OSGP adapts the
IEEE 1377 and the ANSI C 12 table structure for a networking protocol, not just for meters but for
other utility related devices as well and adds extensions for security, authentication, and encryption.
GS2: It is an object oriented data model for handling metering and settlement information. The GS2
format is developed at SINTEF Energy Research and was released in 1995.
78 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
CIM: The Common Information Model (CIM) is an open standard that defines how managed
elements in an IT environment are represented as a common set of objects and relationships
between them.
The function layer localises the use cases and sub-functionalities that the project infrastructure will be
able to perform. This layer maps the defined functions objectives and sub-functionalities in Swedish
UPGRID demonstration.
Market
Enterprise
NIS MDM
LV
Monitoring
Field
Fault Passage Wireless Smart
Indicator (FPI) Current Meter
Sensor
Re-closer Smart
/breaker Transformer
Process
MV LV
79 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
The list of system functions provided corresponds to the use case stated previously which are aligned
with the descriptive technical information collected in D1.1 [1]:
Smart metering data utilisation
Monitoring and Control of LV network
Automation and Control of MV network
Network management methodologies for network operation
Table 16 summarises the used standard protocol interfaces, i.e. in operation by Vattenfall Distribution
today which also will be used in the demonstration. For a mapping between Swedish demo sub-
functionalities and protocols see Table 15.
TABLE 16: SUMMARY OF STANDARD PROTOCOL INTERFACES USED IN THE SWEDISH DEMONSTRATOR
Information
Interface Description Sub-functionality
Layer Standard
SM -> Meter Data OSGP Open Smart Grid Protocol D7: Monitoring and Control of LV Networks
Concentrator (www.osgp.org/) D7.4 Improvement the LV Network
Management System Visualisation by
integrating data measurements from LV
network devices (e.g. customers SM, EV
charging points, DER)
D7.7 Integration of measurement data to
support power flow analysis in LV
Network Management System
D10: Smart metering Data Utilisation
D10.1 Integration and processing of
meter events or/and other sources (e.g.
telecom data) in Outage Management
System (OMS)
D10.3 Algorithm to determine
connectivity of SM to the grid
(identification of phase and line to which
each SM is connected to)
D10.4 Calculation of non-technical losses
using data from metering devices both in
SS and LV network
Meter Data OSGP See above, same as for the interface SM -> DC
Concentrator - >
AMI Head End
AMI Head End -> GS2 Object oriented data model. See above, same as for the interface SM ->
Meter Data XML GS2 file format for daily DC
Management measurement data (meter
System readings) and XML file format
for alarms and events
80 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
The demonstrator platform will be built around existing MV SCADA-DMS, a demo LV SCADA-DMS,
Asset Management / Network Information System (NIS) and AMI Head End systems. The SCADA is
from the turn of the millennium and uses IEC 61870-5-104 as preferred communication protocol.
Vattenfall began in 2002 deployment of automatic meter reading to its 860.000 customers in
Sweden. The third generation meters consisting of approx. 600.000 units deployed from 2005
onwards, as well as existing metering infrastructure and MDM systems to be used in the
demonstrator. This system uses OSGP for both communication from meters to data concentrators
and from data concentrators to AMI head end system.
Table 17 summarises the proposed standard protocol interfaces, i.e. protocols to be tested in the
demonstration. For a mapping between Swedish demo sub-functionalities and protocols see Table 15.
81 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 17: SUMMARY OF PROPOSED STANDARD PROTOCOL INTERFACES IN THE SWEDISH DEMONSTRATOR
Information Layer
Interface Description Sub-functionality
Standard
RTU -> SCADA IEC 60870-5-104 (In Data exchange D7: Monitoring and Control of LV
lieu of finalized -104 between LV network Networks
implementation one secondary substation D7.3 Improvement the LV Network
RTU may use DNP3) and overlying LV Management System visualization by
SCADA/DMS. integrating data measurements from
ZigBee to be used inside SS, (e.g. transformer meter,
between one RTU FTP format not used advanced LV supervision)
and current for real time D7.12 Interoperability test of the
transformer information integration of LV Network
requirements to Management System with equipment
FTP (RFC959) over overlying system, from different manufacturers
GPRS such as LV Monitoring D10: Smart metering Data Utilisation
Application. D10.3 Algorithm to determine
connectivity of SM to the grid
(identification of phase and line to
which each SM is connected to)
D10.4 Calculation of non-technical
losses using data from metering
devices both in SS and LV network
MV FPI -> SCADA IEC 60870-5-104 Data exchange D8: Automation and control of MV
between MV network networks
field installations and D8.1 Monitoring MV network by fault
overlying MV detectors
SCADA/DMS
Smart Transformer IEC60870-5-104 Data exchange D7: Monitoring and Control of LV
between the Smart Networks
(dynamic) D7.9 LV regulation at SS level using a
transformer and new smart transformer
overlying remote
control application,
e.g. MV SCADA
NIS /Asset CIM CIM - Common D9: Network management
Management System Information Model methodologies for network operation
-> LV SCADA for data exchange D9.2 Use CIM for LV network
modelling and data exchange
between e.g. AMI, GIS, MV SCADA, LV
Network Management System
82 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Information Layer
Interface Description Sub-functionality
Standard
CT sensor -> RTU N/A ZigBee wireless D7: Monitoring and Control of LV
communication Networks
D7.3 Improvement the LV Network
Management System visualization by
integrating data measurements from
inside SS, (e.g. transformer meter,
advanced LV supervision)
D7.12 Interoperability test of the
integration of LV Network
Management System with equipment
from different manufacturers
IEC-60870-5-104: Open protocol that provides interoperability between RTU/IED/FPI and MV/LV
SCADA/DMS for telecontrol applications. Mode of data transfer selected is unbalanced balanced
(master/slave initiated message). Data is classified into different information objects and each
information object is provided with a specific address. For real time information requirements.
FTP (RFC956) over GPRS: Standard protocol used to transfer files from RTU/IED to LV Monitoring
Application server, (not to be interpreted as the same as LV SCADA-DMS), over GPRS network. FTP is
built on a client-server architecture and uses separate control and data connections between the
client and the server. This format is suggested for other analysis functions related to network
planning and optimization such non-technical losses, LV topology identification, load transformers
analysis, harmonics, feeder/ phase imbalances, etc.
CIM: Is used for information exchange between applications in the operation and enterprise zones of
the SGAM model.
ZigBee: Is used to allow wireless communication between RTU and sensor. ZigBee provides a data
integrity check and authentication function for each application (RTU/IED and current sensors).
The main experience of using each of these protocols is: IEC-104: IEC-60870-5 protocols Dominant in
Europe, Middle East and Asia Pacific. Selection criteria:
Facility to classify the data into high priority (class-1) and low priority (class-2) and transfer the
same using separate mechanisms
Classify data into different interrogation groups
Cyclic & Spontaneous data updating schemes
Facility for time synchronization
FTP: May authenticate themselves using a clear-text sign-in protocol, normally in the form of a
username and password, but can connect anonymously if the server is configured to allow it. For
secure transmission that protects the username and password, and encrypts the content, FTP is often
secured with SSL/TLS (FTPS).
CIM: Integration between applications on the operation and enterprise zones of SGAM are to be
done, where possible, with IEC 61968 CIM. However, little experience is available using CIM at
83 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Vattenfall. The exception is the information exchange with the AMI head which will use existing g GS2
Data Model.
ZigBee: ZigBee is designed for devices talking to devices.
There would be some risks for using it as identified by the Swedish demonstration:
CIM model is as of yet not widely used at DSO level and its deployment constitutes a risk of increased
complexity and time delay to the demonstrator, should this risk material other means for information
exchange will be used (as they will for the AMI head end system information exchange).
ZigBee: Vattenfall has no previous experience from retrieving sensor information to RTU using
wireless (ZigBee) communication. The use of wireless protocol will be further discussed during the
planning of the demonstrator.
The main reasons that have leaded the Swedish demonstration on using these protocols are:
As conclusion of this section, the selection of standard has not influence on the demonstration design
yet. The main influence of standard is anticipated in the information exchange on operation and
enterprise zones of SGAM model. ZigBee is expected to restrict interoperability between sensors to one
specific RTU brand. Moreover how much the use of standards has impacted on the coexistence of new
developments with existing ones in the demo has not been identified yet.
The long term ambition of Vattenfall as leader of the Swedish demonstrator is to move towards open
standards to safe guard investments, increase completion and lower costs.
Regarding the expected evolution of the selected standards, it is considered that both vendors and
utilities (like Vattenfall) will move towards the CENELEC/IEC TC 57 reference architecture, IEC 62357,
84 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
and that the herein referred to standards will be further developed to replace legacy systems and
protocol solutions.
Table 18 presents the classification of the most relevant protocols identified by the Polish demonstrator
based on the implementations identified in D1.1 [1]; while Table 19 aims to the same purpose but
focused on equipment.
85 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 18: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE POLISH DEMONSTRATOR
86 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 19: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE POLISH DEMONSTRATOR
87 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
3.4.1 PROTOCOLS
Table 20 presents the main protocols used in each of the subfunctionalities identified in D1.1 [1] for the
Polish demonstrator.
Polish demonstration software, called DMS LV [1], has to collect data from:
MV/LV substations (15 kV / 0.4 kV)
Electric meters located within the 3-phase LV (0.4 kV)
Low Voltage Monitoring and Control units (LVM&C units) which are going to be designed especially
for the UPGRID project
Software systems located and exploited in ENERGA-Operator (DSO) such as SCADA/NMS, AMI and
Asset Management System/GIS
It is assumed that most of the data from the LV network will be received via AMI system that
communicates with AMI data concentrators located in MV/LV substations. These concentrators are used
to send and read data form both electric meters and LVM&C units installed within the LV network which
plays a role of the communication media, i.e. the narrow-band PLC technique is assumed to be used. So
these data and also commands (for LVM&C units) from the DMS LV will be transmitted indirectly via
AMI system. On the other hand, Smart Grid Monitoring and Control units (SGM&C units), which will be
installed next to AMI data concentrators in MV/LV substations will be reached by the DMS LV via
SCADA/NMS (MV, LV) using the packet-switched services available in a dedicated APN offered by a
cellular public operator.
More specifically:
In case the transmission concerns LV data periodically collected by the AMI system (e.g. customer
energy profiles, measurements, etc.) the data has to be transmitted between AMI database and the
DMS LV data base using the CIM (i.e., the Common Information Model) standard data semantics
and Web Service technique.
In case the transmission has to be carried out in a real-time (or quasi real-time) mode, e.g. DMS LV
commands directed to LVM&C units, data registered by these units, events from AMI data
concentrators, etc., then it is assumed that the CIM model is no longer used but Web Service
technique is also employed. On the other hand, it is assumed that data concentrators will
communicate with LVM&C units using narrowband PLC technique
In case data has to be mutually exchanged between DMS LV and SCADA/NMS and Asset
Management System/GIS systems the solution has to be based on CIM model and data exchange
concept.
In case the DMS LV communicates indirectly, via. SCADA/NMS with SGM&C units located together
with AMI data concentrators the telecontrol systems and equipment data communication standards
are going to be employed.
88 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
The most important protocols identified by the Polish demonstrator are indicated as follows:
Standards used for data communication between AMI data concentrators and LVM&C units:
PRIME Specification:
PRIME Specification revision 1.3.6. PRIME Alliance
Draft Specification for PoweRline Intelligent Metering Evolution. PRIME Alliance TWG. Revision
1.4. 2014
DLMS protocol:
DLMS/COSEM Architecture and Protocols. Green book 8th edition. Technical report. DLMS
User Association, 2014 [26]
IEC 62056-53 Std. Electricity metering Data exchange for meter reading, tariff and load
control Part 53: COSEM application layer. Second edition, 2006 [27]
COSEM data model:
COSEM Identification System and Interface Classes. Blue Book 12th edition. Technical report.
DLMS User Association, 2014 [28]
IEC 62056-61 Std. Electricity metering Data exchange for meter reading, tariff and load
control Part 61: Object identification system (OBIS). Second edition, 2006 [29]
IEC 62056-62 Std. Electricity metering Data exchange for meter reading, tariff and load
control Part 62: Interface classes. Second edition, 2006 [30]
STG-DC (STG-DC stands for Sistema de Telegestin Data Concentrator) is a protocol to define the
information exchange between the AMI Head End and Data Concentrator units installed in the
secondary substations. It is a web services protocol based on SOAP, it defines methods and data
format to be transmitted in both directions. The AMI Head End must be able to manage, configure
and extract all the information from DCU. It has been developed by Iberdrola within the
framework of the national rollout of SMs determined by law. A version of this protocol is at
disposal of the PRIME Alliance members. Iberdrola is working on implementing new
functionalities.
DC-SAP is a protocol developed within Energa, mostly based on DLMS/COSEM that is used for AMI
Head End Data Concentrator communication. It defines direct and cached communication
modes. Uses TCP/IP port-based transport and efficient (A-XDR) massage coding. The protocol is
open for use for interested parties (http://www.energa-operator.pl/dcsap.xml). Reference
implementation is available.
Web Services
CIM interfaces will be available over typical web services, with relevant WSDLs and defined XSD
structures. Proper security measures will be implemented.
Standard used for data integration between DMS LV and SCADA/NMS and GIS systems:
CIM
Relevant CIM classes will be used to exchange information about:
voltage levels
energy flow
observed events
network topology
specific messaging profiles will be defined
Web Services
CIM interfaces will be available over typical web services, with relevant WSDLs and defined XSD
structures. Proper security measures will be implemented.
Current BlueBook release (v12) is not meant for communication with control and monitoring units, as its
primary application is for metering purposes. To be able to communicate effectively with control and
monitoring units it is necessary to define own classes, able to carry relevant information. This will be
prototyped in the UPGRID Polish demonstrator. DLMS Association allows for extending the COSEM
classes, according to specific rules. The new classes, that will be defined, will service the following use
cases:
reading specific parameters from the monitoring module (for example, environmental data)
sending specific commands to the control unit (for example, to reduce active power output, or
change reactive power output)
90 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
The project will demonstrate how to communicate with the LV monitoring and control units using the
elaborated COSEM extensions, possibly in the real environment (PV panels along with a PV inverter).
As conclusion of this section, PRIME specification and DLMS standard are used for PLC data
communication between AMI data concentrators and associated meters. That is why Prime/DLMS
communication solution is selected for communication with LVM&C units proposed to the demo
project.
The DNP3 standard is selected as the solution for communication with SGM&C units since ENERGA
Operator has a long and positive experience with this standard that is applied between ENERGA's SCADA
systems and RTU devices located in substation both in HV and MV level. The IEC 60870-5-101/104
standards are sometimes also used for these purposes.
Recently ENERGA Operator has decided to use CIM as a data model for the ICT systems. Therefore a
specific CIM profile has been elaborated for ENERGA purposes. CIM standard has to be implemented in
existing SCADA/NMS, AMI system and Asset Management/GIS systems to exchange data with the DEMO
UPGRID ("DMS LV") software that will be elaborated.
Common application of standards simplifies ICT management and makes accepted solutions scalable
and replicable. In opinion of the Polish demonstrator, all proposed standards will be used and even
extended (CIM) in the coming years.
91 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 20: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE POLISH DEMONSTRATOR
Cluster, Function Objectives & Subfunctionalities Main protocols
D7.1 Operation (control and multiservice) of LV grid devices using PLC-PRIME for different telecontrol DLMS/COSEM Extensions for PRIME PLC LV monitoring
applications (Concept test) and control unit
D7.2 Queries to request advanced meter data to support operation DLMS/COSEM, PRIME PLC
D7.3 Improvement the LV Network Management System visualisation by integrating data measurements from DLMS/COSEM, PRIME PLC
inside SS (e.g. transformer meter, advanced LV supervision)
D7.4 Improvement the LV Network Management System visualisation by integrating data measurements from LV DLMS/COSEM, PRIME PLC; DLMS/COSEM Extensions for
network devices (e.g. customers SM, EV charging points, DER) PRIME PLC LV monitoring and control unit
D7.5 Integration of the MV power transformer status from the MV systems to the LV Network Management IEC 60870-5-104; IEEE 1815
System
D7.6 Integration of measurement data to support state estimation in LV Network Management System DLMS/COSEM, PRIME PLC
D7.7 Integration of measurement data to support power flow analyses in LV Network Management System DLMS/COSEM, PRIME PLC
D7.10 LV meshed network operation - Remote reconfiguration (no fully automatic) of the LV network (grid DLMS/COSEM, PRIME PLC
protection)
D7.11 LV meshed network operation - identifying the optimum topological configuration IEC 61968-13
92 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
D9.1 Define a sound LV network (schematic diagrams and parameters of components) N/A
D9.2 Use CIM for LV network modelling and data exchange between e.g. AMI, GIS, MV SCADA, LV Network IEC 61968-13
Management System IEC 61970-301
D9.5 Visualisation of data from LV Management Network System in a geographical context IEC 61968-13
D10.1 Integration and processing of meter events or/and other sources (e.g. telecom data) in the Outage DLMS/COSEM, PRIME PLC
Management System (OMS)
D10.3 Algorithm to determine connectivity of SM to the grid (identification of phase and line to which each SM is DLMS/COSEM, PRIME PLC
connected to)
D10.4 Calculation of non-technical losses using data from metering devices both in SS and LV network DLMS/COSEM, PRIME PLC
D11.1 Data analytics based on historical network state data to assist network planning N/A
D12.2 Transformer replacement optimisation based on historical data from meters inside SS N/A
D12.4 Deploy some mobile devices (e.g. tablet, smart phone) for accessing and visualise remotely information HTTPS, Webservices
from LV system (e.g. geographical context, assets and outage location) to support grid crews
93 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
D13.1 Web portal for increasing the consumer awareness in order to leverage their participation in electricity HTTPS
markets
94 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
3.4.2 EQUIPMENT
PRIME SM:
Single phase meters cover the metrological needs of the residential market, providing automated
meter reading (AMR) solutions to the distribution companies, based on a modular platform. The SMs
incorporates a bidirectional PLC modem (power line carrier) through the low voltage network for
remote reading and control application.
Polish demo SMs are compliant with the Energa PRIME SMs companion, which is similar to Spanish
T5 specification, with specific modifications.
A metering subsystem consisting of a set of single-phase meters (residential use) and three-phase
meters (industrial and commercial use) with low voltage network communication through the
CENELEC A band reserved for the exclusive use of the utilities and using PRIME technology
(www.prime-alliance.org).
The data concentrator devices located in the transformation stations.
For Polish demo, SMs and data concentrators manufactured by different vendors will be used.
It is planned to installed new devices in SS. They will be IEEE 60870-5-104 or IEEE 1815 Monitoring and
control units for MV/LV substations. The Polish demonstrator will use 3 levels control/ monitoring
solutions (RTU, UPS, FPI, telecommunication modem and existing SM and concentrator), Figure 22. In
several SS we are planning to use MV remote control switchgear.
95 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
The Polish demonstration will deliver a specialised LV monitoring control and monitoring unit. This unit
will be used to acquire monitoring data electric, environmental as well as those originating at DER
units. It will have also the capability to send specific control commands to DER units. Final set of
commands will be determined at a later stage, with a focus on effective control of DER units operating
parameters. The monitoring and control messages will be exposed as COSEM classes, reachable over
DLMS protocol, stacked over PLC PRIME protocol.
LV monitoring and control units will communicate in the same way as SMs do, they will just serve
different purposes. Within the units, a standard PRIME stack will be implemented, so they will have
exactly the same capabilities as SMs in terms of PRIME communication they can be promoted to
switches, demoted, they will register with the DCU, etc. They will exploit the phenomenon that the PLC
signal can easily cross the meter and fusebox boundary, being fully useable at customer premises.
Effectively, it can be used to communicate with PLC devices outside the DSO LV grid, but inside
customer home/office picogrid.
96 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Table 21 summaries the main impacts of the identified protocols presented in Table 6 for the Spanish
demonstration on the four factors defined previously (i.e. interoperability, interchangeability, scalability
and replicability); while Table 22 aims to the same purpose but focused on equipment.
97 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 21: IMPACTS FOR THE UPGRID SPANISH DEMONSTRATOR PROTOCOL LIST
List of protocols Impact on
Interoperability Interchangeability Scalability Replicability
Used standardised protocols
It is required to define a clear Difficult due to different Not an issue. Only requirement is to share
data model (companion companion specifications in the same companion
DLMS COSEM
specification) and a different countries. specification.
transport method.
PRIME compliance tests by a PRIME compliance test by a Not an issue. Not an issue.
PRIME 1.3.6 - 4-32 CS
certified laboratory. certified laboratory.
Proposed standard protocols,
proposed standard profiles
PRIME compliance tests by a PRIME compliance test by a Not an issue. Not an issue.
PRIME 1.3.6 - IP CS
certified laboratory. certified laboratory.
Assured if a clear MIB file is A MIB file is required. Not an issue. Not an issue.
SNMPv3
specified.
Used proprietary protocols
WSDL files definition and all It is difficult to assure. An Not an issue. Not an issue if the defined
XSD related to integration test is always reports/web services can be
STG 3.2
reports/orders defined. required even though a clear applicable.
definition is provided.
New standards to be developed,
new extensions to standard to be
developed, new profiles to be
developed
98 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 22: IMPACTS FOR THE UPGRID SPANISH DEMONSTRATOR EQUIPMENT LIST
List of equipment Impact on
Interoperability Interchangeability Scalability Replicability
Used standard equipment
Assured if the meter It is no so obvious. Note that Not an issue. The same applies as with
complies with the protocols apart from protocols, there interchangeability.
definition (includes are several HW
companion specification for characteristics that differ
PRIME SMs DLMS), telecom interfaces from the different countries
(such as the number of
communication ports,
dimensions, terminal
positions)
99 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
100 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
101 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Table 23 summarises the main impacts of the identified protocols presented in Table 10 for the
Portuguese demonstration on the four factors defined previously (i.e. interoperability,
interchangeability, scalability and replicability); while Table 24 aims to the same purpose but focused on
equipment.
102 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
2
TABLE 23: IMPACTS FOR THE UPGRID PORTUGUESE DEMONSTRATOR PROTOCOL LIST
List of protocols Impact on
Interoperability Interchangeability Scalability Replicability
Used standardised protocols
Specific data model required Depend on the data model Depend on the data model.
DLMS/COSEM (companion specification) and transport layer.
2
Empty cells mean Not Applicable or Not an Issue
103 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
3
TABLE 24: IMPACTS FOR THE UPGRID PORTUGUESE DEMONSTRATOR EQUIPMENT LIST
List of equipment Impact on
Interoperability Interchangeability Scalability Replicability
Used standard equipment
Must be compliant with the Even if compliant with the
companion specification and communication protocols
transport layer. and specific companion, it
also must be compliant with
EDP Box (PRIME SM)
other specifications
(mechanical specification,
dimensions, HMI )
3
Empty cells mean Not Applicable or Not an Issue
104 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
105 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Table 25 summarises the main impacts of the identified protocols presented in Table 13 for the Swedish
demonstration on the four factors defined previously (i.e. interoperability, interchangeability, scalability
and replicability); while Table 26 aims to the same purpose but focused on equipment.
106 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 25: IMPACTS FOR THE UPGRID SWEDISH DEMONSTRATOR PROTOCOL LIST
List of protocols Impact on
Interoperability Interchangeability Scalability Replicability
Used standardised protocols
OSGP over PLC (ETSI TS 103 908) Limited. The OSGP alliance is Limited. Although other SMs The same protocol is used The solution can be
(SGAM: Field Station) supported by a handful of are anticipated to support between the SM and DC and duplicated at another
developers. Require the Data the OSPG protocol used by from DC to AMI head end. location, using OSGP SM and
Concentrator developed by the Echelon DC, OSPG protocol also supports DC.
Echelon for exchanging data interchangeability can be direct load control modules,
from SM using OSGP. limited (for instance, based solar panels, gateways, and
on physical connections of other smart grid device. So
the SMs or functionality the solution could be applied
provided by them). for more use cases. Also the
number of levels could be
expanded if data
concentration is desired on
multiple levels.
OSGP over GPRS Limited. The OSGP alliance is Limited. Other SMs Data If the no. of DCs increase in The solution can be
(SGAM: Station Operation) supported by a handful of Concentrators are not relation to the no. of duplicated at another
developers. Require the NES anticipated to support the installed meters, no location, using the same DC
AMI platform developed by OSPG protocol used by the scalability limitation exist. and AMI Head End platform.
Echelon/Telvent for Echelon DC.
exchanging data with the DC
using OSGP.
107 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
109 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 26: IMPACTS FOR THE UPGRID SWEDISH DEMONSTRATOR EQUIPMENT LIST
List of equipment Impact on
Interoperability Interchangeability Scalability Replicability
Used standard equipment
Echelon SMs (SM) Limited. Require the NES Limited. Require the NES Increasing the no of meters The solution can be
platform developed by platform developed by is limited to the DC capacity. duplicated at another location
Echelon for exchanging data Echelon for exchanging data One DC may handle up to with no problem, using the
with the DC using OSGP with the DC using OSGP 1000 SM, but usually the same AMI Head End platform.
maximum volume is around
700-800 SM. If the no of DCs
increase in relation to the no
of installed meters, no
scalability limitation exist.
Echelon Data Concentrators (DC), Limited. Require the NES Limited. Require the NES Unlimited. The no of DCs is The solution can be
(with built in GPRS communication platform developed by platform developed by dependent on the no of duplicated at another location
modem) Echelon for exchanging data Echelon for exchanging data installed SM, usually approx. with no problem, using the
with the SM using OSGP. with the SM using OSGP. 700-800 SM is the maximum same AMI Head End platform.
volume per one DC. The no
of DCs in the used AMI
platform is unlimited. The
AMI platform will be hard
ware scaled according to the
total no of SM to be
collected, hence also the
required volume of DCs.
Proposed standardised equipment
to be used
SMs See above. See above. See above. See above.
110 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
111 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
112 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
114 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
115 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
116 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Table 27 summarises the main impacts of the identified protocols presented in Table 18 for the Polish
demonstration on the four factors defined previously (i.e. interoperability, interchangeability, scalability
and replicability); while Table 28 aims to the same purpose but focused on equipment.
117 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 27: IMPACTS FOR THE UPGRID POLISH DEMONSTRATOR PROTOCOL LIST
List of protocols Impact on
Interoperability Interchangeability Scalability Replicability
Used standardised protocols
Companion specifications May prove a bit difficult due Not an issue. Only requirement is to share
(meter data models) are to different companion the same companion
based on Blue Book, but DSO specifications in different specification and have it
specific deviations and countries. implemented in the meter
DLMS COSEM
changes are defined, thus (typical, meter hardware can
they are not 100% be the same for given
interoperable. vendor, just the firmware is
different).
PRIME compliance tests by a PRIME compliance test by a Not an issue. Not an issue.
PRIME 1.3.6 - 4-32 CS
certified laboratory. certified laboratory.
WSDL files definition and all Possible to ensure if Not an issue. Not an issue if the defined
XSDs related to specification closely reports/web services can be
STG 3.1
reports/orders are defined in followed. An integration test properly implemented.
the specification. is always advised.
Proposed standard protocols,
proposed standard profiles
IEC 60870-5-104: Telecontrol Yes, as long as required Yes, as long as required Not an issue. Full this is widely
equipment and systems Part 5-104: functions are equally functions are equally recognised standard.
Transmission protocols Network implemented by implemented by
access for IEC 60870-5-101 using interoperable equipment. interoperable equipment.
standard transport profiles. Second
edition, 2006
118 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
119 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
TABLE 28: IMPACTS FOR THE UPGRID POLISH DEMONSTRATOR EQUIPMENT LIST
List of equipment Impact on
Interoperability Interchangeability Scalability Replicability
Used standard equipment
Fully interoperable on a Not necessarily Not an issue Same as with
PRIME protocol level. interchangeable due to interchangeability.
Not necessarily possible differences in
interoperable on the DLMS hardware design (HAN ports,
COSEM level, due to possible alternative communication
PRIME SMs differences in companion ports, meter display design
specifications. etc.).
Common (non smart
metering features) are
ensured by compliance with
MID directive
120 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
121 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
122 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
5. GAP ANALYSIS
This chapter presents the Gap Analysis performed based on the information that has been made
available by the UPGRID demonstrators at this stage of the project and that was summarised in the
previous chapters.
The following tables (Table 29 - Table 41) indicate for each interface and for each demonstrator the used
protocol in the Demo Base or the proposed protocol under UPGRID, the gap detected and
recommendations to solve the gap. The high-level protocol layers column and the low-level protocol
layers split the whole protocol in two levels: the first is related with data model and the second is
related with physical aspects. The column GAP indicates issues about interoperability as lack of
definition or proprietary content. The column Recommendation indicates solutions in the case of the
Interface are the part of the demo for developing under UPGRID. An N/A in this column means that the
protocol of this Interface is not included in the part of the demo for developing in the current proposal.
An N/A in the column High-level protocol layers indicates that the demonstrator is not using this
interface or is not relevant.
123 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
125 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
126 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Only use standard ASDUs. All the analysed companion standards fulfil this requirement.
Not use ASDUS related with 32 bits transmission to mount an application level protocol.
Not use ASDUS related with file transmission to mount an application level protocol.
Use a common companion standard or only the common ASDUS to all companion standards. The
parameterization of the physical and link layer is not a problem because IEDs and RTUs are actually
full configurable.
Nevertheless, IEC60870-5-101 and DNP3.0 are mature protocols implemented normally over full
configurable devices that minimise incompatibilities.
In order to use CIM as the base of the communication protocol, two possibilities are available:
127 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
CIM RDF for communicating CIM models (e.g. CIM model of LV network of a district) or changes in
the CIM model (e.g. new LV line or new secondary station). CIM RDF uses XML with RDF syntax
following the standard IEC 61970-501.
CIM XML for communicating value changes in a set of variables of the CIM Model (e.g. meter values,
asset data of a physical device, or a crew work order). CIM XML uses XML following the XML schemas
defined by IEC 61968. For communicating the XML, is typical to use IEC 61968-100.
Both methods, CIM RDF and CIM XML, use the IEC 61970-301, the IEC 61968-11 and IEC 62325-301 as
the definition of the data model. These three standards define the CIM model.
In order to use the CIM RDF or CIM XML, these recommendations should be follow:
Only extend the CIM model with new classes if it is necessary.
If it is necessary a new class, reuse the information that the CIM model provides (e.g. extend a class
that minimizes the number of new attributes to be added).
Use of the CIM model extensions across the demonstrators. A CIM profile must be agreed.
For transferring new network configurations or changes in the network configuration, the CIM RDF is
the adequate method.
For transferring values associated to a network configuration (e.g. meter values, switch positions),
the CIM XML is the recommended method.
In the case of the physical transmission of the data (low-level protocol layers), the UPGRID project is
going to use:
PRIME for meters in three demos.
OSGP for meters in only one demo.
RS485 and ZigBee for sensors.
GPRS and other IP networks for communicating data to the management level or to SCADAs.
The Gap Analysis has not detected issues in the low-level protocol layer: all the installed devices in the
Demo Base or devices to be installed under UPGRID use mature standard protocols. Therefore, from
point of view of interoperability, the syntactic and communication level do not have relevant gaps.
In the case of semantic interoperability, the UPGRID project is going to use mainly four data models
(high-level protocol layers):
DLMS/COSEM for SM data and associated data.
60870-5-101/104 for communicating SCADA with IEDs and RTUS.
128 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
CIM model for modelling the LV network and for transferring data between applications in the
management level that uses the CIM model as a reference.
SNMP for network management.
After Gap Analysis this issues have been detected in the semantic interoperability (high-level protocol
layers):
No definition of the data model and the data format in the communication between mobile devices
and management level. The recommendation is using CIM XML.
No clear criteria about when CIM RDF or CIM XML must be used.
Some demonstrators are using or are planning to use a non-standard data model for collecting and
distributing meter data. The recommendation is using CIM XML.
These gaps justify the development of the sub-functionality Use CIM for LV network modelling and data
exchange between e.g. AMI, GIS, MV SCADA, and LV Network Management System (D9.2).
From the point of view of synergies, the protocol analysis has provided a simplified and common
hierarchical protocol structure that permits share experience across demos. For example:
PRIME: share experience about installation and management of PLC technology.
IEC 60870-104: share experience about using the standard and increase interchangeability.
DLMS/COSEM: use a common set of OBIS for meters and for new devices to be developed that
improve interoperability and interchangeability (this is a proposal and it should be done within the
Companion).
CIM Model: share experience and provide interchangeability of developed functions.
All about CIM, e.g. modelling or implementation, is the main source of synergies, because, from the
point of view of UPGRID, CIM is a new technology to be adopted that implicitly provides interoperability,
interchangeability (applications), scalability and replicability. The standard IEC 61970-301, base of the
CIM model, says This standard (CIM) should be understood as a tool to enable integration in any
domain where a common power system model is needed to facilitate interoperability and plug
compatibility between applications and systems independent of any particular implementation.
Neither, the scalability is an issue because the combination of IEDs and SMs with concentrators permits
to cover wide areas.
129 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Table 42 and Table 43 summarize the impact of the chosen equipment in the interchangeability. With
exception of the Swedish SMs and SM concentrators, the equipment could be interchangeable between
demos if functional and non-functional requirements are equivalents between demonstrators. However,
the interchangeability between demonstrators is more problematic when national regulations or prizes
restrictions play an important role. In fact, the interchangeability is more problematic in a SM than in a
RTU or in a data concentrator.
130 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
131 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Using the equipment type column classification and ordering the equipment as: meter, sensor, IED, data
concentrator and communication equipment, the interchangeability normally increases from meter to
communication equipment, thanks to the low impact of national regulations and the increased flexibility
of the equipment.
The SM is the equipment more affected by national regulations as physical dimensions or terminal
positions.
4
A re-closer/breaker is under discussions within the project to be included or not. This decision is partly dependent on IT security issues and the system set-
up for the project
132 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
6. CONCLUSIONS
The four UPGRID demonstrators have identified, defined and described their own approaches regarding
protocols and equipment. This information is complemented with the impact assessment (based on
interoperability, interchangeability, scalability and replicability) and the detail specification of each
protocol have conformed the base for the Gap Analysis. The Gap Analysis is the main outcome from this
deliverable and has allow to fulfil the T1.3 objectives that were to present the approach to
standardisation of the four demonstrators and extend recommendation based on these approaches to
leverage the advantages derived from using standards solutions.
As it has happened with the technical framework described in D1.1, preparing the requested
contributions to this document has leveraged the planning and dynamics among the partners that
conforms each demo but also inside the organisations of each individual partner. This has been
expressed as a very beneficial impact by them for conducting their respective demo WPs. This also
reflected on the information presented regarding the expected implementation plans. It shows that
exist good coordination among demo partners, roles are clearly defined and risk analysis faced out.
The classification proposed for protocols and equipment give a clear and easy view from where the
demonstrators will start from and in which direction they are evaluating to follow. This is important to
make them evaluate the possibility of implementing some of the recommendations provided in this
document (chapter about the Gap Analysis). The cross reference to the sub-functionalities defined and
selected by each demonstrator in D1.1 has also facilitate the composition of the full conception of the
demos up to this moment (M6). It will be interesting to compare how the initial expectative collected in
D1.3 are finally materialised in each of the demo WPs (WP3-6). An added value to the analysis
performed in the present document will be the analysis, if any, of the deviations. This consolidate the
statement that the Smart Grid standardization framework is mature enough but particular emphasis in
exploring detail aspects derived from its applicability.
The Gap Analysis has detected the main gaps in the high-level protocol layers about using data models.
This issue justifies the development of the sub-functionality Use CIM for LV network modelling and
data exchange between e.g. AMI, GIS, MV SCADA, LV Network Management System (D9.2) for solving
it. The Gap Analysis also has detected how national regulations can hinder the interchangeability of
equipment, mainly in the case of SMs.
This document has been elaborated considering the present stage of definition and concretion of the
conditions, approaches and characteristics of each Demonstrator, combining inputs received from the
demo leaders with the support of the rest of the collaborators and the transversal partners. It is
stablished a clear continuity between the present work and the one that is going to be done in the each
of the demonstrator WP.
As conclusion, it is considered that D1.3 has fulfilled the objectives of task T1.3.
133 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
REFERENCES
UPGRID DOCUMENTS
EXTERNAL DOCUMENTS
134 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
[18] ftp://ftp.cencenelec.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/SGCG_Interoperabilit
y_Report.pdf
[19] IOP Tool (excel file) CEN/CENELEC Smart Grid webpage
[20] http://www.cencenelec.eu/standards/Sectors/SustainableEnergy/SmartGrids/Pages/default.aspx
[21] The IEC Standard map, http://smartgridstandardsmap.com/
[22] Introduction to NISTIR 7628, Guidelines for Smart Grid Cyber Security,
[23] http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf
[24] Mandate M/490, 1st March 2011, ftp://ftp.cencenelec.eu/CENELEC/Smartgrid/M490.pdf
[25] Original source: https://en.wikipedia.org/wiki/File_Transfer_Protocol
[26] DLMS/COSEM Architecture and Protocols. Green book 8th edition. Technical report. DLMS User
Association, 20014.
[27] IEC 62056-53 Std. Electricity metering Data exchange for meter reading, tariff and load control
Part 53: COSEM application layer. Second edition, 2006.
[28] COSEM Identification System and Interface Classes. Blue Book 12th edition. Technical report.
DLMS User Association, 2014.
[29] IEC 62056-61 Std. Electricity metering Data exchange for meter reading, tariff and load control
Part 61: Object identification system (OBIS). Second edition, 2006.
[30] IEC 62056-62 Std. Electricity metering Data exchange for meter reading, tariff and load control
Part 62: Interface classes. Second edition, 2006.
[31] State-of-the-art technologies & protocols. Description of state-of-the-art. Communication
protocols and data structures. D2.1/Part 4. Open Meter, 2009.
[32] IEC 60870-5-104 Std. Telecontrol equipment and systems Part 5-104: Transmission protocols
Network access for IEC 60870-5-101 using standard transport profiles. Second edition, 2006.
[33] IEC 60870-5-101 Std. Telecontrol equipment and systems Part 5-101: Transmission protocols
Companion standard for basic telecontrol tasks. Second edition, 2003.
[34] IEC 60870-5-5 Std. Telecontrol equipment and systems - Part 5: Transmission protocols - Section 5:
Basic application functions. 1995.
[35] IEEE 1815 Std.: IEEE Standard for Electric Power Systems CommunicationsDistributed Network
Protocol (DNP3). Revised edition, 2012.
[36] 650 series DNP3 Communication Protocol Manual. Doc.1MRK 511 241-UEN, ABB, 2011.
[37] 12 IEC 61968-100 - Application integration at electric utilities - System interfaces for distribution
management - Part 100: Implementation profiles, IEC 2013
[38] GRID+ project http://www.gridplus.eu/; D4.2 Grid+ Deliverable D4.2 Data Collection of DSO
Projects
135 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
[39] DISCERN project http://www.discern.eu/; D5.2 - DISCERN guide for facilitating the replication and
scalability of the solutions
136 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
6.1 PRIME
PRIME stands for power linerelated intelligent metering evolution and defines the lower layers of a PLC
narrowband system that operates within the CENELEC A-band, between 42 and 89 kHz. PRIME uses
carrier frequencies (42 - 89 kHz) within the CENELEC A band and offers raw data rates between 5.4 kbps
(Robust mode: DBPSK with convolutional encoding and repetition code) and 128.6 kbps (D8PSK). Since
specification version 1.4, more frequency bands were introduced to utilize the higher frequencies (up to
471 kHz) in ARIB and FCC bands. Using the full FCC band, raw data rates are eight times as high as in
CENELEC A band.
Simplicity, low cost, and flexibility are the main goals in the design of the PRIME system. As of May 2013,
the PRIME Alliance reported that over 2M meters using this technology have been installed, with more
than 6M as of beginning of the year 2015. The PRIME specification is structured into Physical Layer, MAC
Layer and Convergence Layer. For operations and control, a Management Plane is specified.
Physical Layer
Distribution networks are usually made of a variety of conductor types, and terminating into loads of
different impedances, which also vary over time. Such infrastructure results in a communication channel
which has a time dependent amplitude and phase response that varies with frequency. Interference and
impulsive noise produced by motors, switching power supplies and halogen lamps reduces the reliability
of communication signals. Due to line attenuation, the noise is location dependent.
The PRIME Physical layer is based on OFDM (Orthogonal Frequency Division Multiplexing) and
differential phase shift keying (BPSK, DQPSK and D8PSK) as carrier modulation. To address varying
power line channel properties, robustness mechanism convolutional encoding (optional), scrambling
and interleaving are used. PRIME Specification v1.4 also introduces repetition coding as additional
robustness mechanism (ROBO mode).
MAC Layer
The MAC Layer specifies the data link layer of the OSI model.
In a PRIME subnetwork two device types exist: Base nodes and Service nodes. Base nodes manage
subnetwork resources and connections. All devices, which are not Base nodes are Service nodes. Service
nodes register with Base nodes to become part of a subnetwork.
137 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
The topology generated by a PRIME subnetwork is a tree with the Base node as trunk. To extend the
subnetwork range, a Base node can promote a Service node from terminal state to switch state.
Switches relay data in the subnetwork and build the branch points of the tree.
Power line is a shared communication media. Base nodes and switches announce their presence with
beacon messages in well specified intervals. These beacons provide a common time notion to a
subnetwork. Time is split into shared contention period (SCP) and contention free period (CFP). During
SCP, nodes can access the channel using CSMA/CA. For the CFP period, the base node arbitrates channel
access.
To reduce transmission overhead, PRIME uses dynamic addresses to address nodes in a subnetwork.
The addressing scheme resembles the tree structure of the subnetwork and consists of local switch id,
local node id and local connection id. Routes are established during service node registration. PRIME
makes use of address structure for packet routing, which reduces state information needed by service
nodes. Base node and service nodes monitor network attachment based on periodic exchanged control
messages, so called "keep alive messages".
PRIME allows connection oriented communication. The PRIME MAC layer includes control
mechanism/messages to open and close unicast, multicast and broadcast connections. To provide
reliable connections, Selective Repeat ARQ is used between the two connection end points.
PRIME specifies a security profile for encryption of MAC layer packets. Encryption is based on AES-CCM
with 128bit keys and key derivation mechanism recommended by NIST.
Convergence Layer
The PRIME convergence layer is split into a Common Part Convergence Sublayer (CPCS) and Service
Specific Convergence Sublayer (SSCS). The CPCS provides a segmentation and reassembly mechanism to
all SSCS.
PRIME currently specifies four SSCS:
IPv4 SSCS
IPv6 SSCS
NULL SSCS, a transparent SSCS for node management and custom use
IEC 61334-4-32 SSCS for use with DLMS/COSEM
Management Plane
The PRIME Management Plane specifies interfaces for local and remote management of nodes and for
firmware upgrade.
138 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
To exchange data with LVM&C units using the COSEM interface model, the information modelled has to
be turned into a form, which can be transported via communication channels using DLMS protocol.
DLMS specifies services and protocols to build messages carrying the information modelled and held
by the COSEM objects that are transported over various communication media. It is designed so, that
the object model can be extended as required to cover new applications, without affecting the
messaging system.
The IEC 62056-62 DLMS standard introduces a few solutions for an efficient use of the COSEM model.
This extended DLMS constitutes the xDLMS ASE of the COSEM application layer. It is important to note,
that DLMS as specified in IEC 62056-62 does not provide a meter data model or a naming system.
Adding these elements is one of the main evolutions brought by DLMS/COSEM communication solution.
139 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
DLMS protocol uses a client/server concept. The data collection system acts as a client, requesting
services. The logical devices of the LVM&C units (as well as of the AMI meters) act as servers,
responding to service requests. The LVM&C functionality needed for a particular LVM&C unit may be
provided by a single physical device or may be distributed across several physical devices.
For accessing attributes and methods of COSEM objects, their attributes and methods have to be
referenced. There are two possibilities available:
Logical Name (LN) referencing: the attributes and methods are referenced with the triplet {class_id,
logical_name, attribute/method id}. The services are GET, SET, ACTION and EventNotification;
Short Name (SN) referencing: each attribute and methods is mapped to a DLMS named variable. The
services are Read, Write, UnconfirmedWrite and InformationReport. The mapping is provided by the
meter for the client, to obviate the need for manufacturer specific information.
A COSEM Interface Class (IC) is characterized by a set of attributes and methods, which serve to describe
some externally visible features of the class. Each attribute has a defined meaning; the first attribute (of
each COSEM IC) is called the logical name. An attribute can be static, to hold configuration data, or
dynamic, updated by the metering process. Each method defines a certain operation on one or more
attributes. Attributes may be read or written and methods can be invoked remotely via the
communication interface(s) or locally by the metering Application Process (AP). A COSEM IC may have
several instances, called COSEM objects, identified with an OBIS code.
In particular the COSEM interface classes allow modelling the various metering applications and
functions of the device like:
energy and demand metering
measurement of instantaneous values
value monitoring
power quality measurement
time of use
scheduled activities
load profiles
event logging
load management
140 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
OBIS is a naming system, and its original purpose is to identify data on the device (meter, LVM&C unit)
display in a standard and unambiguous way. It is used to identify interface objects as well as data
elements on the display. OBIS is a hierarchical system, consisting of six value groups A to F. In general,
each lower-level value group provides a classification for the quantities identified by upper-level value
groups:
Value group A (the highest level in the hierarchy) identifies the energy type (media) to be measured.
The value A = 0 identifies abstract, media or energy-type independent objects, common for all kind
of meters;
Value group B classifies the quantities identified by value group A; its typical use is to identify
measurement channels;
Value group C further classifies the quantities identified by value group A to B. Its typical uses are to
identify physical quantities, like voltage, current, active / reactive / apparent power, pressure,
volume, flow or abstract data items;
Value group D further classifies the quantities identified by value group A to C. The meaning of each
value depends on the values A to C. Its typical use is to identify the way a physical quantity is
processed for example averaged, integrated, monitored;
Value group E further classifies the quantities identified by value group A to D. The meaning of each
value depends on the values A to D; its typical use is to identify tariff rates;
Value group F further classifies the quantities identified by value group A to E; its typical use is to
identify historical values.
The range in each value group is 0 to 255. In some value groups, manufacturer-, country- or
consortia-specific ranges are available. Standard OBIS codes are allocated by the DLMS UA. A
document called Object definition tables, listing all defined combinations of the values in the six
value groups, together with the interface class(es) and data type(s) to be used is maintained by the
DLMS UA and it is available at HThttp://dlms.com/members/List-OBIS.htmTH. It is used by the CTT
for conformance testing of the COSEM interface objects.
from the meter, with minimum reliance on information coming from the manufacturer, like
passwords, secrets, any manufacturing specific elements. This facilitates plug-and-play;
DLMS messaging services common for all ICs / objects: these are used to access the attributes and
methods of COSEM objects. This means that new interface classes can be specified to cover new
functions, without affecting the protocols. For encoding, the efficient IEC 61334-6 A-XDR standard is
used.
A typical application of CIM is the exchange of a power system model data between companies and
applications, or other interapplication-related integration issues. The standard basically defines three
fundamental parts:
Information model: A canonical model that defines semantic relations between the objects of the
power system. It is modelled in UML and managed in SPARX Enterprise Architect UML modelling
tool.
Contextual profiles: Specific subset of the CIM, for example, Common Power System Model (CPSM).
Implementation models: Rules for coding CIM in XML/RDF schemas, for example, schema for power
system model exchange or schema for messages.
A semantic information model defines the basic vocabulary or terms of the objects. It defines an
ontology that represents the knowledge, business concepts, relationships, and a set of rules. The
knowledge can be organized in a discrete layer for independent use by other systems and thus is more
scalable, maintainable, and manageable.
The context-specific use is restricted by the profile. It restricts the information model and thus is
standardized to provide interoperability.
The message syntax is needed to implement the format of the exchanged information. It has to obtain
the rules of the format and is covered in different part of the standard.
Besides the data model, the standard series specify interface architectures, general guidelines,
implementation profiles, and common services for, for example, data access and exchange, as well as
examples.
142 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
IEC 61970-301 describes a semantic model or domain ontology of all power system components of an
electrical system and their relationship. Physical aspects and complex relations of EMS can be
modelled with the classes defined in the packages depicted in Figure 23.
IEC 61968-11 extends it with other aspects of power system information such as asset management,
workforce scheduling, or customer billing. Information exchange requirements for distribution
systems, which extend the base model, are modelled with the classed defined by the packages
depicted in Figure 24.
IEC 62325-301 describes the framework for energy market communications. Dealing with the market
transaction for energy exchange and market operation (both for the US and EU markets) can be
modelled with the packages depicted in Figure 25.
FIGURE 23: IEC 61970-301 CIM BASE DATA MODEL. (FROM IEC 61970, COMMON INFORMATION MODEL (CIM)/ ENERGY
MANAGEMENT, PART 1405, 2013, WWW.IEC.CH)
FIGURE 24: IEC 61968-11 CIM BASE DATA MODEL. (FROM IEC 61968, COMMON INFORMATION MODEL (CIM)/
DISTRIBUTION MANAGEMENT, PART 113, 2013, WWW.IEC.CH)
143 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
FIGURE 25: IEC 62325-301 CIM BASE DATA MODEL. (FROM IEC 62325, FRAMEWORK FOR ENERGY MARKET
COMMUNICATIONS, PART 1502, 2013, WWW.IEC.CH.)
IEC 61968 is structured into many specific parts. Except from 61968-11 CIM base data model, the
following parts are of particular interest:
Part 1 that defines architecture and interfaces for distribution systems within a utility enterprise
Parts 3 to 9, that define CIM object model and normative XML payloads to exchange CIM derived
data.
Part 100, which role is the following:
Defines profile for application of the other parts of 61968 using common integration technologies,
including JMS and web services.
Defines normative message envelope and WSDL definitions for interfaces.
Provides guidelines and recommendations for usage of Enterprise Service Bus technologies and
specific message exchange patterns.
CIM provides universal logical description of power system for different applications, which is a platform
independent model. In all the packages of CIM, core package and topology package are related to
network topology. There are five classes used for describing the relation of network topology, including
equipment, terminal, connectivity, topological node and topological island. The conducting equipment
class is abstract, it doesnt produce entity object. All the power equipment classes derive from it.
144 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
PowerSystemResource:
The PowerSystemResource class inherits from IdentifiedObject and provides another relatively
abstract class used in the CIM. The PowerSystemResource class supports an association to a
Company class. This relationship identifies the company that operates the resource.
145 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Terminal:
Any object inheriting from the class of ConductingEquipment has a relationship to an object by the
class of Terminal. This relationship has a multiplicity of 0...*, but typically it will be one or two
terminals depending upon the specific class. This relationship is actually defined in the Core package
but only utilized in the Topology package.
146 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
ConnectivityNode:
The ConnectivityNode class has a relationship to the Terminal class. Each ConductingEquipment
object has Terminals, which are then connected to ConnectivityNodes. The terminals can be thought
of as being closely related to the conducting equipment, and the connectivity nodes are the glue that
defines what equipment is connected to what other equipment.
TopologicalNode
The TopologicalNode class is used to define the objects that are all combined into a single bus when a
bus-branch model is built using the device statuses (usually the nominal device statuses). This
aggregation is done with the relationship between TopologicalNode and ConnectivityNode.
For the purpose of data exchange between GIS and AMI systems, a dedicated CIM profile needs to be
created. Such profile will define the complete scope of information that will be exchanged between
these applications.
CIM will be used for the purpose of data exchange between SCADA and AMI. Specifically, a norm 61968-
9 will be used.
147 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
61968-9 specifies the exchange of information between the AMI metering and other systems and
business functions. Specific communication protocols (e.g., TCP/IP) are not defined by this standard.
Information is modelled by a set of messages that support reading and control functions of SMs. Typical
uses are:
Meter reading and control
Meter events
Customer Data Sync and Switching
From the common reference model point of view, the SM is an end device, with a unique id. It can be
considered as a physical asset, which receives control requests and collects and reports measured
values. The SM is part of a business process including customer and respective contracts, energy market,
aggregators, and other ancillary service providers. It can also gather information necessary for other
business functions, like detailed network measurements or environment monitoring.
The reference model specifies the following functionalities for meter reading and control:
Metering system includes data collection, control, and reconfiguration.
Meter data management.
Maintenance.
Load management including load control and load analysis.
Meter asset management.
Meter administrative functions.
For the purpose of data exchange between SCADA and AMI systems, a dedicated CIM profile needs to
be created. Such profile will define the complete scope of information that will be exchanged between
these applications.
148 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
IEC 60870-5-101 provides a communication profile for sending basic telecontrol messages between a
central telecontrol station and telecontrol outstations, which uses permanent directly connected data
circuits between the central station and individual outstations. In some applications, it may be required
to send the same types of application messages between telecontrol stations using a data network
containing relay stations which store and forward the messages and provide only a virtual circuit
between the telecontrol stations. This type of network delays messages by varying amounts of time
depending on the network traffic load.
149 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Physical layer
Even though the standard does not specify the physical layer, it does however specify how to operate in
a networked environment and also suggests how to avoid collisions between simultaneously sending
devices. Many implementations use serial communication based on RS-232, RS-485 or even fibre optics.
DNP3 can also be used over packet-oriented networks such as TCP/IP and UDP in which, for example,
Ethernet may be used. In this case DNP3 can be said to be tunnelled over TCP/IP or UDP. Additional
information on the DNP3 physical layer is available at the DNP Users Group at www.dnp.org.
Link-layer confirm usage is not recommended and the implementation is optional. The IED does not
request data-link layer confirmations for TCP/IP communication. See the DNP technical bulletin TB1998-
0402, section 3 for details at www.dnp.org.
Transport pseudo-layer
To support advanced RTU functions and messages exceeding the maximum data link frame length, a
transport pseudo-layer which implements message assembly and disassembly services was adopted.
Transport functions:
Fragmenting user data into one or more data link frames and transmitting the data to the data link
layer
Assembling the data link frames received from the data link layer into user data
150 | 151
Scope and Boundaries of Project Demonstration
D1.3 Report on standards and potential synergies
Controlling all aspects of the data link excluding data link configuration
Transport responsibilities:
Exchange of SDUs between peer DNP3 transport pseudo layers
Error notification to transport users
Sequencing of SDUs
Application layer
The application layer is responsible for performing operations on data objects defined by the device or
on the device itself. These operations include returning actual values (read function), assigning new
values (write function) if the object represents control points, arming and energizing the output point
(select, operate or direct operate functions) and if counters are used, reading actual values and clearing
the counters. DNP3 uses the term point do identify an entity, and these entities can be categorized into
point-types, such as analogues or binaries. Points are addressed by giving them an index number and an
object is a formatted representation of data from a point. These objects can be assigned to classes in
order to organize events and current values into categories. The DNP3 protocol defines four classes; any
for static data (current value) and 1, 2 and 3 for event data.
Communication modes:
151 | 151