UPGRID D0103 Standards

Real proven solutions to enable active demand and distributed
generation flexible integration, through a fully controllable

LOW Voltage and medium voltage distribution grid
Scope and Boundaries of Project

Demonstrations
Report on standards and
potential synergies
D1.3
2015 The UPGRID Consortium
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
PROGRAMME H2020 Energy Theme

GRANT AGREEMENT NUMBER 646531
PROJECT ACRONYM UPGRID
DOCUMENT D1.3
TYPE (DISTRIBUTION LEVEL) Public
Confidential
Restricted
DUE DELIVERY DATE 30.06.2015
DATE OF DELIVERY 29.06.2015
STATUS AND VERSION Final version / v04
NUMBER OF PAGES 151
WP / TASK RELATED WP1 / T1.3
WP / TASK RESPONSIBLE IBERDROLA / IBERDROLA
AUTHOR (S) IBERDROLA (Ral Bachiller)
PARTNER(S) CONTRIBUTING IBERDROLA (Ral Bachiller; Jess Garca), EDP
(Pedro Manuel, Ricardo Matos, Pedro Godinho),
VTF (Anders Kim Johansson, Nicholas Etherden),
ENERGA (Slawomir Noske), TECNALIA (Eduardo
Garca), IMPERIAL (Christos Vasilakos), COMILLAS
(Jose Antonio), INESC (Luis Seca), ZIV (Laura
Marrn; Txetxu Arzuaga), WITHUS (Tiago Duarte,
Luis Oliveira), NOS (Marijn Van Overveld), POWEL
(Kjetil Kvamne), SE (David Pampliega, Tomas
Sanchez), GE (Manuel Weindorf, Miguel
Ballesteros), IEN (Aleksander Babs, Lukasz
Tarasiuk), ITE (Ignacio Delgado, Irene Aguado)
OFFICIAL REVIEWER/S ZIV (Laura Marrn) / WITHUS (Emanuel Miranda,
Tiago Duarte)
FILE NAME UPGRID_WP1_D1.3_Standards_v04_final
2 | 151
DOCUMENT HISTORY
VERS. ISSUE DATE CONTENT AND CHANGES

v01 25.05.2015 First version including all the contributions received
without the Gap Analysis chapter. Version for review
internally within T1.3.
v02 09.06.2015 Second version including additional contributions.
v03 18.06.2015 Version including Executive summary, Gap Analysis and
Conclusion. Version for Official Review.
v04 29.06.2015 Final version
3 | 151
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
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
TABLE OF CONTENTS
EXECUTIVE SUMMARY _________________________________________________________________ 4

TABLE OF CONTENTS __________________________________________________________________ 6
LIST OF FIGURES ______________________________________________________________________ 8
LIST OF TABLES ______________________________________________________________________ 10
ABBREVIATIONS AND ACRONYMS ______________________________________________________ 12
1. INTRODUCTION ___________________________________________________________________ 15
1.1 PRACTICAL REFERENCES TO STANDARDISATION ______________________________________________ 17
1.2 SCOPE OF THE DOCUMENT _______________________________________________________________ 22
2. METHODOLOGY ___________________________________________________________________ 24
3. INITIAL DEMONSTRATIONS APPROACH TO STANDARDS AND EQUIPMENT ____________________ 33
3.1 SPANISH DEMONSTRATOR _______________________________________________________________ 33
3.1.1 PROTOCOLS __________________________________________________________________________________ 36
3.1.2 EQUIPMENT __________________________________________________________________________________ 42
3.2 PORTUGUESE DEMONSTRATOR ___________________________________________________________ 48
3.2.1 PROTOCOLS __________________________________________________________________________________ 52
3.2.2 EQUIPMENT __________________________________________________________________________________ 57
3.3 SWEDISH DEMONSTRATOR _______________________________________________________________ 62
3.3.1 MAPPING ON SGAM ___________________________________________________________________________ 72
3.3.2 DESCRIPTION OF THE USED STANDARDS PROTOCOLS / PROPRIETARY PROTOCOLS _________________________ 80
3.3.3 DESCRIPTION OF PROPOSED STANDARD PROTOCOL _________________________________________________ 81
3.3.4 DESCRIPTION OF DEVELOPMENT OF EXTENSIONS TO A STANDARD PROTOCOL / PROTOCOL PROFILES TO BE
DEVELOPED (AND POSSIBLE STANDARDIZATION PROCESS) ________________________________________________ 84
3.4 POLISH DEMONSTRATOR ________________________________________________________________ 85
3.4.1 PROTOCOLS __________________________________________________________________________________ 88
3.4.2 EQUIPMENT __________________________________________________________________________________ 95
4. IMPACT OF STANDARDISATION IN UPGRID _____________________________________________ 97

4.1 SPANISH DEMONSTRATOR _______________________________________________________________ 97
4.2 PORTUGUESE DEMONSTRATOR __________________________________________________________ 102
4.3 SWEDISH DEMONSTRATOR ______________________________________________________________ 106
4.4 POLISH DEMONSTRATOR _______________________________________________________________ 117
5. GAP ANALYSIS ___________________________________________________________________ 123
5.1 PROTOCOL GAP ANALYSIS _______________________________________________________________ 123
5.1.1 GENERAL RECOMMENDATIONS FOR USING IEC 60870-5-101/104 AND DNP _____________________________ 127
5.1.2 GENERAL RECOMMENDATIONS FOR USING DLMS/COSEM ___________________________________________ 127
5.1.3 GENERAL RECOMMENDATIONS FOR USING CIM ___________________________________________________ 127
5.1.4 GENERAL RECOMMENDATIONS FOR SNMP ________________________________________________________ 128
6 | 151
5.1.5 CONCLUSIONS ABOUT PROTOCOLS ______________________________________________________________ 128

5.2 EQUIPMENT GAP ANALYSIS______________________________________________________________ 129
6. CONCLUSIONS ___________________________________________________________________ 133
REFERENCES _______________________________________________________________________ 134
ANNEX I. DESCRIPTION OF PROTOCOLS _________________________________________________ 137
6.1 PRIME ______________________________________________________________________________ 137
6.2 DLMS PROTOCOL STANDARD ____________________________________________________________ 139
6.3 COSEM INFORMATION MODE____________________________________________________________ 140
6.4 CIM STANDARD _______________________________________________________________________ 142
6.5 WEB SERVICES ________________________________________________________________________ 148
6.6 IEC 60870-5-101/104___________________________________________________________________ 149
6.7 DNP3 OVER IP ________________________________________________________________________ 149
7 | 151
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
FIGURE 22: THREE LEVELS OF MONITORING IN SECONDARY SUBSTATION _______________________96

FIGURE 23: IEC 61970-301 CIM BASE DATA MODEL. (FROM IEC 61970, COMMON INFORMATION MODEL
(CIM)/ ENERGY MANAGEMENT, PART 1405, 2013, WWW.IEC.CH) ____________________________143
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
FIGURE 25: IEC 62325-301 CIM BASE DATA MODEL. (FROM IEC 62325, FRAMEWORK FOR ENERGY
MARKET COMMUNICATIONS, PART 1502, 2013, WWW.IEC.CH.) _____________________________144
FIGURE 26: CORE PACKAGE OF CIM MODEL ______________________________________________145
FIGURE 27: THE TOPOLOGY PACKAGE OF CIM MODEL ______________________________________147
9 | 151
LIST OF TABLES
TABLE 1: STRUCTURE OF TABLE TO CLASSIFY PROTOCOLS AND EQUIPMENT IN THE DEMONSTRATORS 24

TABLE 2: STRUCTURE OF THE TABLE TO CLASSIFY DEMONSTRATORS PROTOCOLS _________________25
TABLE 3: STRUCTURE OF THE TABLE TO CLASSIFY DEMONSTRATORS EQUIPMENT ________________25
TABLE 4: LIST OF UPGRID PROTOCOL IMPACTS _____________________________________________30
TABLE 5: LIST OF UPGRID EQUIPMENT IMPACTS ___________________________________________30
TABLE 6: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE SPANISH DEMONSTRATOR ___34
TABLE 7: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE SPANISH DEMONSTRATOR ___35
TABLE 8: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE
SPANISH DEMONSTRATOR _____________________________________________________________40
TABLE 9: GROUPS AND SUB-GROUP OF EVENTS DESCRIBED BY THE COMPANION STANDARDS FOR SMS
__________________________________________________________________________________44
TABLE 10: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE PORTUGUESE DEMONSTRATOR
__________________________________________________________________________________49
TABLE 11: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE PORTUGUESE DEMONSTRATOR
__________________________________________________________________________________51
TABLE 12: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY
THE PORTUGUESE DEMONSTRATOR _____________________________________________________54
TABLE 13: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE SWEDISH DEMONSTRATOR _63
TABLE 14: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE SWEDISH DEMONSTRATOR _65
THE SWEDISH DEMONSTRATOR _________________________________________________________70
TABLE 16: SUMMARY OF STANDARD PROTOCOL INTERFACES USED IN THE SWEDISH DEMONSTRATOR 80
TABLE 17: SUMMARY OF PROPOSED STANDARD PROTOCOL INTERFACES IN THE SWEDISH
DEMONSTRATOR ____________________________________________________________________82
TABLE 18: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE POLISH DEMONSTRATOR ___86
TABLE 19: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE POLISH DEMONSTRATOR ___87
THE POLISH DEMONSTRATOR __________________________________________________________92
TABLE 21: IMPACTS FOR THE UPGRID SPANISH DEMONSTRATOR PROTOCOL LIST _________________98
TABLE 22: IMPACTS FOR THE UPGRID SPANISH DEMONSTRATOR EQUIPMENT LIST________________99
10 | 151
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
ABBREVIATIONS AND ACRONYMS
AMI Advanced Metering Infrastructure

AMM Advanced Metering Management
AMR Advanced Metering Reading
ASDU Application Service Data Unit
ATENDE Atende S.A.
CDMA Code Division Multiple Access
CDPSM Common Distribution Power System Model
CEN Comit Europen de Normalisation
CENELEC Comit Europen de Normalisation lectrotechnique
CIM Common Information Model
COMILLAS Universidad Pontificia Comillas
Companion Specification for Energy Metering / Device
COSEM / DLMS
Language Message specification
CT Current Transformer
D Deliverable
DC Data Concentrator
DER Distributed Energy Resources
Distributed Intelligence for Cost-effective and Reliable
DISCERN
Solutions
DMS Distribution Management System
DNP3 Distributed Network Protocol
DSO Distribution System Operator
DTC Distributed Transformer Controller
EB EDP Box
EDP EDP Distribuio - Energia, S.A.
ENERGA Energa Operator S.A.
European Telecommunications Standards Institute (see
ETSI
www.etsi.org)
EU European Union
FP7 Seventh Framework Program
FPI Fault Passage Indicator
FTP File Transfer Protocol
GE IGE Energy Services (UK) Ltd.
GIS Geographical Information System
GPRS General Packet Radio Service
GS2 GrnsSnitt2 or "Interface2"
12 | 151
IBERDROLA Iberdrola Distribucin Elctrica S.A.U.

