Report on standards and potential synergies D1

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 646531

Report on standards and potential synergies

D1.3

2015 The UPGRID Consortium

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

Scope and Boundaries of Project Demonstration D1.3 Report on standards and potential synergies

2 | 151

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 (Raúl Bachiller)

PARTNER(S) CONTRIBUTING IBERDROLA (Raúl Bachiller; Jesús García), EDP

(Pedro Manuel, Ricardo Matos, Pedro Godinho),

VTF (Anders Kim Johansson, Nicholas Etherden),

ENERGA (Slawomir Noske), TECNALIA (Eduardo

García), IMPERIAL (Christos Vasilakos), COMILLAS

(Jose Antonio), INESC (Luis Seca), ZIV (Laura

Marrón; 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 Marrón) / WITHUS (Emanuel Miranda,

Tiago Duarte)

FILE NAME UPGRID_WP1_D1.3_Standards_v04_final


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


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


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


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


7 | 151

5.1.5 CONCLUSIONS ABOUT PROTOCOLS ______________________________________________________________ 128

5.2 EQUIPMENT GAP ANALYSIS______________________________________________________________ 129

6. CONCLUSIONS ___________________________________________________________________ 133

REFERENCES _______________________________________________________________________ 134

DESCRIPTION OF PROTOCOLS _________________________________________________ 137 ANNEX I.

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


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


9 | 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 1–405, 2013, WWW.IEC.CH) ____________________________143

FIGURE 24: IEC 61968-11 CIM BASE DATA MODEL. (FROM IEC 61968, COMMON INFORMATION MODEL

(CIM)/ DISTRIBUTION MANAGEMENT, PART 1–13, 2013, WWW.IEC.CH) ________________________143

FIGURE 25: IEC 62325-301 CIM BASE DATA MODEL. (FROM IEC 62325, FRAMEWORK FOR ENERGY

MARKET COMMUNICATIONS, PART 1–502, 2013, WWW.IEC.CH.) _____________________________144

FIGURE 26: CORE PACKAGE OF CIM MODEL ______________________________________________145

FIGURE 27: THE TOPOLOGY PACKAGE OF CIM MODEL ______________________________________147


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


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


12 | 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é Européen de Normalisation

CENELEC Comité Européen de Normalisation électrotechnique

CIM Common Information Model

COMILLAS Universidad Pontificia Comillas

COSEM / DLMS Companion Specification for Energy Metering / Device

Language Message specification

CT Current Transformer

D Deliverable

DC Data Concentrator

DER Distributed Energy Resources

DISCERN Distributed Intelligence for Cost-effective and Reliable

Solutions

DMS Distribution Management System

DNP3 Distributed Network Protocol

DSO Distribution System Operator

DTC Distributed Transformer Controller

EB EDP Box

EDP EDP Distribuição - Energia, S.A.

ENERGA Energa Operator S.A.