ICCP Inter-Control Center Communications Protocol
IEC International Electrotechnical Commission
IED Intelligent Electronic Device
IEEE Institute of Electrical and Electronics Engineers
IEN Instytut Energetyki
IMPERIAL Imperial College of Science, Technology and Medicine
INESC PORTO - Instituto de Engenharia de Sistemas e
INESC
Computadores do Porto
IOP Interoperability
IP Internet Protocol
ISO International Organization for Standardization
IT Information Technology
ITE Asociacin Instituto Tecnolgico de la Energa
ETSI European Telecommunications Standards Institute
LCC Life Cycle Cost
LV Low Voltage
LVM&C Low Voltage Monitoring and Control
MDM / MDMS Meter Data Management System
MIB Management Information Base
MV Medium Voltage
N/A Not Applicable
NIS Network Information System
NIST National Institute of Standards and Technology
National Institute of Standards and Technology Interagency
NISTIR
Report
NOC Network Operation Centre
NOS NOS Comunicaes, S.A.
OID Object Identifier
OSGP Open Smart Grid Protocol
OSI Open System Interconnection
PBN PRIME Base Node
PER Performance Event Report system
PLC Power Line Communication
PLT Power Line Transmission
POWEL Powel AS
PRIME PoweRline Intelligent Metering Evolution
RTU Remote Terminal Unit
SCADA Supervisory Control And Data Acquisition
SE Schneider Electric Industries SAS
13 | 151
SGAM Smart Grid Architecture Model

SGCG Smart Grid Co-ordination Group
SM Smart Meter
SNMP Simple Network Management Protocol
SS Secondary Substation
STG-DC Sistema de Telegestin-Data Concentrator
T Task
TECNALIA Fundacin Tecnalia Research & Innovation
UML Unified Modelling Language
Real proven solutions to enable active demand and
distributed generation flexible integration, through a fully
UPGRID
controllable LOW Voltage and medium voltage distribution
grid
VT Voltage Transformer
VTF Vattenfall Eldistribution AB
WITHUS WITHUS-Inovacao e Tecnologia Lda.
WP Work Packet
XML Extensible Markup Language
ZIV ZIV Metering Solutions S.L.
14 | 151
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.
As defined in D1.1 Technical specification of project demonstrators, in the UPGRID context,

subfunctionalities are defined as implementations and processes (hardware and software) aimed at
providing a service to achieve a purpose facilitated by standards and right technological choices to attain
expected impacts which can be categorised in Smart Grid function objectives and clusters [1][2].
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
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.
Benefit of using standards for representing Smart Grid solutions
Facilitating knowledge sharing among actors

Facilitate the cooperation between different Stakeholders to design Smart Grid solutions
Common framework to represent Smart Grid architectures
Agreement on a common set of terms that shall be used within a solution representation
Facilitating assessment and comparison of solutions
Establishing a common approach to identify and express requirements for Smart Grid solutions
Identification of interoperability layers
Facilitating human-to-human communications
Fast identification of challenges that have been already analysed
16 | 151
1.1 PRACTICAL REFERENCES TO STANDARDISATION
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.
The most relevant material is summarised in the following index frames:
Smart Grid Standards Mapping Tool
Name of the tool: IEC tool (Smart Grid Standards Map)

Description: It is an interactive internet webpage tool that facilitates the list of standards available for
each area of Smart Grid. Overall, the Smart Grid Standards Mapping Tool defines relationships between
components and standards of the Smart Grid. There are multiple paths to finding the Smart Grid
standard that might be needed, for example equipment, function and SGAM zones/domains. Moreover,
the tool facilitates the purchase of standard documentations.
Purpose: Identification of available standard for the selected equipment and/or function of Smart Grid.
Developer: IEC (International Electrotechnical Commission)
Format: Interactive web tool (free and member access areas)
Where to find it: http://smartgridstandardsmap.com/
A window shoot of the material: Figure 1
SGCG Interoperability IOP tool
Name of the tool: SGCG Interoperability IOP tool

Description: List containing the most relevant standards and standardisation actions in each SGAM
domain [15][17]. For each standard information is provided regarding: SGAM layers and specific systems
that shall utilise the standard.
Purpose: Identified standards entering through the identified high level systems mapping in SGAM
ftp://ftp.cencenelec.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/SGCG_Standards_Report.pdf
Developer: CEN-CENELEC-ETSI Smart Coordination Group
Format: Excel file
Where to find it: Open download
http://www.cencenelec.eu/standards/Sectors/SustainableEnergy/SmartGrids/Pages/default.aspx
A window shoot of the material: Figure 2
17 | 151
FIGURE 1: WINDOW SHOOT OF THE SMART GRID STANDARDS MAP (TAKEN FROM HTTP://SMARTGRIDSTANDARDSMAP.COM/)
18 | 151
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
List of standardised names for Smart Grid players
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
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:
Tools for managing Uses Cases and SGAM model
DISCERN SGAM Visio Template

Template developed in Microsoft Visio (compatible with Visio 2010 and later) to create SGAM models. It
enables users to resize SGAM cells, synchronise SGAM layers, show/hide the background view of the
Component Layer, set out an optimal layout, and export the SGAM models in an XML format based on
an extension of IEC 62559-3 data model.
DISCERN Use Case Template

Template developed in Microsoft Word to create Use Cases. It guides users through the creation of
consistent Use Cases and includes an XML export based on IEC 62559-3 data model.
21 | 151
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.
DISCERN Use Case Management Repository

Web application to store and manage Use Cases, SGAM models, and libraries. Its main features are:
multi-editing of Use Cases and libraries; drag & drop of actors, functions, requirements into the Use
Cases; presentation of SGAM models in an 3-D visualisation tool; importing descriptions in XML files;
and exporting Use Cases in MS Word and SGAM models as well as libraries in XML.
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.
1.2 SCOPE OF THE DOCUMENT
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.
Therefore, D1.3 is focused on communication protocols. More precisely, interchange of information

between equipment involved in the subfunctionalities [reference]. That is the application layer. In this
case the complete names of protocols are requested for identification and Gap Analysis. The equipment
part is managed from a more qualitative approach describing the interchangeability (e.g. equipment
dimensions requirements). This is because existence of particular norms at company and national level.
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
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
FIGURE 4: DIFFERENT DIMENSIONS OF STANDARDS
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
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.
TABLE 1: STRUCTURE OF TABLE TO CLASSIFY PROTOCOLS AND EQUIPMENT IN THE DEMONSTRATORS
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
TABLE 2: STRUCTURE OF THE TABLE TO CLASSIFY DEMONSTRATORS PROTOCOLS
TABLE 3: STRUCTURE OF THE TABLE TO CLASSIFY DEMONSTRATORS EQUIPMENT
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
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)
Description of used Standards / Proprietary protocols - equipment

Brief description
For what functionality (related to D1.1) [1]
Experience of using it e.g. years of using, other projects, products in the market, contribution to the
standardization process (national committee, international committee)
Reason for selecting it (including the case if there was a set of equivalent protocols - equipment)
Description of proposed standard protocol - equipment

Brief description
Experience of using it e.g. years of using, other projects, products in the market, contribution to the
standardization process (national committee, international committee)
Risk for using e.g. time of developing or specified the profile, future standard upgrades
Reason for selecting it (including the case if there was a set of equivalent protocols - equipment)
Description of Development of extensions to a standard protocol - equipment / protocol profiles -

equipment to be developed (and possible standardization process)
Brief description
Reason for doing a new development instead of using existing protocols - equipment
Risk for developing the solution e.g. time of developing or specified the profile, future standard
upgrades
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
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]
Standards bring numerous benefits to business and society, such as:
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
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
Compatibility between versions
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
TABLE 4: LIST OF UPGRID PROTOCOL IMPACTS

List of protocols Impact on
Interoperability Interchangeability Scalability Replicability
Used standardised protocols
Protocols name
Proposed standard protocols, proposed standard
profiles
Protocols name
Used proprietary protocols
Protocols name
New standards to be developed, new extensions to
standard to be developed, new profiles to be
developed
Protocols name
TABLE 5: LIST OF UPGRID EQUIPMENT IMPACTS

List of equipment Impact on
Include protocols in coherency with the first table Interoperability Interchangeability Scalability Replicability
Used standard equipment
Protocols name
Proposed standardised equipment to be used
Protocols name
Used non-standardised equipment
Protocols name
Development of new equipment (and Possible
standardization process)
Protocols name
30 | 151
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
Chapter 5 & 6
FIGURE 6: COMPLETE METHODOLOGY APPLIED IN D1.3
32 | 151
3. INITIAL DEMONSTRATIONS APPROACH TO STANDARDS

AND EQUIPMENT
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.
3.1 SPANISH DEMONSTRATOR
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
TABLE 6: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE SPANISH DEMONSTRATOR
DEMO BASE DEMO DEVELOPED UNDER UPGRID
Used standard protocols Proposed standard protocols to be used

DLMS COSEM PRIME 1.3.6
Transport layer for SMs provided data 4-32/PRIME IP convergence sublayer
Transport layer for line monitoring units CTI hdlc/rs485
Data model for SMs: T5 Spanish Companion Specification
Data model for line monitoring units CTI: CTI Companion
Specification
PRIME 1.3.6 SNMPv3 for MIB collection
4-32 convergence sub-layer
SMs profile
ICCP / TASE2 (IEC 60870-6-503) ICCP / TASE2 (IEC 60870-6-503)
IEC 60870-5-104 IEC 60870-5-104
CIM (IEC 61968, IEC 61970, IEC 62325)
Development of new protocols / Development of extensions to a
Used proprietary protocols standard protocol / protocol profiles to be developed (and
Possible standardization process)
STG-DC 3.2 for SMs management DLMS COSEM
Data model for line monitoring units CTI: CTI Companion
Extend STG 3.2 to include Line Supervision
Particular profile of CIM
34 | 151
TABLE 7: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE SPANISH DEMONSTRATOR
Used standardised equipment Proposed standardised equipment to be used