ETSI European Telecommunications Standards Institute (see

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 GränsSnitt2 or "Interface2"


13 | 151

IBERDROLA Iberdrola Distribución Eléctrica 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 INESC PORTO - Instituto de Engenharia de Sistemas e

Computadores do Porto

IOP Interoperability

IP Internet Protocol

ISO International Organization for Standardization

IT Information Technology

ITE Asociación Instituto Tecnológico de la Energía

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

NISTIR National Institute of Standards and Technology Interagency

Report

NOC Network Operation Centre

NOS NOS Comunicações, 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


14 | 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 Telegestión-Data Concentrator

T Task

TECNALIA Fundación Tecnalia Research & Innovation

UML Unified Modelling Language

UPGRID

Real proven solutions to enable active demand and

distributed generation flexible integration, through a fully

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.


15 | 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é Européen de Normalisation) [3], CENELEC (Comité Européen 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


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


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

http://smartgridstandardsmap.com/




18 | 151

FIGURE 1: WINDOW SHOOT OF THE SMART GRID STANDARDS MAP (TAKEN FROM HTTP://SMARTGRIDSTANDARDSMAP.COM/)



19 | 151

FIGURE 2: WINDOW SHOOT OF THE SGCG INTEROPERABILITY IOP TOOL (TAKEN FROM

HTTP://WWW.CENCENELEC.EU/STANDARDS/SECTORS/SUSTAINABLEENERGY/SMARTGRIDS/PAGES/DEFAULT.ASPX)


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

http://www.discern.eu/project_output/tools.html

http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf


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

http://www.discern.eu/index.html


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

http://www.discern.eu/project_output/tools.html


23 | 151

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.

Standards Solutions

• Measurement standards • Communication protocol standards • Data model standards • Graphical representation • Physical dimension standards • Environmental conditions standards • Power supply standards • …

OSI levels

• Physical • Link • Communication • Application • …

Proprietary Solutions


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


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


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


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

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

Concepts

Standard (interface standard) Communication protocol / protocol

Factors

Interoperability (compatibility)

Interchangeability

Scalability

Replicability


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


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


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


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


32 | 151

FIGURE 6: COMPLETE METHODOLOGY APPLIED IN D1.3

Chapter 5 & 6


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


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

Transport layer for SMs provided data 4-32/PRIME

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

IP convergence sublayer

PRIME 1.3.6

4-32 convergence sub-layer

SMs profile

SNMPv3 for MIB collection

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

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


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


36 | 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 1990’s 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 Telegestión – 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


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


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


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


40 | 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 telecontrol applications (Concept test)

IEC 60870-5-104 over PLC-PRIME from LV SCADA to field devices

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 measurements from inside SS (e.g. transformer meter, advanced LV supervision)

PRIME, PRIME, DLMS COSEM, STG-DC, IEC 60870-5-104 from RTU to SCADA

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)

PRIME, PRIME, DLMS COSEM, STG-DC, IEC 60870-5-104 when possible SOAP/XML with proprietary content or CIM otherwise

D7.5

Integration of the MV power transformer status from the MV systems to the LV Network Management System

ICCP / TASE.2 from MV SCADA to LV SCADA or proprietary database interface

D7.7

Integration of measurement data to support power flow analyses in LV Network Management System

LV DMS internal, no protocol involved – assumed that 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 Network Management System

CIM is supported in Network information / Asset Management 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.


41 | 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 Outage Management System (OMS)

PRIME, DLMS COSEM, IEC 60870-5-104 from MDM/head end to 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 which each SM is connected to)

PRIME

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 information from LV system (e.g. geographical context, assets and outage location) to support grid crews

SOAP/XML over HTTPS via GPRS/UMTS with proprietary content – it needs to be developed/defined in the project.

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

in electricity markets N/A


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


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


44 | 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 can’t 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:


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

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.

Secondary

Substations

Meter rooms

http://www.prime-alliance.org/


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


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


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.


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


49 | 151

TABLE 10: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE PORTUGUESE DEMONSTRATOR



IEC60870-5-104

Light Protocol Implementation Document (LPID) for IEC 60870-

5-104 defined by EDP Distribuição

IEC60870-5-104

Light Protocol Implementation Document (LPID) for IEC 60870-

5-104 defined by EDP Distribuição

PRIME

Version 1.3.6 established by PRIME Alliance

PRIME MAC & PHY layers (PLC)

PRIME 4-32 convergence sub-layer

PRIME

Version 1.3.6 established by PRIME Alliance

PRIME MAC & PHY layers (PLC)

PRIME 4-32 convergence sub-layer


50 | 151

DLMS/COSEM

DLMS UA 1000-1: Blue book, COSEM Identification System and

Interface Classes, 12th Edition

DLMS UA 1000-2: Green book, DLMS/COSEM Architecture and

Protocols, 8th Edition

IEC 62056-42: Electricity metering – Data exchange for meter

reading, tariff and load control - Part 42: Physical


reading, tariff and load control – Part 46: HDLC


reading, tariff and load control – Part 47: COSEM transport layer

for IP networks (Wrapper for GPRS SMs)


reading, tariff and load control – Part 53: COSEM application

layer


reading, tariff and load control – Part 61: Object identification

system (OBIS)

EDP Box data model – EDP companion for DLMS/COSEM

DLMS/COSEM

DLMS UA 1000-1: Blue book, COSEM Identification System and

Interface Classes, 12th Edition

DLMS UA 1000-2: Green book, DLMS/COSEM Architecture and

Protocols, 8th Edition


reading, tariff and load control - Part 42: Physical


reading, tariff and load control – Part 46: HDLC


reading, tariff and load control – Part 47: COSEM transport layer

for IP networks (Wrapper for GPRS SMs)


reading, tariff and load control – Part 53: COSEM application

layer


reading, tariff and load control – Part 61: Object identification

system (OBIS)

EDP Box data model – EDP companion for DLMS/COSEM

Web services SOAP (STG-DC 3.1.c)

Central System – DTC interface based on DC INTERFACE

SPECIFICATION , v3.1.c, authored by Iberdrola but currently

under the responsibility of the Prime Alliance

EDP profile with specific Orders (Bnn) and Reports (Snn) -

WS_STG.DTC_perfil.EDP_v5.13


Central System – DTC interface based on DC INTERFACE

SPECIFICATION , v3.1.c, authored by Iberdrola but currently

under the responsibility of the Prime Alliance

EDP profile with specific Orders (Bnn) and Reports (Snn) -

WS_STG.DTC_perfil.EDP_v5.13

FTP (RFC959) FTP (RFC959)


51 | 151

MODBUS over serial line

MODBUS APPLICATION PROTOCOL SPECIFICATION, V1.1b for

HAN interface of the EDP Box

MODBUS over serial line

MODBUS APPLICATION PROTOCOL SPECIFICATION, V1.1b for

HAN interface of the EDP Box





HAN interface

Data model and communication protocol for the HAN interface

of the EDP Box

N/A

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)


52 | 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 vendor’s

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

1990’s 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.


53 | 151

STG-DC 3.1.c (STG-DC stands for Sistema de Telegestión – 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 Distribuição practical experience in InovGrid project.



No protocols expected under this category.

http://en.wikipedia.org/wiki/Network_protocol

http://en.wikipedia.org/wiki/Computer_file

http://en.wikipedia.org/wiki/Host_(network)

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

http://en.wikipedia.org/wiki/Internet

http://en.wikipedia.org/wiki/Client-server_model

http://en.wikipedia.org/wiki/Clear_text

http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security

http://en.wikipedia.org/wiki/SSL/TLS


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

D1.1 LV customer consumption characterization PRIME, DLMS/COSEM, Web services SOAP (STG-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 (e.g. transformer meter, advanced LV supervision)


D7.4


PRIME, DLMS/COSEM, Web services SOAP (STG-DC 3.1.c)

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


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



D9.4 Implementation of Network Management System (NMS) based on Simple Network Management Protocol (SNMP) at SS level

SNMP

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

Calculation of indicators for SM infrastructure e.g. the availability-KPI indicators to be used in a geographical context the to assist the Network Operation Centre (NOC)

N/A

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 PRIME, DLMS/COSEM, Web services SOAP (STG-DC 3.1.c)



D12.4


N/A


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


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


58 | 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 client’s 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


59 | 151

FIGURE 13: PROTOCOLS FOR EDP BOX PLC PRIME

FIGURE 14: PROTOCOLS FOR EDP BOX GPRS


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


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


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


63 | 151

TABLE 13: CLASSIFICATION OF THE MOST RELEVANT PROTOCOLS IN THE SWEDISH DEMONSTRATOR



OSGP ETSI GS OSG 001 - Open Smart Grid Protocol for both

measurements and events between SM<->DC<->AMI Head End

system

OSGP

GS2* - Message based protocol for measurement values (meter

stands and hourly values) between AMI Head End and Vattenfall

(MDMS)

*GS2 stands for "GränsSnitt2" 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.

GS2

XML - Message based protocol for events from SM from AMI Head

End system and Vattenfall PER-system (PerformanceEventReport

system)

XML

PLC - Power Line Communication, using both A and C band, and

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.

PLC


64 | 151

GPRS/3G - Communication between the field installed IED, e.g. DC,

and telecommunication service provider hardware environment

GPRS/3G/CDMA

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


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

communication modem or with Ethernet connection for an

external modem/router)

Meter Data Concentrators, (with built in GPRS communication

modem or with Ethernet connection for 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


66 | 151



process)

N/A N/A


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


68 | 151

FIGURE 16: SIMPLIFIED DESCRIPTION OF STANDARDS USED FOR SM CONNECTION TO OVERLYING SYSTEM HIERARCHY


69 | 151

FIGURE 17: SIMPLIFIED DESCRIPTION OF STANDARD USED FOR MV NETWORK FPI AND LV NETWORK SECONDARY

SUBSTATION CONNECTION TO OVERLYING SYSTEM HIERARCHY


70 | 151

TABLE 15: IDENTIFICATION OF MAIN PROTOCOLS USED IN EACH SUB-FUNCTIONALITIES SELECTED BY THE SWEDISH DEMONSTRATOR




D7.3


.104 over GPRS for SCADA/DMS, FTP over GPRS for LV 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


GS2 and/or CIM from metering AMM/MDM head end .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 different manufactures

.104 (DNP3 may be used for one RTU, instead of 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 Management System



71 | 151



OSGP and GS2

D10.3

Algorithm to determine connectivity of SM to the grid (identification of phase and line to which each SM is connected to)

Not applicable to protocols. This is a process to be 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


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


73 | 151

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.

Generation Transmission Distribution CustomerDER

Process

Field

Station

Operation

Enterprise

Market

Smart

Meter

Meter Data

Concentrator

AMI

Head End

MV LV

MDM

LV

DMS

MV

SCADA-DMS

NIS

Smart

Transformer

RTU / FPI

Wireless

Current

Sensor

Re-closer

/breaker

Fault Passage

Indicator (FPI)

LV

Monitoring

LV

SCADA


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


75 | 151

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


Process

Field

Station

Operation

Enterprise

Market

Smart

Meter

Meter Data

Concentrator

AMI

Head End

MV LV

MDM

LV

DMS

MV

SCADA-DMS

NIS

Smart

Transformer

RTU / FPI

Wireless

Current

Sensor

Re-closer

/breaker

Fault Passage

Indicator (FPI)

LV

Monitoring

LV

SCADA

OSGP ETSI GS OSG 001

over PLC ETSI TS 103 908

OSG

P E

TSI G

S O

SG

00

1 o

ver

GP

RS

over Zigb

ee

802.15.4

Integration Bus W3C Web Services ?

over networks IP based

IEC

60

87

0-5

-10

4

ove

r G

PR

S

CIM

CIM

IEC

608

70-5

-104

Ove

r G

PRS

FTP

over

GPR

S


76 | 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 requester’s

requirements and quality of service.

http://en.wikipedia.org/wiki/IEC_60870

http://en.wikipedia.org/wiki/Supervisory_control_and_data_acquisition

http://en.wikipedia.org/wiki/Electrical_engineering

http://en.wikipedia.org/wiki/Power_system_automation

http://en.wikipedia.org/wiki/Power_system_automation

http://en.wikipedia.org/wiki/IEC_TC_57

http://en.wikipedia.org/wiki/Communications_protocol

http://en.wikipedia.org/wiki/Electric_power

http://en.wikipedia.org/wiki/Electric_power


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

http://en.wikipedia.org/wiki/Network_protocol

http://en.wikipedia.org/wiki/Computer_file

http://en.wikipedia.org/wiki/Host_(network)

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

http://en.wikipedia.org/wiki/Internet

http://en.wikipedia.org/wiki/Client-server_model

http://en.wikipedia.org/wiki/Clear_text

http://en.wikipedia.org/wiki/File_Transfer_Protocol#Security

http://en.wikipedia.org/wiki/SSL/TLS


78 | 151

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.


Process

Field

Station

Operation

Enterprise

Market

Smart

Meter

Meter Data

Concentrator

AMI

Head End

MV LV

MDM

LV

DMS

MV

SCADA-DMS

NIS

Smart

Transformer

RTU / FPI

Wireless

Current

Sensor

Re-closer

/breaker

Fault Passage

Indicator (FPI)

LV

Monitoring

LV

SCADA

OSGP based on

IEEE 1377 and ANSI C12

OSG

P b

ased o

n

IEEE 13

77

and

A

NSI C

12

SINTEF GS2

Data Model

CIM Data Model


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

FIGURE 21: SGAM FUNCTION LAYER FOR THE SWEDISH DEMONSTRATOR ARCHITECTURE


Process

Field

Station

Operation

Enterprise

Market

Smart

Meter

Meter Data

Concentrator

AMI

Head End

MV LV

MDM

LV

DMS

MV

SCADA-DMS

NIS

Smart

Transformer

RTU / FPI

Wireless

Current

Sensor

Re-closer

/breaker

Fault Passage

Indicator (FPI)

LV

Monitoring

LV

SCADA

D8: Automation and control of MV network

D9: Network management methodologies for network operation

D7

: Mo

nito

ring an

d

con

trol LV

netw

ork


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

Interface Information

Layer Standard Description Sub-functionality

SM -> Meter Data

Concentrator

OSGP Open Smart Grid Protocol

(www.osgp.org/)

D7: Monitoring and Control of LV Networks

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

Concentrator - >

AMI Head End

OSGP See above, same as for the interface SM -> DC

AMI Head End ->

Meter Data

Management

System

GS2

XML

Object oriented data model.

GS2 file format for daily

measurement data (meter

readings) and XML file format

for alarms and events

See above, same as for the interface SM ->

DC


81 | 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 Görlitz 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.


82 | 151

TABLE 17: SUMMARY OF PROPOSED STANDARD PROTOCOL INTERFACES IN THE SWEDISH DEMONSTRATOR

Interface Information Layer

Standard Description Sub-functionality

RTU -> SCADA IEC 60870-5-104 (In

lieu of finalized -104

implementation one

RTU may use DNP3)

ZigBee to be used

between one RTU

and current

transformer

FTP (RFC959) over

GPRS

Data exchange

between LV network

secondary substation

and overlying LV

SCADA/DMS.

FTP format not used

for real time

information

requirements to

overlying system,

such as LV Monitoring

Application.

D7: Monitoring and Control of LV

Networks


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

D10: Smart metering Data Utilisation

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

between MV network

field installations and

overlying MV

SCADA/DMS

D8: Automation and control of MV

networks

D8.1 Monitoring MV network by fault

detectors

Smart Transformer IEC60870-5-104 Data exchange

between the Smart

(dynamic)

transformer and

overlying remote

control application,

e.g. MV SCADA


Networks

D7.9 LV regulation at SS level using a

new smart transformer

NIS /Asset

Management System

-> LV SCADA

CIM CIM - Common

Information Model

for data exchange

D9: Network management

methodologies for network operation

D9.2 Use CIM for LV network

modelling and data exchange

between e.g. AMI, GIS, MV SCADA, LV

Network Management System


83 | 151

Interface Information Layer

Standard Description Sub-functionality

CT sensor -> RTU N/A ZigBee wireless

communication


Networks


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


84 | 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,


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


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

edition. Technical report. DLMS User Association, 2014

COSEM Identification System and Interface Classes. Blue Book –

12th edition. Technical report. DLMS User Association, 2014.

IEEE 1815 Std.: IEEE Standard for Electric Power Systems

Communications—Distributed Network Protocol (DNP3). Revised

edition, 2012

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


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


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


89 | 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 Telegestión – 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.

http://www.energa-operator.pl/dcsap.xml


90 | 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 Communications—Distributed

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)


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


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

D3.1 Remote management of DER DLMS/COSEM Extensions for PRIME PLC LV monitoring and control unit



D7.1 Operation (control and multiservice) of LV grid devices using PLC-PRIME for different telecontrol applications (Concept test)

DLMS/COSEM Extensions for PRIME PLC LV monitoring and control unit

D7.2 Queries to request advanced meter data to support operation DLMS/COSEM, PRIME PLC

D7.3


DLMS/COSEM, PRIME PLC

D7.4


DLMS/COSEM, PRIME PLC; DLMS/COSEM Extensions for 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 System

IEC 60870-5-104; IEEE 1815

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


D7.11 LV meshed network operation - identifying the optimum topological configuration IEC 61968-13


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


IEC 61968-13 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 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 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


HTTPS, Webservices


94 | 151



D13.1

Web portal for increasing the consumer awareness in order to leverage their participation in electricity markets

HTTPS


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


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


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


98 | 151

TABLE 21: IMPACTS FOR THE UPGRID SPANISH DEMONSTRATOR PROTOCOL LIST




DLMS COSEM

It is required to define a clear

data model (companion

specification) and a

transport method.

Difficult due to different

companion specifications in

different countries.

Not an issue. Only requirement is to share

the same companion

specification.

PRIME 1.3.6 - 4-32 CS PRIME compliance tests by a

certified laboratory.

PRIME compliance test by a


Not an issue. Not an issue.

Proposed standard protocols,

proposed standard profiles

PRIME 1.3.6 - IP CS PRIME compliance tests by a





SNMPv3 Assured if a clear MIB file is

specified.

A MIB file is required. Not an issue. Not an issue.


STG 3.2

WSDL files definition and all

XSD related to

reports/orders defined.

It is difficult to assure. An

integration test is always

required even though a clear

definition is provided.

Not an issue. Not an issue if the defined

reports/web services can be

applicable.

New standards to be developed,

new extensions to standard to be

developed, new profiles to be

developed


99 | 151



DLMS COSEM

It is required to define a clear

data model (companion

specification) and a

transport method.

Difficult due to different

companion specifications in

different countries.


the same companion

specification.

STG 3.2 extension


XSD related to

reports/orders defined.

It is difficult to assure. An

integration test is always

required even though a clear

definition is provided.



applicable.

TABLE 22: IMPACTS FOR THE UPGRID SPANISH DEMONSTRATOR EQUIPMENT LIST




PRIME SMs

Assured if the meter

complies with the protocols

definition (includes

companion specification for

DLMS), telecom interfaces…

It is no so obvious. Note that

apart from protocols, there

are several HW

characteristics that differ

from the different countries

(such as the number of

communication ports,

dimensions, terminal

positions…)

Not an issue. The same applies as with

interchangeability.


100 | 151



Line monitoring units

Assured if the monitoring

unit complies with the

protocols definition (includes


DLMS), telecom interfaces…



are several HW





dimensions, installation

limitations...)