PRIME SM N/A
Line Monitoring Units
Data concentrators
Development of new equipment (and possible standardization
process)
N/A PRIME Base node that supports both application, IP and SMs
PRIME service node for IP communications
SW system for PRIME Base Nodes MIB's query
35 | 151
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.
3.1.1.1 DESCRIPTION OF USED STANDARDS PROTOCOLS / PROPRIETARY PROTOCOLS
These protocols are described briefly as follows:
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.
The DLMS/COSEM defines (source: DLMS user association):
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
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
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.
3.1.1.2 DESCRIPTION OF PROPOSED STANDARD PROTOCOL
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.
IEC 104 Use of the pure definition - no modifications/gaps anticipated.
ICCP / TASE2: use the pure definition - no modifications/gaps anticipated.
3.1.1.3 DESCRIPTION OF DEVELOPMENT OF EXTENSIONS TO A STANDARD PROTOCOL / PROTOCOL

PROFILES TO BE DEVELOPED (AND POSSIBLE STANDARDIZATION PROCESS)
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
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.
Web services SOAP Profile: Defined in STG-DC specification

As stated before, this standard uses XML for its message format, and relies on Hypertext Transfer
Protocol (HTTP) for message negotiation and transmission.
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
TABLE 8: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE SPANISH DEMONSTRATOR
Cluster, Function Objectives & Subfunctionalities Main protocols
Cluster 3: Network operations
D7 Monitoring and control of LV networks
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 Network management methodologies for network operation
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
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 Smart metering data utilisation
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)
Cluster 4: Network planning and asset management
D11 New planning approaches for distribution networks
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 Novel approaches to asset management
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
Cluster 5: Market design
D13 New approaches for market design
D13.1 Web portal for increasing the consumer awareness in order to leverage their participation N/A
in electricity markets
41 | 151
3.1.2 EQUIPMENT
The main equipment used in the Spanish demonstrator and classified in

Table 7 is included in the following figures. Figure 7 shows the architecture behind sub-functionalities
dealing with metering data acquisition from field and PRIME as multiservice facilitator; while Figure 8
depicted the list of pieces of equipment indicating their location on the field, functionality and main
protocols used by each of them.
FIGURE 7: ARCHITECTURE FOR SUB-FUNCTIONALITIES IN THE SPANISH DEMONSTRATION DEALING WITH THE DATA
METERING ACQUISITION FROM FIELD (SOURCE: ZIV)
42 | 151
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)
3.1.2.1 DESCRIPTION OF USED STANDARDISED EQUIPMENT / NON STANDARDISED 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. 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
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
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
FIGURE 9: DISTRIBUTED NETWORK
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
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)
Equipment from different manufactures is used in the demonstrator.
Line Monitoring Units (Advanced LV Supervisor):

The ZIV model 5CTI provides information on the probability of a service node being connected to
each one of the LV lines. They will be responsible of measuring the PRIME signal power coming from
each of the meters at the head-end of each one of the LV lines coming out of the LV busbar. The
measurements needed are those of received current, obtained via inductive coupling. This
information will be sent to the Data Concentrator.
This equipment also registers for LV advanced supervision:

Measurement data for the feeder: V, I, P, Q, PF per phase.
Registers (load profile) programmable (interval) for feeder:
Active and Reactive Energy registration (Active in both directions and reactive in the 4 quadrants).
By default 1 hour.
Average voltage per phase, average current per phase, average apparent power and average
neutral current (calculated). By default 10 min.
Maximum (measurement in a cycle) voltage per phase, maximum current per phase, maximum
apparent power and maximum neutral current (calculated). By default 10 min.
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
3.1.2.2 DESCRIPTION OF PROPOSED STANDARD EQUIPMENT
Neither SMs nor Advanced LV supervisor will be installed within UPGRID project.
3.1.2.3 DESCRIPTION OF DEVELOPMENT OF NEW EQUIPMENT (AND POSSIBLE STANDARDIZATION

PROCESS)
PRIME Base node that supports both application, IP and SMs

PBN is a compact PRIME Base Node specially designed for its installation in secondary substations or
transforming centres. Its main goal is to provide power line connectivity to a set of PRIME service
nodes attached to the power grid. PBN main advantages are summarized below:
Advanced management features via SNMP, http or ZPM (ZIV PRIME Manager tool), which includes
PHY Layer diagnostic tool
PRIME subnetwork topology management
PRIME protocol analyser
Firmware upgrade of all ZIV PRIME network devices via multicast connections
Flexible coupling capabilities, which allow simultaneously transmitting and receiving information
over the three power phases.
This device is being evolved including PRIME 1.3.6 IP convergence sublayer.
PRIME service node for IP communications

Compact PRIME Base Node specially designed for its installation in secondary substations or
transforming centres. This device can also act as a service node, being part of a set of PRIME service
nodes attached to the power grid. This device is being evolved including PRIME 1.3.6 IP convergence
sublayer.
SW system for PRIME Base Nodes MIB's query

In the scope of UPGRID project a PRIME management demo system will be deployed by ZIV for
monitoring a maximum of 50 secondary substations. This SW system will be oriented to the use case of
the demonstration, supporting de data acquisition of the PRIME Base Nodes SNMP objects identifiers
(OIDs) defined. PRIME Base Nodes SNMP objects identifiers (OIDs) definition is within the scope of
UPGRID project. The object list required to cover monitoring use case will be defined, specified,
developed and validated within this demo.
47 | 151
3.2 PORTUGUESE DEMONSTRATOR
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
TABLE 10: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE PORTUGUESE DEMONSTRATOR

IEC60870-5-104 IEC60870-5-104
Light Protocol Implementation Document (LPID) for IEC 60870- Light Protocol Implementation Document (LPID) for IEC 60870-
5-104 defined by EDP Distribuio 5-104 defined by EDP Distribuio
PRIME PRIME
Version 1.3.6 established by PRIME Alliance Version 1.3.6 established by PRIME Alliance
PRIME MAC & PHY layers (PLC) PRIME MAC & PHY layers (PLC)
PRIME 4-32 convergence sub-layer PRIME 4-32 convergence sub-layer
49 | 151
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
reading, tariff and load control Part 46: HDLC reading, tariff and load control Part 46: HDLC
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)
reading, tariff and load control Part 53: COSEM application reading, tariff and load control Part 53: COSEM application
layer layer
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
MODBUS over serial line MODBUS over serial line

MODBUS APPLICATION PROTOCOL SPECIFICATION, V1.1b for MODBUS APPLICATION PROTOCOL SPECIFICATION, V1.1b for
HAN interface of the EDP Box HAN interface of the EDP Box
HAN interface N/A
Data model and communication protocol for the HAN interface
of the EDP Box
TABLE 11: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE PORTUGUESE DEMONSTRATOR

PRIME SM EDP Box PRIME SM EDP Box
DTC Distribution Transformer Controller DTC Distribution Transformer Controller
Router Router

process)
N/A HEMS (Gateway and Homeplug)
51 | 151
3.2.1 PROTOCOLS
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.
MODBUS is a request/reply protocol and offers services specified by function codes. It is an

application layer messaging protocol, positioned at level 7 of the OSI model, which provides
client/server communication between devices that can be connected on different types of buses or
networks. In this case, an asynchronous serial line protocol over EIA-485 is used.
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
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.
SNMP (Simple Network Management Protocol), is an "Internet-standard protocol for managing

devices on IP networks". SNMP is used mostly in network management systems .SNMP is a
component of the Internet Protocol Suite as defined by the Internet Engineering Task Force (IETF). It
consists of a set of standards for network management, including an application protocol layer, a
database schema, and a set of data objects.
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.

No protocols expected under this category.
53 | 151
TABLE 12: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE PORTUGUESE DEMONSTRATOR
Cluster 1: Integration of Smart customers
D1 Active Demand for increased network flexibility
PRIME, DLMS/COSEM, Web services SOAP (STG-

D1.1 LV customer consumption characterization
DC 3.1.c)
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)
Cluster 2: Integration of DER and new uses
D3 Integration of DER at low voltage
D3.1 Remote management of DER Web services SOAP (STG-DC 3.1.c)
D6 Integration of infrastructure to host Electrical Vehicles
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
D7.8 Integration of LV power flow and MV power flow analyses N/A
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
D9.7 Load and distributed generation forecasting 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
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
D13.4 Dynamic contractual power control N/A
56 | 151
3.2.2 EQUIPMENT
The main equipment used in the Portuguese demonstrator and classified in Table 11 is depicted in
Figure 11.
FIGURE 11: ARCHITECTURE OF PORTUGUESE DEMONSTRATOR
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
PRIME SM (EDP Box)

The EDP Box (Figure 12) has the capability of remote communication for network management,
remote management and telemetering of the client, allowing for future changes or addition of new
features. It supports a connection to the clients devices or to distinct metering equipment, by
addition of an adequate HAN communication module. Protocols used in the EDP Box with PLC PRIME
and GPRS technology are indicated in Figure 13 and Figure 14 respectively.
FIGURE 12: MAIN CHARACTERISTICS OF THE EDP BOX
58 | 151
FIGURE 13: PROTOCOLS FOR EDP BOX PLC PRIME
FIGURE 14: PROTOCOLS FOR EDP BOX GPRS
59 | 151
DTC (Distribution Transformer Controller)

The DTC unit has key functions that are summarised below:
Concentrator feature:
Management of network monitoring terminal equipment, remote management and metering
(designated by EDP Box or EB), which are installed in customer promises of LV network associated
with the DTC. This management includes configuration, information collection and sending
commands to the EBs, as well as managing the communications network with that equipment.
This feature also includes communication with the central information systems, in particular the
commercial ones.
Monitoring and management of the LV network feature:
Analysis of power transformer data from EDP Box (e.g., events, alarms, power consumption) to
manage the LV network. Sensoring monitoring (e.g., PT cabin door open) and/or management of
devices (e.g., temperature sensor) of power transformer or secondary substation. The DTC also
support future growth of other functions such as the management and controlling of electric
vehicle charging. This feature further includes communication with the central information
systems, in particular the technical ones (SCADA).
FIGURE 15: MAIN CHARACTERISTICS OF THE DTC
Same equipment described in the previous section.
60 | 151

PROCESS)
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
3.3 SWEDISH DEMONSTRATOR
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
TABLE 13: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE SWEDISH DEMONSTRATOR

OSGP ETSI GS OSG 001 - Open Smart Grid Protocol for both OSGP
measurements and events between SM<->DC<->AMI Head End
system
GS2* - Message based protocol for measurement values (meter GS2
stands and hourly values) between AMI Head End and Vattenfall
(MDMS)
*GS2 stands for "GrnsSnitt2" or "Interface2", which is an object

oriented data model, similar to XML, for handling metering and
settlement information. The model was developed in Norway by
SINTEF Energy Research during the 90's at the time for the de-
regulation process in Sweden. Used today in Norway and Sweden.
XML - Message based protocol for events from SM from AMI Head XML
End system and Vattenfall PER-system (PerformanceEventReport
system)
PLC - Power Line Communication, using both A and C band, and PLC
different frequencies. Communication carrier between the SM and
DC.
A-band is for communication between SM and DC and C-band for
communication between SM and in-home devices. In UPGRID
project, just A-band will be used.
63 | 151
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
N/A N/A
64 | 151
TABLE 14: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE SWEDISH DEMONSTRATOR

Echelon SMs (SM) SMs
Echelon Data Concentrators (DC), (with built in GPRS Meter Data Concentrators, (with built in GPRS communication
communication modem or with Ethernet connection for an modem or with Ethernet connection for external modem/router)
external modem/router)
Schneider Electric Smart Transformer
RTU devices (or equivalent IED) for MV and LV measurement in
secondary substations (10-20/0.4 kV)
FPI - Fault passage Indicators for fault detection and localisation on
MV network
Modem/router for GPRS/2G/3G or other secured communication
Re-closer/breaker for remote network operation/automation1
CT - Current Transformers in secondary substation.
(Others, which may be tested are Rogowski Current Transformers,
micro snap-on CT)
CT - Current Transformers for MV network FPIs
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

process)
N/A N/A
66 | 151
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
FIGURE 16: SIMPLIFIED DESCRIPTION OF STANDARDS USED FOR SM CONNECTION TO OVERLYING SYSTEM HIERARCHY
68 | 151
FIGURE 17: SIMPLIFIED DESCRIPTION OF STANDARD USED FOR MV NETWORK FPI AND LV NETWORK SECONDARY
SUBSTATION CONNECTION TO OVERLYING SYSTEM HIERARCHY
69 | 151
TABLE 15: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE SWEDISH DEMONSTRATOR
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)
D8 Automation and control of MV networks
D8.1 Monitoring MV network by fault detectors .104 over GPRS is to be used
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
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
3.3.1 MAPPING ON SGAM
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.
3.3.1.1 COMPONENT LAYER
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
Market
Enterprise
NIS MDM
Operation
AMI
MV LV LV Head End
SCADA-DMS SCADA DMS
LV
Monitoring
Meter Data Station

RTU / FPI Concentrator
Field
Fault Passage Wireless Smart
Indicator (FPI) Current Meter
Sensor
Re-closer Smart
/breaker Transformer
Process
MV LV
Generation Transmission Distribution DER Customer

FIGURE 18: SGAM COMPONENT LAYER FOR THE SWEDISH DEMONSTRATOR ARCHITECTURE
This list of system components that are identified in Figure 18 are:
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
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.
3.3.1.2 COMMUNICATION LAYER
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
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
OSGP ETSI GS OSG

GPRS
001 over GPRS

0870
LV
Over
PR
IEC 6
Monitoring
rG
IEC 60870-5-104
ove
over GPRS
Meter Data
FTP
Station
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
Sensor
Re-closer Smart
Process
MV LV

FIGURE 19: SGAM COMMUNICATION LAYER FOR THE SWEDISH DEMONSTRATOR ARCHITECTURE
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
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.
The standardized communication protocols used are:
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
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.
3.3.1.3 INFORMATION LAYER
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
Market
Enterprise
NIS MDM
CIM Data Model
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
Meter Data Station

IEE OSG
E1 P b
37
7 a ased
nd o
AN n
SI C Field
Fault Passage Wireless 12 Smart
Sensor
Re-closer Smart
Process
MV LV

FIGURE 20: SGAM INFORMATION LAYER FOR THE SWEDISH DEMONSTRATOR ARCHITECTURE
The standardized information models and data formats used are:
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
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.
3.3.1.4 FUNCTION LAYER
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
D9: Network management

methodologies for network operation Operation
AMI
MV LV LV Head End
SCADA-DMS SCADA DMS
control LV network
D7: Monitoring and
LV
Monitoring
D8: Automation and Meter Data Station

control of MV network
Field
Sensor
Re-closer Smart
Process
MV LV

FIGURE 21: SGAM FUNCTION LAYER FOR THE SWEDISH DEMONSTRATOR ARCHITECTURE
79 | 151
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
3.3.2 DESCRIPTION OF THE USED STANDARDS PROTOCOLS / PROPRIETARY PROTOCOLS
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
The experience of using the previous protocols is indicated as follows:
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.
Main reasons for having selected the previous protocols are:
Re-use of existing infrastructure and applications.

OSGP: These SMs like others in OSGP deployments, report not just hourly readings, but efficiently
provide extended load profile 15 minute interval data, power quality reports, and integration with
home energy networks with perfect daily performance of every meter between 99,8 and 100%. In
addition, OSGP is supported by a variety of meter and smart grid device suppliers that offer or
plan to offer solutions compliant with the standard including, Romanian AEM, General Electric,
Mitshubishi Electric, Korea's VIDCOM, Malaysia's Comintel, China's Holley Metering, Brazil's ELO,
Austria's Ubitronix and Kapsch, furthermore Germany's Diehl, and Grlitz with a Landis & Gyr
based solution.
GS2: The model was developed in Norway during the 90's at the time for the de-regulation
process in Sweden. Used today in Norway and Sweden.
Proprietary protocols are not foreseen in the Swedish demonstrator.
3.3.3 DESCRIPTION OF PROPOSED STANDARD PROTOCOL
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
TABLE 17: SUMMARY OF PROPOSED STANDARD PROTOCOL INTERFACES IN THE SWEDISH DEMONSTRATOR
Information Layer
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
Information Layer
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
The main uses of the previous protocols are indicated as follows:
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
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:
CIM information model is proposed by CENELEC/IEC TC 57 reference architecture (standardised as

IEC 62357) and supported - or under pilot development phase - by the NIS and SCADA-DMS systems
at Vattenfall.
ZigBee: General selection criteria are:
Power saving, as a result of the short working period and low power consumption of
communication.
Collision avoidance is adopted
Low cost of the modules, and the ZigBee protocol is patent fee free
Short time delay
3.3.4 DESCRIPTION OF DEVELOPMENT OF EXTENSIONS TO A STANDARD PROTOCOL /

PROTOCOL PROFILES TO BE DEVELOPED (AND POSSIBLE STANDARDIZATION PROCESS)
No extensions of standard protocols are foreseen in the Swedish demonstrator.
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
and that the herein referred to standards will be further developed to replace legacy systems and
protocol solutions.
3.4 POLISH DEMONSTRATOR
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
TABLE 18: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE POLISH DEMONSTRATOR

PRIME Specification revision 1.3.6. PRIME Alliance 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
DLMS/COSEM Architecture and Protocols. Green book 8th IEEE 1815 Std.: IEEE Standard for Electric Power Systems
edition. Technical report. DLMS User Association, 2014 CommunicationsDistributed Network Protocol (DNP3). Revised
COSEM Identification System and Interface Classes. Blue Book edition, 2012
12th edition. Technical report. DLMS User Association, 2014.
STG-DC 3.1 IEC 61970 Std.: Energy Management System Application Program
Interfaces EMS-API
IEC 61968 Std.: Application Integrational Electric Utilities - System
Interfaces for Distribution Management
IEC 61968-100 Std.: Application integration at electric utilities -
System interfaces for distribution management - Part 100:
Implementation profiles
IEC 62325-301 Std.: Framework for Energy Market Communication
DC-SAP (Data Concentrator - Simple Acquisition Protocol) DLMS/COSEM Extensions for PRIME PLC LV monitoring and control
unit
86 | 151
TABLE 19: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE POLISH DEMONSTRATOR

PRIME SMs IEEE 60870-5-104 or IEEE 1815 Monitoring and control units for
MV/LV substations
PRIME Data concentrators
Wireless GSM GPRS/EDGE/UMTS, CDMA
modems/routers/switches for MV/LV substations
process)
N/A DLMS/COSEM/PRIME Monitoring and control units for LV DER
equipment
87 | 151
3.4.1 PROTOCOLS
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
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]
control Part 61: Object identification system (OBIS). Second edition, 2006 [29]
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.
Standards used for indirect data transmission via AMI system:

CIM
Relevant CIM classes will be used to exchange information gathered and made available by the
AMI system, focused on meter measurements and events.
Specific messaging profile will be defined.
89 | 151
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.
Standards used for direct communication with SGM&C units:

IEC 60870-5:
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
[32]
IEC 60870-5-101 Std. Telecontrol equipment and systems Part 5-101: Transmission protocols
Companion standard for basic telecontrol tasks. Second edition, 2003 [33]
IEC 60870-5-5 Std. Telecontrol equipment and systems - Part 5: Transmission protocols -
Section 5: Basic application functions. 1995 [34]
DNP3 over IP:
IEEE 1815 Std.: IEEE Standard for Electric Power Systems CommunicationsDistributed
Network Protocol (DNP3). Revised edition, 2012 [35]

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
Full documentation of the newly defined classes will be provided.
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
TABLE 20: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE POLISH DEMONSTRATOR
Cluster 2: Integration of DER and new uses
D3 Integration of DER at low voltage
DLMS/COSEM Extensions for PRIME PLC LV monitoring

D3.1 Remote management of DER
and control unit
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
D8 Automation and control of MV networks
D8.1 Monitoring MV network by fault detectors IEC 60870-5-104; IEEE 1815
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
D9.7 Load and distributed generation forecasting N/A
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 New planning approaches for distribution networks
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
D13.1 Web portal for increasing the consumer awareness in order to leverage their participation in electricity HTTPS
markets
94 | 151
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.
Smart meters typically provide the following measurements:

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 (cos fi).
Polish demo SMs are compliant with the Energa PRIME SMs companion, which is similar to Spanish
T5 specification, with specific modifications.
PRIME 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:
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
FIGURE 22: THREE LEVELS OF MONITORING IN SECONDARY SUBSTATION