interchangeability.

Data concentrators

Assure if the data

concentrator complies with

the protocols definition

(includes companion

specification for DLMS),

telecom interfaces…



are several HW





dimensions, installation

limitations...)


interchangeability. Apart from

that, note that different

countries require additional

features. For instance, in the

monitoring of the secondary

of the transformer,

telecontrol features…

Proposed standardised equipment

to be used

N/A


N/A

Development of new equipment

(and possible standardization

process)


101 | 151



PRIME Base Node

Required the definition on

how to transport DLMS

traffic - interface with a data

concentrator

Definition of interfaces such

as the data concentrator

interface or the IP interface


interchangeability.

PRIME Service Node Definition of the IP

functionality (NAT support?)

Definition of the IP

functionality (NAT support?)


interchangeability.

SW System for PRIME network

management

Assured if a clear MIB file is

specified.

A MIB file is required. Not an issue. Not an issue.


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


103 | 151

TABLE 23: IMPACTS FOR THE UPGRID PORTUGUESE DEMONSTRATOR PROTOCOL LIST2




DLMS/COSEM

Specific data model required

(companion specification)

Depend on the data model

and transport layer.

Depend on the data model.

PRIME PRIME compliance tests by a




Web services SOAP (STG-DC 3.1.c) Specific

SNMP Specific MIB definition

required

Depend on the MIB Depend on the MIB



(same protocols indicated above)


HAN interface

Specific data model required Specifica hardware interface

(RS-485 on RJ12 connector)

Depend on the data model




developed

N/A

2 Empty cells mean “Not Applicable” or “Not an Issue”


104 | 151

TABLE 24: IMPACTS FOR THE UPGRID PORTUGUESE DEMONSTRATOR EQUIPMENT LIST3




EDP Box (PRIME SM)

Must be compliant with the

companion specification and

transport layer.

Even if compliant with the

communication protocols

and specific companion, it

also must be compliant with

other specifications

(mechanical specification,

dimensions, HMI …)

DTC

Must be compliant with the

companion specification and

transport layer.

Even if compliant with the

communication protocols

and specific companion, it

also must be compliant with

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”


105 | 151





process)

N/A


106 | 151

4.3 SWEDISH DEMONSTRATOR