PROCESS)
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
4. IMPACT OF STANDARDISATION IN UPGRID
4.1 SPANISH DEMONSTRATOR
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
TABLE 21: IMPACTS FOR THE UPGRID SPANISH DEMONSTRATOR PROTOCOL LIST
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 1.3.6 - IP CS
Assured if a clear MIB file is A MIB file is required. Not an issue. Not an issue.
SNMPv3
specified.
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

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.
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 extension
reports/orders defined. required even though a clear applicable.
definition is provided.
TABLE 22: IMPACTS FOR THE UPGRID SPANISH DEMONSTRATOR EQUIPMENT LIST
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

Assured if the monitoring It is no so obvious. Note that Not an issue. The same applies as with
unit complies with the apart from protocols, there interchangeability.
protocols definition (includes are several HW
companion specification for characteristics that differ
Line monitoring units DLMS), telecom interfaces from the different countries
(such as the number of
communication ports,
dimensions, installation
limitations...)
Assure if the data It is no so obvious. Note that Not an issue. The same applies as with
concentrator complies with apart from protocols, there interchangeability. Apart from
the protocols definition are several HW that, note that different
(includes companion characteristics that differ countries require additional
Data concentrators specification for DLMS), from the different countries features. For instance, in the
telecom interfaces (such as the number of monitoring of the secondary
communication ports, of the transformer,
dimensions, installation telecontrol features
limitations...)
Proposed standardised equipment
to be used
N/A
N/A
Development of new equipment
(and possible standardization
process)
100 | 151

Required the definition on Definition of interfaces such Not an issue. The same applies as with
how to transport DLMS as the data concentrator interchangeability.
PRIME Base Node
traffic - interface with a data interface or the IP interface
concentrator
Definition of the IP Definition of the IP Not an issue. The same applies as with
PRIME Service Node
functionality (NAT support?) functionality (NAT support?) interchangeability.
SW System for PRIME network Assured if a clear MIB file is A MIB file is required. Not an issue. Not an issue.
management specified.
101 | 151
4.2 PORTUGUESE DEMONSTRATOR
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
2
TABLE 23: IMPACTS FOR THE UPGRID PORTUGUESE DEMONSTRATOR PROTOCOL LIST
Specific data model required Depend on the data model Depend on the data model.
DLMS/COSEM (companion specification) and transport layer.
PRIME compliance tests by a PRIME compliance test by a

PRIME
Web services SOAP (STG-DC 3.1.c) Specific
Specific MIB definition Depend on the MIB Depend on the MIB
SNMP
required
(same protocols indicated above)
HAN interface Specific data model required Specifica hardware interface Depend on the data model
(RS-485 on RJ12 connector)
developed
N/A
2
Empty cells mean Not Applicable or Not an Issue
103 | 151
3
TABLE 24: IMPACTS FOR THE UPGRID PORTUGUESE DEMONSTRATOR EQUIPMENT LIST
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 )
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
DTC
other specifications
(mechanical specification,
dimensions, HMI )

to be used
(same equipment indicated above)
N/A
3
Empty cells mean Not Applicable or Not an Issue
104 | 151

process)
N/A
105 | 151
4.3 SWEDISH DEMONSTRATOR
Table 25 summarises the main impacts of the identified protocols presented in Table 13 for the Swedish
106 | 151
TABLE 25: IMPACTS FOR THE UPGRID SWEDISH DEMONSTRATOR PROTOCOL LIST
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

ZigBee Different sensors supporting ZigBee is not standardizing The solution is limited by the The solution can be
(SGAM: Field Station) ZigBee can be connected to on information level, so RTU. The limitation is not duplicated at another
the same RTU. Different interchangeability is poor for known but not perceived to location given that the RTU
RTUs can be connected to different sensors. be an issue. supports ZigBee.
the sensors, if they support
ZigBee.
FTP (RFC959) over GPRS FTP offers a high level of Limited. File format and The solution is limited by the The solution can be
(SGAM: Station Operation) interoperability for file content is not standardised. LV monitoring system. The duplicated at another
sharing. limitation is not known but location but only using the
not perceived to be an issue. same LV monitoring system.
Other RTUs could be used as
long as they provide the
required information to be
used by the LV Monitoring
Application.
IEC 60870-5-104 over GPRS The -104 protocol offers a The -104 protocol offers a Vattenfall has today 1000 IEC 60870-5-104 over GPRS.
(SGAM: Station Operation) high level of interoperability. high level of MV station but integrating
interchangeability where also several thousand LV
most RTU on the market can stations to SCADA-DMS
fulfil the utility ASDU would be challenging. The
addressing and interop solutions only foreseen for
specification. strategic LV station with
Also fault passage indicators power quality issues.
are assumed to use -104.

108 | 151

WP3 Web Services exchanging GS2 or Integration bus horizontally Interchangeability would The ability to exchange The replicability is dependent
CIM information models between AMI front end, LV require standardizing the gathered information on the amount of support for
(SGAM: Operation & Enterprise) Monitoring and SCADA-DMS information content between multiple standardized information
as well as vertically to NIS between the involved applications on operation exchange on application
and MDM require a level of systems. This is not within and enterprise level is limited level, and therefore foreseen
high level of standardization the WP5 scope. by the amount of domain to be limited.
regarding the information specific standardized
modelling therefore CIM will information models that the
be considered for use. applications support.
Scalability is expected to be
limited due to dedicated
solutions for information
exchange in practice today.
N/A
developed
N/A
109 | 151
TABLE 26: IMPACTS FOR THE UPGRID SWEDISH DEMONSTRATOR EQUIPMENT LIST
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.
to be used
SMs See above. See above. See above. See above.
110 | 151

Meter Data Concentrators, (with See above. See above. See above. See above.
built in GPRS communication
modem)
Schneider Electric Smart Transformer Data exchange between the Limited, since the core Limited, mainly due to the High, since the booster
MV/LV booster transformer feature of the transformer is investment cost for the transformer is designed to
and an overlying application, the function for voltage transformer. This type is suit network operations in
e.g. MV SCADA, should be regulation, i.e. to limit or designed for LV networks general, where voltage
interoperable with those even eliminate the impact of where voltage fluctuation fluctuation is required to be
system managing to receive voltage fluctuation on the LV cannot be easily handled in managed in order to fulfil
data in the formats used by lines. But any transformer another way without larger quality of supply. One
the booster transformer, i.e. with this function using network re-constructions. limitation may be the size of
IEC 104 protocol. In the standardised IEC 104 E.g. the network situation the transformer, since the
Swedish demonstration this protocol should be possible has changed due to booster part increase the
will be tested, since the to replace with this model. increased DER installation size. This requires some more
ambition is to integrate this (If this voltage regulation etc. space for the installation.
booster transformer against feature is not necessary, this
existing MV SCADA platform type of transformer would
Power on Fusion, supplied not be installed).
by General Electric.
111 | 151

RTU devices (or equivalent IED) for If the RTU (or IEDs) are using If the RTU (or IEDs) are using For the entire system model, In general the same solution
LV measurement in secondary a standardized protocol for a standardized protocol for i.e. RTU communication with should be possible to install
substations (10/0.4 kV) information sharing, information sharing, an overlying LV SCADA/DMS in any secondary substation,
interoperability should be interchangeability should be platform, there should be no large (concrete) as small (pole
high. Any RTU/IED should be high. Any RTU/IED should be limitation in the number of mounted). One limitation
able to communicate with able to communicate with RTUs/IEDs being connected. may arise due the different
an overlying system using an overlying system using One limitation may be ages of the substations,
the same protocol interface. the same protocol interface. noticed for single secondary which may cause technical
This will specifically be This will specifically be substations with several challenges for the
tested in the Swedish tested in the Swedish (>15) outgoing LV lines. If installation. One such
demonstration, using demonstration, using each line is being measured example could be the size of
RTUs/IEDs from different RTUs/IEDs from different this require many devices, the low voltage switchgear
manufacturers and integrate manufacturers and integrate not perhaps RTUs but case, which may not be able
these against several these against several connected "meter modules" to allow for the CT
(different) LV SCADA/DMS (different) LV SCADA/DMS per LV line. The limitation installations.
systems. systems. may be the space required
in the secondary substation
for the installation.
112 | 151

FPI - Fault passage Indicators for fault If the FPIs (or "sensors") are If the RTU (or IEDs) are using The number of FPIs/sensors In general the same solution
detection and localisation on MV using a standardized a standardized protocol for is not a limiting factor. The should be possible to install
network protocol for information information sharing, entire solution should be in MV network.
sharing, interoperability interchangeability should be able to include as many FPIs One limitation may be the
should be high. Any high. Any RTU/IED should be as required. Each FPI is point required network pre-
FPI/sensor should be able to able to communicate with to point connected to the requisites. In order to achieve
communicate with an an overlying system using overlying system. The the correct technical pre-
overlying system using the the same protocol interface. required number of FPIs per requisites the network may
same protocol interface. The This will specifically be MV feeder depends on the need to be re-constructed,
ambition is to test this in the tested in the Swedish network topology, number e.g. poles may need to be in a
Swedish demonstration, demonstration, using of intersections, how precise certain length etc., which
using FPI/sensors from RTUs/IEDs from different the fault detection and makes the installation much
different manufacturers and manufacturers and integrate localisation should be etc. more complicated and costly.
integrate these against these against several One limitation may be the The installation also needs
existing MV SCADA/DMS (different) LV SCADA/DMS required network pre- the feeder to be out of
systems. systems. requisites. In order to service, with power outages
achieve the correct technical for the customers as a result.
pre-requisites the network
may need to be re-
constructed, e.g. poles may
need to be in a certain
length etc., which makes the
installation much more
complicated and costly. The
installation also needs the
feeder to be out of service,
with power outages for the
customers as a result. 113 | 151

Modem/router for GPRS/2G/3G or Different modems/routers One modem/router should No limitation if the volume No limitation, except for the
other secured communication should be possible to use. be possible to exchange of assigned IP-addresses is communication service
One requirement usually is with another, if they have sized to hold the total provided by the operator.
that the modem/router has equivalent ports for IED volume of connected Any modem/router should be
a port for Ethernet connections. Another devices. possible connect to the
connection, unless the limitation is if the operator despite the location
device does not use a built communication is restricted in the communication
in modem, like the Echelon with IT security regulations, network, e.g. GPRS, cover the
DCs used in the Vattenfall where only certain area.
SM process. Another modems/routers have been
limitation is if the approved for network
communication is restricted operations, e.g. remote
with IT security regulations, breaker operations etc.
where only certain
modems/routers have been
approved for network
operations, e.g. remote
breaker operations etc.
114 | 151

Re-closer/breaker for remote Data exchange between a One re-closer/breaker, with One limitation may be the One limitation may be the
network operation/automation MV network re- the same technical communication service communication service
closer/breaker and an specification, should be provided at the location for provided at the location for
overlying application, e.g. possible to re-place with the re-closer/breaker. In the re-closer/breaker. In
MV SCADA, should be another re-closer/breaker some rural areas some rural areas
interoperable with those from another manufacturer. communication may not communication may not
systems managing to receive The ambition is to test this exist, why a remote exist, why a remote operable
data in the formats used by in the Swedish operable re-closer/breaker re-closer/breaker may not be
re-closer/breaker. demonstration and integrate may not be an option to an option to install.
the "demo" re- install.
closer/breaker with the
existing MV SCADA/DMS
system.
CT - Current Transformers in May be limited, depending May be limited, depending Unlimited if the installation Unlimited if the installation
secondary substation. on the integration interface on the integration interface space in the low voltage space in the low voltage
(Others, which may be tested are between the CT and the between the CT and the switchgear allows for the switchgear allows for the size
Rogowski Current Transformers, RTU/IED or the "meter RTU/IED or the "meter size of the CTs to be of the CTs to be connected to
micro snap-on CT) module" in between the module" in between the connected to the wires. In the wires. In some cases
RTU/IED and the CT. RTU/IED and the CT. some cases some LV some LV switchgears are too
Different types are used, Different types are used, switchgears are too small small where the CT is to be
e.g. wireless using ZigBee or e.g. wireless using ZigBee or where the CT is to be connected around the wire.
with cable. with cable. connected around the wire.
115 | 151

CT - Current Transformers for MV Assumed to be good, many Assumed to be good, many See answer for FPI above / See answer for FPI above /
network FPIs manufacturers of current manufacturers of current Scalability. Replicability.
transformers are transformers are
interoperable with IEDs, e.g. interchangeable to connect
RTUs, FPIs/sensors etc., with IEDs, e.g. RTUs,
independent of the supplier. FPIs/sensors etc.,
Integration in most cases independent of the supplier.
based on cable, using Integration in most cases
standardised protocols. One based on cable, using
limitation may be if the standardised protocols. One
FPI/sensor only can be limitation may be if the
wirelessly integrated with FPI/sensor only can be
CTs. In this case, a certain wirelessly integrated with
type of CTs may be required. CTs. In this case, a certain
type of CTs may be required.
N/A
process)
N/A
116 | 151
4.4 POLISH DEMONSTRATOR
Table 27 summarises the main impacts of the identified protocols presented in Table 18 for the Polish
117 | 151
TABLE 27: IMPACTS FOR THE UPGRID POLISH DEMONSTRATOR PROTOCOL LIST
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 1.3.6 - 4-32 CS
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.
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

IEEE 1815: IEEE Standard for Electric Yes, as long as required Yes, as long as required Not an issue. Full this is a widely
Power Systems Communications functions are equally functions are equally recognised standard.
Distributed Network Protocol (DNP3). implemented by implemented by
Revised edition, 2012 interoperable interoperable
equipment/software. equipment/software.
IEC 61970.: Energy Management Yes, according to the defined Can be assured by Not an issue. Full this is a widely
System Application Program data exchange profile. interoperability (IOP) tests. recognised standard.
Interfaces EMS-API
IEC 61968: Application Integration at Yes, according to the defined Can be assured by Not an issue. Full this is a widely
Electric Utilities - System Interfaces data exchange profile. interoperability (IOP) tests. recognised standard.
for Distribution Management
Yes, according to the defined The IEC 61968-100 is well Not an issue. Full this is a widely
IEC 61968-100: Application
data exchange profile. defined and its expected that recognised standard.
integration at electric utilities -
IEC61968-100 compliant
System interfaces for distribution
applications are
management - Part 100:
interchangeable (function-
Implementation profiles
wise).
Relatively easy to achieve An interoperability test is Not an issue. Not an issue if the defined
since the specification is fully advised to prove full services can be properly
DCSAP open, moreover a reference interchangeability. Reference implemented (reference
implementation is available. implementation may be implementation available).
helpful.
119 | 151

developed
A fully documented Once the extensions are Not an issue. The definition of the
extension definition will be implemented into other LV extension will be available,
DLMS COSEM extensions for LV
provided to assure possible monitoring and control so proper (replicable)
monitoring and control units
interoperability. devices, they will be implementations will be
interchangeable. possible.
TABLE 28: IMPACTS FOR THE UPGRID POLISH DEMONSTRATOR EQUIPMENT LIST
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

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 (inclusion
COSEM level, due to possible /non-inclusion of the
differences in companion internal balancing meter,
PRIME data concentrators
specifications. comm ports etc.).
(note: there may be different
companion specification for
meters and data
concentrators).

to be used
Monitoring and control units Generally interchangeable, Not an issue. Same as with
for MV/LV substations are as long as required feature interchangeability.
usually interoperable, since set is implemented.
IEEE 60870-5-104 or IEEE 1815
they are compliant with IEEE
Monitoring and control units for
60870-5-104 and/or IEEE
MV/LV substations
1815, and their feature sets
have a common
denominator.
N/A
121 | 151

process)
The unit will be If functionally equal unit is Not an issue Possible to replicate, if the
interoperable on the PRIME developed - fulfilling the same feature set is
protocol level, as same specification and implemented in the same way
standardised protocol stacks delivering the same feature
will be used. set - then the
The unit will also be interchangeability will be
LV monitoring and control unit interoperable on the DLMS possible.
COSEM level, as it will
adhere to minimum
requirements - in terms of
implemented & required
DLMS operations - defined
by the Green Book
122 | 151
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 Gap Analysis has been divided in:

Protocol Gap Analysis.
Equipment Gap Analysis.
5.1 PROTOCOL GAP ANALYSIS

In order to simplify the analysis of the reported data from demonstrators, the following typical interface
names have been used:
Interface between sensors and IEDs.
Interface between IEDs and data concentrator (e.g. RTUs).
Interface between data concentrators, or IEDs, and SCADA (LV or MV).
Interface for connecting SCADAs (LV or MV).
Interface between SCADA (LV or MV) and management level (GIS, DMS, NIS, MDMS, OMS, NMS,).
Interfaces inside management level (GIS, DMS, NIS, MDMS, OMS, NMS, ).
Interface between SMs and SMs concentrators.
Interface between SMs concentrators and AMI Head-End.
Interface between AMI Head-End and management level (GIS, DMS, NIS, MDMS, OMS, NMS, ).
Interface for prime network management.
Interface for Data concentrator (e.g. RTUs) network management.
Interface between mobile devices and management level.
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
TABLE 29: SENSORS AND IEDS

High-level Low-level protocol Recommendations for
Demonstrator GAP
protocol layers layers new developments
Spanish N/A
Portuguese N/A
Use ZigBee application
standards as ZigBee
Smart Energy SEP 2.0,
High-level protocol uses which defines
Swedish Proprietary ZigBee
proprietary data model. Information model
objects derived from
IEC CIM (61968) and
61850.
Polish N/A
TABLE 30: IEDS AND DATA CONCENTRATORS

Demonstrator GAP
DLMS/COSEM
RS485 with HDLC
(CTI Companion No See section 5.1.2.
standard)
Spanish
IEC60870-104
(Iberdrola PRIME 1.3.6
No See section 5.1.1.
companion
standard)
High-level protocol uses Use IEC60870-104 (see
Proprietary RS485 with HDLC
proprietary data model. section 5.1.1).
Portuguese
RS485 with High-level protocol uses
Proprietary N/A
MODBUS proprietary data model.
Swedish N/A
DLMS/COSEM PRIME 1.3.6
Polish No See section 5.1.2.
with extensions
TABLE 31: DATA CONCENTRATOR, OR IEDS, AND SCADA

Demonstrator GAP
IEC60870-104
(Iberdrola
Spanish IP network No See section 5.1.1.
companion
standard)
IEC60870-104
Portuguese (EDP companion IP network No See section 5.1.1.
standard)
IEC60870-104 or IP network based on
No See section 5.1.1.
DNP3 GPRS
Swedish FTP over an IP Use IEC 61968-9 for
Proprietary file File uses proprietary data
network based on defining the format of
format model.
GPRS the file. See 5.1.3
124 | 151

Demonstrator GAP
IEC60870-104 or
Polish IP network No See section 5.1.1.
DNP3
TABLE 32: BETWEEN SCADAS

Demonstrator GAP
Spanish ICCP / TASE2 IP network No Similar to section 5.1.1
Portuguese N/A
Swedish N/A
Polish N/A
TABLE 33: SCADA AND MANAGEMENT LEVEL

Demonstrator GAP
IEC60870-104
(Iberdrola
Spanish IP network No N/A
companion
standard)
CIM (proposed in
Portuguese Web services Lack of definition See 5.1.3.
Deliverable 1.1)
Lack of definition
Swedish CIM Web services See 5.1.3.
(unknown profile)
Polish CIM IEC 61968-100 No See 5.1.3.
TABLE 34: INSIDE MANAGEMENT LEVEL

Demonstrator GAP
Lack of definition (unknown
Spanish CIM Web services See 5.1.3.
profile)
Lack of definition
Portuguese CIM Web services See 5.1.3.
(unknown profile)
Lack of definition
Swedish CIM Web services See 5.1.3.
(unknown profile)
Polish CIM IEC 61968-100 No See 5.1.3.
TABLE 35: SMS AND SM CONCENTRATORS

Demonstrator GAP
Spanish DLMS/COSEM PRIME 1.3.6 No See section 5.1.2.
DLMS/COSEM PRIME 1.3.6 No See section 5.1.2.
Portuguese
DLMS/COSEM GPRS No See section 5.1.2.
OSGP over ETSI TS High-level protocol uses
Swedish Proprietary N/A
103 908 proprietary data model.
Polish DLMS/COSEM PRIME 1.3.6 No See section 5.1.2.
125 | 151
TABLE 36: SM CONCENTRATORS AND AMI HEAD-END