Table 25 summarises the main impacts of the identified protocols presented in Table 13 for the Swedish




107 | 151

TABLE 25: IMPACTS FOR THE UPGRID SWEDISH DEMONSTRATOR PROTOCOL LIST




OSGP over PLC (ETSI TS 103 908)

(SGAM: Field Station)

Limited. The OSGP alliance is

supported by a handful of

developers. Require the Data

Concentrator developed by

Echelon for exchanging data

from SM using OSGP.

Limited. Although other SMs

are anticipated to support

the OSPG protocol used by

the Echelon DC,

interchangeability can be

limited (for instance, based

on physical connections of

the SMs or functionality

provided by them).

The same protocol is used

between the SM and DC and

from DC to AMI head end.

OSPG protocol also supports

direct load control modules,

solar panels, gateways, and

other smart grid device. So

the solution could be applied

for more use cases. Also the

number of levels could be

expanded if data

concentration is desired on

multiple levels.

The solution can be

duplicated at another

location, using OSGP SM and

DC.

OSGP over GPRS

(SGAM: Station Operation)

Limited. The OSGP alliance is

supported by a handful of

developers. Require the NES

AMI platform developed by

Echelon/Telvent for

exchanging data with the DC

using OSGP.

Limited. Other SMs Data

Concentrators are not

anticipated to support the

OSPG protocol used by the

Echelon DC.

If the no. of DCs increase in

relation to the no. of

installed meters, no

scalability limitation exist.

The solution can be


location, using the same DC

and AMI Head End platform.


108 | 151



ZigBee

(SGAM: Field Station)

Different sensors supporting

ZigBee can be connected to

the same RTU. Different

RTUs can be connected to

the sensors, if they support

ZigBee.

ZigBee is not standardizing

on information level, so

interchangeability is poor for

different sensors.

The solution is limited by the

RTU. The limitation is not

known but not perceived to

be an issue.

The solution can be


location given that the RTU

supports ZigBee.

FTP (RFC959) over GPRS


FTP offers a high level of

interoperability for file

sharing.

Limited. File format and

content is not standardised.

The solution is limited by the

LV monitoring system. The

limitation is not known but

not perceived to be an issue.

The solution can be


location but only using the

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

high level of interoperability.

The -104 protocol offers a

high level of

interchangeability where

most RTU on the market can

fulfil the utility ASDU

addressing and interop

specification.

Also fault passage indicators

are assumed to use -104.

Vattenfall has today 1000

MV station but integrating

also several thousand LV

stations to SCADA-DMS

would be challenging. The

solutions only foreseen for

strategic LV station with

power quality issues.

IEC 60870-5-104 over GPRS.




109 | 151



WP3 Web Services exchanging GS2 or

CIM information models

(SGAM: Operation & Enterprise)

Integration bus horizontally

between AMI front end, LV

Monitoring and SCADA-DMS

as well as vertically to NIS

and MDM require a level of

high level of standardization

regarding the information

modelling therefore CIM will

be considered for use.

Interchangeability would

require standardizing the

information content

between the involved

systems. This is not within

the WP5 scope.

The ability to exchange

gathered information

between multiple

applications on operation

and enterprise level is limited

by the amount of domain

specific standardized

information models that the

applications support.

Scalability is expected to be

limited due to dedicated

solutions for information

exchange in practice today.

The replicability is dependent

on the amount of support for

standardized information

exchange on application

level, and therefore foreseen

to be limited.


N/A




developed

N/A


110 | 151

TABLE 26: IMPACTS FOR THE UPGRID SWEDISH DEMONSTRATOR EQUIPMENT LIST




Echelon SMs (SM) Limited. Require the NES

platform developed by


with the DC using OSGP

Limited. Require the NES



with the DC using OSGP

Increasing the no of meters

is limited to the DC capacity.

One DC may handle up to

1000 SM, but usually the

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.

The solution can be

duplicated at another location

with no problem, using the

same AMI Head End platform.

Echelon Data Concentrators (DC),

(with built in GPRS communication

modem)




with the SM using OSGP.




with the SM using OSGP.

Unlimited. The no of DCs is

dependent on the no of

installed SM, usually approx.

700-800 SM is the maximum

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.

The solution can be

duplicated at another location

with no problem, using the

same AMI Head End platform.


to be used

SMs See above. See above. See above. See above.


111 | 151



Meter Data Concentrators, (with

built in GPRS communication

modem)

See above. See above. See above. See above.

Schneider Electric Smart Transformer Data exchange between the

MV/LV booster transformer

and an overlying application,

e.g. MV SCADA, should be

interoperable with those

system managing to receive

data in the formats used by

the booster transformer, i.e.

IEC 104 protocol. In the

Swedish demonstration this

will be tested, since the

ambition is to integrate this

booster transformer against

existing MV SCADA platform

Power on Fusion, supplied

by General Electric.

Limited, since the core

feature of the transformer is

the function for voltage

regulation, i.e. to limit or

even eliminate the impact of

voltage fluctuation on the LV

lines. But any transformer

with this function using

standardised IEC 104

protocol should be possible

to replace with this model.

(If this voltage regulation

feature is not necessary, this

type of transformer would

not be installed).

Limited, mainly due to the

investment cost for the

transformer. This type is

designed for LV networks

where voltage fluctuation

cannot be easily handled in

another way without larger

network re-constructions.

E.g. the network situation

has changed due to

increased DER installation

etc.

High, since the booster

transformer is designed to

suit network operations in

general, where voltage

fluctuation is required to be

managed in order to fulfil

quality of supply. One

limitation may be the size of

the transformer, since the

booster part increase the

size. This requires some more

space for the installation.


112 | 151



RTU devices (or equivalent IED) for

LV measurement in secondary

substations (10/0.4 kV)

If the RTU (or IEDs) are using

a standardized protocol for

information sharing,

interoperability should be

high. Any RTU/IED should be

able to communicate with

an overlying system using

the same protocol interface.

This will specifically be

tested in the Swedish

demonstration, using

RTUs/IEDs from different

manufacturers and integrate

these against several

(different) LV SCADA/DMS

systems.




interchangeability should be












systems.

For the entire system model,

i.e. RTU communication with

an overlying LV SCADA/DMS

platform, there should be no