Demonstrator GAP
Spanish STG 3.2 SOAP STG is not a standard protocol N/A
Portuguese STG 3.1 SOAP STG is not a standard protocol Use CIM. See 5.1.3.
OSGP over ETSI TS High-level protocol uses
Swedish Proprietary N/A
103 908 (Echelon) proprietary data model
Polish STG 3.1 SOAP STG is not a standard protocol N/A
TABLE 37: AMI HEAD-END AND MANAGEMENT LEVEL

Demonstrator GAP
STG 3.2 is not a standard
Spanish STG 3.2 SOAP Use CIM. See 5.1.3.
protocol
STG 3.1 is not a standard
Portuguese STG 3.1 SOAP Use CIM. See 5.1.3.
protocol
GS2 is not a standard protocol,
but It is considered a de facto
Swedish GS2 IP network Use CIM. See 5.1.3.
standard in the Nordic
countries
Polish CIM IP network No See 5.1.3
TABLE 38: PRIME NETWORK MANAGEMENT

Demonstrator GAP
Spanish SNMP IP Network No See 5.1.4
Portuguese N/A
Swedish N/A
Polish N/A
TABLE 39: DATA CONCENTRATOR (E.G. RTUS) NETWORK MANAGEMENT

Demonstrator GAP
Spanish N/A
Portuguese SNMP IP Network No See 5.1.4
Swedish N/A
Polish N/A
TABLE 40: MOBILE DEVICES AND MANAGEMENT LEVEL

Demonstrator GAP
High-level protocol uses
Spanish Proprietary SOAP Use CIM. See 5.1.3.
proprietary data model.
Portuguese Proprietary SOAP N/A
Swedish N/A
126 | 151

Demonstrator GAP
Polish Proprietary Web services Use CIM. See 5.1.3.
TABLE 41: HOME DEVICES

Demonstrator GAP
Spanish N/A
Use ZigBee application
standards as ZigBee
Not defined high-level protocol
Not defined ZigBee Smart Energy or
layer
ZigBee Home
Portuguese
Automation
Use Prime for PLC and
Not defined high-level protocol DLMS/COSEM for
Not defined PLC
layer high-level protocol
layer.
Swedish N/A
Polish N/A
5.1.1 GENERAL RECOMMENDATIONS FOR USING IEC 60870-5-101/104 AND DNP
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.
5.1.2 GENERAL RECOMMENDATIONS FOR USING DLMS/COSEM
Only add new OBIS codes if it is strictly necessary.

Use a common companion standard or only the common OBIS codes to all companion standards.
5.1.3 GENERAL RECOMMENDATIONS FOR USING CIM
In order to use CIM as the base of the communication protocol, two possibilities are available:
127 | 151
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.
5.1.4 GENERAL RECOMMENDATIONS FOR SNMP
Only add new MIBs if it is strictly necessary.
5.1.5 CONCLUSIONS ABOUT PROTOCOLS
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
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.
5.2 EQUIPMENT GAP ANALYSIS

The installed equipment in de Demo Base and the equipment to be used under UPGRID do not have
problems of interoperability because the communication protocols are based on mature standards or
mature specifications (see 5.1).
Neither, the scalability is an issue because the combination of IEDs and SMs with concentrators permits
to cover wide areas.
129 | 151
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.
TABLE 42: INSTALLED EQUIPMENT IN THE DEMO BASE

Demonstrator Equipment Equipment type Interchangeability
If functional (e.g. measurement functions) and non-
functional requirements (e.g. physical dimensions,
PRIME SM Meter communication ports, terminal positions, temperature
requirements, HMI, national regulations,) are commons
Spanish between demos
Line Monitoring If functional and non-functional requirements are
IED
Units commons between demos.
Data If functional and non-functional requirements are
Data concentrators
concentrator commons between demos.
PRIME SM EDP If functional and non-functional requirements are
Meter
Box commons between demos.
DTC Distribution
Portuguese Transformer
Controller
Communication If functional and non-functional requirements are
Router
equipment commons between demos.
Impossible because the DLMS/COSEM is not compatible
Echelon SMs (SM) Meter
with OSGP.
Echelon Data
Concentrators
Swedish
(DC), (with built in Data Impossible because the DLMS/COSEM is not compatible
GPRS concentrator with OSGP.
communication
modem)
If functional and non-functional requirements are
PRIME SMs Meter
commons between demos.
PRIME Data Data If functional and non-functional requirements are
concentrators concentrator commons between demos.
Wireless GSM
Polish
GPRS/EDGE/UMTS
,CDMA Communication If functional and non-functional requirements are
modems/routers/s equipment commons between demos.
witches for MV/LV
substations
130 | 151
TABLE 43: NEW EQUIPMENT TO BE INSTALLED UNDER UPGRID

Demonstrator Equipment type Equipment type Interchangeability
PRIME Base node
that supports both Data If functional and non-functional requirements are
application, IP and concentrator commons between demos.
Spanish SMs
PRIME service
node for IP
communications
PRIME SM EDP If functional and non-functional requirements are
Meter
Box commons between demos.
DTC Distribution
Transformer
Portuguese Controller
Communication If functional and non-functional requirements are
Router
equipment commons between demos.
IED / Data If functional and non-functional requirements are
Home devices
Impossible because the DLMS/COSEM is not compatible
SMs Meter
with OSGP.
Meter Data
Concentrators,
Data Impossible because the DLMS/COSEM is not compatible
(with built in GPRS
concentrator with OSGP.
communication
modem)
Schneider Electric If functional and non-functional requirements are
IED
Smart Transformer commons between demos.
RTU devices (or
equivalent IED) for
LV measurement If functional and non-functional requirements are
Swedish IED
in secondary commons between demos.
substations
(10/0.4 kV)
FPI - Fault passage
Indicators for fault
detection and IED
localization on MV
network
Modem/router for
GPRS/2G/3G or Communication If functional and non-functional requirements are
other secured equipment commons between demos.
communication
131 | 151
Demonstrator Equipment type Equipment type Interchangeability

Re-closer/breaker
for remote
network IED
operation/automa
tion4
CT - Current
Transformers in
secondary
substation.
(Others, which Sensor
may be tested are
Rogowski Current
Transformers,
micro snap-on CT)
CT - Current
Transformers for Sensor
MV network FPIs
IEEE 60870-5-104
or IEEE 1815
Monitoring and IED
control units for
MV/LV substations
Polish
DLMS/COSEM/PRI
ME Monitoring
and control units IED
for LV DER
equipment
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
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
REFERENCES
UPGRID DOCUMENTS
[1] D1.1 - Report on Technical Specifications WP1 UPGRID project. 2015
EXTERNAL DOCUMENTS
[2] EU Smart Grid mandate M/490, March 2011 ftp://ftp.cencenelec.eu/CENELEC/Smartgrid/M490.pdf