limitation in the number of

RTUs/IEDs being connected.

One limitation may be

noticed for single secondary

substations with several

(>15) outgoing LV lines. If

each line is being measured

this require many devices,

not perhaps RTUs but

connected "meter modules"

per LV line. The limitation

may be the space required

in the secondary substation

for the installation.

In general the same solution

should be possible to install

in any secondary substation,

large (concrete) as small (pole

mounted). One limitation

may arise due the different

ages of the substations,

which may cause technical

challenges for the

installation. One such

example could be the size of

the low voltage switchgear

case, which may not be able

to allow for the CT

installations.


113 | 151



FPI - Fault passage Indicators for fault

detection and localisation on MV

network

If the FPIs (or "sensors") are

using a standardized

protocol for information

sharing, interoperability

should be high. Any

FPI/sensor should be able to

communicate with an

overlying system using the

same protocol interface. The

ambition is to test this in the

Swedish demonstration,

using FPI/sensors from

different manufacturers and

integrate these against

existing MV SCADA/DMS

systems.




interchangeability should be












systems.

The number of FPIs/sensors

is not a limiting factor. The

entire solution should be

able to include as many FPIs

as required. Each FPI is point

to point connected to the

overlying system. The

required number of FPIs per

MV feeder depends on the

network topology, number

of intersections, how precise

the fault detection and

localisation should be etc.

One limitation may be the

required network pre-

requisites. In order to

achieve the correct technical

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.

In general the same solution

should be possible to install

in MV network.


required network pre-

requisites. In order to achieve

the correct technical 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.


114 | 151



Modem/router for GPRS/2G/3G or

other secured communication

Different modems/routers

should be possible to use.

One requirement usually is

that the modem/router has

a port for Ethernet

connection, unless the

device does not use a built

in modem, like the Echelon

DCs used in the Vattenfall

SM process. Another

limitation is if the

communication is restricted

with IT security regulations,

where only certain

modems/routers have been

approved for network

operations, e.g. remote

breaker operations etc.

One modem/router should

be possible to exchange

with another, if they have

equivalent ports for IED

connections. Another

limitation is if the

communication is restricted

with IT security regulations,

where only certain

modems/routers have been

approved for network

operations, e.g. remote

breaker operations etc.

No limitation if the volume

of assigned IP-addresses is

sized to hold the total

volume of connected

devices.

No limitation, except for the

communication service

provided by the operator.

Any modem/router should be

possible connect to the

operator despite the location

in the communication

network, e.g. GPRS, cover the

area.


115 | 151



Re-closer/breaker for remote

network operation/automation

Data exchange between a

MV network re-

closer/breaker and an

overlying application, e.g.

MV SCADA, should be

interoperable with those

systems managing to receive

data in the formats used by

re-closer/breaker.

One re-closer/breaker, with

the same technical

specification, should be

possible to re-place with

another re-closer/breaker

from another manufacturer.

The ambition is to test this

in the Swedish

demonstration and integrate

the "demo" re-

closer/breaker with the

existing MV SCADA/DMS

system.



provided at the location for

the re-closer/breaker. In

some rural areas

communication may not

exist, why a remote

operable re-closer/breaker

may not be an option to

install.



provided at the location for

the re-closer/breaker. In

some rural areas

communication may not

exist, why a remote operable

re-closer/breaker may not be

an option to install.

CT - Current Transformers in

secondary substation.

(Others, which may be tested are

Rogowski Current Transformers,

micro snap-on CT)

May be limited, depending

on the integration interface

between the CT and the

RTU/IED or the "meter

module" in between the

RTU/IED and the CT.

Different types are used,

e.g. wireless using ZigBee or

with cable.

May be limited, depending

on the integration interface

between the CT and the

RTU/IED or the "meter

module" in between the

RTU/IED and the CT.

Different types are used,

e.g. wireless using ZigBee or

with cable.

Unlimited if the installation

space in the low voltage

switchgear allows for the

size of the CTs to be

connected to the wires. In

some cases some LV

switchgears are too small

where the CT is to be

connected around the wire.

Unlimited if the installation

space in the low voltage

switchgear allows for the size

of the CTs to be connected to

the wires. In some cases

some LV switchgears are too

small where the CT is to be

connected around the wire.


116 | 151



CT - Current Transformers for MV

network FPIs

Assumed to be good, many

manufacturers of current

transformers are

interoperable with IEDs, e.g.

RTUs, FPIs/sensors etc.,

independent of the supplier.

Integration in most cases

based on cable, using

standardised protocols. One

limitation may be if the

FPI/sensor only can be

wirelessly integrated with

CTs. In this case, a certain

type of CTs may be required.

Assumed to be good, many

manufacturers of current

transformers are

interchangeable to connect

with IEDs, e.g. RTUs,

FPIs/sensors etc.,

independent of the supplier.

Integration in most cases

based on cable, using

standardised protocols. One

limitation may be if the

FPI/sensor only can be

wirelessly integrated with

CTs. In this case, a certain

type of CTs may be required.

See answer for FPI above /

Scalability.

See answer for FPI above /

Replicability.


N/A



process)

N/A


117 | 151

4.4 POLISH DEMONSTRATOR

Table 27 summarises the main impacts of the identified protocols presented in Table 18 for the Polish




118 | 151

TABLE 27: IMPACTS FOR THE UPGRID POLISH DEMONSTRATOR PROTOCOL LIST




DLMS COSEM

Companion specifications

(meter data models) are

based on Blue Book, but DSO

specific deviations and

changes are defined, thus

they are not 100%

interoperable.

May prove a bit difficult due

to different companion

specifications in different

countries.


the same companion

specification and have it

implemented in the meter

(typical, meter hardware can

be the same for given

vendor, just the firmware is

different).

PRIME 1.3.6 - 4-32 CS PRIME compliance tests by a





STG 3.1


XSDs related to

reports/orders are defined in

the specification.

Possible to ensure if

specification closely

followed. An integration test

is always advised.



properly implemented.



IEC 60870-5-104: Telecontrol

equipment and systems – Part 5-104:

Transmission protocols – Network

access for IEC 60870-5-101 using

standard transport profiles. Second

edition, 2006

Yes, as long as required

functions are equally

implemented by

interoperable equipment.