[3] CEN, https://www.cen.eu/Pages/default.aspx
[4] CENELEC, http://www.cenelec.eu/aboutcenelec/whatwedo/technologysectors/smartgrids.html
[5] ETSI, http://www.etsi.org/
[6] NIST, http://www.nist.gov/
[7] EU Smart Grid mandate M/441, March 2009
[8] http://www.etsi.org/images/files/ECMandates/m441%20EN.pdf
[9] Measuring instruments, CENELEC
[10] http://www.cencenelec.eu/standards/sectors/mid/pages/default.aspx
[11] EU Commission task Force for Smart Grids. Expert Group 1: Functionalities of smart grids and
smart meters. December 2010. http://www.gt-engineering.it/uploads/allegati/25expert_group1.pdf
[12] European Electricity Grid Initiative. Research and Innovation Roadmap 2013-2022. Grid+
http://www.gridplus.eu/Documents/20130228_EEGI%20Roadmap%202013-2022_to%20print.pdf
[13] CEN/CENELEC Smart Grid webpage
[14] http://www.cencenelec.eu/standards/Sectors/SustainableEnergy/SmartGrids/Pages/default.aspx
[15] SGCG/M490/G_Smart Grid Set of Standards, Version 3.1, CEN-CENELEC-ETSI Smart Grid
Coordination Group, Oct 31th 2014
[16] ftp://ftp.cencenelec.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/SGCG_Standards_Re
port.pdf
[17] SGCG/M490/I_Smart Grid Interoperability, Methodologies to facilitate Smart Grid system
interoperability through standardisation, system design and testing, CEN-CENELEC-ETSI Smart Grid
Coordination Group, Oct 31th 2014.
134 | 151
[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.
Part 61: Object identification system (OBIS). Second edition, 2006.
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
[39] DISCERN project http://www.discern.eu/; D5.2 - DISCERN guide for facilitating the replication and
scalability of the solutions
136 | 151
Annex I. DESCRIPTION OF PROTOCOLS

In this Annex a brief description of some of the protocols mentioned in this document is provided for
being of reference to the reader.
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
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
6.2 DLMS PROTOCOL STANDARD

DLMS/COSEM [31] is an open international standard for data exchange with utility meters measuring
any kind of energy, more generally, with intelligent devices like LVM&C units. 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. To meet these objectives, DLMS/COSEM uses
a three-step approach:
Application data modelling: this encompasses the COSEM interface object model and the OBIS data
identification system; see the next point COSEM information model
Messaging: this encompasses services for using the data model. These are the DLMS services
provided by the COSEM application layer;
Transporting: this encompasses communication profiles, i.e. the rules for transporting the APDUs
through various communication channels.
Key features of DLMS protocol:

client-server approach: the LVM&C units act as servers, providing the requested data / services to the
AMI management system, acting as a client. The LVM&C units can also send unsolicited information:
alarms, pre-defined data sets (push operation);
role based access: the server can provide a different scope of access to different clients playing
different roles: end user, meter reader, utility engineer, manufacturer...
OSI/Internet based protocol stacks carrying the messages. Any communication media, capable of
carrying DLMS APDUs is suitable. The communication media currently supported are the following:
local optical/electrical ports, PSTN, GSM, Internet, GPRS, PLC, M Bus, Euridis...
separation of the data model and the protocols orthogonality: the data model and the protocols
are neatly separated. The interface between them is provided by the DLMS messaging services. This
means that the object model can be developed without affecting the protocols and the protocols can
be developed without affecting the model.
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
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.
6.3 COSEM INFORMATION MODE

The COSEM [31] information (data) model presents the functionality of the device (e.g. the meter, the
LVM&C unit) at its interfaces. It specifies a library of COSEM interface classes (IC) and the OBIS Object
Identification System. The functional requirements are mapped to COSEM objects delivering those
functions. Each and every object is identified by its OBIS code. The COSEM model is independent of the
communication media, so that the required functionality can be provided the same way over any media.
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
setting up the communication channels

connection / disconnection of supply to the premises (electricity breaker)
firmware update
security setup
event / alarm handling
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.
Key features of COSEM information model:

Communication and messaging method independent data model and identification system: the
COSEM interface objects, identified with OBIS codes, model the application independently of the
messaging method and the communication method;
Multi-energy: all energy types electricity, gas, water and heat etc. are covered. The interface
classes are the same, only their OBIS codes are media / energy type specific;
Self-description: the meter provides information on the resources the list of objects available. The
meter also provides in each message the data type used. Consequently, the data collection system
and the meter can exchange data based solely on the information taken from the standard and read
141 | 151
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.
6.4 CIM STANDARD

CIM is defined by a series of documents summarized under the three standards for Energy
Management System Application Program Interfaces EMS-API (IEC 61970), Application Integration at
Electric UtilitiesSystem Interfaces for Distribution Management (IEC 61968), and Framework for
Energy Market Communication (IEC 62325).
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.
The CIM core data model is specified by parts of three standards:
142 | 151
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
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.
The Core Package

The Core package contains definitions of classes that are parent classes to many of the more specific
classes in other packages of the CIM model, including classes defined in the 61970 and 61968 series of
standard. The Core package is depicted in Figure 26.
144 | 151
FIGURE 26: CORE PACKAGE OF CIM MODEL
The Core package contains the following classes:

Identified Object:
The Core package contains a class called IdentifiedObject. This class is very abstract and only contains
attributes used to reference the object either by a user or in software. The attributes of
IdentifiedObject include mRID, which is the master resource identifier that should be a globally
unique identifier of objects; the mRID does not have to be human-readable. This identifier is
generally intended to be used by software systems.
The attributes name, description, aliasName, and pathName are intended for providing identifiers
that are human-readable. It is common for names of objects within a utility to not be unique due to
historical naming conventions, the results of mergers and acquisitions, and the inability of other
software systems to manage uniqueness. For these reasons, there are no constraints on these names
requiring them to be unique.
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
Equipment and ConductingEquipment:

The ConductingEquipment class inherits from an Equipment class which inherits from
PowerSystemResource. This is the parent class for most of the physical equipment that are used to
model the power system.
Substations, Bays and Voltage Levels:

The Core package also contains three classes that are used to model the aggregations of equipment:
Substation, Bay, and VoltageLevel classes. These three classes inherit from EquipmentContainer, and
they can be used to construct a hierarchy of objects where equipment is contained in a voltage level,
which is contained in a bay, which is contained in a substation.
It should be noted that this hierarchy is not required in the information model and is not very
applicable to distribution equipment on circuits outside of a substation. However, this hierarchy may
be required in certain application sub-domains such as transmission applications that exist in an EMS.
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.
The Topology Package

The Topology package is used to define the interconnection between any classes that inherits from
ConductingEquipment. This is essentially the wiring diagram of the model. The Topology package is
depicted in Figure 27.
146 | 151
FIGURE 27: THE TOPOLOGY PACKAGE OF CIM MODEL
Key classes within the Topology package are the following.
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
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.
6.5 WEB SERVICES

A web service is a collection of open protocols and standards used for exchanging data between
applications or systems. Software applications written in various programming languages and running
on various platforms can use web services to exchange data over computer networks like the Internet in
a manner similar to inter-process communication on a single computer. This interoperability (e.g.
between Java and Python, or Windows and Linux applications) is due to the use of open standards.
Typically, a web service is characterised by the following features:

is available over the Internet or private (intranet) networks
uses a standardized XML messaging system
is not tied to any one operating system or programming language
is self-describing via a common XML grammar
is discoverable via a simple find mechanism
148 | 151
A web service builds upon the following underlying concepts:

XML to tag the data
SOAP to transfer a message
WSDL to describe the availability of service
6.6 IEC 60870-5-101/104

These parts of IEC 60870 [13] apply to telecontrol equipment and systems with coded bit serial data
transmission for monitoring and controlling geographically widespread processes. They define
telecontrol companion standards that enable interoperability among compatible telecontrol equipment.
The defined telecontrol companion standards utilize earlier standards of the IEC 60870-5 series. The
specification of IEC 60870-5-104 presents a combination of the application layer of IEC 60870-5-101 and
the transport functions provided by a TCP/IP (Transmission Control Protocol/Internet Protocol). Within
TCP/IP, various network types can be utilized, including FR (Frame Relay), ATM (Asynchronous Transfer
Mode) and ISDN (Integrated Service Data Network). Using the same definitions, alternative ASDUs
(Application Service Data Unit) as specified in IEC 60870-5-101 and IEC 60870-5-5 standards may be
combined with TCP/IP.
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.
6.7 DNP3 OVER IP

The DNP3 protocol was developed by Westronic based on the early versions of the IEC 60870-5 standard
telecontrol protocol specifications. Now the protocol specification is controlled by the DNP Users Group
at www.dnp.org. The protocol is based on the EPA (Enhanced Protocol Architecture), a simplified model
of the ISO/OSI model. It specifies the data link layer, the application layer and a transport pseudo-layer.
To support advanced RTU functions and messages larger than the maximum frame length as defined by
the IEC document 60870-5-1, the DNP3 data link is intended to be used with the mentioned transport
pseudo-layer. As a minimum, this transport layer implements message assembly and disassembly
services.
149 | 151
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.
Data link layer

The DNP3 data link layer is designed to operate with asynchronous or synchronous bit serial physical
layers. Fully balanced transmission procedures were adopted to support spontaneous transmissions
from outstations.
Data link functions include:

Performing message data link retransmissions
Synchronizing and handling the FCB in the control octet
Setting and clearing the DFC bit based on buffer availability
Packing user data into the defined frame format includes CRC and transmitting the data to the
physical layer
Unpacking the data link frame received from the physical layer into user data, checking and removing
CRC
Controlling the physical layer
Responding to all valid frames received from the physical layer
Data link responsibilities:

Exchange of SDUs between peer DNP3 data links
Error notification to data link user
Sequencing of SDUs
SDU delivery quality
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
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:
The IED supports four DNP3 communication modes.

Quiescent operation
Unsolicited report-by-exception operation
Polled report-by-exception operation
Polled static operation
151 | 151

UPGRID D0103 Standards

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UPGRID D0103 Standards

Uploaded by

Copyright:

Available Formats

Real proven solutions to enable active demand and distributed

generation flexible integration, through a fully controllable

Scope and Boundaries of Project

2015 The UPGRID Consortium

PROGRAMME H2020 Energy Theme

VERS. ISSUE DATE CONTENT AND CHANGES

EXECUTIVE SUMMARY _________________________________________________________________ 4

4. IMPACT OF STANDARDISATION IN UPGRID _____________________________________________ 97

5.1.5 CONCLUSIONS ABOUT PROTOCOLS ______________________________________________________________ 128

FIGURE 22: THREE LEVELS OF MONITORING IN SECONDARY SUBSTATION _______________________96

TABLE 1: STRUCTURE OF TABLE TO CLASSIFY PROTOCOLS AND EQUIPMENT IN THE DEMONSTRATORS 24

ABBREVIATIONS AND ACRONYMS

AMI Advanced Metering Infrastructure

IBERDROLA Iberdrola Distribucin Elctrica S.A.U.

SGAM Smart Grid Architecture Model

As defined in D1.1 Technical specification of project demonstrators, in the UPGRID context,

Benefit of using standards for representing Smart Grid solutions

Facilitating knowledge sharing among actors

1.1 PRACTICAL REFERENCES TO STANDARDISATION

The most relevant material is summarised in the following index frames:

Smart Grid Standards Mapping Tool

Name of the tool: IEC tool (Smart Grid Standards Map)

SGCG Interoperability IOP tool

Name of the tool: SGCG Interoperability IOP tool

List of standardised names for Smart Grid players

Tools for managing Uses Cases and SGAM model

DISCERN SGAM Visio Template

DISCERN Use Case Template

DISCERN Use Case Management Repository

1.2 SCOPE OF THE DOCUMENT

Therefore, D1.3 is focused on communication protocols. More precisely, interchange of information

FIGURE 4: DIFFERENT DIMENSIONS OF STANDARDS

TABLE 1: STRUCTURE OF TABLE TO CLASSIFY PROTOCOLS AND EQUIPMENT IN THE DEMONSTRATORS

TABLE 2: STRUCTURE OF THE TABLE TO CLASSIFY DEMONSTRATORS PROTOCOLS

TABLE 3: STRUCTURE OF THE TABLE TO CLASSIFY DEMONSTRATORS EQUIPMENT

Description of used Standards / Proprietary protocols - equipment

Description of proposed standard protocol - equipment

Description of Development of extensions to a standard protocol - equipment / protocol profiles -

Standards bring numerous benefits to business and society, such as:

Compatibility between versions

TABLE 4: LIST OF UPGRID PROTOCOL IMPACTS

TABLE 5: LIST OF UPGRID EQUIPMENT IMPACTS

3. INITIAL DEMONSTRATIONS APPROACH TO STANDARDS

3.1 SPANISH DEMONSTRATOR

TABLE 6: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE SPANISH DEMONSTRATOR

DEMO BASE DEMO DEVELOPED UNDER UPGRID

Used standard protocols Proposed standard protocols to be used

TABLE 7: CLASSIFICATION OF THE MOST RELEVANT EQUIPMENT IN THE SPANISH DEMONSTRATOR

DEMO BASE DEMO DEVELOPED UNDER UPGRID

Used standardised equipment Proposed standardised equipment to be used

3.1.1.1 DESCRIPTION OF USED STANDARDS PROTOCOLS / PROPRIETARY PROTOCOLS

These protocols are described briefly as follows:

The DLMS/COSEM defines (source: DLMS user association):

3.1.1.2 DESCRIPTION OF PROPOSED STANDARD PROTOCOL

IEC 104 Use of the pure definition - no modifications/gaps anticipated.

ICCP / TASE2: use the pure definition - no modifications/gaps anticipated.

3.1.1.3 DESCRIPTION OF DEVELOPMENT OF EXTENSIONS TO A STANDARD PROTOCOL / PROTOCOL

Web services SOAP Profile: Defined in STG-DC specification

Cluster 3: Network operations

D7 Monitoring and control of LV networks

D9 Network management methodologies for network operation

D10 Smart metering data utilisation

Cluster 4: Network planning and asset management

D11 New planning approaches for distribution networks