implemented by

interoperable equipment.

Not an issue. Full – this is widely

recognised standard.


119 | 151



IEEE 1815: IEEE Standard for Electric

Power Systems Communications—

Distributed Network Protocol (DNP3).

Revised edition, 2012



implemented by

interoperable

equipment/software.



implemented by

interoperable

equipment/software.

Not an issue. Full – this is a widely


IEC 61970.: Energy Management

System Application Program

Interfaces EMS-API

Yes, according to the defined

data exchange profile.

Can be assured by

interoperability (IOP) tests.



IEC 61968: Application Integration at

Electric Utilities - System Interfaces

for Distribution Management



Can be assured by

interoperability (IOP) tests.



IEC 61968-100: Application

integration at electric utilities -

System interfaces for distribution

management - Part 100:

Implementation profiles



The IEC 61968-100 is well

defined and its expected that

IEC61968-100 compliant

applications are

interchangeable (function-

wise).




DCSAP

Relatively easy to achieve

since the specification is fully

open, moreover a reference

implementation is available.

An interoperability test is

advised to prove full

interchangeability. Reference

implementation may be

helpful.


services can be properly

implemented (reference

implementation available).


120 | 151






developed

DLMS COSEM extensions for LV

monitoring and control units

A fully documented

extension definition will be

provided to assure possible

interoperability.

Once the extensions are

implemented into other LV

monitoring and control

devices, they will be

interchangeable.

Not an issue. The definition of the

extension will be available,

so proper (replicable)

implementations will be

possible.

TABLE 28: IMPACTS FOR THE UPGRID POLISH DEMONSTRATOR EQUIPMENT LIST




PRIME SMs

Fully interoperable on a

PRIME protocol level.

Not necessarily

interoperable on the DLMS

COSEM level, due to possible

differences in companion

specifications.

Not necessarily

interchangeable due to

possible differences in

hardware design (HAN ports,

alternative communication

ports, meter display design

etc.).

Common (non smart

metering features) are

ensured by compliance with

MID directive

Not an issue Same as with

interchangeability.


121 | 151



PRIME data concentrators

Fully interoperable on a

PRIME protocol level.

Not necessarily


COSEM level, due to possible

differences in companion

specifications.

(note: there may be different


meters and data

concentrators).

Not necessarily

interchangeable due to

possible differences in

hardware design (inclusion

/non-inclusion of the

internal balancing meter,

comm ports etc.).

Not an issue. Same as with

interchangeability.


to be used

IEEE 60870-5-104 or IEEE 1815

Monitoring and control units for

MV/LV substations

Monitoring and control units

for MV/LV substations are

usually interoperable, since

they are compliant with IEEE

60870-5-104 and/or IEEE

1815, and their feature sets

have a common

denominator.

Generally interchangeable,

as long as required feature

set is implemented.

Not an issue. Same as with

interchangeability.


N/A


122 | 151





process)

LV monitoring and control unit

The unit will be

interoperable on the PRIME

protocol level, as

standardised protocol stacks

will be used.

The unit will also be


COSEM level, as it will

adhere to minimum

requirements - in terms of

implemented & required

DLMS operations - defined

by the Green Book

If functionally equal unit is

developed - fulfilling the

same specification and

delivering the same feature

set - then the

interchangeability will be

possible.

Not an issue Possible to replicate, if the

same feature set is

implemented in the same way


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


124 | 151

TABLE 29: SENSORS AND IEDS

Demonstrator High-level

protocol layers Low-level protocol

layers GAP

Recommendations for new developments

Spanish N/A

Portuguese N/A

Swedish Proprietary ZigBee High-level protocol uses proprietary data model.

Use ZigBee application

standards as ZigBee

Smart Energy SEP 2.0,

which defines

Information model

objects derived from

IEC CIM (61968) and

61850.

Polish N/A

TABLE 30: IEDS AND DATA CONCENTRATORS



layers GAP


Spanish

DLMS/COSEM (CTI Companion standard)

RS485 with HDLC

No See section 5.1.2.

IEC60870-104 (Iberdrola companion standard)

PRIME 1.3.6


Portuguese Proprietary RS485 with HDLC

High-level protocol uses proprietary data model.

Use IEC60870-104 (see section 5.1.1).

Proprietary RS485 with MODBUS


N/A

Swedish N/A

Polish DLMS/COSEM with extensions

PRIME 1.3.6


TABLE 31: DATA CONCENTRATOR, OR IEDS, AND SCADA



layers GAP


Spanish


IP network No See section 5.1.1.

Portuguese IEC60870-104 (EDP companion standard)


Swedish

IEC60870-104 or DNP3

IP network based on GPRS


Proprietary file format

FTP over an IP network based on GPRS

File uses proprietary data model.

Use IEC 61968-9 for defining the format of the file. See 5.1.3


125 | 151



layers GAP


Polish IEC60870-104 or DNP3


TABLE 32: BETWEEN SCADAS



layers 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



layers GAP


Spanish


IP network No N/A

Portuguese CIM (proposed in Deliverable 1.1)

Web services Lack of definition See 5.1.3.

Swedish CIM Web services Lack of definition (unknown profile)

See 5.1.3.

Polish CIM IEC 61968-100 No See 5.1.3.

TABLE 34: INSIDE MANAGEMENT LEVEL



layers GAP


Spanish CIM Web services Lack of definition (unknown profile)

See 5.1.3.

Portuguese CIM Web services Lack of definition (unknown profile)

See 5.1.3.

Swedish CIM Web services Lack of definition (unknown profile)

See 5.1.3.

Polish CIM IEC 61968-100 No See 5.1.3.

TABLE 35: SMS AND SM CONCENTRATORS



layers GAP


Spanish DLMS/COSEM PRIME 1.3.6 No See section 5.1.2.

Portuguese DLMS/COSEM PRIME 1.3.6 No See section 5.1.2.

DLMS/COSEM GPRS No See section 5.1.2.

Swedish Proprietary OSGP over ETSI TS 103 908


N/A

Polish DLMS/COSEM PRIME 1.3.6 No See section 5.1.2.


126 | 151

TABLE 36: SM CONCENTRATORS AND AMI HEAD-END



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

Swedish Proprietary OSGP over ETSI TS 103 908 (Echelon)

High-level protocol uses proprietary data model

N/A

Polish STG 3.1 SOAP STG is not a standard protocol N/A

TABLE 37: AMI HEAD-END AND MANAGEMENT LEVEL



layers GAP


Spanish STG 3.2 SOAP STG 3.2 is not a standard protocol

Use CIM. See 5.1.3.

Portuguese STG 3.1 SOAP STG 3.1 is not a standard protocol

Use CIM. See 5.1.3.

Swedish GS2 IP network

GS2 is not a standard protocol,

but It is considered a de facto

standard in the Nordic

countries

Use CIM. See 5.1.3.

Polish CIM IP network No See 5.1.3

TABLE 38: PRIME NETWORK MANAGEMENT



layers 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



layers 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



layers GAP


Spanish Proprietary SOAP High-level protocol uses proprietary data model.

Use CIM. See 5.1.3.

Portuguese Proprietary SOAP High-level protocol uses proprietary data model.

N/A

Swedish N/A


127 | 151



layers GAP


Polish Proprietary Web services High-level protocol uses proprietary data model.

Use CIM. See 5.1.3.

TABLE 41: HOME DEVICES



layers GAP


Spanish N/A

Portuguese

Not defined ZigBee Not defined high-level protocol layer

Use ZigBee application standards as ZigBee Smart Energy or ZigBee Home Automation

Not defined PLC Not defined high-level protocol layer

Use Prime for PLC and DLMS/COSEM for 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:


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


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


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

Spanish

PRIME SM Meter

If functional (e.g. measurement functions) and non-functional requirements (e.g. physical dimensions, communication ports, terminal positions, temperature requirements, HMI, national regulations,…) are commons between demos

Line Monitoring Units

IED If functional and non-functional requirements are commons between demos.

Data concentrators Data concentrator

If functional and non-functional requirements are commons between demos.

Portuguese

PRIME SM – EDP Box

Meter If functional and non-functional requirements are commons between demos.

DTC – Distribution Transformer Controller

Data concentrator


Router Communication equipment


Swedish

Echelon SMs (SM) Meter Impossible because the DLMS/COSEM is not compatible with OSGP.

Echelon Data Concentrators (DC), (with built in GPRS communication modem)

Data concentrator

Impossible because the DLMS/COSEM is not compatible with OSGP.

Polish

PRIME SMs Meter If functional and non-functional requirements are commons between demos.

PRIME Data concentrators

Data concentrator


Wireless GSM GPRS/EDGE/UMTS ,CDMA modems/routers/switches for MV/LV substations

Communication equipment



131 | 151

TABLE 43: NEW EQUIPMENT TO BE INSTALLED UNDER UPGRID

Demonstrator Equipment type Equipment type Interchangeability

Spanish

PRIME Base node that supports both application, IP and SMs

Data concentrator



Data concentrator


Portuguese

PRIME SM – EDP Box

Meter If functional and non-functional requirements are commons between demos.

DTC – Distribution Transformer Controller

Data concentrator


Router Communication equipment


Home devices IED / Data concentrator


Swedish

SMs Meter Impossible because the DLMS/COSEM is not compatible with OSGP.

Meter Data Concentrators, (with built in GPRS communication modem)

Data concentrator

Impossible because the DLMS/COSEM is not compatible with OSGP.

Schneider Electric Smart Transformer


RTU devices (or equivalent IED) for LV measurement in secondary substations (10/0.4 kV)


FPI - Fault passage Indicators for fault detection and localization on MV network


Modem/router for GPRS/2G/3G or other secured communication

Communication equipment



132 | 151

Demonstrator Equipment type Equipment type Interchangeability

Re-closer/breaker for remote network operation/automation4


CT - Current Transformers in secondary substation. (Others, which may be tested are Rogowski Current Transformers, micro snap-on CT)

Sensor If functional and non-functional requirements are commons between demos.

CT - Current Transformers for MV network FPIs

Sensor If functional and non-functional requirements are commons between demos.

Polish

IEEE 60870-5-104 or IEEE 1815 Monitoring and control units for MV/LV substations


DLMS/COSEM/PRIME Monitoring and control units 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


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


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

ftp://ftp.cencenelec.eu/CENELEC/Smartgrid/M490.pdf

https://www.cen.eu/Pages/default.aspx

http://www.cenelec.eu/aboutcenelec/whatwedo/technologysectors/smartgrids.html

http://www.etsi.org/

http://www.nist.gov/

http://www.etsi.org/images/files/ECMandates/m441%20EN.pdf

http://www.cencenelec.eu/standards/sectors/mid/pages/default.aspx

http://www.gt-engineering.it/uploads/allegati/25expert_group1.pdf

http://www.gridplus.eu/Documents/20130228_EEGI%20Roadmap%202013-2022_to%20print.pdf





135 | 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 Communications—Distributed 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

ftp://ftp.cencenelec.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/SGCG_Interoperability_Report.pdf

ftp://ftp.cencenelec.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/SGCG_Interoperability_Report.pdf



http://www.nist.gov/smartgrid/upload/nistir-7628_total.pdf

ftp://ftp.cencenelec.eu/CENELEC/Smartgrid/M490.pdf

http://www.gridplus.eu/


136 | 151

[39] DISCERN project http://www.discern.eu/; D5.2 - DISCERN guide for facilitating the replication and

scalability of the solutions

http://www.discern.eu/


137 | 151

DESCRIPTION OF PROTOCOLS Annex I.

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 line–related 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.


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


139 | 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 1990’s 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.


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


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


142 | 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 Utilities—System 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:


143 | 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 1–405, 2013, WWW.IEC.CH)

FIGURE 24: IEC 61968-11 CIM BASE DATA MODEL. (FROM IEC 61968, COMMON INFORMATION MODEL (CIM)/

DISTRIBUTION MANAGEMENT, PART 1–13, 2013, WWW.IEC.CH)

http://www.iec.ch/


144 | 151

FIGURE 25: IEC 62325-301 CIM BASE DATA MODEL. (FROM IEC 62325, FRAMEWORK FOR ENERGY MARKET

COMMUNICATIONS, PART 1–502, 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 doesn’t 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.


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


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


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


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


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

http://www.dnp.org/


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


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